[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)