Ein paar Informationen zu OS-9

    Ein paar Worte zu OS-9 für Leute, die diesen Name nicht einordnen können:

    OS-9 ist ein Multiuser-Multitasking-Echtzeit-Betriebssystem von Microware aus Des Moines, Iowa, USA. Die erste Version wurde im Jahr 1979 veröffentlicht. OS-9 gibt's in drei Geschmacksrichtungen:

    - OS-9 für 6809 (8bit)

    - OS-9/68k für 68k-CPUs (32bit)

    - OS-9000 (später doch wieder OS-9) für 68k, x86, ARM, PPC und ein paar weitere.


    Für die Historiker die Anzeige der Firma Microware aus der BYTE 12/1977 mit der Ankündigung des BASIC-Compilers, der ursprünglich für Motorola und deren Entwickler-Boards entwickelt wurde. Aus dieser Runtime-Umgebung entwickelte sich das OS-9 als Betriebssystem für den MC6809. Um 1984 gab's das OS-9/68k mit Aufkommen vieler 68000-Rechner und -Boards.



    Mehr Informationen gibt's historisch in der Wikipedia sowie aktuell bei Microsys, dem heutigen Distributor für Europa.


    Das 8bit-OS-9 fand weite Verbreitung mit dem Tandy TRS-80 Color Computer. Eine Portierung für den SuperPET (mit 6809) gab es auch. OS-9/68k war ab den späten 1980er bis in die späten 1990er Jahre Industriestandard in der Automatisierungstechnik. Die Zielmaschinen waren dort häufig VMEbus-Systeme. Es gab OS-9-Portierungen auch für den Atari ST, den Amiga und diverse Mac-Modelle. Relativ unbekannt ist die Verbreitung von OS-9/68k V2.4 als CD-I.


    Beim 8bit-OS-9 und beim OS-9/68k wurden die Anwenderprogramme typischerweise auf der Zielmaschine entwickelt, Mit OS-9000 setzte sich die Trennung von Entwicklungs- und Zielmaschine durch. Die typischen Programmiersprachen waren neben dem jeweiligen Assembler für zeitkritische und systemnahe Aufgaben C sowie später C++. Es gab weitere Compiler und Entwicklungsumgebungen für BASIC, Fortran, Pascal, Modula-2 und vermutlich noch ein paar mehr.


    Gruß, Ralf


    OS-9 für eigene 68000 Systeme habe ich auf einem 6809 System mit OS-9 portiert.


    Es gab also für das OS-9(6809) zumindest einen Cross Assembler und Linker für 68000.


    Natürlich ist man, sobald das 68000 System lief, auf dieses als Entwicklungssystem umgestiegen ;)


    Der 6809 Rechner wurde übrigens von Dr. Keil geliehen (ich glaube sogar, umsonst)

    Quote from Reinhard

    OS-9 für eigene 68000 Systeme habe ich auf einem 6809 System mit OS-9 portiert.

    Die C-Software aus dieser Zeit war wohl durchgehend mit nur wenigen #ifdef fürs 8bit- und 68k-OS-9 übersetzbar. Ich habe hier ein paar der einfachen Dienstprogramme (fürs 68k/2.2) mit genau solchen Weichen.


    Quote from Reinhard

    Der 6809 Rechner wurde übrigens von Dr. Keil geliehen (ich glaube sogar, umsonst)

    Das läßt Dr.Keil in einem völlig unerwarteten Licht erscheinen :)


    Gruß, Ralf

    Hier gibt es noch einige weitere Informationen zu OS-9 auf 8-Bit-Rechnern und jeweils passende Software dazu.

    Quote from for(;;)

    Was sind eigentlich die genauen Hardwareanforderungen für OS-9 Level Two auf dem 6809?

    Der reine OS9 Kern für den 6809 hat glaub ich nur 8K.

    Der Rest wird dynamisch geladen je nach Bedarf und Anspruch.


    OS9 ist einfach der Wahnsinn.

    Es war lange vor Linux da, und hatte aber schon alles, was man an Linux schätzt.



    Auf meinem CoCo-3 mit 512KB RAM läuft es traumhaft gut.

    Allerdings bin ich inzwischen mit meinem CoCoDev Board sehr glücklich.

    http://www.davebiz.com/wiki/CoCoDEV


    Weil die halt VGA Ausgang hat und auch sonst richtig bequem ist. :)

    Okay, ich präzisiere meine Frage. Level Two benötigt ja eine MMU. Aber was muss die können? Eine oder mehrere (wie viele?) Seiten Speicher einblenden? Wie groß müssen die sein? Müssen die eine feste oder variable Größe haben? Muss zwischen verschiedenen Speicherkonfigurationen umgeschaltet werden können oder wird bei jedem Kontextwechsel die ganze MMU neu konfiguriert? Gibt es Schaltpläne von historischen Beispielimplementationen?

    Quote from for(;;)

    Okay, ich präzisiere meine Frage. Level Two benötigt ja eine MMU. Aber was muss die können?

    Naja, OS9 passt sich an die Hardware an, indem du Module schreibst.

    Du kannst also ein beliebiges Memory Mangement an das OS9 anpassen.


    Im Falle vom CoCo3 läuft das ganz einfach und effektiv:

    • der Speicher hat im Standard 128K, kann aber auf 512 oder maximal 2MB ausgebaut werden
    • die CoCo-3 CPU sieht natürlich immer nur 64K zur selben Zeit
    • der 64 Speicher Bereich ist in lauter 8K Blöcke zerlegt (also 8 Blöcke zu 8K: 0000-1FFF, 2000-3FFF, ... E000-FFFF)
    • jeder dieser 8 K Blöcke kann beliebig im ganzen Adressbereich verschoben werden
    • es sind also 8 Banking Register (8 Bit -- 256 Banks -- 8K * 256 ergibt die 2MB Obergrenze)


    Quote from for(;;)

    Muss zwischen verschiedenen Speicherkonfigurationen umgeschaltet werden können oder wird bei jedem Kontextwechsel die ganze MMU neu konfiguriert?

    Beim CoCo-3 ist es simpel.

    Nur ein Speichermodell.


    8 Banking Register.

    Jeder 8K Block kann im 2MB Bereich frei verschoben werden.


    Von der Hardware her ganz simpel gehalten.


    Wenn man die GHardware kopiert, kann man die OS9 Module 1:1 nutzen. ;)

    Quote from for(;;)

    Gibt es Schaltpläne von historischen Beispielimplementationen?

    Ja.


    Der CoCo-3 ist super dokumentiert.

    Schaltpläne, unzählige Bücher als PDF.


    Ach ja, soviel ich weiß gibt es nur RAM.

    Der ROM wird beim ersten Reset kopiert und dann ausgeblendet.


    Kann sein dass ich mich irre, aber ich weiß von keiner Möglichkeit wieder ins ROM zu kommen (außer durch einen Hard Reset).

    Quote from for(;;)

    Was sind eigentlich die genauen Hardwareanforderungen für OS-9 Level Two auf dem 6809?

    Es ist, ein Jahrzehnt vor Linux, bei OS9 alles "Device Orientiert", wie bei Linux.


    Jedes "Modul" ist ein Treiber für ein "Device".


    Die Module werden dynamisch geladen.

    Entweder automatisch (beim Start) oder weil der User das anwirft.

    Sobald das Modul geladen ist, kann man das "device" ansprechen.

    Also alles was man braucht und will: Floppy, Harddisk, SD, Network, Terminal ...


    Applikationen fordern beim OS Ressourcen an: Speicher, Zugriff, Multitasking (also "Zeit") ...

    Nur mal so zur Info:


    Der Emulator Xroar Online emuliert Dragon 32/64 und diverse TRS-80ger. Dort kann man unter dem Punkt "Utils" auch direkt NitroOS-9 aufrufen und sich mal anschauen. In Verbindung mit dem Buch "Getting started with OS-9" wahrscheinlich sogar ganz komfortabel zum ersten Ausprobieren. :coffeepc:

    Quote from Diddl

    Es ist, ein Jahrzehnt vor Linux, bei OS9 alles "Device Orientiert", wie bei Linux.

    OS-9 wurde eigentlich(!) nach Informatik-Lehrbuch entwickelt, auch wenn so was zu jener Zeit noch nicht weit verbreitet war.


    Es gibt den Kern, der sich um die Ressourcen Rechenzeit, Speicherverwaltung und teilweise Interprozeßkommunikation kümmert, daneben verteilt er die Anfragen (System Calls) an die IO. Diese ist ringförmig um den Kern angeordnet. Es gibt File Manager für blockorientierte Geräte mit wahlfreiem Zugriff (RBF), blockorientierte Geräte mit sequentiellem Zugriff (SBF), Einzelzeichengeräte mit sequentiellem Zugriff (SCF) als Basis sowie etliche weitere für Kombinationen daraus und weiterer Schichtung wie z.B. Netzwerkprotokolle.


    In der Schicht unterhalb eines File Managers sind die Treiber angeordnet. In einer weiteren Schicht außenherum sind die Deskriptoren für einzelne Geräte/Device.


    Jeder Teil davon ist im Speicher ein Modul. Ein Modul ist ein abgeschlossener Speicherbereich gefüllt mit Code oder mit Daten. Dieses kann von Massenspeicher ins RAM geladen werden oder aus dem RAM/ROM auf Massenspeicher kopiert werden. Ein Modul hat eine Organisationsstruktur zur Beschreibung (Name, Länge, Art, CRC, Zugriffsrechte, usw.). Ein Modul kann im RAM oder im ROM liegen. Ein Modul kann an beliebiger Adreßlage liegen, Code in Modulen ist mehrfach und zeitgleich nutzbar (reentrant) und enthält daher keine absoluten Adressierungen. Selbstmodifizierender Code existiert nicht. D.h. ein OS-9-System kann ROM-fähig und sogar ohne Massenspeicher gebaut werden (Embedded System).


    Zur IO als Beispiel eine serielle Schnittstelle: der Deskriptor hat einen nahezu wahlfreien Name. Der Deskriptor enthält Konfigurationsdaten zu den Parametern einer seriellen Schnittstelle wie die Basisadresse des IO-Chips, die IRQ-Nummern und -prioritäten, 9600 8N1 oder auch das Verhalten der Händeschüttelleitungen. Der Deskriptor enthält den Name des Treibers, für den er angelegt ist. Nennen wir den Deskriptor nach einer üblichen Namenskonvention z.B. "s11". Dieser verweise auf seinen Treiber z.B. "sc68681". Das Modul "sc68681" liegt als Treiber-(Code-)Modul im Speicher und enthält die typischen Aufrufe eines Treibers wie Init, Read, Write, Setstat, Getstat, Close. Der Deskriptor enthält weiterhin den Verweis auf den zuständigen File Manager, hier "scf", der ebenso als separates Modul im Speicher verfügbar ist. Das nächste verwendete Device könnte "/s12" sein, daß ebenso den sc68681 als Treiber verwendet, ein folgendes "/s13" könnte dagegen einen anderen Chip und somit z.B. den sc8530 als Treiber nutzen.


    Mit einem Öffnen des Device "/s11" (typischerweise durch ein "_os_open()" innerhalb eines Anwenderprogramms) wird über den File Manager der Treiber-Code des Init-Teils des Treibers ausgeführt, der als Konfigurationsdaten den Deskriptor erhält. Hier wird die Hardware konfiguriert, die nötigen Speicherbereiche reserviert und das Device in die Liste der verfügbaren Devices eingetragen. Beim Close geht das rückwärts.


    Also ganz einfach :) Alle Module liegen im RAM- oder ROM, für den Betrieb wird i.A. etwas RAM pro initialisiertem, also verfügbarem Device benötigt. Erkennbar an dieser Struktur ist, daß ein File Manager mehrere Treiber "unter sich" haben kann, und daß jeder Treiber mehrere Deskriptoren "unter sich" haben kann. Logisch an dieser Struktur ist, daß jederzeit ein anderer File Manager, Treiber oder Deskriptor nachgeladen werden kann oder in umgekehrter Richtung bei Nichtgebrauch aus dem RAM entfernt werden kann.


    Das ist in Kurzform die Verwaltung von IO-Geräten im OS-9 (in allen drei Geschmacksrichtungen).


    Gruß, Ralf

    Quote

    Microware OS-9® offers out-of-the-box support for a broad array of processors and architectures:

    • 68K / Coldfire
    • x86 / Pentium/Multi-Core
    • PowerPC : 4xx, 5xx, 6xx, e500, e5500, e6500
    • Arm®: Arm9, StrongArm, XScale, ARMv4, v5, v6, v7, v8
    • SuperH : SH-3, SH-4, SH-4A


    Kann mittlerweile auch noch ein paar andere Sachen als reine Homecomputer mit 8Bit Chips.



    PowerPC war wohl das erste wirklich "andere" Lager.






    Interessant fand ich ja auch, daß der C Compiler - namens UltraC - da anscheindend schn relativ zeitig sowas in der Art gemacht hat (möglicherweise), wie die aktuelle von/bei Apple angeschobene Variante mit dem Clang, was ja auch erstmal in so einen "Zwischenlayer" übersetzt. Seite 7 im PDF FasTrak Brochure.pdf



    Warum man aber eine Entwicklungsumgebung im Feindeslager aufsetzt, das versteht man dann wirklich nicht mehr. Insbesondere wo sie als Firma ja anscheinend eine geplante Übernahme durch Microsoft rundheraus abgelehnt haben und v.a. es zu der Zeit ja schon "freies" Xorg gegeben haben muß.





    Scheint ja aber abseits der allgemeinen Computerei trotzdem ganz gut funktioniert zu haben. Dann aber eben leider unter der Wahrnehmungsschwelle des geneigten PC Users; von den vermutlich abstrusen Lizenzgebühren (Auto, Weltraum, Großindustrie) mal ganz abgesehen, die man ja nicht für ein Büronutzer untergraben hätte.




    Immerhin scheint es sogar mit der "Microbox 3" [ Microbox 3 Datasheet (Micro Concepts).pdf ] sogar mal einen Ansatz für eine Art Homecomputer-fähigen Rechner gegeben zu haben, der unter OS-9 betreibbar gewesen wäre. Mit bißchen add-on hätte das sicherlich ein schönes Teil werden können. Hat aber anscheinend noch nichtmal geschafft ein "definiertes" Gehäuse zu bekommen.



    Klingt aber schon interessant. Und sieht auch überschaubar aus.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Edited once, last by ThoralfAsmussen ().

    Like 1

    Das OS-9000 (siehe mein erster Beitrag zur Unterteilung) kam im Jahr 1989 auf den Markt. Es war von Anfang an drauf ausgelegt, daß es relativ CPU-unabhängig aufgebaut ist, weil die in Assembler geschriebenen Anteile minimal waren. OS-9/68k ist dagegen in seinen Systemkomponenten sehr assemblerlastig.


    Diese erste OS-9000-Version gab es für den 80386. Die ersten PowerPC-CPUs wurden erst 1994 unterstützt. Ok, vorher gab's fast keine käuflch. Die IBM-RISC-Maschinen kamen Ende 1993 auf den Markt, die PowerMacs mit dem PPC601 im März 1994 in großer Stückzahl. In der Embedded- und VMEbus-Welt dauerte es danach noch ein paar Monate, bis es Karten gab.


    Was die Trennung von Entwicklungs- und Zielmaschinen angeht war es zuvor in der Embedded-Welt üblich diese Trennung zu haben zelebrieren :) OS-9 war damals vermutlich das einzige System, bei dem man auf der Zielmaschine sinnvoll entwickeln konnte. Insofern paßte Microware seine Software nur an die Gewohnheiten des Marktes an. Enwickler wollten damals vermehrt ihre Entwicklungsumgebung für Mausschubser. GUIs auf OS-9 waren nicht verbreitet. FasTRAK gab es (AFAIR) nicht nur in den Windows-Welten, sondern auch für Solaris.


    Zu den C-Compilern unter OS-9/68k: in der Anfangszeit bis in die frühen 1990er Jahre gab's von Microware den alten K&R-C-Compiler. Er konnte C. Fertig. Es war vermutlich der, der auch schon auf dem 8bit-OS-9 lief. Es gab keine Optimierungen, es gab teils recht lausigen Code. Seinerzeit schrieb ich C so, daß es gut für die Code-Erzeugung von genau diesem Compiler war. Microware hatte das Problem irgendwann erkannt. Währenddessen hatte jemand den Gnu-C auf OS-9 portiert, und ich erkannte die bessere Code-Qualität. Aber dann startete Microware die Compiler- und Entwicklungsumgebungsoffensive. Der Ultra-C-Compiler baut (gemessen am Erscheinungsjahr) richtig guten Code und kennt insbesondere zahlreiche Optionen, die Code-Dateien zielsystemgerecht zu generieren. Hier läuft gerade der UltraC 1.3 auf einer MVME177, und ich finde den gut :)


    Noch was zu typischen Zielmaschinen für OS-9: viele waren und sind an Stellen, wo man sie als "normaler Mensch" nicht wahrnimmt. Ich erwähnte die CD-I-Geräte. Typische Embedded-Lösungen waren im Automotive-Bereich z.B. Motorsteuerungen, es gab Ampelsteuerungen, in den Audiomischpulten von LAWO (die gehören zu den guten :) ) steckte jahrzehntelang OS-9, in Fertigungsmaschinen steckten traditionell häufig VMEbus-Rechner mit OS-9, auf der ISS fliegen heute noch solche Rechner mit, usw. Die allerwenigsten von denen werden als solche erkannt. Nur mal zum überschlägigen Drübernachdenken: heute haben viele Menschen ein oder zwei PCs, dazu ein Schlaufon. Was darauf läuft, ist bekannt und manchmal auch eine Religion. Aber wievielen Embedded-Systemen begegnet man täglich bewußt und unbewußt? Wieviele Embedded-Geräte stecken heute in einem durchschnittlichen Auto? Wieviele finden sich in der Küche oder sonstwo im privaten Haushalt? Gehe durch einen Supermarkt und zähle nach, wieviele Embedded Systeme Dir dort begegnen! Die Waagen bei Käse, Obst, Fleisch und Fisch sind meist von Mettler-Toledo. Ich weiß, was in vielen drinsteckt :) Ok, es ist kein OS-9, aber es bleibt den meisten verborgen. Schau Dich in Deinem Leben auf der Straße um! Für den Straßenverkehr gibt's unzählige Systeme zur Steuerung und Regelung. Schau unter die Straße: dort sind die Versorgungsleitungen für Gas, Wasser, Fernwärme Strom, usw. In jedem Netz stecken dutzende, eher hunderte Embedded Systeme.


    Vergiß die paar PCs auf den Schreibtischen. Deren Anzahl spielt keine große Rolle, wenn man die Gesamtzahl an Rechnern mit Betriebssystemen betrachtet.


    Gruß, Ralf

    Wir bauen immer noch Medizingeräte mit OS-9/68k. Sehr embedded, 4 MB FLASH und 2 MB DRAM, MC68EN360/25MHz. Da sich hier nichts so einfach ändern darf, seit über 20 Jahren unverändert.

    Quote from Reinhard

    Wir bauen immer noch Medizingeräte mit OS-9/68k ... Da sich hier nichts so einfach ändern darf, seit über 20 Jahren unverändert.


    Also DAS DARF sich schon ändern - und an manchen Stellen wäre das vermutlich extrem wünschenswert (BGA oder Perfusoren z.B.) ; ABER dann müßte man ja eine Neuzulassung beantragen und wahrscheinlich jede Menge (teure) Tests machen.


    Ist also eher eine "freiwillige" Entscheidung der Firma.



    Da wo ich das OS-9 mal gesehen habe, war auch ein Gerät aus diesem Bereich. War ein Nephelometer dessen "Steuereinheit" ein Atari Mega STE war. Schönes und v.a. extrem auf die Anwendung zugeschnittenes SEHR schnelles Stück Software. Das ist wahrscheinlich auch nur geändert worden, weil es irgendwann keine Mega STE's mehr gab und natürlich ein ARM Board wesentlich günstiger ist. Wahrscheinlich, das OS-9 scheint SEHR konservativ zu sein, konnte man da die eigentliche Anwendung direkt rüberretten ohne eine einzige Zeile zu ändern - es sei denn man hat eine modernere Oberfläche eingebaut.


    Habe auch noch Bilder von einer US Auktion irgendwo, wo man das Teil sehen kann.


    Gab es auch schon als Variante mit Atari Mega ST - und da sicherlich auch schon mit OS-9.


    Das Teil, wohl Designed, Engineered und Made in Germany, hieß: Behring Nephelometer 100




    edit:

    das kleine alte ursprüngliche findet sich leider nicht mehr, aber es gibt den Nachfolger (wahrscheinlich auch noch mit STE, aber da nicht dabei und wohl auch nur zur Datenaufnahme benutzt) DADE BEHRING BN100 (für Bilder runterscrollen)

    https://www.ebay.com/itm/DADE-…00-ANALYZER-/262063831614


    und die aktuelle Großmaschine - ja, ja die Zentralisierung zwecks Geldeinsparung ... - dann schon mit einem fetten Mac

    https://www.usedlabmachines.co…siemens-bnii-nephelometer

    gibt es auch noch neu, aber wohl nur für Großeinrichtungen bezahlbar

    https://www.siemens-healthinee…tein/systems/bn-ii-system


    https://de.wikipedia.org/wiki/Dade_Behring



    edit2:


    https://web.archive.org/web/20…itt030.info/hardrest.html


    auf Seitenmitte gibt es das "Original"

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Edited 2 times, last by ThoralfAsmussen ().

    Quote from ThoralfAsmussen

    Also DAS DARF sich schon ändern - und an manchen Stellen wäre das vermutlich extrem wünschenswert (BGA oder Perfusoren z.B.) ; ABER dann müßte man ja eine Neuzulassung beantragen und wahrscheinlich jede Menge (teure) Tests machen.


    Ist also eher eine "freiwillige" Entscheidung der Firma.

    Natürlich. Versuche gab es mehrere. Aber die Software ist eben auch genau für OS-9 geschrieben und sehr umfangreich. Auch das hätte man alles anpassen müssen. Von den Testkosten mal abgesehen. Vor 20 Jahren waren die Voraussetzungen auch deutlich einfacher.

    Quote from for(;;)

    Okay, ich präzisiere meine Frage. Level Two benötigt ja eine MMU.

    Hab gerade eine interessante Entwicklung von Retro Innovation gefunden:

    http://www.go4retro.com/products/super-os9-mmu/


    Genau passend zu diesem Thread.

    Deshalb wollte ich diesen Link gleich hier dran hängen.



    Diese Platine von Jim ermöglicht es, OS9 auf einem Super-PET zu betreiben.

    Ähm ...

    ... die Super PET Platine hier im Forum - das wäre doch ideal wenn man diese MMU gleich integrieren könnte.



    Im VICE läuft die Sache jedenfalls ganz schön.


    Ehrlich gesagt juckt mein Bestellfinger ...


    Aber irgendwie befürchte ich da Instabilität, wenn im 6809 Sockel noch eine weitere Platine im Stapel ist. :D

    Meine erste OS-9 Portierung habe ich 1985 gemacht.

    OS-9/68k V1.2 für einen VME Bus Rechner mit 68000er CPU, 68564 SIO, 68230 PIO

    und WD1002-05 DIsk Controller.

    Als Entwicklungsumgebung hatte ich dazu einen VME Bus Rechner mit OS-9/68k V1.2

    Meine letzte OS-9 Portierung habe ich 2004 gemacht.

    OS-9/PowerPC V4.2 für eine VME Bus Karte mit MPC8240 CPU.

    Dazwischen habe ich OS-9/68k bzw. OS-9000/PowerPC auf alle möglichen (VME Bus)

    Rechner portiert.

    Ich würde gerne einen OS9 SBC bauen.



    Ganz minimalistisch:

    • SC6309EP (oder SC6309P) mit 3 MHz
    • 512K Flash Speicher
    • 512K SRAM
    • Banking - 4 Blöcke zu 16K - jeder Block kann beliebig im 1MB Raum liegen
    • IO minimal im Bereich FF00-FFEF (240 Byte)
    • serielle Schnittstelle
    • 8 LED
    • µSD Karte



    Banking:




    Was denkt ihr darüber?


    Ist das machbar?

    (Ich meine die OS9 Anpassung, die Hardware ist fertig)

    Quote from for(;;)

    Die Hardware ist fertig? Welche Hardware meinst du?

    Die Basis ist ein sogenanntes ByteMachine:

    https://github.com/c0pperdragon/ByteMachine



    Die Idee dahinter ist:

    • ein MainBoard mit RAM, ROM, Clock, Reset, 8 x LED, Soft-UART, CD Card
    • dazu verschiedenste CPU Platinen


    Es gibt da zur Zeit 4 CPU Boards:

    • i8088
    • z84c00
    • W65C02 - 16 MHz
    • W65C816 - 16 MHz


    Das hat mich motiviert.

    Darum habe ich versucht es zu erweitern:

    • HD6309P (war super simpel)
    • HD6309EP (erste Gehversuche mit eigener Takt Generierung)


    Nun habe ich es schade gefunden dass der W65C02 nur 64K nutzt.

    Deshalb habe ich eine weiteres CPU Board gebastelt:

    • W65C02 - 16 MHz mit 1MB Banking und 7 IO Slots zu je 16 Byte für PIA, VIA, CIA, ACIA ...


    Dann meine erste IO Card:

    • UART TL16C550 um den Soft UART zu tauschen (noch ungetestet - in Arbeit)



    Funktioniert alles tadellos, bei 16MHz!

    Ich bin wirklich erstaunt wie widerstandslos alles läuft.


    Jetzt hat mich der Größenwahn gepackt ...

    • HD6309EP mit 1MB Banking + UART TL16C550


    Eigentlich nur bereits funktionierende Konzepte ...



    Aufgrund meiner extrem guten Erfahrung mit dem C64 SPS Board ist jetzt die finale Version in meinem Kopf:

    • ByteMachine Mainboard, verwende aber nur noch RAM und ROM
    • HD6309EP
    • ein fetter CPLD (ATF1508 oder EPM7128)
    • ein Arduino Nano


    Den Arduino Nano habe ich ja schon erfolgreich mit dem C64 verheiratet.

    Die Verbindung ist ultraschnell, zumindest aus Sicht einer 8 Bit CPU ... :D


    Der Nano ist quasi generelles IO:

    • I2C
    • SPI für SD Card Zugriff
    • serielle COM (USB)
    • Stromversorgung (USB)


    Der Clou ist, der Arduino verwendet FAT auf der SD Card.

    Pro OS9 Laufwerk gibt es eine Image Datei.

    Aus Sicht des 6309 gibt es Sektor orientierte "Laufwerke".

    Block Read/Write wird vom Arduino direkt umgesetzt in der entsprechenden Image Datei.


    Der 6309 merkt gar nicht, dass es keine "echten" Laufwerke sind.

    Daher funktioniert jedes beliebige Dateisystem, Festplatte oder Diskette, ganz egal was.







    Quote from Diddl

    ein fetter CPLD (ATF1508 oder EPM7128)


    Ich bereue inzwischen sehr, meine letzten Projekte auf dem EPM7128 in PLCC basiert zu haben. Neu vom seriösen Händler werden diese Chips mittlerweile mit Gold aufgewogen, preiswert vom China-Mann sind ein wirklich sehr großer Teil entweder direkt kaputt oder fake und der verbleibende, erst einmal benutzbare Teil zeigt hier eine unterirdische Haltbarkeit bzw. Zuverlässigkeit. Oder anders gesagt: die Dinger sterben hier wie die Fliegen. Ich werde nie wieder etwas damit anfangen und denke hin und wieder über Alternativen nach, aber vorerst habe ich den ganzen Krempel erst mal beiseite gelegt.

    Ich versuche gerade NitrOS9 zu assemblieren.

    Unter Windows ...


    Bin fast am verzweifeln.

    Laut NitrOS Seite benötigt man nur die LWTOOLS.

    Die Binaries für Windows PC's sind, - schwierig.

    LWAS.EXE versteht keine Slash, nur Backslash in Pfaden.

    Drum geht das MAKEFILE nicht.


    Hab mir nun LWTOOLS selbst kompiliert.

    Da ist übrigens jetzt ein C Compiler mit drin, - praktisch undokumentiert.

    Na egal.

    Jetzt übersetzt es mir alle ASM Dateien tadellos.

    Auch die Module, mit etwas 'Überredungskunst' ... :D


    Aber jetzt kommt das nächste.

    Das MAKEFILE ruft jetzt "os9 padrom".

    Das geht natürlich nicht.

    Anscheinend braucht man jetzt einen OS9 Emulator um die ROM und DISK Images zu bilden?


    Wo bekommt man denn diesen OS9 Emulator?

    Oder gibt es eine andere Möglichkeit?

    Quote from ngc224

    os9padrom findet man z.B. hier:


    https://jk.kom.tuwien.ac.at/~j…9Tools_Beta1_Linux.tar.gz


    Allerdings ist das für Linux.


    Danke.


    Habs gefunden, man braucht TOOLSHED.

    Gibt es sogar vorkompiliert für WIN32.


    Da gehen all diese OS9 Kommandos.


    Cool! :)