I found the image "z80asm.ydsk" and took a look at it, and that one does show two byte block numbers:
000e0: 01 5a 38 30 41 53 4d 20 20 43 4f 4d 00 00 00 80 .Z80ASM COM....
000f0: 14 00 15 00 16 00 17 00 18 00 19 00 1a 00 1b 00 ................
00100: 01 5a 38 30 41 53 4d 20 20 43 4f 4d 01 00 00 44 .Z80ASM COM...D
00110: 1c 00 1d 00 1e 00 1f 00 20 00 00 00 00 00 00 00 ........ .......
So it would appear that the image you are looking at is a different format. The header of these ".ydsk" images seems to contain a DPB in it, perhaps we just need to see the first 128 bytes of the .ydsk file you have.
On Sunday, May 16, 2021 at 7:41:27 AM UTC-5, Douglas Miller wrote:
That diskdef does not seem to match the disk image. The directory entries in the image are for a DPB that has the total number of blocks being <= 256 (one byte block numbers), but the diskdef computes out to 2048 blocks total (two byte block numbers).
This results in cpmtools thinking the first block of CPM.SYS is 0x1110 which would correctly be beyond the end of the disk. I'd have to see more of the disk image to tell what the diskdef needs to be.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)