Z180-Stamp Modul

[Joe G. (feinmechaniker)]

Ich wünsche allen Mitlesern ein gesundes neues Jahr!

Das Z180-Stamp Projekt ist in erster Linie ein Lebensgefühl.  Einige der 
hier Beteiligten sind mit dem Z80 und CP/M bzw. U880 und SCP :-) groß 
geworden.  Es macht einfach immer noch Freude sich mit dieser Technik zu 
beschäftigen. Vielleicht vergleichbar wie das Basteln mit Röhren.
Für heutige Steuerungsaufgaben gibt es sicher geeignetere Prozessoren 
als den Z180. Prinzipiell könnte man den Z180 ohne weiteren Prozessor 
(hier der AVR) betreiben. Es gibt auch hier im Forum einige Beiträge die 
sich damit beschäftigen. In dem hier verfolgten Aufbau übernimmt der AVR 
die Funktion eines EPROM’s der Kommunikation mit dem Host, der Erzeugung 
des Takt, der Ansteuerung der SD-Card  usw. Letztlich könnte das 
Z180-Stamp Modul mit einer ECB-Busanpassung mit vorhandener Z80 Hardware 
kombiniert werden.

[Christian J. (Gast)]

Joe G. schrieb:

> Das Z180-Stamp Projekt ist in erster Linie ein Lebensgefühl.  Einige der
> hier Beteiligten sind mit dem Z80 und CP/M bzw. U880 und SCP :-) groß
> geworden.  Es macht einfach immer noch Freude sich mit dieser Technik zu
> beschäftigen

Hmm.....also "EPROM mit Fenster" cool finden, grüne Schrift auf 
schwarzen Monochrom Monitor, IC's, die man ohne Pinzette und Lupe löten 
kann, Chips die warm werden und damit zeigen dass sie "arbeiten". Einen 
Timer als Chip, eine UART als Chip dazu, RAM was man in die Hand nehmen 
kann. Eine CPU die man verstehen kann, ohne E-Technik studiert zu haben. 
Etwas zu bauen was man heute als 1-Chip Lösung für 2€ kaufen kann, aber 
ohne "Aha" Erlebnis.

Ok...

[Marcel A. (dl1ekm)]

Bei mir ist es eher umgekehrt.
Ich bin mit PCs (Turbo Pascal) 1986 groß geworden, habe also die 
C64/Apple/... Zeit nicht miterlebt bzw. das waren unerreichbare Dinge, 
als ich klein war.
Das hole ich heute nach, eben weil es darum geht, Dinge auch zu 
verstehen (wovon ich meilenweit entfernt bin - :-)) und nicht nur zu 
"usen".
Das ist ja auch das große Credo der Herren vom WDR ComputerClub gewesen: 
Zumindest die Dinge dahinter zu verstehen.

Von daher war ich baff erstaunt, als ich letztens mit meinem Kleinen die 
Sendung mit der Maus schaute und dort ein Taschenrechner erklärt wurde 
und dafür an einer großen Wand mit Lampen, Kugeln und Taster das 
Binärsystem inkl. Rechenoperationen erklärt wurde.

Aber nun genug der Nostalgie - Hochachtung vor den Leistungen der 
Hauptaktiven hier - und ich warne schon mal vor bzgl. dummer fragen, 
denn ich fange dann doch "bald" mal an.

[Harald N. (haraldn)]

Noch eine Frage bzgl. meiner nicht funktionierenden Z180 Stamp:
Muss ich den Pins, die nicht mit dem AVR verbunden sind (wie zb HALT, 
NMI, WAIT, INT0, INT1, INT2 und andere), definierte Pegel anlegen?

[Joe G. (feinmechaniker)]

Harald Nagy schrieb:
> Muss ich den Pins, die nicht mit dem AVR verbunden sind (wie zb HALT,
> NMI, WAIT, INT0, INT1, INT2 und andere), definierte Pegel anlegen?

Nein, die liegen bereits auf definiertem Pegel. Du solltest zunächst mal 
schauen ob am Z180 ein Takt anliegt und ob sie die CPU im Resetzustand 
befindet. Um den Speicher zu beschreiben muss die CPU dann in den 
DMA-Mode versetzt werden. Bei korrekter Funktion wechselt dann die CPU 
in diesen Mode und schaltet die Adress- Daten und Steuerleitungen 
hochohmig. Leider kann ich das genaue Taktdiagramm dazu derzeit nicht 
raussuchen, da ich gerade im Urlaub bin. Nächste Woche bin ich wieder 
verfügbar.

[Harald N. (haraldn)]

So, ich hab's heute nochmal versucht und mit meinen eher rudimentären 
Mitteln die Signale gecheckt. An der seriellen Schnittstelle sehe ich 
trotzdem nichts...
Zusammenfassung:
- die AVR Stamp läuft
- zur Z180 Stamp:
* an PHI liegt ein ca 9 MHz Takt - passt
* an M1 und MREQ huschen Signale - passt
* ZRESET ist high - passt
* an den Adress- und Datenleitungen ist Verkehr - passt
* an RXA und TXA passiert nix - passt nicht
* zu obigen Ergebnissen komme ich sowohl mit Quarz als auch mit CLKO

Das bedeutet für mich, dass die CPU läuft nur an der seriellen 
Schnittstelle kommt tatsächlich nix raus...

Leider muss ich die Sachen dieses Wochenende liegen lassen. Vlt ergibt 
sich ja bis Montag eine Lösung.....

[Joe G. (feinmechaniker)]

Vielleicht interessiert es ja jemanden (Source-Code von CP/M) u.a. 
DDT.ASM

http://www.computerhistory.org/atchm/early-digital-research-cpm-source-code/

[Marcel A. (dl1ekm)]

Gibt es inzwischen eigentlich schon eine Grundplatine für die 2 Stamps?

[Joe G. (feinmechaniker)]

Ja, es gibt einen Entwurf mit einer ECB-Bus Variante, einer RS232 und 
einer externen SD-Card. Alles im Euro-Format.

[Christian J. (Gast)]

Joe G. schrieb:

> Vielleicht interessiert es ja jemanden (Source-Code von CP/M) u.a.
> DDT.ASM
>
> http://www.computerhistory.org/atchm/early-digital-research-cpm-source-code/

Grad mal den CPM Source quer gelesen, auch den von Apple Dos, was ich ja 
aus der Schule noch kenne. Ich wundere mich nur wie schlecht der 
dokumeniert ist, dass die sowas als Arbeitsergebnis abliefern konnten. 
Das Aopple Zeug kann man teilweise nur als Geschmiere bezeichnen, was 
"Woz" da ablieferte.

[Leo C. (rapid)]

Joe G. schrieb:
> Harald Nagy schrieb:
>> Eine Frage: wie kann ich prüfen, ob das Z180-Board wirklich läuft?
>
> Zunächst kannst du ja mit dem Monitor einzelne Z180 Befehle in den RAM
> schreiben und auch ausführen. Außerdem wird bei Start des Monitors Leo's
> DDT in den RAM geladen und kann über die serielle Schnittstelle des Z180
> bedient werden. Dazu muß sie zusätzlich auch verdrahtet werden.
> Beitrag "Re: Z180-Stamp Modul"

Leider hatte ich vergessen einige Änderungen zu erwähnen:
Für den Z180 gibt es nun CP/M 3 kompatible Character I/O Routinen [1]. 
Der erste I/O-Kanal geht auf den AVR, der zweite auf ASCI1 (2. serielle 
Schnittstelle am Z180). Weitere Kanäle sind noch nicht realisiert. Die 
DDTZ-Console wird derzeit auf den ersten Kanal geschaltet, also auf den 
AVR. Der AVR-Monitor hat ein neues Kommando "connect" bekommen, das 
diesen Kanal auf die Serielle vom AVR verbindet.

Will man die DDTZ-Console (zusätzlich) auf ASCI1 haben, geht das z. Zt. 
nur, in dem man den Console-IN- und den Console-Out-Vector im Z180-RAM 
ändert, zB. mit dem Befehl mm. Später soll das mal über 
Environment-Variablen einstellbar sein.

Harald Nagy schrieb:
> Ich dachte,
> die Z180-Outputs werden zum AVR durchgeschleift... Wenn ich jetzt
> darüber nachdenke wirds logisch....

Werden sie auch. Jetzt.

> Beim Versuch den Speicher manuell zu beschreiben erhalte ich die
> Fehlermeldung "bus timeout".

Wahrscheinlich fehlte der Takt.

> Zusammenfassung:
> - die AVR Stamp läuft
> - zur Z180 Stamp:
> * an PHI liegt ein ca 9 MHz Takt - passt
> * an M1 und MREQ huschen Signale - passt
> * ZRESET ist high - passt
> * an den Adress- und Datenleitungen ist Verkehr - passt
> * an RXA und TXA passiert nix - passt nicht

Doch, passt. Siehe oben.

> * zu obigen Ergebnissen komme ich sowohl mit Quarz als auch mit CLKO

Geht denn "Speicher manuell zu beschreiben" jetzt? Funktionieren die 
anderen Monitor-Befehle (md, mw, mm, cp, cmp)?

Damit DDTZ läuft, muß Z180-Stamp Pin A17 (DREQ0) auf Low liegen. Falls 
er 1:1 mit der AVR-Stamp verbunden ist, geht das mit dem Befehl "pin 2 
low".


[1] https://archive.org/stream/CPM3-System_Guide#page/n61/mode/2up

[Harald N. (haraldn)]

Danke für die Hinweise! md hatte ich mal versucht und hat auch 
funktioniert. Wie gesagt der Takt liegt auch an, sonst würde doch PHI 
keinen Output geben (ich hoffe ich liege da richtig).
Connect habe ich auch mal eingegeben. In der Hoffnung, das ist der 
Befehl zum verbinden. Anscheinend liege ich da auch richtig. Allerdings 
hat sich der Monitor dann aufgehängt und reagierte nicht mehr auf 
eingaben.
Jedenfalls werde ich es morgen nochmals versuchen!
Im Fall dass alles funktionert steht als nächstes eine Schaltung für ein 
Basisboard für beide Stamps an....

[Leo C. (rapid)]

Harald Nagy schrieb:
> Connect habe ich auch mal eingegeben. In der Hoffnung, das ist der
> Befehl zum verbinden. Anscheinend liege ich da auch richtig. Allerdings
> hat sich der Monitor dann aufgehängt und reagierte nicht mehr auf
> eingaben.

Raus kommt man wieder mit "Control-^ X". Mit "Control-^ ?" bekommt man 
ein kleines Hilfe-Menu.

Allerdings bleibt der Connect-Befehl hängen, wenn DDTZ nicht läuft. 
(Hier inzwischen korrigiert)

[Harald N. (haraldn)]

@all: hat noch keiner ausser Joe und Leo mit den Stamps gespielt?

@Leo: Ich fasse zusammen: alles unverändert. Anscheinend steht im RAM 
nach dem Hochfahren irgendein Schrott?!
Die CPU läuft, der AVR kann den RAM lesen und beschreiben.
Wenn ich connect eingebe hängt sich der AVR-Monitor >>tatsächlich<< auf. 
Komme mit keiner Tastenkombination wieder auf die Kommandozeile. BTW das 
Kommando zum Abbrechen ist doch Ctrl-c? Die beiden anderen, die du 
angegeben hast, führen zu keiner Reaktion....

@Joe: Falls du noch Platinen über hast bzw. vor hast nochmal welche 
anfertigen zu lassen, könntest du mich für jeweils eine vormerken?

[Leo C. (rapid)]

Harald,
hast Du meinen letzten Beitrag nicht gelesen?

[Harald N. (haraldn)]

Doch. Worauf willst du hinaus? Dass der Debugger nicht läuft? Ja, das 
denke ich auch - aber was dagegen tun?

Das Image im Flash ist doch ok nehme ich an...

[Leo C. (rapid)]

Harald Nagy schrieb:
> BTW das
> Kommando zum Abbrechen ist doch Ctrl-c? Die beiden anderen, die du
> angegeben hast, führen zu keiner Reaktion....

Sorry, ich hatte den zweiten Satz von Dir nicht gelesen. ;-(

Ctrl-C kann natürlich nicht zum Beenden verwendet werden, da es an den 
Z180 geschickt werden muß. (CP/M Reboot, Wordstar Page Down, ...)

Jedes "Terminalprogramm" verwendet für den Übergang in einen 
Befehlsmodus andere "ESCAPE Character". Ich habe mich für Ctrl-^ 
entschieden, weil Ctrl-A (screen, minicom) genauso unpraktisch wie 
Ctrl-C ist, und andere übliche "Fluchtzeichen" auf einer deutschen 
Tastatur zu umständlich sind (Telnet: Ctrl-[ Kermit: Ctrl-\).

Also '^' (caret, das Dach) bei gedrückter Control-Taste drücken, und 
danach z.B. '?' für das Menu. Geht in der aktuellen Programmversion aber 
nur, wenn der DDTZ richtig läuft, oder als Allererstes nach dem 
'connect' eingegeben wird.

[Harald N. (haraldn)]

Danke für die Aufklärung. Aber leider funktionierts nicht.
Nach wie vor hängt sich der AVR-Monitor nach dem Eingeben von "connect" 
auf und reagiert auf keine Eingaben mehr.

[Leo C. (rapid)]

Harald Nagy schrieb:
> @Leo: Ich fasse zusammen: alles unverändert. Anscheinend steht im RAM
> nach dem Hochfahren irgendein Schrott?!

Das ist bei RAMs so üblich. Durch den AVR wird das RAM erst auf 
ausdrücklichen Wunsch des Benutzers initialisiert.

> Die CPU läuft, der AVR kann den RAM lesen und beschreiben.

Mach das mal systematisch. ZB.:

=> mw 0 76 80000
Ganzes RAM mit 0x76 (HALT) füllen.

=> md 0
Überprüfen, ob am Anfang des RAMs 0x76 steht.

=> cmp 0 1 80000
Jeweils 2 aufeinanderfolgende Bytes vergleichen. Da das ganze RAM mit 
0x76 gefüllt ist, sollt kein Fehler kommen.

=> go 0
Z180 sollte einen Halt-Befehl ausführen und stehen bleiben. Halt-Ausgang 
sollte Low sein. Wenn Du hier eine LED angeschlossen hast, sollte sie 
leuchten.

=> reset
Halt-Ausgang geht wieder auf High (LED aus).

Wenn das so funktioniert, kannst Du z.B. den Speicher kommplett mit 0 
(NOP) füllen (überprüfen). Nach einem 'go 0' führt der z180 nur NOPs 
aus, im Adressbereich von 0x000 bis 0xffff. Auf den Adressleitungen A0 
bis A15 sollte ein regelmäßiges Muster mit jeweils halbierter Frequenz 
zu sehen sein. Auf A0 bis A6 allerdings gestört durch den Refresh. A16 
bis A19 sollten dauerhaft auf low liegen.

> Wenn ich connect eingebe hängt sich der AVR-Monitor >>tatsächlich<< auf.

Wurde denn vorher der DDTZ ins RAM geladen und gestartet?
Und ist dabei DREQ0 auf low?

[Harald N. (haraldn)]

Werde die Überprüfung durchführen.

Zu meiner Vorgehensweise:
Beim booten wird ja das ram automatisch beladen. Das meinte ich mit 
hochfahren.
ich hab den autoboot unterbrochen. Dann
pin 2 low
loadf
go 0x000
connect

allerdings habe ich auch schon verschiedene abfolgen versucht. Zb auch 
a17 extern auf low

[Leo C. (rapid)]

> ich hab den autoboot unterbrochen. Dann
> pin 2 low
> loadf
> go 0x000
> connect

Gut, daß Du das mal so deutlich hingeschrieben hast. Wenn das nicht tut, 
muß noch irgendwo ein Hardware- oder Verdrahtungs-Fehler sein. Bei mir 
war z.B. ein Pin vom RAM nicht angelötet. Das war nicht mal mit Lupe zu 
erkennen.

> allerdings habe ich auch schon verschiedene abfolgen versucht. Zb auch
> a17 extern auf low

Kann man ja nachmessen.

> go 0x000

Das funktioniert nur zufällig richtig. Die Parameter bei diesen Befehlen 
sind grundsätzlich Hex. 0x muß nicht und darf nicht angegeben werden. 
Die Inputroutine ist allerdings schlampig programmiert und liest nur bis 
zum ersten ungültigen Zeichen, hier 'x'. Alles davor wird als Zahl 
gnommen, hier 0.

[Harald N. (haraldn)]

Bevor ich anfange nachzulöten, habe ich alle Verbindungen durchgemessen. 
Alles soweit ok (Beinchen zu Beinchen nicht Lötstelle zu Lötstelle).

Langsam bekomme ich den Verdacht, dass es an der Verkabelung mit 
Jumperkabeln liegt....

Der RAM wird beim vollständigen beschreiben mit zb 76 vollgeschrieben. 
Allerdings treten systematisch Fehler auf. Wenn ich die Kabel etwas 
bewege gibts zwar ein anderes aber doch ein System beim falsch 
beschriebenen RAM.

Muss ich mir nun doch erst ein Baseboard basteln... Stapeln will ich 
nicht unbedingt (ich will die Pins nicht kappen....)

[Joe G. (feinmechaniker)]

Das VT-100 Terminal Projekt ist wieder ein Schritt weiter. Ich habe dazu 
einen extra Beitrag aufgemacht.
Beitrag "VT100-Terminal (VGA+PS2)"

[Peter Z. (flexopete)]

Moin,
ich bin gerade dabei, meine AVR-Stamp zu testen.
Das board habe ich separat mit 3,3 V versorgt,
Z180-Stamp ist nicht angeschlossen.
Bootloader über ISP geflasht,
...-4.1.hex mit AVRFLASH2.1 übertragen (aus dem SVN).
(was ist denn der Unterschied zur ...-4.2.hex?)

Monitor meldet sich und lässt sich bedienen.
RTC kann ich einstellen und auslesen, aber die
SD geht nicht:

sd status 0
socket status: 01 (03 ohne Karte)

sd info 0
not initialized
command failed, result=1

sd init 0
rc=01
command failed, result=1

SD ist eine 2 GB Transend, aber auch mit 32 GB samsung
getestet, FAT und FAT32.
Ich habe den Eingang auch schon mit 330kOhm auf GND
gelegt, aber dann bekomme ich als socket status immer 03.
Die Leitungen ATMEGA zur SD habe ich durchgemessen, ok.

Jemand ne Idee?

Gruss
Peter

[Leo C. (rapid)]

> (was ist denn der Unterschied zur ...-4.2.hex?)

Kosmetik.
Details gibts hier:
http://cloudbase.mooo.com/cgit/z180-stamp/

> SD geht nicht:
>
> sd status 0
> socket status: 01 (03 ohne Karte)

Hast Du die LED1 am Kartensockel bestückt?
(Eigentlich sollte dann gar kein Unterschied zwischen Karte 
gesteckt/nicht gesteckt erkennbar sein.)

> sd info 0
> not initialized
> command failed, result=1

Der Befehl funktioniert erst nach erfolgreichem 'init'.

> sd init 0
> rc=01
> command failed, result=1

Warum init hier nicht geht, weiß ich auch nicht. Ich probier mal was...

[Harald N. (haraldn)]

Eine Frage: Denkt ihr dass bei der verwendeten Frequenz eine 
Basisplatine mit Fädeldraht verdrahtet noch funktioniert. Nachdem ich 
kein Elektrotechniker bin und meine Erfahrungen noch etwas beschränkt 
sind würde ich gerne eure Meinungen hören bevor ich loslege...

[Leo C. (rapid)]

Harald Nagy schrieb:
> Eine Frage: Denkt ihr dass bei der verwendeten Frequenz eine
> Basisplatine mit Fädeldraht verdrahtet noch funktioniert.

Bei mir funktionierts.
Den Bus und weitere Versorgungsleitungen habe ich mit 0,3mm Lackdraht 
gelötet, und den Rest (SD-Kartenhalter, serielle Schnittstellen, 
HALT-Led) mit dem ganz dünnen Fädeldraht. Für VCC der SD-Karte mußte ich 
allerdings ein LC-Filter spendieren. Sonst gabs beim Einstecken einer 
Karte Brownout-Resets. C alleine hat nicht gereicht.

[Joe G. (feinmechaniker)]

Aus meiner Sicht (Version ohne LED) läuft die Version
*stamp-monitor-hexrel-4.2-test-sd-cd.hex*
wie sie soll (siehe unten). Einzig mit der Meldung

z80_memfifo_init: 0, 7c320
z80_memfifo_init: 1, 7c21d
z80_memfifo_init: 2, 7c423
z80_memfifo_init: 3, 7c526

kann ich nichts anfangen.

=> sd status 0
Socket status: 01
=> sd init 0
rc=00
=> sd info 0
Drive size: 1984000 sectors
Erase block: 8192 sectors
Card type: 4
CSD:
    00000: 00 26 00 32 5f 59 83 c8  be fb cf ff 92 40 40 d7 
.&.2_Y.......@@.
CID:
    00000: 03 53 44 53 55 30 31 47  80 50 48 8b cb 00 96 97 
.SDSU01G.PH.....
OCR:
    00000: 80 ff 80 00                                       ....
SD Status:
    00000: 00 00 00 00 00 00 00 28  01 01 90 00 0a 05 00 00 
.......(........
    00010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
................
    00020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
................
    00030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
................
=> fatstat 0:
FAT type:                2
Bytes/Cluster:           16384
Number of FATs:          2
Root DIR entries:        512
Sectors/FAT:             242
Number of clusters:      61935
FAT start (lba):         1
DIR start (lba,cluster): 485
Data start (lba):        517
Volume name:
Volume S/N:              1234-5678

66 files, 924663 bytes.
6 folders.
990960 KB total disk space.
989120 KB available.

[Leo C. (rapid)]

Joe G. schrieb:
> Aus meiner Sicht (Version ohne LED) läuft die Version
> *stamp-monitor-hexrel-4.2-test-sd-cd.hex*
> wie sie soll (siehe unten).

Danke. Bei Harald gehts auch. Von Peter kam gerade eine Mail, daß es bei 
ihm noch nicht geht.

>Einzig mit der Meldung
>
> z80_memfifo_init: 0, 7c320
> z80_memfifo_init: 1, 7c21d
> z80_memfifo_init: 2, 7c423
> z80_memfifo_init: 3, 7c526
>
> kann ich nichts anfangen.

Macht nichts. ;-)
Das sind Debug-Meldungen, die besagen, daß im Z180-RAM FIFOs für den 
Datenaustausch angelegt wurden. 2 davon sind für die  DDTZ-Console, zu 
der Du Dich mit 'connect' verbinden kannst.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Das sind Debug-Meldungen, die besagen, daß im Z180-RAM FIFOs für den
> Datenaustausch angelegt wurden.

Ok, danke. Aber connect geht nicht mehr :-( Das System bleibt irgendwo 
hängen.

[Harald N. (haraldn)]

@Leo: Deine Mail ist erst jetzt angekommen!?

Hier mein Ergebnis zum Test der Firmware 
*stamp-monitor-hexrel-4.2-test-sd-cd.hex*:

> Hi!
>
> Da es bei mir gerade zeitmässig eher eng zugeht, hab ich nur mal schnell
> die neue Firmware geflasht und die SD/FAT-Befehle durchprobiert:
> funktioniert alles
> Ich habe die Bestückung mit LED (wie auch im GIT angegeben).
> Die LED funktioniert jetzt auch.
> Ich bin mir nicht sicher, aber wenn ich
> mich recht erinnere, hat die LED bei der vorigen Version 4.2 nicht
> funktioniert.

Kommentar von Leo: Eigentlich müßte sie trotzdem brennen, und vielleicht 
garnicht richtig ausgehen. Der Pin wird bei der Version zwischen den 
Zugriffen auf Input geschaltet, um eine eingesteckte Karte zu erkennen. 
Allerdings kann das mit Led nicht richtig funktionieren. Ist aber im 
Moment nicht wichtig.

Anmerkung: Ich habe nochmal versuchsweise die 4.2 Firmware geflasht um 
die LED-Sache zu überprüfen. Mit dieser Version leuchtet die LED nie.

[Harald N. (haraldn)]

Zum Thema Basisplatine: Habt ihr diese in der Art gebaut, wie hier im 
Thread einmal gepostet? Gibt es da evtl ein Schaltplan-Update?
Sollte ich demnächst mal Zeit haben will ich mir nämlich eine solche 
zusammenbasteln um auch endlich die Z180-Stamp zum Laufen zu bringen...

[Leo C. (rapid)]

Joe G. schrieb:
> Ok, danke. Aber connect geht nicht mehr :-( Das System bleibt irgendwo
> hängen.

Ging das denn schonmal bei Dir?
Hier funktionierts. Egal welche Programmversion.

Harald Nagy schrieb:
> Anmerkung: Ich habe nochmal versuchsweise die 4.2 Firmware geflasht um
> die LED-Sache zu überprüfen. Mit dieser Version leuchtet die LED nie.

Auch nicht bei erfolgreichen Zugriffen auf die SD-Karte?
Das kann eigentlich garnicht sein. Wenn die LED richtig angeschlossen 
ist, muß sie leuchten, wenn CS low geht. Und ohne CS auf low ist kein 
Datentransfer zu oder von der Karte möglich.
Ich habe es jetzt auch nochmal mit beiden Versionen ausprobiert. Ohne 
SD-Karte blitzt die LED bei 'sd init 0' kurz auf.

> Zum Thema Basisplatine: Habt ihr diese in der Art gebaut, wie hier im
> Thread einmal gepostet? Gibt es da evtl ein Schaltplan-Update?

Im Anhang ist mein Schaltplan. Nicht unbedingt zur Nachahmung empfohlen. 
Ich habe nur das drauf gebaut, was ich gerade zum Testen brauche. Die 
Jumper für die Taktumschaltung braucht außer mir wahrscheinlich kein 
Mensch.

[Harald N. (haraldn)]

Leo C. schrieb:
> Harald Nagy schrieb:
>> Anmerkung: Ich habe nochmal versuchsweise die 4.2 Firmware geflasht um
>> die LED-Sache zu überprüfen. Mit dieser Version leuchtet die LED nie.
>
> Auch nicht bei erfolgreichen Zugriffen auf die SD-Karte?

Nein definitiv nicht. Keine Ahnung warum aber es ist so. Im Grund aber 
egal, Hauptsache die SD-Karte funktioniert.
Ist ja nicht die einzige unbeantwortete Frage im moment für mich....

[Harald N. (haraldn)]

Frustration macht sich breit... Die Probleme mit dem RAM hab ich immer 
noch.

Ich habe mir jetzt ein Baseboard gelötet (nach dem Schaltplan von Leo, 
ohne SD und Clock-Umschaltung). Funktioniert soweit.

Aber der RAM macht Probleme. Der Test mit mw/md/cmp ist nie erfolgreich. 
cmp bricht aber immer an unterschiedlichen Stellen ab. Manchmal kommt 
auch bei cmp ein Fehler und wenn ich mir die Speicherstelle mit md 
ansehe, passt egtl alles??? Weiterhin ist mir aufgefallen, dass md mal 
schneller mal langsamer (eine Zeile pro Sekunde ca) ist???
Ich habe bereits in meiner Verzweiflung alle Pins am AVR und RAM 
nachgelötet  und alle Verbindungen Pin-zu-Pin durchgemessen aber 
unverändertes Verhalten.

Die Fehler sind dieselben egal ob CLKO oder Quarz, ob 
USB-Stromversorgung oder Einspeisung von 5V-extern....

Mir sind die Ideen ausgegangen und langsam verlässt mich leider auch die 
Lust...

Jemand noch Ideen was ich überprüfen und ausprobieren kann?

[Joe G. (feinmechaniker)]

Harald Nagy schrieb:
> Jemand noch Ideen was ich überprüfen und ausprobieren kann?

Beide Platinen in Huckepackbauweise testen.

[Harald N. (haraldn)]

Joe G. schrieb:
> Harald Nagy schrieb:
>> Jemand noch Ideen was ich überprüfen und ausprobieren kann?
>
> Beide Platinen in Huckepackbauweise testen.

Dann muss ich die Stiftleisten stutzen was ich egtl vermeiden wollte....

[Marcel A. (dl1ekm)]

Hallo zusammen,

ist ja ziemlich ruhig hier geworden ("an die eigene Nase fass") - wie 
ist denn der Stand?

Gibt es etwas neues zum Thema Basis-Board?

Beste Grüße
Marcel

[Marcel A. (dl1ekm)]

Hallo zusammen,
ich habe am Wochenende nun beide Stamps zusammengelötet, jetzt bin ich 
also "startklar".
Am nächsten WE würde ich mir nun gerne das Thema Software vornehmen. 
Beim Review des Threads und der Anleitung habe ich noch so ein paar 
Fragen:

- Wie sieht es denn mit einem Base-Board aus? Bisher habe ich nur den 
Schaltplan von Leo und den „Lochraster-Entwurf/Schaltplan“ von Leo 
gesehen. Ich kann da in Eagle (free) nichts machen, müsste dann auf 
KiCad umsteigen...

- Apropos Baseboard: Ich hadere mit den aus meiner Sicht Widersprüchen: 
In Leos Verdrahtung werden beide seriellen Schnittstellen des Z180 auf 
externe Anschlüsse geführt. In der Beschreibung heißt es aber, dass SER1 
auf den AVR verbunden ist und darüber auch die DDT-Kommunikation 
funktioniert….?

- Welche fuses muss ich einstellen, wenn die den hexmon 4.2 für einen 
ersten ohne bootloader direkt in avr flashen möchte?

- Da ich noch keinerlei Erfahrnung mit Bootloadern gemacht habe: Weiter 
oben ist ein bootloader.hex drin, kann ich den nehmen? Und wie brenne 
ich den an die richtige Stelle? Aber hier muss ich vermutlich noch mal 
genauer die Anleitung von Peter Dannegger lesen (mikrocontroller.net war 
gestern Abend down).

Vielen Dank!

Gruß Marcel

[Leo C. (rapid)]

Marcel A. schrieb:
> - Apropos Baseboard: Ich hadere mit den aus meiner Sicht Widersprüchen:
> In Leos Verdrahtung werden beide seriellen Schnittstellen des Z180 auf
> externe Anschlüsse geführt. In der Beschreibung heißt es aber, dass SER1
> auf den AVR verbunden ist

Wo steht das?

> und darüber auch die DDT-Kommunikation funktioniert….?

Z180 und AVR können über Bereiche im SRAM kommunizieren. Darüber läuft 
z.Zt. auch die DDTZ-Console. Prinzipiell kann diese auf eine der 
seriellen Schnittstellen des Z180 umgelegt werden. Die Software für die 
Umschaltung ist aber noch nicht fertig.

> - Welche fuses muss ich einstellen, wenn die den hexmon 4.2 für einen
> ersten ohne bootloader direkt in avr flashen möchte?

Du kannst Die von hier nehmen 
(Beitrag "Re: Z180-Stamp Modul")
                 Low High Extended
----------------------------------
Mit Bootloader   AF  D6   F5
Ohne Bootloader  AF  D1   F5

Der Unterschied ist hier die BOOTRST-Fuse. (Und die BOOTSZ-Fuses, aber 
die sind bei nicht gebrannter BOOTRST-Fuse relativ egal.)
Hier kann man mit den Fuses experimentieren:
http://www.engbedded.com/fusecalc/

(Bin mir nicht sicher, ob für die Extended Fuses in der PDF-Doku ein 
Tippfehler ist, oder ob Joe die Brown-Out-Detection disabled lassen 
möchte. Letzteres ist nicht empfehlenswert, da dann der EEPROM-Inhalt 
zerstört werden kann.)


> - Da ich noch keinerlei Erfahrnung mit Bootloadern gemacht habe: Weiter
> oben ist ein bootloader.hex drin, kann ich den nehmen?

Ja.

> Und wie brenne
> ich den an die richtige Stelle?

Wie jede andere Datei auch: einfach flashen.
Der Programmer kümmert sich schon um die richtige Stelle, da die 
Intel-Hex-Datei ja Lade-Adressen enthält.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> (Bin mir nicht sicher, ob für die Extended Fuses in der PDF-Doku ein
> Tippfehler ist, oder ob Joe die Brown-Out-Detection disabled lassen
> möchte.

War tatsächlich ein Tippfehler 5F macht keinen Sinn, ist in der Doku 
geändert.

Nachtrag:
Das Basisboard gibt es in EAGLE, es gab bisher nur noch keinen Bedarf 
hier. Die Fertigung 100x160 wird auch etwas mehr kosten als die 
Billigteile aus Fernost.

[Peter Z. (flexopete)]

Moin Joe,

ich würde Bedarf für ein Basisboard anmelden.

Gruss
Peter

[Marcel A. (dl1ekm)]

Danke Leo, hab's kapiert mit der Console.

Basisboard ist tatsächlich ein Problem in China, aber es gibt bei 
iteastudio usw. bis 10x15 (fehlt 1cm...). Da war auch noch ein anderer 
recht günstiger dabei. Könnte ich raussuchnm, elecrow war es nicht :-)

Ich wäre daher auch mit einem Board dabei.

[Marcel A. (dl1ekm)]

So, der AVR Stamp läuft!

Sogar auf Anhieb. Ich hatte nur gedacht, ich hätte den SD-Reader 
verkehrt herum eingebaut, da ich nicht verstanden habe, wie man die 
SD-Karte hineinbekommt und hatte ihn wieder ausgelötet. Dabei ist mir 
aufgefallen, dass man sie (entgegen denen, die ich sonst verwende) 
"einlegen" muss...

Als RC beim sd init erhalte ich allerdings "00" und nicht "08" wie in 
der Doku - ansonsten sieht der SD-Zugriff aber ok aus.

RTC geht auch.

### Reset reason(s): External.
### Setting I2C clock Frequency to 100000 Hz.

ATMEGA1281+Z8S180 Stamp Monitor

### main_loop entered: bootdelay=3

### main_loop: bootcmd="reset; loadf; go ${startaddr}"
Hit any key to stop autoboot:  0
## CPU now in reset state.
Loading Z180 memory...
   From: 0x00000 to: 0x001B9    (  442 bytes)
   From: 0x001C2 to: 0x02D9E    (11229 bytes)
   From: 0x02DAE to: 0x03194    (  999 bytes)
## Starting application at 0x0000 ...
=> sd init 0
rc=00
=> sd info 0
Drive size: 7716864 sectors
Erase block: 8192 sectors
Card type: 12
CSD:
    00000: 40 0e 00 32 5b 59 00 00  1d 6f 7f 80 0a 40 00 a1 @..2[Y...o...@..
CID:
    00000: 02 54 4d 53 41 30 34 47  13 38 ad fb 58 00 e1 31 .TMSA04G.8..X..1
OCR:
    00000: c0 ff 80 00                                       ....
SD Status:
    00000: 00 00 00 00 02 00 00 00  02 02 90 01 00 aa 00 00 ................
    00010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
    00020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
    00030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
=> fatstat 0:
FAT type:                3
Bytes/Cluster:           32768
Number of FATs:          2
Root DIR entries:        0
Sectors/FAT:             941
Number of clusters:      120320
FAT start (lba):         14502
DIR start (lba,cluster): 2
Data start (lba):        16384
Volume name:             INTENSO
Volume S/N:              4BB6-F93A

0 files, 0 bytes.
0 folders.
3850240 KB total disk space.
3850208 KB available.
=> fatls 0:
   0 File(s),         0 bytes total
   0 Dir(s),    3850208K bytes free
=> date 032416492015.00
Tue Mar 24 16:49:00 2015
=> date
Tue Mar 24 16:49:05 2015
=>

Jetzt muss ich mal schauen, wie ich den Z180 angebunden bekomme... Auf 
so eine wilde Lochraster-Party habe ich eigentlich keine Lust. Mal 
sehen...

Noch eine andere Frage: Warum haben eigentlich all diese Projekte 
18,432MHz?

Gruß
Marcel

[Leo C. (rapid)]

Marcel A. schrieb:
> So, der AVR Stamp läuft!

Glückwunsch!

> Als RC beim sd init erhalte ich allerdings "00" und nicht "08" wie in
> der Doku - ansonsten sieht der SD-Zugriff aber ok aus.

Anmerkung dazu hier, erster Absatz:
Beitrag "Re: Z180-Stamp Modul"

> Jetzt muss ich mal schauen, wie ich den Z180 angebunden bekomme... Auf
> so eine wilde Lochraster-Party habe ich eigentlich keine Lust. Mal
> sehen...

Das ist wohl Geschmacksache. Ich kann an Lochraster nichts wildes 
finden. Stapeln wäre noch eine Möglichkeit. Wenn Du die Stapelbuchsen 
eingelötest hättest...

> Noch eine andere Frage: Warum haben eigentlich all diese Projekte
> 18,432MHz?

Was sind denn "alle diese Projekte"?
18,432MHz ist die höchste Baudratenfrequenz unter 20MHz. Der Z8SZ180 ist 
bei 3,3V bis maximal 20MHz spezifiziert. Der AVR ist dann schon deutlich 
übertaktet, läuft aber erfahrungsgemäß noch einwandfrei.

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> So, der AVR Stamp läuft!

Gratulation!

Marcel A. schrieb:
> Noch eine andere Frage: Warum haben eigentlich all diese Projekte
> 18,432MHz?

Es gibt hier im Forum einen schönen Artikel zur Historie:
http://www.mikrocontroller.net/articles/Baudratenquarz


Marcel A. schrieb:
> Jetzt muss ich mal schauen, wie ich den Z180 angebunden bekomme...

So: Beitrag "Re: Z180-Stamp Modul"

[Marcel A. (dl1ekm)]

Ich hadere gerade mit der von Leo gezeigten Einbindung des Linux 
bootloaders in minicom.

Zunächst erzeugt mir das make-file die Datei "bootloader" - im screen 
ist aber "fboot" zu lesen - vermutlich wurde das umbenannt?

Dann kann ich im screenshot (wahrscheinlich) nicht alle 
Parameter-Aufrufe sehen... Leo, kannst du mal den ganzen Aufruf posten, 
falls da noch was kommt?

Ich verstehe das mit den Parametern so nämlich nicht.
Laut MiniCom-Doku gibt es hier

'%l' is expanded to the complete filename of the dial out-device, 
'%f' is expanded to the serial port file descriptor and 
'%b' is expanded to the current serial port speed.

In der Bootloader-Doku steht:

bootloader [-d /dev/ttyS0] [-b 9600] -[v|p] file.hex
-d /dev/ttynn       serial device, (use e.g. /dev/serial/by-id/usb-FTDI* for FT232)
-b nn               Baudrate

Im Screenshop steht aber:

fboot -d %l -b %...

Müsste dann da nicht

fboot -d %f -b %b -p %l

stehen?

[Leo C. (rapid)]

Bin unterwegs und kann gerade nicht nachschauen, was bei mir wirklich 
konfiguriert ist. Ich glaube aber schon, daß ich eine funktionierende 
Konfig gepostet hatte.

[Leo C. (rapid)]

Hallo Marcel,

hatte Dein Problem ganz vergessen. Falls es noch nicht erledigt ist:

> Zunächst erzeugt mir das make-file die Datei "bootloader" - im screen
> ist aber "fboot" zu lesen - vermutlich wurde das umbenannt?

ja

> Im Screenshop steht aber:fboot -d %l -b %...
> Müsste dann da nichtfboot -d %f -b %b -p %l
> stehen?

Der volle Eintrag (~/.minirc.dfl) lautet bei mir:

pu pprog10          /usr/local/bin/fboot -d %l -b %b -p

[Leo C. (rapid)]

Falls es jemand interessiert. ;-)
Ich habe mir jetzt ein Z80-Stamp gebaut. Den Entwurf hatte ich schon vor 
einem halben Jahr gemacht und auch mit dem Bau angefangen. Leider 
fehlten mir ein paar Widerstände, und so war das Ding erst mal wieder in 
der Versenkung verschwunden.

Die Platine habe ich mit CPU, RAM (max 128K), SIO und CTC bestückt, um 
der Z180-Stamp möglichst nahe zu kommen. ;) Takt kommt von einem der 
freien AVR-Ports, da man CLKO für die 4MHz CPU natürlich nicht nehmen 
kann. 2 CTC Kanäle erzeugen den Takt für die seriellen Schnittstellen. 
Der Input für diese Kanäle kann auch von AVR-Port geliefert werden.

Das RAM ist z.Zt nur mit 8K bestückt, da ich keinen größeren Baustein im 
DIL-Gehäuse da habe. Das muß natürlich bald geändert werden, da in 8K 
noch nicht einmal mein schöner DDTZ paßt.

[Holm T. (Gast)]

Wo haste den den Schicken CTC ausgeraben.. sehe ich das erste mal in 
Keramik..

Gruß,

HOlm

[Leo C. (rapid)]

> Wo haste den den Schicken CTC ausgeraben.. sehe ich das erste mal in
> Keramik..

Das hättest Du mich mal vor gut 30 Jahren fragen müssen. Da habe ich das 
sicher noch gewußt...
Aktuell stammt sie aus meinem Schatzkästchen, in dem jetzt aber nur noch 
die TR1402 in Keramik sind. Eine weitere Keramik-CTC habe ich noch auf 
meiner alten I/O-Karte. In dem leeren Steckplatz war die SIO, die ich 
jetzt für die Stamp-Karte geklaut habe. An dem Keramik-8255 war übrigens 
meine 8-Zoll-Floppystation angeschlossen (je ein Port für Daten-IN, 
-Out, und Steuerung).

[Marcel A. (dl1ekm)]

Ich bin nun auch auf den bootloader umgeschwenkt.

Obwohl das HEX des bootloaders nur 2K groß ist, hat er 128k geflashed. N 
denne, muss wohl.

Mit UpdateBootloader unter Windoof war ich dann nicht erfolgreich, da 
sich das Programm über eine falsche Prüfsumme von Leos Test-hex (4.2) 
beschwert und ich daher kein Flash starten konnte.
AVRFlash klappte dagegen problemlos.

Unter Linux habe ich bootloader eingerichtet, auch mit 
minicom-Verbindung. Hier muss ich aber gefühlte 10x den Reset-Knopf an 
der AVR-Stamp drücken, bis der bootloader das merkt und den upload 
startet. Scheint wohl ein timing-Problem zu sein - manchmal finden sie 
sich auch gar nicht.

Die SW von Leo sieht ja wirklich sehr professionell aus, wenn mal mal 
schaut, was help so auswirft. Leider sagt mir das meiste noch nichts. 
Was macht man z.B. mit den fat-Befehlen? Den Z180-Speicher in eine Datei 
schreiben usw.?

Ich habe mir jetzt erst mal Fädeldraht und Stift bestellt, damit ich 
eine Basis-Platine "stricken" kann. Gibts denn auch irgendwo den 
aktuellen Stand der ECB-Platine?

Gruß
Marcel

[Leo C. (rapid)]

Marcel A. schrieb:
> Unter Linux habe ich bootloader eingerichtet, auch mit
> minicom-Verbindung. Hier muss ich aber gefühlte 10x den Reset-Knopf an
> der AVR-Stamp drücken, bis der bootloader das merkt und den upload
> startet. Scheint wohl ein timing-Problem zu sein - manchmal finden sie
> sich auch gar nicht.

Das Problem hatte ich auch, ist seit neuestem komischer Weise weg. Keine 
Ahnung was sich geändert hat. Es geht aber gut, wenn man Reset gedrückt 
hält, wenn man den bootloader startet. Aber wg. des Problems hatte ich 
mal eine Testversion des Monitors mit Bootloader-Support gemacht. Die 
sollte inzwischen in Deinem Posteingang sein.

> schaut, was help so auswirft. Leider sagt mir das meiste noch nichts.

Die meisten Befehle haben eine eigene Hilfe, wenn man "help 'befehl'" 
eingibt. Oft kommen nur die Parameter, aber manchmal auch mehr.

> Was macht man z.B. mit den fat-Befehlen? Den Z180-Speicher in eine Datei
> schreiben usw.?

Genau. Gerade die fat-Befehle haben ausführliche Hilfe.

[Leo C. (rapid)]

Hier mal ein kleines Update des Monitors. Neue Befehle:

mdc        - memory display cyclic
mwc        - memory write cyclic
mloop      - infinite loop on address range
mloopw     - infinite write loop on address range
mtest      - simple RAM read/write test
loadi      - load intel hex file

Mtest ist nicht ganz so 'simple'. Es versucht immerhin heraus zu 
bekommen, ob Schlüsse oder Unterbrechungen auf Datenbus und/oder 
Adressbus vorhanden sind.

Loadi lädt Intel-Hex über die Consolenschnittstelle. Das habe ich 
eingebaut, weil bei meiner Z80-CPU-Karte das ganze System mit 5V läuft, 
und ich deshalb die SD-Karten nicht nehmen kann.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Hier mal ein kleines Update des Monitors. Neue Befehle:

Danke, läuft bei mir! Ich habe die Doku gleich um mdc und mtest 
erweitert.

Marcel A. schrieb:
> Gibts denn auch irgendwo den aktuellen Stand der ECB-Platine?

Ich würde sie gerne nochmals "anfassen". Mit Leos "LoadI" könnte man 
beide Stamp's komplett mit 5V (SD auf Z180 Stamp darf nicht gesteckt 
sein!) laufen lassen. Damit hätte man einen 5V ECB-Bus. Vielleicht ist 
ein Levelshifter auf der ECB-Platine für die externe SD-Card ganz 
nützlich.

[Marcel A. (dl1ekm)]

Bei mir gehts auch - wobei er nach dem FBOOT-Upload in einer 
Endlos-Bootschleife hing (zählte nur noch bis 2 runter) - ein Reset 
half.

Zur Platine: Klingt vielversprechend!

Schönen Abend noch

[Leo C. (rapid)]

Marcel A. schrieb:
> Bei mir gehts auch -

Damit ist Dein Auto-Bootloader-Feature wieder weg...

> wobei er nach dem FBOOT-Upload in einer
> Endlos-Bootschleife hing (zählte nur noch bis 2 runter) - ein Reset
> half.

Das hatte ich vor kurzem auch. Liegt, bzw. lag, sicher an besagtem 
Feature. Der Watchdog wird wahrscheinlich nicht abgeschaltet.

[Leo C. (rapid)]

Joe G. schrieb:
> beide Stamp's komplett mit 5V (SD auf Z180 Stamp darf nicht gesteckt
> sein!) laufen lassen. Damit hätte man einen 5V ECB-Bus. Vielleicht ist
> ein Levelshifter auf der ECB-Platine für die externe SD-Card ganz
> nützlich.

Levelshifter nur für den SD-Slot, statt für den ganzen ECB-Bus, ist 
natürlich weniger Aufwand. Wenn man für den Bus Treiber braucht, 
relativiert sich die Einsparung aber wieder. Allerdings muß auf der 
AVR-Stamp ein Pin des FTDI-Chips umverdrahtet werden.

[Ulrich P. (uprinz)]

Ich habe noch verschiedenen eZ80Acclaim Module herum liegen und mich 
schon gefragt, was ich damit noch anfangen soll. Kann man mit diesen 
Modulen auch noch mitspielen?
http://www.zilog.com/index.php?option=com_product&task=dev_tool_detail&DevToolKit=eZ80F920200ZCOG

[Marcel A. (dl1ekm)]

So, ich fang jetzt mal mit Lötfädeltechnik an :-)

BTW - habt ihr auch vor, für das System ein CPM-Bios zu entwickeln?

[Leo C. (rapid)]

Marcel A. schrieb:
> BTW - habt ihr auch vor, für das System ein CPM-Bios zu entwickeln?

Wer braucht schon CP/M? Wie wärs denn mit BASIC? ;-)

[Leo C. (rapid)]

Sorry, der im letzten Beitrag gepostete Anhang enthält ein übeflüssiges 
PDF, das das Archiv völlig unnötig aufbläht. Wenn ein Moderator den 
Anhang löscht, stelle ich den Rest nochmal neu ein (ca 97K).

Edit: hängt schon dran. ;-(

[Leo C. (rapid)]

Wer's braucht ;) hier ist der Basicinterpreter schon drin.

[Leo C. (rapid)]

Leo C. schrieb:
> Marcel A. schrieb:
>> Unter Linux habe ich bootloader eingerichtet, auch mit
>> minicom-Verbindung. Hier muss ich aber gefühlte 10x den Reset-Knopf an
>> der AVR-Stamp drücken, bis der bootloader das merkt und den upload
>> startet. Scheint wohl ein timing-Problem zu sein - manchmal finden sie
>> sich auch gar nicht.
>
> Das Problem hatte ich auch, ist seit neuestem komischer Weise weg. Keine
> Ahnung was sich geändert hat.

Inzwischen ist die Ahnung wieder gekommen. Ich hatte vor gar nicht 
langer Zeit den Linux bootloader gepatched:

diff Linux/bootloader.c
diff --git a/Linux/bootloader.c b/Linux/bootloader.c
index 3f2225e..3e4af52 100644
--- a/Linux/bootloader.c
+++ b/Linux/bootloader.c
@@ -742,7 +742,8 @@ int connect_device ( int fd,
 
     // first 0x0d for autobaud, then password, then 0xff
     // for answer in one-line mode
-    sprintf (passtring, "%c%s%c", 0x0d, password, 0xff);
+//    sprintf (passtring, "%c%s%c", 0x0d, password, 0xff);
+    sprintf (passtring, "%s%c", password, 0xff);
 
     printf("Waiting for device...  ");

Damit funktionierts einwandfrei.

[Joe G. (feinmechaniker)]

Bei der Nutzung von AVRFlash unter Win muß man auch den Resetknopf 
seeeehr lange drücken :-(

[Marcel A. (dl1ekm)]

zu Bootloader patchen:

Da ich mit git/diff noch nie etwas gemacht habe: Wenn ich das richtig 
sehe, muss ich im Quellcode (habe die Stelle gefunden) nur %c%s%c" gegen 
"%s%c" im sprintf-Aufruf ändern und neu übersetzten?

[Leo C. (rapid)]

Fast. Der zugehörige Parameter muß natürlich auch weg.

-    sprintf (passtring, "%c%s%c", 0x0d, password, 0xff);
+    sprintf (passtring, "%s%c",         password, 0xff);

Das 0x0d soll nicht ausgegeben werden.

[Marcel A. (dl1ekm)]

Leo C. schrieb:
> Wer's braucht ;) hier ist der Basicinterpreter schon drin.

Da ich mit der Verdrahtung noch nicht fertig bin: Wie funktioniert das 
denn mit dem Basic? Wird das automatisch ins RAM kopiert und gestartet? 
Wie bekommt man eine Konsole?

[Leo C. (rapid)]

Marcel A. schrieb:
> Da ich mit der Verdrahtung noch nicht fertig bin: Wie funktioniert das
> denn mit dem Basic?

Ohne die Verdrahtung funktionierts gar nicht. ;-)

> Wird das automatisch ins RAM kopiert und gestartet?
> Wie bekommt man eine Konsole?

In der Befehlsliste gibts einen zusätzlichen Befehl "loadbasic" oder so.
Der Befehl läd den Interpreter aus dem Flash ins RAM. Danach ein "go 0", 
und auf einer der Schnittstellen sollte der Basic-Prompt erscheinen. Ich 
habe gerade eine Programmversion ohne Basic geladen. Deshalb kann ich 
nicht nachschauen. Aber eigentlich müßte es so sein:

Es gibt auf Adresse 0003h im Z180-RAM ein "IOBYTE", über das sich die 
Zuordnung der Console zu einer Schnittstelle einstellen läßt.

IOBYTE
  0     Verbindung zu AVR
  1     ASCI0 mit 9600 Baud, z.Zt. nicht einstellbar
  2     ASCI1 mit 57600 Baud, dito

Die Baudraten gelten für 9,216 MHz Takt, bei 18,432 MHz das Doppelte.
Default für das IOBYTE ist 2, also die zweite Serielle Schnittstelle am 
Z180. Ändern kann man es z.B. mit dem Befehl "mw 3 1", um den Wert auf 1 
zu setzen.

Aber eigentlich war der Basic-Interpreter eher als Scherz gedacht. Wenn 
man das richtig machen will, dann mit ertwas modernerem, mit 
vernünftigem Editor.

[Marcel A. (dl1ekm)]

Hier die Bilder von meinem ersten Lötfädel-Projekt.
Und was soll ich sagen - es läuft!
- Die Tests mit Speicher schreiben, vergleichen und auf HALT laufen 
lassen klappen.
- mtest gibt keine Fehler aus.
- Mit DDT kann ich mich verbinden - Hilfe kommt und es passiert auch 
was...

Ein tolles Teil - VIELEN DANK an Joe und Leo!

Tja - was nun?

Zwei Fragenbereiche hätte ich jetzt:
A) Wie geht es weiter?
- Leo baut ja geniale Dinge -> aber wo gehen die hin?
- Bleibt es bei dem Z180-Stamp mit RAM und "AVR-Hilfsumgebung" oder...?
- Plant ihr noch ein mapping der AVR-Funktionen (i2c, sd, uhr...) auf 
den Z180 (IOREQ 0 - 255)?
- Die Frage war ja letztens ernst gemeint - ist ein CP/M geplant?

B) Nun stellen sich mir doch einige Fragen zur Technik, die sich mir so 
direkt nicht erschließen (wahrscheinlich habe ich nur zu wenig gelesen):
- Wie ist das mit der Taktversorgung des Z180?
  - im Moment verwende ich den onboard 18MHz Quarz
  - Über CLK0 des AVR würde vermutlich der Takt vom AVR zum Z180 EXTAL 
kommen? Ich habe das zwar verdrahtet - aber wie steuert man das? Und 
wieso nur halber Takt? Laut ZILOG müsste dann auch XTAL leer bleiben, 
wenn über EXTAL der Takt kommt.
  - wie würde man einen Einzelschrittmodus realisieren?
  - Was ist mit der Taktquelle aus PB5 des AVR? Wofür ist die?
- Wie ist die RAM-Belegung des Z180 nach dem Boot? DDT ab 0000? Wo wäre 
Platz für eigene Programme?
- Warum muss DSEL0 (über PIN A17 des AVR)  auf low gelegt werden, damit 
DDT läuft? DSEL kenne ich vom normalen Z80 nicht... was macht der? Muss 
man das immer machen, damit der Z180 Programme ausführt?

Sicher ziemliche Anfängerfragen die belegen, dass ich nur die Idee von 
einer Ahnung habe - aber ich arbeite dran :-)

Gruß
Marcel

[Leo C. (rapid)]

Marcel A. schrieb:
> Hier die Bilder von meinem ersten Lötfädel-Projekt.
> Und was soll ich sagen - es läuft!

Glückwunsch!

> - Bleibt es bei dem Z180-Stamp mit RAM und "AVR-Hilfsumgebung" oder...?

oder was?

> - Plant ihr noch ein mapping der AVR-Funktionen (i2c, sd, uhr...) auf
> den Z180 (IOREQ 0 - 255)?

Natürlich wird die AVR-Peripherie für den Z180 zugänglich gemacht.

> - Die Frage war ja letztens ernst gemeint - ist ein CP/M geplant?

Meine Antwort war auch nicht nur unernst gemeint. Trotzdem wird es von 
mir demnächst ein CP/M 3 geben.


> - Wie ist das mit der Taktversorgung des Z180?
>   - im Moment verwende ich den onboard 18MHz Quarz
>   - Über CLK0 des AVR würde vermutlich der Takt vom AVR zum Z180 EXTAL
> kommen?

Genau.

> Ich habe das zwar verdrahtet - aber wie steuert man das?

Für diese Konfiguration gibts nichts zu steuern. Auf der Z180-Karte muß 
JP1 entsprechend gesetzt sein, und am AVR muß die CKOUT-Fuse gebrannt 
werden, damit er den Takt (18,432MHz) auf pin PE7 ausgibt.

> Und wieso nur halber Takt?

Maximal halben Takt bekommt man an den Timer-Ausgängen des AVR (PG5, 
PB4-PB7). Dafür braucht man keine Fuse zu brennen, und man kann auch 
andere Taktteiler einstellen. Der Z180 kann den Takt intern wieder auf 
18,432MHz verdoppeln.

> Laut ZILOG müsste dann auch XTAL leer bleiben, wenn über EXTAL der Takt kommt.

Ja.

>   - wie würde man einen Einzelschrittmodus realisieren?

Ohne Zusatzhardware wohl am Einfachsten, in dem man den Takt für den 
Z180 durch Pin-toggeln am AVR erzeugt. Der AVR könnte dann nach jedem 
(halben) Takt alle Z180-Leitungen einlesen, und entsprechend aufbereitet 
ausgeben.

Hardwarezusatz für Einzelschritt hatte Joe mal gepostet:
Beitrag "Re: Z180-Stamp Modul"

>   - Was ist mit der Taktquelle aus PB5 des AVR? Wofür ist die?

Kann man nehmen, muß man aber nicht.
Das ist OC1A und von den zugänglichen AVR-Timerausgängen der 
flexibelste. Deshalb habe ich den für meine Taktexperimente mit Z180 und 
Z80 genommen.

> - Wie ist die RAM-Belegung des Z180 nach dem Boot?

Es gibt keine.

> DDT ab 0000?

Wenn man ihn läd, ja. Er belegt die untersten 12K und am oberen Ende des 
log. Adressbereichs nochmal ein halbes K.

> Wo wäre Platz für eigene Programme?

In den restlichen 499,5K. ;) Wobei Dein Programm auch ab 0 starten kann, 
wenn Du einen RST-Vector für den Debugger frei hälst. MMU machts 
möglich.

> - Warum muss DSEL0 (über PIN A17 des AVR)  auf low gelegt werden, damit
> DDT läuft?

Was Du meinst, ist DREQ0, nicht DSEL.

Inzwischen nicht mehr. Dieser Pin geht auf DREQ0 des Z180. Die Init für 
meinen DDTZ hatte früher den DMA0-Kanal benutzt, um den kompletten 
Speicher zu löschen. Der dazu verwendete DMA-Mode geht nur, wenn der 
Request-Eingang auf low (aktiv) liegt.

> DSEL kenne ich vom normalen Z80 nicht... was macht der?

Grundlätzlich hilft bei solchen Fragen ein Blick ins Datenblatt.
Das Du DSEL und DREQ0 verwechselt hast, habe allerdings erst später 
gemerkt, nachdem ich den folgenden Text schon geschrieben hatte.

Was es macht ist leicht im Schaltplan zu sehen. DESEL liegt 
normalerweise über einen Pullup auf High. Wird es über die Steckerleiste 
aktiviert (low), blockiert es das CE-Signal am RAM-Chip. D.h. DESEL 
DE-SELektiert das RAM auf der Z180-Karte. Das kann für Erweiterungen 
nützlich sein, z.B. ECB-Karten, die ROMs, Memory-mapped-I/O oder 
Video-RAM im unteren Addressbereich einblenden.

> Muss man das immer machen, damit der Z180 Programme ausführt?

[Leo C. (rapid)]

CP/M Plus (CP/M 3) für Z180-Stamp

Hier ist mal was für Wagemutige zum ausprobieren.
- Es sind Bugs enthalten. Darunter ein gravierender, der Daten von
  Disk an die falsche Stelle im RAM kopiert. Es fehlt noch ein Test,
  ob ein  Datenblock die Grenze zwischen Common- und gebanktem RAM
  überschneidet.

- Console geht auf ASCI0 (9600 Baud). Kann mit DEVICE unter CP/M3 auf
  ASCI1 (57600) Baud umgeschaltet werden. Baudrate-Einstellung geht
  noch nicht.

- Baudraten gelten für 9,216 MHz Takt. Ansonsten umrechenen.

- Console über AVR geht nicht (Bug). Da diese Schnittstelle also nicht
  nutzbar ist, habe ich die Debugmeldungen des Disk-Treibers drin
  gelassen.

- Uhr geht noch nicht.

- Das CP/M kennt 4 Laufwerke (A-D). Alle Diskimages müssen derzeit im
  simh altairZ80 Harddiskformat sein[1]. Das sind die Imagedateien, die
  exakt 8388608 Bytes groß sind.

So bringt man es zum Laufen:

- AVR mit dem Hexfile aus dem Archiv updaten.

- Die beiden anderen Dateien (cpm3.sys und cpm3test.dsk) auf eine
  SD-Karte kopieren.

- Nach Belieben weitere Images im gleichen Format auf die Karte
  kopieren.

- Für die Zuordnung Image<->Laufwerk eine Environmentvariable setzen:
  => setenv dsk0 1:/cpm3test.dsk

- Für bis zu 3 weitere Images analog:
  => setenv dsk1 dev:/pfad/zum/image/imagename

- Für die cpm3.sys Datei kann eine Variable gesetzt werden,
  muß aber nicht:
  => setenv cpm3_file 1:/cpm3.sys

- Wenn die Karte in den Micro-SD-Slot auf der AVR-Stamp gesteckt wird,
  in obigen Beispielen "1:" gegen "0:" tauschen.

- Optional Einstellungen speichern:
  => saveenv

- An die erste Serielle (ASCI0) ein Terminal mit 9600 Baud anschließen.

- Spätestens jetzt die Karte einstecken.

- cpm3.sys Laden:
  => loadcpm

- wenn die Datei nicht gefunden wird:
  => loadcpm dev:/pfad/zu/cpm3.sys

- Wenn das Laden erfolgreich war, steht in der Variablen "startaddress"
  die CP/M coldboot Einprung-Adresse. (Sollte E400 sein).

- Nix wie hin:
  => go {startaddress}

- oder
  => go e400

- Wenn auf dem Terminal der CP/M Prompt erscheint:
  => Viel Spaß  (mit den Bugs, und diese bitte melden)

- Wenn nicht:
  => Auch melden. Dann halt ohne Spaß.


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

[Marcel A. (dl1ekm)]

Nach einem kleinen Vertipper gings:

CP/M Version 3.0, Z180-Stamp BIOS
A>dir
A: BDOS3    SPR : BNKBDOS3 SPR : CCP      COM : COPYSYS  COM : CPMLDR   REL 
A: DATE     COM : DEVICE   COM : DIR      COM : DUMP     COM : ED       COM 
A: ERASE    COM : GENCOM   COM : GENCPM   COM : GET      COM : HELP     COM 
A: HELP     HLP : HEXCOM   COM : PATCH    COM : PIP      COM : PUT      COM 
A: README       : RENAME   COM : RESBDOS3 SPR : SAVE     COM : SET      COM 
A: SETDEF   COM : SHOW     COM : SID      COM : SUBMIT   COM : TYPE     COM 
A>

Turbo-Pascal läuft (erster Test):

Logged drive: B

Work file: 
Main file: 

Edit     Compile  Run   Save

eXecute  Dir      Quit  compiler Options

Text:     0 bytes (8118-8118)
Free: 22765 bytes (8119-DA06)

>
Dir mask: 
READ     ME  : TINST    COM : TINST    DTA : TINST    MSG : TURBO    COM
TURBO    MSG : TURBO    OVR : CMDLIN   PAS : LISTER   PAS : MC-MOD00 INC
MC-MOD01 INC : MC-MOD02 INC : MC-MOD03 INC : MC-MOD04 INC : MC-MOD05 INC
MC       HLP : MC       PAS : MCDEMO   MCS : MC       COM : MC-MOD03 COM
HELLO    PAS 

Bytes Remaining On B: 4184k
>

[Marcel A. (dl1ekm)]

Mit den Tastatur-Codes ist das ja wieder so eine typische CP/M-Sache...

Auf der "Shell" funktioniert bei mir z.B. BS, auch die CTRL-Codes gehen 
weitgehend wie im CPM3-Handbuch beschrieben.
Unter TP sieht das wieder anders aus - aber das muss man eh anpassen.

[Leo C. (rapid)]

Marcel,

falls Du minicom verwendest könnte es auch damit zu tun haben. In der 
Terminaleinstellungen kann man einstellen, ob Backspace BS oder DEL 
senden soll. Es wird aber nicht nur die Backspace-Taste (^H) 
eingestellt, sondern auch die DEL-Taste.

[Joe G. (feinmechaniker)]

Wie ist diese Fehlermeldung zu interpretieren?

## CPU now in reset state.
z80_memfifo_init: 0, 0
z80_memfifo_init: 1, 0
z80_memfifo_init: 2, 0
z80_memfifo_init: 3, 0
Loading Z180 memory...
   From: 0x00000 to: 0x00003    (    4 bytes)
   From: 0x00008 to: 0x0000A    (    3 bytes)
   From: 0x00010 to: 0x00012    (    3 bytes)
   From: 0x00018 to: 0x0001A    (    3 bytes)
   From: 0x00020 to: 0x00022    (    3 bytes)
   From: 0x00028 to: 0x0002A    (    3 bytes)
   From: 0x00030 to: 0x00032    (    3 bytes)
   From: 0x00038 to: 0x0003A    (    3 bytes)
   From: 0x00040 to: 0x00043    (    4 bytes)
   From: 0x00050 to: 0x02C24    (11221 bytes)
   From: 0x02C34 to: 0x02E7F    (  588 bytes)
   From: 0x02EA3 to: 0x02EA3    (    1 bytes)
   From: 0x02EC7 to: 0x02EC7    (    1 bytes)
   From: 0x02EEB to: 0x02EEB    (    1 bytes)
Command failed, result=-1

Der nachfolgende Vorgang läuft erstmal erfolgreich :-)

=> loadcpm
Loading: '0:/cpm3.sys'...

 BNKBIOS3 SPR  E400  0800
 BNKBIOS3 SPR  A700  1900
 RESBDOS3 SPR  DE00  0600
 BNKBDOS3 SPR  7900  2E00

 55K TPA
Loaded: Resident: 0xDE00-0xEBFF, Banked: 0x7900-0xBFFF
=> go e400
## Starting application at 0xe400 ...

[Leo C. (rapid)]

> Wie ist diese Fehlermeldung zu interpretieren?

Alles etwas uneinheitlich, ich weiß. Nichts davon ist im eigentlichen 
Sinne eine Fehlermeldung.

> ## CPU now in reset state.

"##[#..]" am Zeilenanfang war/ist für Debugmeldungen gedacht. Diese 
Zeile ist aber eigentlich eine normale Rückmeldung des davor 
ausgeführten Befehls. Kann man weglassen, aber dann sieht man nicht 
mehr, ob der Befehl etwas gemacht hat.

> z80_memfifo_init: 0, 0
> z80_memfifo_init: 1, 0
> z80_memfifo_init: 2, 0
> z80_memfifo_init: 3, 0

Debug

> Loading Z180 memory...
>    From: 0x00000 to: 0x00003    (    4 bytes)
>    From: 0x00008 to: 0x0000A    (    3 bytes)
>    From: 0x00010 to: 0x00012    (    3 bytes)
>    From: 0x00018 to: 0x0001A    (    3 bytes)
>    From: 0x00020 to: 0x00022    (    3 bytes)
>    From: 0x00028 to: 0x0002A    (    3 bytes)
>    From: 0x00030 to: 0x00032    (    3 bytes)
>    From: 0x00038 to: 0x0003A    (    3 bytes)
>    From: 0x00040 to: 0x00043    (    4 bytes)
>    From: 0x00050 to: 0x02C24    (11221 bytes)
>    From: 0x02C34 to: 0x02E7F    (  588 bytes)
>    From: 0x02EA3 to: 0x02EA3    (    1 bytes)
>    From: 0x02EC7 to: 0x02EC7    (    1 bytes)
>    From: 0x02EEB to: 0x02EEB    (    1 bytes)

Info. Zeigt an, was geladen wurde. Hier durch die vielen kleinen Lücken 
etwas zu geschwätzig. :)

> Command failed, result=-1

Also doch eine Fehlermeldung. Kann ich jetzt nicht zuorden. Irgendein 
Befehl hat Returncode -1 an den Interpreter zurück geliefert. Wird nur 
angezeigt, wenn das Programm mit DEBUG übersetzt wurde, also immer. :)

> Der nachfolgende Vorgang läuft erstmal erfolgreich :-)

Dann ist ja gut. :-)

Irgendwann möchte ich einen oder zwei Schalter für Debuglevel/Verbosity 
einbauen. Noch ist im Flash jedenfalls genug Platz für Debug-Meldungen.

[Joe G. (feinmechaniker)]

kurze Rückmeldung zur Version *stamp-monitor-cpm3-0.1.hex*

Das Ergebnis lautet:

-> go E400
## Starting application at 0xe400 ...
-> z80_memfifo_init: 0, e908
z80_memfifo_init: 1, e92c
z80_memfifo_init: 2, ea65
z80_memfifo_init: 3, ea41

Auf der CP/M Console 0 erscheint folgendes:

CP/M Version 3.0, Z180-Stamp BIOS
A>dir
A: BDOS3    SPR : BNKBDOS3 SPR : CCP      COM : COPYSYS  COM : CPMLDR 
REL
A: DATE     COM : DEVICE   COM : DIR      COM : DUMP     COM : ED 
COM
A: ERASE    COM : GENCOM   COM : GENCPM   COM : GET      COM : HELP 
COM
A: HELP     HLP : HEXCOM   COM : PATCH    COM : PIP      COM : PUT 
COM
A: README       : RENAME   COM : RESBDOS3 SPR : SAVE     COM : SET 
COM
A: SETDEF   COM : SHOW     COM : SID      COM : SUBMIT   COM : TYPE 
COM

CP/M 3.0 scheint also korrekt zu booten.
Leo, das ist einfach enfach Super!

[Marcel A. (dl1ekm)]

Ich finde das auch extrem beeindruckend und ziehe den Hut...

Hinweis an Joe: Wäre es möglich, beim Layout statt dieser komischen 
Micro-SD-Slots "normale" Micro-SD-Slots z.B. im Pollin-Design zu 
verwenden, die nach vorne rausgehen (und nicht zum ISP Stecker) und 
einen normalen Steckmechanismus haben?

Habe inzwischen die Karte mehrfach rein und raus geholt für die Tests - 
und ich glaube, die wird nicht ewig halten...

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Wäre es möglich, beim Layout statt dieser komischen
> Micro-SD-Slots "normale" Micro-SD-Slots z.B. im Pollin-Design zu
> verwenden

Ja sicher. Die ursprüngliche Idee dazu war die interne SD als 
Festplatte zu verwenden und die externe CD-Card zu wechseln. Ich habe 
jedoch selber gemerkt, das das Handling derzeit wenig komfortabel ist. 
Gerne sammel ich weite Vorschläge zur Verbesserung, vielleicht in Form 
einer ToDo-Liste.

[Leo C. (rapid)]

Zum Thema Karte rein/raus.

Von Marcel kam der Vorschlag, stattdessen Dateien über die 
USB-Schnittstelle des Monitors zwischen PC und SD-Karte zu kopieren. 
Prinzipiell ist das möglich, allerdings sollte man dafür ein 
Übertragungprotokoll ala Kermit oder Z/X/Y-Modem haben. Für kleinere 
Dateien bis 512K funktioniert folgender Würgaround:

- Datei in Intel Hex konvertieren. [1]
- Mit loadi ins RAM laden. Auf dem Z180 sollte dann kein Programm
  laufen, es sei denn, man weiß, wo freier Speicher ist. [2]
- Datei mit fatwrite auf die SD-Karte schreiben.

Für die cpm3.sys reicht das allemal. Man kann mit mkfs.cpm aus den 
CP/M-Tools auch CP/M-Imagedateien erzeugen, die deutlich kleiner als 8 
MByte sind.[3] Ein leeres Image ist z.B. nur 57344 Byte groß. Diese 
Dateien werden von Chan's FatFs auf dem Stamp bei Bedarf automatisch 
erweitert. (Heute getestet [4])

In die andere Richtung gehts mit fatload leider nur bis ins RAM, da es 
(noch) kein Upload-Protokoll gibt.


[1] z.B. mit srec_cat (http://srecord.sourceforge.net/)
    $ srec_cat -o cpm3.sys.hex -Intel cpm3.sys -Binary

[2] Das CP/M 3 ist z.Zt mit 3 Speicherbänken je 48K und 16K Common
    konfiguriert, und belegt den Speicher ab 0.
    4 * 0xC000 + 0x4000 = 0x34000
    D.h., von 0x34000 bis 0x7FFFF ist freier Speicher, der vom Monitor
    genutzt werden kann, auch wenn CP/M läuft.

[3] $ mkfs.cpm -f simhd imagename.dsk

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Zum Thema Karte rein/raus.

Der Aufwand für diese Extrafunktion ist aus meiner Sicht nicht 
notwendig. Die von Leo C. beschriebenen Boardmittel sollten für die 
Inbetriebnahme ausreichen. Bootet das System korrekt kann ja über die 
zweite Konsole mittels Kermit oder Z/X/Y-Modem auf die Disketten 
zugegriffen werden und darüber ein Dateiaustausch erfolgen. Die 
USB-Schnittstelle am AVR könnte ja über eine dritte Konsole dem CP/M 
zugeordnet werden. Dann läuft die Modemverbindung über USB. Ich denke, 
dass Leo C. diese Erweiterung eh im Hinterkopf hat.
Eine Variante könnte auch ein USB-Host-Controller [1] mit 
RS232-Schnittstelle sein. Hier ist sogar schon das FAT-System 
integriert.

[1] 
http://www.ftdichip.com/Products/Modules/ApplicationModules.htm#VDrive2

[Marcel A. (dl1ekm)]

Zum Würgaround: Ich hatte gedacht, loadi würde von der SD in Z180-Ram 
schreiben. Muss ich mir noch mal ansehen, wäre sicher nicht schlecht für 
den Anfang.

Zu Joes FTDI-Variante: Das klingt toll- Zugriff auf USB Speicher über 
ein "relativ" einfaches serielles Protokoll.
Mit 25€ zwar an sich kein Schnäppchen, aber bei der Ersparnis 
hinsichtlich Entwicklung...
Das wäre auch was für meinen NDR NKC - mit entsprechender Software 
könnte ich dann über die serielle Schnittstelle Daten vom USB-Stick 
einlesen und auf lokale Disketten kopieren...

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Mit 25€ zwar an sich kein Schnäppchen

Ganz so schlimm ist es nicht. Der Preis gilt ja nur für das komplette 
Modul. Ein VNC2 Chip ist für deutlich weniger zu haben. Dieser könnte 
dann mit auf die Basisleiterplatte.

[Leo C. (rapid)]

Marcel A. schrieb:
> Zum Würgaround: Ich hatte gedacht, loadi würde von der SD in Z180-Ram
> schreiben.

Ja eben. Und mit fatwrite dann das RAM auf SD-Karte schreiben.

Joe G. schrieb:
> Der Aufwand für diese Extrafunktion ist aus meiner Sicht nicht
> notwendig. Die von Leo C. beschriebenen Boardmittel sollten für die
> Inbetriebnahme ausreichen.

Gerade am Anfang der Inbetriebnahme wär's praktisch gewesen. Ich hatte 
die SD-Karte dutzende Male hin und her gesteckt. Allerdings eine normale 
SD-Karte und einfache Sockel. Auf die Idee, übers Z180-RAM zu kopieren, 
bin ich auch erst gestern gekommen.

> Bootet das System korrekt kann ja über die
> zweite Konsole mittels Kermit oder Z/X/Y-Modem auf die Disketten
> zugegriffen werden und darüber ein Dateiaustausch erfolgen.

Ja, nachdem man ein funktionierendes System hat. Und dann nur in die 
CP/M-Imagedateien.

> Die
> USB-Schnittstelle am AVR könnte ja über eine dritte Konsole dem CP/M
> zugeordnet werden. Dann läuft die Modemverbindung über USB. Ich denke,
> dass Leo C. diese Erweiterung eh im Hinterkopf hat.

Das sollte ja eigentlich schon laufen. Siehe Bugliste weiter oben. Das 
Device dafür gibts schon (siehe DEVICE-Befehl unter CP/M).
Zur Zeit gibts aber mindestens einen Bug, der dringender ist. Wenn man 
mit pip große Dateien mit Verify von einer Disk zur anderen kopiert, 
werden falsche Daten geschrieben, und pip bricht beim Verify ab. Im 
Moment habe ich keine Ahnung, woran das liegen könnte. Es gibt keine 
Fehlermeldungen und die Debug-Logs sehen gut aus.

[Marcel A. (dl1ekm)]

Ich habe ein Problem,

mit der Version "stamp-monitor-cpm3-debug-0.0.hex", ist alles ok. Ich 
nutze das im ZIP beigefügte cpm3.sys

Bei der Version "stamp-monitor-cpm3-0.1+fboot-support.hex", die mir Leo 
zum Test der Bootloader gegeben hatte, erscheint in der Z80-Konsole:

CP/M Version 3.0, Z180-Stamp BIOS
BIOS Err on A: No CCP.COM file


Zum loadi-Würgaround: Für den Upload vom PC aus reicht da ein einfaches 
ASCII-Senden der HEX-Datei?

Habe nun beide Boards per USB an einem RASPI hängen und per ser2net 
beide Konsolen (AVR, CP/M) über telenet verfügbar gemacht. Ist aber noch 
nicht sehr stabil, ich denke, die brauchen zu viel Saft und ich muss 
einen Hub mit Stromversorgung zwischenschalten. Auch ist nicht 
reproduzierbar, welcher Adapter ttyUSB0 und 1 wird beim boot - da gibts 
aber glaube ich Tricks  bei den Raspi-Leuten.

Wenn ich jetzt auf der Fritzbox eine Portweiterleitung einrichte 
(+dyndns), könntet ihr per putty/telnet auf die Kiste zugreifen :-)

[Marcel A. (dl1ekm)]

Noch was ist mir aufgefallen.

Nach einem reflash der "stamp-monitor-cpm3-debug-0.0.hex" kommt es 
reproduzierbar zu einer bootschleife. Es wird von 3 bis 2 oder 1 
runtergezählt und dann neu gestartet.
Strom ab und wieder dran - alles prima, auch auf Dauer. Vielleicht sind 
das Relikte vom Bootloader?

[Joe G. (feinmechaniker)]

Anbei die überarbeitete Version der Consolen-Schnittstelle für die 
ECB-Card.

Änderungen:
1. 3.3V oder 5V möglich
2. JP1 deaktiviert die beiden RS-232 und über die beiden Buchsenleisten 
können zwei USB-Module zu Testzwecken gesteckt werden.

[Leo C. (rapid)]

Marcel A. schrieb:
> Noch was ist mir aufgefallen.
>
> Nach einem reflash der "stamp-monitor-cpm3-debug-0.0.hex" kommt es
> reproduzierbar zu einer bootschleife. Es wird von 3 bis 2 oder 1
> runtergezählt und dann neu gestartet.
> Strom ab und wieder dran - alles prima, auch auf Dauer. Vielleicht sind
> das Relikte vom Bootloader?

Das war hier schon mal:
Beitrag "Re: Z180-Stamp Modul"

Reset drücken reicht.

Die Version mit Auto-Bootloader-Support schaltet, um in den Bootloader 
zu kommen, den Watchdog ein. Der Monitor muß diesen beim hochfahren 
ausschalten (oder ständig nachtriggern). Die Version ohne 
Auto-Bootloader-Support weiß davon aber nichts. Wenn Du eine solche 
Version also mit dem Autobootloader flashst, wird diese vom Watchdog 
ständig zurückgesetzt, bis zum nächsten 'External' oder 'Power Up' 
Reset.

[Leo C. (rapid)]

Marcel A. schrieb:
> mit der Version "stamp-monitor-cpm3-debug-0.0.hex", ist alles ok. Ich
> nutze das im ZIP beigefügte cpm3.sys

> Bei der Version "stamp-monitor-cpm3-0.1+fboot-support.hex", die mir Leo
> zum Test der Bootloader gegeben hatte, erscheint in der Z80-Konsole:
>
> BIOS Err on A: No CCP.COM file

Nimmst Du in beiden Fällen das gleiche cpm3.sys?
Dann könnte das der Grund sein. Du hast ja auch die Version 0.1 ohne 
Autoboot bekommen. Das cpm3.sys davon paßt dann wieder.

Da unser CP/M 3 Loaderprogramm - im Gegensatz zum original CPMLDR - 
Dateien mit beliebigem Namen laden kann, sollte ich für cpm3.sys 
vielleicht auch Versionskennungen einführen...


> Zum loadi-Würgaround: Für den Upload vom PC aus reicht da ein einfaches
> ASCII-Senden der HEX-Datei?

Ja.
Unter minicom z.B. "Ctrl-A Y".
Copy-And-Paste ins Terminal müßte auch gehen.
Oder das Terminal verlassen und cat datei >/dev/tty...

> Auch ist nicht
> reproduzierbar, welcher Adapter ttyUSB0 und 1 wird beim boot - da gibts
> aber glaube ich Tricks  bei den Raspi-Leuten.

FTDI-Chips liefern eine Seriennummer, über die die ttyUSBx 
unterscheidbar sind. Die billigen Pofilic, die sonst auch gut 
funktionieren, leider nicht.

[Marcel A. (dl1ekm)]

Das wars mit dem falschen cpm3.sys. Klar - wie immer in 99% ein 
layer-8-Fehler.

Übringens beginnt mein SD-Slot langsam zu spinnen. Hat mich eine halbe 
Stunde gekostet bis ich festgestellt hatte, dass die Klappe den Kontakt 
für CardDetect nicht mehr richtig schließt...

[Joe G. (feinmechaniker)]

Hier eine aktuelle Diskussionsvariante zur ECB-Card.

1. externe SD-Card
Belegung von DAT3/CS und Carddetect von Leo C. übernommen

2. CPU Clock
CLKO (Z180) auf Jumper 3 gelegt. Damit kann der Takt über den ACLOCK 
oder OC1A bezogen werden.

3. Bootloader
Um in einer späteren Version den Bootloader/Monitor zu aktivieren oder 
deaktivieren habe ich den Jumper 2 vorgesehen. Er kann PG2 vom AVR gegen 
Masse ziehen. Vielleicht habt ihr ja noch eine andere Idee dazu.

4. noch offen
Sollte CKA0 (Pin 17, Z180 Stamp) auf OC2A (AVR) ?
HALT LED für Z180 notwendig/gewünscht ?
I2C auf Steckverbinder ?
Weitere Wünsche ?

[Marcel A. (dl1ekm)]

Wo sind denn die seriellen Schnittstellen und USB geblieben? Oder ist 
das ein anderes Blatt oder eine andere Baugruppe?
HALT-LED fand ich ganz praktisch.
I2C fände ich auch super

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Wo sind denn die seriellen Schnittstellen und USB geblieben?

Auf Blatt 2 :-)

[Leo C. (rapid)]

> 1. externe SD-Card
> Belegung von DAT3/CS und Carddetect von Leo C. übernommen

Kann man davon ausgehen, daß ein Kartensockel mit Card-Detect-Switch 
verwendet wird? Dann wäre der Pulldown an DAT3/CS überflüssig und man 
könnte stattdessen wieder eine LED spendieren.

Der 47µF Kondensator dürfte auf jeden Fall zu klein sein, wenn man die 
Karte auch im laufenden Betrieb stecken können will. Bei mir sinds 220µF 
+ 10µH Induktivität geworden. Sicher gehen auch andere Kombinationen[1], 
aber diese Teile waren in meiner Bastelkiste. Auch mit dem 220µF 
Kondensator direkt am Sockel hatte ich ohne die Spule bei fast jedem 
Einstecken einen Brown-Out-Reset.

> 2. CPU Clock
> CLKO (Z180) auf Jumper 3 gelegt. Damit kann der Takt über den ACLOCK
> oder OC1A bezogen werden.

Gut.

> 3. Bootloader
> Um in einer späteren Version den Bootloader/Monitor zu aktivieren oder
> deaktivieren habe ich den Jumper 2 vorgesehen. Er kann PG2 vom AVR gegen
> Masse ziehen. Vielleicht habt ihr ja noch eine andere Idee dazu.

Was soll denn passieren, wenn der Bootloader abgeschaltet ist?

> 4. noch offen
> Sollte CKA0 (Pin 17, Z180 Stamp) auf OC2A (AVR) ?

CKA0/DREQ0 muß nicht mehr unbedingt auf low gezogen werden können. Dafür 
wird die Verbindung also nicht mehr gebraucht. Für meine Z80-Stamp 
erzeuge ich mit OC2A den Baudratentakt. Da CKA0 ja auch ein 
UART-Takteingang ist. paßt die Verbindung dafür ganz gut. Das nur zur 
Info, die Z80-Karte werde ich eher nicht auf die ECB/Basiskarte stecken 
wollen.

> HALT LED für Z180 notwendig/gewünscht ?

Da ich die Duo-LEDs hier rumliegen habe, will ich mir schon seit einer 
Weile die Schaltung im Anhang bauen. Leider habe ich keine passenden 
Gatter mehr. Deshalb ist noch nichts draus geworden. Statt RESET müßte 
man eigentlich auch BUSACK nehmen können. Ich kann mich noch erinnern, 
daß ich mich bewußt für RESET entschieden hatte, weiß aber gerade nicht 
mehr wieso.

Früher [TM], also ganz viel früher, hatte ich mal mit Geräten zu tun, 
auf denen ein in der Firma geschriebenes RTOS lief. Die HALT-Led war 
dort sehr praktisch für's Debugging. Im Normalbetrieb blinkte die LED 
kurz (ging kurz aus) im Halbsekundentakt wegen Displayaktualisierung. 
Wenn die LED anders geflackert hat, oder ständig an oder aus war, war 
sofort klar, daß etwas nicht stimmt. (Überlast, Progrmmierfehler).

> I2C auf Steckverbinder ?

Wenn Platz für den Stecker vorhanden ist, warum nicht?

> Weitere Wünsche ?

Ein AVR-Port auf WAIT? Der Monitor könnte dann den Z80-Bus einlesen und 
auswerten (Singlestep für Arme). Für Siglestep bei voller 
Geschwindigkeit ;) müßte man aber WAIT mit MREQ und/oder M1 
synchronisieren, und wäre dann ungefähr bei 
Beitrag "Re: Z180-Stamp Modul"
Wenn man den Takt weit genug herunter setzt, kann man den Bus aber auch 
ohne WAIT abfragen.

Was könnte man denn sonst noch mit den freien AVR-Leitungen machen?
Auf einen Stecker? Jumperfeld? Das wäre dann die Erweiterung von 3. 
oben.



[1] Abschnitt "Cosideration to Bus Floating and Hot Insertion" in
    http://elm-chan.org/docs/mmc/mmc_e.html

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Kann man davon ausgehen, daß ein Kartensockel mit Card-Detect-Switch
> verwendet wird? Dann wäre der Pulldown an DAT3/CS überflüssig und man
> könnte stattdessen wieder eine LED spendieren.

Ja, ist ein echter Card-Detect-Switch [1]. Damit gibt es auch eine echte 
LED für CS.

> Der 47µF Kondensator dürfte auf jeden Fall zu klein sein...
Ich halte mich mal an Elm-Chans Empfehlung.

> Was soll denn passieren, wenn der Bootloader abgeschaltet ist?
Das war natürlich blödsinnig von mir beschrieben. Es sollte Monitor 
heißen. Der Jumper sollte also den Monitor bei Bedarf ausblenden und das 
System sofort das CP/M booten lassen.

> Da ich die Duo-LEDs hier rumliegen habe...
Da in der echten Single-Step-Schaltung (für Reiche) noch zwei Gatter 
übrig sind, dürften sie nun auch deine Duo-Led ansteuern.

zusätzliche Änderungen:
- I2C liegt auf einem Steckverbinder
- die SD-Card hat Level-Shifter
- ECB_Card kann wahlweise auf 3.3V oder 5V laufen

Mit JP4 (Power) kann nun die gesammte Karte zwischen 3.3V und 5V 
umgeschaltet werden. Bei 5V sind die Level-Shifter aktiv beteiligt, bei 
3.3V sind sie halt nur einfache Puffer. Der MAX3241 verträgt auch 5V.
Fehlt nur noch eine sinvolle Steckerbelegung des ECB-Steckverbinders.

[1] 
http://de.farnell.com/wurth-elektronik/693063010911/speicherbuchse-sd-karte-9pol/dp/2081360

[Leo C. (rapid)]

Joe G. schrieb:
> Der Jumper sollte also den Monitor bei Bedarf ausblenden und das
> System sofort das CP/M booten lassen.

Das ist natürlich schon drin:

=> setenv bootcmd 'loadc; go ${startaddress}'
=> setenv bootdelay 0
=> saveenv

Man kann auch noch weitere Befehle in bootcmd schreiben, jeweils mit ";" 
getrennt. Bei mir z.B.

=> pr bootcmd pins
bootcmd=pin ${pins}; loadc; go ${startaddress}
pins=2 low 3 2

Testen kann man mit
=> run bootcmd
und wenns dann klappt "saveenv".

Der Jumper ist aber trotzdem nützlich. Der Monitor könnte ihn beim 
Hochfahren abfragen, und wenn gesteckt, das EEPROM auf Defaultwerte 
zurück setzten (Kaltstart). Es könnte schließlich vorkommen, daß aus 
irgend einem Grund unsinnige Daten im EEPROM stehen, und der Monitor 
dadurch unbedienbar wird.


Hinter L1 muß auf jeden Fall noch ein Kondensator.
Der Treiber für WAIT muß OC sein.

Joe G. schrieb:
> Mit JP4 (Power) kann nun die gesammte Karte zwischen 3.3V und 5V
> umgeschaltet werden.

