Jaromir Sukuba: The Supercon 2018 Badge Firmware

March 7, 2019 by Elliot Williams 3 Comments

If you missed it, the Hackaday Supercon 2018 badge was a complete retro-minicomputer with a screen, keyboard, memory, speaker, and expansion ports that would make a TRS-80 blush. Only instead of taking up half of your desk, everyone at the conference had one around their neck, when they weren’t soldering to it, that is.

The killer feature of the badge was its accessibility and hackability — and a large part of that was due to the onboard BASIC interpreter. And that’s where Jaromir comes in. Once Voja Antonic had finalized the design of the badge hardware for our conference in Belgrade in the spring of 2018, as Jaromir puts it, “all we needed was a little bit of programming”. That would of course take three months. The badge was battle-tested in Belgrade, and various feature requests, speed ups, and bugfixes were implemented (during the con!) by Jaromir and others.

Firmware work proceeded over the summer. Ziggurat29 helped out greatly by finding ways to speed up the badge’s BASIC interpreter (that story is told on his UBASIC and the Need for Speed project page) and rolled into the code base by Jaromir. More bugs were fixed, keywords were added, and the three-month project grew to more like nine. The result: the badge was in great shape for the Supercon in the fall.

Jaromir’s talk about the badge is supremely short, so if you’re interested in hacking a retrocomputer into a PIC, or if you’ve got a badge and you still want to dig deeper into it, you should really give it a look. We don’t think that anyone fully exploited the CP/M machine emulator that lies inside — there’s tons of software written for that machine that is just begging to be run after all these years — but we’re pretty sure nearly everyone got at least into the basement in Zork. Dive in!

Continue reading “Jaromir Sukuba: The Supercon 2018 Badge Firmware” →

Programmable Ruler Keeps 1970’s Computing Alive

March 2, 2019 by Tom Nardi 23 Comments

A ruler seems like a pretty simple device; just a nice straight piece of material with some marks on it. There are some improvements out there to the basic design, like making it out of something flexible or printing a few useful crib notes and formulas on it so you have a handy reference. But for the most part, we can all agree that ruler technology has pretty much plateaued.

Well, not if [Brad] has anything to say about it. His latest creation, the Digirule2, is essentially an 8-bit computer like those of the 1970’s that just so happens to be a functional ruler as well. Forget lugging out the Altair 8800 next time you’re in the mood for some old school software development, now you can get the same experience with a piece of hardware that lives in your pencil cup.

Even if you’ve never commanded one of the blinkenlight behemoths that inspired the Digirule2, this is an excellent way to get some hands-on experience with early computer technology. Available for about the cost of a large pizza on Tindie, it represents one of the easiest and most cost-effective ways to tell your friends that as a matter of fact you have programmed a computer in binary.

The Digirule2 is powered by a Microchip PIC18F43K20, and is programmed by punching binary in one byte at a time with a bank of eight tactile switches. To make things a little easier, programs can be saved to the internal EEPROM and loaded back up just as easily thanks to the handy buttons next to the power switch. Now all you’ve got to do is figure out what all those blinking LEDs mean, and you’ll be in business.

The original Digirule was a logic gate simulator that we first covered back in 2015. We’re always happy to see projects grow and evolve over time, and think this new retro-computer themed variant is going to be quite popular with those who still love toggle switches and blinking lights.

Continue reading “Programmable Ruler Keeps 1970’s Computing Alive” →

Live Hacking And A MIDI Keytar

March 2, 2019 by Brian Benchoff 8 Comments

We can’t think of where you’d buy a new, cheap, MIDI keytar that’s just a keyboard and a handle with some pitch and mod wheels or ribbon controllers. This is a format that died in the 90s or thereabouts. Yes, the Rock Band controller exists, but my point stands. In fact, the closest you can get to a cheap, simple MIDI keytar is the Alesis Vortex Wireless 2 Keytar, but the buttons on the handle don’t make any sense. [marcan] of Wii and Kinect hacking fame took note. (YouTube, embedded below.)

Reverse engineering is a research project, and all research projects begin with looking at the docs. When it comes to consumer electronics, the best resource is the documents a company is required to submit to the FCC (shout out to FCC.io), which gave [marcan] the user manual, and photos of the guts of the keytar. The ‘system update download’ files are living on the Alesis servers, and that’s really all you need to reverse engineer a keytar.

The first step is extracting the actual device firmware from whatever software package appears on the desktop when you download the software update. This is a simple job for 7zip, and after looking at a binary dump of the firmware, [marcan] discovered this was for an STM chip. With the datasheet of the chip, [marcan] got the entry point for the firmware, some values, and the real hardware hacking began. All of this was done with IDA.

This is a five-hour hacking session of cross-referencing the MIDI spec and a microcontroller built thirty years after this spec was developed. It’s an amazing bit of work just to find the bit of code than handled the buttons on the keytar grip, and it gets even better when the patched firmware is uploaded. If you want to ‘learn hacking’, as so many submitters on our tip line want to do, this is what you need to watch. Thanks [hmn] for the tip.

Continue reading “Live Hacking And A MIDI Keytar” →

LittlevGL Brings GUI Tools To Micropython

February 28, 2019 by Lewin Day 16 Comments

Microcontrollers are wonderfully useful things, but programming them can be a little daunting if you’re used to the simplicity of compiling for regular PCs. Over time though, this has become easier. Communities have strayed away from assembly code and created higher-level languages such as Micropython, to allow these devices to be programmed in a more accessible manner. Unfortunately, Micropython has historically lacked a decent high-level GUI library. Thankfully, that’s no longer the case, with [amirgon] porting LittlevGL to the platform.

