We’ve noticed that adding electronic paper displays to projects is getting easier. [NerdCave] picked up a 4.2-inch E-ink panel but found its documentation a bit lacking when it came to using the display under MicroPython. Eventually he worked it out, and was kind enough to share with the rest of the class.
These paper-like displays draw little power and can hold static images. There were examples from the vendor of how to draw some simple objects and text, but [NerdCave] wanted to do graphics. There was C code to do it, but it wasn’t clear how to port it to Python.
The key was to use the image2cpp website (we’ve used it before, but you can also use GIMP). Instead of C code, though, you get the raw bytes out and place them in your Python code. Once you know the workflow, it isn’t that hard, and this is an inexpensive way to add a different kind of display to your projects. The same image conversion will help you work with other displays, too.
As we all know, when developing software for any platform or simply hacking a bit of code to probe how something works, the ability to deploy code rapidly is a huge help. [Martin Donlon], aka [wickerwaka], is well known in retro gaming and arcade hardware reverse engineering circles and had the usual issues figuring out how an arcade CPU board worked while developing a MiSTer core. Some interesting ASICs needed quite a bit of poking, and changing the contents of socketed ERPOMs is a labour-intensive process. The solution was PicoROM, a nicely designed ROM emulator in a handy DIP-32 form factor.
As the title suggests, PicoROM is based on the Raspberry Pi RP2040. It emulates an 8-bit ROM up to 2MBits in size with speeds up to 100ns. Since it uses the RP2040, USB connectivity is simple, enabling rapid uploading of new images to one (or more) PicoROMs in mere seconds. A vertically orientated USB-C connector allows multiple PicoROMs to be cabled to the host without interfering with neighbouring hardware. The firmware running on core 1 passes data from the internal 264K SRAM, using the PIO block as a bus interface to the target. A neat firmware feature is the addition of a mechanism to use a ROM region as a bidirectional control channel, which the software running on the target can use to communicate back to the host computer. This allows remote triggering of actions and the reporting of responses. Responses which may not be physically observable externally. [Martin] is using this feature extensively to help probe the functionality of some special function chips on the target boards, which is still a slow process but helped massively by reducing that critical software iteration time. The PCB was designed with KiCAD. The project files for which can be found here.
When we think of an m.2 slot in our laptop or similar, it’s usually in the context of its PCI connectivity for high-speed applications such as solid state disks. It’s a connector that offers much more than that interface though, making it suitable for some unexpected add-ons. As an example [MagicWolfi] has produced an m.2 card which contains the equivalent of a Raspberry Pi Pico.
The board itself has the familiar m.2 edge connector at the bottom, and the RP2040 GPIO lines as postage-stamp indentations round the edges. On the m.2 front is uses the USB interface as well as a UART and the I2C lines, as well as some of the interfaces we’re less familiar with such as ALERT, WAKE, DISABLE1/2, LED 1/2, and VENDOR_DEFINED.
On one level this provides a handy internal microcontroller card with which you can do all the things you’d expect from a Pi Pico, but on another it provides the fascinating possibility of the Pico performing a watchdog or other function for the host device. We would be genuinely interested to hear more about the use of the m.2 slot in this way.
[David Shadoff] has a clear soft spot for the NEC console systems and has been collecting many tools and data about them. When developing with these old systems, having a way to upload code quickly is a real bonus, hence the creation of the PC-FX Dev Cart. Based on the Raspberry Pi RP2040, the custom cartridge PCB has everything needed to run software uploadable via a USB-C connection.
While the PC-FX is a CDROM-based system, it does sport a so-called FX-BMP or backup memory port cartridge slot, which games can use to save state and perform other special functions. Under certain circumstances, the PC-FX can be instructed to boot from this memory space, and this cartridge project is intended to enable this. Having a quick way to upload and execute code is very useful when exploring how these old systems work, developing new applications, or improving the accuracy of system emulators. The original FX-BMP cartridge has little more inside than a supercapacitor-backed SRAM and a custom interfacing IC, and of course, it would be quite a hassle to use this to develop custom code.
The RP2040 isn’t really being too tasked in this application, with one core dedicated to emulating a 128K x 8 SRAM, handling the PC-FX bus interface, and the other doing duty on the USB side. At the top of the PCB are a pair of 74LVC16T245 16-bit level shifter ICs, which need to be translated from the 5 Volt console voltage domain into the 3.3 Volts at which the microcontroller operates. Power for the board is taken from the USB, not the console, enabling code to be uploaded before powering up the target. This way, the power budget of the console isn’t compromised, and the cartridge can be initialized before powering up and booting.
[David] Needed to overclock the RP2040 to 240 MHz, way beyond the specification limit of 133 MHz, because despite the PIO block being fast enough to emulate the required interface timing, the latency passing data between the PIO and the CPU core was too large, hence the need for GPIO-based solution. The project was created in KiCAD; the design files can be found here, and only one mistake has been found so far!
[David] is also heavily involved with documenting and collecting all the PC-FX resources available in the wild. These can be found in this GitHub repo. It doesn’t look like we’ve covered the PC-FX before, but we have seen a few hacks about its older sibling, the PC Engine and the closely related TurboGrafx-16. Here’s a simple PC engine-to-TurboGrafx converter board for starters. If you lack the genuine hardware, do not despair; here is an FPGA-based emulator.
Generally speaking, the Hackaday Supercon badge will always have a place for SAO (rebranded as “Supercon add-ons”), and that makes sense. We did originate them, after all. This year, though, we’ve gone all in on SAO, and, in particular, we’ve asked to see more SAOs with communication capabilities. The standard has always had an I2C bus, but few people use them. I decided I wanted to set an example and cook up a badge for Supercon. Was it hard? Yes and no. I’ll share with you a little about the board’s genesis and the issues I found. At the end, I’ll make you a special offer, if you are going to Supercon.
The Idea
The front of the SAOGNR — the SAO connector is, of course, on the back
I’ve been a ham radio operator for a very long time. In fact, July was my 47th anniversary in the radio hobby. Well, that’s not true. It was my 47th year with a license. I had been listening to shortwave long before then. So, I wanted to do something with Morse code. You don’t have to know Morse code to get a license these days, but a lot of hams enjoy it.
I set out to do a simple board that would play some Morse code messages. But that’s just another blinking light LED with a buzzer on it, too. So, naturally, I decided it would also provide Morse code output for the I2C host. That is, the SAO could be used to convert ASCII to Morse code. Sounds simple, right? Sure.
Getting Started
I wanted to use a Raspberry Pi Pico but didn’t want to violate the SAO size requirements. Luckily, there’s an RP2040-Zero module that is quite tiny and looks more or less like a normal Pico. The two big differences are plusses: they have a reset button, and instead of a normal LED, they have a WS2812b-style LED.
Using that let me not worry about a lot of overhead on the board. Sure, it costs a few bucks more, so if you were mass-producing something, that’s not so good. But for this, it was perfect. I only had to add a speaker with a little transistor driver, which is probably unnecessary, four more WS2812B LEDs, and the SAO connector.
I was going to add a button, but I remembered from last year there is a way to use the BOOTSEL button on the module as a normal button, so I decided to cut a corner there. I could have shrunk the board, but I wanted some area for a protyping area and some cool silk screen, since I’m not artistic enough to come up with a nice outline for the board, so I kept the board full-size which is a lot of space.
The only strange thing is that the RP2040-Zero has parts on both sides, so it needs a cutout in the board. No problem. KiCAD didn’t have a good footprint for it that I could find, so I switched over to EasyEDA. They have handy integration with the parts you can get, too, so it is easy to price your board and even buy them already put together if you like.
While I waited for the boards, I decided to grab a similar Pico board and prototype the software. However, in the middle of this, I got a disturbing e-mail.
The Boards are Wrong?
The Chinese board house sent me a note: they were not sure the LEDs were connected properly. I checked, and I double-checked. They looked OK to me. I bravely asked them to build the boards as specified and went back to prototyping.
I’m not always a fan of Python, but we have a history of doing badges in Python so people can easily hack them. So I decided to stick to MicroPython. Getting the code and other features to work was a piece of cake. There is something surreal about using regular expressions to filter comments out of a file on a little microprocessor.
I2C Woe
Once I had the main features working, I set out to do the I2C when I realized an unpleasant fact. The Micropython library has I2C classes so you can host an I2C device. It does not have code that lets you be an I2C device yourself. CircuitPython apparently supports this, but I was in no mood to move the code over. Had I realized it going in, I might have made a different choice.
Luckily, an online forum had some code that directly manipulated the chip’s I2C registers and I was able to adapt that. If you are thinking of building an SAO with I2C capabilities, this is something to check before you go too far.
I stuck with the simple protocol that just lets me receive I2C commands because that’s all I needed, but there were examples of going further. For my project, I created the I2CTarget class. You tell the constructor which I2C bus you want to use, what pins you want to map to, and the I2C address you want to use. There are defaults for all of that.
Once it is running, you can check to see if data is available (call any()) and then read that data (get()). Don’t forget that reading data will block, so if you don’t want to block, check to see if anything is available first. The I2C hardware on the chip has a small FIFO, so that’s fine for this project.
I did create a subclass that allows an I2C object to act like a menu in the code. The menu object normally gets input from the user, but using this little trick lets the I2C commands fake user input.
The Boards Arrive
The board came in, as boards tend to do. I changed a few I/O pins in my code and… big sigh of relief, the LEDs were fine. A few tweaks on the code and the SAO was complete.
I left you all the files and documentation over on Hackaday.io. Maybe I went a little overboard with the documentation. You can decide. The source code is on GitHub, but you’ll find the link on the IO page.
Special Offer
Do you want one? Well, all the design files are there. Fire up your favorite way to etch boards or order them from your favorite board house. It wouldn’t be that hard to point-to-point wire one or put one on a breadboard except for the SAO connector, of course.
However, I have a deal for you. I have a limited number of these and will have them at Supercon. Find me — I’m easy to find since I mostly hang out at the soldering challenge table — and show me some code you propose to run that either uses the SAO or runs on the SAO. If I have any left, I’ll give you one, but when I’m out, I’m out. So, to be on the safe side, maybe make your own and bring it anyway.
Conectar
