Boosting STFM: 16MHz bus, 64MHz Shifter

[exxos]

@exxos - do I remember correctly that you had issues with counterfeit GALs that weren't performing at the indicated speed? The 20V8-10 I'm using has a much whiter print than the 16V8-25 (both Lattice) and it would explain things if it isn't a true 10ns

Yeah I've seen all sorts. Just do a A=B equation and just use the gal as a buffer.. Use your scope to measure the skew between in and out, then you get a better idea of the true delays.

[troed]

... some 33 Ohm series resistors later. Getting there

gal_series_resistors.jpg (120.34 KiB) Viewed 4138 times

[exxos]

[troed]

Moved from a wired prototype board to something a bit more stable, shortened wires and thought a bit about placement. Rewrote the GAL code to make the clocks sync up as they did when I had the F161 version of this working fine.

Not fully stable, but currently no dampening resistors either. It seems the LA needs to be hooked up to at least the GLUE clock for it to boot though, so still some work to be done

Floppy still not working. Actually, since it stopped working suddenly with the F161 where it previously had worked fine maybe I need to start to debug that at the WD1772 rather than assuming the "booster" will fix it ...

gal_prototype3.jpg (242.17 KiB) Viewed 4088 times

gal_prototype1.jpg (115.28 KiB) Viewed 4088 times

gal_prototype2.jpg (71.24 KiB) Viewed 4088 times

Haven't routed DE through the GAL yet, although the code is there, so the third mode with 16MHz bus but normal video is not tested yet.

/Troed

[troed]

... and the clocks for the two modes above, according to the LA, for MMU, CPU and GLUE. Note, I capture Shifter _output_ (divided by the Shifter from the input I give it) since I want to know the skew from what the Shifter would give the MMU and what I give it ...

gal_prototype4.png (71 KiB) Viewed 4087 times

gal_prototype5.png (67.21 KiB) Viewed 4087 times

[exxos]

It might be worth trying the 64mhz into the GAL and bypassing the clocks generated by the shifter & MMU totally ? At least then you will have a clock gen which is as good as can be and things will be in sync (hopefully) better. IIRC the shifter and MMU clocks have a pretty slow rise and fall time, and at 16mhz+ speeds, it adds up the skew delays. At least with the GAL, they are must faster so should be more stable.

[troed]

It might be worth trying the 64mhz into the GAL and bypassing the clocks generated by the shifter & MMU totally ? At least then you will have a clock gen which is as good as can be and things will be in sync (hopefully) better. IIRC the shifter and MMU clocks have a pretty slow rise and fall time, and at 16mhz+ speeds, it adds up the skew delays. At least with the GAL, they are must faster so should be more stable.

Right, so, I'm using the GAL to generate MMU, CPU, GLUE and MFP clocks (and pass through the GAL clock to Shifter). In the three modes:

1) 64.000MHz oscillator into the GAL, giving 64 to Shifter, 32 to MMU, 16 to CPU and 8 to GLUE, 4 to MFP
2) 64.000MHz oscillator into the GAL, giving 32 to Shifter, 32 to MMU, 16 to CPU and 8 to GLUE, 4 to MFP. DE ANDed with (also generated by the GAL) 2 MHz.
3) 32.08MHz original ST oscillator into the GAL, giving 32 to Shifter, 16 to MMU, 8 to CPU and 8 to GLUE, 4 to MFP.

So I'm very happy to see both mode 1 and 3 working at the moment (although unstable, sometimes it doesn't boot etc) since that means I have both the code paths working as they should through the GAL

(The reason I'm not syncing up the clocks, if you look at the LA, is that that doesn't work. I'm "emulating" the skew that ST originally has)

/Troed

[exxos]

Cool,

Just a small note though.. the ST clocks don't actually have any skew at all. That was another AF argument I had with ijor He did agree with me in the end that there was no delays though, so at least that was something.

IIRC one clock is inverted from the 8mhz, can't remember if it was the 32mhz or 16mhz one though.. did write it down *somewhere* in my booster thread I think. Even so , they are in sync on the falling edges of the clocks perfectly.

Its best to check timings like that on a scope as we are looking at very small delays in 10ns or less. You want to aim for the clocks to all be in sync, obviously Atari did the impossible and got them all in sync, even with our GAL's we are still subject to 7ns skew somewhere. But as the rise and fall times of the MMU clocks are slow anyway, it looks like skew when it actually isn't.. so overall, 7ns delays in the GAL logic pretty much evens it all out.

I've seen similar, if you have just 5ns delay on the 8MHz clock from the CPU to GLUE for example, then the floppy drive tends to screw up, and sometimes the video shifts a few pixels to the right.

Good progress in any case

[troed]

IIRC one clock is inverted from the 8mhz, can't remember if it was the 32mhz or 16mhz one though.. did write it down *somewhere* in my booster thread I think. Even so , they are in sync on the falling edges of the clocks perfectly.

Alright, I trust your research on this so I'll figure out which one is inverted and re-do the GAL code to sync on the falling edge I have a hunch it's the MMU. If you recall, when I used the F161 I only got 100% memory speed until I skewed CPU and GLUE - but that might just have covered up for something related to the MMU instead ...

Good progress in any case

Thanks Adding 33 Ohm series resistors to all the clock lines has made it almost completely stable now. However, I managed to confuse myself immensely over the last two hours ...

I searched for a nice place between the GLUE and MMU to sever DE, and found a nice via and trace somewhere above and to the right of the GLUE. Cut the trace, measured, cut, measured, CUT & measured ... and no matter how deep I cut there was still continuity between the MMU DE and GLUE DE. I also measured to the Shifter DE and it had as well.

At the same time, the computer stopped booting, just showing a "blank" screen (but with borders). I checked the schematics and sure, besides connecting GLUE, MMU and Shifter the schematics show an outgoing symbol for DE as well, but I can't see where it's an input anywhere in the schematics. Also, I don't recall DE is used for anything else ...

... so, I scraped the trace and repaired my cut - and then it started booting again. Removed the repair and it didn't ...

I'll hunt down another place to cut DE, but this has me mystified at the moment ...

/Troed

[exxos]

If you recall, when I used the F161 I only got 100% memory boost until I skewed CPU and GLUE - but that might just have covered up for something related to the MMU instead ...

Yeah mostly likely. Inverting the CPU clock for example will re-sync DTACK mostly, so the CPU sees DTACK much later than it should.. in some cases it can make a system work, or slower, or make up run vastly unstable faster It can run like that, but its not really fixing the cause of the issue. Though you have to go pretty far down the rabbit hole to get to that stuff

So "fixing" the clocks will likely break the thing totally.. but at that point you should be able to diagnose the actual issue.. In which case run DTACK via the GAL and just see if the GAL delay itself will bring it back to life..

I don't recall DE is used for anything else ...

I think it just goes from GLUE to MMU & SHIFTER. So probably cutting the track closer to the GLUE might help ?