Jump to content

Loading COF file on Skunk via GDB versus JCP


Recommended Posts

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?

Link to comment
Share on other sites

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
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 by Songbird
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...