3

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?

  • Since the hardware runs at 1.76 MHz and two bytes need to be fetched from RAM for one CHIP-8 instruction, I guess the ultimate upper limit would be 880 kHz but that doesn't really leave room for the actual interpretation of those two bytes... – Cactus Jul 19 at 15:16
3

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?

| improve this answer | |
6

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.

| improve this answer | |
  • I wasn't aware that DRAW (and I presume CLS as well?) wait for a vblank! Do you have a reference for that? – Cactus Jul 21 at 11:02
  • @Cactus: I don't have the code for the COSMAC Chip-8 handy, but I've studied it in the past. Further, if one watches the performance of screen drawing, it's apparent. – supercat Jul 21 at 14:43
  • 2
    @Cactus Yes. Look at memory address $00AC in this disassembly of COSMAC VIP's CHIP-8 interpreter: web.archive.org/web/20190819144645/http://… (interestingly, CLS does not wait for an interrupt) – tobiasvl Jul 21 at 21:29
  • 1
    @tobiasvl: The clear-screen loop takes 12 cycles per byte to clear 256 bytes , and there are about 1800 cycles available for user code to execute between frames. There's no way the clear-screen routine as implemented will complete in a single frame. – supercat Jul 21 at 22:07
  • 1
    @tobiasvl: If code had done something like CLS: ldi 255 / plo b / sex b / clsLoop: ghi 3 / std / std / std / glo b / bnz clsLoop/ stm b / sep 4 to cut the time to 12 cycles every three bytes, making it possible to clear the screen in one frame, then waiting for a frame boundary might make sense, but when the code takes more than a frame to complete that becomes far less relevant. – supercat Jul 21 at 22:29
2

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.