Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

STD really does support the Simtec USB podule

By Chris Williams. Published: 30th Mar 2004, 21:46:57 | Permalink | Printable

Same podule, same end user support, new name

RISC OS USB logoStuart 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

Previous: Disruption follows Manchester BT fire
Next: STD reveal USB, NIC, IDE combo-podule

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

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?

 is a RISC OS Usersimo on 30/3/04 11:22PM
[ Reply | Permalink | Report ]

No, the podule hardware supports USB 1.1 and not 2.0, regardless of what the USB stack can handle.

Chris. Just me.

 is a RISC OS Userdiomus on 30/3/04 11:51PM
[ Reply | Permalink | Report ]

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

 is a RISC OS Usersimo on 31/3/04 5:45AM
[ Reply | Permalink | Report ]

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.

 is a RISC OS Userdiomus on 31/3/04 6:40AM
[ Reply | Permalink | Report ]

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 Risc PC. 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.

 is a RISC OS Userdavehigton on 31/3/04 7:47AM
[ Reply | Permalink | Report ]

According to [link] 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 ;)

 is a RISC OS Userstdevel on 31/3/04 8:31AM
[ Reply | Permalink | Report ]

Sorry.... ^H^H^H^H^H STD USB card ;-)

Old habits......

 is a RISC OS Userstdevel on 31/3/04 8:31AM
[ Reply | Permalink | Report ]

Does this mean it could run at the 6MB/s supported by the RPC?

 is a RISC OS Userjess on 31/3/04 12:50PM
[ Reply | Permalink | Report ]

There's something called CBAI, which I can't find any info on. The only thing there is is section 10 of this: [link] 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 info@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!)

 is a RISC OS Userjohn on 31/3/04 1:40PM
[ Reply | Permalink | Report ]

For those who don't use a cut and paste capable browser and want to visit the link, <a href="[link]">[link]

 is a RISC OS Userjohn on 31/3/04 1:41PM
[ Reply | Permalink | Report ]

"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. ;-))

 is a RISC OS UserMiltonS on 31/3/04 2:11PM
[ Reply | Permalink | Report ]

Nobody has said anything was stolen!

 is a RISC OS UserThe Doctor on 31/3/04 4:28PM
[ Reply | Permalink | Report ]

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.

 is a RISC OS UserJGZimmerle on 31/3/04 4:43PM
[ Reply | Permalink | Report ]

Oh, I nearly forgot my heazard suit... Right, I'm prepared for the flamez, now. Go ahead. ;-)

 is a RISC OS UserJGZimmerle on 31/3/04 6:12PM
[ Reply | Permalink | Report ]

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 :-)

 is a RISC OS UserTonyStill on 31/3/04 10:23PM
[ Reply | Permalink | Report ]

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.

 is a RISC OS Userquatermass on 31/3/04 10:34PM
[ Reply | Permalink | Report ]

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.

 is a RISC OS Userhubersn on 1/4/04 12:01PM
[ Reply | Permalink | Report ]

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

 is a RISC OS Userdgs on 1/4/04 12:49PM
[ Reply | Permalink | Report ]

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 :)

 is a RISC OS Userilludium on 1/4/04 1:47PM
[ Reply | Permalink | Report ]

illudium: My understanding was that it had been resolved quite some time ago :-)

dgs

 is a RISC OS Userdgs on 1/4/04 2:19PM
[ Reply | Permalink | Report ]

dgs: So everyone is happy, yay :biggrin:

 is a RISC OS Userilludium on 1/4/04 2:41PM
[ Reply | Permalink | Report ]

@illudium: 100% agree.

@hubersn: The question is: How do you define "all things RISC OS"? And are NC OS and RISC OS the same thing?

 is a RISC OS UserJGZimmerle on 1/4/04 4:25PM
[ Reply | Permalink | Report ]

I thought the question was "To be, or not to be?"

 is a RISC OS Userjonix on 1/4/04 4:54PM
[ Reply | Permalink | Report ]

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.

 is a RISC OS Userhzn on 4/4/04 12:34PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • DialUp, R-Comp's net connectivity package, is put to the test as Michael Stubbs reviews

     2 comments, latest by gary_hughes_fp on 7/8/01 3:50AM. Published: 12 Feb 2001

  • Random article

  • Iyonix in online press
    Plus part one of drobe.co.uk's Iyonix review
     11 comments, latest by mrchocky on 7/12/02 10:47PM. Published: 5 Dec 2002

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "At least some RISC OS news sites get their facts right before posting articles"
    Page generated in 0.2074 seconds.