Wife and kids when to the shops and as they say, when the cats away the mice will play. I took the time to write a little CHIP-8 emulator, you might remember I did a similar one for the Game-O.
The CHIP-8 is a virtual machine designed to make it quick and easy to write portable games, of course being designed in the 70’s the target hardware was not very powerful so screen updates etc. are carried out using XOR so the flashing is noticeable.
The RETRO’s LPC11u24 chip is so fast, I had to significantly slow things down just to ensure the games are playable. Unfortunately the CHIp-8 specification does not define any timings for the VM op codes so there is no target execution speed, in the days this was designed you just ran as fast as possible…
BTW, I will publish the code. But I will need to wait for the RETRO competition to be over since it is using an enhanced version of the display library that I will publish as part of the competition…
But I’m getting a bit scared now, reading you’re holding out better code for the competition.
(Still struggling to create my first Retro game, while you make seven on a shopping day…)
The enhancements to the library are nothing special, just odds and ends that I needed as I was writing the various games for the competition. I am just not releasing the lib yet because the additions are incomplete, I have only written the minimum code I needed for the games, so it is not ready for general consumption. However any bugs or performance enhancements I find I have been integrating back to the live library. I feel a responsibility not to commit any breaking or potentially breaking changes now as I might set someone back with their game development if I cause an unexpected problem in the library.
As for the “seven games”, actually I have a few dozen, but I cheated, I only wrote the emulator. The games are the original Chip-8 games. To answer @ Ian Lee, I will not submit this for the competition since I did not write the actual games.
While I blanch at having to compete with your talents, I don’t see why you shouldn’t submit this. I don’t recall any requirements in the rules that would preclude the emulator as an entry. As long as you’re clear about it, the judges can take the fact that it’s an emulator into account.
But obviously GHI would have the last word as to valid entries.
All that said, I’m guessing you probably have plenty of games up your sleeve other than the CHIP-8 stuff.
Thank you for your care and effort. I appreciate your considerations.
On that point I agree with @ devhammer. As far as I can see it’s up to the judges to see how they qualify your work. It may be that you didn’t write the actual games, but you did create the ability to play them (and led me to read more about Chip-8).
I will probably submit it and see what my mileage I get out of it.
Cool, I hope you found it interesting. I am a little addicted to the retro stuff, I tinker with Z80 assembly, 6502 assembly etc. and stuff like Chip-8 and Forth just gets me super excited, I even wrote an RLP based Forth interpreter for the Hydra, everyone looked at me funny for awhile, but I plan to do one for mbed none the less
It is amazing, some of the games were written as late as 2008, some of the guys even have their own little macro assemblers for Chip-8 and SChip etc.
In principal it is not too complex. Basically you need to emulate the processor and the attached peripherals ie. screen and keyboard/keypad.
Emulating the CPU is probably the major portion of the emulator, basically what a CPU does is pull an instruction from memory, decode the instruction and execute it, move to the next memory location and repeat. So depending on the complexity of the instruction set, this can be very difficult or very easy. In the case of the Chip-8 it is very easy.
Emulating the peripherals varies in complexity depending on the peripheral. Typically the screen and keyboard are relatively easy.
In the case of the screen, read some data from memory and render it to the screen, the application being executed by the emulated CPU would normally write data to a dedicated memory area which is interpreted by the screen peripheral code and rendered. In the case of the Chip-8 it is even simpler, some of the op codes (CPU instructions) just write directly to the screen, so when you decode and execute the instruction you just write to the screen as directed by the instruction.
Handling keyboard input is typically a matter of reading the key presses and putting data into a dedicated memory location for the application to pickup and interpret.
Having said all that, the purists will point out that things start to get more complex when it comes to the details. For example timing each operation based on the physical hardware timing to ensure that the code execution is true to the original etc. but start simple and work your way up to these more complex scenarios.
You can take a look at the original implementation I did for the Game-O, the only real “funny” code there is related to screen updates, these where necessary to improve performance and not really a requirement for the implementation, so it looks more complex than it really is. https://www.ghielectronics.com/community/codeshare/entry/826
I will publish the RETRO version soon, that is written in C/C++ which performs much better so I did not have to do any tricks to get the required performance, in fact I had to explicitly slow the code down. I wrote it is relatively straight forward C so it should be easy to understand.
That GHI will need to respond to, but my assumption would be that it did not sell well enough to warrant its continued production. It is rather niche market, fun but limited to a small subset of projects.
Just to give a bit of background, we went through a restructuring that started in 2013 and ended in 2014. As part of that restructuring we unfortunately had to modify our catalog and discontinue some products.
@ Gary - Is there a way for someone to get hold of it still or is it sent to Oblivion?
@ Taylorza - Cool. So did anyone get around to making a GBA emulator? I’m pushing it here but is the console capable of emulation of such like DOSBOX?
The Game Boy Advanced is built around a Z80 processor, the Z80 has been widely emulated. The LPC11u24 used in the RETRO does not have enough RAM to emulate the GBA, but I would guess something like the GAME-O could handle it if you used native code, I have never taken a detailed look at the specs of the GBA. I have emulated a ZX Spectrum, a Z80 based computer, on the Hydra using native code.
As for DosBox, that is unlikely, it requires 8086 emulation with a number of peripherals, Hercules/CGA/EGA or VGA emulation, programmable timer, programmable interrupt controller etc. etc. I would not say it can’t be done, I have never looked at the details, but it will take quite a bit of processing power asked of the things I can honk of off the top of my head.
[quote=“taylorza”] I have emulated a ZX Spectrum, a Z80 based computer, on the Hydra using native code.[/quote] Ah, that brings back memories. I still have my ZX81 and ZX Spectrum along with ascessories such as Interface 1 and a bunch of tapes. Do you think the less fancy 1kB ZX81 (b&w, no sound) is feasable on the Retro?
That will be interesting to try, my gut feeling is that it might just be possible. I will need to check what the binary size is of the Z80 emulation. I will definitely get back to you on this, might take a few weeks as I only get to tinker over weekends.
Do you visit worldofspectrum.org? I don’t post there, but other than here it is the forum that I read the most, incredible how much activity there still is after all these years.
I haven’t looked at my Spectrum for decades. Thanks for the tip. Plenty to read there.
I found it quite amazing that there is still such an active community for the ZX81. Someone even managed to add a networking interface to it and now has an active ZX81 webserver!
