Coding a New Basic Interpreter in 2025 to Replace a Slow One
Posted3 months agoActive3 months ago
nanochess.orgTechstory
supportivepositive
Debate
20/100
Basic InterpreterProgramming LanguagesRetrocomputing
Key topics
Basic Interpreter
Programming Languages
Retrocomputing
The author shares their experience of coding a new BASIC interpreter to replace a slow one, sparking a discussion about the history and evolution of BASIC, as well as its continued relevance.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
2d
Peak period
11
48-54h
Avg / period
6
Comment distribution18 data points
Loading chart...
Based on 18 loaded comments
Key moments
- 01Story posted
Sep 28, 2025 at 2:28 PM EDT
3 months ago
Step 01 - 02First comment
Sep 30, 2025 at 6:03 PM EDT
2d after posting
Step 02 - 03Peak activity
11 comments in 48-54h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 1, 2025 at 8:23 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45406645Type: storyLast synced: 11/20/2025, 12:47:39 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Could be one of those with the everlasting ERP type software running on an emulator.
Huh? Don't you need to only change the "next-line-pointer" for the line that's right before the inserted line?
> but the NEXT changed the line, but on the next statement it would lost track and get back to the line following the NEXT. The loops also require their own stack, but including the counter variable address, a pointer to the TO expression, and a pointer to the STEP expression (5 words in total).
Mmm. IIRC, usually the compiled NEXT statement would store the pointer to the corresponding FOR statement, so you don't need an additional stack for loop depth during the execution. But you still need it (or some other sort of chaining) during the program input so whatever.
> Typing the program was difficult, as the keyboard bounced a lot. This happens when you read too fast the keyboard, so fast you can see that effectively the key contact isn't perfect.
Yeah... I've read that keyboard microcontrollers has to deal with contact bounce even today.
I get the impression that they were storing everything sequentially in memory, rather than having a linked list of instructions. Why? I can only speculate. Perhaps it is to make memory management simpler (don't have to keep track of which addresses are in use), or to avoid memory fragmentation in system with limited memory (any modification of code would introduce unusable holes). If that's the case, what you want is an offset rather than an absolute address.
I expect that’s because that is how ‘every’ homecomputer basic did it. Yes, that makes it slow to insert or remove a line close to the start of a long program, but it allow those offsets to be 8 bits, gaining a precious byte over a 16-bit absolute address.
Now, why they initially chose to waste those bytes? I wouldn’t know, but I guess that, because (FTA) “The CP1610 processor cannot address directly the internal memory in byte terms, instead everything is handled by full word”, they didn’t think of using a single byte.
I think you do. Apart from common sense, nothing forbids one from writing stuff like
I think many basics also allowed changing that goto 100 to goto 200 and adding Yes, things would likely end badly, but the basic interpreter would not be smart enough to reject such programs. Its editor didn’t even guarantee that a for statement had a corresponding next or vice versa; all it guaranteed was that the program consisted of a list of lines that each in isolation are valid basic code.I just fired up VICE and my virtual c64 happily ran both of those, if throwing an "out of memory" error after about five runs through the first one counts as "happily".
That will always be the case in hardware. The switch to on will be messy, for example like this:
https://makeabilitylab.github.io/physcomp/arduino/assets/ima...
Can you OOPize it?
- Visual Basic .NET
- PureBasic
- XoJo
- FreeBASIC
- Gambas
- PowerBASIC
You can peruse various implementations, IDEs, and tutorials here: https://github.com/JohnBlood/awesome-basic
https://github.com/JohnBlood/awesome-basic?tab=readme-ov-fil...
It's not as popular as Python, obviously, but that lists over fifty implementations of BASIC.
That book is full of interesting facts and fun low-level tricks for (GW-)BASIC programming. Available for download here: https://github.com/robhagemans/hoard-of-gwbasic
Before reading that I never considered how primitive early BASICs were. There is a lot of linear-searching for things (variables, line-numbers) that has to be considered when optimizing.