• Please review our updated Terms and Rules here

Questions about the Kaypro emulator format.jar program

The Mad Turk

Member
Joined
Apr 5, 2022
Messages
10
Location
Seattle
I have been unable to figure out how to use the format.jar program for the Kaypro simulator. Is it possible to see a real-world example of a format command? For instance, I would like to create a standard 5.25" DSDD from a TR0 file. What I think is really hanging me up is the actual syntax of the format-options part of the command line, though I've not gotten anything to work so far.

In addition, are the .logdisk image files compatible with any other image format, or can they be converted from/to other formats?
 
If you invoke format.jar without any commandline options, it will print "help" information, albeit terse. (I created a shell script named "format" that invokes the "java -jar format.jar ..." command, just for ease of use). The help output is:
Code:
Usage: format [options] <file> [format-options]
       format show [options] [format-options]
       format list
Options:
    files=d  = preload image with files from directory 'd'
    h8d=file = preload image from H8D image
    imd=file = preload image from IMD image
    td0=file = preload image from TD0 image
    nores    = Do not reserve hidden blocks (breaks cpmtools)
    list     = List all known formats
    show     = Show geometry(s) (do not format)
Format-Options:
    5 | 8
    DD | SD
    DS | SS
    DT | ST
    MMS | Z17 | M47 | Z37 | Z47 | Z67 | Z37X | Z47X | Kaypro | HiDens

Basically, the "<file>" parameter is the output image file name, to be created. format refuses to overwrite that file if it already exists. "[options]", if any, must precede the image file name. "[format-options]" must follow. Here is what I use to create a blank Kaypro 400K image:

Code:
java -jar format.jar kp4blank Kaypro 5 DD DS

This creates the file "kp4blank.logdisk" which is a blank Kaypro 400K floppy image.

The "files=d" option may be used to populate the new image with files from your computer. "d" is a directory/path. For example, "files=/some/path/to/cpm/files". All files in that directory will be loaded onto the new image.

The "h8d=file" option is really for Heathkit systems, but if the "file" is the same size as the raw capacity of the image, it will be loaded as-is over the new image.

I've had pretty good success using the "imd=file", although some IMD files out there have issues (like extra tracks beyond the end of the disk).

I've not had much success with the "td0=file" option as most TD0 images I come across are compressed, and the compression algorithm is considered proprietary. I have been able to use a utility to convert TD0 compressed to raw, but I don't recall exactly what util now.

As for as "compatibility" of logdisk images, the first N blocks (N = capacity of diskette) of the file are the diskette image, and you can use cpmtools directly on them (provided you have the diskdefs). I use a modified cpmtools that examines the logdisk data and automatically generates the diskdef. I also have the 'raw2imd' program that can work on logdisk images.
 
Thank you, Doug! That helps immensely. I see now that I wasn't understanding how to place the values in the format-options portion of the command line.
 
OK, I've gave Doug a day off, now I have more questions about format.jar and, by extension, CP/Net.

First, if it's important, I'm running the Kaypro emulator under the Zulu Java JRE (most recent version, I think) on MacOS Monterey, M1 MacBook Air, on a APFS-formatted SSD. I don't know if file system makes a difference, but it might after you hear my question.

I was able to take the information from the last response and create a disk image. I also tried to make one with the same parameters containing the contents of a folder. The disk was created and is readable, but there is no sign of the files, though the command reflected that the nine files in the folder were copied to the new disk.

Similarly, when I open the CP/Net folder structure (created during my previous round of messages), I can copy files to the folders in my host directory, but no files that exist there previously are present when I do a dir. When I look from the Mac, the original files and the files copied are in the folder, but I can't find the original files from within CP/M. Also, when I do a dir on that folder from inside CP/M, I get the message "system file(s) exist," though I haven't tried to make these folders bootable (that wouldn't even work, would it?). This message occurs with every folder on the network filesystem.
 
This one is easy to answer. A special hidden "feature" is that files on the host system are examined to see if the are read-only ("R/O", have no write permissions) or are system ("SYS", have execute permissions). This holds for CP/NET servers as well as format.jar. So, I suspect the files you used in the "files=d" option have their execute permissions set (even though they are not executable on the MAC). One unfortunate glitch is that Windows shows all files as "executable", and so there is a special option for CP/NET servers to deal with this. For format.jar, you'll need to remove execute permissions on the files before creating the image. As an alternative, you should be able to do a "STAT B:*.*[DIR]" under CP/M to change the file attributes (where "B:" is whatever drive these files are on). I should add an option to format.jar to do the same thing as we do on CP/NET for Windows, but that is not there yet.
 
If you still need this, then the IMD software will allow the conversion from a TD0 to a RAW image. But, it's a two step process.

First use one of the utilities to convert the TD0 into an IMD image.

Second, one of the standard IMD utilities has an option to display the image, and send the display to a new file. This file will be a Binary (i.e. RAW) file.

All fairly easy, just that it's two steps.

Geoff
 
If you have libdsk by John Elliott installed, you can use dsktrans to do the conversion for
the following floppy formats.

Code:
$ dsktrans -formats
Disk formats supported:

   pcw180     : PCW / IBM 180k
   cpcsys     : CPC System
   cpcdata    : CPC Data
   pcw720     : PCW / IBM 720k
   pcw1440    : PcW16 / IBM 1440k 
   ibm160     : IBM 160k (CP/M-86 / DOSPLUS)
   ibm320     : IBM 320k (CP/M-86 / DOSPLUS)
   ibm360     : IBM 360k (CP/M-86 / DOSPLUS)
   ibm720     : IBM 720k (144FEAT)
   ibm1200    : IBM 1.2M (144FEAT)
   ibm1440    : IBM 1.4M (144FEAT)
   acorn160   : Acorn 160k
   acorn320   : Acorn 320k
   acorn640   : Acorn 640k
   acorn800   : Acorn 800k
   acorn1600  : Acorn 1600k
   pcw800     : PCW 800k
   pcw200     : PCW 200k
   bbc100     : BBC 100k
   bbc200     : BBC 200k
   mbee400    : Microbee 400k
   mgt800     : MGT 800k
   trdos640   : TR-DOS 640k
   ampro200   : Ampro 40 track single-sided
   ampro400d  : Ampro 40 track double-sided
   ampro400s  : Ampro 80 track single-sided
   ampro800   : Ampro 80 track double-sided
   pcw1200    : PcW16 / IBM 1200k 
   .....
   .....
   .....
   trsg       : TRS-80 Model 4,4P Montezuma System 170K - SSDD 48 tpi 5.25"
   ampro800   : Ampro800 - DSDD 96 tpi 3.5"
   amp6       : Ampro - DSDD 96 tpi 3.5"
   amp5       : Ampro - SSDD 96 tpi 3.5"
   amp4       : Ampro - DSDD 96 tpi 5.25"
   amp3       : Ampro - SSDD 96 tpi 5.25"
   amp2       : Ampro - DSDD 48 tpi 5.25"
   amp1       : Ampro - SSDD 48 tpi 5.25"
   kay3       : KAY3  Kaypro 2X/4/10 (Alternate) - DSDD 48 tpi 5.25" - 512 x 10
   kay2       : KAY2  Kaypro 2X/4/10 - DSDD 48 tpi 5.25" - 512 x 10
   kpiv       : Kaypro 2X/4/10 - DSDD 48 tpi 5.25"
   kpii       : KAY1  Kaypro II/2 - SSDD 48 tpi 5.25" - 512 x 10
   kay1       : KAY1  Kaypro II/2 - SSDD 48 tpi 5.25" - 512 x 10
   fea2       : FEA2 IBM PC, CP/M-86 - 720 KB - DSDD 3.5" - 48 TPI - 512 x 9
   fea1       : FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18
   ibm3740    : IBM3740 SS SD 77T 8" 26x128 b/s

The various types are:
Code:
$ dsktrans -types
Disk image types supported:

   gotek      : Gotek 1440k disc image collection 
   gotek72    : Gotek 720k disc image collection 
   remote     : Remote LibDsk instance
   rcpmfs     : Reverse CP/MFS driver
   dsk        : CPCEMU .DSK driver
   edsk       : Extended .DSK driver
   apridisk   : APRIDISK file driver
   copyqm     : CopyQM file driver
   tele       : TeleDisk file driver
   ldbs       : LibDsk block store
   ldbst      : LDBS (text form)
   sap        : SAP file driver
   qrst       : Quick Release Sector Transfer
   imd        : IMD file driver
   ydsk       : YAZE YDSK driver
   raw        : Raw file driver (alternate sides) 
   rawoo      : Raw file driver (out and out) 
   rawob      : Raw file driver (out and back) 
   myz80      : MYZ80 hard drive driver
   simh       : SIMH disc image driver
   nanowasp   : NanoWasp image file driver
   logical    : Raw file logical sector order
   jv3        : JV3 file driver
   dc42       : Disk Copy 4.2
   cfi        : CFI file driver

The command then becomes:
Code:
dsktrans  [-itype  TYPE]  [-otype  TYPE]  [-iside  SIDE]  [-oside SIDE]
       [-icomp COMP] [-ocomp COMP] [-idstep] [-odstep] [-retry COUNT] [-format
       FMT]  [-first  CYLINDER]  [-last  CYLINDER]  [-comment  TEXT] [-comment
       @FILE] [-md3] [-logical] [-apricot]  [-pcdos]  [-noformat]  INPUT-IMAGE
       OUTPUT-IMAGE

Code:
 $ dsktrans -itype tele -otype raw -format amp2 inputimage.td0 outputimage.raw
 $ dsktrans -itype tele -otype rawob -format amp2 inputimage.td0 outputimage.raw
 $ dsktrans -itype tele -otype imd -format amp2 inputimage.td0 outputimage.imd
 $ dsktrans -itype copyqm -otype imd -format amp2 inputimage.copyqm outputimage.imd

All done in a single step.

Larry
 
This one is easy to answer. A special hidden "feature" is that files on the host system are examined to see if the are read-only ("R/O", have no write permissions) or are system ("SYS", have execute permissions). This holds for CP/NET servers as well as format.jar. So, I suspect the files you used in the "files=d" option have their execute permissions set (even though they are not executable on the MAC). One unfortunate glitch is that Windows shows all files as "executable", and so there is a special option for CP/NET servers to deal with this. For format.jar, you'll need to remove execute permissions on the files before creating the image. As an alternative, you should be able to do a "STAT B:*.*[DIR]" under CP/M to change the file attributes (where "B:" is whatever drive these files are on). I should add an option to format.jar to do the same thing as we do on CP/NET for Windows, but that is not there yet.

That worked perfectly...at least on the CP/Net files (haven't had time to try it with format yet). Since MacOS is Unix, I was able to use chmod to remove the executable flag and they showed right up in dir.
 
Back
Top