Hallo,
ich möchte einen ATR Reader schreiben und lese mich gerade in dessen Struktur ein.
Irgendwie finde ich allerdings nichts konkretes über die Struktur eines Directories.
Irgendwo habe ich gelesen das der Directry Start Sector $169 ist.
Wenn ich aber jetzt $80 (Sectorsize)*$169 + $10 byte ATR Header rechne, dann lande ich
mitten im Verzeichnis und nicht am Anfang wie ich vermutete.

Gibts dazu gute Doku?

Gruß
Guido

Die Sektoren werden ab 1 durchnummeriert, nicht ab 0. Also musst du noch $80 abziehen, um den Beginn des Directory zu bekommen.

Das 90K- und 130K-ATARI-DOS-Format ist z.B. im Atari-Profibuch (ABBUC-Version) auf Seite 153 erklärt:
http://www.abbuc.de/mitgliedschaft/down ... -profibuch

drazil hat geschrieben:Irgendwie finde ich allerdings nichts konkretes über die Struktur eines Directories.
Irgendwo habe ich gelesen das der Directry Start Sector $169 ist.

Die Manuals/Handbücher zu vielen DOS für A8 beschreiben das meist schon. Es kommt aber auf das DOS an, ob es die Struktur von Atari DOS 2.x mimict oder eine eigene Struktur mitbringt.

Dietrich hat geschrieben:Die Sektoren werden ab 1 durchnummeriert, nicht ab 0. Also musst du noch $80 abziehen, um den Beginn des Directory zu bekommen.

Das 90K- und 130K-ATARI-DOS-Format ist z.B. im Atari-Profibuch (ABBUC-Version) auf Seite 153 erklärt:
http://www.abbuc.de/mitgliedschaft/down ... -profibuch

Anmerkung: Das trifft aber nur auf Atari DOS 2.x zu. Andere DOS müssen dazu nicht kompatibel sein.

Hallo Leute

Atari DOS 2.5 hat wenn die Diskette formatiert ist 707 freie Sektoren wenn leer, MyDOS hat 708.

Tschuß

Mathy

GoodByteXL hat geschrieben:Es kommt aber auf das DOS an, ob es die Struktur von Atari DOS 2.x mimict oder eine eigene Struktur mitbringt.

Ein Beispiel für eine völlig andere Struktur ist das SpartaDOS File System (SDFS), welches bis 32 MiB mit derzeit maximal 65535 Sektoren in einer Filestruktur auf Datenträger verwalten kann.

Das SDFS ist in der aktuellen Version von SDX erläutert im Manual: http://sdx.atari8.info/index.php , unter Documents herunterladen und im Inhaltsverzeichnis mal durchschauen.

Das SDFS wird auch von anderen DOS benutzt.

Mathy hat geschrieben:Atari DOS 2.5 hat wenn die Diskette formatiert ist 707 freie Sektoren wenn leer, MyDOS hat 708.

Korrekt. Aber was hat das mit der Fragestellung des Threadstarters oder dem Verlauf der Antworten zu tun? Nichts.

Atari DOS 2.x verwendet den Sektor 720 im Single-Density-Format nicht, weil es mal bei DOS 1.0 irgendein Bug gab, der dazu führte, daß versucht wird, auf Sektor 721 zuzugreifen. Ich meinte, das war in Zusammenhang mit den Basic-Befehlen NOTE und POINT bzw. entsprechenden XIO Calls. Dadurch, das der Sektor 720 im DOS 1.x/2.x Format nicht genutzt wird, tritt der Fehler nicht auf. Jedenfalls so in der Richtung...

Der Sektor 720 ist aber in der VTOC schlicht als belegt markiert, genauso wie die Sektoren 1-3 und die Directory-Sektoren. Von daher muß der Selbstbau-ATR-Kopierer sich nur sauber an die Specs halten (wenn hier von Atari DOS Format die Rede ist), dann geht alles gut.

Gruß, Jürgen

Hallo Jürgen

tfhh hat geschrieben:

Mathy hat geschrieben:Atari DOS 2.5 hat wenn die Diskette formatiert ist 707 freie Sektoren wenn leer, MyDOS hat 708.

Korrekt. Aber was hat das mit der Fragestellung des Threadstarters oder dem Verlauf der Antworten zu tun? Nichts.

In MyDOS hat Charles Marslett den Fehler behoben, der bei Atari DOS gemacht worden ist. Ob der Topicstarter dies' berücksichtigen sollte, kann Ich leider nicht sagen da Ich mich damit nicht auskennen. Aber besser einmal zu viel gewarnt als einmal zu wenig.

Tschüß

Mathy

Achtung: Bei ATRs gibt es keine Einigkeit, ob die ersten drei 128 Byte-Sektoren bei Disketten mit 256 Byte-Sektoren gepaddet werden sollen und wenn ja, dann wie. Die Spezifikation sagt auch nichts dazu. Es gibt daher verschiedene Lösungen.
Avery Lee hat da in AtariAge mal was dazu gepostet. Die meisten ATR-Images scheinen tatsächlich nichts zu padden.

