A live status display for the MiSTer, on the $15 board everyone already has

This is Part 2 of the MiSTer series. Part 1  covered what MiSTer is and why this workshop runs two of them next to real hardware: 

There's a small touchscreen sitting on top of my MiSTer Pi that always knows what the FPGA is doing. Load Dimahoo and the screen fills with Dimahoo artwork; load a Mega Drive game and the box art appears; tap through its pages and it shows the MiSTer's CPU load, memory, storage, network state, and connected USB devices, live. The project is MiSTer Monitor by chipster6502—open source, MIT licensed—and while it was born on a $60 M5Stack tablet, since May it officially runs on the Cheap Yellow Display: the ESP32-2432S028R, a $15 board with a 2.8-inch touchscreen that half the maker community already has in a drawer. This post is the build—which, thanks to the current release, is genuinely easy—and the three-fault network mystery that cost me an evening anyway, because the faults were mine, and they stacked.

The CYD riding the MiSTer Pi—Tron loaded on the core, Tron on the little screen.

What it actually does

The monitor is two pieces talking over your network. On the MiSTer, a small Python server watches what the system is doing—which core is loaded, which game file was just picked—and serves that state over HTTP. On the display, an ESP32 sketch polls that server, identifies the game, fetches its artwork from the ScreenScraper database, and renders it with a footer naming the core and title. Detection is real-time: the server watches the MiSTer's state files with inotify and tells actual game loads apart from menu browsing by comparing file timestamps at nanosecond precision.

The main HUD and the performance page—core status, uptime, CPU and memory, live.

Storage and the USB device scanner.

The artwork is the show—wheel logos, 3D box art, arcade fan art, all configurable in priority order—but the monitor pages earn their keep on a workbench: CPU and memory, uptime, SD card usage, network addresses, and a USB device scanner. When something misbehaves, the little screen is the first place I look.

The hardware: a $15 community legend

The Cheap Yellow Display is a generic ESP32 dev board with a 2.8-inch 320×240 resistive touchscreen, a microSD slot, and WiFi, sold under the catalog number ESP32-2432S028R for about $15. It earned its nickname and a devoted community because it's the cheapest way to put a connected touchscreen anywhere; there's an entire community repository dedicated to things people have made it do. MiSTer Monitor's flagship hardware is the M5Stack Tab5—a 1280×720 ESP32-P4 tablet, and the bigger screen is genuinely nicer—but the v2.2.0 release added a full native CYD port, and that's what's running on mine. Same features, smaller glass, a quarter the price.

Arkanoid (JP) fan art, fetched from ScreenScraper on first load and cached to the card.

The install, as it stands today

The current release removed almost every rough edge this project ever had, so the honest setup story is short:

MiSTer side. Install through the standard MiSTer Downloader: drop the project's database file next to downloader.ini and run Update All. Then two one-time steps—make sure log_file_entry=1 is set under [MiSTer] in MiSTer.ini (without it, the server can't see game loads and the display will sit there politely showing nothing), and add the server's start line to user-startup.sh.

Display side. Flash the firmware from a web page—Chrome or Edge, USB cable, no Arduino IDE, no toolchain. Copy the ready-made SD card layout from the repository onto a FAT32 card, edit one config.ini with your WiFi credentials and a free ScreenScraper account, and boot it.

Two things you no longer need, if you read about this project earlier: a static IP for the MiSTer (the display now finds it automatically by UDP broadcast) and a ScreenScraper developer account (the app ships its own credentials; a free member account is all you bring). Both removals landed in v2.3.0, and they matter—the dev-account approval used to take days.

That's the whole build. Mine still took an evening, and the reasons are the useful part.

Fault one: the CIFS mount that ate my WiFi

My MiSTer's game library lives on a NAS, mounted over CIFS at boot. My MiSTer is also on WiFi. Those two facts had been coexisting only by accident: the CIFS mount script was configured with MOUNT_AT_BOOT="true" and WAIT_FOR_SERVER="true", which hooks the mount early in the boot sequence and blocks, waiting to reach the NAS—over a WiFi link that doesn't exist yet that early in boot. With an ethernet cable plugged in, the mount succeeded instantly over copper and everything proceeded. Without the cable, the mount attempt stalled network bring-up and wlan0 never finished getting an address.

The symptom as I experienced it: "my WiFi dongle won't get an IP unless the ethernet is ALSO plugged in." Hours went into that sentence. The fix is to stop mounting at boot and instead mount when the network is actually up—one line in user-startup.sh:

(while ! ip addr show wlan0 | grep "inet " | grep -qv "169\.254"; 
do sleep 2; done; sleep 5; /media/fat/Scripts/cifs_mount.sh) &

Three details earn their place in that line: it runs in the background so boot never waits on it; it ignores 169.254.x.x self-assigned junk addresses, which MiSTer's boot-time DHCP race can briefly produce and which would otherwise fool the check; and it gives routing five extra seconds to settle before mounting. Set MOUNT_AT_BOOT="false" in cifs_mount.ini so the early hook stays gone. Cable-free cold boot, real DHCP lease, shares mounted seconds later—permanently fixed.

Fault two: the server that worked just well enough to fool everyone

With WiFi fixed, the display joined the network, found nothing, and parked itself on OFFLINE. Meanwhile every test said the MiSTer side was healthy: the server answered HTTP, returned the loaded game's name on request, and the project's developer—who was quick and generous with help when I wrote in—confirmed from my logs that detection was working perfectly.

The tell was one command on the MiSTer:

netstat -uln | grep 51234

Nothing. UDP port 51234 is where the current server answers the display's discovery broadcasts—and my server wasn't listening on it, because my server was an older version left over from earlier experiments. Old enough to predate auto-discovery entirely, new enough that everything else worked, which is exactly the kind of partial failure that eats evenings. One wget of the current server script, one restart, and the responder was listening; the display found the MiSTer within seconds of its next boot.

If your display can't find your MiSTer, run that netstat line first. It would have saved me half the night.

The "before" shot—DISCONNECTED, parked on the placeholder address while three faults stacked.

Fault three: the config option that did nothing (a real bug, now reported)

In between, I'd tried the documented fallback: setting the MiSTer's address manually in the display's config.ini. I edited that file more than ten times. The target on screen never changed from the firmware's built-in placeholder.

That one wasn't me. Reading the CYD firmware source, the config loader parses the ip= key correctly—and then the value is never applied. Every other setting gets wired up after the config loads; the MiSTer IP keeps its compiled-in default and is only ever set by successful auto-discovery. The manual-IP fallback was dead code on the CYD build.

There's a quieter lesson stacked in here too. My "the MiSTer's IP" had been two different addresses all day without my noticing: the wired jack and the WiFi dongle have different MAC addresses, so my router's DHCP reservation only pinned one of them. Every time the cable went in or out for testing, the MiSTer changed identity. If a device can use two interfaces, reserve both MACs—or pick one interface and stay loyal to it.

And the after: CONNECTED, real addresses, requests flowing.

What it's like to live with

Once running, the thing is simply pleasant. Artwork changes a few seconds after a game loads; the first encounter with any title downloads its art from ScreenScraper and caches it to the SD card, so each game is only ever slow once. That first-run warmup is also the one performance note worth giving: the server identifies games by hashing the ROM file, and if your ROMs live on a NAS over WiFi, the first minutes of heavy browsing pull real bandwidth through a small dongle. It settles as caches warm; wired ethernet makes it a non-event.

A night of channel-surfing the cores: WWF Superstars, Armed Police Batrider, Virtua Fighter Remix.

One caveat remains as I write this: a cold-boot race. The display boots in seconds and broadcasts its discovery requests immediately; a cold-booting MiSTer needs a minute before its server is up, so if both power on together the display can give up and sit OFFLINE until you power-cycle it. Boot the MiSTer first, or replug the display—and the manual-IP fix above will retire this caveat for static setups when it ships.

Worth building?

For $15 and an evening—less if your network sins are fewer than mine—you get live game artwork on your shelf, a system monitor you'll actually use, and a project that's improving at a visible pace under a developer who answers questions. The flagship Tab5 version is the same build with a bigger, sharper screen if you'd rather have that. Either way: built and tested at this workshop, on a real MiSTer Pi, next to the real machines it imitates.

Frequently asked

Do I need the M5Stack Tab5, or does the cheap board really work? The CYD (ESP32-2432S028R) is officially supported since v2.2.0 with a native 320×240 layout—it's what this workshop runs. The Tab5 has a much larger 1280×720 screen; the features are the same.

Do I need a ScreenScraper developer account? Not anymore. Since v2.3.0 the firmware ships its own developer credentials; you only need a free member account at screenscraper.fr, entered in config.ini.

Does the MiSTer need a static IP? No—the display discovers it automatically via UDP broadcast. A manual address in config.ini is the documented fallback for networks that block broadcast (with the bug caveat described above on the CYD build).

My display says OFFLINE and never connects. What do I check? In order: log_file_entry=1 in MiSTer.ini; netstat -uln | grep 51234 on the MiSTer to confirm the discovery responder is listening (empty means your server script is outdated); curl http://<mister-ip>:8081/status/game from another device with a game loaded; and if you're on WiFi with CIFS mounts, the boot-order fix in this post.

Further reading

• MiSTer Monitor by chipster6502 (source, releases, documentation): https://github.com/chipster6502/MiSTer_monitor
• Web flasher (Chrome/Edge): https://chipster6502.github.io/MiSTer_monitor/flasher/
• MiSTer Downloader database for the server side: https://github.com/chipster6502/MiSTer_monitor_DB
• The Cheap Yellow Display community repository (witnessmenow): https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display
• ScreenScraper, the artwork database this all leans on: https://www.screenscraper.fr
• The MiSTer WiFi/DHCP boot race, documented: https://github.com/MiSTer-devel/Linux-Kernel_MiSTer/issues/29
• CIFS mounts interfering with MiSTer WiFi (forum thread): https://misterfpga.org/viewtopic.php?t=8730
• Part 1 of this series—what MiSTer is: https://chicagolandretrotech.com/blogs/news/what-is-mister-the-fpga-that-plays-every-atari-i-dont-own-and-some-i-do

I'm Jeffrey Mays. Bench Notes is where I write up the actual workshop work—burns, builds, repairs, and the occasional evening lost to three network faults wearing one disguise. Next in this series: real Atari controllers plugged straight into the FPGA. Subscribe to catch it.