Retro X86 With 486Tang

Tang FPGA boards are affordable, and [nand2mario] has been trying to get an x86 core running on one for a while. Looks like it finally worked out, as there is an early version of the ao486 design on a Tang FPGA board using a Gowin device. That core’s available on the MiSTer platform, which emulates games using an Altera Cyclone device.

Of course, porting something substantial between FPGA architectures is not trivial. In addition, [nand2mario] made some changes. The original core uses DDR3 memory, but for the Tang and the 486, SDRAM makes more sense. The only problem is that the Tang’s SDRAM is 16 bits wide, which would imply you need two cycles per 32-bit access. To mitigate this, the memory system runs at twice the main clock frequency. Of course, that’s kind of double data rate, but not in the same way as DDR memory.

Continue reading “Retro X86 With 486Tang”

Everything You Ever Wanted To Know About The Manhattan Project (But Were Afraid To Ask)

There have been plenty of books and movies about how the Manhattan Project brought together scientists and engineers to create the nuclear bomb. Most of them don’t have a lot of technical substance, though. You know — military finds genius, genius recruits other geniuses, bomb! But if you want to hear the story of the engineering, [Brian Potter] tells it all. We mean, like, all of it.

If you’re looking for a quick three-minute read, you’ll want to give this a pass. Save it for a rainy afternoon when you can settle in. Even then, he skips past a lot of what is well known. Instead, he spends quite a bit of time discussing how the project addressed the technical challenges, like separating out U235.

Four methods were considered for that task. Creating sufficient amounts of plutonium was also a problem. Producing a pound of plutonium took 4,000 pounds of uranium. When you had enough material, there was the added problem of getting it together fast enough to explode instead of just having a radioactive fizzle.

There are some fascinating tidbits in the write-up. For example, building what would become the Oak Ridge facility required conductors for electromagnets. Copper, however, was in short supply. It was wartime, after all. So the program borrowed another good conductor, silver, from the Treasury Department. Presumably, they eventually returned it, but [Brian] doesn’t say.

There’s the old story that they weren’t entirely sure they wouldn’t ignite the entire atmosphere but, of course, they didn’t.  Not that the nuclear program didn’t have its share of bad luck.

Debugging Vs Printing

We’ll admit it. We have access to great debugging tools and, yes, sometimes they are invaluable. But most of the time, we’ll just throw a few print statements in whatever program we’re running to better understand what’s going on inside of it. [Loop Invariant] wants to point out to us that there are things a proper debugger can do that you can’t do with print statements.

So what are these magical things? Well, some of them depend on the debugger, of course. But, in general, debuggers will catch exceptions when they occur. That can be a big help, especially if you have a lot of them and don’t want to write print statements on every one. Semi-related is the fact that when a debugger stops for an exception or even a breakpoint, you can walk the call stack to see the flow of code before you got there.

In fact, some debuggers can back step, although not all of them do that. Another advantage is that you can evaluate expressions on the fly. Even better, you should be able to alter program flow, jumping over some code, for example.

So we get it. There is more to debugging than just crude print statements. Then again, there are plenty of Python libraries to make debug printing nicer (including IceCream). Or write your own debugger. If gdb’s user interface puts you off, there are alternatives.

Everything In A Linux Terminal

Here at Hackaday Central, we fancy that we know a little something about Linux. But if you’d tasked us to run any GUI program inside a Linux terminal, we’d have said that wasn’t possible. But, it turns out, you should have asked [mmulet] who put together term.everything.

You might be thinking that of course, you can launch a GUI program from a terminal. Sure. That’s not what this is. Instead, it hijacks the Wayland protocol and renders the graphics as text. Or, if your terminal supports it, as an image. Performance is probably not your goal if you want to do this. As the old saying goes, “It’s not that the dog can sing well; it’s that the dog can sing at all.”

If, like us, you are more interested in how it works, there’s a write up explaining the nuances of the Wayland protocol. The article points out that Wayland doesn’t actually care what you do with the graphical output. In particular, “… you could print out the graphics and give them to a league of crochet grandmas to individually tie together every single pixel into the afghan of legend!” We expect to see this tested at an upcoming hacker conference. Maybe even Supercon.

We generally don’t like Wayland very much. We use a lot of hacks like xdotool and autokey that Wayland doesn’t like. We also think people didn’t understand X11’s network abilities until it was too late. If you think of it as only a video card driver, then you get what you deserve. But we have to admit, we are humbled by term.everything.

The Android Linux Commander

Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.

I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:

  • All messages to the ordinary Linux start with >
  • All messages to the Android device start with <
  • All messages end with a carriage return

Security

You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.

There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.

If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.

Continue reading “The Android Linux Commander”

Retrotechtacular: The Noisy Home Computer From 1967

[Rex Malik] didn’t need an alarm clock. That’s because he had one of two “home computer terminals” next to his bed and, as you can see in the video below, it made quite a racket. The terminal looks like an ASR33 with some modifications. In 1967, it was quite a novelty and, of course, it didn’t have any real processing power. It connected to an “invisible brain” ten miles away.

What do you do with a computer in 1967? Well, it looks like you could trade stocks. It also apparently managed his shopping list and calendar. His young son also learned some letters and numbers. We’d love to hear from the young [Mr. Malik] today to find out what kind of computer he’s using now.

Continue reading “Retrotechtacular: The Noisy Home Computer From 1967”

Reverse Engineering A (Toy) Fire Engine

Your kid has a toy remote control fire truck. You have an RTL SDR. See where this is going? [Jacob] couldn’t resist tearing into the why and how of the truck’s remote control protocol.

The entire process began with a basic GNU Radio setup to determine the exact frequency of the signal. Then a little analysis suggested that it might be using amplitude shift keying. That is, the information is in the amplitude of the signal, where one possible amplitude is completely off in some cases.

Continue reading “Reverse Engineering A (Toy) Fire Engine”