Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

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.