Re: [hatari-devel] defaulting to SMALL_MEM

[ Thread Index | Date Index | More Archives ]

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?


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() )


Mail converted by MHonArc 2.6.19+