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

npomarede at corp.free.fr npomarede at corp.free.fr
Fri Dec 26 22:52:33 CET 2008

On Fri, 26 Dec 2008, Thomas Huth wrote:

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

I found an example, it was not just related to .b access ; in fact when 
writing .b at address $ff8240, this writes the same value at $ff8241 !

so, $ff8240.b=4 implies $ff8240.w=$404

Here's a little program, with results tested on a STF :

         lea     $ff8240,a0
         lea     res,a1

         move.w  #$777,(a0)

         move.b  #0,(a0)
         move.w  (a0),(a1)+      ; f888
         move.b  #1,(a0)		; -> $101
         move.w  (a0),(a1)+      ; f898
         move.b  #2,(a0)
         move.w  (a0),(a1)+      ; 0202 / fa8a
         move.b  #3,(a0)
         move.w  (a0),(a1)+      ; 6303 / 0b03
         move.b  #4,(a0)
         move.w  (a0),(a1)+      ; fd8c
         move.b  #5,(a0)
         move.w  (a0),(a1)+      ; fd8d
         move.b  #6,(a0)
         move.w  (a0),(a1)+      ; fe8e
         move.b  #7,(a0)
         move.w  (a0),(a1)+      ; 7707 / ff8f

         move.w  #$377,(a0)
         move.w  (a0),(a1)+      ; 1bff / fbff
         move.b  #7,(a0)         ; -> $707
         move.w  (a0),(a1)+      ; 1f07 / 1f0f

         move.b  #7,1(a0)        ; -> $707
         move.w  #$707,(a0)      ; -> $707

         move.b  #$77,1(a0)      ; -> $777 white

         dcb.l   20,0

I'm not sure some program are making use of this feature, but it could be 
good to implement it anyway. Also, we can see that what we read from the 
color register is not always constant. Unused bits are mostly filled with 
1, but not always.

I recall it could have something to do with the fact that these bits are 
reflecting what is happening on the bus or something like that (same as 
when you make the video address points outside of the RAM on a real ST, 
you see a lot of "activity"), so they would be quite random in fact.


More information about the hatari-devel mailing list