Did you ever wonder what your monitor and your computer are talking about behind your back? As it turns out, there’s quite a conversation going on while the monitor and the computer decide how to get along, and sniffing out VGA communications can reveal some pretty fascinating stuff about the I²C protocol.
To reverse engineer the configuration information exchanged between a VGA monitor and a video card, [Ken Shirriff] began by lopping a VGA cable in two. The inside of such cables is surprisingly complex, with separate shielding wires for each color and sync channel and a host of control wires, all bundled in multiple layers of shielding foil and braid to reduce EMI. [Ken] identified the clock and data lines used for the I²C interface and broke those out into a PocketBeagle for analysis using the tiny Linux machine’s I²C tools.
With a Python script to help decode the monitor’s Extended Display Identification Data (EDID) data, [Ken] was able to see everything the monitor knows about itself — manufacturer, serial number, all the supported resolution modes, and even deprecated timing and signal information left over from the days when CRTs ruled the desktop. Particularly interesting are the surprisingly limited capabilities of a VGA display in terms of color reproduction, as well as [Ken]’s detailed discussion on the I²C bus in general and how it works.
Debugging with printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.
The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.
If you’ve played even just a few minutes of Minecraft, you know what a creeper is. For those not familiar with the wildly popular sandbox game, a creeper is a monster that creeps along silently until it’s close to a player, whereupon it self-destructs by exploding. Sometimes it kills the player outright, and other times the explosion blows them into lava or off a cliff, or off a cliff and then into lava. Creepers have no friends.
But now there’s a way to avoid creeper attacks, or at least get a little heads up that these green nasties are lurking about. With [John Allwine]’s creeper detector, Minecraft players can get a real-world indicator of the current in-game creeper threat. The hardware end is simple enough — it’s just a SparkFun RedBoard and a small strip of Neopixels in a laser-cut plywood case. The LEDs lie behind a piece of etched acrylic to diffuse their glow — extra points for the creeper pattern in the lens. The detector talks over USB to a Minecraft mod that [John] wrote to interface the game with the real world. The closer a creeper gets to the player, the brighter the light. — and when it flashes, watch out. See it in action in the video below, if you can stomach watching someone dig straight down. Never dig straight down.
If interfacing the Minecraft world and the real world sounds familiar, maybe it’s because we featured [John]’s SerialCraft mod a while back and admired the potential for using Minecraft as a gateway for getting kids into hardware hacking. We agree that this is a great project to work on with kids, but we may just order the parts to do it for our own Minecraft world. Creeper hate isn’t just for kids.
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.
Being a member of the bomb squad would be pretty high up when it comes to ranking stressful occupations. It also makes for great fun with friends. Keep Talking and Nobody Explodes is a two-player video game where one player attempts to defuse a bomb based on instructions from someone on the other end of a phone. [hephaisto] found the game great fun, but thought it could really benefit from some actual hardware. They set about building a real-life bomb defusal game named BUMM.
The “bomb” itself consists of a Raspberry Pi brain that communicates with a series of modules over a serial bus. The modules consist of a timer, a serial number display, and two “riddle” boxes covered in switches and LEDs. It’s the job of the bomb defuser to describe what they see on the various modules to the remote operator, who reads a manual and relays instructions based on this data back to the defuser. For example, the defuser may report seeing a yellow and green LED lit on the riddle module – the operator will then look this up and instruct the defuser on which switches to set in order to defuse that part of the bomb. It’s the challenge of quickly and accurately communicating in the face of a ticking clock that makes the game fun.
[hephaisto] took this build to Make Rhein-Main 2017, where they were very accepting of a “bomb” being brought onto the premises. The game was setup in a booth with an old analog S-video camera feed and a field telephone for communication – we love the detail touches that really add atmosphere to the gameplay experience.
[Jared Sanson] has a solar power setup on his beach house, consisting of 6 panels and a 24V battery bank, supplied by Outback Inc. Their chargers and inverters pair over a seemingly proprietary connection with a controller known as the MATE. The MATE has a standard serial output which gives some details about the operation, but [Jared] wasn’t getting the detailed information they could get from the controller’s screen. This meant it was time to reverse engineer the proprietary connection instead, which [Jared] calls MateNET.
The controller interfaces with the chargers over a Cat5 cable. [Jared] initially suspected RS-485, but it turned out to be regular serial at 0-24V logic levels, at 9600 baud, 9n1. To figure out the pinout, [Jared] went through the MATE circuitry with a fine-toothed comb, discovering an ATMEGA32. Since both the MATE’s user output & its connection to the other equipment are both serial, a logic mux is used to split the ATMEGA32’s single UART between the two serial connections. With the physical layer sorted, it was time to figure out how the protocol worked.
There’s a lot of reasons you might want to emulate the keyboard on your Commodore 64. The ravages of time and dust may have put the original keyboard out of order, or perhaps you need to type in a long program and don’t fancy pecking away with the less-than-stellar feedback of the standard keys. [podstawek] has come up with the solution: a Commodore 64 keyboard emulator that works over serial.
It’s a simple concept, but one that works well. A Python script accepts incoming keypresses or pre-typed text, then converts them into a 6-bit binary code, which is sent to an Arduino over the serial connection. The Arduino uses the 6-bit code as addresses for an MT8808 crosspoint switch.
The MT8808 is essentially an 8×8 matrix of controllable switches, which acts as the perfect tool to interface with the C64’s 8×8 keyboard matrix. Hardware wise, this behaves as if someone were actually pressing the keys on the real keyboard. It’s just replacing the original key switches with an electronic version controlled by the Arduino.
[podstawek] already has the setup working on Mac, and it should work on Linux and Windows too. There’s a little more to do yet – modifying the script to allow complex macros and to enable keys to be held – so check out the Github if you want to poke around in the source. Overall it’s a tidy, useful hack to replace the stock keyboard.