| Re: [hatari-devel] Add full support for STF/STE MMU |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Just tell me if you need a falcon test.
Laurent
Le 04/01/2017 à 23:42, Nicolas Pomarède a écrit :
Hi
I completed the new part that emulates STF/STE MMU and the different
address translations we can get depending on the MMU settings for each
of the 2 banks (128 KB, 512 KB or 2048 KB).
Thanks a lot to Christian for his documentation on the address mapping
to the CAS/RAS signals.
On STF, the MMU will default to the more versatile version where bank0
and bank1 can have different values (ie the non-IMP version)
On STE, the MMU will always use bank0 size for bank1.
Although very rarely used, this emulation of $ff8001 will allow TOS to
boot and detect RAM without having to patch the memvalid variables
ourselves.
When STF/STE is used with 4 MB or less, then we now use another
versions of the lget/wget/bget/lput/wput/bput functions for RAM which
do an additionnal address translation based on the MMU setting.
These translations were compared to a real STF for all 9 possible
settings, Hatari results should be similar to real HW.
When MMU is configured to match the physical RAM size, then we default
to the usual memory access functions (without translation), so there
will be no speed penalty in 99% of the time, only a slight overhead
during boot when TOS/Emutos change MMU config to detect RAM size.
This emulation can be useful to Emutos devs if they want to test their
RAM detection code without using real HW.
It's also interesting as it now allows STF/STE to boot completely
without any patch in TOS (assuming gemdos HD is not used, only
floppy), thus making Hatari even more "stealth" and closer to the
original HW.
Code is not 100% completete yet, I will add later code for the TT
translations too (according to TOS 3, there're only 2 possible MMU
settings) ; as for Falcon, it seems TOS 4 doesn't use FF8001 at all,
so this register might be ignored (this needs more tests)
Nicolas