Problematische Umlaute und Formatierungen entfernt
This commit is contained in:
drohne235@googlemail.com
parent
ff1fc51564
commit
c1a8861c0d
440
installation.txt
440
installation.txt
|
|
@ -1,220 +1,220 @@
|
||||||
|
|
||||||
1. Installation des Grundsystems
|
1. Installation des Grundsystems
|
||||||
2. Forth im Überblick
|
2. Forth im Überblick
|
||||||
3. Regime im Überblick
|
3. Regime im Überblick
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
1. Installation des Grundsystems:
|
1. Installation des Grundsystems:
|
||||||
|
|
||||||
1. Flashen der drei EEPROMS:
|
1. Flashen der drei EEPROMS:
|
||||||
|
|
||||||
\flash\administra\admflash.spin --> Administra
|
\flash\administra\admflash.spin --> Administra
|
||||||
\flash\bellatrix\belflash.spin --> Bellatrix
|
\flash\bellatrix\belflash.spin --> Bellatrix
|
||||||
\flash\regnatix\regflash.spin --> Regnatix
|
\flash\regnatix\regflash.spin --> Regnatix
|
||||||
|
|
||||||
2. Der Schalter bleibt ab jetzt auf Regnatix stehen. Ein Terminalprogramm (ich verwende Tera Term) starten und 57600 Baud auf die Schnittstelle vom Hive einstellen. Nach einem Reset meldet sich das Propforth im Terminal. Datei "system\basics.f" in einem Editor öffnen, alles markieren, kopieren und im Terminal einfügen. Der Quelltext wird jetzt im Forth compiliert.
|
2. Der Schalter bleibt ab jetzt auf Regnatix stehen. Ein Terminalprogramm (ich verwende Tera Term) starten und 57600 Baud auf die Schnittstelle vom Hive einstellen. Nach einem Reset meldet sich das Propforth im Terminal. Datei "system\basics.f" in einem Editor öffnen, alles markieren, kopieren und im Terminal einfügen. Der Quelltext wird jetzt im Forth compiliert.
|
||||||
|
|
||||||
3. Im Terminalfenster, aso im Forth, dass Kommendo "saveforth" eingeben. Damit wird das gesamte Forthsystem mit der gerade neu compilierten Erweiterungen wieder im EEPROM als Image gespeichert.
|
3. Im Terminalfenster, aso im Forth, dass Kommendo "saveforth" eingeben. Damit wird das gesamte Forthsystem mit der gerade neu compilierten Erweiterungen wieder im EEPROM als Image gespeichert.
|
||||||
|
|
||||||
Nach einem Reset sollte sich das Forth jetzt komplett mit seinem Prompt sowohl auf dem angeschlossenen VGA-Monitor, als auch im Terminal melden. Im Prinzip benötigen wir nun das Terminalprogramm nicht mehr und können direkt am Hive arbeiten. Später, wenn man in Forth programmiert, ist die vorhandene Terminalschnittstelle aber manchmal sehr nützlich.
|
Nach einem Reset sollte sich das Forth jetzt komplett mit seinem Prompt sowohl auf dem angeschlossenen VGA-Monitor, als auch im Terminal melden. Im Prinzip benötigen wir nun das Terminalprogramm nicht mehr und können direkt am Hive arbeiten. Später, wenn man in Forth programmiert, ist die vorhandene Terminalschnittstelle aber manchmal sehr nützlich.
|
||||||
|
|
||||||
Erstellung einer Forth-SDCard:
|
Erstellung einer Forth-SDCard:
|
||||||
|
|
||||||
Im Prinzip kann jede normale FAT16/32 Karte verwendet werden. Lange Dateinamen werden nicht verwendet, Unterverzeichnisse sind kein Problem. Es ist sinnvoll, alle Dateien aus dem Verzeichnis "bin\sd-card-basic\" auf die SD-Karte zu kopieren.
|
Im Prinzip kann jede normale FAT16/32 Karte verwendet werden. Lange Dateinamen werden nicht verwendet, Unterverzeichnisse sind kein Problem. Es ist sinnvoll, alle Dateien aus dem Verzeichnis "bin\sd-card-basic\" auf die SD-Karte zu kopieren.
|
||||||
|
|
||||||
Das Verzeichnis "system" hat eine besondere Bedeutung: Hier sollten sich die Tools, Erweiterungen und Bibliotheken befinden. Mit dem Kommando "sys name.f" kann aus jedem anderen Verzeichnis ohne Wechsel die Datei name.f geladen und compiliert werden.
|
Das Verzeichnis "system" hat eine besondere Bedeutung: Hier sollten sich die Tools, Erweiterungen und Bibliotheken befinden. Mit dem Kommando "sys name.f" kann aus jedem anderen Verzeichnis ohne Wechsel die Datei name.f geladen und compiliert werden.
|
||||||
|
|
||||||
Systemstart:
|
Systemstart:
|
||||||
|
|
||||||
Beim Systemstart wird immer das Forth aus dem EEPROM gestartet. So kann, wie mit den klassischen Homecomputern, sofort unkompliziert programmiert werden. Neben dem Forth gibt es im TriOS noch ein in Spin programmiertes Betriebssystem, welches sich dem Benutzer durch den Kommandointerpreter Regime präsentiert. Aus dem Forth kann diese mit dem Kommando "regime" gestartet werden. Im Gegenzug kann im laufenden Regime mit dem Kommando "forth" wieder zur integrierten Programmiersprache gewechselt werden.
|
Beim Systemstart wird immer das Forth aus dem EEPROM gestartet. So kann, wie mit den klassischen Homecomputern, sofort unkompliziert programmiert werden. Neben dem Forth gibt es im TriOS noch ein in Spin programmiertes Betriebssystem, welches sich dem Benutzer durch den Kommandointerpreter Regime präsentiert. Aus dem Forth kann diese mit dem Kommando "regime" gestartet werden. Im Gegenzug kann im laufenden Regime mit dem Kommando "forth" wieder zur integrierten Programmiersprache gewechselt werden.
|
||||||
|
|
||||||
2. Forth im Überblick:
|
2. Forth im Überblick:
|
||||||
|
|
||||||
Einige nützliche Kommandos befinden sich in dem Modul tools.mod. In den meisten Fällen ist es sinnvoll dieses Modul mit der Befehlssequenz "sys tools.mod saveforth" fest im Forth einzubinden.
|
Einige nützliche Kommandos befinden sich in dem Modul tools.mod. In den meisten Fällen ist es sinnvoll dieses Modul mit der Befehlssequenz "sys tools.mod saveforth" fest im Forth einzubinden.
|
||||||
|
|
||||||
Wichtige Tastencodes:
|
Wichtige Tastencodes:
|
||||||
|
|
||||||
[ESC]-1 Screen 1, COG 1
|
[ESC]-1 Screen 1, COG 1
|
||||||
[ESC]-2 Screen 2, COG 2
|
[ESC]-2 Screen 2, COG 2
|
||||||
[ESC]-3 Screen 3, COG 3
|
[ESC]-3 Screen 3, COG 3
|
||||||
[ESC]-b Break, Reset der aktuellen COG
|
[ESC]-b Break, Reset der aktuellen COG
|
||||||
[ESC]-r Reset, Neustart Regnatix
|
[ESC]-r Reset, Neustart Regnatix
|
||||||
|
|
||||||
Wichtige Kommandos:
|
Wichtige Kommandos:
|
||||||
|
|
||||||
load <name> - Datei laden und comilieren, Ausgabe Screen 3
|
load <name> - Datei laden und comilieren, Ausgabe Screen 3
|
||||||
dload <name> - wie load, aber Ausgabe aktueller Screen
|
dload <name> - wie load, aber Ausgabe aktueller Screen
|
||||||
sys <name> - Datei aus sys-Verzeichnis laden und compilieren
|
sys <name> - Datei aus sys-Verzeichnis laden und compilieren
|
||||||
ls - Dateiliste
|
ls - Dateiliste
|
||||||
lsl - Dateiliste- Long-Format
|
lsl - Dateiliste- Long-Format
|
||||||
cd <name> - in Verzeichniss wechseln
|
cd <name> - in Verzeichniss wechseln
|
||||||
mount - SD-Card einbinden
|
mount - SD-Card einbinden
|
||||||
unmount - SD-Card freigeben
|
unmount - SD-Card freigeben
|
||||||
words - Anzeige Wöterbuch
|
words - Anzeige Wöterbuch
|
||||||
mod? - (tools.mod) Anzeige compilierter Erweiterungen
|
mod? - (tools.mod) Anzeige compilierter Erweiterungen
|
||||||
lib? - (tools.mod) Anzeige compilierter Bibliotheken
|
lib? - (tools.mod) Anzeige compilierter Bibliotheken
|
||||||
cog? - (tools.mod) Anzeige COG-Liste
|
cog? - (tools.mod) Anzeige COG-Liste
|
||||||
cat <name> - (tools.mod) Ausgabe einer Textdatei
|
cat <name> - (tools.mod) Ausgabe einer Textdatei
|
||||||
less <name> - (tools.mod) Zeilenweise Textausgabe
|
less <name> - (tools.mod) Zeilenweise Textausgabe
|
||||||
dm? - (tools.mod) Anzeige der Systemverzeichnisse
|
dm? - (tools.mod) Anzeige der Systemverzeichnisse
|
||||||
regime - CLI starten
|
regime - CLI starten
|
||||||
aload <name> - Adminsitra-Code laden
|
aload <name> - Adminsitra-Code laden
|
||||||
bload <name> - Bellatrix-Code laden
|
bload <name> - Bellatrix-Code laden
|
||||||
spin <name> - Spin-Programm starten
|
spin <name> - Spin-Programm starten
|
||||||
|
|
||||||
Wichtige Dateien:
|
Wichtige Dateien:
|
||||||
|
|
||||||
Die Dateien *.mod und *.lib enthalten ganz normale Forth-Quelltexte. Damit hat man schnell eine Übersicht über die grobe Funktion dieser Quellen: Lib's sind halt reine Sammlungen von Worten zu einer bestimmten Funktionsgruppe und MOD's sind mehr oder weniger fertige und abgeschlossene Programme. Ein Beispiel:
|
Die Dateien *.mod und *.lib enthalten ganz normale Forth-Quelltexte. Damit hat man schnell eine Übersicht über die grobe Funktion dieser Quellen: Lib's sind halt reine Sammlungen von Worten zu einer bestimmten Funktionsgruppe und MOD's sind mehr oder weniger fertige und abgeschlossene Programme. Ein Beispiel:
|
||||||
|
|
||||||
Die Datei hss.lib enthält Worte um die HSS-Funktionen von Administra anzusprechen. Mit diesen Funktionen kann man nun ein Modul (Programm) wie einen HSS-Soundplayer schreiben.
|
Die Datei hss.lib enthält Worte um die HSS-Funktionen von Administra anzusprechen. Mit diesen Funktionen kann man nun ein Modul (Programm) wie einen HSS-Soundplayer schreiben.
|
||||||
|
|
||||||
Im Gegensatz dazu die Datei splay.mod: Mit diesem Modul wird ein HSS-Soundplayer ins System eingefügt, welcher Funktionen aus der hss.lib verwendet.
|
Im Gegensatz dazu die Datei splay.mod: Mit diesem Modul wird ein HSS-Soundplayer ins System eingefügt, welcher Funktionen aus der hss.lib verwendet.
|
||||||
|
|
||||||
Die Datei benötigt man aber mehr oder weniger nur zur Entwicklung, ein fertiges Modul wie splay.mod enthält dann schon die die entsprechenden HSS-Worte die benötigt werden.
|
Die Datei benötigt man aber mehr oder weniger nur zur Entwicklung, ein fertiges Modul wie splay.mod enthält dann schon die die entsprechenden HSS-Worte die benötigt werden.
|
||||||
|
|
||||||
Die ifnot: ... Anweisung sorgt dabei dafür, dass keine Funktionen doppelt in das Wörterbuch compiliert werden. Das ist quasi ein verteiltes und fein granuliertes Konzept analog zu einer DLL. Die Forth-Version funktioniert dabei aber im Gegensatz zu DLL's nicht auf Bibliotheks-, sondern auf Funktionsebene.
|
Die ifnot: ... Anweisung sorgt dabei dafür, dass keine Funktionen doppelt in das Wörterbuch compiliert werden. Das ist quasi ein verteiltes und fein granuliertes Konzept analog zu einer DLL. Die Forth-Version funktioniert dabei aber im Gegensatz zu DLL's nicht auf Bibliotheks-, sondern auf Funktionsebene.
|
||||||
|
|
||||||
*.mod Module, Forth-Erweiterungen für das System
|
*.mod Module, Forth-Erweiterungen für das System
|
||||||
*.lib Bibliotheken, grundlegende Wortsammlungen
|
*.lib Bibliotheken, grundlegende Wortsammlungen
|
||||||
*.adm Administra-Code (z.Bsp. admsid.adm für SIDCog-Code)
|
*.adm Administra-Code (z.Bsp. admsid.adm für SIDCog-Code)
|
||||||
*.bel Bellatrix-Code
|
*.bel Bellatrix-Code
|
||||||
*.bin Spin-Code, im Normalfall zur Ausführung in Regnatix
|
*.bin Spin-Code, im Normalfall zur Ausführung in Regnatix
|
||||||
|
|
||||||
basics.f - (mod:basics) Hive-Core für PropForth
|
basics.f - (mod:basics) Hive-Core für PropForth
|
||||||
ari.lib - (lib:ari) Zusätzliche arithmetische Funktionen
|
ari.lib - (lib:ari) Zusätzliche arithmetische Funktionen
|
||||||
cog.lib - (lib:cog) Zusätzliche COG-Funktionen
|
cog.lib - (lib:cog) Zusätzliche COG-Funktionen
|
||||||
adm.lib - (lib:adm) Administra-Chipmanagment-Funktionen
|
adm.lib - (lib:adm) Administra-Chipmanagment-Funktionen
|
||||||
hss.lib - (lib:hss) Bibliothek für Hydra-Sound-System
|
hss.lib - (lib:hss) Bibliothek für Hydra-Sound-System
|
||||||
sfx.lib - (lib:sfx) Soundeffekt-Bibliothek
|
sfx.lib - (lib:sfx) Soundeffekt-Bibliothek
|
||||||
wav.lib - (lib:wav) Wave-Soundbibliothek
|
wav.lib - (lib:wav) Wave-Soundbibliothek
|
||||||
|
|
||||||
bel.lib - (lib:bel) Bellatrix-Chipmanagment-Funktionen
|
bel.lib - (lib:bel) Bellatrix-Chipmanagment-Funktionen
|
||||||
key.lib - (lib:key) Tastatur-Bibliothek
|
key.lib - (lib:key) Tastatur-Bibliothek
|
||||||
scr.lib - (lib:scr) Screen-Bibliothek
|
scr.lib - (lib:scr) Screen-Bibliothek
|
||||||
sd0.lib - (lib:sd0) SD-Card-Bibliothek
|
sd0.lib - (lib:sd0) SD-Card-Bibliothek
|
||||||
|
|
||||||
debug.f - Nützliche Worte zur Fehlersuche und Entwicklung
|
debug.f - Nützliche Worte zur Fehlersuche und Entwicklung
|
||||||
rom.f - EEPROM-Dateisystem
|
rom.f - EEPROM-Dateisystem
|
||||||
tools.f - Nützliche Tools (cat, less, dm?...)
|
tools.f - Nützliche Tools (cat, less, dm?...)
|
||||||
hplay.f - HSS-Player
|
hplay.f - HSS-Player
|
||||||
wplay.f - WAV-Player
|
wplay.f - WAV-Player
|
||||||
splay.f - SID-Player
|
splay.f - SID-Player
|
||||||
|
|
||||||
Administra-Codedateien im SYS-Verzeichnis:
|
Administra-Codedateien im SYS-Verzeichnis:
|
||||||
|
|
||||||
admled.adm Testprogramm - HBeat-LED blinken lassen
|
admled.adm Testprogramm - HBeat-LED blinken lassen
|
||||||
admsid.adm SidCog-Version (wird von splay benötigt)
|
admsid.adm SidCog-Version (wird von splay benötigt)
|
||||||
admsys.adm Standardcode für ADM mit SD/HSS/WAV
|
admsys.adm Standardcode für ADM mit SD/HSS/WAV
|
||||||
admym.adm Yamaha-Soundchip-Version
|
admym.adm Yamaha-Soundchip-Version
|
||||||
aterm96.adm Mini-OS für Administra (Testzwecke)
|
aterm96.adm Mini-OS für Administra (Testzwecke)
|
||||||
|
|
||||||
Reset-Fehlercodes:
|
Reset-Fehlercodes:
|
||||||
|
|
||||||
0011FFFF - stack overflow
|
0011FFFF - stack overflow
|
||||||
0012FFFF - return stack overflow
|
0012FFFF - return stack overflow
|
||||||
0021FFFF - stack underflow
|
0021FFFF - stack underflow
|
||||||
0022FFFF - return stack underflow
|
0022FFFF - return stack underflow
|
||||||
8100FFFF - no free cogs
|
8100FFFF - no free cogs
|
||||||
8200FFFF - no free main memory
|
8200FFFF - no free main memory
|
||||||
8400FFFF - fl no free main memory
|
8400FFFF - fl no free main memory
|
||||||
8500FFFF - no free cog memory
|
8500FFFF - no free cog memory
|
||||||
8800FFFF - eeprom write error
|
8800FFFF - eeprom write error
|
||||||
9000FFFF - eeprom read error
|
9000FFFF - eeprom read error
|
||||||
|
|
||||||
.err-Fehlercodes:
|
.err-Fehlercodes:
|
||||||
|
|
||||||
0 no error
|
0 no error
|
||||||
1 fsys unmounted
|
1 fsys unmounted
|
||||||
2 fsys corrupted
|
2 fsys corrupted
|
||||||
3 fsys unsupported
|
3 fsys unsupported
|
||||||
4 not found
|
4 not found
|
||||||
5 file not found
|
5 file not found
|
||||||
6 dir not found
|
6 dir not found
|
||||||
7 file read only
|
7 file read only
|
||||||
8 end of file
|
8 end of file
|
||||||
9 end of directory
|
9 end of directory
|
||||||
10 end of root
|
10 end of root
|
||||||
11 dir is full
|
11 dir is full
|
||||||
12 dir is not empty
|
12 dir is not empty
|
||||||
13 checksum error
|
13 checksum error
|
||||||
14 reboot error
|
14 reboot error
|
||||||
15 bpb corrupt
|
15 bpb corrupt
|
||||||
16 fsi corrupt
|
16 fsi corrupt
|
||||||
17 dir already exist
|
17 dir already exist
|
||||||
18 file already exist
|
18 file already exist
|
||||||
19 out of disk free space
|
19 out of disk free space
|
||||||
20 disk io error
|
20 disk io error
|
||||||
21 command not found
|
21 command not found
|
||||||
22 timeout
|
22 timeout
|
||||||
23 parameter error
|
23 parameter error
|
||||||
|
|
||||||
3. Regime im Überblick
|
3. Regime im Überblick
|
||||||
|
|
||||||
Da wir ja drei verschiedene Teilsystem in unserem Computer haben, muss Regime wissen, für welchen Chip eine ausführbare Datei bestimmt ist. Den Typ ausführbarer Dateien kann Regime automatisch anhand der Dateinamenserweiterung unterscheiden:
|
Da wir ja drei verschiedene Teilsystem in unserem Computer haben, muss Regime wissen, für welchen Chip eine ausführbare Datei bestimmt ist. Den Typ ausführbarer Dateien kann Regime automatisch anhand der Dateinamenserweiterung unterscheiden:
|
||||||
|
|
||||||
*.bin Regnatix-Code
|
*.bin Regnatix-Code
|
||||||
*.bel Bellatrix-Code
|
*.bel Bellatrix-Code
|
||||||
*.adm Administra-Code
|
*.adm Administra-Code
|
||||||
|
|
||||||
Dabei genügt es, den Namen ohne Erweiterung einzugeben. Dennoch kann es vorkommen, das man eine normale Spin-Datei mit einer beliebigen Erweiterung gespeichert hat. Diese Datei kann man dann mit den Kommandos rload, aload oder bload ganz gezielt in einen Chip laden.
|
Dabei genügt es, den Namen ohne Erweiterung einzugeben. Dennoch kann es vorkommen, das man eine normale Spin-Datei mit einer beliebigen Erweiterung gespeichert hat. Diese Datei kann man dann mit den Kommandos rload, aload oder bload ganz gezielt in einen Chip laden.
|
||||||
|
|
||||||
<dateiname> - bin/adm/bel-datei wird gestartet
|
<dateiname> - bin/adm/bel-datei wird gestartet
|
||||||
mount - SD-aufwerk mounten
|
mount - SD-aufwerk mounten
|
||||||
unmount - SD-Laufwerk freigeben
|
unmount - SD-Laufwerk freigeben
|
||||||
dir wh - Verzeichnis anzeigen
|
dir wh - Verzeichnis anzeigen
|
||||||
type <sd:fn> - Anzeige einer Textdatei
|
type <sd:fn> - Anzeige einer Textdatei
|
||||||
aload <sd:fn> - Administra-Code laden
|
aload <sd:fn> - Administra-Code laden
|
||||||
bload <sd:fn> - Bellatrix-Code laden
|
bload <sd:fn> - Bellatrix-Code laden
|
||||||
rload <sd:fn> - Regnatix-Code laden
|
rload <sd:fn> - Regnatix-Code laden
|
||||||
del <sd:fn> - Datei löschen
|
del <sd:fn> - Datei löschen
|
||||||
cls - Bildschirm löschen
|
cls - Bildschirm löschen
|
||||||
free - Anzeige des freien Speichers auf SD-Card
|
free - Anzeige des freien Speichers auf SD-Card
|
||||||
attrib <sd:fn> ashr - Dateiattribute ändern
|
attrib <sd:fn> ashr - Dateiattribute ändern
|
||||||
cd <sd:dir> - Verzeichnis wechseln
|
cd <sd:dir> - Verzeichnis wechseln
|
||||||
mkdir <sd:dir> - Verzeichnis erstellen
|
mkdir <sd:dir> - Verzeichnis erstellen
|
||||||
rename <sd:fn1> <sd:fn2> - datei/verzeichnis umbenennen
|
rename <sd:fn1> <sd:fn2> - datei/verzeichnis umbenennen
|
||||||
format <volname> - SD-Laufwerk formatieren
|
format <volname> - SD-Laufwerk formatieren
|
||||||
reboot - Hive neu starten
|
reboot - Hive neu starten
|
||||||
sysinfo - Systeminformationen
|
sysinfo - Systeminformationen
|
||||||
color <0..7> - Farbe wählen
|
color <0..7> - Farbe wählen
|
||||||
cogs - Belegung der COG's anzeigen
|
cogs - Belegung der COG's anzeigen
|
||||||
dmlist - Anzeige der Verzeichnis-Marker
|
dmlist - Anzeige der Verzeichnis-Marker
|
||||||
dm <r/s/u/a/b/c> - Marker-Verzeichnis wechseln
|
dm <r/s/u/a/b/c> - Marker-Verzeichnis wechseln
|
||||||
dmset <r/s/u/a/b/c> - Marker setzen
|
dmset <r/s/u/a/b/c> - Marker setzen
|
||||||
dmclr <r/s/u/a/b/c> - Marker löschen
|
dmclr <r/s/u/a/b/c> - Marker löschen
|
||||||
forth - Forth starten
|
forth - Forth starten
|
||||||
|
|
||||||
Marker:
|
Marker:
|
||||||
r - Marker für Root-Verzeichnis
|
r - Marker für Root-Verzeichnis
|
||||||
s - Marker für System-Verzeichnis
|
s - Marker für System-Verzeichnis
|
||||||
u - Marker für User-Verzeichnis
|
u - Marker für User-Verzeichnis
|
||||||
a/b/c - Benutzerdefinierte Verzeichnismarker
|
a/b/c - Benutzerdefinierte Verzeichnismarker
|
||||||
|
|
||||||
Die r, s, u-Marker werden vom System automatisch gesetzt und intern verwendet.
|
Die r, s, u-Marker werden vom System automatisch gesetzt und intern verwendet.
|
||||||
|
|
||||||
RAMDISK:
|
RAMDISK:
|
||||||
|
|
||||||
xload <sd:fn> - Datei von SD-Laufwerk in RAM laden
|
xload <sd:fn> - Datei von SD-Laufwerk in RAM laden
|
||||||
xsave <x:fn> - Datei aus RAM auf SD-Laufwerk speichern
|
xsave <x:fn> - Datei aus RAM auf SD-Laufwerk speichern
|
||||||
xdir - Verzeichnis im RAM anzeigen
|
xdir - Verzeichnis im RAM anzeigen
|
||||||
xrename <x:fn1> <x:fn2> - Datei im RAM umbenennen
|
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> - Textdatei im RAM anzeigen
|
xtype <x:fn> - Textdatei im RAM anzeigen
|
||||||
|
|
||||||
EXTERNE KOMMANDOS:
|
EXTERNE KOMMANDOS:
|
||||||
|
|
||||||
Die meisten Kommandozeilentools zeigen mit dem Parameter /? eine Liste der Optionen an.
|
Die meisten Kommandozeilentools zeigen mit dem Parameter /? eine Liste der Optionen an.
|
||||||
|
|
||||||
sysconf - Systemeinstellungen
|
sysconf - Systemeinstellungen
|
||||||
hplay - HSS-Player
|
hplay - HSS-Player
|
||||||
wplay - WAV-Player
|
wplay - WAV-Player
|
||||||
splay - SID-Player
|
splay - SID-Player
|
||||||
yplay - Yamaha-Soundchip-Player
|
yplay - Yamaha-Soundchip-Player
|
||||||
sfxtool - HSS-Soundeffekte erstellen
|
sfxtool - HSS-Soundeffekte erstellen
|
||||||
|
|
||||||
vga.bin - VGA 1024 x 768 Pixel, 64 x 24 Zeichen
|
vga.bin - VGA 1024 x 768 Pixel, 64 x 24 Zeichen
|
||||||
htext.bin - VGA 1024 x 768 Pixel, 128 x 48 Zeichen
|
htext.bin - VGA 1024 x 768 Pixel, 128 x 48 Zeichen
|
||||||
tv.bin - TV-Textmodus 40 x 13 Zeichen
|
tv.bin - TV-Textmodus 40 x 13 Zeichen
|
||||||
|
|
||||||
|
|
|
||||||
381
logbuch.txt
381
logbuch.txt
|
|
@ -1,174 +1,207 @@
|
||||||
23.04.2011-dr235 - integration von propforth in trios
|
23.04.2011-dr235
|
||||||
15-04-2011-dr235 - flash-tool/rom: damit kann unter anderem eine bin-datei (z. bsp. basic) in den hi-rom
|
- integration von propforth in trios
|
||||||
(64k eeprom erforderlich!) gespeichert und mit rom gestartet werden
|
15-04-2011-dr235
|
||||||
- übernahme der rtc-routinen von stephan
|
- 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
|
||||||
- time-kommando: anzeige/änderung datum/zeit
|
- übernahme der rtc-routinen von stephan
|
||||||
- perplex: experimentelles tool für plexbus (scan/open/close/get/put)
|
- time-kommando: anzeige/änderung datum/zeit
|
||||||
- fterm: primitiv-terminal für forth-hive
|
- perplex: experimentelles tool für plexbus (scan/open/close/get/put)
|
||||||
18-09-2010-dr235 - regime: free zeigt jetzt auch die speicherbelegung des eram an
|
- fterm: primitiv-terminal für forth-hive
|
||||||
- speicherverwaltung/ramdisk integriert (beispielcode siehe eram.spin & regime.spin)
|
|
||||||
- eram.bin kann jetzt auch mit ramdisk umgehen
|
18-09-2010-dr235
|
||||||
- regime: neue kommandos für ramdisk
|
- regime: free zeigt jetzt auch die speicherbelegung des eram an
|
||||||
- egalisierung der namen für den ramzugriff (älterer code muß leicht angepasst werden)
|
- speicherverwaltung/ramdisk integriert (beispielcode siehe eram.spin & regime.spin)
|
||||||
- user- und systemmode für ramzugriff eingefügt
|
- eram.bin kann jetzt auch mit ramdisk umgehen
|
||||||
- erste version eine make-batch um das gesamte system zu kompilieren (nur grundsystem)
|
- regime: neue kommandos für ramdisk
|
||||||
- änderung zur ios: da bst eine pfadliste zu bibliotheksordnern unterstützt, liegt (soweit das möglich ist)
|
- egalisierung der namen für den ramzugriff (älterer code muß leicht angepasst werden)
|
||||||
die ios nun nur noch unter system\regnatix
|
- user- und systemmode für ramzugriff eingefügt
|
||||||
WICHTIG: Pfad zur ios.spin im bst einstellen
|
- erste version eine make-batch um das gesamte system zu kompilieren (nur grundsystem)
|
||||||
23-08-2010-dr040 - integration ay-emulator (admay.adm) und yplay
|
- ä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
|
||||||
19-07-2010-dr235 - booten eines alternativen administra-codes: befindet sich auf der karte
|
|
||||||
in der root eine datei "adm.sys", so wird diese datei automatisch in
|
WICHTIG: Pfad zur ios.spin im bst einstellen
|
||||||
administra geladen
|
|
||||||
11-07-2010-dr235 - integration sid1/2-funktionen in admsid/ios
|
23-08-2010-dr040
|
||||||
- anpassung sid-demo von ahle2 als regnatix-code (verzeichnis demo)
|
- integration ay-emulator (admay.adm) und yplay
|
||||||
- diverse graphics-spielereien (verzeichnis demo)
|
|
||||||
- sysconf /af - administra neu booten (admflash.adm
|
19-07-2010-dr235
|
||||||
wird dadurch überflüssig)
|
- 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
|
||||||
27-06-2010-dr085/235 - admin mountet nun automatisch nach einem boot
|
|
||||||
26-06-2010-dr235 - div. demos zugefügt
|
11-07-2010-dr235
|
||||||
- shooter angepasst und eingefügt
|
- integration sid1/2-funktionen in admsid/ios
|
||||||
20-06-2010-dr235 - erste lauffähige SID-Player-Version
|
- anpassung sid-demo von ahle2 als regnatix-code (verzeichnis demo)
|
||||||
für die Kommandozeile (splay)
|
- diverse graphics-spielereien (verzeichnis demo)
|
||||||
14-06-2010-dr085/235 - Semaphoren in FATEngine korrekt eingesetzt
|
- sysconf /af - administra neu booten (admflash.adm wird dadurch überflüssig)
|
||||||
- Abfrage des Volume-Labels korrigiert
|
|
||||||
10-06-2010-dr235 - Kommando "ramtest" zugefügt
|
27-06-2010-dr085/235
|
||||||
09-06-2010-dr085 - Fehler in Administra-Bootfunktion behoben
|
- admin mountet nun automatisch nach einem boot
|
||||||
|
|
||||||
-----------------------------------------------------------------------------------------------
|
26-06-2010-dr235
|
||||||
|
- div. demos zugefügt
|
||||||
23-04-2011-dr235
|
- shooter angepasst und eingefügt
|
||||||
|
|
||||||
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.
|
20-06-2010-dr235
|
||||||
|
- erste lauffähige SID-Player-Version für die Kommandozeile (splay)
|
||||||
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.
|
|
||||||
|
14-06-2010-dr085/235
|
||||||
|
- Semaphoren in FATEngine korrekt eingesetzt
|
||||||
02-10-2010-dr235
|
- Abfrage des Volume-Labels korrigiert
|
||||||
|
|
||||||
Speicherverwaltung:
|
10-06-2010-dr235
|
||||||
|
- Kommando "ramtest" zugefügt
|
||||||
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.
|
|
||||||
|
09-06-2010-dr085
|
||||||
Einfacher Modus:
|
- Fehler in Administra-Bootfunktion behoben
|
||||||
|
|
||||||
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.
|
23-04-2011-dr235
|
||||||
ios.ram_wrbyte(ios#sysmod,$20,$100) - Schreibt den Wert $20 an die physische Adresse $100 im eRAM.
|
|
||||||
|
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.
|
||||||
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.
|
|
||||||
|
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.
|
||||||
ios.ram_wrbyte(ios#usrmod,0,$100) - Schreibt den Wert 0 an die Adresse $100 im Userspeicher!
|
|
||||||
|
|
||||||
In Regime kann man mit dem Kommando "free" jetzt auch die wichtigsten Systemvariablen der Speicherverwaltung anzeigen.
|
02-10-2010-dr235
|
||||||
|
|
||||||
RBAS - Erste physische Adresse des Userspeichers
|
Speicherverwaltung:
|
||||||
REND - Physische Adresse der letzten freien Speicherstelle des Userspeichers.
|
|
||||||
USER - Grösse des Userspeichers (REND - RBAS).
|
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.
|
||||||
RAMDRV 0 - Ramdisk ist nicht initialisiert
|
|
||||||
1 - Ramdisk ist initialisiert
|
Einfacher Modus:
|
||||||
SYSVAR - Erste physische Adresse der Systemvariablen.
|
|
||||||
|
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.
|
||||||
Noch genauer kann man sich die Speicherbelegung mit dem Tool "eram" anschauen. Nur ein paar Beispiele:
|
|
||||||
|
ios.ram_wrbyte(ios#sysmod,0,ios#MAGIC)
|
||||||
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.
|
- Schreibt den Wert 0 in die Systemvariable, um einen Kaltstart auszulösen.
|
||||||
d 100 - Anzeige ab physischer Adresse $100
|
|
||||||
d bas - Anzeige vom Start des Userspeichers.
|
ios.ram_wrbyte(ios#sysmod,$20,$100)
|
||||||
n - Anzeige inkrementell fortsetzen
|
- Schreibt den Wert $20 an die physische Adresse $100 im eRAM.
|
||||||
|
|
||||||
Die Nutzung des Userspeichers ist sehr einfach. Es sind dabei nur folgende Regeln zu beachten:
|
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.
|
||||||
|
|
||||||
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.
|
ios.ram_wrbyte(ios#usrmod,0,$100)
|
||||||
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.
|
- Schreibt den Wert 0 an die Adresse $100 im Userspeicher!
|
||||||
In einer Anwendung nicht den einfachen oder strukturierten Modus mischen - das gibt Chaos, wenn man nicht ganz genau aufpasst
|
|
||||||
|
In Regime kann man mit dem Kommando "free" jetzt auch die wichtigsten Systemvariablen der Speicherverwaltung anzeigen.
|
||||||
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.
|
|
||||||
|
RBAS
|
||||||
Strukturierter Modus:
|
- erste physische Adresse des Userspeichers
|
||||||
|
|
||||||
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.
|
REND
|
||||||
|
- Physische Adresse der letzten freien Speicherstelle des Userspeichers.
|
||||||
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.
|
|
||||||
|
USER
|
||||||
Als erstes praktisches Beispiel mögen die neuen Kommandos in Regime selbst dienen, mit denen man die Ramdisk verwalten kann:
|
- Grösse des Userspeichers (REND - RBAS).
|
||||||
Neue Regime-Kommandos:
|
|
||||||
|
RAMDRV
|
||||||
xload <sd:fn> - datei in ram laden
|
0 - Ramdisk ist nicht initialisiert
|
||||||
xsave <x:fn> - datei aus ram speichern
|
1 - Ramdisk ist initialisiert
|
||||||
xdir - verzeichnis im ram anzeigen
|
|
||||||
xrename <x:fn1> <x:fn2> - datei im ram umbenennen
|
SYSVAR
|
||||||
xdel <x:fn> - datei im ram löschen
|
- Erste physische Adresse der Systemvariablen.
|
||||||
xtype <x:fn> - text im ram anzeigen
|
|
||||||
|
Noch genauer kann man sich die Speicherbelegung mit dem Tool "eram" anschauen. Nur ein paar Beispiele:
|
||||||
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.
|
|
||||||
|
"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.
|
||||||
Die Speicherverwaltung ist allerdings noch sehr experimentell - was bedeutet, dass wohl noch einige Bugs drin sein dürften. :)
|
|
||||||
|
"d 100" Anzeige ab physischer Adresse $100
|
||||||
MAKE.BAT
|
|
||||||
|
"d bas" Anzeige vom Start des Userspeichers.
|
||||||
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.
|
|
||||||
|
"n" Anzeige inkrementell fortsetzen
|
||||||
09-06-2010-dr235
|
|
||||||
|
Die Nutzung des Userspeichers ist sehr einfach. Es sind dabei nur folgende Regeln zu beachten:
|
||||||
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... ;)
|
|
||||||
|
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.
|
||||||
Hier nun eine neue und aktuelle Version mit einer temporären funktionierenden Lösung des Problems.
|
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
|
||||||
Im System-Ordner gibt es jetzt folgende ausführbare Administra-Dateien:
|
|
||||||
|
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.
|
||||||
admflash.adm Standard-Flash, welches auch im EEProm gespeichert ist
|
|
||||||
admini.adm Mini-Flash ohne Sound, nor SDCard + Managment-Routinen
|
Strukturierter Modus:
|
||||||
admled.adm Das Heartbeat-LED-Testprogramm zum direkten laden
|
|
||||||
aterm96.adm Die leicht modifizierte Kommandozeile vom Programmierer der FATEngine. Mit
|
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.
|
||||||
diesem Administra-Code kann man direkt über die Hostschnittstelle (9600 Baud)
|
|
||||||
mit dem Chip kommunizieren. Dokumentation der Kommandos findet man im
|
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.
|
||||||
Verzeichnis "komponenten/fat/fatengine beta"
|
|
||||||
|
Als erstes praktisches Beispiel mögen die neuen Kommandos in Regime selbst dienen, mit denen man die Ramdisk verwalten kann:
|
||||||
|
Neue Regime-Kommandos:
|
||||||
07-06-2010-dr235
|
|
||||||
|
xload <sd:fn> - datei in ram laden
|
||||||
Hier der aktuelle Stand von TriOS. Momentan kämpfe ich an einem
|
xsave <x:fn> - datei aus ram speichern
|
||||||
Komplexfehler mit dem Bootloader von Administra. Das Problem ist recht
|
xdir - verzeichnis im ram anzeigen
|
||||||
einfach zu reproduzieren, aber leider (für mich) nur schwer zu
|
xrename <x:fn1> <x:fn2> - datei im ram umbenennen
|
||||||
erfasen: Die verwendete FATEngine besitzt eine Bootfunktion um einen
|
xdel <x:fn> - datei im ram löschen
|
||||||
neuen BIN-Objektcode in den Propeller zu laden. Dieser Code funktioniert
|
xtype <x:fn> - text im ram anzeigen
|
||||||
auch teilweise. So kann man das Administra-Bios selbst laden und dann
|
|
||||||
auch per Regime-Kommandos verwenden: Die Kommandos "cogs" und "sysinfo"
|
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.
|
||||||
sprechen Administra-Funktionen an, welche auch korrekt ausgeführt werden.
|
|
||||||
Das Problem: Nach dem Bootprozess kann man keine SD-Card mehr mounten.
|
Die Speicherverwaltung ist allerdings noch sehr experimentell - was bedeutet, dass wohl noch einige Bugs drin sein dürften. :)
|
||||||
|
|
||||||
Es ist auch möglich den Fehler noch weiter einzugrenzen: Wenn man die
|
MAKE.BAT
|
||||||
originale FATEngine (im Verzeichnis komponenten/fat) vom Host direkt in
|
|
||||||
Administra startet, meldet sich diese in Form einer einfachen Kommando-
|
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.
|
||||||
zeile per Hostschnittstelle. Versucht man dort eine erzeugte BIN-Datei
|
|
||||||
genau dieser Kommandozeile (demo.spin) zu booten, so hat man das gleiche
|
09-06-2010-dr235
|
||||||
Ergebnis.
|
|
||||||
|
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... ;)
|
||||||
Verzeichnisstruktur:
|
|
||||||
|
Hier nun eine neue und aktuelle Version mit einer temporären funktionierenden Lösung des Problems.
|
||||||
bin - BIN-Dateien für die Flash's und die SD-Card
|
|
||||||
doku -
|
Im System-Ordner gibt es jetzt folgende ausführbare Administra-Dateien:
|
||||||
flash - Quelltexte für die Software in den EEProms
|
|
||||||
system - Quelltext für ausführbare BIN-Dateien
|
admflash.adm Standard-Flash, welches auch im EEProm gespeichert ist
|
||||||
zubehör - Kleine Zusatzprogramme (StarTracker, Boulder Dash...)
|
admini.adm Mini-Flash ohne Sound, nor SDCard + Managment-Routinen
|
||||||
komponenten - Div. verwendete Objekte (FATEngine, SIDCog...)
|
admled.adm Das Heartbeat-LED-Testprogramm zum direkten laden
|
||||||
|
aterm96.adm Die leicht modifizierte Kommandozeile vom Programmierer der FATEngine. Mit
|
||||||
Installation:
|
diesem Administra-Code kann man direkt über die Hostschnittstelle (9600 Baud)
|
||||||
|
mit dem Chip kommunizieren. Dokumentation der Kommandos findet man im
|
||||||
1. Flashen der drei EEProms mit den BIN-Dateien aus "bin/flash" oder
|
Verzeichnis "komponenten/fat/fatengine beta"
|
||||||
über das Propellertool aus den Quellen "flash".
|
|
||||||
|
|
||||||
2. SD-Card erstellen: Einfach alles aus "bin/sd-card" auf eine FAT16/32
|
07-06-2010-dr235
|
||||||
Karte kopieren.
|
|
||||||
|
Hier der aktuelle Stand von TriOS. Momentan kämpfe ich an einem
|
||||||
Das System bootet Regnatix und Bellatrix beim Systemstart aus den Dateien
|
Komplexfehler mit dem Bootloader von Administra. Das Problem ist recht
|
||||||
"adm.sys", "reg.sys" bzw. "bel.sys". Diese Dateien können auch das Hidden-Bit gesetzt
|
einfach zu reproduzieren, aber leider (für mich) nur schwer zu
|
||||||
haben. Externe Kommandos bzw. ausführbare BIN-Dateien werden im aktuellen
|
erfasen: Die verwendete FATEngine besitzt eine Bootfunktion um einen
|
||||||
UND im System-Verzeichnis gesucht - alle Systemkommandos können also in das
|
neuen BIN-Objektcode in den Propeller zu laden. Dieser Code funktioniert
|
||||||
System-Verzeichnis kopiert werden.
|
auch teilweise. So kann man das Administra-Bios selbst laden und dann
|
||||||
|
auch per Regime-Kommandos verwenden: Die Kommandos "cogs" und "sysinfo"
|
||||||
Hilfe gibt es meist über das Kommando "help" oder den Parameter "/h".
|
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
|
||||||
|
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
|
||||||
|
genau dieser Kommandozeile (demo.spin) zu booten, so hat man das gleiche
|
||||||
|
Ergebnis.
|
||||||
|
|
||||||
|
Verzeichnisstruktur:
|
||||||
|
|
||||||
|
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...)
|
||||||
|
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".
|
||||||
|
|
||||||
|
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
|
||||||
|
System-Verzeichnis kopiert werden.
|
||||||
|
|
||||||
|
Hilfe gibt es meist über das Kommando "help" oder den Parameter "/h".
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue