Junior Computer ][

Jetzt muss ich doch noch ein ROM Update nachschieben, weil sich in der Version 1.0.3 zwei Fehler eingeschlichen hatten.

Zum einen konnte nach einer Umschaltung der Standard Eingabe von ASCII-Tastatur auf Terminaleingabe (z.B. in BASIC via IN#0) die XModem Routine nicht mehr fehlerfrei Daten lesen. Jetzt läuft alles wieder so wie es soll.

Das andere Problem hatte sich in der Boot Routine ergeben.

Ich war stillschweigend davon ausgegangen, dass ich im Boot Block der FAT32 Partition auf der SD-Karte das erste Byte (x86 Opcode $EB = short jump) gegen einen 6502 Opcode $B0 = BCS (Branch on Carry Set) austauschen kann, damit ich nur noch zum Anfang des Boot Block Buffers ($0600) springen muss, um den Boot Code zu laden. Es hat sich aber herausgestellt, dass Windows eine Änderung an genau diesem Byte des BB nicht wirklich mag und nach einer solchen Änderung die SD-Karte immer als unformatiert angezeigt wird.

Die Lösung ist nun, erst nach dem Einlesen des Boot-Blocks, den Wert $EB im RAM Buffer an $0600 gegen ein $B0 zu tauschen und dann erst mit einem JMP $0600 den Boot-Code auszuführen.

Ich hab jetzt mal einen kleinen Dummy Boot-Code in den Boot-Block geschrieben. Das ganze sieht dann gerade so aus.

Der nächste Schritt ist nun, das Root Directory zu lesen, eine Datei BOOT.SYS zu finden und diese zu laden. Somit können dann die FAT-Treiber und das DOS vom Datenträger geladen werden.

So, jetzt bin ich doch gerade selber etwas erschrocken, als ich gesehen habe, dass es bereits 6 Wochen her ist, als ich mich das letzte mal hier gemeldet hatte. In den letzten Wochen waren bei mir so viele private aktivitäten, die mich von Basteleien und dem Junior im speziellen abgehalten hatten.

Aber jetzt habe ich wieder Zeit und auch richtig viel Lust am Junior ][ weiter zu arbeiten. Hier mal meine Agenda für die nächsten Wochen:

Als erstes werde ich mich noch ein wenig um die Software kümmern, sprich den Boot Code zumindest mal soweit angehen, dass auch jemand anderes als ich ein kleines DOS für den Junior basteln könnte. Dazu wird eventuell nochmal eine kleine Änderung am ROM Code nötig sein, weshalb ich mich vielleicht auch gleich noch mit dem fehlenden Treiber für einen (parallelen) Papertape Reader beschäftige.

Der nächste Punkt ist die dritte Erweiterungsplatine. Hier soll zumindest ein Grafikprozessor und ein Floppy-Controller drauf. Eventuell auch gleich noch eine Banking Logik um die zweiten 64K RAM anzusprechen. Eventuell kommt aber auch gleich noch ein weiterer 128K RAM Baustein mit drauf. Ein Joystick-Port wäre natürlich fein, ließe sich aber auch mit dem zweiten VIA des bisherigen IO-Boards erledigen. Mal schauen.

Beim Grafikprozessor war ja der ESP32 mit FabGL eine große Option. Hier werde ich mich wohl erst mal mit der FabGL beschäftigen müssen. Das Interfacing ist hier auch noch nicht ganz geklärt.

Beim Floppy Controller hatte ich zuerst überlegt, diesen mit einem ATMega zu realisieren. Das war mir aber dann doch zu viel Aufwand, da die MFM Codierung doch recht zeitkritisch ist und ich dann alles hätte in Assembler schreiben müssen. Ich habe mich jetzt deshalb für den GM82C765B Floppy Sub System Controller entschieden, der bei UTSource noch in ausreichender Stückzahl und recht günstig zu haben ist. Ich werde dort in den nächsten Tagen mal ein paar ICs auch für andere Projekte bestellen und mich dann ausgiebig mit diesem Controller beschäftigen.

So weit erst mal wieder ein Lebenszeichen von mir. Ich hoffe, es gibt noch ein paar wenige, die sich für den Junior ][ interessieren, um mich da weiterhin ein wenig vorran zu treiben.

Cheers

Jörg

Heute hab ich mal angefangen, den Bootstrap Loader zu schreiben. Als Test wird jetzt erst mal ein Directory Listing des Root Verzeichnisses ausgegeben.

Morgen kommt die Ausgabe dann wieder raus und statt dessen eine Suchroutine für die Datei BOOT.SYS, von welcher dann der erste Block geladen wird. Ich hoffe, dass ich in diese 512 Byte dann die Read-Treiber für FAT12, FAT16 und FAT32 unterbringen kann, um weitere Blöcke der BOOT.SYS Datei zu laden. Sollte aber klappen...

Das ROM hat jetzt die Versionsnummer 1.0.5 bekommen. Das sollte dann das endgültige BIOS für einen von SD-Karte bootfähigen Kernel sein.

Auf dem Floppy Controller soll es dann noch ein eigenes ROM geben, dass dann von Floppy booten kann. D.h. die jetzt noch verfügbaren 794 Byte im System ROM (ich dachte zuletzt, es wären nur noch 700) können dann noch für anderen Unsinn verbraten werden (nein NorbertJ da bekomme ich beim besten Willen kein PacMan rein ).

Wie dann das ganze für das CPM-65 von Dietrich aussieht, kann ich noch nicht vollständig abschätzen. Dietrich meinte, es wäre eventuell eine gute Idee, die CP/M Disketten als Image Dateien unter FAT auf der SD-Karte zu speichern und diese dann als virtuelle Laufwerke zu mounten.

Hier könnte man also in der BOOT.SYS statt eines Befehlsinterpreters dann einen Image Mounter und den CP/M Bootstrap Loader unterbringen.

Jetzt war es dann doch wieder komplizierter als gedacht.

Ich hatte jetzt mal einen universellen FAT12/16/32 Bootstrap Loader geschrieben, der dann so gerade noch in den Bootblock gepasst hat.

Als ich das dann mit einer FAT32 formatierten SD-Karte ausprobieren wollte, musste ich feststellen, dass bei FAT32 der Einsprung Offset bei $58 liegt, und nicht wie bei FAT12/16 bei $3C. Somit hat man unter FAT32 für den Code 28 Bytes weniger Platz, was dann nicht mehr ausgereicht hätte.

Ausserdem habe ich einige per JSR aufgerufene Unterroutinen wie ADD_32_32 etc. die nach dem Verschieben des Codes nicht mehr funktionieren würden.

Eine Auslagerung der Unterroutinen in das BIOS ROM finde ich nicht so gut, da dann eine Portierung des Betriebssystems wieder schwerer gemacht wird.

Ich habe mich deshalb entschlossen (wahrscheinlich macht das Windows auch so), für FAT12/16 und FAT32 verschiedene Bootstrap Loader zu schreiben, die dann bei der Formatierung entsprechend in den Bootblock geschrieben werden. Eventuell braucht man für FAT12 formatierte Disketten auch einen extra Loader, da der Code meines Wissens, bei unter M$-DOS formatierten Disketten, bei einem Offset von $1E begonnen haben. Unter Windows formatierte Disketten haben dann aber wieder den Offset $3C.

Jedenfalls funktioniert unter FAT16 der Loader jetzt, läd den ersten Block der Datei BOOT.SYS in den Speicher und führt ihn aus. Das ist jetzt das erste mal, dass ein Programm auf dem Junior ][ nicht via XModem vom PC übertragen wurde. Dazu jetzt die ersten Takte von "Also sprach Zarathustra" ... Bombom Bombom Bombom Taaa Taaaaaa Tataaaaaa...

Zitat von Dietrich

FAT12 würde ich nicht mehr in Betracht ziehen. Das benutzt niemand mehr. Keep it simple

Das nächste Hardwareprojekt wird ein Floppy Controller und eine Grafikkarte. FAT12 ist also ein Muss. Ausserdem warum Simpel, wenn es auch spannend geht?

Zitat von ThoralfAsmussen

Kennst Du evtl. die Idee hinter dem Bootloader GRUB von den Linux-Geschichten ? Die laden da mit Stufen 1.5 , soll runtergebrochen auf hier heißen, daß man generisch erstmal nur rausbekommt, was für ein Format die RAMcard hat und dann passend ein BOOT12.SYS oder BOOT16.SYS oder BOOT32.SYS nachlädt, die schlicht alle auf der RAMdisk liegen.

Das hatte ich auch schon überlegt, falls die Treiber nicht in die 512 Bytes passen sollten. Ich werde aber erst mal schauen, wie viel Platz ich für den Code brauche. Im ersten Block müssen ja auch nur die FAT Read Treiber rein. Das macht die Sache deutlich einfacher.

Zitat von Dietrich

Wenn wir dann noch dafür sorgen, dass alle Images in lückenlos aufeinander folgenden Sectoren liegen, haben wir gewonnen.

Das dürfte schwierig werden, wenn man die Images unter Windows, Linux oder MacOS speichert. Die Chance ist zwar bei einem leeren Datenträger groß, dass die Cluster alle aufeinander folgen, aber falls sich z.B. ein defekter Block auf der Platte befindet, kann das schon wieder ganz anders aussehen.

Hier nun mal die neueste BIOS Version (1.0.5), die ihr benötigt, um eure eigenen SD-Karten Boot Versuche zu starten. Ich musste in der Routine LOAD_LBA auch noch einen Fehler fixen, der bei SD-Karten bis 2GB auftrat. Hier wurde die endgültige (Byte orientierte) Adresse nicht richtig berechnet, weil ich vergessen hatte nach dem Bit-Shifting das LSB mit $00 zu füllen. Die Variable SD_TYPE ist von $EE nach $1A gewandert, um nicht mit Dietrichs CPM-65 zu kollidieren. Das sollte aber für die meisten von euch eh irrelevant sein.

In der ZIP Datei "Boot Code" findet ihr eine Anleitung zum Erstellen einer passenden SD-Karte. Statt der beigelegten BOOT.SYS könnt ihr auch eure eigenen Versuche unter diesem Namen auf die Karte schreiben. Einschränkung ist allerdings die Größe, welche 512 Byte nicht überschreiten darf.

Nächste Woche werde ich meine BOOT.SYS weiterschreiben und die FAT Read Treiber integrieren.

Ihr könnt mir gerne jederzeit Feed Back geben und natürlich auch Fragen stellen, wenn sich welche auftun sollten.

Cheers

Jörg

Hallo Norbert

Zitat von NorbertJ

müßte unter der Sparte 'OEM-String ändern' nicht der zweite Programmstring nicht identisch mit dem ersten sein? Im zweiten steht am Anfang ' 600 - B0' anstelle des '600 : EB' zuvor.

Die Code Sequenz die du bei $600 eingeben musst, beginnt mit EB 3C 90. Das ist der originale x86 Code der im Boot Block steht. EB ist hier ein Short Jump, 3C der Sprungoffset und 90 einfach ein NOP.

Nach dem Booten des Junior II siehst du dann aber ab $600 den Code B0 3C 90, da das Junior BIOS den x86 Short Jump gegen einen 6502 BCS Befehl austauscht.

Hintergrund ist (und ich glaube das früher schon erwähnt zu haben), dass Windows den Datenträger nach dem Vorhandensein der Sequenz EB 3C 90 untersucht. Ist diese nicht vorhanden, möchte Windows deine SD-Karte gleich wieder formatieren wenn du sie am PC einliest. Deshalb tauscht der Junior das EB erst nach Einlesen des Boot Sektors direkt im Speicher aus und springt dann nach $600. Da von der BIOS Routine bei fehlerfreiem Laden des Boot Blocks zuvor das Carry Flag gesetzt wurde, verzweigt dann B0 3C an die Adresse, an der der Boot Strap Loader steht ($63E), welcher dann wiederrum die Datei BOOT.SYS sucht, läd und ausführt.

Warum wird bei dir übrigens der Boot Strap Loader bei $064A durch ein Break abgebrochen?

Hast du den Loader Code vor dem Schreiben des Boot Blocks auch schon in den Speicher geladen, oder hast du nur die ersten 11 Bytes geschrieben, um den OEM String zu ändern?

Edit: Ich werde bald ein einzelnes Programm basteln, dass den gesamten Boot Strap Loader Code in einem Rutsch schreibt. Jetzt ist das alles noch sehr rudimentär mit den drei Schritten, die auf dem Junior ausgeführt werden müssen. Sorry.

Hallo Norbert,

nachdem du die oben genannten Schritte gemacht hast, hast du dann ja mit Sicherheit wie beschrieben den kurzen Code an $3000 noch ausgeführt und somit den Boot Block auf SD-Karte gespeichert. Somit sollte der erste Schritt fertig sein. In der BootCode.Zip befindet sich auch noch die Datei BOOT.SYS, welche du einfach unter Windows auf die frisch erstellte SD-Karte kopierst. Dann die Karte wieder in den Junior stecken und neu starten. Danach sollte die Boot Meldung

This is M/OS 65 Version 0.1

erscheinen. Fertig. Das Demoprogrämmchen macht nicht viel, ausser einen ">" Prompt und deine Eingaben auf den Bildschirm auszugeben. Endlosschleife. Abbruch mit der Taste ST der Hex Tastatur.

Statt der beigelegten BOOT.SYS kannst du nun allerdings auch ein eigenes Programm schreiben, welches an Adresse $2000 beginnt. Assemblieren, die Bin Datei in BOOT.SYS umbenennen, auf SD-Karte kopieren und davon booten. Dann wird dein eigener Code ausgeführt.

Übrigens: Da der Boot Strap Loader aus Einfachheitsgründen nur im ersten Root Directory Block nach dem Eintrag "BOOT.SYS" sucht, bringt es nichts, auf eine bereits gut gefüllte Karte diese Datei zu schreiben, da diese dann womöglich erst in zweiten, dritten oder gar zehnten Block auftaucht. Also die Datei BOOT.SYS am Besten gleich nach dem Formatieren draufkopieren. Macht MS DOS glaube ich auch so.

Zitat von NorbertJ

mit 0600.06FF steht in der ersten Zeile EB anstatt B0

strange oder liegt es am Userinterface?...

Der Befehlscode EB wird natürlich erst nach einem Reset - sprich Reboot - ausgetauscht.

So, nach einer langen (aber kurzweiligen) Fernwartungssession mit NorbertJ sind wir dem Phänomen auf die Spur gekommen, warum bei Norbert der Boot Block nicht auf die SD-Karte zurückgeschrieben werden konnte.

Grund ist, dass ich in der Beschreibung geschrieben habe, ihr sollt den Bootstrap Loader einfach mit LM via XMODEM in den Speicher laden. Das Problem ist nun, dass XMODEM immer ganze Blöcke mit einer Größe von 256 Bytes läd. Beim Bootstrap Loader heißt das, Startadresse ist $63E und die geladene Endadresse ist somit $83E ($63E + 2 x 256 Bytes). Die Endadresse des Block Buffers liegt aber bei $7FF. Daher werden 62 Byte in den IO Bereich geschrieben.

Meine IO Karte ist auf K4 gejumpert, also Anfangsadresse $1000. Die von Norbert (und möglicherweise von den meisten anderen) ist aber auf K2 und somit $0800 ! Die 62 Byte überschreiben also fleißig die Register der beiden VIAs und machen somit die Kommunikation via SPI und somit zur SD-Karte unmöglich.

Die Lösung ist jetzt erst mal einfach. Statt eines einfachen LM Befehls nehmt ihr 600.7FF LM, was den Ladebereich einschränkt. Ich hab das in der Beschreibung auch gleich geändert. Ich werde aber einen "Bootblock Creator" schreiben, der dann die einzelnen Schritte vereinfacht. Wird aber leider noch ein paar Tage dauern.

Bis dahin könnt ihr das aber jetzt so wie in der Anleitung beschrieben zusammenschustern.

Gerade eben bin ich mit dem Code für die BOOT.SYS soweit fertig geworden, dass diese auch verteilt auf verschiedene Cluster unter FAT16 sauber geladen wird. Der Code für FAT32 ist auch schon drin, aber noch nicht getestet, da ich den Bootstrap Loader für FAT32 noch nicht geschrieben habe.

Erfreulich ist, dass ich noch 180 Bytes im ersten Block übrig habe, um den FAT12 Loader unterzubringen. Das sollte reichen.

Der Boot Code berechnet jetzt die benötigte Anzahl der Blöcke, die eingelesen werden müssen, um BOOT.SYS vollständig in den Speicher zu laden.

Ich hab im ersten Schritt die Datei künstlich auf 4KB aufgeblasen und gespeichert. Die Clustergröße des FAT16 Volumes ist ebenfalls bei 4KB (also 8 Blöcke).

Um die Cluster auf dem Volume auseinander zu reißen, hab ich dann eine andere Datei auf SD-Karte gespeichert, BOOT.SYS auf 16KB vergrößert, wieder eine neue Datei dazwischen gespeichert und zum Schluss BOOT.SYS auf 32KB vergrößert. Im Code werden dann noch alle 4KB Marker gesetzt um zu schauen, ob alles da ankommt, wo es hingehört.

Im Test Code können beim Booten die geladenen Blöcke in ihren Cluster Ketten angezeigt werden.

Hier sieht man, dass zuerst die verbleibenden 7 Blöcke an LBA $000A26 bis $000A2C des ersten Clusters noch eingelesen werden (der erste Block ist ja schon im Speicher). Dann wird der zweite Cluster mit den Blöcken an $000A5D bis $000A64 gelesen. Danach folgen noch 6 Cluster im durchgängigen Bereich $000A7D..$000AAC.

Zum Schluss noch der Test, ob alle Marker im Speicher stehen

In der Zip ist mal die BOOT.SYS mit 32KB Größe und ohne Anzeige der geladenen Blöcke. Zum vollständigen Laden benötigt der Junior ][ bei mir 1,67 Sekunden, was mit den zwischengeladenen FAT Blöcken dann einen Durchsatz von 21,6 KB/s macht.

Um die BOOT.SYS größer oder kleiner zu machen müsst ihr nur die ORG xxxx Zeilen im Code ändern/rausschmeissen und dann neu kompilieren. Die assemblierte Datei BOOT.BIN in BOOT.SYS umbenennen und dann auf Karte kopieren.

Morgen mache ich dann noch den FAT12 Code fertig.