Beiträge von Diddl

    In WinCupl gibt es einige Beispiele für ATF Programme, im Internet findet man aber kaum etwas. Anbei ein getestetes Programm für einen zweifachen BCD to 7 Segment decoder ( sollte mal eine Anzeige für eine POST Karte werden ).

    Der CPLD wurde/wird hauptsächlich in industriellen Umgebungen eingesetzt.

    Auch in ganz alten PC Karten (ISA) wurde der CPLD gerne verwendet.


    Aber es gibt auch einige Retro Projekte wo der drin ist.

    Und ich habe nun ja auch schon etliche Projekte damit gemacht ... :)

    Ich verwende den ATF15xx sehr gern, es ist ein sehr zuverlässiges Teil.

    Zum einen lässt sich damit der ATF programmieren , zum anderen aber auch die programmierten Funktionen testen.

    Diese Test Funktion gefällt mir sehr gut.



    Dazu wäre es wünschenswert, dass ein Arduino Programm diese CPLD Testfunktion unterstützt.

    So in der Art wie der TL866 die TTL testet.

    Also ein einfaches Textfile, das man einfach in den Arduino Serial Monitor.

    Pro Zeile: digitale Ausgänge setzen + erwartetes Eingangs Muster

    Damit könnte man auch komplexere Abläufe testen (Register schreiben, lesen ...).

    Ich mag meinen Dragon 64.

    Das robuste Gehäuse und auch das Keyboard.


    Technisch gesehen ist es halt nur ein Tandy CoCo-2.


    Es wäre schön, ein Dragon Motherboard mit einem PLUS:

    • CoCo-3 oder gleich noch weiter gehend
    • und doch kompatibel zum Dragon 64

    Die Implementierung der MMU im OS9 Level 2 ist eine katastrophale Bastelei.


    Der Code wird direkt im Kernal Sourcecode gepatched.

    Keine Auslagerung in ein Modul oder Treiber.

    Nicht mal eine Auslagerung in Include Dateien.

    Die haben wohl für jede unterschiedliche Hardware einen eigenen Kernal entwickelt!


    Im NitrOS9 gibt es eigentlich nur noch zwei Ziel Plattformen:

    • Tandy CoCo-3
    • MC09

    Beide Plattformen eignen sich leider nicht gut als Basis für meine SBC-MMU Hardware.



    Aber es gibt ein wunderschöne, uralte Hardware, die fast ident ist zu meiner SBC-MMU Hardware.

    Und es gibt eine OS9 Implementierung für diese Plattform ...


    Der Positron 9000 ist eine sensationelle Maschine!

    Das Ding ist einfach unglaublich!




    Nun habe ich mich mit dem Positron 9000 Kernal intensiv auseinander gesetzt.

    Das hat meine verklärte Sicht auf die Motorola MMU 6829 etwas erschüttert.


    Die schöne Welt, die im "OS9 L2 System Designer Guide" beschrieben wird, die hat auch Schattenseiten:

    Die MMU 6829 bietet "System Schutz" und echte 64K für jeden Task (protected Mode).

    Dafür zahlt man jedoch einen sehr hohen Preis!!



    Jeder Usertask hat seine eigenen 64K vollständig zur Verfügung.

    Der Code läuft in einer Sandbox die absolut sicher ist.

    Etwas das sonst nur viel neuere Systeme bieten können.


    Das funktioniert deswegen, weil die MMU 6829 erkennt, dass die CPU einen Interrupt oder SWI Befehl ausführt.

    Die MMU wartet, bis die CPU alle Register Werte auf den Stack gelegt hat.

    Genau zu diesem Zeitpunkt schaltet die MMU in die System Map und aktiviert den Superuser Modus.

    Die CPU fetched nun den entsprechenden System Vektor (in der System MAP!!) und springt zu dem System Code.


    Soweit so gut, klingt alles wunderschön.

    Doch nun fangen die Probleme an.

    Leider wollte man OS9 L2 binär kompatibel mit L1 machen, damit alte Programme einfach so laufen können.

    OS9 System Funktionen ruft man mit einem SWI Befehl auf.

    Dem SWI Befehl folgt der Funktionscode.


    Für L1 ist das keine große Sache.

    Die Systemfunktion holt sich den PC (program counter) und liest das Byte nach dem SWI Befehl (Funktionscode).

    Dann die der PC am Stack inkrementiert, damit nach der Rückkehr aus der Systemfunktion der folgende Befehl ausgeführt wird.

    Der Funktionscode wird als "übersprungen".


    Für L2 ist das selbe eine Schwerarbeit:

    • um den Inhalt des PC vor dem Aufruf zu kriegen, muss man den User Stack zugreifen
    • der Userstack liegt in der User Map, und man weiß ja nur die logische Stack Adresse in der User Map
    • also logische Adresse in der User Map umrechnen in Page Nummer und Page Adresse
    • die Page temporär in der System Map einblenden und den Wert des PC auslesen
    • der PC Wert um eins inkrementieren
    • nun ist auch der Wert des PC nur eine logische Adresse ...
    • also logische Adresse in der User Map umrechnen in Page Nummer und Page Adresse
    • die Page temporär in der System Map einblenden und den Wert des PC auslesen (Funktionscode)


    Alles in allem recht komplexer Code, einige hundert Befehle ...

    Die erzwungene L2 Kompatibilität ist sehr, sehr teuer!



    Im Falle eines Interrupt ist der L2 Mehraufwand nicht so schlimm.

    Aber natürlich sind praktisch alle Adressen 24 Bit lang statt nur 16 Bit.

    Und man muss ggf. eine Page einblenden um Modulcode ausführen zu können.


    Zugriffe in User Buffer Bereiche sind auch viel komplexer.

    Es müssen immer entsprechende Mappings gemacht werden und die neuen Offset Adressen errechnet werden.




    Fazit:


    Die Kosten für die Sprengung der 64K Begrenzung sind hoch.

    L2 läuft definitiv um einiges langsamer als L1.


    Aber es ist die Sache schon wert.

    Speziell dann, wenn man Multi User Betrieb anbietet wie die Positron 9000 Maschine.


    Die Stabilität ist halt dadurch wirklich extrem gut.

    Keine Seiteneffekte durch andere Software.

    Kaum noch Begrenzungen durch Speicher und andere Ressourcen.

    OS9 Level 2


    Neben zahlreicher kleiner Verbesserungen gibt es folgende Neuerungen gegenüber L1:

    • Speichergröße mehr als 64K
    • Jeder Task kann bis zu 64K für sich alleine haben
    • Trennung von System und Usermode (Schutz)
    • Unterstützung einer MMU


    Um einige oder alle Neuerungen auch wirklich nutzen zu können benötigt man eine MMU.

    Aber nicht jede MMU unterstützt alle Neuerungen.



    Die MMU im Tandy CoCo-3 zum Beispiel ist extrem minimal ausgelegt:

    • Page Größe 8KB (statt der empfohlenen 2K)
    • nur 2 Tasks, wobei Task# 0 immer System ist
    • keine Trennung von System und Usermode
    • keine automatische Umschaltung in den Systemmode bei Taskwechsel


    Das ist bitter, der CoCo-3 profitiert daher nur von einer einzigen Neuerung im Level 2:

    • Die Speichergrenze von 64K wurde durchbrochen

    Leider stehen für den Usertask nicht die ganzen 64K zur Verfügung im CoCo-3.

    Die obersten 512 Byte sind über alle Tasks gleich.

    Das ist notwendig, weil der IRQ und der SWI Befehl keine automatische Umschaltung zum System Task macht.

    In den obersten 512 Bytes stehen die Vektoren und der Code für die Task Umschaltung.


    Es gibt auch keine Schutzfunktion, weder des Systemtask noch Speicherzugriffe außerhalb der eigenen Map.

    Jeder Usertask kann das System abschießen und andere Tasks beeinflussen.

    Auch die IO sind für jeden Task sichtbar und zugreifbar.

    Letztes Jahr habe ich das C64 SPS Projekt gemacht.

    Da ist auch eine BASIC Befehle Erweiterung mit dabei.


    Das kann man gut als Basis verwenden für eigene Projekte.

    Da kann ich auch gerne behilflich sein.


    Es funktioniert in mehreren Schritten:

    • Token/Befehle Tabelle
    • Befehl zu Token Routine (bei Eingabe einer BASIC Zeile)
    • Token zu Befehl Routine (für den LIST Befehl)
    • Code für jeden einzelnen neuen Befehl


    Dazu habe ich die BASIC Formel Auswertung erweitert.

    Jetzt kann man zB. Hexadezimal Zahlen verwenden indem man ein $ Zeichen voran stellt.

    Und man hat eine Funktion die den Wert eines IO Punkt abfragt.



    Die Erweiterung kann auch Befehle die nicht in Token verwandelt werden.

    Weil sie nur im direkt Modus funktionieren, wie zB. RENUM und UNNEW.

    Auf dieser Seite sieht man in einer Zeitleiste die Evolution der Mikroprozessoren:



    Leider ist es nicht ganz vollständig und sehr Intel lastig.

    Zb. fehlt mir der 6809.




    Was für mich sehr überraschend war, der Intel 8086 wurde wurde schon 1978 gebaut!!!!


    Zu der Zeit waren sonst nur 8 Bitter am Markt.

    Da war gerade mal der PET und der Apple verfügbar.

    Also da war Intel aber wirklich seiner Zeit um Längen voraus!


    Allerdings dauerte es ziemlich lange, bis der 8086 dann auch in Stückzahlen verbaut wurde.

    Der 8088 kam erst fast ein Jahr NACH dem 8086.

    Und der 8088 wurde öfter verkauft und viel früher in Hardware eingebaut als der 8086.


    Die Welt wahr wohl noch nicht reif für den 8086 ...

    Im Grunde kann das jedes XUM device (Zoomfloppy).


    Ist nur eine Frage der Firmware.

    Die müsste die SD2IEC Firmware etwas modifizieren.


    Das XUM hat einen USB Atmel (u16, u32) die können mit USB Sticks.

    Und es hat IEC Interface für einen C64 (VC-20, C-128).


    Das original Zoomfloppy hat sogar IEEE-488.

    Da würde es auch mit einem PET, CBM oder CBM-II klappen.

    Es läuft auch heute noch... Inzwischen auf über 20000 Medizingeräten...

    Heute auch noch!


    Dass man das noch nicht auf was neueres portiert hat, verwunderlich ...

    Ist die Zulassung neuer Hardware in dem Bereich so schwierig?




    Driver dynamisch laden und entladen ist eines.

    Hardware im Betrieb anschließen und entfernen (Hot Plugging) ganz was anderes.

    Bei USB ist uns das heute selbstverständlich.

    Aber ich weiß auch noch von Steckkarten die man im Betrieb rein stecken konnte.


    Worauf muss man da achten?

    Kontakte für Stromversorgung länger machen, damit die zuerst Kontakt haben?

    Irgendwas an der Bauteil Selektion, dass die nicht versehentlich den Bus blockiert?

    OS9 ist soooo genial!

    Man kann Driver Code im Betrieb entwickeln, laden und testen.


    Der neue Driver hat eine höhere Revision Nummer. Sobald man den Code lädt, verwendet OS9 den neuen Code mit der höheren Revision Nummer, der alte Code bleibt geladen. Wenn es Probleme gibt, kann man den Code einfach wieder entladen und der alte, funktionierende Driver, der ja noch im Speicher ist, läuft wieder.


    Schon klar, moderne OS wie Linux können das auch. Aber OS9 lief schon 1979!!!

    1979!!!

    Leider kann ich die EPROMs nicht auslesen. Kann ich aber gern machen - muss mir nur ein Lesegerät kaufen - gibt es da einen Tipp?

    Empfehlen würde ich den TL866.

    Das Gerät ist preiswert, robust und kann viele gängige Speicherbausteine lesen und schreiben.


    Die 2532 kannst du damit nur auslesen, wenn du dir einen Adapter Sockel bastelst.

    Die PIN Belegung ist leicht unterschiedlich zu den gängigen 2732.



    Alternativ kannst du die Speicher auch vom CBM aus lesen über ein BASIC Programm.

    Dazu müsstest du aber das Ergebnis speichern können (Floppy Disk oder Tape oder SD Kartenlösung).

    Wie sind die Transmeta den so? Funktionieren die Ordentlich oder machen die manchmal Probleme wie damals die Cyrix 5x86 und Auftragsfertiger?

    Also ich kann nicht klagen, läuft nun im Dauerbetrieb seit 72 Stunden.

    Ist sehr flink und extrem kompatibel.

    Wird kaum handwarm, braucht offenbar wenig Strom.

    Ich bin äußerst zufrieden, es gibt nichts was nicht perfekt läuft.


    Es hat sogar einen freien PCI Slot.

    Echte RS232, ein LPT Port, PS2 Maus und Keyboard, VGA mit 32bit Farbpalette, Audio, Ethernet, 4x USB,

    Win98 erkennt alle Devices bisher tadellos von selbst ...


    Es bootet sogar von USB.

    USB Keyboard und USB Maus gehen auch, aber leider nur unter WIndows.

    Nun ja, mein Vater hatte immer HP Rechner.

    Ich hab da nicht wirklich eine Ahnung davon.


    Wenn die Tasten nicht mehr gut funktioniert haben, dann hat er die Kontaktflächen mit einem Kohlestift behandelt.

    Danach lief es wieder perfekt wie neu.

    Fun-Fakt: Der Futro S220 hat eine Transmeta-CPU (Crusoe TM5800) drin... :)

    Ja genau, ein TM5800 mit 800 MHz Takt.


    Verhält sich aber exakt wie eine 80486 CPU ...

    Das Code Morphing arbeitet wirklich gut.

    Sonst würde ja irgendwas nicht funktionieren.


    Welcher Taktfrequenz einer x86 entsprechen wohl die 800MHz.

    Ich kann dazu nichts finden im Netz.




    Ein Windows 98 Mini PC: Fujitsu S220



    Richtig cool mal wieder Win98 zu sehen.

    Ganz ungewohnt.


    Es laufen alle DOS Spiele tadellos.



    Richtig cool das kleine Ding.

    Hat gerade mal die Größe eines Router und braucht kaum Strom.

    Der Befehl PRINT <String> reserviert Speicher im Himem Bereich.

    Also von oben nach unten wachsend.


    Wenn der RAM Speicher im obersten Adressbereich defekt ist, bekommt man dieses Ergebnis.


    Das selbe passiert, wenn der Zeiger in den HiMEM nicht ins RAM zeigt.

    Das passiert zum Beispiel, wenn man beim C64 ohne Cartridge hochfährt (38K RAM).

    Und dann eine Cartridge einschaltet.

    Dann ist der HIRAM plötzlich im Modul ROM Bereich, da ja nur 30K Frei sind und BASIC aber an 38K RAM glaubt.

    NitrOS9 Level 1 läuft absolut stabil und flink.

    Es startet von SD Karte in unter einer Sekunde, schneller als ein PET oder C64.



    Beim Start hatte ich nur zwei Floppy Laufwerke a 720K.

    Die Floppy Laufwerke werden emuliert durch einen Arduino Nano an dem eine SD Karte angeschlossen ist.

    Auf der SD Karte gibt es pro Laufwerk eine Image Datei, kompatibel mit dem DSK Format.

    Der Output vom NitrOS9 Compiler Lauf ist ein DSK und kann direkt verwendet werden.


    Das Nano-IO Board emuliert mehrere Laufwerke über Image Dateien.

    Aus der Image Datei erkennt der Nano die Laufwerks Geometrie.

    Im OS9 Modus reagiert der Nano nun auch auf Schreibzugriffe auf Sektor 0 (LSN-0).

    Damit kann die Laufwerks Geometrie nun dynamisch verändert werden.

    Das bedeutet, man kann unter OS9 mit DMODE die Geometrie vorgeben und mit FORMAT die Image Datei erstellen, vom SBC aus.



    Das Nano-IO Board emuliert natürlich auch Festplatten.

    Dazu wird derselbe Treiber (sbc09sd.dr) verwendet.

    Man benötigt einfach einen eigenen Device Descriptor.


    WICHTIG: Für Festplatten muss im DD im Feld INFO das Bit 7 gesetzt sein, sonst funktioniert der FORMAT Befehl nicht optimal!!!


    Um die Cluster Größe auf 1 zu halten, darf die Festplatte maximal 128 MB haben.

    Für einen NitrOS9 Rechner ist aber 128 MB mehr als genug.


    Für NitrOS9 gibt es den SuperDriver:

    SuperDriver - NitrOS-9


    Der SuperDriver ermöglich den optimalen Zugriff auf "modernere" Massenspeicher: IDE, SCSI, CD-ROM ...

    Der Treiber erlaubt fremde Blockgrößen (512, 1024, 2048 Byte).

    Es werden Datenträger bis 4 GB native unterstützt, größere nur über Partitionen.


    Device Driver werden geschrieben für den SuperDriver oder für das Native OS9.

    Für das Nano-IO Board gibt es zur Zeit nur den native Driver.

    Der SuperDriver ist wirklich genial, aber für den SBC09 sehe ich keine Notwendigkeit für Festplatten größer 128 MB .



    Was ich beim OS9 wirklich vermisse sind Joker in Dateinamen (*, ?).

    Abhilfe schafft "ShellPlus", damit bekommt man Wildcard Support und eine Command History wie unter Linux.

    Es kostet jedoch einige KB an RAM.

    Was bei Level 2 dann wieder vollkommen egal ist.



    Einer echter Hit ist das BASIC-09!


    Es ist interaktiv und es kompiliert.

    Da gibt es benannte Funktionen und Prozeduren.

    Das BASIC ist strukturiert, und es ist wirklich sehr schnell.

    Die Bedienung ist sehr gewöhnungsbedürftig, wenn man vom MS Basic kommt.



    C-Compiler


    Nun ja, es funktioniert.

    Ohne Festplatte macht es aber keinen Spaß.

    Das C ist etwas veraltet, aber das Binary sieht wirklich sehr gut aus.



    Das Pascal erzeugt P-Code und läuft relativ flink, aber Pascal ist nicht so meins.