Forum: Mikrocontroller und Digitale Elektronik CP/M auf ATmega88


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

So siehts aus.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

File vergessen

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Joe G. schrieb:
> Müßte nun alles bis auf Ö, Ä und Ü gehen.

Die gehen nun auch und jetzt ist Ostern!

von Leo C. (rapid)


Lesenswert?

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.

von Peter Z. (flexopete)


Lesenswert?

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

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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
2
rm -f avrcpm.hex avrcpm.eep avrcpm.obj avrcpm.map avrcpm.lst \
3
    avrcpm-3.1.bin
4
wine C:/Programme/Atmel/AVR\ Tools/AvrAssembler2/avrasm2.exe -I C:/Programme/Atmel/AVR\ Tools/AvrAssembler2/Appnotes -Datmega328P  -DF_CPU=20000000 -DDRAM_8BIT=1 -DBAUD=115200 -DI2C=1 -DEM_Z80=1 -DFAT16_SUPPORT=1 -DMMCBOOTLOADER=0 -fI -o avrcpm.hex avrcpm.asm
5
AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
6
Copyright (C) 1995-2009 ATMEL Corporation
7
8
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/

von Peter Z. (flexopete)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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
6
;
7
;------------------------ Ports ------------------------------------------
8
;80-87    in/out  - Port-Expander PCF8574 (max. 8 Chips)
9
;88-8F    in/out  - Port-Expander PCF8574A (not implemented yet!)
config.inc:
1
; Z80/8080 Virtual Ports
2
3
#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:
1
;------------------------ Virtual I2C interface --------------------------
2
;05  5   out     - Control Port: 1 = Start read operation
3
;                                2 = Start write operation 
4
;05  5   in      - Status of last Transfer: 0 = ok, else fail
5
;06  6   in/out  - Number of bytes to transfer, including Slave address
6
;07,08   in/out  - Read/Write address low/high
... zur Kommunikation mit beliebigen I2C-Chips.

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

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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.

von Peter Z. (flexopete)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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.

von Peter Z. (flexopete)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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"

von Peter Z. (flexopete)


Lesenswert?

ok Leo,
werde ich mal probieren, steht ja so auch im Datenblatt.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Das VT100 kann nun auch CRTL-Codes, damit ist WS oder der Turbo Editor 
zu bedienen. Den Quellcode gibt es vorerst hier...
https://code.google.com/p/avr-cpm-system/

von Leo C. (rapid)


Lesenswert?

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?

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Schaut mal ob WS nun mit VT100 bei euch läuft. Der Turbo Editor geht nun 
bei mir. Es fehlen nur noch die Farbattribute.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Der Code liegt nun nicht mehr sooo weit weg :-)
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/

Im Bild ist WS-30 zu sehen. Attribute fehlen noch.

von Leo C. (rapid)


Lesenswert?

Glückwunsch.

Wenn jetzt noch die "<" vom linken zum rechten Rand wandern...

Leider habe ich gerade Hardwareprobleme. Daher komme ich vorerst nicht 
zum Testen.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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:
1
Name        Sequence        Action
2
-----------------------------------------------------------------------
3
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.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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/

von Leo C. (rapid)


Lesenswert?

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:
1
 irectory of disk A:                                         
2
 -README.0    8Q.PAS       ACT.MAC      AVRCLOCK.MAC AVRCLOCK.PRN AVRCPM.LIB
statt
1
directory of disk A:                                         
2
 -README.0    8Q.PAS       ACT.MAC      AVRCLOCK.MAC AVRCLOCK.PRN AVRCPM.LIB

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?

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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?

von Leo C. (rapid)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Fehler behoben, war ein Bug in der ESC[K Sequenz.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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?

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

@Leo C.

Ab der Version 3.1 scheint in der CFGACPM.LIB

cr equ  13
lf equ  10

verloren gegangen zu sein.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Jens (Gast)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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:
1
Count: n = 49152
2
1 DRAM Wait
3
                Cycles  Time    /n      /c      
4
                 (c)    [ms]    [µs]   [ns]    [MHz]
5
-------------------------------------------------------------
6
ex  (sp),hl     19       231    4,700   247,4   4,043
7
ld  l,c          4        82    1,668   417,1   2.398
8
nop              4        66    1,343   335,7   2,979
9
inc e            4       128    2,604   651,0   1,536
10
inc a            4        99    2,014   503,5   1,986
11
inc hl           6        76    1,546   257,7   3,880
12
push/pop hl  (11+10)/2   152    3,092   294,5   3,395
13
                         151    3,072   292,6   3,418
14
pop hl          10       173    3,520   352,0   2,841
15
-------------------------------------------------------------
16
0 Wait states
17
18
ex  (sp),hl     19       223    4,537   238,8   4,188
19
nop              4        63    1,282   320,4   3,121
20
                                1,302   325,5   3,072
21
ld  l,c          4        79    1,61    402     2,49
22
ex  af,af'       4        94    1,91    478     2,09
23
ld  a,2          7        63    2,56    366     2,73
24
call/ret     (17+10)/3   116    7,08    262     3,81
25
ldi             16       126    5,13    320     3,12
26
ldi (macro)     16       104    4,23    264     3.78
27
28
Count (n) 32:
29
ldir           16/21    6977            208     4,79
30
ldir (macro)   16/21    5010            149     6,70

von Jens (Gast)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Jens (Gast)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Lesenswert?

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

von Marcel A. (dl1ekm)


Lesenswert?

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

von Marcel A. (dl1ekm)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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 !
[7] Beitrag "Re: CP/M auf ATmega88"
[8] Beitrag "Re: CP/M auf ATmega88"

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

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=9
http://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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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"

von Jens (Gast)


Lesenswert?

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.

von Marcel A. (dl1ekm)


Angehängte Dateien:

Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Marcel A. (dl1ekm)


Lesenswert?

Ja danke - habe ich inzwischen auch gelesen und mein post editiert :-)
Wer lesen kann .... jaja... :-)

von Marcel A. (dl1ekm)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Benjamin K. (benjamin92)


Lesenswert?

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?

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Theoretisch ja.

von Benjamin K. (benjamin92)


Lesenswert?

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

von Marcel A. (dl1ekm)


Lesenswert?

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

von Benjamin K. (benjamin92)


Lesenswert?

Bei mir funktioniert TeraTerm ganz gut :)

von Empfehler (Gast)


Lesenswert?


von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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
;

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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"

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Jens (Gast)



Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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"

von Marcel A. (dl1ekm)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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.

von Leo C. (rapid)


Lesenswert?

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"

von Jens (Gast)


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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.

von Jens (Gast)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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.

von Jens (Gast)


Lesenswert?

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:
1
CPM on an AVR, v3.2 r216 Test
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
mmcInit 
6
mmcCMD: 00 00000000 .. 95 CMDRes: 01 
7
mmcCMD: 08 000001AA .. 87 CMDRes: 01 
8
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 40000000 .. 01 CMDRes: 01 
9
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 40000000 .. 01 CMDRes: 00 
10
mmcCMD: 3A 00000000 .. 01 CMDRes: 00 
11
 CT: 04 InitRes: 00 
12
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:
1
> diskutil partitiondisk /dev/diskX 1 MBRFormat "MS-DOS FAT16" "CPM-DISK" 1GB
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:
1
ATmega128 memory use summary [bytes]:
2
Segment   Begin    End      Code   Data   Used    Size   Use%
3
---------------------------------------------------------------
4
[.cseg] 0x000000 0x01f800  15046   1570  16616  131072  12.7%
5
[.dseg] 0x000100 0x000656      0   1366   1366    4096  33.3%
6
[.eseg] 0x000000 0x000000      0      0      0    4096   0.0%
Kann ich cseg irgendwie verkleinern? Der Flash-Vorgang dauert jedesmal 
ewig (gefühlt).

Viele Grüße
Jens

von Leo C. (rapid)


Lesenswert?

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.

von Jens (Gast)


Lesenswert?

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:
1
ATmega128 memory use summary [bytes]:
2
Segment   Begin    End      Code   Data   Used    Size   Use%
3
---------------------------------------------------------------
4
[.cseg] 0x000000 0x004010  14732   1066  15798  131072  12.1%
5
[.dseg] 0x000100 0x000656      0   1366   1366    4096  33.3%
6
[.eseg] 0x000000 0x000000      0      0      0    4096   0.0%
Danke.
1
A>t b
2
3
Timer running. Elapsed: 005.021s.
4
A>tloop
5
6
Timer running. Elapsed: 001.342s.
Gibt es noch einen erweiterten Benchmark?

Viele Grüße
Jens

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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.c
http://wiretap.area.com/Gopher/Library/Techdoc/Bench/dhryst.txt
http://www.netlib.org/performance/html/dhrystone.data.col0.html
http://www.ecrostech.com/Other/Resources/Dhrystone.htm

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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
5
 -----      -----      ----     ----- -----   --- -----------------
6
 Commodore  64         6510      1.00    19    34 C64 ROM ,C Power 2.9 trim,
7
 Apple      IIe        65C02     1.02    37    37 DOS 3.3,Aztec CII v1.05i ,
8
 Home Brew             Z80       4.00    53    53 CPM-80 ,Hisoft C++  ,
9
 Commodore  128        8502      2.00    43    68 C128 ROM ,C Power 128  trim,
10
 Home Brew             Z80       2.50    91    91 CPM-80 2.2,Aztec CII 1.05g ,
11
*Net Brew   AVRCPM     Z80emul  ~3.     100   108 CPM-80 2.2,Aztec CII 1.06d
12
 Cromemco   Z2         Z80       4.00   127   127 Cromix 11.26,ccc  ,
13
 NCR        Decision M 8088      4.77   166   166 MS-DOS 2.11,Lattice 2.14 small,
14
*Net Brew   AVRCPM     Z80emul  ~3.     172   172 CPM-80 2.2,HI-TECH C V3.09
15
 Home Brew             8086      8.00   197   203 iRMX-86 V6,Intel C-86 2.0 large,??
16
 NCR        PC4        8088      0.00   212   212 MS-DOS 2.11,Lattice 2.14 small,

von Jens (Gast)


Lesenswert?

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

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

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

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

> A>8q
>
> Eight Queens. Running 2 iterations ...
> Timer running. Elapsed: 007.669s.
Hui. Ich musste mir erstmal 'ne Bedienungsanleitung für TP3 besorgen:
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

von Leo C. (rapid)


Lesenswert?

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

Beitrag "Re: CP/M auf ATmega88"

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

Hi!

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

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

Wer den Code per copy&paste direkt ins Zielsystem bringen will, kann 
dafür sehr gut screen verwenden. Dazu muß man in screen die 
folgenden Befehle eingeben:
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

von Marcel A. (dl1ekm)


Lesenswert?

Hallo zusammen,

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

Ansonsten schon mal frohes Fest und guten Rutsch!

Marcel

von Jens (Gast)


Lesenswert?

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

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

Viele Grüße
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Jens schrieb:
> Aber 38400 bps gingen dann ohne erkennbare Aussetzer.

Konntest du einen Fehler eingrenzen?

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

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

Viele Grüße
Jens

von Marcel A. (dl1ekm)


Lesenswert?

Hallo Jens,

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

Ich brutzel das nachher mal rein und berichte :-)

Danke und Gruß
Marcel

von Marcel A. (dl1ekm)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Jens schrieb:
> Ich häng mal meine Version hier an.

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

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

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

von Jens (Gast)


Lesenswert?

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

> - wofür ist der "TV-Ausgang" genau?
Dort habe ich mir debug-Ausgaben hingeschickt:
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

von Jens (Gast)


Lesenswert?

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

Viele Grüße
Jens

von Marcel A. (dl1ekm)


Lesenswert?

So, hier mal die ersten Ergebnisse.

Zunächst konnte ich das SPIN nicht compilieren. Das liegt wahrscheinlich 
am QuellCode - Jens arbeitet in ASCII und Joe in UniCode...
Im Editor vom Propeller (bei mir unter Windoof):
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

von Marcel A. (dl1ekm)


