CHIP-8 interpreter on NES! (expansion RAM)

I threw this together in a day, somewhat based on my Conway's Life code. It's set to use MMC1 but doesn't actually write to any MMC1 registers, only using it for the extra RAM emulators grant it.

This demo runs breakout, using left and right to move the paddle. You could replace it with something else, though Blinky wouldn't run when I tried.

One big problem I ran into is that despite the sprite drawing being incredibly inefficient (calls a routine for every single pixel that should be flipped), games still run way too fast. If games actually used the timer it would be fine, but many don't seem to, so I need some sort of instruction limiter. This ROM just runs one instruction per frame.

This is the last piece of the puzzle. Thank you for building it. I hereby offer to donate money to the first person to make a video of running a CHIP-8 game in this interpreter in PocketNES in VBA GX in Dolphin in VirtualBox. Bwonng!

As for speed: How fast does the original CHIP-8 interpreter run on an RCA 1802?

That's cool! I figured it wouldn't be hard to get CHIP-8 games running, but this was extremely quick! And holy crap, 1 instruction per frame and games still work OK? That's insane!

The main problem speed-wise is that all graphics are drawn with XOR, so everything moving tends to flicker, and you need to be able to catch it when it's actually displaying. I was having problems where the ball was just invisible at high speeds. The interpreter also can't update the screen in a single frame, and it needs two, because of how many tiles it needs to draw. Maybe I could OR some frames together and display that to minimize flicker?

Here's a faster version that, instead of waiting a frame every instruction, waits two frames every draw instruction instead, to make sure every change is visible. Makes Breakout way more like an actual game, and from what I can tell the original interpreter added a delay after drawing too.

Still would be good to reduce flicker if I can.

Yeah, the main issue with CHIP-8 and flicker is that anything that moves must be erased and drawn again, so if you update the screen after an object is erased but before it's drawn again, you get flicker.

One solution I've seen was to not update the screen until a few instructions have passed since the last DRAW command. This would in theory give the game time to move all it's objects, or at very least not render frames where objects are invisible.

With so much free screen space, you could use some forced blanking to update the entire playfield at 60Hz, or you could use the second name table for double buffering and do it at 30Hz.

Yo dawg, it looks like it's been done on Super NES too now. See Super Chip8x

Does this have anything to do with my thread?

Mine was, hence the intentionally similar thread title. I wanted to show how easy it would be to just knock out a simple interpreter if extra RAM was used, so I just went and did that in a day.