Yet Another CHIP-8 Interpreter (YACI) Project

Just because we are in great faulty of CHIP-8 interpreters (sarcasm), I proposed myself to write a (Super) CHIP-8 from scratch as a project to help me gain knowledge about emulators and that stuff. The cool thing? I'm not writing it right now. I plan to bundle with it a functional (Super) CHIP-8 assembler as a program to tinker with. So... progress? I've already implemented some of the opcodes (with a big, ugly giant mess of IFs) and they output correctly (as far as my reference sheet can tell). By keeping the coding pace I've been keeping this days (except today), I plan to get it to a usable stage and release it by next week. I'll post some updates and screenshots in this thread of the assembler (and the emulator aswell).

compile chip-8 to sb bytecode

Be careful, there is a lot of incorrect documentation (particularly the 2 most popular: http://devernay.free.fr/hacks/chip8/C8TECH10.HTM and http://mattmik.com/files/chip8/mastering/chip8.html) The most accurate I've found is http://laurencescotford.co.uk/?p=242 Be careful about left/right shift, and any instruction that uses the I register as input (some of them modify its value, others don't)

compile chip-8 to sb bytecode

compile chip-8 to HQ9+

compile chip-8 to sb bytecode

compile chip-8 to HQ9+

would be possible if we add an instruction (λ) which calls SB code, the accumulator points to a SB instruction pointer, and the stack is actually the combination of HQ9 commands before a λ and after the last call of λ

would be possible if we add an instruction (λ) which calls SB code, the accumulator points to a SB instruction pointer, and the stack is actually the combination of HQ9 commands before a λ and after the last call of λ

and the output would be the normal hq9 output and the sb code output would be outputted to an output file aaaa i feel nausea i need to sleep

Be careful, there is a lot of incorrect documentation (particularly the 2 most popular: http://devernay.free.fr/hacks/chip8/C8TECH10.HTM and http://mattmik.com/files/chip8/mastering/chip8.html) The most accurate I've found is http://laurencescotford.co.uk/?p=242 Be careful about left/right shift, and any instruction that uses the I register as input (some of them modify its value, others don't)

Luckily, didn't use any of those pages :p The one you linked as accurate seems indeed pretty accurate (lol), I'll be definitely saving it in my bookmarks. Thanks!

Be careful, there is a lot of incorrect documentation (particularly the 2 most popular: http://devernay.free.fr/hacks/chip8/C8TECH10.HTM and http://mattmik.com/files/chip8/mastering/chip8.html) The most accurate I've found is http://laurencescotford.co.uk/?p=242 Be careful about left/right shift, and any instruction that uses the I register as input (some of them modify its value, others don't)

Luckily, didn't use any of those pages :p The one you linked as accurate seems indeed pretty accurate (lol), I'll be definitely saving it in my bookmarks. Thanks!

It's definitely worth adding emulator settings/quirksmodes because a lot of modern ROMs may have been written assuming inaccurate emulation (and it increases the versatility and use of the emulator as it is.)

Perhaps, but that basically just encourages people to continue writing broken software.

You turn them off by default And CHIP8 has never had an implementation that isn't software anyway

This program compiles and runs correctly! (I added a few console output opcodes for testing...)

Output.

I haven't implemented some opcodes but the assembler is complete (I guess). Key: [QKN4J323]

Also some of the opcodes implementation may not be correct, since I wrote most of them without reference. I also haven't added any kind of Super CHIP-8 support, but I plan to do it when I finish the main emulator

Also x2: the output from the assembler won't work with the other emulators in here, since the assembler packs 4 bytes in an array element, as opposed to the 2 padded bytes per element (i guess) in the other emulators. Shouldn't be so hard to convert though'

What is the point of packing 4 bytes into each integer? You're only saving 12KB of RAM, at the cost of slower and more complicated code

What is the point of packing 4 bytes into each integer? You're only saving 12KB of RAM, at the cost of slower and more complicated code

Well the original motivation was the memory saving... :p

I just noticed something about the call stack that I hadn't thought about before. From http://laurencescotford.co.uk/?p=75:

First up is the stack. This occupies the 48 bytes from 0x06A0 to 0x06CF. This is sufficient to allow 12 levels of nested subroutines. The stack is filled from 0x6CF downwards.

If you try to call more than 12 nested subroutines, the stack will just extend into the program space. As long as the code isn't too long, that will normally be fine. though I suppose technically this should be considered "undefined behavior" (and besides, when would you ever need more than 12 nested calls?), so it probably isn't important.

The More You Know™ I thought stack was populated left to right.