Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

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.

Is there any reason why modern interpreters don't have the framebuffer in addressable memory? Seems handy, but I guess it no program used it the extra space would be more useful. 

(1 edit) (+1)

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.

(+3)

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.