Boosting STFM: 16MHz bus, 64MHz Shifter

Blogs & guides and tales of woo by forum members.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by troed »

Cyprian wrote: Mon Aug 13, 2018 8:53 pm awesome,

I see that fonts are 8x8 instead of 8x16 and gadgets are a bit too wide.
Maybe something else should be patched in that patched Overscan1.6,
Most certainly :) I've only edited lines and byte widths for these tests.

I propose supporting all the doubleST video modes (including this sw-only addition) in exxos' reSTFM project. If so then more time should be (needs to be) spent on the parameters.

Overscan 1.6 doesn't support TOS 2.06 for example
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by troed »

exxos wrote: Mon Aug 13, 2018 8:27 pm Now just need 256 colour version ;)
Yeah I think a nice upgrade would be to have the following new low/medium/high resolutions:

320x200x256 (15kHz, 50/60Hz)
640x200x16 (15KHz, 50/60Hz)
640x400x4 (35.5KHz, 71Hz)

The last two are now done. Let's see if we can get some aid in solving the first ;)
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by exxos »

troed wrote: Mon Aug 13, 2018 10:06 pm Yeah I think a nice upgrade would be to have the following new low/medium/high resolutions:

320x200x256 (15kHz, 50/60Hz)
640x200x16 (15KHz, 50/60Hz)
640x400x4 (35.5KHz, 71Hz)

The last two are now done. Let's see if we can get some aid in solving the first ;)
If you can get 640x400x4 with 16MHz, then what would double speed again give ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by troed »

exxos wrote: Mon Aug 13, 2018 10:12 pm If you can get 640x400x4 with 16MHz, then what would double speed again give ?
Well if we're not redoing GLUE then we're limited by doubling horisontal resolution (like the original doubleST modes did before Czietz found a way to trade horisontal for vertical resolution - but that's a one shot trick). So, 1280x400x4. That requires a replacement Shifter (the original won't do 128MHz) as well as replacement MMU (cannot imagine it doing 64MHz).
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by exxos »

troed wrote: Mon Aug 13, 2018 10:18 pm Well if we're not redoing GLUE then we're limited by doubling horizontal resolution (like the original doubleST modes did before Czietz found a way to trade horizontal for vertical resolution - but that's a one shot trick). So, 1280x400x4. That requires a replacement Shifter (the original won't do 128MHz) as well as replacement MMU (cannot imagine it doing 64MHz).
I'm thinking more new shifter with new modes... really just from a bandwidth point of view... I mean we will have 50MHz power or thereabouts.. that's gotta be able to shift some some serious data to the shifter... New MMU, new GLUE.. whatever is needed...

After that, 030 CPU, 32bit access, and double the bandwidth again ;) :twisted: :lol:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
IngoQ
Site Admin
Site Admin
Posts: 1066
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by IngoQ »

Sounds like a plan ;)
Ingo :geek:

| Atari 1040STE@32MHz | Amiga 1200 (ACA1220) | Atari 800XL (U1MB, SIDE2) | Atari 130XL (Sophia DVI) | C64 (1541 Ultimate II, Rev3 RFMod Replacement) | TI 99/4A (F18A, 32k, FlashROM 99) | Sinclair ZX Spectrum 128 (Stereo, DivMMC) | Amstrad CPC664 (512k, M4 Wifi) | ... |
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by troed »

So a while back I was given a prototype of Smonson's FPGA-Shifter. An awesome piece of tech - the picture quality of doing pure digital video is incredible.

I started out by putting it into an 520ST I have here, since that Shifter was already socketed. Worked right out the gate. I had some spontaneous resets, but didn't think much of them. I'll get back to that later. For reference, the 520ST runs off a picoPSU and has plenty of juice.

Next up was the main reason I wanted one - interfacing it into my doubleST. That Shifter wasn't socketed so I started out by extracting it - and I've then done testing back'n'forth between the FPGA and the original Shifter. This was however not as simple. I couldn't get the FPGA working at all. There's a red led on the FPGA which indicates whether it's getting VSYNCs at the correct 160256 cycle intervals or not - and it was blinking indicating it didn't.

We quickly realized that the FPGA board has its own 32MHz clock, and through the Shifter clk_out uses that to derive all other clocks as normal in an ST - replacing the motherboard crystal completely. Of course, my doubleST uses the motherboard clock for the stock mode, and its own 64MHz oscillator for the accelerated ones, and so the timing was off between the doubleST and the FPGA.

I then tried running my GAL off the clock from the FPGA, but had very little success. In the end it became obvious that the FPGA's 3.3V clock was simply not strong enough for this (even though it works to feed through the Shifter clk_out for the motherboard in the general case, apparently). So, next up was to desolder the 32MHz oscillator from the FPGA and instead feed it with 32MHz from my GAL - running everything off a single master clock. (Smonson has of course been involved the whole time and has spent many hours coding on a special FPGA firmware for my doubleST - many thanks!).

This too has been problematic. Mostly I managed to get a static image showing that the MMU was indeed latching data, the FPGA was indeed outputting stuff on the video interface, and the GLUE was indeed doing VSYNCs when it should, but nothing else.

Switching back to the original Shifter I had no problems booting the computer.

