CP/M auf ATmega88

Geschwindigkeit ist ungefähr 8080 @ 2 MHz.
Turbo-Pascal braucht einen Z80, der derzeit noch nicht unterstützt wird.

do9brx schrieb:
> <\n>PC=2000 <\r>
> <\n>        A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000       31
> 00 20 <\r>
> <\n>PC=2003 <\r>
> <\n>        A =00 BC =0000 DE =0000 <\0><\r>

Der erste Befehl wird richtig gelesen, jedoch nicht korrekt ausgeführt. 
Der Stackpointer sollte auf $2000 stehen die Ausgaberoutine bricht 
jedoch mittendrin vor der Ausgabe von HL ab. Es gibt eigentlich keinen 
Grund für so einen Abbruch. Die Ausgabe ist absolut linear programmiert 
(utils.asm). Kann eigentlich nur ein Interruptaufruf dazwischen kommen. 
Hast du die aktuellen Quellen (siehe hier)?

http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/

Ich bin etwas ratlos, hat jemand noch eine Idee?

Leider habe ich ausser Deinen keine anderen Rams :-( Hab mein Lager 
komplett durchwühlt aber leider nichts zum Ersatz gefunden.

Die Quellen waren die aktuellen, Elko ist bestückt, Spannung ok.

Werd mir das am Wochenende nochmal genauer ansehen, bis dahin muss ich 
ein paar andere 8-Bit Baustellen abschließen.

Gruß, Andre

Peter Sieg schrieb:
> Habe heute mal versucht meinen 4-bit Prototypen (1x 4256 Ram), kein
> Stützkondensator etc. an einem Atari ST als Terminal anzuschließen.
> [...] Habe daraufhin einen 10uF Stützkondensator eingebaut.

> Ich kann da wirklich keine intelligenten Schlüsse raus ziehen ausser:
> Der CP2102 schein den AVR CPM nicht zu beeinflussen/beinträchtigen.?
> Der MAX3232 Wandler aber irgendwie schon..?

Der MAX3232 verwendet eine Ladungspumpe, um die für die RS-232 
erforderlichen Spannungen zu erzeugen. Das kann auf der 
Versorgungsspannung stören, wenn nicht (die richtigen) 
Stützkondensatoren eingebaut sind.

Die Größe der Stützkondensatoren richtet sich nach der Frequenz der 
Störungen: je kleiner die Frequenz, desto kleiner muss der Kondensator 
sein, damit er schnell genug nachliefern kann. Wenn der 10µF Dein 
einziger Entstörkondensator ist, solltest Du es auf jeden Fall noch mit 
einem 100nF zusätzlich probieren.
Oft werden auch ganze Reihen verwendet, wie z.B. 100nF, 1µF, 100µF.

Für die, die nicht selber zusammen bauen möchten/können, habe ich auch 
noch ein paar wenige, fertig aufgebaute und getestete AVR CP/M USB 
Sticks inkl. passender SD Karte abzugeben. Bei Interesse -> Mail.

Peter

Hier ALGOL Compiler (P-Code) und Interpreter.
ALGOLM name.ALG -> Übersetzt nach name.AIN
RUNALG name.AIN führt aus.
2 Beispiele dabei.
Hanoi läuft einwandfrei.
Lunar läuft? Kommt nach Eingabe der Zahl nicht zurück..? unter Altairz80 
ok.

---

Ich glaube, wir habe evtl. noch einen, kleinen Fehler in der 8080 
Emulation..
Mal Multiplan starten in in r1c1 12, in r2c1 24 und in r3c1 =r1c1+r2c1 
eingeben (Summe aus 12+24). Dann r1c1 auf 17 ändern.. ;-)

---

Hier mal wie ich solche Diskimages zusammen stelle.
Altairz80 herunterladen und CPU = 8080 einstellen!. cpm2 laden.
Diskimage z.B von retroarchive herunterladen und testen.
Wenn sie laufen, die Dateien mit w aus dem Image auf Filesystem 
schreiben.
Mit cpmcp dann in ein leeres avrcpm Image kopieren.
Image auf SD Karte kopieren und ausprobieren.

---

Arbeitet eigentlich jemand noch/wieder an der Z80 Unterstützung, jetzt
da ein Z80 Emulator im Source (AX81) verfügbar ist..?

Peter

Peter Sieg schrieb:
> Für die, die nicht selber zusammen bauen möchten/können, habe ich auch
> noch ein paar wenige, fertig aufgebaute und getestete AVR CP/M USB
> Sticks inkl. passender SD Karte abzugeben. Bei Interesse -> Mail.
>
> Peter

gibt es auch noch die variante mit dem vga anschluss (vers. 2...?). was 
kostet ein stick?

Ronny Minow schrieb:
> gibt es auch noch die variante mit dem vga anschluss

Nein, alle Bausätze sind raus. Von Stick müßte es noch genug geben, 
einfach Peter fragen.
Ich bin gerade an einer neunen VGA-Variante als VT100 Terminal. Ist aber 
noch ein Brettaufbau.

Joe G. schrieb:
> Ronny Minow schrieb:
>> gibt es auch noch die variante mit dem vga anschluss
>
> Nein, alle Bausätze sind raus. Von Stick müßte es noch genug geben,
> einfach Peter fragen.
> Ich bin gerade an einer neunen VGA-Variante als VT100 Terminal. Ist aber
> noch ein Brettaufbau.

wenn es da auch bausätze geben wird, nehme ich gerne eins

Joe G. schrieb:
> Ich bin gerade an einer neunen VGA-Variante als VT100 Terminal.

Hier nun die ersten Ergebnisse. Das VT100 Terminal läuft vollständig 
ohne PC mit der AVR CP/M Platine. Für VGA und PS-2 werden genau zwei 
IC's verwendet (1 x P8X32A und 1 x AT24C512 als Speicher). Läuft alles 
auf 3.3V, somit sind auch keine Pegelwandler notwendig.

Hier die Schaltung der VGA und Tastaturansteuerung.

pollmull schrieb:
> Oder hier mit gleichem Chip Terminal gleich noch mit CP/M drin:

Ganz nett, vielelicht baue ich mal das Dracblade in der V5 auf. Die Z80 
Emulation ist darin vollständig enthalten.

Oder PIC32 mit z80sim:

http://www.kenseglerdesigns.com/cms/node/8

Peter

Da nun bald Weihnachten wird, gebe ich einige, restliche Platinen des 
AVR CP/M USB Sticks unter SK ab für 6,50€/Stück. Habe noch 7 Stück da.
Es gibt NUR die Platinen!

Bei Interesse per Mail melden bei: peter (dot) sieg1 (at) gmx.de

Versand per Post für 2€ in D egal wie viele Platinen.

Peter

Hier etwas für die Feiertage.
Die Version 4.0 mit VGA auf einer Platine.

Änderungen gegenüber der alten Version:
- VGA mit VT100 Terminal auf einem Propellerchip
- SRAM
- ATMEGA 644
- zwei serielle Schnittstellen
- 8 Bit –E/A
- Stromversorgung über USB

USB1 ist für die Inbetriebnahme und Experimente gedacht. Über diese 
Schnittstelle kann der Propeller geladen werden und die CP/M Ausgaben 
über ein Terminal mitgelesen werden. Werden die Steckbrücken (JP1 und 
JP2) richtig gesteckt, dann ist das CP/M-System direkt mit dem VT100 
Terminal verbunden.
USB2 ist für alle Anwendungen frei. Denkbar ist z.B. ein Bootloader für 
den AVR. Damit muss bei der Softwareentwicklung der AVR nicht jedes Mal 
über die ISP-Schnittstelle geflasht werden.
Der DRAM wurde durch einen handelsüblichen SRAM ersetzt. Damit sind 
jedoch zwei zusätzliche Latch notwendig geworden.
Durch den Wechsel auf den ATMEGA 644 ist nicht nur noch eine weitere 
serielle Schnittstelle dazu gekommen, sondern auch noch ein komplett 
freier 8-Bit Port. Belegt habe ich PA0 bis PA7, damit können die Pins 
auch als 8-fach ADC verwendet werden.
Die Software muß natürlich noch angepasst werden. VGA und VT100 Terminal 
läuft schon.

Schöne Weihnachten!
Joe

Ich weiß nicht, wurden am Beginn des Projektes nicht alle, die mit SRAM 
kamen, mit den Worten: "Das ist dann ganz was anderes, mach eine eigenes 
Projekt auf!", fortgeschickt? Ich meine der Reiz war ein CP/M auf zwei 
Chips. Das haben wir mit 2xRAM für 8-bit schon aufgeweicht. Noch ein 
Chip sind dann doch etwas über einer großzügig ausgelegten Definition 
von 2 Chips, meiner Meinung. Außerdem frage ich mich ob eine 
zusätzliche, inkompatible HW-Version Softwareentwickler anlocken kann. 
Da müssten dann langsam HW-Abstraktionsschichten eingezogen werden ;-) 
Das bindet doch nur Resourcen, die sowieso nicht da zu sein scheinen. 
Ich hätte lieber Z80 als HW-V4.
Nur meine bescheidene Meinung.
frank

Hallo Frank,
endlich mal eine Meinung der ich mich anschliessen kann...
Nur leider bin ich nicht der richtige für Software, aber Hardware haben 
wir genug. Ein CPM im Propeller mit VGA etc. gibt es schon und passt 
nicht zum AVR. Ich finde die Kombination die du da gebaut hast, als 
Variante sehr gut. Aber leider lassen die Softwarefreaks hier auf sich 
warten...Z80 ist defenitiv überfällig.
Gruß
Hans-Werner

@Frank&Hans-Werner

Sicher sind eure Argumente nicht ganz vom Tisch zu fegen. Für jedes 
Projekt gibt es Vor- und Nachteile. Der Propeller sollte auch kein CP/M 
emulieren sondern nur als Tastatur und VGA Ausgabe fungieren. Das kann 
er gut - das macht er gut.

Meine Motivation war die Folgende.
- nicht mehr so einfach beschaffbare DRAM’s verhindern einen breiten 
Nutzerkreis
- keine weiteren freien Pins am AVR um sich die Welt nach außen zu 
öffnen
- keine serielle Schnittstelle wenn ein Terminal angeschlossen ist

Nun könnte man auch einen größeren AVR nehmen ohne gleich auf SRAM 
zuwechseln. Aber auch das hätte eine angepasste Softwareversion zu 
Folge. Da die RAM-Ansteuerung schon ausgelagert ist, kann sie auch für 
den statischen RAM angepasst werden.
Es war einfach ein Hardwarevorschlag von mir. Diesem Vorschlag braucht 
keiner zu folgen. Mir hat das Arbeiten daran Freude bereitet – einzig 
das zählt!
Schöne Weihnachten!
Joe

Joe G. schrieb:
> Es war einfach ein Hardwarevorschlag von mir. Diesem Vorschlag braucht
> keiner zu folgen.
Das ist schon klar und wir wollen auch nur gepflegt Vor- und Nachteile 
diskutieren.

> Mir hat das Arbeiten daran Freude bereitet – einzig
> das zählt!
Das sei Dir auch gegönnt.
Dir auch schöne Weihnachten!
frank

Frank P. schrieb:
> Das ist schon klar und wir wollen auch nur gepflegt Vor- und Nachteile
> diskutieren.

Wie wir sehen ist die Resonanz auch sehr gering. CP/M ist halt nicht 
AdroidGalaxis500. Da mein ursprünglicher Hardwarevorschlag auf eine 
vereinfachte Bauteilbeschaffung ausgerichtet war, werde ich diese 
Variante vorerst zurückstellen. Der ATMEGA 644 bekommt nun wieder seine 
beiden üblichen DRAM’s. Die Idee der zwei seriellen Schnittstellen, eine 
für den Bootloader, werde ich beibehalten. So passiert es nicht mehr, 
dass die 5V ISP noch im AVR-Board stecken und die SD-Card nicht gezogen 
ist.
Joe

Joe G. schrieb:
> Die Idee der zwei seriellen Schnittstellen, eine
> für den Bootloader, werde ich beibehalten.

fboot von Peter Dannegger kann auf jedem Pin lauschen, ob UART oder 
nicht. Genauso geht auch 1-Wire-Betrieb.
So braucht man keinen Controller mit 2 UARTs (war der mit 2en nicht erst 
der 644P?) und für Layout wärs auch sehr einfach, da man nun direkt bei 
zwei leeren Pins eine Serielle Schnittstelle machen kann, ohne ewig 
durch die Gegend zu routen.

