Da die neue Entwicklung dem AVR CP/M etwas entrückt ist, eröffne ich einen neuen Thread für dieses Thema. Nach einigen Diskussionen habe ich das Z180-Modul nochmals überarbeitet. Es beinhaltet jetzt tatsächlich nur noch den Z180, die Takterzeugung, 3.3 V/ 5.0V und den 512 K SRAM. Weiterhin ist der komplette Z80-Bus auf den Steckverbindern. Somit sollten nunmehr die folgenden Varianten möglich sein: Z180-Stamp + EPROM Z180-Stamp + Bootprozessor (AVR, Propeller, STM32) Z180-Stamp + Bootprozessor + ECB-Bus Im nächsten Schritt folgt der Bootprozessor (AVR, STM32) als Huckepackvariante zum Z180-Stamp. Alle Unterlagen wie immer hier: http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/z180_stamp/docs/
Ich hoffe darauf, dass man sowas (spaeter) auch fertig kaufen kann...sowas kann ich leider nicht zusammenloeten :-(
Joe G. schrieb: > Nach einigen Diskussionen habe ich das Z180-Modul nochmals überarbeitet. > Es beinhaltet jetzt tatsächlich nur noch den Z180, die Takterzeugung, > 3.3 V/ 5.0V und den 512 K SRAM. Eigentlich dachte ich, die Stamp-Platine sollte für sich alleine lauffähig sein. > Z180-Stamp + EPROM Dazu müßte auf auf das Stamp-Modul eine minimale Adressdekodierlogik für das RAM, oder die EPROM-Platine müßte Busmaster-fähig sein. > Z180-Stamp + Bootprozessor (AVR, Propeller, STM32) > Z180-Stamp + Bootprozessor + ECB-Bus ECB wäre dann nochmal eine Extra-Platine? Oder eine andere Bootprozessor-Variante? Was mir besser gefallen würde: Stamp-Platine mit - Z180, RAM, Bootprozessor - RTC mit Batterie - SD-Karte - Serielle vom Bootproz auf extra Stiftleiste und/oder auf Steckerverbinder zur Trägerplatine. Evtl. auch V24- oder USB-Interface direkt auf Stamp. Im 2. Schritt dann eine "Trägerplatine" - V24/USB/RS485/sonstwas Interfaces für 2 bis 3 serielle Schnittstellen. - ECB-Bus - I/O-Ports - VGA-Terminal oder Anschluß für TFT - Netzteil - Prototyping-Area - usw. Je nach Platz und Wünschen der Benutzer. Jeder bestückt nur die Teile, die er braucht. Die Trägerplatine könnte im Europakarten-Format sein. Man könnte natürlich auch eine Lochraster-Karte nehmen (100% Prototyping-Area).
Warum nicht den eZ80F91 verwenden? Der ist aktuell, läuft mit 50 MHz, hat seine Peripherie sowie 512k Flash schon eingebaut und ist binärkompatibel zum alten Z80. Man muss nur noch RAM extern anschließen. fchk
Leo schrieb: > Eigentlich dachte ich, die Stamp-Platine sollte für sich alleine > lauffähig sein. Die unterschiedlichen Wünsche [auch meine :-) ] alle unter einen Hut zu bekommen sind immer ein Problem. Die Z180-AVR Version http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/avr_stamp/doc/ ist ja so eine Variante mit SD, USB und RTC. Leider ist das Layout nur 4-lagig zu realisieren und bei dem Wechsel auf STM32 ist ein neues Z180 Layout notwendig. Daher auch die Idee den Z180 mit SRAM einfach abzukoppeln. Der Vorteil dieser Variante ist eine übersichtliche Zweilagenplatine. Der Bootprozessor mit SD, RTC, USB, Seriell wird einfach auf den Z180 gesteckt (oder Z180 auf Bootprozessor) und dann alles auf die Trägerplatine. Dort kann dann ECB, I/O, VGA, Terminal usw. realisiert werden. Einen weiteren Vorteil sehe ich in den unterschiedlichen Bootvarianten. Es gibt ja schon Lösungen mit Propeller und AVR. Nun würde eine STM32 Lösung dazu kommen. So wie der Z80-Bus jetzt rausgeführt ist, kann der Bootprozessor den SRAM ja per DMA zum schreiben und lesen übernehmen. Die EPROM-Variante müsste dann auch Busmaster-fähig sein bzw. das Stamp-Modul hat eine Logik um für den Bootvorgang im unteren Adressbereich zunächst den ROM einzublenden. Ich glaube, diese Variante wird jedoch nur wenige Liebhaber finden. Ohne die Kosten zu sehr zu betonen, die 2x Zweilagenvariante ist auch günstiger als die 4-lagige Variante. Frank K. schrieb: > Warum nicht den eZ80F91 verwenden? > ... und ist binärkompatibel zum alten Z80. Die Binärkompatibilität reicht für CP/M leider nicht aus. Beim EZ80 liegen die internen I/O-Baugruppen leider auf festen Adressen.
Hallo, CP/M auf dem eZ80 -> http://www.shaels.net/index.php/mic80/mic80-downloads/40-original-ez80-cpm22 gruss joerg
Joe G. schrieb: > Die Binärkompatibilität reicht für CP/M leider nicht aus. Beim EZ80 > liegen die internen I/O-Baugruppen leider auf festen Adressen. Und wieso sollte das stören?? Gruss Georg
Joe G. schrieb: > Frank K. schrieb: >> Warum nicht den eZ80F91 verwenden? >> ... und ist binärkompatibel zum alten Z80. > Die Binärkompatibilität reicht für CP/M leider nicht aus. Beim EZ80 > liegen die internen I/O-Baugruppen leider auf festen Adressen. ... im IO-Adressraum (IN, OUT) "All on-chip peripheral registers are accessed in the I/O address space." Das ist völlig normal und unkritisch. Wichtig ist, dass der Memory space frei ist. fchk
Hallo Leute Warum machen wir nicht endlich mal was gescheites: STM32F4 mit 2MB Flash und 256KRAM. nUarts ne Speicherkarte dran Z80 Emulator drauf das ganze läuft mit 180Mhz Warum soll man jetzt noch ne Platine mit nem Z180 machen, das ist doch absolu überflüssig fertig.
Ich habe nun den zugehörigen AVR-Bootprozessor im SVN eingecheckt. Er hat die folgenden Funktionen: - RTC mit Batterie - SD-Karte (Micro-SD) und auf Steckverbinder zur Trägerplatine - Serielle vom Bootproz. auf Steckerverbinder zur Trägerplatine und USB Die beiden Logikgatter detektieren einen IN/OUT Befehl des Z180 im Adressbereich 40-7F. Der Z180 SRAM wird per DMA übernommen. - /BUSRQ an Z180 - warten auf /BUSAK - Datenaustausch über /RD, /WR und /MREQ - Busfreigabe Da der AVR im Gegensatz zum späteren STM32 zu wenige Pins hat, wird der Adressbus derzeit über ein Latch vergrößert. Weiterhin kann über das Adresslatch bei /IORQ die IO-Adresse vom AVR gelesen werden. Bitte die Schaltung kritisch betrachten und Hinweise und Vorschläge rückmelden.
Joe G. schrieb: > Die beiden Logikgatter detektieren einen IN/OUT Befehl des Z180 im > Adressbereich 40-7F. Und C0-FF, wenn man die A7 nicht noch mit dazu nimmt. Und leider muß man in die Decodierung zusätzlich /M1 oder /RD bzw. /WR einbeziehen, wenn in dem System auch Vector-Interrupts möglich sein sollen. (Das habe ich in meinem STM32-Entwurf auch vergessen.) > Der Z180 SRAM wird per DMA übernommen. Der ATmega1284 hat DMA? Beim STM32 funktioniert das. Am AVR wird man so wohl nur einen Int auslösen können, und die Daten dann so tranferieren: > - /BUSRQ an Z180 > - warten auf /BUSAK > - Datenaustausch über /RD, /WR und /MREQ > - Busfreigabe > Da der AVR im Gegensatz zum späteren STM32 zu wenige Pins hat, wird der > Adressbus derzeit über ein Latch vergrößert. Warum eigentlich kein AVR mit mehr Pins? > Weiterhin kann über das Adresslatch bei /IORQ die IO-Adresse vom AVR > gelesen werden. ? > Bitte die Schaltung kritisch betrachten und Hinweise und Vorschläge > rückmelden. Die Widerstände R13..R15 würde ich von der Z- Auf die A-Platine verschieben. Schließlich werden sie nur dort gebraucht, weil der Mega1284 zu wenig Adressleitungen hat. Ich würde den Takt für den AVR nicht vom Z180 nehmen. Der z180 kann den Takt halbieren oder verdoppeln, und ich weiß nicht, ob der AVR die Frequenzsprünge vertragen würde. Außerdem kann man sich leicht in den Fuß schießen, indem man den Z180 in den IDLE Mode versetzt: The oscillator keeps operating but its output is blocked to all circuitry including the PHI pin. Interessanter wärs anders rum, wenns denn gehen würde. Vorschlag zu Z180 wg. späterer Erweiterungsmöglichkeiten: - A19 auf Steckerleiste. - Zusätzliches Deselect-Signal auf der Steckerleiste vorsehen - CE am RAM dann so:
Externe Hardware (ECB) kann dann RAM auf der oberen Hälfte des 1 Mbyte großen Adressraums einblenden, aber auch an beliebigen Adressen in der unteren Hälfte (Videospeicher, alte ROM-Karten, Memory-Mapped-I/O, ...). Auch die (E)EPROM-Only Variante wäre damit möglich, falls die wirklich jemand bauen möchte. Beim Einschalten muß der z180 in einem definierten Zustand gehalten werden: --> Pulldown am Z180-/RESET. Die sonstige Reset-Beschaltung auf der Z180-Platine (Taster, C) kann entfallen, da der Z180 ja ein definiertes Reset-Signal vom AVR bekommt. Wenn am AVR noch Ports frei wären, würde ich /HALT und eine Int.-Leitung vom Z180 dort anschließen. (In meinem STM32-System habe ich /NMI genommen, aber das läßt sich in einem CP/M-System nicht sinnvoll verwenden.) Steckerleisten nochmal überdenken? - Die Int-Leitungen sollten auf den Bus. - Extra Steckerleiste für die Z180-Peripherie? - AVR-Reset (/RESETIN) auf den Bus? - SD-Karten-Signale (nicht) auf Bus?
Frank K. schrieb: > Warum nicht den eZ80F91 verwenden? Der ist aktuell, läuft mit 50 MHz, Ja, aber der Thread hier heißt leider "Z180-Stamp Modul". hal9000 schrieb: > Warum machen wir nicht endlich mal was gescheites: > STM32F4 mit 2MB Flash und 256KRAM. > nUarts ne Speicherkarte dran > Z80 Emulator drauf Überflüssig, so etwas (änliches) gibt es und habe ich schon. z.B: http://www.schorn.ch/altair.html http://yaze-ag.de/ > das ganze läuft mit 180Mhz Bei mir aktuell mit ca. 2 x 2800Mhz. > Warum soll man jetzt noch ne Platine mit nem Z180 machen, > das ist doch absolu überflüssig So gesehen stimmt das.
Leo C. schrieb: > Und C0-FF, wenn man die A7 nicht noch mit dazu nimmt. Stimmt, vielleicht sollten wir vollständig dekodieren und A7 mit hinzuziehen. > Und leider muß man in die Decodierung zusätzlich /M1 oder /RD bzw. /WR > einbeziehen, wenn in dem System auch Vector-Interrupts möglich sein > sollen. Ja, sowas gab es. Hatte ich schon fast vergessen ;-) Wenn ich mich recht erinnere wurde durch /IORQ UND /M1 angezeigt, dass der Interrupt angenommen wurde und erst dann vom Datenbus der Vektor gelesen. Da muß ich nochmal die alten Taktdiagramme rauskramen. > Der ATmega1284 hat DMA? Nein, natürlich nicht. Mit DMA meinte ich dem DMA-Zyklus des Z80. Der AVR muß dafür natürlich per Interrupt angestoßen werden. > Warum eigentlich kein AVR mit mehr Pins? Da die Pins derzeit alle ausgelastet sind macht das schon Sinn auf eine größere Variante umzusteigen, z.B. ATmega1281. Dann könnte der AVR auch den Takt für den Z180 über CLKO liefern. Leider ist er laut Datenblatt bei 3.3V nicht besonders fix (8MHz). > Die Widerstände R13..R15 würde ich von der Z- Auf die A-Platine > verschieben. Ja, ist sinnvoll. > Vorschlag zu Z180 wg. späterer Erweiterungsmöglichkeiten: > - A19 auf Steckerleiste. Ist schon darauf, liegt versteckt über D0 ;-) > - Zusätzliches Deselect-Signal auf der Steckerleiste vorsehen > - CE am RAM dann so: Ich denk mir mal was sinvolles dazu aus. > --> Pulldown am Z180-/RESET. OK > Wenn am AVR noch Ports frei wären, würde ich /HALT und eine Int.-Leitung > vom Z180 dort anschließen. Mit einem größere AVR ist ja noch Luft dafür. > Steckerleisten nochmal überdenken? > - Die Int-Leitungen sollten auf den Bus. OK > - Extra Steckerleiste für die Z180-Peripherie? Mal schauen wie günstig sie dazu liegen. > - AVR-Reset (/RESETIN) auf den Bus? OK > - SD-Karten-Signale (nicht) auf Bus? Könnte so wie Z180-Peripherie auf einen extra Stecker.
:
Bearbeitet durch User
Leo C. schrieb: > Frank K. schrieb: >> Warum nicht den eZ80F91 verwenden? Der ist aktuell, läuft mit 50 MHz, > > Ja, aber der Thread hier heißt leider "Z180-Stamp Modul". Ja na und? Wenn Du fürs gleiche Geld viel mehr Leistung bekommst, greifst Du da nicht zu? Zumal Du die gleiche Software fahren kannst. Und einen JTAG/ZPAK-Debugger gibts dafür obendrein. Oder bist Du nicht lern- und aufnahmefähig? fchk
Frank K. schrieb: > Ich habe Eval-Board, Prozessormodule und ZDI(Zilog 2-Draht JTAG > Variante)-Debugger und die ganze Doku und Software da, ich weiss, wovon > ich rede. Das war am 13.05.2010. Läuft dein CP/M inzwischen?
Joe G. schrieb: > Frank K. schrieb: >> Ich habe Eval-Board, Prozessormodule und ZDI(Zilog 2-Draht JTAG >> Variante)-Debugger und die ganze Doku und Software da, ich weiss, wovon >> ich rede. > > Das war am 13.05.2010. Läuft dein CP/M inzwischen? Ich brauchte kein CP/M, ich habe das Zilog eigene RTOS verwendet, das im erweiterten 24 bit Modus des eZ80 läuft. Ich sehe aber keinen Grund, warum CP/M nicht laufen sollte, und in einem voherigen Posting war ja ein Link zu einem CP/M für das Zilog-Demoboard enthalten. Sollte ich mal einen Überschuss an Zeit haben, kann ich das ja mal auf mein Board laden. fchk
Leo C. schrieb: > Und leider muß man in die Decodierung zusätzlich /M1 oder /RD bzw. /WR > einbeziehen, wenn in dem System auch Vector-Interrupts möglich sein > sollen. Das ist mit wenigen Standardbauelementen echt blöd aufzulösen :-( So würde es mit 1 x 7400 und 1 x 7420 gehen. AVR_INT = /( /( M1 * /A6 ) * /( M1 * A7 ) * /( IORQ ) * /( M1 * WR ) )
In meinem System mit Z80 macht ein '138 die I/O-Adressdekodierung. Die Interruptlogik geschieht mit '148 und '541.
Joe G. schrieb: > Leo C. schrieb: >> Und leider muß man in die Decodierung zusätzlich /M1 oder /RD bzw. /WR >> einbeziehen, wenn in dem System auch Vector-Interrupts möglich sein >> sollen. > > Das ist mit wenigen Standardbauelementen echt blöd aufzulösen :-( Kannst ja ein Xilinx XC9536XL verwenden. fchk
Hier eine mögliche Lösung.
Ausgangsgleichung:
AVR_INT = /( (/IORQ * /WR * /A7 * A6) +
(/IORQ * /RD * /A7 * A6) +
(/IORQ * /M1) )
NAND-Form:
AVR_INT = /( /( M1 * /A6 ) *
/( M1 WR RD ) *
/( IORQ ) *
/( M1 * A7 ) )
Bei dieser Lösung würde am AVR ein externer Interrupt ausgelöst werden.
In der ISR könnte durch Abfragen von WR, RD und ST die Interruptquelle
zugeordnet werden.
I/O-Read = AVR_INT * /RD
I/O-Write = AVR_INT * /WR
INT 0 (2) = AVR_INT * /ST
Nachtrag:
Die Gatter die noch übrig bleiben, können dann prima für die DESEL
verwendet werden, geht gerade auf ;-)
:
Bearbeitet durch User
Joe G. schrieb: > Ausgangsgleichung: > AVR_INT = /( (/IORQ * /WR * /A7 * A6) + > (/IORQ * /RD * /A7 * A6) + > (/IORQ * /M1) ) > Bei dieser Lösung würde am AVR ein externer Interrupt ausgelöst werden. > In der ISR könnte durch Abfragen von WR, RD und ST die Interruptquelle > zugeordnet werden. Es wird nicht funktionieren, da die Impulse auf den Leitungen viel zu kurz sind, um in einer AVR-Interruptroutine gelesen zu werden, Es sei denn, die Signale werden gelatched, oder man baut noch eine Wait-State-Logik dazu. Aber wozu sollte das denn eigentlich gut sein? Vor allem mit dem Int-Ack kann der AVR eigentlich nichts sinnvolles anfangen. Nützlich wäre allerdings ein Kanal, über den der Z180 einen Datentransfer anstoßen könnte. Der eigentliche Datentransfer wird dann durch den AVR per DMA erledigt. Das hast Du ja weiter oben schon vorgeschlagen. Dazu reicht ein IN oder OUT auf einen passenden Adressbereich. Oder: Wenn der Z180 nichts zu tun hat, weil er auf Daten wartet, läuft er auf einen HALT- oder SLEEP-Befehl. Das HALT-Signal kann dann am AVR einen Interrupt auslösen...
Leo C. schrieb: > Aber wozu sollte das denn eigentlich gut sein? Bei INT0, Mode 2 könnte der AVR den Interruptvektor bereitstellen. Für DMA reicht /IORQ, /RD und /WR aus. /M1 bräuchte dann ja nicht decodiert werden. @Nachtrag: Das war natürlich Unsinn. Die Gatter werden ja auf der Z180-Stamp Platine benötigt und nicht beim AVR (siehe Update im SVN)
Angehängte Dateien:
-
ECB-Traeger.png
30 KB
> Bei INT0, Mode 2 könnte der AVR den Interruptvektor bereitstellen. Wie schon geschrieben, bräuchte man dazu mindestens noch einen Waitstate-Generator. Damit wäre man dann schnell bei einem CPLD, wie der Forentroll hier ja schon vorgeschlagen hat. Die aktuelle Schaltung im SVN funktioniert. Statt der beiden Gatter-ICs könnte man aber auch einen 74LVC138 (oder so) nehmen. Damit könnte man auch den belegten Adressbereich noch weiter einschränken. > @Nachtrag: Das war natürlich Unsinn. Die Gatter werden ja auf der > Z180-Stamp Platine benötigt und nicht beim AVR (siehe Update im SVN) Oder anders rum, also die Dekodierung auf die Z180-Karte setzen. Zwischendurch dachte ich mal, man könnte dadurch ICs einsparen, und das I/O-Select könnte auf einer "Trägerplatine" für die Busbuffer-Steuerung nützlich sein. Beides kommt aber nicht ganz hin und man bräuchte einen weiteren Pin auf den Steckerleisten. Hast Du Dir schon Gedanken darüber gemacht, wie man die "Stamps" auf einer Grundplatte anordnen könnte? Insbesondere auf einer ECB-Europakarte, und wie gut (oder evtl. schlecht) die Anschlüsse dann zugänglich sind? Die Micro-SD-Karte könnte man ja als - im Betrieb nicht wechselbare Harddisk - betrachten. Im Anhang ist mal ein Versuch von mir. Wenn die Karten etwas schmaler wären, könnte man sie um 90° drehen, und die Anschlüsse der AVR-Karte wären in einem 19" Rack von der Frontplatte aus zugänglich. K.A., ob das routingtechnisch geht. /DREQ0 sollte in dem System (dauerhaft) aktiviert werden können. Entweder durch Jumper, Pulldown oder GPIO des Steuerprozessors. Grund: DMA-Transfers 'memory maped i/o <--> mememory' und 'i/o <--> mememory' funktionieren nur mit /DREQ. Mit ersterem löscht meine Kaltstart-Init z.Zt. das RAM (feste mem-src auf incr. mem-dst). Das würde aber ohne /DREQ gehen, wenn man es umprogrammiert auf: incr. mem-src --> inc. mem-dst, wobei dst = src+1. Beim geplanten STM32-Controller könnte man 'i/o <--> mememory' zum Transfer größerer Datenblöcke vom Z180 zum STM verwenden. Pullup an /TEND1 kann entfallen (output). Pullup an CKA1//TEND0 kann evtl. auch entfallen. Allerdings ist die Leitung nach Reset ein Input. Also besser lassen. Verwendungsvorschläge für die noch freien I/Os neuen AVRs (AVR_Stamp): A16-A18 statt der Pulldowns. SD-Card: Card-Detect, Power-On, Write-Protected Für eine im Gerät versenkte Mico-SD wohl weniger wichtig. Beim AVR-CP/M vermisse ich aber vor allem das Card-Detect-Signal.
Vielen Dank für die Hinweise und Vorschläge! In meinem Testaufbau bootet das System bereits mit CP/M 2.2 und ZSDOS. Der Z180 CPU Takt wird dabei vom AVR bereitgestellt. Das läuft mit 18.432 MHz bisher stabil. Bei der Micro-SD wird zwar eine SD > 1 GB erkannt, jedoch noch fehlerhaft gelesen. Hier ist nochmal ein intensives Elm Chan Studium notwendig ;-) > Statt der beiden Gatter-ICs könnte man aber auch einen 74LVC138 (oder > so) nehmen. Damit könnte man auch den belegten Adressbereich noch weiter > einschränken. Die Dekodierung würde ich erst mal so lassen und abwarten welche Anwendungen damit alle entstehen. > Hast Du Dir schon Gedanken darüber gemacht, wie man die "Stamps" auf > einer Grundplatte anordnen könnte? Ja, eigentlich sollte die AVR Platine als "EPROM" direkt auf die Z180 Platine gesteckt werden und dieses Packet dann auf eine ECB Trägerplatte. Genau dafür sind auch die Pinbelegungen der Steckerleisten ausgelegt. Leider kann dann auf der Trägerplatine keine weitere SD-Karte bestückt werden. Ich überlege deshalb auch den SPI-Bus mit auf die Steckerleiste zu legen. > /DREQ0 sollte in dem System (dauerhaft) aktiviert werden können. > Entweder durch Jumper, Pulldown oder GPIO des Steuerprozessors. OK, nehme ich auf, auch die Änderung an /TEND1. > Verwendungsvorschläge für die noch freien I/Os neuen AVRs (AVR_Stamp): > A16-A18 statt der Pulldowns. Sollte auch gehen. Damit könnte der AVR den kompletten RAM beschreiben. > Beim AVR-CP/M vermisse ich aber vor allem das Card-Detect-Signal. Ja, ist bei mehreren SD-Karten sinnvoll. GPIO-Pins sind ja auch noch vorhanden.
:
Bearbeitet durch User
> In meinem Testaufbau bootet das System bereits mit CP/M 2.2 und ZSDOS. Gratuliere. Ich komme leider (bei diesem Projekt) überhaupt nicht von der Stelle. > Der Z180 CPU Takt wird dabei vom AVR bereitgestellt. Das läuft mit > 18.432 MHz bisher stabil. Also anders rum als schon mal geplant. So herum gehts natürlich. > Ja, eigentlich sollte die AVR Platine als "EPROM" direkt auf die Z180 > Platine gesteckt werden und dieses Packet dann auf eine ECB > Trägerplatte. Genau dafür sind auch die Pinbelegungen der Steckerleisten > ausgelegt. Ja, aber der Turm wird etwas hoch. Vor allem für einen 19" Einschub. Vorhin vergessen: Die Stiftleisten der beiden Stamp-Karten passen derzeit nicht ins (Loch-) Raster. > Leider kann dann auf der Trägerplatine keine weitere SD-Karte > bestückt werden. Ich überlege deshalb auch den SPI-Bus mit auf die > Steckerleiste zu legen. Daran hatte ich auch schon mal gedacht. Nicht unbedingt als 2. SD-Karte, sondern um eine SD-Karte in Normalgröße alternativ zu verwenden. >> /DREQ0 sollte in dem System (dauerhaft) aktiviert werden können. >> Entweder durch Jumper, Pulldown oder GPIO des Steuerprozessors. > OK, nehme ich auf, auch die Änderung an /TEND1. Da ich mir kaum vorstellen kann, daß beide DMA-Controller je für externe Peripherie verwendet werden, würde es reichen, einen Jumper, Lötbrücke oder ähnliches vorzusehen. Volle Flexibilität gäbe es mit Anschluß an einen GPIO. >> A16-A18 statt der Pulldowns. > Sollte auch gehen. Damit könnte der AVR den kompletten RAM beschreiben. Unter CP/M 3 kann man dann z.B. ganze SD-Karten-Sektoren direkt in/aus den gebankten Disk-Puffern kopieren. >> Beim AVR-CP/M vermisse ich aber vor allem das Card-Detect-Signal. > Ja, ist bei mehreren SD-Karten sinnvoll. GPIO-Pins sind ja auch noch > vorhanden. Das ist vor allem sinnvoll, um das Ziehen einer Karte zu erkennen. Und um eine neu eingesteckte Karte dann vernünftig initialisieren zu können.
> Gratuliere. Danke > Ja, aber der Turm wird etwas hoch. Vor allem für einen 19" Einschub. > Vorhin vergessen: Die Stiftleisten der beiden Stamp-Karten passen > derzeit nicht ins (Loch-) Raster. Die Stiftleisten sind nun im Loch(2.54)Raster. Der "Turm" hat mir ja auch noch nicht richtig gefallen. Gestern Nacht kam mir eine recht nette Idee dazu. 1. Wer einen Turm bauen möchte kann es tun. Auf der Steckerleiste sind dann nur die Pins A2 (12-16) und A2 (18-24) frei zu lassen. A2 (17) ist /DREQ0 an PB4 wenn man es mag. Somit ist der Turm ohne Grundplatte vollständig lauffähig (5V Versorgung über USB). 2. Wer kein Turm bauen möchte, setzt beide Stamps nebeneinander. Auf den doppelt belegten Pins A2 (12-28) liegen nun noch 8 freie GPIOs der SPI-Bus für eine zweite SD und die notwendigen /CS Signale dafür. Folgende Änderungen wurden weiterhin realisiert. - Adressdekoder doch auf 74138 umgestellt (nur noch ein IC nötig) - Adressbereich 0x40h-0x5Fh auf INT2 - Adressbereich 0x60h-0x7Fh auf INT3 - A16-A18 auf GPIO - /DREQ0 an GPIO - /TEND1 ohne Pullup - Card Detect für SD2 Card Detect für SD1 konnte leider nicht realisiert werden, da der Miro-SD Slot kein Pin dafür hat. Ich denke das ist jedoch nicht so problematisch, da SD1 als interne HD genutzt werden kann.
Hi Joe, bin noch nicht ganz durch, weil ich erst später Zeit habe. Klingt aber alles ganz gut, bis auf eine Kleinigkeit am 138. Entweder /M1 auf G1 legen, oder /WR auf /G2B. Außerdem spricht nichts dagegen, noch eine Adressleitung auf den Decoder zu legen, und damit den belegten Adressbereich noch weiter einzuschränken (imho).
> Klingt aber alles ganz gut, bis auf eine Kleinigkeit am 138.
/M1 auf G2B war natürlich Mist :-(
/M1 ist nun auf G1 und A4 zusätzlich auf G2B.
Damit wird INT2 im Bereich 0x40-0x4F und INT3 im Bereich 0x60-0x6F
ausgelöst.
Hier die Pinbelegung beider Module ohne jedesmal die Schaltung bemühen zu müssen.
Schaut euch mal bitte die finale Version des Z180-Stamp und des AVR-Stamp an. Wenn es keine gravierenden Änderungswünsche gibt, würde ich die Platinen demnächst bei Elecrow in Auftrag geben. 10 Stück würden dort derzeit mit E-Test, Lötstopplack und Bestückungsaufdruck 15.90$ kosten.
Joe G. schrieb: > Card Detect für SD1 konnte leider nicht realisiert werden, da der > Miro-SD Slot kein Pin dafür hat. Meine schon. :) Aber die werden nicht auf Dein Layout passen. Joe G. schrieb: > Hier die Pinbelegung beider Module ohne jedesmal die Schaltung bemühen > zu müssen. Danke, kam gerade recht. Ich hatte angefangen, ein weiteres Stockwerk für den Turm zu konstruieren: Ein Adapter, zwischen VL-Discovery und Z180_Stamp. Joe G. schrieb: > Schaut euch mal bitte die finale Version des Z180-Stamp und des > AVR-Stamp an. Wenn es keine gravierenden Änderungswünsche gibt, würde Ich finde, das es sehr gut geworden ist. Meinen Vorstellungen von "Minimal" ist das System jetzt ziemlich nahe gekommen. (Es sind jetzt mehrere Platinen, aber die Gründe haben wir ja diskutiert.) Aber irgendwas fällt einem ja immer noch ein. Sorry, daß die folgenden Anmerkungen so spät kommen, aber es sind ja auch nur ein paar Kleinigkeiten aus der Wünsch-Dir-Was Kategorie. Gibts einen Grund, warum am 74138 A4 auf einem Enable liegt? Logischer wäre A7. Falls der AVR noch freie Ports hat, könnte man, analog zu DREQ0, weitere Z180-Signale für den AVR zugänglich machen. Mir fallen ein Interrupt (Int1?), HALT und WAIT ein. Über letzteres ließe sich ein Single-Step-Betrieb realisieren (wer's braucht). Ich weiß nicht, nach welchen Kriterien Du die AVR-Ports zugeordnet hast. Sinnvoll wäre, die Signale zur RAM-Steuerung (RD, WR, MREQ, und evtl. BUSREQ, BUSACK) auf (bitadressierbaren) Ports im I/O-Bereich zu haben. Kein Punkt fürs Layout, und vielleicht liegts ja an der Auswahl in Eagle, aber 74ALS und 74HCT sind für 3.3V nicht geeignet. Und dann würde mich noch interessieren, warum der Z180 jetzt doch im PLCC-Gehäuse ist, da QFP ja auch mal im Gespräch war.
Nachtrag: Ist die stehende Knopfzelle nicht etwas hoch? Kein Platz zum hinlegen?
Vielen Dank Leo, > Gibts einen Grund, warum am 74138 A4 auf einem Enable liegt? Logischer > wäre A7. Nein, geht natürlich auch (sogar besser) dann liegt 10-1F bis 70-7F schön in einer Reihe wenn man es mal braucht. > Falls der AVR noch freie Ports hat, könnte man, analog zu DREQ0, weitere > Z180-Signale für den AVR zugänglich machen. Mir fallen ein Interrupt > (Int1?), HALT und WAIT ein. Über letzteres ließe sich ein > Single-Step-Betrieb realisieren (wer's braucht). Mal sehen was das Layout noch so hergibt. Single-Step mit einem Flip-Flop ist natürlich ein "Muss" für jeden Z80 Einsteiger ;-) > Ich weiß nicht, nach welchen Kriterien Du die AVR-Ports zugeordnet hast. Das war dem Z180 Layout geschuldet, beim AVR mußte dann die Steckerleiste auch so belegt sein. Mal sehen ob ich die betroffenen Pins in den Bereich bis 0x1F verlegt bekomme. Ich habe mir auch noch nicht angeschaut was der Compiler aus PORTG &= ~(1<<PG1) eigentlich macht. > Kein Punkt fürs Layout, Der Punktabzug ist berechtigt. Ich war zu faul "LV" in Eagle einzutragen. > warum der Z180 jetzt doch im PLCC-Gehäuse ist Weil er so bei mir rumliegt, QFP geht aber auch. Ich habe nicht nach der Verfügbarkeit dazu geschaut. > Kein Platz zum hinlegen? In den ersten Versionen war kein Platz, doch nun sieht es ja ziemlich aufgeräumt aus und es wird sich warscheinlich der Platz finden.
:
Bearbeitet durch User
Die Signale zur RAM-Steuerung sind auf PORT D umgezogen. PORT G liegt nun frei auf der Steckerleiste A. Hier könnte auch extern HALT und WAIT verdrahtet werden. A7 liegt nun auf dem Enable eines "LV" IC's ;-) Die Pinbelegung auf der Beschreibung ist angepaßt (STM-Turm). Die liegende CR2032 Variante ist ein Monster! Sie paßt jedoch aufs Layout. Der Z180 kommt nun im QFP Gewand.
Angehängte Dateien:
> liegende CR2032 Variante ist ein Monster! Sie paßt jedoch aufs Layout. Eben. Stehend ist sie nämlich auch ein Monster. Man könnte ja mal rechnen, obs eine kleinere auch tun würde. Allerdings ist die CR2032 überall billig zu bekommen. > Der Z180 kommt nun im QFP Gewand. Welches Kriterium hat Dich denn zum Wechsel bewogen? Heute habe ich mir auch mal das Datenblatt vom ATmega1281 gesaugt. Was hat sich Atmel denn bei der Zuordung der ISP-Pins gedacht? (Anhang)
> Welches Kriterium hat Dich denn zum Wechsel bewogen? Das spart den PLCC Sockel und entspannt etwas das Layout. Leider ist die PLCC Version bei den Distributoren sehr viel verbreiteter. Die QFP Version habe ich derzeit nur bei Mouser gefunden. > Was hat sich Atmel denn bei der Zuordung der ISP-Pins gedacht? Der Hinweis war gut! Bei meiner Testversion (DIL) ist alles ok, in der geplanten TQFP-64 Version muß der ISP Stecker ja anders beschaltet werden :-( - muß ich fix noch ändern. > Man könnte ja mal rechnen, obs eine kleinere auch tun würde. Da der Platz ja vorhanden ist, darf sie auch liegen.
Joe G. schrieb: > Das spart den PLCC Sockel und entspannt etwas das Layout. Leider ist die > PLCC Version bei den Distributoren sehr viel verbreiteter. Die QFP > Version habe ich derzeit nur bei Mouser gefunden. Und ich dachte, beide Versionen wären etwa gleich teuer und gleich verfügbar, weil Mouser der einzige Distributor war, bei dem ich geschaut hatte. In der Bucht gibt es ein paar PLCC, und aliexpress hat "interessante" Angebote für beides.
Ich hab mal die üblichen "Verdächtigen" abgegrast. Die QFP Variante ist bei keinem dieser Distributoren derzeit sofort verfügbar (sehr lange Lieferzeiten). Die PLCC Variante hingegen überall sofort. Bei Aliexpress findet man zwar die QFP Variante doch das scheint mir für potentielle Nachnutzer sehr unsicher. Lange Rede kurzer Sinn - das Layout gibt es ja nun für beide Varianten.
Ganz im Sinne von open source hardware hier nun die kompletten Schaltungsunterlagen und das Layout der Stamp Module (/sheet). Die benutze Eagle Version ist die 5.4. Im Ordner /docs findet ihr Schaltungen und Layout als PDF und im Ordner /sheet/Gerber die zugehörigen Gerber-Files. Wer Platinen habe möchte, meldet sich einfach bei mir. Ich werde sie diese Woche bei Elecrow in Auftrag geben (Special Offer For 2 Layer 10*10cm max green PCB - 5/10pcs). Alle Unterlagen hier: http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/ Viel Spaß damit!
Angehängte Dateien:
-
LPs.jpg
180 KB
Gerade sind die Leiterplatten eingetroffen. Von den 2x10 Stück sind noch 6xZ180 und 7xAVR vorhanden. Der Stückpreis liegt bei 2.37$ also 1.73€ + Porto. Wer Interesse hat, bitte einfach bei mir melden. Berücksichtigt ist bereits Leo C. mit 2xZ180 und 1xAVR
Der derzeitige Bestellstand. Bei Bedarf würde ich auch gleich eine Bestellung der IC's (Z180, AVR, SRAM, Micro-SD Holder, Quarz, RTC) machen. AVR Z180 Olaf I I Uwe I Harald I I Leo C I II Joe II II
Eine Sammelbestellung der "Spezialteile" macht sicherlich Sinn, da ja nicht alles "an der nächsten Ecke" lieferbar ist.
Hallo Joe, ich habe dir gerade bei Gaby.de geschrieben... an den Spezialteilen wären ebenfalls interessiert... Natürlich auch ein Satz Platinen Z180 und AVR. Gruß Hans-Werner
:
Bearbeitet durch User
Joe G. schrieb: > Der derzeitige Bestellstand. Bei Bedarf würde ich auch gleich eine > Bestellung der IC's (Z180, AVR, SRAM, Micro-SD Holder, Quarz, RTC) > machen. > > AVR Z180 > Olaf I I > Uwe I > Harald I I > Leo C I II > Joe II II Hi! Bei den IC's wäre ich dann auch gleich mit dabei! LG Harald
:
Bearbeitet durch User
Harald Nagy schrieb: > Bei den IC's wäre ich dann auch gleich mit dabei! ich genauso @Joe, ich übernehme das Porto für alle, wenn du eine Sammelbestellung machst. Gruss Uwe
Für die Platinen hatte ich mich ja schon "angemeldet" - bei den ICs bin auch gerne mit dabei! Gruß Marcel
Joe G. schrieb: > Gerade sind die Leiterplatten eingetroffen. Die sehen sehr gut aus. Ich kann aber nicht noch ein neues Projekt anfangen. Da werde ich ja mit den laufenden nie fertig :-/ Grüße, Jens
Hallo Joe, ich melde mich auch für einen Satz Platinen und natürlich auch die ICs dazu. Das Projekt macht einen guten Eindruck, ich hoffe, dass ich die Lötarbeiten noch hinbekomme. Gruß siggi
Es sollten alle die sich bei mir und hier im Forum gemeldet haben nun eine Mail von mir bekommen haben. Sollte das nicht der Fall sein, bitte eine kurze Info an mich. Wie er derzeit aussieht, ist der erste Satz Platinen (2 x 10) nun verteilt.
Hallo! Ich mir grad nochmal die Unterlagen zu den Modulen angesehen. Hast du auch einen kompletten Schaltplan zum AVR Modul?
Unter http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/Eagle/ ist nun eine *.LIB (Eagle) mit den Stamp-Modulen verfügbar. Eine ECB-Trägerplatine mit zweiter SD, 2 x echter RS-232 und einer Single-Step Logik steht kurz vor der Vorstellung.
Hier nun ein Vorschlag für eine ECB Karte. Derzeit untergebracht sind beide Stamp-Module, zwei RS232-Schnittstellen (3.3V auf +/- 12V), eine SD-Card und eine Single-Step-Logik. Die RS-232 führt auf zwei Wannenstecker, so dass 9-polige oder 25-polige SUB-D leicht gecrimpt werden können. Über die Single-Step-Logik könnte der Z180 vom AVR in den Einzelschrittbetrieb versetzt werden und der Zustand des Adress-, Daten- und Steuerbus in einem Monitorprogramm angezeigt werden. Die Verbindung Z180 Busstecker ist noch offen, das es einige unterschiedliche Varianten gibt [1]. Ich würde nun gerne eine Diskussion zum Entwurf anregen. Welche Busvariante ist sinnvoll? Was sollte noch auf die Karte? [1] http://www.cpcwiki.eu/imgs/8/83/ECB_Bus_-_Pinout_Variants.pdf
Joe G. schrieb: > Hier nun ein Vorschlag für eine ECB Karte. Derzeit untergebracht sind > beide Stamp-Module, zwei RS232-Schnittstellen (3.3V auf +/- 12V), MAX238 ist 5V only. Bei Maxim habe ich überhaupt keine 3.3V Transceiver mit je 4 Rx und 4 Tx gefunden. Bein anderen Herstellern habe ich nicht geschaut. 3Tx/5Rx gibts allerdings zahlreich, z.B. MAX3244. Damit ließe sich auch DCD0 noch versorgen. > Die RS-232 führt auf zwei Wannenstecker, so dass 9-polige oder 25-polige > SUB-D leicht gecrimpt werden können. Find ich gut. Zusätzlich würde ich gerne auch die 3.3V-Seite irgendwie verfügbar machen, z.B. für Blutooth-, sonstige Funkmodule oder RS485. Meine Seriellen haben fast alle irgendwo eine 4-polige Stiftleiste mit Versorgungsspannung und Rx/Tx. > eine SD-Card und eine Single-Step-Logik. SD-Karte ja. Single-Step könnte man ggf. auch extern anschließen. Dann mit Frontpanel. :) Aber Platz ist ja wahrscheinlich vorhanden... > Die Verbindung Z180 Busstecker ist noch offen, das es > einige unterschiedliche Varianten gibt [1]. Ich würde nun gerne eine > Diskussion zum Entwurf anregen. > Welche Busvariante ist sinnvoll? Hier sind ja vor allem die Leute gefragt, die ECB haben wollten. Die Euro-Karten, die ich noch habe, sind für dieses System uninteressant. Welche Frquenzen verträgt der ECB-Bus denn? Mit 20MHz wird er wohl nicht laufen. Und die alten Karten, die man anschließen könnte, schon gar nicht. Takthalbierungslogik? Waitstate-Generator? > Was sollte noch auf die Karte? - Reset-Taser - LED an HALT-Signal - Lochrasterfeld -
Leo C. schrieb: > MAX238 ist 5V only. Ich habe einfach den MAX3238 angenommen :-( Nach dem Studium des Datenblattes bin ich nun klüger. Eine 3 vor dem gleichen Type ist nicht unbedingt 3.3V :-( Ich werde also auf ein 3TX/5RX umstellen. > Zusätzlich würde ich gerne auch die 3.3V-Seite irgendwie > verfügbar machen. Diese Pins können ja auch auf eine Stiftleiste. Hast du einen Favoriten bzw. eine Lieblingsbelegung? > - Reset-Taser > - LED an HALT-Signal Ist schon realisiert. Ein Lochrasterfeld wird allerdings eng. Die beiden Stamp-Module + SD + RS232 füllen den Platz einer Eurokarte schon fast voll aus. Bei ECB warte ich nochmal auf Vorschläge. Ich würde es erst mal nicht benötigen. @alle Bis auf den 74LV138 sind die Teile eingetroffen. Dieses IC ist auf den 10.07. terminiert. Wer seine Bauelemente und Leiterplatten schon früher haben möchte, melde sich einfach bitte kurz bei mir. Sie gehen dann auf die Reise.
Joe G. schrieb: > Ich habe einfach den MAX3238 angenommen :-( Nach dem Studium des Und ich weiß gar nicht, wieso ich zum MAX238 abgedriftet bin. Der MAX3238 ist ja ein 3.3V-Typ und auch mit 3Tx/5Rx. Geht also doch. Nur etwas anders, als Du ursprünglich gedacht hast. > Diese Pins können ja auch auf eine Stiftleiste. Hast du einen Favoriten > bzw. eine Lieblingsbelegung? GND/RXD/TXD/VCC. Wobei GND wahrscheinlich die 1 ist. Ich schließe auch diese Module[1] an, wobei dort RXD und TXD vertauscht sind. (Die Beschriftung ist aus Sicht der USB-Seite.) Aber die Module gibts in unzähligen Varianten, inzwischen sogar billig mit FTDI-Chip. Die Leisten könnte man evtl. um die Steuerleitungen verlängern. Die RX-Leitungen sollten wohl von den Tranceiver-Rx-Ausgängen entkoppelt werden (Dioden/Widerstände/Jumper). > Ist schon realisiert. Ein Lochrasterfeld wird allerdings eng. Die beiden > Stamp-Module + SD + RS232 füllen den Platz einer Eurokarte schon fast > voll aus. Unter den Stamps ist doch auch noch reichlich Platz. Ein Feld mit Lötpunkten im 1.27 Raster wäre vielleicht auch ganz nett. Durchkontaktierte Löcher sind für SMD sowieso nicht optimal. [1] http://www.ebay.de/itm/PL2303-USB-To-RS232-TTL-Converter-Adapter-Module-cable-NEW-/170813867942?pt=LH_DefaultDomain_0&hash=item27c54cc7a6
Leo C. schrieb: >> Diese Pins können ja auch auf eine Stiftleiste. Hast du einen Favoriten >> bzw. eine Lieblingsbelegung? > > GND/RXD/TXD/VCC. Wobei GND wahrscheinlich die 1 ist. Ich finde die Belegung die bei PMODs verwendet wird ganz brauchbar: VCC/GND/RX/TX Michael
Hi, hat jemand die IBAN von Joe für mich? Im Brief war nur die Kto-Nr, da streikt mein Banking-Programm :-) Danke und Gruß Marcel
> hat jemand die IBAN von Joe für mich? Du hast Mail... > Im Brief war nur die Kto-Nr, da google wär'n Versuch wert. > streikt mein Banking-Programm :-) Bei mir hat das Onlinebanking sich nach der Buchung geweigert, eine Vorlage mit Kto-Nr. zu speichern, aber die die IBAN angezeigt. Und Umlaute können die Banken auch immer noch nicht...
Danke für die Mail mit IBAN und BIC, bei EU-Überweisungen geht nämlich nur mehr so!
Angehängte Dateien:
-
Layout-PLCC68.png
100 KB -
IMG_20140725_182102.jpg
80 KB
Inzwischen habe ich die beiden Platinen aufgebaut. Die AVR-Platine funktioniert so weit, aber ich habe noch nicht alle Funktionen getestet. Auf der Z180-Platine ist ein Layoutfehler. Pin 8 (RESET) der CPU ist mit Pin 5 (WAIT) verbunden, statt mit R9 und der Steckerleiste. Leider ist die Verbindung unter dem PLCC68-Sockel, den ich schon eingelötet hatte. Und noch schlimmer, ich habe die beiden Platinen schon fest mit Drähten verbunden, da mir die passenden Steckverbinder noch fehlen. Da ich keine Lust hatte, wieder alles auseinander zu reißen, habe ich die Leiterbahn von der Platinenunterseite her durchbohrt. :) Weitere Fehler habe ich bisher noch nicht gefunden, aber mein Monitor (von der STM32/HD64180-Kombination) läuft leider noch nicht. Vielleicht gibts doch noch eine Inkompatibilität zwischen HD und Z180.
Hallo! Ich bin mit der Z180-Stamp quer eingestiegen, aber interessiere mich auch für das "alte" Projekt. Gibt irgendwo eine Zusammenfassung der aktuellsten Hardware und Software, sodass ich nicht den ganzen CPM-Thread durchackern muss...? Gibt's da eventuell sogar noch Platinen dafür? Danke!
:
Bearbeitet durch User
Es gibt noch den Artikel: http://www.mikrocontroller.net/articles/AVR_CP/M Leider ist der auch nicht mehr so übersichtlich und nicht auf dem neuesten Stand. Zu Platinen kann ich nichts sagen. Da das ganze System aber nur aus MCU, Quarz, 2 DRAMs, SD-Sockel und ein paar Stützkondensatoren und Pullups besteht, kann es auch leicht auf Lochraster aufgebaut werden.
Super danke! Dann werd ich mir die Infos mal aus dem Artikel ziehen und dann mit dem Thread updaten. Erleichtert ja schon mal sehr die Arbeit! Dass das ganze auf Lochraster geht kommt mir sehr entgegen!
Übrigens läuft mein Z180-Stamp inzwischen (seit Samstag). Am RAM-Chip war noch ein Lötfehler. Jetzt fehlen mir noch der Micro-SD-Sockel und anständige und bezahlbare Stift/Buchsenleisten. Den Sockel habe ich u.a. bei Völkner/Conrad gefunden. Zu den Leisten wollte ich Joe schon immer mal fragen, was er verwenden wollte. Insbesondere, wenn man die Platinen stapeln will. Aber da er gerade im Urlaub weilt, hat jemand einen Vorschlag? Bei Interesse und wenn es sich rechnet, würde ich eine Sammelbestellung für die beiden Sachen machen. Sonst noch was?
Hi! Ich hab Joe schon eine EMail geschrieben, zwecks der Bauteile und warte auf seine Rückkehr aus dem Urlaub. Wenn sich da was bzgl Sammelbestellung ergeben würde, wäre ich wieder mit dabei!
Leo C. schrieb: > Übrigens läuft mein Z180-Stamp inzwischen (seit Samstag). super! > Zu den Leisten > wollte ich Joe schon immer mal fragen, was er verwenden wollte. Am Sonntag bin ich wieder zurück. Dann werde ich mit einem Vorschlag dazu melden, es gibt einreihige Buchsen-Stiftleisten mit überlangen Kontakten. Ich glaube Fischer Elektronik ist das Stichwort. Schaut mal nach SL20 THR164 oder ähnliches. Das BIOS lade ich am Sonntag auch mit hoch. Nun gehts wieder an den Strand, Joe
Hier nun der Vorschlag für die Verbindung der beiden Leiterplatten. Die untere Platine (Z180) bekommt 2 x eine Stiftleiste Type SL 1 179 32S (Fischer). Die Stiftleiste wird von der Platinenunterseite durchgesteckt und auf der Oberseite verlötet. Auf der Unterseite sitzt dann das Plastteil mit den kurzen Stiften. Die langen Stifte gehen durch die LP und schauen noch 15mm nach oben. Die obere Platine (AVR) bekommt 2 x eine Buchsenleiste Type BL 5 025 32 (Fischer) auch auf die Unterseite gelötet. Damit gibt es nun die folgenden Steckvarianten. 1.Beide Platinen „huckepack“. Unten Z180 oben AVR 2.Beide Platinen auf einer Eurokarte. Z180 auf Buchsenleiste, AVR auf Stiftleiste. Damit können bein Stecken beide Platinen nicht verwechselt werden.
Hallo Joe,
so ist es ja einfach. :)
Ich hatte nach Stiften gesucht, die man unten stecken kann, und oben
eine Buchse haben. So was findet man in den Katalogen der Hersteller,
aber (fast) nicht bei den Händlern. Also wenn man die überhaupt bekommt,
dann unverhältnismäßig teuer.
> Damit können beim Stecken beide Platinen nicht verwechselt werden.
Das kann man als Vorteil sehen. Aber man kann die Platinen nicht mehr
beliebig aufeinander türmen. Allerdings geht das ja sowieso nicht
wirklich, weil die Steckerbelegungen ja nicht identisch sind.
Leo C. schrieb: > Ich hatte nach Stiften gesucht, die man unten stecken kann, und oben > eine Buchse haben. Gibt es auch: http://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/VA/BL1332/index.xhtml Ich habe mal nach einem 50ziger Los angefragt.
Der von Leo C. entdeckte Fehler (Danke!) ist korigiert und die neuen Daten liegen im SVN. Außerdem gibt es eine Fehlerbeschreibung und ein Korrekturvorschlag. Wer die PLCC-Fassung schon bestückt hat, folgt am besten dem LEo C. Vorschlag der kleinen Bohrung, ansonsten kann der Leiterzug einfach aufgetrennt werden.
Harald Nagy schrieb: > Hi! > > Ich hab Joe schon eine EMail geschrieben, zwecks der Bauteile und warte > auf seine Rückkehr aus dem Urlaub. Wenn sich da was bzgl > Sammelbestellung ergeben würde, wäre ich wieder mit dabei! @Joe: hast du meine email bekommen?
Angehängte Dateien:
-
Stampstapel1.jpg
100 KB -
Stampstapel2.jpg
110 KB
Joe G. schrieb: > Gibt es auch: > http://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/VA/BL1332/index.xhtml Dürfte wohl deutlich teurer werden. Deine ursprüngliche Lösung ist eigentlich ganz gut, da man die Platinen sowieso nicht wirklich stapeln kann, wenn man die zusätzlichen AVR-Ports auch nutzen will. Meine Karten sind z.Zt. allderdings gestapelt. Weil ich nicht auf die optimale Stecklösung warten wollte, habe ich sie kurzerhand mit Drahtstücken übereinander gelötet. War etwas ungeschickt, weil an der Z180-Platine ja noch gar nichts getestet war. Noch ein Punkt für die (ECB-) Basiskarten-Wunschliste: "Kaltstarttaste" an einem der AVR-Ports, um Defaultwerte aus dem EEPROM zu laden. Kann evt. auch mit dem Z180-Reset kombiniert werden. (Ich bastle gerade einen Boot-Monitor, bei dem man alles verkonigurieren kann. Sozusagen ein U-Boot[1]-Port ;) [1] http://www.denx.de/wiki/U-Boot/WebHome
Leo C. schrieb: > "Kaltstarttaste" an einem der AVR-Ports, um Defaultwerte aus dem EEPROM > zu laden. Kann evt. auch mit dem Z180-Reset kombiniert werden. Da haben wir beide aber die gleiche Idee gehabt :-) Du nennst es U-Boot ich hatte die Idee eines BIOS-Setup ähnlich der üblichen PC Hardware. Da es keine Tastatur im unserem Konzept gibt sollte eine "Kaltstarttaste" dafür herhalten.
@all: Joe würde eine Sammelbestellung der notwendigen Steckverbinder durchführen, wenn genügend Leute mitmachen. Wer außer mir hätte dabei noch Interesse?
Joe G. schrieb: > Da haben wir beide aber die gleiche Idee gehabt :-) Du nennst es U-Boot U-Boot würde ich es gerade nicht nennen, da das ein weit verbreiteter Bootloader für Single-Board-Computer, die mit Linux oder ähnlichem laufen, ist. Dessen Funktionsumfang würde nicht mal annähernd in unseren AVR-Speicher passen. Das Konzept kann man aber übernehmen (und Teile des Codes auch ;). Ich halte das für flexibler, als das PC-BIOS mit seinen fest vorgegebenen Menüs. Das Konzept ist ganz kurz und knackig hier beschrieben: http://www.denx.de/wiki/view/U-Bootdoc/UserInterface Wobei für uns die HUSH Shell natürlich nicht in Frage kommt, sondern nur das "simle CLI".
Bei Reichelt gibt es etwas ähnliches -aber auch sehr teuer... Von daher wäre ich eher an der ECB-Platine interessiert, das erscheint mit flexibler. @Leo: Den Micro-SD-Reader habe ich bei Mauser "als Muster" bekommen :-)
Joe G. schrieb: > Gibt es auch: > http://www.fischerelektronik.de/web_fischer/de_DE/Steckverbinder/G02/Buchsenleisten/VA/BL1332/index.xhtml Heute man das Angebot. 50 Stück 381.80 EUR + MwSt. 100 Stück 190,90 EUR + MwSt. 1,90 das Stück würde ja noch gehen, doch wer benötigt 100 Stück? Bei zwei Stamp Modulen sind es gerade 4 Leisten, müßten sich also 25 Interessenten finden.
Ich denke wir sollten warten bis die Urlaubszeit vorbei ist.... Von den leisten würde ich evtl mehr als vier nehmen.
Angehängte Dateien:
-
scr-04.png
84 KB
Auch wenn es bei einem Hobby-Einzelstück nicht so auf die Kosten
ankommt, finde ich 9 Euro (Mwst) für die Leisten schon unverhältnismäßig
teuer. Einfache Stift- und Buchsenleisten kosten nur ein paar Cent.
Einer Sammelbestellung würde ich mich anschließen, wenn es hilft, die
Kosten zu senken. Eilt aber nicht, da ich ja eine vorläufige Lösung
habe.
Die Vorteile beim nebeneinander Stecken dürften wohl überwiegen.
Im Anhang ist ein Hexfile mit Software zum Testen. Der Monitor kann zwar
fast noch nix, ist aber schon 34KB groß. ;) Davon ca. 12KB Z180-
Debugger. Der Sourcecode ist noch in einem Zustand, in dem ich ihn
ungern veröffentlichen würde. Auf Anfrage (PM) kann ich ihn aber
zuschicken.
Environment-Variablen sind so eingestellt, daß der Debugger beim
Einschalten/AVR-Reset in den Z180-Speicher geladen und gestartet wird.
Environment kann man zwar ändern, aber noch nicht dauerhaft speichern.
Es gibt zwar eine Variable für die Baudrate, aber die hat noch keinen
Effekt. Es werden versehentlich noch einige Debug-Meldungen ausgegben.
Beim Debugger handelt es sich um den bekannten DDTZ, den ich vor fast 30
Jahren disassemblierte, und für mein damaliges HD64180 System ROM-fähig
und erweitert hatte. Spezielle Z8S180/Z8L180 Features unterstützt er
noch nicht. Deshalb läuft der Prozessor auch nur mit halbem Einganstakt.
Eine kleine Hilfe ('?' drücken) habe ich kürzlich eingebaut.
Vorraussetzungen:
Z180:
- Pulldwon (10k) an DREQ0 (CKA0), Pin A17 an Stiftleiste.
- Terminal (-Emulator) mit 57600 Baud an ASCI1, (RXA1/TXA1)
- Clock 18,432 MHz, z.B. CLKO-Jumper
AVR:
- Terminal mit 115200 Baud an FTDI
- Quarz 18,432 MHz
- Ggf. CKOUT-Fuse brennen
:
Bearbeitet durch User
Wahrscheinlich wieder eine ziemlich blöde Frage...: Auf dem AVR-Board hängt am Uhren-Chip PCF8583 ein "32khz"-Quarz + Drekko. Ich finde aber überall nur 32,768kHz (Uhrenquarz). Gehe ich recht in der Annahme, dass das passt (laut Datenblatt PCF8583 müsste das auch so sein)? Oder muss es genau 32,000 sein? Danke und Gruß Marcel
Marcel A. schrieb: > Ich finde aber überall nur 32,768kHz (Uhrenquarz). Gehe ich recht in der > Annahme, dass das passt ? Ja, deine Annahme ist korrekt. Es wird ein Uhrenquarz eingesetzt.
Sehr hübsch! Gehört mit einer Single-Step-Taste auf die Frontplatte :-)
Wollte mal fragen, wie es um das Thema "Basisplatine" bestellt ist? Für den Fall, dass ich mal die beiden Boards fertig bekomme... Ein kleines HowTo/Starthilfe wäre sicher auch nicht schlecht - aber ich merke schon, ich oute mich gerade wieder als Anfänger... :-)
Hallo zusammen, ich bin seit ein paar Tagen aus dem Urlaub zurück und wollte mich nun auch daran machen, die zwei Platinen zu bestücken. Hat eigentlich jemand eine Teileliste, um das Bestellen zu vereinfachen? Alles von den Unterlagen (Schaltbild und Layout) abklamüsern ist halt Aufwand. An den Steckverbindern bin ich auch interessiert. Beim Arduino wird ja mit den shields was ähnliches getrieben, insofern ich auch ein paar mehr nehmen würde ... Gruß, Wolfram
Wolfram K. schrieb: > Hat eigentlich jemand eine Teileliste, um das Bestellen zu vereinfachen? > Alles von den Unterlagen (Schaltbild und Layout) abklamüsern ist halt > Aufwand. Wieso ist das Aufwand? Kann man doch mit Eagle exportieren. Im Anhang ist das Ergebnis als csv. Kann in jede Tabellenkalkulation importiert werden.
Leo C. schrieb: > Kann man doch mit Eagle exportieren. Danke für den Tipp - nur hab ich eagle noch nicht mal installiert, da ich die Platinen ja von Joe bezogen habe. Und nochmals danke für die Tabellen - damit hast Du mir schon sehr viel weitergeholfen. Noch irgend welche Hinweise zum Bezug der Teile? Fröhliches Basteln allerseits!
Marcel A. schrieb: > Wollte mal fragen, wie es um das Thema "Basisplatine" bestellt ist? Das Schalungsdesign ist noch nicht ganz fertig. Bin aber dabei. > Ein kleines HowTo/Starthilfe wäre sicher auch nicht schlecht Ich notiere gerade die wichtigsten Schritte beim Zusammenbau um eine kleine Bauanleitung zu schreiben. > Noch irgend welche Hinweise zum Bezug der Teile? Eigentlich alles bei Reic*elt oder ähnlichen Anbietern.
Joe G. schrieb: >> Noch irgend welche Hinweise zum Bezug der Teile? > Eigentlich alles bei Reic*elt oder ähnlichen Anbietern. Kannst du evtl. einen passenden SD-Halter und vlt auch USB-Buchse bei Re*chelt angeben? Sind die Elkos Standardgrößen? Bei den Widerständen und Kerkos sind ja die Größen dabei. Kenn mich mit SMD-Standardteilen nicht so aus.
:
Bearbeitet durch User
Harald Nagy schrieb: > Kannst du evtl. einen passenden SD-Halter und vlt auch USB-Buchse bei > Re*chelt angeben? Den SD-Halter gibts bei Reichelt nicht. Ich habe ihn bei Völkner, Conrad, und einigen Distributoren gesehen. (Leicht zu finden, wenn man nach der Würth Nummer googelt.) Ich habe vor, demnächst bei einem von denen aus anderen Gründen zu bestellen, und könnte evtl. ein paar Kartenhalter mitbestellen, falls sich das rechnet. Leider weiß ich auch immer noch nicht, welche Steckerleisten ich an die Stamp-Karten machen soll. Im Moment ist mir die Variante mit übereinander stecken wieder sehr sympathisch... edit: Der Sockel: http://www.conrad.de/ce/de/product/1088844/WR-CRD-Micro-SD-Kartensockel-mit-Deckel-8-Pins-Pole-8-Wuerth-Elektronik-Inhalt-1-St
:
Bearbeitet durch User
Klingt gut. Bei den Kartenhaltern wäre ich dann dabei! Sonst müsste ich mal schauen ob ich bei Conrad sonst noch was finde, sonst rechnet sich der Versand nicht.... Sollte sich bezgl der Leisten nichts ergeben (scheint sich niemand dafür zu interessieren), werde ich auf "normale" Stecker- und Buchsenleisten ausweichen, da ich die Stamps ohnehin nicht stapeln werde.
:
Bearbeitet durch User
Leo C. schrieb: > Bei Völkner gibts gerade kostenlosen Versand ab 25€. Sicher nicht nach Österreich. Aber danke ich schau mal nach.... Ok, die liefern nicht mal nach Österreich...
:
Bearbeitet durch User
Angehängte Dateien:
-
Bestueckung_1.jpg
320 KB
Bei der Bestückung des Kartenhalters geht es arg eng zu wenn eine 6polige ISP-Buchse mit Rand verwendet wird. Es paßt auf den 1/10mm ;-) Mit kragenloser Buchse ist endlos Platz.
Leo C. schrieb: > Den SD-Halter gibts bei Reichelt nicht. Ich habe ihn bei Völkner, > Conrad, und einigen Distributoren gesehen. (Leicht zu finden, wenn man > nach der Würth Nummer googelt.) > > edit: Der Sockel ... > product/1088844/WR-CRD-Micro-SD-Kartensockel-mit-Deckel-8-Pins ... Es gibt zumindest bei Conrad noch die push-push-Variante des Sockels, die mir persönlich sympatischer ist: http://www.conrad.de/ce/de/product/1088843/WR-CRD-Micro-SD-Kartensockel-Push-Push-8-Pins-Pole-8-Wuerth-Elektronik-Inhalt-1-St Außerdem habe ich die meisten anderen fehlenden Teile bei Reichelt zusammengesucht und für beide stamps als öffentlichen Warenkorb gespeichert: https://secure.reichelt.de/index.html?&ACTION=20&LA=5010&AWKID=951391&PROVID=2084 Wer mag, kann ihn als Grundlage für die eigene Bestellung nehmen und so Suchzeit sparen - aber ohne Garantie, denn ich hab selbst gerade erst meine Bestellung aufgegeben und konnte daher noch nicht überprüfen, ob alles so passt. Und wer schon bei Conrad bestellt, für den ist vielleicht auch diese Leiste (wirewrap) eine Option: http://www.conrad.de/ce/de/product/741634/Praezisions-Buchsenleiste-Wire-Wrap-RM-254-gerade-Pole-1-x-36-10120856-BKL-Electronic-Inhalt-1-St Ich werde sie jedenfalls ausprobieren.
Wolfram K. schrieb: > Es gibt zumindest bei Conrad noch die push-push-Variante des Sockels, > die mir persönlich sympatischer ist: Das Layout sieht aber ganz anders aus. (Das Bild im Serviervorschlag scheint aber auch nicht zum Datenblatt zu passen). > Und wer schon bei Conrad bestellt, für den ist vielleicht auch diese > Leiste (wirewrap) eine Option: Die war mir auch schon aufgefallen, ist mir aber viel zu teuer. Ich habe jetzt zufällig mal in die Bewertungen geschaut. Das Bild passt wohl auch nicht zum Datenblatt.
Ok, die push-push-Variante des SD-Kartensockels passt definitiv nicht - danke für den Hinweis. Und die wirewrap-Leisten nehmen leider nur Rundstifte auf und sind damit nicht stapelfähig ... Hat jemand denn noch was mit gescheiten Leisten in petto?
Gerade gefunden: http://www.electrodragon.com/product/arduino-special-used-break-away-pin-header-with-long-male-pins-68-pins/ Mal schauen, was ich dort sonst noch finde. Nachdem ich bei Conrad/Völkner mehrmals über falsche Produktfotos gestolpert bin, und nun auch noch diesen[1] dreisten Betrugsversuch gesehen habe, werde bei denen sicher nichts mehr kaufen. [1] Beitrag "Re: VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?" Anzeige eines 800x480 Displays wurde in das Foto eines Gerätes montiert, daß ein 320x234 Display hat. Sowas passiert sicher nicht aus Versehen.
Angehängte Dateien:
-
AVR_Stamp_1.jpg
230 KB -
AVR_Stamp_2.jpg
450 KB
Ich habe eigentlich eine ganz gute Lösung gefunden. 4 x Buchsenleiste 2,54 mm, 1x16, gerade (MPE 094-1-016) für 0.32€ das Stück bei Reichelt und 2 x Stiftleiste 32 polig gerade und löte beide zusammen. Bei der Buchsenleiste muss an einer Seite etwas weggefeilt werden, dann wird eine wunderschöne Leiste für 32 Pins daraus. Achtung! Der Batteriehalter KZH 20-1 muß umgedreht (Plus und Minus tauschen) eingelötet werden. Ich habe in der Eagle Lib die Pole vertauscht, sorry :-(
Angehängte Dateien:
-
8pin.jpg
5,9 KB
Ich werde die 8-poligen Buchsen/Steckerleisten bei Electrodragon bestellen. Preis pro 10er Pack 0,93 Euro. Für die beiden Stamp-karten braucht man 16 Stück. Wer Interesse hat, kann mitbestellen. Dazu kämen die anteiligen Versandkosten (fast vernachlässigbar, da ich noch einige andere Teile bestellen will) und die Versandkosten von mir zum Besteller. ca 0,90€..1,50€ Übrigens hat Electrodragon auch Knopfzellenhalter[1], die so aussehen wie auf meinen Fotos oben[2]. 10 Stück für 0,77€. Dieser Halter paßt noch ganz knapp neben den Quarz. Kann ich bei Interesse auch noch mitbestellen. Es müßten aber ca. 10 zusammen kommen, da ich selber noch ausreichend eingedeckt bin. http://www.electrodragon.com/product/cr2032-cr2025-battery-holder/ Beitrag "Re: Z180-Stamp Modul"
Hallo Leo, ich wäre bei einer Bestellung dabei. Vier mal 10 Stück hätte ich gerne. Und wenn möglich, 4 Knopfzellenhalter. Falls Du die SD-Halter noch bestellst, für mich auch 4 Stück. Danke und Gruß Siggi
Ich wäre auch dabei mit 16 Leisten, 1 Knopfzellenhalter, 1 SD-Halter. LG Harald
siggi schrieb: > Falls Du die SD-Halter noch bestellst Sorry, das wäre bei Conrad gewesen. Muß ich erst mal wieder neu suchen.
Da man ja auch noch Leisten braucht, um ggf. beide Platinen nebeneinander auf eine Board zu steckken, brauche ich dann 7 x 10 Leisten. Und eine Knopfzellenhalterung nehme ich auch...
Frage: Wie herum baut man die Leisten am Besten ein? Stifte oben, Buchsen unten, oder umgekehrt? Marcel A. schrieb: > Da man ja auch noch Leisten braucht, um ggf. beide Platinen > nebeneinander auf eine Board zu steckken, Leisten oder Buchsen? Aber auch wenn man stapelt, kann eine "Bodenplatte" sinnvoll sein. Anyway, ED hat auch "normale" Buchsen- und Stiftleisten. Für mich werde ich diese mitbestellen (jeweils "männlich" und "weiblich"): http://www.electrodragon.com/product/break-away-header/ Alternative Buchsen: http://www.electrodragon.com/product/10pcs-16pin-2-54pitch-pin-header-female-for-1602-lcd/ (Die muß man nicht zuschneiden/sägen, aber teurer) Die Bestellung möchte ich gerne bis Sonntag Abend zusammen haben. Bis dahin kann man hier ja noch über die Bauteile diskutieren. Konkrete Bestellungen möchte ich aber gerne per PM oder E-Mail haben. Auch von denen, die sich hier schon gemeldet hatten (Siggi, Harald, Marcel).
Um die Dokumentation bei diesem Projekt nicht so sträflich wie beim AVR CP/M zu vernachlässigen, anbei die Startvariante der Doku. Sie wird zukünftig auch im SVN liegen. Wer etwas dazu beizutragen hat, kann gerne daran mitarbeiten. Hinweise, Fehler, Erweiterungen sind selbstverständlich gerne gesehen.
:
Bearbeitet durch User
Den Micro-SD-Slot gibts bei den großen Distributoren (Farnell, Digikey, Mouser, RS Components) und Mercateo. Die haben alle höhere Mindestbestellwerte, oder liefern nicht an Privat. Distrelec hat ihn für 3,52€ pro Stück + 8,72€ Versandkosten, jeweils incl. MwSt. ebay hat 2 zu teure Angebote aus UK und Aliexpress hat nix.
Die letzte Zeit habe ich mal etwas mit dem Takt für den Z180 experimentiert. Statt dem CLKO-Pin am AVR kann man auch einen Timer-Ausgang nehmen. Damit kann man den Takt zwischen 0,27Hz und 9,22MHz einstellen. Mit dem Z8S180 Takt-Verdoppler kommt man dann wieder auf 18,432 MHz. Mehr als 20 MHz kann der Z8S180 bei 3.3V Vcc ja sowieso nicht. Als Taktausgang am AVR bietet sich PB7 (OC0A oder OC1C) oder PB5 (OC1A) an. PE7 (CLKO) wird dann frei. Im Anhang ist der AVR Bootloader FastBoot von Peter Dannegger/Tutorial ATtiny13, passend konfiguriert für die AVR-Stamp. Die Programmierung über ISP ging mir ziemlich schnell auf die Nerven, da beim ATmega1281 die ISP-Schnittstelle auf den Pins der Seriellen liegt. Und an letzterer hat man ja für gewöhnlich ein Terminal, bzw. einen Terminalemulator.
Zwischenstand Bestellung: 226 Stück 'Arduino Special-Used Pin Header [8 Pins]'[1] 6 Stück 'CR2032 CR2025 Battery Holder'[2] Beides wird nur in 10er Packs geliefert. Da ich eigentlich noch genug Knopfzellenhalter habe, würde ich mich freuen, wenn mir jemand noch ein paar abnimmt. Es bringt mich aber auch nicht um, wenn ich darauf sitzen bleibe (7,7 Cent/Stück). [1]http://www.electrodragon.com/product/arduino-special-used-break-away-pin-header-with-long-male-pins-68-pins/ [2]http://www.electrodragon.com/product/cr2032-cr2025-battery-holder/
> Ok - 2 :-) 2 was? Da ich auf den Micro-SD-Kartenslot angesprochen wurde: Wenn 4 Stück zusammen kommen, kosten die bei oben genannter Quelle[1] 5,70 Euro. Bei z.Zt. unwahrscheinlichen 10 Stück wären es immer noch 4,40 Euro. Mir persönlich zu teuer, aber wenn gewünscht, bestelle ich die so. Dafür bitte nochmal per PM oder E-Mail B'scheid sagen (vielleicht mit Preislimit). [1]Beitrag "Re: Z180-Stamp Modul"
Vorschlag: Phase 1 (Teilebeschaffung und Aufbau) hier und Phase 2 (Inbetriebnahme und Test) in einem neuen thread Beitrag "Z180-Stamp und AVR-Stamp Inbetriebnahme und Test" diskutieren. Könnte etwas zur Übersicht beitragen ...
Stimmt. Ich meine nur, ich nehme gerne auch 2 Batteriehalter, damit 10 zusammen kommen :-)
Wolfram K. schrieb: > Vorschlag: > Phase 1 (Teilebeschaffung und Aufbau) hier und > Phase 2 (Inbetriebnahme und Test) in einem neuen thread Und jedes mal, wenn sich der Fokus leicht ändert, ein neuer Thread, oder wie? > Beitrag "Z180-Stamp und AVR-Stamp Inbetriebnahme und Test" diskutieren. Ich dachte, das Thema verläuft sich. Ich habe gerade jetzt erst gesehen, daß Du tatsächlich schon einen neuen Thread aufgemacht hast. > Könnte etwas zur Übersicht beitragen ... So unübersichtlich finde ich es hier nicht. Im Durchschnitt weniger als ein Beitrag pro Tag, schätze ich mal.
Angehängte Dateien:
-
regler.jpg
130 KB
Hallo Wolfram, ich bin so dreist, und antworte hier auf Deinen Artikel. Sicher wirst Du die Antwort auch hier finden. Falls Dein anderer Thread doch noch ins Rollen kommt, kann ich ihn ja immer ncoh abonieren. Wolfram K. schrieb: > Die Stromversorgung hat Joe schon ganz gut in > http://www.mikrocontroller.net/attachment/229766/Stamp_Doku.pdf erklärt. > Ich werde wohl den 3,3 V-Regler auf dem Z180-Stamp aufbauen, da ich > gerade keine andere Stromversorgung zur Hand habe. Und dann? Da die AVR-Karte Strom über USB bekommt, und ich diese zuerst in Betrieb nehmen wollte, habe ich ihr einfach einen passenden Regler an die Kante montiert. Vielleicht kann man das auf meinen Bildern weiter oben sehen. Ich gebe aber zu, daß das nicht die Lösung für alle ist. Eigentlich wollte ich den Regler auch wieder abbauen, wenn die Z180-Karte dran kommt... > - Wie programmiere ich den AVR zum ersten Mal? Wahrscheinlich über den > 6poligen ISP-Stecker. Genau. Bei der Gelegenheit die Fuses einstellen. Wenn Du dem Z180 keinen extra Quarz verpassen willst, solltest Du (bis auf weiteres) die CLKO-Fuse brennen, damit der AVR seinen Takt auf CLKO/PE7 ausgibt. Meine Fuses stehen auf: avrdude: safemode: Fuses OK (E:F5, H:D6, L:AF) Ohne Bootloader müßte F5 D1 AF passend sein. > Programmer (elektor) ist vorhanden. Macht es Sinn, > gleich den bootloader von Leo zu verwenden? Am Anfang wäre vielleicht über ISP sinnvoller, weil dann eine Fehlerquelle weniger. Und wenn man nur gelegentlich ein neues Programm aufspielt, kann man auch dabei bleiben. Aber man bekommt halt jedesmal Zeichensalat und evtl. nervendes Piepsen über die serielle Schnittstelle in den Terminalemulator. > - Wie kann ich die einzelnen Komponenten (USB, Speicherkarte, Uhr) > testen? Indem man Testprogramme dafür schreibt? ;-) > Hat jemand dazu schon ein paar Testroutinen geschrieben? Einen Teil kannst Du auch mit meinem angehängten Programm testen. Im wesentlichen gilt das gleiche, wie oben[1] schon mal geschrieben. Plus: - Environment Variablen kann man jetzt dauerhaft speichern. - Baudrate kann man einstellen, wird aber nur beim Neustart übernommen. - Datum und Uhrzeit kann man einstellen. (Wochentag wird falsch angezeigt). - Einstellbarer Clock an PB7, Steckerleiste A20. Experimentell, bei lansamem Takt funktionieren die Commands restart, mstep, und go <addr> nicht. - Debug Commands (die mit ! beginnenden), um RAM und EEPROM vom AVR anzuschauen. - Überraschende Debugging Ausgaben. SD-Karte geht leider immer noch nicht. Edit: Bild angehängt [1]Beitrag "Re: Z180-Stamp Modul"
:
Bearbeitet durch User
Der WR-CRD mikro SD 8-Pin kostet bei RS 4,29€ + MwSt das Stück, ab 15 Stück 3,64. Bei Bedarf bestelle ich. Ich würde eigentlich hier in diesem Thread bleiben wollen. Die Beschaffung verläuft sich auch wieder. Wolfram K. schrieb > Ich habe gerade den AVR-Stamp fertig zusammengelötet und stehe vor der > Frage, wie ich nun weiter vorgehe. Leo C. hat ja schon einiges gerade dazu erkärt. Parallel versuche ich die Doku zu schreiben. Der nächste Schritt wird die Programmierung des AVR und des Bootloaders sein. Zunächst erfolgt meine Beschreibung für Windows, für Linux fehlt mir die Zeit UND die Erfahrung. Wenn hier jemand etwas dazu schreibt (einfach als TXT-File) baue ich es gerne ein.
Joe G. schrieb: > Bei Bedarf bestelle ich. Ich plane gerade ein STM32F4-Platinchen und hatte mir diese ausgesucht: http://www.pollin.de/shop/dt/Mzc0ODQ1OTk-/Computer_und_Zubehoer/Hardware/Speicherkarten/micro_SD_Speicherkarten_Sockel_ATOM_MR01_AP20324.html Sehr günstig und hat sogar einen Pin mehr! 'Second-Source' hat Segor für 2,20.
m.n. schrieb: > Sehr günstig und hat sogar einen Pin mehr! Prinzipiell gibt es unglaublich viele Varianten. Für eine einmalige Bastellösung ist das absolut ok. Wenn ein Projekt jedoch in die Breite geht, es von vielen nachgenutzt wird, stellt sich sofort die Frage nach der Verfügbarkeit. Wie sieht es damit in zwei z.B. Jahren aus? Schon beim AVR CP/M Projekt hatten wir das Problem. Die erste Variante haben wir Anfang 05-2010 aufgebaut. Irgendwann 2012 oder 2013 waren die SD-Slots nicht mehr verfügbar. Die derzeit eingesetzte Variante sollte es hoffentlich noch viele Jahre geben.
Joe G. schrieb: > Ich würde eigentlich hier in diesem Thread bleiben wollen. Die > Beschaffung verläuft sich auch wieder. Ok, ich gebe mich geschlagen. Und gleich einen Dank an Leo und Joe für die hilfreichen Ausführungen. Meine Fragen reißen noch nicht ab ... Zum Aufbau des Z180-Stamp: Der 3,3V-Regler hat eine Kühlfläche. Wie bringt man das Teil auf die Platine? Reicht Anlöten an den Anschlüssen und Anlegen der Kühlfläche (ev. mit Wärmeleitpaste) oder soll man versuchen, die Kühlfläche auch anzulöten? Wenn ja, wie?
Joe G. schrieb: > Die derzeit eingesetzte Variante sollte > es hoffentlich noch viele Jahre geben. Darum hatte ich ja auch noch Segor ins Spiel gebracht, wobei man natürlich auch noch die Datenblätter der anderen Anbieter auf Kompatibilität vergleichen könnte. Bei der Relation ca. € 5,-- zu € 0,75 bin zumindest ich schwer ins Grübeln gekommen und habe gnadenlos zugeschlagen :-)
Angehängte Dateien:
-
Power-LP2950.png
24 KB
Wolfram K. schrieb: > Der 3,3V-Regler hat eine Kühlfläche. Wie bringt man das Teil auf die > Platine? Reicht Anlöten an den Anschlüssen und Anlegen der Kühlfläche > (ev. mit Wärmeleitpaste) oder soll man versuchen, die Kühlfläche auch > anzulöten? Wenn ja, wie? Mit Wärmeleitpaste kannst Du da nicht viel ausrichten. Die obere Kante des Reglers an die Flasche anlöten reicht zur Wärmeübertragung völlig aus. Ein Bild von Joe gibts hier: Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" Der Regler kann max. 100 mA. (Mit mehr brauchen wir also nicht zu rechnen ;) Wenn wir von einer maximalen Eingangsspannung von 5,5V ausgehen --> 2,2V Differenz. Also maximal abzuführende Leistung: 220mW Wenn wir eine ganz schlechte Lötstelle haben, können wir mit dem Wärmewiderstand ohne Kühlkörper (RthJ = 92 K/W) rechnen. dT = 220mW * 92K/W = 20,24K Also ca. 20° Temperaturerhöhung worst case. Bei mir messe ich gerade 46mA. Allerdings ohne SD-Karten. Und die ein oder andere Led oder Schnittstellen werden ja auch noch dazu kommen.
Leo C. schrieb: > Im Anhang ist der > AVR Bootloader FastBoot von Peter Dannegger/Tutorial ATtiny13, > passend konfiguriert für die AVR-Stamp. Danke! Läuft sauber und macht mehr Spaß als ISP an und ab stecken. Nun schreib ich gleich mal Doku.
:
Bearbeitet durch User
>> AVR Bootloader FastBoot von Peter Dannegger/Tutorial ATtiny13, >> passend konfiguriert für die AVR-Stamp. Die Anpassungen sind minimal. Wirklich notwendig ist nur die Definition der beiden Pins für RX und TX. Im angehängten Diff ist zusätzlich noch ein Makefile. > Nun schreib ich gleich mal Doku. Danke
Bestellung bei Electrogdragon Wer noch Stift- und/oder Buchsenleisten oder Batteriehalter braucht kann sich noch melden(PM). Von Siggi und Marcel habe ich noch keine E-Mail und keine Postadresse. Ohne werde ich nicht bestellen. Bis Montag warte ich noch.
Eine überarbeitete Doku steht im SVN. Es gibt speziell Infos zum Bootloader und zur Host Software. Weiterhin ist bei der Inbetriebnahme der Stapelvariante die unterschiedliche Belegung der Pins A12 bis A26 zu beachten. Bei der Stapelvariante sind diese Pins NICHT zu verbinden! Näheres auch in der Doku im Anhang. Feierabend, noch einen schönen Sonntag
Leo C. schrieb: > Frage: Wie herum baut man die Leisten am Besten ein? Stifte oben, > Buchsen unten, oder umgekehrt? Die Frage ist oben noch unbeantwortet geblieben. Ich tendiere dazu, die Buchsen unter die Platinen zu machen, und die Stifte oben heraus stehen zu lassen. Man kann die Platinen dann auch mal ohne Grundplatte auf den Tisch stellen, und oben kann man leicht Clips zum Messen anklemmen. (Auf der obersten Platine könnte man die Stifte sogar abschneiden, wenn man sicher ist, daß man nichts mehr draufstecken will.) Auf die Grundplatte kämen dann normale Stiftleisten. z.B. diese hier: http://www.electrodragon.com/product/break-away-header/ [male] Wenn man ein Steckbrett drunter heften will, sollten es diese sein: http://www.electrodragon.com/product/same-length-pin-header-2-54mm/
Leo C. schrieb: > Die Frage ist oben noch unbeantwortet geblieben. Bei meiner Variante sind die Buchsen unten und die Stifte schauen oben raus. Genau aus dem Grund, den du auch angeführt hast. Der Stapel sthet auch ohne Grundplatte auf dem Tisch, zu Messen kann oben an die Stifte ein Oszi angeklemmt werden, auch Erweiterungen am AVR können oben aufgesteckt werden. Auf die Trägerplatine kommen zukünftig einfache Stiftleisten.
Angehängte Dateien:
-
Minicom-fboot.png
68 KB -
Minicom-fboot-2.png
18 KB -
Minicom-fboot-3.png
40 KB
Zum Bootloader (Ergänzung zu Jörgs Beschreibung in der Doku.) Ein gutes Upload-Programm für Linux und andere Posix-Systeme gibt es hier: https://github.com/Boregard/FBoot-Linux Leider blicke ich bei den Kommandozeilenversionen (CLI) für Windows nicht durch. Peter Dannegers Original läuft wohl nicht auf 64-Bit Systemen und evtl. auch nicht auf den neuesten 32-Bit Windows-Versionen. CLI-Programme sind von Vorteil, wenn man einen guten Terminalemulator benutzt (Hyperterm ist es wohl nicht). Man kann den Uploader wie (andere) Datentransfer-Programme aus dem Terminal-Emulator starten, ohne ihn zu verlassen. Bei einigen Terminalemulatoren kann man den Bootloader ins Menü integrieren und mit einem Tastendruck starten. Beispiel für die Config von Minicom im Anhang.
:
Bearbeitet durch User
Meine Kommandozeilenversionen läuft nicht unter Windows 64-Bit und 32-Bit Außerdem wird nur Com1-Com4 unterstützt. In der Doku sind die beiden Programme AVRFlash [1] und Updateloader [2] beschrieben. Beide laufen unter den obigen Windows Systemen. Die Version 8.1 probiere ich noch aus. Allerdings lassen sie sich nicht in das Terminal (Tera Tem VT) einbinden. [1] http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger /Tutorial_ATtiny13 [2] http://www.leo-andres.de/2012/09/updateloader-benutzeroberflache-fur-avr-bootloader/
:
Bearbeitet durch User
Das scheint mir genau unsere Variante desSD Card Connectors zu sein. 20 Stück für 5$ http://www.aliexpress.com/item/20PCS-TF-Micro-SD-Card-Connector-Memory-Card-Socket-holder-flip-type/1923989325.html
Joe G. schrieb: > Das scheint mir genau unsere Variante desSD Card Connectors zu sein. > 20 Stück für 5$ > http://www.aliexpress.com/item/20PCS-TF-Micro-SD-Card-Connector-Memory-Card-Socket-holder-flip-type/1923989325.html Wenn Du das sagst, wirds sehr wahrscheinlich stimmen. Du kannt ja vergleichen. Wie hast Du die überhaupt gefunden? Price: € 3,91 / lot 20 pieces / lot , € 0,20 / piece Shipping: Free Shippingto Germany via China Post Air Mail Estimated Delivery Time: 15-34 days (ships out within 9 business days) Willt Du bestellen, oder soll ich? Meine andere Bestellung wird wahrscheinlich viel früher da sein, aber wenn jemand Geduld hat und Porto sparen will, könnte ich die Halter zusammen mit den anderen Teilen verschicken
:
Bearbeitet durch User
Angehängte Dateien:
-
SD-Card.jpg
44 KB
Hier mal das Original, Pinanzahl und Lage stimmen überein. Leo C. schrieb: > Wie hast Du die überhaupt gefunden? Zufall Ich bestell mal, Briefporto ist ja nicht sooo teuer. Ich kann dann auch gleich überprüfen ob sie wirklich 100% passen. Bei 3,91 kann ich nicht viel falsch machen.
> Ich wäre dabei... Bei dem Preis kann ja fast jeder selber bestellen. Aber was macht man dann mit die restlichen 19 Stück? Außerdem muß man evtl. extra ein Konnto bei Alibaba/Aliexpress anlegen, wenn man noch nicht hat. Nachtrag: > Ich kann dann auch gleich überprüfen ob sie wirklich 100% passen. Gute Idee
:
Bearbeitet durch User
Leo C. schrieb: > Bei dem Preis kann ja fast jeder selber bestellen. Aber was macht man > dann mit die restlichen 19 Stück? Genau das ist das Problem....
ich melde auch mal meinen Bedarf von 4 Stück SD-Card-Connectoren an. Gruß Siggi
siggim schrieb: > ich melde auch mal meinen Bedarf von 4 Stück SD-Card-Connectoren an. Ich habe gestern schon bestellt. Harald 1 Siggi 4
Wenn's ums Loswerden geht nehme ich dir auch 2-3 ab. Wirst ja sehen wer sich noch meldet!
Frage Basisplatine Die Basisplatine soll ja zwei echte RS232 Schnittstellen erhalten. Damit ergibt sich die Frage nach den Buchsen und ihrer Belegung. 1. Möglichkeit (echtes Endgerät) Das CP/M System ist ein echtes Endgerät und bekommt 2x eine 9-polige SUB-D Buchse (male). Mit Pin 3 = TxD und Pin 2 = RxD. Damit würde ein VT100 Terminal z.B. über ein normales Nullmodem Kabel angeschlossen werden. Vorteil: (echte Retro-Beschaltung) Nachteil: RS232toUSB-Wandler nicht nutzbar (selber male). 2. Möglichkeit (Modem) Das CP/M System ist wie ein Modem beschaltet und bekommt 2x eine 9-polige SUB-D Buchse (female). Mit Pin 2 = TxD und Pin 3 = RxD. Damit würde ein VT100 Terminal z.B. über ein Modem-Kabel angeschlossen werden. Vorteil: RS232toUSB-Wandler nutzbar (male). Nachteil: (nicht Retro-Konform) 3. Möglichkeit (Mischbelegung) VT100 bekommt 1x 9-polige SUB-D Buchse (male), mit TxD=3 und RxD=2 RS232 bekommt 1x 9-polige SUB-D Buchse (female), mit TxD=2 und RxD=3 DCD,DTR,DSR usw. natürlich analog Was meint ihr? Vorschläge?
Angehängte Dateien:
-
RS232-Adapter.jpg
100 KB
Also DB9 ist weder echt Retro noch standardkonform. DB9 hat IBM mit ihrem PC durchgesetzt, und gibt es weder in RS232 noch in V24. Wenn schon, dann mußt Du D-SUB 25 nehmen. ;) Eines hat IBM aber richtig gemacht. Da der PC kein Modem ist, sondern nach RS232 ein Endgerät (DTE, Data Terminal Equipment), haben sie den Stecker mit Stiften genommen. Andere nahmen (odere tun es immer noch) Buchsen für ihre Nicht-Modem-Geräte. > Die Basisplatine soll ja zwei echte RS232 Schnittstellen erhalten. Damit > ergibt sich die Frage nach den Buchsen und ihrer Belegung. Du willst die D-Sub Stecker also direkt auf die Platine montieren. Eine Alternative wäre, 10-polige Pfosten/Wannen auf die Platine zu setzen. D-Sub dann über Flachbandkabel. War in PC's mal üblich, und von diesen Kabeln habe ich noch ein paar. 2 sind auf dem Foto. > 1. Möglichkeit (echtes Endgerät) > Das CP/M System ist ein echtes Endgerät und bekommt 2x eine 9-polige Natürlich ist es ein echtes DTE. > SUB-D Buchse (male). Mit Pin 3 = TxD und Pin 2 = RxD. Damit würde ein > VT100 Terminal z.B. über ein normales Nullmodem Kabel angeschlossen > werden. Das VT100 hat einen 25-poligen D-Sub Stecker (male). Du hast andere Nullmodemkabel als ich. ;) Unter Nullmodem verstehe ich ein Gerät/Kabel, daß an beiden Enden wie ein Modem aussieht, also Buchse mit DCE-Belegung. An beide Enden kann man direkt ein DTE, also Stecker (männlich) mit DTE-Belegung, anschließen. > Vorteil: (echte Retro-Beschaltung) > Nachteil: RS232toUSB-Wandler nicht nutzbar (selber male). Diese USB-Wandler sind ja ein Ersatz für die RS232 am PC, also DTEs. > 2. Möglichkeit (Modem) > Das CP/M System ist wie ein Modem beschaltet und bekommt 2x eine > 9-polige SUB-D Buchse (female). Mit Pin 2 = TxD und Pin 3 = RxD. Damit > würde ein VT100 Terminal z.B. über ein Modem-Kabel angeschlossen werden. > Vorteil: RS232toUSB-Wandler nutzbar (männlich). > Nachteil: (nicht Retro-Konform) > > 3. Möglichkeit (Mischbelegung) > VT100 bekommt 1x 9-polige SUB-D Buchse (male), mit TxD=3 und RxD=2 > RS232 bekommt 1x 9-polige SUB-D Buchse (female), mit TxD=2 und RxD=3 > > DCD,DTR,DSR usw. natürlich analog > Was meint ihr? Vorschläge? Meine Meinung dürfte klar geworden sein. Ich kann mich aber auch mit Kompromissen anfreunden, wenn sie das Leben einfacher machen. Und egal, wie Du Dich entscheidest, ich habe den passenden Adapter. Im Bild ist eine Auswahl zu sehen. Wie auch immer, ich würde die 2. Serielle (ASCI1) für das Terminal nehmen, und ASCI0 als "Univarsalschnittstelle" für Modem, Printer, Kommunikation zu anderen Rechnern...
Angehängte Dateien:
-
DB9.jpg
30 KB
Danke für die Ausführungen, > Also DB9 ist weder echt Retro noch standardkonform. Stimmt schon, ist ja erst mit IBM groß geworden. (also Pseudo-Retro);-) > Unter Nullmodem verstehe ich > ein Gerät/Kabel, daß an beiden Enden wie ein Modem aussieht, also Buchse > mit DCE-Belegung. An beide Enden kann man direkt ein DTE, also Stecker > (männlich) mit DTE-Belegung, anschließen. Genau so dachte ich. Das VT100 ist ein echtes DTE, das CP/M auch, dazwischen das Nullmodem mit Buchse-Buchse am Ende und RxD/TxD gekreuzt. So liegen die Kabel bei mir rum. Das VT100 bekommt natürlich ein DB9 (male) - also Pseudo-Retro. > Eine Alternative wäre, 10-polige Pfosten/Wannen auf die Platine zu > setzen. D-Sub dann über Flachbandkabel. So habe ich es auch vor. Die Kabel habe ich schon gecrimpt. Wer Voll-Retro möchte, kann ka ein echten DB25 anschließen. > Wie auch immer, ich würde die 2. Serielle (ASCI1) für das Terminal > nehmen, und ASCI0 als "Univarsalschnittstelle" für Modem, Printer, > Kommunikation zu anderen Rechnern... Auch so ist es geplant.
> Genau so dachte ich. Das VT100 ist ein echtes DTE, das CP/M auch, > dazwischen das Nullmodem mit Buchse-Buchse am Ende und RxD/TxD gekreuzt. Das heißt doch, wenn man die CP/M-Kiste statt ans VT100, über einen USB-Serial-Adapter an den PC anschließen will, geht das ganz genau so. Und VT100 an PC ist natürlich auch gleich. Also überhaupt kein Problem. Achso, wahrscheinlich meinst Du, im 2. Fall kann man sich das (Null-Modem-) Kabel sparen, weil an dem USB-Adapter ja schon einer dran ist. Wie man an dem Adapter in meinem Bild sieht, stimmt das aber sowieso nicht immer. > So habe ich es auch vor. Die Kabel habe ich schon gecrimpt. Wer > Voll-Retro möchte, kann ka ein echten DB25 anschließen. Erst dachte ich, dann ist das sowieso kein Problem. Man quetscht oder lötet einfach einen anderen Stecker ans Flachbandkabel. Aber man muß ja dann auch Adern tauschen. > Auch so ist es geplant. Dann bin ich ja beruhigt. :)
Leo C. schrieb: > >> Auch so ist es geplant. > > Dann bin ich ja beruhigt. :) Jetzt raucht mir der Kopf - aber bei meinen Basteleien bin ich da auch immer durcheinander gekommen und habe immer erst mal gemessen bzw. neu verdrahtet. Habe gerade aktuelle eine Apple IIe serielle Karte (SSC) an einen Raspi-USB-Wandler angeschlossen - die Karte kann man intern von Terminal auf Modem umschalten. Aber das "Nullmodemkabel" ging dann trotz passender Stecker nicht...
Zu den Schnittstellen. Ich würde auch sagen Pfostenleisten wären am besten. Da kann sich jeder mittels Flachbandkabel draufstecken was er braucht.
Harald schrieb: > Ich würde auch sagen Pfostenleisten wären am > besten. Der Trick liegt darin, das Kabel ohne aufzuspleißen oder zu drehen an den Pfostenstecker zu bringen. Ich entwerfe gerde einige Lösungen.
Man glaubt es kaum. Die 8-poligen Buchsenleisten vom Electrodragon [1] sind nicht ohne weiteres anreihbar. Der Kunststoffkörper ist etwas zu lang. :-( Man kann/muß sie mit Feile oder Schleifpapier bearbeiten, falls man nicht zufällig eine Scheifmaschine hat. [1] Die hier: Beitrag "Re: Z180-Stamp Modul"
Leo C. schrieb: > Der Kunststoffkörper ist etwas zu lang. :-( Ist nicht schlimm, war bei mir auch so: Beitrag "Re: Z180-Stamp Modul" Übrigens: Vielen Dank für das Päckchen! Es kam gerade an.
> Ist nicht schlimm, Ich war so sauer, daß ich die Enden teilweise bis aufs blanke Metall abgefeilt hatte. :) Aber jetzt gehts wieder. > war bei mir auch so: Hier ist es allerdings die doppelte Menge, und die Hälfte davon muß man auf beiden Seiten kürzen. Deinen Artikel hatte ich gelesen, aber an den Absatz kann ich mich überhaupt nicht erinnern.
Nein, noch nichts. Kommt ja aus China und dauert halt etwas.
:
Bearbeitet durch User
Hier ist mal ein kleines Update meines Testprogramms. Den Befehl 'clock' habe ich durch einen allgemeineren Befehl 'pin' ersetzt. Man kann damit die AVR-Portpins, die noch keine feste Funktion haben, als konfigurieren und den Pegel setzen. Bei Ports mit Timerausgang kann man die Frequenz einstellen. Von den 5 Timerkanälen können maximal 3 gleichzeitig aktiv sein, da pro Timer immer nur ein Kanal eine Frequenz erzeugen kann. Der Einfachheit halber sind die Pins von 0 bis 10 durchnumeriert. Man könnte sie aber auch nach der Pin-Nummer auf der Steckerleiste benennen. Außerdem könnte man den Pins über eine Environmentvariable Namen zuordnen.
1 | Pin Name Port Timer Mode max div max div min f [Hz] |
2 | ---------------------------------------------------------------------------------- |
3 | 0 PG5 OC0B PWM (2**8)*1024 262144 70.31 |
4 | 1 PG4 |
5 | 2 CLK2 PB4 OC2A Toggle (2**8)*1024*2 524288 35.16 |
6 | 3 ZCLK PB5 OC1A PWM (2**16)*1024 67108864 0.2746 |
7 | 4 PB6 OC1B PWM (2**16)*1024 67108864 0.2746 |
8 | 5 PB7 OC0A Toggle (2**8)*1024*2 524288 35.16 |
9 | 6 PG3 |
10 | 7 PG2 |
11 | 8 PG1 |
12 | 9 PG0 |
13 | 10 CLKO PE7 |
14 | ---------------------------------------------------------------------------------- |
"Screenshoot":
1 | ATMEGA1281+Z8S180 Stamp Monitor |
2 | |
3 | ### main_loop entered: bootdelay=-1 |
4 | |
5 | ### main_loop: bootcmd="pin ${pins}; reset; loadf; go ${startaddr}"
|
6 | => pin |
7 | Pin Config Level Divider Frequency/Hz |
8 | ----------------------------------------- |
9 | 0 Input Low |
10 | 1 Input Low |
11 | 2 Input High |
12 | 3 Input High |
13 | 4 Input Low |
14 | 5 Input Low |
15 | 6 Input Low |
16 | 7 Input Low |
17 | 8 Input Low |
18 | 9 Input Low |
19 | 10 Input High |
20 | => pin 2 Low 3 9MHz |
21 | => pin 2,3 |
22 | Pin Config Level Divider Frequency/Hz |
23 | ----------------------------------------- |
24 | 2 Output Low |
25 | 3 Clock 2 9216000 |
26 | => |
Marcel A. schrieb: > Ich glaube, langsam werde ich mit dem Aufbau mal beginnen müssen :-) Ich hab heute losgelegt. Und gleich mal eine Frage... Also der Aufbau der Boards verlief problemlos (unerwartet). Die Pinheader und der SD-Slot fehlen noch, sonst fertig. Allerdings ist mir aufgefallen, dass ATMEL Studio die Programmierung des 1281 via STK500-kompatiblen ISP-Programmer nicht mehr unterstützt... In AVR Studio 4 gehts anscheinend; zumindest hat sich der Chips auslesen lassen... das Programmieren muss ich morgen mal probieren Edit: Wollte gerade die Fuses setzen (Studio 4.2) aber es kommt nur eine Fehlermeldung...
:
Bearbeitet durch User
Edit: wieder was gelernt. In Studio 6.2 device eingeben, 'unsupported' ignorieren, fuses setzen und programmieren. Läuft alles rund..
Angehängte Dateien:
-
fp-0.0.1a.jpeg
69 KB
Könnte mal jemand sagen wie man diese Anzeigen nennt und wo es sie gibt? Datenblatt? Das suche ich auch noch.... sehr Retro :-)
Christian J. schrieb: > Könnte mal jemand sagen wie man diese Anzeigen nennt und wo es sie gibt? > Datenblatt? Das suche ich auch noch.... sehr Retro :-) Deinen "eigenen" Thread liest Du nicht? Dort steht schon lange, wie die Dinger heißen (TIL311), und ein Bild, auf dem man auch den Stromverbrauch sieht, ist da auch. Und der Stromverbrauch, über den Du bei den NMOS-Chips ja so gern jammerst, ist aber so was von Retro...: Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" Bei Ebay findet man die Displays zahlreich, aber selten billig. Es gibt (oder gab) ähnliche von HP.
Hi! Ich konnte es nicht abwarten und hab den sd Halter bei distrelec besorgt. Nun eine vlt blöde Frage, aber wie löte ich die pins? Kann man die Abdeckung abnehmen ohne dass man was zerstört. Oder gibt's eine eigene Technik?
Harald Nagy schrieb: > Kann man > die Abdeckung abnehmen ohne dass man was zerstört. Ja :-) Auf der Oberseite ist ein kleiner Pfeil. Den Deckel in diese Richtung schieben, dann Deckel einfach aufklappen. Nun kann prima gelötet werden.
Harald schrieb: > Gibt's Neuigkeiten bzgl der SD-Karten-Halter? Da die Ware bei mir eintraf und der Käuferschutz in wenigen Tagen ausläuft, habe ich die Zahlung rückabgewickelt. Die Halter sind immernoch im Shop erhältlich, angeblich mit 100% Zufriedenheit. Nochmals bestellen? http://www.aliexpress.com/item/20PCS-TF-Micro-SD-Card-Connector-Memory-Card-Socket-holder-flip-type/1923989325.html
:
Bearbeitet durch User
> http://www.aliexpress.com/item/20PCS-TF-Micro-SD-Card-Connector-Memory-Card-Socket-holder-flip-type/1923989325.html Was heißt denn "No Feedback Score"? Gibts bei Nicht-Bewertung automatisch die Bestbewertung? Witzig. > Nochmals bestellen? Weiterhin "low priority" Interesse.
Hallo Joe, ich wäre für nochmals bestellen. Was wäre denn die Alternative? Gruß Siggi
> Was wäre denn die Alternative?
(Mikro-)SD-Kartensockel über die Stiftleisten anschließen (Grundplatte).
Ist ja sowieso für die Zweitkarte geplant.
Der Sockel auf meiner Lochraster-Grundplatte ist aber auch immer noch
nicht verdrahtet. Dabei habe die inzwischen von Turm auf Nebeneinander
umgestrickt.
Nur mal eine Frage - kanntet ihr das? Vermutlich schon :-) http://www.pci-card.com/euro-z80.html http://www.pci-card.com/sepia.html#SEPIA-CPU und den NDR-NKC: http://schuetz.thtec.org/ http://www.drcrazy.de/nkc/
Marcel A. schrieb: > Nur mal eine Frage - kanntet ihr das? Danke! Da werden sich aber Hans-Werner und auch Heinrich freuen, dass ihre Internetseiten hier verlinkt werden :-)
Marcel A. schrieb: > Oh - ich war so begeistert... Habe ich was falsch gemacht? Nein, alles OK! Meine Freude war ehrlich gemeint. Beide beschäftigen sich in bewundernswerter Weise mit dieser Technik.
Mein Monitor-Programm kann inzwischen SD-Karten lesen und schreiben. Die BIOS-Schnittstelle, damit der Z180 darauf zugreifen kann, fehlt allerdings immer noch. Aber da ich dieses Jahr sicher nicht mehr dazu kommen werde, stelle ich den aktuellen Stand mal hier rein. Das Programm ist jetzt für 2 Kartensockel konfiguriert. Sockel 0 ist auf der AVR-Stamp-Karte. Für Sockel 1 habe ich bis auf weiteres PG4 für CS und Kartenerkennung vorgesehen. Für CD- und WP-Switches könnten PG3 und PG5, aber natürlich auch andere freie Ports genutzt werden. Darauf, daß man den CS/DAT3-Pin der SD-Karte auch zur Kartenerkennung verwenden kann, bin ich erst vor kurzem gekommen, und habe es gleich mal in das Programm eingebaut. Damit der Pin in dieser Weise funktioniert, muß ein Pulldown-Widerstand, ca. 300K oder größer, angeschlossen sein. Da an dem Pin auf der AVR-Stamp "leider" die LED nach VCC hängt, funktioniert es dort nicht. Falls jemand den MicroSD-Sockel bestückt hat, würde es mich freuen, wenn er die Kartenfunktionen mal testen könnte. Insbesondere würde mich interressieren, ob die Kartenerkennung an dem Sockel funktioniert. Dazu müßte allerdings die LED vom CS-Pin getrennt werden. => sd status 0 Socket status: 01 Mit:
1 | /* Disk Status Bits (DSTATUS) */
|
2 | #define STA_NOINIT 0x01 /* Drive not initialized */ |
3 | #define STA_NODISK 0x02 /* No medium in the drive */ |
4 | #define STA_PROTECT 0x04 /* Write protected */ |
5 | #define STA_FAST 0x08 /* Fast SPI clock */ |
Sehr cool! Vlt komm ich heuer noch zum testen. Kannst du evtl den Quellcode auch hochladen. Schönes Fest und guten Rutsch!
Der Quellcode[1,2] ist immer noch Kraut und Rüben. Zur Zeit nehme ich Tup[3] als Build system (statt Make) Tup hat ggü. Make einige Vorteile, aber: - Läuft auf ungewöhnlichen OS' nicht so gut. - Auf 64-bit Windows läufts wohl immer noch nicht. - Der CP/M-Emulator (für M80) läuft nur mit einem Patch, den der Autor wahrscheinlich nicht aktzeptieren wird. In die Windows-Version bekomme ich den Patch garnicht rein. Inzwischen glaube ich nicht mehr, das man den Build in absehbarer Zeit mit Tup unter Windows vernünftig zum Laufen bekommt. Also müßte mal jemand Makefiles schreiben. [1] http://cloudbase.mooo.com/gitweb/?p=z180-stamp.git [2] http://cloudbase.mooo.com/cgit/z180-stamp/ [3] http://gittup.org/tup/index.html
Joe G. schrieb: > Marcel A. schrieb: >> Oh - ich war so begeistert... Habe ich was falsch gemacht? > > Nein, alles OK! Meine Freude war ehrlich gemeint. Beide beschäftigen > sich in bewundernswerter Weise mit dieser Technik. Ja, mir wird auch ganz warm ums Herz. Das waren noch Zeiten! Z80-CP/M-System mit Faedeldraht auf Lochraster von Hand zusammengebaut. Auf freie "Rechenzeit" am Eprommer im Rechenzentrum gewartet, Kilobyteweise Hexcode eingetippt ... nebenan ratterten die Lochkarten und klackerten die Magnetbaender ... boah bin ich alt. Aber damals waren wir noch jung und schoen ...
Leo C. schrieb: > Falls jemand den MicroSD-Sockel bestückt hat, würde es mich freuen, wenn > er die Kartenfunktionen mal testen könnte. Habe gerade getestet. 1. LED 1 auslöten und durch 330k (1206) ersetzt. 2. R2 auslöten 3. R2/LED1 pin auf GND gelegt (am Reset Taster) vor dem Umbau: sd status 0 Socket status: 01 nach dem Umbau (Scan Disk 1GB) sd status 0 Socket status: 03 (???) sd info 0 No disk sd init 0 No disk
Danke für die Mühe. Joe G. schrieb: > nach dem Umbau (Scan Disk 1GB) > sd status 0 > Socket status: 03 (???) Ohne Karte wäre der Status ok. Leo C. schrieb: > #define STA_NOINIT 0x01 /* Drive not initialized */ > #define STA_NODISK 0x02 /* No medium in the drive */ 2 Möglichkeiten. 1. Die Karte hat keinen Pullup an dem Pin (unwahrscheinlich). 2. Softwarefehler. Der Zweitsockel funktioniert bei mir. Der Erstsockel sollte eigentlich gleich funktionieren. Ich werde mal nachschauen. Dauert aber, da ich gerade nicht viel Zeit habe.
Leo C. schrieb: > muß ein Pulldown-Widerstand... > 1. Die Karte hat keinen Pullup an dem Pin up oder down? Ich habe gerade nochmals in der Beschaltung nachgesehen, soll wohl ein Pullup sein. Ich löte mal um...
:
Bearbeitet durch User
Sehr merkwürdig... mit und ohne eingelegter SD-Card sd status 0 Socket status: 01 sd status 1 Socket status 03 sd info 0 Not initialized sd info 1 No disk
Up. SD-Karten haben am DAT3/CS-Pin einen Pullup[1]. Damit die Leitung ohne Karte nicht in der Luft hängt, braucht man in der Schaltung einen Pulldown x-facher Größe. [1] Fußnote 3 auf Seite 3-1 in [2]: After power up, this line is input with 50Kohm(+/-20Kohm) pull-up (can be used for card detection or SPI mode selection). The pull-up may be disconnected by the user, during regular data transfer, with SET_CLR_CARD_DETECT (ACMD42) command. [2] http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Components/General/SDSpec.pdf Nachtrag: Ist meine E-Mail angekommen?
:
Bearbeitet durch User
Dank Joe funktioniert jetzt auch der Micro-SD-Sockel auf der AVR-Stamp-Karte. In der letzten Programmversion war noch ein Fehler, der nicht nur die Kartenerkennung verhinderte, es fehlte die Steuerung des CS-Signals. Mit der angehängten Version gehts jetzt. Noch ein Hinweis: Joe war so freundlich, die LED aus- und einen Pulldwown-Widerstand einzubauen, um die Kartenerkennung zu testen. Der Umbau ist aber nicht unbedingt notwendig. Mit eingebauter LED kann nur das Fehlen der SD-Karte nicht erkannt werden. Man bekommt dann andere Fehlermeldungen beim Zugriff.
Die RTC Funktion sieht auch fehlerfrei aus :-) Danke! => date Mon Dec 22 10:26:44 2014
Passend zu Leo's verbessertem Monitor eine überarbeitete Version der Doku. Mit ihr sollte RTC und SD-Card bzw. FAT-Filesystem zu testen sein.
Super Doku, Joe! Danke. Als ich die SD-Karten Statusanzeige gebaut hatte, fiel mir schon auf, das der Statuscode 08 (Fast SPI clock) für den Benutzer eher verwirrend als nützlich ist. Ich werde daß Programm ändern, damit er bei der Statusabfrage ausgefiltert wird. Dann muß er auch nicht mehr dokumentiert werden. Sonst noch: Im Unterkapitel Boot Size Configuration, erster Satz, ist ein Wort zu viel. Im Unterkapitel Host Software könnte man noch einen Link zu einem Linux und OS X Programm aufnehmen: https://github.com/Boregard/FBoot-Linux Das Dokument, daß unter [4] verlinkt ist, ist von SanDisk und heißt "SanDisk SD Card Product Manual, Version 2.2" Leider ist es auf der SanDisk Website nicht zu finden. Es wäre schön, wenn jemand dafür einen besseren Link finden würde. Falls sich jemand noch mehr für die Hardware-Details der SD-Karten-Schnittstelle interessiert: Es gibt eine tolle Application note von NXP: AN10911 - SD(HC)-memory card and MMC interface conditioning Link gerade nicht parat, sollte aber leicht zu finden sein.
Danke Leo, die Änderungen sind eingearbeitet. Eine gute Doku zur SD-Card ist auch hier zu finden. https://www.sdcard.org/downloads/pls/simplified_specs/ Der aktuelle Arbeiststand der Doku wie immer hier: http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/manual/ Leos letzter Arbeiststand hier: http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/avr_stamp/Testtools/
So, alles fertig gelötet und provisorischen Kabelsalataufbau zusammengestöpselt (werd mir wohl eine Basisplatine löten). Danke Leo, die on-board SD-Karte funktioniert einwandfrei! Wichtig nur, den Doppelpunkt nach dem 0 nicht zu vergessen..... Eine Frage: wie kann ich prüfen, ob das Z180-Board wirklich läuft?
Harald Nagy schrieb: > Eine Frage: wie kann ich prüfen, ob das Z180-Board wirklich läuft? Zunächst kannst du ja mit dem Monitor einzelne Z180 Befehle in den RAM schreiben und auch ausführen. Außerdem wird bei Start des Monitors Leo's DDT in den RAM geladen und kann über die serielle Schnittstelle des Z180 bedient werden. Dazu muß sie zusätzlich auch verdrahtet werden. Beitrag "Re: Z180-Stamp Modul"
Ah danke! Den Beitrag muss ich anscheinend überlesen haben. Ich dachte, die Z180-Outputs werden zum AVR durchgeschleift... Wenn ich jetzt darüber nachdenke wirds logisch....
Ok, soweit so gut. Leider funktioniert meine Z180-Stamp nicht... Beim Versuch den Speicher manuell zu beschreiben erhalte ich die Fehlermeldung "bus timeout". Ich vermute und befürchte mal, dass bedeutet Lötstellencheck...
Hast du beachtet, dass nicht alle Leitungen zwischen AVR-Stamp und Z180-Stamp 1:1 verbunden sein dürfen (siehe Doku Anhang A).
Ich habe alle Leitungen, die unter "all" zusammengefasst sind, zusammengeschlossen. Weiterhin habe ich mit und ohne CLKO versucht sowie den Jumper am Z180 Board in beiden Stellungen versucht. Bezüglich der Stromversorgung habe ich den Jumper für USB gesetzt, alle GND verbunden, sowie 5 und 3,3 V der beiden Boards verbunden. Entsprechend dem Manual habe ich die Jumper 2/3/4 verbunden. Beim Durchmessen lagen überall die korrekten Spannungen an. Das AVR Board funktioniert vollständig (also auch die Uhr und SD Karte), nur das Z180 Board macht keinen Pieps. Zusatz: Habe eben vorhin die Lötstellen nochmal angesehen. Schaut alles ganz ok aus soweit.
:
Bearbeitet durch User
Es gibt auf dem Z180 Board ein Layoutfehler (Brücke zwischen ZRESET und WAIT)Das Problem wurde hier im Forum schon mal besprochen. Es gibt eine Lösung VOR der Bestückung [1] und eine "Aufbohrlösung" von Leo C. nach der Bestückung. Mit diesem Fehler läuft die CPU nicht. [1] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/z180_stamp/docs/?sortdir=down#dirlist
Auch das habe ich bereits vor dem Löten korrigiert und auf Korrektheit durchgemessen. Ich hab echt keine Ahnung was da nicht passt...
Hallo, als völliger Quereinsteiger hier in diesem Thread, habe ich mich mal durchgelesen und versucht das Projekt im Kopf zusammen zu setzen. Es stellt sich die Frage: Was kann man mit dieser Stamp anfangen? Ist das eine weitere CP/M Plattform zur Benutzung von CPM Programmen oder eine Art "Microcontroller" der sich zur Steueraufgaben einsetzen lässt? Ist die Stamp für sich allein verwendbar oder muss sie ergänzt werden durch Peripherie an den Bus Pins? Für den Z180 gibt es im Netz sehr wenig wie nich finde aber an einem DIP64 Baustein hätte ich schon Interesse, diesen in einem Minicomputer zu verwerkeln.
Ich wünsche allen Mitlesern ein gesundes neues Jahr! Das Z180-Stamp Projekt ist in erster Linie ein Lebensgefühl. Einige der hier Beteiligten sind mit dem Z80 und CP/M bzw. U880 und SCP :-) groß geworden. Es macht einfach immer noch Freude sich mit dieser Technik zu beschäftigen. Vielleicht vergleichbar wie das Basteln mit Röhren. Für heutige Steuerungsaufgaben gibt es sicher geeignetere Prozessoren als den Z180. Prinzipiell könnte man den Z180 ohne weiteren Prozessor (hier der AVR) betreiben. Es gibt auch hier im Forum einige Beiträge die sich damit beschäftigen. In dem hier verfolgten Aufbau übernimmt der AVR die Funktion eines EPROM’s der Kommunikation mit dem Host, der Erzeugung des Takt, der Ansteuerung der SD-Card usw. Letztlich könnte das Z180-Stamp Modul mit einer ECB-Busanpassung mit vorhandener Z80 Hardware kombiniert werden.
Joe G. schrieb: > Das Z180-Stamp Projekt ist in erster Linie ein Lebensgefühl. Einige der > hier Beteiligten sind mit dem Z80 und CP/M bzw. U880 und SCP :-) groß > geworden. Es macht einfach immer noch Freude sich mit dieser Technik zu > beschäftigen Hmm.....also "EPROM mit Fenster" cool finden, grüne Schrift auf schwarzen Monochrom Monitor, IC's, die man ohne Pinzette und Lupe löten kann, Chips die warm werden und damit zeigen dass sie "arbeiten". Einen Timer als Chip, eine UART als Chip dazu, RAM was man in die Hand nehmen kann. Eine CPU die man verstehen kann, ohne E-Technik studiert zu haben. Etwas zu bauen was man heute als 1-Chip Lösung für 2€ kaufen kann, aber ohne "Aha" Erlebnis. Ok...
Bei mir ist es eher umgekehrt. Ich bin mit PCs (Turbo Pascal) 1986 groß geworden, habe also die C64/Apple/... Zeit nicht miterlebt bzw. das waren unerreichbare Dinge, als ich klein war. Das hole ich heute nach, eben weil es darum geht, Dinge auch zu verstehen (wovon ich meilenweit entfernt bin - :-)) und nicht nur zu "usen". Das ist ja auch das große Credo der Herren vom WDR ComputerClub gewesen: Zumindest die Dinge dahinter zu verstehen. Von daher war ich baff erstaunt, als ich letztens mit meinem Kleinen die Sendung mit der Maus schaute und dort ein Taschenrechner erklärt wurde und dafür an einer großen Wand mit Lampen, Kugeln und Taster das Binärsystem inkl. Rechenoperationen erklärt wurde. Aber nun genug der Nostalgie - Hochachtung vor den Leistungen der Hauptaktiven hier - und ich warne schon mal vor bzgl. dummer fragen, denn ich fange dann doch "bald" mal an.
Noch eine Frage bzgl. meiner nicht funktionierenden Z180 Stamp: Muss ich den Pins, die nicht mit dem AVR verbunden sind (wie zb HALT, NMI, WAIT, INT0, INT1, INT2 und andere), definierte Pegel anlegen?
Harald Nagy schrieb: > Muss ich den Pins, die nicht mit dem AVR verbunden sind (wie zb HALT, > NMI, WAIT, INT0, INT1, INT2 und andere), definierte Pegel anlegen? Nein, die liegen bereits auf definiertem Pegel. Du solltest zunächst mal schauen ob am Z180 ein Takt anliegt und ob sie die CPU im Resetzustand befindet. Um den Speicher zu beschreiben muss die CPU dann in den DMA-Mode versetzt werden. Bei korrekter Funktion wechselt dann die CPU in diesen Mode und schaltet die Adress- Daten und Steuerleitungen hochohmig. Leider kann ich das genaue Taktdiagramm dazu derzeit nicht raussuchen, da ich gerade im Urlaub bin. Nächste Woche bin ich wieder verfügbar.
So, ich hab's heute nochmal versucht und mit meinen eher rudimentären Mitteln die Signale gecheckt. An der seriellen Schnittstelle sehe ich trotzdem nichts... Zusammenfassung: - die AVR Stamp läuft - zur Z180 Stamp: * an PHI liegt ein ca 9 MHz Takt - passt * an M1 und MREQ huschen Signale - passt * ZRESET ist high - passt * an den Adress- und Datenleitungen ist Verkehr - passt * an RXA und TXA passiert nix - passt nicht * zu obigen Ergebnissen komme ich sowohl mit Quarz als auch mit CLKO Das bedeutet für mich, dass die CPU läuft nur an der seriellen Schnittstelle kommt tatsächlich nix raus... Leider muss ich die Sachen dieses Wochenende liegen lassen. Vlt ergibt sich ja bis Montag eine Lösung.....
Vielleicht interessiert es ja jemanden (Source-Code von CP/M) u.a. DDT.ASM http://www.computerhistory.org/atchm/early-digital-research-cpm-source-code/
Ja, es gibt einen Entwurf mit einer ECB-Bus Variante, einer RS232 und einer externen SD-Card. Alles im Euro-Format.
Joe G. schrieb: > Vielleicht interessiert es ja jemanden (Source-Code von CP/M) u.a. > DDT.ASM > > http://www.computerhistory.org/atchm/early-digital-research-cpm-source-code/ Grad mal den CPM Source quer gelesen, auch den von Apple Dos, was ich ja aus der Schule noch kenne. Ich wundere mich nur wie schlecht der dokumeniert ist, dass die sowas als Arbeitsergebnis abliefern konnten. Das Aopple Zeug kann man teilweise nur als Geschmiere bezeichnen, was "Woz" da ablieferte.
Joe G. schrieb: > Harald Nagy schrieb: >> Eine Frage: wie kann ich prüfen, ob das Z180-Board wirklich läuft? > > Zunächst kannst du ja mit dem Monitor einzelne Z180 Befehle in den RAM > schreiben und auch ausführen. Außerdem wird bei Start des Monitors Leo's > DDT in den RAM geladen und kann über die serielle Schnittstelle des Z180 > bedient werden. Dazu muß sie zusätzlich auch verdrahtet werden. > Beitrag "Re: Z180-Stamp Modul" Leider hatte ich vergessen einige Änderungen zu erwähnen: Für den Z180 gibt es nun CP/M 3 kompatible Character I/O Routinen [1]. Der erste I/O-Kanal geht auf den AVR, der zweite auf ASCI1 (2. serielle Schnittstelle am Z180). Weitere Kanäle sind noch nicht realisiert. Die DDTZ-Console wird derzeit auf den ersten Kanal geschaltet, also auf den AVR. Der AVR-Monitor hat ein neues Kommando "connect" bekommen, das diesen Kanal auf die Serielle vom AVR verbindet. Will man die DDTZ-Console (zusätzlich) auf ASCI1 haben, geht das z. Zt. nur, in dem man den Console-IN- und den Console-Out-Vector im Z180-RAM ändert, zB. mit dem Befehl mm. Später soll das mal über Environment-Variablen einstellbar sein. Harald Nagy schrieb: > Ich dachte, > die Z180-Outputs werden zum AVR durchgeschleift... Wenn ich jetzt > darüber nachdenke wirds logisch.... Werden sie auch. Jetzt. > Beim Versuch den Speicher manuell zu beschreiben erhalte ich die > Fehlermeldung "bus timeout". Wahrscheinlich fehlte der Takt. > Zusammenfassung: > - die AVR Stamp läuft > - zur Z180 Stamp: > * an PHI liegt ein ca 9 MHz Takt - passt > * an M1 und MREQ huschen Signale - passt > * ZRESET ist high - passt > * an den Adress- und Datenleitungen ist Verkehr - passt > * an RXA und TXA passiert nix - passt nicht Doch, passt. Siehe oben. > * zu obigen Ergebnissen komme ich sowohl mit Quarz als auch mit CLKO Geht denn "Speicher manuell zu beschreiben" jetzt? Funktionieren die anderen Monitor-Befehle (md, mw, mm, cp, cmp)? Damit DDTZ läuft, muß Z180-Stamp Pin A17 (DREQ0) auf Low liegen. Falls er 1:1 mit der AVR-Stamp verbunden ist, geht das mit dem Befehl "pin 2 low". [1] https://archive.org/stream/CPM3-System_Guide#page/n61/mode/2up
Danke für die Hinweise! md hatte ich mal versucht und hat auch funktioniert. Wie gesagt der Takt liegt auch an, sonst würde doch PHI keinen Output geben (ich hoffe ich liege da richtig). Connect habe ich auch mal eingegeben. In der Hoffnung, das ist der Befehl zum verbinden. Anscheinend liege ich da auch richtig. Allerdings hat sich der Monitor dann aufgehängt und reagierte nicht mehr auf eingaben. Jedenfalls werde ich es morgen nochmals versuchen! Im Fall dass alles funktionert steht als nächstes eine Schaltung für ein Basisboard für beide Stamps an....
Harald Nagy schrieb: > Connect habe ich auch mal eingegeben. In der Hoffnung, das ist der > Befehl zum verbinden. Anscheinend liege ich da auch richtig. Allerdings > hat sich der Monitor dann aufgehängt und reagierte nicht mehr auf > eingaben. Raus kommt man wieder mit "Control-^ X". Mit "Control-^ ?" bekommt man ein kleines Hilfe-Menu. Allerdings bleibt der Connect-Befehl hängen, wenn DDTZ nicht läuft. (Hier inzwischen korrigiert)
@all: hat noch keiner ausser Joe und Leo mit den Stamps gespielt? @Leo: Ich fasse zusammen: alles unverändert. Anscheinend steht im RAM nach dem Hochfahren irgendein Schrott?! Die CPU läuft, der AVR kann den RAM lesen und beschreiben. Wenn ich connect eingebe hängt sich der AVR-Monitor >>tatsächlich<< auf. Komme mit keiner Tastenkombination wieder auf die Kommandozeile. BTW das Kommando zum Abbrechen ist doch Ctrl-c? Die beiden anderen, die du angegeben hast, führen zu keiner Reaktion.... @Joe: Falls du noch Platinen über hast bzw. vor hast nochmal welche anfertigen zu lassen, könntest du mich für jeweils eine vormerken?
:
Bearbeitet durch User
Doch. Worauf willst du hinaus? Dass der Debugger nicht läuft? Ja, das denke ich auch - aber was dagegen tun? Das Image im Flash ist doch ok nehme ich an...
:
Bearbeitet durch User
Harald Nagy schrieb: > BTW das > Kommando zum Abbrechen ist doch Ctrl-c? Die beiden anderen, die du > angegeben hast, führen zu keiner Reaktion.... Sorry, ich hatte den zweiten Satz von Dir nicht gelesen. ;-( Ctrl-C kann natürlich nicht zum Beenden verwendet werden, da es an den Z180 geschickt werden muß. (CP/M Reboot, Wordstar Page Down, ...) Jedes "Terminalprogramm" verwendet für den Übergang in einen Befehlsmodus andere "ESCAPE Character". Ich habe mich für Ctrl-^ entschieden, weil Ctrl-A (screen, minicom) genauso unpraktisch wie Ctrl-C ist, und andere übliche "Fluchtzeichen" auf einer deutschen Tastatur zu umständlich sind (Telnet: Ctrl-[ Kermit: Ctrl-\). Also '^' (caret, das Dach) bei gedrückter Control-Taste drücken, und danach z.B. '?' für das Menu. Geht in der aktuellen Programmversion aber nur, wenn der DDTZ richtig läuft, oder als Allererstes nach dem 'connect' eingegeben wird.
Danke für die Aufklärung. Aber leider funktionierts nicht. Nach wie vor hängt sich der AVR-Monitor nach dem Eingeben von "connect" auf und reagiert auf keine Eingaben mehr.
Harald Nagy schrieb: > @Leo: Ich fasse zusammen: alles unverändert. Anscheinend steht im RAM > nach dem Hochfahren irgendein Schrott?! Das ist bei RAMs so üblich. Durch den AVR wird das RAM erst auf ausdrücklichen Wunsch des Benutzers initialisiert. > Die CPU läuft, der AVR kann den RAM lesen und beschreiben. Mach das mal systematisch. ZB.: => mw 0 76 80000 Ganzes RAM mit 0x76 (HALT) füllen. => md 0 Überprüfen, ob am Anfang des RAMs 0x76 steht. => cmp 0 1 80000 Jeweils 2 aufeinanderfolgende Bytes vergleichen. Da das ganze RAM mit 0x76 gefüllt ist, sollt kein Fehler kommen. => go 0 Z180 sollte einen Halt-Befehl ausführen und stehen bleiben. Halt-Ausgang sollte Low sein. Wenn Du hier eine LED angeschlossen hast, sollte sie leuchten. => reset Halt-Ausgang geht wieder auf High (LED aus). Wenn das so funktioniert, kannst Du z.B. den Speicher kommplett mit 0 (NOP) füllen (überprüfen). Nach einem 'go 0' führt der z180 nur NOPs aus, im Adressbereich von 0x000 bis 0xffff. Auf den Adressleitungen A0 bis A15 sollte ein regelmäßiges Muster mit jeweils halbierter Frequenz zu sehen sein. Auf A0 bis A6 allerdings gestört durch den Refresh. A16 bis A19 sollten dauerhaft auf low liegen. > Wenn ich connect eingebe hängt sich der AVR-Monitor >>tatsächlich<< auf. Wurde denn vorher der DDTZ ins RAM geladen und gestartet? Und ist dabei DREQ0 auf low?
Werde die Überprüfung durchführen. Zu meiner Vorgehensweise: Beim booten wird ja das ram automatisch beladen. Das meinte ich mit hochfahren. ich hab den autoboot unterbrochen. Dann pin 2 low loadf go 0x000 connect allerdings habe ich auch schon verschiedene abfolgen versucht. Zb auch a17 extern auf low
> ich hab den autoboot unterbrochen. Dann > pin 2 low > loadf > go 0x000 > connect Gut, daß Du das mal so deutlich hingeschrieben hast. Wenn das nicht tut, muß noch irgendwo ein Hardware- oder Verdrahtungs-Fehler sein. Bei mir war z.B. ein Pin vom RAM nicht angelötet. Das war nicht mal mit Lupe zu erkennen. > allerdings habe ich auch schon verschiedene abfolgen versucht. Zb auch > a17 extern auf low Kann man ja nachmessen. > go 0x000 Das funktioniert nur zufällig richtig. Die Parameter bei diesen Befehlen sind grundsätzlich Hex. 0x muß nicht und darf nicht angegeben werden. Die Inputroutine ist allerdings schlampig programmiert und liest nur bis zum ersten ungültigen Zeichen, hier 'x'. Alles davor wird als Zahl gnommen, hier 0.
Bevor ich anfange nachzulöten, habe ich alle Verbindungen durchgemessen. Alles soweit ok (Beinchen zu Beinchen nicht Lötstelle zu Lötstelle). Langsam bekomme ich den Verdacht, dass es an der Verkabelung mit Jumperkabeln liegt.... Der RAM wird beim vollständigen beschreiben mit zb 76 vollgeschrieben. Allerdings treten systematisch Fehler auf. Wenn ich die Kabel etwas bewege gibts zwar ein anderes aber doch ein System beim falsch beschriebenen RAM. Muss ich mir nun doch erst ein Baseboard basteln... Stapeln will ich nicht unbedingt (ich will die Pins nicht kappen....)
Das VT-100 Terminal Projekt ist wieder ein Schritt weiter. Ich habe dazu einen extra Beitrag aufgemacht. Beitrag "VT100-Terminal (VGA+PS2)"
Moin, ich bin gerade dabei, meine AVR-Stamp zu testen. Das board habe ich separat mit 3,3 V versorgt, Z180-Stamp ist nicht angeschlossen. Bootloader über ISP geflasht, ...-4.1.hex mit AVRFLASH2.1 übertragen (aus dem SVN). (was ist denn der Unterschied zur ...-4.2.hex?) Monitor meldet sich und lässt sich bedienen. RTC kann ich einstellen und auslesen, aber die SD geht nicht: sd status 0 socket status: 01 (03 ohne Karte) sd info 0 not initialized command failed, result=1 sd init 0 rc=01 command failed, result=1 SD ist eine 2 GB Transend, aber auch mit 32 GB samsung getestet, FAT und FAT32. Ich habe den Eingang auch schon mit 330kOhm auf GND gelegt, aber dann bekomme ich als socket status immer 03. Die Leitungen ATMEGA zur SD habe ich durchgemessen, ok. Jemand ne Idee? Gruss Peter
> (was ist denn der Unterschied zur ...-4.2.hex?) Kosmetik. Details gibts hier: http://cloudbase.mooo.com/cgit/z180-stamp/ > SD geht nicht: > > sd status 0 > socket status: 01 (03 ohne Karte) Hast Du die LED1 am Kartensockel bestückt? (Eigentlich sollte dann gar kein Unterschied zwischen Karte gesteckt/nicht gesteckt erkennbar sein.) > sd info 0 > not initialized > command failed, result=1 Der Befehl funktioniert erst nach erfolgreichem 'init'. > sd init 0 > rc=01 > command failed, result=1 Warum init hier nicht geht, weiß ich auch nicht. Ich probier mal was...
Eine Frage: Denkt ihr dass bei der verwendeten Frequenz eine Basisplatine mit Fädeldraht verdrahtet noch funktioniert. Nachdem ich kein Elektrotechniker bin und meine Erfahrungen noch etwas beschränkt sind würde ich gerne eure Meinungen hören bevor ich loslege...
Harald Nagy schrieb: > Eine Frage: Denkt ihr dass bei der verwendeten Frequenz eine > Basisplatine mit Fädeldraht verdrahtet noch funktioniert. Bei mir funktionierts. Den Bus und weitere Versorgungsleitungen habe ich mit 0,3mm Lackdraht gelötet, und den Rest (SD-Kartenhalter, serielle Schnittstellen, HALT-Led) mit dem ganz dünnen Fädeldraht. Für VCC der SD-Karte mußte ich allerdings ein LC-Filter spendieren. Sonst gabs beim Einstecken einer Karte Brownout-Resets. C alleine hat nicht gereicht.
Aus meiner Sicht (Version ohne LED) läuft die Version *stamp-monitor-hexrel-4.2-test-sd-cd.hex* wie sie soll (siehe unten). Einzig mit der Meldung z80_memfifo_init: 0, 7c320 z80_memfifo_init: 1, 7c21d z80_memfifo_init: 2, 7c423 z80_memfifo_init: 3, 7c526 kann ich nichts anfangen. => sd status 0 Socket status: 01 => sd init 0 rc=00 => sd info 0 Drive size: 1984000 sectors Erase block: 8192 sectors Card type: 4 CSD: 00000: 00 26 00 32 5f 59 83 c8 be fb cf ff 92 40 40 d7 .&.2_Y.......@@. CID: 00000: 03 53 44 53 55 30 31 47 80 50 48 8b cb 00 96 97 .SDSU01G.PH..... OCR: 00000: 80 ff 80 00 .... SD Status: 00000: 00 00 00 00 00 00 00 28 01 01 90 00 0a 05 00 00 .......(........ 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ => fatstat 0: FAT type: 2 Bytes/Cluster: 16384 Number of FATs: 2 Root DIR entries: 512 Sectors/FAT: 242 Number of clusters: 61935 FAT start (lba): 1 DIR start (lba,cluster): 485 Data start (lba): 517 Volume name: Volume S/N: 1234-5678 66 files, 924663 bytes. 6 folders. 990960 KB total disk space. 989120 KB available.
Joe G. schrieb: > Aus meiner Sicht (Version ohne LED) läuft die Version > *stamp-monitor-hexrel-4.2-test-sd-cd.hex* > wie sie soll (siehe unten). Danke. Bei Harald gehts auch. Von Peter kam gerade eine Mail, daß es bei ihm noch nicht geht. >Einzig mit der Meldung > > z80_memfifo_init: 0, 7c320 > z80_memfifo_init: 1, 7c21d > z80_memfifo_init: 2, 7c423 > z80_memfifo_init: 3, 7c526 > > kann ich nichts anfangen. Macht nichts. ;-) Das sind Debug-Meldungen, die besagen, daß im Z180-RAM FIFOs für den Datenaustausch angelegt wurden. 2 davon sind für die DDTZ-Console, zu der Du Dich mit 'connect' verbinden kannst.
Leo C. schrieb: > Das sind Debug-Meldungen, die besagen, daß im Z180-RAM FIFOs für den > Datenaustausch angelegt wurden. Ok, danke. Aber connect geht nicht mehr :-( Das System bleibt irgendwo hängen.
@Leo: Deine Mail ist erst jetzt angekommen!? Hier mein Ergebnis zum Test der Firmware *stamp-monitor-hexrel-4.2-test-sd-cd.hex*: > Hi! > > Da es bei mir gerade zeitmässig eher eng zugeht, hab ich nur mal schnell > die neue Firmware geflasht und die SD/FAT-Befehle durchprobiert: > funktioniert alles > Ich habe die Bestückung mit LED (wie auch im GIT angegeben). > Die LED funktioniert jetzt auch. > Ich bin mir nicht sicher, aber wenn ich > mich recht erinnere, hat die LED bei der vorigen Version 4.2 nicht > funktioniert. Kommentar von Leo: Eigentlich müßte sie trotzdem brennen, und vielleicht garnicht richtig ausgehen. Der Pin wird bei der Version zwischen den Zugriffen auf Input geschaltet, um eine eingesteckte Karte zu erkennen. Allerdings kann das mit Led nicht richtig funktionieren. Ist aber im Moment nicht wichtig. Anmerkung: Ich habe nochmal versuchsweise die 4.2 Firmware geflasht um die LED-Sache zu überprüfen. Mit dieser Version leuchtet die LED nie.
:
Bearbeitet durch User
Zum Thema Basisplatine: Habt ihr diese in der Art gebaut, wie hier im Thread einmal gepostet? Gibt es da evtl ein Schaltplan-Update? Sollte ich demnächst mal Zeit haben will ich mir nämlich eine solche zusammenbasteln um auch endlich die Z180-Stamp zum Laufen zu bringen...
Joe G. schrieb: > Ok, danke. Aber connect geht nicht mehr :-( Das System bleibt irgendwo > hängen. Ging das denn schonmal bei Dir? Hier funktionierts. Egal welche Programmversion. Harald Nagy schrieb: > Anmerkung: Ich habe nochmal versuchsweise die 4.2 Firmware geflasht um > die LED-Sache zu überprüfen. Mit dieser Version leuchtet die LED nie. Auch nicht bei erfolgreichen Zugriffen auf die SD-Karte? Das kann eigentlich garnicht sein. Wenn die LED richtig angeschlossen ist, muß sie leuchten, wenn CS low geht. Und ohne CS auf low ist kein Datentransfer zu oder von der Karte möglich. Ich habe es jetzt auch nochmal mit beiden Versionen ausprobiert. Ohne SD-Karte blitzt die LED bei 'sd init 0' kurz auf. > Zum Thema Basisplatine: Habt ihr diese in der Art gebaut, wie hier im > Thread einmal gepostet? Gibt es da evtl ein Schaltplan-Update? Im Anhang ist mein Schaltplan. Nicht unbedingt zur Nachahmung empfohlen. Ich habe nur das drauf gebaut, was ich gerade zum Testen brauche. Die Jumper für die Taktumschaltung braucht außer mir wahrscheinlich kein Mensch.
Leo C. schrieb: > Harald Nagy schrieb: >> Anmerkung: Ich habe nochmal versuchsweise die 4.2 Firmware geflasht um >> die LED-Sache zu überprüfen. Mit dieser Version leuchtet die LED nie. > > Auch nicht bei erfolgreichen Zugriffen auf die SD-Karte? Nein definitiv nicht. Keine Ahnung warum aber es ist so. Im Grund aber egal, Hauptsache die SD-Karte funktioniert. Ist ja nicht die einzige unbeantwortete Frage im moment für mich....
Frustration macht sich breit... Die Probleme mit dem RAM hab ich immer noch. Ich habe mir jetzt ein Baseboard gelötet (nach dem Schaltplan von Leo, ohne SD und Clock-Umschaltung). Funktioniert soweit. Aber der RAM macht Probleme. Der Test mit mw/md/cmp ist nie erfolgreich. cmp bricht aber immer an unterschiedlichen Stellen ab. Manchmal kommt auch bei cmp ein Fehler und wenn ich mir die Speicherstelle mit md ansehe, passt egtl alles??? Weiterhin ist mir aufgefallen, dass md mal schneller mal langsamer (eine Zeile pro Sekunde ca) ist??? Ich habe bereits in meiner Verzweiflung alle Pins am AVR und RAM nachgelötet und alle Verbindungen Pin-zu-Pin durchgemessen aber unverändertes Verhalten. Die Fehler sind dieselben egal ob CLKO oder Quarz, ob USB-Stromversorgung oder Einspeisung von 5V-extern.... Mir sind die Ideen ausgegangen und langsam verlässt mich leider auch die Lust... Jemand noch Ideen was ich überprüfen und ausprobieren kann?
Harald Nagy schrieb: > Jemand noch Ideen was ich überprüfen und ausprobieren kann? Beide Platinen in Huckepackbauweise testen.
Joe G. schrieb: > Harald Nagy schrieb: >> Jemand noch Ideen was ich überprüfen und ausprobieren kann? > > Beide Platinen in Huckepackbauweise testen. Dann muss ich die Stiftleisten stutzen was ich egtl vermeiden wollte....
Hallo zusammen,
ist ja ziemlich ruhig hier geworden ("an die eigene Nase fass") - wie
ist denn der Stand?
Gibt es etwas neues zum Thema Basis-Board?
Beste Grüße
Marcel
Hallo zusammen, ich habe am Wochenende nun beide Stamps zusammengelötet, jetzt bin ich also "startklar". Am nächsten WE würde ich mir nun gerne das Thema Software vornehmen. Beim Review des Threads und der Anleitung habe ich noch so ein paar Fragen: - Wie sieht es denn mit einem Base-Board aus? Bisher habe ich nur den Schaltplan von Leo und den „Lochraster-Entwurf/Schaltplan“ von Leo gesehen. Ich kann da in Eagle (free) nichts machen, müsste dann auf KiCad umsteigen... - Apropos Baseboard: Ich hadere mit den aus meiner Sicht Widersprüchen: In Leos Verdrahtung werden beide seriellen Schnittstellen des Z180 auf externe Anschlüsse geführt. In der Beschreibung heißt es aber, dass SER1 auf den AVR verbunden ist und darüber auch die DDT-Kommunikation funktioniert….? - Welche fuses muss ich einstellen, wenn die den hexmon 4.2 für einen ersten ohne bootloader direkt in avr flashen möchte? - Da ich noch keinerlei Erfahrnung mit Bootloadern gemacht habe: Weiter oben ist ein bootloader.hex drin, kann ich den nehmen? Und wie brenne ich den an die richtige Stelle? Aber hier muss ich vermutlich noch mal genauer die Anleitung von Peter Dannegger lesen (mikrocontroller.net war gestern Abend down). Vielen Dank! Gruß Marcel
Marcel A. schrieb: > - Apropos Baseboard: Ich hadere mit den aus meiner Sicht Widersprüchen: > In Leos Verdrahtung werden beide seriellen Schnittstellen des Z180 auf > externe Anschlüsse geführt. In der Beschreibung heißt es aber, dass SER1 > auf den AVR verbunden ist Wo steht das? > und darüber auch die DDT-Kommunikation funktioniert….? Z180 und AVR können über Bereiche im SRAM kommunizieren. Darüber läuft z.Zt. auch die DDTZ-Console. Prinzipiell kann diese auf eine der seriellen Schnittstellen des Z180 umgelegt werden. Die Software für die Umschaltung ist aber noch nicht fertig. > - Welche fuses muss ich einstellen, wenn die den hexmon 4.2 für einen > ersten ohne bootloader direkt in avr flashen möchte? Du kannst Die von hier nehmen (Beitrag "Re: Z180-Stamp Modul") Low High Extended ---------------------------------- Mit Bootloader AF D6 F5 Ohne Bootloader AF D1 F5 Der Unterschied ist hier die BOOTRST-Fuse. (Und die BOOTSZ-Fuses, aber die sind bei nicht gebrannter BOOTRST-Fuse relativ egal.) Hier kann man mit den Fuses experimentieren: http://www.engbedded.com/fusecalc/ (Bin mir nicht sicher, ob für die Extended Fuses in der PDF-Doku ein Tippfehler ist, oder ob Joe die Brown-Out-Detection disabled lassen möchte. Letzteres ist nicht empfehlenswert, da dann der EEPROM-Inhalt zerstört werden kann.) > - Da ich noch keinerlei Erfahrnung mit Bootloadern gemacht habe: Weiter > oben ist ein bootloader.hex drin, kann ich den nehmen? Ja. > Und wie brenne > ich den an die richtige Stelle? Wie jede andere Datei auch: einfach flashen. Der Programmer kümmert sich schon um die richtige Stelle, da die Intel-Hex-Datei ja Lade-Adressen enthält.
Leo C. schrieb: > (Bin mir nicht sicher, ob für die Extended Fuses in der PDF-Doku ein > Tippfehler ist, oder ob Joe die Brown-Out-Detection disabled lassen > möchte. War tatsächlich ein Tippfehler 5F macht keinen Sinn, ist in der Doku geändert. Nachtrag: Das Basisboard gibt es in EAGLE, es gab bisher nur noch keinen Bedarf hier. Die Fertigung 100x160 wird auch etwas mehr kosten als die Billigteile aus Fernost.
:
Bearbeitet durch User
Danke Leo, hab's kapiert mit der Console. Basisboard ist tatsächlich ein Problem in China, aber es gibt bei iteastudio usw. bis 10x15 (fehlt 1cm...). Da war auch noch ein anderer recht günstiger dabei. Könnte ich raussuchnm, elecrow war es nicht :-) Ich wäre daher auch mit einem Board dabei.
Angehängte Dateien:
-
Z180.jpg
210 KB
So, der AVR Stamp läuft! Sogar auf Anhieb. Ich hatte nur gedacht, ich hätte den SD-Reader verkehrt herum eingebaut, da ich nicht verstanden habe, wie man die SD-Karte hineinbekommt und hatte ihn wieder ausgelötet. Dabei ist mir aufgefallen, dass man sie (entgegen denen, die ich sonst verwende) "einlegen" muss... Als RC beim sd init erhalte ich allerdings "00" und nicht "08" wie in der Doku - ansonsten sieht der SD-Zugriff aber ok aus. RTC geht auch.
1 | ### Reset reason(s): External. |
2 | ### Setting I2C clock Frequency to 100000 Hz. |
3 | |
4 | ATMEGA1281+Z8S180 Stamp Monitor |
5 | |
6 | ### main_loop entered: bootdelay=3 |
7 | |
8 | ### main_loop: bootcmd="reset; loadf; go ${startaddr}"
|
9 | Hit any key to stop autoboot: 0 |
10 | ## CPU now in reset state. |
11 | Loading Z180 memory... |
12 | From: 0x00000 to: 0x001B9 ( 442 bytes) |
13 | From: 0x001C2 to: 0x02D9E (11229 bytes) |
14 | From: 0x02DAE to: 0x03194 ( 999 bytes) |
15 | ## Starting application at 0x0000 ... |
16 | => sd init 0 |
17 | rc=00 |
18 | => sd info 0 |
19 | Drive size: 7716864 sectors |
20 | Erase block: 8192 sectors |
21 | Card type: 12 |
22 | CSD: |
23 | 00000: 40 0e 00 32 5b 59 00 00 1d 6f 7f 80 0a 40 00 a1 @..2[Y...o...@.. |
24 | CID: |
25 | 00000: 02 54 4d 53 41 30 34 47 13 38 ad fb 58 00 e1 31 .TMSA04G.8..X..1 |
26 | OCR: |
27 | 00000: c0 ff 80 00 .... |
28 | SD Status: |
29 | 00000: 00 00 00 00 02 00 00 00 02 02 90 01 00 aa 00 00 ................ |
30 | 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
31 | 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
32 | 00030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
33 | => fatstat 0: |
34 | FAT type: 3 |
35 | Bytes/Cluster: 32768 |
36 | Number of FATs: 2 |
37 | Root DIR entries: 0 |
38 | Sectors/FAT: 941 |
39 | Number of clusters: 120320 |
40 | FAT start (lba): 14502 |
41 | DIR start (lba,cluster): 2 |
42 | Data start (lba): 16384 |
43 | Volume name: INTENSO |
44 | Volume S/N: 4BB6-F93A |
45 | |
46 | 0 files, 0 bytes. |
47 | 0 folders. |
48 | 3850240 KB total disk space. |
49 | 3850208 KB available. |
50 | => fatls 0: |
51 | 0 File(s), 0 bytes total |
52 | 0 Dir(s), 3850208K bytes free |
53 | => date 032416492015.00 |
54 | Tue Mar 24 16:49:00 2015 |
55 | => date |
56 | Tue Mar 24 16:49:05 2015 |
57 | => |
Jetzt muss ich mal schauen, wie ich den Z180 angebunden bekomme... Auf so eine wilde Lochraster-Party habe ich eigentlich keine Lust. Mal sehen... Noch eine andere Frage: Warum haben eigentlich all diese Projekte 18,432MHz? Gruß Marcel
Marcel A. schrieb: > So, der AVR Stamp läuft! Glückwunsch! > Als RC beim sd init erhalte ich allerdings "00" und nicht "08" wie in > der Doku - ansonsten sieht der SD-Zugriff aber ok aus. Anmerkung dazu hier, erster Absatz: Beitrag "Re: Z180-Stamp Modul" > Jetzt muss ich mal schauen, wie ich den Z180 angebunden bekomme... Auf > so eine wilde Lochraster-Party habe ich eigentlich keine Lust. Mal > sehen... Das ist wohl Geschmacksache. Ich kann an Lochraster nichts wildes finden. Stapeln wäre noch eine Möglichkeit. Wenn Du die Stapelbuchsen eingelötest hättest... > Noch eine andere Frage: Warum haben eigentlich all diese Projekte > 18,432MHz? Was sind denn "alle diese Projekte"? 18,432MHz ist die höchste Baudratenfrequenz unter 20MHz. Der Z8SZ180 ist bei 3,3V bis maximal 20MHz spezifiziert. Der AVR ist dann schon deutlich übertaktet, läuft aber erfahrungsgemäß noch einwandfrei.
Marcel A. schrieb: > So, der AVR Stamp läuft! Gratulation! Marcel A. schrieb: > Noch eine andere Frage: Warum haben eigentlich all diese Projekte > 18,432MHz? Es gibt hier im Forum einen schönen Artikel zur Historie: http://www.mikrocontroller.net/articles/Baudratenquarz Marcel A. schrieb: > Jetzt muss ich mal schauen, wie ich den Z180 angebunden bekomme... So: Beitrag "Re: Z180-Stamp Modul"
Ich hadere gerade mit der von Leo gezeigten Einbindung des Linux bootloaders in minicom. Zunächst erzeugt mir das make-file die Datei "bootloader" - im screen ist aber "fboot" zu lesen - vermutlich wurde das umbenannt? Dann kann ich im screenshot (wahrscheinlich) nicht alle Parameter-Aufrufe sehen... Leo, kannst du mal den ganzen Aufruf posten, falls da noch was kommt? Ich verstehe das mit den Parametern so nämlich nicht. Laut MiniCom-Doku gibt es hier
1 | '%l' is expanded to the complete filename of the dial out-device, |
2 | '%f' is expanded to the serial port file descriptor and |
3 | '%b' is expanded to the current serial port speed. |
In der Bootloader-Doku steht:
1 | bootloader [-d /dev/ttyS0] [-b 9600] -[v|p] file.hex |
2 | -d /dev/ttynn serial device, (use e.g. /dev/serial/by-id/usb-FTDI* for FT232) |
3 | -b nn Baudrate |
Im Screenshop steht aber:
1 | fboot -d %l -b %... |
Müsste dann da nicht
1 | fboot -d %f -b %b -p %l |
stehen?
Bin unterwegs und kann gerade nicht nachschauen, was bei mir wirklich konfiguriert ist. Ich glaube aber schon, daß ich eine funktionierende Konfig gepostet hatte.
Hallo Marcel, hatte Dein Problem ganz vergessen. Falls es noch nicht erledigt ist: > Zunächst erzeugt mir das make-file die Datei "bootloader" - im screen > ist aber "fboot" zu lesen - vermutlich wurde das umbenannt? ja > Im Screenshop steht aber:fboot -d %l -b %... > Müsste dann da nichtfboot -d %f -b %b -p %l > stehen? Der volle Eintrag (~/.minirc.dfl) lautet bei mir:
1 | pu pprog10 /usr/local/bin/fboot -d %l -b %b -p |
Angehängte Dateien:
-
z80-stamp.jpg
190 KB
Falls es jemand interessiert. ;-) Ich habe mir jetzt ein Z80-Stamp gebaut. Den Entwurf hatte ich schon vor einem halben Jahr gemacht und auch mit dem Bau angefangen. Leider fehlten mir ein paar Widerstände, und so war das Ding erst mal wieder in der Versenkung verschwunden. Die Platine habe ich mit CPU, RAM (max 128K), SIO und CTC bestückt, um der Z180-Stamp möglichst nahe zu kommen. ;) Takt kommt von einem der freien AVR-Ports, da man CLKO für die 4MHz CPU natürlich nicht nehmen kann. 2 CTC Kanäle erzeugen den Takt für die seriellen Schnittstellen. Der Input für diese Kanäle kann auch von AVR-Port geliefert werden. Das RAM ist z.Zt nur mit 8K bestückt, da ich keinen größeren Baustein im DIL-Gehäuse da habe. Das muß natürlich bald geändert werden, da in 8K noch nicht einmal mein schöner DDTZ paßt.
Wo haste den den Schicken CTC ausgeraben.. sehe ich das erste mal in Keramik.. Gruß, HOlm
Angehängte Dateien:
-
ROM-IO.jpg
180 KB
> Wo haste den den Schicken CTC ausgeraben.. sehe ich das erste mal in > Keramik.. Das hättest Du mich mal vor gut 30 Jahren fragen müssen. Da habe ich das sicher noch gewußt... Aktuell stammt sie aus meinem Schatzkästchen, in dem jetzt aber nur noch die TR1402 in Keramik sind. Eine weitere Keramik-CTC habe ich noch auf meiner alten I/O-Karte. In dem leeren Steckplatz war die SIO, die ich jetzt für die Stamp-Karte geklaut habe. An dem Keramik-8255 war übrigens meine 8-Zoll-Floppystation angeschlossen (je ein Port für Daten-IN, -Out, und Steuerung).
Ich bin nun auch auf den bootloader umgeschwenkt. Obwohl das HEX des bootloaders nur 2K groß ist, hat er 128k geflashed. N denne, muss wohl. Mit UpdateBootloader unter Windoof war ich dann nicht erfolgreich, da sich das Programm über eine falsche Prüfsumme von Leos Test-hex (4.2) beschwert und ich daher kein Flash starten konnte. AVRFlash klappte dagegen problemlos. Unter Linux habe ich bootloader eingerichtet, auch mit minicom-Verbindung. Hier muss ich aber gefühlte 10x den Reset-Knopf an der AVR-Stamp drücken, bis der bootloader das merkt und den upload startet. Scheint wohl ein timing-Problem zu sein - manchmal finden sie sich auch gar nicht. Die SW von Leo sieht ja wirklich sehr professionell aus, wenn mal mal schaut, was help so auswirft. Leider sagt mir das meiste noch nichts. Was macht man z.B. mit den fat-Befehlen? Den Z180-Speicher in eine Datei schreiben usw.? Ich habe mir jetzt erst mal Fädeldraht und Stift bestellt, damit ich eine Basis-Platine "stricken" kann. Gibts denn auch irgendwo den aktuellen Stand der ECB-Platine? Gruß Marcel
Marcel A. schrieb: > Unter Linux habe ich bootloader eingerichtet, auch mit > minicom-Verbindung. Hier muss ich aber gefühlte 10x den Reset-Knopf an > der AVR-Stamp drücken, bis der bootloader das merkt und den upload > startet. Scheint wohl ein timing-Problem zu sein - manchmal finden sie > sich auch gar nicht. Das Problem hatte ich auch, ist seit neuestem komischer Weise weg. Keine Ahnung was sich geändert hat. Es geht aber gut, wenn man Reset gedrückt hält, wenn man den bootloader startet. Aber wg. des Problems hatte ich mal eine Testversion des Monitors mit Bootloader-Support gemacht. Die sollte inzwischen in Deinem Posteingang sein. > schaut, was help so auswirft. Leider sagt mir das meiste noch nichts. Die meisten Befehle haben eine eigene Hilfe, wenn man "help 'befehl'" eingibt. Oft kommen nur die Parameter, aber manchmal auch mehr. > Was macht man z.B. mit den fat-Befehlen? Den Z180-Speicher in eine Datei > schreiben usw.? Genau. Gerade die fat-Befehle haben ausführliche Hilfe.
Hier mal ein kleines Update des Monitors. Neue Befehle: mdc - memory display cyclic mwc - memory write cyclic mloop - infinite loop on address range mloopw - infinite write loop on address range mtest - simple RAM read/write test loadi - load intel hex file Mtest ist nicht ganz so 'simple'. Es versucht immerhin heraus zu bekommen, ob Schlüsse oder Unterbrechungen auf Datenbus und/oder Adressbus vorhanden sind. Loadi lädt Intel-Hex über die Consolenschnittstelle. Das habe ich eingebaut, weil bei meiner Z80-CPU-Karte das ganze System mit 5V läuft, und ich deshalb die SD-Karten nicht nehmen kann.
Leo C. schrieb: > Hier mal ein kleines Update des Monitors. Neue Befehle: Danke, läuft bei mir! Ich habe die Doku gleich um mdc und mtest erweitert. Marcel A. schrieb: > Gibts denn auch irgendwo den aktuellen Stand der ECB-Platine? Ich würde sie gerne nochmals "anfassen". Mit Leos "LoadI" könnte man beide Stamp's komplett mit 5V (SD auf Z180 Stamp darf nicht gesteckt sein!) laufen lassen. Damit hätte man einen 5V ECB-Bus. Vielleicht ist ein Levelshifter auf der ECB-Platine für die externe SD-Card ganz nützlich.
Bei mir gehts auch - wobei er nach dem FBOOT-Upload in einer Endlos-Bootschleife hing (zählte nur noch bis 2 runter) - ein Reset half. Zur Platine: Klingt vielversprechend! Schönen Abend noch
Marcel A. schrieb: > Bei mir gehts auch - Damit ist Dein Auto-Bootloader-Feature wieder weg... > wobei er nach dem FBOOT-Upload in einer > Endlos-Bootschleife hing (zählte nur noch bis 2 runter) - ein Reset > half. Das hatte ich vor kurzem auch. Liegt, bzw. lag, sicher an besagtem Feature. Der Watchdog wird wahrscheinlich nicht abgeschaltet.
Joe G. schrieb: > beide Stamp's komplett mit 5V (SD auf Z180 Stamp darf nicht gesteckt > sein!) laufen lassen. Damit hätte man einen 5V ECB-Bus. Vielleicht ist > ein Levelshifter auf der ECB-Platine für die externe SD-Card ganz > nützlich. Levelshifter nur für den SD-Slot, statt für den ganzen ECB-Bus, ist natürlich weniger Aufwand. Wenn man für den Bus Treiber braucht, relativiert sich die Einsparung aber wieder. Allerdings muß auf der AVR-Stamp ein Pin des FTDI-Chips umverdrahtet werden.
Ich habe noch verschiedenen eZ80Acclaim Module herum liegen und mich schon gefragt, was ich damit noch anfangen soll. Kann man mit diesen Modulen auch noch mitspielen? http://www.zilog.com/index.php?option=com_product&task=dev_tool_detail&DevToolKit=eZ80F920200ZCOG
So, ich fang jetzt mal mit Lötfädeltechnik an :-) BTW - habt ihr auch vor, für das System ein CPM-Bios zu entwickeln?
Marcel A. schrieb: > BTW - habt ihr auch vor, für das System ein CPM-Bios zu entwickeln? Wer braucht schon CP/M? Wie wärs denn mit BASIC? ;-)
Sorry, der im letzten Beitrag gepostete Anhang enthält ein übeflüssiges PDF, das das Archiv völlig unnötig aufbläht. Wenn ein Moderator den Anhang löscht, stelle ich den Rest nochmal neu ein (ca 97K). Edit: hängt schon dran. ;-(
:
Bearbeitet durch User
Leo C. schrieb: > Marcel A. schrieb: >> Unter Linux habe ich bootloader eingerichtet, auch mit >> minicom-Verbindung. Hier muss ich aber gefühlte 10x den Reset-Knopf an >> der AVR-Stamp drücken, bis der bootloader das merkt und den upload >> startet. Scheint wohl ein timing-Problem zu sein - manchmal finden sie >> sich auch gar nicht. > > Das Problem hatte ich auch, ist seit neuestem komischer Weise weg. Keine > Ahnung was sich geändert hat. Inzwischen ist die Ahnung wieder gekommen. Ich hatte vor gar nicht langer Zeit den Linux bootloader gepatched:
1 | diff Linux/bootloader.c
|
2 | diff --git a/Linux/bootloader.c b/Linux/bootloader.c
|
3 | index 3f2225e..3e4af52 100644
|
4 | --- a/Linux/bootloader.c
|
5 | +++ b/Linux/bootloader.c
|
6 | @@ -742,7 +742,8 @@ int connect_device ( int fd,
|
7 | |
8 | // first 0x0d for autobaud, then password, then 0xff |
9 | // for answer in one-line mode |
10 | - sprintf (passtring, "%c%s%c", 0x0d, password, 0xff);
|
11 | +// sprintf (passtring, "%c%s%c", 0x0d, password, 0xff);
|
12 | + sprintf (passtring, "%s%c", password, 0xff);
|
13 | |
14 | printf("Waiting for device... ");
|
Damit funktionierts einwandfrei.
Bei der Nutzung von AVRFlash unter Win muß man auch den Resetknopf seeeehr lange drücken :-(
zu Bootloader patchen: Da ich mit git/diff noch nie etwas gemacht habe: Wenn ich das richtig sehe, muss ich im Quellcode (habe die Stelle gefunden) nur %c%s%c" gegen "%s%c" im sprintf-Aufruf ändern und neu übersetzten?
Fast. Der zugehörige Parameter muß natürlich auch weg.
1 | - sprintf (passtring, "%c%s%c", 0x0d, password, 0xff); |
2 | + sprintf (passtring, "%s%c", password, 0xff); |
Das 0x0d soll nicht ausgegeben werden.
Leo C. schrieb: > Wer's braucht ;) hier ist der Basicinterpreter schon drin. Da ich mit der Verdrahtung noch nicht fertig bin: Wie funktioniert das denn mit dem Basic? Wird das automatisch ins RAM kopiert und gestartet? Wie bekommt man eine Konsole?
Marcel A. schrieb: > Da ich mit der Verdrahtung noch nicht fertig bin: Wie funktioniert das > denn mit dem Basic? Ohne die Verdrahtung funktionierts gar nicht. ;-) > Wird das automatisch ins RAM kopiert und gestartet? > Wie bekommt man eine Konsole? In der Befehlsliste gibts einen zusätzlichen Befehl "loadbasic" oder so. Der Befehl läd den Interpreter aus dem Flash ins RAM. Danach ein "go 0", und auf einer der Schnittstellen sollte der Basic-Prompt erscheinen. Ich habe gerade eine Programmversion ohne Basic geladen. Deshalb kann ich nicht nachschauen. Aber eigentlich müßte es so sein: Es gibt auf Adresse 0003h im Z180-RAM ein "IOBYTE", über das sich die Zuordnung der Console zu einer Schnittstelle einstellen läßt. IOBYTE 0 Verbindung zu AVR 1 ASCI0 mit 9600 Baud, z.Zt. nicht einstellbar 2 ASCI1 mit 57600 Baud, dito Die Baudraten gelten für 9,216 MHz Takt, bei 18,432 MHz das Doppelte. Default für das IOBYTE ist 2, also die zweite Serielle Schnittstelle am Z180. Ändern kann man es z.B. mit dem Befehl "mw 3 1", um den Wert auf 1 zu setzen. Aber eigentlich war der Basic-Interpreter eher als Scherz gedacht. Wenn man das richtig machen will, dann mit ertwas modernerem, mit vernünftigem Editor.
Angehängte Dateien:
-
Z180_AVR_Board_TOP.JPG
390 KB -
Z180_AVR_Board_BOTTOM.JPG
440 KB
Hier die Bilder von meinem ersten Lötfädel-Projekt. Und was soll ich sagen - es läuft! - Die Tests mit Speicher schreiben, vergleichen und auf HALT laufen lassen klappen. - mtest gibt keine Fehler aus. - Mit DDT kann ich mich verbinden - Hilfe kommt und es passiert auch was... Ein tolles Teil - VIELEN DANK an Joe und Leo! Tja - was nun? Zwei Fragenbereiche hätte ich jetzt: A) Wie geht es weiter? - Leo baut ja geniale Dinge -> aber wo gehen die hin? - Bleibt es bei dem Z180-Stamp mit RAM und "AVR-Hilfsumgebung" oder...? - Plant ihr noch ein mapping der AVR-Funktionen (i2c, sd, uhr...) auf den Z180 (IOREQ 0 - 255)? - Die Frage war ja letztens ernst gemeint - ist ein CP/M geplant? B) Nun stellen sich mir doch einige Fragen zur Technik, die sich mir so direkt nicht erschließen (wahrscheinlich habe ich nur zu wenig gelesen): - Wie ist das mit der Taktversorgung des Z180? - im Moment verwende ich den onboard 18MHz Quarz - Über CLK0 des AVR würde vermutlich der Takt vom AVR zum Z180 EXTAL kommen? Ich habe das zwar verdrahtet - aber wie steuert man das? Und wieso nur halber Takt? Laut ZILOG müsste dann auch XTAL leer bleiben, wenn über EXTAL der Takt kommt. - wie würde man einen Einzelschrittmodus realisieren? - Was ist mit der Taktquelle aus PB5 des AVR? Wofür ist die? - Wie ist die RAM-Belegung des Z180 nach dem Boot? DDT ab 0000? Wo wäre Platz für eigene Programme? - Warum muss DSEL0 (über PIN A17 des AVR) auf low gelegt werden, damit DDT läuft? DSEL kenne ich vom normalen Z80 nicht... was macht der? Muss man das immer machen, damit der Z180 Programme ausführt? Sicher ziemliche Anfängerfragen die belegen, dass ich nur die Idee von einer Ahnung habe - aber ich arbeite dran :-) Gruß Marcel
Marcel A. schrieb: > Hier die Bilder von meinem ersten Lötfädel-Projekt. > Und was soll ich sagen - es läuft! Glückwunsch! > - Bleibt es bei dem Z180-Stamp mit RAM und "AVR-Hilfsumgebung" oder...? oder was? > - Plant ihr noch ein mapping der AVR-Funktionen (i2c, sd, uhr...) auf > den Z180 (IOREQ 0 - 255)? Natürlich wird die AVR-Peripherie für den Z180 zugänglich gemacht. > - Die Frage war ja letztens ernst gemeint - ist ein CP/M geplant? Meine Antwort war auch nicht nur unernst gemeint. Trotzdem wird es von mir demnächst ein CP/M 3 geben. > - Wie ist das mit der Taktversorgung des Z180? > - im Moment verwende ich den onboard 18MHz Quarz > - Über CLK0 des AVR würde vermutlich der Takt vom AVR zum Z180 EXTAL > kommen? Genau. > Ich habe das zwar verdrahtet - aber wie steuert man das? Für diese Konfiguration gibts nichts zu steuern. Auf der Z180-Karte muß JP1 entsprechend gesetzt sein, und am AVR muß die CKOUT-Fuse gebrannt werden, damit er den Takt (18,432MHz) auf pin PE7 ausgibt. > Und wieso nur halber Takt? Maximal halben Takt bekommt man an den Timer-Ausgängen des AVR (PG5, PB4-PB7). Dafür braucht man keine Fuse zu brennen, und man kann auch andere Taktteiler einstellen. Der Z180 kann den Takt intern wieder auf 18,432MHz verdoppeln. > Laut ZILOG müsste dann auch XTAL leer bleiben, wenn über EXTAL der Takt kommt. Ja. > - wie würde man einen Einzelschrittmodus realisieren? Ohne Zusatzhardware wohl am Einfachsten, in dem man den Takt für den Z180 durch Pin-toggeln am AVR erzeugt. Der AVR könnte dann nach jedem (halben) Takt alle Z180-Leitungen einlesen, und entsprechend aufbereitet ausgeben. Hardwarezusatz für Einzelschritt hatte Joe mal gepostet: Beitrag "Re: Z180-Stamp Modul" > - Was ist mit der Taktquelle aus PB5 des AVR? Wofür ist die? Kann man nehmen, muß man aber nicht. Das ist OC1A und von den zugänglichen AVR-Timerausgängen der flexibelste. Deshalb habe ich den für meine Taktexperimente mit Z180 und Z80 genommen. > - Wie ist die RAM-Belegung des Z180 nach dem Boot? Es gibt keine. > DDT ab 0000? Wenn man ihn läd, ja. Er belegt die untersten 12K und am oberen Ende des log. Adressbereichs nochmal ein halbes K. > Wo wäre Platz für eigene Programme? In den restlichen 499,5K. ;) Wobei Dein Programm auch ab 0 starten kann, wenn Du einen RST-Vector für den Debugger frei hälst. MMU machts möglich. > - Warum muss DSEL0 (über PIN A17 des AVR) auf low gelegt werden, damit > DDT läuft? Was Du meinst, ist DREQ0, nicht DSEL. Inzwischen nicht mehr. Dieser Pin geht auf DREQ0 des Z180. Die Init für meinen DDTZ hatte früher den DMA0-Kanal benutzt, um den kompletten Speicher zu löschen. Der dazu verwendete DMA-Mode geht nur, wenn der Request-Eingang auf low (aktiv) liegt. > DSEL kenne ich vom normalen Z80 nicht... was macht der? Grundlätzlich hilft bei solchen Fragen ein Blick ins Datenblatt. Das Du DSEL und DREQ0 verwechselt hast, habe allerdings erst später gemerkt, nachdem ich den folgenden Text schon geschrieben hatte. Was es macht ist leicht im Schaltplan zu sehen. DESEL liegt normalerweise über einen Pullup auf High. Wird es über die Steckerleiste aktiviert (low), blockiert es das CE-Signal am RAM-Chip. D.h. DESEL DE-SELektiert das RAM auf der Z180-Karte. Das kann für Erweiterungen nützlich sein, z.B. ECB-Karten, die ROMs, Memory-mapped-I/O oder Video-RAM im unteren Addressbereich einblenden. > Muss man das immer machen, damit der Z180 Programme ausführt?
CP/M Plus (CP/M 3) für Z180-Stamp Hier ist mal was für Wagemutige zum ausprobieren. - Es sind Bugs enthalten. Darunter ein gravierender, der Daten von Disk an die falsche Stelle im RAM kopiert. Es fehlt noch ein Test, ob ein Datenblock die Grenze zwischen Common- und gebanktem RAM überschneidet. - Console geht auf ASCI0 (9600 Baud). Kann mit DEVICE unter CP/M3 auf ASCI1 (57600) Baud umgeschaltet werden. Baudrate-Einstellung geht noch nicht. - Baudraten gelten für 9,216 MHz Takt. Ansonsten umrechenen. - Console über AVR geht nicht (Bug). Da diese Schnittstelle also nicht nutzbar ist, habe ich die Debugmeldungen des Disk-Treibers drin gelassen. - Uhr geht noch nicht. - Das CP/M kennt 4 Laufwerke (A-D). Alle Diskimages müssen derzeit im simh altairZ80 Harddiskformat sein[1]. Das sind die Imagedateien, die exakt 8388608 Bytes groß sind. So bringt man es zum Laufen: - AVR mit dem Hexfile aus dem Archiv updaten. - Die beiden anderen Dateien (cpm3.sys und cpm3test.dsk) auf eine SD-Karte kopieren. - Nach Belieben weitere Images im gleichen Format auf die Karte kopieren. - Für die Zuordnung Image<->Laufwerk eine Environmentvariable setzen: => setenv dsk0 1:/cpm3test.dsk - Für bis zu 3 weitere Images analog: => setenv dsk1 dev:/pfad/zum/image/imagename - Für die cpm3.sys Datei kann eine Variable gesetzt werden, muß aber nicht: => setenv cpm3_file 1:/cpm3.sys - Wenn die Karte in den Micro-SD-Slot auf der AVR-Stamp gesteckt wird, in obigen Beispielen "1:" gegen "0:" tauschen. - Optional Einstellungen speichern: => saveenv - An die erste Serielle (ASCI0) ein Terminal mit 9600 Baud anschließen. - Spätestens jetzt die Karte einstecken. - cpm3.sys Laden: => loadcpm - wenn die Datei nicht gefunden wird: => loadcpm dev:/pfad/zu/cpm3.sys - Wenn das Laden erfolgreich war, steht in der Variablen "startaddress" die CP/M coldboot Einprung-Adresse. (Sollte E400 sein). - Nix wie hin: => go {startaddress} - oder => go e400 - Wenn auf dem Terminal der CP/M Prompt erscheint: => Viel Spaß (mit den Bugs, und diese bitte melden) - Wenn nicht: => Auch melden. Dann halt ohne Spaß. [1] # SIMH AltairZ80 Harddisk diskdef simhd seclen 128 tracks 2048 sectrk 32 blocksize 4096 maxdir 1024 skew 0 boottrk 6 os p2dos end
Nach einem kleinen Vertipper gings:
1 | CP/M Version 3.0, Z180-Stamp BIOS |
2 | A>dir |
3 | A: BDOS3 SPR : BNKBDOS3 SPR : CCP COM : COPYSYS COM : CPMLDR REL |
4 | A: DATE COM : DEVICE COM : DIR COM : DUMP COM : ED COM |
5 | A: ERASE COM : GENCOM COM : GENCPM COM : GET COM : HELP COM |
6 | A: HELP HLP : HEXCOM COM : PATCH COM : PIP COM : PUT COM |
7 | A: README : RENAME COM : RESBDOS3 SPR : SAVE COM : SET COM |
8 | A: SETDEF COM : SHOW COM : SID COM : SUBMIT COM : TYPE COM |
9 | A> |
Turbo-Pascal läuft (erster Test):
1 | Logged drive: B |
2 | |
3 | Work file: |
4 | Main file: |
5 | |
6 | Edit Compile Run Save |
7 | |
8 | eXecute Dir Quit compiler Options |
9 | |
10 | Text: 0 bytes (8118-8118) |
11 | Free: 22765 bytes (8119-DA06) |
12 | |
13 | > |
14 | Dir mask: |
15 | READ ME : TINST COM : TINST DTA : TINST MSG : TURBO COM |
16 | TURBO MSG : TURBO OVR : CMDLIN PAS : LISTER PAS : MC-MOD00 INC |
17 | MC-MOD01 INC : MC-MOD02 INC : MC-MOD03 INC : MC-MOD04 INC : MC-MOD05 INC |
18 | MC HLP : MC PAS : MCDEMO MCS : MC COM : MC-MOD03 COM |
19 | HELLO PAS |
20 | |
21 | Bytes Remaining On B: 4184k |
22 | > |
Mit den Tastatur-Codes ist das ja wieder so eine typische CP/M-Sache... Auf der "Shell" funktioniert bei mir z.B. BS, auch die CTRL-Codes gehen weitgehend wie im CPM3-Handbuch beschrieben. Unter TP sieht das wieder anders aus - aber das muss man eh anpassen.
Marcel, falls Du minicom verwendest könnte es auch damit zu tun haben. In der Terminaleinstellungen kann man einstellen, ob Backspace BS oder DEL senden soll. Es wird aber nicht nur die Backspace-Taste (^H) eingestellt, sondern auch die DEL-Taste.
Wie ist diese Fehlermeldung zu interpretieren? ## CPU now in reset state. z80_memfifo_init: 0, 0 z80_memfifo_init: 1, 0 z80_memfifo_init: 2, 0 z80_memfifo_init: 3, 0 Loading Z180 memory... From: 0x00000 to: 0x00003 ( 4 bytes) From: 0x00008 to: 0x0000A ( 3 bytes) From: 0x00010 to: 0x00012 ( 3 bytes) From: 0x00018 to: 0x0001A ( 3 bytes) From: 0x00020 to: 0x00022 ( 3 bytes) From: 0x00028 to: 0x0002A ( 3 bytes) From: 0x00030 to: 0x00032 ( 3 bytes) From: 0x00038 to: 0x0003A ( 3 bytes) From: 0x00040 to: 0x00043 ( 4 bytes) From: 0x00050 to: 0x02C24 (11221 bytes) From: 0x02C34 to: 0x02E7F ( 588 bytes) From: 0x02EA3 to: 0x02EA3 ( 1 bytes) From: 0x02EC7 to: 0x02EC7 ( 1 bytes) From: 0x02EEB to: 0x02EEB ( 1 bytes) Command failed, result=-1 Der nachfolgende Vorgang läuft erstmal erfolgreich :-) => loadcpm Loading: '0:/cpm3.sys'... BNKBIOS3 SPR E400 0800 BNKBIOS3 SPR A700 1900 RESBDOS3 SPR DE00 0600 BNKBDOS3 SPR 7900 2E00 55K TPA Loaded: Resident: 0xDE00-0xEBFF, Banked: 0x7900-0xBFFF => go e400 ## Starting application at 0xe400 ...
> Wie ist diese Fehlermeldung zu interpretieren? Alles etwas uneinheitlich, ich weiß. Nichts davon ist im eigentlichen Sinne eine Fehlermeldung. > ## CPU now in reset state. "##[#..]" am Zeilenanfang war/ist für Debugmeldungen gedacht. Diese Zeile ist aber eigentlich eine normale Rückmeldung des davor ausgeführten Befehls. Kann man weglassen, aber dann sieht man nicht mehr, ob der Befehl etwas gemacht hat. > z80_memfifo_init: 0, 0 > z80_memfifo_init: 1, 0 > z80_memfifo_init: 2, 0 > z80_memfifo_init: 3, 0 Debug > Loading Z180 memory... > From: 0x00000 to: 0x00003 ( 4 bytes) > From: 0x00008 to: 0x0000A ( 3 bytes) > From: 0x00010 to: 0x00012 ( 3 bytes) > From: 0x00018 to: 0x0001A ( 3 bytes) > From: 0x00020 to: 0x00022 ( 3 bytes) > From: 0x00028 to: 0x0002A ( 3 bytes) > From: 0x00030 to: 0x00032 ( 3 bytes) > From: 0x00038 to: 0x0003A ( 3 bytes) > From: 0x00040 to: 0x00043 ( 4 bytes) > From: 0x00050 to: 0x02C24 (11221 bytes) > From: 0x02C34 to: 0x02E7F ( 588 bytes) > From: 0x02EA3 to: 0x02EA3 ( 1 bytes) > From: 0x02EC7 to: 0x02EC7 ( 1 bytes) > From: 0x02EEB to: 0x02EEB ( 1 bytes) Info. Zeigt an, was geladen wurde. Hier durch die vielen kleinen Lücken etwas zu geschwätzig. :) > Command failed, result=-1 Also doch eine Fehlermeldung. Kann ich jetzt nicht zuorden. Irgendein Befehl hat Returncode -1 an den Interpreter zurück geliefert. Wird nur angezeigt, wenn das Programm mit DEBUG übersetzt wurde, also immer. :) > Der nachfolgende Vorgang läuft erstmal erfolgreich :-) Dann ist ja gut. :-) Irgendwann möchte ich einen oder zwei Schalter für Debuglevel/Verbosity einbauen. Noch ist im Flash jedenfalls genug Platz für Debug-Meldungen.
kurze Rückmeldung zur Version *stamp-monitor-cpm3-0.1.hex* Das Ergebnis lautet: -> go E400 ## Starting application at 0xe400 ... -> z80_memfifo_init: 0, e908 z80_memfifo_init: 1, e92c z80_memfifo_init: 2, ea65 z80_memfifo_init: 3, ea41 Auf der CP/M Console 0 erscheint folgendes: CP/M Version 3.0, Z180-Stamp BIOS A>dir A: BDOS3 SPR : BNKBDOS3 SPR : CCP COM : COPYSYS COM : CPMLDR REL A: DATE COM : DEVICE COM : DIR COM : DUMP COM : ED COM A: ERASE COM : GENCOM COM : GENCPM COM : GET COM : HELP COM A: HELP HLP : HEXCOM COM : PATCH COM : PIP COM : PUT COM A: README : RENAME COM : RESBDOS3 SPR : SAVE COM : SET COM A: SETDEF COM : SHOW COM : SID COM : SUBMIT COM : TYPE COM CP/M 3.0 scheint also korrekt zu booten. Leo, das ist einfach enfach Super!
Ich finde das auch extrem beeindruckend und ziehe den Hut... Hinweis an Joe: Wäre es möglich, beim Layout statt dieser komischen Micro-SD-Slots "normale" Micro-SD-Slots z.B. im Pollin-Design zu verwenden, die nach vorne rausgehen (und nicht zum ISP Stecker) und einen normalen Steckmechanismus haben? Habe inzwischen die Karte mehrfach rein und raus geholt für die Tests - und ich glaube, die wird nicht ewig halten...
Marcel A. schrieb: > Wäre es möglich, beim Layout statt dieser komischen > Micro-SD-Slots "normale" Micro-SD-Slots z.B. im Pollin-Design zu > verwenden Ja sicher. Die ursprüngliche Idee dazu war die interne SD als Festplatte zu verwenden und die externe CD-Card zu wechseln. Ich habe jedoch selber gemerkt, das das Handling derzeit wenig komfortabel ist. Gerne sammel ich weite Vorschläge zur Verbesserung, vielleicht in Form einer ToDo-Liste.
Zum Thema Karte rein/raus. Von Marcel kam der Vorschlag, stattdessen Dateien über die USB-Schnittstelle des Monitors zwischen PC und SD-Karte zu kopieren. Prinzipiell ist das möglich, allerdings sollte man dafür ein Übertragungprotokoll ala Kermit oder Z/X/Y-Modem haben. Für kleinere Dateien bis 512K funktioniert folgender Würgaround: - Datei in Intel Hex konvertieren. [1] - Mit loadi ins RAM laden. Auf dem Z180 sollte dann kein Programm laufen, es sei denn, man weiß, wo freier Speicher ist. [2] - Datei mit fatwrite auf die SD-Karte schreiben. Für die cpm3.sys reicht das allemal. Man kann mit mkfs.cpm aus den CP/M-Tools auch CP/M-Imagedateien erzeugen, die deutlich kleiner als 8 MByte sind.[3] Ein leeres Image ist z.B. nur 57344 Byte groß. Diese Dateien werden von Chan's FatFs auf dem Stamp bei Bedarf automatisch erweitert. (Heute getestet [4]) In die andere Richtung gehts mit fatload leider nur bis ins RAM, da es (noch) kein Upload-Protokoll gibt. [1] z.B. mit srec_cat (http://srecord.sourceforge.net/) $ srec_cat -o cpm3.sys.hex -Intel cpm3.sys -Binary [2] Das CP/M 3 ist z.Zt mit 3 Speicherbänken je 48K und 16K Common konfiguriert, und belegt den Speicher ab 0. 4 * 0xC000 + 0x4000 = 0x34000 D.h., von 0x34000 bis 0x7FFFF ist freier Speicher, der vom Monitor genutzt werden kann, auch wenn CP/M läuft. [3] $ mkfs.cpm -f simhd imagename.dsk
Leo C. schrieb: > Zum Thema Karte rein/raus. Der Aufwand für diese Extrafunktion ist aus meiner Sicht nicht notwendig. Die von Leo C. beschriebenen Boardmittel sollten für die Inbetriebnahme ausreichen. Bootet das System korrekt kann ja über die zweite Konsole mittels Kermit oder Z/X/Y-Modem auf die Disketten zugegriffen werden und darüber ein Dateiaustausch erfolgen. Die USB-Schnittstelle am AVR könnte ja über eine dritte Konsole dem CP/M zugeordnet werden. Dann läuft die Modemverbindung über USB. Ich denke, dass Leo C. diese Erweiterung eh im Hinterkopf hat. Eine Variante könnte auch ein USB-Host-Controller [1] mit RS232-Schnittstelle sein. Hier ist sogar schon das FAT-System integriert. [1] http://www.ftdichip.com/Products/Modules/ApplicationModules.htm#VDrive2
Zum Würgaround: Ich hatte gedacht, loadi würde von der SD in Z180-Ram schreiben. Muss ich mir noch mal ansehen, wäre sicher nicht schlecht für den Anfang. Zu Joes FTDI-Variante: Das klingt toll- Zugriff auf USB Speicher über ein "relativ" einfaches serielles Protokoll. Mit 25€ zwar an sich kein Schnäppchen, aber bei der Ersparnis hinsichtlich Entwicklung... Das wäre auch was für meinen NDR NKC - mit entsprechender Software könnte ich dann über die serielle Schnittstelle Daten vom USB-Stick einlesen und auf lokale Disketten kopieren...
Marcel A. schrieb: > Mit 25€ zwar an sich kein Schnäppchen Ganz so schlimm ist es nicht. Der Preis gilt ja nur für das komplette Modul. Ein VNC2 Chip ist für deutlich weniger zu haben. Dieser könnte dann mit auf die Basisleiterplatte.
Marcel A. schrieb: > Zum Würgaround: Ich hatte gedacht, loadi würde von der SD in Z180-Ram > schreiben. Ja eben. Und mit fatwrite dann das RAM auf SD-Karte schreiben. Joe G. schrieb: > Der Aufwand für diese Extrafunktion ist aus meiner Sicht nicht > notwendig. Die von Leo C. beschriebenen Boardmittel sollten für die > Inbetriebnahme ausreichen. Gerade am Anfang der Inbetriebnahme wär's praktisch gewesen. Ich hatte die SD-Karte dutzende Male hin und her gesteckt. Allerdings eine normale SD-Karte und einfache Sockel. Auf die Idee, übers Z180-RAM zu kopieren, bin ich auch erst gestern gekommen. > Bootet das System korrekt kann ja über die > zweite Konsole mittels Kermit oder Z/X/Y-Modem auf die Disketten > zugegriffen werden und darüber ein Dateiaustausch erfolgen. Ja, nachdem man ein funktionierendes System hat. Und dann nur in die CP/M-Imagedateien. > Die > USB-Schnittstelle am AVR könnte ja über eine dritte Konsole dem CP/M > zugeordnet werden. Dann läuft die Modemverbindung über USB. Ich denke, > dass Leo C. diese Erweiterung eh im Hinterkopf hat. Das sollte ja eigentlich schon laufen. Siehe Bugliste weiter oben. Das Device dafür gibts schon (siehe DEVICE-Befehl unter CP/M). Zur Zeit gibts aber mindestens einen Bug, der dringender ist. Wenn man mit pip große Dateien mit Verify von einer Disk zur anderen kopiert, werden falsche Daten geschrieben, und pip bricht beim Verify ab. Im Moment habe ich keine Ahnung, woran das liegen könnte. Es gibt keine Fehlermeldungen und die Debug-Logs sehen gut aus.
Ich habe ein Problem, mit der Version "stamp-monitor-cpm3-debug-0.0.hex", ist alles ok. Ich nutze das im ZIP beigefügte cpm3.sys Bei der Version "stamp-monitor-cpm3-0.1+fboot-support.hex", die mir Leo zum Test der Bootloader gegeben hatte, erscheint in der Z80-Konsole: CP/M Version 3.0, Z180-Stamp BIOS BIOS Err on A: No CCP.COM file Zum loadi-Würgaround: Für den Upload vom PC aus reicht da ein einfaches ASCII-Senden der HEX-Datei? Habe nun beide Boards per USB an einem RASPI hängen und per ser2net beide Konsolen (AVR, CP/M) über telenet verfügbar gemacht. Ist aber noch nicht sehr stabil, ich denke, die brauchen zu viel Saft und ich muss einen Hub mit Stromversorgung zwischenschalten. Auch ist nicht reproduzierbar, welcher Adapter ttyUSB0 und 1 wird beim boot - da gibts aber glaube ich Tricks bei den Raspi-Leuten. Wenn ich jetzt auf der Fritzbox eine Portweiterleitung einrichte (+dyndns), könntet ihr per putty/telnet auf die Kiste zugreifen :-)
Noch was ist mir aufgefallen. Nach einem reflash der "stamp-monitor-cpm3-debug-0.0.hex" kommt es reproduzierbar zu einer bootschleife. Es wird von 3 bis 2 oder 1 runtergezählt und dann neu gestartet. Strom ab und wieder dran - alles prima, auch auf Dauer. Vielleicht sind das Relikte vom Bootloader?
Anbei die überarbeitete Version der Consolen-Schnittstelle für die ECB-Card. Änderungen: 1. 3.3V oder 5V möglich 2. JP1 deaktiviert die beiden RS-232 und über die beiden Buchsenleisten können zwei USB-Module zu Testzwecken gesteckt werden.
Marcel A. schrieb: > Noch was ist mir aufgefallen. > > Nach einem reflash der "stamp-monitor-cpm3-debug-0.0.hex" kommt es > reproduzierbar zu einer bootschleife. Es wird von 3 bis 2 oder 1 > runtergezählt und dann neu gestartet. > Strom ab und wieder dran - alles prima, auch auf Dauer. Vielleicht sind > das Relikte vom Bootloader? Das war hier schon mal: Beitrag "Re: Z180-Stamp Modul" Reset drücken reicht. Die Version mit Auto-Bootloader-Support schaltet, um in den Bootloader zu kommen, den Watchdog ein. Der Monitor muß diesen beim hochfahren ausschalten (oder ständig nachtriggern). Die Version ohne Auto-Bootloader-Support weiß davon aber nichts. Wenn Du eine solche Version also mit dem Autobootloader flashst, wird diese vom Watchdog ständig zurückgesetzt, bis zum nächsten 'External' oder 'Power Up' Reset.
Marcel A. schrieb: > mit der Version "stamp-monitor-cpm3-debug-0.0.hex", ist alles ok. Ich > nutze das im ZIP beigefügte cpm3.sys > Bei der Version "stamp-monitor-cpm3-0.1+fboot-support.hex", die mir Leo > zum Test der Bootloader gegeben hatte, erscheint in der Z80-Konsole: > > BIOS Err on A: No CCP.COM file Nimmst Du in beiden Fällen das gleiche cpm3.sys? Dann könnte das der Grund sein. Du hast ja auch die Version 0.1 ohne Autoboot bekommen. Das cpm3.sys davon paßt dann wieder. Da unser CP/M 3 Loaderprogramm - im Gegensatz zum original CPMLDR - Dateien mit beliebigem Namen laden kann, sollte ich für cpm3.sys vielleicht auch Versionskennungen einführen... > Zum loadi-Würgaround: Für den Upload vom PC aus reicht da ein einfaches > ASCII-Senden der HEX-Datei? Ja. Unter minicom z.B. "Ctrl-A Y". Copy-And-Paste ins Terminal müßte auch gehen. Oder das Terminal verlassen und cat datei >/dev/tty... > Auch ist nicht > reproduzierbar, welcher Adapter ttyUSB0 und 1 wird beim boot - da gibts > aber glaube ich Tricks bei den Raspi-Leuten. FTDI-Chips liefern eine Seriennummer, über die die ttyUSBx unterscheidbar sind. Die billigen Pofilic, die sonst auch gut funktionieren, leider nicht.
Das wars mit dem falschen cpm3.sys. Klar - wie immer in 99% ein layer-8-Fehler. Übringens beginnt mein SD-Slot langsam zu spinnen. Hat mich eine halbe Stunde gekostet bis ich festgestellt hatte, dass die Klappe den Kontakt für CardDetect nicht mehr richtig schließt...
Hier eine aktuelle Diskussionsvariante zur ECB-Card. 1. externe SD-Card Belegung von DAT3/CS und Carddetect von Leo C. übernommen 2. CPU Clock CLKO (Z180) auf Jumper 3 gelegt. Damit kann der Takt über den ACLOCK oder OC1A bezogen werden. 3. Bootloader Um in einer späteren Version den Bootloader/Monitor zu aktivieren oder deaktivieren habe ich den Jumper 2 vorgesehen. Er kann PG2 vom AVR gegen Masse ziehen. Vielleicht habt ihr ja noch eine andere Idee dazu. 4. noch offen Sollte CKA0 (Pin 17, Z180 Stamp) auf OC2A (AVR) ? HALT LED für Z180 notwendig/gewünscht ? I2C auf Steckverbinder ? Weitere Wünsche ?
Wo sind denn die seriellen Schnittstellen und USB geblieben? Oder ist das ein anderes Blatt oder eine andere Baugruppe? HALT-LED fand ich ganz praktisch. I2C fände ich auch super
Angehängte Dateien:
-
Betriebsled.png
15 KB
> 1. externe SD-Card > Belegung von DAT3/CS und Carddetect von Leo C. übernommen Kann man davon ausgehen, daß ein Kartensockel mit Card-Detect-Switch verwendet wird? Dann wäre der Pulldown an DAT3/CS überflüssig und man könnte stattdessen wieder eine LED spendieren. Der 47µF Kondensator dürfte auf jeden Fall zu klein sein, wenn man die Karte auch im laufenden Betrieb stecken können will. Bei mir sinds 220µF + 10µH Induktivität geworden. Sicher gehen auch andere Kombinationen[1], aber diese Teile waren in meiner Bastelkiste. Auch mit dem 220µF Kondensator direkt am Sockel hatte ich ohne die Spule bei fast jedem Einstecken einen Brown-Out-Reset. > 2. CPU Clock > CLKO (Z180) auf Jumper 3 gelegt. Damit kann der Takt über den ACLOCK > oder OC1A bezogen werden. Gut. > 3. Bootloader > Um in einer späteren Version den Bootloader/Monitor zu aktivieren oder > deaktivieren habe ich den Jumper 2 vorgesehen. Er kann PG2 vom AVR gegen > Masse ziehen. Vielleicht habt ihr ja noch eine andere Idee dazu. Was soll denn passieren, wenn der Bootloader abgeschaltet ist? > 4. noch offen > Sollte CKA0 (Pin 17, Z180 Stamp) auf OC2A (AVR) ? CKA0/DREQ0 muß nicht mehr unbedingt auf low gezogen werden können. Dafür wird die Verbindung also nicht mehr gebraucht. Für meine Z80-Stamp erzeuge ich mit OC2A den Baudratentakt. Da CKA0 ja auch ein UART-Takteingang ist. paßt die Verbindung dafür ganz gut. Das nur zur Info, die Z80-Karte werde ich eher nicht auf die ECB/Basiskarte stecken wollen. > HALT LED für Z180 notwendig/gewünscht ? Da ich die Duo-LEDs hier rumliegen habe, will ich mir schon seit einer Weile die Schaltung im Anhang bauen. Leider habe ich keine passenden Gatter mehr. Deshalb ist noch nichts draus geworden. Statt RESET müßte man eigentlich auch BUSACK nehmen können. Ich kann mich noch erinnern, daß ich mich bewußt für RESET entschieden hatte, weiß aber gerade nicht mehr wieso. Früher [TM], also ganz viel früher, hatte ich mal mit Geräten zu tun, auf denen ein in der Firma geschriebenes RTOS lief. Die HALT-Led war dort sehr praktisch für's Debugging. Im Normalbetrieb blinkte die LED kurz (ging kurz aus) im Halbsekundentakt wegen Displayaktualisierung. Wenn die LED anders geflackert hat, oder ständig an oder aus war, war sofort klar, daß etwas nicht stimmt. (Überlast, Progrmmierfehler). > I2C auf Steckverbinder ? Wenn Platz für den Stecker vorhanden ist, warum nicht? > Weitere Wünsche ? Ein AVR-Port auf WAIT? Der Monitor könnte dann den Z80-Bus einlesen und auswerten (Singlestep für Arme). Für Siglestep bei voller Geschwindigkeit ;) müßte man aber WAIT mit MREQ und/oder M1 synchronisieren, und wäre dann ungefähr bei Beitrag "Re: Z180-Stamp Modul" Wenn man den Takt weit genug herunter setzt, kann man den Bus aber auch ohne WAIT abfragen. Was könnte man denn sonst noch mit den freien AVR-Leitungen machen? Auf einen Stecker? Jumperfeld? Das wäre dann die Erweiterung von 3. oben. [1] Abschnitt "Cosideration to Bus Floating and Hot Insertion" in http://elm-chan.org/docs/mmc/mmc_e.html
Leo C. schrieb: > Kann man davon ausgehen, daß ein Kartensockel mit Card-Detect-Switch > verwendet wird? Dann wäre der Pulldown an DAT3/CS überflüssig und man > könnte stattdessen wieder eine LED spendieren. Ja, ist ein echter Card-Detect-Switch [1]. Damit gibt es auch eine echte LED für CS. > Der 47µF Kondensator dürfte auf jeden Fall zu klein sein... Ich halte mich mal an Elm-Chans Empfehlung. > Was soll denn passieren, wenn der Bootloader abgeschaltet ist? Das war natürlich blödsinnig von mir beschrieben. Es sollte Monitor heißen. Der Jumper sollte also den Monitor bei Bedarf ausblenden und das System sofort das CP/M booten lassen. > Da ich die Duo-LEDs hier rumliegen habe... Da in der echten Single-Step-Schaltung (für Reiche) noch zwei Gatter übrig sind, dürften sie nun auch deine Duo-Led ansteuern. zusätzliche Änderungen: - I2C liegt auf einem Steckverbinder - die SD-Card hat Level-Shifter - ECB_Card kann wahlweise auf 3.3V oder 5V laufen Mit JP4 (Power) kann nun die gesammte Karte zwischen 3.3V und 5V umgeschaltet werden. Bei 5V sind die Level-Shifter aktiv beteiligt, bei 3.3V sind sie halt nur einfache Puffer. Der MAX3241 verträgt auch 5V. Fehlt nur noch eine sinvolle Steckerbelegung des ECB-Steckverbinders. [1] http://de.farnell.com/wurth-elektronik/693063010911/speicherbuchse-sd-karte-9pol/dp/2081360
Joe G. schrieb: > Der Jumper sollte also den Monitor bei Bedarf ausblenden und das > System sofort das CP/M booten lassen. Das ist natürlich schon drin:
1 | => setenv bootcmd 'loadc; go ${startaddress}'
|
2 | => setenv bootdelay 0 |
3 | => saveenv |
Man kann auch noch weitere Befehle in bootcmd schreiben, jeweils mit ";" getrennt. Bei mir z.B.
1 | => pr bootcmd pins |
2 | bootcmd=pin ${pins}; loadc; go ${startaddress}
|
3 | pins=2 low 3 2 |
Testen kann man mit => run bootcmd und wenns dann klappt "saveenv". Der Jumper ist aber trotzdem nützlich. Der Monitor könnte ihn beim Hochfahren abfragen, und wenn gesteckt, das EEPROM auf Defaultwerte zurück setzten (Kaltstart). Es könnte schließlich vorkommen, daß aus irgend einem Grund unsinnige Daten im EEPROM stehen, und der Monitor dadurch unbedienbar wird. Hinter L1 muß auf jeden Fall noch ein Kondensator. Der Treiber für WAIT muß OC sein. Joe G. schrieb: > Mit JP4 (Power) kann nun die gesammte Karte zwischen 3.3V und 5V > umgeschaltet werden. Wenn Pin 4 des FTDI-Chips auf der AVR-Stamp an die Betriebsspannung der Karte (aktuell 3.3V) gehen würde, könnte man auch diese Karte mit 5V versorgen, und damit das gesamte System. Falls es eine Neuauflage der Karte geben sollte...
Leo C. schrieb: > Hinter L1 muß auf jeden Fall noch ein Kondensator. vergessen :-( > Der Treiber für WAIT muß OC sein. mein Gott, das Alter... vor 30 Jahren wußte ich sofort warum OC, beim ersten Schaltungsentwurf wieder mit etwas Nachdenken, gesten nicht mehr :-( > Wenn Pin 4 des FTDI-Chips auf der AVR-Stamp an die Betriebsspannung der > Karte (aktuell 3.3V) gehen würde, könnte man auch diese Karte mit 5V > versorgen, und damit das gesamte System. Hatte ich schon geändert. Weiterhin den Batteriehalter und den Micro-SD-Slot. LP's sind auch keine mehr vorrätig (weder AVR noch Z180), so dass auch hier eine Nachauflage sinvoll erscheint. Der Restfehler beim Z180 ist auch beseitigt.
Leo C. schrieb: > Zur Zeit gibts aber mindestens einen Bug, der dringender ist. Wenn man > mit pip große Dateien mit Verify von einer Disk zur anderen kopiert, > werden falsche Daten geschrieben, und pip bricht beim Verify ab. Der Bug hängt mit dem Multiple-Sector-I/O zusammen, das ich jetzt im Z180 BIOS erst mal heraus genommen habe. Da aber nun beim Schreiben auf der AVR-Seite jeder Sektor einzeln auf die SD-Karte ge-sync-ed wurde, habe ich das AVR-Programm auch noch mal geändert (war sowieso vorgesehen). Der aktuelle Stand scheint jetzt wirklich stabil zu laufen.
Leo C. schrieb: > Der aktuelle Stand scheint jetzt wirklich stabil zu laufen. Ich werde gleich mal testen. Die Schaltung zum ECB-Board hatte auch einen fetten Bug. Die RS-232 Leitungen liegen ja auf einem 10-poligen Wannenstecker um die SUB-D(male) Verbinder einfach anzucrimpen. Die Beschaltung hatte ich jedoch für SUB-D(m)durchgeführt :-( Ist nun korregiert.
Könnte man die Zuordnung der CP/M3 (default) Console nicht auch auf eine Environmentvariable legen? z.B. 'setenv console 0' Derzeit ist das ja über das IOBYTE auf Adresse 0003h realisiert. So könnten Verweigerer einer echten RS-232, über die USB-Verbindung zum AVR auch in den Genuss von CP/M kommen.
Joe G. schrieb: > Könnte man die Zuordnung der CP/M3 (default) Console nicht auch auf eine > Environmentvariable legen? z.B. 'setenv console 0' Sowas habe ich auf meiner Liste. Baudraten dann auch. Bin mir nur noch nicht sicher, ob man es wirklich braucht. > Derzeit ist das ja > über das IOBYTE auf Adresse 0003h realisiert. Das war mal so, bzw. ist für den Debugger (noch) so. Unter CP/M 3 ist die Zuordnung aufwendiger und damit flexibler. Gesteuert wird dann alles mit dem DEVICE-Befehl[1]. Den kann man auch in eine PROFILE.SUB[2] schreiben, und damit die Einstellung bei jedem Kaltstart vorgeben. 'DEVICE CON:=ASCI1' schaltet auf die zweite serielle Schnittstelle um. Die ist ja eigentlich auch für die Console vorgesehen. Im Moment ist es ASCI0, weil ich auf ASCI1 gewohnheitsmäßig den Debugger habe. > So könnten Verweigerer > einer echten RS-232, über die USB-Verbindung zum AVR auch in den Genuss > von CP/M kommen. Wie schon mehrfach geschrieben. funktionert das z.Zt. nicht mit dem CP/M. Aber natürlich kommt das rein, aber im Moment habe ich andere Prioritäten. [1] User's Guide, Kapitel 5.2.5 [3] [2] User's Guide, Kapitel 5.2.74 unten [3] Das Unser's Guide gibts z.B. hier: http://www.cpm.z80.de/manuals/cpm3usersguide.pdf
Ich habe die Version 6 mit neuem Bios mal getestet. Folgende Fehler sind
mir aufgefallen:
1. 5 Laufwerke A-F angelegt
printenv
baudrate=115200
bootcmd=reset; loadf; go ${startaddr}
bootdelay=3
cpm3_file=0:/cpm3.sys
dsk0=0:/cpm3_a.dsk
dsk1=0:/cpm3_b.dsk
dsk2=0:/cpm3_c.dsk
dsk3=0:/cpm3_d.dsk
dsk4=0:/cpm3_f.dsk
pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10
:PE7
startaddress=e400
Das System bootet korrekt von A:
A und B existieren auch tatsächlich bei C kommt die Meldung:
BIOS Error on C: T-00006, S-00000, Read, FatFs: INVALID_OBJECT, Retry
(Y/N) ?
D existiert wieder und bei F erscheint die Meldung:
CP/M Error On F: Invalid Drive
BDOS Function = 14
Turbopascal und WS starten zunächst korrekt. Turbopascal bricht jedoch
das Ausführen großer Programme mit Include und Overlay mit einer
Speicherfehlermeldung ab. Hier muß ich erst mal testen, ob das unter
CP/M 2.2 läuft.
Joe G. schrieb: > Ich habe die Version 6 mit neuem Bios mal getestet. Folgende Fehler sind > mir aufgefallen: > > 1. 5 Laufwerke A-F angelegt Z.Zt. werden nur 4 Laufwerke unterstützt. > printenv > baudrate=115200 > bootcmd=reset; loadf; go ${startaddr} > bootdelay=3 > cpm3_file=0:/cpm3.sys > dsk0=0:/cpm3_a.dsk > dsk1=0:/cpm3_b.dsk > dsk2=0:/cpm3_c.dsk > dsk3=0:/cpm3_d.dsk > dsk4=0:/cpm3_f.dsk > pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10 :PE7 > startaddress=e400 > > Das System bootet korrekt von A: > A und B existieren auch tatsächlich bei C kommt die Meldung: > BIOS Error on C: T-00006, S-00000, Read, FatFs: INVALID_OBJECT, Retry > (Y/N) ? Sind die Laufwerke alle im simhd Format? Die Fehlermeldung ist natürlich nicht besonders hilfreich. Wahrscheinlich ging der Laufwerks-Login schon schief (f_open), aber an der Stelle kann man keine Fehler an das BDOS zurück geben. (Außer Laufwerk als nicht vorhanden melden.) > D existiert wieder und bei F erscheint die Meldung: > CP/M Error On F: Invalid Drive > BDOS Function = 14 Siehe oben. > Turbopascal und WS starten zunächst korrekt. Turbopascal bricht jedoch > das Ausführen großer Programme mit Include und Overlay mit einer > Speicherfehlermeldung ab. Hier muß ich erst mal testen, ob das unter > CP/M 2.2 läuft. Wurde das Programm auf dem CP/M3-System compiliert? Die TPA ist zur Zeit etwas kleiner als bei dem AVR-CP/M-System.
Joe G. schrieb: > Könnte man die Zuordnung der CP/M3 (default) Console nicht auch auf eine > Environmentvariable legen? z.B. 'setenv console 0' Derzeit ist das ja > über das IOBYTE auf Adresse 0003h realisiert. Ich arbeite mich ja immer mehr ein - vom Speichermanagement unter CPM3 bin ich aber noch weit entfernt. Das IOBYTE hatte ich mit CPM2.2 in Verbindung gebracht und mich gewundert, dass dies in dem "Basic"-HEX von Leo bereits eine Bedeutung hatte dass es unter CPM3 zumindest derzeit noch funktioniert. Noch eine Bitte zu den Schnittstellen. Ich fände es gut, wenn VOR dem MAX232 eine Stiftleiste (3 Pins) wäre, um dort billige China-USB-Serial-Wandler alternativ direkt anzuschließen .
Marcel A. schrieb: > Noch eine Bitte zu den Schnittstellen. Ich fände es gut, wenn VOR dem > MAX232 eine Stiftleiste (3 Pins) wäre, um dort billige > China-USB-Serial-Wandler alternativ direkt anzuschließen . Die Buchsenleisten USB0 und USB1 (6polig) liegen ja direkt an der SIO vom Z180 und parallel am MAX3241. Über JP1 wird der MAX in den Shutdown Modus geschickt. Somit sind nur die USB-Wandler aktiv. USB und RS-232 parallel geht leider nicht so einfach. Bei der Beschaltung der Buchsen habe ich mich nach den bei mir [1] rumliegenden Wandlern gerichtet. Um Handshake zu realisieren mit /CTS und /DTR. Außerdem können die Module von 3.3V auf 5v umgeschaltet werden. [1] http://www.aliexpress.com/item/FT232RL-FTDI-USB-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Port-3-3V-5V/2043815349.html
Mal wieder eine blöde Frage. Ich habe in den letzten Tagen viel über die MMU des Z180 gelesen und eine erste Idee bekommen, wie das geht (ganz verstehen würde ich das noch lange nicht nennen). Wichtig ist ja, dass die SW für den Z180 das unterstützt durch geschicktes Einblenden des physikalischen Speichers in den logischen (diese Register). Ebenso die Trennung zwischen Common0, Bank und Common1. Ebenso habe ich versucht zu verstehen, wie CPM3 mit dem Thema umgeht (banked version). Ich habe habe einige Verbindungen nicht verstanden... Kann mir jemand eine gute Quelle nennen? - Nutzt CPM3 selber die MMU für sich (TPA, BIOS, BDOS... so habe ich das verstanden)? - Stellt CPM dann wiederum selber Umschaltmethoden an Anwendungsprogramme bereit? - Oder muss dann CPM-Software die Bank-Mechanismen des Z180 selber nutzen und wenn ja - kommt sie sich dann nicht mit der CPM-Verwaltung ins Gehege? - Was für Speicher sieht ein CPM-Programm denn eigenltich in einem banked CPM3? - Irgendwie hatte ich den Eindruck, dass Banked CPM3 eh nur 2-3 Banks nutzt, um gewisse OS-Anteile auszulagern und mehr TPA zur Verfügung zu stellen? - Wie ist das dann auf "unserer" STAMP implementiert? Ich glaube das bringt so alles nix. Ich muss wirklich bei 0 anfangen wie Leo es mir empfohlen hat. Diese Quereinstiege bringen es nicht - auch wenn mir dazu leider die Zeit fehlt (im Gegensatz zu Leo/Joe bin ich damit nicht groß geworden oder habe damit beruflich zu tun gehabt :-()
:
Bearbeitet durch User
Marcel A. schrieb: > Kann mir jemand eine gute Quelle nennen? Vielleicht "CP/M 3 Programmer’s Manual", Kapitel 1.1? Im "CP/M 3 System Manual" ist das Speichermodell ab Kapitel 1.4 dann nochmal dargestellt. Hier ist eine gute Darstellung von CP/M 2. Unter CP/M 3 ist die Speicheraufteilung aus Sicht der Anwenderprogramme gleich: http://www.oocities.org/homeofoscarvermeulen/cpm.html Das hier hat mir heute Abend die Zeit gestohlen. :) CP/M gibts ab Folge 16: https://www.youtube.com/playlist?list=PLB3mwSROoJ4KLWM8KwK0cD1dhX35wILBj > - Nutzt CPM3 selber die MMU für sich (TPA, BIOS, BDOS... so habe ich das > verstanden)? CP/M setzt nur eine einfache Bank-Umschaltung vorraus. Die Umschaltung kann in Hardware auf unterschiedliche Weise realisiert werden. Auf einem Z180 nimmt man dafür natürlich die MMU. Ins BIOS kommt dann eine Funktion, die für die vom BDOS gewünschte Bank-Nummer, die MMU entsprechend programmiert. > - Stellt CPM dann wiederum selber Umschaltmethoden an > Anwendungsprogramme bereit? Das ist leider nicht vorgesehen. Anwenderprogramme haben nur die TPA zur Verfügung. > - Oder muss dann CPM-Software die Bank-Mechanismen des Z180 selber > nutzen Wenn ein Programm das macht, ist es streng genommen kein CP/M-Programm mehr, auf jeden Fall ist es nicht mehr portabel. Selbst wenn der nächste CP/M3-Computer die gleiche MMU hätte, könnte die Speicherverteilung ganz anders aussehen. Die Bankumschaltung über's BIOS ist zwar portabel, aber für Anwenderprogramme nicht immer erreichbar, da die Umschaltung aus dem Common-Bereich erfolgen muß. > und wenn ja - kommt sie sich dann nicht mit der CPM-Verwaltung > ins Gehege? s.o. > - Was für Speicher sieht ein CPM-Programm denn eigenltich in einem > banked CPM3? Die 64KByte, die als Bank 1 und Common geschaltet sind. Für das Programm frei nutzbar ist der TPA-Bereich. > - Irgendwie hatte ich den Eindruck, dass Banked CPM3 eh nur 2-3 Banks > nutzt, um gewisse OS-Anteile auszulagern und mehr TPA zur Verfügung zu > stellen? So siehts aus. Man kann bis zu 16 Banks zur Verfügung stellen. Das meißte davon kann aber nur als Sektor-Puffer (Platten-Cache) genutzt werden. > - Wie ist das dann auf "unserer" STAMP implementiert? Im Moment ist es so: (logische Adressen 4-stellig, physikalische Adressen 5-stellig) 16K Common (C000-FFFF, 3-4 Banks a max. 48K. (0000-BFFF) Z180 MMU: CBAR: C0 (Common Area1 beginnt bei C000, Banked Area bei 0000, Common Area 0 ungenutzt) CBR: 00 (Log. Addressen C000-FFFF werden auf phys. Adressen 0C000-0FFFF gemappt) BBR: 00, 10, 1C, 28, ... (für Bank 0, 1, 2, 3, ...) Bei dieser Aufteilung kann BBR einfach berechnet werden:
1 | ; Return the BBR value for the given bank number |
2 | ; |
3 | ; in a: Bank number |
4 | ; out a: bbr value |
5 | |
6 | bnk2log: |
7 | or a ; |
8 | ret z ; Bank 0 is at physical address 0 |
9 | |
10 | dec a |
11 | push bc ; |
12 | ld b,a ; |
13 | ld c,CA ; |
14 | mlt bc ; bank size * bank number |
15 | ld a,c ; |
16 | add a,10h ; add bank0 + common |
17 | pop bc ; |
18 | ret ; |
Der Common-Bereich ist so groß, damit man bequem debuggen kann. Später wird das BIOS weiter nach oben geschoben, und der Common-Bereich auf 8K oder 4K verkleinert.
1 | Log Phys Phys Phys |
2 | Addr Addr Addr Addr |
3 | FFFF 0FFFF+---------------+ +---------------+ +---------------+ |
4 | | | | | | | |
5 | E400 | Resident BIOS | | Resident BIOS | | Resident BIOS | |
6 | +---------------+ +---------------+ +---------------+ |
7 | | Resident BDOS | | Resident BDOS | | Resident BDOS | |
8 | +---------------+ +---------------+ +---------------+ |
9 | | High-order TPA| | | | High-order TPA| |
10 | | (not accessed | | | | (not accessed | |
11 | | while Bank 0 | | | | while Bank 2 | |
12 | | is active) | | | | is active) | |
13 | C000 0C000| | | | | | |
14 | +---------------+ | | +---------------+ |
15 | BFFF 0BFFF| | 1BFFF| | 27FFF| | |
16 | | Banked BDOS | | | | | |
17 | | | | | | | |
18 | +---------------+ | | | | |
19 | | | | | | | |
20 | | Banked BIOS | | Transient | | | |
21 | | | | Program | | | |
22 | +---------------+ | Area | | LRU | |
23 | | | | (TPA) | | Data | |
24 | | | | | | Buffers | |
25 | | | | | | | |
26 | | | | | | | |
27 | | | | | | | |
28 | | | | | | | |
29 | | | | | | | |
30 | | LRU Directory | | | | | |
31 | | Buffers | | | | | |
32 | | | | | | | |
33 | | | | | | | |
34 | | | | | | | |
35 | | | | | | | |
36 | | | | | | | |
37 | | | | +-----------+ | | | |
38 | | | | | Console | | +---------------+ |
39 | | | | | Command | | | | |
40 | | | | | Processor | | | CCP Reload | |
41 | 0100 | | | | (CCP) | | | Buffer | |
42 | +---------------+ +-+-----------+-+ +---------------+ |
43 | 0000 00000|///////////////| 10000| Page Zero | 1C000|///////////////| |
44 | +---------------+ +---------------+ +---------------+ |
45 | Operating system Application program Data sector buffers |
46 | Bank 0 Bank 1 Bank 2 |
Leo C. schrieb: > Marcel A. schrieb: >> Kann mir jemand eine gute Quelle nennen? > > Vielleicht "CP/M 3 Programmer’s Manual", Kapitel 1.1? > Im "CP/M 3 System Manual" ist das Speichermodell ab Kapitel 1.4 dann > nochmal dargestellt. > Danke, das hatte ich natürlich bereits gelesen und daraus meine anscheinend weitgehend richtigen Schlüsse gezogen. Danke auch für die tolle Speicherdarstellung. Auch so hatte ich mir das vorgestellt, gut gemacht!
Dieser Link ist auch recht informativ: http://www.prof80.de/ Hier wird die Hardware und Software für CP/M 3 anhand eines HD64180 beschrieben.
Mein Filetransfer macht Probleme. Habt ihr das mal versucht? A>PIP TEST.HEX=AUX:[B] meldet sicht trotz EOF am Fileende (nach erfolgreichem Filetransfer) nicht zurück. DEVICE scheint jedoch korrekt zu sein. A>DEVICE Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff AVRCON NONE IO ASCI0 19200 IOS ASCI1 19200 IOS Current Assignments: CONIN: = ASCI0 CONOUT: = ASCI0 AUXIN: = ASCI0 AUXOUT: = ASCI0 LST: = Null Device
> A>PIP TEST.HEX=AUX:[B]
Seltsame Dinge passieren da bei mir.
Wenn die Datei ein CP/M EOF am Ende hat, reicht es, wenn ich auf der
Console irgend ein Zeichen eingebe, damit der Prompt wieder erscheint.
Wenn die Datei kein EOF hat, muß ich an der Console ein EOF eingeben.
Wenn die Datei viele EOF hat, wie unter CP/M üblich, hängt sich alles
auf.
Bei diesen Versuchen waren AUX und CON immer auf der gleichen
Schnittstelle (ASCI0).
Das System hängt sich aber auch auf, wenn ich mit der Maus in das
Consolen-Terminal paste. Dürfte das gleiche Problem sein wie der 3. Fall
oben.
Der UART bekommt die Zeichen dann schneller, als CP/M sie lesen kann.
Dagegen könnte ein Interrupt-gesteuerter Empfangspuffer zwar helfen,
aber das System sollte auch so nicht hängen bleiben...
(Option "B" gibts beim CP/M 3 PIP nicht mehr. PIP scheint unbekannte
Optionen einfach zu ignorieren.)
Leo C. schrieb: > Wenn die Datei ein CP/M EOF am Ende hat, reicht es, wenn ich auf der > Console irgend ein Zeichen eingebe, damit der Prompt wieder erscheint. > Wenn die Datei kein EOF hat, muß ich an der Console ein EOF eingeben. > Wenn die Datei viele EOF hat, wie unter CP/M üblich, hängt sich alles > auf. Merkwürdig... Bei mir erscheint der Promt immer dann wenn ich EOF über die Konsole eingebe oder noch keinen Transfer gestartet habe. Kommt ein EOF in einer Datei vor beendet PIP manchmal, aber nicht immer. Nun habe ich mal die Option [H] versucht, natürlich mit einer Intel HEX-Datei. Ist es keine so kommt sofort eine Fehlermeldung, ist es eine so wird sie vollständig übertragen aber PIP kehrt nicht mehr zurück. Die Datei existiert dann als Test.$$$ ist aber korrekt.
Es scheint an den chario-Routinen zu liegen, obwohl ich mir das im Moment nicht so richtig vorstellen kann. Vielleicht muß im UART nach einem Overrun-Error der Fehlerstatus zurück gesetzt werden, oder so. Demnächst wollte ich die Treiber auf Interrupt umstellen (war im ddtz schon mal drin), aber das sollte auch mit Polling richtig funktionieren.
> Vielleicht muß im UART nach > einem Overrun-Error der Fehlerstatus zurück gesetzt werden, Das ist tatsächlich so. Solange das Overrun-Fehlerbit gesetzt ist, wird Receive-Data-Full nicht gesetzt. Das erklärt, warum die Schnittstelle hängen bleibt, wenn PIP nach dem ersten EOF keine Zeichen mehr abholt, aber noch weitere EOFs folgen. Es könnte auch passieren, daß der Receiver überläuft, wenn PIP einen Sektor auf "Platte" schreibt. Aber hier scheint das ja nicht der Fall zu sein, da Die Daten ja immer vollständig in der Datei waren.
Die neue BIOS Version scheint bezüglich des DEVICE korrekt zu laufen. Die Baudraten lassen sich alle einstellen. 134 Baud :-) (115200) laufen sogar richtig schnell. Auch der Filetransfer geht bei 115200 richtig schnell und fehlerfrei. Allerdings sollte man bei gleichem SIO-Kanal die Option [H] für den Filetransfer nicht benutzen, da CON dann auf AUX liegt und trotzdem alles auf den Bildschirm kommt. Ist dann ein EOF dabei, ist es vorbei mit den File. Die Übertragung mit PIP TEST.HEX=AUX: reicht also schon für ein INTEL HEX-File aus. Nach der Übertragung ein EOF über die Console senden und schon ist das File auf der SD-Card. Prima Sache!
:
Bearbeitet durch User
Joe G. schrieb: > Die neue BIOS Version Welche nutzt du bzw. hast du? > scheint bezüglich des DEVICE korrekt zu laufen. > Die Baudraten lassen sich alle einstellen. 134 Baud :-) (115200) laufen > sogar richtig schnell. Wie? > Auch der Filetransfer geht bei 115200 richtig > schnell und fehlerfrei. Allerdings sollte man bei gleichem SIO-Kanal die > Option [H] für den Filetransfer nicht benutzen, da CON dann auf AUX > liegt und trotzdem alles auf den Bildschirm kommt. Ist dann ein EOF > dabei, ist es vorbei mit den File. Die Übertragung mit > PIP TEST.HEX=AUX: Auf was ist AUX denn gemappt? ASCI0 (wo auch das Terminal dran hängt)? > reicht also schon für ein INTEL HEX-File aus. > Nach der Übertragung ein EOF über die Console senden vermutlich CRTL-Z? > und schon ist das File auf der SD-Card. > Prima Sache!
Marcel A. schrieb: > Welche nutzt du bzw. hast du? 6.1 > Wie? 115200 Baud > Auf was ist AUX denn gemappt? ASCI0 (wo auch das Terminal dran hängt)? Ja, die Baudrate für CON und AUX muß jedoch vorher über DEVICE eingestellt werden. > vermutlich CRTL-Z? ja, das ist das EOF von CP/M
Marcel A. schrieb: > Welche nutzt du bzw. hast du? Ich hatte Joe einen Zwischenstand mit geändertem UART-Treiber geschickt, um diesen ominösen PIP-Fehler einzugrenzen. > Wie? Als einzige Neuerung ist dort die Baudrateneinstellung drin. Leider aber auch ein schwer zu findender Fehler, der sich beim wiederholten Kaltstart bemerkbar macht ("restart" im Monitor).
Hier mal ein Vorschlag zur ECB-BUS Verschaltung des Steckverbinders. Die Farben sollten eigentlich selbsterklärend sein. grau/braun/blau - ECB BUS Standard braun - nur am Z180 belegt blau - nur am AVR belegt gelb – noch variabel (mein Vorschlag) Weiterhin enthält die Stamp Doku nun eine komplette Darstellung der beiden Stamp-Steckverbinder (Doku Anhang 1). Damit sollte das Stapeln oder das Fädeln einfacher sein :-)
Gibt es hier Leute, die vorhandene ECB-Karten mit dem Stamp-System verwenden wollen? Wenn ja, könnte man diese Karten ja bei der Zuordnung berücksichtigen. Da Kontron am Anfang leider einen Teil des Busses nicht definiert hatte, sind mehrere (Firmen-) Standards entstanden. Im Anhang ist eine Gegenüberstellung einiger davon. Die grünen Leitungen sind bei allen gleich. Der Rest teilt sich im Wesentlichen in 2 Lager (und einen Exoten): Kontron (dunkelblau) und Elzet (hellblau). Von Oettle&Reichler gibt es aber mindestens eine RAM-Karte, die in das Elzet-Lager fällt. Die "xxx" in der Conitec-Spalte sind wohl ein Druckfehler. Da "damals" das Elzet-Lager für Hobbyisten interessanter war, hatte ich mit dieser Belegung für das Stamp-System angefangen. Wie man sieht, bin ich aber noch nicht weit gekommen. Und da ich sowieso keine alten Karten habe, ist es mir egal. Ich würde /INT1 und /INT2 auf den ECB legen. Praktisch für I/O-Karten ohne Zilog-Bausteine. Falls die Leitungen knapp sind, könnte man einen davon statt des /NMI-Signals auf die /NMI-Leitung legen. In einem CP/M-System ist /NMI ja leider unbrauchbar. Aber da niemand gezwungen ist, CP/M auf dem System zu fahren... Jumper? Außerdem sollte man /DREQ1 und/oder /DREQ0 auf den Bus legen. Auf /TEND1 und /TEND0 kann man eher verzichten. Auf /BAI und /BAO kann man wahrscheinlich auch verzichten. Und /RFSH... Gut finde ich die I2C-Leitungen auf dem Bus. Daran hatte ich noch gar nicht gedacht. 3.3V auf VBAT ist sicher auch eine gute, kollisionsfreie Lösung. So weit mal meine aktuelle, unmaßgebliche Meinung.
Danke! Da haben wir ja schon eine recht hohe Übereinstimmung. A16-A19 in Lager 2 zu verschieben ist kein Problem. /ZRESET auf /RESOUT und /ARESET auf /RESET ist auch sinnvoll. Da eine DMA-Kette wohl in unserem System eher keine Verwendung finden wird, liegt auf /BAI und /BAO nun /INT1 und /INT2. Auch /DREQ0 und /DREQ1 finden Platz. 2CLK wird OC1A ( 2 ist also 0.5 :-) Auf drei Leitungen darf man sich noch austoben… Aber vielleicht kommt ja noch der eine oder andere Vorschlag von jemanden der noch ECB-Karten nutzen möchte.
> 2CLK wird OC1A ( 2 ist also 0.5 :-) Wenn der Z180 von OC1A versorgt wird, und der interne Taktteiler eingeschaltet ist, stimmts wieder. O&E haben auf nCLK den Baudratentakt gelegt. Das dürfte auch eher ein 1/n CLK sein. Auf 39c (CLK) sollte PHI vom Z180 gelegt werden. > Auf drei Leitungen darf man sich noch austoben… Ich hätte kein Problem damit, /RFSH umzudefinieren.
Da ja 39c korrekt tatsächlich PHI ist, muss CLK umziehen. Es darf nach 2CLK umziehen und nCLK bekommt dann OC1A. /RFSH steht dann auch noch zur freien Verfügung. Gibt immer noch 3 freie Pins. Wir müssen aber auch nicht alles belegen ;-)
Hallo, angeregt durch die PIP-Tests habe ich mich einmal an Kermit herangetraut. Zunächst habe ich eine Version "generisch" für CP/M 3 gelinkt, so dass ich das File im Anhang erhalte. Dieses läuft auch - grundsätzlich. Aber ich komme mit der Bedienung nicht klar, trotz Doku. Bei "GET" erscheinen einfach ein paar Sonderzeichen auf dem Bildschirm - sonst nichts. Senden einer Datei unter minicom am PC (ruft c-kermit auf) klappt nicht, Fehlermeldung "kein carrier". Bei "CONNECT" passiert nichts. Starte ich Kermit in der minicom-session, bekomme ich einen kermit-client. Dort kann ich auch carrier-detect abschalten. Aber nun habe ich ja keine Kontrolle mehr über die CP/M-Konsole. Ich vermute, für Kermit müsste ich eine 3. Verbindung über ASCI1 herstellen? Ist das schon implementiert? SHOW zeigt mir
1 | Autoreceive is off |
2 | Block check type: 1-character |
3 | Multi-sector buffering at 64 of a maximum of 64 |
4 | File COLLISION: RENAME |
5 | Debugging off |
6 | Current default disk: D |
7 | Display file size on DIRECTORY command on |
8 | Escape char: Control-\ |
9 | File Mode default |
10 | Flow control off |
11 | IBM flag off |
12 | Disposition for incomplete files is discard |
13 | Local echo off |
14 | Logging to D:KERMIT.LOG is off |
15 | Parity: none |
16 | Printer copy off |
17 | RECEIVE packet length 80 |
18 | RECEIVE start-of-pkt char ^A |
19 | SEND packet length 80 |
20 | SEND start-of-pkt char ^A |
21 | Current TACTrap Status/Intercept Character: off |
22 | Timer off |
23 | Current user number: 0 |
24 | Terminal display is REGULAR |
25 | Terminal emulation is OFF |
26 | File warning on |
Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen, also müsste man AUX über Device umlegen...? Vermutlich so...
1 | Current Assignments: |
2 | CONIN: = ASCI0 |
3 | CONOUT: = ASCI0 |
4 | AUXIN: = ASCI1 |
5 | AUXOUT: = ASCI1 |
6 | LST: = Null Device |
Aus der Kermit-Beschreibung:
1 | CP/M-3 Kermit (also known as CP/M-Plus Kermit) is a version of generic |
2 | Kermit-80, and should run on most CP/M-3 (CP/M-Plus) systems. It uses the |
3 | auxilliary port (AUX:) to communicate to the remote Kermit. The SET BAUD |
4 | and SET PORT commands are not supported; nor can a BREAK be sent. Like |
5 | generic Kermit-80, a terminal may be selected at assembly time. |
> angeregt durch die PIP-Tests habe ich mich einmal an Kermit > herangetraut. Hat Dein System die PIP-Tests denn bestanden? > Bei "GET" erscheinen einfach ein paar Sonderzeichen auf dem Bildschirm - > sonst nichts. Diese Sonderzeichen sollten wohl über die Kommunikationsschnittstelle an das andere Kermit gehen, damit es die Datei sendet. Bei Dir war diese Schnittstelle wohl identisch mit der CP/M-Console. Das funktioniert mit CP/M-Kermit wahrscheinlich nicht. > Senden einer Datei unter minicom am PC (ruft c-kermit auf) klappt nicht, > Fehlermeldung "kein carrier". Man müßte dem C-Kermit mitteilen (Config-Datei, oder so) das es an der Schnittstelle kein CD-Signal gibt. > Bei "CONNECT" passiert nichts. > > Starte ich Kermit in der minicom-session, bekomme ich einen > kermit-client. Dort kann ich auch carrier-detect abschalten. Aber nun > habe ich ja keine Kontrolle mehr über die CP/M-Konsole. Stattdessen (C-)Kermit auf dem PC nicht in minicom sondern direkt starten (im Servermode, falls es da nicht schon automatisch ist), mit Verbindung zu der Schnittstelle, die am anderen Ende an CP/M ASCI1 angeschlossen ist? minicom weiterhin zu CP/M ASCI0. > Ich vermute, für Kermit müsste ich eine 3. Verbindung über ASCI1 > herstellen? Wieso eine dritte? Wenn ich Dich richtig verstehe, versuchst Du z.Zt. alles über eine zu machen. Ist das schon implementiert? ASCI0 und ASCI1 funktionieren beide gleich seit Anbeginn. Gleich heißt in diesem Fall leider gleich schlecht. Siehe PIP weiter oben. > Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen, > also müsste man AUX über Device umlegen...? Genau so ist das gedacht.
Marcel A. schrieb: > Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen, > also müsste man AUX über Device umlegen...? Das geht bei CP/M 3 nicht [1]. Der Port ist immer AUX. Also ASCI1 mit Device auf AUX legen. Die Baudrate wird auch von CP/M 3 übernommen. Flow-Control und Handshake usw. über das SET Kommando einstellen. Wenn du SET Terminal VT52 einstelltst und dann Connect eingibst, sollte die Terminalverbindung zum zweiten Terminal laufen. Wenn das nicht geht, ist noch etwas faul. [1] 1.3.2. CP/M 3 Kermit CP/M 3 Kermit should run on most CP/M 3 (CP/M-Plus) systems. It uses the auxilliary port (AUX:) to communicate to the remote Kermit. The SET BAUD and SET PORT commands are not supported; nor can a BREAK be sent. Like Generic Kermit, a terminal may be selected at assembly time.
Joe G. schrieb: > Marcel A. schrieb: >> Aber wo stelle ich den Port ein - der scheint fest auf AUX zu liegen, >> also müsste man AUX über Device umlegen...? > > Das geht bei CP/M 3 nicht [1]. Hatte ich auch gelesen. So, es klappt nun! 3 USB Anschlüsse :-) - AVR Console - CP/M Console ASCI0 (115kB nach Device-Änderung) - Kermit auf ASCI1 (habe ich erst mal auf 19200 gelassen) Connect geht Filetransfer geht Servermode geht Weiter habe ich noch nicht getestet - aber so kann man auch sehr schön Dateien in ein laufendes System übertragen (wenn der PC im "servermode" ist echt kompfortabel). Und das ganze hätte ich jetzt gerne auch auf meinem NKC :-) Dort ist CP/M 2.2, aber in der firmware kein richtiger IOByte-Support. Das sind noch ganz andere Baustellen :-)
Marcel A. schrieb: > So, es klappt nun! Prima, dann ist ja jetzt etwas Zeit für eine kleine Fleißarbeit ;-) Wer Lust hat, kann ja mal eine kurze Pinkontrolle durchführen.
> Prima, dann ist ja jetzt etwas Zeit für eine kleine Fleißarbeit ;-) Er studiert wahrscheinlich gerade die cp*.asm Dateien, um Kermit an seinen NKC anzupassen. :-) > Wer Lust hat, kann ja mal eine kurze Pinkontrolle durchführen. Ein paar Leitungen sind nochmal gewandert... Keine Treiber für den Bus? Spart auf jeden Fall viel Arbeit. Ich denke auch, daß es klappen müßte. Software: Die Verbindung zur AVR-Console funktioniert jetzt. Baudrateneinstellung wurde seit dem letzten Zwischenstand etwas verbessert, aber es müßte noch besser gehen. Z.B. für "krumme Quarzfrequenzen".
Leo C. schrieb: > Keine Treiber für den Bus? Spart auf jeden Fall viel Arbeit. Ich denke > auch, daß es klappen müßte. Mein erstes System hatte ca. A4 Größe, alles ohne Bustreiber. Damals waren aber auch nur 2.5 MHZz Clock üblich ;-) > Software: > Die Verbindung zur AVR-Console funktioniert jetzt. Danke! Es bootet, auch mit einer schönen neuen Meldung über den Clock :-) Restart geht auch wieder, prima. 'Device CON:=AVRCON' verschwindet jedoch im Nirvana. Auch Optionen '[XON,134]' o.ä. mag es nicht. Wie ist hier die korrekte Syntax? Nachtrag: Mit welcher Baudrate läuft dann AVRCON?
:
Bearbeitet durch User
> 'Device CON:=AVRCON' > verschwindet jedoch im Nirvana. Hast Du am anderen Ende 'connect' eingegeben ? > Auch Optionen '[XON,134]' o.ä. mag es nicht. > Wie ist hier die korrekte Syntax? Nicht anders als bei anderen Devices auch. Allerdings wird nichts davon unterstützt. Über XON könnte man ja evtl. nachdenken Das mache ich aber erst, wenn es für die seriellen Schnittstellen implementiert ist. > Nachtrag: > Mit welcher Baudrate läuft dann AVRCON? Mit gar keiner. ;) Ist ja kein UART.
Leo C. schrieb: > Hast Du am anderen Ende 'connect' eingegeben ? natürlich nicht :-( >> Mit welcher Baudrate läuft dann AVRCON? > Mit gar keiner. ;) Ist ja kein UART. Klar, logisch, ich weiß auch nicht, was ich mir bei dieser Frage gedacht habe.
In Anlehnung an die Unix Time eine CP/M Time. Sehr nett :)) Wenn ich richtig gerechnet habe, dann ist das Geburtsdatum am 01.01.1978. Bei der Tagesdifferenz komme ich jedoch auf einen Tag weniger. (Ist aber nicht von Bedeutung) Das stellen der Uhr geht zunächst in beide Richtungen. Im Monitor sollte man jedoch nichts unter dem Jahr 2000 angeben, sonst zählt er vorwärts. Im CP/M geht’s ja sowieso nur ab 2000. Nachtrag: Wer mit PROFILE.SUB und AVRCON arbeitet, sollte noch ein CPM3_boot.dsk ohne PROFILE.SUB auf der SD-Card haben. So kann man bei Fehlern die Bootvariable auf dieses Laufwerk setzten. Ansonsten sperrt man sich tatsächlich vom CP/M aus :-(
:
Bearbeitet durch User
> Wenn ich richtig gerechnet habe, dann ist das Geburtsdatum am > 01.01.1978. Es ist etwas seltsam:
1 | The time of day is kept as four fields. @DATE is a binary word containing the number of days since 31 |
2 | December 1977. The bytes @HOUR, @MIN, and @SEC in the System Control Block contain the hour, |
3 | minute, and second in Binary Coded Decimal (BCD) format. |
> Bei der Tagesdifferenz komme ich jedoch auf einen Tag weniger. (Ist aber > nicht von Bedeutung) Vielleicht wollte man nicht ab 0 zählen. > Das stellen der Uhr geht zunächst in beide Richtungen. Im Monitor sollte > man jedoch nichts unter dem Jahr 2000 angeben, sonst zählt er vorwärts. Ja leider. Eingaben unter 2000 sollten deshalb noch abgefangen werden. > Im CP/M geht’s ja sowieso nur ab 2000. Das liegt am Monitor, genauer an der time-lib aus avr-libc 1.8.1 Die geht erst ab 1.1.2000. Dafür aber bis 2136.
1 | Though not specified in the standard, it is often expected that time_t is a signed |
2 | integer representing an offset in seconds from Midnight Jan 1 1970... i.e. 'Unix time'. |
3 | This implementation uses an unsigned 32 bit integer offset from Midnight Jan 1 2000. The |
4 | use of this 'epoch' helps to simplify the conversion functions, while the 32 bit value |
5 | allows time to be properly represented until Tue Feb 7 06:28:15 2136 UTC. |
Für ein Retroprojekt natürlich etwas schade, daß man keine "Guten Alten Zeiten" einstellen kann. Außerdem ist noch ein Fehler drin. Man sollte die Uhr nicht nach 9:00 Uhr stellen (Integer-Überlauf, inzwischen behoben). Und wenn man die Uhr im Monitor stellt, bekommt das laufende CP/M das nicht mit. Kann man auch noch ändern.
Leo C. schrieb: > The time of day is kept as four fields. @DATE is a binary word > containing the number of days since 31 December 1977. Dann scheint die Zählung zu stimmen. Gezählt wird ab dem 01.01.1978 und der 31.12.1977 wird mitgezählt ;-) > Und wenn man die Uhr im Monitor stellt, bekommt das laufende CP/M das > nicht mit. Kann man auch noch ändern. Beim Neustart von CP/M stimmt ja dann die Zeit, oder CP/M wird gleich aktualisiert so wie umgekehrt bei DATE SET aus CP/M. andere Baustelle: Könnte man die PIN SET Befehle aus dem Monitor nicht auch CP/M verfügbar machen? z.B. über einen OUT Befehl auf einer noch zu definierenden Adresse. Dann könnte die RS-232 / USB Umschaltung am RS-232 Treiber direkt aus CP/M gesteuert werden. Im AVR CP/M der letzten Version mit I2C-Port war das ja auch realisiert. CP/M könnte dann prinzipiell Onboard Konfigurationen selbst durchführen.
Joe G. schrieb: > Leo C. schrieb: >> Hast Du am anderen Ende 'connect' eingegeben ? > > natürlich nicht :-( Das bedeutet, man muss erst auf ASCI0 auf die CPM-Konsole, dort den Device Befehl eingeben. Dann in der AVR-Console "connnect" eingeben? Damit braucht man ja auch weiterhin immer mindestens 2 Verbindungen/Konsolen? > >>> Mit welcher Baudrate läuft dann AVRCON? >> Mit gar keiner. ;) Ist ja kein UART. Wie löst man die Verbindung denn wieder auf? DEVICE wieder umlegen? Wie löst man den "connect" denn wieder? > > Klar, logisch, ich weiß auch nicht, was ich mir bei dieser Frage gedacht > habe.
Joe G. schrieb: > Könnte man die PIN SET Befehle aus dem Monitor nicht auch CP/M verfügbar > machen? Guter Vorschlag. > z.B. über einen OUT Befehl auf einer noch zu definierenden Da wir hier echte Hardware und keinen Emulator haben, geht es auf die Art nicht. Zur Zeit gibt es ein einfaches Protokoll: Z180 sendet Anforderung/Befehl an Monitor - Monitor schickt Antwort (oder auch nicht). Die Liste der Befehle wird bei Bedarf erweitert. Zur Zeit also täglich. :) Marcel A. schrieb: > Das bedeutet, man muss erst auf ASCI0 auf die CPM-Konsole, dort den > Device Befehl eingeben. Dann in der AVR-Console "connnect" eingeben? Bei den jetzigen Defaulteinstellungen, ja. Die sind so für mich praktisch zum Debuggen. > Damit braucht man ja auch weiterhin immer mindestens 2 > Verbindungen/Konsolen? 1. werden die Defaulteinstellungen natürlich irgendwann so geändert, daß sie für die Mehrzahl der Anwendungen möglichst passend sind. 2. kann man jetzt schon (fast) alles "scripten". PROFILE.SUB auf CP/M und Environment (bootcmd) und run-Befehl im Monitor. Das kann aber Probleme geben, wenn man sich die CP/M-Console wegkofiguriert und dann nicht mehr dran kommt. (Siehe Nachtrag in Beitrag "Re: Z180-Stamp Modul") 3. werden deshalb die Grundeinstellungen für die CP/M Console doch mal in den Monitor kommen (Beitrag "Re: Z180-Stamp Modul" f.). > Wie löst man die Verbindung denn wieder auf? DEVICE wieder umlegen? > Wie löst man den "connect" denn wieder? Beitrag "Re: Z180-Stamp Modul"
Marcel A. schrieb: > Damit braucht man ja auch weiterhin immer mindestens 2 > Verbindungen/Konsolen? Die Konfigurationsmöglichkeiten sind Dank Leo’s Programmierkünsten schon jetzt recht groß. Leo kennst sie alle, er programmiert ja, ich dokumentiere sie fleißig mit. Am WE wird es wieder eine Ergänzung im Handbuch geben, die genau die Konfiguration mittels Skript und den Monitorvariablen beschreibt.
> Die Konfigurationsmöglichkeiten sind Dank Leo’s Programmierkünsten schon > jetzt recht groß. Ich glaube, das liegt eher an meiner Entscheidungsschwäche. ;) Dazu kommt der Hang, vorhandene Ressourcen optimal auszunutzen... Dabei fällt mir ein, daß wir noch 238 Byte CMOS-RAM in der Uhr haben. Die könnte CP/M (BIOS) z.B. nutzen, um Einstellungen zu speichern. Der Monitor würde die Bytes einfach transparent durchreichen. Man könnte entweder ein einfaches CP/M-Programm für save/load bauen, oder die Einstellungen bei jeder Änderung ins CMOS-RAM kopieren. Dann hätte man bei jedem Kaltstart die letzten Einstellungen wieder. Die in Frage kommenden Einstellungen sind im Wesentlichen die R/W-Bytes im SCB (Anhang), vor allem Character-I/O Zuordnungen und Baudraten (nicht im SCB, sondern in der @cdtbl), bzw die Werte, die mit DEVICE und SETDEF eingestellt werden. Im Monitor müßte dann nichts über CP/M-Einstellungen wissen. Meinung?
:
Bearbeitet durch User
Angehängte Dateien:
-
8_Inch.jpg
300 KB
Leo C. schrieb: > Dabei fällt mir ein, daß wir noch 238 Byte CMOS-RAM in der Uhr haben. > Die könnte CP/M (BIOS) z.B. nutzen, um Einstellungen zu speichern. Sehr gute Idee! Ich würde die Variante eines eigenen kleinen Save/Load als sinnvoller empfinden. PROFILE.SUB führt das LOAD aus und um SAVE muss man sich halt selber kümmern. Diese Variante hätte den Vorteil eigener Save/Load Routinen. Die Z180-Stammp Variante muss ja nicht in jedem Fall in Kombination mit dem AVR-Stamp aufgebaut werden. In diesem Fall würden ja automatische Routinen ins Leere laufen oder Fehler verursachen. Hingegen eigene Save/Load Routinen könnten der eigenen Hardware (IDE, Floppy [1], ...) angepaßt werden. [1] Bild im Anhang - man vergleiche die Stamp-Größe zur Diskettengröße :-)
> Ich würde die Variante eines eigenen kleinen Save/Load als sinnvoller > empfinden. PROFILE.SUB führt das LOAD aus und um SAVE muss man sich halt > selber kümmern. Gerade PROFILE.SUB wollte ich damit vermeiden. Das verlängert den Bootvorgang schon sehr deutlich. > Diese Variante hätte den Vorteil eigener Save/Load Routinen. Die > Z180-Stammp Variante muss ja nicht in jedem Fall in Kombination mit dem > AVR-Stamp aufgebaut werden. In diesem Fall würden ja automatische > Routinen ins Leere laufen oder Fehler verursachen. Die Funktionalität wäre im BIOS. Und das ist ja gerade die Schnittstelle zur AVR-Stamp, und muß bei einer anderen Kombination sowieso ausgetauscht werden. Zuerst hatte ich auch nur die Parameter im Sinn, die das BIOS sowieso anfaßt (Baudraten, etc). Wenn man die anderen Parameter auch speichern will, ist aber ein eigenständiges Programm besser. Sonst holt man sich Äbhängigkeiten ins BIOS, die dort nichts verloren haben. > Hingegen eigene > Save/Load Routinen könnten der eigenen Hardware (IDE, Floppy [1], ...) > angepaßt werden. Im Fall AVR-Stamp wäre es dann der Kommuniktionskanal zum Monitor im BIOS.
Leo C. schrieb: > Zuerst hatte ich auch nur die Parameter im Sinn, die das BIOS sowieso > anfaßt (Baudraten, etc). Wenn man die anderen Parameter auch speichern > will, ist aber ein eigenständiges Programm besser. Sonst holt man sich > Äbhängigkeiten ins BIOS, die dort nichts verloren haben. Diese Variante klingt sinnvoll. Übrigens werde ich die connect Console vom Monitor nicht mit 'strg ^X' los.
Joe G. schrieb: > Übrigens werde ich die connect Console vom Monitor nicht mit 'strg ^X' > los. Control-Dach ('^') und danach X.
Leo C. schrieb: > Control-Dach ('^') und danach X. Schon klar, aber werde Control^ X noch Control^ x tun was.
Bei mir gings zuerst, aber ich habe etwas wild rumgedrückt, und jetzt hat sich anscheinend alles aufgehängt. :-(
Marcel A. schrieb: > Damit braucht man ja auch weiterhin immer mindestens 2 > Verbindungen/Konsolen? Hier mal ein Auszug aus der Doku zu den Environmentvariablen und zur Befehlsabarbeitung (vollständig im SVN). Damit startet das CP/M direkt auf der AVR-Console ohne externe RS-232 oder USB-Wandler. Sozusagen CP/M für 'Arme' ;-)
Joe G. schrieb: > Hier mal ein Auszug aus der Doku zu den Environmentvariablen und zur > Befehlsabarbeitung (vollständig im SVN). Damit startet das CP/M direkt Klasse Tutorial, danke. Die Console hat noch ein paar Macken. Wenn man nach "Ctrl-^ \" Unsinn eingibt, hängt sie sich auf. > Schon klar, aber werde Control^ X noch Control^ x tun was. Bei mir tun beide "as advertised". Geht denn "Ctrl-^ Q" bei Dir? Einen komischen Effekt hatte ich ein mal mit "Ctrl-^ Ctrl-X". Kann ich aber nicht mehr reproduzieren.
Leo C. schrieb: > Bei mir tun beide "as advertised". Geht denn "Ctrl-^ Q" bei Dir? Geht auch nicht, auch nicht "Ctrl-^ ?". Ich habe auch mal das Terminalprogramm gewechselt, gleiches Ergebnis. Interessant ist das Verhalten wenn die Zeile schon vollgeschrieben ist. Dann setzt "Ctrl-^ x" (alles gleichzeitig) den Cursor auf den Zeilenanfang.
Angehängte Dateien:
-
ECB.jpg
180 KB
Das Routing war nicht schön, aber jetzt gibt es eine akzeptabele Lösung für das ECB-Layout (2 Lagen).
:
Bearbeitet durch User
Angehängte Dateien:
-
stamp-rack.jpg
120 KB
Sieht gut aus. Ich spiele mit dem Gedanken, das System dann in mein altes 19" Rack zu schieben. Allerdings weiß ich nicht, wie ich dann an die USB-Schnittstelle auf der AVR-Stamp kommen soll. Ist es möglich, den SD-Slot etwas nach unten zu schieben? In der Ecke würde Platz für einen Frontplattten-Montagewinkel gebraucht. (Foto hier: Beitrag "Re: Z180-Stamp Modul") Zwischen den beiden Winkeln sind knapp 81mm Platz. Muß aber nicht unbedingt sein.
Leo C. schrieb: > Die Console hat noch ein paar Macken. Wenn man nach "Ctrl-^ \" Unsinn > eingibt, hängt sie sich auf. So schlimm wars dann doch nicht. Die Console hat nach dem '\' drei Dezimalziffern eingesammelt, und wenn man dazwischen andere Zeichen getippt hat, wurden die einfach ignoriert. Ich habe das jetzt so geändert, daß die Code-Eingabe sofort beendet wird, wenn man andere Zeichen als Ziffern eingibt.
Leo C. schrieb: > Ist es möglich, den SD-Slot etwas nach unten zu schieben? In der Ecke > würde Platz für einen Frontplattten-Montagewinkel gebraucht. Hatte ich schon auf meinem Plan und zunächst aus Platzproblemen wieder gestrichgen. SD-Card, 2x Reset + 2x RS-232 habe ich nicht ordentlich auf der Frontplatte unterbekommen. Dazu kommen ja noch die drei LED's. Aber ich stimme dir zu, für eine ordentliche Befestigung sind diese Winkel eigentlich notwendig. Ich versuche mal eine Variante ohne auf Micro-SD zu wechseln. > Allerdings weiß ich nicht, wie ich dann an die > USB-Schnittstelle auf der AVR-Stamp kommen soll. Auf dem AVR-Stamp sind ja noch einige Anschlüsse NC. Mal sehen ob dort USB mit kurzen Verbindungen zu platzieren ist.
Die Montagewinkel sind realisiert. RS-232 ist nun nebeneinander. Über der SD-Card ist sogar noch Platz für eine USB-Einbaubuchse. Hier könnte der Monitoranschluss verlängert werden.
:
Bearbeitet durch User
Joe G. schrieb: > Die Montagewinkel sind realisiert. Ich hatte gerade einen Kommentar zu Deinem letzten Artikel angefangen. Der ist jetzt größtenteils erledigt. :-) > RS-232 ist nun nebeneinander. Am rechten Rand übereinander ginge aber auch. Die breite Frontplatte braucht man so oder so wg. der Höhe der Stamp-Karten. Aber nebeneinander sieht doch besser aus, und die angeschlossenen Kabel versperren nicht die Sicht. > Hier könnte der Monitoranschluss verlängert werden. Würde ich aber nicht unbedingt über die Pfostenleiste machen. Gestern habe ich mal die Zustands-LED angeschlossen. Rot (Halt) und Grün (Running) sind OK. Die Mischfarbe (Monitor) ist aber komisch und stark Blickwinkelabhängig und (für mich) nicht immer klar von Grün zu unterscheiden. Das liegt sicher auch an meiner Rot-Grün-Schwäche und es wird besser, wenn der hintere Teil der Led abgedeckt ist. Im Gehäuse ist das ja sowieso der Fall. Mit den Vorwiderständen kann ich noch etwas experimentieren. Man kann übrigens auch eine 2-Pin Duo-Led anschließen. Die zeigt dann Halt und Running an, und ist im Monitor-Betrieb dunkel.
Leo C. schrieb: >> Hier könnte der Monitoranschluss verlängert werden. > > Würde ich aber nicht unbedingt über die Pfostenleiste machen. Ich sehe noch eine Lösung. Die beiden seriellen Leitungen des AVR (RxD,TxD) werden mit auf die noch freien Pins der Stiftleisten gelegt und bei Bedarf der FTDI über Pin 19 in den Reset geschickt. Das habe ich auf dem VT100 auch so realisiert. Beim Reset meldet der FTDI sich einfach beim Host ab.
> Ich sehe noch eine Lösung. > Die beiden seriellen Leitungen des AVR (RxD,TxD) werden mit auf die noch > freien Pins der Stiftleisten gelegt und bei Bedarf der FTDI über Pin 19 Das finde ich gut. Ich habe mal nach Alternativen gesucht. Leider finde ich zu den diversen gewinkelten USB-Adaptern und -Kabeln keine Maße. Ich fürchte aber, daß die alle zu groß sind. Der Stecker hier ist in die falsche Richtung abgebogen: http://www.reichelt.de/USB-Kabel/DELOCK-82680/3/index.html?ACTION=3&GROUPID=6099&ARTICLE=138017 Der wäre wohl richtig, wenn er denn passen würde. http://www.reichelt.de/USB-Kabel/DELOCK-83356/3/index.html?ACTION=3&GROUPID=6099&ARTICLE=135443
Leo C. schrieb: > Der Stecker hier ist in die falsche Richtung abgebogen: Leo C. schrieb: > Das finde ich gut. Ich auch :-) deshalb noch der folgende Erweiterungsvorschlag. CP/M 3 dürfte noch neben USB0 alias AVRCON auch noch USB1 und USB2 bekommen. Wenn beim Device Befehl gleichzeitig ein AVR-Pin (Set Pin) [1] geschaltet wird, könnte dieses Pin automatisch die beiden Treiber [RS-232 (MAXIM) und FT232 (FTDI)] toggeln. Hier scheinen sich beide Hersteller abgesprochen zu haben, die dazu notwendigen Signale sind gerade invers :-) [1] Beitrag "Re: Z180-Stamp Modul"
Joe G. schrieb: > CP/M 3 dürfte noch neben USB0 alias AVRCON auch noch USB1 und USB2 > bekommen. Wenn beim Device Befehl gleichzeitig ein AVR-Pin (Set Pin) [1] > geschaltet wird, könnte dieses Pin automatisch die beiden Treiber > [RS-232 (MAXIM) und FT232 (FTDI)] toggeln. Kann man machen. Allerdings könnte dann jemand beide Varianten gleichzeitig zuordnen: AUX:=V24-1, USB1 oder AUXIN:=USB1 AUXOUT:=V24-1 Erst dachte ich, kein Problem, die jeweils letzte Einstellung gewinnt. Aber der Treiber muß dann auch die Bitvektoren, in denen die Zuordnung gespeichert ist, manipulieren[*]. Machbar, aber nicht schön. Schöner wäre ein zusätzliches Attribut für die Devices. Das ginge in einem Aufwasch mit Attributen für Parity, Wortbreite, Hardware-Handshake und die Baudraten über 19200. Alles was man dafür braucht ist ein erweitertes Programm 'DEVICE.COM'. Das wäre doch eine schöne Fingerübung für jemanden, der seine Assembler-, PL/M-, C- oder TurboPascal-Kenntnisse auffrischen will. ;-) [*] Diese hier im SCB:
1 | @civec equ scb$base+22h ; Console Input Redirection Vector (word, r/w) |
2 | @covec equ scb$base+24h ; Console Output Redirection Vector (word, r/w) |
3 | @aivec equ scb$base+26h ; Auxiliary Input Redirection Vector (word, r/w) |
4 | @aovec equ scb$base+28h ; Auxiliary Output Redirection Vector (word, r/w) |
5 | @lovec equ scb$base+2Ah ; List Output Redirection Vector (word, r/w) |
Leo C. schrieb: > oder > AUXIN:=USB1 > AUXOUT:=V24-1 Stimmt, dumme Kombination :-( Ein eigens DEVICE.COM ist wohl praktischer, auch kann gleich 134.5 übersetzt werden. > was man dafür braucht ist ein > erweitertes Programm 'DEVICE.COM'. Das wäre doch eine schöne Fingerübung > für jemanden, der seine Assembler-, PL/M-, C- oder > TurboPascal-Kenntnisse auffrischen will. ;-) Mit meiner heutigen Fingerübung kann ich schon den SCB-Block lesen und schreiben. Wo steht eigentlich der tatsächlich zugehörige Name zu der Bitbelegung in Reg 22H-2BH ? Also Bit 15 in Reg 22H ist ja z.B. 'ASCI0'. Oder wird einfach das jeweilige Bit an ASCIx gesetzt? Nachtrag: verzählt, Bit 15 ist natürlich AVRCON
:
Bearbeitet durch User
> Wo steht eigentlich der tatsächlich zugehörige Name zu der > Bitbelegung in Reg 22H-2BH Im BIOS gibt es eine Tabelle in der Datei chario.180. In einem laufenden System findet man sie über eine Funktion in der BIOS-Sprungleiste ("return char dev table" oder so ähnlich).
1 | @ctbl: |
2 | db 'USB0 ' ; device 0 |
3 | db mb$in$out |
4 | db baud$none |
5 | db 'ASCI0 ' ; device 1 |
6 | db mb$in$out+mb$serial+mb$soft$baud |
7 | db baud$19200 |
8 | db 'ASCI1 ' ; device 2 |
9 | db mb$in$out+mb$serial+mb$soft$baud |
10 | db baud$19200 |
11 | db 0 ; table terminator |
Bis 16 Geräte sind möglich. In den "Redirection-Vektoren" ist für jedes
Gerät ein Bit vorgesehen. Höchstwertigstes Bit (Bit 15) für Device 0,
bis niederwertigstes Bit (Bit 0) für Device 15. Ein gesetztes Bit
bedeutet eine Verbindung des Kanals zum Gerät. Sind mehrere Bits bei
einem log. Output-Device gesetzt, wird an alle Greäte ausgegeben. Bei
mehreren Input-Devices wird der Input vom ersten Gerät genommen.
Ein Eintrag in der @ctbl ist 8 Byte groß. Davon 6 Byte für den
Gerätenamen, ein Byte Eigenschaften und Status und ein Byte für
Baudrate.
Für die Baudrate sind nur 4 Bit definiert und im mode byte sind auch
noch ein paar Bits ungenutzt. Ob eine Nutzung dieser Bits unerwünschte
Nebenwirkungen hätte, kann ich nicht sagen. Durch das Original
DEVICE.COM werden sie wahrscheinlich auf 0 gesetzt.
Die Bitdefinitionen für die @ctbl findet man in modebaud.inc oder
MODEBAUD.LIB oder so:
[/pre]
; equates for mode byte bit fields
mb$input equ 00000001b ; device may do input
mb$output equ 00000010b ; device may do output
mb$in$out equ mb$input+mb$output
mb$soft$baud equ 00000100b ; software selectable
; baud rates
mb$serial equ 00001000b ; device may use protocol
mb$xon$xoff equ 00010000b ; XON/XOFF protocol
; enabled
baud$none equ 0 ; no baud rate associated
; with this device
baud$50 equ 1 ; 50 baud
baud$75 equ 2 ; 75 baud
baud$110 equ 3 ; 110 baud
baud$134 equ 4 ; 134.5 baud
baud$150 equ 5 ; 150 baud
baud$300 equ 6 ; 300 baud
baud$600 equ 7 ; 600 baud
baud$1200 equ 8 ; 1200 baud
baud$1800 equ 9 ; 1800 baud
baud$2400 equ 10 ; 2400 baud
baud$3600 equ 11 ; 3600 baud
baud$4800 equ 12 ; 4800 baud
baud$7200 equ 13 ; 7200 baud
baud$9600 equ 14 ; 9600 baud
baud$19200 equ 15 ; 19.2k baud
[/pre]
Die BIOS-Sources sind übrigens auch auf meinem Server zu finden. Mit
SLR180.COM, dem DR Linker LINK80.COM und GENCPM.COM kann man cpm3.sys
auf einem CP/M.System bauen. Wenn man zxcc auf dem PC installiert hat,
geht es auch dort mit dem Makefile.
Danke für die vielen Hinweise! > Bis 16 Geräte sind möglich. In den "Redirection-Vektoren" ist für jedes > Gerät ein Bit vorgesehen. Höchstwertigstes Bit (Bit 15) für Device 0, > bis niederwertigstes Bit (Bit 0) für Device 15. Das deckt sich mit meiner Leseroutine. > Sind mehrere Bits bei > einem log. Output-Device gesetzt, wird an alle Greäte ausgegeben. Bei > mehreren Input-Devices wird der Input vom ersten Gerät genommen. Ich hatte mich schon über die 'Bitverschwendung' gewundert. Aber das macht Sinn wenn auf mehrere Geräte verteilt wird. > Die BIOS-Sources sind übrigens auch auf meinem Server zu finden. Ok, da finde ich ja die Definitionen. Ich schreibe gerade, als Fingerübung ;-) einige Hilfsfunktionen wie Int_to_HEX oder HEX_to_Int usw. Ganz schön umständlich wenn man das mit den Funktionsumfang heutiger Programmiersprachen vergleicht. Ist jedoch eine prima Übung und ich erwische mich gerade wie alte CTRL-Kommandos zum Kopieren, Einfügen oder Löschen wieder ganz automatisch aus den Fingern kommen - wie vor 30 Jahren.
Joe G. schrieb: > Ich schreibe gerade, als Fingerübung ;-) einige Hilfsfunktionen wie > Int_to_HEX oder HEX_to_Int usw. Ganz schön umständlich wenn man das mit > den Funktionsumfang heutiger Programmiersprachen vergleicht. Ist jedoch > eine prima Übung und ich erwische mich gerade wie alte CTRL-Kommandos > zum Kopieren, Einfügen oder Löschen wieder ganz automatisch aus den > Fingern kommen - wie vor 30 Jahren. Für solche Standardlösungen, die in jedem BIOS gebraucht werden, sind Quellen anderer Systeme, wie z.B. unter http://www.prof80.de/downloads.html#prof80 ja auch ganz hilfreich. Ich kannte mich mal recht gut aus mit dem PROF/GRIP-Projekt aus der c't der 80er Jahre und bin mir sicher, dass es dort in den BIOS-Quellen manch interessante Routine zu finden gab. Leider sind die Quellen in den umständlichen Intel-Mnemonics geschrieben und ich hatte mal angefangen, Teile in Zilog-Sprache zu übersetzen... Gruß, Wolfram P.S.: Ctrl-C/Ctrl-V/Ctrl-X verlernt man nicht so schnell :-) P.P.S.: Habe meinen stamp leider noch nicht fertig :-((
Nachtrag: Das meiste wird beim PROF im Monitor abgewickelt und dann vom BIOS aus angesprungen. Daher liest sich z.B. http://www.prof80.de/files/zmon17.zip ganz gut.
Hier mal wieder ein Update um Testen übers Wochenende. Neu ist vor allem die Zuordnung des physikalischen RAMs zu den CP/M-Banks: Common folgt nicht mehr auf Bank 0 sondern auf Bank 1. Damit nichts verschwendet wird ;), folgt Bank 1 unmittelbar auf Bank 0. Außerdem wurde der Common-Bereich von 16K auf 4K verkleinert: Bank 0: 00000 - 0EFFF Bank 1: F0000 - 1DFFF (+ F000) common: 1E000 - 1EFFF (+ F000) Bank 2: 1F000 - 2DFFF (+ F000 + 1000) usw. (+ F000) Vorteil: Die TPA ist jetzt auch im physikalischen Speicher zusammenhängend. Dadurch gehen Interbank Memory-Move und Transfer von und zur Disk ohne Sonderbehandlungen. In der neuen Version geht der Interbank move jetzt mit DMA und der AVR-Disktreiber konnte vereinfacht werden und funktioniert mit Multi-Sector-Transfer. Eigentlich müßte die Version jetzt schneller laufen, aber das habe ich noch nicht getestet. Nachteil: loadcpm3 braucht die Information, wo der Common-Bereich liegt, und die Ladeadresse kann nicht mehr direkt angesprungen werden. Dazu müßte zuerst die MMU programmiert werden. Die Common-Base- und die Banked-Base-Adresse können auf der Befehlszeile von loadcpm3 angegeben werden, oder in Environment-Variablen gesetzt werden (Siehe "help loadcpm3"). Wichtig ist nur die Common-Base. Achtung: Der Defaultwert ist noch auf C000. Deshalb muß für das mitgelieferte cpm3.sys F000 auf eine der beiden Arten vorgegeben werden. In der nächsten Version wird der Defaultwert aus cpm3.sys ausgelesen. Sonstiges: Verbesserungen an der Console (connect command). Commandline editing (endlich:) Letzteres ist noch nicht ganz fertig. Für Erweiterungen und die Tastenzuordnungen nehme ich gerne Änderungsvorschläge entgegen. Für das Verhalten des Historybuffers auch. Das ist sowieso noch eine Baustelle.
Leo C. schrieb: > Verbesserungen an der Console (connect command). Perfekt! Nun kann ich sie wieder ohne Klimmzüge beenden. Sogar die Hilfe geht nun bei mir ;-) > Commandline editing (endlich:) Das spart viel Neugetippe beim Vergetippe Der Bootvorgang läuft stabil durch. Jetzt kann ich testen...
Wolfram K. schrieb: > Für solche Standardlösungen, die in jedem BIOS gebraucht werden, sind > Quellen anderer Systeme, wie z.B. unter Danke für den Tipp. Wirklich sehr viel Nützliches. Ganz neu erfinde ich ja die Unterprogramme doch nicht. Ich schaue schon mal in fremde Quellen ;-)
Leo C. schrieb: > Hier mal wieder ein Update um Testen übers Wochenende. Die BIOS-Funktion 20 (DEVTBL) liefert mir einen falschen Pointer zurück. Korrekt (derzeitiges BIOS) scheint 0xFCA4. Der Aufruf von BIOS 20 liefert jedoch 0xD2C3 zurück?
:
Bearbeitet durch User
Seltsam. Evtl. irgendwo hex und dez vertauscht? Bei mir funktionierts. Die Addresse hat sich inzwischen verändert (FC7E), aber wegen Änderungen an anderer Stelle.
1 | >>ll |
2 | 0100 LD C,32 |
3 | 0102 LD DE,0110 |
4 | 0105 CALL 0005 |
5 | 0108 NOP |
6 | 0109 NOP |
7 | 010A NOP |
8 | 010B NOP |
9 | 010C NOP |
10 | 010D NOP |
11 | 010E NOP |
12 | 010F NOP |
13 | 0110 INC D |
14 | 0111 NOP |
15 | 0112 NOP |
16 | 0113 NOP |
17 | 0114 NOP |
18 | >>d 110 s7 |
19 | 0110 14 00 00 00 00 00 00 ....... |
20 | > x |
21 | ZHV E A =7E BC =0000 DE =0000 HL =0000 SP=D200 PC=0100 LD C,32 |
22 | A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF |
23 | > c |
24 | ZHV E A =7E BC =0032 DE =0000 HL =0000 SP=D200 PC=0102 LD DE,0110 |
25 | A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF |
26 | >> |
27 | ZHV E A =7E BC =0032 DE =0110 HL =0000 SP=D200 PC=0105 CALL 0005 |
28 | A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF |
29 | >> |
30 | ZHV E A =7E BC =FC32 DE =0110 HL =FC7E SP=D200 PC=0108 NOP |
31 | A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=FF |
32 | >>dfc7e |
33 | FC7E 55 53 42 30 20 20 03 00 41 53 43 49 30 20 0F 03 USB0 ..ASCI0 .. |
34 | FC8E 41 53 43 49 31 20 0F 0F 00 B7 D8 DA D8 FD D8 20 ASCI1 ...7XZX}X |
35 | FC9E D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Y............... |
36 | FCAE 00 00 00 00 00 00 00 00 00 ED 43 0E FD C9 EB 3A .........mC.}Ik: |
37 | FCBE 0E FD FE FE 20 0B ED B0 EB C9 CD 5A FD ED 39 39 .}~~ .m0kIMZ}m99 |
38 | FCCE C9 ED 09 26 ED 01 27 E5 D5 3A 0E FD CD 6A FD ED Im.&m.'eU:.}Mj}m |
39 | FCDE 29 20 ED 21 21 ED 39 22 EB 3A 0F FD CD 6A FD ED ) m!!m9"k:.}Mj}m |
40 | FCEE 29 23 ED 21 24 ED 39 25 3E 02 ED 39 31 3E 60 ED )#m!$m9%>.m91>`m |
41 | >> |
Leo C. schrieb: > Seltsam. Evtl. irgendwo hex und dez vertauscht? Eigentlich nicht, laut BIOS Jump Table ist es doch die Funktion 20 (dezimal). Der Funktionsaufruf liefert mir auch einen Pointer zurück, allerdings einen falschen :-(
Hab gerade gesehen, dass du einen BDOS-Aufruf 50 (direkten BIOS-Aufruf) machst. Das werde ich auch mal testen, hatte selbst ja einen direkten BIOS-Audfruf durchgeführt.
Angehängte Dateien:
-
Bildschirmfoto.png
35 KB
> Hab gerade gesehen, dass du einen BDOS-Aufruf 50 (direkten BIOS-Aufruf) > machst. Das habe ich nur deswegen gemacht, weil ich dachte Du machst es auch so. ;) Normalerweise zähle ich die BIOS-Funktionen nicht ab. Aber beim Aufruf über BDOS muß man ja. Ich habe es nochmal mit dem zu letzt veröffentlichten BIOS versucht. Zur Abwechslung diesmal als Screenshot. Die Addresse ist aber nochmal eine andere.
Ein Aufruf über DDTZ gibt mir auch das korrekte Ergebnis. >>d^hl s3*8 FCA4 55 53 42 30 20 20 03 00 41 53 43 49 30 20 1F 04 USB0 ..ASCI0 .. FCB4 41 53 43 49 31 20 0F 0F ASCI1 .. >> Ein Aufruf über die Turbo-Pascal Funktion BIOSHL(20) produziert den Fehler. Wird also ein Turbo Pascal Bug sein. Mal sehen wie ich das umgehen kann.
Leider habe ich gerade kein TP zum Testen parat, aber TP zählt die BIOS-Funktionen ab wboot = 0. BDOS(50) zählt wboot=1. Die Funktionsnr. unter TP wäre dann 19.
Wer hätte das gedacht, wie immer sitzt der Fehler hinter dem Computer :-( trotzdem wieder was gelernt. TP arbeitet in diesem Fall tatsächlich korrekt: BDOS 50 HL :FCA4 BIOS 19 HL :FCA4
Hi, sind Platinen (für die Stamps als Basis und ggf. Backplane) schon in der Mache? Gruß Marcel
Leo’s 'Aufforderung' zur Fingerübung hatte meine Aktivitäten temporär in Richtung Software verlagert ;-) Anbei nun der derzeitige Stand der Backplane. 1. Fehler in der Stamp.Lib AVR-Stamp B22 und B26 vertauscht. Da beide NC waren, jedoch ohne Auswirkung. 2. JP6 hat nun noch RxD_AVR und TxD_AVR um den AVR – Monitor direkt auf die Frontplatte zu legen. Der Steckverbinder ist gleich neben der SD-Card. Wird diese Variante benutzt, ist jedoch der FT232 auf dem AVR-Stamp in den Reset zu schicken. 3. /SHDN vom MAX3241 liegt zusätzlich auf PB6 vom AVR-Stamp um die RS-232 / USB Umschaltung später per Software (DEVICE Befehl) ausführen zu können. Die Leiterplatte ist geroutet und bedarf nur noch einiger Korrekturen bezüglich der Leiterbahnbreiten und der Masseführung. Ich denke sie diese Woche fertig stellen zu können. Um das Fehlerrisiko zu minimieren, würde ich dann erst eine Testplatine fertigen lassen und bestücken, um bei Fehlerfreiheit die gewünschte Anzahl in Auftrag zu geben. Im nächsten Schritt erfolgt die abschließende Überarbeitung der beiden Stamp-Platinen.
Ähm - warum ist eigentlich die com3test.dsk 13,9MB groß, ich dachte, es werden nur bis 8MB Images unterstützt?
> Joe G. schrieb: > Hier mal ein Auszug aus der Doku zu den Environmentvariablen und zur > Befehlsabarbeitung (vollständig im SVN). Damit startet das CP/M direkt > auf der AVR-Console ohne externe RS-232 oder USB-Wandler. Sozusagen CP/M > für 'Arme' ;-) Ich versuche gerade noch herauszubekommen, was der Befehl loadf in der "Bootsequenz" macht. srec_cat image laden... ?
Ich war jetzt eine Woche beruflich in Dubai - vermutlich haben die 43°C mein Hirn verbrutzelt... Habe den Monitor auf 6.4 hochgerüstet. Nun erscheint am Ende eine Fehlermeldung:
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; loadf; go ${startaddr}"
|
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 Z180 memory... |
16 | From: 0x00000 to: 0x00003 ( 4 bytes) |
17 | From: 0x00008 to: 0x0000A ( 3 bytes) |
18 | From: 0x00010 to: 0x00012 ( 3 bytes) |
19 | From: 0x00018 to: 0x0001A ( 3 bytes) |
20 | From: 0x00020 to: 0x00022 ( 3 bytes) |
21 | From: 0x00028 to: 0x0002A ( 3 bytes) |
22 | From: 0x00030 to: 0x00032 ( 3 bytes) |
23 | From: 0x00038 to: 0x0003A ( 3 bytes) |
24 | From: 0x00040 to: 0x00043 ( 4 bytes) |
25 | From: 0x00050 to: 0x02BE4 (11157 bytes) |
26 | From: 0x02BF4 to: 0x02E64 ( 625 bytes) |
27 | From: 0x02EA7 to: 0x02EA8 ( 2 bytes) |
28 | From: 0x02EEB to: 0x02EEC ( 2 bytes) |
29 | From: 0x02F0F to: 0x02F10 ( 2 bytes) |
30 | Command failed, result=-1 |
31 | go - start application at address 'addr' |
32 | Usage: |
33 | go addr |
34 | - start application at address 'addr' |
35 | => |
Egal, CPM (mit dazugehörigem cpm3.sys) kann ich wie beschrieben laden und starten. Aber hier gibt er mir dann einen Fehler unter CPM aus:
1 | A>device |
2 | |
3 | Physical Devices: |
4 | I=Input,O=Output,S=Serial,X=Xon-Xoff |
5 | USB0 NONE IO ASCI0 19200 IOS ASCI1 19200 IOS |
6 | |
7 | |
8 | Current Assignments: |
9 | CONIN: = ASCI0 |
10 | CONOUT: = ASCI0 |
11 | AUXIN: = ASCI0 |
12 | AUXOUT: = ASCI0 |
13 | LST: = Null Device |
14 | |
15 | Enter new assignment or hit RETURN |
16 | |
17 | |
18 | A>device CON:=AVRCON |
19 | |
20 | CON:=AVRCON |
21 | ^ |
22 | Error at the '^'; Invalid physical device |
23 | |
24 | A> |
Scheint die AVRCON nicht zu kennen... Aber device CON:=USB0 geht - nach connect im Monitor. Das passt dann aber nicht zur Doku. Joe schrieb ja oben auch schon:
1 | CP/M 3 dürfte noch neben USB0 alias AVRCON... |
Danach habe ich die CPM-Console im AVR Monitor. Aber wie komme ich wieder in den Monitor (und zurück)? Die Crtl^ X usw. lösen nichts aus.
1 | Connecting to CPU. Escape character is '^^'. |
-> Was muss man denn da eingeben?
Marcel A. schrieb: > Ich versuche gerade noch herauszubekommen, was der Befehl loadf in der > "Bootsequenz" macht. srec_cat image laden... ? Wenn man "nur" CP/M booten will ist das nicht notwendig. Die "Bootsequenz" war ein Beispiel von Joe, um zu zeigen, daß man mehrere, durch Semikolon getrennte Befehle in eine Environment-Variable schreiben, und diese dann ausführen kann. 'loadf' lädt Daten aus dem AVR-Flash in das Z180-RAM. zur Zeit ist das die angepaßte Version von DDT/Z. Vielleicht fliegt der Befehl irgendwann raus, wenn das Flash knapp wird, oder es kommt etwas anderen rein. Den Debugger könnte man ja auch von einer SD-Karte laden, zB. mit 'loadihex'. Joe G. schrieb: > Leo’s 'Aufforderung' zur Fingerübung hatte meine Aktivitäten temporär in > Richtung Software verlagert ;-) Das war keine Aufforderung, sondern ein Hinweis für Leute die sich langweilen, und nicht so recht wissen, was sie mit ihrem CP/M eigentlich machen sollen. ;-)
:
Bearbeitet durch User
> ### main_loop: bootcmd="reset; loadf; go ${startaddr}" Die Variable heißt 'startaddress'. > CON:=AVRCON > ^ > Error at the '^'; Invalid physical device Das Device wurde umbenannt. Der Name AVRCON ist ja nicht so doll. Aus Sicht des Z180-BIOS ist das zwar nur eine Verbindung zum AVR-Controller, und der Z180 hat ja keine Kontrolle darüber, was der AVR damit macht. Aber viele andere Möglichkeiten als die USB-Schnittstelle gibt es ja nicht, und das ist ja auch das was der Benutzer sieht. > Connecting to CPU. Escape character is '^^'. > -> Was muss man denn da eingeben? Das erste '^' ist die (übliche) Abkürzung für Steuerzeichen, bzw. die Control-Taste. Das zweite '^' meint die Taste mit diesem Zeichen selbst. Also Control-Taste (Strg-Taste) gedrückt halten, und dann die Taste mit dem '^' drücken. Der Code der Taste ist 0x1E. Wenn Dir die Taste nicht gefällt, kannst du über die Environment-Variable 'esc_char' eine andere definieren. Hier muß der Hex-Code ohne führendes 0x eingegeben werden. Wenn der Hilfetext zu 'connect' unklar sein sollte, kann man mir gerne einen anderen schicken. Baue ich gerne ein. Das gilt natürlich auch für andere Verbesserungsvorschläge.
Soweit alles klar. CRTL halten, links oben ^ drücken und alles loslassen klappt nicht. Auch kein anderes Zeichen (Q, X, \) Wird einfach ignoriert.
Marcel A. schrieb: > Command failed, result=-1 > go - start application at address 'addr' > Usage: > go addr > - start application at address 'addr' Dein Fehler liegt (eigentlich kein wirklicher Fehler) in der Einvironmentvariable bootcmd="reset; loadf; go ${startaddr}" Die Variable 'startaddr' wird erst beim Aufruf von loadcpm3 erzeugt und belegt. In deinem Fall existiert sie also nicht und führt zum Fehler. Wenn du DDTZ nicht benötigst, lasse loadf weg und nehme den Befehl loadcpm3 mit rein.
Marcel A. schrieb: > CRTL halten, links oben ^ drücken und alles loslassen klappt nicht. Dann läßt dein Terminalprogramm diese Zeichen nicht durch, hatte ich auch. Du kannst jedoch über die Environmentvariable esc_car ein Zeichen angeben welches dein Terminal akzeptiert. Hier mal meine Konfiguration: printenv baudrate=115200 bootcmd=reset; loadc; go ${startaddress} bootdelay=3 cpm3_commonbase=F000 cpm3_file=0:/cpm3_v64.sys dsk0=0:/cpm3_a.dsk dsk1=0:/cpm3_b.dsk dsk2=0:/cpm3_c.dsk dsk3=0:/cpm3_f.dsk esc_char=0x40 pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10 :PE7 startaddress=d100 test_fat=fatstat 0:; fatls 0: test_sd=sd status 0; sd init 0; sd info 0
:
Bearbeitet durch User
Joe G. schrieb: > Marcel A. schrieb: >> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht. > > Dann läßt dein Terminalprogramm diese Zeichen nicht durch, hatte ich > auch. Du kannst jedoch über die Environmentvariable esc_car ein Zeichen > angeben welches dein Terminal akzeptiert. > > Hm, ich nutze genu wie Leo Minicom. Muss ich noch mal schauen
Marcel A. schrieb: > Hm, ich nutze genu wie Leo Minicom. Muss ich noch mal schauen Das 'Q' hast du aber nicht vergessen? => connect ? connect - Connect to CPU console i/o Usage: connect - type the escape character followed by Q to close the connection, or followed by ? to see other options. The default escape character is Ctrl-^ (0x1E). It can be changed by setting env var 'esc_char'. =>
:
Bearbeitet durch User
Marcel A. schrieb: > CRTL halten, links oben ^ drücken und alles loslassen klappt nicht. Nach dem Ctrl-^ sieht man noch nichts. Erst nach dem nächsten Zeichen, z.B '?'. > Auch kein anderes Zeichen (Q, X, \) Nach 'Q' oder 'X' müßte er wieder rausfliegen. Dann kommt das Ctrl-^ wie bei Joe wirklich nicht durch. Villeicht gibts ja Tastaturen, die das Zeichen nicht liefern? Unter Linux kannst Du die Tastatur mit 'showkey -a' testen, allerdings nicht unter X-Window sondern in einer Text-Console.
@ Joe G., welche Bauform hast Du für die Elkos C1, C2 vorgesehen? Mir kommt der Abstand sehr gering vor. Gruss Peter
Peter Zabel schrieb: > welche Bauform hast Du für die Elkos C1, C2 vorgesehen? Die Elkos haben die Bauform SMC-C / SMC-F oder EIA 6032-28 (20). C und F unterscheiden sich nur in der Höhe. Wer mehr die Bezeichnungen 0805, 1206 usw. gewöhnt ist, der darf auch 2312 zur Bauform der verwendeten ELkos sagen. Konkret heißt das 6,0mm x 3,2mm x 2,8mm (L x B x H). Ich kann sie auf dem board jedoch noch etwas auseiander rücken, Platz genug ist ja.
Leo C. schrieb: > Marcel A. schrieb: >> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht. > > Nach dem Ctrl-^ sieht man noch nichts. Erst nach dem nächsten Zeichen, > z.B '?'. > >> Auch kein anderes Zeichen (Q, X, \) > > Nach 'Q' oder 'X' müßte er wieder rausfliegen. Dann kommt das Ctrl-^ wie > bei Joe wirklich nicht durch. Villeicht gibts ja Tastaturen, die das > Zeichen nicht liefern? Unter Linux kannst Du die Tastatur mit 'showkey > -a' testen, allerdings nicht unter X-Window sondern in einer > Text-Console. In der X-Console kommt "nichts" durch. In der Text-Console kommt "^^ 30 0636 0x1e" Scheint also ein Problem meiner X-Umgebung zu sein. Werde es mal mit einem anderen ESC-Char probieren.
PANIK! Mit dem Setzen des esc_char komme ich nun aus dem Connect auch wieder raus. Aber ich kann plötzlich CPM nicht mehr starten. Ich habe mal das bootcmd gelöscht:
1 | => printenv |
2 | baudrate=115200 |
3 | bootdelay=3 |
4 | cpm3_commonbase=F000 |
5 | cpm3_file=0:/cpm3.sys |
6 | dsk0=0:/cpm3test.dsk |
7 | dsk1=0:/tp3-hd.dsk |
8 | dsk2=0:/editor.dsk |
9 | dsk3=0:/kermit.dsk |
10 | esc_char=0x1c |
11 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
12 | startaddress=d100 |
Gehe ich nun ein
- reset
- loadcpm3
- go d100
kommen auf der ASCI0-Schnittstelle nur Müllzeichen an, egal welcher
Baudrate (war bisher 19200).
Hab ich was kaputt gemacht?
Zum Thema DDTZ: Wie starte ich die?
Soweit ich verstanden hatte:
- loadf
- go ${startaddress}
- connect
Aber da passiert gar nix...
> Hab ich was kaputt gemacht? Eher nicht. (obwohl man ja nie etwas ausschließen soll:) Welchen Takt verwendest Du denn? Die Taktfrequenzerkennung funktioniert (noch) nicht immer zuverlässig. Außerdem haben wir letzte Woche festgestellt, das der bisher eingestellte Oszillator ("Low Power Crystal Oscillator") nicht optimal ist. Das hat sicher auch mit der Übertaktung zu tun. Besser ist der "Full Swing Crystal Oscillator". Du könntest das mal ausprobieren, in dem Du die Low-Fuse auf 0x97 stellst. > Zum Thema DDTZ: Wie starte ich die? Du bist der Erste, der fragt. ;) > Soweit ich verstanden hatte: > - loadf > - go ${startaddress} go 0 > - connect Nein, ddt/z meldet sich an ASCI1. Baudrate ist fest auf 112500 bei 18,432MHz Takt (oder 57600 bei 9,216Mhz). Allerdings kann man die Schnittstelle vor dem Starten über das I/O-Byte auf Adresse 3 ändern. 0 ist die AVR-Console, 1 die erste und 2 die zweite serielle Schnittstelle.
Bin gerade unterwegs, verwende aber die 18Mhz auf den Z180 Board... Die ASCII Schnittstelke sollte ja daher nicht von Avr abhängig sein. Der Monitor geht und ist genial. Bisher hatte ich noch nie Probleme. Schaun wir mal.
Ging wieder, als ich zurück kam. Steine vom Herzen fall.... War vielleicht ein Wackler am Jumper vom Z180-Quarz. Weiter gehts :-)
:
Bearbeitet durch User
>> Zum Thema DDTZ: Wie starte ich die? > > Du bist der Erste, der fragt. ;) > >> Soweit ich verstanden hatte: >> - loadf >> - go ${startaddress} > > go 0 > >> - connect > > Nein, ddt/z meldet sich an ASCI1. Baudrate ist fest auf 112500 bei > 18,432MHz Takt (oder 57600 bei 9,216Mhz). > Allerdings kann man die Schnittstelle vor dem Starten über das I/O-Byte > auf Adresse 3 ändern. 0 ist die AVR-Console, 1 die erste und 2 die > zweite serielle Schnittstelle. Nicht ganz. Wenn ich mw 3 1 eingebe, ziehe ich mir die DDTZ-Console auf ASCI0. Dort kommt sie mit 19200 raus genau wie die CPM-Console (bei 18MHz). Mit mw 3 0 kommt sie auf der AVR-Console an. Sonst klappt aber alles prima!
Leo C. schrieb: . Den > Debugger könnte man ja auch von einer SD-Karte laden, zB. mit > 'loadihex'. Den Befehl finde ich nicht... Nur loadf (lädt fest DDTZ), loadi (über serielle Schnittstelle) und loadc (läd CPM).
> Nicht ganz. Wenn ich mw 3 1 eingebe, ziehe ich mir die DDTZ-Console auf > ASCI0. Dort kommt sie mit 19200 raus genau wie die CPM-Console (bei > 18MHz). > Mit mw 3 0 kommt sie auf der AVR-Console an. Ich dachte genau das geschrieben zu haben. >> 'loadihex'. > > Den Befehl finde ich nicht... > Nur loadf (lädt fest DDTZ), loadi (über serielle Schnittstelle) und loadi war gemeint. Ich verliere wohl langsam den Überblick.
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...
:
Bearbeitet durch User
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"
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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>
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
> - 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
@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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Hier mal ein paar Bilder meines Aufbaus mit meinen beschränkten mechanischen Möglichkeiten. Es fehlen noch ein paar Verdrahtungen, die Backplane ist auch noch nicht drin. Links kommt dann demnächst noch die VGA-Platine rein. Etwas Sorgen bereitet mir der USB-Abschluss auf der AVR-Platine. Ich suche immer noch ein passendes Kabel mit Winkel-Stecker (oder einen Winkel-Adapter), da man das Board mit Stecker dran nicht in den Rahmen schieben kann.
> Etwas Sorgen bereitet mir der USB-Abschluss auf der AVR-Platine. Ich > suche immer noch ein passendes Kabel mit Winkel-Stecker (oder einen > Winkel-Adapter), da man das Board mit Stecker dran nicht in den Rahmen > schieben kann. Die Winkeladapter, die ich bisher gefunden habe, waren alle zu groß und in eine falsche Richtung abgewinkelt. Jetzt habe ich diese [1] Adapter gekauft und will einen davon hinter die Frontplatte montieren. Auf der AVR-Stamp wird dann ein Kabel direkt angelötet. [1] http://www.ebay.de/itm/201414916073
Marcel A. schrieb: > Etwas Sorgen bereitet mir der USB-Abschluss auf der AVR-Platine. Ich > suche immer noch ein passendes Kabel mit Winkel-Stecker (oder einen > Winkel-Adapter), da man das Board mit Stecker dran nicht in den Rahmen > schieben kann. Das Teil von Delock/Reichelt ist wahrscheinlich zu dick, oder?!: http://www.reichelt.de/USB-Adapter/DELOCK-65096/3/index.html?ARTICLE=100945
Dirk schrieb: > Das Teil von Delock/Reichelt ist wahrscheinlich zu dick, oder?!: > http://www.reichelt.de/USB-Adapter/DELOCK-65096/3/index.html?ARTICLE=100945 Da habe ich inzwischen auch Kabel mit Winkelstecker gesehen. Aber wahrscheinlich bleibt nur Leos Weg mit direkt drauf löten...
Angehängte Dateien:
-
P1011383.JPG
240 KB
Läuft soweit alles prima, auch die seriellen Schnittstellen, die externe SD usw. Jetzt kämpfe ich "nur" noch mit meinem alten Problem. Ich habe ja auch ein "echtes" VT100 an CON angeschlossen - das super geht, aber sowohl im AVR-Modus als auch unter CP/M reproduzierbar "Müllphasen" hat, die den Bildschirmaufbau durcheinander bringen. Interessanterweise geht an der AVR Console der USB- und Seriell-Anschluss gleichzeitig, senden wie empfangen. So ist das Bild im Anhang entstanden. Auf dem FTDI kommt alles sauber an, am VT100 (MAXxxx) tritt der Fehler auf. Den Max-Baustein hatte ich schon mal geprüft, der schein ansonsten ok zu sein. Die Fehler tauchen auch auf, wenn ich den USB-Anschluss still lege (JP auf AVR Stamp) und nur zur Stromversorgung nehme. Das einzige, was ich noch nicht probiert hatte, ist reine 5V Versorgung von extern (also nix mehr im USB-Port). Hat noch jemand eine Idee?
Marcel A. schrieb: > Hat noch jemand eine Idee? Lasse doch mal parallel zum VT100 einen "Serial Port Analyser" [1] mitlaufen. Dann siehst du ja was gesendet wird und was das Terminal damit macht. [1] http://www.serial-port-monitor.com/
Habe mal eine "echte" serielle Schnittstelle des PCs angeschlossen - damit ist das Problem auch nicht vorhanden. Muss wohl dann ein Problem des HP VT100-Terminals sein - auch eine Verringerung der Geschwindigkeit bringt keine Abhilfe. Immer an der gleichen Stelle (bzw. bei bestimmten Codes) kommt es zu "Müll". Als wenn da ein Puffer nicht richtig arbeitet... EDIT: Ich glaube, ich habe in den 1Mio Einstellungen gerade eine Kombi gefunden, die geht :-)
:
Bearbeitet durch User
Marcel A. schrieb: > Immer an der > gleichen Stelle (bzw. bei bestimmten Codes) kommt es zu "Müll". Das sieht doch nach Handshake aus. Was macht die CTS-Leitung vom Terminal? Möglicherweise signalisiert sie Puffer voll, warten. Wenn dann der Sender munter weiter Zeichen sendet kommt es natürlich zu Fehlern.
So, habe mein erstes richtiges Z80 HelloWorld sowohl auf der Stamp als auch in der ZXCC-Umgebung ans Laufen gebracht :-) Dann habe ich mal mein altes Pollin AVR NetIO Board ausgekramt und eine Firmware von Ulrich Radig drauf gebracht. Nachdem ich die Original-CPU (Mega32) durch eine 644er getauscht hatte und damit den USART-Buffer hochschrauben konnte, dient dieser als Seriell zu Telnet Konverter an der AVR CON. Somit könnte ich den Rechner von meinem Arbeits-PC aus bedienen. Leider ist die Firmware noch etwas eigenwillig hinsichtlich der Übertragung von CTRL-Codes und ESC-Sequenzen. Auch ist es gar nicht so einfach, nur auf 1 Taste zu reagieren (Menüs...) anstatt alles mit CR zu bestätigen. Das wird sicher wieder eine weitere Baustelle - irgendwann.
Angehängte Dateien:
-
P1011423.JPG
250 KB
So, hier mal der aktuelle HW-Stand meiner "Grafikkarte". Die "Firmware 1.7.3 test serial 3" macht aber noch Probleme (CRTL wie SHIFT, Absturz beim Start von TP).
Die RTC schein noch einen Bug zu haben, könnt ihr den Fehler auch nachstellen? im AVR-Monitor => date Sat Jan 23 14:39:38 2015 im CP/M A>date Fri 01/23/2015 14:38:53 Den Jahreswechsel von 2015 auf 2016 scheint die RTC vergessen zu haben. Nachtrag: Nach dem Stellen der RTC ist wieder alles korrekt... A>date Sat 01/23/2016 14:53:29 => date Sat Jan 23 14:53:32 2016
:
Bearbeitet durch User
Marcel A. schrieb: > Gibt's eigentlich was neues vom Vinculum? Nein, noch nicht. Ich habe gerade die reine 5V Version auf dem Tisch.
Joe G. schrieb: > Die RTC schein noch einen Bug zu haben, könnt ihr den Fehler auch > nachstellen? Ja, leider. Ich habe es nicht bemerkt, weil mein Stamp dieses Jahr noch garnicht in Betrieb war. Die RTC hat nur einen 2-Bit Jahreszähler. Deshalb wird das aktuelle Jahr im RTC-RAM gespeichert, aber beim Jahreswechsel (noch) nicht aktualisiert. Außerdem wird wg. eines dämlichen Fehlers das Jahr auch im AVR-RAM nicht aktualisiert, wenn der 2-Bit Zähler von 3 nach 0 überläuft, was dieses mal der Fall war. > Nach dem Stellen der RTC ist wieder alles korrekt... Aber nur für die nächsten 3 Jahre, wenn der Strom nicht abgeschaltet wird.
Merkwürdiges RAM Fehlerbild auf dem Z180-Stamp Leitungen (Adressen, Daten, Steuerleitungen )scheinen alle korrekt, kein Schluss, keine offene Leitung ... Z180 ist im RESET, alle sind Leitungen hochohmig. Wird nun der RAM nur auf EINER Zelle beschrieben (egal welcher), so ist beim Auslesen dieser Inhalt auf ALLEN Zellen. Das ist unabhängig davon auf welcher Adresse geschrieben oder gelesen wird. Die Adressen beim Lesen und Schreiben liegen korrekt an, auch CE, OE und WE. Ich bin etwas ratlos und tippe auf RAM defekt. Hatte schon mal jemand so ein Verhalten? Ach ja, das ist ein zweiter Neuaufbau, der RAM ist also frisch aus der Verpackung. Nachtrag: Ich kann mir eigentlich nur vorstellen, dass der interne Adressdecoder des IC nicht korrekt arbeitet.
:
Bearbeitet durch User
Hallo, ich wollte mich mal wieder melden. Ich war etwas abgetaucht in den Tiefen des NDR Klein Computers... Habe dort das BIOS umgeschrieben für ein drittes "GOTEK USB Floppy-Laufwerk" und dabei glatt nach 30 Jahren einen Fehler im FLOMON (den Basisroutinen des NKC) gefunden :-) Dann habe ich es noch geschafft, auch dort ein Terminal an die serielle Schnittstelle zu bekommen - gar nicht so leicht, denn das IOBYTE ist nicht implementiert. Nun wollte ich mir als nächstes die AVR STAMP in der Version 1.1 aufbauen, damit ich alles mit 5V betreiben kann. Da waren doch keine "Bugs" mehr drin, oder? Habe auf die Schnelle keine Hinweise gefunden. Bin auch mal gespannt, wie es mit dem USB Stick weitergeht. Die KC-Leute und die NDRler haben das ja auch umgesetzt mit den "U-Tools", also Programmen im TPA aus. NeuLinux: "user space" :-) Und ja, das Frontpanel reift noch in meinem Kopf. Habe inzwischen auch einen MFA/BZA-Rechner im Keller mit einer ganzen Kiste voll Karten und dann noch von einem anderen ehemaligen Z80-Entwickler (der es im Gegensatz zu Leo leider aufgegeben hat) einen TRS-80 Nachbau im 19" Rahmen mit einem Wäschekorb voll Literatur. Das wird für ein paar Jahre reichen. Joe - ich muss gerade an deinen Hinweis " nicht zu viele Baustellen..." denken. Gruß in die Runde Marcel
Marcel A. schrieb: > Nun wollte ich mir als nächstes die AVR STAMP in der Version 1.1 > aufbauen, damit ich alles mit 5V betreiben kann. Da waren doch keine > "Bugs" mehr drin, oder? Habe auf die Schnelle keine Hinweise gefunden. Der AVR-Stamp ist ohne Hardwarefehler. Die LP kann so bestückt werden und funktioniert mit 3.3V und 5V. Beim Z180 Stamp (V1.1) habe ich diesen merkwürdigen RAM-Fehler. Nachdem RAM Wechsel ist der Fehler immer noch da, es scheint also nicht der RAM zu sein. Bisher bin ich jedoch mangels Zeit noch nicht fündig geworden. Bis nächste Woche Mittwoch läuft nach das Ballonprojekt [1] mit Hochdruck. [1] Beitrag "Stratosphärenballon"
Joe G. schrieb: > [1] Beitrag "Stratosphärenballon" Hallo Joe - tolle Sache. Ich hatte in unserem OV auch mal eine Technik-Gruppe als Kontrastprogramm zum sonstigen Gelaber gegründet - aber es kamen immer nur dir gleichen 2-3 Leute und für Jugendarbeit konnte ich keinen begeistern - maximal "müsste man mal machen" - meistens aber "oh Gott, stell dir mal vor, da kommen tatsächlich junge Leute". Es war frustrierend. So, das war etwas OT, zurück zum Z180 :-)
Ich baue gerade die AVR Stamp 1.1 zusammen. Dabei sind mir bisher folgende Unterschiede zwischen Schaltplan und BOM, beides V1.1. Z.b. Sind R6-8 anders und IC2 und IC5 sind vertauscht....? Oder habe ich mir vor einigen Wochen eine falsche Version ausgedruckt?
Die habe ich auch - im Schaltplan ist aber z.B. IC5 der 125er Levelshifter und nicht der PCF...
Ich habe da noch 2 Fragen. Aufgrund der besseren Verfügbarkeit habe ich wie empfohlen den ATMEGA2561V eingebaut. Wenn ich die Datenblätter so vergleiche, müssten eigentlich die gleichen FUSE-Bits gelten, oder? Dabei ist mir aber in der Dokumentation aufgefallen, dass dort steht, dass BOOTSZ1, BOOTSZ2 und BOOTRST auf 1 stehen sollen, in der Tabelle der Doku stehen aber "Defaults", die nicht diese Werte haben - das könnte verwirrend sein. Und noch ein Tipp, da ich dafür genau in den Layout-Plan schauen musste: Für JP4 (ISP) bitte im Bestückungsplan einen richtigen Wannenstecker nehmen, damit man den auch anstelle der Stiftleiste nimmt und dann auch gleich "richtig herum" einbauen kann - das kann sonst böse Folgen haben, wenn man das ISP-Kabel falsch herum ansteckt :-) Gruß Marcel
Marcel A. schrieb: > vergleiche, müssten eigentlich die gleichen FUSE-Bits gelten, oder? Sieht so aus. > in der Tabelle > der Doku stehen aber "Defaults", die nicht diese Werte haben - das > könnte verwirrend sein. Ja, in der Tabelle stehen nur die Defaults. Darunter steht in Hex der "richtige" Wert (0xD6). Den Bootloader wirst Du auf jeden Fall anpassen und neu übersetzen müssen. Der Monitor könnte vielleicht unverändert laufen.
Ja, da werde ich mich wohl noch mal reinfuchsen :-) Wo finde ich denn den Source für den "STAMP Monitor V6.5 8 Drives"? Du hattest mir dazu mal eine HEX-Datei gegeben - die SEHR GUT läuft. Die "normale" V6.5 habe ich gefunden.
:
Bearbeitet durch User
> Wo finde ich denn den Source für den "STAMP Monitor V6.5 8 Drives"? Du Nirgens. > hattest mir dazu mal eine HEX-Datei gegeben - die SEHR GUT läuft. > Die "normale" V6.5 habe ich gefunden. Es sollte ausreichen, in der datei z180-serv.c das Makro MAX_DRIVE anzupassen.
Ich bin schon recht weit, aber es klemmt noch. Ich habe den bootloader von hier https://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain" genommen (für die AVR-GCC toolchain), die scripte wie dort beschrieben ausgetauscht und das makefile auf den 2561 angepasst. Es entstand das HEX. Das habe ich geflashed (ACHTUNG: Beim 2561 meckert AVRDUDE über EFUSE=F5 - er setzt das auf FD - das bezieht sich aber nur auf die Brown-Out detection). Danach minicom und fboot gestartet - das Stamp-Monitor-Hex wird geladen!!! Nur startet er danach den Monitor nicht. Obwohl der fastboot ja eigentlich nur 0,3 Sekunden auf mein fboot warten sollte kann ich zu jedem beliebigen Zeitpunkt fboot starten und eine hex-datei übertragen. Das ist doch nicht normal? Oder muss ich den Stamp Monitor doch für den 2561 übersetzen? Aber irgendwie kommt mir der bootloader komisch vor. Ein Flash-Dump zeigt mir aber, dass er etwas übertragen hat. Er scheint es nur nicht zu starten. Leo, du hattest da doch auch "rumgefummelt" - hast du eine Idee? Gruß Marcel
1 | >>> dump flash 0 2000 |
2 | 0000 0c 94 81 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
3 | 0010 0c 94 b3 30 0c 94 b3 30 0c 94 d1 30 0c 94 dc 30 | ..0 ..0 ..0 ..0| |
4 | 0020 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
5 | 0030 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
6 | 0040 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
7 | 0050 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
8 | 0060 0c 94 b3 30 0c 94 d4 63 0c 94 fe 63 0c 94 b3 30 | ..0 ..c ..c ..0| |
9 | 0070 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
10 | 0080 0c 94 32 63 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | .2c ..0 ..0 ..0| |
11 | 0090 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 c0 64 | ..0 ..0 ..0 ..d| |
12 | 00a0 0c 94 b3 30 0c 94 b3 30 0c 94 ce 71 0c 94 b3 30 | ..0 ..0 ..q ..0| |
13 | 00b0 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| |
14 | 00c0 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 31 46 43 46 | ..0 ..0 ..01FCF| |
15 | 00d0 3b 46 91 46 99 46 99 46 ac 46 ac 46 08 08 08 25 |;F.F.F.F.F.F...%| |
16 | 00e0 32 64 20 00 48 69 74 20 61 6e 79 20 6b 65 79 20 |2d .Hit any key | |
17 | 00f0 74 6f 20 73 74 6f 70 20 61 75 74 6f 62 6f 6f 74 |to stop autoboot| |
18 | 0100 3a 20 25 32 64 20 00 23 23 23 20 6d 61 69 6e 5f |: %2d .### main_| |
19 | 0110 6c 6f 6f 70 3a 20 62 6f 6f 74 63 6d 64 3d 22 25 |loop: bootcmd="%| |
20 | 0120 73 22 0a 00 3c 55 4e 44 45 46 49 4e 45 44 3e 00 |s" .<UNDEFINED>.| |
21 | 0130 62 6f 6f 74 63 6d 64 00 23 23 23 20 6d 61 69 6e |bootcmd.### main| |
22 | 0140 5f 6c 6f 6f 70 20 65 6e 74 65 72 65 64 3a 20 62 |_loop entered: b| |
23 | 0150 6f 6f 74 64 65 6c 61 79 3d 25 64 0a 0a 00 62 6f |ootdelay=%d .bo| |
24 | 0160 6f 74 64 65 6c 61 79 00 2e 0a 00 2c 20 00 23 23 |otdelay.. ., .##| |
25 | 0170 23 20 52 65 73 65 74 20 72 65 61 73 6f 6e 28 73 |# Reset reason(s| |
So sieht der Bootloader-Vorgang aus - aber die Applikatio wird eben nicht gestartet - er bleibt in der Suche nach dem Host-Programm stecken
1 | ================================================= |
2 | | BOOTLOADER, Target: V2.1 | |
3 | | (May 13 2015 20:15:36) | |
4 | ================================================= |
5 | Now program device. |
6 | Port : /dev/ttyUSB0 |
7 | Baudrate : 115200 |
8 | File : stamp-monitor-6.5+8drives.hex |
9 | Reading : stamp-monitor-6.5+8drives.hex... File read. |
10 | Size : 81994 Bytes |
11 | ------------------------------------------------- |
12 | Waiting for device... connected! |
13 | Bootloader : V2.1 |
14 | Target : 1E9802 ATmega2561 |
15 | Buffer : 7680 Byte |
16 | Size available: 261120 Byte |
17 | CRC enabled and OK. |
18 | Programming : 0x00000 - 0x14049 |
19 | Writing [############################################################################################################################] 100% |
20 | Elapsed time : 23.83 seconds, 3441 Bytes/sec. |
21 | |
22 | ++++++++++ Device successfully programmed! ++++++++++ |
23 | |
24 | ...starting application |
:
Bearbeitet durch User
> (ACHTUNG: Beim 2561 meckert > AVRDUDE über EFUSE=F5 - er setzt das auf FD - das bezieht sich aber nur > auf die Brown-Out detection). Macht nichts, bzw. FD ist eigentlich "richtiger". > Obwohl der fastboot ja eigentlich nur 0,3 Sekunden auf mein fboot warten > sollte kann ich zu jedem beliebigen Zeitpunkt fboot starten und eine > hex-datei übertragen. Das ist doch nicht normal? Das muß nicht am Bootloader liegen. Auch wenn der Hexdump nicht so aussieht, kann es sein daß das geladene Programm nicht richtig läuft, sondern immer in den Bootloader springt. > Oder muss ich den Stamp Monitor doch für den 2561 übersetzen? Vielleicht. Ich probier's mal aus. Versuch doch mal, den Monitor direkt zu flashen, ohne Bootloader. > Leo, du hattest da doch auch "rumgefummelt" - hast du eine Idee? Wo habe ich rumrefummelt?
Zum 2561: Ich habe mir tup manuell installiert - aber ich habe noch nicht raus, wie ich nur den avr-zweig übersetzen kann. Zum "rumfummeln": Es gab doch mal hier massive Probleme, dass der bootloader das fboot nicht zuverlässig erkannt hat. Da hast du damals glaube ich etwas angepasst. Ich meine auch etwas mit speziellem Bootloader-Support Beitrag "Re: Z180-Stamp Modul" Hab gerade mal das HEX direkt geflashed: Dann passiert nicht - also wird es wohl daran liegen, dass ich erst ein HEX für den 2561 erzeugen muss.
:
Bearbeitet durch User
Marcel A. schrieb: > Für JP4 (ISP) bitte im Bestückungsplan einen richtigen Wannenstecker > nehmen, damit man den auch anstelle der Stiftleiste nimmt und dann auch > gleich "richtig herum" einbauen kann Passt der vom Layout? Ich hatte das nicht überprüft, weil im Normalfall der AVR ja nur einmal mit dem Bootloader geflasht wird. Ich dachte mir, dass der Nachnutzer in diesem Fall genau weiß, was er tut ;-)
Angehängte Dateien:
-
P1011458.JPG
230 KB
Ja, der passt :-). Und da weit vom SD-Card-Reader entfernt auch super. Da ich mit Leo's Hilfe den ATmega2561 gerade zum Laufen gebracht habe, brauchte ich den mehr als gedacht. Anbei ein Bild.
Hallo! Ich bin gerade wieder am Teile zusammensuchen und bin auf den Ferrit auf der ECB gestoßen. Ich konnte den exakten Typ bei meinen üblichen Verdächtigen nicht finden. Sodann: kann ich diese Induktivität verwenden? http://www.reichelt.at/L-1210F-22-/3/index.html?&ACTION=3&LA=446&ARTICLE=138576&artnr=L-1210F+22%C2%B5&SEARCH=22+ferrit+1210
:
Bearbeitet durch User
Ja, kannst du verwenden. Sollte sogar vom Footprint fast passen.
Die 20µH Spule ist schon etwas breit für das 1206 Footprint. Aber da drumherum Platz ist wird es wohl gehen. Die 1206 Spulen vom Reichelt haben entweder zu wenig Induktivität oder zu viel Widerstand. Ich habe noch einen Vorrat von [1]. Bei CSD gekauft, aber da gibts kein Datenblatt. Die 10µH reichen bei mir aus. [1] http://www.tme.eu/de/details/nl322522t-100k/smd-drosseln/yageo/
Ok... geteilte Meinungen. Muss aber sowieso was bei CSD bestellen. Du hast die gezeigte auf dem Board in Verwendung? Dachte 1210 wegen der Teilebezeichnung in der BOM.
Ich habe eine mit 18µH, 1.1 Ohm, Bauform 1210 in Verwendung [1]. Das Footprint ist für 1210 ausgelegt. Leo's Modell geht aber auch. [1] Würth 744032180
Angehängte Dateien:
-
NL322522T-100K.jpg
42 KB
So geteilt finde ich die Meinungen garnicht. Keine Ahnung wie ich auf 1206 gekommen bin. Meine Spule ist 2,5 mm breit, die vom Reichelt 3,0 mm (Dachte es wäre noch mehr). Die Reichelt-Spule hat auf jeden Fall die besseren Werte.
Hallo nochmal! Noch eine Frage habe ich. Ich kann die 74LV138D und 74LV10D nicht finden. Kann ich stattdessen die HC-Typen hernehmen? Weiters finde ich den MAX3241 nicht. Hat vlt jemand 2 Stück über, die er mir verkaufen könnte? Danke
> Noch eine Frage habe ich. Ich kann die 74LV138D und 74LV10D nicht > finden. Kann ich stattdessen die HC-Typen hernehmen? Prinzipiell ja. Aber LV, LVX, HVC, etc. sind wesentlich schneller als die alten HC. Das könnte beim '10 evtl. eine Rolle spielen, vor allem bei 3,3V und 18,432MHz Taktfrequenz. Sollte man mal durchrechnen.
Also für den 138er hätte ich nun den 74LVC138AD gefunden. Für den 10er leider nur 74HC10D oder 74HCT10D. Den Max gibts tatsächlich auf Ebay als MAX3241CAI. Dann werd ich das mal so probieren und zur Not die ICs von den alten Stamps auslöten versuchen...
> Dann werd ich das mal so probieren und zur Not die ICs von den alten > Stamps auslöten versuchen... Bevor Du das machst, löte besser den 74HC10D ein. Wenn der für die höchste Taktfrequenz wirklich zu langsam sein sollte, kannst Du ihn immer noch auslöten. Der HCT geht auf keinen Fall.
Jetzt habe ich gestern die Nachricht geschrieben und dann offenbar gar nicht abgeschickt... MIST. Also, ich habe ein dickes Problem mit der AVR STAMP 1.1 Nur AVR-Betrieb (keine ECB): Ich habe sie auf USB-Power und 5V eingestellt. Dann erscheint bei B1 (sollte 3,3V sein) immer 4,3V (komischerweise genau 0,7V "Diodenspannung" weniger). Ob das über den MISO-Ausgang und die LED am SD-Reader kommt? Betreibe ich die AVR Stamp auf der ECB und stecke auch die Z180 (dort wird ja eigentlich die 3,3V produziert, ändert sich daran auch nichts - am Spannungsregler liegen dann auch 4,3V an! Die Z180 CPU habe ich erst mal gar nicht mit Strom versorgt. Der Zugriff auf SD (beide!) klappt aber - trotz der hohen Spannung. Aber das kann doch nicht gut sein? Nur wenn ich die AVR (und die ECB) auf 3,3V jumpere ist alles ok von den Spannungspegeln her. Irgendwie muss da der Wurm drin sein. Ich habe alles gefühlt 100x überprüft. Habt ihr eine Idee? Gruß Marcel
Die 3.3V kommen doch vom Z180-Stamp. Der AVR-Stamp hat nichts mit den 3.3V zu tun. Wenn du die +5V über USB beziehst, dann werden sie über JP1 an B2 gelegt. Von B2 holt sich dann der Z180-Stamp die +5V, macht 3.3V daraus und legt sie wieder an B1 an. Ob der AVR-Stamp nun mit 5V oder 3.3V versorgt werden soll, legt JP2 auf dem AVR-Stamp fest. Wenn du also nur den AVR in Betrieb hast, dann sollte an B1 nichts anliegen. Nachtrag: Ich habe nochmal in die Schaltung geschaut. Wenn du keine 3.3V für die SD-Card bereit stellst, dann wird der 74HC125 nicht mit Spannung versorgt. Es wird also ein Strom über die Gattereingänge auf die 3.3V Leitung fließen. Das ist nicht gut :-( Auch beim 5V Betrieb sollten also auf jeden Fall an B1 3.3V extern anliegen!
:
Bearbeitet durch User
Genau so waren auch meine Überlegungen. Der AVR-Stamp holt sich (solange die ECB nicht wieder im Rahmen steckt) die 5V vom USB. Diese 5V gehen auch auf B2 und versorgen auch den AVR mit Strom Die 3,3V für die SD-Karte wird vom Z180-Stamp aus den 5V auf B2 geholt und in eben 3,3V umgewandelt und auf B1 gelegt. Der Z180 selber wird wieder mit 5V versorgt. Mich wundert nur, dass der Z180-3,3V-Regler die Spannung auf B1 nicht "runterregelt". Offenbar übersteuert da irgendwas die 3,3V - sehr komisch. Ich raff das nicht...
Angehängte Dateien:
-
Vcc_Problem.jpg
81 KB
Wie gesagt, mit 3,3V klappt alles wunderbar, soweit ich das bisher sehen kann. Ich habe den Jumper für die CPU Spannungsversorgung auf der Z180 derzeit nicht gesetzt (nutze also nur die 3,3V Versorgung der Z180 Stamp). Als ob sich die 3,3V dann doch von "Vcc" geholt werden und nicht von B1? In einer älteren Version des Schaltplans gab es da mal eine Änderung, siehe Anhang... In der "alten" Version waren auch die Widerstände anders nummeriert... (Ein anderer Effekt: Früher konnte ich immer einen MAX... RS232-Wandler auf den RX/TX des AVR parallel zum FTDI mitlaufen lassen - jetzt geht das nur noch in Richtung Terminal, aber nicht mehr in Richtung AVR. Auch nicht MEHR mit dem alten AVR 1.0, wo es immer ging. Komisch. Na, hab das auf jeden Fall mal abgeklemmt.)
:
Bearbeitet durch User
Marcel A. schrieb: > In einer älteren Version des Schaltplans gab es da mal eine Änderung, > siehe Anhang... In der "alten" Version waren auch die Widerstände anders > nummeriert... Die ältere Version wurde nur mit 3.3V betrieben. Dort lagen alle Pullup/down Widerstände natürlich auf Vcc. Data0/MISO ist ein Ausgang der SD-Card. Die Spezifikation der SD-Card [1] sagt dazu: „external pull-up resistor value to prevent bus floating“. Da die maximale Spannung einer SD-Card nur 3.6V betragen darf, liegt der Widerstand R5 (100k) also auf 3.3V. Der AVR erkennt jedoch noch sicher den Pegel. > Als ob sich die 3,3V dann doch von "Vcc" geholt werden und nicht von B1? Wenn ein Fehler auf der AVR-Platine vorliegt und somit eine Spannung größer 3.3V an B1 anliegt, dann kann der Regler natürlich nicht regeln. Er hat ja dann am Ausgang schon eine höhere Spannung. Es muss also erst der Fehler auf dem AVR-Stamp beseitigt werden. Die einzige Verbindung die ich sehe, sind der 74HC125 und die SD-Card. Da DAT0 ein Ausgang ist, kann ich mir das nicht vorstellen. Das kannst du jedoch testen, indem du die SD-Card entfernst. Somit bleibt nur noch der Pegelwandler. Das kannst du testen indem du entweder die LED oder R2 entfernst. Wenn jetzt noch Spannung auf der 3.3V Leitung liegt, muss der Pegelwandler defekt sein. [1] http://www.nxp.com/documents/application_note/AN10911.pdf
:
Bearbeitet durch User
Ich habe beide Boards noch mal auf meiner Lochraster-Basisplatine getestet - gleicher Effekt - dann kann ich das ECB Board ausschließen. SD-Karten sind (sicherheitshalber) im Moment eh nicht gesteckt - daher dürfte da auch nichts in Richtung MISO gehen. Dann habe ich R2 und R5 auf dem AVR Board ausgelötet - dann ist "nur" noch der 125er mit B1 verbunden. Kein Unterschied. Dann habe ich noch mal den 3,3V Regler im Leerlauf arbeiten lassen - 3.3V - passt. Dann habe ich ihn wieder an B1 angeschlossen (auf der Z180 Stamp): 4,3V. Dann habe ich ihn mal mit 220Ohm "belastet" -> B1=3,6V Dann mit 100Ohm (immer zwischen B1 und GND)-> B1=3,1V Hä??? :-) Muss ich also wirklich den 125er auslöten...:-( Komisch.
Marcel A. schrieb: > Muss ich also wirklich den 125er auslöten...:-( Komisch. Schau dir mal an welche Leitung den Strom liefert. Es kommen ja nur SS, SCK ode MOSI in Frage. An welcher Leituung geht der Pegel runter, wenn du die 3.3V belastest?
Angehängte Dateien:
-
P1011466.JPG
170 KB
SS geht auf 4,3/3,6/3,1V SCK und MOSI haben immer 0V Wie gesagt, R2 und R5 sind ausgelötet im Moment. Und die LED hatte geblinkt beim Zugriff auf die SD-Karte.
:
Bearbeitet durch User
Dumme Sache :-( Ich habe es gerade auf deinem Foto gesehen. Du hast einen 74Hc125 eingelötet und ich habe auch die ganze Zeit davon geschrieben. Der 74HC... ist nicht 5V tolerant! Bei diesem Type darf der Eingang nicht größer als Vcc+0.5V sein. Es muss ein 74LVC... oder 74AHC... sein. Das IC muss also tatsächlich runter. Ich ändere das auch gleich im Schaltplan, das steht auch der falsche Type drin. Nachtrag: Kommando zurück - in der Schaltung ist ein 74AHC125
:
Bearbeitet durch User
Danke - MIST!!! Hattest zu geschrieben... Auf dem ECB Board habe ich auch einen 74LV125 - den muss ich dann wohl auch austauschen? Damit nicht noch mehr Baustellen schlummern (Board soll 3,3 und V5 können, der AVR 1.1 am besten auch), hier mal die Liste. Ich glaube aber, die sind alle für 3,3 und 5V geeignet, nur der 125er muss 3,3 V im Ausgang und 5V im Eingang unterstützen. Auf dem ECB Board habe ich sonst so an ICs: Element SOLL IST (Reichlt) Reichelt neu IC1 74AHC125D SMD HC 125 ?? 74LVX 125 D oder 74ABT 125D-SMD? IC3 74LV74D SMD HC 74 --> sollte ok sein oder 74AC 74D-SMD? IC4 74LV00D 74VHC 00 D --> sollte ok sein Laut dem Datenblatt hätte ich jetzt gesagt, dass die SMD HC Serie 2-7V abkann... Das Thema Differenzspannung hatte ich da gar nicht gesehen. Beim AVR ist noch relevant IC 4 74LV138D SMD HC 138 oK? oder besser 74AC 138D-SMD? Mein Fazit: Der hier von Reichrlt sollte gehen, da seine Eingänge bis 7V können und explizit als Anwendung die Anbindung von 5V Systemen an 3V genannt wird? http://www.reichelt.de/ICs-74LVX-74VHCT-/74LVX-125-D/3/index.html?ACTION=3&GROUPID=2936&ARTICLE=40619&SEARCH=74%20125&OFFSET=16&;
:
Bearbeitet durch User
Ich hoffe da ergibt sich jetzt keine böse Überraschung für mich. Hab letzte Woche bestellt und mich streng an den Schaltplan gehalten. Mit Mühe wie man oben sieht...
So, bis ich den richtigen 125er habe betreibe ich alles erst mal auf 3,3V. Nun habe ich noch einen komischen Effekt. Beim Start kommt folgende Ausgabe:
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): none. |
3 | |
4 | ATMEGA2561+Z8S180 Stamp Monitor V6.5 (8.3.2016) |
5 | |
6 | ### main_loop entered: bootdelay=5 |
7 | |
8 | ### main_loop: bootcmd="reset; loadf; go ${startaddr}"
|
9 | Hit any key to stop autoboot: 0 |
10 | CPU nnw in reset state. |
11 | z80_memfifo_init: $i, 0 |
12 | z80_memfifo_init: $i, 1 |
13 | z80_memfifo_init: $i, 2 |
14 | z80_memfifo_init: $i, 3 |
15 | Bus timeout |
16 | Command failed, result=1 |
17 | Command failed, result=-1 |
18 | go - start apphacation at address 'addr' |
19 | Usage: |
20 | go addr |
21 | - start application at address 'addr' |
22 | => |
Stört euch nicht an den Fehlermeldungen, die Parameter sind noch nicht gesetzt, die SD nicht drin und die CPU nicht angeklemmt. Immer an EXAKT der gleichen Stelle kommt es zu Rechtschreibfehlern: "CPU nnw in reset state"" "start apphacation at" Ich habe den Quelltext noch mal überprüft und noch mal neu geflashed (über den bootloader) - keine Änderung. War mir erst gar nicht aufgefallen. Jemand eine Idee? Die AVR Stamp 1.0 macht das nicht:
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): Power on. |
3 | |
4 | ATMEGA1281+Z8S180 Stamp Monitor |
5 | |
6 | ### main_loop entered: bootdelay=3 |
7 | |
8 | ### main_loop: bootcmd="reset; pin 8 low; 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 | Error: failed to open '0:/cpm3+8drives.sys' |
16 | Command failed, result=1 |
17 | ## Starting application at 0xc600 ... |
18 | => |
Habe mir den Flash angeschaut - da steht es auch richtig drin :-)
:
Bearbeitet durch User
Marcel A. schrieb: > Auf dem ECB Board habe ich sonst so an ICs: Harald N. schrieb: > Ich hoffe da ergibt sich jetzt keine böse Überraschung für mich. Bei den anderen IC's gibt es keine Probleme. Die liegen ja komplett auf 3.3V oder auf 5V. Nur der Pegelwandler muss mit beiden Spannungen klar kommen, deshalb auch 74AHC... oder 74LVC... Marcel A. schrieb: > War mir erst gar nicht aufgefallen. Jemand eine Idee? Sieht mir nach einem Timing Problem aus. Bestücke doch erst mal komplett CPU und RAM damit die Busübernahme vom AVR korrekt durchgeführt werden kann.
Ich werde bekloppt... Zunächst mal: mit dem AVR 1.0 auf dem ECB und der Z180-Stamp (alles 3.3V) geht es prima - auch die beiden SD-Karten. Zugriff auf CPM ok.
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; pin 8 low; 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 | Loaded: Resident: 0x1E300-0x1EDFF, Banked: 0x09800-0x0EFFF |
24 | ## Starting application at 0xc600 ... |
25 | => z80_memfifo_init: 0, ca7d |
26 | z80_memfifo_init: 1, cac1 |
27 | z80_memfifo_init: 2, cc3d |
28 | z80_memfifo_init: 3, cc61 |
29 | |
30 | => connect |
31 | Connecting to CPU. Escape character is '^\'. |
32 | |
33 | Physical Devices: |
34 | I=Input,O=Output,S=Serial,X=Xon-Xoff |
35 | USB0 NONE IO ASCI0 19200 IOS ASCI1 19200 IOS |
36 | |
37 | |
38 | Current Assignments: |
39 | CONIN: = USB0 |
40 | CONOUT: = USB0 |
41 | AUXIN: = ASCI0 |
42 | AUXOUT: = ASCI0 |
43 | LST: = Null Device |
44 | |
45 | |
46 | A>dir |
47 | A: BDOS3 SPR : BNKBDOS3 SPR : CCP COM : COPYSYS COM : CPMLDR REL |
48 | A: DATE COM : DEVICE COM : DIR COM : DUMP COM : ED COM |
49 | A: ERASE COM : GENCOM COM : GENCPM COM : GET COM : HELP COM |
50 | A: HELP HLP : HEXCOM COM : PATCH COM : PIP COM : PUT COM |
51 | A: README : RENAME COM : RESBDOS3 SPR : SAVE COM : SET COM |
52 | A: SETDEF COM : SHOW COM : SID COM : SUBMIT COM : TYPE COM |
53 | A: FC INI : FC80 COM : DISKCOPY COM : KERMIT COM : PROFILE BAK |
54 | A: PROFILE SUB |
55 | A> |
Nun die AVR 1.1 (gleiche Environment-Einstellungen und Karten) - und später auch im gleichen ECB. Wenn ich die AVR Stamp mit der 2561er firmware flashe und "standalone" betreibe (3,3V oder 5V Einstellung), sieht die Startmeldung gut aus (keine "Rechtschreibfehler", mehr aber auch nicht, da keine SD-Karte verfügbar).
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): Power on, External, Brown out. |
3 | |
4 | ATMEGA2561+Z8S180 Stamp Monitor V6.5 (8.3.2016) |
5 | |
6 | ### main_loop entered: bootdelay=5 |
7 | |
8 | ### main_loop: bootcmd="reset; pin 8 low; 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 | Error: failed to open '1:/cpm3+8drives.sys' |
16 | Command failed, result=1 |
17 | ## Starting application at 0xc600 ... |
18 | => |
Wenn ich die AVR Stamp dann auf 3,3V jumpere und in das Basisboard einsetze, erscheinen wieder die "Rechtschreibfehler" (siehe nnw statt now) an immer genau der gleiche Stelle. Auch meldet er BUS TIMEOUT und kann angeblich das CPM.SYS nicht laden. Ebenfalls sehen die z80 memfifo-Zeilen ganz anders aus...
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): External. |
3 | |
4 | ATMEGA2561+Z8S180 Stamp Monitor V6.5 (8.3.2016) |
5 | |
6 | ### main_loop entered: bootdelay=5 |
7 | |
8 | ### main_loop: bootcmd="reset; pin 8 low; loadcpm3; go ${startaddress}"
|
9 | Hit any key to stop autoboot: 0 |
10 | CPU nnw in reset state. |
11 | z80_memfifo_init: $i, 0 |
12 | z80_memfifo_init: $i, 1 |
13 | z80_memfifo_init: $i, 2 |
14 | z80_memfifo_init: $i, 3 |
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 | => |
Zugriff auf die SD geht aber soweit ich das testen kann:
1 | => sd init 0 |
2 | rc=00 |
3 | => fatls 0: |
4 | ----A 2015/09/23 20:51 8388608 ws33.dsk |
5 | ----A 2015/09/24 19:46 8388608 basic.dsk |
6 | ----A 2015/09/23 21:05 8388608 bdsc.dsk |
7 | ----A 2015/06/12 09:14 22784 cpm3_4d.sys |
8 | ----A 2015/09/24 10:57 25600 cpm3_8d.sys |
9 | ----A 2015/09/23 22:00 25600 cpm3+8drives.sys |
10 | ----A 2015/03/13 18:35 8388608 CPM3SY~1.DSK |
11 | ----A 2015/05/21 08:16 14548992 cpm3test.dsk |
12 | ----A 2015/09/23 20:54 8388608 dbaseii.dsk |
13 | ----A 2015/09/20 17:57 8388608 development.dsk |
14 | ----A 2015/08/27 15:49 8388608 editor.dsk |
15 | ----A 2015/06/01 16:41 8388608 kermit.dsk |
16 | ----A 2015/09/23 20:57 8388608 multiplan.dsk |
17 | ----A 2014/12/12 19:54 8388608 neu.dsk |
18 | ----A 2015/12/20 21:54 8388608 turbo3.dsk |
19 | ----A 2008/04/12 19:19 1113536 vedit.dsk |
20 | ----A 2015/09/24 14:33 8388608 mp.dsk |
21 | ----A 2015/09/24 13:58 8388608 ws.dsk |
22 | ----A 2015/12/18 18:40 8388608 ws4.dsk |
23 | 19 File(s), 133177024 bytes total |
24 | 0 Dir(s), 3720128K bytes free |
25 | => fatstat 0: |
26 | FAT type: 3 |
27 | Bytes/Cluster: 32768 |
28 | Number of FATs: 2 |
29 | Root DIR entries: 0 |
30 | Sectors/FAT: 941 |
31 | Number of clusters: 120320 |
32 | FAT start (lba): 14502 |
33 | DIR start (lba,cluster): 2 |
34 | Data start (lba): 16384 |
35 | Volume name: CPM |
36 | Volume S/N: 3A09-FE1C |
37 | |
38 | 19 files, 133177024 bytes. |
39 | 0 folders. |
40 | 3850240 KB total disk space. |
41 | 3720128 KB available. |
42 | => |
Nehme ich an dieser Stelle die cpm3_4d.sys (von früher) lande ich einer Bootschleife. Es macht auch keinen Unterschied, ob ich die Datei von 0: oder 1: lese.
:
Bearbeitet durch User
Noch eine Info wg. Bus Timeout. Die Duo-Led geht nach kurzer Zeit von Orange auf grün und die WAIT Led geht dann aus - so wie es sein soll. Auf zum Z180 Board ist allerdings noch ein Quarz drauf. Der Jumper steht aber auf "Taktversorgung von Extern" und auf dem ECB steht der Jumper auf ACLK0. Ich messe an dem Jumper (Mitte) auch genau den Takt. Umjumpern auf intern Quarz macht aber auch keinen Unterschied. Mit der AVR 1.0 macht der Quarz hier keine Zicken. Oder muss der raus (Thema hatten wir oben schon mal...)
:
Bearbeitet durch User
Bei "Rechtschreibfehlern" in der Ausgabe würde ich auf grenzwertiges Taktsignal tippen, obwohl dafür wieder sehr wenige Fehler drin sind. Die Bus Timeouts könnten auch von einem unzuverlässigen Clock verursacht sein. Würde dem Z180 der Takt ganz fehlen, müßte der Fehler schon viel früher kommen. Die AVRs werden bei 3,3V ja deutlich übertaktet. Hast Du einen ATmega2561 (Ausgabe von avrdude weiter oben) oder doch einen ATmega2561V (Hast Du oben mal geschrieben)? Letzterer ist nur bis 8MHz spezifiziert. Jedenfalls: - Welcher Taktoszillator wird verwendet? (fuses) - Oszillator und CLKO pin mit Oszi anschauen. - Taktfrequenz runtersetzen. Wenn kein passender Quarz vorhanden, den Prescaler umprogrammieren: In main.c, Funktion setup_avr() : CLKPR = _BV(CLKPCE); CLKPR = 0; // --> CLKPR = 1;
Leo C. schrieb: > Bei "Rechtschreibfehlern" in der Ausgabe würde ich auf grenzwertiges > Taktsignal tippen, obwohl dafür wieder sehr wenige Fehler drin sind. > > Die Bus Timeouts könnten auch von einem unzuverlässigen Clock verursacht > sein. Würde dem Z180 der Takt ganz fehlen, müßte der Fehler schon viel > früher kommen. Ich habe mal den Quarz auf dem Z180 ausgelötet - keine Änderung. > > Die AVRs werden bei 3,3V ja deutlich übertaktet. > Hast Du einen ATmega2561 (Ausgabe von avrdude weiter oben) oder doch > einen ATmega2561V (Hast Du oben mal geschrieben)? Letzterer ist nur bis > 8MHz spezifiziert. Den "ohne" V - aber laut Datenblatt sieht es so aus, dass der bei 16MHz eh nur einen "Safe"-Bereich von 4,5 - 5,5V hat. (Wieso ich oben geschrieben habe, dass das Board auch bei 3,3V standalone läuft, kann ich nicht sagen, denn dafür ist ja gar keine Spannung auf dem Board :-)) Hätte ich doch mal den 1281er genommen, aber den gibts bei Reichelt nicht (mehr). Aber eigentlich will ich ja eh bei 5V betreiben - da muss ich nur noch die 125er austauschen... > > Jedenfalls: > - Welcher Taktoszillator wird verwendet? (fuses) Exakt wie bei 1281 bzw. in der Doku. AF D6 FD > - Oszillator und CLKO pin mit Oszi anschauen. Kann ich nicht - das schafft wohl mein altes Teil nicht mehr... > - Taktfrequenz runtersetzen. Wenn kein passender Quarz vorhanden, Das muss ich dann wohl mal testen. Wäre ja übel. > den Prescaler umprogrammieren: In main.c, Funktion setup_avr() : > CLKPR = _BV(CLKPCE); > CLKPR = 0; // --> CLKPR = 1;
:
Bearbeitet durch User
> den Prescaler umprogrammieren: In main.c, Funktion setup_avr() : > CLKPR = _BV(CLKPCE); > CLKPR = 0; // --> CLKPR = 1; Das hat aber zur Folge, dass die serielle Ausgabe Müll macht - offenbar wird dann eine andere Übertragungsrate eingestellt? (115200/8) = 14.400?
CLKPR = 1 teilt durch 2. D.h. 115200 --> 57600, wenn F_CPU nicht angepasst wurde. Letzteres ist aber empfehlenswert, wg. Systemzeit, Timeouts, ...
Mein Held :-) CLKPR und F_CPU haben es gebracht - alles ok bei 3,3V. Gut dass du mir gezeigt hast, wie ich die Buildumgebung einrichten musste! Jetzt hoffe ich mal, dass ich bei 5V dann auch wieder den Takt verdoppeln kann.
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): External. |
3 | |
4 | ATMEGA2561+Z8S180 Stamp Monitor V6.5 geringer Takt (14.3.2016) |
5 | |
6 | ### main_loop entered: bootdelay=5 |
7 | |
8 | ### main_loop: bootcmd="reset; pin 8 low; 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: '1:/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 | Loaded: Resident: 0x1E300-0x1EDFF, Banked: 0x09800-0x0EFFF |
24 | ## Starting application at 0xc600 ... |
25 | => z80_memfifo_init: 0, ca7d |
26 | z80_memfifo_init: 1, cac1 |
27 | z80_memfifo_init: 2, cc3d |
28 | z80_memfifo_init: 3, cc61 |
29 | |
30 | => con |
31 | Connecting to CPU. Escape character is '^\'. |
32 | |
33 | Physical Devices: |
34 | I=Input,O=Output,S=Serial,X=Xon-Xoff |
35 | USB0 NONE IO ASCI0 19200 IOS ASCI1 19200 IOS |
36 | |
37 | |
38 | Current Assignments: |
39 | CONIN: = USB0 |
40 | CONOUT: = USB0 |
41 | AUXIN: = ASCI0 |
42 | AUXOUT: = ASCI0 |
43 | LST: = Null Device |
44 | |
45 | |
46 | A>dir |
47 | A: BDOS3 SPR : BNKBDOS3 SPR : CCP COM : COPYSYS COM : CPMLDR REL |
48 | A: DATE COM : DEVICE COM : DIR COM : DUMP COM : ED COM |
49 | A: ERASE COM : GENCOM COM : GENCPM COM : GET COM : HELP COM |
50 | A: HELP HLP : HEXCOM COM : PATCH COM : PIP COM : PUT COM |
51 | A: README : RENAME COM : RESBDOS3 SPR : SAVE COM : SET COM |
52 | A: SETDEF COM : SHOW COM : SID COM : SUBMIT COM : TYPE COM |
53 | A: FC INI : FC80 COM : DISKCOPY COM : KERMIT COM : PROFILE BAK |
54 | A: PROFILE SUB |
55 | A> |
Angehängte Dateien:
-
speedgrades.png
29 KB
Jetzt ist die Frage, ob Du einen Ausreißer hast, oder ob sich der 2561 grundsätzlich schlechter übertakten läßt, als der 1281. Das die neue Layoutversion (1.1) mehr Probleme macht als die alte, schließe ich mal aus, das sie bei Joe mit ATmega1281 ja einwandfrei zu laufen scheint. > Jetzt hoffe ich mal, dass ich bei 5V dann auch wieder den Takt > verdoppeln kann. Gerade beim ATmega2561 sollte die maximale Taktfrequenz unabhängig von der Betriebsspannung sein, siehe Anhang. Auf jeden Fall gibt es aber einen Unterschied zwischen ATmega2561 und dem Rest der Familie.
:
Bearbeitet durch User
Das Bild hatte ich auch gesehen, da hatte mich gewundert, dass die X-Achse erst bei 4,5 V anfängt. Wie du schon sagtest, auf jeden Fall etwas anders. Wir werden sehen.
> dass die X-Achse erst bei 4,5 V anfängt.
Oh, das habe ich ja total übersehen. :-(
Leo C. schrieb: > Das die neue > Layoutversion (1.1) mehr Probleme macht als die alte, schließe ich mal > aus, das sie bei Joe mit ATmega1281 ja einwandfrei zu laufen scheint. Ist nicht repräsentativ, aber die zwei Versionen(1.1) die ich aufgebaut habe laufen mit dem ATmega1281 und 3.3V stabil. Bei der Version 1.0 gab es hin und wieder Probleme beim Einlesen des BIOS von der SD-Card. Das Taktsignal jitterte sehr. Erst mit "Full-Swing-Crystal" war Ruhe.
Während ich noch auf die 125er warte... habe ich noch zwei weitere Z80-Systeme in Betrieb genommen: Den "Microprofessor": http://retro-compi.de/index.php/mpf1 Und den Z80 mini EMUF: http://retro-compi.de/index.php/z80-mini-emuf Bei letzterem war auch ein sehr schönes MSR-Basic dabei - echtzeitfähig, guter IO-Zugriff usw. Ich habe fast keine Informationen darüber gefunden (soll von der Uni München sein, speziell für den EMUF angepasst, aber auch für DOS und CP/M verfügbar gewesen sein). Im Handbuch zum EMUF steht, dass man darauf (ist ja fast wie die Z180 Stamp) ein CP/M realisieren "könnte" :-)
So die 74LVX125 von Reichelt sind angekommmen und nun geht es problemlos mit 3,3V und 5V. Danke für eure Hilfe! Bitte diesen Hinweis für die oben mal von mir veröffentlichte BOM (Reichelt) beachten!
Marcel A. schrieb: > Und den Z80 mini EMUF: http://retro-compi.de/index.php/z80-mini-emuf Das sieht mir fast aus wie der Z80mini3 [1,2]. Der Entwickler scheint sogar mal hier im Forum unterwegs gewesen zu sein [3]. [1] http://elmicro.com/de/z80mini3.html [2] http://mct.de/product/z80mini3.html [3] Beitrag "Re: alternative zu z80"
So, nun komme ich endlich zu meinem Frontpanel-Projekt. Zuvor wollte ich aber dann noch die Funktionweise der LED/Einzelschrittsteuerung auf der ECB verstehen - das wurde zwar glaube ich oben schon mal diskutiert, aber ich habs noch nicht... Zunächst WAIT: ich gehe davon aus, PG2/WAIT auf dem AVR ist ein Ausgang - der direkt mit WAIT auf dem Z180 verbunden ist. Wann setzt der AVR das Signal auf Low? Es ist ja ein Befehl im BootCmd - ist das egal oder erst wenn die Speicheroperationen fertig sind? Das Wait-Signal wird ja auch von der Steuerlogik auf der ECB bestimmt. Wobei die LED ja an der Basis des Transistors hängt und daher nicht direkt den Zustand von Wait anzeigt sondern nur den über die ECB gesteuerten Zustand? Dass der Transistor dann ggf. ein High-Ausgang des AVRs auf LOW zieht ist egal? Nun auch die Frage, wie das ECB Wait entsteht. Wenn ich die Logikstufen richtig verstanden habe: Die CPU "läuft", wenn entweder RUN Lowactiv gesetzt wird (aktiv vom AVR, wann genau?) oder der Rest der Schaltung "0" ausgibt. Das passiert glaube ich nur dann, wenn das D-FlipFlip (Takt aus MREQ/IORQ) mit der STEP-Leitung vom AVR auf 0 gesetzt wird (Reset). D.h. ein "Schritt" ist immer der Abstand zwischen zwei Speicher-Aktionen? Wozu ist der Kondensator C8 vor CLR? DuoLed HALT/RUN: Bisher sehe ich in der Praxis nur den Zustand Grün oder Orange. Rot würde sie ja nur werden, denn HALT auf activelow wäre (und ZRESET high ist). Für "RUN" ergibt sich der Status ebenfalls aus den Gattern. Auch hier zeigt "RUN" ja nicht den echten Status des RUN-Signals des AVRs...? Wird also RUN/STEP nur für die Einzelschrittsteuerung genutzt? Gehe ich recht in der Annahme, dass ZRESET auch vom AVR gesteuert wird in der Startphase, um erst den Speicher zu füllen?
> ich gehe davon aus, PG2/WAIT auf dem AVR ist ein Ausgang - der direkt > mit WAIT auf dem Z180 verbunden ist. Nein, /WAIT ist am AVR nur als Eingang gedacht, um den Zustand abfragen zu können. > Wobei die LED ja an der Basis des Transistors hängt und daher nicht > direkt den Zustand von Wait anzeigt sondern nur den über die ECB > gesteuerten Zustand? Ja. Wäre die Led auf der anderen Seite des Transistors, könnte man sehen, wenn andere Busteilnehmer die CPU ausbremsen. Diese gibt es aber bisher nicht, und die Led hätte noch einen Treiber gebraucht. > Dass der Transistor dann ggf. ein High-Ausgang des AVRs auf LOW zieht > ist egal? Das ist nicht vorgesehen, da der AVR-Port ja nicht mit der Z180-CPU synchronisiert ist. Genau dafür gibt es ja die Single-Step Logik auf der ECB-Karte. Das ganze funktioniert so: /RUN = 0 : Single Step ist abgeschaltet, CPU läuft /RUN = 1 : Durch /MREQ=0 oder /IOREQ=0 wird das D-FF gesetzt --> /WAIT wird 0, CPU wird angehalten. Durch einen Low-Impuls an /STEP wird das FF zurückgesetzt --> /WAIT wird wieder 1, CPU läuft bis zum nächsten Memory- oder I/O-Zugriff. Der Kondensator sorgt (zusammen mit dem Widerstand) dafür, das an /CLR des FF nur ein kurzer Impuls erzeugt wird. Sonst könnte es passieren, dass /CLR beim nächsten MEM- oder I/O-Zugriff noch aktiv ist, und das FF nicht gesetzt werden kann. > DuoLed HALT/RUN: Die Duoled ist unabhängig von der Single-Step-Logik. Orange: CPU außer Betrieb, AVR-Monitor hat Kontrolle über das System. Grün: CPU läuft. Rot: CPU steht auf HALT-Befehl. Das kommt in die Interupt-gesteuerten I/O-Treiber rein. Dann sieht man an der Led, ob die CPU auf Eingaben wartet, oder beschäftigt ist. Oder ob das Programm abgestürzt ist, und in einer Endlosschleife hängt... > Gehe ich recht in der Annahme, dass ZRESET auch vom AVR gesteuert wird > in der Startphase, um erst den Speicher zu füllen? Ja. Und es gibt Monitor-Befehle um einen Reset-Impuls auszulösen, oder den Reset dauerhaft zu aktivieren.
Danke - soweit jetzt weitgehend klar. Bis zu meinem ersten Entwurf eigentlich nur noch eine Frage: Bei dem S100 Panel hat er bei einige LEDs (die mit "Impulsen") durch ein MonoFlop (74LS123) die Anzeige verlängert - macht das Sinn? http://www.s100computers.com/My%20System%20Pages/SMB%20Board/S100%20Bus%20SMB.htm
> macht das Sinn? Kommt drauf an. ;-) Die c't hatte auch mal einen interessanten Bus-Monitor, der auch im N8VEM-Projekt gelandet ist: http://www.retrobrewcomputers.org/doku.php?id=boards:ecb:bus-monitor:start http://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:bus-monitor:ecb_ct_bus_monitor.pdf
Das c't Projekt ist ja richtig gut :-) Minimaler Hardwareaufwand bei maximaler Funktionanlität.
Ich muss mich auch noch mal mehr mit der Speicheraufteilung
beschäftigen. Die Darstellung ganz weit oben weicht ja schon vom
"Standard CPM 3" ab. Im Moment bin ich froh, dass die Aufteilung bei
einem normalen Z80 (hier NDR NKC) verstanden habe :-)
Falls ich mal eine "echte" IO-Baugruppe einbauen möchte ("so wie
früher"), würde ich dieser doch eine Adresse in der Page-0 geben (mit
nem einfachen Addessdekoder?
Ich bin mal ein paar Dateien durchgegangen - aber ich finde keine
Übersicht der belegten Adressen?
Hier hier sind ja die I2C-Routinen auch drin - die Uhr ist daran ja
angebunden - ich glaube Adresse 50?.
Kann man den Bus auch "generisch" vom Z180 aus zugreifbar machen?
Ach ja - wie stehts eigentlich um das Vinculum?
Marcel A. schrieb: > Ach ja - wie stehts eigentlich um das Vinculum? Der läuft gerade auf Sparflamme. Mein Verlag erwartet von mir noch in diesem Jahr ein 350seitiges Manuskript. Der nächste Schritt beim Vinculum ist erst mal eine kleine Zusatzplatine, damit jeder Interessent sich diese Hardware anstecken kann.
Marcel A. schrieb: > Ich muss mich auch noch mal mehr mit der Speicheraufteilung > beschäftigen. Die Darstellung ganz weit oben weicht ja schon vom > "Standard CPM 3" ab. Wo gibt es denn ein "Standard CP/M 3" mit einem 512 KByte RAM-Chip? > Falls ich mal eine "echte" IO-Baugruppe einbauen möchte ("so wie > früher"), würde ich dieser doch eine Adresse in der Page-0 geben (mit > nem einfachen Addessdekoder? I/O wird in Z80-Systemen üblicherweise über I/O-Adressen angesprochen, hat also mit der Speicher-Adressierung nichts zu tun. > Ich bin mal ein paar Dateien durchgegangen - aber ich finde keine > Übersicht der belegten Adressen? Bisher haben wir ja nur die Peripherie, die bereits im Z180 eingebaut ist. Die Belegung findest Du also in den Z180 Handbüchern. (Und in der Datei z180reg.inc) Die Z180-Peripherie belegt die ersten 64 Byte des I/O-Adressraums. > Hier hier sind ja die I2C-Routinen auch drin - die Uhr ist daran ja > angebunden - ich glaube Adresse 50?. > Kann man den Bus auch "generisch" vom Z180 aus zugreifbar machen? Das ist angedacht.
Leo C. schrieb: > I/O wird in Z80-Systemen üblicherweise über I/O-Adressen angesprochen, > hat also mit der Speicher-Adressierung nichts zu tun. Schon klar, so war das auch gemeint. > Bisher haben wir ja nur die Peripherie, die bereits im Z180 eingebaut > ist. Die Belegung findest Du also in den Z180 Handbüchern. (Und in der > Datei z180reg.inc) Die Z180-Peripherie belegt die ersten 64 Byte des > I/O-Adressraums. Das hatte ich gesucht. Aber warum nur 64 bytes? Das sind doch "sonst" 256 Bytes? Bis 3F ist ja schon alles voll :-)
Marcel A. schrieb: > Das hatte ich gesucht. Aber warum nur 64 bytes? Warum denn nicht? Was fehlt Dir denn? > Das sind doch "sonst" > 256 Bytes? Wo denn? >Bis 3F ist ja schon alles voll :-) 2 Adressen, bzw. Adressbereiche hatte ich noch vergessen. 40-5F werden auf der AVR-Stamp ausdekodiert, um dem AVR 2 Interrupt-Signale senden zu können.
Mit dem IORQ werden doch A0 - A7 adressiert. Das sind 256 IO Asressen. Du nutzt doch selbst mit 5F Adressen jenseits 64, vermutlich haben wir aneinander vorbei gesprochen. Ich würde meiner IO Karte dann z.B. Die IO Adresse 70h geben... Und müsste die dan mit den in und out Befehlen ansprechen können? http://home.mit.bme.hu/~benes/oktatas/dig-jegyz_052/Z80-kivonat.pdf Letzte Seite.
> Ich würde meiner IO Karte dann z.B. Die IO Adresse 70h geben... Und > müsste die dan mit den in und out Befehlen ansprechen können? Ja.
So, ich habe hier einmal meine Idee einer Bussignal-Anzeige skizziert mit der Bitte um Feedback. Falls man davon wirklich eine Platine machen sollte, muss ich mir noch etwas für die Verbindungen der Basis- und Anzeigeeinheit überlegen. Für die Anzeige verwende ich derzeit TIL311 - diese haben die Treiber/Dekoderlogik schon eingebunden - ich hatte einige günstig erstanden. Eine Alternative wären vielleicht später noch "normale" 7-Segment-Anzeigen mit eine D345D (ex DDR) Dekoder (habe ich auch welche hier) - oder eben mit einem AVR als Dekoder-IC. Im Moment sind alle Signale gepuffert. Die Status-LEDs sind 1:1 verdrahtet - ohne Monoflop. Für die Adress-Anzeige habe ich einen Latch aus MREQ und IORQ gebildet. Wahrscheinlich kann man den auch für die Datenanzeige verwenden, ansonsten ist ein Latch aus RD/WR vorhanden. Dann habe ich noch einmal die SingleStep-Logik des ECB Basisboards übernommen und an "richtige" Schalter für einen manuellen Betrieb angeschlossen. Ich habe mich mal gezwungen, KiCad zu nehmen, da Eagle in der Free-Version ja auch halbe Euro-Platinengröße begrenzt.
Marcel A. schrieb: > So, ich habe hier einmal meine Idee einer Bussignal-Anzeige skizziert > mit der Bitte um Feedback. Bin unterwegs, deshalb kann ich die Pläne nicht richtig anschauen. Adressen und Daten sollten imho gleichzeitig gelached werden. Da unser Adressbus 20 Leitungen hat, würde ich für die Anzeige 5 Stellen vorschlagen. Der Step-Taster muß entprellt werden. Wenn man Displays mit Hexdecoder selber bauen will, wären die 8x8 Matrix-Displays, die man bei den Chinesen in vielen Varianten mit und ohne Treiber findet vielleicht einen Blick wert. Gleich kommt Karlsruhe, da könnte ich den Text ja beinahe persönlich abgeben. :-) Frohe Ostern
Karlsruhe? - Das ist nicht meine Ecke :-) 5-stelliger Adressbus - ok. Wahrscheinlich wären dann auch noch die anderen Signale des Z180 wie INT1 und INT2 und ... sinnvoll? Ich habe mich halt derzeit auf den "Standard"-Z80 beschränkt - das ist mir schon komplex genug. Entprellen - reicht das C da nicht? Sonst habe ich noch Schaltungen mit Doppel-NAND (oder so) zur Entprellung gesehen - meinst du so was? Und ich habe noch etwas Stress mit dem FTDI (wobei ich immer wieder schwören könnte, dass ich das vorher nicht hatte). Solange ich die ECB über USB Power versorge, klappt es wunderbar. Auch die Umschaltung auf RX/TX-MAX232 auf "echte" serielle (Reset des FTDI) klappt gut mit einem kleinen Schalter auf der Frontplatte. Es geht auch weiterhin gut, wenn ich die ECB in den Rahmen stecke, natürlich den Jumper für BUS Power ziehe aber weiterhin ein USB-Kabel am FTDI lasse. Nur wenn ich das USB Kabel nun abziehe (und RESET gegen GND schalte) und Spannung einschalte, gegen bei beiden LEDs am FTDI auf Dauerlicht. Am RX/TX kommt zuerst etwas Müll, aber dann kommt die Anzeige. Eingaben gehen dann aber nicht mehr. Stecke ich kurz das USB-Kabel in die Buchse, "berappelt" sich der FTDI (Lampen gehen aus) und ich kann wunderbar über RX/TX und COM1 arbeiten. Als wenn der FTDI ohne USB-Verbindung in einen undefinierten Zustand gehen würde beim Power-on. Ich habe aber mit FT-Prog keine mir sinnvolle erscheinende Einstellung gefunden, das zu ändern.
Vergesst das FT232-Problem. Ich hatte mal (weil es damit besser ging) einen Widerstand in die TX-Leitung des Moduls eingebaut - ohne geht es (jetzt) super :-) Zum Entprellen habe ich (wie auch an vielen anderen Stellen) das hier gefunden: http://www.loetstelle.net/praxis/entprellen/entprellen.php https://www.mikrocontroller.net/articles/Entprellung#Einfacher_Taster Im S100 Frontpanel wird der Wechselschalter verwendet - ich würde hier aber die Integrations-Methode (RC + Inverter) nehmen - reicht die einfache Variante mit R=33k und C=100n?
:
Bearbeitet durch User
Beim Testen/Aufräumen meiner "Disk-Images" ist mir aufgefallen, dass man im AVR Monitor zwar zur Laufzeit neue Images auf Drives legen kann, wenn man die austauscht, hat das aber zur Laufzeit im CPM keine Auswirkungen.
Marcel A. schrieb: > reicht die einfache Variante mit R=33k und C=100n? Das kann so pauschal nicht beantwortet werden. Es hängt stark von der qualität der Schalter (Taster) ab. ich würde es mal mit den vorhandenen Tastern auf einem Steckbrett erproben.
Marcel A. schrieb: > Entprellen - reicht das C da nicht? Sonst habe ich noch Schaltungen mit Das C (mit dem R) ist ein Hochpass und macht damit gerade das Gegenteil. > Doppel-NAND (oder so) zur Entprellung gesehen - meinst du so was? Ja, wobei man hier auch das 2. FF im 7474 nehmen könnte (Set- und Reset-Eingang). Marcel A. schrieb: > Im S100 Frontpanel wird der Wechselschalter verwendet - ich würde hier > aber die Integrations-Methode (RC + Inverter) nehmen Das geht notfalls auch, aber der Inverter muß ein Schmitt-Trigger sein. Und wie Joe geschrieben hat, hängt das RC-Glied vom verwendeten Taster ab. Für den RUN/STOP-Schalter reicht übrigens ein einfacher Schließer plus Pullup. Marcel A. schrieb: > Beim Testen/Aufräumen meiner "Disk-Images" ist mir aufgefallen, dass man > im AVR Monitor zwar zur Laufzeit neue Images auf Drives legen kann, wenn > man die austauscht, hat das aber zur Laufzeit im CPM keine Auswirkungen. Hast Du nach dem "Disk-Wechsel" auch Ctrl-C gedrückt?
> > Hast Du nach dem "Disk-Wechsel" auch Ctrl-C gedrückt? Ähm, nein... Wo denn, im CCP?
Ja. CP/M kann ab Version 3 stattdessen auch ein Disk-Change-Signal auswerten. Dieses Signal müßte vom AVR-Monitor beim Ändern der Environment-Variable an den Z180 übermittelt werden. Das ist bisher noch nicht implementiert.
Angehängte Dateien:
-
cf-if.jpg
87 KB
CompactFlash Interface ganz einfach. Vor kurzem bin ich zufällig darüber gestolpert, daß alle CF-Karten im 'True IDE Mode' 8 Bit Datenübertragung unterstützen. Bei IDE Festplatten ist das wohl nur bei den allerersten der Fall, aus der Zeit, als noch PC-XTs verkauft wurden. Eine CF-Karte und einige 'DiskOnModule'[1], die auch nur einen CF-Controller enhalten, liegen hier schon seit Jahren rum. Aber ein performantes 16-Bit Interface war mir immer zu aufwendig[0]. Leider hatte ich keine Decoder (74HC138 oder '139) vorrätig. Damit könnte man das Gattergrab deutlich reduzieren. Die Buffer in den Adressleitungen A0-A2 sind leider notwendig. Grundsätzlich funktioniert das Interface bei 3.3V. Allerdings habe ich bisher nur mit 9,2MHz getestet. Ob die HC-Gatter bei 18,432MHz (oder mehr) und 3.3V noch schnell genug sind, habe ich noch nicht getestet. Der CP/M 3 Treiber funktioniert grundsätzlich. Für den Datentransfer kann ein DMA-Kanal verwendet werden. Dadurch wird das IF sauschnell. Allerdings habe ich einen dicken Fehler noch nicht gefunden. Deshalb gibts dieses Wochenende noch keine Software. [0] Z.B hier http://www.gaby.de/gide/index.htm und hier: Beitrag "Spikes, Designproblem ?" Etwas einfacher, aber nicht mehr performant, ist das hier: http://www.retroleum.co.uk/electronics-articles/an-8-bit-ide-interface/ [1] Die Teile gibts spottbillig bei Pollin, billiger als die günstigsten CF-to-IDE Adapter: http://www.pollin.de/shop/dt/OTAyODkyOTk-/Computer_und_Zubehoer/Hardware/Festplatten_intern/DiskOnModule_PQI_IDE_128_MB.html Das Kabel, das man optional mitbestellen kann, braucht man nicht, da das Modul auch über Pin 20 versorgt werden kann. Scheint auch mit 3.3V zu laufen, aber gründliche Tests stehen noch aus.
Prima Sache! Die CF wird dann unter CP/M (wie genau?) angesprochen? Was ist denn da für ein Filesystem drauf? Leider gibts ja kaum noch CF-Karten (in meiner uralten Kamera steckt glaube ich noch eine :-)) Von daher bin ich auch sehr auf das USB Vinculum Projekt gespannt.
Marcel A. schrieb: > Die CF wird dann unter CP/M (wie genau?) angesprochen? Wie eine IDE-Festplatte. Unter den o.g Links (GIDE und Retroleum) ist das ausführlich erklärt. Der Datentransfer erfolg mit voller CPU-Busgeschwindigkeit. Das dürfte (zumindest beim Lesen) kaum langsamer als eine RAM-Disk sein. > Was ist denn da für ein Filesystem drauf? Das halt, das man drauf macht. Das ist ebenfalls genauso wie auf Festplatten oder SD-Karten. CF-Karten können nicht im laufenden System gesteckt oder gezogen werden, wenn sie im Tue-IDE-Mode betrieben werden. Deshalb kann man sie wirklich wie eine Festplatte behandeln und das Dateisystem kann auch irgendwas spezielles für diesen einen Computer sein. Ich habe vor, die Karte genauso zu partitionieren, wie auf dem AVR-CP/M-System, also MBR mit Partitionstabelle und 1 bis 4 CP/M-Partitionen. Der Rest der Karte kann dann für andere Dateisysteme genutzt werden (FAT). Nicht geplant ist, CP/M-Dateisystem-Images auf einer FAT-Partition zu unterstützen. Dafür haben wir ja noch die SD-Karten. > Leider gibts ja kaum noch CF-Karten Da wäre ja vielleicht das Pollin DiskOnModule Teil eine Möglichkeit.
Angehängte Dateien:
-
Disk_Modul.jpg
240 KB
Leo C. schrieb: > Da wäre ja vielleicht das Pollin DiskOnModule Teil eine Möglichkeit. Sehr schöne Arbeit Leo! Über Reroleum bin ich vor einiger Zeit auch schon mal gestolpert und habe in einem Anflug von "Hamstern" bei Max Pollin zugelangt :-) Wenn also jemand die Versandkosten sparen möchte... für einige (viele) CP/M Systeme reicht mein Vorrat. Vielleicht gleich mit einer kleinen Platine, dann lohnt sich der Aufwand auch bei Elecrow die USB-Platine zu bestellen.
Aber Hallo! ;-)
Ich hatte mich mit 3 Stück begnügt. Damals hatten sie aber noch 1,50
€/Stck gekostet.
> Vielleicht gleich mit einer kleinen Platine
Eine kleine Platine, auf die nur so ein DoM passt, könnte man als
Huckepack-Platine für das Stamp-Modul machen. Für einen
CF-to-IDE-Adapter reicht der Platz nicht. Die Adapter bestehen
eigentlich auch nur aus der Verbindung zweier Stecker. Könnte man auch
weglassen. Aber die 50 poligen CF-Sockel sind einzeln wahrscheinlich
teurer, und vor allem schwer zu löten.
Europakarte (ECB) ist eigentlich überdimensioniert. Es sei denn, wir
finden noch was anderes, was mit drauf passen könnte. Andererseits
könnte man eine ECB-Karte auch für andere Systeme verwenden.
Vielleicht noch einen Parallelport zum Steuern und Regeln, 8255. Dann lohnt der Adressdecoder :-)
Leo C. schrieb: > Eine kleine Platine, auf die nur so ein DoM passt, könnte man als > Huckepack-Platine für das Stamp-Modul machen. So war damals schon mein Plan, einfach Huckepack auf den Stamp als Festplatte.
Leo C. schrieb: > Die Buffer in den > Adressleitungen A0-A2 sind leider notwendig. Was ist denn U5 für ein Baustein? 245/541?
> Vielleicht noch einen Parallelport zum Steuern und Regeln, 8255. Z80 PIO? Allerdings geht damit kein 3.3V Betrieb. Ein paar Latches und Buffer? > Was ist denn U5 für ein Baustein? 245/541? HC126. War in der Bastelkiste. Jeder andere Buffer geht aber auch. Man hätte auch die 3 freien Gatter nehmen können, aber da 2 davon invertieren, wäre die Reihenfolge der IDE-Register nicht mehr Standard. Außerdem gings mit dem Extra-Baustein schneller.
Leo C. schrieb: > Bank 0: 00000 - 0EFFF > Bank 1: F0000 - 1DFFF (+ F000) > common: 1E000 - 1EFFF (+ F000) > Bank 2: 1F000 - 2DFFF (+ F000 + 1000) > usw. (+ F000) ich kämpfe mich gerade durch die Speicherarchitektur. Muss es bei Bank 1 nicht heißen: Bank 1: 0F000 - 1DFFF (+ F000) ?
Joe, ich glaube in deinem Anhang A sind ein paar Fehler in der PIN-Beschreibung: - A12/A13 ist laut AVR Schaltplan PG5/PG4 (nicht PG4/PG5) - B26 ist ja beim AVR RXD0 - B27 ist ja beim AVR RXD1 - Müssten B3-B5 nicht bei Z180 und AVR A16-A18 sein (statt PE2-PE4)?
Marcel A. schrieb: > - A12/A13 ist laut AVR Schaltplan PG5/PG4 (nicht PG4/PG5) Das verstehe ich nicht. Im AVR-Schaltplan steht: B8 - A13 - PC5 B9 - A12 - PC4 ist doch korrekt so. > - B26 ist ja beim AVR RXD0 > - B27 ist ja beim AVR RXD1 B26 /WAIT - RXD0 B27 /PHI - TXD0 > - Müssten B3-B5 nicht bei Z180 und AVR A16-A18 sein (statt PE2-PE4)? B3 - A18 - PE4 B4 - A17 - PE3 B5 - A16 - PE2 ist doch auch korrekt, oder?
Angehängte Dateien:
-
avr_pinout.jpg
130 KB
Joe G. schrieb: > Marcel A. schrieb: >> - A12/A13 ist laut AVR Schaltplan PG5/PG4 (nicht PG4/PG5) > Das verstehe ich nicht. Im AVR-Schaltplan steht: > B8 - A13 - PC5 > B9 - A12 - PC4 > ist doch korrekt so. Sorry, ich meinte A12/A13 auf der PIN-Leiste der AVR-Stamp. Das ist im obigen Übersichtsbild anders als im AVR Schaltplan. Da ist PG4/PG5 anderes herum. > >> - B26 ist ja beim AVR RXD0 >> - B27 ist ja beim AVR RXD1 > B26 /WAIT - RXD0 > B27 /PHI - TXD0 Genau - da hatte ich wohl das SVN nicht aktualisiert. > >> - Müssten B3-B5 nicht bei Z180 und AVR A16-A18 sein (statt PE2-PE4)? > B3 - A18 - PE4 > B4 - A17 - PE3 > B5 - A16 - PE2 > ist doch auch korrekt, oder? In deinem Bild schon. Ich bezog mich aber auf dieses hier (da wo die gemeinsamen Anschlüsse grün sind). Da müsste B3-B5 doch auch grün sein?
:
Bearbeitet durch User
Marcel A. schrieb: > Sorry, ich meinte A12/A13 auf der PIN-Leiste der AVR-Stamp. Das ist im > obigen Übersichtsbild anders als im AVR Schaltplan. Da ist PG4/PG5 > anderes herum. Bin immer noch verwirrt. Im AVR Schaltplan liegen B8 - A13 - PC5 B9 - A12 - PC4 und am Z180 Schaltplan liegen B8 - A13 B9 - A12 alles so wie in der Beschreibung. > Da müsste B3-B5 doch auch grün sein? ja, dürfen grün sein.
Joe, in der Pin-Leiste ist PIN (Stiftleiste) A12 = PG4 / RTS0 A13 = PG5 / CTS0 Im AVR Schaltplan 1.1 ist aber PIN (Stiftleiste) A12 = PG5 A13 = PG4
Ok, begriffen ich hatte immer nach den Adressen geschaut und nicht nach den Pins der Steckverbinder. A12 und A13 sind nun in der Doku getauscht.
Ich habe mal eine Frage zur Inbetriebnahme..es ist ziemlich schwierig sich durch den ellenlangen Thread zu fräsen.. Ich habe die Version 1.1 von den Platinen, noch keine SD Karte dran, weil mir der Slot auf der AVR-Stamp noch fehlt. Auf der Z180-Stamp befindet sich ein Z8S18020VSG, der war bei mir noch in der Ramschkiste und den gibts wohl auch noch bei Darisus... Die ECB Platine ist mir Einzelschrittmimik bestückt, deshalb habe ich ins bootcmd pin 8 low aufgenommen. Auf dem AVR 1281 befindet sich hexrel6.5, mir ist es aber noch nicht gelungen einen "Piep" vom Z180 zu sehen, werde als nächstes mal testen ob der ein Halt ausführt. Die Versorgung steht jetzt komplett auf 3,3V von der Z180 Stamp, ich hoffe der Z180 läuft da mit 18Mhz und 3,3V noch..? Wie ist das bei hexrel-6.5, ich nehme an der DDTZ ist da noch drin, ist der auf Startadresse 0 so dass ich nach connect mal einen Prompt sehen müßte?
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; pin 8 low; loadf; go ${startaddr}"
|
9 | Hit any key to stop autoboot: 0 |
10 | => printenv |
11 | baudrate=115200 |
12 | bootcmd=reset; pin 8 low; loadf; go ${startaddr}
|
13 | bootdelay=3 |
14 | cpm3_file=1:/cpm3.sys |
15 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
16 | startaddr=0 |
17 | |
18 | Environment size: 188/1597 bytes |
Die seriellen Schlipse sind auch noch nicht dran, bestellt ist das Zeug, hoffe das kommt noch vor dem WE.. edit: mtest und Z180 auf Halt schicken scheint zu funktionieren, warum bekomme ich auf der USB Strippe keine Verbindung? BTW: connect sagt escape char währe ^^ ist aber bei mir ^X ?? Gruß, Holm
> ob der ein Halt ausführt. Die Versorgung steht jetzt komplett auf 3,3V > von der Z180 Stamp, ich hoffe der Z180 läuft da mit 18Mhz und 3,3V > noch..? Laut Datenblatt sollte er. > Wie ist das bei hexrel-6.5, ich nehme an der DDTZ ist da noch drin, ist > der auf Startadresse 0 so dass ich nach connect mal einen Prompt sehen > müßte? Der Prompt kommt defaultmäßig an ASCI1. 115200 Baud bei 18,432MHz. Um die Verbindung zu der AVR-Console zu leiten, mußt Du nach dem loadf das IOBYTE auf RAM-Adresse 3 auf 0 setzen (mm- oder mw.Befehl). > ### main_loop: bootcmd="reset; pin 8 low; loadf; go ${startaddr}" "go ${startaddr}" Die Variable heißt eigentlich "startaddress" und das funktioniert nur mit dem loadcpm3-Befehl (Könnte man auch mal ändern). Also "go 0" stattdessen (in "bootcmd" oder manuell). > startaddr=0 Na gut, wenn in startaddr zufällig 0 steht, gehts auch.
Hmm...
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; pin 2 low 8 low 3 9MHz; loadf; go ${startaddr}"
|
9 | Hit any key to stop autoboot: 0 |
10 | => pin 2 low 8 low 3 9MHz |
11 | => loadf |
12 | Loading Z180 memory... |
13 | From: 0x00000 to: 0x00003 ( 4 bytes) |
14 | From: 0x00008 to: 0x0000A ( 3 bytes) |
15 | From: 0x00010 to: 0x00012 ( 3 bytes) |
16 | From: 0x00018 to: 0x0001A ( 3 bytes) |
17 | From: 0x00020 to: 0x00022 ( 3 bytes) |
18 | From: 0x00028 to: 0x0002A ( 3 bytes) |
19 | From: 0x00030 to: 0x00032 ( 3 bytes) |
20 | From: 0x00038 to: 0x0003A ( 3 bytes) |
21 | From: 0x00040 to: 0x00043 ( 4 bytes) |
22 | From: 0x00050 to: 0x02BE4 (11157 bytes) |
23 | From: 0x02BF4 to: 0x02E64 ( 625 bytes) |
24 | From: 0x02EA7 to: 0x02EA8 ( 2 bytes) |
25 | From: 0x02EEB to: 0x02EEC ( 2 bytes) |
26 | From: 0x02F0F to: 0x02F10 ( 2 bytes) |
27 | => mw 3 0 |
28 | => go 0 |
29 | ## Starting application at 0x0000 ... |
30 | => connect |
31 | Connecting to CPU. Escape character is '^^'. |
...da passiert dann nix mehr. Die DuoLED grinst grün... Das mit dem A17 Pulldown an der Z180 Stamp hatte sich indessen erledigt? Gruß, Holm
> => go 0 > ## Starting application at 0x0000 ... > => connect > Connecting to CPU. Escape character is '^^'. > > ...da passiert dann nix mehr. Die DuoLED grinst grün... Hm, sollte eigentlich so aussehen:
1 | => g 0 |
2 | ## Starting application at 0x0000 ... |
3 | => z80_memfifo_init: 0, 2e67 |
4 | z80_memfifo_init: 1, 2eab |
5 | z80_memfifo_init: 2, 2eef |
6 | z80_memfifo_init: 3, 2f13 |
7 | con |
8 | Connecting to CPU. Escape character is '^^'. |
9 | DDT/Z - HD64180 (ROM) |
10 | > |
> Das mit dem A17 Pulldown an der Z180 Stamp hatte sich indessen erledigt?
Ja.
Nachtrag:
Du könntest versuchsweise auf der ECB-Karte den Jumper JP3 auf 2/3
stecken und über PIN3 einen langsameren Takt einstellen.
:
Bearbeitet durch User
...ich kriege die Männeln... Leo mir ist der Zusammenhang mit den Clocks nicht klar und offensichtlich liegt hier das Problem. Ich habe sowohl ein 18,432Mhz Quarz da liegen als auch mit den Jumpern (JP3 auf ECB und JP1 auf Z180 Stamp) experimentiert. (Joe, bitte...bitte! kennzeichne das nächste Mal jeweils die Position 1 an Steckverbindern und Jumpern, Du kriegst vom Platinenhersteller kein Geld zurück wenn Du das weg läßt!) und habe jetzt irgendwie da durcheinander. Ich habe in dessen irgend ein China PL2303 Viech an Con 3 angeprömpelt und JP5 auf der ECB Platine gesetzt, damit dürfte der MAX abgeschaltet sein. Ich habe nun gemerkt das die Schnittstelle mit 115200 sendet und nicht mit 57600 wie ich erwartet hatte. Mir sind ja etliche Details noch nicht klar und ich dachte die Z180 wird immer mit 18,432 betrieben, CLK0 tut das aber natürlich mit 9,2Mhz... Ich habe jetzt also endlich ein Farbbild:
1 | => conn |
2 | Connecting to CPU. Escape character is '^^'. |
3 | |
4 | > |
5 | > ? |
6 | DDT/Z180 (ROM) Commands: |
7 | > @ examine/substitute the displacement register @ |
8 | > A [address] Assemble |
9 | > B[X] display [or clear] all Breakpoints |
10 | B breakp [:count] [breakp..] set Breakpoints |
11 | BX address [address..] clear Breakpoints |
12 | >>C[N][J] [count] trace over Calls [No lit] [Jumps only] |
13 | C[N][J] W|U expression trace over Calls While|Until ... |
14 | >>D [startadr] [ndadr] Display memory in hex and ascii |
15 | > G [startadr] [;breakp..] Go [to start] [temprary breakpoints] |
16 | > H [expression [expression]] compute expressions / show High/max load adr. |
17 | >I [port] Input a byte from port |
18 | >>L [startadr] [endadr] List disassemled code |
19 | > M[V] startadr endadr destadr Move memory [and verify] |
20 | >>O [byte] [port] Output a byte to port |
21 | > Q[J] startadr endadr bytes Qery memory for byte string [Justified] |
22 | > R[displacement] Read intel hex from console [add displacemt] |
23 | > S address Substitute memory |
24 | >>T[N][J] [count] Trace [No list] [Jumps only] [count steps] |
25 | T[N][J] W|U expression Trace While|Until expression |
26 | > V startadr endadr destadr Veriy (compare) two memory areas |
27 | > X[register] eXamine [and substitute] registers |
28 | >Y[0..9] eXamine [and substitute] Y variables |
29 | > Z startadr endadr bytes Zap (fill) memory with a byte string |
30 | > |
Gruß, Holm
Ich habe noch seltsame Effekte.. Da ich noch einige Z8018010VSC habe, habe ich mal einen von denen in die Fassung gesteckt (und weil der PLCC Zieher in der anderen Werkstatt liegt, darf ich nun die Fassung wechseln :-|). Offensichtlich arbeitet der bei 9Mhz Takt nur mit 4,5Mhz und erzeugt eine Baudrate von 14400 die ich mir nicht angucken kann. Mit 18,4 Mhz vom AVR scheint der aber mit 9,2Mhz zu laufen und 57600 Baud zu erzeugen, während der Z8S18020VSC da 115200 Baud erzeugt, also sehr wahrscheinlich mit 18,4Mhz Takt tackert.. Ist das in Ordnung so? Leo wenn ich die Schnittstelle durch beschreiben des IO Bytes von ASCI1 auf AVR USB umstelle, bekomme ich so lange keine Ausgabe am AVR bis ich auf der ASCI1 nicht wenigstens noch mal Enter gedrückt habe..??? Wo klemmt das denn? Gruß, Holm
Erst mal herzlichen Glückwunsch zu Deinem nun laufenden System. Bei Deinem vorherigen Artikel ist mir nicht ganz klar geworden, ob Du zum Z180-Clock noch konkrete Fragen hast. Die verschiedenen Varianten sind zugegebenermaßen etwas verwirrend. > Z8018010VSC Dem fehlt das S im Typnamen und damit offensichtlich auch das "Clock Multiplier Register", CMR. Also ist der Systemtakt PHI immer (nur) die Hälfte des Input-Clocks EXTAL. > Ist das in Ordnung so? Scheint so. > Leo wenn ich die Schnittstelle durch beschreiben des IO Bytes von ASCI1 > auf AVR USB umstelle, bekomme ich so lange keine Ausgabe am AVR bis ich > auf der ASCI1 nicht wenigstens noch mal Enter gedrückt habe..??? Wo > klemmt das denn? Von welcher Schnittstelle das nächste Zeichen zu lesen ist, wird halt nur beim Eintritt in die Consoleneingaberoutine abgefragt, nicht in der Schleife, die dann den entsprechenden Port pollt.
1 | ?conin: |
2 | ld a,(iobyte) |
3 | and 03h |
4 | jp z,ff.in |
5 | dec a |
6 | jp z,as0inp |
7 | dec a |
8 | jp z,as1inp |
9 | jr nullinput |
10 | |
11 | ... |
12 | |
13 | as1inp: |
14 | in0 a,(stat1) |
15 | rlca |
16 | jr nc,as1inp |
17 | in0 a,rdr1 |
18 | ret |
Naja, die Fragen mit dem Clock sind weitestgehend geklärt, zumindest wurde mir das klar als ich mit dem Oszi geguckt habe was los ist. Problematisch ist halt bei der Erstinbetriebnahme das man nicht weiß wo bei Jumpern oder Steckern gerade die 1 ist, auch ein Blick in die Doku hilft da nicht wirklich. Ich habe mir weiter oben im Thread schon die Augen gebrochen um auf den Bildern raus zu finden wo die Jumper stecken. Den Unterschied Z180 und ZS180 hatte ich vermutet, kirre machen kann eines das aber schon, wenn man im Terminalprogramm nur Sauerkraut angezeigt bekommt weil die Baudrate 28800 oder 14400 als Teil von 57600 einfach mal nicht einstellbar ist, oder wie ich das ich mit 57600 eben keine Daten bekomme weil ich ein Quarz mit 18Mhz gesteckt hatte... Eine Kurz-BDA wäre deshalb wirklich nicht schlecht. Diese Art IO-Byte Auswertung habe ich schon mal wo gesehen (Zapple Monitor?), aber so optimal ist das wohl nicht wenn das Ding auf einer toten Schnittstelle im Kreis herum tritt, ich weiß, man kann sich da ganz leicht zum Ei machen wenn man alle Eventualitäten berücksichtigen will. Danke einstweilen, ich warte jetzt ob die Post die SD Fassungen bringt..oder ich hänge ne Andere mit Drähten freitragend an.. :-) Gruß, Holm
An dem Thema mit den Jumpern bin ich auch schon verzweifelt. Ich baue gerade eine Doku dazu auf (www.retro-compi.de), bin aber noch nicht bei der ECB angekommen (intern schon vorbereitet) mit der Doku.
Marcel A. schrieb: > An dem Thema mit den Jumpern bin ich auch schon verzweifelt. Da muss ich wohl nochmals ran... Aber ihr habt natürlich Recht, für mich ist die Funktion der Jumper ja klar, weil ich sie genau so eingebaut habe.
Ja Joe, ich will keinesfalls nörgeln..aber der Bestückungsdruck ermöglicht doch problemlos z.B. Pin 1 zu kennzeichnen. Das nützt nun zwar rückwirkend nix mehr aber den Nächsten :-) Pollin Paket ist gekommen und der SD Adapter aufgelötet, Karte scheint zu funzen nun muß CP/M drauf. Kann ich irgendwo "disks" mit Programmen schnorren, abgesehen von Turbopascal und Turbo Modula? (BTW: ich bin mir recht sicher früher mit TP 3.02A gearbeitet zu haben, ich finde das sich auch noch, der nächste CP/M Rechner steht rechts neben mir, links liegen die Stamps und viele Disketten habe ich auch noch) der übernächste im Nebenzimmer und der A7150 noch 2 weiter kann auch SCP86(CP/M86)..achso, unterm Tisch steht noch eine P8000... Man bräuchte halt so Power 3.07, M80/L80/Linkmt/Tubo,WS,Irgendwas-C, (BDS gefällt mir wegen den Sourcen..) ggf. ein Basic, einen Reassembler wie Rezilog etc..pp.. Ich habe das Alles da, die cpmutils sind auch installiert, auch simh samt altair... aber Jeder macht die Arbeit immer wieder? Mit CP/M 3.0 habe ich allerdings das erste Mal zu tun. Gruß, Holm
Ich kenne nur TP 3.01a - damit bin ich auf dem PC groß geworden. Und den Rest findet Google, da gibt es tolle Seiten mit endlos Software. Habe bei mir inzwischen vieles zusammengestellt. Nimm dir einfach ein 8mb leeres Images und packe das mit den cpmtools drauf. Ist hier im Thread oder auf meiner HP erklärt.
Ja, 3.01A auf DOS ist mir auch bekannt, ich habe aber die Kiste rechts mal angeworfen: TURBO Pascal system Version 3.02A ..ok, ich mache meinen eigenen Stiefel.. Gruß, Holm
Leo gibts statt z180-stamp-cpm3-0.0.zip ein aktuelles Binary? Ich habs versucht selber zu bauen aber dazu muß ich erst mal den zxcc auf FreeBSD portieren, der erzeugt Müll:
1 | $ zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/M |
2 | |
3 | SLR180 Copyright (C) 1985-86 by SLR Systems Rel. 1.31 #SB3028 |
4 | |
5 | boot/M |
6 | VERSION.INC - Bad Dummy Param Line 00001 |
7 | defvers macro\r\n db '0.6.4.4-dirty'\r\n endm\r |
8 | DEFVERS - Line Too |
9 | jjxqfkjjzwyjlzgjijijpsfgj\d]zuhj\dzuhjx~xrtwjpqhw{fHjjwuywujjnxstrrthjjnxsrh
|
10 | DEFVERS - Line Too Long Line 00002 |
11 | jjxqfkjjzwyjlzgjijijpsfgj\d]zuhj\dzuhjx~xrtwjpqhw{fHjjwuywujjnxstrrthjjnxsrh
|
12 | DEFVERS - Line Too Long Line 00003 |
13 | jjxqfkjjzwyjlzgjijijpsfgj\d]zuhj\dzuhjx~xrtwjpqhw{fHjjwuywujjnxstrrthjjnxsrh
|
14 | DEFVERS - Line Too Long Line 00004 |
15 | .. |
da gibts irgendwelchen Kuddelmuddel in den vfs/statfs Vereinbarungen.. oder aber der slr180 von http://www.classiccmp.org/cpmarchives/cpm/Software/rlee/S/SLR%20SYSTEMS/SLR180/ ist kaputt. ..oder ich muß das unter cpmsim machen.. Gruß, Holm
Ich hoffe, das hier geht. > oder aber der slr180 von > http://www.classiccmp.org/cpmarchives/cpm/Software/rlee/S/SLR%20SYSTEMS/SLR180/ > ist kaputt. Eher nicht. Ich glaube, ich habe den gleichen.
Hier mal der aktuelle Stand meines "Speicherbildes", welches ich im Rahmen meines "CP/M Selbststudiums" unter Leo's Anleitung erstellt habe. Es passt zu folgender Einstellung hinsichtlich BDOS: BNKBIOS3 SPR F900 0500 BNKBIOS3 SPR C600 2A00 RESBDOS3 SPR F300 0600 BNKBDOS3 SPR 9800 2E00 (Leo's aktuelles CPM hat das BDOS erst bei F400, so dass sich ein paar 100 Bytes mehr ergeben für den TPA). Jetzt muss ich noch meine "Hausaufgabe" lösen, warum die top page FE ist statt FF und was in den obersten 256 Bytes steckt. Fudel-Tipps willkommen :-)
:
Bearbeitet durch User
Jungs bitte nochmal zum mitmeisseln: ich habe jetzt im Atmel die 6.5 vdie hier oben verlinkt war. Auf der SD Karte habe ich folgende Files:
1 | Environment size: 275/1597 bytes |
2 | => fatls 1: |
3 | ----A 2016/05/14 12:41 22784 cpm364d.sys |
4 | ----A 2016/05/14 12:50 22016 cpm3.sys |
5 | ----A 2016/05/14 12:50 8388608 cpm3test.dsk |
6 | 3 File(s), 8433408 bytes total |
7 | 0 Dir(s), 489440K bytes free |
das Environment sieht so aus:
1 | => printenv |
2 | baudrate=115200 |
3 | bootcmd=pin 2 low 8 low 3 9MHz; loadcpm 1:/cpm364d.sys; go ${startaddress}
|
4 | bootdelay=3 |
5 | cpm3_file=1:/cpm364d.sys |
6 | dsk0=1:/cpm3test.dsk |
7 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
8 | setenv=cpm3_file 1:cpm364d.sys |
9 | startaddress=d100 |
10 | |
11 | Environment size: 275/1597 bytes |
12 | => |
Der DDTZ wird auf ASCI1 sauber mit 115200 Baud angezeigt wenn geladen, memtest is ok aber weder das cpm3.sys noch das cpm364d.sys (aus dem Zip oben) spucken auf der ASCI0 irgend etwas aus. Wenn ich das richtig verstanden habe muß die Schnittstelle auf 19200 Baud stehen (18Mhz Takt). Ist das richtig?
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="pin 2 low 8 low 3 9MHz; loadcpm 1:/cpm364d.sys; go ${startaddress}"
|
9 | Hit any key to stop autoboot: 0 |
10 | Loading: '1:/cpm364d.sys'... |
11 | |
12 | BNKBIOS3 SPR FA00 0500 |
13 | BNKBIOS3 SPR D100 1F00 |
14 | RESBDOS3 SPR F400 0600 |
15 | BNKBDOS3 SPR A300 2E00 |
16 | |
17 | 61K TPA |
18 | Loaded: Resident: 0x1B400-0x1BEFF, Banked: 0x0A300-0x0EFFF |
19 | ## Starting application at 0xd100 ... |
20 | => printenv |
21 | baudrate=115200 |
22 | bootcmd=pin 2 low 8 low 3 9MHz; loadcpm 1:/cpm364d.sys; go ${startaddress}
|
23 | bootdelay=3 |
24 | cpm3_file=1:/cpm3.sys |
25 | dsk0=1:/cpm3test.dsk |
26 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
27 | startaddress=d100 |
28 | |
29 | Environment size: 241/1597 bytes |
30 | => |
Ich habe eine Weile gekämpft weil ich erstens gedacht hatte das Joe den Fehler mit der "männlichen Belegung" der RS232 Pfostenstecker in der Version 1.1 schon korrigiert hatte..dem war nicht so, dann hatte ich den MAX freundlicherweise verkehrt herum aufgelötet weil das weder aus dem Bestückungsdruck noch aus der PDF zu erkennen war und mir falsch herum halt wahrscheinlicher erschien :-| Der MAX scheint es aber überlebt zu haben weil die ASCI1 nun funktioniert und auf der ASCI0 auch mit dem OSZI an A15/A16 der Z180 Stamp beim besten Willen nichts zu erkennen ist. Funktionieren die beiden cpm.sys Files überhaupt mit der hexrel 6.5 auf dem AVR? Mit dem zxcc bin ich noch nicht viel weiter, ich habe ein olles Debian Wheezy in einer VM ...da ist aber git zu alt und es geht auch nicht weiter. Ich habe noch ein FreeBSD 10.1 32 Bit System und will das dort auch noch mal checken (das läuft noch mit UFS, ich schiebe zxccs Probleme darauf das das ZFS auf meiner Kiste einfach ein Bisschen zu modern für diese Linuxsoftware ist, daher die vfs/statfs Probleme..dürfte zu beheben sein ..aber doch nicht alles auf allen Fronten auf einmal bitte..) ..ich hätte nur gerne mal ein CP/M auf den Stamps booten gesehen damit ich eine Referenz habe auf die ich mich beziehen kann, warum macht Ihr das so kompliziert und warum sind modernere Binaries nicht verfügbar? Ich verstehe es einfach nicht warum ihr nicht ein komplettes "Starterkit" mal irgendwo abwerft. Gruß, Holm
Nimm doch mal die Files von meiner HP, die funktionieren (bei mir). Startadresse D100? Das ist bei mir C600....
Marcel A. schrieb: > Nimm doch mal die Files von meiner HP, die funktionieren (bei mir). ...nicht wirklich, oder? "Not Found The requested URL /mages/retrocompi/z180/avr/stamp-monitor-6.5+8drives-1281.hex was not found on this server. Apache/2.2.22 (Debian) Server at www.retro-compi.de Port 80" Wo finde ich die genau? ...ahh..ok, mit einem "i" mehr siehts besser aus, mal gucken. > > Startadresse D100? Das ist bei mir C600.... Die setzt das cpm354d.sys doch selbst beim Laden ins Environment, daran habe ich doch gar nix geändert. Gruß, Holm
Danke für den Bug Hinweis :-) Und stimmt, in Leos neuer Firmware holt er sich das aus dem sys, die Version nutze ich aber noch nicht.
Ok, ich habs mit Deinen Files cpm3+8drives.sys stamp-monitor-6.5+8drives-1281.hex probiert, geht immernoch nicht. (kein bootlader im AVR, programmiert mit ISP/avrdude)
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="pin 2 low 8 low 3 9MHz; loadcpm ${cpm3_file}; go ${startaddress}"
|
9 | Hit any key to stop autoboot: 0 |
10 | Loading: '1:cpm3+8drives.sys'... |
11 | |
12 | BNKBIOS3 SPR F900 0500 |
13 | BNKBIOS3 SPR C600 2A00 |
14 | RESBDOS3 SPR F300 0600 |
15 | BNKBDOS3 SPR 9800 2E00 |
16 | |
17 | 60K TPA |
18 | Loaded: Resident: 0x1B300-0x1BDFF, Banked: 0x09800-0x0EFFF |
19 | ## Starting application at 0xc600 ... |
20 | => fatls 1: |
21 | ----A 2016/05/14 12:41 22784 cpm364d.sys |
22 | ----A 2016/05/14 12:50 22016 cpm3.sys |
23 | ----A 2016/05/14 12:50 8388608 cpm3test.dsk |
24 | ----A 2016/05/14 20:32 25600 cpm3+8drives.sys |
25 | 4 File(s), 8459008 bytes total# SIMH AltairZ80 Harddisk |
26 | diskdef simhd |
27 | seclen 128 |
28 | tracks 2048 |
29 | sectrk 32 |
30 | blocksize 4096 |
31 | maxdir 1024 |
32 | skew 0 |
33 | boottrk 6 |
34 | os p2dos |
35 | end |
36 | 0 Dir(s), 489408K bytes free |
37 | => printenv |
38 | baudrate=115200 |
39 | bootcmd=pin 2 low 8 low 3 9MHz; loadcpm ${cpm3_file}; go ${startaddress}
|
40 | bootdelay=3 |
41 | cpm3_file=1:cpm3+8drives.sys |
42 | dsk0=1:/cpm3test.dsk |
43 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
44 | startaddress=c600 |
45 | |
46 | Environment size: 246/1597 bytes |
47 | => |
Muß ich mehrere (8) Disks definieren damit das läuft? Ich habe A15 und A16 an der Z180 Stamp mal mit dem Schraubenzieher gebrückt, dann werden die Zeichen aus meinem Terminalprogramm auch geechoet, der Kanal 0 vom Max ist also sowohl Sender als auch Empfängerseitig in Ordnung. jetzt fällt mir langsam nix mehr ein, was könnte ich noch probieren? >Und stimmt, in Leos neuer Firmware holt er sich das aus dem sys, die >Version nutze ich aber noch nicht. ..könntest aber wie es aussieht, denn die c600 hat er auch selber rausgekriegt, das ist also im Lader schon drin. Gruß, Holm
Hm, eigentlich kann man nichts falsch machen... Hast du die Environment Variablen mal so belegt wie bei mir? Und bei mir geht alles mit 18Mhz. Und du lädst ja auch nicht das cpm 8 Drives sondern ein Test.sys?
Uff... es fehlte lediglich dieser Eintrag im Environment: cpm3_commonbase=F000.
1 | CP/M Version 3.0, Z180-Stamp BIOS |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | A>dir |
4 | A: BDOS3 SPR : BNKBDOS3 SPR : CCP COM : COPYSYS COM : CPMLDR REL |
5 | A: DATE COM : DEVICE COM : DIR COM : DUMP COM : ED COM |
6 | A: ERASE COM : GENCOM COM : GENCPM COM : GET COM : HELP COM |
7 | A: HELP HLP : HEXCOM COM : PATCH COM : PIP COM : PUT COM |
8 | A: README : RENAME COM : RESBDOS3 SPR : SAVE COM : SET COM |
9 | A: SETDEF COM : SHOW COM : SID COM : SUBMIT COM : TYPE COM |
10 | A>type readme |
11 | CP/M 3 |
12 | ====== |
13 | |
14 | This archive contains an almost complete build of CP/M 3. |
15 | |
16 | If you have the source distribution, the file making.txt explains how to |
17 | set up the build environment on your computer. |
18 | |
19 | Differences from Digital Research CP/M 3 |
20 | ======================================== |
21 | |
22 | All the CP/M 3 patches described in the document CPM3FIX.PAT have been |
23 | applied to the source code, except those to INITDIR. Patches 1-18 (except |
24 | nos. 5 and 9) were applied. |
25 | |
26 | CP/M 3 is now fully Year 2000 compliant. This affects the programs |
27 | DATE.COM, DIR.COM and SHOW.COM. |
28 | |
29 | Dates can be displayed in US, UK or Year-Month-Day format. This is set by |
30 | SETDEF: |
31 | |
32 | |
33 | Press RETURN to Continue |
..schwere Geburt..
>Und du lädst ja auch nicht das cpm 8 Drives sondern ein Test.sys?
Da haste Dich verguckt.
Gruß,
Holm
Stimmt, na dann, viel Spaß. Sehe gerade, die 9 MHz liegt an deiner CPU ohne Verdoppler?
Marcel A. schrieb: > Stimmt, na dann, viel Spaß. Sehe gerade, die 9 MHz liegt an deiner CPU > ohne Verdoppler? Ich habe JP9 rechts stecken, da kommt wohl 18Mhz vom AVR (ACLK0). Das CP/M behauptet ja auch "Estimated CPU clock [Hz]: 18432000". BTW: Ich habe tinst von Turbopascal angeworfen, VT100 existiert ja als Auswahl da nicht, habe Ansi ausgewählt, scheint erst mal zu funktionieren. Gibts eine bessere Auswahl für ein XTerm?
1 | --------------------------------------- |
2 | TURBO Pascal system Version 3.02A |
3 | CP/M-80, Z80 |
4 | |
5 | Copyright (C) 1983,84,85 BORLAND Inc. |
6 | --------------------------------------- |
7 | |
8 | Terminal: ANSI |
9 | |
10 | |
11 | |
12 | Include error messages (Y/N)? |
Sogar das Highlighting der Menüauswahl klappt ( Dir Quit compiler Options etc). WS3.3 läuft auch, da gibts ja auch vt100 in der Auswahl, werde aber den DDR (Robotron) Clone TP auch mal testen, da sind Druckerdefinitionen für Typenraddrucker drin und ich habe Sowas :-) Nochwas: Ich habe 3 4Gig SD Karten, eine davon MicroSD mit Adapter die problemlos mit den Stamps zu funktionieren scheinen, allerdings weder mit WinXP noch mit meinem FreeBSD über einen Hama Card Reader. Ich bekomme da im Prinzip Device Timeouts. Hat Jemand ne Idee wie ich die zum wirtschaften bekomme? Fehler bekomme ich mit dem fat und sd* Zeug nicht.. kann auch Daten dumpen etc... Ich kann aber z.B. mit dd nix davon lesen oder hinschaffen.. Noch ein Problem: das mkfs.cpm legt ja "sparse" Disks an wie Leo oben schon mal erklärt hat, d.h. wenn die disk nicht voll ist, dann ist die Filesize kleiner als die Diskkapazität. Das führt aber unter CP/M zu Fehlern, mit Power und dem Kommando test kann man eine ganze Disk probelesen und eine Checksumme generieren, promt hagelt das Fehler. dieses mkfs.cpm ist wohl daher eher mit vorsicht zu genießen, bei mir ist das z.B. auch nicht in der Lage auf einer Floppy ordentlich zu arbeiten, wahrscheinlich kommt das genau von diesem "Feature". Kopiert lieber die cpm3 Testdisk und macht die unter CP/M dann mit Erase leer..
1 | 00030: 84 a5 9e 2e 33 f5 76 5d 7a c8 68 78 e6 cf 3c 03 ....3.v]z.hx..<. |
2 | Read Data |
3 | 00000: 9a 75 d8 8c ab c4 56 70 cb 85 b4 5a 0d 7f 61 33 .u....Vp...Z..a3 |
4 | 00010: bc 98 c0 51 45 e2 f7 43 34 2d 1a 8b 62 a8 fc 76 ...QE..C4-..b..v |
5 | 00020: 00 25 bc ac 38 e3 6e 2f 9b d5 a7 22 bd c8 4d db .%..8.n/..."..M. |
6 | 00030: 84 a5 9e 2e 33 f5 76 5d 7a c8 68 78 e6 cf 3c 03 ....3.v]z.hx..<. |
7 | Read Data |
8 | 00000: 9a 75 d8 8c ab c4 56 70 cb 85 b4 5a 0d 7f 61 33 .u....Vp...Z..a3 |
9 | 00010: bc 98 c0 51 45 e2 f7 43 34 2d 1a 8b 62 a8 fc 76 ...QE..C4-..b..v |
10 | 00020: 00 25 bc ac 38 e3 6e 2f 9b d5 a7 22 bd c8 4d db .%..8.n/..."..M. |
11 | 00030: 84 a5 9e 2e 33 f5 76 5d 7a c8 68 78 e6 cf 3c 03 ....3.v]z.hx..<. |
12 | Read Data |
13 | 00000: 9a 75 d8 8c ab c4 56 70 cb 85 b4 5a 0d 7f 61 33 .u....Vp...Z..a3 |
14 | 00010: bc 98 c0 51 45 e2 f7 43 34 2d 1a 8b 62 a8 fc 76 ...QE..C4-..b..v |
15 | 00020: 00 25 bc ac 38 e3 6e 2f 9b d5 a7 22 bd c8 4d db .%..8.n/..."..M. |
16 | 00030: 84 a5 9e 2e 33 f5 76 5d 7a c8 68 78 e6 cf 3c 03 ....3.v]z.hx..<. |
17 | Read Data |
18 | 00000: 9a 75 d8 8c ab c4 56 70 cb 85 b4 5a 0d 7f 61 33 .u....Vp...Z..a3 |
19 | 00010: bc 98 c0 51 45 e2 f7 43 34 2d 1a 8b 62 a8 fc 76 ...QE..C4-..b..v |
20 | 00020: 00 25 bc ac 38 e3 6e 2f 9b d5 a7 22 bd c8 4d db .%..8.n/..."..M. |
21 | 00030: 84 a5 9e 2e 33 f5 76 5d 7a c8 68 78 e6 cf 3c 03 ....3.v]z.hx..<. |
22 | ------------------------------------------- |
23 | G=0097:0C T=0157 S=013 PS=012 Rec# 493 |
24 | * - bad sector on |
25 | G=0097:0D T=0157 S=014 PS=013 Rec# 494 |
26 | * - bad sector on |
27 | G=0097:0E T=0157 S=015 PS=014 Rec# 495 |
28 | * - bad sector on |
29 | G=0097:0F T=0157 S=016 PS=015 Rec# 496 |
30 | * - bad sector on |
31 | G=0097:10 T=0157 S=017 PS=016 Rec# 497 |
32 | * - bad sector on |
33 | G=0097:11 T=0157 S=018 PS=017 Rec# 498 |
34 | * - bad sector on |
Gruß, Holm
Holm T. schrieb: > Ich habe eine Weile gekämpft weil ich erstens gedacht hatte das Joe den > Fehler mit der "männlichen Belegung" der RS232 Pfostenstecker in der > Version 1.1 schon korrigiert hatte..dem war nicht so Wo ist das Problem? Die Belegung ist doch korrekt. Auf die Wannenstecker kommen Crimp-Buchsen mit Flachbandkabel welches wiederum genau an die 9-poligen SUB-D (male) passen. CON0 und CON1 sind jeweils ein DTE.
Joe G. schrieb: > Holm T. schrieb: >> Ich habe eine Weile gekämpft weil ich erstens gedacht hatte das Joe den >> Fehler mit der "männlichen Belegung" der RS232 Pfostenstecker in der >> Version 1.1 schon korrigiert hatte..dem war nicht so > > Wo ist das Problem? Die Belegung ist doch korrekt. Auf die Wannenstecker > kommen Crimp-Buchsen mit Flachbandkabel welches wiederum genau an die > 9-poligen SUB-D (male) passen. CON0 und CON1 sind jeweils ein DTE. Dann hatte ich Dich mißverstanden. Ist aber auch egal, ich habe jetzt 2x Male dran und Null-Modem Kabel. Da ist aber gar kein Problem.. :-) Gruß und vielen Dank für Deine Arbeit, Holm
Holm T. schrieb: > BTW: Ich habe tinst von Turbopascal angeworfen, VT100 existiert ja als > Auswahl da nicht, habe Ansi ausgewählt, scheint erst mal zu > funktionieren. anbei ein TP3 für VT100 (dsk-File)
Joe G. schrieb: > Holm T. schrieb: >> BTW: Ich habe tinst von Turbopascal angeworfen, VT100 existiert ja als >> Auswahl da nicht, habe Ansi ausgewählt, scheint erst mal zu >> funktionieren. > > anbei ein TP3 für VT100 (dsk-File) Danke, ich probiere es mal, kannst ja das hier mal checken: http://www.tiffe.de/Robotron/Stamp/tp-3.02a.dsk.gz ...was mache ich denn hier schon wieder flashc?
1 | A>c: |
2 | C>device conout:=ASCI0[38400] |
3 | |
4 | �1!��!9�/��/0 1�#�=�� |
5 | �B��B!��Rj� �B�!�"wc� |
6 | |
7 | �)k�)�k9�� |
8 | � |
9 | @�"���Ox�J |
10 | � |
11 | @�"��Ox�B |
12 | |
13 | x����! |
14 | |
15 | �� |
16 | C>device conout:=ASCI0[57600] |
17 | |
18 | CONOUT:=ASCI0[57600] |
19 | ^ |
20 | Error at the '^'; Invalid option |
21 | |
22 | C> |
..das ist das von Leo überarbeitete device.com, nach den 38400 habe ich den Terminalemulator umgestellt, das erste Mal funzt, 57600 aber nicht..? Gruß, Holm
Holm T. schrieb: > Danke, ich probiere es mal, kannst ja das hier mal checken: Geht gerade nicht, kein CP/M dabei. Komme morgen erst wieder dazu.
Zu Device: schau mal ganz oben im Thread, leo hat das intern umbewertet. 134 steht für 115200... Und als erstes kommt z.B. "Xon,134"
...am abgesehen vo nder Sache mit dem scb Program.. das sollte doch mit Device alleine gehen?
1 | C>device |
2 | |
3 | Physical Devices: |
4 | I=Input,O=Output,S=Serial,X=Xon-Xoff |
5 | USB0 NONE IO ASCI0 38400 IOS ASCI1 19200 IOS |
6 | |
7 | |
8 | Current Assignments: |
9 | CONIN: = ASCI0 |
10 | CONOUT: = ASCI0 |
11 | AUXIN: = ASCI0 |
12 | AUXOUT: = ASCI0 |
13 | LST: = Null Device |
14 | |
15 | Enter new assignment or hit RETURN |
16 | |
17 | |
18 | C>device conout:=asci0[134] |
19 | |
20 | CONOUT:=ASCI0[134] |
21 | ^ |
22 | Error at the '^'; Invalid option |
23 | |
24 | C>device conout:=asci0[xon,134] |
25 | |
26 | CONOUT:=ASCI0[XON,134] |
27 | ^ |
28 | Error at the '^'; Invalid option |
29 | |
30 | C> |
Verstehschni. Edit: Alles Blödsinn, geht doch
1 | A>device conout:=asci0[115200] |
2 | |
3 | Physical Devices: |
4 | I=Input,O=Output,S=Serial,X=Xon-Xoff |
5 | USB0 NONE IO ASCI0 115200 IOS ASCI1 19200 IOS |
6 | |
7 | |
8 | Current Assignments: |
9 | CONIN: = ASCI0 |
10 | CONOUT: = ASCI0 |
11 | AUXIN: = ASCI0 |
12 | AUXOUT: = ASCI0 |
13 | LST: = Null Device |
14 | |
15 | |
16 | A> |
Gruß, Holm
> ...aber 57600 geht halt nicht.
Sorry, da war ein Zahlendreher drin. Mit 56700 (oder 5 oder 56 ...)
könntest Du die 57600 einstellen. Oder das Update aus dem Anhang hier
nehmen.
Kleines Update der Monitorsoftware. Holm T. schrieb: > Uff... es fehlte lediglich dieser Eintrag im Environment: > cpm3_commonbase=F000. Der Wert wird jetzt aus dem cpm3.sys Image ausgelesen und automatisch gesetzt. Das war ja schon lange versprochen (Beitrag "Re: Z180-Stamp Modul"). Wer die Singlestep-Logik auf der Basisplatine hat, kann eine Environment-Variable auf "True" setzten, damit die Pins für RUN und STEP automatisch initialisiert werden: "singlestep=1" Eine automatische Erkennung der Schaltung ist leider zu aufwendig und hat möglicherweise unerwünschte Seiteneffekte. Unterstützung für die Singlestep-Logik gibts aber immer noch nicht. Die RTC sollte jetzt auch den Jahreswechsel korrekt mitmachen. (Der nächste ist ja schon nicht mehr weit.)
1 | leo@cb:~/Projekte/HD64180/z180-stamp$ git log --oneline hexrel-6.5.. |
2 | b51d236 Get common_base from cpm3.sys file. Update default environment (BOOTCMD) |
3 | 8ed6601 Store only command line input in history buffer, but not data (i.e mm command) |
4 | c647afc Enable commandline editing with history buffer parmanently, and remove macro CONFIG_CMDLINE_EDITING and the non-history-buffer code. |
5 | f32690e Remove redundant hist_init() |
6 | 5730789 Use timer 4 instead of 3 for systick (1ms). |
7 | a1595a8 Init ports for single step logic on ECB adapter. Use timer 5 instead of timer 4 for timeouts. |
8 | be84a70 New function: getenv_yesno() |
9 | 19a463f Bufix mstep command: take the right arg for parameter count. |
10 | d9d8de4 Handle bus errors in md command |
11 | 6353e86 Bugfix z80_addrbus_set_tristate() |
12 | 1b77fa4 Rename getenv() to getenv_char() |
13 | f3e47f6 Add build configuration for ATmega2561 |
14 | 85046f8 RTC: Handle turn of the year correctly, detect uninitialized RTC (loss of VBAT) |
15 | aca998c cli.c: bugfix in cli_parse_line(): correct nargs |
Leo C. schrieb: >> ...aber 57600 geht halt nicht. > > Sorry, da war ein Zahlendreher drin. Mit 56700 (oder 5 oder 56 ...) > könntest Du die 57600 einstellen. Oder das Update aus dem Anhang hier > nehmen. Danke Leo, ich werds mal checken. Gruß, Holm
Holm T. schrieb: > Leo C. schrieb: >>> ...aber 57600 geht halt nicht. >> >> Sorry, da war ein Zahlendreher drin. Mit 56700 (oder 5 oder 56 ...) >> könntest Du die 57600 einstellen. Oder das Update aus dem Anhang hier >> nehmen. > > Danke Leo, ich werds mal checken. > > Gruß, > > Holm Ok, Device funtkioniert und auch der stampmonitor ohne cpm3_commonbase. Letzteren habe ich aber wieder zurück geflasht wegen der 8 Laufwerke, ich muß nun mal zusehen das ich die Buildumgebung zum Laufen bekomme. Gruß, Holm
Leo C. schrieb: > Kleines Update der Monitorsoftware. Danke Leo, läuft bei mir.Nun auch ohne cpm3_commonbase=F000 und mit "singlestep=1". Auch "Device" macht was es soll. Den Zahlendreher hatte ich nicht bemerkt, da ich 57600 nie benutzt hatte. Gibt es eine Auflistung der vordefinierten Environment-Variablen. Dann könnte ich sie in die Doku aufnehmen.
Wo bekommt man denn eigentlich diese Frontplatten für die ECB-Bus Karten inklusive Winkel? Ich habe noch ein kleines Gehäuse da von einem Hirschmann HUB.. (wie Ebay 371192627387) @Marcel: machst Du von der 6.6er Version mal ein Binary mit 8 LW? Gruß, Holm
Holm T. schrieb: > @Marcel: machst Du von der 6.6er Version mal ein Binary mit 8 LW? Kann ich mal schauen. War aber glaube ich nicht schwer, da gibts einen Parameter (drive_max oder so im Monitor). Hatte mir Leo mal erklärt. Aber wie gesagt, das cpm.sys muss dazu passen, und das kann ich (noch) nicht übersetzen.
Holm T. schrieb: > Letzteren habe ich aber wieder zurück geflasht wegen der 8 Laufwerke, 4 drives on sd cards ought to be enough for anybody. ;) Die Zuweisung der Images über Environment-Variablen halte ich für ein Provisorium, daß längst durch etwas Besseres ersetzt hätte werden sollen. Deshalb wollte ich das nicht auf mehr Laufwerke ausbauen. Leider komme ich aber nicht dazu, das Provisorium zu ersetzen. Wenn jetzt immer mehr Leute nach 8 Laufwerken "schreien", muß das vielleicht doch mal zum "Standard" machen. Aber ehrlich, was will will man eigentlich mit 8 mal 8 MByte unter CP/M? In CP/M 3 werden die Userbereiche ganz gut unterstützt. Man kann die Dateien auf einer Disk also auf 16 User verteilen.
Leo C. schrieb: > Holm T. schrieb: >> Letzteren habe ich aber wieder zurück geflasht wegen der 8 Laufwerke, > > 4 drives on sd cards ought to be enough for anybody. ;) You are failing badly :-) > > Die Zuweisung der Images über Environment-Variablen halte ich für ein > Provisorium, daß längst durch etwas Besseres ersetzt hätte werden > sollen. Deshalb wollte ich das nicht auf mehr Laufwerke ausbauen. Leider > komme ich aber nicht dazu, das Provisorium zu ersetzen. Wenn jetzt immer > mehr Leute nach 8 Laufwerken "schreien", muß das vielleicht doch mal zum > "Standard" machen. > > Aber ehrlich, was will will man eigentlich mit 8 mal 8 MByte unter CP/M? > In CP/M 3 werden die Userbereiche ganz gut unterstützt. Man kann die > Dateien auf einer Disk also auf 16 User verteilen. Dir kann bei Deinen Fragen geholfen werden: Die Userbereiche unter CP/M sind etwas sperrig zum arbeiten, die meisten Programme unterstützen zwar eine Laufwerksangabe, aber keine User Nummer als "Pfad", leider gab es noch keine Directories wie unter Unixoiden, Billyboy (der alte Pariser) hat die ja auch nur da abgeguckt. Es gibt keine austauschbaren Datenträger aus CP/M Sicht, deshalb ist es sinnvoll eine Auswahl von Programmen gleichzeitig auf den Disketten zu haben. Der Fakt, das ein Drive 8Mbyte groß ist ist dabei eher sekundär, die Drives sind nicht voll und die SD Karten noch lange nicht. Ich habe jetzt auf 0: 6 Laufwerke und auf 1: nur 2, 0 steckt ja später mal im Gerät und ist eher schlecht austauschbar, 1: halt an der Front als Wechseldatenträger zum Datentransfer. Ich vermisse jetzt schon meine K1520Net Netzwerkkarte... hast Du evtl. noch Ambitionen Joe? Das interessiert mich deutlich mehr als eine VGA und ein Tastaturanschluß, Letzteres wird nicht kleiner/besser als ein oller Schleptopp der das mit putty o.ä. ganz hervorragend und auch i.A. billiger macht. Bitte ersetze nicht die Laufwerkszuordnung im Environment durch was Besseres, das ist nämlich schon das Beste. Gruß, Holm
Marcel A. schrieb: > Holm T. schrieb: >> @Marcel: machst Du von der 6.6er Version mal ein Binary mit 8 LW? > > Kann ich mal schauen. War aber glaube ich nicht schwer, da gibts einen > Parameter (drive_max oder so im Monitor). Hatte mir Leo mal erklärt. > Aber wie gesagt, das cpm.sys muss dazu passen, und das kann ich (noch) > nicht übersetzen. Ich würde das gerne selber machen wollen, aber gegenwärtig läuft auf meinem präferierten Host-OS der Assembler mit dem zxcc noch nicht. Das wird noch seine Zeit dauern da ich erst mal wieder Programmierarbeiten erledigen muß um Brötchen zu verdienen... Gruß, Holm
Joe G. schrieb: > Gibt es eine Auflistung der vordefinierten Environment-Variablen. Dann > könnte ich sie in die Doku aufnehmen. So siehts bei 6.6 gerade aus:
1 | Name Typ Default "defaultenv" |
2 | --------------------------------------------------------------------------------------------------------------------- |
3 | baudrate Dezimal "115200" "115200" |
4 | bootcmd String - "pin ${pins}; loadcpm3; go ${startaddress}"
|
5 | bootdelay Dezimal "4" "3" |
6 | cpm3_bankedbase Hex "0" |
7 | cpm3_commonbase Hex - |
8 | cpm3_file String "0:/cpm3.sys" "0:/cpm3.sys" |
9 | dsk0 ... dsk4 String - |
10 | esc_char Hex "1E" |
11 | pin_alias String - "0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7" |
12 | pins String - "2,8 low 9 high 3 2" |
13 | singlestep Bool - |
14 | startaddress Hex - "0" |
Die Spalte Default wird genommen, wenn die entsprechende Variable nicht existiert. Die Variablen werden mit der Spalte defaultenv vorbelegt, wenn beim Start das EEPROM leer oder korrumpiert ist (der Inhalt ist mit einer CRC16 abgesichert), oder der Befehl "defaultenv" ausgeführt wird. Bool-Variablen (singlestep) sind "wahr", wenn sie existieren und das erste Zeichen "1" oder "y" oder "Y" oder "t" oder "T" ist, sonst "unwahr". cpm3_commonbase und startadress werden durch loadcpm3 gesetzt bzw. überschrieben.
Holm T. schrieb: > Die Userbereiche unter CP/M sind etwas sperrig zum arbeiten, Bis CP/M 2.2 war das "Feature" unbrauchbar, aber in 3 ist es deutlich besser geworden. > Es gibt keine austauschbaren Datenträger aus CP/M Sicht, deshalb ist es > sinnvoll eine Auswahl von Programmen gleichzeitig auf den Disketten zu > haben. Die 4 (oder 8 oder 16) ist ja auch nicht die maximale Anzahl an Images auf der SD-Karte, sondern die maximale Anzahl "Disketten", die gleichzeitig im Zugriff sein können. "Herkömmliche" CP/M-Systeme hatten da meistens nur 2. Man kann ja beliebig viele Images auf einer Karte haben, und durch ändern einer Environment-Variablen eine Disk wechseln (Danach Control-C nicht vergessen, wie bei CP/M < 3). > Bitte ersetze nicht die Laufwerkszuordnung im Environment durch was > Besseres, das ist nämlich schon das Beste. Es wäre gut genug, wenn man beim Ändern einer Variablen eine Aktion auslösen könnte. Dann könnte man dem CP/M 3 nämlich Bescheid stoßen, damit es die "gewechselte" Disk ohne Control-C einloggen könnte. Aber wie oben angedeutet, werde ich die 8 wohl in den master-branch übernehmen...
Leo C. schrieb: > Holm T. schrieb: >> Die Userbereiche unter CP/M sind etwas sperrig zum arbeiten, > > Bis CP/M 2.2 war das "Feature" unbrauchbar, aber in 3 ist es deutlich > besser geworden. Mir geht es nicht so sehr um das CP/M, sondern um die Programme die ich da laufen lasse. Bisher habe ich oft den M80 benutzt und da wirds wohl Brühe wenn der auf User 0 sitzt und die zu assemblierenden Dateien auf User 14.. > >> Es gibt keine austauschbaren Datenträger aus CP/M Sicht, deshalb ist es >> sinnvoll eine Auswahl von Programmen gleichzeitig auf den Disketten zu >> haben. > > Die 4 (oder 8 oder 16) ist ja auch nicht die maximale Anzahl an Images > auf der SD-Karte, Ich weiß. > sondern die maximale Anzahl "Disketten", die > gleichzeitig im Zugriff sein können. "Herkömmliche" CP/M-Systeme > hatten da meistens nur 2. ..aber eben recht einfach auszutauschen. Ich brauche nicht Assembler, Tubopascal, BDS und Hitech-C gleichzeitig im Eingriff..aber doch dann und wann. Die Kiste rechts neben mir hat 2 Floppies, eine Ramdisk die A nach M verdrängt und dann selbst A ist und 3 Festplattenpartitionen a 8 MB auf einer 20MB MFM Pladde.. > Man kann ja beliebig viele Images auf einer Karte haben, und durch > ändern einer Environment-Variablen eine Disk wechseln (Danach Control-C > nicht vergessen, wie bei CP/M < 3). > >> Bitte ersetze nicht die Laufwerkszuordnung im Environment durch was >> Besseres, das ist nämlich schon das Beste. > > Es wäre gut genug, wenn man beim Ändern einer Variablen eine Aktion > auslösen könnte. Dann könnte man dem CP/M 3 nämlich Bescheid stoßen, > damit es die "gewechselte" Disk ohne Control-C einloggen könnte. Das würde eine Sonderbehandlung der Environmentvariablen für dsk? erfordern, aber unmöglich ist es nicht. Es erspart im Endeffekt wirklich nur das ^c, weiß nicht ob das lohnt.. > > Aber wie oben angedeutet, werde ich die 8 wohl in den master-branch > übernehmen... :-) Gerne. Es hat kaum Nachteile, nur das BIOS wird größer und da wir hier CP/M 3.0 haben gibts da Reserven. Gruß, Holm
..irgendwie habe ich beim Bearbeiten nun 3 Mal das Selbe geschrieben das aber nicht im Text auftaucht, also hier nochmal einzeln. Ich würde es für besser halten ein CP/M Programm zu haben das die Zuordnung der Images zu den Drives bewerkstelligt (assign "BDS-C1.dsk" "C") und evtl. ein Programm das das Inhaltsverzeichnis und das aktuelle Assignment ausgibt, oder Beides in einem. Die AVR-Console ist eigentlich nur die Firmware des "Festplattencontrollers", mit dem Ding würde ich gerne nur reden wollen wenn ich was grundsätzlich zu ändern habe, zu Wartungszwecken halt. Gruß, Holm
Holm T. schrieb: > Ich vermisse jetzt schon meine K1520Net Netzwerkkarte... hast Du evtl. > noch Ambitionen Joe? An Ambitionen mangelt es nicht, mehr an der Zeit. Zunächst ist ja noch die USB-Schnittstelle in der Pipeline.
Hmm, ich weiß schon, Useless Serial Bus finden die Leute fetzig, ich eher nicht oder nur schaumgebremst, aber das ist eine persönliche Macke von mir. Ich finde es halt Klasse wenn ich ohne irgendwelchem Kram an- oder abzuprömpeln Dateien vom Host holen oder Daten da hin schicken kann :-) USB Sticks findet meine Frau immer total vergammelt unter der Wäschespinne, die letzten Beiden gehen trotz deutlicher Korrosion und Verformungen aber immer noch.. :-| Das ist mir mit Netzwerkkabeln noch nie passiert. :-) Zur Netzwerkkarte: Die Hardwareunterlagen sind ja öffentlich, im Endeffekt sitzt da auch ein AVR und ein Wiznet Modul drauf, nur das Bussystem ist halt derzeit nicht ECB mit DIN Steckern sondern DDR K1520 Bus ..was aber nur ein mechanischer Unterschied ist. Das Ganze ist über eine PIO am System angebunden (weiß nicht wie die Lage mit 18 Mhz-fähigen PIOs in PLCC so aussieht) und die Firmware für den AVR gibts momentan nach Zusendung einer Ethernetadresse (z.B. von einer ollen PC Netzwerkkarte) von susowa (dem Autor) per Mail. Susowa wird sich sicherlich nicht gegen eine Anpassung sperren. http://susowa.homeftp.net/index.php/projekte-mainmenu/kcnet-mainmenu-130/87-nachnutzung.html Wobei K1520Net die Variante für das DDR K1520 OEM Sysstem und KCNet die Varaiante für den KC85 ist. Nur als Info gedacht.. Gruß, Holm
> Bisher habe ich oft den M80 benutzt und da wirds wohl > Brühe wenn der auf User 0 sitzt und die zu assemblierenden Dateien auf > User 14.. Eben nicht. CP/M 3 User’s Manual, 2.7.1 File Attributes:
1 | A file with the SYS attribute has a special advantage when it is created under user 0. When you give a file with |
2 | user number 0 the SYS attribute, you can read and execute that file from any user number. This feature gives |
3 | you a convenient way to make your commonly used programs available under any user number. |
und 4.4.2 Finding Program Files:
1 | The search procedure for a program file can be very different from a data file search. This is because you can |
2 | use the SETDEF command described in Section 5 to define the search procedure you want CP/M 3 to follow |
3 | when it is looking for a program file. With SETDEF you can ask CP/M 3 to make as many as sixteen searches |
4 | when you do not include a drive specifier before the command keyword, but that is a rare case! |
5 | |
6 | ... |
7 | |
8 | When you use a SETDEF command to define your own drive chain, include the default drive, and the drive that |
9 | contains your most frequently used utilities. For an example, assume you defined your drive chain as * (the |
10 | default drive) and drive A. |
11 | |
12 | When you enter the following command: |
13 | |
14 | 2D>SHOW [SPACE] |
15 | |
16 | CP/M 3 looks for SHOW.COM in the following sequence: |
17 | |
18 | 1. drive D, user 2 |
19 | 2. drive D, user 0 |
20 | 3. drive A, user 2 |
21 | 4. drive A, user 0 |
> Das würde eine Sonderbehandlung der Environmentvariablen für dsk? > erfordern, Oder eine allgemeine Erweiterung, daß man an Variablen "Callback-Funtionen" anhängen kann. Dann könnte man z.B. auch die Baudrate ändern, wenn die entsprechende Variable gesetzt wird. Weitere Anwendungen fallen mir aber nicht ein, und deshalb habe ich es auch nicht eingebaut. Holm T. schrieb: > Ich würde es für besser halten ein CP/M Programm zu haben das die > Zuordnung der Images zu den Drives bewerkstelligt (assign "BDS-C1.dsk" > "C") und evtl. > ein Programm das das Inhaltsverzeichnis und das aktuelle Assignment > ausgibt, oder Beides in einem. In die Richtung assign- oder mount-Funktion sollte es gehen. Wenn die Funktion im AVR-Monitor vorhanden ist, kann sie auch von CP/M über das vorhandene (bzw. dann zu erweiternde) Protokoll aufgerufen werden.
Ich werde mich mal damit beschäftigen Leo, wie schon mal erwähnt, mit CP/M3 habe ich das erste Mal zu tun. Nochmal zur Hardware..etwas Bauchschmerzen macht mir der nicht getriebene, doch relativ schnelle Bus. Ich habe gerade mal ein Bisschen herumgegoogelt, schnellere PIOs als 10Mhz habe ich auch nicht gefunden, hat Jemand da schon mal welche auf freier Wildbahn gesehen? Man müßte dann den PIO mit halber Taktfrequenz betreiben, müßte eigentlich funktionieren, hat das schon mal Jemand gemacht? Gruß, Holm
Hallo holm, für die Dateiübertragung vom PC direkt in das CPM nutze ich Kermit. Habe ich hier gerade mal beschrieben: http://retro-compi.de/index.php/z180-stamp/z180-anwendungen/z180-anwendungen-kermit Ansonsten setze ich große Hoffnungen auf Joes Vinculum. Eine Netzanbindung hatte ich auch schon einmal testweise. Dazu kann man ja einen wenige Euro günstigen Seriell-(W)LAN-Wandler nehmen, der die serielle Schnittstelle in Telnet umsetzt. Zum Spaß hatte ich das mal mit dem AVR Net-IO und angepasster Firmware gemacht (Pollin) - hat aber nur "prinzipiell" funktioniert und ich habe das (noch) nicht weiterverfolgt. Denn auch mein Problem ist, dass ich im echten Leben Brötchen verdienen muss :-) Gruß Marcel
Ja klar, Hobby und Spielzeug bleibt das allemal, in so fern haben sich die Prioritäten zu sortieren... Kermit etc. ist mir bekannt, Sowas benutze ich auch teilweise, aber ich finde halt die Möglichkeit ftp/tftp und telnet vom CP/M Rechner aus benutzen zu können interessant, das ist doch deutlich flexibler als Kermit oder die Stöpselei von USB Sticks. IMHO hatten die Jungs auch die DDR Bürocomputer PC1715 oder A5120 diskless mit der Karte gebootet. Ich Freund von mit hat sich gemeldet, er hat wohl noch 100 Stück 16Mhz PLCC PIOs die er mal für ein mittlerweile verstorbenes Forenprojekt von Robotrontechnik.de in Singapur (er ist Seemann) gekauft hatte, da liegen und steckt mir 2 in einen Brief. Ich kann damit mal probieren ob ich die K1520Net Karte ohne Änderungen mit 18,432Mhz zum Laufen bekomme, muß da nochmal mit den Machern der Karte konferieren. Der K1520 Bus ist im wesentlichen das Selbe wie der ECB Bus, nur halt mit anderem Layout. Es gibt auch andere ähnliche Projekte für DDR Computer, z.B: die sogenannte GUN Platine für den PC1715..(Gide, USB, Netzwerk), das ist nur alles nicht für so irre Taktfrequenzen ausgelegt. Auch da werkelt ein Vinculum bzw. der VNC2-32. Freilich hat das Alles Zeit. Gruß, Holm
Auf vielfachen Wunsch hier die 8-drive Version von Monitor und Bios. Genaugenommen ist es sogar eine 12-drive Version, wenn man ein IDE-Gerät dran hat. Holm T. schrieb: > Es hat kaum Nachteile, nur das BIOS wird größer und da wir hier CP/M 3.0 > haben gibts da Reserven. Der Platz, der für alloc und checksum vector drauf geht, ist schon beachtlich. Die Anzahl freier Pages in Bank 0 ging von 75 auf 63, also um 3 KB runter. Also bis zu 6 Directory-Buffer weniger. Schön wärs, wenn man den Platz dynamisch zuordnen könnte, vor allem wenn man noch größere Laufwerke zulassen möchte. CP/M 3 unterstützt ja bis zu 512 MByte. Aber das ist wohl ein Job für jemanden, der sonst nichts zu tun hat. Falls jemand das CF-Interface von oben (Beitrag "Re: Z180-Stamp Modul") nachbauen will: im Schaltplan fehlt noch eine Verbindung von /DREQ1 (15a am ECB) nach GND, da der DMA1 für den Datentransfer verwendet wird. Besser wäre natürlich, wenn man die Verbindung über einen Port ein- und ausschalten könnte, damit der DMA-Kanal auch noch für andere Geräte genutzt werden kann. Möglicherweise reicht aber auch eine Verknüpfung mit DASP.
Fein, probier ich am WE aus. Das hex ist vermutlich für den 1281? D.h. für den 2561 erstelle ich mir das mit der richtigen tup-variante aus dem aktuelle GIT Repository am besten selber? Das CPM.SYS ist davon ja unabhängig. Danke!
@all Wo bekomme ich denn aktuell noch eine ECB-Bus Backplane gekauft? Google war nicht sehr gesprächig. Gruss Peter
@Marcel Danke für die Antwort. Bei den Messer-, Federl. DIN 41612 bin ich gewesen, auf Laborkarte wäre ich nun nicht gekommen. Gruss Peter
http://www.ebay.de/itm/Eurokarten-Bus-Patine-Cross-Europlatine-mit-Stecker-vergoldene-Konnektoren-/191873066629?hash=item2cac86a685:g:gYoAAOSwdV1XOKPk http://www.ebay.de/itm/Populated-64-96-Way-DIN-41612-Eurocard-Connector-Backplane-RS-435-327-/391443027085?hash=item5b23d2948d:g:IDMAAOSwMVFXH7Q5 Unter "VME backplane" findet man noch einiges. Das Meiste aber sehr teuer.
Holm T. schrieb: > Zur Netzwerkkarte: > > Die Hardwareunterlagen sind ja öffentlich, im Endeffekt sitzt da auch > ein AVR und ein Wiznet Modul drauf, nur das Bussystem ist halt derzeit > nicht ECB mit DIN Steckern sondern DDR K1520 Bus ..was aber nur ein ... > http://susowa.homeftp.net/index.php/projekte-mainmenu/kcnet-mainmenu-130/87-nachnutzung.html Die Netzwerkkarte sieht im wesentlichen so aus:
1 | (ECB) |
2 | Bus |
3 | | |
4 | |<===> PIO <===> ATmega162 <===> WIZnet <---> RJ45 (1) |
5 | | |
6 | |<===> Z(1)80 |
7 | | |
Nur die obere Zeile, die untere soll das Rest-System darstellen. Der ATmega reicht die Daten 1:1 durch. Er dient nur dazu, die Schnittstelle des WIZnet-Chips an die PIO anzupassen und die MAC-Adresse der Karte zu speichern. PIO und ATmega kann man imho getrost weglassen, und den WIZnet direkt an den Bus anschließen. Der benötigte Adressdecoder ist in etwa der gleiche. Das sähe dann so aus:
1 | ECB |
2 | Bus |
3 | |<===> WIZnet <---> RJ45 (2) |
4 | | |
5 | |<===> Z(1)80 |
Der Chip könnte auch über seine SPI-Schnittstelle an CSI/O der Z180 angeschlossen werden. Nachteil: Da die CSI/O-Schnittstelle kein richtiges SPI kann, könnte es evtl. Probleme geben. Man müßte irgendwoher ein CS-Signal zaubern. Relativ lansam, max CPU-Takt/20.
1 | ECB |
2 | |<===> Z180-CSI/O <--SPI--> WIZnet <---> RJ45 (3) |
Falls ein Atmega dem Z180 doch noch Arbeit abnehmen könnte, sollte man das WIZnet-Modul an die SPI-Schnittstelle der AVR-Stamp anschließen. Bei dieser Lösung wäre der Hardware-Aufwand am geringsten:
1 | ECB |
2 | | |<=> AVR-Stamp <--SPI--> WIZnet <---> RJ45 (4) |
3 | |<===>| |
4 | | |<=> Z180-Stamp |
:
Bearbeitet durch User
Ich hatte mir noch keinerlei Gedanken um die innere Struktur der Karte gemacht (einfach nur benutzt), wollte das aber nun tun.. Danke Leo. Die hier aufpoppende Frage hat sich mir schon mal in anderem Zusammenhang gestellt, gibts eine SPI Schnittstelle mit BUS-Anschluß? Also Parallel zu SPI? UARTs und DACs gibts ja Haufenweise. Gruß, Holm
Holm T. schrieb: > GUN Platine für den PC1715 Leo C. schrieb: > Falls ein Atmega dem Z180 doch noch Arbeit abnehmen könnte, sollte man > das WIZnet-Modul an die SPI-Schnittstelle der AVR-Stamp anschließen. Ich hatte mir in der Vergangenheit schon mehrfach Gedanken über unterschiedliche Varianten gemacht. Eine PIO-Variante hatte ich wegen der Verfügbarkeit und Geschwindigkeit ausgeschlossen. Das jetzige AVR/Z180-Stamp-System ist ja tatsächlich mit derzeit verfügbaren Bauelementen zu realisieren. Diese Philosophie wollte ich bei Erweiterungen eigentlich beibehalten, unabhängig ob noch jemand eine „schnelle“ PIO in der Kiste hat. Da WIZnet und andere Module über SPI kommunizieren und auch der VNC-II eine SPI-Schnittstelle hat, sehe ich eine Lösung in einer ECB-SPI Umsetzer (egal wie realisiert). Diese Aufgabe könnte z.B. ein AVR übernehmen. Eleganter ist jedoch eine SPI-UART-Bridge wie der SC16IS741A [1]. Er unterstützt flow control über RTS /CTS und könnte am ECB-Board, Console 0 angeschlossen werden. Eine ähnliche Variante ist durch Leo.C. ja schon als I2C-UART-Bridge [2] beim AVR CP/M realisiert. [1] http://cache.nxp.com/documents/data_sheet/SC16IS741A.pdf?pspll=1 [2] Beitrag "Re: CP/M auf ATmega88"
Joe G. schrieb: > Eine PIO-Variante hatte ich wegen > der Verfügbarkeit und Geschwindigkeit ausgeschlossen.Das jetzige > AVR/Z180-Stamp-System ist ja tatsächlich mit derzeit verfügbaren > Bauelementen zu realisieren. Diese Philosophie wollte ich bei > Erweiterungen eigentlich beibehalten, unabhängig ob noch jemand eine > „schnelle“ PIO in der Kiste hat. Verstehe ich. Dennoch juckt es mich, die inzwischen angesammelten Bausteine einmal in der Praxis auszuprobieren (PIO oder 8255, der angeblich weniger zickig ist). Nun kommen mir aufgrund der obigen Diskussion Zweifel auf ob der Geschwindigkeit. Hatte darüber noch gar nicht nachgedacht - aber bedeutet das, für diese Experimente müsste ich deutlich von den 18MHz runter?
Marcel A. schrieb: > aber > bedeutet das, für diese Experimente müsste ich deutlich von den 18MHz > runter? Laut Zilog und auch den Distributoren (z.B. Mouser) gibt es die PIO Z84C20 noch als 10 MHz Version (Z84C2010). Mit einem Bustakt von 10 MHz sollte sie also korrekt laufen.
Joe G. schrieb:> Da WIZnet und andere Module über SPI kommunizieren und auch der VNC-II > eine SPI-Schnittstelle hat, sehe ich eine Lösung in einer ECB-SPI > Umsetzer (egal wie realisiert). Also speziell für den WIZnet-Chip ist das nicht nötig, da er ein wirklich einfach anzusteuerndes und schnelles Bus-Interface hat. Das belegt im "Indirect Bus Interface Mode" 4 I/O Adressen. Datenblöcke können mit INIR/OTIR-Befehlen oder mit einem DMA-Kanal übertragen werden. Dürfte bis 33 MHz CPU-Takt ohne Waitstates funktionieren. > Diese Aufgabe könnte z.B. ein AVR übernehmen. Mit einem AVR wird das wahrscheinlich nicht leistungsfähig, bzw. aufwändig, da man für In und Out je ein Latch mit Handshake bräuchte. Oder eine Z80-PIO. ;) Es soll PICs geben, die so was eingebaut haben. Mit STM32F1 hatte ich das mal für eine Richtung (Z180 out) realisiert. Der war mit 24MHz einen Tick zu langsam für einen Z180 mit 9,2MHz. > Eleganter ist jedoch eine SPI-UART-Bridge wie der SC16IS741A Der ist aber für die falsche Richtung. Noch eleganter ist wohl ein FPGA: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an485.pdf
Leo C. schrieb: > Noch eleganter ist wohl ein FPGA: Ein MAXII EPM240 CPLD ist ja bei verschiedenen Anbietern als kleines Board verfügbar. Nur wer kann so gut Verilog um es auch umzusetzen?
Marcel A. schrieb: > bedeutet das, für diese Experimente müsste ich deutlich von den 18MHz > runter? Ja, oder Takt auf dem ECB-BUS halbieren (oder vierteln, wenn Deine PIOs nur 5 MHz können) wie es Holm weiter oben schon mal angedacht hat. @Joe, mit Verilog allein ist es ja nicht getan. Eigentlich wollte ich mit meinem Beitrag andeuten, daß ich den Aufwand für zu hoch halte (Gilt auch für die Takt-Halbierung). Für WIZnet und VNC2 gibts ja auch andere Lösungen. VNC2 kann außer über UART auch direkt parallel an ECB gekoppelt werden, wie ich gerade im Datenblatt gesehen habe. Wenns gar nicht ohne SPI geht, gibt es immer noch die Möglichkeit, den Chip an die AVR-Stamp anzuschließen. Ein paar Pins für Slave-Select sind ja noch frei. Und die Daten können sehr schnell ins Z180-RAM geschrieben, bzw. gelesen werden. Aber ich will natürlich niemand davon abhalten, ein ECB-SPI-Interface zu bauen. BTW: Mein CF-Interface läuft auch nicht zuverlässig mit 18 MHz, bzw. kommt das System erst gar nicht hoch wenn das IF angesteckt ist. Egal, ob ein CF-Modul drauf ist, oder nicht. Das kann auch an der gammeligen "Backplane" liegen. Auf dem Bild oben (Beitrag "Re: Z180-Stamp Modul") ist es schlecht zu sehen, aber das ist nur ein Stück Flachbandkabel, mit 6 aufgequetschten Buchsen.
Joe G. schrieb: > Ein MAXII EPM240 CPLD ist ja bei verschiedenen Anbietern als kleines > Board verfügbar. Nur wer kann so gut Verilog um es auch umzusetzen? Ich bevorzuge VHDL. Aber wenn Du einmal einen FPGA in der Schaltung hast, willst Du irgendwann alles damit machen... Leo C. schrieb: > Aber ich will natürlich niemand davon abhalten, ein > ECB-SPI-Interface zu bauen. Daran hätte ich auch Interesse. Prinzipiell müßten doch zwei Latches, ein kleiner Zähler, ein Takt und eine Adressmimik ausreichen. Mit der steigenden Flanke von /WR wird der Zähler gestartet und schiebt die Bits raus (und auf dem zweiten Latch rein). Das kann dann gelesen werden. Wäre natürlich schön, das in einem Chip zu haben... Geht sowas mit einem GAL? Viele Grüße, Jens
Joe G. schrieb: > Marcel A. schrieb: >> aber >> bedeutet das, für diese Experimente müsste ich deutlich von den 18MHz >> runter? > > Laut Zilog und auch den Distributoren (z.B. Mouser) gibt es die PIO > Z84C20 noch als 10 MHz Version (Z84C2010). Mit einem Bustakt von 10 MHz > sollte sie also korrekt laufen. Ich habe heute vier Stück Z84C2016VEC, DC 0925 aus der Post genommen (von meinem Freund) ..und er schreibt das er sich dafür interessiert ob die Dinger funktionieren oder ob es China-Fakes sind. Wenn die Dinger funktionieren währen sicherlich genug für Alle hier da, weil das ursprüngliche Projekt halt im Sande verlaufen ist... Ich werde es also mal testen müssen. Gruß, Holm
Marcel A. schrieb: > Verstehe ich. Dennoch juckt es mich, die inzwischen angesammelten > Bausteine einmal in der Praxis auszuprobieren (PIO oder 8255, der > angeblich weniger zickig ist). Da haste was verwechselt. Der 8255 ist ein haarsträubendes Teil ..typisch Intel. Gruß, Holm
Echt? Das stand so in einem MC Artikel. Muss noch mal nachsehen, war irgendwas mit Status oder Timings.
Leo C. schrieb: > Marcel A. schrieb: >> bedeutet das, für diese Experimente müsste ich deutlich von den 18MHz >> runter? > > Ja, oder Takt auf dem ECB-BUS halbieren (oder vierteln, wenn Deine PIOs > nur 5 MHz können) wie es Holm weiter oben schon mal angedacht hat. > > @Joe, > mit Verilog allein ist es ja nicht getan. Eigentlich wollte ich mit > meinem Beitrag andeuten, daß ich den Aufwand für zu hoch halte (Gilt > auch für die Takt-Halbierung). Mal abgesehen von CPLD/FPGA und Verilog...wir haben hier ein ECB Bus Interface..das wurde dazu gemacht erweiterbar zu sein... > Für WIZnet und VNC2 gibts ja auch andere > Lösungen. Welche fallen Dir ein? [..] > > BTW: Mein CF-Interface läuft auch nicht zuverlässig mit 18 MHz, bzw. > kommt das System erst gar nicht hoch wenn das IF angesteckt ist. Egal, > ob ein CF-Modul drauf ist, oder nicht. Das kann auch an der gammeligen > "Backplane" liegen. Auf dem Bild oben > (Beitrag "Re: Z180-Stamp Modul") ist es schlecht > zu sehen, aber das ist nur ein Stück Flachbandkabel, mit 6 > aufgequetschten Buchsen. Es gibt noch ECB Backplanes zu kaufen, ich habe auch irgendwie noch 2 unbestückte da. Ich denke nur nicht das bei 18Mhz irgend Etwas zuverlässig damit laufen wird, schon gar nicht mit dem ungetriebenen Bus. Das Ganze ist eine Fehlkonstruktion, aber das war mir von vornherein bewußt und ich habe die Platinen trotzdem gekauft, also um Gottes Willen Nichts gegen die Konstrukteure... Wenn man wirklich ein kleines ausbaubares System haben möchte muß man sich zwangsläufig Gedanken um das Bussystem machen. Alles oberhalb 5Mhz wird kritisch wenn es nicht terminiert ist, bis 8Mhz wird das noch zu machen sein aber es wird wohl nicht beim 1. Versuch funktionieren. Mir fallen 2 Varianten ein: 1. Redesign der Basisplatine und da die weitestgehend leer ist, lassen sich evtl. noch Bustreiber integrieren. 2. Verlegen der Bustreiber für einen Slot auf eine noch zu konstruierende Backplane wo sie dann als Puffer zwischen der existierenden Basisplatine und dem restlichen System arbeiten. Ich halte die Sache nach wie vor noch für ziemlich heiß und es würde mich interessieren wie Z80 Bausteine sich im IM2 mit halbem oder viertel Systemtakt verhalten. Ich habe ein PDF von Zilog gefunden: (http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=AN0063ft=Application%20Notef=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2TVRnd0wyRndjRzV2ZEdWekwybHVkR1Z5YldWdExuQmtaZz09) das die Anbindung an den schnellen Z8S180 mit 20Mhz erläutert, von halbem Systemtakt redet da aber Keiner. Ich selbst stand noch nie vor dem Problem für einen Z80 nicht gleich schnelle Peripherie auftreiben zu können und weiß nicht ob und wie das tut und wo Probleme entstehen. Wir haben jetzt einen recht schnellen CPU Kern mit Hauptspeicher und auch die Massenspeicher-Anbindung über den schnellen Bus. Es wäre aber hybsch irgendwas wie D/A Wandler oder Netzwerk anbinden zu können, ok mit dem Witznet W5100/W5300 geht das sicher auch noch schnell und direkt, bei dem Rest von Peripherie ist das evtl. nicht unbedingt notwendig..ok, den USB Stick hätte man auch gerne schnell und wer ne VGA Grafik haben will.. Wenn ich nach der PIO Bezeichnung der 16Mhz Dinger die ich hier habe google (Z84C2016VEC) geben mir alleine die gefundenen Links nicht all zu viel Hoffnung das es sich um ein reelles Produkt handelt. Im günstigsten Fall sind das ausgemessene 10Mhz Versionen ...und ich habe derzeit noch keine Ahnung wie viel Luft da nach oben noch ist, vom ungünstigsten Fall reden wir mal nicht. Allerdings sehen die Dinger nicht offensichtlich nach einer Fälschung aus bzw. diese ist dann gut gemacht. Ich werde Zilog mal eine Anfrage schicken.. Was also können/wollen wir machen? Gruß, Holm
Marcel A. schrieb: > Echt? Das stand so in einem MC Artikel. Muss noch mal nachsehen, war > irgendwas mit Status oder Timings. Die PIO funktioniert wie sie soll und ist eigentlich auch nicht timing-kritisch. Der 8255 wartet mit allerhand Nettigkeiten auf wie zum Beispiel die Tatsache das Du keine Portleitungen von Ein- auf Ausgabe und umgekehrt umprogrammieren kannst ohne das das Ding Dir die ganze restliche Programmiererei durcheinander haut (Reset). Das Teil ist wirklich giftig. Um eine LED Anzeige oder ne Tastatur anzubinden tuts freilich. Gruß, Holm
Holm T. schrieb: >> Für WIZnet und VNC2 gibts ja auch andere >> Lösungen. > > Welche fallen Dir ein? Wurde oben ja schon genannt: Beide können direkt an den Prozessor-Bus gekoppelt werden. >> BTW: Mein CF-Interface läuft auch nicht zuverlässig mit 18 MHz, bzw. Läuft inzwischen. Gestern Abend habe ich gemerkt, daß es eigentlich nur beim Start Schwierigkeiten gibt. Heute Morgen war der Grund dann schnell gefunden: Die CF-Karte hat an /RESET eine "größere" Kapazität hängen. Das war auch die einzige Leitung, die ungepuffert vom Bus an den IDE-Stecker ging. Jetzt habe ich den noch freien Buffer in die Reset-Leitung gelötet, und es geht. Trotzdem sollte ich aber auch die Software an der Stelle etwas entschärfen. Damit will ich nicht sagen, daß es über den vollen Temeraturbereich stabil läuft, robust gegen Störungen ist, und auch noch läuft, wenn man noch mehr Karten dazu steckt, usw. Aber auf meinem Schreibtisch ist es jetzt definitiv stabil bei 18,432 MHz. Wundert mich selber. Vorhin habe ich die I/O-Waitstates auch noch auf 0 gesetzt. Läuft immer noch. :) Ein Sektor von oder zur CF-Karte wird jetzt mit 7 Takte/Byte übertragen. Und dank Multi-Sektor-I/O ist zwischen Sektoren oft nur sehr wenig Overhead. Eine RAM-Disk wäre höchstens einen Takt/Byte schneller. Aber auch nur, wenn sie komplett Memory-mapped angebunden ist, und nicht über I/O-Ports. > Es gibt noch ECB Backplanes zu kaufen, ich habe auch irgendwie noch 2 > unbestückte da. Es ist ja nicht so, daß ich nichts anderes hätte. Ich wollte es einfach mal damit ausprobieren. Außerdem ist das Teil so schön flexibel, daß man die Karte hin und her klappen, und so von allen Seiten messen kann. > Ich denke nur nicht das bei 18Mhz irgend Etwas > zuverlässig > damit laufen wird, schon gar nicht mit dem ungetriebenen Bus. Solange alle Busteilnehmer CMOS sind (so wie jetzt) sehe ich darin kein so großes Problem. Buslänge, (fehlende) Terminierung, Kartenanzahl schon eher. > Das Ganze ist eine Fehlkonstruktion, aber das war mir von vornherein > bewußt und ich habe die Platinen trotzdem gekauft, also um Gottes Willen > Nichts gegen die Konstrukteure... Es war eine bewußte Designentscheidung. Zu dem Zeitpunkt waren die Stampkarten noch für reinen 3.3V-Betrieb ausgelegt. Die Bustreiber hätten dann auch noch Levelshifter-Funktion übenehmen müssen. Das alles für den Fall, daß jemand eine ECB-Karte hat, die schnell genug ist, und an dem System noch Sinn macht. Die alten Floppy-Controller, EPROM-,RAM- und RAM-Disk-Karten gehören eher nicht dazu. Auf keinen Fall war und ist das System dazu gedacht, in einem ausgebauten ECB-System die CPU-Karte zu ersetzen. IMHO. > Systemtakt verhalten. Ich habe ein PDF von Zilog gefunden: >(http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=AN0063ft=Application%20Notef=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2TVRnd0wyRndjRzV2ZEdWekwybHVkR1Z5YldWdExuQmtaZz09) > das die Anbindung an den schnellen Z8S180 mit 20Mhz erläutert, von > halbem Systemtakt redet da aber Keiner. Der Link geht bei mir nicht. Falls es diese AN ist: INTERFACING MEMORY AND I/O TO THE 20 MHZ Z8S180 SYSTEM dann ist darin von den alten Z80-Peripheriebausteinen nicht die Rede sondern von: 2) 20 MHz ESCC TM timing is based on the Z85230 Product Specification. Und diesen ESCC wird es wohl für 20 MHz geben. > Wir haben jetzt einen recht schnellen CPU Kern mit Hauptspeicher und > auch die Massenspeicher-Anbindung über den schnellen Bus. Den Speicher kann man übrigens (über den Bus) noch auf 1 Mbyte erweitern. > Es wäre aber hybsch irgendwas wie D/A Wandler Wenn man auf Vektor-Ints verzichten kann, wäre der Anschluß eher langsamerer Peripherie kein großes Problem. Man müßte halt genug Wait-States reinknallen. 2 Interrupt-Leitungen haben wir noch frei. Die liegen auch auf dem ECB-Anschluß. > und wer ne VGA Grafik haben will.. ... Nimmt ein Terminal mit Tektronix 4014 Mode. ;-)
Holm T. schrieb: > Was also können/wollen wir machen? Gute Frage. Ich hätte kein Problem, für gewisse Anwendungen den Takt zu vierteln (4,x MHz) - da diese aber im Quellcode steht, wäre das jedes Mal ein umflashen, oder? Hat das nicht auch Auswirkungen auf die SIO? Ich denke, dann wäre nur noch 38,4kB drin - das ist dann schon spürbar im Terminal :-) Zum 8255: Stimmt, der war recht merkwürdig, aber an sich auch etwas leistungsfähiger. Er wurde ja auch viel eingesetzt - so ganz schlecht kann er ja nicht sein. Ich meine gelesen zu haben, dass sich der 8255 einfacher ansprechen lässt.
Habe die aktuelle SW drin - geht soweit. Habe zwar die CF-Karte noch nicht gebaut - frage ich aber, wie die angesprochen wird? - Sind die Laufwerke schon "fest verdrahtet" auf I - L? - vermutlich muss man das Modul / die Karte erst mal am PC formatieren? - wie sehen denn die Daten für CFDISK aus? Ich erinnere mich nur an die 8MB Partitionen...
@leo: Wie schon geschrieben, mir war von vornherein klar das das ein Spielzeug ist und ich will ja spielen. Ich hatte das ja gegenüber Joe auch shcon mal angesprochen (Mail?) normalerweise kräuseln sich mir die Fußnägel wenn ich diese ateml bootloaded Konstruktionen sehe weil kein Promer für Eproms da ist, ansonsten könnte der Z180 das ja gewissermaßen alleine.. Mir wäre also eine ECB Bus Karte (wegen der möglichen vielen Speilereien am Bus) mit Puffer eigentlich lieber gewesen, aber darüber will ich nicht nörgeln, ich bin erwachsen und wußte was ich mir an den Hals hänge :-) Ich bin aber auch alt genug das mit Bremsen am Mopped mindestens genau so wichtig sind wie der Motor..war früher bestimmt mal anders. Liegt evtl. daran das einem mit den Jahren klar wird das das Leben endlich ist. Ich muß also nicht das letzte Quäntchen Performance haben, Praktikabilität ist auch keine schlechte Sache. ..und ja, das PDF ist das von Dir genannte, mir gibts da nicht um die PIO, die haben nur halt kein Wort über den Anschluß langsamerer Peripherie verloren sondern sogar eine Statemachine in einem EP610 vorgeführt um dem Bus selbst für den recht schnellen ESCC zu bremsen. Auf IM2 können wir sicherlich verzichten, SIOs haben wir IMHO ausreichend bleibt Netzwerk USB und evtl. Spielereien dann doch am Bus, man kann Ints aber auch konzentrieren in dem man das z.B. einen Zähler machen läßt. Der 8255 ist nicht leistungsfähiger als eine PIO, das ist eher umgekehrt. Einfacher zu handhaben isser vielleicht, das liegt aber wohl daran das er älter und primitiver ist. @Marcel: Ich weiß nicht wqas die ASCIs in der Z180 machen, die Baudrate ist vom Takt abhängig, deswegen haben wir auch einen Baudratenquarz. Ich denke aber das Du nicht viel Unterschied zwischen 115200 und 57600 an einem ASCII Terminal merken wirst. Das was Du da siehst ist IMHO nicht mehr die Schnittstellengeschwindigkeit sondern das was die CPU senden und das Terminal empfangen und verarbeiten kann ohne sich zu verschlucken. Ich denke auch nicht das man "jedesmal umflashen" muß, Leo hat den programmäßig den Hut auf (gut so) und das unterbringen von Environmentvariablen für die Baudraten dürfte nicht das Problem sein, der Z180 kann auch ausrechnen welche Vorteiler etc. er für welche Baudrate bei welchem Takt braucht. Es sollte auch mit 9Mhz möglich sein 115200 zu fahren, das konnten schon langsamere Rechner, allerdings wird dann Flußkontrolle wichtig. Zur PIO: Mir sind bei der Z80 PIO keine Bugs bekannt, die macht recht gut und zuverlässig das was sie soll und ist hinsichtlich Bitweiser Programmierung auch flexibler als ein 8255. Ein 8255 dagegen hat mehr pure IO Leitungen nd auch ne rudimentäre Unterstützung für Handshake, aber das ist bei der PIO weiter ausgebaut. Der 8255 war eher da und stammt noch aus dem 8080 System, genauso wie der 8253 und beide haben dann bei 8085 und 8088/8086 eine weitere Blütezeit gehabt. Das Vorhandensein verwendbarer Peripherie-ICs für den 8088 war wohl auch der Grund warum IBM mit den 8088 Krücken den XT zusammengefrickelt hat (ja ich meine das exakt so wie ich das schreibe). 68000 und Z8000 waren weitaus bessere Systeme, es setzt sich am Markt aber wohl prinzipiell exakt das Beschissenste durch. Also merke Dir für die Zukunft: 8255 mehr Portpins aber primitiver und Glitches. Der 82C55A ist etwas besser als der 8255 aber eine PIO ist viel besser und flexibler. Die beim 8255 "zusätzlich" vorhandenen Singale sind bei der PIO auch vorhanden aber teilweise dediziert belegt. Evtl. wird die PIO auch für Manche übersichtlicher wenn sie eine deutsche Doku lesen, ich habe da unter www.tiffe.de/Robotron in dem Directory Bausteinubersicht unter Anderem PDFs zur U855, der Z80-PIO vom MME Erfurt, DDR. Ich habe noch ca. 30-40 Stück russische 8255 da, brauchst Du welche? :-) Sing glaube ich A Typen, sollten also 5Mhz mit machen. Nochmal: Ob das mit der Taktteilerei überhaupt praktikabel funktioniert weiß ich nicht wirklich. Müßte man mal testen. Den Z180 muß man dann wohl trotzdem mit Waitstates ziemlich einbremsen. IMHO hat der Register in denen man das global festlegen kann, aber hier wäre wohl dann eine Mimik analog der aus dem oben angegebenen Datenblatt nötig die die CPU bei Zugriff auf einen bestimmen IO Bereich bremst. Interruptprioritätskette kann man wohl bei 18Mhz weitestgehend vergessen. Natürlich kann man aber auch 74HCT374 oder Sowas als Latch zur Ein-Ausgabe benutzen oder solche S-TTL Oldtimer wie 8212 mit Interruptlogik :-) Gruß, Holm
..Sorry für das Kauderwelsch/Durcheinander.. sitze im Garten am Notebook und hab nicht mal mein Login hier drauf.. Gruß, Holm
Marcel A. schrieb: > Ich hätte kein Problem, für gewisse Anwendungen den Takt zu vierteln > (4,x MHz) - da diese aber im Quellcode steht, wäre das jedes Mal ein > umflashen, oder? Nein, das mit dem vierteln war anders gemeint. Du willst offensichtlich den CPU-Takt komplett niedriger einstellen. Da Du die ECB-Basiskarte hast, kannst Du dafür ganz einfach den Jumper JP3 auf 2-3 stellen und dann über den pin-Befehl an Pin 3 den gewünschten Takt einstellen. 18,432 MHz geteilt durch 2 oder 3 oder 4 oder ... oder 524288. > Hat das nicht auch Auswirkungen auf die SIO? Ich denke, dann wäre nur > noch 38,4kB drin - das ist dann schon spürbar im Terminal :-) Dafür ist ja die Takterkennung im BIOS, die aber leider nicht gut funktioniert. Inzwischen habe ich eine andere (ich lasse den AVR den Takt auf ca. 5 Stellen genau messen), die ist aber noch nicht eingebaut. Aber wenn, dann kann man auch auf der Z180-Stamp (nahezu) beliebige Quarze einstecken. Bis 33,868 MHz getestet. Aus dem User Manual: baud rate = f PHI /(2*(TC+2)*16) Oder anders rum : TC = (f PHI /*2*baud rate*16)) -2 Minimale Taktrate für 115200 baud: 2*2*115200*16/2 = 7,3728 MHz Aber die Baudrate wird ja allgemein überbewertet. Das hatten wir schon weiter oben. > Habe zwar die CF-Karte noch nicht gebaut - frage ich aber, wie die > angesprochen wird? > - Sind die Laufwerke schon "fest verdrahtet" auf I - L? Ja > - vermutlich muss man das Modul / die Karte erst mal am PC formatieren? Partitionieren reicht. Bin dabei, ein fdisk für CP/M mit TP zu schreiben. > - wie sehen denn die Daten für CFDISK aus? Ich erinnere mich nur an die > 8MB Partitionen... Genuau so, wie beim AVR-CP/M-System. Nur primäre Partitionen und Partitionstyp 52. Bisher wird auch nur das simhd-Format unterstützt, also die bekannten 8 MB.
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.4.12-cf-card-dirty |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | cfio: CompactFlash Memory Card driver |
4 | Model: CF Card, S/N: B00D07230E0700221719, Rev: Ver2.35 |
5 | Size: 7880544 Sectors (3940272 KiB) |
6 | I: CP/M partition at: 2048, size: 8192KiB |
7 | J: CP/M partition at: 18432, size: 8192KiB |
8 | K: CP/M partition at: 34816, size: 524288KiB |
9 | |
10 | A> |
holm schrieb: > Fußnägel wenn ich diese ateml bootloaded Konstruktionen sehe weil kein > Promer für Eproms da ist, ansonsten könnte der Z180 das ja gewissermaßen > alleine.. E(E)PROMS sind tot! Und das ist gut so.
Leo C. schrieb: > E(E)PROMS sind tot! Und das ist gut so. Das ist jetzt aber ein hartes Urteil :-) Ich bin froh, einen Brenner zu haben, damit kann ich die firmware für den NDR Computer und diverse Dinge für meinen C128 brutzeln :-)
> E(E)PROMS sind tot! Und das ist gut so.
Ich glaube Dir kein Wort. Auch eine SD Karte ist nix weiter als ein
Flash ROM, es ist aber nicht allzu proaktikabel wenn man damit einen
Z180 anwerfen will.
Beruhige Dich mal mit edem Fdis in Pascal, ich glaube so was habe ich,
zumindest hat es mal eine MFM Festplatte partitioniert und u.A. auch
eine DOS Partition angelegt.
Ich suche das raus.
Gruß,
Holm
holm schrieb: > Wie schon geschrieben, mir war von vornherein klar das das ein > Spielzeug ist und ich will ja spielen. Ich hatte das ja gegenüber Joe > auch schon mal angesprochen Hier nochmals ganz deutlich die Beweggründe für das derzeitige System. Der Z180-Stamp ist eine CPU mit Z80-Bus und Speicher – mehr nicht. Der AVR-Stamp ist ein Speicher der den Bootvorgang übernimmt – mehr nicht. Um den Bootvorgang und die Inbetriebnahme zu erleichtern, übernimmt der AVR noch einige Zusatzfunktionen (Monitor, CD-Card mit FAT, V24, RTC, USB, usw.). Wer das nicht mag, wer klassisch arbeiten möchte, steckt einfach auf den Z180-Stamp seinen EPROM und steckt den Z180-Stamp auf sein eigenes, wie auch immer aufgebautes Board. CP/M – Minimalvariante Z180-Stamp und AVR-Stamp im Huckepackbauweise ergeben ein lauffähiges CP/M Minimalsystem. Es ist dazu keine weitere Hardware notwendig. Die Terminalausgabe für den Monitor und das CP/M erfolgt über die USB-Schnittstelle des AVR-Stamp. CP/M – Grundvariante Z180-Stamp und AVR-Stamp werden auf das Basisboard gesteckt. Auf diesem sind die V24 Schnittstellen der SIO rausgeführt, eine zweite SD-Card untergebracht, Jumper für die Taktumschaltung vorgesehen und der Z80-Bus auf einen Steckverbinder rausgeführt. Bustreiber sind aus schon ausgeführten Gründen nicht vorgesehen. Mehr sollte und darf nicht in dieses System reininterpretiert werden. Es ist und bleibt ein einfaches Experimentalsystem für Z80. Was letztlich jeder damit machen möchte, bleibt den Nachnutzer überlassen.
Holm T. schrieb: >> Für WIZnet und VNC2 gibts ja auch andere Lösungen. > > Welche fallen Dir ein? Hier [1] eine Variante wie der VNC an einen JU+TE TINY über FIFO angeschlossen wird. [1] http://hc-ddr.hucki.net/wiki/doku.php/tiny:erweiterungen:vdip
Joe G. schrieb: > Holm T. schrieb: >>> Für WIZnet und VNC2 gibts ja auch andere Lösungen. >> >> Welche fallen Dir ein? > > Hier [1] eine Variante wie der VNC an einen JU+TE TINY über FIFO > angeschlossen wird. > > [1] http://hc-ddr.hucki.net/wiki/doku.php/tiny:erweiterungen:vdip ...hab das überflogen...wo siehst Du da einen Fifo? Gruß, Holm
Joe G. schrieb: > holm schrieb: >> Wie schon geschrieben, mir war von vornherein klar das das ein >> Spielzeug ist und ich will ja spielen. Ich hatte das ja gegenüber Joe >> auch schon mal angesprochen > > Hier nochmals ganz deutlich die Beweggründe für das derzeitige System. > [..] > > Mehr sollte und darf nicht in dieses System reininterpretiert werden. Es > ist und bleibt ein einfaches Experimentalsystem für Z80. Was letztlich > jeder damit machen möchte, bleibt den Nachnutzer überlassen. Ja Joe, einverstanden und von vornherein klar gewesen. Ich kritisiere nicht, ich labere herum was mir lieber wäre und versuche das zu begründen. Ärgere Dich bitte einfach nicht drüber. Gruß, Holm
Holm T. schrieb: > ...hab das überflogen...wo siehst Du da einen Fifo? im VNC2 > Ärgere Dich bitte einfach nicht drüber. Mache ich nicht, ich gebe nur möglichen Nachnutzern Argumente an die Hand.
Joe G. schrieb: > Holm T. schrieb: >> ...hab das überflogen...wo siehst Du da einen Fifo? > im VNC2 > Ok...das ist aber Bestandteil der internen Programmlogik, im Wesentlichen hat er das Ding parallel angebunden. >> Ärgere Dich bitte einfach nicht drüber. > Mache ich nicht, ich gebe nur möglichen Nachnutzern Argumente an die > Hand. Ok, dann bin ich beruhigt. BTW: Ich habe mit Ralf (Susowa) per Mail konferiert, er ist der Meinung das die Firmware der K1520Net Karte unverändert funktionieren müßte wenn die PIO schnell genug ist. Unter CPM3 hat allerdings noch Niemand die Software ausprobiert. Ich werde das im Laufe dieser Woche mal tun. Auch von Holger (der mit den PIOs) liegt indessen die Aussage vor das Andere die mit 16Mhz schon getestet und für gut befunden hätten..mal gucken.. Ich habe aber auch kein Problem damit wenn der WIZ810/811/812 oder was auch immer direkt an den Bus angebunden werden würde, ich habe nur keinen einzelnen Modul mehr da, nur einen W5100 der sich ein Bisschen blöde handhaben läßt (LQFP80) da ist selbst "dead Bug" eine Herausforderung. Gruß, Holm
Mal wieder eine ganz dumme Frage von mir: Brauchen wir überhaupt eine PIO? Bei meinem NDR Computer ist die Centronics-Schnittstelle einfach mit einem 74245 Bustreiber oder so und einem Adress-Dekoder gelöst - also direkt "memory mapped".
"Wir" brauchen keine PIO. Ob Du eine brauchst, wissen "wir" nicht. Das beim NDR Computer ist mit Sicherheit ein "oder so". Ein Bustreiber tuts nicht.
Marcel lies doch mal richtig, die braucht man nur wenn man die KC85 Netzwerkplatine oder ich halt die K1520Net mehr oder weniger provisorisch am ECB Bus betreiben will. Leo hat sich gerade die Rute über den Arsch gebunden die Software für ein Netzwerkomodul-Anschluß ohne fragwürdige PIOs (hinsichtlich der Taktfrequenz) zu erstellen :-) Gruß, Holm
Zum Pollin DiskOnModule hatte ich schon mal geschrieben (Beitrag "Re: Z180-Stamp Modul"): > Scheint auch mit 3.3V zu laufen, aber gründliche Tests stehen noch aus. Läuft genau wie die CF-Karte wirklich mit 3.3V und 0 Wait-States.
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.4.14-cf-card-dirty |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver |
5 | Model: PQI IDE DiskOnModule, S/N: DOM1D00004532, Rev: 060729DA |
6 | Size: 256000 Sectors (128000 KiB) |
7 | I: CP/M partition at: 2048, size: 8192KiB |
8 | J: CP/M partition at: 18432, size: 118784KiB |
9 | |
10 | A> |
Leo C. schrieb: > Läuft genau wie die CF-Karte wirklich mit 3.3V und 0 Wait-States. Feine Sache Leo, danke. Ich bin gerade dabei deine Schaltung auf eine Platine zu bringen (Huckepackvariante).
Hier ist ein Update vom Schaltplan. Aber eigentlich wollte ich noch schauen, ob man die Gatter noch etwas optimieren kann. Hab nur gerade keine Zeit.
Danke, ich schau mal ob ich noch etwas an Gattern optimieren kann. Die Schaltung und das Layout stelle ich dann hier wieder zur Diskussion rein.
Statt des '126 kann man natürlich auch einen '125 nehmen, oder andere Buffer oder übrig gebliebene Gatter, wenn sie nicht invertieren.
Angehängte Dateien:
-
1.gif
24 KB
Zum Thema DMA-Request (Beitrag "Re: Z180-Stamp Modul") > Möglicherweise reicht aber auch eine Verknüpfung mit DASP. Das habe ich jetzt mal so umgebaut, und es funktioniert. /DREQ1 wird über einen Open-Drain Ausgang nur dann auf low gezogen, wenn DASP- (Device Active/Slave Present) low ist. Das ist nur der Fall, wenn der cfio-Treiber mit der Karte kommuniziert. Zu anderen Zeiten kann der DMA-Kanal von anderen Geräten verwendet werden. In dem angehängten Bild ist ein Sektor-Transfer zu der 4GB CF-Karte zu sehen. Kanal 1 ist CS0- (I/O-Zugriff auf die Karte) und Kanal 2 ist /DREQ1. Die ersten Impulse ab dem Start-Cursor zeigen die Übertragung der Parameter (Sektor-Nr) an die Karte. In der "Pause" wird der DMA-Kanal initialisiert. Der erste Impuls nach der Pause ist der Read-Sektor-Befehl. Die folgenden Pulse bis zum E-Cursor sind die Polling-Schleife, in der die CPU auf das Ende des DMA-Transfers wartet. In dieser Zeit aktiviert der CF-Controller DASP- (/DREQ1), ließt die Daten aus dem Flash und schreibt sie in den internen Sector-Buffer. Ab dem E-Cursor bis zur steigenden Flanke von /DREQ1 werden die Daten per DMA ins RAM transferiert. Gesamtzeit: 278µs Bereitstellung durch Karte: 39µs (bei dem Pollin Modul ca. 68µs) DMA-Transfer: 195µs @Marcel: so besser?
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.4.14-cf-card-dirty |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | |
6 | A> |
Holm T. schrieb: > das mkfs.cpm legt ja "sparse" Disks an wie Leo oben schon mal erklärt > hat, > d.h. wenn die disk nicht voll ist, dann ist die Filesize kleiner als die > Diskkapazität. Das führt aber unter CP/M zu Fehlern, mit Power und dem > Kommando test kann man eine ganze Disk probelesen und eine Checksumme > generieren, promt hagelt das Fehler. Der Programmierer des AVR-Monitors hat offensichtlich die fat-Routinen von chan nicht richtig verstanden und nicht genug getestet. Danke, daß Du den Test jetzt nachgeholt hast. Normalerweise liest CP/M keine ungeschriebenen Sektoren. Wenn man neue Dateien auf so ein kurzes Image kopiert, wird es automatisch erweitert. Das funkioniert einwandfrei. Ich dachte, die Erweiterung wird auch beim Lesen durchgeführt, und man erhält ungeschriebene, also zufällige Daten zurück. Stattdessen liefert ein f_read() außerhalb der Datei aber nichts zurück, also Anzahl gelesene Bytes == 0 und Fehlercode 0 (== alles ok). Das TEST-Kommando von Power bekommt einen Fehler gemeldet ('bad sector'), weil mein Treiber immerhin merkt, daß die Anzahl gelesener Bytes != 512 ist. Ich habe den Treiber jetzt mal so geändert, daß in so einem Fall 512 0-Bytes zurückgeliefert werden. Scheint zu funktionieren. Allerdings ist es unbrauchbar, weil anscheinend bei jedem Zugriff hinter dem Dateiende vom Dateisystem die Cluster-Chain aufs Neue erweitert, aber nicht physikalisch geschrieben wird. Bei dem TEST-Kommando dauert das unerträglich lange:
1 | ## 38852107 cpm_rw: read G: trk:1535, sec: 0, pos: 005ff000, secs: 1, addr: 1cc00 |
2 | short read, brw: 0 |
3 | ## 38853135 cpm_rw: read G: trk:1535, sec: 0, pos: 005ff000, secs: 1, addr: 1cc00 |
4 | short read, brw: 0 |
5 | ## 38854162 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
6 | short read, brw: 0 |
7 | ## 38855189 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
8 | short read, brw: 0 |
9 | ## 38856217 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
10 | short read, brw: 0 |
11 | ## 38857244 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
12 | short read, brw: 0 |
13 | ## 38858271 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
14 | short read, brw: 0 |
15 | ## 38859299 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
16 | short read, brw: 0 |
17 | ## 38860326 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
18 | short read, brw: 0 |
19 | ## 38861353 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
20 | short read, brw: 0 |
21 | ## 38862381 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
22 | short read, brw: 0 |
23 | ## 38863408 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
24 | short read, brw: 0 |
25 | ## 38864435 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
26 | short read, brw: 0 |
27 | ## 38865463 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
28 | short read, brw: 0 |
29 | ## 38866490 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
30 | short read, brw: 0 |
31 | ## 38867517 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
32 | short read, brw: 0 |
33 | ## 38868545 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
34 | short read, brw: 0 |
35 | ## 38869572 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
36 | short read, brw: 0 |
37 | ## 38870599 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
38 | short read, brw: 0 |
39 | ## 38871627 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
40 | short read, brw: 0 |
41 | ## 38872654 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
42 | short read, brw: 0 |
43 | ## 38873681 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
44 | short read, brw: 0 |
45 | ## 38874709 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
46 | short read, brw: 0 |
47 | ## 38875736 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
48 | short read, brw: 0 |
49 | ## 38876763 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
50 | short read, brw: 0 |
51 | ## 38877791 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
52 | short read, brw: 0 |
53 | ## 38878818 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
54 | short read, brw: 0 |
55 | ## 38879845 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
56 | short read, brw: 0 |
57 | ## 38880873 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
58 | short read, brw: 0 |
59 | ## 38881900 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
60 | short read, brw: 0 |
61 | ## 38882927 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
62 | short read, brw: 0 |
63 | ## 38883955 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
64 | short read, brw: 0 |
65 | ## 38884982 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
66 | short read, brw: 0 |
67 | ## 38886009 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, addr: 1cc00 |
68 | short read, brw: 0 |
69 | ## 38887037 cpm_rw: read G: trk:1537, sec: 0, pos: 00601000, secs: 1, addr: 1cc00 |
70 | short read, brw: 0 |
71 | ## 38888064 cpm_rw: read G: trk:1537, sec: 0, pos: 00601000, secs: 1, addr: 1cc00 |
72 | short read, brw: 0 |
73 | ## 38889091 cpm_rw: read G: trk:1537, sec: 0, pos: 00601000, secs: 1, addr: 1cc00 |
74 | short read, brw: 0 |
Der Test läuft seit gestern Abend (seit ca. 38889091 ms) und ist gerade mal bei Track 1537 von 2047 angekommen. Mir fallen noch ein oder 2 Verbesserungsmöglichkeiten ein, die ich heute mal ausprobieren werde. Die einfachste wäre, beim Öffnen der Image-Datei die Länge zu prüfen, und wenn zu kurz gleich auf die volle Größe erweitern. Wenn dann der Platz auf der Karte nicht reicht, gibt es die Überraschung auch gleich an dieser Stelle, und nicht erst, nachdem man z.B. 3 Stunden mit WS an einer Datei editiert hat. Übrigens scheint Power hier auch etwas falsch zu machen. Es liest jeweils 32 mal von jedem Track den Sektor 0. Ein Track hat 32 CP/M-Sektoren (128 Byte), bzw. 8 physikalische Sektroren (512 Byte). Man sollte hier also je Track 1 oder 4 Zugriffe auf jeden Sektor (von 0 bis 7) sehen. Möglicherweise kommt Power mit CP/M 3 nicht zurecht. > dieses mkfs.cpm ist wohl daher eher > mit vorsicht zu genießen, bei mir ist das z.B. auch nicht in der Lage > auf einer Floppy ordentlich zu arbeiten, wahrscheinlich kommt das genau > von diesem "Feature". Du meinst Floppies, die für CP/M formatiert sind? Dann glaube ich das weniger. Auf der Floppy gibts ja kein (zu kurzes) FAT-Dateisystem. Vielleicht sind Deine CP/M-Tools[2] ohne libdsk[3] compiliert. [1] http://elm-chan.org/fsw/ff/en/lseek.html [2] http://www.moria.de/~michael/cpmtools/ [3] http://www.seasip.info/Unix/LibDsk/index.html
Leo C. schrieb: > Holm T. schrieb: >> das mkfs.cpm legt ja "sparse" Disks an wie Leo oben schon mal erklärt >> hat, >> d.h. wenn die disk nicht voll ist, dann ist die Filesize kleiner als die >> Diskkapazität. Das führt aber unter CP/M zu Fehlern, mit Power und dem >> Kommando test kann man eine ganze Disk probelesen und eine Checksumme >> generieren, promt hagelt das Fehler. > > Der Programmierer des AVR-Monitors hat offensichtlich die fat-Routinen > von chan nicht richtig verstanden und nicht genug getestet. Danke, daß > Du den Test jetzt nachgeholt hast. hybsche Beschreibung :-) >[..] > short read, brw: 0 > ## 38878818 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38879845 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38880873 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38881900 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38882927 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38883955 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38884982 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38886009 cpm_rw: read G: trk:1536, sec: 0, pos: 00600000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38887037 cpm_rw: read G: trk:1537, sec: 0, pos: 00601000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38888064 cpm_rw: read G: trk:1537, sec: 0, pos: 00601000, secs: 1, > addr: 1cc00 > short read, brw: 0 > ## 38889091 cpm_rw: read G: trk:1537, sec: 0, pos: 00601000, secs: 1, > addr: 1cc00 > short read, brw: 0 > [/pre] > > Der Test läuft seit gestern Abend (seit ca. 38889091 ms) und ist gerade > mal bei Track 1537 von 2047 angekommen. Mir fallen noch ein oder 2 > Verbesserungsmöglichkeiten ein, die ich heute mal ausprobieren werde. > Die einfachste wäre, beim Öffnen der Image-Datei die Länge zu prüfen, > und wenn zu kurz gleich auf die volle Größe erweitern. Wenn dann der > Platz auf der Karte nicht reicht, gibt es die Überraschung auch gleich > an dieser Stelle, und nicht erst, nachdem man z.B. 3 Stunden mit WS an > einer Datei editiert hat. > > Übrigens scheint Power hier auch etwas falsch zu machen. Es liest > jeweils 32 mal von jedem Track den Sektor 0. Ein Track hat 32 > CP/M-Sektoren (128 Byte), bzw. 8 physikalische Sektroren (512 Byte). Man > sollte hier also je Track 1 oder 4 Zugriffe auf jeden Sektor (von 0 bis > 7) sehen. Möglicherweise kommt Power mit CP/M 3 nicht zurecht. > >> dieses mkfs.cpm ist wohl daher eher >> mit vorsicht zu genießen, bei mir ist das z.B. auch nicht in der Lage >> auf einer Floppy ordentlich zu arbeiten, wahrscheinlich kommt das genau >> von diesem "Feature". > > Du meinst Floppies, die für CP/M formatiert sind? Dann glaube ich das > weniger. Ich schon, weil ichs probiert habe. Auf einem 800K langen Floppyimage funktioniert das, das DD danach auf das Floppy auch, aber mkfs.cpm aufs Device funktioniert nicht. >Auf der Floppy gibts ja kein (zu kurzes) FAT-Dateisystem. > Vielleicht sind Deine CP/M-Tools[2] ohne libdsk[3] compiliert. Genau. Mit Libdisk zerschießt das Zeug regelmäßig die Filesysteme weswegen ich die Version ohne vorziehe :-) Der Libdisk Support ist für den Zugriff auf (raw) Devices nicht notwendig. > > [1] http://elm-chan.org/fsw/ff/en/lseek.html > [2] http://www.moria.de/~michael/cpmtools/ > [3] http://www.seasip.info/Unix/LibDsk/index.html Ich bin nicht der Einzige bei dem die CPMTools mit Libdisk Support die Floppies kaputt machen, das berichtete ein Anderer bei Robotrontechnik.de worauf hin ich mir das genauer angesehen habe. Da ich mit einem Anderen Problem zu tun hatte bin ich da nicht in den Code abgetaucht. Gruß, Holm
Power TEST war nach gut 15 Stunden fertig. Ich hatte noch nicht die Zeit zum Testen (nochmal 15 Stunden), aber ich bin sicher daß bei Wiederholung die gleiche Prüfsumme herauskommen würde. Dabei könnte ich es eigentlich bewenden lassen. Da es aber wahrscheinlich ein paar Nutzer gibt, die von dieser etwas langsamen Lösung nicht begeistert sind, habe ich doch nochmal etwas umgebaut. Die Idee, das Image nur dann zu erweitern, wenn es unbedingt notwendig ist, gefällt mir immer noch, aber dieses Argument: > Wenn dann der > Platz auf der Karte nicht reicht, gibt es die Überraschung auch gleich > an dieser Stelle, und nicht erst, nachdem man z.B. 3 Stunden mit WS an > einer Datei editiert hat. hat den Ausschlag gegeben. Die Image-Datei wird jetzt also beim Drive-Login auf die maximale Größe erweitert. Das ist einfacher und dürfte um einiges schneller sein, als die Datei immer nur bei Bedarf zu erweitern. Die Variante habe ich nicht mehr getestet. Wenn das jemand dringend braucht, oder gründlich testen will, kann ich davon ein Hexfile machen. Sonst habe ich keine weltbewegenden Änderungen.
1 | ## 713157 login: H: |
2 | ## 713168 open: '1:/sparse1.dsk', (env: 'dsk7'), res: 0 |
3 | expanding image file from 57344 to 8388608 |
4 | ## 714343 cpm_rw: read H: trk: 6, sec: 0, pos: 00006000, secs: 1, addr: 07e00 |
Holm T. schrieb: >> Du meinst Floppies, die für CP/M formatiert sind? Dann glaube ich das >> weniger. > > Ich schon, weil ichs probiert habe. > Auf einem 800K langen Floppyimage funktioniert das, das DD danach auf > das Floppy auch, aber mkfs.cpm aufs Device funktioniert nicht. Ich kann mir nicht vorstellen, daß das an besagtem "Feature" liegt. Funktionieren denn die anderen Tools (fsck.cpm, fsed.cpm) direkt auf Floppy? Ausprobieren kann ich es nicht weil ich keine Floppy-Laufwerke (mehr) habe. Mich würde interessieren, warum der TEST-Befehl von Power immer nur Sektor 0 auf jedem Track liest. Hast Du zufällig den Sourcecode davon?
Leo C. schrieb: > Power TEST war nach gut 15 Stunden fertig. Ich hatte noch nicht die Zeit [..] > Wenn das jemand dringend braucht, oder gründlich testen will, kann ich > davon ein Hexfile machen. Sonst habe ich keine weltbewegenden > Änderungen. > >
1 | > ## 713157 login: H: |
2 | > ## 713168 open: '1:/sparse1.dsk', (env: 'dsk7'), res: 0 |
3 | > expanding image file from 57344 to 8388608 |
4 | > ## 714343 cpm_rw: read H: trk: 6, sec: 0, pos: 00006000, secs: 1, |
5 | > addr: 07e00 |
6 | > |
> ..viel Mühe..braucht man das wirklich? Ich halte die sparse Files eher für ein Misfeature, auf heutigen den Datenträgern ist das ganz schlicht egal.... > Holm T. schrieb: >>> Du meinst Floppies, die für CP/M formatiert sind? Dann glaube ich das >>> weniger. >> >> Ich schon, weil ichs probiert habe. >> Auf einem 800K langen Floppyimage funktioniert das, das DD danach auf >> das Floppy auch, aber mkfs.cpm aufs Device funktioniert nicht. > > Ich kann mir nicht vorstellen, daß das an besagtem "Feature" liegt. > Funktionieren denn die anderen Tools (fsck.cpm, fsed.cpm) direkt auf > Floppy? Ausprobieren kann ich es nicht weil ich keine Floppy-Laufwerke > (mehr) habe. Ich bin mir nicht sicher ob die anderen Dinger funktionieren, ich probiere das aber aus. Ich habe in einer Bastelbude meinen alten Rechner stehen, mit 5,25 und 3,5er Laufwerken zum Datenaustausch. > > Mich würde interessieren, warum der TEST-Befehl von Power immer nur > Sektor 0 auf jedem Track liest. Hast Du zufällig den Sourcecode davon? Keine Ahnung und nein, habe ich nicht. Ich habe aber im Robotron-Forum nachgefragt. http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=13509 (Im CP/M Forum kann man sich das wohl kneifen, da hört man maximal ein Echo..). Welche Power Version hattest Du am Wickel?= 3.03 oder 3.07 ..oder was? Warum? Da gibts nur eine Begründung: Bug. Ich wundere mich das das noch Keiner gemerkt haben soll, ich habe in der Vergangenheit haufenweise Disketten damit getestet (und Floppies/Floppyconroller). Gruß, Holm
> ..viel Mühe..braucht man das wirklich?
Nein, aber wenn das Feature zur Hälfte funktioniert sollte man schon
entsheiden, ob man es ganz oder gar nicht haben will. Und wenn man dann
alle Informationen für die Entscheidung hat, möchte man sie nicht
einfach ungenutzt wegwerfen, zumal der eigentliche Fix nur wenige Zeilen
sind:
1 | @@ -325,6 +324,24 @@ void do_msg_cpm_login(uint8_t subf, int len, uint8_t * msg) |
2 | debug_cpmsd("## %7lu open: '%s', (env: '%s'), res: %d\n", get_timer(0),
|
3 | drv_table[drv].img_name, disk_buffer, res); |
4 | |
5 | + if (!res && f_size(&drv_table[drv].fd) < CONFIG_CPM_DISKSIZE) {
|
6 | + unsigned int bw; |
7 | + |
8 | + debug_cpmsd(" expanding image file from %ld to %ld\n",
|
9 | + f_size(&drv_table[drv].fd), CONFIG_CPM_DISKSIZE); |
10 | + |
11 | + res = f_lseek(&drv_table[drv].fd, CONFIG_CPM_DISKSIZE-CONFIG_CPM_BLOCK_SIZE); |
12 | + if (!res) {
|
13 | + memset(disk_buffer, 0xe5, CONFIG_CPM_BLOCK_SIZE); |
14 | + res = f_write(&drv_table[drv].fd, disk_buffer, CONFIG_CPM_BLOCK_SIZE, &bw); |
15 | + if (res || bw < CONFIG_CPM_BLOCK_SIZE) {
|
16 | + debug_cpmsd(" failed! res: %d, bytes written: %u\n", res, bw);
|
17 | + } |
18 | + drv_table[drv].dirty = true; |
19 | + bg_setstat(handle_cpm_drv_to, 1); |
20 | + } |
21 | + } |
22 | + |
23 | /* send result*/ |
24 | msg_cpm_result(subf, 0x00, res); |
25 | } |
26 | @@ -359,11 +376,11 @@ void do_msg_cpm_rw(uint8_t subf, int len, uint8_t * msg) |
18 um genau zu sein, davon 3 Leerzeilen und 3 nur für schließende Klammern und 4 Zeilen Debug-Code, die die meiste Arbeit machen, also 9 Zeilen Netto. ;-)
1 | A>d:power7c |
2 | |
3 | |
4 | POWER 3.07 on CP/M 3.1 B Z |
5 | |
6 | Copyright (c) 1981, 1982, 1983 by PAVEL BREDER |
7 | CHECK faster by WD 12/06/83 |
8 | |
9 | A0= |
> Warum? Da gibts nur eine Begründung: Bug.
Klar, ich würde aber schon gerne wissen, wo dieser Bug ist. Die
Wahrscheinlichkeit ist zwar gering, aber er könnte ja auch in meiner
Software sein. Bei dem CF-Karten-Treiber hatte ich so einen seltsamen
Effekt, für den ich über 3 Wochen keine Erklärung hatte. Dann bin ich
endlich mit dem Debugger durch, was bei einem gebankten System ja auch
nicht ganz einfach ist. Und siehe da: Ein Seiteneffekt bei SELDSK, einer
standardisierten Funktion in der ich gar nichts geändert hatte. Im
cfio-Treiber war Multi-Sector-IO noch nicht realisiert, deshalb wurde
der Sector-Count dort nicht auf 0 oder 1 zurückgesetzt. Wenn dann wieder
auf ein SD-Karten-Laufwerk umgeschaltet wurde, wurden von dort statt
einem gleich mehrere Sektoren gelesen, und Daten im RAM überschrieben.
Hier die Schaltung zum SIDE Interface. Da es relativ aufgeräumt im Layout zu geht, kann das Disk-Modul zwischen die Stiftleisten gelegt werden. Damit wird die Aufsatzplatine auf den Z180-Stamp nicht sehr hoch.
Sieht gut aus. Mit LV-Gattern habe ich nicht getestet, sollte aber mindestens genau so gut funktionieren, wie HC-Gatter. Habe ich das richtig in Erinnerung, daß bei reinem 5V-Betrieb des Systems, die 5V dann auf Pin B1 der Z180-Stamp liegen? Der Test mit 5V steht bei mir noch aus. Mir fällt jetzt auf, daß bei dem gewinkelten Wannenstecker die Aussparung für den Verpolungs-Schutz oben liegt. D.h., der Strom-Anschlußstecker des Pollinmoduls (den wir nicht brauchen), kommt nach unten und sollte dort Platz haben. Dafür kommt "das Gesicht" nach oben, schön. Bei meinem Prototypen habe ich nur eine gewinkelte Stiftleiste eingelötet und genau andersrum belegt, also Verpolschutz nach unten. Die Stiftleiste sitzt so dicht an der Platine, daß ich die Verpolschutznase stutzen mußte. Auf die Leiste passt aber mein CF-Adapter, dh. seine Buchsenleiste ist eigentlich falsch herum montiert. Jetzt sehe ich, daß auf ebay alle billigen Adapter unter 5€ falsch sind. Für den richtigen muß man dort schon über 10€ ausgeben[2]. Das nur als Hinweis, falls jemand einen CF-Adapter statt des Pollin-Moduls verwenden möchte. [1] z.B. http://www.ebay.de/itm/1PCS-Compact-Flash-CF-to-3-5-Female-40-Pin-IDE-Bootable-Adapter-Converter-Card-/401085955462?hash=item5d6295fd86:g:nFYAAOSwZ8ZW4UXy [2] http://www.ebay.de/itm/Delock-IDE-Adapter-Delock-IDE-40Pin-CF-Card-I-II-/361562029374?hash=item542ec6bd3e:g:7lsAAOSwboVXO4az
Leo C. schrieb: > Habe ich das richtig in Erinnerung, daß bei reinem 5V-Betrieb des > Systems, die 5V dann auf Pin B1 der Z180-Stamp liegen? Vielen Dank für den Hinweis. Auf B1 liegen immer nur 3.3V oder bei 5V Betrieb nichts :-( Auf die Schaltung muss also noch ein Jumper 3.3V/5V bzw. es müssen beide Pins B1 und B2 beschaltet werden. Es gibt an den Stamp-Steckern kein Vcc-Pin. > Strom-Anschlußstecker des Pollinmoduls (den wir nicht brauchen), kommt > nach unten und sollte dort Platz haben. An dieser Stelle hat die LP ein Loch. > Das nur als Hinweis, falls jemand einen > CF-Adapter statt des Pollin-Moduls verwenden möchte. Mein Bestand an 128 MB DiskOnModulen sollte für alle potentiellen Nachnutzer reichen. Melde mich nun bis Sonntag ab, schönes WE!
Danke. Falls es keine Mühe macht, könnte man für die LED vielleicht zusätzlich 2 Bohrungen vorsehen? Wenn das ganze Paket in ein 19"-Gehäuse gesteckt wird, könnte man dann eine LED auf der Frontpatte montieren und dort anschließen.
Leo C. schrieb: > Falls es keine Mühe macht, könnte man für die LED vielleicht zusätzlich > 2 Bohrungen vorsehen? Kein Problem, sehe ich noch vor.
Joe G. schrieb: [..] > Mein Bestand an 128 MB DiskOnModulen sollte für alle potentiellen > Nachnutzer reichen. > > Melde mich nun bis Sonntag ab, schönes WE! Ich weiß nicht so recht wohin mit diesem Modul, da ich Huckepack nicht vorgesehen habe und eher auf eine Einschubmimik aus war bzw. bin (ECB). Ich hatte aber über die Anschaffung von so ein paar DOM Modulen nachgedacht..hast Du Dich "zu voll" gesogen? Willst Du wieder welche los werden oder wie soll ich das verstehen? Die Dinger gibts ja noch für nen Äppel und ein Obst.. Ich habe hier einige IMHO nur 8 oder 16MB "Festplatten" von Sandisk da, die ich mal aus irgend welchen Fujuitsu-Siemens 486er Pizzabox-Schachteln geborgen habe, die haben richtige 40polige IDE Pfostenleisten... Gruß, Holm
Holm T. schrieb: > Willst Du wieder welche los > werden oder wie soll ich das verstehen? Ich lasse wieder 10 Leiterplatten fertigen und würde die restlichen Bauelemente besorgen. Dann kann jeder Interessent selber entscheiden, Komplettbausatz incl. DOM oder nur LP. P.S.: Die USB (VNC2) to V24 Schaltung (Steckmodul auf dem ECB) lasse ich gleich mit fertigen.
Oops, gerade gemerkt, daß mein Artikel gestern Abend garnicht raus ging. Mal wieder auf Vorschau statt Absenden geklickt. Beim Lesen unten Heute gegen Gestern tauschen. Holm T. schrieb: > Ich weiß nicht so recht wohin mit diesem Modul, da ich Huckepack nicht > vorgesehen habe und eher auf eine Einschubmimik aus war bzw. bin (ECB). Huckepack kann man ja nachrüsten, oder die Schaltung auf eine ECB-Lochrasterplatte löten. > Ich hatte aber über die Anschaffung von so ein paar DOM Modulen > nachgedacht..hast Du Dich "zu voll" gesogen? Willst Du wieder welche los > werden oder wie soll ich das verstehen? Beitrag "Re: Z180-Stamp Modul" > Ich habe hier einige IMHO nur 8 oder 16MB "Festplatten" von Sandisk da, > die ich mal aus irgend welchen Fujuitsu-Siemens 486er > Pizzabox-Schachteln geborgen habe, die haben richtige 40polige IDE > Pfostenleisten... Die könnten auch funktionieren, wenn Du ein IDE-Kabel dazwischen steckst. Aber die Pollin DOM's wären die schlankere Lösung. Was definitiv nicht an dem Interface funktioniert, sind "moderne" IDE-Festplatten. Heute habe ich eine 20GB WD Caviar und eine 30GB Seagate ausprobiert. Die verstehen den Befehl "Enable 8-bit data transfers" nicht.
Hallo! Dann möchte ich mich gerne schon mal wieder für einen Komplettsatz anmelden ;-) Ich weiß viel zu früh, aber nur für die Akten... Lg Harald
..naja, ich fasse auch nach Joe..also für mich auch die Platinen als Satz. Falls Jemand alte IDE Festplatten haben will, ich habe davon hunderte da..allerdings müßte man deren Status von Fall zu Fall überprüfen. Gruß, Holm
Softwareupdate
Wesentliche Änderung: Statt der Environment-Variablen 'dsk0'..'dsk7'
gibt es ein "attach" Kommando. Das ganze ist noch nicht zu Ende gedacht
(und programmiert), und "die usability" läßt vielleicht noch etwas zu
wünschen übrig. Deshalb wäre ich an gründlichen Tests und
Verbesserungsvorschlägen interessiert.
Die bisherigen Variablen kann man weiterverwenden, wenn man sie jeweils
einem attach-Befehl übergibt: "attach dsk0 ${dsk0}"
Oder für alle auf einmal eine Variable definiert:1 | setenv attach_drives 'at dsk0 ${dsk0};at dsk1 ${dsk1};at dsk2 ${dsk2};at dsk3 ${dsk3};at dsk4 ${dsk4};at dsk5 ${dsk5};at dsk6 ${dsk6};at dsk7 ${dsk7}'
|
Dann muß man nur noch "run attach_drives" irgendwo in seine Boot-Sequenz einbauen. Es gibt jetzt aber auch die Möglichkeit, Befehlsfolgen in einer Datei abzulegen, und mit "source filename" zu laden und auszuführen. Sonstiges: - Der Befehl mw kann jetzt 16- und 32-bit Worte ins RAM schreiben (Optionen -w und -l) - Kommentare in Befehlszeilen, wg. source-Befehl. Kommentarzeichen: "#" - Der Befehl loadcpm3 initialisiert eine weitere Env-Variable: cpm3_scb Sie enthält nach dem Laden die physikalische Basisaddresse des CP/M 3 System Control Blocks. Die Offsets zu den Einträgen sind unter http://www.seasip.info/Cpm/scb.html gelistet. Es sind nicht die aus der DR-Dokumentation. Außerdem gibt es ein Update für das CP/M 3 BIOS. Es ist für die neue Monitor-Version nicht zwingend notwendig, aber: - Bessere Unterstützung der neuen Features, da die neuen Fehlercodes (Write protected, Media change) ausgewertet werden. - Der Treiber für die CF-Karte wurde in den master branch integriert. Dadurch ist der Sourcecode auch auf dem Git-Server.
Noch ein paar Anmerkungen zu dem attach-Befehl. Erstens ist die Hilfe zu dem Befehl fehlerhaft und unvollständig. Daran hatte ich erst wieder dran gedacht, nachdem das Zip-File schon gepackt war. Hier ist eine Auflistung der derzeit möglichen Formate und Optionen:
1 | attach [-rw] [-o options] dsk<n> diskfile |
2 | Attach diskfile to dsk<n>, where n in 0..7 |
3 | -r File is read only (write protected) |
4 | -w File is read/write (default) |
5 | -o options Options is a comma-separated list of |
6 | ro, rw, debug, nodebug |
7 | |
8 | attach [-rw] -o reattach[,other options] dsk<n> |
9 | Change options for dsk<n>. |
10 | Options as above. |
11 | |
12 | attach -d -a|dsk<n> |
13 | detach -a|dsk<n> |
14 | Detach diskfile from dsk<n>. |
15 | -a Detach all. |
16 | |
17 | attach |
18 | Without arguments, list current assignments |
Mit 'reattach' kann man (bisher) nur die Optinen ändern und nicht die dem Laufwerk zugeordnete Datei. Dafür war dieses Format
1 | attach [-rw] -o reattach[,other options] dsk<n> diskfile |
vorgesehen, aber die ganzen Plausibilitätsprüfungen waren mir erst mal zu aufwendig. Zum "Diskwechsel" braucht es also 2 Befehle (detach alt/attach neu) Die Option "debug" gibt beim Zugriff auf die Laufwerke einige Meldungen auf der AVR-Console aus, die vorher durch eine compile time option zuschaltbar waren. Die Meldungen wurden eigentlich eingebaut, um den Treiber selbst zu debuggen, waren aber z.B. vor kurzem hilfreich, einen Fehler in "POWER 3.07" aufzudecken. Das kann bei Bedarf noch ausgebaut werden. Detach setzt im BIOS die Media change Flags ("Door open"). Eigentlich meine ich, alles so implementiert zu haben, wie im "System Guide, Appendix A, Removable Media Considerations" beschrieben. Es funktioniert aber nicht so, wie von mir erwartet, was an einem Fehler irgendwo, oder an meiner Erwartung liegen kann. Vielleicht probierts mal jemand aus.
(Nichts) neues von der Festplattenfront. Ich habe nochmal 4 alte IDE-Platten zwischen 1,2G und 8,6G ausgegraben, und an dem CF-Interface getestet. Aber nicht mal die Quantum Bigfoot (Erinnert sich noch jemand?) kann mit 8 Bit. Gestern Abend bin ich zufällig nochmal über das hier gestolpert: Holm T. schrieb: > $ zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/M > > SLR180 Copyright (C) 1985-86 by SLR Systems Rel. 1.31 #SB3028 > > boot/M > VERSION.INC - Bad Dummy Param Line 00001 > defvers macro\r\n db '0.6.4.4-dirty'\r\n endm\r > DEFVERS - > Line Too > jjxqfkjjzwyjlzgjijijpsfgj\d]zuhj\dzuhjx~xrtwjpqhw{fHjjwuywujjnxstrrthjjn xsrh > DEFVERS - Line Too Long Line 00002 Holm, kann es sein, daß die Datei "version.inc" mit Make auf Deinem FreeBSD generiert wurde? Dann liegt es wahrscheinlich am nicht portablen "echo" das von Make verwendet wurde. Inzwischen habe ich gelernt, daß das portable "echo" "printf" heißt. Du könntest das Makefile also mal folgendermaßen ändern:
1 | version.inc: autorevision.cache |
2 | @echo update $@ |
3 | printf "defvers macro\r\n\ |
4 | db '$(VERS)'\r\n\ |
5 | endm\r\n" > $@ |
Dabei das "\n" ganz am Ende nicht vergessen. Natürlich kann man das System auch auf einem CP/M-Rechner generieren. Dafür habe ich mal alles was man braucht *) in ein Disk-Image gepackt. Mit "mkbcpm3.sub" (Make Banked CP/M 3) kann dann das BIOS assembliert und ein neues CPM3.SYS-File generiert werden. *) und mehr. Aktuell werden nur slr180.com link80.com und gencpm.com genutzt. Die anderen Assembler und Linker sind nur der Vollständigkeit halber, und falls jemand andere Präferenzen hat, dabei.
So ganz Unrecht scheinst Du nicht zu haben Leo:
1 | $ ls |
2 | Makefile chario.180 move.180 |
3 | ascip.180 conbuf.180 msgbuf.180 |
4 | autorevision.cache config.inc scb.180 |
5 | bioskrnl.180 cpm3.lib sdio.180 |
6 | bioskrnl.lst cpm3slr.lib time.180 |
7 | bioskrnl.rel drvtbl.180 utils.180 |
8 | boot.180 gencpm.dat version.inc |
9 | boot.com misc.180 z180.lib |
10 | boot.lst mm.180 z180reg.inc |
11 | boot.rel modebaud.inc |
12 | $ gmake |
13 | zxcc /usr/local/lib/cpm/bin80/slr180.com -bioskrnl/MFS |
14 | zxcc /usr/local/lib/cpm/bin80/slr180.com -chario/MFS |
15 | zxcc /usr/local/lib/cpm/bin80/slr180.com -drvtbl/MFS |
16 | zxcc /usr/local/lib/cpm/bin80/slr180.com -move/MFS |
17 | zxcc /usr/local/lib/cpm/bin80/slr180.com -time/MFS |
18 | zxcc /usr/local/lib/cpm/bin80/slr180.com -mm/MFS |
19 | zxcc /usr/local/lib/cpm/bin80/slr180.com -misc/MFS |
20 | zxcc /usr/local/lib/cpm/bin80/slr180.com -utils/MFS |
21 | zxcc /usr/local/lib/cpm/bin80/slr180.com -msgbuf/MFS |
22 | zxcc /usr/local/lib/cpm/bin80/slr180.com -conbuf/MFS |
23 | zxcc /usr/local/lib/cpm/bin80/slr180.com -ascip/MFS |
24 | zxcc /usr/local/lib/cpm/bin80/slr180.com -sdio/MFS |
25 | zxcc /usr/local/lib/cpm/bin80/slr180.com -scb/MFS |
26 | zxcc link80 -bnkbios3=bioskrnl,boot,chario,drvtbl,move,time,mm,misc,utils,msgbuf,conbuf,ascip,sdio,scb[b,q] |
27 | zxcc: Cannot locate link80, link80.com, link80.COM, link80.cpm _or_ link80.CPM |
28 | Makefile:158: die Regel für Ziel „bnkbios3.spr“ scheiterte |
29 | gmake: *** [bnkbios3.spr] Fehler 1 |
30 | $ |
..nun muß ich mal den Linker suchen, irgendwo liegt der rum... Danke!! Gruß, Holm Edit: Ich habe den umbenannten l80.com da hin kopiert, aber irgendwas spinnt wohl immer noch:
1 | $ ls |
2 | Makefile boot.com cpm3.lib misc.180 msgbuf.180 utils.180 |
3 | ascip.180 chario.180 cpm3slr.lib mm.180 scb.180 z180.lib |
4 | bioskrnl.180 conbuf.180 drvtbl.180 modebaud.inc sdio.180 z180reg.inc |
5 | boot.180 config.inc gencpm.dat move.180 time.180 |
6 | $ gmake |
7 | zxcc /usr/local/lib/cpm/bin80/slr180.com -bioskrnl/MFS |
8 | update version.inc |
9 | zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/MFS |
..dort hängts dann für immer und der zxcc mach 100% Auslastung seines Kerns. Beim ersten Mal lief das durch... hmm.. Gruß, Holm
Der Linker ist in dem Diskimage, daß ich gestern gepostet habe. Es ist der Linker von DR, der zu RMAC gehört. Im Original heißt der wahrscheinlich link.com. Ich habe ihn bei mir zu link80.com umbenannt, weil ich schon einen anderen link.com hatte, und weil er in der Doku auch so ähnlich genannt wird (LINK-80).
Ja, seit ich dem einen umbenannten link.com unter geschoben habe gehts auch besser, als nächstes dann gencpm, da habe ich auch irgendwas auf meinem Rechner gefunden und der findet dann BNKBDOS3.SPR nicht. Ich hatte im Web keinen link80.com gefunden, aber eine Doku die das Ding als Lnk-80 von Microsoft verkaufte, die Syntax in der Doku war die des L80..deswegen der Versuch.. Ich mache das nochmal in Ruhe und es ist logisch das die Sachen auf Deinem Image zu finden sind, ich muß sie nur erst mal da raus holen :-) Probiert habe ich sowieso noch mit der 0.6.4.4-dirty Version. Interessant bleibt das das echo in Make inkompatibel bleibt, ich hatte wohl version.inc schon mal editiert deswegen lief das das erste Mal, oder es war eine File von Dir. Ich hatte schon Gnu-Make (gmake) benutzt. Ob ich den zxcc mit gcc48 oder mit CLANG übersetze scheint übrigens keinen Unterschied zu machen, nur das CLANG mehr meckert.. Ich hatte allerdings zwischenzeitlich auch die atime auf meinem zfs eingeschaltet, kann sein das das auch einen Unterschied gemacht hat. Ich wollte mich heute sowieso mal damit befassen, gestern lag nämlich auch ein 33Mhz Z180 aus China (von janeh2100) im Briefkasten, den wollte ich zumindest mal mit 18Mhz testen... Gruß, Holm BTW: Was haltet Ihr von einem Modul oder einer weiteren Platine mit u.A. einem WD37C65 oder DP8473 drauf?
> zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/MFS > > ..dort hängts dann für immer und der zxcc mach 100% Auslastung seines Da CP/M-Programme (und der Emulator) keine brauchbaren Fehlercodes an die Unix-Shell liefern, wird im Makefile die Ausgabe des Assemblers in eine Datei umgeleitet, und danach nach Fehlern ausgewertet. Manchmal verlangt slr180 aber eine Eingabe vom Benutzer, zB. wenn er eine Seite voll mit Fehlern produziert hat. Durch die Umleitung sieht man davon nichts. Um zu sehen welcher Fehler das sein könnte ist es am Einfachsten, die Zeile
1 | zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/MFS |
direkt in der Shell auszuführen. > Ich mache das nochmal in Ruhe und es ist logisch das die Sachen auf > Deinem Image zu finden sind, ich muß sie nur erst mal da raus holen :-) Eigentlich wars so gedacht, die Sachen da drin zu lassen und das Image an ein CP/M-System anzuschließen. :-) Die anderen fehlenden Teile (gencpm.com, bnkbdos3.spr, ...) sind aber auch in dem Image.
Leo C. schrieb: >> zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/MFS >> >> ..dort hängts dann für immer und der zxcc mach 100% Auslastung seines > > Da CP/M-Programme (und der Emulator) keine brauchbaren Fehlercodes an > die Unix-Shell liefern, wird im Makefile die Ausgabe des Assemblers in > eine Datei umgeleitet, und danach nach Fehlern ausgewertet. Manchmal > verlangt slr180 aber eine Eingabe vom Benutzer, zB. wenn er eine Seite > voll mit Fehlern produziert hat. Durch die Umleitung sieht man davon > nichts. Um zu sehen welcher Fehler das sein könnte ist es am > Einfachsten, die Zeile >
1 | > zxcc /usr/local/lib/cpm/bin80/slr180.com -boot/MFS |
2 | > |
> direkt in der Shell auszuführen. > Ja ich weiß :-) Im Optimalfalle ohne "FS". > >> Ich mache das nochmal in Ruhe und es ist logisch das die Sachen auf >> Deinem Image zu finden sind, ich muß sie nur erst mal da raus holen :-) > > Eigentlich wars so gedacht, die Sachen da drin zu lassen und das Image > an ein CP/M-System anzuschließen. :-) > Die anderen fehlenden Teile (gencpm.com, bnkbdos3.spr, ...) sind aber > auch in dem Image. ..auch das war mir verhältnismäßig klar :-) Wenn Du aber auf die Idee kommst mein Crossdevelopment-System in Ordnung bringen zu wollen..? BTW: Das mit den Platten wundert mich nicht. Tilman Reh hat das GIDE Interface mit 8<>16Bit Umschaltmimik konstruiert als IDE Platten noch nicht wirklich Gigabytes halten konnten. Die 8-Bit fähigen IDE Platten stammen noch aus XT Zeiten und waren damals neu, Du kannst also bei 40-120MB IDE Platten fündig werden.. Die GIDE verwendet 2 74LS646 die sich mittlerweile als Engpaß erweisen, der Einsatz eines kleinen CPLD wäre da wohl sinnvoller, aber auch da werden die 5V Typen knapp. DAS CF Karten Interface ist aus meiner sich eh ein Bisschen "fragwürdig", Flash Memory war mit den SD Karten ja schon abgedeckt, ich sehe keinen wirklich großen Zusatznutzen, es sei denn Du wolltest da eigentlich Festplatten anschließen. Gruß, Holm
> Im Optimalfalle ohne "FS". Gelegentlich brauche ich ein gescheites Listing zum Debuggen. Und da das im Emulator in 0 Zeit erstellt wird... > BTW: Das mit den Platten wundert mich nicht. Mich auch nicht. Hatte ich ja auch schon im ersten Beitrag zum CF-IF (Beitrag "Re: Z180-Stamp Modul") geschrieben. Aber die Hoffnung stirbt ja bekanntlich zu letzt. Außerdem wollte ich testen, ob mein Treiber auch mit so was umgehen kann, ohne hängen zu bleiben oder abzustürzen. Dafür hätte ich natürlich keine 6 Platten durchprobieren müssen. > DAS CF Karten Interface ist aus meiner sich eh ein Bisschen > "fragwürdig", Flash Memory war mit den SD Karten ja schon abgedeckt, ich > sehe keinen wirklich großen Zusatznutzen, es sei denn Du wolltest da > eigentlich Festplatten anschließen. SD geht halt nicht so einfach. Beim Stamp-System nimmt der AVR dem Z180 die Ansteuerung ab. Aber es soll ja Leute geben, die so etwas nicht mögen. Mit dem CF-IF bekommt man auf einfache Weise schnellen Massenspeicher an den Z180, von dem er mit einem kleinen Bootloader auch direkt jedes beliebige Betriebssystem booten könnte. Mit den Pollinmodulen wirds auch noch spottbillig. Festplatten will ich mir nicht (mehr) wirklich antun, sonst gäbe es wahrscheinlich schon ein Interface ala GIDE. > BTW: Was haltet Ihr von einem Modul oder einer weiteren Platine mit u.A. > einem WD37C65 oder DP8473 drauf? Nur zu.
Leo C. schrieb: > > Festplatten will ich mir nicht (mehr) wirklich antun, sonst gäbe es > wahrscheinlich schon ein Interface ala GIDE. Festplatte oder CF/SD ist aber auch ziemlich egal, nur das vertraute Geräusch fehlt bei CF :-) Ob eine CF zuverlässiger als eine Platte ist bleibt noch fraglich. > >> BTW: Was haltet Ihr von einem Modul oder einer weiteren Platine mit u.A. >> einem WD37C65 oder DP8473 drauf? > > Nur zu. ..und wie? Die Teile erfordern fast keine Außenbeschaltung, in so fern ist das verhältnismäßig einfach. Die Realisierung als Stamp wie gehabt geht sicher, es wäre noch ein Stamp Platz auf einer weiteren Basisplatine frei.. aber auch auf der Basisplatine könnte man noch zusätzlichen Kram unterbringen, eben z.B. ein CF Interface und einen FDC ..oder Netzwerk ..keine Ahnung. Gruß, Holm
Holm T. schrieb: > BTW: Was haltet Ihr von einem Modul oder einer weiteren Platine mit u.A. > einem WD37C65 oder DP8473 drauf? Aber nur in Verbindung mit einem 8 Zoll Laufwerk [1] ;-) [1] Beitrag "Re: Z180-Stamp Modul"
Leo C. schrieb: > Natürlich kann man das System auch auf einem CP/M-Rechner generieren. > Dafür habe ich mal alles was man braucht *) in ein Disk-Image gepackt. > Mit "mkbcpm3.sub" (Make Banked CP/M 3) kann dann das BIOS assembliert > und ein neues CPM3.SYS-File generiert werden. >
1 | [..] |
2 | H>era conbuf.rel |
3 | H>era ascip.rel |
4 | H>era sdio.rel |
5 | H>era cfio.rel |
6 | H>era scb.rel |
7 | H>gencpm AUTO |
8 | |
9 | |
10 | CP/M 3.0 System Generation |
11 | Copyright (C) 1982, Digital Research |
12 | |
13 | |
14 | |
15 | *** CP/M 3.0 SYSTEM GENERATION DONE *** |
16 | H> |
..und der Chinesenprozessor geht auch. Gruß, Holm
Joe G. schrieb: > Holm T. schrieb: >> BTW: Was haltet Ihr von einem Modul oder einer weiteren Platine mit u.A. >> einem WD37C65 oder DP8473 drauf? > > Aber nur in Verbindung mit einem 8 Zoll Laufwerk [1] ;-) > > [1] Beitrag "Re: Z180-Stamp Modul" Das hebt mich aber gar nicht an. Ich habe 2 NEC FD1165 da und einen 8 Zoll Beisteller aus der DDR mit 2 MF6400 und ich habe noch mindestens 3 Kartons mit Schachteln voller neuer Disketten... Auch den Gebrauchtbestand eines Forschungsinstitutes am Ort ... Das was Du da hast sieht aus wie die Dinger die die Ungarn immer nachgebaut haben (MF3200 / http://www.robotrontechnik.de/index.htm?/html/komponenten/fs.htm) Du must schon tiefer in die Trickkiste greifen wenn Du mich schocken willst :-) Gruß, Holm
1 | ### Reset reason(s): Power on, External, Brown out. |
2 | |
3 | ATmega1281+Z8S180 Stamp Monitor - Version: 0.6.7.1 |
4 | |
5 | ### main_loop entered: bootdelay=3 |
6 | |
7 | ### main_loop: bootcmd="pin 8 low 3 9MHz; run attach_drives;loadcpm ${cpm3_file}; go ${startaddress}"
|
8 | Hit any key to stop autoboot: 0 |
9 | Loading: '0:cpm3.sys'... |
10 | |
11 | BNKBIOS3 SPR FA00 0500 |
12 | BNKBIOS3 SPR B200 3E00 |
13 | RESBDOS3 SPR F400 0600 |
14 | BNKBDOS3 SPR 8400 2E00 |
15 | |
16 | 61K TPA |
17 | Loaded: Resident: 0x1E400-0x1EEFF, Banked: 0x08400-0x0EFFF |
18 | ## Starting application at 0xb200 ... |
19 | => z80_memfifo_init: 0, b65a |
20 | z80_memfifo_init: 1, b69e |
21 | z80_memfifo_init: 2, b81a |
22 | z80_memfifo_init: 3, b83e |
23 | ................................. |
24 | |
25 | |
26 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.7.1.2-dirty |
27 | Estimated CPU clock [Hz]: 18432000 |
28 | sdio: SD Card driver |
29 | cfio: CompactFlash Memory Card driver: No Card |
30 | A> |
...funzt Leo... Gruß, Holm
Leo was mich noch nervt sind die ASCI Treiber, jedesmal wenn ein neues Laufwerk eingeloggt wird verliert der Kram Character die ich eintippere.. (c:<cr>dir<cr>) Ich habe reingeguckt..alles klar: "; Simple polling drivers for ASCI0 and ASCI1 " Kannst Du das hier evtl da reinbasteln? http://www.tiffe.de/Robotron/LC80ex/TDL-Basic/2016021100/ctcsio.mac ..hab ich gemacht. Das sind zumindest funktionierende serielle Treiber mit Interrupt und Puffer für die SIO auf einem LC80ex. Zeitgeber und ASCI Bits wirst Du natürlich anpassen müssen..aber zumindest das Gerüst ist schon fertig. Du stehst deutlich tiefer in der Materie als ich. Gruß, Holm
> Leo was mich noch nervt sind die ASCI Treiber, jedesmal wenn ein neues > Laufwerk eingeloggt wird verliert der Kram Character. Ist mir noch nie aufgefallen. Du bist der Erste, der sich (zurecht) beschwert. Daß beim "Pasten" mit der Maus Zeichen verloren gehen, hat mich auch schon genervt. > "; Simple polling drivers for ASCI0 and ASCI1 " Mehr oder weniger funktionierende Interrupt-Treiber gibts schon seit ca. einem Jahr. Beim Einbau von flow control habe ich mich dann wohl verzettelt, und ca. Weihnachten bin ich ganz davon abgekommen.
1 | leo@cb:~/Projekte/HD64180/z180-stamp-cpm3/cbios$ git log --format=format:"%aI %s" asci-int-driver |
2 | 2016-04-23T17:21:35+02:00 WIP |
3 | 2015-11-06T19:13:42+01:00 Add TCGETA, TCSETA |
4 | 2015-11-05T10:19:12+01:00 add ioctl data |
5 | 2015-11-02T16:56:18+01:00 working again. |
6 | 2015-10-30T10:02:26+01:00 asci0 int: Save intermediate state. Not working! |
7 | 2015-10-28T14:04:06+01:00 bugfix RTS |
8 | 2015-10-09T11:02:33+02:00 Add RTS/CTS flow control for asci0. |
9 | 2015-06-17T07:45:20+02:00 ascii.180 interrupt driver for ASCI 0/1 |
10 | 2015-10-31T02:52:30+01:00 new chario |
11 | 2015-10-30T09:50:28+01:00 bioskrnl.180: Remove xon/xoff handling. |
> Kannst Du das hier evtl da reinbasteln? Danke, aber nicht ganz passen. Die ASCIs sind doch um einiges anders als die SIO. > ..aber zumindest das Gerüst ist schon fertig. Ein Gerüst habe ich auch. :-)
Ich hoffe das die ASCIs besser sind :-) Die SIO hat zwar keine Fehler soweit aber ist ein Bisschen doof bei async. RTS wird anders ausgewertet als heute für RTS/CTS Handshake üblich, man kann es nicht abschalten so lange noch gesendet wird.. deswegen hält oben DTR her. Auf CTS ihres Gegenübers reagiert die Sio freilich gaanz lieb. Die ASCIs kenne ich (noch) nicht. man müßte mal ins Datenbuch gucken (liegt ja herum, zumindest zum HD64180, hoffe der ist identisch) aber soo groß dürfte der Unerschied nun auch wieder nicht sein, von Int-Vektoren und Baudratengenerierung mal abgesehen. Wenn ich das nochmal anfasse baue ich evtl. Makros ein.. BTW: Beim HI-Tech C 3.09 ist Mathe nicht so prall..
1 | F>test |
2 | Test 4 * 7 = 28 |
3 | Pi: 3.120122 |
4 | |
5 | F>type test.c |
6 | #include<stdio.h> |
7 | #include<float.h> |
8 | #include<math.h> |
9 | |
10 | main() |
11 | {
|
12 | int a,b; |
13 | double pi; |
14 | a=4; |
15 | b=7; |
16 | pi=4.0*atan(1.0); |
17 | |
18 | printf("Test %d * %d = %d\r\n",a,b,a*b);
|
19 | printf("Pi: %lf\r\n",pi);
|
20 | } |
Gruß, Holm
> Ich hoffe das die ASCIs besser sind :-)
Eher umgekehrt.
Zumindest was die Original-ASCI vom Hitachi HD64180 und den ersten Klon
von Zilog betrifft. Beim Z8S180 hat Zilog aber nachgebessert.
Hmm. Ich werde es mir ansehen. Wie viele Seiten Errata gibts denn? BTW: ich kann gar nicht so viel essen wie ich kotzen muß: http://www.theregister.co.uk/2016/06/09/microsoft_freebsd/ :-| Gruß, Holm
> Hmm. Ich werde es mir ansehen. Wie viele Seiten Errata gibts denn? Es sind eher fehlende und Miss-Features als harte Fehler. Break-Detection[1], und die Möglichkeit CTS und DCD "abzuschalten", wurden im Z8S180 nachgerüstet. In [2] steht ganz hinten etwas zu ASCI. > BTW: ich kann gar nicht so viel essen wie ich kotzen muß: Aufrichtiges Beileid[3]. [1] BREAK DETECTION ON Z80180 AND Z181 http://www.datasheetarchive.com/dlmain/Datasheets-41/DSA-808568.pdf [2] Z180 Family QUESTIONS AND A NSWERS http://www.wfms.org/sb180/z180qa.pdf [3] https://de.wikipedia.org/wiki/Embrace,_Extend_and_Extinguish
Von dieser Art Break Detection und Generation lese ich wirklich das erste Mal. Da waren die Hitachisten wohl ein Bisschen schräg drauf... Na gut, ich schrieb schon das Du da tiefer in der Materie steckst, ich habe zwar schon einige HD64180 oder Z180 enthaltende Kisten repariert aber noch nie programmiert. Zu [3] soweit wird es wohl nicht kommen. Wenn Mickeysoft so weiter macht schaffen die sich eh ab. Gruß, Holm
Neuer Versuch. Laufwerks-Login sollte jetzt besser funktionieren, wenn die SD-Karte gezogen, und wieder gesteckt wird. Das Debug-Logging ist jetzt einigermaßen brauchbar. Neues Kommando "bootcf" um von CF-Card booten zu können. Im BIOS wurde die Console auf ASCI1 mit 115200 Baud gestellt. ASCI1 (die 2. Serielle) war ja schon immer als Defaulteinstellung für die Console vorgesehen.
Leo C. schrieb: > Neuer Versuch. > Laufwerks-Login sollte jetzt besser funktionieren, wenn die SD-Karte > gezogen, und wieder gesteckt wird. Das Debug-Logging ist jetzt > einigermaßen brauchbar. > Neues Kommando "bootcf" um von CF-Card booten zu können. ..wenig Zeit heute... > > Im BIOS wurde die Console auf ASCI1 mit 115200 Baud gestellt. > ASCI1 (die 2. Serielle) war ja schon immer als Defaulteinstellung für > die Console vorgesehen. Warum die 2.? Üblicherweise ist 0 die Console.. Gruß, Holm
Die Erste hat mehr Steuerleitungen. ASCI0: RTS0, CTS0, DCD0 ASCI1: CTS1, aber nur, wenn man die Clocked-Serial-I/O nicht verwenden will. Fürs Consolen-Terminal reicht normalerweise eine Schnittstelle ohne Handshake. ASCI0 hat man dann frei für Modem, :-) Drucker, :-) USB-Dongle, ... RTS0 ist übrigens nur ein simpler Output-Port, könnte man also auch für ASCI1 oder sonst was verwenden.
Leo C. schrieb: > Die Erste hat mehr Steuerleitungen. > ASCI0: RTS0, CTS0, DCD0 > ASCI1: CTS1, aber nur, wenn man die Clocked-Serial-I/O nicht verwenden > will. > > Fürs Consolen-Terminal reicht normalerweise eine Schnittstelle ohne > Handshake. ASCI0 hat man dann frei für Modem, :-) Drucker, :-) > USB-Dongle, ... > > RTS0 ist übrigens nur ein simpler Output-Port, könnte man also auch für > ASCI1 oder sonst was verwenden. Ok..leuchtet ein. Ich habe jetzt mal die Version 6.8 drüber gebrezelt und das cpmldr.com auf und das cpm3test.dsk (drive A) kopiert. Das ulpert da noch als rel file herum. Was genau ist die Funktion des Files und wieso einmal als rel und einmal als com file? Ich kann doch sicher das rel-file weghacken? Ich weiß natürlich das CP/M ein Stück Programm benötigt um von irgendwoher in den RAM geladen und dann dort gestartet werden muß..ich kenne nur CP/M 3 nach wie vor nicht und bin nicht dazu gekommen mich wirklich mal eingehend mit der Sache zu befassen... Ich werde mir auch wieder mal die aktuelle Version von git holen..
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8 |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | A> |
CP/M bootet und kommt auch auf asci1 raus, allerdings bei mir mit 19200 Baud. Das hier kriege ich aber nach wie vor noch hin:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8 |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | A>h: |
6 | H>ir |
7 | IR? |
8 | H> |
das "d" habe ich natürlich mit eingegeben. Gruß, Holm
Mal ganz allgemein zum Booten (für die CP/M-Neueinsteiger unter uns) Bei CP/M 2 ist es noch ziemlich einfach: Auf einer bootfähigen Diskette ist im ersten Sektor ein "Cold Boot Loader" und in weiteren Sektoren "in einem Stück" das komplette CP/M-System, bestehend aus CCP, BDOS und BIOS. Beim Booten läd nun eine minimalistische Routine im EPROM den Cold Boot Loader irgendwo ins RAM (Stufe 1), und dieser dann die folgenden Sektoren an die CCP-Adresse (Sufe 2). Anschließend springt er auf den Kalstartvektor im BIOS, welches den Rest an Initialisierungen besorgt, und den CCP startet (Stufe 3). Sicher wird es auch Systeme gegeben haben, die vom ROM aus das komplette System geladen haben, also die Stufe 2 übersprangen. Der Vorteil der 3-stufigen Version ist, daß man das ROM nicht ändern muß, wenn sich das System mal verändert, oder ein ganz anderes System geladen werden soll. Man muß immer nur den Cold Boot Loader auf der Diskette anpassen. Bei CP/M 3 wird es etwas komplizierter, weil das System nicht mehr zusammenhängend geladen werden kann. Von BDOS und BIOS muß je ein Teil in den Common-Bereich und in Bank 0. Der CCP wird (wie ein normales Programm) an den Anfang der TPA in Bank 1 geladen. Deshalb hat DR bei CP/M 3 eine zusätliche Stufe eingeführt. In den Systemspuren ist der Cold-Boot-Loader (wie gehabt in Sektor 1) und der "CP/M 3 system loader" (CPMLDR). Dieser CPMLDR läd das CP/M 3 System aus einer ganz normalen Datei "CPM3.SYS" von der Diskette (Stufe 3). CPM3.SYS hat einen Header mit den Ladeadressen der residenten und gebankten BDOS+BIOS Teile. Der CCP wird von der Cold-Boot-Routine (Stufe 4) im BIOS geladen. Im Stamp-Monitor übernimmt der Befehl "loadcpm3" die ersten 3 Stufen des Bootvorgangs. Allerdings wird dabei CPM3.SYS direkt von der SD-Karte geladen und kann deshalb auch gerne einen längeren Namen mit Versionskennung haben. Da es ja zetzt das CF-Interface gibt, wäre es auch denkbar, ein Stamp-System ohne SD-Karten zu haben. Da die CF-Karte direkt am Z180 hängt, muß der Z180 auch alleine booten. Also ab Stufe 2, die "ROM-Routine" zum laden des Cold-Boot-Loaders wird vom Stamp-Monitor mit dem Befehl "bootcf" ins RAM geladen. Diese "ROM-Routine" kann aber auch mehr als einen Sektor, und deshalb z.B gleich den CPMLDR laden. > cpmldr.com aufund das cpm3test.dsk (drive A) kopiert. Normalerweise gehört der CPMLDR in die Systemspuren. Da er aber auf Adresse 100h gelinkt ist, könnte man ihn auch als normales Programm starten. Praktisch zum Debuggen. Das funktioniert aber mit dieser Version nicht, da dieser CPMLDR in Bank 0 laufen muß. > Das ulpert da noch als rel file herum. Das REL-File ist der früher von DR gelieferte Teil des Laders. Der Haußteil darin ist ein abgespecktes CP/M 3 BDOS, in dem nur Consolen-Ausgabe und die Funktionen für das Laden einer Datei enthalten sind. Dazu wird dann das eigene Loader-BIOS gelinkt, das ebenfalls nur diese Funktionen unterstützt. Mein Loader-BIOS hat nur Unterstützung für die CF-Karte. Außerdem wird die Console auf 115200 Baud initialisiert. > Was genau ist die Funktion des Files und wieso einmal als rel und einmal > als com file? Ich kann doch sicher das rel-file weghacken? Du brauchst es, wenn Du einen neuen CPMLDR bauen willst ("make ldr" oder "MKCPMLDR.SUB"). Aber heutzutage kannst Du es Dir ja aus den Sourcen wieder herstellen[1]. > wirklich mal eingehend mit der Sache zu befassen... Ausführliche Beschreibung in [2]. > Ich werde mir auch wieder mal die aktuelle Version von git holen.. Eigentlich müßten ältere Versionen auch funktionieren. Falls Make beim "autorevision" hängen bleibt, daß ist ein eigenständiges Programm[3]. > CP/M Version 3.0, Z180-Stamp BIOS v0.6.8 ... > CP/M bootet und kommt auch auf asci1 raus, allerdings bei mir mit 19200 > Baud. Keine Ahnung, wie ich das hinbekommen habe. Die 0.6.8 Datei hat bei mir auch 19200. Offensichtlich hatte ich damit nicht getestet. Auf der SD-Karte ist auch nur Version 0.6.7.1.7-dirty. Und die hat 115200, obwohl die Änderung der Baudrate der letzte Schritt vor dem taggen mit 0.6.8 war. Man kann die Baudrate auch im cpm3_x.sys File patchen. Einfach in der Datei nach ASCI1 suchen, und mit einem Binär-Editor (oder dd) das 2. Byte danach (hier auf 3c0), auf den gewünschten Index setzen. 0f ist 19200 und 04 wäre 115200.
1 | 000003a0 ab b4 c9 cd 64 fd b6 b4 c9 55 53 42 30 20 20 03 |....d....USB0 .| |
2 | 000003b0 00 41 53 43 49 30 20 0f 0f 41 53 43 49 31 20 0f |.ASCI0 ..ASCI1 .| |
3 | 000003c0 0f 00 74 bb 97 bb ba bb dd bb 00 bc 23 bc 46 bc |..t.........#.F.| |
> A>h: > H>ir > IR? > H> Anscheinend hatte ich noch nie so schnell nach einem Laufwerkswechsel "dir" eingetippt, aber jetzt habe ich das auch. Beim Wechsel auf ein neues Laufwerk wird erst mal das ganze Directory eingelesen. Das dauert etwas (1024 Einträge == 64 Sektoren). Trotzdem sollte nichts verschluckt werden, weil die ASCI einen 4 Byte großen Puffer hat. Wahrscheinlich wird das Zeichen von der BDOS-Consolenroutine oder vom CCP verschluckt. Nicht schön, und ein Interrupt-Treiber würde dann auch nicht helfen.
1 | A>^C |
2 | A>a: |
3 | A>ir |
Nachtrag, da ich eh gerade an dem Interrupt-Treiber bin. Stimmt, hilft tatsächlich nicht:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8.9-asci-int-driver-dirty |
2 | Estimated CPU clock [Hz]: 9216000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | |
6 | A>^C |
7 | A>a: |
8 | A>ir |
[1] http://www.cpm.z80.de/download/cpm3src_unix.zip [2] https://archive.org/stream/CPM3-System_Guide#page/n105/mode/2up [3] https://autorevision.github.io/
Bekommen wir den FDC37C665GT gehandelt Leo? Die IDE Geschichte nützt uns wahrscheinlich Nichts, aber 2S mit FIFO und 1P sind wohl verwendbar. Die Dinger gibts in der Bucht für Kleingeld und auf ollen Mainboards sicher auch..aber das Gehäuse..TQFP100. Das paßt auch bei einer 2 Lagen Platine sicher nicht mehr auf eine Stamp. DRQ Signale haben wir 2, wie ist denn das mit den DMA-End Signalen? Brauchen wie noch ne CIO als _Int-Conroller? Irgendwo gabs eine Zilog Applikation zur Nachbildung der ED4D Mimik... Gruß, Holm
Holm T. schrieb: > Bekommen wir den FDC37C665GT gehandelt Leo? Warum unbedingt ein Floppy Disk Controller? Wenn du den FDC37C665GT und einen Z80182 nutzen möchtest, warum denn nicht gleich das P112-System [1]? Den gibt es mit CP/M 2.2 CP/M 3.0 UZI180 und sogar mit FUZIX :-) [1] https://en.wikipedia.org/wiki/P112
Joe G. schrieb: > Holm T. schrieb: >> Bekommen wir den FDC37C665GT gehandelt Leo? > > Warum unbedingt ein Floppy Disk Controller? Wenn du den FDC37C665GT und > einen Z80182 nutzen möchtest, warum denn nicht gleich das P112-System > [1]? > Den gibt es mit CP/M 2.2 CP/M 3.0 UZI180 und sogar mit FUZIX :-) > > [1] https://en.wikipedia.org/wiki/P112 Ich verstehe Deine Frage nicht Joe. ..wieso "unbedingt" und wieso "unbedingt nicht?" Ich habe nicht gesagt das Du routen mußt, das würde ich selber versuchen auch wenn ich noch nie ne Platine mit einem TQFP-100 gemacht habe. Es ist nicht nur ein FDC der mir fehlt, sondern auch GPIOs und das System von Dir habe ich, den P112 nicht. Was also hast Du für ein Problem damit das ich an den ECB-Bus Stecker ranhängen will was mir gefällt? An einem CP/M Rechner gehören Floppies und ich habe Floppies da, so what? Gruß, Holm
Holm T. schrieb: > Was also hast Du für ein > Problem damit das ich an den ECB-Bus Stecker ranhängen will was mir > gefällt? Oh, ich habe kein Problem damit - immer zu! Ich wollte nur eine Alternative anbieten.
Die Alternative zu nehmen wäre eine Mißachtung auch Deiner Arbeit und die Anzahl der Baustellen würde wieder um 1 incrementiert werden. Als problematisch erweist sich allerdings der hohe SYSCLK von 18Mhz, die 16Mhz PIOs werden gerade noch so funktionieren und auch "modernere" Peripherie ICs haben keine höheren Taktfrequenzen, selbst wenn man bei artfremden Systemen räubern will wird es da finster.. Ich hätte gerne eine Spielkiste, Console gerne seriell da mir der Aufwand ein Terminal selber zu bauen angesichts oller Notebooks nicht einleuchtend ist. Ich würde aber gerne mal an ein paar Pins eine Anzeige/einen ROM oder I2C oder Sonstwas anhängen "um mal an den Beinen zu wackeln".. und ich würde gerne Daten mit anderen CP/M Rechnern austauschen wollen, daher die Floppy oder auch die Netzwerkgeschichte. Ein System ohne Peripherie kann ich auch im Emulator (cpmsim, simh) laufen lassen ohne mir Gedanken zu machen woher das bootet oder ob der Platz alle wird. Das ist meine Intention, meinst Du ich liege falsch? Gruß, Holm
Holm T. schrieb: > Ich hätte gerne eine Spielkiste, So geht/ging es mir auch. Daher ja "mein" Projekt, da mal eine Bus-Anzeige mit 7-Segment dran zu hängen (komme nur zeitlich nicht dazu, siehe Schaltung oben). Meine Frage, ob die BUS-Treiber den hohen Takt können, hängt da auch noch in der Luft. Und ich habe auch noch eine ganze Kiste "alter" Zilog-Techik hier, die ich eigentlich gerne an den Bus anbinden wollte - aber das war ja auch nicht das primäre Ziel der Entwickler - dafür gäbe es wahrscheinlich genug andere Kisten (ich habe ja noch den NDR Kleincomputer hier :-)). Trotzdem.... Aber dass die 18MHz ein Problem sind, hätte mir klar sein müssen :-)
> Bekommen wir den FDC37C665GT gehandelt Leo? Mein Interesse an Floppies ist auch sehr begrenzt, entsprechend meine Motivation für so ein Projekt. > Das paßt auch bei einer 2 Lagen Platine sicher nicht mehr auf eine > Stamp. Das geht wohl schon wegen der vielen Stecker nicht. > DRQ Signale haben wir 2, wie ist denn das mit den DMA-End Signalen? Für die DMA-Kanäle des Chips wird man wohl DACK-Signale brauchen. Und die haben wir nicht. Bei IDE kann der Z180-DMA den Port im PIO-Mode lesen/schreiben und so einen ganzen Sektor auf einmal übertragen. Bei Floppy und Parallel-Port geht das aber nicht. > Brauchen wie noch ne CIO als _Int-Conroller? Stilecht für den FDC37C665GT wäre ja ein 8259A, und die CPU im IM0 betreiben. Man könnte auch alle INT-Ausgänge des Chips verodern und auf INT1 oder INT2 des Z180 legen, oder auf beide verteilen... > Irgendwo gabs eine Zilog > Applikation zur Nachbildung der ED4D Mimik... Ich könnte mir vorstellen, daß ein halbierter CLock für Z80-Peripherie am ECB einfacher zu realisieren wäre. Für die alten 4-6 MHz PIOs, SIOs und CTCs wäre das aber immer noch zu schnell.
Joe G. schrieb: > und sogar mit FUZIX :-) Das steht auch auf meiner TODO-Liste für das Stamp-System. Aber ich bin ja mit dem CP/M-Kram schon ausgelastet. Marcel A. schrieb: > Trotzdem.... Aber dass die 18MHz ein Problem sind, hätte mir klar sein > müssen :-) Du weißt aber schon, daß man die Taktfrequenz beliebig runter setzten kann. Und für Deine geplanten Spielereien mit 7-Segment und anderem I/O-Kram kommts auf die MHz ja wirklich nicht an. Und für den möglichen Lerneffekt auch nicht.
Leo C. schrieb: >> Bekommen wir den FDC37C665GT gehandelt Leo? > > Mein Interesse an Floppies ist auch sehr begrenzt, entsprechend meine > Motivation für so ein Projekt. > >> Das paßt auch bei einer 2 Lagen Platine sicher nicht mehr auf eine >> Stamp. > > Das geht wohl schon wegen der vielen Stecker nicht. Die hätten mit auf die Stamp gemusst.. und dann gänge da nur irgend ein HD Kram oder Flexleiter.. nicht das Gelbe vom Ei. > >> DRQ Signale haben wir 2, wie ist denn das mit den DMA-End Signalen? > > Für die DMA-Kanäle des Chips wird man wohl DACK-Signale brauchen. Und > die haben wir nicht. Bei IDE kann der Z180-DMA den Port im PIO-Mode > lesen/schreiben und so einen ganzen Sektor auf einmal übertragen. Bei > Floppy und Parallel-Port geht das aber nicht. Ich habe indessen bei der P112 Mimik gelesen das die das wegen der Eigenheit des Z182 DMA das TerminalCount im Speicherschreibzyklus (multiplex) auszugeben dieses gar nicht verwenden können, weil sie es im IO Lesezyklus und nicht im Speicherschreibzyklus brauchen...und desegen ohne arbeiten. Der FDC generiert wohl einen Timout Error der abgefangen wird, das kann also nicht das Problem sein..aber halt keine DMA. Der Z180/Z8S180 scheint sich in dieser Hinsicht identisch zu verhalten nach dem was ich gelesen habe. > >> Brauchen wie noch ne CIO als _Int-Conroller? > > Stilecht für den FDC37C665GT wäre ja ein 8259A, und die CPU im IM0 > betreiben. Ich lasse über eine PIO oder einen CIO mir mir reden, aber nicht über einen 8259, da dieser nur Int Controller kann, die anderen mir aber die GPIOs bringen die ich gerne hätte. > Man könnte auch alle INT-Ausgänge des Chips verodern und auf INT1 oder > INT2 des Z180 legen, oder auf beide verteilen... Der "Super-IO-Chip" 37C665 hat wohl 4 Int Ausgänge (FINTR,PINTR1,IRQ3,IRQ4) für jeden Kram einzeln. Sehr wahrscheinlich ist ein Oder hier ein guter Ansatz, ggf. noch mit einem Latch das eingelesen werden kann.. oder halt eine PIO als "Konzentrator". Ich hatte ein Zilog PDF in der Hand in de die IM2 Mimik in einem EP610 beschrieben war (die Dinger hätte ich sogar und kann sie programmieren) aber ein kleines CPLD wäre hier wohl angebrachter.. > >> Irgendwo gabs eine Zilog >> Applikation zur Nachbildung der ED4D Mimik... > > Ich könnte mir vorstellen, daß ein halbierter CLock für Z80-Peripherie > am ECB einfacher zu realisieren wäre. Für die alten 4-6 MHz PIOs, SIOs > und CTCs wäre das aber immer noch zu schnell. Die Teile gibts aber locker bis 10Mhz darüber wird es eng. PIOs habe ich ja bis 16Mhz und mein Kumpel hat wohl genug für uns Alle hier. Timer sind IMHO nicht so wichtig (intern vorhanden) und Serielle haben wir auch an und für sich genug. (mit dem FDC kämen noch 2 dazu..wenn man sie nutzen will). Ich überschaue aber nicht aus dem Hut wo das bei Interruptbedienung etc überall scherbeln kann. Dazu müßte ich mir auch mal rein ziehen was der ZS180 maximal an Waitstates einzufügen in der Lage ist und wie das konkrete Timing dann aussieht. Beim FDC könnte man sehr wahrscheinlich große Teile des Treibers vom P112 Projekt übernehmen so das das nicht ganz so stressig werden würde. Der Hauptaufwand steckt wohl in der Anpassung der DPH usw., man muß ja auch nicht unbedingt von Floppies booten können... @Marcel: ...eine Busanzeige brauche ich nicht mehr :-) Sowas habe ich zu tiefsten DDR Zeiten gebaut (Multiplexer, Decoder, 7Seg und jede Menge LEDs für die Steuersignale Sowie CUL Draht auf Lochraster) und mich soweit satt gesehen :-) Ich habe auch noch eine K1520 Bedieneiheit K7622 da die ich erst kürzlich repariert habe, die macht genau das und auch Refresh dynamischer Speicher im WAIT....allerdings nur mit 6(!) Bit..muß ich wohl erweitern.. Damit kann man auch einen ROMlosen Computer starten, hat was von Kernspeicher und Console Feeling.. (http://www.robotrontechnik.de/index.htm?/html/zubehoer/bde.htm) Gruß, Holm
Leo C. schrieb: > Joe G. schrieb: >> und sogar mit FUZIX :-) > > Das steht auch auf meiner TODO-Liste für das Stamp-System. Aber ich bin > ja mit dem CP/M-Kram schon ausgelastet. > ..Du machst Dich zur Feile für uns :-) Ich habe mal heute nebenbei ein Bisschen mit BDS C rumprobiert und Dabei ein paar Zeilen aus der Maus ins Terminalprogramm richtung Wordstar fallen lassen. Das ging nicht gut..das ging gar nicht und war IMHO mit ASCI0 schon mal besser. Da landet nur abgehakter Kauderwelsch im WS, egal ob 19200 oder 115200Bd. Das ist ein Hinweis, keine Nörgelei. Wenn ich das richtig verstadnen habe gibts auf ASCI1 gar keine richtige Flußkontrolle mehr... Gruß, Holm
Leo C. schrieb: >> go 0x000 > > Das funktioniert nur zufällig richtig. Die Parameter bei diesen Befehlen > sind grundsätzlich Hex. 0x muß nicht und darf nicht angegeben werden. > Die Inputroutine ist allerdings schlampig programmiert und liest nur bis > zum ersten ungültigen Zeichen, hier 'x'. Alles davor wird als Zahl > gnommen, hier 0. Schon 'ne Weile her. Daran war leider! nur der Satz mit der schlampigen Programmierung richtig. Der Prefix '0x' wird nämlich von strtoul() einfach überlesen (ignoriert), wenn man Zahlen zur Basis 16 einlesen will. Jedenfalls werden jetzt alle Zahleineingaben überprüft, und die Eingabe von z.B "0y123" generiert einen Fehler, statt stillschweigend "0" zu übernehmen. Als Bonus können statt einfacher Zahlen jetzt auch überall einfache arithmetische Ausdrücke eingegeben werden. Bisher nur die 4 Grundrechenarten (+,-,*,/,%) und Klammern. Erweiterungen sind bei Bedarf leicht möglich. Ausdrücke dürfen keine Leerzeichen enthälten oder müssen in einfache oder doppelte Anführungszeichen gesetzt werden. Als Konsequenz der neuen Eingaberoutine ergibt sich, daß wirklich alle numerischen Befehls-Argumente grundsätzlich als Hex-Zahlen interpretiert werden. Vorher war das bei einigen wenigen Befehlen anders (z.B. sleep). Dezimalzahlen kann man eingeben, indem man ein '$' voranstellt. Ich hätte lieber '#' genommen, aber das müßte jedesmal "gequoted" werden, da es bereits als Kommentarzeichen verwendet wird. Außerdem neu: History-search für die Kommandozeile. Unten nochmal die aktuelle und hoffentlich vollständige Liste. Sollten Tasten nicht so funktionieren, bitte melden. Insbesondere HOME und END scheinen Kandidaten zu sein, die in jeder Terminalemulation andere Codes schicken.
1 | Taste(n) Funktion |
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 |
15 | Bild-Auf, PAGEUP history-search-backward |
16 | Bild-Ab, PAGEDOWN history-search-forward |
...Streß..keine Zeit zum ausprobieren.. wollte wenigstens mal ein Ping von mir geben.. Gruß, Holm
Ich habe gerade die letzte Monitorversion
(stamp-monitor_hexrel-6.8.1.hex) sowie das BIOS (cpm3_0.6.7.1.sys)
installiert. Nun komme ich jedoch mit der Syntax des "attach" Kommandos
nicht klar.
setenv attach_drives 'at dsk0 ${1:/cpm3_a.dsk};at dsk1
${1:/cpm3_b.dsk};at dsk2 ${0:/cpm3_c.dsk}'
CP/M starte zwar, findet jedoch dann kein Laufwerk. Wie muss ich die
Laufwerke korrekt angeben?
CP/M Version 3.0, Z180-Stamp BIOS v0.6.7.1
Estimated CPU clock [Hz]: 18432000
sdio: SD Card driver
cfio: CompactFlash Memory Card driver: No Card
CP/M Error On A: Invalid Drive
BDOS Function = 15 File = CCP .COM
A>
Die Frage hat sich erledigt. Das System läuft :-) Danke Leo! setenv attach_drives 'at dsk0 1:/cpm3_a.dsk;at dsk1 1:/cpm3_b.dsk;at dsk2 0:/cpm3_c.dsk'
Bei mir noch die Vorgängerversion, aber drhet sich schon ein paar Wochen:
1 | => printenv |
2 | attach_drives=at dsk0 ${dsk0};at dsk1 ${dsk1};at dsk2 ${dsk2};at dsk3 ${dsk3};at dsk4 ${dsk4};at dsk5 ${dsk5};at dsk6 ${dsk6};at dsk7 ${dsk7}
|
3 | baudrate=115200 |
4 | bootcmd=pin 8 low 3 9MHz; run attach_drives;loadcpm ${cpm3_file}; go ${startaddress}
|
5 | bootdelay=3 |
6 | cpm3_commonbase=f000 |
7 | cpm3_file=0:cpm3_0.6.8.sys |
8 | cpm3_scb=1e900 |
9 | dsk0=0:/cpm3test.dsk |
10 | dsk1=0:/diskb.dsk |
11 | dsk2=0:/diskc.dsk |
12 | dsk3=0:/diskd.dsk |
13 | dsk4=0:/diske.dsk |
14 | dsk5=0:/diskf.dsk |
15 | dsk6=1:/diskg.dsk |
16 | dsk7=1:/diskh.dsk |
17 | esc_char=0x40 |
18 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
19 | startaddress=b300 |
20 | |
21 | Environment size: 574/1597 bytes |
22 | => |
..nur für den Fall das Jemand mal was nachsehen möchte.. Gruß, Holm
Ich hatte geträumt :-( Das Geheimnis hieß „run attach_drives“. Leo C. schrieb: > Unten nochmal die aktuelle und hoffentlich vollständige Liste. Bei mir gehen alle Funktionen. > Natürlich kann man das System auch auf einem CP/M-Rechner generieren. Erzeugt problemlos ein BIOS. Anwelcher Stelle im Quelltext finde ich eigentlich die Baudrate für ASCI1? Sie läuft ja noch auf 19200. Im Binärfile patchen ist ja nur eine Hilfslösung ;-)
Joe G. schrieb: > Anwelcher Stelle im Quelltext finde ich > eigentlich die Baudrate für ASCI1? Sie läuft ja noch auf 19200. Im In der Datei chario.180:
1 | @ctbl: |
2 | db 'USB0 ' ; device 0 |
3 | db mb$in$out |
4 | db baud$none |
5 | |
6 | db 'ASCI0 ' ; device 1 |
7 | db mb$in$out+mb$serial+mb$soft$baud |
8 | db baud$19200 |
9 | |
10 | db 'ASCI1 ' ; device 2 |
11 | db mb$in$out+mb$serial+mb$soft$baud |
12 | db baud$19200 |
13 | |
14 | db 0 ; table terminator |
> Binärfile patchen ist ja nur eine Hilfslösung ;-)
Der neueste Monitor könnte das vielleicht zwischen Laden von cpm3.sys
und Starten automatisiert erledigen. U.a. für so was hat er kürzlich das
Rechnen gelernt. Mit der Zuweisung von logischen I/Os zu Geräten gehts
im Prinzip:1 | mw -w ${cpm3_scb}+${@civec} 8000 2
|
Mit @civec = 0BE aus dieser [1] Tabelle. Leider wirds anschließend aber wieder von der Kaltstartinitialisierung im BIOS (boot.180) überschrieben. Vielleicht ändere ich das mal bei Gelegenheit. Joe G. schrieb: > setenv attach_drives 'at dsk0 1:/cpm3_a.dsk;at dsk1 1:/cpm3_b.dsk;at > dsk2 0:/cpm3_c.dsk' Mein Beispiel mit der Variable "attach_drives" sollte ja eigentlich nur zeigen, wie man die ehemaligen Variablen "dsk0" - "dsk8" weiterverwenden kann. Aber so gehts natürlich auch. Zu dem Attach-Mechanismus würden mich doch mal ein paar kritische Meinungen interressieren. Inzwischen finde ich die "Ergonomie" doch ziemlich bescheiden, und möchte das vielleicht noch mal ändern. Z.B. einen extra Befehl "set" um die Optionen einzustellen. [1] http://www.seasip.info/Cpm/scb.html
Leo C. schrieb: > In der Datei chario.180: Danke, aber dann gibt es einen Compilerfehler. In der Datei MODEBAUD.INC, welche ja auch eingebunden wird, steht auch nur 19200 als größte Baudrate drin.
Übrigens ist da Beitrag "Re: Z180-Stamp Modul" ein BIOS mit 115200 für ASCI1 drin. Ja, die nächste Monitorversion hatte ich wieder ohne BIOS veröffentlicht. :-( 115200 als Default ist aber auch noch nicht der Weisheit letzter Schluß. Bei 9,2MHz CPU-Clock gehen die nämlich nicht...
Leo C. schrieb: > Dann mußt Du halt 134.5 oder so nehmen. Ja sicher, es muss ja auch eine 0x04 gepatcht werden, hätte ich auch drauf kommen können :-( Nun läuft auch das geänderte BIOS. > 115200 als Default ist aber auch noch nicht der Weisheit letzter Schluß. Dann sollte es vielleicht tatsächlich vom AVR übergeben werden. Du hattest es ja gerade skizziert.
Vielleicht sollte man modebaud.inc mal "modernisieren". Aber vielleicht wird die Datei ja auch bald überflüssig, wenn der interruptgesteuerte Treiber endlich kommt. Da solls dann eine "ioctl.inc" geben. Auszug:
1 | ; cflags (2) |
2 | M_CBAUD equ 01Fh ;Baud speed mask |
3 | B0 equ 000h ;hang up |
4 | B50 equ 011h |
5 | B75 equ 012h |
6 | B110 equ 013h |
7 | B134 equ 014h |
8 | B150 equ 005h |
9 | B300 equ 006h |
10 | B600 equ 007h |
11 | B1200 equ 008h |
12 | B1800 equ 009h |
13 | B2400 equ 00Ah |
14 | B3600 equ 00Bh |
15 | B4800 equ 00Ch |
16 | B7200 equ 00Dh |
17 | B9600 equ 00Eh |
18 | B19200 equ 00Fh |
19 | B28800 equ 001h |
20 | B38400 equ 002h |
21 | B57600 equ 003h |
22 | B115200 equ 004h |
23 | B144000 equ 014h |
24 | B192000 equ 016h |
25 | B288000 equ 017h |
26 | M_CSIZE equ 020h ;Character size mask. |
27 | M_CS7 equ 000h ; |
28 | M_CS8 equ 020h ; |
29 | CS8 equ 5 ; |
30 | b2m CSTOPB, 6 ;Set two stop bits, rather than one. |
31 | b2m PARENB, 7 ;Enable parity generation on output and parity checking for input. |
Hier nun endlich der Entwurf für die USB-Schnittstelle auf dem ECB-Board. Die beiden Versorgungsvarianten (5V und 3.3V) machen es notwendig einen Spannungsregler zu integrieren. Ansonsten hätte man am ECB-Board zu viel umlöten müssen. Variante 1 (ECB komplett auf 3.3V) 1. Spannungsregler IC1 wird nicht bestückt und JP3 auf 3.3V gelegt. 2. CON1 Pin 7 (5V) muss zusätzlich an Console0/USB angebracht werden. 3. /CTS0 (Pin18, IC2, auf ECB) muss an CON2, Pin1, ECB gelegt werden. Variante 2 (ECB komplett auf 5V) 1. Spannungsregler IC1 wird bestückt und JP3 auf den Spannungsregler gelegt. 2. CON1 Pin 7 (5V) entfällt. 3. /CTS0 (Pin18, IC2, auf ECB) muss an CON2, Pin1, ECB gelegt werden. CON0 – Programmer wird nicht unbedingt benötigt. Hier kann der VNC2 programmiert und debuggt werden. Es ist auch ein reines flashen über die V24 möglich [1]. Vielleicht hat ja jemand noch eine bessere Idee für dieses Modul. Möglich ist auch wieder eine Huckepackvariante auf dem Z180 Stamp. Hier könnte man einen Parallelzugriff realisieren, allerdings sind wieder Adressdecoder und Bustreiber notwendig. [1] http://www.ftdichip.com/Support/Documents/AppNotes/AN_159%20Vinculum-II%20Firmware%20Flash%20Programming.pdf
Angehängte Dateien:
-
LP.jpg
230 KB
Die LP's für das IDE-Interface sind da :-) Derzeit stehen bei mir die folgenden Interessenten auf der Liste: 1. Harald Bausatz 2. Holm Bausatz 3. Marcel Bausatz ohne DOM 4. Peter LP 5. Siggi Bausatz 6. LeoC als Dank für die Programmierung :-) Da ich 10 Platinen (+ 2 Überlieferungen) bestellt habe, können noch weitere 5 vergeben werden. Ich würde bis nächste Woche weitere Interessenten sammeln und dann Ende der Woche alles versenden. Der Platinenpreis beträgt übrigens 2,15 €/Stück.
> 6. LeoC als Dank für die Programmierung :-)
Vielen Dank. Ich melde mich nochmal dazu per EMail, wenn ich wieder zu
Hause bin.
Angehängte Dateien:
-
IMG_20160711_132021.jpg
480 KB
Das Interface ist einmal aufgebaut. Das Layout scheint korrekt und mit
18 MHz zu laufen. Jetzt bräuchte ich noch einen Hinweis, wie ich darauf
zugreife bzw. ein Laufwerk anlegen :-)
CP/M Version 3.0, Z180-Stamp BIOS v0.6.7.1.2-dirty
Estimated CPU clock [Hz]: 18432000
sdio: SD Card driver
cfio: CompactFlash Memory Card driver
Model: PQI IDE DiskOnModule, S/N: DOM3C00004268, Rev: 060729DA
Size: 256000 Sectors (128000 KiB)
Sehr schön, Joe. Jetzt wäre es ja nicht schlecht, wenn man das Partitionierprogramm hätte, daß ich hier schon angekündigt hatte... > Jetzt bräuchte ich noch einen Hinweis, wie ich darauf > zugreife bzw. ein Laufwerk anlegen :-) Das Bios unterstützt die bekannte DOS-Partitionierung mit bis zu 4 primären CP/M-Partitionen. (Typ 52). Da bisher nur das simhd-Format unterstützt wird, also maximal 4 x 8 MByte. Man kann das Modul am PC partitionieren, wenn man eine Anschlußmöglichkeit hat, z.B. USB-IDE-Adapter. Ein freier IDE-Port am PC geht natürlich auch, ist aber etwas umständlich. Im Anhang sind 2 Dateien die man für eine schnelle 4x8M Partitionierung verwenden kann: DoM-mbr-4x8M.bin: Am PC mit dd auf das DoM kopieren. DoM-mbr-4x8M.dump: Diese Datei kann von sfdisk unter Linux gelesen werden: $ sfdisk /dev/sdx < DoM-mbr-4x8M.dump Man kann die Datei vorher auch editieren. Danach sollte man die ersten 112 Sektoren der Partitionen mit 0xE5 füllen. Das Ergebnis könnte so aussehen:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8.18-int-handling-dirty |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver |
5 | Model: PQI IDE DiskOnModule, S/N: DOM5D00001323, Rev: 060729DA |
6 | Size: 256000 Sectors (128000 KiB) |
7 | I: CP/M partition at: 2048, size: 8192KiB |
8 | J: CP/M partition at: 18432, size: 8192KiB |
9 | K: CP/M partition at: 34816, size: 8192KiB |
10 | L: CP/M partition at: 51200, size: 8192KiB |
11 | |
12 | A> |
Quick&dirty CP/M-Partitionierung: Die Datei im Anhang im Debugger laden und ab Adresse 300h starten. Z.B:
1 | A>ddtz dom-part.bin |
2 | DDT/Z [8101] |
3 | High = 037F Max = 037F |
4 | > g 300 |
5 | |
6 | A> |
Leo C. schrieb: > Im Anhang sind 2 Dateien die man für eine schnelle 4x8M Partitionierung > verwenden kann: > Quick&dirty CP/M-Partitionierung: Besten Dank! Ich werde mal beide Methoden ausprobieren, habe gerade einen USB-IDE Adapter rausgekramt.
Na wenn das nichts ist!
CP/M Version 3.0, Z180-Stamp BIOS v0.6.7.1.2-dirty
Estimated CPU clock [Hz]: 18432000
sdio: SD Card driver
cfio: CompactFlash Memory Card driver
Model: PQI IDE DiskOnModule, S/N: DOM3C00004268, Rev: 060729DA
Size: 256000 Sectors (128000 KiB)
I: CP/M partition at: 2048, size: 8192KiB
J: CP/M partition at: 18432, size: 8192KiB
K: CP/M partition at: 34816, size: 8192KiB
L: CP/M partition at: 51200, size: 8192KiB
A>
Und noch ein Nachtrag. Statt die Datei dom-part.bin in ein CP/M-Image zu kopieren, kann man sie auch von der SD-Karte in den Debugger laden. Also im CP/M zuerst den Debugger starten:
1 | A>ddtz |
und dann im Monitor die Datei laden:
1 | => fatload 1:/dom-part.bin f100 |
Rest wie oben. Edit: zu spät :-)
Leo C. schrieb: > Edit: zu spät :-) Nicht ganz, allein der Hinweis ist es schon wert :-) Aber es scheint noch nicht ganz korrekt formatiert zu sein. Die anderen Laufwerke haben das gleiche Verhalten. J>dir J: : : : : J: : : : : J: : : : : J: : : : : ... J: : : : : J: : : : : J: : : : : Press RETURN to Continue
Wahrscheinlich wirds auch mit "era *.*" nicht besser? Leo C. schrieb: > Danach sollte man die ersten 112 Sektoren der Partitionen mit 0xE5 > füllen. Oder (am PC) gleich die ganze Partition. Z.B. so: # tr '\000' '\345' </dev/zero |dd of=/dev/sdf3 bs=1K count=8K Irgendwo haben wir aber auch noch das makeimage Programm. Für die RAM-Disk vom AVR-CP/M hatte ich mal ein Programm geschrieben, daß das komplette Directory mit E5 überschreibt (wipe.com). Leider funktioniert es nicht unter CP/M 3. Vielleicht ändere ich das demnächst mal. Gerade habe ich versucht, eine DoM-Partition mit 0xff zu füllen, was für Flash-Spreicher ja naheliegender wäre. Funktioniert leider nicht. Für CP/M ist das Directory dann voll.
Leo C. schrieb: > Oder (am PC) gleich die ganze Partition. > Z.B. so: # tr '\000' '\345' </dev/zero |dd of=/dev/sdf3 bs=1K count=8K Das führt zum Erfolg, danke! I,J,K,L lassen sich nun beschreiben und auch nutzen. A>show A: RW, Space: 7,224k B: RW, Space: 7,868k C: RW, Space: 7,816k D: RW, Space: 7,656k E: RW, Space: 7,752k I: RW, Space: 8,124k J: RW, Space: 8,136k K: RW, Space: 8,136k L: RW, Space: 8,136k A> Nachtrag 1: Ich stelle nun die Bausätze zusammen um sie morgen in die Post zu geben, Änderungswünsche könnten also heute noch mitgeteilt werden :-) Nachtrag 2: Wer einen Bausatz mit DOM geordert hat bekommt das Modul gleich formatiert, nicht jeder hat ja einen USB-IDE-Adapter.
:
Bearbeitet durch User
Joe G. schrieb: > Wer einen Bausatz mit DOM geordert hat bekommt das Modul gleich > formatiert, nicht jeder hat ja einen USB-IDE-Adapter. Spitze, hab mir schon gedanken gemacht...!
Hallo Joe, falls verfügbar hätte ich gerne noch einen Satz AVR/Z180-Stamp-Platinen und die ECB-Platine. Gruß Siggi
siggim schrieb: > falls verfügbar hätte ich gerne noch einen Satz AVR/Z180-Stamp-Platinen > und die ECB-Platine. Ja, ist möglich. Das ist der letzte Satz den ich noch habe :-)
:
Bearbeitet durch User
Hier die Unterlagen zum IDE-Interface. Der Aufbau sollte absolut unkompliziert möglich sein. Getestet habe ich selbst mit 3.3V und 18.432MHz. Für eine reine 5V Versorgung muss nur der Jumper JP1 umgesteckt werden. Das DOM-Modul wird selbst über den 40 poligen Steckverbinder versorgt, natürlich kann auch das zugehörige Stromversorgungskabel verwendet werden. Dummerweise ist der Stromversorgungsstecker am DOM-Modul nicht mittig zum Modul. Das ist mir erst bei der Probebestückung aufgefallen .-( Bei Verwendung der mitgelieferten Steckverbinder (Bausatz) liegt das Modul jedoch so hoch, dass die Buchse gerade noch so im Loch verschwindet, passt also. Die zum Bausatz gehörigen Module habe ich alle Formatiert. Es müssten also bei korrektem Aufbau sofort nach dem Bootvorgang die Laufwerke I: bis L: erscheinen.
siggim schrieb: > falls verfügbar hätte ich gerne noch einen Satz AVR/Z180-Stamp-Platinen > und die ECB-Platine. Ja, ist möglich. Das ist der letzte Satz den ich noch habe :-) Dann schick den doch bitte mit dem SIDE-Bausatz mit. Danke. Gruß Siggi
Hier der USB-Adapter. Die Größe beträgt 2cm x 5cm und wird direkt auf das ECB-Board gesteckt. Wenn es keine weiteren Wünsche gibt, würde ich das Board so in die Fertigung geben.
...wollte nur anmerken das ich gerade auch mal dazu gekommen bin die 6.8.1 zu flashen...funzt... ...sagmal Joe, kannst Du nicht auf die kleine USB Platine gleich noch ein paar parallele IO-Register als GPIO häkeln? Jeweils 8 Ein- und Ausgänge wären schon ne feine Sache (16 besser). Einfach ein paar primitive 74HCT... mit IO Decoder... bei den Dingern gibts auch keine Probleme mit Verfügbarkeit oder Geschwindigkeit. Gruß, Holm
Holm T. schrieb: > ...sagmal Joe, kannst Du nicht auf die kleine USB Platine gleich noch > ein paar parallele IO-Register als GPIO häkeln? Die USB-Platine sitzt auf dem V24 Steckverbinder Con2/Con3. Da gibt es keine Bussignale.
...ach Gott, wie langweilig :-| Dann hätte das wohl auf die CF Karte gemußt. Gruß, Holm
Holm T. schrieb: > ...wollte nur anmerken das ich gerade auch mal dazu gekommen bin die > 6.8.1 zu flashen...funzt... Funktionieren die Tasten für Befehlszeileneditierung :) bei Dir richtig? Insbesondere Pos1/Ende, bzw. HOME/END? > ...sagmal Joe, kannst Du nicht auf die kleine USB Platine gleich noch > ein paar parallele IO-Register als GPIO häkeln? Jeweils 8 Ein- und > Ausgänge wären schon ne feine Sache (16 besser). Einfach ein paar > primitive 74HCT... mit IO Decoder... bei den Dingern gibts auch keine > Probleme mit Verfügbarkeit oder Geschwindigkeit. Vielleicht wären ein paar Schieberigister an der Clocked-Serial-I/O (CSIO) etwas für Dich. Wenn Du auf CTS1 nicht verzichten kannst, geht nur Output. Leider hat die Schnittstelle kein CS-Signal. Man könnte RTS0 zweckentfremden, ein Monoflop nehmen, oder statt Schieberegister einen ATTINY oder stm8.
Leo C. schrieb: > Holm T. schrieb: >> ...wollte nur anmerken das ich gerade auch mal dazu gekommen bin die >> 6.8.1 zu flashen...funzt... > > Funktionieren die Tasten für Befehlszeileneditierung :) bei Dir richtig? > Insbesondere Pos1/Ende, bzw. HOME/END? ...nein, hätte ich aber auch nicht erwartet bei meinem "obskuren OS". Zwischen PgUp und Cursor Up bzw. PgDown und Cursor Down kann ich erst mal keinen -Unterschied feststellen. Bei HOME oder End tauchen nur '$' auf. Insert: ^[[2~ Delete: 0x7f Home: ^[[H End: ^[[F PgUp: ^[[5~ PgDown: ^[[6~ > >> ...sagmal Joe, kannst Du nicht auf die kleine USB Platine gleich noch >> ein paar parallele IO-Register als GPIO häkeln? Jeweils 8 Ein- und >> Ausgänge wären schon ne feine Sache (16 besser). Einfach ein paar >> primitive 74HCT... mit IO Decoder... bei den Dingern gibts auch keine >> Probleme mit Verfügbarkeit oder Geschwindigkeit. > > Vielleicht wären ein paar Schieberigister an der Clocked-Serial-I/O > (CSIO) etwas für Dich. Wenn Du auf CTS1 nicht verzichten kannst, geht > nur Output. > Leider hat die Schnittstelle kein CS-Signal. Man könnte RTS0 > zweckentfremden, ein Monoflop nehmen, oder statt Schieberegister einen > ATTINY oder stm8. Laß nur, ich hätte es gerne gehabt, kann aber Sowas auch selber, notfalls auf einer Lochrasterplatte zusammen spaxen. -Ich hatte nicht viel Zeit und die Backplane ist immer noch leer weil bei TME indessen noch keine 3-reihigen DIN41612 Muttis (96p) nachgewachsen sind. Ich mache da noch weiter, wundere mich nur das das sonst Keinen zu interessieren scheint mal was an den CP/M Rechner anschließen zu können was nicht Tastatur oder Bildschirm oder Speicher ist. Gruß, Holm
Holm T. schrieb: > mache da noch weiter, wundere mich nur das das sonst Keinen zu > interessieren scheint mal was an den CP/M Rechner anschließen zu können > was nicht Tastatur oder Bildschirm oder Speicher ist. Doch - mich. Aber ich kämpfe mit Zeit :-)
Leo C. schrieb: > Für die RAM-Disk vom AVR-CP/M hatte ich mal ein Programm geschrieben, > daß das komplette Directory mit E5 überschreibt (wipe.com). Leider > funktioniert es nicht unter CP/M 3. Vielleicht ändere ich das demnächst > mal. So, das Programm geht jetzt auch unter CP/M 3, und man kann damit z.B. neue Partitionen auf CF-Karten oder den DoMs "formatieren". Es sollte auf jedem beliebigen CP/M-(artigen) System ein vermurkstes Directory initialisieren können. Allerdings geht danach kein "Unerase" mehr. Vielleicht sollte man nur das 1. Byte jedes Directory-Eintrags mit E5 überschreiben...
Holm T. schrieb: > ...nein, hätte ich aber auch nicht erwartet bei meinem "obskuren OS". Mir scheint, unter Linux ist der Wildwuchs noch viel schlimmer. Je nach Terminalprogramm bekomme ich für HOME/END ganz unterschiedliche Codes, und mit tio jetzt auch die gleichen wie Du. > Zwischen PgUp und Cursor Up bzw. PgDown und Cursor Down kann ich erst > mal keinen -Unterschied feststellen. Tipp mal die ersten ein oder zwei Zeichen eines weiter zurück liegenden Befehls ein, und probier dann noch mal PgUp. > Bei HOME oder End tauchen nur '$' auf. Dann senden die Tasten Sequenzen, die das Programm nicht kennt. Der '$' war nur als Debug-Hilfe gedacht. > Delete: 0x7f Wie bitte, keine ESC-Sequenz? D.h., die Taste müßte bei Dir das Zeichen links vom Cursor löschen? Und was sendet dann die Backspace-Taste? > Home: ^[[H > End: ^[[F Die habe ich jetzt eingebaut. Kommt dann in die nächste Version. Bis dahin kannst Du Ctrl-A und Ctrl-E verwenden. > Insert: ^[[2~ > PgUp: ^[[5~ > PgDown: ^[[6~ Die sollten funktionieren wie erwartet. Insert schaltet allerdings den Curser nicht um. Man sieht also nicht, ob man im Insert- oder Overwrite-Mode ist.
...das ist nicht unbedingt ein Wildwuchs sondern normal :-) Im Endeffekt kommt das was im X-Server als mapping definiert ist. Du bekommst also immer Ergebnisse je nach dem welches Mapping vom Terminalprogramm installiert ist, oder eben das Defaultmapping vom Xterm durchgereicht. Was wirklich stattfindet bekommt man mit xev (dem X Event Tester) heraus: der Reihenfolge nach Insert, Delete, Home, End, PgUp, PgDown:
1 | KeyPress event, serial 38, synthetic NO, window 0x7200001, |
2 | root 0x256, subw 0x0, time 2526825146, (51,69), root:(59,112), |
3 | state 0x10, keycode 106 (keysym 0xff63, Insert), same_screen YES, |
4 | XLookupString gives 0 bytes: |
5 | XmbLookupString gives 0 bytes: |
6 | XFilterEvent returns: False |
7 | |
8 | KeyRelease event, serial 38, synthetic NO, window 0x7200001, |
9 | root 0x256, subw 0x0, time 2526825230, (51,69), root:(59,112), |
10 | state 0x10, keycode 106 (keysym 0xff63, Insert), same_screen YES, |
11 | XLookupString gives 0 bytes: |
12 | XFilterEvent returns: False |
13 | |
14 | KeyPress event, serial 38, synthetic NO, window 0x7200001, |
15 | root 0x256, subw 0x0, time 2526825655, (51,69), root:(59,112), |
16 | state 0x10, keycode 107 (keysym 0xffff, Delete), same_screen YES, |
17 | XLookupString gives 1 bytes: (7f) "" |
18 | XmbLookupString gives 1 bytes: (7f) "" |
19 | XFilterEvent returns: False |
20 | |
21 | KeyRelease event, serial 38, synthetic NO, window 0x7200001, |
22 | root 0x256, subw 0x0, time 2526825725, (51,69), root:(59,112), |
23 | state 0x10, keycode 107 (keysym 0xffff, Delete), same_screen YES, |
24 | XLookupString gives 1 bytes: (7f) "" |
25 | XFilterEvent returns: False |
26 | |
27 | KeyPress event, serial 38, synthetic NO, window 0x7200001, |
28 | root 0x256, subw 0x0, time 2526826150, (51,69), root:(59,112), |
29 | state 0x10, keycode 97 (keysym 0xff50, Home), same_screen YES, |
30 | XLookupString gives 0 bytes: |
31 | XmbLookupString gives 0 bytes: |
32 | XFilterEvent returns: False |
33 | |
34 | KeyRelease event, serial 38, synthetic NO, window 0x7200001, |
35 | root 0x256, subw 0x0, time 2526826224, (51,69), root:(59,112), |
36 | state 0x10, keycode 97 (keysym 0xff50, Home), same_screen YES, |
37 | XLookupString gives 0 bytes: |
38 | XFilterEvent returns: False |
39 | |
40 | KeyPress event, serial 38, synthetic NO, window 0x7200001, |
41 | root 0x256, subw 0x0, time 2526826644, (51,69), root:(59,112), |
42 | state 0x10, keycode 103 (keysym 0xff57, End), same_screen YES, |
43 | XLookupString gives 0 bytes: |
44 | XmbLookupString gives 0 bytes: |
45 | XFilterEvent returns: False |
46 | |
47 | KeyRelease event, serial 38, synthetic NO, window 0x7200001, |
48 | root 0x256, subw 0x0, time 2526826713, (51,69), root:(59,112), |
49 | state 0x10, keycode 103 (keysym 0xff57, End), same_screen YES, |
50 | XLookupString gives 0 bytes: |
51 | XFilterEvent returns: False |
52 | |
53 | KeyPress event, serial 38, synthetic NO, window 0x7200001, |
54 | root 0x256, subw 0x0, time 2526827154, (51,69), root:(59,112), |
55 | state 0x10, keycode 99 (keysym 0xff55, Prior), same_screen YES, |
56 | XLookupString gives 0 bytes: |
57 | XmbLookupString gives 0 bytes: |
58 | XFilterEvent returns: False |
59 | |
60 | KeyRelease event, serial 38, synthetic NO, window 0x7200001, |
61 | root 0x256, subw 0x0, time 2526827228, (51,69), root:(59,112), |
62 | state 0x10, keycode 99 (keysym 0xff55, Prior), same_screen YES, |
63 | XLookupString gives 0 bytes: |
64 | XFilterEvent returns: False |
65 | |
66 | KeyPress event, serial 38, synthetic NO, window 0x7200001, |
67 | root 0x256, subw 0x0, time 2526827674, (51,69), root:(59,112), |
68 | state 0x10, keycode 105 (keysym 0xff56, Next), same_screen YES, |
69 | XLookupString gives 0 bytes: |
70 | XmbLookupString gives 0 bytes: |
71 | XFilterEvent returns: False |
72 | |
73 | KeyRelease event, serial 38, synthetic NO, window 0x7200001, |
74 | root 0x256, subw 0x0, time 2526827748, (51,69), root:(59,112), |
75 | state 0x10, keycode 105 (keysym 0xff56, Next), same_screen YES, |
76 | XLookupString gives 0 bytes: |
77 | XFilterEvent returns: False |
Xmodmap -pke erzählt die aktuelle Belegung au der Standardausgabe: [code]$ xmodmap -pke keycode 8 = Mode_switch NoSymbol Mode_switch keycode 9 = Escape NoSymbol Escape keycode 10 = 1 exclam 1 exclam onesuperior exclamdown onesuperior keycode 11 = 2 quotedbl 2 quotedbl twosuperior oneeighth twosuperior keycode 12 = 3 section 3 section threesuperior sterling threesuperior keycode 13 = 4 dollar 4 dollar onequarter currency onequarter keycode 14 = 5 percent 5 percent onehalf threeeighths onehalf keycode 15 = 6 ampersand 6 ampersand notsign fiveeighths notsign keycode 16 = 7 slash 7 slash braceleft seveneighths braceleft keycode 17 = 8 parenleft 8 parenleft bracketleft trademark bracketleft keycode 18 = 9 parenright 9 parenright bracketright plusminus bracketright keycode 19 = 0 equal 0 equal braceright degree braceright keycode 20 = ssharp question ssharp question backslash questiondown U1E9E keycode 21 = acute grave acute grave cedilla cedilla cedilla keycode 22 = BackSpace BackSpace BackSpace BackSpace NoSymbol NoSymbol Terminate_Server keycode 23 = Tab ISO_Left_Tab Tab ISO_Left_Tab keycode 24 = q Q q Q at Greek_OMEGA at keycode 25 = w W w W lstroke Lstroke lstroke keycode 26 = e E e E EuroSign EuroSign EuroSign keycode 27 = r R r R paragraph registered paragraph keycode 28 = t T t T tslash Tslash tslash keycode 29 = z Z z Z leftarrow yen leftarrow keycode 30 = u U u U downarrow uparrow downarrow keycode 31 = i I i I rightarrow idotless rightarrow keycode 32 = o O o O oslash Oslash oslash keycode 33 = p P p P thorn THORN thorn keycode 34 = udiaeresis Udiaeresis udiaeresis Udiaeresis diaeresis diaeresis diaeresis keycode 35 = plus asterisk plus asterisk asciitilde macron asciitilde keycode 36 = Return NoSymbol Return keycode 37 = Control_L NoSymbol Control_L keycode 38 = a A a A ae AE ae keycode 39 = s S s S U017F U1E9E U017F keycode 40 = d D d D eth ETH eth keycode 41 = f F f F dstroke ordfeminine dstroke keycode 42 = g G g G eng ENG eng keycode 43 = h H h H hstroke Hstroke hstroke keycode 44 = j J j J dead_belowdot dead_abovedot dead_belowdot keycode 45 = k K k K kra ampersand kra keycode 46 = l L l L lstroke Lstroke lstroke keycode 47 = odiaeresis Odiaeresis odiaeresis Odiaeresis doubleacute doubleacute doubleacute keycode 48 = adiaeresis Adiaeresis adiaeresis Adiaeresis asciicircum asciicircum asciicircum keycode 49 = asciicircum degree asciicircum degree notsign notsign notsign keycode 50 = Shift_L NoSymbol Shift_L keycode 51 = numbersign apostrophe numbersign apostrophe grave grave grave keycode 52 = y Y y Y guillemotright U203A guillemotright keycode 53 = x X x X guillemotleft U2039 guillemotleft keycode 54 = c C c C cent copyright cent keycode 55 = v V v V doublelowquotemark singlelowquotemark doublelowquotemark keycode 56 = b B b B leftdoublequotemark leftsinglequotemark leftdoublequotemark keycode 57 = n N n N rightdoublequotemark rightsinglequotemark rightdoublequotemark keycode 58 = m M m M mu masculine mu keycode 59 = comma semicolon comma semicolon periodcentered multiply periodcentered keycode 60 = period colon period colon U2026 division U2026 keycode 61 = minus underscore minus underscore endash emdash endash keycode 62 = Shift_R NoSymbol Shift_R keycode 63 = KP_Multiply KP_Multiply KP_Multiply KP_Multiply KP_Multiply KP_Multiply XF86ClearGrab keycode 64 = Alt_L Meta_L Alt_L Meta_L keycode 65 = space NoSymbol space keycode 66 = Caps_Lock NoSymbol Caps_Lock keycode 67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 keycode 68 = F2 F2 F2 F2 F2 F2 XF86Switch_VT_2 keycode 69 = F3 F3 F3 F3 F3 F3 XF86Switch_VT_3 keycode 70 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4 keycode 71 = F5 F5 F5 F5 F5 F5 XF86Switch_VT_5 keycode 72 = F6 F6 F6 F6 F6 F6 XF86Switch_VT_6 keycode 73 = F7 F7 F7 F7 F7 F7 XF86Switch_VT_7 keycode 74 = F8 F8 F8 F8 F8 F8 XF86Switch_VT_8 keycode 75 = F9 F9 F9 F9 F9 F9 XF86Switch_VT_9 keycode 76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10 keycode 77 = Num_Lock NoSymbol Num_Lock keycode 78 = Scroll_Lock NoSymbol Scroll_Lock keycode 79 = KP_Home KP_7 KP_Home KP_7 keycode 80 = KP_Up KP_8 KP_Up KP_8 keycode 81 = KP_Prior KP_9 KP_Prior KP_9 keycode 82 = KP_Subtract KP_Subtract KP_Subtract KP_Subtract KP_Subtract KP_Subtract XF86Prev_VMode keycode 83 = KP_Left KP_4 KP_Left KP_4 keycode 84 = KP_Begin KP_5 KP_Begin KP_5 keycode 85 = KP_Right KP_6 KP_Right KP_6 keycode 86 = KP_Add KP_Add KP_Add KP_Add KP_Add KP_Add XF86Next_VMode keycode 87 = KP_End KP_1 KP_End KP_1 keycode 88 = KP_Down KP_2 KP_Down KP_2 keycode 89 = KP_Next KP_3 KP_Next KP_3 keycode 90 = KP_Insert KP_0 KP_Insert KP_0 keycode 91 = KP_Delete KP_Separator KP_Delete KP_Separator keycode 92 = keycode 93 = keycode 94 = less greater less greater bar brokenbar bar keycode 95 = F11 F11 F11 F11 F11 F11 XF86Switch_VT_11 keycode 96 = F12 F12 F12 F12 F12 F12 XF86Switch_VT_12 keycode 97 = Home NoSymbol Home keycode 98 = Up NoSymbol Up keycode 99 = Prior NoSymbol Prior keycode 100 = Left NoSymbol Left keycode 101 = keycode 102 = Right NoSymbol Right keycode 103 = End NoSymbol End keycode 104 = Down NoSymbol Down keycode 105 = Next NoSymbol Next keycode 106 = Insert NoSymbol Insert keycode 107 = Delete NoSymbol Delete keycode 108 = KP_Enter NoSymbol KP_Enter keycode 109 = Control_R NoSymbol Control_R keycode 110 = Pause Break Pause Break keycode 111 = Print Sys_Req Print Sys_Req keycode 112 = KP_Divide KP_Divide KP_Divide KP_Divide KP_Divide KP_Divide XF86Ungrab keycode 113 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift keycode 114 = keycode 115 = Super_L NoSymbol Super_L keycode 116 = Super_R NoSymbol Super_R keycode 117 = Menu NoSymbol Menu keycode 118 = keycode 119 =keycode 120 = keycode 121 = keycode 122 = keycode 123 = keycode 124 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift keycode 125 = NoSymbol Alt_L NoSymbol Alt_L keycode 126 = KP_Equal NoSymbol KP_Equal keycode 127 = NoSymbol Super_L NoSymbol Super_L keycode 128 = NoSymbol Hyper_L NoSymbol Hyper_L keycode 129 = keycode 130 = keycode 131 = keycode 132 = keycode 133 = keycode 134 = KP_Decimal KP_Decimal KP_Decimal KP_Decimal keycode 135 = keycode 136 = keycode 137 = keycode 138 = keycode 139 = keycode 140 = keycode 141 = keycode 142 = keycode 143 = keycode 144 = XF86AudioPrev NoSymbol XF86AudioPrev keycode 145 = keycode 146 = keycode 147 = keycode 148 = keycode 149 = keycode 150 = XF86Sleep NoSymbol XF86Sleep keycode 151 = keycode 152 = keycode 153 = XF86AudioNext NoSymbol XF86AudioNext keycode 154 = keycode 155 = keycode 156 = NoSymbol Meta_L NoSymbol Meta_L keycode 157 = keycode 158 = keycode 159 = keycode 160 = XF86AudioMute NoSymbol XF86AudioMute keycode 161 = XF86Calculator NoSymbol XF86Calculator keycode 162 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause keycode 163 = keycode 164 = XF86AudioStop XF86Eject XF86AudioStop XF86Eject keycode 165 = keycode 166 = keycode 167 = keycode 168 = keycode 169 = keycode 170 = XF86Eject NoSymbol XF86Eject keycode 171 = keycode 172 = keycode 173 = keycode 174 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume keycode 175 = keycode 176 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume keycode 177 = keycode 178 = XF86WWW NoSymbol XF86WWW keycode 179 = keycode 180 =keycode 181 = keycode 182 = keycode 183 = keycode 184 = keycode 185 = keycode 186 = keycode 187 = keycode 188 = keycode 189 = keycode 190 = keycode 191 = keycode 192 = keycode 193 = keycode 194 = keycode 195 = keycode 196 = keycode 197 = keycode 198 = keycode 199 = keycode 200 = keycode 201 = keycode 202 = keycode 203 = keycode 204 = XF86Eject NoSymbol XF86Eject keycode 205 = keycode 206 = keycode 207 = keycode 208 = keycode 209 = keycode 210 = keycode 211 = keycode 212 = keycode 213 = keycode 214 = XF86Display NoSymbol XF86Display keycode 215 = XF86KbdLightOnOff NoSymbol XF86KbdLightOnOff keycode 216 = XF86KbdBrightnessDown NoSymbol XF86KbdBrightnessDown keycode 217 = XF86KbdBrightnessUp NoSymbol XF86KbdBrightnessUp keycode 218 = keycode 219 = keycode 220 = keycode 221 = keycode 222 = XF86PowerOff NoSymbol XF86PowerOff keycode 223 = XF86Standby NoSymbol XF86Standby keycode 224 = keycode 225 = keycode 226 = keycode 227 = XF86WakeUp NoSymbol XF86WakeUp keycode 228 = keycode 229 = XF86Search NoSymbol XF86Search keycode 230 = XF86Favorites NoSymbol XF86Favorites keycode 231 = XF86Reload NoSymbol XF86Reload keycode 232 = XF86Stop NoSymbol XF86Stop keycode 233 = XF86Forward NoSymbol XF86Forward keycode 234 = XF86Back NoSymbol XF86Back keycode 235 = XF86MyComputer NoSymbol XF86MyComputer keycode 236 = XF86Mail NoSymbol XF86Mail keycode 237 = XF86AudioMedia NoSymbol XF86AudioMedia keycode 238 = keycode 239 = keycode 240 = keycode 241 =keycode 242 = keycode 243 = keycode 244 = XF86Battery NoSymbol XF86Battery keycode 245 = keycode 246 = XF86WLAN NoSymbol XF86WLAN keycode 247 = keycode 248 = keycode 249 = keycode 250 = keycode 251 = keycode 252 = keycode 253 = keycode 254 = keycode 255 = [code] ..ich bin mir recht sicher das Du das Alles gar nicht wissen wolltest, aber ich hätte da noch eine längliche Tabelle mit den für "german" gültigen Modifikationen.... Du kannst Dich also nicht darauf verlassen das die Codes immer die selben sind, weil jedes Programm oder der User das Mapping nach seinem Gusto ändern kann. Mach einfach irgend ein Standard Ansi Ding, wenn ich das will kann ich das Mapping meines System daraufhin anpassen. Ich habe übrigens kein Linux sondern FreeBSD 10 auf meinem Rechner, aber der Unterschied zu Linux sollte sehr gering sein da bei Xorg Xserver (xfree86) benutzen. Backspace liefert standardmäßig ^H, Delete halt DEL (0x7f) das ist also bereits gemappt aud eine im Xterminal sinnvolle Funktion. Das Andere sind VT100-ähnliche Steuersequenzen. Wordstar und Turbo bediene ich auch mit den Control und E,S,D,X Tasten.. Der von mir meist benutze Terminalemulator ist Seyon... hornalt. Ich habe keine Ahnung wie der bei den Linux Distries verfügbar ist. Der reicht im Wesentlichen das X-Terminal durch, hat aber die Möglichkeit andere Emulatoren ein zu klinken (Auch Xterm mit VGA statt ISO Font etc..) Ich muß da für die P8000 mit CP/M nochmal was mit ADM3A bauen. Gruß, Holm
Leo C. schrieb: > So, das Programm geht jetzt auch unter CP/M 3, und man kann damit z.B. > neue Partitionen auf CF-Karten oder den DoMs "formatieren". Bei mir geht es :-) Die Platinen und Bausätze sind alle in der Post, viel Spaß beim Aufbau.
Angehängte Dateien:
-
PICT0047.JPG
100 KB
Joe G. schrieb: > Die Platinen und Bausätze sind alle in der Post, viel Spaß beim Aufbau. Danke, schon passiert. Läuft. Joe G. schrieb: > Leo C. schrieb: >> Falls es keine Mühe macht, könnte man für die LED vielleicht zusätzlich >> 2 Bohrungen vorsehen? > > Kein Problem, sehe ich noch vor. Die Bohrungen habe ich noch nicht gefunden.
Bei mir ist die Tüte heute angekommen, allerdings bin ich gerade mal zum reingucken gekommen... Danke einstweilen! Gruß, Holm
Im Anhang ist "mein" aktueller DDT180.COM. Das ist ein um die HD64180/Z180 spezifischen Opcodes erweiterter DDT/Z. Die Erweiterung betrifft nur den Assembler- und Disassembler-Teil. Er läuft also weiterhin auch auf einem Z80 und neue Features gibt es sonst (noch) keine.
Angehängte Dateien:
-
USB.jpg
120 KB
Leo C. schrieb: > Im Anhang ist "mein" aktueller DDT180.COM Sehr schön! In meinem Anhang (Bild), die Platine für den USB-Stick an der RS232-Schnittstelle. Es gibt erst mal 5 Platinen incl. einem VNC2. Die VNC2 Firmware kann über die RS232 programmiert werden [1], allerdings ist das Reset-Timing dabei etwas "hakelig". Besser geht es mit dem zugehörigen Adapter [2] über die Debugschnittstelle. Ordentliche Software unter CP/M existiert noch nicht, hier ist also Mitarbeit gefragt. [1] http://www.ftdichip.com/Support/Documents/AppNotes... [2] http://shop.clickandbuild.com/cnb/shop/ftdichip?productID=141&op=catalogue-product_info-null&prodCategoryID=355
Angehängte Dateien:
-
USB-Stamp.jpg
260 KB
Anbei die der aktuelle Firmwarestand zum USB-Stamp. Die Platine kommuniziert über die V24. Dazu müssen die folgenden Parameter eingestellt sein. Baud: 115200 Data: 8 Stop: 1 Parity: none RTS/CTS Flowcontrol ist nicht unbedingt notwendig, jedoch sollte CTS auf Low liegen. Der USB-Stamp kann zunächst mit einem üblichen Terminal Programm getestet werden. Nach einem Reset sollte die folgende Einschaltmeldung (ohne angestecktem USB-Stick) erscheinen. Ver V2DAP CP/M: Mit USB-Stick erscheint sofort das Laufwerk U: Ver V2DAP CP/M: Device Detected Port2 U:\> Nun können per Terminal alle Monitorkommandos [1] ausgeführt werden. So z.B. „IDD“ USB VID = $0930 USB PID = $6532 Vendor Id = Product Id = USB Flash Memory Revision Level = 1.04 I/F = SCSI FAT16 Bytes/Sector = $0200 Bytes/Cluster = $002000 Capacity = $0F4D8000 Bytes Free Space = $ Bytes U:\> !Anmerkung! Der Monitor befindet sich nach dem Reset sofort im IPA-Mode mit ECS (extendet command set) Die Befehle aus [1] um den Monitor in diesen Mode zu setzen sind also nicht mehr notwendig. [1] http://www.ftdichip.com/Firmware/Precompiled/UM_VinculumFirmware_V205.pdf
:
Bearbeitet durch User
Ich bin gerade dabei USB Tools für CP/M zu schreiben. Dabei verwende ich exakt die gleiche Syntax der "USB Tools 1.5" vom KC85 Team [1]. Nun fällt mir auf, dass bei einer Baudrate von 115200 auf AUX ab dem 5. Zeichen der Rest verschluckt wird. Bei der halben Baudrate treten weniger Fehler auf. @ Leo C. Es gab ja eine "dirty" BIOS Version mit Handshake. Könnte das zuküftig wieder mit rein? Für weitere Tests arbeite ich erst mal mit einer geringen Baudrate. [1] http://susowa.homeftp.net/index.php/download-topmenu/viewdownload/8-cpm-software/202-usb-tools-15.html
@Leo: Guck mal hier gibts Power V3.08: http://www.z80.eu/power.html ..und andere Versionen. Willst Du mal das "test" Kommando ausprobieren? Gruß, Holm
Joe G. schrieb: > @ Leo C. Es gab ja eine "dirty" BIOS Version mit Handshake. Könnte das > zuküftig wieder mit rein? Für weitere Tests arbeite ich erst mal mit > einer geringen Baudrate. Das war eine Testversion des Interrupt-Treibers mit Hardware-Flow-Control. An dem Treiber hat sich inzwischen einiges getan, aber er ist leider immer noch nicht fertig. Heute Morgen habe ich das Teil wieder hervorgekramt, damit ich Dir einen aktuellen Zwischenstand schicken kann. Leider habe ich festgestellt, daß die Flußsteuerung in Emfangsrichtung nicht (mehr) funktioniert. Es kann also noch etwas dauern... Holm T. schrieb: > @Leo: Guck mal hier gibts Power V3.08: Danke für den Hinweis. Inzwischen habe ich es ausprobiert. Scheint nach Version 3.07 deutlich überarbeitet worden zu sein. Der Fehler bei TEST ist auch weg.
Leo C. schrieb: > Heute Morgen habe ich das > Teil wieder hervorgekramt, damit ich Dir einen aktuellen Zwischenstand > schicken kann. Leider habe ich festgestellt, daß die Flußsteuerung in > Emfangsrichtung nicht (mehr) funktioniert. Es kann also noch etwas > dauern... Kein Problem. Ich teste derzeit mit geringerer Baudrate. Der VNC2 selbst ist auch schnell genug um vom CP/M die Daten zu holen, nur gerade in der CP/M Empfangsrichtung hapert es.
Hier ist mal was zum Testen. ASCI0 und ASCI1 laufen über je 128 Byte große FIFOs für RX und TX. Auf ASCIO ist RTS/CTS flow control eingeschaltet. Baudrate kann wie bisher mit dem DEVICE-Befehl eingestellt werden. Andere Parameter (7/8 Bit, Parity, XON/XOFF ...) sind teilweise realisiert und einstellbar, wenn man das Programm dafür hat. ;-) Mehr dazu vielleicht morgen.
Super Leo, danke! Ich mache mich gleich an den Test.
Joe G. schrieb: > Es gibt erst mal 5 Platinen incl. einem VNC2 Hi, bin wieder aus dem Urlaub zurück - kann ich wieder eine haben? Gruß Marcel
Leo C. schrieb: > Hier ist mal was zum Testen. Das flow control geht prima Leo. Leider ist mein Problem nicht behoben damit. Die Ursache liegt im Turbo Pascal Befehl "Read(AUX,Chr)" Der Befehl kehrt nur dann zurück wenn er ein Zeichen empfangen hat und verpaßt dann nach 5 Zeichen erst mal einige (viele) Zeichen. Mal sehen, wie ich das beheben kann. Marcel schrieb: > kann ich wieder eine haben? Ja, gerne.
Joe G. schrieb: > damit. Die Ursache liegt im Turbo Pascal Befehl "Read(AUX,Chr)" Der > Befehl kehrt nur dann zurück wenn er ein Zeichen empfangen hat und Die BIOS-Funktion AUXIST ist Dein Freund. Bei Turbo Pascal auf die Zählung achten (hatten wir ja schon mal).
1 | BIOS Function 18: AUXIST |
2 | |
3 | Return Input Status of Auxiliary Port |
4 | Entry Parameters: None |
5 | Returned Values: |
6 | A=0FFH if ready |
7 | A=00H if not ready |
8 | |
9 | The AUXIST routine checks the input status of the auxiliary port. |
10 | This entry point allows full polled handshaking for communications |
11 | support using an auxiliary port. |
12 | |
13 | BIOS Function 19: AUXOST |
14 | Return Output Status of Auxiliary Port |
15 | Entry Parameters: None |
16 | Returned Values: |
17 | A=0FFH if ready |
18 | A=00H if not ready |
19 | |
20 | The AUXOST routine checks the output status of the auxiliary port. |
21 | This routine allows full polled handshaking for communications |
22 | support using an auxiliary port. |
Habe gerade die BDOS Funktionen 3 und 7 genutzt. Hier bekomme ich auch nur 5 Zeichen und dann ist Schluss. Ich versuche es mal mit den BIOS Funktionen. repeat While B <> 255 do B := BDOS(7); B := BDOS(3); Write(Char(B)); until B = 65;
An die die BDOS Funktionen hatte ich gar nicht gedacht. Das sollte eigentlich auch funktionieren. > repeat > While B <> 255 do B := BDOS(7); > B := BDOS(3); > Write(Char(B)); > until B = 65; Warum nicht:? repeat While BDOS(7) <> 255 do; ... oder While BDOS(7) = 0 do; ...
Leo C. schrieb: > Warum nicht:? War ein Stück Code in ein vorhandenes Programm geschrieben ;-) Ich habe mal beide Versionen durch BIOS und BDOS Funktionen. Sie verhalten sie beide gleich. Zunächst ist der Status $00. Werden Zeichen an AUX gesendet, get der Status auf $FF und die Zeichen können abgeholt werden. Das funktioniert von 1 bis 5 gesendeten Zeichen. Werden jedoch mehr als 5 Zeichen gesendet, dann ist der Status bis zum 5. Zeichen FF und ab dem 6 Zeichen wieder $00 und es wird nicht mehr geholt. Ich hoffe ich habe das Verhalten verständlich beschrieben. Repeat Writeln('Status :',Hex(BDOS(7))); Writeln(Chr(BDOS(3))); until keypressed; Repeat Writeln('Status :',Hex(BIOS(17))); Writeln(Chr(BIOS(6))); until keypressed;
Bisher habe ich nur mit pip getestet und da schien alles in beide Richtungen zu funktionieren. Ich vesuche es jetzt mal mit Turbo.
Wo finde ist denn ein aktuelles CPM.SYS, das für die DOMs geeignet ist? In den Anhängen hier fand ich nur das 0.6.7.1.2-Dirty. Auch wollte ich mal das CPM selber per "make" aus den Quellen übersetzen auf dem Linux-PC. Habe autorevision installiert, aber er bricht ab: zxcc gencpm -AUTO CP/M 3.0 System Generation Copyright (C) 1982, Digital Research ERROR: Unable to open: BNKBDOS3.SPR Das war oben schon mal ein Problem. Muss ich die Datei noch in das Verzeichnis kopieren (von der CPM Diskette)? Ich dachte, im Repo wären alles Dateien drin...?
Marcel schrieb: > Wo finde ist denn ein aktuelles CPM.SYS, das für die DOMs geeignet ist? > In den Anhängen hier fand ich nur das 0.6.7.1.2-Dirty. Ich meine, mit der Version ging es schon. Aber in stamp-monitor_hexrel-6.8.zip ist eine aktuellere Version. Und die aktuellste, mit dem ASCI-Interrupt-Treiber, natürlich auch. > Auch wollte ich mal das CPM selber per "make" aus den Quellen übersetzen > auf dem Linux-PC. Habe autorevision installiert, aber er bricht ab: Mach nochmal einen git pull. Ich habe die fehlenden Dateien jetzt mit hochgeladen. Wenn ich die CP/M 3 Sourcen doch mal auf andere Art zugänglich mache, kann ich die Dateien ja wieder rauswerfen.
Alles gut! Bin dann noch über das neue Attach gestolpert - nun läuft es. Ich überlege nun, wie ich das DOM mit der Platine in mein 19" Rack bekomme. Meine Idee wäre, eine weitere Basis-Platine zu nehmen und das auf einen der Sockel zu stecken. Mal überlegen, welcher der richtige wäre und ob man nicht ein paar Leiterbahnen entfernen müsste...
Marcel schrieb: > Ich überlege nun, wie ich das DOM mit der Platine in mein 19" Rack > bekomme. Meine Idee wäre, eine weitere Basis-Platine zu nehmen und das Und warum nicht auf die Z180-Stamp? Die Karte umrüsten, mit Stiften oder Buchsen oben drauf, wäre wahrscheinlich weniger Aufwand.
Angehängte Dateien:
-
CP_M.jpg
66 KB
Marcel schrieb: > Ich überlege nun, wie ich das DOM mit der Platine in mein 19" Rack > bekomme. Vielleicht so?
Hier mal ein Update meines erweiterten DDTZ. Der Debugger kann jetzt auch mit Symbolen umgehen. Bei der Implementierung habe ich mich stark an SID/ZSID von DR orientiert, aber versucht, deren Bugs und Schwächen zu vermeiden. Eine zu ladende Symboltabelle wird als 2. Datei beim Starten angegeben:
1 | A> DDT180 PROG.COM PROG.SYM |
oder
1 | A> DDT180 * PROG.SYM |
wenn nur die Symboltabelle geladen werden soll. Läuft der Debugger bereits, können die zu ladenden Dateien mit dem F-Befehl angegeben, und anschließend mit R geladen werden. Beispiel:
1 | A>ddt180 |
2 | Symbolic DDTZ/180 - Version 0.4 |
3 | > h |
4 | High = 0100 Max = 0100 Top = CE06 |
5 | > fcsiorw.com |
6 | > r |
7 | High = 01FF Max = 01FF Top = CE06 |
8 | > f* csiorw.sym |
9 | > r |
10 | SYMBOLS |
11 | High = 01FF Max = 01FF Top = CD5B |
12 | > hs |
13 | 0005 BDOS 0103 msg_signon 0130 start |
14 | 013C loop 0150 do_csio_16 0153 while_TE_set_1 |
15 | 0162 while_TE_set_2 0173 while_TE_set_3 0150 do_csio_16_ndis |
16 | 0183 while_TE_set_11 0193 while_TE_set_12 01A3 while_TE_set_13 |
17 | > l l s3 |
18 | 0100 JP 0130 start |
19 | >>l.start |
20 | start: |
21 | 0130 LD SP,(0006) |
22 | 0134 LD DE,0103 msg_signon |
23 | 0137 LD C,09 |
24 | 0139 CALL 0005 BDOS |
25 | loop: |
26 | 013C CALL 0150 do_csio_16 |
27 | 013F PUSH HL |
28 | 0140 LD C,06 |
29 | 0142 LD E,FE |
30 | 0144 CALL 0005 BDOS |
31 | 0147 POP DE |
32 | 0148 OR A |
33 | 0149 JR Z,013C loop |
34 | 014B JP 0000 |
35 | 014E NOP |
36 | 014F NOP |
37 | do_csio_16: |
38 | 0150 LD BC,000A |
39 | >>d .msg_signon .start |
40 | 0103 5A 31 38 30 20 43 53 49 2F 4F 20 74 65 73 74 65 Z180 CSI/O teste |
41 | 0113 72 0D 0A 50 72 65 73 73 20 61 6E 79 20 6B 65 79 r..Press any key |
42 | 0123 20 74 6F 20 71 75 69 74 3A 20 24 00 00 ED to quit: $..m |
43 | >> |
Das Demoprogrämmchen war übrigens der Auslöser für die DDTZ-Erweiterungen. Ich habe mit der CSIO-Schnittstelle herumgespielt, um zu sehen, ob man damit auf einfache Weise ein paar I/O-Ports bekommen kann. Dazu habe ich je 2 Schieberegister für Ein- und Ausgabe angeschlossen, und im DDTZ schrittweise einfache Routinen für die Ansteuerung geschrieben. Dabei habe ich dann die speziellen Z180 I/O-Befehle (IN0, OUT0) vermisst...
Wir haben einen kapitalen Fehler in der Z180 Reset-Schaltung. Ursprünglich sollte /ZRESET nur vom AVR geschaltet werden. Als dann die ECB-Basiskarte kam, hatte ich vorgeschlagen, an diese Leitung einen Taster zu hängen, und übersehen, daß man damit den Ausgang des AVR kurzschließt. :-( Der aktuelle Stand ist in dem ersten Bild zu sehen. Korrekturmöglichkeiten: 1. Auf den Taster verzichten, auslöten und fertig. Auch wenn man die /ZRESET-Leitung richtig beschaltet (s.u.), ist es keine gute Idee, einen Taster gegen Masse direkt daran anzuschließen. Der Taster sollte zumindest entprellt, und eigentlich auch mit dem Takt synchronisiert sein. Daß man ohne den Taster leben kann, beweist alleine die Tatsache, daß sich bis vor kurzem niemand beschwert hat. ;-) Schließlich gibt ja noch den ARESET-Taster, der das gesamte System zurücksetzt, und den Monitorbefehl "restart", der die Funktion hat, die der /ZRESET-Taster auch haben sollte. 2. ZRESET-Taster durch einen Taster an einem AVR-Port ersetzen. Der Monitor löst beim Drücken der Taste (nach Entprellung) den Z180-Reset aus. Als Port würde sich der auf der ECB-Karte mit "MON" bzw. "Monitor" beschriftete Port anbieten, der auf die Stiftleiste JP2 geführt ist. Die eigentlich für diesen Port vorgesehene Funktion "EEPROM löschen" kann problemlos zusätzlich realisiert werden, wenn sie denn mal notwendig werden sollte. 3. Z180 Resetbeschaltung berichtigen. (2. Bild) Dazu kommt an den Z180 Resetpin ein Pullup- statt Pulldown-Widerstand, und die AVR-Karte erhält eine Treiberstufe mit Open-Collector oder Open-Drain Ausgang. Dieser Treiber muß die ZRESET-Leitung auf Low ziehen, wenn der AVR-Port hochohmig ist, z.B. beim Einschalten, oder Flashen einer neuen Monitorversion. Da auf der AVR-Stamp keine Gatter frei sind, wird man als Treiber wohl einen NPN-Transistor oder einen N-MOSFET nehmen. Ein MOSFET hätte den Vorteil, daß man beim Einschalten des Systems den Zustand des Ports ohne Aufwand abfragen kann. So kann man die alte und die korrigierte Schaltung mit der gleichen Software betreiben. Den Umbau kann man natürlich mit 1. oder 2. kombinieren. Außerdem können mit Umbau auch andere Karten am ECB-Bus einen Z180-Reset auslösen. 4. Weitere Vorschläge? Das wars von meiner Seite. Aber vielleicht gibts ja noch Möglichkeiten, an die ich noch gar nicht gedacht habe.
Was sind denn aktuell die Konsequenzen? - Funktioniert der /ZRESET-Schalter gar nicht? Oder nur nicht zuverlässig (Entprellen, Takt)? Das würde zumindest erklären, warum ein Druck auf den Taster meistens "nicht viel geholfen" hat und ich wie beschrieben meistens über ARESET gegangen bin - Leidet der AVR darunter? Bisher ist er noch nicht kaputt gegangen :-)
Leo C. schrieb: > Korrekturmöglichkeiten: Im Sinne einer Kompatibilität würde ich die Variante 3 bevorzugen. So muss die Software sich nicht nach möglichen Hardwarevarianten richten. Bei der Auswahl des n-Kanal Type scheint mir der BSS138 oder ein ander N-Channel Logic Level Gate FET besser geeignet als der IRLML2402. Beim 3.3V Betrieb ist die Vgs(th) zu hoch um sicher zu schalten. Marcel schrieb: > - Funktioniert der /ZRESET-Schalter gar nicht? Kaput gehen wird nichts. Du schließt hat den Ausgangstreiber am Pin mit dem Schalter kurz und es fließt dann der maximale Strom. Laut Datenblatt fließen bei 3.3V etwa 20 mA und dabei schnürt der Ausgangstreiber MOSFET auf 2V ab. Dieser Pegel reicht halt nicht für ein RESET.
Joe G. schrieb: > Leo C. schrieb: >> Korrekturmöglichkeiten: > > Im Sinne einer Kompatibilität würde ich die Variante 3 bevorzugen. So > muss die Software sich nicht nach möglichen Hardwarevarianten richten. > Bei der Auswahl des n-Kanal Type scheint mir der BSS138 oder ein ander > N-Channel Logic Level Gate FET besser geeignet als der IRLML2402. Beim > 3.3V Betrieb ist die Vgs(th) zu hoch um sicher zu schalten. > > Marcel schrieb: >> - Funktioniert der /ZRESET-Schalter gar nicht? > > Kaput gehen wird nichts. Du schließt hat den Ausgangstreiber am Pin mit > dem Schalter kurz und es fließt dann der maximale Strom. Laut Datenblatt > fließen bei 3.3V etwa 20 mA und dabei schnürt der Ausgangstreiber MOSFET > auf 2V ab. Dieser Pegel reicht halt nicht für ein RESET. ..verstehe ich nicht. Der Taster geht gegen Masse und sollte deutlich niederohmiger als ein Ausgangstreiber sein. Woher sollen da die 2V kommen? Das mit dem BSS138 verstehe ich aber auch nicht. Das ist ein Mosfet und kein Sperrchicht-Fet..das Gate sollte isoliert sein (+-20V)..wie kann man da den Pegel am Drain zurück lesen ..oder habe ich das mit dem Rücklesen falsch verstanden? Gruß, Holm
> Im Sinne einer Kompatibilität würde ich die Variante 3 bevorzugen. So Das ist die beste Lösung, und bei einer Neuauflage der Platinen sollten sie auf jeden Fall so gändert werden. Wer sich den Umbau nicht zutraut, kann aber auch mit 1. leben, meine ich. > Bei der Auswahl des n-Kanal Type scheint mir der BSS138 oder ein ander > N-Channel Logic Level Gate FET besser geeignet als der IRLML2402. Beim > 3.3V Betrieb ist die Vgs(th) zu hoch um sicher zu schalten. Eigentlich sollte der IRLML2402 besser als der BSS138 funktionieren, da sein Vgs(th) nochmal niedriger ist. Allerdings hat der bei Ugs = 0,00xV nicht ganz schließen wollen (2 Exemplare). Da es mit dem BSS138 funktioniert, habe ich das nicht weiter untersucht. > Marcel schrieb: >> - Funktioniert der /ZRESET-Schalter gar nicht? > > Kaput gehen wird nichts. Du schließt hat den Ausgangstreiber am Pin mit > dem Schalter kurz und es fließt dann der maximale Strom. Laut Datenblatt > fließen bei 3.3V etwa 20 mA und dabei schnürt der Ausgangstreiber MOSFET > auf 2V ab. Dieser Pegel reicht halt nicht für ein RESET. Im Datenblatt, Figure 32-24, hört die Kurve bei 20mA auf, und die Ausgansspannung ist dann auf 2V abgesunken. Laut "Absolute Maximum Ratings" kann man einen Pin aber bis zu 40mA belasten, wobei der Pegel dann natürlich noch weiter runter geht. Nach den Messungen von Karl-Heinz Kübbeler (Transistortester) haben die Ausgangstransistoren einen RDS(ON) von ca. 22 Ohm. Dann würden ca. 150mA fließen.
Holm T. schrieb: > kein Sperrchicht-Fet..das Gate sollte isoliert sein (+-20V)..wie kann > man da den Pegel am Drain zurück lesen ..oder habe ich das mit dem > Rücklesen falsch verstanden? Nicht Drain, sondern Gate. Es geht darum, die alte Schaltung von der geplanten Schaltung mit Transistor zu unterscheiden. Beim Einschalten des Systems ist der AVR-Port hochohmig, und /ZRESET muß durch externe Beschaltung auf Low gezogen werden. Bei der jetztigen Schaltung hat /ZRESET einen Pulldown und der AVR liest einen Low-Pegel. Würde man bei der neuen Schaltung einen NPN-Transistor nehmen, würde die Basis des Transistors die Spannung am Pullup so weit runterziehen, daß man ohne zusätzlichen Aufwand auch nur ein Low einlesen würde. Das Gate eines MOSFET liegt aber durch den Pullup auf 3,3V.
Achso. Gut dann ist klar was Du willst. Denkst Du aber nicht das die Lösung etwas overengeneered ist? Es wird durch den Port Kurzschluß dem Atmel Nichts passieren, den Kurzschlußstrom könnte man auch noch mit einem R begrenzen, ggf. den Pulldown anpassen. Andererseits halte ich die ganze Taste nicht für so recht notwendig, wenn man den Atmel als "Supervisor" betrachtet kann man den Reset auch da auslösen..klar ein BUS impliziert das der Reset auch von irgendwo da kommen kann, wenn man das will würde ich einfach den Strom begrenzen und gut ist... Gruß, Holm
Holm T. schrieb: > Denkst Du aber nicht das die Lösung etwas overengeneered ist? Stimmt schon. Wobei die Softwareänderung, um auch die umgebaute Version zu erkennen, fast kein Aufwand war. Aber deshalb habe ich ja auch die Alternativen erwähnt. Eigentlich wollte ich noch mal mehr dazu schreiben, bin aber nicht dazu gekommen. Und jetzt muß ich dringend weg.
Leo C. schrieb: > Holm T. schrieb: >> Denkst Du aber nicht das die Lösung etwas overengeneered ist? > > Stimmt schon. > Wobei die Softwareänderung, um auch die umgebaute Version zu erkennen, > fast kein Aufwand war. Aber deshalb habe ich ja auch die Alternativen > erwähnt. Naja ..mir geht halt nicht mal die Notwendigkeit auf da großartig was dran zu ändern..oder das von SW Seite her zu erkennen...weil das Problem halt eher marginal ist. > > Eigentlich wollte ich noch mal mehr dazu schreiben, bin aber nicht dazu > gekommen. Und jetzt muß ich dringend weg. Mache Dir keine Gedanken, wir sind hier mit diesem Thema nicht auf der Flucht. :-) Gruß, Holm
Hallo, ich dachte schon, meine Benachrichtigung wäre defekt :-) Wie stehts denn um das Vinculum? Und ich wollte gerade die SIDE-Teile bei Reichelt bestellen - bin mir aber mit den Typen nicht sicher. Ich betreibe ein 5V-System und bin da schon mal wochenlang einem Fehler auf der Spur gewesen :-) Beispiel 74245. Da gibt es: Typ Versorgung Eingang ABT 4,5 - 5,5V 2V AC 2 - 6V 0 - 6V LVX 2 - 3,6V 0 - 5,5V VHCT 2 - 5,5V 0 - 5,5V Danke und Gruß Marcel
Die Schaltung ist dafür ausgelegt, mit der gleichen Spannung wie die Z180-Karte (und der Rest) betrieben zu werden. Also alles 3,3V oder alles 5,0V. Die Logikfamilie spielt dann keine so große Rolle, da keine Pegel konvertiert werden müssen, und die Geschwindigkeitsanforderungen nicht extrem sind. Auch wenn Du Dein System jetzt nur mit 5V betreibst, würde ich Dir ICs empfehlen, die auch mit 3,3V laufen. Man weiß ja nie... > Typ Versorgung Eingang > ABT 4,5 - 5,5V 2V Geht nicht mit 3,3V > AC 2 - 6V 0 - 6V "Veraltet", sehr steile Schaltflanken, nicht empfehlenswert. > LVX 2 - 3,6V 0 - 5,5V Geht > VHCT 2 - 5,5V 0 - 5,5V Geht nicht mit 3,3V. Reichelt hat da einen "Druckfehler". Auch bei 5V nicht empfehlenswert, da TTL-kompatible Eingänge. Außerdem gibts (bei Reichelt) noch: VHC 2 - 5,5V 0 - 5,5V Sollte gehen. HC 2 - 6V 0 - 6V Geht. Damit läuft meine Schaltung bei 3,3V. Siehe auch: Beitrag "Re: Z180-Stamp Modul"
Marcel A. schrieb: > Wie stehts denn um das Vinculum? Zur Schaltkreisfamilie ist ja schon alles gesagt. Zum Vinculum: Es existiert eine Leiterplatte welche „prinzipiell“ funktionsfähig ist. Harald N. sollte auch eine haben, ich kann aber nicht sagen ob er sie schon aufgebaut hat. „Prinzipiell“ deshalb, weil mir das Design noch nicht gefällt. Die Schaltung ist eingangsseitig für 3.3V bzw. 5V ausgelegt. Um sie in das ECB-Board zu integrieren muss jedoch der zweifache RS232-Treiber deaktiviert werden. Da jedoch üblicherweise dort das Terminal sitzt, kann jetzt nur noch über das virtuelle Terminal am USB-Port gearbeitet werden. Deshalb habe ich die Schaltung nochmals umgebaut. Sie sitzt jetzt direkt an der RS232-Schnittstelle über einen 9-poligen Steckverbinder. Die 5V kommen über RI. Somit kann das USB-Interface nun an eine beliebige RS232 angeschlossen werden. Was jetzt noch fehlt, ist eine ordentliche Leiterplatte. Die Software läuft bis auf den „Copy“ Befehl. Hier sind Files über 32kB noch eine Baustelle.
Leo C. schrieb: >> AC 2 - 6V 0 - 6V > "Veraltet", sehr steile Schaltflanken, nicht empfehlenswert. Leider gibt es bei Reichelt den 138er in SMD nur als AC Version. Den hast du als "veraltet" deklariert, außerdem erscheint mir ein Pegel von 3,8V für "high" dann auch nicht 3,3V-kompatibel. Für 5V sollte er aber gehen - ich probiers - und kenne dann ja eine mögliche Fehlerquelle :-) Vielleicht sollte ich doch mal zu Mouser wechseln?
Marcel A. schrieb: > Leider gibt es bei Reichelt den 138er in SMD nur als AC Version. Artikel-Nr.: SMD HC 138 http://www.reichelt.de/SMD-HC-138/3/index.html?ACTION=3&LA=446&ARTICLE=18638&artnr=SMD+HC+138&SEARCH=74HC138
Joe G. schrieb: > Marcel A. schrieb: >> Leider gibt es bei Reichelt den 138er in SMD nur als AC Version. > > Artikel-Nr.: SMD HC 138 > Mist. Hat mir die Suchmaschine nicht angezeigt :-( Danke!
Marcel A. schrieb: > Leider gibt es bei Reichelt den 138er in SMD nur als AC Version. Den > hast du als "veraltet" deklariert, außerdem erscheint mir ein Pegel von > 3,8V für "high" dann auch nicht 3,3V-kompatibel. Auf die Angaben von Reichelt sollte man sich nicht unbedingt verlassen. Siehe Datenblatt.
Hui, es ist hier ja erstaunlich ruhig geworden (... an die eigene Nase fass...) Mein SIDE muss ich noch aufbauen und das Frontpanel wartet immer noch auf Zusammenbau ... Was ist denn eigentlich aus dem Vinculum geworden? Das war ja schon recht weit und würde eine (vorerst letzte?) tolle Erweiterung des Systems darstellen. Mit besten Grüßen Marcel
Marcel A. schrieb: > Was ist denn eigentlich aus dem Vinculum geworden? Die Testschaltung läuft schon einige Zeit auf dem Steckbrett. Leider bin ich noch nicht dazu gekommen alles auf eine ordentliche LP mit Beschreibung zu bringen. Derzeit drängelt mein Verlag etwas ;-) https://www.amazon.de/dp/B01N8RPPE2/ref=sr_1_2?ie=UTF8&qid=1489736680&sr=8-2&keywords=Grabow+mechatronik
So, der letzte Eintrag ist 1 Jahr alt - sehr schade, dass es so ruhig um diese tolle Plattform geworden ist. Ich habe in den letzten Monaten mit einigen Enthusiasten jede Menge Platinen des NDR Klein Computers neu aufgelegt und hier einen Rechner mit Z80 und einen mit 68000 neu aufgebaut. Darüber ist das hier etwas in den Hintergrund gegangen... Wie sieht es denn mit dem Vinculum aus? Für den NKC haben wir da inzwischen 2 Ausführungen. Und gibt es noch aktualisierte Firmware von Leo? Besten Gruß Marcel
Hi, mal sehen, ob das Forum noch lebt. Nachdem ich die letzten Monate mit dem NDR NKC verbracht habe, wollte ich den Z180-Stamp-Rechner mal wieder anwerfen. Ich war mir sicher, dass ich ihn "lauffähig" ausgeschaltet hatte. Nun startet aber CPM nicht mehr. Im Monitor erscheint:
1 | =========================< (RE)START DEBUG >========================= |
2 | ### Reset reason(s): External. |
3 | |
4 | ATmega2561+Z8S180 Stamp Monitor - Version: 0.6.8.1 |
5 | |
6 | ### main_loop entered: bootdelay=5 |
7 | |
8 | ### main_loop: bootcmd="reset; pin 8 low; loadcpm3; go ${startaddress}"
|
9 | Hit any key to stop autoboot: 0 |
10 | CPU now in reset state. |
11 | Loading: '1:/cpm3_0.6.8.sys'... |
12 | |
13 | BNKBIOS3 SPR FA00 0500 |
14 | BNKBIOS3 SPR B300 3D00 |
15 | RESBDOS3 SPR F400 0600 |
16 | BNKBDOS3 SPR 8500 2E00 |
17 | |
18 | 61K TPA |
19 | Loaded: Resident: 0x1E400-0x1EEFF, Banked: 0x08500-0x0EFFF |
20 | ## Starting application at 0xb300 ... |
21 | => |
Auf Console0 kommt:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8 |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | |
6 | CP/M Error On A: Invalid Drive |
7 | BDOS Function = 15 File = CCP .COM |
Die SD-Karte 1 sieht aber gut aus im Monitor:
1 | => fatls 1: |
2 | ----A 2015/11/29 22:00 8388608 assembler.dsk |
3 | ----A 2015/06/12 09:14 22784 cpm3_4d.sys |
4 | ----A 2015/09/23 22:00 25600 cpm3+8drives.sys |
5 | ----A 2016/05/11 16:40 32768 cpm3system.dsk |
6 | ----A 2015/09/24 14:33 8388608 dbase2.dsk |
7 | ----A 2014/12/12 19:54 8388608 disk1.dsk |
8 | ----A 2014/12/12 19:54 8388608 disk2.dsk |
9 | ----A 2014/12/12 19:54 8388608 disk3.dsk |
10 | ----A 2014/12/12 19:54 8388608 disk4.dsk |
11 | ----A 2015/08/27 15:49 8388608 editor.dsk |
12 | ----A 2015/06/01 15:41 8388608 kermit.dsk |
13 | ----A 2015/09/19 20:31 8388608 leer.dsk |
14 | ----A 2015/11/27 20:07 8388608 share.dsk |
15 | ----A 2015/09/19 19:25 8388608 tp3-hd.dsk |
16 | ----A 2015/09/19 20:32 8388608 tp3vt100.dsk |
17 | ----A 2015/09/20 20:24 8388608 turbo3.dsk |
18 | ----A 2015/09/23 19:51 8388608 ws33.dsk |
19 | ----A 2016/05/11 16:58 8388608 ddtz_d8e.dsk |
20 | ----A 2016/05/22 15:46 30464 cpm3_0.6.4.10-cf-card-dirty.sys |
21 | ----A 2016/06/10 17:21 30464 cpm3_0.6.8.sys |
22 | ----A 2016/08/25 20:23 32000 cpm3_0.6.8-24-dirty.sys |
23 | ----A 2016/08/25 20:39 32000 cpm3_0.6.8.20-int-handling-dirty.sys |
24 | ----A 2016/08/05 14:41 10112 ddt180.com |
25 | 23 File(s), 126045312 bytes total |
26 | 0 Dir(s), 3723696K bytes free |
Die Umgebung sieht auch gut aus:
1 | attach_drives=at dsk0 ${dsk0};at dsk1 ${dsk1};at dsk2 ${dsk2};at dsk3 ${dsk3};at ds}
|
2 | baudrate=115200 |
3 | bootcmd=reset; pin 8 low; loadcpm3; go ${startaddress}
|
4 | bootdelay=5 |
5 | cpm3_commonbase=f000 |
6 | cpm3_file=1:/cpm3_0.6.8.sys |
7 | cpm3_scb=1e900 |
8 | dsk0=0:/cpm3system.dsk |
9 | dsk1=0:/turbo3.dsk |
10 | dsk2=0:/basic.dsk |
11 | dsk3=0:/assembler.dsk |
12 | dsk4=0:/vedit.dsk |
13 | dsk5=0:/ws4.dsk |
14 | dsk6=0:/dbase2.dsk |
15 | dsk7=0:/share.dsk |
16 | esc_char=0x1c |
17 | pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7 |
18 | startaddress=b300 |
Wo könnte der Fehler liegen? Probleme mit der SD-Karte?
> dsk0=0:/cpm3system.dsk > ----A 2016/05/11 16:40 32768 cpm3system.dsk Dein Disk-Image ist zu kurz. Eigentlich sollte es aber automatisch auf 8388608 Byte erweitert werden [1]. Der Patch ist seit Version 6.7.1 im Monitor. [1] Beitrag "Re: Z180-Stamp Modul"
Danke - aber er nimmt ja das DSK von LW 0: ----A 2016/08/25 21:28 8388608 cpm3system.dsk Und egal welche Datei ich als cpm3_file vorgebe (und dann loadcpm3 / go ) - auf der Console wird immer Z180-BIOS v0.6.8 ausgegeben.
Total kurios. Wenn ich ihm das 1:/cpm3system.dsk (32k) vorgebe - wird nichts erweitert. Wenn ich einfach mal eine "leere" Diskette als DSK0 setze kommen genau die gleichen Fehler. Weder Änderungen am cpm3_file noch bei dsk0 bewirken irgendwelche Änderungen...
Ich hätte jetzt vorgeschlagen, daß Du alle Dateien von einem Kartenslot lädst. Aber da hast Du ja schon getan. Vom AVR-Monitor gibt es eine geringfügig neuere Version 0.6.8.2. Diese beiden Änderungen könnten mit Deinen Problemen zu tun haben, aber eher auch unwahrscheinlich: * avr/z180-serv.c: Workaround for GCC bug PR61443 * cmd_attach.c: Correct workaround for GCC bug PR61443 Ich versuche gerade ein System zum Laufen zu bringen, finde aber schon die passenden Kabel nicht. ;-( Nachtrag: Du könntest für das Bootlaufwerk mal das Debugging einschlten, z.B.:
1 | => at -o reattach,debug dsk0 |
:
Bearbeitet durch User
Echt zum verrückt werden ... Loadf geht super - und ich lande dann im DDTZ. Ich habe mal ein älteres cpm.sys probiert - damit startet das System nicht. Soweit ich mich erinnere, müssen ja auch BIOS und CPM.SYS zusammen passen. Vielleicht passt das CPM.SYS nicht ganz? Ich habe im Bios immer noch 8 Laufwerke definiert und hatte mir (eigentlich) die AVR-Files auch für 8 Laufwerke für den 2561 übersetzt... Per Bootloader müsste ich doch auch testweise ältere BIOSe einspielen können?
> Vielleicht passt das CPM.SYS nicht ganz? Alle cpm3_0.6.8.* sollten passen. 0.6.7.* möglicherweise auch noch. > Per Bootloader müsste ich doch auch testweise ältere BIOSe einspielen > können? Ja.
Du bist wie immer mein Held :-) => at -o reattach,debug dsk0 Attachment of '' to dsk0 failed: Disk not attached! Dann manuell attached - und siehe da - geht! Wer lesen kann... - das Problem hatte Joe vor 2 Jahren auch :-) - sorry für die Aufregung! -> "run attach_drives" Schade dass es so ruhig hier geworden ist. Zumindest das USB-Interface hätte ich gerne noch fertig gesehen... Schöne Ostertage und Gruß Marcel
:
Bearbeitet durch User
Ich bin auch noch da, mir fehlt die Zeit aber ich krame das mit Gewißheit auch wieder vor. Mir fehlt noch Peripherie an dem Ding, einfach ein paar GPIOs und wie schon mal angedeutet würde mich rudimentäres Netzwerk interessieren, von mir aus mit ESP ... Gruß, Holm
Marcel A. schrieb: > Wie sieht es denn mit dem Vinculum aus? Mich gibt es auch noch ;-) Ich habe mal mein System wieder in Betrieb genommen, lief fast auf Anhieb. Die SD-Card mußte ich zwei dreimal stecken um richtig gelesen zu werden. Mit der Viculum Hardware hatte ich einige Zeit experimentiert um eine vernüftige Variante zu finden. Auf diesem Stand ist es dann stehengeblieben. Experimentalaufbau + Steckbrett waren mal lauffähig, ich werde es mal wieder hervorkramen...
Prima! Schaltplan und Software für CPM (ich denke angepasste U-Tools von den KC-Leuten) würden mir schon reichen... Gruß Marcel
Holm T. schrieb: > ein paar GPIOs Hallo Holm, ich plane so etwas einfaches wie die IOE für das System. Mit einem echten PIO würde eh schwierig - welcher kann schon 18MHz Takt? :-) Habe mir mal 2 billige MFA-IO-Karten bei ebay geholt - die baue ich mir gemäß IOE dann in mein 19" Rack ein. Gruß Marcel
Marcel A. schrieb: > Holm T. schrieb: >> ein paar GPIOs > > Hallo Holm, ich plane so etwas einfaches wie die IOE für das System. Mit > einem echten PIO würde eh schwierig - welcher kann schon 18MHz Takt? :-) > > Habe mir mal 2 billige MFA-IO-Karten bei ebay geholt - die baue ich mir > gemäß IOE dann in mein 19" Rack ein. > > Gruß > Marcel IOE? -v bitte. Ich bin mir nicht sicher ob man die PIOs mit 18Mhz betreiben müßte, würde das aber ggf. mit 2 16Mhz PLCC PIOs die ich liegen habe mal ausprobieren. Ich übersehe aber nicht was passiert wenn man die Dinger mit halbem Takt und Waitstates laufen läßt (Interruptannahme und Quittung, Vector usw), ich habe mich da noch nicht wirklich reingekniet. Ganz davon abgesehen wären auch schon ein paar blanke Ein- und Ausgaberegister hilfreich, Interruptmöglichkeiten wären aber schön.. Evtl. eine Art PIO in einem CPLD neu auflegen? Gruß, Holm
Zum Thema I/O. Wenn man nur ein paar simple In- und/oder Out-Ports haben will, kann man ein paar Schieberegister an CSIO anschließen. Im Anhang ist ein Beispiel mit je 16 In und Out. Die dazu passende Software könnte ungefähr so aussehen:
1 | ; 16 Bit Port lesen und 16 Bit Port schreiben |
2 | ; |
3 | ; DE: Auszugebender Wert |
4 | ; |
5 | ; Return: |
6 | ; DE: Gelesener IN-Port |
7 | ; |
8 | CSIO16: |
9 | IN0 A,(0AH) ; Warten bis CSIO unbeschäftigt |
10 | AND 30 ; Kann entfallen, da CSIO bei Aufruf immer bereit. |
11 | JR NZ,CSIO16 |
12 | DI ; Keine Unterbrechung zwischen den beiden Transaktionen |
13 | OUT0 (0BH),E |
14 | LD A,10 |
15 | OUT0 (0AH),A ; Transmitter starten |
16 | WL1: |
17 | IN0 A,(0AH) ; |
18 | AND 10 ; |
19 | JR NZ,WL1 |
20 | IN0 E,(0BH) ; Low Byte lesen |
21 | OUT0 (0BH),D |
22 | LD A,10 |
23 | EI |
24 | OUT0 (0AH),A |
25 | WL2: |
26 | IN0 A,(0AH) |
27 | AND 10 |
28 | JR NZ,WL2 |
29 | IN0 D,(0BH) ; High Byte lesen |
30 | RET |
Naja gut, ne SPI basierende Schnittstelle ist schön langsam...aber es gibt fertige Peripherie-Ics wie ADU etc. Das ist allerdings nicht was ich mir vorgestellt hatte. Mir ist klar das der ungepufferte Highspeed-Systembus wohl das größte Problem für Erweiterungen darstellen wird. Gruß, Holm
Hi,
ich nutze die Osterferien, um endlich mal in tiefer in die
Z80-Programmierung einzusteigen.
Ich will hier ja kein Assembler-Hilfs-Forum starten - aber ich kann mir
folgende Meldung von Z80ASM (SLR) nicht erklären:
UEB16M2.Z80 - A11AH Undefined Line 00013
LD DE,A11AH ; MPD (00AB)
Ich will einen 16-Bit Wert in DE speichern. Nehme z.B. 111AH dann geht
es...
P.S.: Was mir echt fehlt im BIOS ist ein fatcp - um images von 1: auf 0:
zu kopieren. (Hintergrund: 1: habe ich extern im Zugriff, 0: liegt in
den tiefen des 19" Gehäuses - da komme ich immer schlecht an die
SD-Karte zum wechseln dran :-))
> UEB16M2.Z80 - A11AH Undefined Line 00013 > LD DE,A11AH ; MPD (00AB) 'A11AH' wäre ein Label, das aber nicht definiert ist. Aus dem Handbuch, Kapitel EXPRESSIONS:
1 | NUMBERS |
2 | |
3 | Numbers are by default radix 10. The default radix may be |
4 | overridden by using one of the following forms: |
5 | |
6 | nB Binary |
7 | nO Octal |
8 | nQ Octal |
9 | nD Decimal |
10 | nH Hexadecimal |
11 | X'n' Hexadecimal |
12 | |
13 | where n is any number of digits valid for the given radix. Note |
14 | that the nB and nD forms will not be recognized if the default |
15 | radix has been changed to larger than 11 or 13 respectively since |
16 | the trailing character would be a valid digit in the default |
17 | radix. Also, the first digit in the nH-type must be from 0-9. |
Der letzte Satz betrifft Dein Problem. > P.S.: Was mir echt fehlt im BIOS ist ein fatcp - um images von 1: auf 0: > zu kopieren. Du meinst den 'Stamp Monitor', oder? Vielleicht sollte man die bash auf den AVR portieren. :-) Oder jemand schaut sich die Datei 'cmd_fat.c' an, und erweitert sie um den Befehl fatcp. Und dann noch fatmv, fatrm, ... :)
Leo C. schrieb: > 'A11AH' wäre ein Label, das aber nicht definiert ist. > Aus dem Handbuch, Kapitel EXPRESSIONS: >
1 | > NUMBERS |
2 | >... |
3 | > Also, the first digit in the nH-type must be from 0-9. |
4 | > |
> Der letzte Satz betrifft Dein Problem. > Danke - du wirst es nicht glauben - natürlich habe ich mir diese Stelle im Handbuch angesehen - aber den letzten Satz nicht mitgelesen :-( LD DE,0A11AH geht > Du meinst den 'Stamp Monitor', oder? > Vielleicht sollte man die bash auf den AVR portieren. :-) Gute Idee :-) > Oder jemand schaut sich die Datei 'cmd_fat.c' an, und erweitert sie um > den Befehl fatcp. Hm ja ... mal sehen, ob es dazu was gibt. > Und dann noch fatmv, fatrm, ... :) :-)
..damit steht der SLR Asembler aber nicht alleine da, die führende 0 bei Hex Zahlen hat Tradition. Gruß, Holm
Hi, kennt hier jemand ein gutes (online) Tutorial für Z80-Programmierung unter CP/M? Der Zaks geht darauf ja nicht ein. Mit dem CPM ProgGuide habe ich es zwar geschafft, Text auszugeben - aber gibt es Code-Sammlungen, wie man z.B. effektiv Benutzereingaben realisiert, Daten ausgibt usw.? Die Z80-Heaven-Seite ist ja sehr TI83-lastig... Gruß Marcel
Ich fürchte, da bist du ein bisschen spät dran, und CP/M zu früh. Die Betriebssystemaufrufe (d.h. die BDOS-Funktionen) sind alle dokumentiert, daraus kannst du das "wie mache ich das" selbst herleiten. Es gibt auch Unmengen an fertigen Programmen, wo du Code abkupfern könntest. Allerdings gab es im Gegensatz zu heute keinen Standard, wie sich Programme üblicherweise verhalten. Jedes Programm hat sich z.B. sein eigenes Parameterformat definiert. Manche Programme reagieren auf Tastendrücke sofort, andere möchten noch ein Enter sehen. Alles, was CP/M nicht anbietet, muss jedes Programm selbst implementieren. Systemweite Bibliotheken (wie DLLs oder .so heute) gab es nicht, hätte auch nicht in den Speicher gepasst. Es gab nur das, was auch gebraucht wurde. Andere Funktionen, wie z.B. Baudrate oder Terminaltyp sind systemspezifisch, da hatte jedes Programm, was sowas brauchte, seine eigene Abstraktion für. Der Nutzer durfte dann die systemspezifischen Sequenzen selbst in die Binärdateien patchen. Schau dir vorhandene Programme an, wenn du den Stil nachempfinden möchtest, oder halte dich an heutige Gepflogenheiten (die du allerdings auch implementieren musst).
Wie svenska schon schreibt: Die Dokus zu BDOS und BIOS sind Dein Freund. Einen ASM-Grundlagenkurs gibt es. z.B. hier: http://www.mpm-kc85.de/dokupack/KCC_ASM_Kurs.pdf Wem die ASM-Progammierung zu 'langsam' geht, der kann auch mit C arbeiten: BDS-C bringt eine bios.h und bdos.h mit. Damit kann man die Systemfunktionen bequem aufrufen.
Guten Abend zusammen, ich habe eine MFA 8-Bit Ausgabe-Karte (8085 System) einmal auf die ECB-Basisboard-Anschlüsse umgelötet. Dabei habe ich noch ein paar "Sicherheitsfragen", bevor ich die Karte nun in das Rack stecke: - Der BUS hat ja 5V/TTL, soweit ich mich erinnern kann? - Ich würde die Karte z.B. auf Adresse CC einstellen und kann sie dann mit OUT ansprechen? Bis 7F waren ja "interne" Adressen. - Mit dem Signal /IOW bin ich mir nicht ganz sicher. Dieses Signal wird künstlich aus den Signalen IO/M, /RD und /WR des 8085 hergestellt (siehe Anhang) und auf den BUS des MFA gelegt. Da es sich bei der Karte nur um eine beschreibbare Karte handelt, meine ich, dass ich RD/WR nicht ausdekodieren muss und /IOW einfach mit /IORQ verbinden kann. - Falls das nicht reicht - dann müsste ich doch einfach "nur" /IORQ und /WR mit einem Oder-Gatter verbinden, um /IOW zu erhalten? Besten Gruß Marcel
Angehängte Dateien:
-
IO-Timing.png
14 KB -
INTACK.png
13 KB
> - Der BUS hat ja 5V/TTL, soweit ich mich erinnern kann? Wenn Du das System mit 5V betreibst, schon. > - Ich würde die Karte z.B. auf Adresse CC einstellen und kann sie dann > mit OUT ansprechen? Bis 7F waren ja "interne" Adressen. 00 - 4F CPU-Intern 40 - 5F Auf AVR-Stamp verbraten 60 - 6F CF-IF Der Rest müßte frei sein. > - Mit dem Signal /IOW bin ich mir nicht ganz sicher. Dieses Signal wird > künstlich aus den Signalen IO/M, /RD und /WR des 8085 hergestellt (siehe > Anhang) und auf den BUS des MFA gelegt. Künstlich würde ich das nicht nennen. > Da es sich bei der Karte nur um > eine beschreibbare Karte handelt, meine ich, dass ich RD/WR nicht > ausdekodieren muss und /IOW einfach mit /IORQ verbinden kann. Das wäre ok, wenn /IORQ nicht noch eine 2. Funktion hätte. Es wird zusammen mit /M1 für den "Interrupt Acknowledge Cycle" verwendet. > - Falls das nicht reicht - dann müsste ich doch einfach "nur" /IORQ und > /WR mit einem Oder-Gatter verbinden, um /IOW zu erhalten? Wäre besser, da Du Dir sonst die Möglichkeit verbaust, /INT0 zu benutzen.
:
Bearbeitet durch User
Ok, danke. Ich werde dann /IORQ0 (müsste mal schauen, was /IORQ1 beim Z180 ist...) und /WR über ein 7432 Oder-Gatter verbinden und dann an den als /IOW bezeichneten Eingang der Karte legen. Für die 8-Bit Eingabekarte würde ich das dann mit /IORQ0 und /RD machen und auf /IOR verbinden.
> Ich werde dann /IORQ0 (müsste mal schauen, was /IORQ1 beim Z180 ist...) Da ist was durcheinander geraten. /IORQ0 und /IORQ1 gibt es nicht. Es gibt /IORQ und /INT0 bis /INT2. /INTx sind Interrupteingänge. Nur Interrupts an /INT0 kommen mit I/O-Schreib/Lesezyklen in Konflikt. Interessant wird das alles aber erst, wenn Du interruptfähige I/O-Hardware anschließen möchtest. > Für die 8-Bit Eingabekarte würde ich das dann mit /IORQ0 und /RD machen > und auf /IOR verbinden. Sicher meinst Du hier /IORQ, dann ist das richtig.
So - funktioniert einwandfrei (nachdem ich einen Verdrahtungsfehler korrigiert hatte). Jetzt scheitere ich daran, dass keiner der "Delay-Samples" funktioniert (für eine Lauflicht-Demo). Nach dem Aufruf des delay-Unterprogramms (verschachtelte Schleifen) stürzt das Com-File ab. Aber heute nimmer :-) Gruß Marcel
Das mit dem Absturz war auch wieder menschliches Versagen... Ich hatte nach dem letzten RET im Unterprogramm kein Enter gedrückt - und prompt hat SLR diese letzte Zeile nicht übersetzt und das Programm ging ins Speichernirvana... Zum Thema Z80 Toolbox: Das hier ist ganz nett: "Doctor Dobb's Z80 Toolbook". Ist aber überwiegend 8080 Code - zusammen mit dem "Übersetzer" 8080->Z80, den mir Werner vom NKC-Forum empfohlen hat (http://www.prof80.de/i2zkurz.html) ist das eine ganz gute Basis. Zum Thema Delay: Die Schleifen, die ich bisher als Samples gefunden habe, sind alle noch viel zu kurz. Sie gehen meist von 2 MHz aus - die Stamp rast ja fast 10x so schnell. Ich werde heute Abend mal die 24Bit-Schleife von Zaks testen. Zum Thema Uhr: Da unter CP/M3 ja die Uhr zur Verfügung steht dachte ich mir, die Sekunden als "Timer" zu nutzen (z.B. jede Sekunde eine LED an und wieder aus). Und jetzt gehts los... Soweit ich das oben und mit den CP/M Handbüchern verstanden habe muss ich hier an den SCB ran - dort sollte immer die richtige Uhrzeit an einer speziellen Speicherstelle stehen? Bei der erwähnten Stelle http://www.seasip.info/Cpm/scb.html habe ich folgendes gefunden:
1 | F4H word Date (days since Jan 0, 1978). |
2 | F6H byte Hour (BCD). |
3 | F7H byte Minute (BCD). |
4 | F8H byte Second (BCD). |
Das ist der Offset zur SCB base. Diese soll cpm3_scb=1e900 sein. Oder man fragt sie ab:
1 | LXI D,SCBPB |
2 | MVI C,49 |
3 | CALL BDOS ;page address of SCB in reg H |
4 | ... |
5 | SCBPB: DB 3AH ;this is where SCB address is |
6 | DB 0 ;get operation |
Stimmen die Offsets? (Man soll ja nicht die orignal CPM nehmen, die fangen bei 58 an). Stimmt das Sample? Oder wie greife ich im Assembler auf 1E900 + F4H zu? Das liegt ja in der (falschen) Bank :-) Oder in Pascal - warum auch immer dafür DPB (49D/31H) genutzt wird
1 | Function SCB_Adr : Integer; { Adresse des SCB im RAM bestimmen }
|
2 | Begin |
3 | New(SCBPB); { Pointer erzeugen }
|
4 | SCBPB^.Offset := $3A; { Adresse des SCB }
|
5 | SCBPB^.Flag := $00; { Flag = Lesen }
|
6 | SCBPB^.Wert := 0; { ohne Funktion }
|
7 | HL := BDOSHL($31,ORD(SCBPB)); { BDOS Aufruf 31H }
|
8 | (* Writeln('HL-Register: ', Hex(HL)); { Adressausgabe des SCB }
|
9 | *) |
10 | SCB_ADR := HL; |
11 | End; |
Oder wie kann ich diese BIOS-Funktion nutzen:
1 | TIME (function 26) |
2 | Get the current date and time into the SCB (at BOOT-0Ch). HL and DE must be preserved. If C=0FFh, then set the time from the SCB instead. |
3 | The format of the 5-byte buffer is: |
4 | DW day ;Day 1 is 1 Jan 1978 |
5 | DB hour ;packed BCD |
6 | DB minute ;packed BCD |
7 | DB second ;packed BCD |
Dazu passende BDOS-Funktionen (48,105,155) gibt es ja erst in höheren CPM-Versionen (86, etc.) Ich blick noch nicht durch, wie ich nun an die Uhrzeit komme...
Selbst die 24bit-Schleife mit jeder Menge taktlastiger Befehle dazwischen kommt gerade in Größenordnung von 1/4 Sekunde... Da werde ich wohl mal mit dem CTC arbeiten. Beispiele für externe CTCs gibt es ja - sind die denn (bis auf die Portadressen) kompatibel zu den eingebauten Timern?
So wie ich die Doku verstehe, liegt der SCB im residenten Teil des BDOS, der immer gemappt ist. Außerdem sollst du den nicht per Hand beschreiben, sondern das BDOS dafür benutzen. Siehe https://www.seasip.info/Cpm/bdos.html für die BDOS-Funktionen. Konkret (ungetestet, ohne jede Erfahrung mit CP/M 3):
1 | LD C, 49 ; function 49/31h: access SCB |
2 | LD DE, SCBPB ; function parameters |
3 | CALL BDOS |
4 | ; die sekunde sollte jetzt in A stehen |
5 | |
6 | SCBPB: |
7 | DB 0F8h ; field "second" ... |
8 | DB 0 ; ... read |
Die BIOS-Funktion klingt eher nach "schreibe die Uhrzeit in den SCB bzw. setze dir Uhrzeit vom SCB", ist also für dich ungeeignet. Unter CP/M 3 soll man das BIOS zudem nicht direkt, sondern nur über die BDOS-Funktion 50 (32h) aufrufen. Spontan scheint mir so, als ob "MP/M II and later" auch CP/M 3 einschließt, d.h. du solltest für die aktuelle Zeit auch BDOS 105/69h benutzen können. Probier's aus.
Danke dir! Mein Verständnis war, dass mit BDOS 31H nur die Basisadresse des SCB liefert und ich zu dieser dann den Offset F8H ergänzen muss für das Feld der Sekunden? So wie hier (allerdings hat er andere Offsets...) https://www.seasip.info/Cpm/scb.html
Lies dir mal die Doku genau durch (und probiere es im Zweifelsfall einfach aus, das schafft Klarheit). Die Funktion 49 heißt "Access the System Control Block" und nimmst in DE einen Zeiger auf einen Parameterblock, der wiederum einen Offset und einen Befehl enthält. Der Befehl ist "read" oder "write" (byte bzw. word), also wird logischerweise der Offset innerhalb des SCB gemeint sein. Damit kannst du also portabel auf die einzelnen Felder des SCB zugreifen. Der Code, den du meinst, erlaubt dir, die Basisadresse des SCB zu finden, weil du dort von Offset 0x3A liest. Offiziell läuft der Offset aber nur von 0x68 bis 0xFF. Wir driften aber vom Thema des Threads ab.
:
Bearbeitet durch User
Zu den Timern. CTC hat 4 mal 8-bit Zähler. Z180 hat 2 mal 16-bit Zähler. Alle diese Zähler können nur abwärts zählen, ggf einen Interrupt auslösen, und ggf. einen Presetwert nachladen, für den nächsten Zyklus. CTC hat für jeden Kanal auch einen Eingang, der statt des Systemtaktes heruntergezählt werden kann. Die Z180 Timer nicht. 3 CTC Kanäle haben einen Ausgang, der beim "Nulldurchgang" gepulst wird, Z180 hat nur für einen Timer einen Ausgang, der bei "Nulldurchgang" auf High oder Low gesetzt, oder getoggelt werden kann. Dummerweise ist der Timerausgang mit Adressleitung A18 gemultiplext (Pinmangel), so daß man bei seiner Verwendung nur 256K RAM nutzen kann. Der interne Timer T0 wird im CP/M3-Bios für Timeouts verwendet. T1 ist frei. Interrupt ist mit den internen Timern auf jeden Fall einfacher. Wenn Interrupts unter CP/M3 genutzt werden sollen, muß die Interruptroutine in die Common Area. Diese beginnt bei F000. Das BDOS liegt auf F300. Dazwischen ist also noch etwas Platz. Außerdem ist noch was zwischen FE00 und FFBF frei. Auf FFC0 liegt die Vector-Tabelle.
Danke euch! Versuch macht klug. Aber stimmt, ich werde hier nur Fragen zur HW oder speziell zum System stellen. Leider findet man echte Profis wie euch ja nicht an jeder Straßenecke:-)
Marcel A. schrieb: > Aber stimmt, ich werde hier nur Fragen zur HW oder speziell zum System > stellen. Du darfst aber auch einen neuen Thread aufmachen und hier verlinken. :-)
Hallo! Endlich hatte ich Zeit, die Platinen zu bestücken. Nun habe ich das Problem, dasss der Thread mittlerweile sehr unübersichtlich geworden ist. Ich habe am Wochenende etwas Zeit das System zu testen. Ich habe die ECB zusammen mit der AVR- und Z180-Stamp und zusätzlich noch die SIDE-Stamp. Dies möchte ich zusammen auf Funktionalität testen. Geflasht habe ich die Firmware Version 6.3. Meine Fragen, die ihr sicher aus dem Kopf beantworten könnt: 1) Wie muss ich die Jumper auf den einzelnen Platinen setzen damit ich das ganze System via USB-Port betreiben kann? 2) Enthält das System noch Hardware-Fehler, die ich vor dem Test beheben MUSS. 3) Welche Dateien/Images muss ich auf die MicroSD der AVR-Stamp bzw die Flash-Karte des ECB aufspielen? Das SIDE-Modul wurde ja schon fertig vorbereitet? 4) Falls ich noch wichtige Punkte vergessen habe... Vielen Dank für eure Hilfe! Bald ist Urlaub, da habe ich hoffentlich Zeit mal den Thread durchzuarbeiten.... Harald
Harald N. schrieb: > Meine Fragen, die ihr sicher aus dem Kopf beantworten könnt: Die Antworten auf deine Fragen findest du in der zugehörigen Doku. Hier sind alle Schritte für eine Inbetriebnahme beschrieben. Versuche mal bitte ganz nach Anleitung zu arbeiten. So kann ich dann mögliche Ergänzungen oder Erweiterungen in die Doku mit aufnehmen, wenn Unklarheiten entstanden sein sollten.
Ok, danke erstmal. Das habe ich am Wochenende versucht. Nicht erwähnt wird die Kombination mit der ECB und dem SIDE-Interface (Jumper). Und ich habe nicht gefunden welche Daten wohin gespielt werden müssen, damit ich das CPM zum Laufen bringe. Ich habe zwar etwas herumgespielt - aber nichts sinnvolles erreicht. Mein Interesse ist zwar sehr groß, aber ich gehöre leider nicht zur Z80- bzw. CPM-Generation, sodass ich mir die ganzen Zusammenhänge hart erarbeiten muss :-) Mir ist eben wichtig, einen Quick-and-Dirty Test durchzuführen, damit ich Lötfehler meinerseits ausschließen kann. Ich habe dann schon vor, den Thread durchzuarbeiten.
Hallo Harald, auf meine HP (die ich aber erst einmal DSGVO-kompatibel machen muss und daher offline ist) habe ich einige Stolpersteine aus meiner Sicht als blutiger Anfänger beschrieben... Ich verstehe beileibe nicht alles, aber das System ist definitiv genial. Ich habe übrigens einen Thread zu meinem Timer-Thema aufgemacht. Es kann doch nicht so schwer sein, 8 LEDs als Lauflicht zu nutzen :-) Ich komm aber nicht weiter... [[Beitrag "Z180 Programmierung (Timer)"]]
Angehängte Dateien:
-
Uebersicht.jpg
71 KB
Hallo Harald, es ist gar nicht so kompliziert. Ich habe mal kurz die Schritte skizziert welche bei korrekt funktionierender Hardware durchzuführen sind. Sollte ein Fehler auftreten, hast Du mit dem Monitor ein sehr gutes Tool diesen zu identifizieren. Hinweise findest du dazu in der Doku oder im HELP des Monitors. Über den Aufbau der Dsk Images von CP/M schreibe ich noch etwas. Du kannst für den ersten Test gerne meine verwenden. Alle hier in der kurzen Beschreibung erwähnten Dateien im Anhang. Schritt 1 Bootloader auf den AVR bringen Datei: bootload.hex Schritt 2 Monitor mittels Bootloader auf den AVR bringen Tools: AVRFlash oder UpdateLoader Datei: stamp-monitor_hexrel-6.8.1.hex Anmerkung: Zu jedem Monitor gehört ein passendes BIOS. Dieses ist auf die SD-Card zu kopieren. Schritt 3 BIOS auf die SD-Card kopieren Datei: cpm3_0.6.8-23.sys Schritt 4 CP/M Laufwerke als Image auf die SD-Card kopieren Datei: cpm3_a.dsk cpm3_b.dsk cpm3_c.dsk Schritt 5 Environmentvariable im Monitor setzen (Beispiel) attach_drives=at dsk0 1:/cpm3_a.dsk;at dsk1 1:/cpm3_b.dsk;at dsk2 0:/cpm3_c.dsk;at dsk3 1:/z180-stamp-cpm3-bios.dsk;at dsk4 1:/z180.dsk baudrate=115200 bootcmd=reset; loadc; run attach_drives; go ${startaddress} bootdelay=3 cpm3_commonbase=f000 cpm3_file=1:/cpm3_0.6.8-23.sys cpm3_scb=1e800 esc_char=0x40 pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10 :PE7 singlestep=1 startaddress=ad00 test_fat=fatstat 0:; fatls 0: test_sd=sd status 0; sd init 0; sd info 0 Schritt 6 AVR neu booten =========================< (RE)START DEBUG >========================= ### Reset reason(s): External. ATmega1281+Z8S180 Stamp Monitor - Version: 0.6.8 ### main_loop entered: bootdelay=3 ### main_loop: bootcmd="reset; loadc; run attach_drives; go ${startaddress}" Hit any key to stop autoboot: 0 CPU now in reset state. Loading: '1:/cpm3_0.6.8-23.sys'... BNKBIOS3 SPR F900 0500 BNKBIOS3 SPR AD00 4300 RESBDOS3 SPR F300 0600 BNKBDOS3 SPR 7F00 2E00 60K TPA Loaded: Resident: 0x1E300-0x1EDFF, Banked: 0x07F00-0x0EFFF ## Starting application at 0xad00 ... => Schritt 7 Ausgabe am CP/M – Terminal CP/M Version 3.0, Z180-Stamp BIOS v0.6.8-23 Estimated CPU clock [Hz]: 18432000 sdio: SD Card driver cfio: CompactFlash Memory Card driver Model: PQI IDE DiskOnModule, S/N: DOM3C00004268, Rev: 060729DA Size: 256000 Sectors (128000 KiB) I: CP/M partition at: 2048, size: 8192KiB J: CP/M partition at: 18432, size: 8192KiB K: CP/M partition at: 34816, size: 8192KiB L: CP/M partition at: 51200, size: 8192KiB A>
:
Bearbeitet durch User
Das Fileformat für die einzelnen CP/M Image Dateien entspricht dem Disk-DH Format des SIM Altair Z80 Simulators [1]. Somit kann dieser als Tool zum Erstellen und auch Testen der Image Dateien verwendet werden. Natürlich sind auch die beliebten CP/M-Tools [2] oder unter Windows der Total Commander [3] möglich. Hier ist jedoch noch ein Plugin [4] für die Behandlung von CP/M Dateien notwendig. [1] https://schorn.ch/altair.html [2] http://www.moria.de/~michael/cpmtools/ [3] https://www.ghisler.com/deutsch.htm [4] http://hc-ddr.hucki.net/wiki/doku.php/cpm/disketten_xp2 Fileformat # SIMH AltairZ80 Harddisk diskdef simhd seclen 128 tracks 2048 sectrk 32 blocksize 4096 maxdir 1024 skew 0 boottrk 6 os 2.2
Vielen Dank! Beim Betrachten deiner Fotos ist mir gerade aufgefallen, dass ich die Module falsch herum auf das ECB gesteckt habe - intuitiv mit Schrift unten ohne nachzudenken. Ich hoffe ich habe da nichts abgeschossen.... Kanns kaum erwarten endlich die Stamps in Betrieb zu nehmen.
Hallo! Das Board läuft zumindest mal. Bootet von SD, memtest war ok Es funktioniert aber nur wenn ich den ISP programmer auch anstecke?????? Auf welcher Konsole sollte sich cpm melden? Muss ich da noch irgendwelche jumper setzen. Mit gnd, TX, rx auf con0 geht zumindest mal nichts.....
Super, Glückwunsch! Ein angesteckter ISP deutet auf fehlerhafte Stromversorgung. Wird dein Bord korrekt über USB oder eine externe Versorgung mit 5V/3.3V versorgt? Auf dem ECB-Board sind nochmals zwei serielle Schnittstellen CON0 und CON1. Damit der Schnittstellentreiber (MAX3241) aktiv ist, darf JP5 nicht geschlossen sein. CON0 ist eine voll ausgebaute RS232 (Handshakeleitungen) CON1 reduziert. In dem BIOS, welches ich dir zur Verfügung gestellt habe ist für die CP/M Konsole CON1 mit 115 kBaud eingestellt (kann später alles geändert werden).
Ich will das Board über USB versorgen. Allerdings läuft es dann nicht an. Als ich den Programmer angesteckt habe, hat alles funktioniert (flashen, Firmware updaten, etc). Ich dachte mir, dass vlt der Strom eines USB Ports nicht reicht.... Auf CON1 kommt jetzt was. Allerdings nur Kauderwelsch (die Baudrate stimmt).
Günstig ist der Betrieb auf zwei Konsolen. Wenn nach der Monitorausgabe 60K TPA Loaded: Resident: 0x1E300-0x1EDFF, Banked: 0x07F00-0x0EFFF ## Starting application at 0xad00 ... => die Ausgabe auf CON1 kommt, wird CP/M ordentlich gestartet.
:
Bearbeitet durch User
Um die Fehler auf der seriellen Seite zunächst mal auszublenden, könntest du die CP/M Konsole auf die AVR Monitorkonsole legen. Ich weiß den Monitorbefehl gerade nicht aus dem Kopf, nutze mal HELP im Monitor. Mit dem Umschalten befindest Du dich dann im CP/M.
Hab keinen entsprechenden Befehl gesehen? Aber memtest ist OK und der CPU test (mit HLT) auch...
@leo: (sorry für OT) hast Du indessen irgendwo mal eine Referenzimplementation eines interruptbasierten Z180 serial- Treibers gefunden? Gruß, Holm
Joe G. schrieb: > önntest du die CP/M Konsole auf die AVR Monitorkonsole legen. Geht mit "con". Aber dazu muss in der CPM-Submit-Datei (Autostart) die Aussage per Assign umgelegt sein...
Harald N. schrieb: > Hab keinen entsprechenden Befehl gesehen? > Aber memtest ist OK und der CPU test (mit HLT) auch... Ich bin leider nicht früher dazu gekommen :-( Nun habe ich dir mal ein CP/M Bootimage erzeugt, welches nach dem Bootvorgang die Console wieder auf den USB-Port legt. Wenn der Monitor also komplett durchgelaufen ist, einfach den Befehl "connect" eingeben. Dann verbindet sich der USB-Port mit der CP/M-Console mit der folgenden Meldung: => connect Connecting to CPU. Escape character is '^€'. Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff USB0 NONE IO ASCI0 19200 IOS ASCI1 115200 IOS Current Assignments: CONIN: = USB0 CONOUT: = USB0 AUXIN: = Null Device AUXOUT: = Null Device LST: = Null Device A> Verlassen kannst du das CP/M mit dem vorher definierten esc_char des Monitors.
Schön, daß hier wieder ein bisschen was los ist. Ich würde mich auch gerne etwas mehr beteiligen, bin aber z.Zt. mit anderen Dingen völlig ausgelastet. Danke Joe, für die tolle Anleitung und die Disk-Images. Joe G. schrieb: > Schritt 5 > Environmentvariable im Monitor setzen (Beispiel) Beim Versuch, diesen Schritt etwas zu automatisieren, bin ich leider auf einen Fehler im Stamp-Monitor gestoßen. Seit einiger Zeit kann der Monitor ja Befehle aus einer Script-Datei lesen und ausführen. Dabei wurden Zeilen, die nur aus Kommentar bestehen leider als Fehler behandelt, und so verhindert, daß man Script-Dateien sinnvoll kommentieren kann. Den Fehler habe ich jetzt behoben (Anhang1). Anhang2 ist ein Beispielscript, daß im wesentlichen die Einstellungen von Joe übernimmt, und noch ein paar Sachen zeigt, die ich für nützlich halte. > baudrate=115200 > bootdelay=3 Diese Einstellungen werden automatisch gesetzt, wenn das EEPROM noch leer ist, oder die CRC nicht stimmt und durch den Befehl "defaultenv". > cpm3_commonbase=f000 > cpm3_scb=1e800 > startaddress=ad00 Diese Variablen werden durch den Befehl loadc automatisch gesetzt. Um die aktuellen Einstellungen leichter in ein Script übernehmen zu können, habe ich dem Befehl printenv eine Option [-s] spendiert, durch die die Variablen im Format "setenv VARIABLE 'WERT'" ausgegeben werden.
1 | => defaultenv |
2 | ## Resetting to default environment |
3 | -> printenv -s |
4 | setenv baudrate '115200' |
5 | setenv bootcmd 'pin ${pins}; loadcpm3; go ${startaddress}'
|
6 | setenv bootdelay '3' |
7 | setenv cpm3_file '0:/cpm3.sys' |
8 | setenv pin_alias '0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10:PE7' |
9 | setenv pins '2,8 low 9 high 3 2' |
10 | setenv startaddress '0' |
11 | => |
Der output kann dann per Copy&Paste in eine Datei übernommen und editiert werden.
Holm T. schrieb: > @leo: (sorry für OT) hast Du indessen irgendwo mal eine > Referenzimplementation eines interruptbasierten Z180 serial- Treibers > gefunden? Referenzimplementation kenne ich keine, nichtmal andere interruptbasierte Beispiele. Meine eigenen Versuche findest Du in den Sourcen von Stamp-Monitor und CP/M 3 Bios:
1 | z180-stamp/z180/asci1-i.180 |
2 | z180-stamp-cpm3/cbios/ascii.180 |
Die sind aber schlecht kommentiert, von vielen Teilen des jeweiligen sonstigen Systems abhängig, die Monitor- (DDTZ-) Variante zu simpel, und die BIOS-Variante etwas "overengineered", unfertig, und auch sonst kaum als Beispiel zu gebrauchen...
Vielen Dank für die neue Monitorversion. Ich werde sie am Wochenende gleich mal testen und natürlich die Dokumentation um die Beschreibung erweitern. Die Möglichkeit die Environmentvariable automatisiert durch eine Datei zu setzen, hatte ich aus Faulheit (lief ja alles ;-) nicht genutzt. Jetzt werde ich es jedoch auch integrieren. Weiterhin hat sich gezeigt, dass ein Neueinsteiger ja recht hilflos vor dem nun schon komplexen System steht. Der erste Schritt für komplette Inbetriebnahmepakete ist ja schon getan. Hier werde ich mal weiter dran arbeiten.
Ich habe jetzt mal die neue Monitorversion in den Flash gebracht und das Laden der Variablen per Script getestet. Der Befehl printenv -s ist tatsächlich sehr nützlich :-) spart viel schreiben. Ansonsten läuft die Übernahme problemlos und bietet somit auch eine prima Variante unterschiedliche Einstellungen zu laden.
Hall Joe! Könntest du nochmal die jumpersetzung zeigen, damit beide stamps auf dem ecb zusammen mit dem flash-modul funktionieren? Entweder habe ich Fehler auf den Platinen oder die jumper sind falsch gesetzt....
Es sind zwei Betriebsvarianten möglich. Eine 5V Variante und eine 3.3V Variante. Ich beschreibe die 5V Variante über USB. 1. AVR-Stamp Die Stromversorgung (5V) erfolgt über die USB-Schnittstelle. Der AVR-Stamp benötigt jedoch neben den 5V auch 3.3V welche vom Z180-Stamp erzeugt werden. Aber der Reihe nach… JP1 schließen JP2 PIN2 und PIN3 brücken In der Doku (Seite 4) ist das die Variante V1-B Damit kommen die 5V vom USB-Steckverbinder über JP1 und JP2 an Vcc. Vcc liegt somit auch an B2 und sollte dort gemessen werden können. 2. Z180-Stamp Hier kommen die 5V von B2 über das ECB-Bord und werden mittels eines Reglers auf 3.3V umgesetzt. Hier gibt es zwei Layoutvarianten, die Version 1.0 und die Version 1.1 In der Layoutvariante 1.0 wird JP2 und JP3 geschlossen. Damit liegen 3.3V an B1 und sollten dort auch gemessen werden können. Weiterhin muss JP2 und JP4 geschlossen sein, damit der Z180 seine 3.3V bekommt. Da beide Varianten so nicht gesteckt werden können (Layoutfehler), ist für eine der beiden Brücken eine Lötstelle zu setzen. Variante C (Seite 3) Ist alles korrekt gebrückt, so muss am Bus B1 3.3V und B2 5V liegen. In der Layoutvariante 1.1 ist der Fehler behoben. Hier ist JP3 und JP6 zu schließen (Variante 1, Seite5). Auch hier muß nach korrekter Beschaltung am Bus B1 3.3V und am Bus B2 5V liegen. Weiterhin benötigt der Z180 einen Takt. Dieser kommt im „Normalfall“ vom AVR über CLKO (A28). Das bedeutet, dass JP1, Pin2 und Pin3 verbunden werden müssen. Ansonsten hat die CPU kein Takt. 3. ECB Das ECB-Board kann wiederum mit 3.3V oder 5V betrieben werden. Für die 3.3V Variante ist JP1 Pin2 und Pin1 zu brücken. Damit wird das Board komplett mit 3.3V versorgt. JP2 (Monitor) bleibt offen. JP3 bestimmt woher die Z180 CPU den Takt bekommt. Da wir über CLKO vom AVR takten wollen, ist JP3 Pin1 und Pin2 zu schließen. JP4 und JP6 bleiben offen. Weiterhin kann der RS232 Treiber deaktiviert werden. Wollen wir aber nicht und so bleibt JP5 auch offen. Nun sollte das System korrekt gesetzt sein.
Ergänzend zu den gestrigen Beschreibungen noch einige wichtige Hinweise. Einige der freien AVR-Pins müssen ebenfalls korrekt gesetzt sein, ansonsten ist möglicherweise die CPU im WAIT oder Halt über die Single-Step-Logik. Da man das File für die Environment Variablen nun prima dokumentieren kann (danke Leo ), habe ich es um die Beschreibung dazu erweitert. Weiterhin habe ich noch die Testbefehle für die externe SD-Card (FAT_1 und SD_1) eingefügt. Nach dem Bootvorgang des CP/M muss die CPU (Z180) in den Haltzustand gehen. Das korrekte Verhalten wird durch die zweifarbige LED angezeigt. Sie MUSS vollständig in der Farbe des Haltzustandes leuchten. Kommt hier, wenn auch schwach, die andere Farbe durch, ist etwas nicht in Ordnung.
@Harald Es gibt noch eine Minimalversion für die Inbetriebnahme. Dazu benötigst du nur den AVR-Stamp und den Z180-Stamp. Beide werden übereinander gesteckt. Unten der Z180, oben der AVR. Bei dieser Variante musst du jedoch beachten (!), dass nicht alle Pins verbunden sein dürfen. Die betroffenen Pins sind in der Doku im Anhang A mit „do not stack“ gekennzeichnet. Ich habe sie einfach auf dem Z180 abgeknipst. Das ist unproblematisch, da ja auch in der ECB-Version bis auf das SIDE-Interface nichts auf dem Z180 steckt. Im SIDE-Interface wird allerdings /DREQ1 benötigt, das Pin muss man dann wieder anlöten. In dieser Minimalversion kann das CP/M nun vollständig gebootet werden. Die AVR-Monitorausgabe und dann später die CP/M-Konsole laufen über die USB-Schnittstelle. Um die notwendigen Einstellungen und Testtools nutzen zu können, habe ich ein Skript (naked.sh) erstellt. Du bringst dieses Skript auf die Micro SD. Dazu noch cpm3.sys und cpm3_a.dsk (alles als ZIP im Anhang). Zur Installation musst du nun noch folgendes tun: => source naked.sh Nun muss die folgende Ausschrift erscheinen: Executing script: 'naked.sh'... ## Resetting to default environment ++ setenv cpm3_file 0:/cpm3.sys ++ setenv bootcmd pin ${pins}; reset; run attach_drives; loadc; go ${startaddress} ++ setenv d0 0:/cpm3_a.dsk ++ setenv d1 0:/cpm3_b.dsk ++ setenv d2 0:/cpm3_c.dsk ++ setenv d3 0:/cpm3_d.dsk ++ setenv d4 0:/cmp3_e.dsk ++ setenv attach_drives at -da; at dsk0 ${d0};at dsk1 ${d1};at dsk2 ${d2};at dsk3 ${d3};at dsk4 ${d4} ++ setenv singlestep 1 ++ setenv pin_alias 0:CSTART,1:SD1_CS,2:PB4,3:OC1A,4:V24_EN,5:PB7,6:SD1_CD,7:WAIT,8:RUN,9:ST EP,10:CLKO ++ setenv pins 2,8 low 9 high 3 2 ++ setenv esc_char 0x40 ++ setenv test_fat_0 fatstat 0:; fatls 0: ++ setenv test_fat_1 fatstat 1:; fatls 1: ++ setenv test_sd_0 sd status 0; sd init 0; sd info 0 ++ setenv test_sd_1 sd status 1; sd init 1; sd info 1 ++ setenv ddtz pin 3 2; loadf; mw 3 0; g 0; con ++ setenv debug-dsk at -o reattach,debug dsk0;at -o reattach,debug dsk1;at -o reattach,debug dsk2 ++ setenv cli Env setup completed successfully. Enter "saveenv" to make changes permanent. Jetzt speicherst du die Einstellungen dauerhaft im AVR EEPROM mittels => saveenv Saving Environment ... Dann startest du das System über die RESET-Taste neu. =========================< (RE)START DEBUG >========================= ### Reset reason(s): External. ATmega1281+Z8S180 Stamp Monitor - Version: 0.6.8.3 ### main_loop entered: bootdelay=3 ### main_loop: bootcmd="pin ${pins}; reset; run attach_drives; loadc; go ${startaddress}" Hit any key to stop autoboot: 0 CPU now in reset state. Attachment of '0:/cmp3_e.dsk' to dsk4 failed: Error opening file! Loading: '0:/cpm3.sys'... BNKBIOS3 SPR F900 0500 BNKBIOS3 SPR AD00 4300 RESBDOS3 SPR F300 0600 BNKBDOS3 SPR 7F00 2E00 60K TPA Loaded: Resident: 0x1E300-0x1EDFF, Banked: 0x07F00-0x0EFFF ## Starting application at 0xad00 ... -> Du befindest dich immer noch im Monitor, aber das CP/M hat schon gebootet und eine Konsolenausgabe auf CON1 getätigt, du siehst sie nur nicht auf der USB-Schnittstelle. Eine korrekte Ausschrift auf CON1 müsste so aussehen: CP/M Version 3.0, Z180-Stamp BIOS v0.6.8-23 Estimated CPU clock [Hz]: 18432000 sdio: SD Card driver cfio: CompactFlash Memory Card driver Model: PQI IDE DiskOnModule, S/N: DOM3C00004268, Rev: 060729DA Size: 256000 Sectors (128000 KiB) I: CP/M partition at: 2048, size: 8192KiB J: CP/M partition at: 18432, size: 8192KiB K: CP/M partition at: 34816, size: 8192KiB L: CP/M partition at: 51200, size: 8192KiB A>device CON:=USB0 Jetzt kannst du die USB-Schnittstelle mit dem CP/M verbinden. -> connect Connecting to CPU. Escape character is '^€'. Physical Devices: I=Input,O=Output,S=Serial,X=Xon-Xoff USB0 NONE IO ASCI0 19200 IOS ASCI1 115200 IOS Current Assignments: CONIN: = USB0 CONOUT: = USB0 AUXIN: = Null Device AUXOUT: = Null Device LST: = Null Device A> Du befindest dich jetzt im CP/M und kannst dort arbeiten. Um das CP/M wieder zu verlassen und zum Monitor zurückzukehren gibst du einfach das ESC-Char ein (eingestellt ist alt gr + @). [ESC Char] => Jetzt bist du wieder im Monitor. Ich hoffe, du kommst mit dieser Beschreibung nun etwas weiter.
Angehängte Dateien:
-
Z180.jpg
380 KB
Harald N. schrieb: > Könntest du nochmal die jumpersetzung zeigen, damit beide stamps auf dem > ecb zusammen mit dem flash-modul funktionieren? Hier noch eine brücke für das Z180 Modul in der Version 1.1. Ist mir leider nicht aufgefallen, da ich gerade mit der Version 1.0 arbeite. :-(
Joe G. schrieb: > Hier noch eine brücke für das Z180 Modul in der Version 1.1. Ist mir > leider nicht aufgefallen, da ich gerade mit der Version 1.0 arbeite. :-( Ist das nicht der Bug der in 1.1 behoben sein sollte? Weil von dieser 3er Brücke höre ich zum ersten Mal...
Angehängte Dateien:
-
Z180_2.jpg
90 KB
Theoretisch ja, in der Schaltung. Im Layout ist aber das zugehörige Pin um ein Platz versetzt, so dass der Jumper nicht gesetzt werden kann :-( Es hilft tatsächlich nur eine Lötbrücke im 3.3V Betrieb.
@ Leo C. Ich habe hier bei einer fehlerhaften CPU (Z180) Platine ein merkwürdiges Problem. Betreibe ich sie alleine (nur mit Versorgungsspannung) scheint sie zu laufen. Adresszähler läuft los, RAM Zugriff erfolgt, Daten werden gelesen… Im Zusammenhang mit dem AVR-Monitor tritt jedoch das folgende Problem auf: Z180 im RESET, Reset ist LOW MTEST gestartet RESET geht auf HIGH BUSRQ geht auf LOW CPU bestätigt mit BUSAK auf LOW Jetzt kommt der Fehler: Das MTEST Programm läuft los aber es werden keine Adressen von AVR auf den Bus gelegt, auch das WR und RD Signal kommt nicht, jedoch werden die Testdaten zum RAM-Test von AVR auf den Datenbus gelegt (HALT ist übrigens HIGH). Natürlich schlägt damit der MTEST fehl [1]. Bei einer lauffähigen Platine kommt ist dieses Verhalten nicht zu beobachten. Warum verhält sich der Monitor so merkwürdig? Ich kann beim besten Willen den Fehler nicht eingrenzen :-( [1] FAILURE (data line): Is 55, should be aa FAILURE (data line): expected aa, actual 55 FAILURE (data line): Is aa, should be 55 FAILURE (data line): expected 54, actual ab FAILURE (data line): Is 54, should be ab FAILURE (data line): expected a8, actual 57 FAILURE (data line): Is a8, should be 57 FAILURE (data line): expected 50, actual af FAILURE (data line): Is 50, should be af FAILURE (data line): expected a0, actual 5f FAILURE (data line): Is a0, should be 5f FAILURE (data line): expected 40, actual bf
Sehr seltsam, daß der AVR zwar Daten auf den Bus legt, aber Addressen und RD/WR nicht. MREQ? Ich würde ja auf einen Buskonflikt tippen. Dem widerspricht aber, daß BUSACK low ist. Leider kann ich z.Zt. nichts ausprobieren, da ich zwar ein Stamp-System hier habe, aber keinerlei Meßmittel. Du könntest probeweise mal die Monitorversion 0.6.8.1 ausprobieren. Ich hatte noch gar nicht erwähnt, daß es seit Version 0.6.8.2 (die hier nicht veröffentlicht wurde), einen Workaround für das ZRESET-Problem[1] gibt. Vielleicht funktioniert der nicht wie gedacht. [1] Beitrag "Re: Z180-Stamp Modul"
Ich konnte den Fehler etwas eingrenzen. Es ist nicht ganz wie beschrieben. Da der Ramtest einige ms dauert, hat der Oszi den nächsten Zyklus nicht mehr in den Speicher bekommen. Das Verhalten sieht nun tatsächlich so aus: Z180 im RESET, Reset ist LOW MTEST gestartet RESET geht auf HIGH BUSRQ geht auf LOW CPU bestätigt mit BUSAK auf LOW genau nach einem M1 Zyklus (also korrekt) MREQ kommt korrekt, weiterhin WR und RD Die Adressen A0 bis A17 zappeln bis auf A1 A1 ist immer HIGH (hier liegt offensichtlich irgendwo der Fehler) Ohne AVR läuft A1 jedoch korrekt – merkwürdig… Ich hatte auch mal die alte Monitorversion getestet, kein Unterschied. Wobei mir schon seit einiger Zeit ein Problem mit dem HALT aufgefallen ist. Nicht immer bootet das System so, dass es im HALT bleibt. Irgendwie wird zyklisch dieser Zustand verlassen. Überschreibe ich den RAM und starte neu, geht alles wieder. Aber erstmal die erste Baustelle…
@Leo: Ich habe gerade die EUMEL Sourcen Rolf-Dieter Klein für den 64180 geschickt bekommen. Die Sios werden da interuptgesteuert betrieben. Gruß, Holm
Die letzte Zeit habe ich mich wieder etwas mit der Hardware beschäftigt und dabei leider noch einen peinlichen Fehler (wieder-) entdeckt: Der RAM-Addressdecoder bezieht A19 mit ein, aber auf der AVR-Stamp ist A19 nicht angeschlossen. Keine Ahnung wieso uns das durch die Lappen gegangen ist. Zumal ich das beim Aufbau des Systems bemerkt haben muß, da ich A19 mit einem Pulldown "provisorisch" auf 0 gezogen habe. Der Widerstand ist auf dem Foto im Beitrag [1] über C9 zu sehen. @Joe Bei Dir oben scheint ja A1 ein Problem zu haben. Kannst Du überprüfen, ob das Problem evtl. auch mit A19 zu tun hat? [1] Beitrag "Re: Z180-Stamp Modul"
Stimmt, dumme Sache! Auf dem Z180 Stamp geht zwar A19 auf den Steckverbinder A3 aber ab da geht es nicht weiter :-( Auf dem AVR bleibt Steckverbinder A3 offen. Somit habe ich den Fehler nicht bemerkt, zumal bei mir der 7410 (zufällig) richtig dekodiert hat. Jetzt ist aber auch ein Widerstand drin :-) Mein Problem ist anderer Art und auch mit dem Widerstand nicht behoben. Nach dem Bootvorgang ## Starting application at 0xad00 ... startet das CP/M mit einer falschen Baudrate, eigentlich total fehlerhaft. Das Haltsignal vom Z180 kommt periodisch mit kurzen Impulsen. Nun muß ich Z180 Reset drücken und den AVR nochmals booten und erst dann (meistens jedenfalls) wird das CP/M richtig gestartet (keine Haltimpulse mehr). Diesen Fehler habe ich tatsächlich nie eingrenzen können. Das A1 Problem hatte ich auf einer weiteren Platine, das ist behoben (fehlende Lötstelle) :-(
Ok, da bei mir aber "alles" funktioniert - besteht da Handlungsbedarf? Muss ich an A19 jetzt etwas anlöten?
Offene Eingänge sind nie gut für die Betriebssicherheit. Hier ist es wohl so, daß der Z180 die meiste Zeit auf 0 zieht. Wenn der AVR zugreift, behält die Leitung offensichtlich ziemlich lange diesen Pegel bei. Falls jemand auf die Idee käme, das RAM auf 1Mbyte zu erweitern, würde er aber wahrscheinlich Probleme bekommen. Wenn der AVR sich dann den Bus schnappt, während der Z180 die A19 auf 1 hält, wird sie auch während dem AVR-Zugriff auf 1 bleiben. Der Pulldown ist sicher die einfachste und schnellste Möglichkeit , um das System zuverlässiger zu machen. In einem nicht erweiterten System auch ohne Nachteile. In einem erweiterten System würde der Pulldown den Bus belasten und/oder vielleicht zu langsam "schalten".
Hallo zusammen,
da ich gerade meine HP "aktualisiere" bin ich noch über folgende Dinge
gestolpert:
SingleStep
Wie ist/war denn da der letzte Stand? Ich sehe, das Joe die
Umgebungsvariable "singlestep = 1" verwendet - meines Wissen geht das
aber (noch) nicht? Wenn ja, was wäre denn da zu tun?
JP2 auf ECB-Board ("Monitor")
Der hat laut meinen Unterlagen (immer noch) keine Funktion?
ZReset-Bug
Da gabe es ja eien Bug in der HW - wurde der inzwischen in einer Version
beseitigt? Ich kann mich nicht mehr daran erinnern, hier etwas
nachgelötet zu haben... Wenn ich ZReset drücke resetet sich die CPU (ein
geladener DDTZ startet erneut bei 0 ...)
Vinculum
Ja... :-) gibts da was neues?
CSIO-Ports
Wenn ich die Beschreibung von Leo richtig lesen dann muss man noch ein
paar Kabel am Z180 an die Leitungen CKS/RXS/TXS anlöten?
Besten Gruß
Marcel
Marcel A. schrieb: > SingleStep Da steht was dazu: Beitrag "Re: Z180-Stamp Modul" > JP2 auf ECB-Board ("Monitor") > Der hat laut meinen Unterlagen (immer noch) keine Funktion? Das ist richtig. Die Kaltstart-Funktion ist immer noch nicht implementiert. Den entprellten ZReset-Taster (s.u.) könnte man auch noch damit machen. Beitrag "Re: Z180-Stamp Modul" > ZReset-Bug Hier ausführlich dargestellt: Beitrag "Re: Z180-Stamp Modul" > Da gabe es ja eien Bug in der HW - wurde der inzwischen in einer Version > beseitigt? Jeder der den Taster ausgebaut oder erst gar nicht bestückt hat, hat den Fehler beseitigt. ;) Der Monitor erkennt die Variante mit dem Transistor seit Version 0.6.8.2 automatisch. Platinen dafür gibts (noch) nicht. > Ich kann mich nicht mehr daran erinnern, hier etwas > nachgelötet zu haben... Wenn ich ZReset drücke resetet sich die CPU und der Port am AVR wird kurzgeschlossen... > (ein geladener DDTZ startet erneut bei 0 ...) Aber nicht immer zuverlässig, weil der Taster nicht entprellt ist. > CSIO-Ports > Wenn ich die Beschreibung von Leo richtig lesen dann muss man noch ein > paar Kabel am Z180 an die Leitungen CKS/RXS/TXS anlöten? Oder an der Basiskarte.
So, ich will endlich mal meinen Z180 fertig bekommen (sofern man davon sprechen kann :-)) und habe mal die SIDE gebaut - und gleich auf eine Karte für den ECB-Bus gepackt - nicht schön, aber geht :-) Ich habe zwar einen USB-IDE-Adapter - aber sowohl das DOM als auch der Adapter sind weiblich :-( - passen also nicht zusammen. Nun habe ich das "Formatierprogramm" für CPM aus Beitrag "Re: Z180-Stamp Modul" genommen - und siehe da:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8 |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver |
5 | Model: PQI IDE DiskOnModule, S/N: DOM3B00003949, Rev: 060729DA |
6 | Size: 256000 Sectors (128000 KiB) |
7 | I: CP/M partition at: 2048, size: 8192KiB |
8 | J: CP/M partition at: 18432, size: 8192KiB |
9 | K: CP/M partition at: 34816, size: 8192KiB |
10 | L: CP/M partition at: 51200, size: 8192KiB |
"SHOW" ist auch ok, aber ich habe damit das gleiche Problem wie Joe Beitrag "Re: Z180-Stamp Modul"
1 | I>dir |
2 | I: : : : : |
3 | I: : : : : |
4 | I: : : : : |
5 | I: : : : : |
Ich hatte mir damals selber 10 DOMs bei Pollin geholt, daher sind die "leer" gewesen... Komme ich da irgendwie weiter oder muss ich das Ding in einen alten IDE-Rechner einbauen? Ach so - wo finde ich denn den DDTZ für CPM wie hier verwendet: Beitrag "Re: Z180-Stamp Modul" Ich habe DDT, DDT180 und DDTZ (meldet sich mit "DDTZ v2.7M by CB Falconer. CPU=Z80") - DDTZ habe ich nur als Image für "loadf"... Besten Gruß Marcel
Hast du das Wipe Program von Leo C. mal versucht? Beitrag "Re: Z180-Stamp Modul" DDTZ Beitrag "Re: Z180-Stamp Modul"
:
Bearbeitet durch User
Danke - hatte ich glatt übersehen! Der Link zum DDT geht ja zu dem DDT180 - den habe ich ja auch - beim Screenshot von Leo zum SIDE meldet sich aber ein "DDTZ"... Zum Thema USB: Ich hatte gar nicht mehr auf dem Schirm, dass das ja eigentlich fertig ist? Beitrag "Re: Z180-Stamp Modul" So wie ich das sehe hast du ein Vinculum rund um den VNC2 nachgebaut und eine andere Firmware eingebracht? Bin mir nicht mehr sicher, ob ich die Platine habe.. Kann man da auch ein "richtiges" Vinculum nehmen? Ich habe auch noch so einen Nachbau von "Bübchen" (mit VNC2), die gehen aber im NKC nicht richtig (parallel mode), vielleicht hier aber (da seriell). Sind die UTools denn auch gefixt? Stichwort 5. Zeichen? Und noch was: Wenn ich das richtig verstanden habe wird das USB-Modul an die serielle Schnittstelle vom Monitor zum PC-Terminal/VT100 auf dem ECB-Board angeschlossen wo auch der AVR-Monitor und per "CON" die Konsole direkt zum Z180 liegt? Nicht die 2 seriellen Schnittstellen des Z180? Wie komme ich denn dann bei gestecktem USB-Modul an die AVR-Monitor-Konsole (Knoten um Hirn :-)=)? Beitrag "Re: Z180-Stamp Modul"
Ich hatte eine Platine für den VNC2 erstellt, welcher ein USB Anschluss (zwei sind möglich) und eine serielle Schnittstelle + Stromversorgung beinhaltete. Weiterhin habe ich die Firmware (USB to Seriell)auf ein externes USB-Laufwerk angepaßt. Die UTools aus dem KC85 Projekt habe ich nie verwendet. Meine Platine wird also komplett seriell angesteuert. An welcher seriellen Schnittstelle sie liegt ist eigentlich egal. Im Z180 Projekt sitzt die Platine an der seriellen Schnittstelle des Z180, vor dem RS232 Wandler! Diese Variante ist jedoch ungünstig, da der Jumper, der den Wandler inaktiv schaltet, gleich beide Schnittstellen außer Betrieb nimmt. So habe ich in einem weiteren Testaufbau dem Modul noch einen eigenen Max232 gespendet und zusätzlich das Pin RI der seriellen Schnittstelle mit 5V beschaltet um das Modul gleich mit zu versorgen. Dazu gibt es allerdings keine neue Leiterplatte (ist jedoch noch geplant).
Danke Joe, war mein Denkfehler. Die USB-Console vom AVR Monitor geht ja direkt auf eine eigene USB-Buchse (da habe ich optional noch einen RS232-Wandler schaltbar für den Anschluss eines externen VT100-Terminals). SIO1 macht ja die Startausgaben bei CPM vor dem Assign-Befehl in der Profile.SUB. Damit wäre SIO0 sinnvoll. Welche Tools setzt du denn jetzt letztlich unter CPM ein, um das als Laufwerk zu nutzen, wenn es nicht die UTools sind?
Marcel A. schrieb: > Ach so - wo finde ich denn den DDTZ für CPM wie hier verwendet: Wahrscheinlich habe ich ihn in den Diskimages zum SIMH Altair Simulator (wieder) gefunden (cpm2.dsk, cpm3.dsk). In den üblichen CP/M Archiven findet man immer nur den anderen DDTZ. > Ich habe DDT, DDT180 Dieser DDT180 ist ja nur ein etwas erweiterter DDTZ von oben. Funktioniert also auch genau so. > und DDTZ (meldet sich mit "DDTZ v2.7M by CB > Falconer. CPU=Z80") - DDTZ habe ich nur als Image für "loadf"... Das ist der "andere" DDTZ. Davon findet man verschiedene Versionen im Netz. Marcel A. schrieb: > Der Link zum DDT geht ja zu dem DDT180 - den habe ich ja auch - beim > Screenshot von Leo zum SIDE meldet sich aber ein "DDTZ"... Spielt aber keine Rolle, weil Programm laden und starten funktioniert bei beiden gleich. Diese Funktionen können natürlich auch alle anderen Debugger für CP/M. Ich würde Dir allerdings gleich den DDT180 von hier empfehlen: Beitrag "Re: Z180-Stamp Modul" oder noch besser: http://cloudbase.mooo.com/cgit/ddt180/
Marcel A. schrieb: > Welche Tools setzt du denn jetzt letztlich unter CPM ein, um das als > Laufwerk zu nutzen, wenn es nicht die UTools sind? Selbstgeschriebene, habe aber nie alle Funktionen realisiert. Ich müßte mir nochmals alles ansehen.
Angehängte Dateien:
Drei Tage ohne Internet. Das kommt dabei raus. Mehr dazu später.
Angehängte Dateien:
-
blockdiagram.png
120 KB
Joe G. schrieb: > Da bin ich gespannt :-) Eigentlich gibts dazu ja nicht mehr viel zu sagen, oder? Es ein Prototyp für eine weitere Alternative für die Z180 Karte. Den 10MHz TMPZ84C015[1] gibt bei Aliexpress für ca. 3€. Da konnte ich nicht widerstehen. Der TMPZ84C015 ist ein Z80 Chip von Toshiba mit integriertem CTC, PIO und SIO. Außerdem sind noch ein Watchdog-Timer und ein Taktgenerator, der verschiedene Strompar-Modi unterstützt, eingebaut. Der Clou: Die MPU kann abgeschaltet und der Rest als Peripherie an einer anderen CPU, z.B. Z180-Stamp, genutzt werden. Um diese Betriebsart zu testen, sind die Jumper J2 - J5 auf der Karte. Die SIO-Anschlüsse dürfen dann auch nicht auf die Steckerleiste A durchverbunden werden. Diese Leitungen habe ich deshalb auch noch nicht verlötet. [1] z.B. http://datasheets.chipdb.org/Toshiba/Z80/TMPZ84C015B.pdf
Die MCU mittels Evaluator-Signal abzuschalten ist tatsächlich eine höchst interessante Funktion. Somit hat man PIO,SIO,CTC und Watchdog in einem Chip, an einem Bus. Leider habe ich den TMPZ84C015 bei Aliexpress nur in größeren Abnahmemengen gefunden. Hast du dazu eine Quelle?
Joe G. schrieb: > TMPZ84C015 Joe G. schrieb: > Hast du dazu eine Quelle? Einfach neu kaufen bei Digikey https://www.digikey.de/products/de?keywords=%20%09269-3906 auch als 16 MHz Version https://www.digikey.de/product-detail/de/zilog/Z84C1516FSG/269-3908-ND/ Gruss
Erich schrieb: > Einfach neu kaufen bei Digikey > https://www.digikey.de/products/de?keywords=%20%09269-3906 > > auch als 16 MHz Version > https://www.digikey.de/product-detail/de/zilog/Z84C1516FSG/269-3908-ND/ Das ist der Zilog-Nachbau, der sogar noch etwas besser ist. Allerdings nicht für 3€, sondern eher das 4-fache Joe G. schrieb: > Leider habe ich den TMPZ84C015 bei Aliexpress > nur in größeren Abnahmemengen gefunden. Du kannst gerne einen von mir haben, auch wenn keine Platine draus wird. Und dann habe ich noch einige zum Preis von 2,8€ + Versandkosten abzugeben. :-) > Hast du dazu eine Quelle? Meine habe ich von hier: https://www.aliexpress.com/item/Free-shipping-10pcs-lot-Tmpz84c015bf-10-TMPZ84C015BF-TMPZ84C015-QFP-100-IC/32472094972.html
Leo C. schrieb: > Du kannst gerne einen von mir haben, auch wenn keine Platine draus wird. > Und dann habe ich noch einige zum Preis von 2,8€ + Versandkosten > abzugeben. :-) Leider erst jetzt die Antwort. Das AVR CP/M System hatte mich gerade etwas beansprucht. Danke für das Angebot! Ich nehme gernen in IC.
Hmm...16Mhz? CPU abschaltbar? Ist das die Peripherie deren Fehlen mich an der Z180 Stamp als Einziges stört? Gruß, Holm
Hallo Joe, dann hätte ich gerne 1 SIDE und je nach Vorrat 2-5 DOM. Schick mir doch deine Kontodaten per mail. Vielen Dank Günther
normalerweise hier: Beitrag "Re: Z180-Stamp Modul" Der Server scheint jedoch gerade nicht zu laufen. Leo C. kann sicher dazu eine Auskunft geben.
Joe G. schrieb: > Der Server scheint jedoch gerade nicht zu laufen. Leo C. kann sicher > dazu eine Auskunft geben. Der Server ist schon einige Wochen down (bootet nicht mehr). Eigenlich wollte ich sowiso die Hardware ersetzen, aber da ich wenig Zeit habe, und ihn bisher niemand vermisst hatte, habe ich mich noch nicht darum gekümmert. Mal sehen, ob ich ihn nächste Woche wieder ans Laufen kriege. Günther S. schrieb: > Hallo Leo, > kann man die BIOS-Quellen von dir bekommen? Bin z.Zt. nicht zu Hause, deshalb im Anhang nur der Stand, den ich auf meinem Laptop rumliegen habe.
Holm T. schrieb: > Hmm...16Mhz? CPU abschaltbar? Ist das die Peripherie deren Fehlen mich > an der Z180 Stamp als Einziges stört? Ich muß zugeben, daß Deine Nörgelei über fehlende (Standard-) Peripherie eine der Triebfedern war, mich mit dem Chip zu beschäftigen. :-)
Leo C. schrieb: > Holm T. schrieb: >> Hmm...16Mhz? CPU abschaltbar? Ist das die Peripherie deren Fehlen mich >> an der Z180 Stamp als Einziges stört? > > Ich muß zugeben, daß Deine Nörgelei über fehlende (Standard-) Peripherie > eine der Triebfedern war, mich mit dem Chip zu beschäftigen. :-) Och Menno.. ich nörgele doch nicht. Ich hätte nur gerne für mich zum Spielen ein paar Drähte dran. Es ist zwar cool mit ziemlicher Geschwindigkeit Compilerläufe und Wordstar durchlaufen lasen zu können, das sind aber Dinge die ich auf solcher Hardware eher nicht zu erledigen habe. Trotzdem Dank für Deine viele Arbeit. Wenn ich Dir mit dem Server irgendwie behilflich sein kann, sag es, ich habe Hardware bei Hetzner im RZ unter FreeBSD laufend. Gruß, Holm
Mein kleiner Server ist wieder online und der Z180-Stamp Sourcecode wieder unter http://cloudbase.mooo.com/cgit/ erreichbar.
Leo C. schrieb: > Mein kleiner Server ist wieder online und der Z180-Stamp Sourcecode > wieder unter http://cloudbase.mooo.com/cgit/ erreichbar. Danke! Gruß, Holm
Leo ich habe mal ne Frage..
Ich hatte zum Robotron Treffen in Garitz meine Z180 Stamp mit und es
gibt da noch Interessenten..nach Rücksprache mit Joe lege ich evtl. mal
noch Platinen auf, schaunmermal..
Aber..ich habe in Garitz eine komische Industrieplatine mit einem
Z18S18020VSC geschenkt bekommen und habe das Ding heute mit Heißluft
runter gelötet, sauber gemacht und in die PLCC Fassung gesteckt..geht
..aber seltsam, sie ASCI 1 läuft als Console mit 115200 Baud:
CP/M Version 3.0, Z180-Stamp BIOS v0.6.8
Estimated CPU clock [Hz]: 18432000
sdio: SD Card driver
cfio: CompactFlash Memory Card driver: No Card
A>
Auf der CPU steht noch SL1960 und 9836 H3.
Ich habe noch weitere 5 Z8S18020VSC, eine davon gelasert Date Code 0721
PF und 4 gelb bedruckt 9921 IY. Diese 5 Starten mit
CP/M Version 3.0, Z180-Stamp BIOS v0.6.8
Estimated CPU clock [Hz]: 18432000
sdio: SD Card driver
cfio: CompactFlash Memory Card driver: No Card
A>
..und 19200 Baud, genauso wie eine Z8S18033VSC mit DateCode 0228.
Des Weiteren habe ich nun noch 4 Z8018010VSC mit Datecode zwischen 9123
und 9346 die mit
CP/M Version 3.0, Z180-Stamp BIOS v0.6.8
Estimated CPU clock [Hz]: 9216000
sdio: SD Card driver
cfio: CompactFlash Memory Card driver: No Card
A>
starten und mit 57600 Baud auf der ASCI1 laufen. Das verwundert mich
nicht, da die Z180 keinen Baudratengenerator wie die S und L Versionen
haben.
..aber was ist mit der Z8S180 los, die da mit 115200 Baud hoch kommt
anstatt mit 19200 wie die restlichen Z8S180? Ich habe nicht die letzte
Version CP/M auf dem Ding, das sind noch Deine älteren polled Treiber..
Hast Du ne Idee?
Das noch:
=> printenv
attach_drives=at dsk0 ${dsk0};at dsk1 ${dsk1};at dsk2 ${dsk2};at dsk3
${dsk3};at dsk4 ${dsk4};at dsk5 ${dsk5};at dsk6 ${dsk6};at dsk7 ${dsk7}
baudrate=115200
bootcmd=pin 8 low 3 9MHz; run attach_drives;loadcpm ${cpm3_file}; go
${startaddress}
bootdelay=3
cpm3_commonbase=f000
cpm3_file=0:cpm3_0.6.8.sys
cpm3_scb=1e900
dsk0=0:/cpm3test.dsk
dsk1=0:/diskb.dsk
dsk2=0:/diskc.dsk
dsk3=0:/diskd.dsk
dsk4=0:/diske.dsk
dsk5=0:/diskf.dsk
dsk6=1:/diskg.dsk
dsk7=1:/diskh.dsk
esc_char=0x40
pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10
:PE7
startaddress=b300
Environment size: 574/1597 bytes
=>
Gruß,
Holm
Joe G. schrieb: > Alle Unterlagen wie immer hier: > http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/z180_stamp/docs/ Scheisse, da sind ja sogar Schaltpläne im Eagle dabei! Jetzt kann man nicht mal mehr meckern...
Leo C. schrieb: > Hilft Dir das weiter? Jepp, danke Dir. Ich wußte nicht das es eine SL1960 Version gibt die sich von den anderen unterscheidet. Gruß, Holm
Raph schrieb: > Scheisse, da sind ja sogar Schaltpläne im Eagle dabei! Jetzt kann man > nicht mal mehr meckern... Wobei Side und ECB noch fehlen. Wie mit Holm schon besprochen gibt es die Tage einen Link zu Github mit allen relevanten Daten für den Nachbau.
..wegen meinem alten Elend mit der Peripherie...eine PIO hab ich nicht gefunden (bisher) aber eine PPI: http://www.cpcwiki.eu/index.php/VHDL_implementation_of_the_8255_PIO Evtl. ist ja dem Ding mit einem CPLD Beine zu machen das es schnell genug wird? Man müßte mal Einen fragen der sich damit auskennt.. Ich werde auch mal die Truppenteile mit dem Verilog SPI Master anmailen ob die das für "nonprofit" evtl. rausrücken..mehr als Nein können die ja schlecht sagen. Gruß, Holm
Mir ist da noch was eingefallen, hier bei mc.net lief doch mal dieses Retrocomputing Projekt auf einem FPGA, der Z1013 und ein Z1013 enthält eine PIO...ergo: https://www.mikrocontroller.net/svnbrowser/redz0mb1e/src/vhdl/PIO.vhd?revision=104&view=markup&sortby=date gibts da eine Z80 PIO in VHDL. Ich habe mit FPGA noch nie was gemacht und mit CPLDs sehr begrenzt. Ich werde mal versuchen den Autor zu kontaktieren ob er es für möglich hält diese PIO einzeln in ein CPLD zu planzen, immerhin hat die PIO die Möglichkeit IM2 zu unterstützen. Edit: Möchte Jemand evtl. eine ECBbackplane mit 4 Slots haben? Ich werde wahrscheinlich Solche machen lassen: https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:backplane-4:start Ich würde die dann für den Selbstkostenpreis + Porto abgeben. ..hab 10 Stk. bestellt, die haben ne Macke. "Special Discount" bei JLCPCB, die 10 Platinen kosten: 1,77..mit Versand 17,97 Euro.. soll angeblich in 14 Tagen hier sein. Für den Preis kann man die nicht mal klauen lassen. Die kleine 3er gefällt mir angesichts unseres hektischen Systems besser..aber da gibts keine Daten, die müßte ich erst nachbauen. Gruß, Holm
Ich habe mich mal an eine Aktualisierung gemacht, habe stamp-monitor_hexrel-6.8.3.zip geflashed und z180-stamp-cpm3_0.6.8-24-dirty_src-only.zip gebootet.. nebenbei das Environment angepaßt, aberdann war die Baudrate vergriesgnaddelt, es kam nix Vernünftiges mehr heraus. Der SL1960 war der Einzige dem ich was entlocken konnte, der erzählte mit 57600 Baud bei 3,88Mhz Taktfrequenz. Ich habe mich deshalb mal über die Einstellungen gemacht: cpm3_file=0:cpm3_0.6.8-24-dirty.sys 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:CLKO pins=2,8 low 9 high 3 9M singlestep=1 -> pin -s 0 CSTART Pullup Low 1 SD1_CS Output High 2 PB4 Output Low 3 OC1A Clock 8999936 2 4 V24_EN Pullup High 5 PB7 Pullup High 6 SD1_CD Pullup Low 7 WAIT Pullup High 8 RUN Output Low 9 STEP Output High 10 CLKO Pullup High CP/M Version 3.0, Z180-Stamp BIOS v0.6.8-24-dirty Estimated CPU clock [Hz]: 18432000 sdio: SD Card driver cfio: CompactFlash Memory Card driver: No Card A> Am Z8S180 liegen (Quarzfassung) 18,432 MHz an ..hab ich noch einen Jumper falsch? Ich dachte da müßten 9,216Mhz auflaufen..und wiso denkt sich de AVR so eine krumme Clock? ok .. setenv pins '2,8 low 9 high 3 9216K' geht auch. ..nanu..jetzt kommt wieder nur Kauderwelsch... Gruß, Holm
Leo was stellt denn Deine z180-stamp-cpm3_0.6.8-24-dirty_src-only.zip für eine Baudrate bei welcher Taktfrequenz des Z180 ein? Ich komme damit nicht klar. Ich habe die Jumperei untersucht und erst mal den Takt auf OC1A umgejumpert, hab auch (wieder) gelernt das man einen Teilerfaktor angeben muß im pin cmd, es liegen 9,216 Mhz an der Z180 an ,damit zeigt cpm3_0.6.8.sys auch 9 Mhz an: CP/M Version 3.0, Z180-Stamp BIOS v0.6.8 Estimated CPU clock [Hz]: 9216000 sdio: SD Card driver cfio: CompactFlash Memory Card driver: No Card A> Mit der z180-stamp-cpm3_0.6.8-24-dirty bekomme ich überhaupt keine nachvollziehbare Baudrate. Was ist denn da voreingestellt? Gruß, Holm
Angehängte Dateien:
-
backplane.jpg
44 KB
Holm T. schrieb: [..] > ..hab 10 Stk. bestellt, die haben ne Macke. "Special Discount" bei > JLCPCB, > die 10 Platinen kosten: 1,77..mit Versand 17,97 Euro.. soll angeblich in > 14 Tagen hier sein. Für den Preis kann man die nicht mal klauen lassen. > > Die kleine 3er gefällt mir angesichts unseres hektischen Systems > besser..aber da gibts keine Daten, die müßte ich erst nachbauen. > > Gruß, > Holm Streß haben die wohl gerade nicht, siehe Anhang... Gruß, Holm
Ich habe hier echt Sorgen mit dem Takt. Aus dem AVR kommen 9,2 Mhz raus, die leigen auch an EXTAL und XTAL an, an PHI erscheinen aber 4,6Mhz. In boot.180 ist definiert: dseg hwini_tab: db (hwini0_e-$)/2 ;count db rcr,CREFSH ;configure DRAM refresh db dcntl,CWAITIO ;wait states db ccr,M_NCD ;No Clock Divide db cmr,PHI_X2 ;X2 Clock Multiplier db omcr,~M_IOC ;Operation Mode Control Register hwini0_e: db 0 ;stop mark PHI_X2 ist aber in config.inc per default 0, der Kommetar sagt das das für verdoppelten Takt auf PHI_X2 equ M_X2CM ;set to M_X2CM to enable the clock doubler gesetzt werden soll. Woher kommt M_X2CM? Definiert ist das nirgends, bastelt das irgend ein Makro? Mit Joes CP/M das die console auf USB0 umleitet sehe ich was, das System läuft aber extrem langsam, über den Daumen gepeilt mit 2,5Mhz. Ich kann leider nicht sehen was die Z180 über ihrn eigenen Clock denkt, da auf der ASCI1 wirklich nur Kauderwelsch raus kommt. Ich habe das mit Leos 24-dirty und auch mit dem Zeug aus dem Git probiert. Was ist denn da los? Ich würde das hier in boot.180 gerne mal tot legen: call msginit call cpu_frq ld (f_cpu),hl ld (f_cpu+2),de Weil da offensichtlich Käse für die Baudratenkalkulation heraus kommt, was muß da für 18,432 Mhz rein? Ich habe leider auch kein funktionierendes ld80 binary..und so kein map file. Gruß, Holm
..nu gucke an..
1 | dseg ; init done from banked memory^M |
2 | ^M |
3 | hwinit:^M |
4 | ld a,(INIDONE)^M |
5 | and 80h^M |
6 | cp INIDONEVAL^M |
7 | ; jr z,hwini_skip^M |
8 | nop |
9 | nop |
10 | ld hl,hwini_tab^M |
11 | call ioini1l^M |
Wenn ich verhindere das die Hardwareinitialisierung ausgelassen wird, macht die CPU ganz plötzlich was sie soll:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8-24-dirty |
2 | Estimated CPU clock [Hz]: 18070588 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | A>dir |
6 | A: BDOS3 SPR : BNKBDOS3 SPR : CCP COM : COPYSYS COM : CPMLDR REL |
7 | A: DATE COM : DEVICE COM : DIR COM : DUMP COM : ED COM |
8 | A: ERASE COM : GENCOM COM : GENCPM COM : GET COM : HELP COM |
9 | A: HELP HLP : HEXCOM COM : PATCH COM : PIP COM : PUT COM |
10 | A: README : RENAME COM : RESBDOS3 SPR : SAVE COM : SET COM |
11 | A: SETDEF COM : SHOW COM : SID COM : SUBMIT COM : TYPE COM |
12 | A: DEVICE PLM : HELP DAT : CPMLDR COM |
13 | A> |
Wo wird denn INIDONE mal gelöscht Leo? # fgrep -i INIDONE *.180 ascii.180: ld a,(INIDONE) ascii.180: cp INIDONEVAL boot.180: ld a,(INIDONE) boot.180: cp INIDONEVAL conbuf.180: ld a,(INIDONE) conbuf.180: cp INIDONEVAL msgbuf.180: ld a,(INIDONE) msgbuf.180: cp INIDONEVAL Gruß, Holm
Leo Du hast offensichtlich mit einem ROM Boot der Z180 experimentiert, mit 9Mhz Takt ohne Multiplier. Die Hardwareinitialisierung in ldrbios.180 ist nicht mit INIDONE und INIDONEVAL verriegelt und funktioniert deshalb, die in boot.180 die aber beim Booten aus dem .sys File benutzt wird ..nur manchmal INIDONE ist die Speicherzelle 03fh und irgend ein Inhalt mit gesetztem Bit 7 da drin reicht aus, das der Prozessor nicht vernünftig initialisiert wird.
1 | dseg ; init done from banked memory |
2 | |
3 | hwinit: |
4 | ld a,(INIDONE) |
5 | and 80h |
6 | cp INIDONEVAL |
7 | jr z,hwini_skip |
So wie Du das machst kann ja da nur 080h oder 0 drin stehen, was bei einem leeren Speicher mit 0ffh oder auch zufälligem Inhalt eine hohe Chance ergibt, das die Initialisierung weg fällt und man wie ich mit obskuren Taktfrequenzen und Baudraten kämpft. Andererseits scheint auch das ldrbios.180 nach erfolgreicher Initialisierung das Flag in INIDONE nicht zu setzen...das ist wohl ne angefangene Baustelle (wie der Name -dirthy auch suggeriert). Ich schlage vor nicht 7 Bit einsparen zu wollen und ein Flag wie 55h, 0aah, oder 5ah, 0a5h zu setzen, das macht eine Fehlfunktion etwas unwahrscheinlicher.... andererseits ist das in boot.180 eher fehl am Platz, da das Label boot: ein Kaltstart Entry sein sollte und ein Kaltstart davon ausgehen sollte das initialisiert werden muß. Hab ich dabei was übersehen? Was wolltest Du einsparen? Ich bin wie schon erwähnt bei CP/M 3 nicht fit... Gruß, Holm
@Holm Super analysiert! Ich hatte mir schon einen Wolf bei meinem System gesucht, warum die Initialisierung mal geht und mal nicht. Da ich immer den Fehler auf der Hardwareseite gesucht hatte, habe ich irgendwann aufgegeben. Aufgrund deines Hinweises schnell das System auf den Tisch geholt und getestet. 0x3F = AC – unleserliche Terminalausgabe – auch RESET hilft nicht. 0x3F mit 00 beschrieben und RESET – alles ist gut!
..danke für die Blümchen Joe..ich hatte mir schon Gedanken um meine Selbstgespräche gemacht :-) Ich habe mir indessen mal einen Überblick verschafft was Leo in den ASCI Treibern so macht..whow, er hat ein termios ioctl Interface angefangen zu implementieren. Ich hatte mich gewundert warum keine Flußkontrolle auf der Console funktioniert..ASCI1 kann ja nur xon/xoff ..aber das gibts noch nicht. Jetzt bin ich am Grübeln ob ich mich da ran traue.. Leos Programmierkünste in Z80 Assembler liegen noch 2 Etagen über meinen..mal gucken. Ich brauche ne Merkzelle, mal gucken in welcher Bank ich Platz dafür finde.. Gruß, Holm
Holm T. schrieb: > Mir ist da noch was eingefallen, hier bei mc.net lief doch mal dieses > Retrocomputing Projekt auf einem FPGA, der Z1013 und ein Z1013 enthält > eine PIO...ergo: > > https://www.mikrocontroller.net/svnbrowser/redz0mb1e/src/vhdl/PIO.vhd?revision=104&view=markup&sortby=date > > gibts da eine Z80 PIO in VHDL. > > Ich habe mit FPGA noch nie was gemacht und mit CPLDs sehr begrenzt. Ich > werde mal versuchen den Autor zu kontaktieren ob er es für möglich hält > diese PIO einzeln in ein CPLD zu planzen, immerhin hat die PIO die > Möglichkeit IM2 zu unterstützen. Die Anfrage ist beim Autor angekommen ;-) Eine Antwort ging auch raus, allerdings an den holm auf robotrontechnik.de -> ich bin tatsächlich urlaubsreif. Also mit den üblichen Alt-CPLD's sehe ich wenig Chancen, da die wenig Flipflops bieten (1-2 pro pin) und lt. letztem Synthesereport 90 davon benötigt werden (und die Z1013 Retro PIO ist schon abgespeckt). Man könnte mal das Design für einen Xilinx XC950xxx durchlaufen lassen, ich erwartet das das höchstens für eine festkonfigurierte (bspw Richtung) PIO passt. Überlegenswert ist aber IMHO ein Lattice "Crossover" CPLD (MachXO?) mit Levelshiftern. Das wäre dann ein kleines 5V geeignetes CPLD. Preis für den kleinsten liegt bei 2-3$ der nächstgrösser (640LUT) so um die 10€, als levelshifter könnte man 24bit busswitches für ca. 3$ verwenden. IMHO wäre es überlegenwert da einen DIL-Module zu machen, das man auch für andere Peripherie wie TIMER verwenden könnte. Die 10 MHz sollten kein Problem sein. So ein DIL-Ersatz auf FPGA-Basis gibt es bereits als GODIL https://shop.trenz-electronic.de/de/Produkte/OHO-Elektronik/GODIL/ Der steht da aber mit ca. 50€ im Katalog und ist hier nur als Prinzipbeispiel verlinkt. Mit Selbstausbeutung und den passenden CPLD scheint mir als Forumsprojekt ein Z80-Peripherieersatz um 15€ möglich. MfG,
Fpga K. schrieb: > Holm T. schrieb: >> Mir ist da noch was eingefallen, hier bei mc.net lief doch mal dieses >> Retrocomputing Projekt auf einem FPGA, der Z1013 und ein Z1013 enthält >> eine PIO...ergo: >> >> > https://www.mikrocontroller.net/svnbrowser/redz0mb1e/src/vhdl/PIO.vhd?revision=104&view=markup&sortby=date >> >> gibts da eine Z80 PIO in VHDL. >> >> Ich habe mit FPGA noch nie was gemacht und mit CPLDs sehr begrenzt. Ich >> werde mal versuchen den Autor zu kontaktieren ob er es für möglich hält >> diese PIO einzeln in ein CPLD zu planzen, immerhin hat die PIO die >> Möglichkeit IM2 zu unterstützen. > > Die Anfrage ist beim Autor angekommen ;-) > Eine Antwort ging auch raus, allerdings an den holm auf > robotrontechnik.de -> ich bin tatsächlich urlaubsreif. Na ob der wohl was damit anfangen kann...soviel ich weiß hat der auch da geantwortet. :-) > > Also mit den üblichen Alt-CPLD's sehe ich wenig Chancen, da die wenig > Flipflops bieten (1-2 pro pin) und lt. letztem Synthesereport 90 davon > benötigt werden (und die Z1013 Retro PIO ist schon abgespeckt). Man > könnte mal das Design für einen Xilinx XC950xxx durchlaufen lassen, ich > erwartet das das höchstens für eine festkonfigurierte (bspw Richtung) > PIO passt. der von mir als Beispiel genannte alt CPLD EPM7160 (MAX7000) hat 160 Makrozellen an 64 User I/O Pins und 3200 Gates. Probiere das mal mit der Synthese. > > Überlegenswert ist aber IMHO ein Lattice "Crossover" CPLD (MachXO?) mit > Levelshiftern. Das wäre dann ein kleines 5V geeignetes CPLD. Preis für > den kleinsten liegt bei 2-3$ der nächstgrösser (640LUT) so um die 10€, > als levelshifter könnte man 24bit busswitches für ca. 3$ verwenden. IMHO > wäre es überlegenwert da einen DIL-Module zu machen, das man auch für > andere Peripherie wie TIMER verwenden könnte. Die 10 MHz sollten kein > Problem sein. 10Mhz? 20! Eine 10Mhz PIO bekommt man noch zu kaufen. > > So ein DIL-Ersatz auf FPGA-Basis gibt es bereits als GODIL > https://shop.trenz-electronic.de/de/Produkte/OHO-Elektronik/GODIL/ > Der steht da aber mit ca. 50€ im Katalog und ist hier nur als > Prinzipbeispiel verlinkt. > > Mit Selbstausbeutung und den passenden CPLD scheint mir als > Forumsprojekt > ein Z80-Peripherieersatz um 15€ möglich. > > MfG, Das geht IMHO noch .. Gruß, Holm
Ich hab ein Bisschen in den asii Treibern herum gehackt um ein IXOFF auf der ASCI1 hin zu kriegen. Irgendwie geht das langsam und bei mir sind temporär ein Haufen Ausrufezeichen (unter Wordstar!?) auf dem Bildschirm zu sehen die verschwinden wenn Alles einkopiert ist, aber es war möglich Joes scb.pas Programm mit Friß und Kotz aus dem Firefox nach Wordstar zu transportieren und das Ding fehlerfrei mit Turbo 3.02A zu kompilieren. Ich kann das auch direkt nach Turbo in den Editor fallen lassen syntaktisch ist das Programm einwandfrei und läßt sich kompilieren, aber wahrscheinlich auf Grund der Terminalemulation sind da die Zeilen treppenförmig seitlich versetzt. Ich habe minicom unter FreeBSD verwendet, mit 57600 8N1 und XON/XOFF Flußkontrolle. Wers mal probieren will, die wesentlichen Dateien sind im Anhang, Makefile oder Submit Dateien anpassen oder Dateinamen ändern. Leo wird da nochmal drüber gucken müssen, das ist mit Sicherheit nicht das Optimum, es erscheint mir zu langsam zu gehen beim paste aber besser als gar nicht... IXOFF in den iflags ist defaultmäßig eingeschaltet und nur bei ASCI1 aktiv... Gruß, Holm
Holm T. schrieb: >> Die Anfrage ist beim Autor angekommen ;-) >> Eine Antwort ging auch raus, allerdings an den holm auf >> robotrontechnik.de -> ich bin tatsächlich urlaubsreif. > > Na ob der wohl was damit anfangen kann...soviel ich weiß hat der auch da > geantwortet. :-) Jup, angekommen, und die robotrontechnik-Hirnhälfte hat auch der mikrocontroller-Hirnhälfte Bescheid gegeben ;-) > der von mir als Beispiel genannte alt CPLD EPM7160 (MAX7000) hat 160 > Makrozellen an 64 User I/O Pins und 3200 Gates. > Probiere das mal mit der Synthese. 160 MC sind 160FF, das sieht nicht hoffnungslos aus(wie gesagt 90 im letzten report) Hab mir grad die passende Software aus dem Downloadkeller geholt (Quartus Web 13.0sp1) und schau mal was in der anstehenden Urlaubswoche in der Oberlausitz wird. Ich hab jetztz nicht den ganzen Briefmarkenthread gelesen, bin aber schon mal drüber gestolpert, das wohl für Stamp Features (M2-IRQ(?)) drin sein müßen, die so noch nicht implementiert sind. Ich bin die PIO nach der U855 Beschreibung im Buch von Kieser/Meder nach. Falls es davon Abweichungen gibt (ist halt nicht die Originale Z80-PIO) bitte Bescheid geben. MfG,
Fpga K. schrieb: > Holm T. schrieb: > >>> Die Anfrage ist beim Autor angekommen ;-) >>> Eine Antwort ging auch raus, allerdings an den holm auf >>> robotrontechnik.de -> ich bin tatsächlich urlaubsreif. >> >> Na ob der wohl was damit anfangen kann...soviel ich weiß hat der auch da >> geantwortet. :-) > > Jup, angekommen, und die robotrontechnik-Hirnhälfte hat auch der > mikrocontroller-Hirnhälfte Bescheid gegeben ;-) > > >> der von mir als Beispiel genannte alt CPLD EPM7160 (MAX7000) hat 160 >> Makrozellen an 64 User I/O Pins und 3200 Gates. >> Probiere das mal mit der Synthese. > > 160 MC sind 160FF, das sieht nicht hoffnungslos aus(wie gesagt 90 im > letzten report) Hab mir grad die passende Software aus dem > Downloadkeller geholt (Quartus Web 13.0sp1) und schau mal was in der > anstehenden Urlaubswoche in der Oberlausitz wird. Ich habe wohl auch noch kleinere (7128,7064). > > Ich hab jetztz nicht den ganzen Briefmarkenthread gelesen, bin aber > schon mal drüber gestolpert, das wohl für Stamp Features (M2-IRQ(?)) > drin sein müßen, die so noch nicht implementiert sind. Ich bin die PIO > nach der U855 Beschreibung im Buch von Kieser/Meder nach. Falls es davon > Abweichungen gibt (ist halt nicht die Originale Z80-PIO) bitte Bescheid > geben. > > MfG, Nein, kein Grund zur Aufregung, die sind ausreichend identisch.. Ich bin neugierig was Du da zusammenbastelst. Gruß, Holm
Hab gerade mal das System unter cp/m selbst gebaut, die Argumentliste für SLR180 im Submit-File wird zu lang, ich habe den Assemblerlauf in 2 Teile aufteilen müssen, sonst klappt das aber. Hat Jemand ein funktionierendes Linux Binary des LD80 und könnte mir das mal zukommen lassen? Der Linuxulator von FreeBSD funktioniert i.A. ganz gut, aber der auf meinem System gebaute LD80 wirft ne core, ich würde mich später drum kümmern wollen...aber hätte zwischenzeitlich gerne ein MAP file des BIOS. Man müßte mal probieren ob man den Kram auch mit dem SRLink oder dem L80 zusammen bekommt... Gruß, Holm
Holm T. schrieb: > Hab gerade mal das System unter cp/m selbst gebaut, die Argumentliste > für SLR180 im Submit-File wird zu lang, ich habe den Assemblerlauf in 2 > Teile aufteilen müssen, sonst klappt das aber. Wie wärs mit der I-Option? | The I option is a special case option used for indirect | command file input. If this option is used, it can be the only | option specified. The /I option causes SLR180 to read the file | <FILENAME>.SUB on the default drive (or the selected source drive) | for its command lines. This is similar to using SUBMIT and XSUB | except that 1) it is much faster, 2) it can be used from within | a SUBMIT file, 3) it can be used without XSUB and SUBMIT leaving | more RAM available for the assembly, and 4) it can be used while | A: is not the default drive. > Hat Jemand ein funktionierendes Linux Binary des LD80 und könnte mir das > mal zukommen lassen? Im Anhang. > aber der auf meinem System gebaute LD80 wirft ne core, ich würde > mich später drum kümmern wollen Darf ich fragen von wo Du den Sourcecode hast? Die originale Version 04b hatte bei mir die gleiche Krankheit. Das habe ich gefixed und noch ein paar Kleinigkeiten geändert. > ...aber hätte zwischenzeitlich gerne ein MAP file des BIOS. Der ld80 wird ja wirklich nur für das Mapfile verwendet. Das bios an sich wird mit dem Linker von DR (link80) generiert. Dieser produziert ein Symbolfile namens 'bnkbios3.sym'. Vielleicht reicht Dir das. > Man müßte mal probieren ob man den Kram auch mit dem SRLink oder dem L80 > zusammen bekommt... Mit dem L80 bestimmt nicht. Der link80 von DR wird benötigt, um das spezielle spr-Format (System Page Relocatable) zu erzeugen. Der SRLink kann das wahrscheinlich auch nicht. Zu den anderen Sachen werde ich heute auch noch was schreiben.
Leo C. schrieb: > Holm T. schrieb: >> Hab gerade mal das System unter cp/m selbst gebaut, die Argumentliste >> für SLR180 im Submit-File wird zu lang, ich habe den Assemblerlauf in 2 >> Teile aufteilen müssen, sonst klappt das aber. > > Wie wärs mit der I-Option? > | The I option is a special case option used for indirect > | command file input. If this option is used, it can be the only > | option specified. The /I option causes SLR180 to read the file > | <FILENAME>.SUB on the default drive (or the selected source drive) > | for its command lines. This is similar to using SUBMIT and XSUB > | except that 1) it is much faster, 2) it can be used from within > | a SUBMIT file, 3) it can be used without XSUB and SUBMIT leaving > | more RAM available for the assembly, and 4) it can be used while > | A: is not the default drive. ..lohnt doch nicht.
1 | H>type MKBCPM3.sub |
2 | ; generate CP/M 3 banked version |
3 | slr180 bioskrnl/M,boot/M,chario/M,msgbuf/M,conbuf/M,asciih/M,drvtbl/M,sdio/M |
4 | slr180 cfio/M,stampf/M,move/M,time/M,fifo/M,utils/M,mm/M,misc/M,scb/M |
5 | link80 bnkbios3[b]=bioskrnl,boot,chario,msgbuf,conbuf,asciih,drvtbl,sdio,cfio,s] |
6 | era bioskrnl.rel |
7 | era boot.rel |
8 | era chario.rel |
9 | era msgbuf.rel |
10 | era conbuf.rel |
11 | era asciih.rel |
12 | era drvtbl.rel |
13 | era sdio.rel |
14 | era cfio.rel |
15 | era stampf.rel |
16 | era move.rel |
17 | era time.rel |
18 | era fifo.rel |
19 | era utils.rel |
20 | era misc.rel |
21 | era mm.rel |
22 | era scb.rel |
23 | |
24 | gencpm AUTO |
25 | era bnkbios3.spr |
26 | |
27 | H> |
..der 2. Aufruf ist zeitmäßig nicht wirklich zu spüren, linken dauert länger. > > >> Hat Jemand ein funktionierendes Linux Binary des LD80 und könnte mir das >> mal zukommen lassen? > > Im Anhang. Danke. > >> aber der auf meinem System gebaute LD80 wirft ne core, ich würde >> mich später drum kümmern wollen > > Darf ich fragen von wo Du den Sourcecode hast? http://48k.ca/ld80.html ..das ist die 2. Version die ich zwischen den Fingern habe. Ich werde Deine Version mal testen. > Die originale Version 04b hatte bei mir die gleiche Krankheit. > Das habe ich gefixed und noch ein paar Kleinigkeiten geändert. Das hatte ich vor, aber ich spare mir die Arbeit gerne wenn das jemand Anderes schon getan hat. Allerdings ist es auch etwas krank 3 verschiedene Linker von 2 Betriebssystemen für ein und die selbe Sache zu verwenden... :-) > >> ...aber hätte zwischenzeitlich gerne ein MAP file des BIOS. > > Der ld80 wird ja wirklich nur für das Mapfile verwendet. Ich weiß. > Das bios an > sich wird mit dem Linker von DR (link80) generiert. Dieser produziert > ein Symbolfile namens 'bnkbios3.sym'. Vielleicht reicht Dir das. Wenn ich debuggen möchte wäre es schon hybsch zu wissen auf welchen Adressen die Symbole liegen. > >> Man müßte mal probieren ob man den Kram auch mit dem SRLink oder dem L80 >> zusammen bekommt... > > Mit dem L80 bestimmt nicht. Der link80 von DR wird benötigt, um das > spezielle spr-Format (System Page Relocatable) zu erzeugen. Der SRLink > kann das wahrscheinlich auch nicht. > > > Zu den anderen Sachen werde ich heute auch noch was schreiben. Das ist das Spannendste :-) Edit: hab mal einen LD80 aus Deinen Quellen gebaut:
1 | # gdb ld80 /home/holm/src/MICROS/avr-cpm/z180-stamp-cpm3/z180-stamp-cpm3/cbios/ld80.core |
2 | GNU gdb 6.1.1 [FreeBSD] |
3 | Copyright 2004 Free Software Foundation, Inc. |
4 | GDB is free software, covered by the GNU General Public License, and you are |
5 | welcome to change it and/or distribute copies of it under certain conditions. |
6 | Type "show copying" to see the conditions. |
7 | There is absolutely no warranty for GDB. Type "show warranty" for details. |
8 | This GDB was configured as "amd64-marcel-freebsd"...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/home/holm/src/MICROS/ld80-leo/ld80] |
9 | |
10 | Core was generated by `ld80 -o bnkbios3.map -ms bnkbios3.map -P 0 -D F000'. |
11 | Program terminated with signal 11, Segmentation fault. |
12 | Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. |
13 | done. |
14 | Loaded symbols for /lib/libc.so.7 |
15 | Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. |
16 | done. |
17 | Loaded symbols for /libexec/ld-elf.so.1 |
18 | #0 getopt (nargc=5, nargv=0x800e4a000, ostr=0x4049bc "-lD:P:C:") |
19 | at /usr/src/lib/libc/stdlib/getopt.c:70 |
20 | 70 if (optind >= nargc || *place++ != '-') {
|
21 | (gdb) where |
22 | #0 getopt (nargc=5, nargv=0x800e4a000, ostr=0x4049bc "-lD:P:C:") |
23 | at /usr/src/lib/libc/stdlib/getopt.c:70 |
24 | #1 0x0000000000401217 in ?? () |
25 | #2 0x0000000000000009 in ?? () |
26 | #3 0x0000000100000001 in ?? () |
27 | #4 0x0000000000000000 in ?? () |
28 | Current language: auto; currently minimal |
29 | (gdb) |
Wohl irgendwie inkompatibles getopt, ich komme nicht drum herum mir das anzugucken. Dein Binary machts anders hübsch: $ ld80 -o bnkbios3.o -ms bnkbios3.map -P 0 -D F000 bioskrnl.rel boot.rel chario.rel msgbuf.rel conbuf.rel asciih.rel drvtbl.rel sdio.rel cfio.rel stampf.rel move.rel time.rel fifo.rel utils.rel misc.rel mm.rel scb.rel ld80: Program too large $ Gruß, Holm
Holm T. schrieb: > Allerdings ist es auch etwas krank 3 verschiedene Linker von 2 > Betriebssystemen für ein und die selbe Sache zu verwenden... :-) Punkt für Dich. > Wenn ich debuggen möchte wäre es schon hybsch zu wissen auf welchen > Adressen die Symbole liegen. Ach, jetzt weiß ich wieder, warum das sym-File aus dem link80 (fast) nicht zu gebrauchen ist. Die entgültigen Adressen liegen da ja noch garnicht fest. Die Code- und Data-Segmentadresse aus dem fertigen cpm3.sys zu klauben, und damit den Linker nochmal laufen zu lassen, könnte aber auch mit link80 funktionieren. Moment... Es geht:
1 | $ zxcc link80 -testl=bioskrnl,boot,chario,msgbuf,conbuf,ascii,drvtbl,\ |
2 | sdio,cfio,stampf,move,time,fifo,utils,misc,mm,scb[DAD00,PF900,q,'$OZ'] |
3 | LINK 1.31 |
4 | |
5 | ?AUXI F915 ?AUXIS F936 ?AUXO F912 ?AUXOS F939 |
6 | ?BANK FBB6 ?BNKSL F951 ?BOOT F900 ?CI FB21 |
7 | ?CINIT FB18 ?CIST FB27 ?CO FB2D ?CONIN F909 |
8 | ?CONO F90C ?CONOS F933 ?CONST F906 ?COST FB33 |
9 | ?DEVIN F93F ?DRTBL F942 ?DVTBL F93C ?FLUSH F948 |
10 | ?HOME F918 ?INIT AE27 ?LDCCP FA65 ?LIST F90F |
11 | ?LISTS F92D ?MLTIO F945 ?MOV F94B ?MOVE FBAA |
12 | ?READ F927 ?RLCCP FA9D ?SCTRN F930 ?SLDSK F91B |
13 | ?STBNK F954 ?STDMA F924 ?STSEC F921 ?STTRK F91E |
14 | ?TIM F94E ?TIME FBFE ?WBOOT F903 ?WRITE F92A |
15 | ?XMOV F957 ?XMOVE FBA5 @ADRV ADF2 @AIVEC FE26 |
16 | @AOVEC FE28 @CBNK FA64 @CIVEC FE22 @CNT ADFB |
17 | @COVEC FE24 @CTBL FAFF @DBNK ADFA @DMA ADF8 |
18 | @DTBL FB43 @LOVEC FE2A @MXTPA FE62 @OP ADF1 |
19 | @RDRV ADF3 @SECT ADF6 @TRK ADF4 @XDPH ADEF |
20 | BOOT AD00 BS$STAC FDD7 HWINIT ADFC IJPHL FC4A |
21 | IOCTL FB1B STAMPF FB85 CPU_FRQ C578 F_CPU FAFB |
22 | GS_RTC C21A INTINIT C55A IOINI1L C39C MSGINIT AFAE |
23 | PR.CRLF C431 PR.DECL C466 PR.INLN C429 PRT0INI C276 |
24 | AS0_DEV B183 AS1_DEV B29C FF_DEV B133 _B0CALL FCF2 |
25 | BUFINIT C2B8 FIFOLST C2B0 HWL2PHY FCC1 MRX.FIF AF6E |
26 | MSG.REC B02D MSG.SM B0C8 MTX.FIF AF2A PHY2LOG FCE2 |
27 | CI.FIFO B0E5 CO.FIFO B109 FF_EMPT C2F4 FF_FULL C33B |
28 | FF_GET C2FE FF_PUT C349 ADD_HLA C3AC B_LD_A C5C5 |
29 | B_ST_A C5E3 DIV32_R C3B1 FF_GECH C317 FF_PUTH C364 |
30 | ISV_SW FD45 S0.INBU B18E S0.OUTB B212 S1.INBU B2A7 |
31 | S1.OUTB B32B CF0 BAAF CF1 BAD2 CF2 BAF5 |
32 | CF3 BB18 SD0 B707 SD1 B72A SD2 B74D |
33 | SD3 B770 SD4 B793 SD5 B7B6 SD6 B7D9 |
34 | SD7 B7FC BNK2PHY FCA3 PR.ERRO C504 PR.IDX C410 |
35 | ?PMSG C3FE GSTIMER C257 BNK2LOG FC93 @DATE FE58 |
36 | @HOUR FE5A @MIN FE5B @SEC FE5C DIV32_1 C3BB |
37 | GTIMER C261 I$STACK FD85 FF_CNT C382 @ERMDE FE4B |
38 | IOINIML C38D PHEX2 C43D PHEX4 C438 PR.DEC C45D |
39 | GET_TMR C5A7 B_LD_HL C5C9 B_ST_HL C5E8 MMUINIT FC8D |
40 | ?ERJMP FE5F @BFLGS FE57 @BNKBF FE35 @CRDMA FE3C |
41 | @CRDSK FE3E @ERDSK FE51 @FX FE43 @MEDIA FE54 |
42 | @MLTIO FE4A @RESEL FE41 @USRCD FE44 @VINFO FE3F |
43 | |
44 | ABSOLUTE 0000 |
45 | CODE SIZE 04D9 (F900-FDD8) |
46 | DATA SIZE 192F (AD00-C62E) |
47 | COMMON SIZE 0000 |
48 | USE FACTOR 2E |
Um das auch unter CP/M zu bauen brauchts dort nur noch dd und awk. ;-) Oder ein kleines Progrämmchen, das die Segmentadressen aus cpm3.sys ließt, und damit den Linker-Befehl zusammen baut. Das könnte ich morgen mal versuchen.
Interruptgesteuerte Serial-Treiber (ASCII) Holm T. schrieb: > Ich hab ein Bisschen in den asii Treibern herum gehackt um ein IXOFF auf > der ASCI1 hin zu kriegen. Respekt dafür, daß Du Dir den spärlich kommentierten Code antust. > Irgendwie geht das langsam und bei mir sind > temporär ein Haufen Ausrufezeichen (unter Wordstar!?) auf dem Bildschirm > zu sehen die verschwinden wenn Alles einkopiert ist, aber es war möglich > Joes scb.pas Programm mit Friß und Kotz aus dem Firefox nach Wordstar zu > transportieren und das Ding fehlerfrei mit Turbo 3.02A zu kompilieren. Wenn ich das richtig verstehe, funktioniert Deine XON/XOff-Erweiterung, aber die Übertragung ist ziemlich langsam. (Aber die Übertragung zu verlangsamen, ist ja auch der Sinn von Flußsteuerung.) Wenn ich mich richtig erinnere, bringt WS die ! auf den Bildschirm, wenn sein Inputbuffer überzulaufen droht, er also mit der Bearbeitung nicht nachkommt. Statt den zu aktualisieren, gibt er dann nur noch ! aus. Aber wenns funktioniert, ist ja erst mal gut. Mir persönlich gefallen die Polling-Schleifen für das TDRE-Bit nicht so gut, da dann Bedienung durch Interrupt und Polling gemischt sind. Könnte zu Race conditions führen. Und wenn nicht, in der Inputroutine (asci1_inp) ohne Interruptsperre pollen, ist das gleiche, als das XON ans Ende des Sedepuffers anzuhängen. TDRE wird an der Stelle ja erst dann 1, wenn die Interruptroutine alle Zeichen gesendet hat. Meiner Meinung nach müßten die XON/XOFF am Anfang des Sendepuffer eingefügt werden (umständlich bis schwierig, zumal der Sendepuffer ja auch voll sein kann), oder Kommuniktion von Sender und Empfänger-Routinen über Flags. Holm T. schrieb: > Ich habe mir indessen mal einen Überblick verschafft was Leo in den ASCI > Treibern so macht..whow, er hat ein termios ioctl Interface angefangen > zu implementieren. Angefangen schon 2015. Leider immer noch weit davon entfernt, fertig zu sein. Liegt sicher auch daran, daß es (für CP/M) etwas over-enginered ist. Heutzutage wird wahrscheinlich niemand mehr Programme für diese Schnittstelle schreiben. Aber ich wollte halt endlich mal ein hardwareunabhängiges Interface, über das man die Seriellen auch voll nutzen kann. In CP/M 2 gabs garnix, und in CP/M 3 kann man nur die Baudrate und Parity einstellen. Eigentlich gibts da auch noch XON/XOFF für die Output-Richtung. Aber die Implementierung ist völlig Banane. Und statt etwas völlig neues zu erfinden, habe ich mich umgeschaut, was es schon gibt... > Ich hatte mich gewundert warum keine Flußkontrolle > auf der Console funktioniert..ASCI1 kann ja nur xon/xoff ..aber das > gibts noch nicht. Es wird dich aber wahrscheinlich nicht wundern, daß es für die Einstellungen ein passendes stty.com gibt, mit dem dann auch Dein xon/xoff ein- und ausgeschaltet werden kann. Anhang nur als Binary, weil es natürlich auch noch nicht fertig ist, und der Sourcecode noch aufgeräumt werden muß.
Leo C. schrieb: > Interruptgesteuerte Serial-Treiber (ASCII) > > Holm T. schrieb: >> Ich hab ein Bisschen in den asii Treibern herum gehackt um ein IXOFF auf >> der ASCI1 hin zu kriegen. > > Respekt dafür, daß Du Dir den spärlich kommentierten Code antust. :-) Naja, ich habs wenigstens versucht, ging ja sonst nicht weiter und ich hab bisher nicht viel beigetragen.. > >> Irgendwie geht das langsam und bei mir sind >> temporär ein Haufen Ausrufezeichen (unter Wordstar!?) auf dem Bildschirm >> zu sehen die verschwinden wenn Alles einkopiert ist, aber es war möglich >> Joes scb.pas Programm mit Friß und Kotz aus dem Firefox nach Wordstar zu >> transportieren und das Ding fehlerfrei mit Turbo 3.02A zu kompilieren. > > Wenn ich das richtig verstehe, funktioniert Deine XON/XOff-Erweiterung, > aber die Übertragung ist ziemlich langsam. (Aber die Übertragung zu > verlangsamen, ist ja auch der Sinn von Flußsteuerung.) Wenn ich mich > richtig erinnere, bringt WS die ! auf den Bildschirm, wenn sein > Inputbuffer überzulaufen droht, er also mit der Bearbeitung nicht > nachkommt. Statt den zu aktualisieren, gibt er dann nur noch ! aus. Ja, so siehts aus. Das was Wordstar da wegfängt, ist syntaktisch korrekt und vereinfacht doch ziemlich den Transport von Quellen auf das System. WS aktualisiert den Bildschirm wenn es sich dann mal ausgekäst hat und das File sieht dann auch korrekt aus. Was Turbopascal nicht paßt weiß ich aber (noch?) nicht. Anzumerken ist freilich das Wordstar deutlich mehr tut, als zur blanken Datenübertragung notwendig wäre, PIP auszuprobieren wäre wohl mal angebracht... > > Aber wenns funktioniert, ist ja erst mal gut. > Mir persönlich gefallen die Polling-Schleifen für das TDRE-Bit nicht so > gut, da dann Bedienung durch Interrupt und Polling gemischt sind. Könnte > zu Race conditions führen. Das war mir bewußt, deswegen wollte ich eigentlich die Interrupts auch an der Stelle sperren, ging aber nicht, das hing endlos und warum habe ich noch nicht untersucht. Dazu müßte ich mir die Senderoutine genauer ansehen, wahrscheinlich blockiert da was, wenn ein Senderpuffer leer - Int kam und dann der Puffer doch nicht leer ist, weil ein XOFF eingefügt wurde. Andererseits hat die Übertragungsstrecke vom CP/M zu Host zu der Zeit eigentlich kaum Last. > Und wenn nicht, in der Inputroutine > (asci1_inp) ohne Interruptsperre pollen, ist das gleiche, als das XON > ans Ende des Sedepuffers anzuhängen. TDRE wird an der Stelle ja erst > dann 1, wenn die Interruptroutine alle Zeichen gesendet hat. TDRE sollte inaktiv werden wenn der Interne Puffer (4 Bytes?) leer ist, das hatte ich als die früheste Möglichkeit angesehen überhaupt Bescheid zu geben, das ich "die Nase voll" habe. Streng genommen müßte man einen indessen auftretenden Interrupt wieder entschärfen wenn man XOFF eingeschmuggelt hat. Ich stehe aber zugegebenermaßen nicht tief genug in der Materie.. evtl. solltest Du da mal sehen was Du machen kannst. Ggf. kann man TIE Rücksetzen wenn TDRE nicht gesetzt ist um die Auslösung des Ints zu verhindern, nach XOFF dann wieder einschalten? Eine Race Condition bleibts trotzdem.. > > Meiner Meinung nach müßten die XON/XOFF am Anfang des Sendepuffer > eingefügt werden (umständlich bis schwierig, zumal der Sendepuffer ja > auch voll sein kann), oder Kommuniktion von Sender und > Empfänger-Routinen über Flags. Das war der Sinn des Pollings, ich wollte eigentlich verhindern das der Sendepuffer in der ASCI vom Interrupt nachgefüllt wird, um frühest möglich das XOFF einzuschmuggeln, ohne den eigenen Senderpuffer im RAM umräumen zu müssen, was IMHO auch zu viel Performance fressen würde. > > Holm T. schrieb: >> Ich habe mir indessen mal einen Überblick verschafft was Leo in den ASCI >> Treibern so macht..whow, er hat ein termios ioctl Interface angefangen >> zu implementieren. > > Angefangen schon 2015. Leider immer noch weit davon entfernt, fertig zu > sein. Liegt sicher auch daran, daß es (für CP/M) etwas over-enginered > ist. Das war zugegebenermaßen auch einer meiner Gedanken.. > Heutzutage wird wahrscheinlich niemand mehr Programme für diese > Schnittstelle schreiben. Aber ich wollte halt endlich mal ein > hardwareunabhängiges Interface, über das man die Seriellen auch voll > nutzen kann. In CP/M 2 gabs garnix, und in CP/M 3 kann man nur die > Baudrate und Parity einstellen. Eigentlich gibts da auch noch XON/XOFF > für die Output-Richtung. Aber die Implementierung ist völlig Banane. > Und statt etwas völlig neues zu erfinden, habe ich mich umgeschaut, was > es schon gibt... Das ist sicher nicht der falsche Weg, allerdings erzeugt er halt ordentlich CPU Last. > >> Ich hatte mich gewundert warum keine Flußkontrolle >> auf der Console funktioniert..ASCI1 kann ja nur xon/xoff ..aber das >> gibts noch nicht. > > Es wird dich aber wahrscheinlich nicht wundern, daß es für die > Einstellungen ein passendes stty.com gibt, mit dem dann auch Dein > xon/xoff ein- und ausgeschaltet werden kann. Anhang nur als Binary, weil > es natürlich auch noch nicht fertig ist, und der Sourcecode noch > aufgeräumt werden muß. Na mal sehen was das so macht.. vllt. heute Abend. Momentan stochere ich in Headern für den arm-none-eabi-gcc herum.. Gruß, Holm
..hab PIP ausprobiert, geht deutlich schneller (so wie man sich das vorstellt) allerdings klaut mir das die Linefeeds aus dem Datenstrom und ich habe trotz [O] und [Qendestring] noch keine Möglichkeit gefunden das zu verhindern... Muß erst mal weiter arbeiten.. BTW: die 10 Rückverdrahtungsplatinen aus China sind heute gekommen, Donnerstag bestellt, Montag hier für 20 Euro..verrückte Welt.. Es sind allerdings keine mehr übrig. Gruß, Holm
Holm T. schrieb: > Fpga K. schrieb >>> der von mir als Beispiel genannte alt CPLD EPM7160 (MAX7000) hat 160 >>> Makrozellen an 64 User I/O Pins und 3200 Gates. >>> Probiere das mal mit der Synthese. >> >> 160 MC sind 160FF, das sieht nicht hoffnungslos aus(wie gesagt 90 im >> letzten report) Hab mir grad die passende Software aus dem >> Downloadkeller geholt (Quartus Web 13.0sp1) und schau mal was in der >> anstehenden Urlaubswoche in der Oberlausitz wird. > > Ich habe wohl auch noch kleinere (7128,7064). > Habs jetzt für den 160 angepasst und durchgefittet. Das passt zwar mit 141 Macrocells ins Device und ist mit 80 MHz ausreichend schnell, dafür drückt der Schuh beim freiwählbaren Umschalten der Portrichtung. Der CPLD gestattet lediglich 6 unabhängige Output enable signale, so dass es im Einzelbitbetrieb nicht möglich ist, für jede Portleitung die Richtung durch die SW zu ändern. Bytemodus kein Problem, ebenso kein Problem bei Einzelbit mit "festverdrahteter" Richtung. (wie beispielsweise beim Z1013 mit seinem festverdrahteten Port B.) MfG,
Die Init-Misere (INIDONE) Joe G. schrieb: > @Holm > Super analysiert! Dem schließe ich mich gerne an. Holm T. schrieb: > Leo Du hast offensichtlich mit einem ROM Boot der Z180 experimentiert, Nur dieser Schluß stimmt nicht ganz. Ich habe das fallweise Überspringen der Initialisierung eingebaut, damit ich den Bootvorgang und das Bios mit dem DDTZ aus dem AVR-Flash debuggen kann. Wenn das Bios alle Schnittstellen neu initialisiert, hängt es mir den Debugger ab. Die Implementierung ging aber offensichtlich daneben. Anfangs war es nicht ganz so schlimm, da das ganze Byte auf der Adresse 3Fh auf 80h geprüft wurde. Im Changlog vom Juni 2016 findet sich dieser Eintrag:
1 | BIOS debugging with ddtz: Set 3F to 81 to en fifo inits. |
Und seit dem wird in der ASCI Initialisierung nur noch das Bit 7 getestet. > So wie Du das machst kann ja da nur 080h oder 0 drin stehen, was bei > einem leeren Speicher mit 0ffh oder auch zufälligem Inhalt eine hohe > Chance ergibt, das die Initialisierung weg fällt und man wie ich mit > obskuren Taktfrequenzen und Baudraten kämpft. Tut mir leid. Vielleicht habe ich die Größe des Problems nicht bemerkt, weil ich den Speicher vor dem Start oft komplett mit 00 oder 76h fülle. Andererseits hatte ich selbst schon das Problem und dann immer eine Weile gebraucht, um dahinter zu kommen. Leider bin ich nicht auf die Idee gekommen, das es anderen genau so gehen könnte. Ok, ich werde die Stelle so umbauen, daß die Initialisierung nur noch dann ausgelassen wird, wenn man das wirklich braucht. > Andererseits scheint auch > das ldrbios.180 nach erfolgreicher Initialisierung das Flag in INIDONE > nicht zu setzen... Vielleicht sollte das Flag besser DONTINIT heißen. Für das ldrbios hatte ich keinen Debugger gebraucht. Das, und der zugehörige cpmldr wird ja eh nur gebraucht, wenn man von CF-Karte booten möchte. > das ist wohl ne angefangene Baustelle (wie der Name > -dirthy auch suggeriert). Das -dirty kommt von der Versionsverwaltung [1]. Es bedeutet, daß die Version, die gerade gebaut wird, nicht im VCS eingecheckt ist. > Ich schlage vor nicht 7 Bit einsparen zu wollen und ein Flag wie 55h, > 0aah, oder 5ah, 0a5h zu setzen, das macht eine Fehlfunktion etwas > unwahrscheinlicher.... s.o. > andererseits ist das in boot.180 eher fehl am > Platz, da das Label boot: ein Kaltstart Entry sein sollte und ein > Kaltstart davon ausgehen sollte das initialisiert werden muß. Aber nicht, wenn man debuggen will... > Hab ich dabei was übersehen? Was wolltest Du einsparen? Ich wollte wohl mehrere Varianten der Initialisierungsauslassung mit Flags in einem Byte realsieren. [1] genauer: Autorevision: https://autorevision.github.io/
Holm T. schrieb: > BTW: die 10 Rückverdrahtungsplatinen aus China sind heute gekommen, > Donnerstag bestellt, Montag hier für 20 Euro..verrückte Welt.. > Es sind allerdings keine mehr übrig. Aber wirklich. Hier kostet ja allein der Versand schon fast so viel. Und schade, ich hatte mich inzwischen dazu durchgerungen, auch eine haben zu wollen.
Fpga K. schrieb: > Holm T. schrieb: >> Fpga K. schrieb >>>> der von mir als Beispiel genannte alt CPLD EPM7160 (MAX7000) hat 160 >>>> Makrozellen an 64 User I/O Pins und 3200 Gates. >>>> Probiere das mal mit der Synthese. >>> >>> 160 MC sind 160FF, das sieht nicht hoffnungslos aus(wie gesagt 90 im >>> letzten report) Hab mir grad die passende Software aus dem >>> Downloadkeller geholt (Quartus Web 13.0sp1) und schau mal was in der >>> anstehenden Urlaubswoche in der Oberlausitz wird. >> >> Ich habe wohl auch noch kleinere (7128,7064). >> > > Habs jetzt für den 160 angepasst und durchgefittet. Das passt zwar mit > 141 Macrocells ins Device und ist mit 80 MHz ausreichend schnell, dafür > drückt der Schuh beim freiwählbaren Umschalten der Portrichtung. Der > CPLD gestattet lediglich 6 unabhängige Output enable signale, so dass es > im Einzelbitbetrieb nicht möglich ist, für jede Portleitung die Richtung > durch die SW zu ändern. Bytemodus kein Problem, ebenso kein Problem bei > Einzelbit mit "festverdrahteter" Richtung. (wie beispielsweise beim > Z1013 mit seinem festverdrahteten Port B.) > MfG, Hmm..Volker das ist zwar irgendwie traurig, aber dann wohl nicht zu ändern, dann gibts eben eine PIO mit im Bitbetrieb 2 festen Eingangsbits, immer noch deutlich besser als gar keine Schnittstelle oder aus TTL Logik bestehend. Wie sieht das denn bei den von Dir gewöhnten Xilinx Chips aus? Hast Du Lust spaßeshalber mal zu checken ob die 8255 auch paßt? http://www.cpcwiki.eu/index.php/VHDL_implementation_of_the_8255_PIO Ich denke aber die Restriktion wird auch dort zuschlagen und das Ding hat noch mehr Portbeine. Gruß, Holm
Leo C. schrieb: > Die Init-Misere (INIDONE) > > Joe G. schrieb: >> @Holm >> Super analysiert! > > Dem schließe ich mich gerne an. > > Holm T. schrieb: >> Leo Du hast offensichtlich mit einem ROM Boot der Z180 experimentiert, > > Nur dieser Schluß stimmt nicht ganz. > Ich habe das fallweise Überspringen der Initialisierung eingebaut, damit > ich den Bootvorgang und das Bios mit dem DDTZ aus dem AVR-Flash debuggen > kann. Wenn das Bios alle Schnittstellen neu initialisiert, hängt es mir > den Debugger ab. Ok, das ist freilich auch ein Grund. > Die Implementierung ging aber offensichtlich daneben. Anfangs war es > nicht ganz so schlimm, da das ganze Byte auf der Adresse 3Fh auf 80h > geprüft wurde. Im Changlog vom Juni 2016 findet sich dieser Eintrag: >
1 | > BIOS debugging with ddtz: Set 3F to 81 to en fifo inits. |
2 | > |
..das habe ich gelesen, konnte das aber nicht deuten, speziell wegen der "1" der "81" und den ands die ich so gefunden hatte. > Und seit dem wird in der ASCI Initialisierung nur noch das Bit 7 > getestet. > >> So wie Du das machst kann ja da nur 080h oder 0 drin stehen, was bei >> einem leeren Speicher mit 0ffh oder auch zufälligem Inhalt eine hohe >> Chance ergibt, das die Initialisierung weg fällt und man wie ich mit >> obskuren Taktfrequenzen und Baudraten kämpft. > > Tut mir leid. Kein Grund zur Aufregung, Du hast shließlich den ganzen Senf geschrieben, da darf doch auch mal was daneben gehen. Ich hatte allerdings zugegebenermaßen langsam an mir gezweifelt, ich habe ja verschiedene Prozessoren, Z18010, dann diesen ominösen SL1960 und dann die späteren Z8S180 und irgendwie ging immer mal was, aber manchmal mit 3,88 Mhz CPU Takt..den ich mir nun gar nicht erklären konnte...deswegen hab ich nachgeguckt. > Vielleicht habe ich die Größe des Problems nicht bemerkt, > weil ich den Speicher vor dem Start oft komplett mit 00 oder 76h fülle. Das hab ich natürlich eher nicht gemacht. Das erinnert mich an ein gekipptes Bit in einem Eprom wodurch die Speicherinitialisierung eines alten Homemade-Computers (vor der Wende, aufgebohrter MC80) den Speicher mit 00 und nicht mit ff initialiserte. Ich habe mich mehrere Wochen gewundert wieso der Basic Interpreter beim Start abstürzte.. Ich habe den Eprom noch richtig ausgelesen nach dem die Ksite Jahrzehnte lang stand, im Disassembler war Alles korrekt.. > Andererseits hatte ich selbst schon das Problem und dann immer eine > Weile gebraucht, um dahinter zu kommen. Leider bin ich nicht auf die > Idee gekommen, das es anderen genau so gehen könnte. > Ok, ich werde die Stelle so umbauen, daß die Initialisierung nur noch > dann ausgelassen wird, wenn man das wirklich braucht. > >> Andererseits scheint auch >> das ldrbios.180 nach erfolgreicher Initialisierung das Flag in INIDONE >> nicht zu setzen... > > Vielleicht sollte das Flag besser DONTINIT heißen. > Für das ldrbios hatte ich keinen Debugger gebraucht. Das, und der > zugehörige cpmldr wird ja eh nur gebraucht, wenn man von CF-Karte booten > möchte. ...das ist im Endffekt gehuppt wie gesprungen... > >> das ist wohl ne angefangene Baustelle (wie der Name >> -dirthy auch suggeriert). > > Das -dirty kommt von der Versionsverwaltung [1]. Es bedeutet, daß die > Version, die gerade gebaut wird, nicht im VCS eingecheckt ist. > >> Ich schlage vor nicht 7 Bit einsparen zu wollen und ein Flag wie 55h, >> 0aah, oder 5ah, 0a5h zu setzen, das macht eine Fehlfunktion etwas >> unwahrscheinlicher.... > > s.o. > >> andererseits ist das in boot.180 eher fehl am >> Platz, da das Label boot: ein Kaltstart Entry sein sollte und ein >> Kaltstart davon ausgehen sollte das initialisiert werden muß. > > Aber nicht, wenn man debuggen will... > >> Hab ich dabei was übersehen? Was wolltest Du einsparen? > > Ich wollte wohl mehrere Varianten der Initialisierungsauslassung mit > Flags in einem Byte realsieren. > > > [1] genauer: Autorevision: https://autorevision.github.io/ Ok...mach nur wie Du denkst, bis jetzt wars hübsch.. :-) Gruß, Holm
Hallo, Durch das Backplane bin ich auch aus dieses Projekt gestossen: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:z180_mark_iv:z180_mark_iv Hat irgendjemand Interesse an Leiterplatten? Ich würde 5 Stück bestellen (kosten zusammen ca 40EUR, 4-fach Multilayer) Viele Grüße Günther
Falls Du Dich noch umentscheidest, so Eins würde ich nehmen: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:cpu280:start Gruß, Holm
Ich denke mal drüber nach, die Software die Tilmann damals entwickelt, war schon ziemlich gut, allein dafür lohnt sich der Aufbau, automatische Diskettenformaterkennung usw. Allerdings waren die ersten CPUs fehlerhaft und es sind ZIP RAM Bausteine und GALs drauf. Vielleicht mache ich auch mal eine neue Z180 Platine, aber das wird noch dauern.
Günther S. schrieb: > Ich denke mal drüber nach, die Software die Tilmann damals entwickelt, > war schon ziemlich gut, allein dafür lohnt sich der Aufbau, automatische > Diskettenformaterkennung usw. Allerdings waren die ersten CPUs > fehlerhaft und es sind ZIP RAM Bausteine und GALs drauf. Vielleicht > mache ich auch mal eine neue Z180 Platine, aber das wird noch dauern. Die Gals brenne ich Dir ..aber ob ich ausreichend RAMs für Dich und für mich habe, weiß ich nicht. Da sind noch andere Eier drauf, der FDC ist wohl ziemlich kitzlig. Ob die CPU Fehler hat? Sagen wir mal so, es ist zumindest kein undurchsichtiges Management Interface mit möchtegern-USB zu Spionagezwecken drin... Ich habe noch 2 Z28010 da liegen. Gruß, Holm
Zur BIOS Symbol-Tabelle Leo C. schrieb: > Die Code- und Data-Segmentadresse aus dem fertigen cpm3.sys zu klauben, > und damit den Linker nochmal laufen zu lassen, könnte aber auch mit > link80 funktionieren. Moment... Wenn man die Segment-Basisadressen aus cpm3.sys lesen kann/soll/muss, dann kann man auch das SYM-File, das der DR Linker schon erzeugt hat, gleich auch noch lesen, und die Segmente selbst addieren. Im Anhang ist das Programm dafür, als CP/M (HI-TECH C) und Linux (GCC) Binary. Source kommt noch. Ohne Argumente nimmt es die CP/M Dateinamen: BNKBIOS3.SYM und CPM3.SYS für Input, und BNKBIOS3.ASY für Output. Wie üblich, -h für Hilfe. Die Methode ist nicht ganz zuverlässig, da absolute Symbole, die zufällig im PSEG oder DSEG liegen, auch convertiert werden. Kommt z.Zt. aber nicht vor.
Danke LEO..ich werds mal testen, der ARM-Scheiß funktioniert endlich. Hast Du die Xon/Xoff Geschichte mal ausprobiert? Gruß, Holm
Dein Linux Binary läuft unter meinem FreeBSD: F915 ?AUXI F936 ?AUXIS F912 ?AUXO F939 ?AUXOS FBB6 ?BANK F951 ?BNKSL F900 ?BOOT FB21 ?CI FB18 ?CINIT FB27 ?CIST FB2D ?CO F909 ?CONIN F90C ?CONO F933 ?CONOS F906 ?CONST FB33 ?COST F93F ?DEVIN F942 ?DRTBL F93C ?DVTBL F948 ?FLUSH F918 ?HOME AE2E ?INIT FA65 ?LDCCP F90F ?LIST F92D ?LISTS F945 ?MLTIO F94B ?MOV FBAA ?MOVE F927 ?READ FA9D ?RLCCP F930 ?SCTRN F91B ?SLDSK F954 ?STBNK F924 ?STDMA F921 ?STSEC F91E ?STTRK F94E ?TIM FBFE ?TIME F903 ?WBOOT F92A ?WRITE F957 ?XMOV FBA5 ?XMOVE ADFB @ADRV FE26 @AIVEC FE28 @AOVEC FA64 @CBNK FE22 @CIVEC AE04 @CNT FE24 @COVEC FAFF @CTBL AE03 @DBNK AE01 @DMA FB43 @DTBL FE2A @LOVEC FE62 @MXTPA ADFA @OP ADFC @RDRV ADFF @SECT ADFD @TRK ADF8 @XDPH AD00 BOOT FDD7 BS$STAC AE05 HWINIT FC4A IJPHL FB1B IOCTL FB85 STAMPF C5A2 CPU_FRQ FAFB F_CPU C244 GS_RTC C584 INTINIT C3C6 IOINI1L AFB7 MSGINIT C45B PR.CRLF C490 PR.DECL C453 PR.INLN C2A0 PRT0INI B18C AS0_DEV B2A5 AS1_DEV B13C FF_DEV FCF2 _B0CALL C2E2 BUFINIT C2DA FIFOLST FCC1 HWL2PHY AF77 MRX.FIF B036 MSG.REC B0D1 MSG.SM AF33 MTX.FIF FCE2 PHY2LOG B0EE CI.FIFO B112 CO.FIFO C31E FF_EMPT C365 FF_FULL C328 FF_GET C373 FF_PUT C3D6 ADD_HLA C5EF B_LD_A C60D B_ST_A C3DB DIV32_R C341 FF_GECH C38E FF_PUTH FD45 ISV_SW B197 S0.INBU B21B S0.OUTB B2B0 S1.INBU B334 S1.OUTB BAD9 CF0 BAFC CF1 BB1F CF2 BB42 CF3 B731 SD0 B754 SD1 B777 SD2 B79A SD3 B7BD SD4 B7E0 SD5 B803 SD6 B826 SD7 FCA3 BNK2PHY C52E PR.ERRO C43A PR.IDX C428 ?PMSG C281 GSTIMER FC93 BNK2LOG FE58 @DATE FE5A @HOUR FE5B @MIN FE5C @SEC C3E5 DIV32_1 C28B GTIMER FD85 I$STACK C3AC FF_CNT FE4B @ERMDE C3B7 IOINIML C467 PHEX2 C462 PHEX4 C487 PR.DEC C5D1 GET_TMR C5F3 B_LD_HL C612 B_ST_HL FC8D MMUINIT FE5F ?ERJMP FE57 @BFLGS FE35 @BNKBF FE3C @CRDMA FE3E @CRDSK FE51 @ERDSK FE43 @FX FE54 @MEDIA FE4A @MLTIO FE41 @RESEL FE44 @USRCD FE3F @VINFO Gruß, Holm
Holm T. schrieb: > Dein Linux Binary läuft unter meinem FreeBSD: Gut, allerdings habe ich nochmal etwas nachgebessert. Die Linuxversion produziert jetzt auch CP/M Zeilenenden (CRLF), und hängt den EOF-Marker an. Ohne das sah die Symboltabelle im CP/M komisch aus, und der Debugger konnte sie nicht laden. In dem Zip sind der Quellcode und die beiden Binaries.
Holm T. schrieb: > Hast Du die Xon/Xoff Geschichte mal ausprobiert? Hab's jetzt mal ins Repo integriert. Das IXOFF-Flag habe ich von iflags (wo es ja eigentlich hingehört) nach fflags verschoben. Dort liegt das Flag, weil die Flag-Speicher bei mir nur jeweils ein Byte groß sind (eh nur 3) und iflags schon voll war. Jetzt klappt auch das Ein- und Ausschalten mit stty. Richtig getestet habe ich aber noch nicht, und das werde ich leider diese und die nächste Woche auch nicht schaffen.
Holm T. schrieb: > Fpga K. schrieb: >> Der >> CPLD gestattet lediglich 6 unabhängige Output enable signale, so dass es >> im Einzelbitbetrieb nicht möglich ist, für jede Portleitung die Richtung >> durch die SW zu ändern. Bytemodus kein Problem, ebenso kein Problem bei >> Einzelbit mit "festverdrahteter" Richtung. (wie beispielsweise beim >> Z1013 mit seinem festverdrahteten Port B.) >> MfG, > > > Hmm.. das ist zwar irgendwie traurig, aber dann wohl nicht zu > ändern, > dann gibts eben eine PIO mit im Bitbetrieb 2 festen Eingangsbits, immer > noch deutlich besser als gar keine Schnittstelle oder aus TTL Logik > bestehend. Denke ich auch, und so häufig sollte man die Richtung auch nicht ändern, notfalls muss halt der CPLD neu programmiert werden. > Wie sieht das denn bei den von Dir gewöhnten Xilinx Chips > aus? Lt. Datenblatt f. XC9500 etwas schlechter: " There are 2 global output enables for devices with up to 144 macrocells, and 4 global output enables for the rest of the devices." Dagegen solltes es bei den FPGA's (Spartan2,3,...) kein Problem sein, jedes Pin individuell zu schalten. Allerdings können FPGA's eher keine 5V ohne Levelshifter/Schutzmassnahmen ab. > Hast Du Lust spaßeshalber mal zu checken ob die 8255 auch paßt? > > http://www.cpcwiki.eu/index.php/VHDL_implementation_of_the_8255_PIO Erst mal nicht, hab jetzt erstmal die PIO so zerlegt, das es a) einfacher sein sollte Fehlendes zu ergänzen und b) teile für CTC und SIO abzuleiten. Falls das Projekt genügend "Eigenleben" entwickelt werde ich es als eigenes Projekt aus diesem Thread abspalten. In 1500 Posts zu navigieren ist am Smartphone nicht so einfach. PS: Wahrscheinlich bin ich am kommenden Wochenende beim "Computer Vintage Festival" in München dabei. Vielleicht trifft man ja jemanden mit ähnlichen themen... MfG,
Angehängte Dateien:
-
xoff-1-1.png
51 KB -
xoff-1-2.png
43 KB -
xoff-2-0.png
100 KB
Holm T. schrieb: > Hast Du die Xon/Xoff Geschichte mal ausprobiert? Jetzt aber. Meiner Meinung nach funktioniert Dein XON/XOFF korrekt, bis auf einen Schönheitsfehler. Gelegentlich wurden 2 oder 3 XOFF hintereinander gesendet. Beim Test mit WS war es immer nur das erste XOFF, das verdreifacht wurde (Bild 1). Etwas besser wurde es, nachdem ich den Test, ob XOFF gesendet werden soll, von "> 75% Buffer voll" auf == umgestellt hatte. Trotzdem habe ich das direkte Senden von XON und XOFF in den Inputroutinen auf Setzen von Flags umgestellt, die dann in der Sende-Interruptroutine abgearbeitet werden. Das ist imho sauberer, und XON wird auch dann sofort gesendet, wenn im Sendepuffer noch Zeichen sind. Der aktuelle Stand ist auf meinem Server im Branch "asci-int-driver" zu finden. Holm T. schrieb: > Irgendwie geht das langsam und bei mir sind > temporär ein Haufen Ausrufezeichen (unter Wordstar!?) auf dem Bildschirm > zu sehen die verschwinden wenn Alles einkopiert ist, aber es war möglich > Joes scb.pas Programm mit Friß und Kotz aus dem Firefox nach Wordstar zu > transportieren und das Ding fehlerfrei mit Turbo 3.02A zu kompilieren. Man kann also sagen, daß WS für Dateitransfer reichlich ungeeignet ist. Dafür ist er aber für die Eingabe durch einen Menschen sehr gut optimiert (besser als der Turbo-Editor), und wenn er mal nicht hinterher kommt, nervt er den Tipper durch die !!! und Gepiepse (Bild 2, nach jedem ! kommt auch noch ein <BEL>). Der Piepser ist bei mir abgeschaltet, deswegen habe ich das auch erst in der Aufzeichnung gesehen. In Bild 3 sieht man die Übertragung einer 260 Byte kurzen Datei mit 115200 Baud. Die Übertragung würde ohne XOFF ca. 23ms dauern. An WS wird sie in 3 kurzen Blöcken, mit dazwischen liegenden langen XOFF-Pausen, in denen WS hauptsächlich mit ! und Piepsen beschäftigt ist, gesendet. Das dauert insgesammt ca. 2,8 Sekunden. WS braucht danach nochmal ca. 2,6s, unter Rufen und Piepsen den Empfangsbuffer zu leeren, den Bildschirm aufzuräumen und die Statuszeile zu aktualisieren. Man kann das langsam finden, aber ich z.B. würde es nicht schaffen, 260 Zeichen in 3-5 Sekunden einzutippen. :-) > Ich kann das auch direkt nach Turbo in den Editor fallen lassen > syntaktisch ist das Programm einwandfrei und läßt sich kompilieren, aber > wahrscheinlich auf Grund der Terminalemulation sind da die Zeilen > treppenförmig seitlich versetzt. Das liegt wohl an der Autoindent-Funktion des TP-Editors. Ganz schlimm war es bei mir, wenn Autointent aktiv, und in der Datei auch noch Tabs enthalten waren. TP hat zwar nicht die lästige !-Pieps-Warnmimik, aber die Bildschirmausgeabe ist nicht so optimiert, wie bei WS. Im LA war zu sehen, daß TP vor jedem einzelnen Zeichen den Cursor zwei mal positioniert, und nach dem Zeichen die Zeile bis zum Ende löscht.
Danke Leo das Du wiedermal Zeit investiert hast. Ich hatte schon am Repository gemerkt das sich was verändert hatte :-) Sicher funktioniert Deine Flag-Geschichte mit Behandlung in der ISR besser, Du kennst ja den Code besser und ich hatte da schon meine Sorgen mich rein zu denken. Zu WS/TP..ja sicher..das sind aber eigentlich nur Notlösungen. PIP sollte auch von der Console auf ein File kopieren können, seltsamer Weise läßt das aber bei mir Linefeeds verschwinden so das die Textdatei dann eine einzige lange Zeile mit Carriage-Return drin ist, das Kopieren selbst ist freilich deutlich schneller. (Ein Filter sollte das beheben können, aber wo kommt das her?) Ich habe aber nicht näher untersucht woran das liegt oder ob der von mir verwendete Terminal-Emulator (seyon) Schuld ist, IMHO ging es aber mit miniterm auch nicht anders. Ich brauche noch ein paar Tage ehe ich mich da wieder ran setzen kann.. >TP hat zwar nicht die lästige !-Pieps-Warnmimik, aber die >Bildschirmausgeabe ist nicht so optimiert, wie bei WS. Im LA war zu >sehen, daß TP vor jedem einzelnen Zeichen den Cursor zwei mal >positioniert, und nach dem Zeichen die Zeile bis zum Ende löscht. ..na toll...war wohl die Billigvariante um einen konsistenten Bildschirminhalt anzuzeigen.... Evtl. sollte man das mal (auch bei WS) mit verschiedenen Terminalemulationen ausprobieren, evtl. ist die gerade verwendete hinsichtlich der Sequenzen etwas "vergriesgnaddelt"... Gruß, Holm
> PIP > sollte auch von der Console auf ein File kopieren können, seltsamer > Weise läßt das aber bei mir Linefeeds verschwinden so das die Textdatei > dann eine einzige lange Zeile mit Carriage-Return drin ist, das Kopieren > selbst ist freilich deutlich schneller. Kann ich hier nicht nachvollziehen. Ich habe gerade 3 Versionen einer Datei mit verschiedenen Zeilenenden mit PIP kopiert: 1. CR Diese Variante habe ich auch für die WS- und TP-Tests genommen. 2. CRLF 3. LF Alle 3 hat pip unverändert gespeichert. Wenn man sich die Dateien mit TYPE anschaut, sieht nur Nr. 2 gut aus (Überraschung). Bei Nr. 1 werden alle Zeilen überenander gedruckt (ach), und Nr. 3 sieht komisch aus.
1 | E>type pip2.txt |
2 | public @dtbl |
3 | extrn sd0,sd1,sd2,sd3 |
4 | extrn sd4,sd5,sd6,sd7 |
5 | extrn cf0,cf1,cf2,cf3 |
6 | |
7 | cseg |
8 | |
9 | @dtbl dw sd0,sd1,sd2,sd3 ; drives A-D |
10 | dw sd4,sd5,sd6,sd7 ; drives E-H |
11 | dw cf0,cf1,cf2,cf3 ; drives I-L |
12 | dw 0,0,0,0 ; drives M-P |
13 | |
14 | end |
1 | E>type pip3.txt |
2 | public @dtbl |
3 | extrn sd0,sd1,sd2,sd3 |
4 | extrn sd4,sd5,sd6,sd7 |
5 | extrn cf0,cf1,cf2,cf3 |
6 | |
7 | cseg |
8 | |
9 | @dtbl dw sd0,sd1,sd2,sd3 ; drives A-D |
10 | dw sd4,sd5,sd6,sd7 ; drives E-H |
11 | dw cf0,cf1,cf2,cf3 ; drives I-L |
12 | dw 0,0,0,0 ; drives M-P |
13 | |
14 | end |
Ja schon möglich Leo, ich schrieb ja das ich es nicht für unwahrscheinlich halte das seyon das versaut, das CR/LF Handling ist da unvollständig implementiert. Ich werde mir die uralte Software wohl mal auf den Tisch ziehen müssen, außer mir ändert dort wohl Niemand mehr was. Ein "richtig gutes" Terminalprogramm als Alternative ist mir aber auch nicht bekannt, schon gar nicht eins, das auch noch ADM3A unterstützen würde..und das könnte ich gut gebrauchen (wegen P8000 WEGA und CP/M) Cutecom ist hybsch für Debugging, aber sonst nicht zu gebrauchen..Minicom..naja.. Ich werde hier mit PIP noch mal testen, einen LA kann ich auch dran hängen. Gruß, Holm
Holm T. schrieb: > Ein "richtig gutes" Terminalprogramm als Alternative ist > mir aber auch nicht bekannt, schon gar nicht eins, > das auch noch ADM3A unterstützen würde.. Gibt es ein gutes Dokument, wo die ADM3A-Sequenzen aufgelistet sind? Ich hatte mal gesucht, aber nichts Gutes gefunden. VT52 und VT100 findet man zuhauf...
S. R. schrieb: > Holm T. schrieb: >> Ein "richtig gutes" Terminalprogramm als Alternative ist >> mir aber auch nicht bekannt, schon gar nicht eins, >> das auch noch ADM3A unterstützen würde.. > > Gibt es ein gutes Dokument, wo die ADM3A-Sequenzen aufgelistet sind? Ich > hatte mal gesucht, aber nichts Gutes gefunden. VT52 und VT100 findet man > zuhauf... Naja, die Termcap oder Terminfo Dateien gängiger Unix Systeme sollten da ausreichend Daten enthalten eine halbwegs brauchbare Emulation auf die Beine stellen zu können... Ansonsten ist das sicher auch aufzutreiben (Bitsavers?).. edit: Uups..ich bin spät dran... Gruß, Holm
Der Serial-Treiber kann jetzt auch für die Senderichtung XON/XOFF Flußsteuerung. Könnte für Peripheriegräte (Drucker, Stanze, ...) nützlich sein. Theoretisch auch für die Konsole. Man könnte längere Bildschirmausgaben mit CTRL-S (XOFF) anhalten, und mit CTRL-Q weiterlaufen lassen. Praktisch ist das kaum nutzbar, da man die Steuercodes für Wordstar und Konsorten und für die CCP Befehlszeile haben möchte.
Aha, dann habe ich ja einen Tester. Meine eigenen Tests waren bisher recht oberflächlich. Interessant wirds, wenn XON/XOFF für beide Richtungen gleichzeitig aktiv ist, und auch Daten in beide Richtungen gleichzeitig fließen.
..naja, das werden wir nur theoretisch brauchen, es schadet aber wohl nix wenn der Treiber ordentlich funktioniert. Interessanter wird das wohl bei Datentransfer über die andere Schnitte, mit Kermit o.Ä. z.B. da müßte an mal explizit XON/XOFF testen mit 7 Bit.. Gruß, Holm
Hallo zusammen, falls jemand noch Lust zum Löten hat - ich bin leider nie dazu gekommen und bei mir stauben ein paar wunderhübsche, praktisch neue Platinen vom Z180-Stamp Modul ein, von denen ich mich nun einfach trennen möchte. Wenn jemand Interesse hat, schau ich mal nach, welche es sind und ob ich damals schon ein paar passende Teile dazu gekauft habe (ist schon zu lange her). Die kämen dann auch dazu - für's Porto und gern noch was obendrauf - muss aber kein Vermögen sein. Bitte melden, dann kommen weitere Infos. Viel Spaß weiterhin. Gruß, W.
Wolfram K. schrieb: > Hallo zusammen, > > falls jemand noch Lust zum Löten hat - ich bin leider nie dazu gekommen > und bei mir stauben ein paar wunderhübsche, praktisch neue Platinen vom > Z180-Stamp Modul ein, von denen ich mich nun einfach trennen möchte. > > Wenn jemand Interesse hat, schau ich mal nach, welche es sind und ob ich > damals schon ein paar passende Teile dazu gekauft habe (ist schon zu > lange her). Die kämen dann auch dazu - für's Porto und gern noch was > obendrauf - muss aber kein Vermögen sein. Bitte melden, dann kommen > weitere Infos. > > Viel Spaß weiterhin. > Gruß, W. Jo mach mal bitte, ich habe zumindest Einen, wenn nicht gar zwei Interessenten.. Joe G. wollte eigentlich die Gerber Files hochladen damit ich Platinen anfertigen lassen kann, hat er aber wohl vergessen. Gruß, Holm
Angehängte Dateien:
-
P1220241.JPG
170 KB -
P1220242.JPG
170 KB -
P1220243.JPG
170 KB -
P1220244.JPG
170 KB
Hallo Holm, bin inzwischen fündig geworden. Anscheinend habe ich doch schon mit Löten angefangen, aber keinen Tests gemacht und auch nicht fertig geworden (s. Fotos). Dazu habe ich noch (nicht verbaut) den PLCC-Sockel, einen Quarz 18,432 MHz, 2x 22pF, 1x 100nF (SMD groß), 3x 100nF (SMD klein), 14x 10k und einen PL-2303. Schick mir Deine Adresse und dann gehen die Teile 'raus. Gruß, Wolfram
@Leo: Ich habe heute mal Deine letzte Version cpm3_0.6.8-35-asci-int-driver.sys auf die sd Karte kopiert und Deine Utilities einkopiert..und stolpere wieder über die Consolenparamter des Z180, bekomme nur Sauerkraut auf den Monitor. Was hast Du denn da standardmäßig eingestellt? Die cpm3_0.6.8-26.sys hatte ich aus den Git Sourcen selbst gebaut, hatte aber dann festgestellt das 0.35 doch ein ganzes Stück höher ist und halt das verwendet. Kannst Du bitte Dein Repository mal auf den aktuellen Stand bringen? Nochwas..ich hatte das gerade oben noch gelesen, willst Du noch so eine ECB Bus Platine haben? Dann laß mir bitte Deine Adresse zukommen. Mailadresse findest Du auf tiffe.de .. Gruß, Holm
Die Version ist im Repo im branch asci-int-driver. Mehr kann ich später schreiben. Sitze gerade auf einem Zahnarztstuhl.
Leo C. schrieb: > Die Version ist im Repo im branch asci-int-driver. > > Mehr kann ich später schreiben. Sitze gerade auf einem Zahnarztstuhl. ..arme Sau.. :-) Gruß, Holm
Holm T. schrieb: > Ich habe heute mal Deine letzte Version > cpm3_0.6.8-35-asci-int-driver.sys auf die sd Karte kopiert und Deine > Utilities einkopiert..und stolpere wieder über die Consolenparamter des > Z180, bekomme nur Sauerkraut auf den Monitor. Was hast Du denn da > standardmäßig eingestellt? Consolenparamter ? Console ist auf ASCI1 mit 115200 Baud. Der Z180 Takt ist auf 18.432 MHz vom AVR gejumpert, und das berühmt-berüchtigte Byte 3f sollte 0 sein. Bei mir sieht das dann so aus:
1 | CP/M Version 3.0, Z180-Stamp BIOS v0.6.8-35-asci-int-driver |
2 | Estimated CPU clock [Hz]: 18432000 |
3 | sdio: SD Card driver |
4 | cfio: CompactFlash Memory Card driver: No Card |
5 | |
6 | A>device |
7 | |
8 | Physical Devices: |
9 | I=Input,O=Output,S=Serial,X=Xon-Xoff |
10 | USB0 NONE IO ASCI0 19200 IOS ASCI1 134 IOS |
11 | |
12 | |
13 | Current Assignments: |
14 | CONIN: = ASCI1 |
15 | CONOUT: = ASCI1 |
16 | AUXIN: = Null Device |
17 | AUXOUT: = Null Device |
18 | LST: = Null Device |
19 | |
20 | Enter new assignment or hit RETURN |
21 | |
22 | A>stty asci1 |
23 | speed 115200 baud; |
24 | -BRKINT |
25 | IXOFF |
26 | |
27 | A> |
> Die cpm3_0.6.8-26.sys hatte ich aus den Git Sourcen selbst gebaut, hatte > aber dann festgestellt das 0.35 doch ein ganzes Stück höher ist und > halt das verwendet. > Kannst Du bitte Dein Repository mal auf den aktuellen Stand bringen? Die aktuelle Version war (wie schon geschrieben auf dem Server im Branch "asci-int-driver". Eigenlich wollte ich im master Branch bis auf weiteres den Polling-Treiber lassen. Jetzt habe ich gemerkt, das im master doch schon der Interrupt-Treiber von vor ein paar Wochen war. Deshalb habe ich den master jetzt auf den neuesten Stand gebracht, die Version auf 0.6.9 erhöht, und den asci-int-driver branch gelöscht. Anhang, der Code ist aber der gleiche als in '0.6.8-35-asci-int-driver'.
Bei mir läuft die cpm3_0.6.9-1.sys korrekt wie beschrieben. Das Byte 0x3F ist wie gewünscht 0.
Ok, ich werde mich heute später noch mal ran setzen. Ich hatte das Problem das überhaupt keine der üblichen Baudraten paßte weder mit 8N1,7E1 oder 7O1. Es gab immer nur Kauderwelsch im Terminal. Joe..darf ich Dich mal an die Gerber Daten zur ECB Platine erinnern? Gruß, Holm
Leo C. schrieb: > Die Init-Misere (INIDONE) ... ist Geschichte. > Ok, ich werde die Stelle so umbauen, daß die Initialisierung nur noch > dann ausgelassen wird, wenn man das wirklich braucht. Ich habe den Test jetzt ganz rausgeschmissen. Man brauchts nicht (mehr).
Ich bin gerade dabei die Hardware zu überarbeiten. Der Z180 soll mit SIDE und einer 8255 PIO, WDC37C65, SD-Karte, MAXen und etwas TTL Logik auf die Bus-Platine. Es gibt dann nur einen Steckplatz für die AVR Stamp. Zusätzlich ist noch ein EPROM/EEPROM vorgesehen. Es ist noch nicht ganz fertig, in 1-2 Wochen bin ich soweit. Ist das für irgendjemand interessant? Dann kann ich Wünsche noch berücksichtigen. Viele Grüße Günther
Günther S. schrieb: > Ich bin gerade dabei die Hardware zu überarbeiten. Der Z180 soll mit > SIDE und einer 8255 PIO, WDC37C65, SD-Karte, MAXen und etwas TTL Logik > auf die Bus-Platine. Es gibt dann nur einen Steckplatz für die AVR > Stamp. Zusätzlich ist noch ein EPROM/EEPROM vorgesehen. Es ist noch > nicht ganz fertig, in 1-2 Wochen bin ich soweit. Ist das für > irgendjemand interessant? Dann kann ich Wünsche noch berücksichtigen. > Viele Grüße > Günther Woher nimmst Du einen 20Mhz-fähigen 8255 PPI? Gruß, Holm
Es lassen sich für den IO Zugriff 4 Waitstates (DCNTL-Register) einschalten, entspricht dann ca 250ns Zugriffszeit, was mit Standard Bausteinen gehen müsste. Für eine Z80PIO kann man den Clock halbieren. Bei mir geht das mit 12 Mhz CPU Takt (24Mhz Quarz) und 6Mhz PIO jedenfalls. IM2 habe ich nicht getestet, da kommen dann aber nochmals 2 Waits dazu. Viele Grüße Günther
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.