[hatari-devel] setting unused bits to 1 when reading hardware regs
Thomas Huth
huth at users.berlios.de
Fri Dec 26 20:04:07 CET 2008
> Datum: Fri, 26 Dec 2008 19:06:17 +0100 (CET)
> Von: npomarede at corp.free.fr
>
> I took my STF out of the box some days ago to do some measures on cycles
> precision and I also had a look at what happened when reading
> shifter/sound registers with unused bits ; I didn't think this mattered
> since we never saw problem with that, but it was wrong :
>
> - ff8260 : bits 2-7 are set to 1
> - ff820a : bits 2-7 are set to 1
> - ff8240-5c : on STF, bits 12-15 seem to be always 1, bits 3/7/11 are
> sometimes 0, sometimes 1. Can't say for STE, bits 3/7/11 are of course
> used but I don't know for 12-15.
>
> I committed a change for $ff8260/0a to add a OR with 0xfc, this fixes
> Awesome menu 16 (why does the TOS needs unused bits set to 1, that's
> really strange).
Ah, OK, I think the trick is that with your patch, the value (read
with MOVE.W $ff8260,...) becomes negative. And negative values are
likely ignored when passed as parameter to the Setscreen XBIOS
function.
> For ff8240-5c, it's more complex. I know some programs are writing bits
> here to detect between STF/STE, so we should be cautious.
>
> Another small problem I saw with colors regs : they can only be accessed
> with .W acces, but on ST you can do a 'move.b #7,$ff8241' and it works. On
> Hatari this will give some wrong colors because we don't "mix" the result
> with the content of $ff8240.
Are you sure? If I look at the code in video.c
(Video_ColorReg_WriteWord ff.) it looks like the code can handle both,
word and byte accesses (it always uses IoMemReadWord to get the
value). Do you have a sample program which fails here?
Thomas
More information about the hatari-devel
mailing list