|Re: [hatari-devel] TT version of 4getful by gwEm crashes with newer Hatari versions|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 08/02/2016 23:52, Eero Tamminen a écrit :
Volume issue is fixed in EmuTOS.
It's only v1.9 and current Hatari WinUAE version with which
4getful TT-version bombs. It starts fine with WinAUE version
from start of last summer, or current OldAUE Hatari version.
didn't have time yet to look at this, but it's on my never-ending todo
list for Hatari :)
Additionally, my fix to the TT palette sync issue Roger reported,
breaks 4getful palette handling. The reason is similar to color
register writes on ST, IO register code doesn't support splitting
long access to 2 word accesses, so current code misses every other
color register change when they're written with longs.
Nicolas, should I add separate function for each ST color
register on TT, similarly to ST/e code, or change the ST/e color
register handling functions to do the work also for TT case?
Is this when writing to ST palette and copying to TT regs with
Video_TTColorSTRegs_WriteWord, or the opposite ?
What is the asm code that does the write to colors regs ? Does colors
looks wrong with old cpu core or with the latest winuae core that
doesn't bomb (or both) ? Since 68030 can do long word access, winuae cpu
core will call the lput handler, but old cpu core will call the wput
PS. Starting TOS v3 with 4 MB bombs regardless of CPU core version.
We would need to look at TOS memory detection, but this could be related
to not enabling the MMU in TT mode ?