The original "Wormy", written by a young man named Matt Gokey, was a Commodore 64 game (written in BASIC) in which the player would move a snake around the screen to collect all the goodies while avoiding mines (or his tail). Very much like Commodore's VIC-20 game Slither, except that the screen was filled with non-moving goodies and obstacles rather than having randomly-appearing targets. My first real game on the PC (CGA) was a variation called "Wormy II", which smoothly animated the snake's motion at 60fps, added various power-ups and power-downs, and allowed the player to control the snake's speed (above a minimum controlled by level and power-ups/power-downs). It also featured a nice rendition of a tune I'd written at music camp some years previously.The 2600 Wormy was planned to be closer to the original (no power-ups or power-downs) but feature the smooth motion and speed control from Wormy II. It would also feature a slightly-shrunk playing area (32x16 instead of 38x20). At the time I designed it, I was unaware of Tapeworm (which is the 2600 game closest to it) but the game as planned has a number of differences from that cart:

• All objects for a level (up to 128, randomly placed) will be placed at the start and shown on screen,
• Good and bad objects will be visually distinct from the snake's tail, without flicker, using striped playfield colors.
• Snake should move at least somewhat smoothly, using a player/missile sprite for the snake's head and the Ball for the tail, and player will control the snake's speed.
• None of the annoying critters that appear randomly and cross the screen.

What makes this interesting is that a 32x16 playfield, showing up to 128 objects, where each square can be black (empty), green (snake), red (mine), or green+red (goodie) would seem to take up 128 bytes of memory, leaving none for anyything else. Nonetheless, I have a proof-of-concept kernel that works to display precisely that.The trick is to allow eight objects (good or bad) per line, using one byte per line to hold a present/not-present indicator for each. The distribution of those eight objects among the 32 squares on the line is controlled by a pseudo-random generator which is 'run' while the screen is drawn. Thus, instead of taking 128 bytes, the screen takes 80 bytes plus the random seed. That at least leaves some space for other things, but there's still a lot to store and not much room to store it.There's more I could say on the subject, but that will be in another entry.