Stuart Tyrrell Developments USB FAQ

Q: What is USB and why is it important to RISC OS

An excellent introduction to USB may be found at http://www.riscos-usb.com

Q: Why are there two USB 'standards' for RISC OS?

USB is a complex standard, and the Simtec USB project had, understandably, been worked upon for a substantial time before the first public release. This work included negotiation between various interested parties. In January 2002, a news article in Acorn User (no 240, page 10) included an endorsement of the Simtec stack by Castle, and a declaration by Jack Lillinstone of Castle that their API would be compatible with the Simtec one.

It was understood that at the time, Pace were developing their own stack for internal use. This stack was based around DeviceFS. Although this type of implementation has a number of significant issues for general use, it was suitable for the limited number of devices which Pace wished to use.

In April 2002, Simtec were approached by an ex-employee of Pace, offering access to the Pace DeviceFS API free of charge. As they were unable to verify the legitimacy of this source, and did not want to pollute their own stack, Simtec declined this offer.

In May 2002, Simtec announced their USB card, based around their existing USB API; Castle announced their USB card, based upon a DeviceFS API.

In November 2002, Castle's Iyonix shipped with RISC OS 5, including Pace's USB API - several months later Castle's USB card was updated to a similar API.

Whilst USB on RISC OS originally involved co-operation between the various parties involved, it is obvious that at some point in time a divergence appeared.

Whilst the simplest route at this point of divergance might have been for Simtec to write off the work that had already been achieved for USB on RISC OS, this is not an option for a number of reasons:

a) The Simtec API was designed from the bottom-up to be suitable for the widest range of implementations, from desktop machines to embedded systems. It was not considered sensible to opt for an API which was, at the time, primarily designed for a specific non-desktop machine.

b) As the Simtec API reflects those typical in the wider computing world, rather than relying on RISC OS' specific DeviceFS, driver development is widely considered to be easier for the Simtec API. This is reflected in the number of third parties who have successfully supported this API.

[We at Stuart Tyrrell Developments believe this is fundemental to the profile of the RISC OS market. If drivers are solely released by hardware manufacturers - whether charged for or given away "free" by funding development by cross-subsidising from machine sales - the developer community is unlikely to profit. Given the nature of "free support" by RISC OS developers and dealers, we believe this policy is unsustainable and to the detriment of the RISC OS market as a whole]

c) As it complies with generally accepted API implementations, the Simtec API is suitable for use outside the RISC OS market. It benefits from the input of large customers, and in turn development of RISC OS drivers are subsidised by these customers. Moreover, as a completely "clean" design (it does not rely on any GPL or sub-licensed code), the Simtec implementation is available for license to customers, several of whom are larger than the RISC OS market as a whole.

In short, we believe that the Simtec USB solution is the most appropriate for RISC OS development, and has the stability associated with its acceptance outside the RISC OS arena.

Q: Why buy a Simtec USB card and use the Simtec API?

Rather than a "quick fix" to get a limited number of devices working, the Simtec API was designed from the bottom-up to support a wide range of devices.

Simtec are the recommended design