Lesenswert?

Jens schrieb:
> Marcel A. schrieb:
>> - in der VT100 sehe ich immer noch viele IFs... ?
> Da mußt Du noch ein Stück runterscrollen.
> An der PS/2-Verarbeitung habe ich nichts geändert (hoffentlich).
>
>> - wofür ist der "TV-Ausgang" genau?
> Dort habe ich mir debug-Ausgaben hingeschickt:
>
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

von Jens (Gast)


Lesenswert?

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

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

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

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

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

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

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

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

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

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

Viele Grüße,
Jens

von Marcel A. (dl1ekm)


Lesenswert?

Ja prima.

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

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

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

Marcel, vielen Dank für's Testen!

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

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

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

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

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

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

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

Ich wünsche allen einen
Guten Rutsch!
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Ich wünsche allen ein gesundes neues jahr!

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

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



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

von Marcel A. (dl1ekm)


Lesenswert?

So,

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

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

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

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

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

Danke!



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

von Andreas G. (dd2ag)


Lesenswert?

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

Gruß,

Andreas

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

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

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

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

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

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

Schönen Abend!
Joe


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

von Marcel A. (dl1ekm)


Lesenswert?

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

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

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

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

Marcel A. schrieb:
> Wo liegen denn die AVR Dateien?

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

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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

Viele Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Marcel A. (dl1ekm)


Lesenswert?

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

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

Gruß
Marcel

von Leo C. (rapid)


Lesenswert?

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

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

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

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

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

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


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

von Marcel A. (dl1ekm)


Lesenswert?

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


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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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


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

Ist wohl korrekt, steht so in der config.asm

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

Das wird wohl die beste Lösung sein.

von Leo C. (rapid)


Lesenswert?

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

Nicht ganz.

> Im ZIP steht 221...

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

Hier die letzten Änderungen, die aller in dem geposteten Zip-File sind:
1
 r221 | leo | 2013-11-16 14:14:02 +0100 (Sa, 16. Nov 2013) | 1 Zeile
2
Geänderte Pfade:
3
   D /avrcpm/trunk/avr/adc.asm
4
5
* fixed previous commit
6
------------------------------------------------------------------------
7
r220 | leo | 2013-11-16 14:03:47 +0100 (Sa, 16. Nov 2013) | 6 Zeilen
8
Geänderte Pfade:
9
   A /avrcpm/trunk/avr/adc.asm
10
   M /avrcpm/trunk/avr/config.inc
11
   M /avrcpm/trunk/avr/i2c.asm
12
   M /avrcpm/trunk/avr/init.asm
13
   M /avrcpm/trunk/avr/svnrev.inc
14
   M /avrcpm/trunk/avr/sw-uart.asm
15
   M /avrcpm/trunk/avr/timer.asm
16
   M /avrcpm/trunk/avr/utils.asm
17
   M /avrcpm/trunk/avr/virt_ports.asm
18
19
* I2C driver enhancements:
20
  - Doesn't hang on bus errors (Misbehaving slave).
21
  - Returns meaningful status codes.
22
  - Returns number of bytes actually transmitted/received.
23
  - config option 'I2C_STATE_DEBUG'
24
* 'MEMDUMP_DEBUG'
25
------------------------------------------------------------------------
26
r219 | leo | 2013-05-09 12:43:53 +0200 (Do, 09. Mai 2013) | 1 Zeile
27
Geänderte Pfade:
28
   A /avrcpm/tags/3.2.1 (von /avrcpm/trunk:218)
29
30
Tag for Version 3.2.1 (IPL.MAC bugfix)
31
------------------------------------------------------------------------
32
r218 | leo | 2013-05-09 12:40:18 +0200 (Do, 09. Mai 2013) | 3 Zeilen
33
Geänderte Pfade:
34
   M /avrcpm/trunk/cpm/IPL.MAC
35
36
* cpm/IPL.MAC
37
  - local definition for cr/lf
38
  - use port 1 (UARTDR) instead of port 2 (deprecated) for console output.