Wenn Pin 4 des FTDI-Chips auf der AVR-Stamp an die Betriebsspannung der 
Karte (aktuell 3.3V) gehen würde, könnte man auch diese Karte mit 5V 
versorgen, und damit das gesamte System. Falls es eine Neuauflage der 
Karte geben sollte...

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Hinter L1 muß auf jeden Fall noch ein Kondensator.
vergessen :-(
> Der Treiber für WAIT muß OC sein.
mein Gott, das Alter...  vor 30 Jahren wußte ich sofort warum OC, beim 
ersten Schaltungsentwurf wieder mit etwas Nachdenken, gesten nicht mehr 
:-(

> Wenn Pin 4 des FTDI-Chips auf der AVR-Stamp an die Betriebsspannung der
> Karte (aktuell 3.3V) gehen würde, könnte man auch diese Karte mit 5V
> versorgen, und damit das gesamte System.
Hatte ich schon geändert. Weiterhin den Batteriehalter und den 
Micro-SD-Slot. LP's sind auch keine mehr vorrätig (weder AVR noch Z180), 
so dass auch hier eine Nachauflage sinvoll erscheint. Der Restfehler 
beim Z180 ist auch beseitigt.

[Leo C. (rapid)]

Leo C. schrieb:
> Zur Zeit gibts aber mindestens einen Bug, der dringender ist. Wenn man
> mit pip große Dateien mit Verify von einer Disk zur anderen kopiert,
> werden falsche Daten geschrieben, und pip bricht beim Verify ab.

Der Bug hängt mit dem Multiple-Sector-I/O zusammen, das ich jetzt im 
Z180 BIOS erst mal heraus genommen habe. Da aber nun beim Schreiben auf 
der AVR-Seite jeder Sektor einzeln auf die SD-Karte ge-sync-ed wurde, 
habe ich das AVR-Programm auch noch mal geändert (war sowieso 
vorgesehen). Der aktuelle Stand scheint jetzt wirklich stabil zu laufen.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Der aktuelle Stand scheint jetzt wirklich stabil zu laufen.

Ich werde gleich mal testen.

Die Schaltung zum ECB-Board hatte auch einen fetten Bug. Die RS-232 
Leitungen liegen ja auf einem 10-poligen Wannenstecker um die 
SUB-D(male) Verbinder einfach anzucrimpen. Die Beschaltung hatte ich 
jedoch für SUB-D(m)durchgeführt :-( Ist nun korregiert.

[Joe G. (feinmechaniker)]

Könnte man die Zuordnung der CP/M3 (default) Console nicht auch auf eine 
Environmentvariable legen? z.B. 'setenv console 0'  Derzeit ist das ja 
über das IOBYTE auf Adresse 0003h realisiert. So könnten Verweigerer 
einer echten RS-232, über die USB-Verbindung zum AVR auch in den Genuss 
von CP/M kommen.

[Leo C. (rapid)]

Joe G. schrieb:
> Könnte man die Zuordnung der CP/M3 (default) Console nicht auch auf eine
> Environmentvariable legen? z.B. 'setenv console 0'

Sowas habe ich auf meiner Liste. Baudraten dann auch. Bin mir nur noch 
nicht sicher, ob man es wirklich braucht.

> Derzeit ist das ja
> über das IOBYTE auf Adresse 0003h realisiert.

Das war mal so, bzw. ist für den Debugger (noch) so. Unter CP/M 3 ist 
die Zuordnung aufwendiger und damit flexibler. Gesteuert wird dann alles 
mit dem DEVICE-Befehl[1]. Den kann man auch in eine PROFILE.SUB[2] 
schreiben, und damit die Einstellung bei jedem Kaltstart vorgeben.
'DEVICE CON:=ASCI1' schaltet auf die zweite serielle Schnittstelle um. 
Die ist ja eigentlich auch für die Console vorgesehen. Im Moment ist es 
ASCI0, weil ich auf ASCI1 gewohnheitsmäßig den Debugger habe.

> So könnten Verweigerer
> einer echten RS-232, über die USB-Verbindung zum AVR auch in den Genuss
> von CP/M kommen.

Wie schon mehrfach geschrieben. funktionert das z.Zt. nicht mit dem 
CP/M. Aber natürlich kommt das rein, aber im Moment habe ich andere 
Prioritäten.


[1] User's Guide, Kapitel 5.2.5 [3]
[2] User's Guide, Kapitel 5.2.74 unten
[3] Das Unser's Guide gibts z.B. hier:
    http://www.cpm.z80.de/manuals/cpm3usersguide.pdf

[Joe G. (feinmechaniker)]

Ich habe die Version 6 mit neuem Bios mal getestet. Folgende Fehler sind 
mir aufgefallen:

1. 5 Laufwerke A-F angelegt

printenv
baudrate=115200
bootcmd=reset; loadf; go ${startaddr}
bootdelay=3
cpm3_file=0:/cpm3.sys
dsk0=0:/cpm3_a.dsk
dsk1=0:/cpm3_b.dsk
dsk2=0:/cpm3_c.dsk
dsk3=0:/cpm3_d.dsk
dsk4=0:/cpm3_f.dsk
pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10 
:PE7
startaddress=e400

Das System bootet korrekt von A:
A und B existieren auch tatsächlich bei C kommt die Meldung:
BIOS Error on C: T-00006, S-00000, Read, FatFs: INVALID_OBJECT, Retry 
(Y/N) ?

D existiert wieder und bei F erscheint die Meldung:
CP/M Error On F: Invalid Drive
BDOS Function = 14

Turbopascal und WS starten zunächst korrekt. Turbopascal bricht jedoch 
das Ausführen großer Programme mit Include und Overlay mit einer 
Speicherfehlermeldung ab. Hier muß ich erst mal testen, ob das unter 
CP/M 2.2 läuft.

[Leo C. (rapid)]

Joe G. schrieb:
> Ich habe die Version 6 mit neuem Bios mal getestet. Folgende Fehler sind
> mir aufgefallen:
>
> 1. 5 Laufwerke A-F angelegt

Z.Zt. werden nur 4 Laufwerke unterstützt.

> printenv
> baudrate=115200
> bootcmd=reset; loadf; go ${startaddr}
> bootdelay=3
> cpm3_file=0:/cpm3.sys
> dsk0=0:/cpm3_a.dsk
> dsk1=0:/cpm3_b.dsk
> dsk2=0:/cpm3_c.dsk
> dsk3=0:/cpm3_d.dsk
> dsk4=0:/cpm3_f.dsk
> pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10 :PE7
> startaddress=e400
>
> Das System bootet korrekt von A:
> A und B existieren auch tatsächlich bei C kommt die Meldung:
> BIOS Error on C: T-00006, S-00000, Read, FatFs: INVALID_OBJECT, Retry
> (Y/N) ?

Sind die Laufwerke alle im simhd Format?
Die Fehlermeldung ist natürlich nicht besonders hilfreich. 
Wahrscheinlich ging der Laufwerks-Login schon schief (f_open), aber an 
der Stelle kann man keine Fehler an das BDOS zurück geben. (Außer 
Laufwerk als nicht vorhanden melden.)

> D existiert wieder und bei F erscheint die Meldung:
> CP/M Error On F: Invalid Drive
> BDOS Function = 14

Siehe oben.


> Turbopascal und WS starten zunächst korrekt. Turbopascal bricht jedoch
> das Ausführen großer Programme mit Include und Overlay mit einer
> Speicherfehlermeldung ab. Hier muß ich erst mal testen, ob das unter
> CP/M 2.2 läuft.

Wurde das Programm auf dem CP/M3-System compiliert? Die TPA ist zur Zeit 
etwas kleiner als bei dem AVR-CP/M-System.

[Marcel A. (dl1ekm)]

Joe G. schrieb:
> Könnte man die Zuordnung der CP/M3 (default) Console nicht auch auf eine
> Environmentvariable legen? z.B. 'setenv console 0'  Derzeit ist das ja
> über das IOBYTE auf Adresse 0003h realisiert.

Ich arbeite mich ja immer mehr ein - vom Speichermanagement unter CPM3 
bin ich aber noch weit entfernt.
Das IOBYTE hatte ich mit CPM2.2 in Verbindung gebracht und mich 
gewundert, dass dies in dem "Basic"-HEX von Leo bereits eine Bedeutung 
hatte dass es unter CPM3 zumindest derzeit noch funktioniert.

Noch eine Bitte zu den Schnittstellen. Ich fände es gut, wenn VOR dem 
MAX232 eine Stiftleiste (3 Pins) wäre, um dort billige 
China-USB-Serial-Wandler alternativ direkt anzuschließen .

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Noch eine Bitte zu den Schnittstellen. Ich fände es gut, wenn VOR dem
> MAX232 eine Stiftleiste (3 Pins) wäre, um dort billige
> China-USB-Serial-Wandler alternativ direkt anzuschließen .

Die Buchsenleisten USB0 und USB1 (6polig) liegen ja direkt an der SIO 
vom Z180 und parallel am MAX3241. Über JP1 wird der MAX in den Shutdown 
Modus geschickt. Somit sind nur die USB-Wandler aktiv. USB und RS-232 
parallel geht leider nicht so einfach. Bei der Beschaltung der Buchsen 
habe ich mich nach den bei mir [1] rumliegenden Wandlern gerichtet. Um 
Handshake zu realisieren mit /CTS und /DTR. Außerdem können die Module 
von 3.3V auf 5v umgeschaltet werden.

[1] 
http://www.aliexpress.com/item/FT232RL-FTDI-USB-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Port-3-3V-5V/2043815349.html

[Marcel A. (dl1ekm)]

Mal wieder eine blöde Frage. Ich habe in den letzten Tagen viel über die 
MMU des Z180 gelesen und eine erste Idee bekommen, wie das geht (ganz 
verstehen würde ich das noch lange nicht nennen).
Wichtig ist ja, dass die SW für den Z180 das unterstützt durch 
geschicktes Einblenden des physikalischen Speichers in den logischen 
(diese Register). Ebenso die Trennung zwischen Common0, Bank und 
Common1.

Ebenso habe ich versucht zu verstehen, wie CPM3 mit dem Thema umgeht 
(banked version). Ich habe habe einige Verbindungen nicht verstanden...
Kann mir jemand eine gute Quelle nennen?
- Nutzt CPM3 selber die MMU für sich (TPA, BIOS, BDOS... so habe ich das 
verstanden)?
- Stellt CPM dann wiederum selber Umschaltmethoden an 
Anwendungsprogramme bereit?
- Oder muss dann CPM-Software die Bank-Mechanismen des Z180 selber 
nutzen und wenn ja - kommt sie sich dann nicht mit der CPM-Verwaltung 
ins Gehege?
- Was für Speicher sieht ein CPM-Programm denn eigenltich in einem 
banked CPM3?
- Irgendwie hatte ich den Eindruck, dass Banked CPM3 eh nur 2-3 Banks 
nutzt, um gewisse OS-Anteile auszulagern und mehr TPA zur Verfügung zu 
stellen?
- Wie ist das dann auf "unserer" STAMP implementiert?


Ich glaube das bringt so alles nix. Ich muss wirklich bei 0 anfangen wie 
Leo es mir empfohlen hat. Diese Quereinstiege bringen es nicht - auch 
wenn mir dazu leider die Zeit fehlt (im Gegensatz zu Leo/Joe bin ich 
damit nicht groß geworden oder habe damit beruflich zu tun gehabt :-()

[Leo C. (rapid)]

Marcel A. schrieb:
> Kann mir jemand eine gute Quelle nennen?

Vielleicht "CP/M 3 Programmer’s Manual", Kapitel 1.1?
Im "CP/M 3 System Manual" ist das Speichermodell ab Kapitel 1.4 dann 
nochmal dargestellt.

Hier ist eine gute Darstellung von CP/M 2. Unter CP/M 3 ist die 
Speicheraufteilung aus Sicht der Anwenderprogramme gleich:
http://www.oocities.org/homeofoscarvermeulen/cpm.html

Das hier hat mir heute Abend die Zeit gestohlen. :) CP/M gibts ab Folge 
16:
https://www.youtube.com/playlist?list=PLB3mwSROoJ4KLWM8KwK0cD1dhX35wILBj

> - Nutzt CPM3 selber die MMU für sich (TPA, BIOS, BDOS... so habe ich das
> verstanden)?

CP/M setzt nur eine einfache Bank-Umschaltung vorraus. Die Umschaltung 
kann in Hardware auf unterschiedliche Weise realisiert werden. Auf einem 
Z180 nimmt man dafür natürlich die MMU. Ins BIOS kommt dann eine 
Funktion, die für die vom BDOS gewünschte Bank-Nummer, die MMU 
entsprechend programmiert.

> - Stellt CPM dann wiederum selber Umschaltmethoden an
> Anwendungsprogramme bereit?

Das ist leider nicht vorgesehen. Anwenderprogramme haben nur die TPA zur 
Verfügung.

> - Oder muss dann CPM-Software die Bank-Mechanismen des Z180 selber
> nutzen

Wenn ein Programm das macht, ist es streng genommen kein CP/M-Programm 
mehr, auf jeden Fall ist es nicht mehr portabel. Selbst wenn der nächste 
CP/M3-Computer die gleiche MMU hätte, könnte die Speicherverteilung ganz 
anders aussehen. Die Bankumschaltung über's BIOS ist zwar portabel, aber 
für Anwenderprogramme nicht immer erreichbar, da die Umschaltung aus dem 
Common-Bereich erfolgen muß.

> und wenn ja - kommt sie sich dann nicht mit der CPM-Verwaltung
> ins Gehege?

s.o.

> - Was für Speicher sieht ein CPM-Programm denn eigenltich in einem
> banked CPM3?

Die 64KByte, die als Bank 1 und Common geschaltet sind. Für das Programm 
frei nutzbar ist der TPA-Bereich.

> - Irgendwie hatte ich den Eindruck, dass Banked CPM3 eh nur 2-3 Banks
> nutzt, um gewisse OS-Anteile auszulagern und mehr TPA zur Verfügung zu
> stellen?

So siehts aus. Man kann bis zu 16 Banks zur Verfügung stellen. Das 
meißte davon kann aber nur als Sektor-Puffer (Platten-Cache) genutzt 
werden.

> - Wie ist das dann auf "unserer" STAMP implementiert?

Im Moment ist es so:
(logische Adressen 4-stellig, physikalische Adressen 5-stellig)

16K Common (C000-FFFF, 3-4 Banks a max. 48K. (0000-BFFF)

Z180 MMU:
CBAR: C0 (Common Area1 beginnt bei C000, Banked Area bei 0000,
         Common Area 0 ungenutzt)
CBR:  00 (Log. Addressen C000-FFFF werden auf phys. Adressen 0C000-0FFFF
         gemappt)
BBR:  00, 10, 1C, 28, ... (für Bank 0, 1, 2, 3, ...)

Bei dieser Aufteilung kann BBR einfach berechnet werden:

; Return the BBR value for the given bank number
;
; in  a: Bank number
; out a: bbr value

bnk2log:
        or      a               ;
        ret     z               ; Bank 0 is at physical address 0

        dec     a
        push    bc              ;
        ld      b,a             ;
        ld      c,CA            ;
        mlt     bc              ; bank size * bank number
        ld      a,c             ;
        add     a,10h           ; add bank0 + common
        pop     bc              ;
        ret                     ;

Der Common-Bereich ist so groß, damit man bequem debuggen kann. Später 
wird das BIOS weiter nach oben geschoben, und der Common-Bereich auf 8K 
oder 4K verkleinert.

  Log    Phys                     Phys                     Phys
 Addr    Addr                     Addr                     Addr
 FFFF   0FFFF+---------------+        +---------------+        +---------------+
             |               |        |               |        |               |
 E400        | Resident BIOS |        | Resident BIOS |        | Resident BIOS |
             +---------------+        +---------------+        +---------------+
             | Resident BDOS |        | Resident BDOS |        | Resident BDOS |
             +---------------+        +---------------+        +---------------+
             | High-order TPA|        |               |        | High-order TPA|
             | (not accessed |        |               |        | (not accessed |
             |  while Bank 0 |        |               |        |  while Bank 2 |
             |   is active)  |        |               |        |   is active)  |
 C000   0C000|               |        |               |        |               |
             +---------------+        |               |        +---------------+
 BFFF   0BFFF|               |   1BFFF|               |   27FFF|               |
             |  Banked BDOS  |        |               |        |               |
             |               |        |               |        |               |
             +---------------+        |               |        |               |
             |               |        |               |        |               |
             |  Banked BIOS  |        |   Transient   |        |               |
             |               |        |    Program    |        |               |
             +---------------+        |     Area      |        |     LRU       |
             |               |        |     (TPA)     |        |     Data      |
             |               |        |               |        |    Buffers    |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             | LRU Directory |        |               |        |               |
             |    Buffers    |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        |               |        |               |
             |               |        | +-----------+ |        |               |
             |               |        | |  Console  | |        +---------------+
             |               |        | |  Command  | |        |               |
             |               |        | | Processor | |        |  CCP Reload   |
 0100        |               |        | |   (CCP)   | |        |    Buffer     |
             +---------------+        +-+-----------+-+        +---------------+
 0000   00000|///////////////|   10000|   Page Zero   |   1C000|///////////////|
             +---------------+        +---------------+        +---------------+
             Operating system        Application program      Data sector buffers
                   Bank 0                  Bank 1                   Bank 2

[Marcel A. (dl1ekm)]

Leo C. schrieb:
> Marcel A. schrieb:
>> Kann mir jemand eine gute Quelle nennen?
>
> Vielleicht "CP/M 3 Programmer’s Manual", Kapitel 1.1?
> Im "CP/M 3 System Manual" ist das Speichermodell ab Kapitel 1.4 dann
> nochmal dargestellt.
>

Danke, das hatte ich natürlich bereits gelesen und daraus meine 
anscheinend weitgehend richtigen Schlüsse gezogen.

Danke auch für die tolle Speicherdarstellung. Auch so hatte ich mir das 
vorgestellt, gut gemacht!

[Joe G. (feinmechaniker)]

Dieser Link ist auch recht informativ:
http://www.prof80.de/

Hier wird die Hardware und Software für CP/M 3 anhand eines HD64180 
beschrieben.

[Joe G. (feinmechaniker)]

Mein Filetransfer macht Probleme. Habt ihr das mal versucht?

A>PIP TEST.HEX=AUX:[B]

meldet sicht trotz EOF am Fileende (nach erfolgreichem Filetransfer) 
nicht zurück. DEVICE scheint jedoch korrekt zu sein.

A>DEVICE

Physical Devices:
I=Input,O=Output,S=Serial,X=Xon-Xoff
AVRCON NONE  IO     ASCI0  19200 IOS    ASCI1  19200 IOS

Current Assignments:
CONIN:  = ASCI0
CONOUT: = ASCI0
AUXIN:  = ASCI0
AUXOUT: = ASCI0
LST:    = Null Device

[Leo C. (rapid)]

> A>PIP TEST.HEX=AUX:[B]

Seltsame Dinge passieren da bei mir.
Wenn die Datei ein CP/M EOF am Ende hat, reicht es, wenn ich auf der 
Console irgend ein Zeichen eingebe, damit der Prompt wieder erscheint.
Wenn die Datei kein EOF hat, muß ich an der Console ein EOF eingeben.
Wenn die Datei viele EOF hat, wie unter CP/M üblich, hängt sich alles 
auf.

Bei diesen Versuchen waren AUX und CON immer auf der gleichen 
Schnittstelle (ASCI0).

Das System hängt sich aber auch auf, wenn ich mit der Maus in das 
Consolen-Terminal paste. Dürfte das gleiche Problem sein wie der 3. Fall 
oben.
Der UART bekommt die Zeichen dann schneller, als CP/M sie lesen kann. 
Dagegen könnte ein Interrupt-gesteuerter Empfangspuffer zwar helfen, 
aber das System sollte auch so nicht hängen bleiben...

(Option "B" gibts beim CP/M 3 PIP nicht mehr. PIP scheint unbekannte 
Optionen einfach zu ignorieren.)

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Wenn die Datei ein CP/M EOF am Ende hat, reicht es, wenn ich auf der
> Console irgend ein Zeichen eingebe, damit der Prompt wieder erscheint.
> Wenn die Datei kein EOF hat, muß ich an der Console ein EOF eingeben.
> Wenn die Datei viele EOF hat, wie unter CP/M üblich, hängt sich alles
> auf.

Merkwürdig...
Bei mir erscheint der Promt immer dann wenn ich EOF über die Konsole 
eingebe oder noch keinen Transfer gestartet habe. Kommt ein EOF in einer 
Datei vor beendet PIP manchmal, aber nicht immer. Nun habe ich mal die 
Option [H] versucht, natürlich mit einer Intel HEX-Datei. Ist es keine 
so kommt sofort eine Fehlermeldung, ist es eine so wird sie vollständig 
übertragen aber PIP kehrt nicht mehr zurück. Die Datei existiert dann 
als Test.$$$ ist aber korrekt.

[Leo C. (rapid)]

Es scheint an den chario-Routinen zu liegen, obwohl ich mir das im 
Moment nicht so richtig vorstellen kann. Vielleicht muß im UART nach 
einem Overrun-Error der Fehlerstatus zurück gesetzt werden, oder so. 
Demnächst wollte ich die Treiber auf Interrupt umstellen (war im ddtz 
schon mal drin), aber das sollte auch mit Polling richtig funktionieren.

[Leo C. (rapid)]

> Vielleicht muß im UART nach
> einem Overrun-Error der Fehlerstatus zurück gesetzt werden,

Das ist tatsächlich so. Solange das Overrun-Fehlerbit gesetzt ist, wird 
Receive-Data-Full nicht gesetzt.

Das erklärt, warum die Schnittstelle hängen bleibt, wenn PIP nach dem 
ersten EOF keine Zeichen mehr abholt, aber noch weitere EOFs folgen. Es 
könnte auch passieren, daß der Receiver überläuft, wenn PIP einen Sektor 
auf "Platte" schreibt. Aber hier scheint das ja nicht der Fall zu sein, 
da Die Daten ja immer vollständig in der Datei waren.

[Joe G. (feinmechaniker)]

Die neue BIOS Version scheint bezüglich des DEVICE korrekt zu laufen. 
Die Baudraten lassen sich alle einstellen. 134 Baud :-)  (115200) laufen 
sogar richtig schnell. Auch der Filetransfer geht bei 115200 richtig 
schnell und fehlerfrei. Allerdings sollte man bei gleichem SIO-Kanal die 
Option [H] für den Filetransfer nicht benutzen, da CON dann auf AUX 
liegt und trotzdem alles auf den Bildschirm kommt. Ist dann ein EOF 
dabei, ist es vorbei mit den File. Die Übertragung mit
PIP TEST.HEX=AUX:
reicht also schon für ein INTEL HEX-File aus. Nach der Übertragung ein 
EOF über die Console senden und schon ist das File auf der SD-Card. 
Prima Sache!

[Marcel A. (dl1ekm)]

Joe G. schrieb:
> Die neue BIOS Version

Welche nutzt du bzw. hast du?

> scheint bezüglich des DEVICE korrekt zu laufen.
> Die Baudraten lassen sich alle einstellen. 134 Baud :-)  (115200) laufen
> sogar richtig schnell.
Wie?

> Auch der Filetransfer geht bei 115200 richtig
> schnell und fehlerfrei. Allerdings sollte man bei gleichem SIO-Kanal die
> Option [H] für den Filetransfer nicht benutzen, da CON dann auf AUX
> liegt und trotzdem alles auf den Bildschirm kommt. Ist dann ein EOF
> dabei, ist es vorbei mit den File. Die Übertragung mit
> PIP TEST.HEX=AUX:
Auf was ist AUX denn gemappt?  ASCI0 (wo auch das Terminal dran hängt)?

> reicht also schon für ein INTEL HEX-File aus.
> Nach der Übertragung ein EOF über die Console senden
vermutlich CRTL-Z?
> und schon ist das File auf der SD-Card.
> Prima Sache!

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Welche nutzt du bzw. hast du?
6.1

> Wie?
115200 Baud

> Auf was ist AUX denn gemappt?  ASCI0 (wo auch das Terminal dran hängt)?
Ja, die Baudrate für CON und AUX muß jedoch vorher über DEVICE 
eingestellt werden.

> vermutlich CRTL-Z?
ja, das ist das EOF von CP/M

[Leo C. (rapid)]

Marcel A. schrieb:
> Welche nutzt du bzw. hast du?

Ich hatte Joe einen Zwischenstand mit geändertem UART-Treiber geschickt, 
um diesen ominösen PIP-Fehler einzugrenzen.

> Wie?

Als einzige Neuerung ist dort die Baudrateneinstellung drin. Leider aber 
auch ein schwer zu findender Fehler, der sich beim wiederholten 
Kaltstart bemerkbar macht ("restart" im Monitor).

[Joe G. (feinmechaniker)]

Hier mal ein Vorschlag zur ECB-BUS Verschaltung des Steckverbinders.

Die Farben sollten eigentlich selbsterklärend sein.

grau/braun/blau - ECB BUS Standard
braun - nur am Z180 belegt
blau - nur am AVR belegt
gelb – noch variabel (mein Vorschlag)

Weiterhin enthält die Stamp Doku nun eine komplette Darstellung der 
beiden Stamp-Steckverbinder (Doku Anhang 1). Damit sollte das Stapeln 
oder das Fädeln einfacher sein :-)

[Leo C. (rapid)]

Gibt es hier Leute, die vorhandene ECB-Karten mit dem Stamp-System 
verwenden wollen? Wenn ja, könnte man diese Karten ja bei der Zuordnung 
berücksichtigen.

Da Kontron am Anfang leider einen Teil des Busses nicht definiert hatte, 
sind mehrere (Firmen-) Standards entstanden. Im Anhang ist eine 
Gegenüberstellung einiger davon. Die grünen Leitungen sind bei allen 
gleich. Der Rest teilt sich im Wesentlichen in 2 Lager (und einen 
Exoten): Kontron (dunkelblau) und Elzet (hellblau). Von Oettle&Reichler 
gibt es aber mindestens eine RAM-Karte, die in das Elzet-Lager fällt. 
Die "xxx" in der Conitec-Spalte sind wohl ein Druckfehler. Da "damals" 
das Elzet-Lager für Hobbyisten interessanter war, hatte ich mit dieser 
Belegung für das Stamp-System angefangen. Wie man sieht, bin ich aber 
noch nicht weit gekommen. Und da ich sowieso keine alten Karten habe, 
ist es mir egal.


Ich würde /INT1 und /INT2 auf den ECB legen. Praktisch für I/O-Karten 
ohne Zilog-Bausteine. Falls die Leitungen knapp sind, könnte man einen 
davon statt des /NMI-Signals auf die /NMI-Leitung legen. In einem 
CP/M-System ist /NMI ja leider unbrauchbar. Aber da niemand gezwungen 
ist, CP/M auf dem System zu fahren... Jumper?

Außerdem sollte man /DREQ1 und/oder /DREQ0 auf den Bus legen. Auf /TEND1 
und /TEND0 kann man eher verzichten.

Auf /BAI und /BAO kann man wahrscheinlich auch verzichten.
Und /RFSH...

Gut finde ich die I2C-Leitungen auf dem Bus. Daran hatte ich noch gar 
nicht gedacht. 3.3V auf VBAT ist sicher auch eine gute, kollisionsfreie 
Lösung.

So weit mal meine aktuelle, unmaßgebliche Meinung.

[Joe G. (feinmechaniker)]

Danke!
Da haben wir ja schon eine recht hohe Übereinstimmung.

A16-A19 in Lager 2 zu verschieben ist kein Problem.
/ZRESET auf /RESOUT und /ARESET auf /RESET ist auch sinnvoll.
Da eine DMA-Kette wohl in unserem System eher keine Verwendung finden 
wird, liegt auf /BAI und /BAO nun /INT1 und /INT2. Auch /DREQ0 und 
/DREQ1 finden Platz. 2CLK wird OC1A ( 2 ist also 0.5 :-)
Auf drei Leitungen darf man sich noch austoben…

Aber vielleicht kommt ja noch der eine oder andere Vorschlag von 
jemanden der noch ECB-Karten nutzen möchte.

[Leo C. (rapid)]

> 2CLK wird OC1A ( 2 ist also 0.5 :-)

Wenn der Z180 von OC1A versorgt wird, und der interne Taktteiler 
eingeschaltet ist, stimmts wieder. O&E haben auf nCLK den Baudratentakt 
gelegt. Das dürfte auch eher ein 1/n CLK sein.

Auf 39c (CLK) sollte PHI vom Z180 gelegt werden.

> Auf drei Leitungen darf man sich noch austoben…

Ich hätte kein Problem damit, /RFSH umzudefinieren.

[Joe G. (feinmechaniker)]

Da ja 39c korrekt tatsächlich PHI ist, muss CLK umziehen. Es darf nach 
2CLK umziehen und nCLK bekommt dann OC1A.
/RFSH steht dann auch noch zur freien Verfügung.
Gibt immer noch 3 freie Pins. Wir müssen aber auch nicht alles belegen 
;-)

[Marcel A. (dl1ekm)]

Hallo,

angeregt durch die PIP-Tests habe ich mich einmal an Kermit 
herangetraut.

Zunächst habe ich eine Version "generisch" für CP/M 3 gelinkt, so dass 
ich das File im Anhang erhalte.
Dieses läuft auch - grundsätzlich.
Aber ich komme mit der Bedienung nicht klar, trotz Doku.
Bei "GET" erscheinen einfach ein paar Sonderzeichen auf dem Bildschirm - 
sonst nichts.
Senden einer Datei unter minicom am PC (ruft c-kermit auf) klappt nicht, 
Fehlermeldung "kein carrier".
Bei "CONNECT" passiert nichts.

Starte ich Kermit in der minicom-session, bekomme ich einen 
kermit-client. Dort kann ich auch carrier-detect abschalten. Aber nun 
habe ich ja keine Kontrolle mehr über die CP/M-Konsole.

Ich vermute, für Kermit müsste ich eine 3. Verbindung über ASCI1 
herstellen? Ist das schon implementiert?

SHOW zeigt mir

Autoreceive is off
Block check type: 1-character
Multi-sector buffering at 64 of a maximum of 64
File COLLISION:  RENAME
Debugging off
Current default disk: D
Display file size on DIRECTORY command on
Escape char: Control-\
File Mode default
Flow control off
IBM flag off
Disposition for incomplete files is discard
Local echo off
Logging to D:KERMIT.LOG is off
Parity: none
Printer copy off
RECEIVE packet length  80
RECEIVE start-of-pkt char  ^A
SEND packet length  80
SEND start-of-pkt char  ^A
Current TACTrap Status/Intercept Character:   off
Timer off
Current user number:  0
Terminal display is REGULAR
Terminal emulation is OFF
File warning on

Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen, 
also müsste man AUX über Device umlegen...?

Vermutlich so...

Current Assignments: 
CONIN:  = ASCI0  
CONOUT: = ASCI0  
AUXIN:  = ASCI1  
AUXOUT: = ASCI1  
LST:    = Null Device

Aus der Kermit-Beschreibung:

CP/M-3 Kermit (also known as CP/M-Plus Kermit) is a version of generic 
Kermit-80, and should run on most CP/M-3 (CP/M-Plus) systems. It uses the 
auxilliary port (AUX:) to communicate to the remote Kermit. The SET BAUD 
and SET PORT commands are not supported; nor can a BREAK be sent. Like  
generic Kermit-80, a terminal may be selected at assembly time.

[Leo C. (rapid)]

> angeregt durch die PIP-Tests habe ich mich einmal an Kermit
> herangetraut.

Hat Dein System die PIP-Tests denn bestanden?

> Bei "GET" erscheinen einfach ein paar Sonderzeichen auf dem Bildschirm -
> sonst nichts.

Diese Sonderzeichen sollten wohl über die Kommunikationsschnittstelle an 
das andere Kermit gehen, damit es die Datei sendet. Bei Dir war diese 
Schnittstelle wohl identisch mit der CP/M-Console. Das funktioniert mit 
CP/M-Kermit wahrscheinlich nicht.

> Senden einer Datei unter minicom am PC (ruft c-kermit auf) klappt nicht,
> Fehlermeldung "kein carrier".

Man müßte dem C-Kermit mitteilen (Config-Datei, oder so) das es an der 
Schnittstelle kein CD-Signal gibt.

> Bei "CONNECT" passiert nichts.
>
> Starte ich Kermit in der minicom-session, bekomme ich einen
> kermit-client. Dort kann ich auch carrier-detect abschalten. Aber nun
> habe ich ja keine Kontrolle mehr über die CP/M-Konsole.

Stattdessen (C-)Kermit auf dem PC nicht in minicom sondern direkt 
starten (im Servermode, falls es da nicht schon automatisch ist), mit 
Verbindung zu der Schnittstelle, die am anderen Ende an CP/M ASCI1 
angeschlossen ist?

minicom weiterhin zu CP/M ASCI0.

> Ich vermute, für Kermit müsste ich eine 3. Verbindung über ASCI1
> herstellen?

Wieso eine dritte? Wenn ich Dich richtig verstehe, versuchst Du z.Zt. 
alles über eine zu machen.

Ist das schon implementiert?

ASCI0 und ASCI1 funktionieren beide gleich seit Anbeginn. Gleich heißt 
in diesem Fall leider gleich schlecht. Siehe PIP weiter oben.

> Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen,
> also müsste man AUX über Device umlegen...?

Genau so ist das gedacht.

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen,
> also müsste man AUX über Device umlegen...?

Das geht bei CP/M 3 nicht [1]. Der Port ist immer AUX. Also ASCI1 mit 
Device auf AUX legen. Die Baudrate wird auch von CP/M 3 übernommen. 
Flow-Control und Handshake usw. über das SET Kommando einstellen. Wenn 
du SET Terminal VT52 einstelltst und dann Connect eingibst, sollte 
die Terminalverbindung zum zweiten Terminal laufen. Wenn das nicht geht, 
ist noch etwas faul.

[1]
1.3.2. CP/M 3 Kermit
CP/M  3  Kermit  should run on most CP/M 3 (CP/M-Plus) systems.  It uses
the auxilliary port (AUX:) to communicate to the remote Kermit.  The SET
BAUD  and  SET PORT commands are not supported; nor can a BREAK be sent.
Like Generic Kermit, a terminal may be selected at assembly time.

[Marcel A. (dl1ekm)]

Joe G. schrieb:
> Marcel A. schrieb:
>> Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen,
>> also müsste man AUX über Device umlegen...?
>
> Das geht bei CP/M 3 nicht [1].
Hatte ich auch gelesen.

So, es klappt nun!
3 USB Anschlüsse :-)
- AVR Console
- CP/M Console ASCI0 (115kB nach Device-Änderung)
- Kermit auf ASCI1 (habe ich erst mal auf 19200 gelassen)

Connect geht
Filetransfer geht
Servermode geht

Weiter habe ich noch nicht getestet - aber so kann man auch sehr schön 
Dateien in ein laufendes System übertragen (wenn der PC im "servermode" 
ist echt kompfortabel).

Und das ganze hätte ich jetzt gerne auch auf meinem NKC :-)
Dort ist CP/M 2.2, aber in der firmware kein richtiger IOByte-Support. 
Das sind noch ganz andere Baustellen :-)

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> So, es klappt nun!

Prima, dann ist ja jetzt etwas Zeit für eine kleine Fleißarbeit ;-)
Wer Lust hat, kann ja mal eine kurze Pinkontrolle durchführen.

[Leo C. (rapid)]

> Prima, dann ist ja jetzt etwas Zeit für eine kleine Fleißarbeit ;-)

Er studiert wahrscheinlich gerade die cp*.asm Dateien, um Kermit an 
seinen NKC anzupassen. :-)

> Wer Lust hat, kann ja mal eine kurze Pinkontrolle durchführen.

Ein paar Leitungen sind nochmal gewandert...
Keine Treiber für den Bus? Spart auf jeden Fall viel Arbeit. Ich denke 
auch, daß es klappen müßte.


Software:
Die Verbindung zur AVR-Console funktioniert jetzt.
Baudrateneinstellung wurde seit dem letzten Zwischenstand etwas 
verbessert, aber es müßte noch besser gehen. Z.B. für "krumme 
Quarzfrequenzen".

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Keine Treiber für den Bus? Spart auf jeden Fall viel Arbeit. Ich denke
> auch, daß es klappen müßte.

Mein erstes System hatte ca. A4 Größe, alles ohne Bustreiber. Damals 
waren aber auch nur 2.5 MHZz Clock üblich ;-)

> Software:
> Die Verbindung zur AVR-Console funktioniert jetzt.
Danke!
Es bootet, auch mit einer schönen neuen Meldung über den Clock :-)
Restart geht auch wieder, prima.
'Device CON:=AVRCON'
verschwindet jedoch im Nirvana. Auch Optionen '[XON,134]' o.ä. mag es 
nicht.
Wie ist hier die korrekte Syntax?

Nachtrag:
Mit welcher Baudrate läuft dann AVRCON?

[Leo C. (rapid)]

> 'Device CON:=AVRCON'
> verschwindet jedoch im Nirvana.

Hast Du am anderen Ende 'connect' eingegeben ?

> Auch Optionen '[XON,134]' o.ä. mag es nicht.
> Wie ist hier die korrekte Syntax?

Nicht anders als bei anderen Devices auch. Allerdings wird nichts davon 
unterstützt. Über XON könnte man ja evtl. nachdenken Das mache ich aber 
erst, wenn es für die seriellen Schnittstellen implementiert ist.

> Nachtrag:
> Mit welcher Baudrate läuft dann AVRCON?

Mit gar keiner. ;) Ist ja kein UART.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Hast Du am anderen Ende 'connect' eingegeben ?

natürlich nicht :-(

>> Mit welcher Baudrate läuft dann AVRCON?
> Mit gar keiner. ;) Ist ja kein UART.

Klar, logisch, ich weiß auch nicht, was ich mir bei dieser Frage gedacht 
habe.

[Joe G. (feinmechaniker)]

In Anlehnung an die Unix Time eine CP/M Time. Sehr nett :))
Wenn ich richtig gerechnet habe, dann ist das Geburtsdatum am 
01.01.1978.
Bei der Tagesdifferenz komme ich jedoch auf einen Tag weniger. (Ist aber 
nicht von Bedeutung)
Das stellen der Uhr geht zunächst in beide Richtungen. Im Monitor sollte 
man jedoch nichts unter dem Jahr 2000 angeben, sonst zählt er vorwärts. 
Im CP/M geht’s ja sowieso nur ab 2000.

Nachtrag:
Wer mit PROFILE.SUB und AVRCON arbeitet, sollte noch ein CPM3_boot.dsk 
ohne PROFILE.SUB auf der SD-Card haben. So kann man bei Fehlern die 
Bootvariable auf dieses Laufwerk setzten. Ansonsten sperrt man sich 
tatsächlich vom CP/M aus :-(

[Leo C. (rapid)]

> Wenn ich richtig gerechnet habe, dann ist das Geburtsdatum am
> 01.01.1978.

Es ist etwas seltsam:

The time of day is kept as four fields. @DATE is a binary word containing the number of days since 31
December 1977. The bytes @HOUR, @MIN, and @SEC in the System Control Block contain the hour,
minute, and second in Binary Coded Decimal (BCD) format.

> Bei der Tagesdifferenz komme ich jedoch auf einen Tag weniger. (Ist aber
> nicht von Bedeutung)

Vielleicht wollte man nicht ab 0 zählen.

> Das stellen der Uhr geht zunächst in beide Richtungen. Im Monitor sollte
> man jedoch nichts unter dem Jahr 2000 angeben, sonst zählt er vorwärts.

Ja leider. Eingaben unter 2000 sollten deshalb noch abgefangen werden.

> Im CP/M geht’s ja sowieso nur ab 2000.

Das liegt am Monitor, genauer an der time-lib aus avr-libc 1.8.1 Die 
geht erst ab 1.1.2000. Dafür aber bis 2136.

Though not specified in the standard, it is often expected that time_t is a signed 
integer representing an offset in seconds from Midnight Jan 1 1970... i.e. 'Unix time'. 
This implementation uses an unsigned 32 bit integer offset from Midnight Jan 1 2000. The 
use of this 'epoch' helps to simplify the conversion functions, while the 32 bit value 
allows time to be properly represented until Tue Feb 7 06:28:15 2136 UTC.

Für ein Retroprojekt natürlich etwas schade, daß man keine "Guten Alten 
Zeiten" einstellen kann.

Außerdem ist noch ein Fehler drin. Man sollte die Uhr nicht nach 9:00 
Uhr stellen (Integer-Überlauf, inzwischen behoben).

Und wenn man die Uhr im Monitor stellt, bekommt das laufende CP/M das 
nicht mit. Kann man auch noch ändern.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> The time of day is kept as four fields. @DATE is a binary word
> containing the number of days since 31 December 1977.

Dann scheint die Zählung zu stimmen. Gezählt wird ab dem 01.01.1978 und 
der 31.12.1977 wird mitgezählt ;-)

> Und wenn man die Uhr im Monitor stellt, bekommt das laufende CP/M das
> nicht mit. Kann man auch noch ändern.

Beim Neustart von CP/M stimmt ja dann die Zeit, oder CP/M wird gleich 
aktualisiert so wie umgekehrt bei DATE SET aus CP/M.

andere Baustelle:
Könnte man die PIN SET Befehle aus dem Monitor nicht auch CP/M verfügbar 
machen? z.B. über einen OUT Befehl auf einer noch zu definierenden 
Adresse. Dann könnte die RS-232 / USB Umschaltung am RS-232 Treiber 
direkt aus CP/M gesteuert werden. Im AVR CP/M der letzten Version mit 
I2C-Port war das ja auch realisiert. CP/M könnte dann prinzipiell 
Onboard Konfigurationen selbst durchführen.

[Marcel A. (dl1ekm)]

Joe G. schrieb:
> Leo C. schrieb:
>> Hast Du am anderen Ende 'connect' eingegeben ?
>
> natürlich nicht :-(

Das bedeutet, man muss erst auf ASCI0 auf die CPM-Konsole, dort den 
Device Befehl eingeben. Dann in der AVR-Console "connnect" eingeben?
Damit braucht man ja auch weiterhin immer mindestens 2 
Verbindungen/Konsolen?

>
>>> Mit welcher Baudrate läuft dann AVRCON?
>> Mit gar keiner. ;) Ist ja kein UART.

Wie löst man die Verbindung denn wieder auf? DEVICE wieder umlegen?
Wie löst man den "connect" denn wieder?

>
> Klar, logisch, ich weiß auch nicht, was ich mir bei dieser Frage gedacht
> habe.

[Leo C. (rapid)]

Joe G. schrieb:
> Könnte man die PIN SET Befehle aus dem Monitor nicht auch CP/M verfügbar
> machen?

Guter Vorschlag.

> z.B. über einen OUT Befehl auf einer noch zu definierenden

Da wir hier echte Hardware und keinen Emulator haben, geht es auf die 
Art nicht. Zur Zeit gibt es ein einfaches Protokoll: Z180 sendet 
Anforderung/Befehl an Monitor - Monitor schickt Antwort (oder auch 
nicht). Die Liste der Befehle wird bei Bedarf erweitert. Zur Zeit also 
täglich. :)


Marcel A. schrieb:
> Das bedeutet, man muss erst auf ASCI0 auf die CPM-Konsole, dort den
> Device Befehl eingeben. Dann in der AVR-Console "connnect" eingeben?

Bei den jetzigen Defaulteinstellungen, ja.
Die sind so für mich praktisch zum Debuggen.

> Damit braucht man ja auch weiterhin immer mindestens 2
> Verbindungen/Konsolen?

1. werden die Defaulteinstellungen natürlich irgendwann so geändert, daß 
sie für die Mehrzahl der Anwendungen möglichst passend sind.

2. kann man jetzt schon (fast) alles "scripten". PROFILE.SUB auf CP/M 
und Environment (bootcmd) und run-Befehl im Monitor. Das kann aber 
Probleme geben, wenn man sich die CP/M-Console wegkofiguriert und dann 
nicht mehr dran kommt. (Siehe Nachtrag in 
Beitrag "Re: Z180-Stamp Modul")

3. werden deshalb die Grundeinstellungen für die CP/M Console doch mal 
in den Monitor kommen 
(Beitrag "Re: Z180-Stamp Modul" f.).


> Wie löst man die Verbindung denn wieder auf? DEVICE wieder umlegen?
> Wie löst man den "connect" denn wieder?

Beitrag "Re: Z180-Stamp Modul"

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Damit braucht man ja auch weiterhin immer mindestens 2
> Verbindungen/Konsolen?

Die Konfigurationsmöglichkeiten sind Dank Leo’s Programmierkünsten schon 
jetzt recht groß. Leo kennst sie alle, er programmiert ja, ich 
dokumentiere sie fleißig mit. Am WE wird es wieder eine Ergänzung im 
Handbuch geben, die genau die Konfiguration mittels Skript und den 
Monitorvariablen beschreibt.

[Leo C. (rapid)]

> Die Konfigurationsmöglichkeiten sind Dank Leo’s Programmierkünsten schon
> jetzt recht groß.

Ich glaube, das liegt eher an meiner Entscheidungsschwäche. ;) Dazu 
kommt der Hang, vorhandene Ressourcen optimal auszunutzen...

Dabei fällt mir ein, daß wir noch 238 Byte CMOS-RAM in der Uhr haben. 
Die könnte CP/M (BIOS) z.B. nutzen, um Einstellungen zu speichern. Der 
Monitor würde die Bytes einfach transparent durchreichen. Man könnte 
entweder ein einfaches CP/M-Programm für save/load bauen, oder die 
Einstellungen bei jeder Änderung ins CMOS-RAM kopieren. Dann hätte man 
bei jedem Kaltstart die letzten Einstellungen wieder.

Die in Frage kommenden Einstellungen sind im Wesentlichen die R/W-Bytes 
im SCB (Anhang), vor allem Character-I/O Zuordnungen und Baudraten 
(nicht im SCB, sondern in der @cdtbl), bzw die Werte, die mit DEVICE und 
SETDEF eingestellt werden.

Im Monitor müßte dann nichts über CP/M-Einstellungen wissen.

Meinung?

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Dabei fällt mir ein, daß wir noch 238 Byte CMOS-RAM in der Uhr haben.
> Die könnte CP/M (BIOS) z.B. nutzen, um Einstellungen zu speichern.

