On 11/06/2017 08:47 PM, silverdr@wfmh.org.pl wrote: > >> On 2017-11-06, at 20:26, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >> >>>> The 8371 and 8372 seem to do this internally, but the question is, is it more than this simple circuit? >>> How does it switch to accept the pulses then? Again - I haven't checked the schematics (don't even remember the pinout) so if you have one at hand and it's on the same pins, then there must be something telling it to run those pins as inputs. Might be done via internal DDR though. >> >> What pulses? Making hsync and vsync inputs instead of outputs? It's done via software (*). XCLKEN only switches the clock signal from internal crystal to external input, nothing more. >> >> (*) Should be Bit 1 in BPLCON0 Register at $dff100 > > That's the internal DDR I thought needed to exist if XCLKEN doesn't affect the sync pins data direction. > > Now the good question - it's been ages ago, but... I /think/ I didn't have to run any software in order to genlock the machine. Would that mean that we (both smf and me) were wrong about how the genlocking was done? Or is there a way to detect _XCLKEN state via software and the rest is done by KS? I see XCLKEN go only to the 74F258 on the A500+ schematics. And if you think about it, you don't really need external resync, you can use hsync and vsync in output state to sync up with the source by varying the clock supplied to the system until everything matches. Kind of a PLL. Gerrit Message was sent through the cbm-hackers mailing listReceived on 2017-11-06 21:00:02
Archive generated by hypermail 2.2.0.