DSK images and cpmtools

[hcddr]

I tried to use

diskdef ch376_8M
  seclen 128
  tracks 2048
  sectrk 64
  blocksize 2048
  maxdir 1024
  skew 1
  boottrk 0
  os 2.2
end

for the harddisk file C.DSK

cpmcp -f ch376_8M C.DSK 0:stat.com stat.com

result: 00000000h: 3A 55 50 31 3A 55 50 32 3A 54 54 59 3A 43 52 54 ; :UP1:UP2:TTY:CRT 00000010h: 3A 4C 50 54 3A 55 4C 31 3A 52 2F 4F 00 52 2F 57 ; :LPT:UL1:R/O.R/W 00000020h: 00 53 59 53 00 44 49 52 00 52 2F 4F 20 52 2F 57 ; .SYS.DIR.R/O R/W 00000030h: 20 53 59 53 20 44 49 52 20 2A 2A 20 41 62 6F 72 ; SYS DIR Abor 00000040h: 74 65 64 20 2A 2A 00 41 63 74 69 76 65 20 55 73 ; ted .Active Us 00000050h: 65 72 20 3A 00 41 63 74 69 76 65 20 46 69 6C 65 ; er :.Active File 00000060h: 73 3A 00 20 20 20 20 00 20 44 72 69 76 65 20 43 ; s:. . Drive C 00000070h: 68 61 72 61 63 74 65 72 69 73 74 69 63 73 00 36 ; haracteristics.6 00000080h: 35 35 33 36 3A 20 00 31 32 38 20 42 79 74 65 20 ; 5536: .128 Byte 00000090h: 52 65 63 6F 72 64 20 43 61 70 61 63 69 74 79 00 ; Record Capacity.

original: 00000000h: C3 33 04 20 20 20 43 6F 70 79 72 69 67 68 74 20 ; Ã3. Copyright 00000010h: 28 63 29 20 31 39 37 39 2C 20 44 69 67 69 74 61 ; (c) 1979, Digita 00000020h: 6C 20 52 65 73 65 61 72 63 68 3F 3F 3F 3F 3F 3F ; l Research?????? 00000030h: 3F 3F 3F 3F 3F 3F 00 00 00 43 4F 4E 3A 52 44 52 ; ??????...CON:RDR 00000040h: 3A 50 55 4E 3A 4C 53 54 3A 44 45 56 3A 56 41 4C ; :PUN:LST:DEV:VAL 00000050h: 3A 55 53 52 3A 44 53 4B 3A 54 54 59 3A 43 52 54 ; :USR:DSK:TTY:CRT 00000060h: 3A 42 41 54 3A 55 43 31 3A 54 54 59 3A 50 54 52 ; :BAT:UC1:TTY:PTR 00000070h: 3A 55 52 31 3A 55 52 32 3A 54 54 59 3A 50 54 50 ; :UR1:UR2:TTY:PTP 00000080h: 3A 55 50 31 3A 55 50 32 3A 54 54 59 3A 43 52 54 ; :UP1:UP2:TTY:CRT 00000090h: 3A 4C 50 54 3A 55 4C 31 3A 52 2F 4F 00 52 2F 57 ; :LPT:UL1:R/O.R/W 000000a0h: 00 53 59 53 00 44 49 52 00 52 2F 4F 20 52 2F 57 ; .SYS.DIR.R/O R/W 000000b0h: 20 53 59 53 20 44 49 52 20 2A 2A 20 41 62 6F 72 ; SYS DIR Abor 000000c0h: 74 65 64 20 2A 2A 00 41 63 74 69 76 65 20 55 73 ; ted .Active Us 000000d0h: 65 72 20 3A 00 41 63 74 69 76 65 20 46 69 6C 65 ; er :.Active File 000000e0h: 73 3A 00 20 20 20 20 00 20 44 72 69 76 65 20 43 ; s:. . Drive C 000000f0h: 68 61 72 61 63 74 65 72 69 73 74 69 63 73 00 36 ; haracteristics.6

Unfortunately, extracted files are missing the first 128 bytes. The calculation of the file pointer may not be correct in procedure drive_seek?

[gotaproblem]

Why do you have a skew of 1, try changing to 0. If still problems, then supply your DPB showing SPT, BSH etc.

[gotaproblem]

Ooops, didn't mean to close

[gd-99]

@hccdr, as gotaproblem suggests I think skew is the issue - I did exactly the same thing. Here is my working entry diskdefs. #Z80 Playstation - 8MB HD # 8MB - 1024 tracks, 2048 BlockSize diskdef ch376_8M seclen 128 tracks 1024 sectrk 64 blocksize 2048 maxdir 1024 skew 0 boottrk 0 os 2.2 end

I have also managed to track down cpmfuse. The Wayback machine has a snapshot of the original website here. For Linux users (I think there is an equiv. for Windows) it is possible, once the cpm image is mounted, to manipulate files in the image from within the desktop file manager. I could only find a copy of the actual cpmfuse executable - and source files - on a fairly nondescript Russian site. I am using cpmfuse and it seems to be fine. Happy to upload the zip file if this would be of use.

[hcddr]

cpmtools: I believe that seek 0 and seek 1 do the same thing.

The error lies in the DSK files themselves. The first record is written as the very last one in the file: C.DSK:

00000000h: 00 44 49 53 4B 53 54 41 54 43 4F 4D 00 00 00 3A ; .DISKSTATCOM...: 00000010h: 1D 00 B6 00 B7 00 B8 00 00 00 00 00 00 00 00 00 ; ..¶.·.¸......... 00000020h: 00 44 44 54 5A 20 20 20 20 43 4F 4D 00 00 00 50 ; .DDTZ COM...P 00000030h: 41 00 42 00 43 00 44 00 45 00 00 00 00 00 00 00 ; A.B.C.D.E....... 00000040h: 00 53 41 56 41 47 45 20 20 43 4F 4D 00 00 00 70 ; .SAVAGE COM...p 00000050h: 12 00 2B 00 AD 00 B0 00 B1 00 BE 00 BF 00 00 00 ; ..+.­.°.±.¾.¿... 00000060h: 00 57 4D 56 54 31 30 30 20 43 4F 4D 00 00 00 52 ; .WMVT100 COM...R 00000070h: 1B 00 3E 00 46 00 50 00 AE 00 AF 00 00 00 00 00 ; ..>.F.P.®.¯..... 00000080h: 00 5A 54 52 41 4E 20 20 20 43 4F 4D 00 00 00 20 ; .ZTRAN COM... 00000090h: 1C 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000000a0h: 00 53 41 4C 49 41 53 20 20 43 4F 4D 00 00 00 3E ; .SALIAS COM...> ... ... 007fff20h: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ; åååååååååååååååå 007fff30h: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ; åååååååååååååååå 007fff40h: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ; åååååååååååååååå 007fff50h: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ; åååååååååååååååå 007fff60h: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ; åååååååååååååååå 007fff70h: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ; åååååååååååååååå 007fff80h: 00 4E 5A 43 4F 4D 20 20 20 4C 42 52 00 00 00 69 ; .NZCOM LBR...i 007fff90h: 5B 00 5C 00 5D 00 B4 00 B5 00 C6 00 C7 00 00 00 ; [..].´.µ.Æ.Ç... 007fffa0h: 00 57 4D 20 20 20 20 20 20 43 4F 4D 00 00 00 4C ; .WM COM...L 007fffb0h: 13 00 4A 00 4B 00 4C 00 4D 00 00 00 00 00 00 00 ; ..J.K.L.M....... 007fffc0h: 00 54 46 45 52 20 20 20 20 43 4F 4D 00 00 00 12 ; .TFER COM.... 007fffd0h: 14 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 007fffe0h: 00 4E 5A 43 4F 4D 20 20 20 43 4F 4D 00 00 00 53 ; .NZCOM COM...S 007ffff0h: 10 00 11 00 18 00 40 00 CA 00 1F 01 00 00 00 00 ; ......@.Ê.......

Maybe this has already been changed and the DSK files are out of date?

I don't have a z80 playground, but I want to use the CH376 on my old 8-bit computers from GDR.

[gd-99]

I too don't have a z80 Playground, I'm using my own board, and have found this implementation of CP/M to work very well with it. I am slowly working the wrinkles out for my use.

Picking up on your second to last sentence, gotaproblem, made a change to cbios.asm. This was the last change made with a description as "Corrected sector offset". Prior to this change it was noted a new formatted DSK had corruption. I don't see the same date stamp for the github DSK's so maybe fair to assume these haven't been updated post cbios change?

I have implemented these latest changes into my cbios.asm, and as advised reformatted my DSK's from within CP/M. Mine seem fine and a can read and write using CP/M or cpmtools without corruption.

I'm not well up on file formats and what to look for but if you are able to lead me by the nose so to speak, I'm happy to carry out comparisons on my set-up if this will help. I have access to a hex editor - ghex.

[hcddr]

The pure cpmtools work correctly with a corrected C.DSK. I can extract data and also copy it to the image. Unfortunately, there are problems when compiling cpmtools with libdsk support. Then you have to define a raw format for libsdsk.rc.

I work with Windows and copy the CP / M files with Total Commander: https://hc-ddr.hucki.net/wiki/doku.php/cpm/disketten_xp2

for direct contact: my email address is hcddr@gmx.de I am now waiting for the updated version in github ...

[hcddr]

Unfortunately, your changes are not visible. Maybe you forgot to commit?

[gotaproblem]

The original disk corruption problem was because the CBIOS is documented as using SECTOR numbers starting at 1. This seems not to be the case with large disks. SECTOR numbers started at 0, meaning it became negative, and hence the corruption. The CBIOS is now fixed to start SECTORS at 0.

As far as the disk images go, you should not need to download a new one. Use the format.com tool to reformat the disk image

[hcddr]

Logical sector numbers in CP/M range from 0 to 65535, the physical sector numbers on disk drives usually start with 1. This is not a question of the drive size, the first sector number for hard disks is also 1 (CHS addressing). With disk images you can take the logical sector number from CP/M and start with 0, this saves the conversion.

[gotaproblem]

Fix issued a few months ago. No further problems reported