pdp11/40 Emulation auf dem Raspberry Pi Pico

    Ueber die Seite zur Emulation der pdp11/40 auf dem Raspberry Pi Pico bin ich vor kurzem "gestolpert" bei der Suche nach weiteren moeglichen Emulationen fuer den Kleinen ;)


    Da es kein Arduino-IDE Code ist, musste wieder meine Pico/SDK Installation herhalten, die ich auch zum compilieren des RC2040 nutze :)

    Deshalb haenge ich Euch das .UF2 Binary (Pico_1140_10112022.zip) hier an, da es auf der Github-Seite nicht angeboten wird.

    Die Disk-Images zum booten findet Ihr auf der Github-Seite des Projektes im Ordner images.


    Soweit klappte das compilieren des Source (bis auf 1-2 Warnings) gut.


    Nun bei der Hardware wurde vom Projekt-Autor anstatt eines normalen Pico ein Sparkfun Things Plus - RP2040 genutzt :(

    und es heisst auf der Github-Seite man sollte die SD-Karte so anschliessen, wie sie bei dieser Platine gemacht wurde:

    "Other hardware may be used including a Pi Pico itself. Wire the SDCard as per the Sparkfun schematic."


    Nun musste ich mir erst dort die SDCard Verbindungen such, mit den GPIO-Pins vergleichen und dann die passenden Pico Standard-Pin-Nummern suchen, da die Sparkfun-Platine mal wieder andere Nummern nutzt.


    Also dafuer eine Art Tabelle selbst erstellt:



    Da mich die Things_Plus_Pin-Namen etwas verwirrten hatte ich beim ersten Start MISO und MOSI verwechselt, denn die eckigen Klammern habe ich mir erst nachhher hinzugefuegt.


    Der zweite Start un die ersten Boot-Versuche haben nun geklappt, deshalb lasse ich es fuer heute dabei - der erste Erfolg muss bis Morgen langen :)

    Morgen kann ich mal sehen, welche Befehle man normal nutzt.


    Evtl. finden sich hier weitere pdp11/40-Freunde, die mri Ideen geben und auch Spass daran haben.

    Auch werde ich dann wohl Morgen (beziehungsweise spaeter am Tag - es ist ja schon hier nach 0:00Uhr) ein Bild meines Breadbard-Aufbaus zum Vergleich mit der Tabelle einstellen (und evtl. Ausschnitte aus dem Schematic-File)






    So - wie versprochen die Bild-Ausschnitte aus dem Sparkfun Things Plus RP2040.
    Dazu noch ein Pico-Bild mit der SPI-Belegung entsprechend meines BreadBoards.

    Weiterhin als .TXT eine Anleitung, wie ich auf meinem armbian das Pico-SDK installiert habe und dann die pdp11/40 fuer den Pico compiliert habe.


    Da ich eben noch einen PicoW verloetet habe (mein letzter freier) habe ich auch nachgesehen, was man beim compilieren aendern muss am Compile-Befehl - steht auch in der Anleiung (siehe cmake Befehl)


    Im Anhang dann auch das .UF2-Binary fuer den PicoW
    (das Binary ist wie bei der Arduino-IDE aufgrund des Board-Typ nicht das selbe)




    Hallo,

    Das ist ja eine Überraschung. Ich arbeite/bastle in einen ähnlichen Bereich. Jedenfalls

    wollte ich eine PDP-11/40 quasi ersetzen, bzw emulieren mit gesamter Peripherie.

    Deine Implementierung ist ein echter Fortschritt und ich bin gerne "Trittbrettfahrer"

    Ich war bisher auf das DE10-Nano Board fixiert, Ein CYCLON V FPGA board mit integrieter

    Cortex A9 CPU . Ich habe damit meinen RL und MFM emulator realisiert. SIMH läuft

    auf darauf. Nun ist allerdings dieses Board rel. teuer geworden und nur noch schwer zu

    bekommen. Mein Ziel war ein RASPBERRY PI und/oder PICO einzusetzen um wesentlich

    kostengünstiger arbeiten zu können, auch für anstehende Projekte wie RX und RK05 Emulator.

    Weil auf den RASPI keine PLL vorhanden ist, habe ich mir mit dem SI5351 clock Generator beholfen.

    Diese Idee habe ich allerdings nun auch verworfen und habe mich nun auf das sehr

    preisgünstige Tang Nano 9K fixiert, welches nun endlich heute angekommen ist. Kostet

    weniger als EUR 20,-. Alternativ habe ich mich noch mit den Merkury 2 Board befasst, ist

    aber mit ca EUR 100,- viel teuerer. Ich will nun versuchen, PICO mit Tang Nano zusammenbringen.

    und werde es mit dem I2 Bus versuchen. Probleme machen allerdings immer noch die Level-shifter.
    Auf einen vielleicht zweites PICO -W lasse ich SIMH laufen mit Deiner tollen Portierung.

    Vielleicht gibt es die eine oder andere Idee für einen Meinungsaustausch ?

    Reinhard

    Hallo Reinhard,

    beim Video schauen auf YT zum Thema pdp habe ich auch Dein RT11-BASIC Video angesehen ;)

    ALLERDINGS geht der grosse Danke fuer die pdp11/40 auf dem Pico NICHT an mich, sondern an

    Ian Schofield von https://github.com/Isysxp/Pico_1140


    Leider kann der/die pdp11/40 Pico nur ein dsk-image mounten, so dass ich gerne ein RT1-RK05 Image finden wuerde auf dem das BASIC schon drauf ist ;)


    Beim Emulator dabei ist ein .DSK mit MINC Basic

    Du hast im Video RT11 5.04 genutzt, der Pico mit pdp11/40 kann (bis jetzt) nur v3.c und v4.x laut Github-Page Doku.


    Gruesse

    Guido

    Einmal editiert, zuletzt von guidol ()

    Interesantes Projekt!

    Habe mir vor paar Tagen sowas gebastelt, hasse diese fliegende Verdrahtungen :)



    Werde es bestimmt mal versuchen, das auch hier drauf zu bringen.


    Gruss & Danke!

    Zitat von e2k

    Werde es bestimmt mal versuchen, das auch hier drauf zu bringen.

    Dann musst Du wohl im Sourcecode finden, wo die SPI-Pins definiert sind, damit es zu Deinem MicroSD-Layout passt.


    Hmm...wenn ich es finden wuerde (habe noch nicht rein gesehen) dann koennte ich meinen RunCPM-SPI-Aufbau nehmen und nur umflashen ;) *holdmybeer*

    War zu einfach - in der hw_config.c ist es drin:


    Code
    .hw_inst = spi1, // SPI component
.miso_gpio = 12, // GPIO number (not pin number)
.mosi_gpio = 15,
.sck_gpio = 14,
...
.ss_gpio = 9, // The SPI slave select GPIO for this SD card


    Fuer meins Breadboard muesste ich wohl nur auf spi oder spi0 wechseln und die Pin-Nummern anpassen...

    vor dem compilieren :)

    Du benutzt aber die gleichen GPIO-Pins wie die spark fun platine?

    Nur die "pin nummern" sind verschieden?


    "alles klar jetzt, unsere emails haben sich überkreuzt" :)


    Der Pico benutzt nur den spi mode der sd-card, stimmt?

    Kein "luxus 4bit" mode"?

    Zitat von e2k

    Du benutzt aber die gleichen GPIO-Pins wie die spark fun platine?

    Nur die "pin nummern" sind verschieden?


    Der Pico benutzt nur den spi mode der sd-card, stimmt?

    Kein "luxus 4bit" mode"?

    Ich habe ein Breadboard mit den GPIO-/PinNummern des Sparfun "nachgestellt" umd nicht am Source was zu aendern.

    Bei RunCPM nehme ich normal andere GPIOs/Pins - da die Nummern (GPIO) aber in der hw_config.c sind (die passen zu der Grafik vom Schaltplan) koennte ich die fuer mein RunCPM Breadboard anpassen.


    Soweit ich weiss, ist es normales SPI ueber einen speziellen noOS-FatFS-SD-Pico Driver

    Ich würde gern mal probieren, ob ich eine emulierte pdp11/40 zum Laufen bekomme. Würde ich da besser einen Sparkfun Things plus oder einen RaspberryPi Pico benutzen? Gibt es Unterschiede bei der Entwicklungsumgebung? Wahrscheinlich würde ich dafür ein nicht mehr ganz so frisches MacBook benutzen, also noch mit Intel CPU.

    Zitat von flowerking

    Ich würde gern mal probieren, ob ich eine emulierte pdp11/40 zum Laufen bekomme. Würde ich da besser einen Sparkfun Things plus oder einen RaspberryPi Pico benutzen? Gibt es Unterschiede bei der Entwicklungsumgebung? Wahrscheinlich würde ich dafür ein nicht mehr ganz so frisches MacBook benutzen, also noch mit Intel CPU.

    Das Sparkfun Things Plus hat den SD-Card-Slot schon onboard, fuer den Pico braucht es Breadboard und SPI-SD-Adapter - ansonten ist es der selbe Prozessor RP2040 (die 16MB Flash des Sparkfun nutzt die pdp11/40 nicht).


    Wenn es nur darum geht eine pdp11/40 zu emulieren, kannst Du auf Deinem MacBook einfach simh fuers erste testen.

    Oder soll das Macbook zum programmeiren des Pico genutzt werden?

    Noch ein paar wichtige Punkte:

    Beim MINC System wurde immer die Memory ( MSV-11 DD) auf 2K I/O Page konfiguriert.

    Dementsprechend wurde der Kernel/RT11-monitor mit Treiber um 2K höher geladen. Ob das richtig

    mit SIMH emuliert wird, weiß ich nicht, probiere doch mal den MINC-Basic Befehl: EXTRA_SPACE

    Ich habe mal versucht Dein MINC Basic zu starten:

    set CPU 11/23,512k

    sim> attach RL0 RL02_0-9.DSK

    sim> attach RL1 MINC_RK05.dsk

    sim> boot rl0

    Kann zwar dann Dein system lesen mit dir dl1: , auch Basic starten mit run dl1:Q4SZMX

    Dein MINC-Basic system ist allerdings nicht offiziell , es sollte von einer RX02/=DY laufen

    und nicht von einer RK05.

    Vielleicht machst DU mal die RX02 Version bootbar: .copy/boot DYMNSJ.SYS

    Ansonsten kannst Du auch das Basic von mir auf Dein MINC System kopieren.

    Es macht für mich auch keinen Sinn das MINC Basic zu benützen.

    Das MINC Basic ist für I/O systeme und Terminals wie VT105/VT125 entwickelt worden.

    pdp11gy

    ums MINC gehts mir auch nicht direkt ;)
    BASIC-11/RT-11 war schon OK :)
    Das MINC-RK05 Image ist wohl beim Pico pdp11/40 Projekt ueber folgenden Weg gekommen:
    https://pdp2011.sytse.net/wordpress/howto/minc-rk05/
    https://pdp2011.sytse.net/wordpress/building-a-rk-minc-disk/


    Weil Du die MINC_RK05.dsk als RL1 gemounted hast, habe ich auch mal was getestet...
    So konnte ich 2 Laufwerke "mounten", Directorys ansehen und auch copy-Befehle absetzen, aber leider scheint das v4.00C RT-11 dann beim naechsten Bootversuch korrupt zu sein:


    Zitat von guidol

    Wenn es nur darum geht eine pdp11/40 zu emulieren, kannst Du auf Deinem MacBook einfach simh fuers erste testen.

    Oder soll das Macbook zum programmeiren des Pico genutzt werden?

    Das MacBook soll zum Programmieren des Pico benutzt werden. Sowohl um darauf Programme zu entwickeln bzw. kompilieren, als auch um die fertige Software auf den Pico zu übertragen.

    Es geht nicht nur darum, eine PDP zu emulieren, ich will mich auch mal ein bisschen mit diesen Mikrocontrollern beschäftigen. Aber simh könnte ich trotzdem mal direkt auf dem Mac testen. ;)

    Zitat von flowerking
    Zitat von guidol

    Wenn es nur darum geht eine pdp11/40 zu emulieren, kannst Du auf Deinem MacBook einfach simh fuers erste testen.

    Oder soll das Macbook zum programmeiren des Pico genutzt werden?

    Das MacBook soll zum Programmieren des Pico benutzt werden. Sowohl um darauf Programme zu entwickeln bzw. kompilieren, als auch um die fertige Software auf den Pico zu übertragen.

    Zum entwickeln fuer den Pico kannst Du das Pico-SDK nehmen (direktes C(++)) oder per arduino-pico core die Arduino-IDE.
    Das SDK erstellt Dir ein .UF2, dass man dann im BOTTSEL-Modus direkt auf den Pico schreibt per Drag&Drop

    Bei der ARduino-IDE erledigt diese das schreiben de .UF2-Binary auf den Pico.


    Die pdp11/40-Emulation wurde mit dem SDK zum .UF2 compiliert.

    So ;) - hartnaeckig sein hat sich wieder gelohnt :)
    Ich habe es nun mit simh v4.0 current (auf Windows und Linux) hinbekommen, RT11-BASIC, Focal und Fortan von dem RL-Image RL0 RL02_0-9.DSK auf das RT-11 V4.00C Image zu kopieren.


    Schoen - fuer mich - ist dies, weil die pdp11/40-Emulation die V4.00C booten kann und ich nun die Sprachen dort nutzbar sind.


    Erst wollte es nicht klappen, da sich die "neue" open-simh Variante weigerte ein RL-Image auf ein RK-device zu mounten:

    Code
    sim> att rk1 ./basic.dsk
%SIM-ERROR: RK1: RL02 container created by the PDP-11 simulator is incompatible with the RK device on the PDP-11 simulator
%SIM-ERROR: RK device: Non-existent parameter - RK05

    Mit simh V4.00 current sah es dann gleich anders aus:


    Wahrscheinlich half hier auch nicht das RK-Image (RT-11 V4.00C) als RL-Image zu mounten, sondern das RL-Image (RL0 RL02_0-9.DSK von pdp11gy ) als RK(1)-Image im read-only Modus zu mounten ;) was simh dazu bringt:

    RK1: Read Only access to inconsistent drive type allowed


    Nach dem boot des RT-11 V4.00C ueber rk0 koennte dann von dem RL-BASIC-Image (also rk1:) kopiert werden:

    Code
    copy rk1:basic.sav rk0:basic.sav
copy rk1:focal.sav rk0:focal.sav
copy rk1:fortra.sav rk0:fortra.sav


    Nach einem Neustart von simh (um sicher zu sein, dass rk1: weg ist und nur von rk0: gelesen wird) bootet V4.00C noch und die Programmiersprachen sind trotzdem noch aufrufbar/nutzbar (die laufen obowhl die aus einem V5.04 Image kommen dann unter V4.00C):



    Das RT-11 V4.00C Image mit den reinkopierten Programmiersprachen haenge ich Euch unten - zum selbst testen - an ;)

    Zitat von guidol
    Zitat von e2k

    Werde es bestimmt mal versuchen, das auch hier drauf zu bringen.

    War zu einfach - in der hw_config.c ist es drin:

    Fuer meins Breadboard muesste ich wohl nur auf spi oder spi0 wechseln und die Pin-Nummern anpassen...

    vor dem compilieren :)

    Gerade mal getestet fuer mein "RC2040"-Pico-Board (RC2014 Emulation mit dem Pico)

    Es muss also spi0. sein und nicht nur spi. (das meckert der Compiler dann an)


    So sieht es in der Datei (an den SPI-Stellen) fuer den RC2040 aus:

    Code
    .hw_inst = spi0, // SPI component
.miso_gpio = 4, // GPIO number (not pin number)
.mosi_gpio = 3,
.sck_gpio = 2,
...
.ss_gpio = 5, // The SPI slave select GPIO for this SD card

    Fuer meinen RunCPM-Pico Aufbau sollte es dann so aussehen:

    Code
    .hw_inst = spi0, // SPI component
.miso_gpio = 16, // GPIO number (not pin number)
.mosi_gpio = 19,
.sck_gpio = 18,
...
.ss_gpio = 17, // The SPI slave select GPIO for this SD card

    Der original Source laesst den Pico auf 200Mhz laufen. "Safe" uebertakten kann man bis 250Mhz (wie bei RunPM),

    dehalb habe ich den Source bei mir vor dem compilieren mal angepasst.


    Die Mhz stellt man ein in der Pico_1140.cxx (Zeile 86)

    von set_sys_clock_khz(200000, true)

    auf set_sys_clock_khz(250000, true)

    vor dem Compile.


    Das gibt der pdp11/40 auch ca. 1/5 mehr CPU-Power ;)

    (getestet mit dem FRACTA.BAS unter BASIC-11)

    Wer im Windows Device-Manager das unerkannte "Reset-Device" weg bekommen will, muss vor dem Compile in der Datei /Pico_1140/Pico_1140_DC/CMakeLists.txt folgende Zeilen am Ende anfuegen:

    Code
    # Disable RESET options - get rid of the unreconized Reset-Device in Device-manager
# see https://forums.raspberrypi.com/viewtopic.php?t=334691
add_compile_definitions(PICO_STDIO_USB_ENABLE_RESET_VIA_BAUD_RATE=0)
add_compile_definitions(PICO_STDIO_USB_ENABLE_RESET_VIA_VENDOR_INTERFACE=0)


    nebenbei: erweiterter Inhalt bei der rtv400c.dsk - da Merge mit den Inhalten aus einem .dsk-Image des
    pdp/1140-Emulator-Autors ;)

    Wer den RunCPM Pico mit meiner SPI-Verkabelungs-Konfig aufgebaut hat



    SCK GPIO 18 - MISO GPIO 16 - MOSI GPIO 19 - SS/CS GPIO 17


    der ganz nun eine precompilierte Version des pdp11/40 Emulators testen ;)
    (mit 250Mhz Takt und ohne Reset-Device im Device-Manager)


    Zu finden hier


    Zitat von guidol

    # Disable RESET options - get rid of the unreconized Reset-Device in Device-manager # see https://forums.raspberrypi.com/viewtopic.php?t=334691 add_compile_definitions(PICO_STDIO_USB_ENABLE_RESET_VIA_BAUD_RATE=0) add_compile_definitions(PICO_STDIO_USB_ENABLE_RESET_VIA_VENDOR_INTERFACE=0)

    es reicht die 2te Zeile, erste kann man auch (ist wohl default?) auf

    Code
    add_compile_definitions(PICO_STDIO_USB_ENABLE_RESET_VIA_BAUD_RATE=1)

    stellen (oder weglassen?)

    Zitat von ThoralfAsmussen

    34 min Ausführungszeit ... naja ... :)

    Nein ;) das BASIC-11 zeigt die "aktuelle" Zeit vor dem Start und nach Ende des Programms.

    Die Startzeit sieht man hier ja nicht - aber es lief nur ein paar Sekunden dafuer.


    Ich hab jetzt (wie bei RunCPM) versucht den Startup-Screen ein wenig nach meinem Geschmack zu "verbeseern" :)

    (Mir gefaellt es jetzt schon besser)


    Ich habe inzwischen alle Teile bekommen, die ich bestellt hatte und habe mal versucht, die PDP zum Laufen zu kriegen. Leider klappt es nicht ganz:


    Nachdem ich nochmal alles mit Guidos Aufbau verglichen habe, wäre meine Vermutung, dass das SD-Kartenmodul nicht für 3,3V geeignet ist? Oder könnte es auch etwas anderes sein?

    Zitat von flowerking

    Nachdem ich nochmal alles mit Guidos Aufbau verglichen habe, wäre meine Vermutung, dass das SD-Kartenmodul nicht für 3,3V geeignet ist? Oder könnte es auch etwas anderes sein?

    Nicht schlimm - Dein SDCard-Modul hat einen 5V nach 3.3V Converter.

    Da die Karte von der Groesse schon mal erkannt wird - ist es schon mal die halbe Miete.


    Die MicroSD Adapter die ich hatte koennten auch kein 3.3V direkt.

    Mein SD (FullSize) kann beides.

    Du solltest Dein weisses Kabel (z.Zt. auf 3.3) ganz an die Ecke (Richtung MicroUSB) stecken.

    Da ist 5V VBUS - dann bekommt Dein MicroSD Modul 5V, die es auf 3.3 runterkonvertieren kann.


    Die Karte sollte FAT32/exFAT formatiert sein und im Hauptverzeichnis ein .dsk Image im RK-Format drin sein :)


    Dann sollte es gehen.


    Anbei noch mal fuer alle genauere (wie es aktuell bei mir ist im original Layout und nicht RunCPM-SPI) PinOut-Bilder ;) Ich hoffe, dies macht es ganz klar! ;)


    SPI Belegung des SDCard-Adapters (nutze hier z.Zt. auch 5V und den StepDown-Converter):


    5V (VBUS und GND( fuer die SD-Karte holen wir uns vorne an der Ecke
    (blau = Masse und gruen = 5V)


    und zum Schluss die Ansicht der SPI-Verbindung von der SDKarte zum Pico

    (schwarz ist nochmal eine GND-Leitung, wird wohl nicht gebraucht ist nur doppelt gemoppelt da ich Verbindungsprobleme ganz sicher ausschliessen wollte)

    Ich bin schon mal einen Schritt weiter. Aber irgendwie mag der Pico meine SD Karte nicht. Zuerst war die Karte mit FAT32 formatiert. Das hat nicht funktioniert. Dann habe ich die Karte mit exFAT formatiert, was auch nicht funktioniert. Leider ist es nur eine NoName-Karte. Ich hätte noch eine 64GB Karte, die kann ich dann morgen mal ausprobieren. Hier würde allerdings nur exFAT gehen, weil 64GB zu gross ist für FAT32.


    Zitat von flowerking

    Ich bin schon mal einen Schritt weiter. Aber irgendwie mag der Pico meine SD Karte nicht. Zuerst war die Karte mit FAT32 formatiert. Das hat nicht funktioniert. Dann habe ich die Karte mit exFAT formatiert, was auch nicht funktioniert. Leider ist es nur eine NoName-Karte. Ich hätte noch eine 64GB Karte, die kann ich dann morgen mal ausprobieren. Hier würde allerdings nur exFAT gehen, weil 64GB zu gross ist für FAT32.

    Erst hatte ich - zur Sicherheit - nochmal deine Verkabelung geprueft, die sieht aber immer noch OK aus
    (auch wenn Du bei den Farben braun=MISO und orange=SCK hast und ich umgekehrt)


    Der Autor Ian Schofield schrieb auf der Read.me-Seite bzw. auch im Source, dass er Probleme mit Noname Karten hatte

    Zitat

    /* The choice of SD card matters! SanDisk runs at the highest speed. PNY

    can only mangage 5 MHz. Those are all I've tried. */

    und (nur) SanDisk benutzt.

    Ich persoenlich habe 8GB und 32GB SD-Karten von SanDisk genutzt (Ultra oder Extreme).


    Der no-OS-FatFS-Treiber im Source kann FAT32 und exFat.
    Meine 32GB Karte habe ich testweise auch schon mit exFAT genutzt, allerdings weiss ich nicht wie sich da die Clustergroesse bei 64GB aendert (bloed, dass man nur noch grosse Karten bekommt - ich haette lieber manchmal 4 und 8GB Karten anstatt 16GB und groesser).


    Ansonten falls Du auch andere Kabel hast (also maennlich auf weiblich) dann wuerde ich mal testen den SDCard-Adapter nicht ins BreadBoard zu stecken und direkt zu verkabeln.


    Aber eigentlich erwarte ich, dass Dein SDCard-Adapter lauffaehig ist, da ich fruehr genau das selbe Modell hatte.

    Ich bin nur fuer Optik und weil der grosse Adapter 2 Kontaktreihen und direkten 3.3V Support hat auf den gewechselt.


    Hier bei der pdp1140 wird die SD-Karte mit 12Mhz auf dem SPI-Bus betrieben (init bei 400KHz) im Gegensatz zu 19Mhz, die ich bei RunCPM nutze - so muesste sich eigentlich die Nutzbarkeit einfacher Karten eher erhoehen :(


    Hast Du die Karte direkt in Windows formatiert oder mit dem "SDCard Formatter"-Programm?

    Irgendwie hatte ich das Gefuehl, dass diesmal die Windows-Formatierung (FAT32/exFAT) besser klappte mit der pdp1140-Emulation als die SDFormatter Formatierung ansonsten bei RunCPm/armbian.


    Ansonsten versuch doch mal die Version im Anhang, ob die besser bei Dir funktioniert.

    Die ist anstatt mit no-OS-FatFS ff14a mit ff15 (aktuelle Github-version des Treibers und noch nicht in der aktuellen pdp1140-Version) kompiliert.