Atarimax Product Discussion Forums https://www.atarimax.com/flashcart/forum/ |
|
Open source command line programming utility. https://www.atarimax.com/flashcart/forum/viewtopic.php?f=8&t=399 |
Page 1 of 1 |
Author: | classics [ Thu Apr 06, 2006 11:57 am ] |
Post subject: | Open source command line programming utility. |
Here is the promised first release of a command line program to program the ColecoVision 128-in-1 flash cartridge. If anyone wants to improve it, add a GUI or port it to OSX feel free. Please keep in mind it was built to be a simple back end for a GUI, not a complete solution. Steve |
Author: | AverageSoftware [ Thu Jun 25, 2009 7:10 pm ] |
Post subject: | |
Hello, just received my 5200 cart today, and I'm having a problem with this command line utility. I have built the utility on both Mac OS X and Linux, and both builds have the same problem. Every ROM I try to work with has an invalid header. The included Windows software handles the exact same files without any issues, so I don't believe the files are at fault. Here is the relevant line from the manifest: rom;1;a5200/Berzerk.bin;Berzerk Has anyone else gotten this utility to work? What am I doing wrong? By the way, once I get this thing working, I plan to start building a Mac OS X and Linux GUI around it. |
Author: | AverageSoftware [ Thu Jun 25, 2009 7:25 pm ] |
Post subject: | |
AverageSoftware wrote: Hello, just received my 5200 cart today, and I'm having a problem with this command line utility.
I have built the utility on both Mac OS X and Linux, and both builds have the same problem. Every ROM I try to work with has an invalid header. The included Windows software handles the exact same files without any issues, so I don't believe the files are at fault. Here is the relevant line from the manifest: rom;1;a5200/Berzerk.bin;Berzerk Has anyone else gotten this utility to work? What am I doing wrong? By the way, once I get this thing working, I plan to start building a Mac OS X and Linux GUI around it. Edit: Gah, this is just for the Coleco cart, isn't it? No wonder. Stupid me... is the a 5200 version of this utility? |
Author: | classics [ Fri Jun 26, 2009 4:32 am ] |
Post subject: | |
Oops, I forgot I never back ported the CV software to work on the 5200 multi. So I spent a few hours tonight hacking on it. A few features might not work 100%, but it seems to be connecting to the cart, programming it and producing a working cartridge at this point. Let me know if this works for you. Steve |
Author: | AverageSoftware [ Mon Jun 29, 2009 10:37 am ] |
Post subject: | |
Partial success. I can build and run the utility on Mac OS, but it keeps getting stuck in wait_transfer_buffer_in The following condition: Code: Select all // Check packet type never evaluates to true, and the program gets stuck looping here. The debug message at this point is Transfering 64 bytes of data on endpoint 0x81 io async operation completed: no error, size=64, result=0x00000000 The endpoint never changes, I'm assuming this is the last transfer block, so it looks to me like it just keeps writing the same block over and over again. On the Linux front, I've compiled and run the utility on both Slackware and Fedora and in both cases, it can't seem to open the cartridge. It detects it's presence, but can get no farther. This may be some sort of configuration/permissions issue on my part, and I'm still playing with it. As a side note, did you know that your Windows utility seems to require administrative rights? When running it under my normal user account, it can't seem to access the menu.rom. Not sure if this was intended or not. |
Author: | classics [ Mon Jun 29, 2009 1:15 pm ] |
Post subject: | |
Can you uncomment the debugging code in wait_transfer_buffer_in/read_device so that the contents of the packets are output to the console? I'm wondering if you are actually getting the correct data from libusb or blank frames. As for the studio software, it should not require administrative access to run. The menu.rom is just a regular flat file with no special ACL or permissions. If this is on a NTFS volume try running the cacls program on the contents of the installation directory to see if any of the files have administrator only permissions set. Steve |
Author: | AverageSoftware [ Mon Jun 29, 2009 3:00 pm ] |
Post subject: | |
With the debug code enabled, I keep getting this: Code: Select all io async operation completed: no error, size=64, result=0x00000000 This is on a freshly blanked cartridge, and the hex dump is consistent between runs of the program. |
Author: | classics [ Tue Jun 30, 2009 12:39 am ] |
Post subject: | |
Is that the only packet you are getting back? Try inserting a line: usleep(500); Before the "readln = usb_bulk_read" line in read_device. I'm not sure what the read rate to the device is on a Mac, it might be sending more requests than it expects in too short a time period. I tried building the program on a Ubuntu 9 vmware machine tonight and it was able to attach to and update the cartridge successfully. Steve |
Author: | AverageSoftware [ Tue Jul 07, 2009 12:42 pm ] |
Post subject: | |
classics wrote: Is that the only packet you are getting back?
Try inserting a line: usleep(500); Before the "readln = usb_bulk_read" line in read_device. I'm not sure what the read rate to the device is on a Mac, it might be sending more requests than it expects in too short a time period. I tried building the program on a Ubuntu 9 vmware machine tonight and it was able to attach to and update the cartridge successfully. Steve The usleep delay didn't help matters, but I'm forgetting about the Mac for now and concentrating on Linux. Out of curiosity, could you explain this to me: Code: Select all result = usb_claim_interface( atarimax_device_handle, 0); What's the significance of the 0 and 1 in these calls? This is where my problem is on Linux, and I can't find anything in the libusb documentation that explains those values. |
Author: | classics [ Tue Jul 07, 2009 9:24 pm ] |
Post subject: | |
These refer to the interfaces and configurations in the USB descriptor for the device. A device can have more than one of each, so these functions let you select among them. However, in this case, the USB cart only has one configuration. On linux you can use the lsusb program to dump the descriptors returned by a USB device and examine the configurations, endpoint groups, etc. Steve |
Author: | AverageSoftware [ Sat Jul 18, 2009 11:09 pm ] |
Post subject: | |
Just to keep you informed on this, I'm fairly sure now that my problems stem from the way USB devices are detected on my particular system, I don't think there is any fault with your code. I'm still screwing around with udev trying to make this work. |
Page 1 of 1 | All times are UTC - 5 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |