Gamedev Like it's 1977: CHIP-8

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Gamedev Like it's 1977: CHIP-8

shodanjr_gr: Nov 20, 2007

Is there a place where I can get some CHIP-8 programs that only use the basic instruction set (not any XO-Chip extensions or CHIP-8E)?

I'm writing a baby's first CHIP-8 interpreter in Swift and could use some source material.

# ¿ Nov 21, 2014 19:42

Adbot: ADBOT LOVES YOU

# ¿ May 12, 2024 19:35

shodanjr_gr: Nov 20, 2007

Internet Janitor posted:

Chip8.com has a Program Pack which has a large archive of binaries classified by type- Chip8, Superchip, etc. I've found some bugs and strange assumptions in some of the SuperChip programs in that collection by disassembling them, but the Chip8 roms all seem more or less clean. I believe that most of the Chip8 programs are transcribed directly from the Cosmac VIP Manual.

That's actually an awesome resource! Thanks!

quote:

Also worth noting, Octo will only compile programs with XO-Chip instructions if you opt-in using the options panel and it indicates whether programs it compiles make use of SuperChip or XO-Chip instructions. Many of the examples that come with Octo or were developed during the OctoJam are "clean" and can be used to test a basic Chip8 interpreter. The two features I am intentionally soft on in my emulation are enforcing limits on call stack depth (Octo allows unlimited depth, the real chip8 interpreter capped depth at 12 nested subroutines) and code size (the real chip8 interpreter reserves a couple hundred bytes of high ram for storing its state, modern chip8 interpreters tend to leave that alone and usable by programs).

Actually I've set up my interpret to protect the memory for both the stack and the interpreter-specific memory range ([0,0x200]) but I'd like to have a "modern-mode" toggle that allows access to those + any extended instructions. Also, one of the things I haven't been able to nail down is the location for storage of the font bitmaps. Are they supposed to be dumped in the [0,0x200] range in "proper" CHIP8 implementations or do they go somewhere else?

# ¿ Nov 21, 2014 21:08

shodanjr_gr: Nov 20, 2007

Thanks to Internet Janitor's 8-bit advice the core of my interpreter is working:

Still need to implement timers but I think ill work on the front-end a bit for now.

e:

shodanjr_gr fucked around with this message at 05:28 on Nov 25, 2014

# ¿ Nov 25, 2014 01:38

shodanjr_gr: Nov 20, 2007

toiletbrush posted:

My ObjC Chip-8 interpreter had a bunch of crappy switch statements on opcodes, does Swifts pattern-matchy switches tidy that sort of thing up quite nicely?

Not as far as I can tell...My dispatch loop looks the same as it would look in ObjC...Also I'd say that Swift's type system makes it a bit more cumbersome to work with strongly typed op-codes and memory words since it will not implicitly cast anything to anything else...

However, being able to break into the interpreter loop during execution and REPL to probe memory locations/registers/etc is like magic.

# ¿ Nov 25, 2014 19:03

shodanjr_gr: Nov 20, 2007

I'll put mine on github when I get the core interpreter running well, hook up touch input and have at least a built-in way to mess around with some demos. Haven't had much time to work on it lately but I'm running into issues with the CaveExplorer demo with the position register (V2 iirc) for the sprite drawing overflowing which leads to hilarious things such as:

# ¿ Dec 5, 2014 01:26

shodanjr_gr: Nov 20, 2007

Pollyanna posted:

Markdown code:

- ChipJS has:
  - a 16-level **return stack**
    - essentially a stack of 12-bit addresses like I
    - allows for subroutines

If you're nitpicking the basic Chip8 has a 12-level stack.

quote:

Another question: where do most programs "assume" font data is located? I don't see any regularly defined addresses for the font sprites.

Asked this a few posts ago. The resident CHIP8 expert said:

Internet Janitor posted:

Storing the font(s) in the 0x000-0x200 range is what essentially every modern chip8 interpreter does, and I think it's a safe assumption. If you check out the VIP manual I linked you'll see that the font data was originally stored in the VIP OS rom, outside of chip8's 4k addressing space entirely. Reasonable programs that use the proper font access opcodes shouldn't know or care where that data is stored.

edit: oh, and one more thing- please do NOT use cowgod's technical reference as a source of opcode descriptions. It gets a number of things subtly wrong. Mastering Chip8 is a much more accurate resource. The testquirks.8o program illustrates some of these differences, and in all three of the behaviors Octo is doing what Scaevolus confirmed the original Chip8 interpreter did.

Also, progress! Chip8 for iOS now has a UI:

And can run CaveExplorer:

Purple area is a placeholder view for the keypad.

# ¿ Dec 8, 2014 02:04

shodanjr_gr: Nov 20, 2007

SystemLogoff posted:

I'm being vain, but can I see a screenshot of one of my games from octojam running on your app?

Sure, throw an Octo-style compiled program listing on paste-bin and I'll give it a shot. There's still a few programs that won't run though so don't get your hopes too high :haw:

Internet Janitor posted:

That's coming together really nicely, shodanjr_gr! Have you tried using a nearest-neighbor upscaling routine for the display? Slightly blurry pixels is probably historically accurate for CRT displays, but I think it might look nicer with crisp rectangular pixels.

Thanks

! My wish-list feature is to have an OpenGL-based frame buffer view with support for filters, scan-lines and different CHIP-8 computer modes. As it stands now I'm just generating a UIImage from the frame buffer array, hence the linear upscaling.

# ¿ Dec 8, 2014 04:34

shodanjr_gr: Nov 20, 2007

SystemLogoff posted:

I'm being vain, but can I see a screenshot of one of my games from octojam running on your app?

Using a $900 smartphone for 8-bit Rock Paper Scissors. What has this world come to?

# ¿ Dec 8, 2014 06:06

Adbot: ADBOT LOVES YOU

# ¿ May 12, 2024 19:35

shodanjr_gr: Nov 20, 2007

Internet Janitor posted:

My suggestion would be:

Make your emulator treat illegal instructions as a halt. Octo treats 0x0000 (which is technically call machine code at address 0x000 but that is useless) this way, which works out especially conveniently because that's also what uninitialized memory immediately following your program looks like.

Write your test programs so that when behaving properly they will eventually execute such a halt instruction.

Implement your test framework to execute programs a cycle at a time and if your programs keep running after an unreasonable maximum number of ticks (say 50,000 instructions) they time out and are treated as failing.

If you don't like using 0x0000 as a halt instruction you could also look for a jump to the address of itself (in octo loop again) which is trivially detectable as an infinite loop because nothing could possibly alter its behavior. You can really tie yourself in knots dreaming up more complicated heuristics or rules of this sort but they'll never generalize. Keep it simple. Testing input is inherently fiddly and probably needs a different strategy if it's worth automated testing at all.

That's how I'm handling things in my interpreter as well and seems to be working fine so far.

# ¿ Dec 19, 2014 10:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Gamedev Like it's 1977: CHIP-8