Is it possible to read video memory? No biggie, I just find myself wanting to occasionally write tests and the only thing I can't check is what was actually drawn.
Not directly. On the COSMAC VIP, the framebuffer was located within addressable memory. This isn't the case with modern interpreters.
More generally, a CHIP-8 program can examine its own frame buffer by drawing a pixel at a time to the screen and checking vF afterwards to determine whether a pixel was toggled.
If your goal is automated testing and you're familiar with JS, you could probably hack up something using Octo's compiler and emulator in a "headless" fashion; they shouldn't have any direct dependencies on browser APIs.
It simply wasn't part of the original interpreter spec.
Other implementations (including CHIP-48 and SCHIP) didn't put the screen memory (and other stuff) at the same locations. Any program that relies on the screen memory location would only work in that specific interpreter. (Some early CHIP-8 games for the VIP might rely on this.)
In fact, the location of the screen memory changed in the original COSMAC VIP interpreter based on how much memory the computer had, since the interpreter's variables (including the screen memory) was always lcoated at the end of the addressable memory space.
One reason was that originally the only way to access display memory in Chip8 was to write 1802 MLS code. I did that a lot. If the purpose of those routines were known, then the functionality could maybe be emulated, but there's little point in emulating the actual 1802 subroutines since they are surely hardware dependent.
This was one of my concerns in writing my emulator MyChip8 in which there are two kinds of memory space relating to the display: that used by the interpreter, and that used by the library OpenGL code that I used to create the display animation. (Qt handles page swapping automatically for a very smooth result.) The interpreter's display memory is simply a 64x32 byte array, and therefore already incompatible with the original Cosmac bitmap display memory. But you could access it in the C++ interpreter code for a special purpose.
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?