Disc Image Manager

[geraldholdsworth]

Fired up my Windoze PC, installed the IDE on it and copied the source code over...and I can replicate the fault.

Bad news...I am now even more confused - if you create an Amiga or DOS Hard Drive, the buttons work (this is the same form and the same buttons).

Also, the disabled controls flash...I think that may be a red-herring!

[geraldholdsworth]

Still confused...but fixed it. I'll get an updated version compiled and put up on GitHub over the next few days.

[Ukwebb]

amazing
In a very similar situation, I logged a call last week with one of our software suppliers, giving them all the guidance as to the fault, which helped them identify the cause of the fault very quickly (in 3 working days). They too are going to release a new build containing the fix .... in January !

[geraldholdsworth]

Took a bit longer than anticipated to get it compiled and uploaded, due to work commitments. But, it is here now. Version 1.46.5.

[marrold]

Yup all working here, thanks for sorting it so quickly

[james]

DIM 1.46.5 macOS (Intel 64 bit)

Opened an 80 track DFS ssd image, dragged a file called RWCmos.txt to the image, gets added as "RWCmos/". All good, readable in MAME.

Open the image in DIM, highlight "RWCmos/", right click and "Delete File". Confirm. File will not be deleted. Under image report:

Code: Select all

File report
===========
:0.$.RWCmos/ could not be read
1 error(s) found

If I "*REN. RWCmos/ RWCmos" in MAME, the resulting RWCmos file can be deleted through DIM.

[geraldholdsworth]

Open the image in DIM, highlight "RWCmos/", right click and "Delete File". Confirm. File will not be deleted. Under image report:

Code: Select all

File report
===========
:0.$.RWCmos/ could not be read
1 error(s) found

If I "*REN. RWCmos/ RWCmos" in MAME, the resulting RWCmos file can be deleted through DIM.

Interesting...thank you - I'll look into that one.

[geraldholdsworth]

Found the cause - it was a line I added to detect, and remove, the characters '/' and '\' at the end of a filename. Currenly not sure why, but I suspect it had something to do with the DOS format. Once I'm less busy with work, I'll investigate further.

EDIT: I've just compiled and uploaded version 1.46.6 which includes this change, plus another bug I found only on macOS (an odd one which I think stems from the compiler rather than my code).

[marrold]

Hi,

BeebEm, B-Em, BeebSCSI etc all expect a DSC file to accompany the .dat file that describes the drive geometry. https://acorn.huininga.nl/pub/software/ ... disks.html

Does Disk Image Manager support creating these?

Thanks
Matthew

[geraldholdsworth]

Does Disk Image Manager support creating these?

Currently, no. But I do have plans to do this.

Oddly enough, I've never found BeebEm needed the file for it to see a hard drive.

[marrold]

Oddly enough, I've never found BeebEm needed the file for it to see a hard drive.

I get the impression its required to get SuperForm to behave?

[BeebMaster]

I think (and dp111) can probably confirm much better than I can, that the DSC file is created if it doesn't exist, or is updated, after a mode select command. It would then be read to get the information required on a mode sense command. It essentially contains the geometry parameters that mode select and mode sense commands use, which would normally be stored in a spare track on a SCSI/ST506 disc, or sometimes (e.g. Xebec, which doesn't have a facility for storing this information on the disc itself) temporarily in the controller's memory.

BeebSCSI/Pi1MHz SCSI should work well enough with disc images which don't have the DSC file. I think it tries to create one if one doesn't exist.

Superform will give an error if it can't read the disc geometry, which would be the stored parameters in the case of a real disc, and I think should be the DSC file in the case of a disc image, but Superform can still then continue as it should issue a mode select command when the drive parameters are input.

[marrold]

Thanks thats really helpful

[james]

Hi. There may be a problem in titling DFS disc images.

I recently downloaded some disc images from bbcmicro.co.uk, edited the titles with DIM, and put them on MMFS where "*DBOOT [title]" pretty much always fails but "*DBOOT [title]*" works. Selecting the imagine by number and running "*TITLE [title]" then allows *DBOOT to work.

