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?
Ich hatte bisher 2 Ramdefekte, die sich ähnlich äußerten.. FAT16 Images
erkannt. IPL bis ok.. dann Register Dump und HALT (Kein Reset!).
Man darf nicht vergessen, das wir das Ganze (zumindest die Rams)
außerhalb der Spezifikation betreiben.. da könnte das eine oder andere
Bauteil gerade an der Grenze sein..
Elko an der SD Karte bestückt? Spannung nicht unter 3,3V?
Peter
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
Habe heute mal versucht meinen 4-bit Prototypen (1x 4256 Ram), kein
Stützkondensator etc. an einem Atari ST als Terminal anzuschließen.
Dazwischen ein Max3232 3,3V TTL auf RS232 Wandler.
Der Prototyp hatte zuletzt über CP2102 TTL USB Adapter immer einwandfrei
am PC über USB funktioniert.
Baudrate auf 9600 8N1 geändert um den ST nicht zu überfordern ;-)
---
Auf einmal hatte ich ähnliche Phenomene wie du!? Reset nach Anzeige
Part. bzw. FAT16 Files und/oder illegal opcode etc. Manchmal auch erst
nach DIR Anzeige etc. = Instabiles Verhalten
???
Habe daraufhin einen 10uF Stützkondensator eingebaut. Spannung gemessen
3,7V von einem starken Steckernetzteil.
Keine wirkliche Verbesserung.
Ram getauscht - keine Besserung.
Ram getauscht auf einen Siemens HYB514256B-70 - damit scheint es nun
stabil zu gehen..??
---
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..?
Wohlgemerkt alle Rams die nun Probleme machten liefen mit CP2102 ohne
jedes Problem!
Peter
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.
100nf sind auch schon drin gewesen.. der ist bei mir immer Standard ;-)
Was auf dem Wandler drauf ist, kann ich nicht entziffern (Fertigmodul)
sieht aber sehr klein aus, so wie 0,1 - 1uf - 5 Stück davon.
Peter
Na, damit sich auch mal wieder was zum Thema AVR CPM tut, hier ein
Diskimage mit Microsoft Multiplan V 1.2.
Entzippen und nach CPMDSK_E.DSK umbenennen. (Anstatt E auch ein anderes
virtuelles Laufwerk je nach Geschmack).
Vorher 1x Install.com ausführen und bei mir auf VT52 = Nr. 23
einstellen.
Peter
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.
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.
Joe G. schrieb:> Ganz nett, vielelicht baue ich mal das Dracblade in der V5 auf. Die Z80> Emulation ist darin vollständig enthalten.>
Oder einen Hive (hive-project.de), da läuft grad wieder eine
Sammelbestellung der Boards. Wenn du dich beeilst, kannst du sicher noch
teilnehmen.
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.
@Joe: Ich sehe es (leider) auch so wie einige Vorredner.. Hardware haben
wir z.Z genug.. ich habe immer noch 5? Platinen des USB Sticks hier..
Rams auch..
Auch gefällt mir! die Kombination aus AVR+Propeller nicht.. der Prop.
kann dann schon alles alleine machen und Z80, CP/M gibts dafür auch
schon.. (sogar in Streichholzschachtelgröße)
Was das Projekt wirklich voran bringen könnte wäre Z80 Emulation und
dann die darauf aufbauenden Diskimages mit Turbo Pascal etc. etc.
Die 8080 Emu scheint aber auch noch mind. einen Bug zu haben.. siehe
Fehler im Multiplan..
Was auch schön wäre, eine altairz80 Emu, der direkt die Diskimages für
dieses Projekt verarbeiten kann..
Und weitere Diskimages die jetzt schon unter 8080 laufen..
Was ist ansonsten ggf. noch 'niedlich' finden würde wäre ein Stick in
SMD Bauweise mit Micro-SD Karte.. und Drams's die sich leicht beschaffen
lassen in SMD.. ist aber nur so ein 'Hirngespinnst'..
Z80 Emu. in ASM gibt ja nun Dank Jörg Wolfram im AX81 Projekt.. Basis
wäre also ja vorhanden..
Vielleicht sollten wir eine Bounty Prämie ausloben für eine
funktionierende Z80 Emu für dieses Projekt..?
Euch allen die besten Wünsche für 2012!
Peter
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.htmlLeo C. schrieb:> Dieses "nur" kann aber recht aufwendig werden, insbesondere bei den> Indexregister-Befehlen
Vielleicht hilft ja noch einer ;-)
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
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
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§ion=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
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:
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:
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
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
@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
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.
@Leo C.: Habe leider nur MS Basic hier..
Evtl. zeigt ja schon ein Vergleich zw. was 8080-DAA machen soll und das
was in unserer Implementierung passiert etwas auffälliges..
BTW: Das erinnert mich an einen Zeitungsartikel in dem es hieß:
... der letzte Fehler in CP/M wurde auch erst nach 7 Jahren gefunden..
;-)
Haha.. derjenige war ganz sicher Gott oder er hat keine Ahnung von
Software..
Peter
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.
@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
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.
Hallo,
Aus: Z80 Instruction Handbook (Your complete reference to the powerful
Z80 instruction set) - SCELBI Publications
DECIMAL ADJUST THE ACCUMULATOR
DAA 047oct 27hex
The decimal adjust accumulator instruction is a one byte instruction
that adjusts the contents of the accumulator to two binary coded-decimal
digits, one digit in the four least significant bits and one digit in
the four most significant bits. This instruction is used following the
addition or subtraction of two pair of BCD digits to adjust the result
to the proper BCD code. It may also be used following an increment,
decrement, or negate directive. Following an addition operation, this
instruction operates in the following manner.
The least significant half of the accumulator is checked for a BCD value
of zero to nine, and the H flag is checked for a zero condition. If both
of these conditions exist, this half is left as is.
However, if this half is greater than nine, or the H flag is one, the
accumulator will be incremented by six, thereby adjusting the least
significant half to the proper BCD code. The most significant half is
then checked for a BCD value of zero through nine and the C flag is
checked for a zero condition. If both conditions are true, the process
is complete. Otherwise, if either condition is not met, the most
significant half of the accumulator is incremented by six, with the
carry flag being set to a one if an overflow from the most significant
half occurs.
In the case of subtraction, the H and C flags are used to determine if
the value six must be subtracted from each half of the byte (which
occurs if the associated flag is set to a logic one state when the DAA
directive is encountered). The Z, S, and P/V flags are affected by these
operations (P/V reflects parity status). The N flag is not altered
Viele Grüße
Gerrit
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"
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:
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
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.
moin moin,
nach langer zeit mal wieder zeit......
1.) alle HL befehle auf eine 256byte page bringen.
2.) auf je eine page die IX und IY befehle. stratadrresse im lowbyte
identisch zu den HL befehlen.
3.) DD/FD schaltet nur das adress highbyte um. nach abarbeitung wieder
auf HL high adresse.
4.) danach normale befehlsabarbeitung.
macht 512byte für die befehle bei gutem tempo.
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:>>
>> 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
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.
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:
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
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.
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
Hi.
Habe gerade Ramblade (ZiCOG - der Welt kleinste CP/M Computer ;-) ) vor
mir liegen: PCB is 1.9"x1.2" (48x30.5mm) SMT (surface mount)
http://forums.parallax.com/showthread.php?116893-RamBlade-Prop-SRAM-microSD-addon-to-run-ZiCog-CPM-PropDos-Catalina-etc
Und dachte mir so, das wäre doch mal eine Herausforderung @Joe?
Atmega328p in SMD
MicroSD Card Slot
2x4256 Drams in SMD (sind leider sehr groß - Alternative SRam?)
Bisschen Hühnerfutter
Nur Anschluß eines CP2102 Dongles = +3.3V und TTL ser. IO
Platine von beiden Seiten bestückt (sonst wird das nichts)
Peter
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
@Joe: Die Idee das als Arduino Nano Addon zu machen gefällt mir!
Läuft allerdings mit 5V = Levelshifter zur SD Karte erforderlich.
Aber das lässt sich ja mit 3k3 und 1k8 (6 Stück) SMD Widerständen
machen.
Leider sind die Arduino nicht wirklich 'billig'.. hatte gerade was um
die 30 US$ gesehen.. aber naja.. auf dem addon wären dann nur Ram und
(Micro-) SD Karte inkl. Levelshiftern..
Peter
Joe G. schrieb:> Ob man die Jugend begeistern kann, wenn man ein "CP/M - Shield" für
...
> Arduino Uno – CP/MLino Shield mit VGA und Tastatur
Arduino kenne ich ja noch. Aber "Shield" ... mußte ich erst mal
nachschlagen.
Ja. Shield muß sein. Und Lino muß umbedingt in den Namen. Aber ob das
für CP/M. daß ja zu seinen Lebzeiten schon nicht wirklich cool war, bei
der "Jugend" reicht? Also wenn es nicht mindestens Gezwitscher blubbern
kann [1], und einen "Gefällt mir" Knopf hat, sicher nicht.
[1] http://bubblino.com/
@Leo C: Haha.. Wink mit dem Zaunpfahl..
Nein ich sehe es folgendermaßen:
Wenn wir ein 'Shield' für diese Platform anbieten haben wir:
- autom. eine fertige Platine für AVR, Quarz, Vin, ggf. USB?
- Ein 'Shield' mit Micro-SD, ggf. Levelshiftern und DRam.
Vorteile:
- AVR Teil kann man fertig kaufen, ist getestet, läßt sich woanders für
verwenden.
- Nur Zusatzplatine muss selbst gebaut werden.
- Evtl. läßt sich Zusatzplatine auch für anderes verwenden!
Nachteile:
- evtl. höherer Preis für beides zusammen anstatt auf einer Platine?
Und an China kommt man solange man sehr günstige Preise haben will nicht
umher (sorry, aber ist so! alles andere ist leider realitätsfern..).
Just my 2 cents
Peter
Die Bastlergemeinde ist sowieso nicht wirklich zu durchschauen. Der
Raspberry-Pi hat einen waren Hype ausgelöst. Mehr als 10.000 verkaufte
Boards innerhalb von Stunden. Ja und was kann man damit tun? Auch nicht
mehr als mit dem CP/M Teil. Na gut Doom spielen aber Ladder und Chess
sind auch ganz nett. An Programmiersprachen gibt es unter CP/M alles als
das Herz begehrt – sogar ohne dot.net Geraffel.
Ich überlege mir mal eine Shield Variante und stelle sie dann zur
Diskussion. Über I2C darf dann auch bubblino angeschlossen werden ;-)
Joe G. schrieb:> Eine Frage zur RAMDISK.
Im aktuellen SVN war nur Code für 4-bit Hardware.
Im Anhang ist jetzt mal eine 8-Bit 192 KB Ramdisk. Getestet habe ich nur
mit 4 MBit Chips, aber es sollte auch mit kleineren funktionieren. Da
die Ramdisk-Größe über Tabellen im BIOS statisch festgelegt ist, muß
dieses eben auch angepaßt werden. Deshalb ist im Anhang auch gleich ein
Diskimage.
Hier mal der Versuch (ausbaufähig), die Speicherorganisation
darzustellen:
Wenn der Z80-Arbeitsspeicher addressiert wird, sind die Adressleitungen
A8-A10 immer High, egal ob entsprechend große RAMs vorhanden oder nicht.
Der Arbeitsspeicher liegt also immer am oberen Ende des physikalischen
RAMs.
Die RAM-Disks füllen den Speicher von unten. Maximal sind 4 Disks a 1
MByte möglich. Zur Zeit wird nicht geprüft, ob eine Ramdisk-Adresse
(Disk/Track/Sector) überhaupt in den vorhandenen Speicher hinein paßt.
Es ist also möglich, durch Schreiben in die RAM-Disk, den
Arbeitsspeicher zu überschreiben.
Eine 192K Disk wird im BIOS (BIOS.MAC) folgendermaßen definiert:
1
; Name spt bls dks dir cks off
2
dpb rd192, 32, 1024, 192, 32, 0, 0
dpb: Macro, daß aus den folgenden Daten den "disk parameter block"
generiert.
spt: sectors per track. Die Zahl muß zum AVR Ramdisk-Treiber passen.
bls: block size (KByte).
dks: disk size. Anzahl Blöcke der Größe bls.
dir: Anzahl Directory Einträge
cks: check size. Anzahl zu prüfender Directory Einträge.
Bei Wechselmedien = cks, sonst 0.
off: offset. Anzahl reservierter Tracks. Wenn off bei der ersten
Ramdisk > 0 ist, wird beim Kaltstart das System hier her kopiert,
und beim Warmstart von hier, statt von SD-Karte geladen. Bringt im
Moment fast nix, da Original BDOS beim Warmstart ohne Disk A:
hängen bleibt.
(s.a. Beitrag "Re: CP/M auf ATmega88")
Die Ramdisk wird beim Starten nicht gelöscht (formatiert), so daß am
Anfang meistens Müll drin steht, den man auch durch "ERA *.*" in allen
Userbereichen nicht weg bekommt. Deshalb gibt es das Programm WIPE.COM
auf dem angehängten Diskimage.
TODO:
- RAMDISK-Zugriff auf für Ramdisk tatsächlich vorhandenes RAM
einschränken. ("#define RAMSIZE" in config.inc)
- Ramdisk(s) abhängig von RAMSIZE dynamisch beim Start einrichten.
Analog zu SD-Karten-Images. BIOS-Anpassung dann nicht mehr notwendig.
- Bei Power-On-Reset die Ramdisk initialisieren.
Sonstige Resets übersteht der Ramdiskinhalt in der Regel, auch wenn
dabei der Refresh für längere Zeit ausfällt.
- Ramdisk-Treiber für 4-bit-RAM aktualisieren.
- MMU: "Ge-paged-tes" RAM für CP/M3
Freiwillige vor.
Die Ramdisk haben wir damals initialisiert, indem wir den ersten
versteckten DIR-Eintrag getestet haben. War es unser Eintrag, war die
Initialisierung fertig. Waren fremde Bytes drin, so wurde unser Eintrag
geschrieben, der Rest vom DIR gelöscht und in den Speicherbereich, auf
den der DIR-Eintrag zeigt, das CCP kopiert.
Leo C. schrieb:> Im Anhang ist jetzt mal eine 8-Bit 192 KB Ramdisk.
Danke Leo! Deine Version geht nun auch mit 256 x 8. Das gibt genau eine
Ramdisk von 192 KB. Unter Verwendung von Wipe läßt sie sich auch sauber
löschen und dann beschreiben. Die Variante zunächst das BIOS zu ändern
und dan ein neues CP/M zu bauen ist akzeptabel. Dabei viel mir auf, das
in unsrer Version SUBMIT nicht richtig ausgeführt wird. M80 und L80
werden einfach nicht gestartet. Auf AltairSIMH läuft es jedoch
problemlos
Joe
bin grade auf euer interessantes Projekt gestoßen.
Bei der Suche nach den RAM's hatte ich bisher kein Glück, die alten
PCs/Amigas habe ich längst verschrottet, und so alte DRAMs noch zu
kaufen ist nicht so einfach...
Hat jemand von euch noch zwei DRAM-Chips übrig?
Vielleicht hat jemand auch noch eine oder zwei Platinen zu verkaufen?
Gruß Jens
Hallo Jens,
RAM's solltest du hier bekommen:
http://www.demotronic.net/
Vielleicht hat Peter auch noch welche übrig?
Eine Platine (Varinate 3 - Stick) hätte ich noch mit zugehörigem SD
Slot.
Ansonsten noch etwas warten, ich bin gerade an der neuen Hardwareversion
mit einem Arduino Pro Mini als CPU-Board.
Joe
Jens schrieb:> bin grade auf euer interessantes Projekt gestoßen.> Bei der Suche nach den RAM's hatte ich bisher kein Glück, die alten> PCs/Amigas habe ich längst verschrottet, und so alte DRAMs noch zu> kaufen ist nicht so einfach...> Hat jemand von euch noch zwei DRAM-Chips übrig?> Vielleicht hat jemand auch noch eine oder zwei Platinen zu verkaufen?>> Gruß Jens
Hallo Jens,
ich selbst kann Dir leider nichts anbieten, aber ebay ist Dein Freund
z.B:
http://www.ebay.de/itm/DRAM-ICs-72-x-256Kbyte-gesockelt-Board-18MB-Classic-/251037082536?pt=Bauteile&hash=item3a72f9e3a8
Ich meine nicht die dort angebotene Platine (zu teuer / zu viele
Bausteine für Deinen Zweck) sondern das was der Verkäufer weiter unten
noch schreibt:
Voraussichtlich nächste Woche biete ich noch viel mehr Schaltkreise aus
meiner Hobbyzeit der
70er bis 90er- Jahre an. Die Aufbereitung zur Einstellung ist jedoch
sehr aufwändig/zeitintensiv,
weshalb ich gegenwärtig eher überlege, das Folgende in Pakete
zusammenzustellen.
Hier ein vorläufiger Überblick (Typenvielfalt und Daten werden noch
erweitert):
...
4 HY 534256 S-10 Hynix CMOS
4 HY 53C256 -LS80 Hynix CMOS
36 HY 53C256 LS-80 ? RAM- Board
...
Der oben genannten Chips wären z.B. passende DRAM's für das hier
beschriebene Projekt.
Entscheidend ist, das die DRAM's 4bit x 256kbit organisiert sind, nicht
zu verwechseln mit 1bit x 256kbit wie z.B. HYB 41256-10 Siemens DRAM!
Ich würde den Verkäufer einfach mal anschreiben...
Viele Grüße
Markus
Der verkauft auch HAL16V8.
Wenn ich mich recht erinnere, dann haben HAL eine vom Hersteller
festgelegte ROM-Maske. Im Gegensatz zu PAL (mit Zener-Fuse) und GAL (mit
EEPROM) ist da nix mit wiederverwenden.
Joe G. schrieb:> Dabei viel mir auf, das> in unsrer Version SUBMIT nicht richtig ausgeführt wird. M80 und L80> werden einfach nicht gestartet. Auf AltairSIMH läuft es jedoch> problemlos
Das habe jetzt endlich mal getestet und ist hier leider genauso.
Aber früher ging das mal...
Vorläufig kann man DO.COM (bzw. SuperSUB), z.B. aus obigem
Emulator-Paket nehmen, das sowieso besser ist.
Noch was anderes.
Da wir ja inzwischen auch Z80 können, wäre es auch interessant, einen
der verbesserten BDOS-Clones zu installieren. Diese wiederum würden von
einem Uhrenbaustein profitieren.
Da ich demnächst sowieso einige Bauteile bestellen will, möchte ich
einen RTC mitbestellen. Welcher Chip ist denn hier so gängig/beliebt?
Beim Reichelt käme wohl nur der DS1307 in Frage.
Der DS1307 ist sehr weit verbreitet und sicherlich nicht die
schlechteste Wahl.
Ich hatte mir die Tage auch schon mal Gedanken darüber gemacht wie I2C
zu benutzen ist. Es könnten ja dann dort ein 8 Bit I/O Port oder A/D
oder oder angeschlossen werden. Die BIOS Funktionen 05 - Stanzer und 06
- Lesereingabe werden doch eigentlich nie mehr benötig. Diese Funktionen
könnten doch eigentlich genutzt werden um auf den I2C zu schreiben bzw.
vom I2C zu lesen. Wir müßten uns nur noch ein ordentliches Protokoll
einfallen lassen.
An andere BDOS-Clones habe ich auch schon gedacht CP/M 3.0 ...
Joe G. schrieb:> Der DS1307 ist sehr weit verbreitet und sicherlich nicht die> schlechteste Wahl.
Na, dann kommen mal >= 2 [1] auf die Liste.
> oder oder angeschlossen werden. Die BIOS Funktionen 05 - Stanzer und 06> - Lesereingabe werden doch eigentlich nie mehr benötig. Diese Funktionen> könnten doch eigentlich genutzt werden um auf den I2C zu schreiben bzw.
Ich habe noch einen Stapel Lochkarten. Aber leider keine Stanze. ;-)
Imho greifen alle gängigen CP/M Kommunikationsprogramme direkt auf die
Ports der seriellen Schittstelle zu, weil die CP/M-Kanäle kaum zu
gebrauchen sind.
Man könnte z.B. im AVR-Teil (damals) gängige UARTs emulieren.
> An andere BDOS-Clones habe ich auch schon gedacht CP/M 3.0 ...
CP/M 3 ging vorher auch schon, da es mit 8080 auskommt. Macht meiner
Meinung nach ohne Banking wenig Sinn. Die Alternativen leisten dann
mehr, bei weniger RAM-Verbrauch.
[1] Da ich z.Zt. dabei bin, meine gute alte HD64180 Karte [2]
wiederzubeleben, soll die natülich nicht zurück stehen müssen.
Allerdings wäre dafür ein RTC mit SPI besser.
[2] Beitrag "Re: z80 system"
Hallo Peter,
ist der V53C104P10L auf dem CP/M-Stick einsetzbar? Wenn ja hätte ich
Interesse an zwei oder vier Stück davon, kannst du mir vielleicht per PM
an jenskauf(at)gmx.net schreiben?
Gruß Jens
Sieht schick aus!
USB Anbindung wie? FT232RL?
Welcher Ramchip (1 oder 2?)? Bezugsquelle?
Gibts passende Arduino Pro Mini über ebay oder wo?
Ansonsten wäre ich mit 2 Stück dabei (je nach Preis auch 3-5).
Peter
USB über FT232RL, die Variante über den MCP2200 würde noch einen
externen Quarz benötigen.
DRAM ist ein HM51W17805 (16M EDO RAM 2-Mword x 8 Bit)
Als Arduino Pro Mini würde auch ein DFRobot Pro Mini V1.2 5V 16MHz
Arduino Compatible gehen (9,9 €) allerdings müßte bei allen Varianten
(auch China) ein 3.3V Regler eingesetzt werden.
Platine derzeit 4 Lagen, es geht sehr eng zu! bei einer Abnahmemenge von
10 liegt der Preis ca. um 11€.
Joe
Hallo Leute,
man ist der Tread riesig. Folgendes Problem: Ich habe einen AVR Stick
(der aus diesem Forum) geschenkt bekommen. Da ist allerdings eine alte
Version an Software drauf. Nun lese ich hier etwas von FAT 16 und Z80
Unterstützung. Wie bekomme ich das alles auf den Stick? Dem Atmel ein
binärfile reinschiessen bekomme ich hin, wie gehts dann mit der SD
Karte? Gibt es da eine Anleitung oder kann mir einer erklären wo ich die
Files wie draufspielen muss?
Gruß
Hannes
Um die AVR-Firmware neu übersetzen (Taktfrequenz 20 statt 24 MHz) habe
ich versucht, die Batchdatei AVRBuild.bat im Ordner der Sourcen
auszuführen, ich erhalte folgende Meldungen:
---
AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
Copyright (C) 1995-2009 ATMEL Corporation
D:\Jens Privat\Z80\Software\AVR\avr\init.asm(44): error: ldiw: Unknown
instructi on or macro
D:\Jens Privat\Z80\Software\AVR\avr\init.asm(44): error: syntax error,
unexpected ',', expecting ':'
Assembly failed, 2 errors, 0 warnings
---
Wie sind die Sourcen zu compilieren, was ist ggf. vorher zu
installieren?
Gruß Jens
Es sieht aus aus ob bei dir die Datei macros.inc nicht geladen wird.
In der avrcpm.asm müßte folgendes stehen:
.include "config.inc"
.include "svnrev.inc"
.include "macros.inc"
Den richtigen Prozessor hast du gesetzt? -Datmega328P
Jens Kaufmann schrieb:> Um die AVR-Firmware neu übersetzen (Taktfrequenz 20 statt 24 MHz) habe> ich versucht, die Batchdatei AVRBuild.bat im Ordner der Sourcen> auszuführen, ich erhalte folgende Meldungen:
In den Sourcen gibt es keine Batchdatei.
Es gibt allerdings ein Makefile, das auch unter Windows funktioniert,
wenn GNU Make installiert ist.
Wo es die Sourcen gibt, hat Joe im Artikel direkt über Deinem gepostet.
Leo C. schrieb:> In den Sourcen gibt es keine Batchdatei.
Ich nehme an, dass ist die Batchdatei die ich mit den Quellen auf die
SD-Card gespielt hatte. Entweder wie Leo C. schon sagte das Makefile
verwenden oder im AVR-Studio das Projekt avrcpm.aps öffnen und unter
Project | Assembler Options die zeile
-DF_CPU=20000000 -DBAUD=57600 -Datmega328P -DDRAM_8BIT
eingeben.
@ Leo C.
Mich würde mal interessieren, ob der DS1307 auch mit 3.3V I2C läuft,
spezifiziert ist er ja nur für 5V. Auch für weitere IC's (IO, AD, DA
...) ist es interessant. Ansonsten müßte ein PCA9306 oder ähnliches
verwendet werden.
Mit der UART Emulation für I2C könnte ich mich auch anfreunden. Dann
kann der I2C Bus mit Kermit oder ähnlicher Software angesprochen werden.
Joe G. schrieb:> Ich nehme an, dass ist die Batchdatei die ich mit den Quellen auf> die SD-Card gespielt hatte.
Dann schaue ich mir die mal an.
> Mich würde mal interessieren, ob der DS1307 auch mit 3.3V I2C läuft,> spezifiziert ist er ja nur für 5V.
Ups, das hatte ich auch übersehen. Das Datenblatt meint:
"When a 3-volt battery is connected to the device and VCC is below 1.25
x VBAT, reads and writes are inhibited."
Mit einer 2,5Volt Batterie würde es wahrscheinlich funktionieren...
> Auch für weitere IC's (IO, AD, DA ...) ist es interessant. Ansonsten> müßte ein PCA9306 oder ähnliches verwendet werden.
Ähnliches wäre z.B.: AN79055 "Bi-directional level shifter for I²C-bus
and other systems." (2 FETs und 2 zusätzliche Pullups.)
https://www.google.com/search?q=%22AN97055%22
Beim Reichelt habe ich noch den PCF8583 gefunden. Größerer
Stromverbrauch, kein Batterie-Management, aber billiger und *"operating
supply voltage: 2.5 V to 6 V"*
Für mein anderes Projekt (HD64180) gehen die aber beide nicht, da ich
dort kein I2C habe.
Joe G. schrieb:> USB über FT232RL, die Variante über den MCP2200 würde noch einen> externen Quarz benötigen.> DRAM ist ein HM51W17805 (16M EDO RAM 2-Mword x 8 Bit)> Als Arduino Pro Mini würde auch ein DFRobot Pro Mini V1.2 5V 16MHz> Arduino Compatible gehen (9,9 €) allerdings müßte bei allen Varianten> (auch China) ein 3.3V Regler eingesetzt werden.> Platine derzeit 4 Lagen, es geht sehr eng zu! bei einer Abnahmemenge von> 10 liegt der Preis ca. um 11€.> Joe
Hmm.. ich werde (für mich) das Gefühl nicht los, das wir dann mit dem
'USB Stick' Konzept besser dran sind.. was meinen die anderen..
Peter
@Joe: Die/Deine Arbeit an sich ist klasse!!
Nur wenn halt alles so mal zusammen rechne.. entschwinden z.Z alle
Vorteile..
Eine separate Platine - evtl. direkt für CP2102 Dongle Anschluß.. geht
evtl. etwas größer mir Bestückung von beiden Seiten.. und viel
günstiger..
Atmega328P+DRAM+Micro-SD+Hühnerfutter
Peter
Peter Sieg schrieb:> Hmm.. ich werde (für mich) das Gefühl nicht los, das wir dann mit dem> 'USB Stick' Konzept besser dran sind.. was meinen die anderen..
Definiere "wir".
Peter Sieg schrieb:> Nur wenn halt alles so mal zusammen rechne.. entschwinden z.Z alle> Vorteile..
Also weiter oben hast Du noch ganz anders argumentiert.
Könnte ja sein, daß das Ding in der "Arduino-Szene" richtig einschlägt.
(Zumindest hier merkt aber leider bisher nichts davon.)
Joe G. schrieb:> ZSDOS Portieren ist ja auch eine nette Aufgabe.
Genau. Super.
Nils S. schrieb:> ... und eine MMU, FPU von Vorteil, 32 Bit Arch. (16 wüde gehen), und> und und
Ohne MMU ist ein Kernel zwar auch realisierbar aber der Kern lebt und
stirbt mit der MMU den das ist es was Ihn so stabil macht. Die Hardware
MMU ist es was ein Linux System so gut laufen lässt.
Waschmaschinenprozessoren ohne MMU sind zwar auch möglich nur das geht
eben von Zeit zu Zeit schief wenn da irgend ein Programm meint es muss
ins RAM posten. Abgesehen davon das ein ARM9 oder ARM11 sehr wenig
kostet und eben diese MMU schon hat. Warum implementierst Du das CP/M
System nicht auf dem ARM9/11? Der ist schon von vorne herein 32bit breit
und mit dem 3S2440 von Samsung der in einem FriendlyARM eingebaut ist
sehr sehr kostengünstig (die Hardware kostet ca. USD60 - 80,- inkl 3,5"
Schirm) uf den kann man bereits ein Keyboard und Netzwerk anstecken.
MfG
weakbit
Joe G. schrieb:> Gibt es eigentlich einen vernünftigen Grund warum wir beim CP/M mit dem> 62K Speichermodell arbeiten?
Ja, wurde von sprite_tm so "geliefert", ... und Trägheit.
Um das zu änderen braucht man eine möglichst vollständige
CPM-Distribution. Bei uns fehlt movcpm.com mit der zugehörigen
Seriennummer.
Oder man generiert alles neu aus den im Netz vorhandenen Sourcen.
Vor ein paar Wochen hatte ich mal mit movcpm angefangen, bin aber wieder
davon abgekommen. Im Anhang ist das Ergebnis. Das movcpm finde ich z.Zt.
nicht, meine Notizen auch nicht. Im Makefile und in CFGACPM.LIB die
gewünschte Spreichergröße setzen.
64k-System macht aber mit unseren großen Diskimages wenig Sinn, da diese
für alv und csv viel Platz beanspruchen. (Man kann das beobachten, in
dem man in avr/config.inc HEAP_DEBUG auf 1 setzt.)
SUBMIT
hatte ich mir gestern Abend nochmal angeschaut.
Joe, falls der Submit-Job "nur" dann nicht ausgeführt wird, wenn er
nicht auf Laufwerk A gestartet wird, handelt es sich (leider) um das
dokumentierte Verhalten von CP/M 2.x. [1]:
1
"If the SUBMIT function is performed on any disk other than
2
drive A, the commands are not processed until the disk is inserted
3
into drive A and the system reboots."
It's not a bug, ...
Beim simh Altair 8800 Emulator funktioniert Submit auch auf anderen
Laufwerken, weil dort dafür (und einige andere Kleinigkeiten) im BIOS
Patches vorhanden sind, die bei jedem Warmstart an CCP und BDOS
appliziert werden.
Man kann sich das Patchen aber sparen, wenn man Submit durch eine der
zahlreich vorhandenen Alternativen (DO, SUPERSUB, JOB, ...) ersetzt.
[1] http://www.cpm.z80.de/manuals/archive/cpm22htm/ch1.htm#Section_1.6.7
Leo C. schrieb:> Man kann sich das Patchen aber sparen, wenn man Submit durch eine der> zahlreich vorhandenen Alternativen (DO, SUPERSUB, JOB, ...) ersetzt.
Leider bricht DO oder SUPERSUB auch mit einem Fehler ab, M80 und L80
einzeln benutzt geht jedoch (Die Datein sind auch auf der HD).
D>do makecpm
SuperSUB V1.1
Memory full error on line number: 2501
Anbei noch alle Datein um sich ein komplettes ZSDOS zu basteln. Das
Diskimage ist wie immer im Altairformat.
Joe
Leo C. schrieb:> Joe, versuch's mal hiermit.
Danke! Es geht damit. Doch warum? Liegt der Unterschied wirklich nur
darin, dass dein File genau 256 Byte lang ist?
> Ok, es war ^Z
Es hätte mich auch gewundert, wenn Du nicht drauf gekommen wärst. Ich
war aber gerade dabei, eine längere Antwort zu tippen. Vielleicht
interessierts ja noch jemanden.
Die 256 Byte sind eher Zufall. Ich habe mit ddt den Sektor nach dem Text
mit 01AH (== ^Z == CP/M End Of File) aufgefüllt. Die Datei habe ich
danach mit SAVE 1 <dateiname> gespeichert.
SuperSub scheint beim Einlesen das physikalische Dateiende nicht zu
beachten, und versucht dann den gesamten Arbeitsspeicher als Text zu
interpretieren, bzw. bis ein EOF-Zeichen erkannt wird.
CP/M 3 (und ZSDOS glaube ich auch) können den Füllgrad des letzten
Sektors speichern (und damit die exakte Dateilänge), aber wahrscheinlich
macht kein CP/M-Programm davon Gebrauch. CP/M Texteditoren speichern
natürlich immer (mindestens) ein 01Ah am Textende.
Vielleicht hat Dein PC-Texteditor ja eine Möglichkeit, Steuerzeichen
direkt einzugeben. Ansonsten: echo, dd, copy, cat, ...
Leo C. schrieb:> Vielleicht hat Dein PC-Texteditor ja eine Möglichkeit
Ich nehme nun WinVi...
@alle
Um die Vorteile des ZSDOS nun auch wirklich nutzen zu können, braucht es
nun der Uhr. Vielleicht können wir uns auf eine gemeinsame
Hardwarevariante verständigen. Anbei mein Vorschlag. Die Uhr (DS1307)
ist über einen Pegelwandler am I2C Bus angeschlossen. Weiterhin ist am
Bus ein PCF8574 (8 Bit I/O). Somit hätte man neben der Uhr noch die
Möglichkeit einen vollständigen 8 Bit Port zu benutzen (LCD, Tastatur,
Led, wie auch immer). Außerdem können ja weitere I2C Geräte
angeschlossen werden.
Kommentare, Vorschläge?
Joe
Joe G. schrieb:> Um die Vorteile des ZSDOS nun auch wirklich nutzen zu können, braucht es> nun der Uhr.
Um die Zeit bis zur funktionierenden RTC zu überbrücken, bastel ich
gerade an der Interrupt-Uhr.
> Die Uhr (DS1307)> ist über einen Pegelwandler am I2C Bus angeschlossen.
2. Stromversorgung und Pegelwandler wegen eines unpassenden
Uhrenbausteins?
Wie wärs mit PCF8583 oder DS1337 + 2 Dioden?
> Weiterhin ist am> Bus ein PCF8574 (8 Bit I/O). Somit hätte man neben der Uhr noch die> Möglichkeit einen vollständigen 8 Bit Port zu benutzen (LCD, Tastatur,> Led, wie auch immer). Außerdem können ja weitere I2C Geräte> angeschlossen werden.
Was könnte man denn noch anschließen wollen?
Drucker vielleicht? Dann bräuchte man 2. PCF8574 oder zB. PCA9555.
2. Serielle? Gibs I2C-UARTS? 2. Software-UART stelle ich mir schwierig
vor.
Thread beobachten
Seitenaufteilung abschalten