test.zip Analyse
In dem .zip File sind zwei .DSK images!
Beim p2cpm.dsk ist ein TA P2 cp/m für 4300h TPA also mit 48 kB.
Wie vermutet - genau zu sehen ist das der Spur 1 mit Sector eigentlich 16 mit ID als 19 dezimal eingerichtet wurde. (wie zuvor bekannt)
Ich gehe davon aus - dass der directory - Bereich ab Track 2 und mit zwei cluster belegbar sind. Je cluster wurde bei (sks, TA, HELL) also hier mit 1 kB eingerichtet wurden.
Das weiss jeder - weil das erstes gespeichters Programm/ File mit dem CLUSTER 2 +++ folgend benutzt wird.
Daher zählen immer (Anfang) im cp/m mit 0 (null) die CLUSTER / BLÖCKE.
Somit ist klar das für das Verzeichnis / directory mit 0 und 1 reserviert wurden!
Popelt man den cp/m CODE raus - würde man den DPB finden und die Aussagen nochmals bestätigen.
(Wer Lust hat - ist das immer eine schöne Aufgabe - nicht ernst gemeint)
Hätte oder hat man eine solche Diskette, würde sicher von einem laufendem cp/m (egal mit 0100h oder 4300h TPA) mit identischer cp/m DPB (DiskParameterBlock) von einem anderen DRIVE les- schreibbar sein!!!!
Die dort befindlichen Programme / Files sind eigentlich an vielen Stellen (4300h TPA) vorhanden.
Bis auf die ofenbar erstellten BASIC / Fortran ? Anwendungen sind ja ohne Dokumente - also nutzlos, oder?
Wo und auf welchern SERVERN sind / sollten IMAGES gesichert werden?
Jetzt eine gute FRAGE:
Warum sind in einem images nur 128 Byte im director Bereich (physikalischer SECTOR) belegt worden?
Die weitern 128 Byte sind ja offenbar mit HEX 40h vorbelegt gewesen / oder wurde historisch so eingerichtet.
Dieser Zustand ist kein Teil von TA als K-Schutz!
Nur evtl. andere Programm-Analyser kommen ins Schleudern - die Urentstehung ist trivialer!
helwie44 †