Disc Image Manager

[billcarr2005]

Cheers Bill.
I did fix a Watford DFS bug in the last version. I'll have another look...I'm sure it should allow 62 files when it detects it as a Watford DFS - of course, it's going to be dependant on whether it correctly ids it as a Watford.

In case it helps any, here's the DSD i was using prior to dragging the additional files over

[geraldholdsworth]

It's working well on Big Sur on M1, and the weird Open dialog bug seems to have gone away too!

That is good news - thank you for trying that out. There is another bug, affecting the M1 on macOS - if you go to the About dialogue it'll probably say 'Version 1.38.5 OS? (CPU?)'. First, I forgot to update the version number, and then the compiler directives where not present for the aarch64 compiler - this will also affect the keyboard shortcuts - so it'll be CTRL instead of CMD. It's fixed for the next version.

[geraldholdsworth]

In case it helps any, here's the DSD i was using prior to dragging the additional files over

I have found that if the two sides of an image are of different sizes (like they are here) then it will fail to flag it as a Watford DFS. I fixed this bug ages ago for Acorn DFS but forgot about the Watford side of things...sorry!

I'm also going to work on being able to have an image with differing formats on either side - i.e. Acorn DFS one side and Watford the other.

[geraldholdsworth]

I'm after some opinions here. I've recently added into DIM the ability for it not to read in sub directories (and only when required). But, in order to show on the tree which directories have been read in and which haven't, I've changed the font and colour for those that haven't:

SubDirs not read in.png (50.36 KiB) Viewed 4940 times

SubDirs not read in (2).png (55.13 KiB) Viewed 4940 times

Which do you think looks better? Or a different colour/font style?

[baz4096]

To me, red looks like it cannot be read, like it’s faulty.

[Pernod]

To me, red looks like it cannot be read, like it’s faulty.

Agree, anything red draws your attention to indicate a problem.

[geraldholdsworth]

Never thought of that. Thank you.

I could use the red colour to indicate broken directories.

[geraldholdsworth]

I have just put version 1.40 on GitHub. For completeness, the updates are:

• Can now use a hybrid DFS image - i.e. one side as Watford the other side as Acorn.
• Can now choose not to scan all sub-directories upon opening. This speeds up the opening of, mainly, ADFS HDD images. The directories are then only scanned when they need to be.
• In the directory tree, directories are now different colours: Red means broken, Blue (and Italic) means not scanned.
• I've also changed the header text from red to dark green.
• I've done a lot more work with DOS and DOS Plus - you can now create blank floppies (360KB/720KB/1.44MB/2.88MB FAT12) and blank hard drives (FAT12). Can also create a 640KB or 800KB DOS Plus image. FAT16 may, or may not, work - this has not been fully tested. FAT32 does not work.
• Also, can now add a DOS partition to an ADFS image.
• Some more changes to the Acorn File Server, while I await further details about the differing formats: Max size of a partition/drive is now limited to 127MB. I've also begun to change the extraction of an AFS partition from a hybrid image - this is ongoing, so it won't produce a viable image.
• I've also improved the separation of the ADFS partition, and the DOS partition. Extracting the DOS partition from a 640KB hybrid floppy will have the header added to make it a proper DOS FAT12.

And some bugs fixed:

