Here is the information for 720CPM86.ZIP (720CPM86.IMG) Peter suggested.

#22DISK Definition
BEGIN FEA2 IBM PC, CP/M-86 - 720 KB - DSDD 3.5" - 48 TPI - 512 x 9
DENSITY MFM LOW
CYLINDERS 80 SIDES 1 SECTORS 9 512
SIDE1 0 1,2,3,4,5,6,7,8,9
BSH 4 BLM 15 EXM 1 DSM 354 DRM 255 AL0 0C0h AL1 0 OFS 2
END

#cpmtools Definition
# FEA2 IBM PC, CP/M-86 - 720 KB - DSDD 3.5" - 48 TPI - 512 x 9
diskdef fea2
seclen 512
tracks 80
sectrk 9
blocksize 2048
maxdir 256
skew 1
boottrk 2
os 3
# libdsk:format ibm720
end

# libdsk Definition
[fea2]
description = FEA2 IBM PC, CP/M-86 - 720 KB - DSDD 3.5" - 48 TPI - 512 x 9
cylinders = 80
heads = 1
secsize = 512
sectors = 9
secbase = 1
datarate = DD

#Flashfloppy/GOTEK Definition
[fea2]
cyls = 80
heads = 1
secs = 9
interleave = 1
bps = 512
id = 1
#rpm = 360
rpm = 300
rate = 250
mode = mfm
iam = no

Create *.TD0 Image

$ dsktrans -itype copyqm -otype tele -format ibm720 720CPM86.IMG 720CPM86.TD0
Input driver: CopyQM file driver
Output driver:TeleDisk file driver

Create *.IMD Image

$ dsktrans -itype copyqm -otype imd -format ibm720 720CPM86.IMG 720CPM86.IMD
Input driver: CopyQM file driver
Output driver:IMD file driver

Create *.RAW Image (Sector Dump)

$ dsktrans -itype copyqm -otype raw -format ibm720 720CPM86.IMG 720CPM86.RAW
Input driver: CopyQM file driver
Output driver:Raw file driver (alternate sides)

Files in the RAW Image

$ cpmls -f fea2 -D 720CPM86.RAW
Name Bytes Recs Attr update create
------------ ------ ------ ---- ----------------- -----------------
144BLDR2.CMD 6K 37 R
86LOGO .CMD 2K 4
ASM86 .CMD 26K 205
ASSIGN .CMD 4K 29
AUTOEXEC.SUB 2K 1
CLS .CMD 2K 4
CONFIG .CMD 4K 21
CPM .SYS 18K 144
DATA .PFK 2K 3
DDT86 .CMD 14K 112
DSKMAINT.CMD 6K 34
ED .CMD 10K 74
FASTKEYS.CMD 2K 5
FUNCTION.CMD 2K 16
GENCMD .CMD 6K 45
GETATCLK.CMD 2K 6
HDMAINT .CMD 26K 196
HELP .CMD 8K 52
HELP .HLP 24K 183
NEWTOD .CMD 2K 10
NUMOFF .CMD 2K 4
PIP .CMD 8K 59
PRINT .CMD 6K 40
SETUP .CMD 8K 63
STAT .CMD 10K 73
SUBMIT .CMD 4K 31
26 Files occupying 206K, 496K Free.

Write Image to Floppy (/dev/fd0) using libdsk (in Debian Linux 11 - 64 Bit)

$ dsktrans -itype raw -otype floppy -format ibm720 720CPM86.RAW /dev/fd0

Larry

On Saturday, March 26, 2022 at 10:19:52 PM UTC, rob.r...@gmail.com wrote:
> Oh interesting, with the 144cpm86.raw image as the selected image, STAT A: DSK: reports:
>
> 1,420: Kilobyte Drive Capacity
>
> With the image I created using dd, mkfs.cpm and cpmcp, it reports:
>
> 156: Kilobyte Drive Capacity
>
> so something is very different between those two images.
>
> I wonder if mkfs.cpm isn't creating the proper directory?

mkfs.cpm is likely not populating the boot sector. If you examine it in a hex editor, the last byte (offset 01FFh) is used by CP/M-86 to determine the capacity. This should be one of:

00h: 160k
01h: 320k
0Ch: 1200k (144FEAT)
10h: 360k (PCP/M-86)
11h: 720k (PCP/M-86)
40h: 360k (PCP/M-86)
48h: 720k (144FEAT)
90h: 1440k (144FEAT)

--
John Elliott

Looking at 144CPM86.IMG (after unpacking it), I see something strange. There are two separate directory areas. I suspect one is a remnant of a previous use of the diskette, apparently using a smaller disk capacity (DPB). I am guessing the directory for the larger capacity is the current one, but can't be certain. Since the files are all binary, with the possible exception of HELP.HLP, it is probably not worthwhile trying to discern the skew from that.

Looking at the boot sector (first sector on disk), it appears that there is a data block after the initial JMP instruction. This data block includes a diskette label string, but I don't see data that resembles a DPB. There is also another 0x90 byte which may, or may not, be a duplicate format byte.

Note that Digital Research did not define how the boot tracks were used, so I suspect it is the BIOS vendor that defined any format data in this boot sector. Vendor documentation, or BIOS source code, would be the definitive answer to how to determine diskette format. I'm not really inclined to try and disassemble the BIOS myself, as I'm not fluent in i8086.

When we got the very first IBM PC at work, the manual for the machine included the complete BIOS source
listing. I remember that because I wrote some assembler and C software using BIOS calls instead of OS
calls, which was possible by studying the manual. Of course that listing was used by cloners like AMI to produce
a compatible BIOS for clone machines, so for later systems IBM did not provide the BIOS source anymore.
I think that manual likely is available somewhere.

Also be aware that "BIOS" has a subtly different meaning in the IBM-PC/DOS world than in CP/M. DOS formally placed the BIOS in the ROM, while in the CP/M world the BIOS was the portion of CP/M that implemented the interfaced to the specific platform. I don't believe that the IBM-PC "BIOS ROM" could be directly used as the CP/M-86 BIOS, so there had to be a "shim" (at least) to interface the CP/M-86 BIOS calls to the platform ROM "BIOS". I'm not sure what DOS defined as far as "format data" in the boot sector, but CP/M-86 was not restricted to running on DOS (IBM-PC compatible) platforms. As I recall, DOS does not use the exact same DPB format as CP/M so there needs to be some translation done there, but it is possible that the diskette format is being detected by the ROM BIOS and then the CP/M-86 BIOS is translating that into what the CP/M-86 BDOS needs.

The original post does say "PC", which I would assume means it is an IBM-PC - but that may be an incorrect assumption.

On Thursday, March 31, 2022 at 12:17:18 AM UTC+1, Douglas Miller wrote:
> Looking at the boot sector (first sector on disk), it appears that there is a data block after the initial JMP instruction. This data block includes a diskette label string, but I don't see data that resembles a DPB. There is also another 0x90 byte which may, or may not, be a duplicate format byte..

CP/M-86 v1.1 for the IBM PC only uses the last byte of the boot sector to determine the disk format. Anything in the preceding 511 bytes may have meaning to other operating systems, but from CP/M-86's point of view it can be ignored.

There's a disassembly of this version of CP/M-86 at <http://www.cpm.z80.de/source.html> (download CPMDEV.ZIP). The default format determination code is simply:

RESET_FLOPPY1:
MOV Word Ptr 0Ah[BX],Offset DPBK1
PUSH BX
MOV BX,Offset DSKBUF
DEC Byte Ptr 01FFh[BX]
POP BX
JNZ RESET_FLOPPY2
MOV Word Ptr 0Ah[BX],Offset DPBK2
; RESET_FLOPPY2:

This is presumably patched by 144FEAT to detect additional disk types and select the appropriate DPB.

--
John Elliott

Can't tell if that source came from DRI or a vendor, but the standard DRI reference BIOS code that is available does not perform any such a check. The CPMDEV.ZIP code (PCBIOS.A86) is looking for a boolean value in the last byte of the boot sector, and has no 1.44M DPB, so is not exactly matching what we're looking for here.

As far as being able to create compatible disks, it is probably necessary to duplicate the boot tracks of a "working" disk of the same format, and fill in the files you want. But if that is not working, it may be the sector skew and without source code for the BIOS, or digging into the DPH/DPB (through DDT or a program), it may come down to creating a disk on the actual PC that contains a large text file that can be easily re-ordered - a large HEX file or assembler listing would work - and then creating an image from that diskette and examining it to determine the skew.

