Revisiting Borland Turbo C And C++

Looking back on what programming used to be like can be a fascinatingly entertaining thing, which is why [Tough Developer] decided to download and try using Turbo C and C++, from version 1.0 to the more recent releases. Borland Turbo C 1.0 is a doozy as it was released in 1987 — two years before the C89 standardization that brought us the much beloved ANSI C that so many of us spent the 90s with. Turbo C++ 1.0 is from 1991, which precedes the standardization of C++ in 1998. This means that both integrated development environments (IDEs) provide a fascinating look at what was on the cutting edge in the late 80s and early 90s.

Online help and syntax coloring in Turbo C++.

It wasn’t until version 3.0 that syntax highlighting was added, with the IDE’s focus being mostly on features such as auto-indentation and tool integration. Version 2.0 added breakpoints and further integration with the debugger and other tools, as well as libraries such as the Borland Graphics Interface (BGI). Although even editors like Notepad++ and Vim probably give these old IDEs a run for their money nowadays, they were totally worth the money asked.

Those of us that have been around long enough to have gotten their start in C++ by using the free Turbo command line tools in the 1990s, or lived through the rough, early days of GCC 2.x+ on Linux, will remember that a development environment that Just Worked© was hard to obtain without shelling out some cash. Within that environment Turbo C and C++ and later Visual Studio and others served a very grateful market indeed.

Beyond the IDE itself, these also came with language documentation, as in the absence of constant internet access, referencing APIs and syntax was done using dead-tree reference books or online documentation. Here “online” meaning digital documentation that came provided on a CD and which could be referenced from within the IDE.

[Tough Developer] walks the reader through many features of the IDE, which includes running various demos to show off what the environment was capable of and how that in turn influenced contemporary software and games such as Commander Keen in Keen Dreams. While we can’t say that a return to Turbo C is terribly likely for the average Hackaday reader, we do appreciate taking a look back at older languages and development environments — if for no other reason than to appreciate how far things have come since then.

Minecraft Finally Gets Multi-Threaded Servers

Minecraft servers are famously single-threaded and those who host servers for large player bases often pay handsomely for a server that has gobs of memory and ripping fast single-core performance. Previous attempts to break Minecraft into separate threads haven’t ended successfully, but it seems like the folks over at [PaperMC] have finally cracked it with Folia.

Minecraft is one of (if not the most) hacked and modded games in history. Mods have been around since the early days, made possible by a dedicated group who painstakingly decompiled the Java bytecode and reverse-engineered it. Bukkit was a server mod back in the Alpha days that tried to support plugins and extend the default Minecraft. From Bukkit, Spitgot was forked. From Spitgot, Paper was forked, which focused on performance and gameplay mechanics. And now from Paper, Folia is a new fork focused on multi-threading.

A Minecraft world is split up into worlds (such as the nether or the overworld) and chunks. Chunks are 16x16xZ vertical columns of blocks. Folia breaks up sections of chunks into regions that can be ticked independently. Of course, moving to a multi-threaded model will cause existing plugins to fail. Very little was made thread-safe and the idea is that data cannot move easily across ticking regions. Regions tick in parallel, not synchronously.

Naturally, the people benefiting from Folia the most are those running servers that support hundreds of players. On a server with a vanilla-like configuration only around a hundred or so players can be online. Increasing single-core performance isn’t usually an option past this point. By moving to other cores, suddenly you can scale out significantly without restoring to complex proxying. Previous attempts have had multiple Minecraft servers and then synced players and entities between them. Of course, this can cause its own share of issues.

It’s simply incredible to us what the modding community continues to develop and create. It takes deep patience to reverse-engineer the system and rearchitect it from the outside. The Folia codebase is available on GitHub under a GNU GPL 3.0 license if you’d like to look through it.

How Much Programming Can ChatGPT Really Do?

By now we’ve all seen articles where the entire copy has been written by ChatGPT. It’s essentially a trope of its own at this point, so we will start out by assuring you that this article is being written by a human. AI tools do seem poised to be extremely disruptive to certain industries, though, but this doesn’t necessarily have to be a bad thing as long as they continue to be viewed as tools, rather than direct replacements. ChatGPT can be used to assist in plenty of tasks, and can help augment processes like programming (rather than becoming the programmer itself), and this article shows a few examples of what it might be used for.

AI comments are better than nothing…probably.

While it can write some programs on its own, in some cases quite capably, for specialized or complex tasks it might not be quite up to the challenge yet. It will often appear extremely confident in its solutions even if it’s providing poor or false information, though, but that doesn’t mean it can’t or shouldn’t be used at all.

The article goes over a few of the ways it can function more as an assistant than a programmer, including generating filler content for something like an SQL database, converting data from one format to another, converting programs from one language to another, and even help with a program’s debugging process.

Some other things that ChatGPT can be used for that we’ve been able to come up with include asking for recommendations for libraries we didn’t know existed, as well as asking for music recommendations to play in the background while working. Tools like these are extremely impressive, and while they likely aren’t taking over anyone’s job right now, that might not always be the case.

Picture of the miniJen structure on a presentation desk

A Jenkins Demo Stand For Modern Times

Once you’re working on large-scale software projects, automation is a lifesaver, and Jenkins is a strong player in open-source automation – be it software builds, automated testing or deploying onto your servers. Naturally, it’s historically been developed with x86 infrastructure in mind, and let’s be fair, x86 is getting old. [poddingue], a hacker and a Jenkins contributor, demonstrates that Jenkins keeps up with the times, with a hardware demo stand called miniJen, that has Jenkins run on three non-x86 architectures – arm8v (aarch64), armv7l and RISC-V.

There’s four SBCs of different architectures involved in this, three acting as Jenkins agents executing tasks, and one acting as a controller, all powered with a big desktop PSU from Pine64. The controller’s got a bit beefier CPU for a reason – at FOSDEM, we’ve seen it drive a separate display with a Jenkins dashboard. It’s very much a complete demo for its purpose, and definitely an eyecatcher for FOSDEM attendees passing by the desk! As a bonus, there’s also a fascinating blog post about how [poddingue] got to running Jenkins on RISC-V in particular.

Even software demonstrations get better with hardware, and this stood out no doubt! Looking to build a similar demo, or wondering how it came together? [poddingue] has blog posts on the demo’s structure, a repo with OpenSCAD files, and a trove of videos demonstrating the planning, design and setup process. As it goes with continuous integrations, we’ve generally seen hackers and Jenkins collide when it comes to build failure alerts, from rotating warning lights to stack lights to a Christmas tree; however, we’ve also seen a hacker use it to keep their firmware size under control between code changes. And, if you’re wondering what continuous integration holds for you, here’s our hacker-oriented deep dive.

The X Macro: A Historic Preprocessor Hack

If we told you that a C preprocessor hack dated back to 1968, you’d be within your rights to remind us that C didn’t exist in 1968. However, assemblers with preprocessors did, and where there is a preprocessor, there is an opportunity to do clever things. One of those things is the so-called X macro, which saw a lot of use in DEC System 10 code but probably dates back even earlier. You can still use it today if you like, even though there are, of course, other arguably better ways to get the same result. However, the X macro can be very efficient, and you may well run into it in some code, too.

Background

Preprocessing used to be a staple of programming. The idea is that code is manipulated purely at the text level before it is compiled. These days, languages with a preprocessor usually handle it as part of the compiler, but you can also use an external preprocessor like m4 for more sophisticated uses.

Modern languages tend to provide other ways to accomplish many of the tasks handled by the preprocessor. For example, if you have a constant you want to set at compile time, you could say:

int X = 32;
y = X;

But then you’ve created a real variable along with the overhead that might entail. A smart compiler might optimize it away for you, but you can be sure by writing:

#define X 32
y = X;

A modern compiler would prefer you to write:

const int X=32;
y = X;

But there are still some common uses for macros, like including header files. You can also make more sophisticated macros with arguments so you don’t incur a function call penalty, although modern usage would be to mark those functions as inline.

The Problem

Which brings us to the X macro. With all great hacks, there is first a problem to solve. Imagine you have a bunch of electronic parts you want to deal with in your code. You don’t want a database, and you don’t want to carry a bunch of strings around, so you define an enumerated type:

Continue reading “The X Macro: A Historic Preprocessor Hack”

Efficient X86_64 Emulation With Box86

Running applications on a different architecture than the one for which they were compiled is a common occurrence, not in the least with Apple’s architectural migration every decade or so. It’s also commonly used with for example ARM, OpenRISC, and RISC-V systems to run applications that are only available for x86 or x86_64. While QEMU and kin are often used here, they’re pretty resource heavy, which is where an option like Box86 and its 64-bit sibling Box64 are attractive options. Unlike QEMU, both offer dynamic recompilation and redirection of dynamic library calls to native libraries, including those for SDL and OpenGL.

Both are available on GitHub under an MIT license, with Box64 probably the most interesting these days as applications and games have moved on to a 64-bit only world. The only hard requirement that Box64 has for a host system is that it is little-endian, which is a pretty easy requirement to meet. The most recent release was on March 10th, with Box86 0.3 and Box64 0.2.2. As essentially a translation layer, it does not offer full compatibility with every bit of software out there, but it’s already good enough to run Steam, GoG, and Epic Game Store clients and install and run Windows games via Wine for x86.

A simple set of benchmarks comparing it with QEMU and FEX (another emulator) shows it to run both more applications, and with significantly better performance.

Videos Teach Bare Metal RP2040

When we write about retrocomputers, we realize that back in the day, people knew all the details of their computer. You had to, really, if you wanted to get anything done. These days, we more often pick peripherals and just assume our C or other high level code will fit and run on the CPU.

But sometimes you need to get down to the bare metal and if your desire is to use bare metal on the RP2040, [Will Thomas] has a YouTube channel to help you. The first video explains why you might want to do this followed by some simple examples. Then you’ll find over a dozen other videos that give you details.

Any video that starts, “Alright, Monday night. I have no friends. It is officially bare metal hours,” deserves your viewing. Of course, you have to start with the traditional blinking LED. But subsequent videos talk about the second core, GPIO, clocks, SRAM, spinlocks, the UART, and plenty more.

As you might expect, the code is all in assembly. But even if you want to program using C without the SDK, the examples will be invaluable. We like assembly — it is like working an intricate puzzle and getting anything to work is satisfying. We get it. But commercially, it rarely makes sense to use assembly anymore. On the other hand, when you need it, you really need it. Besides, we all do things for fun that don’t make sense commercially.

We like assembly, especially on platforms where most people don’t use it. Tackling it on a modern CPU is daunting, but if you want to have a go, we know someone who can help.

Continue reading “Videos Teach Bare Metal RP2040”