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.
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.
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:
int main(int argc,char **argv)
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:
.type main, @function
.size main, .-main
.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 →
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.
This blog was offline for a while yesterday, and was running slow when it was up. Apparently the reason was an internet-wide attack against WordPress sites, attempting to brute-force the admin passwords, and presumably litter any compromised blogs with spam.
Thankfully I used a nice secure password (Eight asterisks – no-one would *ever* guess that!) and RetroRamblings seems to have been spared any such indignity.
After porting the Minimig core to my ebay-acquired Cyclone III board, I’ve spent some time this week porting the MiniSOC project to the Turbo Chameleon 64.
Hardware-wise the TC64 is very similar to the CIII board – the FPGA is identical, and there’s the same amount of SDRAM – albeit with a slightly different layout – so porting projects from one to the other is fairly straightforward. The only complicated part is routing certain signals through a CPLD which is used in the TC64 to multiplex some of the IOs, and as a bonus, to provide 5v tolerance. This is taken care of in the Chameleon-specific toplevel, meaning once again that the same basic source tree can be built for DE1, the CIII board and now also the Turbo Chameleon 64. Continue reading →
I needed a bit of a break from wrestling with timing constraints and trying to figure out how to make the core stable from build to build, so figured I’d make a video of the Minimig core in action. This is the first time I’ve used this particular camcorder, so forgive the shaky camerawork!
In my last post I mentioned removing the blue LEDs from the fascia of the case I plan to use for my FPGA project. I have an extreme dislike of blue LEDs – or at least of the seemingly universal pervasiveness of blue LEDs. We’ve been able to make them cheaply for, what, a decade now? Get over it, people! It’s not novel any more. They’re annoyingly bright and unpleasantly piercing. I’m tired of hiding them behind Post-it notes.
So I replaced these obnoxious blue LEDs with bog-standard red, yellow, orange and green LEDs, which worked but weren’t really bright enough to shine through the diffusing layer on the case. (This layer’s task is presumably to make the blue LEDs vaguely bearable. Hint: you can make them much *more* bearable by not using them in the first place.)
I ordered some high-brightness LEDs, somewhat skeptical about how different they’d be. The difference is dramatic, and the LEDs are now clearly visible even in strong light:
There! Doesn’t that look much nicer than a row of blue lights?