Boosting STFM: 16MHz bus, 64MHz Shifter

[troed]

Fantastic to finally see a proper speed result! Would also be nice to see stock medium res benchmarks at some point I got 200% pretty much across all tests with GB3, but it wasn't a good test... Probably not far out from your second image anyway...

BTW, it seems GEMbench cannot save screenshots in "low" res ... (Greyed out)

Thinking out loud here...

Could we not re-generate the syncs and rebuild a higher vertical resolution ? We have control over DE but if we could double the vertical sync speed as well..

Maybe no reason to start the frame earlier and gain a few extra pixels in the borders as well ?

We can't do anything about GLUE and its counting of lines - but we have full control over DE. It's trivial to do the good old overscan hw mod of course, but it might be possible with some fast logic to selectively add a few lines before and after the regular screen. I think 640x240 and 1280x480 would be nice and fully doable.

It would be a slight nightmare to sync this _exactly_ to the line start and line end of the GLUE-controlled lines though.

[exxos]

BTW, it seems GEMbench cannot save screenshots in "low" res ... (Greyed out)

Yeah, GB6 does not run in low res obviously different screen detection routine there, damn my lazy coding

We can't do anything about GLUE and its counting of lines - but we have full control over DE. It's trivial to do the good old overscan hw mod of course, but it might be possible with some fast logic to selectively add a few lines before and after the regular screen. I think 640x240 and 1280x480 would be nice and fully doable.

It would be a slight nightmare to sync this _exactly_ to the line start and line end of the GLUE-controlled lines though.

What I mean is not letting the GLUE do any of the counting at all..generating new sync external to glue can be done. though I don't know if generating syncs externally would break other stuff.

[troed]

Alright, so here's the first slightly negative observation. The Shifter is indeed getting extremely stressed when in monochrome (where its internal pixel clock is the highest). I didn't see this until now, it takes a few minutes to appear and I've been mostly playing around in "low" res. Also, it's dependent on the actual graphics shown - something I've seen with regards to Shifter behaviour in my sync scroll/overscan research on regular machines as well.

After some more testing, this is indeed caused by Shifter timings being borderline. I had this, quite severe, where it then suddenly "popped" into banded state (every fifth word black, i.e, black vertical columns) where it otherwise was fine, and then it "popped" into a non-banded state again (but with wrap-around at left side) again otherwise displaying everything nicely.

So, it's not a general case of the Shifter not being able to handle the high(est) pixel clock but being down to very delicate borderline timing. This is good - might be something that can be tweakable for each installation or so.

/Troed

[exxos]

After some more testing, this is indeed caused by Shifter timings being borderline. I had this, quite severe, where it then suddenly "popped" into banded state (every fifth word black, i.e, black vertical columns) where it otherwise was fine, and then it "popped" into a non-banded state again (but with wrap-around at left side) again otherwise displaying everything nicely.

So, it's not a general case of the Shifter not being able to handle the high(est) pixel clock but being down to very delicate borderline timing. This is good - might be something that can be tweakable for each installation or so.

From my testing before, if the video was shifting 16pixels to the right and "wrapping around" it was the GLUE clock having to much delay.

Even so, random faults like this may just be noise on some signal. Its common and can get time consuming to track down. Leave all the fine tuning to me when I catch up with stuff and can get it all in my V2.6 prototype

[troed]

I just realized I don't need to guess about the difference between using the F161 16MHz clock for CPU (where memory only reached 100% speed) and using the MMU 16MHz clock (where memory access got to 200%) - I could use the LA to see what the difference is

clocks_mmu_or_f161.png (134.28 KiB) Viewed 6881 times

Surprising, actually.

[exxos]

These are my scope readings I took on a stock machine ages ago...


8MHz - 32MHz

8_32.png (4.55 KiB) Viewed 6872 times

16MHz - 32MHz

16_32.png (4.54 KiB) Viewed 6872 times

8MHz - 16MHz.

8_16.png (4.63 KiB) Viewed 6872 times

They are all perfectly in sync.

You're 161 16MHz line is out of sync with the rest of the system. I still think that is covering up a sync issue with DTACK on the rest of the system. IE delaying the clock to the CPU so it reads DTACK later.

[troed]

Hmm. So I had to steal the recapped PSU from this machine to use in an STE I sold, and now I've just recapped the one I switched out and put back.

... and floppy isn't working. Everything else looks ok. Will have to figure this out - last time this happened it was due to not using good clocks from the the F161, or so I thought at least. Apparently there's something a bit too borderline still. The "new" PSU is the latest recap-version of the SR98 with the diode and resistor mod, so I tuned 5V down from 5.25V to 5.09V, which caused 12V to end up at ~11.5V. Although I cannot believe that should make a difference ...

Will hook up the LA next. Or maybe even the scope I bought and so far haven't used

/Troed

[exxos]

Yeah 12V is normally low. There isn't any regulation on it.. long story anyway..

If the clocks look good , no ringing etc then it should be good. I still suspect sync issue on DTACK. I think you need to run DTACK to the CPU via a flipflop to re-sync it. Basically adding like 100ns or so delay to it. Its the issue I had when running CPU at 16mhz constant. Though likely the MMU isn't cause here as its running faster anyway, but GLUE likely confusing the issues with DMA access. GLUE still issues DTACK at 8mhz and the CPU running 16mhz likely a issue as I found.

You may (or not) see issue if you use diagnostic cartridge and try ROM checksum test..(do it like 100 times) Though issues don't always show up in diagnostic as sometimes it needs some combination of various bus accesses to cause the faults.

I think other than DTACK sync issues and noise on clocks, there shouldn't really be any other issues that I can think of.

[troed]

So I'm still working on this mod. I want to be able to switch between doubleST (16MHz bus, new video modes), the original stefan-mod (16MHz bus) and pure stock.

The crystals we have to play with are the new 64.000MHz and the old 32.08. Since this is not an exact multiple, to be fully compatible when in stock mode all clocks need to be derived from the 32.08.

Here's the output from my first ever GAL program (first written in eqn format, then converted to cupl to be able to simulate in wincupl). Since I made this composite image I've inverted the CPU clock though (I will measure the exact relation of the clocks in an original STFM and modify the GAL code to try to replicate them as far as I can).

The intention is to replace the F161 this way, having the GAL do all the work of switching between modes as well as generating all the clocks for the system, including ANDing DE with 2MHz in the original stefan-mode. Of course, adding a separate switch for hardware overscan becomes trivial this way as well.

A 10ns GAL is required to reach the necessary speeds (the GAL is clocked at 64MHz in both the boosted modes, a 15ns GAL is only rated for 62MHz) and so I've just ordered a few 16V8-10. Until then I have a 20V8-10 laying around that I will try with.

This "booster board" will thus just consist of a 64MHz oscillator and the GAL. Now let's see if I can get it to work outside the simulator ...

doublest_gal.png (40.59 KiB) Viewed 6509 times

(S0 and S1 are the switch signals. clk is GAL clock pin, wired directly from combinatorial SC output)

[troed]

Built this up on a test board and the GAL seems to work as indicated by the simulation, the relation between the clocks look ok. Not sure about the accuracy of the highest clocks though, my LA should capture them better than it seems to do.

Also hooked it up to the STFM, and I get "unable to display this video mode" from the screen which means GLUE is not running at 8MHz.

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

The 16V8-10 I ordered will take a few weeks to arrive, but I ordered from a "reputable" European store to minimize the risk for fakes ...