Re: [hatari-devel] defaulting to SMALL_MEM

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 19 Feb 2022 14:29:01 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
[...] 
> 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.

Ok, if you really think this is necessary, then we indeed have to
consider one of the solutions below...

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

I assume we agree that we don't want to go down that road since the
functions are already quite complex.

>   - 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.

Ack, we should avoid a performance regression if possible.

>   - 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.

As we've recently learnt, SMALL_MEM is even a little bit faster than
using the big 16 MiB array, and 4 MiB (+2 MiB for I/O and ROM) is still
better than 16 MiB, so I think I'd vote for the option #3 now.

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

Ok, but I guess we could also switch the DMA functions here, too? Just
like I did in commit 853fdeef9d438c for the crossbar code?

 Thomas