Simtec USB/Unipod support

Idea: port the RISC OS 5 USB stack to Unipod and Simtec USB hardware using the existing PUSBDriver.

This is an idea I’ve done some preliminary work on, but as ever run out of time.

We all know about the fork of RISC OS USB stacks: in the red corner, the Castle/Iyonix/ROOL stack, in the blue corner the Simtec stack. Development on the Simtec stack seems to have ground to a halt. In addition, some poor design decisions cause unnecessary restrictions (for example, on MassFS 1 on podule hardware there’s no way to read mass storage blocks above 2GB, even if you have a filing system that can cope).

But Simtec USB is hard to ignore, because the vast majority of shipped hardware uses it.

So, why not port the RISC OS 5 USB stack to the Simtec hardware? That would mean one uniform platform for RISC OS USB development. An older version of the stack will already softload on the Castle USB podule, so it should work on older OSs. This would also mean USB would work on Risc PCs running RISC OS 5.

Both the Simtec USB podule and the Unipod use the ISP1161 controller for USB. Now it turns out in the ROOL source tree that there’s already an ISP1161 driver – PUSBDriver. So it should just be a case of tweaking this for the memory map of the podule or Unipod.

For the USB podule, some trial and error revealed the address mapping here: http://www.riscos.info/index.php/Simtec_USB_technical I so far haven’t had time to modify PUSBDriver to test it.

I don’t have a Unipod, but perhaps someone with it could work out and have a go at tweaking the PUSBDriver code to target that hardware.

Hardware loan could be arranged.

Updating PUSBDriver to support Simtec’s products sounds like a good idea to me.

However, it’s worth pointing out that there are two versions of the Castle USB stack – the original stack developed for the USB podule (which I think was written entirely by Castle themselves) and the NetBSD-based stack that was used in the Iyonix. As I understand it the podule stack isn’t as good as the NetBSD stack, and although the two can coexist side-by-side, using a machine with both stacks present would obviously result in increased RAM/ROM (and potentially CPU) usage. Plus maintaining two stacks is always going to be more effort than maintaining just the one, and will cause problems for people who write device drivers (since the stacks don’t have the same set of features available), etc. For instance I’m not even sure if SCSISoftUSB works with the podule stack.

So long story short, I think it would be good to try and rewrite PUSBDriver so that it interfaces with the NetBSD stack instead of Castle’s original stack. This would probably involve rewriting the module in C, to ensure it uses the right structure formats when talking to the rest of the stack. Hopefully it won’t take that much work to rewrite the code – I think it will all depend on exactly how well the internal podule stack API matches up with the internal NetBSD API.

Also it’s worth pointing out that there is a 32bit version of the podule USB stack available, so there’s nothing stopping us from getting PUSBDriver working with Simtec cards first, and then worrying about rewriting PUSBDriver later.

I think I’ve got myself confused. I was referring to PHCIDriver:

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/PHCIDriver/

Looking at the source there are some copyrights of Acorn Network Computing 1996, and it mentions STB targets. Would that be related to Castle’s stack, or the Pace version? It appears to be written almost entirely in C.

I’m completely in accord with ignoring Castle’s stack – the Castle podules are a bit neglected and support even less hardware than Simtec does. Is there likely to be a problem with running the Pace/ROOL stack on RISC OS 4?

Would that be related to Castle’s stack, or the Pace version?

PHCIDriver would almost certainly be for the Castle/podule stack. Or perhaps for an even older stack that never made it to desktop machines; I haven’t really looked at the code much.

It appears to be written almost entirely in C.

You clearly are confused – PHCIDriver is written in assembler :)

Is there likely to be a problem with running the Pace/ROOL stack on RISC OS 4?

None that I know of.

Porting the Castle stack to work with the Simtec USB interface (Podule, UniPod & A9home(?)) would be good, especially if it did away with the 2GB hard limit and also removed the need to have separate drivers for each Mass Storage device! I don’t think the Castle USB podule is a concern, there can’t be many people who still have one, and they’re not still on sale anyway.

(Speaking personally!)

OK, that’ll teach me to post and talk on the phone at the same time :)

What’s the provenance of the Castle/podule stack? Was it something Castle knocked up themselves, or did they licence it from Pace? It’s interesting that all the code is copyright Castle (AFAIK), and that there’s no source release of it. Any ROOL folks like to comment?

I don’t think I’ve ever seen the source code to the Castle podule – I’d be surprised if it was ever in our repository. I don’t know what Castle’s plans are with respect to publishing the sources, but porting our existing (RO5) USB stack to the podule would probably be a bit easier if they were published.

IIRC, the PHCIDriver was written to add support for USB printers to a RISC OS 7500FE-based STB design. The ‘P’ stood for Philips, the designers of the IC in question, since it had a rather unique programming interface. In theory it should at least provide a good reference for driving any other boards that use the same IC.

It is also my impression that the Castle podule drivers never made it into the same repository as the other sources. They were, after all, written before Castle acquired RISC OS.