exxos's Atari, Amiga & retro forum

It seems the MMU never gets WS3&4. Normally it would be 1,2,3,4, but on suska MMU it seems to be like x,x,1,2 like something is out of phase slightly..

Best I got so for is WS4 with video really messed up :)

Been playing around with the code all day again :roll: Really I have only found multiple ways of breaking thing :( Still don't really get what the actual wait state problem is or how to solve it. Mostly it seems to start in WS1, sometimes WS2, most often WS ?.. Though just resetting the MMU changes the states not a actual power on/off... So I don't get whats changing as I would assume it would start up in the same state each time...

I was talking to Icky earlier about just pushing on with the GLUE core not making a combined board to fit the H4 as planned a few months ago. Then people who know actually how to code in FPGA and able to add in such fixes can do so on the development board for the H4.

Does a normal Atari go into WS? ? This shouldn't happen?

DoG wrote: 21 Feb 2020 19:06 Does a normal Atari go into WS? ? This shouldn't happen?

Not seen a proper MMU go into WS ? no... According to the code it shouldn't happen, but I don't know why.

Got a little bit distracted over in this thread talking about wait states...

https://www.exxosforum.co.uk/forum/viewt ... =50&t=2552

I'm not making much progress, though I have managed to build a "wake state nudger" :lol:

Its interesting in suska code there is a "reset" for the shifter as well as the MMU using other signals.

@Icky I will send you the pof when I get home tonight.. then you can keep pressing reset until you get about 164ns delay between LOAD and DE (WS2) and see if closure runs...

I have tried just resetting the MMU, CPU and both, but it doesn't really make any odds to WS.. I also have timed loads of things to the 8MHz clock and while I think it may reduce the "randomness" of the WS numbers, it still seems to more like have 8 states than 4.

What does seem to happen is there seems to be 2 sets of wakeupstates , I assume in the GLUE. As multiple power on/offs either get WS1,WS2, or WS? constantly. It looks like the MMU is creating the 2 different WS numbers. So while the random aspect is likely the GLUE, I still can't figure out how the MMU is ending up with such random timings when everything is (AFAIK) reset on power up and a manual button.

I can get it into WS2 when its 344ns between LOAD and DE.


Now it gets past the WS check in Closure but gets to a pink (well looks more like salmon) screen and hangs. @troed - any idea where this may be hanging in the demo that may give us a clue to the next place to start looking in the MMU?

Icky wrote: 26 Feb 2020 23:14 I can get it into WS2 when its 344ns between LOAD and DE.

Its odd in itself.. Last week 168ns gave WS2.. Today 256ns gave WS2... Now you get 344ns...it could be the GLUE causing that variation..

I did manage to get the same delay every reset, but the machine doesn't boot then :roll:

I think we should try the suska GLUE with a proper MMU and study from that angle for a while. Once working, try both suska GLUE MMU and see what happens. See if the random timings stop.

I also wonder if the reset code is for suska only and not to reset the proper MMU etc as removing the code doesn't change anything.

At this point I can only think the GLUE is the cause for all this randomness. If we can reset them both with system reset then I would make the assumption the randomness would stop. As to if we could get it into a known wake state and run closure is another matter.

Though while the core may not work with demos like closure, I think we need to remember that the core was also to get a fixed boot up state so we can run them at double speed. At that point, timings are trashed anyway, so the timings being off is actually irrelivent as it won't run demos at double speeds anyway.

So my plan is to just get the GLUE working, then both together, if we can run GB6 then let's just jump to the H4 FPGA COMBO and work on higher speeds.

If you want to run Closure, you need a cycle exact GLUE & MMU, and I think Suska is far from that. It's not just the wake state. Btw, my opinion is to have a good MMU first, with the original Glue, because the Glue chip which is responsible for the basic timing things (horizontal/vertical counter and h/v irq generation).

Just to let people know this project is not dead :)

In fact I just came across the motherboard and hooked it up..


Pretty much a clean bill of health :)

Aside from ultimately replacing the original ST chipset (mostly MMU,GLUE,BLITTER) with modified suska cores, this opens the door to a faster than 8MHz bus speed.

The problem with overclocking the original MMU, was the wait states were just screwing up the timings up. So there was something like a 1 in 4 chance of it even booting. Fixing that problem resulted in slowdowns. Overall as I said before, I deemed it as a dead-end road project and abandoned the idea because it is simply not scalable to faster speeds. However this MMU core we can bend it to our will ;)

With some tweaks to pair it with a 16MHz CPU, we can properly crank the ST-RAM speed to 16Mhz. With some other tweaks we can even get the full 14 MB ST-RAM range running at 16MHz. This will basically render accelerators and alt-ram obsolete. Which is one of the main reasons I have not been investing a huge amount of time in accelerators lately as there is something much better around the corner anyway.

Once we have the MMU running at 16MHz bus speeds, I will design a SRAM board for the H5 and see how much of that 64MHz CPU bandwidth we can make use of with the SEC booster ;)

Ultimately we want to have a plug-in board for the H5 which is basically a combined MMU,GLUE,BLITTER. As original chips are basically unobtainable moving to FPGA cores is the only option. So we might as well update system as well. We can of course have TOS206 decoding built into it and anything else we can dream up :)

We already have a new HDMI shifter thanks to @Icky and @Smonson. Which when combined with a proper accelerated bus, opens the door to higher colour depths and resolutions without having to bodge on graphics cards etc

So I hope people can see the direction that @Icky and I are moving in with designing the H5 and SEC booster as the groundwork for a truly remarkable high-speed system.