Hallo,
erstmal vielen Dank für die Hinweise und Tips das hat schonmal geholfen.
Aktuall kann mein Reader zumindest die Verzeichnisse von diversen Image Typen/Grössen lesen
inkl. Subdirectories.
Ziel der Übung ist es übrigens das der Reader nicht nur ATR's sonden auch DSK's(CPC) und d64|71(c64) Images lesen können soll.

Soweit so gut.
Jetzt versuche ich gerade Files aus dem ATR zu extrahieren. Allerdings aus einem 16MB ATR.
Über den jeweiligen Directory Eintrag finde ich ja den ersten Sector eines Files. Soweit passt es noch.
Ich habe gelernt das die letzten 3 Bytes eines Sektors die Anzahl der zulesenden Bytes, die Filenummer
und den nächsten Sektor beinhalten. Ist auch verstanden.
Nur wenn ich mich jetzt mit denSsektordaten zum nächsten Sektor hangel stehen dort nicht die erwarteten Daten drin sondern irgendetwas anderes.

Ich vergleiche meinen Dump gerade mit der DiskExplorer View aus Altirra.
Wenn ich danach gehe und das Ganze mit meinem Dump vergleiche so stehen die Folgedaten nicht im ermittelten nächsten Sektor sondern einfach direkt hinter dem aktuell bearbeiteten Sektor. Also einfach $100 draufgerechnet.

Wie kann das sein. Ist das bei den grossen Images normal so? Werden die letzten drei Bytes einfach ignoriert?



Bin Dankbar für Ratschläge

Nachtrag, hab den Fehler gefunden.
Beim Lesen des Files bin ich zuerst nach dieser https://www.atariarchives.org/iad/chapter2.php
Anleitungen gegangen. Dort scheint die Anordnung der letzten drei Bytes nicht zu stimmen.
Jetzt bin ich nach der Profibuch Anleitung gegangen und jetzt passt es.

Jetzt stimmt auch der ermittelte Folgesektor.

Moin,

drazil hat geschrieben:Hallo,
erstmal vielen Dank für die Hinweise und Tips das hat schonmal geholfen.
Aktuall kann mein Reader zumindest die Verzeichnisse von diversen Image Typen/Grössen lesen
inkl. Subdirectories.
Ziel der Übung ist es übrigens das der Reader nicht nur ATR's sonden auch DSK's(CPC) und d64|71(c64) Images lesen können soll.

Das sieht nach einem richtig coolen Tool aus, wow! Vielen Dank dafür schon mal, bin mal gespannt, wie es sich entwickelt.

Betreffend DOS und Sektorverkettung: Die üblichen Informationen beziehen sich meistens auf Atari DOS 2.x - und das kann nur bis max. 180 KByte große Disketten verwalten. Die 16 MByte ATRs lassen sich nur mit myDOS oder SpartaDOS anlegen, wobei für GameDOS-Loader meistens dann nur myDOS infrage kommt. myDOS kann auch Unterverzeichnisse, wovon einige der 16 MByte ATRs Gebrauch machen. Das kann Atari DOS pauschal gar nicht.

Auf Mathy´s Homepage findest Du die gesamte Dokumentation inkl. TechDocs für myDOS.

Grüße, Jürgen

Mitterweile klappt auch das extrahieren von Files aus dem grossen ATR File.
Bei dem 16 MB ATR muss man die vollen 16 Bit für den FolgeSektor nehmen statt nur 10Bit. Macht auch Sinn.
Naja ich lerne ja noch.
Mein nächstes Problem sind jetzt die kleinen ATR's 90 KB.
Danach kommen die DSK Images für den CPC dran.

Hallo Drazil

MyDOS benutzt ab eine bestimmt Anzahl von Sektoren 16 Bit für den "Next Sector". Bin mir nicht mehr sicher ab wann genau. Darunter benutzt er 10 Bit für den "Next Sector" und 6 Bit für "Ich bin Teil der x-ten Datei in der Directory", genau wie DOS 2.5. Das kann man aber auch sehen am Eintrag in die Directory. Wenn Ich mich nicht irre ist es das erste Byte im Eintrag.

Tschüß

Mathy

Hi Mathy danke für den Hinweis.
Hatte mir schon sowas gedacht.
Hier habe ich auch noch eine andere Beschreibung dazu gefunden: http://atari.fox-1.nl/disk-formats-explained/
Na dann werde ich mal weiter implementieren. Macht gerade so'n Spass

In was schreibst du das? Qt/Java?

Hi Jac,
das ist eine eclipse RCP Anwendung.
Passt doch zu deiner WUDSN IDE

Das Ganze wird allerdings kein eclipse Plugin.

drazil hat geschrieben:Hi Jac,
das ist eine eclipse RCP Anwendung.
Passt doch zu deiner WUDSN IDE

Das Ganze wird allerdings kein eclipse Plugin.

Und wie das passt, RCP schließt ja plugin/lib nicht aus und das ganze macht ja auch als Standlone-Tool Sinn. AppleCommander habe ich auch so eingebunden. Ich schick Dir mal 'ne PM

Ich arbeite mich gerade in die Eclipse RCP Entwicklung ein.
Bei Interesse : https://github.com/guidobonerz/nerdsuite
Die Screenshots sind allerdings nicht wirklich aktuell