16 May
2005
16 May
'05
2:25 p.m.
On 5/16/05, Allison <ajp166 at bellatlantic.net> wrote:
Handy and required... some vintage ROMs do some funny stuff writing
against ROM for efficiency believe that it won't have any effect. But
writing against RAM has an effect, and against flash can lock up the
flash since it can trigger its state machine.
Ok, the usual MMU only fairly fine grained. Does any apps make use of
that kind of MMU and space?
Not yet, this is a new thing, and there's no software to take
advantage of the full potential yet.
Each block in
the map can be marked read-only so that if you are
emulating ROM with RAM or flash you get a perfect emulation, i.e. any
writes against ROM don't get applied.
Handy!
Now I understand what it is and the basic logic
inside. Like many MMU
based 8bitters the addition of large ram is usually to emulate disk.
I'm curious to see if any actually do swaping or overlay so the app
can access a larger space or larger data. The reason for that is
most cases that is rare or not even done.
Well the M100 uses a RAM based file system. Our MMU is a new thing, so
any use made of it beyond emulating multiple M100 fast-switch maps
will be by new software. In particular I'm planning a management
program that can set up maps and burn new ROMs to flash or set them up
in RAM. But the spec will be freely available so user programs can get
direct access to extended RAM. All you need to do is CLEAR enough
space to get a 1K window and a BASIC program can start PEEKing and
POKEing extended RAM without too much trouble. That's why we have such
a fine-grain MMU block size.
-- John.