Smiler
14/5/04 1:33PM |
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.  |
JWCR
14/5/04 1:51PM |
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? |
IvanDobski
14/5/04 1:57PM |
You certainly won't need to buy a new harddisc. Harddisc formatting software has been included with every version of RISC OS |
jbyrne
14/5/04 2:00PM |
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? |
nunfetishist (-1.0)
14/5/04 2:04PM |
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. |
diomus (+1.0)
14/5/04 2:08PM |
In reply to 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
14/5/04 2:11PM |
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. |
IvanDobski
14/5/04 2:14PM |
Form the press release at http://www.iconbar.com/pressreleases/?action=show_page&dir=castle&file=0405141208350409
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. |
spellinn
14/5/04 2:36PM |
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/ |
diomus
14/5/04 2:37PM |
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. |
nunfetishist
14/5/04 2:48PM |
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)? |
adrianl (+1.0)
14/5/04 3:24PM |
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. |
ksattic
14/5/04 4:14PM |
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). |
nunfetishist
14/5/04 4:20PM |
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. |
simo
14/5/04 5:13PM |
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  |
spellinn
14/5/04 5:14PM |
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/ |
AMS
14/5/04 6:08PM |
In reply to 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 RiscPC's HDD controller (thankfully)
|
md0u80c9
14/5/04 7:00PM |
In reply to simo:
the chip may be different, but ADFS itself isn't. That's one of the many reasons why ADFS is so slow. The RiscPC 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 . |
TonyStill
14/5/04 10:11PM |
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. |
hzn
15/5/04 10:18AM |
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 RiscPC 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 RiscPC 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.
|
md0u80c9
15/5/04 4:15PM |
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. |
nunfetishist
16/5/04 10:08PM |
Inside Acorn, apparently, FileCore was described as the 8-leter F word. |
md0u80c9
16/5/04 10:33PM |
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. |
zakalwe
16/5/04 11:28PM |
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? |
Sawadee
17/5/04 12:25AM |
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. |
spellinn
17/5/04 10:46AM |
In reply to md0u80c9:
ADFS does contain an ATA driver - otherwise UDMA100 hard disc access wouldnt work too well!
In reply to 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)
In reply to 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/ |
caliston2
17/5/04 12:15PM |
In reply to 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
17/5/04 12:18PM |
In reply to 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. |
AMS
17/5/04 1:36PM |
In reply to 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
17/5/04 1:38PM |
Another question might be where does a DeCSS type (Content Scrambling System Decoder) fit into all of this ???? |
| Use the forum for more comments on this article |
