Porting a Core, DeMiSTified – Part 5 – 2021-03-07
I’m not going to go into great depth regarding the substitute controller module which I’m using for this project, since I’ve covered much of that ground in previous posts (see the previous series about the ZPU-based control module, the TG68_MiniSoC project and also EightThirtyTwoDemos) – in all cases I have a soft CPU with a number of memory-mapped hardware registers, and I’m following much the same pattern this time around.
Briefly, I have a UART for serial debugging output, an SPI chip select register which allows one of several SPI channels to be selected, an SPI data transfer register, a simple interrupt controller, PS/2 keyboard and a simple timer in the form of a millisecond counter. I also have a joystick input register, since the controller will be responsible for relaying joystick events into the guest core.
So having created a CPU and peripheral module which we can connect to the guest core, all that remains is porting the firmware, yes?
Porting a Core, DeMiSTified – Part 4 – 2021-03-03
(Before I start this installment, I should say that I have now released the Chameleon port of the NES core – I’m not going to delay the core just to talk about the process!)
So we have a project file for the MiST version of the core, and we need to create project files for other platforms. My scripts and Makefiles will produce these files, so what I need to do is extract a list of components from the .qsf project file for MiST.
Porting a Core, DeMiSTified – Part 3 – 2021-03-01
When an FPGA core is a self-contained standalone project with only one target board, managing the project from within the FPGA vendor’s IDE works fine. However, once there’s a significant amount of shared code between projects, or you’re building for multiple targets, things get more tedious,
EightThirtyTwoDemos currently has targets for nine different boards, and there are another four within easy reach that I could add if I wished. There are nine demo projects in the repo, so I could have to rebuild as many as 81 projects when something changes. Loading each project, one after another, and rebuilding them manually would be ridiculously inefficient – a better solution is needed.
Porting a core, DeMiSTified – Part 2 – 2021-02-25
The goal is to provide an environment in which a MiST core can be included as a submodule, thus porting the core to a new target board without making large-scale changes. To do this, we’re going to need a toplevel for each target board which maps the signals of MiST’s FPGA to board-specific resources.
Let’s take a close look at a MiST core’s toplevel…
Porting a Core, DeMiSTified – Part 1 – 2020-02-24
There are many FPGA cores out there which could be ported to the Turbo Chameleon 64 cartridge. In some cases it’s just a question of somebody doing the legwork, in other cases it gets a little bit more involved – but can we do anything to make the amount of work required more manageable?
Long-time readers will know by now that I don’t ask that kind of question out loud unless I already know that the answer is yes!
I’ve just bought a couple of the ridiculously cheap DECA MAX10 dev boards from Arrow and one of the first projects I attempted to port to it gave me an error message I wasn’t expecting:
Error (276003): Cannot convert all sets of registers into
RAM megafunctions when creating nodes. The resulting number
of registers remaining in design exceeds the number of
registers in the device...
Hmmm, OK, what’s going on here? For some reason the ROM in my project isn’t getting recognised and implemented as initialised block RAM – what gives?
It occurred to me recently that there is a lot of history in the Minimig project, with many people making important contributions over the course of some 15 years.
It also occurred to me that as developers come and go, and new users encounter the latest Minimig cores without having seen what came before, there’s a real danger that some of that history will be forgotten.
I’ve just released an updated version of the MinimigAGA core for all three of my current target platforms – TC64 version 1, TC64 version 2, and MiST.
The core doesn’t have 100% feature parity between the three platforms, since the MiST has an onboard microcontroller to handle input and storage, while the Chameleon doesn’t. Having to implement an equivalent microcontroller in the FPGA makes some things harder – but other things easier.
For this reason, this time around the TC64 ports have a feature not yet available on MiST – experimental floppy drive sounds. To enable this, simply copy the drivesnd.bin file onto the SD card. If you don’t like it, just delete the file again – there isn’t (yet) a way to turn it on and off from the menus.
Other changes this time include the addition of a very basic LED Audio filter implementation – not accurate, but just good enough to make the going-through-tunnels sound effect in Lotus II work, and Slingshot on Atari-Forum has put some hard work into debugging the CPU core, and found an issue with stack frames which was preventing certain Graftgold games from working in ‘020 mode. His fixes to the CPU are included.
I’ve also made some timing tweaks on all three platforms so that all of them build with clean timing reports.
Turbo Chameleon 64 users can find the latest version of the core here
MiST users can find the latest version of the Minimig core at the official MiST binaries repository.
After porting the MiST’s Minimig core to the Turbo Chameleon 64, I spent happy few weeks adding extra features including, most notably, RTG support. A number of people have kindly supported me in this endeavour, both directly via PayPal and also on Patreon – and I’m very grateful for this support.
None of this would have been possible without building upon the MiST’s AGA core, though, so it seems only right that I should port my improvements back to the MiST.
If it’s seemed quiet here lately, that’s because I’ve been hard at work improving the Turbo Chameleon 64 ports of the Minimig core.
The two main features added since the last release are an experimential implementation of the Akiko Chunky-to-Planar converter which can be used by a handful of games to increase video performance, and an experimental P96 retargetable graphics driver.