Disc Image Manager

discuss pc<>acorn file transfer issues and the use of other utils
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

DutchAcorn wrote:
Fri Mar 19, 2021 5:22 am
It would be cool to be able to add zip files where Disc Image Manager offers the option of unpacking the zip to the destination directory.
I have looked at unzipping, and zipping, files but hadn't thought of doing it like this...I'll add it to the list. Thank you.
User avatar
0xC0DE
Posts: 943
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: Disc Image Manager

Post by 0xC0DE »

I feel pretty dumb because I can't figure out how to extract files from a disc image from the command line.

I try the following in a batch file (Windows):

cd auto-gen\tmpdel
\DiscImageManager\DiscImageManager.exe --insert:TMPDISK.ssd --extract:$.*
cd ..\..

And I've tried many other combinations. Can't find any specific help in the documentation.
Are wildcards allowed? How do I specify multiple files? How do I determine where my files go on the host system?

Thanks for looking into this ;)
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my games and demos for Acorn Electron and BBC Micro
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

0xC0DE wrote:
Sat Mar 20, 2021 11:14 pm
cd auto-gen\tmpdel
\DiscImageManager\DiscImageManager.exe --insert:TMPDISK.ssd --extract:$.*
cd ..\..
Try --extract:$
This will extract the entire contents of the root to the currently selected host directory.
It looks like I added a second parameter to this (and never documented it), so --extract:$|"C:/Downloads" should extract everything from the root to the C:/Downloads folder (quotes might be optional - this bit is handled by the OS).
But I do think it needs wildcards on the image side - I'll add it to the list.
User avatar
0xC0DE
Posts: 943
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: Disc Image Manager

Post by 0xC0DE »

geraldholdsworth wrote:
Sun Mar 21, 2021 8:52 am
0xC0DE wrote:
Sat Mar 20, 2021 11:14 pm
cd auto-gen\tmpdel
\DiscImageManager\DiscImageManager.exe --insert:TMPDISK.ssd --extract:$.*
cd ..\..
Try --extract:$
This will extract the entire contents of the root to the currently selected host directory.
It looks like I added a second parameter to this (and never documented it), so --extract:$|"C:/Downloads" should extract everything from the root to the C:/Downloads folder (quotes might be optional - this bit is handled by the OS).
But I do think it needs wildcards on the image side - I'll add it to the list.
Sorry mate, tried $, with an without host destination path. Nothing gets extracted. I can see the disc image is opened properly (by adding --keepopen)
It's a DFS image btw. Will try ADFS as well. Edit: no luck with ADFS and CFS either
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my games and demos for Acorn Electron and BBC Micro
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

0xC0DE wrote:
Sun Mar 21, 2021 9:04 am
Sorry mate, tried $, with an without host destination path. Nothing gets extracted. I can see the disc image is opened properly (by adding --keepopen)
It's a DFS image btw. Will try ADFS as well. Edit: no luck with ADFS and CFS either
OK, leave it with me. I'll see what is going on.

EDIT: Sorry, try :0.$ for DFS. The following string worked for me on macOS:
--insert:"/Users/geraldholdsworth/Downloads/RI Test.ssd" --extract:":0.$|/Users/geraldholdsworth/Downloads/Test" -k

What you should see is, if you use the keep open option, a load of files left selected. This indicates that it has successfully found the file(s) you want extracted.

I'll have a look at ADFS now.
EDIT2: ADFS works for me. I did notice my placing of the quotes in the above string, so wanted to make sure it didn't make a difference, which it doesn't:
--insert:"/Users/geraldholdsworth/Downloads/MasterWelcome.adl" --extract:$|"/Users/geraldholdsworth/Downloads/Test" -k
User avatar
0xC0DE
Posts: 943
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: Disc Image Manager

Post by 0xC0DE »

Got it working now (DFS, is all I need) thanks!!
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my games and demos for Acorn Electron and BBC Micro
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

DutchAcorn wrote:
Fri Mar 19, 2021 5:22 am
RiscOS software is often available online as a zip file containing the required files and directories. Trouble is that these files need to be unpacked in RiscOS with a RiscOS archiver to avoid loss of the file type information. It would be cool to be able to add zip files where Disc Image Manager offers the option of unpacking the zip to the destination directory.
Ask and ye shall receive...

...written this into the latest version, now uploaded.

Only does Zip archives at the moment though.
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

Must be the day of updates for me...

I've put up the latest version (1.05.18) as I'm going to work on increasing the resolution of the graphics, having now got my Sprite Converter outputting transparent PNGs and having found some 68x68px RISC OS sprites for the filetypes.

One of the changes in this version is that I've increased the font size in the main directory tree. I have also been asked about increasing the size of the buttons too, plus the file details panel's font does look small on 2K and 4K screens (not that I have one...although I'm hoping with all the AV kit I've got I might be able to fool my computer into outputting 4K resolution then scaling it back down for my FHD screen).

Another change, which was asked for, was extracting files from an image, via the command line, using wildcards. So, it is done. I've linked this to the search facility on the GUI, so this can also do wildcard searching. I've gone for the ADFS option of '*' for zero or many characters and '#' for a single character. It also keeps the ability of just specifying the directory (so '$' will select everything in the root).

There is a few other minor changes, and bug fixes.
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

Hmmm...noticed that, while I was away working on Sprite Converter, a bug had crawled in and made a nest in the ADFS section of the code. For some reason, most ADFS images will go into an endless loop when reading them.

EDIT: Found it - I've fallen foul of this before...Lazarus doesn't always take all changes into consideration when compiling. So, you could make a change, test it out and find it works OK. Only when you do a full release compile does it then look at the change and you find it no longer works!

Problem is, I've started on another change which I can't reverse to deliver a fixed version. So I need to get this new bit working before putting a fixed version up. Hopefully by tonight I'll get a fixed version up.

EDIT 2: Bug fixed version now uploaded.
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

