When it comes to novelty typefaces there is no shortage of weird and wonderful fonts to be found when you have finally tired of Comic Sans. Everything from bananas forming letters to Wild West saloon lettering can be yours, plus of course our favourite, the embossed Dymo label. But there’s a new kid on the novelty typeface block, and for us it sweeps all before it.
We have shamefacedly to admit that we don’t know binary ASCII by sight, so we’ll have to take his word for it. But for the curious there’s a demo from which you can amuse yourself creating traces, and if you can’t recognize serial ASCII then the chances are few of the people around you can either. We take our hats off to [Guy], and it’s something we’re sure we’ll use at some point to delight and confuse our friends. It’s not the first font we’ve brought you, here are some more if you come from the bitmap era.
The best part of I2C is that it is a bus that is available just about anywhere, covering a vast ecosystem of devices that offer it as a hardware-defined interface, while being uncomplicated enough that it can also be implemented purely in software on plain GPIO pins. Despite this popularity, I2C is one of those famous informal standards that feature a couple of popular implementations, while leaving many of the details such as exact timing, bus capacitance and other tedious details to the poor sod doing the product development. Thus it is that we end up with articles such as a recent one on the tongue-twisting [pair of pared pears] blog, covering issues found while implementing an I2C slave.
As with any shared bus, whether multi-master or not, figuring out when the bus is clear is a fun topic, yet one which can cause endless headaches. One issue here comes from a feature that the SMBus version of I2C calls quick read/write. This allows for the rapid transfer of some data. Still, depending on the data returned by the slave, it may appear to the master that nothing is happening yet, since SDA is being held low by the slave until the stop condition, essentially locking the bus.
I2C hold times example.
Where things get even more exciting comes generally in the form of what logic analyzers love to traumatically call a ‘spurious start/stop condition’. This refers to the behavior of SDA and SCL, with SDA going low before SCL indicating an error. This can occur due to a hold time that’s too low, causing other devices on the bus to miss the transition. Here SMBus defines a transition time of 300 ns, while I2C calls for 0 seconds, but it’s now suggested to delay calling a start/stop condition until a delay of 300 ns has passed. Essentially, it would seem that implementing a hold time is the way forward until evidence to the contrary appears.
The third pitfall pertains to the higher-speed modes of I2C, including Fast-Mode (FM) and Fast-Mode Plus (FM+). Backward compatibility with these higher speed versions is absent to spotty. Although FM+ (introduced by NXP in 2007) is supposed to be backward compatible with slower speeds, effectively the timing requirement differences between the FM+ and FM standards are too large to compensate for. At least in the current versions of the standards, but one of the joys of I2C is that there’s always another new set of revisions to look forward to.
One of the problems with designing things on a chip is finding a good way to talk to the outside world. You may not design chips yourself, but you care because you want to connect your circuits — including other chips — to the chips in question. While I2C and SPI are common solutions, today’s circuits are looking for more bandwidth and higher speeds, and that’s where Interlaken comes in. [Comcores] has an interesting post on the technology that blends the best of SPI 4.2 and XAUI.
The interface is serial, as you might expect. It can provide both high-bandwidth and low-latency multi-channel communications. Interlaken was developed by Cisco and Cortina Systems in 2006 and has since been adopted by other industry-leading companies. Its latest generation supports speeds as high as 1.2 Tbps.
Often with more “modern” complex protocols involving handshaking, token exchanges, and all the other hoops and whistles accompanying them, we forget how useful and powerful serial can be. In what might be a wonderful tribute to that, [Davide Gironi] created a simple AVR-powered 16-digit serial display.
It can display two numbers, and that’s it. A MAX7219 drives the display, and the brains are an ATmega8. It’s straightforward to send new values: a start byte, a CRC, the data to display, and an end byte. A CP2102 provides a UART to USB interface to connect to a host. An EEPROM helps it remember the last numbers shown. It supports positive, negative, and floating-point numbers.
This is a beautiful example of doing one thing and doing it well. The design is simple and allows it to be used for anything. You can show the current stock market price, the time for the next two trains for your commute, or whatever else you can think of. [Davide] included a schematic, code, and a 3d printed enclosure.
When it’s not just sticking fake gears on things and calling it a day, the Steampunk look is pretty cool. Imagining technology in a world stuck with Victorian aesthetics is a neat idea, and one that translates to the look of other time periods — Fallout, anyone?
But what if you try to create a technological aesthetic based on a more recent and less celebrated time? That’s what [ghettobastler] has attempted with this somewhat bizarre Minitel-YouTube-VCR mash-up. Taking inspiration from a webcomic’s take on “Formicapunk,” modern tech based on the aesthetic of the wildly successful French videotex service of the 70s and 80s, the system uses a very cool Minitel 1B terminal and a Raspberry Pi 3.
A custom level-shifter for the Pi
With the help of a level-shifting circuit, the Mintel and the Pi talk over serial, allowing the terminal to be used as, well, a terminal for the Pi. Videos are downloaded from YouTube by the Pi, which sends the video to the VCR from its composite output, and controls the VCR with an IR LED that emulates the original remote. Come to think of it, just watch the video below — it’s probably easier than trying to describe it.
It’s weird, true, but we love the look of that Minitel terminal. Something about it just screams cyberdeck; if anyone has a spare one of these, get busy and put something together for our Cyberdeck Design Contest.
The hacking life is not without its challenges, and chief among these is the tendency to always be in acquisition mode. When we come across a great deal on bulk equipment, or see a chance to rescue some obscure gear from the e-waste stream, we generally pounce on it, regardless of the advisability.
We imagine this is why [Nathan] ended up with a hoard of PS/2 keyboards. Seriously, there are like thousands of the things. And rather than lug a computer to them for testing, [Nathan] put together this handy Arduino-based portable tester to see which keyboards still have some life left in them. The video below goes into detail on the build, but the basics are pretty simple — an Arduino, a 16×2 LCD display, and a few bits and bobs to run it off a LiPo pack and charge it up. Plus, of course, a PS/2 jack to plug in a keyboard and power it up. Interestingly, the 16×2 display is an old Parallax unit, from the days when RadioShack still existed and sold their stuff. That required a little effort to get it working with the Arduino, but in the end it works like a charm — plug in a keyboard and whatever you type shows up on the screen.
Of course, it’s hard to look at something like this, and that mountain of keyboards in the background, and not scheme up ways to really automate the whole test process. Perhaps an old 3D printer with a stylus mounted where the hot end would go could press each key in turn while the tester output is recorded — something like this Wordle-bot, but on a keyboard scale. That kind of goes against [Nathan]’s portability goal, but it’s still fun to think about.
Universal Serial Bus has been the defacto standard for sending information to and from computer peripherals for almost two decades, but despite the word “universal” in the name this wasn’t always the case. Plenty of competing standards, including USB, existed in the computing world in the decades before it came to dominance, and if you’re trying to recover data from a computer without USB you might have to get creative with how it’s done.
[Ben] recently came across a 80486 with this problem, so he had to get creative to recover the contents of the drive. He calls it the “lunchbox” computer due to its form factor, and while it doesn’t have USB it does have a tried-and-trusted serial port to communicate with other computers. [Ben] wrote up a piece of software for both the receiving computer and the sending computer in order to copy the drive sectors one by one across a serial link to a standalone computer running Windows XP, and was able to recover the contents of the drive that way instead.
All of the code [Ben] wrote is available on his GitHub page for anyone looking to boot up a 30-year-old computer again. While it might sound uncommon, computers of this vintage are still around running things like CNC machines or old mainframes.
