exxos's Atari, Amiga & retro forum

Smonson wrote: ↑Thu Aug 30, 2018 8:24 am On mine it doesn't, the crystal connects to 2 pins on the shifter to create the resonant circuit, the clean digital signal is only inside the shifter. If you measure one of the pins off the crystal, you get a low-voltage sinewave.

oh wow, never seen the 32mhz gen "missing" before, what revision board is that ?

Smonson wrote: ↑Thu Aug 30, 2018 8:24 am On mine it doesn't, the crystal connects to 2 pins on the shifter to create the resonant circuit, the clean digital signal is only inside the shifter. If you measure one of the pins off the crystal, you get a low-voltage sinewave.

I think this is unknown .. which Shifter do you have? All I know about and have seen get a proper 32.xMHz clock generated by the circuitry from outside of the Shifter. I agree the crystal itself isn't the full oscillator circuit.

XTL1 is the pin that clock goes to. I use it as a source clock in my doubleST GAL for the stock mode.

Ummm off the top of my head I couldn't tell you the board revision number - it's the one with 8 J-leaded drams underneath the power supply. Next time I have it opened up I'll try to remember to get a photo.

Troed, maybe mine does have a proper external clock and I misinterpreted what I saw. I can't remember which pin I measured to see the sinewave. For a machine with a full clock on pin 2, do you get a sinewave on pin 1?

Smonson wrote: ↑Thu Aug 30, 2018 8:54 am Troed, maybe mine does have a proper external clock and I misinterpreted what I saw. I can't remember which pin I measured to see the sinewave. For a machine with a full clock on pin 2, do you get a sinewave on pin 1?

I'll check after work. Now the 32MHz clock is known to be "weak" so I wouldn't be surprised if it's not a perfect squarewave ... I think exxos has posted scope readings off it in one or a hundred of his booster threads

(but I've had no problem running my GAL off it with a 7 cm wire. Not to say it wasn't sensitive to outside disturbances though .. it was)

32MHz gen is basically a analouge circuit , it outputs a crappy 1v p-p sine, probably with 2.5V offset as well. The shifter cleans that up and outputs 16MHz to the MMU.

You need to run the 32MHz line via a schmitt buffer. I had exactly same issues on my 40MHz STE booster. My GAL output was like 2-4V and didn't hit a logic low (rise and fall times way to slow even being like 2ns!) . The buffer thankfully solves that and gives a decent 0-5V wave for the CPU.

The very first 520ST schematic says XTL0 is grounded though.
Ah, exxos as usual knows all about it I seem to have been lucky to have been able to use the 32MHz clock as it was for my GAL.

exxos wrote: ↑Thu Aug 30, 2018 9:03 am 32MHz gen is basically a analouge circuit , it outputs a crappy 1v p-p sine, probably with 2.5V offset as well. The shifter cleans that up and outputs 16MHz to the MMU.

This definitely explains everything I've seen then - and if it's in the schematics it's pretty much guaranteed.

So, to sum up: a future revision of the HDMI board could use the original clock generator circuit by putting a buffer on the DIP socket adapter, passing the 32MHz through the ribbon cable up to the board (assuming it can survive 10cm of ribbon cable) and driving the FPGA's clock source.

Smonson wrote: ↑Thu Aug 30, 2018 9:10 am So, to sum up: a future revision of the HDMI board could use the original clock generator circuit by putting a buffer on the DIP socket adapter, passing the 32MHz through the ribbon cable up to the board (assuming it can survive 10cm of ribbon cable) and driving the FPGA's clock source.

Do you need to make one FPGA firmware per motherboard clock or are those two different things?

It would be awesome to use the stock clock for compatibility.

troed wrote: ↑Thu Aug 30, 2018 9:22 am Do you need to make one FPGA firmware per motherboard clock or are those two different things?
It would be awesome to use the stock clock for compatibility.

Nah, trivial differences like that don't cause any problem. Large clock speed differences could matter due to the fact that it's an input to a PLL, so the compiler needs to know what the clock speed coming in is in order to generate the right settings. I guess it would also overclock the HDMI dot clock slightly, so the frame rate could be as high as 71.8Hz