I'd love to help out with this project, but currently a large number of miles away from the unit. Maybe when I'm back at home we can have a look at what is going on.

Progress updates:
I was able to upload the FPGA configuration (ulpitest.rbf), but was not able to check the result yet because of lack of time.

SPT file format (ITI1480A.spt):
A serie oh chunks composed as follows:
- 'CSPT' magic
- 4 bytes (int, probably unsigned): Chunk length, magic included
- 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x50 0xa0 0x70 0x00 0x00 0x6c 0x65: I believe this contains usb transfer struct and understood it once without writing it down... and forgot it since then. Shame.
- 2 bytes (half int): Address to start writing at on device
- 0x0f 0x00 0x00 0x00
- 4 bytes (int, probably unsigned): data length, so == [chunk length] - 32
- x bytes: Data
Note: When address is 0xe600 (CPUCS register address), payload controls cpu reset state, so separates programs in file.
I could recompose an IHX file from it and both upload it to device and disassemble it with dis51 (in multiple steps as it is not aware of interrupt trampolines, even less of auto interrupt tables as used for usb and i2c in EZ-USB chips). Also, it lacks many special function register names - but nothing is impossible with a good doc at hand.

Here is the protocol sructure as I reverse-engineered it (take this with a grain of salt, as I didn't check most of this experimentaly):
Note: Packets must always be long of 64 bytes, pad when necessary.
Endpoint: 1 (BULK OUT, max packet size 64B)
Structure (in tree-ish representation of):
- 1 byte: command
0x00: FPGA
- 1 byte:
0x00: start configuration (reset FPGA)
0x01: send configuration data
- [61 bytes]: configuration data
- 1 byte: actual configuration data length (should be 61 until last configuration send in typical use)
0x01: Stop capture
0x02: Get status (return value = 1 byte, meaning unknown yet)
0x03: Pause/Continue capture
- 1 byte:
0x00: continue
0x01: pause

Capture data should flow through endpoint 2 (0x82) in the same format as usb file.

Plans:
- rewrite current trial-and-error code into something maintainable (done)
- publish code (done)
- write a udev script taking care of firmware uploads (done)
- design a way for userland to control device and generate ".usb" files (done)
- provide a way to browse ".usb" files under linux (improve .NET support in wine, ...?)

Many thanks to ITI for their approach to software (free - as in beer - and allowing/tolerating reverse engineering for interoperability).

Progress updates:
I was able to dump data received from the analyzer.

For some reason, it is not stable yet: quite often, the device starts sending a 2-bytes pattern like mad.
It is supposed (if I understood correctly) to send a given pattern mike mad when told to stop capturing (and host software stops after receiving that pattern for more than 2 consecutive 0x200 byte transfers).

But the pattern I see when I don't expect the burst are different (ex: "20 c1" vs expected "f1 41").

So I could not confirm yet that the dumped data is a valid ".usb" file, but the device send something which really looks like it is, aside from the strange byte spam.

I finished rewriting dirty code. I have now to find a place to publish it at[1], and start hunting bugs.
FYI, my codebase is currently only composed of python scripts:
- 130 lines to convert SPT file into IHX
- 171 lines to send RBF file and dump received data into a file
The latter relies upon a python libusb1 wrapper I wrote, which is available here[2]:
git://z6.physik.fu-berlin.de/linux-minidisc
See "libusb1.py" and "usb1.py" in /netmd directory.
Also, there are patches currently pending inclusion and available on their mailing list:
https://lists.fu-berlin.de/pipermail/linux-minidisc/2010-January/date.html
edited by vpelletier on 1/27/2010

[1] Done: http://github.com/vpelletier/ITI1480A-linux
edited by vpelletier on 1/27/2010
[2] Now also available on github: http://github.com/vpelletier/python-libusb1
edited by vpelletier on 1/27/2010

I could confirm with latest[1] version the validity of captured output as a valid ".usb" file byt opening it with ITI's software after capture.

I suspect there still is a timing problem causing the analyzer to send the "strange" data pattern in a loop, but I could run a few captures successfully in a row.
Such timing problem could be of 2 kind:
- accessing the analyzer too early (I added a 100ms sleep after FPGA configuration upload)
- too much latency on the host side when fetching data from usb, causing analyzer buffer to fill up and maybe causing what I'm observing (I did not trigger one under windows yet)
I still have to investigate on this part.

[1] http://github.com/vpelletier/ITI1480A-linux/commit/0cc883264ab94af9dfc8a93b61b5baf6bfa65466

I believe the current code is in a decent shape on the technical side:
- plugging the device loads the EZ-USB firmware
- device is accessible to normal users once EZ-USB firmware has taken over device control
- capture works (I didn't see the analyzer going mad since the addition of the post-FPGA-configuration-upload delay)
- pause, continue, stop commands work (...since github push from a few minutes ago)

What is missing is:
- distribution (something to place files where they are supposed to be)
- live capture inspection (currently there is no integration into analyzer software)

I believe I'll make a pause on this for a while, and go back to actually using the analyzer  .

Short update:
I wrote a short python script decoding usb file format to a level similar to "Message view" panel.
Its purpose is only to illustrate file format, and will probably not evolve besides that.
My next goal is to add support for this file format in ethereal.
I have some quick & dirty C code for this locally, which is not even at the level of above-mentionned python script... Which is why I didn't publish it yet.