09.11.2011-dr235

- 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äter getrennt in einer toolbox-serie verö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.

logbuch.txt

@@ -1,25 +1,30 @@
-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.
+09.11.2011-dr235
+- 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äter getrennt in einer toolbox-serie verö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.
 
 23.04.2011-dr235	
 - integration von propforth in trios
 
 15-04-2011-dr235
 - 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
-- übernahme der rtc-routinen von stephan
-- time-kommando: anzeige/änderung datum/zeit
-- perplex: experimentelles tool für plexbus (scan/open/close/get/put)
-- fterm: primitiv-terminal für forth-hive
+- übernahme der rtc-routinen von stephan
+- time-kommando: anzeige/änderung datum/zeit
+- perplex: experimentelles tool für plexbus (scan/open/close/get/put)
+- fterm: primitiv-terminal für forth-hive
 
 18-09-2010-dr235
 - regime: free zeigt jetzt auch die speicherbelegung des eram an
 - speicherverwaltung/ramdisk integriert (beispielcode siehe eram.spin & regime.spin)
 - eram.bin kann jetzt auch mit ramdisk umgehen
-- regime: neue kommandos für ramdisk
-- egalisierung der namen für den ramzugriff (älterer code muß leicht angepasst werden)
-- user- und systemmode für ramzugriff eingefügt
+- regime: neue kommandos für ramdisk
+- egalisierung der namen für den ramzugriff (älterer code muß leicht angepasst werden)
+- user- und systemmode für ramzugriff eingefügt
 - erste version eine make-batch um das gesamte system zu kompilieren (nur grundsystem)
-- änderung zur ios: da bst eine pfadliste zu bibliotheksordnern unterstützt, liegt (soweit das möglich ist) die ios nun nur noch unter system\regnatix 
+- änderung zur ios: da bst eine pfadliste zu bibliotheksordnern unterstützt, liegt (soweit das möglich ist) die ios nun nur noch unter system\regnatix 
 			  
 WICHTIG: Pfad zur ios.spin im bst einstellen
 
@@ -33,24 +38,24 @@ WICHTIG: Pfad zur ios.spin im bst einstellen
 - integration sid1/2-funktionen in admsid/ios
 - anpassung sid-demo von ahle2 als regnatix-code (verzeichnis demo)
 - diverse graphics-spielereien (verzeichnis demo)
-- sysconf /af - administra neu booten (admflash.adm wird dadurch überflüssig)
+- sysconf /af - administra neu booten (admflash.adm wird dadurch überflüssig)
 
 27-06-2010-dr085/235
 - admin mountet nun automatisch nach einem boot		
 
 26-06-2010-dr235
-- div. demos zugefügt
-- shooter angepasst und eingefügt
+- div. demos zugefügt
+- shooter angepasst und eingefügt
 
 20-06-2010-dr235
-- erste lauffähige SID-Player-Version für die Kommandozeile (splay)
+- erste lauffähige SID-Player-Version für die Kommandozeile (splay)
 
 14-06-2010-dr085/235
 - Semaphoren in FATEngine korrekt eingesetzt
 - Abfrage des Volume-Labels korrigiert
 
 10-06-2010-dr235
-- Kommando "ramtest" zugefügt
+- Kommando "ramtest" zugefügt
 
 09-06-2010-dr085
 - Fehler in Administra-Bootfunktion behoben
@@ -59,7 +64,7 @@ WICHTIG: Pfad zur ios.spin im bst einstellen
 
 23-04-2011-dr235
 
-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ö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. 
+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ö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.
 
@@ -72,15 +77,15 @@ In dieser Version ist eine erste Beta-Version der Speicherverwaltung des externe
 
 Einfacher Modus:
 
-Hierbei kann ein Programm auf den eRAM ü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 ü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ärts. 
+Hierbei kann ein Programm auf den eRAM ü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 ü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ärts. 
 
 ios.ram_wrbyte(ios#sysmod,0,ios#MAGIC)
-- Schreibt den Wert 0 in die Systemvariable, um einen Kaltstart auszulösen.
+- Schreibt den Wert 0 in die Systemvariable, um einen Kaltstart auszulösen.
 
 ios.ram_wrbyte(ios#sysmod,$20,$100)
 - Schreibt den Wert $20 an die physische Adresse $100 im eRAM.
 
-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.
+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.
 
 ios.ram_wrbyte(ios#usrmod,0,$100)
 - Schreibt den Wert 0 an die Adresse $100 im Userspeicher!
@@ -94,7 +99,7 @@ REND
 - Physische Adresse der letzten freien Speicherstelle des Userspeichers.
 
 USER
-- Grösse des Userspeichers (REND - RBAS).
+- Grösse des Userspeichers (REND - RBAS).
 
 RAMDRV	
 0 - Ramdisk ist nicht initialisiert
@@ -105,7 +110,7 @@ SYSVAR
 
 Noch genauer kann man sich die Speicherbelegung mit dem Tool "eram" anschauen. Nur ein paar Beispiele:
 
-"d" Anzeige des Speichers. Es werden zwei Adressspalten angezeigt. Die zweite schwarze Adresse in jeder Zeile zeigt die physische Adresse, die erste grüne Adresse die virtuelle Adresse im Userspeicher. Man kann sehr gut erkennen, ab welcher Adrese der Userbereich anfängt und wo er endet.
+"d" Anzeige des Speichers. Es werden zwei Adressspalten angezeigt. Die zweite schwarze Adresse in jeder Zeile zeigt die physische Adresse, die erste grüne Adresse die virtuelle Adresse im Userspeicher. Man kann sehr gut erkennen, ab welcher Adrese der Userbereich anfängt und wo er endet.
 
 "d 100"	Anzeige ab physischer Adresse $100
 
@@ -115,31 +120,31 @@ Noch genauer kann man sich die Speicherbelegung mit dem Tool "eram" anschauen. N
 
 Die Nutzung des Userspeichers ist sehr einfach. Es sind dabei nur folgende Regeln zu beachten:
 
-Man muss selbst darauf achten die Speichergrenzen nicht zu überschreiten. Bei Ü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ü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ändert. Wer also residente Daten über die Laufzeit der Anwendung hinaus braucht, muss im strukturierten Modus mit der Ramdisk arbeiten.
+Man muss selbst darauf achten die Speichergrenzen nicht zu überschreiten. Bei Ü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ü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ändert. Wer also residente Daten über die Laufzeit der Anwendung hinaus braucht, muss im strukturierten Modus mit der Ramdisk arbeiten.
 In einer Anwendung nicht den einfachen oder strukturierten Modus mischen - das gibt Chaos, wenn man nicht ganz genau aufpasst
 
-Ansonsten kann man wie gehabt die schon bekannten IOS-Routinen verwenden, einzig der Übergabeparameter zur Wahl des System- oder Usermodus sind hinzugekommen. Als Beispiel kann man sich die Soundplayer anschauen, die ihre Dateiliste im Userspeicher ablegen.
+Ansonsten kann man wie gehabt die schon bekannten IOS-Routinen verwenden, einzig der Übergabeparameter zur Wahl des System- oder Usermodus sind hinzugekommen. Als Beispiel kann man sich die Soundplayer anschauen, die ihre Dateiliste im Userspeicher ablegen.
  
 Strukturierter Modus:
 
-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ü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.
+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ü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 ü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.
+Gedacht, getan: Im strukturierten Modus wird der Speicher in Form einer Ramdisk verwaltet. Die Dateien/Daten können ü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.
 
-Als erstes praktisches Beispiel mögen die neuen Kommandos in Regime selbst dienen, mit denen man die Ramdisk verwalten kann:
+Als erstes praktisches Beispiel mögen die neuen Kommandos in Regime selbst dienen, mit denen man die Ramdisk verwalten kann:
 Neue Regime-Kommandos:
 
 xload <sd:fn>           - datei in ram laden
 xsave <x:fn>            - datei aus ram speichern
 xdir                    - verzeichnis im ram anzeigen
 xrename <x:fn1> <x:fn2> - datei im ram umbenennen
-xdel <x:fn>             - datei im ram löschen
+xdel <x:fn>             - datei im ram löschen
 xtype <x:fn>            - text im ram anzeigen
 
-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.
+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.
 
-Die Speicherverwaltung ist allerdings noch sehr experimentell - was bedeutet, dass wohl noch einige Bugs drin sein dürften. :)
+Die Speicherverwaltung ist allerdings noch sehr experimentell - was bedeutet, dass wohl noch einige Bugs drin sein dürften. :)
 
 MAKE.BAT
 
@@ -147,34 +152,34 @@ Diese Batchdatei im obersten Verzeichnis kompiliert das Grundsystem, bestehend a
 
 09-06-2010-dr235
 
-Nach nur zwei Tagen hat drohne085 (frida) das Geheimnis um die Bootroutine gelö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ö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ön kann praktische Parallelverarbeitung sein... ;)
+Nach nur zwei Tagen hat drohne085 (frida) das Geheimnis um die Bootroutine gelö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ö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ön kann praktische Parallelverarbeitung sein... ;)
 
-Hier nun eine neue und aktuelle Version mit einer temporären funktionierenden Lösung des Problems.
+Hier nun eine neue und aktuelle Version mit einer temporären funktionierenden Lösung des Problems.
 
-Im System-Ordner gibt es jetzt folgende ausführbare Administra-Dateien:
+Im System-Ordner gibt es jetzt folgende ausführbare Administra-Dateien:
 
 admflash.adm		Standard-Flash, welches auch im EEProm gespeichert ist
 admini.adm		Mini-Flash ohne Sound, nor SDCard + Managment-Routinen
 admled.adm		Das Heartbeat-LED-Testprogramm zum direkten laden
 aterm96.adm		Die leicht modifizierte Kommandozeile vom Programmierer der FATEngine. Mit 
-			diesem Administra-Code kann man direkt über die Hostschnittstelle (9600 Baud)
+			diesem Administra-Code kann man direkt über die Hostschnittstelle (9600 Baud)
 			mit dem Chip kommunizieren. Dokumentation der Kommandos findet man im 
 			Verzeichnis "komponenten/fat/fatengine beta"
  
 
 07-06-2010-dr235
 
-Hier der aktuelle Stand von TriOS. Momentan kämpfe ich an einem 
+Hier der aktuelle Stand von TriOS. Momentan kämpfe ich an einem 
 Komplexfehler mit dem Bootloader von Administra. Das Problem ist recht 
-einfach zu reproduzieren, aber leider (für mich) nur schwer zu
+einfach zu reproduzieren, aber leider (für mich) nur schwer zu
 erfasen: Die verwendete FATEngine besitzt eine Bootfunktion um einen
 neuen BIN-Objektcode in den Propeller zu laden. Dieser Code funktioniert 
 auch teilweise. So kann man das Administra-Bios selbst laden und dann
 auch per Regime-Kommandos verwenden: Die Kommandos "cogs" und "sysinfo"
-sprechen Administra-Funktionen an, welche auch korrekt ausgeführt werden.
+sprechen Administra-Funktionen an, welche auch korrekt ausgeführt werden.
 Das Problem: Nach dem Bootprozess kann man keine SD-Card mehr mounten.
 
-Es ist auch möglich den Fehler noch weiter einzugrenzen: Wenn man die 
+Es ist auch möglich den Fehler noch weiter einzugrenzen: Wenn man die 
 originale FATEngine (im Verzeichnis komponenten/fat) vom Host direkt in  
 Administra startet, meldet sich diese in Form einer einfachen Kommando-
 zeile per Hostschnittstelle. Versucht man dort eine erzeugte BIN-Datei
@@ -183,28 +188,28 @@ Ergebnis.
 
 Verzeichnisstruktur:
 
-bin			- BIN-Dateien für die Flash's und die SD-Card
+bin			- BIN-Dateien für die Flash's und die SD-Card
 doku			- 
-flash			- Quelltexte für die Software in den EEProms
-system			- Quelltext für ausführbare BIN-Dateien
-zubehör			- Kleine Zusatzprogramme (StarTracker, Boulder Dash...)
+flash			- Quelltexte für die Software in den EEProms
+system			- Quelltext für ausführbare BIN-Dateien
+zubehör			- Kleine Zusatzprogramme (StarTracker, Boulder Dash...)
 komponenten		- Div. verwendete Objekte (FATEngine, SIDCog...)
 
 Installation:
 
 1. 	Flashen der drei EEProms mit den BIN-Dateien aus  "bin/flash" oder
-	über das Propellertool aus den Quellen "flash".
+	über das Propellertool aus den Quellen "flash".
 
 2. 	SD-Card erstellen: Einfach alles aus "bin/sd-card" auf eine FAT16/32
 	Karte kopieren.
 
 Das System bootet Regnatix und Bellatrix beim Systemstart aus den Dateien
-"adm.sys", "reg.sys" bzw. "bel.sys". Diese Dateien können auch das Hidden-Bit gesetzt
-haben. Externe Kommandos bzw. ausführbare BIN-Dateien werden im aktuellen
-UND im System-Verzeichnis gesucht - alle Systemkommandos können also in das 
+"adm.sys", "reg.sys" bzw. "bel.sys". Diese Dateien können auch das Hidden-Bit gesetzt
+haben. Externe Kommandos bzw. ausführbare BIN-Dateien werden im aktuellen
+UND im System-Verzeichnis gesucht - alle Systemkommandos können also in das 
 System-Verzeichnis kopiert werden.
 
-Hilfe gibt es meist über das Kommando "help" oder den Parameter "/h".
+Hilfe gibt es meist über das Kommando "help" oder den Parameter "/h".