- Status New
- Percent Complete
- Task Type Bugs
- Category Games
- Assigned To No-one
- Operating System iPod 5G
- Severity Low
- Priority Medium
- Reported Version Release 3.15
- Due in Version Undecided
-
Due Date
Undecided
-
Votes
1
- theunamedguy (2023-01-01)
- Private
FS#13376 - SDL games can't open overlay on 5G Video iPod with 32 MB RAM
There are variants of the 5G Video iPod with 32 MB and 64 MB RAM. Rockbox makes one build, with memory size set to 64 MB. This is a problem for SDL game overlays, because their location in memory depends on memory size. They’re built for 64 MB memory, and Rockbox will refuse to load them into non-existent memory on an iPod with 32 MB memory. The workaround is to set the memory size to 32 MB and rebuild them. In the build directory, after a build is complete, you can do:
sed -i s/MEMORYSIZE=64/MEMORYSIZE=32/ Makefile
rm apps/plugins/overlay_ref.link
make
Verify the result via:
grep PLUGIN_RAM apps/plugins/sdl/*.refmap
You should see:
PLUGIN_RAM 0×0000000000000000 0x0000000001e80000
and not:
PLUGIN_RAM 0×0000000000000000 0x0000000003e80000
After this, Wolf3D, Duke3D and Quake all worked for me, though I had a data abort when exiting Quake.
This is on Rockbox 3.15. I’ve also downloaded rockbox-ipodvideo-20221120.zip and confirmed the problem exists there, but II don’t have the new toolchain, so I didn’t experiment with that build.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
After some discussion on IRC (https://www.rockbox.org/irc/log-20221216#17:24:41), I've decided the best way of properly fixing this is to change the ipodvideo memory layout to assume 32 MB by default, and to only expand the audio buffer to the high 32 MB bank at runtime. This is the opposite of the status quo (which assumes 64 MB and shrinks to 32 MB at runtime).
I think nothing bad should happen if we do this - as long as the executable still loads into the low 32 MB, we'll be able to expand the audio buffer to the full 64 MB on devices with the expanded memory and use that memory for buffering/plugin overlays/etc.
(As an aside, this issue arises mostly because the plugin overlay architecture insists on loading the overlay text into the _end_ of the audio buffer.)