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

[Thomas Huth <th.huth@xxxxxxxxx>]

On 05/05/2019 18.34, Nicolas Pomarède wrote:
> Le 05/05/2019 à 17:03, Vincent Rivière a écrit :
>> Hello,
>>
>> I use a recent Hatari Git compiled for Cygwin.
>> It seems there is a bug between "24 bits addressing" and reset.
>>
>> I use a custom EmuTOS which display traces about the internal IS_BUS32
>> value. Basically, it is detected by writing a value to address 0x0c
>> (Address Error vector). If that value also appears at address
>> 0x0100000c (should be either nothing or TT-RAM), then this is a 24-bit
>> address bus. Also, if reading that 32-bit address causes a Bus Error,
>> then this is a 32-bit bus, as it should have read back the value at
>> 0x0c if it was 24-bit.
>>
>> - I start Hatari with a 68030 configuration, with "24 bits addressing"
>> unchecked. It is detected as 32-bit, fine.
>> - F12, CPU. I check "24 bits addressing", click "Back to main menu",
>> click "Reset machine", click OK. It is still detected as 32-bit
>> (because no bus error occurred), this is wrong.
>> - F12. I just click "Reset machine" then OK. It is now detected as
>> 24-bit, this is good.
>>
>> The fact that 2 reset are required to take in account that "24 bits
>> addressing" option is a bug in Hatari.
>> And of course, this is very confusing when doing tests.
>
> yes, this is a known issue, it was discussed in february in thread "Quit
> dialog suggestions". Not fixed yet, but it will be.

What do you think about this suggestion:

diff a/src/cpu/memory.c b/src/cpu/memory.c
--- a/src/cpu/memory.c
+++ b/src/cpu/memory.c
@@ -1612,7 +1612,7 @@ void memory_init(uae_u32 NewSTMemSize, uae_u32 NewTTMemSize, uae_u32 NewRomMemSt
 {
     int 	addr;
 
-    last_address_space_24 = currprefs.address_space_24;
+    last_address_space_24 = ConfigureParams.System.bAddressSpace24;
 
     /* Round to next multiple of 65536 bytes */
     STmem_size = (NewSTMemSize + 65535) & 0xFFFF0000;
@@ -1697,7 +1697,7 @@ void memory_init(uae_u32 NewSTMemSize, uae_u32 NewTTMemSize, uae_u32 NewRomMemSt
     /* Handle extra RAM on TT and Falcon starting at 0x1000000 and up to 0x80000000 */
     /* This requires the CPU to use 32 bit addressing */
     TTmemory = NULL;
-    if (!currprefs.address_space_24)
+    if (!ConfigureParams.System.bAddressSpace24)
     {
 	/* If there's no Fast-RAM, region 0x01000000 - 0x80000000 (2047 MB) must return bus errors */
 	map_banks_ce ( &BusErrMem_bank, TTmem_start >> 16, ( TTmem_end - TTmem_start ) >> 16, 0, CE_MEMBANK_CHIP16, CE_MEMBANK_NOT_CACHABLE);
@@ -1771,7 +1771,7 @@ void memory_init(uae_u32 NewSTMemSize, uae_u32 NewTTMemSize, uae_u32 NewRomMemSt
      * to 0xff000000, so we remap memory 00xxxxxx to FFxxxxxx here. If not,
      * we'd get some crashes when booting TOS 3 and 4 (e.g. both TOS 3.06
      * and TOS 4.04 touch 0xffff8606 before setting up the MMU tables) */
-    if (!currprefs.address_space_24)
+    if (!ConfigureParams.System.bAddressSpace24)
     {
       /* Copy all 256 banks 0x0000-0x00FF to banks 0xFF00-0xFFFF */
       for ( addr=0x0 ; addr<=0x00ffffff ; addr+=0x10000 )

Vincent, does that fix the problem for you?

 Thomas