I found out recently that there is now a second version of the Turbo Chameleon 64 cartridge for the Commodore 64. The reason for this is, apparently, that the Cyclone III FPGA that was used in the original design has been superceded and is difficult to obtain at affordable prices. For this reason Individual Computers have redesigned the cartridge to use a Cyclone 10 FPGA instead. The model chosen is essentially the same thing in a different package, so porting cores would simply be a case of recompiling with the new device and pinout as the target – except they’ve also taken the opportunity to make small improvements to the design. For this reason it now takes a little bit of work to port existing cores to the V2 hardware.
I now have an initial build of the Minimig core for V2 hardware, which is available as before on the Minimig TC64 Snapshots page.
Edit: Since the V2 hardware is likely to attract newcomers to the Chameleon platform, I should explain what to do with the two files in the snapshop archive:
- The fampiga_tc64v2.rbf file is the core itself, and needs to be flashed into the Chameleon cartridge using the Chaco utility.
- The OSD_CA01.sys file is the firmware for the secondary CPU core that runs the menu system and disk emulation, and needs to be written to the root directory of an SD card. The card will also need to contain a Kickstart image, named kick.rom
Another point to bear in mind is that the core doesn’t yet attempt to translate the C64 keyboard to the Amiga – so far just the run/stop key is used to toggle the OSD – so you will need a PS/2 keyboard to use the core for anything that requires keyboard input.
Source is availabe, as before, on github.
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:
Part 3: Tweaking the VDP implementation
In the second part of this series, I increased the throughput of the Megadrive core’s SDRAM controller, which gave nearly but not quite enough extra bandwidth to solve the sprite display problems. To improve things yet further I need to look at the VDP implementation itself…
Following the SDRAM-related improvements to the Megadrive / Genesis core that I’ve covered in my last couple of posts, here’s an updated snapshot for both the Chameleon and MIST boards:
While it’s still not perfect, the glitches should be much less noticeable, and hopefully there will no more missing platforms or missiles making games unplayable!
Part 2: Saving cycles
In the first part of this series I covered some basic tidy-ups to the code to make it easier to maintain. Now I’ll look at how we can speed things up.
The Megadrive/Genesis core has been plagued from the start with graphical issues that result from the SDRAM controller not responding quickly enough. Over the last few days I’ve finally put some time into understanding the SDRAM controller used by the project and spent some time improving its throughput.
I’ve just made available an updated version of the Sega Megadrive / Genesis core for the Turbo Chameleon 64. The only change is to the joystick handling – I’ve untangled the joystick directions and remapped the buttons slightly.
There’s still not a lot of point in using a traditional 1-button C64 joystick with this, but I’ve also fixed a bug in my previous attempt which prevented the CDTV infra-red controller from working. This does now work, and the buttons are mapped as follows:
Play / Pause => Megadrive Start
Volume Up => Megadrive A
A => Megadrive B
B => Megadrive C
I’ve mapped Volume UP to button A simply because it physically feels in the right place. The CDTV pad isn’t super-responsive, so trying to use for serious gameplay is an exercise in frustration, but it does work, and the controllers are readily available from AmigaKit.
The new core can be found here: fpgagen_chameleon_20180305.zip
One of the challenges I’ve faced in the ZPUDemos project is keeping the various targets up to date. When I add a peripheral to – for example – the SDBootstrap SOC, I have to modify each and every target’s project file to match, and it’s very easy to lose track of which ones have been updated and which ones haven’t.
ZPUDemos currently supports no fewer than eight different target boards, and contains eleven different projects – that’s a lot of project files!
In an attempt to make this more manageable, I’ve written some scripts to generate project files automatically, from a list of RTL files, and a board-specific template file. I’ve taken the opportunity to clean up the whole project, too, so the directory structure is more logical. Continue reading
Part 7 – Loading data from SD card.
In this part of the series I’m going to look at the most useful aspect of the control module – using it load data from SD card and pass it to the host core.
To make a meaningful demonstration, the host core needed to be able to do something with the received data, so I’ve pulled in the SDRAM controller and VGA framebuffer from the ZPUDemos project. What I’ve called the “host core”, the part of the project which the ZPU-based control module is supporting, is now capable of displaying a 640x480x16-bit VGA screen from SDRAM, and as such the project is now quite a bit more complicated; however, the only new file needed by the control module itself is spi.vhd which handles communication with the SD card.
Part 6 – resource sharing
So far we have the control module merging an on-screen display with the underlying host core’s video output, responding to keypresses and running a simple on-screen menu. The largest single addition now will be SD card access, which I will explore in the next part. In this part, however, I’m going to talk about resource sharing.
Some cores, like the test-pattern generator we’ve been using so far or the PC-Engine core, make no use of the keyboard or SD card, so giving sole access to the control module is no problem. If, on the other hand, the underlying core does make use of keyboard and SD card (such as the OneChipMSX core, for instance) we need to have some way of arbitrating for access to these resources. Continue reading