Hi there,

I have a Gotek running FlashFloppy in my PC I'm using for CP/M-86. I'm having a hard time finding out the magic sequence to use cpmtools to create new floppies.

Using the cpm86-144feat format, I can seem to create an image, and the CP/M-86 machine can read the directory, but the files are all wrong - truncated, etc. Like the sectors are out of order.

I was trying to create an image like:

dd if=/dev/zero of=test.img bs=1440k count=1
mkfs.cpm -f cpm86-144feat test.img
cpmcp -f cpm86-144feat test.img test.txt 0:

Does anyone know of the incantation to create an image? It doesn't even have to be a 1.44mb image. I just want to transfer some software over to my machine, like modem9.

Thank you!

Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/24/22 7:07 PM, Robert Roland wrote:

Hi there,

I have a Gotek running FlashFloppy in my PC I'm using for CP/M-86. I'm having a hard time finding out the magic sequence to use cpmtools to create new floppies.

Using the cpm86-144feat format, I can seem to create an image, and the CP/M-86 machine can read the directory, but the files are all wrong - truncated, etc. Like the sectors are out of order.

I was trying to create an image like:

dd if=/dev/zero of=test.img bs=1440k count=1
mkfs.cpm -f cpm86-144feat test.img
cpmcp -f cpm86-144feat test.img test.txt 0:

Does anyone know of the incantation to create an image? It doesn't even have to be a 1.44mb image. I just want to transfer some software over to my machine, like modem9.

Thank you!

Rob

I am trying to remember how I did it but I am drawing a blank.

All you need to do is fill the directory sectors with 0xe5. I can't find
a way to make dd do that.

CP/M-68K has a program called init that just fills the director sectors
like that. It includes source but that is in MC68000 assembly.

You could of course whip up a short program that just writes 0xe5 to a file.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy the image file and erase everything?


Randy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25.03.22 01:07, Robert Roland wrote:

Hi there,

I have a Gotek running FlashFloppy in my PC I'm using for CP/M-86. I'm having a hard time finding out the magic sequence to use cpmtools to create new floppies.

Using the cpm86-144feat format, I can seem to create an image, and the CP/M-86 machine can read the directory, but the files are all wrong - truncated, etc. Like the sectors are out of order.

I was trying to create an image like:

dd if=/dev/zero of=test.img bs=1440k count=1
mkfs.cpm -f cpm86-144feat test.img
cpmcp -f cpm86-144feat test.img test.txt 0:

Does anyone know of the incantation to create an image? It doesn't even have to be a 1.44mb image. I just want to transfer some software over to my machine, like modem9.

It does sound a bit like you have a skew factor configured.
Check for cskew and/or interleave in IMG.CFG
My IMG.CFG (for the SB180FX) is pretty simple:

[::819200]
cyls = 80
heads = 2
secs = 5
bps = 1024
gap3 = 99
id = 17

Josef

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

You can use 'tr' to convert the 0x00 to 0xe5:

dd if=/dev/zero bs=1440k count=1 | tr '\000' '\345' >test.img

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Definitions I have for fea1 are as follows. Notice the ORDER CYLINDERS which
has the following meaning in the 22DISK definition. (cpmtools installed with libdsk will
allow you to do this.)

#outback CYLINDERS specifies that all tracks on the first side are recorded
# then all tracks on second side. Tracks on side 0 are written
# from 0 up and side 1 down to 0.

BEGIN FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18
DENSITY MFM HIGH
CYLINDERS 80 SIDES 2 SECTORS 18 512
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18
SIDE2 1 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18
ORDER CYLINDERS
BSH 5 BLM 31 EXM 1 DSM 354 DRM 255 AL0 0C0h AL1 0 OFS 2
END

# FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18
diskdef fea1
seclen 512
tracks 160
sectrk 18
blocksize 4096
maxdir 256
skew 1
boottrk 2
os 3
libdsk:format ibm1440
end

