This is being cause by either an ARM erratum or the variables within the codelet for LDMIA R13!,{R0-R2,PC} @ 2CB68 getting corrupt. When the codelet exits via LDR PC, return_address; return_address has changed from 2C470 to 110 - which coincidentally is the value of R0 on entry.

EDIT: Another possibility is IRQ stack corruption, although unlikely inside a channel handler.

Reencoding the instruction as two instruction, one to load everything except PC and the second to load PC works around the issue - but doesn't really help locate root cause. What I have established is that [R13, #12] is 20000112 when it crashes.

EDIT2: Doh..having wasted over a day thinking there's something wrong within ADFFS, it's just dawned on me that BlastOn's voice is using BL. This isn't allowed within a voice as IRQ are enabled and as a consequence R14 can't be used. I'll correct the code, which will hopefully fix the issue.

@Jon: BlastOn has music during gameplay, but the main character does not move at all now. It used to move using Z-X etc. Now it won't move with ANY key on the keyboard. I am using the Eterna version with F1064001 ID code, and the latest 2.61r beta from the dev site.

Also, Cannon Fodder does not exit clearly anymore: it leaves last sample sounding, and the "press any key or mouse button to continue" message is missing now. That's from floppy, no outdated scripts this time.

Vanfanel wrote:@Jon: BlastOn has music during gameplay, but the main character does not move at all now. It used to move using Z-X etc. Now it won't move with ANY key on the keyboard. I am using the Eterna version with F1064001 ID code, and the latest 2.61r beta from the dev site.

I fixed that a few mins after uploading and then reuploaded , you may have grabbed the file before I'd fixed it. Updating obey.zip should resolve it.

Vanfanel wrote:Also, Cannon Fodder does not exit clearly anymore: it leaves last sample sounding, and the "press any key or mouse button to continue" message is missing now. That's from floppy, no outdated scripts this time.

SoundDMA has crashed then, which leaves the system in an unstable state. I've not managed to repro this, does it do it every time? At what point are you quitting?

Ironically, I was trying to figure out how to recover from a SoundDMA crash yesterday, but it really breaks the Pi in such an unstable state, the only fix is a reboot.