CIA test

Toni Wilen · 25 October 2006, 19:25

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.

Code:

	; 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 · 25 October 2006, 20:28

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 · 25 October 2006, 20:33

what does it mean?

Toni Wilen · 25 October 2006, 20:40

It means:

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

keropi · 25 October 2006, 20:41

oh, thanx

musashi5150 · 25 October 2006, 20:56

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 · 25 October 2006, 21:05

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:

Quote:

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 · 26 October 2006, 13:48

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 · 26 October 2006, 16:39

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 · 26 October 2006, 18:25

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

I added following code:

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 · 27 October 2006, 01:27

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 · 27 October 2006, 02:39

Quote:

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 · 27 October 2006, 07:54

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 · 03 March 2007, 22:14

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.

25 October 2006, 20:33	#3
keropi . Join Date: Oct 2004 Location: Ioannina/Greece Posts: 5,041	what does it mean? __________________ *A1200D mfilos ed.* : ACA 1231/42 , Indivision MK2 , IDEfix Express , Subway , PicoPSU 120w custom 3.9 ROM/OS**

25 October 2006, 20:41	#5
keropi . Join Date: Oct 2004 Location: Ioannina/Greece Posts: 5,041	oh, thanx __________________ *A1200D mfilos ed.* : ACA 1231/42 , Indivision MK2 , IDEfix Express , Subway , PicoPSU 120w custom 3.9 ROM/OS**

26 October 2006, 18:25	#10
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 38 Posts: 12,034	Hahaa, it is real hardware bug, but not in ALARM == TOD comparator. TOD incrementation logic is buggy.. I added following code: 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. Last edited by Toni Wilen; 26 October 2006 at 18:36.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A little test for you hackers...	Ray Norrish	Coders. General	3	17 April 2006 01:55
Hardware symbols includes like cia.i	Photon	Coders. General	6	10 March 2006 23:48
Take the Amiga purity test!	Andrew	Retrogaming General Discussion	39	07 October 2003 19:15
who wants to test my site	blobrana	Amiga websites reviews	5	02 September 2002 20:23

25 October 2006, 20:28	#2
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 31 Posts: 2,245	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...

25 October 2006, 20:40	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 38 Posts: 12,034	It means: - my program has a bug or - CIA ALRM interrupt does something undocumented.

25 October 2006, 20:56	#6
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 31 Posts: 2,245	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... ?

26 October 2006, 13:48	#8
Doc Mindie In deep Trouble Join Date: Sep 2004 Location: Manchester, Made in Norway Age: 40 Posts: 802	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

26 October 2006, 16:39	#9
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 38 Posts: 12,034	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.

27 October 2006, 01:27	#11
Doc Mindie In deep Trouble Join Date: Sep 2004 Location: Manchester, Made in Norway Age: 40 Posts: 802	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.

27 October 2006, 07:54	#13
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 38 Posts: 12,034	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)

03 March 2007, 22:14	#14
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 38 Posts: 12,034	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.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

AdSense
Advertisement:

AdSense
Advertisement: