u/Stackter

Hey everyone,

I'm a proud owner of a classic Mazda MX-5 Miata, and instead of installing modern aftermarket gauges that ruin the 90s interior look, I decided to give my old Nintendo DS Lite a permanent home on my dashboard.

The DS receives UDP packets from an ESP32 in the engine bay (reading Oil Temp, Oil Pressure and coolant Temp.) and displays everything in real-time. I'm writing this entirely in C using devkitARM and the gl2d library.

To keep the memory footprint extremely low and ensure a locked 60 FPS, I am drawing almost all UI elements, gauges, and graphs directly via code loops (glBox, glLine, etc.). I am using spritesheets only for the animated 3D car models (like the G-Force indicator and startup sequence); absolutely everything else is code-rendered.

However, I've hit a major roadblock regarding the Dual-Screen rendering and I'm hoping someone can help me Out.

Since the DS only has one 3D core, I am using the standard Display Capture method to achieve hardware-accelerated rendering on both screens. My main loop alternates rendering between the top and bottom screen every frame:

swiWaitForVBlank();

while(REG_DISPCAPCNT & DCAP_ENABLE);

if((frame & 1) == 0) {

lcdMainOnBottom();

vramSetBankC(VRAM_C_LCD);

vramSetBankD(VRAM_D_SUB_SPRITE);

REG_DISPCAPCNT = DCAP_BANK(2) | DCAP_ENABLE | DCAP_SIZE(3);

drawDashboard();

} else {

lcdMainOnTop();

vramSetBankD(VRAM_D_LCD);

vramSetBankC(VRAM_C_SUB_BG);

REG_DISPCAPCNT = DCAP_BANK(3) | DCAP_ENABLE | DCAP_SIZE(3);

drawMenu();

}

glFlush(0);

The Bug: I am experiencing severel "screen swapping" issues (both screens freezing, or the top and bottom screen rapidly flickering/swapping back and forth).

This only happens when the main loop gets stalled by blocking operations:

When I open my internal "Data Logger" menu, which uses libfat to fopen and parse a large .csv file from the SD card.

When the WiFi connection to the ESP32 drops and Wifi_InitDefault() or Wifi_AutoConnect() tries to re-initialize the connection in the background.

It seems that whenever the CPU is blocked by SD I/O or WiFi, swiWaitForVBlank() goes out of sync with the physical refresh rate, causing the VRAM bank swapping and REG_DISPCAPCNT to completely mess up the frame parity.

My Question: What is the standard/best-practice way to handle heavy, blocking FAT/WiFi I/O without breaking the strict (frame & 1) VBlank alternation required for dual-screen 3D capture? Do I need to move the FAT reads to an asynchronous timer, or is there a way to safely "pause" the screen swapping hardware registers before initiating a heavy SD card read, and resume it afterwards without corrupting the VRAM banks?

Any advice on how to handle synchronous stalls while doing display captures would be highly appreciated!

Hey guys,

I wanted to share my recent DIY project with you. I originally saw someone on Instagram selling gauge setups that connect to a PSP, and it got me thinking—I bet I could build something like that myself from scratch.

Turns out, you absolutely can. The hardware side consists of a custom PCB I soldered together around an ESP32 microcontroller, which interfaces with all the automotive sensors. But the biggest challenge was the software: I had to write a custom Nintendo DS "Homebrew Game" from scratch. The DS connects to the ESP32 via Wi-Fi, receives the telemetry data, and processes it in real-time. It took hours upon hours of coding and troubleshooting to figure out how to make both worlds talk to each other.

Choosing the right console was another major decision. The original DS felt a bit too small, the DSi XL turned out way too big for the interior, and the 3DS didn't have that classic retro vibe I wanted. As you can see in the pictures, I tested a few options, but I finally settled on the DS Lite as the perfect middle ground.

Currently, the main functions are split between the two screens. The top screen displays the critical engine vitals: Oil Pressure, Oil Temperature, and Coolant Temperature. The bottom screen features a menu with various utilities, including a GPS speedometer (with an RPM gauge coming sooner or later), a compass, GPS coordinates, outside temperature, a gyroscope, a trip counter, and historical data graphs for the oil stats. I've also integrated some data-logging capabilities.

I'm always looking to improve this setup, so if you guys have any feedback, UI suggestions, or ideas, please let me know!

Hey guys, here’s another update on my Nintendo DS digital dash project for my NA!

As you can see in the pictures, almost everything is up and running now, except for the coolant temperature sensor and the RPM gauge. I’m also ironing out a few small data-logging issues and minor UI bugs, but the good news is that the GPS speedometer works perfectly. Both oil pressure and oil temperature readouts are also working flawlessly and almost instantly, and the historical data graphs are running smoothly too.

To get the real coolant temperature working, I just need to source a Y-connector to split the factory sensor location at the back of the engine block. However, I'm still struggling to get a clean RPM signal for the rev counter. I haven't found a reliable way to wire it up yet, so if anyone has successfully solved this on an NA before, I could really use some advice!

While reshelling my DS Lite, I temporarily switched to a DSi XL—and as you can see, it is absolutely massive in the Miata interior! Once the DS Lite is finished, I need to figure out the best mounting spot. Right now, I’m thinking about deleting the left eyeball air vent in the center console and 3D-printing a custom mount to fit right there. Ideally, I want to position the DS slightly higher than how it looks in the first picture.