It wouldn’t fit (with hires)… only worked originally because 64x32 = 256 bytes leaving 256 bytes for the interpreter (and font), all in the reserved first 512 bytes.
Hires would require 1KB of buffer ram… (
Not quite; the screen memory was not located in the first 512 bytes. (Neither was the font, which was in the VIP OS.) That only contained the interpreter code itself, but no variables. On the COSMAC VIP, the 256 bytes of screen/frame buffer were located in the last 352 of the addressable memory, along with variables for the V and I "registers" and other data. This location changed depending on how much memory the VIP had, which is probably one reason it wasn't included in the spec.
There were in fact even some "hires" CHIP-8 interpreters for the COSMAC VIP, such as "CHIP-10". That was unproblematic, as long as the VIP had enough memory. Although, the way the "Pixie" video chip worked, the resolution was 64x128 instead of 128x64 (because each pixel was fewer scanlines tall).
So when you use the opcode to fetch the address of the a font character… are you saying that CHIP8 memory access was entirely (or partially) abstracted on the VIP? Or just that modern interpreters do that entirely differently?
Most interpreters I’ve seen all place the font somewhere in the first 512 bytes so that after fetching the address i would always be guaranteed to be less than 512, etc… pointing into the “reserved” portion of RAM…
I always got the impression from reading the technical stuff that i was pointing to REAL memory locations… the whole reason programs start at 0x200 instead of 0 was because the interpreter itself was literally using that RAM on the host system.
The real VIP had a 16-bit address space which was mostly unpopulated. The VIP "OS" resided in a ROM which was outside the 4kb of RAM that CHIP-8 can easily access, but you could still manipulate i to point there via repeated addition or, in the case of the font, via the instruction Octo calls "i := hex vx".
I linked the manual, which contains memory maps, earlier in the thread.
You are correct in that `i ` pointed to real memory locations, and that programs start at 0x200 because the CHIP-8 interpreter was using that RAM on the COSMAC VIP. However, on the VIP, the font characters weren't located in the interpreter, but in the VIP's own OS or monitor program (CHIP-8 simply reused the VIP's font). The original CHIP-8 specification didn't specify where the font was (or should be) located, so in a way it was "abstracted" away. The value of `i` after using the font opcode was, in a sense, undefined.
Modern interpreters do it differently. Somewhere along the line, people decided to put the font in the now unpopulated memory region that used to be occupied by the interpreter. After all, why not, if the spec doesn't say where it should be?