Mark Williams (C)

Ende der 1980er Jahre bin ich in die 16- Bit Welt aufgestiegen und habe mir einen Atari 1040 ST zugelegt. Die Sprache C war damals en Vouge und ausserdem recht sexy, das neue Atari Basic, nett ausgedrückt, langsam….

Der Compiler meiner Wahl war das in Deutschland von Markt und Technik vertriebene Mark Williams C. Nicht etwa lange Recherchen führten mich zum Kauf des recht kostspieligen Produktes, sondern seine Verfügbarkeit in meiner Heimatstadt.

 

Logo, Mark Williams Company. Quelle: Wikipedia, Copyrighted free use

Keine GUI, eine Bash ähnliche Shell ist die Kommandozentrale des Compilers. So kam es, dass mein erstes getipptes Unix/ Linux Kommando „ls“ ungefähr zwischen 1989 und 1990 in der Konsole landete. Unmittelbar danach habe ich meine ersten Gehversuche mit dem (micro)Emacs gemacht. Man sollte denken das mein Jüngeres ich sich davon hätte abschrecken lassen. Schließlich hatte ich meinen 8- Bit Atari eingemottet und dachte mit der Maus wird alles besser. Wäre dem so gewesen, dann wäre auch meine Geschichte hier zu Ende. Im Gegenteil, es war Liebe auf den ersten Blick!

Micro Shell – MSH

ST- MicroEmacs

Mark Williams ReSource Editor, der einzige GUI- Anteil im Paket. Ganz komfortabel die Benutzeroberfläche deiner App (sorry, .PRG) gestalten.

Ich werde diesen Artikel als Startpunkt für weitere, ausführliche recherchierte Fakten zum Mark Williams C nutzen. Bis hierhin erst einmal ein paar Dinge die ich bis jetzt gefunden, beziehungsweise eben nicht gefunden habe.

Da wäre zunächst einmal ein Funktionierendes Disk Image des Compiler’s. Gefunden habe ich das im AtariAge Forum, allerdings nicht vollständig. Die Shell und der Emacs laufen, der Compiler nicht:

Mark Williams C auf AtariAge (verlinkt am 7.7.2017)

Mein absoluter Wunsch und Traum, bis jetzt, wäre eine Original Ausgabe von Markt und Technik. Bis jetzt, blieb die Suche erfolglos.

Ein Ehemaliger angestellter der Mark Williams Company hat mit Erlaubnis seines ehemaligen Arbeitgebers den Source Code und einige Bücher der Firma online gestellt:

Mark Williams Company Sources, Stephen A. Ness  (verlinkt am 7.7.2017)

 

 

Werbung

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.

 

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:

1. Rufe „fgetstart“ -> Der Startsektor der Datei ist nun bekannt. Falls die Datei nicht existiert, wir Null  zurückgegeben.
2. Lese 125* Datenbytes ab dem ermittelten ersten Sektors in den Buffer.
3. Rufe „fgetnext“ -> der nächste Sektor ist nun bekannt. Wird Null zurückgegeben, dann war das der letzte Datensektor der Datei.
4. 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.

Näheres dazu hier im Blog

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

Life, as simple as it is…….

Der Ansatz war, Conway’s life endlich mal selber zu programmieren. Nun ja…

…welche Sprache darf’s den sein? Einfache Antwort: 6502 Assembler. Warum: lerne das seit einem Jahr und es läuft mir inzwischen recht locker von der Taste…… Aber, C wäre auch mal wieder nett gewesen.

Das Ergebnis:

Der Trick: Die einfache Anwendung der berühmten 3 Regeln von Conway alleine tut es nicht. Folgendes ist zu tun:

Man benötigt zwei Matrixen welche die Zellen enthalten. Man wendet die Regeln auf die erste Matrix an, schreibt das Ergebnis aber in die zweite ohne den Inhalt der ersten dabei abzuändern. Die Zweite Matrix enthält nun die erste Generation.

Nun löscht Man Matrix 1 und benutzt Matrix 2 als Eingabematrix. Das Ergebnis ist Generation 2. Das ganze wiederholt man nun so oft wie man möchte.

Den Source dazu gibt es hier:

Life.c

Das oben beschriebene ist mir mit meiner Version in 6502 Assembler leider noch nicht gelungen. Das Ergebnis läßt sich hier ansehen:

http://retrozock.com/2012/11/02/simple-life/

Programmier Sachen…. (6502, C und so…..)

Vom Wohnzimmer nach draußen in den Garten, nur mal kurz meine Buchhaltung erledigen, dann den Rechner zuklappen und in die Sonne liegen. Tja, bin  glatt abgedriftet im WWW. Ergebnis: Einige interessante Links :

• The Fridge
  6502 Assembler Source Code Sammlung, hauptsächlich für den C64http://www.ffd2.com/fridge/ 
• CC65
  Ein Cross Compiler für 6502 Maschinen. Source in C- entwickeln, das Ergebnis: 6502 Objekt/ Source. Läuft unter Dos, Linux und läßt sich für viele andere Host Plattformen Kompilieren.
  http://www.cc65.org/
  
  Die Seite enthält auch eine Link- Liste. Dort findet sich das Folgende Tutorial zum Programmieren in C:
  http://gd.tuwien.ac.at/languages/c/programming-bbrown/
  
  

Viel Spass beim ausprobieren 🙂

X-Code…

.…ist definitiv zu modern für dieses Blog.

Aber, scheinbar bietet diese Tool eine der wenigen Möglichkeiten auf einem modernen Mac zu programmieren (man möge mich korrigieren).

Zum Screenshoot:
http://yfrog.com/gy33ndp

Nachdem ich seit Januar 2012 wieder mit dem guten alten 6502 Assembler zu programmieren angefangen habe, bin ich jetzt doch etwas neugierig geworden und dachte mir, kann nicht schaden meine neu angelernten „Coding Skills“ auf eine neuer Platform zu transformieren. Anlass ist der Wunsch nach einem „Cross Assembler“ für den Mac.

6502 Code mit einem Tool auf dem Mac schreiben, direkt in den „ATARI Mac“ übertragen (als *.ATR) und austesten. Hmmmmm…. verlockend. Massig Platz für den Source Code.

Falls es das schon gibt, bitte melden 🙂

Atari Wiki

Das folgende zum Wochenende:

http://wiki.strotmann.de/wiki/

Unerschöpflicher Informationsquell, auch zum Thema 6502. Sehr krativ,  der Umgang mit den „unused opcodes“ des Prozessors. Schaut mal hier.

Des Weiteren wird geboten: Zeitschriften, Bücher und sonstige Artikel zum Thema. Passende Software gesucht? Bitte, wer einen exotischen Assembler sucht oder etwa ein lang veschollen geglaubtes Tool, der wird fündig. Kleines Beispie: der „PM Animator“ von Peter Finzel, ehemals im „Atari Magazin“ beworben. Ein passender Artikel dazu aus der allseits beliebten „Assemblerecke“ des Autors rundet das ganze ab. Großartig!