ST FPGA MMU Development

Progress on our FPGA cores.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: ST FPGA MMU Development

Post by Badwolf »

Icky wrote: Wed Mar 16, 2022 12:20 pm 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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
JezC
Posts: 2083
Joined: Mon Aug 28, 2017 11:44 pm

Re: ST FPGA MMU Development

Post by 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:
User avatar
Icky
Site Admin
Site Admin
Posts: 3986
Joined: Sun Sep 03, 2017 10:57 am
Location: UK

Re: ST FPGA MMU Development

Post by Icky »

JezC wrote: Wed Mar 16, 2022 9:46 pm @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.
User avatar
JezC
Posts: 2083
Joined: Mon Aug 28, 2017 11:44 pm

Re: ST FPGA MMU Development

Post by 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
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: ST FPGA MMU Development

Post by ijor »

Icky wrote: Wed Mar 16, 2022 12:20 pm 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
troed
Moderator
Moderator
Posts: 909
Joined: Mon Aug 21, 2017 10:27 pm

Re: ST FPGA MMU Development

Post by troed »

ijor wrote: Thu Mar 17, 2022 2:56 pm You can use my cores for cycle exact accuracy.
That would indeed be fantastic!
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: ST FPGA MMU Development

Post by ijor »

exxos wrote: Fri Feb 14, 2020 9:12 pmTroed'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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
Post Reply

Return to “FPGA DEVELOPMENT”