SAMdisk .IMD file compatibility

[Jeff Albrecht]

Noticed a mention of SAMdisk in another thread.

Downloaded v. 3.8.7 from http://simonowen.com/samdisk/ to 64 bit win 8.1

Found some .IMD files I'm interested in for CompuPro and Kaypro II from http://www.classiccmp.org/dunfield/img54306/system.htm

Trying several of the .IMD files I'm able to get 'info', but not a 'dir' directory. 'view' does show a raw dump.


** info **
C:\Users\Jeff\OneDrive\Development\CPM\kayproii>C:\Users\Jeff\OneDrive\Developme
nt\CPM\SAMdisk387\samdisk info kaypro1.imd
[kaypro1.imd]
Type: IMD
Size: 40 Cyls, 1 Head

IMD 1.01: 3/08/2005 11:48:57
KAYPRO II
CP/M 2.2

C:\Users\Jeff\OneDrive\Development\CPM\kayproii>

** dir **
C:\Users\Jeff\OneDrive\Development\CPM\kayproii>C:\Users\Jeff\OneDrive\Developme
nt\CPM\SAMdisk387\samdisk dir kaypro1.imd
Error: unrecognised directory format

C:\Users\Jeff\OneDrive\Development\CPM\kayproii>

I guess a generic cp/m directory is not supported?? From the readme.txt

The currently supported formats are:

SAM Coupé and MGT +D
ProDos CP/M
Amstrad CPC and Spectrum +3 CP/M
Opus Discovery
TR-DOS
Didaktik

Are there utilities that allow file extraction from .IMD file images? Or just writing a disk from a .IMD image?

I can setup a VM and/or I have an IBM XT with ethernet and tcp/ip connectivity.

[David Schmidt]

On 4/12/2015 9:19 AM, Jeff Albrecht wrote:
> Are there utilities that allow file extraction from .IMD file images? Or just writing a disk from a .IMD image?
>
> I can setup a VM and/or I have an IBM XT with ethernet and tcp/ip connectivity.

I only skimmed the other thread... but the way to deal with .imd is to
us imdu.exe to convert to a non-compressed, unadulterated .img:
imdu /B kaypro1.imd kaypro1.img

...and then take a look at your kaypro1.img with various tweaks to
diskdefs in cpmtools. Your Kaypro images are probably just a little
different than SAMdisk expects, and a simple tweak to where the
directory lives, bytes per sector, or whatever will straighten it out.

[Tom Burnett]

There is available on GitHub both source code and a Windows binary for imd2raw that will do the conversion directly from 64 bit Windows.

It is here under the imd2raw directory:
https://github.com/Tbxxx/zxcc-windows/

Tom

