Date   : Sun, 02 Jan 2011 22:51:21 +0100
From   : rick@... (Rick Murray)
Subject: Patching a CF card patched ADFS

On 02/01/2011 00:35, J.G.Harston wrote:

> There was a big reallocationing sometime in the early 1990s which
> pruned Acorn's huge claimed chunk an rationalised things a bit.

I can see the stable door, but I can't see the horse anywhere...


> HardwareDriverX_ReadSectors, HardwareDriverXX_WriteSectors is all
> that's needed.

I've considered writing a veneer to allow ADFS to "talk" to FileStore 
floppies, but the whole thing just seemed to be complicated. I recall, 
also, some quirk in the link-in code (sorry it isn't specific, it was a 
decade ago - the bit that links in as a filing system) where what the 
PRMs said and what actually arrived were totally different things. My 
code was called when a disc of unknown format was inserted, and it 
attempted to read the first sectors of the disc to ID the disc, but 
regardless of what I set the code to (claim anything as "ours" or say 
"not known"), my code was never called again. It's like ADFS 
(FileSwitch?) called me, ignored the reply, then reported the standard 
"Not understood" response.

I asked around for the DOSFS sources (to see how that worked) but as 
nothing was forthcoming, I gave up.


> The whole point of writing device drivers instead of whole filing
> systems is to leave all the complexity higher up in
> pre-existing code,

...which works to a point. The point being where you need to support 
stuff that ADFS can't do.

You see, the *idea* is that it is supposed to be easy and simple. DOSFS 
shows how. But DOSFS is well within the capabilities of something ADFS 
could do itself if you patch the sources to understand the disc. 
Multi-Gb multi-partition drives, the ability to mount/unmount 
partitions, etc. Does vanilla ADFS do any of this even as yet?


> I can imagine hearing Acorn saying "...but you've just duplicated
> xxx-thousand lines of pre-existing code to re-invent a pre-existing wheel!"

And I can imagine <developer> saying "...no, we duplicated xxx-thousand 
lines of code in order to get it working the way it should have done in 
the first place."


> A single common CDROMFS instead of at least three different CDROMFSs.

Mmmm... I'm aware of three:

1. The Morley version, doesn't do ATAPI as it talks SCSI to a SCSI bus.

2. The lesser Acorn version. Made by somebody else, incidentally.

3. The Warm Silence one, does fancy filenames and such. [though I think
    the later RISC OS (>=4) does this sort of thing too?

Back the the dark ages, CD-ROM drives were notoriously tricky little 
buggers, and tended to need specific drivers. Then ATAPI came along, and 
it took market forces plus a couple of years of procrastination before 
that worked. Even today you'll get units that won't work with harddiscs, 
or refuse to be slave, or rubbish like that. A single common CDROMFS 
might be viable these days (I think the Warm Silence one is a single 
type?) but originally there needed to be... many... and in this case 
even then some things were highly quirked if you didn't have the exact 
sort of drive the FS was written for. I managed to get some sort of 
eesox (sp?) driver to talk to my ancient CD drive, but it never managed 
to eject the platter via code. I had to reach forward (okay, all of a 
matter of inches) and poke the button.


> Quite a bit of it was Acorn letting things run away from them too
> quickly.

Or burying their heads in the sand. Make no mistake, some of the 
technical innovations going on were mind-blowing. Thank God the ARM 
legacy is still with us today. I also believe that small embedded 
devices do not require Linux, they could have used a patched up version 
of RISC OS.

Take a look through my b.log sometime and look at the stuff I've written 
about the Neuros OSD. Basically it is an ARM926 (or something like that) 
bolted to a DSP. 16Mb Flash, 64Mb RAM. SD/CF/USB and network support. It 
is, basically, a fancy video recorder. Sure, people have made it sing 
and dance in cute ways, as it is not unlike a proto Beagleboard. But its 
goal in life is to be a video recorder.
Does it need Debian and Qt4? My god, the install of the more recent of 
the firmwares (that moved to Qt4) requires a CF card to always be 
inserted as the code outgrew the 16Mb Flash.
You tell me a reasonably complete RISC OS, the Ingenient codecs, and 
some UI code couldn't fit into that. Given the base size of RISC OS 3.70 
(and I'd say a fair whack of that stuff wouldn't even be necessary), you 
will probably have space left over. Okay, it won't be as feature-rich as 
the Debian installed, but why the hell am I actually running lighttpd on 
my video recorder?!?

But RISC OS was never really developed that much. Niall Douglas wrote 
some rather interesting code to pre-empt certain things, but I got the 
feeling he was jeered more than applauded, which is a shame as patching 
some of that functionality into RISC OS itself probably wouldn't have 
been terribly difficult. That's not to say a pre-emption hybrid would be 
useful in an embedded device, but these are the things Acorn should have 
been considering. It was a powerful, lightweight, damn-easy-to-use OS 
that could have made in-roads in the embedded scene. Now we're looking 
at "AndroidLite" for these lower end devices (where "whoo, my processor 
is faster than yours" doesn't figure into the equation much).


> I've gone blurry-eyed working my way through FileSwitch/FileCore/
> ADFS code and documentation way too many times. ;)

I went blurry eyed (and slightly insane) trying to decypher the 
paragraphs describing the New Map.


Best wishes,

Rick.

-- 
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...