CP/M auf ATmega88

[Nils E. (yetanotheruser)]

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

[Joe G. (feinmechaniker)]

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?

[Peter Sieg (Gast)]

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

[andre b. (do9brx)]

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

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

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

Gruß, Andre

[Peter Sieg (Gast)]

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

[Nils E. (yetanotheruser)]

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.

[Peter Sieg (Gast)]

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

[Peter Sieg (Gast)]

Der AX81 von Jörg ist da:

http://www.jcwolfram.de/projekte/avr/ax81/main.php

Peter

[Peter Sieg (Gast)]

Und auch:

Beitrag "AX81 - ZX81 im AVR"

Peter

[Peter Sieg (Gast)]

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

[Peter S. (petersieg)]

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

[Peter S. (petersieg)]

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

[Ronny M. (hobby-coder)]

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?

[Joe G. (feinmechaniker)]

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.

[Ronny M. (hobby-coder)]

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. (feinmechaniker)]

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.

[GUEST#1 (Gast)]

@Joe G.:  http://obex.parallax.com/objects/734/   ;-)

[Joe G. (feinmechaniker)]

Hier die Schaltung der VGA und Tastaturansteuerung.

[pollmull (Gast)]

Joe G. schrieb:
> Hier die Schaltung der VGA und Tastaturansteuerung.

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

http://forums.parallax.com/showthread.php?117996-Dracblade-SBC-with-Catalina-C-PropBasic-CP-M-MP-M-TRS80-wireless-network&highlight=zicog

[Joe G. (feinmechaniker)]

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.

[pollmull (Gast)]

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.

[Peter S. (petersieg)]

Oder PIC32 mit z80sim:

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

Peter

[Peter S. (petersieg)]

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

[Joe G. (feinmechaniker)]

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

[Osche R. (Gast)]

Hat der Propeller nicht genügend Rechenleistung, um den AVR mit zu 
emulieren?

[Frank P. (mauz)]

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

[Hans- w. S. (hschuetz)]

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

[Joe G. (feinmechaniker)]

@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

[Frank P. (mauz)]

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

[Joe G. (feinmechaniker)]

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

[Nils S. (kruemeltee)]

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.

[Joe G. (feinmechaniker)]

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

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

[Peter Sieg (Gast)]

@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

[Joe G. (feinmechaniker)]

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 (Gast)]

Prima! Danke für die Korrektur!
Hast du mal probiert, ob der ominöse Multiplanfehler nun weg ist..?

Gruß Peter

[Joe G. (feinmechaniker)]

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

[Peter S. (petersieg)]

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

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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.

[Leo C. (rapid)]

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.

[Joe G. (feinmechaniker)]

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

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

Leo C. schrieb:
> bei 8080 ein undefinierter Opcode

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

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

Vielleicht hilft ja noch einer ;-)

[Leo C. (rapid)]

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

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

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

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

Allen einen Guten Rutsch
Leo

[Markus G. (thechief)]

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

[Joe G. (feinmechaniker)]

@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

[Peter Sieg (Gast)]

@Markus: Willkommen!

Prima! Noch einen Mitstreiter!

Peter

[Markus G. (thechief)]

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

[Markus G. (thechief)]

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

[Joe G. (feinmechaniker)]

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 (Gast)]

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

Peter

[Joe G. (feinmechaniker)]

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.

[Peter S. (petersieg)]

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

[Peter S. (petersieg)]

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

[Markus G. (thechief)]

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

[Joe G. (feinmechaniker)]

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.

[Peter S. (petersieg)]

@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

[Markus G. (thechief)]

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

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


Gruß

Markus

[Joerg W. (joergwolfram)]

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

[Nils E. (yetanotheruser)]

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

[Markus G. (thechief)]

Hallo zusammen,

so nun ist es soweit:

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

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

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

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


Viele Grüße

Markus

[Joe G. (feinmechaniker)]

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

Herzlichen Glückwunsch!

[Markus G. (thechief)]

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

#define DRAM_8BIT 0

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

#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:

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

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

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

.equ MEMTEST = 1

 in der Datei: config.inc zu setzen!


Viele Grüße

Markus

[Leo C. (rapid)]

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 (Gast)]

Wer sollte was dagegen haben.. ;-)

Gruß Peter

[Markus G. (thechief)]

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

