Scott Shawcroft Is Programming Game Boys With CircuitPython

March 2, 2020 by Kristina Panos 18 Comments

Some people like to do things the hard way. Maybe they drive a manual transmission, or they bust out the wire wrap tool instead of a soldering iron, or they code in assembly to stay close to the machine. Doing things the hard way certainly has its merits, and we are not here to argue about that. Scott Shawcroft — project lead for CircuitPython — on the other hand, makes a great case for doing things the easy way in his talk at the 2019 Hackaday Superconference.

In fact, he proved how easy it is right off the bat. There he stood at the podium, presenting in front of a room full of people, poised at an unfamiliar laptop with only the stock text editor. Yet with a single keystroke and a file save operation, Scott was able make the LEDs on his Adafruit Edge Badge — one of the other pieces of hackable hardware in the Supercon swag bag — go from off to battery-draining bright.

Code + Community

As Scott explains, CircuitPython prides itself on being equal parts code and community. In other words, it’s friendly and inviting all the way around. Developing in CircuitPython is easy because the entire environment — the code, toolchain, and the devices — are all extremely portable. Interacting with sensors and other doodads is easy because of the import and library mechanics Python is known for, both of which are growing within the CircuitPython ecosystem all the time.

CircuitPython is so friendly that it can even talk to old hardware relatively easily without devolving into a generational battle. To demonstrate this point, Scott whipped out an original Nintendo Game Boy and a custom cartridge, which he can use to play fun sounds via the Game Boy’s CPU.

Now You’re Playing With Python

It’s interesting to see the platforms on which Scott has used the power of CircuitPython. The Game Boy brings the hardware for sound and pixel generation along with some logic, but he says it’s the code on the cartridge that does the interesting stuff.

The CPU communicates with carts at a rate of 1MHz. As long as you can keep this rate up and the CPU understands your instructions, you can get it to do anything you want.

Scott’s custom cart has a 120MHz SAMD51. He spends a second explaining how he gets from Python libraries down to the wire that goes to the Game Boy’s brain — basically, the C code underneath CircuitPython accesses direct structs defined within the SAMD to do Direct Memory Access (DMA), which allows for jitter-free communication at 1MHz.

He’s using the chip’s lookup tables to generate a 1MHz signal out of clock, read, and A15 in order to send music-playing instructions to the sound register of the Game Boy’s CPU. It sounds like a lot of work, but CircuitPython helps to smooth over the dirty details, leaving behind a simpler interface.

If you want easy access to hardware no matter how new or nostalgic, the message is clear: snake your way in there with CircuitPython.

Continue reading “Scott Shawcroft Is Programming Game Boys With CircuitPython” →

Additive, Multi-Voice Synth Preserves Sounds, Too

January 13, 2020 by Kristina Panos 2 Comments

For his final project in [Bruce Land]’s microcontroller design class, [Mark] set out to make a decently-sized synth that sounds good. We think you’ll agree that he succeeded in spades. Don’t let those tiny buttons fool you, because it doesn’t sound like a toy.

Why does it sound so good? One of the reasons is that the instrument samples are made using additive synthesis, which essentially stacks harmonic overtones on top the fundamental frequency of each note. This allows synthesizers to better mimic the timbre of natural, acoustic sounds. For each note [Mark] plays, you’re hearing a blend of four frequencies constructed from lookup tables. These frequencies are shaped by an envelope function that improves the sound even further.

Between the sound and the features, this is quite an impressive synth. It can play polyphonically in piano, organ, or plucked string mode through a range of octaves. A PIC32 runs the synthesizer itself, and a pair of helper PIC32s can be used to record songs to be played over. So [Mark] could record point and counterpoint separately and play them back together, or use the helper PICs to fine-tune his three-part harmony. We’ve got this thing plugged in and waiting for you after the break.

If PICs aren’t what you normally choose, here’s an FPGA synth.

Continue reading “Additive, Multi-Voice Synth Preserves Sounds, Too” →

Using Lookup Tables To Make The Impossible Possible

January 10, 2020 by Dan Maloney 60 Comments

Embarrassing confession time: I never learned my multiplication tables in grade school. Sure, I had the easy tables like the twos and the fives down, but if asked what 4 x 7 or 8 x 6 was, I’d draw a blank. As you can imagine, that made me a less than stellar math student, and I was especially handicapped on time-limited tests with lots of long multiplication problems. The standard algorithm is much faster when you’ve committed those tables to memory, as I discovered to my great woe.

I was reminded of this painful memory as I watched Charles Lohr’s 2019 Supercon talk on the usefulness and flexibility of lookup tables, or LUTs, and their ability to ease or even completely avoid computationally intensive operations. Of course most LUT implementations address problems somewhat more complex than multiplication tables, but they don’t have to. As Charles points out, even the tables of sines and logarithms that used to populate page after page in reference books have been ported to silicon, where looking up the correct answer based on user input is far easier than deriving the answer computationally.

Yes, this is a Minecraft server all thanks to LUTs.

One of the most interesting examples of how LUTs can achieve the seemingly impossible lies in an old project where Charles attempted to build a Minecraft server on an ATMega168. Sending chunks (the data representations of a portion of the game world) to clients is the essential job of a Minecraft server, and on normal machines that involves using data compression. Rather than trying to implement zlib on an 8-bit microcontroller, he turned to a LUT that just feeds the raw bytes to the client, without the server having the slightest idea what any of it means. A similar technique is used by some power inverters, which synthesize sine wave output by feeding one full cycle of values to a DAC from a byte array. It’s brute force, but it works.

Another fascinating and unexpected realization is that LUTs don’t necessarily have to be software. Some can be implemented in completely mechanical systems. Charles used the example of cams on a shaft; in a car’s engine, these represent the code needed to open and close valves at the right time for each cylinder. More complicated examples are the cams and gears once found in fire control computers for naval guns, or the programming cards used for Jacquard looms. He even tips his hat to the Wintergatan marble machine, with its large programming drum and pegs acting as a hardware LUT.

I found Charles’ talk wide-ranging and fascinating. Originally I thought it would be an FPGA-heavy talk, but he didn’t actually get to the FPGA-specific stuff until the very end. That worked out fine, though — just hearing about all the cool problems a LUT can solve was worth the price of admission.

And for the curious, yes, I did eventually end up memorizing the multiplication tables. Oddly, it only clicked for me after I started playing with numbers and seeing their relationships using my first calculator, which ironically enough probably used LUTs to calculate results.

Continue reading “Using Lookup Tables To Make The Impossible Possible” →