Putting a GUI into a project with a screen seems simple, until one actually gets down to brass tacks. A simple button can consist of a background color, text, and a symbol – and that’s not even considering the use of shading or other visual effects. Having a library to handle the grunt work can massively cut down development time.

LittlevGL is the work of [kisvegabor], and is programmed in C, but this effort has made it possible to integrate it with Micropython code. It’s all object-oriented, and thus works well in the broader Python framework. [amirgon] notes that it’s particularly good for quick development, due to Python’s ability to run code without a slow compiling step.

There are other approaches to this problem, too – with MyOpenLab being a particularly versatile example.

Teardown Of A Luxury Bluetooth Nightlight

February 28, 2019 by Tom Nardi 4 Comments

If you had asked us yesterday what peak nightlight technology looked like, we might have said one of those LED panels that you stick in the outlet. At least it beats one of those little wimpy light bulbs behind the seashell, anyway. But after looking at a detailed teardown of the “Glow Light” from Casper, we’ve learned a lot about the modern nightlight. Such as the fact that there are adults who not only sleep with nightlights, but are willing to pay $89 USD for one.

But more importantly, as [Tyler Mincey] demonstrates in his excellent look inside one of these high-end nightlights, they are gorgeous pieces of engineering. Even if a nightlight next to the bed has long since gone the way of pajamas with feet on them for you personally, we think you’ll be impressed just how much technology has gone into these softly glowing gadgets.

On the outside they might look like marshmallows, but the insides look far more like what you’d expect from an expensive piece of consumer gear. It’s based on the Nordic nRF52832 Bluetooth SoC which is becoming an increasingly common sight in consumer gadgets, and uses an inertial measurement unit (IMU) to detect when it’s moved or twisted and adjusts the light output accordingly. If you’ve got the disposable income for two of these things, they’ll even synchronize so that twisting one will dim its counterpart.

The teardown that [Tyler] did on the Glow Light is quite frankly one of the best we’ve ever seen, and while it might be a bit light on the gritty technical details, it more than makes up for that with the fantastic pictures that are about as close to actual hardware porn as you can get. The only question we have now is, how long until a hacker replicates this design with a 3D printed enclosure and an ESP?

[Thanks to Adrian for the tip.]

New Part Day: The STM32 That Runs Linux

February 27, 2019 by Brian Benchoff 45 Comments

There are a lot of ARM microcontrollers out there, and the parts from ST are featured prominently is the high-power builds we’re seeing. The STM32F4 and ~F7 are powerhouses with great support, and the STM32F0 and the other younger children of the family make for very good, low-power microcontrollers. Now, the STM32 family is getting a big brother. It runs Linux. It’s two ARM Cortex-A7 cores and one M4 core on the same chip. The STM32MP1 is the chip you want if you still can’t figure out how to waste computing cycles by blinking LEDs.

Block diagram of the STM32MP157 Image: ST

First, that Linux support. The STM32MP157C was mainlined into Linux last summer, and there is support for Android. So yes, this chip can run Linux. There is an optional 3D GPU in this family, a MIPI-DSI controller, support for HDMI-CEC, USB 2.0, and 10/100M or Gigabit Ethernet. This brings us the inevitable question of whether you can build a Raspberry Pi clone with these parts. Maybe, champ, but if you’re asking that question it’s probably not you that’s going to build one. It looks as if this chip is designed for phones, set-top boxes, and smart TVs. That doesn’t preclude a single board computer, but the biggest problem there is maintaining software support anyway.

The chip family in question all come with dual ARM Cortex-A7 processors running at a nominal 650MHz. There’s also a Cortex-M4 running at 209MHz, and the ST literature suggests that engineers are already running Linux on the A7 and an RTOS on the M4. This chip will need external memory, but DDR3 / DDR3L / LPDDR2 / LPDDR3 are supported.

This chip is only announced right now, you can’t get it on Mouser or Digikey yet, and there’s no information on pricing. However, there are two development boards available, the Evaluation board, which features 1 GB of DDR3L, 128 MB of Flash, and an 8 GB eMMC. There’s a 5.5″ display, and enough connectors to make your heart flutter. The Discovery board is a bit more cut down, and comes with a 4″ 480×800 LCD, WiFi, Bluetooth LE, and of course it comes with GPIO expansion connectors for an Arduino and Raspberry Pi. The Discovery Board is not available at this time, but it will sell for $99 USD.

Multiple OLEDs? Save Pins By Sharing The I2C Clock

February 27, 2019 by Donald Papp 17 Comments

Inexpensive OLED displays with I2C interfaces abound, but there is a catch: they tend to be stuck on I2C address 0x3C. Some have a jumper or solder pads to select an alternate (usually 0x3D), but they lack any other method. Since an I2C bus expects every device to have a unique address, this limits the number of displays per bus to one (or two, at best.) That is all still true, but what [Larry Bank] discovered is a way to get multiple OLED displays working with considerably fewer microcontroller pins than usually needed.

While bit-banging I2C to host one display per bus on the same microcontroller, an idea occurred to him. The I2C start signal requires both clock (SCL) and data (SDA) to be brought low together, but what would happen if the displays shared a single clock line? To be clear, each OLED would — logically speaking — still be on its own I2C bus with its own data line, but they would share a clock signal. Would a shared clock cause attached devices to activate unintentionally?

A quick test consisting of four OLED displays (all with address 0x3C) showed that it was indeed possible to address each display with no interference if they shared a clock. Those four individually controlled displays needed only five I/O lines (four SDA, one shared SCL) instead of eight. The Multi_OLED library is available on GitHub, and in case it is useful for devices other than OLED displays, bit-banged I2C with support for shared clock lines is available separately.

There’s more to do with OLEDs than get clever with signals: check out these slick number-change animations, and that even looks to be a project that could benefit from a few saved GPIO pins, since it uses one small display per digit.