Irgendwann musste es ja so kommen: Auf dem Tisch ist kein Platz für zwei Hives und das ständige Umstöpseln nervt, wenn man zwischen der mentalen und der TriOS-Welt wechselt. Also muss ein Loader her, um TriOS bei Bedarf eine Gehirnwäsche zu verpassen – denn so ganz möchte man ja im mentalen Alltag auch nicht auf Boulder Dash und TriBorg verzichten…

Gesagt, getan! Mit dem kleinen Progrämmchen welches ich das Wochenende erstellt habe, kann nun einfach das mental-System unter TriOS gestartet werden. Ein wenig Vorarbeit war aber vorher noch nötig: Da mental ein blockorientiertes Dateisystem nutzte, um direkt auf den Datenräger zuzugreifen, war so ein Wechsel zur FAT16/32 Welt nicht so einfach möglich. Ein solcher direkter Zugriff auf den Datenträger ist zwar sehr schnell, einfach und leicht zu parallelisieren, aber auch völlig inkompatibel und erfordert so wieder komplexe Methoden, um Daten zwischen den verschiedenen Welten auszutauschen. Als stand schon recht frühzeitig die Frage im Raum, wie man zum Beispiel die mühsam programmierten Quelltexte sichern kann. Zwischenzeitlich habe ich einfach vom gesamten Datenträger (der SD-Card) ein Image gezogen, aber das ist auf der einen Seite recht langsam und auf der anderen Seite weckt die Frage „Datenträger formatieren?“ beim Einlegen der Karte doch ein komisches Gefühl… 😉 Aber ich bin ja durchaus manchmal ein Mensch des goldenen Mittelwegs: Also habe ich für mental das (m)ental (f)ile (s)ystem – kurz mfs – etabliert, welches eine praktische Schnittmenge zwischen den Vor- und Nachteilen der erschiedenen Welten darstellt.

Wie funktioniert es: mental nutzt nun sogenannte „Tapes“ als strukturierte Datenbereiche. Tapes sind im Prinzip zusammenhängende, unfragmentierte Datenbereiche auf dem Datenträger – quasi ein zusammenhängedes Band von Screens. mental kann auf der einen Seite direkt und blockweise in Form von Screens auf deren Inhalt zugreifen und auf der anderen Seite verschiedene Tapes über einen symbolischen Namen mit name use ansprechen, Screen 0 ist dabei immer der erste Screen des Tapes und die Tapegrenze kann nicht überschrieben werden, bzw. endet in einem Systemfehler. Das Wort tapes listet alle verfügbaren Tapes auf dem Datenträger auf. Unter TriOS und auf dem Host-PC sind die Tapes dank des FAT16/32-Frames von fsrw ganz normal als Datei sichtbar und können wie diese kopiert, gesichert und übertragen werden. Es ist einzig darauf zu achten, dass die Tape-Dateien immer fortlaufend und im Stück auf einen leeren Datenträger kopiert oder zusammengestell werden, damit sie nie fragmentieren, was im Extremfall zu Datensalat führt. Klingt etwas kompliziert, ist aber in der Handhabung sehr einfach und unkompliziert, wenn man das Prinzip verstanden hat: SD-Card leeren, dann einfach alle nötigen Tapes auf die Karte kopieren die benötigt werden. Zum Schluss noch die Systemdateien um TriOS zu starten und evtl. weiter Daten. Da die Daten auf dem Hive ja allsamt sehr klein sind , geht das alles sehr schnell. Also für mich fühlt sich momentan das Handling ziemlich gut an, da so eine recht praktikable und unkomplizierte Brücke zwischen den Welten geschlagen ist! 🙂

Wie geht es nun weiter mit mental: Momentan arbeite ich an einem Snapshot um die aktuell Version zu einem Paket zu schnüren und als Alphaversion zur Verfügung zu stellen.  Es fehlt noch eine Minidokumentation, welche ich gerade schreibe. Folgende Sachen sind realisiert:

• Compiler
• Interpreter
• Grundwortschatz
• Quelltexteditor
• Quellextverwaltung
• Autostart
• TriOS-Loader

Damit kann man autark auf dem Hive arbeiten. Natürlich fehlen in dieser frühen Phase noch die spannenden Sachen, wie eine Bibliotheksverwaltung, Sound, Grafik usw. aber man kann es unter TriOS starten, erste Experimente machen und masochistische Drohnen können ein wenig in meinen kruden Quelltexten schnorren… 😉