Nils S. schrieb:
> fboot von Peter Dannegger kann auf jedem Pin lauschen, ob UART oder
> nicht. Genauso geht auch 1-Wire-Betrieb.

Das wären in der aktuellen Variante PC4 zund PC5. Damit würde I2C 
wegfallen. Soll nur CP/M darauf laufen - kein Problem. Aber mal einen 
Schritt weiter gedacht. Über eine zweite serielle Schnittstelle könnte 
man mit Kermit o.ä. auf das CP/M zugreifen. Am 8-Bit Port kann ein LCD 
oder, oder angeschlossen werden.

Peter Sieg schrieb:
> Z80 Emu. in ASM gibt ja nun Dank Jörg Wolfram im AX81 Projekt.. Basis
> wäre also ja vorhanden..

In der Quelle 8080int-jmp.asm ist ja auch schon alles vorbereitet. Es 
müssen (nur) noch die Z80 spezifischen Codes nachgetragen werden. Ich 
habe mal in der To_Tabelle die Befehle mit (Z80) markiert. Dabei viel 
mir auch auf, dass der OpCode D9 falsch interpretiert wurde. Laut 8080 
sollte das RET sein, ausgeführt wurde NOP und im Z80 ist es EXX. Ich 
habe es korrigiert (siehe Anhang).

Joe

Peter Sieg schrieb:
> Hast du mal probiert, ob der ominöse Multiplanfehler nun weg ist..?
Nein noch nicht.

@alle
Schraubt schon jemand an der Z80 Umsetzung? Wenn ja, bitte kurz melden 
damit wir nicht doppelt schrauben ;-)

Joe

Der Fehler im Multiplan ist immer noch..

Einfach mal in Zelle r2c2 23 und in r3c2 4 und in r4c2 r2c2+r3c2 
eintragen.
Ergibt ersteinmal richtig 27. Dann r3c2 von 4 auf 9 ändern .. :-(

Peter

Peter Sieg schrieb:
> Der Fehler im Multiplan ist immer noch..

Bist dur dir sicher, dass Multiplan unter dem 8080 läuft? Möglicherweise 
ist die unterschiedliche Parity-Flag Behandlung die Ursache. Setze doch 
mal EM_Z80 auf 1, dann werden die Z80 Flags ausgeführt. Ich habe erst 
mal alle Z80 JR nn Befehle eingebaut. Im nächsten Jahr mehr...

Allen einen schönen Jahreswechsel mit viel Elan für neue und alte 
Projekte!

Gruß Joe

Joe G. schrieb:
> In der Quelle 8080int-jmp.asm ist ja auch schon alles vorbereitet. Es
> müssen (nur) noch die Z80 spezifischen Codes nachgetragen werden.

Dieses "nur" kann aber recht aufwendig werden, insbesondere bei den 
Indexregister-Befehlen (DD/FD-Prefixe). Ich wünsche Dir und uns viel 
Erfolg. Kennst Du diese Seite hier?
http://z80.info/decoding.htm
Da könnten ein paar nützliche Hinweise drin sein.

> habe mal in der To_Tabelle die Befehle mit (Z80) markiert. Dabei viel
> mir auch auf, dass der OpCode D9 falsch interpretiert wurde. Laut 8080
> sollte das RET sein, ausgeführt wurde NOP und im Z80 ist es EXX. Ich
> habe es korrigiert (siehe Anhang).

Dir Korrektur ist richtig (Danke), aber die Beschreibung nicht ganz. D9 
ist bei 8080 ein undefinierter Opcode (RET ist C9). Meines Wissens hat 
der 8080 im Gegensatz zu den meisten anderen Prozessoren auch keine 
nennenswerten undokomentierten Befehle an solchen Stellen. Der Fehler 
dürfte sich daher in keinem Programm bemerkbar machen.


Joe G. schrieb:
> Bist dur dir sicher, dass Multiplan unter dem 8080 läuft?

Ganz sicher. Damit habe ich Mitte der 80er die Telefonabrechnung für 
unser Stockwerk im Studentenwohnheim gemacht (10 Apartments und ein 
Telefon mit Einheitenzähler auf dem Flur).

Nächstes Jahr werde ich mir den Fehler mal anschauen.

> Möglicherweise
> ist die unterschiedliche Parity-Flag Behandlung die Ursache. Setze doch
> mal EM_Z80 auf 1, dann werden die Z80 Flags ausgeführt.

Ich kann mir nicht vorstellen, daß es ein Programm gibt, daß mit dem 
8080-Befehlssatz auskommt, die Flags aber wie beim Z80 interpretiert.

Peter Sieg schrieb:
> Was das Projekt wirklich voran bringen könnte wäre Z80 Emulation und
> dann die darauf aufbauenden Diskimages mit Turbo Pascal etc. etc.

Turbo Pascal wäre sicher nett, aber wichtiger finde ich, das das 
bestehende Minimalsystem zu verbessern, so das es richtig rund läuft.
Dazu stehen auf meiner ToDo-Liste noch:

- Notwendige und nützliche Tools auf PC als Paket zusammenstellen 
("Entwicklungsumgebung") und insbesondere dokumentieren. Möglichst 
einheitlich für Linux und Windows.

- SD-Kartentreiber verbessern.

- Break erkennen.

Mit dem ersten Punkt hatte ich vor einigen Monaten schon mal 
angefangen...

> Was auch schön wäre, eine altairz80 Emu, der direkt die Diskimages für
> dieses Projekt verarbeiten kann..

Zu altairz80 habe ich da
Beitrag "Re: CP/M auf ATmega88"
schon was geschrieben.

Leo C. schrieb:
> Kennst Du diese Seite hier?

Die und die anderen Links auf der Seite sind eine Goldgrube!

Leo C. schrieb:
> bei 8080 ein undefinierter Opcode

Stimmt, ich hatte diese Quelle genutzt und das "Sternchen" vor RET 
übersehen.
http://www.pastraiser.com/cpu/i8080/i8080_opcodes.html

Leo C. schrieb:
> Dieses "nur" kann aber recht aufwendig werden, insbesondere bei den
> Indexregister-Befehlen

Vielleicht hilft ja noch einer ;-)

Joe G. schrieb:
> http://www.pastraiser.com/cpu/i8080/i8080_opcodes.html

Gute Tabelle. Die *-Befehle dürften durch unvollständige Decodierung 
zusatande kommen.

(Z80-Emu)
> Vielleicht hilft ja noch einer ;-)

Bestimmt, schließlich rufen hier so viele nach Z80-Unterstützung. ;-)
Ich gehöre vorläufig nicht dazu, weil meine Freizeit bis auf Weiteres 
fast vollständig in dieses Projekt geht:
http://openpetition.de/petition/online/stuttgarter-erklaerung-zur-fortfuehrung-des-widerstandes-gegen-stuttgart-21
(Übrigens kann uns jeder dort durch Unterzeichnung unterstützen, aber 
weil das hier Offtopic ist, Rückfragen bitte nur per PM)

Allen einen Guten Rutsch
Leo

Hallo Retro-Freak Kollegen, :-)

wünsche allen hier gut ins neue Jahr 2012 gekommen zu sein!

Dies ist mein erster Beitrag in diesem Thread (habe bisher nur 
mitgelesen).
Von Peter habe ich vor ein paar Tagen zwei Platinen erstanden, sind 
gestern auch angekommen, Danke Peter!

Nun muss ich noch die nötigen Bauteile besorgen und das Ganze 
aufbauen...
...und dann gehts erst richtig los! :-)

Ich würde Euch gerne bei diesem spannenden Projekt unterstützen!

Was ich beitragen kann:

Aus dem Bereich Software(-Entwicklung):
- Etwas angestaubte Kenntnisse in 8080/8085 Assembler von früher...
- Kenntnisse auch in anderen Assembler Dialekten (6502/68000er) wer weiß 
wofür es mal gut ist... :-)
- Kenntnisse in C / C++
- Allgemeine Kenntnisse im Bereich Softwareentwicklung (z.B. diverse 
IDE's, etc.)

Aus dem Bereich Hardware:
- Allgemeine Elektronik-Kenntnisse (bin ausgebildeter 
Kommunikationselektroniker)
- Kenntnisse im Bereich Mikroprozessor-/Mikrocontroller-Technik
- Messtechnik im eigenen Elektronik-Labor: 2 x Oszilloskop (analog u. 
digital), 34 Kanal-Logikanalyser, STK500 Entwicklungsboard, etc.

Ich möchte zu meinem Einstieg auch gleich einen Vorschlag machen:

Mir ist beim Lesen aller (ja es sind über 1000!) Beiträge aufgefallen, 
dass es viele wertvolle Hinweise / Links in diesem Threat gibt, welche 
aber nur teilweise in der Projektseite: 
http://www.mikrocontroller.net/articles/AVR_CP/M aufgeführt sind!

Zum Beispiel aktuell dieser: http://z80.info/decoding.htm

Ich würde als erstes die Links alle heraussuchen und auf der 
Projektseite im Breich "Siehe auch" einfügen.

Des weiteren würde ich vorschlagen, auf der Projektseite auch einen 
Punkt "ToDo" einzuführen um dort anstehende Themen wie z.B.: Erweiterung 
um Z80 Emulation aufzuführen evtl. mit Hinweis wer an welchem Punkt 
bereits arbeitet!

Was haltet Ihr davon?


Viele Grüße

Markus

@Markus

Willkommen bei den Retroinfizierten!
Wie du schon mitbekommen hast, lebt so ein Projekt vom Enthusiasmus der 
Beteiligten. Somit ist jede Mitarbeit willkommen. Sei es bei der 
Dokumentation der Hardware oder der Software. Dein Vorschlag, die 
Projektseite zu aktualisieren ist gut. Eine Linksammlung fehlte 
tatsächlich noch darauf. Auch eine ToDo-Sammlung ist eine gutes 
demokratisches Mittel „wirkliche“ Bedürfnisse zu erfassen sowie den 
aktuellen Stand zu dokumentieren.
Darf ich dir gleich einen konkreten Vorschlag unterbreiten? Da eine 
Aufbaudokumentation noch fehlt, ist es aus meiner Sicht ganz nützlich so 
was in Angriff zu nehmen. Wenn du bei deinem Aufbau die Aufbauschritte 
und auch die dabei auftretenden Hürden dokumentierst hätten wir gleich 
einen Anfang. Also einfach kurz alles notieren was bei der Hard- und 
Software schief gehen kann.
Gruß Joe

Hallo Joe,
hallo Peter,

Danke für die herzliche Begrüßung!

Die Schlacht hat bereits gegonnen :-), seht hier:

http://www.mikrocontroller.net/articles/AVR_CP/M#Siehe_auch

Als nächstes werde ich dort noch jede Menge weitere Links einfügen, 
welche ich aus diesem Threat extrahiert habe!

Dann folgt der Todo Abschnitt, da dürft Ihr Euch dann verausgaben... ;-)

Und wenn ich, voraussichtlich nächste Woche, alle Bauteile zusammen 
habe, baue ich einen CP/M Stick auf und notiere mir dabei was mir dabei 
auffällt (wie von Joe vorgeschlagen)!


Viele Grüße

Markus

Hallo zusammen,

so, ich habe meine Drohung, die Linksammlung zu vervollständigen und 
eine ToDo-Liste einzufügen, nun war gemacht! :-)

Das Ergebnis seht Ihr hier:

http://www.mikrocontroller.net/articles/AVR_CP/M#ToDo_Liste

Sollte etwas fehlen, nicht gefallen, etc. bitte einfach (selbst) 
editieren!


Viele Grüße

Markus

Markus G. schrieb:
> Die Schlacht hat bereits gegonnen :-), seht hier:

Dank Markus und dem Verweis auf das Total Commander Plugin für CP/M habe 
ich das AVR CP/M Format in die diskdefs des TC eingetragen. Nun kann man 
mit dem TC unter Windows wunderbar unsere Images bearbeiten!

Peter Sieg schrieb:
> Braucht der nicht trotzdem die cpmtools im Hintergrund..?
> Schön wäre 1 Installer/ZIP zum entpacken, wo alles gleich fertig drin
> ist..

