At Last! CP/M For Protected Mode

August 4, 2026 by Al Williams 28 Comments

If you used a serious computer pre-IBM PC, there was a fair chance its operating system was CP/M. CP/M was a staple among 8080 and Z80 computers and while there were other versions, we’ll always associate CP/M with the Z-80. There was a CP/M made for the PC which used an 8088 (a hybrid 8-bit bus with a 16-bit 8086 core), but it was overwhelmed by MSDOS. However, there was another interesting version made for the 68000, and now [johnsonjh] has ported that over to create an early version of CP/M for 80386 protected mode.

The Z-80 only had a 16-bit address bus, so it could only handle 64K of memory. It was common to “bank switch” some memory, and CP/M Plus could be made to understand that (for example, you might have 32K of common memory and three banks of 32K memory; you could address one bank at a time). However, the 386 had a full-blown memory management unit that could remap physical 4K memory pages to anywhere in a program’s virtual address space.

Ordinary CP/M couldn’t handle that, but the Motorola 68000 had a similar page management model, so it makes sense it might be easier to port CP/M-68K to the 80386 than starting from the original, even though the instruction set for the Z-80 is conceptually more similar to the 80386.

What can you do with it? We don’t know. Presumably, it will allow you to use lots of memory. Historically, CP/M software from one variant would not run on another, so you’ll have to build anything you want to use. Of course, the real killer for lots of CP/M memory was multitasking, but that takes MP/M, and only about half of that is currently working. But we won’t be surprised to see it completed soon.

While CP/M skills won’t land you many jobs these days, it is a pretty good way to get mentioned on Hackaday.

The 16K Display That Ate Las Vegas

August 3, 2026 by Al Williams 29 Comments

You may have a 4K television. Perhaps you have even bought an 8K screen, despite the shortage of things worth watching in 8K. A 16K display is, today, a rarity. But even when those eventually become commonplace, yours probably will not cover 14,900 square meters, rise 73 meters into the air, or wrap over your head and behind your peripheral vision.

That is approximately what happens inside Sphere in Las Vegas. The venue’s interior display is quoted as having a resolution of 16K by 16K and an area of 160,000 square feet, or about 3.7 acres. Unlike most enormous movie screens, it is not illuminated by a projector. The entire surface is a direct-view LED display: an immense, curved video wall assembled from tens of thousands of smaller pieces.

After seeing The Wizard of Oz at Sphere, however, the most interesting part was not simply the screen’s size. It was how thoroughly the screen could disguise itself.

Where Did The Theater Go?

Radio City or the Sphere? (It is the Sphere; photo courtesy [DP])

Before the presentation began, the auditorium appeared to have a conventional architectural ceiling. Great orange ribs curved over the seating, while ventilation grilles, suspended loudspeakers, lighting fixtures, curtains, and video monitors completed the illusion. It looked like the Radio City Music Hall’s proscenium. Then the show started — and the apparent theater completely disappeared. The speakers, the TVs, even the stage.

The obvious first conclusion was that the LED surface must be optically transparent, allowing the audience to see the real roof behind it until the pixels illuminated. That explanation was attractive because Sphere’s audio system really is installed behind the display, and the surface must allow sound through it.

It was also, apparently, wrong. The only explanation that makes sense is that the ceiling, ribs, grilles, speakers, and monitors were already being displayed by the screen. It was like a holodeck impersonating a physical theater interior. When the Oz material began, the system simply replaced one complete visual environment with another.

That’s what happens when a display fills nearly all of your useful visual field. A normal screen announces itself with a bezel, a wall, or at least a clearly visible edge. Sphere’s display extends upward and around the audience, removing many of those references. Give the image credible perspective, texture, shadows, and familiar architectural details, and the brain accepts the pixels as a room.

The same effect makes the Oz landscapes seem less like scenes displayed in front of the audience and more like places into which the auditorium has been inserted. Of course, there are more special effects. For The Wizard of Oz, there is wind and smoke, along with paper leaves, flower petals, and foam-rubber apples that fall from the sky. All of this makes it even more immersive.

Continue reading “The 16K Display That Ate Las Vegas” →

Hackaday Podcast Episode 380: 3D Printing The Rainbow, IR And IP Camera Hacks, And Americium 241 On The Loose

July 31, 2026 by Al Williams No comments

Elliot Williams and Al Williams got together to compare notes on the most interesting posts this week on the site. As usual, there are just too many choices, so you’ll have to settle for just the few that can fit in a podcast. The guys were excited about 3D printing — both FDM and SLA — as well as a few camera projects. Ever wanted your own starship? They do, too, and you’ll hear about it along with portable radar and more.

Want to make flexible PCBs? Fill up a carbon dioxide tank? Or play Doom via regular expressions? Tune in, and you’ll find out about those stories and more.

Follow along with the links, and as always, tell us what you think about this episode in the comments! Better still, drop us a note in the mailbag, and you might hear your question on a future episode. You can record audio or send us a message, and one of the hosts will read it on your behalf.

Direct download in IR color-corrected DRM-free MP3.

Continue reading “Hackaday Podcast Episode 380: 3D Printing The Rainbow, IR And IP Camera Hacks, And Americium 241 On The Loose” →

BASICally, Its Retro Machine Language

July 23, 2026 by Al Williams 29 Comments

We enjoyed [Beej’s] trip down memory lane looking at a BASIC game, The Wizard’s Castle, written for the Exidy Sorcerer. It appeared in a 1980 magazine that included the title graphic above. It reminded us how, back in those days, we did things with BASIC that you shouldn’t be able to do and it often looks, today, rather cryptic.

In particular, even if you know modern BASIC, these few lines might give you a pause:

10 REM"_(C2SLFF4
40 POKE 260,218: POKE 261,1: T = USR(0): T = PEEK(-2049)
80 Q = RND(-(2*T+1))

Line 10 is a comment, but a strange one. Certainly that doesn’t matter, right? Actually, it is a key part of the action. On line 40, you can see some pokes to write directly to memory and a peek to read some memory value back. The USR function calls some machine language program. You may realize the whole thing is to get some value T to seed the random number generator in line 80.

This leads to a few obvious questions. First, how does USR know what to call? Second, where is the machine language program? The details varied by system, of course, but in this case, the program knows that location 259 has a jump instruction that USR called. So poking an address into 260 and 261 was telling USR where it should go.

But what’s at that address? Keep in mind that an old computer like the Sorcerer didn’t have megabytes of memory being swapped about by an operating system. That means that things tended to be in known places and that BASIC had to be judicious about storing source code.

Continue reading “BASICally, Its Retro Machine Language” →

Encryption In The 1790s

July 23, 2026 by Al Williams 12 Comments

For as long as humans have had writing, there’s been a need to send secret messages. It is easy to think that Enigma machines and their immediate predecessors are old tech, but they are much more recent than ancient systems used by the Greeks and Romans. Even Thomas Jefferson, one of the founding fathers of the United States, was interested in encryption and is often said to have invented the Jefferson Disk machine for encryption. The truth is, the device is probably older than Jefferson, but he certainly thought about using it for secret communications.

Simple but Effective

Thomas Jefferson was, apparently, a fan of secret messages

The idea is simple. We make a series of disks. Each disk has a number on it and, around the edge, all the letters of the alphabet. The placement of each wheel with the same number is the same, but, overall, the arrangement is random. That is, all disks marked #5 might start with XCBYG, but all disks marked with #10 could start with FAYQL. You take one set of disks, and I keep the other set.

When we want to send secret messages, we agree to arrange our disks on an axle in the same order. Jefferson used a 36-disk system, so we might agree to go left to right with the odd numbers first and then the even numbers, or any other setup that we could agree on.

Encryption

Once the wheels are in place, encryption is simple. There’s a bar across the device, and you line up your message using a wheel for each letter: ENEMYCOMESBYSEA, for example. Then you look at any different row, which will now read something crazy like: FSRSSXQCGAEEFOR (plus the random letters on the rest of the disks). That’s the message you send.

Continue reading “Encryption In The 1790s” →

The Need For Speed: Internet Speed Measurement (or DIY?)

July 22, 2026 by Al Williams 14 Comments

Car enthusiasts want to know how quickly they can make a quarter mile. Weightlifters are forever trying to add one more plate to the bar. Internet denizens have their own favorite number to brag about: the result from a speed test.

The ritual is familiar. Close a few browser tabs, click the big “Go” button, and watch the needle climb. Perhaps you pay for gigabit service and see 940 megabits per second, which produces a satisfied nod. Perhaps you see 299 megabits and begin obsessing over network hardware. But before you get too excited either way, try another test. There is a fair chance it will give you a different answer.

That does not necessarily mean one test is lying. “Internet speed” is not a single physical quantity waiting to be measured. A speed test measures the performance of a particular device, over a particular local connection, through a particular ISP route, to a particular server, at a particular time using a particular test method. Change any of those things and the answer can change too. Continue reading “The Need For Speed: Internet Speed Measurement (or DIY?)” →

Compile Here, Run Everywhere: Crosstool-Ng

July 22, 2026 by Al Williams 10 Comments

In a recent post, I mentioned that I wanted to build some tools for a stripped-down Linux running on a 3D printer with a MIPS CPU. I had two options: build a toolchain to cross-compile, or use Zig, which, in theory, has built-in toolchains for MIPS. I had to jump through hoops to get Zig to work, and I did mention Crosstool-Ng, so you might wonder why I didn’t start there. Turns out, it had its own set of hoops to work through.

Continue reading “Compile Here, Run Everywhere: Crosstool-Ng” →