Loading COF file on Skunk via GDB versus JCP

[Songbird]

I'm trying to get my next CD emulated using JagCDU, and have found an odd problem: if I load a COF file via JCP, it will start the program because I can hear the music I set up, but the screen stays black and the controller does not respond to anything. If I load the exact same COF file via GDB and type "continue", the program runs fine.

 

I'm guessing there's some kind of initialization issue where if the disc is loaded on a real CD unit or the COF file on GDB, then it works properly. Could RAM be zeroed in one case and not the other and perhaps revealing an initialization glitch within the CD program? Other ideas?

[Songbird]

The two loads do appear different in terms of how much data they send:

jcp v02.03.03 built on Oct  3 2010

COFF File:  Skip 168 bytes, base addr is $4000, length is 262458 bytes
Sending...........
Jag accepted start request at $00004000.

Finished in 889 millis, 295KB/second.

Loading section .text, size 0x2f20 lma 0x4000
Loading section .data, size 0x2fbd0 lma 0x6f20
Start address 0x4000 , load size 207600
Transfer rate: 415200 bits/sec.

 

I'll try manually cutting down the file to the smaller 207600 size and see if I can do a straight binary load to $4000 using JCP...

Edited June 26, 2016 by Songbird

[ggn]

Can you check out your linker's (rln I suppose?) output? With enough verbosity you get a report on how big each section is (TEXT, DATA, BSS, perhaps COMMON as well). The difference you see might be the symbol/fixups table, something that gdb might be detecting and not transmitting.

 

Also it's certain that the Skunkboard BIOS changes a few things to the system - I've witnessed a ton of binaries converted using JiFFI to work as ROM but not as COFF and vice versa.

[Songbird]

This is actually a really old COF file from 2002 so I didn't have any matching build output, but I got it to rebuild today using rln and it seems to match what GDB is telling me:

+---------+----------+----------+----------+
| Segment |     TEXT |     DATA |      BSS |
| Sizes   |----------+----------+----------|
| (Hex)   |     2F20 |    2FBD0 |    5CF30 |
+---------+----------+----------+----------+

I also got the raw binary to output exactly 207600 bytes, however if I do jcp prog.bin $4000 it has the same result where the screen goes black and the music starts, but the rest of the program doesn't run. This is very confusing, since it appears GDB is performing the exact same operation yet GDB is successful at running the program...

[ggn]

Ok, I'm pretty sure I've experienced something like that in the past but for the life of me I can't remember what and how it was dealt with . The only relevant thing I can find is some startup code I had to use when converting coffs to roms inside jiffi:

 

 

move #$2700,sr
move.w #$7fff,$f0004e

 

This is executed at the very beginning of the code. You might want to give this a shot, but no guarantees!

[Songbird]

I figured it out: the stack wasn't initialized. I didn't remember that Protector SE took care of the stack init for unencrypted CD games, so the CD boot track didn't have to do that if it didn't want to. I'd call that a bug (and it's my bug in my CD program ) because each CD should take care of its own init instead of relying on the boot cartridge.

 

So, it must be that GDB is setting up the stack on the Jag whereas JCP is not, thus the difference in behavior I observed.

[dilinger]

I guess you are using GDB with jserve; in this case, the Jaguar debug stub (jdb.cof - loaded by jserve) initialise the stack at $1FFFF0.