2021-05-02
I’ve finally turned my attention to porting the updated version of the Megadrive/Genesis core to the Turbo Chameleon 64. Since I last had any input into this core it’s come on in leaps and bounds, and adding the DeMiSTify module to make it run on controllerless boards would be next to trivial.
Or so I thought…
Continue readingExploring audio DACs in simulation – Part 2 – 2021-04-02
Having rambled on a little longer than I intended while setting the scene for these experiments, I’m going to set up a simple testbench with verilator to evaluate the performance of several different DACs.
Continue readingPorting 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?
Well…. no.
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…or, perhaps I should say eventually.
In case you wondered why things are so quiet here at the moment, it’s because a week and a half a go I finally took possession of my new home. It’s going to be several weeks before I have internet access, and no doubt several more before I can turn my attention from decorating to geekiness!
Rest assured that I will eventually get back to tinkering with FPGAs and all things retro.
880 Gamer Issue 7 is out!
Another beautifully produced edition of the PDF Magazine 880 Gamer is out now, complete with coverdisk in ADF format!
This and previous issues can be found at: http://www.users.on.net/~stanners/
A few people have pointed out to me that the ZPU toolchain is becoming more difficult to build as time goes on. It’s based around a specific version of GCC and hasn’t been updated in a while, so while technologies used in the build process move on and the incompatibilities that creep in are fixed in the GCC mainline, the ZPU toolchain is left out in the cold.
In an attempt to halt the bitrot, I’ve updated the patch on my “Setting Up the Toolchain” post, which while being workaround-laden rather than an actual fix, should render the toolchain buildable on a more modern Linux distro.
So this site, like any site that accepts comments, receives its fair share of spam. Akismet does a pretty good job of keeping them at bay, but sometimes the weirdest ones get through.
This one’s bizarre enough that I almost approved it – but I don’t want to reward the spammer by sharing the actual advertised link site! so….:
In my last post I mentioned that I had to employ some ugly hacks in the boot firmware for my ZPU project, to make sure certain structures ended up in SDRAM rather than the initial Boot ROM.
To illustrate the problem let’s look at a minimal test program:
short inconvenience;
int main(int argc,char **argv)
{
inconvenience=0x0123;
return(0);
}
This little program declares a 16-bit word global variable, and then writes to it. The assembly output produced by
zpu-elf-gcc -Os -S bsstest.c
is as follows:
.file "bsstest.c" .text .globl main .type main, @function main: im 291 nop im inconvenience storeh im 0 nop im _memreg+0 store poppc .size main, .-main .comm inconvenience,2,4 .ident "GCC: (GNU) 3.4.2"
Note the storeh instruction half way down. That’s the source of my problem. I’ve implemented storeh in hardware for SDRAM, but not for the BlockRAM-based Boot code, and I’d really like to avoid doing the latter if possible, because doing a 16-bit write to a 32-bit wide RAM is going to be messy and eat up logic elements. The boot code is also rather on the large side, so it would be nice to avoid storing unitialised data in there at all if possible.
Continue reading
I have a confession to make!
After my post about video game music and references – deliberate or otherwise – to pop music of the day, I remembered my old AMRWolf project and the ProTracker module I wrote to serve as its title music:
Wow – does that say *1996*? Now I feel old! Anyhow, bonus points to anyone who can identify the piece of 80s pop music that inspired the backing track…
The module itself, in case anyone’s interested, can be found here. (Yes, imaginatively titled “Untitled2”. I could occasionally come up with music tracks that were worth not deleting on the spot, but I never could come up with decent names for them! I still can’t, for the very occasional pieces I come up with these days – “Ode to a Girl who Works in Lidl” *really* doesn’t cut it!)
The sampled breaks were themselves created in ProTracker, then rendered down to a single sample to squeeze as much from the 4-channel sound chip as possible. Sadly I don’t have the source tracks any more.