Fission Mailed! (or: Debugging Without Serial?)


GeminiDomino

Member
Joined
Dec 17, 2005
Messages
374
Yay, finally got nesgp2x (nk) to compile after switching the buttons around. Only problem is, now it just blackscreens on me. =\

Is there any way of getting debugging output besides having a serial cable?
 
you could add a couple of fake "breakpoints" somewhere in the code -- i mean, force it to print various to the console and possibly exit early, moving later and later into the code until you find where it stops. if you launch the program with sterm or mocca you can see the output. hopefully it's not freezing in which case mocca might be helpful.

but if there's a really bad problem with it then unfortunately you're gonna be trying to "type" in sterm for a while...
 
You can redirect output in your shell script:

Code:
./nesgp2x > output.txt

or set up a USB serial link using the cable you already have, or use sterm, which provides a console on the gp2x itself, using the joystick to select characters for input (knid of tedious but it does the job).

If you're seeing a black screen then either your program is locking up before it gets anything on-screen, or your shell script is failing to chain to the menu again, after your program quits for whatever reason. If you're not using an interactive shell (serial/usb/sterm) then it's worth instrumenting the shell script so you can find out exactly how far it's getting:

Code:
#!/bin/bash

# delete old output file
rm -f output.txt

# log a message to output.txt - sync to make sure it gets 
# written before you run anything that might lock up the gp2x
echo "About to run nesgp2x..." >> output.txt
sync

# run the game, catenating its output to the logfile too
./nesgp2x >> output.txt

# log that we got back, and sync
echo "nesgp2x exited" >> output.txt
sync

# chain to gp2xmenu
cd /usr/gp2x
exec ./gp2xmenu

and I'd also recommend instrumenting the program's startup:

Code:
int main(void)
{
    printf ("entered main function\n");  // print a message
    fflush(stdout);                      // flush libc buffers
    sync();                              // flush kernel buffers
 
GeminiDomino posted on Feb 12 2006 at 01:31 PM said:
Is there any way of getting debugging output besides having a serial cable?

The usb cable. If you really don't wan't to use the USB cable that came with your unit, because you find it distasteful, you could always redirect standard output and standard error to a files, mount the filesystem in sync-mode, and read the output later. Use the > and 2> redirection symbols for this. But you really should be using the USB-cable, so you can see if it's not something dumb like \r in your scripts..

Actually, if you can't get the USB cable to work with gfoot's stuff, you will have worse problems get redirection to work....

P.
 
Last edited by a moderator:
I wouldn't mount the file system in sync mode, instead I'd either make sure to umount or sync the file system before removing the card. You can do this by typing either:

cd / && umount /mnt/sd

or

cd / && sync

before removing the card. If your current directory is on the SD card somewhere (eg. /mnt/sd/mystuff) and you remove the card, then you'll confuse the automounter and it'll refuse to speak to you again until the next reboot, hence the reason for the "cd /" in the above lines.
 
luteijn posted on Feb 12 2006 at 08:01 AM said:
GeminiDomino posted on Feb 12 2006 at 01:31 PM said:
Is there any way of getting debugging output besides having a serial cable?

The usb cable. If you really don't wan't to use the USB cable that came with your unit, because you find it distasteful, you could always redirect standard output and standard error to a files, mount the filesystem in sync-mode, and read the output later. Use the > and 2> redirection symbols for this. But you really should be using the USB-cable, so you can see if it's not something dumb like \r in your scripts..

Actually, if you can't get the USB cable to work with gfoot's stuff, you will have worse problems get redirection to work....

P.

Cool, the USB cable can do that? Nifty, I'll look into it.

EDIT: Sweet! That works! Awesome!

Yep, it can't find libjpeg. I guess that must be statically linked into the SDL the author used... dammit.

Yanno, screw it. this isn't even the latest version, and the project has been abandoned. *mumble* I'll just do without NES. At least Squidge has that wicked SNES emu.
 
Last edited by a moderator:
If it errors out with looking for libjpeg.so or similar, you need to link with -static. In fact, link with -static anyway, it's good practice.
 
nickspoon posted on Feb 13 2006 at 10:57 AM said:
If it errors out with looking for libjpeg.so or similar, you need to link with -static. In fact, link with -static anyway, it's good practice.

Actually tried that. It still does it. The only thing I can think of is that the toolchain I built with ooPo's perl script didn't statically link libjpeg, whereas the one I installed from the archive did. So I'd have to statically link the whole SDL, which would just make the thing insanely HUGE.

Too many versions of the same library, I guess. :unsure:
 
Last edited by a moderator:
Back
Top