It’s been some time since I’ve made any significant changes to the EightThirtyTwo ISA, CPU or compiler backend, and this is mostly because I’ve been busy using it in real projects.
EightThirtyTwo’s original purpose, apart from the obvious learning exercise, was to be the supporting CPU in the AGA Minimig core for the Turbo Chameleon 64, and it’s performed this function quite nicely: it’s significantly smaller than the secondary TG68 used in the ECS core, and somewhat smaller than the OpenRISC cores that were used in some other Minimig variants, while using fewer memory blocks due to its logic-based register file and reasonably good code-density.
Nevertheless there are always bugs to be fixed and improvements to be made.
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
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.
At long last, the AGA enhanced Minimig core finally comes to the Turbo Chameleon 64!
I teased the new core on YouTube a couple of days ago:
At the same time I announced that, in response to several people prompting me in the past, I now have a virtual tip jar – so anyone who wishes to contribute towards the development of this and other cores can now do so.
I’m not planning to paywall cores or releases – that’s not my style – but as an incentive for supporters, I’ve added a “Core Supporters” page to the On-screen Menu, which I’ll use to thank by name anyone who donates £20 or more via PayPal or supports me on Patreon at the second tier.
In other news – I’ve just released the first beta – see the Turbo Chameleon 64 section elsewhere on this site.
What better way to celebrate Star Wars Day than with a multi-CPU code density shoot-out?! (Well, OK, most people can probably name a dozen better ways without even trying – but this is how I’m choosing to spend it!)
I was curious to know just how well the code density of EightThirtyTwo code generated by the VBCC backend stacks up against other architectures, so I compiled a fixed codebase, namely the OSD control module from one of the many Minimig variants, targetting 832, m68k, MIPS, OpenRISC, RISC-V ARM, and even i386 and x86-64. The results make for interesting reading…
I’m continuing to make gradual improvements to the EightThirtyTwo toolchain, and over the last few days I’ve given my attention to linker libraries, and endian issues.
While I initially intended EightThirtyTwo to be a big endian CPU, it occurred to me early on that I could make endian-ness configurable with a generic parameter. This I did, and having set that “littleendian” parameter to “true” for testing, I never actually changed it back, so all my testing over the last few months has actually been in little endian mode!