mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CP/M auf ATmega88


Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> unterstützten Controller zu vergrößern. Und eine zusätzliche
> DRAM-Variante gibts wahrscheinlich auch.
Da müssen wir mal sehen, wie wir meine Änderungen ins Repository 
bekommen.

> Und wenn Du die I2C-Verbindung
> AVR-Propeller richtig durchziehen willst, dann bekommen wir auch noch
> einen I2C-Multimaster-Treiber. :)
I2C müsste eigentlich schon gehen. Der Propeller bootet ja aus dem 
EEPROM und der AVR hängt via Pegelwandler auch an den I2C-Leitungen...

> Mit was programmierst Du?
Hardware: Mit einem selbstgebauten AVR910:
http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html
Software: avrdude, ich weiß aber gerade nicht in welcher Version.

>> Timer running. Elapsed: 005.021s.
> Timer running. Elapsed: 003.860s.
Ok, das passt. Der ATmega328 läuft ja auch mit 20 MHz, der ATmega128 mit 
16 MHz.

> A>8q
>
> Eight Queens. Running 2 iterations ...
> Timer running. Elapsed: 007.669s.
Hui. Ich musste mir erstmal 'ne Bedienungsanleitung für TP3 besorgen:
Running
Eight Queens. Running 2 iterations ...
Timer running. Elapsed: 010.383s.
Ein paar Prozentpunkte dürften sich noch rausholen lassen, wenn ich die 
Steuerleitungen für den RAM ändere.

> Vor einigen Monaten hatte ich auch mal mit Dhrystone experimentiert. Die
> Dateien und Ergebnisse muß ich mal suchen.
> Hier sind schon mal ein paar Links dazu:
Ich dachte eher an die Übersicht, wie schnell welcher Opcode simuliert 
wird. Naja, ist auch nicht wirklich wichtig.

Jetzt wird erstmal CP/M gelernt.

Grüße
Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Ich dachte eher an die Übersicht, wie schnell welcher Opcode simuliert
> wird. Naja, ist auch nicht wirklich wichtig.

Beitrag "Re: CP/M auf ATmega88"

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich habe die RTC mal ein bischen aufgepeppt.
Mit Turbo Pascal 3 kann man auch in der heutigen Zeit noch relativ gut 
programmieren, hätte ich nicht gedacht. Auch der eingebaute Editor ist 
ganz brauchbar (im Gegensatz zu ED...)
Im Anhang sind die ergänzten bzw. veränderten Programmteile.

Die Adresse der RTC musste ich auf 0x51 (read: 0xA3, write 0xA2) 
umstellen, da auf 0x50 schon der EEPROM vom Propeller liegt.

Wer den Code per copy&paste direkt ins Zielsystem bringen will, kann 
dafür sehr gut screen verwenden. Dazu muß man in screen die 
folgenden Befehle eingeben:
<ctrl> a : readbuf <filename>
<ctrl> a : slowpaste 30
<ctrl> a ]
Durch slowpaste wird das Einfügen so verzögern, das der Emulator 
hinterherkommt.

Viele Grüße
Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

es ist ja hier etwas ruhig geworden :-)
Über die Tage wollte ich mich mal wieder etwas mehr mit dem System 
auseinander setzen. Daher die Frage, ob sich evtl. schon 
"Verbesserungen" am Zusammenspiel AVR/Propeller hinsichtlich der 
VGA-Ausgabe ergeben haben.

Ansonsten schon mal frohes Fest und guten Rutsch!

Marcel

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel Andre schrieb:
> Daher die Frage, ob sich evtl. schon
> "Verbesserungen" am Zusammenspiel AVR/Propeller hinsichtlich der
> VGA-Ausgabe ergeben haben.
Ähm, ja. Ich hatte mir den Propeller-Code mal vorgenommen. Allerdings 
ist der noch nicht in einem vorzeigbaren Zustand.
Aber 38400 bps gingen dann ohne erkennbare Aussetzer. Hübsch wäre noch 
ein FIFO zwischen VT100-Dekoder und Steuercode-Execution.

Momentan will ich mir noch ein kleines TFT als Ausgabeeinheit dranbauen.
Ich weß nur noch nicht, ob am Propeller, am ATmega oder ob auf einem 
weiteren Controller.

Viele Grüße
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Aber 38400 bps gingen dann ohne erkennbare Aussetzer.

Konntest du einen Fehler eingrenzen?

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Konntest du einen Fehler eingrenzen?
Ich denke die vielen (zum Großteil unnötigen) if-Abfragen bremsen den 
Spin-Interpreter aus. Ich hab das mal auf (m.E.) übersichtlichere 
case-Konstrukte umgestellt.
Ich häng mal meine Version hier an.

Viele Grüße
Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

ich habe mir das gerade mal im Propeller-Tool angesehen auf die Schnelle 
und 2 Fragen:
- in der VT100 sehe ich immer noch viele IFs... ?
- wofür ist der "TV-Ausgang" genau?

Ich brutzel das nachher mal rein und berichte :-)

Danke und Gruß
Marcel

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blöde Frage - wo liegen im Moment die Sourcen?
http://cloudbase.homelinux.net/ ist irgendwie offline.
Habe ich was überlesen?

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Ich häng mal meine Version hier an.

Danke, ich schaue mir morgen mal die Änderungen an.

Marcel A. schrieb:
> - wofür ist der "TV-Ausgang" genau?

TV ist nicht notwendig und nicht bei uns implementiert. Ursprünglich war 
es für Debugzwecke vorgesehen.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> - in der VT100 sehe ich immer noch viele IFs... ?
Da mußt Du noch ein Stück runterscrollen.
An der PS/2-Verarbeitung habe ich nichts geändert (hoffentlich).

> - wofür ist der "TV-Ausgang" genau?
Dort habe ich mir debug-Ausgaben hingeschickt:
  other:
    debug.str( string("m1 not supported: "))
    debug.hex( remote, 2)
    debug.out( 13)

Welche Hardware verwendest Du? Ich habe mich ja beim 
Propeller-Terminal-Teil mehr am Parallax-Evaluationboard orientiert. 
Neben dem VGA-Ausgang gibt es dort noch eine Chinch-Buchse mit TV-Out.


Marcel A. schrieb:
> Ich brutzel das nachher mal rein und berichte :-)
Ich habe auch an der Videoauflösung rumgespielt. Es kann also sein, das 
Dein Ausgabegerät nicht synchronisiert, in diesem Fall stellst Du in der 
VGA_HiRes_Text_010.spin die Auflösung am Besten zurück auf 640x480 (in 
VGA_1024.spin muß dann noch rows angepasst werden.)


Viele Grüße,
Jens

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade gesehen, das mein Text etwas missverständlich klingen 
könnte:
Jens schrieb:
> Ich denke die vielen (zum Großteil unnötigen) if-Abfragen bremsen
Das 'unnötig' bezieht sich auf die Tatsache, das am häufigsten 'normale' 
Zeichen reinkommen. Nur wenn eine ESC-Sequenz vorkommt bzw. aktiv ist, 
muß diese interpretiert werden, nicht bei jedem Zeichen.

Viele Grüße
Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hier mal die ersten Ergebnisse.

Zunächst konnte ich das SPIN nicht compilieren. Das liegt wahrscheinlich 
am QuellCode - Jens arbeitet in ASCII und Joe in UniCode...
Im Editor vom Propeller (bei mir unter Windoof):
{{ for keyboard-de start }}

                        cmp     data,#de_ae     wz      'replace ae
        if_z            mov     data,#"ä"
                        cmp     data,#de_oe     wz      'replace oe
        if_z            mov     data,#"ö"
                        cmp     data,#de_ue     wz      'replace ue
        if_z            mov     data,#"ü"

Bei Joe:
{{ for keyboard-de start }}

                        cmp     data,#de_ae     wz      'replace ae
        if_z            mov     data,#"ä"
                        cmp     data,#de_oe     wz      'replace oe
        if_z            mov     data,#"ö"
                        cmp     data,#de_ue     wz      'replace ue
        if_z            mov     data,#"ü"
Klar - in Zeile 361 der keyb-DE bleibt er dann hängen. Also einfach Joes 
Datei genommen...


Danach nur Wirrwarr auf dem Bildschirm. Klar, Jens hatte auf 38400 
stehen, Joe auf 115200. Ändern - gut. (wow, ich habe mich an 
Propeller-Code gewagt haha...)

Und siehe da: Er scheint erst mal nichts mehr zu verschlucken!!!

Allerdings ist es immer noch nicht schön:
- Alles nur einfarbig - blauer Hintergrund, weiße Schrift
- Es kommt vor, dass der Cursor verschwindet (hängt wahrscheinlich mit 
Steuerzeichen aus TP zusammen)
- Ab und zu werden dauerhaft "!" ausgegeben...
- Editor in TP funktioniert nicht - die Eingabe ist wohl letztlich ok, 
aber die Darstellung kommt nicht hinterher - kein Scrolling, kein 
Einfügen sichtbar usw. Der Bildschirm wird nicht richtig aufgebaut.
- Scrollen klappt auch in WS nicht

Ergebnis: Die VT100 von Joe hat bei mir funktional besser geklappt. 
Vielleicht kann Joe die Timing-Optimierungen übernehmen, dann wäre es 
wahrscheinlich so perfekt, wie es unter CP/M sein kann, wo hinsichtlich 
Tastatur und Bildschirm jeder sein eigenen Standard definiert hat :-)

Danke an Jens!!!

Gruß
Marcel

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Marcel A. schrieb:
>> - in der VT100 sehe ich immer noch viele IFs... ?
> Da mußt Du noch ein Stück runterscrollen.
> An der PS/2-Verarbeitung habe ich nichts geändert (hoffentlich).
>
>> - wofür ist der "TV-Ausgang" genau?
> Dort habe ich mir debug-Ausgaben hingeschickt:
>
>   other:
>     debug.str( string("m1 not supported: "))
>     debug.hex( remote, 2)
>     debug.out( 13)
> 
>
> Welche Hardware verwendest Du?
Die Platine von Joe G

>Ich habe mich ja beim
> Propeller-Terminal-Teil mehr am Parallax-Evaluationboard orientiert.
> Neben dem VGA-Ausgang gibt es dort noch eine Chinch-Buchse mit TV-Out.
>
>
> Marcel A. schrieb:
>> Ich brutzel das nachher mal rein und berichte :-)
> Ich habe auch an der Videoauflösung rumgespielt. Es kann also sein, das
> Dein Ausgabegerät nicht synchronisiert, in diesem Fall stellst Du in der
> VGA_HiRes_Text_010.spin die Auflösung am Besten zurück auf 640x480 (in
> VGA_1024.spin muß dann noch rows angepasst werden.)
>
Das war kein Problem - aber mein TP-Programm, wo ich mit Farbe (gemäß 
Joes Implementierung) rumgespielt habe, zeigt keine Farbe mehr.
Liegt wohl daran, dass Joe einiges anders gemacht hat.

Aber wie gesagt - die Timing-Probleme scheinen hier nicht aufzutreten.
>
> Viele Grüße,
> Jens

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Das liegt wahrscheinlich
> am QuellCode - Jens arbeitet in ASCII und Joe in UniCode...
Jepp. Mit UniCode kommt mein diff-Tool nicht klar. Da hab ich 
konvertiert. Ich schau aber nochmal nach, ob es auch anders geht.

> Und siehe da: Er scheint erst mal nichts mehr zu verschlucken!
Bei 115200 im Propeller? Wenn das klappt, zieh ich meine Datenrate auch 
wieder hoch :-)

> - Alles nur einfarbig - blauer Hintergrund, weiße Schrift
Dafür muß man im Propellercode noch ein bissel mehr ändern.
Bisher gibt es dort keinen Speicher für die Farbe.
Leider ist der Code schon recht unübersichtlich (und m.E. auch ungünstig 
benannt), da machen Änderungen nicht so sehr viel Spaß.

> - Es kommt vor, dass der Cursor verschwindet (hängt wahrscheinlich mit
> Steuerzeichen aus TP zusammen)
Da müßte man mal auf die debug-Ausgabe schauen. Alles was er nicht 
kennt, sollte dort auftauchen.

> - Ab und zu werden dauerhaft "!" ausgegeben...
Das klingt nach einer verschluckten seriellen Schnittstelle.

> - Editor in TP funktioniert nicht - die Eingabe ist wohl letztlich ok,
> aber die Darstellung kommt nicht hinterher - kein Scrolling, kein
> Einfügen sichtbar usw. Der Bildschirm wird nicht richtig aufgebaut.
Bei mir ließ sich TP ganz gut bedienen. Kann aber auch an 38400 <-> 
115200 liegen.

> - Scrollen klappt auch in WS nicht
WS habe ich noch nicht verwendet. Der ist mir zu krude zum Bedienen.

Marcel A. schrieb:
>> Welche Hardware verwendest Du?
> Die Platine von Joe G
Da gibt es kein TV-Out. Schade um die ungenutzten Pins.

> Liegt wohl daran, dass Joe einiges anders gemacht hat.
Ich wollte den Code lesbarer formulieren. Außerdem hab ich versucht mich 
an die Spec zu halten (Links im Code). Es kann gut sein, das nicht alles 
100%ig identisch implementiert wurde.

Aber wir wollen ja auch im nächsten Jahr noch was zum Basteln haben :-;

Viele Grüße,
Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja prima.

ich arbeite übrigens immer noch mit der CPM Version 204... Hat jemand 
mal ein neueres, laut Leo ist das ja uralt? Ich finde leider derzeit die 
SVN-Quellen nicht... wo liegen die denn aktuell?

Dann könnte ich mal versuchen, die selber zu übersetzen (oh weh...) und 
auf 57600 gehen... denn das 204er Image von Joe hat 115200.

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Marcel, vielen Dank für's Testen!

Ich hab nochmal nachgeschaut: Mea cupla.
Irgendwas hab ich am Code kaputtoptimiert :-(
Z.B. wurden Parameter nicht richtig interpretiert.

Die Farbe (ESC[xx;xxm) müsste jetzt wieder gehen. Aber immer nur für den 
kompletten Bildschirm.

2. Problem: Scrollen
Das Problem kann ich hier nachvollziehen, aber nicht so richtig 
debuggen.
Wenn ich den Debug-Output aktiviere, schmiert der Propeller ab.
Weiß jemand, welche Sequenzen der Editor von TURBO.COM beim 
Runterscrollen schickt?
Damit könnte ich gezielter suchen.
(Das Hochscrollen klappt übrigens...)

In Joe's Code wird ESC[L und ESC[M interpretiert. Das hab ich in keinem 
Standard gefunden, aber in dieser Version wieder mit reingenommen.

Die Baudrate hab ich jetzt sowohl im AVR, als auch im Propeller auf 
115200 gesetzt. Bis auf das Scrollproblem sehe ich keine Fehler.

Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von 
bold auf dem Propeller-Terminal hat. Bisher sieht es in der 
Linux-Konsole besser aus, als auf dem Terminal.

Außerdem hab ich noch mein ANSI-Testprogramm angehangen. Das darf gern 
erweitert werden :-)
Momentan kann es mehr als unser VT100/ANSI-Emulator.

Ich wünsche allen einen
Guten Rutsch!
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wünsche allen ein gesundes neues jahr!

Jens schrieb:
> In Joe's Code wird ESC[L und ESC[M interpretiert. Das hab ich in keinem
> Standard gefunden, aber in dieser Version wieder mit reingenommen.

Eine Übersicht über die gebräuchlisten Codes findet man hier [1].
Alle derzeit implementierten Codes stehen in der Doku [2] zum VT100 
Terminal.
Ein guter Test ist tatsächlich WS. Dort wird sehr intensiv Gebrauch von 
den gängisten Sequenzen gemacht. WS sollte also in jedem Fall laufen.
Einen Bufferüberlauf kann man sehr gut mit einer gesendeten Testdatei 
einer ganz bestimmten Länge testen. Das merkwürde ist. Beim ERSTEN 
Senden gibt es keine Probleme mit jeder Baudrate. Eine beliebig lange 
Datei wird fehlerfrei gesendet und schnell korrekt dargestellt. Erst 
beim zweiten Versuch tritt der Fehler auf das Zeichen "verschluckt" 
werden, übrigens dann bei jeder Baudrate. Deshalb auch mein Verdacht, an 
einer Stelle wird der Bufferzeiger flasch überschrieben.
Gruß Joe



[1] http://www-user.tu-chemnitz.de/~heha/hs/terminal/terminal.htm
[2] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/manual/

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

hier wie versprochen die Ergebnisse der Tests der letzten VT100 von 
Jens:

- FarbCode scheinen zumindest bei meinem Testprogramm ok (habe ansitest 
noch nicht probiert)
- Inversdarstellung ok - z.B. bei WS
- TP: Sieht gut aus, auch Zeile einfügen, was aber (wie erwähnt) nicht 
geht ist "runterscrollen", während raufscrollen geht (das war früher 
auch nicht besser glaube ich)
- TP: Nach Beenden von TP kann ich keine großen Buchstaben mehr eingeben 
(shift geht nicht) - daher auch kein Laufwerkswechsel möglich. 
Propeller-Reset hilft (das war aber früher auch schon so glaube ich).
- WS: sieht gut aus - aber genau wie TP kein runterscrollen. Weitere 
Tests aber nicht möglich, da WS/AVR/... beim Ankommen am unteren 
Bildschirm abstürzt

Sonstiges:
- nach wie vor kommen irgendwann nur noch "!" und sonstiger Müll als 
Phantomeingabe... da hilft auch kein Propeller-Reset (das war früher 
nicht so)
- Auch in TP "stürzt" das ganze schon mal ab - keine Reaktion, keine 
Anzeige... Nur Power off hilft (war früher auch nicht so).

Subjektive Zusammenfassung:
- Das "Verschluck-Problem", was bei mir immer am Anfang/Start auftrat, 
ist offenbar weg - somit hier offenbar deutliche Verbesserung
- Die sonstigen "früheren" Probleme (Scrollen, Shift...) sind wohl noch 
da.
- Einige Instabilitäten sind dazugekommen, meine ich (Abstürze, Dauer 
"!")

Ich würde es gerne mal mit 57600 Bd ausprobieren. Aber leider habe ich 
keinen aktuellen QuelleCode (ich arbeite mit V3.2 204).
Wo ist denn der Link geblieben oder hat jemand mal ein "aktuelles" Hex 
mit 57600 und 115200 Baud?

Danke!



P.S.:"Früher" meint Joe's V1.0

Autor: Andreas G. (dd2ag)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß, die Frage kommt ziemlich (zu?) spät: aber gibt es noch die 
Möglichkeit, hier über ein Forenmitglied an eine fertige, unbestückte 
Platine zu kommen? Oder sind alle Bestände schon abverkauft?

Gruß,

Andreas

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Gruttmann schrieb:
> Ich weiß, die Frage kommt ziemlich (zu?) spät: aber gibt es noch die
> Möglichkeit, hier über ein Forenmitglied an eine fertige, unbestückte
> Platine zu kommen?

Es gibt noch genau EINE unbestückte Platine (letzte Version VGA + CP/M).

Marcel A. schrieb:
> Das "Verschluck-Problem", was bei mir immer am Anfang/Start auftrat,
> ist offenbar weg

Ich habe gerade mal getestet. Das Problem liegt in der 
FullDuplexSerial.spin, es kommt zu einem Pufferüberlauf. Mal sehen ob 
ich den Fehler unproblematisch beheben kann.

Marcel A. schrieb:
> Wo ist denn der Link geblieben oder hat jemand mal ein "aktuelles" Hex
> mit 57600 und 115200 Baud?

Ich lade mal morgen die aktuelle Version hier [1] hoch.

Schönen Abend!
Joe


[1] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich lade mal morgen die aktuelle Version hier [1] hoch.

Prima. Aber da liegen ja nur die Propeller-Dateien. Wo liegen denn die 
AVR Dateien?

>
> Schönen Abend!
> Joe
>
>
> [1] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Wo liegen denn die AVR Dateien?

Auf meinem Server. ;)
Leider hat DYN.COM vor ein paar Wochen meinen Hostnamen ohne Vorwarnung 
gelöscht. Der Server deshalb unter dem alten Namen nicht mehr 
erreichbar.

Die aktuelle Version habe ich mal hier angehängt. Änderungen gab es 
zuletzt nur im I2C-Treiber. Später mehr.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Leo C.
Wollen wir die aktuellen Daten mal im Mikrocontroller svn 
zusammenführen?

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Wollen wir die aktuellen Daten mal im Mikrocontroller svn
> zusammenführen?
Da wäre ich auch dafür. Ich würde mir sogar ein Login holen, damit ich 
mal meinen Code als branch einchecken kann.

Viele Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens
Ich habe nun mal deinen Code getestet. die Sequenz ESC[J (Bildschirm 
löschen) ist fehlerhaft. Außerdem produziert dein Code den gleichen 
Bufferüberlauf bei langen Datein.
Joe

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei, mir das MakeFile für AVRCPM anzupassen. AVR Studio 
6 hat eine ganz andere Verzeichnis-Struktur bei mir angelegt...

Vorab habe ich noch mal TP und WS mit der Terminal-Ausgabe getestet.
TP läuft soweit ich sehen kann problemlos.
WS scrollt auch hier nicht richtig... Wenn man in der letzten Zeile 
ankommt, schreibt man da immer weiter (kein Scrolling), auch wenn der 
Zeilenzähler hochzählt. Letztlich stimmt das Ergebnis, aber komisch 
ausschauen tut es schon... Liegt das an meinem WS (Image von Joe)?

Gruß
Marcel

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Wollen wir die aktuellen Daten mal im Mikrocontroller svn
> zusammenführen?

Das hatten wir ja vor fast einem Jahr schonmal angedacht. Damals wollte 
ich allerdings das komplette Repository mit der ganzen History 
transferieren. Dazu hätte man ein Dump des Repos auf dem hiesigen Server 
einspielen müssen. Leider hat der Admin (Andreas Schwarz) nicht auf 
meine Anfrage geantwortet.

Jens schrieb:
> Da wäre ich auch dafür. Ich würde mir sogar ein Login holen, damit ich
> mal meinen Code als branch einchecken kann.

Das hättest Du natürlich auch auf meinem Server tun können...

Was spricht denn dagegen, das Repo auf git zu konvertieren, und dann auf 
GitHub oder einem ähnlichen Server zu installieren?

Ansonsten könnte ich den aktuellen Stand auf den mikrocontoller.net 
SVN-Server kopieren. Die avrvga-Software von Frank Zoll natürlich auch.


Das alte Repo ist jetzt erstmal hier zugänglich:
http://cloudbase.mooo.com/viewvc/avr-cpm/

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Marcel A. schrieb:
>> Wo liegen denn die AVR Dateien?
>
> Auf meinem Server. ;)
> Leider hat DYN.COM vor ein paar Wochen meinen Hostnamen ohne Vorwarnung
> gelöscht. Der Server deshalb unter dem alten Namen nicht mehr
> erreichbar.
>
> Die aktuelle Version habe ich mal hier angehängt. Änderungen gab es
> zuletzt nur im I2C-Treiber. Später mehr.


Meldet sich als
CPM on an AVR, v3.2 r216M
Ist das richtig? Im ZIP steht 221...

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das VT100 Terminalprogramm sollte nun mit 115200 fehlerfei 
funktionieren. Es gab im Test (auch mit sehr langen Textdatein) keine 
Fehler mehr. Die FullDuplexSeriel.spin. war noch fehlerhaft. Außerdem 
habe ich noch die Initialisierung etwas geändert. Ich habe alle 
Änderungen im SVN hochgeladen.


Marcel A. schrieb:
> Meldet sich als
> CPM on an AVR, v3.2 r216M

Ist wohl korrekt, steht so in der config.asm

Leo C. schrieb:
> Ansonsten könnte ich den aktuellen Stand auf den mikrocontoller.net
> SVN-Server kopieren. Die avrvga-Software von Frank Zoll natürlich auch.

Das wird wohl die beste Lösung sein.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> CPM on an AVR, v3.2 r216M
> Ist das richtig?

Nicht ganz.

> Im ZIP steht 221...

