Spider USB

[MikeB]

Anyone got a Spider USB on the Mediator, wanna know if there are any issues with it.

[tjaoz]

I 've got one. It is excellent.

[sicky]

SEAL's http://www.seal-amiga.co.uk Sam Byford has got one and has written am article about it in the current issue of Total Amiga http://www.totalamiga.org

From what I can gather he is pretty impressed with it, his review certainly indicates that.

[MikeB]

Sounds interesting i have to get the mag and read the review.

thanks for the comments.

E

[Kurt]

I have a spider with a mediator 1200SX works
good in USB 1.1 mode in USB 2.0 mode somewhat flakey. I currently use the older 1.1 drivers as the new 2.0 drivers are hit and miss.

Elbox seems to update drivers on a regular basis so hopefully in the next update it will be corrected.

I know that really is not much help to you. I only use it for transfering images from my Sony Camcorder and Canon Digital cameras so for me it works great for what I need it for. At $40 dollars it was " Cheap " for an Amiga USB card.

Kurt  

[tjaoz]

I have a spider with a mediator 1200SX works
good in USB 1.1 mode in USB 2.0 mode somewhat flakey. I currently use the older 1.1 drivers as the new 2.0 drivers are hit and miss.

I use USB 2.0 driver and it works flawlessly with my USB devices: optical mouse, Logitech USB keyboard, USB 2.0 Universal Flash Card reader and ZIP-100.
The hits you mentioned do not mean anything improper in operation of the USB 2.0 driver. Below  precise Elbox explanation from the Poseidon mailing list.

SPIDER HARDWARE (SELECTED ISSUES)

Unlike other USB controllers for Amiga, the SPIDER card is not
a single USB 1.1 controller with a several-port hub, but three
independent USB controllers in one PCI card.

Two of these controllers are OHCI (USB 1.1) units, and one is an
EHCI (USB 2.0) controller.

These controllers being independent means that the USB devices
working at the same time, which are connected to different
controllers, do not have to share the USB band, as is the case with
devices connected to the hub controlled with a single USB controller.

The SPIDER card has five USB ports.

The EHCI (USB 2.0) controller may support any of the five ports in
the SPIDER card. This controller is supported by spider.device UNIT 2.

One of the OHCI (USB 1.1) controllers supports three ports in the
SPIDER. This controller is supported by spider.device UNIT 0.

The other OHCI (USB 1.1) controller supports two SPIDER ports.
This controller is supported by spider.device UNIT 1.

The SPIDER ports are connected to particular OHCI (USB 1.1)
controllers as follows:

                 -
                  |-----  
                  |     |
 UNIT 0 PORT 1    |O    | UNIT 0 PORT 3
                  |     |--------------|
 UNIT 1 PORT 1    |O       O           |
                  |                    |
 UNIT 0 PORT 2    |O                    -----------
                  |                               |
 UNIT 1 PORT 2    |O                              |
                  |                               |
                  |  ------                       |
                  |--      ------------------ ----|      
                  |


INITIALISING SPIDER PORTS (SELECTED ISSUES)

spider.device UNIT 2 is opened in the first place.

The driver connects all the ports in the SPIDER card to the EHCI
(USB 2.0) controller. Then the driver checks the standard of the
devices connected to particular ports in the SPIDER card.

If an USB 2.0 standard device is connected to the given port or
no device is connected, the given port CONTINUES to be controlled
by the EHCI (USB 2.0) controller.

If an old-standard USB 1.1 device is connected to the given port,
the given port is then SWITCHED by hardware means (with an integral
multiplexer) from the EHCI (USB 2.0) controller to the appropriate
OHCI (USB 1.1) controller.

Then the spider.device UNIT 0 and UNIT 1 are opened, which control
the OHCI (USB 1.1) controllers.

Then the Poseidon stack sends the initialising commands (Port_RESET,
CLEAR_PORT_ENABLE and CLEAR_PORT_FEATURE) to EVERY of the ports:
first to the 5 ports which may be controlled by the EHCI controller,
then to the 3 ports which may be controlled by the OHCI 0 controller,
and finally to the 2 ports which may be controlled by the OHCI 1
controller.

As the SPIDER card has 5 ports, and not 10 (5+3+2), then initialisation
in case of only 5 ports will be successful.

When commands initialising the port are addressed to such a port of
the controller, which was hardware-disconnected from this controller
(due to another-standard devices detected in it), the spider.device
driver returns the information to the stack that initialisation of
this controller's port cannot be successfully executed (endpoint stall).

It is clear as this port is not available to this controller.

This leads to displaying messages:

Warning hub.class   Port_RESET for port 1 failed: endpoint stall (4)
Warning hub.class   CLEAR_PORT_ENABLE failed: endpoint stall ($)
Warning hub.class   CLEAR_PORT_FEATURE (1) failed: endpoint stall (4)

This behaviour of the driver is fully correct.


FINAL NOTE

We have changed the way the spider.device driver operates in order
to prevent false pretences for threatening SPIDER users that these
messages mean some sort of incorrect operation of the card or of the
driver.

The spider.device ver. 2.1 driver returns the information to the
Poseidon stack about correct execution of initialising commands,
even in case of non-existing ports.

I hope the above dispels all doubts in this respect.