128 BYTES. Not KB. Not MB. Bytes.

Those 128 bytes of RAM were used for two things: Self-modifying code, and data storage. For example, Pitfall uses 2 bytes for the score, 2 bytes for the time, 2 bytes for the lives (2 lives, but it's faster than using an AND) ONE byte for the current area, etc.

However, they had a far more manageable 4 KB of ROM, so there was plenty of room for routines.

They had no framebuffer. The screen was drawn by hardcoded routines, with specific hardware support for certain registers.

There were 5 special display registers.

2 "Player" registers which were 8 bit, and would be automatically displayed at a certain portion of the scanline. (You chose location, color and graphics before the line drew)
2 "Missile" registers which were 1 bit. (Think 1-pixel bullets) also with configurable colors per-line.
1 "Ball" register. Effectively a missile register, but with more features. Player and Ball registers could be reflected or repeated in certain locations. Missiles could not. Balls could also be stretched in two directions so as to be on more scanlines without the effort of drawing them there.

Other than those, there were 40 playfield blocks, at 1/4 the resolution of the rest of the screen. These all had the same color, unless you changed it between each scanline, and when redrawing one, you had to redraw all of them. The purple and grey blocks on that image are playfield blocks.

If you want more info on this stuff watch this video. Very informative.



So, a quick explanation of EVERY graphic on that screenshot.

The background color is being changed every few scanlines, thus the shift from lighter to darker browns.

The Purple and grey blocks are Playfield blocks, with the playfield color changing occasionally.

The player, key, and little box thing are all drawn using the player registers. Between each scanline, the graphics are changed, and between each sprite, so are the colors. You will never see more than 2 unique 8*x sprites on any line, but space invaders for the atari shows how you can get multiple duplicated sprites.

The black lines at the edge are actually a bad thing. It means their routines took too long, and they missed part of the scanline.

No problem.

My favorite part about the pitfall video I linked: 256 bytes of level data stored in a 50 byte algorithm. He calls it a reversible polynomial counter. Basically, he can increment or decrement it and it becomes an apparently nonrelated number.

Best part: Since the counter only needs to store a byte in RAM at a time, the whole routine is in the 4 KB of ROM.

I guess maybe they just didn't know how to do it right, but somehow knew it would work in that state and coders would just deal with it. I'M glad better stuff came out afterward, though.

So, TheNlightenedOne, have you started to make something or are you planning to start?

What are your projects? Are they calc-related too?

Btw we might have to live with the possibility that there will never ever be any other emulator released for the Nspire. Such project takes so much work. That's why since 1990 there have been only like 10 completed calculator RPGs that are not written in TI-BASIC or Axe and why there are only two people who ever released console emulators on the Nspire. To even stand a chance at having a SNES/Sega Genesis emu for the Nspire in the next decade, Omnimaga would need at least 1000 registered users logged in at once on a regular basis and 20K posts a day, then we could hopefully find one person in the member list who is interested and dedicated enough.

True, but it seems that even then very few people seem to want to take on such task. The few who do usually cancel the project before a single line of code is written.

Oh lol ok then, 7 lines of code. But yeah people get the idea. And a developer team would still require good management. Most team projects tend to die more often than solo projects unless incredibly massive (by massive I mean commercial Playstation 3 games, for example).