STD really does support the Simtec USB podule - RISC OS News, Software and Information

STD really does support the Simtec USB podule

Published: 30th Mar 2004, 21:46:57GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

Same podule, same end user support, new name

Stuart Tyrrell Developments has announced today that it is to officially take over distribution and front line of support of the Simtec USB1.1 card, for both end users and RISC OS dealers. Henceforth, the USB card, designed and manufactured by Simtec, will be known merely as the 'STD USB card'.

This announcement will, in all probability, not win a prize for being the most exciting RISC OS news for 2004. This is especially because STD have more or less provided all end user support and sales presence for the USB card, so punters won't see a drastic change in operations. However, we were taught never to rain on anyone's parade so we'll indulge the two companies just this once.

"We have worked for many years with Simtec, acting as dealers and agents for their RISC OS products, and we have commissioned designs such as NET100 from them," explained Stuart Tyrrell of STD. "We're delighted to formalise these arrangements."

Simtec's Gavin Simpson added, wistfully: "With Stuart Tyrrell Developments distributing and supporting the RISC OS port of our embedded USB stack, Simtec can concentrate on product development - adding new features and hardware interface support."

See, that's the interesting part: while Simtec have been producing upgrades for RISC OS hardware for almost 15 years now, they are an electronic design house with many customers coming from well outside of our market and one can understand their gradual tip-toeing away from our tiny platform. Philips, for example, recommends them for designing USB products. So, now that Simtec can concentrate fully on their own work, STD claim changes made to the Simtec USB stack will eventually filter down to RISC OS end users. Citing an example of this, STD say support for wireless networking and other non-mass storage USB devices was made available to RISC OS users following work that Simtec carried out for their customers.

The STD USB podule is suitable for machines fitted with a backplane and 26bit RISC OS, namely RiscPCs, A7000s and A5000s. The drivers for the card are incompatible with Castle's USB stack and vice versa - which, naturally, is really handy for the platform. Both USB implementations have their supported devices lists online for you to compare at your leisure: Simtec vs. Castle. Given the race last year to be the first developer to release drivers for digital cameras, MP3 players and other gadgets, at least we can conclude that a little competition certainly never hurt nobody.

Update at 23:59 30/3/2004
Having read through the STD FAQ on USB, we've spotted an eyebrow raising entry in the aforementioned FAQ, titled Why are there two USB 'standards' for RISC OS?, which explains STD's and Simtec's side of the USB driver split. According to the FAQ: "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."

Perhaps an interesting read, if you fancy delving into STD's retelling of the politics and history behind the embarrassing USB divide.

Links
RISC OS USB website - to be updated shortly with "current and future developments of the STD USB card".
STD USB podule details

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

