Wie alles anfing

Faszination Retrocomputer: Wir bauen uns einen Computer. Nein, nicht so eine schnöde Kiste mit Standardkomponenten aus dem Handel, mit Gigabytes und Gigahertz, mit verkrusteten Monsterbetriebssystemen und gigantischen Verteidigungslinien wie Firewall und Antivirus – die sind einfach nur langweilig, unkreativ und die Ursache für einen nahen Hirntod… Nein, wir bauen uns einen niedlichen kleinen Minicomputer, eine komplette Eigenentwicklung: Eine Hand voll Schaltkreise sollte genügen. Und natürlich ein nettes und schlankes Betriebssystem. Frei nach dem alten Motto: Genial einfach, einfach genial.

Der Hive

  • 3 x Parallax Propeller P8X32
  • 24 RISC-Prozessoren
  • 80 MHz Systemtakt
  • 1 MByte externer RAM
  • VGA-Anschluss
  • Videoausgang
  • Stereo-Sound
  • SD-Card Laufwerk bis 2 GByte (onBoard)
  • PS/2 Keyboard und Maus
  • Erweiterungsbus
  • Hostport zum PC
  • Netzwerkkarte
  • Eurocard-Format

 

img_0186.jpg img_0193.jpg img_0194.jpg img_0195.jpg img_0196.jpg img_0200.jpg img_0205.jpg img_0206.jpg

So oder ähnlich dachte ich vor einigen Wochen als ich vor Langeweile anfing meinen Keller aufzuräumen und mit feuchten Augen einen alten Atari 800 XL zum Leben erweckte. Irgendwer hatte ihm bei der Aufrüstung des Arbeitsspeichers die Chips zerschossen. Mangels passender Ersatzschaltkreise baute ich kurzerhand ein altes SIM-Modul ein – und siehe, er erwachte tatsächlich wieder zum Leben. Schnell noch die Datasette aus dem Haufen geklaubt; da war doch noch diese Schachtel mit den alten ORWO-Kassetten und schon bald flimmerte und musizierte der kleine Kerl vor sich hin. Ein paar Zeilen Basic eingetippt – was man noch so in verstaubten Schichten des Gehirns finden konnte – und gleich flitzten geschäftig Zahlenreihen über den Bildschirm. Selbst ein Atmas-II-Assembler fand sich noch samt einiger verwegener Listings (ich sah da einen Treiber um über RS232 auf einen ST bzw. seine Festplatte zugreifen zu können).

Genau das war wohl der Augenblick als ich dachte: „Was wäre wohl heute möglich? Könnte man ein solches Gerät heute mit einfachen Mitteln selbst entwickeln?“ Mein letzter wirklicher Eigenbaucomputer lag viele Jahre zurück, muss wohl so in den 70er Jahren gewesen sein. Erst ein Versuch mit einem U808 Prozessor und kurz darauf das erste funktionstüchtige Gerät mit einem U880 (Z80-Clone). Es folgten die tollen CPUs von Motorola und solche Exoten wie der Hitachi H4. Ich glaube zu dieser Zeit habe ich das meiste über diese Technik gelernt und meine Fähigkeiten alles Technische zu zerlegen um die unschätzbare Möglichkeit erweitert, auch wieder (fast) alles funktionierend in Gang zu setzen… 😉