This is when I recalled that exxos had been almost surprised that in my original doubleST I hadn't needed to delay /DTACK at all. And, probing the CPU with my LA I did realize that the CPU was HALTed. So, I added a 74LS04 to my test board and started adding delays to /DTACK. And hey - now I could get the FPGA to boot. I do need to add 40-60ns, which causes visible memory read errors (MMU/Shifter - blinking pixels, every 16 pixels disturbance etc).

If I use the original Shifter with the same /DTACK delay I have similar memory read errors in the video output.

If I do _not_ delay /DTACK - original Shifter output is fine. But the FPGA doesn't boot.

... and this is where I'm at. To complicate things, when I do get the FPGA to boot the computer resets spontaneously almost constantly. I seldom get more than a few seconds out of each boot. There are no such issues with the original Shifter.

I need ideas:

1) What can cause spontaneous resets through the Shifter socket? The FPGA only has an adapter that sits there (and it additionally picks up VSYNC) - and that's it.
2) What can the FPGA Shifter do, compared to the original Shifter, that creates a need for me to delay /DTACK? In both cases my GAL creates all clocks.

/Troed

*) Clocks are: 32MHz Shifter inverted compared to the 32MHz MMU. CPU/GLUE/MFP are all synced to the falling edge with the MMU clock. They all have 33 Ohm resistors on the GAL output. Short wires to MMU, CPU, MFP. Longer wire to the FPGA/Shifter.

*) The PSU is recapped, and the motherboard cap is beefed up as well. I'd be surprised if there were power issues. Running it at 5.1V (helps with overclocking original Shifter)
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by exxos »

How exactly have you added the dtack delay into it.. I assume you have lifted the CPU pin and added the delay there,,,

8mhz with delayed dtack will likely cause issues...

Its probably better to use a flipflop delay clocked from the CPU clock. This way you can add a jumper wire for no delays or 1 or 2 CPU clock delays to CPU dtack.

But even so, as the MMU is running faster then as long as the ram can keep up, then it shouldn't need any delays I think...

But in the mix is all the bus grant stuff as well.. Glue doesn't like the CPU doing that stuff faster... Delaying dtack is slowing the CPU down and will likely cause bus grant to be slower... These problems get pretty complicated to track down... But you should probably add a delay from CPU BG pin to the MB ..

ROM is another problem.. While it can run faster .. Glue is still running at 8mhz with ROM decoding, its possible the CPU is re-reading the slower glue dtack line... So delays on dtack then make sense.. I had huge trouble with that stuff..

I would say start with delaying dtack only on ROM access.. The MMU I assume will be fine to run without delays... I had to do my booster code with various delay lengths depending on what was being accessed...

As to why you only get problem with the FPGA.. No idea really.. Could be bus loading issues... 2.2k sil pull ups normally solve that.. The shifter is pretty much a slave to the MMU.. So can't really see it being anything else..
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by Smonson »

exxos wrote: Wed Aug 29, 2018 11:34 pm As to why you only get problem with the FPGA.. No idea really.. Could be bus loading issues... 2.2k sil pull ups normally solve that.. The shifter is pretty much a slave to the MMU.. So can't really see it being anything else..
The FPGA is interfaced to the data bus (off the shifter socket) through a bidirectional transceiver which drives the bus whenever /CS and R are asserted - through current-limiting resistors which I think are 3K ohms on Troed's board from memory. Then, also buffered a second time by the shifter's original bus transceivers that are on the ST board.

The address bus just goes through normal one-way level-shifting buffers, no limiting resistors.

The machine should boot up and output stable video with all the data and address lines disconnected, though - probably an experiment worth doing to rule out the possibility.

I've never had a crash or a spontaneous reboot on my machine with the FPGA shifter, but I only have one ST, so maybe I'm just lucky. I'm interested to know how you go, Exxos (especially on a normal-speed machine).
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Boosting STFM: 16MHz bus, 64MHz Shifter

Post by troed »

exxos wrote: Wed Aug 29, 2018 11:34 pm How exactly have you added the dtack delay into it.. I assume you have lifted the CPU pin and added the delay there,,,
Yes :)
8mhz with delayed dtack will likely cause issues...
Yeah for now I only run at 16MHz all the time. Exact same code for both original Shifter and FPGA-Shifter.
Its probably better to use a flipflop delay clocked from the CPU clock. This way you can add a jumper wire for no delays or 1 or 2 CPU clock delays to CPU dtack.
Ok.
I would say start with delaying dtack only on ROM access.. The MMU I assume will be fine to run without delays... I had to do my booster code with various delay lengths depending on what was being accessed...
Yeah .. that's outside of what the GAL can do, would need to redo it on a much bigger CPLD.
As to why you only get problem with the FPGA.. No idea really.. Could be bus loading issues... 2.2k sil pull ups normally solve that.. The shifter is pretty much a slave to the MMU.. So can't really see it being anything else..
I've added 2.2k SIL to both address and data busses on this machine so I should be at 1.8 in total I think. I agree that I can't see either why the FPGA Shifter is affecting the need for /DTACK delay - thus my confusing post about it asking for ideas :D

The spontaneous reset issue is even weirder. I can't see any sane reasons for how the Shifter is able to cause the computer to reset. Will LA a more complete set of CPU pins to see if I can figure something out.
Locked

Return to “MEMBER BLOGS”