CP/M-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Memberlist || Home || Statistik || Kalender || Staff

Willkommen Gast!

[ Unofficial CP/M Website ] [ Z80 Family Support Page ] [ Forum-Regeln ] [ Impressum/Kontakt ] [ Datenschutzerklärung ]

CP/M-Forum » CP/M 2.2 » CP/M auf Arduino? » Threadansicht

Autor

Thread - Seiten: -1- [ 2 ]

000
22.02.2012, 01:33 Uhr
prefect

Hi!

Ich bin auf der Suche nach Hinweisen/Hilfen/Kritik zu meiner Idee.

Ich bin auf den Arduino gekommen. Der kleine Kerl wird in sowas wie C programmiert, Assembler kann er auch. Es gibt Mengen an Hardware zum drankleben.

Ich bin ein alter "CP/M-2.2-Fetischist" in alten Zeiten hab ich mir ein BIOS für den HD64180 gebaut, mit RAMdisk, etc.pp. sogar mit SCSI disk am Ende.
Heute hab ich die Hardware nicht mehr.

Ich dachte nun: es gibt Z80 Emulatoren im Source und ich nehme so einen als Grundgerüst und reiche den IO auf die Arduino-Ebene durch: disks über Image Dateien auf SD-Karte, Console über Ethernet/telnet. Aus 512kbRAM lässt sich noch eine RAMdisk bauen. Die schnelle Periphere tröstet dann vielleicht über den mageren Systemtakt hinweg, der bei 16MHz auf dem Host kaum an 2MHz auf Z80 Ebene kommen wird. Kosten: 30€ für den Mega, 25€ für das RAM, 25€ für Ethernet und SD-Slot, Strom über USB. ginge noch billiger ohne Ethernet. 30€ mehr und es geht sogar PoE. WLAN wäre auch machbar oder 2,4GHz-Link. Das Ding ist eine eierlegende-Woll-Milch-Sau.

Nun also: es ist lange her mit dem CP/M. Ich habe Fragen:
- Empfehlung einer Doku oder Webseite mit einer Beschreibung wie man ein CP/M "boot-strapped", also BIOS-template, assemblieren, linken, etc.? CP/M source und binaries hab ich gefunden im Internet, aber Doku ist dann doch rar.
- Hat jemand Empfehlung zum "besseren" Emulator den ich für meine Zwecke sezieren kann ... und auch darf!?
- Gibt es HowTos für das Aufbürsten eine CP/M 2.2 mit all den Z-Dingern die ich nicht kenne? Gibt es ein Rezept für ein Spitzen-CP/M mit allen Chromteilen wie z.B. Kommandozeilen-Editor/-History etc.pp.?
- Was waren generell die besten Bücher?

Ich denke mir dass es ein interessantes System wird, durch die Emulation wird das TPA recht gross: alle Arbeit im BIOS wird ausserhalb des emulierten RAMs erledigt und vielleicht kann ich noch Teile des BDOS/CCP nach "draussen" verfrachten.

Nur ich brauche einen Hirn-Refresh. Eventuell zum Training mal selbst nach Howto ein CPM in einem Linux-Emu zusammenstricken?!?

Bin für jeden hint und jeden Link dankbar.

Warum den Unsinn, wenn man sich einen CP/M Rechner kaufen oder löten kann?

Arduino programmieren ... in Turbo-Pascal meine Relais steuern? LCD-Displays steuern? Mit einer IDE im Arduino? Modula, Ada, C, PL/I, Fortran, nutzen was man grad kann? Das verleiht dem "kleinen Freund" vielleicht eine ganz neue Gemeinde.

Wer's nicht kennt: die Arduino-Mega Platine ca 13x5 cm mit Ethernet + RAM und ist weil sandwich (CPU+Ethernet) ca 3-4 cm hoch. Für einen kompletten CP/M Rechner doch s*x klein. Darüber dass sämtlich existierende Software auf eine SD passt brauchen wir nicht wohl diskutieren. Strom kommt über USB, darüber kann man natürlich auch auf den Rechner: ich denke an ein virtuelle Terminal im Arduino, welches eine VT emulation macht, eventuell mit Umsetzung: intern Vt52 extern VT100 oder so. Sowas hab ich schon mal gemacht, ist nicht die Welt und wenn sich in meiner Abwesenheit nichts geändert hat, brauchen CP/M Anwendungen ja auch vergleichsweise wenig Steuerzeichen fürs Terminal.

Also: gibt es etwas Starthilfe für einen Verrückten?

Also ich könnte mir vorstellen dass das so eine Art "kleine Renaissance" für gute alte CP/M sein könnte, wenn man es richtig macht. Im Arduino macht CP/M richtig sinn. Emuliert? Hmmm ok. Ich betrachte das dann als eine Art JVM oder UCSD-pCode.

.

Gruss
Adrian

