Part 1: This should be easy, right?
Some months back I was introduced to OneChipMSX by a keen user of the Turbo Chameleon 64 and various other FPGA boards, in the hope that I’d be able to port the project to the Chameleon.
At the time it was a more complicated proposition than I was capable of tackling, but I’ve learned a great deal since then, so recently decided to look again.
At a first glance OneChipMSX seems to be a good fit for the Chameleon: source is available, and apart from the designated OneChipMSX hardware it’s been ported to the Altera DE0 and DE1 boards. The project doesn’t use SRAM, and will only half-fill the EP3C25 on the Chameleon 64. All in all it looks like an easy port, except for one inconvenient little detail: there’s a BIOS file which needs to be stored in flash. The existing ports of the project all have one thing in common; rather than storing the BIOS in separate flash, they store it in the very same flash chip that contains the FPGA bitstream; the EPCS4. This makes porting the project to a board that doesn’t use this configuration chip a little tricky, since the Initial Program Loader which loads the BIOS from the EPCS is (a) a tiny Z80 assembly language program, and (b) lacking source code!
Having grown up on a C64 and then an Amiga, I’ve never been exposed to Z80 machine language, so there was quite a learning curve involved. I have to say, though, having read up on the subject that I’m impressed with the Z80 instruction set – the instruction set is elegant and the code density is excellent.
The IPL is, in theory, capable of loading the BIOS image from an SD card, but I have yet to get this working; it apparently requires that the card be freshly formatted, regular SD rather than SDHC, and for the BIOS to be the first file copied to the newly-formatted card.
I did manage to find source code for one version of the Initial Program Loader, but soon realized that it expects the BIOS to be raw, whereas the version supplied with the DE1 port expects a packed BIOS image (supplied in hex form).
It soon became clear that my choices were to (a) rewrite the initial program loader to deal with the Chameleon64’s flash chip, or bypass the Initial Program Loader, forget about flash and use a more sophisticated bootloader to read the BIOS from SD card. Since the Chameleon has no switches, and the switch functions are quite important I also need to implement some kind of OSD menu system, so I elected to add an extra CPU to the project to handle both duties – booting and OSD handling. If you’re a regular reader you’ll probably have no trouble at all guessing which CPU I chose!
The extra CPU starts with a ‘Z’ but it is not a Z80?
😉
Yup! And once again, using it in a real project, I found and fixed some issues.
Please keep us updated 🙂
I only had a short look at the MSX and if it would be feasible to port it to the MiST. I’m a hdl beginner and therefore tried easier cores first. I assume you know the MiST and it hasn’t sram and flash as well. Unfortunately also no sd card access from the core yet (but I already asked Till to implement that in the arm firmware 🙂
How much KB is the BIOS? I assume it won’t fit in the bram of the EP3?
Yes I’m familiar with (and like very much) the MIST board, but the lack of direct FPGA->SD card access does make porting certain cores more difficult than it would otherwise be.
I’m having some difficulty getting this working, and finding a lot of pitfalls and complications along the way. The BIOS is pretty large, at least 200KB (so no, it won’t fit into the BRAM) – but confusingly, the BIOS image available for download on Caro’s OCMSX DE1 page isn’t the same as the BIOS image that gets loaded into the EPCS. Also the Initial Program Loader in the project isn’t the same as the only copy I was able to find of its source code. So I’m currently disassembling code, deciphering header formats and suchlike.
The EPCS protocol is very simply, thankfully – you send it one command and a byte offset, and it just spews data in your direction as long as you ask it to.
Hi Alastair! good luck with this core porting, MSX looks very promising and with nice games 🙂
I hope it doesn’t get too difficult. Best regards! Juan
The MiST got me started on the FPGA topic and with Till’s help we ported some more cores to it. During that he developed some interfaces to help noobs like me easier development (simple sdram controller, data upload via osd to sdram or bram).
He said if time allows he would write an interface for sd as well since I raised that question already some time ago 😉
Not sure if that would allow the same level of control like a direct attached sd.