imd format

[Bill Cunningham]

I am running across files in .imd format. With both cp/m and dos. I
can't seem to find a tool to deal with this format. It sees to be similar to
img but older.

Bill

[Udo Munk]

IMD tools there: http://www.classiccmp.org/dunfield/img/index.htm

You need to setup a DOS system though, I'm using a virtual one
because I won't waste real hardware for any DOS stuff.

[Bill Cunningham]

"Udo Munk" <udo....@freenet.de> wrote in message
news:5e2fcf75-3425-44b8...@googlegroups.com...

It runs with dosbox. But I don't quite know what to do here. There's so
many tools. Analyzer, viewer. I just want to unarch or uncompress the .imd
file.

Bill

[Udo Munk]

On Saturday, April 11, 2015 at 6:33:14 PM UTC+2, Bill Cunningham wrote:

> It runs with dosbox. But I don't quite know what to do here. There's so
> many tools. Analyzer, viewer. I just want to unarch or uncompress the .imd
> file.

IMD files are disk images, hence the name. Since this are no archives
like zip and so on there are no such operations like unarchive or
uncompress.

Then it comes with documentation, I would suggest to read it,
so that you get an idea what the tools are for and how to use them.

[Udo Munk]

In case you mean with "unarchive" to get files from this images...

What I do is converting the IMD images with IMDU (option /B) to a
raw disk image, that can be used with cpmtools then.

[Bill Cunningham]

"Udo Munk" <udo....@freenet.de> wrote in message

news:f84ac644-036e-4f3f...@googlegroups.com...

> In case you mean with "unarchive" to get files from this images...
>
> What I do is converting the IMD images with IMDU (option /B) to a
> raw disk image, that can be used with cpmtools then.

Oh ok I see then. I think what I am working with right here is a DOS 2.x or
something like that. Really old. I am wanting to look at fat12.

Bill

[Bill Cunningham]

"Udo Munk" <udo....@freenet.de> wrote in message

news:f84ac644-036e-4f3f...@googlegroups.com...

> In case you mean with "unarchive" to get files from this images...
>
> What I do is converting the IMD images with IMDU (option /B) to a
> raw disk image, that can be used with cpmtools then.

Course I've got some old cp/m's too that are in .imd format. I know what to
do with them now.

Bill

[Steven Hirsch]

Yes, like Udo mentioned the only thing you can do without ancient hardware is
convert IMD format to a binary sector image. One of these days I'd like to
port imdu to Linux for exactly that reason. Unfortunately, Dave Dunfield used
his own (highly non-standard) compiler and it looks to be a non-trivial task.

[Udo Munk]

On Saturday, April 11, 2015 at 10:29:37 PM UTC+2, Steven Hirsch wrote:

> Yes, like Udo mentioned the only thing you can do without ancient hardware is
> convert IMD format to a binary sector image. One of these days I'd like to
> port imdu to Linux for exactly that reason. Unfortunately, Dave Dunfield used
> his own (highly non-standard) compiler and it looks to be a non-trivial task.

I think the IMD format is documented good enough to write similar tools
from scratch. As far as I know several emulations can mount IMD images,
so some unixoid source to start from should available. Might be less work
than trying to port it.

[Tom Burnett]

Unixoid source is available. However, it uses stdin/stdio and redirection. This, of course, won't work on Windows because of a now ancient decision by Dr. Gary Kildall to have two types (binary and text) of files in his then new hot operating system that didn't keep track of a last byte of the last sector. ;-)

So, for Windows use, it needs argument checking, a couple of fopens/fcloses and modification of the input/output code to use them.

Udo, might it not be a bad idea to include at least the source (binaries including for Windows would be nice, also) for those who need to convert an *.imd disk file for use on z80pack? You could do in your sleep in less than 10 minutes. If you need a Windows binary (or even my modified source code), just say the word and I'll send it. Along with the Windows port of cpmtools, this combination should do what is needed.

Windows cpmtools is here:
http://www.cpm8680.com/cpmtools/

I sent a copy of my modified source Al Kossow what is probably a year and a half ago now, but if he's posted it, I don't know where it is. For that matter, I don't even know if he has a process/policy on accepting modifications to old software. Per our discussion on the zxcc-windows post, changing old software is tough to sell. However, it's source and is still very useful.

The output is known to be md5 hash identical to Dsve Dunfield's conversion utility. I was working with Bill Buckels on the Windows port of cpmtools and I needed to convert a bunch of imd files to raw sectors to test, work out diskdefs and the like. No DOSBox, no nothing. Native. As you know, I don't like to drop into emulators preferring to run programs directly from the command line. ;-)

Anyway,
There are (at least) two copies on bitsavers.

One is here:
http://bitsavers.trailing-edge.com/bits/Convergent/ngen/imd2raw/imd2raw.c

The other is here:
http://bitsavers.trailing-edge.com/bits/Tektronix/8562/tools/imd2raw.c

The only difference between the two is the size of an internal buffer, I used the big one.

If you don't think it's a good idea, so be it.

If you need anything from me, please let me know.

Tom

[Bill Cunningham]

"Udo Munk" <udo....@freenet.de> wrote in message

news:f84ac644-036e-4f3f...@googlegroups.com...

> In case you mean with "unarchive" to get files from this images...
>
> What I do is converting the IMD images with IMDU (option /B) to a
> raw disk image, that can be used with cpmtools then.

Ok raw binary. Then what cpmtools do you use?

Bill

[Tom Burnett]

If you are running Windows, it pretty much has to be:
http://www.cpm8680.com/cpmtools/

It comes with source code, Windows binaries produced with the MingW C compiler and is ready to use.

There is a bit of a learning curve, but Google for cpmtools will help find examples. Maybe you won't need them, but I sure did.

Full man pages for all commands are on the above Bill Buckels site.

Tom

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message
news:ddfec0b0-50aa-40a9...@googlegroups.com...

I have cpmtools with my linux. This is going to work fine for my cp/m
files. What I'm working on now is dos 2.x something because I want to look
at fat12. The imdu.com tool worked fine in 16 bit enviornment and said
something about '77'. Maybe that's a format. Was the DOS that was coming out
like cp/m in that there were different formats? The page I read said 8"
diskettes.

Bill

[Tom Burnett]

The "77" is almost certainly the number of tracks. That's normal for an 8" disk. That said, I'm not aware MSDOS/PCDOS ever came in 8" format. To say that in a public forum is virtually an engraved invitation to be proved wrong, however. By that time, my 8" drives were long gone. Maybe someone else knows otherwise?

Tom

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message

news:2c56df77-6316-44d8...@googlegroups.com...

The "77" is almost certainly the number of tracks. That's normal for an 8"
disk. That said, I'm not aware MSDOS/PCDOS ever came in 8" format. To say
that in a public forum is virtually an engraved invitation to be proved
wrong, however. By that time, my 8" drives were long gone. Maybe someone
else knows otherwise?

I certainly have to commend you on your C. All standard C it looks to
me. I wish I could whip out C like that. My style is embeded IFs and ELSE
IFs not so much switch() an dwhile occasionally I will use :)

The .bin file I have that imdu.com produced. Is that a filesystem? Does
it need to be examined ? mkfs.cpm shouldn't be needed at al here should it?

Bill

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message

news:2c56df77-6316-44d8...@googlegroups.com...

The "77" is almost certainly the number of tracks. That's normal for an 8"
disk. That said, I'm not aware MSDOS/PCDOS ever came in 8" format. To say
that in a public forum is virtually an engraved invitation to be proved
wrong, however. By that time, my 8" drives were long gone. Maybe someone
else knows otherwise?

fsed.cpm calls the .bin file pcdos. What files I have say msdos. pcdos
and msdos was what was coming out to compete with cp/m I guess. It was my
understanding that Kildall disagreed with a contract and IBM went with MS.
And the rest is history.

I tried "boot b.bin" in dosbox and it said booting drive A and I waited
for a long time and nothing happened. I finally killed dosbox. Maybe it's
the wrong image or something. Yes 77 is part of the format 128 sectors is
part of it too.

Bill

[Tom Burnett]

The "bin" file is the raw sectors disk image. So, yes, it's a file system, but with a very specific (and proprietary to the system manufacturer) format.

No makefs.cpm needed. All you need is cpmls to list a directory of the files and cpmcp to copy them onto your hard drive (or vice-versa).

If the disk format is not listed in diskdefs, you'll need to write one, or, alternatively, score one from a Google search.

What disk format are you using for CP/M i.e what computer did it come from?

And, while I appreciate the compliment on my C, honesty compels me to admit that most of the code is Michael Haardt's. He is the author and maintainer. I just ported it to Windows. As a percentage, very little of the total source code is mine. Michael knows what he is doing.

The home page of the Linux/Unix version is here:

http://www.moria.de/~michael/cpmtools/


Tom

[Tom Burnett]

Read that screen carefully. Are you sure it doesn't say 128 bytes per sector and 26 sectors per track? If it does, it's a standard IBM 3740 8" diskette.

Try this:
cpmls -f ibm-3740 <disk_image_filename>

If you get binary garbage to the screen, you have more investigation to do.

If you get a nice, clean directory listing, you're home free.

Tom

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message

news:22d6fdce-c4d5-40b1...@googlegroups.com...

> Read that screen carefully. Are you sure it doesn't say 128 bytes per
> sector and 26 sectors per track? If it does, it's a standard IBM 3740 8"
> diskette.
>
> Try this:
> cpmls -f ibm-3740 <disk_image_filename>
>
> If you get binary garbage to the screen, you have more investigation to
> do.
>
> If you get a nice, clean directory listing, you're home free.

Yes it called it an ibm-3740. I must've confused bytes per sector and
sectors per track.

Bill

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message

news:22d6fdce-c4d5-40b1...@googlegroups.com...

[snip]

> If you get a nice, clean directory listing, you're home free.

I did indeed get some garbage. Now I am stuck.

Bill

[Tom Burnett]

What is the size of your image file?

If it's 256,256 bytes (77*128*26) you may have a corrupted disk.

Tom

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message

news:53323b2d-c0ee-44ba...@googlegroups.com...

> What is the size of your image file?
>
> If it's 256,256 bytes (77*128*26) you may have a corrupted disk.

That's it exactly. So is there no hope for it then?

Bill

[Tom Burnett]

It's probably corrupted. Some files may be usable. What kind of a directory list do you get? Any filenames look good? Make another copy with IMDU /B (don't forget the /B). Does IMDU complain about anything when the conversion is done? Can you download another copy and try that? You just have to play with it a bit. Hopefully the files are recoverable.

Tom


Tom

[ldkr...@gmail.com]

Bill,
You can also use SAMDisk (ver 3.8.7) to convert your .IMD file.


Larry

[Tom Burnett]

I've uploaded imd2raw.c and imd2raw.exe to GitHub.

URL: https://github.com/Tbxxx/zxcc-windows/

It's in the directory "imd2raw".

Linux people: It should compile and run on Linux with no problems. If it doesn't, please let me know.

Tom

[Tom Burnett]

Bill, now that I think about it, go out to the 'Net and find a "strings.exe" file. Then run strings on your disk file and pipe it through "more" like this:
strings <image.dsk> | more

You'll see a lot of non sense characters, but you'll also see the disk's directory. If it has io.sys, autoexec.bat, command.com, gwbasic.exe or any other MSDOS file, cpmtools will never read it. Honestly, I have no idea how to get files from an 8" ibm 3740 diskette. However, if it shows CP/M files, it may still be recoverable.

Finally, if the file you want is text, strings will show it. You can redirect the output to a file and edit the garbage out leaving the file you want. I know it's not very elegant, but it'll work if the text file really needs to be recovered. If it's a binary file, try to find it in a 5.25" or 3.5" format. (only half a ;-) )

A Google for "windows strings programs" finds a lot of them with a Microsoft one at the top ready for download.

Strings will print all printable characters that are at least 4 (usually the default, but also usually changeable with a command line option) characters in length i.e. it has to have 4 printable characters in a row in order to be printed to the screen. It's a very useful utility for lots of uses.

Good luck.
Tom

[Udo Munk]

On Saturday, April 11, 2015 at 11:32:53 PM UTC+2, Tom Burnett wrote:

> Udo, might it not be a bad idea to include at least the source (binaries
> including for Windows would be nice, also) for those who need to convert
> an *.imd disk file for use on z80pack? You could do in your sleep in less
> than 10 minutes. If you need a Windows binary (or even my modified source
> code), just say the word and I'll send it. Along with the Windows port of
> cpmtools, this combination should do what is needed.

I think this tools are needed by everyone who wants to handle disk image
files for emulations or write real floppy disks with them. This is better
put at some more generic place, you have uploaded it to github now. That's
better than including it in z80pack. I have downloaded the C source and I
will try it out sometime when time permits. Would save me to fiddle with
a virtual DOS system, if I can convert the IMD images directly on my
workstations. Thanks for making it available.

[ldkr...@gmail.com]

Tom,
I compiled the imd2raw.c in Debian 7.x (64 Bit) and it functions properly.

[code]
gcc -Wall imd2raw.c -oimd2RAW
chmod 755 imd2raw
./imd2RAW KP2-000.imd KP2-000.dsk
[/code]

THANKS.


Larry

[Tom Burnett]

I understand your point, but an obscure post to GitHub isn't going to get the exposure that inclusion in z80pack would. But that's your call.

It should run on virtually anything. It's ANSI C with no dependencies on anything other than the standard C library. I see Larry has already compiled and ran it on Linux.

Note, I'm not enough of a low-level floppy person to have written it. I just changed the file I/O, argument checks, etc. to make it work anywhere.

Tom

[Udo Munk]

On Sunday, April 12, 2015 at 2:34:43 PM UTC+2, Tom Burnett wrote:

> I understand your point, but an obscure post to GitHub isn't going
> to get the exposure that inclusion in z80pack would. But that's your
> call.

Also true, I have uploaded it to the tools directory here:
http://www.autometer.de/unix4fun/z80pack/ftp/tools/

> It should run on virtually anything. It's ANSI C with no dependencies
> on anything other than the standard C library. I see Larry has already
> compiled and ran it on Linux.

I just compiled it on OS X, works too, should also do for other BSDish
systems.

[Udo Munk]

On Sunday, April 12, 2015 at 2:53:32 PM UTC+2, Udo Munk wrote:

> Also true, I have uploaded it to the tools directory here:
> http://www.autometer.de/unix4fun/z80pack/ftp/tools/

Added a short readme file too, so after a while it probably
shows up in the search engines, when one searches for IMD tools.

[Tom Burnett]

Cool. I would like it available for those who need it. It's a pain to go into DOSBox just to process an *.imd file. Most of Mr. Dunfield's code is 8086 assembly between #asm and #endasm statements. I'm not even really complaining. His tools are essential and I see more IMD format files every day. I just needed to be able to access them with other programs (e.g. cpmtools) so a painless conversion was nice.

Tom

[Udo Munk]

On Sunday, April 12, 2015 at 3:14:48 PM UTC+2, Tom Burnett wrote:

> Cool. I would like it available for those who need it. It's a
> pain to go into DOSBox just to process an *.imd file. Most of
> Mr. Dunfield's code is 8086 assembly between #asm and #endasm
> statements. I'm not even really complaining. His tools are
> essential and I see more IMD format files every day. I just
> needed to be able to access them with other programs (e.g. cpmtools)
> so a painless conversion was nice.

I had the same problem with the Cromemco images from Marcus Bennett's
site, this are mostly IMDs. For me it was a pain to to use a Virtualbox
DOS system to process the disks. This makes it much easier and
probably many others can use this too. Thanks again.

[Al Kossow]

On 4/11/15 2:32 PM, Tom Burnett wrote:

> Anyway,
> There are (at least) two copies on bitsavers.
>
> One is here:
> http://bitsavers.trailing-edge.com/bits/Convergent/ngen/imd2raw/imd2raw.c
>
> The other is here:
> http://bitsavers.trailing-edge.com/bits/Tektronix/8562/tools/imd2raw.c
>
> The only difference between the two is the size of an internal buffer, I used the big one.
>

imd2raw is still a work in progress. It's good enough for what I needed to do for the Tek and Convergent
media conversions, but there are problems with it, like correctly dealing with unreadable sectors and some
corner cases with disks with mixed sector types.

I should put media conversion tools into a 'tools' tree parallel to bits and pdf on bitsavers.

[Bill Cunningham]

"Tom Burnett" <tbur...@gmail.com> wrote in message

news:7901de34-47ef-41d3...@googlegroups.com...

It's probably corrupted. Some files may be usable. What kind of a
directory list do you get? Any filenames look good? Make another copy with
IMDU /B (don't forget the /B). Does IMDU complain about anything when the
conversion is done? Can you download another copy and try that? You just
have to play with it a bit. Hopefully the files are recoverable.

I don't get any file names. Just:
5:
10:

And entriess like that and character like garbage.

Bill

[Tom Burnett]

OK, try the strings trick. If you see MSDOS filenames, that's the problem. Once again, I have no idea how to get files off an 8" MSDOS disk. Perhaps someone else knows.

If it's IBM 3740 format (and it is) and no imd2raw errors, then it should show a good directory listing if it's CP/M. That was the only "standard" there ever was. I think one of the major reasons MSDOS knocked off CP/M so quickly is disk interchangeability. At any given state of the art, if you handed someone a PC disk, you knew they could read it. Almost every manufacturer was different in CP/M. Serial ports also. You bought a communications program for your PC, it just worked. No finding the right overlay, using DDT to apply it and then a save command and all that stuff.


Tom

[Tom Burnett]

On Sunday, April 12, 2015 at 10:57:12 AM UTC-7, Bill Cunningham wrote:

Al,
Imd2raw worked well for something approaching 100 images while I was working on cpmtools for Windows. I posted a dozen or so diskdefs in comp.os.cpm that are now in the standard distribution. So it seems to be pretty solid, but no doubt you run across many more disk formats than I'll ever see. So, I think it's fair to say, at least for the common ones, it works well. I didn't realize you wrote it (read: put your name in it). I just thought I got lucky exploring. ;-) I was in the convergent directory because I used to develop on it in my Pacific Bell days. A utility like that is really needed. IMDU works great, but is dependent on MSDOS (real or emulated) and is much more convoluted to use than a 32 bit program in your PATH somewhere especially if your Windows is 64 bit and won't run a 16 bit executable directly.

A separate tools area is a great idea.

Tom

[dottor Piergiorgio M. d' Errico]

why parallel ?

disk image and .pdf/scans tools are different enough for consistency
having a tools/ dir in both bits and pdf.. (Mind you, I kept a large
"mirror" of your great archive in one of my HD:

> du -s dino/
> 180936356 dino/

("dino" (as the very old mainframes are affectionately remembered) is,
for historical reasons, the root dir of said select mirror)

Best regards from Italy,
Dott. Piergiorgio.