Castle releases Acorn SCSI source - RISC OS News, Software and Information

Castle releases Acorn SCSI source

Published: 1st Jul 2003, 20:05:19GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

Beckoning 'SCSI-like' device support

At the start of May this year, Castle Technology announced some details of a SCSI driver framework for the Iyonix. Some time after the announcement, their SCSI documentation page was eventually graced with lots of API details.

On Monday this week, Castle released the source code to an example SCSISoft driver, which in reality is the driver for the Acorn SCSI card. The example driver and included documents are useful for developers wishing to implement support for a SCSI based storage system.

"An increasing number of devices are using SCSI command protocols over
non-SCSI connections", Castle claim in the new SCSI documentation. "Examples include ATAPI (SCSI-over-ATA), Iomega Zip drives (SCSI-over-Parallel) and USB Mass Storage devices (SCSI-over-USB)."

Castle's new "SCSI switcher" filing system enables "multiple 'SCSI-like' interfaces can be handled simultaneously". So, as an example, you can use a SCSI harddisc (with suitable interface card) and a SCSI-like USB file storage device at the same time through Castle's central SCSIFS.

It's clear that Castle are keen to woo third party developers to the Iyonix platform. Given that the computer boasts USB and PCI expansion capabilities, there's a vast range of existing PCI and USB based hardware so RISC OS developers can concentrate on just the drivers. An immediate pool of existing available drivers can be found grazing in the open source Linux arena, however these all require a high degree of low level porting to get them up and running on RISC OS.

Links
SCSI API details

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

[Printable] [Digg this] [Blog search]

NudeLooney 2/7/03 8:51PM	Smashing! Example code is always nice! If anyone from Castle is reading this ... could we have examples for PCI and USB too?
mrchocky 2/7/03 9:05PM	Castle already provide examples for USB (last time I checked, anyway). As for PCI, it's so simple it's barely worth it. If you know enough to program your PCI device, then you'll know enough to use the API - which, as we know, resembles the Linux one. The complex bit of programming PCI drivers is invariably actually driving the device, rather than the simple task of actually gaining access to it. -- Peter, drobe.co.uk
tribbles2 3/7/03 9:49AM	This is all very well and good, and having a centralised filing system is a nice idea - my problem with it is that FileCore is limited to 8 devices which means that rather than having 4 different FSses each with 8 devices (ie. a total of 32 devices), you've now got 1 FS with 8 devices. 1) Unless RISC OS 5 has got over the 8 device limit 2) Unless I'm the only kind of person who will have more than 8 devices
mrchocky 3/7/03 10:13AM	1) Alas, no. I hope this might be changed in future, but I'm not sure what implications that might have. 2) You're mad. Anyway, it's heading in the right direction. -- Peter, drobe.co.uk
hubersn 3/7/03 10:18AM	http://www.iyonix.com/32bit/FileCore.shtml says that there are now (using Filecore_DiscOp64) 8 bits for the drives, so we now have 256 possible drives per FS. However, I am not sure if the SCSIFS stuff already supports it. I think the next important step should be to raise that 2 GB per file limit - I feel lots of new interesting variants in every RISC OS API under the sun coming up...
tribbles2 3/7/03 12:27PM	*In reply to hub:* I'd forgotten about the 64-bit FileCore stuff. However, FileCore also needs to be able to add/remove drives at whim, rather than at initialisation time - otherwise you'd tend to get a few entries in the Task Manager (for E+ format drives). Of course, the number of SCSI drives is a configurable parameter, but having to restart SCSIFS (or even the machine - it's not something I've needed to do) because you've just plugged in a new device which can't be accessed because of too many drives can be (is) an annoyance. Name resolution will also be a problem (ie. drives with the same name but on different media) - does anyone know what SCSIFS (or even ADFS) does with this (not tried it before, and ADFS is at home )? The Iyonix's DOSFS with correct drive names helps here... 2GB per file limit will become more and more of a bummer, and 64-bit FileSwitch needs to be implemented.
Smiler 4/7/03 4:19PM	2GB per file is a bummer? What are you trying to store? Hard-drive images? Surely for nearly everything except emulation 2GB is more than adequate. -- Smiler - Alex Melhuish
tribbles2 4/7/03 4:28PM	Three occasions where you'd get >2G files: 1) Databases 2) Video 3) Hard drive images It may be surprising, but of the three, the third is what I'm going to find first. Or rather, DOSFS images for PC cards (since DOSFS uses FileSwitch).