Re: [hatari-devel] defaulting to SMALL_MEM (was: Hatari on constrained devices)

[Christian Zietz <czietz@xxxxxxx>]

Christian Zietz schrieb:

> There seems to be something amiss with the Falcon emulation in general.
> Even if I start Hatari with "-s 4 --machine falcon --tos TOS404.IMG",
> i.e, a supported RAM size, I just get a black window for a few seconds
> which then closes without any error message. In contrast, EmuTOS boots
> under Falcon emulation.
> This is with commit 175b878a, either using my own Windows builds or the
> one from http://antarctica.no/~hatari/.

Loading it into WinDbg yields the following information:

> (b00.4c70): Access violation - code c0000005 (first chance)
> hatari_win64_debug!Screen_BitplaneToChunky32+0xc:
> 00007ff6`df78841e 448b19          mov     r11d,dword ptr [rcx] ds:000002dd`481ac000=????????
>
> 0:000> k
>  # Child-SP          RetAddr               Call Site
> 00 000000ee`aa9ff1b8 00007ff6`df789718     hatari_win64_debug!Screen_BitplaneToChunky32+0xc [\home\hatari\hatari-builder2\hatari\src\screenConvert..c @ 205]
> 01 000000ee`aa9ff1d0 00007ff6`df7a2dc5     hatari_win64_debug!Screen_GenConvert+0x91e [\home\hatari\hatari-builder2\hatari\src\screenConvert.c @ 343]
> 02 000000ee`aa9ff350 00007ff6`df798f5e     hatari_win64_debug!VIDEL_renderScreen+0x3f5 [\home\hatari\hatari-builder2\hatari\src\falcon\videl.c @ 1007]
> 03 000000ee`aa9ff3f0 00007ff6`df74dfdf     hatari_win64_debug!Video_InterruptHandler_VBL+0x270 [\home\hatari\hatari-builder2\hatari\src\video.c @ 4373]
> 04 000000ee`aa9ff470 00007ff6`df7cf251     hatari_win64_debug!CycInt_CallActiveHandler+0x30 [\home\hatari\hatari-builder2\hatari\src\cycInt.c @ 784]
> 05 000000ee`aa9ff4a0 00007ff6`df7cca61     hatari_win64_debug!m68k_run_2ce+0x31d [\home\hatari\hatari-builder2\hatari\src\includes\cycInt.h @ 135]
> 06 000000ee`aa9ff520 00007ff6`df776463     hatari_win64_debug!m68k_go+0x266 [\home\hatari\hatari-builder2\hatari\src\cpu\newcpu.c @ 7608]
> 07 000000ee`aa9ff580 00007ff6`df777b46     hatari_win64_debug!M68000_Start+0x30 [\home\hatari\hatari-builder2\hatari\src\m68000.c @ 301]
> 08 000000ee`aa9ff5b0 00007ff6`e0199f71     hatari_win64_debug!SDL_main+0x4a5 [\home\hatari\hatari-builder2\hatari\src\main.c @ 966]
> 09 000000ee`aa9ff690 00007ff6`df7413c1     hatari_win64_debug!Disasm_ParseOption+0x144e
> 0a 000000ee`aa9ff720 00007ff6`df7414d6     hatari_win64_debug!public_all+0x3c1
> 0b 000000ee`aa9ff7f0 00007ffe`79c37034     hatari_win64_debug!public_all+0x4d6
> 0c 000000ee`aa9ff820 00007ffe`79e82651     KERNEL32!BaseThreadInitThunk+0x14
> 0d 000000ee`aa9ff850 00000000`00000000     ntdll!RtlUserThreadStart+0x21
>
> 0:000> dt STRam
> hatari_win64_debug!STRam
> 0x000002dd`47dab040  "`.???"
>
> 0:000> ? @rcx - @@(STRam)
> Evaluate expression: 4198336 = 00000000`00400fc0

As you can see, it crashes in Screen_BitplaneToChunky32() while
accessing 0x000002dd`481ac000. This is 0x400FC0 past the start of STRAM
(at 0x000002dd`47dab040). Thus, Hatari's "VIDEL" tries to read past the
end of STRAM. With SMALL_MEM, this address can point into non-allocated
memory, resulting in the access violation and ultimately the crash.

I'll leave it to someone familiar with the VIDEL emulation to figure out
why.

Regards
Christian