# libdsk Definition
#ORDER CYLINDERS
#
[fea1]
description = FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18 sides = outback
cylinders = 160
heads = 2
secsize = 512
sectors = 18
secbase = 1
datarate = HD

#Flashfloppy/GOTEK Definition
[fea1]
cyls = 160
heads = 2
secs = 18
interleave = 1
bps = 512
id = 1
#rpm = 360
rpm = 300
rate = 500
mode = mfm
iam = no

I'd copy a pretty large ASCII text file so you can look at the sectors and follow the
data to make sure it is correct.

dd if=/dev/zero bs=1440k count=1 | tr '\000' '\345' >test.img
mkfs.cpm -f fea1 test.img
cpmcp -f fea1 -T fea1,rawob /path/to/file/test.img test.txt 0:

or what I'd use is:
cpmcp -f fea1 -T fea1,rawob /path/to/your/image/test.img 0:test.txt

Then for directory listings use:
cpmls -f fea1 -T fea1,rawob -D test.img
AND
cpmcp -f fea1 -T fea1,rawob 0:*.* ./path/to/your/folder/cpm86

See how that works with cpmtools.


libdsk can also be used to write the .img (RAW = Sector Dump) directly to the floppy.

https://forums.debian.net/viewtopic.php?f=16&t=112244


Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Do you have a bootable file of *.TD0, *.IMD that you can forward to me?

Send me a PM with your email address.

Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, March 25, 2022 at 7:37:05 AM UTC-7, [email protected] wrote:

I'd copy a pretty large ASCII text file so you can look at the sectors and follow the
data to make sure it is correct.
dd if=/dev/zero bs=1440k count=1 | tr '\000' '\345' >test.img
mkfs.cpm -f fea1 test.img
cpmcp -f fea1 -T fea1,rawob /path/to/file/test.img test.txt 0:

Thanks - I've given this a shot, but had to make small alterations -

