| Re: [hatari-devel] Preparing release 2.3 - status |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 11/7/20 9:56 PM, Thomas Huth wrote:
Am Sat, 7 Nov 2020 19:31:11 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
Doc updates are done, but issues were found,
of which some are still open:
* Random Hatari crash with EKO system
-> Thomas & Nicolas are looking for better DMA
buffer handing fix
The crash is already fixed. The code could still be improved with
Nicolas DMA read/write functions, but that's certainly not something
that has to be done before the release.
Well, I'm pretty sure HW doesn't take ST RAM size
modulo of address values. :-) I.e while that
commit fixes the crash and missing sound in EKO,
it's not full/correct solution.
While rest can be fixed after release, I think
there should be some note of it being a temporary
band-aid so that doing proper fix doesn't get
forgotten after release. Either some TODOs in
code, or note in todo.txt.
If somebody has time to
complete Nicolas' patch and do all the regression testing afterwards,
you're very welcome. But at least I currently don't have enough spare
time to work on this, sorry.
Good to know, thanks!
* H20 music missing
(after v1.5 due to commit c96a36308)
-> Laurent investigating best fix
>
It would certainly be good to know what was causing this regression,
but since Falcon timings are far away from being perfect, it's just
"expected" that timing sensitive stuff sometimes works by accident, and
sometimes gets broken again. Thus this should not block the release.
Somebody needs to implement proper Falcon timings (and
corresponding regression tests) first before we can consider such
regressions as blocking.
It wasn't timing related issue, but as Laurent
isn't going to look at this before release, I just
updated compatibility doc.
* GEMPlay 1.99 double bus errors
-> can somebody reproduce this? If yes,
could somebody test it also on real Falcon?
* -2-10x slowdown in Hmm... & '_' demos under
EmuTOS compared to TOS4, even after STOP / DSP
fix
-> I'll profile Hatari
Certainly nothing that should block the release (since Hatari will be
shipped with EmuTOS 1.0 that does not contain the DSP support yet).
I think newer EmuTOS versions are also quite
important, as EmuTOS gets released more often
than Hatari, and users can update EmuTOS
independently.
While this obviously isn't a regression or release
blocker, I would still very much like to verify
before release whether it's Hatari or EmuTOS
issue. I.e. that there isn't some serious lurking
issue.
* Uwe's duplicate drive image issue
- will look into that last, unless somebody
else will
At least I currently won't have spare time to look into this. Sorry.
Sure, no problem. It will just take a bit of
extra time until I get to it.
- Eero