|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: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sun, 20 Feb 2022 08:48:16 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1645346900; bh=yi1y0kY4eNsGIPses8nhbFl7EBqxdPrv36wVcoLIwRc=; h=Date:From:To:Subject:From; b=WvwwRD1rxgdiW4kZl92+spT3Q1DZ1mOlbt8Q4X4gQRHwdlS6OhnLzm4OzO89V3HwP c6j/gAiIZywDsijL98J3AQIfmtnPQyv1nUKyQsmT++WdNDBtmnMzxmr7+3m/TbvyKz vbZjx4pDv3O2ZWUPOXsdPueRyG3jYaT9FLs/fcM6U+p82DH18aEYDnjeRFlRcCR83n TDAkyT2oT4lgdXLoleXC6T353TaVklfBJbTP5sue7pCTm0lUkRG/CEeELOC+AcWJmW hE9WPpdAOskISn3VRmDytDWTYXP6vV+tZvmdFMHmZIQ14CfFwjvqec4oYhbyzs2PeU DVmeoOkEQqYIA==
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
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
> - 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?