So I created a DFS image in DIM and gave it the title "ABCD", duplicated the image file, opened it in MAME and did a "*TITLE ABCD". Here's what's in the first 8 bytes of each (the first from DIM, the second as updated by DFS):

Code: Select all

> head -c 8 dim.ssd | od -x
0000000      4241    4443    2020    2020                                

> head -c 8 dfs.ssd | od -x
0000000      4241    4443    0000    0000                                

It may be that those trailing spaces in the title should be nulls.

[geraldholdsworth]

When I was researching this, some of the sources I found say it should be padded with spaces while others say nulls. MDFS certainly says nulls.

I'll change it to nulls as that does appear to be more compatible with most things, and I trust JGH's knowledge. I need to do a compile and upload of a new version anyway.

[Ukwebb]

It does indeed look to be including spaces on the end of the file name.
Loading a DIM named disk into DFS shows the extra spaces between end of the disk title and the sequence number on the end , and it should indeed be padded out with 0x00

So your mmfs command would technically need to include those trailing spaces to work, which isn't ideal.

Just noticed too that renaming in DIM doesn't update the sequence number , no biggy, but just something I noticed

I'm sure its an easy fix for Gerald.

[geraldholdsworth]

I've, finally, compiled and uploaded 1.46.7. This includes some code by regregex, and the additions mentioned above, except for the sequence number issue - that's to come. I have looked at this before, and thought that I had added it...obviously not . As ukwebb said, not a biggy. I'll add that next and make it the next major release (1.47), before I dive in and rewrite it to take account of partitions.

EDIT: Forgot to mention that the 32bit macOS version is no more. The latest version of Lazarus doesn't appear to like compiling to it - I think the developers have given up on that platform now. If anyone desperately wants the 32bit macOS version, just let me know and I'll get it compiled using the previous version of Lazarus.

EDIT2: And then, just like that, someone has fixed Lazarus so it compiles 32 bit mac OS projects...so, this is now available too.

[james]

Thanks for version 1.46.7. After re-titling the disc images to change the trailing x20 -> x00 in titles, *DBOOT now works as expected.

I did notice something else, which may be an artifact of the some disc images rather than DIM. But, for example, if you look at Acornsoft Meteors http://bbcmicro.co.uk/game.php?id=8 then a phantom folder appears:

It also appears in this Killer Gorilla disc image

Edit: there's nothing immediately obviously wrong when CATting the image in MAME:

[geraldholdsworth]

I did notice something else, which may be an artifact of the some disc images rather than DIM. But, for example, if you look at Acornsoft Meteors http://bbcmicro.co.uk/game.php?id=8 then a phantom folder appears:

Now that is quite odd. I can't find a reason why DIM would be doing this. It doesn't do it to all DFS discs, and the headers are correct (as far as I can see).

Meditate on this, I will.

EDIT: Found it - there was a bug detecting double sided images. I had set the double sided flag at the start of the ID process as an assumption, then re-set it later on after further checks. However, I was using a local variable in the ID function instead of the global variable and this got set too early. The phantom directory was the second side never getting populated or named.

[james]

When I was researching this, some of the sources I found say it should be padded with spaces while others say nulls. MDFS certainly says nulls.

This thead https://www.stardot.org.uk/forums/viewt ... 22#p409422 seems to suggest that earlier (8271) DFSes erroneously used spaces instead of NULs

I just tried DFS 1.20. It's quite happy to CAT an existing disc with trailing NULs, but "TITLE does then change them to spaces.

[egrath]

Tried the latest released version 1.46.7 and the ARM native version does not work on my Macintosh Mini M1. However, the x86-64 version works thanks to the OS integrated emulation.

Greenshot 2024-03-23 09.16.10.png (49.43 KiB) Viewed 3364 times

Also a few tried older versions, all suffer from the same issue.

[geraldholdsworth]

This is most annoying - mainly because I develop DIM on an M2 Mac, but also because I thought I'd sorted this issue. However, it appears to be an Apple issue, as I've seen other applications suffer the same thing. What to do is to extract the application from the DMG then, in Terminal:

Code: Select all

cd <path to application>
xattr -cr "Disc Image Manager.app"