Large disc record wiki entry

I’ve updated the FileCore Large Disc Record as it was missing the Zones MSB and the Format version fields.

I’m not sure what to call the non-extended Format version though so I’ve called it “Small directories” – is there an official name for the original FileCore version before Extended/Big Directories was added?

I got the field information from HForm, not any official documentation, so it needs four-eyes and amending/correcting if necessary.

That matches what I have in DiscKnight, which is a relief.

Before “Big Directories”, there were “Old Directories” and “New Directories”. That’s official filecore naming from PRM2.

Is it worth to discriminate between the RO 3.6 stuff (big disc) vs. the RO 3.8 stuff (big directories)? RO3.6 did not have the nzones_2, format_version and root_size entries.

there were “Old Directories” and “New Directories”.

If I recall correctly E format (new) could support 77 files per directory, while D format (and was there L or was that on the Master?) only supported 47 files per directory (old).

discriminate between the RO 3.6 stuff (big disc) vs. the RO 3.8 stuff (big directories)?

It’s two different but related things (sizer of entire disc, size of directory entries) so it would make sense to.

If I recall, RAMFS uses big directories but an old disc layout (hence the 512MB limit)?
That might have changed since I last looked, it’s been a while…

If I recall correctly E format (new) could support 77 files per directory, while D format (and was there L or was that on the Master?) only supported 47 files per directory (old).

E/F is new map/new dirs, D is old map/new dirs (i.e. “map full” and regular compacting needed), L is old map/old dirs.

Old dirs are restricted to 7 bit ASCII (because the top bit is used for flags) and 47 entries.

It’s two different but related things (sizer of entire disc, size of directory entries)

IMHO these things are completely unrelated and, even mopre importantly, orthogonal – you can have a non-big disc with big dirs and the other way round.

Maybe it would be good to state also disc size limits there (byte vs. sector addressing wrt the “big” flag).

Thanks for the correction Steffen. It’s been a small eternity since I used anything older than E format.

There are:

• Old format
• New format
  And:
• Old directories
• New directories
• Big directories

The common ‘shapes’ of ADFS are:
S,M,L : Old format, old directories
D : Old format, new directories
E, F : New format, new directories
E+, F+ : New format, big directories

I’ve documented them here:
https://www.geraldholdsworth.co.uk/documents/DiscImage.pdf
(which is actually me reading the current documentation then re-writing it as something that I, and hopefully others, will understand)

The “official” docs are scattered around PRM2, PRM5a and the Ursula docs, which make them a bit harder to read than necessary. But I think they are quite understandable. But I also read Gerald’s effort, and find it equally readable!

And soon, really soon now, I will release some software that makes use of all the knowledge gained from reading this stuff.

Sounds interesting Steffen. Can’t wait to see it.

Is it anything like Disc Image Manager?
https://github.com/geraldholdsworth/DiscImageManager/releases/tag/V1.43

Yes, it is similar to DiscImageManager (or more like your previous one, DiscImageReader, because it is currently Read Only), but it will focus on slightly different features (mostly the planned features for the future to be honest). I just decided that I need to stop piling features and need to release it. This year. Really.

The list of features I want to add to it is at least double the size than what I already included. Go figure. Still pondering if I should try to include direct USB device access. And the StrongHelp viewer. And the ZIP and Arc/Spark support. And the ISO9660 export. And being a true Windows/Linux/MaxOS filer. And partitioning scheme support for all SCSI and IDE podules. And adding a ShareFS server.

The list of features I want to add to it is at least double the size than what I already included.

Not to forget direct floppy access via GreaseWeazle and/or Fluxengine and/or KryoFlux.

That sounds absolutely fantastic. Far more advanced that what I can achieve. I did think about adding direct SD card access, but couldn’t work out how to do it.

I’ve got a feeling most people use Disc Image Manager to access DFS images anyway.

A lot of the extra features I’ve added have been by request – e.g., Spark (and PackDir) support, DOS access, Acorn FS support, etc. I’m just working on a major revamp of the code to deal with multiple (ADFS and >1 DOS, and Amiga RFS) partitions.