> > Think about something like a PDA. They have buttons to bring specific Apps > > to the front. That is pretty similar to a switchaway. Now such a PDA > > has no MMU usually ... so how do we transparently remap the VidRAM > > to some normal RAM there? > > Difficult - right?
> Not at all! AROS does it, AmigaOS does it, exactly that way! Please detail. I would like to know how you do that _WITHOUT_AN_MMU_ and with hard-mapped graphics RAM areas. I know it can be done if we have an MMU, I know it can be done if we can just tell the graphics hardware to display another piece of main memory. But can it be done if the graphics RAM is at 0xe0000000 and normal system RAM is at 0x00000000-0x10000000 and we have no MMU to change that for the application's view? > I know it can be done - the OS I code can do it - so I see no reasons as > for why ggi/kgi shouldn't do it. It can do so, because it has a MMU or can change the base of the vidram on the display chip probably. If it does it in another way, I'd like to learn about that. How do you tell an app (without the app cooperating) that the addresses it is writing to have changed? Eventually in the middle of a write? > since I have no chance to convince you, No. You of course have the chance. I changed my mind once, from your point to my current one, and I might as well change it back to my old position, if you can show me that it can be done on any target, not only on pretty sophisticated hardware that can be abused to dynamically map some fake framebuffer to a place where the real one was. > and since I have no time to implement the stuff myself, I'll drop the > discussion here. Please don't. If you can convince me on that, I'm fully with you, that it would be the nicest thing to have, as it allows us to just transparently switch first, and then send the app an event which it can process asynchronously, then to decide what to do. But I just doubt it can be done anywhere, and I am afraid, that it can get really really complex and hard to code in the cases where it can be done. CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
