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.
Every now and then a remote control acts up. Maybe you are trying to change the channel on your television and it’s just not working. A quick way to determine if the remote control is still working is by using a cell phone camera to try to see if the IR LED is still lighting up. That can work sometimes but not always. [Rui] had this problem and he decided to build his own circuit to make it easier to tell if a remote control was having problems.
The circuit uses a Vishay V34836 infrared receiver to pick up the invisible signals that are sent from a remote control. A Microchip 12F683 processes the data and has two main output modes. If the remote control is receiving data continuously, then a green LED lights up to indicate that the remote is functioning properly. If some data is received but not in a continuous stream, then a yellow LED lights up instead. This indicates that the batteries on the remote need to be replaced.
The circuit also includes a red LED as a power indicator as well as RS232 output of the actual received data. The PCB was cut using a milling machine. It’s glued to the top of a dual AAA battery holder, which provides plenty of current to run the circuit.