[dottor Piergiorgio M. d' Errico]

these format are for machines not originally intended for CP/M or
derived from these (Opus Discovery and MGT are the two major 3rd party
disk drive interface for the Spectrum, Didaktik was an East europe
advanced clone of the Spectrum, the SAM Coupè was a western EU one (!);
the Amstrad CPC was another, different, UK home computer. TR-DOS and
ProDos are known enough here, I guess.

I suspect is that the program you used is intended for those perforce
more eccentric/peculiar disk formats and handle their quirks (notice
that the amstrad and spectrum +3 use an 3" (76mm) floppy and the
so-called "prodos CPM" dealt with Woz's genial but unconventional 5¼
controller)

HTH, and

Best regards from Italy,
dott. Piergiorgio.

[Jeff Albrecht]

Ran it with the following results. It created a .DSK of 204,800 bytes.

C:\Users\Jeff\OneDrive\Development\CPM\kayproii>C:\Users\Jeff\OneDrive\Developme

nt\CPM\zxcc-windows-master\zxcc-windows-master\imd2raw\imd2raw kaypro1.imd kaypr
o1.dsk
Cyl 00 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 01 Hd 0 512 ..C....CC. 0 8 3 6 1 9 4 7 2 5
Cyl 02 Hd 0 512 C......... 0 8 3 6 1 9 4 7 2 5
Cyl 03 Hd 0 512 .......C.. 0 8 3 6 1 9 4 7 2 5
Cyl 04 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 05 Hd 0 512 ..C....C.. 0 8 3 6 1 9 4 7 2 5
Cyl 06 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 07 Hd 0 512 .CCC...C.C 0 8 3 6 1 9 4 7 2 5
Cyl 08 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 09 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 10 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 11 Hd 0 512 ....C..... 0 8 3 6 1 9 4 7 2 5
Cyl 12 Hd 0 512 ..C....... 0 8 3 6 1 9 4 7 2 5
Cyl 13 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 14 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 15 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 16 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 17 Hd 0 512 .....CC..C 0 8 3 6 1 9 4 7 2 5
Cyl 18 Hd 0 512 .C...C.C.. 0 8 3 6 1 9 4 7 2 5
Cyl 19 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 20 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 21 Hd 0 512 .......C.. 0 8 3 6 1 9 4 7 2 5
Cyl 22 Hd 0 512 ..C....... 0 8 3 6 1 9 4 7 2 5
Cyl 23 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 24 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 25 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 26 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 27 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 28 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 29 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 30 Hd 0 512 .....C...C 0 8 3 6 1 9 4 7 2 5
Cyl 31 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 32 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 33 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 34 Hd 0 512 .....C.... 0 8 3 6 1 9 4 7 2 5
Cyl 35 Hd 0 512 ....C..... 0 8 3 6 1 9 4 7 2 5
Cyl 36 Hd 0 512 ....C..... 0 8 3 6 1 9 4 7 2 5
Cyl 37 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 38 Hd 0 512 .......... 0 8 3 6 1 9 4 7 2 5
Cyl 39 Hd 0 512 .CCC.CCC.C 0 8 3 6 1 9 4 7 2 5

C:\Users\Jeff\OneDrive\Development\CPM\kayproii>dir *.dsk
Volume in drive C is Windows
Volume Serial Number is 1698-97D5

Directory of C:\Users\Jeff\OneDrive\Development\CPM\kayproii

04/12/2015 09:05 AM 204,800 kaypro1.dsk
1 File(s) 204,800 bytes
0 Dir(s) 822,126,235,648 bytes free

C:\Users\Jeff\OneDrive\Development\CPM\kayproii>

Then I mounted it and attempted to read:
Perhaps I need a Kaypro simulator?

Altair 8800 (Z80) simulator V3.8-1 build 1296 (scp created May 3 2009 at 12:19:
34 with gcc 4.2.4)

sim> attach dsk2 kaypro1.dsk
sim> do cpm2

64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.27, 2 HD, 02-May-2009)

A>dir c:
C: : : :
A>

[Tom Burnett]

I don't think the Schorn Altair simulator (simh) has the capability to read kaypro disks.

The cpmtools port to Windows does. It's at Bill Buckels' site:

http://www.cpm8680.com/cpmtools/

The 204,800 size means it's almost certainly a Kaypro II disk.
It's already included in the diskdefs file that comes with cpmtools, but for reference it's:
# Kaypro II
diskdef kpii
seclen 512
tracks 40
sectrk 10
blocksize 1024
maxdir 64
skew 0
boottrk 1
os 2.2
end

So 512*40*10 (bytes/sec * tracks * sectors/trk) = 204,800

A directory can be done with:
cpmls -f kpii <image_name>

So, yes, you either need a Kaypro emulator/simulator or cpmtools. I don't think simh does Kaypro. Lots of other stuff and very well I might add.

Tom

[retrogear]

just a quick rundown:

with imagedisk utilities expand the image:

C:\imd>imdu kaypro1.imd kaypro1u.imd /E
IMageDisk Utility 1.17 / Jun 27 2008

IMD 1.01: 3/08/2005 11:48:57
KAYPRO II
CP/M 2.2

0/0 250 kbps DD 10x512
40 tracks(40/0), 400 sectors (34 Compressed)

use samdisk to convert to .raw

C:\imd>samdisk kaypro1u.imd kaypro.raw
Wrote 40 cyls, 1 heads, 10 sectors, 512 bytes/sector = 204800 bytes

rename kaypro.raw to kaypro.img and run cpmtools:

C:\cpmtools>cpmls -f kpii kaypro.img 0:*.*
0:
asm.com
basiclib.rel
baud.com
config.com
copy.com
ddt.com
diskdef.lib
dplay.bas
dump.asm
dump.com
ed.com
fac.bas
fac.com
format.com
load.com
movcpm.com
oki.2
overlayb.com
pip.com
sbasic.com
sbios.asm
stat.com
submit.com
sysgen.com
term.com
userlib.rel
xamn.bas
xsub.com

C:\cpmtools>

[Jeff Albrecht]

I wonder if you used the same input source that I used? I ran cpmls against the kaypro1.dsk file I created with imd2raw.exe from kaypro1.img in the Kaypro II System Disks here http://www.classiccmp.org/dunfield/img54306/system.htm

My directory is far shorter than yours. Note that if I used the syntax 'cpmls -f kpii kaypro.img' I get the same directory but with garbage before and after.

C:\Users\Jeff\OneDrive\Development\CPM\cpmtoolsWin32\cpmtools>cpmls -f kpii kayp
ro1.dsk 0:*.*
0:
asm.com
baud.com
copy.com
ddt.com
ed.com
format.com
movcpm.com
overlayb.com
pip.com
sbasic.com
stat.com
submit.com
sysgen.com
term.com
xsub.com

C:\Users\Jeff\OneDrive\Development\CPM\cpmtoolsWin32\cpmtools>

[Jeff Albrecht]

> So, yes, you either need a Kaypro emulator/simulator or cpmtools. I don't think simh does Kaypro. Lots of other stuff and very well I might add.
>
> Tom

Any ideas on an entry for cpmtools diskdefs for CompuPro 8" SSDD and DSDD formats? I grepped without finding for compupro, visan and godbout.

[ldkr...@gmail.com]

The later versions of cpmtools require more switches to get a directory listing.

I used imd2raw to convert KP2-000.IMD to KP2-000.DSK

Then I used cpmls to view the directory of the .DSK image

larry@debian:~/Downloads/imd2raw$
[code]
cpmls -f kpii -T raw KP2-000.dsk 0:*.*
[/code]

[quote]
0:
asm.com
config83.com
ddt.com
disk4tst.com
du-87.com
dump.com
ed.com
filter.com
initdisk.com
load.com
modem903.com
movcpm.com
newtr.com
nsweep.com
nulu12.com
pip.com
[/quote]

[quote]
larry@debian:~/Downloads/imd2raw$ cpmls
Usage: cpmls [-f format] [-T libdsk-type] [-d|-D|-F|-A|[-l][-c][-i]] image [file ...]
larry@debian:~/Downloads/imd2raw$
[/quote]

Larry

[David Schmidt]

On 4/12/2015 2:56 PM, Jeff Albrecht wrote:
> Any ideas on an entry for cpmtools diskdefs for CompuPro 8" SSDD and DSDD formats? I grepped without finding for compupro, visan and godbout.

Tell us something about the disk geometry (tracks, sectors, bytes per
sector, FM vs. MFM for the first two tracks or not) and we can help you
get something together...

[Tom Burnett]

Larry,

Obviously, I need to update the Windows port. ;-) Michael has apparently been busy.

Jeff,

The only way I know to do it is to start from something similar (e.g. DSDD or SSDD) from another entry and copy it with a new unique name. There are only so many things that (usually!) can change. So you look at the imd2raw data when the conversion is done and it will tell you how many tracks/sides/sector size/sectors per track, etc. Change the corresponding data in your new entry to match. Then try a directory listing. If it continues with garbage at the end, make your number of directory entries smaller. And so on and so forth. It's not difficult so much as repetitive, but it doesn't usually take very long to nail it. Then publish it here or somewhere else public so it's readily available. Hopefully, Michael will find it and put it in the next release.

The key is a good, clean directory list (preferably one that matches a strings output - if there is a bunch more files in a strings output, make the directory larger and hope they aren't erased files) and a cpmcp that copies all the files to the local directory. Are there E5 bytes in the files (or, for that matter, garbage BETWEEN file listing in the cpmls? Are the text files "scrambled"? Can you run a sample com program? If there are those kinds of problems, that's a skew issue. If you can't get a directory at all when you're pretty sure you have the start location right (via a hex dump program), then look at the number of boot tracks. You and disk have to agree on everything for it to work.

Tom

[ldkr...@gmail.com]

Jeff,
I used the COM8 & COM9 Disk Definitions to create my absolute best guess of the
cpmtools definitions. You might have to use SKEW 0 (or [0..8] to find the correct one)

When you get a good directory listing then type put a long text file to see if
it is complete. Modify as needed.

diskdef COM8 #= Compupro (Viasyn) 8/16 1,024 bytes/sector - SSDD 8"
#= MFM, HIGH DENSITY
seclen 1024 #= Sectors xx,1024
tracks 77 #= (Cylinders * Sides) = 77*1 = 77
sectrk 8 #= Sectors 8,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 128
skew 3 #= may be 0 thru 6, or so
boottrk 2 #= OFS = 2
os 2.2 #= 2.2, or 2, or 3
end



diskdef COM9 #= Compupro (Viasyn) 8/16 1,024 bytes/sector - DSDD 8"
#= MFM, HIGH DENSITY, ORDER SIDES
#= ORDER SIDES specifies that first one side then the other is written/read
# before the cylinder number is advanced.
seclen 1024 #= Sectors xx,1024
tracks 144 #= (Cylinders * Sides) = 77*2 = 144
sectrk 8 #= Sectors 5,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 256
skew 3 #= may be 0 thru 6, or so
boottrk 4 #= OFS = 4
os 2.2 #= 2.2, or 2, or 3
end



Good Luck.


Larry

[retrogear]

> I wonder if you used the same input source that I used? I ran cpmls against the >kaypro1.dsk file I created with imd2raw.exe from kaypro1.img in the Kaypro II >System Disks here http://www.classiccmp.org/dunfield/img54306/system.htm

Yes it's the kaypro II system disks link (kayproii.zip) then kaypro1.imd in that zip. For some reason you're seeing half the files. I trust samdisk over other conversion utilities. I've had better results with it. Even converting teledisk .td0 is better than td02imd. Simon Owen's last update was just a month ago.

BTW - Schorn's simh Altairz80 supports the CompuPro 8" formats

Larry G

[Jeff Albrecht]

On Sunday, April 12, 2015 at 12:18:53 PM UTC-7, ldkr...@gmail.com wrote:
> Jeff,
> I used the COM8 & COM9 Disk Definitions to create my absolute best guess of the
> cpmtools definitions. You might have to use SKEW 0 (or [0..8] to find the correct one)
>
> When you get a good directory listing then type put a long text file to see if
> it is complete. Modify as needed.
>
> diskdef COM8 #= Compupro (Viasyn) 8/16 1,024 bytes/sector - SSDD 8"

Larry,

Did you write these? COM8, COM9? They were not in the cpmtools diskdefs windows port that I just downloaded from the link in this thread. Perhaps they're in the mainline linux distro?

David, I grabbed the CompuPro manual .pdf image and ocr'd the following from the format section:

After the user has specified the drive to be formatted, FORMAT
attempts to determine the specified disks format. The disk format
or lack thereof is displayed for the user and a message requesting
the new format selection is displayed. The format of these
displays are as follows:
8" disk: 77 tracks, 1 sided, format #0, 128 byte sectors.
Track 0, All other tracks, Density, Format type:
128/SD, 26 x 128 bytes, Single a 0 IBM 1 (3740)
128/SD, 26 x 256 bytes, Double - 1
128/SD, 15 x 512 bytes, Double = 2
128/SD, 8 x 102A bytes, Double - 3
Select Disk format type (0-3):
0 - 128 2 - 512
1 - 256 3 - 1024

[ldkr...@gmail.com]

Jeff,
I made a few updates to the original ccpmtools definitions:


diskdef title
seclen xxx #= Sectors xx,1024
tracks xx #= (Cylinders * Sides) = 80*2 = 160
sectrk xx #= Sectors 5,xxx
blocksize xxxx #= (128*(BLM+1)) = 2048
maxdir xxx #= (DRM+1) = 256
skew x #= may be 1 thru 6, or so
boottrk x #= OFS = 2
os x.x #= 2.2, or 2, or 3
end

diskdef COM8 #= Compupro (Viasyn) 8/16 1,024 bytes/sector - SSDD 8"

#= MFM, HIGH DENSITY
seclen 1024 #= Sectors xx,1024
tracks 77 #= (Cylinders * Sides) = 77*1 = 77
sectrk 8 #= Sectors 8,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 128

datarate DD
fm NO

skew 3 #= may be 0 thru 6, or so
boottrk 2 #= OFS = 2
os 2.2 #= 2.2, or 2, or 3
end



diskdef COM9 #= Compupro (Viasyn) 8/16 1,024 bytes/sector - DSDD 8"
#= MFM, HIGH DENSITY, ORDER SIDES
#= ORDER SIDES specifies that first one side then the other is written/read
# before the cylinder number is advanced.
seclen 1024 #= Sectors xx,1024

tracks 154 #= (Cylinders * Sides) = 77*2 = 154

sectrk 8 #= Sectors 5,xxx

sides alt

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 256

datarate DD
fm NO

skew 3 #= may be 0 thru 6, or so
boottrk 4 #= OFS = 4
os 2.2 #= 2.2, or 2, or 3
end

This should work fine.

Good Luck.


Larry

[ldkr...@gmail.com]

Jeff,
I used some EU Definitions to compare to 22DISK definitions, along with the
latest cpmtools definition file, and .libdskrc, which I have been updating.

My version of cpmtools that I've been using is 2.18, but I've got the version 1.20 downloaded. I've also sent Michael & John (libdsk) emails with some updated
CP/M definitions.


Larry

[Jeff Albrecht]

On Sunday, April 12, 2015 at 12:23:03 PM UTC-7, retrogear wrote:
> > I wonder if you used the same input source that I used? I ran cpmls against the >kaypro1.dsk file I created with imd2raw.exe from kaypro1.img in the Kaypro II >System Disks here http://www.classiccmp.org/dunfield/img54306/system.htm
>
> Yes it's the kaypro II system disks link (kayproii.zip) then kaypro1.imd in that zip. For some reason you're seeing half the files. I trust samdisk over other conversion utilities. I've had better results with it. Even converting teledisk .td0 is better than td02imd. Simon Owen's last update was just a month ago.
>

Larry,

I duplicated your results exactly using the imd and samdisk route.

I'm running FreeDos in Oracles virtual box. Sure would be nice to just wrap the imd utilities somehow so as not to need the vm. What virtualization are you using?

My imd is a couple versions older than yours. Where might I download the latest copy?

Wonder if I should file a bug on TBxxx's github for imd2raw.

[retrogear]

> Larry,
>
> I duplicated your results exactly using the imd and samdisk route.
>
> I'm running FreeDos in Oracles virtual box. Sure would be nice to just wrap the imd utilities somehow so as not to need the vm. What virtualization are you using?

No virtualization, just Windows XP command window.

>
> My imd is a couple versions older than yours. Where might I download the >latest copy?

http://www.classiccmp.org/dunfield/img/index.htm
I see I'm using 1.17 but there is a 1.18. I forget why I stuck with 1.17
but I think there was a reason...

Larry G

[ldkr...@gmail.com]

Jeff,
I've downloaded the latest IMD from Dave Dunfields site at:
http://www.classiccmp.org/dunfield/img/index.htm

I've been playing with cpmtools ver 2.18 and corresponding via email with Michael & John to get all the Radio Shack TRS-80 - Montezuma Micro CP/M Disk,
NEWDOS 80, and TRSDOS Ver 1.3 Definitions in:
1. The latest 22DISK by Chuck(G) (Registered Ver 1.45)
2. cpmtools >= Ver 2.18
3. libdsk >= 1.3.3

I'm basically playing with a Kryoflux and SuperCard Pro doing Preservation of
old TRS-80 Model 1, 3, & 4 (TRSDOS, NEWDOS, MONTEZUMA MICRO), Kaypro II, Ampro Little Board, and CP/M Big Board Files (PFM on Al's Site).

I'm really not into virtualization, but rather Emulation of the CP/M Systems in Debian trying to save old CP/M system and data floppy's before they self destruct, with no backup. Therefore the need for cpmtools & libdsk to access
the images with Linux.


Larry

[Tom Burnett]

Re: a bug report
Al Kossow has posted on the related thread here in comp.os.cpm that imd2raw is not 100% reliable. I had great luck in extracting many (> 75) disk images from Dave Dunfield's site and all existing diskdefs entries I tried worked fine and I worked out a dozen or so more and they worked find. Apparently, imd2raw can have difficulty with mixed density tracks and other unusual diskettes. See the other thread (Bill Cunningham) for his post. I'm no expert at low level floppy details and I simply converted Al's program to run anywhere instead of just Unix/Linux (it used stdin to stdout and that's not binary in Windows).

Also, at least for Windows, there is an alternative you might like better. Google "takeda msdos" and very close to the first return (it is the first just now) is his site to download an MSDOS emulation program. BUT, no vm. It runs msdos programs transparently using the Windows file system. So you just put "msdos" before any 16 bit command e.g. "msdos imdu /b <args>" and it works. I've ran C compilers, assemblers, linkers, etc. using this program and it's reliable. His latest version will even run gwbasic.

Source code is provided. This guy is well beyond good.

You might want to try this (for Windows only). Maybe some floppy wizards can make imd2raw better. I dunno. Too bad we can't get Dave Dunfield to hack on it. ;-)

Tom

[Tom Burnett]

Oh... One more thing...
Note that a TRS-80 Model 1 disk is almost certain mixed density if it's anything other than the original TRSDOS. The Level II ROM looked for a disk controller and, if it found one, loaded sector 0 of track 0 into memory and transferred control to it. As the original disk was single density, track 0 had to be single density even on later DOSes (LDOS. Newdos, etc.) that were double density because the ROM code insisted on it. Newdos even has a specific pdrive for this type of disk.

That's exactly the problem diskettes Al Kossow says will have problems.

Tom

[Jeff Albrecht]

> Also, at least for Windows, there is an alternative you might like better. Google "takeda msdos" and very close to the first return (it is the first just now) is his site to download an MSDOS emulation program. BUT, no vm. It runs msdos programs transparently using the Windows file system. So you just put "msdos" before any 16 bit command e.g. "msdos imdu /b <args>" and it works. I've ran C compilers, assemblers, linkers, etc. using this program and it's reliable. His latest version will even run gwbasic.
>
> Source code is provided. This guy is well beyond good.
>
> You might want to try this (for Windows only). Maybe some floppy wizards can make imd2raw better. I dunno. Too bad we can't get Dave Dunfield to hack on it. ;-)

Yo Tom!

Sweet! Ran imdu with msdos takeda downloaded from: http://homepage3.nifty.com/takeda-toshiya/ How nice not to fire up the VM for this quick command. Thanks for the headsUp.

C:\Users\Jeff\OneDrive\Development\CPM\imd118>msdos imdu kaypro1.imd kaypro1u.imd /E
IMageDisk Utility 1.18 / Mar 07 2012

IMD 1.01: 3/08/2005 11:48:57
KAYPRO II
CP/M 2.2

0/0 250 kbps DD 10x512
40 tracks(40/0), 400 sectors (34 Compressed)

C:\Users\Jeff\OneDrive\Development\CPM\imd118>

[Tom Burnett]

You're welcome. I'm retired and have too much time on my hands and still know how to program. ;-) Not to mention time to spend on the Internet looking for stuff that interests me.

I'm really just trying to be helpful. I don't mean to send anyone chasing the proverbial wild goose.

Let's make imd2raw.c better and send it back to Al. Exactly what diskettes was it having problems with, where are they and I'll go get them and look at it. But that kind of expertise was never my long suit so no guarantees.

Tom

[ldkr...@gmail.com]

Here is my best guess of all the Compupro definitions for cpmtools. The skew may have to be adjusted accordingly. Other parameters may need a bit of adjustment
after trying an actual floppy or image file.


diskdef COM7 #= Compupro (Viasyn) 1,024 bytes/sector - DSDD 96 tpi 5.25"
#= MFM

seclen 1024 #= Sectors xx,1024

tracks 160 #= (Cylinders * Sides) = 80*2 = 160
sectrk 5 #= Sectors 5,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 256
datarate DD
fm NO

skew 2 #= may be 0 thru 6, or so

diskdef COMA #= Compupro (Viasyn) 512 bytes/sector - SSDD 8"
#= MFM, HIGH DENSITY
seclen 512 #= Sectors xx,512

tracks 77 #= (Cylinders * Sides) = 77*1 = 77

sectrk 15 #= Sectors 15,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 128
datarate DD
fm NO

skew 4 #= may be 0 thru 6, or so

boottrk 2 #= OFS = 2
os 2.2 #= 2.2, or 2, or 3
end

diskdef COMB #= Compupro (Viasyn) 256 bytes/sector - SSDD 8"
#= MFM, HIGH DENSITY
seclen 256 #= Sectors xx,256

tracks 77 #= (Cylinders * Sides) = 77*1 = 77

sectrk 26 #= Sectors 25,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 128
datarate DD
fm NO

skew 9 #= may be 0 thru 6, or so

boottrk 2 #= OFS = 2
os 2.2 #= 2.2, or 2, or 3
end

diskdef COMC #= Compupro (Viasyn) - DSSD 8"
#= FM, HIGH DENSITY

#= ORDER SIDES specifies that first one side then the other is written/read
# before the cylinder number is advanced.

seclen 128 #= Sectors xx,128

tracks 154 #= (Cylinders * Sides) = 77*2 = 154

sectrk 26 #= Sectors 26,xxx
sides alt
blocksize 1024 #= (128*(BLM+1)) = 1024

maxdir 128 #= (DRM+1) = 128

datarate SD
fm YES
skew 6 #= may be 0 thru 6, or so

boottrk 4 #= OFS = 4
os 2.2 #= 2.2, or 2, or 3
end

diskdef COMD #= Compupro (Viasyn) 512 bytes/sector - DSHD 8"
#= MFM, HIGH DENSITY

#= ORDER SIDES specifies that first one side then the other is written/read
# before the cylinder number is advanced.

seclen 512 #= Sectors xx,512

tracks 154 #= (Cylinders * Sides) = 77*2 = 154

sectrk 15 #= Sectors 15,xxx

sides alt
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 256

datarate HD
fm NO
skew 4 #= may be 0 thru 6, or so

boottrk 4 #= OFS = 4
os 2.2 #= 2.2, or 2, or 3
end

diskdef COME #= Compupro (Viasyn) 256 bytes/sector - DSHD 8"
#= MFM, HIGH DENSITY
seclen 256 #= Sectors xx,256

tracks 154 #= (Cylinders * Sides) = 77*2 = 154

sectrk 26 #= Sectors 26,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 256

datarate HD
fm NO
skew 9 #= may be 0 thru 6, or so

boottrk 4 #= OFS = 4
os 2.2 #= 2.2, or 2, or 3
end

Larry

[Tom Burnett]

Cool. They have been added to my diskdefs file. FWIW, I find it useful to include comments at the top the total size of the expected image file. Then when you get a "cromemco" or "kaypro" or whatever disk image that can show up in some slightly different format as the hardware evolved over time, you know which one it is without having to experiment.

Here is one of mine that is in diskdefs and posted to comp.os.cpm some time ago:
# Morrow Decision SSDD 8"
# Entry derived from IMDU conversion to raw sectors
# 1st track is SSSD 128*26, hence the offset
# image size - 625,920
# image downloaded from bitsavers
# Test OK
diskdef morssdd8
seclen 1024
tracks 77
sectrk 8
blocksize 2048
maxdir 128
skew 3
boottrk 1
offset 3328
os 2.2
end

When you an image with that oddball size, you'll know what it is.

Tom

[ldkr...@gmail.com]

Here are some other cpmtools definitions that I have been using. The TRS-80
(Montezuma Micro Ver 2.31) definitions for a 96TPI drive weren't tested since
I don't have a 96 TPI Drive.


diskdef a1 #= Generic CP/M - SSSD 8"
#= DENSITY FM, HIGH

seclen 128 #= Sectors xx,128

tracks 77 #= (Cylinders * Sides) = 77*1 = 77

sectrk 26 #= Sectors 26,xxx

blocksize 1024 #= (128*(BLM+1)) = 1024

maxdir 64 #= (DRM+1) = 64
datarate SD
fm YES
skew 6 # may be 1, not sure = SKEW 2 = 2

boottrk 2 #= OFS = 2
os 2.2

end

diskdef acn1 #= Acorn CP/M on Acorn Z80 second processor.
#= DENSITY FM, LOW

seclen 256 #= Sectors xx,256

tracks 160 #= (Cylinders * Sides) = 80*2 = 160

# sides outback #= Order of Cylinders
sides alt #= Order of Cylinders
sectrk 10 #= Sectors 10,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 128

# skewtab 0,1,4,5,8,9,2,3,6,7
datarate DD #= LOW Density
FM YES #= FM Format
# secbase 0
# skew 0 #= may be 0 thru 6, or so... try 3 & 0
boottrk 3 #= OFS = 3
os 2.2
end

diskdef acn2 #= Acorn CP/M on Acorn Z80 second processor (Alternate).
#= DENSITY FM, LOW

seclen 256 #= Sectors xx,256

tracks 160 #= (Cylinders * Sides) = 80*2 = 160

sides outback #= Order of Cylinders
# sides alt #= Order of Cylinders
sectrk 10 #= Sectors 10,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 128

skewtab 0,1,4,5,8,9,2,3,6,7,0,1,4,5,8,9,2,3,6,7
datarate DD #= LOW Density
FM YES #= FM Format
secbase 0
# skew 0
boottrk 3 #= OFS = 3
os 2.2
end

diskdef acn3 #= Sloger DDCPM on Acorn Z80 second processor.
#= DENSITY MFM, LOW

seclen 512 #= Sectors xx,512

tracks 160 #= (Cylinders * Sides) = 80*2 = 160

sides outback #= Order of Cylinders
# sides alt #= Order of Cylinders
sectrk 10 #= Sectors 10,xxx
blocksize 4096 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 128
skewtab 0,0,2,2,4,4,6,6,8,8,1,1,3,3,5,5,7,7,9,9
datarate DD #= LOW Density
FM NO #= FM Format
# secbase 0
# skew 1
boottrk 3 #= OFS = 3
os 2.2
end

diskdef acn4 #= Sloger DDCPM on Acorn Z80 second processor (alternate).
#= DENSITY MFM, LOW

seclen 512 #= Sectors xx,512

tracks 160 #= (Cylinders * Sides) = 80*2 = 160

# sides outback #= Order of Cylinders
sides alt #= Order of Cylinders
sectrk 10 #= Sectors 10,xxx
blocksize 4096 #= (128*(BLM+1)) = 2048
maxdir 256 #= (DRM+1) = 128
# skewtab 0,2,4,6,8,1,3,5,7,9
datarate DD #= LOW Density
FM NO #= FM Format
# secbase 0
skew 0 #= may be 0 thru 6, or so... try 3 & 0
boottrk 3 #= OFS = 3
os 2.2
end

diskdef big1 #= Big Board (512 bytes/sector) - SSDD 8"
#= DENSITY MFM, HIGH

seclen 512 #= Sectors xx,512
tracks 77 #= (Cylinders * Sides) = 77*1 = 77
sectrk 15 #= Sectors 15,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048

maxdir 128 #= (DRM+1) = 64
datarate DD
fm NO
skew 0 # may be 1, not sure = SKEW 2 = 2

boottrk 2 #= OFS = 2
os 2.2

end

diskdef big2 #= Big Board (512 bytes/sector) - DSDD 8"
#= DENSITY MFM, HIGH

seclen 512 #= Sectors xx,512
tracks 154 #= (Cylinders * Sides) = 77*2 = 154

sides outback

sectrk 15 #= Sectors 15,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048

maxdir 128 #= (DRM+1) = 64
datarate DD
fm NO
skew 0 # may be 1, not sure = SKEW 2 = 2
boottrk 1 #= OFS = 2
os 2.2
end

diskdef big3 #= Big Board 1024 bytes/sector - SSDD 8"
#= DENSITY MFM, HIGH

seclen 1024 #= Sectors xx,1024
tracks 77 #= (Cylinders * Sides) = 77*1 = 77

sectrk 9 #= Sectors 9,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048

maxdir 128 #= (DRM+1) = 64
datarate DD
fm NO
skew 0 # may be 1, not sure = SKEW 2 = 2

boottrk 2 #= OFS = 2
os 2.2

end

diskdef big4 #= Big Board SWP 1024 bytes/sector - SSDD 8"
#= DENSITY MFM, HIGH
seclen 1024 #= Sectors xx, 1024

tracks 77 #= (Cylinders * Sides) = 77*1 = 77

sectrk 9 #= Sectors 9,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048

maxdir 128 #= (DRM+1) = 64
datarate DD
fm NO
secbase 18
skew 0 # may be 1, not sure = SKEW 2 = 2

boottrk 2 #= OFS = 2
os 2.2

end

#Radio Shack Model 4 running Montezuma Micro Ver 2.31 CP/M
diskdef trsg #= TRS-80 Model 4,4P Montezuma System 170K - SSDD 48 tpi 5.25"
#= DENSITY MFM, LOW
seclen 256
tracks 40
sectrk 18
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsh #= TRS-80 Model 4,4P Montezuma Data 200K - SSDD 48 tpi 5.25"
#= DENSITY MFM, LOW

seclen 512
tracks 40
sectrk 10

blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trsi #= TRS-80 Model 4,4P Montezuma System 350K - DSDD 48 tpi 5.25"
#= DENSITY MFM, LOW
seclen 256
tracks 80
sides outout
sectrk 18
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsj #= TRS-80 Model 4,4P Montezuma Data 400K - DSDD 48 tpi 5.25"
#= DENSITY MFM, LOW
seclen 512
tracks 80
sides outout
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trsk #= TRS-80 Model 4,4P Montezuma System 350K - SSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 256
tracks 80
sectrk 18
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsl #= TRS-80 Model 4,4P Montezuma Data 400K - SSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trsm #= TRS-80 Model 4,4P Montezuma System 710K - DSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 256
tracks 160
sides alt
sectrk 18
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsn #= TRS-80 Model 4,4P Montezuma Data 800K - DSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 512
tracks 160
sides alt
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trso #= TRS-80 Model 4,4P Montezuma Extend System 190K - SSDD 48 tpi 5.25"
#= DENSITY MFM, LOW

seclen 512
tracks 40
sectrk 10

blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsp #= TRS-80 Model 4,4P Montezuma Extend System 390K - SSDD 48 tpi 5.25"
#= DENSITY MFM, LOW
seclen 512
tracks 80
sides alt
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsq #= TRS-80 Model 4,4P Montezuma Extend System 390K - SSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trsr #= TRS-80 Model 4,4P Montezuma Extend System 790K - DSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 512
tracks 160
sides alt
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 2
os 2.2
end

diskdef trss #= TRSS TRS-80 Model 4,4P Montezuma Super Data 220K - SSDD 48 tpi 5.25"
#= DENSITY MFM, LOW
seclen 1024
tracks 40
sectrk 6
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trst #= TRS-80 Model 4,4P Montezuma Super Data 440K - DSDD 48 tpi 5.25"
#= DENSITY MFM, LOW
seclen 1024
tracks 80
sides outout
sectrk 6
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trsu #= TRS-80 Model 4,4P Montezuma Super Data 440K - SSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 1024
tracks 80
sectrk 6
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trsv #= TRS-80 Model 4,4P Montezuma Super Data 880K - DSDD 96 tpi 5.25"
#= DENSITY MFM, LOW
seclen 1024
tracks 160
sides alt
sectrk 6
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end

diskdef trsw #= TRS-80 Model 4,4P Montezuma System 400K - SSDD 96 tpi 3.5"
#= DENSITY MFM, LOW
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 128
datarate DD
fm NO
skew 2
boottrk 0
os 2.2
end


Larry

[Tom Burnett]

Great. And I'm an ex-TRS80 person.

Thank you. Thee sure save a lot of time. Not even to mention the hair-pulling until it's right.

Tom

[ldkr...@gmail.com]

Here are my Ampro Little Board Z80 CP/M 2.21 Definitions for cpmtools
Once again I don't have a 96 TPI 5.25" Floppy so these are not verified.

diskdef amp1 #= Ampro Little Board Z80 running CP/M 2.21 - SSDD 48 TPI 5.25"
#= DENSITY MFM, LOW
seclen 512 #= Sectors xx,512
tracks 40 #= (Cylinders * Sides) = 40*1 = 40

sectrk 10 #= Sectors 10,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048

maxdir 64 #= (DRM+1) = 64

skew 0 #= SKEW 0

boottrk 2 #= OFS = 2
os 2.2
end

diskdef amp2 #= Ampro Little Board Z80 running CP/M 2.21 - DSDD 48 TPI 5.25"

#= DENSITY MFM, LOW
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 128

skew 0

boottrk 2
os 2.2
end

# Test OK - image size = 409,600, from Don Maslin's archive
diskdef ampdsdd #= Ampro Little Board Z80 running CP/M 2.21 - DSDD 48 TPI 5.25" - 512 x 10

#= DENSITY MFM ,LOW
seclen 512

tracks 80
sectrk 10
blocksize 2048
maxdir 128

skew 0
boottrk 2
os 2.2
libdsk:format ampro400d
end

diskdef amp3 #= Ampro Little Board Z80 running CP/M 2.21 - SSDD 96 TPI 5.25"

seclen 512
tracks 80
sectrk 10
blocksize 2048

maxdir 64
skew 0

boottrk 2
os 2.2
end

diskdef amp4 #= Ampro Little Board Z80 running CP/M 2.21 - DSDD 96 TPI 5.25"

seclen 512
tracks 160

sectrk 10
blocksize 2048
maxdir 128

skew 0

boottrk 2
os 2.2
end

# Test OK - image size = 819,200, from Don Maslin's archive
diskdef ampdsdd80 #= Ampro Little Board Z80 running CP/M 2.21 - DSDD 96 TPI 5.25" - 512 x 10
seclen 512
tracks 160

sectrk 10
blocksize 2048
maxdir 128

skew 0
boottrk 2
os 2.2
libdsk:format ampro800
end

diskdef amp5 #= Ampro Little Board Z80 running CP/M 2.21 - SSDD 96 TPI 3.5"
#= DENSITY MFM, LOW
seclen 1024
tracks 80
sectrk 5
blocksize 2048
maxdir 128
skew 0

boottrk 2
os 2.2
end

diskdef amp6 #= Ampro Little Board Z80 running CP/M 2.21 - DSDD 96 TPI 3.5"
#= DENSITY MFM, LOW
seclen 1024
tracks 160
sectrk 5
blocksize 2048
maxdir 256
skew 0

boottrk 2
os 2.2
end

Larry

[Steven Hirsch]

On 04/16/2015 10:43 AM, ldkr...@gmail.com wrote:
> Here are my Ampro Little Board Z80 CP/M 2.21 Definitions for cpmtools
> Once again I don't have a 96 TPI 5.25" Floppy so these are not verified.

I wish someone would setup a website or repository for third-party and/or
untested defs that Michael is not prepared to include in the distribution.

I try to grab these as they appear in forums and newsgroups and throw them in
a directory, but it's not an optimal solution.

[David Schmidt]

He has been very accommodating when they're brought to his attention.
But it would be especially nice to get the current ones documented to
the excellent level of detail such as we've seen here lately - that
would be a nice collaborative effort to set up.

[Tom Burnett]

I sent Michael email a couple of days ago to the effect that there were multiple new diskdefs being posted in comp.os.cpm and so he might want to check it out. That's about all we can do I think. I'm pretty sure he'll include them. That I know of, all diskdefs posted here in (at least) the recent past are in cpmtools including the ones I've posted.

Anyone know of any Michael has not been willing to include? If so, then a repository is a good idea.

Tom

[Tom Burnett]

> I sent Michael email a couple of days ago to the effect that there were multiple new diskdefs being posted in comp.os.cpm and so he might want to check it out. That's about all we can do I think. I'm pretty sure he'll include them. That I know of, all diskdefs posted here in (at least) the recent past are in cpmtools including the ones I've posted.
>
> Anyone know of any Michael has not been willing to include? If so, then a repository is a good idea.
>
> Tom

Michael has asked me for a patch with all the new diskdefs posted here against a new 2.21 beta. I'll get that to him in the next day or so.

They should all be in the next release. Michael says to send him email with a new diskdefs when they are available as he does not follow comp.os.cpm consistently.

Tom

[Tom Burnett]

Patchfile is delivered to Michael.

The three posts from Larry are a very large percentage of the current diskdefs database. Let's make cpmtools work on everything!

03/16/2015 10:06 AM 25,869 diskdefs
04/19/2015 09:07 AM 14,452 adds
04/19/2015 09:09 AM 41,658 patchfile

Thanks Larry,
Tom

[Tom Burnett]

Larry,

Did you modify cpmtools for a new keyword "datarate" in diskdefs?

Tom

[ldkr...@gmail.com]

Tom,
No I didn't modify anything in cpmtools. In fact I'm still running Version 2.18
in Linux (Debian 7.x (64 Bit)) compiled with libdsk.

I'm not 100% sure the Zorba definitions I've got work correctly, because I've been trying to access three .TD0 files to try and extract some files. I can get a valid Directory listing of them, but I have trouble extracting .SRC or .DOC files, such that the data in the files is 100% correct.

These are not 100%, and if anyone has suggestions I'd appreciate any suggestions.
I've been testing with compat32.TD0, zrba-cpm.TD0, and mite30.TD0.

diskdef zor1

seclen 512 #= Sectors xx,512

tracks 80 #= (Cylinders * Sides) = 40*2 = 80
sides alt #= added

sectrk 10 #= Sectors 10,xxx
blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 64 #= (DRM+1) = 64

datarate DD #= LOW Density
FM NO #= FM Format

skew 0 #= was SKEW 2

boottrk 2 #= OFS = 2
os 2.2
end

diskdef zor2

seclen 512 #= Sectors xx,512

tracks 160 #= (Cylinders * Sides) = 80*1 = 160

sectrk 10 #= Sectors 10,xxx

sides alt #= added
blocksize 4096 #= (128*(BLM+1)) = 2048
maxdir 128 #= (DRM+1) = 64
skew 0 #= was SKEW 2

boottrk 2 #= OFS = 2
os 2.2
end

diskdef zqq

seclen 512 #= Sectors xx,512

tracks 80 #= (Cylinders * Sides) = 40*2 = 80
sides alt #= added

sectrk 9 #= Sectors 9,xxx

blocksize 2048 #= (128*(BLM+1)) = 2048
maxdir 64 #= (DRM+1) = 64

datarate DD #= Double Density

skew 0 #= SKEW 0
boottrk 2 #= OFS = 2
os 2.2
end

Thanks.

Larry

[Tom Burnett]

The reason I ask about "datarate" is Michael is asking if it's a non-standard extension. And, of course, I have no idea.

Tom

[Tom Burnett]

On Sunday, April 19, 2015 at 1:55:05 PM UTC-7, ldkr...@gmail.com wrote:

About the zorba definitions: Did you convert them to raw sectors? You might have less trouble if you separated the tasks of uncompressing the td0 files from the file extraction/directory.

Takeda's msdos program (google: "takeda msdos" will do it along with Dave Dunfield's utility. I modify this script as needed:

rem sample bat for converting td0 to dsk
rem td02imd.com and imdu.com must be in local directory
rem 1st, convert td0 to imd
msdos td02imd lcpm22.td0
msdos td02imd lcpm22.td0
msdos td02imd lcpm22.td0
msdos td02imd lcpm22.td0
rem 2nd, convert imd to dsk
msdos imdu /b lcpm22.imd lcpm22.dsk
msdos imdu /b lcpm30a.imd lcpm30a.dsk
msdos imdu /b lcpm30b.imd lcpm30b.dsk
msdos imdu /b lcpm30c.imd lcpm30c.dsk
rem done!

Then see if your definitions work on the *.dsk files.

Just a suggestion,
Tom

[ldkr...@gmail.com]

Tom,
Thanks for the tip. That was the problem.............an undocumented anomaly
in the way cpmtools & libdsk handle a .TD0 file. My definition was correct as
could read the .FOR and .SRC files.

I'm going to write up the steps I went through to get the conversion and access of the files.

Larry

[Tom Burnett]

You're welcome. You might want to email John Elliot (libdsk is his-email address is on his website) with the issues you are having on td0 files documented is as much detail as you can. Ideally, he can find it and fix it.

I've thought about putting direct *.IMD support in cpmtools - at least for the Windows version. Maybe JV3 and DMK from the TRS-80 world also (lots of CP/M images for the Model 4 in those formats), but about all I can think of to do is simply read the images into memory and then read data from there as if it were a disk image. Is that worth doing? I dunno.

It would be a bear to do all the seeks when everything is not easily calculated based on sector size and then seek wherever you need to read/write. If the image is in memory, it would just work with arithmetic on a pointer transparent to the user. Is that really IMD, JV3 or DMK support? Again, I dunno. But I think it would work for purposes of getting directory listings and copying files off of the disk. Copying onto the disk is a lot more complicated, so maybe just R/O support?

Tom

[ldkr...@gmail.com]

Tom & fellow CP/M users:
I've finished my guide (PART #7) of a larger [HOWTO] on the Kyroflux Forum.
[url]http://forum.kryoflux.com/viewtopic.php?f=3&t=853&p=8580#p8580[/url]

Part #7 deals with the creation, and use of CP/M Floppy Definitions to access
.DSK and .TD0 Images with cpmtools (built with libdsk). (I probably should
update cpmtools to the latest version and re-test to see if the problem still
exists.)

I'll email Michael & John tomorrow as it's late, and I've been at this for a
long time.

Larry

[William Pechter]

In article <c8486809-ff21-4149...@googlegroups.com>,

There were also 80 track double sided 96tpi Zorba disks for the later ones.
I've got the box in my basement.

Let me know if I can help.


Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/

[ldkr...@gmail.com]

Bill,
If you have a Boot floppy available for the 96 TPI Drive, I'm wondering if you can download Imagedisk from Dave's site:
[url]http://www.classiccmp.org/dunfield/img/index.htm[/url]
and make an image .IMD of that floppy and email it to me @gmail.com

Thanks.

Larry

[John Elliott]

ldkr...@gmail.com wrote:
> Tom,
> Thanks for the tip. That was the problem.............an undocumented anomaly
> in the way cpmtools & libdsk handle a .TD0 file. My definition was correct as
> could read the .FOR and .SRC files.

The problem was that the disk image used the 'extended surface' sector
numbering system, which LibDsk didn't support. Consequently it couldn't
access any sectors on side 1.

I have uploaded libdsk-1.3.7, which does support this style of numbering.
It also includes support for IMD-format disc images; since this is new and
untested code, you may want to treat it with caution.

--
John Elliott

Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show

[ldkr...@gmail.com]

John,
THANKS! You always have the answer, or deliver it promptly.

Larry

[John Elliott]

John Elliott <j...@seasip.demon.co.uk> wrote:
> I have uploaded libdsk-1.3.7, which does support this style of numbering.
> It also includes support for IMD-format disc images; since this is new and
> untested code, you may want to treat it with caution.

I've now updated libdsk to 1.3.8, with a fix for the IMD geometry probe.

Since Vodafone appear to be trying to kill Demon Internet through a
mixture of indifference and incompetence, the URL to go to is
<http://www.seasip.info/Unix/LibDsk/>.

[Alan Laughton]

On 25/04/2015 5:04 AM, John Elliott wrote:
> John Elliott <j...@seasip.demon.co.uk> wrote:
>> I have uploaded libdsk-1.3.7, which does support this style of
>> numbering. It also includes support for IMD-format disc images;
>> since this is new and untested code, you may want to treat it with
>> caution.
>
> I've now updated libdsk to 1.3.8, with a fix for the IMD geometry
> probe.
>
> Since Vodafone appear to be trying to kill Demon Internet through a
> mixture of indifference and incompetence, the URL to go to is
> <http://www.seasip.info/Unix/LibDsk/>.
>

Thanks for the update, a friend has just patched it into ubee512 &
ubeedisk, a Microbee Emulator and support util. Also into a Microbee
Patched CPMTOOLS. Everything works great, can convert *.DSK to *.IMD
and vise-versa. Can boot IMD images and can copy files to and from the
image when booted in ubee512.

But (there is always a BUT), with CPMTOOLS, I can get a Directory of an
image with

cpmls -F -f ds80 -T imd test.imd

can extract all files to a folder called "files" from the image with

cpmcp -f ds80 -T imd test.imd 0:*.* files

but I cant seam to copy files to the image with

cpmcp -f ds80 -T imd test.imd files\*.* 0:

Am I doing something wrong ? Have replaced files\*.* with files\* and
g:\files\* and g:\files\*.* with same negative results.

Alan

[Udo Munk]

On Saturday, April 25, 2015 at 4:44:53 PM UTC+2, Alan Laughton wrote:

> but I cant seam to copy files to the image with
>
> cpmcp -f ds80 -T imd test.imd files\*.* 0:
>
> Am I doing something wrong ? Have replaced files\*.* with files\* and
> g:\files\* and g:\files\*.* with same negative results.

Compressed image perhaps? Difficult to rewrite sectors in a compressed image
and probably not implemented.

[Alan Laughton]

The patched cpmtools/ubee512/ubeedisk author found the problem and
believes it is a cpmtools bug that has gone unnoticed. Doing a grep
Device_close *.c showed that function never gets called from anywhere
and so does not flush the buffer that the IMD driver would be using.
Seems that DSK and RAW images were being flushed by other means. The
Microbee patched cpmtools is based on 2.10 but the same problem appears
to be in the latest current release of 2.20.

In cpmcp.c I added the following two lines of code above the
exit(exitcode) which is at end of main()

if (&super.dev)
Device_close(&super.dev);

exit(exitcode);