Developing Win7/10 driver for ATI USB2.0 TV Wonder?
 

I am not the man for this job.

Let me state that from the outset, so no one else feels compelled to avoid stealing my thunder.

But

This is a very good device, it contains the original ATI Theater 200 chip, and a USB2.0 bus connection.

I used to think you had to understand everything going on low level to successfully write a device driver.

But the USB Snoopy for Windows XP device driver shim exists and can capture, startup, and on demand commands in response to exercising DirectShow WDM functions.

The DirectShow WDM functions work reasonably well on Windows 7 and possibly Windows 10 for 64 bit device drivers.

So I am coming around to think this really might be possible.

Windows 7 is stable and abandoned by Microsoft so its no longer shifting sand.

That makes it a good weigh point, and a nice transition from 32 bit to a fully 64 bit device driver.

And its what I know best for now.

Windows 10 is very long in the tooth.. and I hear rumblings of Windows 2020 replacing it in early 2021 wholesale.. sorry if not everyone at Microsoft has heard this yet... the Apple ARMs race has them thinking outside the box.

I don't know how long it will take.

But if anyone wants to make suggestions or help.. or just cheer me along..

I'm a very amateur software programmer.

Anyway.. hang on to your ATI USB2.0 TV wonders, hope may be on the way.

Here's to cheering you along, JWillis! :salute::beer:

Jwillis, Why don't you join in the effort to finishing the VHS decode software project?

I'm not much of a software coder.

Much of the templates for a WDM device driver are already there in Visual C++

I think the ATI USB bridge is just a firmware blob upload and then pushing register reads and writes through the blob firmware into the Theater 200 chip.

The registers in the Theater 200 chip are not openly documented, but the WDM functions can be exercised from GraphEdit and the read and writes copied using a protocol analyzer into the template and compiled into a device driver.

Visual C++ should do the rest and it just has to be set to x64 bit during compile.

That my thinking.

Fleshing out a simple crossbar and capture filter from Templates also "appears" basic.

It could completely overwhelm me.. and may never be finished.

Joining a project implies real skills and knowing what your doing.. i'm deficient in both.

but I'm also dumb enough to try

We know that ATI AIW PCI/AGP/USB (not PCIe) "work" in WinVista and Win7 x86 (not x64). Both VirtualDub and ATI MMC. But "work" gets very hackish, and often undoes itself at reboot.

I think Win7 x86 may be a good intermediate step for you. Get Win7 to install the drivers without hacks needed, remember after reboots. Then jump over to x64, and make those adjustments.

The PCI/AGP have the problem of needing display drivers. But the USB does not. That may be why USB works, while AGP/PCI will not -- although it is possible those will, too. Remember the Omega drivers, which gave x64 ATI support to Win7/8/10.

If you're dumb enough to try, I'm dumb enough to be your cheerleader. "Rah, rah, siss boom bah." (Sound of a sheep exploding. -Johnny Carson)

Win7 x86 is an interesting step

but the changes from x86 to x64 should be the flip of a switch during compile.. from what I can see

Visual C++ takes care of all the kernel calls and function de-referencing

my plan is just copy the steps during device insertion.. which I expect to be the blob upload to the serial eprom/ram

then open up GraphEdit and exercise the pin properties and filter settings for the crossbar and capture components

each should have a unique USB stream of steps

then copy those into the functions of a blank filter template in visual c++

since it works with virtual dub, and that uses those two filters, then a x64 version should provide the same capability

i still won't be able to decipher what that does in register space in the ati usb2.0 or any chips on an i2c bus on that board.. it will be a mystery.. and the usb bridge chip blob is usually proprietary.. so reverse engineering it that way shouldn't be possible

as a hack.. it will be pathetic

the only outcome will be a device driver.. not a lot of answers about how it works

i am very surprised they never took the same code and just recompiled it themselves

i guess there was a reason..

the ati usb tv wonder came out in 2004, windows 7 came out in late 2009 .. maybe 5 years was just too long for them to care about supporting the product

technically windows xp lasted until april 2014 and the company got bought in 2005 .. i guess they had other priorities

ntsc ended in early 2009 and most people probably weren't thinking of tape conversion in the aftermath of the financial crisis

it sure would be better if someone with the original ATI device driver code could simply load it up and flip a switch and hit compile.. but as old as this is getting.. perhaps they aren't around anymore.. shuffled off this mortal coil ect..

I got lucky and found a USB 2.0 Protocol Analyzer.

Since I am no expert and I am learning this myself, the bare minimum to get to a device driver.

I thought I would share the data I collect in case someone else understands it better.. or might eventually take over the whole project.

I can't see the forest for the trees right now.. so I don't know when it might be complete.

First Step:

I downloaded the "free" Datacenter and used that to capture USB bus from the moment the USB cable of the ATI USB2.0N video capture box was plugged into the laptop acting as the video capture host.

It appears to me it negotiated USB bus speeds up to (480 Mbps) High Speed, then assigned it a USB bus address number, and then interrogated it to discover why kind of device it was.

Then the Host appears to have loaded a device driver on the video capture host and started sending a binary blob to program the USB bridge chip.

Then it settled down and just pinged it every so often.

That is the basic Windows XP device driver start up procedure.

Windows recognized a new device, fetched its hardware identifier, loaded a device driver and sent a binary blog to the device to set it up.

Any Windows x64 device driver would have to do the same thing.

I can see it has one Configuration and one Endpoint, with Four Interfaces.

One interface uses the USB Bulk protocol to transfer data
Three interfaces use the USB Isochronous protocol to transfer data

All the Interfaces are Inputs

http://www.digitalfaq.com/forum/atta...1&d=1598151087

The compressed tdc capture file is attached to this message, it is very small, less than 1 Megabyte.

The USB protocol analyzer I'm using is the www.TotalPhase.com USB 480 Beagle.

The viewer software I am using for capture and to decode the capture is the Total Phase Data Center protocol analysis software. Version 6.73.007 on Windows 7 x64.

The Data Center software can be downloaded here Data Center

For Windows, Linux or Mac

You do not have to have the USB 480 in order to install the Data Center software and open up the capture file.

Capturing the start up the ATI USB2.0 video capture box when VirtualDub 1.9.11 was opened on Windows XP SP2 went well and appeared to have no problems.

After a few seconds the capture produced a 98 MB file, but I think its orders of magnitude more complex.

VirtualDub had to build a Directshow graph to model the flow and use that to retrieve video and sound from the ATI USB2.0N video capture device.

That was more a "stunt" than a serious collection of data. I wanted to see if it could be done. And the results were good.

Really I think the proper way to proceed is to startup GraphEdit 32bit and load the ATI USB2.0N cross bar and capture exercising its functions retrieving and setting things. Those should send commands to the video capture device across the bus. Those same command should be appropriate for a 64 bit device driver. Then load the capture filter and do the same.

I'm not too interested in the BDA Tuner filter since NTSC signals are no longer broadcast.

This device also has no hardware MPEG encoding feature so there are no hardware encoding filters to map out.