2018-04-20
Here’s an updated snapshot of the FPGA Megadrive / Genesis core for both Chameleon64 and MIST with the latest memory speed improvements. I’m hopeful that this will pretty much eliminate the sprite issues that have been present in previous releases:
- Chameleon – fpgagen_chameleon_20180420.zip
- Mist – fpgagen_mist_20180420.zip
Thanks very much for the efforts , it’s much appreciated to have someone still working on MIST cores 🙂
Loading on to my MIST now for a play test!
Great stuff !!
I am also happy for some more stuff for MiST ! And possibly more dev for the Amigacore on Chameleon !
Thanks for the update, it’s greatly appreciated.
Hi AMR,
i have try to send you an email into Atari-Forum but seems newbie can’t use that feature.
I have some knowledge into Megadrive hadware and a working toolchain for
making demo ( i use SGDK).
If you agree/need i will be very happy to help you.
I can provide some sample demo with for testing sprite,Background priority
, simple sound etc..
Could you tell me how can i send you a private message ?
Hi – I have received your email through AtariForum, so don’t worry, I’ll respond soon!
Whoo! Nice! Gonna try this out next weekend. Thanks for still working on cores for the MIST.
Going to give the update a try. Do you ask “Is this as good as it gets?” because the core is now near perfection or because it is “as good as can be” based on FPGA space left, etc.?
It’s certainly not perfect, and the FPGA is now pretty full. There is a possibility that I might be able to squeeze a bit more bandwidth out of it, and just an outside chance I might be able to fix a few other issues in the fulness of time, but I don’t think there’s a lot more scope for improvement within the current FPGA’s space constraints.
where is the source code ?
The source is on github – as with all my FPGA projects. My fork is at https://github.com/robinsonb5/fpgagen
Thank you Mr. Robinson for the latest changes! You often tell us that the FPGA in the MIST is used up. Have you ever thought about switching to MISTer? It has much more FPGA capacity and also a powerful ARM core (Hybrid Emulation?). Your code including changes has already been ported. If you had more capacity, could you push the core even further? I use the MISTer myself, it is also open source and if you have any questions, please contact me. If you need a donation, feel free to contact me too!
Thank you for your efforts.
Thanks for the recommendation. I’m aware of the MISTer project and it looks very interesting, but I have too many other projects on the go right now to get involved with another FPGA platform!
Hi, thanks for the update. Is DE2 not working anymore? I just tried with the current source code, but I’m getting a black screen after reading the ROM.
DE1 have some missing files, fails to build
I thought DE2 was still working – I like to use the DE2 when developing since it’s nice and roomy, and fairly quick to build for. I’ll take a look when I get a chance.
I should probably remove the DE1 target – there’s no chance of the updated core fitting in the EP2C20.
Thanks! I believe I saw some DE1 version, but without FM sound (maybe yours?). It could be a possibility for those who still have a DE1, now, to play with the perfect sprites. Or even without FM no longer fit on DE1 anymore?
Anyway, thanks for your efforts, I really appreciated.
This version works on DE1 – https://github.com/Torlus/fpgagen – but requires the ROM to be uploaded into the DE1’s flash. Phoboz ported it to MIST, incorporating my ZPU-based control module from my ports of the OneChipMSX and PC Engine cores. This version can load ROMs from SD card, and is the basis of the versions with FM sound, but no longer fits in the DE1 even without sound due to lack of block RAM.
How do I get this working on the Chameleon?
I flashed slot2 using ChaCo and the core boots provided i start it with ChaCo. If I remove the power to the Chameleon then I try to start with ChaCo or using the Chameleon built-in menu I get this…..
SD Init….
Read failed
MBR fail
or just
SD init…
Anyone else had this problem? Kind od ruins it when ever I want to use the core with the Chameleon I have to use my laptop to reflash and boot the core every time. 🙁
I haven’t seen this myself – but does pressing the reset buttons on the Chameleon have any effect? Have you tried with different SD cards?
If I use reset without powering down after flash…. works fine.
Reset after power down and i get SD Init…
Haven’t tried an alternative SD card yet. Currently using micro SD and adapter.
A small win.
Tried full size SD card, didn’t work because every time it was inserted the Chameleon would reset and upon launching fpgagen would give me a read reset fail…
However I discovered when using the previous micro SD card (doesn’t reset Chameleon upon insert) at first would give me
SD init…
SD card reset failed!
Read failed
MBR fail
SD init….. and so on repeating
But if I remove and re-insert then it loads fpgagen file browser (sometimes requires remove, re-insert and reset chameleon to work).
So good enough. 🙂
OK thanks for the info. I’ll take a look sometime soon. I just realised I haven’t actually tried flashing this core onto my own Chameleon at all – I’ve only tested by programming the core with a USB-Blaster.
I totally missed this one … shame on me.
Excellent work. Did you also upgrade the tg68? I still have the version with the latest tg68k at https://github.com/harbaum/fpgagen . It may make sense to combine this with your latest changes.
I’ve updated my fork and it now includes your changes and a pretty new tg68k. The mist FPGA is now 97% full.
I don’t see any difference 🙂 which imho is a good sign. But there may be a significant change in 68k CPU speed as both tg68(k) versions work pretty differently in that respect.
One bug unrelated to my changes happens in Sonic demo mode: The upper border at on point “opens” and ~16 additional lines are displayed containing garbage.
97%? Wow – actually I’m amazed it fits at all, which is one of the reasons I didn’t attempt to integrate the newer CPU core myself. (The other being that I’m still splitting my time between far too many projects, so was concentrating very specifically on SDRAM performance!)
I didn’t expect it to work either. But as this was just a matter of re-applying a simple patch i gave it a try, anyway.
It may at least be useful to see if certain things are related to CPU bugs or CPU speed as the new CPU would then have an impact on this.
So i can tell e.g. that the bottom border garbage in Sonic intro is not CPU related.
I’ve added the ability to drive YPbPr component inputs with the core. This works on my TV in 15Khz and in 30lkHz mode.
I have a feature request: It would be nice if the OSD would be controllable via gamepad or joystick. That way no keyboard would be required at all.
That’s a good idea – I’ll take a look at some point.
VDP fix for games that show additional 16 lines at the bottom:
In vdp.vhd change line 665 from
V30 <= REG(2)(3);
to
V30 <= REG(1)(3);
Worms has also been fixed. So to answer that question in the title: No, it can still be improved.
But we still have a use for a helping hand. There’s sure a lot left that needs improvement