m: Weg mit dem nutzlosen Plunder…

Nach einer kreativen Pause nun weiter in diesem Film. Die letzten Tage habe ich mich intensiv jenen m-Funktionen gewidmet, mit welchen ich Quelltexte auf dem Massenspeicher bearbeiten, verwalten und auszuführen/compilieren kann. Geplant waren eigentlich FAT16/32-Containerdateien für ein Blockinterface. Diesen Plan habe ich aber aus verschiedensten Gründen verworfen. Ein gravierender Grund ist die fehlerhaften seek-Funktion, die relativ geringe Performance des FAT-Layers und der enorme Speicherverbrauch in Administra. Ganz nebenbei hat mich schon lange die mit FAT32 einhergehende Komplexität gestört. Es ist wie mit vielen Dingen im Computerbereich, die uns das Leben bequem gestalten: Diese Bequemlichkeit wird durch Komplexität erkauft, welche dann irgendwann immer schwerer beherrschbar ist.  Ein einfaches Blockinterface dagegen gibt alle Freiheit aber auch die Verantwortung die Daten selbst zu strukturieren. Wie man nun sinnvoll in einem solchen System Daten strukturiert, ist ein kleines Abenteuer für sich und wird mir wohl noch einige Ideen abverlangen. Genau das  richtige Experimentierfeld, um langweilige Abende zu füllen. Also frisch ans  Werk und weg mit dem komplizierten Plunder… 😉

m6m7m8

Nun, wenn ich zu einem Entschluss gekommen bin, dann geht es meist sehr schnell. So habe ich einfach den kompletten Administra-Code von mental „entkernt“ und ein neues Screeninterface implementiert. Und ich bin sehr mit dem Ergebnis zufrieden! 🙂 Nicht nur das dieses neue Interface eine sehr flache Struktur hat, es ist natürlich durch die geringe Komplexität auch sehr schnell! Nach einigen Stunden Arbeit kann ich nun schon Quelltexte  bearbeiten, verwalten und compilieren, dass es eine wahre Wonne ist! Der Editorcode in Bella ist noch nicht perfekt, aber ich verändere ihn  stückweise, bis er meinen Vorstellungen entspricht. Da ich ja nun die ersten Quelltexte direkt auf dem Hive bearbeite, habe ich dann auch noch
schnell einen Kopierpuffer und eine Copy/Past-Funktion im Editorcode eingefügt.

Was habe ich sonst noch implementiert: Bei einem Sytstemstart wird Screen 0 als Autostartfunktion automatisch geladen/ausgeführt/compiliert. Zusätzlich hat Administra einen 32 Level Screenstack erhalten, so dass auch verschachtelte load-Funktionen korrekt bearbeitet werden und es wird automatisch ein Workbereich beim Systemstart compiliert. Momentan habe ich die ersten 16 Screens als Bereich für die Konfiguration und als „Bootscript“ reserviert. Was passiert nun aber, wenn man in einem solchen Screen einen Fehler einbaut, welcher dann schon beim Systemstart
zu einem unbenutzbaren System führt? Ganz einfach: Karte ziehen, Hive neu starten und das Grundsystem meldet sich nach einem „r/w error“ mit seinem normalen Prompt. Nun kann man das Medium manuell mounten und den Fehler beheben. Cool, gefällt mir sehr gut und man kann schon richtig mit dem System autark ohne Host arbeiten und programmieren!

Neben der wirklich rasanten Geschwindigkeit, schlägt sich die Umbaumaßnahme auch im Speicherverbrauch wieder: der grundlegende  Administra-Code mit Screeninterface und Parser ist nicht mal 4 KByte groß. Alle weiteren Routinen müssen nun natürlich an ein Raw-Blockinterface angepasst werden, aber dafür ist eine Parallelisierung wahrscheinlich ohne große Probleme möglich. So sollte es kein Problem sein, dass die Wave- oder SIDCog-Routinen parallel zum mental-Core auf den Datenträger zugreifen. Gerade dieser kleine Speicherverbrauch wird dem Administracode gut tun, da ja noch COM, Sound und LAN-Funktionen fehlen, die ebenfalls ihren Speicher brauchen und in einer COG parallel laufen wollen.

Zur Dokumentation des aktuellen Arbeitsstandes drei Bildschirmfotos:

  1. Bootvorgang: Nach einem Reset wird automatisch Screen 0 vom Datenträger abgearbeitet. Was sich auf diesem Screen befindet ist ganz dem  Benutzer überlassen. Aktuell habe ich dort eine Willkommensmeldung inklusive Ausgabe des freien Speichers geskriptet, sowie die Definition einiger Strukturkonstanten und die Ladeanweisung für die Workscreens definiert. So werden automatisch nach einem Reset die experimentellen Spracherweiterungen compiliert und stehen sofort zur Verfügung. Praktisch, so kann man schnell neue Worte entwerfen und testen.
  2. Workscreen: Wird aktuell automatisch beim Sytemstart compiliert. Einige Anweisungen werden wohl noch ihren Weg in den Grundwortschatz finden, andere werden letztlich in Modulen landen, die bei Bedarf nachgeladen werden.
  3. Ausgabe von Indexzeilen als Ersatz für ein Verzeichnis. Ohne FAT16/32-System muss man sich seine Daten auf dem Datenträger selbst organisieren – was viel Verantwortung, aber auch Freiheit mit sich bringt. Momentan unterteile ich die Screens in mehrere Metaebenen (Projekte/Module/Work) um die Daten zu strukturieren.

Ich habe einige Zeit mit mir gerungen, um statt mit einem FAT-Dateisystem mit dem Datenträger in einer viel direkteren Form zu arbeiten, aber diese Form mit den Ressourcen umzugehen hat seinen ganz eigenen Reiz. Im ersten Moment war der Verzicht auf FAT sicher schmerzhaft, aber letztlich habe ich ein gutes Gefühl bei diesen Umbaumaßnahmen, da Einfachheit letztlich durch nichts zu ersetzen ist.

Bleibt ein letztes Problem: Wie übertrage ich Daten zwischen dem Host und dem mental-System? Der Plan sieht vor, dass in Administra eine passendes Kommunikationsmodul läuft, um per XModem oder einem anderen Protokoll Daten vom Host zu empfangen und auf SDCard im Blockformat zu speichern. Die mental-Medien selbst können dann als Image auf dem Host gespeichert und kopiert werden. Wie man das mit einfachen Worten steuert, muss ich mal überdenken.