Amiga stuck in genlock mode, preventing boot?

[fgh]

I remember once my old A2000 didn't boot at all when connected via RGB port, but worked fine when connected via composite.
Although I'm not 100% sure, I think I was using an RGB-scart cable.
However I've read lots of times that this will happen with non-buffered RGB-VGA adapters on big box amiga models.

But WHY?


Having read up a bit now, this is my understanding so far:

To allow a perfect sync of amiga video to external video through a genlock, Amiga computers can run its video timing off the sync of an external video source via pin 1 'external clock' and pin 2 'external clock enable' on the the DB23 video port, plus the Hsync and Vsync signals can be switched from outputs to inputs.

Graphics.library (kickstart ROM) detects a genlock by turning h+vsync to inputs (genlock mode, BPLCON0 External Resync) briefly and check if the horizontal position is changing.
If a genlock IS detected but no real sync is there, the machine will hang, waiting forever for an external sync signal.
And this is how your big box amiga hangs when attempting to use an unbuffered RGB-VGA adapter.

So, is the hsync signal just unconnected and floating then, and confusing the detection routine? Is that it?
If so, would that not explain why it could happen with an RGB cable as well? (as I think it did for me) They should only use Csync, so Hsync and Vsync are perhaps not connected and floating as well.


I'm not at all a hardware designer, so excuse me, but could this be solved simply by pulling up or down the hsync signal? Or would that mess up the sync when used as an output? (Edit: Which is still no problem for RGB-scart)

If it would be that simple I don't see a reason for people to keep making RGB-scart adapters, 23-15pin adapters, and motherboard clones with the same issue. (So I guess it's not that simple, haha!)


Thank you all for your attention!

[Daedalus]

Indeed, SCART doesn't use the HSync or VSync signals, so they shouldn't be affected at all by using an RGB-SCART cable unless it's some sort of non-standard wiring. Leaving the sync signals unconnected won't cause the machine to think there's a genlock attached; if it did, you'd never be able to use the machine using just the composite output.

Also, the circuitry is almost identical between the big-box and wedge Amigas, the chips dealing with the sync signals (Alice / Agnus) are identical and wedge Amigas can certainly detect and use a genlock, so while people always say that unbuffered big-box Amigas are more affected by this issue, I don't understand how. And in my limited experience, the only time I've seen this issue in real life is on an A1200 with an old VGA CRT attached. Adding buffers to the sync lines in that case enabled that monitor to be used. Any VGA display I've tested since has not caused issues when connected unbuffered to a big-box or wedge Amiga.

From this, my understanding of the issue is that some older displays place enough of a load on the HSync and VSync signals to drag them down and thus fooling the Amiga into waiting for the signal to rise again to sync. The display and/or cable you used with your A2000 must have presented a similar load to your A2000 to cause this issue. Pulling up the signal won't help here, because putting the sync lines in input mode already means there's most likely a pull-up applied internally.

[pandy71]

AFAIR AmigaOS activate briefly H and V sync inputs to align internal timing with external one - by forcing H and V sync inputs to one state you may perhaps solve issue but it may be more riskier due load on those lines - isn't better is just buffer those pins?

[fgh]

Thanks for your input guys!

Originally Posted by Daedalus

Leaving the sync signals unconnected won't cause the machine to think there's a genlock attached; if it did, you'd never be able to use the machine using just the composite output.

That's true, why didn't I didn't think of that

Originally Posted by Daedalus

Also, the circuitry is almost identical between the big-box and wedge Amigas, the chips dealing with the sync signals (Alice / Agnus) are identical and wedge Amigas can certainly detect and use a genlock, so while people always say that unbuffered big-box Amigas are more affected by this issue, I don't understand how. And in my limited experience, the only time I've seen this issue in real life is on an A1200 with an old VGA CRT attached. Adding buffers to the sync lines in that case enabled that monitor to be used. Any VGA display I've tested since has not caused issues when connected unbuffered to a big-box or wedge Amiga.

From this, my understanding of the issue is that some older displays place enough of a load on the HSync and VSync signals to drag them down and thus fooling the Amiga into waiting for the signal to rise again to sync. The display and/or cable you used with your A2000 must have presented a similar load to your A2000 to cause this issue. Pulling up the signal won't help here, because putting the sync lines in input mode already means there's most likely a pull-up applied internally.

Ok, thanks a lot. Interesting that it was an A1200 you had it on.

I had a quick look at amigapcb.org and I see v+hsync pins connect to 47 Ohm resistors on the 4000 and 500 vs 68 Ohm on the 1200 and 600, but on the 4000 they also connect to a 74HC4066 (Vsync, U205) and a 74FCT245 (Hsync, U458). Not sure these could explain anything. (Didn't look up 1000/2000/3000 schematics.)

Originally Posted by pandy71

AFAIR AmigaOS activate briefly H and V sync inputs to align internal timing with external one

The brief activation is to detect if there is an external sync present (Change in horizontal position). If one is detected, it enters genlock mode and it's running off the external sync directly.

Originally Posted by mark_k

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).

ERSY = External sync AKA genlock mode

Originally Posted by pandy71

by forcing H and V sync inputs to one state you may perhaps solve issue but it may be more riskier due load on those lines - isn't better is just buffer those pins?

Sure, using a buffered adapter solves the problem so it's not a big deal.

I was just curious, as it can be really confusing for people when it happens, and it's not super well known.
And as Rob confirms, I'm not sure about the claims of it not being a problem on wedge machines. Perhaps it might even happen on scart connections on some machines or monitors, or with dodgy cables.

If someone could explain it precisely, I'd mention it for the OS devs, perhaps they could improve genlock detection somehow to avoid the problem in future kickstart versions.

[pandy71]

Originally Posted by fgh

The brief activation is to detect if there is an external sync present (Change in horizontal position). If one is detected, it enters genlock mode and it's running off the external sync directly.

But OS enters to genlock mode briefly during boot - even if pulses are present ERSY it is inactive until latter activated by application. Probably such functionality is made to pre synchronize Amiga in broadcast signal flow where common timing is distributed to all participants.

Originally Posted by fgh

Sure, using a buffered adapter solves the problem so it's not a big deal.

It is also recommended for safety as HSync and VSync signals are directly feed to Agnus/Alice as such there is relatively high risk for those nowadays quite costly IC's.

Originally Posted by fgh

I was just curious, as it can be really confusing for people when it happens, and it's not super well known.
And as Rob confirms, I'm not sure about the claims of it not being a problem on wedge machines. Perhaps it might even happen on scart connections on some machines or monitors, or with dodgy cables.

I think this malfunction of sink (in this case monitor) - perhaps home noise is present. And "wedge" Amiga are exactly same as big Amiga in terms of design - some additional functionality that differentiate between "wedge" / non "wedge" may be associated with presence of internal video port slot present on all big Amiga models. So wedge is simplified where non wedge may need to prevent possibility for non working or partially working functionality where more than one genlock is present.

Originally Posted by fgh

If someone could explain it precisely, I'd mention it for the OS devs, perhaps they could improve genlock detection somehow to avoid the problem in future kickstart versions.

Technically problem is solved by fixing HW malfunction - don't think SW workarounds can be better than proper HW approach.

Issue could be probably solved at the IC design level or by more complex V and H sync I/O pins (like input sampled on one CDAC phase and output placed on other CDAC phase so you could create separate input and output but this was not necessary as genlock functionality albeit very popular in Amiga was relatively low % usage of the overall Amiga models sold).

[fgh]

Originally Posted by pandy71

But OS enters to genlock mode briefly during boot - even if pulses are present ERSY it is inactive until latter activated by application. Probably such functionality is made to pre synchronize Amiga in broadcast signal flow where common timing is distributed to all participants.

