CIA test

[Toni Wilen]

Run following code on your real Amiga (include model) without startup-sequence and if possible, explain the return value and value you expected.

I can't explain it

Executable attached, source below.

	; WARNING: ugly code ahead! :)

	lea $dff000,a6
	; disable interrupts
	move.w $1c(a6),d7
	move.w #$7fff,$9a(a6)

	; CIA-B base address
	lea $bfd000,a0

	; disable interrupts
	move.b #$7f,$d00(a0)
	; release possible TOD read latch
	move.b $800(a0),d0
	; clear possible old interrupts
	move.b $d00(a0),d0
	; write 0x000000 to ALARM
	bset #7,$f00(a0)
	move.b #0,$a00(a0)
	move.b #0,$900(a0)
	move.b #0,$800(a0)
	; write 0x000002 to TOD
	bclr #7,$f00(a0)
	move.b #0,$a00(a0)
	move.b #0,$900(a0)
	move.b #2,$800(a0)

	moveq #$40,d1
l2	move.b $900(a0),d0
	; TOD 0x004000 or higher?
	cmp.b d1,d0
	bcc.s l1
	; ALRM interrupt?
	btst.b #2,$d00(a0)
	beq.s l2
l1	; read TOD
	moveq #0,d6
	move.b $a00(a0),d6
	lsl.l #8,d6
	move.b $900(a0),d6
	lsl.l #8,d6
	move.b $800(a0),d6

	; restore interrupts
	move.w #$7fff,$9a(a6)
	or.w #$8000,d7
	move.w d7,$9a(a6)

	; output D6 to CLI

	move.l 4,a6
	lea dos(pc),a1
	moveq #0,d0
	jsr -$0228(a6)
	move.l d0,a3

	move.l d6,-(sp)
	lea s(pc),a0
	move.l sp,a1
	lea putchar(pc),a2
	jsr -$020a(a6)
	addq.l #4,sp

	move.l a3,a1
	jsr -$019e(a6)
	moveq #0,d0
	rts

putchar
	movem.l d0-d3/a6,-(sp)
	and.w #$ff,d0
	beq.s pc1
	move.w d0,d3
	move.l a3,a6
	jsr -$03c(a6)
	move.l d0,d1
	beq.s pc1
	move.w d3,-(sp)
	move.l sp,d2
	addq.l #1,d2
	moveq #1,d3
	jsr -$0030(a6)
	addq.l #2,sp
pc1	movem.l (sp)+,d0-d3/a6
	rts
	
dos	dc.b 'dos.library',0
s	dc.b '%ld',10,0

[musashi5150]

Amiga 500/68000/KS1.3/512K+512K+4M: 4096
Amiga 4000/68060/KS3.1/2M+16M+128M: 4096
CD32/68030/KS3.1/2M+16M: 4096

Still thinking about result...

[keropi]

what does it mean?

[Toni Wilen]

It means:

- my program has a bug
or
- CIA ALRM interrupt does something undocumented.

[keropi]

oh, thanx

[musashi5150]

To be honest Toni, my knowledge of the CIAs is a bit lacking... I think I've got an idea where you are going with this, but what were you expecting and why... ?

[Toni Wilen]

It sets ALARM to zero, TOD to 2, waits until ALARM interrupt triggers which _should_ only happen when ALARM == TOD -> only after TOD wraps around after about 17 minutes.

But my test program triggers the interrupt when TOD == 0x1000 (4096). It should return 16384 (0x4000, the limit value)

Interestingly this weird feature only triggers if ALARM equals zero.

Added:

CD32/68030/KS3.1/2M+16M: 4096

Hmm.. even CD32 has the "bug". CIAs are integrated in Akiko chip, I'd have expected possible hardware bugs being fixed during the Akiko design process..

[Doc Mindie]

it's possible that this bug might have had something they desired, and thus left it in there? Either that, or they didn't know what triggered the bug. Your pick

What is TOD anyways? Time Of Delay or something?

and why 17 minutes? it sure doesn't take even the A500 to count from 2 to 16384 17 minutes :scratch

[Toni Wilen]

TOD = Time Of Day.

I think the name originally come from 6526 CIA, used in C64 for example, which had "real" TOD, Hours/Mins/Seconds/10thseconds BCD counters.

8520 is 6526 + 4 register BCD TOD counter replaced with 3 register 24-bit binary counter. All other functions are exactly same.

CIA-B TOD counts horizontal syncs = 24-bit counter overflows in about 17 minutes (2^24 / (312 * 50) = 1075 seconds = 17.9 minutes. (PAL)

Counting to 16384 takes only ~1 second.

[Toni Wilen]

Hahaa, it is real hardware bug, but not in ALARM == TOD comparator. TOD incrementation logic is buggy..

I added following code:

..
lea out(pc),a1
moveq #-1,d2
move.b $900(a0),d0
cmp.b d0,d2
beq.s same
move.b d0,d2
move.b d0,(a1)+
same:
; TOD 0x004000 or higer?
...
out: dcb.b 10000

after running "out" had following values:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 10 11 12 13...

ADDED: 0F->00->10 transition takes only couple of cycles (maybe one E-clock cycle?) so TOD does not lose time because of this bug.

Programs that read TOD properly (=all programs most likely) by reading MSB first which enables read-latch don't see anything wrong.

[Doc Mindie]

Okays...... 1075secs ..... 17mins 55secs...... so nearly 18 mins..... get your maths right, Tony :P

However, on a serious note, I see where you were completely confuzzeled before...... things should not go from 15 to zero to 16 like that.

[girv]

Originally Posted by Toni Wilen

Hahaa, it is real hardware bug, but not in ALARM == TOD comparator. TOD incrementation logic is buggy

Nice find How old is the 8250 design and this is only uncovered now

A couple of questions spring to mind:

• you tested TODMID; does the bug also happen with TODLOW and TODHI? I think TODLOW is OK, or your test program would have stopped at TOD=0x000010.
• does it happen (to any byte) at other xF->x0 boundaries like 0x1F->0x20, 0x2F->0x30 etc. ? 0xFF->0x00 ought to be interesting to test at least
• does it happen on CIA-A as well?

[Toni Wilen]

TODLOW does not have the bug. TODHI not yet tested.

(17 or 18 minutes, who cares? I remember it being 17.something and I was too lazy to calculate it yet again)

[Toni Wilen]

Documenting another CIA feature/bug here:

Read access to TODHI does not latch the timer if ALARM-bit in control register B (CRB) is set.