Rockbox

  • Status New
  • Percent Complete
    0%
  • 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
  • Private
Attached to Project: Rockbox
Opened by dreamlayers - 2022-11-20

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.

Admin
Warning: Undefined array key "useheading" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 1099 Warning: Undefined array key "target" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557 Warning: Trying to access array offset on value of type null in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557

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.)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing