12/3/2025 6 PM - Headless Raspberry Pi

12/3/25

*Picture is just for concept, the display here is not compatible and the tin is not big enough for the final project, additionally for more computing power the Radxa 0 3W will be used for wider variety of emulation_

Since I do not yet have the grant, I haven’t been able to acquire the full components for AltoiDS, so I performed preliminary testing using parts I already had on hand. For this initial phase, I used a Raspberry Pi Zero 2 W to simulate the handheld console environment and imaged an SD card with RetroPie. I attempted to enter headless mode, but network configuration issues required me to reimage the SD card before I could successfully access the system. Once connected, I updated packages and completed a basic setup to ensure RetroPie runs properly on a compact board. I did not perform GPIO testing at this stage because the setup requires a functional display and I currently lack an OTG adapter to connect a keyboard. Additionally, I located a limited edition XL Altoids tin to serve as the future enclosure and planned how the board, display, and other components will fit, taking preliminary measurements for 3D-printed internal mounts. This testing phase serves as a foundation for the project and prepares the system for full assembly once the necessary materials are obtained.

12/3/2025 9 PM - Concept Cad Files / Parts List

12/3/25

I started compiling the full Bill of Materials (BOM) for AltoiDS, including links, prices, and notes for each component. I also set up a GitHub repository to track project files, documentation, and CAD designs.

I created a rough CAD prototype to visualize the outside of the console. This helped plan proportions, button placements, and the overall look. The CAD only covers the exterior because I don’t have the components yet to model the inside.

For the main board, I chose the Radxa Zero 3 W instead of a Pi Zero 2 W because it has more RAM and processing power. This ensures smoother emulation across a wider range of systems, which is key for a handheld that aims to run games from NES to more demanding consoles.

The XL Altoids tin was chosen for both practical and conceptual reasons. The original idea was an Altoids-sized portable, but standard tins are too small to fit the components I need. The XL tin provides enough space for the board, screen, battery, and 3D-printed internal mounts, while keeping the device compact and visually appealing. It also reduces the need for fully custom fabrication while giving the finished project a polished look.

I also researched suitable screens and buttons, aiming for compact and compatible parts that will fit inside the tin once I receive the grant and can order the remaining components.

12/4/2025 - Published BOM / Part Research

12/4/25

I continued refining the Bill of Materials (BOM) for AltoiDS, researching and selecting components for the handheld build. Each part was evaluated for compatibility, size, and cost, including the main board, screen, buttons, battery, and connectors. I compiled links and pricing to ensure efficient sourcing once the grant is awarded.

The project uses prebuilt components rather than a custom PCB due to my current skillset, but each piece was chosen to allow meaningful assembly, wiring, and testing, which supports a Tier 1 project. The total projected cost slightly exceeds $200 primarily due to shipping costs from multiple suppliers. This keeps the budget within the Tier 1 limit of $400 while allowing higher-performance parts like the Radxa Zero 3 W for broader emulation support, a larger TFT display, and a battery setup that provides longer playtime.

I also confirmed GPIO compatibility for buttons, selected 12×12 mm tactile switches for ABXY and D-pad controls, and smaller 6×6 mm switches for Start/Select to save space. The XL Altoids tin was chosen as the enclosure because a standard tin is too small for the layout, and it aligns with the project’s goal of a compact, “Altoids-sized” handheld. I planned 3D-printed internal mounts to maximize space efficiency and accommodate all components.

Additional components, like the TP4056 charging module and MT3608 boost converter, were chosen to support safe battery operation and stable voltage output. This BOM research ensures that once the grant is received, assembly and testing can proceed smoothly. Overall, the careful selection of parts and consideration of budget, function, and size justify the Tier 1 classification.

12/5/2025 - Official BOM on Github (more part research)

12/5/2025

Today I finalized the Bill of Materials for AltoiDS. I researched the Radxa Zero 3 W for compatibility with ILI9341 SPI displays and confirmed the GPIO pinout to plan for all button connections. I selected 12×12 mm tactile switches for ABXY and D-pad controls and smaller 6×6 mm switches for Start/Select to save space. I also added a 10 kΩ resistor kit for reliable button inputs.

For power, I chose a 2000 mAh LiPo battery with a TP4056 charger and an MT3608 boost converter. I decided against an internal speaker to prioritize space for wiring and the battery. The enclosure will be an XL Altoids tin, slightly larger than a standard one, to fit all components and allow room for 3D-printed mounts.

This stage was mostly research and planning, preparing the layout and selecting parts for the project. The total cost is still slightly above $200 due to shipping.

12/6/2025 11 AM - Python + C Scripts

12/5/25

^ i had to sleep, so this got posted late

Today I wrote six Python scripts for testing and configuring the GPIO buttons once hardware arrives. These are based on my planned GPIO pinout.

Scripts Created

button_test.py - Button Input Testing

Monitors all 10 buttons (D-pad, ABXY, Start, Select) and prints which button gets pressed. Planned GPIO assignments:

"UP": 5, "DOWN": 6, "LEFT": 13, "RIGHT": 19
"A": 16, "B": 20, "X": 21, "Y": 26
"START": 17, "SELECT": 27

Checks GPIO pins every 0.05 seconds to detect presses.

pinout_validator.py - GPIO Conflict Check

Scans the button assignments to ensure no two buttons use the same GPIO pin. Ran it on my current plan: "No conflicts detected."

generatebuttonmap.py - Config Generator

Generates RetroPie-compatible button config files from GPIO pin definitions:

input_up_btn = "5"
input_down_btn = "6"
input_a_btn = "16"

powerbuttondaemon.py - Shutdown Handler

Monitors GPIO pin 4 for a 2+ second button hold to trigger safe shutdown. Prevents SD card corruption from hard power-offs.

launcher_mock.py - Menu Prototype

Text-based menu prototype using keyboard input:

=== AltoiDS Launcher ===
> Start RetroPie
  Settings
  Shutdown

debug_logger.py - Event Logger

Logs button events with timestamps to help troubleshoot input issues:

2024-12-05 14:23:17 | EVENT: A
2024-12-05 14:23:18 | EVENT: START

