Here's an initial port of the Sega Megadrive / Gensis core to V2 hardware. This is merely a port of the V1 core, and doesn't incorporate any of the recent upstream improvements.

retroramblings.net/snapshots/fpgagen_chameleonv2_20190505.zip

Please test and let me know if you encounter any problems. It should support CDTV pads, C64 joystick (though only one button) and PS/2 keyboard mapping for both players.

Quote from Tobias

Just did a quick test... seems to work. I got some weird problems with one SD card, it showed a bunch of empty directory entries and i couldnt select the ROMs i copied to it. with another fresh card it worked. would be great to have a readme in the zip that tells me where the buttons are mapped to on the keyboard =)

Thanks - I've given the release a page on my blog, here - http://retroramblings.net/?p=1246

Good point about the controls - I've listed them on the release page, but I'll include a readme next time I make a release.

Not sure what's causing the SD card issues, but clearly I need to revisit the FAT code at some point.

(Also, the ported cores thread gives the impression that I'm the author of several cores - I can't claim that much credit, having mostly just ported them and made some improvements here and there.)

Quote from Karsten

Is the FPGA Megadrive available for Turbo Chameleon v2?

Yes indeed - the first post in this thread contains a link. Or find it here: http://retroramblings.net/?m=201905

Quote from kezax

Hello, I have a question about core development. I am interested in porting an existing core (the Amstrad-alt core which is working on the MIST) to the Chameleon V2 hardware, just, I am quite starting on the subject, and I wonder how in practice a port to the Chameleon is made in general. Is it possible to test a core in some kind of chameleon emulator ? Or do you test everything on the real hardware from the start and use Chaco or a JTAG connector to be able to trace something ?

There's no "emulator" as such - nothing where you can run a core on the PC and see the graphics and hear the sound, but there is simulation software which you can use to test an individual subsystem - or even an entire core if you can arrange a complete enough testbench for it. Quartus has integration with ModelSim, but there's also Verilator for verilog and GHDL for VHDL, both of which are open-source and very useful. I've used GHDL to run test programs on my CPU design.

The other very useful tool in Quartus is SignalTap, which is a real-time logic probe, accessed over JTAG. Using it requires some spare logic and block RAM within the FPGA - so if the core you're working on nearly fills the FPGA, finding room for SignalTap can be a problem, but it's unbelievably useful. (JTAG has other uses, too - you can set up a virtual serial port and read its output using nios2-terminal - you can even write your own software to talk to a core over JTAG. I can connect to my CPU over JTAG and single-step through the program, read and write memory, etc.)

As it happens, I'm currently working on a framework to make porting MiST cores easier - and I've literally today released a port of the NES core, which makes use of it. The framework's firmware doesn't yet support disk images, so it probably won't be complete enough to help with the Amstrad core yet, but it may be in future.

As a development platform I use a DE10-lite (which is *not* the same thing as the DE10-nano used on the MiSTer) - the reason I chose it is that the MAX10 FPGA it uses has the same technology level as the Chameleon's FPGA, but it's twice the size, so has plenty of room for extra debugging modules.

To use JTAG you have to solder a pin header to the Chameleon, to which you connect a USB-Blaster. Note that once you've done this you can't connect a clock-port peripheral because the pin header physically gets in the way.

You can upload a .sof file using the Quartus programmer.

It's straightforward on Chameleon V2 hardware. On V1 hardware there's another device on the JTAG chain (a Xilinx CPLD) which means you have to do auto-detection of the JTAG chain and apply the .sof to the correct device. You have to do this every session because Quartus won't save the chain file, due to it not recognising the other device on the chain.

Quote from pwsoft

Actually... you can create a custom device definition for the CPLD in the Quartus programmer software and then you can save it.

Right click on the CPLD icon, select "Change Device", then add an entry for it in the "User Defined" list by pressing new and filling in a few details.

Yes, I did experiment with that once before - but I couldn't figure out how to save the definition for future reference... (I can export it, but next time I run the software I need to import it manually, otherwise I can't load a .cdf that references it!)

Maybe it's a Windows / Linux thing?