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.

Perfect examples of that happening on more recent games include Harvest Moon 64 (cheapest is $55, cartridge only) and the Zelda Master Quest Gamecube Disc. ($35) Where other games on their consoles go as low as $10

I was under the incorrect assumption that the sectors were smaller than that. Pity.

That doesn't sound impossible to me....

I meant a text editor that loads parts of the files into RAM at a time (Specifically, the part you're looking at) and automatically writes back modifications either once a block is unloaded or when the alteration buffer is full.

In other words, we need a direct-to-archive editor, that Axe supports

5061: You've actually eaten Omni peanuts, and realized they are made from styrofoam.

If we implement the in-place sort, the ID list becomes unnecessary, as it's implied that it goes {0 1 2 3 .. highest ID}

You don't need to draw during the sort. Just sort the list in-place as opposed to creating a new, still unsorted list.

Are there any assumptions we can make about the output list?