TL;DR

• DIY mouth-operated USB HID mouse for appr. 10$ in materials.
• Built from hand-solderable, easy-to-source components and 3D-printed parts.
• Custom PCB with an open-source firmware.
• Includes a 3D-printed sip/puff pressure sensor.
• Appears as a standard USB HID mouse can be calibrated via serial terminal.
• Complete hardware files, firmware, BOM, and assembly instructions are available below.

Introduction

It has been a while since I published my design for a mouth-operated mouse in 2015 (3D Printed Mouth-Operated Mouse). Even after more than 10 years, it remains one of the designs that continues to receive a surprising amount of attention on Thingiverse. That made me think it might be worth revisiting the concept.

A lot has changed since then. Affordable PCB manufacturing has become widely available, electronic components are much easier to source, and 3D printing has evolved significantly, making it more accessible than ever. The DIY assistive technology ecosystem has also grown, with projects such as:

• Mouth-Operated Mouse V3
• LipSync
• FLipMouse

to name just a few.

Even so, I think there is still room for an updated version of my original design. My goals for this revision were:

• Maintain the low cost, or reduce it even further.
• Use components that are easy to source.
• Optimize the design for production in small batches (5-10 units), for example in makerspaces.

Disclaimer

The design focuses on cost-effectiveness. However, it is not intended for mass production. All components have been chosen to be easily sourced in most locations. It does not use any parts that require specialized soldering equipment. The goal was to provide a product that can be assembled by a person with intermediate skills, for example in a makerspace, using a basic soldering iron and simple magnification, along with widely available consumables such as super glue and access to a 3D printer capable of printing PLA.

I hope this design is helpful or sparks some creative ideas! It’s not a ready-to-go product, though, so it does take a bit of skill to make and may not work perfectly on the first try. Have fun experimenting, and feel free to adapt it for your own projects. If you have any problems, I’m happy to help as long as I have the time, but if I’m busy, you’re on your own.

Design

The old design relied on off-the-shelf parts. Most of these were available from AliExpress-style shops, along with a pressure sensor salvaged from an e-cigarette. While this approach worked for some time, most of those parts are no longer available and have been difficult to source for quite a while.

This time, I wanted to avoid those dependencies. The new design uses a custom double-sided PCB that can be ordered from your preferred PCB manufacturer. It exclusively uses components that can be soldered by hand with basic SMD soldering skills. There are no extremely fine-pitch parts or QFN packages. The BOM has also been optimized to keep both the total component count and the number of different component types as low as possible.

One thing the design does not use is an off-the-shelf pressure sensor. I found that pressure sensors suitable for a project like this are either relatively expensive compared to the overall project cost or difficult to source. I recently wrote an article about how to build a pressure sensor using strain gauges and 3D printing. Developing that sensor was a prerequisite for this project, as I wanted a solution that was inexpensive and easy to source.

In addition to the pressure sensor and the assembled PCB, you’ll need a few 3D-printed parts, some hardware such as screws, and a length of silicone tubing.

Cost

The design mainly focuses on cost-effectiveness. To support that claim, I’d like to take a closer look at the actual cost breakdown.

The costs were calculated based on the components required to build 10 units. I did not cut corners on critical parts such as the joystick and generally chose components from well-known manufacturers. Most prices are based on listings from LCSC and AliExpress, so there is still some potential to reduce the overall cost further.

The calculation does not include taxes, shipping, customs fees, or assembly consumables such as solder, flux, adhesive tape, and similar materials.

The main takeaway is that the material cost of a single device is around 7 EUR (7.35 EUR). Even when accounting for the fact that many components must be purchased in larger quantities than required for a batch of 10 units, the effective cost remains below 10 EUR per device (9.88 EUR).

PCB

Case

Sensor

Assembly

To build the device, you will need the following parts:

• Electronics
  • Assembled PCB
  • Assembled pressure sensor
• 3D-Printed Parts
  • Case bottom
  • Case front cover
  • Spacer
  • Mouthpiece mount
  • Mouthpiece
  • Mounting nut cover
• Hardware
  • 5× M3×20 screws (e.g. DIN 7985)
  • 5× M3 hex nuts (DIN 934)
  • 1× 1/4"-20 nut
  • 2× M2×5 countersunk screws (or self-tapping screws)
• Silicone hose (4mm OD / 2mm ID)

PCB

All files required to manufacture and assemble the PCB are available in the Releases section of the hardware repository.

To order the PCB, Gerber files are provided. For assembly, an interactive Bill of Materials (BOM) is also included.

Not every listed component needs to be populated. Components marked DNP (Do Not Populate) should be omitted. These parts are normally hidden in the interactive BOM.

Pressure Sensor

The pressure sensor is covered in a separate article. Please refer to:

3D Printed Pressure Sensor

UPDATE 09.08.2026: Alternative Pressure Sensor

There is a second option for the sensor. If you don’t want to build the DIY sensor, there is a commercial drop-in replacement. The XGZP160010S from CFSensor can be connected mostly in the same way as the DIY sensor.

To make mounting easier, a carrier PCB is provided here: https://codeberg.org/embedded-ideas/ahid_hw_cf_sensor_single/releases

There is an additional model for the back of the case that allows you to mount the assembled board. The connections to the board are as follows:

Remove R13 and R14 and connect the positive signal line from the sensor board to either the lower pad of R13 or the upper pad of R14. If you want, you can also bridge those pads, as they are connected anyway.

The sensor can be screwed to the case using two M3x6 mm screws and two M3 nuts.

Device Assembly

⚠️ Before starting assembly, make sure the firmware has been flashed onto the PCB.

1. Insert the 1/4"-20 nut into the corresponding cutout in the case and secure it using the mounting nut cover.
2. Insert an M3 nut into each of the four corner slots of the case.
3. Connect the pressure sensor to the PCB using the solder pad connections.
4. Mount the sensor inside the case using the two M2 screws. Make sure it is installed in the correct orientation.
5. Carefully place the PCB into the case. Ensure that the sensor wires are routed underneath the PCB without being pinched. There should be a small gap between the PCB and the wires.
6. Install the mouthpiece mount onto the joystick.
7. Fit the front cover, making sure it is correctly oriented. The cover includes a cutout that aligns with the pressure sensor.
8. Insert the remaining M3 nut into the slot of the mouthpiece.
9. Slide the mouthpiece onto the mouthpiece mount.
10. Install and tighten the M3 screw to secure the mouthpiece.
11. Finally, connect the pressure sensor to the mouthpiece using the silicone hose.

Firmware

I have been trying to publish a new version of the original mouth-operated mouse for several years now. During that time, I actually completed two new hardware designs. The reason I never published them was that I couldn’t find the time to write the software the way I wanted.

This time, I wrote the software in a way that I believe is a step in the right direction. It’s now structured to be extendable and maintainable. It isn’t just a simple Arduino sketch, but it also isn’t quite what I ultimately want it to be. It’s fully usable, but it’s still a work in progress.

The goal is to create a fairly universal firmware that can implement more than just mouse functionality. The firmware should be configurable through profiles to adapt to specific tasks, and it should also be adaptable to different hardware devices.

Since implementing mouse functionality alone isn’t particularly challenging, the current firmware is more than sufficient for this project. However, I expect that future devices may make use of much more of its potential.

Currently, the inputs are mapped as follows:

• Joystick movement controls the mouse cursor. When scroll mode is enabled, joystick movement scrolls the page instead.
• Pressing the joystick toggles between “cursor mode” and “scroll mode”".
• Pressure sensor inputs emulate the mouse buttons:
  • Sip = Left mouse button
  • Puff = Right mouse button

Flashing the Firmware

There are two ways to get the firmware onto the microcontroller. You can use the debug port and a wlink compatible debuger/programmer. For most people it will be easier to just use the integrated USB bootloader. When pressing the pushbutton on the board while powering up the device, it will enter the bootloader. You can then use e.g. a tool like wchisp to upload the firmware. I also provide a web-based version for flashing the firmware:

Firmware Flash Tool

Calibration

Before using the device, perform an initial calibration of the joystick and the pressure sensor. Calibration is done through a serial terminal. You can use a terminal program such as PuTTY or Minicom. If you prefer not to install any software, you can use my web-based terminal instead:

Serial Terminal

The cal command provides several subcommands for calibration. First, list all available inputs that can be calibrated:

cal list

> cal list
0: Joystick x-Axis
1: Joystick y-Axis
2: Pressure Sensor
>

To calibrate an input, use the cal start command followed by the input number. The calibration process will guide you through the required steps. If you are not satisfied with the result, simply do not confirm the calibration. The previous calibration will be restored automatically.

cal start

> cal start 0
Please don't operate Joystick x-Axis and leave it in the idle position!
Measuring baseline
Operate Left and leave idle afterwards.
Operate Right and leave idle afterwards.
Please test calibration:        0
Operate both functions (Left and Right) to keep the calibration.
Restoring previous calibration.
Done.
>

Repeat this process for all inputs. Once all channels have been calibrated, the device is ready for use.

Finally, store the calibration in persistent memory. If you skip this step, the calibration will be lost after the device is power-cycled.

cal write

> cal write
Calibration stored successfully!
>

Project files

The project is split into two repositories on Codeberg. One repository contains the hardware design along with the 3D models. The software is maintained as a separate project because it may be reused for other devices in the future. It is not intended to be used exclusively for the Mouth Operated Mouse II.

Hardware (Board and 3D-Models)

• Repo: https://codeberg.org/embedded-ideas/MouthOperatedMouse2-HW
• Releases: https://codeberg.org/embedded-ideas/MouthOperatedMouse2-HW/releases

AHID Software

• Repo: https://codeberg.org/embedded-ideas/ahid
• Releases: https://codeberg.org/embedded-ideas/ahid/releases

TL;DR

• Differential air pressure sensor
• Built using a 3D-printed body and standard strain gauges
• Material cost below USD 2 (below USD 1 in quantities of 10 or more)
• Designed for a measurement range of ±10 kPa
• Tested for detecting sip-and-puff gestures

Introduction

I recently needed an air pressure sensor for one of my projects. I was looking for something inexpensive and easy to source. The sensor only needed to operate over a range of roughly ±10 kPa relative to atmospheric pressure, and there were no strict accuracy requirements. Essentially, I needed a sensor capable of detecting the mild vacuum and overpressure generated when a person sips and puffs into a tube.

There are quite a few suitable options available. ST, for example, offers the MPXx5010 sensor family (originally developed by NXP), and there are also sensors from Asian manufacturers such as CFSensor. The problem is that these options tend to be either relatively expensive or difficult to source for one-off builds.

This made me wonder whether it would be possible to build a “good enough” pressure sensor using only inexpensive, widely available components.

As it turns out, it is…to some extent.

The resulting sensor will never be as precise or reliable as a commercially manufactured device. Nevertheless, it works surprisingly well for the intended purpose. After an initial calibration, it remains reasonably stable over a typical indoor temperature range and is not particularly sensitive to humidity.

What I will not do in this article is present a scientific analysis of the sensor or provide a complete specification. I expect every sensor to behave somewhat differently due to variations in the construction process, the materials used, and countless other factors that cannot be tightly controlled when building a device like this at home.

Instead, my goal is to show that it is possible to build a simple, low-cost pressure sensor that is perfectly adequate for certain applications. I will describe how I built mine so that others can adapt the design, improve upon it, or build on my code and 3D models for their own projects.

Sensor Idea

Building a pressure sensor comes with several challenges, and building one from 3D-printed parts adds even more. My initial idea was to print a hollow body with a thin membrane and attach a strain gauge to the membrane. After several iterations, I concluded that a two-part design would be the best solution:

The lower part forms the membrane, which is 0.4 mm thick. A circular wall is printed directly onto the membrane, creating the air chamber and providing a mounting surface for the top cover. The top cover contains the hose connector and two mounting points for screws. It is significantly thicker than the membrane to provide the necessary rigidity. Both parts are bonded together using super glue, creating an airtight seal. I used PLA+ to print the housing, although PETG would likely be a good alternative as well.

For the measurement, I use two strain gauges in a half-bridge configuration. One gauge is mounted in the center of the membrane, where it experiences tensile strain when positive pressure is applied. The second strain gauge is centered on the edge of the membrane, where it experiences compressive strain under the same pressure.

This arrangement offers another important advantage: thermal compensation. Since both strain gauges are mounted on nearly the same surface, they experience the same temperature changes. As a result, their resistances change by approximately the same amount, causing most of the temperature-induced error to cancel out.

Sensor Assembly

Assembling the sensor can be a bit challenging. The most delicate step is attaching the strain gauges to the membrane. I don’t think there is a single “best” method for doing this. Although it is possible to attach the strain gauges first and solder the wires afterward, I would not recommend that approach, as the heat generated during soldering can easily deform or melt parts of the thin membrane.

In the following, I will describe the assembly method that I have found to be the most reliable and easiest to work with.

First, I used two small strips of adhesive tape to fix the strain gauges onto a clean surface at the correct spacing (8.5 mm), while leaving the solder pads exposed.

Next, I added additional tape to the sides to ensure everything stayed in place while soldering the wires to the strain gauges. I used red and black wires for the reference voltage connections and a yellow wire for the signal. The insulation of the signal wire was stripped in a way that allowed it to be connected to both gauges, making the soldering process much easier.

After attaching the wires and cleaning the assembly with IPA, I applied another piece of adhesive tape over the entire assembly and trimmed it to the correct width using an X-Acto knife.

The complete assembly can then be lifted and positioned on the membrane. To do this, first mark the center of the membrane using either the alignment marks on the sides of the case or the provided printable template. Make sure you do not use the center of the strain gauge itself. Instead, use the alignment marks on the gauge.

Lift the gauge assembly using the side of the transfer tape opposite the wires as a hinge. This ensures that the assembly can be returned to exactly the same position after applying the adhesive. Apply a small amount of super glue to the strain gauges, then lower the assembly back onto the membrane. Press the gauges firmly and evenly against the membrane for 15–30 seconds. Once the adhesive has set, carefully remove the transfer tape wherever possible.

Optionally, you can apply a small amount of additional glue to secure the wires to the side of the sensor for improved strain relief.

As a final step, glue the two halves of the sensor together. Apply a small amount of super glue along the wall of the bottom part, then firmly press the top cover into place. Hold it for 15 to 30 seconds, then allow the glue to fully cure.

Your sensor is now ready to use.

Taking Measurements

We now have two resistors on a membrane whose resistance changes slightly when pressure is applied. To make the sensor useful, we need to measure these tiny resistance changes.

The two strain gauges form one half of a Wheatstone bridge. By adding a second voltage divider and connecting both dividers to the same reference voltage, we complete the bridge. The voltage difference between the two halves is the quantity we are interested in. Ideally, the reference divider remains stable while the voltage across the strain gauge divider changes with the applied pressure.

Because these voltage changes are extremely small, they must be amplified before they can be measured. Since we are interested in the difference between the two bridge outputs, a differential amplifier, more specifically an instrumentation amplifier, is the ideal choice. Finally, the analog signal must be converted into a digital value.

Building such a circuit from discrete components is unnecessarily complicated. Instead, I highly recommend using an off-the-shelf solution such as the HX711 or HX717. These inexpensive ICs integrate everything we need: a stable reference voltage, a differential amplifier, and a high-resolution analog-to-digital converter. The following example shows how to connect the sensor to an HX717. R1 and R2 represent the strain gauges on the sensor.

Congratulations! We now have a digital representation of the applied pressure. But is it useful yet? Probably not. The raw value is not calibrated and has no meaningful reference point. Instead, we simply get an integer that does not directly correspond to any physical quantity.

Calibration is therefore an essential step and brings us to the software side of the project. First, we need to establish a reference point for zero pressure, followed by one or more calibration points that define the measurement range.

At first glance, it might seem sufficient to measure the sensor with no pressure applied to determine the zero point. In practice, however, the zero value drifts depending on the previously applied load. After positive pressure, the resting value settles slightly higher than it does after negative pressure. As a result, the sensor effectively has two different zero points, one for positive measurements and one for negative measurements.

A practical solution is to treat all values between these two zero points as zero. Measurements above the positive zero point use that value as their reference, while measurements below the negative zero point use the negative reference. The measured value can then be linearly interpolated between the corresponding zero point and the calibrated maximum or minimum, allowing the result to be expressed as a more intuitive range, such as ±100%.

I did not calibrate the sensor against any specific physical reference value, so I cannot make any claims about its absolute accuracy or linearity. Instead, I calibrated it based on my own ability to perform sip and puff gestures.

If you have access to equipment capable of generating a stable pressure or vacuum and can perform some measurements, I would be very interested in the results, especially regarding the sensor’s linearity.

For my intended use, however, calibrating the sensor to my own sip and puff strength is entirely sufficient ;)

I wrote some code to execute the signal conditioning and the calibration. You will find this in the download section of this post.

Final Thoughts

The described sensor works quite well for its intended purpose, and I think it has some potential for DIY projects. I haven’t seen anything that uses a similar technique, so I think it is worth writing about and sharing the idea.

Printing the sensor also provides a lot of freedom in terms of its shape and how it can be mounted. This may allow you to build a product with a custom-made sensor that would not have been possible using a commercial one. You could even integrate the sensor directly into the enclosure of a product.

If you use this idea in one of your own projects, I would be happy to hear about it.

Project files

DOWNLOAD: Code, STL and SCAD files

I recently ran into a problem that might be interesting for others. I wanted to use multiple HX717 load cell ADCs in one of my projects. These chips use a very simple serial protocol: pulses on the clock line shift out the result of the previous conversion, and a new conversion is triggered immediately afterward. The number of additional pulses after the 24-bit result defines the gain and the channel for the next conversion.

This protocol makes it very easy to connect multiple ADCs to the same clock line while reading data from multiple sensors simultaneously. My approach was to generate the clock using a timer. A second channel of that timer triggers a DMA transfer. All data lines are connected to the same GPIO port, which makes it possible to use DMA to capture all inputs in parallel and store them in memory efficiently.

What I didn’t know is that there is an undocumented behavior, or perhaps a feature, built into the protocol. After triggering a conversion, the data line goes low when the result is ready. This allows you to trigger, for example, on a falling edge to start reading the data.

However, what is not documented is what happens if you don’t read the data. After approximately 3 ms, the device generates a pulse of about 160 µs, which repeats every 3 ms. You can interpret this as a kind of “Hey, I still have data you requested” signal. When using a single sensor, this can be helpful if you miss the initial falling edge for some reason. But when using multiple HX717s, this behavior becomes problematic.

Another complication is that conversion time is not constant. I measured conversion times ranging from approximately 500 µs to 3500 µs. This introduces jitter in the first falling edge, meaning each HX717 becomes ready at a slightly different time. As a result, it’s not practical to trigger on the falling edge of a single device when multiple devices are used in parallel.

To address this, I initially tried using a fixed timing approach. The driver triggers conversions at a constant frequency to achieve a steady output rate. I used a trigger frequency of 290 Hz, which is below the specified maximum of 320 Hz. However, some conversions occasionally took longer than expected. In a setup with three HX717 devices, this meant that one device could still be busy while the others were already finished.

To handle this, I added a check to ensure that all data lines had gone low (indicating “data ready”) before issuing the next clock sequence. This helped avoid reading incomplete data, but it also exposed the interaction with the periodic “reminder” pulses, which can interfere with edge-based detection if not handled carefully.

Besides occasionally skipping a conversion, this approach works in most cases, but there is an important edge case.

If a conversion is skipped because another sensor is not ready yet, the timing can align such that the clock pulses are sent exactly during one of those periodic “reminder” pulses on the data line. And that’s where things break down.

The device does not handle this situation well.

Initially, I assumed it would simply return the data as usual, since from a protocol perspective the sequence still appears valid. However, that’s not what happens. Instead, the device shifts out invalid data and then pulls the data line high for approximately 15 ms. This delays subsequent conversions and introduces corrupted samples, which must be detected and filtered out.

I considered several potential solutions, but ruled them out before implementation:

• Extending the first high pulse to >160 µs
  • Not viable. The protocol only allows a maximum high time of 50 µs.
  • Pulses of around 80 µs already trigger a power-down condition.
• Adding discrete logic to combine the data signals
  • Would require additional hardware components.
  • There are still timing scenarios where this approach could run into the same issue.
• Polling the state of the data lines
  • Inefficent.
  • If the state is sampled just before the rising edge of the periodic pulse, it could lead to the same problem.

I believe there is no truly clean solution to this problem unless each HX717 runs on its own isolated interface. Since I wanted to operate up to six devices simultaneously in this project, that was not an option due to hardware limitations.

As I don’t have strict timing requirements for precise filtering and still had some processing resources available, I settled on the following approach:

I added a falling-edge interrupt for each data signal. The interrupts are disabled while the clock sequence is being sent, and all flags are cleared before re-enabling them. Inside the interrupt handler, I store a timestamp for each device and check whether the time difference between the current timestamp and the stored one is below a threshold of 2.8 ms.

This ensures two things:

• a) that a falling edge has occurred after the clock sequence, and
• b) that there is still some margin before the device triggers its periodic data-line pulse.

Based on this, the system only sends the next clock sequence when all devices are within a valid timing window.

In theory, this approach could lead to a situation where the system never finds a valid window to send a clock sequence. In practice, however, this is extremely unlikely due to independent clock drift and conversion-time jitter across devices.

In real-world operation, the results are solid. The driver achieves an average sample rate of around 316Hz, with the lowest observed rate dropping to 232 Hz over a five-minute measurement period.

TL;DR

• Based on the Open xGB Display
• Matches original Game Boy Color display size
• USB UVC video output via USB-C
• 3x integer scaling (9 pixels per pixel)
• Supports color intensity control, tinting, and pixel or scanline effects
• Custom FPCs for simplified assembly and a clean internal layout

Introduction

This mod was developed as a demo for the Open xGB Display. Since I had not covered the Game Boy Color on this blog before, and because I think the mod turned out quite nicely, I decided to write a separate blog post on how to build it.

The mod is built around the ER-TFT028A5-4, a modern IPS TFT display with an active width of 43.20 mm, which almost perfectly matches the original Game Boy Color display. It looks great when used with off the shelf lenses.

The display is a relatively recent model with solid technical specifications. It offers a high contrast ratio of 1500:1 and a brightness of 800 cd/m².

The 480×640 resolution allows for pixel perfect 3× integer scaling, using 9 pixels per pixel. When applying effects such as horizontal or vertical lines, as well as a pixel effect, most of the pixels remain active. There is also a long term supply promised by buydisplay.com, available until at least 2034.

Besides the display, the second main feature is the integrated video capture. The mod includes a custom FPC to connect the USB C port to the Open xGB Display board. It is designed to fit into the upper half of the shell, so you do not need to sacrifice the link port. It can also double as a charging port if you use it as a 5 V supply for a battery charging mod. Two solder pads provide easy access to the USB VBUS.

The connection to the original Game Boy Color hardware is also made via a custom FPC cable, which provides solder pads for directly connecting the buttons and the enable line.

Before you proceed, I highly recommend reading the post about the Open xGB Display in order to know what you are getting yourself into ;)

What to Expect – and What Not To

All data and materials are provided “as is”. If you have questions, I’m happy to help when I have the time, however, support is not guaranteed, and responses may be delayed. If you encounter any problems, I would appreciate it if you report them so the project can continue to improve. If you are able to fix an issue yourself, contributions are very welcome!

Disclaimer: Use of the provided information, files, and build instructions is entirely at your own risk. No guarantee is given regarding accuracy, completeness, or functionality. Any liability for damage to hardware or software, consequential damages, or other claims arising from use is excluded.

Settings and Effects

You can access the device menu via a long press of the Select button. First, the brightness menu will be shown. If you hold it longer, you will enter the settings menu.

• Color Intensity

  • Brightness: General brightness value of the image, which manipulates the V value in the HSV model
  • Saturation: Changes the overall saturation of the image, which manipulates the S value in the HSV model

• Tinting

  • Enable: Enables tinting the image in a single color
  • Color: Sets the hue value to a fixed value, fixing the H value in the HSV model

• Effects

  • Mode: Horizontal lines, vertical lines, or both, which generate a pixel-like effect
  • Brightness: Brightness value of the lines, allowing for a generally brighter image compared to using only black
  • Saturation: Allows desaturating the lines instead of making them darker

• Misc

  • Vertical position: Sets the vertical position to align the image with the lens

Build

I will not cover how to assemble the PCB. I will assume you have a fully working, fully assembled Open xGB Display PCB at hand. If you need information on how to assemble the board, have a look at this post. If you need information on how to flash the software, you will find it in this post. You will need the following materials for the build:

• Parts

  • Open xGB Display PCB
  • ER-TFT028A5-4 TFT module
  • GBC FPC adapter
  • USB FPC adapter
  • 3D printed TFT frame
  • 3D printed USB cover
  • Game Boy Color shell and lens

• Tools and consumables

  • Double-sided adhesive tape
  • Files
  • X-Acto knife
  • Side cutters
  • Wires, ~1 to 1.2 mm outer diameter
  • Thin wires for button connections
  • 3D printed cut template
  • 3D printed display dummy

1. TFT cutout: All modifications are done on the front of the shell. Cut a slot through the display compartment walls on the front. You can use the 3D printed template to get the correct dimensions. The display dummy is also a good way to test the fit without risking the real TFT module. The cutout does not need to be perfect, since it will be covered by the lens anyway.

2. USB cutout: For the USB port, proceed slowly and use a file. File the side wall down to the bottom. Create a cutout for the cable to allow a wider bending radius. Once the connector fits, press it firmly against the shell to leave marks from the rear pins of the connector. Use a 1 mm drill and drill holes where the marks are. Test fit the USB connector and the 3D printed housing.

3. PCB assembly: Glue the PCB to the display. The top edge of the PCB must align with the top edge of the display. Use the adhesive tape provided by the manufacturer and add additional tape in the center of the board to maintain a small gap between the PCB and the metal frame of the TFT module.

4. Lens installation: The lens can be glued directly into the case. To prevent dust from getting between the lens and the TFT module, I recommend adding tape on the top and bottom edges of the lens. If there is a slight gap, it can also improve the overall appearance. I used a glass lens with a slightly looser fit compared to the plastic lens that came with the case.

5. Display installation: Attach the frame to the module using adhesive tape. Thread the FFC cable of the display through the TFT frame as shown in the picture. This reduces excess cable length and allows for a clean installation. Add two wires for the power supply; they should fit into the slots of the TFT frame. Do not forget to install the USB FPC. You can now add the button membranes, the IR cover, and the power switch slider.

6. Connecting the GBC PCB: The custom FPC allows direct connection to the buttons and the power switch. Use small gauge wire to connect to the board. Since Nintendo used fairly large vias back in the day, you can use them as solder points. Make sure to connect the correct points on the board, as there are different PCB revisions. If in doubt, check the CGB CPU and trace the connections to a suitable via.

7. You can now connect the Game Boy PCB to the display board and screw it in place. As a final step, solder the supply cable to the battery terminals.

Thanks

• Natalie the Nerd
  • Gameboy Color CPU footprint (https://wiki.nataliethenerd.com/gameboy/gameboycolor)
  • Gameboy Color PCB scans (https://wiki.nataliethenerd.com/gameboy/gameboycolor)

Files

Source code and release binaries are hosted on codeberg.org. Please let me know if anything is missing.

• Hardware

  • Open XGB Display
    • Git repository: https://codeberg.org/embedded-ideas/OpenXgbDisplay-HW
    • Releases: https://codeberg.org/embedded-ideas/OpenXgbDisplay-HW/releases
  • Debug adapter
    • Git repository: https://codeberg.org/embedded-ideas/PiPicoFfcDebugAdapter-HW
    • Releases: https://codeberg.org/embedded-ideas/PiPicoFfcDebugAdapter-HW/releases

• Software

  • Git repository: https://codeberg.org/embedded-ideas/OpenXgbDisplay-SW
  • Releases: https://codeberg.org/embedded-ideas/OpenXgbDisplay-SW/releases

TL;DR

• Development board for Game Boy Color and Game Boy Advance display mods (RGB TFT replacement system)
• Modular hardware platform with support for multiple configurations
• Flexible integration via FPC/FFC adapters for different console layouts
• Based on RP2350B or RP2354B
• Optional USB video output via additional CH32V305 coprocessor (UVC support)
• Fully open source hardware and software
• All design files and firmware available in the repository

Introduction

If you have been following the blog, you might be familiar with my previous projects, the Open DMG Display and the Open AGB Display, and maybe also with the recently added USB video output on the Open DMG Display.

I also did a proof-of-concept for video output on the Game Boy Advance, but I didn’t implement this into a working mod.

This project brings all of that together. However, instead of another device-specific mod, I wanted to focus on a generic board with reusable code as a blueprint for MCU-based display mods. It can be seen as an invitation for the community to build upon.

Maybe you would like to design a Game Boy Color with a huge display, but you’re not familiar with writing firmware or drivers for TFT displays. Or perhaps you are strong in software but don’t want to design the circuitry from scratch. This is where the xGB Display helps you jump-start your project.

It offers:

• A generic board that can be used in multiple different projects
• Two example implementations using the board (CGB and AGB)
• Support for different displays
• Tested components and schematics

What to Expect – and What Not To

I hope this project finds its target audience and continues to mature over time. It is by no means a finished product. I expect bugs in both the software and the hardware, and you should as well when using the provided materials.

All data and materials are provided “as is”. If you have questions, I’m happy to help when I have the time, however, support is not guaranteed, and responses may be delayed. If you encounter any problems, I would appreciate it if you report them so the project can continue to improve. If you are able to fix an issue yourself, contributions are very welcome!

Disclaimer: Use of the provided information, files, and build instructions is entirely at your own risk. No guarantee is given regarding accuracy, completeness, or functionality. Any liability for damage to hardware or software, consequential damages, or other claims arising from use is excluded.

The Firmware

The firmware is based on the Open AGB Display. It has the same set of features. The relevant changes are:

• Dynamic configuration capabilities for Game Boy Color and Game Boy Advance signals
• Support for multiple TFT modules (see Hardware section for details)
• A new module that sends frame data via serial output to the USB video output coprocessor

In addition to the main firmware, there is also code running on the CH32V305 coprocessor for video output via USB.

Configuration

In order to allow the same firmware to run in different modes on different target hardware, it is crucial to provide configuration information about the underlying hardware and the connected peripherals. This is done using information blocks stored at the end of the flash memory. There are two blocks that are mandatory for running the firmware:

• The HIB (Hardware Information Block), which holds information about the hardware the firmware is running on
  • Hardware revision
• The PIB (Product Information Block), which holds information about the configuration of the hardware
  • Connected peripherals
  • Product revision

Currently, only a minimal amount of information is stored in these blocks. To allow for more information in the future, each block includes a version field. The blocks can be created using a Python script, which you will find in the firmware repository in the scripts subfolder. The firmware will restart into the bootloader if no valid information blocks are found!

Signals and Timings

Capturing the Game Boy signals is done very similarly to how it is implemented in the Open AGB Display. That post already describes the details. The most important takeaway is that the frame timing is driven by the Game Boy’s signal, which allows for low latency in combination with the RGB interface on the recommended TFT displays.

The Hardware

I designed a very small and fairly dense board for this project. It can be used to implement a mod directly or as a basis for designing your own board using the provided design files.

I also designed two types of demo implementations using this board: one for the Game Boy Advance and one for the Game Boy Color. Besides the board itself, you’ll also need an FPC adapter cable to connect it to the original Game Boy hardware. Examples of these FPC designs are also provided in the repository.

If you wish to utilize the coprocessor for USB video output, you’ll also need an FPC or FFC connection for the USB port. Again, example designs are provided and are intended to fit the demo mods.

The Open xGB Display Board

I will briefly describe some aspects of the Open xGB PCB, which I hope will help you understand what the hardware offers.

1. Misc connections: These are mainly intended for implementing user input via buttons. By default, they are used to navigate the menu. They operate at input levels between 0V and 3.3V, where a low level means pressed and a high level means released. They can be directly connected to the Game Boy’s input buttons. The default mapping is: 1 for Enter, 2 for Right, and 3 for Left. These connections are also available on the connector to the Game Boy, so it may be more convenient to access them via an FPC.

2. Main MCU (RP2354B): If you are using the RP2354B, which I would recommend, you do not need external flash. If you have reasons to use the RP2350B, there is still a footprint for external flash memory.

3. Generic xGB connector: The 24-pin FFC connector is intended to connect the Game Boy display signals to the OXD board. In addition, it carries the general power-enable signal as well as the three misc connections described in (1).

4. USB video coprocessor: Since the RP235xB only offers a USB FS interface, which is not fast enough for UVC video output, a second microcontroller has been added to the board. It is a small CH32V305 MCU with a USB HS interface. The controller is connected via a serial link that uses two SPI interfaces connected together. It is implemented as a fully independent circuit powered by USB, so it does not consume power unless it is in use. Unfortunately, it does not allow bootloader access, so it must be flashed via a debug probe (which is relatively inexpensive, though).

5. USB and debug connection to the RP235xB: The 10-pin FFC connector is intended for use with the debug adapter. It provides access to the SWD interface as well as USB for the RP235xB.

6. TFT connector: The 40-pin FFC connector is intended to connect a TFT module. The pinout supports a range of displays from buydisplay.com (see TFTs). If you are using a display with a different pinout or connector, it should not be difficult to reroute this part of the board.

7. Power supplies: There are two SMPS power supplies for the main circuit (they do not power the coprocessor). One supplies 3.3V for the RP235xB and peripherals. The other is used exclusively for the backlight. The supplies are chosen to operate within the range of two rechargeable AA cells but can also be powered from a 5V supply if required. The backlight supply is a current source regulated via a PWM DAC. This helps prevent flicker caused by on/off cycles. You will also find JP1 in this area. If bridged, the enable line will be tied to the battery, so the device will start directly when power is applied.

8. Supply terminals: Solder pads for connecting the supply voltage (typically a ~3V battery). In addition to power, you also need to provide a voltage above ~0.7V to the enable line in order to start the OXD. If you do not want to use the enable line, bridge JP1 (see 7).

Firmware Flashing and Debug Adapter

In order to get any firmware onto the Open xGB Display board, you’ll need some kind of adapter to connect to the 10-pin FFC connectors. This is also true if you want to do any debugging during development. You could either use a 10-pin FFC-to-pin-header adapter or the debug adapter I created for the Open AGB Display. I will explain the process using this adapter in the following section.

The debug adapter uses a 10-pin same-side FFC cable to connect to the debug connectors on the OXD board. It provides a JST-SH (1.0 mm pitch) 3-pin connector that is compatible with the Raspberry Pi Pico Debug Probe. It also offers a USB-C port to access USB during development. There is a possibility to power the target from this USB-C port by bridging JP1 and/or JP2, but you have to be careful with this feature. The 5V supply will be directly connected to the supply terminals. If those terminals are connected to the Game Boy, you will supply it with 5V, which might destroy your hardware.

Flashing the RP235xB: There are two ways to get the firmware onto the RP235xB. The easiest way is to plug the device into a computer via USB and boot into bootloader mode by holding SW1 during power-up. The device will show up as a mass storage device. You can then simply copy the provided UF2 file. Don’t forget to provide the information block data along with the firmware. You only need to do this once.

If you have a suitable debug adapter at hand and want to compile the code yourself, you can also flash the firmware using SWD.

Flashing the CH32V305: There is currently only one way to get firmware onto the CH32V305: you must connect a debugger to the chip. I recommend using a WCH-Link and connecting it via a JST-to-pin-header adapter to the debug board. If you bought a Pico Debug Probe, you will already have such an adapter.

With the CH32V305, you’ll need to connect JP1 and/or JP2 on the debug adapter board in order to power the chip via a connected USB cable. As the WCH-Link uses pin headers and also provides 5V, wiring it up to an FFC adapter is also a good option.

Within the release files you will find a hex file with the firmware. This can be flashed using the wlink software with the following command:

wlink flash [PATH TO RELEASE FILES]/xgb2usb.hex

TFTs

The project currently exclusively uses TFT modules with a parallel RGB interface. This brings some advantages:

• A bufferless interface, which reduces latency
• Full control over frame timing
• The ability to let the input signal drive frame timing
• Prevention of tearing

In order to support as many displays out of the box as possible, I decided to use displays from buydisplay.com (not sponsored). They provide a wide range of displays with RGB interfaces and a consistent pinout.

• Implemented

  • ER-TFT028A5-4: 2.80", 1500:1, 480x640, 800 cd/m², 30 mA, 9.00V
  • ER-TFT040-3: 4.00", 800:1, 480x480, 400 cd/m², 30 mA, 15.00V
  • ER-TFT034-2: 3.40", 800:1, 480x480, 550 cd/m², 30 mA, 18.00V
  • ER-TFT3.95-1: 3.95", 800:1, 720x720, 350 cd/m², 30 mA, 15.00V
    • Signal timings need to be optimized, limited support

• Pin compatible

  • ER-TFT3.54-1: 3.54", 1000:1, 640x960, 450 cd/m², 30 mA, 15.00V

• Pin compatible but requires backlight supply changes

  • ER-TFT3.53-1: 3.53", 1000:1, 480x800, 400 cd/m², 15 mA, 21.00V
    • Backlight current must be set via a different resistor
  • ER-TFT020-6: 2.00", 1000:1, 480x360, 800 cd/m², 90 mA, 3.00V
    • Low backlight voltage, requires a different backlight supply
  • ER-TFT024-5: 2.40", 1000:1, 480x640, 350 cd/m², 60 mA, 3.00V
    • Low backlight voltage, requires a different backlight supply
  • ER-TFT021-1: 2.10", 700:1, 480x480, 300 cd/m², 60 mA, 3.20V
    • Low backlight voltage, requires a different backlight supply (round display)

When choosing a display, the most important criteria are size and resolution. Most of the currently supported TFTs have a 480-pixel width, which allows integer scaling for both CGB (160×144) and AGB (240×160). This is especially useful for allowing DMG and CGB games on the Game Boy Advance to be stretched to full width.

How to Use

In order to provide a better understanding of how this project can be used, I built two mods based on the OXD PCB: one for the Game Boy Advance and one for the Game Boy Color. I won’t go into great detail here because the Game Boy Advance variant is essentially a refinement of the Open AGB Display, and I will write another more detailed post about how to build the Game Boy Color version. I will therefore only describe what is required to build something useful with the OXD board.

Game Boy Connection FPC Examples

In order to connect the board to a Game Boy Color or Game Boy Advance, you’ll need to connect the display signals to the 24-pin FFC connector. You could do this using off-the-shelf FFC or FPC cables, which are no longer very expensive. Remember that the misc signals used for the control buttons are also available on the FFC connector, as well as the enable line. It therefore makes sense to include these in an FPC design as well.

On the left is the connection FPC for the Game Boy Color with its 50-pin display connector. On the right is the 32-pin Game Boy Advance variant. You can see that both cables expose the misc and enable pins via solder pads. This has proven to work quite well if you use thin wires for the connections to the Game Boy PCBs.

For my mods, I connected left, right, and select for the Game Boy Color, and left shoulder, right shoulder, and select for the Game Boy Advance to the misc connection pads. The enable line is connected to the power switch.

USB FPC Examples

For the USB connection to the CH32V305, which can be used for video streaming, I also designed FPCs. I used USB-C connectors and additional 5.1 kΩ resistors to enable proper 5V negotiation when connected.

Both designs include additional pads to connect to the 5V line provided by USB. This can be useful, for example, for connecting a battery charger.

3D Prints

In order to fit everything into original or aftermarket cases, I had to design some 3D-printed parts. These mainly include a frame to hold the TFT module and the board, as well as covers for the USB ports. I also found it useful to design templates for cutouts and display alignment.

Game Boy Advance

For the Game Boy Advance, I used the same display module as in the Open AGB Display (ER-TFT034-2). This time, I added an additional frame to provide better side support and to align the OXD board. The case cutouts and custom lens are the same as in the Open AGB Display. On the top, there is a cutout for the USB-C connector.

Game Boy Color

I think the Game Boy Color mod turned out really nicely, and I haven’t previously written a post covering it. As mentioned, I will cover the mod in more detail in a separate post. I will link it here as soon as it is published.

Please have a look at his post: CCGB

Known Issues

• The placement of the USB port on the AGB mod is not ideal because the connector can apply stress to the TFT module.
• In AGB mode, the video output occasionally shows a shifted line, resulting in a one-frame glitch. This may be due to a software issue or a limitation of the serial transfer or board signal integrity, and requires further investigation.

Files

Source code and release binaries are hosted on codeberg.org. Please let me know if anything is missing.

• Hardware

  • Open XGB Display
    • Git repository: https://codeberg.org/embedded-ideas/OpenXgbDisplay-HW
    • Releases: https://codeberg.org/embedded-ideas/OpenXgbDisplay-HW/releases
  • Debug adapter
    • Git repository: https://codeberg.org/embedded-ideas/PiPicoFfcDebugAdapter-HW
    • Releases: https://codeberg.org/embedded-ideas/PiPicoFfcDebugAdapter-HW/releases

• Software

  • Git repository: https://codeberg.org/embedded-ideas/OpenXgbDisplay-SW
  • Releases: https://codeberg.org/embedded-ideas/OpenXgbDisplay-SW/releases

• Joystick made from PCB and strain gauges
• Files below

Introduction

There are many ways to build a two-dimensional control device. In the early days, digital joysticks were common. They provided only left/right/up/down inputs, with diagonal movement represented as a combination of two directions. Today, most devices are analog and based on potentiometers or Hall sensors. Touchpads are also widely used and typically operate capacitively.

In some notebooks, however, you will find another class of control device. These often look like small rubber caps, famously a red rubber dot. Such devices measure bending forces. Some implementations work capacitively, but resistive measurement is more common today.

Using a very similar technique, it is possible to build a comparable device from standard FR-4 PCB material. The Strainstick is one such device. The design was inspired by the haptic knob project from scottbez1. It is intended to be used as part of one of my other projects, but I thought it was interesting enough to publish a short post about it.

Hardware

The Strainstick uses a 2-layer PCB and is equipped with four very common BF350 strain gauges. To keep things simple, the design uses an ADC with an integrated reference and PGA, the HX717 from AVIA Semiconductors. This chip is very similar to the more famous HX711, but offers higher bandwidth and requires fewer external components while still providing an integrated reference voltage.

The HX717 is a two-channel device, but only one channel is used. Switching between the A and B channels takes approximately four cycles, which would significantly reduce the available bandwidth. Therefore, two chips are used.

Each axis uses one set of strain gauges. This allows a better signal to be obtained (the bending forces compress one gauge and stretch the other) and thermally couples the resulting half-bridge.

I am aware that, instead of strain gauges, it is possible to use SMD resistors. I like the idea, but I wanted a more well-defined device. I would expect differences between manufacturers and possibly reliability issues in the long run. This might be something to test in the future.

Attaching the strain gauges

The process of strain gauge attachment isn’t very complicated. You will need:

• Isopropyl alcohol (for cleaning)
• Adhesive tape
• Tweezers
• Scissors or an X-Acto knife
• A cyanoacrylate-based glue (super glue)

First, clean the board with IPA. Apply adhesive tape to the areas close to the strain gauges where components need to be attached on the board.

Next, cover the gluing areas with tape in a cross-shaped pattern. Make sure the center of the first tape does not overlap the gluing areas on its sides.

Now, lift the tape from the edges of the board and slide one strain gauge underneath it using tweezers. Ensure it is correctly aligned and fits within the gluing area. Also, make sure the solder pads are on the correct side. Repeat this for the other gauges and perform a final check to ensure everything is positioned correctly.

It’s now time to glue the gauges in place. Lift the tape with the attached gauge one at a time and apply a thin layer of super glue to the gluing area. Lower the tape and press the gauge onto the PCB with your thumb. Hold it in place for about 30 seconds, then proceed to the next gauge.

Depending on the glue and the amount used, you can proceed directly to removing the tape, starting with the first gauge you glued down.

When removing the tape, pull it to the side rather than lifting it straight up.

You are now left with attached strain gauges. Use some wire to connect the gauges to the PCB. Be careful with heat on the gauges, as they can be somewhat sensitive.

Finally, clean the board with IPA. Even after cleaning, you may find some residue from the adhesive tape or super glue on the uncovered areas, but the rest of the board should be clean and ready for assembly.

Assembly

The assembly is a straightforward process. There are no particularly complicated components on the board, but I would recommend using some form of magnification. An interactive BOM is included in the released files. As always, I recommend using lead-free solder.

I may create a future version of the board that allows the strain gauges to be mounted on the back of the PCB. This would enable the use of a stencil. For now, however, the board must be soldered by hand.

Software

I created a demo for the device that allows it to act as a mouse. The demo is currently only available as a binary. I plan to publish the source code alongside the mentioned project in the future. If you really want to tinker with the code, feel free to send me an email.

There is an Arduino library for the HX711 which, I believe, should also work for the HX717. This might be a better option if you want to experiment with the device.

The demo runs on the CH32V203 demo board from WCH. You have to connect the Strainstick as follows:

• Pin 1 –> 5V
• Pin 2 –> PA2
• Pin 3 –> PA3
• Pin 4 –> PA8
• Pin 5 –> GND

You can flash the software using the integrated Bootloader and WCHISP. Set BOOT0 to high and reboot the board.

Thanks

• Thank scottbez1 for the general idea of strain gauges on PCBs

Project files

• KiCAD Files
• Gerbers
• Test firmware for CH32V203
• Interactive BOM
• 3D printed rod

TL;DR

• See pictures ;)
• Files below

Introduction

I already did a take on designing SMD parts containers for SMD tapes. Recently, I came across the problem of storing smaller gauge wires. I thought it would be nice to store them in the same kind of containers I use for my SMD storage. What bothered me about my last design was the amount of time it took to assemble the containers with a rail, and also that the rails themselves are inconvenient to store. So I had the idea of making the containers connect to each other, which also eliminates the need to print a cover for each one. I started experimenting with the dovetail approach I used for my SMD storage tray.

After a few iterations, I was quite happy with the results. I ended up designing an SMD parts container that still works like the ones from, for example, Robin Reiter, but is easier to print and can be stacked. I also designed a matching storage container for wires. To make handling a bit easier, I created an angled stand and hooks for IKEA Skådis boards, which can be directly attached to the connected containers.

Features

• Only one non-printable part: a single spring per container
• Only one cover per stack (reduces parts and print time)
• Label area for writing or printed labels
• Fully customizable using the OpenSCAD customizer
• Wire container with a rewind mechanism

Printing and Assembly

The default container size is 60 mm inner diameter, with a width of 8 mm for the SMD containers and 9 mm for the wire containers. You can easily customize these dimensions using the OpenSCAD customizer. I provide STL files for the 60 mm containers with the default widths, along with all matching parts, including the stands and hooks for IKEA Skådis. The rest is up to you.

For easier printing, I also added full container sets that include all required parts for one container (except the label inlay).

• Additional parts: One 0.3 mm wire spring (4 mm outer diameter, 20 mm length) per container
• Layer height: 0.2 mm
• Nozzle: 0.4 mm
• Smooth print bed
• PLA or PLA+ recommended

Wire container assembly

First, screw both parts of the spool together. Set the slider to the lowest position. Insert the spring and push the slider upward. You can compress the spring with a flathead screwdriver to make this easier.

Next, place the gear into its slot and press it down until it clicks into place. Insert the spool with the gear side facing up. The wire should be routed as shown in the picture.

If you want to use a label, simply bend the label insert and slide it into the corresponding slots on top of the container.

SMD container assembly

The SMD container assembly is very similar. Just make sure the slider is inserted all the way at the bottom.

Thanks

• Robin Reiter and Lord Asdi for the idea of the tape holding mechanism
• Dr. Jörg Janssen for the gears OpenSCAD library
• Ryan A. Colyer for the threads OpenSCAD library

Project files

DOWNLOAD: STL and source files

TL;DR

• The Open DMG Display firmware now supports video output via USB Video Class (UVC).
• Utilizes an MJPEG approach adapted from the GB Interceptor.
• New firmware available at link.

Introduction

It has been a while since I published the Open DMG Display. Since then, I’ve tinkered with the display signals of the entire Game Boy lineup, which resulted in an open display for the Game Boy Advance. I don’t know who it was, but someone asked whether it would be possible to add capturing to this device, and that got me thinking about an implementation.

I remembered the talk by Sebastian Staacks at 37C3 about his GB Interceptor. I came to the conclusion that it wouldn’t be worth trying to implement this directly on the RP2350 (especially after asking Sebastian whether he thought it was possible). So I moved on to experimenting with an ESP32P4, which worked well. Since I also wanted to get familiar with the TinyUSB library, I tried getting capturing to run on a cheap CH32V305, which also worked.

What I totally overlooked was that the GB Interceptor approach could be adapted to the Open DMG Display, something I’m hereby catching up on.

Implementation

Until now, the Open DMG Display only used one of the RP2350’s cores, leaving the other free for USB video. The implementation relies heavily on the TinyUSB library for the core USB functionality, while the rest adapts the MJPEG approach from the GB Interceptor.

RAW frames are captured using the existing code. Once a frame is complete, it’s copied into a separate memory region for further processing, which ties USB output to the Game Boy’s frame timing. In 30 FPS mode, every second frame is skipped. Lookup tables convert the 2-bit-per-pixel raw data into 3-bit-per-pixel data as a preliminary step before JPEG encoding.

Unlike Sebastian Staacks’ approach, no PIOs are used, the dedicated core has enough resources to handle everything in software, including JPEG generation via lookup tables.

The adapted method from Sebastian and Ikadzuchi reduces JPEG quantization to the lowest frequencies, keeping mostly luminance. Huffman tables and other parameters are tuned to efficiently encode 3bpp grayscale images using 5 bits per pixel plus JPEG overhead, which includes unused chroma. This allows 30 FPS over a 12 Mbit USB link.

For 60 FPS mode, chroma is skipped entirely, transferring only luminance. This can cause compatibility issues with some software.

For a deeper dive, check out Sebastian’s talk.

Usage

The USB video output is disabled by default. To use it, you need to enable it in the menu. Look for “USB Video Mode” and choose between:

• OFF
  • The system will not initialize the USB port, and the second core will remain inactive.
• 30fps
  • This mode produces approximately 29.85 FPS. Every second frame is skipped to keep the data rate well below 12 Mbit.
• 60fps
  • This mode may have compatibility issues. It has been tested with QV4L2 and OBS, only OBS handled the signal correctly.

After selecting a mode, restart the device. It should now be detected like a webcam or a USB microscope.

Thanks

• Sebastian Staacks for his talk at the 37C3 and the GB Interceptor code (especially the Python scripts)
  • https://media.ccc.de/v/37c3-11928-reconstructing_game_footage_from_a_game_boy_s_memory_bus
  • https://github.com/Staacks/gbinterceptor/tree/main/firmware/jpeg
• Ikadzuchi for suggesting a method on how to efficiently use MJPEG for greyscale images
  • https://github.com/Staacks/gbinterceptor/issues/17
• The whole team from the TinyUSB library for this awesome piece of software
  • https://www.tinyusb.org

Files

• Code: https://codeberg.org/embedded-ideas/OpenDmgDisplay-SW/
• Binaries: https://codeberg.org/embedded-ideas/OpenDmgDisplay-SW/releases

TL;DR

• Research project
• Shows how to capture Gameboy Advance and potentially Gameboy Color display signals using a CH32V305RBT6
• Uses TinyUSB library to output the signals via USB (USB Video Class)
• Code and binaries: https://codeberg.org/embedded-ideas/xgb2usb/

Introduction

This project is a proof-of-concept for capturing and outputting display signals from the 2nd and 3rd generation Game Boys using a low-cost, general-purpose microcontroller. It describes how to use a CH32V305 MCU, without any specialized peripherals (other than USB 2.0 HS), to capture the Gameboy Advance’s RGB565 display signals at approximately 60 Hz and full resolution, and stream them over USB using the UVC protocol in YUY2 format, all without any additional circuitry, allowing to build a recording/capturing device for the GBA. The code should also work for the Game Boy Color, as the signals are quite similar. There is only a difference in the resolution.

I’ll walk through my thought process and the ideas that led to my solution.

Motivation

Capturing parallel display signals isn’t very complicated when using popular microcontrollers with a wide range of fast parallel peripherals, such as the PIO on the Raspberry Pi Pico or the PARLIO on the ESP32-P4. Traditional interfaces like external memory controllers or camera interfaces can also be used to capture this data.

But what if you want to do the capturing on a very basic microcontroller? I wanted to test whether this would work using a general-purpose controller. I had a WCH CH32V203 lying around, so I decided to start with that. Due to my recent projects, I used the familiar signal from my Game Boy Advance.

Project Execution & Problem Solving

I had the following plan: I wanted to trigger on the VSYNC (start-of-frame) signal using an external interrupt. After this, another external signal interrupt from the pixel clock would trigger a DMA transfer, which moves the contents of a GPIO port input register containing 16 pin states into memory. Not a bad plan, but I was surprised to discover that it isn’t possible to trigger DMA transfers directly from external signals.

A deeper look into the DMA peripheral led me to the capture mode of the timer peripherals. This mode allows an external signal to trigger a DMA channel. Normally, it is intended to transfer the counter register, but there is nothing stopping you from using a GPIO port input register as the source address. And it actually worked.

With this setup, capturing the data became possible, but it was essentially useless because the frame data couldn’t be stored anywhere. A whole frame, 240 by 160 pixels with 2 bytes per pixel, would require 75 KiB of RAM, while the controller only had 20 KiB.

Great! A Frankenstein-like peripheral driver made from a timer, DMA, and basic GPIO, glued together with a few lines of code. Luckily, I also wanted to explore the TinyUSB library’s video capabilities and came across the CH32V305RBT6, which is essentially a CH32V203 with 50 percent more RAM and, most importantly, a high-speed USB port.

TinyUSB includes an implementation for UVC, or USB Video Class, normally used for webcams, and it was used in the Gameboy Interceptor, a Classic Gameboy (DMG-01) capture device by Sebastian Staaks (https://github.com/Staacks/gbinterceptor). It uses the full-speed USB port of a Pi Pico. However, for the higher resolution and color depth of the Gameboy Advance, a full-speed interface isn’t fast enough. This made the CH32V305 an excellent candidate, especially at a price of 1.50 USD per unit for 10 pieces. Still, there isn’t enough RAM to store a full frame, and TinyUSB only supports transferring complete frames.

After spending some time with the TinyUSB code, I managed to modify the video class driver to support “on-the-fly” data streaming without a frame buffer. I first experimented with generated data and then integrated my capture driver from the CH32V203. I modified it to provide a ring buffer that stores data line by line along with the line index. This allowed the USB video class code to synchronize on the first frame. After that, it retrieves data as quickly as possible. If it is too fast, it waits until new line data is received. With a ring buffer of about 50 lines, this worked quite well.

You can find my changes to the tinyUSB library here: https://github.com/embedded-ideas/tinyusb. I made a pull request so it might end-up in the mainline repo (update: it did).

Unfortunately, this was not the end of the challenge. The captured data was RGB565, but the supported video formats were only MJPEG, which we cannot calculate fast enough, and YUV2. YUV2 still requires calculations beyond the CPU’s capabilities. At this point, it was useful that the AGB doesn’t fully use RGB565: the lowest green bit is tied to ground. This means we are effectively dealing with RGB555, or 15-bit data.

This allowed an easy solution: a lookup table. By storing 8-bit YUV values for each possible color, we require 96 KiB, which can be stored in flash memory.

And voilà, it works.

Code

The code is separated into two parts. There is the capture driver (xgb_capture.c) which provides the captured data either as YUV2 or RGB565 data and the code that takes care of the tinyUSB interface (stored in main.c). The other files are taken from the video capture example of the tinyUSB library. They provide the right configuration and the USB descriptors.

You can find the code on codeberg.org: https://codeberg.org/embedded-ideas/xgb2usb/

Build (Linux)

First you have to prepare the toolchain. Download and extract the archive and add the path to the bin directory to your PATH variable.

https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/download/v15.2.0-1/xpack-riscv-none-elf-gcc-15.2.0-1-linux-x64.tar.gz

Clone and build the project

git clone --recurse-submodules https://codeberg.org/embedded-ideas/xgb2usb.git
cd xgb2usb/tinyusb/tools/
python get_deps.py ch32v30x
cd ../..
mkdir build
cd build
cmake ..
make

Flash the binary to the MCU

The CH32V305 comes with a bootloader. Normally a development board should have a button labeled boot. You have to hold this button while pressing reset or plugin in the device. The MCU should start in bootloader mode which allows us to flash software via the USB. There is a nice tool for this: https://github.com/ch32-rs/wchisp/releases/tag/v0.3.0

Make sure you added the path to the executable to your PATH variable and run:

wchisp flash xgb2usb.hex

Testing

There are several options to test if the device works. You might consider OBS, QV4L2 or an Android app like “USB Camera”

Hardware

The code should work fine with every evaluation board which uses a CH32V305RBT6 and an external 8MHz crystal. I used the nanoCH32V305 board which isn’t ideal because two of the used inputs are only available via the second USB port data lines, hence I had to use an additional adapter board for A11/12 (see pictures).

Connections

Thanks

• TinyUSB Library for this awesome project
  • https://github.com/hathach/tinyusb
• xPack Binary Development Tools for providing a nice way to get an alternative toolchain
  • https://github.com/xpack-dev-tools/
• WCH-ISP for the easy to use flash tool
  • https://github.com/ch32-rs/wchisp/

Files

Sourcecode and release binaries are hosted on codeberg.org

• Sourcecode: https://codeberg.org/embedded-ideas/xgb2usb/
• Binaries: https://codeberg.org/embedded-ideas/xgb2usb/releases

Disclaimer

This project is provided for educational and experimental use only. Use all code, hardware, and instructions at your own risk.

The author assumes no responsibility for damage, data loss, or malfunction resulting from its use. All trademarks (e.g., Game Boy Advance) belong to their respective owners. This project is not affiliated with WCH, Nintendo, or any other company.

TL;DR

• Fully open-source IPS display mod for the Game Boy Advance
• Based on RP2350B for signal capture + rendering
• Requires custom PCB, case cuts, and optional custom lens
• Integer upscaling on 480x480 display resolution (pixel-perfect)
• Effects support (scanlines, color tweaks, pixelation)
• Power efficient: ~10-12h on NiMH at 50% brightness
• Hardware & software files linked below

Introduction

After designing the Open DMG Display, I became curious whether I had missed anything by never owning a Game Boy Advance. At a recent retro fair in my city, I found a good deal on a standard Game Boy Advance and took it home. I was genuinely surprised by how poor the display quality was. Once again, I couldn’t find any affordable open-source option for a display replacement. I found a nice 480×480 IPS module and already had some RP2350B breakout boards lying around, so I decided to run some experiments to see if I could capture the Game Boy Advance image and display it at full framerate with low latency.

Those experiments eventually escalated into this very project.

What to Expect – and What Not To

This is an open project, not a finalized product. All data and materials are provided as is. If you have questions, I’m happy to help when I have the time — however, support is not guaranteed and responses may be delayed. Bugs in the code and potential hardware issues are to be expected. If you encounter any problems, I’d appreciate it if you report them so the project can continue to improve. If you’re able to fix an issue yourself, contributions are very welcome!

Disclaimer: Use of the provided information, files, and build instructions is entirely at your own risk. No guarantee is given regarding accuracy, completeness, or functionality. Any liability for damage to hardware or software, consequential damages, or other claims arising from use is excluded.

Signals and Timings

In order to understand how this project works, it is essential to first understand the signals we receive from the Game Boy Advance and how we process this data. I will begin with a brief introduction to the Game Boy Advance display signals before explaining how we translate these signals for the TFT.

Gameboy Advance Display Signals

If you look at the schematic of the Game Boy Advance, you will see many data lines going to the display. Fortunately, not many of them are relevant for capturing the image data. The most important lines are the DCK, SPL, and SPS lines, along with the 16 data lines (LDRx/LDGx/LDBx).

Regarding the data lines, the Game Boy Advance uses an RGB565 color scheme where the least significant bit of the green channel is tied to ground. This means there is no loss of information if RGB555 is used. In my case, it was easier to use RGB565 to have clean 16-bit data for storage and transport.

The data is transmitted line-by-line from the upper left to the lower right. The start of a frame is indicated by the SPS line, which acts as a vertical synchronization (or start-of-frame) signal. The frame rate directly corresponds to the frequency of this signal.

Between two low pulses on the SPS (VSYNC), there are a total of 161 pulses on the SPL (HSYNC) signal, which translates to 161 lines. If you know why there is an additional line, please contact me. In practice, the last line can be ignored.

Now let’s take a closer look at a single line. It begins with a high pulse on the SPL (HSYNC) line. The DCK (pixel clock) is only active during the transfer of line data. There are 241 clock cycles within a line, which makes one additional pulse or 241 pixels per row. The first pixel can be ignored. For implementation purposes, the pixel data is valid only when SPL is low (meaning that SPL is high during the first clock pulse).

Finally, down at the single-pixel level, the data on the data lines changes on the falling edge of the pixel clock (DCK) and should therefore be latched or captured on the rising edge.

If you want you can download the captures (can be used with Saleae Logic 2): AGB_Signal_Captures.zip

TFT

The TFT uses a non-buffered RGB565 interface, which is quite similar to what I described above. Unfortunately, it differs in ways that prevent us from simply passing the signal through. One major difference is the resolution, meaning we have to handle more data per unit of time. Another difference is in the signal itself. I will not go into detail, but for example, the TFT’s pixel clock must run continuously, whereas the Game Boy signal does not. There are also parameters such as front porches, back porches, and so on.

Therefore, we first buffer part of the frame in the RP2350’s RAM before transferring it to the TFT. More precisely, we capture half of the Game Boy Advance frame before starting the transfer to the display. This approach has two consequences:

• We get a synchronized signal with the same frame rate as the original.
• We introduce a fixed offset to the original signal, also known as latency (or some might call it lag).

Since the display controller has no buffer, the signal almost directly drives the TFT’s line and column drivers. However, the display still has a response time, which is a physical characteristic also present in the original Game Boy Advance screen. I do not have the exact figures for the original, but the panel used in this project has a worst-case response time of around 25 ms for a white-to-black transition, which should be relatively rare in most games.

The latency caused by buffering the signal in the RP2350’s RAM measures around 6.5 ms. This is the time between the moment the last pixel of a Game Boy Advance frame is received and the moment the TFT signal reaches the last active line of the display area used for rendering the Game Boy image. This figure assumes that the 240×160 image is scaled to 480×320 and centered on a 480×480 TFT. In this case, 80 pixels at both the top and bottom of the screen remain unused, so the last line containing content would be line 400.

Signal timings of the Gameboy and the TFT can be downloaded here: agb_tft_timings.sal

Capturing and Rendering

The capture driver (agb_capture.c) uses one of the PIO units to capture the full frame and stores the data into a buffer via a DMA channel. This buffer, therefore, holds 16-bit RGB565 pixel values in a linear fashion, starting from the upper-left pixel and ending at the lower-right pixel. It is able to generate a callback after receiving a specified number of lines. For example, we can configure this callback to trigger after receiving 50% of the lines respectively after capturing half of the frame. We use this callback to trigger the other critical driver responsible for generating the display signal: the TFT driver (tft.c). This driver generates a standard RGB interface signal commonly used in modern TFT display controllers. One advantage of this interface is that it is unbuffered, allowing direct control over timing. We leverage this by using the capture driver’s callback to initiate a new frame sequence in the TFT driver. Once started, the TFT driver automatically requests the pixel data line by line as it renders the frame. The TFT driver uses its own callback to request this data, effectively acting as the link between the capture driver and the TFT driver. This callback is responsible for transfering the captured image to the TFT display.

In the simplest implementation, this rendering function simply passes the pixel data through to the display, resulting in a 240x160 image displayed on the TFT. Since both systems use the same RGB565 format, the pixel data can be used directly. However, to better utilize the 480x480 display, we can upscale the image to 480x320 using simple integer scaling. While basic, this allows the rendered image to fill the full width of the TFT module.

The rendering function also has significant potential for implementing custom effects and additional functionality, which I will describe in the next chapter.

Effects

Each pixel’s color is expressed as a 16-bit color value. We have enough RAM to store lookup tables that allow direct mapping from each color to a different value. For example, we can store a slightly more saturated version of each color, resulting in a more vibrant and colorful image. Alternatively, we can fix the hue to a single color and only modify the saturation and brightness, which would produce a single-color tinted image. If green is used, this would make every Game Boy Advance game look more like a high-resolution DMG version.

Since the TFT resolution is twice that of the source image, we have four pixels available for each source pixel. I used this for another class of effect: introducing a second lookup table intended to store a less bright or less saturated version of the values in the first lookup table. Each of the four pixels is linked to one of the two lookup tables. For example, if the two upper pixels are linked to lookup table one and the lower two to lookup table two, this creates a horizontal scanline effect. If the same pattern is applied to the left and right pixels, it produces vertical scanlines. If only the upper-left pixel of the four-pixel block uses values from lookup table one, it results in a kind of pixelation effect.

The color adjustments are calculated using the HSV model. The values are computed once and stored in the lookup tables. This approach uses significant RAM but enables real-time rendering of the described effects.

Build

Before you start the build, I recommend using an aftermarket shell to keep the original device intact. You should also print the 3D patterns and the display dummy to make your life easier.

• TFT Display Module HD34013C40 3.4" 480x480 with 40-pin RGB interface (https://de.aliexpress.com/item/1005007703060475.html)
• Assembled Open AGB Display PCB
• Pi Pico Debug Adapter for flashing
• 50mm-150mm FFC, 0.5 pos FFC for connecting the programming adapter
• 50mm 32- or 40-pin FFC, 0.5mm pitch
• 3D prints:
  • Cutting patterns
  • Display dummy
  • Link port dummy
  • Bottom spring
• Thin double-sided tape
• Non-conductive foam
• Screen lens without prints to build the custom screen lens (optional)
  • Vinyl film or spray paint

Case modification

Start with the upper half of the shell. Use the provided pattern to cut the walls at the correct spot. File down any high points on the case that prevent the display from sitting flat. You can also use a sharp knife for scraping. During this process, use the display dummy to check the fit and protect the actual display.

If you want to use the full display area for classic games, you’ll need to cut a new screen opening. A 3D-printable pattern is provided for this as well. Use the pattern to cut a groove first, then remove the excess material with a wire cutter. Finally, file down any burrs for a clean finish.

PCB assembly and firmware flashing

You’ll find all information about the required components in the provided BOM. The PCB can be ordered from your preferred supplier. You’ll need to decide whether to place the 32-pin or 40-pin connector for the connection to the AGB PCB. I was only able to test the 32-pin version, so use the 40-pin connector with caution, as it is still untested. A cost-effective method for assembling components onto the PCB is explained in this blog post: Manual Assembly of Modern PCBs Using Low-Cost Tools.

In addition to the main PCB, there is a separate adapter board used for flashing the firmware and/or connecting to the debug interface. You’ll need to assemble this board as well. Connect it to the AGB main board via a 10-pin FFC and power the OpenAGB Display board with an external 3V supply. Alternatively, you can power the Open AGB Display board through the adapter board by bridging the solder jumpers, but be careful not to connect it to the AGB mainboard at the same time.

To flash the firmware, connect the USB-C port of the adapter board to your PC while holding the push button. An external drive should appear in your file system. Copy the provided UF2 file onto this drive. Once the drive disappears, the flashing process is complete.

TFT assembly

First, connect the display to the 40-pin connector on the bottom of the Open AGB Display PCB. Clean the back of the TFT with IPA. Apply double-sided tape to the back of the PCB and remove the protective film. Attach the PCB to the back of the TFT, using the display edges for alignment.

Next, solder the wires to the corresponding pads on the board. Use an appropriate wire gauge for the power connections. To avoid confusion, mark the three input wires, either with a permanent marker (as I did) or by using different wire colors. Then insert the 32- or 40-pin FFC into the upper connector and lower the assembly into the case. Make sure to remove the protective film from the display before installation.

Insert the 3D-printed spring at the bottom of the TFT, and place pieces of non-conductive foam on the back of the display. This will keep the TFT pressed firmly against the shell.

Now move on to soldering the AGB mainboard. Begin by removing the link port from the top of the PCB. Connect the wire from pad 3 on the Open AGB Display to TP2. Since the remaining soldering will be done on the back of the AGB mainboard, this is a good time to tidy up the cables and secure the PCB in place with screws. It is also the right moment to connect the FFC between the Open AGB Display board and the AGB PCB. Next, connect the wire from pad 2 to the left shoulder button, and the wire from pad 1 to the right shoulder button. Finally, connect the supply wires to the power switch.

Custom Lens

If you want to take full advantage of the display size, especially when it comes to classic Game Boy games, you’ll need to use a custom lens for the screen. Fortunately, there are clear glass and plastic lenses available that do not have any printed graphics.

To achieve a cleaner look, it’s a good idea to add a frame that hides the adhesive and the rough edges from the cutouts we previously made.

I tried two methods for creating a frame on the lens. Both use a 3D-printed pattern (included in the project files) to make it easier to mark the transparent area.

Method 1: Spray Paint

For the first attempt, I used spray paint. I cleaned the glass lens and masked off the area that needed to remain transparent. I applied two coats of black spray paint and removed the masking tape while the paint was still slightly wet. If the paint dries completely, it may peel off when removing the tape. I let the lens dry overnight.

Method 2: Vinyl Film

For the second attempt, I used black vinyl film, typically used with vinyl cutters. I first cleaned the glass lens and covered one side with the film. It is important to be very careful during this step to avoid creating bubbles in the area that will remain on the lens.

Next, I used the 3D-printed pattern to mark the area where the film should be removed, and cut along the marked edges with an X-Acto knife. I then carefully removed the rectangular cutout.

To assemble the lens into the case, I used double-sided tape for both methods. It can easily be applied along the edges of the black frame and trimmed to the right shape using the lens itself as a guide.

OSD Menu and Settings

Press the Select button for 2 seconds to change the brigthness level. Use the left and right shoulder buttons to change the value.

If you hold Select for 5 seconds, you will enter the settings menu. In this menu, you can:

• Adjust the color brightness
• Apply a tint to the display using a single color
• Enable visual effects, such as pixelation or scanlines
• View the About section, which shows the current software version
• And maybe more in future software revisions

This allows you to customize the display to your preference and explore the available effects.

Supply and power consumtion

The Open AGB Display is powered directly from the battery and does not rely on the AGB’s internal voltage regulators. The board includes two regulators (in addition to the internal regulator of the RP2350). The first is a SEPIC converter that generates the 3.3V rail, accepting input voltages from 1.8V up to 5.5V. The second is a step-up converter that generates 18V for the backlight, operating from 1.8V to 6V.

Both regulators are connected to the battery through the power switch. Since this switch is usually somewhat aged and subject to wear, a voltage drop across it is to be expected. With the backlight fully enabled, the system draws around 400mA at 2.2V. In my measurements, the power switch introduced a voltage drop of about 0.08V, corresponding to roughly 200mΩ resistance. This could be worth revisiting in future revisions.

The regulators have been tested to start up reliably at 2.1V input at the battery terminals, which aligns with the lower discharge voltage of NiMH cells. To reduce current draw, and therefore losses, you may want to consider Li-Ion AA cells with 1.5V nominal voltage. This also brings the regulators closer to their efficiency sweet spot. However, the original AGB regulators may have been optimized for slightly lower voltages, so the measured system power consumption does not provide a clear picture.

(The power consumtion at the time of release with the system running a GBA game)

In practice, 50% brightness feels like a comfortable setting for indoor play. With modern NiMH cells, you can expect around 10–12 hours of runtime from two fully charged batteries, which, in my opinion, is quite reasonable. There may still be potential for software optimizations to reduce power consumption further, but as long as you’re using the maximum backlight setting, the impact of such tweaks will be limited.

Thanks

• AGB board scans

  • Natalie the Nerd
  • https://github.com/nataliethenerd/boardscans/tree/main/AGB-CPU-10
  • https://github.com/nataliethenerd/boardscans/tree/main/AGB-CPU-01

• Graphics Library for the OSD

  • LVGL Graphics Library
  • https://lvgl.io/

Files

Sourcecode and release binaries are hosted on codeberg.org

• Hardware

  • Open AGB Display
    • GIT-Repository: https://codeberg.org/embedded-ideas/OpenAgbDisplay-HW/
    • Releases: https://codeberg.org/embedded-ideas/OpenAgbDisplay-HW/releases
  • Debug adapter
    • GIT-Repository: https://codeberg.org/embedded-ideas/PiPicoFfcDebugAdapter-HW
    • Releases: https://codeberg.org/embedded-ideas/PiPicoFfcDebugAdapter-HW/releases

• Software

  • GIT-Repository: https://codeberg.org/embedded-ideas/OpenAgbDisplay-SW/
  • Releases: https://codeberg.org/embedded-ideas/OpenAgbDisplay-SW/releases

• Fixed fractional factor upscaling method
• Targeted at real-time frame upscaling
• Combines nearest-neighbor with local interpolation
• Well-suited for pixel-based graphics retro game visuals
• Optimized for resource-constrained embedded systems
• See accompanying images and example code

Introduction

I came across the problem of upscaling retro game image/frame data in real-time. While integer upscaling is trivial, fractional upscaling becomes challenging when working with limited resources (e.g., slow floating-point arithmetic). Additionally, the algorithms commonly used for upscaling photos are not well-suited for low-resolution game content or pixel art.

The following image demonstrates what happens when you upscale a 160×144 image by a factor of 1.5 using standard methods. The nearest neighbour approach preserves the overall appearance but introduces visual artifacts. In contrast, bilinear interpolation smooths the image, resulting in washed-out colors and a blurry look.

There is also a problem when using nearest-neighbor scaling in applications that feature thin lines with high contrast against the background. When these lines move between frames, a flickering effect can occur. I recorded a video to demonstrate this on a real TFT display. The footage was captured at 120 fps and slowed down to 0.25× the original speed. Have a look, for example, at the moving platforms and the background trees.

What I came up with is somewhat of a hybrid approach. First, the scaled original image is overlaid on the target pixel grid. If a pixel from the original image fully covers a target pixel, we simply use that color. If two or four source pixels intersect within a target pixel, we compute the average of their colors.

I’m not sure if this is a known method - so far, I haven’t found any information or a name for it. A fitting description might be something like “nearest neighbour with local bilinear interpolation,” “nearest neighbour with edge averaging,” or “nearest neighbour with edge blurring.” For simplicity, I’ll refer to it as “Edge Smoothing”.

In the following, I will outline an efficient implementation of the proposed method, tailored for resource-constrained systems.

Idea and Implementation

While experimenting with pixel data, I noticed some interesting properties when using scaling factors expressed as fractions $\frac{a}{b}$, especially when $b=2^n$, with $a,n\in \mathbb{N}$.

$\frac{a}{2^n}$ (e.g. factors like 1.5, 1.375, 1.125, 2.75)

• The pixel boundaries will meet at $a$ respectively $b$ when laying the scaled origin pixel grid over the new one. This results in a repeating pattern of $axa$ pixels.

  • This observation is somehow obvious but important for the algorithm
  • A repeating pattern can allow some pre-calculation
  • A repeating pattern can save a lot of memory when doing precalculations

• The area covered by a scaled source pixel on a new pixel will always be a fraction in the form of $\frac{1}{2^x}$ when $b$ has been choosen as $b=2^n$

  • This allows efficent division by using shifing
  • and can be used to efficently calculate an average color of overlapping pixels

I think a visual representation will be helpful:

The grey pixels represents the source pixels scaled with a factor of 1.5 or

The blue pixels represent the unscaled target pixels. The yellow square marks the repeating pattern. This works the same for other factors but get’s a bit messy to show as an example:

With the pattern we are able to precalculate which pixels of the source are relevant for a pixel on the target by just using an offset during runtime. Every $a$ rows respecively cols we are applying the same pattern with a different offset to the source pixels.

Example 1

Let’s say we want to upscale a given source graphic from 160×144 px to 240×216 px.

• The scaling factor is 1.5, or $\frac{3}{2^1}(a=3,n=1)$ respectively $a=3,b=2$.
• We have a $3x3$ repeating pattern.
• As most image data comes in a linear buffer, we will work line by line.
  • We are using zero-based indices.
  • The upper-left pixel is stored at position 0 in a one-dimensional array.
  • Line $y$ starts at offset $\mathrm{width}*y$
  • This concept applies to both the source and the destination.
• The pattern is hardcoded to allow for optimization and to avoid unnecessary calculations.

Setting a pixel in the target array is done using macros (defines) which assign pixel values based on one, two, or four different pixels relative to the current source pixel offset. In this case, we only use equal distributions of the pixels: 100%, 50%/50%, and 25%/25%/25%/25%.

We apply the first row of our pattern to the first three pixels of the target data. Then we add an offset of $b$ to the source pixel $x$-offset and repeat the process until the first line of the target data is complete.

After resetting the $x$-offset, we apply the second row of the pattern to generate our destination data, and then repeat with the third row. By adding an offset of $b$ to the source pixel $y$-offset, we shift the pattern to match the next three lines.

After repeating this for every row in the target array, we end up with our upscaled frame.

The advantage of carefully choosing the denominator as $2^n$ becomes evident in the mix_2 and mix_4 functions: we don’t need any floating-point arithmetic.

#define SRC_PX(x,y) psSrc[y*uiSrcWidth+x]
#define SRC_OFF_X(x) (uiSrcOffsetX + x)
#define SRC_OFF_Y(y) (uiSrcOffsetY + y)

#define DST_SET_1_100(sx, sy) psDst[uiDstPos++] = SRC_PX(SRC_OFF_X(sx), SRC_OFF_Y(sy))
#define DST_SET_2_50_50(sx0, sy0, sx1, sy1) mix_2(&psDst[uiDstPos++], &SRC_PX(SRC_OFF_X(sx0),SRC_OFF_Y(sy0)), &SRC_PX(SRC_OFF_X(sx1),SRC_OFF_Y(sy1)))
#define DST_SET_4_25_25_25_25(sx0, sy0, sx1, sy1, sx2, sy2, sx3, sy3) mix_4(&psDst[uiDstPos++], &SRC_PX(SRC_OFF_X(sx0),SRC_OFF_Y(sy0)), &SRC_PX(SRC_OFF_X(sx1),SRC_OFF_Y(sy1)), &SRC_PX(SRC_OFF_X(sx2),SRC_OFF_Y(sy2)), &SRC_PX(SRC_OFF_X(sx3),SRC_OFF_Y(sy3)))

static inline void mix_2(uint16_t* const puwDst, const uint16_t* const puwSrc0, const uint16_t* const puwSrc1)
{
  *puwDst = (((*puwSrc0) & 0x1F) + ((*puwSrc1) & 0x1F))>>1;
  *puwDst |= (((((*puwSrc0)>>5) & 0x3F) + (((*puwSrc1)>>5) & 0x3F))>>1)<<5;
  *puwDst |= ((((*puwSrc0)>>11) + ((*puwSrc1)>>11))>>1)<<11;
}

static inline void mix_4(uint16_t* const puwDst, const uint16_t* const puwSrc0, const uint16_t* const puwSrc1, const uint16_t* const puwSrc2, const uint16_t* const puwSrc3)
{
  *puwDst = (((*puwSrc0) & 0x1F) + ((*puwSrc1) & 0x1F) + ((*puwSrc2) & 0x1F) + ((*puwSrc3) & 0x1F))>>2;
  *puwDst |= (((((*puwSrc0)>>5) & 0x3F) + (((*puwSrc1)>>5) & 0x3F) + (((*puwSrc2)>>5) & 0x3F) + (((*puwSrc3)>>5) & 0x3F))>>2)<<5;
  *puwDst |= ((((*puwSrc0)>>11) + ((*puwSrc1)>>11) + ((*puwSrc2)>>11) + ((*puwSrc3)>>11))>>2)<<11;
}

void scale_1_5_rgb565(const uint16_t* const psSrc, uint16_t* const psDst, uint uiSrcWidth, uint uiSrcHeight)
{
  // We expect the destination height and width to be a multiple of 3
  // so we have to assure the source width and height is a multiple of 2
  // otherwise we have to add special handling for the last row/column
  assert(uiSrcWidth%2 == 0);
  assert(uiSrcHeight%2 == 0);

  uint uiDstWidth = uiSrcWidth + (uiSrcWidth>>1);
  uint uiDstHeight = uiSrcHeight + (uiSrcHeight>>1);

  uint uiSrcOffsetX = 0;
  uint uiSrcOffsetY = 0;
  uint uiDstPos = 0;
  uint uiWidthDiv = uiDstWidth / 3; // a

  for (uint uiY = 0; uiY < uiDstHeight; uiY+=3)
  {
    // Pattern row 0
    uiSrcOffsetX = 0;
    for (uint uiX = 0; uiX < uiWidthDiv; uiX++)
    {
      DST_SET_1_100( 0,0 ); 
      DST_SET_2_50_50( 0,0 , 1,0 ); 
      DST_SET_1_100( 1,0 );
      uiSrcOffsetX += 2; // 2^n 
    }

    // Pattern row 1
    uiSrcOffsetX = 0;
    for (uint uiX = 0; uiX < uiWidthDiv; uiX++)
    {
      DST_SET_2_50_50( 0,0 , 0,1 );
      DST_SET_4_25_25_25_25( 0,0 , 0,1 , 1,0, 1,1 );
      DST_SET_2_50_50( 1,0 , 1,1 );
      uiSrcOffsetX += 2; // 2^n 
    }
    
    // Pattern row 2
    uiSrcOffsetX = 0;
    for (uint uiX = 0; uiX < uiWidthDiv; uiX++)
    {
      DST_SET_1_100( 0,1 );
      DST_SET_2_50_50( 0,1 , 1,1 );
      DST_SET_1_100( 1,1 );
      uiSrcOffsetX += 2; // 2^n 
    }

    uiSrcOffsetY += 2; // 2^n
  }

}

Example 2

This can be seen more or less as a real-world example. While the first example was used to generate the demo images, this code was used for the demo videos. It includes additional optimizations and is designed to upscale image data in real time (~60 fps), captured from a Game Boy Advance (240×160) running a Game Boy Classic game (160×144). The scaling factor is again 1.5. The code takes into account the offset of the smaller image within the 240×160 display area. Since the TFT driver in this case requests the image line by line, only one line of the image is generated per call.

void tft_line_callback_1_5(uint uiLineCounter, uint16_t* const puwLineBuffer)
{
  uint16_t* auwFrameBuffer = agb_capture_get_framebuffer();
  uint16_t* psSrc;
  uint uiDstPos = 0;
  static uint uiSrcOffsetY = 0;

  if (uiLineCounter < 216)
  {

    psSrc = &auwFrameBuffer[240 * (8 + uiSrcOffsetY) + 40];

    switch (uiLineCounter % 3)
    {
      case 0:
        for (uint uiX = 0; uiX < 240/3; uiX++)
        {
          uint32_t ulSumR0001 = ((uint32_t)(psSrc[0 + 0*240] & 0xF800) + (uint32_t)(psSrc[0 + 1*240] & 0xF800));
          uint32_t ulSumG0001 = ((uint32_t)(psSrc[0 + 0*240] & 0x07E0) + (uint32_t)(psSrc[0 + 1*240] & 0x07E0));
          uint32_t ulSumB0001 = ((uint32_t)(psSrc[0 + 0*240] & 0x001F) + (uint32_t)(psSrc[0 + 1*240] & 0x001F));

          puwLineBuffer[uiDstPos++] = psSrc[0 + 0*240 ];
          puwLineBuffer[uiDstPos++] = ((ulSumR0001>>1)&0xF800) | ((ulSumG0001>>1)&0x07E0) | (ulSumB0001>>1);
          puwLineBuffer[uiDstPos++] = psSrc[1 + 0*240];
          psSrc += 2;
        }
        break;
      case 1:
        for (uint uiX = 0; uiX < 240/3; uiX++)
        {
          uint32_t ulSumR0001 = ((uint32_t)(psSrc[0 + 0*240] & 0xF800) + (uint32_t)(psSrc[0 + 1*240] & 0xF800));
          uint32_t ulSumG0001 = ((uint32_t)(psSrc[0 + 0*240] & 0x07E0) + (uint32_t)(psSrc[0 + 1*240] & 0x07E0));
          uint32_t ulSumB0001 = ((uint32_t)(psSrc[0 + 0*240] & 0x001F) + (uint32_t)(psSrc[0 + 1*240] & 0x001F));

          uint32_t ulSumR1011 = ((uint32_t)(psSrc[1 + 0*240] & 0xF800) + (uint32_t)(psSrc[1 + 1*240] & 0xF800));
          uint32_t ulSumG1011 = ((uint32_t)(psSrc[1 + 0*240] & 0x07E0) + (uint32_t)(psSrc[1 + 1*240] & 0x07E0));
          uint32_t ulSumB1011 = ((uint32_t)(psSrc[1 + 0*240] & 0x001F) + (uint32_t)(psSrc[1 + 1*240] & 0x001F));

          puwLineBuffer[uiDstPos++] = ((ulSumR0001>>1)&0xF800) | ((ulSumG0001>>1)&0x07E0) | (ulSumB0001>>1);
          puwLineBuffer[uiDstPos++] =
              (((ulSumR0001 + ulSumR1011)>>2)&0xF800)
            | (((ulSumG0001 + ulSumG1011)>>2)&0x07E0)
            | ((ulSumB0001 + ulSumB1011)>>2);
          puwLineBuffer[uiDstPos++] = ((ulSumR1011>>1)&0xF800) | ((ulSumG1011>>1)&0x07E0) | (ulSumB1011>>1);
          psSrc += 2;
        }
        break;
      case 2:
        for (uint uiX = 0; uiX < 240/3; uiX++)
        {
          uint32_t ulSumR0111 = ((uint32_t)(psSrc[0 + 1*240] & 0xF800) + (uint32_t)(psSrc[1 + 1*240] & 0xF800));
          uint32_t ulSumG0111 = ((uint32_t)(psSrc[0 + 1*240] & 0x07E0) + (uint32_t)(psSrc[1 + 1*240] & 0x07E0));
          uint32_t ulSumB0111 = ((uint32_t)(psSrc[0 + 1*240] & 0x001F) + (uint32_t)(psSrc[1 + 1*240] & 0x001F));

          puwLineBuffer[uiDstPos++] = psSrc[0 + 1*240];
          puwLineBuffer[uiDstPos++] = ((ulSumR0111>>1)&0xF800) | ((ulSumG0111>>1)&0x07E0) | (ulSumB0111>>1);
          puwLineBuffer[uiDstPos++] = psSrc[1 + 1*240];
          psSrc += 2;
        }
        uiSrcOffsetY += 2;
        break;
    }
  }
  else
  {
    memset(puwLineBuffer, 0x00, sizeof(uint16_t)*480);
    uiSrcOffsetY = 0;
  }
}

TL;DR

• CSV user palettes: NAME,C1,C2,C3,C4 (see my_user_palettes.csv)
• CSV auto palettes: NAME,C1,C2,C3,C4,GAME_ID (see my_auto_palettes.csv)
• Logo image: Best 160x144 PNG (see my_logo.png)
• Upload like firmware via USB bootloader
• Link to the scripts
• Example calls
  • odd_custom_palette.py my_user_palettes.csv my_user_palettes.bin
  • odd_custom_palette.py -id my_auto_palettes.csv my_auto_palettes.bin
  • odd_custom_logo_generator.py my_logo.png my_logo.bin
  • uf2conv.py -c -b 0x10190000 -f RP2XXX_DATA -o my_auto_palettes.uf2 my_auto_palettes.bin
  • uf2conv.py -c -b 0x101B0000 -f RP2XXX_DATA -o my_user_palettes.uf2 my_user_palettes.bin
  • uf2conv.py -c -b 0x101B8000 -f RP2XXX_DATA -o my_logo.uf2 my_logo.bin

Introduction

The Open DMG display (hereafter referred to as ODD) comes with basic palettes and a custom logo, which are both directly compiled into the firmware. One way to modify these is by changing the data within the code and recompiling it. However, not everyone is comfortable with this approach. Therefore, the firmware also supports the use of external palettes and logos. To make it easier to create the required external data, I wrote a few Python scripts, which I will introduce in this blog post.

Palettes

The ODD differentiates between two types of palettes, which are also stored separately. There are user palettes, which are intended to be manually chosen by the user during operation. Additionally, there are automatic palettes, which are automatically chosen when a specific game is detected.

User palettes

The user palettes are simple datasets that consist of a name (using only ASCII characters) and four 24-bit colors. Using the “odd_custom_palette.py” script, you can generate the binary data that the ODD firmware can read. You can choose between two methods to create a table of personally chosen palettes. The straightforward approach is to create a CSV file and edit it with software like LibreOffice Calc.

The second method is to use GBP files. The script will use the filename as the name of the palette. You can obtain GBP files, for example, from emulators. The script is also capable of processing entire directories. You can store multiple GBP files in one directory and let the script combine them. Additionally, you can generate CSV files from a folder containing GBP files. Let’s clarify this with a few examples:

Creating binary data from a CSV file:
odd_custom_palette.py my_user_palettes.csv my_user_palettes.bin

Creating binary data from a folder of GBP and/or CSV files:
odd_custom_palette.py ./my_palettes/ my_user_palettes.bin

Creating a CSV table from a folder of GBP and/or CSV files:
odd_custom_palette.py ./my_palettes/ my_user_palettes.csv

Auto palettes

Auto palettes contain the same data as user palettes but also have an ID field. If the game ID matches the ID field of one of the auto palettes, the ODD firmware will automatically select this palette. The generation process is largely the same, but you must use CSV files only, as GBP files cannot store the ID.

The same script is used to generate the binary data, but with the -id parameter.

Creating binary data from a CSV file
odd_custom_palette.py -id my_auto_palettes.csv my_auto_palettes.bin

Custom logo

Creating a custom logo is simple. You can design it using your favorite image editor. It’s best to start with a 160x144 canvas to get the aspect ratio correct. Save the image as a PNG file. The finished image can then be converted into a format readable by the ODD firmware using the odd_custom_logo_generator.py script.

Converting image to grayscale binary for ODD firmware:
odd_custom_logo_generator.py my_logo.png my_logo.bin

Writing the data to the ODD

After creating the different binaries, you need to upload them to the correct positions in the ODD’s flash memory. The easiest way to achieve this is by using the same mechanism that is used to upload firmware to the device. To do so, we will need UF2 files, which can be processed via the USB bootloader. I have added the uf2conv.py script by Microsoft to the script folder. It can be used as follows:

Conversion of the auto palette data:
uf2conv.py -c -b 0x10190000 -f RP2XXX_DATA -o my_auto_palettes.uf2 my_auto_palettes.bin

Conversion of the user palette data:
uf2conv.py -c -b 0x101B0000 -f RP2XXX_DATA -o my_user_palettes.uf2 my_user_palettes.bin

Conversion of the custom logo data:
uf2conv.py -c -b 0x101B8000 -f RP2XXX_DATA -o my_logo.uf2 my_logo.bin

You can boot the ODD into the UF2 bootloader by pressing the bootloader button during power-on while the device is connected to a PC. Copy the UF2 files to the RP2350 drive. The firmware should automatically detect the new custom data.

Non-volatile data area

The ODD uses a flash memory area to store non-volatile user data. In order to support the upcoming RP2354B chips with integrated 2MB memory the valid total flash memory is limited to 2MB. The first 1.5MB is reserved for the program data. This is followed by 512kB of user data. With respect to the flash and program data offset (0x10180000) The non-volatile memory is organized as follows:

Pre-generated palettes from TheWolfBunny64

When it comes to custom palettes for the Game Boy you will sooner or later find the name TheWolfBunny64. It seems like he started something with his passion for the 4-color limeted handheld. Many people who are publishing their own takes on custom palettes mention him on the demo image or in their comments as a source of inspiration. He recently posted on bsky:

“One reason why I made #GameBoy palettes since 2019: to carry on the Game Boy’s legacy. Truth told, it gets repetive to play games in the same old four shades of green. Hence why I made holiday palettes like these, to make things a bit more festive. And you can find them on itch and Analogue Pocket.”

(https://bsky.app/profile/thewolfbunny64.bsky.social/post/3lkvt2ska2s24)

And I really wanted to add “… and on the ODD” to his last sentence. I had a short chat with him asking for permission for the use of his material and also started following him on bsky (@thewolfbunny64.bsky.social). He really seems passionate about what he is doing and it looks like he invests a lot of time into it. Maybe you should consider thanking him for his hard work.

Thanks Patrick!

In the following you will find the different palette packs downloadable as directly flashable UF2 files. Enjoy!

Palette Packs

American Pop Culture Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: American_Pop_Culture_Pack.uf2

Anime and Manga Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Anime_and_Manga_Pack.uf2

Bandai Namco Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Bandai_Namco_Pack.uf2

Company Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Company_Pack.uf2

Food and Drink Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Food_and_Drink_Pack.uf2

Gaming Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Gaming_Pack.uf2

Holiday Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Holiday_Pack.uf2

Japanese Company Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Japanese_Company_Pack.uf2

J-Pop Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: J-Pop_Pack.uf2

K-Pop Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: K-Pop_Pack.uf2

Legacy Palette Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Legacy_Palette_Pack.uf2

Misc. Palette Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Misc._Palette_Pack.uf2

Nintendo Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Nintendo_Pack.uf2

Sports Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Sports_Pack.uf2

Traditional JPN Colors Pack

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: Traditional_JPN_Colors_Pack.uf2

Full palette set as CSV

Author: Patrick Adams (TheWolfBunny64)
Source: https://thewolfbunny64.itch.io/game-boy-custom-palettes
Download: TheWolfBunny64_All.csv

Can be used to create your own selection from the different sets. Just follow the CSV to BIN conversion paragraph.

More sources for palettes

• https://github.com/davewongillies/openfpga-palettes
• If you know more let me know

Link to the Python Scripts

-> Repository on codeberg.org <-

TL;DR

• Fully open-source (GPL licensed) and open hardware (CC-BY-SA licensed)
• Custom PCB
• All files available (C code, KiCAD and OpenSCAD)
• Based on RP2350B or RP235xB when available
• Features
  • Dimming
  • Palette switching
  • Automatic game detection with palette presets
  • etc.
• Approx. 20 EUR in parts per unit (for quantities of 5 pcs)
• Requires minimal modifications to the case

Introduction

I’ve been thinking about the toys that played an important role during my childhood. Among many others, I had a constant companion that made family reunions bearable: my trusty Game Boy. Unfortunately, I sold my original unit years ago and never used one again. Recently, driven by nostalgia, I bought a model with a broken display on eBay, with the goal of fixing it.

I switched it on, and while there were some lines on the screen, the much bigger issue was that I instantly remembered how poor the LCD was—even back in the day. I did a quick search on how to replace the already broken display with something a bit more modern. While it’s easy to find IPS mods for a DMG, the pricing didn’t seem reasonable.

So, I did the obvious: I started building my own version of such a mod. After spending more money than I would have on any of the available IPS kits, and more time than I originally estimated, I now have exactly what I wanted. To make it easier for others, I’m publishing this project here for anyone who might be interested.

• Features of the Open DMG Display (further called ODD)
  • RP235xB Microcontroller – Affordable, accessible alternative to FPGA solutions.
  • Custom PCB – Minimal case mod needed.
  • 2-Layer PCB – Cost-effective (ENIG recommended).
  • 3.2" TFT Display – Pixel-perfect, used area matches original size.
  • Backlight Control – Flicker-free dimming (no PWM).
  • Multifunction Switch – Replaces contrast wheel; handles UI navigation.
  • Battery Monitoring – LED, battery warning icon, adjustable settings.
  • On-Screen Menu
  • Display Modes - Scanlines and Pixels(experimental)
  • Game Detection – CRC32-based title screen detection via DMA for auto palette selection
  • PCB design supports different displays and fast modification.
  • 3D-Printed Frame for the TFT module
  • Update (03.01.2026): Integrated Super Game Boy inspired color plattes for all 32 supported games
  • Update (03.01.2026): Integrated Game Boy Color inspired color plattes for all 45 supported games

What to Expect – and What Not To

This is an open project, not a finalized product. All data and materials are provided as is. If you have questions, I’m happy to help when I have the time — however, support is not guaranteed and responses may be delayed. Bugs in the code and potential hardware issues are to be expected. If you encounter any problems, I’d appreciate it if you report them so the project can continue to improve. If you’re able to fix an issue yourself, contributions are very welcome!

User interface

The user interface is controlled using the multiswitch, which replaces the contrast wheel of the original LCD board. It can be moved up, moved down, and pressed. There are three different modes:

• Brightness Adjustment Mode
  This is the default mode and allows you to set the display brightness. Simply move the wheel up or down to adjust the brightness level.
• Palette Selection Mode
  To enter this mode, press the multiswitch briefly. Use the up and down movements to switch between different palettes.
• Menu Mode
  To access the menu, press and hold the multiswitch (long press). The menu provides access to more advanced features, which will be explained in the following sections.

Menu

• BATT LED DEFAULT
  • ON: The LED will be on when the battery is good
  • OFF: The LED will be off when the battery is good
• BATT LED MODE
  • OFF: LED will always be off
  • INVERT: Invert the state of the LED when the battery is empty (depending on the BATT LED DEFAULT setting)
  • PULSE: The LED will start pulsing when empty
  • BLINK: The LED will start blinking when empty
• BATT LED LEVEL
  • Battery LED brightness (adjustable in three steps)
• BATT WARN ON TFT
  • Show an empty battery symbol on the screen when the battery gets empty
• BATT TYPE
  • Set battery type dependent thresholds for battery empty detection
• AUTO PALETTE
  • Use automatic game detection and set the palette accordingly
• AUTO PALETTE (changed 03.01.2026)
  • OFF: Disable automatic color palette switching
  • SGB: Use Super Game Boy–inspired palettes when a supported game is detected
  • CGB: Use Game Boy Color–inspired palettes when a supported game is detected
  • USR: Use custom palettes provided by the user (if no custom data is provided, this behaves like OFF)
• DISPLAY MODE (experimental)
  • NORMAL: Use four pixels to display one pixel of the game image
  • LINES: Fill every second line with black (creating a scanline effect)
  • PIXELS: Only use one pixel for the game image and set the rest to black (creating a pixelated look)
• DISPLAY VSYNC
  • GB: Use the driver mode that lets the Game Boy drive the VSYNC (frame timing)
  • SELF: Use the driver mode that creates the frametiming itself
  • WARNING! You currently need to restart the device in order to apply the new setting
• CUSTOM LOGO
  • If ON: Use the custom logo from NV-Memory. If no valid logo was found, use the demo logo.
• SHOW DEBUG INFO
  • Show some data on the screen like battery voltage and the game identifier (see Game detection)
• REBOOT TO BOOTLOADER
  • This will reset the device and start it into the bootloader (same as pressing the USB boot button on startup).

Implementation details

I think some aspects of the ODD might be interesting to know, so I explain them briefly.

Capturing the image data

I wrote a separate blog post about this a while ago. You will find this at https://www.embedded-ideas.de/posts/241209_dmg_display_capture/

Game detection

While searching for suitable color palettes, I came across a repository of palettes for the Super Game Boy. These palettes introduce special 4-color palettes optimized for some of the more popular games. For example, there are custom palettes for Mario games and for Tetris.

The Super Game Boy was able to detect the game and choose the appropriate palette. This was done using the game identification data stored in the game ROM. Unfortunately, the ODD doesn’t have access to any memory, so game detection can only be done using the display data.

I came up with the following solution: The DMA controller of the RP235x allows the generation of a CRC32 checksum through its debugging function block (see dma_sniffer functions). This makes it possible to generate a checksum for each captured frame without using any CPU resources. The checksum is constantly monitored until the logo screen’s checksum is detected for the first time. We then look for a checksum that is neither the logo screen’s nor an empty frame (checksum == 0), and voilà, we have the checksum of the game’s title screen.

I tested this method with each game I have on hand, and it looks like this simple approach works like a charm. The final step is to search for the checksum in a table of palettes and activate the corresponding one.

This approach will work for every game as long as it always has the same title screen.

Update (03.01.2026): Not only does the Super Game Boy have game-optimized palettes, but the Game Boy Color also offers a variety of color palettes for different games. The ODD has these palettes built in. You can choose between Super Game Boy inspired game palettes, Game Boy Color inspired palettes, or a custom, user-defined palette table.

TFT driver and VSYNC handling

The TFT is driven using a parallel RGB interface with 16-bit color (RGB565). This means the signal directly translates to the image on the screen — there’s no frame buffering in RAM like with the more common MCU8080, SPI, or similar interfaces.

Pros and Cons

This setup brings some nice advantages, but also a few challenges.

Let’s start with the downsides: Signal generation on the RP2350 is a bit tricky. So far, I haven’t found a clean or elegant solution for a driver. I’ve implemented one which supports two modes of operation (which I’ll explain below), but honestly, I’m not super happy with it in terms of code readability and maintainability. That said, it’s working quite well in practice.

Another downside is display initialization. With the RGB interface, it took me some time to get the settings just right to avoid artifacts and flickering. I found this article that helped explain some of the strange behavior I was seeing. It was a useful starting point — though I’ll admit, I’m far from an expert in this field.

The Upside: Full Display Control - The real advantage of this approach is that you have complete control over the display timing. As long as you stay within acceptable signal margins, the source (here the Game Boy) can effectively control the frame timing of the target display.

Driver mode 1: Game Boy Synchronized

The goal of this mode is to match the Game Boy’s frame timing as closely as possible, without skipping a single frame.

Here’s how it works:

• The driver is triggered by the capture module after it has captured half of the frame.
• It starts a new frame at that moment, transferring the captured data while the rest of the frame gets captured.
• This introduces a delay of about 6ms, which I think is acceptable — especially when you compare it to the original Game Boy LCD’s refresh behavior.

The Game Boy’s signal isn’t always perfectly consistent. A game can skip clocks to produce visual effects, resulting in frame jitter (longer or shorter frames). Depending on the TFT controller, this can cause flickering.

In my tests, when I stretched the interval between frames to allow for maximum signal jitter from the Game Boy’s signal, I did see flicker — so I had to reduce the interval. This worked fine for the displays I used, but I can’t guarantee it will work for every game. Some titles might push the frame length so far that the TFT driver overflows and skips a frame, resulting in visible flicker. (If you find a game that does this, please let me know!)

Another issue: the Game Boy sometimes has blank periods where no frame data is transmitted. The TFT really doesn’t like that. To compensate, the driver detects timeouts and continues displaying the last valid frame while the GB signal is “asleep.”

Driver mode 2: Constant self-driven

For good measure, I also added a second mode that runs independently of the Game Boy’s timing. This one simply generates frames at a fixed ~60Hz, always showing the most recently captured GB frame.

This approach ignores GB timing completely, so we lose a frame here and there as we’re sampling a ~55 Hz signal at 60 Hz. You guessed it — Nyquist and Shannon don’t approve Sampling Theorem. Still, for most users and most games, this works just fine.

And if you do run into a compatibility issue or timing problem with the first mode, this can be a solid fallback.

Image overlay (Statusbar, Menu)

The menu and other on-screen graphics are implemented as a kind of canvas layered above the actual game image. This canvas uses the lightest (background) and the darkest color of the active palette. It also supports defining areas as either transparent or opaque. The resolution matches the game graphics, ensuring that the interface blends seamlessly with the gameplay. This approach maintains immersion — the additional functionality feels native to the device rather than imposed on top.

I chose this method over using modern graphics libraries like LVGL, etc., as it provides a simpler and more integrated solution. Another benefit is that the canvas can be combined with the game image using basic binary logic operations, making it both lightweight and efficient:

for (ui=0; ui < MAIN_WORDS_PER_LINE; ui++) // Overlay image insertion (for menus etc.)
{
    ((uint32_t*)pucLineData)[ui] &= odd_display_aulOverlayMask[uiLine * MAIN_WORDS_PER_LINE + ui]; // Clear DMG screen where mask is set to 0
    ((uint32_t*)pucLineData)[ui] |= odd_display_aulOverlay[uiLine * MAIN_WORDS_PER_LINE + ui];     // Add overlay image data
}

Design choices

Some parts of the design might seem a bit odd and need some explanation. I will therefore tell a bit about why I chose to do it this way. Maybe you have a better idea — so we can use this text as a basis for discussion ;)

Display selection

It took me quite a while to find a reasonably sized display for this project. The original aspect ratio of the Game Boy isn’t very common these days—especially when you’re aiming for a specific resolution that enables pixel-perfect rendering of the DMG’s 160×144px image.

I initially explored various 2.x" displays that closely matched the physical dimensions of the original LCD. Unfortunately, most of them came with a resolution of 160×128px.

Eventually, I abandoned the idea of a landscape-oriented display and started searching for a portrait-oriented alternative. This approach made the search much easier. I settled on using 3.2" screens, which almost perfectly match the original screen size when mounted vertically. The chosen resolution is 320×480px—ideal for mapping the Game Boy’s 160px width perfectly when using 4 pixels per pixel. As for the vertical resolution, we do end up with 192 unused pixels, but that’s a trade-off I’m willing to accept.

These types of displays aren’t extremely common, but they’re not hard to find either. In the final design, I added support for two different displays. Both use the HIMAX HX8357-A01 chipset and share the same resolution and physical dimensions. However, they differ in backlight technology, TFT type, and connector.

Why go through all this effort?

• Sourcing stability: I believe the display is the most likely component to become difficult to source over time. Supporting two display options increases longevity and flexibility.
• Flexible routing: The two connector variants allowed me to create a PCB layout that can be easily adapted to support other displays in the future.
• Backlight versatility:
  There are two common approaches to LED backlighting:
  • Parallel configuration is simpler and often runs off the logic supply (typically 3.3V), which makes it easy to implement. However, it can lead to uneven illumination.
  • Series configuration eliminates uneven lighting but requires a higher voltage and a more complex boost circuit.

To accommodate both types, the board includes support for both backlight circuits: a step-down and a step-up converter, both capable of dimming without using PWM (to avoid backlight flicker). This means you can adapt the board to future display modules without needing a complete redesign.

Currently the board supports the following physical displays

• JJY3202-05-Z-A

  • 3.2 inch IPS TFT
  • 6 LED backlight (series) ~19.2V
  • 45 pin .3 pitch connector
  • 45.12mm x 67.68mm active area
  • Ecyberspaces via AliExpress (https://de.aliexpress.com/item/32632665396.html)

• TT320LHN10A

  • WARNING! The init code for this display isn’t ready yet. There might be flicker and/or artefacts when using it. I would currently recommend using the JJY3202-05-Z-A.
  • 3.2 inch IPS TFT
  • 6 LED backlight (parallel) ~3.2V
  • 40 pin .5 pitch connector
  • 45.12mm x 67.45mm
  • Sources
    • Spring Trend Limited http://stldisplays.com/ (OEM)
    • Shenzhen Toppop Electronic Co.,Ltd https://toppoplcd.com/productdetails_5252259.html

PCB

I have chosen to use a 2-layer PCB to keep the cost down. If you don’t opt for a special surface finish, you could order 5 boards for around 7 EUR. With ENIG (which I recommend for the button contacts), the cost increases to about 23 EUR for 5 pieces. A 4-layer design would at least double these numbers.

The chosen thickness of 1.6mm is required to provide enough clearance for the multi-purpose switch on the left side. The multi-purpose switch would not have fit with the original 1mm PCB thickness of the genuine display.

USB connector placement

The USB connector is not intended for regular use, nor is it meant to be accessed through a cutout in the case. It is designed solely to provide a way to upload the firmware onto the device after it has been built, functioning like an internal flash programmer. If you really want to, you might be able to add a cutout to the DMG shell and use a cable with a long tip.

1.25mm pitch FFC connector to the gameboy

Flat flex cable connectors with a 1.25mm pitch are not very common these days. You can easily find 0.3mm, 0.5mm, and 1.0mm pitch connectors, but 1.25mm connectors are rarely available at a reasonable price point. Therefore, I’ve added solder pads that allow for directly soldering a 1.25mm pitch FFC onto the board. This method is not intended for mass production and is more time-consuming compared to soldering a simple connector. If you’re willing to invest, you might consider designing a flex PCB optimized for this use case.

In addition to the solder pads, there is also an extra footprint for a 0.5mm pitch connector, which includes all the relevant signals. This is intended for use with a custom flex PCB adapter that I may design in the future. This connector is currently untested.

Assembly

You will need the following parts:

• PCB and stencil (JLCPCB, PCBWay, multi-cb, etc.)
• Components according to BOM (DigiKey, Mouser, LCSC, etc.)
• 1.25mm pitch FFC cable (AliExpress or eBay)
• TFT display (see display selection)
• 4x M2 screws with 5mm length (for the display frame)
• Display frame top and bottom (3D-printed)
• Consider buying an after market Game Boy case in order to not modify your original one (AliExpress, eBay)

PCB assembly

You’ll need some soldering experience, but it’s not as difficult as you might think. I cover the process of assembling the critical components with basic tools in this post: Manual Assembly of Modern PCBs Using Low-Cost Tools.

If you’ve ever wanted to get into micro soldering, this project is a great place to start.

I recommend using the provided interactive BOM during assembly — it really helps streamline the process.

FFC Cable Soldering

In addition to assembling the PCB, you’ll need to solder the FFC cable to the board. This part is a bit messy. As mentioned, getting connectors with the right pitch can be tricky, so we’ll need to improvise.

You’ll need:

• A 1.25 mm pitch FFC cable (100 mm length; shorter may also work)
• Some tape (e.g., Kapton tape)
• A hot air tool
• Patience

Steps:

1. Remove the stiffener from one side of the FFC using hot air (~100 °C).
2. Carefully lift each individual trace with a knife or sharp tweezers. Doing this on a hotplate makes it easier.
   Be careful not to burn yourself and use a safe working temperature.
3. Once all traces are lifted, trim the excess plastic beneath the traces.
4. Bend the traces downward slightly so they apply some pressure against the board.
5. Align the traces with the pads on the board and fix them in place with tape.
6. Solder the traces, and optionally add strain relief with additional tape.

Quick & Dirty Method (Not Recommended)

If you’re looking to speed things up — and don’t mind the smell of burning mystery plastic — you can skip most of the above and align the FFC directly after removing the stiffener.

Warning: This method will probably burn part of the FFC. Proceed at your own risk.

Display frame

The frame is 3D printed. I used a standard layer height of 0.2 mm with a 0.4 mm nozzle. PETG is a good material choice for printing the frame, though a flexible PLA blend could also work well.

The frame is attached to the PCB using four 5 mm M2 screws. If you have appropriately sized self-tapping screws, those can be a suitable alternative.

Flashing the firmware

Connect the ODD to a PC using a USB cable. While holding down the USB BOOT button, apply power to the board. There are two ways to do this:

1. Recommended: Close jumper JP1 to power the ODD via the USB cable.
   Important: If you choose this method, never switch on the Game Boy while the USB cable is attached!
2. Leave JP1 open and power the board via the Game Boy mainboard instead.

Once connected, a virtual drive will appear on your computer. Simply copy the supplied UF2 file onto the drive — and you’re done!

Case preparation and board installation

Next, remove the protective film from the TFT. Carefully lower the board into the case, making sure the speaker is seated correctly. Pay close attention to the routing of the speaker cables. Use the Phillips screws to secure the board in place.

Note: The ODD PCB is slightly thicker (0.6 mm) than the original PCB. As a result, the back shell may not close perfectly. You’ll need to file down some of the board rests on the back shell. Take your time and check the fit frequently. You may also want to use a caliper to measure your progress for accuracy.

Unused circuitry

There are some unused, or DNP (Do Not Populate), components on the board. Here’s an explanation of what to do with them:

• Connector J3
  • Can be used to design a flex PCB as a replacement for the 1.25 mm FFC cable.
  • UNTESTED!
• Op-Amp U4
  • If you’re aiming for the most precise battery measurement in the history of the DMG—or if you want to overclock the ADC—this one’s for you.
• Resistors R22, R23
  • I initially thought the negative rail might need some load. That doesn’t seem to be the case, so I decided not to use them.
• Capacitors C37, C39, C38, C40
  • If you want better compliance, or if you experience noise, you can experiment with these values. They’re intended for decoupling the ODD supply from the Game Boy mainboard.
  • So far, the regulator caps in combination with the larger electrolytic capacitor have worked fine for me.

Thanks

I used several resources that really helped speed things up:

• DMG LCD scans
  • bit9 on chipmusic.org
  • https://chipmusic.org/forums/post/215957/#p215957
• Schematics
  • Gekkio on github
  • https://github.com/Gekkio/gb-schematics/blob/main/DMG-LCD-06/schematic/DMG-LCD-06.pdf
• Color Palettes
  • TheWolfBunny64 (https://thewolfbunny64.itch.io/game-boy-custom-palettes)
  • AdvancedFan2020 (https://www.deviantart.com/advancedfan2020)
• Font
  • vyznev on fontstruct.com
  • Pascal Stang via glcd library
• PIO
  • A big thank you to the Raspberry Pi team for the PIO units. I believe peripherals like this should have been available years ago!
• Game Dependent Color Palettes (updated 03.01.2026)
  • VIS modding for providing all missing game checksums for the 32 Super Gameboy palettes (https://github.com/VISmodding)
  • VIS modding for providing all game checksums for the 45 Game Boy Color games (https://github.com/VISmodding)
  • R.A.Helllford for providing the palette data (found on https://github.com/davewongillies/openfpga-palettes)

Files

Sourcecode and release binaries are hosted on codeberg.org

• Hardware

  • GIT-Repository: https://codeberg.org/embedded-ideas/OpenDmgDisplay-HW/
  • Releases: https://codeberg.org/embedded-ideas/OpenDmgDisplay-HW/releases

• Software

  • GIT-Repository: https://codeberg.org/embedded-ideas/OpenDmgDisplay-SW/
  • Releases: https://codeberg.org/embedded-ideas/OpenDmgDisplay-SW/releases

I describe the process of assembling a PCB with some somewhat challenging components using only low-cost tools, like a ~10 USD hotplate. The result isn’t perfect, but it’s still very good for a manually assembled board.

Introduction

I think that in electronics, microsoldering has become a necessary skill for professionals and aspiring hobbyists alike. On a professional level, you should be able to make small modifications to a prototype board yourself. As a hobbyist, you need this skill in order to use modern components on your mostly manually assembled PCBs.

I recently worked a lot with the RP2040 and the RP2350B, which are well known to many people as the Pi Pico and Pi Pico 2, respectively. Maybe you’ve considered a project using one of these chips but changed your mind after discovering that they are only available in a QFN package.

With this post, I’m documenting my assembly process to show that soldering these types of components isn’t as hard as you might think, as long as you’re using the right tools. To make this even more accessible, I limited myself to basic equipment and more affordable consumables. The result may not be perfect, but it is far better than just “working.”

Board and equipment

As an example, I’m using one of my recent prototypes for the Open DMG Display, along with the corresponding stencil. The tools are mostly available through sites like AliExpress, eBay, etc.

• USB-C Mini Hotplate – 12.99 EUR incl. VAT (Link)
  • These mini hotplates are really cheap compared to a hot air station. When it comes to board assembly, I would absolutely choose one of these over any hot air station for assembling new boards.
• Low Temperature Sn42Bi58 Solder Paste OL-3016 – 4.07 EUR incl. VAT (Link)
  • This paste is a bit strange. It’s more like a fluid than a paste, but it is still possible to work with.
• Gel Flux OT-338 – 6.39 EUR incl. VAT (Link)
  • Surprisingly good flux.
• Pinecil – 25.99 USD (Link)
  • I have this around for field use and small modifications on the desk.
• TS-BC2 TS100 Iron Tip – ~10 USD
  • The Pinecil comes with a conical tip. Do yourself a favor and get a chisel or beveled tip.
  • Avoid using the really small ones. It might sound counterintuitive, but it’s easier to use a decent tip size.
• KELLYSHUN Solder Wick (came with the paste)
• 0.5mm Solder Wire with High Sn (e.g., Sn99.3Cu0.7)
  • I used my usual high-quality solder wire here, but I don’t think this counts as cheating.
• Bent Tweezers – 1.89 EUR incl. VAT (Link)
  • I also use those as a daily driver
• Metal Spatula or Old Credit Card

Besides the soldering equipment, you will need some sort of magnification. I would not recommend magnifying glasses. If you don’t have a lot of money to spend, use a USB camera with some clearance for soldering. I had one from Andonstar, which did a good job: Link. If you want to invest more, buy a proper stereo microscope.

I expect you to have a suitable USB-C power supply for the hotplate and the Pinecil.

The process

I’m using a hotplate process. In my opinion, this is a much more controlled and much easier process compared to using a cheap hot air station. You don’t have to worry about larger ground planes or uneven heating.

I started with the preparation of the PCB. I like to use other boards of the same height to build a temporary frame that holds the board in place. I used Kapton tape for this, but any type of tape works fine. Before aligning the stencil, I give the board a good wipe with some IPA.

The alignment of the stencil is crucial but doesn’t have to be within µm. Make sure the pads are aligned not only locally but also in other places on the board. Check diagonally at the upper left and the lower right. If your board has fiducials, use those.

After the alignment, tape the stencil at the upper corner to create a hinge. I forgot to take a picture of this, but you can see it in the picture with the solder paste.

Apply the perfect amount of solder paste above the area you want to assemble ;) In this example, I only want to assemble a part of the board that has the critical components that can’t be soldered with an iron. You also have to take into account that the space on the hotplate is limited.

As I mentioned, the solder paste I used was quite liquid. I initially took multiple strokes with the spatula, which resulted in a horrible outcome. The paste just spread under the stencil, and the board was completely covered.

If this happens to you, don’t worry. Clean everything up with some IPA and try again. On my second attempt, I only used one stroke, which worked quite well.

The result isn’t perfect, but you can clearly see the pad shapes even on the small-pitch parts. You shouldn’t worry if there’s a bit too much paste in those places. The paste will distribute itself as long as it’s roughly in the right place.

It is now time to start the assembly process. I recommend getting everything in place before you start assembling.

First, place the parts you can’t solder with an iron. I started with the QFN80 here.

I dropped it a bit misaligned and smeared some of the paste around. Normally, this is not a problem. I corrected the alignment and placed the oscillator, the flash, and the 45-pin FFC connector, followed by the other parts whose pads were covered with paste.

Now the board is ready for soldering using the hotplate. With the low-temperature paste I used, the following temperature profile was applied:

• 60s at 110°C
• 150s at 170°C
• 100s at 220°C
• Switch off for cooldown

Unfortunately, this needs to be done manually with the hotplate. That’s one of the reasons you might consider something like the MHP50 if you do this type of work more often.

I really like watching this process. The solder paste starts to melt, and shortly after, everything aligns itself. If something doesn’t align properly, you can use the tweezers to gently wiggle it until it sits perfectly.

As expected, my result wasn’t perfect but absolutely fine for a hand-assembled board. The only thing that was expected was a lot of bridging on the QFN80 package.

This is not a problem at all. Just use some flux and drag your iron along the sides of the IC.

This is how it looks after some cleanup with IPA.

The only thing left to do is soldering the components that haven’t been covered with the solder paste. Again, you should carefully decide which components you’d like to solder with the hotplate, as the area is limited to the size of the heat bed. The used hotplate allows for a 55mm x 55mm area.

Result and conclusion

The result looks OK overall. It works fine, and I’ve seen much worse. There are some misaligned passives, and a few pads had a little too much paste. I was surprised by the cheap flux—it really did a great job. The hotplate also worked much better than I expected. The solder paste was a bit strange and caused some bridging due to its liquid nature (and me dropping components). Working with the Pinecil feels a bit unusual, to be honest. I missed the round shape of my other soldering iron, especially with the beveled tip.

Overall, there is nothing wrong with the tools and consumables. It’s quite easy to hand assemble modern components with low-cost equipment. Just give it a try.

TL;DR

• See pictures ;)
• Files below

Introduction

I sometimes work on projects where I need to assemble multiple PCBs or iterate on a project using almost the same components for each prototype. I prefer doing these assemblies manually, as, in my opinion, it speeds up the process when dealing with prototypes. A recurring problem for me is handling components stored in small zipper bags within boxes of components in small zipper bags. I often feel like I spend more time searching for parts than placing and soldering them. This becomes especially problematic when the assembly process is fragmented. If I assemble three PCBs one weekend and another three the next, I end up wasting a lot of time just getting everything ready.

For a recent project, I wanted to approach things differently. The components needed to be stored with the project in a way that allows me to start assembling as soon as I pull them out of the drawer. I found a convenient way to store passives on 8mm tape. Several people had published some excellent 3D printable designs for this exact purpose, so I tried out the most promising one. Overall, it worked well, but I wanted a few modifications. Besides the passives, I needed storage for lower-count parts, like ICs, inductors, etc. I envisioned a sort of tray that would allow me to insert component tapes, securing them in a way that prevents them from falling off but still lets me pull them out easily during assembly. Unfortunately, I couldn’t find anything pre-made that fit these needs, especially not a storage solution optimized for the specific components I use for my project. So, I decided to design it myself.

Parametric SMD storage tray

The goals for this design were to provide a space saving method to store component tapes of different sizes that also lets you directly use the components for assembly. I came up with a design which, at least for me, solves the problem.

It

• … is fully parametric
• … is fully 3D printable (no additional parts required)
• … supports labeling (flat surface)
• … supports waterproof markers
• … has an integrated spring mechanism to securely hold the tapes
• … has a cover tape slot
• … makes a satisfying click when correctly assembled

To modify the design to suit your needs, you will need to use OpenSCAD (https://www.openscad.org). If you’re not familiar with it, don’t worry. The only thing you need to do is provide table-like data. You’ll need to describe the dimensions of the tape using seven values, along with an additional parameter to define the tolerance.

tape([ 12.0, 2.7, 0.5, 1.0, 3.0, 1.0, 3.0], 0.2),
tape([  8.0, 1.3, 0.3, 1.0, 3.5, 1.0, 3.5], 0.2),
tape([    w,   h,  ht, wsl, wsr, wtl, wtr], tolerance),

Each line represents one rail on the tray. All values are in mm. The diagram should make things a bit clearer:

In addition to the custom dimensions, I’ve also included some generic presets that should fit most 8mm, 12mm, and 16mm tapes. I’ve provided two examples in the SCAD file to help you get started. After editing the dimensions, you will need to compile the model (F6) and export the STL (F7).

For those who don’t want to modify the design, I’ve generated trays with 8x8mm, 8x12mm, and 8x16mm slots, each with a length of 150mm, using the generic presets. If you want to test if your tapes fit the presets, there is also a pre-generated tester model.

Hope you like it!

Build

Print settings

• Use a flat bed for printing
• .2mm layers
• .4 nozzle
• I had really good results with PLA+

Assembly

Just slide the two halfs together until you hear a click.

SMD component containers on a rail

The original model was designed by @LordAsdi_1250566 and published on Printables.com (https://www.printables.com/model/580643-smd-component-tape-magazine-8-12-16mm). He mentioned that he was inspired by Robin Reiter, who had also published a 3D printable design earlier (https://www.thingiverse.com/thing:3952021), which, in turn, was inspired by Maxint, who may have had the idea in the first place (https://www.thingiverse.com/thing:2186862). In any case, I made some improvements to the chosen design from my perspective:

• Container
  • Flat labels (better adhesion)
  • Snap-in labels (removable)
  • Parametric version (you can generate any width you like)
  • Screws instead of clips
• Rail
  • Support for weights (optional)
  • 3D printed spring instead of foam
  • Parametric version (you can generate any width you like)

Build

Required parts

• M2.5 x 6mm countersunk screws
  • Metric screws are not ideal for this purpose, but they are working really well here. If you have suitable self-tapping screws, use those.
• Cheap 8mm and 10mm round stock
  • Mild steel, nothing fancy
  • Cut to the length of your rail
• Spring (Wire 0.3mm, OD: 4mm, Length=20mm)
  • Maybe 0.4mm wire would be better but I could not test it yet

Print settings

• Use a flat bed for printing
• .2mm layers
• .4 nozzle
• I used PETG (PLA+ might be fine as well)

Container assembly

Rail assembly

Project files

DOWNLOAD: SMD Tray files

DOWNLOAD: SMD Containers files

TL;DR

• STLINK-V3MINIE to 2.54mm pin header adapter
• Target power supply with 5V and 3.3V
• 3.3V supply is adjustable via resistor divider
• Current limiting with LED indicator
• 3D printed case
• Open hardware: all files available

Introduction

I really enjoy working with STM32 MCUs and ST’s ecosystem, including their debugging adapters. Most of the time, I use the STLINK-V3SET. However, what I don’t like about it is the STDC14 connector with its 1.27mm pitch ribbon cables. Over the last few years, I’ve had several issues related to these cables. A broken wire, or even worse, an intermittent contact, caused delays during development. The problem often appeared as a faulty toolchain and was not easy to detect. I have experienced this issue with other debuggers like the Atmel ICE or the PLS UDE, etc.

For my hobby projects, I therefore use a different kind of connection. Most of the time, I have enough space to fit a standard 2.54mm pin header (single row), which is also used on most of ST’s development boards. So far, I have not experienced any major problems with signal integrity. However, when using this approach, I encountered some disadvantages when using the STLINK-V3SET with its 2.54mm adapter board:

• When using DuPont cables, the STLINK-V3SET gets messy.
• The adapter board with the pin headers has a large unprotected area (ESD and short circuit risks).
• Micro USB connection.
• Unnecessarily large device (when used with the adapter board).
• No target power supply options.

My requirements

Therefore I wanted:

• Smaller footprint
• USB-C connection
• 2.54mm pitch connector only
• Target supply option with 5V and 3.3V (up to max. USB current –> 500mA)
• Same compatibility with the ST ecosystem

An STLINK-V3MINIE based alternative

ST released the STLINK-V3MINIE debugger as a cheaper alternative to the STLINK-V3SET. It is the first one with a USB-C connector and provides both a STDC14 and a board-edge connector, while being fully compatible with the ST ecosystem.

Around the STLINK-V3MINIE, I designed a small board that connects to the board-edge connector. It offers direct access to the SWD port as well as the internal VCP port, and provides 5V and 3.3V on a 2.54mm pitch pin header. The pin header is separated into three groups (SWD, VCP, and power supply) but can be used with a 2x10 connector to build custom adapters for different projects.

Required materials

• PCB (Gerbers are included with the project files)
• BOM according to the IBOM
• 2.54mm double-row pin header (2x10)
• AVX board-edge connector (009159010061911)
• 3D printed case
• STLINK-V3MINIE

Assembly

The board is a standard 1.6mm 4-layer PCB. For easy assembly, you should use the “interactive BOM.”

Besides the board assembly, there is one other thing to be soldered. You need to add a jumper cable to the STLINK-V3MINIE in order to route the VBUS (+5V) to the adapter board. The following pictures show how I did it, but you might want to do it differently.

For the case, there are four STL files included in the project files. The bottom part of the case can be printed with or without a cutout for the STDC14 connector of the STLINK-V3MINIE. If you don’t use the connector, you might want to desolder it and use the file without the cutout (mine_adapter_btm_no_con.stl). Otherwise, you should use the default one (mine_adapter_btm.stl). The top part also has two variants. One version has holes for the LEDs to shine through (mine_adapter_top_led_holes.stl). This version should be used if you are using a material that doesn’t allow light to pass through. If you are using a transparent or light material, the other version with minimal material where the LEDs sit is better, as it allows the light to shine through the plastic (mine_adapter_top.stl). You can print with a default layer height of 0.2mm and a standard 0.4mm nozzle. I recommend PETG or PLA+ for some flexibility. Pure PLA might not be the best choice. After printing, you may need to clean up the area around the USB-C connector.

Once you have everything together, just connect the adapter board to the STLINK-V3MINIE using the AVX board-edge connector and place it into the top part of the case. The bottom part is held together with clips, so there is no need for screws. Be careful if you didn’t desolder the STDC14 connector in order to avoid breaking the small plastic pieces on the sides.

Files

STLINK-V3MINIE Adapter REV 1.0 DOWNLOAD

Contact

If you have any questions you can send a mail to info ‘at’ embedded-ideas.de or contact me via mastodon @DerTobi@mastodon.social

TL;DR

• Only HSYNC, VSYNC, CLOCK, DATA0 and DATA1 is required
• Frame starts with rising edge on VSYNC
• Row begins on rising edge on HSYNC
• First pulse of row needs to be ignored (occurs while HSYNC is high)
• First pixel of a row is captured on falling edge of HSYNC
• Other pixels of a row are captured on falling edge of CLOCK

Introduction

Capturing the image data from the DMG LCD data lines is actually not very complicated, but there are a few things you need to consider to get it right. Unfortunately, to the best of my knowledge, there is no official documentation for the signals coming from the GAME BOY’s CPU to the display board. I spent some time figuring out how it works (or at least how I think it works :) and thought it might be worth writing the results down.

Signals

There are quite a few signals that are correlated with the display. To capture the image, you will only need VSYNC, HSYNC, CLOCK, and the data lines (DATA0, DATA1).

If you’re working with, for example, 3.3V logic, you might consider using a level shifter. A generic buffer like the 74LVC541 worked well in my use case.

Frame structure

A frame contains all the data for one full image on the screen. In the case of the DMG, it is used to transfer 160x144 2-bit pixels. The process begins with the first pixel in the upper-left corner and continues horizontally. After 160 pixels, the next line is transferred until 144 lines have been sent to the display.

Each frame begins with a rising edge on the VSYNC line. The VSYNC signal stays high during the transfer of the first line and then returns to a low level for the rest of the frame.

Within a frame, you will find 144 lines, each initiated with a rising edge on the HSYNC line.

It seems there is some controversy about how the pixel clock works. I used an approach that I haven’t seen elsewhere (please email me if I’m wrong).

My first implementation just used the falling edge of the pixel clock (CLOCK line). I measured the pulses of the clock within the frame (160) and the alignment of the pixel data. This led to the obvious conclusion that the pixel data is valid on the falling edge of the clock.

After a while, I noticed some strange artifacts on the first column of pixels on the screen. Whenever a moving sprite leaves the screen on the right, it shows up pixel-wise on the first column on the left.

I searched for other projects that tried to capture the DMG screen and came across an article by Thomas Spurden (https://thomas.spurden.name/blog/capturing-gb-lcd/ ). He mentions a project by Sven Dahlstrand (https://github.com/svendahlstrand/game-boy-lcd-sniffing ) that uses the same approach I did, and an article by Kevin Horton (http://blog.kevtris.org/blogfiles/Nitty%20Gritty%20Gameboy%20VRAM%20Timing.txt ) which might have served as the signal interpretation blueprint for Thomas’ project.

Thomas and Kevin both say that the pixel data is valid on the rising edge of the pixel clock. Looking at the signals, this might be possible, but it would also be very strange from a design point of view. We are dealing with old (and cost-optimized) hardware, which might not be able to capture the signal fast enough. Even with modern hardware, it might be challenging to get it right. Additionally, this weakens the signal integrity when it comes to capacitive effects. Looking at the signals, the falling edge provides a nice sampling point at approximately 50%, which seems more likely to be the right approach in my opinion.

Thomas also mentions that the first pulse on the clock line should be ignored. I think he is correct. The position of the pulse in relation to the data looks a bit random compared to the other pulses. With the rising-edge approach, the capture of the last pixel (which, accordingly, has no pulse on the pixel clock) is done when the row is latched via the CPL signal.

If the data is valid on the rising edge of the pixel clock, we would miss the first pixel when we focus on the falling edge instead. I wasn’t happy with this solution, so I did some more analysis on how to capture the first pixel while using the assumption that data is valid on the falling edge.

I used the title screen of Super Mario Land 2 for this. On the far-left column, there is a black line starting from the 15th row. This makes it easy to validate the first pixel of each row.

After some time, I found the pattern that the first pixel data is valid on the falling edge of HSYNC. Measurements also show that the timing is close, if not similar, to the pixel clock. In my opinion, this makes more sense from a design perspective than capturing on the rising edge. The clock line might be disabled if HSYNC is high and triggers the capture mechanism as soon as it returns to low.

I re-implemented my solution, which now works as follows:

1. Wait for the rising edge on the VSYNC signal.
2. Wait for the falling edge on the HSYNC line and capture data lines directly as the first pixel.
3. Wait for the falling edge on the CLOCK line and capture data as the next pixel.
4. Repeat step 3 for the next 158 pixels.
5. Repeat from step 2 for the next 143 lines.
6. Repeat from step 1.

I did some testing with Super Mario Land, Super Mario Land 2, Wario Land, and Pocket Bomberman. Everything looks quite stable. ;)

You can download some of my sample data from the Super Mario Land 2 title screen here (50MS/s dumped from Saleae Logic 2).

Please let me know if you find any issues with my approach.

TL;DR

• Printable 8-bit ghost shaped CO² monitoring device
• Changes color according to CO² level
• Works with Arduino
• Uses Sensirion SCD4x CO² sensor
• Based on ESP32-C6 (WiFi, Bluetooth, IEEE802.15.4 capable)
• Custom PCB
• All open source / open hardware
• Files (Board, BOM, Sketch, etc.)
• Full list of required parts in assembly instructions
• File download here.

Introduction

I came across the topic of air quality measurement several times within the last couple of years (mainly on scientific or technical podcasts). As a developer I’m aware of the problem of bad air quality in the office without noticing it. If you’re busy problem solving, you might not have time to care about unimportant things like oxygen.

On a second though oxygen might help your brain solving the problem faster and keeps you awake. I came to the conclusion that a simple device which changes it’s color from green over yellow to red in order to signalize “hey dude, it’s time to open the window” would be the best for my use case.

I liked the idea that the device should fit nice on a desk and looks somewhat friendly (and maybe a bit nerdy). So an 8-bit ghost was the obvious solution.

Hardware

I wanted the device to be reproducible (as christmas presents), so I decided to design a custom PCB. Nothing fancy, just a controller, an LDO, some pixel LEDs and passives. I used four layers because it doesn’t cost much more and it speeds up the process. If somebody wants to I’m sure it can be reduced to 2-layers.

In order to allow expansion of the functionality and maybe some kind of integration into a smart home setup, the ESP32-C6 seemed like a good fit for the project. It offers the whole range of 2.4GHz standards (WiFi, Bluetooth, 802.15.4 –> ZigBee, Thread).

I tested some sensors (including VOC sensors) and came to the conclusion that only a real CO²-sensor delivers reliable results. The smallest and “cheapest” solution which is widely available is the Sensirion SCD40. You can get it for around 30$ from DigiKey.

The sensor is attached to the board using spring loaded pins in order to avoid damaging it or heat it up to much in the soldering process. Besides the spring loaded pin option, there is also a header which fits the boards available from ebay or aliexpress. I didn’t design any 3D parts for this, so you have to design it yourself.

The device uses 17 WS2812B RGB LEDs which should be driven on a low brightness level in order to avoid heat (and dazzling).

It doesn’t take expert level skills to solder the board, but a beginner might run into problems soldering the smaller components and finer pitch parts, especially the USB-C connector.

Firmware

I still don’t like the Arduino IDE and the “Arduino Sketch” style of programming. But I get the point that it should be easy for beginners and it allows non programmers to “get shit done”.

Anyways, I decided to write a basic firmware using Arduino to allow more people to have fun with the project.

The sketch should have enough comments and a sufficient naming scheme to make it understandable. In good Arduino style, a maximum of external libraries have to be imported:

• Sensirion I2C SCD4x (Sensirion) –> SCD4x sensor driver
• Sensirion Core (Sensirion) –> Required by Sensirion I2C SCD4x
• Adafruit NeoPixel (Adafruit) –> WS2812 Pixel LED handling
• Adafruit Debounce (Adafruit) –> Button handling

Assembly and programming

Partlist

• Printables (I used PETG but PLA etc. should be fine as well)
  • 1 frontcover (needs to be transparent)
  • 1 backcover
  • 2 eyes
  • 1 sensor holder
  • 1 sensor cover
  • 1 eye conector
  • 1 button cover
• Nuts and Bolts
  • 3 countersunk M3 x 16mm (e.g. DIN965)
  • 2 M3 x 12mm (any flat headed screw will do)
  • 5 M3 nuts
• Populated PCB (see board BOM and assembly pictures for details)
• Sensirion SCD4x Sensor (SCD40-D-R2)

Board assembly

You can order the board from anywhere you like. Gerbers are provided with the project files. The boards includes a holder for the springs. Before doing anything else you should remove it and put it aside. If you want to connect the ground pad of the ESP module, you should solder it first. I recommend to solder all LEDs and their decoupling caps afterwards. Remaining SMD components can be soldered in a small to large manner. As a last step the spring loaded pin assembly needs to be put together. It’s a bit tricky, so take your time. Make sure you dont solder the “springy” part. I provide some detail pictures as a reference.

For easy assembly you can use the “Interactive BOM” provided in the download archive.

Remember that you also have to buy the CO² sensor: Sensirion SCD40-D-R2 which is seen as an external component and is therefore not part of the BOM.

Printing

Nothing special about this. I used a .4mm nozzle and a .2mm layer hight with 15% infill. My print was a bit stringy because of the slightly older PETG filament. PLA might be the better option here.

Case assembly

First screw the sensor to the board and slide the M3 nuts into the front cover. Continue with the eye assembly. Place the board into the case and add the sensor cover and the button cover. Add the back cover and tight it shut with the countersunk screws.

Compiling and flashing

Download a recent version of the Arduino IDE and install the following libraries (Tools -> Manage Libraries):

• Sensirion I2C SCD4x (Sensirion) –> SCD4x sensor driver
• Sensirion Core (Sensirion) –> Required by Sensirion I2C SCD4x
• Adafruit NeoPixel (Adafruit) –> WS2812 Pixel LED handling
• Adafruit Debounce (Adafruit) –> Button handling

As well as the board support package (Tools -> Board -> Boards manager)

• esp32 (Espressif Systems)

Select the board “esp32 -> ESP32C6 Dev Module” and make sure to enable “USB CDC On Boot” in order to get the println outputs on the serial monitor. It might also be neccessary to install pyserial (serial libraries for python) in order to get the ESP32 tools running.

Files

Please download from the link below. The archive contains all required files to build the project.

• Schematic
• Bill of Materials (BOM)
• Gerber files to order the PCB
• STL files for printing
• OpenSCAD source files
• Arduino demo sketch (basic functionality, buttons are not used)

AirGhost REV 1.2 DOWNLOAD

Contact

If you have any questions you can send a mail to info ‘at’ embedded-ideas.de or contact me via mastodon @DerTobi@mastodon.social

The Odroid H2 and the Odroid H2+ are some of the few single board computers which offer PC like interfaces including 2x SATA, an NVMe slot, 2x 2.5 GBit ethernet (1 GBit for the H2) as well as dual RAM sockets. Besides the interfaces the board is equipped with a powerful, yet energy efficient x86 processor and includes an on board power supply.

In my opinion, the board is the perfect fit for an open source NAS system build. Unfortunately the case which is offered by the manufacturer didn’t meet my requirements.

I therefore built myself a compact and stable case which has the features I want. Maybe it still needs some spit and polish but the result is quite useful for me and maybe for you as well.

Before you start printing, be sure you want to have this case. It will take you a while to get hold of the parts and you will require some grams of filament ;-)

Parts

• 3D printed parts
  • 1x Backplate
  • 1x Fan mounting plate
  • 1x Left side panel
  • 1x Right side panel
  • 1x Top panel
  • 2x HDD rails
  • 4x Feet
  • 1x Button and LED holder
  • 1x Front cover
  • 1x Button inlay (should be printed transparent)
  • 1x Bottom plate with or without maintenance opening
• Screws
  • 9x M3 16mm
  • 29x M3 12mm
  • 4x Fan screws (normally included with the fan)
  • 8x 6-32 screws for HDD mounting
• Intended Hardware
  • Odroid H2 or Odroid H2+ (https://www.hardkernel.com/shop/odroid-h2plus/)
  • RAM (I used 1x Kingston KVR24S17S8/8)
  • NVMe SSD (e.g. Kingston A2000 250GB SA2000M8/250G)
  • 2x 3.5″ HDD (e.g. Seagate Ironwolf, Toshiba N300, be careful with WD RED –> https://www.youtube.com/watch?v=aztTf2gI55k )
  • 2x Odroid SATA cable-set (https://www.hardkernel.com/shop/sata-data-and-power-cable/)
  • 92mm PC fan (e.g. bequiet! PURE WINGS 2 92mm)
• Additional electronics
  • Temperature controlled fan controller (e.g. https://de.aliexpress.com/item/33015447685.html)
  • 3mm LED with a suitable current limiting resistor for 3.3V
  • Pushbutton (I got mine from one of those very handy kits https://de.aliexpress.com/item/32953981481.html)
  • Some jumper wires (e.g. https://de.aliexpress.com/item/32990585262.html)

Assembly Instructions

General rules:

• Use M3 12mm screws if not noted otherwise
• Insert M3 nuts into hexagonal holes
• Insert M3 nuts in the corresponding slots

You should start by mounting the fan to its mounting plate using the fan screws.

Depending on you choice of the bottom plate its a good idea too add the door to it.

After installing the nuts on the bottom, you can screw the fan and the back panel to the bottom plate. And add the feet (use M3 16mm for the feet).

Its time to screw down the Mainboard…

…and add the HDD rails…

…as well as the mount for the pushbutton (use M3 16mm for this).

I used some superglue to keep the push button in place. Don’t forget the current limiting resistor for the LED (@3V3).

Its time to install the remaining hardware. I connected the fan controller board to one of the SATA supply cables…

…and did some cable management. The BIOS battery can be glued to the side of the HDD rail.

Add the button inlay to the front cover.

The top and side covers can be mounted next. It is important to have the side panel with the vents on the right of the case. Do not screw down the side panels on the front. They will be fixed using the front cover.

The front cover is fixed using four M3 16mm screws. You need a screwdriver with a thin shaft in order to be able to screw it down trough the vent slots on the sides.

Done.

Files

Download CC-BY-SA 4.0

After reading some post which say something like “There is no way in hell there will be a driver for the RTL8125 unless a big company needs it…”, I came across the following forum topics which pointed me to the actual driver supplied by Realtek.

https://www.xigmanas.com/forums/viewtopic.php?t=15326 https://forum.netgate.com/topic/135850/official-realtek-driver-binary-1-95-for-2-4-4-release/8

Actually I didn’t expected Realtek to provide drivers for FreeBSD but it is available as source for download at:

https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software

Compiling the driver

Hint: I also provide the binaries for FreeNAS/FreeBSD 11.3. If you don’t want to compile the driver, you can download the binaries and just install it.

As a first attempt I tried to compile the driver directly on my FreeNAS installation. Unfortunately it looks like FreeNAS comes without a build system. As this is my first contact with FreeBSD, I decided to compile the driver on a virtual machine using a fresh FreeBSD 11.3 installation.

You can get the ISO image at https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.3/FreeBSD-11.3-RELEASE-amd64-dvd1.iso and install it on e.g. a new VitualBox.

During the installation process you should select to install the “System source tree” in order to be able to compile the system and the driver. If you forgot this step you might consider this blog post: https://www.jan0sch.de/post/install-freebsd-sources/. There is nothing else to worry about during the installation. Just follow the process.

The required steps to build the driver are described in the drivers readme.txt. I will describe the steps again as there are some slight changes necessary.

First of all you might want to backup the original files

cp /usr/src/sys/dev/re/if_re.c /usr/src/sys/dev/re/if_re.c.org
cp /usr/src/sys/modules/Makefile /usr/src/sys/modules/Makefile.org
cp /usr/src/sys/modules/re/Makefile /usr/src/sys/modules/re/Makefile.org
cp /usr/src/sys/amd64/conf/GENERIC /usr/src/sys/amd64/conf/GENERIC.org

Now we remove the driver as part of the kernel build. Remove the following lines from /usr/src/sys/amd64/conf/GENERIC respectively /usr/src/sys/modules/Makefile. I used vi for this. If you’re not familiar with vi some hints:

• dd –> delete line
• :wq –> save and exit
• :q! –> exit without saving (if you messed up ;-)

vi /usr/src/sys/amd64/conf/GENERIC
delete line -->  device              re

vi /usr/src/sys/modules/Makefile
delete line -->  re \

Now the fun part. First we set the build config, then we start the build process. You might consider to get some coffee, this might take a while. After the build we make a reboot.

cd /usr/src/sys/amd64/conf
/usr/sbin/config GENERIC
cd ../compile/GENERIC

make cleandepend
make depend
make
make install
reboot

Now we have the environment to build our driver as a kernel module. First we download the sources from Realtek (or use the link on my webspace). Then we unpack the files to the home dir.

cd ~
fetch http://www.embedded-ideas.de/files/rtl_bsd_drv_v196.04.tgz
tar -zxvf rtl_bsd_drv_v196.04.tgz

Now we copy the files to the right folders…

cd rtl_bsd_drv_v196.04
cp if_re* /usr/src/sys/dev/re/
cp Makefile /usr/src/sys/modules/re/

…and build them.

cd /usr/src/sys/modules/re
make clean
make

Thats it. Copy the if_re.ko onto a USB drive and continue with the installation on FreeNAS.

Update 16.08.20: The build system changed a bit on FreeBSD 12.1. You will find the binaries at /usr/obj/usr/src/amd64.amd64/sys/modules/re. If in doubt, use find / | grep if_re.ko to find the module.

Installing the RTL8125 driver on FreeNAS

As you might not have a working network connection you might consider to copy the driver to a USB stick. If you didn’t wanted to compile it yourself, you can download the binary here :

https://www.embedded-ideas.de/files/if_re-amd64-FreeBSD_11_3.ko

Update 16.08.20: Binaries for TrueNAS 12 BETA 2 (FreeBSD12.1) untested on my target machine but loadable on a virtual machine: https://www.embedded-ideas.de/files/if_re-amd64-FreeBSD_12_1.ko

Please make sure to safe the file on the USB stick as if_re.ko.

On the FreeNAS shell we first have to mount the USB stick. The example expects a FAT32 stick.

mkdir /mnt/usbstick
mount -t msdosfs /dev/da0s1 /mnt/usbstick

Now we have to copy the driver and change the file permissions.

cd /boot/kernel
cp /mnt/usbstick/if_re.ko ./
chown root:wheel if_re.ko
chmod 0555 if_re.ko

In order to load the module on startup we have to add the following line to /boot/loader.conf

vi /boot/loader.conf
add line --> if_re_load="YES"

Again a hint if you are not familiar with vi:

• i –> change to insert mode
• ESC –> leave the insert mode
• :wq –> save and exit
• :q! –> exit without saving

The driver should be loaded after a reboot. You can check this with

kldstat

if_re.ko should appear in the list. And the network interfaces should be available on FreeNAS.

It is nice to have a good CV/CC supply in the lab, especially if you want to power-up your prototype for the first time. Unfortunately those supplies are normally big and heavy and you don’t want to carry 9+ kilos from the lab to the living room in order to do some work on the couch.

A while ago I ordered a DPS3005 module to have a useable CV/CC “supply for the kitchen table”. The module itself provides no outstanding performance but is good enough for most scenarios.

In order to add input and output terminals to the module, I designed a small 3D printable case.

Happy printing!

Additional parts

• DPSxxxx size module
• 4x M3 Nut
• 4x M3 Screw Length: 30-50mm
• Input Terminals (Safety or Double 4mm Jacks) and DC-Jack
• Output Terminals (Safety or Double 4mm Jacks)
• Cable to connect the Terminals to the module (maybe soldering equipment and heat shrink)

Example for the safety or isolated terminals:

Example for the double screw terminal and the DC-Jack

Modules which (should) fit

• DPS3003
• DPS3005 (tested)
• DPS5005
• Electronic Load XY-FZ25 (tested)
• …maybe others as well

Files

• Left Part (DPS_Case_left_*.stl)
  • with isolated terminals on the front and back (DPS_Case_left_f_iso_b_iso.stl)
  • with double terminals on the front and back (DPS_Case_left_f_dual_b_dual.stl)
  • with an isolated terminal on the front and a double terminal on the back (DPS_Case_left_f_iso_b_dual.stl)
  • with a double terminal on the front and an isolated terminal on the back (DPS_Case_left_f_dual_b_iso.stl)
• Right Part (DPS_Case_right.stl)

DOWNLOAD ALL

For a while I used a Netgear Firewall Router as network switch and internet router. An additional Raspi Zero provided a Pi-hole.

Actually I couldn’t find a good alternative for the crappy Netgear router because most devices today only provide 4 LAN ports and I need at least six. So I ordered an eight port switch and started this little weekend project.

What I wanted was a simple OpenWRT router with one WAN interface and one LAN interface together with an additional Raspi Zero which could be used for other services. This setup allows to play around with the Raspi Zero without influencing the router. In order to keep cabling to a minimum, I wanted to connect the Pi Zero via a USB network connection.

OpenWRT on the Orange Pi R1

The OrangePi R1 is officially supported by the OpenWRT project, unfortunately it doesn’t support the additional USB ports of the board. In order to get USB running with the current version (19.07) you have to compile the sources yourself after hacking a kernel patch. I’m not very familiar with modifying the kernel respectively the Device Tree so I took a quick and dirty approach (..and left a message in the forum, hoping someone will submit the hack as a proper patch :-)

For now, the hack will do…

I assume you are running Linux. Download the sources of the OpenWRT 19.07 version from GitHub: https://github.com/openwrt/openwrt/tree/openwrt-19.07 and get your build environment ready according to https://openwrt.org/docs/guide-developer/quickstart-build-images within menuconfig your target configuration should look something like this:

In addition we need the RNDIS driver which can be activated at Kernel modules–>USB Support–>kmod-usb-net–>kmod-usb-net-rndis. If you need anything else, now is the time.

Save the build config and open the file target/linux/sunxi/patches-4.14/201-ARM-dts-sun8i-fix-USB-Ethernet-of-Orange-Pi-R1.patch and replace its content with the following:

From b76dc5927f6442df913f03ed261c5bff18a98df6 Mon Sep 17 00:00:00 2001
From: Icenowy Zheng <icenowy@aosc.io>
Date: Thu, 28 Dec 2017 21:01:56 +0800
Subject: [PATCH] ARM: dts: sun8i: fix USB Ethernet of Orange Pi R1

Orange Pi R1 uses a Realtek RTL8152B USB Ethernet chip, which is easily
seen on the board but not show in the schematics. A regulator for the
power of the RTL8152B chip is hidden, which uses the same pin with the
Wi-Fi regulator on the original Orange Pi Zero.

Add this regulator back to the device tree, and bind it to USB1.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
@@ -49,6 +49,20 @@
 
 	/delete-node/ reg_vcc_wifi;
 
+	/*
+	 * Ths pin of this regulator is the same with the Wi-Fi extra
+	 * regulator on the original Zero. However it's used for USB
+	 * Ethernet rather than the Wi-Fi now.
+	 */
+	reg_vcc_usb_eth: reg-vcc-usb-ethernet {
+		compatible = "regulator-fixed";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "vcc-usb-ethernet";
+		enable-active-high;
+		gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
+	};
+
 	aliases {
 		ethernet1 = &rtl8189etv;
 	};
@@ -71,3 +85,23 @@
 		reg = <1>;
 	};
 };
+
+&usbphy {
+	usb1_vbus-supply = <&reg_vcc_usb_eth>;
+};
+
+&ohci2 {
+	status = "okay";
+};
+
+&ohci3 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&ehci3 {
+	status = "okay";
+};

This simply enables the additional USB ports. Save the file and start to compile using make -j. Now its time for a coffee break.

If everything worked you should now find an image for your Orange Pi R1 in bin/targets/sunxi/cortexa7. Dependent on your preferences you can decide to use either openwrt-sunxi-cortexa7-sun8i-h2-plus-orangepi-r1-ext4-sdcard.img.gz or openwrt-sunxi-cortexa7-sun8i-h2-plus-orangepi-r1-squashfs-sdcard.img.gz. Load the contained image to an SD-Card and power up your Orange Pi R1 with it.

It should be possible to connect to OpenWRT using ssh root@192.168.1.1 on the connector without the sticker. The other connector needs to be connected to a DHCP enabled net with internet access. First of all we need to install LuCI (https://openwrt.org/docs/guide-user/luci/luci.essentials for details):

opkg update
opkg install luci
opkg install luci-ssl-nginx

LuCI should now be available via https://192.168.1.1/.

Raspian installation and RNDIS setup

I used Raspbian Buster Lite for my setup, but the following should work on other versions as well.

Obviously, first step is to prepare an SD-Card with the Raspian image. After that we need to activate the ethernet adapter emulation. Open the boot partition and add the following line to the config.txt:

dtoverlay=dwc2

Open the cmdline.txt and add the following text behind rootwait:

modules-load=dwc2,g_ether

The last step in the boot partition is the creation of an empty file named ssh in order to allow console access.

For details you might consider reading https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadget (even if I doubt their choice for a text editor).

Bringing it all together

Connect the Pi Zero to the Orange Pi R1 using the OTG USB port of the Pi Zero (the inner one). If you run dmesg on the Orange Pi it should show something like

[    8.902193] usb 4-1: New USB device found, idVendor=0525, idProduct=a4a2
[    8.908916] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    8.916146] usb 4-1: Product: RNDIS/Ethernet Gadget
[    8.921287] usb 4-1: Manufacturer: Linux 4.19.75+ with 20980000.usb
[    8.930453] cdc_ether 4-1:1.0 usb0: register 'cdc_ether' at usb-1c1c000.usb-1, CDC Ethernet Device, xx:xx:xx:xx:xx:xx

For the rest we can use LuCI. Open Network–>Interfaces and click on Edit at the br-lan interface. Open the tab Physical Settings and activate usb0 in the drop down box on the bottom.

We now have connected the Pi Zero to the 192.168.1.x network. It should be available via raspberrypi.lan or the IP-lease that it got from OpenWRT (see Network–>DHCP and DNS–>Static Leases).

This should be enough to get you up and running. I highly recommend to set a password for OpenWRT as a next step ;-)

• Pros
  • Possible extension of existing projects
  • Often easier routing
  • IO features like enhanced current capabilities or voltage level shifting
• Cons
  • Requires CPU cycles for bus access
  • Slower access
  • Higher complexity (no register mapping)
  • Additional cost/parts

I came across this problem several times now and often used the very common Microchip port expanders like the MCP23008. Such a device offers 8 to 16 configurable pins which can be inputs or outputs with pull-up/down resistors. Actually those parts work great but they can be very expensive depending on your project. Another downside is the protocol overhead which you get as a trade-off for the flexibility of those devices. In case you only want to have a fixed number of inputs or outputs the good old 74 series might be a better solution.

I assume it is widely known that the SPI-Bus is ideal for the connection of shift registers to a micro controller. The 74 logic series offers a wide range of such registers. Especially the 74xx595 and the 74xx165 are good candidates for port expansion.

The 74xx595 is a serial-in parallel-out (SIPO) shift register with an output latch, it offers eight outputs and can be directly connected to a standard SPI bus which is set to CPOL=0 CPHA=0. The only downside is that if you don’t want the outputs to have an unpredictable state before the first transfer, you also have to control the output enable line. In case you only want to control some LEDs you might not care and set the output enable permanently.

The 74xx165 is a parallel-in serial-out (PISO) shift register with an input latch, it offers eight inputs. Unfortunately it is a bit less compatible to the SPI defacto standards. It is still possible to use it but you need an active high chip enable and invert the SPI clock (CPOL=1 CPHA=0). Unfortunately this makes it also incompatible with the 74xx595. But what if you need inputs and outputs for your project and you don’t want to mess around with two busses, different chip select lines or clock polarity settings?

The solution is quite simple with another part from the 74 series. Just an inverter e.g. 74xx04 on the latch input and on the clock line of the 74xx165 will do the job. Now the PISO also works with a negative chip select and the common CPOL=0 CPHA=0 settings. The 74xx595 and the 74xx165 can co-exist on one SPI bus and even better: you just need one SPI transfer to set the outputs and read the inputs.

Another great feature of this circuit is its expandability. If you need 8 more inputs or outputs, you just add another shift register. For the 74xx595 this can be achieved by connecting the nG, RCLK, nSCLR and SCKL in parallel and the serial output (QHser) with the new chips serial input (SER). The same for the 74xx165: connect SH and CLK in parallel and the serial output (QH) of the new chip to the serial input (SER).

The presented circuit assumes an own bus for the port expansion. If you want to share the bus with other peripherals, you need to get the SPI MISO line in a tri-state if the chip select line is high. This can be achieved with a tri-state buffer like the 74xx125.

There are many derivatives of the shift registers and other parts that can be used for the circuits shown above.

• 74HCT595 / 74HCT165 – Only for 5V systems
• 74HC595 / 74HC165 – OK for 3.3V applications
• 74LVC595 / 74LVC165 – 3.3V system + 5V tolerant
• 74LVC2G04 Dual inverter (in case you don’t have space for the 74xx04)
• 74LVC1G125 – Single tri-state buffer for bus sharing (replaces 74xx125)
• TPIC6B595 – High current version of the 74xx595 with open drain outputs
• etc.

All parts are generic and you can get them from different manufacturers. This allows you to buy all required ICs for as low as 0.20 USD (already @100 qty) from one of the major brands and even cheaper from a no-name brand .

This should be enough information to get you started on the hardware side, but what about the software? Most things on the cons list are software related. Can we get around some of the problems? Maybe! At least we don’t have any protocol overhead. In case of the circuit in the last picture, we transfer 8 bits with which we set the state of 8 outputs and simultaneously read the state of 8 inputs. With the right hardware we can even offload the CPU cycles to the DMA controller and speed up the transfer rate without causing any CPU load. If we reserve a fixed address for the DMA transfer we can even resemble a “register” for the input and output states. In order to use this mechanism it is crucial that the SPI controller supports to set the chip select line in the right way. The controller has to pull the CS line low on the beginning of a transfer and reset it to high after it. Most microcontrollers that I know have this feature but there are exceptions (most of the STM32 controllers).