cpmcp -f fea1 -T fea1,rawob test.img 86comutl/* 0:

returned "Requested driver not found", but

cpmcp -f fea1 -T rawob,fea1 test.img 86comutl/* 0:

Seems to have completed successfully. cpmls returns the expected values:

cpmls -f fea1 -T rawob,fea1 -D test.img
Name Bytes Recs Attr update create
------------ ------ ------ ---- ----------------- -----------------
FASTCOM .CMD 4K 7
CHGNUM .CMD 4K 26
CHGNUM .DOC 4K 24
COMOFF .A86 4K 25
COMOFF .CMD 4K 6
COMOFF .DOC 4K 21
COMSET .A86 4K 7
COMSET .CMD 4K 5
COMSET .DOC 4K 14
DIAL .A86 12K 83
DIAL .CMD 4K 7
FASTCOM .DOC 4K 11
MODEM9 .A86 116K 904
MODEM9 .CMD 52K 413
MODEM9 .DOC 8K 35
SEND .A86 8K 34
SEND .DOC 4K 18
SEND1 .CMD 4K 5
SEND2 .CMD 4K 5
SEND3 .CMD 4K 5
SEND4 .CMD 4K 5
TERMINAL.CMD 8K 56
TERMINAL.DOC 4K 21
23 Files occupying 272K, 1140K Free.

On my CPM-86 machine, the directory of this image looks right, but the files are wrong. They either end early, or are full of garbage.

I've still got something slightly off here.

I do have your definitions in /usr/local/share/diskdefs, and ~/.libdskrc, and IMG.CFG (cpmtools, libdsk and FlashFloppy definitions)

For the bootable image, I originally used the CPM86 1.44 image that I believe was created by Freek, obtained here: http://www.cpm.z80.de/download/144cpm86.zip

Thanks,

Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
Yikes, I had mistakes in my commands. I was going from memory, which was incorrect.

cpmcp -f fea1 -T rawob,fea1 /path/to/your/image/test.img 0:test.txt

Then for directory listings use:
cpmls -f fea1 -T rawob,fea1 -D test.img

AND
cpmcp -f fea1 -T rawob,fea1 0:*.* ./path/to/your/folder/cpm86

Plus comment out this line:
#libdsk:format ibm1440

Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
You should also be able to write the .IMG (.RAW = Sector Dump) to floppy using Linux.

Debian Linux has a Floppy Parameter list in /etc/mediaprn. It has lots of pre-defined
definitions. You would have to build a definition but that's easy.

description = FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18 sides = outback
cylinders = 160
heads = 2
secsize = 512
sectors = 18
secbase = 1
datarate = HD

"CPM86-144":
DS HD sect=18 cyl=80 ssize=512

$ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
fd0 2:0 1 4K 0 disk <------------------Proper Floppy Drive
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 117.2G 0 part /
├─sda2 8:2 0 24.4G 0 part
├─sda3 8:3 0 321.7G 0 part
└─sda4 8:4 0 2.5G 0 part [SWAP]
sdb 8:16 1 7.2G 0 disk
└─sdb1 8:17 1 7.2G 0 part
sr0 11:0 1 1024M 0 rom

$ getfdparm /dev/fd0

get geometry parameters: No such device

$ setfdparm -p cpm86144 /dev/fd0
$ getfdparm /dev/fd0

DS HD sect=18 ssize=512

$ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
fd0 2:0 1 800K 0 disk <------------------- Correct size for Floppy
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 117.2G 0 part /
├─sda2 8:2 0 24.4G 0 part
├─sda3 8:3 0 321.7G 0 part
└─sda4 8:4 0 2.5G 0 part [SWAP]
sdb 8:16 1 7.2G 0 disk
└─sdb1 8:17 1 7.2G 0 part
sr0 11:0 1 1024M 0 rom


$ dsktrans -itype rawoo -otype floppy 144CPM86.RAW /dev/fd0


Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
I've made another mistake on the cpm86-144 definition for /etc/mediaprm.

It should be DS QD sect=9 ssize=512

((512 * 9) * 2) * 80 = 737280

Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 5:49:47 AM UTC-7, [email protected] wrote:

Rob,
I've made another mistake on the cpm86-144 definition for /etc/mediaprm.

It should be DS QD sect=9 ssize=512

((512 * 9) * 2) * 80 = 737280

Larry

I haven't had any luck getting any of these images to read on the CPM-86 machine. I can see the directory, but the contents of the files are all bad. Latest attempt was this:

dd if=/dev/zero bs=720k count=1 | tr '\000' '\345' >comm.fea1.img
# I used 720k here because the output is converted to two bytes by the tr command, netting a 1.44 mb file
mkfs.cpm -f fea1 comm.fea1.img
cpmcp -f fea1 -T rawob,fea1 comm.fea1.img test.txt 0:

My cpmtools diskdefs file has this entry:

# FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18
diskdef fea1
seclen 512
tracks 160
sectrk 18
blocksize 4096
maxdir 256
skew 1
boottrk 2
os 3
#libdsk:format ibm1440
end

My ~/.libdskrc:

#ORDER CYLINDERS
[fea1]
description = FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18 sides = outback
cylinders = 160
heads = 2
secsize = 512
sectors = 18
secbase = 1
datarate = HD

And the FlashFloppy IMG.CFG:

# flashfloppy/GOTEK
[fea1]
cyls = 160
heads = 2
secs = 18
interleave = 1
bps = 512
id = 1
#rpm = 360
rpm = 300
rate = 500
mode = mfm
iam = no

I can see the test.txt file in the DIR A: on the CPM-86 machine, but its contents are trashed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/26/22 3:36 PM, Douglas Miller wrote:

It does sound a lot like either sector skew or track/side placement. That is all a product of the BIOS you are running. Perhaps it's time to reverse-engineer the real disk layout. Can you take a known-good disk and create a raw image of it, and either

analyze it for sector skew/side placement or else post it so others can look at it? Ideally, that disk would contain text files that can be more-easily pieced back together.

Or with a working system, ask the BIOS. It does require a short program
to call the Get Disk Parameters function.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It does sound a lot like either sector skew or track/side placement. That is all a product of the BIOS you are running. Perhaps it's time to reverse-engineer the real disk layout. Can you take a known-good disk and create a raw image of it, and either
analyze it for sector skew/side placement or else post it so others can look at it? Ideally, that disk would contain text files that can be more-easily pieced back together.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 3:54:27 PM UTC-5, David Schultz wrote:

Or with a working system, ask the BIOS. It does require a short program
to call the Get Disk Parameters function.
--
http://davesrocketworks.com
David Schultz

Confirming the DPB by asking CP/M will help, but the skew and side placement won't be shown without more work.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/26/22 4:11 PM, Douglas Miller wrote:

On Saturday, March 26, 2022 at 3:54:27 PM UTC-5, David Schultz wrote:

Or with a working system, ask the BIOS. It does require a short program
to call the Get Disk Parameters function.
--
http://davesrocketworks.com
David Schultz

Confirming the DPB by asking CP/M will help, but the skew and side placement won't be shown without more work.

Skew should be easy to discover with DDT. Just find where the SECTRAN
call goes and examine the code.

Side placement shouldn't be too hard as there are only two options. Try
both. Or dig into the sector read code.



--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 2:27:27 PM UTC-7, [email protected] wrote:

Rob,
You can can log the A: drive, then do:

DIR A: DSK:

That doesn't seem to work right -

I get the contents of A:, and:

DSK:?

That will be a good starting point.

[code]
If you have a functional CP/M system, you can use DDT to find the Disk Parameter Block Address,
the Allocation Address, along with the information stored there for the logged floppy drive.

1. Log the floppy drive you wish to locate the DPB data for. I will use A: for this example
2. Run DDT and enter the code below:
A: <Carriage RETURN>
DDT
-f0100,0200,00 #fill memory with zero's
-A0100 #assemble program at 0100
0100 mvi c,0f #0f in C for Open file

This nets a ?

I'm on a CPM-86 1.1 system here (specifically, a Compaq Portable 386). I think MVI is an 8080 instruction?

I'm a little out of my depth here using DDT86 to dig into these BIOS calls.

I wonder if I might be better off running Concurrent CPM-86 3.1 (that can read DOS FAT12 floppies, I believe?)

Thanks,

Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
You can can log the A: drive, then do:

DIR A: DSK:

That will be a good starting point.

[code]
If you have a functional CP/M system, you can use DDT to find the Disk Parameter Block Address,
the Allocation Address, along with the information stored there for the logged floppy drive.

1. Log the floppy drive you wish to locate the DPB data for. I will use A: for this example
2. Run DDT and enter the code below:
A: <Carriage RETURN>
DDT
-f0100,0200,00 #fill memory with zero's
-A0100 #assemble program at 0100
0100 mvi c,0f #0f in C for Open file
0102 lxi d,005c #FCB in reg DE
0105 call 5 #call BDOS
0108 rst 7 #back to DDT
0109 mvi c,1b #1B in C for Get Allocation Address
010B call 5 #call BDOS
010E rst 7 #back to DDT
010F mvi c,1F #get disk parameter address
0111 call 5 #HL will contain the address
0114 rst 7 #back to DDT
0115 nop #
0016 . #type PERIOD to EXIT Assembler
-d0100 #display memory at 0100
0100 0e0f115c00cd0500FF0E1BCD0500FF0E1FCD0500FF
-g0100 #execute program
*108 #program exits here after file search
-g0109 #execute programs
*010E #program exits here with Allocation Address
-g010F #execute programs
*0114 #program exits here with Disk Parameter Address
-xH #display DPB that is in reg HL
#<CR> will exit register modify
#CNTL C will exit DDT and save 1 test101.ddt will save the file
#save n filename.com saves 1 256 byte block of data.

The contents of register HL is the address of Drive A: DPB. If you display that address (mine was
F5E3) you will see F5E3: 2400040F0154007F00C00020000200.

The Disk Parameter Block (DPB) for each drive is: +-----+------+-------+-------+-------+-------+------+------+------+-----+
|SPT.|BSH..|BLM..|EXM..|DSM.. |DRM.|AL0..|AL1..|CKS..|OFF.| +-----+------+-------+-------+-------+-------+------+------+------+-----+
16B 8B 8B 8B 16B 16B 8B 8B 16B 16B

RPT = 0024 = The number of 128 byte records per track.
BSH = 04 = The block shift count.
BLM = 0F = The block mask.
EXM = 01 = The extent mask.
DSM = 0054 = Disk storage maximum (the largest block number).
DRM = 007F = Directory maximum (the largest directory entry).
DAB = C000= Directory Allocation Block AL0: = C0 & AL1: = 00
CKS = 0020 = Directory check size.
OFF = 0002 = Track offset (number of reserved tracks).

SPT: Number of sectors per track. May differ from RPT if physical sectors are other than
128 bytes in size.

SSZ: Sector size code:
0 = 128 bytes per sector
1 = 256 bytes per sector
2 = 512 bytes per sector
3 = 1024 bytes per sector

NTK: Number of tracks (35, 40, 77, or 80). The number of tracks can be determined by formatting
a Floppy, or with Anadisk. Anadisk will also tell you the sector size and SKEW.
[/code]

This will get you the DPB INFO.



AH! I assumed the .IMG was a Sector Dump, but it is a CQ = COPYQM Image file

00000000 43 51 14 00 02 00 00 00 00 00 00 74 00 00 00 00 CQ.........t.... 00000010 12 00 02 00 00 00 00 00 00 00 00 00 30 4B 20 44 ............0K D 00000020 6F 75 62 6C 65 2D 53 69 64 65 64 00 00 00 00 00 ouble-Sided..... 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 00 00 00 00 01 01 50 50 4E DD CC A5 ..........PPN... 00000060 2A 2A 20 4E 4F 4E 45 20 2A 2A 00 4C 0C 46 2A 29 ** NONE **.L.F*) 00000070 00 00 00 00 01 00 04 00 00 00 00 00 00 00 00 00 ................ 00000080 00 00 00 00 76 49 6D 61 67 65 20 66 69 6C 65 20 ....vImage file 00000090 63 72 65 61 74 65 64 20 62 79 20 75 6E 72 65 67 created by unreg 000000A0 69 73 74 65 72 65 64 20 43 6F 70 79 51 4D 1B 00 istered CopyQM.. 000000B0 EB 2B 90 50 56 42 41 43 4B 55 50 00 02 01 02 00 .+.PVBACKUP.....


$ 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 <---------------------Source is this one
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) <---------------------Contents of .RAW file to use with cpmtools
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



$ 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) <-------------Disk Format will be this CPM86 type
acorn160 : Acorn 160k
.........
.........
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
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


Convert the image to a .RAW = SECTOR DUMP type.

$ dsktrans -itype copyqm -otype rawob -format ibm1440 144CPM86.IMG 144CPM86.RAW



$ hexedit 144CPM86.RAW
[code]
00000000 EB 2B 90 50 56 42 41 43 4B 55 50 00 02 01 02 00 .+.PVBACKUP..... 00000010 02 10 00 40 01 FE 01 00 08 00 01 00 00 00 00 00 ...@............ 00000020 00 00 00 00 00 00 00 FF 12 00 10 08 00 FA 8C CC ................ 00000030 8E D4 BC 00 7C FB 8C C8 05 B0 07 8E D8 CD 12 2D ....|..........- 00000040 1A 00 B1 06 D3 E0 8E C0 A3 FF 01 B9 02 00 A0 FF ................ 00000050 02 3C 90 74 21 D0 2E 28 01 D1 2E 2B 01 D1 2E 29 .<.t!..(...+...) 00000060 01 D1 E1 3C 48 74 0F B0 0F A2 28 01 D1 26 2B 01 ...<Ht....(..&+. 00000070 D1 26 29 01 D1 E9 33 C0 33 D2 CD 13 BE 8B 02 E8 .&)...3.3....... 00000080 F5 00 BF 00 34 33 C0 50 51 E8 75 00 59 58 40 E2 ....43.PQ.u.YX@. 00000090 F6 B0 00 BF 00 34 26 81 65 09 7F 7F 26 80 65 0B .....4&.e...&.e. 000000A0 7F BE E2 02 B9 0D 00 FC F3 A6 74 10 83 E7 E0 83 ..........t..... 000000B0 C7 20 FE C8 75 E0 BE C0 02 E9 B6 00 FE 06 A5 02 . ..u........... 000000C0 26 FF 75 05 26 8B 45 03 33 FF E8 34 00 58 80 3E &.u.&.E.3..4.X.> 000000D0 FF 02 48 75 07 0B C0 74 03 E8 25 00 BE 88 02 E8 ..Hu...t..%..... 000000E0 95 00 A1 FE 02 8A 1E 27 01 06 1F BE 80 00 33 FF .......'......3. 000000F0 B9 80 0F FC F3 A4 B9 4B 47 BA 42 44 EA 00 01 00 .......KG.BD.... 00000100 00 8B 0E 2B 01 F7 E1 F6 36 28 01 04 02 51 3A 06 ...+....6(...Q:. 00000110 27 01 74 06 A2 27 01 E8 2E 00 8A FC B3 00 D1 E3 '.t..'.......... 00000120 8B F3 81 C6 00 10 1E 06 1F B9 00 01 FC F3 A5 1F ................ 00000130 50 BE 86 02 E8 40 00 58 FE C4 3A 26 28 01 72 04 [email protected]..:&(.r. 00000140 B4 00 FE C0 59 E2 C6 C3 BE 05 00 50 33 D2 3C 50 ....Y......P3.<P 00000150 72 06 2C 9F F6 D8 FE C6 8A E8 BB 00 10 B1 01 A0 r.,............. 00000160 28 01 B4 02 CD 13 58 73 08 4E 75 DF BE A0 02 EB (.....Xs.Nu..... [/code]


Directory is located at 0x2400 = 9216 Decimal ((512 Sector size * 9) * 2 Boot Tracks) = 9216
[code]
00002400 00 43 50 2F 4D 2D 38 36 20 B1 34 34 00 00 00 80 .CP/M-86 .44.... 00002410 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 ................ 00002420 00 43 50 2F 4D 2D 38 36 20 B1 34 34 01 00 00 80 .CP/M-86 .44.... 00002430 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 .............. ! 00002440 00 43 50 2F 4D 2D 38 36 20 B1 34 34 02 00 00 80 .CP/M-86 .44.... 00002450 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 "#$%&'()*+,-./01 00002460 00 43 50 2F 4D 2D 38 36 20 B1 34 34 03 00 00 80 .CP/M-86 .44.... 00002470 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 23456789:;<=>?@A 00002480 00 43 50 2F 4D 2D 38 36 20 B1 34 34 04 00 00 80 .CP/M-86 .44.... 00002490 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 BCDEFGHIJKLMNOPQ 000024A0 00 43 50 2F 4D 2D 38 36 20 B1 34 34 05 00 00 80 .CP/M-86 .44.... 000024B0 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 RSTUVWXYZ[\]^_`a 000024C0 00 43 50 2F 4D 2D 38 36 20 B1 34 34 06 00 00 80 .CP/M-86 .44.... 000024D0 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 bcdefghijklmnopq 000024E0 00 43 50 2F 4D 2D 38 36 20 B1 34 34 07 00 00 80 .CP/M-86 .44.... 000024F0 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 rstuvwxyz{|}~... 00002500 00 43 50 2F 4D 2D 38 36 20 B1 34 34 08 00 00 80 .CP/M-86 .44.... 00002510 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 ................ 00002520 00 43 50 2F 4D 2D 38 36 20 B1 34 34 09 00 00 50 .CP/M-86 .44...P 00002530 92 93 94 95 96 97 98 99 9A 9B 00 00 00 00 00 00 ................ 00002540 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ................ [/code]



$ ls -alt 144CPM86.RAW
-rw-r--r-- 1 larry larry 1474560 Mar 26 16:01 144CPM86.RAW



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



Editing the autoexec.sub looks sane, but we need a longer file that is ASCII to see if extracts properly.

$ gedit autoexec.sub

GETATCLK
FASTKEYS
NUMOFF
86LOGO



Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
I located a long ASCII file, and inserted it in the Image 144CPM86.RAW. Then, I deleted the Original,
and extracted the file from the .RAW image. It is sane and the size of the file was 13843 Mar 26 16:42 tnc.txt.

Now dsktrans can be used to re-create the CopyQM file, or you can write the .RAW file to a real floppy with
dsktrans.

What method have you been using to write the image file to floppy? I can send you the .RAW or image type you
require.


Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
SORRY, My memory is failing again. The command is:

STAT A: DSK:

If B:'s DPB is different you can log B: drive, and get the same type information from B:

B:

STAT B: DSK:

Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 2:48:52 PM UTC-7, [email protected] wrote:

What method have you been using to write the image file to floppy? I can send you the .RAW or image type you
require.

I'm using a Gotek floppy emulator running the FlashFloppy firmware, as opposed to a real floppy drive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The total capacity of the disk is based on the DPB. Depending on the specifics of your BIOS implementation, the DPB could be stored on the floppy and used during login to access the drive - in which case you'll need to replicate that. Note that cpmtools
does not do that, and mkfs.cpm only initializes the directory area according to what you told it was the DPB. If your version of CP/M-86 does store the DPB on the floppy, then that might explain the "156K" - it is blinding using invalid/unitialized data.

It might be easier to make an image of a working CP/M-86 diskette and post it. I'll be glad to analyze it for you and get the specifics of the format. If you have the source code for the BIOS, you can post that as well and I'll be glad to dig into it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rob,
I created a .IMD and .TD0 file and looked at the .information created by IMDA and IMDU (Imagedisk utilities).

$ dsktrans -itype copyqm -otype tele -format ibm1440 144CPM86.IMG 144CPM86.TD0
$ dsktrans -itype copyqm -otype imd -format ibm1440 122CPM86.IMG 144CPM86.IMD

$ IMDA 144CPM86.IMD >> 144CPM86.TXT


IMDA shows the information on the IMD file

IMageDisk Utility 1.18 / Mar 07 2012
IMD TD 1.5 3.5 HD MFM S-step, 2 sides 6/02/2001 1:34:24

Image file created by unregistered CopyQM

Assuming 1:1 for Binary output
0/0 500 kbps DD 18x512
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
D D D D D DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5
0/1 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5
1/0 D DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5
1/1 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5
2/0 D D DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 D D
2/1 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5
..
..
..
78/0 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 78/1 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 79/0 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 79/1 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 DE5 160 tracks(80/80), 2880 sectors (2520 Compressed)


Which matches the 22DISK definition


BEGIN FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18
DENSITY MFM HIGH
CYLINDERS 80 SIDES 2 SECTORS 18 512
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18
SIDE2 1 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18
ORDER CYLINDERS
BSH 5 BLM 31 EXM 1 DSM 354 DRM 255 AL0 0C0h AL1 0 OFS 2
END


Larry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26.03.2022 at 23:49 Douglas Miller wrote:

The total capacity of the disk is based on the DPB. Depending on the specifics of your BIOS implementation, the DPB could be stored on the floppy and used during login to access the drive - in which case you'll need to replicate that. Note that

cpmtools does not do that, and mkfs.cpm only initializes the directory area according to what you told it was the DPB. If your version of CP/M-86 does store the DPB on the floppy, then that might explain the "156K" - it is blinding using invalid/
unitialized data.

It might be easier to make an image of a working CP/M-86 diskette and post it. I'll be glad to analyze it for you and get the specifics of the format. If you have the source code for the BIOS, you can post that as well and I'll be glad to dig into it.

May be you take a look at my old blog entry also: http://www.z80.eu/blog/index.php?entry=entry120807-180000

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 10:19:52 PM UTC, [email protected] 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)