Die Datei snvrev.inc wurde seit r216 nicht mehr eingecheckt (Fehler 
meinerseits). Die Datei sollte bei jedem Build neu erzeugt werden (Das 
Programm dazu findet man hier: http://www.compuphase.com/svnrev.htm).
Allerdings macht das nur dann Sinn, wenn man mit einer aus dem SVN 
ausgecheckten Arbeitskopie arbeitet.

Hier die letzten Änderungen, die aller in dem geposteten Zip-File sind:
 r221 | leo | 2013-11-16 14:14:02 +0100 (Sa, 16. Nov 2013) | 1 Zeile
Geänderte Pfade:
   D /avrcpm/trunk/avr/adc.asm

* fixed previous commit
------------------------------------------------------------------------
r220 | leo | 2013-11-16 14:03:47 +0100 (Sa, 16. Nov 2013) | 6 Zeilen
Geänderte Pfade:
   A /avrcpm/trunk/avr/adc.asm
   M /avrcpm/trunk/avr/config.inc
   M /avrcpm/trunk/avr/i2c.asm
   M /avrcpm/trunk/avr/init.asm
   M /avrcpm/trunk/avr/svnrev.inc
   M /avrcpm/trunk/avr/sw-uart.asm
   M /avrcpm/trunk/avr/timer.asm
   M /avrcpm/trunk/avr/utils.asm
   M /avrcpm/trunk/avr/virt_ports.asm

* I2C driver enhancements:
  - Doesn't hang on bus errors (Misbehaving slave).
  - Returns meaningful status codes.
  - Returns number of bytes actually transmitted/received.
  - config option 'I2C_STATE_DEBUG'
* 'MEMDUMP_DEBUG'
------------------------------------------------------------------------
r219 | leo | 2013-05-09 12:43:53 +0200 (Do, 09. Mai 2013) | 1 Zeile
Geänderte Pfade:
   A /avrcpm/tags/3.2.1 (von /avrcpm/trunk:218)

Tag for Version 3.2.1 (IPL.MAC bugfix)
------------------------------------------------------------------------
r218 | leo | 2013-05-09 12:40:18 +0200 (Do, 09. Mai 2013) | 3 Zeilen
Geänderte Pfade:
   M /avrcpm/trunk/cpm/IPL.MAC

* cpm/IPL.MAC
  - local definition for cr/lf
  - use port 1 (UARTDR) instead of port 2 (deprecated) for console output.
------------------------------------------------------------------------
r217 | leo | 2013-05-01 20:57:11 +0200 (Mi, 01. Mai 2013) | 1 Zeile
Geänderte Pfade:
   A /avrcpm/tags/3.2 (von /avrcpm/trunk:216)

Tag for Version 3.2
------------------------------------------------------------------------
r216 | leo | 2013-05-01 20:47:41 +0200 (Mi, 01. Mai 2013) | 6 Zeilen
Geänderte Pfade:
   M /avrcpm/trunk/avr/Makefile
   M /avrcpm/trunk/avr/Z80int-jmp.asm
   M /avrcpm/trunk/avr/avrcpm.asm
   M /avrcpm/trunk/avr/config.inc
   M /avrcpm/trunk/avr/dsk_fat16.asm
   M /avrcpm/trunk/avr/dsk_fsys.asm
   M /avrcpm/trunk/avr/dsk_mgr.asm
   M /avrcpm/trunk/avr/init.asm
   M /avrcpm/trunk/avr/macros.inc
   M /avrcpm/trunk/avr/svnrev.inc
   M /avrcpm/trunk/avr/utils.asm
   M /avrcpm/trunk/avr/virt_ports.asm
   M /avrcpm/trunk/cpm/BIOS.MAC
   M /avrcpm/trunk/cpm/CFGACPM.LIB

* cpm/BIOS.MAC
  - conin/const: Use function 'uartstat' (port 3) instead of 'constat' (port 0). constat will be removed soon.
* avr/virt_ports.asm
  - Mark 'constat' as deprecated.
* avr/*
  - More lds/sts --> ldd/std changes.
------------------------------------------------------------------------

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Ich wünsche allen ein gesundes neues jahr!

Diesem Wunsch schließe ich mich gerne an, auch wenn er für mich gestern 
zu spät kam. Mir gings nämlich gar nicht gut. Ich konnte mich kaum auf 
dem Stuhl halten. An exzessivem Feiern kann es aber nicht gelegen 
haben...

Seit heute wirkt der Wunsch aber. Danke Joe.


Jens schrieb:
> Weiß jemand, welche Sequenzen der Editor von TURBO.COM beim
> Runterscrollen schickt?
> Damit könnte ich gezielter suchen.

Auch wenn die Frage inzwischen erledigt ist.
Mit TINST.COM kann man nachsehen, wie das Terminal configuriert ist.
Das hatte ich gestern gemacht, aber nicht mehr geschafft, das Ergebnis 
abzuschicken.
Terminal type: ANSI 
Send an initialization string to the terminal? (Y/N)?  N 
Send a reset string to the terminal (Y/N)?  Y 
Command: <ESC> [ 0 m   (27 91 48 109)  
CURSOR LEAD-IN command:  <ESC> [   (27 91)  
CURSOR POSITIONING COMMAND to send between line and column:    ;   (59)  
CURSOR POSITIONING COMMAND to send after both line and column: H   (72)  
Column first (Y/N)?  N 
OFFSET to add to LINE:   1 
OFFSET to add to COLUMN: 1 
Binary address (Y/N)?  N 
Number of ASCII digits (2 or 3):  2 
CLEAR SCREEN command:  <ESC> [ 2 J   (27 91 50 74)  
Does CLEAR SCREEN also HOME cursor (Y/N)?  N 
HOME command:  <ESC> [ H   (27 91 72)  
DELETE LINE command:  <ESC> [ 1 M   (27 91 49 77)  
INSERT LINE command:  <ESC> [ 1 L   (27 91 49 76)  
ERASE TO END OF LINE command: <ESC> [ K   (27 91 75)  
START HIGHLIGHTING command:   <ESC> [ 1 m   (27 91 49 109)  
END HIGHLIGHTING command:     <ESC> [ 0 m   (27 91 48 109)  
Number of rows (lines) on your screen:  24 
Number of columns on your screen:       80 
Delay after CURSOR ADDRESS (0-255 ms):                      0 
Delay after CLEAR, DELETE and INSERT (0-255 ms):            0 
Delay after ERASE TO END OF LINE and HIGHLIGHT (0-255 ms):  0 
Is this definition correct? (Y/N)?  N


> Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von
> bold auf dem Propeller-Terminal hat. Bisher sieht es in der
> Linux-Konsole besser aus, als auf dem Terminal.

Dazu müßte man wohl einen 2. Font haben. Keine Ahnung, ob das möglich 
ist.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergisst das... WS ist noch auf 40/43 Zeilen eingestellt - das passt 
natürlich nicht zu 25 Zeilen im Terminal...

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Terminialprogramm hat doch 40 Zeilen. Außerdem kann ja WS auch auf 
eine andere Zeilenzahl konfiguriert werden. Installationen gibt es hier:
Beitrag "Re: CP/M auf ATmega88"
Beitrag "Re: CP/M auf ATmega88"

Jens schrieb:
> Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von
> bold auf dem Propeller-Terminal hat. Bisher sieht es in der
> Linux-Konsole besser aus, als auf dem Terminal.

Dazu müßte in der VGA_HiRes_Text_010.spin ein zweiter Zeichensatz 
implementiert werden. Wie das geht kann hier: VGA_HiRes_Text.spin 
entnommen werden, oder wie Leo C. zu sagen pflegt: Freiwillige vor.

: Bearbeitet durch User
Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Das Terminialprogramm hat doch 40 Zeilen.

Richtig. Daran hab ich den Fehler ja auch erkannt :-)

> Außerdem kann ja WS auch auf
> eine andere Zeilenzahl konfiguriert werden. Installationen gibt es hier:
> Beitrag "Re: CP/M auf ATmega88"
> Beitrag "Re: CP/M auf ATmega88"
>
> Jens schrieb:
>> Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von
>> bold auf dem Propeller-Terminal hat. Bisher sieht es in der
>> Linux-Konsole besser aus, als auf dem Terminal.
>
> Dazu müßte in der VGA_HiRes_Text_010.spin ein zweiter Zeichensatz
> implementiert werden. Wie das geht kann hier: VGA_HiRes_Text.spin
> entnommen werden, oder wie Leo C. zu sagen pflegt: Freiwillige vor.


Habe jetzt die neue VT100 SPIN drin - WS läuft, aber TP scrolled immer 
noch nicht richtig. Timing scheint ok zu sein - weitere Tests morgen.
Besuch vor der Tür.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen zusammen,

so, hier die Ergebnisse meiner Tests.

Versionen:
AVRCPM "221"
VGA: Rev 85

Unter Windows/Teraterm (Terminal, 40 Zeilen):
- WS ok (da müsste ich mir evtl. die Tastatuscodes noch anpassen, das 
ist ja an sich ein buchfüllendes Thema)
- TP ok (scrollen etc.). Der Code wird in der einen Version (DISK B) 
leider invertiert dargestellt... In der Version  DISK F ist das wie 
bekannt besser mit Gelb auf Schwarz und weißen Menüs. Leide kann man ja 
nicht auslesen, WELCHEN der 32 Screen-Emulationen hier verwendet wird...

Unter Propeller:
- keine Timingprobleme oder Müllzeichen festgestellt -> SUPER!
- WS ok (siehe oben, auch scrollen)
- TP "fast" ok: Auch hier die inverse Darstellung wie im Bild (DISK B) 
und eine Darstellung ohne Attribute mit DISK F (da der Propeller ja wie 
beschrieben wohl nur 2 Farben + Invers unterstützt). Ich habe noch keine 
Option gefunden, dass der Editor den Text dann "flach" darstellt ohne 
Attribute)
- ABER: Scrollen nach unten klappt nicht (beide Versionen) - man sieht 
das auf dem Bild - die untere Zeile wird immer mit der aktuellen Zeile 
gefüllt. aber der Bildschirm/Text rutscht nicht rauf. Gleiches 
Verhalten, wenn man die Steuercodes für ScrollDown drückt. ScrollUp geht 
dann wieder.
- Manchmal (nicht wirklich reproduzierbar) akzeptiert das System nach 
dem Verlassen von TP oder WS die shift-Taste nicht mehr. Vermutlich 
liegt das an irgendwelchen Steuercodes. Propeller-Reset hilft.

Ich bin mir nicht sicher, ob Scrollen früher mal geklappt hat. Glaube 
aber nicht.

So, das wars erst mal von der Front :-)

Gruß
Marcel

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer mag, kann nun auch die deutschen Umlaute ö,ä,ü und ß verwenden. Dazu 
muß in der VGA_1024.spin der deutsche Zeichensatz geladen werden. Leider 
ist in diesem Fall WS oder TP noch nicht richtig zu benutzen, da hier im 
deutschen Zeichensatz noch die entsprechenden Standardzeichen 
eingetragen werden müssen (macht etwas Arbeit).

@Marcel
Vielen Dank für den Test!
Zu Invers oder Bold hatte ich ja schon was gesagt, hier müßte der 
Zeichensatz implementiert werden.

In der TINST.COM werden die Steuerkommandos für das Terminal und auch 
die Tastatur festgelegt. So habe ich z.B. für das "Start highlighting" 
den Code ESC[7m (invers) eingetragen, "Bold" gibt es ja noch nicht. 
Weiterhin sind dort die Editorkommandos festgelegt. Wenn also eine ESC 
Sequenz verwendet wird, die bei uns noch nicht implementiert ist, dann 
geht die Ausführung schief. Beim schnellen Überfliegen habe ich z.B. 
ESC[H und ESC[f (Cursor home) entdeckt. Diese Codes sind noch nicht 
implementiert (muß ich noch nachtragen).

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Eine Übersicht über die gebräuchlisten Codes findet man hier [1].
Ok. Es gibt sicher hübschere Übersichten, aber lass uns die von heha 
verwenden.

Marcel A. schrieb:
> TP: Nach Beenden von TP kann ich keine großen Buchstaben mehr eingeben
> (shift geht nicht) - daher auch kein Laufwerkswechsel möglich.
Das Problem kann ich nicht nachvollziehen.

> nach wie vor kommen irgendwann nur noch "!" und sonstiger Müll als
> Phantomeingabe...
Dieses Problem kann ich auch nicht nachvollziehen.

Von wo kommen Deine Eingaben? Vielleicht gibt es Unregelmäßigkeiten beim 
PS/2-Protokoll?

Joe G. schrieb:
> @Jens
> Ich habe nun mal deinen Code getestet. die Sequenz ESC[J (Bildschirm
> löschen) ist fehlerhaft.
Inwiefern?
Es gibt einen Parameter für ESC[J:
ESC[J oder ESC[0J  Löschen vom Kursor nach rechts und bis zum Bildende
ESC[1J             Löschen vom Bildanfang und von links bis zum Kursor
ESC[2J             Löschen des Bildschirms
Bei meinen Tests hat das hervorragend funktioniert.

> Außerdem produziert dein Code den gleichen
> Bufferüberlauf bei langen Datein.
Kein Wunder, ich verwende ja auch die unveränderte 
FullDuplexSerial.spin.

Joe G. schrieb:
> Ich habe alle
> Änderungen im SVN hochgeladen.
Dummerweise kann man wegen der komischen Dateikodierung von den 
wichtigsten Dateien kein Diff machen :-(
Als Beispiel siehe hier:
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga/VT100_VGA.spin?r1=86&r2=88

Leo C. schrieb:
> Mit TINST.COM kann man nachsehen, wie das Terminal configuriert ist.
Ah. TINST hatte ich noch nicht ausprobiert.
Wobei zum Scrollen ja nichts weiter drinsteht. Immerhin kann man die 
Markierung auf invers konfigurieren, bis es einen bold-Font gibt.

Joe G. schrieb:
> Das Terminialprogramm hat doch 40 Zeilen
Deins vielleicht. Ich hab mir noch ein paar weitere VGA-Modi (80x32 und 
80x28) definiert, damit die Schrift nicht so gequetscht aussieht.

Joe G. schrieb:
> Beim schnellen Überfliegen habe ich z.B.
> ESC[H und ESC[f (Cursor home) entdeckt. Diese Codes sind noch nicht
> implementiert (muß ich noch nachtragen).
In meinem Code sind sie drin. Auch das Nachtragen geht dort leichter...

Viele Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Editor von Turbopascal sollte nun gehen. Es gab noch einen Bug bei 
ESC[M.
@Jens wenn du diesen Fehler übernommen hattest, bitte die Korrektur 
übernehmen.


Jens schrieb:
> Dummerweise kann man wegen der komischen Dateikodierung von den
> wichtigsten Dateien kein Diff machen :-(

geht doch ?
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga/VGA_1024.spin?r1=87&r2=90

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Dummerweise kann man wegen der komischen Dateikodierung von den
> wichtigsten Dateien kein Diff machen :-(
> Als Beispiel siehe hier:
> 
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga/VT100_VGA.spin?r1=86&r2=88

An der Kodierung scheints nicht zu liegen. Imho verwendet man für sowas 
aber sowieso nicht das viewvc-Provisorium, sondern einen anständigen 
SVN-Clienten mit eingebautem oder externem Diff-Tool. Unter Windows z.B. 
Tortoise SVN (s. Anhang für mitgeliefertes Diff). Auch Meld 
(http://meldmerge.org/) hat keine Probleme mit utf-16.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Marcel A. schrieb:
>> TP: Nach Beenden von TP kann ich keine großen Buchstaben mehr eingeben
>> (shift geht nicht) - daher auch kein Laufwerkswechsel möglich.
> Das Problem kann ich nicht nachvollziehen.
Passiert(e) ab und zu beim Beenden von TP - ist aber nicht schlimm.
>
>> nach wie vor kommen irgendwann nur noch "!" und sonstiger Müll als
>> Phantomeingabe...
> Dieses Problem kann ich auch nicht nachvollziehen.
Hat sich ja inzwischen erledigt.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe gerade die Rev 91 der VT100.SPIN getestet.
Hatte mir erst mal eine IDE für den Propeller unter Linux installiert - 
war es leid, immer zum anderen PC zu rennen.

Was soll ich sagen: Der Editor läuft unter TP! SUPER!


Folgendes habe ich noch:
- Ab und zu (manchmal reproduzierbar wenn ich den TP-Editor verlasse und 
auf die DOS-Ebene gehe) geht shift nicht mehr. Wenn aber nur ich das 
Problem habe - egal.
- Ab und zu stehen merkwürdige "@" im Quelltext/Display. Die 
verschwinden aber beim scrollen und sind nicht im File enthalten - auch 
eher geringes Problem
- Wer verrät mir, wie ich in TP/TPINST einstelle, dass der Quelltext 
nicht invertiert dargestellt wird (siehe Bild in einem der letzten 
Posts). Irgendwie muss das gehen, denn eine andere TP-Version macht das 
nicht (die schreibt im Terminal aber auch gelben Text auf schwarz und 
weiße Menüs), die erscheint im Propeller überall grün auf schwarz

@Jens: Aus dem Aufbau deiner Farb-Testroutine am Ende von ansitest.pas 
vermute ich, dass die nur für Terminalbetrieb gedacht ist, da sie ja 
alle Kombinationen "durchrattert" und das daher auf dem Probeller (der 
kennt die Attribute ja nur für den ganzen Bildschirm) dann mit weißer 
Schrift auf weißem Hintergrund endet? Propeller-Reset hilft :-) Habe mal 
ein paar readln eingebaut.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@alle
Um mit einem "Bold" Zeichensatz zu arbeiten, müßte die 
"Inversdarstellung" rausgenommen werden. Es gibt ja nur 8 Bit für jedes 
Zeichen. Mit dem 8 Bit (derzeit für invers zuständig) könnte man nun auf 
den zweiten Zeichensatz umschalten. Was meit ihr, lieber "invers" oder 
lieber "bold"?
Wenn "bold" wie sollten wir den Zeichensatz pixeln? In der angehängten 
Quelle habe ich dazu alles vorbereitet. Mit der Sequenz ESC[7m schaltet 
man nun auf den zweiten Zeichensatz um. Da ich den ersten Zeichensatz 
nur umkopiert habe, ist die Darstellung natürlich noch identisch. Hier 
müßte nun die Arbeit beginnen. Es sind die drei Blöcke von $80 bis $F8 
die bearbeitet werden müssen.


Marcel A. schrieb:
> - Ab und zu (manchmal reproduzierbar wenn ich den TP-Editor verlasse und
> auf die DOS-Ebene gehe) geht shift nicht mehr. Wenn aber nur ich das
> Problem habe - egal.

Das schau im mir mal an.

Marcel A. schrieb:
> Wer verrät mir, wie ich in TP/TPINST einstelle, dass der Quelltext
> nicht invertiert dargestellt wird

Bei TINST.COM in der Terminalkonfiguration VT100 das "Start 
highlighting" abschalten, also ESC[7m rausnehmen.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Leo C. schrieb:
>> Ansonsten könnte ich den aktuellen Stand auf den mikrocontoller.net
>> SVN-Server kopieren. Die avrvga-Software von Frank Zoll natürlich auch.
>
> Das wird wohl die beste Lösung sein.

Da sich mein Vorschlag, das Repository auf Git umzustellen, leider nicht 
durchgesetzt hat, ist die AVR-CP/M Software ab sofort auf
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
bzw. svn://mikrocontroller.net/avr-cp-m
zu finden.

Die Historie ist bis auf weiteres noch hier zu erreichen:
http://cloudbase.mooo.com/viewvc/avr-cpm (Browser)
bzw. http://cloudbase.mooo.com/svn/avr-cpm (SVN-Client)

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei etwas zum Testen. Die ESC-Sequenz "Invers" schaltet nun auf einen 
anderen Zeichensatz. In TP an den Menübuchstaben zu erkennen.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VT100-Terminal

Die neue Version ist eingecheckt. Der Nutzer kann nun zwischen drei 
Varianten auswählen.

1. Zeichensatz mit deutschen Umlauten
2. Zeichensatz mit inverser Darstellung
3. zwei Zeichensätze

Die Auswahl erfolgt in der VGA_1024.spin

OBJ
' vga : "vga_Hires_Text_German"    'with German letters ä,Ä,ö,Ö,ü,Ü,ß
' vga : "vga_Hires_Text_Invers"    'with inverse letters
 vga : "vga_Hires_Text_Double"    'with second character font

Wer es in Betrieb testen möchte, kann mittels der Tastenkombination 
"Alt+i" den aktuellen Zeichesatz umschalten.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wir (Dank an Leo C. für die Hinweise) haben mal ein kleines RAM-Modul 
für das CP/M-System entworfen. Es hat die folgenden technischen Daten:
- Softwarekompatibel zum bisherigen System,
- 3.3V oder 5V,
- 512K SRAM (verfügbar),
- in 64K Bänken linear adressierbar,
- steckbar DIL-18 polig
Was meint ihr? Würde damit das CP/M-System für potentielle Interessenten 
lukrativer?
Gruß Joe

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn der Vorteil/Unterschied zu dem RAM-Baustein, der bisher auf 
deinem Board verbaut ist?

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Hatte mir erst mal eine IDE für den Propeller unter Linux installiert -
> war es leid, immer zum anderen PC zu rennen.
Hast Du da mal einen Link?
Ich würde den Propeller auch viel lieber unter Linux programmieren.

Marcel A. schrieb:
> @Jens: Aus dem Aufbau deiner Farb-Testroutine am Ende von ansitest.pas
> vermute ich, dass die nur für Terminalbetrieb gedacht ist, da sie ja
> alle Kombinationen "durchrattert" und das daher auf dem Probeller (der
> kennt die Attribute ja nur für den ganzen Bildschirm) dann mit weißer
> Schrift auf weißem Hintergrund endet? Propeller-Reset hilft :-) Habe mal
> ein paar readln eingebaut.
Ich habe sie zumindest im Terminal getestet. Vielleicht schaffen wir es 
ja im Propeller noch einen Attribute/Farbspeicher pro Zeichen zu 
implementieren. Schade, das sich der Propeller nicht so richtig gut 
debuggen läßt.

Joe G. schrieb:
> lieber "invers" oder
> lieber "bold"?
Lieber bold. Aber noch lieber Beides :-)
Deutsche Umlaute halte ich dagegen für überflüssig. Damit fängt man sich 
die Zeichensatzprobleme von MS-DOS ein.

Joe G. schrieb:
> Was meint ihr? Würde damit das CP/M-System für potentielle Interessenten
> lukrativer?
Ich finde nein. Welche Software läuft damit, die vorher nicht lief?

Bei meiner SIMM-Variante lassen sich Module von 256kB bis 4MB verwenden. 
Aber selbst der 256kB-Riegel wird nicht vollständig genutzt.

Viele Grüße
Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Hast Du da mal einen Link?
> Ich würde den Propeller auch viel lieber unter Linux programmieren.

Such mal nach "Brad's Spin Tool", bzw. BST von Brad Campell.

Marcel A. schrieb:
> Was ist denn der Vorteil/Unterschied zu dem RAM-Baustein, der bisher auf
> deinem Board verbaut ist?

Manche Leute mögen DRAMs nicht. Oder haben Beschaffungsprobleme, oder 
können/wollen die Teile nicht löten.

Jens schrieb:
> Joe G. schrieb:
>> Was meint ihr? Würde damit das CP/M-System für potentielle Interessenten
>> lukrativer?
> Ich finde nein. Welche Software läuft damit, die vorher nicht lief?
>
> Bei meiner SIMM-Variante lassen sich Module von 256kB bis 4MB verwenden.
> Aber selbst der 256kB-Riegel wird nicht vollständig genutzt.

Mit der RAM-Disk kann man bis 4MB nutzen. Leider ist sie sehr langsam.

Deutlich schneller sollte es gehen, wenn man bei den obersten drei 
Adressbits auf Multiplexing verzichtet. Mit etwas geändertem RAM-Treiber 
bekommt man dann vielleicht auch mehrere RAM-Banks (z.B. für CP/M 3) mit 
ausreichender Geschwindigkeit hin.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Such mal nach "Brad's Spin Tool", bzw. BST von Brad Campell.
Danke, das sieht gut aus.
Leider scheint die Mac-Variante bei mir nicht zu laufen. Das wäre das 
i-Tüpfelchen gewesen :-)
Dann probiere ich als nächstes die Linux-Version aus.

> Manche Leute mögen DRAMs nicht. Oder haben Beschaffungsprobleme, oder
> können/wollen die Teile nicht löten.
Ok. Da hatte ich Euch falsch verstanden. Es soll also eine weitere 
Speichervariante darstellen.
Prinzipiell ist die Idee gut, aktuell beschaffbare Bausteine zu 
verwenden.
Mein Bedarf ist zwar gedeckt, aber ich bin ja auch nicht der Einzige ;-)

> Mit der RAM-Disk kann man bis 4MB nutzen.
Ja, aber wozu?
Die SD-Karte geht ja schon wesentlich schneller als dazumal die 
Diskettenlaufwerke. RAM-Disk wurde ja zur Steigerung der 
Zugriffsgeschwindigkeit genutzt. Bei den damaligen RAM-Preisen war aber 
die Verbreitung eher gering. Daher gibt es auch nicht allzuviel 
Software, die das sinnvoll nutzen kann.

Also eine SRAM-Variante ja, aber übermäßig viel davon (>256k), halte ich 
nicht für sinnvoll.

Viele Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die RAM-Variante soll eine kleine Hilfe sein.
Es können derzeit verfügbare IC's verwendet werden oder eigene DRAM's 
auf einer entsprechenden Adapterkarte. Somit ist keine Layoutänderung 
nötig.

Jens schrieb:
> ielleicht schaffen wir es
> ja im Propeller noch einen Attribute/Farbspeicher pro Zeichen zu
> implementieren.

30 Zeilen mit 80 Zeichen würden wir mit dem verfügbaren Speicher gerade 
noch hinbekommen. Dann ist aber das Ende der Fahnenstange erreicht.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt nun eine neue VT100 Variante.

- 80 Zeichen x 30 Zeilen
- Vordergrund- und Hintergrundfarbe für jedes Zeichen einzeln 
einstellbar
- Invers ESC[7m
- Fett ein (helle Schrift) ESC[1m
- Fett aus (dunkle Schrift) ESC[22m

WS und TP müssen für diese Attribute natürlich angepaßt werden. 
Selbstverständlich auch für Bildschirmauflösung 80x30.

http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga_color/

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
CP/M Duino

- Boardgröße Arduino Mega
- 512 MB SRAM (verfügbar)
- SD Card (verfügbarer Halter)
- RTC mit Stützbatterie
- 8 Bit Porterweiterung
- 2 ADC
- VT-100 Shield steckbar

Vielleicht interessiert sich der eine oder andere „Arduino Jünger“ ja 
für eine solche Variante. Der Arduino bleibt dabei voll erhalten, 
bekommt sogar noch 512 MB RAM und über das VT-100 Shield eine 
VGA-Ausgabe und eine PS2 Tastatur.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> CP/M Duino
>
> - Boardgröße Arduino Mega
D.h. da steckt letztlich ein Arduina-Kompatibles Design hinter? Die IDE 
würde einen normalen Arduina-"irgendwas" erkennen?

> - 512 MB SRAM (verfügbar)
> - SD Card (verfügbarer Halter)
> - RTC mit Stützbatterie
> - 8 Bit Porterweiterung
> - 2 ADC
> - VT-100 Shield steckbar
>
> Vielleicht interessiert sich der eine oder andere „Arduino Jünger“ ja
> für eine solche Variante. Der Arduino bleibt dabei voll erhalten,
> bekommt sogar noch 512 MB RAM und über das VT-100 Shield eine
> VGA-Ausgabe und eine PS2 Tastatur.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Design ist annähernd Kompatibel. Wenn der Arduino Bootloader 
installiert
ist, sollte die IDE auch laufen. Sinnvoll ist jedoch der CP/M Bootloader 
;-)

Autor: Leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joe.

Joe G. schrieb:
> - 512 MB SRAM (verfügbar)
> - SD Card (verfügbarer Halter)
> - RTC mit Stützbatterie
> - 8 Bit Porterweiterung

Ich dachte, Du wolltest ein "Shield" mit ungefähr den oben genannten 
Komponenten bauen, damit Arduino-Besitzer auf CP/M "upgraden" können.

Wo siehst Du den Vorteil der Komplettlösung im Arduino-Format?

Joe G. schrieb:
> Sinnvoll ist jedoch der CP/M Bootloader ;-)

Könnte mir vorstellen, daß man ein CP/M-Image für den Arduino-Bootloader 
gernerieren kann.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leo,

das war die ursprüngliche Idee. Dummerweise sind beim Arduino nicht alle 
für unser CP/M-System benötigten Pins rausgeführt (siehe Anlage). Der 
Arduino USB-Port liegt direkt auf AVR_TX /AVR_RX also für uns so auch 
nicht zu gebrauchen. Der Propeller könnte in der Original Arduino 
Konfiguration auch nicht programmiert werden. So entstand der nun 
vorliegende Vorschlag.
1. Ein Arduino Board welches Arduino und CP/M kompatibel ist.
2. Ein VT-100 Shield

Die Idee mit dem CP/M–Image für den Arduino Bootloader ist natürlich 
sehr gut. Dazu müsste allerdings auch der Arduino Bootloader auf die 
Rx,Tx Pins beim CP/M angepasst werden.

Warum das ganze?
Ich sehe dabei zwei Aspekte. Der CP/M-Kenner kann sich ohne viel Aufwand 
mit den Arduino beschäftigen und die Arduino-Jugend bekommt ohne viel 
Aufwand ein komplettes Betriebssystem mit allen verfügbaren Programmen, 
wie C, Pascal, Forth, Wordstar… sowie ein Arduino Board mit 512 KB SRam, 
SD-Card, RTC, I2C usw. + VGA.

: Bearbeitet durch User
Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Neben der reinen AVR Lösung hat die Nutzung einer echten Z80 CPU auch 
seinen Charme. Recherchiert man mal nach aktuellen Lösungen, so 
kristallisieren sich unabhängig voneinander immer ähnliche Konzepte 
heraus.

1. moderne Z80 CPU (z.B. Z8L180 oder Z8S180) 3.3V, 33 MHz
2. 128k – 512K SRAM
3. kein EPROM oder EEPROM
4. Bootvorgang über AVR
5. SD-Card statt Diskette

Beispiele dazu sind hier zu finden:
http://www.shaels.net/index.php/mini80
http://forums.parallax.com/showthread.php/148944-Propeller-Z80-CPM-hybrid
http://hive-project.de/board/viewtopic.php?f=15&t=955

Den letzten Link habe ich für weitere Überlegungen aufgegriffen. Micha 
hat dazu ein sehr gutes minimales Hardwarekonzept (sowie eine 
Softwarebasis) auf AVR-Basis entwickelt. Dieses Konzept habe ich nun 
aufgegriffen und etwas erweitert um ein Maximum an Softwaremodulen 
unseres Systems weiter zu nutzen. Grob skizziert würde es etwa so 
aussehen:
1. AVR übernimmt Buskontrolle
2. AVR initialisiert den RAM und die SD-Card (Kontrolle über V24 / 
Terminal)
3. AVR läd BIOS von SD-Card und schreibt es in den RAM
4. AVR übergibt CRT Kanal an Z80 SIO
5. AVR initialisiert Soft I2C mit RTC
6. AVR übergibt Bus an Z80
7. Z80 bootet CP/M
8. AVR stellt IN(), OUT() Funktionen für Z80 zur Verfügung (virtuelle 
SIO, PIO)

Mir gefällt die Idee persönlich so gut, dass ich sie für mich aufbauen 
werde. Konzeptionell sind dazu folgende Schritte geplant.
1. minimaler Hardwareentwurf (siehe Anhang) als Entwicklungsbasis
2. Portierung der Software sowie Integration von Hardwareverbesserungen, 
-erweiterungen
3. finale Version mit integriertem VT-100 Terminal auf bisheriger Basis
4. CP/M Duino mit echtem Z80 (Z180) ??

Es gibt sowohl im CP/M Forum als auch im HIVE Forum Interessenten. Auch 
Micha als ursprünglicher Entwickler der Lösung ist weiter interessiert. 
Es sollte doch möglich sein, die Interessenten aus drei Foren in einem 
gemeinsamen Projekt zu bündeln.

Viel Text zu einer kurzen Frage.
Wer hat Interesse an diesem Projekt sowie zunächst an der Stufe 1 und 
Stufe 2 ? Schaltung und Layout sind erstellt und könnten kurzfristig für 
weitere Diskussion dienen.

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Neben der reinen AVR Lösung hat die Nutzung einer echten Z80 CPU auch
> seinen Charme.

Ach. ;-)

> 4. Bootvorgang über AVR

Da gibts noch Alternativen. Letztes Jahr hatte ich mal was mit stm32 
angfangen.

> 2. AVR initialisiert den RAM und die SD-Card (Kontrolle über V24 /
> Terminal)
> 3. AVR läd BIOS von SD-Card und schreibt es in den RAM
> 4. AVR übergibt CRT Kanal an Z80 SIO

Die Umschalter würde ich einfach weglassen. Die Consolenschnittstelle 
kann durch den I/O-Controller einfach durchgeschleift werden. Die beiden 
Z180-UARTs stehen dann als weitere Schnittstellen zur Verfügung.

> 5. AVR initialisiert Soft I2C mit RTC

RTC ist im STM32 bereits eingebaut.

> Mir gefällt die Idee persönlich so gut, dass ich sie für mich aufbauen
> werde. Konzeptionell sind dazu folgende Schritte geplant.
> 1. minimaler Hardwareentwurf (siehe Anhang) als Entwicklungsbasis

Ist (noch) nicht minimal. ;)

> 4. CP/M Duino mit echtem Z80 (Z180) ??

Ach, dazu wollte ich ja auch noch was schreiben.

> Wer hat Interesse an diesem Projekt sowie zunächst an der Stufe 1 und
> Stufe 2 ? Schaltung und Layout sind erstellt und könnten kurzfristig für
> weitere Diskussion dienen.

Interessieren tuts mich schon. Aber nicht so, daß ich eine Platine haben 
wollen würde.

Noch ein paar Worte zu meiner STM32–Variante.

- Den HD64180 hatte ich schon. Der läuft nur mit 5V.
- STM32 I/Os sind 5V-tolerant.
- STM32F1 mit vielen Pins sind billiger als AVR.
- Durch die vielen I/O-Pins kann alle denkbare Peripherie ohne weitere
  ICs angeschlossen werden.
- Ein STM32VLDISCOVERY hatte ich schon. Damit konnte ich schnell
  anfangen.

Leider hat das Discovery-Board doch zu wenige 5V-tolerante I/O-Ports. 
Deshalb sind jetzt noch 2 Buffer-ICs verbaut. Wenn ich mal wieder dazu 
komme, soll das Board (und die beiden HCT541) gegen einen (mindestens) 
100 poligen STM32F101 getauscht werden.

Im angehängten Schaltplan sind P1-P3 die Buchsenleisten, auf die das 
Discovery-Board gesteckt wird.

Autor: Svenska (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein anderes Beispiel hab ich mal aufgebaut, aber mit einem klassischen 
Z80:
Beitrag "Re: eigenes Z80 Mainboard - geht das so?"

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Da gibts noch Alternativen. Letztes Jahr hatte ich mal was mit stm32
> angfangen.

Leider habe ich davon keine Ahnung, aber kann ja noch werden ;-)

> Ist (noch) nicht minimal. ;)
Stimmt, anbei die Schaltung des derzeitigen Standes.

> Interessieren tuts mich schon. Aber nicht so, daß ich eine Platine haben
> wollen würde.
Manchmal gibt es auch was umsonst ;-)

Prinzipiell habe ich nichts gegen eine STM32-Variante. Leider ist der 
3.3V Z180 (Z8S180) nicht so richtig verfügbar. Der Z8L180 (5V) jedoch 
überall.

> Die Umschalter würde ich einfach weglassen. Die Consolenschnittstelle
> kann durch den I/O-Controller einfach durchgeschleift werden. Die beiden
> Z180-UARTs stehen dann als weitere Schnittstellen zur Verfügung.

Das ist eigentlich auch nur für die Entwicklung gedacht. So kann der 
Initialisierungsvorgang beim AVR besser überwacht werden. Natürlich 
können auch einfach alle drei Schnittstellen nach außen geführt werden.

Autor: Guido L. (guidol1970)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Neben der reinen AVR Lösung hat die Nutzung einer echten Z80 CPU auch
> seinen Charme.

> Beispiele dazu sind hier zu finden:
> http://www.shaels.net/index.php/mini80
> http://forums.parallax.com/showthread.php/148944-Propeller-Z80-CPM-hybrid
> http://hive-project.de/board/viewtopic.php?f=15&t=955
>

Ich habe "damals" noch einen V6Z80P "ergattert", da die fertige Platine 
nur zu bekommen war, wenn der nette UKler einem die Bauteile aufgeloetet 
hat....so gibt es nicht so viele davon und nun hat er das Modell 
eingestellt:

http://www.retroleum.co.uk/electronics-articles/v6z80p/

Die Platine nutzt einen echten Z80 und SD-Karte als Medium

: Bearbeitet durch User
Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Finde ich spannend.
Noch spannender finde ich, dass ich diese Antwort 2x schreiben muss, die 
erste ist verschütt gegangen.

Wofür ist den CRT gut? Das ist doch auch nur eine serielle 
Schnittstelle, oder? Wo ist der Unterschied zum TTY Anschluss?

Habe zwar noch jede Mengen "Baustellen" hier aber... in was für einer 
Größenordnung liegt denn das Projekt (Platine, Bauteile...)?

Gruß
Marcel

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Wofür ist den CRT gut? Das ist doch auch nur eine serielle
> Schnittstelle, oder? Wo ist der Unterschied zum TTY-Anschluss?

An CRT wird das Terminal angeschlossen. Darüber erfolgen also die 
Bildschirmausgabe und die Tastatureingabe. Mit TTY wird eine 
vollständige serielle Schnittstelle, also Rx, Tx, RTS, CTS, DTR, DSR 
bereitgestellt.

> Habe zwar noch jede Mengen "Baustellen" hier aber... in was für einer
> Größenordnung liegt denn das Projekt (Platine, Bauteile...)?

Die Platine habe ich noch nicht kalkuliert, bei den Bauelementen schlägt 
die Z180 CPU mit ca 10 $ zu. Den Rest kann man sich ja selbst 
ausrechnen.

Es ist jedoch KEIN fertiges, erprobtes Konzept wie das bereits 
existierende AVR CP/M !! Hier darf noch kräftig selbst Hand angelegt 
werden.

Nachtrag: Anbei alle Schaltungen. Nun darf kräftig Kritik geäußert 
werden bzw. Fehler und Unstimmgikeiten benannt werden.

: Bearbeitet durch User
Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nur mal kurz, weil ich gerade nicht viel Zeit habe.


Joe G. schrieb:
> Leider ist der
> 3.3V Z180 (Z8S180) nicht so richtig verfügbar. Der Z8L180 (5V) jedoch
> überall.

Hier scheints mehrere Verwechslungen zu geben, was bei den Datenblättern 
von Zilog (Viele (Druck-)Fehler und fast immer "Preliminary") auch kein 
Wunder ist. Die angehängten Graphen stammen aus [1]. Daraus, und aus der 
Tabellenüberschrift zu den AC Characteristics in [1] und [2] schließe 
ich, daß der Z8S180 auch mit 3.3 V, dann allerdings nur bis 20MHz läuft.

Beim freundlichen Chinesen habe ich den Z2S180 incl. Versand ab ca. 
€2,20 gesehen, bei Abnahme von 10 Stück.


Wenn man den Z180 (und das RAM) mit 3.3V betreiben kann, ist es 
schaltungstechnisch fast egal, ob man als "Hilfscontroller" einen AVR 
oder STM32 nimmt. Gleiche Anzahl I/Os vorausgesetzt.

[1] http://www.zilog.com/docs/z180/um0050.pdf
[2] http://www.zilog.com/docs/z180/z8s180ps.pdf

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Daraus, und aus der
> Tabellenüberschrift zu den AC Characteristics in [1] und [2] schließe
> ich, daß der Z8S180 auch mit 3.3 V, dann allerdings nur bis 20MHz läuft.

Da ich gerade zwei frische Z8S180033VSC auf dem Labortisch habe, teste 
ich gleich mal den Spannungsbereich aus.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade 2 CPU's (Z8L180) getestet. Der M1 Zyklus bzw. der 
Adresszähler laufen bei beiden Exemplaren sauber von 5 V bis runter zu 
2.4 V.
Der Quarztakt lag auf 20 MHz.

: Bearbeitet durch User
Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei ein vorläufiger Abschlussstand der AVR CP/M Version. Gegenüber der 
letzten Version sind noch folgende Änderungen eingeflossen:
1. Adresslatch auf /BUSACK gelegt (Danke Leo C.)
2. SRAM auf 512K vergrößert
3. Takt direkt am Z180 erzeugt
4. System komplett auf 3.3V (Levelshifter für SD entfällt)
5. I2C komplett separat, also Umschalter CRT1/CRT2 getrennt
Ich würde diesen Arbeitsstand zunächst „einfrieren“ um weitere Ideen und 
Vorschläge zu sammeln.
Aus meiner Sicht sehr überlegenswert der Vorschlag von Leo C. anstelle 
eines AVR’s ein STM32 zu verwenden. Die Entwicklung könnte in Richtung 
„CP/M Shield für STM Discovery“ gehen.

: Bearbeitet durch User
Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein Layout gibt es nun auch.

Autor: Svenska (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wäre es nicht sinnvoller, einen neuen Thread dafür aufzumachen? "CP/M 
auf ATmega88" passt inzwischen überhaupt nicht mehr.

Mich würde es freuen, weil die Thread-Ladezeit in meinem Firefox langsam 
unerträglich wird.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> CP/M Shield für STM Discovery
Für welches Discovery? Ich hab inzwischen mehrere :-)

Außerdem ist man dann gleich wieder an dem Punkt, den Propeller 
einzusparen, weil der STM genug Power für VGA hat:
Youtube-Video "STM32 VGA graphics demos"

Viele Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach einigen Überlegungen hat sich die AVR_Z80_Stamp Version 
herauskristallisiert. Also ein Z180-Modul mit kompletten Z80 Bus. So 
kann das Modul z.B. auf eine Leiterkarte mit ECB-BUS gesteckt werden. 
Das Modul selbst ist jedoch auch schon (fast, nur 3.3V) ohne äußere 
Beschaltung komplett lauffähig. Die Unterlagen dazu gibt es wie immer 
hier:
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/
Ich warte noch auf einige Bauelementemuster um das Layout zu überprüfen 
und dann werde ich einen Satz Leiterplatten fertigen lassen. Bei allem 
Enthusiasmus bitte jedoch immer bedenken. Es ist zunächst eine 
Entwicklungsversion.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Weiterentwiklung auf Basis des Z180 gibt es jetzt einen einen 
Thread.
Beitrag "Z180-Stamp Modul"

Autor: Matthias I. (matze5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist die AVR Variante mittlerweile voll 8080 Kombatibel?

Gruss Matthias

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist die AVR Variante mittlerweile voll 8080 Kombatibel?

Was fehlt denn, oder was hat gefehlt?

Autor: Matthias I. (matze5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich frag nur da ich schon seit langeren mal einen Nachbau machen will 
und ich wuerde gern mit dem Asembler drauf rumspielen :)

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> und ich wuerde gern mit dem Asembler drauf rumspielen :)

Dabei sollte aber volle Z80 Kompatibilität nicht stören, oder?

In der config.inc gibt es einen Schalter 1), um die Z80 Emulation 
abzuschalten. Dieser Schalter stammt aus der Anfangszeit des Projekts, 
als der Interpreter für die Z80 Opcodes noch gar nicht vorhanden war, 
und diente dazu, das Verhalten der Flags zwischen 8080- und Z80-Mode 
umzuschalten.

Man könnte den 8080-Mode dazu verwenden, Flash einzusparen, damit das 
Programm wieder in einen atmega88 paßt. Da an dieser Variante bisher 
niemand Interesse gezeigt hat, ist sie wenig getestet, und die 
undokumentierten 8080 Opcodes werden wahrscheinlich garantiert nicht 
richtig interpretiert.


1)  #define EM_Z80 1    /* Emulate Z80 if true, else 8080 */

Autor: Matthias I. (matze5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach seh schon jetzt ist es der ATMega168 :)

Intressant waere noch eine zweite Serielle Schnittstelle.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ach seh schon jetzt ist es der ATMega168 :)