Wenn euch jemand fragt, was ihr mit dem komischen Hive-Ding da so macht, dann könnt ihr jetzt mit vollem Ernst antworten: „Nun ja, ich beschäftige mich nebenher mit experimenteller Medienarchäologie!“ Ok, man ist also so etwas wie ein Indiana Jones des Computerzeitalters auf der Suche nach dem verborgenen Schatz der vergangenen Zukunft in den Ruinen versunkener digitaler Kulturen… 😉

Aber jetzt mal ganz ernsthaft: Dieses Video ist ein einführender Vortrag von Prof. Dr. Wolfgang Ernst und Dr. Stefan Höltgen zur Vortragsreihe „SHIFT – RESTORE – ESCAPE“ an der Humboldt-Universität zu Berlin. Einfach mal ansehen und sacken lassen – es lohnt sich, denn bei einigen Aspekten geht es auch um jene Ideen, die hinter den Projekten hier stehen. Ich hoffe die Vorträge werden irgendwann auch als Video verfügbar sein – wir werden das beobachten.

Nach einigen internen Aufräumarbeiten am Code von TriOS und den Neuerungen von U-Held (Fenster/Anpassung TV-Modus), sind nun kleine Tools mit einer textbasierten strukturierteren Benutzeroberfläche kein Problem mehr. Als erstes habe ich mir einen schon lange fälligen Filemanager vorgenommen. Keine uneigennützige Wahl, denn ich brauche ihn als Basis für einige Tools, um eine Brücke zwischen TriOS und mental zu bauen. Ziel ist es, mental als nutzbare Programmiersprache unter TriOS startbar zu machen.

In jedem Fall können solche Tools jetzt sehr einfach und fast schon komfortabel mit den Fensterfunktionen in Spin erstellt werden. Einige nutzbare GUI-Objekte wie ein variables Dateilistenfenster habe ich schon als Objekt ausgelagert. Keine großen Sachen, aber Kleinvieh macht auch Mist. In der nächsten Revision R56 wird der Filemanager beiliegen.

[Zeige als Diashow]

Nach einigen Tagen Abstinenz habe ich nun wieder ein wenig Hand angelegt und den TriBorg-Player verbessert. Das Programm ist ja ursprünglich als Programmloader gestartet und zu einem SID-Player mutiert. Dennoch gab es noch einige Altlasten: So mussten die Dateien des Players und auch die DMP-Files im Hauptverzeichnis liegen. Mit einer kleinen Änderung kann nun der Player auch aus einem Verzeichnis gestartet werden. Alle DMP-Files in diesem Verzeichnis werden dann in die Playliste übernommen und abgespielt. Mit ESC gelingt nun wieder der „geordnetet Rücksturz zur Erde“ – man landet also wieder wie es sich gehört in der Kommandozeile von Regime.

Soll der Player automatisch von SD-Card starten, so kann eine Kopie von „triborg.bin“ als „reg.sys“ im Hauptverzeichnis gespeichert werden. In diesem Fall müssen sich natürlich alle anderen Dateien ebenfalls dort befinden. Mit ESC wird dann der Player neu gestartet.

Bei dieser Gelegenheit habe ich auch gleich noch die Kommandozeile „Regime“ angepasst: Auch dort kann nun ein anderer Code in Administra geladen werden, ohne das sich das aktuelle Verzeichnis ändert, in welchem man sich gerade befindet. Vor der Änderung befand man sich nach dem Laden eines neuen Administra-Codes immer wieder im Hauptverzeichnis, da das Medium neu eingebunden wurde. Regime merkt sich nun das aktuelle Verzeichnis, startet den Code und wechselt dann wieder an die korrekte Stelle im Verzeichnisbaum. Praktisch ist das zum Beispiel immer dann, wenn man in einem Verzeichnis mit Mediendateien wie SID- oder AY-Soundfiles schnell den Administra-Code mit der passenden Soundkarte laden möchte – geht jetzt problemlos ohne wildes hin- und herwechseln in den Verzeichnissen. 🙂

Sehr schöne Sache: U-Held hat einen ersten Schritt zur Anbindung der G0-Grafiklib an PropForth erstellt. Unter Spin habe ich ja schon mit G0Test und TriBorg mit den Funktionen experimentiert. Die Funktionen in der Forth-G0-Lib sind noch nicht vollständig, aber die grundlegenden Wörter um den G0-Treiber komfortabel zu starten und zu initialisieren sind realisiert. Die anderen Funktionen sind mehr oder weniger Fleißarbeit. Die Programmierung ist auch recht einfach, wie wir gleich sehen werden. Wer also gern in Forth Programme oder Games mit Grafik schreiben möchte, erfährt mehr nach dem Knick…

Continue reading ‘Grafik in Forth programmieren’ »

Ist schon ein paar Tage her (hab gerade wenig Zeit) und die meisten werden es sich schon aus dem Forum besorgt haben. Kurz die Neuerungen in Stichworten:

• Speichererweiterung auf 512kb -> Hinweis für Nutzer der Ramdisk-Funktion: Ram-Bank1 wird von TRIOS-Basic genutzt und überschrieben, also für Ram-Disk „NICHT“ Ram-Bank1 benutzen
• Anzahl der möglichen Basic-Zeilen wurde auf 999_999 erhöht (das sollte wohl reichen )
• Stringvariablen verfügbar: Ab sofort werden Strings unterstützt (#a … #z)
• neue Befehle: -STR l, STR r, STR m (entspricht strleft, strright, midstr)
• LEN(string) ermittelt die Länge eines Strings (die maximale Länge eines Strings darf 150 Zeichen betragen, längere Strings werden abgeschnitten)
• STRCOMP(string1,string2) vergleicht zwei Strings und gibt entweder -1(strings sind gleich) oder 0(strings sind ungleich) zurueck
• Input-Befehl um Stringeingabe erweitert
• kleinere Fehler bei Windows-Funktionen beseitigt
• Basicprogramme werden ab sofort im eRam abgelegt, dadurch ist der gesamte Regnatix-Speicher für’s TRIOS-Basic frei (ca. die hälfte ist noch frei für Erweiterungen)

Wie üblich weitere Infos im Forum: TriOS-Basic

Hier nun Schaltplan, Bestückungsplan, Pinbelegungen der Buchsen und eine kurze Übersicht der Funktionen, etwas ausführlicher dann in einem späteren Tutorial:

[Zeige als Diashow]

Continue reading ‘Sepia-IO: Funktionen, Schaltplan, Pinbelegungen’ »

Aktuell arbeite ich wie angekündigt an einer IO-Erweiterung für den Hive. An diesem Wochenende habe ich den ersten Prototypen aufgebaut und wie es bis jetzt ausschaut, funktioniert alles perfekt.

[Zeige als Diashow]

Gleich vorweg und um alle Bedenken zu zerstreuen: Wie man unschwer auf den Bildern erkennen kann, ist es völlig problemlos möglich, mit der Karte (bis zu vier) digitale Joysticks mit einem ganz einfachen Adapter direkt am Hive anzuschließen! Aber es geht natürlich noch einiges mehr… 😉 Continue reading ‘Prototyp IO-Karte „Sepia“’ »

Im Propeller update BLOG hat sich Chip Gracey mit einigen Informationen zum Bootverhalten und dem internen ROM gemeldet: Im ROM enthalten ist ein Bootloader für einen angeschlossenen SPI-Flash oder die serielle Schnittstelle mit SHA256/HMAC Authentifizierung, um den Code schützen zu können. Da der Flash nun SPI verwendet, dürfte sich die Bootzeit aus dem Flash deutlich verkürzen, obwohl ich das nie als Problem angesehen habe. Wahrscheinlich ist einfach der Code einfacher, da SPI ja ekanntlich einfacher gestrickt ist.

Aber viel interessanter: Continue reading ‘Infos zum Propeller II von Chip Gracey’ »

.:.:– TACHYON –:.:.

Hmm, hab ich doch in dem Beitrag zum Geschwindigkeitsvergleich glatt vergessen zu erwähnen was Tachyon überhaupt ist. Ok, das holen wir hier mal nach! Lassen wir einfach Peter Jakacki – dem Entwickler von Tachyon – zu Wort kommen: „TACHYON – A Fast and small Forth byte code VM„. Tachyon ist also wie m ein Forth-Derivat mit einigen wirklich interessanten Eigenschaften.  Das primäre Ziel ähnelt PropForth: Es soll ein interaktives Entwicklungswerkzeug sein, welches auf einem Propellerchip läuft und typisch über die serielle Schnittstelle und ein Terminalprogramm auf einem Hostcomputer bedient wird. Man kann es also nicht wirklich mit m und mental vergleichen, welches ja dem Hive mit seinen drei Propellerchips auf den Leib geschneidert ist. Im Gegensatz zu PropForth ist Tachyon sehr schnell und wahrscheinlich auch recht klein – genaue Zahlen zum Speicherverbrauch habe ich aber leider noch nicht. Da es aber ein klassisches Forthmodell ist, dürfte es auch mehr Speicher belegen als der m-Core, welcher ja viele Aufgaben nebenläufig auf die beiden Slaves verteilt. Continue reading ‘Was ist Tachyon?’ »

Sorry, das zweite Video kommt heute aus meinem Darkroom… 😉 Naja, ich hoffe man kann dennoch ein wenig erkennen, zumindest habe ich die Boxen ordentlich aufgedreht, was am Licht gefehlt hat.