Sehr gute Idee!
Ich würde die Variante eines eigenen kleinen Save/Load als sinnvoller 
empfinden. PROFILE.SUB führt das LOAD aus und um SAVE muss man sich halt 
selber kümmern.
Diese Variante hätte den Vorteil eigener Save/Load Routinen. Die 
Z180-Stammp Variante muss ja nicht in jedem Fall in Kombination mit dem 
AVR-Stamp aufgebaut werden. In diesem Fall würden ja automatische 
Routinen ins Leere laufen oder Fehler verursachen. Hingegen eigene 
Save/Load Routinen könnten der eigenen Hardware (IDE, Floppy [1], ...) 
angepaßt werden.


[1] Bild im Anhang - man vergleiche die Stamp-Größe zur Diskettengröße 
:-)

[Leo C. (rapid)]

> Ich würde die Variante eines eigenen kleinen Save/Load als sinnvoller
> empfinden. PROFILE.SUB führt das LOAD aus und um SAVE muss man sich halt
> selber kümmern.

Gerade PROFILE.SUB wollte ich damit vermeiden. Das verlängert den 
Bootvorgang schon sehr deutlich.

> Diese Variante hätte den Vorteil eigener Save/Load Routinen. Die
> Z180-Stammp Variante muss ja nicht in jedem Fall in Kombination mit dem
> AVR-Stamp aufgebaut werden. In diesem Fall würden ja automatische
> Routinen ins Leere laufen oder Fehler verursachen.

Die Funktionalität wäre im BIOS. Und das ist ja gerade die Schnittstelle 
zur AVR-Stamp, und muß bei einer anderen Kombination sowieso 
ausgetauscht werden.

Zuerst hatte ich auch nur die Parameter im Sinn, die das BIOS sowieso 
anfaßt (Baudraten, etc). Wenn man die anderen Parameter auch speichern 
will, ist aber ein eigenständiges Programm besser. Sonst holt man sich 
Äbhängigkeiten ins BIOS, die dort nichts verloren haben.

> Hingegen eigene
> Save/Load Routinen könnten der eigenen Hardware (IDE, Floppy [1], ...)
> angepaßt werden.

Im Fall AVR-Stamp wäre es dann der Kommuniktionskanal zum Monitor im 
BIOS.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Zuerst hatte ich auch nur die Parameter im Sinn, die das BIOS sowieso
> anfaßt (Baudraten, etc). Wenn man die anderen Parameter auch speichern
> will, ist aber ein eigenständiges Programm besser. Sonst holt man sich
> Äbhängigkeiten ins BIOS, die dort nichts verloren haben.

Diese Variante klingt sinnvoll.

Übrigens werde ich die connect Console vom Monitor nicht mit 'strg ^X' 
los.

[Leo C. (rapid)]

Joe G. schrieb:
> Übrigens werde ich die connect Console vom Monitor nicht mit 'strg ^X'
> los.

Control-Dach ('^') und danach X.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Control-Dach ('^') und danach X.

Schon klar, aber werde Control^ X noch Control^ x tun was.

[Leo C. (rapid)]

Bei mir gings zuerst, aber ich habe etwas wild rumgedrückt, und jetzt 
hat sich anscheinend alles aufgehängt. :-(

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Damit braucht man ja auch weiterhin immer mindestens 2
> Verbindungen/Konsolen?

Hier mal ein Auszug aus der Doku zu den Environmentvariablen und zur 
Befehlsabarbeitung (vollständig im SVN). Damit startet das CP/M direkt 
auf der AVR-Console ohne externe RS-232 oder USB-Wandler. Sozusagen CP/M 
für 'Arme' ;-)

[Leo C. (rapid)]

Joe G. schrieb:
> Hier mal ein Auszug aus der Doku zu den Environmentvariablen und zur
> Befehlsabarbeitung (vollständig im SVN). Damit startet das CP/M direkt

Klasse Tutorial, danke.


Die Console hat noch ein paar Macken. Wenn man nach "Ctrl-^ \" Unsinn 
eingibt, hängt sie sich auf.

> Schon klar, aber werde Control^ X noch Control^ x tun was.
Bei mir tun beide "as advertised". Geht denn "Ctrl-^ Q" bei Dir?

Einen komischen Effekt hatte ich ein mal mit "Ctrl-^ Ctrl-X". Kann ich 
aber nicht mehr reproduzieren.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Bei mir tun beide "as advertised". Geht denn "Ctrl-^ Q" bei Dir?


Geht auch nicht, auch nicht "Ctrl-^ ?". Ich habe auch mal das 
Terminalprogramm gewechselt, gleiches Ergebnis.

Interessant ist das Verhalten wenn die Zeile schon vollgeschrieben ist. 
Dann setzt "Ctrl-^ x" (alles gleichzeitig) den Cursor auf den 
Zeilenanfang.

[Joe G. (feinmechaniker)]

Das Routing war nicht schön, aber jetzt gibt es eine akzeptabele Lösung 
für das ECB-Layout (2 Lagen).

[Leo C. (rapid)]

Sieht gut aus.

Ich spiele mit dem Gedanken, das System dann in mein altes 19" Rack zu 
schieben. Allerdings weiß ich nicht, wie ich dann an die 
USB-Schnittstelle auf der AVR-Stamp kommen soll.

Ist es möglich, den SD-Slot etwas nach unten zu schieben? In der Ecke 
würde Platz für einen Frontplattten-Montagewinkel gebraucht. (Foto hier: 
Beitrag "Re: Z180-Stamp Modul") Zwischen 
den beiden Winkeln sind knapp 81mm Platz. Muß aber nicht unbedingt sein.

[Leo C. (rapid)]

Leo C. schrieb:
> Die Console hat noch ein paar Macken. Wenn man nach "Ctrl-^ \" Unsinn
> eingibt, hängt sie sich auf.

So schlimm wars dann doch nicht. Die Console hat nach dem '\' drei 
Dezimalziffern eingesammelt, und wenn man dazwischen andere Zeichen 
getippt hat, wurden die einfach ignoriert. Ich habe das jetzt so 
geändert, daß die Code-Eingabe sofort beendet wird, wenn man andere 
Zeichen als Ziffern eingibt.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Ist es möglich, den SD-Slot etwas nach unten zu schieben? In der Ecke
> würde Platz für einen Frontplattten-Montagewinkel gebraucht.

Hatte ich schon auf meinem Plan und zunächst aus Platzproblemen wieder 
gestrichgen. SD-Card, 2x Reset + 2x RS-232 habe ich nicht ordentlich auf 
der Frontplatte unterbekommen. Dazu kommen ja noch die drei LED's. Aber 
ich stimme dir zu, für eine ordentliche Befestigung sind diese Winkel 
eigentlich notwendig. Ich versuche mal eine Variante ohne auf Micro-SD 
zu wechseln.

> Allerdings weiß ich nicht, wie ich dann an die
> USB-Schnittstelle auf der AVR-Stamp kommen soll.
Auf dem AVR-Stamp sind ja noch einige Anschlüsse NC. Mal sehen ob dort 
USB mit kurzen Verbindungen zu platzieren ist.

[Joe G. (feinmechaniker)]

Die Montagewinkel sind realisiert.
RS-232 ist nun nebeneinander. Über der SD-Card ist sogar noch Platz für 
eine USB-Einbaubuchse. Hier könnte der Monitoranschluss verlängert 
werden.

[Leo C. (rapid)]

Joe G. schrieb:
> Die Montagewinkel sind realisiert.

Ich hatte gerade einen Kommentar zu Deinem letzten Artikel angefangen.
Der ist jetzt größtenteils erledigt. :-)

> RS-232 ist nun nebeneinander.

Am rechten Rand übereinander ginge aber auch. Die breite Frontplatte 
braucht man so oder so wg. der Höhe der Stamp-Karten. Aber nebeneinander 
sieht doch besser aus, und die angeschlossenen Kabel versperren nicht 
die Sicht.

> Hier könnte der Monitoranschluss verlängert werden.

Würde ich aber nicht unbedingt über die Pfostenleiste machen.



Gestern habe ich mal die Zustands-LED angeschlossen. Rot (Halt) und Grün 
(Running) sind OK. Die Mischfarbe (Monitor) ist aber komisch und stark 
Blickwinkelabhängig und (für mich) nicht immer klar von Grün zu 
unterscheiden. Das liegt sicher auch an meiner Rot-Grün-Schwäche und es 
wird besser, wenn der hintere Teil der Led abgedeckt ist. Im Gehäuse ist 
das ja sowieso der Fall. Mit den Vorwiderständen kann ich noch etwas 
experimentieren.

Man kann übrigens auch eine 2-Pin Duo-Led anschließen. Die zeigt dann 
Halt und Running an, und ist im Monitor-Betrieb dunkel.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
>> Hier könnte der Monitoranschluss verlängert werden.
>
> Würde ich aber nicht unbedingt über die Pfostenleiste machen.

Ich sehe noch eine Lösung.
Die beiden seriellen Leitungen des AVR (RxD,TxD) werden mit auf die noch 
freien Pins der Stiftleisten gelegt und bei Bedarf der FTDI über Pin 19 
in den Reset geschickt. Das habe ich auf dem VT100 auch so realisiert. 
Beim Reset meldet der FTDI sich einfach beim Host ab.

[Leo C. (rapid)]

> Ich sehe noch eine Lösung.
> Die beiden seriellen Leitungen des AVR (RxD,TxD) werden mit auf die noch
> freien Pins der Stiftleisten gelegt und bei Bedarf der FTDI über Pin 19

Das finde ich gut.

Ich habe mal nach Alternativen gesucht. Leider finde ich zu den diversen 
gewinkelten USB-Adaptern und -Kabeln keine Maße. Ich fürchte aber, daß 
die alle zu groß sind.
Der Stecker hier ist in die falsche Richtung abgebogen:
http://www.reichelt.de/USB-Kabel/DELOCK-82680/3/index.html?ACTION=3&GROUPID=6099&ARTICLE=138017

Der wäre wohl richtig, wenn er denn passen würde.
http://www.reichelt.de/USB-Kabel/DELOCK-83356/3/index.html?ACTION=3&GROUPID=6099&ARTICLE=135443

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Der Stecker hier ist in die falsche Richtung abgebogen:

Leo C. schrieb:
> Das finde ich gut.

Ich auch :-) deshalb noch der folgende Erweiterungsvorschlag.

CP/M 3 dürfte noch neben USB0 alias AVRCON auch noch USB1 und USB2 
bekommen. Wenn beim Device Befehl gleichzeitig ein AVR-Pin (Set Pin) [1] 
geschaltet wird, könnte dieses Pin automatisch die beiden Treiber 
[RS-232 (MAXIM) und FT232 (FTDI)] toggeln. Hier scheinen sich beide 
Hersteller abgesprochen zu haben, die dazu notwendigen Signale sind 
gerade invers :-)

[1] Beitrag "Re: Z180-Stamp Modul"

[Leo C. (rapid)]

Joe G. schrieb:
> CP/M 3 dürfte noch neben USB0 alias AVRCON auch noch USB1 und USB2
> bekommen. Wenn beim Device Befehl gleichzeitig ein AVR-Pin (Set Pin) [1]
> geschaltet wird, könnte dieses Pin automatisch die beiden Treiber
> [RS-232 (MAXIM) und FT232 (FTDI)] toggeln.

Kann man machen. Allerdings könnte dann jemand beide Varianten 
gleichzeitig zuordnen:
   AUX:=V24-1, USB1
oder
   AUXIN:=USB1
   AUXOUT:=V24-1

Erst dachte ich, kein Problem, die jeweils letzte Einstellung gewinnt.
Aber der Treiber muß dann auch die Bitvektoren, in denen die Zuordnung 
gespeichert ist, manipulieren[*]. Machbar, aber nicht schön.
Schöner wäre ein zusätzliches Attribut für die Devices. Das ginge in 
einem Aufwasch mit Attributen für Parity, Wortbreite, Hardware-Handshake 
und die Baudraten über 19200. Alles was man dafür braucht ist ein 
erweitertes Programm 'DEVICE.COM'. Das wäre doch eine schöne Fingerübung 
für jemanden, der seine Assembler-, PL/M-, C- oder 
TurboPascal-Kenntnisse auffrischen will. ;-)


[*] Diese hier im SCB:

@civec  equ     scb$base+22h    ; Console Input Redirection Vector (word, r/w)
@covec  equ     scb$base+24h    ; Console Output Redirection Vector (word, r/w)
@aivec  equ     scb$base+26h    ; Auxiliary Input Redirection Vector (word, r/w)
@aovec  equ     scb$base+28h    ; Auxiliary Output Redirection Vector (word, r/w)
@lovec  equ     scb$base+2Ah    ; List Output Redirection Vector (word, r/w)

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> oder
>    AUXIN:=USB1
>    AUXOUT:=V24-1

Stimmt, dumme Kombination :-(
Ein eigens DEVICE.COM ist wohl praktischer, auch kann gleich 134.5 
übersetzt werden.

> was man dafür braucht ist ein
> erweitertes Programm 'DEVICE.COM'. Das wäre doch eine schöne Fingerübung
> für jemanden, der seine Assembler-, PL/M-, C- oder
> TurboPascal-Kenntnisse auffrischen will. ;-)

Mit meiner heutigen Fingerübung kann ich schon den SCB-Block lesen und 
schreiben. Wo steht eigentlich der tatsächlich zugehörige Name zu der 
Bitbelegung in Reg 22H-2BH ? Also Bit 15 in Reg 22H ist ja z.B. 'ASCI0'. 
Oder wird einfach das jeweilige Bit an ASCIx gesetzt?

Nachtrag: verzählt, Bit 15 ist natürlich AVRCON

[Leo C. (rapid)]

> Wo steht eigentlich der tatsächlich zugehörige Name zu der
> Bitbelegung in Reg 22H-2BH

Im BIOS gibt es eine Tabelle in der Datei chario.180. In einem laufenden 
System findet man sie über eine Funktion in der BIOS-Sprungleiste 
("return char dev table" oder so ähnlich).

@ctbl:
        db      'USB0  '    ; device 0
        db      mb$in$out
        db      baud$none
        db      'ASCI0 '    ; device 1
        db      mb$in$out+mb$serial+mb$soft$baud
        db      baud$19200
        db      'ASCI1 '    ; device 2
        db      mb$in$out+mb$serial+mb$soft$baud
        db      baud$19200
        db      0           ; table terminator

Bis 16 Geräte sind möglich. In den "Redirection-Vektoren" ist für jedes 
Gerät ein Bit vorgesehen. Höchstwertigstes Bit (Bit 15) für Device 0, 
bis niederwertigstes Bit (Bit 0) für Device 15. Ein gesetztes Bit 
bedeutet eine Verbindung des Kanals zum Gerät. Sind mehrere Bits bei 
einem log. Output-Device gesetzt, wird an alle Greäte ausgegeben. Bei 
mehreren Input-Devices wird der Input vom ersten Gerät genommen.

Ein Eintrag in der @ctbl ist 8 Byte groß. Davon 6 Byte für den 
Gerätenamen, ein Byte Eigenschaften und Status und ein Byte für 
Baudrate.
Für die Baudrate sind nur 4 Bit definiert und im mode byte sind auch 
noch ein paar Bits ungenutzt. Ob eine Nutzung dieser Bits unerwünschte 
Nebenwirkungen hätte, kann ich nicht sagen. Durch das Original 
DEVICE.COM werden sie wahrscheinlich auf 0 gesetzt.
Die Bitdefinitionen für die @ctbl findet man in modebaud.inc oder 
MODEBAUD.LIB oder so:
[/pre]
  ; equates for mode byte bit fields

mb$input    equ 00000001b       ; device may do input
mb$output   equ 00000010b       ; device may do output
mb$in$out   equ mb$input+mb$output

mb$soft$baud    equ 00000100b   ; software selectable
                                ; baud rates

mb$serial   equ 00001000b       ; device may use protocol
mb$xon$xoff equ 00010000b       ; XON/XOFF protocol
                                ; enabled

baud$none  equ 0               ; no baud rate associated
                                ; with this device
baud$50     equ 1               ; 50 baud
baud$75     equ 2               ; 75 baud
baud$110    equ 3               ; 110 baud
baud$134    equ 4               ; 134.5 baud
baud$150    equ 5               ; 150 baud
baud$300    equ 6               ; 300 baud
baud$600    equ 7               ; 600 baud
baud$1200   equ 8               ; 1200 baud
baud$1800   equ 9               ; 1800 baud
baud$2400   equ 10              ; 2400 baud
baud$3600   equ 11              ; 3600 baud
baud$4800   equ 12              ; 4800 baud
baud$7200   equ 13              ; 7200 baud
baud$9600   equ 14              ; 9600 baud
baud$19200  equ 15              ; 19.2k baud
[/pre]

Die BIOS-Sources sind übrigens auch auf meinem Server zu finden. Mit 
SLR180.COM, dem DR Linker LINK80.COM und GENCPM.COM kann man cpm3.sys 
auf einem CP/M.System bauen. Wenn man zxcc auf dem PC installiert hat, 
geht es auch dort mit dem Makefile.

[Joe G. (feinmechaniker)]

Danke für die vielen Hinweise!

> Bis 16 Geräte sind möglich. In den "Redirection-Vektoren" ist für jedes
> Gerät ein Bit vorgesehen. Höchstwertigstes Bit (Bit 15) für Device 0,
> bis niederwertigstes Bit (Bit 0) für Device 15.

Das deckt sich mit meiner Leseroutine.

> Sind mehrere Bits bei
> einem log. Output-Device gesetzt, wird an alle Greäte ausgegeben. Bei
> mehreren Input-Devices wird der Input vom ersten Gerät genommen.

Ich hatte mich schon über die 'Bitverschwendung' gewundert. Aber das 
macht Sinn wenn auf mehrere Geräte verteilt wird.

> Die BIOS-Sources sind übrigens auch auf meinem Server zu finden.
Ok, da finde ich ja die Definitionen.

Ich schreibe gerade, als Fingerübung ;-) einige Hilfsfunktionen wie 
Int_to_HEX oder HEX_to_Int usw. Ganz schön umständlich wenn man das mit 
den Funktionsumfang heutiger Programmiersprachen vergleicht. Ist jedoch 
eine prima Übung und ich erwische mich gerade wie alte CTRL-Kommandos 
zum Kopieren, Einfügen oder Löschen wieder ganz automatisch aus den 
Fingern kommen - wie vor 30 Jahren.

[Wolfram K. (proof80)]

Joe G. schrieb:

> Ich schreibe gerade, als Fingerübung ;-) einige Hilfsfunktionen wie
> Int_to_HEX oder HEX_to_Int usw. Ganz schön umständlich wenn man das mit
> den Funktionsumfang heutiger Programmiersprachen vergleicht. Ist jedoch
> eine prima Übung und ich erwische mich gerade wie alte CTRL-Kommandos
> zum Kopieren, Einfügen oder Löschen wieder ganz automatisch aus den
> Fingern kommen - wie vor 30 Jahren.

Für solche Standardlösungen, die in jedem BIOS gebraucht werden, sind 
Quellen anderer Systeme, wie z.B. unter 
http://www.prof80.de/downloads.html#prof80 ja auch ganz hilfreich. Ich 
kannte mich mal recht gut aus mit dem PROF/GRIP-Projekt aus der c't der 
80er Jahre und bin mir sicher, dass es dort in den BIOS-Quellen manch 
interessante Routine zu finden gab. Leider sind die Quellen in den 
umständlichen Intel-Mnemonics geschrieben und ich hatte mal angefangen, 
Teile in Zilog-Sprache zu übersetzen...

Gruß, Wolfram

P.S.: Ctrl-C/Ctrl-V/Ctrl-X verlernt man nicht so schnell :-)
P.P.S.: Habe meinen stamp leider noch nicht fertig :-((

[Wolfram K. (proof80)]

Nachtrag: Das meiste wird beim PROF im Monitor abgewickelt und dann vom 
BIOS aus angesprungen. Daher liest sich z.B. 
http://www.prof80.de/files/zmon17.zip ganz gut.

[Leo C. (rapid)]

Hier mal wieder ein Update um Testen übers Wochenende.

Neu ist vor allem die Zuordnung des physikalischen RAMs zu den 
CP/M-Banks: Common folgt nicht mehr auf Bank 0 sondern auf Bank 1. Damit 
nichts verschwendet wird ;), folgt Bank 1 unmittelbar auf Bank 0. 
Außerdem wurde der Common-Bereich von 16K auf 4K verkleinert:

Bank 0: 00000 - 0EFFF
Bank 1: F0000 - 1DFFF  (+ F000)
common: 1E000 - 1EFFF  (+ F000)
Bank 2: 1F000 - 2DFFF  (+ F000 + 1000)
usw.                   (+ F000)

Vorteil:
Die TPA ist jetzt auch im physikalischen Speicher zusammenhängend. 
Dadurch gehen Interbank Memory-Move und Transfer von und zur Disk ohne 
Sonderbehandlungen. In der neuen Version geht der Interbank move jetzt 
mit DMA und der AVR-Disktreiber konnte vereinfacht werden und 
funktioniert mit Multi-Sector-Transfer. Eigentlich müßte die Version 
jetzt schneller laufen, aber das habe ich noch nicht getestet.

Nachteil:
loadcpm3 braucht die Information, wo der Common-Bereich liegt, und die
Ladeadresse kann nicht mehr direkt angesprungen werden. Dazu müßte 
zuerst die MMU programmiert werden.
Die Common-Base- und die Banked-Base-Adresse können auf der Befehlszeile 
von loadcpm3 angegeben werden, oder in Environment-Variablen gesetzt 
werden (Siehe "help loadcpm3"). Wichtig ist nur die Common-Base. 
Achtung: Der Defaultwert ist noch auf C000. Deshalb muß für das 
mitgelieferte cpm3.sys F000 auf eine der beiden Arten vorgegeben werden.
In der nächsten Version wird der Defaultwert aus cpm3.sys ausgelesen.

Sonstiges:
Verbesserungen an der Console (connect command).
Commandline editing (endlich:)

Letzteres ist noch nicht ganz fertig. Für Erweiterungen und die 
Tastenzuordnungen nehme ich gerne Änderungsvorschläge entgegen. Für das 
Verhalten des Historybuffers auch. Das ist sowieso noch eine Baustelle.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Verbesserungen an der Console (connect command).

Perfekt! Nun kann ich sie wieder ohne Klimmzüge beenden. Sogar die Hilfe 
geht nun bei mir ;-)

> Commandline editing (endlich:)
Das spart viel Neugetippe beim Vergetippe

Der Bootvorgang läuft stabil durch. Jetzt kann ich testen...

[Joe G. (feinmechaniker)]

Wolfram K. schrieb:
> Für solche Standardlösungen, die in jedem BIOS gebraucht werden, sind
> Quellen anderer Systeme, wie z.B. unter

Danke für den Tipp. Wirklich sehr viel Nützliches.
Ganz neu erfinde ich ja die Unterprogramme doch nicht. Ich schaue schon 
mal in fremde Quellen ;-)

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Hier mal wieder ein Update um Testen übers Wochenende.

Die BIOS-Funktion 20 (DEVTBL) liefert mir einen falschen Pointer zurück.
Korrekt (derzeitiges BIOS) scheint 0xFCA4. Der Aufruf von BIOS 20 
liefert jedoch 0xD2C3 zurück?

[Leo C. (rapid)]

Seltsam. Evtl. irgendwo hex und dez vertauscht? Bei mir funktionierts. 
Die Addresse hat sich inzwischen verändert (FC7E), aber wegen Änderungen 
an anderer Stelle.

>>ll
0100  LD   C,32
0102  LD   DE,0110    
0105  CALL 0005       
0108  NOP  
0109  NOP  
010A  NOP  
010B  NOP  
010C  NOP  
010D  NOP  
010E  NOP  
010F  NOP  
0110  INC  D
0111  NOP  
0112  NOP  
0113  NOP  
0114  NOP  
>>d 110 s7
0110   14 00 00 00  00 00 00  .......
> x
 ZHV  E  A =7E BC =0000 DE =0000 HL =0000 SP=D200 PC=0100       LD   C,32
         A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF 
> c
 ZHV  E  A =7E BC =0032 DE =0000 HL =0000 SP=D200 PC=0102       LD   DE,0110
         A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF       
>>
 ZHV  E  A =7E BC =0032 DE =0110 HL =0000 SP=D200 PC=0105       CALL 0005
         A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF       
>>
 ZHV  E  A =7E BC =FC32 DE =0110 HL =FC7E SP=D200 PC=0108       NOP  
         A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF 
>>dfc7e
FC7E   55 53 42 30  20 20 03 00  41 53 43 49  30 20 0F 03  USB0  ..ASCI0 ..
FC8E   41 53 43 49  31 20 0F 0F  00 B7 D8 DA  D8 FD D8 20  ASCI1 ...7XZX}X 
FC9E   D9 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  Y...............
FCAE   00 00 00 00  00 00 00 00  00 ED 43 0E  FD C9 EB 3A  .........mC.}Ik:
FCBE   0E FD FE FE  20 0B ED B0  EB C9 CD 5A  FD ED 39 39  .}~~ .m0kIMZ}m99
FCCE   C9 ED 09 26  ED 01 27 E5  D5 3A 0E FD  CD 6A FD ED  Im.&m.'eU:.}Mj}m
FCDE   29 20 ED 21  21 ED 39 22  EB 3A 0F FD  CD 6A FD ED  ) m!!m9"k:.}Mj}m
FCEE   29 23 ED 21  24 ED 39 25  3E 02 ED 39  31 3E 60 ED  )#m!$m9%>.m91>`m
>>

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Seltsam. Evtl. irgendwo hex und dez vertauscht?

Eigentlich nicht, laut BIOS Jump Table ist es doch die Funktion 20 
(dezimal).
Der Funktionsaufruf liefert mir auch einen Pointer zurück, allerdings 
einen falschen :-(

[Joe G. (feinmechaniker)]

Hab gerade gesehen, dass du einen BDOS-Aufruf 50 (direkten BIOS-Aufruf) 
machst. Das werde ich auch mal testen, hatte selbst ja einen direkten 
BIOS-Audfruf durchgeführt.

[Leo C. (rapid)]

> Hab gerade gesehen, dass du einen BDOS-Aufruf 50 (direkten BIOS-Aufruf)
> machst.

Das habe ich nur deswegen gemacht, weil ich dachte Du machst es auch so. 
;) Normalerweise zähle ich die BIOS-Funktionen nicht ab. Aber beim 
Aufruf über BDOS muß man ja.
Ich habe es nochmal mit dem zu letzt veröffentlichten BIOS versucht. Zur 
Abwechslung diesmal als Screenshot. Die Addresse ist aber nochmal eine 
andere.

[Joe G. (feinmechaniker)]

Ein Aufruf über DDTZ gibt mir auch das korrekte Ergebnis.

>>d^hl s3*8
FCA4   55 53 42 30  20 20 03 00  41 53 43 49  30 20 1F 04  USB0  ..ASCI0 
..
FCB4   41 53 43 49  31 20 0F 0F   ASCI1 ..
>>

Ein Aufruf über die Turbo-Pascal Funktion BIOSHL(20) produziert den 
Fehler. Wird also ein Turbo Pascal Bug sein. Mal sehen wie ich das 
umgehen kann.

[Leo C. (rapid)]

Leider habe ich gerade kein TP zum Testen parat, aber TP zählt die 
BIOS-Funktionen ab wboot = 0. BDOS(50) zählt wboot=1. Die Funktionsnr. 
unter TP wäre dann 19.

[Joe G. (feinmechaniker)]

Wer hätte das gedacht, wie immer sitzt der Fehler hinter dem Computer 
:-( trotzdem wieder was gelernt.

TP arbeitet in diesem Fall tatsächlich korrekt:

BDOS 50 HL :FCA4
BIOS 19 HL :FCA4

[Marcel A. (dl1ekm)]

Hi,
sind Platinen (für die Stamps als Basis und ggf. Backplane) schon in der 
Mache?

Gruß Marcel

[Joe G. (feinmechaniker)]

Leo’s 'Aufforderung' zur Fingerübung hatte meine Aktivitäten temporär in 
Richtung Software verlagert ;-)
Anbei nun der derzeitige Stand der Backplane.

1.
Fehler in der Stamp.Lib
AVR-Stamp B22 und B26  vertauscht. Da beide NC waren, jedoch ohne 
Auswirkung.

2.
JP6 hat nun noch RxD_AVR und TxD_AVR um den AVR – Monitor direkt auf die 
Frontplatte zu legen. Der Steckverbinder ist gleich neben der SD-Card. 
Wird diese Variante benutzt, ist jedoch der FT232 auf dem AVR-Stamp in 
den Reset zu schicken.

3.
/SHDN vom MAX3241 liegt zusätzlich auf PB6 vom AVR-Stamp um die RS-232 / 
USB Umschaltung später per Software (DEVICE Befehl) ausführen zu können.

Die Leiterplatte ist geroutet und bedarf nur noch einiger Korrekturen 
bezüglich der Leiterbahnbreiten und der Masseführung. Ich denke sie 
diese Woche fertig stellen zu können. Um das Fehlerrisiko zu minimieren, 
würde ich dann erst eine Testplatine fertigen lassen und bestücken, um 
bei Fehlerfreiheit die gewünschte Anzahl in Auftrag zu geben.
Im nächsten Schritt erfolgt die abschließende Überarbeitung der beiden 
Stamp-Platinen.

[Joe G. (feinmechaniker)]

Fertig (siehe Anhang)

[Marcel A. (dl1ekm)]

Ähm - warum ist eigentlich die com3test.dsk 13,9MB groß, ich dachte, es 
werden nur bis 8MB Images unterstützt?

[Marcel A. (dl1ekm)]

> Joe G. schrieb:
> Hier mal ein Auszug aus der Doku zu den Environmentvariablen und zur
> Befehlsabarbeitung (vollständig im SVN). Damit startet das CP/M direkt
> auf der AVR-Console ohne externe RS-232 oder USB-Wandler. Sozusagen CP/M
> für 'Arme' ;-)

Ich versuche gerade noch herauszubekommen, was der Befehl loadf in der 
"Bootsequenz" macht. srec_cat image laden... ?

[Marcel A. (dl1ekm)]

Ich war jetzt eine Woche beruflich in Dubai - vermutlich haben die 43°C 
mein Hirn verbrutzelt...

Habe den Monitor auf 6.4 hochgerüstet. Nun erscheint am Ende eine 
Fehlermeldung:

=========================<  (RE)START DEBUG  >=========================
### Reset reason(s): External.

ATMEGA1281+Z8S180 Stamp Monitor

### main_loop entered: bootdelay=3

### main_loop: bootcmd="reset; loadf; go ${startaddr}"
Hit any key to stop autoboot:  0 
CPU now in reset state.
z80_memfifo_init: 0, 0
z80_memfifo_init: 1, 0
z80_memfifo_init: 2, 0
z80_memfifo_init: 3, 0
Loading Z180 memory... 
   From: 0x00000 to: 0x00003    (    4 bytes)
   From: 0x00008 to: 0x0000A    (    3 bytes)
   From: 0x00010 to: 0x00012    (    3 bytes)
   From: 0x00018 to: 0x0001A    (    3 bytes)
   From: 0x00020 to: 0x00022    (    3 bytes)
   From: 0x00028 to: 0x0002A    (    3 bytes)
   From: 0x00030 to: 0x00032    (    3 bytes)
   From: 0x00038 to: 0x0003A    (    3 bytes)
   From: 0x00040 to: 0x00043    (    4 bytes)
   From: 0x00050 to: 0x02BE4    (11157 bytes)
   From: 0x02BF4 to: 0x02E64    (  625 bytes)
   From: 0x02EA7 to: 0x02EA8    (    2 bytes)
   From: 0x02EEB to: 0x02EEC    (    2 bytes)
   From: 0x02F0F to: 0x02F10    (    2 bytes)
Command failed, result=-1
go - start application at address 'addr'
Usage:
go addr
    - start application at address 'addr'
=>

Egal, CPM (mit dazugehörigem cpm3.sys) kann ich wie beschrieben laden 
und starten.

Aber hier gibt er mir dann einen Fehler unter CPM aus:

A>device

Physical Devices: 
I=Input,O=Output,S=Serial,X=Xon-Xoff
USB0   NONE  IO     ASCI0  19200 IOS    ASCI1  19200 IOS    


Current Assignments: 
CONIN:  = ASCI0  
CONOUT: = ASCI0  
AUXIN:  = ASCI0  
AUXOUT: = ASCI0  
LST:    = Null Device

Enter new assignment or hit RETURN 


A>device CON:=AVRCON

 CON:=AVRCON
      ^     
Error at the '^'; Invalid physical device

A>

Scheint die AVRCON nicht zu kennen...
Aber device CON:=USB0 geht - nach connect im Monitor.
Das passt dann aber nicht zur Doku. Joe schrieb ja oben auch schon:

CP/M 3 dürfte noch neben USB0 alias AVRCON...

Danach habe ich die CPM-Console im AVR Monitor.
Aber wie komme ich wieder in den Monitor (und zurück)?
Die Crtl^ X usw. lösen nichts aus.

Connecting to CPU. Escape character is '^^'.

-> Was muss man denn da eingeben?

[Leo C. (rapid)]

Marcel A. schrieb:
> Ich versuche gerade noch herauszubekommen, was der Befehl loadf in der
> "Bootsequenz" macht. srec_cat image laden... ?

Wenn man "nur" CP/M booten will ist das nicht notwendig. Die 
"Bootsequenz" war ein Beispiel von Joe, um zu zeigen, daß man mehrere, 
durch Semikolon getrennte Befehle in eine Environment-Variable 
schreiben, und diese dann ausführen kann.

'loadf' lädt Daten aus dem AVR-Flash in das Z180-RAM. zur Zeit ist das 
die angepaßte Version von DDT/Z. Vielleicht fliegt der Befehl irgendwann 
raus, wenn das Flash knapp wird, oder es kommt etwas anderen rein. Den 
Debugger könnte man ja auch von einer SD-Karte laden, zB. mit 
'loadihex'.

Joe G. schrieb:
> Leo’s 'Aufforderung' zur Fingerübung hatte meine Aktivitäten temporär in
> Richtung Software verlagert ;-)

Das war keine Aufforderung, sondern ein Hinweis für Leute die sich 
langweilen, und nicht so recht wissen, was sie mit ihrem CP/M eigentlich 
machen sollen. ;-)

[Leo C. (rapid)]

> ### main_loop: bootcmd="reset; loadf; go ${startaddr}"

Die Variable heißt 'startaddress'.

> CON:=AVRCON
>       ^
> Error at the '^'; Invalid physical device

Das Device wurde umbenannt. Der Name AVRCON ist ja nicht so doll. Aus 
Sicht des Z180-BIOS ist das zwar nur eine Verbindung zum AVR-Controller, 
und der Z180 hat ja keine Kontrolle darüber, was der AVR damit macht. 
Aber viele andere Möglichkeiten als die USB-Schnittstelle gibt es ja 
nicht, und das ist ja auch das was der Benutzer sieht.

> Connecting to CPU. Escape character is '^^'.
> -> Was muss man denn da eingeben?

Das erste '^' ist die (übliche) Abkürzung für Steuerzeichen, bzw. die 
Control-Taste. Das zweite '^' meint die Taste mit diesem Zeichen selbst. 
Also Control-Taste (Strg-Taste) gedrückt halten, und dann die Taste mit 
dem '^' drücken. Der Code der Taste ist 0x1E. Wenn Dir die Taste nicht 
gefällt, kannst du über die Environment-Variable 'esc_char' eine andere 
definieren. Hier muß der Hex-Code ohne führendes 0x eingegeben werden.

Wenn der Hilfetext zu 'connect' unklar sein sollte, kann man mir gerne 
einen anderen schicken. Baue ich gerne ein. Das gilt natürlich auch für 
andere Verbesserungsvorschläge.

[Marcel A. (dl1ekm)]

Soweit alles klar.
CRTL halten, links oben ^ drücken und alles loslassen klappt nicht. Auch 
kein anderes Zeichen (Q, X, \)
Wird einfach ignoriert.

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Command failed, result=-1
> go - start application at address 'addr'
> Usage:
> go addr
>     - start application at address 'addr'

Dein Fehler liegt (eigentlich kein wirklicher Fehler) in der 
Einvironmentvariable bootcmd="reset; loadf; go ${startaddr}"
Die Variable 'startaddr' wird erst beim Aufruf von loadcpm3 erzeugt und 
belegt. In deinem Fall existiert sie also nicht und führt zum Fehler. 
Wenn du DDTZ nicht benötigst, lasse loadf weg und nehme den Befehl 
loadcpm3 mit rein.

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht.

Dann läßt dein Terminalprogramm diese Zeichen nicht durch, hatte ich 
auch. Du kannst jedoch über die Environmentvariable esc_car ein Zeichen 
angeben welches dein Terminal akzeptiert.

Hier mal meine Konfiguration:

printenv
baudrate=115200
bootcmd=reset; loadc; go ${startaddress}
bootdelay=3
cpm3_commonbase=F000
cpm3_file=0:/cpm3_v64.sys
dsk0=0:/cpm3_a.dsk
dsk1=0:/cpm3_b.dsk
dsk2=0:/cpm3_c.dsk
dsk3=0:/cpm3_f.dsk
esc_char=0x40
pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10 
:PE7
startaddress=d100
test_fat=fatstat 0:; fatls 0:
test_sd=sd status 0; sd init 0; sd info 0

[Marcel A. (dl1ekm)]

Joe G. schrieb:
> Marcel A. schrieb:
>> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht.
>
> Dann läßt dein Terminalprogramm diese Zeichen nicht durch, hatte ich
> auch. Du kannst jedoch über die Environmentvariable esc_car ein Zeichen
> angeben welches dein Terminal akzeptiert.
>
>
Hm, ich nutze genu wie Leo Minicom. Muss ich noch mal schauen

[Joe G. (feinmechaniker)]

Marcel A. schrieb:
> Hm, ich nutze genu wie Leo Minicom. Muss ich noch mal schauen

Das 'Q' hast du aber nicht vergessen?

=> connect ?
connect - Connect to CPU console i/o
Usage:
connect
    - type the escape character followed by Q to close the connection,
      or followed by ? to see other options. The default escape 
character
      is Ctrl-^ (0x1E). It can be changed by setting env var 'esc_char'.
=>

[Leo C. (rapid)]

Marcel A. schrieb:
> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht.

Nach dem Ctrl-^ sieht man noch nichts. Erst nach dem nächsten Zeichen, 
z.B '?'.

> Auch kein anderes Zeichen (Q, X, \)

Nach 'Q' oder 'X' müßte er wieder rausfliegen. Dann kommt das Ctrl-^ wie 
bei Joe wirklich nicht durch. Villeicht gibts ja Tastaturen, die das 
Zeichen nicht liefern? Unter Linux kannst Du die Tastatur mit 'showkey 
-a' testen, allerdings nicht unter X-Window sondern in einer 
Text-Console.

[Peter Z. (flexopete)]

@ Joe G.,
welche Bauform hast Du für die
Elkos C1, C2 vorgesehen?
Mir kommt der Abstand sehr gering vor.

Gruss
Peter

[Joe G. (feinmechaniker)]

Peter Zabel schrieb:
> welche Bauform hast Du für die Elkos C1, C2 vorgesehen?

Die Elkos haben die Bauform SMC-C / SMC-F oder EIA 6032-28 (20). C und F 
unterscheiden sich nur in der Höhe. Wer mehr die Bezeichnungen 0805, 
1206 usw. gewöhnt ist, der darf auch 2312 zur Bauform der verwendeten 
ELkos sagen. Konkret heißt das 6,0mm x 3,2mm x 2,8mm (L x B x H). Ich 
kann sie auf dem board jedoch noch etwas auseiander rücken, Platz genug 
ist ja.

[Marcel A. (dl1ekm)]

Leo C. schrieb:
> Marcel A. schrieb:
>> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht.
>
> Nach dem Ctrl-^ sieht man noch nichts. Erst nach dem nächsten Zeichen,
> z.B '?'.
>
>> Auch kein anderes Zeichen (Q, X, \)
>
> Nach 'Q' oder 'X' müßte er wieder rausfliegen. Dann kommt das Ctrl-^ wie
> bei Joe wirklich nicht durch. Villeicht gibts ja Tastaturen, die das
> Zeichen nicht liefern? Unter Linux kannst Du die Tastatur mit 'showkey
> -a' testen, allerdings nicht unter X-Window sondern in einer
> Text-Console.
In der X-Console kommt "nichts" durch.
In der Text-Console kommt "^^ 30 0636 0x1e"

Scheint also ein Problem meiner X-Umgebung zu sein. Werde es mal mit 
einem anderen ESC-Char probieren.

[Marcel A. (dl1ekm)]

PANIK!

Mit dem Setzen des esc_char komme ich nun aus dem Connect auch wieder 
raus.

Aber ich kann plötzlich CPM nicht mehr starten.

Ich habe mal das bootcmd gelöscht:

=> printenv
baudrate=115200
bootdelay=3
cpm3_commonbase=F000
cpm3_file=0:/cpm3.sys
dsk0=0:/cpm3test.dsk
dsk1=0:/tp3-hd.dsk
dsk2=0:/editor.dsk
dsk3=0:/kermit.dsk
esc_char=0x1c
pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7
startaddress=d100

Gehe ich nun ein
- reset
- loadcpm3
- go d100

kommen auf der ASCI0-Schnittstelle nur Müllzeichen an, egal welcher 
Baudrate (war bisher 19200).
Hab ich was kaputt gemacht?

Zum Thema DDTZ: Wie starte ich die?
Soweit ich verstanden hatte:
- loadf
- go ${startaddress}
- connect

Aber da passiert gar nix...

[Leo C. (rapid)]

> Hab ich was kaputt gemacht?

Eher nicht. (obwohl man ja nie etwas ausschließen soll:)

Welchen Takt verwendest Du denn?
Die Taktfrequenzerkennung funktioniert (noch) nicht immer zuverlässig.
Außerdem haben wir letzte Woche festgestellt, das der bisher 
eingestellte Oszillator ("Low Power Crystal Oscillator") nicht optimal 
ist. Das hat sicher auch mit der Übertaktung zu tun. Besser ist der 
"Full Swing Crystal Oscillator". Du könntest das mal ausprobieren, in 
dem Du die Low-Fuse auf 0x97 stellst.

> Zum Thema DDTZ: Wie starte ich die?

Du bist der Erste, der fragt. ;)

> Soweit ich verstanden hatte:
> - loadf
> - go ${startaddress}

go 0

> - connect

Nein, ddt/z meldet sich an ASCI1. Baudrate ist fest auf 112500 bei 
18,432MHz Takt (oder 57600 bei 9,216Mhz).
Allerdings kann man die Schnittstelle vor dem Starten über das I/O-Byte 
auf Adresse 3 ändern. 0 ist die AVR-Console, 1 die erste und 2 die 
zweite serielle Schnittstelle.

[Marcel (Gast)]

Bin gerade unterwegs, verwende aber die 18Mhz auf den Z180 Board...
Die ASCII Schnittstelke sollte ja daher nicht von Avr abhängig sein. Der 
Monitor geht und ist genial.
Bisher hatte ich noch nie Probleme. Schaun wir mal.

[Marcel A. (dl1ekm)]

Ging wieder, als ich zurück kam. Steine vom Herzen fall....
War vielleicht ein Wackler am Jumper vom Z180-Quarz.

Weiter gehts :-)

[Marcel A. (dl1ekm)]

>> Zum Thema DDTZ: Wie starte ich die?
>
> Du bist der Erste, der fragt. ;)
>
>> Soweit ich verstanden hatte:
>> - loadf
>> - go ${startaddress}
>
> go 0
>
>> - connect
>
> Nein, ddt/z meldet sich an ASCI1. Baudrate ist fest auf 112500 bei
> 18,432MHz Takt (oder 57600 bei 9,216Mhz).
> Allerdings kann man die Schnittstelle vor dem Starten über das I/O-Byte
> auf Adresse 3 ändern. 0 ist die AVR-Console, 1 die erste und 2 die
> zweite serielle Schnittstelle.

Nicht ganz. Wenn ich mw 3 1 eingebe, ziehe ich mir die DDTZ-Console auf 
ASCI0. Dort kommt sie mit 19200 raus genau wie die CPM-Console (bei 
18MHz).

Mit mw 3 0 kommt sie auf der AVR-Console an.

Sonst klappt aber alles prima!

[Marcel A. (dl1ekm)]

Leo C. schrieb:
. Den
> Debugger könnte man ja auch von einer SD-Karte laden, zB. mit
> 'loadihex'.

Den Befehl finde ich nicht...
Nur loadf (lädt fest DDTZ), loadi (über serielle Schnittstelle) und 
loadc (läd CPM).

[Leo C. (rapid)]

> Nicht ganz. Wenn ich mw 3 1 eingebe, ziehe ich mir die DDTZ-Console auf
> ASCI0. Dort kommt sie mit 19200 raus genau wie die CPM-Console (bei
> 18MHz).
> Mit mw 3 0 kommt sie auf der AVR-Console an.

Ich dachte genau das geschrieben zu haben.

>> 'loadihex'.
>
> Den Befehl finde ich nicht...
> Nur loadf (lädt fest DDTZ), loadi (über serielle Schnittstelle) und

loadi war gemeint. Ich verliere wohl langsam den Überblick.