There were many implementations of CP/M-86. For the IBM to my knowledge DRI only supported 160K and 360K for the original release.

That said all other PC type versions expanded from type 00 and type 1 to allow more diskette versions., the latest is a patched version that supports up to 1.44mb and was never from DRI.

Meaning everyone is correct.

Randy

On Thursday, March 31, 2022 at 7:44:40 PM UTC-5, Douglas Miller wrote:
> Can't tell if that source came from DRI or a vendor, but the standard DRI reference BIOS code that is available does not perform any such a check. The CPMDEV.ZIP code (PCBIOS.A86) is looking for a boolean value in the last byte of the boot sector, and has no 1.44M DPB, so is not exactly matching what we're looking for here.
>
> As far as being able to create compatible disks, it is probably necessary to duplicate the boot tracks of a "working" disk of the same format, and fill in the files you want. But if that is not working, it may be the sector skew and without source code for the BIOS, or digging into the DPH/DPB (through DDT or a program), it may come down to creating a disk on the actual PC that contains a large text file that can be easily re-ordered - a large HEX file or assembler listing would work - and then creating an image from that diskette and examining it to determine the skew.

Decided to take a little time to educate myself on this version of CP/M-86. Found this site https://www.z80cpu.eu/mirrors/klaw/files.htm, specifically the "144FEAT2.ZIP" download. Not sure what you're actually running, but there is some good information in the DOC files in the ZIP. One thing I see in 144PREP2.DOC is:

6. Standard CP/M-86, without the "1.44 MB feature" loaded, will "see" all
diskette types prepared by 144PREP2 as a 160 KB single-sided
diskette with all diskette space used by a file called CP/M-86.720 c.q.
CP/M-86.120 c.q. CP/M-86.144.
This will prevent a non-patched, standard CP/M-86 system from accidently
overwriting data on the new higher capacity diskette types.

This explains what I saw in the disk image - that "phantom" directory was actually this trick to prevent accidental corruption when being used on a system that had not been patched. I haven't thoroughly analyzed the patch being done here, and probably won't, but it still begs the question of what the original BIOS is doing as well - in addition to what changes after the patch. Since the 720K, 1.2M, and 1.44M formats are new, there might be clues if one could find the DPHs and DPBs being used there (DPH contains the skew table, if any).

There is also the file 144TECH2.DOC with valuable information.

On 25/03/22 02:03, David Schultz wrote:
> All you need to do is fill the directory sectors with 0xe5. I can't find
> a way to make dd do that.

perhaps creating a file containing some E5s, of appropriate power-of-two
lent (easy to create with a flexible enough hex editor) and using it as
input file (if=e5.bin) ?

Best regards from Italy,
dott. Piergiorgio.

On Thursday, March 31, 2022 at 6:58:00 AM UTC-5, Douglas Miller wrote:
> Also be aware that "BIOS" has a subtly different meaning in the IBM-PC/DOS world than in CP/M. DOS formally placed the BIOS in the ROM, while in the CP/M world the BIOS was the portion of CP/M that implemented the interfaced to the specific platform. I don't believe that the IBM-PC "BIOS ROM" could be directly used as the CP/M-86 BIOS, so there had to be a "shim" (at least) to interface the CP/M-86 BIOS calls to the platform ROM "BIOS". I'm not sure what DOS defined as far as "format data" in the boot sector, but CP/M-86 was not restricted to running on DOS (IBM-PC compatible) platforms. As I recall, DOS does not use the exact same DPB format as CP/M so there needs to be some translation done there, but it is possible that the diskette format is being detected by the ROM BIOS and then the CP/M-86 BIOS is translating that into what the CP/M-86 BDOS needs.
>
> The original post does say "PC", which I would assume means it is an IBM-PC - but that may be an incorrect assumption.

