{"id":"gen-1785796520-tQRy1b0rv5dCf93J3cJT","choices":[{"finish_reason":"stop","index":0,"logprobs":null,"message":{"content":"# CHIP-8 “CPU” Specification Sheet\n\n## 1. Scope and Terminology\n\nCHIP-8 is best described as a **bytecode virtual machine / interpreted instruction set**, not a physical CPU. The term “CPU” is commonly used for the virtual processor state and execution model implemented by a CHIP-8 interpreter.\n\nThis document specifies the classic CHIP-8 virtual CPU, memory model, instruction set, display, keypad, timers, and compatibility quirks.\n\n> **Note:** Historical CHIP-8 implementations have several ambiguities. This specification identifies a practical reference behavior and calls out common quirks where implementations differ.\n\n---\n\n## 2. General Description\n\n| Property | Value |\n|---|---|\n| Architecture class | Interpreted 16-bit opcode virtual machine |\n| Data width | 8-bit |\n| Address space | 4096 bytes, `0x000`–`0xFFF` |\n| Program origin | `0x200` |\n| General-purpose registers | 16 × 8-bit, `V0`–`VF` |\n| Index register | 16-bit `I`, effective address usually masked to 12 bits |\n| Program counter | 16-bit `PC`, effective address usually masked to 12 bits |\n| Stack | 16 return-address entries |\n| Timers | 2 × 8-bit, decrement at 60 Hz |\n| Display | 64 × 32 pixels, 1-bit monochrome |\n| Input | 16-key hexadecimal keypad, keys `0x0`–`0xF` |\n| Sound | Single buzzer/beeper, active while sound timer is nonzero |\n| Opcode size | 16 bits |\n| Opcode endianness | Big-endian |\n| Instruction rate | Not strictly defined; commonly 500–1000 instructions/second |\n\n---\n\n## 3. Architectural Block Diagram\n\n```text\n +-----------------------------------+\n | CHIP-8 VM |\n | |\n | +---------+ +---------+ |\n Opcode fetch <--|-- | PC | | Stack | |\n | +---------+ +---------+ |\n | | ^ |\n | v | |\n | +---------+ +---------+ |\n Memory <--------|-- | Decoder |<------>| CU | |\n | +---------+ +---------+ |\n | | | |\n | v v |\n | +---------+ +---------+ |\n | | V0..VF |<----->| ALU | |\n | +---------+ +---------+ |\n | | | |\n | v v |\n | +---------+ +---------+ |\n | | I | | Timers | |\n | +---------+ +---------+ |\n | | | |\n +--------|------------------|-------+\n | |\n v v\n +-----------+ +-----------+\n | 4 KiB RAM | | 60 Hz tick|\n +-----------+ +-----------+\n\n +-----------+ +-----------+\n | 64x32 FB | | 16-key |\n +-----------+ +-----------+\n```\n\n---\n\n## 4. Memory Model\n\n### 4.1 Address Space\n\n| Address Range | Size | Typical Use |\n|---|---:|---|\n| `0x000`–`0x1FF` | 512 bytes | Interpreter reserved area, often font sprites |\n| `0x200`–`0xFFF` | 3584 bytes | Program code, data, stack, variables |\n\nCHIP-8 programs are normally loaded at address `0x200`.\n\n### 4.2 Endianness\n\nCHIP-8 instructions are 16 bits wide and stored big-endian.\n\n```text\nAddress N+0: high byte\nAddress N+1: low byte\n```\n\nExample:\n\n```text\nMemory:\n0x200: 0x12\n0x201: 0x30\n\nOpcode fetched = 0x1230\n```\n\n### 4.3 Effective Address Masking\n\nThe physical CHIP-8 memory is only 4096 bytes. Although `I` and `PC` may be implemented as 16-bit values, effective memory accesses should normally use:\n\n```text\neffective_address = address & 0xFFF\n```\n\nThis applies to opcode fetches, sprite reads, register store/load operations, and BCD writes.\n\n---\n\n## 5. Programmer-Visible Registers\n\n### 5.1 Register File\n\n| Register | Width | Description |\n|---|---:|---|\n| `V0`–`VE` | 8-bit | General-purpose registers |\n| `VF` | 8-bit | General-purpose register and flag register |\n| `I` | 16-bit | Index/register address pointer |\n| `PC` | 16-bit | Program counter |\n| `SP` | 8-bit or implementation-defined | Stack pointer |\n| `DT` | 8-bit | Delay timer |\n| `ST` | 8-bit | Sound timer |\n\n### 5.2 `VF` Flag Usage\n\n`VF` is both a general-purpose register and a status flag. Its value may be overwritten by ordinary register operations. Flag-producing instructions define its value explicitly.\n\n| Operation | `VF` Meaning |\n|---|---|\n| `8XY4` ADD | Set to `1` if there is a carry, otherwise `0` |\n| `8XY5` SUB | Set to `1` if there is no borrow, otherwise `0` |\n| `8XY7` SUBN | Set to `1` if there is no borrow, otherwise `0` |\n| `8XY6` SHR | Set to least significant bit before shift |\n| `8XYE` SHL | Set to most significant bit before shift |\n| `DXYN` DRW | Set to `1` if drawing erases any pixel, otherwise `0` |\n| `FX1E` ADD I | Optionally set on 12-bit overflow in some implementations |\n| Logical ops `8XY1`–`8XY3` | Modern implementations often clear `VF` to `0` |\n\nFor instructions not listed above, `VF` is either unchanged or implementation-defined unless otherwise stated.\n\n---\n\n## 6. Stack\n\nCHIP-8 provides a call/return stack with a nominal depth of 16 entries.\n\n### 6.1 Stack Behavior\n\nEach stack entry stores a return address.\n\nA typical implementation uses:\n\n```text\nstack[16]\nSP = 0\n```\n\n#### CALL\n\n```text\nstack[SP] = PC\nSP = SP + 1\nPC = nnn\n```\n\n#### RET\n\n```text\nSP = SP - 1\nPC = stack[SP]\n```\n\n### 6.2 Stack Pointer Semantics\n\nThis specification assumes `SP` points to the next free stack slot before a push.\n\nOther equivalent conventions exist, but observable behavior should match:\n\n- `CALL` stores the address of the instruction after the `CALL`.\n- `RET` returns to that stored address.\n- Maximum nominal nesting depth is 16 calls.\n\n### 6.3 Stack Overflow / Underflow\n\nBehavior on stack overflow or underflow is historically undefined.\n\nRecommended implementation behavior:\n\n| Condition | Recommended Behavior |\n|---|---|\n| Stack overflow | Ignore push, trap, or halt; do not corrupt memory |\n| Stack underflow | Ignore pop, trap, or halt; do not corrupt memory |\n\n---\n\n## 7. Reset and Initial State\n\nA reference CHIP-8 interpreter should initialize the virtual machine as follows:\n\n| State | Reset Value |\n|---|---|\n| `PC` | `0x200` |\n| `I` | `0x000` |\n| `SP` | `0x000` |\n| `V0`–`VF` | `0x00` recommended |\n| `DT` | `0x00` |\n| `ST` | `0x00` |\n| Memory | Undefined except interpreter/font area |\n| Display | Cleared to black |\n| Keys | All released |\n| Sound | Off |\n\nSome programs may rely on uninitialized memory or registers, but well-behaved software should not assume any particular pre-initialized RAM content.\n\n---\n\n## 8. Opcode Encoding\n\nAll CHIP-8 instructions are 16 bits.\n\n### 8.1 Generic Fields\n\n```text\n15 12 11 8 7 4 3 0\n+----------+----------+----------+----------+\n| opcode | x | y | n |\n+----------+----------+----------+----------+\n| opcode + kk |\n+----------+----------+----------+----------+\n| opcode + nnn |\n+----------+----------+----------+----------+\n```\n\n| Field | Width | Meaning |\n|---|---:|---|\n| `opcode` | 4 bits or more | Primary operation code |\n| `x` | 4 bits | Source/destination register `Vx` |\n| `y` | 4 bits | Secondary register `Vy` |\n| `n` | 4 bits | Small constant, often sprite height |\n| `kk` | 8 bits | Immediate byte |\n| `nnn` | 12 bits | Address |\n\n### 8.2 Program Counter Behavior\n\nA common execution sequence is:\n\n```text\nopcode = memory[PC] << 8 | memory[PC + 1]\nPC = (PC + 2) & 0xFFF\nexecute(opcode)\n```\n\nInstructions that skip the next instruction advance `PC` by an additional 2 bytes.\n\nInstructions that jump or call overwrite `PC`.\n\n---\n\n## 9. Instruction Set Summary\n\n### 9.1 Opcode Table\n\n| Opcode | Mnemonic | Operation | Notes |\n|---|---|---|---|\n| `0NNN` | `SYS nnn` | Historically calls RCA 1802 machine code at `nnn` | Usually ignored/no-op in modern CHIP-8 |\n| `00E0` | `CLS` | Clear display | Framebuffer set to black |\n| `00EE` | `RET` | Return from subroutine | Pops return address |\n| `1NNN` | `JP nnn` | `PC = nnn` | Unconditional jump |\n| `2NNN` | `CALL nnn` | Push `PC`, then `PC = nnn` | Subroutine call |\n| `3XNN` | `SE Vx, kk` | If `Vx == kk`, skip next instruction | Compare immediate |\n| `4XNN` | `SNE Vx, kk` | If `Vx != kk`, skip next instruction | Compare immediate |\n| `5XY0` | `SE Vx, Vy` | If `Vx == Vy`, skip next instruction | Compare registers |\n| `6XNN` | `LD Vx, kk` | `Vx = kk` | Load immediate |\n| `7XNN` | `ADD Vx, kk` | `Vx = Vx + kk` | No carry flag; wraps mod 256 |\n| `8XY0` | `LD Vx, Vy` | `Vx = Vy` | `VF` usually unchanged |\n| `8XY1` | `OR Vx, Vy` | `Vx = Vx OR Vy` | Modern implementations often set `VF = 0` |\n| `8XY2` | `AND Vx, Vy` | `Vx = Vx AND Vy` | Modern implementations often set `VF = 0` |\n| `8XY3` | `XOR Vx, Vy` | `Vx = Vx XOR Vy` | Modern implementations often set `VF = 0` |\n| `8XY4` | `ADD Vx, Vy` | `Vx = Vx + Vy`; `VF = carry` | Carry if result > `0xFF` |\n| `8XY5` | `SUB Vx, Vy` | `VF = 1` if `Vx >= Vy`; `Vx = Vx - Vy` | No-borrow flag |\n| `8XY6` | `SHR Vx` | `VF = Vx & 1`; `Vx >>= 1` | Some variants shift `Vy` instead |\n| `8XY7` | `SUBN Vx, Vy` | `VF = 1` if `Vy >= Vx`; `Vx = Vy - Vx` | No-borrow flag |\n| `8XYE` | `SHL Vx` | `VF = (Vx >> 7) & 1`; `Vx <<= 1` | Some variants shift `Vy` instead |\n| `9XY0` | `SNE Vx, Vy` | If `Vx != Vy`, skip next instruction | Compare registers |\n| `ANNN` | `LD I, nnn` | `I = nnn` | Load index register |\n| `BNNN` | `JP V0, nnn` | `PC = nnn + V0` | Jump offset by `V0` |\n| `CXNN` | `RND Vx, kk` | `Vx = random() & kk` | Random source unspecified |\n| `DXYN` | `DRW Vx, Vy, n` | Draw sprite at `(Vx, Vy)`; `VF = collision` | Sprite from memory at `I` |\n| `EX9E` | `SKP Vx` | If key `Vx` is pressed, skip next instruction | Key index masked to `0xF` |\n| `EXA1` | `SKNP Vx` | If key `Vx` is not pressed, skip next instruction | Key index masked to `0xF` |\n| `FX07` | `LD Vx, DT` | `Vx = DT` | Read delay timer |\n| `FX0A` | `LD Vx, K` | Wait for keypress, store key in `Vx` | Blocking instruction |\n| `FX15` | `LD DT, Vx` | `DT = Vx` | Set delay timer |\n| `FX18` | `LD ST, Vx` | `ST = Vx` | Set sound timer |\n| `FX1E` | `ADD I, Vx` | `I = I + Vx` | Optional overflow flag quirk |\n| `FX29` | `LD F, Vx` | `I = font_sprite_address(Vx & 0xF)` | Sets `I` to digit font |\n| `FX33` | `BCD Vx` | Store BCD of `Vx` at `I`, `I+1`, `I+2` | Hundreds, tens, ones |\n| `FX55` | `LD [I], V0..Vx` | Store registers `V0` through `Vx` at `I` | `I` update behavior is quirk-sensitive |\n| `FX65` | `LD V0..Vx, [I]` | Load registers `V0` through `Vx` from `I` | `I` update behavior is quirk-sensitive |\n\n---\n\n## 10. Detailed Instruction Semantics\n\n### 10.1 System and Control\n\n#### `0NNN` — `SYS nnn`\n\nHistorically used to call a native RCA 1802 machine-language routine.\n\nRecommended modern behavior:\n\n```text\nno operation\n```\n\n#### `00E0` — `CLS`\n\nClears the display.\n\n```text\nframebuffer = all pixels off\n```\n\nDoes not normally affect registers.\n\n#### `00EE` — `RET`\n\nReturns from a subroutine.\n\n```text\nSP = SP - 1\nPC = stack[SP]\n```\n\n#### `1NNN` — `JP nnn`\n\nUnconditional jump.\n\n```text\nPC = nnn\n```\n\n#### `2NNN` — `CALL nnn`\n\nCalls a subroutine.\n\n```text\nstack[SP] = PC\nSP = SP + 1\nPC = nnn\n```\n\nThe stored return address should be the address of the instruction following the `CALL`.\n\n#### `BNNN` — `JP V0, nnn`\n\nJump to address offset by `V0`.\n\n```text\nPC = (nnn + V0) & 0xFFF\n```\n\n---\n\n### 10.2 Skip Instructions\n\nSkip instructions skip the following instruction by adding an extra 2 to `PC`.\n\n#### `3XNN` — `SE Vx, kk`\n\n```text\nif Vx == kk:\n PC = PC + 2\n```\n\n#### `4XNN` — `SNE Vx, kk`\n\n```text\nif Vx != kk:\n PC = PC + 2\n```\n\n#### `5XY0` — `SE Vx, Vy`\n\n```text\nif Vx == Vy:\n PC = PC + 2\n```\n\n#### `9XY0` — `SNE Vx, Vy`\n\n```text\nif Vx != Vy:\n PC = PC + 2\n```\n\n---\n\n### 10.3 Load and Arithmetic Instructions\n\nAll 8-bit arithmetic is modulo 256 unless a flag condition is specified.\n\n#### `6XNN` — `LD Vx, kk`\n\n```text\nVx = kk\n```\n\n#### `7XNN` — `ADD Vx, kk`\n\n```text\nVx = (Vx + kk) & 0xFF\n```\n\n`VF` is unchanged.\n\n#### `8XY0` — `LD Vx, Vy`\n\n```text\nVx = Vy\n```\n\n`VF` is normally unchanged.\n\n#### `8XY1` — `OR Vx, Vy`\n\n```text\nVx = Vx | Vy\n```\n\nModern implementations commonly clear `VF` to `0`.\n\nHistorical implementations may leave `VF` unchanged.\n\n#### `8XY2` — `AND Vx, Vy`\n\n```text\nVx = Vx & Vy\n```\n\nModern implementations commonly clear `VF` to `0`.\n\nHistorical implementations may leave `VF` unchanged.\n\n#### `8XY3` — `XOR Vx, Vy`\n\n```text\nVx = Vx ^ Vy\n```\n\nModern implementations commonly clear `VF` to `0`.\n\nHistorical implementations may leave `VF` unchanged.\n\n#### `8XY4` — `ADD Vx, Vy`\n\n```text\nsum = Vx + Vy\nVx = sum & 0xFF\nVF = 1 if sum > 0xFF else 0\n```\n\n#### `8XY5` — `SUB Vx, Vy`\n\n```text\nVF = 1 if Vx >= Vy else 0\nVx = (Vx - Vy) & 0xFF\n```\n\n`VF = 1` indicates no borrow.\n\n#### `8XY6` — `SHR Vx`\n\nReference behavior:\n\n```text\nVF = Vx & 1\nVx = Vx >> 1\n```\n\nCommon quirk:\n\n```text\nVF = Vy & 1\nVx = Vy >> 1\n```\n\nThis quirk is sometimes called the “shift Vy” quirk.\n\n#### `8XY7` — `SUBN Vx, Vy`\n\n```text\nVF = 1 if Vy >= Vx else 0\nVx = (Vy - Vx) & 0xFF\n```\n\n`VF = 1` indicates no borrow.\n\n#### `8XYE` — `SHL Vx`\n\nReference behavior:\n\n```text\nVF = (Vx >> 7) & 1\nVx = (Vx << 1) & 0xFF\n```\n\nCommon quirk:\n\n```text\nVF = (Vy >> 7) & 1\nVx = (Vy << 1) & 0xFF\n```\n\nThis quirk is sometimes called the “shift Vy” quirk.\n\n---\n\n### 10.4 Index Register Instructions\n\n#### `ANNN` — `LD I, nnn`\n\n```text\nI = nnn\n```\n\n#### `FX1E` — `ADD I, Vx`\n\n```text\nI = I + Vx\n```\n\nSome implementations set `VF = 1` if `I + Vx > 0xFFF`, otherwise `VF = 0`.\n\nMany implementations leave `VF` unchanged.\n\nMemory accesses using `I` should still mask to 12 bits unless the implementation intentionally supports a larger address space.\n\n#### `FX29` — `LD F, Vx`\n\nSets `I` to the address of the built-in hexadecimal font sprite for digit `Vx & 0xF`.\n\n```text\ndigit = Vx & 0xF\nI = font_base + digit * 5\n```\n\nEach digit sprite is 5 bytes high and 8 pixels wide.\n\n---\n\n### 10.5 Memory and BCD Instructions\n\n#### `FX33` — `BCD Vx`\n\nStores the binary-coded decimal representation of `Vx` in memory.\n\n```text\nmemory[(I + 0) & 0xFFF] = Vx / 100\nmemory[(I + 1) & 0xFFF] = (Vx / 10) % 10\nmemory[(I + 2) & 0xFFF] = Vx % 10\n```\n\nExample:\n\n```text\nVx = 123\n\nmemory[I + 0] = 1\nmemory[I + 1] = 2\nmemory[I + 2] = 3\n```\n\n#### `FX55` — `LD [I], V0..Vx`\n\nStores registers `V0` through `Vx` in memory starting at address `I`.\n\nReference modern behavior:\n\n```text\nfor i = 0 to x:\n memory[(I + i) & 0xFFF] = V[i]\n```\n\n`I` is left unchanged.\n\nHistorical/quirk behavior:\n\n```text\nI = (I + x + 1) & 0xFFF\n```\n\n#### `FX65` — `LD V0..Vx, [I]`\n\nLoads registers `V0` through `Vx` from memory starting at address `I`.\n\nReference modern behavior:\n\n```text\nfor i = 0 to x:\n V[i] = memory[(I + i) & 0xFFF]\n```\n\n`I` is left unchanged.\n\nHistorical/quirk behavior:\n\n```text\nI = (I + x + 1) & 0xFFF\n```\n\n---\n\n### 10.6 Timer Instructions\n\n#### `FX07` — `LD Vx, DT`\n\n```text\nVx = DT\n```\n\n#### `FX15` — `LD DT, Vx`\n\n```text\nDT = Vx\n```\n\n#### `FX18` — `LD ST, Vx`\n\n```text\nST = Vx\n```\n\n---\n\n### 10.7 Key Instructions\n\n#### `EX9E` — `SKP Vx`\n\nSkip next instruction if the key whose index is in `Vx` is currently pressed.\n\n```text\nkey = Vx & 0xF\nif key_pressed[key]:\n PC = PC + 2\n```\n\n#### `EXA1` — `SKNP Vx`\n\nSkip next instruction if the key whose index is in `Vx` is not currently pressed.\n\n```text\nkey = Vx & 0xF\nif not key_pressed[key]:\n PC = PC + 2\n```\n\n#### `FX0A` — `LD Vx, K`\n\nBlocks execution until a key is pressed.\n\n```text\nwait for keypress\nVx = key value, 0x0 to 0xF\n```\n\nImplementation notes:\n\n- Some implementations wait for a key-down event.\n- Some implementations accept any currently pressed key.\n- Some implementations require a key press and release.\n- For broad compatibility, a key-down event or currently pressed key is usually acceptable.\n\n---\n\n### 10.8 Random Instruction\n\n#### `CXNN` — `RND Vx, kk`\n\n```text\nVx = random_byte() & kk\n```\n\nThe random-number generator is not architecturally specified. For testing, an implementation should provide deterministic seeding or injection.\n\n---\n\n## 11. Display Subsystem\n\n### 11.1 Display Parameters\n\n| Property | Value |\n|---|---|\n| Width | 64 pixels |\n| Height | 32 pixels |\n| Color depth | 1 bit per pixel |\n| Background | 0 = off/black |\n| Foreground | 1 = on/white |\n| Origin | Top-left, coordinate `(0, 0)` |\n\n### 11.2 Drawing Operation\n\nThe draw instruction is:\n\n```text\nDXYN\n```\n\nIt draws an `N`-byte-tall sprite from memory starting at `I` at coordinates `(Vx, Vy)`.\n\nSprite dimensions:\n\n```text\nwidth = 8 pixels\nheight = N rows\n```\n\nEach byte represents one row. The most significant bit is the leftmost pixel.\n\nExample row byte:\n\n```text\n0b10110000 = pixels: # . # # . . . .\n```\n\n### 11.3 Drawing Algorithm\n\nReference pseudocode:\n\n```text\nVF = 0\n\nfor row = 0 to height - 1:\n sprite_byte = memory[(I + row) & 0xFFF]\n\n for bit = 0 to 7:\n if sprite_byte & (0x80 >> bit):\n x = (Vx + bit) & 63\n y = (Vy + row) & 31\n\n if framebuffer[y][x] == 1:\n VF = 1\n\n framebuffer[y][x] ^= 1\n```\n\n### 11.4 Collision Flag\n\n`VF` is set to `1` if drawing turns any previously on pixel off.\n\nOtherwise, `VF` is set to `0`.\n\nThis is an XOR collision flag, not a simple overlap flag.\n\n### 11.5 Coordinate Wrapping and Clipping\n\nHistorical behavior varies.\n\nA common reference behavior for classic CHIP-8 is:\n\n```text\nx = (Vx + bit) modulo 64\ny = (Vy + row) modulo 32\n```\n\nSome implementations instead clip drawing to the visible screen:\n\n```text\nif x < 64 and y < 32:\n draw pixel\n```\n\nFor maximum compatibility:\n\n| Mode | Behavior |\n|---|---|\n| Classic CHIP-8 profile | Wrap coordinates modulo 64×32 |\n| Super-CHIP/modern profile | Often clips coordinates |\n| Recommended implementation | Provide configurable wrap/clip |\n\n### 11.6 Sprite Height for `N = 0`\n\nIn strict classic CHIP-8, `N` is normally a height from 1 to 15.\n\n`N = 0` is ambiguous and often used by later CHIP-8 variants.\n\nCommon compatibility behavior:\n\n```text\nif N == 0:\n height = 16\nelse:\n height = N\n```\n\nStrict original behavior may treat `N = 0` as zero height or reserved.\n\n---\n\n## 12. Font Sprites\n\nCHIP-8 includes a built-in hexadecimal font for digits `0`–`F`.\n\nEach character is 5 bytes tall and 8 pixels wide.\n\n### 12.1 Standard Font Bitmaps\n\n```text\n0: F0 90 90 90 F0\n1: 20 60 20 20 70\n2: F0 10 F0 80 F0\n3: F0 10 F0 10 F0\n4: 90 90 F0 10 10\n5: F0 80 F0 10 F0\n6: F0 80 F0 90 F0\n7: F0 10 20 40 40\n8: F0 90 F0 90 F0\n9: F0 90 F0 10 F0\nA: F0 90 F0 90 90\nB: E0 90 E0 90 E0\nC: F0 80 80 80 F0\nD: E0 90 90 90 E0\nE: F0 80 F0 80 F0\nF: F0 80 F0 80 80\n```\n\n### 12.2 Font Location\n\nThe font is stored in the interpreter-reserved region, commonly somewhere in:\n\n```text\n0x000–0x1FF\n```\n\nThe exact base address is implementation-defined, but `FX29` must return the correct address for the requested digit.\n\nExample:\n\n```text\nfont_base = 0x000\ndigit = Vx & 0xF\nI = font_base + digit * 5\n```\n\n---\n\n## 13. Keypad\n\n### 13.1 Keypad Model\n\nCHIP-8 uses a 16-key hexadecimal keypad.\n\nKey values are:\n\n```text\n0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,\n0x8, 0x9, 0xA, 0xB, 0xC, 0xD, 0xE, 0xF\n```\n\n### 13.2 Common Host Mapping\n\nA common PC keyboard mapping is:\n\n```text\nCHIP-8 keypad: Host keyboard:\n1 2 3 C 1 2 3 4\n4 5 6 D Q W E R\n7 8 9 E A S D F\nA 0 B F Z X C V\n```\n\nThis mapping is not required by the architecture.\n\n### 13.3 Key State\n\nAn interpreter should maintain:\n\n```text\nkey_pressed[16]\n```\n\nEach entry is boolean:\n\n```text\nfalse = key released\ntrue = key pressed\n```\n\nKey repeat behavior is implementation-defined.\n\n---\n\n## 14. Timers and Sound\n\n### 14.1 Delay Timer\n\nThe delay timer is an 8-bit countdown timer.\n\n```text\nif DT > 0:\n DT = DT - 1\n```\n\nIt decrements at 60 Hz.\n\nThe delay timer has no direct hardware effect; programs poll it using:\n\n```text\nFX07\n```\n\n### 14.2 Sound Timer\n\nThe sound timer is also an 8-bit countdown timer.\n\n```text\nif ST > 0:\n ST = ST - 1\n```\n\nIt decrements at 60 Hz.\n\nWhile `ST > 0`, the sound output should be active.\n\n```text\nsound_active = (ST > 0)\n```\n\n### 14.3 Sound Characteristics\n\nThe original CHIP-8 sound output is a simple buzzer or beeper.\n\nThe frequency and waveform are not specified. A square wave is typical.\n\nRecommended implementation:\n\n| Property | Suggested Value |\n|---|---|\n| Waveform | Square wave |\n| Frequency | 4000 Hz typical, implementation-defined |\n| Volume | Host-controlled |\n| Duration | While `ST > 0` |\n\n---\n\n## 15. Timing Model\n\n### 15.1 Instruction Execution\n\nCHIP-8 does not define a precise clock rate. The virtual CPU executes instructions one at a time.\n\nA typical interpreter loop is:\n\n```text\nwhile running:\n fetch opcode\n decode opcode\n execute opcode\n wait until next instruction tick\n```\n\n### 15.2 Recommended Instruction Rate\n\n| Use Case | Instruction Rate |\n|---|---:|\n| Conservative classic timing | 500 instructions/second |\n| Common default | 700 instructions/second |\n| Faster modern default | 1000 instructions/second |\n| Required timer rate | 60 Hz |\n\nMany original CHIP-8 games feel correct between 500 and 700 instructions per second. Some programs may run too fast at 1000 instructions per second.\n\n### 15.3 Timer Tick Independence\n\nTimers should decrement independently of instruction execution timing, ideally driven by a 60 Hz host timer.\n\n```text\nevery 1/60 second:\n if DT > 0: DT -= 1\n if ST > 0: ST -= 1\n```\n\n---\n\n## 16. Execution Example\n\n### 16.1 Simple Program\n\n```text\n0x200: 6005 LD V0, 0x05\n0x202: 6107 LD V1, 0x07\n0x204: 8014 ADD V0, V1\n0x206: 00EE RET\n```\n\n### 16.2 Step-by-Step\n\nInitial:\n\n```text\nPC = 0x200\nV0 = 0x00\nV1 = 0x00\n```\n\nStep 1:\n\n```text\nFetch 0x6005 at 0x200\nPC becomes 0x202\nV0 = 0x05\n```\n\nStep 2:\n\n```text\nFetch 0x6107 at 0x202\nPC becomes 0x204\nV1 = 0x07\n```\n\nStep 3:\n\n```text\nFetch 0x8014 at 0x204\nPC becomes 0x206\nV0 = V0 + V1\nV0 = 0x05 + 0x07\nV0 = 0x0C\nVF = 0\n```\n\nStep 4:\n\n```text\nFetch 0x00EE at 0x206\nReturn from subroutine\n```\n\n---\n\n## 17. Invalid and Undefined Opcodes\n\nNot all 16-bit values correspond to defined CHIP-8 instructions.\n\nExamples of undefined or reserved patterns include many values not listed in the instruction table.\n\nRecommended behavior:\n\n```text\nif opcode is undefined:\n treat as no-op, or log/trap in debug mode\n```\n\nThe program counter has usually already advanced by 2 before execution, so an undefined opcode should not normally cause an infinite loop unless deliberately implemented as a trap.\n\n---\n\n## 18. Compatibility Quirks\n\nCHIP-8 has several historical ambiguities. For maximum compatibility, implementations often provide quirk flags.\n\n### 18.1 Quirk Table\n\n| Quirk | Affected Instructions | Behavior |\n|---|---|---|\n| Shift source | `8XY6`, `8XYE` | Shift `Vx` or shift `Vy` into `Vx` |\n| Logical flag | `8XY1`, `8XY2`, `8XY3` | Clear `VF` or leave `VF` unchanged |\n| Load/store index | `FX55`, `FX65` | Leave `I` unchanged or increment by `X + 1` |\n| `FX1E` overflow | `FX1E` | Set or leave `VF` on 12-bit overflow |\n| Display clipping | `DXYN` | Wrap coordinates or clip to screen |\n| `DXYN` height zero | `DXYN` | Treat `N = 0` as 0 rows or 16 rows |\n| Key wait semantics | `FX0A` | Require key event, accept held key, or wait for release |\n| `0x0000` handling | `0000` | Ignore, trap, or execute native behavior |\n| `FX55`/`FX65` boundary | `FX55`, `FX65` | Wrap memory accesses or allow implementation-defined behavior |\n\n### 18.2 Recommended Default Profile\n\nFor a modern CHIP-8 interpreter aiming for broad compatibility:\n\n| Setting | Recommended Default |\n|---|---|\n| Shift source | Shift `Vx` |\n| Logical operations | Clear `VF` for `8XY1`, `8XY2`, `8XY3` |\n| `FX55`/`FX65` | Leave `I` unchanged |\n| `FX1E` overflow | Leave `VF` unchanged |\n| Display coordinates | Wrap for classic CHIP-8, optional clip |\n| `DXYN` with `N = 0` | Treat as height 16 for Super-CHIP compatibility |\n| `FX0A` | Accept key-down event or currently pressed key |\n| Invalid opcodes | No-op or debug trap |\n\n---\n\n## 19. Reference Interpreter Pseudocode\n\n```text\nfunction step():\n opcode = memory[PC] << 8 | memory[PC + 1]\n PC = (PC + 2) & 0xFFF\n\n switch opcode:\n case 0x00E0:\n clear_display()\n\n case 0x00EE:\n SP = SP - 1\n PC = stack[SP]\n\n case 0x1000 to 0x1FFF:\n PC = opcode & 0xFFF\n\n case 0x2000 to 0x2FFF:\n stack[SP] = PC\n SP = SP + 1\n PC = opcode & 0xFFF\n\n case 0x3000 to 0x3FFF:\n x = (opcode >> 8) & 0xF\n kk = opcode & 0xFF\n if V[x] == kk:\n PC = (PC + 2) & 0xFFF\n\n case 0x4000 to 0x4FFF:\n x = (opcode >> 8) & 0xF\n kk = opcode & 0xFF\n if V[x] != kk:\n PC = (PC + 2) & 0xFFF\n\n case 0x5000 to 0x5FFF:\n if (opcode & 0x000F) == 0:\n x = (opcode >> 8) & 0xF\n y = (opcode >> 4) & 0xF\n if V[x] == V[y]:\n PC = (PC + 2) & 0xFFF\n\n case 0x6000 to 0x6FFF:\n x = (opcode >> 8) & 0xF\n kk = opcode & 0xFF\n V[x] = kk\n\n case 0x7000 to 0x7FFF:\n x = (opcode >> 8) & 0xF\n kk = opcode & 0xFF\n V[x] = (V[x] + kk) & 0xFF\n\n case 0x8000 to 0x8FFF:\n execute_8xxx(opcode)\n\n case 0x9000 to 0x9FFF:\n if (opcode & 0x000F) == 0:\n x = (opcode >> 8) & 0xF\n y = (opcode >> 4) & 0xF\n if V[x] != V[y]:\n PC = (PC + 2) & 0xFFF\n\n case 0xA000 to 0xAFFF:\n I = opcode & 0xFFF\n\n case 0xB000 to 0xBFFF:\n PC = ((opcode & 0xFFF) + V[0]) & 0xFFF\n\n case 0xC000 to 0xCFFF:\n x = (opcode >> 8) & 0xF\n kk = opcode & 0xFF\n V[x] = random_byte() & kk\n\n case 0xD000 to 0xDFFF:\n x = (opcode >> 8) & 0xF\n y = (opcode >> 4) & 0xF\n n = opcode & 0xF\n draw_sprite(V[x], V[y], n)\n\n case 0xE000 to 0xEFFF:\n execute_exxx(opcode)\n\n case 0xF000 to 0xFFFF:\n execute_fxxx(opcode)\n\n default:\n undefined_opcode(opcode)\n```\n\n---\n\n## 20. Conformance Requirements\n\nA conforming basic CHIP-8 implementation should provide:\n\n1. 4096 bytes of addressable memory.\n2. Program execution beginning at `0x200`.\n3. Sixteen 8-bit `V` registers.\n4. A 16-bit `I` register with 12-bit effective memory addressing.\n5. A program counter and 16-level call stack.\n6. Fetch/decode/execution of 16-bit big-endian opcodes.\n7. The full documented instruction set, subject to declared quirk behavior.\n8. A 64×32 monochrome framebuffer.\n9. XOR sprite drawing from memory at `I`.\n10. A 16-key input model.\n11. Delay and sound timers decrementing at 60 Hz.\n12. Sound output while the sound timer is nonzero.\n13. Deterministic handling, or documented handling, of undefined opcodes.\n14. Documented behavior for known compatibility quirks.\n\n---\n\n## 21. Absolute Maximum Ratings\n\nNot applicable.\n\nCHIP-8 is a software virtual machine and has no electrical ratings.","refusal":null,"role":"assistant","annotations":null,"audio":null,"function_call":null,"tool_calls":null,"reasoning":"We need answer user's request: \"Write a comprehensive spec sheet in markdown for the CHIP-8 \"CPU\"\". Need produce final in markdown. Need likely comprehensive spec sheet for CHIP-8 CPU. Need be accurate: CHIP-8 is interpreted virtual machine, not true CPU. Spec includes architecture, registers, memory map, instruction set, timing, display, input, sound, quirks, opcodes maybe full table. Need comprehensive but not too enormous? Desired oververbosity 9. We can write detailed markdown. Need ensure correctness. Let's recall CHIP-8 specs.\n\nCHIP-8: created by Joseph Weisbecker, 1970s, RCA COSMAC VIP? Implemented as interpreter. 4K memory, 16 8-bit registers V0-VF, 16-bit index register I, 16-bit program counter, stack of 16 12-bit addresses (SP 8-bit?), 8-bit opcode, 16-bit opcodes? Actually instructions are 2 bytes (16-bit), big-endian. CPU clock? Original COSMAC VIP maybe 1.76 MHz? CHIP-8 timer frequencies 60 Hz. Common interpreter cycle rates vary. Need spec sheet style.\n\nMemory map typical:\n0x000-0x1FF interpreter reserved (includes fontset), 0x200-0xFFF program. Font sprites: 0x000-0x1FF often, modern implementations use 0x050-0x0A0? Characters 0-F 5 bytes each. Maybe specify.\n\nRegisters:\nV0..VF 8-bit general purpose. VF carries flag for arithmetic, collision. I 16-bit memory address. PC 16-bit. SP 8-bit maybe stack pointer to array of 16 16-bit values? stack[16] addresses. Delay timer DT, sound timer ST 8-bit decrement at 60 Hz when >0.\n\nInstruction encoding: nnn 12-bit addr, kk byte, n/x nibble register, etc.\nOpcodes full:\n0NNN machine code RCA 1802 call (not generally used) or 0x0NNN SYS nnn.\n00E0 CLS\n00EE RET\n0NNN SYS nnn ignored\n1NNN JP nn\n2NNN CALL nnn\n3XNN SE Vx, byte skip if Vx == kk\n4XNN SNE Vx, byte skip if !=\n5XY0 SE Vx, Vy skip if equal\n6XNN LD Vx, byte\n7XNN ADD Vx, byte (no carry)\n8XY0 LD Vx, Vy\n8XY1 OR Vx, Vy (VF reset in modern? original maybe VF not? Quirks: SCHIP resets VF for 8xy1-8xy3? Need mention. Original COSMAC VIP does not set VF? Actually modern CHIP-8: 8XY1, 8XY2, 8XY3 set VF to 0, because ambiguity. Need spec can define canonical modern behavior and note quirks.)\n8XY2 AND Vx,Vy\n8XY3 XOR Vx,Vy\n8XY4 ADD Vx,Vy with carry; VF=1 if carry else 0\n8XY5 SUB Vx,Vy; Vx=Vx-Vy; VF=NOT borrow (1 if Vx>=Vy)\n8XY6 SHR Vx {, Vy}; Some original: Shift Vy then store in Vx? Modern: Vx = Vx >> 1, VF=least significant bit before shift. Some use Vy. Need specify canonical and quirks.\n8XY7 SUBN Vx,Vy; Vx=Vy-Vx; VF=NOT borrow (Vy >= Vx)\n8XYE SHL Vx {, Vy}; VF=MSB before shift; modern Vx = Vx << 1.\n9XY0 SNE Vx,Vy skip if !=\nANNN LD I,nnn\nBNNN JP V0,nnn PC=nnn+V0\nCXNN RND Vx, byte; Vx=random & kk\nDXYN DRW Vx,Vy,nibble; draw sprite at (Vx,Vy), width 8, height n, from memory[I]. Sprite values XOR. VF=1 if any pixel turned off (collision). Coordinates wrap? Original wrap? Many wrap, but SCHIP no wrap maybe clipping. Need spec define wrap or clipping? Original CHIP-8? I think sprites wrap around display edges? Need be careful. Many emulators: wraparound; but modern practice maybe clipping. Let's state configurable, original likely wrap? Actually COSMAC VIP display routine? It may wrap coordinates modulo 64x32? Let's not overclaim. Define reference: x = Vx mod 64, y = Vy mod 32? But drawing lines may wrap? Need spec sheet can include options. Better: define canonical: coordinates masked/wrapped modulo display dimensions; optional clip mode.\nEX9E SKP Vx skip if key Vx pressed\nEXA1 SKNP Vx skip if key not pressed\nFX07 LD Vx,DT\nFX0A LD Vx,K wait for key press then store. blocking.\nFX15 LD DT,Vx\nFX18 LD ST,Vx\nFX1E ADD I,Vx; I = I + Vx; VF? Some set VF if overflow? Modern Super-CHIP sets VF=1 if I > 0xFFF? Original maybe not. Need note.\nFX29 LD F,Vx; set I = location of sprite for digit Vx (font).\nFX33 BCD Vx; store BCD at I,I+1,I+2.\nFX55 LD [I],V0..Vx; store registers. Original I increments? Modern I unchanged? Original? CHIP-8 increments I? Actually FX55/FX65: \"The interpreter increments I by X + 1 after execution\"? Different. Many modern preserve I, but original increments? Need mention. In original CHIP-8, I is incremented? Let's recall: On COSMAC VIP, maybe I points to memory after? Some docs: \"Stores V0 to VX (including VX) in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation?\" Let's verify from memory: Cowgod's CHIP-8 Technical Reference says: FX55: \"stores V0 through VX in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation.\" Wait contradictory? Maybe \"left unchanged\" means it is restored? There are quirks. Many emulators: I is unchanged (or set to I+X+1). Actually modern docs say \"I does not change\" for FX55/FX65. But Octo etc have quirks. Need include.\nFX65 LD Vx,[I].\n\nInput: 16-key hex keypad, keys 0-F. Key state latched? Usually array. FX0A waits for keydown then keyup? Common: stores key on key down and continues; some wait for key press and release? Need specify? CHIP-8 instruction: \"A key press is awaited, and then stored in Vx.\" Usually key press event not held. Some implementations wait until key released? Need maybe define event.\n\nDisplay: monochrome 64x32 pixels. Drawing uses XOR. Coordinate origin top-left. Pixel bit order: each byte row, MSB leftmost. Font: 5x? 5 bytes each 8x5? Actually 8x5 font. Need show font bitmaps maybe. Could include table.\n\nTiming: CHIP-8 CPU cycle: fetch 2-byte opcode, decode, execute. Timers run independent at 60Hz. Original CPU clock not fixed. Recommend 500-1000 instructions/sec? Common: 500 Hz? Actually CHIP-8 on COSMAC VIP ran at 1.76 MHz but interpreter overhead gives effective opcodes maybe ~1000/s? Many emulators use 1000 opcodes/sec, timers 60Hz. For spec sheet can define abstract: instruction rate configurable, typical 500 Hz or 1000 Hz. Need maybe mention sound beep square wave when ST>0.\n\nStatus flags: VF: carry, borrow, collision. Undefined after some ops? Need mention VF is general register and may be overwritten. In arithmetic, VF used. Logical ops reset VF to 0 in modern (optional original preserve?). For shift, VF low/high bit. For ADD I overflow optional.\n\nInstruction cycle details: PC increment before execute? Usually PC += 2 before executing; then instructions may modify. Skip instructions increment PC by 2 extra. For CALL pushes PC after increment. Need specify.\n\nInterrupts? None.\n\nPower/reset state: PC=0x200, I=0, SP=0, timers=0, registers maybe undefined/zero; display cleared? Key states up. Memory undefined except interpreter/font.\n\nMemory endian: Big-endian for opcodes: first byte high, second low. Multi-byte values? BCD writes hundreds, tens, ones at I,I+1,I+2.\n\nOpcode table. Need include all official opcodes and pseudo. Could include bitfields:\n15-12 opcode, 11-8 x, 7-4 y, 3-0 n, 7-0 kk, 11-0 nnn.\nNeed note unused opcodes are illegal/no-op; maybe skip? In spec, invalid opcodes should trap/no-op configurable. 0NNN ignored. 0xF??.\n\nNeed mention compatibility variants: CHIP-8, CHIP-48, SCHIP, XO-CHIP. But spec sheet for CHIP-8 CPU, maybe include quirks table. Could include recommended defaults for modern interpreter.\n\nNeed be comprehensive but not too verbose. Let's structure:\nTitle, overview, terminology, architecture block diagram ASCII, address space, registers, stack, timers, memory/font, display, keyboard, instruction format, execution model, instruction set table with details, opcode details by category, timing, reset, quirks/compatibility, implementation notes, pseudocode maybe, test requirements.\n\nNeed ensure not say CPU physical if quote. Maybe \"CHIP-8 'CPU'/virtual machine\".\n\nLet's craft final markdown. Need maybe include all opcodes:\n0x0000? Usually 0000 is SYS? Might hang? In many interpreters 0x0000 ignored. Need specify.\n\nDetailed table:\nOpcode | Mnemonic | Description | Flags.\n\n0nnn SYS addr ignored.\n00E0 CLS clear display.\n00EE RET return.\n1nnn JP addr.\n2nnn CALL addr.\n3xnn SE Vx, byte.\n4xnn SNE Vx, byte.\n5xy0 SE Vx, Vy.\n6xnn LD Vx, byte.\n7xnn ADD Vx, byte (VF unchanged).\n8xy0 LD Vx, Vy (modern VF=0? Some docs say VF unchanged? Actually Cowgod: 8XY0: Set Vx = Vy. VF is not affected? Wait many modern: 8xy0 sets Vx=Vy. Does VF reset? Let's check: For logical operations 8XY1-8XY3, VF is set to 0 in modern interpreters, but 8XY0? I think it may not affect VF, but some set VF=0? Need check. Cowgod: 8XY0 - LD Vx, Vy: Store value of Vy in Vx. No flag. For 8XY1 OR: sets Vx = Vx OR Vy; VF is set to 0 (modern). 8XY2 AND VF=0. 8XY3 XOR VF=0. But 8XY0 maybe does not. Need decide. For a comprehensive spec, list canonical modern: 8xy0 VF unchanged? But some docs say \"VF is reset by all 8xy?\" Hmm. Let's recall: Octo quirk \"vfOrder\" etc. \"Shift instructions set Vx to Vy?\" \"loadStore\" etc. \"logic\" quirk: \"logic operations set VF to 0\". Might include 8XY1-8XY3 only? In SuperChip, VF reset for 8XY1,2,3? Need state. For maximum compatibility, document both: reference modern: 8xy0 does not modify VF; 8xy1-8xy3 clear VF; original may leave VF unchanged. Need mention.\n\n8xy4 ADD: VF=carry.\n8xy5 SUB: VF=NOT borrow.\n8xy6 SHR: VF=LSB before shift. Modern shifts Vx; original shifts Vy? Actually details: Cowgod: \"Shifts Vx right by one bit. If least-significant bit of Vx is 1, VF=1 else 0. Vx /= 2.\" But \"original CHIP-8 implementation shifts Vx and stores result in Vx? Some use Vy?\" There is quirk \"shift\" where some shift Vy, leaving Vx unchanged? Let's recall: CHIP-8 instruction 8XY6: \"Shift Vx right by one bit. VF set to least significant bit. Some interpreters shift Vy and store in Vx.\" Since opcode includes y. Modern canonical: Vx = Vx >> 1. Alternative: Vx = Vy >> 1. Need note. Similarly 8XYE: Vx = Vx << 1 vs Vx = Vy << 1. Also for shift, if y=x no difference. Need include.\n\n9xy0 SNE.\nAnnn LD I.\nBnnn JP V0.\nCxnn RND.\nDxyn DRW. If n=0? Often draws 16-line sprite? Actually DXY0 draws 16 pixels tall? Wait CHIP-8: N is height from 0 to 15? If N=0, draws 16? I recall DXYN: draw sprite with N bytes. If N=0, draws 16 bytes? Many modern: N=0 means 16 height (SuperChip uses 16x16 sprites? Actually SuperCHIP high-res uses 16x16 with DXY0? Yes). Original CHIP-8 only N 1-15? Many implement N=0 as 16 for compatibility with SCHIP. Need include. For CHIP-8 canonical: n=0 may be implementation-defined; recommended treat as 16 for SCHIP. But if spec sheet for original CHIP-8, N=1..15, N=0 reserved? Need comprehensive include note.\n\nEx9E, ExA1.\nFx07, Fx0A, Fx15, Fx18, Fx1E, Fx29, Fx33, Fx55, Fx65.\n\nNeed maybe include 0x00FB, 0x00FC scroll right/left? Those are SuperCHIP not CHIP-8. Could mention not part of base.\n\nFont data: Standard 8x5 hex font, 80 bytes, typically at 0x000 or 0x050. Could include bytes: 0xF0,0x90,0x90,0x90,0xF0 for 0; 0x20,0x60,0x20,0x20,0x70 for 1; etc. Let's list maybe. Need ensure accuracy:\n0: F0 90 90 90 F0\n1: 20 60 20 20 70\n2: F0 10 F0 80 F0\n3: F0 10 F0 10 F0\n4: 90 90 F0 10 10\n5: F0 80 F0 10 F0\n6: F0 80 F0 90 F0\n7: F0 10 20 40 40\n8: F0 90 F0 90 F0\n9: F0 90 F0 10 F0\nA: F0 90 F0 90 90\nB: E0 90 E0 90 E0\nC: F0 80 80 80 F0\nD: E0 90 90 90 E0\nE: F0 80 F0 80 F0\nF: F0 80 F0 80 80\nGood.\n\nNeed maybe specify display coordinate wrap. Let's investigate original. CHIP-8 display: Draw at coordinate (Vx, Vy), width 8 height N. If pixel is off when XOR, VF=1. If pixel exceeds screen boundaries, it may wrap around? Some docs: \"If the coordinate is off-screen, it wraps around. If the sprite extends beyond the bottom, it wraps.\" Hmm. But not all. For spec, define reference behavior: x = Vx & 63, y = Vy & 31? But drawing rows if y+n > 32? Could wrap each pixel y coordinate modulo 32. For x each bit maybe wrap? Since row byte width 8; if x near 63, bits wrap to left? Some implementations clip if x > 56? Actually common: wrap? Let's recall CHIP-8 draw: for each row, for each bit, if xPos+bit < width and yPos < height then xor. Some no wrap. Original COSMAC VIP? The video memory is 64x32 bits, address computed? If coordinate wraps maybe due to 6-bit x and 5-bit y? Could be modulo. Let's not state absolute. We can say \"Reference behavior for compatibility: mask/wrap coordinates modulo display size; many modern interpreters optionally clip. Specify your implementation.\" But user asked spec sheet; we can choose normative. Could define \"Baseline CHIP-8: wraps both axes modulo 64x32. Super-CHIP: clips.\" Is that accurate? Hmm.\n\nMaybe safer: \"Original CHIP-8 display coordinates are typically treated modulo the display dimensions; many modern implementations provide clipping as a compatibility option. This spec defines wrap as normative for pure CHIP-8.\" Need be okay.\n\nNeed mention memory I range 12-bit? I is 16-bit but CHIP-8 memory only 4096; effective address I & 0xFFF. FX1E can set I beyond? If I is 16-bit, could >0xFFF; memory accesses mask. Some set VF on overflow. Need specify.\n\nProgram counter: 16-bit but memory 4096; PC masked? If jump beyond? Should mask to 12-bit or undefined. Define effective PC = value & 0xFFF. But instructions use nnn 12-bit so PC within. BNNN adds V0 can exceed 4095; mask. Could note.\n\nStack: 16 levels. CALL pushes PC (after +2). RET pops. SP increments/decrements. Overflow/underflow behavior undefined; recommended trap/no-op.\n\nRandom: CxNN uses implementation-defined PRNG; deterministic not specified. Should say should be random enough, not cryptographic.\n\nKey FX0A: need semantics: If no key pressed, PC repeats instruction? Usually decrement PC by 2 or not increment? Implementation: wait by not advancing until key event. It should store key code 0x0-0xF. Should ignore key repeats? Define key down event. Need note if multiple keys pressed: store first/lowest? Implementation-defined. For deterministic tests can hook.\n\nTimers: DT, ST loaded with Vx. At 60Hz, if >0 decrement. Sound active while ST > 0. If ST loaded with 0 no beep. If DT/ST loaded with >0 beep maybe after tick. Could mention.\n\nInstruction timing: For compatibility, use instruction scheduler: execute 1 opcode per cycle at 500 Hz? Let's think. The CHIP-8 technical reference by Thomas Daley? Many emulators do 10-15 cycles? Original? The CPU is interpreter on 1.76 MHz COSMAC VIP, so each CHIP-8 instruction many machine cycles. Effective instruction rate often 500 Hz for games. But some use 1000 Hz too fast. Need spec maybe: \"No canonical fixed instruction rate; typical 500–1000 opcode/s. Timers must be 60 Hz.\" For spec sheet maybe include recommended: 700 Hz? But comprehensive should mention configurable. Could include \"default 500 Hz for classic timing\".\n\nNeed maybe include bit-level opcode decoding. Could include pseudocode. Let's craft robust.\n\nPotential pitfalls: Need not overstate \"CPU\". Need markdown. Need include table of opcodes maybe large but okay. Need maybe include cycle/flag effects. Need include variants/quirks table.\n\nLet's outline final:\n\n# CHIP-8 “CPU” Specification Sheet\n\n## 1. Scope\nCHIP-8 is a bytecode VM / interpreter, not silicon CPU. This spec defines classic CHIP-8 execution environment.\n\n## 2. Architecture summary\n- 8-bit registers, 16-bit address, 4KiB memory, 16x12-bit stack, 64x32 1bpp display, 16 keys, 2 timers.\n\nTable.\n\nASCII block diagram.\n\n## 3. Memory map\nTable:\n0x000-0x1FF reserved (interpreter, font). 0x200-0xFFF program RAM.\nFont locations. Endianness.\n\n## 4. Programmer-visible registers\nTable: V0-VF, I, PC, SP, DT, ST, stack.\nVF details.\n\n## 5. Reset and initial state.\n\n## 6. Instruction format\n2 bytes big-endian. Bit fields table. PC behavior. Skip behavior.\n\n## 7. Instruction set\nMaybe grouped tables with full opcode. Need be comprehensive. Could use columns: Opcode, Mnemonic, Operation, Flags/Notes.\nNeed ensure no missing.\n\nLet's detail opcodes:\n0NNN | SYS nnn | ignored/no-op | None. Original machine call to RCA 1802.\n00E0 | CLS | clear display to black | none\n00EE | RET | PC = stack[SP]; SP-- | none\n1NNN | JP nnn | PC=nnn | none\n2NNN | CALL nnn | push PC+2; PC=nnn | none\n3XNN | SE Vx, kk | if Vx==kk skip next | none\n4XNN | SNE Vx, kk | if Vx!=kk skip | none\n5XY0 | SE Vx, Vy | if Vx==Vy skip | none\n6XNN | LD Vx, kk | Vx=kk | none\n7XNN | ADD Vx, kk | Vx=Vx+kk wrap | VF unchanged\n8XY0 | LD Vx, Vy | Vx=Vy | VF unchanged (modern)\n8XY1 | OR Vx, Vy | Vx|=Vy | modern VF=0\n8XY2 | AND | &= | modern VF=0\n8XY3 | XOR | ^= | modern VF=0\n8XY4 | ADD | Vx += Vy; VF=carry | carry\n8XY5 | SUB | if Vx >= Vy VF=1 else 0; Vx-=Vy | not borrow\n8XY6 | SHR | VF=Vx&1; Vx>>=1 | LSB. Optional Vy quirk\n8XY7 | SUBN | if Vy >= Vx VF=1 else 0; Vx=Vy-Vx | not borrow\n8XYE | SHL | VF=Vx>>7; Vx<<=1 | MSB. Optional Vy quirk\n9XY0 | SNE | if Vx != Vy skip | none\nANNN | LD I,nnn | I=nnn | none\nBNNN | JP V0,nnn | PC=nnn+V0 | none\nCXNN | RND Vx,kk | Vx=(rand & kk) | none\nDXYN | DRW Vx,Vy,n | sprite at I, n rows, XOR, VF=collision | VF=1 if erased; n=0 as 16 optional\nEX9E | SKP | if key Vx pressed skip | none\nEXA1 | SKNP | if key Vx not pressed skip | none\nFX07 | LD Vx,DT | Vx=DT | none\nFX0A | LD Vx,K | wait key, Vx=key | none\nFX15 | LD DT,Vx | DT=Vx | none\nFX18 | LD ST,Vx | ST=Vx | none\nFX1E | ADD I,Vx | I+=Vx | optional VF overflow\nFX29 | LD F,Vx | I=font address for digit Vx & 0xF | none\nFX33 | BCD Vx | mem[I]=hundreds, [I+1]=tens, [I+2]=ones | none\nFX55 | LD [I], V0..Vx | store regs | I behavior quirk\nFX65 | LD V0..Vx, [I] | load regs | I behavior quirk\n\nNeed include invalid opcodes: 0x0000 maybe ignored; unused: 0x0? DXY0? FX?? no. Define illegal as no-op or trap.\n\n## 8. Display subsystem\n- 64x32 framebuffer, coordinate system, pixel order, drawing algorithm, collision, font, timing. Maybe include font table.\n\n## 9. Input subsystem\n16-key keypad mapping, key codes 0-F, key state.\n\n## 10. Timers/sound\n60Hz, square wave.\n\n## 11. Timing and performance\nInstruction rate. Cycle model: fetch-decode-execute. No interrupts. Timers independent.\n\n## 12. Compatibility quirks\nTable: shift source, logical VF, load/store I increment, I overflow VF, 0x0000, DXY0 height, display wrap/clip, key wait.\n\nNeed be detailed but not too enormous. However user asked comprehensive spec sheet, so opcode table enough.\n\n## 13. Implementation pseudocode\nMaybe include pseudo for core loop and draw. Good.\n\n## 14. Conformance requirements.\n\nNeed maybe include \"electrical/mechanical\"? Since CPU quote, maybe \"Not applicable: virtual CPU\". Could include \"package: software ROM/RAM\". Spec sheet style could include absolute max ratings joke? But user likely wants technical spec. Could include \"No silicon\". Keep professional.\n\nNeed ensure markdown valid. Use tables. Long table maybe okay. Need avoid too wide? Fine.\n\nLet's think of correctness more deeply.\n\nCHIP-8 history: original on COSMAC VIP had 16 hex keypad, 64x32 display, sound buzzer. CPU: RCA CDP1802 at 1.76 MHz. But CHIP-8 itself is an interpreted language with opcode size 16-bit. \"CPU\" maybe refers to virtual CPU. Spec sheet should mention \"CHIP-8 CPU is typically implemented by interpreter\". Maybe include if one were to build hardware: data path 8-bit ALU, address 16-bit, opcode fetch 16-bit, microcode? Could provide spec for hardware implementation. But likely user expects CHIP-8 CPU spec. Need maybe include \"CPU core\" details for emulator: registers, opcodes.\n\nLet's consider if \"CHIP-8 CPU\" includes \"opcode 0x0000\"? Some emulators treat as infinite loop? On original, opcode 0x000 is SYS 000 which may jump to interpreter? But many ignore. For spec, say \"0x0000 should be treated as NOP for compatibility unless implementing RCA 1802 native calls.\" Good.\n\nStack pointer: Some docs say SP is 8-bit, but stack entries are 12-bit? Could be 16-bit. In CHIP-8, memory addresses 12-bit, so stack addresses are 12-bit, but typical emulator uses 16-bit stack array. SP points to top. On CALL: stack[SP] = PC; SP++. PC = addr. On RET: SP--; PC = stack[SP]. Some definitions SP points to next free? We can define normative. Need mention reset SP=0. Max depth 16. If SP would exceed 16, undefined; recommended ignore/trap.\n\nPC behavior: Fetch opcode at PC and PC+1, then PC = (PC + 2) & 0xFFF. Then if instruction sets PC, overrides. If skip, PC = (PC + 2) & 0xFFF. This is common. Need mention \"some interpreters increment PC after execution, but observable behavior is equivalent if skip/call handled carefully.\" For spec, define pre-increment.\n\nMemory: 4096 bytes, addresses 0x000-0xFFF. If I + X exceeds 0xFFF, address wraps/masks? For FX33, FX55, FX65, DXYN? Drawing reads from I..I+n-1, should wrap? Many implementations mask each address. Define effective address = (I + offset) & 0xFFF. Need mention. For FX55/FX65 if I unchanged vs increment, if address wraps, etc.\n\nBCD: mem[I] = Vx/100, mem[I+1] = (Vx/10)%10, mem[I+2] = Vx%10.\n\nRND: Vx = random & kk. Random generator not specified. For testability, expose seed.\n\nKeys: Key code is Vx lower nibble. If Vx > 0xF, use Vx & 0xF.\n\nFX0A: Wait for keypress. Common: if no key pressed, PC -= 2 to repeat. If key pressed, store. If multiple keys, choose lowest or first. If key held before instruction? Usually requires new key press? Many emulators check current key state and if any down store. This can cause immediate. Spec can say: \"A key transition from up to down should satisfy the instruction; implementations may accept currently held keys.\" For compatibility, maybe \"any key currently pressed\" because games? Hmm. Let's define normative: waits for a key-down event; if already pressed may be accepted as event? Need not be too rigid. Could say implementation-defined, but for deterministic tests define key-down event. Need maybe \"blocking: no further instructions execute until a key is accepted.\"\n\nDisplay drawing algorithm detail:\nFor row r=0..height-1:\n spriteByte = mem[(I+r)&0xFFF]\n for bit c=0..7:\n if spriteByte & (0x80 >> c):\n px = (Vx + c) mod 64\n py = (Vy + r) mod 32\n old = fb[py][px]\n new = old XOR 1\n if old == 1 and new == 0: VF = 1\n fb[py][px] = new\nBefore draw VF=0? Usually VF set to 1 if collision else 0. Yes, DRW sets VF=1 if any erased, else 0. Need specify VF=0 initially for draw. Some quirks? Yes.\n\nIf n=0: height=16 for SCHIP; if pure CHIP-8, height=0? Many docs: n is height, range 1-15. But if n=0, many implementations use 16; if height=0, no draw and VF=0. For comprehensive, say \"For base CHIP-8, N=0 is reserved and should be treated as height 0 or as implementation-defined; for SCHIP compatibility, treat as 16.\" But if spec wants normative, choose one. Maybe \"Recommended: N=0 draws 16 rows\". But classic CHIP-8 games don't use. If we define as 16, it is modern/SCHIP. Could be okay if comprehensive. But to avoid wrong, note option. In opcode table: DXYN: if N=0, height is 0 in strict original or 16 in common SCHIP-compatible mode; spec default: 16? Hmm.\n\nMaybe define \"Base CHIP-8 height = N rows; if N=0, no pixels are drawn.\" Then \"Compatibility extension: many systems treat N=0 as 16 rows.\" But comprehensive might include both. We can have a column \"Notes\" and quirks.\n\nShift quirks: Need more precise. Some original implementations shift Vy not Vx: For 8XY6: \"If the quirk shift_y is enabled, Vx = Vy >> 1; otherwise Vx >>= 1.\" If enabled and x != y, Vx gets shifted Vy. Some also preserve Vy? Yes. Need note.\n\nLogical VF quirk: For 8XY1-8XY3 modern clear VF; original may leave VF unchanged? Need include. Some also 8XY0? Some \"vfOrder\" quirk: \"VF is reset before logic op\"? Hmm.\n\nLoad/store quirk: FX55/FX65: original increments I to I+X+1? Let's investigate to avoid misinformation. Modern CHIP-8 docs from Tobias? Many say \"I is not changed.\" But Octo's quirk \"loadStore\" says \"On the COSMAC VIP, load/store increments I by X+1; many CHIP-8 programs assume I unchanged?\" Let's search memory: I know from emulation: There is quirk \"CHIP-8 legacy: load/store leave I unchanged\" vs \"SuperChip: I increments by x+1\"? Wait. Let's recall actual: Cowgod's technical reference says for FX55: \"The interpreter increments I by X + 1 after execution.\"? Or \"I is increased by 1 for each value written, and left unchanged after operation\"? Let me think of common emulator code: Many implement `for i=0..x memory[I+i]=V[i]` and do not modify I. Some compatibility flag \"vfOrder\", \"shift\", \"logic\". Another quirk \"loadstore\" in Chip8 emulator? Some CHIP-8 programs expect I to be incremented? Example: Spacefight 2091 uses FX55? Hmm. There are known quirks:\n- `quirk_sf`: shift instructions set Vx = Vy? \n- `quirk_load`: increment I after FX65? \n- `quirk_store`: increment I after FX55?\nMaybe original VIP increments I after store/load? Let's find from memory: In CHIP-8, FX55: \"stores V0 through VX (including VX) in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation.\" Wait that phrase could be from Cowgod: It says \"The full 16-bit content of I is incremented by x+1, but only the lower 12 bits are used\"? No.\n\nLet's reason from hardware? CHIP-8 on COSMAC VIP: I is a memory pointer register. FX55 might use auto-increment? It might leave I at I+x+1 because easier. But many modern docs say I unchanged. Which behavior is required by programs? There are test ROMs that detect. Octo options: `-s` superchip? There are quirks: `shift`, `logic`, `loadstore` maybe. \"In the original CHIP-8 implementation, the index register is incremented by load/store, while in CHIP-8 on the COSMAC VIP?\" Need be accurate.\n\nLet's recall from Octo documentation: \"quirk load-store: In the original CHIP-8 interpreter, the index register I is incremented by load/store operations, but CHIP-8 programs written for later interpreters expect I to remain unchanged.\" Or vice versa. Actually I remember using Chip-8 emulator: option \"Set I = I + X + 1 after FX55/FX65\" is for SCHIP? Let's search mental: There is a known quirk \"store/load should not increment I\". Many emulators have config \"Original CHIP-8 behavior: increment I on load/store\". Modern CHIP-8 (CHIP-48/SCHIP?) maybe leaves unchanged. Which is original? The original COSMAC VIP manual might say I is incremented? Hmm.\n\nCowgod's technical reference (v5.0) says:\nFX55: \"Store V0 to VX in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation.\" Wait left unchanged? That is contradictory; maybe \"increased\" means internal pointer during operation, but after operation original I remains? It may be because I is copied to a temporary and incremented, but I register not changed. Modern interpreters preserve I. But some tests show some ROMs expect I incremented? Need not decide; list quirk.\n\nLet's check known CHIP-8 test ROMs: \"Flags and quirks\" from corax89: tests shift, load/store. The CHIP-8 spec by John? It says: \"FX55 and FX65: I is incremented by X+1 on the original CHIP-8 interpreter. Most modern interpreters leave I unchanged, but this breaks some original ROMs.\" Hmm.\n\nMaybe the original COSMAC VIP had no separate I? Actually CHIP-8 interpreter used register I as memory pointer. The VIP had DMA register? It might be easier to increment I. I found memory: \"CHIP-8 has two timer quirks: delay timer decrements at 60 Hz. The original VIP had a quirk where Fx55 and Fx65 increment I by X+1.\" Yes, there is a \"quirk_load\" in chip8 emulator: \"On the COSMAC VIP, Fx65 increments I by X+1 after loading registers; on modern interpreters I is unchanged.\" There is also \"quirk_store\" for Fx55. Some ROMs like \"Rocket Launch\" maybe rely? Need not know.\n\nSpec: We can define canonical modern behavior: I unchanged after FX55/FX65. Include quirk: original VIP/SCHIP may increment I by X+1. But if spec is \"CHIP-8 CPU\" maybe original? Could say \"Historically ambiguous; define your implementation.\" Comprehensive includes both.\n\nFX1E overflow VF: In SuperCHIP, if I + Vx > 0xFFF, VF=1, else 0; I wraps? Actually I is 16-bit, addition may overflow 12-bit but not 16. Some docs: \"If I + Vx > 0xFFF, VF = 1, else VF = 0. This quirk is only implemented in some interpreters.\" Need mention. If I > 0xFFF, memory accesses mask. Modern CHIP-8 often leaves VF unchanged. Some SuperCHIP uses VF overflow. Need note.\n\nDXYN collision: VF set if pixels erased; if drawing outside? If clipped, no collision for off-screen? In wrap, collisions can happen. Need state.\n\nKeyboard mapping: Typical PC keys: 1234/QWER/ASDF/ZXCV to hex keypad. But not part of spec. Could include recommended mapping.\n\nSound: Single-channel square wave/buzzer. Frequency not specified. Recommend 4000 Hz? Original beep simple. Need state.\n\nMaybe include \"electrical characteristics\" as not applicable. But spec sheet maybe fun: \"Technology: software interpreted; process: N/A\". Could include. But avoid too silly.\n\nNeed maybe include \"Instruction cycle timing\" for hardware implementation:\nFetch: 2 bytes from memory at PC, big-endian. Decode: bits. Execute. Timers tick asynchronous. For CPU core, need opcode register, ALU 8-bit, adders, random, timers. But not necessary.\n\nNeed maybe include \"Example: opcode 0x1230: PC = 0x230\".\n\nNeed maybe include \"Program assembly format\"? Maybe not.\n\nNeed maybe include \"Memory alignment\": instructions must start at even? CHIP-8 PC starts at 0x200 and increments by 2, jumps to even? nnn can be odd? Actually addresses are 12-bit, but if PC odd, instruction fetch misaligned? CHIP-8 doesn't require alignment? PC can be set to odd by BNNN? nnn plus V0 may be odd if V0 odd. If fetch from odd and next even? It could work but interpreters often fetch PC and PC+1, so odd is okay? But original? Most code even. For spec, say \"Programs conventionally use even addresses; odd PC values are legal in this spec but not recommended; fetch uses consecutive bytes.\" Good.\n\nNeed maybe include \"No memory protection\". Good.\n\nLet's craft comprehensive markdown. Need maybe include table of contents? Not necessary but can. Use headings.\n\nLet's ensure opcode table not too wide. Could split into groups: 0x0, jumps, math, memory, display/input, FX. But one table easier. Need maybe include bitfields before.\n\nDetailed flag effects: Maybe separate table.\n\nPotential missing opcode: 0xFX??: FX0C? Not valid. 0x0? DXYN with N=0? OK.\n\nNeed maybe include \"SYS\" is not executed as CHIP-8; original calls machine language routine. Modern should ignore. But if writing spec, maybe mention `0NNN` calls RCA 1802 machine code routine at nnn in native VIP environment. In CHIP-8-only, no-op.\n\nNeed maybe include \"CHIP-8 has no interrupts; however display refresh and timers may be host-driven.\"\n\nNeed maybe include \"Memory mapped display? No, separate framebuffer.\" Original VIP had video RAM in main memory? CHIP-8 display uses memory? The interpreter draws to screen, not memory-mapped in programmer model. Spec can say display framebuffer is separate from the 4KiB address space; not directly accessible except DRW. Original maybe video RAM? But CHIP-8 abstracts. Good.\n\nNeed maybe include \"Font sprite address: FX29 sets I to base + digit*5. Common base 0x000 or 0x050. For this spec, canonical base 0x000; many modern use 0x050 to avoid conflict. Implementations must document base.\" Maybe spec should choose canonical? Could choose 0x000? But many emulators load font at 0x050 to leave 0x000 free? In original, font stored in interpreter area 0x000-0x1FF, often at 0x000. The low 0x1FF reserved, so any location is okay as long as FX29 works. For spec sheet, define \"font base implementation-defined within reserved region; FX29 returns address; standard font bytes listed.\" Good.\n\nNeed maybe include \"Program load address 0x200\". Some programs loaded at 0x200, 0x600 for SCHIP? Base: 0x200.\n\nNeed maybe include \"Memory size 4096 bytes; upper addresses maybe RAM.\" Good.\n\nLet's maybe include \"Conformance: required instructions\" and optional quirks.\n\nLet's think if we need include exact bit encodings for all opcodes? Table includes opcode pattern. Use `nnn`, `kk`, `x`, `y`, `n`.\n\nCould include pseudocode:\n```\nfunction step():\n opcode = (mem[pc] << 8) | mem[pc+1]\n pc = (pc + 2) & 0xFFF\n switch opcode & 0xF000:\n ...\n```\nBut maybe too long. Could include draw pseudocode.\n\nNeed final answer just markdown. It can be long. Good.\n\nDouble-check opcodes:\n- `8XY5`: If Vx > Vy, VF=1 else 0? Actually not borrow: if Vx >= Vy, no borrow, VF=1. For equal, VF=1. Then Vx=Vx-Vy. Correct.\n- `8XY7`: Vx = Vy - Vx; if Vy >= Vx VF=1 else 0. Correct.\n- `8XY6`: VF=LSB of Vx before shift. If quirk shift Vy, VF=LSB of Vy before shift? If Vx = Vy >> 1, VF set to LSB of Vy? Some implementations set from Vx? Need say canonical: source operand's LSB. If using Vy source, VF = source LSB. Similarly SHL source MSB.\n- `DXYN`: sprite data from I to I+N-1. If N=0, in SCHIP height 16; else height 0? For table, mention.\n- `FX29`: If Vx is e.g. 0xA, lower nibble. `I = font_address + (Vx & 0xF) * 5`.\n- `FX33`: Does not change Vx. Uses decimal digits. Good.\n- `FX55`: Store V0..Vx. If X=0 stores V0. Does not change registers. I behavior quirk.\n- `FX65`: Load V0..Vx. If X=0 loads V0. I behavior quirk.\n\nNeed maybe include \"All arithmetic modulo 256 unless flags specified.\"\n\nNeed maybe include \"Skip instructions: The skipped instruction is completely not executed; if skipped instruction is DXYN? no.\"\n\nNeed maybe include \"When instruction both sets PC and skip? none.\"\n\nNeed maybe include \"0x00E0 clears framebuffer and maybe resets VF? No.\"\n\nNeed maybe include \"0x00EE does not clear stack.\" Good.\n\nNeed maybe include \"BNNN uses V0; not VX.\" Good.\n\nNeed maybe include \"CXNN random AND kk, not modulo.\" Good.\n\nNeed maybe include \"EX9E/EXA1 key index masked to 0-F.\" Good.\n\nNeed maybe include \"FX0A if key code is stored in Vx, lower nibble of Vx? It stores 0-F.\" Good.\n\nNeed maybe include \"No DMA, no memory-mapped I/O.\" Good.\n\nMaybe include \"Host responsibilities: refresh display after each draw/timer; sample sound while ST>0; poll keys.\" Good.\n\nNeed maybe include \"Compatibility modes: CHIP-8, CHIP-48, Super-CHIP, XO-CHIP not covered.\" Could mention extensions.\n\nLet's think about spec sheet style: Could include \"Part number\"? Maybe not. But \"comprehensive spec sheet\" maybe like datasheet: General Description, Features, Pinout? For CHIP-8 virtual CPU no pinout. We can add a \"Ordering information / variants\"? Maybe overkill. But user said CPU in quotes, so maybe they expect playful but technical. We can include \"Package: source code/software; no pins\". But keep professional.\n\nPotential issue: final answer too long? It's okay. Need maybe avoid too many caveats but include quirks.\n\nLet's write final with headings. Need ensure markdown tables not broken. Use monospace for opcodes.\n\nDetailed sections:\n\n1. Identification\n```\nArchitecture: 16-bit opcode, 8-bit data, 12-bit address\nProgram origin: 0x200\nMemory: 4096 bytes\nDisplay: 64x32 1bpp\nInput: 16 keys\nTimers: 2 x 8-bit @ 60Hz\n```\n\n2. Block diagram ASCII.\n\n3. Address space and memory.\n\n4. Registers.\n\n5. Reset.\n\n6. Opcode encoding.\n\n7. Instruction set.\n\n8. Display.\n\n9. Keyboard.\n\n10. Timers/sound.\n\n11. Timing.\n\n12. Quirks.\n\n13. Implementation notes/pseudocode.\n\n14. Conformance.\n\nLet's craft. Need maybe include \"Table: VF flag summary\".\n\nLet's ensure final answer doesn't mention analysis. Use English. Need no code of analysis.\n\nLet's start final.\n\nNeed decide normative choices:\n- We'll present a \"Reference implementation profile\" with defaults. For ambiguous items, say \"Implementation-defined/quirk\" and recommend defaults. That satisfies comprehensive.\n\nDefaults for reference:\n- `0x0000` NOP.\n- `8XY1-8XY3` clear VF; `8XY0` unchanged.\n- Shifts operate on Vx (not Vy).\n- FX55/FX65 leave I unchanged (modern common). But maybe original increments. We can state default modern; original quirk optional.\n- FX1E leaves VF unchanged unless overflow quirk enabled.\n- DRW N=0: height 16? For pure CHIP-8 reference maybe height 0? But compatibility with SCHIP common. Need choose default? For comprehensive, maybe define \"CHIP-8 base: N = height in rows (1-15). N=0 is reserved; for maximum compatibility, implementations may implement N=0 as height 16. This spec's canonical CHIP-8 profile treats N=0 as height 0 unless SCHIP compatibility is enabled.\" But many tests? Games don't use N=0. If we treat N=0 as height 0, a SCHIP ROM would fail, but that's extension. The user asked CHIP-8, so okay. But maybe \"comprehensive\" should include N=0 as 16. Let's define a \"CHIP-8/SCHIP compatible\" default: N=0 height 16. But if strict original, no. Hmm.\n\nMaybe include \"Height is N rows; if N=0, behavior is historically ambiguous. Recommended for broad compatibility: height=16. Strict original profile: height=0.\" That's safe.\n\nDisplay wrap: We can define \"Reference wraps both axes; optional clip.\" But many modern emulators clip by default? Let's see. If coordinates wrap, drawing at x=60 with 8px wraps. Some games rely? Probably not. The original COSMAC VIP likely wraps due to modulo? We can say \"Historical CHIP-8 commonly wraps; SCHIP clips.\" Good.\n\nFX55/FX65 default: broad compatibility? Many modern docs say I unchanged; but some original ROMs expect increment? Need define quirk. Maybe default \"leave I unchanged\" because most homebrew and docs. But \"original\" maybe increment. Could say \"Most modern CHIP-8 implementations leave I unchanged; original VIP behavior may increment. Provide compatibility switch.\" Good.\n\nFX1E default: no VF; optional overflow.\n\nKey wait default: accept key-down event; if key already held maybe not? To avoid repeated immediate, but many emulators check state. For compatibility, accept any currently pressed key. Hmm. Let's state \"A key-down event or any currently pressed key may satisfy; implementation must document.\" But for spec, define \"current key state\" maybe easier. Many CHIP-8 games use FX0A to wait; if key held, they might continue, not issue. Good.\n\nNeed maybe include \"When DT/ST decrement: if loaded with 1, becomes 0 after next tick; sound stops when ST becomes 0.\" Good.\n\nLet's produce final. Ensure table syntax correct. Use code fences for pseudocode.\n\nNeed maybe include font table. Could be large but okay. Use code block with hex lines.\n\nLet's draft final in mind:\n\n```\n# CHIP-8 \"CPU\" Specification Sheet\n\n## 1. Overview\n...\n```\n\nNeed maybe include note: \"CHIP-8 is not a physical CPU; the 'CPU' is a virtual processor/ISA.\"\n\nLet's craft with enough detail.\n\nOne thing: `0x0NNN` is SYS. If opcode is 0x0000, some emulators infinite loop if PC not advanced? If we define NOP and PC already advanced, fine.\n\nInstruction table might have `VF` column. Need avoid too wide. Use separate notes.\n\nMaybe include opcode table as:\n\n| Encoding | Mnemonic | Operation | Notes |\n|---|---|---|---|\n\nFor `DXYN`, operation text long but okay.\n\nNeed include all opcodes but maybe group by high nibble. Good.\n\nLet's write.\n\nDouble-check if `FX0A` stores key value in Vx and then continues. Does it also wait for key release? Some docs: \"All execution stops until a key is pressed.\" It doesn't wait release. But some emulators wait keydown and keyup? Need specify not release. Good.\n\nNeed include \"Key values 0x0-0xF; keypad layout standard 4x4.\"\n\nNeed include \"Recommended host key map: 1 2 3 C / 4 5 6 D / 7 8 9 E / A 0 B F\" maybe.\n\nLet's maybe include \"Display refresh: host should render framebuffer after each draw; no direct pixel access.\" Good.\n\nPotential issue: Some CHIP-8 docs say `8XY1`, `8XY2`, `8XY3` set VF to 0 because original? Actually original COSMAC VIP might set VF to 0? Need say \"modern reference clears VF; some historical implementations leave VF unchanged.\" Good.\n\nNeed maybe include \"For `8XY4` ADD with immediate? No carry from `7XNN`.\" Good.\n\nNeed maybe include \"All registers are 8-bit except I and PC 16-bit; effective addresses 12-bit.\" Good.\n\nLet's write final. Ensure no missing closing. Use bullet list.\n\nNeed maybe include \"Opcode invalid: recommended no-op and log; not skip.\" Could be important. If invalid, PC already advanced. For undefined opcodes, don't corrupt state. Good.\n\nNeed maybe include \"Memory writes are immediate; no cache.\" Good.\n\nLet's produce final with robust content.","reasoning_details":[{"type":"reasoning.text","text":"We need answer user's request: \"Write a comprehensive spec sheet in markdown for the CHIP-8 \"CPU\"\". Need produce final in markdown. Need likely comprehensive spec sheet for CHIP-8 CPU. Need be accurate: CHIP-8 is interpreted virtual machine, not true CPU. Spec includes architecture, registers, memory map, instruction set, timing, display, input, sound, quirks, opcodes maybe full table. Need comprehensive but not too enormous? Desired oververbosity 9. We can write detailed markdown. Need ensure correctness. Let's recall CHIP-8 specs.\n\nCHIP-8: created by Joseph Weisbecker, 1970s, RCA COSMAC VIP? Implemented as interpreter. 4K memory, 16 8-bit registers V0-VF, 16-bit index register I, 16-bit program counter, stack of 16 12-bit addresses (SP 8-bit?), 8-bit opcode, 16-bit opcodes? Actually instructions are 2 bytes (16-bit), big-endian. CPU clock? Original COSMAC VIP maybe 1.76 MHz? CHIP-8 timer frequencies 60 Hz. Common interpreter cycle rates vary. Need spec sheet style.\n\nMemory map typical:\n0x000-0x1FF interpreter reserved (includes fontset), 0x200-0xFFF program. Font sprites: 0x000-0x1FF often, modern implementations use 0x050-0x0A0? Characters 0-F 5 bytes each. Maybe specify.\n\nRegisters:\nV0..VF 8-bit general purpose. VF carries flag for arithmetic, collision. I 16-bit memory address. PC 16-bit. SP 8-bit maybe stack pointer to array of 16 16-bit values? stack[16] addresses. Delay timer DT, sound timer ST 8-bit decrement at 60 Hz when >0.\n\nInstruction encoding: nnn 12-bit addr, kk byte, n/x nibble register, etc.\nOpcodes full:\n0NNN machine code RCA 1802 call (not generally used) or 0x0NNN SYS nnn.\n00E0 CLS\n00EE RET\n0NNN SYS nnn ignored\n1NNN JP nn\n2NNN CALL nnn\n3XNN SE Vx, byte skip if Vx == kk\n4XNN SNE Vx, byte skip if !=\n5XY0 SE Vx, Vy skip if equal\n6XNN LD Vx, byte\n7XNN ADD Vx, byte (no carry)\n8XY0 LD Vx, Vy\n8XY1 OR Vx, Vy (VF reset in modern? original maybe VF not? Quirks: SCHIP resets VF for 8xy1-8xy3? Need mention. Original COSMAC VIP does not set VF? Actually modern CHIP-8: 8XY1, 8XY2, 8XY3 set VF to 0, because ambiguity. Need spec can define canonical modern behavior and note quirks.)\n8XY2 AND Vx,Vy\n8XY3 XOR Vx,Vy\n8XY4 ADD Vx,Vy with carry; VF=1 if carry else 0\n8XY5 SUB Vx,Vy; Vx=Vx-Vy; VF=NOT borrow (1 if Vx>=Vy)\n8XY6 SHR Vx {, Vy}; Some original: Shift Vy then store in Vx? Modern: Vx = Vx >> 1, VF=least significant bit before shift. Some use Vy. Need specify canonical and quirks.\n8XY7 SUBN Vx,Vy; Vx=Vy-Vx; VF=NOT borrow (Vy >= Vx)\n8XYE SHL Vx {, Vy}; VF=MSB before shift; modern Vx = Vx << 1.\n9XY0 SNE Vx,Vy skip if !=\nANNN LD I,nnn\nBNNN JP V0,nnn PC=nnn+V0\nCXNN RND Vx, byte; Vx=random & kk\nDXYN DRW Vx,Vy,nibble; draw sprite at (Vx,Vy), width 8, height n, from memory[I]. Sprite values XOR. VF=1 if any pixel turned off (collision). Coordinates wrap? Original wrap? Many wrap, but SCHIP no wrap maybe clipping. Need spec define wrap or clipping? Original CHIP-8? I think sprites wrap around display edges? Need be careful. Many emulators: wraparound; but modern practice maybe clipping. Let's state configurable, original likely wrap? Actually COSMAC VIP display routine? It may wrap coordinates modulo 64x32? Let's not overclaim. Define reference: x = Vx mod 64, y = Vy mod 32? But drawing lines may wrap? Need spec sheet can include options. Better: define canonical: coordinates masked/wrapped modulo display dimensions; optional clip mode.\nEX9E SKP Vx skip if key Vx pressed\nEXA1 SKNP Vx skip if key not pressed\nFX07 LD Vx,DT\nFX0A LD Vx,K wait for key press then store. blocking.\nFX15 LD DT,Vx\nFX18 LD ST,Vx\nFX1E ADD I,Vx; I = I + Vx; VF? Some set VF if overflow? Modern Super-CHIP sets VF=1 if I > 0xFFF? Original maybe not. Need note.\nFX29 LD F,Vx; set I = location of sprite for digit Vx (font).\nFX33 BCD Vx; store BCD at I,I+1,I+2.\nFX55 LD [I],V0..Vx; store registers. Original I increments? Modern I unchanged? Original? CHIP-8 increments I? Actually FX55/FX65: \"The interpreter increments I by X + 1 after execution\"? Different. Many modern preserve I, but original increments? Need mention. In original CHIP-8, I is incremented? Let's recall: On COSMAC VIP, maybe I points to memory after? Some docs: \"Stores V0 to VX (including VX) in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation?\" Let's verify from memory: Cowgod's CHIP-8 Technical Reference says: FX55: \"stores V0 through VX in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation.\" Wait contradictory? Maybe \"left unchanged\" means it is restored? There are quirks. Many emulators: I is unchanged (or set to I+X+1). Actually modern docs say \"I does not change\" for FX55/FX65. But Octo etc have quirks. Need include.\nFX65 LD Vx,[I].\n\nInput: 16-key hex keypad, keys 0-F. Key state latched? Usually array. FX0A waits for keydown then keyup? Common: stores key on key down and continues; some wait for key press and release? Need specify? CHIP-8 instruction: \"A key press is awaited, and then stored in Vx.\" Usually key press event not held. Some implementations wait until key released? Need maybe define event.\n\nDisplay: monochrome 64x32 pixels. Drawing uses XOR. Coordinate origin top-left. Pixel bit order: each byte row, MSB leftmost. Font: 5x? 5 bytes each 8x5? Actually 8x5 font. Need show font bitmaps maybe. Could include table.\n\nTiming: CHIP-8 CPU cycle: fetch 2-byte opcode, decode, execute. Timers run independent at 60Hz. Original CPU clock not fixed. Recommend 500-1000 instructions/sec? Common: 500 Hz? Actually CHIP-8 on COSMAC VIP ran at 1.76 MHz but interpreter overhead gives effective opcodes maybe ~1000/s? Many emulators use 1000 opcodes/sec, timers 60Hz. For spec sheet can define abstract: instruction rate configurable, typical 500 Hz or 1000 Hz. Need maybe mention sound beep square wave when ST>0.\n\nStatus flags: VF: carry, borrow, collision. Undefined after some ops? Need mention VF is general register and may be overwritten. In arithmetic, VF used. Logical ops reset VF to 0 in modern (optional original preserve?). For shift, VF low/high bit. For ADD I overflow optional.\n\nInstruction cycle details: PC increment before execute? Usually PC += 2 before executing; then instructions may modify. Skip instructions increment PC by 2 extra. For CALL pushes PC after increment. Need specify.\n\nInterrupts? None.\n\nPower/reset state: PC=0x200, I=0, SP=0, timers=0, registers maybe undefined/zero; display cleared? Key states up. Memory undefined except interpreter/font.\n\nMemory endian: Big-endian for opcodes: first byte high, second low. Multi-byte values? BCD writes hundreds, tens, ones at I,I+1,I+2.\n\nOpcode table. Need include all official opcodes and pseudo. Could include bitfields:\n15-12 opcode, 11-8 x, 7-4 y, 3-0 n, 7-0 kk, 11-0 nnn.\nNeed note unused opcodes are illegal/no-op; maybe skip? In spec, invalid opcodes should trap/no-op configurable. 0NNN ignored. 0xF??.\n\nNeed mention compatibility variants: CHIP-8, CHIP-48, SCHIP, XO-CHIP. But spec sheet for CHIP-8 CPU, maybe include quirks table. Could include recommended defaults for modern interpreter.\n\nNeed be comprehensive but not too verbose. Let's structure:\nTitle, overview, terminology, architecture block diagram ASCII, address space, registers, stack, timers, memory/font, display, keyboard, instruction format, execution model, instruction set table with details, opcode details by category, timing, reset, quirks/compatibility, implementation notes, pseudocode maybe, test requirements.\n\nNeed ensure not say CPU physical if quote. Maybe \"CHIP-8 'CPU'/virtual machine\".\n\nLet's craft final markdown. Need maybe include all opcodes:\n0x0000? Usually 0000 is SYS? Might hang? In many interpreters 0x0000 ignored. Need specify.\n\nDetailed table:\nOpcode | Mnemonic | Description | Flags.\n\n0nnn SYS addr ignored.\n00E0 CLS clear display.\n00EE RET return.\n1nnn JP addr.\n2nnn CALL addr.\n3xnn SE Vx, byte.\n4xnn SNE Vx, byte.\n5xy0 SE Vx, Vy.\n6xnn LD Vx, byte.\n7xnn ADD Vx, byte (VF unchanged).\n8xy0 LD Vx, Vy (modern VF=0? Some docs say VF unchanged? Actually Cowgod: 8XY0: Set Vx = Vy. VF is not affected? Wait many modern: 8xy0 sets Vx=Vy. Does VF reset? Let's check: For logical operations 8XY1-8XY3, VF is set to 0 in modern interpreters, but 8XY0? I think it may not affect VF, but some set VF=0? Need check. Cowgod: 8XY0 - LD Vx, Vy: Store value of Vy in Vx. No flag. For 8XY1 OR: sets Vx = Vx OR Vy; VF is set to 0 (modern). 8XY2 AND VF=0. 8XY3 XOR VF=0. But 8XY0 maybe does not. Need decide. For a comprehensive spec, list canonical modern: 8xy0 VF unchanged? But some docs say \"VF is reset by all 8xy?\" Hmm. Let's recall: Octo quirk \"vfOrder\" etc. \"Shift instructions set Vx to Vy?\" \"loadStore\" etc. \"logic\" quirk: \"logic operations set VF to 0\". Might include 8XY1-8XY3 only? In SuperChip, VF reset for 8XY1,2,3? Need state. For maximum compatibility, document both: reference modern: 8xy0 does not modify VF; 8xy1-8xy3 clear VF; original may leave VF unchanged. Need mention.\n\n8xy4 ADD: VF=carry.\n8xy5 SUB: VF=NOT borrow.\n8xy6 SHR: VF=LSB before shift. Modern shifts Vx; original shifts Vy? Actually details: Cowgod: \"Shifts Vx right by one bit. If least-significant bit of Vx is 1, VF=1 else 0. Vx /= 2.\" But \"original CHIP-8 implementation shifts Vx and stores result in Vx? Some use Vy?\" There is quirk \"shift\" where some shift Vy, leaving Vx unchanged? Let's recall: CHIP-8 instruction 8XY6: \"Shift Vx right by one bit. VF set to least significant bit. Some interpreters shift Vy and store in Vx.\" Since opcode includes y. Modern canonical: Vx = Vx >> 1. Alternative: Vx = Vy >> 1. Need note. Similarly 8XYE: Vx = Vx << 1 vs Vx = Vy << 1. Also for shift, if y=x no difference. Need include.\n\n9xy0 SNE.\nAnnn LD I.\nBnnn JP V0.\nCxnn RND.\nDxyn DRW. If n=0? Often draws 16-line sprite? Actually DXY0 draws 16 pixels tall? Wait CHIP-8: N is height from 0 to 15? If N=0, draws 16? I recall DXYN: draw sprite with N bytes. If N=0, draws 16 bytes? Many modern: N=0 means 16 height (SuperChip uses 16x16 sprites? Actually SuperCHIP high-res uses 16x16 with DXY0? Yes). Original CHIP-8 only N 1-15? Many implement N=0 as 16 for compatibility with SCHIP. Need include. For CHIP-8 canonical: n=0 may be implementation-defined; recommended treat as 16 for SCHIP. But if spec sheet for original CHIP-8, N=1..15, N=0 reserved? Need comprehensive include note.\n\nEx9E, ExA1.\nFx07, Fx0A, Fx15, Fx18, Fx1E, Fx29, Fx33, Fx55, Fx65.\n\nNeed maybe include 0x00FB, 0x00FC scroll right/left? Those are SuperCHIP not CHIP-8. Could mention not part of base.\n\nFont data: Standard 8x5 hex font, 80 bytes, typically at 0x000 or 0x050. Could include bytes: 0xF0,0x90,0x90,0x90,0xF0 for 0; 0x20,0x60,0x20,0x20,0x70 for 1; etc. Let's list maybe. Need ensure accuracy:\n0: F0 90 90 90 F0\n1: 20 60 20 20 70\n2: F0 10 F0 80 F0\n3: F0 10 F0 10 F0\n4: 90 90 F0 10 10\n5: F0 80 F0 10 F0\n6: F0 80 F0 90 F0\n7: F0 10 20 40 40\n8: F0 90 F0 90 F0\n9: F0 90 F0 10 F0\nA: F0 90 F0 90 90\nB: E0 90 E0 90 E0\nC: F0 80 80 80 F0\nD: E0 90 90 90 E0\nE: F0 80 F0 80 F0\nF: F0 80 F0 80 80\nGood.\n\nNeed maybe specify display coordinate wrap. Let's investigate original. CHIP-8 display: Draw at coordinate (Vx, Vy), width 8 height N. If pixel is off when XOR, VF=1. If pixel exceeds screen boundaries, it may wrap around? Some docs: \"If the coordinate is off-screen, it wraps around. If the sprite extends beyond the bottom, it wraps.\" Hmm. But not all. For spec, define reference behavior: x = Vx & 63, y = Vy & 31? But drawing rows if y+n > 32? Could wrap each pixel y coordinate modulo 32. For x each bit maybe wrap? Since row byte width 8; if x near 63, bits wrap to left? Some implementations clip if x > 56? Actually common: wrap? Let's recall CHIP-8 draw: for each row, for each bit, if xPos+bit < width and yPos < height then xor. Some no wrap. Original COSMAC VIP? The video memory is 64x32 bits, address computed? If coordinate wraps maybe due to 6-bit x and 5-bit y? Could be modulo. Let's not state absolute. We can say \"Reference behavior for compatibility: mask/wrap coordinates modulo display size; many modern interpreters optionally clip. Specify your implementation.\" But user asked spec sheet; we can choose normative. Could define \"Baseline CHIP-8: wraps both axes modulo 64x32. Super-CHIP: clips.\" Is that accurate? Hmm.\n\nMaybe safer: \"Original CHIP-8 display coordinates are typically treated modulo the display dimensions; many modern implementations provide clipping as a compatibility option. This spec defines wrap as normative for pure CHIP-8.\" Need be okay.\n\nNeed mention memory I range 12-bit? I is 16-bit but CHIP-8 memory only 4096; effective address I & 0xFFF. FX1E can set I beyond? If I is 16-bit, could >0xFFF; memory accesses mask. Some set VF on overflow. Need specify.\n\nProgram counter: 16-bit but memory 4096; PC masked? If jump beyond? Should mask to 12-bit or undefined. Define effective PC = value & 0xFFF. But instructions use nnn 12-bit so PC within. BNNN adds V0 can exceed 4095; mask. Could note.\n\nStack: 16 levels. CALL pushes PC (after +2). RET pops. SP increments/decrements. Overflow/underflow behavior undefined; recommended trap/no-op.\n\nRandom: CxNN uses implementation-defined PRNG; deterministic not specified. Should say should be random enough, not cryptographic.\n\nKey FX0A: need semantics: If no key pressed, PC repeats instruction? Usually decrement PC by 2 or not increment? Implementation: wait by not advancing until key event. It should store key code 0x0-0xF. Should ignore key repeats? Define key down event. Need note if multiple keys pressed: store first/lowest? Implementation-defined. For deterministic tests can hook.\n\nTimers: DT, ST loaded with Vx. At 60Hz, if >0 decrement. Sound active while ST > 0. If ST loaded with 0 no beep. If DT/ST loaded with >0 beep maybe after tick. Could mention.\n\nInstruction timing: For compatibility, use instruction scheduler: execute 1 opcode per cycle at 500 Hz? Let's think. The CHIP-8 technical reference by Thomas Daley? Many emulators do 10-15 cycles? Original? The CPU is interpreter on 1.76 MHz COSMAC VIP, so each CHIP-8 instruction many machine cycles. Effective instruction rate often 500 Hz for games. But some use 1000 Hz too fast. Need spec maybe: \"No canonical fixed instruction rate; typical 500–1000 opcode/s. Timers must be 60 Hz.\" For spec sheet maybe include recommended: 700 Hz? But comprehensive should mention configurable. Could include \"default 500 Hz for classic timing\".\n\nNeed maybe include bit-level opcode decoding. Could include pseudocode. Let's craft robust.\n\nPotential pitfalls: Need not overstate \"CPU\". Need markdown. Need include table of opcodes maybe large but okay. Need maybe include cycle/flag effects. Need include variants/quirks table.\n\nLet's outline final:\n\n# CHIP-8 “CPU” Specification Sheet\n\n## 1. Scope\nCHIP-8 is a bytecode VM / interpreter, not silicon CPU. This spec defines classic CHIP-8 execution environment.\n\n## 2. Architecture summary\n- 8-bit registers, 16-bit address, 4KiB memory, 16x12-bit stack, 64x32 1bpp display, 16 keys, 2 timers.\n\nTable.\n\nASCII block diagram.\n\n## 3. Memory map\nTable:\n0x000-0x1FF reserved (interpreter, font). 0x200-0xFFF program RAM.\nFont locations. Endianness.\n\n## 4. Programmer-visible registers\nTable: V0-VF, I, PC, SP, DT, ST, stack.\nVF details.\n\n## 5. Reset and initial state.\n\n## 6. Instruction format\n2 bytes big-endian. Bit fields table. PC behavior. Skip behavior.\n\n## 7. Instruction set\nMaybe grouped tables with full opcode. Need be comprehensive. Could use columns: Opcode, Mnemonic, Operation, Flags/Notes.\nNeed ensure no missing.\n\nLet's detail opcodes:\n0NNN | SYS nnn | ignored/no-op | None. Original machine call to RCA 1802.\n00E0 | CLS | clear display to black | none\n00EE | RET | PC = stack[SP]; SP-- | none\n1NNN | JP nnn | PC=nnn | none\n2NNN | CALL nnn | push PC+2; PC=nnn | none\n3XNN | SE Vx, kk | if Vx==kk skip next | none\n4XNN | SNE Vx, kk | if Vx!=kk skip | none\n5XY0 | SE Vx, Vy | if Vx==Vy skip | none\n6XNN | LD Vx, kk | Vx=kk | none\n7XNN | ADD Vx, kk | Vx=Vx+kk wrap | VF unchanged\n8XY0 | LD Vx, Vy | Vx=Vy | VF unchanged (modern)\n8XY1 | OR Vx, Vy | Vx|=Vy | modern VF=0\n8XY2 | AND | &= | modern VF=0\n8XY3 | XOR | ^= | modern VF=0\n8XY4 | ADD | Vx += Vy; VF=carry | carry\n8XY5 | SUB | if Vx >= Vy VF=1 else 0; Vx-=Vy | not borrow\n8XY6 | SHR | VF=Vx&1; Vx>>=1 | LSB. Optional Vy quirk\n8XY7 | SUBN | if Vy >= Vx VF=1 else 0; Vx=Vy-Vx | not borrow\n8XYE | SHL | VF=Vx>>7; Vx<<=1 | MSB. Optional Vy quirk\n9XY0 | SNE | if Vx != Vy skip | none\nANNN | LD I,nnn | I=nnn | none\nBNNN | JP V0,nnn | PC=nnn+V0 | none\nCXNN | RND Vx,kk | Vx=(rand & kk) | none\nDXYN | DRW Vx,Vy,n | sprite at I, n rows, XOR, VF=collision | VF=1 if erased; n=0 as 16 optional\nEX9E | SKP | if key Vx pressed skip | none\nEXA1 | SKNP | if key Vx not pressed skip | none\nFX07 | LD Vx,DT | Vx=DT | none\nFX0A | LD Vx,K | wait key, Vx=key | none\nFX15 | LD DT,Vx | DT=Vx | none\nFX18 | LD ST,Vx | ST=Vx | none\nFX1E | ADD I,Vx | I+=Vx | optional VF overflow\nFX29 | LD F,Vx | I=font address for digit Vx & 0xF | none\nFX33 | BCD Vx | mem[I]=hundreds, [I+1]=tens, [I+2]=ones | none\nFX55 | LD [I], V0..Vx | store regs | I behavior quirk\nFX65 | LD V0..Vx, [I] | load regs | I behavior quirk\n\nNeed include invalid opcodes: 0x0000 maybe ignored; unused: 0x0? DXY0? FX?? no. Define illegal as no-op or trap.\n\n## 8. Display subsystem\n- 64x32 framebuffer, coordinate system, pixel order, drawing algorithm, collision, font, timing. Maybe include font table.\n\n## 9. Input subsystem\n16-key keypad mapping, key codes 0-F, key state.\n\n## 10. Timers/sound\n60Hz, square wave.\n\n## 11. Timing and performance\nInstruction rate. Cycle model: fetch-decode-execute. No interrupts. Timers independent.\n\n## 12. Compatibility quirks\nTable: shift source, logical VF, load/store I increment, I overflow VF, 0x0000, DXY0 height, display wrap/clip, key wait.\n\nNeed be detailed but not too enormous. However user asked comprehensive spec sheet, so opcode table enough.\n\n## 13. Implementation pseudocode\nMaybe include pseudo for core loop and draw. Good.\n\n## 14. Conformance requirements.\n\nNeed maybe include \"electrical/mechanical\"? Since CPU quote, maybe \"Not applicable: virtual CPU\". Could include \"package: software ROM/RAM\". Spec sheet style could include absolute max ratings joke? But user likely wants technical spec. Could include \"No silicon\". Keep professional.\n\nNeed ensure markdown valid. Use tables. Long table maybe okay. Need avoid too wide? Fine.\n\nLet's think of correctness more deeply.\n\nCHIP-8 history: original on COSMAC VIP had 16 hex keypad, 64x32 display, sound buzzer. CPU: RCA CDP1802 at 1.76 MHz. But CHIP-8 itself is an interpreted language with opcode size 16-bit. \"CPU\" maybe refers to virtual CPU. Spec sheet should mention \"CHIP-8 CPU is typically implemented by interpreter\". Maybe include if one were to build hardware: data path 8-bit ALU, address 16-bit, opcode fetch 16-bit, microcode? Could provide spec for hardware implementation. But likely user expects CHIP-8 CPU spec. Need maybe include \"CPU core\" details for emulator: registers, opcodes.\n\nLet's consider if \"CHIP-8 CPU\" includes \"opcode 0x0000\"? Some emulators treat as infinite loop? On original, opcode 0x000 is SYS 000 which may jump to interpreter? But many ignore. For spec, say \"0x0000 should be treated as NOP for compatibility unless implementing RCA 1802 native calls.\" Good.\n\nStack pointer: Some docs say SP is 8-bit, but stack entries are 12-bit? Could be 16-bit. In CHIP-8, memory addresses 12-bit, so stack addresses are 12-bit, but typical emulator uses 16-bit stack array. SP points to top. On CALL: stack[SP] = PC; SP++. PC = addr. On RET: SP--; PC = stack[SP]. Some definitions SP points to next free? We can define normative. Need mention reset SP=0. Max depth 16. If SP would exceed 16, undefined; recommended ignore/trap.\n\nPC behavior: Fetch opcode at PC and PC+1, then PC = (PC + 2) & 0xFFF. Then if instruction sets PC, overrides. If skip, PC = (PC + 2) & 0xFFF. This is common. Need mention \"some interpreters increment PC after execution, but observable behavior is equivalent if skip/call handled carefully.\" For spec, define pre-increment.\n\nMemory: 4096 bytes, addresses 0x000-0xFFF. If I + X exceeds 0xFFF, address wraps/masks? For FX33, FX55, FX65, DXYN? Drawing reads from I..I+n-1, should wrap? Many implementations mask each address. Define effective address = (I + offset) & 0xFFF. Need mention. For FX55/FX65 if I unchanged vs increment, if address wraps, etc.\n\nBCD: mem[I] = Vx/100, mem[I+1] = (Vx/10)%10, mem[I+2] = Vx%10.\n\nRND: Vx = random & kk. Random generator not specified. For testability, expose seed.\n\nKeys: Key code is Vx lower nibble. If Vx > 0xF, use Vx & 0xF.\n\nFX0A: Wait for keypress. Common: if no key pressed, PC -= 2 to repeat. If key pressed, store. If multiple keys, choose lowest or first. If key held before instruction? Usually requires new key press? Many emulators check current key state and if any down store. This can cause immediate. Spec can say: \"A key transition from up to down should satisfy the instruction; implementations may accept currently held keys.\" For compatibility, maybe \"any key currently pressed\" because games? Hmm. Let's define normative: waits for a key-down event; if already pressed may be accepted as event? Need not be too rigid. Could say implementation-defined, but for deterministic tests define key-down event. Need maybe \"blocking: no further instructions execute until a key is accepted.\"\n\nDisplay drawing algorithm detail:\nFor row r=0..height-1:\n spriteByte = mem[(I+r)&0xFFF]\n for bit c=0..7:\n if spriteByte & (0x80 >> c):\n px = (Vx + c) mod 64\n py = (Vy + r) mod 32\n old = fb[py][px]\n new = old XOR 1\n if old == 1 and new == 0: VF = 1\n fb[py][px] = new\nBefore draw VF=0? Usually VF set to 1 if collision else 0. Yes, DRW sets VF=1 if any erased, else 0. Need specify VF=0 initially for draw. Some quirks? Yes.\n\nIf n=0: height=16 for SCHIP; if pure CHIP-8, height=0? Many docs: n is height, range 1-15. But if n=0, many implementations use 16; if height=0, no draw and VF=0. For comprehensive, say \"For base CHIP-8, N=0 is reserved and should be treated as height 0 or as implementation-defined; for SCHIP compatibility, treat as 16.\" But if spec wants normative, choose one. Maybe \"Recommended: N=0 draws 16 rows\". But classic CHIP-8 games don't use. If we define as 16, it is modern/SCHIP. Could be okay if comprehensive. But to avoid wrong, note option. In opcode table: DXYN: if N=0, height is 0 in strict original or 16 in common SCHIP-compatible mode; spec default: 16? Hmm.\n\nMaybe define \"Base CHIP-8 height = N rows; if N=0, no pixels are drawn.\" Then \"Compatibility extension: many systems treat N=0 as 16 rows.\" But comprehensive might include both. We can have a column \"Notes\" and quirks.\n\nShift quirks: Need more precise. Some original implementations shift Vy not Vx: For 8XY6: \"If the quirk shift_y is enabled, Vx = Vy >> 1; otherwise Vx >>= 1.\" If enabled and x != y, Vx gets shifted Vy. Some also preserve Vy? Yes. Need note.\n\nLogical VF quirk: For 8XY1-8XY3 modern clear VF; original may leave VF unchanged? Need include. Some also 8XY0? Some \"vfOrder\" quirk: \"VF is reset before logic op\"? Hmm.\n\nLoad/store quirk: FX55/FX65: original increments I to I+X+1? Let's investigate to avoid misinformation. Modern CHIP-8 docs from Tobias? Many say \"I is not changed.\" But Octo's quirk \"loadStore\" says \"On the COSMAC VIP, load/store increments I by X+1; many CHIP-8 programs assume I unchanged?\" Let's search memory: I know from emulation: There is quirk \"CHIP-8 legacy: load/store leave I unchanged\" vs \"SuperChip: I increments by x+1\"? Wait. Let's recall actual: Cowgod's technical reference says for FX55: \"The interpreter increments I by X + 1 after execution.\"? Or \"I is increased by 1 for each value written, and left unchanged after operation\"? Let me think of common emulator code: Many implement `for i=0..x memory[I+i]=V[i]` and do not modify I. Some compatibility flag \"vfOrder\", \"shift\", \"logic\". Another quirk \"loadstore\" in Chip8 emulator? Some CHIP-8 programs expect I to be incremented? Example: Spacefight 2091 uses FX55? Hmm. There are known quirks:\n- `quirk_sf`: shift instructions set Vx = Vy? \n- `quirk_load`: increment I after FX65? \n- `quirk_store`: increment I after FX55?\nMaybe original VIP increments I after store/load? Let's find from memory: In CHIP-8, FX55: \"stores V0 through VX (including VX) in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation.\" Wait that phrase could be from Cowgod: It says \"The full 16-bit content of I is incremented by x+1, but only the lower 12 bits are used\"? No.\n\nLet's reason from hardware? CHIP-8 on COSMAC VIP: I is a memory pointer register. FX55 might use auto-increment? It might leave I at I+x+1 because easier. But many modern docs say I unchanged. Which behavior is required by programs? There are test ROMs that detect. Octo options: `-s` superchip? There are quirks: `shift`, `logic`, `loadstore` maybe. \"In the original CHIP-8 implementation, the index register is incremented by load/store, while in CHIP-8 on the COSMAC VIP?\" Need be accurate.\n\nLet's recall from Octo documentation: \"quirk load-store: In the original CHIP-8 interpreter, the index register I is incremented by load/store operations, but CHIP-8 programs written for later interpreters expect I to remain unchanged.\" Or vice versa. Actually I remember using Chip-8 emulator: option \"Set I = I + X + 1 after FX55/FX65\" is for SCHIP? Let's search mental: There is a known quirk \"store/load should not increment I\". Many emulators have config \"Original CHIP-8 behavior: increment I on load/store\". Modern CHIP-8 (CHIP-48/SCHIP?) maybe leaves unchanged. Which is original? The original COSMAC VIP manual might say I is incremented? Hmm.\n\nCowgod's technical reference (v5.0) says:\nFX55: \"Store V0 to VX in memory starting at address I. The index register I is increased by 1 for each value written, and left unchanged after operation.\" Wait left unchanged? That is contradictory; maybe \"increased\" means internal pointer during operation, but after operation original I remains? It may be because I is copied to a temporary and incremented, but I register not changed. Modern interpreters preserve I. But some tests show some ROMs expect I incremented? Need not decide; list quirk.\n\nLet's check known CHIP-8 test ROMs: \"Flags and quirks\" from corax89: tests shift, load/store. The CHIP-8 spec by John? It says: \"FX55 and FX65: I is incremented by X+1 on the original CHIP-8 interpreter. Most modern interpreters leave I unchanged, but this breaks some original ROMs.\" Hmm.\n\nMaybe the original COSMAC VIP had no separate I? Actually CHIP-8 interpreter used register I as memory pointer. The VIP had DMA register? It might be easier to increment I. I found memory: \"CHIP-8 has two timer quirks: delay timer decrements at 60 Hz. The original VIP had a quirk where Fx55 and Fx65 increment I by X+1.\" Yes, there is a \"quirk_load\" in chip8 emulator: \"On the COSMAC VIP, Fx65 increments I by X+1 after loading registers; on modern interpreters I is unchanged.\" There is also \"quirk_store\" for Fx55. Some ROMs like \"Rocket Launch\" maybe rely? Need not know.\n\nSpec: We can define canonical modern behavior: I unchanged after FX55/FX65. Include quirk: original VIP/SCHIP may increment I by X+1. But if spec is \"CHIP-8 CPU\" maybe original? Could say \"Historically ambiguous; define your implementation.\" Comprehensive includes both.\n\nFX1E overflow VF: In SuperCHIP, if I + Vx > 0xFFF, VF=1, else 0; I wraps? Actually I is 16-bit, addition may overflow 12-bit but not 16. Some docs: \"If I + Vx > 0xFFF, VF = 1, else VF = 0. This quirk is only implemented in some interpreters.\" Need mention. If I > 0xFFF, memory accesses mask. Modern CHIP-8 often leaves VF unchanged. Some SuperCHIP uses VF overflow. Need note.\n\nDXYN collision: VF set if pixels erased; if drawing outside? If clipped, no collision for off-screen? In wrap, collisions can happen. Need state.\n\nKeyboard mapping: Typical PC keys: 1234/QWER/ASDF/ZXCV to hex keypad. But not part of spec. Could include recommended mapping.\n\nSound: Single-channel square wave/buzzer. Frequency not specified. Recommend 4000 Hz? Original beep simple. Need state.\n\nMaybe include \"electrical characteristics\" as not applicable. But spec sheet maybe fun: \"Technology: software interpreted; process: N/A\". Could include. But avoid too silly.\n\nNeed maybe include \"Instruction cycle timing\" for hardware implementation:\nFetch: 2 bytes from memory at PC, big-endian. Decode: bits. Execute. Timers tick asynchronous. For CPU core, need opcode register, ALU 8-bit, adders, random, timers. But not necessary.\n\nNeed maybe include \"Example: opcode 0x1230: PC = 0x230\".\n\nNeed maybe include \"Program assembly format\"? Maybe not.\n\nNeed maybe include \"Memory alignment\": instructions must start at even? CHIP-8 PC starts at 0x200 and increments by 2, jumps to even? nnn can be odd? Actually addresses are 12-bit, but if PC odd, instruction fetch misaligned? CHIP-8 doesn't require alignment? PC can be set to odd by BNNN? nnn plus V0 may be odd if V0 odd. If fetch from odd and next even? It could work but interpreters often fetch PC and PC+1, so odd is okay? But original? Most code even. For spec, say \"Programs conventionally use even addresses; odd PC values are legal in this spec but not recommended; fetch uses consecutive bytes.\" Good.\n\nNeed maybe include \"No memory protection\". Good.\n\nLet's craft comprehensive markdown. Need maybe include table of contents? Not necessary but can. Use headings.\n\nLet's ensure opcode table not too wide. Could split into groups: 0x0, jumps, math, memory, display/input, FX. But one table easier. Need maybe include bitfields before.\n\nDetailed flag effects: Maybe separate table.\n\nPotential missing opcode: 0xFX??: FX0C? Not valid. 0x0? DXYN with N=0? OK.\n\nNeed maybe include \"SYS\" is not executed as CHIP-8; original calls machine language routine. Modern should ignore. But if writing spec, maybe mention `0NNN` calls RCA 1802 machine code routine at nnn in native VIP environment. In CHIP-8-only, no-op.\n\nNeed maybe include \"CHIP-8 has no interrupts; however display refresh and timers may be host-driven.\"\n\nNeed maybe include \"Memory mapped display? No, separate framebuffer.\" Original VIP had video RAM in main memory? CHIP-8 display uses memory? The interpreter draws to screen, not memory-mapped in programmer model. Spec can say display framebuffer is separate from the 4KiB address space; not directly accessible except DRW. Original maybe video RAM? But CHIP-8 abstracts. Good.\n\nNeed maybe include \"Font sprite address: FX29 sets I to base + digit*5. Common base 0x000 or 0x050. For this spec, canonical base 0x000; many modern use 0x050 to avoid conflict. Implementations must document base.\" Maybe spec should choose canonical? Could choose 0x000? But many emulators load font at 0x050 to leave 0x000 free? In original, font stored in interpreter area 0x000-0x1FF, often at 0x000. The low 0x1FF reserved, so any location is okay as long as FX29 works. For spec sheet, define \"font base implementation-defined within reserved region; FX29 returns address; standard font bytes listed.\" Good.\n\nNeed maybe include \"Program load address 0x200\". Some programs loaded at 0x200, 0x600 for SCHIP? Base: 0x200.\n\nNeed maybe include \"Memory size 4096 bytes; upper addresses maybe RAM.\" Good.\n\nLet's maybe include \"Conformance: required instructions\" and optional quirks.\n\nLet's think if we need include exact bit encodings for all opcodes? Table includes opcode pattern. Use `nnn`, `kk`, `x`, `y`, `n`.\n\nCould include pseudocode:\n```\nfunction step():\n opcode = (mem[pc] << 8) | mem[pc+1]\n pc = (pc + 2) & 0xFFF\n switch opcode & 0xF000:\n ...\n```\nBut maybe too long. Could include draw pseudocode.\n\nNeed final answer just markdown. It can be long. Good.\n\nDouble-check opcodes:\n- `8XY5`: If Vx > Vy, VF=1 else 0? Actually not borrow: if Vx >= Vy, no borrow, VF=1. For equal, VF=1. Then Vx=Vx-Vy. Correct.\n- `8XY7`: Vx = Vy - Vx; if Vy >= Vx VF=1 else 0. Correct.\n- `8XY6`: VF=LSB of Vx before shift. If quirk shift Vy, VF=LSB of Vy before shift? If Vx = Vy >> 1, VF set to LSB of Vy? Some implementations set from Vx? Need say canonical: source operand's LSB. If using Vy source, VF = source LSB. Similarly SHL source MSB.\n- `DXYN`: sprite data from I to I+N-1. If N=0, in SCHIP height 16; else height 0? For table, mention.\n- `FX29`: If Vx is e.g. 0xA, lower nibble. `I = font_address + (Vx & 0xF) * 5`.\n- `FX33`: Does not change Vx. Uses decimal digits. Good.\n- `FX55`: Store V0..Vx. If X=0 stores V0. Does not change registers. I behavior quirk.\n- `FX65`: Load V0..Vx. If X=0 loads V0. I behavior quirk.\n\nNeed maybe include \"All arithmetic modulo 256 unless flags specified.\"\n\nNeed maybe include \"Skip instructions: The skipped instruction is completely not executed; if skipped instruction is DXYN? no.\"\n\nNeed maybe include \"When instruction both sets PC and skip? none.\"\n\nNeed maybe include \"0x00E0 clears framebuffer and maybe resets VF? No.\"\n\nNeed maybe include \"0x00EE does not clear stack.\" Good.\n\nNeed maybe include \"BNNN uses V0; not VX.\" Good.\n\nNeed maybe include \"CXNN random AND kk, not modulo.\" Good.\n\nNeed maybe include \"EX9E/EXA1 key index masked to 0-F.\" Good.\n\nNeed maybe include \"FX0A if key code is stored in Vx, lower nibble of Vx? It stores 0-F.\" Good.\n\nNeed maybe include \"No DMA, no memory-mapped I/O.\" Good.\n\nMaybe include \"Host responsibilities: refresh display after each draw/timer; sample sound while ST>0; poll keys.\" Good.\n\nNeed maybe include \"Compatibility modes: CHIP-8, CHIP-48, Super-CHIP, XO-CHIP not covered.\" Could mention extensions.\n\nLet's think about spec sheet style: Could include \"Part number\"? Maybe not. But \"comprehensive spec sheet\" maybe like datasheet: General Description, Features, Pinout? For CHIP-8 virtual CPU no pinout. We can add a \"Ordering information / variants\"? Maybe overkill. But user said CPU in quotes, so maybe they expect playful but technical. We can include \"Package: source code/software; no pins\". But keep professional.\n\nPotential issue: final answer too long? It's okay. Need maybe avoid too many caveats but include quirks.\n\nLet's write final with headings. Need ensure markdown tables not broken. Use monospace for opcodes.\n\nDetailed sections:\n\n1. Identification\n```\nArchitecture: 16-bit opcode, 8-bit data, 12-bit address\nProgram origin: 0x200\nMemory: 4096 bytes\nDisplay: 64x32 1bpp\nInput: 16 keys\nTimers: 2 x 8-bit @ 60Hz\n```\n\n2. Block diagram ASCII.\n\n3. Address space and memory.\n\n4. Registers.\n\n5. Reset.\n\n6. Opcode encoding.\n\n7. Instruction set.\n\n8. Display.\n\n9. Keyboard.\n\n10. Timers/sound.\n\n11. Timing.\n\n12. Quirks.\n\n13. Implementation notes/pseudocode.\n\n14. Conformance.\n\nLet's craft. Need maybe include \"Table: VF flag summary\".\n\nLet's ensure final answer doesn't mention analysis. Use English. Need no code of analysis.\n\nLet's start final.\n\nNeed decide normative choices:\n- We'll present a \"Reference implementation profile\" with defaults. For ambiguous items, say \"Implementation-defined/quirk\" and recommend defaults. That satisfies comprehensive.\n\nDefaults for reference:\n- `0x0000` NOP.\n- `8XY1-8XY3` clear VF; `8XY0` unchanged.\n- Shifts operate on Vx (not Vy).\n- FX55/FX65 leave I unchanged (modern common). But maybe original increments. We can state default modern; original quirk optional.\n- FX1E leaves VF unchanged unless overflow quirk enabled.\n- DRW N=0: height 16? For pure CHIP-8 reference maybe height 0? But compatibility with SCHIP common. Need choose default? For comprehensive, maybe define \"CHIP-8 base: N = height in rows (1-15). N=0 is reserved; for maximum compatibility, implementations may implement N=0 as height 16. This spec's canonical CHIP-8 profile treats N=0 as height 0 unless SCHIP compatibility is enabled.\" But many tests? Games don't use N=0. If we treat N=0 as height 0, a SCHIP ROM would fail, but that's extension. The user asked CHIP-8, so okay. But maybe \"comprehensive\" should include N=0 as 16. Let's define a \"CHIP-8/SCHIP compatible\" default: N=0 height 16. But if strict original, no. Hmm.\n\nMaybe include \"Height is N rows; if N=0, behavior is historically ambiguous. Recommended for broad compatibility: height=16. Strict original profile: height=0.\" That's safe.\n\nDisplay wrap: We can define \"Reference wraps both axes; optional clip.\" But many modern emulators clip by default? Let's see. If coordinates wrap, drawing at x=60 with 8px wraps. Some games rely? Probably not. The original COSMAC VIP likely wraps due to modulo? We can say \"Historical CHIP-8 commonly wraps; SCHIP clips.\" Good.\n\nFX55/FX65 default: broad compatibility? Many modern docs say I unchanged; but some original ROMs expect increment? Need define quirk. Maybe default \"leave I unchanged\" because most homebrew and docs. But \"original\" maybe increment. Could say \"Most modern CHIP-8 implementations leave I unchanged; original VIP behavior may increment. Provide compatibility switch.\" Good.\n\nFX1E default: no VF; optional overflow.\n\nKey wait default: accept key-down event; if key already held maybe not? To avoid repeated immediate, but many emulators check state. For compatibility, accept any currently pressed key. Hmm. Let's state \"A key-down event or any currently pressed key may satisfy; implementation must document.\" But for spec, define \"current key state\" maybe easier. Many CHIP-8 games use FX0A to wait; if key held, they might continue, not issue. Good.\n\nNeed maybe include \"When DT/ST decrement: if loaded with 1, becomes 0 after next tick; sound stops when ST becomes 0.\" Good.\n\nLet's produce final. Ensure table syntax correct. Use code fences for pseudocode.\n\nNeed maybe include font table. Could be large but okay. Use code block with hex lines.\n\nLet's draft final in mind:\n\n```\n# CHIP-8 \"CPU\" Specification Sheet\n\n## 1. Overview\n...\n```\n\nNeed maybe include note: \"CHIP-8 is not a physical CPU; the 'CPU' is a virtual processor/ISA.\"\n\nLet's craft with enough detail.\n\nOne thing: `0x0NNN` is SYS. If opcode is 0x0000, some emulators infinite loop if PC not advanced? If we define NOP and PC already advanced, fine.\n\nInstruction table might have `VF` column. Need avoid too wide. Use separate notes.\n\nMaybe include opcode table as:\n\n| Encoding | Mnemonic | Operation | Notes |\n|---|---|---|---|\n\nFor `DXYN`, operation text long but okay.\n\nNeed include all opcodes but maybe group by high nibble. Good.\n\nLet's write.\n\nDouble-check if `FX0A` stores key value in Vx and then continues. Does it also wait for key release? Some docs: \"All execution stops until a key is pressed.\" It doesn't wait release. But some emulators wait keydown and keyup? Need specify not release. Good.\n\nNeed include \"Key values 0x0-0xF; keypad layout standard 4x4.\"\n\nNeed include \"Recommended host key map: 1 2 3 C / 4 5 6 D / 7 8 9 E / A 0 B F\" maybe.\n\nLet's maybe include \"Display refresh: host should render framebuffer after each draw; no direct pixel access.\" Good.\n\nPotential issue: Some CHIP-8 docs say `8XY1`, `8XY2`, `8XY3` set VF to 0 because original? Actually original COSMAC VIP might set VF to 0? Need say \"modern reference clears VF; some historical implementations leave VF unchanged.\" Good.\n\nNeed maybe include \"For `8XY4` ADD with immediate? No carry from `7XNN`.\" Good.\n\nNeed maybe include \"All registers are 8-bit except I and PC 16-bit; effective addresses 12-bit.\" Good.\n\nLet's write final. Ensure no missing closing. Use bullet list.\n\nNeed maybe include \"Opcode invalid: recommended no-op and log; not skip.\" Could be important. If invalid, PC already advanced. For undefined opcodes, don't corrupt state. Good.\n\nNeed maybe include \"Memory writes are immediate; no cache.\" Good.\n\nLet's produce final with robust content.","format":"unknown","index":0}]},"native_finish_reason":"stop"}],"created":1785796520,"model":"qwen/qwen3.8-max","object":"chat.completion","service_tier":null,"system_fingerprint":null,"usage":{"completion_tokens":21288,"prompt_tokens":63,"total_tokens":21351,"completion_tokens_details":{"accepted_prediction_tokens":null,"audio_tokens":0,"reasoning_tokens":11803,"rejected_prediction_tokens":null,"image_tokens":0},"prompt_tokens_details":{"audio_tokens":0,"cached_tokens":0,"cache_write_tokens":0,"video_tokens":0},"cost":0.127854,"is_byok":false,"cost_details":{"upstream_inference_cost":0.127854,"upstream_inference_prompt_cost":0.000126,"upstream_inference_completions_cost":0.127728}},"provider":"Alibaba"}

Random comp.