39
------------------------------------------------------------------------
40
r217 | leo | 2013-05-01 20:57:11 +0200 (Mi, 01. Mai 2013) | 1 Zeile
41
Geänderte Pfade:
42
   A /avrcpm/tags/3.2 (von /avrcpm/trunk:216)
43
44
Tag for Version 3.2
45
------------------------------------------------------------------------
46
r216 | leo | 2013-05-01 20:47:41 +0200 (Mi, 01. Mai 2013) | 6 Zeilen
47
Geänderte Pfade:
48
   M /avrcpm/trunk/avr/Makefile
49
   M /avrcpm/trunk/avr/Z80int-jmp.asm
50
   M /avrcpm/trunk/avr/avrcpm.asm
51
   M /avrcpm/trunk/avr/config.inc
52
   M /avrcpm/trunk/avr/dsk_fat16.asm
53
   M /avrcpm/trunk/avr/dsk_fsys.asm
54
   M /avrcpm/trunk/avr/dsk_mgr.asm
55
   M /avrcpm/trunk/avr/init.asm
56
   M /avrcpm/trunk/avr/macros.inc
57
   M /avrcpm/trunk/avr/svnrev.inc
58
   M /avrcpm/trunk/avr/utils.asm
59
   M /avrcpm/trunk/avr/virt_ports.asm
60
   M /avrcpm/trunk/cpm/BIOS.MAC
61
   M /avrcpm/trunk/cpm/CFGACPM.LIB
62
63
* cpm/BIOS.MAC
64
  - conin/const: Use function 'uartstat' (port 3) instead of 'constat' (port 0). constat will be removed soon.
65
* avr/virt_ports.asm
66
  - Mark 'constat' as deprecated.
