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

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:
// Check packet type
      if ((packet.data.reserved_in_packet_type & 0x3f) == TRANSFER_BUFFER_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:

io async operation completed: no error, size=64, result=0x00000000
Read 64 bytes from endpoint 1
00 F4 AA FB 00 00 3A 00
00 00 3A 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 02 00 00 00
Operation Status: OPERATION_COMPLETE
Device State: STATE_IDLE


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:

result = usb_claim_interface( atarimax_device_handle, 0);
result = usb_set_configuration( atarimax_device_handle, 1 );


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/