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!
Porting an arcade core to the Turbo Chameleon 64 – Part 2 – 2020-03-06
For the Chameleon64 port of Rampage I needed some way of showing an On-Screen Display. While the core doesn’t have many options to worry about, I did want to be able to display a “Loading” message and an “Error” message if loading the ROM failed.
There are several different ways we could approach this, but as you’ll recall from part 1, we’re very short of block RAM for this project, so minimising block RAM usage will be my priority.
Tunneling debugging information over JTAG – 2020-03-04
One of my primary platforms for FPGA tinkering is the Turbo Chameleon 64 cartridge – which comes in two flavours: the original V1 hardware which features a Cyclone III FPGA and the V2 hardware which has a very similar Cyclone 10LP FPGA (basically the same thing in a newer package).
While this cartridge is intended as an expansion for the venerable Commodore 64 8-bit computer from the 1980s, it can nonetheless run other more general-purpose cores, so most of my projects have Chameleon64 targets. The one downside of this hardware is the lack of general purpose IOs. It has no built-in serial port, and nowhere really convenient to attach a USB-serial dongle either. It’s possible to misuse the IEC port for this purpose, but then I need to remember to disable it before distributing a finished core (I doubt a 1541 disk drive would appreciate having RS232 data spewed at it). There’s also a USB debugging protocol built into the cartridge, which I haven’t yet explored – mostly because so many of my projects can be built for multiple platforms, I’m reluctant to put a large amount of effort into supporting features only available on one of them.
I discovered the other day, however, that it’s possible to tunnel a UART-style connection over JTAG.