On 11.4.2004 at 21:28 Marcel Kilgus wrote: > I'm no hardware guy, but just for the sake of argument this chip > looks like it could provide USB host functionality with a not too > complex CPU interface. There's even a document with complete > schematics that describes on how to interface it with a DragonBall > CPU. > >http://www.semiconductors.philips.com/cgi-bin/pldb/pip/ISP1161a.html > >I have no clue how difficult the software side would be. > >Marcel
To be honest, I have not looked at Philips for USB chips, having had rather nasty experiences recently with CAN bus chips - that "let's make things better" motto should really sometimes be, "let's leave things alone"... I had a quick look and downloaded the files - great tip. I had previously looked at the ISP1160 (which is only a host adapter, not a combined host / device), which can be used to provide USB functionality on an ISA card - a host-only adapter would already be sufficient. It may even be possible to connect this chip onto a regular QL. I will try to get some data on the cost and availability of the chip, unfortunately Philips does not offer an on-line quote for this chip either (just like they didn't for the 1160). As far as the software side goes, I think it would be extremely difficult if not impossible to put up a complete host stack under SMSQDOS without some serious changes to SMSQDOS (which it admittedly needs badly), as we again have a lack of clear layering - something that is a common thread from file systems down to TCP/IP. Let me make this clearer: it is not possible to cleanly have one driver interface with another and then operate as a driver stack (in this case 'driver' refers to the way SMSQDOS defines the term), which is paramount with things such as USB, where only a hardware interface is defined, and not it's ultimate function. To illustrate: the functions of a USB printer are rather different than the ones of a USB storage device, or a USB mouse, yet they all communicate using a USB interface, but all the possile functions cannot be integrated into one monolythic drivers, mostly because they are not known in advance. Because of this, with each new device, a 'driver stack' is created with pre-existing drivers, and new, device speciffic drivers, which interface with each other. Simplifying this down to SMSQDOS-speak: a complete USB driver stack has a hardware driver, and, a set of 'sub-drivers' if you will, that handle various classes of devices, and then a set od 'sub-sub drivers' that handle various devices of the same class, and then, we can have a 'sub-sub-sub driver', for instance to set up a file system on a suitable device within a suitable class, etc. Under SMSQDOS it is very difficult (AFAIK impossible cleanly) for multiple drivers to address a single piece of hardware, without some sort of arbitrating mechanism 'on the side' which operates unbeknownst to the OS and just between the drivers themselves. Alternatively, a hardware abstraction driver could be made, that provides a multiple access virtual device, to which the various other drivers then interface, and manages the arbitration as to which drivers can do what and when to the hardware or each other - although this is possible, it is subject to all sorts of silly limitations, as soon as a directory device enters the picture (slaving, DEFBs, name lengths etc). All that being said, it may well be possible to _relatively_ simply interface to a single class of devices, for instance, USB storage devices such as USB Flash keys or hard drives, but probably NOT USB flash card readers per se. This is because a 'stack' of sorts for a speciffic class of devices can be 'fused together' into a single device driver, that could operate under the confines of SMSQDOS, in it's current state. Even so, there would be no guarantees that every generic device of the storage class would work, so if you go out and just buy a USB Flash key, wether it works or not may depend on what kind of internal circuitry it has. _______________________________________________ QL-Users Mailing List
