There is a gotcha lurking in wait for hackers who look at a piece of equipment, see a port labeled “Serial / RS-232”, and start to get ideas. The issue is the fact that the older the equipment, the more likely it is to be a bit old-fashioned about how it expects to speak RS-232. Vintage electronics may expect the serial data to be at bipolar voltage levels that are higher than what the typical microcontroller is used to slinging, and that was the situation [g3gg0] faced with some vintage benchtop equipment. Rather than deal with cables and wired adapters, [g3gg0] decided to design a wireless adapter with WiFi and Bluetooth on one end, and true RS-232 on the other.
The adapter features an ESP32 and is attached to a DB-9 plug, so it’s nice and small. It uses the ST3232 chip to communicate at 3 V logic levels on the microcontroller side, supports bipolar logic up to +/-13 V on the vintage hardware side, and a rudimentary web interface allows setting hardware parameters like baud rate. The nice thing about the ST3232 transceiver is that it is not only small, but can work from a 3 V supply with only four 0.1 uF capacitors needed for the internal charge pumps.
As for actually using the adapter, [g3gg0] says that the adapter’s serial port is exposed over TCP on port 23 (Telnet) which is supported by some programs and hardware. Alternately, one can connect an ESP32 to one’s computer over USB, and run firmware that bridges any serial data directly to the adapter on the other end.
Design files including schematic, bill of materials, and PCB design are shared online, and you can see a brief tour of the adapter in the video, embedded below.
Serial ports used to be everywhere. In a way, they still are since many things that appear to plug in as a USB device actually look like a serial port. The problem is that today, the world runs on the network. Sure, you can buy a terminal server that converts a serial port to an Ethernet port, but what fun is that? In this article, I’m going to show you how to stream serial ports over the network using some available Linux tools. It isn’t perfect, and it won’t work for every case, but when it works it works well.
Everything is a File, Until it Isn’t
At some point in the past, Unix — the progenitor of Linux — treated virtually everything as a file, and all files were created more or less equal. Programs didn’t care if a file was local, on the network, from a tape drive, or arriving over a named pipe.
But things started to change. Even though a serial port is just a file under Linux, it has some special attributes that let you set, for example, baud rates. Worse, some programs “know” too much about files and insist on certain naming conventions. So, in theory, you should be able to create a network socket, connect one end to a serial port and the other end to a program, and be done with it. In theory.
When [kiwih] picked up an Agilent 54621A scope, he was amused that it had a floppy disk. At one time, it was high-tech to use a disk to transfer scope data to your computer. Today, not so much. However, on the back was a serial port. Surely it was possible to read data from there. It is, and what results is a nice walkthrough of finding the port’s info and interfacing with it using Python.
Normally, you’d use the included BenchLinkXL software to grab data from the port, but that software is so old it would not run under Windows 10 or Wine. Searching didn’t turn up much on the serial port, but it did locate a manual for a similar Agilent scope. That manual wasn’t too helpful since it assumed you were connecting via a LAN or USB. However, it did make reference to an older model that was also similar and that was the key to finding a manual that did explain the serial port protocol.
The command set looks suspiciously like SCPI — Standard Commands for Programmable Instruments — which is a layer on top of the GPIB protocol. Many scopes speak that language, so that’s not surprising. That also means if you are in the mood to communicate with an SCPI scope, you might find the code useful, even if you don’t use a serial port or have this exact Agilent model.
Ask a hacker to imagine computing in the 1980s, and they might think of the classic 8-bit all-in-one machines from the likes of Commodore and Atari, or perhaps the early PCs and Macs. No matter the flavor, they’ll likely have one thing in common: a lack of mobility thanks to being anchored down by a bulky CRT screen in the form of either a television or a dedicated monitor. Mobile computing at the time was something of an expensive rarity, consisting of various quirky handhelds that today have been all but forgotten.
Looking to see if one of these so-called “pocket computers” could still be of use in 2019, [James Fossey] set out to get his circa 1986 Psion Organiser II connected to the Internet. With a Hitachi CPU, two-line text-only LCD and ABCD keyboard it’s a world away from the modern smartphone, yet as an early stab at a PDA as well as general purpose computer it’s visibly an ancestor of the devices we carry today. Of course, as the Psion was produced before the advent of affordable mobile data and before even the invention of the Web, it needed a bit of help connecting to a modern network.
Psion sold an RS-232 cable accessory which came with both serial terminal and file transfer in ROM, so with one of these sourced and a little bit of hackery involving an RS-232 to TTL converter and a DB-25 connector, he was able to hook it up to a Raspberry Pi. That means it’s reduced to being a dumb terminal for a more powerful machine that can do the heavy lifting, but those with long memories will tell you that’s exactly what would have been done with the help of a modem to connect to a BBS back in 1986. So far he’s got a terminal on the Pi and a Twitter client, but he’s declined to show us the Hackaday Retro Edition.
Psion has rarely featured directly on these pages, but despite being forgotten by many today they were a groundbreaking company whose influence on portable computing stretched beyond their own line of devices. One we have shown you is an effort to put more recent hardware into a Psion Series 5 clamshell.
Interviewing to be a full-stack engineer is hard. It’s a lot harder than applying for a junior dev job where you’re asked to traverse a red-black tree on a whiteboard. For the full-stack job, they just give you a pile of 2N2222 transistors. (The first company wasn’t a great fit, and I eventually found a place that gave me some 2N2907s for the interview.) That said, there’s a certain challenge in seeing how far you can push some doped silicon. Case in point, [Alastair Hewitt]. He’s building a computer to browse the world wide web from the gate level up.
The goal of this project is to browse the web using only TTL logic. This presents problems that aren’t readily apparent at first glance. First up is being able to display text on a screen. The easiest way to do this now is to get a whole bunch of modern memories that are astonishingly fast for a 1970s vintage computer. This allows for VGA output, and yes, we’ve seen plenty of builds that output VGA using some big honkin’ memories. It turns out these RAM and ROM chips are a little better than the specs say they are, and this computer is overclocked from the very beginning.
A bigger problem is how to interface with a network. This is a problem for very old computers, but PPP still exists and if you have the software stack you can read something from a server over a serial connection. [Alistar] actually found the UART frequency was more important than the dot clock frequency of VGA, and the system clock must therefore be built around the serial port, not the display interface. This means the text mode interface is actually 96 columns instead of the usual 80 columns.
It’s very easy to say that you’re building a computer on a bread board. It’s another thing entirely to actually do it. This is actually a surprisingly well-though out sketch of a computer system that will, theoretically, be able to connect to the Internet. Of course, the reality of the situation is that this computer will be connecting over serial to a computer that’s connected to the Internet, but there’s no shame in that. You can check out the progress on the GitHub for this project.
[John Whittington] failed to win a bid for an old VT-220 serial terminal on eBay, so he decided to make his own version and improve it along the way. The result is the Whitterm-220 (or WT-220) which has at its core a Raspberry Pi and is therefore capable of more than just acting as a ‘dumb’ serial terminal.
The enclosure is made from stacked panels of laser-cut plywood with an acrylic plate on the back for labels and connectors, where [John] worked paint into the label engravings before peeling off the acrylic’s protective film. By applying paint after laser-engraving but before peeling off the film, it acts as a fill and really makes the text pop.
Near the front, one layer of clear acrylic among the plywood layers acts as a light guide and serves as a power indicator, also doing double duty as TX/RX activity lights. When power is on, that layer glows, serving as an attractive indicator that doesn’t interfere with looking at the screen. When data is sent or received, a simple buffer circuit tied to the serial lines lights up LEDs to show TX or RX activity, with the ability to enable or disable this functionality by toggling a GPIO pin. A video overview is embedded below, where you can see the unit in action.
Modern operating systems insulate us — as programmers, especially — from so much work. Depending on how far back you go, programmers had to manage their own fonts, their own allocation space on mass storage, or even their own memory allotments. Every year, though, it seems like things get easier and easier. So why is it so annoying to open a simple serial port? It isn’t hard, of course, but on every operating system it seems to be painful — probably in an attempt to be flexible. And it is even worse if you want portability. I needed to write some C code that read data from an FPGA’s embedded logic analyzer, and I was annoyed at having to write yet more serial port code. I have my own shim library, but it isn’t well tested and isn’t all that flexible — it does what I need, but I wanted something better. What I wound up with the serial library from Sigrok. You know Sigrok? The logic analyzer software.
You might counter that the serial port is old hat, so no one wants to support it with modern systems. While the physical serial port might be on life support, there’s no shortage of equipment that connects via USB that appears to be a serial port. So while I was talking to an FTDI chip on an FPGA board, you could just as well be talking to an Arduino or a USB voltmeter or anything.
I guess the Sigrok developers had the same problem I did and they took the time to write a nice API and port it to major platforms. Although Sigrok uses it, they maintain it as a separate project and it was just what I needed. Sort of. I say sort of because the version installed with Ubuntu was old and I needed some features on the newest release, but — as usual — the Internet came to the rescue. A quick Git command, and four lines of build instructions and we were ready to go.