QB64 Hits Version 2.0, Gets Enhanced Debugging

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 new debug mode in QB64 v2.

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.

Yo Dawg, We Heard You Like Retrocomputers

The idea of having software translation programs around to do things like emulate a Super Nintendo on your $3000 gaming computer or, more practically, run x86 software on a new M1 Mac, seems pretty modern since it is so prevalent in the computer world today. The idea of using software like this is in fact much older and easily traces back into the 80s during the era of Commodore and Atari personal computers. Their hardware was actually not too dissimilar, and with a little bit of patience and know-how it’s possible to compile the Commodore 64 kernel on an Atari, with some limitations.

This project comes to us from [unbibium] and was inspired by a recent video he saw where the original Apple computer was emulated on Commodore 64. He took it in a different direction for this build though. The first step was to reformat the C64 code so it would compile on the Atari, which was largely accomplished with a Python script and some manual tweaking. From there he started working on making sure the ROMs would actually run. The memory setups of these two machines are remarkably similar which made this slightly easier, but he needed a few workarounds for a few speed bumps. Finally the cursor and HMIs were configured, and once a few other things were straightened out he has a working system running C64 software on an 8-bit Atari.

Unsurprisingly, there are a few things that aren’t working. There’s no IO besides the keyboard and mouse, and saving and loading programs is not yet possible. However, [unbibium] has made all of his code available on his GitHub page if anyone wants to expand on his work and may also improve upon this project in future builds. If you’re looking for a much easier point-of-entry for emulating Commodore software in the modern era, though, there is a project available to run a C64 from a Raspberry Pi.

Thanks to [Cprossu] for the tip!

Should You Build For Windows, Mac, IOS, Android, Or Linux? Yes!

The holy grail of computer languages is to write code once and have it deploy effortlessly everywhere. Java likes to take credit for the idea, but UCSD P-Code was way before that and you could argue that mainframes had I/O abstraction like Fortran unit numbers even earlier. More modern efforts include Qt, GTK, and other things. Naturally, all of these fall short in some way. Now Google enters the fray with Flutter.

Flutter isn’t new, but in the past, it only handled Android and iOS. Now it can target desktop platforms and can even produce JavaScript. We haven’t played with the system enough to say how successful it is, but you can try it in your browser if you want some first-hand experience.

Continue reading “Should You Build For Windows, Mac, IOS, Android, Or Linux? Yes!”

Write Once, Run Everywhere: Cross-Platform Programming Done Right

One of the goals of programming languages back in the 1950s was to create a way to write assembly language concepts in an abstract, high-level manner. This would allow the same code to be used across the wildly different system architectures of that era and subsequent decades, requiring only a translator unit (compiler) that would transform the source code into the machine instructions for the target architecture.

Other languages, like BASIC, would use a runtime that provided an even more abstract view of the underlying hardware, yet at the cost of a lot of performance. Although the era of 8-bit home computers is long behind us, the topic of cross-platform development is still highly relevant today, whether one talks about desktop, embedded or server development. Or all of them at the same time.

Let’s take a look at the cross-platform landscape today, shall we?

Continue reading “Write Once, Run Everywhere: Cross-Platform Programming Done Right”