[Joe G. (feinmechaniker)]

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

[Markus G. (thechief)]

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:

.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 08         EX AF,AF'  (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 10 oo      DJNZ o    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 18 oo  JR o    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 20 oo  JR NZ,o    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 28 oo  JR Z,o    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 30 oo  JR NC,o    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; 38 oo  JR C,o    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; CB     (Z80 specific)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; D9    EXX    (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; DD     (Z80)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; ED    (Z80 specific)
.dw (FETCH_NOP  | OP_INV  | STORE_NOP)   ; FD     (Z80 specific)

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


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

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

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


Viele Grüße

Markus

[Joe G. (feinmechaniker)]

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

[Peter Sieg (Gast)]

Sehr schön, das da (noch/wieder) wer dran arbeitet!

Gruß Peter

[Markus G. (thechief)]

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

[Peter Sieg (Gast)]

Gerade festgestellt das:
SIEMENS HYB514256B-70
wovon ich noch 9 Stk. habe NICHT laufen!

Kennt jemand noch eine Quelle von 4256 Drams?

Peter

[Markus G. (thechief)]

Hallo zusammen,

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

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!

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:

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

Viele Grüße

Markus


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

[Markus G. (thechief)]

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 (Gast)]

Hmm Ja.. sind mit 30MHz getaktet.. ;-)
Das ist dann natürlich grenzwertig und das auch noch bei nur 3,3V..

Gruß Peter

[Leo C. (rapid)]

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

[Markus G. (thechief)]

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

Hallo Peter,

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

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

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


Viele Grüße

Markus

[Peter Sieg (Gast)]

Bei laufen die alle nicht bei 20MHz (SIEMENS HYB514256B-70).

Peter

[Peter Sieg (Gast)]

@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

[Leo C. (rapid)]

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

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

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

[Peter Sieg (Gast)]

@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

[Leo C. (rapid)]

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

Deshalb habe ich extra eine Quelle angegeben. ;-)

[Markus G. (thechief)]

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

[Markus G. (thechief)]

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

[Leo C. (rapid)]

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.

[Peter Sieg (Gast)]

@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

[Leo C. (rapid)]

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

[Markus G. (thechief)]

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

[Peter Sieg (Gast)]

Hi.

8Mhz habe ich (und will ich) nicht ausprobieren.
Die V53C104P haben -70.

Bei 30MHz habe sie damals nicht funktioniert.

Peter

[Peter Sieg (Gast)]

Um noch mal ein paar 'Schwesterprojekte' zu zeigen:

Propeller:
http://forums.parallax.com/showthread.php?116893-RamBlade-Prop-SRAM-microSD-addon-to-run-ZiCog-CPM-PropDos-Catalina-etc

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

Das Ramblade in Streichholzschachtelgröße hatte ich schon mal.. dann 
aber verkauft.. habe es mir mal wieder bestellt (40US$+6US$ shipping).

Bei dem PIC32 habe ich mir mal ein Duinomite-Mini von Olimex für 30€ 
bestellt. Das ist wohl z.Z das Stand-Alone Basic drauf.. aber das sollte
sich ja ändern lassen..

Trotzdem ist und bleibt unser 'Baby' die AVR Lösung ;-)

Peter

[Markus G. (thechief)]

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

[Leo C. (rapid)]

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.

[Leo C. (rapid)]

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

[Draco (Gast)]

Leo C. schrieb:
> Leider habe ich keine Quellen gefunden, die den DAA Befehl vollständig
> beschreiben.

Schau mal im Buch "Programmierung des Z80" ab Seite 226: 
http://www.wincpc.ch/docs/Programmierung%20des%20Z80.pdf

Ich gehe mal davon aus, dass der Link legal ist, da Rodney Zaks an 
anderer Stelle der Bereitstellung des Buches zugestimmt hat: 
http://www.z80.info/zaks.html

[Leo C. (rapid)]

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)

[Markus G. (thechief)]

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

[Bernd B. (mainhattan)]

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.

[Gee_Tee (Gast)]

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

[Peter Sieg (Gast)]

Super!!
Nun arbeitet MP so wie es soll ;-)

Danke!

Peter

[Leo C. (rapid)]

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.

[Leo C. (rapid)]

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.

[Markus G. (thechief)]

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

[Abdul K. (ehydra)]

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

[Joerg W. (joergwolfram)]

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

[Leo C. (rapid)]

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. (rapid)]

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

[Markus G. (thechief)]

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

[Markus G. (thechief)]

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

[Leo C. (rapid)]

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:

do_op_prefixED:
  mem_read_ds zl,z_pc      ;zl = memReadByte(z_pc)
  adiw  z_pcl,1            ;++z_pc
  ldi  zh,high(EDjmp)      ;
  ijmp


do_op_prefixDD:
;TODO: Flag für DD setzen

  mem_read_ds zl,z_pc      ;zl = memReadByte(z_pc)
  adiw  z_pcl,1            ;++z_pc
  ldi  zh,high(DDFDjmp)    ;
  ijmp

do_op_prefixFD:
;TODO: Flag für FD setzen

  mem_read_ds zl,z_pc      ;zl = memReadByte(z_pc)
  adiw  z_pcl,1            ;++z_pc
  ldi  zh,high(DDFDjmp)    ;
  ijmp

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

  opctable opcjmp

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

Danach die neuen Tabellen. z.B.:

  opctable EDjmp

instr   fetch_nop,  op_nop,    store_nop  ;00    ;NOP
.
.
instr   fetch_C,    op_IN,     store_B    ;40    ;IN B,(C)
instr   fetch_B,    op_OUT,    store_nop  ;41    ;OUT (C),B
instr   fetch_BC,   op_SBCHL,  store_nop  ;42    ;SBC HL,BC
instr   fetch_DIR16,op_STBC,   store_nop  ;43    ;LD (nn),BC
instr   fetch_nop,  op_NEG,    store_nop  ;44    ;NEG
.
.

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.

[Konrad S. (maybee)]

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.

[Leo C. (rapid)]

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.

[Bernd B. (mainhattan)]

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. (thechief)]

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

[Markus G. (thechief)]

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

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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.

[Horst.S (Gast)]

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.

[Horst.S (Gast)]

Hier noch meine Tabelle dazu.....

[Leo C. (rapid)]

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.

[Leo C. (rapid)]

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

CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
04<00@0000
05<01@0001
06<02@0002
07<03@0003
0C<08@0008
0D<09@0009
0E<0A@000A
0F<0B@000B
14<10@0010
15<11@0011
16<12@0012
17<13@0013
1C<18@0018
1D<19@0019
1E<1A@001A
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.

[Peter Sieg (Gast)]

Wichtig wäre eine einfache Meldung Ram1 Und/Oder Ram2 defekt und gut ist 
und
dann ggf. noch die Bits (für Lötfehler bei LR Aufbau).

Peter

[Markus G. (thechief)]

Markus G. schrieb:
> Hallo zusammen,
>
> ich habe meine, im Beitrag #2541628 veröffentlichte,
> Speichertest-Routine nun noch einmal verfeinert:
>
> 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!
>
> 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:
>
>

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

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

[Leo C. (rapid)]

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:

CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Addr xx yy
0000 00 04 -------- -----X--
0001 01 05 -------- -----X--
0002 02 06 -------- -----X--
0003 03 07 -------- -----X--
0008 08 04 ----X--- -----X--
0009 09 05 ----X--- -----X--
000A 0A 06 ----X--- -----X--
000B 0B 07 ----X--- -----X--
000C 0C 04 ----X--- --------
000D 0D 05 ----X--- --------
000E 0E 06 ----X--- --------
000F 0F 07 ----X--- --------
0010 10 14 -------- -----X--
0011 11 15 -------- -----X--
0012 12 16 -------- -----X--
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. 
:-)

[Leo C. (rapid)]

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.

[Leo C. (rapid)]

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:

-l100,11a
  0100  MVI  A,01
  0102  OUT  4F
  0104  LXI  B,77FF
  0107  PUSH B
  0108  POP  PSW  
  0109  LXI  B,1234
  010C  LXI  D,5678
  010F  LXI  H,9ABC
  0112  ??=  08
  0113  ??=  D9
  0114  ??=  08
  0115  ??=  D9
  0116  MVI  A,00
  0118  OUT  4F
  011A  NOP  
  011B  
