ADFS Format

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

ADFS Format

Post by geraldholdsworth » Wed Jan 24, 2018 4:57 pm

Hi all,

As you may have seen, I was asking for help on the newer ADFS formats. I was asking because I'm writing a class, in Delphi, which will (eventually) be able to load an ADFS image and allow you to extract the files. In actual fact, this has developed from the original code that opened a DFS image and extracted files, to ADFS (old map), to Commodore 64 images, to ADFS (new map). In order to, hopefully, make sure I can remember how ADFS does it in the years to come (and to help others who, in the future, may also want to do something similar) I've begun writing the attached document explaining it all in a, hopefully, much simpler way. There's still lots to do (like include the aforementioned formats, as well as Amiga adf and Sinclair/Amstrad dsk), but it's a start.

It will eventually make it's way onto my own page at http://www.geraldholdsworth.co.uk. Comments are, of course, welcome.

Cheers,

Gerald.
Attachments
Acorn ADFS.pdf
(187.26 KiB) Downloaded 58 times
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
jgharston
Posts: 3129
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: ADFS Format

Post by jgharston » Wed Jan 24, 2018 5:09 pm

geraldholdsworth wrote:It will eventually make it's way onto my own page at http://www.geraldholdsworth.co.uk. Comments are, of course, welcome.
I think something stronger than Paracetamol is needed to understand 'new map' and 'big map' disk allocation. I took me hours to get a good idea of 'new map' in my head, and 'big map' is still slipping from my grasp.

At least the directory structure is nice and clear, both 'old dir' and 'new dir'.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

steve3000
Posts: 1874
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: ADFS Format

Post by steve3000 » Wed Jan 24, 2018 11:54 pm

Brilliant resource, very useful to see this all in one place. Interesting to read about the 'G' format, I don't recall having seen that before, was it ever supported by RISC OS do you know? Or was it just theoretical?

Anyway thanks for sharing!

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Wed Jan 31, 2018 4:51 pm

steve3000 wrote:Interesting to read about the 'G' format, I don't recall having seen that before, was it ever supported by RISC OS do you know? Or was it just theoretical?
I've never seen it before and only became aware of it when a friend sent me a portion of the FileCore source code and pointed out the G format descriptor.

I've updated the document - found a few mistakes, plus added a bit more (I actually then used it to write my code, and realised that it wasn't as intuitive as it should be) and have found a home for it here:
http://www.geraldholdsworth.co.uk/DiscI ... cImage.pdf
where I'll update it every so often. The accompanying Disc Image project (http://www.geraldholdsworth.co.uk/code. ... =DiscImage) will also get a link to the document, and I'll add an update date on the page so you don't need to download it to see if it has been updated.

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Wed Feb 07, 2018 11:37 am

jgharston wrote:I took me hours to get a good idea of 'new map' in my head, and 'big map' is still slipping from my grasp.
Hi Jonathan - I noticed that your page:
http://mdfs.net/Docs/Comp/Disk/Format/ADFS
has reverted back to an older version, as it now refers to the directory identifiers as being 'MICK' and not 'NICK'. Could this have happened when you had your domain issue?
(I was using a saved copy of this page as reference before, and I'm sure it had this corrected...pity as I've now deleted it)
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
jgharston
Posts: 3129
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: ADFS Format

Post by jgharston » Wed Feb 07, 2018 8:46 pm

geraldholdsworth wrote:Hi Jonathan - I noticed that your page:
http://mdfs.net/Docs/Comp/Disk/Format/ADFS
has reverted back to an older version, as it now refers to the directory identifiers as being 'MICK' and not 'NICK'. Could this have happened when you had your domain issue?
Could be. I've just checked my archive of my server dated 31-Aug-2017 and it contains the file dated 04-Apr-2013, with no reference to Mick/Nick, so the update and regression happened recently. I'll turn the Beeb on and re-update it.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

sirbod
Posts: 843
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: ADFS Format

Post by sirbod » Sat Feb 10, 2018 1:50 am

geraldholdsworth wrote:
steve3000 wrote:Interesting to read about the 'G' format, I don't recall having seen that before, was it ever supported by RISC OS do you know? Or was it just theoretical?
I've never seen it before and only became aware of it when a friend sent me a portion of the FileCore source code and pointed out the G format descriptor.
From memory, either the 710 or 711 supported octal density. G would be the RISC OS equivalent of PC 2.88mb which were available for a while, so F with double the sectors and zones.

I used to have a few drives at one point, which I think I pulled from some Compaq servers in the early 90's. I don't ever recall seeing any specific media for them, although some HD media may also have supported ED. The same thing goes for the 120mb floppies which I definitely still have one of for posterity, I seem to recall they used lasers to read the disc...but I digress as they used an IDE interface.

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Sat Feb 10, 2018 10:46 am

sirbod wrote:G would be the RISC OS equivalent of PC 2.88mb which were available for a while, so F with double the sectors and zones.
I was always under the impression that standard floppy discs had a maximum unformatted capacity of 2MB, so this took me a bit by surprise. Of course, having different drives and media would be the other option (I do remember the LS120 drives).

I've updated the document now, a few more times. It has it's own page, although the link direct to the PDF above still works:
http://www.geraldholdsworth.co.uk/code. ... ption2.txt

I'm currently still working towards a complete document - the latest addition (not in the one published) includes details of DFS.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
jgharston
Posts: 3129
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: ADFS Format

Post by jgharston » Sun Feb 11, 2018 5:49 pm

I've updated my ADFS format documentation correcting some errors I and others have spotted, and trying to clarify a few points, particularly where I'd glossed over between offsets into a disk image and logical sector offsets into a physical disk.

I'm afraid even reading your version of 'new maps' I still glazed over. :(

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Sun Feb 11, 2018 6:48 pm

jgharston wrote:I'm afraid even reading your version of 'new maps' I still glazed over. :(
I've just re-read that part of it, and I can see it still isn't as clear as planned. I'll have to revisit the wording, try and make it clearer.

When Jasper explained it to me, I still glazed over. He did say that when he saw it, it was like a "lightbulb moment", as he put it. It still took me ages to see it - hence the reason for the document. Multizones was then another kettle of fish.

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Mon Feb 12, 2018 1:59 pm

jgharston wrote:I'm afraid even reading your version of 'new maps' I still glazed over. :(
I've re-written the section on Allocation Maps. It now reads:
New Maps are laid out, well, like a map. This map is scaled down so it can be fitted into a sector. The scale is defined by the bpmb entry in the disc record (1<<log2bpmb), where 1 bit in the map represents bpmb number of bytes (bpmb = bytes per map bit). The file objects (i.e. files and directories) are split into 1 or more fragments so that they fit into the disc. These fragments are given IDs, which are labelled on the map. The distance the beginning of these IDs is from the beginning of the map indicates how far into the disc they are. The end of the fragment is marked by a bit being set (after the ID). The distance from the beginning of the ID to, and including, this bit represents the length of the fragment. A file object may be split into more than one fragment and, as such, will have the same fragment ID appearing more than once in the map.
As the map is contained within an entire sector, and the capacity of the discs gets bigger, either the scale will need to be adjusted accordingly, or more sectors will need to be used. As it happens, Acorn chose the latter. Instead of a map spreading across sector boundaries, Acorn chose to use zoning. This is where the map is then split into different zones, which can be likened to being spread across several pages. Each zone is then confined to single sectors, but the scale can then be adjusted to zoom in a little. However, multizone maps will be discussed later.
Acorn refer to this layout of the fragments as the Allocation Bytes, and, on E and E+ format discs, appears at adf offset 0x0040 - this is the four-byte zone header followed by the 60-byte disc record.
The file objects' fragment IDs are indicated in the directory entries, and are listed as 'Indirect Address'. This is also the same for the root, which is specified in the disc record. This Indirect Address is a three-byte value (four-bytes with Big Directories), which breaks down to:
0fffffff ffffffff ssssssss
where f is the fragment ID and s is the sector offset. This is assuming an idlen of 15, which specifies how long the fragment ID can be - the maximum possible, under RISC OS 5.23 currently, is 21 bits (hence the four-byte indirect address with Big Directories). The top three bits of a four-byte indirect address will be the disc number (the three-byte address is made up to four bytes by the addition of the disc number).
Instead of the paragraphs there, just before the examples given (writing English, and explaining things, was never my strong point).
Does that sound clearer?
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

Phlamethrower
Posts: 69
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: ADFS Format

Post by Phlamethrower » Mon Feb 12, 2018 8:59 pm

As someone who's read a lot of technical documentation over the years but has never managed to get his head around the ADFS/filecore format, here are my thoughts:
  • A picture is worth a thousand words! Good diagrams might be a pain to create but they're well worth it in terms of aiding comprehension.
  • As I understand it there are two or three "layers" to the system - e.g. the disc is split into zones, zones contain objects, and objects can be files or directories. Split your explanation into different sections along those lines - start with a diagram and explanation which shows how a disc is split into zones, then show and explain the structure of each type of zone, then show and explain the structure of the different object types. Or even if you don't go with that ordering, at least start with an overview that explains how the different components fit together.
  • I know you're mainly approaching this in terms of floppy discs, but starting off with a table of specifications for the different floppy formats is only likely to confuse the reader. Try starting with just a generic LBA hard disc (where the only two parameters are the sector size and the number of sectors), then go into the specifics of how the format is adapted for floppies, CHS, etc. later on.
  • A glossary might be useful
I haven't tried reading through them, but maybe try looking at Microsoft's documentation for the MBR & FAT for some inspiration (they have useful-looking diagrams, which is what attracted my attention to them)

https://technet.microsoft.com/en-us/lib ... 76786.aspx
https://technet.microsoft.com/en-us/lib ... 76720.aspx

User avatar
martinw
Posts: 1295
Joined: Sat Nov 13, 2010 10:31 am
Location: Aberdeenshire, Scotland
Contact:

Re: ADFS Format

Post by martinw » Tue Feb 13, 2018 3:18 pm

Phlamethrower wrote:A picture is worth a thousand words! Good diagrams might be a pain to create but they're well worth it in terms of aiding comprehension.
+1 :D

Moving pictures are worth a million words!

http://williamson-labs.com/

Martin

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Tue Feb 13, 2018 4:50 pm

Phlamethrower wrote:A picture is worth a thousand words! Good diagrams might be a pain to create but they're well worth it in terms of aiding comprehension.
I've used examples, but maybe I should highlight certain sections for these examples. I have written guides before (like on how to use all the equipment in a radio studio, and instruction manual for my Repton Map Display) and have used screen shots, or photographs, with the arrows and boxes that Word provides. Food for thought.
Phlamethrower wrote:As I understand it there are two or three "layers" to the system - e.g. the disc is split into zones, zones contain objects, and objects can be files or directories. Split your explanation into different sections along those lines - start with a diagram and explanation which shows how a disc is split into zones, then show and explain the structure of each type of zone, then show and explain the structure of the different object types. Or even if you don't go with that ordering, at least start with an overview that explains how the different components fit together.
Yep - I'm starting with this, but then move onto multi-zones, etc. Thought I'd try and explain the basic concept first.
Phlamethrower wrote:I know you're mainly approaching this in terms of floppy discs, but starting off with a table of specifications for the different floppy formats is only likely to confuse the reader.
Each chapter starts with the list of "perfect" shapes (this document now includes DFS as well as ADFS, and will eventually include Commodore and Sinclair/Amstrad). Yep, I am concentrating on floppy images, but have just written a section on ID-ing an ADFS disc which mentions about hard discs, and how not to reject an image because of certain values as it may be a hard drive image.
Phlamethrower wrote:A glossary might be useful
Not a bad idea.

I'll upload the latest version in a moment.

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
pau1ie
Posts: 528
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford
Contact:

Re: ADFS Format

Post by pau1ie » Wed Feb 14, 2018 10:34 am

This might be beyond the scope of your document, but I am struggling to understand how a disc works and how much of that is replicated in a disc image.

On a 5.25" floppy the head is moving around the track. To get the catalogue you move the head to track 0, but how do you know when it starts? I know there are index pulses from the hole, so I assume that is involved. Is the track number stored somewhere on the disc, or does the computer need to remember where the head is?

I understand tracks are split into sectors, but I don't know what that means (A track is obvious, but why split it up?). Also, there is a Cyclic Redundancy Check (CRC) which I assume is some type of checksum on the data in the sector to ensure the data written is the same as that read back. I am not sure whether this is used in disc images, but I think it is because I understand the copy protection on some games need an invalid CRC to work properly. How is it stored? Also, is the sector number stored in the sector? I guess it must be because I read articles about getting extra performance by trying to start sector 0 of track n+1 where the head is likely to be after reading track n and stepping in. If so, is this replicated on an image file?

I am not sure how useful I will find this information, but for some reason the gap in my knowledge bothers me! Having said that, I have gained some knowledge from your document about disc image formats, so it is already a useful resource. Thanks for taking the time to create it.
I'm working on http://bbcmicro.co.uk

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: ADFS Format

Post by Coeus » Wed Feb 14, 2018 11:38 am

pau1ie wrote:...On a 5.25" floppy the head is moving around the track. To get the catalogue you move the head to track 0, but how do you know when it starts? I know there are index pulses from the hole, so I assume that is involved.
Limiting the discussion to soft sectored discs, which the common ones, the index hole provides the cue for the disc controller to start recording when formatting that track. To format a disc the formatting programs lays out the exact sequences of sectors and gaps in memory for a track, has the controller write this to the disc, then repeats for the next track etc.
pau1ie wrote:...Is the track number stored somewhere on the disc, or does the computer need to remember where the head is?
Before the data in each sector is a header which includes the track number and the sector number.
pau1ie wrote:I understand tracks are split into sectors, but I don't know what that means (A track is obvious, but why split it up?).
If this was not done the minimum unit of information that could be written to disc would be a whole track. On a standard Acorn DFS disc this is about 2.5K. That means if you opened a file for writing, for example BASIC's PRINT# and the like, the DFS would have to claim 2.5K of memory so it could keep a copy of the whole track in memory and then write it out periodically and when the file closed.

Splitting the track into sectors means that now a sector is the smallest amount that can be written in one go so that memory requirement has been reduced to 256 bytes. What happens when you write a single sector is that you get the controller to step the head to the right track then issue the command to write the sector. The controller starts reading the sectors until it finds the header for the sector to be written. There is a gap between the sector header and the start of the data which gives the controller time to switch from reading to writing and write the sector contents to disc.
pau1ie wrote:Also, there is a Cyclic Redundancy Check (CRC) which I assume is some type of checksum on the data in the sector to ensure the data written is the same as that read back. I am not sure whether this is used in disc images, but I think it is because I understand the copy protection on some games need an invalid CRC to work properly. How is it stored? Also, is the sector number stored in the sector? I guess it must be because I read articles about getting extra performance by trying to start sector 0 of track n+1 where the head is likely to be after reading track n and stepping in. If so, is this replicated on an image file?
There are two fundamentally different ways to store floppy images for use in emulators. The simple way, which is adequate in many cases, is to store only the data in the image file. All the other information that would be on a real disc is omitted including all the track/sector IDs, the CRC, the gaps etc. When code running in the emulator issues a command to the floppy disc controller to read a sector the emulator performs a simple multiply calculation: track * sector * bytes-per-sector to seek to the appropriate place in the image file and reads the data there. This "data only" approach is what is used in the common SSD and DSD disc images and their ADFS versions (ADF, ADL etc.).

The other approach is to encode everything that was on the original disc including the IDs, the gaps, even bits with dodgy levels. That can then cope with all the non-standard discs including sectors where the track number in the headers is not the same one as the physical track it is located on, bad CRCs, out-of-order sector numbers etc. I know FDI disc images take this approach but I don't know the internal details - you'd have to find the documentation.

Much of what I have said here will be easier to understand by referring to this diagram from the i8271 datasheet:
Screenshot from 2018-02-14 11-47-09.png

User avatar
pau1ie
Posts: 528
Joined: Thu May 10, 2012 9:48 pm
Location: Bedford
Contact:

Re: ADFS Format

Post by pau1ie » Wed Feb 14, 2018 12:36 pm

Wow, thanks. I'm going to have to read that a few times for it to sink in!
I'm working on http://bbcmicro.co.uk

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: ADFS Format

Post by crj » Wed Feb 14, 2018 3:17 pm

Coeus wrote:If this was not done the minimum unit of information that could be written to disc would be a whole track. On a standard Acorn DFS disc this is about 2.5K. That means if you opened a file for writing, for example BASIC's PRINT# and the like, the DFS would have to claim 2.5K of memory so it could keep a copy of the whole track in memory and then write it out periodically and when the file closed.
Even worse, you would be faced with two choices:
  • Round the size of each file up to the nearest 2.5Kbytes
  • Load the entire track into RAM, modify it and write it back if you wanted to store a new file in a part-used track.
The need to set aside 2.5K of RAM for the second option is not the only problem: you'd also reduce the disc's life by increasing the number of times each part of it was written to, and you'd risk losing an existing file every time you wrote a new one.


