Conqueror on Pi using ADFFS

[sirbod]

"FX 20" to reset the font.

Look further up in the codelet for the source address, it will be before the variable block. The exit address isn't much use as it's probably wrong.

Also remember the source address will be +8 due to pipelining.

[jms2]

Thanks - I'm enjoying this and still remain quite optimistic that I might find what's wrong. Any anyway, learning a bit of ARM code is a good thing.

[jms2]

I have probably reached the limit of my understanding, but just in case...

This is the contents of memory just before the instruction that aborts (the last line). I think the codelet is entered at &10FCA80 and stores R1 at &10FCA7C (the value being &A3FC). Then it reads the CPSR into R1 and stores it at &10FCA78. Then it tries to load R1 with whatever value is 108 bytes down from whatever R0 is pointing to, which isn't a valid address (or so it would seem).

I can't find valid code at any of the addresses before the codelet, ie &10FF4C0, &10FD0C0, &110CCF0 or &A3FC. Or should I be looking much further up?

I'm not sure whether its the JIT R0 or the real R0 that is relevant, but both of them are pointing to invalid addresses, so that explains why it is aborting. The JIT R0 is the same as real R1, which I assume is expected. The real R0 is set to &6D01315C.

Anyway, I'm happy to put this in the "too difficult" category but I thought it was worth raising just in case it points to a flaw in ADFFS rather than an oddity with my copy of Zarch.

[sirbod]

You can ignore A3FC, that's just the value of R1 before the codelet was entered.

What I can't see from the photo is the source instruction address, which is further up, or what the codelet is doing which is further down. The codelet looks like it might be replacing LDR PC, [R0, #-108] from the first few instructions, so might be the game calling the baddie code?

1100000 and above is the JIT translated code, which will have been flushed when the JIT shut down - JITSHOWREGS will shut the JIT down, so avoid using it if you want to poke around in the translated code. Just drop the 11 from the front of any address to get the corresponding source address. ie 1108000 is the translated instruction from 8000

Addresses between C00000 and 1100000 are codelets, which will only ever be entered from translated code above 1100000 via a B or BL instruction.

[jms2]

I had a good look further up Jon, but I found nothing. However, based on what you've said I think CCF0 may be the source address, as &110CCF0 is stored in &10FCA74.

At &CCF0 in the original code I find LDMIA R13!,{R6-R12,PC}. This is in a block of valid code. But you said earlier that this is the address +8, so stepping back a bit I get:

CCE8 ADD R0,PC,R0,LSL #2
CCEC LDR PC,[R0,#-108]
CCF0 LDMIA R13!,{R6-R12,PC}

And the translated code:

110CCE8 B &010FCB00 \ Translated code from originating address (&CCF0-8)
110CCEC B &010FCA80 \ This is a jump to the address where the crash occurs
110CCF0 B &010FD100

If the offset is +4 rather than +8, then it looks like the original instruction is LDR PC,[R0,#-108] and it is being substituted by the codelet at &10FCA80, which clearly does something relevant.

[sirbod]

based on what you've said I think CCF0 may be the source address

CCEC is the source instruction of the codelet.

CCE8 ADD R0,PC,R0,LSL #2
CCEC LDR PC,[R0,#-108]
CCF0 LDMIA R13!,{R6-R12,PC}

And the translated code:

110CCE8 B &010FCB00 \ Translated code from originating address (&CCF0-8)
110CCEC B &010FCA80 \ This is a jump to the address where the crash occurs
110CCF0 B &010FD100

If the offset is +4 rather than +8, then it looks like the original instruction is LDR PC,[R0,#-108] and it is being substituted by the codelet at &10FCA80, which clearly does something relevant.

110CCE8 is the JIT instruction for CCE8, which branches to the codelet at 10FCB00. 110CCEC is CCEC etc.

My guess would be R0 is corrupt when CCE8 is executed, which results in CCEC branching to an invalid address. I’d have to look at the source, but it does look like the baddie code handler.

A wild stab in the dark, but try zeroing memory before the *GOARM3JIT 0 line in the Obey file. I don’t recall what the * command is offhand, but you’ll find it via *HELP Debugger

[jms2]

I think it's *InitStore ... I'll give it a go!

When you say "baddie code", do you mean the code that handles the enemy ships? The crash occurs on the title screen just before the spaceship zooms into view. I can't remember if its the player ship or an enemy ship.

[sirbod]

do you mean the code that handles the enemy ships?

I've now checked the source code and its the buffer flush code that's crashing:

Code: Select all

.Buftable    :]:FOR I%=0 TO depth:[ OPT Z: EQUD Graphbuf+Glen*I%: EQUD Graphbuf+Glen*(I%+1)-9*4:]:NEXT
...
.BuftableV EQUD Buftable
...

.flushcalls
           EQUD PixelL2  : EQUD PixelL2: EQUD PixelL2: EQUD PixelL2
           EQUD PixelL2  : EQUD PixelL2: EQUD PixelL : EQUD PixelD : EQUD Pixel
           EQUD PixelD2  : EQUD PixelD2: EQUD PixelD2: EQUD PixelD2
           EQUD PixelD2  : EQUD PixelD2: EQUD PixelD : EQUD PixelD : EQUD Pixel
           EQUD triangle2: EQUD finish


.FlushbufR0 \ flush graphic buffer no. R0

      STMFD SP!,{R6-R12,R14}
      LDR R1,BuftableV: LDR Rptr,[R1,R0,ASL#3]
      LDR RSC,SCbasV
.fl1  LDR R0,[Rptr],#4
      ADD R0,PC,R0,LSL#2: LDR PC,[R0,#FNR(flushcalls+4)]
.finish LDMFD SP!,{R6-R12,PC}

So basically, either R0 is corrupt on entry, or Buftable is corrupt causing .fl1 to load an invalid flushcalls pointer.

[Dunkinator]

Does anyone know if it's possible to extract the sounds from the game?