Re: [hatari-devel] Bug with "24 bits addressing" and reset

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 1 Jun 2019 00:40:15 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 5/31/19 6:11 PM, Thomas Huth wrote:
> > On 05/05/2019 18.34, Nicolas Pomarède wrote:  
> >> Le 05/05/2019 à 17:03, Vincent Rivière a écrit :  
> ...
> > Vincent, does that fix the problem for you?  
> 
> IMHO easiest way to test this is checking automatic
> 32-bit addressing enabling for TT.
> 
> ------------------------------------------
> $ hatari --machine tt --addr24 off --ttram 32 --trace os_base --tos 
> etos512k.img
> ..
>                     EmuTOS Version:     0.9.10
>                      CPU type:           M68030
>                      Machine:            Atari TT
>                      ST-RAM:             4 MB
>                      Alt-RAM:            32 MB
>                      GEMDOS drives:      AB
> ------------------------------------------
> 
> => Works when 24-bit addressing is explicitly disabled.  
> 
> ------------------------------------------
> $ hatari --machine tt --ttram 32 --trace os_base --tos etos512k.img
> ERROR: Enabling 32-bit addressing for TT-RAM access.
> This can cause issues in some programs!
> ..
>                     EmuTOS Version:     0.9.10
>                      CPU type:           M68030
>                      Machine:            Atari TT
>                      ST-RAM:             4 MB
>                      GEMDOS drives:      AB
> ------------------------------------------
> 
> => shows the Hatari dialog, but automatic 32-bit address change  
>     doesn't currently work in Hatari.
> 
> Your patch seems to fix this:
> ------------------------------------------
> $ hatari --machine tt --ttram 32 --trace os_base --tos etos512k.img
> ERROR: Enabling 32-bit addressing for TT-RAM access.
> This can cause issues in some programs!
> ...
>                      EmuTOS Version:     0.9.10
>                      CPU type:           M68030
>                      Machine:            Atari TT
>                      ST-RAM:             4 MB
>                      Alt-RAM:            32 MB
>                      GEMDOS drives:      AB
> ------------------------------------------
> 
> => TT-RAM present with automatic 32-bit mode switch.  

Ok, patch committed now.

> There may be also some extra places where things aren't in sync,
> as WinUAE CPU core and Hatari use a different variable for this.
> 
> Check "git grep" output for "address_space_24" and "bAddressSpace24".
> 
> There's e.g. this:
> ------------------------------------------
> #ifndef WINUAE_FOR_HATARI
>          if (currprefs.cpu_compatible) {
>                  if (currprefs.address_space_24 &&
> currprefs.cpu_model 
>  >= 68040)  
>                          currprefs.address_space_24 = false;
>          }
> #else
>          /* Hatari : don't force address_space_24=0 for 68030, as the 
> Falcon has a 68030 LC with only 24 bits */
>          /* TODO ? Force address_space_24=0 for 68040 ? */
> #endif
> ------------------------------------------
> 
> Shouldn't Hatari disable 24-bit addressing also for >= 040?

I guess that's a philosophical question. AFAIK the 68030 in the Falcon
is also a 32-bit CPU, where the engineers simply did not wire up the
uppermost 8 address bits. So one could imagine a 68040 or 68060
accelerator card where the uppermost 8 address bits are also not wired
up. Does not make too much sense, but it is certainly possible.

So I think we could either keep the code and for the flexibility here,
or say that we do not care and rather want the code to be closer to the
WinUAE sources again... Most people who try to emulate a Falcon with a
68040 or 68060 want to have Fast-RAM and thus 32-bit memory anyway.

 Thomas