PS: warum mache ich das mit Arduino und nicht glatt auf Atmel AVR C oder Assembler? Arduino ist eine Quickstart-Plattform: da kann man mit minimalen Kenntnissen Beachtliches basteln. Das will ich so beibehalten: ähnlich wie Linux denke ich über eine Arduino-CP/M-Distribution nach. Wenn DR (was ich nicht genau weiss) noch auf den Rechten hockt, dann eben mit den open-source-replacements (Internet überflogen, es scheint da sowohl für die cores als auch a für die Tools genug Altnernativen zu geben.

Dieser Post wurde am 22.02.2012 um 01:39 Uhr von prefect editiert.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

001
22.02.2012, 07:58 Uhr
m.haardt

Warum nicht? Ich kann yaze empfehlen, das ist sehr schnell und kann auch eine MMU emulieren. Damit kannst Du CP/M 3 laufen lassen und hast eine maximale TPA. Die RAM Disk kannst Du dann auch unter CP/M 3 implementieren, statt auf dem Wirt. Vor allem kannst Du alles wahlweise auf dem Arduino oder unter Linux benutzen.

Michael

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

002
24.03.2012, 11:18 Uhr
Feinmechaniker

Hallo,
ein AVR CP/M Projekt findest du hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Das sollte 1:1 auf dem Arduino laufen. Natürlich noch SD-Card und RAM anschließen.

Joe

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

003
07.05.2012, 01:35 Uhr
prefect

Zitat:

Feinmechaniker postete
Hallo,
ein AVR CP/M Projekt findest du hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Das sollte 1:1 auf dem Arduino laufen. Natürlich noch SD-Card und RAM anschließen.

Joe

Danke Joe,

ich habe mir yaze angeschaut. Nix für Arduino. Ich will was Besseres!
Yaze hat nen code-Generator in Perl und so'n rappel, implementiert nicht alle undocumented Z80 opcodes, ist gnubbelig bei der Einbindung von Hardware.

Ich will kein Museumsstück bauen, sondern etwas für den tatsächlichen praktischen Einsatz. Also sind einige Nächte reingegangen:

Ich habe einen reinen C++ basierten Z80 Emulator geschrieben. Basierend auf Wissen aus Rodnay Zaks' Buch, einigen sehr aufschlussreichen Artikeln aus dem Internet und ja ... auch dem source von yaze. Immer mal ganz gut zu prüfen ob und warum yaze denn z.B. irgendwelche Flags anders setzt. War nicht immer richtig was yaze da so machte.

Meine Hoffnung ist, den C++ code dann minimal-invasiv auch direkt im Arduino IDE übersetzen zu können!

RenaissanZ (kurz RZ), so hab ich das Teil getauft läuft derzeit auf Linux und bootet. Nur leider hab ich einen CP/M re-engineered source für das System genommen und als Kern verwendet und der ist anscheinend fehlerhaft. Gemerkt habe ich das weil ich für RZ nun einen tracers geschrieben habe für den ich eine TCL/Tk GUI hab. Sehr s*x. Einfach den RZ laufen lassen bis es kracht, das Tracefile in die GUI schicken und dann wie auf einem Videoschnittsystem den Ablauf vor und zurückspulen. Suchfunktionen kommen noch. Es wird der "mitgerechnete" Speicher angezeigt und ... deshalb hatte ich den Source genommen auch der jeweils zugehörige Code aus einem Assembler-Listing (vom z80asm).

Das Problem meines Codes (irgendwo von dieser site) ist nicht nur , dass es dis-assembliertes CP/M2 (wohl 2.2) ist sondern insbesondere in 8080 disassembliert wurde und dann von dort nach Z80 übersetzt (mit einem Fehler drin). ich befürchte also der Code ist buggy und dient nur zur Anschauung obwohl gut dokumentiert. Wenn ich ins CCP trace dann geht das auf das erste DIR hin und holt einen first-FCB wie es soll. Nur der wird nicht erkannt und als leer reported, obwohl ich den geladenen Block mit der einen Datei im 1. FCB genau sehen kann im Speicher wie auch auf disk. Aber anscheinen lädt das BDOS in den Dirbuffer, checkt aber dann den Userbuffer ... doof.

Ich brauche ein besseres CPM2.2 als binary oder viel lieber als Z80 source.
Ich nehm aber was ich kriegen kann. Hat jemand was getestetes rumliegen?

Achja, das Arduino-CP/M Projekt ... ist dünn dokumentiert, keine build dateien und bei den CP/M images dort weiss ich nicht woran ich bin, ich werd aber deren Kern mal testen.

Ziel ist: auf dem Arduino ein CP/M zu haben mit variabler Konfiguation:
- Ardiuno Mega mit 512kRAM am Bus des Controllers
- Arduino Uni mit 64kRAM seriell am I2C
- Floppys als EEPROM oder Image auf SD-Card
- Terminal als V.24 (über USB zum host oder separat), Ethernet-telnet oder Micro-VGA (µVGA Hardware läuft schon).

ich hab viel vor. Aber ich brauch als nächstes Mal ein richtiges funzendes CP/M erstmal auf dem Linux und dann den Port auf Arduino.

Achja, hat jemand nen Vorschlag für eine Qualitätssicherung, also Testprogramme, die vielleicht einen Prozessor/Emulator-Test machen könnten?

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

004
07.05.2012, 20:09 Uhr
m.haardt

Vielleicht könntest Du die Fehler in yaze und im CP/M Disassemblercode beim Namen nennen. Ich hatte nämlich umgedreht keinerlei Probleme, P2DOS und Z80CCP (oder irgendwas sonst) unter Yaze ans Laufen zu bekommen. Auch die Einbindung virtueller Hardware war an Einfachheit nicht zu überbieten. Das war allerdings noch yaze 1.

Zu yaze gehört ein Testprogramm, was extrem viel testet und dabei jeweils Prüfsummen vom CPU-Zustand macht. Diese stimmen mit dem Lauf auf Z80 Hardware überein. Lass es mal auf Deinem Emulator laufen. Gibt es Unterschiede, dann sind das Bugs bei Dir oder in der von Dir benutzten Dokumentation, wenn man Z80 Hardware als Referenz akzeptiert.

Michael

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

005
07.05.2012, 20:36 Uhr
prefect

Michael, ich wollte nicht yaze runtermachen, der funktioniert tatsächlich gut. Die "Fehler" betreffen einige Flags im Handling bei undokumentierten opcodes und hier wiederum die X und Y flags, die wohl eher selten benutzte werden. Auch sind nicht alle undokumentierten Opcodes vorhanden.

Das Ganze ist eher akademisch. Praktisch sowieso nicht relevant, das dieses Verhalten weder bei den folgenden Z180++ noch beim 8080 vorlag.

Wenn es Dich wirklich interessiert, dann mach ich mir die Mühe und such das raus, findest Du aber mit Google selbst. Es geht um eine Seite von worldofspectrum (ZX Spectrum Seite, einige von den Jungs hatten richtig was los!).

Was den CPM code betrifft, der Fehler war keiner, nur ein Stilfehler.

Dass es nicht lief, lag an meinem Emu (RET NC statt RET C, es fehlte ein "!").
Der Stilfehler liegt im Code der meisten Disassembleten CP/M wie ich feststellen musste. Mal abgesehen davon, dass der Login-drive Mechanismus etwas hirnig ist (erst werden einzelne pointer kopiert, dann der Rest vom DPH und schliesslich der DPB byteweise. Das hätte man bei korrekter Auslegung der Speicherstellen auch so beim DPH gekonnt. Ich vermute ein Problem mit Rückwärtskompatibilität zu 1.4 etc.pp.

Der Stilfehler ist die Benennung des DPB. Die letzten Elemente des DPB heissen: ALLOC1 (byte), ALLOC2(byte), CKS (word) und OFF (word). Die Bedeutung kannste im DR Manual nachschauen.

Derjenige der das CP/M disassembliert hat, hat den DPB so beendet:

ALLOC1 (word), ALLOC2 (word), OFF (word).

Da bekam ich dann nachts die Panik: was ist hier los: wo ist CKS geblieben, wieso vergleicht das Login für den Drive den ALLOC2?, steht OFF jetzt an der falschen Position.

Wegen des geistlosen oder fehlerhaften Namens habe ich gar nicht gemerkt das ALLOC1 und ALLOC2 words waren und eigentlich alles ok war aber der Name blöd.

Sehr irritieren und ich bin auch voll drauf reingefallen.

Mein Emu tut nun übrigens, der RET-Fehler war das Problem. Sicher werde ich noch mehrere Fehler finden und toasten bevor ich auch nur annähernd die Stabilität von yaze erreiche. Aber ich arbeite dran. Ich versuche ein Unit-Test-System aufzubauen mit welchem ich Opcode für Opcode das Verhalten prüfen kann um damit schlußendlich Regressionstests über den Emulator fahren zu können.

Option 1: ich generiere einen Z80-Code, mit welchem ich alle Opcodes testen kann. Der Testlauf generiert einen Trace welchen ich dann mit TCL auf Korrektheit prüfen kann.

Option 2: es gibt ein TCL Interpreter im Emulator mit dem ich solche Tests machen kann.

In jedem Fall kann ich mittels einer TCL Bibliothek dann die Tests einfach und kompakt scripten oder gar den Code generieren.

Dieser Post wurde am 07.05.2012 um 20:44 Uhr von prefect editiert.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

006
07.05.2012, 20:40 Uhr
prefect

http://www.worldofspectrum.org/z88forever/dn327/z80undoc.htm

Dies und Sean Young's "Undocumented Z80" waren Paten bei RZ.

(Wenn man mal von yaze und Rodnay Zaks absieht)

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

007
07.05.2012, 20:56 Uhr
prefect

Etwas zum RZ:

es ging mir darum den Emu optimal and die Hardware anzubinden auf der er läuft. Dazu gibt es Plugin-Klassen die man einfach in die Z80-instanz einklinken kann. Das ist etwa wie eine Steckkarte im PC. Der Emu geht beim Boot hin und fragt alle Plugins nach den Adressen und erstellt damit eine Map für den I/O.

Damit ist es möglich, durch Ändern einzelner Zeilen und Einbinden anderer oder neuerer Klassen den Emu auf X-beliebige Hardware umzubiegen. Core bleibt der gleiche, aber was für ne MMU da ist oder wo im Addressraum die Hardware liegt ist frei konfigurierbar (compile-time, für PC später eventuell auch runtime, ich vermute compile-time reicht, muss ja auch ein BIOS da sein das mitspielt).

Der Einfachheit halber und weil es eben ein praktisches statt ein nostalgisches Projekt ist, gibt es z.b. statt ROM ein Boot-Device und einen IPL code: der Emulator kopiert das BIOS an Ort und Stelle und sprint es an und das BIOS schreibt ein Magic-Byte in ein Device und bekommt dafür - express - das CP/M geladen. So wird sowas dann auch auf einem Arduino schnell!

Was mir wichtig ist und was entstehen soll: eine virtuelle Arbeitsumgebung die auf die Host-Hardware über BIOS Treiber und emulierte Hardware Zugriff bekommen soll. Die Möglichkeit eine RZ-Arduino-Umgebung auf einem PC zu emulieren, samt virt. Hardware-Interfaces, also ohne Arduino für Arduino-CP/M zu entwickeln. Ein In-System-Debugger und -Tracer der es erlaub aber auch jeden Fehler zackig zu finden und zu rösten. Eine Entwicklungsumgebung die ich auf dem Arduino haben kann, im Betrieb, wenn ich so will. Die Möglichkeit Arduino/RZ Software auch Remote zu aktualisieren (SD-Karte tauschen, Ethernet, USB, EEPROM chip) ohne den Arduino selbst flashen zu müssen.

Wozu: damit verpasse ich dem dann minimal mit 30€ zu Buche schlagenden Arduino die Leistungsfähigkeit die sonst nur ein Dragon Board mitbringt, plus Fernwartung und Fernupgrades, etc. pp. das geht später vielleicht sogar kabellos. Ich finde der Gedanke hat was und vielleicht findet sich ja eine Gruppe Fans.

Ginge es mir nur um CPM würd ich yaze auf nem Winterm 9440 ans laufen bringen, und gut!

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

008
07.05.2012, 21:14 Uhr
m.haardt

Eben diese Konfigurierbarkeit von I/O kenne ich von yaze und genau darum verwendete ich es vor Ewigkeiten, selbst einen Emulator nach meinen Wünschen zu bauen. Aber gut, irgendwas geht da wohl an mir vorbei.

Spielen undokumentierte Opcodes inzwischen eine wichtige Rolle? Ich meine mich zu erinnern, dass der 64180 sich da auch etwas anders verhielt, aber das störte abgesehen von Xitan BASIC niemand, was dann halt gepatcht wurde. Beim 6502 waren sie dagegen sehr wichtig.

Bist Du schon bei den yaze Tests fündig geworden?

Michael

Dieser Post wurde am 07.05.2012 um 21:16 Uhr von m.haardt editiert.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

009
07.05.2012, 21:27 Uhr
prefect

Yup!

Der Z80 Emulator von yaze wird aus einem Perl-Script generiert, nicht wirklich was ich will. Ich hatte mit yaze-ag experimentiert und mit dessen Source mich eingelesen. Ich war nicht wirklich happy, das kann aber auch Ungeduld meinerseits gewesen sein.

Arduino ist im Prinzip eine C++-IDE simpler Bauart und ich will exakt für diese IDE den Emulator bauen. So dass dieser nativ direkt in der Arduino-1.0 als "Sketch" zu übersetzen ist. Mit CP/M drin und so weiter. Dann kann absolut JEDER der ein Arduino Buch bis Seite 30 gelesen hat, das CPM ans Rennen bringen. So zumindest die Theorie.

Den Hinweis auf die Yaze tests verfolge ich gleich. Danke!

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

010
07.05.2012, 21:39 Uhr
prefect

Heee, na das ist mal was: ein Z80 Programm für CP/M als CPU test. Damit bin ich direkt von 0 auf speed. Danke für den Tip!

DAS war mir am yaze echt entgangen, ich hatte mich viel zu sehr auf simz80 konzentriert.

Wegen ... da ist Dir was entgangen: hier mal ein Auszug aus RZ: das Main! Ich habe den Logging Ballast entfernt:

int main() {
BigMemory m(128*1024); // Create 128k memory
Z80cpu z80(m, 5, 10); // Create a CPU using that memory
PCconsole con(0x10); // Create a console
PCdisk dsk(0xD0, m, (char*)"opaque.dsk");
InitialProgramLoader ipldev(0x00, m, (char*)"cpm2.bin", 0xdc00);

z80.registerDevice(&con); // Tell the CPU about it.
z80.registerDevice(&dsk);
z80.registerDevice(&ipldev);

con.print((char*)"\nRenaissanZ/Linux\n");
con.print((char*)"Z80-Emulator for Linux\n");
con.print((char*)"Version 0.1\n\n");
con.print((char*)"(c) 2012 Adrian Wallaschek\n\n");

// Copy the boot code in the ram
//
InitialProgramLoader bios(0x01, m, (char*)"bios.bin", 0xf200);
int loaded = bios.load();
if (loaded != 603) {

m.wr(0xf200, 0x76);

}

// RUN!
//
z80.setPC(0xf200);
do {
z80.executeOneCommand();
} while (!z80.isHalted());

Der Code oben initialisiert die CPU, klebt ne Disk und ne Console dran. Ein IPL wird gebaut für das CPM (so bekommt man ein BIOS kurz ;-)). Optionen am Z80 geben die Länge der Device-Table un der Breakpoint table an.

Breakpoint sind HALT Befehle deren Adresse und eigentliches Kommando in einer Tabelle vermerkt sind. Ein Vorgriff auf den in-system-debugger der noch kommt.

Ich glaube, selbst wenn ich noch kommandozeilen optionen etc. einpflege, C++ ist generell aufgeräumter als C insbesondere generiertes C.

Dieser Post wurde am 07.05.2012 um 21:47 Uhr von prefect editiert.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

011
07.05.2012, 21:51 Uhr
prefect

Nachschlag:

der Grund warum yaze das mit dem Perl macht ist auch experimentell es ging um tuning: funktionen gegen macros.

C++ kann sowas mit einem keyword: inline und schon is es effektiv ein Macro aber mit dem Ganzen sicherheitsgewusel vom compiler. Das hat irgendwie mehr.

(Nicht zuletzt ist es auch ein Projekt um meine Krallen wieder an etwas code zu schärfen. C++ stand an!) ;-)

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

012
07.05.2012, 22:11 Uhr
proof80

Hi Adrain!

Und wenn CP/M 2.2 durch ist, geht's weiter mit CP/M 3.0 bzw. ZSYS ?

Gruß, Wolfram

P.S.: Was Du da treibst, motiviert

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

013
07.05.2012, 22:27 Uhr
prefect

Ich will definitiv diese Schritte gehen.

Mit CP/M 3.0 komm ich klar. Für ZSYS fehlen mir sourcen, info , Hilfe.

Das kommt aber alles noch. Der Ganze Trick am System wird sein, dass für die verschiedenen Systeme dann - ich nenne es hochtrabend - Distributionen existieren werden: je eine Systemdisk und für die Anwendungen jeweils Disk-Images mit 4 Disks an board (quasi partitioniert). Das macht m.E. Sinn, da wir keine Subdirectories haben.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

014
07.05.2012, 22:32 Uhr
m.haardt

Das Perlscript tut schon etwas mehr als nur mit inline ginge. Ich bin kein Freund von Perl, halte aber eine Codegenerierung bei einem Emulator für sinnvoll, um maximale Geschwindigkeit zu erreichen. Man mag die Augen vor anderen Zielarchitekturen verschließen, aber auch Compiler ändern sich und wer will dann schon alles umschreiben, um ein spezielles neues Feature zu verwenden.

Yaze ist schwach bei Interrupts und DMA, die parallel zur CPU emuliert sollten. Das spielt bei CP/M kaum eine Rolle, bei MP/M aber schon. Wenn Du kein Museum willst, dann ist CP/M 3 wenigstens anzuraten, aber wenn Du schon ein modulares BIOS nimmst, kannst Du auch gleich MP/M benutzen. Ich wollte da bei Yaze immer mal was dran tun, kam aber nie dazu.

Die schönste Emulation, die ich je sah, ist TME (the machine emulator). Die Art, wie die Architekturkonfiguration Komponenten zu einer virtuellen Maschine verbindet, ist einfach wunderbar, und der Einsatz von Threads bildet die Parallelität in der Hardware natürlich nach. Bei anderen Emulatoren dominiert die CPU-Emulation, bei TME ist der Name Programm: Es emuliert wirklich die ganze Maschine.

Michael

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

015
07.05.2012, 23:33 Uhr
prefect

Klingt interessant, TME werde ich mir mal anschauen.

Was interrupts betrifft, da steht noch Arbeit an. Es hängt davon ab ob die jeweilige Hostplatform sowas anbietet. Da es um "Microcontroller"-Programme unter CP/M geht, kann das Bedeutung gewinnen, allerdings viel später.

DMA ist eine Comfortsache mehr als eine Parallelisierungsfrage. Arduino und andere kleinere Plattformen haben kein Multithreading, darum ist das nicht auf meinem Radar, aber zwischen zwei Kommandos einfach mal nen Block transferieren ist schon s*x.

Irgendwann werde ich sicher über MP/M nachdenken. Insbesondere weil ich mir damals an einem MP/M für den NDR-Klein-Computer satt die Zähne ausgebissen habe.

CP/M 3 kommt definitiv bald. TPA-Optimierung und insbesondere Flow-Control für die sekundäre Kommunikation (AUX

machen es interessant. Ich gedenke die Anbindung von einigen Sensoren oder so im Arduino exemplarisch über ein Device mit "Kommandozeile" zu machen.

Das lässt sich dann sehr hübsch und anschaulich programmieren.

Aber DAS ist noch science fiction. Ein Schritt zur Zeit. Derzeit baue ich die Terminal-Emulation für ncurses. gutes altes VT52, hatte ich immer lieber als VT100, die VT100 ist so ballüsig.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

016
09.05.2012, 00:57 Uhr
prefect

Michael,

ich möchte mich nochmal für den Hinweis auf die yaze-tests bedanken. Ich verstehe nun auch warum ich die nicht bemerkt hatte. Ich hatte nicht mit yaze sondern mit yaze-ag experimentiert. Yaze-ag ist noch etwas wuseliger als das Original. Und die tests sind nicht mehr dabei!

Tatsächlich glaube ich, ich hätte den yaze einbetten können, aber jetzt gehe ich nach vorne und schaue was kommt.

Die yaze tests finden gerade reichlich meiner Flüchtigkeitsfehler. Das spart mir Wochen geistlosen Suchens. Ich kann mich nicht genug bedanken!

Ich denke ich werde den Gedanken des Test-Programms weiter ausbauen, wenn ich die Zeit dafür finde. Erstmal bin ich kräftig am Debuggen!

Dieser Post wurde am 09.05.2012 um 00:57 Uhr von prefect editiert.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

017
09.05.2012, 21:10 Uhr
m.haardt

Freut mich, dass es hilft, aber danke nicht mir, sondern dem Autor von yaze. :-) Ich finde yaze kein bisschen wuselig, sondern einfach wunderbar gradlinig und sehr gruendlich gemacht. yaze-ag schaute ich mir nie an, denn Z80 wurde mir irgendwann zu langweilig und CP/M ist einfach katastrophal rückständig, wenn man die Alternativen gesehen hat.

Es ist sehr, sehr schade, dass RIOS nie richtig das Licht der Welt gesehen hat. Nach dem bisschen, was es zu lesen gibt, hätte das eine Konkurrenz zu OS/9 sein können. Da wirkt CP/M (auch MP/M) wie ein Dinosaurier.

Michael

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

018
09.05.2012, 23:58 Uhr
prefect

Ist sicherlich alles richtig. Ich komme ja aus einer anderen Ecke.

Ich versuche nicht CP/M quasi als Rechner einzusetzen sondern eher als nach der Art einer Java-VM oder USCD-pCode für Micro-Controller wie den ATMEL/Arduino. Verglichen damit dass so ein Micro-Controller im Feld nicht mehr programmiert wird, bzw. werden kann, wäre so ein CP/M doch ein netter Schritt nach vorne.

Das Problem mit yaze: es geht dafür nicht. Die kleinste Variante von Ardiuno hat keine nennenswere Menge RAM. Genug für den Emulator nicht genug für das CP/M. Die RAMs hängen an einer mit 8MHz betriebenen seriellen Leitung (SPI). Das wird richtig langsam und brauch eine Art auf das RAM zuzugreifen, die eher nach I/O aussieht. Trotzdem mit 8MHz Takt hoffe ich auf hinreichend Performance um nicht zu verzweifeln.

Spätestens da kann yaze nicht mit. Übrigens ... derzeit ungetuned ist yaze um Faktor 10-20 schneller als RZ. Das war erwartet, allein wegen der Klassenstruktur und der Art des RAM-Zugriffs.

Auf www.wallaschek.de habe ich übrigens so eine Art Blog, dort habe ich auch direkt meinen Dank an Cringle gerichtet (auch wenn er's nicht weiss ;-)).

Ich kämpfe mich derzeit durch zexall.com, den Test von yaze. Hartes Brot.

Danach kommt einiges an Tuning und die Portierung. Generell geht es mir zuforderst um Funktionalität. Wer firepower braucht nimmt für was auch immer doch sowieso ein ARM-Board mit Linux. Mit geht es um kompakte Qualität und optimal griffige Tools fürs Debuggen. Mit RZ ist das portabel von einem Arduino mit SPI-RAMs über einen Arduino mit richtigem RAM oder z.B. einem Wyse AMD-K6 oder ARM-basierten Thin-Client, vielleicht sogar die dBox-II bis hin zu einem Linux PC oder Mac. Software entwickeln - deployen auf was auch immer angemessen erscheint. Kaum Strombedarf.

Für Vieles s*x und für IT-Einsteiger vielleicht die "bessere" Lernplattform für Fundamentales.

Aber ich träume schon wieder ... warum auch nicht ... das ist der schönste Teil an dem Projekt.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

019
11.05.2012, 02:02 Uhr
prefect

Also bis auf 2 tests bestehe ich den zexall.com

Das ist ein Anfang. Tinst.com funktioniert trotzdem noch nicht. :-(

Wie es scheint brauche ich eine bessere "Vergleichssoftware" als zexall und insbesondere ein Referenz-System zum Vergleichen.

Ich hab mal beim Eletronikladen angefragt was die für nen Z80mini3 haben wollen, alternativ schiesse ich bei ebay nen C128D (mit der Idee hatte ich sowieso gespielt). Für meinen alten apple IIe habe ich vor September keinen Platz zum Aufstellen und er C128D passt noch unter den Tisch. Irgendwie.

Bis dahin werd ich mal an einer Software basteln die präziser zur Sache geht als Zexall. Es wird auch so ein Exerciser wie Zexall, der aber auf einem CP/M Programm Referenzdateien aus Test-Beschreibungen generiert. Die gleichen Beschreibungen soll dann der RZ abarbeiten. Der Rest ist eine Frage von diffs. Irgendsowas muss es werden.

Das Problem mit zexall: er sagt es ist was falsch, er lässt aber offen was. Da nun z.B. in einem einzigen Test 8 Kommandos geprüft werden und nichtmal erklärt wird was anders ist, kann ich mir nen Wolf suchen. Und zex deckt nichtmal alles ab wie es scheint. Also: eigenen Exerciser entwerfen.

Erstmal nehm ich mal yaze als Referenz-System, irgendwo muss ich anfangen. Später hol ich mir Z80 und eZ80 als Referenz dazu.

Es wird schon werden. Das Problem der enorm grossen Dateien für die Referenzdaten muss ich dann natürlich lösen. Aber bei MB grossen Disks muss a was gehen. Ansonsten raus zur seriellen Schnittstelle, Arduino dran und auf SD-Card schreiben lassen. Einige Tage später ist das Set komplett ;-). Ich kann so nicht weiter testen, nicht wenn ich in diesem Jahrtausend noch fertig werden will. Es muss mal wieder etwas Werkzeug her.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

020
11.05.2012, 08:27 Uhr
proof80

Zitat:

prefect postete
Das Problem mit zexall: er sagt es ist was falsch, er lässt aber offen was.

Was meinst Du, kann man zexall aufbohren, z.B. durch eine detailierte Fehlermeldung? Taugt das Prinzip was? Wenn ich da in die source schau, muss ich erst mal tiefer graben, bis sich mir die Funktionsweise erschließt:

Quellcode:

; <adc,sbc> hl,<bc,de,hl,sp> (38,912 cycles)
adc16:    db    0ffh        ; flag mask
    tstr    0edh,042h,0,0,0832ch,04f88h,0f22bh,0b339h,07e1fh,01563h,0d3h,089h,0465eh
    tstr    0,038h,0,0,0,0,0,0f821h,0,0,0,0,0    ; (1024 cycles)
    tstr    0,0,0,0,0,0,0,-1,-1,-1,0d7h,0,-1    ; (38 cycles)
    db    0d4h,08ah,0d5h,019h            ; expected crc
    tmsg    '<adc,sbc> hl,<bc,de,hl,sp>....'

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

021
11.05.2012, 08:28 Uhr
proof80

Zitat:

prefect postete
Und zex deckt nichtmal alles ab wie es scheint.

Hast Du das im Fokus, was da fehlt?

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

022
11.05.2012, 10:44 Uhr
prefect

zexall kommentiert sehr genau sein eigenes Problem, Cringle war das sehr selbstsicher, "Zexall" sagt ob es funktioniert oder nicht. Liefert aber keine Hilfe zur root-cause-Analyse. Es sagt nicht warum es zu dem Schluss kommt.

Nein man kann es nicht aufbohren, nur das Konzept klauen und feiner granulieren.

Ein einzelner Test berechnet eine Prüfsumme über zig tausend Ausführungen.
(z.B. 8 Kommandos * 256 Input Werte * 16 Flag-Zustände oder so).

Bei also zig-tausend executions ... welche brachte den Fehler?

tstr ist ein Macro, ist dokumentiert aber dünn. Effektiv beschreibt es die Ausgangswerte für die Register und ein Kommando und eine Maske mit der das Kommando variiert werden kann. In Deinem Bsp. oben ist es ein adc und der wird mit dem 38 (00111000) variiert. Also die 3 markierten bits werden mit 0-7 befüllt wodurch sich die anderen Kommandos ergeben.

Die Idee ist haltbar. Das Problem ist: Es gibt nur einen CRC um das Ergebnis zu prüfen. Es müsste mindestens mal 8CRC geben. Eigentlich einen CRC pro Ausführung und der sollte kein CRC sein sondern einfach ein snapshot der Ergebnis-Register. und dann wärs gut.

Klar ist: ist habe in meinem trace allein 25 byte zustandsdaten, d.h. für eine echten Test heisst das 25*256*256 = ca. nen MB

Was geht also:
- Interface nach draussen bauen, eventuell das Ausgabe-Format auf "relevante Register" kürzen (bei einem ADD A,B brauch ich de,hl,pc nun wirklich nicht) also die Ausgabe über flags steuern und damit ggfls auf 5-8 byte quetschen. Das geht dann pro Test auf eine Datei. Für den Test eine Linux Software mit TCL bauen die das analysiert!

2. Problem: wenn man einen spezifischen Test abfahren will, kostet alles was sowieso schon funktioniert viel Zeit, der Test sollte also von einer Datei getrieben sein und nicht im Code.

Das sind alles keine "Probleme" im zex. Zex wurde mit anderen Zielen geschrieben.

Das mach ich mir mal neu übers Wochenende.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

023
11.05.2012, 19:52 Uhr
m.haardt

Ich würde eher zusehen, yaze und Deinen Emulator parallel den gleichen Code ausführen zu lassen, und nach jedem Befehl den Maschinenzustand zu vergleichen. zexall langt, um die Korrektheit nachzuweisen. Du willst doch nur zwei Bugs finden, wozu da Riesenaufwand treiben?

Michael

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

024
11.05.2012, 20:09 Uhr
prefect

Nö, ich will mehr. Ich will das Dingen dahingehend ausbauen, dass ich exakte Kompatibilität zu diverser CPU-Hardware herstellen kann.

Z80ABH, Z180, eZ80, HD64180 was auch immer.

Desweiteren, wenn dieses Ding mehr taugen soll als zu einer Nostalgie-Spielerei, sollte die vCPU vollständiger Qualitätssicherung unterliegen.

Bei Java ist die JVM auch das wohl am besten getestetste Element ;-)

Auf diese Weise kann ich dann ähnlich z.B. einem IOS Emulator den Arduino und dessen Peripherie in der Z80 Emulation komplett virtuell bereitstellen.

Ich mir klar dass das science fiction ist. Aber das ist mein Ziel: einen sicheren im Sinne von "zuverlässigen" Emulator, der die Microcontroller Plattform mit diverser jahrelang getesteter Software versorgt aus Zeiten wo Qualität noch höher bewertet wurde als der Ausliefertermin.

Bin ich ein Spinner? Ja vielleicht. Wenn ich nur so gut werden wollte wie der Yaze, hätte ich den gleich umstricken und behalten können.

Aber richtig, meine erste Referenz, mangels Hardware, wird der yaze sein.

ich hab mir die Schaltpläne angeschaut vermutlich krieg ich einen Z80 auf einem Breadboard hin. Ich wäre ja nicht der erste. Die Idee an der Hardware wäre den Z80 so anzubinden wie Apple das tat: RAMs vom Host und die CPU mittels BUSREQ davon fernhalten ;-). Das ginge hinter einem Arduino Mega. Ich muss dazu aber noch lernen wie ich den I/O vom Mega, bzgl. RAM-Zugriff auf High schalte.

Der Gedanke:
- Breadboard nehmen
- Arduino Mega nehmen (hat digitalen IO den man auch als RAM interface konfigurieren kann).
- Z80 auf Breadboard.
- RAM auf Breadboard. Erstmal nur 64kB, später auch mit Bank-Switching.
- Interrupts etc. verdrahten.

Dann können Z80 und Arduino wechselweise aufs RAM zugreifen. Arduino ist master und kann den Z80 über Busreq "freilassen" oder sich das RAM heranziehen (Busreq, bei BusAck hat der Z80 das Feld geräumt, dann den eigenen MemBus aktivieren und zugreifen). Der Z80 könnte über den Datenbus und ein Latch Interrupts an den Arduino schicken.

Ok das Design ist noch sehr High Level aber ne Idee die nicht viel kostet.

Frage: hat jemand den Schaltplan von so einer alten Apple Z80 Karte?

Der Arduino wäre über Ethernet und V.24 die Console, liefert insgesamt 4 serielle Schnittstellen und ggf. auch eine parallele, mit der Micro-VGA wäre dann auch PS/2 und VGA-Text dran, die Ethernet-Karte hat einen SD-Slot.
Da ist Musik drin. Aber wie immer .... science fiction ... oder will jemand mithelfen bei der Hardware?

Ich werde also mal den Exerciser bauen und schauen ob ich für's erste vielleicht mal einen C128D bei ebay erzocken kann.

Profil || Private Message || Suche

Zitatantwort || Editieren || Löschen || IP

Seiten: -1- [ 2 ] [ CP/M 2.2 ]