ST FPGA MMU Development

[Badwolf]

Looks like we have an FPGA MMU running on an H5. It's a little unstable at the moment as am just tuning it to work with the Phoenix Shifter but GEMBench runs ok. Most effort yesterday went into making the 7 Segment Display read as MMU. Its the important things :)

Great milestone!

BW

[JezC]

@Icky Excellent progress...I know the final goal is for a perfect facsimile for the original devices (so it runs all demos/games etc.) but I wonder if anyone else is more interested in a working GEM-level replacement first & then maybe the upgrade to the final 'perfect' version when that is available...

Just thinking that it's another way to help fund the ongoing development (barring the current component supply issues, of course!)... :roll:

[Icky]

@Icky Excellent progress...I know the final goal is for a perfect facsimile for the original devices (so it runs all demos/games etc.) but I wonder if anyone else is more interested in a working GEM-level replacement first & then maybe the upgrade to the final 'perfect' version when that is available...

Just thinking that it's another way to help fund the ongoing development (barring the current component supply issues, of course!)... :roll:

This is something we are looking to do. E.g. we have been discussing for example the Phoenix Shifter and Phoenix Blitter boards where for example the FPGA Blitter is at about 98% done. By releasing a batch of boards so that others can help with testing and improving that last perfection.

However exactly as you mention @JezC the current supply issue has stalled things. One silver lining is that the manufacturer we were using to get these boards made is finally sending me back all the parts I had tied up with them. If I can make around 5-10 boards and get them up and running we can release as a sort of ALPHA testing.

[JezC]

@Icky Cool...hope you receive those parts very soon.

I'd be happy to help with testing if needed...might be more heavy use with 'serious'/MIDI& music based s/w rather than games or demos...but will happily try anything where I can.

:thumbup:

[ijor]

Looks like we have an FPGA MMU running on an H5.

You can use my cores for cycle exact accuracy. With all due respect to Wolfgang, Suska cores, AFAIK, are not really accurate. I assume it just was never his goal.

But note that the wakestate doesn't depend on GLUE only. Wakestates are a product of the relation between MMU and GLUE. Unless you use a single FPGA, which obviously requires a motherboard redesign, it is very trick to fully control the wakestate.

[troed]

You can use my cores for cycle exact accuracy.

That would indeed be fantastic!

[ijor]

Troed's Closure demo fails to detect the wait states, but I have no idea why as I am not a demo coder... I can only possibly think it may be something to do with 50/60hz switching, but I really would assume all this is done by the GLUE anyway...

Wakestates depend both on GLUE and MMU. If the MMU implementation is not cycle exact, it might certainly produce invalid wakestate results.

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.

Actually, not everything is reset on hardware reset. The other factor is that reset is not synchronized.

If we can reset them both with system reset then I would make the assumption the randomness would stop.

No, it won't. Again, the whole point about wakestates is that they are not affected by hardware reset. Otherwise you could get different states each time you press the reset button. But reset doesn't change the wakestate, hence the term "wake" state.

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

All the original chipset has hardware reset. Most don't have a reset pin, yet they still have hardware reset. I believe I documented this somewhere years ago, but can't find the note right now.