I asked a question here about CHIP-8 instruction timing, and this answer mentions that
DRAW waits for vblank:
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
Trying to dig deeper into this, I got this helpful comment:
@Cactus Yes. Look at memory address $00AC in this disassembly of COSMAC VIP's CHIP-8 interpreter: http://web.archive.org/web/20190819144645/http://laurencescotford.co.uk/wp-content/uploads/2013/08/CHIP-8-Interpreter-Disassembly.pdf (interestingly, CLS does not wait for an interrupt)
What is still unclear to me is whether this means that each individual
DRAW instruction will wait for a full frame, or just that they will stall execution until the vertical blanking area is reached?
In other words, suppose I have a sequence of
DRAW instructions. Will the first one stall the bytecode interpreter until we reach vblank and then they all will execute quickly, or will the first one take a full 1/60th of a second, then the second one will take another 1/60th of a second, and so on? Does that mean it is impossible to change more than one 8x16 rectangle of the screen per frame?
Edit: hopeful clarification of my question: suppose I have the following sequence of instructions:
DRAW v0 v1 1 DRAW v0 v1 1 ... DRAW v0 v1 1
60 times total. Is this going to take a whole second on the original CHIP-8, or is this going to take until the end of the current frame and then however long it takes to change these 60 bytes?
(If it matters, my angle for this question is that I am working on a book where one of the chapters implements a CHIP-8 machine on an FPGA. So there are at least two goals here:
- I'd like to describe the intended behaviour of the
- I'd like to implement
DRAWsuch that it is compatible with the existing corpus of CHIP-8 software.)