New Disk Image Editor

[yellowpig]

I mentioned in a recent thread that I have been working on a (Windows) program to handle BBC disk images. It is now at a stage where others might like to try it out.

I have called the program "Beeb Image" and have put it on my website at: http://www.cowsarenotpurple.co.uk/beeb-image.html.

The program will handle images of DFS, ADFS and DOS floppy disks. DOS formats include the Master 512's 640k and 800k formats. It can also handle BBC (ADFS) hard disks, including those with a Master 512 DOS "partition".

Using it files can be moved or copied between disk images (of different or the same type) and between an image and the Windows host. File and disk details such as file-names, boot options, etc can be edited. Directories on images of ADFS or DOS disks can be treated the same way.

There are some limitations, of course. For one thing it is currently Windows-only. Also, I haven't been able to work out how to implement drag-and-drop in a way that will preserve BBC files' load and execution addresses.

Have fun with this, and let me know if you come across any bugs or other problems.

David

[jgharston]

There are some limitations, of course. For one thing it is currently Windows-only. Also, I haven't been able to work out how to implement drag-and-drop in a way that will preserve BBC files' load and execution addresses.

When you receive a drag'n'drop file, append ".inf" to the filename and if it exists use its contents as the BBC metadata. The format is:
(one_or_more_non_space_characters)(one_or_more_spaces)(hex_address)(one_or_more_spaces)(hex_address)(any_supplimentary_info)
for instance:
SCREEN 3000 0
MDUMP/S 800 0000B82C
PRLIST FFFF0900 FFFF091A 33 7764 123435 6C67 33569A
(You can't see, but those have multiple spaces in them - you should swallow any number of extranous spaces).
On reading you should ignore the first parameter, and use the second and third parameters as the load and exec address. If the fourth parameter exists it is the access attributes, and can also be L which is an alias for 08. If there is no source access attribute, set the destination access to &33 = WR/wr (or &00 on DFS).

When you send a drag'n'drop, and you should have a user-settable "create .inf files" option, if that option is set, append ".inf" to the output filename and write:
(filename)(spaces_padded_to_12)(8_digit_hex_address)(exactly_one_space)(8_digit_hex_address)(optionally: (exactly_one_space)(2_digit_hex_address) or 'L')(end_of_line)
for instance:
SCREEN 00003000 00000000
MDUMP/S 00000800 0000B82C L
PRLIST FFFF0900 FFFF091A 33
(You can't see, but those have exactly once space between the address parameters, and exactly enough spaces after the leafname to pad to 12 characters)

Also, remember to translate between BBC filename characters and WinDOS characters:
# <-> ?
. <-> /
$ <-> <
^ <-> >
& <-> +
@ <-> =
% <-> ;
And special case, as it's nonreversable: WinDOS SPC -> BBC _

So, for example, assuming "create .inf" is turned on:
dragging BBC file Menu12 gives WinDOS file Menu12 and Menu12.inf containing (eg) Menu12 FFFF1200 FFFF803A
dragging BBC file Build/src gives WinDOS file Build.src and Build.src.inf containing (eg) Build/src FFFF1900 FFFF801E
dragging BBC file PIC1=2? gives WinDOS file PIC1@2# and PIC1@2#.inf containing (eg) PIC1=2? FFFF3000 FFFF3000

Dragging WinDOS file Client65 gives BBC file Client65 and if Client65.inf exists, sets the load/exec from the contents
Dragging WinDOS file notes.txt gives BBC file notes/txt and if notes.txt.inf exists, sets the load/exec from the contents
Dragging WinDOS file Build#1.zip gives BBC file Build?1/zip and if Build#1.zip.inf exists, sets the load/exec from the contents
Dragging WinDOS file Image 1 gives BBC file Image_1 and if Image 1.inf exists, sets the load/exec from the contents
Dragging WinDOS file TMP@1.$$$ gives BBC file TMP=1/<<< and if TMP@1.$$$.inf exists, sets the load/exec from the contents

Converting leafname characters is a lot simpler than translating characters in full pathnames are you aren't needing to parse pathname-specific characters, a translation of this will do it for you:
80 DEFFNfn_zip(B$):LOCALB%:A$="#?./$<^>&+@=%; "
90 FOR A%=1 TO LEN B$:B%=INSTR(A$,MID$(B$,A%,1))-1
100 IF B%>TRUE:B$=LEFT$(B$,A%-1)+MID$(A$+"_",(B%EOR1)+1,1)+MID$(B$,A%+1)
110 NEXT:=B$

You will need to truncate WinDOS leafnames to fit the destination BBC filesystem. You probably need a user-settable option or dialogue to enable/disable this and to chose what to do if multiple files truncate tpo the same leafname (eg Build Source 1 and Build Source 2 both truncate to Build_Sour.

You also need an option to decide what to do with DFS directory prefixes, does DFS T.ReadMe go to WinDOS T.ReadMe, T\ReadMe or ReadMe.T ? DFS $.name always goes to WinDOS name

Also, remove the space from the program name. Spaces in filenames are the sperm of the devil, and are a particular right pain in executable pathnames.

[jgharston]

If you're having problems preserving metadata dragging/dropping between different images open in BeebImage, then BeebImage knows it's got the two images open, so it can tell itself what the metadata is that needs transfering.

[tricky]

Thanks, that sounds really useful as making ADFS discs of my games is currently a painful manual process in an emulator.

...I haven't been able to work out how to implement drag-and-drop in a way that will preserve BBC files' load and execution addresses...

BeebEm (and maybe others) write a file with a .INF extension with the same name as the beeb file to windows with the original name and info eg:

LOADER on a beeb when "exported" with beebem and $ as the current directory will give:
LOADER and LOADER.INF
The inf file contains:

Code: Select all

$.LOADER  FF1900 FF8023 000B75

In this case a BASIC program (&8023) that was saved with DFS and PAGE at &1900 (load address); lenght &B75 bytes, although you coulds get that from the file.

Edit: PS sorry jgh, I've only just noticed you made two posts while I was typing mine. I only saw the shorter one immediately above this one.

[jgharston]

From the documentation:

In addition, "illegal" characters are converted to "legal" ones. Most characters that are unacceptable by the filing system of the destination disk or image are replaced with underlines, with the following exceptions:

NO NO NO NO NO NO NO! Don't invent your own system, use the pre-existing system, the one that's been around for 31 years, as described in my previous post.

[jgharston]

The ###BBC.inf file is a text file, which can be edited directly with a text editor if required.
...
<dir>.<filename> [L] <load address> <execution address>
Files Saved from ADFS:
<filename> <attributes> (<cycle number>) <load address> <execution address>

Again, NONO NO NO NO NO NO NO. Don't invent your own system, use the pre-existing system that's been around for more than 28 years.

<filename> <load address> <execution address> [L]|<access>

[CMcDougall]

^ don't re invent the wheel , or stop listening to '2 Unlimited - No limits" ....

will give your proggy a spin David

[jgharston]

Ah, very first image I test happend to be a SystemDOS disk. Extracting files from directory ' ' creates files ABASIC._ etc. Atom/System uses ' ' as the root directory instead of '$', so to avoid masses of frustated renaming back and forth, would be useful to have a 'assume this is the default directory' sort of option.

"VList/src" was extracted as "Vlist_src". That's definitely wrong. Don't invent your own scheme, must be "VList.src", see above.

I got 'can't understand this disk' when loading ABZTtxt.ssd, not sure why, DFS Explorer is ok with it.
and BasUtils.ssd
and JJR1.dsd, Music2.ssd, and a bunch of other stuff.

I can't work out how to copy from one image to another I tried running two copies, but that didn't work either.

Free space &3D08300 (63996672) - ooo, that would be easier to read as 63,996,672.

...now I'll have to tidy up the mess of files I've made from testing

I'm on the edge of saying that extracted filenames should match what UnImg does, but I have a nagging thought at the back of my head saying there's an edge case where UnImg gets things wrong, and I can't remember what it is.

[jgharston]

Discovered how to copy between images!

Probably just a display formatting issue, but I
copied dfs:RGBEDIT to adfs:RGBEDIT - worked ok.
then copied adfs:RAMCOUNT/S to dfs:RAMCOUN - copy worked ok, but the RGBEDIT entry changed from being displayed DFS style:
* $ RGBEDIT FFFFFB56 0002B070 001AB
to being displayed ADFS style
* RGBEDIT WR FFFFFB56 0002B070 001AB 00

[jgharston]

To select a directory (as opposed to a file with with usual FileOpen dialog) you need to use FolderBrowserDialog.

Code: Select all

    if (folderBrowserDialog1.ShowDialog() == DialogResult.OK) 
    {
        textSelectedPath = folderBrowserDialog1.SelectedPath;
    }

[yellowpig]

I will go through JGH's posts and do what I can about sorting some of these things out. Some of them will take some thinking about.

Most of the choices I made seemed to make sense at the time. I am not familiar with all the standards mentioned.

David

[danielj]

Fear not!

d.

[simonm]

This looks very promising! I was thinking recently (since I'm archiving a lot of acorn disks) that a tool like this would be super useful.
Out of interest - do you have any plans to open source it? (via Github etc.)

[simonm]

On a related note, since these days a lot of modded systems use CF or SD cards, does anyone know if it's easy to parse the .img files you get from a CF card (using a tool like win32diskimager) as an ADFS HD image? I presume they are low level byte copies of whats on the card, but not sure how the data is formatted.

This would be terrific, as we could stuff files onto the CF card on the host acorn machine, then read back the image of it on a PC, and get the files back to PC using a tool like this. Or vice-versa: create compilation images on a PC that can be written straight to CF etc.

[CMcDougall]

had a go & it's soooooo easy!

just : Image>load image
have a few discs open: ADFS (spit), DFSssd & DFSdsd , choose file by highlighting then: File >Copy files ,
change to other disc (tabs), File >Paste files
Done

all this .INF files, that's soooo 2002

[yellowpig]

When you receive a drag'n'drop file, append ".inf" to the filename and if it exists use its contents as the BBC metadata. The format is:
(one_or_more_non_space_characters)(one_or_more_spaces)(hex_address)(one_or_more_spaces)(hex_address)(any_supplimentary_info)
for instance:

...

Yes, I can see that this might well work.

However, I think it does involve having a separate .inf file for every BBC file. I was trying to avoid this and have a single .inf for the whole directory, because all of these files create so much clutter in the Explorer display. Perhaps it is unavoidable, though.

[danielj]

I realise that it's a "standard" that's been used for forever, but I would add my two penneth by suggesting it's a standard that I've not had to worry about since about 1998 - in fact I've actively avoided using anything that saves files like that simply as it's so messy.

Why not support both options - a single file containing the meta-data for the directory, or individual INF files. Just because something was done first doesn't mean it's the best way of doing something. It's not like there's an international body dictating the standards for storing Acorn files on filesystems that don't hold Acorn metadata?

*dives into bunker*

d.

[yellowpig]

Also, remember to translate between BBC filename characters and WinDOS characters:
# <-> ?
. <-> /
$ <-> <
^ <-> >
& <-> +
@ <-> =
% <-> ;
And special case, as it's nonreversable: WinDOS SPC -> BBC _

and

From the documentation:

In addition, "illegal" characters are converted to "legal" ones. Most characters that are unacceptable by the filing system of the destination disk or image are replaced with underlines, with the following exceptions:

NO NO NO NO NO NO NO! Don't invent your own system, use the pre-existing system, the one that's been around for 31 years, as described in my previous post.

I can certainly do this, but I wasn't familiar with this particular correspondence.

I didn't try to invent a system. I began with the translation as used by the Master 512's MOVE.EXE utility. (It is in Robin Burton's Master 512 Technical Guide on page 166.) This didn't quite work, however, so I just tweaked it a bit.

Where did the list you mention come from?

David

[yellowpig]

The ###BBC.inf file is a text file, which can be edited directly with a text editor if required.
...
<dir>.<filename> [L] <load address> <execution address>
Files Saved from ADFS:
<filename> <attributes> (<cycle number>) <load address> <execution address>

Again, NONO NO NO NO NO NO NO. Don't invent your own system, use the pre-existing system that's been around for more than 28 years.

<filename> <load address> <execution address> [L]|<access>

Once again, I can do things as you outline, but I didn't invent the format I have used. It is the format output by *INFO in Acorn DFS/ADFS.

The idea I had in mind (perhaps a silly one) was that you could SPOOL *INFO * (or *EX) and use the result as a .inf file.

[yellowpig]

Ah, very first image I test happend to be a SystemDOS disk. Extracting files from directory ' ' creates files ABASIC._ etc. Atom/System uses ' ' as the root directory instead of '$', so to avoid masses of frustated renaming back and forth, would be useful to have a 'assume this is the default directory' sort of option.

"VList/src" was extracted as "Vlist_src". That's definitely wrong. Don't invent your own scheme, must be "VList.src", see above.

I got 'can't understand this disk' when loading ABZTtxt.ssd, not sure why, DFS Explorer is ok with it.
and BasUtils.ssd
and JJR1.dsd, Music2.ssd, and a bunch of other stuff.

Let me know where I can find these disks (archives somewhere, I expect) and I will see what the problem is.

[yellowpig]

To select a directory (as opposed to a file with with usual FileOpen dialog) you need to use FolderBrowserDialog.

Code: Select all

    if (folderBrowserDialog1.ShowDialog() == DialogResult.OK) 
    {
        textSelectedPath = folderBrowserDialog1.SelectedPath;
    }

Sorry, but I hate the Folder Browser Dialog. Not only is the look and feel of it as though it comes from Windows95 (which it does), but browsing with it is awkward, and you can only select one folder at a time.

What I really wanted was a way of selecting both files and folders from a folder. It is obviously possible, because that is what Windows Explorer does, but it is not obvious how to do it from any of the standard WPF controls. (Of course, I could write my own custom contol to do it, but that is a lot of work.)

David

[yellowpig]

This looks very promising! I was thinking recently (since I'm archiving a lot of acorn disks) that a tool like this would be super useful.
Out of interest - do you have any plans to open source it? (via Github etc.)

I will tie up a few loose ends (like some of those mentioned in this thread) and improve the comments in the source. Then I am quite happy to make it publicly available.

It is written in Visual Studio 2015 using C# - I know it is not everybody's favourite language, but it is what I currently know best and have come to quite like it.

David

[simonm]

Sounds great David. It's been brilliant to see how much community effort has enhanced open sourced projects like BeebAsm and B-Em.
I actually much prefer c# over c++ for getting stuff done quickly. Plus I believe .NET apps can run just fine on Mac/Linux using Wine.

[Pernod]

This is looking really useful, thanks

I've been using it to create a couple of floppy images for use with the Atom, by importing ATM files, and have a feature request.

Atom ATM files contain a 22 byte header:
00-15 Filename
16-17 Load address (lb-hb)
18-19 Execute address (lb-hb)
20-21 Filelength (lb-hb)
22- File data

So in order to import the files I had to strip the header and manually input the load/exec addresses, this could be automated. You can detect the ATM filetype being imported either by extension ATM, or preferably look at bytes 20-21 and if they match filesize-22 then must be ATM.
Steps to import ATM:
- check filetype is ATM by comparing bytes 20-21 with filesize-22
- if ATM then strip header bytes 00-21 and import
- add load and exec addresses from stripped header, file length should already be correct
- change directory from default '$' to ' ' on all imported files (I had to manually edit the created image to achieve this)

[garfield]

This looks very promising! I was thinking recently (since I'm archiving a lot of acorn disks) that a tool like this would be super useful.
Out of interest - do you have any plans to open source it? (via Github etc.)

I will tie up a few loose ends (like some of those mentioned in this thread) and improve the comments in the source. Then I am quite happy to make it publicly available.

It is written in Visual Studio 2015 using C# - I know it is not everybody's favourite language, but it is what I currently know best and have come to quite like it.

David

This is good to read.

[crj]

However, I think it does involve having a separate .inf file for every BBC file. I was trying to avoid this and have a single .inf for the whole directory, because all of these files create so much clutter in the Explorer display. Perhaps it is unavoidable, though.

It's the third millennium; it really ought to be possible to store Acorn-specific information as extended attributes!

[jms2]

Would it be feasible to simply store the load and exec addresses in the filename? When re-importing the file onto a BBC disk image the filename would need to be truncated anyway.

Even in the absence of software which can interpret the filename correctly, the user could do it manually to re-create the attributes.

Or is there some hidden flaw with this approach?

[tricky]

The MFC and Win32 dialogs just have a allow multiple selection flag, I'll have to go and check the details.
I never did make friends with WPF or C#, although I know some programmers who did

[crj]

Would it be feasible to simply store the load and exec addresses in the filename?

Well... yes. Kinda.

Or is there some hidden flaw with this approach?

I think the main flaws are the obvious ones: it would look hideous, and would mean you couldn't just type the "filename" when dealing with the file on the non-Acorn side.

Acorn's NFS implementation (that's NFS as in the Sun Microsystems protocol, not as in Econet) did something very similar: if a RISC OS file had type &XYZ, the NFS filename would be myFile,xyz . But that was only a fallback if you hadn't set up a filetype to extension mapping for that particular type. It's worth bearing in mind that NFS was designed towards interoperability rather than archival purposes, which might not be ideal.

[sweh]

I realise that it's a "standard" that's been used for forever, but I would add my two penneth by suggesting it's a standard that I've not had to worry about since about 1998 - in fact I've actively avoided using anything that saves files like that simply as it's so messy.

Why not support both options - a single file containing the meta-data for the directory, or individual INF files. Just because something was done first doesn't mean it's the best way of doing something. It's not like there's an international body dictating the standards for storing Acorn files on filesystems that don't hold Acorn metadata?

The INF file is the most portable between solutions. It means that data extracted by one tool can be used directly with another. I use this, for example, with the perl utilities (for extracting SSD images) and HostFS. So I can do

Code: Select all

beeb getfiles foo.ssd ~/Beeb_Disks/500.foo

And that will immediately work with HostFS:UPURS

Creating a new solution will result in reduced compatibility across tools.

Aside, storing the "correct" filename in the INF file and not worrying about the OS "native" filename is the correct way of doing it. foo/bar could be saved as foo_bar as long as foo_bar.inf file says foo/bar and as long as the program that transfers back to the Beeb correctly extracts the filename from the INF file. I'm pretty sure my tools don't match JGH's algorithms for native filenames. But they don't need to, because the INF file holds the real data