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.
We’ve all at some point or other seen something done online by somebody else, and thought “I’d like to have a go at that!”. When [Phooky] saw the artwork on the #PlotterTwitter hashtag, he remembered a past donation of a plotter to the NYC Resistor hackerspace. Some searching through the loft revealed a dusty cardboard box containing not the lovely Hewlett-Packard he’d hoped for, but instead an Apple 410 Color Plotter. This proved to be such an obscure part of the legacy Apple product line that almost no information was available for it save for a few diagrams showing DIP switch settings for the serial port.
Undeterred, he took a look inside and found a straightforward enough control board featuring a Z80 processor and support chips with 1983 date codes. The ROMs were conveniently socketed, so after dumping their contents, he was able to identify the routine for the plotter’s test program, and thus work from there to deduce its command set. A small matter of the plotter using hardware handshaking lines to signal a full buffer later, and he was able to use it to produce beautiful plots. Should you be one of the lucky few remaining Apple 410 owners, you may find his software library for it to be of some use.
When did you last buy a mouse? Did it have a little adapter in the box? There was a time when if you bought a USB mouse, in the box was also an adapter to allow it to be used with the older PS/2 interface. And if you were to go back a few more years into the past, you’d have found when you bought a mouse with a PS/2 connector fitted, it may well have come with an adapter for a 9-pin RS232 serial port. Those mice from a decade or more ago would have contained the software to recognise the interface into which they were plugged, and emulate it accordingly. It is unlikely then that you could take a modern USB-only device and an unholy chain of USB-to-PS/2-to-serial adapters, and have it work as a serial mouse. Want to run Windows 3.1 on a 386DX? You need a serial mouse.
Happily, [matze525] has come along with a solution for those of you with a need to drive an ancient PC with a serial mouse. He’s created a PS/2 to RS232 mouse converter, and it takes the form of a little PCB with an AT90S2313P microcontroller to do the translation and an RS232 level converter chip.
It might sound like a rather unexpected device to produce, but we can see it fills an important niche. In the early 1990s mice were not the reliable optical devices we have today, instead they had nasty mechanical connections inside, or if you were extremely lucky, optical encoder wheels. The supply of still-reliable RS232 mice must therefore be dwindling, and if you have a Windows 3.1 PC to keep alive then we can see the ability to use a more modern pointing device has a lot going for it.
When it comes to large systems, there are a lot more computers than there are people maintaining them. That’s not a big deal since you can simply use a KVM to connect one Keyboard/Video/Mouse terminal up to all of them, switching between each box simply and seamlessly. The side effect is that now the KVM has just as much access to all of those systems as the human who caresses the keyboard. [Yaniv Balmas] and [Lior Oppenheim] spent some time reverse engineering the firmware for one of these devices and demonstrated how shady firmware can pwn these systems, even when some of the systems themselves are air-gapped from the Internet. This was their first DEF CON talk and they did a great job of explaining what it took to hack these devices.