CIA Interrupts and Timers and Ports

[nocash]

CIA A and CIA B are said to be able to generate INT2 and INT6 accordingly... but I don't know what INT2 and INT6 are referring to... my three theories would be:
- INT2/INT6 are causing Bit2/Bit6 in INTREQR to be set (that would be "SOFT" and "BLIT")?
- INT2/INT6 are meaning CPU Interrupt Level2/Level6 and do set Bit3/Bit13 in INTREQR (that would be "PORTS" and "EXTER")?
- INT2/INT6 might refer to CPU Interrupt Level2/Level6 but do not affect any bits in INTREQR?
Am I on the right way, or is it working even differently?

Here's some kickstart code that doesn't work right in my emu, and I am having problems to imagine how it could/should work at all.
Caution: The disassembler syntax used here is showing operands ordered as "destination,source" (unlike normal 68000 syntax).

FE9292  call    0FE953Ah               ;-init some CIA stuff
FE9296  movb    [0F00h+a0],8h          ;-stop timer b
FE929C  movb    [600h+a0],0FFh         ;\timer b reload = FFFFh
FE92A2  movb    [700h+a0],0FFh         ;/
FE92A8  movw    [0DFF09Ah],4000h
FE92B0  addb    [126h+a6],1
FE92B4  call    0FE930Eh ;@@waitvsync  ;-wait, with timer b stopped ???
FE92B8  movb    [0F00h+a0],19h         ;-start/load timer b
FE92BE  call    0FE930Eh ;@@waitvsync  ;-wait, with timer b running
FE92C2  movb    [0F00h+a0],8h          ;-stop timer b
FE92C8  movd    d0,0h
FE92CA  movb    d0,[700h+a0]
FE92CE  shld    d0,8
FE92D0  movb    d0,[600h+a0]
FE92D4  subb    [126h+a6],1
FE92D8  jge     0FE92E2h ;@@cont1
FE92DA  movw    [0DFF09Ah],0C000h
       @@cont1:
FE92E2  cmpw    d0,0CCDDh
FE92E6  ja      0FE92F0h ;@@cont2
FE92E8  movd    d0,32h
FE92EA  movw    d1,4E20h
FE92EE  jmp     0FE92F6h ;@@cont3
       @@cont2:
       @@amok_jump:
FE92F0  movd    d0,3Ch
FE92F2  movw    d1,411Bh
       @@cont3:
FE92F6  movw    [22h+a2],d0
FE92FA  movw    [24h+a2],d1
FE92FE  movb    [213h+a6],d0
FE9302  movd    a1,a2
FE9304  call    0FFFFFE50h+a6
FE9308  popd    d2,a2,a3
FE930C  ret
       ;---
       @@waitvsync:
FE930E  movb    d0,[800h+a0]        ;-TOD.lsb
       @@wait_lop:
FE9312  cmpb    d0,[800h+a0]        ;-TOD.lsb
FE9316  jnz     0FE9336h ;@@wait_done
FE9318  tstb    [700h+a0]           ;-timer b.msb
FE931C  js      0FE9312h ;@@wait_lop
FE931E  pushd   d7,a5,a6
FE9322  movd    d7,15000002h
FE9328  movd    a6,[4h]
FE932C  call    0FFFFFF94h+a6
FE9330  popd    d7,a5,a6
FE9334  jmp     0FE92F0h ;@@amok_jump   ;<-- go amok without "ret" ???
       @@wait_done:
FE9336  ret

Essentially, the "@@waitvsync" function is supposed to wait for the CIA TOD vsync counter to change, or, if that doesn't happen, to generate some timeout via CIA Timer B.
The first call to "@@waitvsync" seems to have three problems:
- Timer B counter is still unitialized (only the reload value is initialized)
- Timer B is stopped
- And, assuming that uninitialized counter would be less than 8000h: The jump at FE931C wouldn't be taken, so following code would hit the "@@amok_jump" stuff (with the return address being left on stack, and thus crashing a moment later; that looks really like a bug in the kickstart rom).
The code would pass without crashing if something would initialize Timer B counter to a value of 8000h..FFFFh. Is that happening anywhere? Maybe upon Reset? Or maybe anytime when stopping the Timer? Or when writing to the Timer reload value, is that also changing the counter value? Official docs say that counter is read-only though.
Or well, maybe I am still having bugs in my disassembler, or my emulation has failed to execute some important CIA initialization function.

Oh, and what is the "Memory Overlay" bit (in CIA A Port A Bit 0) doing? Is that bit causing ROM to be mirrored to address 00000000h (so the CPU could fetch the Reset vector from ROM)?

[Toni Wilen]

That strange m68k disassembly syntax is unreadable..

INT2/INT6 are meaning CPU Interrupt Level2/Level6 and do set Bit3/Bit13 in INTREQR (that would be "PORTS" and "EXTER")?

This.

The code would pass without crashing if something would initialize Timer B counter to a value of 8000h..FFFFh. Is that happening anywhere? Maybe upon Reset?

Hardware reset sets all CIA timer counters to FFFF.

Oh, and what is the "Memory Overlay" bit (in CIA A Port A Bit 0) doing? Is that bit causing ROM to be mirrored to address 00000000h (so the CPU could fetch the Reset vector from ROM)?

Exactly.

[nogginthenog]

Originally Posted by Toni Wilen

That strange m68k disassembly syntax is unreadable..

It's x86 syntax for the 68000. Surely that's a bannable offence :-)

[nocash]

Thanks, Toni! That answers helped me to get through some problems (oh, and sorry for not replying earlier).

[Locutus]

That disassembly output just made me puke

[Lazycow]

Uahh... come on, use another disassembler

[Photon]

Originally Posted by Toni Wilen

That strange m68k disassembly syntax is unreadable..

It's "68000 8086 style" syntax? I think i saw it once before. I do agree it's horrible, of course. Original syntax is & was always a strength of 680x0. You could read it like a novel <3

From this I'm thinking the confusion might be partly "IRQ vs INT". In all CPUs, IRQ is an interrupt request and INT is an interrupt. On old PCs it's more well-known as "a way to invoke an interrupt". Whatever that shit is about. Well, it's about BIOS

How the interrupts work in CPUs is explained as applied on Amiga with code examples in Amiga System Programmer's Guide which is available as PDF on archive.org. For a formally correct explanation without code examples, turn to Amiga Hardware Reference Manual, which is available online at dev.elowar.com.

Sorry if you knew all this, links are just for completeness.

[nocash]

Yes, 8086 syntax. I can only read that kind of code like a novel, but yeah, it depends on what you are familar with, seeing code with reversed source/dest ordering can be quite a brainkiller.
Anyways, back to first seven lines of my disassembly:

FE9292  call    0FE953Ah               ;-init some CIA stuff
FE9296  movb    [0F00h+a0],8h          ;-stop timer b
FE929C  movb    [600h+a0],0FFh         ;\timer b reload = FFFFh
FE92A2  movb    [700h+a0],0FFh         ;/
FE92A8  movw    [0DFF09Ah],4000h
FE92B0  addb    [126h+a6],1
FE92B4  call    0FE930Eh ;@@waitvsync  ;-wait, with timer b stopped ???

My mistake has been that I missed this important sentence from the CIA specs: "In one-shot mode, a write to timer-high will transfer the timer latch to the counter and initiate counting regardless of the start bit."
So, the timer wasn't stopped at all, and the counter wasn't uninitialized either.

Just treating the timer as stopped with initial reset value of FFFFh worked to get through above code, although that wasn't exactly what happened on real hardware, and emulating it that way still caused problems later on (disc stepping also relies on starting/reloading the one-shot timer on MSB writes).