[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

> 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?


More information about the hatari-devel mailing list