Mod Archive Forums Mod Archive Forums
Advanced search  


Please note: Your main account will not work here, you must create a forum account to post on the forums.

Pages: [1]   Go Down

Author Topic: Problems porting Milkytracker  (Read 2333 times)

0 Members and 1 Guest are viewing this topic.


  • Liking the Pie
  • Offline Offline
  • Posts: 2
    • View Profile
Problems porting Milkytracker
« on: August 11, 2011, 00:36:30 »


I've recently ported Milkytracker to the Caanoo, an ARM device by GamePark Holdings, the successor to the GP2X and GP2X Wiz. It works well for the most part, but I have a few issues. The only changes to the code that I made were related to controls; remapping the buttons, getting the joystick working, and whatnot.

The tracker doesn't save any changed configuration for some reason. The internal memory of the device is read-only, and that may be the problem if the tracker tries to save it there, instead of the SD card. Is there a way to change the path that Milkytracker looks for the configuration file?

The tracker doesn't exit properly; it just hangs at a black screen, leaving you no choice but to shut it down by holding the power switch. I just ran Milkytracker from a terminal server, and this is what showed up when I exit:
Crashed with signal 11
Please submit a bug report stating exactly what you were doing at the time of the crash, as well as the above signal number. Also note if it is possible to reproduce this crash.

A backup has been saved to /root/BACKUP00.XM

Segmentation fault

Mouse movement works fine with the touch screen and joystick, but USB mice don't seem to work at all.

Other than that, everything seems to work fine.
« Last Edit: August 11, 2011, 02:35:14 by com64 »


  • Devouring the Pies
  • Offline Offline
  • Posts: 21
    • View Profile
    • Loki Clock's Inflammatory Internet Homepage
Re: Problems porting Milkytracker
« Reply #1 on: October 13, 2011, 06:01:24 »

Is there a debugger for the Caanoo that you can attach to Milky? To make debugging at all quick, you need a symbolic (function names, not machine code) stack trace to know where in the program it faulted.

Otherwise, you can look at the exit routine and print numbered messages throughout to see how far it goes before it faults.

The fault might come from it trying to destruct the keyboard & mouse stuff that never initialized properly.
Pages: [1]   Go Up