Eher nicht. ;)

> Intressant waere noch eine zweite Serielle Schnittstelle.


Klar.

Autor: Matthias I. (matze5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich blick da nicht durch,
da ist nur die Rede von ATmega88 und weiter unten von 168,
was ist den nun die aktuelleste Version mit AVR ?

Diese ?:
http://www.mikrocontroller.net/articles/Datei:ACPM_Prop.jpg


Gruss Matze

: Bearbeitet durch User
Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> da ist nur die Rede von ATmega88 und weiter unten von 168,
> was ist den nun die aktuelleste Version mit AVR ?

Die aktuelle Software braucht einen ATmega328P. Mit ein paar kleinen 
Einschränkungen würde man sie noch in einen 168 bekommen, aber im 
Normalfall sollte man sich daß nicht antun. Vom Preis und Verfügbarkeit 
her dürfte sowieso fast kein Unterschied bestehen.

> Diese ?:
> http://www.mikrocontroller.net/articles/Datei:ACPM_Prop.jpg

Auf dem Foto sieht man nicht, welcher Controller auf der Platine ist. 
Bin mir aber ziemlich sicher, daß die niemand mit atmega168 bestückt 
hat.

Autor: Drako (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ebay-Artikel Nr. 281464531861

...

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Drako schrieb:
> ...

2 Fragen:

Ist da noch die Firmware drauf, die im ersten Bild (Screenshoot) zu 
sehen ist (v2.3 r185)? Wenn nicht, welche dann?

Wird der USB-Dongle, der im 2 Bild zu sehen ist, mitgeliefert? Ist aus 
dem Text nicht klar zu erkennen.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 2 Fragen:

2 Tage - keine Antwort.

Dann kann man wohl davon ausgehen, das auf der halb bestückten Platine 
noch die uralte Firmware mit unfertigem, buggy Z80-Interpreter drauf 
ist. Neu flashen geht auch nicht so einfach, der der ISP-Stecker ja auch 
fehlt. Aber da man wg. USB-Anschluß ja sowieso zum Lötkolben greifen 
muß...

Autor: Marcel A. (dl1ekm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe mal meinen ersten Lochraster-Aufbau von "anno dazumal" 
ausgegraben (siehe Foto), den mit ATMega88 und 4bit RAM.
Ich habe dem dann einen 328p spendiert und wollte die aktuelle 
"firmware" mit Z80-Unterstützung draufbringen.

Tja, mehrere Hürden - und letztlich kein Erfog:

- zunächst musste ich im MakeFile die Pfade zum avrasm und den 
includesdes AVR Studios anpassen - kein Problem
- dann musste ich noch svnver.exe nachinstallieren (oder den Eintrag im 
MakeFile auskommentieren) - auch kein Problem
- obwohl ich dann (so denke ich, siehe Anhang) die Flags richtig gesetzt 
habe konnte er die init.asm nicht übsersetzten "Symbol SCL not found". 
Ich denke das liegt daran, dass wegen der Abwahl von I2C die 
equ-Einträge nicht geladen werden, in der init.asm aber trotzdem darauf 
verwiesen wird. Ich habe also mal eben SCL durch 5 und SDA durch 4 
ersetzt im code - ist ja eh egal
- beim Auslesen der "Release-Version" spuckt mir make immer noch 
folgende Fehler aus:
process_begin: CreateProcess(NULL, awk -vID=VMAJOR "$1$2 ~ \"#define\"ID {print $3}" config.inc, ...) failed.
process_begin: CreateProcess(NULL, awk -vID=VMINOR "$1$2 ~ \"#define\"ID {print $3}" config.inc, ...) failed.
process_begin: CreateProcess(NULL, awk -vID=VMAJOR "$1$2 ~ \"#define\"ID {print $3}" config.inc, ...) failed.
process_begin: CreateProcess(NULL, awk -vID=VMINOR "$1$2 ~ \"#define\"ID {print $3}" config.inc, ...) failed. 
- es wird keine eep-Datei erzeugt, im MakeFile steht aber für "make 
program" sowohl hex als auch eep brennen. Daher kommt es zum Fehler 
"avrcpm.eep not found". Ist das schlimm? Wird überhaupt was ins eeprom 
geschrieben?

Wenn ich den 328er dann einsetze passiert - nichts. Keine Antwort auf 
dem Terminal...

Mache ich hier noch was falsch oder "geht das gar nicht auf der HW"?

Danke und Gruß
Marcel

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> im MakeFile steht aber für "make
> program" sowohl hex als auch eep brennen. Daher kommt es zum Fehler
> "avrcpm.eep not found".

$ make flash

make program benutzt kein Mensch (dachte ich)

> Ist das schlimm?

Unschön, aber nicht schlimm.

> Mache ich hier noch was falsch oder "geht das gar nicht auf der HW"?

Weiß nicht, ob die aktuelle Software noch mit 4-bit läuft.
Kann ich mir erst heute Mittag anschauen. Alles so lange her...

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den letzten Beitrag habe ich wieder gelöscht, weil der darin enthaltene 
Änderungsvorschlag Mist war. Da der Rest nicht ganz so falsch ist, 
stelle ich ihn wieder rein


Marcel A. schrieb:
> - obwohl ich dann (so denke ich, siehe Anhang) die Flags richtig gesetzt

Man kann stattdessen make übrigens auch so starten:
$ make DRAM_8BIT=0

oder auch
$ make flash DRAM_8BIT=0 AVRDUDE_PROGRAMMER=usbasp

> habe konnte er die init.asm nicht übsersetzten "Symbol SCL not found".
> Ich denke das liegt daran, dass wegen der Abwahl von I2C die
> equ-Einträge nicht geladen werden, in der init.asm aber trotzdem darauf
> verwiesen wird.

Genau

> Ich habe also mal eben SCL durch 5 und SDA durch 4
> ersetzt im code - ist ja eh egal

Das ist natürlich nicht egal, da die Ports ja für etwas anderes 
verwendet werden.
8-bit RAM:
;Port C
.equ SDA  = 4
.equ SCL  = 5
4-bit RAM:
;Port C
.equ RAM_W  = 4
.equ RAM_CAS  = 5

Die RAM-Steuerleitungen als Input, macht sich dann nicht so gut.

Für die RXD-Leitung gilt ähnliches. Es kann natürlich sein, das noch 
weitere Stellen angepaßt werden müssen. Wenns bei Dir so immer noch 
nicht läuft, und müßte ich mir notfalls ein 4-Bit System aufbauen.

> process_begin: CreateProcess(NULL, awk -vID=VMAJOR "$1$2 ~ \"#define\"ID
> {print $3}" config.inc, ...) failed.

Gibt es ein awk auf dem Rechner, und ist es im "$PATH"?

: Bearbeitet durch User
Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Änderung wahr wohl doch richtig. Also bleibt sie erst mal so im SVN.

@Marcel, falls Du Dir den Download sparen willst:
; - Setup Ports

;  ldi   temp,(1<<PUD)    ;disable pullups
;  outm8  P_PUD,temp
  out   PORTD,_255    ;all pins high (enables pullup on input ports)
  out   PORTB,_255
  out   PORTC,_255
  out   DDRD,_255    ; PD all outputs
#if I2C_SUPPORT
  ldi  temp,~((1<<SCL)|(1<<SDA))
  out  DDRC,temp 
#endif
#if DRAM_8BIT
  ldi  temp,~(1<<RXD)
  out  DDRB,temp
#endif

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gawk (aus WinAVR) drauf, und im makefile steht auch "AWK=gawk".
Ist auch im PATH.
Trotzdem ging es erst, als ich gawk.exe in awk.exe umbenannt hatte. Na 
egal.

Jetzt kommen nur noch diese warnings:
avrcpm.asm(35): info: 'config.inc' included from here
config.inc(374): warning: Register r8 already defined by the .DEF directive
avrcpm.asm(35): info: 'config.inc' included from here
config.inc(375): warning: Register r9 already defined by the .DEF directive
avrcpm.asm(35): info: 'config.inc' included from here
config.inc(378): warning: Register r10 already defined by the .DEF directive
avrcpm.asm(35): info: 'config.inc' included from here
config.inc(379): warning: Register r11 already defined by the .DEF directive
avrcpm.asm(35): info: 'config.inc' included from here
config.inc(382): warning: Register r12 already defined by the .DEF directive
avrcpm.asm(35): info: 'config.inc' included from here
config.inc(383): warning: Register r13 already defined by the .DEF directive
avrcpm.asm(35): info: 'config.inc' included from here 

Ich habe schon mit BAUD rumgespielt - ohne "sichtbaren" Erfolg.
Der Cursor in TeraTerm scheint bei einem Reset leicht zu flackern - mehr 
nicht.

Wahrscheinlich geht es einfach nicht. Ist zwar schade, macht aber auch 
keinen Sinn, da groß weiter zu testen, danke Leo.

Ich sollte mal langsam mit dem "großen" CPM-Rechner anfangen :-)

Gruß
Marcel

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe gawk (aus WinAVR) drauf, und im makefile steht auch "AWK=gawk".
> Trotzdem ging es erst, als ich gawk.exe in awk.exe umbenannt hatte. Na
> egal.

Im Makefile steht zwar:
AWK = gawk

allerdings:
conf-val = $(shell awk ...

statt:
conf-val = $(shell $(AWK) ...

Bei mir (Debian) gibt es einen Link von awk auf gawk über die 
Alternativen-Verwaltung.

> Wahrscheinlich geht es einfach nicht.
Du bist jetzt wohl der Erste nach über 3 Jahren, der das merkt.
Aber ich weiß nicht so recht, ob ich mich damit abfinden will...
Mal sehen, ob ich etwas Zeit finde.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum!

Ich versuche gerade mit den cpmtools auf die 8 MB-Images zuzugreifen. 
Aber irgendwie gelingt mir das nicht. cpmls zeigt einfach nichts an.

Ist denn die diskdef richtig, oder passt die nur für die 260 kB-Images? 
(Mit den 260 kB-Images funktioniert cpmls.)
diskdef avrcpm
  seclen 128
  tracks 77
  sectrk 26
  blocksize 1024
  maxdir 64
  skew 1
  boottrk 2
  os p2dos
end

Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der hier müßte passen:
 # SIMH AltairZ80 Harddisk
diskdef simhd
  seclen 128
  tracks 2048
  sectrk 32
  blocksize 4096
  maxdir 1024
  skew 0
  boottrk 6
  os p2dos
end

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super. Das funktioniert.

Jetzt bekomme ich beim Ausführen von verschiedenen Programmen "CPU 
halted!"-Fehler.

Zum Beispiel bei ZEXTEST 
(http://www.jens-mueller.org/jkcemu/zextest.html)
62k cp/m vers 2.2

A>d:
D>dir
D: ZEXALL   SRC : ZEXDOC   SRC : ZEXALL   COM : ZEXDOC   COM
D>zexdoc

S       A =E5 BC =00F8 DE =F1FF HL =F8F8 SP=E3A9 PC=019E       76 29 2C
        a'=00 bc'=0000 de'=0000 hl'=0000 IX=0000 IY=0000 I=00       CPU halted!

Oder einem Editor:
>dir *.com
C: CFGDATE  COM : DATE     COM : EDIT     COM : RECEIVE  COM
C: SETDATE  COM : SETDISK  COM : SETEDIT  COM : STAT     COM
C: TDATE    COM
C>edit

S       A =E5 BC =00FD DE =DDFF HL =E5FD SP=E406 PC=018C       76 65 6E
 Z  NC  a'=00 bc'=0000 de'=0000 hl'=E37E IX=E3F3 IY=9BE1 I=00       CPU halted!

Wie kann ich jetzt weiter vorgehen? Hat unsere Emulation noch Schwächen?

Viele Grüße,
Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "CPU halted!"-Fehler.

Das ist kein Fehler. Nur der Hinweis, daß die CPU auf einen HALT-Befehl 
gelaufen ist. ;)

Von der Standard-Firmware wird normalerweise das gesamte RAM mit 0x76 
(== HALT) gefüllt. Bei Programm- oder Hardware-Fehlern ist die 
Wahrscheinlichkeit, daß die CPU auf so einen Halt springt, relativ groß. 
Könnte sein, daß Du ein Hardwareproblem hast.

> Wie kann ich jetzt weiter vorgehen? Hat unsere Emulation noch Schwächen?

Die wird schon noch Schwächen haben, aber ganz bestimmt nicht solche. 
Zexdoc habe ich z.B. auch zum Testen benutzt.

Kannst Du mal die kompletten Boot-Meldungen posten?

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Kannst Du mal die kompletten Boot-Meldungen posten?
Sieht eigentlich unverdächtig aus:
CPM on an AVR, v3.2 r216 Test
Testing RAM: fill...wait...reread...
Initing mmc...

A: FAT16 File-Image 'A' at: 003, size: 8192KB.
B: FAT16 File-Image 'B' at: 5262, size: 8192KB.
C: FAT16 File-Image 'C' at: 5257, size: 8192KB.
D: FAT16 File-Image 'D' at: 6298, size: 8192KB.
E: FAT16 File-Image 'E' at: 6811, size: 8192KB.
F: FAT16 File-Image 'F' at: 7323, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!

62k cp/m vers 2.2

A>
Die Images C und D hab ich gestern neu erstellt. Dort laufen die 
Programme nicht. Images E und F sind die beiden Benchmark-Images 
(Dhrystone), die funktionieren. Und Image A und B sind 'alt', die 
funktionieren auch.

Du kannst ja evtl. mal einen Blick auf das angehängte Image werfen 
(zextest.simhd). Zum Erstellen habe eigentlich nur empty.simhd genommen 
und die Dateien mit cpmcp reinkopiert.

Dank & Gruß,
Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Sieht eigentlich unverdächtig aus:
> CPM on an AVR, v3.2 r216 Test

Ich wollte vor allem wissen, ob Du aktuelle Firmware hast.

> A: FAT16 File-Image 'A' at: 003, size: 8192KB.
> ...

Leider sieht man hier nicht die exakte Größe.
$ ls -l *.IMG *.simhd
-rw-r--r-- 1 leo leo 8388608 Mai  2  2012 CPMDSK_A.IMG
-rw-r--r-- 1 leo leo 8388864 Nov 28 18:03 zextest.simhd
$ 

Dein 'zextest.simhd' ist um einen Sektor (512 byte) größer als 8192KB. 
Deshalb wird es als my80- statt als simhd-Image erkannt. Diese Ecke ist 
leider etwas unübersichtlich und schlecht dokumentiert.
Die cpmtools verlassen sich im Wesentlichen auch darauf, daß der 
Anwender weiß was er tut.
$ fsck.cpm -f simhd -n zextest.simhd 
Phase 1: check extent fields
Phase 2: check extent connectivity
zextest.simhd: 6/1024 files (0.0% non-contigous), 42/2048 blocks
$ fsck.cpm -f myz80 -n zextest.simhd 
Phase 1: check extent fields
Phase 2: check extent connectivity
zextest.simhd: 6/1024 files (0.0% non-contigous), 36/2048 blocks
$ 

> Zum Erstellen habe eigentlich nur empty.simhd genommen
> und die Dateien mit cpmcp reinkopiert.

Wo gibts denn dieses 'empty.simhd'? Das scheint dann nämlich fehlerhaft 
zu sein. Ich habe nur ein leeres myz80 Image gefunden[1].

Hier noch die Zusammenfassung von [2] und [3]:
$ ./makeimage /dev/null myz80.img $(expr 128 \* 65536 + 256)
$ ./makeimage /dev/null simhd.img $(expr 128 \* 65536)

Danach mit cpmtools bespielen. Format 'myz80' bzw. 'simhd'.

# MYZ80 hard drive (only works with libdsk, because it has a 256-byte header)
diskdef myz80
  seclen 1024
  tracks 64
  sectrk 128
  blocksize 4096
  maxdir 1024
  skew 1
  boottrk 0
  os 3
end

# SIMH AltairZ80 Harddisk
diskdef simhd
  seclen 128
  tracks 2048
  sectrk 32
  blocksize 4096
  maxdir 1024
  skew 0
  boottrk 6
  os 2.2
end


[1] Beitrag "Re: CP/M auf ATmega88"
[2] Beitrag "Re: CP/M auf ATmega88"
[3] Beitrag "Re: CP/M auf ATmega88"

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wo gibts denn dieses 'empty.simhd'? Das scheint dann nämlich fehlerhaft
> zu sein. Ich habe nur ein leeres myz80 Image gefunden[1].
Da habe ich wohl was durcheinandergehauen.

Ich habe gedacht, das die 8 MB-Images automatisch simhd-Images sind:
 8388864 10 Okt  2010 empty.simhd
    8314  1 Nov  2013 empty_8MByte_img.zip

Richtig muß es wohl dann so heißen:
 8388864 10 Okt  2010 empty.myz80
    8314  1 Nov  2013 empty_8MByte_img.zip

Hätte ich mal ins zip-Archiv geschaut, hätte ich das auch sehen können 
(facepalm):
$ unzip -l  empty_8MByte_img.zip 
Archive:  empty_8MByte_img.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
  8388864  10-10-10 03:05   myz80.img
 --------                   -------
  8388864                   1 file

Vielen Dank Leo, ich glaube ich komme jetzt weiter.
Noch eine Frage: Wo gibt es makeimage? Mein Mac ist da etwas 
minderbemittelt.

Viele Grüße,
Jens

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Noch eine Frage: Wo gibt es makeimage?
Da mach ich mal die Ingrid [1]:
makeimage gibt es im SVN-Repository:
avrcpm/trunk/tools/makeimage/license.txt
avrcpm/trunk/tools/makeimage/makeimage.c
avrcpm/trunk/tools/makeimage/makeimage.sln
avrcpm/trunk/tools/makeimage/makeimage.vcproj
Und es läßt sich auch problemlos mit einem Mac kompilieren und 
ausführen:
$ makeimage /dev/null simhd.img $(expr 128 \* 65536)
- Opening Input File
- Opening Output File
- Copy Input File content to Output File
- Append Empty Block to End of File

Jetzt klappt's auch mit der Nachbarin (äh, dem Image :-)
62k cp/m vers 2.2

A>c:
C>dir
C: ZEXALL   COM : ZEXALL   SRC : ZEXDOC   COM : ZEXDOC   SRC
C>zexdoc
Z80 instruction exerciser
<adc,sbc> hl,<bc,de,hl,sp>....

Danke,
Jens


[1] http://de.wikipedia.org/wiki/Ingrid#Sonstiges

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

ich war grade den passenden Link für makeimage am Suchen. Aber schön, 
daß es die Ingrid gibt. ;)

Jens schrieb:
> $ unzip -l  empty_8MByte_img.zip

Bleibt für mich noch die Frage, wo Du diese Zip-Datei her hast. Bei mir 
hieß die nämlich mal myz80-img.zip.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Bei mir
> hieß die nämlich mal myz80-img.zip.
Ich hatte sie umbenannt. Der Originalname war mir zu kryptisch ;-)

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nächste Baustelle ;-)

Ich möchte eine Bootdiskette erstellen.

Variante 1: Klonen der Bootdisk mit SYSGEN

Aus nicht nachvollziehbarer Quelle hab ich ein SYSGEN (siehe Anhang):
C>a:load sysgen

FIRST ADDRESS 0100
LAST  ADDRESS 04FF
BYTES READ    0400
RECORDS WRITTEN 08


C>dir
C: CLS      HEX : SDIR     HEX : SYSGEN   HEX : SYSGEN   COM
C>a:pip a:=sysgen.com
C>a:
A>sysgen
SYSGEN VER 2.0
SOURCE DRIVE NAME (OR RETURN TO SKIP)a
SOURCE ON A, THEN TYPE RETURN
FUNCTION COMPLETE
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)c
DESTINATION ON C, THEN TYPE RETURN
FUNCTION COMPLETE
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)

