Hier die richtige Skizze. In der ursprünglichen Skizze waren RX_Prop und
Tx_Prop vertauscht. Ursache ist ein Layoutfehler. Da alle Pins jedoch
auf das Steckfeld gehen (zum Glück) kann der Fehler durch die nun
richtigen Brücken korregiert werden.
Super! Da hast sich gerade unsere Post gekreuzt ;-)
Das EEPROM (Fassung ist gut) sollte wieder drauf. Ansosnten ist die
Software nach dem Reset gelöscht.
EEPROM ist wieder drauf. Jetzt mit Sockel. Funktioniert auch. Leider
geht die Tastatur (noch) nicht. Das kann jetzt alles mögliche sein. Die
habe ich vor ein paar Tagen zum Reinigen zerlegt und vielleicht falsch
zusammen gebaut.
Das Terminal verschluckt aber Zeichen. Beim Hochfahren des AVRs wird nur
die Hälfte der Meldungen angezeigt. Bei mir kommt da wg. 6 "Laufwerken"
ziemlich viel Text.
Wenn die Tastatur korrekt angeschlossen ist, sollten die 3 LEDs beim
Reset kurz aufblinken (Tastaturreset), tun sie das nicht, geht die
Initialisierung schon schief.
Das "verschlucken" von Zeichen liegt an der Kommunikation. Der Puffer
ist derzeit 256 Byte groß, reicht jedoch bei 115200 Baud offensichtlich
für deine Datenmenge noch nicht aus. Mal sehen was sich da machen läßt.
Die Tastatur geht jetzt auch. R16 und R17 waren vertauscht. Evtl. ein
Problem mit dem Bestückungsplan.
Ein paar Tasten gehen aber noch nicht so richtig.
"Backspace" macht seltsame Sachen
"+" auf dem Ziffernblock geht nicht.
"'" (Symbol über '#'): Dort scheint "`" (0x60) statt "'" (0x27) zu
kommen.
"{[]}" Eckige und geschweifte Klammern fehlen.
Joe G. schrieb:> Das "verschlucken" von Zeichen liegt an der Kommunikation.
Mit der noch nicht funktionierenden Tastatur hatte ich den interessanten
Effekt, daß die Bootmeldungen alle richtig kamen, wenn ich den
USB-Stecker (Stromversorgung) eingesteckt hatte. Beim Drücken der
Reset-Taste kamen nur die verstümmelten Meldungen. Mit der
funktionierenden Tastatur kommen jetzt nur noch verstümmelte Meldungen.
Der AVR-TXD-Leitung würde ein Pullup ganz gut tun. Wenn die Leitung am
Jumperfeld offen ist, reicht es, wenn ich mit der Hand nur in die Nähe
komme, damit der AVR verrückt spielt.
Nachtrag: Man kann natürlich auch den internen Pullup enablen. Werde ich
gleich mal machen.
Leo C. schrieb:> Evtl. ein Problem mit dem Bestückungsplan.
Danke, ich schau mal nach.
Leo C. schrieb:> Ein paar Tasten gehen aber noch nicht so richtig.
Müßte nun alles bis auf Ö, Ä und Ü gehen.
Joe G. schrieb:> Die gehen nun auch und jetzt ist Ostern!
Klammern gehen, Umlauts gehen, sogar die hier:²³
Die Backspacetaste spinnt aber noch und die Control-Codes gehen nicht.
Eilt aber alles nicht.
Leo C. schrieb:> "+" auf dem Ziffernblock geht nicht.
Die Taste ist kaputt.
Aber am CP/M-Computer brauche ich sie nicht unbedingt.
Moin Leo,
bin auch dabei die neue Platine aufzubauen. Prop-Terminal geht,
Tastatur geht auch. AVR lässt sich flashen, nur kommt nichts auf
der seriellen Schnittstelle. Übersetzt habe ich das avrcpm.asm
mit Studio4 mit folgenden Änderungen im Makefile:
#MCU = atmega88
MCU = atmega328
F_CPU = 20000000
DRAM_8BIT = 1
#BAUD = 57600
BAUD = 115200
I2C = 1
EM_Z80 = 1
FAT16_SUPPORT = 1
MMCBOOTLOADER = 0
Die Übersetzung lief ohne Fehler und Warnungen.
Fuses: kein div8, ext crystal osz
Hast Du ein Hexfile für mich, damit ich ein HW-Problem ausschliessen
kann?
Vielen Dank
Gruss
Peter
Peter Zabel schrieb:> MCU = atmega328
Das sollte atmega328*p* heißen. Ist aber egal, da 'config.inc' dann
trotzdem atmega328p genommen wird, was eigentlich ein Fehler ist aber
auch egal ist, da für die Software kein Unterschied, ob MCU mit oder
ohne 'P', falls es letzteren überhaupt gibt.
1
leo@cb:~/src/avr/CPM_auf_ATmega88/3.1/3.1/avr$ make clean all
avrcpm.asm(33): Including file 'C:/Programme/Atmel/AVR Tools/AvrAssembler2/Appnotes\m328Pdef.inc'
9
avrcpm.asm(35): Including file 'config.inc'
10
...
Allerdings geht bei mir 'make flash' damit nicht, da avrdude keinen
'atmega328' kennt.
Ansonsten läuft das Programm bei mir mit diesen Einstellungen.
ps: In trunk gibts eine neue Version, die gründlich getestet werden
müßte.
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/avr/
Hallo Leo,
Dein hex-file lief zuerst auch nicht. PB0 und PB1 geprüft, sind mit
dem Steckerfeld verbunden. Reset nicht auf Masse. Dann habe ich gesehen,
dass ich Brownout aus alter Gewohnheit auf 4,3V gesetzt habe...
Mein hex-file läuft auch. Habe ich richtig gesehen, dass die I2C
Basisadressen auf 0x40 (RTC) und 0x80 (Par) liegen?
Jetzt muss ich erstmal überlegen, wie das mit der SD Erstellung war.
Ist schon länger her.
Gruss
Peter
Glückwunsch Peter.
Peter Zabel schrieb:> Habe ich richtig gesehen, dass die I2C> Basisadressen auf 0x40 (RTC) und 0x80 (Par) liegen?
Fast.
virt_ports.asm:
1
;------------------------ Wall Clock and Timers --------------------------
2
;40 in/out - Timer/Clock control.
3
;41-46
4
;
5
;47-4D clock - BCD format: ss, mm, hh, DD, MM, YYl, YYh
#define TIMERPORT 0x40 /* Base z80 port address for clock access */
4
#define TIMER_CTL TIMERPORT
5
#define TIMER_MSECS TIMERPORT+1
6
#define TIMER_SECS TIMER_MSECS+2
7
#define CLOCKPORT TIMERPORT+7 /* Real time clock BCD (ss,mm,hh,DD,MM,YYYY) */
8
9
#define starttimercmd 1
10
#define quitTimerCmd 2
11
#define printTimerCmd 15
12
#define uptimeCmd 16
Auf 40-46 liegt der Interrupt-Timer, den es schon fast von Anfang an
gibt.
Dieser kann z.B. mit dem Programm 'ACT' aus dem cpm/utils Verzeichnis
abgefragt und gesteuert werden.
Die RTC liegt auf 46-4D. Eigentlich auch eine Interrupt-Uhr. Nur das
Stellen beim Booten erfolgt über den RTC-Chip, sofern vorhanden. Für
diese Uhr gibt es einen ZSDOS-Treiber ('LDTIM.COM') und ein
ZSDOS-Programm zum steuern und abfragen ('TD.COM') [1].
Und dann gibt es noch [2]:
virt_ports.asm:
Im Anhang ist ein bootbares simhd-Image mit dem man die neue Hardware
testen kann. Im wesentlichen ist ZSDOS drauf (aber nicht ganz
vollständig), und ein paar Test- und Benchmarkprogramme.
Hallo Leo,
wenn ich Dein image mit dd auf die sd schreibe, dann mault dd, dass
nicht
genügend Speicher vorhanden ist und kopiert 1 Block weniger.
Die 8 MB habe ich vorher mit cfdisk erzeugt, Type 52. Bootflag gesetzt.
Die SD bootet zwar, zeigt aber no Files. Mit cpmls sehe ich sie aber im
image.
Muss ich die Partition grösser machen?
Gruss
Peter
Einfach das zip auspacken, und die Datei auf eine Karte mit Fat-16
Dateisystem kopieren. Hätte ich vielleicht dazu schreiben sollen.
Wenn von dem Image gebootet werden soll, sollten keine CP/M-Partitionen
vorhanden sein.
Hallo Leo,
ich sehe schon, es hat sich viel getan. Super Arbeit!
Mit RTCDemo konnte ich Datum und Uhrzeit stellen und auslesen.
Allerdings läuft die RTC ca. 17% zu schnell, sowohl eingeschaltet als
auch ausgeschaltet. Ich werde morgen mal den Quarz tauschen, obwohl
ich nicht daran glauben kann.
Vielen Dank für Deine Hilfe und Frohe Ostern.
Gruss
Peter
Peter Zabel schrieb:> Allerdings läuft die RTC ca. 17% zu schnell, sowohl eingeschaltet als
Hast Du einen Kondensator oder Trimmer an Pin 1 der RTC? Der wurde im
Layout vergessen. Siehe hier (ff):
Beitrag "Re: CP/M auf ATmega88"
Guten Morgen und Frohe Ostern.
Im Anhang ist was Neues zum Testen. Allerdings nur interessant, wenn man
einen Mega im 32 poligen Gehäuse (SMD) hat. Insbesondere die neue
Hardware von Joe G.
Joe G. schrieb:> Das VT100 kann nun auch CRTL-Codes, damit ist WS oder der Turbo Editor
Danke.
Das Meiste scheint zu funktionieren. Folgende Punkte sind mir
aufgefallen:
- 'Return' scheint ein "Auto-Linefeed" zu machen.
- 'Backspace' liefert "0xC8 0x08" statt 'DEL' (0x7F).
- Wenn auf der letzten Position einer Zeile (80) etwas ausgegeben wird,
geht der Curser automatisch in die nächtse Zeile. Wordstar mag das
nicht.
- 'Delete Line' und/oder 'Insert Line' funktioniert nicht richtig.
- Die Cursor-Tasten liefern keine VT-100-Codes, aber das ist nicht
unbedingt von Nachteil.
> zu bedienen. Den Quellcode gibt es vorerst hier...> https://code.google.com/p/avr-cpm-system/
Was heißt vorerst, und wieso so weit weg?
Danke für die Hinweise.
Leider zeigen sich bei der Umsetzung der Codes Unterschiede zwischen
VT100 und den gewohnten MSDOS Funktionen. Wir sollten einen guten
Kompromiss finden.
Beispiel:
Backspace VT100 = Cursor links, Zeichen bleibt stehen
Backspace MSDOS = Cursor links, Zeichen löschen, nachfolgende Zeichen
nach links schieben
DEL MSDOS = Zeichen an Cursorposition löschen, nachfolgende Zeichen nach
links schieben (Vorwärtslöschung)
Hier mein Vorschlag:
BS mit VT100 Funktion 0x08
DEL mit VT100 Funktion 0x7F
Joe G. schrieb:> Schaut mal ob WS nun mit VT100 bei euch läuft. Der Turbo Editor geht nun> bei mir. Es fehlen nur noch die Farbattribute.
Bei mir werden wieder (oder immer noch) Zeichen verschluckt. Ich hätte
schwören können, daß das mit V05 weg war. Jetzt habe ich die noch mal
geladen, war aber leider nicht besser. In meiner Verzweiflung bin ich
jetzt mal auf 9600 Baud gegangen (Habe ich an meinem anderen System auch
gerade). Die Startup-Meldungen sind jetzt heil.
Kann es sein, daß die unterste Zeile beim Scrollen nicht mit hoch
geschoben wird?
Im Anhang ist ein Disk-Image mit ganz frisch konfiguriertem Wordstar
3.3. Das Higlight-Attribut ist auf "Inverse-Video" voreingestellt.
Ich habe jeweils 40 Zeilen eingestellt, und sonst nur noch:
WS.COM - Nur Terminal VT100 aus Menü ausgewählt.
WSE.COM - Zusätzlich die Escape-Sequenzen für "Delete Line" und "Insert
Line" konfiguriert.
Wenn man eine Datei öffnet, erscheint auf dem Bildschirm nur noch Salat.
Entweder ist Wordstar oder das Terminal abgestürtzt. Da es mit meiner
vorherigen WS-Version nicht so schlimm ist, kann es eigentlich nur an
dem Inverse-Attribut oder an den 40 Zeilen liegen. WS mit 40 Zeilen
läuft aber in der PC-Terminalemulation.
Danke für die Rückmeldung. Ich schaue mir am Freitag mal den Datenstrom
zwischen WS und VT100 an. Möglicherweise gibt es noch Codes die nicht
unterstützt sind. Das scrollen der letzten Zeile ist auch noch ein Bug.
Joe G. schrieb:> Leider zeigen sich bei der Umsetzung der Codes Unterschiede zwischen> VT100 und den gewohnten MSDOS Funktionen. Wir sollten einen guten
Man muß den ASCII-Code[1] DEL/0x7F und die Taste[2] Delete/Del/Entf
auseinander halten. Außerdem ist die Ecke ist aus historischen Gründen
etwas verkorkst. Schließlich wurde ASCII[0] für Fernschreiber mit
Druckwerk und Lochstreifenleser/stanze erfunden.
CP/M 2.2 unterstützt die Teletype auch noch: ASCII DEL, bzw Rubout
(0x7F) gibt das letzte Zeichen einfach noch mal aus und löscht es im
Input-Buffer[3]. ZSDOS hat aufgeräumt: "The delete key has been fixed so
that Rubout acts like Backspace instead of echoing the deleted
character."[4]
> Hier mein Vorschlag:> BS mit VT100 Funktion 0x08> DEL mit VT100 Funktion 0x7F
Wordstar macht es so:
BS (0x08, ^H) - Curser nach links bewegen.
DEL (0x7F) - Zeichen links vom Curser löschen.
^G - Zeichen an Curserposition löschen, also das, was man
am PC üblicherweise mit der Del-Taste machen will.
In der ANSI-Emulation unter Linux sendet die DEL-Taste eine 4 Zeichen
lange Escape-Sequenz (^[[3~), so wie alle Tasten des Curserblocks.
Deshalb habe ich weiter oben geschrieben, das man an der Stelle das
ANSI-Verhalten vielleicht garnicht haben möchte. Unter Turbopascal kann
mans imho verwenden. Mit Wordstar aber eher nicht. Sogar DEL/BS patchen
ist schon etwas aufwendig.
[0] https://en.wikipedia.org/wiki/ASCII "Since the delete code often
produced a backspace effect, this also forced terminal manufacturers
to make any Delete key produce something other than the Delete
character." [5]
[1] https://en.wikipedia.org/wiki/Delete_character
[2] https://en.wikipedia.org/wiki/Delete_key
[3] http://www.cpm.z80.de/manuals/cpm22-m.pdf Seite 5-16
[4] http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos3.zip
Seite 19, auch als PDF [6]
[5] https://en.wikipedia.org/wiki/ASCII#cite_note-bsp_del_mismatch-45
[6] http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos.pdf
Glückwunsch.
Wenn jetzt noch die "<" vom linken zum rechten Rand wandern...
Leider habe ich gerade Hardwareprobleme. Daher komme ich vorerst nicht
zum Testen.
Leo C. schrieb:> Wenn jetzt noch die "<" vom linken zum rechten Rand wandern...
Stimmt, sieht nicht schön aus ;-) Ist behoben.
Da der Propeller noch viele Pins frei hat, könnte ein Pin ein Piezo
Beeper bekommen. Damit würde auch ein BEL ausgegeben werden. Weiterhin
ist mit einem weiteren freien Pin ein AVR Reset möglich. Damit könnte
über eine Taste (z. B. F12) ein AVR Reset ausgeführt werden. Die Taste
F1 ist derzeit mit einem Terminal Reset belegt (ganz nützlich wenn das
Terminal derzeit noch Fehlfunktionen zeigt). Hier könnten wir uns auch
eine zugeordnete Taste überlegen (F11 ??). Übrigens, Alt Break steht
noch auf meiner Liste.
Gestern Abend habe ich mal die Sonntag-Nachmittag-Version getestet.
Für Ladder reichts jetzt :-)
Ein kosmetisches Plus wäre die Möglichkeit, den Curser abzuschalten.
Auf dem Bild sieht man ihn an ca. 4 Stellen gleichzeitig. Das Original
VT-100 kann das zwar nicht, aber spätestens ab VT-220 gehts[1]:
1
4.6.7 Text Cursor Enable Mode (DECTCEM)
2
Text cursor enable mode determines if the text cursor is visible.
3
You set and reset this mode as follows.
4
5
Mode Sequence Action
6
Set 9/11 3/15 3/2 3/5 6/8 Makes the cursor visible.
7
CSI ? 2 5 h
8
9
Reset 9/11 3/15 3/2 3/5 6/12 Makes the cursor not visible.
10
CSI ? 2 5 l
Joe G. schrieb:> Da der Propeller noch viele Pins frei hat, könnte ein Pin ein Piezo> Beeper bekommen. Damit würde auch ein BEL ausgegeben werden. Weiterhin
Gut.
> ist mit einem weiteren freien Pin ein AVR Reset möglich. Damit könnte> über eine Taste (z. B. F12) ein AVR Reset ausgeführt werden. Die Taste> F1 ist derzeit mit einem Terminal Reset belegt (ganz nützlich wenn das> Terminal derzeit noch Fehlfunktionen zeigt). Hier könnten wir uns auch> eine zugeordnete Taste überlegen (F11 ??).
Ich hatte schon mal den umgekehrten Weg angedacht: Propeller-Reset durch
AVR auslösen, um über CP/M ein neues Propeller-Programm zu laden. Da am
AVR aber gar keine Pins mehr frei sind, könnte man vielleicht beide
Resets gleichzeitig auslösen...
Reichen die freien Pins auch noch für einen seriellen oder parallelen
Druckerport? Die Frage/der Vorschlag ist höchstens halb Ernst gemeint,
da diese Erweiterung einfacher über I2C realisierbar wäre.
> Übrigens, Alt Break steht noch auf meiner Liste.
Gut. Inspiriert vom Linux Magic SysRq [2] möchte ich die
Break-Funktion bei Gelegenheit auch noch etwas ausbauen.
Nachtrag:
Die nostalgische Farbe ist ja verschwunden. Naja, "richtige" VT-100 sind
auch schwarz/weiß, und demnächst wird man die Farbe wahrscheinlich
selbst einstellen können.
[1] http://vt100.net/docs/vt220-rm/chapter4.html#S4.6.7
[2] http://en.wikipedia.org/wiki/Magic_SysRq_key
Leo C. schrieb:> Ein kosmetisches Plus wäre die Möglichkeit, den Curser abzuschalten.
Ein später Hinweis, aber noch nicht zu spät ;-) Bisher wird der Cursor
immer in den jeweiligen Routinen gesetzt.
Leo C. schrieb:> Da am> AVR aber gar keine Pins mehr frei sind, könnte man vielleicht beide> Resets gleichzeitig auslösen...
Dazu Kompromissvorschlag. Für einen Sotwaretest sind beide unabhängigen
Restfunktionen ganz nützlich. Ich lege jedes Reset auf einen getrennten
Pin am Propeller und per Software kann man sich die jeweilige
Konfiguration wählen. Etwa so:
Variante Reset AVR Reset Propeller Taste
1 x F11
2 x F12
3 x x F12
Leo C. schrieb:> Reichen die freien Pins auch noch für einen seriellen oder parallelen> Druckerport?
Die Pins würden reichen. Tatsächlich habe ich auch schon darüber
nachgedacht. Mir viel jedoch bisher keine sinnvolle Lösung zur Kopplung
VT100 – CP/M – COM oder PRT ein.
Leo C. schrieb:> Gut. Inspiriert vom Linux Magic SysRq [2] möchte ich die> Break-Funktion bei Gelegenheit auch noch etwas ausbauen.
Wirklich nett!
Leo C. schrieb:> Nachtrag:> Die nostalgische Farbe ist ja verschwunden. Naja, "richtige" VT-100 sind> auch schwarz/weiß, und demnächst wird man die Farbe wahrscheinlich> selbst einstellen können.
genau
Joe G. schrieb:> Dazu Kompromissvorschlag. Für einen Sotwaretest sind beide unabhängigen> Restfunktionen ganz nützlich. Ich lege jedes Reset auf einen getrennten> Pin am Propeller und per Software kann man sich die jeweilige> Konfiguration wählen. Etwa so:> Variante Reset AVR Reset Propeller Taste> 1 x F11> 2 x F12> 3 x x F12
Ich weiß nicht, ob sich der ganze Aufwand überhaupt lohnt. Die Idee, den
Propeller durch den AVR zu resetten, kam mir, weil das Umstecken der
Jumperkabel so umständlich war. Inzwischen geht das aber, und bei
Gelegenheit werde ich einen Schalter dran bauen.
Ich dachte, man kann sich das Umstecken sparen, wenn man den Propeller
vom CP/M aus programmiert. Da der AVR dann aber keine Verbindung zu
einem PC hat, und das programmieren aus dem Reset heraus starten müßte,
macht die Sache wohl nur mit einem Bootloader Sinn, der das
Propellerprogramm von der SD-Karte lädt. Alles in allem ziemlich viel
Aufwand.
>> Reichen die freien Pins auch noch für einen seriellen oder parallelen>> Druckerport?>> Die Pins würden reichen. Tatsächlich habe ich auch schon darüber> nachgedacht. Mir viel jedoch bisher keine sinnvolle Lösung zur Kopplung> VT100 – CP/M – COM oder PRT ein.
Auf Terminalseite so:
Printer 9/11 3/5 6/9 Turns on printer controller mode.
4
Controller CSI 5 i
5
6
9/11 3/4 6/9 Turns off printer controller mode.
7
CSI 4 i
8
9
The terminal sends received characters to the printer without displaying them on the screen.
10
All characters and character sequences except NUL, XON, XOFF, CSI 5 i, and CSI 4 i are sent
11
to the printer. The terminal does not insert or delete spaces, provide line delimiters, or
12
select the correct printer character set. Printer controller mode has a higher priority than
13
auto print mode. You can select printer controller mode during auto print mode.
14
15
In printer controller mode, keyboard activity continues to be directed to the host.
Auf CP/M-Seite kann man dann z.B. ein extra Druckprogamm schreiben. Da
auf CP/M ja immer nur ein Programm laufen kann, gibts keine Konflikte
mit der Console. Eigentlich würde man aber gerne einen Treiber im BIOS
haben wollen, der die Druckerausgabe in den Consolendatenstrom einfügt.
Damit das ohne Verklemmungen in jeder Situation einwandfrei
funktioniert, dürfte der Aufwand erheblich sein.
Wahrscheinlich ist es viel einfacher, eine parallele oder serielle
Druckerschnittstelle an I2C zu klemmen. Die Serielle könnte zudem für
andere Zwecke genutzt werden.
Es gibt für das VT100 neue Funktionen.
- Cursor unsichbar schalten wie VT220 (für Spieler)
- inverse Zeichendarstellung
- setzen der Vordergrund- und Hintergrundfarbe
- Pfeiltastenfunktion
Alle derzeit realisierten Funktionen sind im VT100.pdf beschrieben.
Code und PDF hier:
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Der Bildschirm ist wieder grün. ;-)
Invers funktioniert. Den Rest habe ich noch nicht getestet.
Ist Dir der Fehler im Wordstar Hauptmenü schon aufgefallen?
Bei der Überschrift des Directories fehlt der erste Buchstabe:
Schaltet man mit 'F' das Dir aus und wieder an, ist Der Buchstabe da.
Wechselt man das Laufwerk mit 'L' fehlt der Buchstabe wieder.
Der Fehler ist ab Revision 66 zu sehen. Mit r65 gehts noch.
Joe, hast Du eigentlich mein Posting vom 31.3. (Ostern) gesehen?
Leo C. schrieb:> Bei der Überschrift des Directories fehlt der erste Buchstabe:
Danke!
Es scheint ein Timing Problem zu sein. Direkt vor der Ausgabe von
"Directory" wird die Sequenz ESC[11;01H ausgeführt. Wenn sie fertig ist,
der Cursor an der richtigen Stelle steht, ist das "D" schon aus dem
Puffer. :-( Mal sehen ob ich die Geschwindigkeit noch etwas erhöhen
kann. Spin ist recht langsam in der Ausführung.
Leo C. schrieb:> Joe, hast Du eigentlich mein Posting vom 31.3. (Ostern) gesehen?
Ja, habe ich gesehen und leider noch nicht getestet (ADC). Ist jedoch
als nächstes auf dem Plan. In diesem Zusammenhang gleich eine Frage an
alle.
Nach Rücksprache mit der Redaktion der Zeitschrift FUNKAMATEUR würden
sie uns Platz für einen Beitrag zum CP/M System einräumen (2 Seiten).
Dazu sind natürlich externe Anwendungen wünschenswert und der ADC zählt
ganz sicher dazu. Weiterhin würde ich ein LCD Display mal über I2C
ankoppeln bzw. den Franklin Light Sensor aus einem anderen Beitrag hier
im Forum. Welche Ideen hättet ihr noch?
Für den Beitrag im FA würde ich die Schaltung und das Layout auch
nochmals anpassen. Auch hier sind Korrekturen und Wünsche willkommen.
Die folgenden Wünsche stehen schon auf meiner Liste.
- Stützbatterie statt Goldcap
- korrektes Layout für RTC
- LED an SD Card
- Pull Up an SD Card
- Piezo für Bell Signal vom Propeller
- AVR Reset vom Propeller
Um die vielen DRAM Varianten zu integrieren, könnte auf der Leiterplatte
einfach eine DIL Fassung für einen (Norm)RAM vorgesehen werden. Auf
einer kleinen Zusatzplatine kann dann jeder seinen vorhandenen RAM
auflöten und in die DIL Fassung stecken.
Joe G. schrieb:> Es scheint ein Timing Problem zu sein.
Scheint mir eher nicht so. Bei 9600 ist das Problem auch noch. Bei 80MHz
hat der Spin-Interpreter dann immerhin 80000 Takte pro Zeichen. Ich
wollte gerade noch langsamer testen, aber bei 4800 Baud funktioniert
unsere Soft-UART (RX) nicht mehr. :(
> Ja, habe ich gesehen und leider noch nicht getestet (ADC). Ist jedoch> als nächstes auf dem Plan.
Das Ganze war ein Schnellschuß zum Probieren und als
Diskussionsgrundlage. Erweiterung auf 10 Bit wäre kein Problem. Die
Temperatur- und VCC-Messung würde ich wieder raus werfen.
> Nach Rücksprache mit der Redaktion der Zeitschrift FUNKAMATEUR würden> sie uns Platz für einen Beitrag zum CP/M System einräumen (2 Seiten).> Dazu sind natürlich externe Anwendungen wünschenswert und der ADC zählt> ganz sicher dazu. Weiterhin würde ich ein LCD Display mal über I2C> ankoppeln bzw. den Franklin Light Sensor aus einem anderen Beitrag hier> im Forum. Welche Ideen hättet ihr noch?
Nützliche Aufgaben für das Gerät fallen mir eigentlich nicht ein. ;-)
> - Stützbatterie statt Goldcap> - korrektes Layout für RTC
+ C, bzw. Trimmer an OSCI
> Um die vielen DRAM Varianten zu integrieren, könnte auf der Leiterplatte> einfach eine DIL Fassung für einen (Norm)RAM vorgesehen werden. Auf> einer kleinen Zusatzplatine kann dann jeder seinen vorhandenen RAM> auflöten und in die DIL Fassung stecken.
Oh je. Was wäre denn ein (bzw. das) Norm-RAM?
> aber bei 4800 Baud funktioniert unsere Soft-UART (RX) nicht mehr. :(
Geht jetzt ab 2400 Baud.
Noch langsamer ist zusätzliche Arbeit, die ich mir jetzt spare.
Der Fehler mit Wordstar ist auch mit 2400 noch da. Wordstar schreibt
erst das Directory, dann die Überschrift-Zeile "directory of disk A:",
und dann wird die Zeile darüber gelöscht. Dabei, oder danach, wird das
'd' gelöscht.
Ich bin schon auf der Suche und habe die Sequenz abgespeichert. Erst
wird alles korrekt geschrieben und dann der Cursor an die Stelle von "d"
gesetzt und gelöscht, ich bleibe dran...
Anbei die überarbeitete Schaltung. Folgende Änderungen sind
eingeflossen:
- Stützbatterie CR2032 für RTC
- korrektes Layout für RTC
- LED an SD Card
- Pull Up an SD Card
- Piezo für Bell Signal vom Propeller
- AVR Reset vom Propeller
- Trimmer für RTC
- Layout für SD-Slot von Attend (erhältlich bei Pollin)
Gibt es nöch Änderungen oder Wünsche?
ADC 0x17 bis 0x21
Nun habe ich endlich auch mal die beiden ADC Wandler mit der Testversion
überprüft.
0x17 und 0x18 gehen gut,
0x20 und 0x21 auch,
0x19 (Temperatursensor) habe ich nicht begriffen. Was hast du dort
angeschlossen, einen PT100?
Noch ein Vorschlag zur Erweiterung des Z-System Timers. Könnte man nicht
gleich mit LDTIM die Zeit aus der RTC übernehmen? Das Stellen mit TD
würde dann entfallen.
Nachtrag:
Die Definition von cr und lf ist jetzt in BIOS.MAC. Mit dieser
Konfiguration kann jedoch IPL.MAC nicht übersetzt werden, da die
Definition dort fehlt.
Sorry für so spät, z.Zt. komme ich zu fast nichts.
Joe G. schrieb:> Anbei die überarbeitete Schaltung. Folgende Änderungen sind> eingeflossen:>> - Stützbatterie CR2032 für RTC
Siehe 1. Bild. D2 kann eine Silizium-Diode sein. Wenn der Platz knapp
ist, kann man für D1/D2 eine Doppeldiode (BAV170) nehmen. [1]
> - korrektes Layout für RTC> - Trimmer für RTC
Weiter oben hatte ich mal vorgeschlagen, an Pin 3 und Pin 7 Pullups
vorzusehen, damit man wahlweise auch den PCF8563 einsetzen kann. Da wir
aber weder mit INT noch mit CLKOUT etwas anfangen können (außer evtl.
für Testzwecke), sind die Pullups nicht notwendig. Den 8563 könnte man
auch so einlöten, wenn er denn im gleichen Gehäuse wäre. :-( (SOT96-1
vs. SOT176-1)
[1] http://www.nxp.com/documents/user_manual/UM10301.pdf
Joe G. schrieb:> ADC 0x17 bis 0x21>> Nun habe ich endlich auch mal die beiden ADC Wandler mit der Testversion> überprüft.> 0x17 und 0x18 gehen gut,
Es gibt dort weniger Parameter zum Einstellen, als ich ursprünglich
dachte. Als Referenz kommt ja eigentlich nur Vcc in Frage.
Man könnte die Abfrage auch auf 10 Bit erweitern.
> 0x20 und 0x21 auch,
Bringt aber nix, da wegen Streuungen der internen Referenz ein Abgleich
notwendig ist. Dann kann man auch gleich die Vcc genau ausmessn.
> 0x19 (Temperatursensor) habe ich nicht begriffen. Was hast du dort> angeschlossen, einen PT100?
Dort ist ein interner Sensor angeschlossen. Siehe entsprechendes Kapitel
im Datenblatt (Anhang).
Bringt aber auch nix. Der Sensor hat starke Exemplarstreuungen und muß
abgeglichen werden (Parameter im EEPROM?). Wer den ganzen Aufwand nicht
scheut, kann auch gleich statt eines CP/M-Programms den AVR
programmieren.
> Noch ein Vorschlag zur Erweiterung des Z-System Timers. Könnte man nicht> gleich mit LDTIM die Zeit aus der RTC übernehmen? Das Stellen mit TD> würde dann entfallen.
Bei mir funktioniert es so:
- Beim Einschalten wird die Zeit aus der RTC als Systemzeit übernommen.
- Wenn die RTC vorher schon mal gestellt wurde, und die Standby-
Stromversorgung durchgehalten hat, stimmt die Uhrzeit jetzt.
- Während des Betriebs wird die Systemuhr über einen Timer-Interrupt
aktualisiert.
- Durch LDTIM wird die Uhr für ZSDOS (zB. für Timestamps) zugänlich
gemacht. Sie kann anschließend über TD abgefragt oder neu gestellt
werden.
- Wenn die Systemuhr durch TD gestellt wird, wird die neue Zeit auch in
die RTC kopiert.
Meiner Meinung nach also genau so, wie Du es gerne hättest. Falls es bei
Dir anders ist, brauche ich eine genaue Beschreibung.
LDTIM lädt den Treiber z.Zt. unter den CCP. Dadurch funktioniert der
Warmstart nicht mehr wie vorgesehen, und es gibt Probleme beim Wechseln
der SD-Karte. Den Uhrentreiber will ich bei Gelegenheit ins BIOS
verfrachten, aber das Warmstart-Problem bleibt, wenn z.B. andere
residente Programme geladen werden.
Joe G. schrieb:> Ab der Version 3.1 scheint in der CFGACPM.LIB> cr equ 13> lf equ 10> verloren gegangen zu sein.
Das sind ja keine für AVR-CP/M systemrelevanten Konstanten.
Joe G. schrieb:> Die Definition von cr und lf ist jetzt in BIOS.MAC. Mit dieser> Konfiguration kann jedoch IPL.MAC nicht übersetzt werden, da die> Definition dort fehlt.
Dann werde ich die auch in IPL.MAC definieren. Danke für den Hinweis.
Ich bin nun auch mal wieder dazu gekommen am System zu arbeiten.
- Die RTC geht im CP/M korrekt, war mein Fehler, ich hatte nicht die
korrekte BIOS Version auf meiner Card
- BEL, 07h, ^G ist implementiert (siehe Schaltungserweiterung)
- CP/M Reset ist implementiert (Taste F12) (siehe Schaltungsänderung)
Wer sich noch an den Aufbau wagen möchte, ich habe noch einige Platinen
hier liegen.
Das VT100 Terminal hat nun einen Arbeitsstand erreicht, der es gestattet
die Version 1.0 zu vergeben. Es sind nun alle ESC Farbsequenzen für
Vorder- und Hintergrundfarbe implementiert sowie die gestern erwähnten
Funktionen BEL und CP/M Reset. Weiterhin gibt es noch eine „hot key“
Taste (Alt+i) die von der normalen auf die inverse Textfunktion schaltet
und wieder zurück.
Wünsche und Fehler nehme ich gerne entgegen.
Hallo Gemeinde!
Erstmal vielen Dank, für die viele Arbeit, die bereits in das Projekt
gesteckt wurde!
Ich würde den CP/M-Emulator gerne nachbauen, um auch mal in den Genuß
eines Klassikers zu kommen.
Ich habe mir den kompletten Thread durchgelesen (was schon alleine
mehrere Abende gedauert hat...)
und versuch mal zu rekapitulieren:
* Z80-Emulation läuft mit ca. 2 MHz bei 20 MHz AVR-Frequenz
* CP/M und ZSDOS
* Zugriff auf SD-Karte mit FAT16 Filesystem
* Terminal mit Propeller (80x25?) und PS/2-Tastatur oder wahlweise per
USB
zusätzlich gibt es einen I2C-Anschluß, an dem bisher eine
Real-Time-Clock hängt.
Ist das soweit richtig?
Dann zu meinen Vorstellungen:
Als DRAM's habe ich hier noch folgende Chips gefunden:
HYB514256-AJ-70 256k x 4Bit
KM44C1000AJ-7 1M x 4Bit
HYB511000AJ-70 1M x 4Bit
Wenn ich den HYB514256 verwende ist die Speicheraufteilung die folgende:
62k RAM
2k System
192k RAM-Disk
Da die HYB514256 lt. Thread nicht bei allen funktioniert haben bleibt
als Alternative noch die 1M x 4Bit Chips. Wird in diesem Fall eine
größere RAM-Disk angelegt oder 'verfällt' der RAM, weil die
Adressleitungen fehlen?
@Joe:
Wäre es möglich den letzten Stand der Schaltung zu veröffentlichen?
Ich würde mir die Platine gern etwas umgestalten, da ich sie gleich auf
einer alten PS/2-Tastatur montieren möchte.
Außerdem würde ich gleich noch ein (Text-)Display und ein kleines
Soundmodul integrieren bzw. passende Anschlußmöglichkeiten dafür
vorsehen.
Sehe ich das richtig, daß der Pegelwandler zur SD-Karte weggefallen ist
und jetzt alles auf 3,3V läuft?
Wo bezieht man denn den Propeller-Chip am günstigsten?
Schön wäre ja die Lösung mit dem AVR gewesen (wie die Variante 2), aber
da ließ sich offenbar die nötige Auflösung von 80x24 und die
PS/2-Ansteuerung nicht vernünftig realisieren.
Programmiert wird der Propeller via serieller Schnittstelle? Ist da
schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,
oder wofür ist der I2C-EEPROM (AT24C512) da?
Das sollten erstmal genug Fragen sein ;-)
Viele Grüße
Jens
Jens schrieb:> Hallo Gemeinde!
Willkommen im Club.
(Auch wenn die Gemeinde sich etwas verlaufen zu haben scheint :)
> und versuch mal zu rekapitulieren:>> * Z80-Emulation läuft mit ca. 2 MHz bei 20 MHz AVR-Frequenz
Es sind inzwischen eher 3 MHz. Vielleicht sogar etwas mehr. [1]
> * CP/M und ZSDOS> * Zugriff auf SD-Karte mit FAT16 Filesystem> * Terminal mit Propeller (80x25?) und PS/2-Tastatur oder wahlweise per> USB> zusätzlich gibt es einen I2C-Anschluß, an dem bisher eine> Real-Time-Clock hängt.
+ 8-Bit Parallelport über PCF8574> Ist das soweit richtig?
Wenn wir über die letzte Leiterplatte von Joe G. reden, ja.
> Dann zu meinen Vorstellungen:> Als DRAM's habe ich hier noch folgende Chips gefunden:> HYB514256-AJ-70 256k x 4Bit> KM44C1000AJ-7 1M x 4Bit> HYB511000AJ-70 1M x 4Bit>> Wenn ich den HYB514256 verwende ist die Speicheraufteilung die folgende:> 62k RAM> 2k System> 192k RAM-Disk
256K x 4-Bit: Da bleiben nur 64K für die RAM-Disk.
> Da die HYB514256 lt. Thread nicht bei allen funktioniert haben bleibt> als Alternative noch die 1M x 4Bit Chips. Wird in diesem Fall eine> größere RAM-Disk angelegt oder 'verfällt' der RAM, weil die> Adressleitungen fehlen?
Wir haben 11 Adressleitungen. Das reicht bis 4 MByte.
Allerdings ist die RAM-Disk ziemlich uninterressant, da sie nicht
schneller als die SD-Karte ist. Ich weiß noch nicht mal, ob sie in der
aktuellen Software überhaupt noch funktioniert.
> Sehe ich das richtig, daß der Pegelwandler zur SD-Karte weggefallen ist> und jetzt alles auf 3,3V läuft?
Pegelwandler waren noch nie nötig, da ja alles mit 3,3V läuft.
> Programmiert wird der Propeller via serieller Schnittstelle? Ist da> schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,> oder wofür ist der I2C-EEPROM (AT24C512) da?
So ist es.
[1] :
Vor einigen Monaten hatte ich mal mit ein paar Benchmarks angefangen
(Dhrystone und ähnliches). Leider bin ich nicht fertig geworden und habe
keine fertigen Ergebnisse. Eine Tabelle mit den Ausführungszeiten
einzelner Befehle, habe ich aber noch gefunden:
>> * Z80-Emulation läuft mit ca. 2 MHz bei 20 MHz AVR-Frequenz> Es sind inzwischen eher 3 MHz. Vielleicht sogar etwas mehr. [1]
Gut. Ich denke das ist mir ausreichend schnell am Original Z80.
[Hardwarestand]
> Wenn wir über die letzte Leiterplatte von Joe G. reden, ja.
Ja, siehe Post vom 4.5.2013
(Beitrag "Re: CP/M auf ATmega88")
>> Dann zu meinen Vorstellungen:>> Als DRAM's habe ich hier noch folgende Chips gefunden:>> HYB514256-AJ-70 256k x 4Bit>> KM44C1000AJ-7 1M x 4Bit>> HYB511000AJ-70 1M x 4Bit>> 256K x 4-Bit: Da bleiben nur 64K für die RAM-Disk.
Ist denn die 4-Bit-Variante genauso schnell, wie die 8-Bit-Variante (mit
2 Chips)? (Ich hab mehrere Chips zur Verfügung, leider nix mit 8-Bit
Datenbreite.)
> Wir haben 11 Adressleitungen. Das reicht bis 4 MByte.> Allerdings ist die RAM-Disk ziemlich uninterressant, da sie nicht> schneller als die SD-Karte ist. Ich weiß noch nicht mal, ob sie in der> aktuellen Software überhaupt noch funktioniert.
Ok. Also mehr als 256kByte ist vorerst nicht sinnvoll.
>> Sehe ich das richtig, daß der Pegelwandler zur SD-Karte weggefallen ist>> und jetzt alles auf 3,3V läuft?> Pegelwandler waren noch nie nötig, da ja alles mit 3,3V läuft.
In der Version 2 (im Wiki), ist ein 74HCT08 zur SD-Karte verzeichnet.
Wenn nur mit 3,3V gearbeitet wurde, könnte das die Probleme mit dem
HYB514256 erklären.
Laut Datenblatt des HYB514256B/BJ ist er für 5V Vcc spezifiziert.
Apropos, hat jemand das Datenblatt zum HYB514256A/AJ?
>> Programmiert wird der Propeller via serieller Schnittstelle? Ist da>> schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,>> oder wofür ist der I2C-EEPROM (AT24C512) da?> So ist es.
Welche Größen darf der EEPROM haben? Gibt es eine Mindestgröße für die
Verwendung als VGA-Terminal? Wie kommen die Daten in den EEPROM? Gibt es
da einen Bootloader im Propeller? Ist der schon drin?
Viele Grüße
Jens
Jens schrieb:> Ist denn die 4-Bit-Variante genauso schnell, wie die 8-Bit-Variante (mit> 2 Chips)? (Ich hab mehrere Chips zur Verfügung, leider nix mit 8-Bit> Datenbreite.)
UPS, natürlich sollte man 2 Chips nehmen. 4 Bit ist schon deutlich
langsamer. Dann Stimmt Deine Rechnung also.
> Welche Größen darf der EEPROM haben? Gibt es eine Mindestgröße für die> Verwendung als VGA-Terminal?
Joe?
Ansonsten Datenblatt besorgen. Ich kann grad schlecht nachschauen, weil
ich unterwegs bin.
> Wie kommen die Daten in den EEPROM? Gibt es> da einen Bootloader im Propeller? Ist der schon drin?
Ja ist drin. (So war das "So ist es." gemeint.)
Jens schrieb:> Hallo Gemeinde!Leo C. schrieb:> Willkommen im Club.> (Auch wenn die Gemeinde sich etwas verlaufen zu haben scheint :)
Auch von mir ein Willkommen!
(Ein Gemeindemitglied war im Urlaub ;-)
Jens schrieb:> @Joe:> Wäre es möglich den letzten Stand der Schaltung zu veröffentlichen?
Ja, das werde ich demnächst tun. Wenn du mir deine Kontaktdaten
zusendest, kannst du schon jetzt den aktuellen Stand erhalten.
Jens schrieb:> Programmiert wird der Propeller via serieller Schnittstelle? Ist da> schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,> oder wofür ist der I2C-EEPROM (AT24C512) da?
Korrekt, der Propeller enthält den entsprechenden Bootloader und dieser
kann über einen seriellen Port angesprochen werden.
http://en.wikipedia.org/wiki/Parallax_Propeller#Boot_mechanism
Auf der Platine ist es über die USB-Schnittstelle realisiert. Über sie
kann der Propeller programmiert werden oder die VT100 Ausgabe an ein
externes Terminal erfolgen.
Jens schrieb:> Welche Größen darf der EEPROM haben?
mindestens 32KB
Ok. Zum Propeller bin ich jetzt im Wesentlichen aufgeklärt :-)
Noch ein paar Fragen zum Design:
Ich würde gerne nur einen Quarzoszillator verwenden. Der Propeller wird
momentan mit 5 MHz betrieben und besitzt eine interne PLL.
Diese PLL kann den Eingangstakt um den Faktor 1, 2, 4, 8 oder 16
vervielfachen.
Ich kann im Quellcode vom Terminal (Repository und VT100_V05.zip) keine
Stelle finden, an der CLKSET aufgerufen wird. Ist da evtl. nicht alles
dabei?
Wie läuft das beim Propeller, gibt es da eine Art "main", wo festgelegt
wird in welchem COG welcher Code läuft?
Im Datenblatt ist ein ominöses top objekt file erwähnt. Wo finde ich
das?
Der ATmega328 wird auch außerhalb der Spezifikation betrieben.
Laut Datenblatt (Rev. 8271E), Grafik 29-1 und Tabelle 29-11, verlässt
man oberhalb von 13,3 MHz den sicheren Betriebsbereich bei einer
Betriebsspannung von 3,3 V.
Für 20 MHz Taktfrequenz sollte man den ATmega328 mit mindestens 4,5 V
betreiben.
Meine Speicherchips sind alle noch auf 30-Pin SIMM-Modulen verbaut.
Diese SIMM-Module sind ebenfalls für 5V Betriebsspannung spezifiziert.
Von daher wäre es schon sinnvoll den Speicher und den Controller mit 5V
zu versorgen, oder?
Viele Grüße
Jens
P.S.: Was spricht eigentlich dagegen SIMM-Fassungen zu verwenden? Da
müßte ich die Chips nicht erst ablöten.
Jens schrieb:> Ich kann im Quellcode vom Terminal (Repository und VT100_V05.zip) keine> Stelle finden, an der CLKSET aufgerufen wird.
In der Datei VT100_VGA.spin
CON
'clock configuration
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 '5 MHz Quarz AVR CP/M
Jens schrieb:> Wie läuft das beim Propeller, gibt es da eine Art "main", wo festgelegt> wird in welchem COG welcher Code läuft?
Das "main"-File ist die besagte Datei VT100_VGA.spin
Die 5 MHz des Propeller sollten zunächst nicht verändert werden, da sie
den Pixeltakt sowie alle Timingsignale zur Synchronisation
bereitstellen. Die zugehörigen Konstanten befinden sich in der Datei
VGA_HiRes_Text_010.spin
Jens schrieb:> Für 20 MHz Taktfrequenz sollte man den ATmega328 mit mindestens 4,5 V> betreiben.
Bisher gab es bei keinem Nachbau damit Probleme. Viele Varianten laufen
auch mit 25 MHz oder höher. Ich denke Peter hat es sogar bis 30 Mhz
getrieben.
Die letzte Variante benutzt einen HM51W17805 als DRAM. Dieser ist für
3.3V spezifiziert.
Jens schrieb:> P.S.: Was spricht eigentlich dagegen SIMM-Fassungen zu verwenden?
Nichts, nur der Platz.
Joe G. schrieb:>> Ich kann im Quellcode vom Terminal (Repository und VT100_V05.zip) keine>> Stelle finden, an der CLKSET aufgerufen wird.>> In der Datei VT100_VGA.spin
Mein grep kann mit UTF-16 nix anfangen. Deshalb hat meine Suche nach
clk nichts gebracht...
> CON> 'clock configuration> _clkmode = xtal1 + pll16x> _xinfreq = 5_000_000 '5 MHz Quarz AVR CP/M
Also 16 * 5 MHz = 80 MHz.
Auf 80 MHz kommt man auch mit 4 * 20 MHz.
> Die 5 MHz des Propeller sollten zunächst nicht verändert werden, da sie
Wie gesagt, ich denke der Propeller läuft mit 80 MHz.
> Bisher gab es bei keinem Nachbau damit Probleme. Viele Varianten laufen> auch mit 25 MHz oder höher. Ich denke Peter hat es sogar bis 30 Mhz> getrieben.
Das mag ja sein, und ich möchte auch niemandem zu Nahe treten, aber in
meinen Augen ist das Murks.
> Die letzte Variante benutzt einen HM51W17805 als DRAM. Dieser ist für> 3.3V spezifiziert.
Jepp. Den hab ich aber nicht. (Im Gegensatz zu den SIMM-Modulen.)
>> P.S.: Was spricht eigentlich dagegen SIMM-Fassungen zu verwenden?> Nichts, nur der Platz.
Richtig, so richtig niedlich sind die nicht.
Auch ist bei SIMM das /OE nicht rausgeführt. Daher müßte man Adress- und
Datenbus trennen, was mehr Pins am AVR benötigt.
Siehe auch diesen Beitrag:
Beitrag "Re: 2MB DRAM an AVR"
Schade eigentlich.
Viele Grüße
Jens
Jens schrieb:> Auf 80 MHz kommt man auch mit 4 * 20 MHz.
Es ist natürlich möglich EINEN 20 MHz Oszillator zu verwenden und den
AVR und den Propeller damit zu takten.
Jens schrieb:> Das mag ja sein, und ich möchte auch niemandem zu Nahe treten, aber in> meinen Augen ist das Murks.
Sicherlich ist wieder eine getrennte Spannungsversorgung denkbar. In der
Variante 2 haben wir das ja auch so realisiert. Allerdings sind dann
Pegelwandler zwischen AVR und SD-Card und AVR und Propeller notwendig.
Auch kann die RAM-Konfiguration beliebig geändert werden. Da alle
Quellen offen sind, hast du hier freie Hand.
Hallo,
ich habe ein paar DRAMs gefunden:
5x MB81C4256A-70P
7x V53C104AP-80
als 20-Pin DIP. Vielleicht sind die ja für dieses Projekt kompatibel und
jemand kann sie brauchen.
Joe G. schrieb:> Stückpreis 0,55€ + Porto (0,70€ Warensendung)
Wäre bei mir wohl ähnlich...
Gruß, TS
Hallo zusammen
nach der ersten einfachen 8080-Version auf Lochraster habe ich nun dank
Joes Hilfe auch auf "seiner Platine" den Z80-Teil mit FTDI ans laufen
bekommen. VGA/Tastatur/RTC/PIO folgen demnächst.
Freundlicherweise hat mir Joe auch direkt ein 240k "Boot-Image" und ein
weiteres 8MB CPM Image gegeben, welche ich zusammen auf eine mit FAT16
formatierte SD-Karte kompiert habe.
Alles wunderbar - bin begeistert (auch wenn die Löterei der Horror war).
Nun habe ich aber noch ein paar Anfänger/DAU-Fragen:
CPMTools unter Linux:
- Habe die avrcpm-Definition eingetragen - die boot-Diskette wird sauber
ausgelesen
- Aber die 8MB Datei geht zwar unter CPM, die Tools zeigen aber nichts
an, fehlt mir hier eine file-Definition? Wie kann die dieses Image
bearbeiten?
- das erste Image lautet CPMDSK_A. -> ist LW A. das zweite CPMDSK_D ->
wird als LW B eingebunden - warum nicht als D?
FAT16
- wie groß darf ich die FAT16-Partition machen: 2GB oder 4GB?
- Muss die erste "Diskette" immer 243K haben oder kann die auch schon
8MB sein?
- Ist 8MB eine feste Obergrenze? Oder ginge auch mehr (quasi eine
Festplatten-Simulation)?
Herzlichen Dank!
Gruß
Marcel
Marcel Andre schrieb:> Hallo zusammen>> nach der ersten einfachen 8080-Version auf Lochraster habe ich nun dank> Joes Hilfe auch auf "seiner Platine" den Z80-Teil mit FTDI ans laufen> bekommen. VGA/Tastatur/RTC/PIO folgen demnächst.>> Freundlicherweise hat mir Joe auch direkt ein 240k "Boot-Image" und ein> weiteres 8MB CPM Image gegeben, welche ich zusammen auf eine mit FAT16> formatierte SD-Karte kompiert habe.>> Alles wunderbar - bin begeistert (auch wenn die Löterei der Horror war).>> Nun habe ich aber noch ein paar Anfänger/DAU-Fragen:>> CPMTools unter Linux:> - Habe die avrcpm-Definition eingetragen - die boot-Diskette wird sauber> ausgelesen> - Aber die 8MB Datei geht zwar unter CPM, die Tools zeigen aber nichts> an, fehlt mir hier eine file-Definition? Wie kann die dieses Image> bearbeiten?
Mein Fehler! Wer lesen kann.... Habe simhd ergänzt - alles klar :-)
> - das erste Image lautet CPMDSK_A. -> ist LW A. das zweite CPMDSK_D ->> wird als LW B eingebunden - warum nicht als D?>> FAT16> - wie groß darf ich die FAT16-Partition machen: 2GB oder 4GB?> - Muss die erste "Diskette" immer 243K haben oder kann die auch schon> 8MB sein?> - Ist 8MB eine feste Obergrenze? Oder ginge auch mehr (quasi eine> Festplatten-Simulation)?
Auch hier: 8MB ist offenbar die 8-bit "Systemgrenze" für CP/M. Na,
reicht ja auch :-)
> Herzlichen Dank!>> Gruß> Marcel
Das Format des 8MB Images ist das HD Format von AltairSIMH. Das hat den
Vorteil, dass man unter AltairSIMH wunderbar auf dem PC arbeiten kann
und diese Datei dann gleichzeitig unter unserem CP/M System laufen
lassen kann.
Das System welches derzeit gebootet wird ist tatsächlich ZSDOS. Alle
Quelldateien dazu befinden sich auf der 8MB HD. Um sich ein eigenes
System zusammen zu bauen musst du nur die Datei AVRCPM.SUP ausführen. In
ihr sind auch alle benötigten Quelldateien für das ZSDOS System
aufgeführt.
Die wichtigen Fragen sind ja schon beantwortet. Bleibt noch...
Marcel Andre schrieb:> - das erste Image lautet CPMDSK_A. -> ist LW A. das zweite CPMDSK_D ->> wird als LW B eingebunden - warum nicht als D?
Kurze Antwort:
Weil es so geworden ist ;-)
Und wir außerdem spätestens mit 'CPMDSK_Q.IMG' ein Problem hätten.
Längere Antwort:
Als Dateinamen für die Images sind 'CPMDSK_A.IMG' bis 'CPMDSK_Z.IMG'
erlaubt.
CP/M unterstützt maximal 16 Laufwerke, die über einen Index 0..15
verwaltet werden. Davon haben wir (bis auf weiteres) die letzten 8
(8..15, bzw I..P) für fest im BIOS definierte Laufwerke, z.B. RAM-Disks,
reserviert. Die ersten 8 (0..7, bzw. A..H) werden in aufsteigender
Reihenfolge duch die automatisch erkannten Diskimages belegt.
[3][5]
Natürlich könnte man das auch anders machen, wenns denn eine(r) macht...
> FAT16> - wie groß darf ich die FAT16-Partition machen: 2GB oder 4GB?
4G sollten gehen, da 128 Sectors/Cluster unterstützt werden [6].
> - Muss die erste "Diskette" immer 243K haben oder kann die auch schon> 8MB sein?
Wenn ich mich richtig erinnere, kann von allen unterstützten Formaten,
außer MYZ80, gebootet werden. simhd geht definitiv. [1][2][3]
> - Ist 8MB eine feste Obergrenze? Oder ginge auch mehr
Es gibt Erweiterungen, die mehr könnten.
CP/M 3 kann 512MB.
> (quasi eine Festplatten-Simulation)?
Hüstel.
Zu CP/Ms besten Zeiten waren Festplatten eher deutlich kleiner als 8 MB.
Zum Zeitpunkt der angehängten Anzeige gab es allerdings auch schon
IBM-PCs (kompatible) mit 10 MB Festplatte zum halben Preis dieser
Platte.
> Herzlichen Dank!> Gruß> Marcel
Ein Abschnitt zu Disk-Images im AVR CP/M-Artikel wäre nicht
schlecht. Damit könntest Du Deinem Dank noch stärkeren Ausdruck
verleihen. ;-)
Dazu auch noch die Hinweise [7] und [8].
Und noch ein allgemeiner Hinweis:
Die AVR-CP/M-Software enthielt lange Zeit einen Fehler, durch den bei
Image-Formaten mit Headern ungleich der physikalischen Sektorgröße (yaze
und simhd), Daten in falslche Sektoren geschrieben wurden. Der Fehler
wurde in r209 bzw. Version 3.2 behoben. Deshalb bitte keine älteren
Versionen benutzen, wenn man mit diesen Image-Formaten "arbeiten"
möchte.
[1] Beitrag "Re: CP/M auf ATmega88"
[2] Beitrag "Re: CP/M auf ATmega88"
[3] Beitrag "Re: CP/M auf ATmega88"
[4] Beitrag "Re: CP/M auf ATmega88"
[5] drvtbl in BIOS.MAC
[6] dsk_fat16.asm:
1
; Function: Cluster to HostSector
2
...
3
; ! Only works with Clustersizes 2,4,8,16,32,64,128 !
So. Ich hab jetzt mal einen Schaltplan mit den folgenden Besonderheiten
erstellt:
- SIMM-Module statt Einzel-DRAM-Chips, deswegen
- ein ATmega128 (ausreichend IO, war außerdem gerade im E-Schritt)
- SIMM und ATmega auf 5V, restliche Peripherie mit Pegelwandler auf 3,3V
- UART-Multiplexer per DIP-Switch und "ODER"-Gatter, damit PC und
PS/2-Tastatur ohne umzuschalten verwendet werden können
- I2C mit 3,3V und 5V auf 4-polige Leiste herausgeführt
- restliche IO vom Propeller-Chip herausgeführt, damit kann z.B.
Sound-IO nachgerüstet werden
- neben dem VGA-Ausgang ist auch noch ein Video-Ausgang vorhanden
- Text-Display und LEDs als Erweiterungen am I2C, können sowohl vom AVR
als auch vom Propeller angesteuert werden
Die Idee hinter der Sache ist die: ich möchte gern meine SIMM-Rigel
nicht wegen der zwei DRAM-Chips auseinandernehmen, sondern direkt
verwenden.
Außerdem scheint der Propeller ein recht interessanter Chip zu sein.
Leider ist das Eval-Board völlig überteuert. Daher habe ich die für mich
interessante Peripherie vom Propeller-Eval-Board hier mit drauf gepackt.
An den restlichen IOs kann man Erweiterungen nach Bedarf vornehmen.
Die Anschlüsse sind PMOD kompatibel.
Wer nicht basteln möchte kann sich da auch hier bedienen:
http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,401&Cat=9http://www.maximintegrated.com/app-notes/index.mvp/id/5468
Die UART-Schnittstelle soll mehrere Funktionen erfüllen:
- Debugging AVR (PC <-> AVR)
- Debugging Propeller (PC <-> Propeller)
- Normalbetrieb, AVR sendet -> Propeller und PC empfangen
Propller (PS/2) oder PC senden -> AVR empfängt
So. Nun muß ich mal sehen, wie ich das Ganze auf eine (oder mehrere)
Platine(n) bringe.
Wer mag, kann mal drüber schauen, auch wenn es etwas voll geworden ist.
Aber so kann ich es noch ausdrucken und komme mit Eagle-Freeware aus.
Viele Grüße
Jens
Da hast du ja viel Arbeit investiert!
Was mir beim flüchtigen Betrachten auffällt.
Der AVR läuft mit 5V, der FT232 und der Propeller mit 3.3V. Nun
verbindest du Tx und Rx mit diesen unterschiedlichen Pegeln (AVR –
Prop.)
Liegen die ungenutzten Tx-Pins immer auf High damit das „Oder“
funktioniert?
Die gänzlich andere DRAM-Beschaltung bedingt eine neue RAM-Ansteuerung,
die Verwendung der AVR UART ersetzt die Soft UART. Wenn schon so viele
Änderungen, warum denn nicht gleich ein XMEGA mit ordentlicher
DRAM-Beschaltung?
Fazit:
Was ist der Gewinn der neuen Schaltung? Außer vielen Softwareänderungen
kann ich keine Vorteile erkennen. Doch das ist meine ganz persönliche
Meinung, ich möchte dich nicht in deinem Elan bremsen.
Nachtrag:
Wenn es dir um die zwei Versorgungsspannungen und den RAM geht, schlage
ich folgende Lösung vor. Alles läuft weiter auf 3.3V und der AVR wird
halt langsamer getaktet. An den jetzigen „DRAM-Bus“ kommt eine
„Hardwareemulation“ für einen 3.3V SRAM. Der Adress- /Datenmultiplexer
kann über RAS/CAS geschaltet werden. Damit ändert sich in der
Ansteuerung nichts bis auf das Abschalten des Refresh was jedoch sowieso
nicht viel Zeit kostet [1].
[1] Beitrag "Re: CP/M auf ATmega88"
Joe G. schrieb:> Der AVR läuft mit 5V, der FT232 und der Propeller mit 3.3V. Nun> verbindest du Tx und Rx mit diesen unterschiedlichen Pegeln (AVR –> Prop.)
Da ist noch der Pegelwandler dazwischen (TXB0108).
> Liegen die ungenutzten Tx-Pins immer auf High damit das „Oder“> funktioniert?
Meines Wissens nach ist der Ruhezustand auf den UART-Leitungen '1'.
Aber ausprobiert habe ich das mit der "Veroderung" noch nicht.
> Die gänzlich andere DRAM-Beschaltung bedingt eine neue RAM-Ansteuerung,> die Verwendung der AVR UART ersetzt die Soft UART. Wenn schon so viele> Änderungen, warum denn nicht gleich ein XMEGA mit ordentlicher> DRAM-Beschaltung?
Der Mega128 ist mir zugeflogen und die SIMM-Rigel liegen rum. Die
RAM-Ansteuerung kann ich mir leicht anpassen (hoffentlich).
Ich habe zwar den UART auf die UART-Pins gelegt, aber dort kann ich auch
erstmal Soft-UART drauf machen, muß also den Code nicht zwingend ändern.
Außerdem wäre XMEGA für mich eine neue Architektur, die für mich auf
Dauer keinen Erkenntnisgewinn bringt. Abgesehen von evtl. benötigten
neuen Programmiergeräten.
> Fazit:> Was ist der Gewinn der neuen Schaltung?
Für mich oder für die Community?
Für mich sieht es so aus:
- Propeller ist neu
- SIMM-DRAM-Ansteuerung ist neu
- UART-Veroderung ist neu (aber wenn es geht komfortabel)
- CPM kenn ich noch nicht und
ich habe meinen ersten selbstgebauten Computer :-)
Für die Community kann ich nicht sprechen. Es ist eben eine weitere
Variante. Wie bei den Linuxdistributionen ;-)
Grüße
Jens
Zum Nachtrag: Ich hab mit zwei Versorgungsspannungen kein Problem, ich
möchte nur gern alle Bauteile laut Spezifikation betreiben.
Hallo,
habe nun den Propeller in Betrieb genommen. Nachdem ich in die Falle mit
dem vertauschten RX/TX erkannt hatte und noch einige kalte Lötstellen
ausgemerzt hatte, ging es (siehe Bilder).
Aber nur so zu 90%...
Das Problem der abgeschnittenen Ränder habe ich durch manuelle
Einstellung hinbekommen - der AUTO-Modes hats nicht geschafft :-)
In WS/TP werden z.B. keine CRTL-Codes erkannt. Es geht auch kein
"Löschen nach links" - auch nicht im "DOS-Prompt" usw.
Anderes Problem: Keine Farben (alles grün) und auch kein
Bildschirm-Löschen usw.... (siehe 2. Bild)
Wo sollte ich suchen? Da ja "grundsätzlich" alles geht würde ich fast
ein HW-Problem ausschliessen?
Im CPM->USB-Modus geht alles zu 99% (Farben nicht 100%, wahrscheinlich
Problem von Hyperterminal/Minicom/Putty).
Danke euch!
Gruß
Marcel
Hallo Marcel,
die aktuelle Softwareversion gibt es hier (Version 1.0):
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Alle Codes die derzeit implementiert sind und alle Farbvarianten sind im
beigefügten Dokument aufgeführt.
So - geht nun deutlich besser.
Ab und zu kommt die Tastatur-Emulation unter TP noch ins stottern (dann
geht alles mit Shift nicht mehr...) - ist aber nicht reproduzierbar.
Verstehen tue ich allerdings die ESC-Codes für die Farben noch nicht.
Grundsätzlich wirken sich die Codes offenbar auf den GANZEN Bildschirm
aus - nicht auf die folgenden Zeichen? Zumindest mein Testprogramm in TP
verhält sich so.
Gemäß VT100.pdf:
write(chr(27) + '[44m');
-> setzt den ganzen Bildschirm in Blau. Schrift auch in blau, vor grünem
Hintergrund.
Code 34m: -> setzt den ganzen Bildschirm schwarz, Text dann schwarz vor
blauem Hintergrund.
Scheint alles invers zu sein.
ESC 7m bewirkt aber keine Invers-Umschaltung. ALT-i hilft bei TP auch
nicht.
Die Steuer-Codes (Löschen usw.) verhalten sich unter TP und WS
unterschiedlich - aber wenn ich hier weiter oben lese ist das wohl
normal...
Gruß
Marcel
Marcel Andre schrieb:> Grundsätzlich wirken sich die Codes offenbar auf den GANZEN Bildschirm> aus - nicht auf die folgenden Zeichen? Zumindest mein Testprogramm in TP> verhält sich so.
Korrekt. Da der Bildwiederholspeicher des Propeller begrenzt ist, werden
die Farben nur für den gesamten Bildschirm gesetzt. ESC[44m setzt also
den Bildschirmhintergrund blau unabhängig von der Vordergrundfarbe.
ESC[32m würde dann den Text grün darstellen.
Der Bildwiederholspeicher ist gerade so groß, dass es möglich wäre jeder
Textzeile eine andere Vordergrund- und Hintergrundfarbe zuzuordnen. Aber
ob das Sinn macht?
Marcel Andre schrieb:> ESC 7m bewirkt aber keine Invers-Umschaltung.
Sollte es eigentlich tun, ALT i auch, ich überprüfe es mal.
F1 sollte alles wieder in den Grundzustand setzen, also invers aus, grün
auf schwarz.
Marcel Andre schrieb:> Die Steuer-Codes (Löschen usw.) verhalten sich unter TP und WS> unterschiedlich - aber wenn ich hier weiter oben lese ist das wohl> normal...
Grundsätzlich können ja bei der WS-Konfiguration einige Steuerzeichen
selbst definiert werden. Möglicherweise unterscheiden sie sich in der
Version gerade von TP.
Rein theoretische Frage: Wäre es eigentlich möglich, auf der vorhandenen
Hardware (CP/M Stick V 3.2) einen Intel 8086 oder 8088 zu emulieren und
da darauf dann PTS-DOS laufen zu lassen?
Okay, das klingt ja interessant. Mal gucken, ob ich mit meinen
bescheidenen Kenntnissen da was hinbekomme. (Hatte mal 2 Jahre
Assemblerprogrammierung für Intel 8051 in der Schule und C Kenntnisse
hab ich auch, die werden wohl weniger helfen). Jetzt muss ich sowieso
erstmal das AVR Tutorial durcharbeiten. Bin ziemlich am Anfang. Hab mir
übers lange Wochenende den Thread hier durchgelesen und gemerkt, dass
ich nicht viel verstehe...
So, habe nun die Uhr und den Parallel-Port erfolgreich "am Laufen".
Schon toll - das Konzept mit den virtuellen Ports für I2C und den
Parallel-Chip. Großes Lob an Leo für die Implementierung!
Habe erfolgreich in TP die Ports gelesen und geschrieben (Blinker :-))
Joe erwähnte, dass auf Port 17-22 (?) auch die ADCs des AVR liegen? In
der virt_ports.asm habe ich die aber nicht gefunden.
Einen Krampf bekomme ich immer noch bei den Terminal-Emulationen. Es
reicht ja schon, dass Propeller-Terminal und USB-Terminal (Putty) sich
anders verhalten bzgl. Bildschirm und KeyCodes. Auch klar, dass sich
Programme unterschiedlich verhalten bei den Steuertasten (wie TP und
WS), das kann man mit Muße konfigurieren. Aber dass sich auch ein
Programm selber unterschiedlich verhält... Siehe TP: Im Menü geht DEL
(nach links), im Editor nicht mehr (zumindest im Terminal)... Argggg :-)
Kann mir jemand ein gutes Terminalprogramm für Windows und/oder Linux
empfehlen? Putty und minicom habe ich probiert... Evtl. optimierte
Settings?
Schönen Abend noch!
Marcel
Tera Term mit der VT100 Einstellung sollte alles richtig machen.
Marcel Andre schrieb:> Joe erwähnte, dass auf Port 17-22 (?) auch die ADCs des AVR liegen? In> der virt_ports.asm habe ich die aber nicht gefunden.
;------------------------ ADC Interface
----------------------------------
;17-19 23,25 in - ADC Channels 6,7 and 8 (Temp-Sensor)
; ADC 6,7 only Devices in 32 pin Case (TQFP/MLF)
; 8 Bit only
; Fixed ADC clock (FCPU/128, 156KHz at 20MHz CPU)
; Vref = VCC
;20,21 in - ADC: Measure VCC
;
Joe G. schrieb:> Marcel Andre schrieb:>> Joe erwähnte, dass auf Port 17-22 (?) auch die ADCs des AVR liegen? In>> der virt_ports.asm habe ich die aber nicht gefunden.>> ;------------------------ ADC Interface> ----------------------------------> ;17-19 23,25 in - ADC Channels 6,7 and 8 (Temp-Sensor)> ; ADC 6,7 only Devices in 32 pin Case (TQFP/MLF)> ; 8 Bit only> ; Fixed ADC clock (FCPU/128, 156KHz at 20MHz CPU)> ; Vref = VCC> ;20,21 in - ADC: Measure VCC
In virt_ports.asm sind die Einträge seit SVN r214 drin. Nützt aber
nichts, da ich den eigentlichen ADC-Code noch nicht eingecheckt habe.
Ich hatte nur an Ostern eine "ADC-Testversion" hier als
Diskussionsgrundlage gepostet. Diskussion gabs keine, aber ich bin
inzwischen der Meinung, daß die Temperatur- und VCC-Messungen ziemlich
unsinnig sind und nur Verwirrung stiften, und deshalb entfernt werden
sollten. Im Anhang ist noch mal der fehlende Code.
Marcel Andre schrieb:> Siehe TP: Im Menü geht DEL> (nach links), im Editor nicht mehr (zumindest im Terminal)... Argggg :-)> Kann mir jemand ein gutes Terminalprogramm für Windows und/oder Linux> empfehlen? Putty und minicom habe ich probiert... Evtl. optimierte> Settings?
Meinst Du mit DEL die Taste mit dem Pfeil nach links oder die Taste, die
auf deutschen Tastaturen mit "Entf" beschriftet ist?
Wahrscheinlich sendet Deine DEL-Taste 0x08 (Backspace). "Löschen links"
geht aber in (mindestens) Turbopascal und Wordstar mit 0x7F (Delete).
minicom funktioniert bei mir mit der Einstellung "Backspace key sends:
DEL" (Terminal settings).
Eigentlich braucht man unter linux aber gar kein (extra)
Terminalprogramm. "$ cu -l /dev/ttyUSB0 -s 115200 --nostop" tuts auch.
(Allerdings grade nicht mit der Propeller-Platine. Wahrscheinlich, weil
DCD und/oder DSR nicht aktiv sind.)
Hier ist noch mehr zum Thema:
Beitrag "Re: CP/M auf ATmega88"
Leo C. schrieb:> Wahrscheinlich sendet Deine DEL-Taste 0x08 (Backspace). "Löschen links"> geht aber in (mindestens) Turbopascal und Wordstar mit 0x7F (Delete).
In den meisten Terminal-Emulationsprogrammen lässt sich das Verhalten
der Backspace-Taste einstellen - so auch in PuTTY. Das ging auch schon
in den damaligen DEC-Terminals der 80er Jahre... und sorgte damals schon
für jede Menge Verwirrung unter DEC/VMS, PDP11/RT bzw. Ultrix.
So, ich wollte mich mal wieder melden...
Hier mein aktueller Stand:
Die Idee mit der gemeinsamen Taktquelle (20 MHz für AVR und Propeller)
habe ich wieder verworfen, da der ATmega128 nur bis 16 MHz spezifiziert
ist.
Außerdem mußte ich AVR/CPU und Propeller/IO trennen, da es aussichtslos
schien, mit zwei Lagen den von mir gewünschten Formfaktor (Leiterplatte)
zu realisieren.
Dabei habe ich auch gleich die Schaltpläne getrennt (Anhang).
Danach wurden die Leiterplatten geroutet und gefertigt, Bauteile
bestellt und fleißig bestückt.
Viel geprüft und gemessen und dann hab ich die Schaltungen Stück für
Stück in Betrieb genommen.
Dabei wurden kleine Testprogramme (in C) für die einzelnen Funktionen
geschrieben oder genutzt:
Was bisher getestet wurde:
* ATmega128 (16 MHz Takt) --> funktioniert
* UART mit FTDI und 115200 kBit/s --> funktioniert
* SD-Karte (nachdem der richtige Pegelwandler verbaut wurde: TX_S_0108)
--> funktioniert
* SIMM-Riegel (256 kB, 1 MB, 4 MB) --> funktioniert
* die DIP-Umschalter am UART-Multiplexer (PC <-> AVR, PC <-> Propeller)
--> funktionieren
Damit muß man nicht umjumpern, sondern braucht nur die kleinen
Umschalter betätigen :-)
* Propeller --> funktioniert
Ich hab ein paar Spin-Beispiele ausprobiert und dann das aktuelle
VT100-VGA-Spin eingespielt.
Was noch ungetestet ist:
* RTC
* Video-Ausgabe (RCA-Buchse)
* I2C (mit 3.3V und 5V)
* ADC-Kanäle am AVR
Mängel, die mir bisher aufgefallen sind:
* Der Buzzer ist viel zu leise, eigentlich knackt er nur beim Ein- und
Ausschalten.
Damit der richtig geht, muß ich mit dem Propeller eine Frequenz
ausgeben.
* Auf der ATmega128-Leiterplatte hab ich zu wenig Platz um die
ISP-Buchse gelassen, unschön.
* Der Spannungsregler AP1117 schwingt gelegentlich (bei ca. 3,8 kHz), da
müssen größere Kondensatoren in die Nähe.
* Es fehlt ein Pullup an Propeller-TX, damit auch bei abgesteckter
Propellerplatine die TX-Veroderung geht.
* Das Propellerterminal kommt nicht wirklich mit 115200,8,N,1 aus. Dort
werden Zeichen verschluckt und Bits falsch interpretiert, wenn es zu
schnell geht.
Wenn man auf Senderseite zwei Stopbits einsetzt, geht es etwas besser,
aber immer noch nicht perfekt.
Außerdem fehlt noch die dritte Platine. Dort soll folgendes drauf:
* der 8-Bit Parallelport
* ein Display (nur welches? Text oder Grafik? LCD oder OLED?)
* Soundmodul
* ...?
Den aktuellen Schaltplan gibt es als Anhang, die Layouts werde ich bei
Gelegenheit auch noch veröffentlichen.
Jetzt sitze ich an der Speicheranbindung.
Vielleicht kann mir jemand (Leo?) sagen, was an der folgenden Ausgabe
falsch ist?
1
CPM on an AVR, v3.2 r216
2
Testing RAM: fill...wait...reread...
3
Addr xx yy
4
0083 83 83 -------- --------
5
00CC CC CC -------- --------
6
0225 27 27 -------- --------
7
0356 55 55 -------- --------
8
03D2 D1 D1 -------- --------
9
0407 03 03 -------- --------
10
0428 2C 2C -------- --------
11
04E9 ED ED -------- --------
12
0501 04 04 -------- --------
13
0576 73 73 -------- --------
14
0658 5E 5E -------- --------
15
0819 11 11 -------- --------
16
08F2 FA FA -------- --------
17
09E8 E1 E1 -------- --------
18
0A78 72 72 -------- --------
19
0B96 9D 9D -------- -------- System halted!
Und gleich noch eine Frage: An welcher Stelle werden die Adressleitungen
A8-A10 verwendet?
Bei dram_write und dram_read habe ich nichts gefunden. Dort wird immer
nur mit A0-A7 + A0-A7 gearbeitet (16 Bit = 64 kByte).
Ansonsten hier noch einmal Vielen Dank an die vielen Helfer, die die
Vorarbeit geleistet haben!
Es ist ein sehr spannendes Projekt :-)
Bis später
Jens
Nur ganz kurz, Morgen habe ich wahrscheinlich mehr Zeit, um auf Deine
Schaltung einzugehen:
Jens schrieb:> Und gleich noch eine Frage: An welcher Stelle werden die Adressleitungen> A8-A10 verwendet?
Bisher nur bei der RAM-Disk. Siehe dsk_ram.asm (8-bit).
Ansonsten werden A8-A10 bei allen DRAM-Zugriffen immer auf High
gehalten. Etwas mehr Info fidest Du vielleicht hier:
Beitrag "Re: CP/M auf ATmega88"
Hallo Jens,
spannend, dass du auch die Probleme mit der Propeller-VGA-Ausgabe hast.
Ich nutze die Platine von Joe. Anfangs ging es auch - aber seit ca. 2
Wochen habe ich immer an den genau gleichen Stellen Lücken in der
Darstellung oder falsche Interpretation von Zeichen usw.
Das scheint aber nicht immer ein Problem zu sein - bei Joe läuft es wohl
derzeit stabil. Bislang gibt es hier noch kein Indiz, woran das genau
liegt - da es ja beim einen geht - beim anderen nicht bzw. sich zeitlich
ändert...
Gruß
Marcel
Ich habe momentan etwas wenig Zeit, doch ich werde mich in einer ruhigen
Minute mal dem Problem mit der VGA-Ausgabe annehmen. Vermutlich ist es
einer der CTRL-Befehle der den Bildschirmspeicher zu weit überschreibt.
Da gleich darauf der V24 Puffer folgt, entstehen dabei die Probleme.
Jens schrieb:> Vielleicht kann mir jemand (Leo?) sagen, was an der folgenden Ausgabe> falsch ist?CPM on an AVR, v3.2 r216> Testing RAM: fill...wait...reread...> Addr xx yy> 0083 83 83 -------- --------
...
> 0B96 9D 9D -------- -------- System halted!
Falsch ist, daß Zellen ausgegeben werden, die angeblich gar keinen
Fehler haben. Unter xx steht, was in die Zelle geschrieben wurde, und
unter yy, was später gelesen wurde. Wenn die beiden Wert gleich sind,
dürfte also gar nichts ausgegeben werden. In der Testroutine kann ich
keinen Fehler entdecken. Bin ratlos.
Hier noch was zum Ramtest:
Beitrag "Re: CP/M auf ATmega88"
Leo C. schrieb:> Falsch ist, daß Zellen ausgegeben werden, die angeblich gar keinen> Fehler haben. Unter xx steht, was in die Zelle geschrieben wurde, und> unter yy, was später gelesen wurde. Wenn die beiden Wert gleich sind,> dürfte also gar nichts ausgegeben werden. In der Testroutine kann ich> keinen Fehler entdecken. Bin ratlos.
Ich glaube an meinem refresh ist was falsch. Ich bin in AVR-ASM nicht so
die Leuchte (C liegt mir mehr). Vielleich fällt Euch ja was auf:
[asm]
.cseg
INTERRUPT OC2Aaddr
push temp ; 2
LDS temp, RAM_CTRL_PORT ; 2
; gehe am refresh vorbei, wenn gerade ein Zugriff erfolgt
; ras = 0 -> Zugriff
; ras = 1 -> kein Zugriff -> refresh
sbrs temp, ram_ras ; 2
rjmp norefresh ; 2
; CAS RAS
cbr temp, (1<<ram_cas) ; 1 1 1
STS RAM_CTRL_PORT, temp ; 2 0 1
cbr temp, (1<<ram_ras) ; 1 0 1
STS RAM_CTRL_PORT, temp ; 2 0 0
sbr temp, (1<<ram_ras) ; 1 0 0
STS RAM_CTRL_PORT, temp ; 2 0 1
cbr temp, (1<<ram_ras) ; 1 0 1
STS RAM_CTRL_PORT, temp ; 2 0 0
sbr temp, (1<<ram_ras) ; 1 0 0
STS RAM_CTRL_PORT, temp ; 2 0 1
sbr temp, (1<<ram_cas) ; 1 0 1
STS RAM_CTRL_PORT, temp ; 2 1 1
norefresh: ;
pop temp ; 2
reti ; 4 --> 32 cycles
[/asm]
Dummerweise habe ich die Speichersteuerleitungen (RAS, CAS, WE) an Port
G gelegt, da kann ich die in und out-Befehle nicht verwenden.
Viele Grüße
Jens
Joe G. schrieb:> Vermutlich ist es> einer der CTRL-Befehle der den Bildschirmspeicher zu weit überschreibt.
Hmm. Bei 'normaler' ASCII-Ausgabe werden doch gar keine CTRL-Befehle
ausgeführt. Oder doch?
Grüße
Jens
Marcel Andre schrieb:> Anfangs ging es auch - aber seit ca. 2> Wochen habe ich immer an den genau gleichen Stellen Lücken in der> Darstellung oder falsche Interpretation von Zeichen usw.
Du kanns ja mal versuchen eine kleine Pause beim Versenden einzulegen
(softuart) oder zwei Stoppbits, statt nur Einem (harduart).
Letzteres hat das Problem bei mir etwas entspannt.
Marcel Andre schrieb:> sich zeitlich> ändert...
Ich denke die verschiedenen Quarze sind unterschiedlich frequenz-,
spannungs- und temperaturstabil. Wenn das Timing da etwas knapp ist,
kann das zu den beobachteten Effekten führen.
Viele Grüße
Jens
Jens schrieb:> Ich glaube an meinem refresh ist was falsch.
Ich bin mir sogar sicher, das da was falsch ist. Wenn ich den refresh
rausnehme, komme ich zum 'Initing mmc...'
Jetzt muß ich erstmal die SD-Karte bearbeiten.
Viele Grüße
Jens
Jens schrieb:> Ich glaube an meinem refresh ist was falsch. Ich bin in AVR-ASM nicht so> die Leuchte (C liegt mir mehr). Vielleich fällt Euch ja was auf:
Du hast auf jeden Fall vergessen, das Status-Register zu retten, da
cbr/sbr-Befehle die Flags verändern.
Den Rest schaue ich mir noch an.
1
> .cseg
2
>
3
> INTERRUPT OC2Aaddr
4
>
5
> push temp ; 2
6
in temp,sreg
7
push temp
8
> LDS temp, RAM_CTRL_PORT ; 2
9
10
...
11
12
> norefresh: ;
13
pop temp
14
out sreg,temp
15
> pop temp ; 2
16
> reti ; 4 --> 32 cycles
> Dummerweise habe ich die Speichersteuerleitungen (RAS, CAS, WE) an Port> G gelegt, da kann ich die in und out-Befehle nicht verwenden.
Das ist wirklich ungeschickt.
Leo C. schrieb:> Du hast auf jeden Fall vergessen, das Status-Register zu retten, da> cbr/sbr-Befehle die Flags verändern.
Super! Jetzt geht's auch mit refresh :-)
>> Dummerweise habe ich die Speichersteuerleitungen (RAS, CAS, WE) an Port>> G gelegt, da kann ich die in und out-Befehle nicht verwenden.> Das ist wirklich ungeschickt.
Naja. Nicht ganz so tragisch. Ich habe ein paar freie Portpins auf
Stiftleisten gelegt. Da kann ich zum Optimieren noch umfädeln. Aber
erstmal muß es überhaupt funktionieren.
Nächster Punkt ist die SD-Karte...
...aber nicht mehr heute!
Viele Grüße & Vielen Dank,
Jens
Der Rest sollte eigentlich funktionieren.
Aber was hälst Du denn von folgender Variante:
1
.cseg
2
3
INTERRUPT OC2Aaddr
4
5
push temp ;2
6
LDS temp, RAM_CTRL_PORT ;2
7
8
; gehe am refresh vorbei, wenn gerade ein Zugriff erfolgt
9
; ras = 0 -> Zugriff
10
; ras = 1 -> kein Zugriff -> refresh
11
12
sbrs temp, ram_ras ;2
13
rjmp norefresh ;-
14
; CAS RAS
15
; 1 1
16
STS RAM_CTRL_PORT,_CASREF ;2 0 1
17
STS RAM_CTRL_PORT,_CAS0 ;2 0 0
18
STS RAM_CTRL_PORT,_CASREF ;2 0 1
19
STS RAM_CTRL_PORT,_CAS0 ;2 0 0
20
STS RAM_CTRL_PORT,_255 ;2 1 1
21
22
norefresh: ;
23
pop temp ;2
24
reti ;4 --> 22 cycles
Dazu in 'config.inc' statt:
.def _OE = r4
folgendes:
.def _CASREF = r4 ;CAS before RAS refresh
und in 'init.asm' das Register entsprechend initialisieren.
Hier kann man sich push/pop von SREG wieder sparen, da die verwendeten
Befehle kein Flag ändern.
Evtl. müßten noch ein paar NOPs eingestreut werden.
Leo C. schrieb:> Aber was hälst Du denn von folgender Variante:
Ist vorgemerkt. Aber optimiert wird später (Hardware + Software)
:-)
Jetzt findet er das passende Image nicht:
mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please change MMC/SD-Card.
Gerade eben wollte ich fragen, wo ich weiter zu suchen habe.
Hardwaremäßig funktioniert die SD-Karte, ich habe den Code von Roland
Riegel ausprobiert, der lief:
http://www.roland-riegel.de/sd-reader/index.html
Jetzt habe Testweise die SD-Karte nochmal neu bespielt. Mit dem Mac geht
das z.B. so:
Anschließend noch noch CPMDSK_A.IMG, CPMDSK_B.IMG und CPMDSK_C.IMG
draufkopiert.
Und auf einmal läuft es! Cool!
1
CPM on an AVR, v3.2 r216 Test
2
05 05 01 04
3
Testing RAM: fill...wait...reread...
4
Initing mmc...
5
6
A: FAT16 File-Image 'A' at: 003, size: 256KB.
7
B: FAT16 File-Image 'B' at: 057, size: 256KB.
8
C: FAT16 File-Image 'C' at: 073, size: 256KB.
9
Partinit done.
10
Ok, Z80-CPU is live!
11
12
62k cp/m vers 2.2
13
14
A>dir
15
A: ASM COM : DDT COM : DUMP COM : ED COM
16
A: T COM : TLOOP COM : LOAD COM : MBASIC COM
17
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
18
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
19
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
20
A: ZORK1 DAT : SURVEY COM
21
A>
Die vier Zahlen auf der zweiten Zeile sind von meinem
Speicher-Debugging.
Die Ausgaben vom Emulator zum Propeller laufen offenbar langasm genug,
so das auf dem VGA-Monitor alles 'ordentlich' zu sehen ist.
Dann doch noch eine Frage:
Herzlichen Glückwunsch Jens.
Jens schrieb:> Jetzt habe Testweise die SD-Karte nochmal neu bespielt. Mit dem Mac geht
...
> Und auf einmal läuft es! Cool!
Vielleicht bekommst Du ja noch raus, woran es lag.
Jens schrieb:> Die Ausgaben vom Emulator zum Propeller laufen offenbar langasm genug,> so das auf dem VGA-Monitor alles 'ordentlich' zu sehen ist.
Ja, leider ist das so. 9600 Baud würden für das 3 MHz Z80 CP/M föllig
ausreichen. Und wir bekommen jedes mal die Krise, wenn mit 115200 etwas
nicht richtig tut.
Jens schrieb:> Kann ich cseg irgendwie verkleinern? Der Flash-Vorgang dauert jedesmal> ewig (gefühlt).
Versuch mal:
$ make MMCBOOTLOADER=0 clean all
Wenn das hilft, und Du den Bootloader nicht brauchst, kannst Du den
Support dafür auch dauerhaft abschalten. Entweder im Makefile oder in
config.inc.
Leo C. schrieb:> Herzlichen Glückwunsch Jens.
Naja, der Glückwunsch gehört Euch, ich habe ja 'nur' nachgebaut...
>> Jetzt habe Testweise die SD-Karte nochmal neu bespielt. Mit dem Mac geht> Vielleicht bekommst Du ja noch raus, woran es lag.
Beim ersten Mal habe ich die Partitionierung mit dem
Festplattendienstprogramm gemacht. Ich glaube das Programm legt per
Default eine GUID (http://de.wikipedia.org/wiki/GUID_Partition_Table)
Partitionstabelle an. Das funktioniert natürlich nicht, wenn ein Master
Boot Record erwartet wird.
>> Die Ausgaben vom Emulator zum Propeller laufen offenbar langasm genug,>> so das auf dem VGA-Monitor alles 'ordentlich' zu sehen ist.> Ja, leider ist das so. 9600 Baud würden für das 3 MHz Z80 CP/M föllig> ausreichen. Und wir bekommen jedes mal die Krise, wenn mit 115200 etwas> nicht richtig tut.
Ich versuche alle meine Projekte mit 115200 bps laufen zu lassen. Das
ist für mich ein Quasistandard. Und ich denke auch, das der Propeller
die Rechenleistung hat, um das zu schaffen. Aber das gehört in die
Kategorie Optimierung Propeller.
Dort muss ich sowieso nochmal ran, damit der richtig beept.
>> Kann ich cseg irgendwie verkleinern?> Versuch mal:> $ make MMCBOOTLOADER=0 clean all
Ich hab es gleich in der config.inc deaktiviert. Jetzt dauert der
Programmiervorgang nur noch 12 Sekunden:
Jens schrieb:> Naja, der Glückwunsch gehört Euch, ich habe ja 'nur' nachgebaut...
Eben nicht 'nur'. Immerhin bist Du gerade dabei, die Menge der
unterstützten Controller zu vergrößern. Und eine zusätzliche
DRAM-Variante gibts wahrscheinlich auch. Und wenn Du die I2C-Verbindung
AVR-Propeller richtig durchziehen willst, dann bekommen wir auch noch
einen I2C-Multimaster-Treiber. :)
>> $ make MMCBOOTLOADER=0 clean all> Ich hab es gleich in der config.inc deaktiviert. Jetzt dauert der> Programmiervorgang nur noch 12 Sekunden:ATmega128 memory use summary
Mit was programmierst Du?
Bei mir für mega328p mit avrdude/dragon/isp sind es ca. 14s + nochmal
14s für den Verify. Der Unterschied ohne/mit Bootloader-Kennung ist mir
früher auch schon aufgefallen, und ich hatte überlegt, an der Stelle
etwas zu ändern. Allerdings ist der Unterschied mit avrdude 6 jetzt
verschwunden.
> A>t b>> Timer running. Elapsed: 005.021s.> A>tloop>> Timer running. Elapsed: 001.342s.> Gibt es noch einen erweiterten Benchmark?
A>act b
Timer running. Elapsed: 003.860s.
A>tloop
Timer running. Elapsed: 000.989s.
A>8q
Eight Queens. Running 2 iterations ...
Timer running. Elapsed: 007.669s.
A>
ACT.COM ist die neuere Version von T.COM. 8Q.PAS ist im Anhang.
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:
http://classes.soe.ucsc.edu/cmpe202/benchmarks/standard/dhrystone.chttp://wiretap.area.com/Gopher/Library/Techdoc/Bench/dhryst.txthttp://www.netlib.org/performance/html/dhrystone.data.col0.htmlhttp://www.ecrostech.com/Other/Resources/Dhrystone.htm
DHRYSTONE
Im Anhang sind 2 Diskimages mit C-Compilern, und jeweils dem Benchmark
Source und Binary. Für jeden Compiler habe ich jeweils eine Funktion
"time" geschrieben, die die Zeit in Sekunden liefert. Allerdings nicht
die aktuelle Uhrzeit, sondern nur die Zeit in Sekunden seit dem setzten
Reset.
Für den Test ist das ja egal.
Leider weiß ich noch nicht, warum die Laufzeit so stark schwankt. Mit
Hi-Tech C z.B zwischen 27 und 30 Sekunden, was 185 dhrystone/s bis 166
dhrystone/s entspricht. Eigentlich müßte immer das Gleiche (+- 1s)
herauskommen.
Die Ergebnisse (ca. Mittelwerte) habe ich in die Tabelle aus dem ersten
Link oben eingefügt. Sieht doch garnicht schlecht aus.
1
DHRYSTONE 1.1 BENCHMARK SUMMARY
2
SORTED BY PERFORMANCE
3
4
MANUF MODEL PROC CLOCK NOREG REG OS,COMPILER,NOTES
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:
1
Running
2
Eight Queens. Running 2 iterations ...
3
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
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:
1
<ctrl> a : readbuf <filename>
2
<ctrl> a : slowpaste 30
3
<ctrl> a ]
Durch slowpaste wird das Einfügen so verzögern, das der Emulator
hinterherkommt.
Viele Grüße
Jens
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
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
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
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
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.
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:
1
other:
2
debug.str(string("m1 not supported: "))
3
debug.hex(remote,2)
4
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
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
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):
1
{{ for keyboard-de start }}
2
3
cmp data,#de_ae wz 'replace ae
4
if_z mov data,#"ä"
5
cmp data,#de_oe wz 'replace oe
6
if_z mov data,#"ö"
7
cmp data,#de_ue wz 'replace ue
8
if_z mov data,#"ü"
Bei Joe:
1
{{ for keyboard-de start }}
2
3
cmp data,#de_ae wz 'replace ae
4
if_z mov data,#"ä"
5
cmp data,#de_oe wz 'replace oe
6
if_z mov data,#"ö"
7
cmp data,#de_ue wz 'replace ue
8
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
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:>
1
>other:
2
>debug.str(string("m1 not supported: "))
3
>debug.hex(remote,2)
4
>debug.out(13)
5
>
>> 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
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
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.
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
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/
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
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
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/
> 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/
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.
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
@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
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
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/
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...
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.
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:
1
r221 | leo | 2013-11-16 14:14:02 +0100 (Sa, 16. Nov 2013) | 1 Zeile
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.
1
Terminal type: ANSI
2
Send an initialization string to the terminal? (Y/N)? N
3
Send a reset string to the terminal (Y/N)? Y
4
Command: <ESC> [ 0 m (27 91 48 109)
5
CURSOR LEAD-IN command: <ESC> [ (27 91)
6
CURSOR POSITIONING COMMAND to send between line and column: ; (59)
7
CURSOR POSITIONING COMMAND to send after both line and column: H (72)
8
Column first (Y/N)? N
9
OFFSET to add to LINE: 1
10
OFFSET to add to COLUMN: 1
11
Binary address (Y/N)? N
12
Number of ASCII digits (2 or 3): 2
13
CLEAR SCREEN command: <ESC> [ 2 J (27 91 50 74)
14
Does CLEAR SCREEN also HOME cursor (Y/N)? N
15
HOME command: <ESC> [ H (27 91 72)
16
DELETE LINE command: <ESC> [ 1 M (27 91 49 77)
17
INSERT LINE command: <ESC> [ 1 L (27 91 49 76)
18
ERASE TO END OF LINE command: <ESC> [ K (27 91 75)
END HIGHLIGHTING command: <ESC> [ 0 m (27 91 48 109)
21
Number of rows (lines) on your screen: 24
22
Number of columns on your screen: 80
23
Delay after CURSOR ADDRESS (0-255 ms): 0
24
Delay after CLEAR, DELETE and INSERT (0-255 ms): 0
25
Delay after ERASE TO END OF LINE and HIGHLIGHT (0-255 ms): 0
26
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.
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.
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.
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
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).
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:
1
ESC[J oder ESC[0J Löschen vom Kursor nach rechts und bis zum Bildende
2
ESC[1J Löschen vom Bildanfang und von links bis zum Kursor
3
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=88Leo 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
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.
> 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.
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.
@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.
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)
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.
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
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
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.
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
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.
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/
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.
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.
Das Design ist annähernd Kompatibel. Wenn der Arduino Bootloader
installiert
ist, sollte die IDE auch laufen. Sinnvoll ist jedoch der CP/M Bootloader
;-)
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.
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.
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/mini80http://forums.parallax.com/showthread.php/148944-Propeller-Z80-CPM-hybridhttp://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.
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.
> 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.
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
> 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.
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
> 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.
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.
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.
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.
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:
http://www.youtube.com/watch?v=HkUUJ-rOUPg
Viele Grüße,
Jens
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.
> 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 */
> 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.
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.
> 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ß...
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:
- 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
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...
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:
1
$ make DRAM_8BIT=0
oder auch
1
$ 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:
1
;Port C
2
.equ SDA = 4
3
.equ SCL = 5
4-bit RAM:
1
;Port C
2
.equ RAM_W = 4
3
.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"?
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:
1
avrcpm.asm(35): info: 'config.inc' included from here
2
config.inc(374): warning: Register r8 already defined by the .DEF directive
3
avrcpm.asm(35): info: 'config.inc' included from here
4
config.inc(375): warning: Register r9 already defined by the .DEF directive
5
avrcpm.asm(35): info: 'config.inc' included from here
6
config.inc(378): warning: Register r10 already defined by the .DEF directive
7
avrcpm.asm(35): info: 'config.inc' included from here
8
config.inc(379): warning: Register r11 already defined by the .DEF directive
9
avrcpm.asm(35): info: 'config.inc' included from here
10
config.inc(382): warning: Register r12 already defined by the .DEF directive
11
avrcpm.asm(35): info: 'config.inc' included from here
12
config.inc(383): warning: Register r13 already defined by the .DEF directive
13
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
> 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.
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.)
> "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?
Leo C. schrieb:> Kannst Du mal die kompletten Boot-Meldungen posten?
Sieht eigentlich unverdächtig aus:
1
CPM on an AVR, v3.2 r216 Test
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: FAT16 File-Image 'A' at: 003, size: 8192KB.
6
B: FAT16 File-Image 'B' at: 5262, size: 8192KB.
7
C: FAT16 File-Image 'C' at: 5257, size: 8192KB.
8
D: FAT16 File-Image 'D' at: 6298, size: 8192KB.
9
E: FAT16 File-Image 'E' at: 6811, size: 8192KB.
10
F: FAT16 File-Image 'F' at: 7323, size: 8192KB.
11
Partinit done.
12
Ok, Z80-CPU is live!
13
14
62k cp/m vers 2.2
15
16
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
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.
1
$ ls -l *.IMG *.simhd
2
-rw-r--r-- 1 leo leo 8388608 Mai 2 2012 CPMDSK_A.IMG
3
-rw-r--r-- 1 leo leo 8388864 Nov 28 18:03 zextest.simhd
4
$
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.
> 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]:
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:
1
8388864 10 Okt 2010 empty.simhd
2
8314 1 Nov 2013 empty_8MByte_img.zip
Richtig muß es wohl dann so heißen:
1
8388864 10 Okt 2010 empty.myz80
2
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):
1
$ unzip -l empty_8MByte_img.zip
2
Archive: empty_8MByte_img.zip
3
Length Date Time Name
4
-------- ---- ---- ----
5
8388864 10-10-10 03:05 myz80.img
6
-------- -------
7
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
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.
Thread beobachten
Seitenaufteilung abschalten