So, nun ist schon mal der einfache Fall abgedeckt. FAT12/16 Root Directories können nun vollständig über alle Verzeichnisblöcke hinweg gelesen und angezeigt werden. Ich hab dann auch gleich mal ein DIR /p implementiert, bei der das Verzeichnis dann (guess what?!) seitenweise ausgegeben wird.
Hier kann dann das Listing auch mit ESC abgebrochen werden.
...
So, nun ist schon mal der einfache Fall abgedeckt. FAT12/16 Root Directories können nun vollständig über alle Verzeichnisblöcke hinweg gelesen und angezeigt werden. Ich hab dann auch gleich mal ein DIR /p implementiert, bei der das Verzeichnis dann (guess what?!) seitenweise ausgegeben wird.
Hier kann dann das Listing auch mit ESC abgebrochen werden.
Klasse Jörg! Danke!
Wegen Rüsselseuche war bei mir jetzt am Wochenende mal Programmierpause. Gestern konnte ich dann aber noch auch den FAT32 Root Directory Fall - und somit auch Unterverzeichnisse in FAT12/16 und 32 - abdecken. Ich hab dann gleich die Hauptschleife zum Durchsuchen der Verzeichnisse so umgebaut, dass sie durch Einklinken einer Call-Back Funktion universell einsetzbar wird. Sprich, auch für die Befehle CD, MKDIR, DEL, etc. ohne Änderung funktioniert.
Den Kommandozeilen Parser hab ich auch gleich so weit vereinfacht, dass ohne viel Aufwand verschiedene Kommando Optionen und die Pfad/Dateinamen auseinandergepflückt werden. Somit konnte ich dann gleich mal weitere Optionen für DIR mit einbinden.
Weitere Funktionen wie DIR *.TXT usw. kommen demnächst.
Ansonsten kam heute meine Bestellung aus Dänemark an.
100 PCI Slots für gerade mal 39€. Da der nächste Rechner (aamoo) ja ein paar Karten-Slot bekommen soll, war ich auf der Suche nach Card Edge Konnektoren und fand die alten ISA Slots alle extrem teuer. Auch für die 120 pol. PCI Slots muss man schon etwa 2-3€ pro Konnektor ausgeben. Umso erfreuter war ich natürlich, als ich das Angebot in DK gefunden habe. Wenn der Rechner sich dann also mal materialisiert haben sollte, kann ich eventuellen Nachbauern gerne die benötigten Slots für 39 cent/stk abgeben.
Zusätzlich kamen jetzt auch mal zwei bestellte RasPi Pico bei mir an, mit denen ich dann für den aamoo wohl eine VGA Karte basteln werde. Das Raspberry Pi Pico VGA Projekt ist dazu der Ausgangspunkt.
ZitatIch war jetzt natürlich gespannt, ob sich durch diesen einfachen Patch meine kleine Schaar an nicht lesbaren SD-Karten auch zum Arbeiten bewegen lässt.
Kurz: Leider nein.
Schade. Meine SDs gehen jetzt alle. Ich habe allerdings auch nur ein kleines Sortiment - 4 GB und 8 GB von 3 Herstellern. Das Problem dürfte darin liegen, dass die SPI-Schnittstelle im Mode 3 betrieben wird. Das liegt hardwaremäßig so fest und läßt sich so ohne weiteres nicht ändern. SD -Karten erwarten aber Mode 0. Die meisten SDs tolerieren Mode 3, leider nicht alle.
Bei Problemen also mehrere SDs verschiedener Hersteller probieren 😇
Dietrich
....werde mein Feedback etwas später abgeben...
Cheers
Hallo Jörg,
gute Nachricht, meine 8GB Micro-SD-Karte mit 2GB Partition bootet einwandfrei.
DIR -> ok
CLS -> ok
ECHO und PAUSE habe ich jetzt noch nicht genauer testen können, da es noch keinen TYPE-Befehl o.ä. gibt.
Es kommen aber bei deren Ausführung keine Fehlermeldungen und ECHO meldet auch das ON oder OFF zurück,
wenn man ECHO mit Parameter aufruft.
Ich finde es ganz super, dass du jetzt schon die ersten Befehle implementiert hast. Prima und danke, Jörg!
LG Norbert
... funktioniert aber ebenso mit den vollen 8GB /FAT32 ...
4 GB Karte mit 16 Files und 12 DIRs zugemüllt geht bei mir auch mit allen Optionen für DIR. CLS, ECHO und Pause gehen auch.
Bei der Gelegenheit ist mir nochmal aufgefallen, dass BOOT.SYS im 1. Directory-Sektor stehen muß, sonst wird die Datei vom Bootloader nicht gefunden. Das ließe sich leicht ändern, zumindest für den 1. Block
Weiter so Jörg
Dietrich
Der DIR Befehl ist jetzt mal annähernd fertig. Die Eingabe von Wildcard Zeichen (* und ?) funktioniert so weit. Jetzt müssen nur noch die Pfade bei z.B. DIR SYSTEM\*.BIN temporär gesetzt werden. Das bekomme ich aber erst nächste Woche fertig. Da das dann aber der gleiche Code wie beim Change Dir Befehl ist, werden dadurch gleich zwei Fliegen mit einer Klappe erschlagen.
Hab nun doch am Wochenende Zeit weiter zu machen. Das VCFe in München wurde auf den 7/8. September verschoben, weil die (letztes Jahr fertig renovierte) Halle einen Deckenschaden hat 
. Shit happens...
Oh, das ist schade! Also das mit der Halle natürlich.
Eine Frage am Rande:
a) Muß denn die MS Notation von Dateinamen mit dem umgekehrten Schrägstrich sein?
Praktisch alle nicht MS Betriebssysteme benutzen den normalen Schrägstrich (CP/M, Linux, OS-9, alle UNIXe, die meisten Großrechner.)
b) Und Optionen werden fast überall sonst mit einem Minuszeichen eingeleitet.
Oder will man hier unbedingt MS nacheifern?
Ich würde ja noch eine Art Formatvariable anregen, in die man beliebige Formatswitches reinschreiben kann und die das DIR dann immer mit auswertet, wenn vorhanden. Damit ließen sich persönlich angepaßte Standardausgaben ohne das ständige Nachstellen von / bzw. \ Optionen benutzen.
Schön wäre evtl. auch ein "freies" Pagemodesystem, wo man evtl. mit -p den Pagemode auf Seitenlänge (Bildschirm Y Max) einschaltet, aber mit -p[x] die Zahl der Zeilen x mit angeben kann.
edit: Vom Acorn kommend ist das Kommando "up" sehr witzig. Das entspricht dem "cd ..".
Frage: ist geplant, ein Binärfile direkt von der SD-Karte laden oder starten zu können, analog zu BLOAD and BRUN beim Apple II ?
Ich würde ja noch eine Art Formatvariable anregen, in die man beliebige Formatswitches reinschreiben kann und die das DIR dann immer mit auswertet, wenn vorhanden. Damit ließen sich persönlich angepaßte Standardausgaben ohne das ständige Nachstellen von / bzw. \ Optionen benutzen.
Schön wäre evtl. auch ein "freies" Pagemodesystem, wo man evtl. mit -p den Pagemode auf Seitenlänge (Bildschirm Y Max) einschaltet, aber mit -p[x] die Zahl der Zeilen x mit angeben kann.
Ich werde mich erst mal auf die Basics konzentrieren. Ich hab immer noch den Floppy/Grafik Controller im Hinterkopf, der muss auch mal was werden. Ich lade aber natürlich alle dazu ein, meinen Code dann nach belieben selber zu verbessern und zu ergänzen.
Frage: ist geplant, ein Binärfile direkt von der SD-Karte laden oder starten zu können, analog zu BLOAD and BRUN beim Apple II ?
Ja, ist für mich natürlich auch sehr wichtig. Es stellt sich noch die Frage, ob die BIN Dateien dann, wie jetzt für XMODEM nötig, die Start Adresse an den ersten zwei Bytes beinhalten soll, oder ob man dann einfach z.B. BRUN filename / (oder - ) $4000 eingibt. Ersteres wäre ja eigentlich schon fast ein COM File Header.
Für mich logisch wäre es, die ersten beiden Bytes eines Programms für die Startadresse zu nutzen. Ich wüßte sonst nicht, welchen Sinn ein BRUN XY.bin macht, wenn das Programm an einer anderen Adresse als der originalen gestartet wird und dann abstürzt. Oder mache ich da gedanklich einen Fehler? Bei BLOAD könnte ich mir das mit dem angehängten Adressparameter noch vorstellen. Ausnahme wäre natürlich ein relozierbares Programm.
Es macht z.B. dann nicht unbedingt Sinn, wenn man das etwa auch als eine schnelle Swapping-Routine mitbenutzen will, was ja gar nicht schlecht wäre. Etwa so in der Art, daß das zugrundeliegende Tool immer 256 Byte (oder 1K (?) oder flexibel) auf einen Hieb holt / schreibt und eigentlich selbst schon weiß (weil es das vom Programm gesagt bekommt), wo die Startadresse / Position sein soll. Zumindest wäre dafür eine 2 Byte Zusatzadresse eher hinderlich, und wer weiß, ob man nicht evtl sogar mal größere Adressen haben will (RAM Expansion), dann bräuchte man auch was anderes.
Wenn die SD Card schnell genug ansprechbar ist, kann sowas sogar richtig neue Programme ermöglichen.
Ein BLOAD , BRUN in der gewollten Form läßt sich da ja evtl obendrauf aufsetzen.
Ansonsten: Meine Textchen sind eh nur Vorschläge.
Ich werde mich erst mal auf die Basics konzentrieren. Ich hab immer noch den Floppy/Grafik Controller im Hinterkopf, der muss auch mal was werden.
Ich find das ja gut, daß Du so schrittweise da ein komplettes System draus machst. Es ist halt nur so, daß man manches auch nur einbauen kann, wenn man es mal gehört hat. Die Entscheidung wann und ob, liegt dann ja sowieso nicht beim Vorschlagenden.
Ich find das ja gut, daß Du so schrittweise da ein komplettes System draus machst. Es ist halt nur so, daß man manches auch nur einbauen kann, wenn man es mal gehört hat. Die Entscheidung wann und ob, liegt dann ja sowieso nicht beim Vorschlagenden.
Ich behalte (oder versuche es zu mindest) eure Vorschläge alle im Kopf. Na ja ehrlicherweise schreib ich sie mir auf 
.
Ich möchte den Kern so weit wie möglich einfach halten und alles was "nur" User IO ist, dann eben in die Shell zu verlagern. Die Shell kann dann auch von einem Programm wieder aus dem Speicher verdrängt werden, der Kernel nicht, weshalb die Shell auch größer ausfallen darf.
Deine Vorschläge sind alles Dinge, die in der Eingabezeile entschieden werden. Ein BLOAD oder BRUN hingegen ist sowieso essentiell. D.h. findet der Commando Interpreter von der Eingabezeile aus keinen internen Befehl, wird auf dem Datenträger nachgeschaut, ob da ein passender Dateiname eines ausführbaren Programms (sprich Befehl) vorhanden ist. Das wird dann durch die Kern Funktion OS_LOAD in den Speicher geladen und dann ausgeführt. Das entspricht also schon dem BLOAD, bzw. BRUN, weshalb diese Befehle recht einfach zu implementieren sind.
Wenn alles mal in seinen Basics so weit läuft, werden die Shell(s) dann mit Sicherheit noch mehr Funktionen bekommen, und da bin ich für jede Idee dankbar.
Da hast du aus meiner Sicht absolut recht.
Die 2 Byte Startadresse am Beginn eines ausführbaren Programms haben einen gewissen Charme.
In CPM-65 gibt es diese nicht. Da wird jedes Programm an den Beginn des User RAM (= TPA) geladen und dort gestartet. Meistens ist das ok. Wenn ein Programm allerdings an einer anderen Stelle laufen soll, wie zum Beispiel der Debugger, der im obersten Speicherbereich läuft, muss sich das Programm dann noch selbst an den Zielort verlagern und die TPA ist dann zerstört. Bei nachladbaren Treibern oä. wäre das ein erhebliches Problem. Das kann man sich mit dem Header und der passenden OS_LOAD Routine sparen.
Dietrich
