Ja, wusste auch nicht vorher, das Chuck mit Sydex mehr oder weniger eine One-Man-Show ist. Erst wie ich gesehen habe, dass die Registrierung auch von ihm kam, also dass er auch hinter der info@sydex.com steht, war mir das bewusst geworden.
So wie ich das verstanden hatte, wollte er aber nicht mehr lange das machen (das mit 22Disk und Sydex).
Der Chuck ist auch im Nachbarforum zu erreichen und dort sehr aktiv:
Hier noch etwas zu 22disk und Sydex von Herb Johnson
Der Artikel ist ja relativ alt . Da liegt die Vermutung nahe, daß die dort erwähnten Rechteinhaber, zumindest für 22Disk, nicht mehr die aktuellen sind.
Könnte natürlich auch daran liegen, daß inzwischen kaum noch Geld damit zu machen ist.
Zitat von fritzeflinkIch selber nutze ja meist echte Hardware und da bietet es sich der Einfachheit wegen an, Informationen u.A. auch aus der
SAMDISK Excel Tabelle in die 22disk Formatdefinitionen einfließen zu lassen. Hier sind dann auch Formatdefinitionen aus
SCOPY und Klaus Kämpf seinem PDrive für Genie Rechner zusammengefasst. (Beispiel zu itt3030)
PAW hat mit seiner samdisk Unterstützung weitere Möglichkeiten der Erkennung von Formarten aufgezeigt.
Die Idee, alle bekannten Formate zu sammeln, finde ich gut! Leider eignet sich die Formatdatei von 22DISK nur bedingt dafür, da z.B. nicht alle Formate aus SCopy darin abgebildet werden können (Leistungsumfang von 22DISK deckt nicht alle Möglichkeiten von SCopy ab).
Das war auch der Grund, warum ich eine eigene EXCEL-Tabelle (SAMCONV.xls ... letzte Vers. 2.20) angelegt habe. Hier ist es möglich Formate aus 22DISK und SCopy, sowie weitere Formate abzubilden und auch bei SAMdisk-Images anzuwenden. Dazu gibt es importprogramme um Formate aus den oben genannten Tools zu importieren:
Falls die Parameter häufig für 22DISK benötigt werden, könnte man über eine Exportfunktion von SAMCONV in die 22DISK-Tabelle nachdenken.
Nachtrag zu SAMCONV 2.20: habe bei Tests auf neueren EXCEL-Versionen (neuer als OFFICE 2003) festgestellt, dass es auf 64-Bit Versionen (derzeit) nicht läuft. Makros bringen eine Fehlermeldung.
Grüße, PAW
Können wir eine eigene Format-Definitions-Datei für 22Disk nutzen und die erweitern, wie wir wollen?
Können wir eine eigene Format-Definitions-Datei für 22Disk nutzen und die erweitern, wie wir wollen?
Ja, das in der ausführlichen 22disk.txt Dokumentation beschrieben.
stripidx Syntax is - stripidx in-file out-file
erstellt aus einer *.def Datei eine *.txt Datei
genindex.exe Syntax is - genindex in-file out-file
erstellt aus einer Definitions Textdatei eine für 22disk indizierte Datei.
Ich habe für meine Systeme eine kleine Definitionsdatei die ich leicht editieren kann und per batch mit Genindex verarbeite.
Dann fange ich mal an:
"22disk" disk definition:
BEGIN FOR1 Formula 1 - DSDD 48 tpi 5.25"
DENSITY MFM ,LOW
CYLINDERS 40 SIDES 2 SECTORS 18,256
SIDE1 0 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
SIDE2 1 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
ORDER SIDES
BSH 4 BLM 15 EXM 1 DSM 172 DRM 127 AL0 0C0H AL1 0 OFS 3
END
BSH 4 = Block shift needed for translation of an allocation block number to a relative address
BLM 15 = Block mask / bit mask corresponding with BSH
EXM 1 = extent mask / bit mask for delimiting extents or groups of records
DSM 172 = total number of sectors present on a diskette
DRM 127 = total number of directory entries (related to AL0 and AL1 also)
AL0 0C0H = most significant bit (maps the first allocation block of the disk)
AL1 0 = least significant bit
OFS 3 = number of tracks used for storing the CP/M system and BIOS
Und noch von meinem ehem. Rechner Elzet/P (Elzet-80):
BEGIN ELZ1 Elzet 80 Quad Density - DSDD 96 tpi 5.25"
DENSITY MFM ,LOW
CYLINDERS 80 SIDES 2 SECTORS 5,1024
SIDE1 0 1,2,3,4,5
SIDE2 1 6,7,8,9,10
ORDER SIDES
BSH 4 BLM 15 EXM 0 DSM 390 DRM 127 AL0 0C0H AL1 0 OFS 4
END
Gab es in der ct nicht mal eine große Übersicht?
Ich müsste mal nachschauen..
xesrjb
Gab es in der ct nicht mal eine große Übersicht?
Ich müsste mal nachschauen..
xesrjb
Habe ich hier (siehe Bild), leider nicht fehlerfrei und mit Vorsicht zu nutzen.
Chaos mit System
Diskettenformate unter CP/M
Holger Petersen, Axel Unterschütz
Grundlagen CP/M-Diskettenformate
c't 6/85 S. 120 (gr)
Weiter informativ:
Daten auf Scheiben
File- und Disk-Formate unter CP/M, MSDOS und TOS
Wilfried Haaf, Frank Middel
Kartei, Floppy, Diskettenformate
c't 11/87 S. 241 (be)
CP/M wird flexibel
Beliebige Disketten-Formate unter CP/M 2 am Beispiel der IFC-Karte
Thorsten Freygang
Programm, CP/M
c't 5/87 S. 166
Ich habe aus der aktuell lizensierten 22disk Version das Tool FTOD getestet.
Ein RAW Image aus dem Prof.181 im PROF8 Format.
fctod p181x_01.bin /pro8 a*:*.* c:\temp
// Falls das Format nicht angegeben wird kann das Formt interaktiv ausgewählt werden
Ergebniss in c:\temp:
C:\...disktool\22fch\fttest.txt
Copying A0:T80.COM to c:\temp\T80.CPM
Copying A0:PROFILE.SUB to c:\temp\PROFILE.SUB
Copying A0:SETDEF.COM to c:\temp\SETDEF.CPM
Copying A0:PROFILE.BAK to c:\temp\PROFILE.BAK
Copying A0:MKBIOS.SUB to c:\temp\MKBIOS.SUB
Copying A0:MKBIOS.BAK to c:\temp\MKBIOS.BAK
Copying A0:PROF181X.TXT to c:\temp\PROF181X.TXT
Copying A0:22-PROF.TXT to c:\temp\22-PROF.TXT
Copying A0:P2.181 to c:\temp\P2.181
Copying A0:P7.181 to c:\temp\P7.181
Copying A0:P6.181 to c:\temp\P6.181
Copying A0:PMON181.ASM to c:\temp\PMON181.ASM
Copying A0:PIP.COM to c:\temp\PIP.CPM
Copying A0:PD.PRN to c:\temp\PD.PRN
Copying A0:PD.REL to c:\temp\PD.REL
Copying A0:PD.SYM to c:\temp\PD.SYM
Copying A0:PL.PRN to c:\temp\PL.PRN
Copying A0:PL.REL to c:\temp\PL.REL
Copying A0:PL.SYM to c:\temp\PL.SYM
Copying A0:P7.SYM to c:\temp\P7.SYM
95 file(s) copied
Copy complete22Disk in der Version 1.45 ist wohl nicht ganz fehlerfrei. Mir ist aber noch nicht klar, ob man das überall nachvollziehen kann.
Ich habe einen Formula One, habe also folgerichtig auch das Diskettenformat dazu ausgewählt.
Dann habe ich IMD genutzt, um eine Image-Datei aus der CP/M Bootdisk des Formula One zu erzeugen, die hängt hier als ZIP-Datei dran.
Mit IMDU (per Kommando: IMDU FORMULA1.IMD FORMULA1.BIN /B) habe ich dann eine Sector-by-Sector Image-Datei (also nur die Floppy-Sektoren ohne Track- bzw. Steuerinformation) gemacht.
Zuerst einmal habe ich dann FCTOD unter DOSBOX ausprobiert - ging nicht.
Den Fehler habe ich dann in DOSBOX erstmal vermutet.
Also nochmal auf dem echten Rechner ausprobiert und eingeben:
CTOD /FOR1 B0:STAT.COM STAT.COM (mein 360KB-Laufwerk ist B: !)
Es kam mit der Version 1.45 eine Fehlermeldung.
Also habe ich 22DISK 1.44 genommen, und das eingegeben - ging alles glatt.
Zurückgewechselt auf 22DISK 1.45 und wieder CTOD genutzt - ging dann auch (komisch?! Auf einmal...).
Dann wieder FCTOD versucht, ging mit dem Binary Image wieder schief.
Wer IMD nutzt, um die Formula-One Bootdiskette auf eine echte DD Diskette wieder zurückzuschreiben, kann das auch selbst alles ausprobieren.
Muss wohl Chuck mal fragen...
Hallo Fritz,
das ist zwar eine Erklärung, warum es nicht gehen könnte, aber nicht wirklich logisch.
Denn das CTOD funktioniert ja auch. Und programmatisch könnte man ja die unterschiedliche Geometrie (wenn vorhanden) mit berücksichtigen.
Ich sehe momentan anhand der 22Disk Definition auch nicht, warum da SD als Systemspur vorhanden ist:
BEGIN FOR1 Formula 1 - DSDD 48 tpi 5.25"
DENSITY MFM ,LOW
CYLINDERS 40 SIDES 2 SECTORS 18,256
SIDE1 0 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
SIDE2 1 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
ORDER SIDES
BSH 4 BLM 15 EXM 1 DSM 172 DRM 127 AL0 0C0H AL1 0 OFS 3
END
Wo steht das hier in der Definition ? OFS steht nur für die Anzahl der Systemspuren.
Chuck hat sich auf meine Frage hin schon gemeldet und schaut sich das näher an, er kann sich das momentan nicht erklären und meldet sich wieder bei mir.
Dann kann ich die Antwort auch hier posten.
Gruß Peter
Edit: Ok. Fritz, Du scheinst da wirklich recht zu haben. Im User Handbook steht das hier:
Bleibt aber trotzdem die Frage offen, wieso CTOD funktioniert - da müsste man ja die gleichen Probleme haben...
Edit ^2: Siehe FORMULA2.ZIP - habe mal 2304 Bytes (18x128 Bytes) eingefügt, dann funktioniert auch FCTOD damit. Ist aber irgendwie blöde, weil wie bereits erwähnt CTOD damit ja auch zurecht kommt. Da wurde das FCTOD wohl etwas einfacher programmiert.
Alles anzeigenas ist zwar eine Erklärung, warum es nicht gehen könnte, aber nicht wirklich logisch.
Denn das CTOD funktioniert ja auch. Und programmatisch könnte man ja die unterschiedliche Geometrie (wenn vorhanden) mit berücksichtigen.
Ich sehe momentan anhand der 22Disk Definition auch nicht, warum da SD als Systemspur vorhanden ist:
BEGIN FOR1 Formula 1 - DSDD 48 tpi 5.25"DENSITY MFM ,LOW
CYLINDERS 40 SIDES 2 SECTORS 18,256
SIDE1 0 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
SIDE2 1 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
ORDER SIDES
BSH 4 BLM 15 EXM 1 DSM 172 DRM 127 AL0 0C0H AL1 0 OFS 3
END
22disk und ctod bearbeiten die Diskette ab den Directoryspuren.
Der Offset bezieht sich auf die Spur unabhängig wie formatiert. für die Daten ist das auch unerheblich.
Bei einer physikalischen Diskette definiert der Stepper die Kopfposition.
Bei einem Image muß die Position des Directorys (OFFSET) in Anzahl der Bytes angegeben werden (bei unterschiedlicher sektorart im Offset zum Rest der Diskette) und ist abhängig von Sektorgröße * Anzahl Sektoren und auch der eventuell speziellen Handhabung der Diskettenseiten.
Hallo Fritz,
Danke für die Erklärung, auch wenn das jetzt nicht neu war. Chuck meint, es wäre vielleicht eine Idee, einen zusätzlichen Parameter in die Cpmdisks.def reinzubringen. Was hältst Du davon ?
Gruß Peter
Hallo Fritz,
Danke für die Erklärung, auch wenn das jetzt nicht neu war. Chuck meint, es wäre vielleicht eine Idee, einen zusätzlichen Parameter in die Cpmdisks.def reinzubringen. Was hältst Du davon ?
Gruß Peter
Hallo Peter,
meine kleine Erläuterung war auch eher für Mitleser gedacht.
Wenn fctod universeller wird - warum nicht ?
Was für ein Parameter soll denn eingeführt werden.
Na denkbar wäre bspw. ein optionaler Wert für eine im Format differierende Systemspur, d.h. wenn die Angabe existiert, dann ist die Spur logisch anders aufgebaut. Also beim Beispiel Yodobashi Formula One bspw. dann so:
BEGIN FOR1 Formula 1 - DSDD 48 tpi 5.25"
DENSITY MFM ,LOW
CYLINDERS 40 SIDES 2 SECTORS 18,256
SYSTRK 0 SECTORS 18,128
SIDE1 0 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
SIDE2 1 1,2,5,6,9,10,13,14,17,18,3,4,7,8,11,12,15,16
ORDER SIDES
BSH 4 BLM 15 EXM 1 DSM 172 DRM 127 AL0 0C0H AL1 0 OFS 3
END
Da bin ich für, gute Idee. 
Ok, neuer Post von Chuck.
Er schlägt einfach eine zusätzliche Kommandozeilen-Option vor, also bspw. /TEST=12345 , wobei dann 12345 der Offset-Wert in Bytes wäre, wo das Directory anfängt. Finde ich besser als nichts, aber ist halt wenig komfortabel, weil man dann selbst immer nachschauen muss, welchen Wert man dazu bräuchte.
Habe ihm vorgeschlagen, er soll einfach die Community einbinden, die können ja für Ihn die CPMDISKS.DEF editieren, so dass ein zusätzlicher Offset-Wert dann in der CPMDISKS.DEF steht. Wäre später bei der Nutzung halt wesentlich komfortabler.
Chucks letzte Antwort hat mich wieder etwas ernüchtert:
Hi Peter,
Your input, as always, is valuable. However, there is the matter of reality for me, at least--and the stated purpose of the pair (22Disk and 22Nice).
My last serious use of CP/M was probably around 1984. I realized then that CP/M, particularly in the 8-bit world was a thing rapidly fading toward extinction. There was a strong user base in the CNC world, but even that was moving toward MS-DOS. So I development 22Disk to assist people in crossing to the new PC world. The 22Nice package, in addition, would let them transparently run their applications. (One of my longest-term customers was Vic Gerhardi, who you may know from his Z-88 "Wizardry" book. He used Datastar on his PC until well after 2010. After the death of his wife, however, he's dropped out of sight.) It succeeded marvelously in that respect. Mission accomplished.
One can, of course, see the text representation of all definitions using the STRIPIDX utility.
FCTOD was an afterthought--done long after the original product. The file I/O routines for it also allow writing, so an FDTOC would probably be a fairly simple task. But there's the matter of reality.
Total receipts for 22Disk registration thus far this year amount to less than what I get for reading one reel of 1/2" tape. And I still process perhaps 100+ reels of tape from the 1960s and 1970s.
My lovely wife and I are well into our seventh decade--an age where one deals with the problems of age and the very real prospect that tomorrow might not be as easy as today. My object for participating in the vcfed discussions are not so much for my own benefit, but to contribute what I've learned over the 50 or so years in this business. I most certainly am not a collector, though I still have a stash of equipment that was purchased to do work.
I hope you can understand. Mostly today, I want to spend time outdoors with my wife and dogs while I'm still able. Perhaps someday, I'll simply share the source code assuming that there's no legal liability attached.
All the best,
Chuck
Das habe ich so verstanden, als ob er da doch nichts mehr an Zeit investieren möchte.
Allerdings habe ich mir selbst geholfen, und eine Art "Preprocessor" für FCTOD geschrieben. Siehe Anhang (ZIP Datei, mit C-Quellcode).
Jetzt fehlt mir aber momentan auch die Zeit, die Konfigurationsdatei mit Leben zu füllen, d.h. mit den Formaten von 22DISK, die genau das Problem mit der abweichenden 1. Systemspur haben. Habe das mal beispielhaft für das Format "FOR1" gemacht, und ich denke das 2. Beispiel OSB1 ist auch nicht ganz falsch, habe es aber *nicht* ausprobiert.
Das Programm wird einfach *VOR* FCTOD mit der Image-Datei ausgeführt.
Beispielaufruf:
MODIMAGE /FOR1 imgfile1.bin imgfile2.bin
Wenn "FOR1" in der MODIMAGE.CFG gefunden wird, werden die Werte in der Zeile genommen, um das Image zu vergrößern.
Ich bin davon ausgegangen, dass es keinen Fall für "Verkleinern" gibt.
Gruß Peter
Immerhin ist es möglich, dass er eines Tages den Quellcode für den ganzen Kram öffnet.
Hallo Fritz,
solange nur Du das liest, ist es aber keine programmtechnische Lösung.
Ja, mit einem zusätzlichen Programm ist das auch nicht elegant, aber wenigstens habe ich das Problem mit dem oben angehängten C-Programm so gelöst, dass es automatisch bearbeitbar ist.
Ich werde versuchen, meine Datenbasis für das o.g. Programm weiter auszubauen, aber wie gesagt, das kostet Zeit.
Könnte auch versuchen, so ein Kommentar in der CPMDISKS.DEF direkt auszuwerten, aber das ändert nichts daran, dass jemand diese Werte erst erfassen muss.
Gruß Peter
Zum Erfassen der Werte :
Ich habe mit dem HxC Konverter TD0 nach IMD gewandelt, das geht in batchmodus.
Mit TD02IMD geht es auch, habe ich aber nur Dateiweise gemacht und ist nicht ganz so einfach.
Dann wandel ich die IMD nach RAW (BIN) mit IMDU und schreibe die Konsolenausgabe nach Imagename.log
Das ganze hier manuell, eine Batchmöglichkeit wäre natürlich toll.
Hier Aufruf unter NC als Extension: IMD imdu !.! !.bin /B/E/D/Y >!.log
IMDU Image.IMD Image.bin /B/E/D/Y > IMAGE.log
Als Ergebniss habe ich ein RAW-Image und die Informationen dazu im log.
Mit TDCHECK lasse ich noch die hoffentlich in der TD0 gespeicherten Einträge anzeigen.
Ich habe für die Don Maslin Images eine kleines Projekt beendet.
Aus dem readme:
This is am workplace for informations about the formatdefinitions.
Please go to /images-97 and into the alphabetic folder of your computersystem
as there may be a lot of more informations like extracted files in a *.zip file.
Using:
HxC coverter to make IMD from TD0
IMDU for BIN (RAW-files) and the LOG files where you get the track / sector
information for the IMD
Excample:
## 100-cond.log ##
IMDU:
Assuming 1:1 for Binary output
0/0 250 kbps DD 16x256
35/0 250 kbps DD 9x512
80 tracks(40/40), 1210 sectors (347 Compressed)
TDCHECK for information about the TD0 files if a Note ins included
TDCheck TeleDisk File Checker, Version 2.23TUL
Sydex Copyright 1993. All Rights Reserved.
-- Checking F:\ALL\TD0\100-COND.TD0...
Produced with version 2.1
New Advanced data compression was used.
All sectors were copied.
Both sides were checked.
Source was 5" low-density MFM.
This file was created on March 6, 1994 at 15:08:48
Condor 20 for HP 100 series
DSDD 256 byte sector, 0-15, 4:1
ding Track 0, Side 0, 16 Sectors
Reading Track 0, Side 1, 16 Sectors
Reading Track 1, Side 0, 16 Sectors
Reading Track 1, Side 1, 16 Sectors
Reading Track 2, Side 0, 16 Sectors
Reading Track 2, Side 1, 16 Sectors
Reading Track 3, Side 0, 16 Sectors
Reading Track 3, Side 1, 16 Sectors
Reading Track 4, Side 0, 16 Sectors
Reading Track 4, Side 1, 16 Sectors
Reading Track 5, Side 0, 16 Sectors
Reading Track 5, Side 1, 16 Sectors
Reading Track 6, Side 0, 16 Sectors
*** and so onGut Sache. Damit kann ich auch mein Tool mit Daten füttern, die Konfigurationsdatei dazu stelle ich dann hier rein.
P.S.: Kann man auf oldcomputers-ddns.org auch via FTP zugreifen ?
