Das XX gezieht sich auf den Offset 15 im Track Info Block.
Dieser gibt am viele Sektoren es in einem Track gibt.
Und woher weiß man wie viele Tracks es gibt?
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von oobdoo am
Das XX gezieht sich auf den Offset 15 im Track Info Block.
Dieser gibt am viele Sektoren es in einem Track gibt.
Und woher weiß man wie viele Tracks es gibt?
Das steht doch in der Doku
Die Anzahl der Tracks steht bei Offset 30 in der von dir verlinkten Doku
Das hier ist was mein Code bisher ausgibt vom Header und vom Directory am Beispiel vom Spiel HACKER
Das steht doch in der Doku
Das ist richtig. Ich habe aber nur deepl.com als Übersetzer. Der reicht aus um ganz leichte Konversation auf Englisch zu betreiben.
Bei technischen Texten versteh ich aus so einer Übersetzung in der Regel weniger als 50%, d.h. ich muss beim Programmieren
hin und wieder Raten bis ich zu einem funktionierenden Ergebnis komme oder öfter in einem Forum wie hier Nachfragen.
So sieht es bei mir aktuell aus wenn ich ein DSK eingelesen habe. Da steht mir noch ein langer Weg bevor, bis ich hoffentlich ein
DSK ohne Fehler auswerten kann.
Das ist richtig. Ich habe aber nur deepl.com als Übersetzer. Der reicht aus um ganz leichte Konversation auf Englisch zu betreiben.
Ok, sorry. Meine Antwort sollte nicht zynisch wirken.
Sieht doch schon gut aus.
Ok, sorry. Meine Antwort sollte nicht zynisch wirken.
Kein Problem, alles ist gut.
Ich habe ein weiteres Verständnisproblem. Im Sector Info wird der Offset 03 als Sector Size beschrieben, mit einer Länge von einem Byte.
Das ist der Wert welcher der Sector ID folgt. Mit CPCDiskXP prüfe ich meine Ergebnisse. Das meldet als Sektorgröße 512 Bytes. Eine Zahl die
aber zwei Bytes benötigt. Wenn ich mit beim Rechnen nicht vertan habe, dann sind im Hexeditor nach der Sector ID die 512 bzw. &200 zu
finden. Dies wäre dann aber im Widerspruch zur Sector Size Angabe auf http://www.cpcwiki.eu/index.ph…SK_disk_image_file_format
welche ja nur ein Byte länge haben darf.
Was stimmt denn nun? Oder habe ich da einen Fehler gemacht und ihn übersehen?
Oder ist die Sektorgröße speziell kodiert? Also 0 für 128 Bytes, 1 für 256 Bytes und 2 für 512 Bytes. Dann gäbe es kein Problem mehr mit der 1-Byte Länge.
Allerdings habe ich diesbezüglich keine Informationen gefunden die meine Spekulation bestätigen würde.
Nachtrag:
Ich habe auf https://www.cpc-power.com/cpca….php?page=articles&num=39 etwas gefunden was meine Überlegung stützen könnte.
For 8k Sectors (N="6"), only 1800h bytes is stored.
Wenn 8kb den N=6 entsprechen, dann käme bei 512 Bytes ein N=2 raus.
https://github.com/teiram/dsktools?files=1
Ich würde sagen, das ist 128 << 2, wenn ich die Sources recht lese. Also immer 128 nach links schieben.
https://github.com/teiram/dsktools?files=1
Ich würde sagen, das ist 128 << 2, wenn ich die Sources recht lese. Also immer 128 nach links schieben.
Meine Überlegung war so:
512 = N 2
1024 = N 3
2048 = N 4
4096 = N 5
8192 = N 6
Hm, 04:00 Uhr. Zeit langsam Schluss zu machen...
Noch was gefunden: https://acorn.huininga.nl/pub/…d/software/pc/fdc/fdc.txt
Dort steht:
BYTES n Set number of bytes per sector. "n" is 128, 256, 512, or 1024.
Würde zum Text auf Seite 5-13 im Datasheet vom FDC passen: http://www.cpcwiki.eu/imgs/f/f3/UPD765_Datasheet_OCRed.pdf
Ja, das stimmt doch.
N=2 : 128 << 2 = 512
N=3 : 128 << 3 = 1024
usw
Achso. Ja da hast Du natürlich Recht.
Die kleinste Einheit ist hierbei immer ein Record=128 Byte
Die kleinste Einheit ist hierbei immer ein Record=128 Byte
Noch nicht viel mehr als gestern, aber dafür bin ich mir heute sicher(er) das die gelesenen Werte auch stimmen.
Gerade mal ~300 Bytes von 191kb ausgewertet. Mal schauen was die Nacht so bringt.
Das ist aber kein cp/m Format, oder? Dafür hätte ich nämlich Sources...
Das ist aber kein cp/m Format, oder? Dafür hätte ich nämlich Sources...
Hmm, das weiss ich leider nicht ob das ein CP/M Format ist.
Ich vermute aber, das NUR das Disk Layout an sich CP/M entspricht und der Rest CPC specifisch ist.
Irgendwo hab auch gelesen, das CP/M auch nicht immer gleich CP/M war/ist.
Wo steht denn in der Anleitung vom Buch (Beschreibung des CPC - DSK DiskImage Formats gesucht)
oder im CPC Wiki wie die Startposition vom Directory berechnet wird? Ich komme gerade nicht weiter.
Hmm, das weiss ich leider nicht ob das ein CP/M Format ist.
Ich vermute aber, das NUR das Disk Layout an sich CP/M entspricht und der Rest CPC specifisch ist.
Irgendwo hab auch gelesen, das CP/M auch nicht immer gleich CP/M war/ist.
... vielleicht helfen dir diese Definitionen. Es gab übrigens mal einen CPC Emulator namens CPCEMU von Marco Vieth. Da sind sehr viele Infos dabei ...
Wo steht denn in der Anleitung vom Buch (Beschreibung des CPC - DSK DiskImage Formats gesucht)
oder im CPC Wiki wie die Startposition vom Directory berechnet wird? Ich komme gerade nicht weiter.
Hi,
das ist abhängig von der ersten Sektor ID im ersten Track.
Steht dort eine 0x41 dann ist es eine System Disk (bootable), dann muss man die ersten beiden Tracks überspringen.
Wenn ein anderer Wert drin steht wie z.B. 0xc1 , dann ist eine Daten Disk und das Verzeichnis steht direkt hinter der Sektorinformation Liste vom ersten Track.
Gefunden hab ich das hier
Ich verstehe das so:
Also ist in Sector 0 die SectorID für die Unterscheidung der richtige Wert?