-g100,11a

    N   A =01 BC =0000 DE =0000 HL =0000 SP=0100 PC=0104       01 FF 77 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
    N   A =01 BC =77FF DE =0000 HL =0000 SP=0100 PC=0107       C5 F1 01 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
    N   A =01 BC =77FF DE =0000 HL =0000 SP=00FE PC=0108       F1 01 34 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
SZHVNC  A =77 BC =77FF DE =0000 HL =0000 SP=0100 PC=0109       01 34 12 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
SZHVNC  A =77 BC =1234 DE =0000 HL =0000 SP=0100 PC=010C       11 78 56 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
SZHVNC  A =77 BC =1234 DE =5678 HL =0000 SP=0100 PC=010F       21 BC 9A 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
SZHVNC  A =77 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0112       08 D9 08 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
        A =00 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0113       D9 08 D9 
SZHVNC  A'=77 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
        A =00 BC =0000 DE =0000 HL =0000 SP=0100 PC=0114       08 D9 3E 
SZHVNC  A'=77 BC'=1234 DE'=5678 HL'=9ABC IX=0000 IY=0000 I=00       
SZHVNC  A =77 BC =0000 DE =0000 HL =0000 SP=0100 PC=0115       D9 3E 00 
        A'=00 BC'=1234 DE'=5678 HL'=9ABC IX=0000 IY=0000 I=00       
SZHVNC  A =77 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0116       3E 00 D3 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       
SZHVNC  A =00 BC =1234 DE =5678 HL =9ABC SP=0100 PC=0118       D3 4F F7 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00       *011A
-

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 (Gast)]

Super! Habe es gestern mal für 328P übersetzt und läuft ersteinmal 
soweit..
Gibts für ddtz eigentlich ein Manual?

Peter

[Leo C. (rapid)]

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

[Leo C. (rapid)]

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

[Leo C. (rapid)]

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

[Joe G. (feinmechaniker)]

Glückwunsch!
Ich bin sprachlos.

[Peter Sieg (Gast)]

@Leo C. Super! Herzlichen Glückwunsch!!

Muss ich die Tage gleich mal ausprobieren..

Vielen Dank!

Gruß Peter

[Peter Sieg (Gast)]

Hab ich ausprobiert.. Compile von hello.pas geht.. aber sollte da nicht 
ein hello.com gespeichert sein.. (man ist das lange her mit TP ;-) )

Peter

[Leo C. (rapid)]

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.

[Peter Sieg (Gast)]

Arrg.. compiler (O)ptions - (C)om file ;-)

Ja, ja lang ist es her..

Super!

Peter

[Leo C. (rapid)]

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:

C>exz80doc
Z80 instruction exerciser
Undefined status bits NOT taken into account
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles   OK
add hl,<bc,de,hl,sp>..........( 35,840) cycles   OK
add ix,<bc,de,ix,sp>..........( 35,840) cycles   OK
add iy,<bc,de,iy,sp>..........( 35,840) cycles   OK
aluop a,nn....................( 45,056) cycles   OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles   OK
aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles   ERROR **** crc expected:a4026d5a found:e7318427
aluop a,(<ix,iy>+1)...........(229,376) cycles   ERROR **** crc expected:e849676e found:74a1545f
aluop a,(<ix,iy>-1)...........(229,376) cycles   ERROR **** crc expected:edd8136d found:7130205c
bit n,(<ix,iy>+1).............(  2,048) cycles   OK
bit n,(<ix,iy>-1).............(  2,048) cycles   OK
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles   OK
cpd<r>........................(  6,144) cycles   ERROR **** crc expected:c8439345 found:a8554cee
cpi<r>........................(  6,144) cycles   ERROR **** crc expected:e66fa7d2 found:478b76a1
<daa,cpl,scf,ccf>.............( 65,536) cycles 
   VN   A =8E BC =9079 DE =8D5B HL =A559 SP=299D PC=253B       27 00 00 
        A'=00 BC'=0000 DE'=0000 HL'=0000 IX=1D60 IY=09FA I=00       Invalid opcode!

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

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

[Joe G. (feinmechaniker)]

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

[Joe G. (feinmechaniker)]

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

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

[Leo C. (rapid)]

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:

C>ex1
Z80 instruction exerciser
Undefined status bits NOT taken into account
<inc,dec> a...................(  3,072) cycles   OK
<inc,dec> b...................(  3,072) cycles   OK
<inc,dec> bc..................(  1,536) cycles   OK
<inc,dec> c...................(  3,072) cycles   OK
<inc,dec> d...................(  3,072) cycles   OK
<inc,dec> de..................(  1,536) cycles   OK
<inc,dec> e...................(  3,072) cycles   OK
<inc,dec> h...................(  3,072) cycles   OK
<inc,dec> hl..................(  1,536) cycles   OK
<inc,dec> ix..................(  1,536) cycles   OK
<inc,dec> iy..................(  1,536) cycles   OK
<inc,dec> l...................(  3,072) cycles   OK
<inc,dec> (hl)................(  3,072) cycles   OK
<inc,dec> sp..................(  1,536) cycles   OK
<inc,dec> (<ix,iy>+1).........(  6,144) cycles   OK
<inc,dec> (<ix,iy>-1).........(  6,144) cycles   OK
<inc,dec> ixh.................(  3,072) cycles   OK
<inc,dec> ixl.................(  3,072) cycles   OK
<inc,dec> iyh.................(  3,072) cycles   OK
<inc,dec> iyl.................(  3,072) cycles   OK
ld <bc,de>,(nnnn).............(     32) cycles   OK
ld hl,(nnnn)..................(     16) cycles   OK
ld sp,(nnnn)..................(     16) cycles   OK
ld <ix,iy>,(nnnn).............(     32) cycles   OK
ld (nnnn),<bc,de>.............(     64) cycles   OK
ld (nnnn),hl..................(     16) cycles   OK
ld (nnnn),sp..................(     16) cycles   OK
ld (nnnn),<ix,iy>.............(     64) cycles   OK
ld <bc,de,hl,sp>,nnnn.........(     64) cycles   OK
ld <ix,iy>,nnnn...............(     32) cycles   OK
ld a,<(bc),(de)>..............(     44) cycles   OK
ld <b,c,d,e,h,l,(hl),a>,nn....(     64) cycles   OK
ld (<ix,iy>+1),nn.............(     32) cycles   OK
ld (<ix,iy>-1),nn.............(     32) cycles   OK
ld <b,c,d,e>,(<ix,iy>+1)......(    512) cycles   OK
ld <b,c,d,e>,(<ix,iy>-1)......(    512) cycles   OK
ld <h,l>,(<ix,iy>+1)..........(    256) cycles   OK
ld <h,l>,(<ix,iy>-1)..........(    256) cycles   OK
ld a,(<ix,iy>+1)..............(    128) cycles   OK
ld a,(<ix,iy>-1)..............(    128) cycles   OK
ld <ixh,ixl,iyh,iyl>,nn.......(     32) cycles   OK
ld <bcdehla>,<bcdehla>........(  3,456) cycles   OK
ld <bcdexya>,<bcdexya>........(  6,912) cycles   OK
ld a,(nnnn) / ld (nnnn),a.....(     44) cycles   OK
ldd<r> (1)....................(     44) cycles   OK
ldd<r> (2)....................(     44) cycles   OK
ldi<r> (1)....................(     44) cycles   OK
ldi<r> (2)....................(     44) cycles   OK
neg...........................( 16,384) cycles   OK
<rrd,rld>.....................(  7,168) cycles   OK
<rlca,rrca,rla,rra>...........(  6,144) cycles   OK
shf/rot (<ix,iy>+1)...........(    416) cycles   OK
shf/rot (<ix,iy>-1)...........(    416) cycles   OK
shf/rot <b,c,d,e,h,l,(hl),a>..(  6,784) cycles   OK
<set,res> n,<bcdehl(hl)a>.....(  6,912) cycles   OK
<set,res> n,(<ix,iy>+1).......(    448) cycles   OK
<set,res> n,(<ix,iy>-1).......(    448) cycles   OK
ld (<ix,iy>+1),<b,c,d,e>......(  1,024) cycles   OK
ld (<ix,iy>-1),<b,c,d,e>......(  1,024) cycles   OK
ld (<ix,iy>+1),<h,l>..........(    256) cycles   OK
ld (<ix,iy>-1),<h,l>..........(    256) cycles   OK
ld (<ix,iy>+1),a..............(     64) cycles   OK
ld (<ix,iy>-1),a..............(     64) cycles   OK
ld (<bc,de>),a................(     96) cycles   OK
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.

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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.