I got the clear impression from other posts (and the A1300 service manual) that the handover to external sync happens at boot, and the machine is synced to the external source from that point until next reboot.

Originally Posted by pandy71

It is also recommended for safety as HSync and VSync signals are directly feed to Agnus/Alice as such there is relatively high risk for those nowadays quite costly IC's.

Good point. I don't intend to recommend the use of unbuffered 23-15pin adapters.
However a common understanding seems to be that wedge models HAVE signal buffers, and that's why these issues are less common. So if they don't, it's nice to know their agnus/alice might need protection too.

Originally Posted by pandy71

I think this malfunction of sink (in this case monitor) - perhaps home noise is present. And "wedge" Amiga are exactly same as big Amiga in terms of design - some additional functionality that differentiate between "wedge" / non "wedge" may be associated with presence of internal video port slot present on all big Amiga models. So wedge is simplified where non wedge may need to prevent possibility for non working or partially working functionality where more than one genlock is present.

Yes, it could be those chips I mentioned are related to the video slots.
(I think it's still not possible to use more than one genlock though, IIRC Video Toaster manual says something about that (it's also a genlock))

Originally Posted by pandy71

Technically problem is solved by fixing HW malfunction - don't think SW workarounds can be better than proper HW approach.

Issue could be probably solved at the IC design level or by more complex V and H sync I/O pins (like input sampled on one CDAC phase and output placed on other CDAC phase so you could create separate input and output but this was not necessary as genlock functionality albeit very popular in Amiga was relatively low % usage of the overall Amiga models sold).

Sure, if someone knows for sure what causes this, what makes models differ, and an easy hw fix is possible, I'll mention it to the guys who design the replica boards as well. But most amiga computers are already manufactured long time ago

[pandy71]

Originally Posted by fgh

I got the clear impression from other posts (and the A1300 service manual) that the handover to external sync happens at boot, and the machine is synced to the external source from that point until next reboot.

Practically impossible to avoid drift in Amiga and TV studio - firstly if you are not activating interlace then you will have different number of lines in Amiga than in TV standard, secondly Amiga crystal drift with time and temperature don't mentioning wide tolerance in frequency so it is unavoidable to get fully synced Amiga if it is synced once only on boot stage - ERSY need to be constantly active to get synchronization between external source and Amiga video.

Originally Posted by fgh

Good point. I don't intend to recommend the use of unbuffered 23-15pin adapters.
However a common understanding seems to be that wedge models HAVE signal buffers, and that's why these issues are less common. So if they don't, it's nice to know their agnus/alice might need protection too.

I know, you discovered some misbehavior so this topic occurs.
Amiga (wedge) are not buffered for sure - IO pins are directly connected with video port so this fragile part - from A500 rev 6 schematics looks like HSYNC is pulled up to Vcc with 4.7k resistors so it is always high, both HSYNC and VSYNC are current limited by 47Ohm resistors.
On A3000 and A3000T it is opposite - HSYNC is not pulled up, on A4000 HSYNC is pulled up by 10k resistor also on A4000T it seem to be pulled up by 10k resistor. On A2000 rev 6 HSYNC is pulled up by 10k resistor.
Seem only A3000 are affected by missing pulling up resistor on HSYNC line.

Originally Posted by fgh

Yes, it could be those chips I mentioned are related to the video slots.
(I think it's still not possible to use more than one genlock though, IIRC Video Toaster manual says something about that (it's also a genlock))

If TV studio use single master clock then it should be no problem to use multiple genlocks especially if they are more intelligent.
But my point was rather to use internal video slot and also video port so some form of arbitration control over priority could be designed.

Originally Posted by fgh

Sure, if someone knows for sure what causes this, what makes models differ, and an easy hw fix is possible, I'll mention it to the guys who design the replica boards as well. But most amiga computers are already manufactured long time ago

Yep so best is to used buffered interfaces and consider everything as potential danger for Amiga - there is thread about overclocking precious MC68060 - same for Amiga custom IC's - nowadays they are no longer produced.