Man benötigt nur das cpmwfx Plugin für TC und die diskdefs (siehe oben).
Dann wird das Immage gemappt und kann bearbeitet werden. Das geht sogar 
schneller und einfacher als bei ZIP. Ein Installer wird somit 
überflüssig da sich das Immage wie ein Unterverzeichnis in Win verhält. 
Probier es mal, du wirst begeistert sein.

Arg?!"§§$$%

1. Also TC (Shareware) installiert.
2. cpm wfx plugin von hier geladen als zip: 
http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2
3. TC gestartet und Zip aus 2 geöffnet. Findet plugin und frag ob es 
inst. werden soll. Ja.
4. diskdefs in TC install Pfad\plugins\wfx\cpmimg kopiert und vorhandene 
überschrieben.
5. TC neu gestartet. Doppelklick auf CPMDSK_A.IMG --.. kann nicht 
geöffnet werden..

Super tolle Anleitung und super tolles selbsterklärendes Tool!
Außerdem sind im cpmimg Verzeichnis doch wieder cpmls, cpmcp, cpmrm.exe 
etc. drin..

Peter

EDIT:
6. Anleitung unter 2 weiter lesen... !!
7. CPM Image datei mit F5 Kopieren an cpmwfx 'senden'..
8. Datei im rechten Fenster dann markieren mit der Maus und im Menu 
unter Dateien-Eigenschaften unten im Format-Eingabefenster 'avrcpm' 
eingeben..

Hurra!

ok, wer es braucht.. Ich denke man könnte avrcpm noch als Default Format 
einstellen..? Spart zumindest Schritt 8.

Ich bleibe dann doch lieber bei den CMD Tools.. denn für ein erzeugen 
eines CP/M Diskimage braucht man das trotzdem..

Peter

Hallo zusammen,

ich habe eine Anmerkung zum Thema SD-Kartenleser (SCDA...) - 
Platinenlayout des CP/M-Stick:

GPS'ler schrieb:
> Hallo @Joe,
>
> vorneweg, ich habe noch nie eine Leiterplatte mit Eagle entworfen und
> dadurch keinerlei Erfahrung in dieser Richtung!
>
> ....aber kann es sein, dass die SD-Karte Spiegelverkehrt ist und würde
> nur passen, wenn das auf der Unterseite wäre. Ich habe mehrere
> SD-Kartenhalter und wollte testen ob diese in etwa passen. Aber leider
> nein. Dabei ist mir aufgefallen,dass die SCDA... falsch angeschlossen
> sein müßte.Im Manual von denen steht "Viewed from the mounting face
> side". Ich habe dein Layout ausgedruckt und ne SD Karte draufgelegt. CS
> ist der  erste  bzw. 2. Pin nach der Abschrägung....
>
> Eventuell liege ich voll daneben.....deshalb prüfen....
>
> MfG
> Achim
>
> Ps: Eventuell kannst du die Pads nach recht verlängern (Falls das bei
> euererKarte nicht stört) , dann würde es auch für meine passen...
> Anbei die LIB

Ich habe heute das oben von GPS'ler (Achim) angesprochene Problem mit 
dem vermeintlich spiegelverkehrten Layout des SD-Kartenhalters selbst 
nachvollzogen:

Ich habe mir für den Aufbau des CP/M-Sticks über ebay folgende 
SD-Kartenhalter gekauft:

http://www.ebay.de/itm/15x-ALPS-SCDA-SD-MEMORY-CARD-READER-BUCHSE-/290644435363?pt=Kartenleseger%C3%A4te&hash=item43abc221a3

Dabei habe ich folgendes festgestellt:

1. Der Pinabstand passt nicht genau zum Layout.
2. Dieser Kartenhalter ist NICHT für "Reverse mount" sondern für 
"Standard mount" gedacht (s. Anhang scda.pdf).
3. Er ist also für unser Projekt NICHT geeignet!!!
4. Für einen korrekten Aufbau ist zwingend der SD-Kartenhalter vom Typ: 
ALPS (Hersteller) SCDA5A0201 erforderlich!

Ob es baugleiche SD-Kartenhalter von anderen Herstellern gibt ist mir 
nicht bekannt!

Und nun die Master-Frage: Hat jemand von Euch noch einen, besser wären 
zwei, SD-Kartenhalter des richtigen Typs zum Verkauf für mich?


Gruß

Markus

Markus G. schrieb:
> Für einen korrekten Aufbau ist zwingend der SD-Kartenhalter vom Typ:
> ALPS (Hersteller) SCDA5A0201 erforderlich!

Ich habe sie immer hier bezogen:
http://www.csd-electronics.de/
Best.Nr.: 020115
Stückpreis: 2,95€

Peter Sieg schrieb:
> Ich denke man könnte avrcpm noch als Default Format
> einstellen..? Spart zumindest Schritt 8.

getan (siehe Anhang)

Peter Sieg schrieb:
> Ich bleibe dann doch lieber bei den CMD Tools.. denn für ein erzeugen
> eines CP/M Diskimage braucht man das trotzdem..

Du brauchst doch nur einmal ein leeres Image erstellen. Dann kopierst du 
mit TC alle Dinge die du benötigst in das Imageverzeichnis. Das 
komplette Image wird automatisch angepasst.

@Markus: Bezugsquelle SD Slot wurde ja schon genannt. Der SCDA6A.. 
sollte auch passen (ALPS). Ansonsten ging es 2009 darum einen günstigen 
SD Slot mit GUTER Qualität UND Eagle LBR zu finden.. das war das 
Ergebnis..

Peter

@Joe:
Danke für die Bezugsquelle, dort werde ich nun auch Kunde! :-)

@Peter:
Danke für die Alternative und Hintergrundinfos!


Gruß

Markus

Da ich mich mit CP/M bis her nur sehr oberflächlich befasst habe,
kann man eigentlich auch mit 64 Zeichen/Zeiile "sinnvolle" Dinge damit 
anstellen oder müssen es unbedingt 80 Zeichen sein?

Gruß Jörg

80x24 sollte das Terminal wenigstens bieten, ansonsten sind die 
Möglichkeiten schon arg eingeschränkt.

Hallo zusammen,

so nun ist es soweit:

Auch ich besitze nun einen funktionierenden AVR CP/M-Stick! Juhu

Da ich zwischenzeitlich auch einige Tests mit diversen DRAM-Bausteinen 
und ein paar SD-Karten durchgeführt habe, habe ich dies nun auch auf der 
Projektseite im Abschnitt Hardware im Anschluss an die Hardwarevariante 
3 dokumentiert:

http://www.mikrocontroller.net/wikisoftware/index.php?title=AVR_CP/M&section=2#Hardware

An dieser Stelle auch gleich die Bitte, diesen Abschnitt, um die von 
Euch erfolgreich eingesetzten DRAM's und SD-Karten, zu erweitern!


Viele Grüße

Markus

Markus G. schrieb:
> Auch ich besitze nun einen funktionierenden AVR CP/M-Stick!

Herzlichen Glückwunsch!

Joe G. schrieb:
> Markus G. schrieb:
>> Auch ich besitze nun einen funktionierenden AVR CP/M-Stick!
>
> Herzlichen Glückwunsch!

Hallo Joe,

Danke für den Glückwunsch! :-)

Bis zur endgültigen Funktion hatte ich aber auch ein paar spannende 
Begegnungen der Dritten Art, welche ich hier kurz aufzeigen möchte damit 
andere Retro-Fans nicht in die gleichen Fallen tappen:

1. Ich hatte mich anfangs von der 4bit DRAM Architektur (256k x 4Bit) 
irritieren lassen und in der Datei: config.inc

1

#define DRAM_8BIT 0

eingetragen, was zu Zeichensalat auf dem Terminal führte!
Korrekt ist:

1

#define DRAM_8BIT 1   /* 1 = 8bit wide DRAM */

2. Ich habe es geschafft mir genau zwei defekte DRAM's aus meinem Fundus 
auszusuchen und den AVR CP/M-Stick damit zu bestücken! (Murphys Gesetz 
Teil 1) :-(

Das wäre an sich noch gar kein so großes Problem gewesen, wenn nicht 
auch noch die vorhandene Speichertest-Routine aktiviert durch:

1

.equ MEMTEST = 1

 in der Datei: config.inc im Fehlerfall einfach weiterlaufen würde!!! 
(Murphys Gesetz Teil 2) :-(

Dies kann dann z.B. so aussehen:

CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
FE<FF@FFFE
Initing mmc...
A:FAT16 File-Image at: 026, size: 256KB.
B:FAT16 File-Image at: 010, size: 256KB.
C:FAT16 File-Image at: 018, size: 256KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2

PC=202B
 Z P    A =80 BC =0034 DE =0080 HL =F580 SP =2000 PC =202B       C3 00 
F2

Wie weit die Einschaltmeldungen noch ausgegeben werden, ist unter 
anderem auch davon abhängig ob und welche Debug Ausgaben aktiviert sind!

Ergo: Defekte DRAM's führen zu blöden, bösen und ggf. schwer zu 
findenden Fehlern!!!

Aber nun zum angenehmen Teil, der Lösung:

Nachdem ich mich dann irgendwann dazu entschieden hatte ein neues Paar 
DRAM's einzusetzen sah es gleich viel besser aus!

Und um das Ganze nicht vielleicht noch einmal erleben zu müssen habe ich 
mich anschließend entschlossen die Speichertest-Routine etwas zu 
modifizieren.
Die von mir überarbeitete Testroutine hält beim ersten Speicher-Fehler 
das System an und fordert zum Tausch des/der DRAM-Chips auf!
Diese Routine kann über die Anweisung:

1

.equ MEMTEST = 2

 (oder höher) in der Datei: config.inc aktiviert werden!

Das Ganze sieht dann im Fehlerfall z.B. so aus:

CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
RAM test failure:
00<01@0100
System halted, replace RAM chip(s)!


Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag 
angehangen.
Um die geänderte Speichertest-Routine zu verwenden sind also nur zwei 
kleine Schritte nötig:

1. Austausch der vorhandenen Datei init.asm im Projektverzeichnis durch 
die im Anhang befindliche Datei init.asm.
2. Aktivieren der neuen Routine durch die Anweisung:

1

.equ MEMTEST = 2

 (oder höher) in der Datei: config.inc

Auch die alte Speichertest-Routine kann weiterhin verwendet werden, 
hierzu ist wie bisher die Anweisung:

1

.equ MEMTEST = 1

 in der Datei: config.inc zu setzen!


Viele Grüße

Markus

Markus G. schrieb:
> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
> angehangen.

Danke.
Verbesserungen und Korrekturen (insbesondere) mit Patch sind sehr sehr 
gern gesehen.

Wenn niemand was dagegen hat, werde ich die Änderung übernehmen.

Peter Sieg schrieb:
> Wer sollte was dagegen haben.. ;-)
>
> Gruß Peter

Ich bestimmt nicht!
Und dann war der Fehler und das Debugging wenigstens lohnenswert... :-)


Viele Grüße

Markus

Markus G. schrieb:
> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
> angehangen.

Super,läuft!

Wenn du Lust hast auch am Z80 Code zu arbeiten....

Die "JR Dinge" habe ich schon eingepflegt, sind aber noch nicht 
vollständig getestet. CB, ED und FD sind noch offen (viel Fleißarbeit).

Gruß Joe

Joe G. schrieb:
> Markus G. schrieb:
>> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
>> angehangen.
>
> Super,läuft!
>
> Wenn du Lust hast auch am Z80 Code zu arbeiten....
>
> Die "JR Dinge" habe ich schon eingepflegt, sind aber noch nicht
> vollständig getestet. CB, ED und FD sind noch offen (viel Fleißarbeit).
>
> Gruß Joe

Hallo Joe,

Danke, freut mich! :-)

Ja, ich habe Lust auch bei der Z80 Emulation zu unterstützen.
Ich habe mir schon mal das z80int.asm Modul angesehen, kann es aber noch 
nicht komplett überblicken.
Mir sind dabei vermeintlich ein paar Z80 spezifische Dinge aufgefallen 
welche ich hier kurz aufzeigen möchte:

1. Wir müssen folgende Opcodes noch implementieren / testen:

1

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 08         EX AF,AF'  (Z80)

2

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 10 oo      DJNZ o    (Z80)

3

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 18 oo  JR o    (Z80)

4

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 20 oo  JR NZ,o    (Z80)

5

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 28 oo  JR Z,o    (Z80)

6

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 30 oo  JR NC,o    (Z80)

7

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 38 oo  JR C,o    (Z80)

8

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; CB     (Z80 specific)

9

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; D9    EXX    (Z80)

10

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; DD     (Z80)

11

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; ED    (Z80 specific)

12

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; FD     (Z80 specific)

Dahinter verbergen sich 456(!) einzelne Opcodes, soviel zum Thema 
Fleißarbeit... :-)


2. Unter den Z80 spezifischen Opcodes gibt es auch einige welche 4 Bytes 
lang sind.
Diese befinden sich alle in den Bereichen der DD, ED und FD Opcodes!
Wie wirkt sich dies auf die Opcode-Decoder-Routinen aus? Grübl

Ich habe die von mir angefertigte Tabelle (im xls und ods Format) diesem 
Beitrag angehangen.

Diese Webseite diente mir als Quelle:
http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.txt


Viele Grüße

Markus

Markus G. schrieb:
> Ja, ich habe Lust auch bei der Z80 Emulation zu unterstützen.

Der aktuelle Interpreter ist 8080int-jmp.asm
Für die 4 Byte Opcodes habe ich auch noch keinen Plan. Vielleicht fällt 
Leo C. was dazu ein ;-).

Gut ist auch immer ein Blick auf das Projekt von Jörg Wolfram
http://www.jcwolfram.de/projekte/avr/ax81/main.php
Dort hat er schon einen Z80 Interpreter für AVR implementiert. Er kann 
nicht 1:1 übernommen werden aber der Blick auf einzelne Befehle ist 
äußerst hilfreich (Danke Jörg!).

Wenn du mir deine PM senden köntest, dann würde ich dir meinen 
Arbeitsstand von 8080int-jmp.asm zukommen lassen.

Gruß Joe

Joe G. schrieb:
> Markus G. schrieb:
>> Ja, ich habe Lust auch bei der Z80 Emulation zu unterstützen.
>
> Der aktuelle Interpreter ist 8080int-jmp.asm
> Für die 4 Byte Opcodes habe ich auch noch keinen Plan. Vielleicht fällt
> Leo C. was dazu ein ;-).
>
> Gut ist auch immer ein Blick auf das Projekt von Jörg Wolfram
> http://www.jcwolfram.de/projekte/avr/ax81/main.php
> Dort hat er schon einen Z80 Interpreter für AVR implementiert. Er kann
> nicht 1:1 übernommen werden aber der Blick auf einzelne Befehle ist
> äußerst hilfreich (Danke Jörg!).
>
> Wenn du mir deine PM senden köntest, dann würde ich dir meinen
> Arbeitsstand von 8080int-jmp.asm zukommen lassen.
>
> Gruß Joe

Hallo Joe,

okay, dann übernehme ich gerne Deinen Arbeitsstand.
Du hast soeben eine PM von mir bekommen mit meiner privaten 
Emailadresse! :-)

Das Projekt von Jörg ist mir auch bekannt, war auch gerade wieder auf 
der Seite und habe mir die Sourcen der V0.26 gezogen und kurz einen 
Blick in den Z80-Emu geworfen!
Was mir dort auf den ersten Blick gut gefallen hat ist die Unterteilung 
der "Opcode Familien" in einzelne Module (Include Dateien).
Ich finde dies macht das Ganze zumindest etwas übersichtlicher...


Viele Grüße

Markus

Hallo zusammen,

ich habe meine, im Beitrag #2541628 veröffentlichte, 
Speichertest-Routine nun noch einmal verfeinert:

Durch den Eintrag:

1

.equ MEMTEST = 3

(oder höher) in der Datei: config.inc

ist es nun möglich im Falle eines Speicherfehlers auf einem AVR 
CP/M-Stick V3.0 den/die defekten DRAM-Chips (IC5 / IC6) anzeigen zu 
lassen!

Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
angehangen.

Um die geänderte Speichertest-Routine zu verwenden sind also nur zwei
kleine Schritte nötig:

1. Austausch der vorhandenen Datei init.asm im Projektverzeichnis durch
die im Anhang befindliche Datei init.asm.

2. Aktivieren der neuen Routine durch die Anweisung:

.equ MEMTEST = 3

 (oder höher) in der Datei: config.inc

Auch die alten Speichertest-Routinen können weiterhin verwendet werden,
hierzu ist wie bisher die Anweisung:

.equ MEMTEST = 1 oder 2

in der Datei: config.inc zu setzen!

Siehe auch folgenden Auszug aus der Datei init.asm:

1

;------------------------------------------------------------------------------------  

2

;  Info about MEMTEST:

3

;  0 = no memtest at all

4

;  1 = memtest shows defects but carrys on

5

;  2 = memtest shows defect and stops on first failure

6

;  3 = memtest shows defect, stops on first failure and

7

;      shows which RAM chip has to be replaced

8

;      on an AVR CP/M-Stick V3.0

9

;------------------------------------------------------------------------------------

Viele Grüße

Markus


PS: @Leo: Du darfst auch die neue Version gerne (wieder) ins SVN 
einchecken!

Peter Sieg schrieb:
> Gerade festgestellt das:
> SIEMENS HYB514256B-70
> wovon ich noch 9 Stk. habe NICHT laufen!
>
> Kennt jemand noch eine Quelle von 4256 Drams?
>
> Peter

Hallo Peter,

ich kenne leider auch keine verlässliche Quelle für weitere passende 
DRAM's außer ab und zu ebay. :-(

Nachtrag: Gerade gefunden, könnte evtl. noch eine Quelle sein:
http://www.arcadecomponents.com/memory.html

Versand ist auch nach Deutschland möglich!


Aber was mich in diesem Zusammenhang noch interessieren würde:

Mit welcher uC Taktfrequenz hast Du die SIEMENS HYB514256B-70 DRAM's 
getestet?

Ich hatte ursprünglich drei IC's davon (über ebay gekauft - also ohne 
Gewähr auf Funktion).
Bei meinen Tests mit 20 MHz uC Takt, stellten sich dann 2 von 3 IC's als 
reproduzierbar defekt heraus...

Einer davon läuft aber einwandfrei bei 20 MHz Takt, höhere Frequenzen 
habe ich mangels Quarze bisher nicht getestet!


Gruß

Markus

Zu den RAMs:
"DRAM_WAITSTATES" in der config.inc hochsetzen wäre vielleicht einen 
Versuch wert.

Peter Sieg schrieb:
> Hmm Ja.. sind mit 30MHz getaktet.. ;-)
> Das ist dann natürlich grenzwertig und das auch noch bei nur 3,3V..
>
> Gruß Peter

Hallo Peter,

ja 30 MHz ist schon verdammt viel.
Ich habe soeben auch noch einmal Tests mit meinen zwei vermeintlich 
defekten SIEMENS HYB514256B-70 IC's durchgeführt:

Einmal mit 2 bzw. 3 Waitstates, wie von Leo vorgeschlagen, bei 20 MHz uC 
Takt und dann noch mit 1 bzw. 2 Waitstates bei 8 MHz uC internen Takt.
Aber es hilft alles nichts, diese beiden IC's sind definitiv defekt!

Vielleicht solltest Du Deinen DRAM's auch mal nur 8 MHz uC internen Takt 
gönnen, dann sollte aber wirklich nichts fehlen, ausser sie sind 
wirklich defekt!


Viele Grüße

Markus

Peter Sieg schrieb:
> @Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan
> schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein
> Wurm drin sein..?

Jetzt habe ich es mal mit der Version 1.06 von hier
http://www.schorn.ch/cpm/intro.php
ausprobiert. Da taucht der Fehler auch auf. Da der Fehler im simh mit 
8080-Emulation nicht vorkommt, muß es wohl an unserer CPU-Emulation 
liegen.

Ich tippe auf den DAA-Befehl, da Multiplan wahrscheinlich mit BCD-Zahlen 
rechnet. Vielleicht hat ja zufällig jemand CBASIC von Digital Research 
parat, das auch in obiger Quelle zu finden ist, und das auch mit BCD 
rechnet, und kann meine Vermutung bestätigen.

Peter Sieg schrieb:
> @Leo C.: Habe leider nur MS Basic hier..

Deshalb habe ich extra eine Quelle angegeben. ;-)

Peter Sieg schrieb:
> @alle: Wie ist denn der Stand bei der Implementierung der Z80
> Unterstützung?
> @Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan
> schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein
> Wurm drin sein..?
>
> Ach Ja.. Platinen sind nun alle.. wenn noch wer hier Bedarf hat.. müßte
> ich dann nachbestellen und das müssen immer mind. 10 Stück sein..
>
> Peter

Hallo zusammen,

ich habe zwischenzeitlich von Joe seinen aktuellen Arbeitsstand der 
Datei: 8080int-jmp.asm für den Z80 Emulator bekommen, Danke Joe!

Bin aber leider noch nicht wirklich dazu gekommen mich dort etwas 
einzuarbeiten. :-(


Viele Grüße

Markus

Leo C. schrieb:
> Peter Sieg schrieb:
>> @Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan
>> schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein
>> Wurm drin sein..?
>
> Jetzt habe ich es mal mit der Version 1.06 von hier
> http://www.schorn.ch/cpm/intro.php
> ausprobiert. Da taucht der Fehler auch auf. Da der Fehler im simh mit
> 8080-Emulation nicht vorkommt, muß es wohl an unserer CPU-Emulation
> liegen.
>
> Ich tippe auf den DAA-Befehl, da Multiplan wahrscheinlich mit BCD-Zahlen
> rechnet. Vielleicht hat ja zufällig jemand CBASIC von Digital Research
> parat, das auch in obiger Quelle zu finden ist, und das auch mit BCD
> rechnet, und kann meine Vermutung bestätigen.

Hallo zusammen,

ich nehme mich des "Multiplan Fehlers" an!
@Leo C.: Danke für die Quelle zum CBASIC und den Hinweis auf den DAA 
Befehl, mal sehen was ich herausbekomme.

Diese Bausstelle bringt dann auch gleich mein Verständnis über den 
Prozessablauf des 8080 Befehlsinterpreters voran.
Dies hilft mir anschließend für die Arbeit am Z80 Interpreter...

Alles ein Frage der richtigen Kombination(en)... ;-)


Viele Grüße

Markus

Markus G. schrieb:
> ich nehme mich des "Multiplan Fehlers" an!

Bin inzwischen einen Schritt weiter:
Bei den Arithmetikbefehlen wird das H-Flag (half carry) nicht gesetzt.

Ich habe auch mal einen Patch angefangen (Anhang), aber z.Zt. habe ich 
nicht mal einen Assembler auf meinem Rechner installiert.
Bis ich testen kann, dauert also etwas.

Meine Entwicklungsumgebung geht wieder.
Der DAA-Code ist total buggy. 2 Fehler habe ich gefunden und dem 
nächsten bin ich auf der Spur. (Wer hat nur so einen Mist programmiert? 
;)

Peter Sieg schrieb:
> @Leo C / Markus: Prima!
>
> Ich kann etwas mehr zu Rams sagen:
> SIEMENS HYB514256B-70 gehen bei mir definitiv nicht bei 3,3V, 20MHz und
> 3 Waitstates. Mehr als 8 Stück getestet - alle liegen nicht.
>
> Aber:
> V53C104P laufen nun bei 3,3V, 20MHz und 3 Waitstates!
> Diese liefen damals unter 30/25MHz, 3,3V und 1 Waitstates NICHT.
>
> Peter

Hallo Peter,

Deine RAM's verwirren mich... :-)

Drei Fragen dazu:

1. Was machen denn die SIEMENS HYB514256B-70 bei 8 MHz internem uC Takt?

2. Bleibt jeder RAM-Chip für sich gesehen bei jedem RAM-Test an der 
selben Adresse stehen?
Zum Beispiel:

1. Chip immer an der Adresse 0100 (HEX):
2. Chip immer an der Adresse 0080 (HEX):
3. Chip immer an der Adresse 02CE (HEX):
etc...

Siehe auch meinen Beitrag #2545923.

3. Welche Zugriffszeit haben Deine V53C104P RAM's?


Viele Grüße

Markus

Leo C. schrieb:
> Markus G. schrieb:
>> ich nehme mich des "Multiplan Fehlers" an!
>
> Bin inzwischen einen Schritt weiter:
> Bei den Arithmetikbefehlen wird das H-Flag (half carry) nicht gesetzt.
>
> Ich habe auch mal einen Patch angefangen (Anhang), aber z.Zt. habe ich
> nicht mal einen Assembler auf meinem Rechner installiert.
> Bis ich testen kann, dauert also etwas.

Hallo Leo,

ich sehe Du bist voll in Deinem Element... ;-)
Ich habe mir Deine neue 8080int-jmp.asm geladen, assembliert und damit 
Multiplan 1.06 geteset:

Ich kann Dir sagen, noch ist der Bug da! :-)
Er tritt z.B. bei Additionen mit einem Ergebnis größer gleich 30 auf, 29 
+ 1 = 130 und 29 + 2 = 131 :-)
Es gibt auch nette Subtraktionen: 1 - 8 = -1, 100 - 1 = 109 und 100 - 8 
= 102 :-)

Falls es wieder eine neue Version zum Testen gibt, nur her damit... :-)


Viele Grüße

Markus

Markus G. schrieb:

> Ich kann Dir sagen, noch ist der Bug da! :-)

Ja, der DAA-Code ist (bzw. war) ein einziger großer Bug. :)

Hast Du auch das hier gelesen?
Beitrag "Re: CP/M auf ATmega88"

> Falls es wieder eine neue Version zum Testen gibt, nur her damit... :-)

Ich mache DAA gerade komplett neu. Im Moment gibts besonders lustige 
Ergebnisse (Anhang). Aber vielleicht wirds heute noch fertig.

So, für Multiplan reichts jetzt.
Ob die Emulation allerdings ganz korrekt ist, weiß ich nicht.
Außerdem fehlt noch der Fall, wenn das N-Flag gesetzt ist. Das sollte 
aber für alle korrekten 8080-Programme ausreichen.

Im Anhang ist noch ein Multiplan Testprogramm.

Leider habe ich keine Quellen gefunden, die den DAA Befehl vollständig 
beschreiben. Für 8080 findet man noch weniger, als für den Z80.
Auf der Suche habe ich aber noch folgende interessante Dokumente 
gefunden:

http://anyplatform.net/cpus.html
(weiter unten 8080/Z80 Series)

Weitere habe ich schon wieder verloren...

Hallo Draco,

danke für den Hinweis. Zaks ist schon eine der besten Referenzen für Z80 
überhaupt, aber leider fehlt auch bei ihm der Zustand des Half-Carry 
nach dem DAA-Befehl. Inzwischen habe ich aber noch ein gutes Dokument 
(wieder-) gefunden:

"The Undocumented Z80 Documented"
http://www.myquest.nl/z80undocumented/
(auch auf http://www.z80.info) zu finden)

Leo C. schrieb:
> So, für Multiplan reichts jetzt.
> Ob die Emulation allerdings ganz korrekt ist, weiß ich nicht.
> Außerdem fehlt noch der Fall, wenn das N-Flag gesetzt ist. Das sollte
> aber für alle korrekten 8080-Programme ausreichen.
>
> Im Anhang ist noch ein Multiplan Testprogramm.
>
> Leider habe ich keine Quellen gefunden, die den DAA Befehl vollständig
> beschreiben. Für 8080 findet man noch weniger, als für den Z80.
> Auf der Suche habe ich aber noch folgende interessante Dokumente
> gefunden:
>
> http://anyplatform.net/cpus.html
> (weiter unten 8080/Z80 Series)
>
> Weitere habe ich schon wieder verloren...

Hallo Leo,

super! Danke!

Ich habe noch ein interesantes "Original-Dokument" gefunden.
Über den folgenden Link kann man sich das "Intel 8080 Microcomputer 
System's Users Manual" ansehen:

http://www.scribd.com/doc/19954501/Intel-8080-Manual-1

Auf der Seite 29 von 40 ist der DAA Befehl beschrieben, die betroffenen 
Flags (Fußnote 10) sind auf der Seite 33 von 40 beschrieben:

"If the value of the least significant 4-bits of the accumulator is 
greater than 9 or if the auxiliary carry bit is set, 6 is added to the 
accumulator. If the value of the most significant 4-bits of the 
accumulator is now greater than 9 or if the carry bit is set, 6 is added 
to the most significant 4-bits of the accumulator."


Viele Grüße

Markus

Hallo zusammen,

der DAA des 8080 ist einfach, da er nur Additionen korrigiert. Der Wert 
des H-Flags nach der DAA-Operation ergibt sich aus der Oder-Verknüpfung 
des vorherigen Wertes von H und aus der Bedingung Lower Nibble > 9. Also 
H=H or (Akku and 0x0f)>9.
Seien a,b Element aus [0..9], s=a+b. Wenn s>9, dann hat ein Überlauf von 
der Einerstelle auf die Zehnerstelle stattgefunden, also muss H gesetzt 
werden. Jetzt ist es aber so, dass wir nicht 10, sondern 16 als Basis 
für eine Stelle haben (Aufspaltung des Bytes in 2 Nibbles), daher wird 
für s aus [16..18] das H-Flag automatisch gesetzt. Für s aus [10..15] 
gibt es keinen Überlauf im 16er-System, aber im 10er-System, daher muss 
das H-Flag über die Bedingung lower nibble>9 gesetzt werden.
Die gleiche Überlegung trifft auch auf das C-Flag und das Higher Nibble 
zu, aber man muss hier schon den Überlauf aus der Einerstelle mit 
einbeziehen. Das ergibt dann C=C or (Akku>0x99).
Und der Korrekturwert ergibt sich aus den Werten der beiden Flags nach 
den beiden oben genannten Oder-Verknüpfungen:
Wenn H=1, dann wird 0x06 zum Akku addiert.
Wenn C=1, dann wird 0x60 zum Akku addiert.
Und wenn beide Flags gesetzt sind, dann ist der Korrekturwert 0x66.
Entsprechende Überlegungen muss man bei der Korrektur für Subtraktionen 
beim Z80 machen.

Vielen Dank für die weiteren Hinweise zum DAA-Befehl.
Wie die Flags gesetzt werden müssen, ist auch in den 8080 Datenbüchern,
die ich auch auf meiner Festplatte gefunden habe, beschrieben.

Im Anhang ist mein aktueller Stand für den Interpreter.
DAA ist nur für den 8080 drin. Ich habe nochmal die Behandlung der Flags 
bei allen relevanten
Befehlen anhand der angehängten Tabelle überprüft, und einige kleine 
Fehler korrigiert.

Insbesondere INC und DEC sind dadurch leider größer und langsamer 
geworden.

Zum Ausgleich habe ich die Opcode-Tabellen nochmal etwas komprimiert. 
Dies brachte
Platzeinsparungen und Geschwindigkeitssteigerungen um unteren 
Promillebereich. Insbesondere der
der NOP-Befehl konnte deutlich beschleunigt werden. :-)

Die anderen Interpretervarianten habe ich teilweise nachgezogen. Es 
stellt sich aber die Frage,  ob diese überhaupt noch von Interesse sind 
(evtl. wg. ROM-Größe). Wenn ja, würde ich aber als nächstes Die Dateien 
umstrukturieren, so daß die Action-Routinen (fetch/op/store)
nur einmal vorhenden sind.

Als Übung, oder für Leute mit Zeit/Langeweile, hätte ich jetzt folgende 
Vorschläge:

1. Testen, testen, testen...

2. Überprüfung, ob die Flags überall richtig behandelt werden.
   (kann natürlich mit 1. verbunden werden (DDT))

3. INC/DEC sehen so aus, als könnten sie verbessert werden.
   Da die Befehle häufig vorkommen, würde sich das lohnen. Auch Peters
   Bench-Schleife ist jetzt langsamer geworden.

Mit welchen SD-Karten gibt es denn noch Probleme?
Vielleicht kann man im Treiber ja noch was verbessern.

Im Anhang ist ein Photo von allen Karten, die bei mir laufen. Auf der 
Micro-SD ist kein Hersteller zu finden. Vielleicht möchte ja jemand die 
Projektseite damit ergänzen. Die Hardware ist bei mir auf Lochraster 
gestrickt (8-Bit RAM).

Karten, die nicht funktionieren, habe ich bei mir keine.

Leo C. schrieb:
> Mit welchen SD-Karten gibt es denn noch Probleme?
> Vielleicht kann man im Treiber ja noch was verbessern.
>
> Im Anhang ist ein Photo von allen Karten, die bei mir laufen. Auf der
> Micro-SD ist kein Hersteller zu finden. Vielleicht möchte ja jemand die
> Projektseite damit ergänzen. Die Hardware ist bei mir auf Lochraster
> gestrickt (8-Bit RAM).
>
> Karten, die nicht funktionieren, habe ich bei mir keine.

Hallo Leo,

ich habe die noch fehlenden SD-Karten (mit Hersteller) von Dir auf der 
Projektseite ergänzt.

Welchen Systemtakt hat Dein Lochraster-Aufbau?
Ich frage weil ich auf der Projektseite den Systemtakt (bei mir 20 MHz) 
mit angegeben habe.
Ggf. würde ich dann noch einen eigenen Abschnitt für Deine Karten 
einfügen.


Viele Grüße

Markus

Falls es noch interessiert und ich habe nicht alles hier gelesen!
"Der Z80 ist beim DAA Befehl inkompatibel zum 8080." Leider ist das 
alles ne lange Zeit her. Es kann daher sein, ich erzähle nicht alles 
ganz richtig. Alles was ich definitiv weiß:
1. Es gab einen Unterschied im Standard-Befehlssatz von 8080, 8085, Z80 
, der auch dokumentiert war.
2. Das wurde ausgenutzt um den Prozessor automatisch zu erkennen.
3. Dieser Unterschied war dort dokumentiert als unwesentlich, weil er in 
normalen Programmen nicht vorkommt.

Vielleicht hilft das euch ja.

Ehemaliger Z80-Bastler -
Abdul

Zum DAA Befehl beim Z80 scheint es auch im Netz widersprüchliche 
Dokumentationen zu geben, insbesondere was das Flag-Handling anbetrifft. 
Gestern musste ich auch feststellen, dass meine Implemntierung beim AX81 
nicht zu 100% korrekt ist. Aufgefallen ist es mir aber erst beim 
Spectrum-ROM als da in den Zahlen plötzlich vereinzelt Sonderzeichen 
aufgetreten sind. Beim ZX81 schein der Fehler dagegen nicht zu stören.

Gruß Jörg

Markus G. schrieb:
> Welchen Systemtakt hat Dein Lochraster-Aufbau?
> Ich frage weil ich auf der Projektseite den Systemtakt (bei mir 20 MHz)
> mit angegeben habe.

Auch 20 MHz.

Hier gibts Bilder:
Beitrag "Re: CP/M auf ATmega88"

Joerg Wolfram schrieb:
> Zum DAA Befehl beim Z80 scheint es auch im Netz widersprüchliche
> Dokumentationen zu geben, insbesondere was das Flag-Handling anbetrifft.

Vielleicht hilft Dir das hier:
http://anyplatform.net/media/guides/cpus/8080%20&%20Z80%20Processor%20Data.txt

In der Doku fehlt häufig der Zustand des H-Flags nach dem DAA-Befehl.

@Abdul: "Ehemalig" muß ja nicht für immer sein...

Leo C. schrieb:
> Markus G. schrieb:
>> Welchen Systemtakt hat Dein Lochraster-Aufbau?
>> Ich frage weil ich auf der Projektseite den Systemtakt (bei mir 20 MHz)
>> mit angegeben habe.
>
> Auch 20 MHz.
>
> Hier gibts Bilder:
> Beitrag "Re: CP/M auf ATmega88"

Hallo Leo,

Danke für die Info!


Gruß

Markus

Leo C. schrieb:
> Joerg Wolfram schrieb:
>> Zum DAA Befehl beim Z80 scheint es auch im Netz widersprüchliche
>> Dokumentationen zu geben, insbesondere was das Flag-Handling anbetrifft.
>
> Vielleicht hilft Dir das hier:
> http://anyplatform.net/media/guides/cpus/8080%20&%20Z80%20Processor%20Data.txt
>
> In der Doku fehlt häufig der Zustand des H-Flags nach dem DAA-Befehl.
>
> @Abdul: "Ehemalig" muß ja nicht für immer sein...


Hallo Leo,

Danke für den Link, ich habe ihn gleich in unsere Projektseite mit 
aufgenommen!

@Abdul: "Ehemalig" geht ja gleich gar nicht... ;-)


Gruß

Markus

Ich habe mir mal ein paar Gedanken zum Z80 Interpreter gemacht, und
angefangen, die Tabellenmakros entsprechend zu erweitern.
Folgendermaßen könnte es klappen:

Für jeden Prefix wird eine neue Tabelle angelegt. Für DD und FD könnte 
man eine gemeinsame Tabelle verwenden, und beim Einstieg ein Flag 
entsprechend setzen.
Wir brauchen dann 4 zusätzliche Tabellen: ED, DD/FD, CB, und CBDD/FD.
Da jede Tabelle 512 Byte belegt, und für die meisten Befehle nochmal 
Zwischensprungtabellen dazu kommen, könnte es für den ATmega168 knapp 
werden.


Für jeden Prefix gibts eine neue OP-Aktion:

1

do_op_prefixED:

2

  mem_read_ds zl,z_pc      ;zl = memReadByte(z_pc)

3

  adiw  z_pcl,1            ;++z_pc

4

  ldi  zh,high(EDjmp)      ;

5

  ijmp

6

7

8

do_op_prefixDD:

9

;TODO: Flag für DD setzen

10

11

  mem_read_ds zl,z_pc      ;zl = memReadByte(z_pc)

12

  adiw  z_pcl,1            ;++z_pc

13

  ldi  zh,high(DDFDjmp)    ;

14

  ijmp

15

16

do_op_prefixFD:

17

;TODO: Flag für FD setzen

18

19

  mem_read_ds zl,z_pc      ;zl = memReadByte(z_pc)

20

  adiw  z_pcl,1            ;++z_pc

21

  ldi  zh,high(DDFDjmp)    ;

22

  ijmp

Die Tabellen bekommen einen Namen über ein Makro zugeordnet. Zuerst die 
schon bestehende Tabelle:

1

  opctable opcjmp

2

3

.

4

.

5

instr   fetch_nop,  op_prefixED,store_nop  ;ED    ;(ED opcode prefix)

6

.

7

.

Danach die neuen Tabellen. z.B.:

1

  opctable EDjmp

2

3

instr   fetch_nop,  op_nop,    store_nop  ;00    ;NOP

4

.

5

.

6

instr   fetch_C,    op_IN,     store_B    ;40    ;IN B,(C)

7

instr   fetch_B,    op_OUT,    store_nop  ;41    ;OUT (C),B

8

instr   fetch_BC,   op_SBCHL,  store_nop  ;42    ;SBC HL,BC

9

instr   fetch_DIR16,op_STBC,   store_nop  ;43    ;LD (nn),BC

10

instr   fetch_nop,  op_NEG,    store_nop  ;44    ;NEG

11

.

12

.

Fetch/Op/Store-Aktionen müssen definiert sein, bevor sie in den Tabellen
referenziert werden können. Damit die Sprünge möglichst kurz werden, 
sollten sie
unmittelbar vor der Tabelle, in der sie das erste mal angesprochen 
werden,
platziert werden.

Im Anhang ist ein ausbaufähiges Gerüst nach diesem Schema. Ich kann die 
Datei ohne Fehler assemblieren, und einen Befehl aus der ED-Tabelle habe 
ich erfolgreich getestet.

Leo C. schrieb:
> Für DD und FD könnte
> man eine gemeinsame Tabelle verwenden

Wenn mich meine Erinnerung nicht trügt, sind beim Z80 das DD und das FD 
nur Präfixe, die dafür sorgen, dass der nachfolgende Befehl auf das IX- 
bzw. IY-Register wirk, statt auf das HL-Register. Daraus folgen einige 
undokumentierte Befehle, da alles, was mit HL geht auch mit IX und IY 
geht, nur ein bisschen langsamer und ein Byte mehr an Code.

Hallo Konrad,

so ist es.
Wenn man allerdings bei jedem Befehl mit H, L oder HL prüft, ob vorher 
ein DD- oder FD-Prefix war, dürfte das doch zu viel Geschwindigkeit 
kosten. Aber man kann es natürlich ausprobieren, vor allem, wenn der 
Platz nicht reicht.

Besonders hilfreich finde ich übrigens "The Undocumented Z80 
Documented":
http://www.myquest.nl/z80undocumented/

Nicht nur wegen der undokumentierten Befehle.

Brauchen wir wirklich für die DD/FD-Behandlung eigene, vollständige 
Sprungtabellen? Ich denke, dass geht besser, wenn man erweiterte 
fetch_XX und store_XX-Routinen benutzt. Also zusätzlich zu fetch_HL auch 
noch fetch_HLIXIY, welches ein Flag beachtet, dass durch die Präfix 
DD/FD gesetzt wird und nach jeder Ausführung wieder zurückgesetzt wird.
Wenn wir z.B. INC HL betrachten, dann ist das fetch_HL, op_INC16 und 
store_HL für den i8080. Für Z80 wird daraus folgendes: fetch_HLIXIY, 
op_INC16, store_HLIXIY. Bei LD H,(HL) müssen wird daraus dann daraus 
fetch_MHLIXIY, op_nop, store_H machen. INC L wäre dann fetch_LXLYL, 
op_INC, store_LXLYL für das undokumentierte Feature auf die einzelnen 
Bytes der Indexregister zugreifen zu können.
Die Bitbefehle sind leider etwas komplizierter, da hier durch Vorsetzen 
von DD aus SET 7,A ein SET 7,(IX+d),A wird, also auf jeden Fall der 
Speicher über IX+d angesprochen wird.
Durch die Einführung von fetch_HLIXIY dauert die Verarbeitung von 
Befehlen mit HL länger als die mit BC oder DE. Auch muss man bei der 
Behandlung des Displacement-Bytes bei fetch_MHLIXIY und store_MHLIXIY 
aufpassen, dass sie einzeln aber auch paarweise vorkommen können [Siehe 
INC (IX+d); LD (IX+d),A und LD A,(IX+d)].

Markus G. schrieb:
>
> Ich habe die von mir angefertigte Tabelle (im xls und ods Format) diesem
> Beitrag angehangen.
>
> Diese Webseite diente mir als Quelle:
> http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.txt
>
>
> Viele Grüße
>
> Markus

Hallo zusammen,

ich habe in den von mir im Beitrag #2542248 erstellten Tabellen drei 
versehentlich doppelt vorhandene Z80 Codes (CB01, DD22 und ED6B) 
gefunden und korrigiert.

Im Anhang die neuen Tabellen.


Viele Grüße

Markus

Hallo zusammen,

zum Thema Sprungtabellen und zusätzlicher Speicherbedarf:

Wie wäre es, wenn wir, um keine Geschwindigkeitsverluste zu haben und 
nicht von vorne herein zu viel Speicher zu verbrauchen, erst einmal nur 
alle "offiziellen" Befehlskombinationen implementieren würden?

Wenn wir anschließend wissen wie es mit dem Speicherbedarf (bezogen auf 
ATMega 168) aussieht, könnten wir dann ggf. die Befehls-Tabellen 
komplett (inkl. illegaler Opcodes) implementieren oder uns mit der 
Variante von Bernd B. (mainhattan) weiter beschäftigen?!


Just my 2 cents... :-)


Viele Grüße

Markus

Ich finde die Variante von Leo C. ganz gut. An Speicherplatz sollte es 
nicht mangeln. Der ATMega168 kann ja leicht durch den ATMega328 ersetzt 
werden.

Bernd B. schrieb:
> Brauchen wir wirklich für die DD/FD-Behandlung eigene, vollständige
> Sprungtabellen?

Dazu habe meine Meinung schon eins höher in der Antwort an Konrad 
geschrieben.

Markus G. schrieb:
> Wie wäre es, wenn wir, um keine Geschwindigkeitsverluste zu haben und
> nicht von vorne herein zu viel Speicher zu verbrauchen, erst einmal nur
> alle "offiziellen" Befehlskombinationen implementieren würden?

Natürlich sollte man (solltest Du :)) die dokumentierten Befehle zuerst 
implementieren. Ich glaube aber, daß die undokumentierten wenig 
zusätzlichen Platz belegen. Der Platz für die Sprungtabelle wird sowiso 
benötigt, und der Rest wird meistens aus bereits vorhanden Teilen 
zusammen gebaut.

Allgemein:
Ich habe einen (rudimentär getesteten) Vorschlag geliefert, wie man die 
bestehende Tabelle für die Z80-Mehrbyteopcodes erweitern kann, weil es 
dazu eine Anfrage gab 
(Beitrag "Re: CP/M auf ATmega88").


Im Anhang ist noch mal Update.

Die ED-Tabelle ist jetzt fast vollständig. Die ED-Befehle sind aber noch 
nicht alle voll funktionsfähig (Bitte die "TODO:"-Stellen suchen).

Die anderen Tabellen (DDFD, CB und DDFDCB) sind bisher nur Platzhalter. 
Ich glaube, daß der Code dazu in 16K unterzubringen ist. Im Moment sind 
noch über 3,5 KByte frei.

Hallo Horst,

ich habe mir erlaubt, Deine Tabelle etwas umzuformatieren. Kannst Du sie 
in dieser Form noch gebrauchen?
Wenn ja, die ED-Tabelle habe ich ergänzt. Es fehlen noch die 
Block-Befehle.

RAM-Test in init.asm

Markus G. hat Recht. Es macht keinen Sinn, das System bei einem 
RAM-Fehler weiter laufen zu lassen.

Aber
Markus G. schrieb:
> Durch den Eintrag:
> .equ MEMTEST = 3
>
> (oder höher) in der Datei: config.inc
>
> ist es nun möglich im Falle eines Speicherfehlers auf einem AVR
> CP/M-Stick V3.0 den/die defekten DRAM-Chips (IC5 / IC6) anzeigen zu
> lassen!

Dieses halte ich aber doch für etwas zu spezialisiert. Nicht jeder hat 
einen CP/M-Stick V3.0.

Was haltet Ihr denn von folgender Lösung (Anhang)?

1

CPM on an AVR, v2.1

2

Testing RAM: fill...wait...reread...

3

04<00@0000

4

05<01@0001

5

06<02@0002

6

07<03@0003

7

0C<08@0008

8

0D<09@0009

9

0E<0A@000A

10

0F<0B@000B

11

14<10@0010

12

15<11@0011

13

16<12@0012

14

17<13@0013

15

1C<18@0018

16

1D<19@0019

17

1E<1A@001A

18

1F<1B@001B System halted!

Die ersten 16 Fehler (knapper Bildschirm voll) werden ausgegeben und 
dann gestoppt. An den Mustern kann man u.U. erkennen, welche(s) Bit(s) 
defekt ist/sind.

Das Ausgabeformat könnte man noch verbessern. Man könnte auch 
zusätzliche Spalten ausgeben, mit 1-Bits, die 0 sein sollen und 0-Bits, 
die 1 sein sollen. Aber das halte ich auch wieder für übertrieben.

Markus G. schrieb:
> Hallo zusammen,
>
> ich habe meine, im Beitrag #2541628 veröffentlichte,
> Speichertest-Routine nun noch einmal verfeinert:
>
> Durch den Eintrag:
>
>

1

> .equ MEMTEST = 3

2

>

>
> (oder höher) in der Datei: config.inc
>
> ist es nun möglich im Falle eines Speicherfehlers auf einem AVR
> CP/M-Stick V3.0 den/die defekten DRAM-Chips (IC5 / IC6) anzeigen zu
> lassen!
>
> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
> angehangen.
>
> Um die geänderte Speichertest-Routine zu verwenden sind also nur zwei
> kleine Schritte nötig:
>
> 1. Austausch der vorhandenen Datei init.asm im Projektverzeichnis durch
> die im Anhang befindliche Datei init.asm.
>
> 2. Aktivieren der neuen Routine durch die Anweisung:
>
> .equ MEMTEST = 3
>
>  (oder höher) in der Datei: config.inc
>
> Auch die alten Speichertest-Routinen können weiterhin verwendet werden,
> hierzu ist wie bisher die Anweisung:
>
> .equ MEMTEST = 1 oder 2
>
> in der Datei: config.inc zu setzen!
>
> Siehe auch folgenden Auszug aus der Datei init.asm:
>
>

1

> ;------------------------------------------------------------------------------------

2

> ;  Info about MEMTEST:

3

> ;  0 = no memtest at all

4

> ;  1 = memtest shows defects but carrys on

5

> ;  2 = memtest shows defect and stops on first failure

6

> ;  3 = memtest shows defect, stops on first failure and

7

> ;      shows which RAM chip has to be replaced

8

> ;      on an AVR CP/M-Stick V3.0

9

> ;------------------------------------------------------------------------------------

10

>

>
> Viele Grüße
>
> Markus
>
>
> PS: @Leo: Du darfst auch die neue Version gerne (wieder) ins SVN
> einchecken!

Hallo zusammen,

ja, ich verstehe Leo's Eiwand, dass meine Ramtest Variante 3 nur für den 
CPM-Stick V3.0 zu gebrauchen ist, das ist absolut richtig!
Genau aus diesem Grund habe ich auch die von mir zuvor implementierte 
Variante 2 (MEMTEST = 2) im Code belassen.
Diese ist allgemein gültig, da sie den / die defekten Ram-Chips nicht 
durch eine IC-Nummer / Position bestimmt und somit für jede 
Aufbauvariante (Lochraster, ältere Platinenversion, etc.) verwendet 
werden kann.
Die Ergänzung der Ausgabe um die Bitmuster haltet ich auch für sinnvoll 
- Lötspritzer lassen grüßen... ;-)

Mein Vorschlag wäre also die Variante 2 um die Ausgabe der Bitmuster zu 
ergänzen.


Viele Grüße

Markus

Peter Sieg schrieb:
> Wichtig wäre eine einfache Meldung Ram1 Und/Oder Ram2 defekt und gut ist

Ist Ram1 jetzt der obere oder der untere Chip?

Markus G. schrieb:
>> ;  Info about MEMTEST:
>> ;  0 = no memtest at all
>> ;  1 = memtest shows defects but carrys on
>> ;  2 = memtest shows defect and stops on first failure
>> ;  3 = memtest shows defect, stops on first failure and
>> ;      shows which RAM chip has to be replaced
>> ;      on an AVR CP/M-Stick V3.0

Variante 1 hat sich offensichtlich nicht bewährt, da RAM-Fehler zu 
leicht übersehen werden können.

Wenn wir Variante 3 in den allgemeinen Code aufnehmen, werden wir über 
kurz oder lang auch Schalterstellungen für die anderen Hardwarevarianten 
aufnehmen müssen.

Und mein Hauptpunkt: Ich befürchte ganz einfach, daß diejenigen, die 
nicht in Lage sind, die Bitmuster zu interpretieren, auch die größten 
Schwierigkeiten haben werden, das Programm selbst mit der richtigen 
Schalterstellung zu übersetzen.

Im Anhang ist mein aktuelles Verhandlungsangebot :-)
Die Ausgabe könnte dann ungefähr so aussehen:

1

CPM on an AVR, v2.1

2

Testing RAM: fill...wait...reread...

3

Addr xx yy

4

0000 00 04 -------- -----X--

5

0001 01 05 -------- -----X--

6

0002 02 06 -------- -----X--

7

0003 03 07 -------- -----X--

8

0008 08 04 ----X--- -----X--

9

0009 09 05 ----X--- -----X--

10

000A 0A 06 ----X--- -----X--

11

000B 0B 07 ----X--- -----X--

12

000C 0C 04 ----X--- --------

13

000D 0D 05 ----X--- --------

14

000E 0E 06 ----X--- --------

15

000F 0F 07 ----X--- --------

16

0010 10 14 -------- -----X--

17

0011 11 15 -------- -----X--

18

0012 12 16 -------- -----X--

19

0013 13 17 -------- -----X-- System halted!

Verbesserungen am Format, eine ordentliche Überschriftenzeile, und die 
Erklärung, was das ganze überhaupt soll, überlasse ich gerne dem Leser. 
:-)

Im Anhang ist ein Vorschlag für BREAK-Erkennung und Verarbeitung.

Z. Zt. wird BREAK nur bei einem Character timeout erkannt. Ein BREAK, 
daß nur wenig länger als ein normales Zeichen dauert. funktioniert noch 
nicht.

BREAK setzt ein Flag in einem Interpreter-Register, in das auch die 
Flags für Interrupts (und vielleicht Trace, Einzelschritt...) kommen 
sollen.
Z. Zt. setzt BREAK den PC auf null. --> Warmstart.
Denkbar wären auch Kaltstart, Interrupt/NMI, Sprung in Debugger...
Vielleicht brauchen wir für so was noch ein schönes API.

Ich würde mich freuen, wenn viele Leute das mal mit vielen verschiedenen 
Terminals/-Emulatoren testen würden. Bei mir funktionierts mit minicom 
und Windows Hyperterminal, wobei ich für letzteres Google bemühen mußte, 
um die Break-Taste zu finden (ctrl-break, bzw. Strg-Untbr).
Möglicherweise gibt es Terminals, die nur ein kurzes BREAK-Signal 
senden. Mit denen funktionierts dann (noch) nicht, und das wären dann 
gute Testkanditaten für die Vervollständigung des Codes.


Nils Eilers schrieb:
> Was anderes: ich habe gesehen, wird ein BREAK auf der seriellen
> Schnittstelle derzeit noch nicht behandelt. Das ADM-3A hat eine extra
> Break-Taste und Terminalprogramme bieten üblicherweise die Funktion, ein
> Break zu senden. Das würde die Möglichkeit eröffnen, bei Empfang eines
> Breaks einen Kalt- oder Warmstart auszuführen, oder einen Debugger
> aufzurufen.

Update

ddtz macht intensiv Gebrauch von Z80-Befehlen und kommt jetzt schon 
ziemlich weit. Er läuft aber noch nicht wirklich, weil noch eine Menge 
Befehle fehlen.
Z. Bsp. CB, und DD/FDCB komplett und in der ED-Tabelle fehlen bis auf 
LDDR noch alle Blocktransfer- und Suchbefehle. Ausserdem sind die 
implementierten Befehle kaum getestet.

Trace kann jetzt zur Laufzeit durch Schreiben auf einen Port ein- und 
ausgschaltet werden. Praktisch zum Testen der neuen Befehle:

1

-l100,11a

2

  0100  MVI  A,01

3

  0102  OUT  4F

4

  0104  LXI  B,77FF

5

  0107  PUSH B

6

  0108  POP  PSW  

7

  0109  LXI  B,1234

8

  010C  LXI  D,5678

9

  010F  LXI  H,9ABC

10

  0112  ??=  08

11

  0113  ??=  D9

12

  0114  ??=  08

13

  0115  ??=  D9

14

  0116  MVI  A,00

15

  0118  OUT  4F

16

  011A  NOP  

17

  011B  

18

-g100,11a

19

20

    N   A =01 BC =0000 DE =0000 HL =0000 SP=0100 PC=0104       01 FF 77 

21

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

22

    N   A =01 BC =77FF DE =0000 HL =0000 SP=0100 PC=0107       C5 F1 01 

23

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

24

    N   A =01 BC =77FF DE =0000 HL =0000 SP=00FE PC=0108       F1 01 34 

25

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

26

SZHVNC  A =77 BC =77FF DE =0000 HL =0000 SP=0100 PC=0109       01 34 12 

27

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

28

SZHVNC  A =77 BC =1234 DE =0000 HL =0000 SP=0100 PC=010C       11 78 56 

29

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

30

SZHVNC  A =77 BC =1234 DE =5678 HL =0000 SP=0100 PC=010F       21 BC 9A 

31

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

32

SZHVNC  A =77 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0112       08 D9 08 

33

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

34

        A =00 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0113       D9 08 D9 

35

SZHVNC  A'=77 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

36

        A =00 BC =0000 DE =0000 HL =0000 SP=0100 PC=0114       08 D9 3E 

37

SZHVNC  A'=77 BC'=1234 DE'=5678 HL'=9ABC IX=0000 IY=0000 I=00       

38

SZHVNC  A =77 BC =0000 DE =0000 HL =0000 SP=0100 PC=0115       D9 3E 00 

39

        A'=00 BC'=1234 DE'=5678 HL'=9ABC IX=0000 IY=0000 I=00       

40

SZHVNC  A =77 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0116       3E 00 D3 

41

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       

42

SZHVNC  A =00 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0118       D3 4F F7 

43

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       *011A

44

-

Da z. Zt. einiges in Bewegung ist, habe ich den alten Stand (8080 only, 
korrigierter DAA, alter RAM-Test, kein BREAK) als Version 2.2 
eingefroren:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/2.2/

Die aktuelle Version ist wie üblich im trunk-Zweig.

Peter Sieg schrieb:
> Gibts für ddtz eigentlich ein Manual?

Im angehängten Zip ist sogar eins auf Deutsch drin.
(Ich weiß grad nicht mehr wo ich das her hab, deshalb kann ich keinen 
Link posten.)

Sorry, das war kein Manual, sondern "nur" eine Art Referenz. Im Netz 
findet man aber viele Versionen von ddtz mit englischen und deutschen 
Beschreibungen.

'tp3-hd.dsk' in 'CPMDSK_x.IMG' umbenennen.

Glückwunsch!
Ich bin sprachlos.

Man müßte doch auch ein Handbuch im Netz finden.
(Ich habe hier noch eine Kopie der gedruckten Fassung)

Aber Du wirst es sicher auch so noch finden. Sooo viele Punkte hat das 
Hauptmenü ja auch nicht.

Im Z80-Interpreter dürften aber noch ein paar Fehler versteckt sein.

Der Turbo-Editor spinnt, und MC.PAS kann zwar als COM übersetzt werden,
aber mit dem Demosheet verrechnet es sich, wenn man andere/größere 
Zahlen eingibt.

Letzte Nacht habe ich mal den Exerciser laufen lassen.
Heute Morgen sah das dann so aus:

1

C>exz80doc

2

Z80 instruction exerciser

3

Undefined status bits NOT taken into account

4

<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles   OK

5

add hl,<bc,de,hl,sp>..........( 35,840) cycles   OK

6

add ix,<bc,de,ix,sp>..........( 35,840) cycles   OK

7

add iy,<bc,de,iy,sp>..........( 35,840) cycles   OK

8

aluop a,nn....................( 45,056) cycles   OK

9

aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles   OK

10

aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles   ERROR **** crc expected:a4026d5a found:e7318427

11

aluop a,(<ix,iy>+1)...........(229,376) cycles   ERROR **** crc expected:e849676e found:74a1545f

12

aluop a,(<ix,iy>-1)...........(229,376) cycles   ERROR **** crc expected:edd8136d found:7130205c

13

bit n,(<ix,iy>+1).............(  2,048) cycles   OK

14

bit n,(<ix,iy>-1).............(  2,048) cycles   OK

15

bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles   OK

16

cpd<r>........................(  6,144) cycles   ERROR **** crc expected:c8439345 found:a8554cee

17

cpi<r>........................(  6,144) cycles   ERROR **** crc expected:e66fa7d2 found:478b76a1

18

<daa,cpl,scf,ccf>.............( 65,536) cycles 

19

   VN   A =8E BC =9079 DE =8D5B HL =A559 SP=299D PC=253B       27 00 00 

20

        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=1D60 IY=09FA I=00       Invalid opcode!

Diese Fehler sind inzwischen korrigiert. Der Abbruch mit "Invalid 
opcode! " kam beim DAA-Befehl, weil dort immer noch der Teil mit 
gesetztem N-Flag fehlt. Den Abbruch habe ich jetzt aber raus gemacht, 
damit ich sehen kann, wie weit das Testprogramm die nächste Nacht kommt.

Außerdem habe ich heute die noch fehlenden Block-I/O Befehle eingebaut.
Update im SVN.

Klasse Leo!
TP 3.0 läuft bei mir nun auch. Der Editor bockt zwar noch etwas doch mit 
dem Exerciser sollten sich alle Fehler ausmerzen lassen. Es dauert....
Meiner rechnet immer noch hier:
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles

Leo C. schrieb:
> Man müßte doch auch ein Handbuch im Netz finden.

http://electrickery.xs4all.nl/comp/tp30/

Hallo Joe,

danke fürs testen.
Versuch's mal mit der Version im Anhang. Damit scheint jetzt alles zu 
laufen.

Der Turbopascal-Editor läuft damit, und das Microcalc Demo auch.
Der Exerciser sah bei mir zu letzt so aus:

1

C>ex1

2

Z80 instruction exerciser

3

Undefined status bits NOT taken into account

4

<inc,dec> a...................(  3,072) cycles   OK

5

<inc,dec> b...................(  3,072) cycles   OK

6

<inc,dec> bc..................(  1,536) cycles   OK

7

<inc,dec> c...................(  3,072) cycles   OK

8

<inc,dec> d...................(  3,072) cycles   OK

9

<inc,dec> de..................(  1,536) cycles   OK

10

<inc,dec> e...................(  3,072) cycles   OK

11

<inc,dec> h...................(  3,072) cycles   OK

12

<inc,dec> hl..................(  1,536) cycles   OK

13

<inc,dec> ix..................(  1,536) cycles   OK

14

<inc,dec> iy..................(  1,536) cycles   OK

15

<inc,dec> l...................(  3,072) cycles   OK

16

<inc,dec> (hl)................(  3,072) cycles   OK

17

<inc,dec> sp..................(  1,536) cycles   OK

18

<inc,dec> (<ix,iy>+1).........(  6,144) cycles   OK

19

<inc,dec> (<ix,iy>-1).........(  6,144) cycles   OK

20

<inc,dec> ixh.................(  3,072) cycles   OK

21

<inc,dec> ixl.................(  3,072) cycles   OK

22

<inc,dec> iyh.................(  3,072) cycles   OK

23

<inc,dec> iyl.................(  3,072) cycles   OK

24

ld <bc,de>,(nnnn).............(     32) cycles   OK

25

ld hl,(nnnn)..................(     16) cycles   OK

26

ld sp,(nnnn)..................(     16) cycles   OK

27

ld <ix,iy>,(nnnn).............(     32) cycles   OK

28

ld (nnnn),<bc,de>.............(     64) cycles   OK

29

ld (nnnn),hl..................(     16) cycles   OK

30

ld (nnnn),sp..................(     16) cycles   OK

31

ld (nnnn),<ix,iy>.............(     64) cycles   OK

32

ld <bc,de,hl,sp>,nnnn.........(     64) cycles   OK

33

ld <ix,iy>,nnnn...............(     32) cycles   OK

34

ld a,<(bc),(de)>..............(     44) cycles   OK

35

ld <b,c,d,e,h,l,(hl),a>,nn....(     64) cycles   OK

36

ld (<ix,iy>+1),nn.............(     32) cycles   OK

37

ld (<ix,iy>-1),nn.............(     32) cycles   OK

38

ld <b,c,d,e>,(<ix,iy>+1)......(    512) cycles   OK

39

ld <b,c,d,e>,(<ix,iy>-1)......(    512) cycles   OK

40

ld <h,l>,(<ix,iy>+1)..........(    256) cycles   OK

41

ld <h,l>,(<ix,iy>-1)..........(    256) cycles   OK

42

ld a,(<ix,iy>+1)..............(    128) cycles   OK

43

ld a,(<ix,iy>-1)..............(    128) cycles   OK

44

ld <ixh,ixl,iyh,iyl>,nn.......(     32) cycles   OK

45

ld <bcdehla>,<bcdehla>........(  3,456) cycles   OK

46

ld <bcdexya>,<bcdexya>........(  6,912) cycles   OK

47

ld a,(nnnn) / ld (nnnn),a.....(     44) cycles   OK

48

ldd<r> (1)....................(     44) cycles   OK

49

ldd<r> (2)....................(     44) cycles   OK

50

ldi<r> (1)....................(     44) cycles   OK

51

ldi<r> (2)....................(     44) cycles   OK

52

neg...........................( 16,384) cycles   OK

53

<rrd,rld>.....................(  7,168) cycles   OK

54

<rlca,rrca,rla,rra>...........(  6,144) cycles   OK

55

shf/rot (<ix,iy>+1)...........(    416) cycles   OK

56

shf/rot (<ix,iy>-1)...........(    416) cycles   OK

57

shf/rot <b,c,d,e,h,l,(hl),a>..(  6,784) cycles   OK

58

<set,res> n,<bcdehl(hl)a>.....(  6,912) cycles   OK

59

<set,res> n,(<ix,iy>+1).......(    448) cycles   OK

60

<set,res> n,(<ix,iy>-1).......(    448) cycles   OK

61

ld (<ix,iy>+1),<b,c,d,e>......(  1,024) cycles   OK

62

ld (<ix,iy>-1),<b,c,d,e>......(  1,024) cycles   OK

63

ld (<ix,iy>+1),<h,l>..........(    256) cycles   OK

64

ld (<ix,iy>-1),<h,l>..........(    256) cycles   OK

65

ld (<ix,iy>+1),a..............(     64) cycles   OK

66

ld (<ix,iy>-1),a..............(     64) cycles   OK

67

ld (<bc,de>),a................(     96) cycles   OK

68

All tests successful.

Ich habe die Source neu übersetzt und dabei alle Tests die schon positiv 
durchgelaufen sind, sowie DAA (bekannter Fehler) und die Block-I/O 
Befehle auskommentiert.

Prima, der Editor läuft nun auch!

Wenn du Lust hast dieses Stück zu übernehmen...

instr   do_fetch_DIR8,  op_DJNZ,  do_store_nop  ;10 nn      ;DJNZ nn 
(Z80 OK)

;----------------------------------------------------------------
;|Mnemonic  |SZHPNC|Description          |Notes                 |
;|----------+------+---------------------+----------------------|
;|DJNZ e    |------|Dec., Jump Non-Zero  |B=B-1 till B=0        |
;
;The b register is decremented, and if not zero, the signed value e is 
added to pc.
;The jump is measured from the start of the instruction opcode.
;e = Relative addressing (PC=PC+2+offset)
do_op_DJNZ:  ; decremt B, jump B=0
  lds temp, z_b    ; B in temp
  dec temp      ; temp decrementieren
  breq do_op_DJNZ_Z  ; bei B=0
  sts z_b, temp    ; temp in B
  subi opl, 0x80    ; z_pc + e im Zweierkomplement
  subi z_pcl, 0x80
  sbc z_pch, _0
  add z_pcl, opl
  adc z_pch, _0
do_op_DJNZ_Z:
  ret

Joe G. schrieb:
> Wenn du Lust hast dieses Stück zu übernehmen...

Nur wenn Du den Fehler behältst. ;-)

Die trickreiche Displacement-Berechnung braucht einen Takt (und ein 
Register) weniger. Super!
Die Abkürzung ("Gehe nicht über store_...") bringt aber mehr.

Es gibt noch merkwürdige Fehler. Wenn TP über Q verlassen wird z.B. das 
hier:

Logged drive: A
Work file:
Main file:

Edit     Compile  Run   Save
eXecute  Dir      Quit  compiler Options

Text:     0 bytes (8118-8118)
Free: 24301 bytes (8119-E006)

>

S   NC  A =09 BC =0606 DE =DF28 HL =DC00 SP=E3A9 PC=DC01       76 DF C3
 Z  N   A'=AF BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       CPU 
halted!

oder wenn das compillierte Programm als COM ausgeführt wird:

A>dir
A: TEST     PAS : TINST    COM : TINST    DTA : TINST    MSG
A: TURBO    COM : TURBO    MSG : TURBO    OVR : TEST     BAK
A: TEST     COM
A>test
Das ist ein AVR CP/M Test

A: TEST     PASA: T   COM A: TINST    MSGA: /0123456 789A: TINST 
DTAA: TURBO    COMA: TURBO    COMA: TEST     BAKA: TEST     BAK
I/O error 00, PC=3A50
Program aborted

A>

Das gilt übrigens auch für Zork1. Beim beenden stürzt es ab.

Damit der TP Editor über VT100 etwas bedienbarer wird, habe ich einige 
"übliche" Steuerkommandos eingefügt, wer Lust hat kann ja noch 
erweitern.

@ Leo C.

Kommando zurück! Ich hatte deine letzte Version mit der SVN Version 
gemischt. Nun geht es korrekt.

Hallo Joe,

Die angehängte geht noch einen Tick besser. Bis auf DAA werden damit 
alle Tests von EXZ80DOC bestanden.

Hallo Leo,

super läuft. Ich lasse gerade EXZ80DOC laufen und gehe erst mal was 
essen...

Hier die Befehle für den TP Editor.

Da der Z80-Interpreter nun komplett ist, und gut läuft, habe ich mir 
erlaubt, die Versionsnummer auf 3.0 zu erhöhen. Diese Version ist auch 
wieder dauerhaft im tags-Verzeichnis abgelegt:

http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.0/

- Z80 ist jetzt der Defaultprozessor. Das Programm belegt damit z.Zt.
  aber mehr als 16 KB Flash. --> Atmega328 erforderlich.

- Für 8080 kann übersetzt werden, wenn "EM_Z80" in config.inc auf 0
  gesetzt wird.

- Trace kann jetzt (auch) zur Laufzeit ein- und ausgeschaltet werden.
  Einschalten: 1 auf Port 0x4F ausgeben.
  Ausschalten: 0 auf Port 0x4F ausgeben.
  (ddtz: "O 1 4f")

- Um Trace von der CP/M-Befehlszeile aus zu schalten, wurde das
  Timer-Steuerprogramm (im Verzeichnis cpm/utils) erweitert.
  (Der Name TIMER.COM passt nicht mehr, Vorschläge?)

- BREAK: Ein laufendes Programm kann jederzeit durch senden von BREAK
  abgebrochen werden. Zur Zeit wird dann ein Warmstart ausgeführt,
  was natürlich nicht hilft, wenn BDOS und/oder BIOS durch ein
  amoklaufendes Programm überschrieben wurden.

Bitte gründlich testen. Kommentare, Änderungs- und 
Verbesserungsvorschläge wie immer...

Schönes Wochenende

Perfekt!

Trace läuft...
Break läuft...

TIMER.COM darf auch ACT.COM heißen. (AVR CP/M Tool) ;-)

Peter Sieg schrieb:
> Und dachte mir so, das wäre doch mal eine Herausforderung @Joe?

Das Projekt liegt schon in der Schublade. Als RAM habe ich 16 Stück 
HM51W17805J-6 rumliegen (16M EDO DRAM 3.3V). Es würde nur ein IC 
benötigt werden da er als 2M x 8 organisiert ist. Mit dem Refresh bin 
ich mir nicht ganz sicher, sollte jedoch gehen (vielleicht schaut Leo 
auch mal aufs Datenblatt).
Es könnte dann eine CP/M 3.0 Jubiläumsversion geben ;-)

Eine Frage zur RAMDISK.

Wenn ich #define RAMDISKCNT auf 1 setze wird eine Ramdisk angelegt. I: 
z.B.
Da ja RAMSIZE nicht ausgewertet wird und in der aktuellen Stickversion 
nur 2x256Kx4 verbaut sind, wo liegt dann der Ram und wie groß ist er? 
STAT zeigt mir 1M für I: an, was ja nicht sein kann. In diesem Zustand 
werden auch alle Programme fehlerhaft beendet. Zum Glück gibt es ja nun 
Break ;-)

Ohje Ramdisk,

die habe ich außer Betrieb genommen, als ich die Erweiterung für mehrere 
Diskformate eingebaut hatte. Mit etwas Glück, könnte sie laufen, wenn 
man die Parameter in config.inc (RAMSIZE) anpasst. Bin aber nicht 
optimistisch.
Der Hauptgrund, warum ich mich nicht mehr dafür interessiert habe ist, 
daß die RAM-Zugriffe langsamer sind, als die Zugriffe auf die SD-Card.

Zum EDO-Ram: Refresh ist sicher kein Problem, und auch sonst müßte es 
genauso funktionieren, wie die normalen D-Rams. EDO ist ja nur eine 
weitere "Betriebsart".

EDO-Ram: Ich setzte mal einen Testweise auf die Stickversion.
Ramdisk: Ist nur schade wenn man 2MB verschenkt.

Mal eine ganz andere Frage in den Raum geworfen.
Ob man die Jugend begeistern kann, wenn man ein "CP/M - Shield" für 
Arduino ins Leben ruft. Das könnte in beliebigen Ausbaustufen entstehen.
Arduino Nano – Shield mit RAM und SD-Card - kleinstes CP/M System der 
Welt ;-)
Arduino Uno – CP/MLino Shield mit VGA und Tastatur
...
Joe