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/
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.
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 allcircuitry 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.htmlhttp://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.
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 ) )
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 ;-)
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)
> 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.
> 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.
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.
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.
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.
> 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!
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
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
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
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
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.
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
> 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...
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!
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.
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?
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 :-)
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
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.
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.
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
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.
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...
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.
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?
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
:-(
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
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.
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.
> 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"
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.
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"
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.
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 :-)
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.
>> 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.
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.
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
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
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....
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?
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...
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...
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.
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]
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...
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.
> 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.
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 */
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...
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?
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.
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.
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...
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.
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.....
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?
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...
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....)
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.
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.
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?
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.
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.
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}"
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.
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.
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:
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..
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.
Sorry, der im letzten Beitrag gepostete Anhang enthält ein übeflüssiges
PDF, das das Archiv völlig unnötig aufbläht. Wenn ein Moderator den
Anhang löscht, stelle ich den Rest nochmal neu ein (ca 97K).
Edit: hängt schon dran. ;-(
Leo C. 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:
zu Bootloader patchen:
Da ich mit git/diff noch nie etwas gemacht habe: Wenn ich das richtig
sehe, muss ich im Quellcode (habe die Stelle gefunden) nur %c%s%c" gegen
"%s%c" im sprintf-Aufruf ändern und neu übersetzten?
Leo C. 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.
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
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?
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
> 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 :-()
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.
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!
> 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!
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?
> '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 :-(
> 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?
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.
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.
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.
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.
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:
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
> 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?
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
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.
> 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
Leo’s 'Aufforderung' zur Fingerübung hatte meine Aktivitäten temporär in
Richtung Software verlagert ;-)
Anbei nun der derzeitige Stand der Backplane.
1.
Fehler in der Stamp.Lib
AVR-Stamp B22 und B26 vertauscht. Da beide NC waren, jedoch ohne
Auswirkung.
2.
JP6 hat nun noch RxD_AVR und TxD_AVR um den AVR – Monitor direkt auf die
Frontplatte zu legen. Der Steckverbinder ist gleich neben der SD-Card.
Wird diese Variante benutzt, ist jedoch der FT232 auf dem AVR-Stamp in
den Reset zu schicken.
3.
/SHDN vom MAX3241 liegt zusätzlich auf PB6 vom AVR-Stamp um die RS-232 /
USB Umschaltung später per Software (DEVICE Befehl) ausführen zu können.
Die Leiterplatte ist geroutet und bedarf nur noch einiger Korrekturen
bezüglich der Leiterbahnbreiten und der Masseführung. Ich denke sie
diese Woche fertig stellen zu können. Um das Fehlerrisiko zu minimieren,
würde ich dann erst eine Testplatine fertigen lassen und bestücken, um
bei Fehlerfreiheit die gewünschte Anzahl in Auftrag zu geben.
Im nächsten Schritt erfolgt die abschließende Überarbeitung der beiden
Stamp-Platinen.
> Joe G. 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:
### 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.
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. ;-)
> ### main_loop: bootcmd="reset; loadf; go ${startaddr}"
Die Variable heißt 'startaddress'.
> CON:=AVRCON> ^> Error at the '^'; Invalid physical device
Das Device wurde umbenannt. Der Name AVRCON ist ja nicht so doll. Aus
Sicht des Z180-BIOS ist das zwar nur eine Verbindung zum AVR-Controller,
und der Z180 hat ja keine Kontrolle darüber, was der AVR damit macht.
Aber viele andere Möglichkeiten als die USB-Schnittstelle gibt es ja
nicht, und das ist ja auch das was der Benutzer sieht.
> Connecting to CPU. Escape character is '^^'.> -> Was muss man denn da eingeben?
Das erste '^' ist die (übliche) Abkürzung für Steuerzeichen, bzw. die
Control-Taste. Das zweite '^' meint die Taste mit diesem Zeichen selbst.
Also Control-Taste (Strg-Taste) gedrückt halten, und dann die Taste mit
dem '^' drücken. Der Code der Taste ist 0x1E. Wenn Dir die Taste nicht
gefällt, kannst du über die Environment-Variable 'esc_char' eine andere
definieren. Hier muß der Hex-Code ohne führendes 0x eingegeben werden.
Wenn der Hilfetext zu 'connect' unklar sein sollte, kann man mir gerne
einen anderen schicken. Baue ich gerne ein. Das gilt natürlich auch für
andere Verbesserungsvorschläge.
Marcel A. 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
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'.
=>
Marcel A. schrieb:> CRTL halten, links oben ^ drücken und alles loslassen klappt nicht.
Nach dem Ctrl-^ sieht man noch nichts. Erst nach dem nächsten Zeichen,
z.B '?'.
> Auch kein anderes Zeichen (Q, X, \)
Nach 'Q' oder 'X' müßte er wieder rausfliegen. Dann kommt das Ctrl-^ wie
bei Joe wirklich nicht durch. Villeicht gibts ja Tastaturen, die das
Zeichen nicht liefern? Unter Linux kannst Du die Tastatur mit 'showkey
-a' testen, allerdings nicht unter X-Window sondern in einer
Text-Console.
Peter 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:
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.
>> 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...
Schalte in diesem Fall mal auf 9600 Baud um, dann geht die Kommunikation
wieder. Es scheint am 18,432MHz Takt zu liegen und der Takterkennung.
Bei mir hat der "Full Swing Crystal Oscillator" [1] geholfen. Das Jitter
ist deutlich geringer und die Amplitude direkt am Quarz höher. Ich bin
mir auch nicht sicher, ob der Z180 innerhalb seiner Spezifikation
betrieben wird. Den damaligen Test [2] hatte ich ja nur an zwei Mustern
durchgeführt.
[1] Beitrag "Re: Z180-Stamp Modul"
[2] Beitrag "Re: CP/M auf ATmega88"
Marcel A. schrieb:> Aber bei loadc klappt das offenbar nur, wenn es "kalt"? ist. Wie oben
Es klappt wahrscheinlich nur, wenn ddt/z vorher nicht gelaufen ist.
Sorry, ich habe immer wieder vergessen das zu erwähnen. Das CP/M-BIOS
initialisiert normalerweise die komplette Hardware selbst, und richtet
auch eigene FIFO's im RAM ein, für die Kommunikation mit dem AVR. Damit
man das BIOS mit DDT/Z debuggen kann, wird ein Teil der Init
ausgelassen, wenn das BIOS feststellt, das der Debugger läuft. Sonst
würde der Debugger ja abgehängt. Leider klappt aber das aber noch nicht
alles wie gewünscht. Wenn man nach Experimenten mit dem Debugger das
CP/M starten will, sollte man z.Zt. die Address 0x38 mit 0 oder sonst
irgenwas != 0x80 beschreiben. Natürlich kann man auch den ganzen
Speicher löschen.
Joe G. schrieb:> Ich bin> mir auch nicht sicher, ob der Z180 innerhalb seiner Spezifikation> betrieben wird. Den damaligen Test [2] hatte ich ja nur an zwei Mustern> durchgeführt.
Laut Z80S180 Datenblatt[1] ist alles im grünen Bereich.
[1] http://www.zilog.com/docs/z180/z8s180ps.pdf
Zitat Frontpage: "Operating Range: 5V (3.3V@ 20 MHz)"
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.
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:\>
@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.
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 ;-)
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
@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,
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.
Joe G. schrieb:> I2C> Ethernet> Die Protokolle X25, TCPIP, Telnet, SMTP usw. im Z80 aufzusetzen, stelle> ich mir recht aufwendig vor.
Klar, das ist sinnlos.
> Möglicherweise existieren schon ähnliche> Projekte. Vielleicht ist es jedoch besser wie beim Umsetzer RS232 to USB> ein IC mit diesen Implementierungen zu nutzen.
Genau dafür ja der AVR Net-IO. Mit der firmware von Uli Radig setzt der
TCP/IP(Telnet) in RS232 um, beidseitig. Oder so ein Projekt wie unten
von Andreas beschrieben.
Aber auch dazu gibt es Alternativen. In der CT wurde gerade ein Baustein
vorgestellt, der das komplette WiFi-Thema abfrühstückt, und dann per
UART, SPI usw. transparent angesprochen wird (PAN9320).
Dein XPort ist ja auch so etwas.
Wichtig war mir nur, dass die Idee an sich machbar ist.
> Spontan fällt mir dazu> der XPORT von LANTRONIX ein. Den kannst du prima für Experimente an die> Erweiterungsstecker auf der Busplatine stecken.
Anbei die überarbeitete AVR-Stamp Version mit folgenden Änderungen:
1. vernünftiger Mico-SD-Halter (Pollin)
2. Fehler im Batteriehalter korregiert
3. RxD0 und TxD0 auf B26 bzw. B27 gelegt
4. FTDI über RESET abschaltbar
5. Stromversorgung flexibel zwischen 5V USB, extern 5V oder 3.3V
Bitte mal durchsehen und Fehler, Wünsche oder Kritik äußern.
Was waren die Überlegungen zu diesen Änderungen?
1. Mit der 5V Betriebsweise kann am Z80 Bus mit 5V Pegeln gearbeitet
werden.
2. Ist der FTDI nicht in Betrieb kann über RxD0 und TxD0 ein externes
VT100 Terminal angeschlossen werden, ohne die beiden seriellen
Schnittstellen des Z180 zu blockieren.
Andreas R. schrieb:> Vielleicht wäre das eine Netzwerklösung:Marcel A. schrieb:> Genau dafür ja der AVR Net-IO.
Ja dann... Wer schreibt den Telnet-Client für CP/M? Ich übernehme dann
gerne die Hardware :-)
Nachtrag:
Irgendwie war Seite 2 des PDF nicht mit dabei, hier nun die Schaltung
vollständig.
Sind die Änderungen halbwegs auch auf einer bereits bestückten Platine
machbar? Insbesondere der Z80-5V Bus-Betrieb und die Nutzung von RX/TX0
(also der über den AVR bereit gestellte Port) mit FTDI-Abschaltung wären
nett...
Marcel A. schrieb:> Sind die Änderungen halbwegs auch auf einer bereits bestückten Platine> machbar?
Ja sicher. Ich glaube Leo C. betreibt eine ähnliche Variation.
1. +3.3V auf +5V legen (Jumper auf dem Z180 Stamp)
2. Am FTDI die Verbindung von Pin 17 zu Pin 4 trennen und Pin 4 auf +5V
oder 3.3V (sind ja nun +5V)legen.
3. Pin 19 auf Masse legen (Achtung (!) in dieser Stellung kann keine
Firmware mehr geflasht werden)
4. Micro-SD-Card entfernen (verträgt auf keinen Fall +5V)
5. RxD0 auf B26 und TXD0 auf B27 legen.
Habs gesehen: Da ist ja nun ein Levelshifter drin vor der internen
SD-Karte.
Aber ohne SD-Karte wäre das ja doof. Aber auf der Basis-Platine ist ja
auch eine externe SD-Karte vorgesehen - mit Level-shifter. Und so wie
ich das sehe, sind die Anschlüsse parallel zur "internen" SD-Karte. Also
entweder intern oder extern? Die externe SD mit Level-Shifter würde dann
die Funktion der bisher internen SD übernehmen?
Ansonsten muss ich das ganze Zeug noch mal aufbauen - Fluch des Early
Adaptors :-)
Joe G. schrieb:> Ja dann... Wer schreibt den Telnet-Client für CP/M? Ich übernehme dann> gerne die Hardware :-)
Wenn man einen Socket hat, ist Telnet doch nicht mehr so schlimm? Aber
man kann ja nicht viel damit machen? SSH wäre cool.
Marcel A. schrieb:> lso> entweder intern oder extern? Die externe SD mit Level-Shifter würde dann> die Funktion der bisher internen SD übernehmen?
Vielleicht war meine bisherige Erklärung nicht so eindeutig, deshalb
noch mal.
Die bisher aufgebauten Systeme Z180-Stamp (V1.0) und AVR-Stamp (V1.0)
sind beide eigentlich für 3.3V ausgelegt. Damit gehen dann auch beide
SD-Karten, die interne und die externe auf dem Basisboard. Dem
Basisboard selber sind die Spannungen egal, dieses geht immer mit 3.3V
oder 5V.
Die derzeit überarbeiteten Versionen des Z180-Stamp (V1.1) und des
AVR-Stamp (V1.1) werden neben der eigentlichen Beseitigung der Bugs auch
auf 5V laufen können. Das ist jedoch nur dann von Vorteil, wenn am
Z80-Bus ältere Erweiterungsschaltungen mit 5V betrieben werden (z.B.
Floppy-Controler, PIO, SIO, CTC oder ähnliches). Neue
Hardwareentwicklungen (Ethernet, USB, WLAN…) können natürlich gleich auf
3.3V ausgelegt werden.
Hi!
Also nochmal kurz zum Zusammenfassen:
- Die Busplatine ist erste Release
- Die beiden Stamps kommen in einer fehlerkorrigierten Version 1.1
zwar nicht dieser Thread, aber
- die VT100-Platine ist auch die fehlerkorrigierte Version 1.1
Ist das so richtig? Das SVN scheint nämlich nicht aktuell zu sein.
LG
Harald N. schrieb:> Ist das so richtig? Das SVN scheint nämlich nicht aktuell zu sein.
Sollte nun alles wieder aktuell sein (alle drei Platinen in der Version
1.1)
Andreas R. schrieb:> SSH wäre cool.
Ein 80286 mit 12 MHz braucht etwa 4 Minuten, um den initialen Key
auszurechnen. Der Server hat in der Zeit die Verbindung schon längst mit
einem Timeout getrennt - vergiss es.
Joe G. schrieb:
ion der bisher internen SD übernehmen?
> Die bisher aufgebauten Systeme Z180-Stamp (V1.0) und AVR-Stamp (V1.0)> sind beide eigentlich für 3.3V ausgelegt. Damit gehen dann auch beide> SD-Karten, die interne und die externe auf dem Basisboard. Dem> Basisboard selber sind die Spannungen egal, dieses geht immer mit 3.3V> oder 5V.
Danke dir, vielleicht muss ich mal das Brett vor dem Kopf suchen, aber
so ganz habe ich es noch nicht...
Wenn man beide Stamps mit 5V betreiben will, geht das ja ohne Probleme,
da glaube ich alle Bausteine 5V können - bis auf die SD-Karte, richtig?
Daher ist nun vor der internen SD-Karte eine Pegelanpassung, richtig?
Die externe SD-Karte auf dem Basis-board bekommt auch eine
Pegelanpassung, richtig?
Und wenn ich den Schaltplan richtig lese, sind die interne und die
externe SD an den gleichen Anschlüssen - also kann doch auch nur eine
davon verwendet werden, oder?
Um beim FTDI muss ich auch noch etwas beachten bei 5V-Betrieb?
Marcel A. schrieb:> Wenn man beide Stamps mit 5V betreiben will, geht das ja ohne Probleme,> da glaube ich alle Bausteine 5V können - bis auf die SD-Karte, richtig?
**** *******
Wie Du richtig siehst, können eben nicht alle Bausteine 5V. Deshalb ist
es genau anders rum und 3.3V geht ohne Probleme. Jedenfalls, wenn man
nur das System mit den beiden Stamp-Karten (und vielleicht noch einer
zusätzlichen SD-Karte) betrachtet. Die Probleme beginnen, wenn man das
System erweitern will, z.B. mit (alten) ECB-Karten über die
ECB-Schnittstelle auf der Basis-Karte. Oder, wie es mir passiert ist,
statt der Z180-Stamp-Karte eine CPU-Karte verwenden will, die nur 5V
kann [1].
> Daher ist nun vor der internen SD-Karte eine Pegelanpassung, richtig?
Damit man die AVR-Stamp auch mit 5V betreiben kann.
> Die externe SD-Karte auf dem Basis-board bekommt auch eine> Pegelanpassung, richtig?
Ja, aus dem gleichen Grund.
> Und wenn ich den Schaltplan richtig lese, sind die interne und die> externe SD an den gleichen Anschlüssen -
Bis auf die Select-Leitung (CD/SS bzw. CD/DAT3).
> also kann doch auch nur eine> davon verwendet werden, oder?
Nein.
> Um beim FTDI muss ich auch noch etwas beachten bei 5V-Betrieb?Joe G. schrieb:> 2. Am FTDI die Verbindung von Pin 17 zu Pin 4 trennen und Pin 4 auf +5V> oder 3.3V (sind ja nun +5V)legen.
Siehe Bild.
Pin 4 muß gleiches Potential wie VCC am AVR haben.
@Joe
Auf der neuen AVR-Stamp gehört der Pullup DAT0/MISO (R4) an 3.3V, nicht
an VCC.
[1] Beitrag "Re: Z180-Stamp Modul"
@Joe
Im Stromlaufplan der Base sind die ICs 74AHC bzw 74LV, in der
BOM taucht aber auch 74AC auf.
74LV können 3,3V, 74AC 2-6V.
Welche sind denn die richtigen Typen?
Gruss
Peter
Jetzt hab ichs... Danke.
Mit den Select-Leitungen kann zwischen interner und externer SD
selektiert werden - feine Sache.
Ich habe halt (inzwischen) ganze Kisten mit "Z80-Hardware" hier, die ich
gerne verbasteln würde - daher mein Interesse an den 5V.
Wenn ich also auf die interne SD verzichte (und stattdessen die externe
SD über Shifter nehme) und die Umbauanleitungen von Joe beachte für die
V1.0, dann wäre das möglich.
Das hier:
>3. Pin 19 auf Masse legen (Achtung (!) in dieser Stellung kann keine>Firmware mehr geflasht werden)
bedeutet also, dass ich mir das schaltbar machen sollte (ist im neuen
Plan ein Jumper) - um zwischen VT100/RXTX0 und Programmierung umschalten
zu können?
Peter Z. schrieb:> Welche sind denn die richtigen Typen?
Die zweite Spalte in der BOM bezeichnet tatsächlich den verwendeten
Type. Die dritte Spalte nur das Gehäuse des Device. Du solltest also wie
angegeben einen AHC nehmen. Die beiden LV Bezeichnungen muss ich noch
ändern (Danke). Diese Typen ergaben sich aus der reinen 3.3V Bestückung.
Leo C. schrieb:> Auf der neuen AVR-Stamp gehört der Pullup DAT0/MISO (R4) an 3.3V, nicht> an VCC.
Natürlich, Danke!
Nachtrag zur Logikfamilie:
Es scheint nicht ganz so eindeutig zu sein. Normalerweise hat die
LV-Familie (Low-Voltage-CMOS) eine Betriebsspannung von 3.3V [1]. Nun
geben unterschiedliche Hersteller wiederum eigene Daten dazu an [2].
Hier läuft ein 74LV74 auch mit 5V.
[1] https://de.wikipedia.org/wiki/Logikfamilie
[2] http://www.nxp.com/documents/data_sheet/74LV74.pdf
Kleines Update für den Stamp-Monitor.
Es enthält nur kleine Änderungen in der SD-Karten-Erkennung. Wer bisher
nur einen Kartensockel angeschlossen und damit keine Probleme hat,
braucht das Update nicht.
Der Befehlszeileneditor kennt jetzt auch die Ende-Taste. Allerdings
liefern Pos1 und Ende je nach Terminal(-Emulation) unterschiedliche
Codes, so daß die Tasten manchmal doch nicht funktionieren.
Hier eine Liste der Editor-Funktionen und die Tastenzuordnung.
Änderungen und Erweiterungen sind denkbar.
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.
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"
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>
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.
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:
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 :(...
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
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.
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?
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.
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
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?
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
Philipp Klaus K. schrieb:> st damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware> (OSHW) Definition fällt", und welche genau wird später festgelegt?
Gemeint ist CC BY-NC-SA 4.0 für die Baupläne (Schaltungsunterlagen und
Layout) Das sollte auch so auf den Schaltplänen verzeichnet sein.
> Wird es sowas dieses Jahr nochmal geben?
Das kommt auf den Bedarf an. Derzeit sieht es nicht danach aus. Es sind
jedoch noch Platinen vorrätig.
2 x ECB Bus
4 x AVR-Stamp
4 x Z180-Stamp
Joe G. schrieb:> Philipp Klaus K. schrieb:>> st damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware>> (OSHW) Definition fällt", und welche genau wird später festgelegt?>> Gemeint ist CC BY-NC-SA 4.0 für die Baupläne (Schaltungsunterlagen und> Layout) Das sollte auch so auf den Schaltplänen verzeichnet sein.
Beim AVR-Stamp und dem Z180-Stamp steht "CC BY-NC-SA 4.0", die sind also
keine Open Source Hardware. Bei dem ECB-Board steht "open source
hardware", und das Open Source Hardware Logo ist im Platinenlayout. Das
Logo darf nur für Open Source Hardware verwendet werden.
>>> Wird es sowas dieses Jahr nochmal geben?> Das kommt auf den Bedarf an. Derzeit sieht es nicht danach aus. Es sind> jedoch noch Platinen vorrätig.>> 2 x ECB Bus> 4 x AVR-Stamp> 4 x Z180-Stamp
Wieviel würde es mich kosten, wenn ich von jeder Art eine nähme?
In manchen Beiträgen dieses Threads ist ein STM32-Stamp erwähnt. Gibt es
den schon?
Philipp
Philipp Klaus K. schrieb:> Wieviel würde es mich kosten, wenn ich von jeder Art eine nähme?Joe G. schrieb:> Preise incl. Versand aus China, Zoll und Einfuhrumsatzsteuer:> BUS 6.10€> Z180-Stamp 3.36€> AVR-Stamp 3.36€
+ 1.65 Porto . Kurze Mail mit deiner Adresse an mich reicht, dann sende
ich dir die Platinen per Post zu.
Joe G. schrieb:> Philipp Klaus K. schrieb:>> st damit gemeint "irgendeine Lizenz, die unter die Open Source Hardware>> (OSHW) Definition fällt", und welche genau wird später festgelegt?>> Gemeint ist CC BY-NC-SA 4.0 für die Baupläne (Schaltungsunterlagen und> Layout) Das sollte auch so auf den Schaltplänen verzeichnet sein.
Nochmal nachgeschaut: "CC BY-NC-SA 4.0" steht bei den Schaltplänen für
AVR-Stamp und Z180-Stamp, bei der Busplatine steht da nichts. "Open
Source Hardware" und Logo stehen auf den Layouts.
Aber "CC BY-NC-SA 4.0" ist nicht Open Source Hardware.
Philipp
Marcel A. schrieb:> Beim D345 bin ich mir nur nicht sicher> hinsichtlich der Störme. Da steht in den (spärlichen) Unterlagen etwas> von Konstantstromsenke 40mA.
Im Datenblatt steht für die Typen 345/347 eindeutig 20 mA drin, und für
die 346/348 0...40 mA.
So, hier habe ich mal die Bestellnummern für Reichelt für die
Basis-Platine auf Basis der oben gelisteten BOM zusammengestellt.
Die ICs sollten in Absprache mit Joe für 3,3V und 5V Betrieb geeignet
sein.
Hinweis:
- Eine passende 3mm Duo-Led gibt es dort nicht, nur 5mm. Also entweder
dann alles auf 5mm LEDs oder die LED woanders (ebay) hernehmen
- Den MAX3241 gibts da auch nicht - also entweder anderer Distributor
oder ebay
- Den SD-kartenleser entweder von Pollin oder aus China
- Wofür die 2 0Ohm Widerstände an CON0/1 sind, erschließt sich mir noch
nicht, sind das die gebrückten Steuerleitungen (RTS etc.)?
Wenn jemand Fehler findet, bitte melden.
Gruß
Marcel
Joe G. schrieb:> Eine Fertigung ohne Druck würde ca. 20€/Stück> kosten, mit Druck 35€/Stück. Wie ist eure Meinung?
Puh, das ist ja nicht wenig...
Welche Breite hast du denn genommen bzw. was ist denn die
"Standard-Breite" (vermutlich 20/40mm)?
Es fehlen ja noch ein paar Bohrungen und Befestigungen - aber ist ja
sicher auch erst mal nur eine Idee.
Marcel A. schrieb:> Welche Breite hast du denn genommen bzw. was ist denn die> "Standard-Breite" (vermutlich 20/40mm)?
Die Frontplatte ist 3 HE und 10 TE, also 128.4 x 50.46
> Es fehlen ja noch ein paar Bohrungen und Befestigungen
Welche? Eigentlich ist alles drauf.
Marcel A. schrieb:> Wofür die 2 0Ohm Widerstände an CON0/1 sind, erschließt sich mir noch> nicht, sind das die gebrückten Steuerleitungen (RTS etc.)?
Der 0-Ohm Widerstand zwischen den Pins 2 und 7 ist eine Brücke zwischen
DTR und DSR [siehe PDF]. Der Wannenstecker ist ja so belegt, dass ein
Flachbandkabel ohne löten direkt an einen D-SUB ST 09FB passt. Die
Brücke zeigt dem jeweiligen Partner nur an, dass das andere Gerät
angeschlossen und generell zur Arbeit bereit ist.
Joe G. schrieb:> Marcel A. schrieb:>> Es fehlen ja noch ein paar Bohrungen und Befestigungen> Welche? Eigentlich ist alles drauf.
z.B. die Löcher für die SUB-D Stecker - aber ich denke, ich mache eh ein
eigenes Layout bei dem Kurs...
SUB-D-Stecker (male) war ja jetzt der letzte Stand der Diskussion?
Und die USB-Buchse ist wahrscheinlich als Verlängerung für die
USB-Buchse auf dem AVR Stamp gedacht? RXDA/TXDA ist ja auch noch mal auf
der Basis herausgeführt - vermutlich für die VT100 intern.
Was macht man mit dem Anschluss "Monitor" (PG5)?
Wenn einmal "Einzelschritt" unterstützt wird, ist das ja für Leos
Monitor vorgesehen. Könnte man das auch über einen Taster machen? Mit
einem händisch gesteuerten Takt (wie beim S100-Projekt) oder als Input
für den AVR-Monitor?
Marcel A. schrieb:> z.B. die Löcher für die SUB-D Stecker
Sind doch dabei, links und rechts neben dem Durchbruch für den Kelch.
> SUB-D-Stecker (male) war ja jetzt der letzte Stand der Diskussion?
Ein DTE, Data terminal equipment (Computer oder Terminal), bekommt einen
Stecker [1].
> Und die USB-Buchse ist wahrscheinlich als Verlängerung für die> USB-Buchse auf dem AVR Stamp gedacht? RXDA/TXDA ist ja auch noch mal auf> der Basis herausgeführt - vermutlich für die VT100 intern.
Ja
> Was macht man mit dem Anschluss "Monitor" (PG5)?
Derzeit noch nichts. Zukünftig sollen damit im Fehlerfall der EEPROM des
AVR mit einer Defaulteinstellung geladen werden.
> Könnte man das auch über einen Taster machen?
Ja sicher, STEP auf PG0 zu legen war ja nur ein Vorschlag.
[1] https://de.wikipedia.org/wiki/RS-232
Marcel A. schrieb:> So, hier habe ich mal die Bestellnummern für Reichelt für die> Basis-Platine auf Basis der oben gelisteten BOM zusammengestellt.> […]
Könnte man noch dokumentieren, wozu die Teile jeweils gebraucht werden,
so dass man gleich sieht, was man z.B. weglassen kann, wenn man kein
Interesse an irgendwelchen Teilfunktionalitäten hat? Danke.
Philipp
Ich denke, das ist schwierig, da es Abhängigkeiten gibt. Letztlich hilft
da nur, die Schaltung zu verstehen (da musst ich auch durch :-) und ist
bei der Basisplatine ja auch übersichtlich) und dann schauen, was man
machen will.
Ich wüsste bei den paar Cent aber nicht, was man weglassen sollte. Am
ehesten vielleicht den MAX3241, wenn man dank USB-Seriell-Adapter auf
"echte" 12V RS232 verzichten kann.
Ich stelle mir gerade auch die Teile für die neue AVR Stamp 1.1
zusammen, da ich doch gerne beide SD-Karten nutzen möchte.
Den ATMEGA1281V gibts bei Reichelt nicht mehr - nur den "dickeren"
ATMEGA2561V - sollte laut Unterlagen gleiches Layout haben, nur doppelte
so viel Flash. Da wäre dann noch Potential für weitere
Monitor-Funktionen :-).
Richtig?
Bei der Z180 Stamp hatten sich ja "nur" der Fehler im Layout unter der
CPU und die Änderungen in den Jumpern zur Spannungsversorgung ergeben?
Passendes RAM und CPU gibts bei Reichelt nicht - vielleicht ebay oder
Sammelbestellung "demnächst" mal.
Beim Durchsehen der Schaltpläne ist mir aufgefallen, dass die 3,3V auf
dem Z180-Modul aus den 5V erzeugt werden. Warum? Wäre das nicht eher
eine Aufgabe für die Busplatine?
Philipp
Philipp Klaus K. schrieb:> Warum?
Vielleicht etwas Historie zum Verständnis.
Nach dem AVR-CP/M System entstand der Wunsch mal wieder etwas mit einem
richtigen Z80 zu machen. Dabei sollten nur heute verfügbare Bauelemente
verwendet werden um den Nachbau zu erleichtern. Im Prinzip benötigt man
neben CPU und Adressdecoder nur noch RAM und EPROM. Um den EPROM
Anwenderfreundlich zu gestalten, wurde er durch einen AVR ersetzt, d.h.
der AVR steckt als EPROM auf dem Z180. Somit ist auch die
Stromversorgung auf der eigentlichen Hauptplatine (Z180). Das System ist
also als Huckepackvariante ohne Busplatine vollständig lauffähig. Die
Idee mit der Busplatine kam erst viel später. Da aber alles Hobby ist
und alle Daten frei verfügbar sind, kann jeder letztlich damit machen
was er möchte – z.B. auch die Stromversorgung auf die Busplatine
bringen.
Marcel A. schrieb:> Bei der Z180 Stamp hatten sich ja "nur" der Fehler im Layout unter der> CPU und die Änderungen in den Jumpern zur Spannungsversorgung ergeben?
Ja korrekt, mehr ist dort nicht geändert
Joe G. schrieb:> Nach dem AVR-CP/M System entstand der Wunsch mal wieder etwas mit einem> richtigen Z80 zu machen.
Bei mir wars so, daß ich danach meine fast 30 Jahre alte HD64180-Karte
[0] wieder in Betrieb nehmen wollte. Das EPROM hatte ich bereits durch
ein EEPROM ersetzt. Nachdem mir das aber zu umständlich wurde, und auch
noch ein Serial-Port durch Netzteilprobleme zerstört wurde, hatte ich
ein neues System aufgebaut, mit einem 2. HD64180, statischem RAM und
einem stm32-discovery-board als EPROM-Ersatz und zum Anschluß von
moderner Peripherie [1].
Schließlich hatten wir beide Systeme zusammen gelegt, wobei der stm32
bis auf weiteres unter den Tisch gefallen ist.
Philipp Klaus K. schrieb:> In manchen Beiträgen dieses Threads ist ein STM32-Stamp erwähnt. Gibt es> den schon?
S.o.
[0] Beitrag "Re: z80 system"
[1] Beitrag "Re: CP/M auf ATmega88"
Marcel A. schrieb:> Den ATMEGA1281V gibts bei Reichelt nicht mehr - nur den "dickeren"> ATMEGA2561V - sollte laut Unterlagen gleiches Layout haben, nur doppelte> so viel Flash.
Sollte gehen. Aber wieso eigentlich die V-Versionen? Die sind bis 8 MHz
spezifiziert, während die Versionen ohne V immerhin bis 16 MHz gehen.
Allerdings auch nicht bei 3.3V ;)
> Da wäre dann noch Potential für weitere> Monitor-Funktionen :-).
Auch im ATmega128 sind noch ca. 45 K frei.
Im Anhang ist der Versuch einer Stückliste für Bestückungsvarianten für
die Busplatine. Die Bauteile in Spalte "Alle" sollten immer bestückt
werden, bis auf die (x)-Teile, die auch weggelassen werden können, wenn
man sie nicht braucht.
Marcel A. schrieb:> - Eine passende 3mm Duo-Led gibt es dort nicht, nur 5mm. Also entweder> dann alles auf 5mm LEDs oder die LED woanders (ebay) hernehmen
Pollin hat mehrere. Ich habe die KINGBRIGHT L-93WEGW. Ob die anderen
besser oder schlechter sind, kann ich nicht sagen.
Wer seine ECB-Busplatine noch nicht vollständig bestückt hat, könnte
noch die folgende Erweiterung übernehmen:
- CON2 (6polig) durch eine Buchse (7polig) ersetzen.
Dazu muss per Hand ein weiteres Loch gebohrt werden, Platz dafür ist
vorhanden. Dieses zusätzliche Pin wird dann mit /CTS0 beschaltet (Pin 18
IC2). Damit kann bei der SIO Kanal 0 später Hardware-Handshake (RTS/CTS)
genutzt werden. Diese Funktion ist für die USB-Host Erweiterung
notwendig.
> - CON2 (6polig) durch eine Buchse (7polig) ersetzen.> Dazu muss per Hand ein weiteres Loch gebohrt werden, Platz dafür ist> vorhanden.
Gute Idee. Werde ich bei Gelegenheit wohl machen. Allerdings muß ich den
zusätzlichen Pin dann einkleben. Ich habe bei mir Stift- statt
Buchsenleisten eingelötet.
Inzwischen habe ich mir ein paar von den USB-Serial-Adaptern mit FT323RL
und 6-poliger Stiftleiste zum Testen bestellt.
Im Anhang ist ein DEVICE.COM, daß die von unserem BIOS unterstützten
Baudraten richtig anzeigt. Also diese hier:
150 300 600 1200
1800 2400 3600 4800
7200 9600 19200 28800
38400 57600 115200
Die Änderung ist also rein kosmetisch.
Man könnte das Programm noch etwas "aufbohren", um zusätzliche Baudraten
zu unterstützen. Nur welche? Über 115200 halte ich nicht für sinnvoll.
Braucht jemand Baudraten unter 150? Amateurfunker vielleicht? Oder
möchte jemand noch ein DATEX-P Modem betreiben?
Leo C. schrieb:> Braucht jemand Baudraten unter 150? Amateurfunker vielleicht?
Grins... Nein, ich denke auch wir Funkamateure brauchen das heute nicht
mehr. 300Bd Packet Radio (AX.25) haben wir vor über 20 Jahren auf
Kurzwelle gemacht - heute sieht das anders aus.
Leo C. schrieb:> Im Anhang ist ein DEVICE.COM
Sehr schön! Wo hast du denn eigentlich die PL/M Quelle für DEVICE her?
> Allerdings muß ich den zusätzlichen Pin dann einkleben.
Das ist das schwere Los der Betatester :-)
> Man könnte das Programm noch etwas "aufbohren", um zusätzliche Baudraten> zu unterstützen. Nur welche?
Der USB-Host schafft auch 250000 Baud.
Marcel A. schrieb:> Packet Radio (AX.25) haben wir vor über 20 Jahren auf> Kurzwelle gemacht
Kein Packet Radio auf Langwelle?
Joe G. schrieb:> Der USB-Host schafft auch 250000 Baud.
Mit 18,432 MHz Takt könnten wir theoretisch noch 144K, 192K, 288K. Aber
unter CP/M sind 115,2K ja schon mehr als schnell genug. Wenn man mit
TYPE eine Datei ausgibt, schafft CP/M ca. 26,2 KBaud. Input habe ich
noch nichts gemessen, dürfte aber kaum schneller verarbeitet werden
können. Vielleicht kannst Du ja mal messen, auf welche effektive
Datenrate der USB-Host kommt.
Joe G. schrieb:> Sehr schön! Wo hast du denn eigentlich die PL/M Quelle für DEVICE her?
Von "The Unofficial CP/M Web site":
http://www.cpm.z80.de/source.html
Daraus dann das "DEVELOPERS BUILD DIRECTORY for CP/M 3", bzw. die
Unix-Version davon. Das sind die Sourcen zu den Binaries, die ich bisher
schon für unser System genommen hatte und hier zu finden sind:
http://www.cpm.z80.de/binary.html#operating
Dort, und auf John Elliott's Site (http://www.seasip.info/index.html),
von dem die Pakete stammen, findet man auch die Tools, die man zum bauen
braucht.
Die Quellen will ich auch in unser Repo integrieren, weiß aber noch
nicht genau, in welcher Form.
README von John Elliott:
1
CP/M 3
2
======
3
4
This archive contains an almost complete build of CP/M 3.
5
6
If you have the source distribution, the file making.txt explains how to
7
set up the build environment on your computer.
8
9
Differences from Digital Research CP/M 3
10
========================================
11
12
All the CP/M 3 patches described in the document CPM3FIX.PAT have been
13
applied to the source code, except those to INITDIR. Patches 1-18 (except
14
nos. 5 and 9) were applied.
15
16
CP/M 3 is now fully Year 2000 compliant. This affects the programs
17
DATE.COM, DIR.COM and SHOW.COM.
18
19
Dates can be displayed in US, UK or Year-Month-Day format. This is set by
20
SETDEF:
21
22
SETDEF [US]
23
SETDEF [UK]
24
SETDEF [YMD] respectively.
25
26
The CCP has a further bug fix: A command sequence such as:
27
28
C1
29
:C2
30
:C3
31
32
will now not execute the command C3 if the command C1 failed.
33
34
What's missing?
35
===============
36
INITDIR.COM - because it is written in PL/I and I can't make the
37
PL/I compiler at <http://cdl.uta.edu/cpm> compile it.
38
Apparently a more recent version of the compiler is
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:
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.
@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.
> 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.
Meine Platine hat keinen Bestückungsaufdruck. Wo der Fehler war, weiß
ich nicht (mehr).
Aber hier habe ich leider Mist geschrieben. Gerade nochmal nachgemessen:
> Bei mir ist in dem Bild der obere Anschluß rot und der untere grün.
Falsch! Grün ist oben und Rot unten.
Der Rest stimmt aber:
> Rot geht über 150 Ohm> an pin 13 von IC4 und grün über 270 Ohm an Pin 11. Kann sein, daß bei> mir die Widerstände vertauscht sind, aber das Ergebnis sieht brauchbar> aus.
D.h. der Schaltplan, Version 1.1 ist richtig.
Leo C. schrieb:> D.h. der Schaltplan, Version 1.1 ist richtig.
Korrekt, ich hatte die Farbzuordnung im Schaltplan korregiert. Die
ECB-LP hat sich gegenüber der Testversion auch nur minimal geändert. Nur
die LED für die externe SD ist ewas verschoben und gedreht, so dass sie
besser gebogen werden kann.
@Leo
Habe die DUO-LED jetzt angelötet, Rot an R9 und Grün an R8.
Beim Einschalten ist die LED grün, im Monitor Betrieb rot/grün.
Mit pin 8 low bleibt es so. Allerdings gibt es es beim RAM write
auch kein Bus-timeout mehr und "md" zeigt jetzt die richtigen
Werte.
Mtest füllt ja den gesamten Speicher mit 00h und zeigt 0 errors.
Die LED leuchtet grün, solange der Test läuft, dann wieder rot/grün.
Dann habe ich 7FFFFh mit 76h beschrieben und mit go 0 gestartet.
Die LED wird grün und bleibt grün. Scheinbar wird die 76h nicht
erreicht, denn ein weiteres go 0 meldet "CPU already running".
Was kann ich noch testen?
Gruss
Peter
In der Z180 Version 1.0 war noch ein Hardwarefehler bei RESET. Ist der
behoben?
Nachtrag. Versuche doch mal den Halt Befehl etwas früher in den RAM zu
schreiben, z. B. In den ersten 64k RAM Bereich.
Peter Z. schrieb:> Dann habe ich 7FFFFh mit 76h beschrieben und mit go 0 gestartet.> Die LED wird grün und bleibt grün. Scheinbar wird die 76h nicht> erreicht, denn ein weiteres go 0 meldet "CPU already running".
Die 7FFFF kann nicht erreicht werden. Der up läuft nur bis FFFF und
fängt dann wieder bei 0 an. Grün ist dann also OK.
> 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
@leo
Ich habe jetzt mal die VT100-Platine an ASCI0 (auch an ASCI1 probiert)
angeschlossen und nach Deiner Anleitung vom 16.5. CP/M3 gestartet.
Allerdings kommt keine Meldung auf dem Terminal.
Welche Baudrate muss ich denn einstellen, habe 4800, 9600 und 19200
probiert?
Gruss
Peter
Peter Z. schrieb:> Welche Baudrate muss ich denn einstellen
Beide Schnittstellen sind default auf 19200 Baud eingestellt [1]. Die
VT100 Software ist jedoch auf 115200 Baud eingestellt. Wenn du diese
nicht geändert hast, verstehen sich beide natürlich nicht ;-) Außerdem
gibt es seit dem 16.05 auch ein neues BIOS. Vielleicht gibt Leo ja auch
bald die ganz neue Version mit integriertem Handshake 'offiziell' frei
;-)
[1]
Physical Devices:
I=Input,O=Output,S=Serial,X=Xon-Xoff
USB0 NONE IO ASCI0 19200 IOSX ASCI1 19200 IOS
Current Assignments:
CONIN: = ASCI0
CONOUT: = ASCI0
AUXIN: = ASCI0
AUXOUT: = ASCI0
LST: = Null Device
Ich habe jetzt mal getestet, ob ASCI0 und ASCI1 überhaupt gehen.
Dazu habe ich DDT/Z über ASCI1 ADR 3,02 115200 Baud ans VT100
ausgegeben, ok. DDT/Z über ASCI0 ADR 3,01 19200 Baud VT100 auch ok.
VT100 19200 Baud an ASCI0, neues Bios geladen, go FA00 --> keine Ausgabe
auf das VT100.
Gruss
Peter
Peter Z. schrieb:> go FA00 --> keine Ausgabe auf das VT100.
Das BIOS startet an Adr: 0xCD00
Du kannst jedoch die Startadresse automatisch ermitteln und dann mit
dieser Adresse starten.
bootcmd=reset; loadc; run run_step; go ${startaddress}
Außerdem sollte cpm3_commonbase=F000 sein.
Leo C. schrieb:> Gilt das für beide Richtungen?
Eine Datei von CP/M auf den USB-Stick schieben dauert ca. 12,3 KBbaud.
In die andere Richtung schaffe ich jetzt etwa die gleiche
Geschwindigkeit.
@Joe,
ich habe mal die env geändert, bekomme aber eine Fehlermeldung.
Hier mal die env und die Fehlermeldung.
printenv
baudrate=115200
bootcmd=reset; loadc; run run_step; go $(startaddress)
bootdelay=3
cpm3_commonbase=F000
cpm3_file=1:/cpm3.sys
dsk0=1:/cpm3test.dsk
pin_alias=0:PG5,1:PG4,2:PB4,3:PB5,4:PB6,5:PB7,6:PG3,7:PG2,8:PG1,9:PG0,10
:PE7
startaddress=d100
Environment size: 242/1597 bytes
## Error: "run_step" not defined
Command failed, result=1
Gruss
Peter
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?
> bootcmd=reset; loadc; run run_step; go $(startaddress)
^^^^^^^^^^^^^^^
Der Monitor versteht hier nur geschweifte Klammern {}.
Joe hat wohl eine Environment-Variable mit Namen run_step, in der
Monitor-Befehle stehen. Du kannst das auf jeden Fall weglassen.
Für den Anfang kannst Du die Monitor-Befehle auch einzeln direkt
eingeben, statt über bootcmd ausführen zu lassen. Wenn vorher bereits
DDTZ lief, solltest Du RAM-Adresse 3F mit irgendwas != 80h füllen. Z.B.
=> mw 3f 0
Und dann:
=> loadc
=> go ${startaddress}
Dann sollte sich auf ASCI0 CP/M melden.
Nachtrag:
> Es ging darum, die richtige Startadresse zu haben, um eine Bootmeldung> am Terminal zu bekommen.
Die hatte Joe für das aktuelle BIOS ja auch schon genannt. Statt
=> go ${startaddress} kannst Du auch
=> go CD00
eingeben. Nur wird sich die Adresse bei der nächsten BIOS-Version wieder
ändern und ist deshalb für automatisches Starten nicht geeignet.
Leo 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
Joe G. schrieb:> Das Binärfile wird> also in einem Ruck übertragen ohne Checksumme, Prüfbyte usw... Bremsen> lässt sich die Software in diesem Zustand nur noch über RTS oder CTS.
Das läßt sich wohl kaum noch was beschleunigen. Auf CP/M-Seite möglichst
große Puffer, die mit Multi-Sector-I/O gelesen/geschrieben werden. Man
kann auch direkt auf die serielle Schnittstelle zugreifen, statt übers
BIOS zu gehen. Aber wenn der USB-Host merkwürdige Denkpausen macht, wie
Du weiter oben geschrieben hattest, nützt das alles auch nicht viel.
Danke für die FTDI-Links. Ich hatt da schon mal gesucht, aber nicht das
richtige gefunden.
Leo C. schrieb:> Das läßt sich wohl kaum noch was beschleunigen.
Der VNC2 kennt noch einen 8 Bit FIFO-Mode. Hier sollen laut einiger
Forumnutzer ca. 65 KBaud möglich sein. Vielleicht wenn ich mal viel Lust
und Zeit habe ;-)
Peter Z. schrieb:> Damit startet cpm3 bis zum cpm3-Prompt auf ASCI0
Mein Glückwunsch!
> wie willst Du das mit den beiden USB-Buchsen machen?> V2DIP2-32 Platine an der Frontplatte montieren oder eigene Platine?
Ich habe ehrlich gesagt noch keine Idee. Zunächst würde ich die Platine
auf die Buchsenleiste CON2 (Console 0 – USB) stecken. Die Umschaltung
(JP5) müßte jedoch manuell erfolgen. Vielleicht ist auch ein eigens
Slotblech mit kleinem Umschalter sinnvoll. Dann würde nur ein Kabel auf
CON2 aufgesteckt werden. Da ich noch keinen Platinenentwurf habe, bin
ich für Ideen noch ganz offen.
Ich hatte mir für das 19" Rack ein kleines Mini-Servernetzteil geholt.
Passt fast perfekt auf eine Europlatine und in den Rahmen. 5V 7A, 12V
2A, -12V. Leider kommen trotz Lastwiderstände 5,3V und 11V raus. Die 11V
sind ja egal, werde wohl eh nie einen 6551 verwenden. Aber 5,3V?
Leider kann man nichts einstellen...
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.
Leo war ein µ schneller :-)
Meinen Werten lag die folgende Überlegung bei 3.3V zugrunde:
rot (1.6 V Flussspannung) 7 mA - 270 Ohm
grün (2.1 V Flussspannung) 8 mA - 150 Ohm
Moin!
Ist eigentlich noch ein satz Platinen verfügbar, wenn ja meld ich mal
gesteigertes Interesse an. Da ich hier nicht angemeldet bin mal bitte
unter Random-0123 at gmx.de melden.
Bei mir klappt es auch nicht so recht....
Zunächst eine Anmerkung (vielleicht habe ich das auch überlesen): Die
Beschriftung für die AVR/Z180-Stamps ist auf der ECB verkehrt herum.
Wenn man die Stamps so einsetzt, dass die Schrift auf den Stamps der
Schrift auf dem Basisboard entspricht, sind sie verkehrt drin. Zum Glück
hatte Joe ein Bild eingestellt, so dass mir das irgendwann aufgefallen
war (nix ging).
Dann ist die Beschreibung / Abbildung für JP1 kritisch. Wenn man die
Platine vor sich hat und dann die Jumpereinstellung auf dem Schaltplan
anschaut, dann ist das auch spiegelverkehrt. Wahrscheinlich ist der
Schaltplan und die Jumperbeschreibung richtig, aber der Jumper sitzt auf
der Platine anders als man denkt...
Tip: In der nächsten Charge einen Platinenaufdruck vorsehen :-)
Nach einem Missgeschick, bei dem ich mir die USB Buchse abgerissen
hatte, ging es dann weiter.
Die AVR Stamp antwortet nun wie gewohnt - aber die Kommunikation zur
Z180 scheint nicht zu gehen. Ich habe unten mal das bootlog angehängt.
WAIT (LED2) leuchtet IMMER rot.
DuoLed wechselt beim Boot von gelb nach grün.
Druck auf Z-Reset bewirkt, dass die DuoLed kurz gelb und dann wieder
grün ist.
Dass ein Lesefehler kommt, ist komisch. Ich kann problemlos auf die
SD-Karte zugreifen.
Der Test mit dem mw 0 76 80000 steigt mit Bus-Fehler aus.
Auf meiner Lochraster-Platine (da geht noch alles) hatte ich einen
Jumper für Pin 2 (A17) nach GND. Das geht ja auch mit pin 2 low. Macht
aber keinen Unterschied.
Irgendwas mache ich falsch - wieso ist WAIT immer an?
Hinweise: Ich habe auf der Z180 Stamp noch einen Quarz, da ich bislang
diesen genutzt hatte. Aber auch wenn ich den per Jumper deaktiviere
zeigt das keine Änderung
> 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
> - 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
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 :-)
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.
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
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.
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?
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.
> 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_DanneggerBeitrag "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
> (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.
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 ;-)
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.
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
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!
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...
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.)
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
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?
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.
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
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&
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:
### 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:
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.
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).
### 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...
### 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.
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...)
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;
> 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?
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.
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.
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.
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!
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.
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.
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.phphttps://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?
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?
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.
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.
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.
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.
> 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?
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?
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.
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?
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.
> => 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.
...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.
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.
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:
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 :-)
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?
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
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
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)
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?
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..<.
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
> ...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.)
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:
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!
|<===> 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:
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 PC1715Leo 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
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
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
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.
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".
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
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).
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
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:
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.
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.>>
>
..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:
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.
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.
..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:
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
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.
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:
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
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>
> 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.>
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
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.
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..
> 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.
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 .|
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
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.
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>
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
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.
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
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.
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:
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.
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...!
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 :-)
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.
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.
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.
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.
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
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
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.
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
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;
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.
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:
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?
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
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:
> 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.:
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
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...
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
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, ... :)
:-)
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
> - 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.
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.
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)"]]
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 6AVR 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>
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.
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.
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}'
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.
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...
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…
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) :-(
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
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
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.
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?
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.
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
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
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
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
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.
..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:
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.
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:
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
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.
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,
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.
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
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
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'.
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