Bin das nur ich, oder benutzt wirklich JEDER eine andere Belegung der sd-card in den Projekten?
Das projekt sieht toll aus, nur es fängt wieder damit an, wie zum **** ist die sd-card angeschlossen 
Gruss & DANKE für die witzigen Projekte mit dem kleinsten rp2040 ...
adafruit hat einen Artikel, wie man ein HDMI Display und USB Tastatur an das Pico RunCPM bringt 
Klasse!
Wenn man aber dafür schon wieder zwei Picos nimmt, kann man dann nicht gleich einen "zero" nehmen ?
Wenn man aber dafür schon wieder zwei Picos nimmt, kann man dann nicht gleich einen "zero" nehmen ?
koennte man sicherlich - hat aber nicht den Reiz der Mikrocontroller. Anstatt des Zero tut es jedes alte ARM-SBC aus der Schublade. Aber ein Pico muss nicht Linux booten. Der bootet direkt CP/M.
Und einen eigenen Mikrocontroller fuers Video hat sogar der Agon Light(2)
Aber ein Pico muss nicht Linux booten. Der bootet direkt CP/M.
...das muss eine Raspberry auch nicht unbedingt: http://www.projekte.daleske.de…0_RPI/prog_EMUZ80_RPI.htm
(...jedoch sind diese Versionen wohl "nur" für die RP1, RP2 und RP3 geeignet...)
Das mit zwei Picos finde ich blöde, den Ansatz über reine µC jedoch toll! Ich mag es auch nicht wenn da unterhalb erst noch ein Linux werkeln muss...
:)Franky
...das muss eine Raspberry auch nicht unbedingt: http://www.projekte.daleske.de…0_RPI/prog_EMUZ80_RPI.htm
(...jedoch sind diese Versionen wohl "nur" für die RP1, RP2 und RP3 geeignet...)
Das Ultibo-CP/M habe ich schon mal vor Jahren getestet, allerdings war die Bildschirmausgabekompatibilitaet nicht so hoch, es gab nur Disk-Images und umstellen auf helle/gruene Schrift auf schwarz jabe ich damals auch nicht hinbekommen - ansonsten war es nett sowas als Bare-Metal zu haben.
Dafuer gibt es jetzt Linux fuer ESP32-S3 soviel zum Microcontroller muessen kein Linux booten
(OK - muessen nicht, geht aber jetzt)
Display More...das muss eine Raspberry auch nicht unbedingt: http://www.projekte.daleske.de…0_RPI/prog_EMUZ80_RPI.htm
(...jedoch sind diese Versionen wohl "nur" für die RP1, RP2 und RP3 geeignet...)
Das mit zwei Picos finde ich blöde, den Ansatz über reine µC jedoch toll! Ich mag es auch nicht wenn da unterhalb erst noch ein Linux werkeln muss...
:)Franky
Habe mal von http://www.projekte.daleske.de…09_EMUZ80/prog_EMUZ80.htm die Windows-Version ausprobiert.
Auf der einen Seite schon mit Features wie das Debuggen und dem Tracing (gut!) ausgestattet, auf der anderen Seite wirklich nicht richtig kompatibel und funktionell. Wenn man in der Konsole (CP/M CCP) in der Kommandozeile etwas eintippt, und korrigieren will, funktioniert "Backspace" nicht wirklich (zumindest nicht visuell). Das HEBASIC als Test für Z80 Kompatibilität ist auch nicht schlecht, das funktioniert auch nicht (siehe Bild).
Schade, ansonsten auch vielversprechend für den Raspi...
P.S.: Ich versuche mal den Autor anzusprechen, vielleicht kann er mir ja erklären, was mit "29H Fehler - Befehl nicht ausgewertet" gemeint ist (BDOS Funktion 29H ? CPU Opcode 29H ?).
Update auf RP2040-Core v3.3.0
Hier .UF2-Binary fuer Pico & PicoW
Bilder von einem weiteren gluecklichen RunCPM Pico User
Hatte ihm beim compilieren geholfen und den Source leicht
auf seriell angepasst (Pin 1/2 bzw. GPIO0/1 mit 115.200Baud)
fuer sein DEC VT510 Terminal.
Das Breadboard "klebt" hinten am Terminal - ich finde es sieht cool aus
Das mit dem (alten, echten) Terminal gefällt
Allerdings hätte ich mir immer noch gewünscht, das irgendwann demnächst CP/M 3.0 unterstützt wird.
Es gibt zwar jetzt nicht so viele "ich-laufe-nur-auf-CP/M_3" Programme, aber es ist schon richtig cool, mehr RAM (mehr als 64KB) für Anwendungen benutzen zu können, bspw. für DiskCopy-Software, oder kein Ctrl-C beim Diskettenwechsel mehr nötig zu haben, oder das man bspw. RSX Treiber zur Laufzeit laden kann (bei DOS hätte man die TSR-Programme genannt; so kann man dann bspw. auch einen Tastaturtreiber nachladen, statt jedes Mal eine länderspezifische CP/M 2.2 Version sich besorgen zu müssen).
P.S.: Wer Interesse an RSX Programmierung hat, kann mal ins Dr. Dobb's Journal von Juli 1984 nachschauen, und zwar ab S. 20 (S.23 ist das Listing).
Mal wieder der (binary) Versuch einer Overclock-Version >250Mhz
also
270Mhz fuer den nornmalen Pico und
260Mhz fuer den PicoW
Die passende "boards.txt" fuer den HW-RP2040-Arduino-Core Support habe ich mit ins .ZIP gepackt fuers
260/270Mhz overclocken beim selbst-compilieren.
Mehr scheint leider nicht zu gehen, da die Arduino-IDE die Picos nicht ueber-"volten" laesst.
Fuer 300Mhz braeuchten wir wohl min 1.2-1.3V anstatt 1.15V
Durchs WLAN braucht der PicoW wohl mehr Strom und kommt nicht auf 270Mhz
(BTW: Die LED des PicoW ist auch VIEL langsamer als die des normalen Pico, da diese
beim PicoW ueberf WLAN-Modul geht 
)
Hier anbei jeweils ein .UF2 Binary
PS: Wenn es mit dem SDCard-Init nicht klappt, dann
- die Daten wegsichern
- die Karte mit dem SDCard Formatter v5 neu formatieren
- Daten zuruecksichern
Vorher hatte ich das Problem, dass manche SD-Karten nicht mit noch mehr Mhz zusammen spielemn wollten.
Nun gehen selbst so langsame mit (4)-Speed
Fuer die RC2040-Platinen-User auch mal eine 270Mhz-Version
Als .UF2-Binary steht zur Auswahl je ein File fuer die Nutzung
der gruenen (Pico onboard) oder der roten (onboard RC2040) LED
