RG34XX / muOS ENGINEERING NOTES

Engineering notes — RG34XX port

How do you adapt a game to a handheld without changing its identity? Explore controls, presentation timing and the tests behind the choices.

Start with a topic below. The source files and full measurements are one level deeper.

01 / CONTROLS

How are port settings kept separate from gameplay?

The reference keeps port instructions off the game image. Settings remain available through MENU+R2; MENU+L2 returns to muOS.

The GBA controls stay assigned to gameplay. These additional shortcuts use the handheld's extra controls, rather than repurposing the game's buttons.

Lesson: make platform functions accessible without making them part of the game's presentation. The player can reach settings when needed while the gameplay image stays clear.

Read the control changes and supporting record

02 / TIMING

Does a faster screen make the game faster?

Not necessarily. Game logic updates the world. Screen refresh displays images. They do not have to run at the same rate.

This project records game logic near 59.7275 Hz and a screen mode near 119.455 Hz. It does not claim 120 FPS game logic.

The P11.4 change schedules presentation once per logic period. The resulting trace still contains ticks with zero or two presentations.

Lesson: measure actual behaviour rather than describing a scheduling rule as a guaranteed result.

Show the measured comparison

The two captures contain 10,203 and 10,449 ticks. Their p95 lateness is 5.790787 and 0.027887 ms.

The p95 is the threshold containing about 95% of values. The largest presentation duration increased from 46.450584 to 60.917250 ms.

There is one capture per variant. Identical scenes and randomised order were not established.

Read the full table and measurement definitions

03 / AUDIO

Can audio measurements and listening disagree?

They can record different aspects of the same work. Timing counters measure execution. A listening check records what the tester heard.

The earlier 1,600-frame machine test reported AUDIO1600_MACHINE_AUDIO_REGRESSION. The later manual acceptance reports audio OK.

Lesson: keep both observations. Do not replace a negative test with a later positive summary.

Show the audio details

The largest callback gap rose from 62.2 to 168.8 ms. The p95 of each window's maximum audio work fell from 30.79 to 26.53 ms.

The A53 patch changes one enhanced-resampling branch to LINEAR. The gbaAccurate branch retains NEAREST.

The launcher requests 1600 frames but prints 1920. Neither message alone proves the device's effective buffer size.

Read audio results · Read the buffer discrepancy

04 / TESTING

Why does the test setup matter?

A remote-shell launch and a normal handheld menu launch can leave different background conditions.

The later AutoLab procedure uses a normal muOS Ports session and deterministic replay. That procedure must not be assumed for the earlier timing pair.

Lesson: describe the setup actually used before comparing the results.

The final acceptance records one manual session and two preceding automated soak runs. These are not three full playthroughs.

Read the benchmarking lesson · Inspect acceptance and sample sizes

05 / OPEN QUESTIONS

What still needs investigation?

The records retain conflicting audio-buffer messages, autosave activity and a different CPU governor after exit. Pointer warnings also remain.

Their causes remain unresolved. Investigation needs to connect each message to its code path and effective runtime value.

One comparison records a 5.3 °C higher maximum temperature. Energy values are null. Lower clocks alone cannot establish energy savings.

Lesson: an accepted configuration can still have documented limits.

Read each observation and what is still unknown

06 / USE THE KNOWLEDGE

How can you use this knowledge?

Find the matching problem. Read the change and its limits. Inspect the source before adapting the idea to another platform.

Use a separate copy for experiments. A successful result on this handheld does not automatically apply elsewhere.

Look up a term · Browse all lessons · Check rebuild requirements

Found an unclear passage? Include its title and the missing explanation in a GitHub issue.

Supporting records and review scope

Analysis date: 7 September 2026. Method: reanalysis of archived device sessions.

Integration patches and launcher

Runtime records and log excerpts

Timing and monitor calculations

Dated workflow notes

Full raw traces remain in the private archive. The public extract supports inspection, but not every numerical recalculation.