💾 Archived View for s73.girv.in › glog › 2024 › 2024-01-15-cdtv-bug-hunt.gmi captured on 2024-05-12 at 15:09:14. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

CDTV Bug Hunt

15 January 2024

The Rogue Declan physical releases are coming up and one of those will be an actual CD aimed at CD32, but I wanted to see if I could get the game running on the CDTV as well. With 1Mb RAM and Kickstart 1.3 it meets the system requirements (just), but booting the game on this hardware took much longer than expected.

Even though it worked perfectly on emulators, and even a real CD32, the CD game crashed or otherwise misbehaved when run on the one real CDTV I had available for testing. Worse than that, the crashes were random and made no logical sense.

After burning through a stack of test CD-Rs, we (LinuxJedi and I) finally nailed down what was going on.

[IMG: CDTV with a stack of CD-R]

The problems were caused by many ingame variables having random values on startup. However, this required a chain of circumstances to be in place before it manifested, which is why it took so long to figure out.

Deep breath.

The executable had hunks with an allocation size larger than their load size, ie: they would use more RAM than data loaded from disk, and the unused RAM would not be changed by the loading process. This was unexpected. The non-loaded areas are where the compiler places the variables.

Kickstart 1.3 is well known not to zero-initialise BSS hunks in loaded executables, but as the game executable didn't have any BSS hunks it would seem this wasn't the issue. Thinking about it though, it would make sense that no hunks are zero-initialised as they are all loaded with the LoadSeg() OS call. I didn't confirm this by looking at a ROM disassembly, but it makes sense. Why would BSS, of all things, be a special case?

The executable had custom startup code. I didn't realise the standard C runtime startup code zero-initialised the variable area, so with the custom code this process was being skipped.

Kickstart has a power on memory test that effectively zeros all of Chip RAM, so any uninitialised hunk memory located in this area would actually be zeroed. However, the test CDTV also had Fast RAM! So variables were being set to whatever values were in this RAM at load time. Usually zero, but after a warm boot it contained effectively random data.

CD32 was fine because it boots to Kickstart 3.x, which zeros all hunk memory on load. The ADF versions were fine because they use a custom executable loader that zeros memory and doesn't allow for uninitialised hunk memory in any case.

So the issue would only manifest on a Kickstart 1.3 machine, having Fast RAM, using the normal OS executable loader, after a warm reboot (or several). Out of all the Amiga configurations Rogue Declan supports, only an expanded CDTV or A500 with an A570 would have problems.

I was very happy to finally solve this one!

A stock CDTV currently boots the game with about 16Kb of RAM free, but that's another battle.

CDTV Bug Hunt

Related Links

Tags