{"id":18071,"date":"2026-05-19T16:40:57","date_gmt":"2026-05-19T20:40:57","guid":{"rendered":"https:\/\/scruss.com\/blog\/?p=18071"},"modified":"2026-05-19T16:40:57","modified_gmt":"2026-05-19T20:40:57","slug":"the-broken-basic-years","status":"publish","type":"post","link":"https:\/\/scruss.com\/blog\/2026\/05\/19\/the-broken-basic-years\/","title":{"rendered":"The Broken BASIC Years"},"content":{"rendered":"\n

I polled Mastodon people a few weeks back:<\/p>\n\n\n\n

\"mastodon<\/figure>\n\n\n\n

Twice as many people said their home computer’s BASIC did something illogical as said it did the right thing. What gives?<\/p>\n\n\n\n

The de facto<\/em> problem<\/h2>\n\n\n\n

BASIC was refined over several years in the mid-1960s as part of the Dartmouth Time-Sharing System<\/a> (DTSS) running on a GE mainframe. It was intended to be accessible to all students at Dartmouth. Responsiveness to user commands was valued over performance. The concept caught on, and by 1970 DEC, HP, IBM and GE all had time sharing BASIC systems in the market.<\/p>\n\n\n\n

The language was simple enough that if you’d used it before on another system, you’d have a good idea how it should look. Implementations of BASIC sprung up on lots of computer systems based on whatever documentation was at hand: if you were lucky, maybe a photostat of a Dartmouth BASIC manual<\/a>, or maybe one of the programming manuals<\/a> that DEC sold for their PDP-8 systems. <\/p>\n\n\n\n

The original BASIC ran on a mainframe computer with each line being compiled into separate jobs by a terminal server. Early microcomputer developers, however, saw BASIC as something they could fit into a few thousand bytes as an interpreter. With so little space to work in, and so few guidelines to work from, implementation rules became very blurred. Here’s what you might have expected to see if you fired up your 8K Altair 8800 some time in 1976 after buying a shiny new (and $$) copy of Altair BASIC:<\/p>\n\n\n\n

MEMORY SIZE? 8192\nTERMINAL WIDTH? 80\nWANT SIN-COS-TAN-ATN? N\n\n1862 BYTES FREE\nALTAIR BASIC REV. 4.0\n[EIGHT-K VERSION]\nCOPYRIGHT 1976 BY MITS INC.\nOK\n10 FOR X=3 TO 2 STEP 1\n20 PRINT X\n30 NEXT X\n40 PRINT X\nRUN\n 3 \n 4 \nOK\n<\/code><\/pre>\n<\/div>\n\n\n\n
With so little memory to play with, the FOR X=3 TO \u2026<\/em> is effectively treated as LET X=3<\/em>, and NEXT X<\/em> becomes LET X=X+1<\/em> (with an optional GOTO 20<\/em> if X < 2, which it never is). The 1975 Altair BASIC Manual<\/a> has a slightly more lucid description on page 32, but doesn’t explain why<\/u> it does this. Maybe it was influenced by FORTRAN-66, which always executed a DO<\/em> clause once.<\/p>\n\n\n\n
The only guidance against this admittedly illogical behaviour is hidden away on page 37 of the Dartmouth BASIC 4th Edition manual<\/a> from 1968:<\/p>\n\n\n\n
\"text:
No, I can’t get past that the Os are slashed and the 0s are not, either<\/figcaption><\/figure>\n\n\n\n
So in a feat of mass emulation (and sometimes using real vintage hardware), here are some BASIC systems that always<\/strong> execute a FOR<\/em> loop at least once:<\/p>\n\n\n\n