… für mich! Eingehend beschrieben wurden die Formate der Atari Disketten und der DOS’e schon oft. Sei es in zeitgenössischen Büchern oder hier und da im WWW. Ausschlaggebend für mich diesen Artikel zu schreiben war, dass ich zwar viel über das Thema gelesen habe, bis jetzt aber nicht in der Lage war das ganze zusammenhängend, kurz und knackig wiederzugeben. Diesen Versuch will ich jetzt einmal wagen……
Schlagwort-Archive: Atari Disk
MADS => *.ATR
Toller Assembler, der MADS. Standardmäßig erzeugt der aber *.XEX Dateien. Keine schlechte Sache, an sich. Wenn man aber das SIO2USB Interface benutz und es nicht schafft genau solche Dateien damit zu starten, dann steht man vor einer Herausforderung, die man gerne annimmt.
*.XEX sind Atari DOS 2.X (mit DOS 1.0 müsste es auch gehen) kompatible Binary’s. Ich habe noch keinen Weg gefunden solche Dateien mit dem SIO2USB zu starten.
Also, man überredet den MADS einfach dazu ein *. ATR zu erzeugen. Problem gelöst!
Wie das geht kann man sich hier anschauen:
*.XEX spielerisch erklärt:
Alternativen zur Atari 1050…
….Einen zeitgenössischen Artikel dazu findet man da:
Electronic Games, Dezember 1984, Seite 69
Ob Concorde, Percom oder Rana. Alles da um es nachzulesen.
Percom: 704kB? Welches DOS? Fragen über Fragen…..
Useful Bugs….
Aus: „Inside Atari Dos“
Merke: Das FMS des Atari Dos akzeptiert keine Sektor 0! Für Atari Beginnt die Diskette mit Sektor 1!
Eine kurze Geschichte der Dateisysteme…
…passt ganz gut zu meinen Anstrengungen Mac OS das Lesen von 8- Bit Atari Disketten beizubringen. Informativ und Amüsant:
Zum Artikel geht es hier:
Eine Zusammenfassung meines eigenen kleinen Projektes, und ein paar Informationen zum Atari Disk- File Format gibt es hier im Blog:
- ATR Open.
Funktionssammlung in der Programmiersprache C zur Emulation des Atari DOS 2.x FMS. - Diverses zum Atari DOS 2.X File Format
Binaray File Format des DOS 2.X // Boot Sektoren.. - Inside Atari DOS
Das Atari DOS 2.x im Detail
Viel Spass!
ATR Open
Kleiner Erfolg. Alle „Kernel- Routinen“ laufen. Die erste höher Funktion ist auf dem Weg: „rfile“, wir können nun eine Datei lesen. Das tracen funktioniert, nur das Kopieren der Daten in den Buffer muss noch richtig programmiert werden.
„rfile“ liest eine Datei und ermittelt dabei die exakte Dateigröße.
Inside Atari DOS
Unerlässlich für jeden der verstehen möchte wie der ATARI Disketten verwaltet. Die digitale Ausgabe findet sich bei: http://www.atariarchives.org/iad/
Compiled by Bill Wilkinson,
Optimized Systems Software, Inc.
Published 1982
ATARI DOS 2.x unter MAC OS X…..
….derzeit eine Sammlung grundlegender Funktionen in „C“. Nicht mehr.
Mit grundlegend bezeichne ich derzeit zwei Hauptgruppen von C- Subroutinen die ich zur Zeit entwickele. Die eine möchte ich gerne als „Kernel- Funktionssatz“ benennen. Das sind solche Programmteile die als Bausteine der zweiten Funktionsgruppe dienen, die wiederum komplexere Aufgaben übernehmen und sich aus Funktionen der ersteren zusammensetzen.
Zur Gruppe der „Kernel- Funktionen“ gehören beispielsweise:
- fgetstart
Liefer den Startsektor eines Files zurück - fgetnext
Liefert die Nummer des nächsten Sektors in der File- Sektor- Kette zurück - fgetstat
Liefert den Status eines Files zurück - fgetscnt
Liefer die Anzahl der Sektoren die durch das File belegt werden zurück - fgetfno
Liefert den Index des Files entsprechend seines Auftretens im Directory zurück
Die Zweite Funktionsgruppe „Komplexe Funktionen:
Als Beispiel dazu der Funktionsteil „readfile“.
Der Funktion „readfile“ übergeben wir den Dateinamen und den Speicherbereich in dem wir die gelesenen Daten ablegen möchten. Die Funktion tut nun das Folgende:
- Rufe „fgetstart“ -> Der Startsektor der Datei ist nun bekannt. Falls die Datei nicht existiert, wir Null zurückgegeben.
- Lese 125* Datenbytes ab dem ermittelten ersten Sektors in den Buffer.
- Rufe „fgetnext“ -> der nächste Sektor ist nun bekannt. Wird Null zurückgegeben, dann war das der letzte Datensektor der Datei.
- Lese 125* Datenbytes ab dem ermittelten Sektor und fahre ab Schritt 3 fort.
Das War’s DOS 2.x macht es nicht anders……
DOS= Disk Operating System:
Das DOS – oder genauer: Das (F)ile (M)anagement (S)ystem des Atari DOS – hat die Aufgabe die Sektoren einer Diskette geordnet nach Datei- Namen zu verwalten. Dazu legt das DOS drei wesentliche Datenstrukturen an. Die erste ist das schon erwähnte „Directory“. Die zweite Struktur ist die „Volume Table of Contents“ die VTOC und die Dritte der Datensektor selbst.
Das Directory identifiziert die Dateien eindeutig, enthält den Status einer Datei, den Starsektor und die Anzahl der Sektoren die die Datei auf der Diskette belegt. Die VTOC gibt Auskunft über die Anzahl der verfügbaren Sektoren, der belegten Sektoren und zeigt für jeden Sektor auf der Diskette ob er belegt oder frei ist. Der Datensektor selbst enthält die Daten der Datei und Informationen darüber, wieviele Bytes des Sektors für Daten genutzt werden, die Nummer der Datei zu dem die Daten gehören und schließlich den Zeiger auf den nächsten Datensektor der zur Datei gehört (Steuerbytes. In diesem Fall 3=3 x 8 Bit=24 BIT). Enthält der Zeiger auf den nächsten Sektor eine „0“, handelt es sich um den letzten Sektor der Datei.
Ausgabe der VTOC einer DOS 2.x formatierten Diskette.
Die VTOC besteht im wesentlichen aus 90 Bytes. Jedes Bit repräsentiert einen Sektor (90 x 8=720 mögliche Sektoren). Bit gesetzt bedeutet: Sektor frei.
Eine Kleine Einschränkung: Einen DOS 2.x Emulator kann und will sich die angestrebte Funktionssammlung für die Programmiersprache „C“ nicht nennen . Das DOS welches auf der original Hardware eines Atari Computers läuft, ist wesentlich umfangreicher und komplexer. So kann das original DOS bis zu 8 Laufwerke und in der Summe max. 8 geöffnete Dateien verwalten. Weder das letztere noch die damit zusammenhängende Verwaltung des RAM- Speichers leistet die beschriebene Funktionssammlung. Ziel des Projektes ist es lediglich die wichtigsten Teile des DOS 2.x in C abzubilden um Disk Image- Files auf MAC OS oder, einer beliebig anderen Platform , ohne den „Umweg“ über einen Emulator bearbeitbar zu machen.
Tiefer Einblicke zum original DOS gewährt das (Standard?)Werk: „Inside Atari DOS“ .
*Jeder Sektor einer im single density Format formatierten Diskette kann mit 128 Bytes beschrieben werden, Jeder Sektor einer im double density Format formatierten Diskette kann mit 256 Bytes beschrieben werden. Nach Abzug der 3 Steuer- Bytes bleiben jew. 125/ 253 Datenbytes übrig.
Die Disketten des Atari, Dos und Co.
Aktuell versuche ich mich daran einige grundelgende Atari Dos 2.x Routinen in C zu entwickeln. Grundlage: Das bekannte ATR- File Format. Letzteres enthält, bis auf einige Header- Bytes, die Rohdaten einer Atari Diskette.
Den Aktuellen Stand meier Bemühungen findet man da: main.c 17.52.25
Anmerkung: Ich lerne noch! Eine der wichtigsten Fragen: Wie bestimme ich große einer Datei unter Mac OS X in C?
Im Folgenden einiges zur Organisation einer Disk im Dos 2.x Format.
Directory
- Ab Sektor 361
- 8 Sektoren lang
Jeder Eintrag ist 16 Bytes lang und hat die Folgende Struktur:
- Byte 0: Flag
- Byte 1+2: Sektor Count. Filegröße in Sektoren (Low + High Byte)
- Byte 3+4: File Start. Erster Sektor des Files
- Ab Byte 5: File Name
Atari Dos 2.x Objekt File Format
…Objekt Files werden oft auch als „Binär Files“ bezeichnet und lassen sich über die Dos Shell (Das DUP.SYS) über den Menübefehl „L“ laden und ausführen.
Haben wir uns schon einmal gefragt, woher die Laderoutine weiss, wo im Speicherbereich das Programm abgelegt und dann gestartet werden soll? Ja?
Jedes Objekt File beginnt so:
$FF, $FF Immer!
Start Adresse Low + High Byte
End Adresse Low + High Byte
Es folgen n (Endadresse – Startadresse +1) Datenbytes.
Das war’s
Wer sich für den Boot Sektor interessiert, der findet hier im Blog mehr.
Quelle: Atari Profibuch (ABBUC e.V. )
Viel Spass!
RetroZock 