Sneekie

Watch the bytes move

Sneekie has no "snake object". The snake, the walls, the hearts and the arrows are just characters living in the screen's memory, and the game reads and writes that memory directly. Steer below and watch it happen: the screen on top and the raw memory beneath it are the same bytes. Every move is a few peeks and pokes — shown live on the right. Eat a heart and a club pops up somewhere; the four arrows patrol on their own.

A Sneekie playfield connected to a glowing text video memory grid.

Each cell is two bytes (character, then a brightness/color attribute), addressed by offset = (row − 1) × 160 + (col − 1) × 2. This is a 22×15 corner of the real 80×25 screen — same formula, same 160-byte row stride.

The screen — what you see
Operations (this move)
Steer
The memory — the byte in each cell

That's the whole trick behind the 1988 code. See it in the source on the explained page, or next to the JavaScript port on the migration page.

PEEK and POKE beams pulling 3D hearts, clubs, arrows, stones, and snake segments from video memory.

The glyphs behind the bytes

Every character you just watched move — the snake, the walls, the heart — is one of 256 glyphs baked into the same IBM VGA 8×16 ROM font the game draws with. Each glyph is 16 bytes, and each byte is one row of 8 pixels: a bit that is on lights a pixel. That whole font is embedded right in game.js. The coloured glyphs are the ones Sneekie actually pokes into video memory — hover or tap any cell to take it apart.

CP437 — all 256 glyphs
Take a glyph apart
Code
Hex
Character
In Sneekie
16 bytes → 16 rows of pixels
A CRT font explorer showing a CP437 glyph grid, one selected heart glyph enlarged into pixels, and its 16 byte rows.