• The incorrect OS and CPU were reported in the about box on an ARM Mac (and some other features didn't work).
• A Watford DFS DS image would get incorrectly IDed as an Acorn DFS DS sometimes.
• The file details panel would sometimes not get fully repainted.
• Forgot to add the new file types to the filters on the Save dialogue box.
• The DOS partition of a 640KB hybrid wasn't getting read correctly.

As always, any bugs either email me, PM me, or drop a message here.

EDIT: Since putting this release out this morning, and then researching on how to support FAT32, I have found out that the calculation I use to find the FAT, and the root, on FAT12 and FAT16 is incorrect. Changing this should then make it support FAT32...in theory. Also, in theory, there could be some FAT12 or FAT16 images that DIM fails to read correctly, and some blank DOS images that DIM produces would be incorrectly formatted. This will be fixed for the next version, unless someone urgently requires it sooner.

[0xC0DE]

I am using your fantastic program every day, but I found a bug that sometimes happens and sometimes it doesn't. This is on Windows 64bit DIM version 1.40 (but it also happened in older versions).

Situation: I extract (all) files from a disk image by using the command line of DIM as follows (in a batch file):

Code: Select all

\DiscImageManager\DiscImageManager.exe ^
  "--insert:tmpdel\TMPDISK.ssd" ^
  "--extract::0.$|tmpdel"

Upon inspection of the extracted file(s) I see that all or part of the file suddenly contains &FF bytes, rendering them useless:

Edit: if I add a few bytes to the source file, then extract again, all appears to be well again. That's why sometimes it happens, and sometimes it doesn't. Could be an alignment issue that throws DIM off??

[geraldholdsworth]

Edit: if I add a few bytes to the source file, then extract again, all appears to be well again. That's why sometimes it happens, and sometimes it doesn't. Could be an alignment issue that throws DIM off??

Could be - what is the reported length of that file, plus the starting sector, you've got there, before you've added any bytes?

[0xC0DE]

Could be - what is the reported length of that file, plus the starting sector, you've got there, before you've added any bytes?

I'm sorry I didn't look and I can't reproduce it right now with different file sizes

[geraldholdsworth]

I'm sorry I didn't look and I can't reproduce it right now with different file sizes

No probs. I'll have a look through the code and see if I can see anything obvious.

EDIT: Only thing I can find that would produce 0xFF is if the application is being asked to access data beyond the end of the image. For example, if the image size is 102400 bytes and a file's offset+length takes it above 102400 bytes. So another bit of info that would be useful would be the image's size, as reported to Windows/Linux/macOS.

[0xC0DE]

So another bit of info that would be useful would be the image's size, as reported to Windows/Linux/macOS.

Thanks for looking into it. I typically operate on very small ssd files as created by BeebAsm. Usually only a few Kb. I extract files from a couple of them and use DIM to add those to the final disk image which is usually a 200Kb ssd file (DFS).
But the problem happens when extracting not when adding files.

[geraldholdsworth]

Thanks for looking into it. I typically operate on very small ssd files as created by BeebAsm. Usually only a few Kb. I extract files from a couple of them and use DIM to add those to the final disk image which is usually a 200Kb ssd file (DFS).
But the problem happens when extracting not when adding files.

If (when) it happens again, could you send me the problem SSD?
I was on the verge of compiling 1.41, but I'll hold off until I can get this issue sorted (it was only improving DOS reading/writing and adding FAT32 and LFN support, so probably not as important).

[0xC0DE]

Thanks for looking into it. I typically operate on very small ssd files as created by BeebAsm. Usually only a few Kb. I extract files from a couple of them and use DIM to add those to the final disk image which is usually a 200Kb ssd file (DFS).
But the problem happens when extracting not when adding files.

If (when) it happens again, could you send me the problem SSD?
I was on the verge of compiling 1.41, but I'll hold off until I can get this issue sorted (it was only improving DOS reading/writing and adding FAT32 and LFN support, so probably not as important).

I will but it happens very infrequently and haven't been able to trigger it intentionally so far. By all means, please don't wait for me before releasing a new version of DIM.

[geraldholdsworth]

I will but it happens very infrequently and haven't been able to trigger it intentionally so far. By all means, please don't wait for me before releasing a new version of DIM.

I've made a slight change to how files are extracted - so now it should fail it if it goes beyond the end of the image, instead of filling with 0xFF. Need to make sure it'll work as expected before I put this new version out.

[geraldholdsworth]

Version 1.41 is now available. Main new features:

• Read and Write of MS-DOS FAT12, FAT16 and FAT32, including Long Filename support.
• Loads more MS-DOS improvements (see the Changes.txt file for more details).
• When downloading files, if the file 'goes of the end of the image', it will fail the download instead of filling the remainder with 0xFF.

And bugs fixed:

• Hard drive creator would not always create an exact sized image.
• On ADFS/DOS hybrid images, the directory separator for DOS would still be '.' instead of '\'.
• DFS, C64, CFS, and Spark images were being opened without the 'directory been read' flag set.
• DFS images were still not being correctly IDed, in particular Watford DFS and some double sided.

[geraldholdsworth]

I've now added the functionality of writing back to !SparkFS files (ZIP format) in version 1.42, which is now available.

In addition, there are a few bug fixes, mostly to do with extracting from Spark files, but also a couple which affected ADFS:

• Clicking on the filetype icon to change the filetype crashed the application.
• Clicking on the timestamp field to change the time or date, then clicking into this now editable field resulted in the file in the directory listing becoming editable. Quite an odd one that.

So, you may be asking "why make SparkFS writable outside of RISC OS?" I asked myself the same question, as adding files from, say Windows, into a Spark archive is just the same as adding them to a ZIP file (which is what is actually happening). However, I then thought about those files with the accompanying *.inf files...these are taken into account and the details are stored in the extra field in the ZIP archive, just like !SparkFS does. Also, if a file has an extension that Disc Image Manager recognises, this is converted to a RISC OS compatible filetype (as is with ADFS) and time/date stamped.

[BeebMaster]

Thanks for the latest version, I've just tried the Linux 64-bit version (it says Intel 64-bit, and I am on AMD if that makes any difference to anything).

I'm having a few problems. One disc I have won't expand the directories. This is an ADFS 640K L disc, but it was formatted and used exclusively so far on my RISC PC so maybe it's a bit "unusual" as an "L" disc. I see it has the disc title you can give during the Desktop format operation interleaved in the final few bytes of sectors 0 and 1.

It doesn't seem to like a lot of my BBC Winchester disc images, it just says "Please wait...working" and does that forever. Is there a debug output I can get to see what's happening?

Could the number of files in a directory be reported somewhere in a future version?

[geraldholdsworth]

Thanks for the latest version, I've just tried the Linux 64-bit version (it says Intel 64-bit, and I am on AMD if that makes any difference to anything).

No, makes no difference. It's actually x86_64. I only report it as Intel as it was easier. I suppose I could have 'Intel compatible'.

I'm having a few problems. One disc I have won't expand the directories. This is an ADFS 640K L disc, but it was formatted and used exclusively so far on my RISC PC so maybe it's a bit "unusual" as an "L" disc. I see it has the disc title you can give during the Desktop format operation interleaved in the final few bytes of sectors 0 and 1.

There is an option I introduced in the previous but one version to not read in all the directories until you double click on them. It could also be using the wrong interleave, and not detecting the correct one (if on Auto). Have a play with the various options, see if any work forcing an interleave.

It doesn't seem to like a lot of my BBC Winchester disc images, it just says "Please wait...working" and does that forever. Is there a debug output I can get to see what's happening?

Yes, there is. In the options there is a debug tick box. This creates a temporary file. If you then go to the About dialogue window and click on the DIM icon it will then report the file location in an 'error' box and copies it to the clipboard. It doesn't put a load of info into the debug, but it might be enough.
You could always send me any problem images you have and I'll analyse them to find out what is going on. Either PM me here, or email me (my address is in the User Guide which should be alongside the binary in the ZIP file).

Could the number of files in a directory be reported somewhere in a future version?

Yes it can. I've been thinking that same thing recently too, oddly enough.

[BeebMaster]

A bit of progress...the log shows that for one of the images, it seems to be getting stuck reading the M512 DOS partition file:

Code: Select all

16:43:02 23 Apr 2022: Reading :AFS$\MDFS\LIBRARY\!help\Errors.TooMany
16:43:02 23 Apr 2022: Reading :AFS$\MDFS\LIBRARY\!help\Errors.Unusual
16:43:02 23 Apr 2022: Removing blank entries
16:43:02 23 Apr 2022: Reading DOS Plus partition
16:43:02 23 Apr 2022: Reading C:

Another image it mounts and shows the L3 Econet area as appearing in "$" but doesn't show the ADFS bit at all - but this may be because there is a corrupt free space map:

Code: Select all

0000:0000 | F5 0E 00 D1 52 00 45 54  00 D4 66 00 68 53 00 68  53 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | õ..ÑR.ET.Ôf.hS.hS...............................................
0000:0040 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ................................................................
0000:0080 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ................................................................
0000:00C0 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 C9 00  01 00 00 00 00 00 00 3E | ......................................................É........>
0000:0100 | 01 00 00 02 00 00 03 00  00 F3 99 00 5F AD 00 5F  AD 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | .........ó.._.._................................................
0000:0140 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ................................................................
0000:0180 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 | ................................................................
0000:01C0 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 4D 01  01 00 00 F4 BF 02 0C BF | ......................................................M....ô¿..¿

which gives this:

(Dunno why that picture is so dark!)

Haven't got anywhere with the ADFS L disc yet, I changed to sequential but it didn't do anything different. This is an image I've made with my own RISC OS disc imager, so I probably should check it a bit more first.

[geraldholdsworth]

A bit of progress...the log shows that for one of the images, it seems to be getting stuck reading the M512 DOS partition file:

Code: Select all

16:43:02 23 Apr 2022: Reading :AFS$\MDFS\LIBRARY\!help\Errors.TooMany
16:43:02 23 Apr 2022: Reading :AFS$\MDFS\LIBRARY\!help\Errors.Unusual
16:43:02 23 Apr 2022: Removing blank entries
16:43:02 23 Apr 2022: Reading DOS Plus partition
16:43:02 23 Apr 2022: Reading C:

It took me ages to notice, but it looks like you have an ADFS partition (which maybe just a dummy one), an Acorn FS partition and a DOS+ partition. That is something DIM doesn't know about (but I have often wondered if such a beast would exist), so I would be interested to see it "in the flesh", and then look to add that functionality.

Another image it mounts and shows the L3 Econet area as appearing in "$" but doesn't show the ADFS bit at all - but this may be because there is a corrupt free space map:

Could be - the FSM does show that it is 0 sectors long, which could be throwing it off. I can't remember how DIM handles that...I'd need to find the bit in the code to confirm what it does.

Also, the numbers don't add up...0xFF6607 * 256 = 428,4876,544 bytes. But the free space does add up (both in the map and the figures on the screen shot).

[BeebMaster]

It took me ages to notice, but it looks like you have an ADFS partition (which maybe just a dummy one), an Acorn FS partition and a DOS+ partition. That is something DIM doesn't know about (but I have often wondered if such a beast would exist), so I would be interested to see it "in the flesh", and then look to add that functionality.

I may have been thinking at cross-purposes earlier. Most of my hard discs have a L3 partition on them, but I don't have any ADFS discs which have an actual DOS partition. Some of them have the DRIVE_C file within the ADFS area created by the HDisk utility for the Master 512, however this image doesn't have that! It does have some ROM images in it, including Fastboot which has DOS-y looking bits within the ROM, how does DIM detect a DOS partition?

Another image it mounts and shows the L3 Econet area as appearing in "$" but doesn't show the ADFS bit at all - but this may be because there is a corrupt free space map:

Could be - the FSM does show that it is 0 sectors long, which could be throwing it off. I can't remember how DIM handles that...I'd need to find the bit in the code to confirm what it does.

Also, the numbers don't add up...0xFF6607 * 256 = 428,4876,544 bytes. But the free space does add up (both in the map and the figures on the screen shot).

It's only a 28MB hard disc - the free space map has been wrong for years and years, but it all still works so I haven't dared to try to correct it!

[geraldholdsworth]

how does DIM detect a DOS partition?

The steps taken to ID a disc is something like this:

1. Load the data into memory.
2. Attempt to ID the disc - ADFS is up first.
3. During the ADFS ID, it will try to determine the shape (S, M, L, D, etc.). If it determines it is an 'L', it will see if it is one of the 'special' DOS+ images.
4. Again, during the ADFS ID, and after seeing if it is a 640K DOS+, it looks to see if it has an Acorn FS partition. It will also set up some of the disc record variables here.
5. Having determined it is an ADFS, it will then read the image. First, the ADFS part is read in. Then the AFS part is read, if the flag is set. And finally the DOS part is read, if the flag is read.

In order to determine a DOS partition, it needs to be a 640K 'L' with a reported sector count of 0xAA0 (instead of 0xA00). However, if an ADFS hard drive is determined, then it will look for a DOS signature starting after the root, on the start of every sector, than adjust the disc sizes accordingly.

Now I'll need to figure out why I did it that way - it is obvious that this is how it is finding your DRIVE_C DOS file, and then crashing the application as it readjusts the ADFS partition to be just before this.

[geraldholdsworth]

Got it now - the sample I have of an ADFS HDD with a DOS partition has the ADFS sector count covering the entire disc, including the DOS partition. There is even a small ADFS area after the DOS area, marked out in the FSM. There is no other way of telling if there is a DOS partition present unless I go looking for it. I guess the DOS partition is marked out as a file which has no entry in any directory.

So, my thinking is (after a few pints of bitter on a Saturday night) to then, when reading in the ADFS directories, that if a file is found that has the same address as the DOS partition, then cancel the DOS part. However, this fails if the user has elected not to scan all ADFS directories on load. Or, we don't check for DOS if AFS has already been determined.

Job for Sunday morning, me thinks.

EDIT: Would you believe it? This sample I have has a DRIVE_C file which is the DOS partition. Is this how a Master 512 works with a DOS partition on a hard drive? Whichever, I still need to rethink this approach.

[BeebMaster]

Yes, there isn't a DOS partition as such, it's an actual ADFS file called DRIVE_C which is laid out as a DOS disc (FAT12 I think). I can probably find a blank ADFS disc with DRIVE_C on to upload.

The funny thing is though that the hard drive image which crashes doesn't have a DRIVE_C file at all - but something is being recognised as DOS, possibly one of the ROM images on there, maybe Essential Software's Fastboot.

[geraldholdsworth]

The funny thing is though that the hard drive image which crashes doesn't have a DRIVE_C file at all - but something is being recognised as DOS, possibly one of the ROM images on there, maybe Essential Software's Fastboot.

It is quite possibly a file with a DOS header and FAT. I'll take another look into the IDing of a DOS partition, as I haven't changed it much since I found the Microsoft White Paper detailing the FAT specifications online.

[geraldholdsworth]

I've added a few more sanity checks for DOS images. It is quite possible it was getting fooled by version 1.21 of the CPFS ROM.

I also found that a bug crept in where blank DOS images were being IDed as double sided DFS images...odd!!

While I was there, I've added in the reporting of the number of items in a directory.

I'll compile and upload an interim release later on (version 1.42.1).

EDIT: That's 1.42.1 compiled and uploaded to the binaries folder on GitHub.

[geraldholdsworth]

Just uploaded version 1.43.

Changes in this version are mostly to do with AmigaDOS. This format is now writable as well as readable (and I've made some improvements with the reading side too). Still got some way to go, as there are a few different variations of this format.

Other additions/improvements:

• As requested above - reports the number of items in a directory.
• More sanity checks on DOS images.
• Found that some images were getting mistaken for DFS, so this is now IDed last.
• CRC32 is no longer reported for directories - not sure how useful that was anyway.
• DOS partitions on ADFS - when this is a file (see above), the file within the ADFS partition is now in green and cannot be deleted. I've also added a configuration to specify if you want DOS files opened as partitions or not - only with ADFS Old Directory hard drives though.
• Added some more command line options and parameters. Can now create DOS or Amiga hard drive images, DOS floppy images, and set configuration options.

On the list of bug fixes are:

• I guess the DOS sanity checks comes under this area too.
• The custom filetype entry box was not positioned correctly, when changing filetypes.
• ADFS filetypes and timestamps were getting reported for non-ADFS and ADFS old directory images.
• I found a problem when moving/copying files, using drag and drop, that the directory tree would go crazy. This was down to the directory being passed over was expanded instantly. There is now a 1 second delay.
• If a file was deleted, but the user clicked on 'No' on the confirmation box, the confirmation box would not go away. This also happened if a delete failed.
• And, finally, the Compress UEF Files configuration option was not saved to the registry.

As always, let me know of any problems.

[ncc-1701]

I'm happy to report that Disk Image Manager saved my bacon the other day, when I had a 'corrupted' BBC disc image. It turned out that a recent change I had made to my assembly source file had led the assembler to decide that my binary started at address 0x0000. When the binary was loaded, ADFS began marching through page 0, resetting all the bytes, until it got to the bytes it was using itself, at which point it looped infinitely.