Well look at the rich guy here with a disk drive.
---
TBH, my first computer, a second-hand C64, did come with a disk drive (and a monitor!!), but that was in the early 90s, several years after the heyday of the sixty-four.
This question is being answered all over the Internet every day and I love it.
If you are of a certain age, the words 38911 BASIC BYTES FREE will bring memories flooding back. You remember the blue screen that you had spent hours staring at, and all those games in magazines that you could type in line by line, and not really understanding most of what you're even typing. You remember that the disk drive was device 8, and that you had time to go make a cup of tea before it would finish loading.
All of that now runs inside PostgreSQL.
PL/CBMBASIC is a procedural language extension that executes function bodies on Commodore 64 BASIC V2. 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 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 thing costs about 15 to 20 microseconds, which is roughly a thousand times faster than the original C64 ever managed, and quick enough to call per row over a large table without too much waiting.
CREATE EXTENSION plcbmbasic;
CREATE FUNCTION hello(who text) RETURNS text AS $$
10 PRINT "HELLO, ";WHO$;"!"
$$ LANGUAGE plcbmbasic;
SELECT hello('WORLD'); -- HELLO, WORLD!
Yes, those are line numbers, and they are mandatory. User code starts at line 10, 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 ends up as WHO$, a smallint named lives becomes a LIVES%, and everything numeric otherwise lands in a 40-bit CBM float.
Anyone who programmed a C64 discovered that you could not have a variable called TOTAL. The tokeniser truncated keywords, including inside identifiers, so TOTAL contained TO. 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.
The extension ships a validator, so PostgreSQL now delivers these opinions at CREATE FUNCTION time instead of leaving you to rediscover them at runtime:
ERROR: parameter name "total" contains the BASIC keyword TO
HINT: This is why nobody could ever have a variable called TOTAL
on the Commodore 64.
When a BASIC program ends, its variables are still sitting in the emulated 64KB of RAM. So for OUT and INOUT parameters, the handler uses 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.
CREATE FUNCTION divmod(num int, den int, OUT quot int, OUT rmd int) AS $$
10 QUOT=INT(NUM/DEN)
20 RMD=NUM-QUOT*DEN
$$ LANGUAGE plcbmbasic;
SELECT * FROM divmod(47, 5); -- quot | rmd
-- ------+-----
-- 9 | 2
PEEKing another process's memory for its results is not a pattern I expect to see in the PostgreSQL documentation any time soon.
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:
CREATE FUNCTION top_scores() RETURNS text AS $$
10 OPEN 1,8,0,"SELECT NAME, SCORE FROM HISCORES ORDER BY SCORE DESC"
20 INPUT#1,N$,S
30 IF ST<>0 AND N$="" THEN 60
40 PRINT N$;" ";S
50 IF ST=0 THEN 20
60 CLOSE 1
$$ 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 (like the 1541 did).
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:
10 OPEN 15,8,15
20 PRINT#15,"DELETE FROM HISCORES WHERE SCORE < 1000"
30 INPUT#15,EN,EM$,RC,ES
The status record is 0,OK,<rows>,0, same as the original. Each PRINT# appends and the terminating CR executes, so you can build statements longer than BASIC's 255-character string limit by sending them in pieces. INSERT, UPDATE, DDL, whatever you like. It is an untrusted language for superusers only.
Runtime errors are trapped through the interpreter's own ERROR vector at $0300, the same plugin mechanism Simons' BASIC used, so a mistake returns a proper PostgreSQL error carrying the ROM error code:
ERROR: BASIC error: ?DIVISION BY ZERO ERROR IN 20
And because the KERNAL's STOP routine (the RUN/STOP key scan, polled before every statement) is patched to CHECK_FOR_INTERRUPTS(), the immortal 10 GOTO 10 dies cleanly to statement_timeout.
I benchmarked identical functions against PL/Python. PL/Python wins, as you would expect from a language that keeps a warm interpreter around instead of rebooting a Commodore 64 for every function call: roughly 14 to 19 times quicker on trivial calls, narrowing to about 6 times on a workload that queries 100 rows from inside the function, where both sides have the same SPI overhead. But the C64's floor is that 15 microsecond power cycle, which puts it in the same cost bracket as a non-inlined SQL function, and the interpreter gets through about a million BASIC statements per second. The machine this ROM shipped on managed about a thousand.
It is ancient C64 BASIC in there, so everything is uppercased, including string literals, because the C64's default character set had no lower case as such. Strings top out at 255 characters. Floats have nine significant digits. There is no NULL, it arrives as an empty string, and you can COALESCE in the query if you care. INPUT raises an error, because there is no keyboard attached to your database. POKE and SYS work against the emulated 64KB if you enjoy danger, and POKEs only have an effect until the next call's power cycle.
The code is at github.com/darkixion/pl-cbmbasic.
READY.
ā