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

RISC OS 5.10 readied for release

By Chris Williams. Published: 21st Sep 2005, 14:04:40 | Permalink | Printable

Updates to USB and Nvidia drivers, whispers of multi-cored CPUs

Castle have issued a new RISC OS 5 ROM for brave Iyonix users to beta test. Version 5.10 is mainly a bug fixing exercise, and coincides with a USB mass storage update that also corrects a few glitches.

"It is intended that these updates will go in general circulation in a few days time, unless anything hugely untoward crops up. We have been running these for a while now," said Castle's John Ballance. Iyonix users have already noticed problems with RISC OS 5.10 and QuickFiler.

The ROM also includes an updated driver module for the Nvidia GeForce 2 graphics card, using knowledge gleaned from the BeOS related Haiku project. The new module is capable of accessing the BIOS on the Nvidia graphics card, presumably so that the OS can easily identify the revision of the graphics card present and other details that may vary over time as Nvidia manufacture new cards. John added that GeForece 4 support was still some way away.

Silicon overview of an ARM coreIPTV teasing
Castle's Jack Lillingston recently gave a talk at a London user group, and mentioned some developments regarding multi-cored processors. The company is still working on IPTV based products for clients, and will be sticking to XScale processors for their desktop computers. For the STB work, RISC OS 5 could run on a processor with multiple cores, although the OS would execute on a single core, leaving the others to handle networking and video decoding, for example.

An example IPTV box is expected to be on display at the South East show next month.


Iyonix website

Previous: 'Experienced' users offered A9homes to test
Next: ROL cuts deal with Omega users


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

What I'd love from USB mass storage is to be able to use >2GB devices, because then I could use my Iyonix to put stuff onto my MP3 player, but I guess that's a much bigger problem. In any case, it can't encode them anywhere near as fast as my laptop :-(

 is a RISC OS UserSimonC on 21/9/05 3:45PM
[ Reply | Permalink | Report ]

SimonC: You already can. The caveat is, however, that the devices need to be FileCore formatted. DOSFS is still limited to 2GB.

 is a RISC OS Userjmb on 21/9/05 4:34PM
[ Reply | Permalink | Report ]

The problem is that MP3 players mostly use FAT formated drives.

 is a RISC OS Usernetec on 21/9/05 4:48PM
[ Reply | Permalink | Report ]

netec: Yes. My point was, however, that the limitation is not in the USB mass storage subsystem but in the RISC OS filing system design.


a) FileSwitch allows a maximum file size of 4GB (2^32-1). b) FileCore allows a maximum file size of 2GB (2^31-1). c) Image filing systems are limited by the maximum file size supported by the underlying "real" filing system. d) DOSFS is an image filing system. e) SCSIFS is a FileCore-based FS, and thus subject to FileCore's filesize limit (see b) f) USB mass storage devices appear to the system as SCSI discs (thus using SCSIFS for access). g) FAT formatted USB mass storage devices are accessed via DOSFS which sits on top of SCSIFS. h) Thus, by "c", "d" and "e", FAT formatted media accessed via DOSFS over SCSI are limited to a maximum size of 2GB.

How to fix this? Simple; allow FileSwitch and FileCore to use larger values for maximum filesize.

 is a RISC OS Userjmb on 21/9/05 5:51PM
[ Reply | Permalink | Report ]

Is it that simple (not that that sounds all that simple)? Wouldn't DOSFS also need updating - presumably in it there's something like a 32 bit file pointer?

 is a RISC OS UserSimonC on 21/9/05 6:02PM
[ Reply | Permalink | Report ]

SimonC: It's conceptually very simple, yes. Actually implementing it is an entirely different matter.

Of course, there is another way in which large FAT formatted media could be accessed; write a "real" filing system that directly accesses devices which are registered with SCSIdriver.

 is a RISC OS Userjmb on 21/9/05 8:35PM
[ Reply | Permalink | Report ]

