The EightThirtyTwo ISA – Part 19 – 2020-03-25
One my main goals when starting the EightThirtyTwo project was to minimise the amount of block RAM I needed to devote to firmware; indeed, this was even more of a goal than was raw speed.
So how does the architecture measure up to that goal?
Continue reading2020-03-13
Long story short: I’ve just spent way too much debugging a problem that turned out simply to be an SDRAM chip’s CKE line not connected in the toplevel design file!
Continue readingThe EightThirtyTwo ISA – Part 19 – 2020-03-08
In my experiments a few days ago I noticed an odd problem with the EightThirtyTwo toolchain – namely that the following construct worked just fine:
char string[]="Hello, world!";
but the following didn’t:
char *string="Hello, world!";Continue reading
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.
Continue readingTunneling 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.
Continue readingPorting an arcade core to the Turbo Chameleon 64 – Part 1 – 2020-02-26
There are many, many arcade re-creation cores in existence now – and only a handful have been ported to the Turbo Chameleon 64. When I discovered that Rampage exists for both MiSTer and MiST my interest was piqued, because this is a game I played on the Amiga as a kid, and while the Amiga version’s not a bad conversion, the original arcade game is significantly better.
The EightThirtyTwo ISA – part 18 – 2020-02-19
Having added partial results forwarding I figured I’d better check that I hadn’t broken dual-thread mode in the process. (Spoiler alert: I had!)
Continue readingThe EightThirtyTwo ISA – Part 17 – 2020-02-16
I was looking today at ways of improving the throughput of the EightThirtyTwo CPU. The design as it stands is very simple, and didn’t make any attempt to perform result forwarding or instruction fusing. These are both strategies for improving the performance of certain constructs, and I wasn’t sure which of these two techniques I should use.
In brief, without either mechanism implemented, when the CPU encounters code such as:
li 0
mr r0
it has to wait until the first instruction has finished writing to the tmp register before moving its new contents into the pipeline, and only then finally writing it to r0.
Continue readingThe EightThirtyTwo ISA – Part 16 – 2020-02-08
In my last post I touched briefly on the 832a assembler which I wrote as the first part of my solution to improving the code density of compiled C code.
An assembler that takes a single source file and spits out a ready-to-run binary file is not particularly difficult to write, but it’s not particularly useful either – in order to be useful we need to be able to link together multiple code modules.
Thus, 832a now has a cousin: 832l, the linker.
Continue readingThe EightThirtyTwo ISA – Part 15 – 2020-02-06
I’ve joked a few times in this series about being too lazy to write an assember – but it would be more true to say that the stop-gap solution I was using was adequate, so my time was better spent on the more enjoyable aspects of the project. I am now feeling the limitations of using the GNU assembler to produce a bytestream for a target it knows nothing about, and to improve either the performance or code density of the vbcc backend’s output any further, I need to address the problem I’ve had so far with cross-module references…
Continue reading