Re: [hatari-devel] defaulting to SMALL_MEM

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Fri, 18 Feb 2022 23:03:42 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 18/02/2022 à 21:33, Thomas Huth a écrit :
> > Am Thu, 17 Feb 2022 11:14:25 +0100
> > schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:  
> 
> >> That is, instead of allocating STRamEnd bytes for STRam[], we
> >> allocate STRamEnd + SCREENBYTES_LINE*10 bytes and fill this extra
> >> space of SCREENBYTES_LINE*10 bytes with 0.  
> > 
> > After thinking about this for a while, I agree, it's like the best
> > solution to add some margin to the allocation for this instead, to
> > avoid that the code gets too ugly and to avoid regressions with the
> > performance of the rendering functions.
> > 
> > But shouldn't we rather allocate NUM_VISIBLE_LINE_PIXELS *
> > NUM_VISIBLE_LINES / 2 bytes instead? ... in case a program sets the
> > memory base to the very end of the RAM and then does some fullscreen
> > tricks?  
> 
> yes, SCREENBYTES_LINE*10 was an example, but a proper counting should
> be done.
> In all cases it would just add less than 100 kB for a whole screen,
> so even if we round it to 100 or 200 kB if we're too lazy to do a
> proper counting of bytes, it's quite negligible.

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?

 Thomas