A>dir c:
NO FILE
A>
Komisch. Alle Dateien sind 'weg' und booten läßt sich von dem Image auch 
nicht. Nur cpmls sieht die Dateien noch:
$ cpmls -f simhd /Volumes/CPM-DISK/CPMDSK_C.IMG 
0:
cls.hex
sdir.hex
sysgen.com
sysgen.hex
Kann das überhaupt so gehen? Möglicherweise verwende ich SYSGEN falsch, 
oder ich habe eine ungeeignete Version, oder SYSGEN kommt mit den großen 
Images nicht klar.




Variante 2: Bauen der Bootdisk auf dem Hostsystem
Hostsystem ist bei mir ein MacOS X (10.9.5).
Erster Schritt: Ich brauche (einen/den?) z80asm
Hier habe ich einen gefunden: 
http://wwwhomes.uni-bielefeld.de/achim/z80-asm.html

Der läßt sich aber nicht Kompilieren.
1. Versuch:
In file included from asm.c:12:
./z80-cpu.h:31:61: error: redefinition of 'wait'
enum cpu_control_pin { rd, wr, iorq, mreq, m1, inter, halt, wait, reset, rfsh,
                                                            ^
/usr/include/sys/wait.h:248:7: note: previous definition is here
pid_t   wait(int *) __DARWIN_ALIAS_C(wait);
        ^
1 error generated.
Aus irgendeinem Grund liegt 'wait' im selben Namensraum.
Ich hab das erste wait zu waitpin umbennant und scheitere jetzt am

2. Versuch:
ar rcs asm.a z80-cpu.o asm.o hash.o compile.o regs.o instr.o interrupt.o \
                 expression.o mini-display.o keyboard.o file.o
gcc -lc -o z80-asm z80-asm.o dummy.o asm.a hardware/hard.a
Undefined symbols for architecture x86_64:
  "_A", referenced from:
      _reg_adr in asm.a(regs.o)
  "_B", referenced from:
      _reg_adr in asm.a(regs.o)
  "_C", referenced from:
      _reg_adr in asm.a(regs.o)
  "_D", referenced from:
      _reg_adr in asm.a(regs.o)
  "_E", referenced from:
      _reg_adr in asm.a(regs.o)
  "_H", referenced from:
      _reg_adr in asm.a(regs.o)
  "_I", referenced from:
      _reg_adr in asm.a(regs.o)
  "_IXh", referenced from:
      _reg_adr in asm.a(regs.o)
  "_IXl", referenced from:
      _reg_adr in asm.a(regs.o)
  "_IYh", referenced from:
      _reg_adr in asm.a(regs.o)
  "_IYl", referenced from:
      _reg_adr in asm.a(regs.o)
  "_L", referenced from:
      _reg_adr in asm.a(regs.o)
     (maybe you meant: _LISTING)
  "_R", referenced from:
      _reg_adr in asm.a(regs.o)
ld: symbol(s) not found for architecture x86_64
Da bin ich einigermaßen ratlos.

Vielleicht hat ja jemand noch Tipps, um Variante 1 und Variante 2 zum 
Laufen zu bekommen.

Danke,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein CP/M-System direkt unter CP/M bauen hatte ich hier [1] mal 
beschrieben.
Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b 
streichen, da er nur für den Simulator definiert ist.

[1]: Beitrag "Re: CP/M auf ATmega88"

: Bearbeitet durch User
Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Ich möchte eine Bootdiskette erstellen.

Mein Vorschlag: Nachschauen, wie das Makefile im Zweig 
'avrcpm/trunk/cpm/' vom SVN-Server Deines Vertrauens die Teile 
zusammenstoppelt.

> Variante 1: Klonen der Bootdisk mit SYSGEN
> Aus nicht nachvollziehbarer Quelle hab ich ein SYSGEN (siehe Anhang):

Möglicherweise wird dieses Sysgen die falschen Sektoren, oder zu wenige 
kopieren.

> A>dir c:
> NO FILE
> A>
> Komisch. Alle Dateien sind 'weg' und booten läßt sich von dem Image auch

> Kann das überhaupt so gehen?

Theoretisch schon.
> oder ich habe eine ungeeignete Version,

Sehr wahrscheinlich. Im Anhang ist das Original-SYSGEN von DR. Statt die 
Die Disk-Geometrie vom BIOS zu holen, liest (und schreibt) es die 
Sektoren 1 bis 26 von Track 0 und 1.
Die großen Formate haben aber 32 oder noch mehr Sektoren pro Spur.

> oder SYSGEN kommt mit den großen Images nicht klar.

Von dem Sektorproblem abgesehen, eher nicht.
Das simh-Format hat 6 Spuren a 32 Sektoren für das System reserviert.
Das Directory kann dann eigentlich nicht überschrieben werden.

Wurden denn beide Images vor und nach SYSGEN als simh erkannt? 
(Überprüfen mit 'A>stat dsk:')
Hier ist 'A' simh und 'G' myz80:
A>stat dsk:

    A: Drive Characteristics
65344: 128 Byte Record Capacity
 8168: Kilobyte Drive  Capacity
 1024: 32  Byte Directory Entries
 1024: Checked  Directory Entries
  256: Records/ Extent
   32: Records/ Block
   32: Sectors/ Track
    6: Reserved Tracks

    G: Drive Characteristics
65536: 128 Byte Record Capacity
 8192: Kilobyte Drive  Capacity
 1024: 32  Byte Directory Entries
 1024: Checked  Directory Entries
  256: Records/ Extent
   32: Records/ Block
  128: Sectors/ Track
    0: Reserved Tracks


> Variante 2: Bauen der Bootdisk auf dem Hostsystem
> Hostsystem ist bei mir ein MacOS X (10.9.5).
> Erster Schritt: Ich brauche (einen/den?) z80asm

Die BIOS-Quellen sind für den Microsoft M80 geschrieben. Die gängigen 
Crossassembler sind oft nicht ganz kompatibel. Deshalb nehme ich m80.com 
oder neuerdings slr180.com in einem CP/M-Emulator. Leider weiß ich 
nicht, ob es einen passenden Emulator für MacOS gibt.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Ein CP/M-System direkt unter CP/M bauen hatte ich hier [1] mal
> beschrieben.
Der Thread ist ja inzwischen schon etwas unüberichtlich geworden. Das 
war mir entgangen.

> Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b
> streichen, da er nur für den Simulator definiert ist.
Wie ruft man denn die SUB-Datei unter CP/M überhaupt auf?
Was braucht man alles dazu? Nur SUBMIT.COM oder auch XSUB.COM?
So tut sich jedenfalls nicht viel:
G>a:submit avrcpm.sub

G>

Wenn ich das Makefile/Buildscript/avrcpm.sub per Hand durchspiele 
scheitere ich an diesem Punkt:
G>F:M80 =ZSDOS/M

...

U                                         IF  ROM
U                                           IF  ZS
P                                       ORG     ZSDOS+0DF9H
U                                         IF  ZS
U                                         IF  ROM

1197 Fatal error(s),108 Warning(s)

G>
Hab ich den falschen Assembler?


Leo C. schrieb:
> Mein Vorschlag: Nachschauen, wie das Makefile im Zweig
> 'avrcpm/trunk/cpm/' vom SVN-Server Deines Vertrauens die Teile
> zusammenstoppelt.
Dort hab ich schon geschaut. Das entspricht ja im wesentlichen der 
avrcpm.sub. Allerdings fehlen im Repository (URL: 
svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk/cpm) m.E. ein paar 
wichtige Quellen, z.B. ZSDOS.MAC oder BDOS.MAC. Außerdem ist mir nicht 
klar, wo die CPMxx.SYS herkommen, bzw. wie diese erstellt werden.


> Wurden denn beide Images vor und nach SYSGEN als simh erkannt?
Vorher ja, hinterher sieht es so aus :-/
A>stat dsk:

    A: Drive Characteristics
65344: 128 Byte Record Capacity
 8168: Kilobyte Drive  Capacity
 1024: 32  Byte Directory Entries
 1024: Checked  Directory Entries
  256: Records/ Extent
   32: Records/ Block
   32: Sectors/ Track
    6: Reserved Tracks

    C: Drive Characteristics
 1944: 128 Byte Record Capacity
  243: Kilobyte Drive  Capacity
   64: 32  Byte Directory Entries
   64: Checked  Directory Entries
  128: Records/ Extent
    8: Records/ Block
   26: Sectors/ Track
    2: Reserved Tracks
Offenbar verändert SYSGEN die Laufwerkscharakteristik.
Den Ansatz mit SYSGEN werde ich später weiterverfolgen. Selber bauen ist 
viel spannender.


> CP/M-Emulator ... für MacOS
Wird es sicher geben. Aber ich hab ja Zugriff auf das CP/M-System via 
Terminalprogramm. Da brauch ich keinen Emulator :-)

Gute N8,
Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was braucht man alles dazu? Nur SUBMIT.COM oder auch XSUB.COM?
> So tut sich jedenfalls nicht viel:
G>a:submit avrcpm.sub

Möglicherweise handelt es sich um das Problem, das hier
Beitrag "Re: CP/M auf ATmega88"
und hier
Beitrag "Re: CP/M auf ATmega88"
angesprochen wird.

> 1197 Fatal error(s),108 Warning(s)

So viele Fehler bekomme ich von M80 immer, wenn die Zeilenenden nicht 
stimmen. Der besteht auf CR/LF.
Die SLR-Assembler schlucken auch Unix-Zeilenenden.

Jens schrieb:
> Allerdings fehlen im Repository (URL:
> svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk/cpm) m.E. ein paar
> wichtige Quellen, z.B. ZSDOS.MAC oder BDOS.MAC.

Vom BDOS hatten wir nie Sourcecode, findet man aber, wie ZSDOS im Netz.

> Außerdem ist mir nicht klar, wo die CPMxx.SYS herkommen, bzw. wie
> diese erstellt werden.

Die 62K-Version hatte Sprite_tm in der Urfassung des Projekts schon 
mitgeliefert.
http://spritesmods.com/?art=avrcpm&page=4

Die anderen hatte ich mal mir irgendeinem MOVCPM gebastelt. Das hatte 
eine andere Seriennummer als Sprite_tms CP/M. Ich meine, die 
Seriennummern angepaßt zu haben, weiß aber nicht mehr, wie weit ich 
damit gekommen bin, und ob wirklich alles funktioniert, weil ich dann 
auf ZSDOS umgestiegen bin.

> Offenbar verändert SYSGEN die Laufwerkscharakteristik.

SYSGEN kopiert höchstwahrscheinlich ab Track 0, Sektor 1, weil auf 
Floppies die Sektornumerierung bei 1 beginnt. Da unsere Sektor-zählung 
bei 0 beginnt, wird der erste Sektor nicht mitkopiert. Dieser enthält 
beim simh-Format nicht nur den IPL, sondern auch eine Formatkennung. 
Wenn diese nach dem Kopieren fehlt, wird das (ursprünliche) 
AVRCPM-Standardformat angenommen.

Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL 
orientieren, oder die Diskgeometrie aus dem BIOS auslesen, und dann 
konsequenter weise auch die BIOS-Funktion für Sector-Translate 
verwenden.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> G>a:submit avrcpm.sub
>
> Möglicherweise handelt es sich um das Problem, das hier
Bestimmt. Aber erstmal muss es manuel funktionieren. Dann schau mir das 
nochmal an.
Und ich dachte immer so komisches Verhalten gibt es erst seit MS-DOS ;-)


>> 1197 Fatal error(s),108 Warning(s)
> So viele Fehler bekomme ich von M80 immer, wenn die Zeilenenden nicht
> stimmen. Der besteht auf CR/LF.
Die Zeilenenden waren bzw. sind es nicht. Viel einfacher: Es fehlt die 
ZSDOS.LIB

