Hallo, ich habe sowas ähnliches wie Beitrag "CP/M auf ATmega88" gemacht, nur mit einem Atmega8515 und dessen XMEM-Interface. Daran sind 32 oder 64 KB SRAM angeflanscht (maximal 63 KB nutzbar, was vollkommen ausreicht), sowie eine SD-Karte am SPI. Emuliert wird ein Intel 8080, kein Z80. Die Platine ist mit Kupferlackdraht handverdrahtet. Ursprünglich hatte ich nur 32 KB RAM für CP/M, aber weder Wordstar noch Multiplan oder Zork reicht das. Daher das Türmchen. Softwareseitig ist alles in Assembler geschrieben, entweder avra (für den AVR) oder z80asm (für den i80). Rückblickend ist die Wahl des Controllers ganz besonders klug gewesen, denn sowohl Flash als auch RAM sind eher zu klein. Aber ich wollte keine neue Platine machen. Der i80-Emulator (den ich hier schonmal gepostet hatte) passt dank geschicktem Alignment und Tricks in unter 3 KB Flash, aber für eine effiziente Z80-Emulation bräuchte ich deutlich mehr. Mit nur 512 Byte RAM fehlt dem Chip der interne Speicher, um einen Sektor der SD-Karte zu puffern. Also habe ich den Code für die SD-Karte in das BIOS verlegt, inklusive (de)blocking. Für das BIOS ist genug Flash vorhanden, so dass das System prinzipiell selbst booten kann (alternativ kann man auch von einer Hex-Datei starten). CP/M selbst passt wiederum nicht in den Flash, die SD-Karte ist also tatsächlich notwendig. Das System mappt vier 8 MB-Laufwerke A: bis D: auf die SD-Karte, mit einem Offset von 4 MB. Damit bleibt die Karte für andere Anwendungen nutzbar. Performance ist durchaus ordentlich. Bei 16 MHz und 2 Waitstates entspricht die Geschwindigkeit ziemlich genau einem i8080/Z80 mit 2.6 MHz. (Verglichen wurde FRACTAL.BAS unter MBASIC-80 mit den Zahlen von https://forum.classic-computing.de/forum/index.php?thread/22627-runcpm-speed-vergleich-auf-verschiedenen-plattformen/). Die Disk-Performance ist akzeptabel. Der Sektor-Cache im Deblocking beschleunigt nur Lesezugriffe. Geschätzt komme ich mit meiner 128 MB MicroSD-Karte auf etwa 14 KB/s lesend und 3.5 KB/s schreibend. CP/M-Software ist klein genug. LADDER macht Spaß und ist angenehm schnell. Zork und die ganzen Infocom-Adventures laufen auch. (Anmerkung: Die Interpreter von Zork I, II und III sind bis auf die Dateinamen identisch und funktionieren auch für die anderen V.3-Abenteuer.) Viel Spaß, Svenska
:
Bearbeitet durch User
Nettes Projekt. Ist schon interessant, daß gerade CP/M noch immer interessant genug ist, daß dafür Emulatoren auf unterschiedlicher Basis geschrieben werden. W.S.
Ein paar Fragen zur Platine bzw. zu den Bausteinen: - warum hast du beim SRAM zwei Pins umgebogen und auf der Oberseite der Platine verlötet? geht das nicht auch auf der Unterseite? - auf dem SD-Addon-Board: ist da noch ein ROM drauf? Fall ja, wie wird darauf zugegriffen? Und insgesamt: Wie lange braucht man für die Anpassungen von CP/M und BASIC auf eigenes System, bei entsprechender Erfahrung?
Sigi schrieb: > - warum hast du beim SRAM zwei Pins umgebogen und > auf der Oberseite der Platine verlötet? geht das > nicht auch auf der Unterseite? Das sind zwei SRAMs piggy-back (aka. Huckepack oder Türmchen), alle Signale parallel, nur /CS ist getrennt für oben und unten, siehe auch: S. R. schrieb: > Ursprünglich hatte > ich nur 32 KB RAM für CP/M, aber weder Wordstar noch Multiplan oder Zork > reicht das. Daher das Türmchen.
Sigi schrieb: > - warum hast du beim SRAM zwei Pins umgebogen und > auf der Oberseite der Platine verlötet? geht das > nicht auch auf der Unterseite? Das sind die /CS-Pins von den beiden SRAM-Bausteinen (2x32 KB), weil CP/M mit nur 32 KB RAM keinen Spaß macht. Deswegen auch der zusätzliche 74xx-Baustein (A15 vom AVR geht einmal auf /CS vom einen Baustein, und durch einen Inverter auf /CS vom anderen Baustein). Aber ja, das kann man auch besser machen, z.B. mit einem 64 KB oder 128 KB SRAM - dann reichen drei Bausteine (AVR + Latch + SRAM) für das Gesamtsystem. > - auf dem SD-Addon-Board: ist da noch ein ROM drauf? > Fall ja, wie wird darauf zugegriffen? Nein, das ist nur ein Levelshifter für die SD-Karte. Der Atmega8515 ist für 16 MHz bei 5 V spezifiziert, aber SD-Karten wollen 3.3 V für Versorgung und Datenleitungen. Diese Fassung hat einen ordentlichen Pegelwandler verbaut, die meisten anderen hängen nur einen Widerstand in Reihe. > Und insgesamt: Wie lange braucht man für die > Anpassungen von CP/M und BASIC auf eigenes > System, bei entsprechender Erfahrung? Ich habe nur ein CP/M-BIOS angepasst, kein BASIC (mir reicht Microsoft's MBASIC unter CP/M). Ein minimales BIOS kann man sich in ein paar Stunden selbst schreiben, das ist auch sehr gut im "Alteration Guide" beschrieben (z.B. http://bitsavers.trailing-edge.com/pdf/digitalResearch/cpm/2.2/CPM_2.2_Alteration_Guide_1979.pdf), inklusive Beispielcode. Ursprünglich hatte ich ein eigenes Terminalprogramm genommen, welches Disk-Sektoren über die serielle Leitung schickt - mit sowas ist ein komplettes BIOS in ein paar 100 Byte drin. Ein bisschen fieser wird es, wenn die Hardware komplexer und dynamisch wird. In meinem Fall sind das SD-Kartentreiber und 512 Byte-Sektoren. Andere Systeme haben eine Terminalemulation (ADM-3A oder VT52) für die Videoausgabe integriert, unterstützen mehrere Disk-Formate und das IOBYTE. Das kann man beliebig weit treiben, soweit der Speicher reicht.
Hi Svenska, fand das ganz interessant und habe das mal nachgebaut mit 128K-SRAM (nur 64K benutz) auf einer Platine von einem alten Projekt, HW sollte ok sein. Haste mal nen Tip wieso sich CP/M nicht meldet hier ein Log vom Terraterm : Memtest... ok Boot internal BIOS? [y/n] y Booting... MINICPM v2 SD CARD ACMD41 V1:04 CPU halted Boot internal BIOS? [y/n] n Please send IHEX now Gruß ths
Hi, die SD-Karte antwortet auf ACMD41 mit 0x04 ("invalid command"). Laut Flowchart ist das eine MMC-Karte, die habe ich nicht implementiert (passt nicht in einen MicroSD-Slot). Meine Test-Karte für SDv2 hat auch nicht funktioniert (MISO blieb dauerhaft high), daher habe ich SDv2 (ist SDv2 == SDHC?) ebenfalls nicht implementiert. Probiere mal eine andere SD-Karte. Ich habe eine MicroSD-Karte von SanDisk mit 128 MB im Einsatz, aber das hilft dir vermutlich nicht viel. Gruß, Svenska
:
Bearbeitet durch User
So, nun ist fast ein Monat vergangen. Jetzt frage ich mal: Wie soll es hier weitergehen? W.S.
W.S. schrieb: > Wie soll es hier weitergehen? Weiß nicht. Was hättest du gern? Es ist ein Projekt mit Code und funktioniert bei mir. Da sich ths nicht mehr gemeldet hat, weiß ich nicht, ob er es hinbekommen hat oder nicht. Ein passendes zweites Projekt (auch mit AVR drin) habe ich zwar angefangen, aber noch nicht fertiggestellt. Das kommt aber irgendwann, falls es jemanden interessiert.
S. R. schrieb: > Weiß nicht. Was hättest du gern? Hmm.. nach meinen Wünschen brauchst du dich nicht zu richten. Hab selber so ein Projekt zum Spielen (selber + Verwandtschaft), allerdings komplett anders aufgezogen: 20 MHz Z80, 128 K RAM (2 Bänke mit 8 K Common), dazu 1 MB RO-Drive (Flash) und nochmal 1 MB RAM Disk akkugestützt, dazu CF-Karte für mehrere Drives, Logik per CPLD, Konsole entweder vom PC aus via FT245 oder per IR-Tastatur (die gab's mal für unter 1€ bei Pollin) nebst PIC16 als Tastaturanschluß und GLCD mit RAIO-Chip, Drucker per Centronics-Interface. Das ist also eigentlich das komplette Gegenteil deines Projektes und ich schätze, es würde dir nicht wirklich gefallen. Allerdings kann man damit sowohl das Benutzen eines CPLD üben, Assembler für PIC16 und Z80 üben, und obendrein ein wenig Layouten üben. Und es war ne sinnvolle Verwendung von verbleiten Rücklauf-Beständen an Chips, die der Bestücker nicht selbst verschrotten wollte. Ist also schon ne Weile her damit. Also mache du, wie es dir am besten gefällt. Was mir hier an diesem Forum immer stärker aufgefallen ist, ist daß gar viele Leute den Boden unter den Füßen (sprich die Verbindung zur Hardware) verloren haben und nicht mehr wissen, auf welcher Seite der Griff beim Lötkolben ist. Von daher finde ich dein Projekt richtig gut, weil es all den anderen zeigt, wie man Hardware zum Funktionieren bringen kann nur mit einigen Bauteilen und etwas Wickeldraht. Siehe auch die diversen Basteleien von Prof. Bernd Ulmann, der hat auch ein Händchen für Rechnersysteme, die mit Wickeldraht gemacht sind. W.S.
W.S. schrieb: > Das ist also eigentlich das komplette Gegenteil deines Projektes > und ich schätze, es würde dir nicht wirklich gefallen. Ich habe zwischenzeitlich ein paar ZETA V2 mit Z80 (10 MHz, 512 KB RAM, 512 KB Flash bzw. 4 MHz, 512 KB RAM, 128 KB Flash) aufgebaut und damit gespielt. Den Reiz der etwas größeren 8 Bit-Welt kann ich also durchaus nachvollziehen. Leider gibt's keine ordentlichen C-Compiler für i80. ACK generiert nur mäßig guten Code, ist aber stabil und wenigstens C89. SDCC ist moderner, soll aber buggy sein und macht nur Z80. Es gibt im Netz ein paar vereinzelte Leute, die sich mit der Technologie auch noch tiefgreifend befassen. Beispielsweise CP/Mish (https://github.com/davidgiven/cpmish), wo jemand versucht, ein freies CP/M-System zu bauen. Oder FUZIX (https://github.com/EtchedPixels/FUZIX), was ungefähr einem leicht modernisierten V7-UNIX entspricht.
Hi Svenska, anbei mein Verständnis wie die Schaltung nach den Angaben in deinem Readme File und dem ATmega8515 Datenblatt aussehen müsste. Bei der Verschaltung der Steuersignale /RD /WR und ALE mit den Peripheriebausteinen bin ich mir nicht ganz sicher, da die Signale an dem RAMs und dem Latch andere Bezeichnungen haben. Wenn ich mir auf der Lötseite der Rasterplatine die Verdrahtung des TTL Inverters anschaue, wird dort mehr als 1 Gatter benutzt. - Thomas
@Svenska, jetzt habe ich das Ganze mal per Steckbrett mit 128k SRAM ähnlich wie User ths (Gast) gemäß beiliegender Schaltung erprobt. Man benötigt dann ja nur 3 ICs (µC, Latch und SRAM, von dem 64K benutzt werden). Auch bei mir bootet CP/M 2.2 nicht, siehe Screenshot. Das File minicpm.img befindet sich auf einer 128MB Mikro SD Karte, die mit FAT16 formatiert wurde. Die Karte wird wohl auch erkannt, aber dann kommt die Meldung "HARD REBOOT NOT IMPLEMENTED". Was kann die Ursache sein? - Thomas
Thomas N. schrieb: > anbei mein Verständnis wie die Schaltung nach den Angaben in deinem > Readme File und dem ATmega8515 Datenblatt aussehen müsste. Ich hab das im Detail nicht durchgeschaut, aber sieht gut aus. > Wenn ich mir auf der Lötseite der Rasterplatine die Verdrahtung > des TTL Inverters anschaue, wird dort mehr als 1 Gatter benutzt. Öh, da müsste ich mal nachschauen. Eigentlich reicht ein Gatter, um die jeweilige RAM-Bank auszuwählen. Thomas N. schrieb: > Man benötigt dann ja nur 3 ICs (µC, Latch und SRAM, > von dem 64K benutzt werden). Genau, das ist die Alternative. > Auch bei mir bootet CP/M 2.2 nicht, siehe Screenshot. > Das File minicpm.img befindet sich auf einer 128MB Mikro SD Karte, > die mit FAT16 formatiert wurde. Das geht nicht. Die minicpm.img ist ein Image einer SD-Karte und muss direkt ab Adresse null geschrieben werden. Aus Platzgründen (nicht genug RAM im AVR) habe ich das Disk-Interface in 8080-Assembler geschrieben, ohne Partitionstabelle und FAT; die Laufwerke liegen auf fixen Sektoren (siehe README). Das CP/M-BIOS beginnt ab dem zweiten Sektor, daher ist der erste Sektor für eine Partitionstabelle nutzbar - solange keine Partition in den ersten 36 MB liegt, ist der Stick dann normal nutzbar. > Die Karte wird wohl auch erkannt, aber dann kommt die Meldung > "HARD REBOOT NOT IMPLEMENTED". Was kann die Ursache sein? Die Initialisierungsroutinen (zwischen INITSEG und INITEND) wird nach dem Start überschrieben, um das BIOS zur Laufzeit zu verkleinern. Damit ist ein Kaltstart nicht möglich. Das interne BIOS lädt die CP/M-Sektoren von der SD-Karte, initialisiert sich und springt dann in den geladenen Code. In deinem Fall sind das alles Nullen, d.h. die CPU führt schlicht NOPs aus, bis sie auf das BIOS trifft. Dessen Kaltstartroutine ist aber überschrieben, daher die Meldung. Etwas irreführend, tut mir Leid. :-)
:
Bearbeitet durch User
@svenska danke für die ausführliche Antwort. Könntest Du mal im Detail erklären, wie ich die Imagedatei ab Sektor 0 auf die Mikro SD Karte kopiere. Ich verfüge über ein aktuelles Linux Mint sowie Windows 7 oder 10. Beim Studium der Firmware sind mir noch ein paar Dinge aufgefallen: 1. In main.asm sind am Ende diverse CALL Instruktionen, die der ATmega8515 aber nicht unterstützt. AVRA meldet hier keinen Fehler, sondern übersetzt das mit 94 0e xx xx. AVRStudio 4.17 liefert die Fehlermeldung. 2. Dort befindet sich auch die Zeile lpm zl, z+ was infolge des gleichen Registers zu undefiniertem Ergebnis führt und von AVRStudio mit einem Fehler quittiert wird, von AVRA nicht. - Thomas
jetzt habe ich die Imagedatei mal mittels DD unter Linux auf die Mikro SD Karte kopiert wie im Screenshot dargestellt - leider ohne Erfolg. Die Meldung HARD REBOOT NOT IMPLEMENTED bleibt bestehen. - Thomas
Thomas N. schrieb: > 1. In main.asm sind am Ende diverse CALL Instruktionen, die der > ATmega8515 aber nicht unterstützt. AVRA meldet hier keinen Fehler, > sondern übersetzt das mit 94 0e xx xx. AVRStudio 4.17 liefert die > Fehlermeldung. Dafür, dass der das nicht unterstützt, springt er aber offensichtlich die richtigen Adressen an... :-) Aber ja, ein paar Teile des Systems sind nicht mit der gleichen Sorgfalt erstellt worden wie andere. Irgendwann wollte ich dann einfach fertig werden. > 2. Dort befindet sich auch die Zeile lpm zl, z+ was infolge des gleichen > Registers zu undefiniertem Ergebnis führt und von AVRStudio mit einem > Fehler quittiert wird, von AVRA nicht. Du meinst im CPU-Core? Das wusste ich nicht. In meinen Tests hat das auf mehreren AVRs (auch Atmega328p) immer funktioniert. Ist auch direkt in der Kernschleife, die muss schnell sein... Thomas N. schrieb: > jetzt habe ich die Imagedatei mal mittels DD unter Linux auf die > Mikro SD Karte kopiert wie im Screenshot dargestellt - leider > ohne Erfolg. Die Meldung HARD REBOOT NOT IMPLEMENTED bleibt bestehen. Das ist schade und liegt daran, dass ich ein Pfosten bin und meine eigene README nicht gelesen habe. Ist halt doch schon etwas her, ich bitte um Entschuldigung. Hatte meine Antwort schnell vor der Reise ins Büro grob aus dem Kopf geschrieben und schlecht recherchiert. :-) Laufwerk A: liegt auf der SD-Karte ab Sektor 8192 - und das BDOS wird von dort geladen (Track 1), nicht vom Beginn der SD-Karte. Wie in der README beschrieben, leider nicht deutlich genug. Wenn du eine normale Partition auf einer leeren SD-Karte erzeugst, dann beginnt die üblicherweise ab Sektor 2048 (1 MB) oder 8192 (4 MB). Früher hat man die Partitionen an Spuren ausgerichtet, bei Flash ist das kontraproduktiv und ich richte immer an 4 MB aus, weil viele Karten das als Eraseblock nutzen. Du kannst die Datei einfach mit: > dd if=minicpm.img of=/dev/sdc bs=512 seek=8192 an die richtige Stelle schreiben. Oder du erstellst mit fdisk/cfdisk eine Partition ab Adresse 8192 (entweder 8 oder 32 MB groß) und schreibst das Image direkt da rein. Dann kannst du mit den cpmtools auch direkt auf der Partition arbeiten: > cpmls -f minicpm /dev/sdc1 Du musst aber die Definition für "minicpm" in die /etc/cpmtools/diskdefs eintragen (steht in der README). Noch ein Hinweis: Die minicpm.img enthält ein paar Dateien in verschiedenen Userbereichen (0:TOOLS, 1:ZORK, 2:LADDER, 3:WS, 4:MP). Noch ein Nachtrag: Die Laufwerke B: und C: und D: enthalten kein gültiges Dateisystem und CP/M kann damit nur begrenzt umgehen und die ungültigen Einträge auch nicht immer löschen. Dafür gibt es CLRDIR.COM, das solltest du einmalig benutzen, um die anderen Laufwerke einzurichten (das Y für die Bestätigung muss ein Großbuchstabe sein!).
:
Bearbeitet durch User
Danke, das war der entscheidende Hinweis, jetzt funktioniert es! Wenn man cpu_cb.inc und cpu.inc erst am Ende von main.asm einbindet, kann man alle CALL Instruktionen durch RCALL ersetzen ohne dass die Adresslimits überschritten werden. Die von AVRStudio beanstandete Zeile lpm zl, z+ befindet sich in cpu.inc.
Thomas N. schrieb: > Danke, das war der entscheidende Hinweis, jetzt funktioniert es! Freut mich, dass es funktioniert und ich hoffe, dass du wenigstens ein bisschen Freude mit dem System hast. :-) > Wenn man cpu_cb.inc und cpu.inc erst am Ende von main.asm einbindet, > kann man alle CALL Instruktionen durch RCALL ersetzen ohne dass die > Adresslimits überschritten werden. Mich irritiert gerade, dass das System trotzdem funktioniert - die CPU startet ja. Seltsam. In jedem Fall sollte man auf die Adressen im Image aufpassen, sonst verschwenden die Alignment-Beschränkungen in der CPU recht viel Flash. > Die von AVRStudio beanstandete Zeile > lpm zl, z+ befindet sich in cpu.inc. Ich hab die Zeile gefunden, nachdem du mich darauf hingewiesen hast... aber da es so funktioniert, lasse ich das einfach so. Es gibt ja nicht so viele AVRs mit XMEM und wenig RAM. Rückblickend hätte ich das für einen Atmega162 aufziehen sollen, aber so ist es auch ganz gut.
Übers Wochenende habe ich mich noch mal etwas mit dem mini CP/M Rechner beschäftigt. Er läuft jetzt stabil mit 18,432MHz µC Takt, was auch den Rundungsfehler bei der Berechnung der Baudrate minimiert. Unabhängig davon, auf welchem Laufwerk man eingeloggt ist, landet man nach der Ausführung eines Programms oder einem Warnstart (^C) immer auf Laufwerk A. Beiliegender Screenshot eines Compilerlaufs von Pascal/MT+ zeigt die Laufwerkswechsel. Da ich die Schaltung - derzeit als Steckbrett-Aufbau - gerne weiter nutzen möchte, habe ich hierzu eine Platine entworfen. Falls Interesse besteht, könnte ich nach Fertigstellung & Test die Gerberfiles hier posten. - Thomas
Thomas N. schrieb: > Unabhängig davon, auf welchem Laufwerk man eingeloggt ist, > landet man nach der Ausführung eines Programms oder einem > Warnstart (^C) immer auf Laufwerk A. Ich glaube, das ist ein Bug in nbios/disks.inc:306 (dskst). Das ZF Flag wird nur für A == 0 gesetzt, nicht für A < 4. Idee 1: Ersetze das "or a" durch "xor a". Idee 2: Füge vor dem "or a" ein "xor a" ein. Habe aber beides nicht getestet, weil die Hardware gerade nicht griffbereit. Dann das BIOS neu assemblieren und avr/bios.inc neu generieren (ich habe das mit xxd und vim gemacht). Das sollte das Problem beheben. Thomas N. schrieb: > Da ich die Schaltung - derzeit als Steckbrett-Aufbau - gerne weiter > nutzen möchte, habe ich hierzu eine Platine entworfen. Funktioniert die Platine auch mit dem Atmega162? Lassen sich die oberen 64 KB ansprechen?
Idee 1 hat bereits funktioniert. Ich habe bei der Gelegenheit mal die Baudrate auf 115200 verdoppelt, was auch stabil läuft. Zur Platine: Wenn ich das richtig sehe, haben beide Controller das gleiche Pinlayout. Der ATmega162 sollte also auch funktionieren. Der externe Speicher beginnt dann erst ab Adresse 0x0500. Zur Umschaltung auf die oberen 64 KB habe ich jetzt noch den freien µC Pin 29 im Layout mit A16 verdrahtet, ich habe die Platinenfertigung ja noch nicht beauftragt. Die Umschaltung der 64 KB Blöcke muss dann separat erfolgen.
:
Bearbeitet durch User
Thomas N. schrieb: > Idee 1 hat bereits funktioniert. Teste bitte auch, dass du nicht auf Laufwerk E: wechseln kannst (und wieder zurückgeworfen wirst). Wenn der Test nicht richtig funktioniert, dann hast du eine Endlosschleife aus Fehlermeldungen. :-) Thomas N. schrieb: > Wenn ich das richtig sehe, haben beide Controller das > gleiche Pinlayout. Der ATmega162 sollte also auch funktionieren. Genau. Ich hatte in die AVR087 geschaut und die Unterschiede sind eher gering. Der 162 kann aber wohl seinen Takt auf B0 ausgeben. Thomas N. schrieb: > Die Umschaltung der 64 KB Blöcke muss dann separat erfolgen. Lieber so als komplett ungenutzt lassen. Die restlichen 64 KB könnte man als RAM-Disk benutzen - mit 128 KB RAM sollte sich auch FUZIX portieren lassen, wäre aber nicht ganz einfach. > Platinenfertigung Hättest du Lust, eine Platine nach Schweden zu schicken? :-)
:
Bearbeitet durch User
S. R. schrieb: > Hättest du Lust, eine Platine nach Schweden zu schicken? :-) Ich würde auch eine nehmen :)
Nach dem Versuch auf Laufwerk E zu wechseln kommt der erwartete BDOS Error, danach landet man wieder auf dem zuvor benutzen Laufwerk; das scheint also OK zu sein. Dann ist mir die Verwaltung der Imagefiles noch nicht ganz klar: Wenn ich das originale minicmp.img mit dd nach der zuvor beschriebenen Methode auf die SD Karte kopiere, dann die Laufwerke B: bis D: initialisiere und auch Dateien dorthin kopiere funktioniert das wie erwartet. Wenn ich danach dem ursprünglichen minicpm.img mit cpmcp Dateien hinzufüge und das dann wieder mit dd auf die Karte kopiere, sind die im ersten Schritt auf B: bis D: kopierten Daten immer noch vorhanden, sie liegen also außerhalb des Images. Nun hatte ich die Idee, den gesamten Inhalt der Karte mit dd auf ein Image zu schreiben, das dann die Größe der SD Karte hat. Es lässt sich zwar auch wieder zurück auf die Karte schreiben und funktioniert auch für B - D. Wenn ich diesem Image weitere Dateien hinzufüge (Laufwerk A), werden die auch mit cpmls angezeigt, im CP/M Directory tauchen sie aber nicht mehr auf. Von Interesse wäre einen Datenaustasch mit dem PC via XMODEM über die CON: Schnittstelle bereitzustellen, wie es im Z80-MBC2 Projekt realisiert wurde. Dann könnte man leicht mal einzelne Dateien ohne Änderung der Image Datei austauschen (mit PUTTY o.ä). XMODEM benötigt hierzu allerdings einen Empfangspuffer von 128 Byte. Ich habe jetzt 3 Platinen bei Aisler in Auftrag gegeben, Lieferung in ca. 2 Wochen. Eine davon ist für S.R. reserviert (schick mir eine PN mit deiner Adresse). Für alle anderen sind beiliegend die Gerber Files.
Thomas N. schrieb: > Nach dem Versuch auf Laufwerk E zu wechseln kommt der erwartete BDOS > Error, danach landet man wieder auf dem zuvor benutzen Laufwerk; das > scheint also OK zu sein. Eigentlich sollte man auf A: landen. Naja, solange es funktioniert... Thomas N. schrieb: > Dann ist mir die Verwaltung der Imagefiles noch nicht ganz klar: Du überschätzt das System, glaube ich. :-) Das BDOS greift direkt auf die SD-Karte zu und mappt die Laufwerke so: A: belegt die Sektoren 8192 bis 24575 ( 4 bis 12 MB) B: belegt die Sektoren 24576 bis 40959 (12 bis 20 MB) C: belegt die Sektoren 40960 bis 57343 (20 bis 28 MB) D: belegt die Sektoren 57344 bis 73727 (28 bis 36 MB) Alle Laufwerke sind 8 MB groß und haben die gleiche Geometrie; die erste Spur (64 Sektoren x 512 Byte = 32 KB) ist für den Bootcode (BDOS und CCP) reserviert. Die minicpm.img enthält nur eins dieser Laufwerke, mit CP/M schon in der Bootspur. Die anderen Laufwerke brauchen keinen Bootcode, deswegen habe ich keine Images dafür gebaut. Du kannst mit "fdisk" Partitionen über diese Bereiche erzeugen (Typ 0x52), dann kann cpmls direkt auf die Partitionen (als mmcblk0pX) zugreifen, oder du nimmst "losetup" und erzeugst passende Devices per Hand (als loopN). Die einzelnen Laufwerke kannst du auch mit dd raus- und reinkopieren (mit seek=... oder skip=...) Thomas N. schrieb: > Wenn ich diesem Image weitere Dateien hinzufüge (Laufwerk A), > werden die auch mit cpmls angezeigt, im CP/M Directory tauchen > sie aber nicht mehr auf. Ein CP/M-Dateisystem enthält keine Informationen über sich selbst, d.h. CP/M kann nichtmal erkennen, ob das Dateisystem gültig ist. Die Struktur steht im BIOS. Wenn cpmcp das falsche Format oder den falschen Offset benutzt, dann merkt CP/M davon nichts. Mit "fsed.cpm" kannst du dir die Details anschauen. Thomas N. schrieb: > XMODEM benötigt hierzu allerdings einen Empfangspuffer von 128 Byte. Was meinst du mit Empfangspuffer? XMODEM habe ich nicht getestet, aber PIP, LOAD und DUMP sind vorhanden. Ich weiß aber nicht, ob das bei hohen Baudraten noch stabil läuft; mein Z80 @ 4 MHz mag XMODEM nur bis 19200 bps. Adresse ist auf dem Weg.
OK Problem gelöst: Ich habe mich jetzt nochmal etwas genauer mit dem dd von Linux beschäftigt, und das Extrahieren und Zurückspeichern der Abbilder einzelner Laufwerke von/auf die SD Karte funktioniert wenn man die Optionen seek, skip und count entsprechend nutzt. Zur Dateiübertragung: XMODEM übertragt in Blocks zu 128 Byte. Die Übertragung jedes Blocks wird mit einer Prüfsumme verifiziert. Stimmt die nicht, wird der Block erneut übertragen. Das funktioniert bei meinem Z80-MBC2 CP/M Rechner für Files aller Art perfekt mit PUTTY oder Hyperterminal, die beide das XMODEM Protokoll unterstützen - und das bei 115200 Baud. Du kannst ja bei Gelegenheit versuchen ob XMODEM auf deinem minicpm Rechner über die CON: Schnittstelle läuft, bei mir hat es bisher nicht funktioniert. Immerhin ist es mir jetzt gelungen, mit PIP Textfiles fehlerfrei vom PC direkt auf die SD Karte zu schreiben ebenfalls bei 115200 Baud, aber mit einer kleinen Sendpause nach jedem Byte, damit Zeit für den Schreibvorgang bleibt.
Thomas N. schrieb: > Zur Dateiübertragung: XMODEM übertragt in Blocks zu 128 Byte. Die > Übertragung jedes Blocks wird mit einer Prüfsumme verifiziert. In nbios/nbios.asm werden conin/conout direkt auf Port 0x10 geleitet, der in avr/cpu_cb.inc auf uart_raw_getc/uart_raw_putc (und direkt auf UDR) geht. Die Zeichen werden also nicht verändert. Die UART ist nicht interruptgesteuert, hat keinen FIFO und besitzt kein Handshaking! Wenn du da mit hoher Geschwindigkeit 130 Bytes am Stück draufschießt, kann das nichts werden. Versuche mal lieber 9600 oder 1200 bps, die sind realistisch. Übrigens: Bei 115.200 bps steigt der IHEX-Parser im AVR aus und man kann ohne zusätzliche Wartezeiten nicht mehr von einer Hex-Datei booten. Daher die 57.600 bps als Standardwert. Für CP/M ist das deutlich zu viel. Der Z80-MBC2 hat mindestens 8 MHz auf dem Z80 (verglichen mit den ungefähr 2.6 MHz auf dem 8080 hier) und einen enormen seriellen Puffer: > // Print if the input serial buffer is 128 bytes wide > (this is needed for xmodem protocol support) > if (SERIAL_RX_BUFFER_SIZE >= 128) > Serial.println(F("IOS: Found extended serial Rx buffer")); Mein ZETA V2-Board hat einen 16550 UART (mit 16 Byte FIFO) und verkraftet XMODEM nur bis maximal 19200 bps. Wieviel ohne den FIFO möglich wäre, weiß ich nicht.
:
Bearbeitet durch User
noch eine Frage zu den beigefügten Testprogrammen, die sich als Intel Hexfiles (reine Textfiles) übertragen lassen: Hierzu habe ich mal die Baudrate auf 19200 heruntergesetzt und 2 der Tests (8080pre & cputest) hochgeladen. Zunächst läuft ein Zähler hoch mit abschliessender Meldung "finished". Dann kommt entweder sofort oder nach einiger Zeit die Meldung "CPU halted". Weitere Meldungen pass / fail o.ä sehe ich nicht, d.h. die Programme selbst erzeugen keine Ausgaben an das Terminal?
Thomas N. schrieb: > Zunächst läuft ein Zähler hoch > mit abschliessender Meldung "finished". Das ist der Hex-Loader. Der Zähler ist die Adresse in der Datei; 0x4BF0 ist die letzte Datenzeile in tests/cputest.hex. Thomas N. schrieb: > Dann kommt entweder sofort oder > nach einiger Zeit die Meldung "CPU halted". Die Testprogramme sind ganz normale CP/M-Programme, die ab Adresse 0x0100 liegen werden und die BDOS-Funktionen 02h (CONOUT) und 09h (PRINTSTR) benutzen. In avr/cpu.inc ist eine kleine BDOS-Emulation, die du erst aktivieren musst (".define BDOS"). Alternativ kannst du die Programme auch von CP/M aus starten. Dazu kopierst du die Hex-Datei in das CP/M (entweder direkt auf die SD-Karte oder seriell mit PIP) und konvertierst sie mit LOAD in eine COM-Datei. Das CP/M-BIOS selbst sollte auch bootbar sein; in avr/main.asm wird ab Adresse 0x0100 ein "JP 0x7A00" (bis 32 KB) bzw. "JP 0xEA00" (darüber) angelegt. Wenn die Hex-Datei diesen Sprung nicht enthält, wird also direkt dorthin weitergesprungen.
OK dann sehe ich wegen 2x conout bei CP/M aber alles doppelt ;-) IHEX läuft bei mir immer noch stabil mit exakt eingestellten 115200 Baud aus 18,432 MHz µC Takt.
Nun habe ich 2 der Testprogramme (Hexfiles) mal auf das SD Image für Laufwerk A kopiert. Load beanstandet dann aber die falsche Startadresse <> 0x100.
Thomas N. schrieb: > OK dann sehe ich wegen 2x conout bei CP/M aber alles doppelt ;-) Aber sicher doch. ;-) Thomas N. schrieb: > IHEX läuft bei mir immer noch stabil mit exakt > eingestellten 115200 Baud aus 18,432 MHz µC Takt. Meine Platine hat exakt 16 MHz, vielleicht ist auch einfach nur der Fehler zu groß. Freut mich aber, ich habe nicht damit gerechnet, dass der Loader schnell genug ist. Thomas N. schrieb: > Load beanstandet dann aber die falsche Startadresse <> 0x100. Du stellst echt gute Fragen. Da habe ich spontan keine Antwort. Die erste Zeile von CPUTEST.HEX lautet: > :100100003E023CEA0030C30901F331FF2FCD4F21FD Das ist eindeutig an Adresse 0100h (: 10 0100 00...). Vielleicht mag DDT die Datei lieber: > DDT CPUTEST.HEX > ^C > SAVE 80 CPUTEST.COM Sollte aber einfacher sein, die originalen COM-Dateien im Netz zu finden oder mit objcopy zu konvertieren. Die Programme habe ich für die CPU-Entwicklung benutzt (deswegen auch die BDOS-Emulation dort).
:
Bearbeitet durch User
Schon komisch, mit DDT / SAVE hat es funktioniert. Anbei nochmal etwas zum Thema UART Baudrate.
Hier 2 Fotos von der fertig bestückten und gut funktionierenden Platine. Da A16 zur Ansteuerung des 2. 64K Blocks mit PE2 des ATmega8515 verdrahtet ist, sollte man dieses (hier noch nicht genutzte) Signal zu Beginn vom main.asm initialisieren z.B. (sbi DDRE, 2, cbi PORTE, 2). Wie schon erwähnt, läuft das bei mir jetzt mit 18,432MHz; beim SRAM reicht 1 Wait Zyklus aus, 0 Zyklen geht nicht.
Mir erschliesst sich nicht warum du
1 | lpm zl, Z+ |
benutzt. Macht das nicht dasselbe wie ein
1 | lpm zl, Z |
anschliessend wird ja zh eh überschrieben, d.h. das auto-increment hat keine Funktion
Peter S. schrieb: > Macht das nicht dasselbe wie ein > lpm zl, Z > > anschliessend wird ja zh eh überschrieben ZH wird natürlich nicht überschrieben, sondern der gelesene Wert wird in ZL geladen. Und bzgl. Unterschied zw. lpm ZL,Z und lpm ZL,Z+: Überleg mal, was mit ZH passiert, wenn vor dem Befehl in ZL 255 drinstand...
Peter S. schrieb: > Mir erschliesst sich nicht warum du >> lpm zl, Z+ > benutzt. Macht das nicht dasselbe wie ein >> lpm zl, Z > anschliessend wird ja zh eh überschrieben, > d.h. das auto-increment hat keine Funktion Stimmt. Ich tippe sehr stark auf "das hat der Autor bestimmt ohne groß drüber nachzudenken so gemacht". :-) Es ist sowieso egal: Funktioniert beides, braucht beides die gleiche Taktanzahl, ist beides offiziell undefiniert. Dafür sieht es genauso aus wie die beiden Zeilen drüber. Jim schrieb: > ZH wird natürlich nicht überschrieben, > sondern der gelesene Wert wird in ZL geladen. Der relevante Code lautet:
1 | lpm zl, Z+ |
2 | ldi zh, high(fetch_begin) |
Erst wird ZL überschrieben (undefiniertes Verhalten laut Dokumentation), direkt danach dann ZH. Es ist also tatsächlich egal, welche Variante genutzt wird.
Thomas N. schrieb: > Hier 2 Fotos von der fertig bestückten und gut funktionierenden Platine. Super. Ich habe dir jetzt nochmal eine PN mit der Adresse geschickt (die dritte insgesamt), wenn die nicht ankommt, dann schicke mir einfach deine Mail per PN und ich antworte direkt...
lpm zl, z hat gegenüber lpm zl, z+ den Vorteil, dass damit die Fehlermeldung in AVRASM2 (AVRStudio) verschwindet und man die Firmware nun auch problemlos hiermit assemblieren kann. Mittlerweile habe ich die TPA um 1KB auf 56KB erhöht, was trotz des SRAM Limits noch möglich ist: - MSIZE bzw. MEM auf 61 setzen, BIOS & CPM.SYS neu übersetzen - AVR Firmware mit neuem BIOS und Startadresse EE00 statt EA00 neu assemblieren - CPM.SYS per Hex-Editor in das vorhandene Image ab Adresse 200h patchen (5683 Byte überschreiben). @ S.R. Vielleicht kannst du mal beschreiben, wie du die ursprüngliche Image Datei erzeugt hast, dann könnte man statt zu patchen eine neue Datei anlegen. Die Platine ist unterwegs.
:
Bearbeitet durch User
Thomas N. schrieb: > lpm zl, z hat gegenüber lpm zl, z+ den Vorteil, dass damit die > Fehlermeldung in AVRASM2 (AVRStudio) verschwindet und > man die Firmware nun auch problemlos hiermit assemblieren kann. Oh, das wusste ich nicht. Ich habe nur kurz in das Instruction Set Manual geschaut und überlesen, dass "lpm zl, z" wohldefiniert ist. > Mittlerweile habe ich die TPA um 1KB auf 56KB erhöht, > was trotz des SRAM Limits noch möglich ist: Das dürfte dann die Grenze sein. Ich hatte ursprünglich mit MSIZE=62 gearbeitet, bis der SD-Treiber zu groß wurde. Ich sehe, du hast auch am System geschraubt. Irgendwelche coolen Dinge? :-) > Vielleicht kannst du mal beschreiben, wie du die ursprüngliche Image > Datei erzeugt hast, dann könnte man statt zu patchen eine neue Datei > anlegen. Die "minicpm"-Diskdef setzt "boottrk 1", also einen Boot-Track. Traditionell ist der erste Sektor ein first-stage-loader, gefolgt von BDOS, CCP und BIOS. In diesem System wird das BIOS extern geladen, also sind nur BDOS und CCP (CPM.SYS) relevant; der first-stage-loader wird nicht benutzt. Das Image habe ich mit einem dummy-loader (512 Byte) erzeugt, dann mit mkfs.cpm erzeugt und anschließend mit Nullbytes aufgebläht: $ dd if=/dev/zero of=loader.bin bs=512 count=1 $ mkfs.cpm -f minicpm -b loader.bin -b cpm.sys tmpdisk.img $ dd if=tmpdisk.img of=newdisk.img bs=$((256*64*512)) conv=sync $ rm tmpdisk.img Nicht schön, und in erster Linie unzureichend dokumentiert. Wenn ich etwas Zeit finde (aber erst in ein paar Wochen), werde ich das ganze Feedback einarbeiten und ein neues Paket schnüren. > Die Platine ist unterwegs. Super, freut mich!
:
Bearbeitet durch User
Bitte 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.