Great milestone!
BW
Great milestone!
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.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!)...
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.
Wakestates depend both on GLUE and MMU. If the MMU implementation is not cycle exact, it might certainly produce invalid wakestate results.
Actually, not everything is reset on hardware reset. The other factor is that reset is not synchronized.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.
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.If we can reset them both with system reset then I would make the assumption the randomness would stop.
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.Its interesting in suska code there is a "reset" for the shifter as well as the MMU using other signals.