simo 30/3/04 11:22PM	Can't we call is the BUS STD card? And shouldn't it be "STD USB 2.0 high-speed" now instead of 1.1?
diomus 30/3/04 11:51PM	No, the podule hardware supports USB 1.1 and not 2.0, regardless of what the USB stack can handle. Chris. Just me.
simo 31/3/04 5:45AM	But isn't USB 2.0 "high-speed" just a renamed 1.1, or does it include more? USB 2.0 as we know it is "full-speed" 480Mbps
diomus 31/3/04 6:40AM	USB2.0 is a faster implementation of 1.1 and it's even backwards compatible to 1.x - however, the USB1.1 chipset in the Simtec podule can't magically become a 2.0 chipset. To suggest otherwise is crazy talk. Anyway, the RiscPC podule bus is rated at 6MB/s (TRM 1-19), which is, shall we say, slightly less than the top data transfer rate endowed by USB2.0. Chris. Just me.
davehigton 31/3/04 7:47AM	OK, so when do we get isochronous support in the STD USB stack? I'd realiy like to use my iMic to record audio on my RiscPC. I want to write the drivers and make them freely available; but I can't, because the stack is only a partial implementation of USB 1.1.
stdevel 31/3/04 8:31AM	According to [Link: www.semiconductors.philips.com] the device used on the Simtec card is USB2.0 (full speed and low speed), but that's more to do with the re-branding of USB which happened a year or so ago rather than any change in chipset. To avoid confusion we refer to the card as USB1.1, then people won't assume that it's USB2.0 (high speed), although we could call it USB2.0 if we wanted. The API is USB2.0. It's unlikely that any RISC OS stack will implement isochronous support, as RISC OS simply can't debatch packets quickly enough to provide usable bandwidth where QOS is not guaranteed. The stack itself /does/ provide for isochronous transfers, but a decision was made to disable the back-end for this in the RISC OS version rather than to have developers try to write drivers for devices which would be unusable. I'll endeavour to have a tutorial written for this for the re-launched website, to avoid further repetition. If anyone can develop a fully guaranteed-QOS scheduler for RISC OS, we've plenty of other applications that would benefit
stdevel 31/3/04 8:31AM	Sorry.... ^H^H^H^H^H STD USB card Old habits......
jess 31/3/04 12:50PM	Does this mean it could run at the 6MB/s supported by the RPC?
john 31/3/04 1:40PM	There's something called CBAI, which I can't find any info on. The only thing there is is section 10 of this: [Link: www.acornusers.org] It seems to be some kind of prioritised interrupt handler. However, it doesn't appear to be a fully guaranteed QOS scheduler And contact Robin Watts at [Email: info [at] wss.co.uk ] for more details. Oh, and if anyone's got some fully guaranteed magic pixie dust for RISC OS, I've got plenty of applications that could benefit (with apologies to stdevel!)
john 31/3/04 1:41PM	For those who don't use a cut and paste capable browser and want to visit the link, [Link: www.acornusers.org] [Link: www.acornusers.org].
MiltonS (-0.6) 31/3/04 2:11PM	"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." Perhaps the very same ppl that offered the stolen Pace RISC OS 4 source code to Castle and then set themselves up as software team and then later joined Castle? Leave you to work out who that was. )
The Doctor (-0.1) 31/3/04 4:28PM	Nobody has said anything was stolen!
JGZimmerle (-0.5) 31/3/04 4:43PM	Of course not, who would want to claim something only Pace could prove, if they could be sued for their comments. No one would, and that is why nobody did, even when managers from Pace told certain licensees that no-one but ROL had a valid licence at the time. And even managers from Pace would have been very unwilling to sue anyone, because that would have shown to their share-holders that they failed to protect their source code. Wich would also explain why RISC OS might have been sold at a price wich was lower than the highest bid. All the above is purely speculative, of course.
JGZimmerle 31/3/04 6:12PM	Oh, I nearly forgot my heazard suit... Right, I'm prepared for the flamez, now. Go ahead.
TonyStill 31/3/04 10:23PM	Just so I'm clear here: Is it suggested that someone stole the RO4 source and gave it to Castle, then joined them to develop it...so they could publicly release it? If a Pace manger was to get in trouble, surely it would be for not pursuing a theft when the thief advertised who he was, not for the original theft (do you search every employee every day in case they've got a CD-R in their pocket with stolen code on it?). I have this theory about two little green men in a flying saucer building the pyramids; I reckon it's more credible
quatermass 31/3/04 10:34PM	Funny, this rumour has been going around the RISC OS developer pool for well over a year now. Every developer in RISC OS and ZFC circles certainly has heard of it. Drobe has as well of course I'm sure. I personally am surprised it's never leaked to the surface 'as it were' before now. Whether its true or not is another question of course. Now largely pointless story as Castle now owns the source code and Pace don't seem to be bothered.
hubersn 1/4/04 12:01PM	Some developers even checked knowledgable sources and came to the conclusion that it was very obvious who tried to spread damaging rumours like that. It is really sad that the only people who really know what happened are not interested in publishing the whole story. Unfortunately, this allows people like JZ to further spread their conspiracy theories of why a certain RISC OS related company is now not the owner of all things RISC OS.
dgs 1/4/04 12:49PM	*In reply to JGZimmerle:* If you can tell us the values of these "bids", (and maybe even who they were from), then you can make clear to us which was higher and which was lower. If you don't know the financial values of the supposed bids, then what you've said is pretty meaningless. dgs
illudium 1/4/04 1:47PM	*In reply to hubersn:* The trouble with knowledgeable sources is that different sources have different knowledge. I'd suspect that unless you have access to all the correspondence and licences between the various companies involved since RISC OS moved to Pace then you can't know every part of the story. In any case this isn't a situation that's likely to be resolved in Drobe comments
dgs 1/4/04 2:19PM	*In reply to illudium:* My understanding was that it had been resolved quite some time ago dgs
illudium 1/4/04 2:41PM	*In reply to dgs:* So everyone is happy, yay :biggrin:
JGZimmerle 1/4/04 4:25PM	@illudium: 100% agree. *In reply to hubersn:* The question is: How do you define "all things RISC OS"? And are NC OS and RISC OS the same thing?
jonix 1/4/04 4:54PM	I thought the question was "To be, or not to be?"
hzn 4/4/04 12:34PM	Looking at a posting stating that a company (STD) paritally supports USB (i.e. Simtec but not Castle) and then skimming through the threads is interesting: I enjoy the capability to start with one topic and then quickly move to a different one Anyhow as for the rumors of stolen source and license breaching and the like: If I look at the facts then a) Castle now owns RISC OS, b) no company pushed legal actions against Castle getting the license and selling the IYONIX pc with RISC OS 5. If the rumors about stolen code or breaching of the license of RISCOS Ltd and other claims along these lines were true as the odd "knowledgeable source" posted in the net ... then I'd expect legal actions taken but that seems not to have happened. Thus I tend to agree with the conspiracy theory.