View Single Post
Old 23 December 2014, 15:36   #711
Toni Wilen
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,549
Made In Croatia problem better explanation (before everyone forget what was the real problem..)

It has following code:

000002AC 47f9 00bf d000           LEA.L $00bfd000,A3
000002B2 177c 007f 0d00           MOVE.B #$7f,(A3, $0d00) == $00bfdd00
000002B8 422b 0e00                CLR.B (A3, $0e00) == $00bfde00
000002BC 2b7c a000 2000 ffca      MOVE.L #$a0002000,(A5, -$0036) == $00dff09a
000002C4 21fc 0000 05b0 0078      MOVE.L #$000005b0,$00000078
Because of TOD bug, CIA-B ALARM interrupt is active at this point (and has been active since the initial vector part started, confirmed on my real A500 with oscilloscope connected to CIA-B interrupt pin)

Move to $bfdd00 does not clear the interrupt, only reads clear interrupts, disabling CIA interrupt by writing to $bfdd00 won't disable already active interrupts.

Then comes move.l #$a0002000,-$36(a5). Enable CIA-B interrupt ($a000->INTENA) and attempts to clear currently active CIA-B interrupt ($2000->INTREQ).

INTREQ write does nothing because it is external (CIA) interrupt. (Logic analyzer confirmed, CPU IPL lines won't change)

Finally interrupt vector is set, same vector that previous line enabled. If interrupt starts before this write: crash.

Reason: some MOVE.L variants read interrupt state before writes and some after writes. For example MOVE.L #$a0002000,$dff09a will read it after both writes (and would crash) but MOVE.L #$a0002000,(an) or x(an) read it before writes (and work). All 3 variants have 100% identical write,write,prefetch cycle sequence. (Most/all MOVE.W's seem to read if after writes)

This is yet another undocumented 68000 behavior, it seems interrupt line sampling is microcode controlled and different instructions sample it in different phases during instruction execution... (Fortunately in Amiga only MOVEs matter because custom registers are read-only or write-only)
Toni Wilen is online now  
Page generated in 0.04936 seconds with 9 queries