Zugegeben, eine gehörige Prise Nekromantie ist schon dabei, in der heutigen Zeit eine solche Bastelei anzugehen, aber ich wollte mit dem fertigen Gerät ja auch nicht die Marktmacht erringen oder ähnliches. (Obwohl natürlich, wenn ich jetzt noch das Ethernet Modul integriere und einen Lynx-ähnlichen Browser mitliefere, stehen die Chancen vielleicht gar nicht schlecht… 😉 Aber eines sollte dem Besucher dieser Seite klar sein: Der Weg ist das Ziel! Wer das irgendwie mental nicht auf die Reihe bekommt, liest am besten nicht weiter. Und bitte keine nervenden Fragen, warum ich nicht einfach das billige Board von Händler X samt CPU und RAM nehme – das ist ja tausendmal schneller als diese Kiste und kostet nur ein Bruchteil. In einem solchen Falle einfach hierher LINK oder dorthin LINK wechseln und den Link zu meiner Webseite unbedingt aus den Favoriten löschen. Am besten noch den Browsercache leeren und diese Adresse in die Blacklist der Antivirensoftware übernehmen, damit ich meine Ruhe habe.

Wo waren wir gleich noch, ach ja: Der Weg ist das Ziel. Nach den ersten paar Wochen stand die Kiste fast fertig auf meinem Tisch und geordnete Zeichenfolgen flimmern über den angeschlossenen Monitor, eine Tastatur und Boxen sind angeschlossen. Ich muss gestehen, dass ich die letzten Jahrzehnte kaum soviel Spaß daran hatte etwas zu basteln, wie in dieser Zeit. Aber fangen wir mal ganz am Anfang an – genau: Im Keller bei dem alten Atari!

Ein wenig Software ist auch schon fertig wie man hier sehen kann. Zugegeben, etwas rudimentär, aber durchaus geeignet für weitere Entwicklungen. Weitere Videos:

Hier ist der Busmonitor in Aktion zu sehen – eine Aufsteckplatine um die Bussignale zwischen RAM und den Propellern anzuzeigen.

Was wollte ich eigentlich bauen? Eines war mir klar: Es muss eine Art Minimalcomputer werden. Keine riesigen Materialschlachten. Und es sollte alles mit den üblichen Hausmitteln eines Technikers zu bewältigen sein – keine exotischen, sondern überall verfügbare und vernünftig lötbare (also bedrahtete) Bauelemente. Für solche Experimente verbietet sich bei mir dann immer eine fertige Platine, muss alles auf Lochrasterboards gehen für so einen Prototyp. Also habe ich vorsorglich die Kataloge von Reichelt und Co. entstaubt. Ein weiterer Gedanke war die Erweiterbarkeit – das ist immer wichtig bei solchen Projekten – und Grundbedingung für die spätere Weltherrschaft. 😉 Aber das war zu diesem frühen Zeitpunkt schon eine recht abstrakte Forderung. Fest stand allerdings, dass alles – sowohl Hard- als auch Software – soweit wie möglich, selbst entwickelt werden sollte.

Die Auswahl des Systems: Spätestens hier machte sich ein Stachel aus früheren Zeiten in meinem Fleisch bemerkbar. Vor Schmerzen drehte sich alles vor meinen Augen wie ein Propeller! Genau, da gab es doch diesen überaus genialen Propeller-Chip von Parallax, mit dem ich immer schonmal etwas basteln wollte. Bisher hatte leider kein Problem die nötige finanzielle Schwelle überwunden, um mir mal eines der verfügbaren Demoboards anzuschaffen. Zum damaligen Zeitpunkt wusste ich leider noch nicht, dass dieser Chip wirklich so genial ist und man solch ein Board überhaupt nicht braucht. In der Realität habe ich mit dem Demoboard auch wirklich nur einen Tag rumgespielt, um mich anschließend sofort mit dem Lötkolben auf die einzelnen Prop Chips zu stürzen.

Aber langsam, da gab es immer noch diesen seltsamen Schmerz wenn ich an den Propeller dachte, und der Stachel im Fleisch hatte zwei Enden wie ein ekliger, kleiner Widerhaken: Auf der einen Seite besitzen die Props wirklich viele Ressourcen (mit wenigen Widerständen ist PS/2-Keybard, Maus, VGA-Monitor oder Fernseher und Sound angeschlossen), aber auf der anderen Seite haben diese Teufelsschaltkreise doch irgendwie verdammt wenig Ressourcen (vor allem RAM), um als richtiger Computer durchzugehen. Ich grübelte mehrere schlaflose Nächte: Sollte ich einen „dicken“ Prozessor zu dem Prop gesellen, um darauf ein Hostsystem laufen zu lassen? Das passte mir irgendwie nicht zum Konzept eines einfachen und minimalistischen Computers. Fremdprozessoren waren einfach feige, da konnte ich grübeln wie ich wollte! Die reine Lehre bestand für mich irgendwie darin, nur mit dem Propeller-Chip auszukommen.

Was konnte eigentlich so ein normaler Prozessor was ein Prop nicht konnte? Das war doch die Frage! Ich glaube, eine entscheidende Philosophie für den Gebrauch der Propeller ist es, Hardware durch schnelle Software, die auf noch viel schnelleren RISC-Prozessoren läuft, zu ersetzen. Warum also verwende ich für den Retrocomputer nicht einfach mehrere Propellerchips, von denen einer die Funktion eines Hostprozessors mit mehr RAM übernimmt? So ein wenig relativ dummer Arbeitsspeicher als Zusatzbaustein konnte nicht gegen die reine Lehre verstoßen, hatte ich das Gefühl. Zumal es recht kompakte Schaltkreise mit entsprechender Bitbreite problemlos heut auf dem Markt gibt. Drei Props – das schien mir intuitiv die richtige Anzahl für solch ein Projekt. Ein Prop übernimmt alle Benutzerschnittstellen (Monitor, Tastatur, Maus). Eventuell kann er auch komplexere Aufgaben wie Menüstrukturen autark verwalten und bearbeiten. Ein weiterer Prop ist für die Gerätesteuerung zuständig (SD-Card-Laufwerk, Sound, LAN, Schnittstelle zu weiteren Props). Diese beiden Schaltkreise besitzen zwar für sich eine gehörige Eigenintelligenz, aber verrichten ihre Arbeit unter dem Regime des dritten Chips, der gleichzeitig auch als Host Zugriff auf den externen Ram hat. Einzig auf diesem dritten Propeller laufen die eigentlichen Anwenderprogramme.

Weil ich mir einbilde eine poetische Ader zu besitzen, verpasste ich allen Propellern einen Namen – Bellatrix, Administra und Regnatix. Solche Namensgebungen sind schließlich eine ausgestorbene Tradition bei meinen alten Nostalgiecomputern. Antic, Pokey, Tom und Jerry klingen mir da noch so in den Ohren… Regnatix also ist die Königin in dem System und steuert Bellatrix und Administra. Außerdem sollte der Host noch ausreichend RAM bekommen, möglichst statischen Speicher und gleich mit 8Bit-Datenbreite, um die Ansteuerung und Verdrahtung zu vereinfachen. Ich schaute also nach, was momentan auf diesem Gebiet so Mode ist, und empfand schicke 512 KByte statische Rams mit 8 Bit Datenbreite eine angemessen Größenordnung. Vor Freude sah ich gleich zwei Bänke vor, um auf eine glatte Speichergröße von 1 MB zu kommen – klingt doch wirklich ganz nett für einen Prop oder?

Der Bus: 1 MB RAM ergeben 20 Adressbits. Um unnötige Hardware für die Adressdekodierung der beiden Bänke zu vermeiden, sah ich an Regnatix zwei Ausgänge (/RAM1, /RAM2) zur Selektion vor. Die jeweilige Speicherbank muss also von den RAM-Routinen per Software ausgewählt werden. Bleiben also noch 19 Adressbits, was eindeutig zu viel für Regnatix ist. Damit entschied sich, dass der Adressbus noch durch ein 8 Bit-Latch für den höherwertigen Teil entlastet werden muß. Angesteuert wird das Latch auch per Software direkt von Regnatix über das Signal /AL. Den alten Plan, Bellatrix und Administra über eine serielle Schnittstelle an Regnatix zu koppeln, ließ ich bei der Portaufteilung fallen: Da genug I/O-Leitungen vorhanden waren, wurden alle Props wie die RAMs über einen parallelen 8 Bit-Datenbus gekoppelt. Für jeden Slave Chip gibt es ebenfalls ein entsprechendes Selektionssignal (/PROP1, /PROP2) und korrespondierend dazu an jedem Slave einen Eingang (/SELECT). Um alles auf dem Bus geordnet ablaufen zu lassen definierte ich ein Bustakt (BUSCLK), welcher von Regnatix generiert wird. Letztlich gibt es noch ein Schreibsignal (/WR) für RAMs und Props. Da die Reaktionszeit der Slave Schaltkreise nicht definiert ist, muss durch diese eine Quittung (/HS) erfolgen.

Da die Ausgänge der Propeller keinen Tri-State-Modus zulassen bedarf es einer genau definierten Choreographie der Signale. Es ist zu beachten, dass ein Programmfehler durchaus nicht nur zu einem logischen Buskonflikt führen kann, sondern auch Ausgänge die dauerhaft gegeneinander arbeiten beschädigt werden können.

Bussignale, Betriebsspannungen und verbleibende I/O-Ports von Administra und Bellatrix werde ich letztlich auf einem Erweiterungsbus zusammenfassen.

ram_write.jpgram_read.jpgprop_write.jpgprop_read.jpg

Software: Als Betriebssystem hatte ich am Anfang nur einen Gedanken: Forth. Ich wollte schon immer einen Computer bauen der Forth als Betriebssystem besitzt, und irgendwie passt die Philosophie von Forth auch zu den Propellerchips – schon alleine weil beide so schön esoterisch sind. 🙂 Außerdem erspart man sich mit Forth so einige Mühen: Da ist gleich ein System mit einer Scriptsprache, mit Massenspeicher, mit Compiler und überhaupt… So dachte ich damals, als ich noch kein Spin kannte. Davon aber später mehr.

Zumindest standen jetzt die groben Eckdaten des Computers fest:

  • 3 x Parallax Propeller Prozessor
    • Regnatix – Hostsystem, Systembus, RAM-Anbindung
    • Administra – Sound, SD-Card-Laufwerk, LAN
    • Bellatrix – Grafiksubsystem, Keyboard, Maus
  • 80 MHz Systemtakt
  • 1 MByte externer RAM
  • VGA-Anschluss
  • Videoausgang
  • Stereo-Sound
  • SD-Card Laufwerk bis 2 GByte
  • PS/2 Keyboard und Maus
  • 8 Bit Erweiterungsbus
  • Hostport zum PC
  • Netzwerkkarte

Man stelle sich das mal vor: Man ist Gebieter über einen Schwarm von 24 RISC-Prozessoren die man nach Lust und Laune verbraten kann, um einem Minicomputer Leben einzuhauchen. Das ist schon eine verrückte Basis für ein kleines Bastelprojekt. Und mal ehrlich – für ein textbasiertes Betriebssystem ist ein Zusatzspeicher von 1 MByte doch auch eine mehr als ausreichende Größe. Wer würde im Angesicht eines blanken Propellers schon an solche Dinge wie eine RAM-Disk oder eine ausgewachsene Textverarbeitung denken? Mit dieser Konfiguration ist das kein Problem mehr: Die meisten lästigen Aufgaben sind in die zwei Slave-Chips ausgelagert, und die 32 KByte Hub-RAM stehen vollständig für Software oder Softwaremodule zur Verfügung. Ein Traum für jeden Techniker, selbst so ein Schluderjahn wie ich konnte damit etwas sinnvolles zustande bringen. Bei dem Gedanken hatte ich auch gleich einen passenden Namen für den Computer parat: Hive – wie ein Bienenkorb oder ein Ameisenbau, ein Nest voller Einzelindividuen die eine fette Königin (Regnatix) umsorgen.

An die Arbeit: Der Plan war also gefasst. Ich entwarf grob die Schaltung, wälzte einen Abend Kataloge und bestellte ein Propeller-Demoboard, drei einzelne Propellerchips und eine paar weitere Teile, die ich nicht in der Bastelkiste hatte (RAMs, Adresslatch, Quarze, EEPROMs und das Gehäuse). Bis die Ware eintraf, überdachte ich genau die Signalbelegung für alle Props und die Busprotokolle für den Datenaustausch zwischen Regnatix, RAM´s sowie den beiden Slave-Propellern.

<I/O-Belegung der Propellerchips >

pinout.jpg r13-schalt1.jpg r13-schalt2.jpg r13-schalt3.jpgr13-schalt3.jpg

(Die Schaltpläne sind nicht vollständig, sondern repräsentieren einen Entwurf vor der praktischen Realisierung. Das Gerät selbst funktioniert fantastisch, aber die fertige Schaltung hat diverse kleinere Veränderungen erfahren, die ich zur gegebenen Zeit einarbeiten werde.)

Als die Ware endlich geliefert wurde, verschwand ich für eine Woche im Keller. 🙂 Glücklicherweise ergab es sich, dass ich den geplanten Jahresurlaub mit meiner Frau nicht antreten konnte, worüber ich zu ihrer Überraschung nicht wirklich traurig war – so hatte ich eine ganze Woche Zeit, der reinen Technikerlust zu fröhnen. Einen Tag verbrachte ich mit dem Demoboard – ich hätte es nicht wirklich bestellen brauchen. Allerdings ist ein ordentliches Handbuch nicht zu unterschätzen, und wer kann schon sagen, was mir noch alles zu den Props einfällt. Für kleine lötfreie Experimente ist es wirklich eine gute Sache.

img_0158.jpg img_0159.jpg

Aber es drängte mich jetzt wirklich dem Hive erstes Leben einzuhauchen. Bellatrix machte den Anfang, da der Erfolg dort durch VGA und Keyboard am schnellsten sichtbar wurde. Etwas Bedenken hatte ich noch wegen der Interfaceschaltung zum Host, aber auch diese Zweifel zerstreuten sich schnell, als die erste LED am Prop blinkte. Monitor, Keyboard, Maus war schnell auf der Experimentierplatine verdrahtet.

 

img_0161.jpg img_0163.jpg img_0165.jpg

Dann folgte Administra und nicht viel später gab es den ersten Sound. Am Hostinterface kann ich durch einen Schalter (DIP-Switch) den entsprechenden Prop wählen, der vom PC aus programmiert werden soll. Später ersetzte ich den DIP durch einen Schiebeschalter und machte ihn an der Rückseite des Gehäuses zugänglich.

 

img_0166.jpg img_0167.jpg img_0168.jpg img_0169.jpg img_0170.jpg

Die nächste Hürde war Regnatix und der Bus zu den anderen Props. Aber auch das entpuppte sich als eine leichte Übung: Nach kurzer Zeit empfing der Host die Tastatureingaben von Bellatrix und konnte Zeichen zum Screen senden – der Bus und die entsprechenden Protokolle funktionierte wie geplant. Einzig die Busvedrahtung per Kupferlackdraht zwischen den Props und den externen Rams erforderte echte Fleißarbeit – da ist Durchhalten angesagt. Für die ersten Tests habe ich noch eine Aufsteckplatine für Regnatix gebastelt, um mit LED´s Daten-, Adress- und Steuerbussignale anzeigen zu können. Ich liebe wirklich diese kleinen massig blinkenden Gizmos wenn alles funktioniert. 🙂 Mit Spin ist es ein Kinderspiel solche Sachen zu testen, die Hardware kann man im Einzelschritt dann bequem mit der Busanzeige beobachten und analysieren.

Mittlerweile sammelten sich die ersten Softwarehalden mit den Busroutinen, um die Kommunikation zwischen den Props und den Zugriff von Regnatix auf den externen RAM zu realisieren. Der RAM Test war beim ersten Versuch erfolgreich.

Als letztes blieb mir noch den SD Karten Laufwerk  anzuschließe – typisch für den Propeller ohne Probleme. Verzichtet habe ich vorerst auf den Videoausgang (mangels eines kleinen TV-Monitors zum testen) und die Ethernet-Schnittstelle, aber diese steht ganz oben auf der Wunschliste, da ich schon immer auf unterer Protokollebene mit TCP/IP arbeiten wollte. Vorerst erklärte ich den Prototypen bezüglich der Hardware als nahezu fertig und erledigte die letzten mechanischen Arbeiten (Aussparungen und Halterungen am Gehäuse), um endlich aus einem Drahtverhau ein fertiges Gerät entstehen zu lassen.

Die Software: Bei den Hardwareexperimenten war die Software vergleichbar einem Gestrüpp gewachsen. Alles hatte mehr oder weniger den Status einer Testsoftware, um irgendwelche schaltungstechnischen Details während der Lötarbeiten zu prüfen. Nun war also die Zeit gekommen, auch hier Ordnung einziehen zu lassen. Für Belatrix und Administra schrieb ich eine Art BIOS, welches komplett aus dem EEPROM gebootet wurde. Nach dem Bootvorgang lauschten beide Bienchen am Bus, ob irgendwelche Kommandos von Queen Regnatix gesendet wurden, um diese auszuführen.

 

img_0175.jpg

Das System in Regnatix ist flexibler gestaltet: Momentan benutze ich lediglich zwei COGs (als COG wird ein RISC-Prozessor im Propeller bezeichnet; acht derartige COGs sind in jedem Chip) für das Hostsystem – da ist also noch mehr als genug Reserve vorhanden. In einer COG läuft der sogenannte Loader des Systems, die weiteren COGs sind frei für die Anwendungen. Der Loader hat folgende zentrale Aufgaben:

1. Verwaltung des Heaps: Der Heap ist ein möglichst großes Bytearray, in welches der Loader BIN-Dateien von der SD-Card laden und diese in einer weiteren COG zur Ausführung bringt. Da der Loader selbst sehr klein ist, bleibt für den Heap, und damit für die Anwenderprogramme, ca. 31900 Byte interner Programmspeicher. Die BIN-Datei ist dabei ein ganz normales kompiliertes Spin Objekt, welches in den Heap geladen und dann in der zweiten COG gestartet wird. Der Loader selbst bleibt nach dem Start in der COG-0 aktiv, deaktiviert aber seinen gesamten Zugriff auf den externen Bus, um nicht in Konflikt mit der Anwendung zu gelangen. Während das Anwenderprogramm in der zweiten COG abgearbeitet wird, wartet der Loader auf ein Steuerkommando um weitere Ladevorgänge auszuführen. Das klingt etwas verwirrend, aber man muss sich bei den Propellern Chips daran gewöhnen acht separate Prozessoren (COGs im Parallax-Vokabular) zur Verfügung zu haben.

2. Systemstart: Beim Einschalten des Rechners gibt der Loader Administra den Befehl die Datei „sys.bin“ von SDCard zu übertragen und kopiert diese in den Heap, um sie dann in der zweiten COG zu starten. Im Normalfall enthält diese Datei dann einen Kommandozeileninterpreter oder eine andere Benutzeroberfläche. Es ist aber auch denkbar, in dieser Weise ein beliebiges anderes Anwenderpogramm zu starten. Lediglich die Datei „sys.bin“ muss dafür geändert werden.

3. Programm Loader: Ist eine Anwendung geladen und gestartet, kann diese dem Loader zur Laufzeit den Befehl geben, eine andere BIN-Datei zu starten. So kann z.B. die Kommandozeile externe Kommandos einfach von SDCard starten. Wird eine Anwendung beendet, so kann sie mit der IOS-Funktion „ios.ldsys“ einfach wieder „sys.bin“ laden und fortsetzen. Bekommt der Loader ein Kommando, so beendet er momentan alle anderen COGs und startet das neue Objekt. Für spätere Erweiterungen ist es denkbar, dass über einen globalen Parameter im eRAM, ausgewählte COGs nicht beendet werden und so als residente Dienste oder Programme arbeiten.

Während der Heap also vom Loader bei jedem Ladevorgang mit einer neuen Anwendung (oder einem Anwendungsmodul) belegt wird, steht der externe RAM unangetastet für die Anwendungen selbst zur Verfügung. Programme könnten so in Module aufgeteilt werden. Als weitere Funktion des Loaders wird also noch ein Teil folgen, um den externen RAM zu verwalten und Konflikte zwischen Anwendungen zu vermeiden.

Die ios.spin ist ein Objekt mit allen nötigen Routinen, um mit den Ressourcen des Hive umgehen zu können, also eine Art Funktionsbibliothek, welche ich für das Hive-System erstellt habe. Momentan gibt es eine minimalistische Kommandozeile, diverse Tools und iSpin.

iSpin – ist der aktuelle Rest vom Forth und alles andere als fertig. 😉 Letztendlich ist es ein in Spin programmiertes System mit einer Forth ähnlichen Struktur und besitzt einen experimentellen Charakter.

Ursache ist die verführerische Einfachheit von Spin. Um ganz ehrlich zu sein: Ich habe noch nie so einfach und mit einer solchen Leichtigkeit und Freude einen Mikrokontroller programmiert. Ich finde, das Propeller-Tool ist eine wirklich geniale Software. Die Assemblerprogrammierung hebe ich mir einfach für später auf, in dieser Beziehung ist der Propeller ja auch eine geniale Maschine.

Dennoch brauche ich für den Hive vorerst eine interaktive Programmiersprache – als Scriptsprache oder um zum Beispiel einen Assembler zu schreiben. Geschwindigkeit ist dabei sekundär. Zwar habe ich schon so einiges in Forth geschrieben, aber von dem „Getriebe“ habe ich mich immer fern gehalten. Ein wirklich gutes Forth nativ in Assembler zu schreiben ist für mich schon ein wenig die hohe Schule, und so habe ich erstmal in Spin angefangen.

Über Forth wurde ja viel geschrieben und erzählt. Für mich ist Forth folgendes:

Forth ist ein ganzheitliches offenes Ordnungsprinzip für Computer. Forth ist ganzheitlich weil es ein Betriebssystem, Compiler, Interpreter und Scriptsprache ist, und alle diese Elemente selbst realisiert, verwaltet und erweitert. Forth ist also ganzheitlich, weil es alle Aspekte des zu ordnenden Mediums umfasst. Es gibt kein spezielles Forth. Forth kann zum Beispiel in Assembler oder auch in C oder halt auch in Spin geschrieben sein, aber man kann in Forth auch einen Assembler, C oder Spin schreiben. „Forth ist schnell“ gilt nur, wenn sich das Forth-Ordnungsprinzip direkt auf die Maschinenebene bezieht – das grenzt beim Propeller aber wirklich fast an Erleuchtung. 😉

Was zeichnet die Forth-Ordnungsstruktur aus?

1. Es gibt eine virtuelle Schicht von grundlegenden Basisoperationen (primäre Worte) die so einfach und universell wie möglich sind, um alle weiteren sekundären Wortbildungen zu beschreiben.

2. Alle Basisoperationen sind in einer Datenbank organisiert (Wörterbuch), welches durch Forth selbst verwaltet und erweitert werden kann.

3. Alle Parameterübergaben erfolgen über einen Stack.

Das ist eigentlich schon alles. Somit ist iSpin natürlich keine Rakete, aber dafür besitzt es den unschätzbaren Vorteil interaktiv zu sein. Als universeller Codegenerator ist iSpin ausreichend um einen COG-Assembler, oder vielleicht sogar einen Spin-Compiler zu schreiben. Wäre doch toll wenn man auf dem Hive ganz autark ohne ein Hostsystem Propeller programmieren könnte! Leider fehlen mir für einen Spin-Compiler noch die nötigen Informationen über den Token Code, aber vielleicht findet sich das auch noch.

Die Struktur von iSpin ist relativ einfach: Alle primäre Worte sind in Spin programmiert und befinden sich im Hub-RAM (hRAM). Das Wörterbuch befindet sich im externen RAM (eRAM). Damit ist natürlich mehr als genug Platz auch für größere Anwendungen. Bisher habe ich keine Ahnung ob das ganze schnell genug ist um es zu verwenden, aber das wird sich zeigen.

Wie geht es weiter? Nett wäre es eine ordentliche Platine zu entwickeln. Die Hardware ist ja wirklich relativ einfach. Mit einer I2C-Schnittstelle von Administra könnte man externe Propeller programmieren. Die nötigen Compiler, Interpreter oder Assembler vorausgesetzt, wäre es möglich ohne einen PC als Entwicklungssystem einzig mit dem Hive Software zu entwickeln – ob man das letztlich wirklich will, ist eine andere Frage. Aber wie gesagt: Der Weg ist das Ziel. Mit einer entsprechenden Platine wäre ein kleiner Hive-Notebook denkbar. Mit einem kleinen TV-Monitor werde ich noch einen entsprechenden Video-Ausgang einbauen und Bellatrix mit Routinen für die Grafikausgabe ausstatten. Was momentan fehlt sind halt so nette Killeranwendungen wie ein graphisch aufwendiger Soundtracker, Tempest oder ein Hive-Office… 🙂

Wichtig für eine sinnvollere Anwendung wäre auch noch eine Erweiterung des FAT16-Dateisystems für die SD-Karte, denn es fehlen Funktionen um mit Verzeichnissen oder mehreren Dateien umzugehen. Bei gängigen Größen von 2GB wird es ohne Verzeichnisse schnell unübersichtlich.