20 December 2012, 23:03 | #1 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
CIA-A TOD clock source with genlock
The A500/A2000 Technical Reference Manual mentions (on page 9):
Quote:
|
|
21 December 2012, 08:31 | #2 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
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. |
22 December 2012, 18:09 | #3 | ||
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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:
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): Quote:
Quote:
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. Last edited by mark_k; 22 December 2012 at 18:30. |
||
22 December 2012, 18:28 | #4 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
Quote:
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) |
|
22 December 2012, 20:24 | #5 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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:
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. Last edited by mark_k; 22 December 2012 at 23:09. |
26 December 2012, 16:39 | #6 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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 Code:
$CCFC < val 60Hz, 16667us $B5DA <= val < $CCFC 50Hz, 20000us $99F8 <= val < $B5DA 30Hz, 33333us val < $99F8 25Hz, 40000us Code:
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 Last edited by mark_k; 26 December 2012 at 16:50. |
26 December 2012, 17:05 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
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. |
26 December 2012, 17:34 | #8 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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??? |
26 December 2012, 17:48 | #9 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
half-rate HSYNC really needs real genlock test because it is possible this behavior is NTSC only.
|
26 December 2012, 18:03 | #10 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
http://www.winuae.net/files/b/winuae.zip now does half TOD stuff if "genlock connected" is set. (Vsync if vblank timing, hsync always)
|
26 December 2012, 20:08 | #11 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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? Last edited by mark_k; 28 July 2014 at 12:03. |
26 December 2012, 23:39 | #12 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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.
|
27 December 2012, 13:01 | #13 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
Quote:
|
|
27 December 2012, 16:41 | #14 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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. Code:
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 |
27 December 2012, 17:44 | #15 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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! Last edited by mark_k; 27 December 2012 at 18:02. |
27 December 2012, 18:46 | #16 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
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. |
27 December 2012, 20:17 | #17 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
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). |
27 December 2012, 21:06 | #18 | |||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
Quote:
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. Quote:
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. Quote:
|
|||
31 December 2012, 15:43 | #19 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,333
|
I took pictures of some pages of the A1300 genlock service manual. Maybe the timing diagrams in particular could be of some help.
|
31 December 2012, 17:01 | #20 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
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 |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
example of a CIA timer interrupt in assembler using cia.resource | Apollo | Coders. Asm / Hardware | 3 | 05 July 2013 08:40 |
CIA chips | Yakumo9275 | support.Hardware | 3 | 23 March 2013 18:56 |
Genlock's uploads | Genlock | project.Amiga File Server | 7 | 20 August 2010 23:24 |
Genlock emulator | Leandro Jardim | request.UAE Wishlist | 24 | 04 June 2010 07:47 |
Neriki Genlock | Geepster | support.Hardware | 1 | 17 April 2005 08:55 |
|
|