B1260 Custom register byte write bug

[paraj]

Suuuuuper minor, but I don't think this matches real HW behavior.

Attached executable when run with quickstart Blizzard 1260 + "Best compatibility" (includes Adv. chipset -> Custom register byte write bug), ouputs 7f00 0000. My real B1260 outputs 7f00 7fff (even w/o startup sequence).

Core is:

        lea     custom,a0
        move.w  #$4000,intena(a0)
        move.w  intreqr(a0),d0
        or.w    #$8000,d0

        move.w  #$7fff,intreq(a0)
        move.b  #$ff,intreq(a0)
        moveq   #0,d6
        move.w  intreqr(a0),d6

        move.w  #$7fff,intreq(a0)
        move.b  #$ff,intreq+1(a0)
        moveq   #0,d7
        move.w  intreqr(a0),d7

        move.w  #$7fff,intreq(a0)
        move.w  d0,intreq(a0)
        move.w  #$c000,intena(a0)

        PRINTF  <"%04lx %04lx",10>,d6,d7

I.e. there is difference in handling of writes to odd bytes.

[Toni Wilen]

Confirmed (and fixed). I had (and still have) Blizzard 68060 that I used to confirm this years ago but perhaps I used bad test values.

Still need to do some test program that writes and reads random values to ADKCON and AKDCONR to 100% confirm this (make sure there is no random behavior or dependencies on "bus noise"). (ADKCON/ADKCONR is easier, can "safely" modify them without need to disable interrupts)

[paraj]

Thanks for your continued attention to even the smallest details

Do you mean something like the attached? At least on my system KS v. 3.1 trackdisk is messing with some of the adkcon bits, but maybe you can avoid that if you disconnect the drive?

With interrupts off it gets through the 1M iterations on both B1260 and plain 020.

If I keep them on I see effect of the occasional change:
00fc61f4 30bc 0600 move.w #$0600,(a0)
00fc61f8 30bc 9100 move.w #$9100,(a0)