[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Application compatibility




concerns.  My idea was for a partial virtual machine, making certain
attributes inheritable from the parent, such as VDI physical/parent workstation,

For legacy applications running in a window while they believe they are on a screen of their own?

Make the parent create a shared memory off-screen bitmap in whatever mode the child is known to like, which the child then gets as the target when it opens its virtual workstations, while the parent periodically blits to the real screen. Or you could just use the feature to force an application into a window even if it would prefer the entire screen.
The AES might not be too happy about either of these arrangements, though.

make logbase per application, have physbase mapped via the MMU,

Logbase() has "never" been used as it is, which is a very good thing. Making such an amazingly "hackish" feature something that is supported via the OS is a terrible idea, IMO. There were "write to memory buffer" drivers from the very first days of the GDOS and later off-screen bitmaps, which are a much better way to do things if you absolutely must draw outside of the actual screen.

Having Logbase() be global but still changeable is of course a definite recipe for disaster, but the obvious thing to do is to completely disable it. I have yet to hear about a single program having problems with disabled Logbase().

have other hardware vectors and such remapped via the MMU - sound,
timers, and MIDI come to mind.

To make old games and midi sequencers and such work under memory protected MiNT?

For example, if an application writes directly to the screen or assumes
a specific resolution or color depth, it would be possible to have this
application write to a memory buffer instead, either with VDI tricks
and/or mapping the screen to memory via the MMU.

I think the way this works is ... when the app tries to do a direct
screen memory write, a page fault occurs due to write protection.  The
fault is caught, write protection removed, and the page is marked dirty.
...

You'd also need to copy the screen data corresponding to that page there before you allow the application to start writing, since it may not be intending to update the entire page. And you'd have to do an on-the-fly conversion to whatever mode the application is expecting the screen to be in...

This kind of thing really isn't workable unless you do it for a full "virtual" screen at once. It would be really hard to get it to integrate with other applications on the screen if you're actually in a different real mode (which you are almost guaranteed to be since the set of applications drawing to the screen is very nearly limited to old games and monochrome only software).

If you are going to do it on a full screen basis, using the MMU to mark modified pages is indeed a good way to lessen the amount of work needed when updating the real screen periodically. Even better, if this was a game it would be doing its updating outside of the current screen and then switch using Physbase(), so just blit everything when that call is made.

In any case, this is sort of Atari-on-Atari emulator thing. Not something that would need to involve any part of the OS.

--
| Why are these | johan@klockars.net
|  .signatures  |
| so hard to do | http://www.klockars.net
|     well?     | (fVDI, MGIFv5, QLem)