|Re: [hatari-devel] add support for TT ram ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On keskiviikko 17 joulukuu 2014, Nicolas Pomarède wrote:
> I just committed support for extra TT RAM when the selected machine is
> set to "TT".
> This was tested with TOS 3.06 and EmuTOS 0.9.3.
> This works by simulating the bus errors that the TOS will encounter when
> scanning the possible extra RAM starting at address $10000000.
> As such, the following parameters are needed in Hatari :
> - 24 bit addressing should not be used, else there's no way to see
> more RAM if upper 8 bits of an address can't be used
> - "patch TOS for faster boot" should not be used, because it would
> bypass the TOS' detection for TT RAM, and no RAM would be added.
> As a side note, it's not advised to set this setting, as it can lower
> the compatibility with some games that expect the whole TOS boot
> sequence to be made (so, I will change it to default to false for new
I've changed TOS memory setup code to automatically disable 24-bit
addressing and fastboot if TT-RAM is used under TT emulation. It
will notify user about about this.
As there's no point in using 32-addressing unless there's TT-RAM,
and it makes things less compatible, I'm forcing 24-bit addressing
when TT-RAM is not in use. Should I remove 24-bit selection from
SDL GUI, options and config file too?
> - if using EmuTOS, there's a bug in version 0.9.3 (and lower) where
> EmuTOS will crash when 32 bit addressing is used and a cartdridge is
> detected at address $FA0000. This means TT RAM and HD emulation can't be
> used at the same time for the moment.
> You should either use TOS 3.06, or wait for EmuTOS 0.9.4 that fixes this
No need to wait, Vincent did EmuTOS CVS snapshot including the fix:
>If you boot TOS 3.06 with HD gemdos emulation, you will get some messages :
> GEMDOS Fsfirst() failed due to invalid DTA address 0x121c00e0
> And you can't access c: or whatever letter your HD has been assigned.
> After tracing various calls, the problem is in gemdos.c where basically
> all code that does HD interception expect the DTA to be in standard RAM,
> not in valid TT RAM :(
> So, only solution for now to have extra TT RAM and HD is to use
> a direct HD image, not the HD gemdos emulation.
Just use EmuTOS, only TOS v3 has that problem.
> Such extra RAM won't be available at the moment for Falcon, because TOS
> 4 doesn't scan $1000000 for extra RAM (due to its 24 bit addressing
> limitation). EmuTOS doesn't scan it either, as Falcon are not supposed
> to have such RAM anyway.
> Next steps :
> - add support for TT RAM in Falcon mode, by patching TOS variables
> - add support for TT RAM in TT/Falcon mode when using "patch TOS for
> faster boot"
After these are done, the forcing part can be updated.