[Joe G. (feinmechaniker)]

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.

[Joe G. (feinmechaniker)]

@ Leo C.

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

[Leo C. (rapid)]

Hallo Joe,

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

[Joe G. (feinmechaniker)]

Hallo Leo,

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

[Joe G. (feinmechaniker)]

Hier die Befehle für den TP Editor.

[Leo C. (rapid)]

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

[Joe G. (feinmechaniker)]

Perfekt!

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

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

[Peter Sieg (Gast)]

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

[Joe G. (feinmechaniker)]

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

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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

[Joe G. (feinmechaniker)]

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

[Peter Sieg (Gast)]

@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. (feinmechaniker)]

Den Mini gibt es als Arduino Pro Mini Enhancement (3.3V/5V 
adjustable)/16MHz MEGA328P-AU für 7,84€ inc. Versand.

[Peter Sieg (Gast)]

Jup:

http://www.ebay.de/itm/Arduino-Pro-Mini-Enhancement-3-3V-5V-adjustable-16MHz-MEGA328P-AU-/160762063172?pt=LH_DefaultDomain_0&hash=item256e2a6944#ht_1319wt_1139

Da fehlt dann aber ein USB Dongle..

Peter

[Hans- w. S. (hschuetz)]

Aber leider wieder aus China....Zoll und so....
Gruß
Hans -Werner

[Leo C. (rapid)]

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/

[Peter Sieg (Gast)]

@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

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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:

         +---------------------------------------------------------------------------------------+
Linear   |21 |20 |19 |18 |17 |16 |15 |14 |13 |12 |11 |10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
         +-----------------------+-------------------------------+-------------------------------+
 DRAM    |R C|R C|R C|R C|R C|R C|              Row              |              Col              |
         |  10   |   9   |   8   | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
         +---------------------------------------------------------------------------------------+
Ramdisk  |DSK 0-3|          Track 0-255          |   Sector 0-31     |       Byte 0-127          |
         +---------------------------------------------------------------------------------------+
Memory   | 1   1   1   1   1   1 |                       RAM-Adr. 0-65536                        |
         +---------------------------------------------------------------------------------------+

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:

  ;  Name   spt   bls  dks  dir  cks off
  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.

[Holger (Gast)]

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.

[Peter Sieg (Gast)]

Noch mal was abgefahrenes:

http://www.dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit

;-)

Peter

[Konrad S. (maybee)]

Peter Sieg schrieb:
> Noch mal was abgefahrenes:
>
> http://www.dmitry.co/index.php?p=./04.Thoughts/07....

Abgefahren? Ja, aber auf eine Art, vor der ich den Hut ziehe!

Jetzt fehlt nur noch, dass jemand mehrere ATmegas nimmt und damit ein 
Multi-Core-System aufbaut.

[Joe G. (feinmechaniker)]

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

[Jens (Gast)]

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

[Joe G. (feinmechaniker)]

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

[Markus G. (thechief)]

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

[Osche R. (Gast)]

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.

[Peter Sieg (Gast)]

Ram's V53C104P10L habe ich noch welche da.
Max. 20MHz und ggf. noch Wartezyklen..

Peter

[Leo C. (rapid)]

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.

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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"

[Jens K. (camenzind)]

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

[Peter Sieg (Gast)]

@Jens. Ja. Laufen 2 Sticks damit. Aber max. 20MHz.

Schicke mir ne Mail an peter.sieg1 (at) gmx (dot) de

Peter

[Joe G. (feinmechaniker)]

CP/M Lino

CP/M Shield für Arduino Pro Mini
- Größe 20 mm x 50 mm
- Mini USB B
- Micro SD
- 2 MB RAM

Wollen wir?

[Peter Sieg (Gast)]

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

[Joe G. (feinmechaniker)]

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

[Joe G. (feinmechaniker)]

Nachtrag:
16 RAM's habe ich derzeit. Eine Quelle ist auch hier:
http://www.demotronic.net/
Stückpreis 1,95€

[Hannes (Gast)]

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

[Joe G. (feinmechaniker)]

Hallo Hannes,

SD Card:
Deine SD Card mit Fat16 formatieren und dann die Imagefiles 
CPMDSK_A.IMG, CPMDSK_B.IMG und CPMDSK_C.IMG aus
http://www.mikrocontroller.net/articles/AVR_CP/M
auf die Karte kopieren.