Ich habe hier (http://www.znode.de/specials/zsdossrc/) eine gefunden, 
jetzt kommt diese Ausschrift:
G>f:m80 =zsdos/m
P                                       COMMON  /_BIOS_/

1 Fatal error(s)
G>
Vielleicht könnt Ihr Eure ZSDOS.LIB nochmal zeigen, bzw. im Repository 
einchecken.

> Die SLR-Assembler schlucken auch Unix-Zeilenenden.
Denn kann ich mir ja trotzdem mal anschauen.


>> Außerdem ist mir nicht klar, wo die CPMxx.SYS herkommen, bzw. wie
>> diese erstellt werden.
> Die 62K-Version hatte Sprite_tm in der Urfassung des Projekts schon
> mitgeliefert.
> http://spritesmods.com/?art=avrcpm&page=4
Ok.

> Die anderen hatte ich mal mir irgendeinem MOVCPM gebastelt. Das hatte
> eine andere Seriennummer als Sprite_tms CP/M. Ich meine, die
> Seriennummern angepaßt zu haben, weiß aber nicht mehr, wie weit ich
> damit gekommen bin, und ob wirklich alles funktioniert, weil ich dann
> auf ZSDOS umgestiegen bin.
ZSDOS ist offenbar eh das bessere BDOS.

> Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL
Später. Aber es wäre ein originalerer Weg, um eine Systemkopie 
anzufertigen.

Viele Grüße,
Jens

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> G>f:m80 =zsdos/m
> P                                       COMMON  /_BIOS_/

Könnte das hier sein:
--- /home/leo/CPM/src/ZSDOS/1/ZSDOS.LIB  1998-12-24 10:19:34.000000000 +0100
+++ /home/leo/src/avr/CPM_auf_ATmega88/joe/zsdos-20120425/ZSDOS.LIB  2012-04-25 12:17:10.000000000 +0200
@@ -173,7 +173,5 @@
 ; the ZRL equate to TRUE.  With the ZRL equate set to FALSE, a standalone
 ; .REL file will be produced with no external requirements.
 
-ZRL  EQU  TRUE    ; Set True .ZRL file with COMMON for NZCOM,
+ZRL  EQU  FALSE    ; Set True .ZRL file with COMMON for NZCOM,
         ;     False to produce straight .REL file
-

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super:
G>f:m80 =zsdos/m

No Fatal error(s)

G>
Ich habe jetzt eine CPM.BIN!
Vielen Dank bis hierhin. Ohne Internet würde ich wahrscheinlich jetzt 
noch Doku lesen.


Joe G. schrieb:
> Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b
> streichen, da er nur für den Simulator definiert ist.

Jetzt bleibt nur noch eine Frage:
Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der 
'Boot-Diskette'?

Hier wird ja nach 'w' gleich aufgeräumt:
SAVE 26 cpm.bin
ERA IPL.COM   
ERA CCP.COM 
ERA ZSDOS.COM       
ERA BIOS.COM
w cpm.bin b
ERA CPM.BIN  

Viele Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der
> 'Boot-Diskette'?

Ich habe als "Boardmittel" die CP/M Tools verwendet.
mkfs.cpm.exe -f avrcpm -b cpm.bin -L test diskimage
Ich vermute jedoch, dass du mit "Boardmittel" direkt in CP/M die CPM.BIN 
Datei in den Bootsektor schreiben möchtest, oder?

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Vielen Dank bis hierhin. Ohne Internet würde ich wahrscheinlich jetzt
> noch Doku lesen.
...
> Jetzt bleibt nur noch eine Frage:
> Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der
> 'Boot-Diskette'?

CPM/M 2.2 ALTERATION GUIDE

Diese Doku gibts im Internet. ;-)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hah! Es bootet!
Vielen Dank, Jungs!

Joe G. schrieb:
> Ich habe als "Boardmittel" die CP/M Tools verwendet.
> mkfs.cpm.exe -f avrcpm -b cpm.bin -L test diskimage
Stimmt. So stehts ja auch im Makefile von Leo.
Bei mkfs.cpm kann man ja auch mehrmals -b <file> angeben. Kann man sich 
da den Zusammenbau mit DDT bzw. dd evtl. sparen?

> Ich vermute jedoch, dass du mit "Boardmittel" direkt in CP/M die CPM.BIN
> Datei in den Bootsektor schreiben möchtest, oder?
Ja. Das meinte ich eigentlich. Muß ja damals auch ohne Host-PC gegangen 
sein.


Um das Bauen zu vereinfachen, hab ich jetzt SuperSUB probiert:
http://archives.scovetta.com/pub/walnut-creek/SIMTEL/SIGM/VOLS000/VOL085/SUPERSUB.ASM
Aber so richtig gesprächig sind dir Tools von damals alle nicht:
G>dir
G: AVRCPM   LIB : CPM      BIN : BIOS     MAC : CCP      MAC
G: CFGACPM  LIB : SUPERSUB ASM : IPL      MAC : MEMCFG   LIB
G: ZSDOS    MAC : ZSDOS    COM : IPL      COM : CCP      COM
G: AVRCPM   SUB : BIOS     COM : XSUB     COM : ZSDOS    LIB
G: M80      COM : L80      COM : DDT      COM : SUPERSUB COM
G: $$$      SUB
G>supersub avrcpm.sub
SuperSUB V1.1

G>

Viele Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:
  • DO.COM (2,13 KB, 134 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Hah! Es bootet!
Glückwunsch!

Jens schrieb:
> Aber so richtig gesprächig sind dir Tools von damals alle nicht:

Versuche es mal mit DO.COM

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Versuche es mal mit DO.COM
Das meldet sich ja mit der gleichen Versionsnummer wie SUPERSUB.COM.
Immerhin kommt es bis zum DDT:
G>L80 BIOS,BIOS/N/E

Link-80  3.44  09-Dec-81  Copyright (c) 1981 Microsoft

Data    0100    0608    < 1288>

43314 Bytes Free
[0000   0608        6]

(xsub active)
G>ERA BIOS.REL
G>; PUT PIECES TOGETHER
G>DDT

(xsub active)
G>F100 5C00 0
F100?

G>

Viele Grüße,
Jens

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr merkwürdig. Ich hab jetzt den DDT nochmal auf das Laufwerk 
draufkopiert und nun geht es. Danke!

Mal sehen, was ich als nächstes ausprobiere.

Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe diese Frage auch schon beim AX81-Projekt gestellt:
Da sich diese Arduino (Uno) Boards (mit ATmega328 und 16 MHz) immer 
größerer Beliebtheit erfreuen - könnte das nicht eine alternative Basis 
zum "CPM Stick" sein?
Es müsste ja "nur" der RAM-Kram auf ein Zusatz-Shield. USB usw. ist ja 
schon alles drauf. Die SD-Card entweder mit auf das Zusatzshield oder 
ein SD-Card-Shield.

Würde ich glatt mal probieren - 2 Fragen:
- reichen die 16 MHz auf dem Board aus?
- wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?

Was meint ihr?

Gruß
Marcel

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Würde ich glatt mal probieren - 2 Fragen:
> - reichen die 16 MHz auf dem Board aus?
Ja. Ich habe bei der ATmega128-Variante auch 'nur' 16 MHz verwendet.

> - wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?
Nicht zwingend. Ich weiß aber nicht, wie knapp es im 328 zugeht.

Die Pins müssten ja gerade so reichen (UART, I2C, SD-Karte und DRAM).

Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

habe mir das gerade noch mal genauer angesehen.
PINs sind alles da - ABER:
RX/TX ist hart verdrahtet auf die RX/TX-Pins des ATMega (PD0/PD1). Diese 
werden aber im CPM-Stick für die RAM-Adressleitungen verwendet. Im Stick 
gibt es stattdessen einen Soft-UART auf den Pins PB0/PB1.
Würde bedeuten, man müsste HW-mäßig auf der Arduino-Uno-Platine 
rumbrutzeln - oder?

Zum Thema Bootloader: Habe ich das da richtig verstanden - wenn ich ein 
mit AVR GCC erstelltes oder eben dieses "CPM-HEX" mit avrdude und "-c 
arduino" flashe, dann ist das so wie mit der IDE und das HEX kommt 
hinter den Bootloader (falls es passt...)?

Danke und Gruß
Marcel

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Da sich diese Arduino (Uno) Boards (mit ATmega328 und 16 MHz) immer
> größerer Beliebtheit erfreuen - könnte das nicht eine alternative Basis
> zum "CPM Stick" sein?

Beitrag "Re: CP/M auf ATmega88"

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Beitrag "Re: CP/M auf ATmega88"
Das passt aber nicht auf meine Uno's.
Mimimi
:-)

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, für mich würde sich die Frage stellen, ob man mit dem USB-Seriell 
irgendwie klar kommt ...

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Es müsste ja "nur" der RAM-Kram auf ein Zusatz-Shield. USB usw. ist ja
> schon alles drauf. Die SD-Card entweder mit auf das Zusatzshield oder
> ein SD-Card-Shield.

z.B. so was:
Ebay-Artikel Nr. 121505102595

Da könnte man die RAMs gleich drauffrickeln. Und die Uhr könnte man auch 
mitverwenden.

>> - wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?

Wenn man den USB-Converter nur für den Download verwenden möchte, nicht. 
Wenn man den USB-Converter aber auf die Pins des AVRCPM-Serial-IF 
umlegt, kann man den Arduino Bootloader wahrscheinlich nicht mehr 
verwenden. Mit Peter Danneggers Fastboot, oder mit dem SD-Bootloader 
gehts aber.
Beitrag "Re: CP/M auf ATmega88"

Jens schrieb:
> Nicht zwingend. Ich weiß aber nicht, wie knapp es im 328 zugeht.

Platz satt.

Marcel A. schrieb:
> RX/TX ist hart verdrahtet auf die RX/TX-Pins des ATMega (PD0/PD1). Diese
> werden aber im CPM-Stick für die RAM-Adressleitungen verwendet. Im Stick

Datenbus. D.h., sie sind hochohmig, wenn nicht auf das RAM zugegriffen 
wird, bzw, können auch noch für was anderes verwendet werden.

> gibt es stattdessen einen Soft-UART auf den Pins PB0/PB1.
> Würde bedeuten, man müsste HW-mäßig auf der Arduino-Uno-Platine
> rumbrutzeln - oder?

Ja.
Oder 4-Bit RAM.

> Zum Thema Bootloader: Habe ich das da richtig verstanden - wenn ich ein
> mit AVR GCC erstelltes oder eben dieses "CPM-HEX" mit avrdude und "-c
> arduino" flashe, dann ist das so wie mit der IDE und das HEX kommt
> hinter den Bootloader (falls es passt...)?

Der Bootloader liegt am Flash-Ende. Das "HEX" kommt also davor.

Marcel A. schrieb:
> Ja, für mich würde sich die Frage stellen, ob man mit dem USB-Seriell
> irgendwie klar kommt ...

Wenn die Pins nicht umgelegt werden sollen, gehts noch mit 4-Bit RAM.
(Wenn 4-Bit RAM dann mal wieder geht...)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für so ein Arduino-Ding würde ich aber Speicher nehmen, der aktuell 
verfügbar ist. Serielle RAMs hab ich aber noch keine gesehen. (Im 
Gegensatz zu seriellen 'ROMs' [=EEPROM]).

Grüße,
Jens

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Serielle RAMs hab ich aber noch keine gesehen.

23LCV1024
Bei Mouser für 2-3€/Stück als PDIP-8/SOIC-8/TSSOP-8 lieferbar.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Konrad S. schrieb:
> 23LCV1024
Danke, sieht auf den ersten Blick ganz nett aus. Aber als 
Hauptspeicherersatz taugt es leider nicht, da der Speicher intern in 
pages (zu 32 Bytes) segmentiert wird.

Parallele Speicher (SRAM) brauchen zu viele Pins für einen Arduino-Uno.
Alternativ könnte man den Ardino MEGA 2560 nehmen (15€ bei ebay). Den 
finde ich aber nicht mehr so gängig, wie den Uno.

Oder SRAM (128k x 8) + 74164 (2x) für die Adresse.
Um 64k RAM anzusteuern braucht man
 8 Pin Daten
 2 Pin Steuerleitung (/OE & /WE)
 2 Pin Adresse (seriell über 74164)
------
12 Pins, wobei man die Adresspins mit der SD-Karte teilen kann.

Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch 
langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).

Viele Grüße,
Jens

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> da der Speicher intern in
> pages (zu 32 Bytes) segmentiert wird.

Der 23LCV1024 hat auch einen "sequential mode", da kannst du beliebig 
lesen/schreiben.

> Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch
> langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).

Klar, das ist der Preis für die geringere Anzahl an Pins.

Es gäbe auch noch serielles FRAM, z.B. FM25V02 (32kB, 6€) oder FM25V05 
(64kB, 12€). Hätte auch seinen Reiz.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Konrad S. schrieb:
>> 23LCV1024
> Danke, sieht auf den ersten Blick ganz nett aus. Aber als
> Hauptspeicherersatz taugt es leider nicht, da der Speicher intern in
> pages (zu 32 Bytes) segmentiert wird.

Spielt keine Rolle (Datenblatt):
- Byte, Page and Sequential mode for Reads and Writes

> Parallele Speicher (SRAM) brauchen zu viele Pins für einen Arduino-Uno.

Beim Arduino Uno sind alle I/O-Pins auf Steckerleisten geführt und damit 
hat er genau so viele Pins wie die 28-Pin ATmegas, die wir normalerweise 
für das Projekt nehmen.

> Alternativ könnte man den Ardino MEGA 2560 nehmen (15€ bei ebay). Den
> finde ich aber nicht mehr so gängig, wie den Uno.

Wäre (auch) eine Möglichkeit.

> Oder SRAM (128k x 8) + 74164 (2x) für die Adresse.
> Um 64k RAM anzusteuern braucht man
> 12 Pins, wobei man die Adresspins mit der SD-Karte teilen kann.
> Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch
> langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).

Wesentlich schneller, bei gleichem Hardware-Aufwand, dürfte diese 
Variante sein:
Beitrag "Re: CP/M auf ATmega88"

Das SPI-RAM wäre natürlich auch erheblich schneller.

Zusammenfassung bis hier:
Für AVR-CP/M mit Arduino Uno sind folgende Varianten denkbar:
- Onboard USB-Schnittstelle nicht benutzen
- Onboard USB-Schnittstelle umverdrahten
- 4-Bit DRAM
- 8-Bit Static-RAM mit Adress-Latches
- SPI-RAM

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Zusammenfassung bis hier:
> - SPI-RAM

Wenn Minimal dann einen SPI-RAM z.B. 23K512 oder 23K1024. Eine kleine 
Beschreibung zur Ansteuerung findet man hier:
http://www.parallax.com/sites/default/files/downloads/AN012-SRAM-v1.0.pdf

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der SRAM mit den Adress-Latches ist eine sehr gute Idee.

Leo C. schrieb:
> Zusammenfassung bis hier:
> Für AVR-CP/M mit Arduino Uno sind folgende Varianten denkbar:
> - Onboard USB-Schnittstelle nicht benutzen
> - Onboard USB-Schnittstelle umverdrahten
> - 4-Bit DRAM
> - 8-Bit Static-RAM mit Adress-Latches
> - SPI-RAM

Meiner bescheidenen Meinung nach sind nur zwei Dinge sinnvoll:
- Onboard USB nutzen
und
- 8-Bit SRAM oder SPI-RAM
und zusammen mit RTC und SD-Card auf ein Uno-kompatibles Shield.

Wenn es eine Entscheidung gibt, würde ich mich auch für Schaltplan, 
Layout und Prototypfertigung zur Verfügung stellen.

Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um AVR CP/M auf eine breitere Basis zu stellen, verfolge ich die Idee 
mit den Arduinos ja schon länger. Bisher ist eine „gute“ Lösung immer an 
den folgenden Problemen gescheitert.
 - 5V Versorgung der Arduino UNO Versionen
 - Rx/Tx Pins liegen falsch
Auch SRAM mit Latch bietet dabei keinen Ausweg. Auch hier müsste Rx/Tx 
umverdrahtet werden. Für die 3.3V Lösung müsste entweder ein 
Levelshifter für die SD-Card eingesetzt werden, oder das Arduino Board 
auf 3.3V umgestellt werden. Irgendwie alles unbefriedigend.
Eine Alternative war ein Arduino „kompatibler“ Entwurf [1]. Dazu gibt es 
von der Schaltung bis zum fertigen Layout alle Unterlagen.

Für ein „echtes“ Arduino Shield sehe ich nur die folgende Alternative:
 - Arduino UNO auf 3.3V umstellen
 - SPI-RAM (hat auch 3.3V !!) um die Original Rx/Tx Pins zu nutzen

Irgendwie alles unbefriedigend :-(

Besser sieht es mit der Arduino Pro Version aus. Die gibt es für 3.3V 
UND 20 MHz OHNE USB. Auf dieses Shield könnte der RAM (SRAM oder SPI) 
die SD-Card, die RTC und der V24-USB Wandler. Das Shield würde also bis 
auf den Prozessor das komplette CP/M System zur Verfügung stellen. Doch 
auch das macht eigentlich wenig Sinn. Dann kann man ja auch gleich auf 
[1] zurückgreifen.

[1] Beitrag "Re: CP/M auf ATmega88"

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe in der Mittagspause die Varianten nochmals überdacht.
Was haltet ihr von der folgenden Kombination:
-  Arduino UNO OHNE Änderungen (5V und Rx/Tx auf den üblichen Pins)
als COM 2 für CP/M
-  CP/M Shield mit 5V und 3.3V (Spannungsregler auf dem Shield)
-  Levelshifter nur für für SD-Card und SPI-RAM ( z.B. TXB0108)
-  RTC und I2C Porterweiterung auf 5V
-  USB oder V24 für Terminal
-  wenn noch Platz ist Propeller mit VT100 auf Shield
Um das System schnell wieder zum Laufen zu bringen, müsste nur die RAM 
Lib gegen eine neue SPI-RAM Lib ausgetauscht werden. Aber dazu könnte 
Leo C. ja vielleicht einen Kommentar zu abgeben.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt gut - aber letztlich gehen schon die Vorteile des UNO in den 
Hintergrund - es wird letztlich ja doch "nur" die CPU wiederverwendet. 
Man müsste dann 2 USB-Kabel anschließen...
Aber was meint ihr?

Mir kommt gerade noch eine andere (wahrscheinlich dumme) Frage: Die 
RAM-Chips für die 4-bit und 8-bit Adressierung (HW Varianten 1 + 2 
(Stick)) sind doch die gleichen, oder?

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mir kommt gerade noch eine andere (wahrscheinlich dumme) Frage: Die
> RAM-Chips für die 4-bit und 8-bit Adressierung (HW Varianten 1 + 2
> (Stick)) sind doch die gleichen, oder?

Edit, da Frage falsch gelesen:
Ja.

: Bearbeitet durch User
Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Was haltet ihr von der folgenden Kombination:
> -  Arduino UNO OHNE Änderungen (5V und Rx/Tx auf den üblichen Pins)
> als COM 2 für CP/M
> -  CP/M Shield mit 5V und 3.3V (Spannungsregler auf dem Shield)
> -  Levelshifter nur für für SD-Card und SPI-RAM ( z.B. TXB0108)
> -  RTC und I2C Porterweiterung auf 5V
> -  USB oder V24 für Terminal
> -  wenn noch Platz ist Propeller mit VT100 auf Shield
Für mich klingt das sehr vernünftig.

Mit Propeller drauf, wird der Platz wahrscheinlich zu knapp. Oder man 
macht den Propeller gleich auf eine zweite Platine, so das man den noch 
obenauf stapeln kann. Der braucht ja nur RX und TX.
Die RX-Signale (von Tastatur und UART) muß man irgendwie verodern.
Also irgendwie so:
 
=Propeller-Shield=
 |||||||  ||||||
===CP/M-Shield====
 |||||||  ||||||
===Arduino-Uno====
VGA und PS/2 gibt es auf dem Propeller-Shield. RAM und RTC auf dem 
CP/M-Shield und UART und CPU auf dem Arduino.

> Um das System schnell wieder zum Laufen zu bringen, müsste nur die RAM
> Lib gegen eine neue SPI-RAM Lib ausgetauscht werden.
Sollte machbar sein. Die Umstellung auf SIMM-Module war auch nicht 
wirklich schwer.

Viele Grüße,
Jens

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> SPI-RAM (hat auch 3.3V !!)

23LCV1024 geht mit 2.5V bis 5.5V.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da jetzt "alle" SPI-RAM wollen, versuchen wir mal herauszufinden, ob die
Geschwindigkeit davon im aktzeptablen Bereich liegen kann.

Zum Vergleich 8-Bit DRAM
Memory Read braucht 11 Takte.
Die Z80-Interpreter Hauptschleife braucht mindestens 25 Takte 
(NOP-Befehl). Davon die 11 Takte für den Opcode-Fetch. Bei 20MHz 
AVR-Takt würde das einem Z80 mit 3,2MHz entsprechen. Gemessen[1] hatte 
ich mal 3,1Mhz. Die Differenz dürfte an den 1ms Timer- und den 
Refresh-Interrupts liegen.

SPI-RAM ohne Cache
Die Berechnungen erfolgen unter optimalen Bedingungen: Macro, also ohne 
Call/Ret Overhead und alle benötigten Daten in Registern. Es kann also 
nur schlechter werden.

  'CS Low' + 'Out CMD+Address' + 'In Data' + 'CS High'
=     2    +    3 x (16 +1)    + (16 + 1)  +    2
= 55 + 1x17
= 72

Der NOP-Befehl würde 72+14 = 86 Takte brauchen, entsprechend
ca. 0,93 MHz Z80.

16-Bit Zugriffe könnten optimiert werden:
(55 + 2x17)/2 = 44,5 Takte pro Byte.
Bei angenommenen 20% 16-Bit Zugriffen (wer macht mal ein Profiling?) 
hätten wir ca 66 Takte pro RAM-Zugriff.

SPI-RAM mit Cache
Als hier der Vorschlag SPI-RAM kam, war meine erste Idee, daß das mit 
Cache vielleicht sogar schneller laufen könnte, als DRAM. Schließlich 
haben wir noch fast 600 Byte RAM frei. Das würde für einen 512-Byte 
großen Cache ausreichen. Wenn wir auf den FAT-Buffer verzichten, hätten 
wir sogar 1024 Byte für den Cache.

Welchen Cache brauchen wir?
Der einfachste Cache[2], mit einem einzigen Block in passender Größe, 
wie z.B. in [3], ist beim Z80 wg. der geringen Lokalität von Code und 
Daten wenig sinnvoll. Meiner Meinung nach ist er völlig ungeeignet, da 
jeder Z80-Befehl mit Datenzugriff mindestens 2 Cache-Misses erzeugen 
würde, wenn Code und Daten nicht im gleichen Block liegen. Letzteres ist 
aber sehr wahrscheinlich. Sogar dann noch, wenn der Block 1024 Byte groß 
wäre.

Das andere Extrem wäre ein mehrfach-assoziativer Cache mit möglichst 
vielen kleinen Blöcken. Diese Variante scheidet offensichlich aus, weil 
die Suche im Tag-RAM nach dem richtigen Block viel zu lange dauert. Und 
der Verwaltungsaufwand für eine Verdrängungsstrategie käme noch dazu.

Bleibt "Direct Mapped" (einfach assoziativ) mit optimaler Blockgröße und 
-Anzahl.

Damit der Cache einen Vorteil bringt, sollte der Zugriff bei einem Hit 
schätzungsweise in der Größenordnung 20 Takte oder darunter liegen. Bei 
einem Miss wird auf jeden Fall ein Vielfaches benötigt. Bei meinen 
ersten Versuchen mit 32 Blöcken a 16 Byte (oder umgekehrt) brauchte ich 
aber schon mehr als 15 Takte, um herauszufinden, ob der benötigte Block 
im Cache ist. Die Berechnung des Offsets braucht dann nochmal mindestens 
das Gleiche.

Aber vielleicht funktioniert das Ganze ja mit 4 Blöcken a 256 Byte. 
Diese Variante würde sich extrem optimieren lassen. Das Low-Byte der 
Addresse könnte z.B. direkt als Offset dienen. Die Valid- und 
Dirty-Flags könnten (falls überhaubt benötigt) evtl. in Registern 
gehalten werden.

Leider habe ich nicht die Zeit, um das alles auszuprobieren. Stattdessen 
würde ich mich lieber um mein Z180-Projekt kümmern, das ja auch so schon 
nur sehr schleppend voran kommt.

[1] Beitrag "Re: CP/M auf ATmega88"
[2] http://de.wikipedia.org/wiki/Cache
[3] 
http://www.parallax.com/sites/default/files/downloads/AN012-SRAM-v1.0.pdf

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Da jetzt "alle" SPI-RAM wollen, versuchen wir mal herauszufinden, ob die
> Geschwindigkeit davon im aktzeptablen Bereich liegen kann.

Das war doch schon eine sehr gute Abschätzung, danke!
SPI-RAM war ja auch nur ein Zugeständnis an einen unveränderten Arduino 
UNO. Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet 
werden. Letztlich ist es sinnvoller die Ressourcen in den Z180 zu 
stecken. AVR CP/M läuft ja :-)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Abschätzung. SPI-RAM ist also zu langsam.

