So your first Picotron cart runs. Now what?

Last time I walked through the basics — the specs, the desktop, a three-line hello world, a dot you can push around with the arrow keys.

If you went through that and got the dot moving, you cleared the only bar that actually matters on day one: does the thing run. Nobody's proud of a moving dot, though, and nobody's opening the BBS to admire your moving dot either. This is the part after that — the part the first piece skipped on purpose because it was already long enough. Turning a running cart into something you'd actually save, what the desktop buys you that a plain code editor doesn't, and what a reasonable next project actually looks like once hello world stops being impressive.

The desktop is the part a specs table can't show you

It's easy to skim past the desktop in the excitement of getting Lua to run at all, but it's the single biggest practical difference between Picotron and PICO-8, and no comparison table captures it. PICO-8 gives you one screen that flips between the code editor and the running game with a keypress — cute, minimal, and also basically the entire interface. Picotron doesn't do that. It's windows: your code editor, your running cart, a terminal, whatever else you've opened, sitting next to each other, resizable, like an actual (very small) computer instead of a single-purpose toy.

In practice that means you can watch your cart run in one window while editing the code in another, instead of alt-tabbing your own brain between two states of the same screen. Save the file and the running window updates without you leaving the code — no context switch, no "wait, which mode am I in." It sounds like a small convenience until you're twenty minutes into a bug and realize you haven't lost your place once. That's the whole reason Lexaloffle calls this thing a workstation instead of a console, and it's also, not coincidentally, why people describe working in it as calming rather than fiddly — the machine gets out of the way of the part you're actually trying to do.

From one dot to sixteen

Take the dot from the first piece — the one you push around with the arrow keys — and give it a life of its own instead of a joystick. Bouncing it off the screen edges is maybe ten minutes of work, and it stops looking like debug output and starts looking like a thing:

local x, y, dx, dy

function _init()
  x, y = 240, 135
  dx, dy = 2, 1.4
end

function _update()
  x += dx
  y += dy
  if x < 8 or x > 480 - 8 then dx = -dx end
  if y < 8 or y > 270 - 8 then dy = -dy end
end

function _draw()
  cls(1)
  circfill(x, y, 8, 12)
end

Nothing new here syntactically — same _init/_update/_draw shape, same circfill, same +=. The only new idea is velocity: instead of reading the keyboard every frame, dx and dy carry a direction and flip when the dot hits an edge.

One bouncing dot is cute for about thirty seconds. A screen full of them is where it gets interesting, and the change costs almost nothing — a Lua table standing in for what would otherwise be a dozen copy-pasted variables:

local balls = {}

function _init()
  for i = 1, 16 do
    balls[i] = {
      x = rnd(480), y = rnd(270),
      dx = rnd(4) - 2, dy = rnd(4) - 2,
      c = 8 + i % 8,
    }
  end
end

function _update()
  for _, b in ipairs(balls) do
    b.x += b.dx
    b.y += b.dy
    if b.x < 6 or b.x > 480 - 6 then b.dx = -b.dx end
    if b.y < 6 or b.y > 270 - 6 then b.dy = -b.dy end
  end
end

function _draw()
  cls(1)
  for _, b in ipairs(balls) do
    circfill(b.x, b.y, 6, b.c)
  end
end

rnd(n) returns a random number between 0 and n, the same call PICO-8 Lua uses, so if you've touched that before, this part is free. Everything else is just "do the single-dot logic, but once per entry in a table." Run it and you've got sixteen colored dots drifting around and bouncing off the walls forever — which, arguably, is the first thing in this whole exercise that's actually watchable on its own, rather than a demonstration of a mechanic. Leave it running in a window in the corner of the desktop while you do something else in another window, and it stops being a toy example and becomes exactly the kind of small interactive doodad the first piece said Picotron was actually good for — the stuff that isn't quite a game.

Why the extra colors and the bigger screen actually matter

The spec sheet from part one mentioned 64 definable colors against PICO-8's fixed 16, and a 480×270 canvas against PICO-8's 128×128. Those numbers sound like marketing until you notice what they let you do that a 16-color palette can't: shade something instead of just outlining it. Sixteen colors is enough for flat, iconic pixel art — PICO-8's whole visual identity is built on that constraint — but it isn't enough for a smooth gradient or a soft light source without dithering tricks. Sixty-four is enough to fake both. The bigger canvas has a similar effect on layout rather than art: at 128×128, almost anything you draw is the whole screen, so there's no real concept of "a window within the screen." At 480×270 you can genuinely have a HUD in one corner and a play area that isn't the entire display, the way an actual 16-bit-era game would.

None of that makes Picotron "better." It makes it suited to a different kind of project — something with a UI, or shading, or multiple screens' worth of visual information — while PICO-8 keeps rewarding the opposite instinct: fit the whole idea into almost nothing. Knowing which constraint you're picking is more useful than knowing which console is more powerful.

Saving it as something you'd actually show someone

Once something like the ball screensaver exists, the next question is what to do with it, and this is where the .p64 / .p64.png split from part one stops being trivia. Save it plainly — save balls.p64 from the terminal — and you've got a cart on disk, the same shape as PICO-8's .p8 text carts: readable, diffable, easy to back up. Pack it as a .p64.png instead and the cart becomes an image: something you can drop in a folder or send to someone, and the picture is the program. That's not a gimmick. A screenshot that's also a working piece of software is a much easier thing to hand someone than a file with instructions attached, and it's a big part of why these carts spread the way they do — the "cart as its own advertisement" idea PICO-8 popularized carries over intact.

The BBS is smaller than you'd expect, and that's the point

Where you'd actually hand a cart to someone is the Lexaloffle BBS, and it's worth saying plainly: it's small. This isn't itch.io with its infinite scroll, or a subreddit with a firehose feed. It's closer to a clubhouse — you'll recognize usernames if you spend any time there at all, and a lot of the Picotron section is still people figuring the machine out in public rather than showcasing finished work. That's not a knock on it. A small BBS means a table of bouncing colored dots posted today is genuinely visible instead of buried on page forty, and the PICO-8 side of that same BBS has close to a decade of proof that a small, close community outlasts whatever hype cycle got people in the door in the first place. Post the screensaver. Somebody will ask how you did the color cycling, and that one question is worth more than a hundred silent downloads.

Early access is a feature you'll actually feel

The other thing nobody mentions until it happens to them: Picotron is still active alpha / early access, and that's not a footnote you can skim past the way you would on a finished product. It means an update can change something underneath a cart you already saved, and the fix is sometimes on you, not on Lexaloffle. That's less scary than it sounds — it's the direct tradeoff for a platform that's still visibly getting better every few weeks instead of shipping once and going quiet — but it's real, and it changes how you should think about anything you build right now: as a snapshot of what you learned this month, not a permanent artifact. A short tutorial on handling auto-updates gracefully is genuinely more useful at this stage than another "look what I built" showcase:

And if the two code examples above went by too fast and you want to see the whole environment worked through slowly, start to finish, this seminar-length walkthrough is worth the longer runtime — it's the closest thing to sitting next to someone who already knows the machine:

Past the screensaver

A table of bouncing dots is a fine second project, but it's still just physics. The genuinely different thing about Picotron, compared with almost every other fantasy console in this series, is that "game" isn't the only category it's built for — part one's own framing was games, animations, music, demos, and "other curiosities," and that last phrase is doing real work. A tiny always-on clock rendered in big pixel digits. A one-button ambient noise generator built entirely on the tracker. A palette-cycling generative pattern you leave running as a desktop background inside the desktop. None of these are hard, exactly — they're all variations on the same _update/_draw loop from above — but none of them are games either, and that's specifically the space Picotron opens up that a single-purpose console doesn't. If PICO-8 taught you to finish small games, Picotron is a decent place to find out whether you actually enjoy making small things, full stop.

The rest of the links — official site, manual, X, Mastodon, BlueSky — are all in the first piece, so I won't repeat the whole list here. The one worth bookmarking specifically for this stage is the BBS, since it's the only one of the bunch that actually wants something back from you:

• Lexaloffle BBS: lexaloffle.com/bbs