GPIO Organization

Grouped pins logically:

• D-pad: pins 5, 6, 13, 19
• ABXY: pins 16, 20, 21, 26
• Start/Select: pins 17, 27

Current Status

Scripts are written but untested. Need actual hardware to verify GPIO functionality. Some scripts (validator, config generator) work now since they only process text. Others (button_test, power daemon) require GPIO hardware.

Next Steps

• Create visual GPIO pinout diagram
• Research Radxa GPIO library compatibility
• Wait for grant approval
• Test with hardware when it arrives

Repository: GitHub

All scripts are available in the AltoiDS Repo on Github

12/6/2025 1 PM - Rough Model: AltoiDS 3D Printable Inserts

12/6/25

Today I got the personal Fusion 360 plan and started designing the internal mounting inserts for AltoiDS. Since I don't have the physical components yet, I used measurements from a CAD model I found on GrabCAD by Mark Simonelli to plan the layout.

Fusion 360 Setup

Downloaded and installed Fusion 360 with the free personal license. This is my first time using proper CAD software for a project like this. Spent some time learning the basic interface and tools.
Design Process
Found an Altoids tin model on GrabCAD (created by Mark Simonelli) that has accurate dimensions. Used this as a reference to design internal mounting inserts that will hold the screen and button assembly, since the actual xl tin does not have published measurements the only size measurement is the eBay listing showing it to be 8 inches long, I calculated the size of the other sizes if scaled correctly to make a ratio to multiply part measurements by to get accurate sizes that are to scale in the CAD software.

The inserts are designed to be 3D printable and snap/fit into the tin without permanent modifications to the enclosure.
Models Created
Designed rough internal inserts based on the tin dimensions shown here:

Published STL files showing the inserts both inside and outside the Altoids tin to visualize how they'll fit.

Current Limitations

These are rough estimates since I don't have:

The actual physical tin to measure
The components to test-fit
Exact dimensions for all parts

Once I receive the hardware, I'll need to:

Take precise measurements w/ Caliper
Iterate on the design
Test print and adjust fitment
Add mounting points for specific components

What I Learned

Real CAD is more complex than I expected. Took time to figure out how to properly constrain parts and ensure measurements were accurate. The GrabCAD model was helpful as a starting reference, but I'll need real measurements for the final design.

Next Steps

Wait for grant approval
Order parts
Take precise measurements of actual components
Refine CAD models based on real hardware
Test print inserts
Iterate design based on fit testing

STL files available in repo: GitHub
(requirements.txt was also added to GitHub for Python Scripts)

12/6/2025 4 PM - CAD Refinement & Project Organization

12/6/25

Time spent: 5.2 hours

Today I continued refining the 3D-printed internal mounting system and organized the project structure for Blueprint submission.

CAD Design Progress

Continued work in Fusion 360 on the internal mounting inserts. Built on the initial design from my previous session where I used the GrabCAD model by Mark Simonelli and calculated tin dimensions based on the 8-inch length from the eBay listing.

Made adjustments to component spacing, mounting points, and wire routing channels. The inserts are designed to be modular and snap/fit into the tin without permanent modifications.

Design Challenges

Working without physical components means relying on datasheets and calculated measurements. The current design uses best estimates based on the scaled GrabCAD model. Will need to iterate once I can test-fit actual components.

Project Organization

Python Scripts:

Added requirements.txt to the GitHub repo:

RPi.GPIO>=0.7.0

All test scripts organized in Python-Scripts folder:

• pinout_validator.py – Validates GPIO assignments for conflicts
• generate_button_map.py – Auto-generates RetroPie button configs
• power_button_daemon.py – Monitors GPIO for safe shutdown
• launcher_mock.py – Menu system prototype
• debug_logger.py – Event logging for troubleshooting

Wiring Documentation:

Created detailed ASCII wiring diagram showing:

• All GPIO pin assignments (10 buttons + power + display)
• SPI connections for ILI9341 display
• Power flow: Battery → TP4056 → MT3608 → Radxa
• Pull-up resistor placement for each button

Budget Confirmation

Finalized BOM at $196.70 (including $40 shipping), which qualifies as Tier 2 for Blueprint. Project focus:

• DIY assembly (no custom PCB)
• 3D-printed mounting solutions
• Hand-wiring all connections
• Modular component placement

Next Steps

• Submit for Blueprint Tier 2 grant approval
• Order components once approved
• Print test version of inserts
• Take precise measurements with actual hardware
• Iterate CAD design based on real fitment
• Begin assembly and wiring

Repository updates: GitHub - AltoiDS

12/6/2025 6 PM - Full Wiring & GPIO Routing Specification

12/6/2025

Focus: Hardware planning for electrical layout, GPIO assignments, and power routing

Today I created the full wiring and GPIO routing plan for the AltoiDS handheld. This included defining all button inputs, SPI display lines, the power system layout, grounding strategy, and the physical wire routing inside the enclosure.

System Overview

The wiring plan covers the Radxa Zero 3W, the ILI9341 SPI display, LiPo battery, TP4056 charger, MT3608 boost converter, momentary buttons for controls, the power switch, and optional audio parts. The goal was to create a stable and repeatable wiring layout that works in the small enclosure and keeps signals clean.

GPIO Assignments

I mapped every button to specific Radxa GPIO pins so the routing stays simple once the parts arrive.

Up: GPIO5 (pin 29)
Down: GPIO6 (pin 31)
Left: GPIO13 (pin 33)
Right: GPIO19 (pin 35)
A: GPIO26 (pin 37)
B: GPIO16 (pin 36)
X: GPIO20 (pin 38)
Y: GPIO21 (pin 40)
Start: GPIO23 (pin 16)
Select: GPIO24 (pin 18)
L1: GPIO25 (pin 22)
R1: GPIO22 (pin 15)

All inputs use pull-ups in software and switch to ground. Debounce will be handled in software.

SPI Display

I assigned the ILI9341 screen to the standard SPI0 bus for speed and stability.

SCLK: GPIO11 (pin 23)
MOSI: GPIO10 (pin 19)
MISO: GPIO9 (pin 21)
CS: GPIO8 (pin 24)
DC: GPIO7 (pin 26)
RESET: GPIO27 (pin 13)
VCC and LED on 3.3V, ground to system ground