Dann die Variante mit den Adress-Latches.
Lohnt es sich dort ein drittes Latch (für die 'Bankadresse') einzubauen?
Kennt sich jemand aus, wie das Bankswitching realisiert sein muß, damit 
CP/M 3.0 damit was anfagen kann? Dürfen die Bänke 64k groß werden, oder 
müssen die kleiner sein (16k)?

Joe G. schrieb:
> Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet
> werden.
Alternativ mußte man 4 Datenleitungen über Port C und die anderen über 
Port D abhandeln. Geht natürlich wieder auf die Performance.

Hier nochmal der Link zum Schaltplan:
http://arduino.cc/de/uploads/Main/Arduino_Uno_Rev3-schematic.pdf

Umverdrahten würde ich vermeiden wollen.

Grüße,
Jens

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Danke für die Abschätzung. SPI-RAM ist also zu langsam.

Das habe ich nicht gesagt. ;-)
Dazu müßte zu langsam erst mal definiert werden. Wie schnell es mit 
optimaler Cache-Strategie werden kann, ist auch noch offen. Es ist aber 
abzusehen, daß es auch damit deutlich langsamer bleiben wird, als 8-Bit 
DRAM.

> Dann die Variante mit den Adress-Latches.
> Lohnt es sich dort ein drittes Latch (für die 'Bankadresse') einzubauen?

Das Latch ist bereits im µC vorhanden, da die Adressleitungen A16-A18 
"ungemultiplexed" auf die µC-Ports gehen.

> Kennt sich jemand aus, wie das Bankswitching realisiert sein muß, damit
> CP/M 3.0 damit was anfagen kann? Dürfen die Bänke 64k groß werden, oder
> müssen die kleiner sein (16k)?

Siehe Bild (Quelle [1]). Die Größe des Common-Bereichs ist nicht 
festgelegt. Typische Werte liegen zwischen 4K und 32K. Wie man dieses 
Modell in Hardware (bzw. im Emulator) realisiert, ist nochmal ein 
anderes Thema.

> Joe G. schrieb:
>> Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet
>> werden.
> Alternativ mußte man 4 Datenleitungen über Port C und die anderen über
> Port D abhandeln. Geht natürlich wieder auf die Performance.

2 Leitungen verlegen würde reichen:
Arduino UNO:
     ---------------------------------------------------------------------------------
     |                          Pin Nummer ATmega (28 pol.)                          |
     +-------------------------------------------------------------------------------+
     |13 |12 |11 | 6 | 5 | 4 | 3 | 2 |19 |18 |17 |16 |15 |14 |28 |27 |26 |25 |24 |23 |
     ---------------------------------------------------------------------------------
     |         Port D                |         Port B        |         Port C        |
     +-------------------------------+-----------------------+-----------------------+
     | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0 |
     |                        TX  RX |SCK DO  DI  CS         |SCL SDA                |
     +-------------------------------+-----------------------+-----------------------+
DRAM |D3  D2  D1  D0  D3  D2         |                D1  D0 |                       |
     |A7  A6  A5  A4  A3  A2         |A10 A9  A8      A1  A0 |        WE  OE  CAS RAS|
     +-------------------------------+-----------------------+-----------------------+
SRAM |AD7 AD6 AD5 AD4 AD3 AD2        |A18 A17 A16     AD1 AD0|        WE  OE  ASH ASL|
     +-------------------------------+-----------------------+-----------------------+

ASH: Address Strobe High
ASL: Address Strobe Low
Da die Ansteuerung der beiden Latches im Prinzip weniger anspruchsvoll 
ist, als die Steuerung des DRAMs, ließe sich evtl. noch was optimieren.



[1] 
http://bitsavers.informatik.uni-stuttgart.de/pdf/digitalResearch/cpm_plus/CPM_Plus_System_Guide_Jan83.pdf

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> 2 Leitungen verlegen würde reichen:
Der Performanceverlust um aus Port D und Port B wieder ein 8-Bit Wert zu 
basteln, dürfte deutlich geringer sein als den RAM über SPI anzusteuern.

DRAM sollte sicherlich
     +-------------------------------+
DRAM |D7  D5  D5  D4  D3  D2         |
     |A7  A6  A5  A4  A3  A2         |
     +-------------------------------+
heißen.

Als VT100 habe ich gerade eine erweiterte Version für das Z180 Projekt 
in Betrieb genommen. Darauf gibt es noch einen Signalquellenumschalter. 
Somit kann vom Terminal die Eigangsquelle ausgewählt werden. Dieses 
Design ließe sich sicherlich auf ein passendes Shield bringen.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das richtig verstanden habe würde dann die Leitungen PD0/1 und 
PB0/1 vertauscht werden - rein in Software. Ist das denn von der 
Performance her realistisch?

Ansonsten denke ich auch, dass die UNOs dann als Plattform keinen Sinn 
machen, wenn außer der CPM nicht weiter verwendet werden kann.

Meine ursprüngliche Idee war eigentlich nur ein "RAM-Shield" mit 2 x 
RAM-IC und SD-Card zu ergänzen und fertig :-)

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch mal eine Frage zu den Anfängen: Wozu ist eigentlich die RST-Leitung 
auf dem USB-Seriell-Adapter auf dem CPM-Stick (HW-V2) da? Diese wird da 
mit dem Reset des ATmega verbunden...? Kann man dann aus dem Terminal 
den Stick resetten - wie?
Peter Sieg hatte einmal angemerkt, dass diese NICHT mit dem AVR-Reset 
verbunden werden sollte - ist sie aber.

Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann 
und ich die HW V3 (Joes all-in-one) schon habe wollte ich mir den mal (8 
Bit RAM) aufbauen. Aber die meisten CP2102-Adapter haben den RST nicht 
herausgeführt. Stellt sich also die Frage, ob der überhaupt notwendig 
ist.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann

Wer behauptet denn so was?
Das Ding ist schon lange "auf Z80". Daß es angeblich nicht funktioniert, 
wahrscheinlich gedebuged werden müßte, und dies zur Zeit niemand machen 
will, ist eine andere Geschichte...

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Marcel A. schrieb:
>> Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann
>
> Wer behauptet denn so was?
> Das Ding ist schon lange "auf Z80". Daß es angeblich nicht funktioniert,
> wahrscheinlich gedebuged werden müßte, und dies zur Zeit niemand machen
> will, ist eine andere Geschichte...

Ups - so habe ich das ja nicht gemeint. Ich habe da leider zu wenig Plan 
von, um selber Hand anzulegen. Muss ja auch nicht sein - ist doch so 
schon super.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ups - so habe ich das ja nicht gemeint.

Dann ist ja gut. :)
Du hast zwar 2 mal im Abstand von ein paar Wochen geschrieben, daß es 
nicht wichtig sei, aber es scheint Dich ja doch zu beschäftigen...
Deshalb habe ich mal zurück geblättert.

Marcel A. schrieb:
> So, ich habe mal meinen ersten Lochraster-Aufbau von "anno dazumal"
> ausgegraben (siehe Foto), den mit ATMega88 und 4bit RAM.
> Ich habe dem dann einen 328p spendiert und wollte die aktuelle
> "firmware" mit Z80-Unterstützung draufbringen.

Das klingt so, als wäre das Ding "anno dazumal" schon mal gelaufen. 
"Anno dazumal" gab es (mindestens) zwei 4-Bit Varianten, die leider 
schön öfter für Verwirrung gesorgt haben. In der aktuellen Software ist 
aber nur noch eine Pin-Belegung vorgesehen. Du könntest Deine 
Verdrahtung mal mit der Definition in config.inc vergleichen. 
Insbesondere diese Pins:
[avrasm]
;Port C
.equ RAM_D0  = 0
.equ RAM_D1  = 1
.equ RAM_D2  = 2
.equ RAM_D3  = 3
.equ RAM_W  = 4
.equ RAM_CAS  = 5
[avrasm]

Sicherheitshalber den Rest aber auch. Bei Unterschieden wäre es wohl am 
Besten, wenn Du Deine Verdrahtung änderst.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Wozu ist eigentlich die RST-Leitung
> auf dem USB-Seriell-Adapter auf dem CPM-Stick (HW-V2) da? Diese wird da
> mit dem Reset des ATmega verbunden...? Kann man dann aus dem Terminal
> den Stick resetten - wie?

Das Reset-Pin liegt einfach nur zur freien Verfügung auf der LP. In der 
Bestückungsvariante FTDI wird es nicht benutzt. Man könnte es jedoch auf 
RTS/CTS oder DTR/DSR legen und vom Terminal darüber Reset auslösen 
(müßte jedoch noch programmiert werden)

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:


> ;Port C
> .equ RAM_D0  = 0
> .equ RAM_D1  = 1
> .equ RAM_D2  = 2
> .equ RAM_D3  = 3
> .equ RAM_W  = 4
> .equ RAM_CAS  = 5

>
> Sicherheitshalber den Rest aber auch. Bei Unterschieden wäre es wohl am
> Besten, wenn Du Deine Verdrahtung änderst.

Hallo Leo,

ich habe noch mal alles geprüft. Ich habe wohl die 4-Bit Version "neu", 
also mit getauschten PC1/PC4. Verbindungen stimmen alle.
Derzeit läuft darauf eine Version für 8080 auf dem ATmega88. Ich kann 
leider nicht sagen, welche Version, es meldet sich mit 1.0...
Ich vermute aber mal, dass ich eine Version drin habe mit nur einem 
asm-file kompiliert und folgendem Inhalt:
#ifndef DRAM_DQ_ORDER      /* If this is set to 1, the portbits  */
  #define DRAM_DQ_ORDER 1    /* for DRAM IO3 and WE are swapped.    */
...
;Port C
#if DRAM_DQ_ORDER == 1
.equ ram_d1 =  1
.equ ram_w  =  4
#else /* original */
.equ ram_d1 =  4
.equ ram_w  =  1
#endif
.equ ram_d0 =  0
.equ ram_d2 =  2
.equ ram_d3 =  3
.equ ram_cas=  5

.equ P_W   = PORTC
.equ P_CAS = PORTC

.equ RAM_DQ_MASK = (1<<ram_d3)|(1<<ram_d2)|(1<<ram_d1)|(1<<ram_d0)
.equ PC_OUTPUT_MASK = (1<<ram_cas)|(1<<ram_w)
#endif

Die HW müsste das hier sein (ohne FTDI):
[[Beitrag "Re: CP/M auf ATmega88"]]

Also das scheint es nicht zu sein.

: Bearbeitet durch User
Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Teilweise sitzt das Problem (Z80 - 4Bit-Ram) auch vor der Tastatur... 
Ich hatte zwar das neue HEX in den 328p geflashed - aber die Fuses nicht 
angepasst - lief immer mit intern 8MHz.

Ich habe ihn nun genau wie den M88 auf "Ext-Full-Swing-Osz" (mit dem 
Eclipse-Plugin) eingestellt - lfuse=77
Oder wäre "Ext Osz > 8MHz" besser?

Nun zeigt er wenigstens "Müll" im Terminal an und zwar im richtigen 
Verhältnis/Startverhalten.... Der Müll ist aber immer das gleiche 
Zeichen. Mit den seriellen Einstellungen habe ich schon gespielt - 
bisher erfolglos. Aber ich denke, da könnte zumindest ein Teil meines 
Problems liegen.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Teilweise sitzt das Problem (Z80 - 4Bit-Ram) auch vor der Tastatur...

Das Problem sitzt fast immer vor der Tastatur. Man weiß nur oft nicht, 
vor welcher... ;-)

> lfuse=77

Wenn das Hex ist, ist die "Divide clock by 8 internally; [CKDIV8=0]" 
Fuse aktiviert.

Meine ATmega328P Fueses stehen auf:
avrdude: safemode: lfuse reads as D6
avrdude: safemode: hfuse reads as D2
avrdude: safemode: efuse reads as 7

ps:
Zum Rumspielen mit verschiedenen Einstellungen ist der "Engbedded Atmel 
AVR® Fuse Calculator" gut zu gebrauchen:
http://www.engbedded.com/fusecalc/

: Bearbeitet durch User
Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, habe ich mir gerade auch schon überlegt. Probier ich gleich aus!

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, das mit dem Takt war schon mal das Grundproblem - eigentlich ein 
Klassiker... Grrrr (Hau mit dem Kopf auf die Tischkante....).

Nun, ich habe dann sicherheitshalber auch noch mal den aktuellen Stand 
(V 154) übersetzt und geflashed. Es zeigt die gleiche Ausgabe wir der 
manuell angepasste Stand auf dem 328er:
CPM on an AVR, v3.2 r0
Testing RAM: fill...wait...reread...
Addr xx yy
0000 00 FF -------- XXXXXXXX
0001 01 FF -------- XXXXXXX-
0002 02 FF -------- XXXXXX-X
0003 03 FF -------- XXXXXX--
0004 04 FF -------- XXXXX-XX
0005 05 FF -------- XXXXX-X-
0006 06 FF -------- XXXXX--X
0007 07 FF -------- XXXXX---
0008 08 FF -------- XXXX-XXX
0009 09 FF -------- XXXX-XX-
000A 0A FF -------- XXXX-X-X
000B 0B FF -------- XXXX-X--
000C 0C FF -------- XXXX--XX
000D 0D FF -------- XXXX--X-
000E 0E FF -------- XXXX---X
000F 0F FF -------- XXXX---- System halted!

Das dort r0 angezeigt wird liegt wohl auch daran, dass ich es als 
Tar-Ball geladen habe und nicht richtig ausgeckekt habe. Muss mich mal 
mit SVN befassen...
Warning: unable to find Subversion 1.7 'working copy' metadata.
This directory may not be under version control.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Lesen der Make-Meldungen ist mir aufgefallen, dass er die 8-Bit 
Files für dram verwendet hat - musste da noch einen Schalter umlegen.
Jetzt verwendet er die 4bit-Files-aber gleiches Ergebnis.

ALso weitersuchen... :-)

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> CPM on an AVR, v3.2 r0
> Testing RAM: fill...wait...reread...
> Addr xx yy
> 0000 00 FF -------- XXXXXXXX
> 0001 01 FF -------- XXXXXXX-

Egal was ins RAM geschrieben wird, es wird immer 0xFF zurück gelesen. 
Sieht nach einem Wrie-Only-Memory aus. ;) Könnte aber auch an der 
Initialisierung liegen.

Früher (TM) sah die Portinitialisierung mal so aus:
; - Setup Ports
  ldi   temp,(1<<PUD)    ;disable pullups
  outm8  P_PUD,temp
  ldi  temp,0xFF
  out   PORTD,temp    ;all pins high
  out   PORTB,temp
  out   PORTC,temp
  out   DDRD,temp    ; all outputs
  out  DDRB,temp
  out  DDRC,temp
Du könntest in init.asm den Teil zwischen
"Setup Ports" und "outm8 TIMSK1,_0"
mal durch diese Zeilen ersetzen.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, wir sind fast am Ziel :-)

Die oben genannte Änderung führ zur folgenden Ausgabe:
CPM on an AVR, v3.2 r0
Testing RAM: fill...wait...reread...
Initing mmc...

A: CP/M partition at: 062, size: 7657KB.
B: CP/M partition at: 15376, size: 7688KB.
C: CP/M partition at: 30752, size: 7688KB.
D: CP/M partition at: 46128, size: 7688KB.
Partinit done.
Ok, Z80-CPU is live!

Danach bleibt der Cursor aber stehen.
Kann das daran liegen, dass das CPM auf der SD noch für einen 8080 ist?

Wenn ich die SD-Card aus dem HW-4 Projekt (mit Propeller) reinstecke, 
kommt:
CPM on an AVR, v3.2 r0
Testing RAM: fill...wait...reread...
Initing mmc...

A: FAT16 File-Image 'A' at: 003, size: 256KB.
B: FAT16 File-Image 'B' at: 007, size: 256KB.
C: FAT16 File-Image 'C' at: 011, size: 256KB.
D: FAT16 File-Image 'D' at: 023, size: 8192KB.
E: FAT16 File-Image 'E' at: 015, size: 250KB.
F: FAT16 File-Image 'F' at: 019, size: 256KB.
G: FAT16 File-Image 'G' at: 283, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!

62k cp/m vers 2.2

A>dir

Bei Eingabe von "dir" stürzt er aber ab.

Hängt das ggf. mit diesen Einstellungen im MakeFile zusammen 
(FAT/CPM-Support)?
#FAT16_SUPPORT = 0
#CPMDSK_SUPPORT = 0
#MMCBOOTLOADER = 0


Das "Problem" in der Init.asm für 4-bit liegt für mein (rudimentäres) 
Assembler-Verständnis darin, dass in der aktuellen Fassung:
; - Setup Ports

;  ldi   temp,(1<<PUD)    ;disable pullups
;  outm8  P_PUD,temp
  out   PORTD,_255    ;all pins high (enables pullup on input ports)
  out   PORTB,_255
  out   PORTC,_255
  out   DDRD,_255    ; PD all outputs
#if I2C_SUPPORT
  ldi  temp,~((1<<SCL)|(1<<SDA))
  out  DDRC,temp 
#endif
#if DRAM_8BIT
  ldi  temp,~(1<<RXD)
  out  DDRB,temp
#endif

die "out DDRC" und "out DDRB" in den IF-Schachteln stecken und daher bei 
4-Bit nicht angesprochen werden und damit die Ports nicht richtig 
initialisiert werden.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Kann das daran liegen, dass das CPM auf der SD noch für einen 8080 ist?

Nein, daß könnte der Z80-Emulator (mindestens) genau so gut. Es liegt 
eher daran, daß das BIOS nicht mehr zu der Schnittstelle im Emulator 
paßt.

> Wenn ich die SD-Card aus dem HW-4 Projekt (mit Propeller) reinstecke,

Welcher Firmwarestand ist den auf dem Gerät drauf?
Könnte das gleiche Problem sein, ich glaubs aber eher nicht. 
Wahrscheinlich ist noch was anderes faul.

Marcel A. schrieb:
> die "out DDRC" und "out DDRB" in den IF-Schachteln stecken und daher bei
> 4-Bit nicht angesprochen werden und damit die Ports nicht richtig
> initialisiert werden.

Die IF-Schachteln habe ich erst kürzlich eingebaut, eben wegen dem 4-Bit 
RAM. War offensichtlich ein Schuß in den Ofen.


Fast vergessen:
Ich wollte ein Image mitschicken, daß mit Deinem Softwarestand auf jeden 
Fall laufen sollte. Leider habe ich gerade ein Problem.

: Bearbeitet durch User
Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So - es läuft FAST alles.

Das meine Karte aus der alten HW gar nicht geht ist klar - das war noch 
das Partitions-Schema und nicht das FAT16-System.

Den Fehler mit dem Absturz nach dem Boot habe ich sowohl mit meinem CPM 
Image als auch mit dem von Leo. Aber nicht immer. Meistens startet er 
durch, ich kann auch einiges machen.

Es fällt aber auf, dass einige Zeichen "komisch" sind...

Ich konnte sogar Turbo Pascal starten

Der Aufruf von kompilierten COM-Dateien geht dafür aber wieder.

Manchmal klappt auch der Wechsel der Disketten - manchmal nicht.
Habe auch mal die Geschwindigkeit von 57600 auf 38400 geändert - keine 
Änderung.

Hier mal ein Auszug, was sich so tut und was für Fehlermeldungen kommen. 
Ich würde sagen: Im Grund geht es jetzt - aber irgendwo ist noch was 
faul.

Was wäre eigentlich der Vorteil der 8bit-Variante? War das nur 
Geschwindigkeit?

Leo, das mit den IFs war sicher kein Schuss in den Ofen. Das war schon 
genau das Problem, wahrscheinlich müsste man die IFs nur anders 
aufbauen.

A: FAT16 File-Image 'A' at: 003, size: 256KB.
B: FAT16 File-Image 'B' at: 007, size: 256KB.
C: FAT16 File-Image 'C' at: 011, size: 256KB.
D: FAT16 File-Image 'D' at: 023, size: 8192KB.
E: FAT16 File-Image 'E' at: 015, size: 250KB.
F: FAT16 File-Image 'F' at: 019, size: 256KB.
G: FAT16 File-Image 'G' at: 283, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!

62k cp/m vers 2.2

A>c:
C>dir
62k cp/m vers 2.2

A>dir
A: CPMSTAT  COM : DDT      COM : DDTZ     COM : TD       CFG
A: COPY     CFG : LDTIM    COM : SIMHCLOK REL : AVRCLOCK REL
A: COPY     UPD : COPY     COM : CPU      COM : DO       COM
A: DUMP     COM : ED       COM : TD       COM : WIPE     COM
A: STAT     COM
A>

B>turbo

ZSDOS error on Á: No Drive
Call: 14

B>
--------------------------------- 
  CPM on an AVR, v3.2 r0
Testing RAM: fill...wait...reread...
Initing mmc...

A: FAT16 File-Image 'B' at: 007, size: 256KB.
B: FAT16 File-Image 'C' at: 011, size: 256KB.
C: FAT16 File-Image 'D' at: 023, size: 8192KB.
D: FAT16 File-Image 'E' at: 015, size: 250KB.
E: FAT16 File-Image 'F' at: 019, size: 256KB.
F: FAT16 File-Image 'G' at: 283, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!

62k cp/m vers 2.2

A>dir
A: TEST     BAK : TINST    COM : TINST    DTA : TINST    MSG
A: TURBO    COM : TURBO    MSG : TURBO    OVR : TEST     COM
A: TEST     PAS : BLOCK    PAS : BLOCK    BAK : BDOS     COM
A: BDOS     PAS : BDOS     BAK : RTCDEMO  PAS : RTCDEMO  COM
A: ANSITEST BAK : ANSITEST PAS
A>test
Das ist ein AVR CP/M Test in Turbo Pascal 3.0
Hello Word VT100 Test !

A>

Logged drive: A

Work file:
Main file:

Edit     Compile  Run   Save

eXecute  Dir      Quit  compiler Options

Text:     ð bytes (8118-8118)
Free: ððððð bytes (8119-E006)

>
Dir mask:
TEST     BAK : TINST    COM : TINST    DTA : TINST    MSG : TURBO    COM
TURBO    MSG : TURBO    OVR : TEST     COM : TEST     PAS : BLOCK    PAS
BLOCK    BAK : BDOS     COM : BDOS     PAS : BDOS     BAK : RTCDEMO  PAS
RTCDEMO  COM : ANSITEST BAK : ANSITEST PAS

Bytes Remaining On A: ðððk
>

--- Editor gestartet (test.pas):

^K^K^K^K^K 1    Col 69  Insert    Indent  A:TEST.PAS
     C  A =1D BC =611E DE =423F HL =1FB7 SP=E3FC PC=7CEB       76 61 6C
  H NC  a'=00 bc'=0000 de'=0000 hl'=0000 IX=7BF3 IY=446C I=00       CPU halted!
 
A>b:
B>dir
B: C        CCC : C        SUB : CC2      COM : CC       COM
B: CLIB     COM : CLINK    COM : DEFF2    CRL : DEFF     CRL
B: BDS      LIB : STDIO    H   : TTT2     C   : MMIND    C
B: OTHELLO  C   : STONE    C   : ED       COM : OTHELLO  CRL
B: STONE    $$$
B>ed

Bdos Err On P: Select

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Es fällt aber auf, dass einige Zeichen "komisch" sind...
Wirklich sehr mysteriös.

> Habe auch mal die Geschwindigkeit von 57600 auf 38400 geändert - keine
> Änderung.
>
> Hier mal ein Auszug, was sich so tut und was für Fehlermeldungen kommen.
> Ich würde sagen: Im Grund geht es jetzt - aber irgendwo ist noch was
> faul.
Ich hätte da immer noch das Speichertiming im Verdacht.

> Was wäre eigentlich der Vorteil der 8bit-Variante? War das nur
> Geschwindigkeit?
Meines Erachtens: ja

Grüße,
Jens

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sollte ich mal den Speicher tauschen?

Hm... Es stellt sich die Frage, ob es wirklich den Aufwand lohnt, das 
Thema 4Bit "gerade" zu biegen. Einziger Grund kann ja letztlich nur 
sein, dass die DRAMs nicht mehr ganz so leicht zu beschaffen sind.

Ich denke, ich werde als nächsten mal den "Stick" bauen, dann habe ich 
fast alles (alte) HW zusammen und kann dann hoffentlich mit dem Z180 
Projekt anfangen.

Über Weihnachten werde ich mal mehr über den Z80 und CPM lesen.
(Rolf-Dieter Klein's Buch, Rodnay Zak, NCR Kleinkomputer.... Schon nett 
:-))

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vielleicht sollte ich mal den Speicher tauschen?

Eher nicht. Auch wenn es wirklich Timing-Probleme sind, heißt das nicht, 
das es am RAM-Chip liegt. Ich vermute aber eher, daß die Initialisierung 
immer noch nicht in Ordnung ist, bzw. daß Port-Register irgendwo 
verändert werden, wo sie es nicht sollten. Es ist etwas mühsam, das 
durch starren auf den Bildschirm herauszufinden. Vielleicht stecke ich 
mir doch mal so ein System zusammen. Dieses Jahr aber nicht mehr.

