Cino and Castle hype new ADFS | Drobe.co.uk archives

Cino and Castle hype new ADFS

By Chris Williams. Published: 14th May 2004, 13:18:23 | Permalink | Printable

I've got the brains, you've got the looks

Castle and the CinoDVD team have "joined forces" to develop a new version of ADFS, the age old disc filing system designed by Acorn. Their combined efforts will hopefully "allow faster transfer of data through the RISC OS filing system, ADFS, whilst consuming much less CPU resources."

Which will be terribly useful for a DVD player, like the one that the Cino team pre-announced last year. It's expected that the new ADFS will provide the level of data transfer, from DVD drives and other media, to make real time DVD playback on RISC OS possible. Cino programmer Adrian Lees is also, incidentally, responsible for Aemulor, and so now his ARM optimisation skills are really going to be put to the test. The new ADFS development will perhaps again kick start further efforts to migrate software and hardware away from legacy Acorn era technology.

"I am delighted to work with Castle to provide the first RISC OS DVD player. The work we are undertaking will free up a lot of valuable CPU resources which are needed for decrypting and decoding the video and audio data," commented Neil Spellings, of the CinoDVD team.

"The product is destined to be called Cino and should be available later this year".

Links

CinoDVD website

Previous: Wakefield 2004 show guide
Next: Wakefield photos and gossip

Discussion

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

This is excellent news. If this is going to happen, then I hope they go back to the drawing board and think about this from stratch - there's plenty of inspiration available. Linux has several filing systems capable of storing files, quickly, up to terabytes in size. Also, the new WinFS system for <shudders> Windows XP 'Longhorn' is actually very impressive, and I certainly wouldn't complain if a similar database system were used on RISC OS. It can search files in mere seconds on any field reference - outstanding. I hope something good really does come from this, and it'll give me yetanother reason to upgrade.

Smiler on 14/5/04 1:33PM
[ Reply | Permalink | Report ]

For the unenlightened, exactly what needs to be upgraded in ADFS? Will the new version be backwards compatable, or will I need to buy a new Hard disc in the new format?

JWCR on 14/5/04 1:51PM
[ Reply | Permalink | Report ]

You certainly won't need to buy a new harddisc. Harddisc formatting software has been included with every version of RISC OS

IvanDobski on 14/5/04 1:57PM
[ Reply | Permalink | Report ]

Surely what Cino needs is a new CDFS, not a new ADFS. Is this a typo or have I got the wrong end of the stick?

jbyrne on 14/5/04 2:00PM
[ Reply | Permalink | Report ]

Do they mean ADFS or FileCore? (ADFS being essentially the IDE driver, and FileCore being the file system.) They're both due for a serious overhaul, really. I've often pondered looking at writing a replacement for FileCore myself based on one of the other freely available file systems. The "new" FileCore with >77 directory entries is all well and good, but it certainly doesn't match up to modern standards at all.

nunfetishist on 14/5/04 2:04PM
[ Reply | Permalink | Report ]

JWCR: As I understand things, ADFS is the low level software that talks to your hard disc, on behalf of other software. By improving ADFS, you can improve the way data is handled and passed around the system, which is what CTL and CinoDVD mean here.

You most probably will not have to buy a new hard disc, and although backwards compatibility can be possible, you may need to reformat to a newer disc layout (like the upgrade from E to E+ with RISC OS 4), to make use of any benefits - but this is all speculation based on previous changes to ADFS and such things.

It's early days yet, hence 'hype' in the headline, so we don't know of any specifics, unless one of the CinoDVD people posts a comment, sends an email or talks at a show/usergroup about it.

Chris. Just me.

diomus on 14/5/04 2:08PM
[ Reply | Permalink | Report ]

jbyrne and nunfetishist:

Um good point actually, is it actually ADFS that needs changing, or CDFS or the filecore layer? I bet everyone's too busy for the show to answer questions, something to bring up at the show, I think.

Chris. Just me.

diomus on 14/5/04 2:11PM
[ Reply | Permalink | Report ]

Form the press release at [link]

The current CD/DVD access in ADFS uses PIO modee and blocking I/O. This mean the CPU is heavily involved in transferring data from the CD/DVD drive, and that RISC OS cannot do anything else whilst waiting for data to arrive from the drive. This project will look at implementing DMA access to the drive, and providing a non-blocking interface to ADFS which Cino, and other applications and parts of RISC OS, could then use to speed up their own transfers and use less CPU in the process.

IvanDobski on 14/5/04 2:14PM
[ Reply | Permalink | Report ]

ADFS provides the SWI which CDFS (and DVDFS) use to communicate with the IDE devices, so its ADFS which needs tweaking.

This isnt going to be a re-write - its to implement features which are essential if we are to see DVD playback on RISC OS.

Cino /will/ effectively also replace CDFS with DVDFS, which can also read CDs and a whole lot more.

We cant just add the required functionality into DVDFS as we have to cooperate with ADFS transfers from the hard disc, so this functionlity is better placed in the OS - hence the development deal with Castle.

Come to Wakefield if you want to know more!

Cheers,

/Neil/

spellinn on 14/5/04 2:36PM
[ Reply | Permalink | Report ]

I've been reliably informed that.. "ADFS provides the underlying SWI (ADFS_ATAPIOP) which CDFS and DVDFS use to communicate with the device itself."

Chris.

diomus on 14/5/04 2:37PM
[ Reply | Permalink | Report ]

Shame really. FileCore's also quite a bit of a bottleneck in the whole chain. I'm deeply surprised that ADFS still uses PIO, however. Didn't most of the IDE podules use DMA (which is why they were always so much faster)?

nunfetishist on 14/5/04 2:48PM
[ Reply | Permalink | Report ]

PIO is only used for C/DVD access on the Iyonix. DMA was introduced for hard disks only. We're extending it to encompass CD and DVD drives too.

adrianl on 14/5/04 3:24PM
[ Reply | Permalink | Report ]

nunfetishist: Cards such as the Blitz! use PIO to communicate with the IDE drives and DMA to communicate with the host computer's memory system (except with the Kinetic - DMA isn't available at all there).

ksattic on 14/5/04 4:14PM
[ Reply | Permalink | Report ]

Ah, so they talk PIO to the drives, but the podule does all of the waiting, and then it shoves the data to the CPU/memory via DMA? That doesn't sound quite so bad.

nunfetishist on 14/5/04 4:20PM
[ Reply | Permalink | Report ]

But don't the third-party IDEFS's already totally outperform ADFS, or is that just down to the hardware (like Blitz, RapIDE, Simtec, Omega) surely the Iyonix isn't using the same hardware disk controller as the RiscPC?

Am I missing the point? Maybe someone should write a plugin for VRPC-SE that forks off DVD playing to PowerDVD

simo on 14/5/04 5:13PM
[ Reply | Permalink | Report ]

nunfetish: Its still bad because RISC OS is still going in circles waiting for the data to come into the podule then into main memory. All I/O is blocking at present.

Cheers,

/Neil/

spellinn on 14/5/04 5:14PM
[ Reply | Permalink | Report ]

simo>

The Iyonix uses the same southbridge as the Omega, and is capable of UDMA100 (except for the CD devices which still run in PIO mode). It does *not* use the RISC PC's HDD controller (thankfully)

AMS on 14/5/04 6:08PM
[ Reply | Permalink | Report ]

simo - the chip may be different, but ADFS itself isn't. That's one of the many reasons why ADFS is so slow. The Risc PC can't, AFAICT, support DMA on its internal interface, which is unfortunate.

I've pointed this out before, but there are billions of things you can do to ADFS to bring it up to date, and DMA transfers is a big one on a system that supports them. Creating a filesystem which uses DMA is itself not too difficult.

Filecore is a major bottleneck too - you can't, for example, command cache correctly using filecore, and the way it currently does its sector requests is pretty inefficient when compared to ATA or SCSI specs.

But that's a MUCH meatier job. Anyone who plays with Filecore though is incredibly brave. Or stupid. Or both. After all, it's possible, but much trickier, to cause data corruption in ADFS. Trashing a hard disc by modifying filecore is no doubt easy-peasy

md0u80c9 on 14/5/04 7:00PM
[ Reply | Permalink | Report ]

AIUI, it's blocking that's the issue here, not the access mode to the media itself. Crudely, RO provides blocking disc IO which means that when an application requests a disc (etc) fetch, the OS waits until the transfer is complete so it can give the data back to the application in responsponse to the request. Simple to use and understand.

However, there are issues of delay here, as the OS waits for the transfer to happen so it can return the data (discs still take time to physically access the right sector(s)); the CPU is effectively idling during this time.

An alternative strategy - non-blocking IO - is to allow the application to ask the OS to initiate the transfer, then go do something else and come back later to collect the data via a further request to the OS. More complex, but a suitably written application can then do something useful with the CPU time that is wasted in the blocking model.

Typically, an application would request the data from a disc that it needs for its next transaction, collect the data for the current transaction (that had been previously requested) and process it while the disc was delivering the next lot of data. The benefit comes from the parallel processing.

I think the relevance to a compute-intensive DVD player is pretty clear.

TonyStill on 14/5/04 10:11PM
[ Reply | Permalink | Report ]

This is good news, indeed. Firstly since it means that some interesting enhancement is on its way for the IYONIX pc and secondly since I think it good news so see such co-operation to happen between two companies in the RISC OS market.

Speeding things up is welcome all the time. If at the same time they enhance the disc drivers to support Joilet, DVD, VFAT32 and the like that would be good news, indeed. BTW, ADFS takes care of floppies too. Does that mean that their access will then perhaps not block the system as much as it does now (like DMA background transfers and real background formatting)? ;-)

Just a short notice on the Blitz IDE controller: True, that is a pretty fast IDE for the Risc PC using IDEFS. I managed to write CDRs at 12speed with source an IDE disc on Blitz and destination a CD writer on Eesox SCSI. AFAIK Omega uses IDEFS as well. At least I know that when my ex-Blitz (ex since I sold it as well as my Risc PC when moving to an IYONIX pc) had problems I got the replacement from MicroDigital so that there is a good guess that IDEFS if from MicroDigital and thus I don't expect that IDE driver and filingsystem to find its way into the IYONIX pc.

hzn on 15/5/04 10:18AM
[ Reply | Permalink | Report ]

Tony,

I agree - non-blocking IO would be exceptionally handy, but would involve a major re-work of Filecore, which as I stated earlier, is a job for those who wear teflon underpants. OK, I didn't state that, but you get my gist

. DMA would be the very least. There are lots of other problems within ADFS - I don't know which of those Pace have solved and which they haven't.

md0u80c9 on 15/5/04 4:15PM
[ Reply | Permalink | Report ]

Inside Acorn, apparently, FileCore was described as the 8-leter F word.

nunfetishist on 16/5/04 10:08PM
[ Reply | Permalink | Report ]

I believe that this is still true for all parties

. The 8-letter F word, and the equally sadistic 10-letter F-word are probably mysteries to almost all in the history of RISC OS.

I did the Select documentation for Filecore up to RISC OS 4 (NB nothing has changed since RISC OS 4 in any version of RISC OS except the very bare minimal scratchings on its surface!) Scared the wits out of me. Much qudos to Druck, who is the only one I know that even understands the Filecore disc format!

ADFS is mistakenly still two components in one box - a floppy driver (which includes legacy floppy drives, I'm sure,) and a hard disc driver. And by hard disc I mean an ST506/IDE driver, not an ATA driver.

md0u80c9 on 16/5/04 10:33PM
[ Reply | Permalink | Report ]

Why would it be especially handy for DVD playback? After all, most DVDs are recorded at around 8Mbit/s, which means the driver/controller just has to transfer and compute one megabyte of data each second. Is this a problem? Or is this about not being able to use the cpu for something else during DVD playback due to locking?

zakalwe on 16/5/04 11:28PM
[ Reply | Permalink | Report ]

Sounds like a good move for Castle and CinoDVD to give us a new ADFS to update our age old disc filing system. But is this unique change available for RISC OS 4 (Select) or is it another problem to choose if you want Select, a new ADFS, 26 or 32 computer. Choice may be great but not if our own platform is divided like two totally different computers, or am I still just Acorn minded? Steve.

Sawadee on 17/5/04 12:25AM
[ Reply | Permalink | Report ]

md0u80c9: ADFS does contain an ATA driver - otherwise UDMA100 hard disc access wouldnt work too well!

zakalwe: the problem is there so many CPU intensive tasks to be done as part of DVD playback: decryption, huffman decoding, IDCT, motion compensation, YUC colourspace conversion, scaling and finally screen plotting - and we havnt even touched on sound yet!

With blocking i/o we cant afford to waste any cpu time waiting for data to come in over the IDE bus - its not the speed of the transfer thats the problem - its cpu utilisation whilst its happening (from two angles - the current PIO mode involves the CPU for transfering the data which DMA wouldnt, and the blocking i/o makes the app sit in a loop waiting for the data to be present)

Sawadee: Our changes will be for RISC OS 5 only. No other RISC OS hardware is capable of doing what we need, so theres little point of implementing it on the slow IDE bus of RiscPC.

Cheers,

/Neil/

spellinn on 17/5/04 10:46AM
[ Reply | Permalink | Report ]

spellinn:

Am I right in thinking that the API will be something like: go fetch these blocks into this buffer and set a flag (pollword say) when you're done? Meanwhile the processor continues the task it was doing before? As opposed to the way most OSs do it which is to block on I/O as far as the process is concerned, but go and execute another process while that one is waiting.

The second is more general but I'm not sure it's something that fits too well into the RISC OS cooperative multitasking model. The first is obviously suited to Cino (assuming it's single threaded/processed), but I'm not sure that it's that useful to other applications because I don't know of too many cases where they can prefetch data. Will FileCore/Switch make use of this, or is it just at the block level?

caliston2 on 17/5/04 12:15PM
[ Reply | Permalink | Report ]

md0u80c9:

I've always thought that a FileCore replacement using a sensible filing system would be a good idea. Something like ext3/reiserfs/xfs might be nice. ROL mentioned something like this at Guildford last year, but nothing seems to have been talked about it since.

caliston2 on 17/5/04 12:18PM
[ Reply | Permalink | Report ]

caliston2>

Surely the *existing* ADFS handles UDMA transfers correctly and that has not had a negative impact on the Co-operative multitasking ? As far as I can tell all Castle will be doing is expanding ADFS to support UDMA for non-harddisk devices (ATAPI type CD/DVD devices).

Cino (for it's part) from the comments in this thread will implement a UDF 1.02 filing system (to support VideoDVD) when it makes calls to access sectors through ADFS these will now happen under UDMA rather than PIO (that change being made within ADFS itself).

AMS on 17/5/04 1:36PM
[ Reply | Permalink | Report ]

Another question might be where does a DeCSS type (Content Scrambling System Decoder) fit into all of this ????

AMS on 17/5/04 1:38PM
[ Reply | Permalink | Report ]

@AMS: In the application handling the content, of course (CSS = content scrambling system).

anon/195.227.111.2 on 17/05/04 2:34PM
[ Reply | Permalink | Report ]

At the RISCOS presentation Paul Middleton's stated that they are also working on a replacement for ADFS, are we getting 2 new ADFS's or one?.

Pete on 17/05/04 3:51PM
[ Reply | Permalink | Report ]

Again, the use of ReiserFS or XFS will not happen while RISC OS is so primitive. They both depend heavily on multithreading, and RISC OS is only just developing that properly in userland, let alone kernel land. Even ext2 would be a wonderful step forward. FileCore is horribly simple, and frankly cack, by even 15 year old standards.

nunfetishist on 17/05/04 6:11PM
[ Reply | Permalink | Report ]

In reply to 195.227.111.2 >

I know CSS is Content Scrambling System (I was however referring to the decoder hence my mention of Content Scrambling System Decoder). Specifically I was wondering if the deCSS part would be a stand alone Relocatable Module (as deCSS is somewhat warm to the touch

and is covered by the GPL I'd expect that is what would happen).

If Cino uses a licensed CSS decoder the bully for them (in which case it would be - as you say - part of the application).

AMS on 17/05/04 6:42PM
[ Reply | Permalink | Report ]

The CSS licence fee is astronomical. I'm interested to know how Cino can afford it if it's a "legitimate" licensee. The DVD consortium don't seem too worried about it however, as they've not chased the numerous free software products. These days, you don't even need the DVD-ROM drive's co-operation, as you can crack the key in a number of seconds these days.

I'm also interested in the price of Cino. Considering you can get real DVD players for less than 30 quid these days, it should certainly be priced around that area, otherwise there isn't much point. (You could watch DVDs on your Iyonix by visiting Tesco and Asda and buying one of their cheap DVD players, and buy the supported TV card, and not waste all those CPU cycles otherwise!

nunfetishist on 17/05/04 11:05PM
[ Reply | Permalink | Report ]

nunfetishist: You can also buy your Iyonix with the necessary TV card pre-fitted, now.

But that doesn't stop lots of people wanting a native software RISC OS solution.

dgs

dgs on 18/05/04 01:31AM
[ Reply | Permalink | Report ]

nunfetish: You are right, the DVD standards books and logo certification cost around £10k which is totally out of reach for a market this size.

Your point about pricing is one we are aware of, although you could argue that as you can get a PC for 1/3 price of the Iyonix which "does the same thing" then why pay 3 times the price for the Iyonix?

Cheers,

/Neil/

spellinn on 18/05/04 07:50AM
[ Reply | Permalink | Report ]

spellinn: I wouldn't argue that. People who have bought an Iyonix bought one because they prefer it. They'll be very little difference from the user's point of view from using a software DVD player, compared to a TV card and a 30 quid DVD player, except for a (small) amount of deskspace, and a hell of a lot of CPU time. So not only would it be cheaper, but it'd be faster, more convienant, and you'd have the peace of mind that you had a DVD logo certified player.

What you've got to work out is what is the small amount of desk space worth to people? Considering Asda's current 30 quid jobby has a tiny footprint, I'd think not a lot...

These days, you get Windows DVD playing software (in my case PowerDVD) free with DVD-ROMs that can be bought for 16 quid. It's going to be a tricky product to price. I certainly think it should be *no* more expensive than 30 pounds, pref. a lot cheaper, if I were ever to buy a copy. But I am not the world, and many RISC OS uses artifically maintain the market by buying things they'll never use.

nunfetishist on 18/05/04 10:41AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

Online banking with RISC OS
We thought this would be of high interest

28 comments, latest by devine on 25/9/05 8:30AM. Published: 1 Sep 2005

Random article

Google search toolbar updated
Searchy 1.60 features various tweaks and fixes

Discuss this. Published: 27 Oct 2007

Create a new account
Forgot your password?

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