Power System

Battery connects to the TP4056 on B+ and B−. The charger output feeds the MT3608 boost module, and the boost output goes to the Radxa 5V rail. I planned wire lengths, gauge, and placement to reduce drop during load spikes. Boost will be set around 5.1V.

Grounding and Noise Control

All grounds tie directly back to the Radxa instead of chaining. SPI wires stay short, button wires are routed away from power, and twisting clock and ground will help cut noise. The tin enclosure will only be grounded if later testing shows it improves stability.

Wire Routing Plan

Inside the tin, the plan is:

D-pad on a ribbon cable
ABXY grouped in heat shrink
Power wires along the walls
Button wires around the upper perimeter
SPI wires under the screen with foam for insulation
Wires are kept between 40 and 70 mm with strain relief

Work Completed

Checked Radxa documentation for pin functions, planned all button and display assignments, created the full power wiring plan, set routing rules for each wire group, and confirmed everything fits the enclosure layout.

Conclusion

This session produced the full electrical wiring plan for the AltoiDS handheld, including GPIO mapping, display routing, power system layout, grounding rules, and physical wire paths. This gives me a solid baseline for the actual wiring once the hardware arrives.

*Credit to Radxa Documentation Center

12/6/2025 7 PM - Thermal Analysis and Airflow Study for AltoiDS

12/6/25

For this journal I focused on evaluating the thermal behavior of the AltoiDS system and how heat will move through the enclosure, including passive cooling options, airflow limitations, and whether a vent cutout is necessary. Since the system is built inside a metal Altoids XL tin, heat transfer acts differently compared to plastic cases. The goal of this analysis was to understand where heat will build up, how it will exit the enclosure, and what design adjustments may be needed when the hardware arrives.

Overview

The Radxa Zero 3W, boost converter, chargng module, and display all generate heat inside a small metal enclosure with limited airflow. I used part specs, typical SBC thermal behavior, and heat transfer basics to estimate how the system will behave under a normal gaming workload.

Heat Sources

Radxa Zero 3W
Typical load temperatures range between 55–70°C in open air. In a closed metal tin, this can increase by 10–20°C depending on airflow and where heat accumulates. The CPU and GPU are the largest single heat producers in the system.

Boost Converter (MT3608)

Boost converters run warm under load, especially when stepping battery voltage to 5V at high current. Peak draw for the system can reach around 1A, so the converter can add noticeable heat. Most of this heat comes from switching losses in the inductor and MOSFET.

LiPo Battery

LiPo cells warm slightly during load and charging. They should be isolated from heat sources to avoid long-term degradation. They can tolerate some warmth but should not sit near the boost converter or SBC.

Display

The ILI9341 backlight produces mild heat, but the panel itself is not a major thermal driver. Most of its waste heat dissipates through the glass.

Enclosure Material Analysis

The Altoids tin is thin steel coated with tinplate. This has some unique thermal effects:

• Metal conducts heat quickly, so hotspots spread across the shell instead of staying local.
• The enclosure can work as one large passive heatsink if components are thermally coupled to the lid or bottom plate.
• Because the enclosure is sealed, it traps warm air and reaches equilibrium faster than plastic cases.

Adding Passive Cooling

I have small copper or aluminum heatsinks that will be mounted directly onto the Radxa CPU. These significantly improve thermal performance in confined spaces. The metal lid of the tin can also act as a supplemental heatsink if the thermal gap between the CPU heatsink and the lid is small enough to conduct some warmth.

Airflow Limitations

There is no natural airflow in a sealed Altoids tin. Even with passive heatsinks, warm air inside the enclosure has nowhere to exit unless vents are added. Because warm air rises, most heat will accumulate near the upper side of the enclosure, especially behind the display.

Vent Cutout Analysis

I evaluated whether a vent cutout would meaningfully improve airflow:

• A vent located high in the lid would allow rising hot air to escape.
• A vent along the side could allow cross ventilation if there is enough internal space.
• Cutting the tin weakens structural strength, especially around button or screen areas.

*vent added to cad model 3d inserts

At this stage, I might add a small slit or grille if there is enough unoccupied metal after installing the screen. If not, passive cooling with heatsinks and thermal spacing should be enough for this hardware.

Thermal Management Strategy

Based on the analysis, the cooling plan is:

• Place heatsinks on the Radxa CPU and possibly the boost converter.
• Keep the boost converter physically separated from the battery.
• Leave a small air gap above the CPU heatsink to allow heat to spread through the interior.
• Avoid trapping the battery between heat sources.
• Optionally add a vent if the final assembly shows temperatures climbing too high.

What I Need to Test When the Hardware Arrives:

• Measure real temperature rise inside the tin after 15–20 minutes of emulation.
• Test how hot the exterior shell gets to confirm safe operating temperatures.
• Check whether the boost converter adds more heat than expected.
• Confirm if a vent is needed or if passive cooling alone is enough.
• Evaluate whether thermal pads or foil can improve heat conduction to the lid.

Conclusion

This study establishes the baseline expectations for heat buildup and cooling inside the AltoiDS system. The metal enclosure works both as a thermal conductor and a heat trap, so the final results will depend heavily on component placement and spacing. Once the hardware arrives, I can perform direct testing to finalize the cooling strategy and determine if a vent needs to be added.

12/6/2025 9 PM - Fusion 360 Case Refinements & Support Structure

12/6/25

Today I worked on fixing a major problem with the internal insert design in Fusion 360. The bottom tray had nowhere to actually sit inside the tin.

The Problem

The Altoids tin is completely smooth inside - no ridges, no notches, nothing for the insert to grab onto. If I just dropped the tray in, it would slide around whenever I moved the device or tried to install components. Friction alone wasn't going to cut it.

The Fix: Support Posts

Added support posts to the inside of the case model. These give the tray specific points to rest on so it stays level and doesn't shift around once everything's assembled.

Electrical Isolation Layer

Also modeled a small internal tray that sits between the electronics and the metal tin shell. Since the tin is conductive, I don't want any exposed pins or solder joints accidentally touching it and causing shorts. This tray keeps everything separated and safer.

New Renders

Made some fresh renders showing how it all fits together:

• Case with the new support posts
• Internal isolation tray
• How components will actually sit inside

What Got Done

• Added support structure so the insert actually stays put
• Designed isolation tray for electrical safety
• Cleaned up the CAD files
• Generated documentation images
• Pushed everything to GitHub

Next Steps

• More Pre-liminary testing
• Wait for grant approval
• Test print the insert once I can order parts
• See if the support posts are strong enough or need tweaking
• Adjust sizing based on real hardware fitment

Repository: GitHub - AltoiDS

12/7/2025 - Component Research & Selection Justification

12/7/25

Today I researched different single-board computers and components to figure out what would actually work best for this build. Spent time comparing specs, prices, and whether things would physically fit in the tin.

SBC Comparison

Board	CPU	Clock Speed	RAM	GPU	WiFi	Price	Power Draw
Radxa Zero 3W	Cortex-A55 (4-core)	1.6 GHz	1-8GB LPDDR4	Mali-G52-2EE	WiFi 6	$15-$66	~0.5A
Pi Zero 2W	Cortex-A53 (4-core)	1.0 GHz	512MB LPDDR2	VideoCore IV	WiFi 4	$15	0.46A
Orange Pi Zero 2W	Cortex-A53 (4-core)	1.5 GHz	1-4GB LPDDR4	Mali-G31 MP2	WiFi 5	$13-$24	~2.4W
Libre Le Potato	Cortex-A53 (4-core)	1.5 GHz	2GB DDR3	Mali-450	None	$35	~1W

(credit: Radxa)

Why I Chose Radxa Zero 3W

The Radxa uses newer ARM Cortex-A55 cores instead of the older A53 cores in everything else. It's about 33% faster than the Pi Zero 2W in benchmarks. The Mali-G52 GPU is way better than the Pi's VideoCore IV and supports modern graphics APIs.

The big difference is RAM. Pi Zero 2W only has 512MB, which would struggle with SNES and Genesis games. The Radxa's 8GB gives tons of headroom and won't bottleneck anything.

At 65mm × 30mm, it's also one of the smallest boards with this much power, which matters when fitting everything in a tiny tin.

What I Almost Picked Instead

Pi Zero 2W: Cheapest option at $15 and has the best community support. But 512MB RAM just isn't enough for what I want to run. Would be fine for NES/Game Boy but that's it.

Orange Pi Zero 2W: Really close second choice. Similar performance to Radxa but slightly weaker GPU. Main concern was the 2.4W power draw getting too hot in the sealed tin.

(credit: AliExpress)

Libre Le Potato: Good performance but it's Pi 3 sized (too big) and has no built-in WiFi/Bluetooth. Would need USB dongles which defeats the compact design.

Display Choice

Went with the ILI9341 2.8" SPI display ($7.50) because:

• Actually fits in the tin lid
• Uses only 6 GPIO pins (leaves plenty for buttons)
• Well documented Linux drivers
• Cheap, which leaves budget for better CPU

320×240 resolution is low but works fine for pixel art games from the 8-bit and 16-bit era.

Battery

Picked a 2000mAh LiPo ($9.99). Did some quick math:

• System draws about 5.5W during gaming
• 2000mAh × 3.7V = 7.4Wh
• 7.4Wh ÷ 5.5W = ~1.3 hours runtime

Not amazing but good enough for portable gaming sessions. Bigger batteries wouldn't physically fit in the available space.

Cost vs Performance

The Radxa costs $51 (3.4x more than Pi Zero), but you get:

• 16x more RAM
• 60% faster clock speed
• Way better GPU
• Newer CPU architecture

For what I'm trying to build, the extra cost is worth it. The Pi Zero would limit what games I could actually run smoothly.

What This Can Actually Run

Based on the specs, this should handle:

• NES, Game Boy, SNES, Genesis: Perfect
• Game Boy Advance: Great
• PlayStation 1: Pretty good

Repository: GitHub - AltoiDS

12/10/2025 - BOM Cost Optimization

12/9/25

Today I reworked the Bill of Materials to cut costs by switching most components from Amazon to AliExpress suppliers.

Why the Change

My original BOM came out to $196.70 with most parts from Amazon. That was cutting it close to the Tier 2 budget ceiling of $200, leaving almost no room for adjustments or a custom PCB if needed. After the grant feedback, I needed to find ways to reduce costs while keeping the same quality components.

What I Did

Spent time searching AliExpress for equivalent parts from reliable sellers. Checked reviews, shipping times, and verified specs matched what I need.

Key changes:

• Battery: $9.99 → $7.07 (saved $2.92)
• TP4056 charger: $6.29 → $1.98 (saved $4.31)
• Boost converter: $6.99 → $2.93 (saved $4.06)
• Tactile switches: $8.99 → $7.61 (saved $1.38)
• 6x6mm buttons: $6.99 → $2.38 (saved $4.61)
• Audio jack: $9.99 → $0.72 (saved $9.27)
• Jumper wires: $14.99 → $8.44 (saved $6.55)
• Power switch: $6.00 → $2.50 (saved $3.50)

What stayed the same:

• Radxa Zero 3W 4GB: Found better shipping deal at $52.63 total (was $51 + expensive shipping)
• Display: Kept Elecrow ($7.50) - reliable seller with good documentation
• MicroSD: Kept Amazon ($15) - Samsung brand, fast shipping
• Resistor kit: Kept Amazon ($5.98) - needed the specific 10kΩ values
• Tin: eBay ($15) - no cheaper source for XL size (upgraded the board to a USB-C version too)

Results

Old BOM: $196.70
New BOM: $165.55
Savings: $31.15

This gives me $34.45 of budget headroom under the Tier 2 limit. That's enough to add a custom PCB (~$10-20) if needed to address the reviewer's complexity concerns, or just serves as buffer for unexpected costs.

Trade-offs

Shipping time: AliExpress parts take 2-4 weeks vs Amazon's 2-day. Not ideal but acceptable since I'm waiting on grant approval anyway.