67
* avr/*
68
  - More lds/sts --> ldd/std changes.
69
------------------------------------------------------------------------

von Leo C. (rapid)


Lesenswert?

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

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

Seit heute wirkt der Wunsch aber. Danke Joe.


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

Auch wenn die Frage inzwischen erledigt ist.
Mit TINST.COM kann man nachsehen, wie das Terminal configuriert ist.
Das hatte ich gestern gemacht, aber nicht mehr geschafft, das Ergebnis 
abzuschicken.
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)  
19
START HIGHLIGHTING command:   <ESC> [ 1 m   (27 91 49 109)  
20
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.

von Marcel A. (dl1ekm)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

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

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

: Bearbeitet durch User
von Marcel A. (dl1ekm)


Lesenswert?

Joe G. schrieb:
> Das Terminialprogramm hat doch 40 Zeilen.

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

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


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

von Marcel A. (dl1ekm)


Lesenswert?

Guten Morgen zusammen,

so, hier die Ergebnisse meiner Tests.

Versionen:
AVRCPM "221"
VGA: Rev 85

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

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

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

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

Gruß
Marcel

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

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

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

von Jens (Gast)


Lesenswert?

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

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

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

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

Joe G. schrieb:
> @Jens
> Ich habe nun mal deinen Code getestet. die Sequenz ESC[J (Bildschirm
> löschen) ist fehlerhaft.
Inwiefern?
Es gibt einen Parameter für ESC[J:
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=88

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

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

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

Viele Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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


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

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

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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

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

von Marcel A. (dl1ekm)


Lesenswert?

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

von Marcel A. (dl1ekm)


Lesenswert?

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

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


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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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


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

Das schau im mir mal an.

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

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

von Leo C. (rapid)


Lesenswert?

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

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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

VT100-Terminal

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

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

Die Auswahl erfolgt in der VGA_1024.spin

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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Marcel A. (dl1ekm)


Lesenswert?

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

von Jens (Gast)


Lesenswert?

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

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

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

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

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

Viele Grüße
Jens

von Leo C. (rapid)


Lesenswert?

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

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

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

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

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

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

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

von Jens (Gast)


Lesenswert?

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

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

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

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

Viele Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Es gibt nun eine neue VT100 Variante.

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

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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

CP/M Duino

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

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

von Marcel A. (dl1ekm)


Lesenswert?

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

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Leo (Gast)


Lesenswert?

Hallo Joe.

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

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

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

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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Leo,

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

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

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

: Bearbeitet durch User
von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

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

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

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

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

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

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

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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

Ach. ;-)

> 4. Bootvorgang über AVR

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

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

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

> 5. AVR initialisiert Soft I2C mit RTC

RTC ist im STM32 bereits eingebaut.

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

Ist (noch) nicht minimal. ;)

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

Ach, dazu wollte ich ja auch noch was schreiben.

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

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

Noch ein paar Worte zu meiner STM32–Variante.

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

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

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

von Svenska (Gast)


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

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

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

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

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

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

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

von Guido L. (guidol1970)


Angehängte Dateien:

Lesenswert?

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

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

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

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

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

: Bearbeitet durch User
von Marcel A. (dl1ekm)


Lesenswert?

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

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

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

Gruß
Marcel

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

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

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

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

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

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

: Bearbeitet durch User
von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

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


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

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

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


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

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

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

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Ein Layout gibt es nun auch.

von Svenska (Gast)


Lesenswert?

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

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

von Jens (Gast)


Lesenswert?

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

Außerdem ist man dann gleich wieder an dem Punkt, den Propeller 
einzusparen, weil der STM genug Power für VGA hat:
http://www.youtube.com/watch?v=HkUUJ-rOUPg

Viele Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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

von Matthias I. (matze5)


Lesenswert?

Ist die AVR Variante mittlerweile voll 8080 Kombatibel?

Gruss Matthias

von Leo C. (rapid)


Lesenswert?

> Ist die AVR Variante mittlerweile voll 8080 Kombatibel?

Was fehlt denn, oder was hat gefehlt?

von Matthias I. (matze5)


Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

> und ich wuerde gern mit dem Asembler drauf rumspielen :)

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

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

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


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

von Matthias I. (matze5)


Lesenswert?

Ach seh schon jetzt ist es der ATMega168 :)

Intressant waere noch eine zweite Serielle Schnittstelle.

von Leo C. (rapid)


Lesenswert?

> Ach seh schon jetzt ist es der ATMega168 :)

Eher nicht. ;)

> Intressant waere noch eine zweite Serielle Schnittstelle.


Klar.

von Matthias I. (matze5)


Lesenswert?

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

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


Gruss Matze

: Bearbeitet durch User
von Leo C. (rapid)


Lesenswert?

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

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

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

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

von Drako (Gast)


Lesenswert?

Ebay-Artikel Nr. 281464531861

...

von Leo C. (rapid)


Lesenswert?

Drako schrieb:
> ...

2 Fragen:

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

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

von Leo C. (rapid)


Lesenswert?

> 2 Fragen:

2 Tage - keine Antwort.

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

von Marcel A. (dl1ekm)


Angehängte Dateien:

Lesenswert?

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

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

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

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

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

Danke und Gruß
Marcel

von Leo C. (rapid)


Lesenswert?

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

$ make flash

make program benutzt kein Mensch (dachte ich)

> Ist das schlimm?

Unschön, aber nicht schlimm.

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

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

von Leo C. (rapid)


Lesenswert?

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


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

Man kann stattdessen make übrigens auch so starten:
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"?

: Bearbeitet durch User
von Leo C. (rapid)


Lesenswert?

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

@Marcel, falls Du Dir den Download sparen willst:
1
; - Setup Ports
2
3
;  ldi   temp,(1<<PUD)    ;disable pullups
4
;  outm8  P_PUD,temp
5
  out   PORTD,_255    ;all pins high (enables pullup on input ports)
6
  out   PORTB,_255
7
  out   PORTC,_255
8
  out   DDRD,_255    ; PD all outputs
9
#if I2C_SUPPORT
10
  ldi  temp,~((1<<SCL)|(1<<SDA))
11
  out  DDRC,temp 
12
#endif
13
#if DRAM_8BIT
14
  ldi  temp,~(1<<RXD)
15
  out  DDRB,temp
16
#endif

von Marcel A. (dl1ekm)


Lesenswert?

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

Jetzt kommen nur noch diese warnings:
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

von Leo C. (rapid)


Lesenswert?

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

Im Makefile steht zwar:
AWK = gawk

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

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

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

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

von Jens (Gast)


Lesenswert?

Hallo Forum!

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

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

Jens

von Leo C. (rapid)


Lesenswert?

Der hier müßte passen:
1
 # SIMH AltairZ80 Harddisk
2
diskdef simhd
3
  seclen 128
4
  tracks 2048
5
  sectrk 32
6
  blocksize 4096
7
  maxdir 1024
8
  skew 0
9
  boottrk 6
10
  os p2dos
11
end

von Jens (Gast)


Lesenswert?

Super. Das funktioniert.

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

Zum Beispiel bei ZEXTEST 
(http://www.jens-mueller.org/jkcemu/zextest.html)
1
62k cp/m vers 2.2
2
3
A>d:
4
D>dir
5
D: ZEXALL   SRC : ZEXDOC   SRC : ZEXALL   COM : ZEXDOC   COM
6
D>zexdoc
7
8
S       A =E5 BC =00F8 DE =F1FF HL =F8F8 SP=E3A9 PC=019E       76 29 2C
9
        a'=00 bc'=0000 de'=0000 hl'=0000 IX=0000 IY=0000 I=00       CPU halted!

Oder einem Editor:
1
>dir *.com
2
C: CFGDATE  COM : DATE     COM : EDIT     COM : RECEIVE  COM
3
C: SETDATE  COM : SETDISK  COM : SETEDIT  COM : STAT     COM
4
C: TDATE    COM
5
C>edit
6
7
S       A =E5 BC =00FD DE =DDFF HL =E5FD SP=E406 PC=018C       76 65 6E
8
 Z  NC  a'=00 bc'=0000 de'=0000 hl'=E37E IX=E3F3 IY=9BE1 I=00       CPU halted!

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

Viele Grüße,
Jens

von Leo C. (rapid)


Lesenswert?

> "CPU halted!"-Fehler.

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

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

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

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

Kannst Du mal die kompletten Boot-Meldungen posten?

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

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

von Leo C. (rapid)


Lesenswert?

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

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

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

Leider sieht man hier nicht die exakte Größe.
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.
1
$ fsck.cpm -f simhd -n zextest.simhd 
2
Phase 1: check extent fields
3
Phase 2: check extent connectivity
4
zextest.simhd: 6/1024 files (0.0% non-contigous), 42/2048 blocks
5
$ fsck.cpm -f myz80 -n zextest.simhd 
6
Phase 1: check extent fields
7
Phase 2: check extent connectivity
8
zextest.simhd: 6/1024 files (0.0% non-contigous), 36/2048 blocks
9
$

> 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]:
1
$ ./makeimage /dev/null myz80.img $(expr 128 \* 65536 + 256)
2
$ ./makeimage /dev/null simhd.img $(expr 128 \* 65536)
3
4
Danach mit cpmtools bespielen. Format 'myz80' bzw. 'simhd'.
5
6
# MYZ80 hard drive (only works with libdsk, because it has a 256-byte header)
7
diskdef myz80
8
  seclen 1024
9
  tracks 64
10
  sectrk 128
11
  blocksize 4096
12
  maxdir 1024
13
  skew 1
14
  boottrk 0
15
  os 3
16
end
17
18
# SIMH AltairZ80 Harddisk
19
diskdef simhd
20
  seclen 128
21
  tracks 2048
22
  sectrk 32
23
  blocksize 4096
24
  maxdir 1024
25
  skew 0
26
  boottrk 6
27
  os 2.2
28
end


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

von Jens (Gast)


Lesenswert?

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

Ich habe gedacht, das die 8 MB-Images automatisch simhd-Images sind:
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

von Jens (Gast)


Lesenswert?

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

Jetzt klappt's auch mit der Nachbarin (äh, dem Image :-)
1
62k cp/m vers 2.2
2
3
A>c:
4
C>dir
5
C: ZEXALL   COM : ZEXALL   SRC : ZEXDOC   COM : ZEXDOC   SRC
6
C>zexdoc
7
Z80 instruction exerciser
8
<adc,sbc> hl,<bc,de,hl,sp>....

Danke,
Jens


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