Bei den "Kunstwerken" hatte ich es ja schon vor einiger Zeit vorgestellt, jetzt gibt es auch eine Doku zum Projekt und somit ein erstes öffentliches Release. Und es gibt diesmal wieder einen Emulator. Eigentlich war das ursprüngliche Ziel, einen C-Compiler auf dem Mikrocontroller zu relisieren, über den cc/pcc bin ich dann irgendwie zur PDP11 gekommen. Beim MXE11 handelt es sich um die Emulation einer PDP11 mit 28 KWorten Speicher, auf der ein Mini-Unix läuft. EIS ist implementiert, eine FPU zur Zeit aber noch nicht. Als Massenspeicher werden 3 RK05 Disks via Image auf einem DataFlash (AT45DB642) oder SD-Karte emuliert, wobei bei der SD-Karte das Image "raw" an den Kartenanfang geschrieben wird und somit keine Dateisysteme auf der Karte unterstützt werden. Ein 60 HZ Timer (KL11) ist vorhanden sowie 2 serielle Interfaces. Diese sind auf Emulatorebene mit jeweils 256 Bytes großen Puffern ausgestattet und arbeiten standardmäßig mit 38400 Baud. Das Mini-Unix wurde damals entwickelt, um Unix auch auf Maschinen ohne MMU laufen lassen zu können. Es handelt sich dabei um ein "abgespecktes" V6-Unix, so sind nur max. 4 Nutzer und 13 Prozesse gleichzeitig möglich. Es gibt eine Vielzahl an Tools und es können eigene Programme in verschiedenen Programmiersprachen erstellt werden (ASM, C, BASIC und Fortran/Ratfor, wobei ich letztere nicht getestet habe. Der Emulator läuft auf versciedenen Mikrocontrollern ab 64K RAM, entwickelt habe ich ihn parallel auf einem SPC56EL60 und mit SDL-Konsole unter Linux. Später sind dann noch einige STM32-Versionen hinzugekommen. Freies RAM wird weitestmöglich für Disk-Schreibcache verwendet, bei 64K RAM sind es allerdings nur 4 Sektoren. Das reicht aber aus, um periodische Zugriffe bei einem User abzufangen. Außerdem gibt es noch eine optionale RTC mit einem ATMega88, die ist aber nicht unbedingt erforderlich. Die interne RTC der STM32 wird nicht unterstützt und momentran ist auch nichts in diese Richtung geplant. Eher noch eine MSP430-Variante der RTC. Von der Geschwindigkeit her würde ich den Emulator im "Mittelfeld" sehen, auf jeden Fall lässt sich damit arbeiten. Den kompletten Kernel neu zu übersetzen, braucht auch auf einem STM32F107 mit 72MHz weniger als 10 Minuten. Ansonsten habe ich auch die verschiedenen Emulatorvarianten mit zwei Benchmarks getestet und die Ergebnisse mit veröffentlicht. Das Projekt findet sich unter http://www.jcwolfram.de/projekte/mxe11/main.php dieses Mal gibt es auch eine englische Version, wobei die Übersetzung noch nicht "optimal" ist. http://www.jcwolfram.de/projekte/mxe11_en/main.php Alternativ ist meine Seite auch aus dem TOR-Netz erreichbar: http://tcrkkpvqapdku6vi.onion/projekte/main.php Für das nächste Release steht analoges/digitales I/O an, wofür ich aber erst neue Hardware entwerfen muss. Geplant habe ich auch eine mobile Variante, daher gibt es jetzt schon eine SDL-Version, die ein 320x240 Display emuliert. Gedanken habe ich mir auch über Netzwerkfähigkeit gemacht, diese soll über CAN realisiert werden und sowohl eine virtuelle serielle Verbindung als auch ein viertes (virtuelles) Laufwerk bereitstellen. Aber bis dahin wird es noch etwas dauern... Jörg
Angehängte Dateien:
-
scr1.png
19 KB -
mxe11_32f405_top.jpg
7,1 KB
Irgendwann wird der Tag kommen, an dem ich meine im Keller herumstehende PDT-11/150 abstauben und wieder zum Leben erwecken werde! ;-)
? ? ? ? ? (Für diejenigen, deren Browser die obigen Zeichen nicht darstellen können: Unicode Character 'CLAPPING HANDS SIGN' (U+1F44F))
Da sich die FPU-Emulation noch etwas hinziehen wird, gibt es erst mal einen "Zwischenstand". Eine wesentliche Änderung betrifft den Anschluss der emulierten Festplatte, beim Start wird automatisch erkannt, ob eine SD-Karte oder ein DataFlash angeschlossen sind. Außerdem gibt es jetzt Analog- und Digital-IO, dazu habe ich auch passende Kernelmodule entwickelt. Alternativ lassen sich die Speicherzellen direkt ansprechen. - 4 digitale Inputs, ansprechbar über /dev/gpio /dev/gpio ist ein Character-Device, beim Lesen wird der Status der 4 Inputs (mit Pull-up) als Hex-Char zurückgegeben. - 4 digitale Outputs, ansprechbar über /dev/gpio Beim Schreiben auf /dev/gpio werden nur Hex-Chars ausgewertet, die 4 Ausgänge folgen dem entsprechenden Bitmustern. - 4 analoge Inputs (10 Bits Auflösung) über /dev/adc0 ... /dev/adc3 Die Werte werden als 4-stellige Dezimalzahlen und LF als Trenner ausgegeben. - 4 analoge Outputs (PWM mit 10 Bits Auflösung) über /dev/pwm0 ... /dev/pwm3 Hier wird ein numerischer String erwartet, bei Leerzeichen oder LF im String, wird der aktuelle Wert ausgegeben. Außerdem gibt es jetzt noch einen (Pseudo-)Zufallszahlengenerator über /dev/random und einen Tick-Counter mit 12KHz für Echtzeitaufgaben. Auf der anderen Seite habe ich die Unterstützung für den STM103 eingestellt, da ich auf meinem "Board" (Dead-Bug BGA) nicht mehr an die I/O zum Testen herankomme. Ebenfalls eingestellt habe ich die englische Version der Dokumentation. Jörg
Da ich (aus einem anderen Grund) mir heute den aktuellen MinGW Crosscompiler installiert habe, gibt es hiermit auch eine Version, die unter Windows laufen sollte. Getestet habe ich es allerdings nur mit wine. Dazu einfach das Verzeichnis entpacken und die Exe in dem Verzeichnis starten. Die DLLs und das Image-File müssen auch im gleichen Verzeichnis liegen. Bei genügend Interesse würde ich das ggf. mit in den Hauptzweig aufnehmen. Jörg
:
Bearbeitet durch User
Nachtrag: 1. Das Executable ist eine 64-Bit Version 2. Virustotal hat keine Beanstandungen gemeldet 3. Anstelle AltGr muss man Alt verwenden 4. Ich habe es unter W7 testen können, Z und Y sind noch vertauscht Die anderen Tasten (# * + - ...) hatte ich schon reingepatcht, weil die auch unter Wine nicht gingen. Dabei sieht es so aus, dass ein QWERTY Tastaturlayout verwendet wird. Das scheint aber nur ein Problem bei dem Cross-compilierten Programm zu sein, die Linux-SDL Version verhält sich richtig und nimmt den Keycode Vielleicht weiß jemand, wie man es hinbekommt, dass die Cross-compilierten SDL-Programme das aktuelle Layout verwenden? Jörg
Klasse, was du da wieder gezaubert hast!! Ich würde mich sogar mehr für eine bare Metal pdp11 Emulation interessieren. Quasi das Gegenstück zur PDP11Gui: Danke+Gruß, Peter
Hallo, passt zwar zu meinem Alter, passt aber wohl nicht wirklich zu meinen C-Kenntnissen... Anschauen werde ich mir das auf jeden Fall. Den Kram für den ESP32 gebaut, WLAN mit rein und die Terminals per putty z.B. wäre doch irgendwie lustig. Gruß aus Berlin Michael
Die PC-Version ist eigentlich nur mit abgefallen, weil ich sie bei der Entwicklung benötigt habe. Für Emulation auf dem PC gibt es ja schon SIMH. Zielplattformen sind diverse Mikrocontroller, das sollte "Bare Metal" genug sein. Außerdem läuft z.B. RT11 nicht. Jörg
> Quasi das Gegenstück zur PDP11Gui:
Man könnte sicherlich eine Art "externen" Debugger ähnlich wie beim
AX81/AX82 mit einbauen. Platz ist ja noch genug im Flash der Controller.
Entweder über den zweiten seriellen Port oder über eine zweite
"Bildschirmseite" im Terminalprogramm, zu der man mittels
Funktionstasten umschalten kann.
Da es keinen Speicherschutz gibt, lässt sich direkt auf die Hardware
zugreifen und mit abgeschalteten Interrupts ist der Kernel praktisch
stillgelegt. Für meine ersten Versuche hatte ich das auch so gemacht,
via Pointer direkt in die Hardware-Register geschrieben und das Ganze
auf dem PC mit dem PCC übersetzt.
Als Nächstes will ich die PC-Version (SDL) dahingehend erweitern, dass
sie sich auch als Terminalprogramm für die µC-Version eignet. Eine
offizielle Windows-Variante des PC-Programmes wird es nun auch geben, da
sie quasi mit abgefallen ist.
also z.B "pdp11sim /dev/ttyUSB0" oder "pdp11sim.exe COM15"
Die Entwicklung am Projekt findet aber von meiner Seite weiterhin unter
Linux statt.
Außerdem stehen "Aufräumarbeiten" im Kernel an, insbesondere will ich
die TTYs auf 8 Bit (bis jetzt 7+Parity) umstellen und die nicht
benötigte EIS Emulation entfernen. Dadurch wird auch wieder etwas Platz
für weitere Treiber frei. Oder für eine größere Vektortabelle, was eine
kompatiblere 2. serielle Schnittstelle ermöglichen würde.
Jörg
Das ist doch echt mal ein geiles Projekt! Aber willste nicht nen größeren STM32 mit (mehr internen und/oder) externen RAM nehmen? Dann entfallen die Speicherprobleme. Wie schafft es denn mini Unix ohne MMU Prozesse nachzuladen und zum laufen zu bringen? Für unseren MIPS TTL soll ja auch nochn OS her was Programme/Prozesse nachladen kann. Das wollt ich eigentlich in Hardware lösen mit Paging (verschiedene Speicheradressen sind an 0x00000000 einblendbar) Aber wenn man sich das sparen kann wär das auch gut. Ein C Compiler der recht schnell (und überhaupt) auf ner 4MHz CPU läuft wird ja auchnoch gesucht. Den GCC 4 auf MIPS Compilen und laufen lassen wird sicher seeeeehr schnell ;)
Mw E. schrieb: > Wie schafft es denn mini Unix ohne MMU Prozesse nachzuladen und zum > laufen zu bringen? Es gibt Prozessorarchitekturen, die relokatiblen Code kennen. Das bedeutet, daß Code an beliebige Adressen geladen werden kann und lauffähig ist. Realisiert wird das durch PC-relative Adressierung im Code (d.h. keine absoluten Sprünge). Der gute alte 68k ist eine davon, dessen Vorgänger 6809 war auch eine. Beim x86-PCs wird dafür die Segmentitis und ein patchender Programmlader genutzt. Die pdp11 gehört AFAIK auch in diese Kategorie.
> Aber willste nicht nen größeren STM32 mit (mehr internen und/oder) > externen RAM nehmen? Meine primäre µC Plattform für das Projekt ist der SPC56EL, die STM32-Versionen kamen erst später dazu. Deswegen gibt es für den SPC auch eine ASM-Optimierung, die immerhin fast doppelt so schnell ist wie die Variante in reinem C. > Wie schafft es denn mini Unix ohne MMU Prozesse nachzuladen und zum > laufen zu bringen? Swapping, wie halt bei Unix üblich. Bei einem Prozesswechsel wird der komplette 32K User-Bereich von 0x6000 bis 0xDFFF geswappt. Der Swap-bereich liegt auf dem ersten Device im Bereich über 2MB, daher sind die Images alle nur 2MB statt 2,5MB groß. Um die Platte zu schonen, liegen zwischen dem Wechsel von aktiven Prozessen mindestens 2 Sekunden, außerdem werden die Sektoren dafür "reihum" genutzt. PDP11-Code ist meiner Erfahrung nach nicht generell relokatibel. Aber beim Mini-Unix beginnen alle Programme bei 0x6000 und der Linker ist so gepatcht, dass er Code rauswirft, der bei 0x6000 beginnt. Der vorhandene C-Compiler war bei mir übrigens das ausschlaggebende Kriterium, die PDP11 zu emulieren. Und der CC ist auch recht flott, das Compilieren des Kernels dauert ca. 3-5 Minuten, je nach Controller. Ohne MMU ist man halt auf den 64K (56K RAM) Adressraum beschränkt, den man aber mit gängigen Controllern abdecken kann. Die PDP11-MMU ist meiner Meinung nach übrigens nur recht ineffizient emulierbar, wenn man sie komplett und richtig emulierten will. Denn man muß ja bei jedem Speicherzugriff incl. Opcode-Fetching die Adresse übersetzen. Und dazu muss man zusätzlich schauen, ob die betreffende Adresse überhaupt wohin zeigt. Die Segmente sind zwar 8K groß, können aber auch nur teilweise aktiv sein. Das heißt, am oberen oder unteren Ende des Segments könnte auch ein nicht gemappter Bereich liegen, der beim Zugriff eine Exception auslöst. Selbst mit einer Tabelle im RAM, die 1K-weise mappt, geht die Performance schon deutlich runter. Und Performance war mir bei dem Projekt wichtig, da es auch einigermaßen benutzbar sein sollte. Es gäbe sicherlich die Möglichkeit, den Swap-Bereich in das interne bzw. externe RAM zu legen. Im Moment nutze ich aber das "überschüssige" RAM als Schreibcache für die Platte (ausschließlich des Swap-Bereiches). Interessanter wäre für mich da die FPU-Emulation, bei single precision könnte man ja die im SPC und M4 integrierte FPU nutzen.
Ja realloc Code kennt man, wenn die PDP11 das kann ist es klar wieso das geht. Das nennt sich dann PIC (Place Independend Code) ARM kanns ja eigentlich auch, aber Compiler generieren absoluten Code aus Performacegründen. Bei MIPS rein theoretisch auch. Statt jal muss dann erstmal die Adresse über den GlobalPOinter in ein Register geladen werden und dann die Startadresse draufaddiert werden. Danach gehts mit jalr weiter. Das saugt aber sehr an der Performance. :/
Für eine frühere Version, bei der es nur darum ging, PDP11-Code auszuführen hatte ich ein semitransparentes MMU-System vorgesehen. Das bestand aus 64 1K-Blöcken je Prozess, die dann ins Nichts (Exception auf dem Host), ins RAM oder auch ins Flash des Controller zeigen konnten (execute in place). Pseudo-Kernel und Shell liefen auf dem Host-System, ein Programm hat beim Start lediglich sein BSS-Segment und 1K Stack aus einem Pool bekommen. Wenn der Stack nicht ausgereicht hatte, ist dann automatisch der nächste Block gemappt worden, Gleiches bei alloc-Aufrufen. So hat im günstigsten Fall ein Programm nur 2K RAM benötigt. Syscalls waren als Unterprogrammaufrufe im Bereich 0xE000-0xEFFF realisiert, die ich dann im Host-System abgefangen habe. Um den CC ans Laufen zu bekommen, hätte ich aber noch mehr Syscalls implementieren müssen und das ist irgendwann zu aufwändig und komplex geworden. Und immer inkompatibler...
Nach längerer Zeit gibt es ein kleines Update (V.74). Änderungen gab es eigentlich nur bei den SDL-Versionen. Die können jetzt auch als Terminal für die µC-Versionen dienen. Außerdem habe ich (experimentelle) Windows-Versionen erstellt, auch diese können als serielles Terminal fungieren. Sie Entwicklung erfolgt allerdings weiter nur unter Linux. Da es inzwischen genügend schnelle Mikrocontroller mit mehr als 256K RAM gibt (SPC58..., STM32H7..) überlege ich derzeit, doch noch eine Variante mit MMU zu programmieren, auf der dann auch ein "reguläres" Unix laufen kann. http://www.jcwolfram.de/projekte/mxe11/main.php Die weiter oben angegebene Onion-Adresse ist übrigens nicht mehr aktuell, ich habe sie durch http://jwolframhu6lcyog.onion ersetzt. Jörg
Nun ja, das Konzept MMU habe ich wieder verworfen. Allein Speicherzugriffe über eine Tabelle mit Zeigern zu indizieren und auf mehrere Registersätze via Array zuzugreifen bringt auf dem PowerPC eine Geschwindigkeitsreduzierung um fast 40%. Und da ist das ganze Exception- und Flag-Handling der MMU noch gar nicht dabei. Auf dem STM32 wird es etwas besser aussehen, da hier schon einige PDP11-Register im Speicher stehen, aber letztendlich ist es mir nicht wert. Was ich aber wahrscheinlich aufgreifen werde, ist die weiter oben angesprochene Idee mit dem ESP32. Einfach deswegen, weil da die Verbreitung wesentlich größer ist. Falls es überhaupt noch jemanden interessiert... Jörg
> Falls es überhaupt noch jemanden interessiert...
Falls du ueberfluessige Resourcen hast dann kannst du ja noch UCSD-P auf
einem Mikrocontroller ans laufen bringen. Das baue ich dann auch nach.
.-)
Olaf
> Falls du ueberfluessige Resourcen hast
Eher nicht. Für mich reicht die SPC56 Version völlig aus und für den
ESP32 müsste ich den ganzen I/O Krempel portieren, da das bei den
anderen Controllern portabel über die Unilib läuft. Allerdings könnte
man beim ESP32 halt auf dem zweiten Core z.B. ein Terminal mit VGA und
PS2 laufen lassen und hätte so fast einen kompletten Computer im Modul.
UCSD-P bzw. P-Code VM klingt zwar interssant, aber da ist momentan
nichts geplant.
Jörg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.