[hatari-devel] setting unused bits to 1 when reading hardware regs

npomarede at corp.free.fr npomarede at corp.free.fr
Fri Dec 26 19:06:17 CET 2008

Quoting thomas answer on atari-forum, regarding the strange resolution 
problem when exiting Awesome menu 16



Code: Select all
0000cc38:    MOVE.W $ffff8260,$0001ad5e
0000cc40:    MOVE.L $0000044e,$0001ad5a

Note that it reads the FF8260 register with a WORD access, though this 
register is only one byte long. That's a bug.

When you push a key to exit the intro, it restores the resolution (and 
screen base) like this:

Code: Select all
0000cc7c:    MOVE.W $0001ad5e,-(A7)
0000cc82:    MOVE.L $0001ad5a,-(A7)
0000cc88:    MOVE.L $0001ad5a,-(A7)
0000cc8e:    MOVE.W #$0005,-(A7)
0000cc92:    TRAP.L #$0000000e
0000cc94:    LEA.L (A7,$000c) == $0001b08e,A7

This only works by accident if the "move.w $ff8260,..." results in a zero. 
As soon as it results in another value (what happens on Hatari, where a 
read to $ff8261 results in $FF), the Setscreen call fails.

Now the question: Do you always get 0 on a real ST when you read from 
$FF8261 ? What about STE, TT and Falcon? Does anybody know? Unfortunately 
I don't have my ST here at the moment, so I can't verify it on my own...


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).

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.

Hope I didn't break anything with this late patch, time to pack my bag and 
go on holidays :)


More information about the hatari-devel mailing list