Re: [MiNT] 040/060 MMU tree builder

[tlang@dialup.becom.net (Torsten Lang)]

Hi Thomas,
> 
> How does the "infamous" Splitram.prg for the Hades work, as it actually
> does remap RAM, i.e. split the large ST-RAM block into ST-RAM and
> TT-RAM, as it should be?
> 
I've written splitram.prg since Fredi didn't do anything to solve the problems
Bernd and me had. Well, as you may remember the first Hades accessories from
Fredi deactivated the caches depending on some rules you could configure.
This lead to a lot of trouble since this seemed not to be implemented in a
clean and systemfriendly way. So Fredi did a special accessory version that
didn't contain that cache switching routines any more. But there still was
a problem left: When you activate the mmu (e. g. by activating the rom-port
emulation) the accessory did build new mmu tables to split the ram. At
this point you couldn't leave gem anymore since unloading the acc would crash
the system. So I asked Fredi to split his acc into a TSR splitting the ram
immediately and an acc for controlling the TSR what he didn't do until now.

splitram.prg does nothing magical - it's not more than a fast hack to provide
separate ST and TT ram: It cuts down ST-RAM to 14MB (so you MUST have more
than 16MB in your Hades to use this) and adds all memory above 16MB as TT-RAM.

Since newer TOS versions that know TT-RAM (>=2.06) definitely have problems
on >68030 systems without TT-RAM this was the easiest way to solve
problems. Another point is that older programs using the ST-compatible IO-
area won't trash any memory in use any more.

A small drawback is that you lose 2MB of RAM (well, otherwise I would have to
remap the RAM which dows not make sense without system-wide cache- and mmu support
routines) but since ram really has become cheap...

Another drawback is that Fredi's acc doesn't work anymore together with splitram.

Regards,
   Torsten