Well it’s been nearly a year since my last post, and in the break between Christmas and New Year I once again have a few spare hours to tinker with projects. I’ve used a few of these to get the MIST Sega Genesis / Megadrive core working, at last, on the Chameleon 64.
In the Christmas break I’ve finally found a little bit of time to tinker with FPGAs again. Not enough to tackle anything major, but I’ve done a little bit of bug fixing on the OneChipMSX core.
Or so I thought. 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/
One of the challenges I’ve faced in the ZPUDemos project is keeping the various targets up to date. When I add a peripheral to – for example – the SDBootstrap SOC, I have to modify each and every target’s project file to match, and it’s very easy to lose track of which ones have been updated and which ones haven’t.
ZPUDemos currently supports no fewer than eight different target boards, and contains eleven different projects – that’s a lot of project files!
In an attempt to make this more manageable, I’ve written some scripts to generate project files automatically, from a list of RTL files, and a board-specific template file. I’ve taken the opportunity to clean up the whole project, too, so the directory structure is more logical. Continue reading
It’s good to be able to report that the upstream ZPU project – and also the toolchain – has officially moved from its previous home to github, so the source for the GCC port can now be found here: https://github.com/zylin/zpugcc\
Better yet, this repo contains the various build fixes needed to compile this old version of GCC on a modern Linux system, so much of my previous “Setting up the toolchain” post is no longer relevant, and has been updated accordingly.
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.
Part 7 – Loading data from SD card.
In this part of the series I’m going to look at the most useful aspect of the control module – using it load data from SD card and pass it to the host core.
To make a meaningful demonstration, the host core needed to be able to do something with the received data, so I’ve pulled in the SDRAM controller and VGA framebuffer from the ZPUDemos project. What I’ve called the “host core”, the part of the project which the ZPU-based control module is supporting, is now capable of displaying a 640x480x16-bit VGA screen from SDRAM, and as such the project is now quite a bit more complicated; however, the only new file needed by the control module itself is spi.vhd which handles communication with the SD card.
Part 6 – resource sharing
So far we have the control module merging an on-screen display with the underlying host core’s video output, responding to keypresses and running a simple on-screen menu. The largest single addition now will be SD card access, which I will explore in the next part. In this part, however, I’m going to talk about resource sharing.
Some cores, like the test-pattern generator we’ve been using so far or the PC-Engine core, make no use of the keyboard or SD card, so giving sole access to the control module is no problem. If, on the other hand, the underlying core does make use of keyboard and SD card (such as the OneChipMSX core, for instance) we need to have some way of arbitrating for access to these resources. Continue reading