Re: [hatari-devel] defaulting to SMALL

On Sat, Feb 19, 2022 at 5:29 AM Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

Le 19/02/2022 à 10:12, Thomas Huth a écrit :

>
> I just tried this, but it does not really work: If the user configured
> less than 4 MiB of STRam, we also allocate less than 4 MiB of memory.
> But the Atari program could still set the memory base address somewhere
> close to the 4 MiB area, way beyond the ST-RAM + safety space, so
> Hatari still crashes in that case. To really be safe with this
> approach, we'd always need to allocate at least 4 MiB + safety space
> of memory to make sure that the 22 bit video address base never can
> point to an unallocated memory region.
>
> I have to say that I don't like the idea to always allocate 4 MiB just
> because of this. So I think I'd rather keep the current approach, and
> if we're worried about the video address counter not advancing anymore
> after the end of STRam, we should maybe simply increase pVideoRaster by
> SCREENBYTES_LINE bytes, without taking the border effects into account,
> since it is really completely unlikely that a program sets the video
> base to the end of ST-RAM *AND* opens borders *AND* then still depends
> on the accuracy of the video address counter ... or what do you think?

Hi

I don't think it's too much to allocate always 4 MB RAM, it's still
better than allocating 16 MB and also the first 4 MB are special : even
if not all ram is plugged, the region < 4 MB will return the data last
seen on the bus when reading it, while the region > 4MB will really do a
bus error.

I think I already saw some games/demos that set video address to close
to end of RAM and would read above 512 KB (can't remember which ones,
maybe "leavin terramis" did this) and in that case it's important to
update pVideoRaster.

For example, as part of a protection a demo/game could set video address
above physical RAM, then do some tricks to remove left/right borders and
then use the content of the video address counter to decode the protection.

If we consider that pVideoRaster will only increase by SCREENBYTES_LINE
in that case, then such protections will not work.

I see several possible solutions in that case :

- maintain a really more complex Video_CopyScreenLineColor to check we
don't access above allocated (and also Video_CopyScreenLineMono at some
point, because it's possible to do some border tricks in mono, even if
not supported yet in Hatari), while still correctly updating pVideoRaster

- don't use memcpy functions, but use get_word() to copy data 1 word
at a time, taking all memory regions into account (as in cpu/memory.c) ;
would work, but screen rendering would be slower by a huge factor.
This could be an option if we want someday a "cycle accurate" shifter
emulation, but not for the generic case.

- always allocate 4 MB + safety margin and keep current code as it is

- don't default to SMALL_MEM and keep current code as it is

I don't think SMALL_MEM is really necessary given today's computer and
it's only 16 MB to allocate, but that's only my opinion, I understand
other would like to save ram.

Then as a trade off between really more complex code and lowering RAM
usage and keeping the possibility to emulate border tricks even when
video points outside physical RAM, I would go for nbr 3 and always
allocate 4 MB + margin.

Also , I think the code in dmaSnd.c is accessing STRam[] directly too,
so we can have same problem of reading unallocated memory. Doing nbr 3
would fix that too (for blitter it's OK already, it uses get_word() )

Nicolas