Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.adm and .ads disc images treated as interleaved double-sided #198

Open
Radiorama7 opened this issue May 10, 2023 · 4 comments
Open

.adm and .ads disc images treated as interleaved double-sided #198

Radiorama7 opened this issue May 10, 2023 · 4 comments

Comments

@Radiorama7
Copy link

B-Em seems to treat .adm and .ads ADFS disc images as double-sided, interleaved, thus failing to read data beyond track 0/side 0. Verified in BBC Master Compact mode.

@Radiorama7 Radiorama7 changed the title .adm and .ads disc images treated as interleaved double-side .adm and .ads disc images treated as interleaved double-sided May 10, 2023
@SteveFosdick
Copy link
Collaborator

Before I change this, is there a reference to a convention that these image formats should have the side stored sequentially, or a body of files for which this is true? I know ADFS uses the sides sequentially but with the DSD files used for double-sided DFS discs the sides are independent so the way DFS uses them is certainly not why the tracks of the two sides are interleaved with each other in the image file. The reason for the interleaving is no doubt an historical accident in that someone presumably wrote a program to the read these discs on a PC and store the contents in a file and it is quicker to read each cylinder (the same track on both sides) before moving to the next rather than read one side completely and then the other. So the obvious question is are ADFS disc exempt from that accident, i.e. someone had said that the tracks should be stored in the file one side after the other?

@Radiorama7
Copy link
Author

Steve,
thanks for looking into this issue. Standard formats for ADFS floppy discs are ADFS L (80-track, double-sided, 640 kB), ADFS M (80-track, single-sided, 320kB), ADFS S (40-track, single-sided, 160kB). Images are usually saved in files with extensions .adl, .adm, and .ads, respectively. .adl images are usually interleaved, most probably for the very reason you stated above (it's quicker to read full cylinders while sitting on a track before moving on to the next track). The point here is that .adm and .ads are inherently single-sided, so there should be no interleaving because there's no side 1 anyway :)
I have .adm and .ads images that read correctly on ADFS Explorer and B-Em 2.2, which the current B-Em fails to read. *DUMPing files from beyond track 0 shows incorrect data, as if the wrong tracks were being read. Dumping the same files from ADFS Explorer after setting the "Interleaved"option shows the same (wrong) data, therefore it seems like B-Em is failing to set the correct Interleavedness after loading files with those extensions.

@SteveFosdick
Copy link
Collaborator

Could you attach one of the disc images that is failing to read correctly? Looking at the way the detection works, there is an extra step in that B-EM current reads the ADFS free space map and checks how many sectors are declared there and uses that to decide which format it is rather than trust the file extension.

@Radiorama7
Copy link
Author

Radiorama7 commented May 12, 2023

Ok, that's it. The .adm and .ads files I've been playing with declare 2560 sectors, that is the size of a double-sided disc. I'm attaching one of them. I found more .adm files that declare 1280 sectors (as they should) and they work perfectly with B-Em. So it is a matter of deciding which policy to follow - whether to trust the declared sectors, the file extension, or the file size. I'm afraid I haven't got a definite answer, but if it were me, I'd use the file size (if >327680, then double-sided and interleaved, else single-sided. I've never seen a non-interleaved .adl image).
Quest.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants