Scott Shawcroft Is Programming Game Boys With CircuitPython

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.

18 thoughts on “Scott Shawcroft Is Programming Game Boys With CircuitPython

  1. I don’t get the logic. The interpreter must reside on the device, consuming valuable memory. It runs maybe 100 times slower than a compiled program.
    How is any of this better?

    1. 100 times slower for heavy math and magic, for trivial bleepy bloopy stuff, maybe only 3-5x slower.

      But really, this is how to make a gameboy into a soundcard.

    2. Faster time to market. And you can call C from MicroPython (and I assume Circuit python), so as a library author you can wrap performant code in sugary syntax.

      But memory fragmentation over time is a serious issue for long-running applications.

        1. DOS batch files ARE indeed real programming, as are shell scripts. They are an indispensable part of any large software project and they are debugged and code reviewed and checked into version control just like C source .

      1. “faster time to market” only if your programmer only knows python – and that’s a problem. I’m also not sure what kind of product would be faster to market using python than just C. Also, if “sugary syntax” is what you are wrapping C code in, it probably makes sense to just wrap that “performant code” in C since you’re using C anyway.

        CircuitPython is a solution in search of a problem.

        1. The most excellent programming advise ever is from Prof Gerald Sussman who said that version 1 of your project will inevitably fail, so embrace reality and write version 1 in an interpreted language to learn the problem, and then code up version 2 in a high performance language.

    3. Isn’t CircuitPython a fork of MicroPython (and why)? And I recall it is pretty quick and about the same as Cpython – but a lot smaller. Plus, when you are on an ST32xxxx like the original (168MHz ARM) 95% of applications will be spinning its wheels waiting for events. Besides. MicroPython has two ways of going much faster for hardware control, the most important of which is the Viper decorator that allows pointers to hardware registers. (The other is @micropython.native)

    4. Actual experience says that such systems spend 99% of CPU in low level application code and 1% of CPU in the interpreter so the speed of the interpreter is pretty much irrelevant.

  2. Man i get frustrated reading
    “But its so slow in comparison to C”

    There is nothing wrong using other people examples, files or tools and modifying it for purpose just like there is no problem in using obfuscated languages to perform a process. You think every person who uses a computer knows how powershell works? no but they can still produce meaningful stuff using obfuscation of process using GUIS. There is a whole branch of devops called chatops which allows obfuscation and shows how allowing people to use tools they dont fulling understand within a wall can speed everyone up and allows for people to specialise in the things they know best.

    Not everyone is a genius, not everyone has to be to make things and people who make tools to let people into their world and learn should be celebrated not berated with
    “BUT ITS SO SLOW”

    1. As long asn you don’t write code professionally and you play in your bedroom with it or prototype with it it’s fine.

      But you try to build a product on top of it you are doing it wrong, you lose money if you try to solve a software problem with some hardware and that’s a fact.

      1. And why does it matter if someone who isn’t you loses time or money doing something in a way that’s different to how you would do it???

        A: it doesn’t

        But that also assumes people don’t learn and change and evolve there process. I work at a software company, do you think they haven’t changed from shitty processes to more advanced ones over time? Getting something to work to fill a need and slowly fixing the shortcomings of that product is literally how every piece of software worth a damn is written. Even if that means changing language your working in. If you are just talking about business usage, time to market is a huge factor in deciding profitability. So someone who can duct tape together a solution, test it in a environment it will be used in and modify according to customer demandsis leaps and bounds ahead of the guy who decides to write something well, not test it in a production environment but run tests on it instead and not rely on feedback from people who use the product but on what he thinks best.

        The truth is, you are gatekeeping, you think the only way to do things is the way you know and anyone who approaches it differently is inherently stupid. People solve problems everyday in silly ways doesn’t mean the solution is wrong. It just that we do things differently.

      2. I have personally made a lot of money working on a very slow interpreted language with just the right C bindings. We passed our first POC with flying colors, performance was excellent because the CPU spent 99+% of it’s time executing the low level C code and less than 1% of CPU in the interpreter.

        Most complex software is running some sort of domain specific high level language. There are only about 4 people on this planet who can write C code competently so interpreters are good things.

Leave a Reply to Clovis FritzenCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.