One detail which may be easy to overlook: a floppy drive can't turn the write head on and off with pinpoint accuracy. The reason there has to be a gap between sectors is so that there's space for the drive to be sure of having switched on the write head before the next sector spins round, while also being sure not to have switched it on before the previous sector has finished. (Secondarily, drive spin speeds aren't as precise as you might expect: if you write a sector twice, it can take up a tiny bit more space the second time.)

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: ADFS Format

Post by Coeus » Wed Feb 14, 2018 4:01 pm

crj wrote:...Load the entire track into RAM, modify it and write it back if you wanted to store a new file in a part-used track.
This read-modify-write arrangement is exactly what DFS has to do if you write into the middle of a file, except it does it for sectors rather than tracks. If you write this in basic:

Code: Select all

F%=OPENUP"File"
PTR#F%=100
PRINT#F%,45
CLOSE#F%
Position 100 is not on a sector boundary and the length of the value 45 is less that a sector so DFS will have to read the first sector of the file into memory, modify the four bytes at location 100 and write it back out again.

The bigger the smallest unit you can write is the longer that process takes as well as the increased wear. So it is a compromise. Smaller sectors enable less reading/writing of unchanged data in this way as well as less wasted space at the ends of files but it also means more of the potential capacity of the disc used by gaps and sector headers rather than data.

User avatar
BigEd
Posts: 1974
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: ADFS Format

Post by BigEd » Wed Feb 14, 2018 6:39 pm

I'm not sure there's any wear involved when writing to a floppy. There will be wear according to how much time the disk rotates under the (loaded) head, but because the disk keeps spinning for a while after each access, that might be regarded as per-track wear rather than per-sector wear, and would be the same for reads and writes.

Might be interesting to note that the Amiga did access its floppies a track at a time - the sector structure was there, but the gaps could be minimal and so more sectors could be fitted into a track.
Last edited by BigEd on Wed Feb 14, 2018 6:41 pm, edited 1 time in total.

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Wed Feb 14, 2018 6:41 pm

pau1ie wrote:This might be beyond the scope of your document, but I am struggling to understand how a disc works and how much of that is replicated in a disc image.
Yep, I'm afraid that accessing actual discs is beyond the scope of the document, and me. The formats described are as they are laid out on the disc. If you were to read the data direct off a disc, using an OSWORD call (IIRC), it is how it will appear in memory.

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Thu Mar 01, 2018 1:21 pm

Found an oddity with ADFS hard drive disc images (i.e. those with .hdf extensions). The ones I've been looking at are those supplied with Arculator and RPCemu.

Basically, these have the boot block at offset &E00, and not &C00 where all the documentation and source code says it should be. But then all the offset calculations are &200 bytes out. For example, the disc record points towards the map being at &191B000, but is actually at &191B200.

Is there something I'm missing? How do the emulators work OK with it like this? (OK, I know a simple work around, like adding &200 to everything, but would love to know the reason why).

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
jgharston
Posts: 3129
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: ADFS Format

Post by jgharston » Thu Mar 01, 2018 2:43 pm

Some emulators stick a header on an image file to describe the geometry of the device the image was taken from. For example, the MyZ80 CPM disk image format has such a 256-byte header which means all access has to have &100 added to it. RPCEmu and Arculator could be doing the same thing.

An initial thought on identifying the type of disk image is to look for the start of the root directory.
* If it is at &200 then it's at 256-byte sector ADFS disk image with no header
* If it is at &400 and there's a footer at &6FC then it's a 256-byte sector ADFS disk image with a header
* If it is at &400 and there's a footer at &BFC then it's a 1024-byte sector ADFS disk image with no header
* If it is at &600 then it's a 1024-byte sector ADFS disk image with a header

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Thu Mar 01, 2018 4:16 pm

jgharston wrote:Some emulators stick a header on an image file to describe the geometry of the device the image was taken from.
These are all just zeros...unless it is just reserving the area for this purpose.
jgharston wrote:An initial thought on identifying the type of disk image is to look for the start of the root directory.
This is how ADFS actually does it, from what I can tell in the source code. I decided to use this as a secondary check, after initially determining the map type and directory type from the headers (although, I seem to remember, I go hunting for the root directory instead of assuming it is at &200, or &400).

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
billcarr2005
Posts: 1204
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: ADFS Format

Post by billcarr2005 » Thu Mar 01, 2018 9:06 pm

pau1ie wrote:This might be beyond the scope of your document, but I am struggling to understand how a disc works and how much of that is replicated in a disc image.
Somewhat related to your query, here are the details from a single track from the Tynesoft game "The Big KO"... using Acorn 1770 DFS, I read the entire track 0

Code: Select all

THE BIG KO TRACK 0
------------------

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  gap
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF     
FE                                               index mark?
00 00 00 00 00 01                                index?
FE                                               sector ID mark
00 00 07 01                                      track, head, sector, size (sector ID)
68 44                                            sector ID CRC
FF FF FF FF FF FF FF FF FF FF                    gap
00 00 00 00 00 00                                sync bytes
FB                                               data mark
[256 bytes]                                      data
EB CB                                            data CRC

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF     gap
00 00 00 00 00 00                                sync bytes
FE                                               sector ID mark
00 00 08 01                                      track, head, sector, size (sector ID)
78 7A                                            sector ID CRC
FF FF FF FF FF FF FF FF FF FF                    gap
00 00 00 00 00 00                                sync bytes
FB                                               data mark
[256 bytes]                                      data
20 00                                            data CRC

...
sectors 09, 00, 01, 02, 03 ,04, 05
...

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF     gap
00 00 00 00 00 00                                sync bytes
FE                                               sector ID mark
00 00 06 01                                      track, head, sector, size (sector ID)
5B 75                                            sector ID CRC
FF FF FF FF FF FF FF FF FF FF                    gap
00 00 00 00 00 00                                sync bytes
FB                                               data mark
[256 bytes]                                      data
05 85                                            data CRC

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  gap
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF
DF
One single track, &A00 (10 x 256 bytes) of data requires &C2D / 3117 bytes on the disk surface.

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Mon Mar 26, 2018 11:24 am

Just a quick note to say that I've uploaded the latest version of this document, which now includes details on the AmigaDOS format (that other *.adf and *.hdf file extension format), plus a few other minor adjustments (and some more details included in this thread about physical disc formats, just for completeness).
I've also uploaded the latest version of the code.

Both are still a work in progress, so any mistakes/bugs I notice, or are pointed out to me, will be rectified.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Wed May 23, 2018 9:12 am

It's been pointed out to me about the ordering of files on ADFS. There is nothing in the PRMs, that I can see, that suggests that the files stored on disc need to be in alphanumeric order. On investigating (using TextEdit on my Mac to change filenames around), I have found:
* BBC Master ADFS doesn't care when reading the directory structure in what order the files are in (Old Map, Old Directory, or 'S', 'M' and 'L' formats). But it does appear that it sorts them before writing the directory structure back out.
* RISC OS 5.24 (and presumably all RISC OS) ADFS does care about order when reading in, and will report a Broken Directory...OK, only tried this on an Old Map, New Directory ('D' format) disc.

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

sirbod
Posts: 843
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: ADFS Format

Post by sirbod » Wed May 23, 2018 11:37 am

geraldholdsworth wrote: * RISC OS 5.24 (and presumably all RISC OS) ADFS does care about order when reading in, and will report a Broken Directory...OK, only tried this on an Old Map, New Directory ('D' format) disc.
I've randomly seen this error when cataloguing old format discs (eg Zarch and Conqueror) but I've not managed to track down the root cause as I've never been able to reliably reproduce the error.

FileCore will be generating the error, so it would also occur on other filing systems that are FileCore based, not just ADFS. I wouldn't expect the order of files to be an issue, its more likely the directory was malformed. From a quick skim through the FileCore source code, the error only occurs under the following conditions: ADFSBuffers is also a contributing factor here as FileCore checks the cache, just something to be aware of, particularily on RISC OS 3.5 and earlier where there are known bugs around background transfers.

User avatar
geraldholdsworth
Posts: 373
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: ADFS Format

Post by geraldholdsworth » Wed May 23, 2018 4:14 pm

sirbod wrote:I've randomly seen this error when cataloguing old format discs (eg Zarch and Conqueror) but I've not managed to track down the root cause as I've never been able to reliably reproduce the error.
Silly me - I was swapping single characters of filenames around to change the order which worked OK on old directories as the directory check byte doesn't come into play. But, for new directories it does, and it calculates it word by word, instead of byte by byte. For the new directory structure I was swapping two filenames (of equal length) over which obviously screwed up the check byte.

There are four reasons I've found, so far, to cause Broken Directory:
1. 'HUGO'/'NICK' don't match on the head and tail on Old or New Directory;
1a. 'SBPr' and 'oven' are not at the head and tail respectively on Big Directory;
2. Start sequence and end sequence do not match;
3. Directory check byte does not add up on New or Big Directory.

Although looking at the code you pointed to, another reason for Broken Directory would be the size not being right (checked under sanity check). I don't think the ADFSBuffers is a contributing factor in my cases, but I'll be aware of it now.

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

Post Reply