You can still apply different palettes to different elements on the screen, even if each element only uses 1 bit per pixel. It just means that each palette can only have two colors.
Tobias V. Langhoff
Creator of
Recent community posts
Hey! It seems that both the GB and GBC versions run fine on a regular GB (DMG), so I'm a little confused as to why there are two different versions? The GBC version and the GB version look identical to me when running on a GB.
However, the GB version doesn't seem to work on a GBC - after the initial fade, the screen remains black, so there seem to be some palette issues there. But, again, I'm not sure what the GB version is really for, since the GBC version runs on a GB.
(The reason I wanted to try the GB version on a GBC was to play around with different palettes, so that could be one reason for its existence!)
Of course, that'd be cool! https://itch.io/jam/octojam-8/rate/491494
This is great! And super hard!
It was completely unplayable for me with the default cursor speed, as it was impossible for me to move the cursor only one step at a time, but when I turned it down to 1 or 2 it worked great.
I wonder if it'd be possible to add mouse control, or if that'd make it too easy (navigating the cursor around with the keyboard does add its own challenge). But with mouse support and potentially a browser version for a lower barrier of entry, I think this could be a hit.
I wrote an article on how to get CHIP-8 up and running on one of these beauts: https://tobiasvl.github.io/blog/chip-8-hp-48/
You are correct in that `i ` pointed to real memory locations, and that programs start at 0x200 because the CHIP-8 interpreter was using that RAM on the COSMAC VIP. However, on the VIP, the font characters weren't located in the interpreter, but in the VIP's own OS or monitor program (CHIP-8 simply reused the VIP's font). The original CHIP-8 specification didn't specify where the font was (or should be) located, so in a way it was "abstracted" away. The value of `i` after using the font opcode was, in a sense, undefined.
Modern interpreters do it differently. Somewhere along the line, people decided to put the font in the now unpopulated memory region that used to be occupied by the interpreter. After all, why not, if the spec doesn't say where it should be?
Not quite; the screen memory was not located in the first 512 bytes. (Neither was the font, which was in the VIP OS.) That only contained the interpreter code itself, but no variables. On the COSMAC VIP, the 256 bytes of screen/frame buffer were located in the last 352 of the addressable memory, along with variables for the V and I "registers" and other data. This location changed depending on how much memory the VIP had, which is probably one reason it wasn't included in the spec.
There were in fact even some "hires" CHIP-8 interpreters for the COSMAC VIP, such as "CHIP-10". That was unproblematic, as long as the VIP had enough memory. Although, the way the "Pixie" video chip worked, the resolution was 64x128 instead of 128x64 (because each pixel was fewer scanlines tall).
It simply wasn't part of the original interpreter spec.
Other implementations (including CHIP-48 and SCHIP) didn't put the screen memory (and other stuff) at the same locations. Any program that relies on the screen memory location would only work in that specific interpreter. (Some early CHIP-8 games for the VIP might rely on this.)
In fact, the location of the screen memory changed in the original COSMAC VIP interpreter based on how much memory the computer had, since the interpreter's variables (including the screen memory) was always lcoated at the end of the addressable memory space.
Cool! I made two games last year that targeted the original COSMAC VIP CHIP-8 implementation, and I'm working on another now. Historical accuracy is definitely one of the things I enjoy most in Octojam.
"Sprite drawing trigger vblank" means that when Octo encounters a `sprite` instruction, it will then halt and wait for the next frame is drawn before continuing execution, so drawing sprites will be a bottleneck for speed.
I think 7 or 15 cycles per frame is reasonable. It's all an approximation, of course, since in Octo all instructions take one "cycle" (AFAIK) while it varies between instructions on COSMAC VIP. Here's a table of real-world timing for each instruction.
The best approach is probably to test your game in the Emma02 emulator, which emulates the COSMAC VIP faithfully. As far as I remember it's a little hard to understand how to use it though.
The jam has started! Has anyone started? Do you have any ideas?
I have a few ideas. This year my goal is to make on CHIP-8 game targeted at the COSMAC VIP, one SUPER-CHIP game targeted at the HP48 calculators, and one XO-CHIP game. I made two CHIP-8 games that ran on original COSMAC VIP hardware last year, and that was great fun. (I also like turn-based stuff and puzzle games anyway, which is well suited for that.)
I'm so stoked for Octojam, I put together a little keypad, inspired by the COSMAC VIP's keypad, to play this year's games with:
It's a BM-16A PCB and case, purchased from KPRepublic. I had to solder in switches myself (I put in some Zealios Zilent switches I had lying around for a tactile feel). The keycaps are a DSA Mono-Color keyset for an ortholinear layout from Pimp My Keyboard (Signature Plastics); the DSA profile means the keycaps are all the same height, and the ortholinear set comes without sublegends on the numeric keys.
I then programmed the keypad using the open source QMK firmware, and mapped the keys to the Octo layout (ie. 1234qwerasdfzxcv).
Time to play some CHIP-8 games!
Thank you! I definitely think I can do more interesting things with the concept, but sadly I didn't have time for much level design or to develop the concept further.
In retrospect I agree on the red+green color choice – those tiles are actually from a classic (now public domain) puzzle game called Laser Tank, which I've played a lot, so I guess I've just gotten used to the colors over the years, haha.