These days, the word efficiency is often used as decoration. People talk about lightweight code, slim architectures, modern frameworks and performance as if picking the right stack were enough to be virtuous. The VIC-20, instead, left no room for rhetoric: with about 3.5 KB of RAM available to the user, every choice became immediately concrete.
The case was very simple and very real. My uncle Ottavio took part in Portfolio, the prize game published by La Repubblica. Every day you had to check the numbers printed in the newspaper and compare them with about 200 cards. By hand, it was slow, repetitive and error-prone work. In the house, however, there was a Commodore VIC-20. Not a powerful machine, not a workstation, not a “comfortable” system: a home computer with a MOS 6502 CPU at around 1 MHz, built-in BASIC and very little free memory.
The point was not to “write a program”. The point was to fit both program and data inside a limit that is ridiculous by today’s standards. Today a single icon can weigh more than all the working memory that was available on that machine. On the VIC-20, instead, you had to think as if every byte had a personality, a function and a bill to pay.
The problem wasn’t computation, it was data
Checking 200 cards didn’t require any exotic algorithm. You had to read the combinations, enter the numbers published in the newspaper, compare, and flag any matches. The real constraint was representation. If you wasted memory on convenient but heavy structures, the program would die before it even started.
The solution was to use BASIC in the most direct way possible: the cards were entered into the program as DATA lines, then read with READ. No database, no external files, no useless abstractions. The data lived in the code, compressed into the most accessible form for that machine and that language. It wasn’t elegant by modern standards, but it was exactly the kind of elegance that matters when the limit is physical.
The flow was essential: the program contained the cards, the user typed in the day’s numbers, the VIC-20 scanned the combinations and reported the winning ones. There was nothing to “scale” in the modern sense of the word, and yet everything you really need in a useful system was there: input, data model, verification, output.
Efficiency as design, not as slogan
That experience teaches something many modern environments tend to hide: efficiency does not appear at the end, when you “optimize”. It starts at the beginning, when you decide how to represent the problem. On a small machine, a bad choice doesn’t just produce a slower program. It produces an impossible program.
The VIC-20 forced you to ask questions that are still very relevant today: what data do I really need? How many times do I have to read it? Can I avoid useless copies? Am I using a structure because I need it or because it makes me feel safer? BASIC was limited, yes, but precisely for that reason it made the cost of every decision visible. One unnecessary line was space stolen from the program. An overly wide representation meant one fewer card. Confused logic was time lost rereading code on a screen that didn’t forgive much.
This is not nostalgia for hardship. Nobody in their right mind misses limits just for sport. The point is something else: when you learn to program under a real constraint, you keep the habit of distinguishing between necessary complexity and ornamental complication. And that skill is useful even when you work on modern servers, databases, automations, AI or CMS platforms: the hardware changes, but entropy is always there waiting.
From newspaper game to useful code
The key moment wasn’t technical in the strict sense. It was operational. That program wasn’t a homework exercise and it wasn’t a demo to show that the computer could “do things”. It solved a very specific household problem: checking a lot of Portfolio cards without going through a small manual torture every day.
This changes how you look at code. The computer stops being a fascinating object and becomes a lever. You take a repetitive process, describe it, have a machine execute it, and free up human time. On a tiny scale, it was already automation. With less memory than a fragment of a modern web page, the VIC-20 was doing what useful systems still do today: taking a boring job and making it verifiable.
RetroLab exists partly for this reason. Not to put old machines under glass, but to remember that those systems taught with a very productive harshness. The VIC-20 did not let you cover a weak project with libraries, RAM or generous interfaces. It forced you to understand the problem before you wrote. If you got it wrong, there was no profiler to save you: there was a blinking cursor and a hard memory limit.
What really changes
The lesson from the Portfolio program is not that “people coded better back then”. That would be a convenient and fairly false line. The lesson is that constraints make technical thinking measurable. On an unexpanded VIC-20, using DATA and READ to store about 200 cards wasn’t a romantic choice: it was a project survival strategy.
Brought into the present, that mindset is still valuable. Before adding a framework, a service, a queue, an agent or an AI layer, you need to ask whether the problem model is already clear. The VIC-20 didn’t just teach you to save bytes. It taught you not to lie to yourself about the shape of the problem. And that, in 2026, is still a very concrete form of efficiency.
In short
- The Portfolio program on VIC-20 was born from a real problem: checking about 200 cards every day.
- The main constraint was memory: about 3.5 KB available for program and data.
- The solution used
DATAlines and reading withREAD, avoiding needlessly heavy structures. - The technical lesson is not nostalgia for limits, but deliberate design under real constraints.
- Efficiency means choosing the right representation of the problem even before you optimize the code.
Sources and context
- AndroidLab/OpenClaw editorial memory: documented account of Michele Dipace’s Portfolio program on VIC-20.
- RetroLab: AndroidLab retrocomputing lab
- Related: BebboSSH on AROS and retrocomputing as a real lab