Kurios... Wenn ich loadf (DDTZ) lade, mit mw 3 1 auf ASCI0 umleite, bekomme ich IMMER eine Konsole in meinem 2. minicom Terminal angezeigt. Aber bei loadc klappt das offenbar nur, wenn es "kalt"? ist. Wie oben geschrieben ging es eben - jetzt nicht mehr (hilft auch kein Wackeln). Nur Datenmüll. Es bootet dann auch das CPM nicht richtig, da ich ja eine PROFILE.SUB mit Device auf USB0 drin habe - aber da kommt trotz connect auch nichts an... Es kann also nicht (nur) an der ASCI-Ausgabe liegen...
Schalte in diesem Fall mal auf 9600 Baud um, dann geht die Kommunikation wieder. Es scheint am 18,432MHz Takt zu liegen und der Takterkennung. Bei mir hat der "Full Swing Crystal Oscillator" [1] geholfen. Das Jitter ist deutlich geringer und die Amplitude direkt am Quarz höher. Ich bin mir auch nicht sicher, ob der Z180 innerhalb seiner Spezifikation betrieben wird. Den damaligen Test [2] hatte ich ja nur an zwei Mustern durchgeführt. [1] Beitrag "Re: Z180-Stamp Modul" [2] Beitrag "Re: CP/M auf ATmega88"
Marcel A. schrieb: > Aber bei loadc klappt das offenbar nur, wenn es "kalt"? ist. Wie oben Es klappt wahrscheinlich nur, wenn ddt/z vorher nicht gelaufen ist. Sorry, ich habe immer wieder vergessen das zu erwähnen. Das CP/M-BIOS initialisiert normalerweise die komplette Hardware selbst, und richtet auch eigene FIFO's im RAM ein, für die Kommunikation mit dem AVR. Damit man das BIOS mit DDT/Z debuggen kann, wird ein Teil der Init ausgelassen, wenn das BIOS feststellt, das der Debugger läuft. Sonst würde der Debugger ja abgehängt. Leider klappt aber das aber noch nicht alles wie gewünscht. Wenn man nach Experimenten mit dem Debugger das CP/M starten will, sollte man z.Zt. die Address 0x38 mit 0 oder sonst irgenwas != 0x80 beschreiben. Natürlich kann man auch den ganzen Speicher löschen. Joe G. schrieb: > Ich bin > mir auch nicht sicher, ob der Z180 innerhalb seiner Spezifikation > betrieben wird. Den damaligen Test [2] hatte ich ja nur an zwei Mustern > durchgeführt. Laut Z80S180 Datenblatt[1] ist alles im grünen Bereich. [1] http://www.zilog.com/docs/z180/z8s180ps.pdf Zitat Frontpage: "Operating Range: 5V (3.3V@ 20 MHz)"
Angehängte Dateien:
-
USB.jpg
82 KB
Hier eine kleine Hardwarespielerei, USB an CP/M :-) USB1 ist jedoch kein echtes CP/M Laufwerk, sondern wird über ein kleines Zusatzprogramm gehändelt. USB1:\> Dir FTRFB.FTD MC-MOD00.INC MC-MOD01.INC MC-MOD02.INC MC-MOD03.INC MC-MOD04.INC MC-MOD05.INC READ.ME TINST.COM TINST.DTA TINST.MSG TP3.DSK TURBO.COM TURBO.MSG TURBO.OVR USB1:\> IDD USB VID = $1221 USB PID = $3234 Vendor Id = USB Product Id = Disk Revision Level = 2.60 I/F = SCSI FAT16 Bytes/Sector = $0200 Bytes/Cluster = $000800 Capacity = $07ABE000 Bytes Free Space = $ Bytes USB1:\>
Ah, Urlaubszeit vorbei :-) In den Feengrotten war ich auch schon bei unserem Harz-Urlaub... Dass die auch USB Sticks hatten? Nun, kannst du etwas mehr über die Verbindung sagen? Da ist ja dieses von dir schon mal erwähnte Zwischenmodul im Einsatz... USB file system auf seriell glaube ich? Gruß Marcel
Marcel A. schrieb: > Ah, Urlaubszeit vorbei :-) Nein, nur die Prüfungszeit ;-) > Dass die auch USB Sticks hatten? Das obligatorische Gruppenbild wird als Stick ausgegeben. > Nun, kannst du etwas mehr über die Verbindung sagen? In meiner Schaltung ist derzeit in VNC1-L, ein USB Host Controller. Allerdings gibt es dafür schon eine Nachfolgevariante, den VNC2. Dieser ist auch preislich (ca 2,5€/Stück) und gehäusetechnisch interessanter. Für unsere Anwendung würde der VNC2-32L1B ausreichen. Da ich jedoch nur die erste Variante hatte, habe ich damit gebastelt. Der Controller stellt ein recht umfangreichen USB-Host zur Verfügung u.a. auch ein FAT16 und FAT32 Filesystem. Die Ansteuerung erfolgt über SPI oder UART. Derzeit habe ich auf einem AVR einen kleinen Befehlsinterpreter für einfache Kommandos und sende das Ergebnis dann über die UART. Unter CP/M gibt es nur ein Programm welches diese Kommandos ausführt. CP/M selbst sieht also das USB Filesystem nicht. Mit diesem Programm können jedoch Daten zwischen USB und dem CP/M Filesystem ausgetauscht werden. Wie das endgültig werden soll, da hab ich noch keine Idee. Vielleicht hat ja jemand einen Vorschlag dazu. Im nächsten schritt würde ich erst mal eine VNC2 Hardware fädeln und die auch zum Laufen bringen.
Z80 + Vinculumhardware gab es schon mal hier: http://susowa.homeftp.net/index.php/hardware-mainmenu/hardware-module-mxxx-mainmenu-50/197-netzwerk-und-usb-modul-m052.html Dort wird der Chip via PIO-Port angebunden. Vielleicht mal nach der Software fragen, dort erfolgt der Zugriff vom CP/M aus über die USB-TOOLS: http://susowa.homeftp.net/index.php/projekte-mainmenu/usb-mainmenu-131/193-usb-tools-12-cpm.html Viele Grüße, Jens
Marcel A. schrieb: > Wie ist eigentlich der Stand des Basis-Boards? Da Board ist in der Fertigung, die Lieferung wird in der kommenden Woche erfolgen. Dann bestücke und teste ich es und wenn alles ok ist, kann die Sammelbestellung erfolgen. Jens schrieb: > dort erfolgt der Zugriff vom CP/M aus über die USB-TOOLS: Die derzeitige Versuchsvariante steuert den VNC1 über SPI an und stellt dem Nutzer einen kleinen Monitor über V24 zur Verfügung. Wenn die VNC2 IC’s da sind, kommen die auf eine kleine Platine die pinkompatibel mit den USB-Adaptern des ECB-Boards sind. Dann kann zwischen RS232, RS232-USB und USB-Stick gewählt werden. Die Versuchssoftware ist derzeit so ähnlich wie KERMIT. Man startet das USBKERMIT und kann dann auf den USB-Stick zugreifen bzw. Dateien austauschen. Natürlich nehme ich gerne weitere Vorschläge oder Wünsche entgegen.
Hallo zusammen, ich bin gerade über SymbOS gestolpert- ein grafisches Betriebssystem a la GEOS GEM TOS / GS/OS ... bisher portiert für die Z80-Rechner CPC und MSX: http://www.symbos.de/facts.htm Dafür bräuchte man natürlich auch ordentlich Grafik - also eine "Grafik-Stamp". Diverse Lösungsansätze gibt es ja: http://tldr.fi/2014/09/27/zc160-vga-adapter1/ http://www.hanssummers.com/newz80.html Letztlich ist das im Rahmen der "myCPU" alles schon mal gemacht worden - aber wäre das nicht was? Aber wie immer übersteigt das meine Kenntnisse bei weitem :-) Ich löte gerade die VT100-Platine zusammen... Gruß Marcel
Bin bis 24.08 im Urlaub und nur sporadisch online. Vollgrafik lässt sich mit dem VT100 Modul natürlich ich realisieren. Muss nur programmiert werden:-)
> Marcel A. schrieb: >> Wie ist eigentlich der Stand des Basis-Boards? kurzer Zwischenstand @Basisbord Der Urlaub ist beendet, das Bord ist da, die Bauelemente auch. Nun muß noch bestückt werden. @USB Der Vinculum-II inc. Programmer/Debugger ist auch da. Er läßt sich programmieren und liest auch schon wieder ein USB-Stick. U:\> IDDE USB VID = $0930 USB PID = $6545 Vendor Id = TOSHIBA Product Id = TransMemory Revision Level = PMAP I/F = SCSI FAT32 Bytes/Sector = $0200 Bytes/Cluster = $004000 Capacity = $0003A1F5C000 Bytes Free Space = $ Bytes U:\>
Angehängte Dateien:
-
BUS.jpg
220 KB
@Leo Die BUS-LP scheint auf den ersten Blick fehlerfrei zu sein (keine Layoutfehler). Das System bootet mit 3.3V und Ausgabe auf Console 0. Ich habe aber noch weiteren Tests (alles auf 5V, 2. SD Card, RS232 und USB, Taktumschaltung) vorgenommen. Bei der Bestückung sollte die DUO-LED D2 gegenüber der Schaltung gedreht werden (rot/grün tauschen). Jetzt leuchtet rot bei RUN und grün bei HALT.
Joe G. schrieb: > @Leo > Die BUS-LP scheint auf den ersten Blick fehlerfrei zu sein (keine > Layoutfehler). Ich nehme eine!
OK, notiert. Interessenten bitte melden. Bis zum endgültigen Bestelltermin würde ich jedoch gerne noch die Inbetriebnahme von Leo C. abwarten um tatsächlich alle Fehler auszuschließen. Vier Augen sehen mehr als 2 ;-)
Moin Joe, bin mit einer Basis-Platine dabei. Gruss Peter ps: gibt es eine BOM zur Basis-Platine?
Hallo, - ist es geplant, mehr als 4 disk images zu unterstützen? - kennt jemand ein nettes GUI für die cpmtools? das Zusammenstellen auf der Kommandozeile (linux) ist doch recht aufwendig - hat schon mal jemand filecommander (FC) unter cp/m probiert? Gruß Marcel
Marcel A. schrieb: > - ist es geplant, mehr als 4 disk images zu unterstützen? Ja, natürlich. Es ist auch ein besserer Mechanismus zum "mounten" der Images geplant. Die Zuordnung über die Environment-Variablen ist doch etwas umständlich, und war und ist nur als Provisorium gedacht. Wenn Du dringenden Bedarf hast, kann ich das Provisorium aber auf mehr Laufwerke umstellen. > - kennt jemand ein nettes GUI für die cpmtools? das Zusammenstellen auf > der Kommandozeile (linux) ist doch recht aufwendig Meinst Du jetzt für Windows, oder wie soll man das verstehen? http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2 > - hat schon mal jemand filecommander (FC) unter cp/m probiert? Und was wäre wenn?
Nein, für Linux. Die TC Erweiterum kannte ich, hilft aber nicht. Wie handhabst du denn effektiv das Erstellen von DSK-Files? Zum FC, mich würden Erfahrungen zu PIP Alternativen interessieren.
Marcel A. schrieb: > Nein, für Linux. Die TC Erweiterum kannte ich, hilft aber nicht. > Wie handhabst du denn effektiv das Erstellen von DSK-Files? Effektiv, im Sinne von effizient oder so, wahrscheinlich garnicht. ;-) Über die Jahre hat sich eine Anzahl Karten mit Images hier angesammelt, die ich zum Testen nehme. Die Images kann man ja auch einfach zwischen Karten (und Festplatte) hin und her kopieren. Nur selten muß ich etwas in einem Image ändern. Den cpmtools-Befehl dazu finde ich dann oft im Historybuffer der Shell. Allerdings wäre es auch oft schneller gewesen, den Befehl neu zu schreiben, anstatt ewig in der History zu suchen, und dann einen alten Befehl zu editieren... > Zum FC, mich würden Erfahrungen zu PIP Alternativen interessieren. Und was hindert die daran, sie zu machen?
Ich habe den FC von Heiko (den meinst Du doch, oder) mal auf dem AVR-CPM ausprobiert. Aber die Darstellung war nicht zu gebrauchen. Möglichweise kann man da noch was konfigurieren. Alternativ kann man mit dem Terminal einen PC1715 emulieren. Aber das ging mir dann etwas zu weit. Jens
Joe G. schrieb: > Vier Augen sehen mehr als 2 ;-) Und so haben wir jeder noch einen Layoutfehler entdeckt. Nicht auszumalen, wenn es 10 Betatester gegeben hätte ;-) Bei mir laufen nun alle Baugruppen fehlerfrei. Beide SD-Karten, wahlweise V24 oder USB, Run/Step und CLK auf Quarz oder AVR. Die beiden Layoutfehler korrigiere ich Anfang nächster Woche (bin ab jetzt bis Sonntag unterwegs). Peter Z. schrieb: > ps: gibt es eine BOM zur Basis-Platine? bitteschön Marcel A. schrieb: > - hat schon mal jemand filecommander (FC) unter cp/m probiert? Ja, ich (FC80 von Heiko Poppe). Er muss jedoch auf das jeweilige Terminal konfiguriert werden. In meinem derzeitigen VT100 System [1] muß ich noch die Sonderzeichen (Rahmendarstellung) dafür ändern. Ich nutze zum Erstellen der *.DSK Files SIMH [1] Beitrag "VT100-Terminal (VGA+PS2)"
Hallo! Ich nehme an, es ist noch nicht zu spät ;-) Ich würde auch eine Basisplatine nehmen. PS: wenn es eine Neuauflage der Stamps gibt wäre ich auch dabei! LG
Hallo Joe, bei der Basisplatine wäre ich auch gern mit von der Partie. Gruß, Wolfram
@alle Nach dem heutigen Dollarkurs wird die Busplatine 3,98€/Stück kosten. Produktionsdauer 4-7 Tage + Versandzeit aus China. Harald N. schrieb: > PS: wenn es eine Neuauflage der Stamps gibt wäre ich auch dabei! Es wird auch eine Neuauflage dazu geben. Das Z180 Modul ist schon überarbeitet. Am AVR Modul bin ich jedoch noch dran, hier ist etwas mehr zu tun.
Hallo Joe, ich nehme auch eine Basisplatine. Bei der Neuauflage der Stamps bin ich auch dabei. mfg Pitt
Hallo, nur mal so ein Gedankengang (vermutlich rauft sich Leo gleich die Haaare..). Beim AVRCPM gab es einen I2C Bus, der über Port-Addresen auch aus CPM heraus z.B. mit Turbo Pascel ansprechbar war. Wäre so etwas auch mit dem STAMP möglich? Kann die AVR-Stamp das wieder über Port-Mapping durchreichen? Dann könnte man darüber wieder schon "moderne" HW ansprechen. Ansonsten geht das natürlich dank echter HW auch ganz klassisch über den Adressbus und Busdekoder (74LS138 usw :-) Wäre es nicht auch möglich, einen der seriellen Anschlüsse des Z180 (ich glaube an einem hängt ja das später das Vinculum) auch z.B. mit einem AVR NetIO zu verbinden (mit passender Firmware) und damit ins Netz zu bringen? Telnet wäre dann ja kein Problem (habe das ja schon mit einem Raspi als Serial2Net-Service gemacht). Gruß Marcel
I2C Der Z80 und der AVR kommunizieren ja nur über ihren gemeinsamen RAM. Zu diesem Zwecke hat Leo Kommunikationsbefehle eingeführt. Wenn der I2C des AVR genutzt werden soll, müsste das über diesen Weg realisiert werden. Da CP/M 3 über Device die Schnittstellen verwaltet, könnte es neben ASCI0, ASCI1 und USB0 dann auch ein I2C geben. Ethernet Die Protokolle X25, TCPIP, Telnet, SMTP usw. im Z80 aufzusetzen, stelle ich mir recht aufwendig vor. Möglicherweise existieren schon ähnliche Projekte. Vielleicht ist es jedoch besser wie beim Umsetzer RS232 to USB ein IC mit diesen Implementierungen zu nutzen. Spontan fällt mir dazu der XPORT von LANTRONIX ein. Den kannst du prima für Experimente an die Erweiterungsstecker auf der Busplatine stecken.
Vielleicht wäre das eine Netzwerklösung: http://arduino-hannover.de/2014/12/11/wifi-kochbuch-mit-esp8266/ Man kann anscheinend die Firmware im esp8266 per Arduino IDE umflashen. Dazu gibt es gerade ein Projekt um den c64 ins Internet zu bringen: http://www.lemon64.com/forum/viewtopic.php?t=57035
Joe G. schrieb: > I2C > Ethernet > Die Protokolle X25, TCPIP, Telnet, SMTP usw. im Z80 aufzusetzen, stelle > ich mir recht aufwendig vor. Klar, das ist sinnlos. > Möglicherweise existieren schon ähnliche > Projekte. Vielleicht ist es jedoch besser wie beim Umsetzer RS232 to USB > ein IC mit diesen Implementierungen zu nutzen. Genau dafür ja der AVR Net-IO. Mit der firmware von Uli Radig setzt der TCP/IP(Telnet) in RS232 um, beidseitig. Oder so ein Projekt wie unten von Andreas beschrieben. Aber auch dazu gibt es Alternativen. In der CT wurde gerade ein Baustein vorgestellt, der das komplette WiFi-Thema abfrühstückt, und dann per UART, SPI usw. transparent angesprochen wird (PAN9320). Dein XPort ist ja auch so etwas. Wichtig war mir nur, dass die Idee an sich machbar ist. > Spontan fällt mir dazu > der XPORT von LANTRONIX ein. Den kannst du prima für Experimente an die > Erweiterungsstecker auf der Busplatine stecken.
Anbei die überarbeitete AVR-Stamp Version mit folgenden Änderungen: 1. vernünftiger Mico-SD-Halter (Pollin) 2. Fehler im Batteriehalter korregiert 3. RxD0 und TxD0 auf B26 bzw. B27 gelegt 4. FTDI über RESET abschaltbar 5. Stromversorgung flexibel zwischen 5V USB, extern 5V oder 3.3V Bitte mal durchsehen und Fehler, Wünsche oder Kritik äußern. Was waren die Überlegungen zu diesen Änderungen? 1. Mit der 5V Betriebsweise kann am Z80 Bus mit 5V Pegeln gearbeitet werden. 2. Ist der FTDI nicht in Betrieb kann über RxD0 und TxD0 ein externes VT100 Terminal angeschlossen werden, ohne die beiden seriellen Schnittstellen des Z180 zu blockieren. Andreas R. schrieb: > Vielleicht wäre das eine Netzwerklösung: Marcel A. schrieb: > Genau dafür ja der AVR Net-IO. Ja dann... Wer schreibt den Telnet-Client für CP/M? Ich übernehme dann gerne die Hardware :-) Nachtrag: Irgendwie war Seite 2 des PDF nicht mit dabei, hier nun die Schaltung vollständig.
Sind die Änderungen halbwegs auch auf einer bereits bestückten Platine machbar? Insbesondere der Z80-5V Bus-Betrieb und die Nutzung von RX/TX0 (also der über den AVR bereit gestellte Port) mit FTDI-Abschaltung wären nett...
Marcel A. schrieb: > Sind die Änderungen halbwegs auch auf einer bereits bestückten Platine > machbar? Ja sicher. Ich glaube Leo C. betreibt eine ähnliche Variation. 1. +3.3V auf +5V legen (Jumper auf dem Z180 Stamp) 2. Am FTDI die Verbindung von Pin 17 zu Pin 4 trennen und Pin 4 auf +5V oder 3.3V (sind ja nun +5V)legen. 3. Pin 19 auf Masse legen (Achtung (!) in dieser Stellung kann keine Firmware mehr geflasht werden) 4. Micro-SD-Card entfernen (verträgt auf keinen Fall +5V) 5. RxD0 auf B26 und TXD0 auf B27 legen.
Habs gesehen: Da ist ja nun ein Levelshifter drin vor der internen SD-Karte. Aber ohne SD-Karte wäre das ja doof. Aber auf der Basis-Platine ist ja auch eine externe SD-Karte vorgesehen - mit Level-shifter. Und so wie ich das sehe, sind die Anschlüsse parallel zur "internen" SD-Karte. Also entweder intern oder extern? Die externe SD mit Level-Shifter würde dann die Funktion der bisher internen SD übernehmen? Ansonsten muss ich das ganze Zeug noch mal aufbauen - Fluch des Early Adaptors :-)
Joe G. schrieb: > Ja dann... Wer schreibt den Telnet-Client für CP/M? Ich übernehme dann > gerne die Hardware :-) Wenn man einen Socket hat, ist Telnet doch nicht mehr so schlimm? Aber man kann ja nicht viel damit machen? SSH wäre cool.
Marcel A. schrieb: > lso > entweder intern oder extern? Die externe SD mit Level-Shifter würde dann > die Funktion der bisher internen SD übernehmen? Vielleicht war meine bisherige Erklärung nicht so eindeutig, deshalb noch mal. Die bisher aufgebauten Systeme Z180-Stamp (V1.0) und AVR-Stamp (V1.0) sind beide eigentlich für 3.3V ausgelegt. Damit gehen dann auch beide SD-Karten, die interne und die externe auf dem Basisboard. Dem Basisboard selber sind die Spannungen egal, dieses geht immer mit 3.3V oder 5V. Die derzeit überarbeiteten Versionen des Z180-Stamp (V1.1) und des AVR-Stamp (V1.1) werden neben der eigentlichen Beseitigung der Bugs auch auf 5V laufen können. Das ist jedoch nur dann von Vorteil, wenn am Z80-Bus ältere Erweiterungsschaltungen mit 5V betrieben werden (z.B. Floppy-Controler, PIO, SIO, CTC oder ähnliches). Neue Hardwareentwicklungen (Ethernet, USB, WLAN…) können natürlich gleich auf 3.3V ausgelegt werden.
Hi! Also nochmal kurz zum Zusammenfassen: - Die Busplatine ist erste Release - Die beiden Stamps kommen in einer fehlerkorrigierten Version 1.1 zwar nicht dieser Thread, aber - die VT100-Platine ist auch die fehlerkorrigierte Version 1.1 Ist das so richtig? Das SVN scheint nämlich nicht aktuell zu sein. LG
Harald N. schrieb: > Ist das so richtig? Das SVN scheint nämlich nicht aktuell zu sein. Sollte nun alles wieder aktuell sein (alle drei Platinen in der Version 1.1)
Andreas R. schrieb: > SSH wäre cool. Ein 80286 mit 12 MHz braucht etwa 4 Minuten, um den initialen Key auszurechnen. Der Server hat in der Zeit die Verbindung schon längst mit einem Timeout getrennt - vergiss es.
Joe G. schrieb: ion der bisher internen SD übernehmen? > Die bisher aufgebauten Systeme Z180-Stamp (V1.0) und AVR-Stamp (V1.0) > sind beide eigentlich für 3.3V ausgelegt. Damit gehen dann auch beide > SD-Karten, die interne und die externe auf dem Basisboard. Dem > Basisboard selber sind die Spannungen egal, dieses geht immer mit 3.3V > oder 5V. Danke dir, vielleicht muss ich mal das Brett vor dem Kopf suchen, aber so ganz habe ich es noch nicht... Wenn man beide Stamps mit 5V betreiben will, geht das ja ohne Probleme, da glaube ich alle Bausteine 5V können - bis auf die SD-Karte, richtig? Daher ist nun vor der internen SD-Karte eine Pegelanpassung, richtig? Die externe SD-Karte auf dem Basis-board bekommt auch eine Pegelanpassung, richtig? Und wenn ich den Schaltplan richtig lese, sind die interne und die externe SD an den gleichen Anschlüssen - also kann doch auch nur eine davon verwendet werden, oder? Um beim FTDI muss ich auch noch etwas beachten bei 5V-Betrieb?
Angehängte Dateien:
-
IMG_20150901_175658.jpg
76 KB
Marcel A. schrieb: > Wenn man beide Stamps mit 5V betreiben will, geht das ja ohne Probleme, > da glaube ich alle Bausteine 5V können - bis auf die SD-Karte, richtig? **** ******* Wie Du richtig siehst, können eben nicht alle Bausteine 5V. Deshalb ist es genau anders rum und 3.3V geht ohne Probleme. Jedenfalls, wenn man nur das System mit den beiden Stamp-Karten (und vielleicht noch einer zusätzlichen SD-Karte) betrachtet. Die Probleme beginnen, wenn man das System erweitern will, z.B. mit (alten) ECB-Karten über die ECB-Schnittstelle auf der Basis-Karte. Oder, wie es mir passiert ist, statt der Z180-Stamp-Karte eine CPU-Karte verwenden will, die nur 5V kann [1]. > Daher ist nun vor der internen SD-Karte eine Pegelanpassung, richtig? Damit man die AVR-Stamp auch mit 5V betreiben kann. > Die externe SD-Karte auf dem Basis-board bekommt auch eine > Pegelanpassung, richtig? Ja, aus dem gleichen Grund. > Und wenn ich den Schaltplan richtig lese, sind die interne und die > externe SD an den gleichen Anschlüssen - Bis auf die Select-Leitung (CD/SS bzw. CD/DAT3). > also kann doch auch nur eine > davon verwendet werden, oder? Nein. > Um beim FTDI muss ich auch noch etwas beachten bei 5V-Betrieb? Joe G. schrieb: > 2. Am FTDI die Verbindung von Pin 17 zu Pin 4 trennen und Pin 4 auf +5V > oder 3.3V (sind ja nun +5V)legen. Siehe Bild. Pin 4 muß gleiches Potential wie VCC am AVR haben. @Joe Auf der neuen AVR-Stamp gehört der Pullup DAT0/MISO (R4) an 3.3V, nicht an VCC. [1] Beitrag "Re: Z180-Stamp Modul"
@Joe Im Stromlaufplan der Base sind die ICs 74AHC bzw 74LV, in der BOM taucht aber auch 74AC auf. 74LV können 3,3V, 74AC 2-6V. Welche sind denn die richtigen Typen? Gruss Peter
Jetzt hab ichs... Danke. Mit den Select-Leitungen kann zwischen interner und externer SD selektiert werden - feine Sache. Ich habe halt (inzwischen) ganze Kisten mit "Z80-Hardware" hier, die ich gerne verbasteln würde - daher mein Interesse an den 5V. Wenn ich also auf die interne SD verzichte (und stattdessen die externe SD über Shifter nehme) und die Umbauanleitungen von Joe beachte für die V1.0, dann wäre das möglich. Das hier: >3. Pin 19 auf Masse legen (Achtung (!) in dieser Stellung kann keine >Firmware mehr geflasht werden) bedeutet also, dass ich mir das schaltbar machen sollte (ist im neuen Plan ein Jumper) - um zwischen VT100/RXTX0 und Programmierung umschalten zu können?
Peter Z. schrieb: > Welche sind denn die richtigen Typen? Die zweite Spalte in der BOM bezeichnet tatsächlich den verwendeten Type. Die dritte Spalte nur das Gehäuse des Device. Du solltest also wie angegeben einen AHC nehmen. Die beiden LV Bezeichnungen muss ich noch ändern (Danke). Diese Typen ergaben sich aus der reinen 3.3V Bestückung. Leo C. schrieb: > Auf der neuen AVR-Stamp gehört der Pullup DAT0/MISO (R4) an 3.3V, nicht > an VCC. Natürlich, Danke! Nachtrag zur Logikfamilie: Es scheint nicht ganz so eindeutig zu sein. Normalerweise hat die LV-Familie (Low-Voltage-CMOS) eine Betriebsspannung von 3.3V [1]. Nun geben unterschiedliche Hersteller wiederum eigene Daten dazu an [2]. Hier läuft ein 74LV74 auch mit 5V. [1] https://de.wikipedia.org/wiki/Logikfamilie [2] http://www.nxp.com/documents/data_sheet/74LV74.pdf
Kleines Update für den Stamp-Monitor. Es enthält nur kleine Änderungen in der SD-Karten-Erkennung. Wer bisher nur einen Kartensockel angeschlossen und damit keine Probleme hat, braucht das Update nicht. Der Befehlszeileneditor kennt jetzt auch die Ende-Taste. Allerdings liefern Pos1 und Ende je nach Terminal(-Emulation) unterschiedliche Codes, so daß die Tasten manchmal doch nicht funktionieren. Hier eine Liste der Editor-Funktionen und die Tastenzuordnung. Änderungen und Erweiterungen sind denkbar.
1 | Key(s) Function |
2 | ------------------------------------------------- |
3 | Pos1, HOME, CTL-a beginning-of-line |
4 | Ende, END, CTL-e end-of-line |
5 | RIGHT, CTL-f forward-char |
6 | LEFT, CTL-b backward-char |
7 | Entf, DC, CTL-d delete-char |
8 | BS, DEL, CTL-h backward-delete-char |
9 | CTL-k kill-line (cursor to end) |
10 | CTL-x, CTL-u kill-whole-line |
11 | CTL-c discard input |
12 | Einfg, IC, CTL-o toggle insert/overwrite |
13 | UP, CTL-p previous-history |
14 | DOWN, CTL-n next-history |
Tolle Erweiterung! Ich hatte nur die direkten Befehle getestet. Nach welcher Regel folgt die CTRL Syntax? WS und VI sind es nicht ;-) Aber von mir aus kann es so bleiben-
Keine Ahnung, welcher Standard das sein soll. Aber da ja alles nur geklaut ist: Ich habs von UBoot. Und dort steht im Source-Code:
1 | /*
|
2 | * cmdline-editing related codes from vivi.
|
3 | * Author: Janghoon Lyu <nandy@mizi.com>
|
4 | */
|
Die Defaulteinstellungen meiner Linux-Shell sind aber ähnlich und laut
Doku "similar to those of Emacs". Ctl-u löscht dort allerdings vom
Curser zum Zeilenanfang und Ctl-x ist ein Prefix.
> Aber von mir aus kann es so bleiben-
Ich benutze die Ctl-Tasten auch so gut wie nie. Deswegen habe ich auch
kein Problem damit, die Zuordnung zu ändern.
Angehängte Dateien:
-
Elecrow.jpg
100 KB
We have shipped your order by DHL and you should receive it in 3-5 work days. Also noch eine Woche...
Hallo, gibt es inzwischen eine Möglichkeit, die Baudraten von ASCI0 und ASCI1 im AVR-Setup einzustellen? Für DDTZ sind die glaube ich fest eingestellt und bei CP/M kann man sie (dann) über DEVICE einstellen. Wenn eh wieder einmal eine neue Firmware rauskommt, wäre ich für z.B. 8 statt 4 disk-images dankbar. Trotz 8MB wird es auf den Disketten trotz USER-Verwendung schnell unübersichtlich. Denn eine User-Einstellung bezieht sich dann auf alle Disketten, etwas lästig. Ich glaube ZDOS oder etwas vergleichbares hatte das intelligenter gelöst... Gruß Marcel
Hallo Wolfram, ich antworte dir mal hier. Einen zweiten Thread zum Aufbau halte ich nicht für sinnvoll. Das zerstückelt die vielen Informationen nur unnötigerweise. Zu deinen Fragen: Die Dokumentation wird ständig von mir ergänzt. Den aktuellen Stand findest du immer hier: https://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/ In der Doku sind die meisten deiner Fragen beantwortet. Es geht um den Bootloader, den Monitor und die darin implementierten Befehle zum Test von RAM, RTC, SD-Card, FAT usw. Auch kleine Beispiele zum z.B. zum RAM-Test sind dokumentiert. Wenn du nicht weiterkommst, einfach fragen. Gruß Jörg
Marcel A. schrieb: > gibt es inzwischen eine Möglichkeit, die Baudraten von ASCI0 und ASCI1 > im AVR-Setup einzustellen? Ich weiß nicht wie Leo C. das sieht, aber nur mit einer Baudrateneinstellung ist es ja nicht getan. Es gibt ja auch diverse Kombinationen um die E/A Geräte den unterschiedlichen Kanälen zuzuweisen [1]. Als Zwischenlösung halte ich ein kleines Programm für sinnvoll, welches des SCB-Block liest und schreibt. Dann kann mit DEVICE zunächst die persönliche Einstellung erzeugt werden, anschließend wird der SCB-Block gesichert und über PROFILE.SUB beim Start geladen. Ich las mal was von einer „Fingerübung“ :-), wie sieht es damit bei dir aus? [1] Beitrag "Re: Z180-Stamp Modul"
Angehängte Dateien:
-
P1011297.JPG
230 KB -
P1011299.JPG
240 KB
Hallo, so, ich habe mir mal bei ebay ein Terminal zugelegt (dies ist schon ein recht modernes, das 115kB kann) und über einen MAX232-Konverter an ASCI1 angeschlossen. Ein glasklares Bild :-) Komischerweise geht es bei 19200 nicht richtig. Zwar war Senden und Empfangen ok, aber die auf dem Bildschirm angezeigten Zeichen der Eingabe waren teilweise vermüllt. Ich habe NOXON eingestellt - ob sich da vielleit Zeichen auf der Schnittstelle überholen? Wie gesagt, wenn man DIR eingibt, steht auf dem Bildschirm im Promt Zeichensalat, aber nach <ENTER> erscheint das Directory... Vielleicht müsste ich da noch ein bissl in den 1000 Parametern des Terminals spielen. Die Cursor-Tasten machen auch noch nicht ganz, was sie sollen :-) Es wäre auch schön, dieses Terminal direkt an den AVR (USB0) anzuschliessen. Mit der Stamp 1.1. ist das ja vorgesehen, bei meiner 1.0 müsste ich das noch mit Draht herausführen. Gruß Marcel
Joe G. schrieb: > Marcel A. schrieb: >> gibt es inzwischen eine Möglichkeit, die Baudraten von ASCI0 und ASCI1 >> im AVR-Setup einzustellen? > > Ich weiß nicht wie Leo C. das sieht, aber nur mit einer > Baudrateneinstellung ist es ja nicht getan. Es gibt ja auch diverse > Kombinationen um die E/A Geräte den unterschiedlichen Kanälen zuzuweisen > [1]. Stimmt - da war was... > Als Zwischenlösung halte ich ein kleines Programm für sinnvoll, > welches des SCB-Block SCB - ähm... ? Ich habe zwar eine Idee, aber... > liest und schreibt. Dann kann mit DEVICE zunächst > die persönliche Einstellung erzeugt werden, anschließend wird der > SCB-Block gesichert und über PROFILE.SUB beim Start geladen. Die Reihenfolge habe ich noch nicht ganz verstanden. Zunächst kann die Geschwindigkeit der USB0 ja recht einfach in den Settings eingestellt werden (baudrate). Die Geschwindigkeiten für ASCI0/1 sind ohne CPM (also z.B. bei DDTZ) ja bislang fest vorgegeben bzw. man kann die Ausgabe natürlich wieder auf USB0 umleiten (MW 3 x). Hier wäre es schön, die Geschwindigkeit variabel einzustellen (Parameter?), das hat erst mal noch nichts mit CPM zu tun. Unter CPM klappt das mit DEVICE ja schon ganz hervorragend, das ganze noch in die PROFILE.SUB und gut. Aber da man mit DEVICE eigentlich auch nur die Zuordnung und die Baudrate einstellen kann (8,N,1 ist wohl hardcoded?) und da man eh DEVICE aufrufen muss, um die Ausgaben umzubiegen, hat ein Auslesen der Vorgaben eigentlich keinen Mehrwert. Bleibt eigentlich nur der Wunsch einer Baudraten-Einstellung unabhängig von CPM. Gruß Marcel
Ich habe mir nun RX0/TX0 vom AVR in meiner Stamp 1.0 auf B26/27 gelegt. Kann ich da nun etwas anschließen (Spannungsversorgung dann nicht über USB) oder muss ich den FTDI noch zusätzlich stilllegen?
Marcel A. schrieb: > Die Reihenfolge habe ich noch nicht ganz verstanden. CP/M Plus kennt logische Geräte und physikalische Geräte. Die logischen Geräte sind: CONIN, CONOUT, AUXIN, AUXOUT, LST. Die physikalischen Geräte sind : Keyboard, Screen, Printer, … Über den DEVICE Befehl erfolgt nun eine Zuordnung dieser Geräte, der Einstellung des Protokolls und der Übertragungsgeschwindigkeit. Im Prinzip kannst du dir das wie eine Schaltmarix vorstellen. Es sind also sehr viele Kombinationen möglich wie z.B. DEVICE CONOUT := ASCI0[XON,9600] und DEVICE CONIN := ASCI1[XON,19200]. Das Bedeutet also, dass Der Bildschirm an ASCI1 mit 19200 Baud läuft und die Tastatur an ASCO0 mit 9600 Baud. Das Protokoll bei beiden ist XON/XOFF. Um nun genau diese Vielfalt nicht einzuschränken hatte ich folgenden Vorschlag. Der Nutzer stellt einmalig seine gewünschte Kombination ein und dann wird der komplette SCB-Block mit allen Einstellungen auf dem Bootlaufwerk gesichert. Beim Neustart wird nun über PROFILE.SUB dieser Block geladen. Eine erneute Einstellung über viele DEVICE Befehle erübrigt sich dann. > so, ich habe mir mal bei ebay ein Terminal zugelegt (dies ist schon ein > recht modernes, das 115kB kann) und über einen MAX232-Konverter an ASCI1 > angeschlossen. Kann der Konverter den 3.3V Pegel tatsächlich umsetzen oder benötigt er einen 5V Pegel? Welches IC ist auf dem Konverter verbaut? > Kann ich da nun etwas anschließen (Spannungsversorgung dann nicht über > USB) oder muss ich den FTDI noch zusätzlich stilllegen? Eine Parallelschaltung der Signale geht natürlich nur bei RX. Die TX Leitungen beinhalten ja jeweils einen Ausgangstreiber. Hier muss also der FTDI über seine RESET-Leitung in den hochohmigen Zustand geschickt werden, sonst geht es nicht. Auf der gerade gelieferten Variante habe ich extra dafür einen Jumper vorgesehen. Bei Deiner Variante musst du auf der LP selbst eingreifen.
Joe G. schrieb: > Marcel A. schrieb: >> Die Reihenfolge habe ich noch nicht ganz verstanden. > > CP/M Plus kennt logische Geräte und physikalische Geräte. Die logischen > Geräte sind: > CONIN, CONOUT, AUXIN, AUXOUT, LST. Die physikalischen Geräte sind : > Keyboard, Screen, Printer, … Das war klar. > Der Nutzer stellt einmalig seine gewünschte Kombination ein und dann > wird der komplette SCB-Block mit allen Einstellungen auf dem > Bootlaufwerk gesichert. Beim Neustart wird nun über PROFILE.SUB dieser > Block geladen. Eine erneute Einstellung über viele DEVICE Befehle > erübrigt sich dann. Ich glaube, ich weiß, was du meinst. >> so, ich habe mir mal bei ebay ein Terminal zugelegt (dies ist schon ein >> recht modernes, das 115kB kann) und über einen MAX232-Konverter an ASCI1 >> angeschlossen. > > Kann der Konverter den 3.3V Pegel tatsächlich umsetzen oder benötigt er > einen 5V Pegel? Welches IC ist auf dem Konverter verbaut? Ja "Operation Voltage 3,3-5V" - ebay http://r.ebay.com/UKP424 Wobei der gelieferte etwas anders aussieht. Drauf ist ein MAX3232. > Bei Deiner Variante musst du auf der LP selbst eingreifen. Hab ich mir gedacht - mach ich.
Joe G. schrieb: > Die TX > Leitungen beinhalten ja jeweils einen Ausgangstreiber. Hier muss also > der FTDI über seine RESET-Leitung in den hochohmigen Zustand geschickt > werden, sonst geht es nicht. Man kann die TXe auch über ein AND-Logikgatter zusammenschalten. Es darf natürlich trotzdem nur einer senden, sonst gibt es Salat. BTDT. Jens
Ich hab mal ein kleines Programm zum Schreiben und Laden des I/O-Blocks im SCB gebastelt. Das Programm wird mit zwei Parametern aufgerufen. Parameter 1 ist der Dateiname für den zu sichernden Block und Parameter 2 gibt an ob die Datei gelesen oder geschrieben wird. Schreiben: scb Dateiname w Lesen: scb Dateiname r Anbei die COM und die Quelle zum Basteln ;-) Hier mal ein Beispiel wie es geht. A>scb scb.dat w A>device Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff USB0 NONE IO ASCI0 134 IOSX ASCI1 134 IOSX Current Assignments: CONIN: = ASCI0 CONOUT: = ASCI0 AUXIN: = ASCI0 AUXOUT: = ASCI0 LST: = Null Device A>device AUX:=ASCI1[XON,134] Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff USB0 NONE IO ASCI0 134 IOSX ASCI1 134 IOSX Current Assignments: CONIN: = ASCI0 CONOUT: = ASCI0 AUXIN: = ASCI1 AUXOUT: = ASCI1 LST: = Null Device A>scb scb.dat r A>device Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff USB0 NONE IO ASCI0 134 IOSX ASCI1 134 IOSX Current Assignments: CONIN: = ASCI0 CONOUT: = ASCI0 AUXIN: = ASCI0 AUXOUT: = ASCI0 LST: = Null Device A>
Prima, aber wo liegt jetzt der Vorteil gegenüber Device? Die Werte im SCB kann ich ja im AVR-Bios nicht ändern, oder?
Marcel A. schrieb: > Die Werte im SCB kann ich ja im AVR-Bios nicht ändern, oder? Nein, das Programm ändert nur im RAM des CP/M. > aber wo liegt jetzt der Vorteil gegenüber Device? Es können alle Einstellungen mit einem Befehl geändert werden.
Angehängte Dateien:
-
P1011319.JPG
170 KB -
P1011321.JPG
150 KB
So, der Umbau auf externe "USB0" hat geklappt. Ich kann nun mein Terminal direkt an RX0/TX0 anschließen - super! Auf der AVR-Stamp 1.0 habe ich mit Sekundenkleber und Fädeldraht einen Jumper zum Stillegen des FTDI untergebracht. Sobald die neue Basisplatine da ist, kann ich den Rest des 5V-Umbaus vornehmen, denn dann lässt sich bei der 1.0 ja die interne SD-Karte nicht mehr verwenden (muss externe nehmen). Schönes WE Marcel
Joe G. schrieb: > Ich hab mal ein kleines Programm zum Schreiben und Laden des I/O-Blocks > im SCB gebastelt. > Anbei die COM und die Quelle zum Basteln ;-) Sag mal, wie hast du den Quelltext so vorbildlich formatiert (alle Kommentare rechtsbündig auf 80 Zeichen)... Hast du dafür eine Routine programmiert?
Marcel A. schrieb: > So, der Umbau auf externe "USB0" hat geklappt. > > Ich kann nun mein Terminal direkt an RX0/TX0 anschließen - super! Auf > der AVR-Stamp 1.0 habe ich mit Sekundenkleber und Fädeldraht einen > Jumper zum Stillegen des FTDI untergebracht. Übrigens scheint ein Parallelbetrieb FTDI / MAX232 zu funktionieren - Eingaben und Ausgaben erscheinen sowohl auf dem Terminal als auch in Minicom/Putty - egal wo ich etwas eingebe. Ob das aber so "gesund" ist?
Marcel A. schrieb: > gibt es inzwischen eine Möglichkeit, die Baudraten von ASCI0 und ASCI1 > im AVR-Setup einzustellen? Für DDTZ sind die glaube ich fest eingestellt > und bei CP/M kann man sie (dann) über DEVICE einstellen. Die Schnittstellen sind ja im Z180 eingebaut. Deshalb müssen sie vom Programm, daß auf dem Z180 läuft programmiert werden. So ganz allgemein geht das also nicht mit dem AVR-Monitor. Für DDTZ könntest Du die Initialisierung patchen:
1 | 59 002D' initab1: |
2 | 60 002D' 01 05 00 db 1,stat1,0 ;Disable rx/tx ints, disable CTS1 |
3 | 61 0030' 01 13 08 db 1,asext1,M_BRGMOD ;Enable baud rate generator |
4 | 62 0033' 02 1C 03 00 db 2,astc1l,low 3, high 3 |
5 | 63 0037' 01 03 80 db 1,cntlb1,M_MPBT ;No MP Mode, X16 |
6 | 64 003A' 01 01 64 db 1,cntla1,M_RE+M_TE+M_MOD2 ;Rx/Tx enable, 8N1 |
7 | 65 003D' 00 db 0 |
Die Tabelle liegt nach loadf auf 2e02, der Wert, der ins Baudratenregister geschrieben wird, demnach auf 2e0a/2e0b. Die 0003, die jetzt drin stehen ergeben 115200 Baud bei 18,432 MHz CPU-Takt, bzw 57600 Baud bei 9,216 MHz. Also: => loadf => mw 2e0a "Teiler low"; mw 2e0b "Teiler high" => go 0 > Wenn eh wieder einmal eine neue Firmware rauskommt, wäre ich für z.B. 8 > statt 4 disk-images dankbar. Trotz 8MB wird es auf den Disketten trotz Wie groß ist denn der Leidensdruck? Beitrag "Re: Z180-Stamp Modul" Bis die "richtige" Lösung kommt, kann es noch dauern, zumal ich z.Zt. auf dem Propeller-Trip bin. ;)
Joe G. schrieb: > SCBPB^.Offset := $3A; { Adresse des SCB } Wo ist das denn dokumentiert? In der DR Doku finde ich überall nur:
1 | 39 - 3B | Reserved For System Use |
Ich habe es noch nicht ausprobiert, aber wenn ich das richtig verstehe, werden in SCB_In() 128 Byte ab Offset $1A über den SCB (und rarüber hinaus) geschrieben. Das wäre keine gute Idee. Z.B. müßte die Uhr dann auch auf den Zeitpunkt der letzten Sicherung zurückgestellt werden. Marcel A. schrieb: > Sag mal, wie hast du den Quelltext so vorbildlich formatiert (alle > Kommentare rechtsbündig auf 80 Zeichen)... Das ist mir auch aufgefallen. > Hast du dafür eine Routine programmiert? Oder einen Editor, bzw IDE benutzt, der/die sowas kann?
Marcel A. schrieb: > Sag mal, wie hast du den Quelltext so vorbildlich formatiert Alte Angewohnheit. Da der Monitor nur 80 Zeichen darstellt, hatte ich damals unter CP/M immer die Kommentare rechtsbündig ausgerichtet - per Hand ;-) > Ob das aber so "gesund" ist? Wie schon geschrieben, bei Rx kein Problem, bei Tx arbeiten zwei Treiber gegeneinander. Ja, ein ODER hätte es auch gelöst aber diese Variante war ja ursprünglich nicht vorgesehen. Leo C. schrieb: >> SCBPB^.Offset := $3A; { Adresse des SCB } > Wo ist das denn dokumentiert? Das habe ich hier entdeckt: http://www.cirsovius.de/CPM/cpm.html > aber wenn ich das richtig verstehe, werden in SCB_In() 128 Byte ab Offset > $1A über den SCB (und rarüber hinaus) geschrieben. Eigentlich nur genau 32 Byte um eben Datum und Uhrzeit nicht zu überschreiben. SCB_Pointer = ^SCB_Type; SCB_Type = array[0..31] of byte; { Bytefeld } Es war alles auch nur als erste Idee gedacht. Ab Addr+ $1A zu sichern ist nicht optimal. In Addr+$1B steht die aktuelle Cursorposition und die ändert sich ja ständig. Außerdem muss neben dem Bitfeld auch die Devicetable gesichert werden, das ist in dem kurzen Program auch nicht enthalten. Weiterhin sollten wahrscheinlich nach dem Rücklesen der Devicetable auch noch die Geräte neu initialisiert werden.
Joe G. schrieb: > Das habe ich hier entdeckt: > http://www.cirsovius.de/CPM/cpm.html Danke. Auf der Seite war ich auch schon öfters. Tolle Sachen. Unter anderem hat er Turbo Pascal und viele andere CP/M-Programme disassembliert. > Eigentlich nur genau 32 Byte um eben Datum und Uhrzeit nicht zu > überschreiben. > SCB_Pointer = ^SCB_Type; > SCB_Type = array[0..31] of byte; { Bytefeld } Ja, aber Du nimmst BlockRead/BlockWrite. Und bei denen ist die Recordlänge immer ein CP/M-Sector, also 128 Byte. Beim Rest Zustimmung.
Leo C. schrieb: > Ja, aber Du nimmst BlockRead/BlockWrite. Stimmt, ist durch ein typisiertes File ersetzt. Die Sicherung beginnt nun auch erst bei $1D. Wenn jemand wirklich Verwendung hätte, würde ich das Sichern der DEVTBL und der anschließenden Initialisierung noch einbauen.
Ich wollte mir gerade einen Satz Diskette (8MB Format) für die Stamp zusammenstellen, dabei bin ich drauf gestoßen, dass weder SIMH noch die Stamp das zu AVRCPM-Zeiten genutzte IMG-Format unterstützt. Da hatte ich nämlich mal eine TP301-Version, gepatcht auf VT100 und mit Unterstützung der PC-Cursor-Tasten (ESC-Codes). Hat jemand ein passendes DSK-File oder wie bekomme ich diese TP-Version rüber? CPMTOOLS?
Marcel A. schrieb: > zusammenstellen, dabei bin ich drauf gestoßen, dass weder SIMH noch die > Stamp das zu AVRCPM-Zeiten genutzte IMG-Format unterstützt. Stimmt nicht.
Joe G. schrieb: > Ab Addr+ $1A zu sichern > ist nicht optimal. In Addr+$1B steht die aktuelle Cursorposition und die > ändert sich ja ständig. Offset 1A und 1C sind die Consolenbreite und Zeilenanzahl. Die beiden wären schon interessant, da sie ja auch zu den Parametern gehören die mit DEVICE geändert werden können. Joe G. schrieb: > Stimmt, ist durch ein typisiertes File ersetzt. Die Sicherung beginnt > nun auch erst bei $1D. 1D - 21 sind RO und nicht (offiziell) dokumentiert. Da könnte Überschreiben wieder zu unerwünschten Effekten fürhren. Man wird wohl nicht umhin kommen, die interressierenden Bytes selektiv in den SCB zurück zu schreiben. Die interessanten Bytes wären imho: 1A, 1C, 22-2B, (2C), 4C-50 Oder man macht es konsequent nur für die Gerätezuordnung (22-2B), dann aber auf jeden Fall mit den Daten aus der DEVTBL. > Wenn jemand wirklich Verwendung hätte, würde ich > das Sichern der DEVTBL und der anschließenden Initialisierung noch > einbauen. Ich dachte, Du wärst derjenige gewesen, der so ein Programm haben wollte. :)
Eine meiner Ideen für eine "Erweiterungskarte" ist eine Anzeige mit kultigen 7 Segment Anzeigen aus der DDR. So im Stiele eines Microprofessors, LC80 oder HexIo. Leo hatte ja schon mal was gebaut. Was würde sich da anbieten? Eine Starre PC Anzeige, Adressbusanzeige, Datenbusanzeige? Oder etwas flexibles, was über SW (Monitor) angesprochen werden kann?
Marcel A. schrieb: > Hat jemand ein passendes DSK-File oder wie bekomme ich diese TP-Version > rüber? CPMTOOLS? Vielleicht ist es recht nützlich im SVN ein kleines Softwarearchiv mit getesteter Software und VT100-Kompatibilität anzulegen. Ich habe mal TP 3.00A als Muster eingespielt [1]. Leo C. schrieb: > Man wird wohl nicht umhin kommen, die interressierenden Bytes selektiv > in den SCB zurück zu schreiben. Ja, so sieht es wohl aus. Da ich den DEVICE-Befehl sowiso mal um die neuen Baudraten erweitern wollte, könnte er auch gleich die Save Routine mitbekommen. [1] https://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/packages/
Marcel A. schrieb: > Was würde sich da anbieten? Eine Starre PC Anzeige, Adressbusanzeige, > Datenbusanzeige? Oder etwas flexibles, was über SW (Monitor) > angesprochen werden kann? Mein Vorschlag dazu: Adress- und Datenbus + einige Status-LED. Dann könnte man über die Single-Step Logik Programme im Einzelschrittbetrieb ausführen. Als Formfaktor die Größe eines Stamp mit Pin kompatibilität. So könnte die Platine als Huckepack gesteckt werden.
Joe G. schrieb: > Als Formfaktor die Größe eines Stamp mit Pin kompatibilität. So könnte > > die Platine als Huckepack gesteckt werden. Ok - wobei bei mir Huckepack nicht funktioniert (nur Pins zum in den Sockel stecken). Ich dachte auch eher an eine Einschubkarte. Aber das schließt sich ja nicht aus. Hast du zufällig einen guten Link? Ich hatte auch schon mal gesucht und bin immer wieder auf Hinweise gestoßen, dass die "richtigen" BCD Dekoder wohl nicht mehr verfügbar sind. Es müssten ja 4 auf 10 Decoder für 7-Segment sein, oder?
Ich lese wieder über CP/M und erinnere ich mich daß ich derive für CP/M noch nicht gefunden habe... ich würde gerne vielleicht auch die alte version für DOS 3.3 die Hercules unterstützt hat, di habe ich auch nie mehr gefunden :(...
Marcel A. schrieb: > Hast du zufällig einen guten Link? Na der S100 Bus-Monitor [1] ist doch schon mal eine gute Anlaufstelle. Ansonsten BCD-7Segmentdecoder und etwas Logik. [1] http://www.s100computers.com/My%20System%20Pages/SMB%20Board/S100%20Bus%20SMB.htm
Alejandro P. schrieb: > Ich lese wieder über CP/M und erinnere ich mich daß ich derive für CP/M > noch nicht gefunden habe Vielleicht hilft dir das hier weiter... Der Vorgänger von DERIVE ist eigentlich muMATH implementiert in der Sprache muSIMP. Unter CP/M gab es also nur muMATH u.a hier [1] zu finden. [1] http://www.retroarchive.org/cpm/misc/misc.htm
Joe G. schrieb: > We have shipped your order by DHL and you should receive it in 3-5 work > days. > Also noch eine Woche... Eine chinesische Woche ;-) Nun ist das Packet in Deutschland, der Zoll möchte jetzt noch mitreden und dann... ist es hoffentlich bald hier.
Hallo, ich hatte ja berichtet, dass ich ein HP Terminal (was richtig viele Emulationen hat und 1000 Parameter kann) im VT100-Modus über einen MAX232 an USB/ASCI angeschlossen hatte. Dabei kam/kommt es immer noch zu merkwürdigen Fehlern, die ich bei Anschluss an eine PC-COM-Schnittstelle nicht habe: 1) im AVR Modus verschluckt sich die Ausgabe reproduzierbar und gibt "Müll" an der Stelle aus. Sieht man gut bei "help" oder "fatls". Im CPM Modus habe ich das auch, aber deutlich weniger. Da geht nur ganz selten ein Zeichen verloren. Experimente mit XON/XOFF haben bisher nichts gebracht. 2) im AVR- und CPM-Modus erscheinen bei langsamer Geschwindigkeit (9600/19200) auf dem Terminal bei Tastatureingaben nur "Mist" - aber es werden die richtigen Daten zur Stamp geschickt (ein DIR erscheint am Bildschirm "chinesisch" - aber nach Enter sehe ich sauber das Directory. Das habe ich bisher nur mit "hoher" Geschwindigkeit zu 99% weg bekommen. 3) Bei Verwendung der Steuertasten/Cursor (unter TP) erscheinen auf dem Bildschirm massig "ESC-Sonderzeichen" - die allerdings nicht in den Quellcode übernommen werden, also nicht gesendet werden. Dieser effekt ist deutlich geringer, wenn ich über USB0 (Also den AVR) gehe als über ASCI0/1. Bei USB0 kommt bei langsamer Tippweise nur bei jedem 3. Up/Down ein Müllzeichnen, bei links/rechts fast nie. Das habe ich bisher nur weg bekommen, indem ich im Terminal unter "Xmt Pace" 35cps eingetragen habe (statt Baud). Dann baut das Terminal "Zwangspausen" zwischen den Zeichen ein. Dann klappt alles wunderbar unter TP - auch wenn die Navigation etwas langsam ist und man schön im TP-Editor sehen kann, wie die ESC-Sequenzenin der Statusleiste verarbeitet werden. Man kann damit nun arbeiten - schön ist aber etwas anderes. Ist mein Terminal kaputt? Oder kann man am Zusammenspiel Terminal/Stamp noch etwas optimieren? Ich habe gefühlt schon 1000 Kombinationen durch. Hat da jemand eine Idee? Gruß Marcel
Angehängte Dateien:
-
LPs.jpg
110 KB
Das Bild ist nicht vom Hauptzollamt sondern von meinem Schreibtisch :-) Alle bisherigen Interessenten sollten nun eine Mail von mir haben. Wer nicht, bitte per Mail mit der gewünschten Anzahl bei mir melden. Preise incl. Versand aus China, Zoll und Einfuhrumsatzsteuer: BUS 6.10€ Z180-Stamp 3.36€ AVR-Stamp 3.36€
Etwas Off-Topic: Was für eine Entwicklungsumgebung setzt ihr für Assembler (Z180) ein? Unter CPM (Editor, Übersetzter, Linker...)? Oder Cross-Assembler? (GNU...) Und noch eine Frage: Müssten auch die Basis-Platine nicht eigentlich Bus-Treiber (245er)? In allen anderen Konzepten sind die Adress- und Daten-Schnittstellen immer darüber geführt.
Sehe ich es eigentlich richtig, dass die Z180 CPU über ASCI0 noch ein RTS Signal bereit stellt? Damit kann also ein externes Gerät mitteilen, dass gesendet werden darf oder nicht (ich bin immer noch an meinem Terminal-Problem dran). Aber unter CPM kann ich doch nur zwischen "kein Handshake" und "Soft-Handshake (XON/XOFF)" (xon, noxon) unterscheiden - RTS hilft mir da ja nicht, oder?
Marcel A. schrieb: > Sehe ich es eigentlich richtig, dass die Z180 CPU über ASCI0 noch ein > RTS Signal bereit stellt? ASCI0: RTS, CTS, DCD ASCI1: CTS > Damit kann also ein externes Gerät mitteilen, > dass gesendet werden darf oder nicht (ich bin immer noch an meinem > Terminal-Problem dran). Nein, RTS ist ein Ausgang, über den ein Gerät (hier ASCI0) mitteilt, daß es senden möchte (Request To Send). CTS und DCD sind Eingänge. CTS kann den Sendeteil steuern und DCD den Empfangsteil. > Aber unter CPM kann ich doch nur zwischen "kein Handshake" und > "Soft-Handshake (XON/XOFF)" (xon, noxon) unterscheiden - RTS hilft mir > da ja nicht, oder? Bisher ist weder Hardware- noch Software-Flow Control im BIOS. Einschalten von XON/XOFF über DEVICE nutzt also nix. Auf der Consolenschnittstelle ist XON/XOFF außerdem problematisch, da z.B. Wordstar die Steuerzeichen braucht. XON = Ctrl-Q, XOFF = Ctrl-S. Marcel A. schrieb: > Was für eine Entwicklungsumgebung setzt ihr für Assembler (Z180) ein? Schau doch mal in die Zip-Datei, die ich Dir kürzlich geschickt habe, insbesondere ins Makefile. > Und noch eine Frage: Müssten auch die Basis-Platine nicht eigentlich > Bus-Treiber (245er)? In allen anderen Konzepten sind die Adress- und > Daten-Schnittstellen immer darüber geführt. Beitrag "Re: Z180-Stamp Modul"
Ok, ich hatte mir dazu nur die Anschlüsse auf dem Basisboard angesehen. Aber wenn da im BIOS eh nichts drin ist, brauche ich mir auch keine Sorgen zu machen :-)
Bevor der Postmann zweimal klingelt, hier schon die Doku zu den unterschiedlichen Varianten der Stromversorgung. Die vollständige Doku natürlich wieder im SVN. Bei den Stamp-Modulen gibt es ja nun die Varianten V1.0 und V1.1. Die Version V1.0 ist ohne Umbau nur für den 3.3V Betrieb ausgelegt. In der Version 1.1 können beide CPU’s auch mit 5V versorgt werden. Damit ist der ECB-BUS 5V kompatibel. Eine Mischvariante geht aus verständlichen Gründen natürlich nicht. Um bei der Vielfalt nicht den Überblick zu verlieren, sind in der Doku die notwendigen Jumperstellungen aufgeführt. Im Zweifelsfall sind jedoch immer die Schaltungsunterlagen zu Rate zu ziehen.
Hallo, gibts noch freie Leiterplatten? Ich habe Interesse an einem Bus und Z180 Stamp Viele Grüße Günther
Günther S. schrieb: > gibts noch freie Leiterplatten? Ich habe Interesse an einem Bus und Z180 > Stamp Ja Günther. Für ein komplettes System sind 1 x Bus 1 x AVR-Stamp 1 x Z180-Stamp notwendig.
Ich hätte da noch 2 Fragen: Warum sind die Adress- und Datenleitungen eigentlich nicht gepuffert? In den mir bekannten Systemen (z.B. NDR Computer) sind an den Adress- und Datenleitungen 74245er Bausteine. Braucht das die Z180 Stamp nicht? Und dann bin ich über das Register OMCR gestolpert, bei dem zwischen Z80-Mode und HD64180 Mode umgeschaltet werden kann (wenn ich das richtig gelesen habe). In welchem Mode arbeiten "wir" denn? Bei 64180 würden wahrscheinlich die Timing-Diagramme aus dem Kieser nicht mehr stimmen sondern die aus dem Zilog Datenblatt?
Marcel A. schrieb: > Warum sind die Adress- und Datenleitungen eigentlich nicht gepuffert? In > den mir bekannten Systemen (z.B. NDR Computer) sind an den Adress- und > Datenleitungen 74245er Bausteine. Braucht das die Z180 Stamp nicht? Das hängt sehr davon ab, wie groß die nachfolgenden Lasten sind. In unserem Fall (erste Version) bestehen die Lasten nur aus dem CMOS-RAM und etwas Adresslogik. Das schafft die CPU auch ohne Bustreiber. Außerdem müssen die kapazitiven Lasten (Leiterlängen) beachtet werden. Auch hier gibt es keine Probleme, da alles auf recht kleinem Raum abgewickelt wird. Ein weiterer Gesichtspunkt waren die 3.3V Pegel. Da viele Bussignale bidirektional sind und wir original mit 3.3V arbeiten, hätten bidirektionale Pegelwandler eingesetzt werden müssen. Das war deutlich zu viel Aufwand. In der jetzigen 5V Variante könnte man sicherlich einen gepufferten Bus einfacher realisieren. Leider wird es dann auf der Eurokarte mit dem Platz recht knapp.
Wo liegen denn in etwa so die Grenzen? Kann man das sagen oder muss man probieren und "merkt" es dann? Oder reicht es, wenn die Peripherie-Baugruppen einen TriState Bustreiber verwenden?
Angehängte Dateien:
-
P1011337.JPG
170 KB -
P1011341.JPG
170 KB -
D345.jpg
78 KB
Hallo, im Anhang meine ersten Gehversuche / Analysen für eine Hex-Anzeige des Adress- und Datenbusses. Leider gibt es ja keine Hex-BCD Codierer für 7-Segmentanzeigen mehr (der 4511 geht nur von 0-9). Daher habe ich mir - einige TIL311 (Dekoder und Anzeige in einem) - einige D345D (passend zu meinen VEB-Anzeigen :-)) bei ebay (Osteuropa...) besorgt. Ein Arduino dient mir als Bus/Latch-Emulator. Wie man sieht, geht das soweit. Beim D345 bin ich mir nur nicht sicher hinsichtlich der Störme. Da steht in den (spärlichen) Unterlagen etwas von Konstantstromsenke 40mA. Ob das dann auch mit "modernen" 7-Segment-Anzeigen funktioniert, die deutlich weniger brauchen/vertragen? Stilecht ist das schon - aber im Sinne der Reproduzierbarkeit wird man vermutlich dafür wieder einen AVR zur Decodierung einsetzen. Dann könnte man auch gleich ein LCD nehmen, aber ich finde die Anzeigen einfach schön :-) Nun müsste ich mich mal an die Logik begeben. Meine Gedanken mit der Bitte um Korrektur: - Buspufferung mit 74HC244 (rein lesend) - Auswertung von MREQ und IORQ und RD/WD zur Erkennung von gültigem Bus-/Datentraffic (Latch) - LEDs für Signaliserung IORQ oder MREQ Vielleicht könnte man auch eine 2. Schaltung realisieren im Sinne einer "Datenanzeige" wie beim HEXIO, MPF-1 oder LC80 (wobei dort die Kodierung der Anzeigen in Software (Monitor) realisiert wird/wurde). Gruß Marcel
Joe war schneller, hier also teilweise nochmal die gleiche Antwort mit anderen Worten. Marcel A. schrieb: > Ich hätte da noch 2 Fragen: Die erste wurde weiter oben aber schon mal beantwortet. > Warum sind die Adress- und Datenleitungen eigentlich nicht gepuffert? In > den mir bekannten Systemen (z.B. NDR Computer) sind an den Adress- und > Datenleitungen 74245er Bausteine. Braucht das die Z180 Stamp nicht? 74245 was? Standard TTL (eher nicht), LS-TTL oder CMOS? Ohne jetzt bei NDR-Klein nachgeschaut zu haben, aber diese Systeme hatten oft schon viele (NMOS) Peripherie- und Speicher-Bausteine auf der CPU-Karte. Das Stamp-System besteht ausschließlich aus (wenigen) CMOS-Bausteinen. Diese belasten den Bus weniger und können gleichzeitig mehr treiben, als alte NMOS oder LS-TTL Bauteile. Wenn Du allerdings vor hast, Deinen Bus mit 15 Karten zu betreiben, würde ich Dir schon zu Puffern raten. Um dabei die volle Flexibilität des Stamp-Systems zu erhalten, müssen diese aber komplett bidirektional sein (auch Adress- und Steuerleitungen), und als Level-Shifter dienen können. (Bus 5V, Stamp 3,3V, neuerdings wahlweise auch 5V). Bei ein oder 2 zusätzlichen Karten heben die zusätzlichen Latenzen von Bustreibern ihre Vorteile wahrscheinlich wieder auf. > Und dann bin ich über das Register OMCR gestolpert, bei dem zwischen > Z80-Mode und HD64180 Mode umgeschaltet werden kann (wenn ich das richtig > gelesen habe). Es wird nur das Timing beim I/O-Lese- oder Schreibzyklus geändert. > In welchem Mode arbeiten "wir" denn? Was sagen denn die Quellen? ;-) Ich habe keine Ahnung, was da gerade eingestellt wird, aber solange keine Zilog Peripherie-Bausteine (PIO, CTC, SIO) dran hängen, spielt es keine Rolle. > Bei 64180 würden > wahrscheinlich die Timing-Diagramme aus dem Kieser nicht mehr stimmen > sondern die aus dem Zilog Datenblatt? Es stimmen immer nur die aus dem Z8S180 Datenblatt. Das Timing unterscheidet sich auch an anderen Stellen vom Original Z80. Z.B Opcode-Fetch immer in 3 statt 4 Taktzyklen. Marcel A. schrieb: > Wo liegen denn in etwa so die Grenzen? Kann man das sagen oder muss man > probieren und "merkt" es dann? Man kann es ausrechnen. Ausgangspegel, Eingangsschaltschwellen und Ströme, Leitungskapazitäten (CMOS), Schaltfrequenzen u.a. spielen eine Rolle. Was steht denn im Kieser dazu? > Oder reicht es, wenn die Peripherie-Baugruppen einen TriState Bustreiber > verwenden? Wenn die Peripheriebaugruppe auch nur aus wenigen CMOS-Bausteinen besteht, sind die Treiber dort genaus so überflüssig/kontraproduktiv wie auf der CPU-Karte.
Marcel A. schrieb: > Stilecht ist das schon - aber im Sinne der Reproduzierbarkeit wird man > vermutlich dafür wieder einen AVR zur Decodierung einsetzen. Dann könnte > man auch gleich ein LCD nehmen, aber ich finde die Anzeigen einfach > schön :-) http://picprojects.org.uk/projects/decoder7/ Wenn der Dekoder nicht so kofortabel sein muß, tuts auch ein 14-poliger µC. > Nun müsste ich mich mal an die Logik begeben. Meine Gedanken mit der > Bitte um Korrektur: > - Buspufferung mit 74HC244 (rein lesend) Falls Du die Stamp mit 3.3V betreibst, und die Anzeige mit 5V, besser HCT. Wenn Du die Bauteile noch kaufen mußt, schau Dir auch HC(T)541 an. Pinout! > - Auswertung von MREQ und IORQ und RD/WD zur Erkennung von gültigem > Bus-/Datentraffic (Latch) Muß nicht unbedingt sein. > - LEDs für Signaliserung IORQ oder MREQ RD, WR und BUSREQ sind auch eine Überlegung wert. > Vielleicht könnte man auch eine 2. Schaltung realisieren im Sinne einer > "Datenanzeige" wie beim HEXIO, MPF-1 oder LC80 (wobei dort die Kodierung > der Anzeigen in Software (Monitor) realisiert wird/wurde). Und den bestehenden Monitor im AVR magst Du nicht? ;) Er ist zugegeben noch nicht fertig. Insbesondere unterstützt er die neue Single-Step Schaltung auf der Buskarte noch nicht.
Marcel A. schrieb: > Leider gibt es ja keine Hex-BCD Codierer für 7-Segmentanzeigen mehr Wie sieht es denn mit dem V40511 aus? Verfügbar hier [1]. [1] http://www.oppermann-electronic.de/html/ic.html
Leo C. schrieb: > http://picprojects.org.uk/projects/decoder7/ > Wenn der Dekoder nicht so kofortabel sein muß, tuts auch ein 14-poliger > µC. Genau so etwas meinte ich - allerdings kenne ich mich nur mit AVR aus. Das bisschen BCD-Logik... > Wenn Du die Bauteile noch kaufen mußt, schau Dir auch HC(T)541 an. > Pinout! Guter Tipp! Da ist das Layout deutlich anwendungsfreundlicher. Aber wenn ich den Bus eh mit 5V betreibe kann ich den Treiber (siehe letztes posting) ja auch weglassen? >> - Auswertung von MREQ und IORQ und RD/WD zur Erkennung von gültigem >> Bus-/Datentraffic (Latch) > Muß nicht unbedingt sein. Ok - dachte nur, falls da doch undefinierte Zustände herrschen. Dann würden also quasi Decoder + Anzeige "direkt auf den Bus" ausreichen? > >> - LEDs für Signaliserung IORQ oder MREQ > > RD, WR und BUSREQ sind auch eine Überlegung wert. Ok > > Und den bestehenden Monitor im AVR magst Du nicht? ;) Welcher Monitor :-) Nein, schon klar. Sinnvoll / unabdingbar ist meine Idee nicht, aber dafür macht sie optisch (hoffentlich) etwas her.
Platinen sind angekommen, danke. Trotz Peters Nachfrage zur BASIS-BOM bin ich mir aber noch nicht sicher, welche ICs hier richtig sind. BOM: 1 74AHC125D 74AC125D IC1 1 74LV00D 74AC00D IC4 1 74LV74D 74AC74D IC3 also 1 x 74AHC125D aber IC 3 und 4 als LV Typ? Oder AC/AHC?
Es ist nicht ganz so simpel. Bei reinem 3.3V Betrieb, alles was für 3.3V spezifiziert ist. Also LVT, LV, LVC, ALVC, LV-A. Bei 5V Betrieb werden nur die Pegelwandler mit 3.3V versorgt und müssen dazu 5V tolerante Eingänge haben. Das sind die Familien LVT, LVC, ALVC, LV-A und ALVT. Die restlichen Logikbausteine müssen für 5V ausgelegt sein, also die Familien HC, AHC, AC, und LV-A. Nun kommt jedoch dazu, dass einige IC’s der 5V CMOS-Reihe schon ab 2V laufen, so auch der 74AHC125. Er kann nun mit 3.3V betrieben werden und hat 5V tolerante Eingänge. Jetzt kommt noch dazu, dass TI und NPX andre Typbezeichnungen haben. Ein CMOS 74LV00 von NPX arbeitet von 1.0 – 5.5V Das CMOS Äquivalent von TI nennt sich dann 74HC00. Und nun für Praktiker :-) Bei reiner 3.3V Bestückung die LVC oder LV Reihe wenn der LV-Type für 3.3V spezifiziert ist.. Bei 5V Bestückung und 3.3V für die SD-Card für den Levelshifter den 74AHC125 nehmen und für den Rest die LV Reihe.
Eine Aufbau- und Inbetriebnahmeanleitung ist für die alten Hasen die damals Weihnachten neben der Modelleisenbahn auch einen Z80 gefunden haben, nicht notwendig. Doch für alle diejenigen, die mit 76h nichts mehr anfangen können, vielleicht sehr hilfreich. Die Inbetriebnahme sollte mit den boardeigenen Mitteln durchführbar sein. Schritt 1: AVR-Stamp AVR-Stamp vollständig bestücken. Dazu gehört auch der 18.432 MHz Quarz. Die Z180 CPU leitet später ihren Takt von diesen Quarz ab. Die 5V Stromversorgung kann über die USB-Schnittstelle gewonnen werden. Die 3.3V müssen zur Inbetriebnahme noch extern zugeführt werden. Ohne die 3.3V laufen die interne SD-Card, LED1, LED2 und LED3 nicht! JP1 und JP2 entsprechend dem Handbuch stecken und den AVR Bootloader über die ISP Schnittstelle (JP4) flashen. JP3 bleibt offen. Die konkreten Fuseeinstellungen des AVR’s sind dem Handbuch zu entnehmen. USB-Schnittstelle mit dem Host verbinden. Ist der entsprechende Treiber im jeweiligen Betriebssystem installiert, erscheint nun ein zusätzlicher COM-Port. Anschließend kann die aktuelle AVR-Firmware in den AVR eingespielt werden. Start eines Terminalprogramms auf dem Host mit folgenden Einstellungen: Port: COMx Baud rate: 115200 Data: 8 bit Parity: none Stop: 1 bit Wird nun der Reset-Taster betätigt, meldet sich das Monitorprogramm mit einer Einschaltmeldung. Unter Zuhilfenahme der Monitorbefehle können nun die Funktion des RTC, der SD-Card und der Bussteuerung überprüft werden. Schritt 2: ECB-Bus Eine Bestückung des ECB-Bus Karte erleichtert die weite Inbetriebnahme, ist jedoch nicht zwingend notwendig. Achtung, Steckrichtung und Steckplatz des AVR-Stamp beachten! Zunächst kann die Funktion der zweiten SD-Card überprüft werden. Sie sollte sich äquivalent zu der internen SD-Card verhalten. An JP3 (ECB-Card) können die Taktsignale für die Z180 CPU gemessen werden. Weiterhin sollte die korrekte Funktion von /ZRESET überprüft werden. Da ohne den Z180-Stamp /HALT noch offen ist, müssen bei der DUO-LED (D2) beide Farben gleichzeitig leuchten (Mischfarbe). LED2 (WAIT) darf nicht leuchten. Das wird über den entsprechenden Monitor-Pin-Befehl realisiert. Schritt 3: Z180-Stamp Z180-Stamp bestücken. Achtung, der Z180 bekommt keinen eigenen Quarz! Die Stromversorgung kann nun wie gewünscht (5V/3.3V) über die jeweiligen Jumper gewählt werden. Abschließend wird der Z180-Stamp neben den AVR-Stamp auf den ECB-Bus gesteckt. Über das Monitorprogramm können nun die Funktionen des Z180-Stamp geprüft werden. In erster Linie betrifft das die korrekte Funktion des CMOS-RAM und der CPU. Dazu existiert eine RAM-Testroutine im Monitor. Weiterhin kann der RAM bis auf die vorletzte Speicherzelle mit 00h (NOP) beschrieben werden. Die letzte Speicherzelle erhält den Wert 76h (Halt). Wird nun die CPU ab Adresse 00h gestartet, führt sie bis zum RAM-Ende NOP Befehle aus und geht dann in den Halt (DUO-LED D2 nur rot). Auf dem Adressbus können in dieser Zeit die Adresssignale gemessen werden (verhalten sich wie Binärteiler). Damit ist der Funktionstest abgeschlossen und die weitere Inbetriebnahme wird mit dem CP/M Plus Betriebssystem vorgenommen.
Joe G. schrieb: > Z180-Stamp bestücken. Achtung, der Z180 bekommt keinen eigenen Quarz! Warum nicht? Per JP1 kann man den doch immer noch eine andere Taktquelle auswählen? Philipp
Angehängte Dateien:
-
z180_um_p11.png
84 KB
Nochmal mit kleinerem Anhang. > Per JP1 kann man den doch immer noch eine andere Taktquelle > auswählen? Aber an XTAL hängt dann immer noch das andere Ende vom Quarz und der C. Laut Datenblatt/User Manual nicht zulässig. An meiner Platine habe ich einen Sockel für den Quarz einglötet. Der Kondensator hängt dann aber immer noch an XTAL.
Leo C. schrieb: > Nochmal mit kleinerem Anhang. > >> Per JP1 kann man den doch immer noch eine andere Taktquelle >> auswählen? > > Aber an XTAL hängt dann immer noch das andere Ende vom Quarz und der C. > Laut Datenblatt/User Manual nicht zulässig. OK, aber wozu dann überhaupt JP1? Bzw. Warum nicht Jumper, die beide Leitungen trennen? Philipp P.S.: Da ich erst seit ein paar Tagen zum Z180-Stamp lese: Warum soll der Z180 den Takt vom AVR statt vom Quartz bekommen? Möglichkeit, mit unterschiedlichen Taktraten zu arbeiten?
> OK, aber wozu dann überhaupt JP1? Bzw. Warum nicht Jumper, die beide > Leitungen trennen? Anfangs waren die Möglichkeiten, die der flexible Takt vom AVR bietet noch nicht so ganz klar, und wir haben einfach mal die 2 "Bestückungsvarianten" vorgesehen. Es gab sogar die Überlegung, es genau anders rum zu machen: Z180 mit Quarz und AVR ohne. > Möglichkeit, mit unterschiedlichen Taktraten zu arbeiten? Ja genau. Der AVR kann über die Fuses so eingestellt werden, daß er seinen eigen Takt (18,432 MHz) über einen Pin ausgibt. Einige der freien Pins können aber auch über einen Timer Frequenzen bis 9,216 MHz ausgeben. Sehr flexibel und praktisch für Tests. Der Z180 hat einen Taktverdoppler, so daß er wieder auf 18,432 Mhz kommen kann. Hier ist eine Tabelle: Beitrag "Re: Z180-Stamp Modul" Man könnte auch den Monitor im AVR zum Debugger ausbauen und den Z180 dann z.B. auch mit Einzeltaktimpulsen versorgen...
Leo C. schrieb: > Man könnte auch den Monitor im AVR zum Debugger ausbauen und den Z180 > dann z.B. auch mit Einzeltaktimpulsen versorgen... Ist dieser Monitor frei? Hier im Thread werden wohl immer neue Versionen als Binärdateien gepostet, aber Quellcode sehe ich weder hier noch im stamp-svn. Philipp P.S.: Unter welcher Lizenz steht eigentlich die Busplatine?
Philipp Klaus K. schrieb: > aber Quellcode sehe ich weder hier noch im stamp-svn. Den Quellcode gibt es hier: http://cloudbase.mooo.com/cgit/z180-stamp/tree/ > P.S.: Unter welcher Lizenz steht eigentlich die Busplatine? open source hardware
Marcel hatte die Idee einer einheitlichen Frontplatte zur ECB-BUS Platine. Anbei ein Entwurf dazu. Erstellt ist die Konstruktion mit dem Frontplatten Designer. Eine Fertigung ohne Druck würde ca. 20€/Stück kosten, mit Druck 35€/Stück. Wie ist eure Meinung?
Joe G. schrieb: > Philipp Klaus K. schrieb: >> aber Quellcode sehe ich weder hier noch im stamp-svn. > > Den Quellcode gibt es hier: > http://cloudbase.mooo.com/cgit/z180-stamp/tree/ Schön, GPL v2+. >> P.S.: Unter welcher Lizenz steht eigentlich die Busplatine? > open source hardware Ist damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware (OSHW) Definition fällt", und welche genau wird später festgelegt? Philipp
In der Vergangenheit gab es wohl Sammelbestellungen für Platinen und Chips. Wird es sowas dieses Jahr nochmal geben? Philipp
Philipp Klaus K. schrieb: > st damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware > (OSHW) Definition fällt", und welche genau wird später festgelegt? Gemeint ist CC BY-NC-SA 4.0 für die Baupläne (Schaltungsunterlagen und Layout) Das sollte auch so auf den Schaltplänen verzeichnet sein. > Wird es sowas dieses Jahr nochmal geben? Das kommt auf den Bedarf an. Derzeit sieht es nicht danach aus. Es sind jedoch noch Platinen vorrätig. 2 x ECB Bus 4 x AVR-Stamp 4 x Z180-Stamp
Joe G. schrieb: > Philipp Klaus K. schrieb: >> st damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware >> (OSHW) Definition fällt", und welche genau wird später festgelegt? > > Gemeint ist CC BY-NC-SA 4.0 für die Baupläne (Schaltungsunterlagen und > Layout) Das sollte auch so auf den Schaltplänen verzeichnet sein. Beim AVR-Stamp und dem Z180-Stamp steht "CC BY-NC-SA 4.0", die sind also keine Open Source Hardware. Bei dem ECB-Board steht "open source hardware", und das Open Source Hardware Logo ist im Platinenlayout. Das Logo darf nur für Open Source Hardware verwendet werden. > >> Wird es sowas dieses Jahr nochmal geben? > Das kommt auf den Bedarf an. Derzeit sieht es nicht danach aus. Es sind > jedoch noch Platinen vorrätig. > > 2 x ECB Bus > 4 x AVR-Stamp > 4 x Z180-Stamp Wieviel würde es mich kosten, wenn ich von jeder Art eine nähme? In manchen Beiträgen dieses Threads ist ein STM32-Stamp erwähnt. Gibt es den schon? Philipp
Philipp Klaus K. schrieb: > Wieviel würde es mich kosten, wenn ich von jeder Art eine nähme? Joe G. schrieb: > Preise incl. Versand aus China, Zoll und Einfuhrumsatzsteuer: > BUS 6.10€ > Z180-Stamp 3.36€ > AVR-Stamp 3.36€ + 1.65 Porto . Kurze Mail mit deiner Adresse an mich reicht, dann sende ich dir die Platinen per Post zu.
Joe G. schrieb: > Philipp Klaus K. schrieb: >> st damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware >> (OSHW) Definition fällt", und welche genau wird später festgelegt? > > Gemeint ist CC BY-NC-SA 4.0 für die Baupläne (Schaltungsunterlagen und > Layout) Das sollte auch so auf den Schaltplänen verzeichnet sein. Nochmal nachgeschaut: "CC BY-NC-SA 4.0" steht bei den Schaltplänen für AVR-Stamp und Z180-Stamp, bei der Busplatine steht da nichts. "Open Source Hardware" und Logo stehen auf den Layouts. Aber "CC BY-NC-SA 4.0" ist nicht Open Source Hardware. Philipp
Marcel A. schrieb: > Beim D345 bin ich mir nur nicht sicher > hinsichtlich der Störme. Da steht in den (spärlichen) Unterlagen etwas > von Konstantstromsenke 40mA. Im Datenblatt steht für die Typen 345/347 eindeutig 20 mA drin, und für die 346/348 0...40 mA.
So, hier habe ich mal die Bestellnummern für Reichelt für die Basis-Platine auf Basis der oben gelisteten BOM zusammengestellt. Die ICs sollten in Absprache mit Joe für 3,3V und 5V Betrieb geeignet sein. Hinweis: - Eine passende 3mm Duo-Led gibt es dort nicht, nur 5mm. Also entweder dann alles auf 5mm LEDs oder die LED woanders (ebay) hernehmen - Den MAX3241 gibts da auch nicht - also entweder anderer Distributor oder ebay - Den SD-kartenleser entweder von Pollin oder aus China - Wofür die 2 0Ohm Widerstände an CON0/1 sind, erschließt sich mir noch nicht, sind das die gebrückten Steuerleitungen (RTS etc.)? Wenn jemand Fehler findet, bitte melden. Gruß Marcel
Joe G. schrieb: > Eine Fertigung ohne Druck würde ca. 20€/Stück > kosten, mit Druck 35€/Stück. Wie ist eure Meinung? Puh, das ist ja nicht wenig... Welche Breite hast du denn genommen bzw. was ist denn die "Standard-Breite" (vermutlich 20/40mm)? Es fehlen ja noch ein paar Bohrungen und Befestigungen - aber ist ja sicher auch erst mal nur eine Idee.
Marcel A. schrieb: > Welche Breite hast du denn genommen bzw. was ist denn die > "Standard-Breite" (vermutlich 20/40mm)? Die Frontplatte ist 3 HE und 10 TE, also 128.4 x 50.46 > Es fehlen ja noch ein paar Bohrungen und Befestigungen Welche? Eigentlich ist alles drauf.
Marcel A. schrieb: > Wofür die 2 0Ohm Widerstände an CON0/1 sind, erschließt sich mir noch > nicht, sind das die gebrückten Steuerleitungen (RTS etc.)? Der 0-Ohm Widerstand zwischen den Pins 2 und 7 ist eine Brücke zwischen DTR und DSR [siehe PDF]. Der Wannenstecker ist ja so belegt, dass ein Flachbandkabel ohne löten direkt an einen D-SUB ST 09FB passt. Die Brücke zeigt dem jeweiligen Partner nur an, dass das andere Gerät angeschlossen und generell zur Arbeit bereit ist.
Joe G. schrieb: > Marcel A. schrieb: >> Es fehlen ja noch ein paar Bohrungen und Befestigungen > Welche? Eigentlich ist alles drauf. z.B. die Löcher für die SUB-D Stecker - aber ich denke, ich mache eh ein eigenes Layout bei dem Kurs... SUB-D-Stecker (male) war ja jetzt der letzte Stand der Diskussion? Und die USB-Buchse ist wahrscheinlich als Verlängerung für die USB-Buchse auf dem AVR Stamp gedacht? RXDA/TXDA ist ja auch noch mal auf der Basis herausgeführt - vermutlich für die VT100 intern. Was macht man mit dem Anschluss "Monitor" (PG5)? Wenn einmal "Einzelschritt" unterstützt wird, ist das ja für Leos Monitor vorgesehen. Könnte man das auch über einen Taster machen? Mit einem händisch gesteuerten Takt (wie beim S100-Projekt) oder als Input für den AVR-Monitor?
Marcel A. schrieb: > z.B. die Löcher für die SUB-D Stecker Sind doch dabei, links und rechts neben dem Durchbruch für den Kelch. > SUB-D-Stecker (male) war ja jetzt der letzte Stand der Diskussion? Ein DTE, Data terminal equipment (Computer oder Terminal), bekommt einen Stecker [1]. > Und die USB-Buchse ist wahrscheinlich als Verlängerung für die > USB-Buchse auf dem AVR Stamp gedacht? RXDA/TXDA ist ja auch noch mal auf > der Basis herausgeführt - vermutlich für die VT100 intern. Ja > Was macht man mit dem Anschluss "Monitor" (PG5)? Derzeit noch nichts. Zukünftig sollen damit im Fehlerfall der EEPROM des AVR mit einer Defaulteinstellung geladen werden. > Könnte man das auch über einen Taster machen? Ja sicher, STEP auf PG0 zu legen war ja nur ein Vorschlag. [1] https://de.wikipedia.org/wiki/RS-232
Marcel A. schrieb: > So, hier habe ich mal die Bestellnummern für Reichelt für die > Basis-Platine auf Basis der oben gelisteten BOM zusammengestellt. > […] Könnte man noch dokumentieren, wozu die Teile jeweils gebraucht werden, so dass man gleich sieht, was man z.B. weglassen kann, wenn man kein Interesse an irgendwelchen Teilfunktionalitäten hat? Danke. Philipp
Ich denke, das ist schwierig, da es Abhängigkeiten gibt. Letztlich hilft da nur, die Schaltung zu verstehen (da musst ich auch durch :-) und ist bei der Basisplatine ja auch übersichtlich) und dann schauen, was man machen will. Ich wüsste bei den paar Cent aber nicht, was man weglassen sollte. Am ehesten vielleicht den MAX3241, wenn man dank USB-Seriell-Adapter auf "echte" 12V RS232 verzichten kann.
Ich stelle mir gerade auch die Teile für die neue AVR Stamp 1.1 zusammen, da ich doch gerne beide SD-Karten nutzen möchte. Den ATMEGA1281V gibts bei Reichelt nicht mehr - nur den "dickeren" ATMEGA2561V - sollte laut Unterlagen gleiches Layout haben, nur doppelte so viel Flash. Da wäre dann noch Potential für weitere Monitor-Funktionen :-). Richtig? Bei der Z180 Stamp hatten sich ja "nur" der Fehler im Layout unter der CPU und die Änderungen in den Jumpern zur Spannungsversorgung ergeben? Passendes RAM und CPU gibts bei Reichelt nicht - vielleicht ebay oder Sammelbestellung "demnächst" mal.
Beim Durchsehen der Schaltpläne ist mir aufgefallen, dass die 3,3V auf dem Z180-Modul aus den 5V erzeugt werden. Warum? Wäre das nicht eher eine Aufgabe für die Busplatine? Philipp
Philipp Klaus K. schrieb: > Warum? Vielleicht etwas Historie zum Verständnis. Nach dem AVR-CP/M System entstand der Wunsch mal wieder etwas mit einem richtigen Z80 zu machen. Dabei sollten nur heute verfügbare Bauelemente verwendet werden um den Nachbau zu erleichtern. Im Prinzip benötigt man neben CPU und Adressdecoder nur noch RAM und EPROM. Um den EPROM Anwenderfreundlich zu gestalten, wurde er durch einen AVR ersetzt, d.h. der AVR steckt als EPROM auf dem Z180. Somit ist auch die Stromversorgung auf der eigentlichen Hauptplatine (Z180). Das System ist also als Huckepackvariante ohne Busplatine vollständig lauffähig. Die Idee mit der Busplatine kam erst viel später. Da aber alles Hobby ist und alle Daten frei verfügbar sind, kann jeder letztlich damit machen was er möchte – z.B. auch die Stromversorgung auf die Busplatine bringen. Marcel A. schrieb: > Bei der Z180 Stamp hatten sich ja "nur" der Fehler im Layout unter der > CPU und die Änderungen in den Jumpern zur Spannungsversorgung ergeben? Ja korrekt, mehr ist dort nicht geändert
Joe G. schrieb: > Nach dem AVR-CP/M System entstand der Wunsch mal wieder etwas mit einem > richtigen Z80 zu machen. Bei mir wars so, daß ich danach meine fast 30 Jahre alte HD64180-Karte [0] wieder in Betrieb nehmen wollte. Das EPROM hatte ich bereits durch ein EEPROM ersetzt. Nachdem mir das aber zu umständlich wurde, und auch noch ein Serial-Port durch Netzteilprobleme zerstört wurde, hatte ich ein neues System aufgebaut, mit einem 2. HD64180, statischem RAM und einem stm32-discovery-board als EPROM-Ersatz und zum Anschluß von moderner Peripherie [1]. Schließlich hatten wir beide Systeme zusammen gelegt, wobei der stm32 bis auf weiteres unter den Tisch gefallen ist. Philipp Klaus K. schrieb: > In manchen Beiträgen dieses Threads ist ein STM32-Stamp erwähnt. Gibt es > den schon? S.o. [0] Beitrag "Re: z80 system" [1] Beitrag "Re: CP/M auf ATmega88"
Marcel A. schrieb: > Den ATMEGA1281V gibts bei Reichelt nicht mehr - nur den "dickeren" > ATMEGA2561V - sollte laut Unterlagen gleiches Layout haben, nur doppelte > so viel Flash. Sollte gehen. Aber wieso eigentlich die V-Versionen? Die sind bis 8 MHz spezifiziert, während die Versionen ohne V immerhin bis 16 MHz gehen. Allerdings auch nicht bei 3.3V ;) > Da wäre dann noch Potential für weitere > Monitor-Funktionen :-). Auch im ATmega128 sind noch ca. 45 K frei. Im Anhang ist der Versuch einer Stückliste für Bestückungsvarianten für die Busplatine. Die Bauteile in Spalte "Alle" sollten immer bestückt werden, bis auf die (x)-Teile, die auch weggelassen werden können, wenn man sie nicht braucht.
Marcel A. schrieb: > - Eine passende 3mm Duo-Led gibt es dort nicht, nur 5mm. Also entweder > dann alles auf 5mm LEDs oder die LED woanders (ebay) hernehmen Pollin hat mehrere. Ich habe die KINGBRIGHT L-93WEGW. Ob die anderen besser oder schlechter sind, kann ich nicht sagen.
Wer seine ECB-Busplatine noch nicht vollständig bestückt hat, könnte noch die folgende Erweiterung übernehmen: - CON2 (6polig) durch eine Buchse (7polig) ersetzen. Dazu muss per Hand ein weiteres Loch gebohrt werden, Platz dafür ist vorhanden. Dieses zusätzliche Pin wird dann mit /CTS0 beschaltet (Pin 18 IC2). Damit kann bei der SIO Kanal 0 später Hardware-Handshake (RTS/CTS) genutzt werden. Diese Funktion ist für die USB-Host Erweiterung notwendig.
> - CON2 (6polig) durch eine Buchse (7polig) ersetzen. > Dazu muss per Hand ein weiteres Loch gebohrt werden, Platz dafür ist > vorhanden. Gute Idee. Werde ich bei Gelegenheit wohl machen. Allerdings muß ich den zusätzlichen Pin dann einkleben. Ich habe bei mir Stift- statt Buchsenleisten eingelötet. Inzwischen habe ich mir ein paar von den USB-Serial-Adaptern mit FT323RL und 6-poliger Stiftleiste zum Testen bestellt. Im Anhang ist ein DEVICE.COM, daß die von unserem BIOS unterstützten Baudraten richtig anzeigt. Also diese hier: 150 300 600 1200 1800 2400 3600 4800 7200 9600 19200 28800 38400 57600 115200 Die Änderung ist also rein kosmetisch. Man könnte das Programm noch etwas "aufbohren", um zusätzliche Baudraten zu unterstützen. Nur welche? Über 115200 halte ich nicht für sinnvoll. Braucht jemand Baudraten unter 150? Amateurfunker vielleicht? Oder möchte jemand noch ein DATEX-P Modem betreiben?
Leo C. schrieb: > Braucht jemand Baudraten unter 150? Amateurfunker vielleicht? Grins... Nein, ich denke auch wir Funkamateure brauchen das heute nicht mehr. 300Bd Packet Radio (AX.25) haben wir vor über 20 Jahren auf Kurzwelle gemacht - heute sieht das anders aus.
Leo C. schrieb: > Im Anhang ist ein DEVICE.COM Sehr schön! Wo hast du denn eigentlich die PL/M Quelle für DEVICE her? > Allerdings muß ich den zusätzlichen Pin dann einkleben. Das ist das schwere Los der Betatester :-) > Man könnte das Programm noch etwas "aufbohren", um zusätzliche Baudraten > zu unterstützen. Nur welche? Der USB-Host schafft auch 250000 Baud.
Marcel A. schrieb: > Packet Radio (AX.25) haben wir vor über 20 Jahren auf > Kurzwelle gemacht Kein Packet Radio auf Langwelle? Joe G. schrieb: > Der USB-Host schafft auch 250000 Baud. Mit 18,432 MHz Takt könnten wir theoretisch noch 144K, 192K, 288K. Aber unter CP/M sind 115,2K ja schon mehr als schnell genug. Wenn man mit TYPE eine Datei ausgibt, schafft CP/M ca. 26,2 KBaud. Input habe ich noch nichts gemessen, dürfte aber kaum schneller verarbeitet werden können. Vielleicht kannst Du ja mal messen, auf welche effektive Datenrate der USB-Host kommt. Joe G. schrieb: > Sehr schön! Wo hast du denn eigentlich die PL/M Quelle für DEVICE her? Von "The Unofficial CP/M Web site": http://www.cpm.z80.de/source.html Daraus dann das "DEVELOPERS BUILD DIRECTORY for CP/M 3", bzw. die Unix-Version davon. Das sind die Sourcen zu den Binaries, die ich bisher schon für unser System genommen hatte und hier zu finden sind: http://www.cpm.z80.de/binary.html#operating Dort, und auf John Elliott's Site (http://www.seasip.info/index.html), von dem die Pakete stammen, findet man auch die Tools, die man zum bauen braucht. Die Quellen will ich auch in unser Repo integrieren, weiß aber noch nicht genau, in welcher Form. README von John Elliott:
1 | CP/M 3 |
2 | ====== |
3 | |
4 | This archive contains an almost complete build of CP/M 3. |
5 | |
6 | If you have the source distribution, the file making.txt explains how to |
7 | set up the build environment on your computer. |
8 | |
9 | Differences from Digital Research CP/M 3 |
10 | ======================================== |
11 | |
12 | All the CP/M 3 patches described in the document CPM3FIX.PAT have been |
13 | applied to the source code, except those to INITDIR. Patches 1-18 (except |
14 | nos. 5 and 9) were applied. |
15 | |
16 | CP/M 3 is now fully Year 2000 compliant. This affects the programs |
17 | DATE.COM, DIR.COM and SHOW.COM. |
18 | |
19 | Dates can be displayed in US, UK or Year-Month-Day format. This is set by |
20 | SETDEF: |
21 | |
22 | SETDEF [US] |
23 | SETDEF [UK] |
24 | SETDEF [YMD] respectively. |
25 | |
26 | The CCP has a further bug fix: A command sequence such as: |
27 | |
28 | C1 |
29 | :C2 |
30 | :C3 |
31 | |
32 | will now not execute the command C3 if the command C1 failed. |
33 | |
34 | What's missing? |
35 | =============== |
36 | INITDIR.COM - because it is written in PL/I and I can't make the |
37 | PL/I compiler at <http://cdl.uta.edu/cpm> compile it. |
38 | Apparently a more recent version of the compiler is |
39 | required. |
Nachtrag. PIP ist doch deutlich schneller als TYPE und schafft 51 KBaud statt 26,2K. Aufs NULL-Device schafft PIP umgerechnet ca. 97 KBaud.
Leo C. schrieb: > Vielleicht kannst Du ja mal messen, auf welche effektive > Datenrate der USB-Host kommt. Das werde ich am WE mal machen. > Von "The Unofficial CP/M Web site": Wunderbar, das ist ja eine wahre Fundquelle!
Der Geschwindigkeitstest ist erst mal ernüchternd. Bei einer Baudrate von 115200 kommen effektiv 3,1 KBaud für den Dateitransfer raus. Der USB-Host macht zwischendurch immer merkwürdige „Denkpausen“.
Gilt das für beide Richtungen? Es muß nicht alleine am USB-Host liegen. Kann auch sein, das die andere Seite das Protokoll nicht optimal implementiert hat.
Moin, bin gerade dabei, die ECB-BUS Platine aufzubauen, 3,3V. Die AVR-Stamp läuft problemlos, beide SDs, RTC ok. Im Zusammenspiel mit der Z180-Stamp gibt es beim Schreiben ins RAM ein Bus timeout. Auch das Lesen ist merkwürdig, danach ändern sich nur A0 bis A3. Schreibt man einmalig, dann ändert sich das Bitmuster in den unteren 8 Bytes und bleibt dann, auch nach neuem Schreiben. Bei der 4.2 sieht es am Anfang richtig aus oder wird da nichts ins RAM geschrieben? Bereits gemacht: ADR-Leitungen gegeneinander durchgeklingelt Clock am Jumper gemessen, ok. Daten-Leitungen gegeneinander, gegen ADR, gegen GND und 3,3V ok. alle Lötstellen geprüft und nachgelötet (speziell AVR), Z180-Stamp ist ja eher gröber. Die Platinen, Stamps, sind V1.0 Ext. 5V Netzteil Jemand ne Idee? Gruss Peter ps: sind die Widerstände der DUO-LEDs durchs Drehen der LED im Plan schon getauscht?
Hi! Ich hatte/habe dasselbe Problem mit meinen beiden V1.0 Stamps (siehe irgendwo oben hier im Thread). Ich hab bis dato den Fehler noch nicht gefunden. Also ich bin gespannt was bei dir rauskommt.
Moin Harald, danke für Deine Anteilnahme :-) Ich habe Deine Beiträge gelesen, aber es ging, glaube ich, um fliegenden Aufbau, oder? Wie sieht es denn mit der ECB aus? Wie waren Deine Read-Ausgaben? Gruss Peter
Die Bus timeouts müssen weg. Dazu muß der Z180 auf BUSREQ reagieren können, und mit BUSAK anzeigen, daß er den Bus freigegeben hat. Dazu braucht der Z180 einen Takt (scheint bei Dir der Fall zu sein), und neuerdings, seit es die Bus-Karte mit der Singlestep-Logik gibt, muß auf dieser der RUN-Pin auf low sein.
1 | => pin 8 low |
Dann sollte die WAIT-Led aus gehen. Für die Pins kann man auch Namen vergeben:
1 | => pr pin_alias |
2 | pin_alias=0:CSTART,1:SD1_CS,2:PB4,3:OC1A,4:V24_EN,5:PB7,6:SD1_CD,7:WAIT,8:RUN,9:STEP,10:PE7 |
3 | => pin |
4 | Pin Name Config Level Divider Frequency/Hz |
5 | --------------------------------------------- |
6 | 0 CSTART Pullup High |
7 | 1 SD1_CS Output High |
8 | 2 PB4 Pullup High |
9 | 3 OC1A Pullup High |
10 | 4 V24_EN Pullup High |
11 | 5 PB7 Pullup High |
12 | 6 SD1_CD Pullup Low |
13 | 7 WAIT Pullup High |
14 | 8 RUN Output Low |
15 | 9 STEP Pullup High |
16 | 10 PE7 Input High |
Ich habe den Aufbau gestapelt, mit Jumperkabeln und mit einer gefädelten Basisplatine versucht. Die neue habe ich noch nicht ausprobiert... Wenn ich mich recht erinnere kam eben manchmal dieser Fehler. Und wenn nicht war der Memread immer nur teilweise richtig, als wenn bestimmte Datenleitungen "nicht funktionierten". Allerdings waren es nie reproduzierbar die selben. Weiterhin ist beim Durchklingeln alles ok. Die AVR-Stamp allein funktioniert komplett. Weiterhin muss ich dazusagen, dass ich die Stamps schon länger nicht mehr in den Fingern hatte und ich zunächst mal die V1.1 aufbauen will wenn ich wieder mal mehr zeit habe.
Leuchtet denn die WAIT-Led bei Dir? Wenn ja, dann sollte sie nach Eingabe von: => pin 8 low ausgehen.
@Harald, ich hatte immer diese IC-Sockel-Pins im Auge, deshalb habe ich auf die ECB gewartet. Gruss Peter
@Leo, wollte erst auf eine vernünftige Idee mit der Frontplatte warten, ohne die Löcher vorher dichtzulöten. Aber ich werde die LEDs mal irgendwie dranfummeln. Gruss Peter
Bin davon ausgegangen, daß Du die LEDs dran hast. Du kannst aber auch den Pegel messen, oder den Befehl einfach so eingeben. Jedenfalls ist es so, daß der Z180 ohne den Befehl im WAIT stehen bleibt, wenn die Single-Step-Logik vorhanden ist.
Man ruiniert leicht die Duko beim häufigen raufundrunter justieren, aber ich mache das mal. Werde berichten. Gruss Peter
Angehängte Dateien:
-
duoled.png
7,9 KB
> vergessen, an welchen Anschluss muss denn nun die rote LED > der Duo-Led? Ich weiß nicht, ob wir die gleiche Platine haben. Bei mir ist in dem Bild der obere Anschluß rot und der untere grün. Rot geht über 150 Ohm an pin 13 von IC4 und grün über 270 Ohm an Pin 11. Kann sein, daß bei mir die Widerstände vertauscht sind, aber das Ergebnis sieht brauchbar aus.
Joe hatte doch mal berichtet, dass er die Led gedreht hatte, weil Run sonst Rot ist. Gruss Peter
Meine Platine hat keinen Bestückungsaufdruck. Wo der Fehler war, weiß ich nicht (mehr). Aber hier habe ich leider Mist geschrieben. Gerade nochmal nachgemessen: > Bei mir ist in dem Bild der obere Anschluß rot und der untere grün. Falsch! Grün ist oben und Rot unten. Der Rest stimmt aber: > Rot geht über 150 Ohm > an pin 13 von IC4 und grün über 270 Ohm an Pin 11. Kann sein, daß bei > mir die Widerstände vertauscht sind, aber das Ergebnis sieht brauchbar > aus. D.h. der Schaltplan, Version 1.1 ist richtig.
Leo C. schrieb: > D.h. der Schaltplan, Version 1.1 ist richtig. Korrekt, ich hatte die Farbzuordnung im Schaltplan korregiert. Die ECB-LP hat sich gegenüber der Testversion auch nur minimal geändert. Nur die LED für die externe SD ist ewas verschoben und gedreht, so dass sie besser gebogen werden kann.
@Leo Habe die DUO-LED jetzt angelötet, Rot an R9 und Grün an R8. Beim Einschalten ist die LED grün, im Monitor Betrieb rot/grün. Mit pin 8 low bleibt es so. Allerdings gibt es es beim RAM write auch kein Bus-timeout mehr und "md" zeigt jetzt die richtigen Werte. Mtest füllt ja den gesamten Speicher mit 00h und zeigt 0 errors. Die LED leuchtet grün, solange der Test läuft, dann wieder rot/grün. Dann habe ich 7FFFFh mit 76h beschrieben und mit go 0 gestartet. Die LED wird grün und bleibt grün. Scheinbar wird die 76h nicht erreicht, denn ein weiteres go 0 meldet "CPU already running". Was kann ich noch testen? Gruss Peter
In der Z180 Version 1.0 war noch ein Hardwarefehler bei RESET. Ist der behoben? Nachtrag. Versuche doch mal den Halt Befehl etwas früher in den RAM zu schreiben, z. B. In den ersten 64k RAM Bereich.
Peter Z. schrieb: > Dann habe ich 7FFFFh mit 76h beschrieben und mit go 0 gestartet. > Die LED wird grün und bleibt grün. Scheinbar wird die 76h nicht > erreicht, denn ein weiteres go 0 meldet "CPU already running". Die 7FFFF kann nicht erreicht werden. Der up läuft nur bis FFFF und fängt dann wieder bei 0 an. Grün ist dann also OK.
@Joe, Leo Reset-Änderung ist gemacht. Bei 76h in Adr FFFFh geht die CPU in Halt, LED leuchtet rot. Welche weiteren Tests soll ich machen? Gruss Peter
> Was kann ich noch testen?
Das sieht doch jetzt alles schon viel besser aus.
Du könntest z.b. mit loadf den den Debugger laden und mit g 0 starten.
Er sollte sich an ASCI1 melden. Falls Du kein Terminal an der
Schnittstelle hast, kannst Du auch zwischen laden und starten das Byte
auf Adresse 3 auf 0 setzen, und nach dem Start 'Connect' eingeben.
@Leo Bin mit Hterm auf der ser2USB Schnittstelle der AVR-Stamp. Die anderen COM-Ports muss ich noch vorbereiten. DDT läuft auch, Mem dump ging schon mal. Weitere Tests? Gruss Peter
> Weitere Tests?
Na dann freu Dich doch mal, das soweit alles zu funktionieren scheint.
Du könntest ja mal riskieren, CP/M zu starten.
@leo Ich habe jetzt mal die VT100-Platine an ASCI0 (auch an ASCI1 probiert) angeschlossen und nach Deiner Anleitung vom 16.5. CP/M3 gestartet. Allerdings kommt keine Meldung auf dem Terminal. Welche Baudrate muss ich denn einstellen, habe 4800, 9600 und 19200 probiert? Gruss Peter
Peter Z. schrieb: > Welche Baudrate muss ich denn einstellen Beide Schnittstellen sind default auf 19200 Baud eingestellt [1]. Die VT100 Software ist jedoch auf 115200 Baud eingestellt. Wenn du diese nicht geändert hast, verstehen sich beide natürlich nicht ;-) Außerdem gibt es seit dem 16.05 auch ein neues BIOS. Vielleicht gibt Leo ja auch bald die ganz neue Version mit integriertem Handshake 'offiziell' frei ;-) [1] Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff USB0 NONE IO ASCI0 19200 IOSX ASCI1 19200 IOS Current Assignments: CONIN: = ASCI0 CONOUT: = ASCI0 AUXIN: = ASCI0 AUXOUT: = ASCI0 LST: = Null Device
Ich habe jetzt mal getestet, ob ASCI0 und ASCI1 überhaupt gehen. Dazu habe ich DDT/Z über ASCI1 ADR 3,02 115200 Baud ans VT100 ausgegeben, ok. DDT/Z über ASCI0 ADR 3,01 19200 Baud VT100 auch ok. VT100 19200 Baud an ASCI0, neues Bios geladen, go FA00 --> keine Ausgabe auf das VT100. Gruss Peter
Peter Z. schrieb: > go FA00 --> keine Ausgabe auf das VT100. Das BIOS startet an Adr: 0xCD00 Du kannst jedoch die Startadresse automatisch ermitteln und dann mit dieser Adresse starten. bootcmd=reset; loadc; run run_step; go ${startaddress} Außerdem sollte cpm3_commonbase=F000 sein.
Leo C. schrieb: > Gilt das für beide Richtungen? Eine Datei von CP/M auf den USB-Stick schieben dauert ca. 12,3 KBbaud. In die andere Richtung schaffe ich jetzt etwa die gleiche Geschwindigkeit.
@Joe, ich habe mal die env geändert, bekomme aber eine Fehlermeldung. Hier mal die env und die Fehlermeldung. printenv baudrate=115200 bootcmd=reset; loadc; run run_step; go $(startaddress) bootdelay=3 cpm3_commonbase=F000 cpm3_file=1:/cpm3.sys dsk0=1:/cpm3test.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=d100 Environment size: 242/1597 bytes ## Error: "run_step" not defined Command failed, result=1 Gruss Peter
> bootcmd=reset; loadc; run run_step; go $(startaddress)
^^^^^^^^^^^^^
Was soll das denn bezwecken?
Hatte Joe so gepostet, da ich keine Ausgabe auf dem VT100 habe. Siehe weiter oben.
Joe G. schrieb: > Beide Schnittstellen sind default auf 19200 Baud eingestellt Und die CP/M Console ist auf ASCI0. Das hat leider ein paar mal gewechselt, aber bei den letzten BIOS-Versionen ist es so. Die Console sollte eigentlich auf ASCI1 sein. > Vielleicht gibt Leo ja auch bald die ganz neue Version mit integriertem > Handshake 'offiziell' frei ;-) Es gibt eine Testversion mit fest eingebautem RTS/CTS Flow-Control für ASCI0. Ich bin dabei, Flow-Control für Senden und Empfangen getrennt einschaltbar zu machen. Auch die anderen Parameter (7/8 Datenbits, Stopbits, Parity, XON/XOFF für beide Richtungen) sollen konfigurierbar werden. Soweit möglich, natürlich für beide Schnittstellen. Wenn das alles mal drin ist, wird es wieder eine Version geben. Leider komme ich z.Zt. kaum von der Stelle. Kann also noch etwas dauern. Joe G. schrieb: > Eine Datei von CP/M auf den USB-Stick schieben dauert ca. 12,3 KBbaud. > In die andere Richtung schaffe ich jetzt etwa die gleiche > Geschwindigkeit. Kann man das verwendete Protokoll irgendwo nachlesen?
@Leo Das Terminal ist mit 19200 an ASCI0. Es ging darum, die richtige Startadresse zu haben, um eine Bootmeldung am Terminal zu bekommen. Gruss Peter
> bootcmd=reset; loadc; run run_step; go $(startaddress) ^^^^^^^^^^^^^^^ Der Monitor versteht hier nur geschweifte Klammern {}. Joe hat wohl eine Environment-Variable mit Namen run_step, in der Monitor-Befehle stehen. Du kannst das auf jeden Fall weglassen. Für den Anfang kannst Du die Monitor-Befehle auch einzeln direkt eingeben, statt über bootcmd ausführen zu lassen. Wenn vorher bereits DDTZ lief, solltest Du RAM-Adresse 3F mit irgendwas != 80h füllen. Z.B. => mw 3f 0 Und dann: => loadc => go ${startaddress} Dann sollte sich auf ASCI0 CP/M melden. Nachtrag: > Es ging darum, die richtige Startadresse zu haben, um eine Bootmeldung > am Terminal zu bekommen. Die hatte Joe für das aktuelle BIOS ja auch schon genannt. Statt => go ${startaddress} kannst Du auch => go CD00 eingeben. Nur wird sich die Adresse bei der nächsten BIOS-Version wieder ändern und ist deshalb für automatisches Starten nicht geeignet.
@Leo ok, das hat schon mal geklappt. Jetzt muss ich mal mehr in die env einlesen. Gruss Peter
Peter Z. schrieb: > Jetzt muss ich mal mehr in die env einlesen. In der Dokumentation [1], Seite 15, habe ich etwas zu den Variablen geschrieben und auch zu der Startadresse. Meine Variable run_step ist tatsächlich individuell zur Steuerung der Singelstep Logik. [1] https://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/manual/?sortdir=down
Leo C. schrieb: > Kann man das verwendete Protokoll irgendwo nachlesen? Die Software für den VNC2 ist ein recht großes Paket, zu finden hier: http://www.ftdichip.com/Firmware/VNC2tools.htm Von diesem gesamten Softwarepaket habe ich die V2DAP Firmware auf dem IC installiert. Auch diese Software ist recht umfangreich. Über einem RTOS Kernel laufen u.a. der USB Host Driver, das FAT Filesystem und die UART. Das Protokoll ist jedoch recht simpel. 115200 Baud, 8N1, RTS/CTS. Um ein File zu übertragen oder ein File zu empfangen wird ein entsprechendes Kommando ausgeführt welches die exakte Anzahl der zu übermittelnden Bytes enthält. Dann legt die RTOS Software los und endet erst wenn alle Bytes übertragen oder empfangen sind. Das Binärfile wird also in einem Ruck übertragen ohne Checksumme, Prüfbyte usw... Bremsen lässt sich die Software in diesem Zustand nur noch über RTS oder CTS. Eine Firmwarebeschreibung mit allen Kommandos gibt es hier: http://www.ftdichip.com/Firmware/Precompiled/UM_VinculumFirmware_V205.pdf
Meine boootcmd sieht jetzt so aus:
setenv bootcmd 'reset; pin 8 low; loadf; mw 3f 00; loadc; go
${startaddress}'
Damit startet cpm3 bis zum cpm3-Prompt auf ASCI0 --> VT100 19200 Baud.
Kann man auch envs löschen, oder ist das erst ein Problem, wenn der
Platz auf dem EEPROM knapp wird?
@Joe
wie willst Du das mit den beiden USB-Buchsen machen?
V2DIP2-32 Platine an der Frontplatte montieren oder
eigene Platine?
Oder nur die Buchsen an der FP und die Elektronik woanders?
Ich frage deshalb, weil ich in den nächsten Tagen mal eine
FP bauen wollte.
Gruss
Peter
> Kann man auch envs löschen, oder ist das erst ein Problem, wenn der > Platz auf dem EEPROM knapp wird? Ja. => help setenv
Joe G. schrieb: > Das Binärfile wird > also in einem Ruck übertragen ohne Checksumme, Prüfbyte usw... Bremsen > lässt sich die Software in diesem Zustand nur noch über RTS oder CTS. Das läßt sich wohl kaum noch was beschleunigen. Auf CP/M-Seite möglichst große Puffer, die mit Multi-Sector-I/O gelesen/geschrieben werden. Man kann auch direkt auf die serielle Schnittstelle zugreifen, statt übers BIOS zu gehen. Aber wenn der USB-Host merkwürdige Denkpausen macht, wie Du weiter oben geschrieben hattest, nützt das alles auch nicht viel. Danke für die FTDI-Links. Ich hatt da schon mal gesucht, aber nicht das richtige gefunden.
Leo C. schrieb: > Das läßt sich wohl kaum noch was beschleunigen. Der VNC2 kennt noch einen 8 Bit FIFO-Mode. Hier sollen laut einiger Forumnutzer ca. 65 KBaud möglich sein. Vielleicht wenn ich mal viel Lust und Zeit habe ;-) Peter Z. schrieb: > Damit startet cpm3 bis zum cpm3-Prompt auf ASCI0 Mein Glückwunsch! > wie willst Du das mit den beiden USB-Buchsen machen? > V2DIP2-32 Platine an der Frontplatte montieren oder eigene Platine? Ich habe ehrlich gesagt noch keine Idee. Zunächst würde ich die Platine auf die Buchsenleiste CON2 (Console 0 – USB) stecken. Die Umschaltung (JP5) müßte jedoch manuell erfolgen. Vielleicht ist auch ein eigens Slotblech mit kleinem Umschalter sinnvoll. Dann würde nur ein Kabel auf CON2 aufgesteckt werden. Da ich noch keinen Platinenentwurf habe, bin ich für Ideen noch ganz offen.
Ich hatte mir für das 19" Rack ein kleines Mini-Servernetzteil geholt. Passt fast perfekt auf eine Europlatine und in den Rahmen. 5V 7A, 12V 2A, -12V. Leider kommen trotz Lastwiderstände 5,3V und 11V raus. Die 11V sind ja egal, werde wohl eh nie einen 6551 verwenden. Aber 5,3V? Leider kann man nichts einstellen...
Sehe ich das richtig: Im Schaltplan der Basisplatine und in der BOM sind die Werte für R8/R9 verdreht? Was ist denn richtig? Oder egal?
Geschmacksache. Wenn durch beide Dioden der gleiche Strom fließen soll, sollte der kleinere Widerstand an Grün und der größere an Rot. Bei meinem Lochrasteraufbau war damit die Mischfarbe, wenn beide Leds leuchten, für mich unbefriedigend (Rot-Grün-Sehschwäche). Mit 150 Ohm an Rot und 270 an Grün sah es für mich besser aus. Das hängt aber auch von der Led ab.
Richtig ist der Schaltplan, hier habe ich die Farbzuordnung korrekt geändert. Im BOM ist noch die alte (fehlerhafte) Zuordnung.
Leo war ein µ schneller :-) Meinen Werten lag die folgende Überlegung bei 3.3V zugrunde: rot (1.6 V Flussspannung) 7 mA - 270 Ohm grün (2.1 V Flussspannung) 8 mA - 150 Ohm
Moin! Ist eigentlich noch ein satz Platinen verfügbar, wenn ja meld ich mal gesteigertes Interesse an. Da ich hier nicht angemeldet bin mal bitte unter Random-0123 at gmx.de melden.
Bei mir klappt es auch nicht so recht.... Zunächst eine Anmerkung (vielleicht habe ich das auch überlesen): Die Beschriftung für die AVR/Z180-Stamps ist auf der ECB verkehrt herum. Wenn man die Stamps so einsetzt, dass die Schrift auf den Stamps der Schrift auf dem Basisboard entspricht, sind sie verkehrt drin. Zum Glück hatte Joe ein Bild eingestellt, so dass mir das irgendwann aufgefallen war (nix ging). Dann ist die Beschreibung / Abbildung für JP1 kritisch. Wenn man die Platine vor sich hat und dann die Jumpereinstellung auf dem Schaltplan anschaut, dann ist das auch spiegelverkehrt. Wahrscheinlich ist der Schaltplan und die Jumperbeschreibung richtig, aber der Jumper sitzt auf der Platine anders als man denkt... Tip: In der nächsten Charge einen Platinenaufdruck vorsehen :-) Nach einem Missgeschick, bei dem ich mir die USB Buchse abgerissen hatte, ging es dann weiter. Die AVR Stamp antwortet nun wie gewohnt - aber die Kommunikation zur Z180 scheint nicht zu gehen. Ich habe unten mal das bootlog angehängt. WAIT (LED2) leuchtet IMMER rot. DuoLed wechselt beim Boot von gelb nach grün. Druck auf Z-Reset bewirkt, dass die DuoLed kurz gelb und dann wieder grün ist. Dass ein Lesefehler kommt, ist komisch. Ich kann problemlos auf die SD-Karte zugreifen. Der Test mit dem mw 0 76 80000 steigt mit Bus-Fehler aus. Auf meiner Lochraster-Platine (da geht noch alles) hatte ich einen Jumper für Pin 2 (A17) nach GND. Das geht ja auch mit pin 2 low. Macht aber keinen Unterschied. Irgendwas mache ich falsch - wieso ist WAIT immer an? Hinweise: Ich habe auf der Z180 Stamp noch einen Quarz, da ich bislang diesen genutzt hatte. Aber auch wenn ich den per Jumper deaktiviere zeigt das keine Änderung
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): External. |
3 | |
4 | ATMEGA1281+Z8S180 Stamp Monitor |
5 | |
6 | ### main_loop entered: bootdelay=3 |
7 | |
8 | ### main_loop: bootcmd="reset; loadcpm3; go ${startaddress}"
|
9 | Hit any key to stop autoboot: 0 |
10 | CPU now in reset state. |
11 | z80_memfifo_init: 0, 0 |
12 | z80_memfifo_init: 1, 0 |
13 | z80_memfifo_init: 2, 0 |
14 | z80_memfifo_init: 3, 0 |
15 | Loading: '0:/cpm3+8drives.sys'... |
16 | |
17 | BNKBIOS3 SPR F900 0500 |
18 | BNKBIOS3 SPR C600 2A00 |
19 | RESBDOS3 SPR F300 0600 |
20 | BNKBDOS3 SPR 9800 2E00 |
21 | |
22 | 60K TPA |
23 | Bus timeout |
24 | Error: failed to read '0:/cpm3+8drives.sys' |
25 | Command failed, result=1 |
26 | ## Starting application at 0xc600 ... |
27 | => fatls 0: |
28 | ----A 2015/09/23 20:51 8388608 ws33.dsk |
29 | ----A 2015/09/24 19:46 8388608 basic.dsk |
30 | ----A 2015/09/23 21:05 8388608 bdsc.dsk |
31 | ----A 2015/06/12 09:14 22784 cpm3_4d.sys |
32 | ----A 2015/09/24 10:57 25600 cpm3_8d.sys |
33 | ----A 2015/09/23 22:00 25600 cpm3+8drives.sys |
34 | ----A 2015/11/11 22:51 8388608 cpm3system.dsk |
35 | ----A 2015/05/21 08:16 14548992 cpm3test.dsk |
36 | ----A 2015/09/23 20:54 8388608 dbaseii.dsk |
37 | ----A 2015/09/20 17:57 8388608 development.dsk |
38 | ----A 2015/08/27 15:49 8388608 editor.dsk |
39 | ----A 2015/06/01 16:41 8388608 kermit.dsk |
40 | ----A 2015/09/23 20:57 8388608 multiplan.dsk |
41 | ----A 2014/12/12 19:54 8388608 neu.dsk |
42 | ----A 2015/09/24 20:07 8388608 turbo3.dsk |
43 | ----A 2008/04/12 19:19 1113536 vedit.dsk |
44 | ----A 2015/09/24 14:33 8388608 mp.dsk |
45 | ----A 2015/09/24 13:58 8388608 ws.dsk |
46 | ----A 2015/09/24 14:36 8388608 ws4.dsk |
47 | 19 File(s), 133177024 bytes total |
48 | 0 Dir(s), 3720128K bytes free |
49 | => mw 0 76 80000 |
50 | Bus timeout |
51 | Command failed, result=1 |
52 | => <INTERRUPT> |
53 | => |
> WAIT (LED2) leuchtet IMMER rot. Bei mir blau. Also muß da schon mal was falsch sein. ;-) > Der Test mit dem mw 0 76 80000 steigt mit Bus-Fehler aus. Klar, wenn der Z180 den Bus nicht freigeben kann, weil er im WAIT steht. Leo C. schrieb: > und > neuerdings, seit es die Bus-Karte mit der Singlestep-Logik gibt, muß auf > dieser der RUN-Pin auf low sein. > => pin 8 low > Dann sollte die WAIT-Led aus gehen. > Irgendwas mache ich falsch - wieso ist WAIT immer an? Weil die Singlestep-Logik aktiviert ist. Wenn der Monitor wüßte, das die Busplatine mit Single-Step-Logik angeschlossen ist, könnte er den Pin 8 automatisch schalten...
Marcel A. schrieb: > Bei mir klappt es auch nicht so recht.... Schau nochmals hier: Beitrag "Re: Z180-Stamp Modul" Die Steckrichtung und die Funktion der Single-Step-Logik sind dort für die Inbetriebnahme beschrieben. Leo C. schrieb: > Wenn der Monitor wüßte, das die Busplatine mit Single-Step-Logik > angeschlossen ist, könnte er den Pin 8 automatisch schalten... JP2 (Monitor) ist ja noch ohne Funktion. Er könnte ja dem Monitor eine Mitteilung dazu machen :-) Cyclotron schrieb: > Ist eigentlich noch ein satz Platinen verfügbar Ja, es gibt noch einen Satz.
> JP2 (Monitor) ist ja noch ohne Funktion. Er könnte ja dem Monitor eine > Mitteilung dazu machen :-) Der Jumper soll aber eine andere Funktion bekommen. Man könnte auch eine Env-Varialble einrichten "Single-Step-Logik vorhanden Ja/Nein" oder so. Aber stattdessen kann man genau so gut "pin 8 low" in das Boot-Script schreiben. Vielleicht reicht es auch, die Fehlermeldung "Bus timeout" zu verbessern. Für den Fehler gibt es 2 Gründe: Der Z180 hat keinen Takt oder Wait ist aktiv. Letzteres kann der Monitor feststellen.
Hallo, ich weiß nicht ob das hier von Interesse ist. Ich habe aus alten Tagen noch eine Menge unbenutzter Chips Z8018006VSC liegen. Dazu einen Haufen Zilog Datenbücher und für Assemblerfreude das Handbuch von Rodney Zaks. Und zum guten Schluß einen Lauterbach 80 ICE für den Z80 im DIP Sockel. Mit Koffer! Ich brauche die Sachen nicht mehr. Gruß Werner
Verd.... das wars. Danke - geht 1A. Wie immer: Hätte ich (noch) mal nachgelesen hätte ich gesehen, dass ein Kollege hier schon mal das gleiche Problem hatte. Sorry!!! Ich nutze jetzt wieder den Quarz auf der Z180 stamp. Mit den Takt-Jumoerungen hadere ich noch etwas. Was ich glaube bisher verstanden zu haben: - JP1 auf der Z180 Stamp: Entweder eigener 18MHz Quarz oder externe CLK0-Leitung - JP2 auf Basisboard: Umschaltung der CLK0-Leitung zwischen ACLK0 und OCA1. - OCA1 kann vom AVR von 0,x - 9,x MHz eingestellt werden. Wie? und wie aktiviert man im Z180 dann den Taktverdoppler? - Was kommt den aus ACLK0 raus? Immer 9,x Mhz? - Die SingleStep-Logik hat nichts mit dem Takt zu tun sondern wird über das WAIT-Signal gesteuert. Warum also die Aussage, bei Basis-board-Betrieb darf auf der Z180 Stamp kein Quarz sein? Gruß Marcel
Angehängte Dateien:
-
CLKO.png
97 KB
> - OCA1 kann vom AVR von 0,x - 9,x MHz eingestellt werden. Wie? => help pin Wenn das nicht weiter hilft, frag nochmal konkreter. Dann verbessern wir den Help-Text. > und wie aktiviert man im Z180 dann den Taktverdoppler? Die Software, die auf dem Z180 gestartet wird, muß das entsprechende Bit im 'Clock Mutiplier Register' (CMR) setzen. Den BIOS-Sourcecode hast Du ja. > - Was kommt den aus ACLK0 raus? Immer 9,x Mhz? Siehe Anhang. > Warum also die Aussage, bei Basis-board-Betrieb darf auf der Z180 Stamp > kein Quarz sein? Quelle?
Leo C. schrieb: >> - OCA1 kann vom AVR von 0,x - 9,x MHz eingestellt werden. Wie? > > => help pin Stimmt :-) RTFM. Müsste man (= ich?) mal besser dokumentieren... Mal wieder gesehen, was du da tolles implementiert hast - genial. > >> - Was kommt den aus ACLK0 raus? Immer 9,x Mhz? > Siehe Anhang. Also 18,x MHz - hatte ich inzwischen auch mal gemessen. > >> Warum also die Aussage, bei Basis-board-Betrieb darf auf der Z180 Stamp >> kein Quarz sein? > > Quelle? Joe am 30.9.: "Z180-Stamp bestücken. Achtung, der Z180 bekommt keinen eigenen Quarz! " Philipp hatte ja die gleiche Frage wie ich - und offenbar KANN die Z180 CPU weiterhin den eigenen Q nehmen, aber eben auch die Versorgung vom AVR. Dafür ist ja JP1 da. Ob es auch klappt, den Z180 vom AVR zu versorgen, wenn der Z180 Quarz per Jumper nur 1-beinig dran hängt, gilt es ja noch zu testen.
> Stimmt :-) RTFM. Müsste man (= ich?) mal besser dokumentieren... Wie meinst Du das? Dokumentieren, daß man das feine Handbuch lesen soll? Vielleicht im Handbuch? > Ob es auch klappt, den Z180 vom AVR zu > versorgen, wenn der Z180 Quarz per Jumper nur 1-beinig dran hängt, gilt > es ja noch zu testen. Wird schon klappen. Aber warum willst Du überhaupt einen extra Quarz anschließen? An der Stelle sollte ich vielleicht auch mal darauf hinweisen, daß die automatische Takterkennung nicht immer zuverlässig funktioniert. Mit 18,432 oder 9,216 MHz vom AVR geht es meistens, aber mit beliebigen Quarzen am Z180 liegt die Schätzung häufig so weit daneben, das die seriellen Schnittstellen nicht mehr funktionieren, weil deren Baudrate dann zu weit daneben liegt. Die Erkennung wird man irgendwann mal verbessern müssen. Alternativ könnte der Z180 die Taktfrequenz auch aus einer Environment-Variablen auslesen...
Leo C. schrieb: > Alternativ könnte der Z180 die Taktfrequenz auch aus > einer Environment-Variablen auslesen... Das halte ich für keine so schlechte Idee!
Leo C. schrieb: . Aber warum willst Du überhaupt einen extra Quarz > anschließen? > Weil der da vorgesehen war (V 1.0 early user...) und da nun mal jetzt drauf ist :-) Aber ich habs kapiert: sinnvoller wäre entweder/oder und nicht "und" bei den Quarzen auf den STAMPs. Bisher klappte das aber alles prima mit dem Z180-Quarz.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.