Und das die vom Z80, weil der Schaltplan noch nicht fertig ist... da wird erstmal nur Basisverdrahtung gemacht, Vcc, Gnd usw.
Christian J. schrieb: > Leider muss man > dabei aber oben mehr Abstand lassen da die Kämme 2 Lochreihen für sich > brauchen. Der grosse Nacteil ist, dass Falsche Verdrahtungen nicht mehr > lösbar sind, da du den Draht nicht mehr rausziehen, nicht mal > identifizieren kannst. Da hilft nur abschneiden am Pin und neuen ziehen, > den alten drin liegen lassen. Und bei Fehlern suchst Du dir einen Wolf, weil Du die Drähte ja nicht verfolgen kannst. Dazu kommt noch das Übersprechen, wenn die Drähte über lange Strecken parallel liegen. Ohne die Kämme erreichst Du eine wesentlich höhere Packungsdichte, kannst jede einzelne Verbindung wieder finden, und hast deutlich reduziertes Übersprechen. Da ist ein Beispiel: Beitrag "Re: z80 system" Beitrag "Re: z80 system" Mit Kämmen hätte das nie auf eine Eurokarte gepasst, und die 16 dynamischen RAMs hätten wahrscheinlich nicht funktioniert.
Leo C. schrieb: > A.K., von wann sind denn Deine TTL-Schinken? Bei mir ist das nur ein > Band "Fifth European Edition 1982", 4cm dick. TI Vol 1, 74/74S/74LS: 1983, 6. Ausgabe TI Vol 2, 74AS/74ALS: 1983/84, 7. Ausgabe Motorola 74HC(T) von 1984 Valvo HEF4000 von 1980
Christian J. schrieb: > Das ist alles schon gut durchdacht und der STI hat "3 in 1" mit 40 Pins > statt " 3 in 3" mit 100 Pins. Sehr luftig. Geht auch anders, ebenfalls Retro (bis auf den zentralen Taktgenerator), mit dem RCA 1802: Beitrag "Re: Zeigt her Eure Kunstwerke !" Sehr praktisch ist, dass man ohne ROM auskommt. Die UART ist hier ein AY-3-1015 und die ist ganz nach deinem Geschmack, weil im Programm völlig ohne Konfiguration auskommt. ;-)
:
Bearbeitet durch User
Leo C. schrieb: > Und bei Fehlern suchst Du dir einen Wolf, weil Du die Drähte ja nicht > verfolgen kannst. Dazu kommt noch das Übersprechen, wenn die Drähte über > lange Strecken parallel liegen. > > Ohne die Kämme erreichst Du eine wesentlich höhere Packungsdichte, > kannst jede einzelne Verbindung wieder finden, und hast deutlich > reduziertes Übersprechen. Ich finds so aber schöner .... http://www.mikrocontroller.net/attachment/93660/z180_3.JPG Und da ich eh Brille trage und mit Lupe arbeite muss es nicht so extrem werden. Lieber etwas luftiger. Und Übersprechen hatte bei den bisschen Megahertz noch nie.
Ich bin ja mittelmäßig über das Interesse an Retrodesigns beeindruckt. Da die Frage nach einem Terminal aufkam. Christian J. schrieb: > Gibt es vielleicht noch Bausätze fix und fertig für Z80 Maschinen mit > einer Art Bildschirm und Tastatur? Da kann man ja was Modernes nehmen. Im AVR CP/M Projekt ist damals eine Variante mit VT100 Terminal entstanden. Beitrag "Re: CP/M auf ATmega88" Eine abgespeckte reine VT100 Terminal Version wandert bei mir gerade in ein kleines Gehäuse um an der VESA Aufnahme an einem handelsüblichen Monitors befestigt zu werden. Es wird also nur noch eine Tastatur angesteckt und fertig ist das Terminal. Die Schnittstelle ist derzeit USB und erhält gerade noch eine echte RS232. Der Code ist frei und darf gerne weiterentwickelt werden. Beitrag "Re: CP/M auf ATmega88" Vielleicht hat ja jemand Interesse daran…
A. K. schrieb: >> 1. Ich will kein Gattergrab erzeugen, was leider sehr schnell geht. >> Reicht ein 74HCT138 aus, um 3 I/O Bausteine zu decodieren? Wie schon mal geschrieben: Bei den wenigen IO Bausteinen, die du hast, ist ein extra Dekoder völlig überflüssig. Häng einfach jeden /CS an eine andere Adressleitung, angefangen mit A7 und dann abwärts. Damit kannst du 4 Bausteine bequem sortieren und hast noch jeweils die unteren 4 Adressen frei für interne Register.
Christian J. schrieb: > Moment.... ohne da jetzt nachgeschaut zu haben..... "schneller ist > besser"? Man sollte da vorsichtig sein. Prinzipiell werden HCT gehen. Aber wenn du eine Interruptsteuerkette benutzt, kommt es auf die Laufzeiten der Gatter an. Da wurden schon mal ein paar eingebaut, um ein paar ns zu verzögern. Und 1985, seitdem werden keine Logikschaltkreise dazugekommen sein. Im Moment habe ich auch 20ns CMOS-RAM im Verdacht, das sie in alten 80C31 Schaltungen Probleme machen. Eigentlich sind da ursprünglich 150ns eingebaut.
Michael_ schrieb: > Aber wenn du eine Interruptsteuerkette benutzt, kommt es auf die > Laufzeiten der Gatter an. Da wurden schon mal ein paar eingebaut, um ein > paar ns zu verzögern. Yep. Aber bei einem einzigen STI...
Zum Z80 STI (Mostek MK3801) hier ein deutliche besser gescanntes Datenblatt http://schuetz.thtec.org/mccomputer/Mostek%20-%20MK3801%20-%20Serial%20Timer%20Interrupt%20Controller.PDF (Achtung: 10 MByte) Das ist vorteilhaft auch "textdurchsuchbar" in der PDF, nicht nur Grafik. Gruss
Dass die IEI/IEO-Kette bei steigender Länge (typ mehr als 4 Devices in der Chain) irgendwann Ärger macht ist richtig. Da gab es 2 Möglichkeiten: Waitstates im IACK Zyklus, oder den IEI/IEO Durchlauf der langsamen ICs mittels externer Gatter zu beschleunigen. Doku dazu, in traumhaft schönem Retro-Design: http://www.z80.info/zip/z80-interrupts.pdf
:
Bearbeitet durch User
Christian J. schrieb: > In einem Kamm kann ich ca 30-40 Drähte parallel führen. VeroWire-Fädeltechnik ist eine feine Sache, aber lass bloss diese Plastikkämme weg! In den parallel geführten Drähten gibt es dermassen viel Übersprechen, dass Dein Z80 wahrscheinlich schon bei 4 MHz aussteigen wird. Anarchieverdrahtung ist angesagt, d.h. die Drähte mit ein paar Millimetern Überlänge per Luftlinie führen. Das sieht dann später aus wie eine noch nicht entflochtene Platine in der Guide- bzw Ratsnest-Ansicht. Masseleitungen kann man vorher als Gitter mit 0,6 mm-Silberdraht ausführen.
Erich schrieb: > Zum Z80 STI (Mostek MK3801) hier ein deutliche besser gescanntes > Datenblatt > http://schuetz.thtec.org/mccomputer/Mostek%20-%20MK3801%20-%20Serial%20Timer%20Interrupt%20Controller.PDF > (Achtung: 10 MByte) > Das ist vorteilhaft auch "textdurchsuchbar" in der PDF, nicht nur > Grafik. Danke, das mit den weißen Pilz-Geflechten links hatte ich schon gefunden. Und das wird erst so richtig Retro, wenn man auf Ökopapier ausdruckt und nen Kaffee drüber kippt :-) Habe denn Rat angenommen, IC Fassungen nochmal raus, Kämme auch und alles enger zusammen. Gegen die Kämme ist nichts zu sagen, damit laufen andere auch. Und daher bleiben sie drin. Bei meinem Röhrenamp war Durcheinander auch besser wegen der Brummstörungen die ein "geordnetes Design" sich einfängt aber hier wird es ordentlch und Chuck Norris macht keine Fehler beim Verdrahten.... die Drähte legen sich vor Angst von allein an den richtigen Pin! ;-)
Michael_ schrieb: > Im Moment habe ich auch 20ns CMOS-RAM im Verdacht, das sie in alten > 80C31 Schaltungen Probleme machen. Kann schon sein. Aber wohl weniger des Timings wegen, sondern weil die Power-Transienten die Abblockung überfordern oder weil die Flankenwechsel an 8 parallelen Datenleitungen die Verdrahtung überfordern. Die Flanken sind halt etwas fixer als bei den 450ns RAMs der 8041-Ära. In diesem Sinne auch Gruss an Christian mit seinen Fädelkämmen. ;-)
Moin, hoffe mal das ist so richtig, mehrere Wege führen nach ROM: Adressdecodierung ROM/RAM: A13 v A14 v A15 => CE/-ROM und CE-RAM (74HCT32) ROM = 0x0000 - 0x1FFF RAM = 0x2000 - 0x7FFF I/O: Z80 STI (24 register) + 8255 (4 Register) + ADC0804 (1 ro Register) Adressdecodierung I/O über 74HCT138 (3 zu 8 Muxer) Q3 11 = CS(ADC0804) A7 --> Q2 10 = CS(8255) - 74HCT138 Q1 01 = CS(Z80 STI) A6 --> Q0 00 = unbenutzt A3,A2,A1,A0 => Z80 STI (A0,A1,A2,A3) A1,A0 => 8255 (A0,A1) Memory Map 0x40 - 0x57 Z80 STI 0x80 - 0x83 8255 0xC0 - 0xC0 ADC0804 Ok?
> Ok?
Kommt drauf an.
Was ist mit den anderen 4 Eingängen vom '138?
Leo C. schrieb: >> Ok? > > Kommt drauf an. > > Was ist mit den anderen 4 Eingängen vom '138? Der 138 hat nur 3 Decoder Eingänge, brauchen tue ich aber nur 2 und am Ausgang 4, Q0 muss frei bleiben. Und ein EN kommt an IOREQ vom Z80.
> Der 138 hat nur 3 Decoder Eingänge, brauchen tue ich aber nur 2
Gibst Du den 3. an den Händler zurück?
Wie bitte? Das ist ein straight forward Decoder, da geht nix zurück. Nr.3 wird tot gelegt auf 0, so dass nur 4 Zustände decodiert werden für maximal 3 Devices. Bin nur unschlüssig, ob Q0 frei bleiben muss. E1/ macht ja die Freigabe über IOREQ.
Ich grüble nur grad nach, ob das so alles mit dem Timing und dem Fan-Out hinhaut. Mehr als 3 IO würden schon sicher einen Bustreiber bedeuten an D0-D7 . Und auch von den Laufzeiten her muss das passen. 107ns ist (26). Von Adress anlegen bis IOREQ kommt. Rotz, hat mal einer ein besseres Datasheet der alten B Variante vom Z80.....
> Wie bitte? Das ist ein straight forward Decoder, da geht nix zurück. Sorry, ich wollte meinen "Artikel" nochmal ergänzen, hatte aber ein Problem hier. > Nr.3 wird tot gelegt auf 0, so dass nur 4 Zustände decodiert werden für > maximal 3 Devices. Auf 0 legen ist schon mal besser als nix, bzw. offen lassen. > Bin nur unschlüssig, ob Q0 frei bleiben muss. Warum sollte der frei bleiben müssen. Wenn Eingang C auf GND liegt, kannst Du die ersten 4 Ausgänge beliebig verwenden. Wenn Du nur 3 brauchst, kannst Du sie Dir aussuchen. > E1/ macht ja die Freigabe über IOREQ. (In meinem Datenblatt heißen die Enable-Eingänge G1, G2A und G2B) /IOREQ auf G2A (oder G2B). Auf G1 solltest Du /M1 legen, da während des Interrupt Acknowledge Cycle /IOREQ und /M1 low sind. Ich würde allerdings A7 auf G2B legen, und A4, A5, A6 auf A, B, C. Kostet nichts, und die Adressen werden besser ausdekodiert. Vorteilhaft bei Erweiterungen, und Amok laufende Programme treffen seltener eine gültige Adresse.
Leo C. schrieb: > Auf G1 solltest Du /M1 legen, da während des Interrupt Acknowledge Cycle > /IOREQ und /M1 low sind. /M1 ist mir noch etwas ein Rätsel. Was soll der bei der Decodierung der I/O denn mitmischen? Ist nicht im Diagramm des I/O Zyklusses drin. Nur beim INT Acknowledge. Und M1 liegt brav am M1 der Z80 STI dran, nicht abe am Decoder.
1 | Interrupt Request/Acknowledge Cycle |
2 | |
3 | Figure 9 illustrates the timing associated with an interrupt cycle. The CPU |
4 | samples the interrupt signal (INT) with the rising edge of the last clock at the |
5 | end of any instruction. The signal is not accepted if the internal CPU |
6 | software controlled interrupt enable flip-flop is not set or if the BUSREQ |
7 | signal is active. When the signal is accepted, a special M1 cycle is |
8 | generated. During this special M1 cycle, the IORQ signal becomes active |
9 | (instead of the normal MREQ) to indicate that the interrupting device can |
10 | place an 8-bit vector on the data bus. Two wait states are automatically |
11 | added to this cycle. These states are added so that a ripple priority interrupt |
12 | scheme can be easily implemented. The two wait states allow sufficient time |
13 | for the ripple signals to stabilize and identify which |
14 | I/O device must insert the response vector. Refer to Chapter 6 for details on |
15 | how the interrupt response vector is utilized by the CPU. |
Christian J. schrieb: > Memory Map > 0x40 - 0x57 Z80 STI > 0x80 - 0x83 8255 > 0xC0 - 0xC0 ADC0804 Das ist keine Memory Map, sondern eine I/O Map. > Ok? Nicht Ok. Ein Interrupt-Acknowledge-Zyklus legt dir /IORQ auf Low und aktiviert damit ein zufälliges I/O-Gerät. Doofe Sache, sowas. ;-) So schwer ist der '138er nicht: Nichtinvertierendes Enable an /M1. Zwei Invertierende Enables an /IORQ. Drei Eingänge an A7 bis A5. Fertig. Damit hast du acht (ACHT!) Chip-Enables, die deinen I/O-Adressraum im 32er-Raster sauber aufteilen, und nicht alle davon werden benutzt. Erspart dir offene Eingänge. An die Peripherie selbst kommen dann A0..A4 (je nachdem, was du brauchst), D0..D7, /RD, /WR und der entsprechende Ausgang vom '138 an /CE. Dein Bild ist grausam. Besorge dir das normale Manual vom Z80 von Zilog, das sind bessere Diagramme drin. Dein (26) besagt, dass wenn /IORQ fällt, die Adresse gültig ist und du sie latchen darfst (Setup-Zeit ist 100 ns), und die Adresse auch für den ganzen Zyklus gültig bleibt (Hold-Zeit). Da ein I/O-Zyklus immer auch einen zusätzlichen Wartezyklus beinhaltet, brauchst du dir da eigentlich keine Sorgen machen.
> Was soll der bei der Decodierung der I/O denn mitmischen? Es soll verhindern, daß während des IntAck Cycles Deine Peripherie selektiert wird. Während dieses Cycles liegen mehr oder weniger zufällige Daten auf dem Adressbus, IORQ ist low, M1 aber auch. > Und M1 liegt brav am M1 der Z80 STI dran, nicht abe am Decoder. M1 liegt aber z.B nicht am 8255 an. Z80-Peripherie-Bausteine mögen den IntAck selber erkennen. Der 8255 kann das aber nicht. Du mußt verhindern, daß der decoder I/O-Selects generiert, wenn M1 aktiv ist. /E1 /E2 E3 /IOREQ A7 /M1
:
Bearbeitet durch User
Hier gibts die Datenblätter: http://www.zilog.com/index.php?option=com_product&Itemid=26&task=docs&businessLine=1&parent_id=139&familyId=20&productId=Z84C00 Du brauchst (mindestens) PS0178 und UM0080.
Hi, ich danke euch, ist klar jetzt. So langsam fängt es an Spass zu machen, auch wenn es sehr ungewohnt ist wenn man seit Jahren nur noch Controler verwendet hat wo alles drin ist. Bin noch dabei und habe in meinen umfangreichen Settkästen einen CD4060 gefunden, der vielleicht mit einen 32khz Quarz einen 1s Takt erzeugen könnt für "irgendwas sinnvolles" und einen SN74245 Bus bidirektionalen Treiber. Ist wahrscheinlich Mumpitz aber an Halt sitzt eine Low Power LED dran und ich überlege ob man irgendwas sehen würde, wenn man die D0...D7 oder andere Signale auf 8 LEDS führen würde. Wahrscheinlich würden sie aber nur flimmern und glimmen und das war es. Mal spasseshalber: Leite ich das Signal des Quarzoscillators auf einen CD4020 um, schalte dahinter einen Inverter als Treiber (4020 dürfte zu schwach sein die Z80 zu treiben), so komme ich nach 14 Stufen auf minimal 225 Hz. fmax des 4020 bei 5V sind 4 Mhz, passt also. Sagen wir der Z80 würde mit 10 khz getaktet, vorrausgesetzt er hat ein voll statisches Design, würden dann die anderen Bausteine noch arbeiten? (außer dem ADC080), so dass man mit Leds die Bits sehen könnte?
Leo C. schrieb: > Auf G1 solltest Du /M1 legen, da während des Interrupt Acknowledge Cycle > /IOREQ und /M1 low sind. Schadet nichts, nützt aber auch nichts. S. R. schrieb: > Nicht Ok. Ein Interrupt-Acknowledge-Zyklus legt dir /IORQ auf Low und > aktiviert damit ein zufälliges I/O-Gerät. Doofe Sache, sowas. ;-) Im IACK bleibt RD inaktiv, weshalb ein mögliches CS von den Bausteinen ignoriert wird.
:
Bearbeitet durch User
Christian J. schrieb: > Sagen wir der Z80 würde mit 10 khz > getaktet, vorrausgesetzt er hat ein voll statisches Design, Der Z80 hat ein vollständig statisches Design.
Christian J. schrieb: > Mehr als 3 IO würden schon sicher einen Bustreiber > bedeuten an D0-D7 Gerechnet, geraten oder gelesen? Würde mich auch interessieren, wo die Grenze ist. Und wenn, dann betrifft die nur die I/O-Zugriffe, da neben dem RAM auch das verwendete ROM viel schneller sein dürfte als damals üblich.
:
Bearbeitet durch User
>Der Z80 hat ein vollständig statisches Design. Ja. Daher gab es auch schon immer die "Bus-Monitor" Schaltungen. Zwecks Retro-Design unbedingt mit dem TIL311 (nervenstarke Netzteile sind dann Pflicht). http://www.s100computers.com/My%20System%20Pages/SMB%20Board/S100%20Bus%20SMB.htm Mit den Comparatoren kann man eine beliebige Adresse (/MREQ) oder IO-Zugriff (/IORQ) einstellen, wahlweise zusätzlich qualifiziert mit /RD oder /WR. Sobald die Adresse erreicht wird bleibt die ZPU stehen! Dann kann man mit dem Single-Step-Taster wirklich jeden einzelnen Zyklus weitertasten. Recht lustig bei 4-Byte-Befehlen wie RRC (IX+33) etc. Praktisch ist das dann ein Logicanalyser für Arme. Dies nur zur Info. Für das Projekt hier ist es jedoch nicht zielführend; später mal was grösseres bauen... Wenn ich heute Abend mal in meinen Kellerspeicher (wörtlich!) komme, suche ich mal meinen uralten Aufbau mit dem Z80 STI raus. Anno 1982 oder sorum, mit kreuz-und-quer Kupferlackdrähten von irgendeinem Trafo abgewickelt. Nix mit Fädelkämmen oder so' Zeug, das nimmt vielzuviel Platz weg, wie schon gesagt wurde. Und macht die Fehlersuche schwer. Praktische Tips: Sinnvoll ist es, das Schaltbild bzw. ALLE PINS JEDES Bauteils auszudrucken und nach den löten durchzupiepsen. Insbesondere auch darauf, daß Pins nicht mit benachbarten links/rechts verbunden sind (wo's nicht sein soll). Jeden Pin jedes Bauteils mit Markerstift auf der Liste abstreichen wenn ok. Auch darf kein Pin offen sein. Unbenutze nach Gnd oder auf eine "+Pullup" Lötinsel über 10k. Bei Beginn Verdrahtung mit GND und VCC (+5) beginnen; diese über Silberdraht. Einen 100nF an jedem IC z.B. unter dem Sockel "schräg". Smd-Cs wären einfacher, sind aber eher kein Retrodesign. Gute Laborplatine FR4 einsetzen, die sind doch stabiler als Hartpapier. Wie weit ist das Schaltbild? Gruss
TIL311? Sowas habe ich zu DDR Zeiten mal als Einsteckkarte für den K1520 Bus gebaut, mit "gewöhnlichen" 7 Seg anzeigen, einem U40511 und diversen Multiplexern. Die Steuersignale gingen auf Status-LEDs. Traurigerweise habe ich das irgendwann mal verschenkt... Der Nutzeffekt war aber damals nicht all zu hoch, da in den Rechnern dynamische RAMs werkelten die einen Refresh brauchten, da war nicht viel mit Schrittbetrieb. Gruß, Holm
Erich schrieb: > Wie weit ist das Schaltbild? Ich bin noch dabei, muss est den STI noch zeichnen, da es den nicht gibt bei eagle. Ich habe den M1 jetzt mit reingenommen und 1 zu 8 decodiert und alle Ves angeshclossen. Natürlich mache ich es auch so, nach em Löten wird alles gepiepst und danach ohne IC Strom angelegt und geschaut ob der da ist wo er hin soll. Oszi werkelt auch schon, mit dem 25 Euro Logix Analyszer von ebay kann man schon was machen. Bis später... heute nacht gehts weiter. Ich werde noch eine Taktreduzierung mit einbauen mit dem 4020, die per Dip/Jumper etc umsteckbar ist. >>Gerechnet, geraten oder gelesen? Würde mich auch interessieren, wo die >>Grenze ist. Und wenn, dann betrifft die nur die I/O-Zugriffe, da neben >>dem RAM auch das verwendete ROM viel schneller sein dürfte als damals >>üblich. Hängt vom Fan-Out und von den Kapaizitäten und Frequenzen ab. Müsste man wohl eher ausprobieren oder Ersatzschaltbild zeichnen und rechnen wo die Grenze liegt und bei welcher Frequenz. Wahrscheinlich gibt Jehova Rufe aber da wird noch ein AVR an den Steuer-Bus mit drankommen, der die Signal "mono-flopped" und zwar so dass man es sehen kann auf den LEDs.
>da in den Rechnern dynamische RAMs werkelten
Ja, das war leider so bei üblichen "simplen" CP/M Designs. Anders bekam
man ja 16k oder gar 64k Ram nicht auf 'ne kleine Europaplatine
(100x160).
In dem Betrieb wo ich mein Praxissemester machte Anfang der 80er, da
wurden allerdings Industriesteuerungen gebaut, im Doppeleuropaformat
(160x230). Da ging schon mehr drauf.
Kaum daß das statische Ram 2kx8 Cmos (6116) erfunden war, wurde eine
Leiterplatte entworfen mit 16 Stück drauf! Stückpreis des 2k Rams damals
ca. 40 Mark (pro Stück).
32 kByte statisches Ram auf EINER Platine, das hatte die Welt noch nicht
gesehen... Zwei Karten davon in das Rack, 64k, mit
Eprom-Ausblendungsmöglichkeit (umschaltbar), das war der erste Schritt
um die Industriesteuerung CP/M kompatibel zu machen. Kurz später haben
wir einen Floppycontroller dazugebaut, von 'ner S100 Platine
nachempfunden, aber das ist 'ne ganz eigene Geschichte.
Gruss
A. K. schrieb: > Schadet nichts, nützt aber auch nichts. Stimmt, war wohl schon zu früh. > Im IACK bleibt RD inaktiv, weshalb ein mögliches CS von den Bausteinen > ignoriert wird. Bei seinem jetzigen Plan stimmt das. Wenn er aber doch noch Peripherie ohne 8080-Bus-Interface anschließen sollte, wirds mit M1 auf dem Decoder einfacher. Z.B. könnte er an einen der Selects ein FF (oder gleich ein 8 Bit breites Latch) anschließen, um das EPROM abschalten zu können. Erich schrieb: > Daher gab es auch schon immer die "Bus-Monitor" Schaltungen. > Zwecks Retro-Design unbedingt mit dem TIL311 (nervenstarke Netzteile > sind dann Pflicht). Stimmt auch. Das A-Meter im Bild zeigt nur den Strom der Display-Platine. Der Rest (Z8S180, 512K RAM, ATmega1281, FT232RL) braucht knapp 50 mA bei jeweils 18,432MHz.
Erich schrieb: >>da in den Rechnern dynamische RAMs werkelten > Ja, das war leider so bei üblichen "simplen" CP/M Designs. Anders bekam > man ja 16k oder gar 64k Ram nicht auf 'ne kleine Europaplatine > (100x160). > In dem Betrieb wo ich mein Praxissemester machte Anfang der 80er, da > wurden allerdings Industriesteuerungen gebaut, im Doppeleuropaformat > (160x230). Da ging schon mehr drauf. Hmpf...die Rechner von denen ich redete (K1520) waren nicht simpel und auch nicht auf Europaformat, sondern auf DDR Standard K1520 mit 170x215 mm. Das war Industriehardware. Die DDR "Europaformat" Platinen waren 170x95 oder 170x215mm in den Abmessungen, Raster war metrisch 2,5mm genauso wie die dazugehörigen Steckverbinder. > > Kaum daß das statische Ram 2kx8 Cmos (6116) erfunden war, wurde eine > Leiterplatte entworfen mit 16 Stück drauf! Stückpreis des 2k Rams damals > ca. 40 Mark (pro Stück). > 32 kByte statisches Ram auf EINER Platine, das hatte die Welt noch nicht > gesehen... Zwei Karten davon in das Rack, 64k, mit > Eprom-Ausblendungsmöglichkeit (umschaltbar), das war der erste Schritt > um die Industriesteuerung CP/M kompatibel zu machen. Kurz später haben > wir einen Floppycontroller dazugebaut, von 'ner S100 Platine > nachempfunden, aber das ist 'ne ganz eigene Geschichte. > Gruss Der damals übliche Floppycontroller bestand aus Schieberegistern (7495), 2 Eproms (2708) mit Marken-Mustern und 2 PIOs und wurde meistens im DMA Betrieb (durch eine 2. CPU, keine Z80-DMA) gefahren. :-) Gruß, Holm
Hallo! Etwas Funktionsfähiges könnte auch so aussehen: #Toshiba TMPZ84C015AF6 mit "nur" 4,9 MHz #32K EPROM (Monitor, BASIC, BDOS, CCP ,BIOS) #64K RAM #480K RAM-Floppy "Gold-Akku" gepuffert #7 x 8M (CF-)"Harddisc" #Kassetten-Interface #eigenes BIOS #Kompatibilität: bisher läuft Alles u.a. TP3.01A
Schnelle Zischenfrage: Ein 3,6V Pufferakku übe eine Diode abgekoppelt von den 5V und mit Ladevorrichtung über Wierstand (10mA), würde der über das Ram die ganze restliche Schaltung mitversorgen? Ich weiss nicht wie sich stromlose Bausteine verhalten, wenn diese um einen guppiert sind, der 3V anliegen hat. PS: Der 2764 zieht 40mA Ruhestrom und 70mA Betrieb.... um die Stromrechnung brauchte sich wohl keiner damals Gedanken machen. In einem Zeitalter wo ein uC 5mA zieht ist das schon ..... bombatisch.
Christian J. schrieb: > Ein 3,6V Pufferakku übe eine Diode abgekoppelt von den 5V und mit > Ladevorrichtung über Wierstand (10mA), würde der über das Ram die ganze > restliche Schaltung mitversorgen? Ich weiss nicht wie sich stromlose > Bausteine verhalten, wenn diese um einen guppiert sind, der 3V anliegen > hat. Was für ein RAM-Chip ist es denn? Da war doch was mit 20ns - was nach Cache-RAM klingt, und sind nicht grad stromsparend. Ansonsten ist es nur CE=Vcc(RAM) wichtig.
:
Bearbeitet durch User
Hallo! Das gepufferte RAM ist ein 512Kx8 Low Power CMOS, wird über einen MAX691 Supervisor geschaltet und mit dem 1F GoldCap bleibt sein Inhalt locker drei Wochen erhalten, auch wenns rechnerisch wahrscheinlich nicht hin kommt. Für lange Speicherzeiten ist eh die Flash-Card da.
Wenn ichs richtig sehe, ist das RAM ein AS6C4008-55PCN. Also ein 512Kx8 mit 55ns Zugriffszeit. Für den guten alten Z80 auch nicht schlecht. Zum Puffern reicht auch eine billige 3V Knopfzelle. Allerdings wärs wohl besser, wenn Christian erst mal sein Grundsystem ans Laufen bringt.
>Ein 3,6V Pufferakku Prinzipiell solltest du dich weniger mit solchen gimmicks befassen. Vieles ist machbar, aber kaum alles gleichzeitig auf einer "einfachen" Platine. Mit deinem Taktkram bin ich schon skeptisch. Und die Ram-Bufferung funktioniert wirklich nur zuverlässig mit so'nem Maximchip; die hat ursprünglich Dallas Semiconductor erfunden, z.B. den DS1210. Maxim hat die Firma dann später aufgekauft. Und "low current" cmos, keine cacherams; also z.B. HM62256 (32k) oder HM628128 (128k). Programme debuggen im Ram kann sowieso das Ram selbst ruckzuck überschreiben, muss man also was richtig nonvolatile haben. Flash oder neu laden von RS232/PC. Ich würd' eher über so'n kleinen modernen 8-Pin serielles Flash nachdenken, das kann man an die Pio hängen und es nimmt wenig Platz weg. Die "Load/Loadgo" Routinen dafür kann man ins normale Eprom leicht unterbringen. Jedenfalls viel einfacher als "echte" Flashchips oder gar SD-Karten. Microchip 25LC1024 in DIP8 oder was von STM (dort aufpassen auf +5V und Gehäuseform). Allerdings sollte man 32k normales Eprom vorsehen (27C256) und ggf. eine Eprom-Ausblendemöglichkeit falls man 128k Ramchip einbaut (und nur zu 64k nutzt). Gruss
Erich schrieb: > Und die Ram-Bufferung funktioniert wirklich nur zuverlässig mit so'nem > Maximchip; Nö. Sowas hat man schon gemacht, bevor es solche Chips gab. Aber ich gebe Leo recht. Der Kram soll erst einmal ohne Gimmicks funktionieren. Lötpunktraster nachträglich anzupassen ist nicht sonderlich schwierig.
:
Bearbeitet durch User
Erich schrieb: > Die "Load/Loadgo" Routinen dafür kann man ins normale Eprom leicht > unterbringen. Tja, bei einer Retro-CPU mit eingebautem Bootloader hat man es eben etwas leichter. ;-) Wobei man sich natürlich auch den Spass machen kann, das EPROM komplett wegzulassen und einen AVR mit seinen Ports an den Bus zu hängen. Der krallt sich den Bus und füllt das RAM. Bei einem 40-Pinner fällt das nicht weiter auf, wenn man die Beschriftung durch "Z80 LDR" ersetzt.
:
Bearbeitet durch User
@prx >>> Und die Ram-Bufferung.. >Nö. Sowas hat man schon gemacht, bevor es solche Chips gab. Meine Erfahrung zeigte was anderes. Mag' aber sein daß es mit ausgesuchten Ramtypen eines Herstellers ging. Hat man "6264" Typen kreuz und quer eingekauft gings schief. >Retro-CPU Ein Z80 sollte der Chef auf der Platine sein. Sonst isses kein Retro. Dulden könnte man bestenfalls eine DMA. Da aber dem TE bereits die SIO schon zu kompliziert vorkam ist das kein Thema hier. Und ausser für DD floppy braucht sie nicht wirklich. Gruss
A. K. schrieb: > Wobei man sich natürlich auch den Spass machen kann, das EPROM komplett > wegzulassen und einen AVR mit seinen Ports an den Bus zu hängen. Der > krallt sich den Bus und füllt das RAM. Genau das wird hier realisiert: Beitrag "Re: Retro Fieber: Z80 oder 68000 ?"
Erich schrieb: >>Nö. Sowas hat man schon gemacht, bevor es solche Chips gab. > Meine Erfahrung zeigte was anderes. Dann deutlicher: Ich habe es gemacht, an einem 68000 System, mit NiCd Akkus. Frag mich nicht mehr, mit welcher Spannung, die muss natürlich zum RAM passen. Wobei das vor 3 Jahrzehnten nicht Retro war, sondern Stand der Technik. Die EPROM-Brennerei war mir zu blöd. > Mag' aber sein daß es mit ausgesuchten Ramtypen eines Herstellers ging. Die sind dabei völlig schnurz. Entscheidend ist, dass CE entsprechend kontrolliert wird. Wenn CE=Vcc(RAM), dann brennt da nix an. > Ein Z80 sollte der Chef auf der Platine sein. Wäre er ja auch, nachdem sein RAM den Inhalt hat. Wenn man einen Loader für ein ROM entwickelt hat, dann kann man den AVR ja wieder rausziehen > Da aber dem TE bereits die SIO schon zu kompliziert vorkam ist das kein > Thema hier. OK, überzeugt. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Wobei man sich natürlich auch den Spass machen kann, das EPROM komplett > wegzulassen und einen AVR mit seinen Ports an den Bus zu hängen. Der > krallt sich den Bus und füllt das RAM. Tja, dazu gab es zwei Vorschläge hier zum dranhängen/mitmachen/ nachbauen. Beitrag "eigenes Z80 Mainboard - geht das so?" Beitrag "Z180-Stamp Modul" > Bei einem 40-Pinner fällt das > nicht weiter auf, wenn man die Beschriftung durch "Z80 LDR" ersetzt. Unter dieser Bedingung fällt der 2. Vorschlag allerdings weg (64 Pin QFP). Erich schrieb: > Ein Z80 sollte der Chef auf der Platine sein. Sonst isses kein Retro. > Dulden könnte man bestenfalls eine DMA. "Retro Modern" ist auch eine schöne Sportart.
Anbei schonmal eine eagle lib mit dem Z80 STI, wer Spass dran hat.... Und weiter gehts .... wurschtel
Wie heißt Dein RAM genau? Der Schaltplan paßt nicht zu meiner Behauptung, es sei ein AS6C4008-55PCN.
Route 66 schrieb: > Etwas Funktionsfähiges könnte auch so aussehen: > #Toshiba TMPZ84C015AF6 mit "nur" 4,9 MHz Hättest aber auch schreiben können, das das der CEPAC-80 ist. Wurde konstruiert von Stefan Wimmer und erschien in der c't 8/88: http://www.oocities.org/capecanaveral/6368/cepac_ct.html Genau das Dings hat jahrelang meinen SAT Empfänger gesteuert. Das schöne ist die kompakte Toshiba CPU mit allen Z80 Peripherien, die man so braucht, wie oben schon öfter erwähnt. Ich glaub' sogar, ich hab noch ein oder 2 CPU hier rumliegen... Hier ist übrigens 'ne nette Seite mit Z80 Basteleien: http://z80.info/homebrew.htm
:
Bearbeitet durch User
So, mir tun die Augen weh..... Rohbau steht, Details und Fehler müssen noch beseitigt werden. Einige Leitungen weiss ich auch noch nicht was damit tun. RAM ist ASC61008 laut Aufschrift.
A. K. schrieb: > Da fehlt aber noch ziemlich viel. Heute nicht mehr .... ich frage mich welcher Depp das alles verdrahten soll... finde hier keinen. Grobe Fehler vielleicht mal anführen, nicht verbundene Pins werden noch gemacht. tromversorgung etc kommt nicht drauf. Das ist nur ein Plan, wird nie eine Platine draus werden. PS: Was fehlt denn noch "Wichtiges" außer - Reset Schaltung und Taster - Stecker nach draußen - 5V Versorgung
Christian J. schrieb: > Einige Leitungen weiss ich auch noch nicht was damit tun. Hier mal ein Anfang: An WAIT, INT, NMI, BUSRQ, je ein Pullup. INT an STI anschließen. Am STI IEI ein Pullup. RD an OE von RAM und EPROM. WR an WE von RAM. MREQ an CS1 von RAM. Pullups generell 4,7k. > RAM ist ASC61008 laut Aufschrift. Das Datenblatt habe ich inzwischen auch gefunden. Dann ist das so in Ordnung. Meine Aussagen weiter oben passen natürlich trotzdem.
:
Bearbeitet durch User
In die Speicherdekodierung muss MREQ rein, sonst mischen die auch bei I/O-Zugriffen mit. Beim RAM täte es das /CS1, aber beim ROM gibts kein zweites /CS. Allerdings halte ich den Vorschlag von oben, statt getrennter Adressräume ein Flipflop zu verwenden, für sinnvoller. Also ab Reset lesen aus ROM, schreiben ins RAM. Nach Zugriff auf eine I/O-Adresse schaltet das FF um, und es wird aus dem RAM gelesen. Reset-Code kopiert ROM-Inhalt über sich selbst und schaltet dann um.
Da fehlt noch mehr, zb die MREQ,RD,WR Veroderung auf die Memories. Mache ich morgen. Danke!
A. K. schrieb: > Allerdings halte ich den Vorschlag von oben, statt getrennter > Adressräume ein Flipflop zu verwenden, für sinnvoller. Also ab Reset > lesen aus ROM, schreiben ins RAM. Nach Zugriff auf eine I/O-Adresse > schaltet das FF um, und es wird aus dem RAM gelesen. Reset-Code kopiert > ROM-Inhalt über sich selbst und schaltet dann um. Das wollte ich jetzt so nicht. Der Monitor läut schon aus dem ROM heraus, erst nach dem Laden eines User Progrs springt er rüber. Was bringt denn diese FF Geschichte für Vorteile? Und Wird da das ROM abgschaltet?
Christian J. schrieb: > Was bringt denn diese FF Geschichte für Vorteile? Die gesamten 64KB des Adressraums sind als RAM nutzbar. Es lassen sich die RST Befehle im RAM-Programm verwenden. Bei dir sind die im ROM und allenfalls über Sekundärvektoren nutzbar. > Und Wird da das ROM abgschaltet? Über einen der Ausgänge des 138ers.
!CE von RAM und EPROM muss mit MREQ verknüpft werden - oder Du bastelst Dir !MEMRD und !MEMWR. Ansonsten kommen Dir die Speicher bei IO-Zugriffen in die Quere. So, wie Du es jetzt machst, ist das Pfusch. Das merkst Du spätestens dann, wenn Du statt des UV-EPROMS entweder ein 28F256 EEPROM oder ein 29C256 Flash einsetzten möchtest. http://www.atmel.com/Images/doc0006.pdf http://www.ej9.ru/data/datasheet_ej9_at29c256.pdf Das könnte nämlich auf die Dauer wesentlich angenehmer sein. Die kleinen Unterschiede im Pinout bei Pin 1 und Pin 27 (A14, !WE, Vpp) handhabst Du über Jumper. Wurde früher auch so gemacht. Auch einen Schreibschutz kannst Du so realisieren. 100n Abblockkondensatoren nicht vergessen. fchk
So, sieht schon besser aus, Fehler auch korrigiert. Jetzt aber Feierabend und Danke Jungs! Mal schauen wie ich mich revanchieren kann. >>So, wie Du es jetzt machst, ist das Pfusch. Das merkst Du spätestens >>dann, wenn Du statt des UV-EPROMS entweder ein 28F256 EEPROM oder ein >>29C256 Flash einsetzten möchtest. Du warst jetzt schneller als ich korigieren konnte :-)
Und hier der Plan als Grundstock wer Spass hat sich da was eigenes draus zu entwickeln.... ist ja "open source" :-) Da ich alle Bausteine doppelt und dreifach habe wegen Minderbstellmenge würde ich die gerne, wenn Interesse besteht, den Herren hier verschenken, die mir derart viel geholfen haben.
wie gesagt: denke an die Jumper, um statt des 27c256 ein 28c256 oder 29c256 einsetzen zu können, wenn Du es Dir anders überlegst. Das nachträglich einzuflicken, wird hässlich. Oder ein M48Z08 oder M48Z35. Die gabs damals auch schon. Auch nahezu pinkompatibel. http://www.reichelt.de/Timekeeper-Zeropower/M-48Z35-Y70/3//index.html?ACTION=3&GROUPID=2948&ARTICLE=39921&OFFSET=16&WKID=0& fchk PS: http://www.reichelt.de/-EE-Flash-Eproms/28C256-150/3//index.html?ACTION=3&GROUPID=4510&ARTICLE=1945&SEARCH=28c256&OFFSET=16&WKID=0&
Eine Frage zum Reset: Muss der so aufwendig sein? Oder startet der Z80 auch von allein nach Anlegen der Spannung?
Ok, habe da noch was gefunden: http://books.google.de/books?id=mVQnFgWzX0AC&printsec=frontcover&hl=de#v=onepage&q&f=false Es ist vollständig einsehbar aber nicht downloadbar. Höchstens man snapshottet jede Seite einzeln :-) Heute kam auch das DDR Buch über den U080 von Amazon.
Christian J. schrieb: > Das wollte ich jetzt so nicht. Der Monitor läut schon aus dem ROM > heraus, erst nach dem Laden eines User Progrs springt er rüber. Was > bringt denn diese FF Geschichte für Vorteile? Du kannst den ganzen RAM als solchen nutzen. Der Monitor muß nicht bei 0000H liegen, sondern kann sich z.B. ans RAM-Ende verschieben. Die Vektoren bei 0x0038, 0x0018 etc. sind für Anwendercode frei. Du kannst Teile des Monitors im RAM überladen (und dadurch ausprobieren bevor du sie in ein EPROM brennst). Du kannst auch aus dem Monitor heraus ein Betriebssystem mit beliebigem Speicherlayout bootstrappen. Z.B. ein CP/M mit dem BIOS am RAM-Ende. Oder etwas ZX80-kompatibles mit dem ROM ab 0x0000. XL
> habe da noch was gefunden: http://retro.hansotten.nl/uploads/z80/BuildYourOwnZ80.pdf Gurgel mal nach Steve Ciarcia. Da wirst Du ziemlich viel finden.
Axel Schwenke schrieb: > Du kannst den ganzen RAM als solchen nutzen. Der Monitor muß nicht bei > 0000H liegen, sondern kann sich z.B. ans RAM-Ende verschieben. Die > Vektoren bei 0x0038, 0x0018 etc. sind für Anwendercode frei. Du kannst > Teile des Monitors im RAM überladen (und dadurch ausprobieren bevor du > sie in ein EPROM brennst). Du kannst auch aus dem Monitor heraus ein > Betriebssystem mit beliebigem Speicherlayout bootstrappen. Z.B. ein CP/M > mit dem BIOS am RAM-Ende. Oder etwas ZX80-kompatibles mit dem ROM ab > 0x0000. Ok, ist mir aber im ersten Ansatz zu kompliziert wenn noch nicht einmal das Einfache läuft. Mein Gedanke ist der, dass ab Start das ROM abläuft und auf Eingabe vom PC wartet, dass der ein Hex File einspielt. Das ROM hat Sprungadressen der Vektortabelle auf das RAM. Freigabe der INTS Das kann das Userprogramm dann nutzen. Denn die INTs brauche ich auf jeden Fall. So stelle ich mir das zumindest vor, habe mich damit aber noch nicht genau befasst. Wird doch hoffemntlich möglich sein im ROM weitere Sprünge zu hinterlegen, zb nachdem man gestestet hat ob Ram Code da ist.
Christian J. schrieb: > Das ROM hat Sprungadressen der Vektortabelle auf das RAM. Die Vektortabelle des IM2 kannst du platzieren wohin du willst. Sekundärvektoren über ROM ins RAM sind nicht sinnvoll. Der beschriebene Loader geht gut ohne Interrupts. Da gehts zunächst um eine einfachstmögliche Lösung um Programme vom PC ins RAM zu kriegen, mehr nicht. Das muss auch kein Intel Hex-Format sein. Ein Bootloader, der fix <n> KB binär an den Anfang vom RAM reinzieht und anspringt reicht. Der Rest passiert dann da. Eine Entwicklung über immer wieder zu brennende EPROMs ist einfach nur nervend, sollte also minimiert werden. Ein ROM-Monitor, der komplexer ist als besagter Bootloader, wird sinnvollerweise im RAM entwickelt, nicht im ROM.
:
Bearbeitet durch User
Hi, wie gesagt, dass mit dem FF ist mir zu kompliziert, ich müsste mir da erstmal eine Schritt ür Schritt Ablauffolge machen, was da im Einzelnen passiert und dann die entsprechende Logic dazu einbauen. Ich wüsste jetzt nicht wie ich die A13,14,15 Logik derart umarbeiten müsste, damit ich das RAM schwuppdiwupp da liegen habe wo vorher das ROM war und dass auch der Umschaltvorgang keinelei Probleme verursacht, weil der Z80 plötzlich im Nirgendwo ist. Eine CPU kann nicht stehen bleiben, die rennt immmer, d.h. das Umschalten müsste zwischen zwei Bus-Zyklen liegen und dann muss auch alles fertig sein im RAM. Wie Du schriebst würde ein IOREQ das FF kippen, d.h. zu dem Zeitpunkt gibt es keinen Memory-Zugriff, da der IO Befehl ja geladen wurde (Prefetch-Queue gibt es ja bei Z80 nicht), ausgeführt wird ....IOREQ kommt....zack....das RAM flippt durch Umschaltung der Adresscodierung auf den Platz des ROMs, dann kommt der nächste Buszyklus und der wird dann auf dem RAM ausgeführt an gleicher Adresse. Ich befasse mich ja erst seit 10 Tagen damit von Null an. Das schreibt sich siher einfacher hier als es ist, für jemand der das schon gemacht hat als für jemand, der das alles bis ins Detail verstehen muss, damit er es umsetzen kann. Der C64 hatte auch sowas, da lag unter dem BIOS noch RAM drunter, und man konnte umschalten. Trotzdem merke ich, dass eine gründliche Planung notwendig wird und Notizzettel nicht mehr reichen, da ich schon weit über das "Grant Minimalsystem" hinaus komme und ohnehin den Monitor neu schreiben muss. Es wird alles aus dem Ram heraus laufen, EPROMs brennen habe ich wirklich keine Lust zu zudem das ja auch nur einige Male geht. Und Retromässig bleiben die Fenster auch offen, damit man "Chip" sieht :-) Aktuell plane ich die Peripherie und wieviel Coderschalter ich brauche und wieviele Tasten. Damit das Ding auch was Sichtbares macht als Demo-Rechner und nicht nur schwarze Kästen zu sehen sind. Das Teil ist nur solange interessant, wie man daran basteln kann. Ein Attiny84 wird ein Interface zu einem 64KB EEPROM bilden, da I2C über Z80 nicht möglich ist., gibt zwar Steine die das können zb http://www.nxp.com/documents/leaflet/75016079.pdf abe ein AVR ist da die ideale Lösung mit einem Selbstbauprotokoll am PIO Port Daten des RAM ins EEPROM zu schaufeln. Eine SAVE und eine LOAD Taste werden das Userprogramm sichern und zurück laden und starten aus dem ROM heraus. Das kommt in den Monitor rein.
Christian ich lese dauernd "zu kompliziert".. Was zum Teufel willst Du eigentlich mit der Platine anfangen wenn dauernd was kompliziert ist? Ein Bisschen Nachdenken wird Dir Keiner abnehmen können. Ich weise noch darauf hin, das der CPU Clock nicht TTL konform ist, es werden CMOS Pegel benötigt (ist so auch dokumentiert). Es empfiehlt sich also einen PNP Transistor oder einen BS250 als aktiven Pullup an einem Leistungsgatter zu verwenden. Hier noch ein Bisschen Lesestoff den DU sicher in 3 Minuten überflogen hast und als zu kompliziert abhakst: http://www.z80.info/#BASICS_DATA Gruß, Holm
Holm Tiffe schrieb: > Es empfiehlt sich > also einen PNP Transistor oder einen BS250 als aktiven Pullup an einem > Leistungsgatter zu verwenden. Wenn sein Oszillator nicht sowieso schon CMOS Pegel liefert, dann hängt er eben ein HCT Gatter dazwischen.
Holm Tiffe schrieb: > Ich weise noch darauf hin, das der CPU Clock nicht TTL konform ist, es > werden CMOS Pegel benötigt (ist so auch dokumentiert). Was ist los ? Da ist alles ttl konform, auch bei mir. Der Wecker schwingt und hat einen Treiber....
Christian J. schrieb: > Was ist los ? Da ist alles ttl konform, auch bei mir. Der Wecker > schwingt und hat einen Treiber.... Andersrum. Der Takteingang der CPU hat eine ungewöhnliche Pegelanforderung und eine etwas höhere Eingangskapazität. Dein Oszillator liefert wenn du Pech hast aber nur TTL Pegel. Blick ins Datasheet hilft, bei CPU und Oszillator.
:
Bearbeitet durch User
Meint ihr jetzt die Pegel oder die Flankensteilheit? http://de.wikipedia.org/wiki/Logikpegel Ein Schmitt Trigger dürfte Abhilfe shcaffen, ich habe da aber sowieoso noch was anderes vor....
Hier die Pegel Spec..... Also wenn der Osc zwische 0.5V und 4.5V Pegel macht mit genügend "Dampf", also Push Pull Stufe, dann dürfte doch alles ok sein. Habe keinen Osczi hier, müsste ich mir mal wieder beschaffen......
Liebe Leute, bevor ihr jetzt stundenlang über nicht konformen Clock und Reset philosophiert, sollte man mal klären welche Z80 CPU jetzt Christian überhaupt einzubauen gedenkt: Einen echten original alten in NMOS (dto. die ostdeutsche Variante U880)oder doch 'ne neuere Cmos (Z84C00). Und was ist mit 74xx, sind hier "LS" oder "HC/HCT" geplant? Die reine Retrolehre ist diese Projekt sowieso nimmer. Mit 'nem Cmos Osc Baustein hast die alten LS Treiberprobleme eh nimmer. Den Kram mit der Clockauswahl (heute 08:44), weglassen! Die Resetschaltung dort ist Quark. Noch schlimmer ist die von gestern Abend 22:57, da wird der Taster recht schnell kaputt gehen (warum??). Standard ist 7705, wurde schon geraten. Oder was moderneres, wie LT1232, MIC1232. >Habe keinen Osczi hier Das kann noch ein grösseres Problem werden. Gruss
Erich schrieb: > Einen echten original alten in NMOS (dto. die ostdeutsche Variante > U880)oder doch 'ne neuere Cmos (Z84C00). Die Daten der CMOS-Version unterscheiden sich in dieser Frage nicht von der alten NMOS-Version.
Christian J. schrieb: > Ein Attiny84 wird ein Interface zu einem 64KB EEPROM bilden, da I2C über > Z80 nicht möglich ist., gibt zwar Steine die das können zb > http://www.nxp.com/documents/leaflet/75016079.pdf abe ein AVR ist da die > ideale Lösung mit einem Selbstbauprotokoll am PIO Port Daten des RAM ins > EEPROM zu schaufeln. Eine SAVE und eine LOAD Taste werden das > Userprogramm sichern und zurück laden und starten aus dem ROM heraus. > Das kommt in den Monitor rein. EEPROMs gab es zu der Zeit noch nicht. Das erste, was es gab, was der 28C64, parallel und fast 6264/27C64-pinkompatibel. Oder eben batteriegepuffertes RAM. Und wenn seriell: SPI ist deutlich einfacher zu implementieren. fchk
Joe G. schrieb: > Christian J. schrieb: >> ... ich frage nach einem Käfer und du kommst mit einem >> Panzer daher, für den es NICHTS irgendwo gibt. > > Hier sogar in zwei Varianten. Selbstverständlich mit CP/M :-) Sehr netter "Panzer" der grosse im rechten Bild :-) Wann geht der in Serie? .-)
Christian J. schrieb: > wie gesagt, dass mit dem FF ist mir zu kompliziert, ich müsste mir da > erstmal eine Schritt ür Schritt Ablauffolge machen, was da im Einzelnen > passiert und dann die entsprechende Logic dazu einbauen. Es ist zwar keineswegs so kompliziert wie du denkst, aber ja. Taktdiagramme und zu Fuß aufgebaute Decodierlogik sind doch gerade der Teil, der Retrocomputing von dem modernen Zeug unterscheidet und so interessant macht. > Ich wüsste > jetzt nicht wie ich die A13,14,15 Logik derart umarbeiten müsste, damit > ich das RAM schwuppdiwupp da liegen habe wo vorher das ROM war und dass > auch der Umschaltvorgang keinelei Probleme verursacht, weil der Z80 > plötzlich im Nirgendwo ist. Eine CPU kann nicht stehen bleiben, die > rennt immmer, d.h. das Umschalten müsste zwischen zwei Bus-Zyklen liegen > und dann muss auch alles fertig sein im RAM. Erstens: Die Idee ergibt nur dann einen Sinn, wenn du den ganzen Adreßraum (64K) voll RAM hast. Wenn du jetzt zusätzlich ein ROM hast, dann muß das in jedem Fall irgendwo ein- und das RAM entsprechend ausgeblendet werden. Zweitens: An dieser Stelle kommt jetzt ein weiteres Logiksignal ins Spiel. Nennen wir es ROMEN (wie ROM ENable). Die Dekodierlogik für das /CS von RAM bzw. ROM wird jetzt so erweitert, daß bei ROMEN=H das ROM eingeblendet ist und bei ROMEN=L eben nicht. Das ist keine Raketentechnik. Dazu braucht man nur irgendwo in der Logikkette zur Erzeugung der /CS Signale ein passendes Gatter mit einem freien Eingang. Optional kann man noch darüber nachdenken, ob man Lese- und Schreib- zugriffe separat betrachten will. Bspw. könnte man Schreibzugriffe immer ins RAM leiten, auch dann wenn an der entsprechenden Adresse eigentlich das ROM eingeblendet ist. Das macht die ganze Sache noch flexibler und war bei Heimcomputern auch üblich. Ist aber wie gesagt optional. Drittens: Das ROMEN Signal macht man jetzt nicht statisch (wozu ich auch einen manuell betätigten Schalter zählen würde) sondern generiert es selber. Da der Z80 nach RESET gerne bei 0000H ein Programm sehen möchte, ist es nur logisch, ihm das ROM bei 0000H zu zeigen und RESET das ROMEN auf H setzen zu lassen. Damit man ROMEN wieder auf L kriegt, kann man z.B. einen bisher ungenutzten Ausgang des IO-Adreßdecoders verwenden. Oder einen Pin der PIO. Oder sonst was. Und man würde wohl ein Flipflop nachschalten, das von RESET gesetzt und einem zweiten Signal gelöscht wird. Wer mitdenkt, würde vermutlich auch einen Weg vorsehen, das Flipflop per Software wieder setzen (und so das ROM einblenden) zu können. Dann kann man im Monitor einen "Warmstart" Befehl implementieren: "kopiere den Monitor frisch aus dem ROM ins RAM, laß den Rest vom RAM aber wie er ist". > Wie Du schriebst würde ein IOREQ das FF kippen, d.h. zu dem Zeitpunkt > gibt es keinen Memory-Zugriff, da der IO Befehl ja geladen wurde > (Prefetch-Queue gibt es ja bei Z80 nicht), ausgeführt wird ....IOREQ > kommt....zack....das RAM flippt durch Umschaltung der Adresscodierung > auf den Platz des ROMs, dann kommt der nächste Buszyklus und der wird > dann auf dem RAM ausgeführt an gleicher Adresse. Man kann sich alternativ auch einfach clever anstellen. Aus dem ROM führt man nur den Code aus, der den Monitor ins RAM kopiert. Dann springt man ins RAM in den Monitor und erst dort schaltet man das ROM aus. In dem Buch aus dem ich die Idee habe [1], macht es der Autor anders ^Wgenau so. Habs gerade nochmal rausgesucht. Dieses Stück Code ist sogar im Quellcode abgedruckt. Einen Scan des Hexdumps des dort verwendeten Monitors hätte ich auch noch. Mit Prüfsummen, die sogar stimmen. XL [1] "Mikroelektronik in der Amateurpraxis 3"; Teil 2: Bernd Hübler "BASIC-Kleincomputer mit Grafik". Militärverlag der DDR, 1987
Guido Lehwalder schrieb: > Sehr netter "Panzer" der grosse im rechten Bild :-) > Wann geht der in Serie? .-) Der Panzer ist schon durch, ich glaube es gibt keine Platinen mehr dazu. Den Originalthred vom Entwickler findest du übrigens hier: http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=10189
Hi, Leute nehmt es mir nicht übel aber aus der Sicht des TS der jeden Beitrag liest wird es langsam "widersprüchlich", zb das mit der Reset Schaltung(taugt was, taugt nichts..... das sind Schaltungen aus Büchern!), der nächste kommt mit dem Clock usw. Da sind sich einige selbst nicht einig. Ich verwende eine moderne Z80 Typ C (habe aber auch andere hier, eine uralte "A" auch noch) und ansonsten nur HCT und LS Chips, was grad da ist. HCT aber 90%. Mir ist Retro wurst solange es funktioniert und ich mich nicht tot suche, zudem ich noch einen Oszi anschaffen muss. Der alte hat es hinter sich und ziert die Müllhalde. Diese Umschaltgeschichte ist jetzt vom Tisch bei mir, bei 8k ROM und 56k Ramist genug Platz für alles und CP/M wird nie laufen bei mir, da ich da keine Lebensaufgabe draus machen will und in 3 Wochen das Board hier fertig haben möchte. Wie es geht weiss ich aber jetzt, die 8kb ROM aus dem RAM aus wegblenden ist nicht so schwer. Aber wie zum Teufel soll man dafür noch Code erzeugen? Ich werde mit C arbeiten im Userprogramm und den Monitor mit Asm schreiben. Da ich bisher keine einzige Zeile geschrieben habe für den Z80 wird das auch noch mal einiges an Zeit kosten da erste Erolge zu sehen. Ich werde dennoch eine Dualtaktung bauen, eine mit 2 Hz und eine normale. Und die "Spielereien" mit dem Ausblenden und Einblenden braucht man nicht, wenn man nur etwas damit spielen will un sich freut, wenn es funktioniert. Also...... Resetschaltung für Taster ok? Oder nicht? Clock duch Inverter durchjagen? Ok? Gruss, Christian
Christian J. schrieb: > Holm Tiffe schrieb: >> Ich weise noch darauf hin, das der CPU Clock nicht TTL konform ist, es >> werden CMOS Pegel benötigt (ist so auch dokumentiert). > > Was ist los ? Da ist alles ttl konform, auch bei mir. Der Wecker > schwingt und hat einen Treiber.... Ist es nicht. Gruß, Holm
Erichs Kritik in Ehren, aber etwas konstruktiver hätte er schon auftreten können. Kannst dem Schalter, der den Elko kurzschliesst, noch ein 100 Ohm Widerstand in Reihe verpassen. Dann blitzt es nicht so und er lebt länger.
A. K. schrieb: > Holm Tiffe schrieb: >> Es empfiehlt sich >> also einen PNP Transistor oder einen BS250 als aktiven Pullup an einem >> Leistungsgatter zu verwenden. > > Wenn sein Oszillator nicht sowieso schon CMOS Pegel liefert, dann hängt > er eben ein HCT Gatter dazwischen. Was hast Du gegen einen einzelnen BS250 ohne weitere Bauteile? Source an VCC, Gate an en Eingang eines Negators, Drain an den Ausgang des Negators..ferdsch. Sieht sogar auf dem Oszillograf chick aus. Gruß, Holm
Holm Tiffe schrieb: > Was hast Du gegen einen einzelnen BS250 ohne weitere Bauteile? Oben schrieb mal wer, dass jemand, dem schon der SIO zu kompliziert ist ... Er sollte immerhin verstehen, was er da tut.
Holm Tiffe schrieb: > Was hast Du gegen einen einzelnen BS250 ohne weitere Bauteile? > Source an VCC, Gate an en Eingang eines Negators, Drain an den Ausgang > des Negators..ferdsch. Und was ist daran einfacher, als der Negator ohne BS250? ;-)
A. K. schrieb: [..] > > Und was ist daran einfacher, als der Negator ohne BS250? ;-) Ein transistor anstatt einem zusätzlichen IC mit mindestens 14 Beinen auf einer kleinen Eurokarte.. Latürnich nur wenn nicht das Gatter sowieso gerade irgendwo übrig ist. Gruß, Holm
OK, Christian sollte zunächst mal sein Schaltbild etwas weiterbringen, dann kann man über einzelne Punkte nochmals diskutieren. Hier noch der Link auf ein wirklich kleines System. http://petersieg.kilu.de/miniz80/miniz80.html Wurde erfragt hier Beitrag "Re: einfache Z80 Schaltung" aber dort hat dann der Fragesteller nicht mehr geantwortet. Schade daß die anderen Spezialisten hier (prx) und (souleye) darauf nicht verwiesen haben. Letzten Beitrag dort beachten; ein Jammer! Meinen alten Kram hab' ich noch irgendwo, muss ihn nur in den Listen finden... @Christian: Wennste schon 32-Pin-Ram einbaust, kannst nebendran den Sockel für's Eprom auch als 32-Pin machen. Auch wenn zunächst nur 27C256 reinkommt. Warum, schreibe ich dir später einmal. Aber Stichwort ist 29F010 (29F040). Da finde ich ein Stück SW bei mir... Gruss
Holm Tiffe schrieb: > Ein transistor anstatt einem zusätzlichen IC mit mindestens 14 Beinen > auf einer kleinen Eurokarte.. Und woher kommt dein Negator, wenn kein Gatter übrig ist?
Christian J. schrieb: > Ich verwende eine moderne Z80 Typ C (habe aber auch > andere hier, eine uralte "A" auch noch) Was steht genau auf dem Chip? "Typ C" gibt es nicht. Es gibt NMOS und CMOS Chips NMOS, Zilog Bezeichnung: Z8400 (+Zusatz) 2,5 MHz Z80 4 MHz Z80A 6 MHz Z80B 8 MHz Z80H CMOS, Zilog Bezeichnung Z84C00x 6 MHz Z84C006 8 MHz Z84C008 10 MHz Z84C0010 20 MHz Z84C0020 Wahrscheinlich gibts noch mehr, und andere Hersteller haben noch andere Bezeichnungen. Für Deine Schaltung macht es einen Unterschied, ob Du eine NMOS- oder eine CMOS-CPU einsetzen willst.
Leo C. schrieb: > Für Deine Schaltung macht es einen Unterschied, ob Du eine NMOS- oder > eine CMOS-CPU einsetzen willst. Worin? Klar, eine vorneweg für CMOS gebaute Schaltung kann stellenweise 74HC verwenden, weshalb die NMOS Version dann scheitert. Aber inwiefern sollte eine für NMOS gebaute Schaltung mit der CMOS Version Probleme bekommen? Es sei denn natürlich, er erwischt einen NSC800. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Holm Tiffe schrieb: >> Ein transistor anstatt einem zusätzlichen IC mit mindestens 14 Beinen >> auf einer kleinen Eurokarte.. > > Und woher kommt dein Negator, wenn kein Gatter übrig ist? Alex! Gruß, Holm
Leo C. schrieb: [..] > > Wahrscheinlich gibts noch mehr, und andere Hersteller haben noch andere > Bezeichnungen. > > Für Deine Schaltung macht es einen Unterschied, ob Du eine NMOS- oder > eine CMOS-CPU einsetzen willst. Wieso eigentlich nur CPU, die restlichen Peripherie-ICs betrifft das genau so. Gruß, Holm
Leo C. schrieb: > Christian J. schrieb: >> Ich verwende eine moderne Z80 Typ C (habe aber auch >> andere hier, eine uralte "A" auch noch) > > Was steht genau auf dem Chip? > > "Typ C" gibt es nicht. > Es gibt NMOS und CMOS Chips > > NMOS, Zilog Bezeichnung: Z8400 (+Zusatz) > 2,5 MHz Z80 > 4 MHz Z80A > 6 MHz Z80B > 8 MHz Z80H > > CMOS, Zilog Bezeichnung Z84C00x > 6 MHz Z84C006 > 8 MHz Z84C008 > 10 MHz Z84C0010 > 20 MHz Z84C0020 Z8420BB1 Z84C0BB6 Klar macht das einen Unterschied! Ob 7400N oder 74LS00 macht auch einen :-) Die ....N habe ich mal alle wegeworfen, 50mA pro Chip waren etwas viel. Specialfrage für Holm: Glaubst Du .... bei Röhren gibt es ja auch vielleicht sowas .... dass es was ausmacht, wenn ich deinen Takt von 3,6Mhz duch den Inverter eines unschuldigen 7414 Inverter Gatters jage und gleich nebenan, sozusagen als Nachbarn liegt die reset Schaltung auf den beiden anderen Invertern. Merkt der Reset ob der Nachbar dauernt mit dem Presslufthammer arbeitet? :-)
Christian J. schrieb: > Kla macht das einen Unterschied! Ob 7400N oder 74LS00 macht auch einen Weshalb es angebracht wäre, im Schaltplan die realen Typen zu zeigen, nicht das, was ist der Liste zufällig oben stand. Oder meist du mit 7432/74138 wirklich die TTLs erster Generation?
> Z8420BB1 Das müßte eine PIO sein, keine CPU. > Z84C0BB6 Da stimmt was nicht. Scheint (auch) keine CPU zu sein.
:
Bearbeitet durch User
Links die CPUs.... >>Weshalb es angebracht wäre, im Schaltplan die realen Typen zu zeigen, >>nicht das, was ist der Liste zufällig oben stand. Oder meist du mit >>7432/74138 wirklich die TTLs erster Generation? Ja, schon als Kind holte ich die vom Sperrmüll etc aus Platinen raus, das war ca 1975. Ich hatte hunderte dieser "Käfer". So mit ca 10 betrieb ich die dann auch mal und merkte, dass sie 50ma "fressen". Dann kamen CD .... und die konnten nicht mal Leuchtiode treiben. Die Z80 kann eine blaue LED treiben, die sieht man noch mit 200uA hell genug.
"Darf" man die CMOS mit den alten kombinieren? Würd ich mich nicht trauen.
Harald schrieb: > "Darf" man die CMOS mit den alten kombinieren? Würd ich mich nicht > trauen. Also mit HCT ahre ich bisher immer gut, die haben hohen Eingangswiderstand, hohe Treiberleistung und sind TTL komptibel. Alles andere kenne ich auch nicht. Eine CMOS CPU wird wohl damit klarkommen, man merkt es sicher auch und sieht es au dem Oszi wenn da zu sehr was daneben liegt.
Die Daten der NMOS und CMOS Versionen der Z80 CPU sind ziemlich gleich, was die Pegel in einer Mischumgebung angeht. Die Timings habe ich nicht verglichen. Ich sehe keinen Grund, weshalb NMOS und CMOS Versionen von CPU und Peripherie nicht miteinander kooperieren sollten. Nur auf 74HC Bausteine sollte man verzichten. 74LS00 ist ok, 74HCT00 ist ok, aber 7400/74S00 haben neben dem Stromverbrauch einen zu hohen Fanin. Auch CD4000er sind tabu.
Ok, zurück zum Thema ..... wenn ich gleich vom Walken wiederkomme wolllte ich etwas basteln: Reset Schaltung ok, aber es blitzt eben. Ok, .... C etwas kleiner machen. Ausgang des Oszillator leite ich dann durch ein Inverter HCT Gatter aber leider sind dazu 6cm Lutstrecke nötig, d.h. er liegt nicht mehr direkt am Pin. Ok. Außerdem werde ich einen Jumper ür den Takt einbauen, so dass ich noch über einen CD4060 einen erzeugen kann, auch über HCT Gatter aun den Clock. Das sollte auch erstmal genügen ür heute...
Was die Logikchips betrifft war mir schon klar. Ich meinte CPU und Peripherie unterschiedlicher Typen.
Bisschen Grundlagen zu Mischkonfigurationen: In der Anfangszeit der Z80 üblich waren NMOS LSI-Chips kombiniert mit LS-TTL Logik, also 74LS00. Das war also schon ein Mix, aber die Pegel solcher NMOS-ICs orientierten sich notwendigerweise an TTL Pegeln, zumal das auch technisch passte. Sogar die ollen und langsamen PMOS-Chips mussten sich an TTLs orientieren, und da passte das eigentlich nicht so recht. Auch damalige CMOS Mikroprozessoren (z.B. NSC800 = Z80 in CMOS, aber inkompatiblem Gehäuse) orientierten sich teilweise an TTL Logik. RCA tat dies beim CDP1802 zwar nicht, aber die hatten ihre eigene CD4000er Logik im Auge. Und hatten Probleme beim Anschluss von normalem Speicher ausserhalb der RCA Reihe, denn normaler Speicher lieferte TTL Pegel und passte folglich nur mit Pegelkonverter an den Datenbus. Also dann CMOS in Breite aufkam, einerseits als 74HC(T) Logik, andererseits in den Mikroprozessoren der 80er, mussten die sich mit der bestehenden Welt arrangieren. Der Rest der Welt war ja weiterhin teils TTL, teils NMOS. Man konnte nicht alles mit einem Schlag umstellen und musste noch lange Zeit mit bestehender NMOS Peripherie und über TTL definierten Bussytemen auskommen. Also: Auch wenn Zilog die eigene Linie in einem Rutsch umstellte, mussten die Anwender weiterhin mit bestehenden Bausteinen anderer Hersteller leben. Mischkonfigurationen waren deshalb völlig normal. Deshalb gab es die TTL kompatible 74HCT00 Serie neben der nicht kompatiblem 74HC00 Serie. Und deshalb erwarten CMOS Prozessoren dieser Generation meist TTL-Pegel am Interface, keine CMOS-Pegel. Dass dies nicht auf alle Pins zutreffen muss, das wurde schon anhand des Takteingangs gezeigt. Der hatte schon in der NMOS Version eine sehr eigene Pegeldefinition. Überrascht hat mich eher, dass dies sogar noch auf die CMOS Version zutrifft.
Christian J. schrieb: > dass ich noch über einen CD4060 einen erzeugen kann Am 3,6MHz Takt wird das eng, den dieser Kollege hat bei 5V eine Maximalfrequenz von typisch 4MHz, mindestens 1,5MHz.
:
Bearbeitet durch User
Christian J. schrieb: > Reset Schaltung ok, aber es blitzt eben. Ok, .... C etwas kleiner > machen. Nö. Kleinen Widerstand in Reihe zum Schalter machen. > leider sind dazu 6cm Lutstrecke nötig Stört nicht. Die Taktleitung landet ja auch beim STI, und der wird wohl auch nicht direkt passend liegen. Nur wärs empfehlenswert, diese Taktleitungen nicht auf Länge parallel zu anderem Kram im Fädelkamm zu ziehen.
:
Bearbeitet durch User
Christian J. schrieb: > Z84C0BB6 Das ist ein Druckfehler. > > Klar macht das einen Unterschied! Ob 7400N oder 74LS00 macht auch einen > :-) Die ....N habe ich mal alle wegeworfen, 50mA pro Chip waren etwas > viel. Ich habe Rechner, bei denen 50mA mehr nicht auffallen aber in denen ein LS00 statt einem 00 nicht arbeitet. > > Specialfrage für Holm: > > Glaubst Du .... bei Röhren gibt es ja auch vielleicht sowas .... dass es > was ausmacht, wenn ich deinen Takt von 3,6Mhz duch den Inverter eines > unschuldigen 7414 Inverter Gatters jage und gleich nebenan, sozusagen > als Nachbarn liegt die reset Schaltung auf den beiden anderen Invertern. > Merkt der Reset ob der Nachbar dauernt mit dem Presslufthammer arbeitet? > :-) Nein. Gruß, Holm
Hallo, hier ist der vorläufige Stand. Es ist kein Konstruktionsplan, daher sind Massen auch nicht eingezeichnet und auch keine Blockkondensatoen, damit es nicht unübersichtlich wird. NMI ist noch frei und auch der INT des ADC liegt noch offen. Da muss ich mal schauen was damit machen. NMI für ADC ist mir zu viel, vielleicht ein Taster mal schauen.
Christian J. schrieb: > auch der INT des ADC liegt noch offen. Nu haste in der Kiste eigens einen Interrupt-Controller mit 8 Eingängen und willst ihn nicht nutzen?
Ich vermute mal das die STI sich über ein CLK Signal freuen würde. NMI und INT kannst Du erst mal mit einem Pullup (2,2k z.B.) nach VCC beschalten. Die Treibenden Ausgänge sind open Drain. Gruß, Holm
Das mit dem Takt müssen wir wohl noch ein paar Wochen üben. Ein 7414 Standard-TTL ist als Pegelkonverter für den Takteingang der CPU sowas von deplaziert. Das muss 74HCT sein. Und wenn das kein 7414 ist, dann schreib nicht 7414 ran. Dito 7432. Zum NMI: Was immer du damit machen willst: Du willst ihn garantiert nicht offen lassen.
:
Bearbeitet durch User
>Bisschen Grundlagen zu Mischkonfigurationen: Da habe ich jetzt auch einen Beitrag in Form des beigefügten Bilds. Ist ein Einplatinencomputer; kein herausgeführter Bus, nur I/Os. Die Platine hat ca. die Maße 280x225 mm, stammt lt. Labelaufkleber von der Fa. Bergmann (Spielautomaten). War aber wohl eher so'n Testgerät dafür, denke ich. Ein Ebaykauf, schon länger her, lag etwas eingestaubt im Keller bei mir. Am Datecode "9229" erkennbar hergestellt nach Mitte 1992. Mit 'ner schönen Mischbestückung, CPU, CTC und viele PIOs in NMOS, die beiden SIOs in Cmos (Tosbiba). Habe kein Schaltbild dafür. Decodierung für Memory und IO ist aber easy, da '138 Decoder, keine PALs/GALs. Schwieriger sind schon die ganzen Stecker aussenrum, muss man alles rauspiepsen. Naja, RS232 4x über die 2 Maxims, eh klar, das sind ja nicht so viele Pins (links oben). Spannungsregler "TA7805S", ist aber auch nur 1A (Toshiba). Die Platine zieht am Eingang des 7805 nur gute 0,6A ; erstaunlich. Platine ist nur 2-Lagen, keine Smds, Rückseite nur Leiterbahnen. Mein Respekt an den Layouter! Programm unbekannt, läuft jedoch, denn kurze Piepser und LED-Blinksequenzen kommen und nach ca. 10s kommt lauter Piepton, dann ist wohl Programmende/Abbruch. Über'n Winter werd' ich mal mein Monitorprogramm draufsetzen, wenn ich die SIO und Baudrate rausgepiepst habe. Nett sind die vielen Opto in und ULN Ausgänge, insofern wär' Schaltbild bzw. Steckeranschlußplan schon gut. ----> Wer dafür Schaltbild hat, bitte hier melden! Gruss
Auch schön ist das Drumrum. Eine kunterbunte Mischung aus 74HC, 74HCT, 74LS, 74-Std und CD4000. Fehlt eigentlich nur 74S. Und der HC138 an einer NMOS CPU wirkt etwas schräg. An alle Freunde von Bustreibern, von wegen knappem Timing, Fanin, Fanout und so: findet ihr welche? Da sind circa 18 VLSIs Devices am Bus, zzgl. Gatter.
:
Bearbeitet durch User
A. K. schrieb: > Das mit dem Takt müssen wir wohl noch ein paar Wochen üben. Ein 7414 > Standard-TTL ist als Pegelkonverter für den Takteingang der CPU sowas > von deplaziert. Das muss 74HCT sein. Es gibt keine HCT in der Lib ! Das ist nur ein Plan zum Verdrahten. Ich definiere mir doch keine neuen Bausteine, nur weil da ein Buchstabe fehlt.
Christian J. schrieb: > Es gibt keine HCT in der Lib ! Was für ein Programm ist das denn, in dem es keine andern Logikbausteine als TTL-Urfassung gibt? Kannst es auch separat in einem Eck als Text ranschreiben. Das wird ja wohl gehen. Spart dämliche Kommentare von irritierten Lesern.
Holm Tiffe schrieb: > Ich vermute mal das die STI sich über ein CLK Signal freuen würde. > NMI und INT kannst Du erst mal mit einem Pullup (2,2k z.B.) nach VCC Die hat ein Clock, es reicht wenn man den Netzen die gleichen Namen gibt anstatt ein Knäuel Leitungen durchs Design zu ziehen. In jobtechnischen Designs mache ich gar keine Leitungen rein bei uc, nur noch Bezeichner. Bei 144 Pins würde man sonst Augenkrebs kriegen.
Nur so aus Neugierde: Was für jobtechnische Designs macht du? Angesichts deiner Kenntnisse und Fragen liegt entsprechende Erfahrung nicht unbedingt nahe.
:
Bearbeitet durch User
Erich schrieb: >>Bisschen Grundlagen zu Mischkonfigurationen: > > Da habe ich jetzt auch einen Beitrag in Form des beigefügten Bilds. > Ist ein Einplatinencomputer; kein herausgeführter Bus, nur I/Os. > Die Platine hat ca. die Maße 280x225 mm, stammt lt. Labelaufkleber von > der Fa. Bergmann (Spielautomaten). War aber wohl eher so'n Testgerät > dafür, denke ich. Ein Ebaykauf, schon länger her, lag etwas eingestaubt > im Keller bei mir. > Am Datecode "9229" erkennbar hergestellt nach Mitte 1992. Damit kannste nix anfangen. Das sind I/O Karten für Geräte mit vielen Relais oder Lampen bzw Eingängen. Der Z80 wurde extrem aufgebohrt mit Ports. Ich würde da einen Bunsenbrenner mit Flachdüse hinter halten, vorne eine Crimpzange und die PIO's etc alle rausholen. geht bei mir ratzfatz sowas, 2s sind die draußen. Die Elkos, Batterie usw. dürften alle hinüber sein.
>Damit kannste nix anfangen. Hä? Wie meinen? Wie kommst DU auf das schmale Brett? Was weisst DU schon womit ich was anfangen kann? Geht's noch? Ich habe sämtliches Equipment für den Z80. Dinge, die du wahrscheinlich nicht mal gehört hast daß es sowas gibt oder gab. Ich habe fast 20 Jahre aktiv an entsprechenden Designs gearbeitet. In unterschiedlichen Firmen und Branchen. Angefangen beim 2708 und 2102. Endend mit dem TMPZ84C015 und drumrun, hier angedeutet Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" Gruss und Gute Nacht.
Auf der weiter oben schon zitierten z80.info Seite findet sich auch noch mein altes Standalone Steuercomputer Projekt in Europlatinen-Größe. Ich häng Euch mal den Schaltplan ran. Highlight der Software ist u.a.eine SPS-ähnliche Programmierung mit bis zu 8 Threads und Programm-Eingabemöglichkeit via 3x4er Tastaturmatrix. Bei Interesse (PM) gerne mehr, Platinen und andere Bauteile wären auch noch vorrätig ;-)
Na, da ist bei LCD wenigstens mal eine saubere Erzeugung von R/W und E eines 6800 Busses drin. Bizarr: Wenn RAM2 ein EEPROM ist und per Port reingemappt wird, dann hat man zwar 32KB EPROM und 32KB EEPROM, aber 0 KB RAM. Was soll dieser Spuk?
:
Bearbeitet durch User
Christian J. schrieb: > Sorry, Vorgänger, hier der letzte Stand..... Das wird so nicht funktionieren. Du wehrst Dich ständig gegen ein Ein- und Ausblenden des EPROM. Ein gleichzeitiger Betrieb von RAM und EPROM geht aber so, wie Du es vorhast, nicht!
Route 66 schrieb: > Ein gleichzeitiger Betrieb von RAM und EPROM > geht aber so, wie Du es vorhast, nicht! Weshalb? Die ersten 8KB gehören dem EPROM, der Rest ist RAM.
Christian J. schrieb: > Es gibt keine HCT in der Lib ! Das ist nur ein Plan zum Verdrahten. Ich > definiere mir doch keine neuen Bausteine, nur weil da ein Buchstabe > fehlt. Natürlich nicht. Es gibt nur die Grundtypen. Ob das Dingsbums mit den sechs Invertern jetzt 7404, 74LS14, 74HCT14 oder SN74LVT14D-Q1 heisst, steht in dem >VALUE-Attribut. Das passt man nach Bedarf im Schaltplan an.
A. K. schrieb: > Weshalb? Die ersten 8KB gehören dem EPROM, der Rest ist RAM. Simmt. /CE vom EPROM geht ja an CE2 vom RAM
Route 66 schrieb: > Christian J. schrieb: >> Sorry, Vorgänger, hier der letzte Stand..... > > Das wird so nicht funktionieren. Du wehrst Dich ständig gegen ein Ein- > und Ausblenden des EPROM. Ein gleichzeitiger Betrieb von RAM und EPROM > geht aber so, wie Du es vorhast, nicht! Hallo, nicht böse sein, dass ich mich etwas aus dem Thread zurückgezogen habe, weil man mit immer neuen "Neuigkeiten" konfrontiert wird und sich dann fragt ob man noch auf dem rechten Kurs ist. Natürlich geht das, ging schon immer auch mit 8085. Memory ist Memory, wohin der PC zeigt ist dem Z80 egal, hauptsache die Weichen (Decoder) werden richtig gestellt. Da ich etwas Zeit hatte, habe ich die Verdrahtungfehler korrigiert - nicht gut nachts zu arbeiten und sich bei den Pins zu verzählen bzw. "spiegelbildlich" zu verdrahten. Und bevor es weitergeht muss ich erstmal im Zaks lesen, bzw dem DDR Buch über den U880 was heute gekommen ist. Außerdem fehlt mir noch der Programmer und ein Oszi muss auch wieder her. Und über LS, HCT und HC mache ich mir echt keinen Bart in einer Hobbyzeichnung. Es ist real alles HCT und das genügt mir auch. Sobald es läuft teste ich mal LS und man wird sehen.
Christian J. schrieb: > Und über LS, HCT und HC mache ich mir echt keinen Bart in einer > Hobbyzeichnung. Offensichtlich. Wenn du dann aber ein solches Oevre postest, um mögliche Kommentare zur Verbesserung zu erheischen, dann sorgt das für Verwirrung. Mindestens erklärende Worte wären dann angebracht.
:
Bearbeitet durch User
A. K. schrieb: > Christian J. schrieb: >> Und über LS, HCT und HC mache ich mir echt keinen Bart in einer >> Hobbyzeichnung. > > Offensichtlich. Wenn du dann aber ein solches Oevre postest, um mögliche > Kommentare zur Verbesserung zu erheischen, dann sorgt das für > Verwirrung. Mindestens erklärende Worte wären dann angebracht. Ok, wir sitzen uns hier ja nicht gegenüber, so dass man erklärende Worte mit einfügen kann..... PS: Oben ist ein Bild, ist die CPU von Signetics ein NMOS?
Da ist mehr als ein Bild, aber in keines mit Signetics. Wenn du das mit "SGS" meinst - das ist SGS, später SGS-Thomson, heute STM.
:
Bearbeitet durch User
Christian J. schrieb: > Oben ist ein Bild, ist die CPU von Signetics ein NMOS? Ja. Steht doch drauf: "Z8400". Und es ist eine für 2.5MHz: "Z80CPU" XL
Christian J. schrieb: > Klar macht das einen Unterschied! Ob 7400N oder 74LS00 macht auch einen > :-) Die ....N habe ich mal alle wegeworfen, N steht für die Gehäuseform (Pastic-Dual-Inline, bei TI). Ich wette, auf Deinen 74LS00 ist auch ein N angehängt. > NMI für ADC ist mir zu viel, vielleicht ein Taster mal schauen. Die Pullups wurden ja schon mehrfach erwähnt. Ene Taste an NMI halte ich nicht für sinnvoll, aber wenn Du das wirklich machen willst, dann nur mit Entprellung. A. K. schrieb: > Auch schön ist das Drumrum. Eine kunterbunte Mischung aus 74HC, > 74HCT, > 74LS, 74-Std und CD4000. Fehlt eigentlich nur 74S. Ich finde keine 74HCT in dem Bild. iInteressant finde ich die 4584B die alle gesockelt sind. > Und der HC138 an einer NMOS CPU wirkt etwas schräg. Das sehe ich auch so. Ansonsten ist gegen HC nichts einzuwenden. Mit CMOS-CPU könnte Christian auch HC stat HCT nehmen (Akademisch, da er ja nur HCT hat).
Leo C. schrieb: > Ich finde keine 74HCT in dem Bild. Stimmt. HC1, nicht HCT. ;-) > iInteressant finde ich die 4584B die alle gesockelt sind. Das folgt ungefähr der Regel, dass was nach draussen geht gesockelt ist. Also die Schmitt-Trigger 4584 (Eingänge) und die ULN2004 (Ausgänge). Was ist eigentlich ein OKI M82X42B?
:
Bearbeitet durch User
A. K. schrieb: > Was ist eigentlich ein OKI M82X42B? Das ist eine RTC http://www.alldatasheet.com/datasheet-pdf/pdf/11263/OKI/MSM62X42B.html
A. K. schrieb: > Das soll eine 6 sein? ;-) Scheinbar ja, denn diese Anordnung neben der Stützbatterie und das Gehäuse sind eindeutig. Ich muß mal im Keller nachsehen, ob bei meinem IC die 6 auch so undeutlich ist.
Passt schon. Denn mit 82 gibts weit und breit nix. Nie wieder OKI Drucker. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Das folgt ungefähr der Regel, dass was nach draussen geht gesockelt ist. > Also die Schmitt-Trigger 4584 (Eingänge) und die ULN2004 (Ausgänge). Schmitt-Trigger und 15V Eingangsspannung. Und ja, gelegentlich Chip tauschen, ist wohl billiger, als eine gute Schutzbeschaltung. > Das soll eine 6 sein? ;-) Ach, so ist es ja einfach. Christian J. schrieb: > Außerdem fehlt mir noch der Programmer In dem Buch von Steve Ciarcia, daß Du neulich ausgegraben hast, sind mindestens 3 Programmer für den 2708 drin. Das erste mit manueller Address- und Dateneingabe über Kippschalter. ;-)
Leo C. schrieb: > Schmitt-Trigger und 15V Eingangsspannung. Fast alle 4000er erlauben nur Vdd+0,5V. Die 4049/4050 mit abweichender Eingangsschutzschaltung sind die Ausnahme.
Leo C. schrieb: > Das erste mit manueller Address- und Dateneingabe über Kippschalter. ;-) Würde für eine einfachen Bootloader sogar reichen. Muss ja nicht viel rein: STI-UART initialisieren, <n> Bytes reinziehen, springen.
A. K. schrieb: > Fast alle 4000er erlauben nur Vdd+0,5V. Die 4049/4050 mit abweichender > Eingangsschutzschaltung sind die Ausnahme. Autsch, dachte es wär ein 4049 mit Schmitt-Trigger. Ich hätte das Datenblatt doch richtig anschauen sollen. A. K. schrieb: > Würde für eine einfachen Bootloader sogar reichen. Muss ja nicht viel > rein: STI-UART initialisieren, <n> Bytes reinziehen, springen. Ich halte die Idee auch nicht für ganz abwegig. Für modernere EPROMs würde die Schaltung auch noch etwas einfacher werden. Die Schaltung auf dem Photo habe ich mal zusammengeklopft, um ein EEPROM zu programmieren. Die könnte man auch für EPROMs erweitern.
A. K. schrieb: > Bizarr: Wenn RAM2 ein EEPROM ist und per Port reingemappt wird, dann hat > man zwar 32KB EPROM und 32KB EEPROM, aber 0 KB RAM. Was soll dieser > Spuk? Das EEPROM dient hier nur als eine Art Disk für SPS- Anwenderprogramme. Diese werden dann vor Ausführung via CPU-Register in das RAM kopiert.
:
Bearbeitet durch User
Weiter oben jat jemand behauptet, das Schrittbetrieb nur bei S-RAM geht. Aber es geht auch mit D-RAM. Mit ein paar FF geht es aber. Bei KRAMER bin ich fündig geworden. Reinkopieren möchte ich es nicht, mit dem Nachfolger des DDR-Militärverlages ist nicht zu spaßen.
Michael_ schrieb: > Weiter oben jat jemand behauptet, das Schrittbetrieb nur bei S-RAM geht. > Aber es geht auch mit D-RAM. > Mit ein paar FF geht es aber. Bei KRAMER bin ich fündig geworden. > Reinkopieren möchte ich es nicht, mit dem Nachfolger des > DDR-Militärverlages ist nicht zu spaßen. Der Jemand war ich, gib mal die Seitennummer.... (Die Veröffentlichung einer Textstelle als Auszug bringt Dich in keinerlei Copyrightprobleme, Du kopierst ja nicht das Buch, sondern zitierst) Das das Prinzipiell funktioniert wenn der Refresh weiter gewährleistet ist, ist klar, ich habe aber mit kommerziellen Rechnerbausteinen des K1520 Systems zu tun gehabt, da war keine Eigenbauhardware involviert die das hätte bewerkstelligen können. Das der Einzelschrittbetrieb mit einer sogenannten Bedieneinheit K7622, die eine Refreshlogik enthielt, möglich war, ist eine andere Baustelle... Gruß, Holm
Michael_ schrieb: > Es ist Bild 1.26 S.39. Und was läßt dich glauben, die da gezeigte Simpel-Schaltung würde mit dRAM funktionieren? Die hält /WAIT schlicht aktiv und in dieser Zeit passiert auf dem Bus nichts, insbesondere auch kein Refresh. XL
Hier noch die Schaltung für alle, die nicht wissen was "der Kramer" ist. Oder die ihn gerade nicht haben ;) XL
Ja, habe den Kramer und hatte ja nach der Seite gefragt. Michael_ dies ist eine "normale" schaltung die den Prozessor so lange im Wait festhält, bis man die Schritt-Taste wieder drückt. Im Wait Zustand hält der Prozessor alle seine Signale statisch am Bus gleich solange /WAIT aktiv ist. Damit entfallen aber sämtliche Refreshcyclen auf dem Bus und der DRAM verliert deshalb seinen Inhalt. Klar funktioniert die Schaltung auch mit DRAM, aber der DRAM funktioniert nicht mit der Schaltung... Um das zu erreichen ist deutlich mehr Aufwand erforderlich, man muß dem Prozessor nach jedem Befehl den BUS wegnehmen und den Refresh selbst durchführen. Gruß, Holm
Allein - wo kriegt man heute noch passendes DRAM in passender Grösse? Vorzugsweise in der 16Kbit Version mit 3 Spannungen. Daher muss man wohl gezwungenermassen mit SRAM vorlieb nehmen und kann nicht ausprobieren, nach wievielen Sekunden der Inhalt tatsächlich entschwindet.
A. K. schrieb: > Allein - wo kriegt man heute noch passendes DRAM in passender Grösse? > Vorzugsweise in der 16Kbit Version mit 3 Spannungen. Daher muss man wohl > gezwungenermassen mit SRAM vorlieb nehmen und kann nicht ausprobieren, > nach wievielen Sekunden der Inhalt tatsächlich entschwindet. Machst Du Witze? U256/4116/K565RU3A habe ich da, sogar K565RU1 aka 2107, neu in OVP.. ...sagt Dir evita.lt was? Gruß, HOlm
Holm Tiffe schrieb: > Machst Du Witze? Ja, gelegentlich schon. > ...sagt Dir evita.lt was? Das Mädel kenn ich nicht und mein Litauisch ist nicht so besonders. > U256/4116/K565RU3A habe ich da Ich fürchte, Christian bleibt dennoch lieber bei seinem etwas aus der Zeit fallenden SRAM.
:
Bearbeitet durch User
A. K. schrieb: > Holm Tiffe schrieb: >> Machst Du Witze? > > Ja, gelegentlich schon. > >> ...sagt Dir evita.lt was? > > Das Mädel kenn ich nicht und mein Litauisch ist nicht so besonders. Das ist aber eine echte Bildungslücke. Wenn Du nicht so gut in Litausch bist, empfehle ich Dir mal auf den "EN" Link ganz oben zu clicken, es sei denn Du bevorzugst "RU". Anmerkung: Litauen ist EU Land. > >> U256/4116/K565RU3A habe ich da > > Ich fürchte, Christian bleibt dennoch lieber bei seinem etwas aus der > Zeit fallenden SRAM. Ich hoffe es inständig. Gruß, Holm
Holm Tiffe schrieb: > Das ist aber eine echte Bildungslücke. Ok, dann also in Englisch. Und was soll ich da finden? Suchen funktioniert bei mir nicht, das Angebot russischer Chips sagt mir nichts, deren Datasheets kann ich nicht lesen, und der Rest ist teils leicht angestaubt aber nicht derart exotisch.
:
Bearbeitet durch User
Logisch das Du fragst woher man irgendwelches Zeuch bekommt.. ist so ähnlich wie bei Christian. "Verstehe ich nicht" oder "kann ich nicht lesen" oder "sagt mir nichts" ist so ziemlich das Selbe.. Kennst Du noch ein Angebot für einen 8080A für 62 Cent? Gruß, Holm
Holm Tiffe schrieb: > Kennst Du noch ein Angebot für einen 8080A für 62 Cent? Nö. Aber wenn ich einen suchen würde, dann wärs mir egal ob der 0,62€ oder 6,20€ kostet, denn ich bräuchte ganz sicher keine 100 Stück davon. Abgesehen davon finde ich dort zwar einen 8085AH für 5,50@, aber keinen 8080A. Jedenfalls nicht unter Mikroprozessoren.
Moin, habe nichts weiter gemacht heute aber mal im "Keser Meder" gelesen, dem DDR Schmöker über U8.... . Sehr gut beschrieben aber ich finde es etwas amüsant wie die Autoren es als "Entwicklung der DDR" hinstellen, ohne ein Wort darüber zu verlieren, dass das Ding re-engineered wurde. Wie weiss ich nicht, entweder aus der Funktion her nachgebaut oder direkt von der Chipmaske? Von der Diadaktik aber zehnmal besser zu lesen als so mache engl. Literatur.
Holm Tiffe schrieb: >> Allein - wo kriegt man heute noch passendes DRAM in passender Grösse? > > ...sagt Dir evita.lt was? Danke. Hat lang gedauert, aber irgendwann fiel der Groschen. ;-) Auf die rhetorische Frage erwartete ich nämlich keine Antwort.
:
Bearbeitet durch User
Na gut, jetzt bin ich mal dran mit nicht verstehen, aber offensichtlich hast Du raus bekommen was man wie konvertieren muß damit die Seite interessant wird... Gruß, Holm
Christian J. schrieb: > Moin, > > habe nichts weiter gemacht heute aber mal im "Keser Meder" gelesen, dem > DDR Schmöker über U8.... . Sehr gut beschrieben aber ich finde es etwas > amüsant wie die Autoren es als "Entwicklung der DDR" hinstellen, ohne > ein Wort darüber zu verlieren, dass das Ding re-engineered wurde. Wie > weiss ich nicht, entweder aus der Funktion her nachgebaut oder direkt > von der Chipmaske? > Von der Diadaktik aber zehnmal besser zu lesen als so mache engl. > Literatur. Kannste denn wenigstens die Autoren beim richtigen Namen nennen? Der U880 ist in der DDR entwickelt worden, auch wen der Z80 kompatibel ist. Ob der re-engeneered worden ist, oder ob die Masterbänder vorlagen wie einige Informanten behaupten, sei dahin gestellt. Fakt ist allerdings das MME den Z80 besser im Griff hatte als Zilog. Meinen verschwommenen Infos nach ist KnowHow Richtung Zilog zurück geflossen, MME (später Thesys) konnte die besseren ICs bauen. (Ist auch nicht verwunderlich, Zilog selber hatte wohl keine Fabs. In der DDR ist aber richtig Entwicklungsaufwand in die Dinger gesteckt worden) Gruß, Holm
Holm Tiffe schrieb: > Na gut, jetzt bin ich mal dran mit nicht verstehen, aber offensichtlich > hast Du raus bekommen was man wie konvertieren muß damit die Seite > interessant wird... Hab ich nicht versucht, weil ich nicht auf der Suche nach dem Speicher bin. Eine rhetorische Frage ist eine, bei der man keine Antwort erwartet. Sollte ausdrücken, dass Z80 Kram im Handel deutlich häufiger zu finden sein dürfte, als antikes 3-Spannungs-DRAM. Mit Russen und Ablegern hatte ich da nicht gerechnet, die habe ich nicht auf dem Radar (Wessi eben ;-).
:
Bearbeitet durch User
Holm Tiffe schrieb: > Fakt ist allerdings > das MME den Z80 besser im Griff hatte als Zilog. Meinen verschwommenen > Infos nach ist KnowHow Richtung Zilog zurück geflossen, MME (später > Thesys) konnte die besseren ICs bauen. Kann es sein, daß Du Zilog mit den russischen Nachbauern verwechselst? http://zeptobars.ru/en/read/Zilog-Z80-Z0840004PSC (Auch die Links auf der Seite anschauen) > (Ist auch nicht verwunderlich, Zilog selber hatte wohl keine Fabs. In Zilog hat ohne Fab angefangen. Aber ziemlich bald eine gebaut. http://www.computerhistory.org/collections/catalog/102658073
Axel Schwenke schrieb: > Und was läßt dich glauben, die da gezeigte Simpel-Schaltung würde mit > dRAM funktionieren? Die hält /WAIT schlicht aktiv und in dieser Zeit > passiert auf dem Bus nichts, insbesondere auch kein Refresh. Glauben tu ich das schon, wissen nicht. Aber da Kramer D-RAM einsetzt, habe ich angenommen, das es geht. Getestet hab ich das nicht. Beim LC-80, welcher nur mit S-RAM arbeitet, wird das softwaremäßig mit NMI und der CTC gemacht. Gewisse Einschränkungen gibt es auch da. Christian J. schrieb: > Moin, > > habe nichts weiter gemacht heute aber mal im "Keser Meder" gelesen, dem > DDR Schmöker über U8.... . Sehr gut beschrieben aber ich finde es etwas > amüsant Amüsant haben wir damals(TM) darin die Aussage " Und wenn der Prozessor mal wieder Zeit hat, arbeitet er das vorhergehende Programm weiter ab" gefunden. Heute normal, aber damals mit starrer TTL- oder Analogtechnik war das etwas ganz seltsames. Kennt ihr noch "ELISA"? Damals(TM) der blanke Wahnsinn!
Michael_ schrieb: > Beim LC-80, welcher nur mit S-RAM arbeitet, wird das softwaremäßig mit > NMI und der CTC gemacht. Zwei paar Stiefel. Mit WAIT trackt man Buszyklen, HEX Anzeige oder was auch immer. Mit NMI gibts Single-Stepping im Debug-Monitor.
Leo C. schrieb: > Holm Tiffe schrieb: >> Fakt ist allerdings >> das MME den Z80 besser im Griff hatte als Zilog. Meinen verschwommenen >> Infos nach ist KnowHow Richtung Zilog zurück geflossen, MME (später >> Thesys) konnte die besseren ICs bauen. > > Kann es sein, daß Du Zilog mit den russischen Nachbauern verwechselst? > http://zeptobars.ru/en/read/Zilog-Z80-Z0840004PSC > (Auch die Links auf der Seite anschauen) > > >> (Ist auch nicht verwunderlich, Zilog selber hatte wohl keine Fabs. In > > Zilog hat ohne Fab angefangen. Aber ziemlich bald eine gebaut. > http://www.computerhistory.org/collections/catalog/102658073 Nein, ich verwechsele Nichts. Ich bezweifele aber, das die Russen die Chips selbst gemacht haben, die haben zwar alles Mögliche selbst gemacht, beim Z80 vermute ich aber nur Zyklus II. Deswegen gibt es IMHO auch Z80 in russischem Keramikgehäuse mit russisch aussehender Schrift und "80-CPU MME". Mich wundert nicht, das die Dies von Zilog und MME unterschiedlich sind. Die Annahme man könne einen Chip einfach so nachbauen, ist völliger Blödsinn. Selbst wenn man dann die Innenschaltung kennt, muß man diese auf eine verfügbare Technologie umsetzen, das heißt i.A. auch neues Layout. Aus diesem Grunde finde ich auch das seltsamerweise übereinstimmende leere Feld auf dem Chip putzig und es weist darauf hin, das die Chips alle aus der selben Fab kommen. Die Tatsache das irgend jemand ein "much denser peripherals layout" hat, heißt nicht das das irgendwie besser funktionieren muß, im Gegenteil. Wenn der Chip kleiner ist, ist es i.A. billiger, aber die Stromtragfähigkeit der Transistoren geht zurück, damit kann man u.U. einen externen Bus nur langsamer umladen.. Wenn die CPU selbst kleiner ist, läuft die eher schneller, aber dann braucht man auch kräftige Treiber. Fällt Dir was auf? Gruß, Holm
Zilog Z80 = 1976, MME U880 = 1980. Bisschen spät für nützliche Info von MME zu Zilog. Abgesehen davon wars nicht lizenziert. Mit Reproduktion über geklaute Masken wärs voll kompatibel, nicht bloss beihnahe.
:
Bearbeitet durch User
Hallo, wie auch immer ... ich habe noch keine russ Chips gehabt, weiss aber dass die natürlich auch welche bauen können. Wieso auch nicht. Allerdings billiger über die Auslandslieferanten. Für die DDR galt ja das Sperrabkommen, die haben sogar eine VAX damals in vielen teilen reingeschmuggelt, weiss noch wie das durch die Presse ging. http://www.focus.de/politik/deutschland/geheimdienste-heisse-stasi-scheiben_aid_149145.html "In der Tat tauchen in Stasi-Unterlagen neben kleinen Techno-Schiebern auch namhafte Westkonzerne auf: Ob Großrechner und Chiffriergeräte von Siemens, Abhöranlagen von Rhode & Schwarz oder VAX-Computer der US-Marke DEC – Stasi und KoKo beschafften alles. Sogar komplette Leiterplattenfabriken wurden via Schweiz und Österreich in die DDR geschleust (FOCUS 18/94)." Einen Chip aber kann man nicht 1:1 nachbauen, wohl aber seine Funktionen auf ein eigenes Design kopieren, also die Z80 nur als Vorlage nehmen. Egal..... sehr gutes Buch!
Christian J. schrieb: > Einen Chip aber kann man nicht 1:1 nachbauen, Doch, wenn man neben den Masken auch die Fabtechnik geklaut hat.
A. K. schrieb: > Christian J. schrieb: >> Einen Chip aber kann man nicht 1:1 nachbauen, > > Doch, wenn man neben den Masken auch die Fabtechnik geklaut hat. Und wie willst du die Masken aus einer Fab rausbringen? Die sind wie Staatsgeheimnisse. Ich habe sowas einmal erlebt, 1998 als ich noch bei der Chipschmiede XYZ war.... da wurden die Masken für MP3 und DSL "geklaut", d.h. irgendwie fanden die ihren Weg zu den Amis damals, vermutlich abgehörte emails etc.... gab ganz schön Ärger.
Christian J. schrieb: > Und wie willst du die Masken aus einer Fab rausbringen? Die sind wie > Staatsgeheimnisse. Eben. ;-) Genau damit hatte man reichlich Übung. Also an Staatsgeheimnisse ranzukommen. Weshalb sollte das bei Firmen nicht möglich gewesen sein?
Hier einiges dazu, James Bond ist ein Waisenknabe dagegen :) http://computer-oiger.de/2011/08/26/die-teure-jagd-auf-den-megabit-chip/2189 erledigten die sog "Beschaffungsorgane" ... grins :-) Implanter, Lithografiemaschinen und andere Anlagen, die für die DDR-Chipentwicklung dringend benötigt wurden, aber unter dem US-Technologie-Embargo CoCom standen, wurden meist mit hohen Bestechungsgeldern (in Devisen natürlich) im Westen eingekauft und dann über verschlungenen Wegen in die DDR gebracht, um diese Geschäfte zu verschleiern. Brief von Prof. Volker Kempe an Erich Honecker, 1986: „Die in der Republik hergestellte Rechentechnik bleibt in Menge, Zuverlässigkeit, Leistungsvermögen, Preis, Ausstattung und Software besorgniserregend hinter dem internationalen Stand zurück.“
Christian J. schrieb: > http://computer-oiger.de/2011/08/26/die-teure-jagd-auf-den-megabit-chip/2189 Besonders süss finde ich den abschliessenden Leserbrief: "Hätte die DDR 10 Jahre länger existiert, war das aus der Sicht vieler Spezialisten durchaus möglich im Schnitt den Standard der NSW Länder zu erreichen und in Teilbereichen sogar zu übertreffen ……" Dieser Stil hat sich seit Chruschtschow kaum geändert. ;-) Will das nicht schlechtreden. Aber das Problem war und ist nicht so sehr, mit mörderischem Aufwand einen Gleichstand zu erreichen, sondern ihn zu halten. Die finanziellen Mittel dazu waren einfach nicht da. Wie das läuft konnte man in den letzten 10 Jahren beobachten. Wieviele Firmen gibt es noch, die hochaktuelle Prozesstechniken beherrschen? Diese Zahl hat sich bös eingedampft. Warum? Enormes Investitionsvolumen, in jahrelanger Vorfinanzierung ohne das dafür Geld reinkommt. Kombiniert mit dem Schweinezyklus der Nachfrage hat das fast alle zu Aufgabe/Verkauf gezwungen. Ok, der Schweinezyklus entfällt in der Planwirtschaft.
:
Bearbeitet durch User
"Wobei das Nachbauen eine Kunst für sich war und einer Eigentwicklung an komplexität nicht nachstand. Die ORiginale wurden nur benötigt um 100% SW kompatibel mit dem Westen zu sein, um z.B. zu verhindern, dass SW aus dem Westen ohne änderung lauffähig ist." Ich kann nicht mehr ..... komme aus dem Grinse nicht mehr heraus :-) ROFL.
Die Z80 und U880 waren nicht ganz gleich. Das konnte man an den Pseudo-Befehlen erkennen. Es gab auch noch andere Hersteller. Mal gingen bestimmte Befehle, mal nicht.
Noch eine späte Frage: Was nehme ich als Kommunikations Platform? Mir schwebt da minicom vor, zudem es auch viele Protokolle beherrscht. Allerdings weiss ich nicht ob das ein Program ist, was auch Befehle senden kann, so dass es komfortabel ist. Ich bin grad dabei unter Linux eine Anwendung auf Konsole zu schreiben, die mir alles reinholt was von dem Z80 kommen wird und gleichzeitig meine Eingaben an ihn sendet. Vor allem will ich es komfortabel haben Intel Hex Files upzuloaden und nicht erst umständlich in minicom eine Datei öffnen und dann zig Tastendrücke später sie abzusenden. Aufgrund des Vorhandenseins aller Werkzeuge kommt für mich da nur Linux in Betracht, idealerweise die Kommandozeile. Oder gibt es da schon etwas in der Richtung, was gut passt? Hier ist so eine DDR-PIO .... könnte ich ja mal kaufen, um zu sehen ob sie kompatibel ist. http://www.ebay.de/itm/UB855D-DDR-MME-2-5MHz-Z80-PIO-paralleler-Interface-Chip-fur-Z80-U880-DIP40-/231125374265?pt=Bauteile&hash=item35d0255539
PS: Für das Ding hier habe ich damals 100 DM ausgeben müssen von meinem tasschengeld als 17 jähriger..... wahnsinn! Die habe ich heute noch aber sind beide tot nach 20 Mal brennen.....
Christian J. schrieb: > Oder gibt es da schon etwas in der Richtung, was gut passt? Für den von mir skzzierten ersten Bootloader: cp binfile /dev/ttyXXX Serielles Terminal-Programm für Linux gibts natürlich auch.
So eine Sch... Wollte auch mal wieder etwas mit Z80 versuchen, hab die ganzen Kisten durchsucht und natürlich festgestellt, dass gerade die mit den Z80 und Peripherie fehlt. Ist vielleicht besser so. Aber was anderes hab ich Depp aufbewahrt, wer sich noch erinnern kann...
Christian J. schrieb: > Was nehme ich als Kommunikations Platform? Mir schwebt da minicom vor, > zudem es auch viele Protokolle beherrscht. Minicom und Kermit habe ich nie wirklich benutzt. Ich erschlage solchen Kleinkram mit Picocom. Mit den lrzsz-Tools kann man damit auch X/Y/Z-Modem machen, Binärdateien gehen aber auch. > Ich bin grad dabei unter Linux eine Anwendung auf Konsole zu schreiben, > die mir alles reinholt was von dem Z80 kommen wird und gleichzeitig > meine Eingaben an ihn sendet. Was bist du umständlich. :-) "picocom --send-cmd cat" im richtigen Ordner starten. Die Datei sendest du dann mit Ctrl+A, Ctrl+S, Dateiname, Enter. Statt "cat" solltest du aber ein besseres Programm nehmen, wenn du Rückmeldungen magst (z.B. "pv", oder gleich "sz" für ZModem).
Michael_ schrieb: > Die Z80 und U880 waren nicht ganz gleich. Das konnte man an den > Pseudo-Befehlen erkennen. Es gab auch noch andere Hersteller. > Mal gingen bestimmte Befehle, mal nicht. Das ist einfach nicht wahr. Sämtliche Befehle waren implementiert, auch die undokumentierten. Die CPUs verhielten sich absolut identisch. Irgendwas war aber mal mit dem CTC, weiß aber nicht mehr was genau. Ich habe zu DDR Zeiten in der Halbleiterbranche gearbeitet und bin deshalb nicht auf seltsame Berichte angewiesen. Ja, ich habe auch an importierten Embargomaschinen gearbeitet. Gruß, Holm
Christian J. schrieb: > Noch eine späte Frage: > [..] > Hier ist so eine DDR-PIO .... könnte ich ja mal kaufen, um zu sehen ob > sie kompatibel ist. > > http://www.ebay.de/itm/UB855D-DDR-MME-2-5MHz-Z80-PIO-paralleler-Interface-Chip-fur-Z80-U880-DIP40-/231125374265?pt=Bauteile&hash=item35d0255539 Die PIO ist kompatibel, aber im metrischen Raster. Das auf Deinem Bild ist ein Z8 in der Entwicklerversion. Mit 8748/9 kann ich Dir sicherlich noch aushelfen, die Teile sind aber dumm wie ein Sack Holz... Gruß, Holm
Christian J. schrieb: > "Wobei das Nachbauen eine Kunst für sich war und einer Eigentwicklung an > komplexität nicht nachstand. Die ORiginale wurden nur benötigt um 100% > SW kompatibel mit dem Westen zu sein, um z.B. zu verhindern, dass SW aus > dem Westen ohne änderung lauffähig ist." > > Ich kann nicht mehr ..... komme aus dem Grinse nicht mehr heraus :-) > ROFL. Wo hast Du denn den Schmarrn her? Gruß, Holm
Holm Tiffe schrieb: > Das ist einfach nicht wahr. Sämtliche Befehle waren implementiert, auch > die undokumentierten. Die CPUs verhielten sich absolut identisch. Wikipedia: "Die Unterschiede beschränken sich auf spezielle Details wie ein nicht gesetztes CY-Flag bei dem OUTI-Befehl." und "The U880 is an almost identical copy of Zilog's 8-bit Z80 microprocessor. Differences include absence of CY flag setting in OUTI command (when L goes zero) and another behaviour of hidden bus register seen through undocumented F3 and F5 flags." Quellen werden dort leider nicht genannt. Muss folglich als unbestätigt gelten. Es ergibt in exakt dieser Formulierung auch keinen Sinn, denn laut Zilog Doku lässt OUTI das C Flag unverändert.
:
Bearbeitet durch User
A. K. schrieb: > Holm Tiffe schrieb: >> Das ist einfach nicht wahr. Sämtliche Befehle waren implementiert, auch >> die undokumentierten. Die CPUs verhielten sich absolut identisch. > > Wikipedia: "Die Unterschiede beschränken sich auf spezielle Details wie > ein nicht gesetztes CY-Flag bei dem OUTI-Befehl." und "The U880 is an > almost identical copy of Zilog's 8-bit Z80 microprocessor. Differences > include absence of CY flag setting in OUTI command (when L goes zero) > and another behaviour of hidden bus register seen through undocumented > F3 and F5 flags." > > Quellen werden dort leider nicht genannt. Muss folglich als unbestätigt > gelten. Es ergibt in exakt dieser Formulierung auch keinen Sinn, denn > laut Zilog Doku lässt OUTI das C Flag unverändert. Ich glaube das der Wikipedia aber nicht und halte das für Unfug. Es wäre auch ein ziemlicher Quatsch mit Sowas bei sonst identischem Befehlssatz einen Prozessor inkompatibel machen zu wollen, meinst Du nicht. Egal. Ich werde das mal aufgreifen und bei www.robotrontechnik.de diskutieren. Das sollte sich relativ leicht verifizieren lassen. Ich denke eher das sich das oben beschriebene Verhalten um steinalte Bugs in den ersten Masken gehandelt hat, auch bei Zilog. Jemand hat dann sozusagen 2 verschiedene paar Schuhe verglichen. Gruß, Holm
Holm Tiffe schrieb: > Es wäre auch ein ziemlicher Quatsch mit Sowas bei sonst identischem > Befehlssatz einen Prozessor inkompatibel machen zu wollen, meinst Du > nicht. Wollen mit Sicherheit nicht. Wenn das geschieht, dann unbeabsichtigt. Die genannte Auswirkung auf die eigentlich undefinierten F3/F5 Flags würde gut in diese Kategorie passen, vorausgesetzt da wurden nur Prinzip und Layout übernommen, nicht aber Masken auf eigene Fabtech portiert. > Egal. Ich werde das mal aufgreifen und bei www.robotrontechnik.de > diskutieren. Das sollte sich relativ leicht verifizieren lassen. Ich habe mal kurz die Historie im deutschen Wikipedia Artikel danach durchforstet. Diese Information kam erst in 2012 von "wdwd" = Walter Dvorak rein. Den müsste man fragen können. https://de.wikipedia.org/w/index.php?title=MME_U880&diff=103624554&oldid=103372272 Edit: wdwd hat das möglicherweise nur aus der englischen Version übersetzt. Da wars 2007, ein Bystrov Dmitry Mikhailovich: https://en.wikipedia.org/w/index.php?title=U880&diff=163599069&oldid=155211715 PS: Oder MME ist in eine Falle gelaufen. In der gestern verlinkten Unterhaltung kann man ja lesen, dass bewusst welche eingebaut wurden. Damals waren es die Japaner, die alles klauten was man brauchen konnte.
:
Bearbeitet durch User
Christian J. schrieb: > PS: Für das Ding hier habe ich damals 100 DM ausgeben müssen von meinem > tasschengeld als 17 jähriger..... wahnsinn! Die habe ich heute noch aber > sind beide tot nach 20 Mal brennen..... Lag das an den Chips oder am unsensiblen Brenner? Intel adressierte damit die Profis, nicht die Hobbyisten. Jedenfalls waren diese Preise nicht unwesentlich für all die EMUFs und EPACs verantwortlich, mit denen Hobbyisten ihre Controller strickten. Ein 6504 mit EPROM und 6532(RAM,Timer,IO) kostete ein Bruchteil und hatte zudem den gleichen Prozessor wie viele Pre-PCs. Es erklärt auch den späteren Erfolg von Microchip in dem Sektor, dank der PIC16 mit Fenster-EPROM. Auch die waren viel billiger.
:
Bearbeitet durch User
Holm Tiffe schrieb: > Mit 8748/9 kann ich Dir sicherlich noch aushelfen, die Teile sind aber > dumm wie ein Sack Holz... > > Gruß, > > Holm Die würden nur rumliegen wie die GU80 Röhre als Deko :-) Was heisst dumm? Die tun alles was man ihnen sagt. Hatte damals den Keil C Compiler und habe viel damit gemacht, Basis 8031, MCS 51 Befehlssatz. Völlig normale Mikrocontroller mit etwas sparsamer Ausrüstung an Bord. Aber ok sonst, finde die mit Fenster sowieso cool.
A. K. schrieb: > Intel adressierte damit die Profis, nicht die Hobbyisten. Missverständlich formuliert. Damit war der Preis gemeint.
:
Bearbeitet durch User
A. K. schrieb: > Es erklärt auch den späteren Erfolg von Microchip in dem Sektor, dank > der PIC16 mit Fenster-EPROM. Auch die waren viel billiger. Oh ja, 1996 als ich meinen ersten Job als HW Entwickler hatte waren "JW" Versionen in, selbst die 8 Pinner hatten kleine Fensterchen. Nur war ihre Haltbarkeit klein, mehr als 10 Löschvorgänge mit einem normalen Löschgerät erreichte ich auch nicht. Dann kam Flash Ende der 90iger und alles wurde gut. PIC habe ich bestimmt 6 Jahre benutzt, Hobby und Arbeit und die stehen AVR in nichts nach, alles genauso komfortabel. Selbstverständlich auch Single Step Hardware Debugging :-) Die JW kosten aber heute rund 10 USD / Stück, gibt es aber noch.
Christian J. schrieb: > Hatte damals den Keil C Compiler > und habe viel damit gemacht, Basis 8031, MCS 51 Befehlssatz Das nehme ich dir nicht so ohne weiteres ab. MCS-48 (und dein Foto ist ein 8749) war wirklich dumm wie ein Sack Holz und konnte nicht mal von alleine über eine Pagegrenze laufen, ohne das man ihn per AJMP dahin lockte. Das führte bei mir dann zu so abenteuerlichen Konstruktionen wie 'Alle INT auf Page 2', denn Page 0 und 1 waren besetzt vom Hauptprogramm etc. Ich habe es schon beim IBM PC Keyboard Kontroller bewundert, wie die Jungs in diesen MC was vernünftiges reinbekommen haben - der MCS-51 war dagegen Labsal für den Programmierer...
Matthias Sch. schrieb: > Das nehme ich dir nicht so ohne weiteres ab. MCS-48 (und dein Foto ist > ein 8749) war wirklich dumm wie ein Sack Holz und konnte nicht mal von > alleine über eine Pagegrenze laufen, ohne das man ihn per AJMP dahin > lockte. > Das führte bei mir dann zu so abenteuerlichen Konstruktionen wie 'Alle > INT auf Page 2', denn Page 0 und 1 waren besetzt vom Hauptprogramm etc. > Ich habe es schon beim IBM PC Keyboard Kontroller bewundert, wie die > Jungs in diesen MC was vernünftiges reinbekommen haben - der MCS-51 war > dagegen Labsal für den Programmierer... Sorry, mein Fehler, MCS 48 war eine Katastrophe, Page Jumg+127 Bytes. habe aber noch ein Board damit hier aus meinen Jugendjahren. Ich meinte den Nachfolger, den 51er.
Matthias Sch. schrieb: > konnte nicht mal von > alleine über eine Pagegrenze laufen, Das Datenblatt mal gelesen? Oder nur vergesslich? Der MCS48 war zu seiner Zeit nicht schlecht. Wir haben den millionenfach eingesetzt, zum Schluss mit 2764 als externem Programmspeicher. Du hast insofern recht, dass man ihn nicht mit Klicki-Bunti IDEs programmieren konnte. Assembler war schon notwendig. Und man sollte etwas Übung haben. Der MCS51 wird heute noch viel eingesetzt. Die Architektur hat durchaus ihre Vorteile.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.