LOAD "PL/CBMBASIC",8,1: Commodore 64 BASIC for PostgreSQL
Skip to main content
LOAD "PL/CBMBASIC",8,1: Commodore 64 BASIC for PostgreSQL
Get link
Other Apps
July 03, 2026
If you are of a certain age, the words 38911 BASIC BYTES FREE will do something to you that no amount of therapy can undo. You remember the blue screen. You remember typing in three pages of a listing from a magazine, getting ?SYNTAX ERROR IN 2340, and not knowing which of the three pages contained the typo. You remember that the disk drive was device 8, and that it was slower than continental drift.<br>I have some news. All of that now runs inside PostgreSQL.<br>PL/CBMBASIC is a procedural language extension that executes function bodies on Commodore 64 BASIC V2. Not a lookalike, not a tribute act: the actual Microsoft/Commodore interpreter from 1982, by way of Michael Steil's cbmbasic project, which statically recompiled the 6502 ROM into C. That C is compiled straight into the extension's shared library, so the interpreter lives inside your backend process. Every function call is an in-memory power cycle: zero the 64KB RAM array, reset the CPU registers, and re-enter the ROM at $E394. The whole ceremony costs about 15 to 20 microseconds, which is roughly a thousand times faster than the hardware ever managed, and quick enough to call per row over a large table without feeling guilty.<br>CREATE EXTENSION plcbmbasic;
CREATE FUNCTION hello(who text) RETURNS text AS $$<br>10 PRINT "HELLO, ";WHO$;"!"<br>$$ LANGUAGE plcbmbasic;
SELECT hello('WORLD'); -- HELLO, WORLD!Yes, those are line numbers. Yes, they are mandatory. User code starts at line 10, like nature intended, because lines 0 to 9 are reserved: the extension injects your function arguments there as ordinary BASIC assignments before your code runs. A text parameter named who arrives as WHO$, a smallint named lives becomes a genuine 16-bit LIVES%, and everything numeric otherwise lands in a 40-bit CBM float, all nine glorious significant digits of it.<br>The validator has opinions, because BASIC V2 had opinions<br>Anyone who programmed a C64 for more than an hour discovered that you could not have a variable called TOTAL. The tokeniser crunched keywords anywhere, including inside identifiers, so TOTAL contained TO and became garbage. SCORE contained OR. BUDGET contained GET. Only the first two characters of a name were significant, so USERNAME and USERID... actually those were fine, US$ and US are different variables, but ALPHA and ALPS silently became the same string. And TI and ST were taken by the system.<br>The extension ships a validator, so PostgreSQL now delivers these opinions at CREATE FUNCTION time instead of leaving you to rediscover them at runtime:<br>ERROR: parameter name "total" contains the BASIC keyword TO<br>HINT: This is why nobody could ever have a variable called TOTAL<br>on the Commodore 64.Some traumas deserve better error messages than we got the first time round.<br>OUT parameters, by walking the variable table<br>When a BASIC program ends, its variables are still sitting in the emulated 64KB of RAM. So for OUT and INOUT parameters, the handler does the only reasonable thing: it walks BASIC's own simple-variable table, the 7-byte entries between VARTAB at $2D/$2E and ARYTAB at $2F/$30, decodes the type-encoded name bytes, and converts the 5-byte floats, 16-bit integers, and string descriptors back into SQL values.<br>CREATE FUNCTION divmod(num int, den int, OUT quot int, OUT rmd int) AS $$<br>10 QUOT=INT(NUM/DEN)<br>20 RMD=NUM-QUOT*DEN<br>$$ LANGUAGE plcbmbasic;
SELECT * FROM divmod(47, 5); -- quot | rmd<br>-- ------+-----<br>-- 9 | 2PEEKing another process's memory for its results is not a pattern I expect to see in the PostgreSQL documentation any time soon, but it feels deeply right here.<br>The database is device 8<br>Here is the part I am most pleased with. On a Commodore 64, your data lived on the disk drive, device 8, and you spoke to it with OPEN, INPUT#, GET#, PRINT#, CLOSE, and the ST status variable. So in PL/CBM-BASIC, device 8 is the database. The "filename" you OPEN is an SQL statement, executed through SPI inside your transaction:<br>CREATE FUNCTION top_scores() RETURNS text AS $$<br>10 OPEN 1,8,0,"SELECT NAME, SCORE FROM HISCORES ORDER BY SCORE DESC"<br>20 INPUT#1,N$,S<br>30 IF ST<>0 AND N$="" THEN 60<br>40 PRINT N$;" ";S<br>50 IF ST=0 THEN 20<br>60 CLOSE 1<br>$$ LANGUAGE plcbmbasic;Column values stream back one CR-terminated record at a time, and ST picks up the EOF bit (64) on the final byte, the same way it did from a 1541. The read-until-done loop you wrote in 1985 works unchanged, including the part where you had to be careful about empty files, which is what line 30 is doing.<br>It gets better. Secondary address 15 was the drive's command channel, the one you would PRINT# DOS commands to and read 00, OK,00,00 back from. That works too:<br>10 OPEN 15,8,15<br>20 PRINT#15,"DELETE FROM HISCORES WHERE SCORE The status record is 0,OK,,0, in honour of the original. Each PRINT# appends and the...