The example linked in the post has a lot of issues. It seems to be case‑sensitive (it errors on `Screen` instead of `SCREEN`), a simple `GOTO` loop can lock up the VM (in real QB you can break out with Ctrl+Break), doesn't attempt any real emulation of `PEEK` and `POKE` memory access, and its flood-fill algorithm is fundamentally broken for `PAINT`.
Try this out:
SCREEN 12
N = 14
R = 220
FOR i = N TO 1 STEP -1
CIRCLE (320, 240), R * i / N, i
PAINT (320, 240), i
NEXT
Ouch.
It also suffers from the same fundamental problem most online QBasic emulators have (Qb.js is another well‑known example): they’re essentially compilers. For those of us who grew up with QBasic, one of its biggest strengths was that it was an interpreter. It loaded extremely fast, you could set breakpoints on the fly, and it had immediate feedback.
Another huge part of the original experience was integrated help. If you didn’t understand a command, you slapped that F1 key and got instant context‑sensitive help right inside the IDE.
I’m actually working on a truly browser‑native QBasic environment. It uses a virtual CPU plus a typed AST built from the original BAS source, so you can start and stop execution just like in classic QBasic. It’s pretty much feature‑complete at this point.
My goal is to have an online QBasic IDE that behaves with one‑to‑one parity with QBasic 1.1, and optionally lets you switch the interpreter to QuickBasic 4.5 for more advanced features like including `.BI` library files. I’ve already built a hardware abstraction layer that can mimic VGA memory/registers, BIOS interrupts, and even a COM modem. It’s about 95% feature‑complete at this point (DONKEY, GORILLA, NIBBLES all run perfectly)
One of the core design goals is full round‑trip compatibility: if you write a program in this web‑based IDE, you should be able to take the BAS file to an original 386 running QBasic and have it behave exactly the same and vice versa.
The example linked in the post has a lot of issues. It seems to be case‑sensitive (it errors on `Screen` instead of `SCREEN`), a simple `GOTO` loop can lock up the VM (in real QB you can break out with Ctrl+Break), doesn't attempt any real emulation of `PEEK` and `POKE` memory access, and its flood-fill algorithm is fundamentally broken for `PAINT`.
Try this out:
Ouch.It also suffers from the same fundamental problem most online QBasic emulators have (Qb.js is another well‑known example): they’re essentially compilers. For those of us who grew up with QBasic, one of its biggest strengths was that it was an interpreter. It loaded extremely fast, you could set breakpoints on the fly, and it had immediate feedback.
Another huge part of the original experience was integrated help. If you didn’t understand a command, you slapped that F1 key and got instant context‑sensitive help right inside the IDE.
I’m actually working on a truly browser‑native QBasic environment. It uses a virtual CPU plus a typed AST built from the original BAS source, so you can start and stop execution just like in classic QBasic. It’s pretty much feature‑complete at this point.
My goal is to have an online QBasic IDE that behaves with one‑to‑one parity with QBasic 1.1, and optionally lets you switch the interpreter to QuickBasic 4.5 for more advanced features like including `.BI` library files. I’ve already built a hardware abstraction layer that can mimic VGA memory/registers, BIOS interrupts, and even a COM modem. It’s about 95% feature‑complete at this point (DONKEY, GORILLA, NIBBLES all run perfectly)
One of the core design goals is full round‑trip compatibility: if you write a program in this web‑based IDE, you should be able to take the BAS file to an original 386 running QBasic and have it behave exactly the same and vice versa.
Small teaser demonstration:
https://imgur.com/a/7CwBF22
Thanks for the feedback. I've resolved the issue.