It's a while ago and i do not have the technical background but how does SCSIFS affect SCSI devices? I have had a SCSI harddisk with 10 GB and i used the full capacity in one partion. I guess i am mixing up something, don't i?

Sincerely Hauke

 is a RISC OS UserVLIW on 21/9/05 9:41PM
[ Reply | Permalink | Report ]

In reply to VLIW:

You're mixing maximum partition size with maximum file size. This is only related in the special case of image file systems where files are treated as partitions.

 is a RISC OS Usermaus on 21/9/05 10:38PM
[ Reply | Permalink | Report ]

netec : To throw a spanner in the works, I have come across an MP3 Player that uses NTFS? obscure company, not sure what it was now.....but windows sees it as NTFS, and my yepp T6 as FAT.

Grr to oversights!

 is a RISC OS Userem2ac on 22/9/05 9:54AM
[ Reply | Permalink | Report ]

The problem comes from the way our system works. When a drive is to be mounted FileCore issues Service_IdentifyDisc which is monitored by image fileing systems. DOSFS/Win95FS tells it that it knows of the drive's formatting and FileCore let it handle the drive as an image file (and since files are limited to 2GB, only drives <= 2GB are thus supported).

What we should have is what I would call sector/block mode filing systems. FileCore would issue a similar service to Service_IdentifyDisc that such FSs would monitor. These FS would not access the disc as an image file but by using the FileCore_SectorOp API. They could provide disc logical formating routines (i.e. routine to set up boot blocks, initial maps and root directory). We would then have a FATFS for handling FAT16/32 discs, one could write a Ext3FS to support this Unix format, etc.

 is a RISC OS Userandretim on 22/9/05 12:59PM
[ Reply | Permalink | Report ]

Extending previous comment (Firefox textarea limit?):

The ADFS/Filecore (damn naming confusion) disc structure could even be extracted from FileCore and turned into a separate block mode FS, let say OSFS, leaving only device management and the disc access API into FileCore. Better still we could start from a clean new module and API let say DiscCore whithout the limitations of FileCore with regard to the number and nature of devices, which already cause problems to USB. FileCore would then just be an empty shell redirecting calls to DiscCore.

This module could be designed with nice feature in mind such as device listing API and partition management, offer to handle itself disc icons and get rid of all those dupplicate xxx_filer modules. Actually we shouldn't even need to have ADFS/IDEFS/SCSIFS only modules which register devices and drivers to DiscCore and CDFS or maybe to an even more generic DeviceCore module understanding device classes USB style dispatching them in turn to device class modules (DiscCore, CDCore, DVDCore, ...).

 is a RISC OS Userandretim on 22/9/05 1:26PM
[ Reply | Permalink | Report ]

"These FS would not access the disc as an image file but by using the FileCore_SectorOp API."

But then you lose the advantage of being able to have a foreign partition as a file. Wouldn't it just be easier to lift the 2GB limit?

 is a RISC OS UserIvanDobski on 22/9/05 3:26PM
[ Reply | Permalink | Report ]

Then the ADFS part of FileCore could be just another image filesystem and FileCore would become just a layer for generic block filesystems :-)

RISC OS 5 has at least made a start on some of the annoying file system features. The SCSI stuff has been seperated into a generic bit and a hardware specific bit. IIRC there are changes to the FileCore API to allow enormous discs and more devices, even if nothing uses them yet...

Also, why isn't the CDFS filesystem stuff an image filesystem, is accessing a data CD significantly different from accessing a SCSI or ATAPI disc, or did CDFS predate image filesystems?

 is a RISC OS Userjamesp on 22/9/05 4:24PM
[ Reply | Permalink | Report ]

To andretim: your suggestion to call directly FileCore_SectorOp is unfortunately a short term solution. The architectural best solution is extend FileSwitch (the mother of all FS, including FileCore) for >31bit file size access, even directory enumeration and file info and catch other fish by this as well (like >2GByte files on FS which support this (like most network based onces)).

The fact that FileCore needs to be used when ImageFS needs direct access to its media is not logical when we are talking about media which are not supported by FileCore. Eg. CDFS. Currently you can't neatly support other CD/DVD fileformats just by implementing a ImageFS. Typically this is worked around by writing a FileCore based FS talking to CDFS which then make FileCore say "oops, this is not a FileCore formated media; let's ask around for a suitable ImageFS".

It is wrong that Service_IdentifyDisc is FileCore specific, it should be possible to let CDFS/USB Mass storage issue a Service_IdentifyDisc alike service call directly (without the need to have a FileCore based FS on top of CDFS/USB Mass storage) so that if you don't have FileCore in RISC OS, this still would work.

 is a RISC OS Userjoty on 22/9/05 4:49PM
[ Reply | Permalink | Report ]

In this article: [link] I talked about some of the ways that the whole ADFS et al software stack ought to be designed, although it doesn't touch too much on some of the important specifics that joty's named above.

 is a RISC OS Usermrchocky on 22/9/05 10:53PM
[ Reply | Permalink | Report ]

In reply to IvanDobski and jamesp:

Who still use an image file these days? I have since long stopped using my PC card and removed the half empty PC image files that were taking space for nothing on my HD. Anyway it would be a matter of hours to write a module that would fakes such files as an HardDisc.

DOS/ADFS Image files just contains sector/block organised data like real disks so the corresponding filing systems so tehy will read data from it by blocks just as they would have done using a SectorOp API and when accessing real devices FileCore translate their access into sector/block reading operations anyway. The advantage is that you don't need to rewrite first FileSwitch, FileCore and whatever who knows whatever other modules first to support files larger than 2GB.

 is a RISC OS Userandretim on 23/9/05 12:49PM
[ Reply | Permalink | Report ]

"Also, why isn't the CDFS filesystem stuff an image filesystem, is accessing a data CD significantly different from accessing a SCSI or ATAPI disc, or did CDFS predate image filesystems? "

I think it did predate image filing systems, viz there was a version of CDFS for RISC OS 2.

 is a RISC OS UserIvanDobski on 23/9/05 1:15PM
[ Reply | Permalink | Report ]

In reply to joty:

You can issue all services you want but you also need an API to access your device. I would be in favor of a central device manager with device classes USB style. The module handling for example the IDE interface would then for example scan the interface to identify device and tell the device manager: I have device 0 which is of category "HardDisc" and you can be accessed through this "HardDisc" interface, device 1 is of category "DVD" and can be accessed though this "ATAPI" interface, ... The device manager would then register device 0 to FileCore for identification by FileCore/DiscCore standard API using FilingSystems, device 1 to a DVDCore for identification by DVDCore standard API using FilingSystems, etc.

 is a RISC OS Userandretim on 23/9/05 1:19PM
[ Reply | Permalink | Report ]

To andretim: "You can issue all services you want but you also need an API to access your device."

Just let the new Service_IdentifyDisc service call (lets call it Service_IdentifyDisc2) specify the SWI number which needs to be used to read the media. Which of course needs to be able to go beyond 2 GByte. Every issuer of this new Service_IdentifyDisc2 fills in the SWI appropriate for its media reading. That's just to broken aspect (and nothing more) of the original Service_IdentifyDisc API, i.e. the API specifies you have to use a FileCore SWI so e.g. CDFS can't use this.

"...central device manager..."

I think this is too complicated and I fail to see the additional advantages.

 is a RISC OS Userjoty on 23/9/05 5:08PM
[ 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

  • Archive booklets review part one
    MessengerPro, VirtualRPC, simple networking and programming guides
     20 comments, latest by jlavallin on 19/12/05 3:28PM. Published: 12 Dec 2005

  • Random article

  • Archive usage survey: VRPC edges past Iyonix
    RiscPC king still rules the land
     84 comments, latest by datawave on 17/11/05 01:27AM. Published: 10 Nov 2005

  • 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
    "So, if I had 'teased' you with spin you might have printed it. Instead because it was simply factual you decided not to"
    Page generated in 0.2034 seconds.