The IBM ROM BIOS is better referred as 'rom-bios'. It is mostly the INT services.
The cp/m Bios is the software buss interface to the hardware, sometimes known as the CBIOS, customized bios.
For CP/M-86 the cbios begins at offset 2500h, which has the jump table to all the services the cbios offers, including the low level hardware interfaces.
As an aside, a working cp/m-86 binary can be split there at the cbios jump table and a new cbios binary org'd for 2500h can 'paper-over' there as one
method of modifing cp/m-86 [1]. Also, the IBM versions load at segment 0051h whereas the non-IBM versions often use 0040h.
The CP/M-86 v. 1.0 for the IBM-PC was the first version offered, followed by CP/M-86 v. 1.1 for the IBM PC/XT which added hard disk support.
There is the EAGLE version of CP/M-86 on Gaby's site - the unofficial cpm site. It is IBM compatible as Eagle computers were an IBM clone. ( I
once had it running on a dell pentium laptop by using a 720k 3 1/2 floppy formatted as 360k media and installed the EAGLE version on it. So I know
the cbios was ibm compatible. After this time the OEMs began using 3 1/2 floppy drives whose controllers dropped support for 720k format, then floppy drives began to disappear. ) The Eagle software includes the source for the CBIOS in CPMBIOS.A86 so have a look there for the CBIOS to
RomBios usage. It uses INT 10h, 12h, 13h, 14h, 16h, 17h, of the IBM RomBios.

[1] AIR Freek didn't want to modify CP/M-86 until after load time where his driver does a 'hot' patch of cp/m-86.

The CP/M-86 media does not have a BPB structure on disk like pcDos does. It's method is use of a DPH & DPB structures held in the CBIOS.
The DPB.OFFSET field holds the offset in TRACKs to use to be at the beginning of the Disk Directory.
The only snippet of code I have on this system from those times (over 20 years ago) is this, from 2014 in nasm syntax..
Note: There is no sector skew on modern floppy drives.

fwiiw:

;;==================;; -=== D A T A ===-
;;==================;;------------------------------------------------------
;; Disk Structures DPH, DPB. Work Areas CSV, ALV.
;;------------------------------------------------------
;; CSV size is based on CKS size, CSVsz = CKS = (DRM+1)/4
;; ALV size is based on maxium blks, = (DSM/8)+1
; ; DISK PARAMETER HEADER
; FEAT_DPH DW 0 ;NO TRANSLATE TABLE (for sector skew)
DW 0 ;; cdrmaxa, DPH[2]
DW 0 ;; curtrka, DPH[4]
DW 0 ;; curreca, DPH[6]
DW DIRBUF ;DIRECTORY SCRATCH PAD
FEAT_DPB DW FEAT144 ;DPBK1
DW FEAT_CSV ;CHECK VECTOR 0
DW FEAT_ALV ;ALLOCATION VECTOR 0

;-----------------------------------------------------------
; PC DOUBLE SIDED - 1440k drive - Feat144.
; ; 512 BYTES PER SECTOR
; 18 SECTORS PER TRACK
; 160 TRACKS PER DRIVE, 80 per side
; DOUBLE DENSITY
;-----------------------------------------------------------
;; bls144 equ 4096 ;block size is 32 sectors of 128 bytes

FEAT144:
ISTRUC DPB_
at DPB_.CSPT, DW 72 ;LOGICAL 128byte SECTORS PER TRACK
at DPB_.CBSH, DB 5 ;BLOCK SHIFT FACTOR
at DPB_.CBLM, DB 31 ;BLOCK MASK VALUE
at DPB_.CEXM, DB 1 ;EXTENT MASK
at DPB_.CDSM, DW 354 ;DISK STORAGE ( IN BLOCKS - 1)
at DPB_.CDRM, DW 255 ;DIRECTORY ENTRIES ( -1 )
at DPB_.CAL0, DB 0C0h ;DIRECTORY ALLOCATION VECTOR 0
at DPB_.CAL1, DB 00h ;DIRECTORY ALLOCATION VECTOR 1
at DPB_.CCKS, DW 64 ;SIZE OF CHECK VECTOR
at DPB_.COFF, DW 2 ;SYSTEM OFFSET ** in Tracks **
featcsv equ 64 ;; (DRM+1)/4 =256/4 =64
featalv equ 45 ;; (DSM/8)+1 =(354/8)+1 = 44+1 = 45

