On a related note (of using BASIC where it doesn't belong), I hacked together a method to convert BASIC code to WebAssembly using BaCon[0], a BASIC-to-C converter, and Emscripten to take the resulting C output and generate some wasm.[1] Much like the linked article, this is a fun diversion to entertain the idea of using BASIC where the language authors couldn't possibly have imagined it. Perhaps I'll get around to actually making a "real" project out of it sometime...
This is really interesting, thank you! I've been working the last couple of days on getting an old type-in game working and I had some vague thoughts about it being fun to somehow make it playable on the web. I'd have to convert it from Microsoft BASIC to the dialect BaCon uses, but that's definitely an option. Another option I've considered is to see about getting cbmbasic[0] running using a JS terminal emulator. And of course it might be a fun exercise to just convert them by hand to JS or what have you.
Happy that it could get the juices flowing :) The chosen implementation for your project certainly depends on what "vibe" and level of authenticity you're looking to achieve. I'm a huge fan of WebAssembly simply because the idea of writing web-native code in a language of my choosing makes the little computer scientist in me giddy.
That's not to mention the wealth of existing code with potential to be ported to this universal medium; for example, a project porting vim to WebAssembly was posted to HN just over a week ago[0] which reignited my interest in pursuing this avenue further.
It is my understanding that QB64 [1] compiles through C++, although I haven't tried it myself. They in theory support a superset of QBasic, and you could compile the C++ generated files using emscripten (again, in theory).
It’s slow. All those layers of abstraction exact their toll on latency, even on today’s monster systems.
Reading the essay, my heart goes out to the author: he missed all those wonderful years in the ‘80’s and the early ‘90’s cracking protections, swapping, coding intros, watching demos and competing on the Commodore64, Commodore Amiga and the ATARI ST. He missed out on all the wonderful memories and all the action. I’m saddened by it. He started out on an obscure platform and then switched immediately to a drab, boring, soulless PC bucket, never to experience the joy of the Scene.
For me writing software in BASIC under MS-DOS and later on Windows®️ was an afterthought, since I had already been proficient in MC68000 and MOS 6502 intro coding on Amiga and Commodore64. It was easy to do since I stumbled upon the complete, official reference manual on BASIC 3.0 from Microsoft and I already knew BASIC from learning it on the Commodore PLUS/4. The only piece of software I wrote was an ASCII survey points file to DXF converter which I then ported to VisualBASIC 2.0, and that because I also had the full AutoCAD book set which included full DXF format specification. It cut down our work from several hours to a few seconds, but BASIC on the PC had always been an afterthought for me, something I knew but never used much, or something to whip up a quick utility in and run it from a batch file wrapper.
The Rust Evangelism Strike Force has nothing on the remnants of the once-mighty civilization from the Lost Continent of Amiga. "Oh, you poor benighted soul, how I pity you. Do you not know that the gods spoke in 68000 assembly? If you've never programmed the Copper via a DMA transfer in response to a raster interrupt, then my friend, you haven't truly begun to live."
I was firmly on the side of Atari ST, but I can't help but agree with you on this.
On the Atari side:
Switching screen refresh times in the middle of the line in order trick the graphics chip to not draw the border so you can fill the entire screen with graphics is something every developer should have done, the Amiga with its fancy copper didn't need this.
The one that was the go-to manual back in the days was the Atari Compendium. I still have the book on my shelf.
I have seen digital versions (scans, I guess) floating around online. I don't know how complete they are.
There is still a demoscene for the Atari, although it's of course much smaller these days. You can find some pointers on our group's website: www.dhs.nu
The Rust Evangelism Strike Force has nothing on the remnants of the once-mighty civilization from the Lost Continent of Amiga.
And that is good so, for it means that there are still hidden places on this world where the chaos and evil that is Rust hasn’t reached. May it stay hidden and unsullied by the Darkness, and may the Rust evangelism strike force never spread their foul language there!
Thanks for this fun article :)
I noticed your serverless function response time is between 2000 to 3000ms, I wonder why and it would be super interesting to have more details about time taken by each step of the process (python proxy / dosbox / qbasic / openwhisk)
On a "warm" invocation, almost all the time goes into DOSBox + QBasic.
Not precise measurements but: on my MacBook Pro, running the QBasic interpreter from within DOSBox consistently takes about 1.5 seconds & running DOSBox + QBasic from the shell in "headless" mode takes about 2.4 seconds.
OpenWhisk also gives me the logs of the invocations, which include debug lines produced by DOSBox, and from the timestamps in those I can tell that invocations do typically spend >2s running DOSBox.
I see a few problems in the QuickBasic 4.5 (English) distribution available at antonis.de.
- The BRUN45.EXE file in QB_4_5_E.ZIP is the German version one whereas the other files in this ZIP are the English version ones.
- The original directory layout of QuickBasic 4.5 (INC/, HLP/, LIB/) is missing although all the important content from those directories are preserved in the top-level directory.
- The content of the INC/EXAMPLES/ directory is missing too.
The original distribution is much better preserved at the www.qbasic.net URL I shared earlier. It also contains the English version of QBasic 1.1 interpreter.
Doing the same w/ GWBASIC ought to be pretty straightforward. It returned back to the OS via the "SYSTEM" statement. Back in the "day" before I had the QuickBASIC compiler I would invoke GWBASIC programs from batch files in a similar manner, pulling input from STDIN and outputting to STDOUT.
This is very cool. I've often wished I could return to my roots of simply programming, and not being a server admin and dba. Am I the only who wishes we could deploy things like BASIC applications to a runtime in the cloud and be done with all these layers of abstraction and incidental complexity?
I get the nostalgia, but even though I started with BASIC (Applesoft BASIC as an 8-year-old in 1988), I wouldn't want to go back there. Structured, object-oriented, event-driven, and functional programming are all truly useful. Trying to choose the modern programming language with the least incidental complexity is enough IMO.
Furthermore, the UI facilities that early microcomputer BASICs provided would not be acceptable today. The graphics of the Apple II or QBASIC might be cool for a retro game, but you wouldn't want to develop a real application that way. For one thing, such applications were inaccessible to blind users with the primitive screen readers that existed back then, and today's screen readers would do no better. And a text UI with PRINT and INPUT would be accessible but even more retro. So even if you wrote an app in BASIC and deployed it to a cloud platform, you'd somehow have to use a modern platform like the Web for your UI. Unless, of course, you want to develop a retro game, and that might indeed be a fun side project.
70 REM draw hamburger
80 HGR2:HCOLOR=5
100 for t = 1 to 50 step 0.01
140 x = Sin(Tan(t))
160 y = Cos(t)
180 xp = (x * 50) + 150
190 yp = (y * 50) + 100
200 HPLOT xp, yp TO xp, yp
300 next t
The suggestion to "use SYSTEM instead of END" is suspicious.
SYSTEM spawns the system shell as a sub-process. If one would EXIT from the spawned command.com/cmd.exe, QBASIC would pop up back. I think a user of programs written in this way would find themselves surprised.
This is not true, system quits basic. In gwbasic this was unconditional since there was no ide, in qbasic it works if you used /run to start the program right away, otherwise system is equivalent to end and just drops you back into the ide.
SYSTEM with a string argument on some Microsoft BASICs spawned a shell that ran the command in the argument. On others, the SHELL command did this. (iirc mbasic on xenix used SHELL, GWbasic used SYSTEM with an argument.)
Back then, they called it a subnotebook, and it was plenty useful offline. My Contura Aero (in 1994-95) had a 486 (SX I think, 25 or 33 MHz), 4 MB of RAM, and a ~170 MB hard drive. The 3.5" floppy drive was indeed connected via PCMCIA. Its primary purpose was taking notes in class and doing homework, but I also did some QBASIC and assembly programming on it.
On a related note (of using BASIC where it doesn't belong), I hacked together a method to convert BASIC code to WebAssembly using BaCon[0], a BASIC-to-C converter, and Emscripten to take the resulting C output and generate some wasm.[1] Much like the linked article, this is a fun diversion to entertain the idea of using BASIC where the language authors couldn't possibly have imagined it. Perhaps I'll get around to actually making a "real" project out of it sometime...
[0]: http://www.basic-converter.org/
[1]: https://github.com/matthewwiese/basic-to-c-wasm-example