cpmtools (unfertig???)

    Hi,

    habe ich in der Doku von cpmtools was übersehen oder fehlen da tatsächlich die ganzen Einstellungen für Spielarten der "Doppelseitigkeit"? In der aktuellen "diskdevs" gibt es zwar Hinweise auf einen Parameter "sides" mit den möglichen Werten "alt, outout, outback" aber diese scheinen bei mir keinen Einfluß zu haben und auch im Source kann ich keine Verwendung derselben finden (in den manpages dito).


    Ohne die Definition wie die Spuren/Sektoren unter Verwendung der 2ten Seite abgebildet werden ist das doch ziemlich nutzlos für modernere CP/M Formate, oder?


    Gruß, schufti

    CPMTOOLS wird mit Images genutzt, weshalb die Daten in Reihe (?) hintereinander sein sollten.

    Ergänzung: Wenn als Image mit den LIBDISK erstellt wurde passen die Datenreihenfolge in den Images womöglich, ein

    Image mit IMD macht dabei sicherlich Probleme. Ich habe die cpmtools bisher unter Windows und unter linux ohne die

    libdisk genutzt.



    Ich habe aber auch schon diverse Probleme mit der Formatdefinition unter 22disk und den cpmtools

    gehabt die ich nicht immer lösen konnte. Larry konnte aber oft helfen.


    Beim Zugriff auf die reale Diskette mit den LIBDISKS muß natürlich auch auf die Spurlage geachtet werden.


    Aus New LIBDSK definitions require the following information:


    [title]

    description = DESC The description of the format as shown by (for example) dskform–help.

    sidedness =TREATMENT How a double-sided disk is handled.

    This can either be alt (sides alternate – used by most PC-hosted operating systems),

    outback (use side 0 tracks 0-79, then side 1 tracks 79-0 – used by 144FEAT CP/M disks),

    or outout (use side 0 tracks 0-79, then side 1 tracks 0-79 – used by some Acorn formats).

    If the disk is single-sided, this parameter can be omitted.

    cylinders = COUNT Sets the number of cylinders (usually 40 or 80).

    heads = COUNT Sets the number of heads (usually 1 or 2 for single- or double- sided).

    sectors = COUNT Sets the number of sectors per track.

    secbase = NUMBER Sets the first sector number on a track. Usually 1; some Acorn formats use 0.

    secsize = COUNT Sets the size of a sector in bytes. This should be a power of 2.

    datarate = VALUE Sets the rate at which the disk should be accessed. This is one of: HD, DD, SD or ED.

    rwgap = VALUE Sets the read/write gap.

    fmtgap = VALUE Sets the format gap.

    fm = Y or N Sets the recording mode - Y for FM, N for MFM.

    multitrack = Y or N Sets multitrack mode.

    skipdeleted = Y or N Sets whether to skip deleted data.


    The LIBDSK Data rate will be one of:


    RATE_HD, /* Rate for High-density disc - 1.2Mb in 5.25" 96 tpi drive, or 1.44Mb in 3.5" 96 tpi drive */

    RATE_DD, /* Rate for Double-density disc - 360k in 5.25" 48 tpi drive, or 720K in 3.5" 48 tpi drive */

    RATE_SD, /* Rate for Double-density disc - 180k in 5.25" 48 tpi drive, or 360k in 3.5" 48 tpi drive */

    RATE_ED /* Data rate for 2.8Mb 3.5" in 3.5" 96 tpi drive */




    New CPMTOOLS definitions require the following information:


    diskdef title

    seclen xxx #= Sectors xx,1024

    tracks xx #= (Cylinders * Sides) = 80*2 = 160

    sectrk xx #= Sectors 5,xxx

    blocksize xxxx #= (128*(BLM+1)) = 2048

    maxdir xxx #= (DRM+1) = 256

    skew x #= may be 1 thru 6, or so

    boottrk x #= OFS = 2

    os x.x #= 2.2, or 2, or 3

    end



    So, if you know the 22DISK parameters, you can easily fill in the details for LIBDSK & CPMTOOLS. As an

    Mit freundlichen Grüßen


    fritz

    Einmal editiert, zuletzt von fritzeflink ()

    Hi fritz,

    danke für die rasche Antwort. Ich denke, dass die "Images" die Disk 1:1 so abbilden wie auf der Scheibe vorhanden - ich hätte nicht gesehen, dass ein Imagingtool Parameter bezüglich der "Leserichtung" bei zweiseitigen Disks erwartet. Das ist ja auch der "Vorteil" der Imagingtools, dass sie ohne Kenntnis der Geometrie arbeiten (können); so kann man die Adressierung aus jedem Emulator einfach wie auf echte HW machen.


    Also ist der Parameter "sidedness" oder "sides" (wie dann fälschlich in der aktuellen diskdevs) nur in Zusammenhang mit der libdsk lib wirksam - das muss ich mir dann erst ansehen, LIBDSK hatte ich bislang nicht am Radar, versuche - gerade wenn ich mich in ein neues Thema einarbeite - mit so wenig Komponenten wie möglich auszukommen. Habe LIBDSK auch eher echten HW Zugriffen zugeodnet (wie fdrawcmd)


    Leider gibt es ja zu den cpmtools weder ein "offizielles" Repo noch Doku oder eine Platform (Forum).


    Gruß,

    schufti

    Hi,

    habe mir jetzt die aktuelle Version der cpmtools inkl. libdsk compiliert aber trotzdem schaffe ich es nicht, so etwas einfaches wie das einseitige Kaypro2 Format vernünftig zu "bearbeiten". Das .dsk Image ist aber ok, PAWs SAMconv Tool bringt die selben Dateien wie mein CP/M Rechner.

    Im Anhang mal das .dsk image und die diskdefs die ich verwende - eventuell kann ja ein Kundiger mal ein Auge drauf werfen.

    Ok, also die cpmtools per se scheinen tatsächlich mit DS Formaten nicht wirklich umgehen zu können, dazu muss die LIBDSK eingebunden werden. Diese benötigt zwingend die Definitionen der .libdskrc, ansonsten kommen wieder nur diskdefs und unzulängliche cpmtools-Zugriffe zur Geltung.


    P.S.: das KayproII Format (SS/DD/48tpi) scheint mir ein wenig seltsam. Nicht nur, dass die Sektoren# mit 0 beginnen (kann man über skewtable lösen), es passt auch die Anzahl der Dir-Einträge nicht mit AL0/AL1 zusammen. Die 64 Einträge benötigen 64*32Byte=2k was bei einer Allocationblocksize von 1k 2 Blöcke ergibt, entsprechend einem AL0 Eintrag von 0xC0, definiert ist original allerdings 0xF0, was wohl bei SW die AL0 über die Anzahl der Dir-Einträge bestimmt zu Problemen führt... (und 2 Blöcke verschwendet?)

    Einmal editiert, zuletzt von schufti ()

    Ich habe mal deine ZIP ausgepakt.


    Das kaypro.dsk file ist kein raw imagefile sondern ein SAMDISK file. Ich weiss nicht ob die cpmtools das lesen können aber das steht hier wohl auch drin.

    Ich selber nutze bei den cpmtools nur RAW Images von IMD da ich dazu auch passende Hardware habe.


    Mit freundlichen Grüßen


    fritz

    Einmal editiert, zuletzt von fritzeflink ()

    Die Kaypro2 Variante nutze ich (nach Erweiterung der diskdefs) mit SAMdisk Images erfolgreich so:

    cpmls -f kpii kaypSS.dsk

    cpmcp -t -f kpii kaypSS.dsk 0:*.* cpm

    sowohl cpmtools als auch libdsk geben ja an .dsk zu unterstützen.


    Nach langem Schmökern in der libdsk.pdf und endlosen Versuchen erkannte ich, dass die Definition für KAYPRO4 (kpiv) im o.g. Thread falsch ist. Jetzt mit korrektem .libdskrc Eintrag ist auch das erfolgreich.


    Habe mir noch extra von Dave Dunfield's Seite auch KP4 .IMDs geholt, läuft ebenfalls.


    Alfred: es wurde um 2k größer definiert (4 anstatt 2 1k AUs), somit wäre AL0/1 zu soetwas wie "reserved Blocks" umdefiniert?