Re: [hatari-devel] Hatari Falcon 060 emulation observations

[Thomas Huth <th.huth@xxxxxxxxx>]

 Hi Laurent,

a very late reply, but now I finally also had some spare minutes to look
at the ct60 TOS images...

On 11/11/2018 22.35, Laurent Sallafranque wrote:
> Hi,
> 
> I've managed to boot the CT60 TOS to the desktop with very few changes
> to hatari (That's only a proof of concept for now).
> 
> To make it run to the GEM :
> 
> modify 1 line in hatari code in memory.c
> 
> #define TTmem_end    0xffffffff     /* Max value for end of TT ram,
> which gives 2047 MB */
> //#define TTmem_end    0x80000000            /* Max value for end of TT
> ram, which gives 2047 MB */

That's a very ugly hack. A slightly less ugly hack is this one, to
change memory_init() to not generate a bus error for these regions
anymore:

diff a/src/cpu/memory.c b/src/cpu/memory.c
--- a/src/cpu/memory.c
+++ b/src/cpu/memory.c
@@ -1785,6 +1785,21 @@ void memory_init(uae_u32 NewSTMemSize, uae_u32 NewTTMemSize, uae_u32 NewRomMemSt
        }
     }
 
+    if (!ConfigureParams.System.bAddressSpace24 && TosVersion == 0x404
+        && ConfigureParams.System.nCpuLevel == 5)
+    {
+       map_banks_ce(&VoidMem_bank, 0xf000, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf040, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf080, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf0c0, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf100, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf140, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf180, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf1c0, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf200, 0xff, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+       map_banks_ce(&VoidMem_bank, 0xf300, 1, 0, CE_MEMBANK_CHIP32, CE_MEMBANK_NOT_CACHABLE);
+    }
+
     illegal_count = 0;
 }

.... then the ct60 TOS does not crash anymore, but of course still
fails to detect the DIMMs.

> Then, add 2 conditional CPU breakpoints:
>    1:    pc = $e9adb2
>    2:    pc = $e9d658
> 
> At the first breakpoint,
>> r pc=$e9ae6c
>> c
> 
> At the second breakpoint,
>> r pc=$e00798
>> c
> 
> That's all ;)

I think we can't handle this via TOS patches easily, since there
are multiple versions of this TOS available, and the addresses are
not always the same.

If we really want to support the ct60 TOS, I think someone has to
implement the ct60 MMIO registers:

http://tho-otto.de/hypview/hypview.cgi?url=%2Fhyp%2Fct60.hyp&index=84

.... which involves emulation of an I2C bus and the SPD data of the
DIMMs. Not impossible, but certainly a bunch of work.

>>> IDE 0.0
>>> And here I got : EXCEPTION PROCESSING 2: Access Fault and a debugger
>>> message appears with the registers.

The ct60 TOS seem to expect that the IDE bus is always available. The
exception should go away when you add an IDE driver to the emulated
system. ... maybe we should always enable the IDE registers on the
Falcon, I've also seen some other software already (Cecile HD driver
for example) which depends on the availability of these registers on
the Falcon...

 Thomas