CP/M auf Atmega8515 mit XMEM

[S. R. (svenska)]

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

[W.S. (Gast)]

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.

[Sigi (Gast)]

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?

[Martin H. (horo)]

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.

[S. R. (svenska)]

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.

[ths (Gast)]

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

[S. R. (svenska)]

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

[S. R. (svenska)]

Hat es mit einer anderen SD-Karte funktioniert?

[W.S. (Gast)]

So, nun ist fast ein Monat vergangen.
Jetzt frage ich mal:
Wie soll es hier weitergehen?

W.S.

[S. R. (svenska)]

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.

[W.S. (Gast)]

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.

[S. R. (svenska)]

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.

[Thomas N. (tonevi)]

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

[Thomas N. (tonevi)]

@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

[S. R. (svenska)]

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. :-)

[Thomas N. (tonevi)]

@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

[Thomas N. (tonevi)]

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

[S. R. (svenska)]

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!).

[Thomas N. (tonevi)]

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.

[S. R. (svenska)]

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.

[Thomas N. (tonevi)]

Ü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

[S. R. (svenska)]

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?

[Thomas N. (tonevi)]

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.

[S. R. (svenska)]

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? :-)

[900ss (900ss)]

S. R. schrieb:
> Hättest du Lust, eine Platine nach Schweden zu schicken? :-)

Ich würde auch eine nehmen :)

[Thomas N. (tonevi)]

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.

[S. R. (svenska)]

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.

[Thomas N. (tonevi)]

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.

[S. R. (svenska)]

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.

[Thomas N. (tonevi)]

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?

[S. R. (svenska)]

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.

[Thomas N. (tonevi)]

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.

[Thomas N. (tonevi)]

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.

[S. R. (svenska)]

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).

[Thomas N. (tonevi)]

Schon komisch, mit DDT / SAVE hat es funktioniert.
Anbei nochmal etwas zum Thema UART Baudrate.

[Thomas N. (tonevi)]

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.

[Peter S. (cbscpe)]

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

[Jim (Gast)]

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...

[S. R. (svenska)]

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:

lpm zl, Z+
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.

[S. R. (svenska)]

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...

[Thomas N. (tonevi)]

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.

[S. R. (svenska)]

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!