Autor: Cord J. (cord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich möchte auch endlich mal den CP/M Computer nachbauen.
Hat noch jemand eine von diesen Platinen übrig?

http://www.mikrocontroller.net/articles/Datei:Avr_cpm2.jpg

Wenn nicht, würde ich gerne welche fertigen lassen. Hat sonst noch 
jemand Interesse? Ich hätte auch noch ein paar Speicherchips KM44C4100 
oder M5M44256
abzugeben.

Gruß
  Cord

Autor: Marcel A. (dl1ekm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe gerade das CP/M-Stick-Layout (Peter Sieg) überarbeitet (ohne 
FTDI, für gängige USB-Sticks, etwas kleiner und für "günstigere" SD Card 
Reader.

Die Platinen sind bestellt, dauert aber eine Weile. Teile wie USB-Sticks 
und Reader habe ich auch... Bei Bedarf einfach melden.

Gruß
Marcel

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht ganz so schlank wie CPM auf dem Atmega88, aber vielleicht trotzdem 
interessant: CPM auf dem Arduino Due.
http://sourceforge.net/projects/cpmduino/

Autor: Peter S. (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Hi,
>
> ich habe gerade das CP/M-Stick-Layout (Peter Sieg) überarbeitet (ohne
> FTDI, für gängige USB-Sticks, etwas kleiner und für "günstigere" SD Card
> Reader.
>
> Die Platinen sind bestellt, dauert aber eine Weile. Teile wie USB-Sticks
> und Reader habe ich auch... Bei Bedarf einfach melden.
>
> Gruß
> Marcel

@Marcel: Das PCB Layout/Schaltung stammt von Joe G., nicht von mir.
Kannst du bitte deine Überarbeitete Version als Eagle Dateien hier zur 
Verfügung stellen? Welcher SD Slot ist jetzt verwendet?

Peter

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

die egale-Datei ist auf meiner Homepage

http://www.retro-compi.de/index.php/cpm-z80-projekte/cpm-stick/cpmstick-hardware

unten zum Download verfügbar.

Es passen die Adapter z.B. von "Pollin" oder aus China. Ich habe auch 
gute Erfahrungen mit den Micro-SD-Slots von Pollin/China gemacht.

Gruß
Marcel

Autor: petersieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh. Super! Vielen Dank.

Peter

Autor: Pruunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es irgendwo Layout Dateien der neuesten Version mit AVR Terminal ?

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pruunz schrieb:
> Gibt es irgendwo Layout Dateien der neuesten Version mit AVR Terminal ?

Ja, bei mir. Sende mir einfach eine Mail.

Autor: Christian D. (toast_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich spiele ja schon seit einiger Zeit gerne mit dem AVRCP/M rum.
Dabei habe ich inzwischen schon öfter den Wunsch nach einer freien 
RS232-Schnittstelle verspürt.
Man könnte diese dann prima für Dateiübertragungen zur 'richtigen' CP/M 
Systemen benutzen.
Die vorhandene ist ja ausschließlich fürs Terminal.

Inwieweit wäre sowas realisierbar ?

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt 
fertige Chips, die aber teuer und schlecht erhältlich sind.
Vor einiger Zeit hatte ich mal angefangen, so einen I2C-UART mit einem 
ATTiny2313 zu realisieren. Mangels eigenem Bedarf und übertriebener 
Featuritis ist das Projekt irgendwann liegen geblieben.

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> -itis

Entzündung?

Man kann auch einen Bitbanging UART auf freien Pins verwenden. Meistens 
ist auch keine echte bidirektionale Verbindung nötig, also kommt man auf 
dem Controller mit einem Pin aus, bei Bedarf als Eingang oder Ausgang.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils S. schrieb:
> Man kann auch einen Bitbanging UART auf freien Pins verwenden.

Klar

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt
> fertige Chips, die aber teuer und schlecht erhältlich sind.

Den SC16IS740 gibt es für 2,77€/Stück bei Mouser.

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
AVR-CP/M-Propeller-Terminal

Hier mal was zum Testen. Neue/aufgebesserte Software für das Terminal. 
Liegt auch schon seit ein paar Tagen auf dem SVN-Server[1]. Ein paar 
Fehler wurden beseitigt, ein paar weitere VT100-Funktionen hinzu gefügt, 
und etwas schneller ist sie auch.

Ich habe vor, die Software noch weiter auszubauen und zu beschleunigen. 
Außerdem soll sie an die stand-alone Version des Terminals[2] angepaßt 
werden, zumal Joe mir eine Platine dafür geschenkt hat.



[1] 
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/source/work/
[2] Beitrag "VT100-Terminal (VGA+PS2)"

Autor: Xyz X. (Firma: xyz) (khmweb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Warum? Weil es geht! Und weil es Spaß macht zu zeigen, das es geht..
> Und weil ein ATmega88 ca. 3€ kostet, eine solches DRam gibts in der
> Schrottkiste (sind z.B beim Amiga 500 verwendet worden..) also alles
> für ca. 6-8€..

Noch preiswerter, zum Nulltarif, aber hier wohl weniger von Reiz: CP/M 
unter Windows mittels kostenfreiem, seit vielen Jahren bewährtem Emu, z. 
B. via download von meiner site sharpmz.org. Dort gibts auch 
verschiedene CP/M-Versionen, haufenweise Spiele, tonnenweise Software, 
diskimages und und und... Der schnellste Weg, um CP/M zum Laufen zu 
bringen. Anleitung bei Interesse im eigenen Thread oder via PN.

: Bearbeitet durch User
Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Propeller-Terminal für die AVR-CP/M-Platine

Die Entwicklung der Software geht im Thread "VT100-Terminal (VGA+PS2)" 
hier

Beitrag "Re: VT100-Terminal (VGA+PS2)"

weiter, da die Hardwareunterschiede zwischen den beiden Terminals ja 
gering sind.

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
>> Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt
>> fertige Chips, die aber teuer und schlecht erhältlich sind.
>
> Den SC16IS740 gibt es für 2,77€/Stück bei Mouser.

Oder knapp 9€ für 5 Stück inclusive alles beim Ali.
Also gut, gestern sind sie angekommen, und mindestens einer funktioniert 
sogar. Deshalb gibts im SVN jetzt minimalen Support für den Chip. Die 
Register des UARTs sind zwischen 50H und 5FH in den I/O-Addressraum des 
Z80 gemappt, können also mit IN- und Out-Befehlen angesprochen werden. 
Einfache In- und Out-Routinen können dann z.B. so aussehen:
;----------------------------- ISC16IS740 UART -------------------------------
I2C_UART_PORT   equ     50H

I2C_UART_RHR    equ     I2C_UART_PORT+00H       ;R      Receive Holding
I2C_UART_THR    equ     I2C_UART_PORT+00H       ;W      Transmit Holding
I2C_UART_IER    equ     I2C_UART_PORT+01H       ;R/W    Interrupt Enable
I2C_UART_FCR    equ     I2C_UART_PORT+02H       ;W      FIFO Control
I2C_UART_IIR    equ     I2C_UART_PORT+02H       ;R      Interrupt Identification
I2C_UART_LCR    equ     I2C_UART_PORT+03H       ;R/W    Line Control
I2C_UART_MCR    equ     I2C_UART_PORT+04H       ;R/W    Modem Control
I2C_UART_LSR    equ     I2C_UART_PORT+05H       ;R      Line Status
I2C_UART_MSR    equ     I2C_UART_PORT+06H       ;R      Modem Status
I2C_UART_SPR    equ     I2C_UART_PORT+07H       ;R/W    Scratchpad
I2C_UART_TCR    equ     I2C_UART_PORT+06H       ;R/W    Transmission Control
I2C_UART_TLR    equ     I2C_UART_PORT+07H       ;R/W    Trigger Level
I2C_UART_TXLVL  equ     I2C_UART_PORT+08H       ;R      Transmit FIFO Level
I2C_UART_RXLVL  equ     I2C_UART_PORT+09H       ;R      Receive FIFO Level
I2C_UART_EFCR   equ     I2C_UART_PORT+0FH       ;R/W    Extra Features
I2C_UART_DLL    equ     I2C_UART_PORT+00H       ;R/W    divisor latch LSB
I2C_UART_DLH    equ     I2C_UART_PORT+01H       ;R/W    divisor latch MSB
I2C_UART_EFR    equ     I2C_UART_PORT+02H       ;R/W    Enhanced Feature
I2C_UART_XON1   equ     I2C_UART_PORT+04H       ;R/W    Xon1 word
I2C_UART_XON2   equ     I2C_UART_PORT+05H       ;R/W    Xon2 word
I2C_UART_XOFF1  equ     I2C_UART_PORT+06H       ;R/W    Xoff1 word
I2C_UART_XOFF2  equ     I2C_UART_PORT+07H       ;R/W    Xoff2 word


;-----------------------------------------------------------------------------
; Output character in C
; Return with character in  C and A

i2c_uart_out:
        IN   A,(I2C_UART_LSR)
        AND  20H
        JR   Z,i2c_uart_out     ; wait till ready
        LD   A,C
        OUT  (I2C_UART_THR),A
        RET

;-----------------------------------------------------------------------------
; Get character from I2C UART
; Return character in A

i2c_uart_in:
        IN   A,(I2C_UART_LSR)
        AND  01H
        JR   Z,i2c_uart_in     ; wait till ready
        IN  (I2C_UART_RHR),A
        RET

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schön!
Nun noch einen modernen DRAM (aktuell verfügbar) und das Z180 Projekt 
bekommt ernsthafte Konkurenz ;-)

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Never, ever ;-)

Es sei denn, man tauscht auch noch den µC, z.B. gegen einen Cortex-M.

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für den I2C-UART gibts jetzt ein Kermit. Damit er läuft braucht man die 
neueste Firmware. Beides als Binaries im Anhang. Die Kermit-Quellen sind 
vorläufig auf meinem Server[1], und kommen demnächst ins hiesige SVN.


[1] http://cloudbase.mooo.com/cgit/Kermit-80/

Autor: Andreas R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mir kürzlich auch einen avrcpm-Rechner zusammengebaut mit 
ATmega328P, 20 MHz, 8bit DRAM und einer 1 GB SD-Karte.
Als Firmware hatte ich erst die Version 3.2 r154, dann Version 3.5 r242. 
Die Anbindung über RS232 zum PC läuft mit einem CP2102-Dongle und 115200 
baud. Einen I2C-UART habe ich noch nicht angeschlossen.
Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der 
Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:
Kermit läuft zwar unter CP/M im avrcpm und ich kann im Prinzip auch 
Dateien zwischen PC und avrcpm hin- und herschicken (ich verwende 
TeraTerm und dessen eingebautes Kermit-Protokoll auf der PC-Seite), aber 
die Transferrate ist mit ca. 20 Bytes/s nicht brauchbar.

Ich habs so probiert: auf der CP/M-Seite kerm411.com gestartet und die 
folgenden Befehle im Kermit abgesetzt:
set local-echo on
set port crt
receive
danach in TeraTerm mit File/Transfer/Kermit/Send... eine Datei 
ausgewählt und übertragen. Diese ist dann im CP/M System auch 
angekommen, aber mit nur ca. 20 Bytes/s.

Die umgekehrte Richtung geht auch:
im CP/M-Kermit diese Befehle absetzen:
set local-echo on
set port crt
send foo.bar
dann in TeraTerm File/Transfer/Kermit/Receive
foo.bar kommt dann auf dem PC an, aber auch nur mit der langsamen 
Transferrate von ca. 20 Byte/s.

Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja 
im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein 
ist...

Gruss,

Andreas

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

ich hatte das auch schon für die Z180 Stamp gebaut. Aber dort habe ich 
für die "Console" und die Kermit-Schnittstelle zwei unterschiedliche 
Ports genommen. Mich wundert, dass das überhaupt über die gleiche 
geht...?

Gruß
Marcel

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas R. schrieb:
> Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der
> Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:

Du hast ein "Generic Kermit-80" gebaut?

> set local-echo on

Das dürfte für Dateiübertragung keine Rolle spielen. Im Zweifelsfall ist 
es eher kontraproduktiv.

> set port crt

Das dürfte überflüssig sein, weil die IOBYTE-Funktionalität im 
AVR-CP/M-BIOS nicht implementiert ist.

Versuch' mal noch ein:
set terminal quiet

Dann werden während der Dateiübertragung keine Zeichen auf die Console 
ausgegeben.

> Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja
> im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein
> ist...

Marcel A. schrieb:
> Mich wundert, dass das überhaupt über die gleiche
> geht...?

me too.

Autor: Andreas R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die Rückmeldungen.

Leo C. schrieb:
> Andreas R. schrieb:
>> Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der
>> Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:
>
> Du hast ein "Generic Kermit-80" gebaut?
>

Genau...

>> set local-echo on
>
> Das dürfte für Dateiübertragung keine Rolle spielen. Im Zweifelsfall ist
> es eher kontraproduktiv.
>

Stimmt, wie sich herausgestellt hat, macht dieser Befehl keinen 
Unterschied...

>> set port crt
>
> Das dürfte überflüssig sein, weil die IOBYTE-Funktionalität im
> AVR-CP/M-BIOS nicht implementiert ist.

Dieser Befehl ist aber offenbar (bei mir zumindest) nötig, sonst bekomme 
ich gar keine Kermit-Verbindung hin...

> Versuch' mal noch ein:
> set terminal quiet
>
> Dann werden während der Dateiübertragung keine Zeichen auf die Console
> ausgegeben.

Das hat bei mir nichts gebracht, d.h. die Transferrate ist immer noch 
bei ca. 20 Bytes/s :-(

>> Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja
>> im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein
>> ist...
>
> Marcel A. schrieb:
>> Mich wundert, dass das überhaupt über die gleiche
>> geht...?
>
> me too.

Geht es vielleicht, weil ich TeraTerm unter Windows benutze? Ich habs 
noch nicht unter Linux (mit z.B. minicom) probiert...

Danke und Gruss,

Andreas

Autor: Leo C. (rapid)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Inzwischen habe ich mir auch ein "Kermit-80 v4.11 configured for Generic 
CP/M-80 with VT100" gebaut und einiges ausprobiert. Im Grunde hätte aber 
etwas Nachdenken und ein Blick in den Sourcecode gereicht, um darauf zu 
kommen, daß das nicht funktionieren kann. ;-)

Das Kermit-Programm fragt während der Übertragung eines Pakets auch 
immer die Consolenschnittstelle ab, damit der Benutzer die Übertragung 
ggf. abbrechen kann (Funktion inchr in cpspk2.asm). Da Com.- und 
Consolenschnittstelle aber die Gleiche ist, werden dadurch Zeichen, die 
zu Datenpaketen gehören, als Consoleninput gelesen, und verworfen.

Wenn man die Consolenabfragen an den entsprechenden Stellen rauswerfen 
würde, könnte es funktionieren...

Autor: Andreas R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Leo C. schrieb:
> Inzwischen habe ich mir auch ein "Kermit-80 v4.11 configured for
> Generic
> CP/M-80 with VT100" gebaut und einiges ausprobiert. Im Grunde hätte aber
> etwas Nachdenken und ein Blick in den Sourcecode gereicht, um darauf zu
> kommen, daß das nicht funktionieren kann. ;-)
>
> Das Kermit-Programm fragt während der Übertragung eines Pakets auch
> immer die Consolenschnittstelle ab, damit der Benutzer die Übertragung
> ggf. abbrechen kann (Funktion inchr in cpspk2.asm). Da Com.- und
> Consolenschnittstelle aber die Gleiche ist, werden dadurch Zeichen, die
> zu Datenpaketen gehören, als Consoleninput gelesen, und verworfen.
>
> Wenn man die Consolenabfragen an den entsprechenden Stellen rauswerfen
> würde, könnte es funktionieren...

Vielen Dank Leo, das war der entscheidende Hinweis!

Ich habe in cpspk2.asm, Zeile 936 den Befehl
  call  inpcon    ; Try to get a character from the console
durch drei NOPs ersetzt - nun kriege ich vernünftige 
Kermit-Datenübertragungsraten hin (ca. 700 Byte/s für PC->avrcpm und ca. 
1.4 kByte/s für avrcpm->PC). Ich verwende TeraTerm unter Windows - ich 
werde aber auch noch minicom unter Linux testen. Ausserdem muss ich noch 
weitere Tests machen zur Zuverlässigkeit der Datenüebertragung.
Konkret habe ich aber nicht den Kermit-Sourcecode geändert und neu 
kompiliert, sondern mein kerm411.com gepatcht: die Bytefolge "CD 1A 70" 
bei Offset 2A19 wurde durch "00 00 00" ersetzt.

Ich glaube, nun haben wir einen bequemen Weg, Dateien von und zum avrcpm 
zu übertragen, ohne jedesmal mit der SD-Karte hantieren zu müssen. Was 
fehlt ist halt die Möglichkeit, die Datenübertragung zu unterbrechen - 
man muss wohl den avrcpm mit dem Resettaster neu starten, falls das 
nötig ist...

Grüsse und schönes Wochenende,

Andreas

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Für den I2C-UART gibts jetzt ein Kermit.

Prima, läuft...

A>kerm411
Kermit-80 v4.11 configured for AVR-CP/M with VT100
UART detected, crystal frequency: 11.0592 MHz.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hat das ganze mal jemand auf einem Arduino Nano umgesetzt:
https://acdc.foxylab.com/node/76

Das einzige zusätzliche Bauteil ist eine SD-Karte, die auch gleich als 
RAM herhalten muß.

Hier noch das passende Video, für die, die kein Russisch können oder 
Google-Translate nicht kennen:
Youtube-Video "CP/M 2.2 & Arduino Nano 3.0"

Grüße,
Jens

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info!
Eine sehr interessante Lösung, die SD-Card gleich als RAM zu nutzen. 
Warum sind wir nicht darauf gekommen :-( Einzig die Umsetzung in GO 
scheint mir recht langsam und die Beschränkung auf einen 8080. Aber mit 
einer Micro-SD sollte nun ein CP/M in einem kleinen USB-Stick Gehäuse 
möglich sein :-)

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Eine sehr interessante Lösung, die SD-Card gleich als RAM zu nutzen.

Stimmt.

> Warum sind wir nicht darauf gekommen :-( Einzig die Umsetzung in GO

Weil "uns" sogar SPI-RAM schon zu langsam war. Siehe 
Beitrag "Re: CP/M auf ATmega88" ff.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Einzig die Umsetzung in GO scheint mir recht langsam

Wenn ich den durch Google-Translate gedrehten Text richtig verstehe, ist 
nur das PC-Programm zum Senden einer Hex-Datei an den Arduino, in Go 
geschrieben. Von der Arduino-Software (Monitor und Emulator) habe ich 
keine Quellen gefunden.

> und die Beschränkung auf einen 8080.

Reicht für mindestens 99% aller verfügbaren CP/M Programme. Aber soll ja 
trozdem noch geändert werden.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> nur das PC-Programm zum Senden einer Hex-Datei an den Arduino, in Go
> geschrieben.

Stimmt, habe ich dann auch gelesen. Mein Russisch ist echt eingerostet, 
ich habe buchstabiert wie ein Anfänger :-(
Den Simulator hat er offensichtlich selbst programmiert ohne das die 
Quellen derzeit verfügbar sind.
"я решил две задачи - создал эмулятор процессора Intel 8080."

: Bearbeitet durch User
Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Den Simulator hat er offensichtlich selbst programmiert ohne das die
> Quellen derzeit verfügbar sind.

Sind jetzt verfügbar [1], alles in C++ umgesetzt.

[1] https://github.com/Dreamy16101976/cpm4nano

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
>> Offenbar verändert SYSGEN die Laufwerkscharakteristik.
>
> SYSGEN kopiert höchstwahrscheinlich ab Track 0, Sektor 1, weil auf
> Floppies die Sektornumerierung bei 1 beginnt. Da unsere Sektor-zählung
> bei 0 beginnt, wird der erste Sektor nicht mitkopiert. Dieser enthält
> beim simh-Format nicht nur den IPL, sondern auch eine Formatkennung.
> Wenn diese nach dem Kopieren fehlt, wird das (ursprünliche)
> AVRCPM-Standardformat angenommen.
>
> Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL
> orientieren, oder die Diskgeometrie aus dem BIOS auslesen, und dann
> konsequenter weise auch die BIOS-Funktion für Sector-Translate
> verwenden.
Das habe ich jetzt gemacht. Ich habe syscop.c [1] für unsere Zwecke 
modifiziert.
Als Compiler habe ich BDS-C verwendet:
C>CC AVRSYSCP
BD Software C Compiler v1.60  (part I)
  24K elbowroom
BD Software C Compiler v1.60 (part II)
  25K to spare
C>CLINK AVRSYSCP
BD Software C Linker   v1.60

Last code address: 2BCE
Externals start at 2BCF, occupy 0006 bytes, last byte at 2BD4
Top of memory: DA05
Stack space: AE31
Writing output...
  35K link space remaining

Anschließend kann man entweder die Systemspuren in eine Datei sichern:
C>AVRSYSCP A: SYSTRKS.BIN 52

oder -tada- eine Datei in die Systemspuren schreiben:
C>AVRSYSCP CPM.BIN A:

Wenn ich das richtig verstanden habe, muß bei 8MB-Images die 
Formatkennung "<CPM_Disk>" am Ende des ersten Sektors (0x76...0x7f) 
stehen, damit das modifizierte Image funktioniert.

Die Anpassung dafür könnte in IPL.MAC stattfinden.
Ein weiteres .org im Quelltext führt zu einem
B>m80 =ipl8m/m
P                                       org     176h

1 Fatal error(s)
Weiß jemand, wie man das richtig macht?

Viele Grüße,
Jens


[1] 
http://www.classiccmp.org/cpmarchives/cpm/Software/WalnutCD/cpm/utils/dskutl/syscop.c

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Ein weiteres .org im Quelltext führt zu einem
> B>m80 =ipl8m/m
> P                                       org     176h

Das ".org" hast Du am Ende vor dem "end" eingefügt?

Wahrscheinlich mußt Du davor noch ein ".dephase" schreiben.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wahrscheinlich mußt Du davor noch ein ".dephase" schreiben.
Ja, das scheint zu klappen.

Ich habe auch noch einen anderen Weg gefunden.
Wenn man mit DDT die Teile zusammenlinkt, kann man noch die folgenden 
Kommandos anhängen:
S176
3C
43
50
4D
5F
44
69
73
6B
3E
.
D170

Danke,
Jens

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr,

ich kann ein AVR CP/M Stick in der Rev.3 (USB Stick Form) bekommen, 
inkl. USB TTL Wandler, welcher afaik als Terminal Zugang dient.

Ich komme aus der DOS Zeit, bzw. dem ehem. DDR BIC 5105/ 5110.

Ich habe mir schon einige CP/M Emulatoren geholt, um üben zu können. Ich 
scheitere aber am erstellen der Disketten, bzw. am einbinden/ mounten 
der Disketten. Ich habe JAZE 2.04.x und einen Z80 Emulator getestet. Bei 
JAZE 2.4.x habe ich mir eine Diskette erstellt, bekomme aber die 
herunter geladenen Programme nicht auf die virtuelle Diskette... Den Z80 
Emulator 1.0.10.x bekomme ich nicht einmal gestartet. Was das angeht, 
ist JAZE doch einfacher zu starten, da dieser vorkonfiguriert ist und 
eine CP/M Version bei liegt.

Ich möchte mir gerne ein solchen Stick holen, um die frühere Zeit der 
Computer kennen zu lernen. Ich habe und hatte ältere Computer, will aber 
etwas näher an die Wurzeln heran. Bevor ich das aber mache, will ich das 
zuerst einmal Virtuell sehen.

Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den 
i8080 testen kann, bevor ich mir einen solchen Stick bauen lasse?

LG Ronny

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ronny M. schrieb:
> Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den
> i8080 testen kann

YAZE hast du ja schon genannt. Neben vielen anderen 
Simulationsprogrammen gibt es noch AltairZ80 [1]. Dort lassen sich u.a. 
verschiedene Betriebssysteme u.a. CP/M, simulieren.

[1] http://schorn.ch/index.html

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Ronny M. schrieb:
>> Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den
>> i8080 testen kann
>
> YAZE hast du ja schon genannt. Neben vielen anderen
> Simulationsprogrammen gibt es noch AltairZ80 [1]. Dort lassen sich u.a.
> verschiedene Betriebssysteme u.a. CP/M, simulieren.
>
> [1] http://schorn.ch/index.html

Ich bekomme leider keine Diskimages für Yaze erstellt, bzw. keine 
Programme in eine *ydsk rein geschoben.. Weist Du, wie das geht?

Danke für dem Tipp zum Altair Emulator. Ich denke aber, dieser passt 
nicht zum Rev. 3 Board. Da ist wohl YAZE passender. Nur, wie bekomme ich 
eine Datei, ein Program auf die *.ydsk...?

Vielen Dank für die Hilfe :)

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ronny M. schrieb:
> Danke für dem Tipp zum Altair Emulator. Ich denke aber, dieser passt
> nicht zum Rev. 3 Board. Da ist wohl YAZE passender.

Mit YAZE habe ich noch nicht gearbeitet aber was hat die Rev. 3 was 
anders sein sollte? Ist doch auch nur ein AVR mit RAM. Und CP/M ist 
CP/M. Ich hatte damals alle meine Laufwerke unter dem AltairZ80 
erstellt.

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das hat sich inzwischen erledigt. YAZE habe ich wieder gelöscht. SIMH 
Altair Z80 hat die Aufgabe der Emulation übernommen. Aber auch das hat 
sich in einigen Tagen erledigt. Peter Sieg hat in der Bucht ein Set aus 
CPM Stick + USB-Serial Adapter angeboten, welches ich mir gekauft habe.

Das ganze ist in wenigen Tagen bei mir. Die CPM Tools zum erstellen 
eigener *.dsk "Disketten" habe ich mir auch schon geholt. Ein wenig 
Software legt er mir auch noch bei. Und, ein wenig Software findet man 
ja noch im Netz :)

Autor: Marcel A. (dl1ekm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na denn. Auch ich habe hier noch einige Sticks (Platine) und jede Menge 
4-bit RAM und was man sonst so braucht vorrätig...
Schau mal auf meine HP...

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel A. schrieb:
> Na denn. Auch ich habe hier noch einige Sticks (Platine) und jede Menge
> 4-bit RAM und was man sonst so braucht vorrätig...
> Schau mal auf meine HP...

Eine mit dem VGA Anteil hätte ich noch gerne. Das aber ein anderes mal, 
bei mir steht bald ein Umzug an...

Autor: Ronny M. (hobby-coder)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr,

evtl. kann mir jemand bei der Lösung eines Problems helfen.

Ich habe ja den CPM Stick gekauft und eine CD mit Tools usw. bekommen. 
Auf der CD sind auch ein paar Disk/HD Images. Ich kann den Stick sauber 
booten und auf das Laufwerk B zugreifen. Laufwerk B ist ein 
Festplattenimage mit 8MB größe.

Allerdings sehe ich nur den Inhalt der ersten 256kb... Mit B: komme ich 
sauber auf die Festplatte,  "stat" zeigt mir ein Freiraum von ca. 7.7MB 
an. Auf der HDD sind aber mehr Programme...

Ich habe einige Programme aus der Batch Datei, die mir die DiskImages 
erstellt, auskommentiert. In ADA usw. programmiere ich nicht...

Ich habe die Batch Dateien, womit ich mir meine Images erzeugt habe, 
einmal angehangen.

Ich sehe weder mit der originales Batch Datei, noch mit meinen 
Änderungen alle Dateien auf der HDD. Muss ich evtl. einen bestimmten 
Bereich ansprechen? Ein B: scheint ja nicht zu reichen....

Ich komme nicht aus der CPM Zeit. Ich bin erst Ende der 80er Jahre, mit 
DOS und dem Robotron BIC5105, bzw. BIC 5110 in die PC Welt 
eingestiegen...

Autor: Peter S. (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi.
Die einzelnen Applikationen sind in sog. Userbereiche kopiert - siehe 
Batch Datei.
Umschalten mit z.B. user 1
(2, 3,...)

Das war eine Vorstufe der Unterverzeichnisse.

So hat man alles sauber getrennt und nicht Ada mit C oder Pascal 
vermischt.

Peter

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Afaik hat CPM weder Unterverzeichnisse, noch Userkonten... Oder, habe 
ich hier einen Denkfehler...?

Autor: Peter S. (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CP/M hat ebend keine Unterverzeichnisse.
Und auch keine Userkonten ala Unix etc.
ABER: Sog. User Bereiche. Das ist nichts weiter als das die Dateien 
einem Userbereich zugeordnet werden und in der Anzeige NUR die Dateien 
angezeigt werden, die zum aktuellen Userbereich gehören. Physikalisch 
liegt alles im Rootverzeichnis.
Umschaltung mit user n.

Lies dir doch bitte mal ein CP/M Handbuch durch.

Googlen geht aber auch:
http://www.primrosebank.net/computers/cpm/cpm_cookbook_user.htm


Peter

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du, oder jemand anderes, mir ein passendes Buch empfehlen? Ich 
habe, im 64er Forum - oder besser gesagt - deren Datengrab, ein wenig 
Einsteigerliteratur gefunden. Aber, keines hiervon sprach das "user x" 
Thema an..."

Autor: Peter S. (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank :)

Eine Frage zum Schluss noch: Wie kann ich mbasic/ Basic 80 beenden und 
zurück zu CPM kommen? ein ^c, ^x oder ^q brachte kein Erfolg. Ich muss 
SIMH, bzw. den Stick resetten, um wieder zum BDOS zurück zu kommen... 
Hatte M$ damals keine Exit- Routine eingebaut...? "quit", "bye" oder 
"exit" bringt auch kein Erfolg.

Btw: das ist echt ein nettes kleines Spielzeug :)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
system

Autor: Ronny M. (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> system

Danke :) Damit sind meine Fragen beantwortet. Wenn ich doch wieder 
welche habe, schreibe ich das hier rein :)

Autor: David R. (retrogadgets)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I have the cpm stick 3.1 board with the atmega 328, 2x TC514256AP-70 
drams but nothing showing on the serial port, nor is the sd card being 
read.

question, does the atmega show anything through the serial terminal 
before reading the sd card, so i can rule out the atmega is programmed 
correctly with the correct fuse settings.

any help would be appreciated.

Autor: David R. (retrogadgets)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...

Autor: Horst S. (h3aau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin,
hat schon mal einer darüber nachgedacht das ganze auf einen 
STM32F103P6T8 zu bringen? wäre doch auch eine nette sache.

Autor: Horst S. (h3aau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine natürlich den STM32F103C8T6............... sorry

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David R. schrieb:
> question, does the atmega show anything through the serial terminal
> before reading the sd card,
You should see something like:
CPM on an AVR, v3.2 r0
Testing RAM: fill...wait...reread...
Initing mmc...

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst S. schrieb:
> hat schon mal einer darüber nachgedacht das ganze auf einen
> STM32F103P6T8 zu bringen? wäre doch auch eine nette sache.
Der Z80-Emulator ist in feinstem AVR-Assembler geschrieben, das portiert 
man nicht mal so eben.
Welche Vorteile versprichst Du Dir von STM32-Variante?

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte halt auf das DRAM verzichten und hätte ggf. mehr Speed.


Beim STM32F103C8T6 bräuchte man aber wieder externes RAM, der hat intern 
nur 20K. Sinnvoller wäre etwas mit 64K oder mehr. Oder noch besser 128K 
RAM, da könnte man auch die Videoausgabe mit reinmachen. Also z.B. ein 
STM32F405RG. Wobei sich dann trotzdem die Frage stellt, ob sich der 
Aufwand lohnt. Denn es gibt ja schon die AVR-Variante, die recht gut 
funktioniert. Und ich denke auch, dass das Interesse an solchen 
Projekten eher nachlässt. Leider...

Jörg

Autor: Andreas J. (antibyte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für ARMe gibt's schon fertige Z80-Emulationen. Die sind meist in C 
geschrieben, weil dank der deutlich höheren Taktgeschwindigkeit die 
Emulation nicht extrem performen muss. Als Ausgleich ist die Emulation 
akkurater (d.h. das Zeitverhalten entspricht dem Original).

Autor: David R. (retrogadgets)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I see on the forum different fuse setting for the atmega 328, which 
should i use?

Autor: David R. (retrogadgets)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avrdude -c usbasp -p m328p -e -U flash:w:avrcpm.hex
avrdude -c usbasp -p m328p -U lfuse:w:0xf7:m -U hfuse:w:0xdf:m

ive used the above is this correct

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir einen AVR-CP/M Stick V3.1 zusammengebaut.
Tolles Projekt - schon erstaunlich, was in dem kleinen Ding mit grossem 
Assembler-Quellcode-Herz steckt.

Wenn ich den Microsoft FORTRAN 3.44 Compiler ausprobiere, bekomme ich 
einen Fehlerabbruch.

Der gleiche Compiler funktioniert auf dem Z80-CP/M Subsystem in meinem 
HP-86, an der Software liegt es also nicht.
C>user 7

C>type hello.for
      PROGRAM MAIN
      print *, 'Hello World!'
      END

C>f80 HELLO=HELLO
FORTRAN-80 Ver. 3.4 Copyright 1978, 79, 80 (C) By Microsofô
BYTES: 31663
Š1            PROGRAM MAIN
2             print *, 'Hello World!'
*****‰0000'     LD      BC¬$$L
*****‰0003'     JP‰$INIT
?Line: 2 Statement Unrecognizable or Misspelleä:PRIN
3             END
*****‰0006'     CALL‰$EX

Program Unit Length½0009 (9)
 Bytes
Data Area Length½0001 (1) Bytes

Subroutines Referenced:
Š$INIT                  $EX

Variables:
Š
Labels:
Š$$L    0006'
Š1 Fatal Error(s) Detected
Merkwürdig sind die ersten und letzten Buchstaben der Fehlermeldungen.
Diese Zeichen haben jeweils bit 7 gesetzt.

Š = 0x8A = 1000.1010, bit 7 gelöscht: 0000.1010 = 0x10 = '\n'
½ = 0xBD = 1011.1101, bit 7 gelöscht: 0011.1101 = 0x3D = '='
ä = 0xE4 = 1110.0100, bit 7 gelöscht: 0110.0100 = 0x64 = 'd'

Auch wird PRINT nur verkürzt ausgegeben.

Hat jemand diesen FORTRAN Compiler auf dem AVR-CP/M laufen?
Kann es sein, dass hier noch Z80 opcodes fehlen?

Alle anderen Programme, incl. C Compiler etc. scheinen gut zu laufen, 
nur der F80 nicht.

Hat jemand ein kleines Fortran Beispielprogramm mit PRINT oder WRITE, 
das läuft?

Martin

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Habe mir einen AVR-CP/M Stick V3.1 zusammengebaut.

Welche Firmware-Version hast Du auf dem Stick?

> Kann es sein, dass hier noch Z80 opcodes fehlen?

Sicher nicht. Zumal der F80 ziemlich sicher ein reines 8080 Progamm ist.
Ich dachte zuerst an ein Timing-Problem mit der seriellen Schnittstelle. 
Da aber nicht nur die Ausgabe vermurkst ist, sondern auch Fehler beim 
compilieren sind, wird es wohl was anderen sein.
Ich schau mal rein.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... warte nochmal, bevor Du suchst ... der Compilerfehler ist 
wahrscheinlich eher ein Problem meinerseits mit dem Uralt-Fortran. Ich 
teste heute abend nochmal weiter.

Unabhängig davon: die gesetzten 7.bit im den Fehlermeldungen könnten 
vielleicht verwendet worden sein um die Zeichenattribute für ein 
Terminal zu steuern? Eventuell ist der Compiler für den TRS-80 und der 
versteht so etwas z.B. für inverse Ausgabe oder ähnliches? Andere 
Terminals maskieren dieses 8. Bit dann einfach weg. Ich habe 
Windows/Teraterm mit 8 Datenbits + 1 Stop bit verwendet.

Martin

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> ... warte nochmal, bevor Du suchst ... der Compilerfehler ist
> wahrscheinlich eher ein Problem meinerseits mit dem Uralt-Fortran. Ich

Zu spät. ;)

> Wenn ich den Microsoft FORTRAN 3.44 Compiler ausprobiere, bekomme ich
> einen Fehlerabbruch.

Das ist wahrscheinlich der neueste FORTRAN Compiler den es von Microsoft 
für CP/M gibt. Den gleichen habe ich inzwischen auch ausprobiert.

> Der gleiche Compiler funktioniert auf dem Z80-CP/M Subsystem in meinem
> HP-86, an der Software liegt es also nicht.

Das der Dein hello.for übersetzt hat, glaube ich jetzt nicht. MS FORTRAN 
3.4 ist im wesentlichen ein FORTRAN-66 Compiler und hat definitiv keinen 
PRINT-Befehl.

> Unabhängig davon: die gesetzten 7.bit im den Fehlermeldungen könnten
> vielleicht verwendet worden sein um die Zeichenattribute für ein
> Terminal zu steuern?

Bei mir kommen diese Bits nicht. Das scheint mir eher ein 
Hardware-Problem oder ein Problem mit Deinr AVRCPM Firmware-Version 
(welche?) zu sein.

> Ich habe
> Windows/Teraterm mit 8 Datenbits + 1 Stop bit verwendet.

Das sollte passen.

CPM on an AVR, v3.5 r242
Testing RAM: fill...wait...reread...
Initing mmc...

A: CP/M partition at: 001, size: 7811KB.
B: FAT16 File-Image 'A' at: 3766, size: 8192KB.
C: FAT16 File-Image 'B' at: 859, size: 8192KB.
D: FAT16 File-Image 'C' at: 003, size: 8192KB.
E: FAT16 File-Image 'E' at: 375, size: 2048KB.
F: FAT16 File-Image 'F' at: 504, size: 1024KB.
G: FAT16 File-Image 'H' at: 586, size: 256KB.
H: FAT16 File-Image 'I' at: 603, size: 256KB.
Partinit done.
Ok, Z80-CPU is live!

62k cp/m vers 2.2

A>b:
B>f80 =hello
MAIN

?Line: 2 Statement Unrecognizable or Misspelled:PRIN

?1 Fatal Error(s) Detected

B>type hello2.for
      PROGRAM MAIN
      WRITE(1,200)
200   FORMAT(1X,'Hello World!')
      END

B>f80 =hello2 
MAIN

B>l80 hello2,hello2/n/e

Link-80  3.44  09-Dec-81  Copyright (c) 1981 Microsoft

Data    0103    1A0B    < 6408>

39529 Bytes Free
[0117   1A0B       26]

B>hello2

Hello World!

B>


Nachtrag:
Falls Du tatsächlich eine modifizierte Compilerversion haben solltest:
Im Anhang ist ein Diskimage mit dem Compiler den ich zum Testen 
verwendet habe.
Handbuch gibts hier:
http://www.textfiles.com/bitsavers/pdf/microsoft/cpm/Microsoft_FORTRAN-80_Ver3.4_Users_Manual_Nov80.pdf

: Bearbeitet durch User
Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Mühe.

Ich hatte ein Disk Image CPMDSK_D.IMG verwendet. Dort lag unter USER 7 
ein Programm HELLO.FOR. Damit bekam ich gleich die Fehlermeldungen und 
die "merkwürdigen" Zeichen und glaubte dass da etwas größeres nicht 
stimmt.
Wie Du schreibst, ist das Programm aber nicht für FORTRAN IV (oder 66?) 
geeignet. Ich hatte dann gestern abend noch ein eigenes Testprogramm 
geschrieben und das funktioniert. Entschuldigung für die Verwirrung.

Wenn ich allerdings einen Syntaxfehler in das Programm einbaue, kommen 
wieder diese Zeichen mit gesetztem 7.Bit. Das müsste bei Dir auch der 
Fall sein?
Vielleicht verwenden bestimmte Terminals das 7.Bit um invers oder fett 
darzustellen (es gab auch eine Version dieses Fortrans für den TRS/80, 
vielelicht versteht der das).  Das ist aber kein wirkliches Problem.

Mein (jetzt erfolgreicher) Test:
CP/M on AVR, v3.2 r155
Testing RAM: fill...wait...verify...
Reading SD card...

A: FAT16 Image 'A' at: 002, size: 256 KB.
B: FAT16 Image 'B' at: 266, size: 256 KB.
C: FAT16 Image 'D' at: 274, size: 8192 KB.
D: FAT16 Image 'E' at: 010, size: 8192 KB.
Partinit done.
Ramdisk found.
Ok, Z80-CPU is alive!

ipl <<<<<<<<<<<<<< Was bedeutet das? Aus welcher .asm Quelle kommt das?
62k cp/m vers 2.2

A>C:
C>USER 7

C>TYPE HELLO.FOR
      PROGRAM HELLO
      INTEGER I, IUNIT
      REAL X,Y
      IUNIT=6
      WRITE(5,100)
C     0 = current drive
C     3 = drive C:
      CALL OPEN(IUNIT,11HHELLO   TXT,3)
      DO 50 I=1,100
         X=FLOAT(I)/10.0
         Y=SIN(X)
         WRITE(IUNIT,200) X,Y
50    CONTINUE

100   FORMAT(15H Hello FORTRAN!)
200   FORMAT(1H ,F12.3,3H = ,F12.3)
      END


C>F80 HELLO=HELLO
HELLO

C>L80 HELLO/N,HELLO/E

Link-80  3.44  09-Dec-81  Copyright (c) 1981 Microsoft

Data    0103    1E69    < 7526>

37999 Bytes Free
[0139   1E69       30]

C>HELLO
Schreibt "Hello FORTRAN" auf die LST device (Terminal)
Erstellt Datei 'HELLO.TXT' mit X,Y Werten.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich hatte ein Disk Image CPMDSK_D.IMG verwendet. Dort lag unter USER 7
> ein Programm HELLO.FOR.

Und F80.COM befindet sich ebenfalls auf diesem Image?
Wo finde ich das Image? Oder kannst Du es mir zukommen lassen?

> Wenn ich allerdings einen Syntaxfehler in das Programm einbaue, kommen
> wieder diese Zeichen mit gesetztem 7.Bit. Das müsste bei Dir auch der
> Fall sein?

Nein, die Zeichen kommen bei mir nicht.

> Vielleicht verwenden bestimmte Terminals das 7.Bit um invers oder fett
> darzustellen (es gab auch eine Version dieses Fortrans für den TRS/80,
> vielelicht versteht der das).

Das mag durchaus sein, aber mMn müßten die Bits dann anders verteilt 
sein. Für mich sieht das eher nach Übertragungsfehler aus.

> Das ist aber kein wirkliches Problem.

Für mich schon, solange die Ursache nicht klar ist.
Deshalb hätte ich gerne das Disk Image.

> Mein (jetzt erfolgreicher) Test:CP/M on AVR, v3.2 r155

Zwar nicht uralt, aber auch nicht die neueste Version. Du könntest auf 
v3.5 updaten.

> Ok, Z80-CPU is alive!
>
> ipl <<<<<<<<<<<<<< Was bedeutet das? Aus welcher .asm Quelle kommt das?
> 62k cp/m vers 2.2

Das ist der "Initial Prgram Loader".
Der Bootloader im ersten Sektor der Disk, der das CP/M (CCP+BDOS+BIOS) 
aus den reservierten Systemspuren ins RAM läd.
Sourcecode ist in cpm/IPL.MAC.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich werde mal versuchen mir eine aktuellere Firmware zu assemblieren.

>Zwar nicht uralt, aber auch nicht die neueste Version. Du könntest auf v3.5 
updaten.
Woher nehmen und nicht stehlen? Ich habe bislang nur ein 3.2 für die 
standalone Version unter
https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/trunk/avr
gefunden. Ich habe die V3.1 Stick-Platine mit TTL-Serial ind 8-bit DRAM, 
d.h. kein Propeller, VT100 etc. Wollte nur noch (wenn der Chinese 
liefert) auf I2C-Seriell aufrüsten.

Danke für die Erläuterung des "ipl" - ich dachte das es Optionen 
(I2C,...) kennzeichnet und konnte es in den Quellen nicht finden.

Die disk-image Dateien habe ich von 
https://www.mikrocontroller.net/articles/AVR_CP/M dort unter "Downloads" 
die datei CPMDSK_C.IMG geladen. Dort war unter "USER 7" der FORTRAN 
Compiler mit L80 und dem "Beispiel" zu finden.

Den MS-F80 v3.44 Compiler hatte ich auch schon früher mal für andere 
CP/M Rechner gefunden, vermutlich geistern die selben Dateien an vielen 
Stellen herum. Z.B. auf http://www.retroarchive.org/
Da es auch eine TRS-80 Version des Compilers (zumindest der Handbücher) 
gab, habe ich noch nach TRS-80 Infos gesucht.

Dazu habe ich noch dies gefunden:
The Model 4 uses the same character set as the Model 3 as long as the reverse video is turned off. If you wish to use reverse video, first send CHR$ code 16 to the display, then switch in the video memory. You can only access inverse video and POKE the data if you SET bit 7 of the data going to the display. Example: Send ASCII code to display with this assembler program: 

    LD A,41H 
    LD HL,F800H 
    LD (HL),A 
 
The above puts the normal video “A” on the screen. If you want reverse video, use this: 

    LD A,41H ; A 
    SET 7,A 
    LD HL,F800H 
    LD (HL),A 
 
You can also calculate the reverse video strings by adding 128 to each value to send to the screen. 
***** N O T E ***** 
If you enable the reverse video, you *CANNOT* use the graphics characters. To disable the reverse video and enable the graphics, send a CHR$ code 17 to the screen. 

Meine Spekulation ist, dass diese TRS-80 Spezialität verwendet wird um 
Fehlermeldungen (nur diese) hervorzuheben. Um das zu prüfen, müsste man 
aber den F80 disassemblieren, soweit wollte ich nun nicht gleich gehen.

Wenn aber diese Zeichen bei Dir (im Fehlerfall) nicht auftauchen, muss 
es wohl etwas anderes in meiner Konfiguration sein.  Merkwürdig wäre 
dann aber das alle (?) anderen Programme (Turbo Pascal, Multiplan, 
Wordstar, ED) mit ihren durchaus komplexen Ausgaben einwandfrei zu 
funktioniern scheinen.

Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
O.K. ich habe nun doch noch die aktuellen (hoffe ich) Quellen gefunden 
und habe nun die Version 3.5 laufen.

Auch damit kommen bei Fehlermeldungen (nur dort) ebenfalls jeweils die 
letzten Zeichen mit gesetztem Bit 7.

Daraufhin habe ich mir die Fehlermeldungen im F80.COM angesehen. Sie 
haben immer auf dem letzten Buchstaben bit 7 als Ende-Kenner gesetzt.
Damit spart man ein (Null-)Byte pro String, setzt aber voraus, dass die 
Ausgabeeinheit immer nur 7 bit ausgibt.
Im BIOS gibt es dazu die 5 Funktionen CONIN, CONOUT, LIST, READER und 
PUNCH.
Im "CP/M 2.2 Alteration Guide" steht (S. 17/18, 1979-er Digital Research 
Ausgabe), das für diese das high order (parity) bit == 0 sein soll,
auch bei der Eingabe. Das bedeutet dann aber auch, dass man generall in 
CP/M keine 8-bit Binärdaten einlesen oder ausgeben kann.

Es ist mir nicht 100% klar ob diese Funktionen 7 bit erwarten oder ggf. 
das 7.bit selbst löschen.

Nur die Funktionen CONIN und READER löschen bit 7 explizit im Beispiel 
BIOS (S. 53)

In dem CP/M Assemblercode des HP Systems, das ich vor einiger Zeit mal 
disasembliert hatte, findet ebenfalls eine explizite Maskierung auf die 
unteren 7-bits beim TTY input statt.

Die CP/M Version von AVR-CPM macht anscheinend diese Filterung nicht, 
sondern gibt die volle 8-bit Breitseite auf die Konsole.
Der Emulator "Z80Emu" gibt auch nur die 7-bit Texte aus.

So wie es jetzt ist, kann man dann aber auch höhere > 128 Zeichencodes 
ausgeben, was ja auch ganz nett ist.
Ich bin nicht sicher ob CP/M grundsätzlich als 7-bit System für jede 
Console - I/O zu verstehen ist.

Meine Spekulation zu TRS-80/Steuerzeichen war nicht richtig.

F80.COM:
...
 I  l  l  e  g  a  l     S  t  a  t  e  m  e  n  t     N  u  m  b  e  .
49 6C 6C 65 67 61 6C 20 53 74 61 74 65 6D 65 6E 74 20 4E 75 6D 62 65 F2
0xF2 & 0x7F => 0x72 = 'r'

0000477A 496C 6C65 6761 6C20 5374 6174 656D 656E Illegal Statemen
0000478A 7420 4E75 6D62 65F2 5374 6174 656D 656E t Numbe.Statemen
0000479A 7420 556E 7265 636F 676E 697A 6162 6C65 t Unrecognizable
000047AA 206F 7220 4D69 7373 7065 6C6C 65E4 496C  or Misspelle.Il
000047BA 6C65 6761 6C20 5374 6174 656D 656E 7420 legal Statement 
000047CA 436F 6D70 6C65 7469 6FEE 496C 6C65 6761 Completio.Illega
000047DA 6C20 444F 204E 6573 7469 6EE7 496C 6C65 l DO Nestin.Ille
000047EA 6761 6C20 4461 7461 2043 6F6E 7374 616E gal Data Constan
000047FA F44D 6973 7369 6E67 204E 616D E549 6C6C .Missing Nam.Ill
0000480A 6567 616C 2050 726F 6365 6475 7265 204E egal Procedure N
0000481A 616D E549 6E76 616C 6964 2044 4154 4120 am.Invalid DATA 
0000482A 436F 6E73 7461 6E74 206F 7220 5265 7065 Constant or Repe
0000483A 6174 2046 6163 746F F249 6E63 6F72 7265 at Facto.Incorre
0000484A 6374 204E 756D 6265 7220 6F66 2044 4154 ct Number of DAT
0000485A 4120 436F 6E73 7461 6E74 F349 6E63 6F72 A Constant.Incor
0000486A 7265 6374 2049 6E74 6567 6572 2043 6F6E rect Integer Con
0000487A 7374 616E F4                            stan.
...

Martin