- fehler in regflash.spin behoben, konfiguration ohne forth konnte nicht compiliert werden
- standartkonfiguration ist jetzt ohne forth, ist einfacher f<>r den einstieg
- div. demos entfernt, diese werden sp<73>ter getrennt in einer toolbox-serie ver<65>ffentlicht
06.11.2011-dr235
- fehlersuche zum problem mit dem neuen bella-loader: einige bel-dateien (guidemo, 4-boing) wurden nicht korrekt initialisiert, also starteten nicht sauber. parameter und ladevorgang ist korrekt, ursache ist wahrscheinlich eine falsche initialisierung der stackwerte im pasm-teil des loaders. als l<>sung kann man diese bel-dateien als eeprom-image abspeichern, diese starten korrekt.
- flash-tool/rom: damit kann unter anderem eine bin-datei (z. bsp. basic) in den hi-rom (64k eeprom erforderlich!) gespeichert und mit rom gestartet werden
- <20>nderung zur ios: da bst eine pfadliste zu bibliotheksordnern unterst<73>tzt, liegt (soweit das m<>glich ist) die ios nun nur noch unter system\regnatix
- booten eines alternativen administra-codes: befindet sich auf der karte in der root eine datei "adm.sys", so wird diese datei automatisch in administra geladen
11-07-2010-dr235
- integration sid1/2-funktionen in admsid/ios
- anpassung sid-demo von ahle2 als regnatix-code (verzeichnis demo)
Ein neuer Meilenstein: PropForth ist jetzt in TriOS integriert. Als Nebeneffekt starten nun wieder, wie bei meiner ersten SpinOS-Version, alle drei Chips ihren initialen Code aus ihrem EEPROM und nicht mehr vom SD-Laufwerk. Damit gibt es vom Einschalten bis zum Forth-Prompt quasi keine f<>hlbare Bootzeit mehr. So geh<65>rt es sich f<>r einen richtigen Homecomputer. Es ist nun m<>glich, unmittelbar nach dem Einschalten sofort zu programmieren. Erst wenn man zu Regime wechselt wird kurz reg.sys nachgeladen. Aber selbst die Ladezeiten sind nun durch Verwendung des SD-Blocktransfer erfreulich kurz.
Obwohl das Grundsystem vom Forth den halben hRAM belegt, ist es als genormte Sprache doch eine wunderbare Geschichte im Hive. Viele der Ressourcen sind jetzt schon problemlos in Forth nutzbar und man kann sehr unkompliziert experimentieren.
02-10-2010-dr235
Speicherverwaltung:
In dieser Version ist eine erste Beta-Version der Speicherverwaltung des externen RAM's enthalten. Der Speicher kann dabei in einem einfachen oder einem strukturierten Modus verwendet werden. Klingt kompliziert, ist aber ganz einfach.
Hierbei kann ein Programm auf den eRAM <20>ber die IOS-Routinen ios.ram_* zugreifen. Wahlweise kann der Speicher im Systemmode direkt von 0 bis $07FFFF angesprochen werden, oder nur der Userbereich. Im Systemmodus ist darauf zu achten, dass eine eventuell vorhandene Ramdisk und die Systemvariablen nicht <20>berschrieben werden, man sollte also wissen was man tut... ;) Die Ramdisk wird ab der physischen Adresse 0 als verkettete Liste verwaltet, die Systemvariablen befinden sich ab $07FFFF abw<62>rts.
Da es nun m<>hsam ist in einem kleinen Code solche Konflikte mit dem Systemspeicher zu vermeiden, gibt es den Usermodus. Im Usermodus wird nur genau jener freie Speicher adressiert, welcher sich zwischen Ramdisk und Systemvariablen befindet. In diesem Fall ist die Adressierung also virtualisiert.
"d" Anzeige des Speichers. Es werden zwei Adressspalten angezeigt. Die zweite schwarze Adresse in jeder Zeile zeigt die physische Adresse, die erste gr<67>ne Adresse die virtuelle Adresse im Userspeicher. Man kann sehr gut erkennen, ab welcher Adrese der Userbereich anf<6E>ngt und wo er endet.
Man muss selbst darauf achten die Speichergrenzen nicht zu <20>berschreiten. Bei <20>berschreitung kann aber nichts passieren - die IOS-Routinen brechen einfach ab, allerdings werden die eigenen Daten halt nicht korrekt verarbeitet. Es werden also die Systemvariablen und die Daten in der Ramdisk gesch<63>tzt.
Der Userbereich im eRAM ist nur zur Laufzeit der Anwendung g<>ltig. Wird die Anwendung beendet, so kann durch Regime oder eine andere Anwendung mit den Daten der Ramdisk gearbeitet werden, wodurch sich der physische Bereich des Userbereiches ver<65>ndert. Wer also residente Daten <20>ber die Laufzeit der Anwendung hinaus braucht, muss im strukturierten Modus mit der Ramdisk arbeiten.
Ansonsten kann man wie gehabt die schon bekannten IOS-Routinen verwenden, einzig der <20>bergabeparameter zur Wahl des System- oder Usermodus sind hinzugekommen. Als Beispiel kann man sich die Soundplayer anschauen, die ihre Dateiliste im Userspeicher ablegen.
Was ist aber, wenn wir einen kleinen Texteditor schreiben wollen, der seine Textdaten resident im eRAM speichern kann? Ich m<>chte also den Texteditor verlassen k<>nnen, um in Regime zum Beispiel einen Assembler aufzurufen, welcher den Text dann assembliert. Darauf folgend m<>chte ich meinen Texteditor wieder starten und an dem Text weiter arbeiten. Daf<61>r muss es meiner Anwendung - dem Textprogramm - m<>glich sein, einen Speicherbereich im eRAM zu reservieren, der von System und anderen Anwendungen respektvoll behandelt wird.
Gedacht, getan: Im strukturierten Modus wird der Speicher in Form einer Ramdisk verwaltet. Die Dateien/Daten k<>nnen <20>ber ihren Namen angesprochen werden. Es kann mit put & get sequentiell, oder mit read & write direkt adressierbar auf die Daten in der Datei zugegriffen werden.
So ist es also m<>glich, sich in der Kommandozeile anzuschauen, welche residenten Daten die Programme aktuell angelegt haben. Sofern es Textdaten sind, k<>nnen diese Daten auch einafch angezeigt werden.
Diese Batchdatei im obersten Verzeichnis kompiliert das Grundsystem, bestehend aus den drei Flashdateien und den grundlegenden Kommandos im Systemverzeichnis. Ist ein erster Versuch. Was noch fehlt ist ein Fehlerlog und vielleicht noch die anderen Programme.
Nach nur zwei Tagen hat drohne085 (frida) das Geheimnis um die Bootroutine gel<65>st: Die Ursache lag in einer von der FATEngine verwendeten Semaphore, welche fest auf den Lock 0 "verdrahtet" war. Diese Semaphore wird an diversen Stellen in der Engine verwendet, wurde aber beim Bootvorgang nicht gel<65>scht oder freigegeben! Gedacht war sie, um den Bus zur SD-Card bei einem Zugriff zu verriegeln, falls mehrere Instanzen der Engine laufen, und gleichzeitig zugreifen wollen. Somit hat sich die Engine quasi selbst verriegelt und nach dem Bootvorgang als "neue Instanz" nun auch keinen Zugriff mehr - so sch<63>n kann praktische Parallelverarbeitung sein... ;)
