RISC OS 5.10 readied for release | Drobe.co.uk archives

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 core

IPTV 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.

Links

Iyonix website

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

Discussion

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

SimonC 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.

jmb on 21/9/05 4:34PM
[ Reply | Permalink | Report ]

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

netec 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.

Specifically:

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.

jmb 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?

SimonC 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.

jmb 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

VLIW 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.

maus 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!

em2ac 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.

andretim 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, ...).

andretim 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?

IvanDobski 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?

jamesp 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.

joty 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.

mrchocky 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.

andretim 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.

IvanDobski 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.

andretim 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.

joty 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

South East 2008 show photos
If a picture tells a thousand words, here's a short story

8 comments, latest by hzn on 22/10/08 10:03AM. Published: 20 Oct 2008

Random article

Punter bitten by fraudsters after using R-Comp site
Holy insecure HTTP, Batman!

26 comments, latest by TonyStill on 23/6/06 11:21PM. Published: 17 Jun 2006

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Drobe often has glaring factual errors that could simply be avoided with the bare minimum of research"
Page generated in 0.0563 seconds.