Can't run Wolf 3D and Duke Nukem 3D on iPod 5.5G 30GB

[GCRaistlin]

I have 2 iPods 5.5G 30GB and iPod 5.5G 80GB. I installed Rockbox 3.15 on all of them. Wolf 3D works OK on my 80GB iPod but doesn't work on both 30GB iPods:

Code: [Select]

Can't open /.rockbox/rocks/games/wolf3d.ovlThis file exists and is idenctical to the one on 80GB iPod. The same situation with Duke Nukem 3D.

[Frankenpod]

Could it be to do with the fact that the 30gb model has 32mb on-board RAM vs 64mb on the 80gb one?

[dreamlayers]

Yes. The problem is that there is a single build for the Video iPod for both 32 MB and 64 MB memory. The memory is initially set to 64 MB. This causes the overlay header to ask for it to be loaded into non-existent memory on iPods with 32 MB. Take a look at apps/plugins/sdl/wolf3d.refmap created when building.

I was able to get Wolf 3D to run by first building normally, then editing Makefile, changing to MEMORYSIZE=32, and rebuilding wolf3d.ovl. Then copying apps/plugins/sdl/wolf3d.ovl to /.rockbox/rocks/games/wolf3d.ovl on the iPod made Wolf 3D run.

Edit: The procedure to do this after a build is complete, in the build directory:

Code: [Select]

sed -i s/MEMORYSIZE=64/MEMORYSIZE=32/ Makefile
rm apps/plugins/overlay_ref.link
make
Verify the result via:

Code: [Select]

grep PLUGIN_RAM apps/plugins/sdl/*.refmapYou should see:
PLUGIN_RAM       0x0000000000000000 0x0000000001e80000
and not:
PLUGIN_RAM       0x0000000000000000 0x0000000003e80000

Wolf3D, Duke3D and Quake all worked for me, though I had a data abort when exiting Quake.

[__builtin]

This seems like something that we should configure at compile time (or maybe at load time). I haven’t dug too deep, but it looks like tools/configure sets it to 64 MB by default, and it says it’s detected at runtime.

So perhaps the overlay loader needs to be smart enough to load into the right memory region depending on 32/64?

Does anyone know where/how the memory size detection works?

[__builtin]

Did some digging... looks like the probing takes place in `firmware/target/arm/pp/crt0-pp.S`, and the detected size eventually makes its way into `unsigned char probed_ramsize`, which is equal to either 32 or 64.

The allocator code (`core_alloc.c`) then detects if the memory size is 32 MB, and decreases the audio buffer length accordingly by subtracting 32 MB.

It looks like we won't be able to fix this at compile-time, so we need to do it at load time. I think we could adjust the load address in `load_code.c` to be 32 MB less if it lies in the second 32 MB bank, but I don't know if the plugin code itself is position-independent and able to handle this. Does anyone have ideas as to how to best fix this?