Quality concerns: Checked seller ratings and reviews carefully. The modules (TP4056, MT3608) are all standard chips with datasheets - hard to mess up. The savings are mainly from cutting out Amazon's markup and using direct-from-China shipping.

Returns: If something arrives broken, AliExpress returns are slower than Amazon. Mitigated this by ordering from sellers with 95%+ ratings and thousands of orders.

Next Steps

• Wait for grant approval with new $165.55 budget
• Consider adding custom power management PCB with remaining budget (if denied)
• Parts will take longer to arrive but cost savings are worth it

Repository: GitHub - AltoiDS

2/9/2026 8 PM - Soldered Header to Radxa Zero 3W

2/9/26

Started working on getting the Radxa Zero 3W set up for the AltoiDS build. Ran into an issue where the SD card image got corrupted during flashing. The adapter got bumped during validation and the board wouldn't boot (just black screen with green power LED). Had to re-flash the Radxa OS image completely.
While waiting for the second flash to complete, I soldered the 40-pin GPIO header onto the Radxa Zero 3W. This is necessary for connecting the buttons and controls later. Made sure the header was straight before soldering by clamping it to my helping hand. Soldered opposite corner pins first to lock it in place, then completed the rest of the pins. Used flux to help solder flow, Joints came out fine.
After the re-flash completed successfully, the board booted into Radxa OS and I was able to log in with the default credentials.

Next steps: Install RetroArch and start configuring emulators, then work on the screen setup and button wiring.

2/9/2026 9 PM - Radxa OS Optimization & RetroArch Setup

2/9/26

What I Did

Started optimizing the Radxa Zero 3W's operating system to prepare for the dual-screen handheld build. The board came with Radxa OS (Debian-based with KDE desktop), which needed to be streamlined for gaming performance before installing RetroArch and configuring the emulators.

System Optimization

Disabled unnecessary services to free up RAM and CPU resources for emulation:

Services Disabled:

• CUPS (printing service - not needed on a handheld)
• Samba (file sharing - unnecessary for standalone device)
• Avahi (network discovery - not required)
• Bluetooth (can re-enable later if needed)
• DNSmasq (DNS caching - unnecessary overhead)

KDE Desktop Optimization:

• Disabled KDE compositor to improve frame rates during emulation
• Masked baloo file indexing services (weren't present but prevented future installation)
• Identified resource usage with system monitoring - found Chromium, Xorg, and Plasmashell as main consumers

Current System State:

• 3.9GB total RAM with ~1.5GB free after KDE loads
• CPU load averaging 2.6-3.7 under light desktop use
• Identified Xorg using 26% CPU, which should drop significantly when running RetroArch directly

RetroArch Installation

Successfully located and installed RetroArch from the Radxa OS package repositories:

sudo apt install retroarch retroarch-assets

Emulator Cores Installed:

• libretro-nestopia (NES)
• libretro-snes9x (SNES)
• libretro-genesisplusgx (Genesis/Mega Drive)
• libretro-gambatte (Game Boy/Game Boy Color)
• libretro-mgba (Game Boy Advance)
• libretro-beetle-psx (PlayStation 1)
• libretro-desmume (Nintendo DS - experimental)

This covers all the systems mentioned in my component research journal from December. The Radxa Zero 3W should handle NES through PS1 perfectly, with the 4-core A55 CPU and Mali-G52 GPU providing plenty of headroom.

Display Configuration

Hardware Status:

• 2.8" ILI9341 screen has arrived and is ready for testing (although, after seeing in real life, seems to be quite small compared to the case, may have to request top-off or just buy it myself and use the 2.8" screen to get a true DS experience)
• Will configure framebuffer settings for the display once initial software setup is complete

Next Steps for Display:

1. Test the 2.8" screen with basic framebuffer output
2. Configure display rotation and resolution for optimal viewing
3. Set up RetroArch video output settings
4. Optimize display driver for gaming performance

GPIO Button Integration

With the 40-pin header already soldered (from previous journal), the next phase is button configuration:

Planned Workflow:

1. Wire up buttons according to my GPIO mapping from December journal
2. Test each GPIO pin with Python script to verify connections
3. Map buttons to RetroArch input system using the built-in input configuration
4. Create udev rules if needed for persistent button mapping

GPIO Assignments (from previous journal):

• D-Pad: GPIO 5, 6, 13, 19
• Face buttons (ABXY): GPIO 26, 16, 20, 21
  
• Start/Select: GPIO 23, 24
• Shoulders (L1/R1): GPIO 25, 22

Boot Configuration Planning

Final goal is auto-boot directly into RetroArch for a console-like experience:

Development Phase (Current):

• Keep KDE desktop accessible for configuration and testing
• Launch RetroArch manually to test cores and settings
• Use desktop for file management and troubleshooting

Production Phase (After Testing):

• Configure auto-login to console
• Create boot script to launch RetroArch on startup
• Bypass KDE desktop entirely for faster boot and lower resource usage
• Keep option to access desktop via key combination if needed

What Went Well

• Found RetroArch and all needed cores in the official Radxa repos (no need to compile from source)
• Successfully identified and disabled resource-heavy services
• System is running leaner while keeping the desktop functional for setup work
• Clear path forward for display and button configuration once hardware arrives

Current Blockers

• Need to complete button wiring before input mapping can be tested
• Can't fully test RetroArch performance without ROMs and configured inputs
• Display configuration pending until button controls are working

Next Session Goals

1. Test RetroArch launch and verify cores load properly
2. Source test ROMs for each system to validate emulator performance
3. Begin planning framebuffer configuration for dual displays
4. Start physical button wiring once I have a good testing workflow established

Time Spent

Approximately 2.5 hours on system optimization, package research, and RetroArch installation.

---

Repository: GitHub - AltoiDS

2/11/2026 7 AM - RetroPie Installation & System Setup

2/11/26

What I Did

Spent today trying to get a stable retro gaming setup running on the Radxa Zero 3W. Started with manual RetroArch, ran into issues, and ended up installing RetroPie instead.

RetroArch Struggles

Got RetroArch installed from the Radxa repos along with cores for NES, SNES, Genesis, Game Boy, GBA, PS1, and DS. It launched fine but kept crashing whenever I tried to mess with playlist settings. Pretty sure it was KDE's compositor causing issues since I noticed the desktop alone was eating 26% CPU and almost 300MB of RAM just sitting there.

Tried switching to Openbox to lighten things up, but that created a whole new problem - WiFi wouldn't connect properly. Kept getting "secrets required" errors even though the same network worked perfectly in KDE. At that point I was just wasting time fighting with configs.

Switching to RetroPie

Decided to just use RetroPie instead of manually setting everything up. It handles all the RetroArch configuration, includes EmulationStation for a proper game library interface, and has box art scraping built in.

Installation:

git clone --depth=1 https://github.com/RetroPie/RetroPie-Setup.git
cd RetroPie-Setup
sudo ./retropie_setup.sh

Picked "Basic Install" which compiles everything from source. Takes forever on ARM but at least it'll work properly with Radxa's GPU drivers.

Problem I ran into: KDE kept locking the screen and pausing the compilation every time I walked away. Had to disable auto-lock and sleep so it could actually finish:

xset s off
xset -dpms
systemctl mask sleep.target suspend.target

The install is still running - currently compiling the N64 emulator. Gonna take several more hours since it's building everything from scratch.

What Actually Worked

• Found all the emulator cores I need in the official repos
• Figured out KDE is way too heavy for what I'm building
• RetroPie should give me EmulationStation with controller setup and ROM management already done
• Learned that screen locking will pause long compile jobs (annoying but good to know)

Next Steps

• Wait for RetroPie to finish compiling
• Test EmulationStation and make sure it works
• Copy over some ROM files to test
• Wire up the GPIO buttons and configure inputs
• Get the 2.8" display working
• Eventually set it to auto-boot into EmulationStation instead of the desktop

Repository: GitHub - AltoiDS

2/11/2026 9 PM - RetroPie Finally Working (Mostly)

2/11/26

What I Did

Spent way too long getting RetroPie to actually install and run. Had to fix a bunch of broken dependencies, fight with EmulationStation to recognize my keyboard, and figure out what systems actually got installed vs what I'm still missing. Got it working and tested some games.

The Dependency Nightmare

So the RetroPie installer just kept crashing with errors about missing packages. Kept saying it couldn't find flex, bison, and libglew-dev and a bunch of git clones were failing. Had to manually install the build tools:

sudo apt install flex bison libglew-dev build-essential git cmake libsdl2-dev

After that it actually worked. Took forever to compile everything but at least it didn't error out halfway through this time.

EmulationStation Being Weird

First time I launched EmulationStation it just sat there saying "no gamepads detected" and completely ignored my keyboard. Spent like 20 minutes trying different things before it finally decided to accept keyboard input. Once it worked I could actually navigate menus and set up controls.

Found out RetroPie installed way more systems than I expected - there's like 20+ folders for different consoles. Got the main ones I care about (NES, SNES, Genesis, N64) plus a bunch of random stuff I've never heard of.

Game Boy Advance, regular Game Boy, and PlayStation 1 didn't install automatically though. Tried adding Nintendo DS from the experimental packages but it failed - the Radxa repos don't have the pre-compiled core and it won't build from source. Gonna skip DS for now anyway since the dual screen thing is gonna be complicated.

ROM Testing

Copied ROMs over to the RetroPie folders for NES, SNES, Genesis, and other systems that got installed. Tested NES games and everything works - emulation runs smooth, no major issues. Still need to add GBA and DS ROMs once I get those emulators installed.

Current State

EmulationStation is working and games are actually playable. NES tested and confirmed working. The main systems are good to go, just missing GBA, GB/GBC, and PS1 which need to be installed separately.

Next Steps

• Install the missing GBA/GB/PS1 emulators
• Test performance on SNES and Genesis games
• Wire up GPIO buttons for real controls instead of keyboard
• Get the 2.8" display working
• Set up auto-boot straight to EmulationStation

Hours here are just the active work - RetroPie compilation ran overnight so most of the time was just waiting for things to compile while I did other stuff.

Time Spent

3.5 hours

---

Repository: GitHub - AltoiDS

2/12/2026 - ROM Testing & Emulator Setup

2/12/26

What I Did

Loaded ROMs into EmulationStation, tested games across different systems, fixed SNES emulator issues, and got GBA working. Also changed the EmulationStation theme to something that'll look better on a small screen.

Loading ROMs

Copied ROM files into the RetroPie folders for NES, SNES, Genesis, GBA, and the other installed systems. Had to organize them by console since EmulationStation expects specific folder structures.

Testing Games

Started testing games on different systems to make sure emulation actually works:

NES: Works perfectly, no issues. Games run smooth.

SNES: Had a problem where every game would open but throw a "Romset is unknown" error. Turned out the only emulator option was fbneo, which is an arcade emulator, not a SNES core. Had to install the actual SNES emulator (lr-snes9x) through RetroPie's package manager. After that SNES games worked fine.

GBA: Works great, no issues.

Didn't get to test everything yet but the main systems I care about are all functional now.

EmulationStation Theme

Changed the theme from the default to SNES Mini. Looks way cleaner and should work better on the small 2.8" screen once I get that set up. There's also a TFT theme specifically designed for tiny displays that I might try later.

What Worked

• Got all the ROMs organized and loaded
• Fixed SNES by installing the correct emulator core
• NES and GBA confirmed working with good performance
• Found a better theme for small screens

Next Steps

• Install PS1 and remaining emulators
• Test more games to check performance
• Start working on the 2.8" display configuration
• Wire up GPIO buttons for actual controls
• Set up auto-boot to EmulationStation

Time Spent

2.4 hours

---

Repository: GitHub - AltoiDS

2/13/2026 4 PM - Installing more emulators, Partial GPIO Setup

2/12/26

This session was all about expanding my retro gaming handheld's software capabilities and starting to work on the physical GPIO button setup.

Emulator Installation & Configuration

