It’s quite probable that any of you who have built a keyboard will have done so using a matrix of keys connected to a microcontroller, or if you are old-school, a microprocessor. A CPU can scan the keyboard matrix with ease, and pass whatever is typed either to whatever software it is running, or to a host computer. There was a time however when available CPUs were not considered powerful enough to do all this and also perform a useful task, so a keyboard would have its own decoder chip that would output ASCII over a parallel interface. It’s an era [John Calhoun] harks back to with Adam74, a little ASCII terminal which takes its input from that 7-bit parallel port.
In the place of a forest of TTL chips which might have graced the originals, within that attractive curved laser cut acrylic case is an LCD display and a Teensy microcontroller board. There’s a level shifter for the classic 5 volt logic, and of course a small buzzer for the essential BEL character. In these days when a parallel interface is relatively rare, he describes the rediscovery of alternate earth lines in a ribbon cable to minimize cross-talk. Should you wish to try your own, everything can be found on GitHub.
All in all it’s a fun way to rediscover an old idea.
The desk of any self-respecting technology enthusiast in the 2020s is not complete without a special keyboard of some sort, be it a vintage IBM Model M, an esoteric layout or form factor, or just a standard keyboard made with clacky mechanical switches. But perhaps we’ve found the one esoteric keyboard to rule them all, in the form of [HIGEDARUMA]’s 8-bit keyboard. You can all go home now, the competition has been well and truly won by this input device with the simplest of premises; enter text by setting the ASCII value as binary on a row of toggle switches. No keyboard is more retro than the one you’d find on the earliest microcomputers!
Jokes aside, perhaps this keyboard may be just a little bit esoteric for many readers, but it’s nevertheless a well-executed project. Aside from the row of binary inputs there is a keypress button which sends whatever the value is to the computer, and a stock button that allows for multiple inputs to be stored and sent as one. If you pause for a moment and think how often you use Ctrl-C and Ctrl-V for example, this is an essential function. There’s more information on a Japanese website (Google Translate link), which reveals that under the hood it’s a Bluetooth device running on an ESP32.
We can imagine that with a bit of use it would be possible to memorize ASCII as binary pretty quickly, in fact we wouldn’t be at all surprised to find readers already possessing that skill. But somehow we can’t imagine it ever being a particularly fast text input device. Take a look for yourselves, it’s in the video below the break.
Continue reading “Mechanical Keyboards Are Over, This Device Has Won”
Everyone by now has probably seen the original — and best; fight us — installment of the Star Wars franchise, and likely the ASCII-art animation version of it that improves greatly on the film by eliminating all those distracting special effects, human actors, and the soundtrack. But what we haven’t had until now is a portable player for ASCIIWars, to enjoy the film in all its character-based glory while you’re on the go.
While this tribute to [Simon Jansen]’s amazing ASCII-art achievement might seem like a simple repackaging of the original, [Frank] actually had to go to some lengths to make this work. After getting [Simon]’s blessing, the build started with a WEMOS D1 Mini, a good platform for the project less for its wireless capabilities and more for its 4 MB of flash memory. A 240×360 TFT LCD display was selected to show the film; the scale of the display made most fonts hard to read, so [Frank] used Picopixel, a font designed for legibility on small screens. The animation file is stored on the SPIFFS file system on the D1’s flash memory, and a few lines of code parse it and send it to the display. The final touch is mounting the whole thing is an old slide viewer, which magnifies the display to make it a little easier to see.
As much as we applaud [Frank]’s tribute to [Simon]’s effort, there’s no reason to confine this to the Star Wars universe. If you read up on the history of ASCII art, which goes surprisingly far back, you might be inspired to render another classic film in ASCIImation and put it on a viewer like this. ASCII-Metropolis, anyone?
Continue reading “Enjoy An ASCII Version Of Star Wars In The Palm Of Your Hand For May The 4th”
At some point or another, many of us have tried to see how much of our digital lives could be accessed from the comfort of a terminal. We’ve tried Alpine for email, W3M for web browsing, and even watched Star Wars via telnet. But, in the increasingly socially-distant world we find ourselves in today, we find ourselves asking: what about video calling?
Okay, we weren’t asking that. But thankfully [Andy Kong] was, and saw fit to implement it when he and a friend created AsciiZOOM, a “secure, text-based videoconferencing app, accessible from the safety of your terminal.”
As you may have guessed, [Andy]’s solution replaces the conventional video stream we’re all used to with realtime animated ASCII art. The system works by capturing a video stream from a webcam, “compressing” each pixel by converting it into an ASCII character, and stuffing the entire frame into a TCP packet. Each client is connected to a server (meeting room?) which coordinates the packets, sending them back and forth appropriately.
As impressive as it is impractical, the only area in which the project lacks is in audio. [Andy] suggests using Discord to solve that, but here’s hoping we see subtitles in version 2! Will AsciiZOOM be replacing our favorite videoconferencing suite any time soon? No. Are we glad it exists? You betcha.
Continue reading “Real Hackers Videoconference In Terminal”
In case you grow tired of clear-written, understandable code, obfuscation contests provide a nice change of scenery, and trying to make sense of their entries can be a fun-time activity and an interesting alternative to the usual brainteasers. If we ever happen to see a Simpsons episode on the subject, [Andy Sloane] has the obvious candidate for a [Hackerman Homer] entry: a rotating ASCII art donut, formatted as donut-shaped C code.
The code itself actually dates back to 2006, but has recently resurfaced on Reddit after [Lex Fridman] posted a video about it on YouTube, so we figured we take that chance to give some further attention to this nifty piece of art. [Andy]’s blog article goes in all the details of the rotation math, and how he simply uses ASCII characters with different pixel amounts to emulate the illumination. For those who prefer C over mathematical notation, we added a reformatted version after the break.
Sure, the code’s donut shape is mainly owed to the added filler comments, but let’s face it, the donut shape is just a neat little addition, and the code wouldn’t be any less impressive squeezed all in one line — or multiple lines of appropriate lengths. However, for the actual 2006 IOCCC, [Andy] took it a serious step further with his entry, and you should definitely give that one a try. For some more obfuscated shell animations, check out the fluid dynamics simulator from a few years back, and for a more recent entry, have a look at the printf Tic Tac Toe we covered last month.
Continue reading “Mmm… Obfuscated Shell Donuts”
Testing software is — sometimes — easier than testing hardware. After all, you can always create test files and even fake user input before monitoring outputs using common tools. Hardware though, is a bit different. Sometimes it is hard to visualize exactly what’s happening. [Andrew Ray’s] answer? Produce simulated waveforms using ASCII text.
The process uses some custom tools written in OCaml, but the code is available for you on GitHub. The tool, called Hardcaml, allows you to write test benches for hardware — not a new idea for FPGA developers. The output, however, is an ASCII text waveform and common software development tools can check that waveform against the expected output.
Continue reading “Testing Hardware With ASCII Waveforms”
Buried deep within all UNIX-based operating systems are vestiges of the earliest days of computing, when “hardware” more often than not meant actual mechanical devices with cams and levers and pulleys and grease. But just because UNIX, and by extension Linux, once supported mechanical terminals doesn’t mean that getting a teletype from the 1930s to work with it is easy.
Such was the lesson learned by [CuriousMarc] with his recently restored Model 15 Teletype; we covered a similar Model 19 restoration that he tackled. The essential problem is that the five-bit Baudot code that they speak predates the development of ASCII by several decades, making a converter necessary. A task like that is a perfect job for an Arduino — [Marc] put a Mega to work on that — but the interface of the Teletype proved a bit more challenging. Designed to connect two or more units together over phone lines, the high-voltage 60-mA current loop interface required some custom hardware. The testing process was fascinating, depending as it did on an old Hewlett-Packard serial signal generator to throw out a stream of five-bit serial pulses.
The big moment came when he used the Teletype to log into Linux on a (more or less) modern machine. After sorting out the mysteries of the
stty command, he was able to log in, a painfully slow process at 45.5 bps but still a most satisfying hack. The ASCII art — or is it Baudot art? — is a nice bonus.
We love restorations like these, and can practically smell the grease and the faint tang of ozone around this device. We’re not thrilled by the current world situation, but we’re glad [CuriousMarc] was able to use the time to bring off a great hack that honors another piece of our computing history.
Continue reading “Logging Into Linux With A 1930s Teletype”