[hatari-devel] Memory, Falcon and TT (24 vs 32 bits computers)

[Laurent Sallafranque]

Yes, but if we can do these changes, we'll have more memory, the 68040 
(or 68060) and the 68040 MMU.

This mean the opportunity to be able to play the 060 demos.

Laurent


Le 20/01/2011 21:38, Eero Tamminen a écrit :
> Hi,
>
> On keskiviikko 19 tammikuu 2011, Thomas Huth wrote:
>> I don't think that you've got to change here much. The old UAE core
>> already has the address_space_24 configuration variable, which should
>> theoretically be able to switch between 24 and 32 bit mode.
>> The magic is here only done in uae-cpu/memory.c: When in 24 bit mode
>> (which is the only working mode in Hatari right now), the same address
>> banks are mapped multiple times already, so that it does not matter
>> which byte has been put in the highest 8 bits of the the address.
>>
>> I think you've only got the change both memory.c files a little bit if
>> you want to support Fast-RAM (beyond the 16 MB barrier) emulation.
> There's also the OS memory initialization code in stMemory.c and most
> of the Hatari code uses the macros&  inlines from stMemory.h to access
> memory:
> $ grep -l STMemory_ *.c */*.[ch]
> bios.c
> blitter.c
> fdc.c
> gemdos.c
> memorySnapShot.c
> mfp.c
> stMemory.c
> tos.c
> vdi.c
> xbios.c
> includes/stMemory.h
> cpu/hatari-glue.c
> debug/breakcond.c
> debug/debugcpu.c
> debug/debugInfo.c
> debug/evaluate.c
> uae-cpu/hatari-glue.c
>
> Can applications on TT/CT60 etc. use addresses pointing to TT/Fast-RAM
> e.g. in their GEMDOS calls?
>
> If yes, either stMemory.h macros&  functions need to be modified too
> or alternatively a lot of Hatari code needs to be changed to use AUE core
> functions instead...
>
>
> 	 - Eero
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>