Despite the name, BASIC isn’t exactly a language recommended for beginners these days. Technology has moved on, and now most people would steer you towards Python if you wanted to get your feet wet with software development. But for those who got their first taste of programming by copying lines of BASIC out of a computer magazine, the language still holds a certain nostalgic appeal.
If that sounds like you, then may we heartily recommend QB64. The open source project seeks to modernize the classic programming language while retaining compatibility for QBasic 4.5, the late-80s BASIC environment Microsoft included with MS-DOS. That modernization not only includes the addition of contemporary technology like OpenGL, but cross-platform support that lets you run the same code on Windows, Linux, and Mac OS.
The QB64 team released version 2.0 just a few days ago, making this the perfect time to give the project a test drive if you haven’t tried it out yet. The changelog includes platform specific improvements for each supported operating system, as well as a long list of general fixes and updates. But arguably the biggest feature for this release is the inclusion of the $Debug metacommand.
When this command is included in your code, the IDE will insert a debugging stub into the compiled program. During execution, the QB64 IDE will switch over to debugging mode, and communicate with your program in real-time over a local TCP/IP connection. The debugging mode lets you step through the code line-by-line, check the values of variables, and set breakpoints. Once you’re done fussing with the code and want to release a final binary, you just need to remove that single $Debug command and recompile.
We’ve talked in the past about using QB64 to revitalize vintage code, and think the project is a fantastic melding of old and new technology. You never know when you might suddenly have the urge to dust off some code you wrote back in the 80s and run it on an OS that didn’t even exist at the time.
QB64 is awesome – I have used it for several projects, including logging fire alarm panel data, ID scans at gates, etc. Compiled .exe is self-contained and runs quick and smooth.
Agreed. It’s amazing.
Wonder how it fairs against TurboRascal which does C64 and much more.
nice text gui. I need similar in my C project on linux
Look into ncurses – that may well be what you want.
no ncurses is not similar i use ncurses and hate it
Java is much more powerful than BASIC. I mean this runs on small pc’s, and is optmized for DOS and Linux. If “hello world” compiles in less than 1 minute, and needs less than 4GB of RAM, 4cores, and 10Gb of ‘helper libraries’ than your programming language is a trivial POS.
Java just needs as few as 4 cores, as little as 4GB of memory, and can get by with as little as 5Gb of disk space for a basic installation.
Hello world can compile and run in just minutes, and gets faster every time.
Haha, I’d take it over BASIC, but while Java is pretty hideous (unless you have an absolute fetish for boilerplate) the JVM is good. You can compile a decent language to the JVM and usually get out of the pain of writing Java.
Sure if all you do is run code on a Wintel platform with gigs of memory and a monster HDD. What made BASIC popular in its time was that you could bring it up on anything from a Zilog Z-8 to a 6502 or 68k with minimal hardware reqs.(just life Forth).
I would say that the Arduino IDE with it’s abstracted C as a programming language has become the new defacto BASIC of the 21st century. Yeah it’s ugly like BASIC and pros hate it. But it’s popular among hobbyists and newbies for a reason – it’s accessible to mere mortals(just like BASIC was).
FWIW, latest Arduino IDE download is 300+ MB in zip format and unpacks to 600.
There’s lots to like about QB64:
– Cross-plarform, Windows, Linux, macOS.
– Stand-alone/portable application, doesn’t mess up your environment.
– Has a GUI IDE.
– Has some Debug capability.
– Has a GUI dev-tool called Inform.
– Not an interpreter, generates stand-alone executables from C++ source.
– QB64 is fast (in the FAQ they talk about slowing it down if need-be).
But the big problem for me with QB64 is there’s no working hardware I/O. At the very least if QB64 had working serial port access (like most other BASIC programs), almost anything is possible with a USB/UART cable and a microcontoller acting as a GPIO, I2C, SPI, etc. bridge. But alas the OPEN “COM…” function appears to be really-really broken:
Re: Bizarre behavior from OPEN COM:
https://www.qb64.org/forum/index.php?topic=3459.msg127741#msg127741
Here’s the bug filed and acknowledged way back on 07-Jan-2021, zero progress to-date:
https://github.com/QB64Team/qb64/issues/99
Then there’s this little nasty bit from the QB64 FAQ:
https://www.qb64.org/wiki/QB64_FAQ#Q:_Are_there_any_known_incompatibilities.3F
Q: Are there any known incompatibilities?
A: There are some things that QB64 cannot do, like direct hardware access, which makes older more advanced programs that make use of ABSOLUTE, INTERRUPT, PEEK, POKE and OUT not work properly. Although some older functionality is emulated, if your program doesn’t use such statements you probably won’t notice any difference between QB 4.5 and QB64 (and if you do, report it as a bug in the forums). You can expect the most common addresses for interrupts, etc. to be functioning.
Here’s a forum thread asking about SPI and I2C; you have to see the comical response for yourself:
QB64 Discussion / Re: Help on Code to emulate SPI or I2C thru USB COM ports
https://www.qb64.org/forum/index.php?topic=1834.msg110746#msg110746
Well since it can’t access hardware it’s not worth much to me. That was half the fun of using QB you could access the printer port and homebrew ISA cards with no problem.
+
That’s what I loved to do with QB 4.5, Power Basic, VBDOS and PDS 7.x..
They were fine tools to bit-bang the hardware on gameport, serial port and parallel port.
And homebrew devices installed on prototype ISA cards.
The STICK () and STRIG () commands were very fun to use, also.
They could be used to read analog and digital values drom gameport, if memory serves.
Gladly, QB64 seems to have those, too.
Is it possible that direct hardware access is being limited by Windows? Newer versions of Windows tend to have the hardware pretty much locked away from the software, if I understand it correctly (I’m neither a programmer or a systems engineer, just a hobbyist and a lousy one at that). Not sure how all that works, but it seems like that sort of thing could cause problems in situations like this.
Ever since Win 2000, there has been a thing call HAL (Hardware Access Level). Direct access to processor I/O must be limited so a little thing like an app does not crash the whole system. If it’s really required to get to the I/O level. There is a driver called PORTIO. Which you can call via the HAL, because it sits below HAL closer to the hardware. The days of directly driving Ports and I/O are long gone. Just like floppies, serial modems and glass CRT’s.
Quick Basic was my second programming language that I used, my first one in creating a useful application. (first one was the Atari Basic haha). With Quick Basic I did some nice software, one of them was a simple database (which stored only text and numbers, no fancy stuff). If I remember correctly, the software was a barcode database with product information. It was fun… Until I discovered c#.
I had similar experiences with QB45. I used it to write software to help my Dad with his computer, made a few small games, and even wrote a few programs to help with my BBS (that dates it) including a terrible but effective ASCII editor.
With the power of today’s computers VS what there was in 1999, how about picking up where NESEM left off? NES emulator written in QuickBasic 7.1 https://www.zophar.net/nes/nesem.html
Nothing wrong with BASIC, it was the second language I learned, assembly being the first. What made it popular back in the day was that you could bring up a version on almost any 8 bit or 16bit micro with just a few KBytes of ram. Something you can’t do with modern languages due to their massive bloat.
Heck when I worked for Boeing we used a HP variant of BASIC that interfaced GPIB test equipment to troubleshoot the avionics and electrical system of the B-1B. The nice thing about it was easily learned by techs.. Something you can’t say about so called modern languages like Python.
Call me crazy, but it would be very neat if QB64 also targetted the .NET platform.
VB.net could use some competition.
This IDE brings back memories of Turbo Pascal. Those were the times.
Maybe I’m an oddball, newbie, or just not manly enough to embrace C++, but I always believed BASIC was the closest programming language to English. If I was an author writing a book, and someone suggested I wasn’t a ‘Real’ author uless if I wrote my book in Italian or Japanese, I’d happily ignore them. I think BASIC would be much more popular if it was called ‘Jet’, or “Hard Test”. Years ago, I developed a Fire Alarm annunciator using QB4.5, and then ported it to PowerBasic. It was lightning fast and rock solid stable. 20+ years ago I built a POCSAG decoder in the obscure but incredible BASCOM for an Atmel microcontroller, and it also worked very well, with development and debugging an absolute joy. Line numbers are a thing of the past. Modern BASIC compilers have few of the encumberances that gave BASIC a bad name.
Funny you should pick “Jet”. That is what it was called under the Pick Operating System. Jetbasic. Like QB64 it was compiled.
Let me also suggest FreeBasic. It runs on DOS, Linux, Windows and Xbox platforms. I use it on both older 32-bit and 64-bit platforms, no problem. Excellent backwards QB compatibility option. Excellent Communications (USB/Serial,etc) and a support community that will help with virtually any problem – promptly!
Excellent I/O? That’s exactly what’s missing in QB64… Thanks.
It was the I/O capability (USB/serial/etc) that I needed for my Arduino and PIC projects. Using FB now for 1Mb/sec USB with the Arduino UNO R3.
In a series of primitive benchmark tests (multiple loops) against C++,Labview and Python, the FB ran as fast as the C++. Labview and Python were slower.
Firstly, I am a scientist. I program for specific purposes, and because it is fun, but I am not a professional programmer. Although I did use QuickBasic 4.5, GW BASIC/BASICA, and LabView for serial and A/D converter data collection and instrument control in the (distant) past, I can’t comment on the serial port I/O capabilities of QB64 or FB because I have not had a need to use them this way.
I can, however, comment (if somewhat subjectively) on aspects of usability and community engagement. I got back into BASIC programming in the last couple of years and tried both FreeBasic and QB64 in the process. I think that it is great that both of these exist. Both are very good and I would suggest checking out both.
I could be wrong, but my impression is that the QB64 community is more active than the FB community and that there is presently more ongoing development of QB64.
With respect to usability: QB64 is easier to get up and running. Once you download and extract it, everything is just right there and ready to go. It is very intuitive. There is more to fiddle with and figure out to get FreeBasic going, but it works well once you get over the first hurdle. I have ended up using QB64 a lot more than FreeBasic. It is quite powerful and the extended functionality is quite powerful. For example, I have found the interaction with the Windows clipboard most useful. QB64 is my go-to and it has not disappointed.
For good I/O try RobotBASIC.org http://www.robotbasic.org/