esc
Anthology / Yagnipedia / MSX

MSX

The Borrowed Computer, the Video Club, and the First Software Ever Sold
Technology · First observed 1983 (ASCII Corporation and Microsoft — a standardised home computer architecture that Japan loved, Europe tolerated, and riclib borrowed over Christmas at age fourteen); the machine was a Sharp, with two internal 3.5" floppy drives on the right side, shaped like an Amiga 500 · Severity: Foundational (the machine on which the first software was sold, at fourteen, written in POKEd Z80 assembly, beating an IBM PC)

MSX is a standardised home computer architecture from 1983, designed by ASCII Corporation and Microsoft, running a Z80 processor, shipping with BASIC in ROM, and remembered primarily in Japan and parts of Europe. It is remembered in the lifelog for one specific reason: it was the machine on which riclib, at age fourteen, sold his first software.

He did not own an MSX.

“The developer did not own the machine. The developer did not know the BASIC. The developer POKEd Z80 assembly into memory and wrote directly to floppy disk sectors. The developer was fourteen. The developer beat an IBM PC.”
— The Lizard, who has never needed to own the hardware to understand it

The Video Club

The owner of a video rental club — the kind of shop that existed before streaming, where VHS tapes lined the walls and customers rented movies by handing over their membership card and trusting the shopkeeper to write it down — loaned riclib an MSX over Christmas break. The owner needed software. The owner had a computer. The owner had a fourteen-year-old who could program. The transaction was simple: take the machine home, write the software, bring it back.

riclib did not know MSX BASIC very well. The MSX was not a Spectrum. The BASIC was different. The system calls were different. The hardware was different. What was not different was the Z80 processor underneath, and riclib already spoke Z80.

So he did what any Z80 Assembly programmer would do when confronted with an unfamiliar BASIC: he ignored the BASIC. He figured out how to POKE Z80 assembly directly into memory — the same technique that had worked on the Spectrum, the same POKE, the same principle of bypassing the interpreter and talking directly to the machine. The MSX’s BASIC was a language riclib did not know. The MSX’s Z80 was a processor riclib knew intimately, undocumented instructions and all.

The Database

The MSX — a Sharp, if riclib remembers correctly, shaped like an Amiga 500 with the keyboard integrated into the main unit — had two 3.5-inch floppy disk drives, both internal, mounted on the right side. Two. This was, for 1980s home computing, extravagant. And it was the architectural insight that made the software fast.

riclib did not use a file system. File systems are abstractions — they map filenames to sectors, maintain directories, handle allocation tables, and add overhead at every step. The video club software did not need a file system. The video club software needed to store and retrieve records — movie titles, customer names, rental dates — and it needed to do it fast.

riclib wrote directly to disk sectors.

The index — the mapping of what was stored where — was loaded into memory on startup. The entire index, in RAM, accessible at the speed of a Z80 memory read. When a customer rented a movie, the software looked up the record in the in-memory index, calculated the sector on the floppy disk, performed one seek, read or wrote the data, and was done.

Nothing took longer than one disk seek. Not a read. Not a write. Not a rental. Not a return. One seek. On a floppy disk, a seek is measured in tens of milliseconds — the time it takes for the read/write head to move to the correct track. The operation — rent out a movie — took approximately 300 milliseconds. Less than a third of a second. The customer handed over the membership card, the operator typed the movie title, and the rental was recorded before the customer finished putting the card back in their wallet.

This was, without knowing the terminology, a hand-built database engine. An in-memory index with direct sector addressing on the storage layer. No file system overhead. No directory traversal. No FAT table lookup. One index lookup in RAM, one calculated sector address, one disk seek, done. The best index ever built — not because it was sophisticated, but because it was minimal. There was nothing between the query and the data except one multiplication and one seek.

The Competition

The Competition

The video club next door had software too. Proper software. Written on an IBM PC. Running MS-DOS. Stored on a hard drive — the prestige storage medium, faster than floppies, larger than floppies, more expensive than floppies. Real business software on a real business computer.

Every operation took at least ten seconds. Not ten seconds total. Ten seconds each.

Look up customer: ten seconds. The hard drive churns. The operator waits. The customer waits. The hard drive finds the record. The screen updates.

Look up movie: ten seconds. Same churn. Same wait. The customer is still standing at the counter. The operator navigates to a different form — because the software had multiple forms, each one a separate screen, each transition a journey through the MS-DOS application’s menu system.

Record the transaction: ten seconds. Another form. Another write. Another wait.

Between the three ten-second operations and the navigation between forms — the menu system, the form transitions, the “Press Enter to continue” prompts — a single rental took approximately two minutes. Two minutes of a customer standing at a counter watching an IBM PC think about whether it wanted to cooperate.

riclib’s software had a dashboard. One screen. Not multiple forms. Not a menu system. Not a navigation hierarchy. One screen.

Enter customer ID. Enter movie ID. Done.

The in-memory index resolved the customer instantly — no disk seek, the index was in RAM. The movie lookup was instant — same index, same RAM. The transaction recorded to disk in one seek — 300 milliseconds. The software even detected automatically whether the operation was a rental or a return: if the movie was currently marked as rented to the customer, it was a return; if not, it was a rental. No separate “return” form. No mode switch. No “Press F3 for Returns.” The software knew. Enter the two numbers. The software figured out the rest.

If the customer did not know their number — search. By name. In memory. Instant. The index was in RAM. The search was a string comparison loop running at Z80 speed through a few kilobytes of customer records. The result appeared before the operator finished lifting their fingers from the keyboard.

The IBM PC next door: two minutes per rental, three forms, ten seconds per operation, a hard drive that cost more than the entire MSX.

The Sharp MSX: one screen, two numbers, 300 milliseconds, two floppy drives that cost nothing because the machine was borrowed.

This was the first sale. The first software riclib ever sold. Written on a machine he did not own, in a language he POKEd into memory because he did not know the native BASIC, using a storage architecture he invented because he did not know about databases, at an age when most people are learning to drive.

The video club owner got software that rented movies in 300 milliseconds on a single screen. riclib got paid. The video club next door continued to navigate three forms and wait two minutes per rental and did not understand why the shop next door’s queue moved faster.

Measured Characteristics

See Also

See Also