; EAGLE EXTENSION
;; at DPB_.RMSK, DB 1 ;PHYSICAL TO LOGICAL SECTOR MASK VALUE
;; at DPB_.RLSHF, DB 1 ;PHYSICAL TO LOGICAL SECTOR SHIFT VALUE
;; at DPB_.RSDF, DB 1 ;LOGICAL TRACK TO HEAD/TRACK METHOD
;; at DPB_.RDSZ, DB 1 ;READ SIZE
;; at DPB_.RHWP, DW 1 ;POINTER TO HAREWARE PARAMETER TABLE
;; at DPB_.RXLT, DW 1 ;POINTER TO PHYSICAL SECTOR TRANSLATION
;; at DPB_.SID, DW 0090h ; = 144 Feat Boot Sector ID.
IEND
;; feat144..
FEAT_CSV TIMES featcsv DB 0 ;;CHECK VECTOR 1
FEAT_ALV TIMES featalv DB 0 ;;ALLOCATION VECTOR 1
;---------------------------------------------------------------------
; CONTROLLER PARAMETERS FOR PC DISKETTES
;---------------------------------------------------------------------
;; Diskette Parameter Table (DPT) for PC-ROM-BIOS Int 1Eh Vectors.
;;--------------------------------------------------------------------
;For 720 KB and 1.44 MB, 3.5 inch diskettes we will use a different DPT
;(source: MS-DOS 6.2):
;DF 02 25 02 12 1B FF 6C F6 0F 08.
PC_F144:
ISTRUC DPTbl_
at DPTbl_.Spec1, DB 0DFh ;"DISK_BASE" HARDWARD INFORMATION
at DPTbl_.Spec2, DB 2 ;SPEC BYTE 2, 02h, HeadLoad & nonDMA_Flg
at DPTbl_.MotD, DB 25 ;MOTOR OFF TIME
at DPTbl_.RSSHF, DB 2 ;SECTOR SIZE SHIFT FACTOR, 2 = 512 byte sectors
at DPTbl_.RSPT, DB 12 ;EOT - SPECTORS PER TRACK
at DPTbl_.GapL, DB 01Bh ;GPL - READ GAP LENGTH
at DPTbl_.DataL, DB 0FFh ;DTL - DATA LENGTH
at DPTbl_.GapF, DB 06Ch ;FORMAT GAP LENGTH
at DPTbl_.Fillr, DB 0F6h ;FILL BYTE FOR FORMAT
at DPTbl_.Settl, DB 0Fh ;SKIP FLAG / HEAD SETTLE TIME
at DPTbl_.MotS, DB 8 ;MOTOR START TIME ( IN 1/8THS'S)
; local info extention..
at DPTbl_.RTPS, DB 80 ;TRACKS PER "SIDE"
at DPTbl_.RHPD, DB 2 ;NUMBER OF HEADS
IEND
;---------------------------------------------------------------------
; E N D O F F E A T D R I V E R
;---------------------------------------------------------------------

AIR the DPTbl was slightly different from other IBM RomBios references I had, so double check these.
Note that early media used a format filler byte of E5h versus the later format filler byte of F6h. This
brings up a point~ early CP/M-80 saw the default E5h in the directory entry as 'this fcb spot is free' was
a change made when the default filler went F6h?

hth,

Steve

On 4/1/22 5:23 AM, dott.Piergiorgio wrote:
> On 25/03/22 02:03, David Schultz wrote:
>> All you need to do is fill the directory sectors with 0xe5. I can't
>> find a way to make dd do that.
>
> perhaps creating a file containing some E5s, of appropriate power-of-two
> lent (easy to create with a flexible enough hex editor) and using it as
> input file (if=e5.bin) ?
>
> Best regards from Italy,
> dott. Piergiorgio.
I forgot about one little detail. If you want the disk to be bootable,
it is going to have to look like a boot disk to the ROM BIOS. Which
means that first sector is important too.

I do see CPM listed among the various partition types:
https://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html

That dang ROM BIOS both simplifies and complicates things.

--
http://davesrocketworks.com
David Schultz

On Friday, April 1, 2022 at 7:09:07 PM UTC+1, David Schultz wrote:
> I forgot about one little detail. If you want the disk to be bootable,
> it is going to have to look like a boot disk to the ROM BIOS. Which
> means that first sector is important too.
>
> I do see CPM listed among the various partition types:
> https://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html

Fortunately, partition types don't come into play for a floppy disk. Even for a hard disk, the ROM BIOS doesn't know about partition tables - it just loads the first sector from the drive and that sector is what parses the partition table to find the active volume.

--
John Elliott