Boosting STFM: 16MHz bus, 64MHz Shifter

[troed]

I never checked the sync of the 161, looks to clock on the rising edge and says rising in the pdf after a quick look, your LA seem to clock on the 32mhz HI, so would seem to be all correct I think , glad it proved it could work though! I can add that into the next booster logic now I know it works

So, back to this. Yes, the LA shows the 16MHz (first output of the 161) going hi at the same time as MMU 32MHz, however, the second and third outputs of the 161 are not synced to the rising but the falling edge of 16MHz. So, 8MHz never goes hi when 16 does but is always a half 16Mhz cycle behind. The same goes for 4MHz but there I don't think it makes much difference.

I'll think about what signals to study to try to figure out why RAM access is slowed down. If DTACK is done just slightly early then I guess it would cause a halving of throughput.

new_clocks.png (138.53 KiB) Viewed 7050 times

"A buffered clock (CLK) input triggers the four flip-flops on the rising (positive-going) edge of CLK."
- SN17F161A: http://www.tij.co.jp/jp/lit/ds/sdfs056b/sdfs056b.pdf

But looking at their state diagram:

Screen Shot 2017-10-12 at 13.03.10.png (187.28 KiB) Viewed 7050 times

... it looks as mine, synced on the falling edge of QA.

FWIW - the way I wired it up is as follows:

• A-D (inputs) to GND
• ENT and ENP to VCC
• CLR and LOAD to VCC

(One way of fixing this might be to feed the 161 with 64MHz and use its 32/16/8/4 - but I'm wary of changing the relationship between Shifter and MMU in any way)

/Troed

[exxos]

When the 32 MHz clock goes high, it changes state the slower clock speeds also. So the output is change on the rising edge the 32 MHz input clock.

One small thought is that I think the clock signal is inverted through the shifter, I am not 100% sure, I cannot remember, but I'm sure the shifter inverts the 16MHz signal.

I don't know if you still are inverting the 32 MHz (was 16mhz from shifter) to the MMU or not ? But you could try inverting just that clock to the MMU and see if that helps.

As you say, timeslots between video and RAM access except should really matter with speed, but it might be worth doing the DE mod to bring back the proper resolutions and then just try again. Really distorted the beginning and make sure that this isnt the problem before thinking and looking into other things.

There one thing to doublecheck, is that you do actually have 32MHz in the input of the MMU... Looking at your LA result, 32mhz is double the CPU speeds, so 16mhz x2 is 32mhz.. but worth double checking you are on the right pin on the MMU.

[exxos]

Tests run with the latest GEMbench 6 - it's great to see programs not checking video mode ("low") but the fact that the resolution (640*200 - although there seems to be an off-by-one error in the detection) is good enough to run

I'm still sure RAM should be 200% once everything has been tuned correctly, but it's great to see the increased color depth doesn't have a huge impact on performance. A booster that includes these video modes will probably make 640x200x16 the most popular mode I think.

I am still puzzling over these figures.. Even with ram access at 100% you should really be seeing something more along the lines of the V2 booster speeds..



With ROM access at 179% display performance should be a lot higher. I'm actually assuming here the slowdown is due to 16 colours.

I think we really need to backtrack into benchmarking proper medium resolution and see what the figures turn out like then.. We clearly have a huge slowdown with all tests somewhere, and of course no speed jump in ram access speed. This all has to be related to the extended resolution as a lot of the benchmark figures make no sense at all.

Of course integer division and ROM access are correct, even so we should be seeing 50% increase in display performance easily with the CPU and RAM running at 16MHz....

[troed]

With ROM access at 179% display performance should be a lot higher. I'm actually assuming here the slowdown is due to 16 colours.

Yeah, GEM graphics definitely takes more CPU in four bitplanes than two. I ran the same Gembench test in medium resolution (1280x200 ) for a more proper comparison:

IMG_20171012_213439.jpg (951.27 KiB) Viewed 7028 times

/Troed

[exxos]

definitely takes more CPU in four bitplanes than two. I ran the same Gembench test in medium resolution (1280x200 ) for a more proper comparison:

looks much better, other than RAM access

At some point, we can mix 32mhz CPU in there and 32MHz ROM for even faster speeds

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

Anyway, as you can see from these pictures, when there are alternating white/black horisontal lines the Shifter "flickers" a few pixels (four? it's discreet anyway) back'n'forth, a sort of "dot crawl" but shifting the content. On more regular single color backgrounds the graphics is stable.

This is a bit of a bummer. 640x200 in 16 colors is really nice - but 1280x400 is a lot nicer than I initially thought. I didn't know GEM started showing three columns of informations etc - but it does. It also feels like the old medium with elongated icons etc (the new "medium" in 1280x200 is however a joke with the standard icons and fonts). So, this issue I was a bit sad to see. The Shifter isn't warm to the touch or anything, I just think it's just too borderline at 64MHz.

IMG_20171012_233449.jpg (834.52 KiB) Viewed 7016 times

IMG_20171012_233620.jpg (1.54 MiB) Viewed 7016 times

[exxos]

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.

Doesn't the shifter actually run at 64mhz when in monochrome mode ? you could try a IMP shifter if you have one...

Would assume even though it works with some over clocking, its internals can't cope with the overclock with monochrome..

..or could be the transistor driver needs speeding up Q6... ?

Question is, is it the shifter tripping up, or the "Drive" for the mono line... likely the shifter, but IMP normally run faster (I think ).

Maybe scope the shifter mono output vs the transistor output when the machine is "cold" and see what you get, then look at it again when its acting up.. see if you can spot something.. then again you need a fast scope for that

Try a different shifter

[exxos]

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 ?

[troed]

So, back to this. Yes, the LA shows the 16MHz (first output of the 161) going hi at the same time as MMU 32MHz, however, the second and third outputs of the 161 are not synced to the rising but the falling edge of 16MHz. So, 8MHz never goes hi when 16 does but is always a half 16Mhz cycle behind. The same goes for 4MHz but there I don't think it makes much difference.

So I kept thinking about this. I do believe while it's nice that 16, 8 and 4 MHz all go HI when 32MHz (MMU) does - it's probably not proper sync to have 8MHz and 4MHz (well, I guess only 8MHz matters) go hi only on the falling edge of the 16MHz (CPU) pulses. I.e, GLUE and CPU are not in sync, IMHO.

I've thought about how I could invert (with as low delay as possible) or chain a few delays so that the 16MHz clock came "in sync" with the others - but before doing that I figured I could just take the 16MHz from the MMU instead of from the F161. The floppy problems I had were surely because of some downstream issue with the 8MHz and hadn't anything to do with the CPU clock.

... and what do you know:

IMG_20171013_204109.jpg (1.19 MiB) Viewed 6979 times

IMG_20171013_204749.jpg (1.01 MiB) Viewed 6979 times

/Troed

[exxos]

All the clocks should be in sync on a stock machine. Though I think the shifter inverters the 16mhz output. This will mean the MMU is actually out of sync with the shifter clock, and so will the CPU clock etc down the line.

All this won't be a problem when its all routed though a PLD

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

You really need to add a blitter now