AVR Binärfile:
Aktuelle Version von hier laden
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.0/
übersetzen und auf den AVR bringen.

Bei Fragen fragen.

Joe

[Jens K. (camenzind)]

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

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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.

[Joe G. (feinmechaniker)]

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.

[Leo C. (rapid)]

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.

[Peter Sieg (Gast)]

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 G. (feinmechaniker)]

War nur ein Vorschlag Peter...
ZSDOS Portieren ist ja auch eine nette Aufgabe.

Joe

[Peter Sieg (Gast)]

@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

[Leo C. (rapid)]

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.

[Hans G. (weakbit)]

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. (feinmechaniker)]

Gibt es eigentlich einen vernünftigen Grund warum wir beim CP/M mit dem 
62K Speichermodell arbeiten?

[Leo C. (rapid)]

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

[Leo C. (rapid)]

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]:

 "If the SUBMIT function is performed on any disk other than 
drive A, the commands are not processed until the disk is inserted 
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

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Um das zu änderen braucht man eine möglichst vollständige
> CPM-Distribution.

Ich habe mal das CCP und das BDOS von ZSDOS übersetzt und statt des 
CPM.SYS von sprite_tm eingesetzt. ZSDOS läuft nun auf unserem System. 
Jetzt müßte natürlich noch das BIOS angepaßt werden. Für alle die selbst 
mal damit experimentieren wollen:

cpm.bin - beinhaltet das neue ZSDOS
CCP.BIN - CCP Binärcode für das 62K Modell
ZSDOS.BIN - BDOS Binarcode für das 62K Modell
CCP.MAC - CCP Quelle
ZSDOS.MAC - BDOS Quelle
CPMDSK_A.IMG - Bootfile

Um cpm.bin zu bilden müssen bei dd die Speichermodelladressen 
berücksichtigt werden.
dd  conv=sync bs=128  count=1 if=ipl.bin > cpm.bin
dd  conv=sync bs=128 count=16 if=CCP.BIN >> cpm.bin
dd  conv=sync bs=128 count=28 if=ZSDOS.BIN >> cpm.bin
dd  conv=sync bs=128  count=6 if=bios.bin >> cpm.bin

Viel Spaß beim ausprobieren!
Joe

A>ddt
DDT VERS 2.2
-de400
E400 00 00 00 00 00 00 C3 9B E4 4C E7 4C E7 4C E7 4C .........L.L.L.L
E410 E7 F1 F1 00 00 6D DD F1 DD F1 DD F1 DD F1 DD F1 .....m..........
E420 DD F1 DD F1 00 00 17 01 00 00 00 00 00 00 80 00 ......;.........
E430 00 00 15 F5 7B F4 23 F5 32 F5 42 F5 1A 00 03 07 ....{.#.2.B.....
E440 00 F2 00 3F 00 C0 00 10 00 02 00 02 20 00 00 00 ...?............
E450 00 00 00 00 02 00 40 00 CD E3 00 0F 00 20 E4 20 ......@.........
E460 E4 A5 E3 5A 53 44 4F 53 20 31 2E 31 20 43 6F 70 ...ZSDOS 1.1 Cop
E470 79 72 69 67 68 74 20 28 63 29 20 31 39 38 37 2C yright (c) 1987,
E480 38 38 20 6F E5 BA E6 83 E6 6F E5 BA E6 83 E6 20 88 o.....o......
E490 00 20 E4 20 00 BB E8 E6 E7 00 00 AF 47 6F 67 22 ............Gog"
E4A0 4C E4 22 4E E4 ED 73 61 E4 31 9B E4 DD E5 D5 DD L."N..sa.1......
E4B0 E1 DD 22 5D E4 DD 22 5F E4 21 E6 E7 E5 79 32 4B .."].."_.!...y2K

[Joe G. (feinmechaniker)]

Und hier die Files

[Joe G. (feinmechaniker)]

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. (rapid)]

Joe, versuch's mal hiermit.

[Joe G. (feinmechaniker)]

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?

[Joe G. (feinmechaniker)]

@ Leo C.
Ok, es war ^Z

[Leo C. (rapid)]

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

[Joe G. (feinmechaniker)]

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

[Leo C. (rapid)]

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.