Gigasoft wrote:
Erm, I'm looking at the code now and I'm wondering what the hell I'm reading. The interrupt firing early is the least of your problems. There are quite a few things here that are fundamentally wrong
What code are you looking at? With the reference to USB_RET_* below, I am guessing the Bochs code. Well, I don't admit that the code is perfect. I coded it so that it would work with various modern (and not so modern) OSes, which it does just fine. Remember, Bochs assumes that all devices attached are valid and can read and write as needed. It has not reason to assume otherwise.
Gigasoft wrote:
such as:
- There is no such thing as a "stack" of queues! If the Link Pointer of a Queue Head has the T bit set, it marks the end of the frame. To avoid an infinite loop if the HCD makes use of bandwidth reclamation, the time taken for each transfer must be counted up, and processing must stop once the time spent exceeds the allowed maximum.
Well, this is where you are wrong. There is to a "stack" of queues. For example, if the current Queue Head's vert pointer is pointing to another Queue Head, you now have a stack of Queues.
Gigasoft wrote:
- If a packet does not complete successfully, Bochs happily advances the queue anyway.
Again, Bochs assumes that all packets will complete successfully. Why wouldn't it? Bochs is in control. If it makes it to the point where it will now transfer a packet, if the packet isn't going to transfer correct, there is more problems than just the packet transfer. Bochs returns errors for invalid requests, but if it is a valid request to a valid device, the packet *will* transfer correctly.
Gigasoft wrote:
- If the device handler returns USB_RET_ASYNC, the NAK bit is not set as it ought to be.
No, the ASYNC is used differently. As far as Bochs is concerned, (and please note I did not write the async part, so I am not totally clear on the process), the transaction is going to be successful.
Gigasoft wrote:
- If the device handler returns USB_RET_NAK, the ActLen field is set to 0x7fd.
(IIRC) It should be 0x7FF. I don't know where you are getting 0x7FD, but I can have a look.
Gigasoft wrote:
- If a short packet is detected, all further queues will become stuck if a packet completes successfully.
Again, I did not write the ASYNC part and can't comment accurately about that. However, the code does work for all guests that we have tested with, which include various Linux Distros, Win95, Win98SE, WinXP, Win7, as well as others.
If you have additions and or changes, you are welcome to modify the source and send an update request. My email address can be found on the URL below.
Ben
http://www.fysnet.net/the_universal_serial_bus.htm