|Re: [hatari-devel] defaulting to SMALL_MEM|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] defaulting to SMALL_MEM
- From: Christian Zietz <czietz@xxxxxxx>
- Date: Wed, 9 Feb 2022 20:19:42 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1644434383; bh=w3sTT/RF/fVFVEyocjH5jIq17A3lU7wrkeK7dmurSKk=; h=X-UI-Sender-Class:Date:To:References:From:Subject:In-Reply-To; b=Ki6mBVQo5GdKTHX8KdjkP2FjBC/3imLsAOzMbwt6xaI1+EB5PZdJIJP2vXhCh09ev 8Qxnv63Kc2UBbDIIySTXVosfwDJsOnWRMFG4KaltnXClXJToeha6T5D6u85zsOjT0N NUUeIxDETAQUrU32u1g6+MBQs0PWH8DWU/5juccQ=
Eero Tamminen schrieb:
For some reason, these Valgrind errors happen only with TOS4, not with
Meanwhile, I have an idea what's going wrong in Hatari. I don't have
time to fully prove my theory; but hopefully it'll help anyway.
Via NVRAM (see my post where I attached it) I configured the Falcon to
boot in 1-bit-per-pixel (mono) mode. Switching the Videl to mono is
tricky, as was discussed about a year ago on the EmuTOS list.
Atari TOS does so via an intermediary step, where it switches to a 4 bpp
mode. For this intermediary step the allocated amount of video memory is
not sufficient, so the Videl reads past the end of ST RAM. This is
apparently harmless on real hardware, but on Hatari with SMALL_MEM it
accesses unallocated memory, potentially causing an access violation.
(EmuTOS uses a different method.)
The easiest fix might be to allocate a bit more memory than needed for