I installed PlayStation 1 emulation using lr-pcsx-rearmed through the RetroPie setup menu. Had to navigate through the package management system and figure out the difference between main packages and optional packages. PS1 was a priority since the Radxa Zero 3W can handle it pretty well, and honestly, the game library is amazing - Tony Hawk's Pro Skater 2, Crash Team Racing, Metal Gear Solid, all the classics.

I also got Game Gear emulation set up, which uses the same lr-genesis-plus-gx core as Genesis and Master System. Ran into this weird issue where the ROM files kept throwing "insert last multi volume disk" errors even though they looked like normal single ZIP files. Turns out the files were corrupted or something. Eventually learned that emulators can just run compressed ROMs directly anyway, so I didn't even need to extract them.

System Compatibility Research

Spent a good chunk of time researching which console systems would actually run well on the Radxa Zero 3W's hardware (1.6GHz quad-core ARM, 4GB RAM, Mali-G52 GPU). Had to understand the performance requirements of different emulators and the limitations of ARM-based single board computers.

What I found:

• Runs perfectly: NES, SNES, Genesis, GBA, GB/GBC, PS1, Game Gear, arcade games
• Hit-or-miss: N64 (really depends on the game, needs frameskip), Dreamcast (demanding but might work), Sega Saturn (experimental)
• Won't work: GameCube, PS2, 3DS, Switch (way too demanding for this hardware)

The N64 situation is interesting - emulation is super game-specific. Something like Super Mario 64 might run at 20-30fps with frameskip, but demanding games like GoldenEye just won't run well at all. What's weird is that N64 emulation can actually perform better than DS emulation sometimes, even though the DS is technically less powerful hardware. This is because DS emulation with DeSmuME has to handle dual screens, touch input, and more complex ARM CPU emulation all at once.

I also put together lists of must-have games for each system - GBA, GB/GBC, PS1, Game Gear, and N64. Figured out what games would actually be worth playing on this thing.

GPIO Button Setup (Initial Work)

Started working on GPIO button configuration for the physical controls. This is basically the bridge between software and hardware - mapping the physical buttons that'll be wired to the Radxa's GPIO pins to controller inputs that EmulationStation and RetroArch can understand. Pretty essential for the handheld to actually function without needing an external controller.

The GPIO work involves figuring out:

• Which GPIO pins are actually available on the Radxa Zero 3W
• How to configure button mappings in RetroArch
• Testing button inputs before doing the full hardware assembly

Challenges & Problem-Solving

That Game Gear ROM extraction issue taught me about file corruption and multi-volume archives. Instead of wasting hours trying to fix the extraction, I learned that emulators can just run ZIP files directly, which is actually more efficient anyway.

Understanding system compatibility meant I had to balance what games I wanted against what the hardware could actually handle. Had to adjust my expectations - like realizing that while N64 is technically installed, it's not going to provide a great experience for most games. Better to focus on the systems that run flawlessly. (edit: N64 actually runs pretty good, at least for the games i chose to install that I thought it was capable of.)

Next Steps

• Keep working on GPIO button configuration and test the physical controls
• Fix the DS emulation white screen issue when launching from EmulationStation
• Add more ROM libraries for the newly installed systems
• Test GPIO button mappings with actual gameplay

Time spent: Around 4-5 hours

What I Learned

Hardware limitations are super important for retro gaming projects. It's better to have 6 systems that run perfectly than 10 systems where half of them are stuttering and basically unplayable. ARM-based emulation is really different from x86 PC emulation - what works great on a desktop won't necessarily translate to a single board computer. The maturity and optimization of individual emulators matters way more than the raw power of the original console when you're figuring out what will actually run well.

2/13/2026 10 PM - Custom Boot Splash & Branding

2/13/26

What I Did

Designed a custom boot splash screen and project banner based on the Altoids tin aesthetic. Spent time creating graphics that match the retro handheld theme.

Boot Splash Design

Created a custom splash screen that mimics the Altoids tin design with project branding. The design includes:

• Classic Altoids tin styling with red background
• "ALTOIDS" in the signature yellow/black font
• "Curiously Strong Emulation" tagline (playing on the original Altoids slogan)
• Retropie logo (replacing peppermint icon)
• "RETROPIE" branding (different font, replacing the flavor name)
• "With Other Digital Emulators" text (replacing the original natural flavors text)

The goal was to make something that looks clean on boot and ties the whole vintage tin concept together. This will show up when the handheld powers on before EmulationStation loads.

Blueprint Banner

Used the same design as the project banner but with formatting tweaks for the Blueprint page.

Display Testing

Got the 2.8" display wired up and powered on - currently shows a white screen which means it's getting power and signals, just needs driver configuration. Wired according to the GPIO plan from December:

• VCC to 3.3V
• GND to ground
• CS, RESET, DC, MOSI, SCK to their respective GPIO pins

Next step is configuring the SPI driver to actually display graphics instead of just white.

What Worked

• Created cohesive branding that fits the project theme
• Display hardware successfully connected and powered
• Graphics are ready to use once display driver is configured

Next Steps

• Configure SPI display driver to get the screen working properly
• Install the boot splash once display is functional
• Continue wiring GPIO buttons
• Test button inputs

Time Spent

1.2 hours

---

Repository: GitHub - AltoiDS

2/15/2026 - Display Driver Configuration & Troubleshooting

2/13/26

What I Did

Spent several hours trying to get the 2.8" ILI9341 SPI display working with the Radxa Zero 3W. Got the hardware wired and SPI bus enabled, but ran into extensive driver compatibility issues.

Enabling SPI Bus

The Radxa Zero 3W doesn't have SPI enabled by default. Had to enable it through device tree overlays:

Process:

1. Found SPI overlay files in /boot/dtbo/ - all were disabled by default
2. Used rsetup to manage overlays but the SPI0 overlay wasn't showing up in the menu
3. Manually enabled SPI0 by editing /etc/kernel/cmdline to add the overlay
4. Ran sudo u-boot-update to apply changes
5. After reboot, /dev/spidev0.0 appeared confirming SPI bus was active

This took a while to figure out since Radxa's overlay system works differently from Raspberry Pi.

Driver Attempts

Tried multiple approaches to get the display driver working:

Attempt 1: fbcp-ili9341
Cloned and tried to compile fbcp-ili9341 (framebuffer copy driver designed for small SPI displays). Build failed with ARM architecture errors - the tool is optimized for Raspberry Pi and doesn't compile properly on Radxa's RK3568 chip.

Attempt 2: fbtft kernel modules
Tried loading fbtft (framebuffer TFT) modules directly but they weren't available in Radxa's default kernel. Attempted to build them from source but ran into missing dependencies.

Attempt 3: Plymouth boot splash
Got sidetracked trying to configure Plymouth for a custom boot splash, but Plymouth services weren't properly configured on Radxa OS. Decided to skip this for now.

Attempt 4: Device tree overlays
Found that Radxa has pre-built overlays for Waveshare displays (which use similar ILI9341/ILI9486 chips). Enabled the Waveshare 3.5" overlay through rsetup, which successfully created /dev/fb1 (second framebuffer device).

Attempt 5: Driver mismatch
Problem: The Waveshare overlay loaded the ILI9486 driver, but my display uses the ILI9341 chip. Writing test patterns to /dev/fb1 resulted in a white screen - the wrong driver can't communicate with the hardware properly.

Current Status

• SPI bus is enabled and working (/dev/spidev0.0 exists when SPI overlay is active)
• Framebuffer device /dev/fb1 is created when Waveshare overlay is enabled
• Display powers on and shows white screen (backlight working, power good)
• Kernel has fb_ili9341.ko module available in /lib/modules/
• Successfully loaded ILI9341 module but can't bind it to the display hardware

The core issue: The Waveshare device tree overlay is hardcoded to use ILI9486. Simply loading the ILI9341 kernel module doesn't rebind it because the device tree already claimed the SPI bus with the wrong driver. Would need to either:

1. Decompile and modify the .dtbo file to use ILI9341 instead
2. Create a custom device tree overlay from scratch
3. Wait for different display with better driver support

What I Learned

• Radxa's overlay system uses rsetup + u-boot-update instead of /boot/config.txt
• Device tree overlays control hardware initialization at boot, not just kernel modules
• SPI displays need matching drivers - can't just swap one for another
• The RK3568 chip has fbtft drivers built in, which is good for future attempts
• Driver architecture on ARM SBCs varies significantly between manufacturers

Challenges

• Driver compatibility between Raspberry Pi focused tools and Radxa hardware
• Device tree overlay configuration is more complex than expected
• Limited documentation for SPI displays on Radxa boards specifically
• Can't easily modify pre-compiled device tree overlay files

Next Steps

• Look into creating a custom device tree overlay for ILI9341
• Alternative: rewire to different pins that have working display overlays
• For now, moving on to GPIO button configuration which is more straightforward

The display hardware is wired correctly and the kernel has the right drivers - it's purely a device tree configuration issue that will require more advanced debugging or different hardware.

Time Spent

3.5 hours

---

Repository: GitHub - AltoiDS

2/16/2026 - System Configuration & Power System Wiring

2/16/26

What I Did

Got a bunch of system configuration stuff sorted out - WiFi file sharing, auto-login, boot settings - and started wiring up the power system.

WiFi ROM Transfer (Samba)

Set up a Samba share so I can transfer ROMs directly from my Windows PC over WiFi without needing a USB drive every time. Took a while to get working - tried a few different approaches before it clicked.

My computer now has a network drive mapped directly to the RetroPie ROM folders. Now I can just open File Explorer on Windows, navigate to the share, and drag ROMs straight into the right folder. Way more convenient than unplugging SD cards or USB drives.

Boot & Login Configuration

Spent time trying to get the system to boot seamlessly without any password prompts or interaction needed. The goal is: flip the power switch, device turns on, goes straight to EmulationStation.

KDE Wallet: Disabled the password prompt for KDE Wallet which was asking for a password every boot to unlock WiFi credentials. Set it to use an empty password so WiFi connects automatically without any interaction.

Auto-login: Configured SDDM (the login manager) to auto-login as the radxa user. This took a few attempts - had to create the config file manually since it didn't exist:

sudo mkdir -p /etc/sddm.conf.d/
sudo nano /etc/sddm.conf.d/autologin.conf

Added:

[Autologin]
User=radxa
Session=plasma

EmulationStation Auto-start: Configured EmulationStation to launch automatically on login through KDE's autostart system. Now boots straight into the game library without needing to manually launch anything.

Challenges:
Ran into a few issues during boot config - accidentally broke the desktop environment at one point by misconfiguring the display manager. Had to re-enable SDDM and restore the desktop session. Learned that systemd service symlinks need to be removed before re-enabling services.

Power System Wiring

Started wiring up the power system using the TP4056 charging module and MT3608 boost converter.

Power flow:
Battery → TP4056 (charging/protection) → MT3608 (boost to 5V) → Radxa

Wiring completed:

• LiPo battery (2000mAh) connected to TP4056 B+ and B-
• TP4056 OUT+ connected to MT3608 VIN+
• TP4056 OUT- connected to MT3608 VIN- Voltage adjustment: Used a multimeter to measure the MT3608 output voltage and adjusted the potentiometer (trim pot) to set the output to 5.1V. The 5.1V gives a small buffer to account for voltage drop in wires while still being safe for the Radxa.

Current status:
Power system is fully wired and tested - battery charges via micro USB on the TP4056, boost converter outputs stable 5.1V. Haven't connected to the Radxa yet since I need to figure out the best connection point (GPIO 5V pins vs USB-C power port).

What Worked

• Samba file sharing working from Windows
• KDE Wallet no longer prompts for password on boot
• Auto-login configured, boots straight to desktop then EmulationStation
• Power system wired and outputting correct 5.1V
• Boost converter potentiometer adjusted successfully

Current Blockers

• Need to connect power system to Radxa (deciding between GPIO pins vs USB-C)
• Display driver still not working (ongoing issue from previous session)
• GPIO buttons still need software configuration

Next Steps

• Connect power system to Radxa and test battery-powered boot
• Configure GPIO buttons for game controls
• Continue display driver troubleshooting
• Test full system on battery power

Time Spent

3.8 hours

---

Repository: GitHub - AltoiDS