CIA-A TOD clock source with genlock

[mark_k]

The A500/A2000 Technical Reference Manual mentions (on page 9):

In the A500, the Time of Day clock is tied to the VSYNC signal rather than the power line. This results in the theoretical error of several minutes a day. For more precise timing, use the optional real-time clock.

In genlock mode, the genlock peripheral provides a 30Hz V/Z signal, which results in the clock running at half speed.

I assume the Z is actually a misprint for 2. Does WinUAE emulate that feature when CIA TOD source is set to vertical sync and the genlock connected box is checked? Seems a bit weird to me, though I never used a genlock back in the day.

[Toni Wilen]

I don't see how this can be true because it would make all vblank synced programs (for example demos) to run at half speed, not just CIA TOD and I don't remember anyone mentioning this kind of genlock side effect..

Perhaps some models (Commodore only?) had this "feature"? I have used some 3rd party genlocks and I don't remember anything weird happening.

[mark_k]

It wouldn't make vblank-synced programs run at half speed, since the vertical blank interrupt is generated by the custom chips independent of the fact that the HSYNC and VSYNC pins on Agnus are used as reset inputs when a genlock is connected. But there could be issues with programs which use the CIA TOD counters. For example a program which times disk head stepping using CIA-B TOD would step at half-speed when the genlock has an active video signal input. [Since the HSYNC signal is at half line rate, see below.]

The Amiga 1000 and 2000 (probably 3000 and 4000 too?) use the power supply tick for the CIA-A timer. So the genlock doesn't affect CIA-A TOD on those machines, it's just with the A500 that something strange could happen. The A/B2000 can be jumpered to use vsync as CIA-A tick, but it wasn't shipped like that from the factory.

Basic summary:

• With interlaced source video input to the genlock, the VSYNC line gets pulsed on each odd field, i.e. at ~30Hz for NTSC. On the A500 the VSYNC line is connected to CIA-A TICK.
• With non-interlaced source video input, the VSYNC line is pulsed on every field, i.e. at ~60Hz for NTSC.
• With both interlaced and non-interlaced source video input, the HSYNC line is pulsed every two scanlines. The HSYNC line is connected to CIA-B TICK.
• With no video input signal the Amiga generates its own syncs.

When the genlock is connected, the genlock generates horizontal and vertical reset signals which it derives from the incoming source video signal. (With no video signal present the genlock provides the Amiga master clock signal but the Amiga generates its own sync signals.) The Agnus HSYNC and VSYNC pins are inputs when the genlock is connected with incoming video signal.

Looking at the A500 schematic, the Agnus VSYNC line connects to pin 12 of the 23-pin video connector and CIA-A pin 19 (TICK). Similarly Agnus HSYNC connects to video connector pin 11 and CIA-B pin 19.

The HSYNC connection to CIA-B pin 19 is basically the same with the A2000 and B2000. So probably all Amigas can have a half-frequency HSYNC signal applied to CIA-B with genlock & active input video signal.

I read the A1300 genlock service manual (P/N 314983-01). [Anyone know if a scanned version is available online?]

If no video signal is present the Amiga generates its own sync signals. So no problem there. The difference comes when there is a video signal present. Then the genlock drives the Agnus HSYNC and VSYNC pins. And consequently the CIA-B tick pin. And for A500 or suitably-jumpered A2000, the CIA-A tick pin too.

For normal interlaced input video the VSYNC input is pulsed on every odd field, i.e. at ~30Hz for NTSC. With non-interlaced input video (e.g. perhaps from some VCRs or another Amiga) the VSYNC input is pulsed every field/frame, i.e. at ~60Hz for NTSC.

About the horizontal reset signal (HSYNC):

The horizontal reset circuit consists of U17B and U14B. The reset signal occurs on the alternate cycle of the horizontal beam counter. The FF U17B is toggled by the rising edge of RGH, and U14B is triggered by the rising edge of the U17B output. A 32 usec reset pulse is sent to the computer at the beginning of every other line.

About the vertical reset pulse (I've deleted parts for brevity):

The vertical reset pulse is generated on the even odd fields to reset the vertical beam counter of the computer. ... one can determine whether the start of the vertical synch is coincident with the beginning of a line or shifted by half a line. The circuit is configured to detect even odd fields, and is connected to the vertical reset logic so that the reset to the computer is sent on the even odd field. The vertical reset circuit ... generates a 64 usec pulse immediately after the detected vertical synch. ... NAND gate gates the reset pulse during the even field.

There are probably misprints in the text, where I think it should say odd instead of even. The vertical timing diagram indicates that the V/2 reset pulse happens on odd fields, and says "With non-interlaced video source input the V/2 RESET will occur on every field. This applies to both odd-field only and even-field only video sources."

Originally Posted by Toni Wilen

Perhaps some models (Commodore only?) had this "feature"? I have used some 3rd party genlocks and I don't remember anything weird happening.

If you still have access to a genlock, hook it up to an Amiga and apply an interlaced video signal to its input (e.g. from a DVD player or whatever). Then you should be able to write a test program to check the CIA TOD clock rates.

[Toni Wilen]

Originally Posted by mark_k

It wouldn't make vblank-synced programs run at half speed, since the vertical blank interrupt is generated by the custom chips independent of the fact that the HSYNC and VSYNC pins on Agnus are used as inputs when a genlock is connected.

Says who? That can't be correct, at least without more proof

Sync signals are either generated by Agnus or by genlock, not both and everything is synced to genlock when genlock is active. Whole system hangs if genlock mode is enabled without sync signals coming from genlock.

ROM graphics.library routine also checks genlock by enabling genlock mode and then checking if vertical line (VPOS) counter stops. (Which is source for vblank strobe which Paula sees and generates vblank interrupt)

[mark_k]

It's correct that video sync signals are generated either by Agnus or by the genlock. When generated by Agnus they are output on the VSYNC and HSYNC Agnus pins which connect directly to the 23-pin video output connector.

When sync is being generated by the genlock however, the genlock itself generates horizontal and vertical video sync signals. Or more accurately, it basically passes through sync signals extracted from the incoming video source to the genlock video output. The genlock doesn't send those sync signals to the Amiga. Instead it sends horizontal and vertical reset pulses to Agnus on the HSYNC and VSYNC pins of the Amiga video connector. So in that case what's input to the Agnus HSYNC and VSYNC pins aren't normal video sync signals, just half-line-rate or half-field-rate pulses. When the ERSY bplcon0 bit is set, Agnus uses those reset pulses to synchronise the Amiga video signal with the genlock video source. If you're able to hook up a genlock to your logic analyser-enhanced Amiga, check what's on the Agnus HSYNC and VSYNC pins when there is interlaced video input to the genlock.

Basically, when Agnus is synced to the genlock video, you'll get vertical blank interrupts corresponding to the field rate of the genlock video source. But on A500/600/1200 the CIA-A TOD will be half that rate if the genlock video is interlaced (as all "proper" video signals will be).

I took a quick look at the genlock-detection code in Kickstart 40.70. It seems to do this:

• Loop calling VBeamPos (reads vposr/vhposr, returns vertical beam position) until position is between 20 and 160.
• Write $0102 to bplcon0 (set GAUD and ERSY bits).
• Read vhposr 373 times. Read vhposr again. If the horizontal positions of the last two values read differ, then genlock is present. Set GfxBase->gb_system_bplcon0 to $302 (COLOR+GAUD+ERSY).
• If the horizontal beam position isn't counting, set GfxBase->gb_system_bplcon0 to $200 (COLOR). Check whether CIAA TOD is counting. If it is, set TODA_SAFE bit in GfxBase->DisplayFlags. So in the usual case of no genlock connected, TODA_SAFE is set if CIAA TOD counts independently of vertical sync. So that bit should be set for A1000, A2000, A3000 but not for A500/600/1200.

Regarding the VSYNC/power supply CIA-A tick source: It seems all big-box Amigas use the power supply tick by default. A2000 and A3000 can be jumpered to use VSYNC instead. Probably the A4000 can too but I don't have schematics for that. All-in-one Amigas (500/600/1200) can only use VSYNC.

Update: The CDTV, A4000 and A4000T have VSYNC connected to CIA-A tick pin. I guess Commodore went with PC-style power supplies for the A4000(T); no tick signal from the PSU explains why VSYNC is used instead.

[mark_k]

Toni, some evidence for you that the Amiga timer.device supports 25Hz/30Hz CIA-A TOD as would be the case on an A500 with genlock connected...

Take a look at this code from timer.device in Kickstart 40.70. This is where it calculates the CIA-A TOD rate. The result gets put in ExecBase PowerSupplyFrequency. It counts timer B down from $FFFF for the period between CIA-A TOD counts. Timer B frequency is 0.709379MHz for PAL machines. The threshold values used are

$CCFC < val		60Hz, 16667us
$B5DA <= val < $CCFC	50Hz, 20000us
$99F8 <= val < $B5DA	30Hz, 33333us
val < $99F8		25Hz, 40000us

Get_CIAA_TOD_freq
	LEA	(_ciaa).L,A0
	LEA	(_ciaa).L,A1
	BCLR	#CIACRBB_ALARM,(ciacrb,A1)
	MOVE.B	#0,(ciatodhi,A1)
	MOVE.B	#0,(ciatodmid,A1)
	MOVE.B	#0,(ciatodlow,A1)
	MOVE.B	#CIACRBF_RUNMODE,(ciacrb,A0)
	MOVE.B	#$FF,(ciatblo,A0)
	MOVE.B	#$FF,(ciatbhi,A0)
	MOVE.B	(ciatodlow,A1),D0

.Wait_TOD_change
	TST.B	(ciatbhi,A0)
	BEQ.B	__Alert_Timer	;Alert() if timer B reaches 0

	CMP.B	(ciatodlow,A1),D0	;Wait until TOD low changes
	BEQ.B	.Wait_TOD_change

	MOVE.B	#(CIACRBF_START|CIACRBF_RUNMODE|CIACRBF_LOAD),(ciacrb,A0)	;Start timer B counting down
	MOVE.B	(ciatodlow,A1),D0

.Wait_TOD_change2
	TST.B	(ciatbhi,A0)
	BEQ.B	__Alert_Timer

	CMP.B	(ciatodlow,A1),D0
	BEQ.B	.Wait_TOD_change2

	MOVE.B	#CIACRBF_RUNMODE,(ciacrb,A0)	;One-shot mode
	MOVEQ	#0,D0
	MOVE.B	(ciatbhi,A0),D0
	LSL.L	#8,D0
	MOVE.B	(ciatblo,A0),D0

; So counted-down timer B value is in D0
	CMP.W	#$CCFC,D0
	BLO.B	.Not60

	MOVE.W	#60,D0
	MOVE.W	#16667,D1
	BRA.B	SetValsAndReturn

.Not60	CMP.W	#$B5DA,D0
	BLO.B	.Not50

	MOVE.W	#50,D0
	MOVE.W	#20000,D1
	BRA.B	SetValsAndReturn

.Not50	CMP.W	#$99F8,D0
	BLO.B	.Not30

	MOVE.W	#30,D0
	MOVE.W	#33333,D1
	BRA.B	SetValsAndReturn

.Not30	MOVE.W	#25,D0
	MOVE.W	#40000,D1

SetValsAndReturn
	MOVE.W	D0,($28,A2)
	MOVE.W	D1,($2A,A2)
	RTS

[Toni Wilen]

Good enough proof

I guess genlock "half-rate" must have something to do with odd/even field toggling and every-frame sync would cause some side-effects?

Perhaps it is needed to sync both agnus and genlock inputs to same field types? (long or short) and to force non-laced long only field to become short/long toggling? (To match genlock input which is of course always interlaced)

I can't test, don't have genlock.

[mark_k]

Yes I think that's pretty much it. The half-rate VSYNC pulses would be to make the Amiga output long/short fields corresponding to long/short genlock video fields. (I wonder whether the VPOSW LOF bit has any effect in that case?)

As for the half-rate HSYNC pulses (CIA-B TICK)... perhaps that's to do with the NTSC long/short lines thing???

[Toni Wilen]

half-rate HSYNC really needs real genlock test because it is possible this behavior is NTSC only.

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip now does half TOD stuff if "genlock connected" is set. (Vsync if vblank timing, hsync always)

[mark_k]

Here's a little test program for HSYNC/CIA-B TOD. If you can find someone with an NTSC Amiga and NTSC genlock, and someone else with a PAL Amiga and PAL genlock to test it, that could solve the "mystery". (Screenshots taken using the winuae.zip you just uploaded.)

Edit: since the test sets COLOR00 which may be transparent (i.e. the genlock video shows through wherever colour 0 is), the user would need to set their genlock to "Amiga only" video mode. A less hastily cobbled-together test might fill the screen with another colour and change that palette register instead.

I've attached another disk image which boots to an interlaced Workbench; that may or may not be preferable/easier to use with a genlock.

Edit 2: Do you know any programs which use the CIA-B TOD registers?

[mark_k]

Here's a slightly updated version of the test program. This time it waits for three changes of CIABTODLO before changing background colour. So the stripes should be 3 or 6 scanlines high.

[mark_k]

Originally Posted by mark_k

Edit 2: Do you know any programs which use the CIA-B TOD registers?

Answering my own question partly... graphics.library uses the CIA-B TOD for things like QBSBlit(), which gets used by Workbench uses it when you drag icons. So generally the graphics Gels system probably uses it. I'll take a look at the code and see if there's anything to suggest graphics.library knows about the TOD running at half-rate. See this Usenet thread from 1995.

[mark_k]

Regarding the half-rate CIA-B TOD tick with genlock, here's a "smoking gun" from the graphics.library blitter interrupt code.

There could be a noticeable difference between how the current non-beta WinUAE works with genlock connected option checked, and a real Amiga (with or without genlock). It could show up if you drag several icons around the screen on Workbench. There might be more tearing in WinUAE than on a real Amiga since graphics.library isn't waiting for the correct beam position. Probably easier to notice any difference if you use a disk which has very large icons. (Are there any test/demo programs which use QBSBlit() a lot???)

The important bit happens near the .WaitForBeamPos label.

BltSrv_Code	MOVE.W	#INTF_BLIT,(intreq,A0)
		MOVE.L	(gb_blthd,A1),D0
		BEQ.B	JustRTS

		BTST	#1,(gb_Flags+1,A1)
		BEQ.B	JustRTS

		MOVEA.L	A1,A6
		MOVEA.L	D0,A1
		TST.B	(dmaconr,A0)
lbC02F2F8	BTST	#6,(dmaconr,A0)	;BBUSY-8	
		BEQ.B	lbC02F318

		TST.B	(_ciaa).L
		TST.B	(_ciaa).L
		MOVE.W	(intreqr,A0),D0
		AND.W	#INTF_VERTB,D0
		BEQ.B	lbC02F2F8

		BRA.B	lbC02F2C2

lbC02F318	TST.B	(dmaconr,A0)
		BCLR	#7,(gb_Flags+1,A6)
		BNE.B	lbC02F34A

		MOVE.W	(bn_beamsync,A1),D0
		BPL.B	lbC02F340

		BCLR	#15,D0
		MOVE.W	D0,(bn_beamsync,A1)
		MOVE.L	(vposr,A0),D1
		LSR.L	#8,D1
		AND.W	#$7FF,D1
		CMP.W	D0,D1
		BLO.B	.WaitForBeamPos

lbC02F340	MOVEA.L	(bn_function,A1),A5
		JSR	(A5)
		BRA.W	lbC02F2BA

lbC02F34A	BTST	#CLEANMEn,(bn_stat,A1)
		BEQ.B	lbC02F35C

		MOVEA.L	(bn_cleanup,A1),A5
		JSR	(A5)
		MOVEA.L	(gb_blthd,A6),A1
lbC02F35C	MOVE.L	(A1),(gb_blthd,A6)
		BNE.B	lbC02F374

		ANDI.W	#$FFFD,(gb_Flags,A6)
		MOVE.W	#INTF_BLIT,(_custom+intena).L
		JMP	(_LVODisownBlitter,A6)

lbC02F374	TST.W	(gb_BlitLock,A6)
		BEQ.B	lbC02F39A

		CLR.L	(gb_blthd,A6)
		ANDI.W	#$FFFD,(gb_Flags,A6)
		MOVE.W	#INTF_BLIT,(_custom+intena).L
		JSR	(_LVODisownBlitter,A6)
		MOVE.L	(A1),(gb_blthd,A6)
		ADDQ.W	#1,(gb_BlitLock,A6)
		RTS

lbC02F39A	MOVE.W	#(INTF_BLIT|INTF_SETCLR),(_custom+intreq).L
		RTS

.WaitForBeamPos	BTST	#1,(gb_system_bplcon0+1,A6)	;ERSY
		BEQ.B	.NoGenlock

		LSR.W	#1,D0	;CIA-B TOD counts at half rate with genlock!
.NoGenlock	LEA	(_ciab).L,A0
		MOVEA.L	A6,A1
		MOVEM.L	D0/A0/A1,-(SP)
		MOVEQ	#-1,D0
		MOVE.B	#0,(ciatodhi,A0)
		MOVE.B	D0,(ciatodmid,A0)
		MOVE.B	D0,(ciatodlow,A0)
		MOVEA.L	(gb_cia,A6),A6
		MOVEQ	#CIAICRF_ALRM,D0
		JSR	(_LVOSetICR,A6)
		MOVEM.L	(SP)+,D0/A0/A1
		BSET	#6,(gb_Flags+1,A1)
		ROR.W	#8,D0
		MOVE.B	D0,(ciatodmid,A0)
		ROL.W	#8,D0
		MOVE.B	D0,(ciatodlow,A0)
		MOVEQ	#$7F,D0
		ADDQ.L	#5,D0	;$84 = CIAICRF_SETCLR|CIAICRF_ALRM
		JSR	(_LVOAbleICR,A6)
		RTS

[mark_k]

You can easily see the problem when half-rate CIAB TOD is not implemented. Boot a Workbench 1.x disk. Once it loads insert the attached disk image which contains four large icons.

Open the LargeIconsTest disk icon (it will take a while to open). Drag the Xmas_scaled icon out of the window, onto the Workbench backdrop. Close the disk window.

Now drag the Xmas_scaled icon around. With WinUAE 2.5.1 and "Genlock connected" enabled the icon flickers a lot because WinUAE isn't emulating the half-rate TOD. With Genlock connected disabled the icon moves smoothly. Compare with the recent winuae.zip which includes half-rate TOD support. With that the icon moves smoothly both with and without Genlock connected.

Update: I have attached a couple of AVI files to illustrate the difference. Warning: they unpack to about 800MB each!

[Toni Wilen]

Great, I guess there is no need for real genlock tests anymore

Unfortunately ROM genlock connected test code is "bad", it assumes slow chop register accesses (one access = horizontal counter changed), fastest possible CPU mode rarely detects genlock. I am trying to implement some kind of hack to "fix" this..

Also display timing is not right, non-laced mode is still non-laced (long fields only). This isn't easy fix.

[mark_k]

I guess you could delay vhposr reads for a short while, if the value which would be returned is unchanged from the previous read? That should satisfy the ROM genlock check code. Could it adversely affect any other programs?

With interlaced video input to the genlock I assume Agnus is forced to generate alternating long/short fields corresponding to the input video. Perhaps writing to the LOF bit does nothing in that case???

I wonder what would happen when non-interlaced video is input to the genlock. Remember in that case VSYNC is pulsed every field for both all-long and all-short fields input video. And what if you try to use an interlaced Amiga mode then? Best guess, the genlock output would be non-interlaced with all Amiga fields output as long (or all as short).

[Toni Wilen]

Originally Posted by mark_k

I guess you could delay vhposr reads for a short while, if the value which would be returned is unchanged from the previous read? That should satisfy the ROM genlock check code. Could it adversely affect any other programs?

Yes, it would kill perforrmance and in fastest possible modes chipset clock cycles are accumulated slowly and only when there is enough, all cycles are mulated in single pass. Which means v/hpos counters stay the same for a long time and then suddenly get change by one or more lines.. This all just to make it as fast as possible (and to allow JIT to work because it can execute hundreds of m68k instructions in one pass)

It is easy to detect when genlock test is done (BPLCON0 = 0x0102 which is never used normally) but bypassing above cycle accumulation stuff isn't that simple.

With interlaced video input to the genlock I assume Agnus is forced to generate alternating long/short fields corresponding to the input video. Perhaps writing to the LOF bit does nothing in that case???

LOF bit still does something.

Remember that LOF bit only does two things:
1) Agnus starts vblank if vpos counter + (LOF ? 0 : 1) == maxvpos. (+LOF gets inverted now if BPLCON0 lace bit is set)
2) Agnus hsync output includes long/short field pulse stream (equalizing pulses that TV uses to detect field type) during vblank period. (I am not sure what happens if LOF is changed during this time)

2) of course can't happen in genlock mode, lines are input only

But mode still becomes interlaced because genlock forces vblank (via Agnus vsync input) maxvpos - 1 every other line.

I wonder what would happen when non-interlaced video is input to the genlock. Remember in that case VSYNC is pulsed every field for both all-long and all-short fields input video. And what if you try to use an interlaced Amiga mode then? Best guess, the genlock output would be non-interlaced with all Amiga fields output as long (or all as short).

I don't think this is officially supported = I don't really care.

[mark_k]

I took pictures of some pages of the A1300 genlock service manual. Maybe the timing diagrams in particular could be of some help.

[Toni Wilen]

Thanks.

So it is as simple as:

hsync: every other line, not synced to NTSC long or short lines.
vsync: if genlock is connected to interlaced signal: long fields only, if non-interlaced: both fields.

Emulation still needs to handle genlock forced odd/even toggle in non-interlaced modes before timing is exactly right.

Also technically timing shouldn't be exactly right because genlock source was usually VHS video cassette