I've uploaded version 1.05.19 - the main changes with this version is making it more 'High-DPI'. In order to do this, I've changed some of the labels around, completely removed the search panel (I've moved it to a separate window), and used higher res graphics. I've also 'texturised' it, RISC OS style...although I'm not too sure about it - looks OK on macOS, but not so on Windows.

I've got a plan to see what it looks like on 4K and 8K screens, despite not owning one - I have found I have a programmable EDID Manager...although issues might occur when I try to downscale a 4K or 8K to FHD. But, that's why I'm an AV Engineer for a living!
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

Just tried the latest version of Disc Image Manager (DIM) on macOS. I noticed something odd:

I used DIM to open a .SSD containing a BASIC program file that had a load-address of FF1900 and an exec-address of FF8023.

I then exported that file to my Mac desktop (using the "Extract File ..." menu option).

Then I closed the .SSD in DIM and imported the BASIC program file from my desktop onto a new blank ADFS disc-image in DIM (using "Add File(s) ...").

And I found that the load- and exec-addresses were given as "00031900" and "00038023", which are obviously wrong! (They should be "FFFF1900" and "FFFF8023" respectively.)

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

Re: Disc Image Manager

Post by geraldholdsworth »

lurkio wrote:
Tue Apr 06, 2021 1:24 pm
And I found that the load- and exec-addresses were given as "00031900" and "00038023", which are obviously wrong! (They should be "FFFF1900" and "FFFF8023" respectively.)
That looks to me like they're getting decoded as 32 bit ADFS timestamp and filetypes. What 'shape' ADFS did you import them to?

Cheers,

Gerald.
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

geraldholdsworth wrote:
Tue Apr 06, 2021 1:47 pm
lurkio wrote:
Tue Apr 06, 2021 1:24 pm
And I found that the load- and exec-addresses were given as "00031900" and "00038023", which are obviously wrong! (They should be "FFFF1900" and "FFFF8023" respectively.)
That looks to me like they're getting decoded as 32 bit ADFS timestamp and filetypes. What 'shape' ADFS did you import them to?
"S (160K)".

I think the point is that the addresses in the .inf file should be written as "FF1900" and "FF8023" to preserve the FF's at the beginning, especially at the beginning of the load-address, because they indicate that the files should be loaded into the I/O (host) processor rather than any parasite (co-processor).

That's what happens if you do the whole transfer from DFS to ADFS manually in BeebEm using the *XFER command in the ADT ROM: the load- and exec-addresses are correctly written as FFFF1900 and FFFF8023 on the ADFS disc.

Also, if I use the app DFSImager (under WINE on macOS) to export the BASIC program file from the .SSD to my Mac desktop, the .inf file written by DFSImager contains the correct values (or at least the 24-bit versions thereof). Here are the full contents of the .inf file written by DFSImager:

Code: Select all

$.TERP FF1900 FF8023 CRC= C52
:idea:
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

Ahh...found it - it's much simpler, and nothing to do with ADFS. For some odd reason the load and execution addresses are not being decoded correctly when the SSD file is first loaded. So the exported file will have the '0003xxxx' instead of '00FFxxxx'.

I wonder what I changed to cause this....

EDIT:
Ahhh...rewind a bit to those images you posted up that wouldn't read. I found I was multiplying bits 16 and 17 by 0x55 and couldn't work out why...just worked out why! (3*0x55=0xFF) This was needed for the load and execution addresses, but not the length and the sector address.
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

Fixed it, and uploaded the fixed version. I've also put in the code to expand a DFS address of 00FFxxxx to FFFFxxxx when importing to ADFS. And, I found a bug when creating new images having one already open.
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

geraldholdsworth wrote:
Tue Apr 06, 2021 3:20 pm
Fixed it, and uploaded the fixed version. I've also put in the code to expand a DFS address of 00FFxxxx to FFFFxxxx when importing to ADFS. And, I found a bug when creating new images having one already open.
Do you not think that "00FFxxxx" is misleading? If a DFS file has a load-address of "FFxxxx" then shouldn't the correct 32-bit expansion of that address be "FFFFxxxx"? (Or just stick to "FFxxxx", as DFSImager does.)

I know it may not make any practical difference to your app, but I couldn't swear that it'll make no difference to the interoperation of your app with, say, DFSImager, or with MMBExplorer by robcfg of this parish.

If someone used DIM to export a DFS file with a load-address of "FFxxxx", and if DIM wrote "00FFxxxx" into the .inf file, then isn't there a risk that that might get carried over literally as "00FFxxxx" if the user then used another app or some other means of importing that file to an ADFS disc or disc-image?

I'd be happier if the load-address in the .inf file was either "FFxxxx" or "FFFFxxxx" — but not "00FFxxxx" because that seems to be neither fish nor fowl!

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

Re: Disc Image Manager

Post by geraldholdsworth »

lurkio wrote:
Tue Apr 06, 2021 3:41 pm
I'd be happier if the load-address in the .inf file was either "FFxxxx" or "FFFFxxxx" — but not "00FFxxxx" because that seems to be neither fish nor fowl!
I'm happy to change it. When we 'thrashed' out the inf spec here there was no mention of length of hex addresses. So, just to make sure - for DFS 6 hex digits and ADFS 8 hex digits, or just remove any leading zero's (I think it'll look nicer using the former)?

EDIT: Further up the thread, where I referenced JGH's original document, it stated 8 hex digits for load and exec addresses, but also gave examples of those with less and stated that applications should still be able to parse them properly. However, it does suggest using FFFFxxxx for DFS, if I've read it correctly.
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

geraldholdsworth wrote:
Tue Apr 06, 2021 3:57 pm
I'm happy to change it. When we 'thrashed' out the inf spec here there was no mention of length of hex addresses. So, just to make sure - for DFS 6 hex digits and ADFS 8 hex digits, or just remove any leading zero's (I think it'll look nicer using the former)?

EDIT: Further up the thread, where I referenced JGH's original document, it stated 8 hex digits for load and exec addresses, but also gave examples of those with less and stated that applications should still be able to parse them properly. However, it does suggest using FFFFxxxx for DFS, if I've read it correctly.
I agree that eight-digit addresses in all cases would be ideal, but I think six digits for DFS files would be better in practice, if only because DFSImager doesn't seem to like it when you try to import a file that has an eight-digit load-address in the .inf: DFSImager somehow drops the leading "FFFF" altogether and writes the load-address to the .SSD as "00xxxx"!

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

Re: Disc Image Manager

Post by geraldholdsworth »

'tis done. Will be there on the next update (unless you want it sooner, and I'll do another compile and upload).
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

When extracting a file from a .SSD, the version of DIM I'm currently using fails to include the directory-name in the .inf file when the directory-name is "$". That behaviour breaks compatibility with DFSImager, which doesn't know what directory the file belongs to if the directory-name is missing from the .inf file. Other apps may also fail to deduce that the directory should be "$" in this case -- and I don't think they should really have to deduce it. I don't think there's a good reason to treat the "$" directory differently from any other directory. When a file is being extracted from a .SSD, the directory-name should always be included in the .inf file, I think..?

Another issue I just came across was that when I created a new ADFS image and started adding files to it from my desktop, the files didn't show up in the DIM "Image Contents" window until I closed the image and opened it again!

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

Re: Disc Image Manager

Post by geraldholdsworth »

lurkio wrote:
Tue Apr 06, 2021 8:12 pm
When extracting a file from a .SSD, the version of DIM I'm currently using fails to include the directory-name in the .inf file when the directory-name is "$".
IIRC, that was a conscious decision not to include root. I think I toyed with that for a while. Should be easily rectified.
lurkio wrote:
Tue Apr 06, 2021 8:12 pm
Another issue I just came across was that when I created a new ADFS image and started adding files to it from my desktop, the files didn't show up in the DIM "Image Contents" window until I closed the image and opened it again!
I found that bug earlier on today too. It threw me at first, and then I realised what was happening. They do actually appear - what doesn't appear is the little arrow to the left of $ telling you you can expand it. If you double click on the $ it should then open it up as normal. This is due to me having to redraw the tree myself so I can get the highlighter colours I want (I was getting grey on a little darker grey...very difficult to see).
User avatar
geraldholdsworth
Posts: 843
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: Disc Image Manager

Post by geraldholdsworth »

I've managed to resolved the little issue with the arrows on the Directory tree (I hope). It's a bit of a bodge, but it appears to work on both macOS and Windows. Anyway, I've uploaded the latest version to GitHub. Main changes, not covered above, are:
  • I've decided to change the version numbering. We have moved from 1.05.19 to 1.20.
  • When you export a CSV of the image's contents, the hex addresses follow the same convention as the inf file - i.e. 6 digits for DFS, 8 for everything else.
  • When you double click on a file, within the directory tree, if it is detected as a BBC BASIC file, or is known as a text or obey file, then not only will you get the hex dump but also, in a separate tab, the BBC BASIC detokenised listing, or the text file as, well, text. I'm looking to expand this to displaying bitmaps, PNGs, JPEGs and, of course, Sprites (see my other project - Sprite Converter)
  • Because of the above, 'Hex Dump' has changed to 'File Viewer'.
I've started working on trying to get Big Directories working properly - however, this means a major restructuring of a lot of code. I started, but then reverted back when my brain turned to mush. I've reverted back, so beware when loading any ADFS image...it may not work (or may be slow).

The BBC BASIC detokeniser was written as a separate application, then included into Disc Image Manager. If you want it as a stand alone application, it is here. Due to the number of application already doing this, I doubt I'll be developing it any further as a standalone.
User avatar
robcfg
Posts: 123
Joined: Sun Dec 30, 2018 6:23 pm
Contact:

Re: Disc Image Manager

Post by robcfg »

lurkio wrote:
Tue Apr 06, 2021 1:24 pm
Just tried the latest version of Disc Image Manager (DIM) on macOS. I noticed something odd:

I used DIM to open a .SSD containing a BASIC program file that had a load-address of FF1900 and an exec-address of FF8023.

I then exported that file to my Mac desktop (using the "Extract File ..." menu option).

Then I closed the .SSD in DIM and imported the BASIC program file from my desktop onto a new blank ADFS disc-image in DIM (using "Add File(s) ...").

And I found that the load- and exec-addresses were given as "00031900" and "00038023", which are obviously wrong! (They should be "FFFF1900" and "FFFF8023" respectively.)

:!:
I'd like to follow up on this.

From the OS perspective ( see http://beebwiki.mdfs.net/Acorn_DFS_disc ... System_DFS ), the addresses are in the 0xFFFFxxxx format, because the OSFILE function do an OR with 0xFFFF0000 and the actual address.

Now, if that is the case, you wouldn't be able to save a file intended to be loaded in a secondary CPU address space, as the OR operation would set any unset bit in the higher part of the address.

Also, the address saved in the DFS file descriptors is 18-bit wide, meaning that the top 6 bits don't have any defined value, so the addresses are indeed in the "0x31900" format. Anything else is padding to 24 or 32 bit addresses which is not stored in the file descriptors.

So, if everyone would prefer to have the addresses shown as 0xFFFFxxxx or 0xFFxxxx, it's fine by me, but I'd like to see a SSD image, with some files with load or exec addresses for secondary CPUs to confirm that they would be shown as 0xFFFDxxxx or 0xFExxxx, before changing the way MMBExplorer shows them.
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

robcfg wrote:
Sun Apr 11, 2021 7:06 pm
From the OS perspective ( see http://beebwiki.mdfs.net/Acorn_DFS_disc ... System_DFS )
I think that that link (which takes you to the subheading "Acorn System DFS") does NOT give you info about any DFS found in any BBC Micro computer. I believe, rather, that it gives you info about the DFS found in Acorn System computers.

So I'm not sure it's relevant to the discussion in this thread..? But I'm no expert, so please correct me if I'm wrong.

:?:

EDIT:
robcfg wrote:
Sun Apr 11, 2021 7:06 pm
So, if everyone would prefer to have the addresses shown as 0xFFFFxxxx or 0xFFxxxx, it's fine by me
I think 0xFFxxxx would be best. That's what DFSImager and Disc Image Manager do now.

robcfg wrote:
Sun Apr 11, 2021 7:06 pm
but I'd like to see a SSD image, with some files with load or exec addresses for secondary CPUs to confirm that they would be shown as 0xFFFDxxxx or 0xFExxxx, before changing the way MMBExplorer shows them.
I'm probably misunderstanding you, but I thought that files that were meant to be loaded into the host (I/O) processor should have load-addresses of the form 0xFFFFxxxx (or 0xFFxxxx on DFS), and files meant to be loaded into the parasite (co-processor or Second Processor) should have load-addresses of the form 0x0000xxxx (or 0x00xxxx on DFS)? So I'm not sure where your examples "0xFFFDxxxx" and "0xFExxxx" come in..?

:?:
User avatar
robcfg
Posts: 123
Joined: Sun Dec 30, 2018 6:23 pm
Contact:

Re: Disc Image Manager

Post by robcfg »

I'm probably misunderstanding you, but I thought that files that were meant to be loaded into the host (I/O) processor should have load-addresses of the form 0xFFFFxxxx (or 0xFFxxxx on DFS), and files meant to be loaded into the parasite (co-processor or Second Processor) should have load-addresses of the form 0x0000xxxx (or 0x00xxxx on DFS)? So I'm not sure where your examples "0xFFFDxxxx" and "0xFExxxx" come in..?
It's actually quite easy.

A file intended to be loaded on the host processor has bits 16 and 17 set (thus the 0x3xxx format), but for files intended to be loaded elsewhere, the bit values can be 01, 10 or 00. If you pad the remaining 6 bits with 1 (as the OS seems to do), then you get addresses in the form 0xFExxxx, 0xFDxxxx or 0xFCxxxx.

In case the two bits need to have the same value, the it's either 0xFFxxxx or 0x00xxxx. I think this is important, that's the representation chosen by the OS, and it may save the destination processor (either host or external) somewhere else but, if we do the same with the file descriptors, you risk losing that information, especially if you or the address with 0xFFFF0000, because then you don't know which processor it was destined to.

I think the correct thing to do, as Disc Image Manager and MMBExplorer are programs that are outside the machine and not tied to the OS, is to show the data as it is stored in the disc to avoid corruption.
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

robcfg wrote:
Sun Apr 11, 2021 7:47 pm
A file intended to be loaded on the host processor has bits 16 and 17 set (thus the 0x3xxx format), but for files intended to be loaded elsewhere, the bit values can be 01, 10 or 00.
Can they, though? I've never come across a file where bits 16 and 17 were 01 or 10. They've only ever been 11 or 00 in every file I've ever seen. Are 01 and 10 actually legal values? What do they mean?

robcfg wrote:
Sun Apr 11, 2021 7:47 pm
I think the correct thing to do, as Disc Image Manager and MMBExplorer are programs that are outside the machine and not tied to the OS, is to show the data as it is stored in the disc to avoid corruption.
Currently, when you export a file with a load-address of 0xFFxxxx (e.g. FF1900) from a .SSD, using DiscImager or Disc Image Manager, the .inf file will record the load-address as FFxxxx (e.g. FF1900). How are you proposing to record the load-address in the .inf when the same file is exported from the .SSD using MMBExplorer?

:?:
User avatar
robcfg
Posts: 123
Joined: Sun Dec 30, 2018 6:23 pm
Contact:

Re: Disc Image Manager

Post by robcfg »

lurkio wrote:
Sun Apr 11, 2021 7:56 pm
robcfg wrote:
Sun Apr 11, 2021 7:47 pm
A file intended to be loaded on the host processor has bits 16 and 17 set (thus the 0x3xxx format), but for files intended to be loaded elsewhere, the bit values can be 01, 10 or 00.
Can they, though? I've never come across a file where bits 16 and 17 were 01 or 10. They've only ever been 11 or 00 in every file I've ever seen. Are 01 and 10 actually legal values? What do they mean?
I don't know what are legal values or not, that's why I'm asking.
lurkio wrote:
Sun Apr 11, 2021 7:56 pm
robcfg wrote:
Sun Apr 11, 2021 7:47 pm
I think the correct thing to do, as Disc Image Manager and MMBExplorer are programs that are outside the machine and not tied to the OS, is to show the data as it is stored in the disc to avoid corruption.
Currently, when you export a file with a load-address of 0xFFxxxx (e.g. FF1900) from a .SSD, using DiscImager or Disc Image Manager, the .inf file will record the load-address as FFxxxx (e.g. FF1900). How are you proposing to record the load-address in the .inf when the same file is exported from the .SSD using MMBExplorer?

:?:
It shouldn't actually matter how you save it on the inf file, as when saving the data to the SSD image, program should only care about the value of those bits, so all formats are equally valid. But I feel that as only 18 bits are saved to disk, the 0x3xxxx format is the right one, whatever values are in the upper 6 bits are not on the file descriptors.

The simplest way would be to AND the addresses stored on the inf file with 0x3FFFF to make sure the right address is read correctly from the inf file, and show it and store it on the inf file in whatever way suits you best.
User avatar
lurkio
Posts: 3397
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Disc Image Manager

Post by lurkio »

robcfg wrote:
Sun Apr 11, 2021 8:12 pm
lurkio wrote:
Sun Apr 11, 2021 7:56 pm
I've never come across a file where bits 16 and 17 were 01 or 10. They've only ever been 11 or 00 in every file I've ever seen. Are 01 and 10 actually legal values? What do they mean?
I don't know what are legal values or not, that's why I'm asking.
I suspect that 01 and 10 aren't legal values. I'll try and find a reference in some documentation, but it would be helpful if someone who knows the answer for sure could weigh in here..!

[-o<

But if 01 and 10 are illegal values, then the only legal values are 00 and 11, and it can be assumed that the presence of 11 in the top bits of the load-address of a DFS file implies that the load-address can be expanded to the form FFxxxx when it is written to the .inf, right..?


robcfg wrote:
Sun Apr 11, 2021 8:12 pm
lurkio wrote:
Sun Apr 11, 2021 7:56 pm
Currently, when you export a file with a load-address of 0xFFxxxx (e.g. FF1900) from a .SSD, using DiscImager or Disc Image Manager, the .inf file will record the load-address as FFxxxx (e.g. FF1900). How are you proposing to record the load-address in the .inf when the same file is exported from the .SSD using MMBExplorer?
It shouldn't actually matter how you save it on the inf file, as when saving the data to the SSD image, program should only care about the value of those bits, so all formats are equally valid. But I feel that as only 18 bits are saved to disk, the 0x3xxxx format is the right one, whatever values are in the upper 6 bits are not on the file descriptors.

The simplest way would be to AND the addresses stored on the inf file with 0x3FFFF to make sure the right address is read correctly from the inf file, and show it and store it on the inf file in whatever way suits you best.
The problem comes if I export a file with a load-address of FFxxxx from a .SSD using MMBExplorer, and MMBExplorer writes the load-address as 3xxxx: if I then import that file to an ADFS disc (using DIM or some other utility app) then that load-address will be recorded as 0003xxxx on the ADFS disc, instead of FFFFxxxx, which is what it should really be. (ADFS files have 32-bit load- and exec-addresses.) I realise that 0003xxxx is kind of a meaningless load-address but I think it is legal to have a file with that load-address on an ADFS disc!

:!:

(EDIT: Note that when you do a *INFO, DFS itself will display the load-address as FFxxxx (e.g. "FF1900") even though, technically, it's recorded on disc as 3xxxx.)
Post Reply

Return to “software & utilities for the pc, mac or unix”