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

Castle USB to get audio, video support

Published: 19th Jul 2006, 13:45:44 | Permalink | Printable

Will leave Simtec stack behind says key developer

A generic webcamWork is underway to add support for streaming data from webcams and radios over USB to RISC OS 5. Castle's John Ballance is said to be developing support for isochronous devices with the help of the ex-Pace engineer responsible for the Iyonix USB stack, Dan Ellis.

The work could see new gadgets connected to RISC OS computers, with users watching live video from webcams and listening to music picked up in realtime from FM and AM stations. The updates could be released within the next few weeks, sources confidently state.

Dave Higton is also aiming to maintain the Castle USB stack for the company's USB podules. According to Dave, the Iyonix stack and podule stack have separated, and there are features present in the Iyonix stack that are missing from the podule card. Dave hopes to backport these features for podule users if he is granted access to the stack source code.

Speaking at the London RISC OS usergroup, Dave also encouraged more programmers to step forward and write USB drivers. While demonstrating USB development and prototyping devices he has created RISC OS support for, he said writing drivers for both the Castle and Simtec USB stacks was not difficult - although he found the Castle stack easier to write software for. Dave has previously produced a number of USB drivers for RISC OS.

He said: "My message is simple - writing USB drivers isn't very hard to do."

Dave added that if the RISC OS 5 USB stack gains isochronous support and the Simtec USB stack does not, the Simtec solution will be at a significant disadvantage.


Castle USB technical notes Simtec USB technical notes

Previous: Blogging helped me code says developer
Next: ROS must open up to survive says Wild


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

Good news, now all we need is the same for the Simtec USB stack which I'm hoping is still being developed.

 is a RISC OS Usermfraser on 19/7/06 6:53PM
[ Reply | Permalink | Report ]

This is intresting stuff, I look forward to seeing what is possible.

 is a RISC OS Userjamesp on 19/7/06 9:45PM
[ Reply | Permalink | Report ]

In erply to mfraser:

What we need is just one USB stack for all - or at least one common interface for both so that there is no need to write apps etc. using USB to support both stacks.

 is a RISC OS Userhzn on 20/7/06 7:11AM
[ Reply | Permalink | Report ]

hzn>Support the USB stack that has the most applications then - that would the DeviceFS/Castle one. Besides the Castle one offers USB2 while the Simtec one doesn't (though to be fair this is a hardware limitation).

Isosynchronous support is one of those *must have* features (and full marks to John Ballance and associates on that). I would query though how practical it would be for (video) on the slow podule bus of the RISC PC - it should work better on the Iyonix. Should be the encouragement I need now is to upgrade beyond 5.03 and get the USB 2.......

 is a RISC OS UserAMS on 20/7/06 1:24PM
[ Reply | Permalink | Report ]


In the "ROS must open up to survive says Wild" article you equated open sourcing RISC OS to "advocating an approach that would [...] lead to further fragmentation". hzn has suggested a solution which would mean that USB developments would benefit both Castle and Simtec users, yet you, instead, are effectively advocating abandoning all those users with Simtec podules and the increasing number of users with an A9home.

Are you sure you're interested in preventing "further fragmentation"?

 is a RISC OS Userfylfot on 20/7/06 2:20PM
[ Reply | Permalink | Report ]

fylfot>Think about it logically for a sec. We currently have *two* USB stacks. One of those stacks (the DeviceFS/Castle one) is getting Isosynchronous transfer support added. Nothing else has changed - no extra fragmentation (isosync is *part* of the USB standard so should already have some representation in both stacks- even if the actual functionality was not implemented).

In response to hzn I was suggesting that we standardise on the stack that has the most capabilities (and I'd consider Isosync a *biggie*). That stack would be the Castle/DeviceFS one - if it were adopted by *all* vendors then we'd have *less* fragmentation. I am not sure how acchievable that is (are there commercial/business/licensing or technical issues that would prevent Castle's USB stack being deployed on an A9) but the suggestion I made is, I feel, more likely to yield the best overall results. Certainly more so than trying to implement an overarching abstraction layer that accomodates the existing two stacks - or going back to square one and coming up with a single unified (but different) third USB stack model.

 is a RISC OS UserAMS on 20/7/06 7:50PM
[ Reply | Permalink | Report ]

fylfot: How does dropping one USB stack and focus entirely on the other work against "preventing further fragmentation"? Wouldn't that do the exact opposite, help prevent the fragmentation? After all, dropping one stack and focusing on the other leaves one stack to work on instead of the current two!

That was not hzns exact words but would be a way of accomplishing what he pointed out when he wrote: "What we need is just one USB stack for all". Whether or not AMS' suggestion is the best way is a matter of opinion but surely not opposing this!

 is a RISC OS UserGulli on 20/7/06 8:00PM
[ Reply | Permalink | Report ]

An alternative may be to provide a module which implements the DeviceFS API but calls down to the Simtec stack.

 is a RISC OS Userjamesp on 20/7/06 8:23PM
[ Reply | Permalink | Report ]

jamesp>That's quite true - an ingenious solution too.

I must complement you on your site discussing the USB API ([link]) very informative it is too.

Making a module implement DeviceFS and calling down to the Simtec stack would definately provide the programmer with a coherent single API interface (at the the expense of some lost speed). Any USB device supported in that way would then have the virtue of running on Castle Iyonix/RPC USB Podule/A9Home/Simtec Podule. Probably as close to a single USB API as we're likely to get that can run on all platforms.

It would *not* however provide additional functionality not afforded by the Simtec stack itself (it wouldn't magically add Isosynchronous transfers or USB 2 if the underlying stack didn't know how to do this). But at least it *might* allow the task of supporting USB devices in a crossplatform manner that little bit easier.

 is a RISC OS UserAMS on 20/7/06 8:47PM
[ Reply | Permalink | Report ]

The USB notes have moved to [link] now, so they can be maintained by anyone who's interested. I'm going to remove the ones from my site now.

I don't know how involved my suggestion would be, I'm not at all familiar with the Simtec API.

 is a RISC OS Userjamesp on 20/7/06 9:07PM
[ Reply | Permalink | Report ]

In reply to hzn: "What we need is just one USB stack for all - or at least one common interface for both so that there is no need to write apps etc. using USB to support both stacks."

That would be ideal, but unfortunately I can't see that happening any time soon, can you?

 is a RISC OS Usermfraser on 21/7/06 2:57PM
[ Reply | Permalink | Report ]

mfraser: Which brings us back to the $64K question of exactly what are RISC OS Open Limited planning.

 is a RISC OS UserJWCR on 21/7/06 10:03PM
[ Reply | Permalink | Report ]

Would be nice to see this sort of thing on the Simtec stack. I did ask STD about this (in the context of the Unipod) but their response was something to the effect of 'it's unlikely to happen, but it might - in any case, don't hold your breath'... Having spent the money on a Unipod, I'm beginning to think I might have been better off buying a Castle USB card instead. That said, I've sold my spare IDE interface and Ethernet card, so there's no going back now...

 is a RISC OS Userphilpem on 29/7/06 12:54AM
[ 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

  • Cross platform development
    Building RISC OS Programs on Windows
     47 comments, latest by EasyKees on 07/10/04 8:05PM. Published: 24 Sep 2004

  • Random article

  • WindowManager and FontManager are ROOL batch two priority
    Wimp and font modules hoped for next shared source release
     Discuss this. Published: 25 Sep 2007

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    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
    "I was going to say something then but I remembered you're a reporter. So I won't"
    Page generated in 0.1075 seconds.