Effective speed of original COSMAC VIP CHIP-8 interpreter

Question

The original CHIP-8 interpreter ran on RCA 1802-based kit computers and home computers, most notably on the COSMAC VIP. Some of the CHIP-8 opcodes are complicated and involve many memory round-trips, for example the drawing instructions, or the ones that store register values in RAM. However, many of them are straightforward register-to-register operations which can be implemented fairly uniformly in a bytecode interpreter: just fetch the bytes, switch on the relevant parts of it to jump to the right operation, then do the operation.

For this second kind of "regular", "atomic" operations, I think it should be meaningful to assign a single number to the effective interpretation rate, i.e. on average restricted to these operations, how many CHIP-8 bytecode instructions could the original interpreter run per second on the COSMAC VIP?

Answer 1

This is the best reference I know of concerning timing in the CHIP-8 interpreter for COSMAC VIP: Chip 8 Instruction Scheduling and Frequency

To understand the reasons for the timings here, you'll need to look at a disassembly of the interpreter. Sadly, the website mentioned in the link above (Laurence Scotford's blog) is down, but some of the pages (but not all) are available at the Internet Archive's WayBackMachine.

One reason is of course that the CHIP-8 registers aren't really registers, but just memory locations. So each time the interpreter looks up a register, it needs to add the register number as an offset to the memory location of register V0. In addition, instructions in the $8XYN range are decoded and dispatched to the 1802 CPU's ALU, which is why they have uniform timing. Perhaps those would make for an OK baseline?

Answer 2

For Chip-8 code that draws anything, the limiting factor will be the wait-for-vblank that is built into all of the draw operations, which will limit speed to 60 draw-sprite operations per second regardless of anything else that's going on. I don't know how much Chip-8 code wouldn't benefit from being run "as fast as possible" outside of the operations that are bound by frame rate. The language would could have accommodated much better games if it had separated out "wait for vblank" and "draw sprite" actions, so as to draw more than one sprite per frame, but it is what it is, and its the fact that every draw operation takes one frame should simplify emulation timing.

Answer 3

From what I remember when I disassembled the ROM of my HUG1802 back in 1981, the Chip-8 interpreter is actually quite efficient - which it needs to be because the CPU is very slow and the display system makes it even slower.

The CDP1802 takes 8 clock cycles per CPU cycle, and most instructions take 2 cycles (a few take 3). Although the CPU can be clocked as high as 3.2 MHz on 5V, the CDP1861 video display controller requires it run at 1.76 MHz. At this frequency it is roughly equivalent to a 6502 running at 200 kHz. As if that wasn't bad enough, the CDP1861 imposes severe restrictions on what instructions can be executed during video line display, tying the CPU up for ~50% of the video frame time.

The most accurate way to time the Chip-8 instructions would be to run them on an actual machine, but that might not be practicable. You could test the timing in an emulator, but if it is not cycle accurate (including video display) the results may not be very useful.

Another way would be to disassemble the ROM and count instructions. This should be very accurate if done right, but time consuming. I found a source code listing for another implementation of Chip-8 on the 1802 here. I don't know how close this is to the timing of the original, but it does include the interrupt and display DMA code which you would need to calculate the average processing time with video display on.