Classic 80s Text-To-Speech On Classic 80s Hardware

October 26, 2021 by Bryan Cockfield 34 Comments

Those of us who were around in the late 70s and into the 80s might remember the Speak & Spell, a children’s toy with a remarkable text-to-speech synthesizer. While it sounds dated by today’s standards, it was revolutionary for the time and was riding a wave of text-to-speech functionality that was starting to arrive to various computers of the era. While a lot of them used dedicated hardware to perform the speech synthesis, some computers were powerful enough to do this in software, but others were not quite able. The VIC-20 was one of the latter, but thanks to an ESP8266 it has been retroactively given this function.

This project comes to us from [Jan Derogee], a connoisseur of this retrocomputer, and builds on the work by [Earle F. Philhower] who ported the retro speech synthesis software known as SAM from assembly to C which made it possible to run on the ESP8266. Audio playback is handled on the I2S port, but some work needed to be done to get this to work smoothly since this port also handles the communication with the VIC-20. Once this was sorted out, a patch was made to be able to hear the computer’s audio as well as the speech synthesizer’s. Finally, a serial command interface was designed by [Jan] which allows for control of the module.

While not many of us have VIC-20s sitting at home, it’s still an interesting project that shows the broad scope of a small and inexpensive chip like the ESP8266 which would have had a hefty price tag back in the 1980s. If you have other 80s hardware laying around waiting to be put to work, though, take a look at this project which brings new vocabulary words to that old classic Speak & Spell.

Continue reading “Classic 80s Text-To-Speech On Classic 80s Hardware” →

Capacitive Touch Controller For FPGAs

October 24, 2021 by Bryan Cockfield 10 Comments

Most projects that interface with the real world need some sort of input device. Obviously this article is being written from a standardized “human interface device” but when the computers become smaller the problem can get more complicated. We can’t hook up a USB keyboard to every microcontroller since we often only need a few buttons, but even buttons can be a little bit too cumbersome for some applications. For something even simpler, we would like to turn your attention to capacitive touch controllers.

Granted, these devices are really only simpler from a hardware perspective. Rather than a switch that can be prone to failure either when its moving parts break or its contacts become corroded, a capacitive touch button only needs a certain conductive area on something like a PCB, along with a few passive components, to work. The real difficulty is in the software, so this project aims to make it simpler to bring these sort of devices to any FPGA that needs some sort of interface like this. It can operate in stand-alone mode or in a custom user interface, and was written to be platform-independent in VHDL without the need for any dependencies or macros.

The project’s page goes into a great amount of detail on how capacitive touch sensors like these work in general, and describes the operation of this specific code as well. Everything is open source, so it’s ready to be put to work right away. If you need capacitive touch capabilities on something like a microcontroller, though, take a look at this tiny Atmel-powered musical instrument instead.

In Search Of The First Comment

October 23, 2021 by Elliot Williams 105 Comments

Are you writing your code for humans or computers? I wasn’t there, but my guess is that at the dawn of computing, people thought that they were writing for the machines. After all, they were writing in machine language, and whatever bits they flipped into the electronic brain stayed in the electronic brain, unless punched out on paper tape. And the commands made the machine do things, not other people. Code was written strictly for computers.

Modern programming practice, on the other hand, is aimed firmly at people. Variable and function names are chosen to be long and to describe what they contain or do. “Readability” of code is a prized attribute. Indeed, sometimes the fact that it does the right thing at all almost seems to be an afterthought. (I kid!)

Somewhere along this path, there was an important evolutionary step, like the first fish using its flippers to walk on land. Comments were integrated into programming languages, formalizing the notes that coders of old surely wrote by hand in the margins of the paper first-drafts before keying it in. So I went looking for the missing link: the first computer language, and ideally the first program, with comments. I came up empty handed.

Or rather full handed. Every computer language that I could find had comments from the beginning. FORTRAN had comments, marked by a “C” as the first character in a line. APL had comments, marked by the bizarro rune ⍝. Even the custom language written for the Apollo 11 guidance computers had comments — the now-commonplace “#”. I couldn’t find an early programming language without comments.

My guess is that the first language with a comment must have been an assembly language, because I don’t know of any machines with a native comment instruction. (How cool and frivolous would that be?)

Assemblers simply translate mnemonic names to their machine instruction counterparts, but this gives them the important freedom to ignore anything starting with, traditionally, a semicolon. Even though you’re just transferring the contents of register X to the memory location pointed to in register Y, you can write that you’re “storing the height above ground (meters)” in the comments.

The crucial evolutionary step, though, is saving the comments along with the code. Simply ignoring everything that comes after the semicolon and throwing it away doesn’t count. Does anyone know? What was the first code to include comments as part of the code itself, and not simply as marginalia?

DOOM Played By Tweet

October 13, 2021 by Bryan Cockfield 5 Comments

Getting DOOM to run on hardware it was never intended to run on is a tradition as old as time. Old cell phones, embedded systems, and ancient televisions have all been converted to play this classic first-person shooter. This style of playing games on old hardware might be passé now as the new trend seems to be the ability to play this game on more ethereal platforms instead. This project brings DOOM to Twitter.

The gameplay is a little nontraditional as well. To play the game, a tweet needs to be sent with specific instructions for the bot. The bot then plays the game according to its instructions and then tweets a video. By responding to this tweet with more instructions, the player can continue the game tweet-by-tweet. While slightly cumbersome, it does have the advantage of allowing a player to resume any game simply by responding to the tweet where they would like to start. Behind the scenes of the DOOM-playing Twitter bot is interesting as well and the code is available on the project’s GitHub page.

While we’ve seen plenty of DOOM instances on all kinds of hardware, it’s safe to say we’ve never really seen a gameplay experience quite like this one. It may stay as a curiosity, but DOOM porters are always looking for something else to run this classic game so it may eventually branch out or develop into something more user-friendly like this cloud-based Atari 2600.

Erasable Pen Ink Adds Colors To 3D Prints

September 28, 2021 by Bryan Cockfield 8 Comments

Changing colors during a 3D print is notoriously difficult. Either you need multiple heads ready to go during the print which increases operating and maintenance costs for your printer, or you need to stop the print to switch the filament and then hope that everything matches up when the print is resumed. There are some workarounds to this problem, but not many of them are as smooth an effortless as this one which uses erasable pen ink to add colors to the filament on the fly.

Erasable pen ink is a thermochromic material that doesn’t get removed from paper when erased like graphite from a pencil. Instead the heat from the friction of erasing causes it to become transparent. By using this property for a 3D print, the colors in the print can be manipulated simply by changing the temperature of the hot end. Of course the team at [Autodrop3d] had quite a learning curve when experimenting with this method, as they had to run the extruder at a much lower temperature than normal to have control over the ink’s color, had to run the print much slower than normal, and were using a very sticky low-temperature plastic for the print.

With all of these modifications to the print setup, there are bound to be some limitations in material and speed, but the results of the project speak for themselves. This allows for stock 3D printers to use this method with no hardware modifications, and the color changes can be done entirely in software. While everyone catches up with this new technology, there are some other benefits to a 3D printer with multiple print heads, though, and some clever ways of doing the switching without too much interruption.

Continue reading “Erasable Pen Ink Adds Colors To 3D Prints” →

The Newlib Embedded C Standard Library And How To Use It

July 19, 2021 by Maya Posch 4 Comments

When writing code for a new hardware platform, the last thing you want to do is bother with the minutiae of I/O routines, string handling and other similarly tedious details that have nothing to do with the actual project. On bigger systems, this is where the C standard library would traditionally come into play.

For small embedded platforms like microcontrollers, resources are often tight enough that a full-blown stdlib won’t fit, which is why Newlib exists: to bring the portability benefits of a standard library to microcontrollers.

Whether you use C, C++ or MicroPython to program an MCU, Newlib is likely there under the hood. Yet how exactly does it integrate with the hardware, and how are system calls (syscalls) for e.g. file and input/output handling implemented? Continue reading “The Newlib Embedded C Standard Library And How To Use It” →

Cracking A GBA Game With NSA Tools

July 16, 2021 by Bryan Cockfield 1 Comment

[Wrongbaud] is a huge fan of Japanese kaiju-style movies, including Godzilla and King Kong. In honor of the release of a new movie, he has decided to tackle a few projects to see how both of these monsters can hold their own against other legendary monsters. In this project, he is using Ghidra, named after another legendary kaiju, against the password system of the Game Boy Advance game Kong: King of Atlantis.

Since this project is a how-to, [wrongbaud] shows how to search Ghidra for existing scripts that might already have the functionality needed for GBA analysis and emulation. When not, he also illustrates how to write scripts to automate code analysis, and then moves on to cracking the level password system on the game.

The key to finding the passwords on this game was looking for values in the code that were seven characters long, and after some searching [wrongbaud] is finally able to zero in on the code responsible for handling passwords. Once found a brute force method was automated to find viable passwords, and from there the game was officially pwned. For anyone interested in security, reverse engineering, or just the way that binaries work, it’s quite the detailed breakdown. Of course, it’s not the only example we have seen that uses this software tool to extract passwords.