Moin, vielleicht kennen die es, die wie ich Mitte 40 sind und in den 80igern Lochraster Aufbauten mit 6502 oder Z80 gemacht haben. Auch ich habe noch solche Kabelverhaue gefunden, die Leiterplatten aus Presspapier sind allerdings extrem dunkelbraun geworden und ich kann nichts mehr in Betrieb nehmen, da ich weder Eprom Simulator habe, noch Brenner, noch die alten Software tools von damals unter DOS. Das Netz ist ja voll davon aber das macht es auch unübersichtlich. Gibt ja teilweise Monsterprojekte mit Ram Disk usw. Habe hier noch Original Z80er liegen, die rund 20 Jahre alt sind im DIP40 und auch einige 68000er, Format Milchschnitte im Keramik Gehäuse. Auch nicht jünger. Aber der 68000 ist wohl etwas zu komplex um das auf Lochraster aufzubauen. Und ein ualter verstaubter "Microprofessor" liegt hier auch noch, Asemberprogramme auf Papier, in Codes mit Tabelle umrechnen, eintippen als Hex .... kenne ich noch aber war "nervtötend". Wer mal einen IMSAI programmiert hat weiss was ich meine, die müssen damals unendlich viel Zeit gehabt haben. Meine Vorstellung, um das Ganze etwas handlicher zu machen sind Verzicht auf VGA Ausgabe, keine Peripherie usw. Woher nehmen und nicht stehlen? 1. Schaltplan für Minimalsystem mit Uart, PIO, Ram, ROM => Ok, Internet 2. Eprom Emulator? 3. Eprom Brenner und Eproms => ibäh, schon bestellt 4. PIO Bausteine, Timer, zb 8155, 8153 .... finde ich schon noch irgendwo. 5. C Cross Compiler für Linux oder Windows? Ausgabe: Hex File für Brenner 6. Assembler? Och nö..... das dauert ja ewig da was Gescheites zu programmieren. Alternativ würde mir folgende Lösung gefallen: Ein RS232 Terminalanschluss am Z80 System, Uart-USB Konverter, im EPROM ein komfortabler Monitor und ich bediene das ganze aus der Konsole von Linux heraus, so wie ich mich auf einm Raspi auch einlogge. Programme sollten hochgeladen werden können und im RAM ausgeführt werden. Hat sich schonmal jemand an sowas gewagt? So ein bisschen Old School Feeling aber mit modernen Elementen? Gruss Christian
Vor langer Zeit habe ich so was mal mit einem 6502 aufgebaut, allerdings mit EPROM Emulator als Hilfe. Für den 68000 gibt es GCC als Cross-Compiler und auch Assembler. Für den Z80 gibt es zumindest reichlich Simulatoren - man kann also ggf. das Debugging erst mal auf dem PC machen und erst dann auf die richtige Hardware gehen - ohne EPROM Emulator ist das recht hilfreich. Unter Linux stehen die Chancen nicht schlecht auch eine Cross Assembler und ggf. sogar Compiler zu finden - notfalls auch als Compiler auf einem Simulierten Z80 Computer (CP/M ?) aus der Steinzeit. Die Idee mit dem Minimalsystem als eine Art Bootloader ist gut. Das muss für den Anfang keine kompletter Monitor sein - ein Bootloader über UART reicht für den Anfang. Das spart für die Entwicklung den Umweg über das EPROM. Ein statisches CMOS RAM mit Stützbatterie ist ggf. eine Alternative zu EPROM. Den Bootloader/Monitor könnt man ggf. sogar auf einem modernen µC laufe lassen, der parallel mit am BUS hängt, und Wahlweise zum Z80 läuft. Wenn man sowieso nicht in ASM Programmiert, braucht man auch keine Antike CPU. In C merkt man davon nicht viel. So schlimm ist ASM auch nicht. Auch ist es mit einer ggf. nicht normalen Hardware ggf. nötig den Startcode des Compilers anzupassen, ganz ohne ASM wird es also schwer.
Wozu das Ganze? Es hat damals (tm) wahnsinnig Spass gemacht, aber die Sachen haben sich gewaltig verändert. Ich seh da absolut keinen Sinn mehr drin, da lass ich nicht mal Nostalgie mehr gelten. Mit einer simplen Ein-Chip-Lösung schlägst du um Längen alles, was selbst ein getuntes Z80-Komplettsystem jemals konnte. Und das, ohne eine rel. komplizierte und inzwischen teure Hardware zu bauen. Die Zeit kommt nie wieder, der nutzbare Lerneffekt ist auch eher klein. Falls du dennoch was damit machen willst - habe ich alles noch da, bringe es einfach nicht übers Herz, das Zeug zu entsorgen. Aber ich weiss genau, dass ich es nie wieder anfassen werde.
Hallo, > vielleicht kennen die es, die wie ich Mitte 40 sind und in den 80igern > Lochraster Aufbauten mit 6502 oder Z80 gemacht haben. äh, nein. Also, ja. Also, gemacht ("in der Mache") ja, aber andere Randbedingungen. :-) Ich bin seit langer Zeit mehr oder weniger unregelmäßig dabei (je nach Zeit und Lust), ein Z80-System aufzubauen. Der Winter steht vor der Tür, die notwendigsten Bestellungen sind eingetroffen, mal schauen. Im Augenblick läuft CP/M in 32 KB RAM, dazu gibt es hier irgendwo auch einen Threads von mir, oder zwei. > Aber der 68000 ist wohl etwas zu komplex um das auf Lochraster > aufzubauen. Ein 16 Bit breiter Bus ist mehr Löterei, ansonsten dürften die sich nicht besonders unterscheiden. Aber dafür gibt es ja den 68008. > Meine Vorstellung, um das Ganze etwas handlicher zu machen sind Verzicht > auf VGA Ausgabe, keine Peripherie usw. Nun, ich möchte daraus mal einen echten Computer bauen, d.h. es gibt ein einfaches Bussystem, wo man Peripherie und RAM nachstecken kann. > 1. Schaltplan für Minimalsystem mit Uart, PIO, Ram, ROM => Ok, Internet Ja, oder auch hier gibt es schon einige relativ minimale Schaltungen. > 2. Eprom Emulator? > 3. Eprom Brenner und Eproms => ibäh, schon bestellt > 4. PIO Bausteine, Timer, zb 8155, 8153 .... finde ich schon noch > irgendwo. Auf all das habe ich in meinem Konzept verzichtet und durch einen einzigen AVR ersetzt. Der Z80 ist als Anwendungsprozessor dem AVR als Boardcontroller untergeordnet. Der AVR kann den RAM selbstständig beschreiben und den Z80 resetten, erspart mir also das ROM, und ist außerdem (braucht ein zusätzliches schnelles Gatter) ein I/O-Gerät, welches UART, Floppy und (später) Timer bereitstellt. Wenn du mit nichts kompatibel sein musst, brauchst du auch die alten Bausteine nicht nachbilden. > 5. C Cross Compiler für Linux oder Windows? Ausgabe: Hex File für > Brenner SDCC ist ein optimierender C-Compiler, der u.a. den Z80 kennt und einige fertige Routinen mitbringt. > Ein RS232 Terminalanschluss am Z80 System, Uart-USB Konverter, im EPROM > ein komfortabler Monitor und ich bediene das ganze aus der Konsole von > Linux heraus, so wie ich mich auf einm Raspi auch einlogge. Programme > sollten hochgeladen werden können und im RAM ausgeführt werden. Noch enthält bei mir der AVR das Monitorprogramm, mit dem ich einen Speicherabzug (Hex-Datei) direkt in den Speicher schreiben kann. Außerdem kann man dort einstellen, welche Geräte in den Slots stecken (das Betriebssystem kann das dann auslesen und die entsprechenden Treiber laden). Gruß
Zu den 68000 gab es doch auch etliche interessante c't-Projekte. Die Artikel dazu sind auf DVD noch zu haben, notfalls bestimmt auch bei mir in Papierform, wenn ich lange genug suche.
P.S.: Ich hatte mal für eine Freundin ein paar Artikel zu dem Thema rausgesucht, vielleicht helfen sie ja (Heft/Seite/Titel): % c't 84/ 7 82 EPAC-80 (Prozessor Z80) % c't 84/ 8 93 Testprogramm für EPAC-80 (Prozessor Z80) % c't 85/ 3 47 Mehr als nur ein 16-bit-EPAC-95 (Prozessor TMS9995) % c't 85/ 3 52 EPAC-95 (Prozessor TMS9995) % c't 85/ 4 110 MONALISA: Monitor für EPAC-95 (Prozessor TMS9995) % c't 85/ 7 124 68000-Assembler-Programmierung unter RTOS % c't 86/ 6 60 Echtzeit-Multitasking mit RTOS/PEARL Teil 1: Mehrere Programme "gleichzeitig" - auf dem Atari ST % c't 86/ 6 76 EPAC-09 (Mit Prozessor 6809) % c't 86/ 7 62 Echtzeit-Multitasking mit RTOS/PEARL Teil 2: Umgang mit dem Betriebssystem % c't 86/ 8 38 Echtzeit-Multitasking mit RTOS/PEARL PEARL und Pascal - eine Gegenüberstellung % c't 86/ 8 94 Echtzeit-Multitasking mit RTOS/PEARL Teil 3: Programmieren in PEARL unter RTOS % c't 86/ 8 98 Cleo in neuem Gewand: Neue Disketten-Kommandos für RTOS/PEARL % c't 86/ 9 53 Echtzeit-Multitasking mit RTOS/PEARL Teil 4: Programmieren in PEARL unter RTOS % c't 86/10 80 Echtzeit-Multitasking mit RTOS/PEARL Teil 5: Maus, Grafik, Interrupt % c't 86/11 80 Echtzeit-Multitasking mit RTOS/PEARL Teil 6: Assembler-Programmierung in PEARL-Umgebung % c't 86/11 86 c't-KAT-Ce 68000-Einplatinensystem - Teil 1: Die Platine % c't 86/12 130 Echtzeit-Multitasking mit RTOS/PEARL Teil 7: RTOS-Pe(a)rlen % c't 86/12 156 c't-KAT-Ce 68000-Einplatinensystem - Teil 2: EPROM-Interna % c't 87/ 1 146 Echtzeit-Multitasking mit RTOS/PEARL Teil 8: Wir machen Musik... % c't 87/ 1 152 c't-KAT-Ce 68000-Einplatinensystem - Teil 3: REAL-Arithmetik % c't 87/ 2 88 EPAC 68008 Teil 1 % c't 87/ 2 92 Echtzeit-Multitasking mit RTOS/PEARL Teil 9: PEARL-Programme in EPROMs % c't 87/ 3 128 Echtzeit-Multitasking mit RTOS/PEARL Teil 10: Software-Upgrading % c't 87/ 3 134 Das "Grafische Kernsystem" in und unter PEARL % c't 87/ 3 140 EPAC 68008 Teil 3: RTOS % c't 87/ 5 94 PEARL-Texter - ein kleiner Editor für RTOS-UH % c't 87/ 5 148 EPAC 68008 Teil 3: P-Bus % c't 87/ 6 164 EPAC 68008 Teil 4: Scheibchenweise % c't 87/ 7 90 c't-KAT-Ce 68000-Einplatinensystem - Teil 4: KAT-Ce-Pascal % c't 87/ 7 94 Monsieur Fourier und Mister 68000: Schnelle Fourier-Transformation (FFT) mit der c't-KAT-Ce % c't 87/ 7 104 EPAC 68008-Programme auf Atari entwickeln % c't 87/ 9 166 Die c't-KAT-Ce mit doppelt soviel RAM % c't 87/ 9 168 RTOS-UH/PEARL für unseren Einplatinen-Computer % c't 87/ 9 168 RTOS-UH/PEARL für unseren Einplatinen-Computer % c't 88/ 6 92 Interrupt-Programmierung bei der c't-KAT-Ce % c't 88/ 7 156 EPAC 68000 1: Schaltung % c't 88/ 8 144 EPAC 68000 2: Software % c't 88/10 148 Task-Kommunikationssystem unter RTOS % c't 88/10 254 Pascal/Assembler-Entwicklungssystem für die KAT-Ce % c't 89/ 9 38 RTOS-UH/PEARL jetzt in Version 2.2 % c't 89/ 9 200 Einplatinen-Rechner KAT-Ce in Low-Power-Ausführun % c't 89/11 290 C für D- und EPACS
m68k ist nach wie vor eine von uCLinux unterstützte Architektur und wird gepflegt. Die kleinen Nachfolger der dicken 68000er sind z.B. der Dragonball M68(EZ/VZ)328, der in Palm Handhelds der ersten und zweiten Generation arbeitet (und auch im UcDimm und uCSimm). Ein kleines System könnte 2MB ROM/Flash und 8MB RAM haben, damit lässt sich ein 2.0er Linux bequem booten und zum Laufen bringen. http://www.uclinux.org/
Ich habe mich damals mit dem 68000er versucht. Geplant war ein Slot-System mit viel DRAM, hochauflösender Grafik, Diskettenlaufwerk, paralleler und serieller Schnittstelle, Betriebssystem und was einem in seiner jugendlichen Naivität sonst noch so alles in den Kopf schießt. Daraus geworden ist immerhin etwas, was rechnen konnte, und womit ich mich selber mit der schieren Rechenpower des Prozessors (verglichen mit dem 6502 in meinem Apple) beeindrucken konnte. Christian J. schrieb: > 1. Schaltplan für Minimalsystem mit Uart, PIO, Ram, ROM => Ok, Internet Da ich bei der Sache etwas lernen und auch eigene Ideen realisieren wollte, habe ich versucht, weitgehend mit dem Buch "M68000 Familie Teil 1 Grundlagen und Architektur" von Werner Hilf und Anton Nausch auszukommen. Zusätzlich habe ich aber auch einige Tipps aus einer 68000-Artikelserie in der Zeitschrift "Elektronik" übernommen. > 2. Eprom Emulator? Den hatte ich nicht, brauchte ihn aber auch nicht. Stattdessen programmierte ich einen Boot-Loader ins EPROM, mit dem die eigentliche Software über eine UART-Schnittstelle ins RAM geladen werden konnte. Da ich kein UV-Löschgerät hatte, musste der Loader möglichst auf Anhieb funktionieren, weswegen er äußerst minimalistisch gehalten war und im Wesentlichen dazu diente, einen 2nd-Stage-Loader zu laden, der dann seinerseits die eigentliche Software lud. Die Loader-Firmware legte ich in den oberen Adressbereich der EPROMs. An der Adresse 0 (Startadresse nach Reset) lag ein Jump-Befehl zur Anfangsadresse des Loaders. Dieses Vorgehen ermöglichte es in beschränktem Umfang, neue Versionen der Loader-Firmware zu brennen, ohne die EPROMs dafür löschen zu müssen. > 3. Eprom Brenner und Eproms => ibäh, schon bestellt EPROMs hatte ich zwar, aber keinen Brenner dazu. Da ich ihn ohnehin nur für die Programmierung des Boot-Loaders benötigte, habe ich mir etwas ganz Primitves bestehend aus Adress- und Daten-Latch und etwas Software für den Apple selbst gebastelt. > 4. PIO Bausteine, Timer, zb 8155, 8153 .... finde ich schon noch > irgendwo. Bei mir war die einzige Peripherie ein UART MC6850, der sowohl zum Laden von Programmen als auch zur Interaktion mit dem Rechner verwendet wurde. Ein Gegenstück mit dem gleichen Chip lötete ich als Steckkarte für den Apple zusammen. Für diesen schrieb ich auch ein einfaches Terminalprogramm. > 5. C Cross Compiler für Linux oder Windows? Ausgabe: Hex File für > Brenner Wie schon geschrieben wurde: Dafür gibt es den GCC (C-Compiler) und die Binutils (Assembler, Linker und noch ein paar weitere Tools). Ich hatte so etwas damals leider nicht zur Verfügung :-( > 6. Assembler? Och nö..... das dauert ja ewig da was Gescheites zu > programmieren. Der 68000 ist eigentlich dank vieler Register und 16/32-Bit-Arithmetik ganz angenehm in Assembler zu programmieren. Meinen 68000-Rechner programmierte ich anfangs noch direkt mit Hex-Codes bis der Leidensdruck hoch genug war, dass ich einen einfachen Assembler schrieb. Die Schaltung hatte ich wie du auf Hartpapierlochraster aufgebaut. Die Rückseite der CPU-Platine war ein dichter Pelz aus Schaltdraht. 16 Daten- und streckenweise noch mehr Adressleitungen, die sich durch das ganze System ziehen, sind eben nicht ganz ohne. Einen Verdrahtungsfehler zu korrigieren war etwa vergleichbar mit einer Herzoperation ;-) Bald nach Fertigstellung der CPU-Platine sind die Preise für den Atari ST und den Amiga so weit gefallen, dass mir die Weiterentwicklung des eigenen Rechners nicht mehr als lohnend erschien und ich meine Freizeit vorerst lieber in Softwareprojekte auf dem Amiga investierte. Ja, das waren noch Zeiten. Heute bekommt man die gesamte Schaltung von damals mit vergleichbarer Rechenleistung und sogar erweiterter Peripherie auf einem winzigen Chip (bspw. einem ATtiny) für weniger als 2% des Preises geliefert. Deswegen hätte ich heute keine Motivation mehr, das Projekt von damals wieder aufleben zu lassen. Es gibt inzwischen genügend spannendere Dinge im Bereich Hardware und Software, mit denen man sich die Zeit totschlagen kann :)
Christian J. schrieb: > Hat sich schonmal jemand an sowas gewagt? So ein bisschen Old School > Feeling aber mit modernen Elementen? Den Z80 gibts auch in modern. Das macht dann echt Spaß - immer noch. http://www.zilog.com/index.php?option=com_product&task=product&businessLine=1&id=77&parent_id=77&Itemid=57 fchk
Christian J. schrieb: > Hat sich schonmal jemand an sowas gewagt? Tausende. Sie sind alle an der Software gescheitert. Ein Universalcomputer ist ohne Software nutzlos und die zu schreiben, alleine ein Betriebssystem, ist tausendmal mehr Arbeit als ein paar Chips zusammenzulöten. Schon ein BIOS überfordert die meisten. Also bleibt nur, hardwarekompatibel zu vorhandener Software zu sein. CP/M inklusive PL/M und GEM ist heute im Source verfügbar. Oder man baut etwas mit dedizierter Spezialsoftware, z.B. einen Schachcomputer.
Christian J. schrieb: ... > 2. Eprom Emulator? Braucht man nicht unbedingt. > 3. Eprom Brenner und Eproms => ibäh, schon bestellt Fehlkauf. Von alten PC-Mainboards kann man parallel ansteuerbare Flash- ROMs abziehen. Braucht man nur noch einen Brenner dafür. > 5. C Cross Compiler für Linux oder Windows? Ausgabe: Hex File für > Brenner > 6. Assembler? Och nö..... das dauert ja ewig da was Gescheites zu > programmieren. Ohne Assembler geht zu Anfang nichts. > Alternativ würde mir folgende Lösung gefallen: Was heißt hier alternativ? Wenn du nicht das Äquivalent einer Grafik- karte zusammenlöten willst, ist eine serielle Terminalschnittstelle zum PC das Mittel der Wahl. > Ein RS232 Terminalanschluss am Z80 System, Uart-USB Konverter, im EPROM > ein komfortabler Monitor und ich bediene das ganze aus der Konsole von > Linux heraus, so wie ich mich auf einm Raspi auch einlogge. Programme > sollten hochgeladen werden können und im RAM ausgeführt werden. Jepp. Genau so. Nur daß du dir den Monitor zumindest in Teilen selber schreiben mußt. Aus der alten Zeit gibt es zwar noch Quellcode für Monitorprogramme (u.a. von den Herren Hübler und Kramer oder vom LC80, Z1013 usw.). Aber die paßt sicher nicht 100%ig und man muß zumindest Teile anpassen. Das Minimum was der Monitor mitbringen muß, sind Funktionen zum Laden und Starten von Programmen im RAM. Wenn man das ganze mit Flash baut, könnte man sogar ins Flash laden. Mittelfristig würde man sicher ein BIOS implementieren wollen und darauf CP/M aufsetzen. Spätestens dann hat man auch einen Compiler für z.B. Turbo Pascal oder notfalls auch C. XL
Ich hatte auch mal so etwas überlegt. Aber dann, was macht man damit? CP/M laufen lassen. Und dann die gleichen SW-Probleme wie damals? Langsam und umständlich? Wo jede SW-Emulation das 100mal schneller erledigt. Praktischen Nutzen gibt es nicht. Nochmal Wordstar? Nur für 10 Minuten ein warmes Gefühl? Denn Texte schreiben möchte ich damit nicht mehr. Oder das Konzept mit dem AVR als Slave Prozessor. Der könnte doch auch schon den Z80 mit emulieren. Vielleicht nicht ganz in Echtzeit, aber die Z80 ist überflüssig. Und für richtige Projekte ist der 64K Arbeitsspeicher zu klein. War er damals schon und das gilt heute immer noch. Ich habe mich dann dafür entschieden, doch lieber was neues zu machen, wo man was lernt oder den Horizont erweitert. FPGA, Muticore Arm, ungewöhnliche Architekturen wie XMOS Prozessoren ... das macht mehr Spass.
Ein 68K System ist recht einfach, EPROM/SRAM/Peripherie und eine einfache Adressauswertung(CS auf die Adressleitungen legen) und schon ist das System fertig. Oder das hier mal anschauen http://www.s100computers.com/My%20System%20Pages/68000%20Board/68K%20CPU%20Board.htm http://wandel.ca/homepage/mc68008/
Axel Schwenke schrieb: >> 5. C Cross Compiler für Linux oder Windows? Ausgabe: Hex File für >> Brenner >> 6. Assembler? Och nö..... das dauert ja ewig da was Gescheites zu >> programmieren. > > Ohne Assembler geht zu Anfang nichts. ACK. Assembler, Linker, Locater und C-Compiler gibt es als Freeware in guter Qualität. > Was heißt hier alternativ? Wenn du nicht das Äquivalent einer Grafik- > karte zusammenlöten willst, ist eine serielle Terminalschnittstelle zum > PC das Mittel der Wahl. Für den Anfang die imho beste Wahl. >> im EPROM >> ein komfortabler Monitor und ich bediene das ganze aus der Konsole von >> Linux heraus, so wie ich mich auf einm Raspi auch einlogge. Programme >> sollten hochgeladen werden können und im RAM ausgeführt werden. Sooo viel muss der Monitor nicht können. Im Prinzip reicht es hin, wenn er HEX Files laden kann. Für Debugging sind Breakpoints und Einzelschritt noch sinnvoll. > Jepp. Genau so. Nur daß du dir den Monitor zumindest in Teilen selber > schreiben mußt. Maximal müssen die Basisadressen des UART und - falls vorhanden - die Initialisierung des Baudraten CTC und einer PIO angepasst werden. Das sind aber schlichte Tabellen. > Mittelfristig würde man sicher ein > BIOS implementieren wollen und darauf CP/M aufsetzen. Eher kurzfristig, würde ich als erstes machen. Das Problem ist nur, dass dann auch eine Floppy (notfalls als Emulator) da sein muss. Als Anregung gibt es hier im Forum einen CP/M Computer auf AVR Basis.
Wollte ich auch mal machen, allerdings zur Zeit mache ich damit nichts mehr. Diverse RAM und Flash chips hier, 68000er CPUs, GAL Brenner, jede Menge Leiterplatten. 8031 habe ich auch hier, einfacher da nur 8bit. Es stellt sich aber die Sinnfrage, PIC32 hat den Speicher integriert und ist viel schneller.
Angehängte Dateien:
-
IMG_1395.jpg
630 KB
Guten Morgen! Danke für die vielen Antworten !!!! Ich kann jetzt nicht auf jede eingehen aber sehe, dass ich nicht der einzige bin, der sowas mal angedacht hat. Die Hardware wäre wohl eher weniger ein Problem aber die Software müsste was Fertiges sein. Wenn man sich das alles recht überlegt wäre vielleicht die Anschaffung eines Apple 2, den es ab 500 Euro gibt mit 2 Floppys wohl besser oder vielleicht eines Atari. Dann kann ich wieder "Quit Update Compile" tippen (diese 3 Wörter haben sich vor 25 Jahren wohl in mein Hirn eingebrannt") und zuschauen und Kaffee trinken während der Apple die Floppys anwirft und das Pascal Programm kompiliert. Das UCSD Pascal gibt es auf Disk Images wie ich sah, muss man nur "irgendwie" auf die uralten Floppy kriegen. Das Ding auf dem Bild hahe ich noch, müsste nur mal die Elkos tauschen nach über 20 Jahren. Hier steht auch das ganze Leid von jemandem, der es an der VHS als "Retro Kurse" anbietet. http://www.simulationsraum.de/blog/tag/z80/ Gibt sogar ein eigenes Magazin "Retro Computer": https://www.csw-verlag.com/RETRO-Magazin/ Worüber ich noch nachdenken muss ist "Willst Du das wirklich antun?" .... Gruss Christian Wenn ich sowas hier sehe schüttelt es mich schon..... 68000er Asm.... als ich noch so programmierte drehte sich mir der Schädel wenn ich abends von der Arbeit nach Hause kam :-( validstr dc.b 'Invalid, must be one of the following:',13,10,0 baudtbl2 dc.b '75',0,'110',0,'134.5',0,'150',0,'300',0,'600',0 dc.b '1200',0,'2000',0,'2400',0,'4800',0 dc.b '1800',0,'9600',0,'19200',0,0 keepmsg dc.b 'Data table invalid - reset.',13,10,0 section one,code dumptokens move.b (a2)+,d0 beq.s tokend dcont bsr putchar bra dumptokens tokend moveq #' ',d0 bsr putchar move.b (a2)+,d0 bne.s dcont bra crlf getab bsr skipspc beq synerr addq.l #1,a3 bsr toupper cmp.b #'A',d0 beq.s gota cmp.b #'B',d0 bne synerr lea chanb,a5 lea p_mr1b,a6 rts gota lea chana,a5 lea p_mr1a,a6 rts
Hallo, Anfang der 80'er Jahre gab es den NDR Klein Computer zum selbst bauen. Das war ein modulares System von Rolf Dieter Klein und wurde mit dem NDR zusammen gemacht. Im Franzis Verlag gab es dazu Bücher und in der MC Artikel. Platinen und Halbleiter konnte man im Elektronikladen (Elmicro) bestellen. Es war damals nicht so einfach einen Mikrocontroller zu organisieren. Der Computer war modular, eine CPU Platine, eine für I/O, eine für serielle Schnittstelle, eine für ein Grafikterminal, eine für ein Spannungs-Frequenzwandler usw. Der Prozessor war ein 4MHz Z80A. Später gab es dann auch die 8 Bit Variante vom 68000, den 68008 und irgend wann in der MC auch den europaweit ersten Selbstbau Computer mit 32 Bit, ein 68020, glaub ich war das damals. Das war ein so cooles Projekt, ich konnte damals beim gut ein Jahrzehnt langen Bauen meines Computers sehr viel lernen. Das Buch und verschiedenen Sonderhefte, selbst den 68008 und den Grafikprozessor von Thomson hab ich noch heute. Lust hatte ich auch immer mal so ein System mit einem richtigen Bussystem wieder aufzubauen. Aber wenn man die Leistung der modernen Controller sieht mit ISP Schnittstelle, dann ist die Motivation doch nicht mehr so groß. Die Software halte ich gar nicht so für das Problem. Fehlende Programmierschnittstelen früher waren viel schwerwiegender. Es gab damals nur UV Licht löschbare EPROMS. Später gab es von Waferscale (übernommen von ST) Flash Speicher mit JTAG. Wenn es die Bausteine heute noch gibt, würde ich bei dem Z80 System darauf zurück greifen. Die Bausteine hatten auch ein wenig programmierbare Logik. Viel Erfolg bei Deinem Vorhaben. Gruß thomas Ergänzung: In der c't Hacks 4/2013 war ein Projekt: Z80 CP/M Rivival Buch: Rolf Dieter Klein Franzis Verlag 1983 Mikrocomputer selbstgebaut und programmiert ISBN: 37723-7162-0 gibt's vielleicht bei Ebay
PittyJ schrieb: > Oder das Konzept mit dem AVR als Slave Prozessor. Der könnte doch auch > schon den Z80 mit emulieren. Vielleicht nicht ganz in Echtzeit, aber die > Z80 ist überflüssig. Da gibt es hier im Forum auch ein Projekt zu. Wenn der AVR einen Z80 emuliert und der DRAM sauber angeschlossen ist, kommt man auf knapp über 2 MHz, wenn ich mich recht entsinne. > Und für richtige Projekte ist der 64K Arbeitsspeicher zu klein. War er > damals schon und das gilt heute immer noch. Dafür gibt es ja Banking. Dummerweise unterstützt das kaum ein C-Compiler vernünftig. > FPGA, Muticore Arm, ungewöhnliche Architekturen wie XMOS Prozessoren ... > das macht mehr Spass. Hängt davon ab, was für dich Spaß ist. ;-) Wenn man die 80er nicht live miterlebt hat, ist auch ein Z80 eine neue Welt.
Hallo, ich lese seit Stunden Seiten wie die mit dem N80VEM oder dem NDR Computer durch und komme langsam zu der Erkenntnis, dass der Raspberry Pi die beste Wahl ist, wenn man auf Konsolen Look steht. Nur versteht man da nicht mal ansatweise mehr wie der innendrin funktioniert, weil die CPU viel zu komplex ist. An mi ist schon die virtuelle Adressraum vorbeigegangen, was eine MMU ist. Denn wer nur mit Controllern arbeitet braucht das ja nicht. 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.
Christian J. schrieb: > 5. C Cross Compiler für Linux oder Windows? Ausgabe: Hex File für > Brenner > 6. Assembler? Och nö..... das dauert ja ewig da was Gescheites zu > programmieren. Was soll dann der Quatsch mit Z80/68K? Wenn du sowieso nur eine (idealerweise alles egalisierende) Hochsprache drauf loslassen willst, spielt die konkrete Hardware doch überhaupt keine Rolle. Du kannst denselben Qualm dann auch für ein modernes µC-System übersetzen und die CPU-Opas dahin geben, wo sie wirklich nochmal etwas nützen (wenn auch nicht dir): zum Wertstoff-Hof. Retro ohne Asm ist wie Monte Carlo ohne Roulette. Langweilige Zeitverschwendung. Außer einer Auffrischung der Fertigkeiten bezüglich des Lötens auf Lochraster ist daraus keinerlei Gewinn zu erzielen, nichtmal ideeller.
Zumindest in Sacen Grafikarte habe ich hier schon was gefunden, was evtl mit einem PIC oder AVR angeschlossen werden könnte, damit man was sieht. http://www.watterott.com/de/Micro-VGA-Mikrocontroller-VGA-Grafikkarte
Sodele.... hier ist mein Wunschsystem :-) Wird direkt nachgebaut. Mit Monitor, Forth Interpreter, Laderoutine für Hex File usw. http://www.vaxman.de/projects/Z80_mini/index.html
Halloooooooooo............. ! Kann mal einer von den Z80 Cracks bitte zuhören bzw -lesen? Habe mir die ganze Hardware heute bestellt: - neue Zilog Z80 CPU's - Z80 PIO - 16C550 Uart - RAM - EPROM - Brenner und bin dabei den Schaltplan in Eagle ein zu hacken. Mit der 6510 kenne ich mich aus, damit habe ich viel gemacht damals, auch mit dem 8031 und seinem Multiplex Bus aber Z80 eben nüscht... Fragen: 1) I/O Der Z80 hat wie ich sehe I/O Funktionen IN und Out und eine IOREQ Leitung. Bindet man die Peripherie nun als I/O oder Memory Mapped ein? So wie ich das sehe kann ich die Register des 16C550 doch locker mappen über A15,14,13 (nutze eh nur A0 - A12), so dass ich alle Befehle drauf anwenden kann, statt nur IN und OUT, oder? Also .......A15 A14 A13 A12 ROM 0 0 0 1 RAM 0 0 1 0 UART 0 1 0 0 PIO 1 0 0 0 oder über Glue Logic eben decodieren, wobei ich das vermeiden will, damit kein TTL Grab entsteht. 2) Bus Der Z80 hat Bus-Steuerleitungen, Wait, HALT etc. Werden die bei einem Minimalsystem benötigt oder brauche ich den Bus nur, wenn ich den als extern ausführe, so dass ich Erweiterungskarten einstecken kann, die sich den Bus holen können um auf die RAM, ROM etc zuzugreifen? Gruss, Christian
Christian J. schrieb: > Der Z80 hat wie ich sehe I/O Funktionen IN und Out und eine IOREQ > Leitung. Bindet man die Peripherie nun als I/O oder Memory Mapped ein? Möglichst als I/O, ergibt sauberere Programme, und die PIO braucht das für die Interrupt-Bearbeitung. Christian J. schrieb: > Der Z80 hat Bus-Steuerleitungen, Wait, HALT etc. Werden die bei einem > Minimalsystem benötigt Hängt von deinem Minimalsystem ab. Das Timing des Z80 ist sehr eng. Gerade mit alten (langsamen) Speicherchips braucht man WAIT. Aber beim 16C550 nicht.
Ok! Also PIO, 16C550 und evtl. 8153 Timer als I/O mappen. Decodiert werden müssen die aber dann auch. ROM / RAM simpel über A15 decodieren? Mit PALoder GAL und so nem Driss fange ich nicht mehr an, keinen Brenner, keine Ahnung, keine Software :-)
Christian J. schrieb: > Der Z80 hat wie ich sehe I/O Funktionen IN und Out und eine IOREQ > Leitung. Bindet man die Peripherie nun als I/O oder Memory Mapped ein? Wie du gern möchtest. Allerdings ist der (Speicher) Adreßraum mit 64K nach heutigen Maßstäben ohnehin eher klein. Warum sollte man davon noch was für IO abzwacken wollen, wo man den separaten IO Adreßraum doch geschenkt kriegt? Auch von der Decodierungslogik her ist einfacher, separate Adreßräume zu verwenden. Nicht zu vergessen verlangen diverse Standardumgebungen (wie CP/M und Vettern) einen möglichst großen, von 0 an durchgehenden RAM. Ich würde so ein System nicht anders aufsetzen, als mit einem mindestens 64K großen RAM, das hier und da von (EP)ROM überdeckt wird. Eine neckische Idee ist z.B. das ROM nur nach RESET an Adresse 0x0000 einzubinden und dann als allererste Aktion ins RAM zu kopieren. Danach wird das ROM abgeschaltet und das System läuft komplett aus dem RAM. > Der Z80 hat Bus-Steuerleitungen, Wait, HALT etc. Werden die bei einem > Minimalsystem benötigt oder brauche ich den Bus nur, wenn ich den als > extern ausführe, so dass ich Erweiterungskarten einstecken kann, die > sich den Bus holen können um auf die RAM, ROM etc zuzugreifen? WAIT wirst du mit aktuellen Bausteinen eher nicht brauchen. Allerdings kann man damit auch nette Spielchen machen, wie z.B. Hardware- Einzelschrittbetrieb. Woran du recht zeitig denken solltest, ist welchen Interruptmode du verwenden willst. IM2 ist am leistungsfähigsten, muß aber bei der Adreßdecodierung berücksichtigt werden, damit sowohl das Lesen des Interruptvektors als auch das Snoopen des RETI Opcodes funktionieren. Es gibt in diesem Bereich auch ein paar known bugs - lies also mal ein paar Vintage Seiten genauer. XL
Ich kann das gut verstehen, wenn man sich wieder mit den "alten" CPUs und Systemen beschäftigt. Es geht doch eigentlich nur der Nostalgie willen, solche "Systeme" wieder zu bauen oder wieder ans Laufen zu bringen. Es geht doch garnicht darum, dass es heute besser MC/CPUs gibt. Ich habe heute noch ein Tektronix 4014 / Siemens 97801 kompatibles Terminal in Betrieb, das ich 1985 auf Basis der Intel 8031 und Zilog Z80 CPU entwickelt habe. Also 2 CPUs. Der Z80 kümmert sich um die grafische Darstellung. Die 8031 MCU macht nur die Kommunikation V.24/RS422 und bedient die serielle Tastatur. Das Terminal, das Gerät selbst ist ein Siemens 97801 mit meinem Motherboard, ist super für Debuggingzwecke via serieller Schnittstelle. Printerport und Mausanschluss inklusive. Ich verwende es heute noch. Besser als jede PC-Emulation. Daneben habe ich noch einen Unix System in Betrieb. Macht echte Laune, mit dem Maschinchen zu arbeiten. Hat eine NSC32016 CPU, 10 MHz Takt, 512 MB, 40 MB HD, bootet schneller als jeder aktuelle PC und hat schon Jahrzehnte auf dem Buckel. Baujahr 1985! Ausser der HD, original Hersteller war RODIME, jetzt Seagate , bis heute keinen Ausfall. Das soll mal ein aktuelles System nach machen! Ich habe oft den Eindruck, dass die "alten" Systeme besser gebaut waren. Das ist mein Sicht zu diesem Thema.
Ja, ja, alter Mann (55) erzählt vom Krieg! Es hat und heute auch noch, einfach Spass gemacht! Das vermisse ich oft, wenn ich mir die Beiträge so anschaue. Vor allem die nutzlosen Antworten. Habe eigentlich überhaupt das Denken gelernt? Es gab noch kein Internet, wo man Datasheets massig findet und viele nicht in der Lage sind diese wirklich zu verstehen. Da musste man die vorhandenen Infos wirklich verstehen lernen. Die Databooks musst man teilweise noch bezahlen!!!! Und Du musstest mit dem/den Lieferanten einen guten Draht aufbauen, sonst hattest du verloren. Und nicht wie hier so oft: Hau drauf, ohne Sinn und Verstand. Das wollte ich noch anmerken.
Hallo, > 1) I/O > Der Z80 hat wie ich sehe I/O Funktionen IN und Out und eine IOREQ > Leitung. Bindet man die Peripherie nun als I/O oder Memory Mapped ein? Das bleibt voll und ganz dir überlassen. Für I/O-Zugriffe legt der Z80 immer einen Wartezyklus ein, aber dafür bleibt dein RAM-Adressraum sauber. Im Gegensatz zum 8085 kannst du den I/O-Adressraum ebenfalls mit 16 Bit adressieren, aber mit 8 Bit ist es einfacher. Wenn ich das richtig sehe, haben EPROMs ein high-aktives enable, und SRAMs ein low-aktives. In dem Moment könntest du den Chip direkt mit A15 auswählen (und nur bei /MREQ aktivieren) und bekommst dann je 32 KB ROM (low) und RAM (high). Damit geht aber kein CP/M. > So wie ich das sehe kann ich die Register des 16C550 doch locker mappen > über A15,14,13 (nutze eh nur A0 - A12), so dass ich alle Befehle drauf > anwenden kann, statt nur IN und OUT, oder? Sinnvoll für Hardwarezugriffe sind nur Load- und Blockbefehle. Beide gibt es auch in der I/O-Variante. Eine vernünftige Ausdekodierung von I/O für bis zu 8 Geräte (je 32 Ports) kannst du z.B. mit einem einzigen 74xx138 machen: /M1 an EN1, /IORQ an /EN2, fertig. > 2) Bus > > Der Z80 hat Bus-Steuerleitungen, Wait, HALT etc. Werden die bei einem > Minimalsystem benötigt oder brauche ich den Bus nur, wenn ich den als > extern ausführe, so dass ich Erweiterungskarten einstecken kann, die > sich den Bus holen können um auf die RAM, ROM etc zuzugreifen? An sich sind die uninteressant. An /HALT kannst du eine LED hängen, die dir anzeigt, ob dein System gerade im Leerlauf ist (auf Interrupts wartet), das ist auch zum Testen hilfreich. @DingsDa: Magst du das Tektronix-kompatible Terminal etwas näher ausführen? Mir gefällt die Idee nämlich, relativ einfach Grafiken darstellen zu können, aber außer xterm kann das kein Terminalemulator. Wie machst du die Ausgabe? Gruß, Svenska
S. R. schrieb: > EPROMs ein high-aktives enable Datenblatt mal überflogen? /CE und /OE sind auch beim Eprom aktiv-LO. SRAMs gab es mal mit zwei Enable Eingängen, einer Hi und einer Lo aktiv. Für den TO: ich würde die Z80-SIO nehmen und einen externen Baudraten Generator. Wenn du mit Interrupts arbeiten willst (und das willst du irgendwann), ist das mit den Z80 Bausteinen einfacher. Die liefern dann den Vektor und du brauchst keine Klimmzüge im Programm zu machen.
Hi Christian J. (hobel) , du hast doch hier Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" selbst das Foto des "Micro-Professor" uPF-1 MPF-1B eingestellt! Warum verwendest du dieses System nicht für deine Experimente? Ist mit Z-80 und hat ausführliches Handbuch, mit Sourcelisting, mit vielen Beispielen, auch Vektor-INT2 mode des Z80. Handbuch inzwischen auch online; Google findet es. Gruss
Z180-System mit integrierter PIO, CTC und SIO und 512k RAM, ein AVR ersetzt den EPROM. Beitrag "Z180-Stamp Modul" oder ganz klassisch mit Z80 http://www.projekte.daleske.de/cpm/06_z80hwe/cpm_z80hwe.htm
Hallo, danke für die Tipps! Habe mich heute nur den ganzen Tag mit "Daytrading" an der Börse befasst und da recht gute Gewinne gemacht, die ich jetzt wieder für Hardware verbraten werde :-) Also, das System soll bestehen aus .... nur die Hardware, Software weiss ich noch nicht so genau: Z80 Z80 PIO Z80 CTC bzw 8253 Timer Baustein 16C550 Serial Port 32 kb RAM 32 KB ROM evtl. eine Arduino 7-Segment Anzeige mit Atmel als Treiber, mal gucken. Video Interface .... gibt es auch für die UART, der C550 hat zwei davon: http://www.watterott.com/en/Micro-VGA-Cost-effective-Microcontroller-VGA-Interface So für einen 7z Bildschirm, man will ja was sehen. Tastatur macht keinen Sinn, dafür braucht man ja ein echte BIOS, Speichereinheiten etc. Und Programme werde ich auf dem Z80 nicht einhacken. Interrupts.... wofür? Es gibt 3 Stück, Mode 2 wird wohl am meisten benutzt. Auch die Timer 0.3. brauchen einen, den NMI vielleicht? Die 16C550 muss Zeichen melden, also gehen deren IRQ Ausgänge an die CPU. Glue Logic muss ich noch den Kopf rauchen lassen, der 74HC138 scheint mir geeignet wenigstens 3 Peripheriebausteine anzuschliessen. Für RAM/ROM braucht man nur die A15 über 2 Inverter nacheiander jeweils intervertiert an EPROM und RAM zu gehen, der eine ist negiert, der andere nicht. Software: Bisher noch keine Ahnung! Ich werde auf keinen Fall Asm Programme schreiben, brennen, löschen, korrigiere und alles von vorne wie früher. Das muss auf dem PC besser gehen mit einem Cross Assembler, wenn es geht mit Simulation des Programms aber da weiss ich nicht was es da gibt. Bin sehr verwöhnt mit grafischer Oberfläche von MPLAB und ARM IDE's. Der Z80 Asm ist "verständlich" .. habe das Buch "Z80" gekauft und mein Unterbwusst sein sagt mit jeder Seite: "Das hast du vor 25 Jahren alles mal gemacht, es ist nicht neu .... nur "ungewohnt". Irgendwas vergessen?
Angehängte Dateien:
-
schematic__1_.jpg
280 KB
Weiter im Text: Was macht man überhaupt mit diesem System? Assembler erlaubt keine komplexen Anwendungen, zumindest nicht wenn man nicht endlos Zeit hat und vor allem KEIN BIOS dahinter wie das DOS BIOS füher, wo man zig INTs nutzen konnte um Dateien zu schreiben, Ausgaben zu machen und und und. Da freut man sich wenn Lämpchen blinken, etwas ausgegeben wird auf der Uart, vielleicht ein 7-Segment Display ein paar Zahlen anzeigt. Und vielleicht fühlt man sich "nostalgisch", wenn man den schwarzen Chip anschaut und nichts sieht aber weiss, dass er innendrin grad "rechnet". Mit dem Internet wird er sich ebenso wenig verbinden können, wie ein USB Gerät anzusteuern oder eine 3,5z Floppy, was ja denkbar wäre als Datenspeicher. Vermutlich wird also die Verwendung eine Art "physical computing" sein, Ports einlesen, ausgeben, irgend einen Sensor dran und 2-3 Relais, die irgendwas ansteuern. Oder sehe ich das falsch?
Du willst also ein Z80 System bauen. Finde ich sehr interessant. Beschäftige mich auch damit soweit es die Zeit erlaubt. Und nun führst du dein eigenes Projekt mit deinen letzten zwei posts ad absurdum.... Gespaltene Persönlichkeit?
Christian J. schrieb: > Was macht man überhaupt mit diesem System? Christian J. schrieb: > Oder sehe ich das falsch? Du erkennst langsam, waorum solche Schaltung Unsinn sind. Wenn du CP/M und GEM laufen lassen könntest, oder ein Arcade-Spiel aus MAME auf die Hardware ziehen könntest. Also erst die Anwendung suchen, die mit einen Uralt-OProzessor besser geht (weniger Bauaufwand weil Pläne und Software fertig) als mit einem Neuen, und dann bauen.
Das genau ist das Problem - erst die Software haucht dem Kerlchen Leben ein. Du hast nicht genug Zeit in deinem Leben, das alles selbst zu machen. 16C550 - du solltest bei der originalen Z80-SIO bleiben. Nur damit funktioniert das eigentlich geniale Interupt-System (Peripherie liefert den Opcode, IM2 (?) ) in seiner ganzen Schönheit.
Christian J. schrieb: > Hallo, > > danke für die Tipps! Habe mich heute nur den ganzen Tag mit > "Daytrading" an der Börse befasst und da recht gute Gewinne gemacht, die > ich jetzt wieder für Hardware verbraten werde :-) > > Also, das System soll bestehen aus .... nur die Hardware, Software weiss > ich noch nicht so genau: > > Z80 > Z80 PIO > Z80 CTC bzw 8253 Timer Baustein > 16C550 Serial Port > 32 kb RAM > 32 KB ROM Wenn ich das machen würde: EZ80F91: hat bereits 256k Flash, seriell, SPI, I2C, RTC und Glue Logic drin; http://www.digikey.de/product-detail/de/EZ80F91AZA50SG/269-4564-ND/1236489 Beschaltung gemäß Datenblatt dazu ein 128k SRAM wie dieses hier zB: http://www.digikey.de/product-detail/de/IS61C1024AL-12JLI-TR/706-1303-1-ND/4733133 oder mehr, wenn Du magst. Tu Dir keinen Zwang an. Denke daran: Du kannst Bankswitching machen, musst es aber nicht. Der EZ80 kann 16MB Adressraum linear (!) adressieren. Restliche Peripherie je nach Wunsch hinzufügen - genügend IO-Pins hat das Teil. Assembler/Compiler/RTOS gibts bei Zilog. Wenn Du magst, darfst Du auch noch einen DP83848C anklemmen und das 10/100 Ethernet in Betrieb nehmen. http://www.digikey.de/product-detail/de/DP83848CVV%2FNOPB/DP83848CVV%2FNOPB-ND/947542 Ansonsten gibts das alles fertig, wenn Dir SMD unheimlich ist (alles eine Frage der Übung und der richtigen Technik): http://www.digikey.de/product-detail/de/EZ80F910200KITG/269-4560-ND/1236485 Da ist dann auch ein Debuggerkabel dabei. fchk
Harald schrieb: > Du willst also ein Z80 System bauen. Finde ich sehr interessant. > Beschäftige mich auch damit soweit es die Zeit erlaubt. > > Und nun führst du dein eigenes Projekt mit deinen letzten zwei posts ad > absurdum.... > > Gespaltene Persönlichkeit? Nein, das nennt man den Prozess der Entscheidungsfindung. Pro und Contra .... solange bis man sich für eine Richtung entschieden hat oder etwas verwirft. Da hier nur der Weg zählt und es kein Ziel gibt entspricht es nicht der üblichen Vorgehensweise, die ich als Ingenieur so kenne. Da würde ich nämlich estmal eine Spec schreiben. @Frank: Mit den smd Chips und moderner CPU fehlt der "Geist der Nostalgie"... es sollen ja gerade die Uralt Steine sein die verbaut werden. Sonst geht auch ein Raspberry Pi, sicherlich komfortabler. DIe CPM/M Version ist deutlich aufwendiger und ich würde mal sagen, da geht ein Jahr ins Land bevor das alles läuft.... http://searle.hostei.com/grant/cpm/index.html Der hie baut sogar "Pong" selbst nahc mit TTL.... denke mal er hat keine Familie und sehr viel Zeit :-), siehe Bild. http://searle.hostei.com/grant/pong/index.html
H.Joachim Seifert schrieb: > 16C550 - du solltest bei der originalen Z80-SIO bleiben. Nur damit > funktioniert das eigentlich geniale Interupt-System (Peripherie liefert > den Opcode, IM2 (?) ) in seiner ganzen Schönheit. Jein. Er könnte die PIO, die er vorgesehen hat, als IM2 Quelle nutzen, in dem IRQ des 16C550 in den PIO geht. Aber bei 2 Quellen braucht er sowieso keinen IM2.
MaWin schrieb: > H.Joachim Seifert schrieb: >> 16C550 - du solltest bei der originalen Z80-SIO bleiben. Nur damit >> funktioniert das eigentlich geniale Interupt-System (Peripherie liefert >> den Opcode, IM2 (?) ) in seiner ganzen Schönheit. > > Jein. > > Er könnte die PIO, die er vorgesehen hat, als IM2 Quelle nutzen, in dem > IRQ des 16C550 in den PIO geht. > > Aber bei 2 Quellen braucht er sowieso keinen IM2. Hi, ich denke ich habe mich entschieden. der Junge hat alles wunderbar beschrieben, an jedes Detail gedacht und vor allem hat er ein komplettes BIOS geschrieben mit Basic Interpreter und einem Terminal Adapter für den PC. Das denke ich spart deutlich Arbit und Basic ist ja ok. http://searle.hostei.com/grant/z80/SimpleZ80.html Anbei mal ein echter "Bill Gates" von 1978 .... ein Basic Interpreter.
Angehängte Dateien:
So, falls es jemanden interessiert,der ähnliches im Schilde führt, so denke ich, dass das der schnellste Weg zu einem "Retro Computer" ist. Basic! Und da es Peek und Poke gibt sind auch Peripherie Geräte wie Timer etc programmierbar und auslesbar. Evtl. muss ich da aber den Asm verändern, sofern die auf das Memory zugreifen und nicht auf die I/O. Anbei ein Bild des Erstellers diesen klasse Z80 System mit echtem BIOS dahinter.
Christian J. schrieb: > Mit den smd Chips und moderner CPU fehlt der "Geist der Nostalgie"... es > sollen ja gerade die Uralt Steine sein die verbaut werden. Sonst geht > auch ein Raspberry Pi, sicherlich komfortabler. Nun, man kann sich das Leben auch schwer machen. > DIe CPM/M Version ist deutlich aufwendiger und ich würde mal sagen, da > geht ein Jahr ins Land bevor das alles läuft.... Das haben schon andere vor Dir gemacht: http://www.shaels.net/index.php/mic80/mic80-general/38-mico-overview http://z80cpu.eu/mirrors/www.vegeneering.com/eZ80_CPM/index.html http://www.hsl.wz.cz/cpmez80.htm
Dann bau doch einen ZX80 oder ZX81 nach. Da gibt es sehr schöne Implementierungen mit Standardbauteilen. Suchbegriff "ZX97 wilf righter", "ZX81NU", "zx80 grant searle".
Christian J. schrieb: > So, > > falls es jemanden interessiert,der ähnliches im Schilde führt, so denke > ich, dass das der schnellste Weg zu einem "Retro Computer" ist. Basic! Ich denke, auf der Schiene fahren schon bessere Züge, die zeitgemäß und schneller sind. Beitrag "maximite TFT mmbasic Computer" Beitrag "PIC 32 schneller Basic Interpreter"
Hallo, ich habe mir mal den SDCC Compiler runtergelden und etwas quer durchs Manual gelesen. Das scheitn mir doch den ungeliebten Assembler zu ersparen (Nein..... ich habe keinen Bock da drauf! Seit 1995 nicht mehr...). Zumindest für eine Applikation und um die geht es ja was schickes für die Kiste zu schreiben. Einen Monitor, der sich Intel .hex Files über die Uart reinzieht und diese im Ram decodiert und ausführt habe ich schon. Ram ist bei mir Batterie gepuffert also bleibt es auch drin. Kennt sich jemand mit diesem SDCC Compiler aus? Alos erstes tauchen natürlich Fragen auf, wie - wie teile ich ihm die Memory Map meines Rechners mit? - wie bringe ich ihm bei, dass auf $80 die Timer I/O liegt und auf $A0 die Serielle Schnittstelle? - kann er Code erzeugen für I/O gemappte Devices? Oder nur für welche die memory mapped sind? - wie leite ich stdout um auf meine Z80 SIO Uart usw.? Beispiele gibt es keine im Netz, habe alles durchsucht.
Christian J. schrieb: > Beispiele gibt es keine im Netz, habe alles durchsucht. Das glaube ich dir nicht. > Kennt sich jemand mit diesem SDCC Compiler aus? Nur am Rande, habe ihn (bisher) nicht für größere Projekte benutzt. Es gibt wohl ein paar Bugs bei speziellen Sachen (z.B. __critical), aber der Codegenerator an sich soll gut sein. Auf der Webseite werben sie zumindest damit, dass sie fast so gut sind wie IAR (und damit besser als alle anderen). > - wie teile ich ihm die Memory Map meines Rechners mit? Sollte mit --code-loc und --data-loc gehen, notfalls musst du dir eine eigene Startup-Datei (crt0.rel) bauen. > - wie bringe ich ihm bei, dass auf $80 die Timer I/O liegt und > auf $A0 die Serielle Schnittstelle? Der Compiler kennt weder serielle Schnittstellen noch Timer, also wirst du dir dafür deine eigenen Treiber schreiben müssen. ;-) > - kann er Code erzeugen für I/O gemappte Devices? Ja. Du kannst Variablen mit ein paar Spezialflags deklarieren:
1 | __sfr __at 0x12 reg1; |
2 | __sfr __at __banked 0x1234 reg2; |
dann wird für Zugriffe darauf ein in- oder out-Befehl erzeugt. Letzteres erzeugt Code, der I/O mit allen 16 Adressbit macht (Eigenheit vom Z80). > Oder nur für welche die memory mapped sind? Wie dir andere bereits schrieben: Löse dich von MMIO. Das ist auf einem Z80 nicht zielführend. > - wie leite ich stdout um auf meine Z80 SIO Uart Naja, die mitgelieferten Funktionen rufen nicht mitgelieferte Funktionen auf... Ein Beispielcode für meine Hardware:
1 | #include <stdio.h> |
2 | |
3 | __sfr __at 0x10 uart_data; /* Datenregister */ |
4 | __sfr __at 0x11 uart_rxfill; /* Anzahl Bytes im Rx-Puffer */ |
5 | |
6 | void putchar(char c) { |
7 | uart_data = c; |
8 | }
|
9 | |
10 | void main(void) |
11 | {
|
12 | char rx; |
13 | char hello[] = "Hallo, Welt!\n"; |
14 | |
15 | printf("%s", hello); |
16 | while(uart_rxfill) { |
17 | rx = uart_data; |
18 | printf("%c", rx); |
19 | }
|
20 | }
|
Hallo S.R, danke für die Ausführungen, wird Zeit den Thread mal auszudrucken als pdf und ins Info Verzeichnis zu legen. Ich habe mir heute mal einen sehr aufwendigen Krypto DOS Virus angeschaut, den ich aus Interesse mal 1995 für IBM 486 geschrieben habe mit ca 23 J. Wurde sogar veröffentlicht als Demo Code. 30 Seiten Asm ausgedruckt. Frage mich wieso es mir heute so schwer fällt derart guten Asm wie damals zu schreiben? Alter? Das was Du da schreibst gefällt mir, vielleicht hast Du ja ein paar Sourcen deines projektes mal für mich, so dass ich Beispiele habe? Nicht für "C" sondern die Spezialfunktionen, wie SFR Register belegen und ansprechen usw. Einiges werde ich sicher inline asm codieren müssen aber das meiste in C. Da ich recht viel Sourcen gefunden habe, die man fast schon mit Ehrfurcht anschaut (1976er Orginal Sourcen von CP/M und Microsoft für Z80) würde ich gern einige tolle Sachen wie FORTH Interpreter Basic Interpreter übernehmen in den Monitor.
Christian J. schrieb: > Das was Du da schreibst gefällt mir, vielleicht hast Du ja ein paar > Sourcen deines projektes mal für mich, so dass ich Beispiele habe? Nicht > für "C" sondern die Spezialfunktionen, wie SFR Register belegen und > ansprechen usw. Das kann ich nicht, weil ich das bisher selbst nicht gemacht habe. Fast die gesamte Peripherie ist in einem AVR implementiert und daher aus Z80-Sicht extrem einfach zu bedienen. Im Augenblick läuft auch nur ein ziemlich minimales CP/M, bis ich mal wieder die Muße finde, das Speichersystem fertigzustellen. Zu dem Projekt findest du zwei Threads hier: Hardware: Beitrag "eigenes Z80 Mainboard - geht das so?" CP/M: Beitrag "CPM.SYS und wenig RAM" Gruß
S. R. (svenska) schrieb: > SFR Register Der Z80 hat ein einziges "SFR", das Register, das das Hi-Byte der Interrupt Vektor Tabelle enthält. SDCC kenne ich nicht, ich arbeite mit einer Variante von "QC". Der iwrd aber nicht grundsätzlich anders sein. Du hast eine Runtime-Lib und ein Startup-Programm dabei. Für die Runtime-Lib musst du üblicherweise Sachen wie Console Eingabe und Ausgabe definieren. Und im Startup werden die RAM Grenzen angegeben und es wird der Stack gesetzt und bei Bedarf das I-Register. Mehr ist nicht nötig. Es ist mit Sicherheit ein Hello-World Programm dabei. Nimm das als Anregung.
Angehängte Dateien:
-
DSC02544.jpg
740 KB
Ich finde den 8031 interessant da er viele interne Register hat, und einfach zu beschalten ist. Kann sogar Multiplikation. Schaltung bereits aufgebaut, jeweils 2 mal ein paar Stunden, kein Schaltplan. Muss nur noch das FLASH IC anschliessen. 6507 und 68000 Computer sind auch vorgesehen.
Angehängte Dateien:
Hi, zumindest kam heute erstmal der Scinken, den ich brauche an, sehr gute Zustand, 19 Euro ..... denke mal ich mache da weiter und erst danach an dem Board. Ich kenne mich intern mit dem AVR nicht sonderlich aus, denke aber dass ich auf Arduino Basis eine gemischte Lösung machen kann, dass der Z80 über seine PIO und vielleicht 4 Leitungen von der einen Datenspeicher adressieren kann, der am Atmel dran hängt. So eine Art SPI mit Bit Banging. Ist ja kein Thema da eine SD Karte dran zu papen - Arduino eben - und eine Art kleinen Treiber zu schreiben, der mal eben das RAM Image ablegt und es sich auch wieder reinzieht, so dass Programme erhalten bleiben. Zu sfr steht folgendes im Manual: 3.5.2.1 __sfr (in/out to 8-bit addresses) The Z80 family has separate address spaces for memory and input/output memory. I/O memory is accessed with special instructions, e.g.: __sfr __at 0x78 IoPort; /* define a var in I/O space at 78h called IoPort */ Writing 0x01 to this variable generates the assembly code: 40 3.6. OTHER SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC 3E 01 ld a,#0x01 D3 78 out (_IoPort),a 3.5.2.2 banked sfr (in/out to 16-bit addresses) The keyword __banked is used to support 16 bit addresses in I/O memory e.g.: __sfr __banked __at 0x123 IoPort; Writing 0x01 to this variable generates the assembly code: 01 23 01 ld bc,#_IoPort 3E 01 ld a,#0x01 ED 79 out (c),a
Angehängte Dateien:
-
io_schematic.gif
83 KB
Hier ist übrigens eine Möglichkeit ohne eine PIO die IO Pins eines Z80 gewaltig aufzublasen.
Christian J. schrieb: > Ich kenne mich intern mit dem AVR nicht sonderlich aus, denke aber dass > ich auf Arduino Basis eine gemischte Lösung machen kann, dass der Z80 > über seine PIO und vielleicht 4 Leitungen von der einen Datenspeicher > adressieren kann, der am Atmel dran hängt. Wenn, dann nimm doch gleich die Z80-DMA für gemeinsamen Speicher. Ich finde, wer alte Prozessoren wiederbeleben will, sollte beim damaligen Stand verbleiben und ihn auch so nachvollziehen. Es macht keinen Sinn, damit einen PC nachzuhecheln. Ich habe damit 1990 aufgehört. Vielleicht noch stromsparende Chips, größere Speicher, einen Uhren-Chip usw. einzubauen, das ist zu akzeptieren. Es sind Oldtimer, die auch so behandelt werden wollen. Ein sehr gutes Buch ist Kieser-Meder Aufbau und Anwendung des Mikroprozessorsystems U880 (Z80).
> Ich finde, wer alte Prozessoren wiederbeleben will, sollte beim > damaligen Stand verbleiben und ihn auch so nachvollziehen. Nicht unbedingt. Das hängt davon ab, ob es "authentisch Retro" sein soll wie bei Autos oder nicht. EPROMs machen mir keinen Spaß, also lasse ich sie weg. PALs und 8"-Disketten sind schwer zu bekommen, also lasse ich sie weg. DRAMs möchte ich allerdings benutzen, sonst ließe ich sie auch weg. Niemand verbietet dir USB oder Ethernet an solchen Basteleien - gibt auch genug Leute, die das an ihren C64 oder KC85 gebastelt haben. Wenn du den Druck hast, damit auch Youtube schauen zu wollen, dann ist die Bastelei sowieso nichts für dich. Andererseits... Youtube auf nem KC... wäre definitiv cool. ;-)
Christian J. schrieb: > zumindest kam heute erstmal der Scinken, den ich brauche an, sehr gute > Zustand, 19 Euro Was? 19 Euro? Dann muss ich meinen Zaks mal verscherbeln. Hätte nicht gedacht, das das Ding so viel wert ist. Ich brauche ihn jedenfalls nicht mehr.
S. R. schrieb: > DRAMs möchte ich allerdings benutzen, sonst ließe ich sie auch > weg. Gibt es so kleine DRAMs noch? Ich hätte einfach einen 128kB*8 SRAM rangepappt. Das DRAM-Timing mit Z80 ist nicht ganz ohne. Oft waren in den Schaltungen RC-Glieder zum Feinabgleich.
Peter Dannegger schrieb: > S. R. schrieb: >> DRAMs möchte ich allerdings benutzen, sonst ließe ich sie auch >> weg. > > Gibt es so kleine DRAMs noch? Neu wohl nicht mehr. Obwohl Pollin ein 256Kx1 dRAM verkloppt. Aber so was schnuckeliges wie 64Kx4 (61464?) findet man wohl nur noch in gut sortierten Bastelkisten. > Das DRAM-Timing mit Z80 ist nicht ganz ohne. Oft waren in den > Schaltungen RC-Glieder zum Feinabgleich. Was aber nicht heißt daß es nicht besser gehen würde. Wenn man den doppelten (IIRC, kann auch 4x gewesen sein) CPU-Takt zur Verfügung hatte, dann konnte man auch einen synchronen Generater für das signaling bauen. Nicht zu vergessen die geniale Methode, Speicherzugriffe per WAIT auf 4 Takte zu verlängern (dann sind sie gleich lang wie M1 Zyklen), dann aber zwei unabhängige Speicherzugriffe in jeden 4-Takte Zyklus zu packen. Z.B. einen für die CPU und einen für die Grafikhardware. Ich hab ja mal günstig einen i82720 GDC geschossen und trage mich immer noch mit dem Gedanken, daraus eine Grafikkarte für eines meiner Z80 Schätzchen zu bauen. Man bräuchte einen Sponsor, damit man nicht mehr arbeiten gehen müßte ;) XL
Georg G. schrieb: > Der Z80 hat ein einziges "SFR", das Register, das das Hi-Byte der > Interrupt Vektor Tabelle enthält. Unvollständig: Das andere "SFR" ist nur 7 Bit breit und enthält die Refresh-Adresse für dynamische RAMs. Sie wird im M1-Zyklus im Takt 4 auf den Adressbus gelegt und automatisch inkrementiert.
Ich halte es prinzipiell für Unfug ein CP/M System aus einem Z80 zu bauen und dann einen Amtel da als Slave dranzuketten. Entweder man macht die Peripherie und den Speicher mit dem Z80 selber (ok, für Ethernet und USB wird man Slaves brauchen) oder man läßt es. Wenn schon Retro dann IMHO richtig, man kann ein CP/M System mit 8MB Platten auf einer SD Karte betreiben, man kann aber auch einen 8272 (µPD765) da anknoten und ein Floppylaufwerk dran basteln. Ich empfehle da 5,25Zoll 800KB Laufwerke wege nder Zuverlässigkeit. die 3,5 Zoll PC Teile sind doch alle mehr oder weniger WORN Devices und alle unterschiedlich justiert. Console Interface ist dann eine SIO mit PC-Terminal dran, auf dem 2. Kanal kann noch ein Drucker landen. (Sofern man noch einen mit V.24 oder IFSS auftreiben kann). Übrigens weil einer mal Wordstar ansprach: auf einem 10Mhz Z80 macht sogar das Laune... Das Alles muß man nicht unbedingt alleine und zu Fuß machen, vieles davon wurde schon implementiert (Netzwerk, RAMdisk, SD-Card, IDE Interface, USB usw) und ist z.B: auf ollen DDR robotron K1520 Rechnern verfügbar. Ich habe solchen Kram auch noch da... Ehe der To ICs kauft: bitte bei mir nachfragen, ich sponsore die, will nur das Porto. Gruß, Holm
Holm Tiffe schrieb: > Ehe der To ICs kauft: bitte bei mir nachfragen, ich sponsore die, will > nur das Porto. Hi, tja, leider schon passiert, heute kamen alle IC's, dazu noch eine 8255 PIO (ist einfacher zu handhaben), 56k SRAMs im exotischen Gehäuse, Z80 CTC, Z80 SIO usw. Und mit CP/M wird nix, weil mir das viel zu aufwendig ist. Selbst durch Fremdprojekte durchzusteigen (zb FAT System für Flash Cards, angebunden durch IDE Schnittstelle) brauchst Du Tage. Es dreht sich alles immer um die Frage: Wie kriege ich meine Software da rein und teste sie, ohne dass zwischen Codeänderung und Test ne halbe Stunde vergeht. Wo drauf entwickel ich die Software? Auf dem Z80 oder einem PC? Wie speichere ich Programme ab? So nett wie beim PIC oder AVR wird es nicht sein, wo eine ISP dran ist und eine Uart zum Debuggen. Debuggen wird wohl gar nicht gehen. Heute mal geschaut.... einen Eprom Emulator kriegt man kaum noch und wenn dass fast 300 Euro. Damals an der uni hatte ich einen peps-3, damit ging das sehr einfach unter DOS.
> Wo drauf entwickel ich die Software? Auf dem Z80 oder einem PC? PC natürlich ;) Ausser du bist Masochist... > Debuggen wird wohl gar nicht gehen. Debugging wird überschätzt. Es reichen ein paar Leds zum Morsen schon aus, UART ist schon Luxus. Man lernt damit, auch etwas systematischer nachzudenken, was eigentlich wie schiefgehen kann, was zum Led-Pattern passt. > einen Eprom Emulator kriegt man kaum noch und wenn dass fast 300 Euro. Bau dir einen. Habs für mein allererstes eigenes uC-System (Z80, auch schon über ein Vierteljahrhundert her, urgs...) auch gebastelt. War recht trivial. Als Speicher ein SRAM (optional batteriegepuffert), daran für die Adressen 2*74HC590 und für die Daten ein 74HC595. Braucht nach aussen ~6 Leitungen. Wenn der Z80 im Reset ist, kann man bequem die Treiber der Zähler/SRs aktivieren und Daten ins SRAM reinschreiben (ging damals über den Parallelport). Dann OE wieder aus und Reset loslassen. Turnaroundzeit war im Bereich einiger 10s für ein paar KB Programm, war noch alles schnarchiges Basic... Den Emu habe ich vor ein paar Tagen beim Aufräumen sogar wieder gesehen :)
Christian J. schrieb: > Und mit CP/M wird nix, weil mir das viel zu aufwendig ist. Selbst durch > Fremdprojekte durchzusteigen (zb FAT System für Flash Cards, angebunden > durch IDE Schnittstelle) brauchst Du Tage. Ist das nicht das, was du willst? Oder ist dein Ziel nur, innerhalb von ein paar Stunden einen Z80 auf ein Brett zu löten und gut ist? Ein kleines CP/M-BIOS kriegt man in 300 Zeilen Assembly hin. > Es dreht sich alles immer um die Frage: Wie kriege ich meine Software da > rein und teste sie, ohne dass zwischen Codeänderung und Test ne halbe > Stunde vergeht. Da wirst du dir selbst was ausdenken müssen. In meinem Fall: "make", BREAK (für den Monitor), Hexfile verschicken, Reset. Dauert keine 10 Sekunden. > Wo drauf entwickel ich die Software? Auf dem Z80 oder > einem PC? Wie speichere ich Programme ab? SDCC ist ein Cross-Compiler. Der läuft nicht auf dem Z80. Wolltest du ihn nicht benutzen? > So nett wie beim PIC oder AVR wird es nicht sein, wo eine ISP dran ist > und eine Uart zum Debuggen. Debuggen wird wohl gar nicht gehen. Du bist sicher, dass du keinen Z80-Emulator benutzen willst? Da sind Debugschnittstellen meist drin, inklusive Breakpoints, Register gucken und so.
Christian J. schrieb: > Es dreht sich alles immer um die Frage: Wie kriege ich meine Software da > rein und teste sie, ohne dass zwischen Codeänderung und Test ne halbe > Stunde vergeht. Wo drauf entwickel ich die Software? Auf dem Z80 oder > einem PC? Wie speichere ich Programme ab? > > So nett wie beim PIC oder AVR wird es nicht sein, wo eine ISP dran ist > und eine Uart zum Debuggen. Debuggen wird wohl gar nicht gehen. Ein MODERNER Z80 hat JTAG und ZDS(ne Art Zweidraht-JTAG). Aber den willst Du ja nicht haben. fchk
>dazu noch eine 8255 PIO (ist einfacher zu handhaben)...
Unmengen von Programmierern und Elektronikern international ärgern sich
über das Ding und Du hältst es für einfacher?
Wolltest Du nicht ein Z80 System bauen? Die volle Leistungsfähigkeit der
Interruptkette im IM" bekommst Du nur mit Zilog ICs dieser Serie und die
PIO ist recht einfach zu handhaben :-)
Gruß,
Holm
Hallo, wie geil ist das denn? Einfach mal mit dem SDCC etwas gespielt, Nonsense Code geschrieben und es kommt Z80 Asm bei heraus! Kleines Script geschrieben, mit make2bin wird ein Bin File draus, sonst Intel-Hex-8. Ich weiss noch damals wie sehr ich mir einen Cross Compiler gewünscht habe, so um 1995 herum ..... gab es nicht oder war zu teuer. Dann kann es ja losgehen ..... muss nur noch die putchar überschreiben. Mal schauen, ob sich auch ein Monitor mit dem C Compiler schrieben lässt zumindest mit Inline Asm wegen der Int Tabelle, Startup Code usw. Ohne Asm geht es definiv nicht. Voila..... er macht was er soll, der SDCC :-) Aus
1 | #include <stdio.h> |
2 | #include <stdlib.h> |
3 | |
4 | int main() |
5 | {
|
6 | unsigned int a,i; |
7 | static __sfr __at 0x10 uart_data; |
8 | |
9 | i=0; |
10 | |
11 | for ( a = 0; a < 10; a++ ) |
12 | {
|
13 | i =i + a; |
14 | if (i>1000) |
15 | i=0; |
16 | }
|
17 | |
18 | i = 10; |
19 | while(--i>0) { |
20 | a = uart_data; |
21 | printf("%c", a); |
22 | }
|
23 | |
24 | return 0; |
25 | }
|
wird:
1 | 1 ;-------------------------------------------------------- |
2 | 2 ; File Created by SDCC : free open source ANSI-C Compiler |
3 | 3 ; Version 3.4.0 #8981 (Apr 5 2014) (Linux) |
4 | 4 ; This file was generated Sat Sep 6 11:09:47 2014 |
5 | 5 ;-------------------------------------------------------- |
6 | 6 .module test |
7 | 7 .optsdcc -mz80 |
8 | 8
|
9 | 9 ;-------------------------------------------------------- |
10 | 10 ; Public variables in this module |
11 | 11 ;-------------------------------------------------------- |
12 | 12 .globl _main |
13 | 13 .globl _printf |
14 | 14 ;-------------------------------------------------------- |
15 | 15 ; special function registers |
16 | 16 ;-------------------------------------------------------- |
17 | 0010 17 _main_uart_data_1_27 = 0x0010 |
18 | 18 ;-------------------------------------------------------- |
19 | 19 ; ram data |
20 | 20 ;-------------------------------------------------------- |
21 | 21 .area _DATA |
22 | 22 ;-------------------------------------------------------- |
23 | 23 ; ram data |
24 | 24 ;-------------------------------------------------------- |
25 | 25 .area _INITIALIZED |
26 | 26 ;-------------------------------------------------------- |
27 | 27 ; absolute external ram data |
28 | 28 ;-------------------------------------------------------- |
29 | 29 .area _DABS (ABS) |
30 | 30 ;-------------------------------------------------------- |
31 | 31 ; global & static initialisations |
32 | 32 ;-------------------------------------------------------- |
33 | 33 .area _HOME |
34 | 34 .area _GSINIT |
35 | 35 .area _GSFINAL |
36 | 36 .area _GSINIT |
37 | 37 ;-------------------------------------------------------- |
38 | 38 ; Home |
39 | 39 ;-------------------------------------------------------- |
40 | 40 .area _HOME |
41 | 41 .area _HOME |
42 | 42 ;-------------------------------------------------------- |
43 | 43 ; code |
44 | 44 ;-------------------------------------------------------- |
45 | 45 .area _CODE |
46 | 46 ;test.c:4: int main() |
47 | 47 ; --------------------------------- |
48 | 48 ; Function main |
49 | 49 ; --------------------------------- |
50 | 0000 50 _main_start:: |
51 | 0000 51 _main: |
52 | 52 ;test.c:9: i=0; |
53 | 53 ;test.c:11: for ( a = 0; a < 10; a++ ) |
54 | 0000 21 00 00 [10] 54 ld hl,#0x0000 |
55 | 0003 5D [ 4] 55 ld e,l |
56 | 0004 54 [ 4] 56 ld d,h |
57 | 0005 57 00107$: |
58 | 58 ;test.c:13: i =i + a; |
59 | 0005 19 [11] 59 add hl,de |
60 | 60 ;test.c:14: if (i>1000) |
61 | 0006 3E E8 [ 7] 61 ld a,#0xE8 |
62 | 0008 BD [ 4] 62 cp a, l |
63 | 0009 3E 03 [ 7] 63 ld a,#0x03 |
64 | 000B 9C [ 4] 64 sbc a, h |
65 | 000C 30 03 [12] 65 jr NC,00108$ |
66 | 66 ;test.c:15: i=0; |
67 | 000E 21 00 00 [10] 67 ld hl,#0x0000 |
68 | 0011 68 00108$: |
69 | 69 ;test.c:11: for ( a = 0; a < 10; a++ ) |
70 | 0011 13 [ 6] 70 inc de |
71 | 0012 7B [ 4] 71 ld a,e |
72 | 0013 D6 0A [ 7] 72 sub a, #0x0A |
73 | 0015 7A [ 4] 73 ld a,d |
74 | 0016 DE 00 [ 7] 74 sbc a, #0x00 |
75 | 0018 38 EB [12] 75 jr C,00107$ |
76 | 76 ;test.c:19: while(--i>0) { |
77 | 001A 11 0A 00 [10] 77 ld de,#0x000A |
78 | 001D 78 00104$: |
79 | 001D 1B [ 6] 79 dec de |
80 | 001E 7A [ 4] 80 ld a,d |
81 | 001F B3 [ 4] 81 or a,e |
82 | 0020 28 13 [12] 82 jr Z,00106$ |
83 | 83 ;test.c:20: a = uart_data; |
84 | 0022 DB 10 [11] 84 in a,(_main_uart_data_1_27) |
85 | 0024 6F [ 4] 85 ld l,a |
86 | 0025 26 00 [ 7] 86 ld h,#0x00 |
87 | 87 ;test.c:21: printf("%c", a); |
88 | 0027 01r39r00 [10] 88 ld bc,#___str_0 |
89 | 002A D5 [11] 89 push de |
90 | 002B E5 [11] 90 push hl |
91 | 002C C5 [11] 91 push bc |
92 | 002D CDr00r00 [17] 92 call _printf |
93 | 0030 F1 [10] 93 pop af |
94 | 0031 F1 [10] 94 pop af |
95 | 0032 D1 [10] 95 pop de |
96 | 0033 18 E8 [12] 96 jr 00104$ |
97 | 0035 97 00106$: |
98 | 98 ;test.c:24: return 0; |
99 | 0035 21 00 00 [10] 99 ld hl,#0x0000 |
100 | 0038 C9 [10] 100 ret |
101 | 0039 101 _main_end:: |
102 | 0039 102 ___str_0: |
103 | 0039 25 63 103 .ascii "%c" |
104 | 003B 00 104 .db 0x00 |
105 | 105 .area _CODE |
106 | 106 .area _INITIALIZER |
107 | 107 .area _CABS (ABS) |
Angehängte Dateien:
-
DSCN7615.JPG
240 KB
Moin, so das Z80 ist in der Planung fertig. Auf dem Block, für einen sauberen Eagle Schaltplan fehlte mir doch der Nerv. Um ein wenig mehr zu haben wird noch ein antiker.. abstaub.... ADC 0804 AD/Wandler dran gepappt an eine freie decodierte Leitung des I/O Busses. Köstlichkeiten wie den 12 Bit ADC 84 und DAC 80 von Burr Brown habe ich auch noch, monströse schwere Chips in Keramik. Ich frage mich die ganze Zeit nur, wieso ich nicht noch einen Schritt in der Evoluion zurück gehe und zb eine PDP-11 nachbaue? So ein TTl Grab.... da sieht man ja fast die Elekronen flitzen, wenn man viele LEDs an die Ports klebt :-) Und diese weisse Herdplatte links oben mit den beiden Kochfeldern macht auch was her. Glaube damit kann man auch eine ganze CPU nachbauen, so im Format Backblech..... ;-) Frage: Ich habe mit der seriellen Schnittstelle noch ein Problem. In Grant's Plänen http://searle.hostei.com/grant/z80/SimpleZ80.html benutzt er einen TTL-USB Converter mit CTS/DTR Signal, angesteuert von einer 68B50. Keine Z80 SIO. So etwas habe ich nicht gefunden. Diese Arduino Cips für 2 Euro fuffzig haben nu RX und TX, was ja auch reicht. Mit einem 3,64 Mhz Quartz müssten 56 kBaud erreichbar sein. Wozu also diese beiden Modem Leitungen? Gruss, Christian
Christian J. schrieb: > Wozu also diese beiden Modem Leitungen? Um die Übertragung zu bremsen, falls es einer Seite zu schnell gehen sollte, was ja bei den alten Schätzchen u.U. häufiger vorkommen dürfte, als bei modernen Multicore-Gigahertz-CPUs.
Christian J. schrieb: > der Evoluion zurück gehe und zb eine PDP-11 nachbaue? So ein TTl > Grab.... da sieht man ja fast die Elekronen flitzen Wenn du damit das Bild meinst: Das ist ja schon eine neumodische VLSI-Version mit einer hochintegrierten CPU in Form ebendieser Herdplatte. Bei den vorherigen Typen war nicht nur das Drumrum aus TTLs der 74Sxx Serie, aufgebaut sondern auch die CPU selbst: http://www.neurotica.com/w/images/7/79/DEC-PDP1170-KB11C-3.jpg (hier ohne FPU, wie man unschwer erkennen kann).
Für museumsreife Mikroprozessoren und deren Peripherie ist Kessler immer mal einen Blick wert. So findet sich da neben DMA und CTC auch ein PIO, allerdings in PLCC44: http://www.kessler-electronic.de/Halbleiter/integrierte_Schaltkreise/Mikrocontroller/Zilog_Z80_c245.htm Segor ist als Bezugsquelle verstaubter Hardware auch recht interessant und da findet sich auch der normale PIO in DIP40: http://www.segor.de
Christian J. schrieb: > Ich weiss noch damals wie sehr ich mir einen Cross Compiler gewünscht > habe, so um 1995 herum ..... gab es nicht oder war zu teuer. TASM gabs aber damals schon lange und war immer sehr preisgünstige Shareware. Der konnte (und kann auch heute noch) einen Haufen Prozessoren programmieren, wie den Z80, 6502, 6800,MCS-48,MCS-51, TMS32020 usw. Du kannst auch neue Prozessoren definieren - ist eben ein Tabellengesteuerter Assembler. Hier mal ein Beispiel: http://www.vintagecomputer.net/software/GNICE/TASM/TASMTABS.HTM Falls du das Binary nicht auftreiben kannst, kann ich dir bestimmt mal was zusammensuchen. Im Anhang ist ein kleines Monitorprogramm in Z80 Assembler, eigentlich fur den Toshiba TMPZ84C015 gedacht, der ein komplettes Z80 System mit PIO,SIO und CTC beinhaltet - der CEPAC80 von der c't war ein Kleinsystem mit diesem Chip. Der Monitor residiert im Bereich von 0000h-1fffh. Ab 9000 ist ein RAM eingeblendet, der optional gepuffert wird und Programme oder Daten hält. So ein Dings hat jahrelang meinen alten (analogen) Satellitenempfänger gesteuert, im RAM waren die Programmspeicher. Der Monitor kann auch ein IntelHex empfangen und dann ausführen.
Hallo, mit dem TASM habe ich damals einen Stealth Virus für DOS geschrieben, der war aber von Borland. War total happy, dass ich den an der Uni bekam. Danke erstmal für den Source, werde ich da mal einarbeiten sobald das System läuft und ich den Zaks durch habe, denn soooooo einfach ist das alles doch nicht. Die Interrupt Struktur des Z(0 ist mir so neu, der gibt ja über die PIO ein Register zuück, so dass die IR Quelle indentifiziert werden kann. der 6510 hatte nur eine IRQ Quelle, den NMI und den INT Pin. Ich finde den ARM7 schon komplex aber da habe ich eine astreine IDE von Rowley wo ich alles machen kann icl Singe Step Debugging, Test im RAM usw. CPU aus Gattern aufbauen? Hatten die sonst keine Hobbies? Am Zeichenbrett? Ich habe sowas mal gesehen in meiner alten Fima, hoch komplexe Schaltpläne mit Tusche auf A2 .... örks @Matthias: evtl habe ich später nochmal ne Frage, denn mich interessiert vom Monitor nur der Intel Hex Upload. Ich werde 8kb ROM einbauen und 56kb RAM, es wird nur ein Upload Programm geben und den Basic Interpreter, sowie ein Memory Dump. Also quasi Auswahl 1) Upload 2) Save 3) Basic 4) Memory Dump wobei das Save auch nur ein Listen ist, das ich mit dem Terminal wieder abspeichern kann. Gruss, Christian
Christian J. schrieb: > CPU aus Gattern aufbauen? Hatten die sonst keine Hobbies? http://www.mycpu.eu/
>Die Interrupt Struktur des Z80 ist mir so neu Diese Aussage zeigt, daß du dich mit dem in deinem Besitz befindlichen Z80-System "Microprofessor" niemals (ernsthaft) beschäftigst hast. Denn dort wird das ausführlich mit funktionsfähigen Beispielen gemacht. Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" Gruss
Angehängte Dateien:
Erich schrieb: > Z80-System "Microprofessor" niemals (ernsthaft) beschäftigst hast. Doch...... so ca 1986 mal und seitdem liegt das Ding in der Kiste und wurde nie wieder angeschaut, weil es mir zu blöd ist Asm per Tabelle in Hex umzurechnen..... hier noch ein Terminal eines CC85 den ich damals für 300 bei Conrad kaufte. RN = Return, BS = Backstep. AD = Adresse, DT = Data. Alles schön in Hex eintippen :-) Machen konnte man mit dem Ding nichts! Zumindest nichts sinnvolles. Habe nur noch ein Kassetten Interface dran gebaut und einen 8253 Timer und danach die Lust verloren. Übrigens bin ich gerade DABEI mich damit zu befassen. Hautpscahe ich verstehe wie die Cortex IRQ Struktur funktioniert, damit verdiene ich u.a. nämlich Geld das zu verstehen :-)
Joe G. schrieb: > Christian J. schrieb: >> CPU aus Gattern aufbauen? Hatten die sonst keine Hobbies? > > http://www.mycpu.eu/ Ich habe da mal quer gelesen und mir einige Schaltpläne angeschaut bzw Sourcen. Der Junge ist 32, hat E_technik studiert. Er kennt sich sehr gut damit aus wie eine ALU innendrin aufgebaut ist. Hat einen Befehlsdecoder mit Microcode realisiert, da der Aufwand das mit Gattern zu machen noch deutlich höher ist als 50 TTL Chips. Er wird Tage gebraucht habe die Timing Probleme in den Griff zu kriegen. Er hat einen eigenen Assembler geschrieben, eigenen Basic Interpreter, ein eigenes DOS, einen TCP IP Stack. Er hat eine vermutlich überdurchschnittliche Intelligenz und sicher keine Freundin, weil Frauen Zeit beanspruchen, die er nicht hat. Ich bewundere sowas aber ich habe nie Zeit verschwendet Dinge zu bauen, die es schon gibt, sondern das was es gab dazu benutzt etwas Neues daraus zu machen.
> Z80-System "Microprofessor" Ich habe auch so'n Teil, angeschafft 1981/1982, als es aktuell war. Da ich auch über ein CP/M System verfügte, habe ich die beiden Teile über eine am Microprofessor nachgerüstete serielle Schnittstelle ergänzt. Anfangs musste ich noch einen "Urbootloader" täglich inn Ram eintippen. Aber kurz später habe ich das Eprom gepatched und musste nur noch <Adresse><Go> drücken, damit wartete der Microprofessor auf ein ausführbares Programm für seinen Rambereich. Ob ich Intel-Hex benutzte oder Binärformat weiss ich jetzt nimmer. Auf jeden Fall schrieb ich meine Programm für den Microprofessor fortan auf dem CP/M System, assembliert mit M80/L80. Später ergänzte ich den Microprofessor auf seinem Lochrasterfeld mit einen Multiplex-Interface für eine Brother-Typenradschreibmaschine, deren Tastaturmatrix ich angezapft hatte (denn Schreibmaschinen mit Interface waren unbezahlbar). So konnte ich über den Microprofessor als Subsystem auch Schönschriften (Briefe etc.) in Wordstar verfasst schreiben und ausdrucken. Texte sauber in Blocksatz geschrieben (http://de.wikipedia.org/wiki/Blocksatz), als Student wohlgemerkt, nicht nur auf den Epson Matrixdrucker, da staunten manche Leute... Gruss
Angehängte Dateien:
-
jobs_wozniak_apple1.jpg
82 KB
Wie gesagt, irgendwann kommen wir alle wieder bei den Keulen und Steinhämmern an ..... wenn ich sowas hier sehe, Transistor für Transistor Qualität :-) Und wirklch Geld verdient haben damit nur die beiden, zur richtigen zeit am richtigen Ort das Richtige gemacht. http://www.4004.com/assets/PB120046.JPG
Eine kurze Frage: Die Z80 PIO oder liebr den 8255? Der 8255 ist einfacher und hat 3 Ports. Die PIO hat alle mögichen Funktionenl die wohl mal für Drucker, Centronics, Lochkartenleser usw. vorgesehen waren, die aber heute kein Mensch mehr braucht. Leider haben beide Chips wohl gemeinsam, dass sich die Ports nur als Ganze auf Out oder IN setzen lassen. Ob man den Interrupt Firlefanz der PIO braucht sei mal dahin gestellt. Ich brauche eigentlich nur einen birdiretionalen Port um etwas anzuschliessen. Spricht also was gegen den 8255? Oder für die Z80 PIO?
Christian J. schrieb: > Ich brauche eigentlich nur einen birdiretionalen Port um etwas > anzuschliessen. Dann nimm einen bidirektionalen Bustreiber. Dein 8255 hat drei davon vereint und werde glücklich. Für deine einfachen Aufgaben reicht das. Die Z80-PIO hat jedoch Eigenschaften, welche man in den Ports moderner MC wiederfindet.
Angehängte Dateien:
-
pio.jpg
150 KB
Christian J. schrieb: > Leider haben > beide Chips wohl gemeinsam, dass sich die Ports nur als Ganze auf Out > oder IN setzen lassen. Schon mal einen Blick ins Datenblatt riskiert?
Christian J. schrieb: > Die Z80 PIO oder liebr den 8255? Nimm das was Du da hast. > Der 8255 ist einfacher und hat 3 Ports. Vier. Zwei mit 8 bit und zwei mit 4 bit. Will sagen, Port C ist teilbar. Damit kann man den Handshake für die Ports A und B machen, z.B. für zwei Druckerports. > Ob man den Interrupt Firlefanz der PIO braucht sei mal dahin gestellt. Wenn Du "richtige" Z80-Interrupts haben willst, also mit 255 Vektoren, dann brauchst Du den. Der einfache Spring-Nach-0038h (mode 1) geht auch so. Oft reicht das -- Motorola hatte ja damals auch nur einen /IRQ mit festem Sprungziel.
Erich schrieb: >>Die Interrupt Struktur des Z80 ist mir so neu > Diese Aussage zeigt, daß du dich mit dem in deinem Besitz befindlichen > Z80-System "Microprofessor" niemals (ernsthaft) beschäftigst hast. Naja, ich habe damals relativ komplexe Sachen mit dem CEPAC80 gemacht, aber heute müsste ich mich da auch wieder einarbeiten, wenn ich das wollte. Christian J. schrieb: > Die Z80 PIO oder liebr den 8255? > > Der 8255 ist einfacher und hat 3 Ports. Die PIO hat alle mögichen > Funktionenl die wohl mal für Drucker, Centronics, Lochkartenleser usw. > vorgesehen waren, die aber heute kein Mensch mehr braucht. Das kann man vorher nicht wissen, die PIO ist halt für die etwas merkwürdige INT-Vektor Mimik des Z80 genau massgeschneidert und macht einiges automatisch, wozu du beim 8255 etwas Code brauchst. Der o.a. Satellitenempfänger hatte so viele Ports, das ich mit externen Latches (74373) und Input Ports (74244) nachhelfen musste. Für 'Pinchange' Interrupts im modernen Sinne gehts ohne PIO nur sehr schwer und mit externer Hardware neben dem 8255. Die IR-Fernbedienung meines Sat-RX nutzte deswegen die PIO Hardware des TMPZ Chips.
Christian J. schrieb: > Leider haben > beide Chips wohl gemeinsam, dass sich die Ports nur als Ganze auf Out > oder IN setzen lassen. Nö. Z80-PIO: In Mode 3 kann man die Richtung bitweise festlegen. Und mit einer Maske kann man festlegen, welche Pins einen Interrupt auslösen sollen.
>die PIO ist halt für die etwas >merkwürdige INT-Vektor Mimik des Z80 >genau massgeschneidert Das ist keine "merkwürdige Mimik", sondern der anno 1976 von Zilog eingeführt Vector-Interrupt-Mode "IM2". Hierbei liefern die Peripheriebausteine PIO, CTC oder SIO bei der Auslösungen eines INT direkt eine <Lo-Adresse> (die den Bausteinen bei ihrer Initialisierung zugewiesen wird). Zusammen mit der <Hi-Adresse> die im CPU Register "I" initialisiert wird, ergibt sich somit eine <16Bit-Adresse> als Zeiger. Der Zeiger zeigt auf eine Tabelle, unter der die Startadressen der jeweiligen Interrupt-Funktionen definiert sind. Denn man muss wissen: Jeder der Bausteine PIO, CTC, SIO hat mehrere Vektoren, kann somit mehrere Interrupt-Funktionen direkt auslösen. Der CTC (Counter/Timer) hat z.B. 4, je einen eigenen für seine 4 Timerkanäle. Wird jetzt beispielsweise der Kanal2-INT ausgelöst, so "landet" die Programmausführung wenige Takte später direkt in der Unterfunktion CTC_INT_CH2. Ohne daß irgendwo noch umständlich abgefragt werden muss, welcher Baustein oder welcher Unterkanal des Bausteins den INT ausgelöste hat. Die SIO (serieller Baustein) hat noch mehr Vektoren (8); sie unterscheidet zwischen ihren beiden Channels A/B sowie direkt zwischen Rx und Tx sowie Rx error und Tx error. Ein fast geniale Struktur, die andere Hersteller (bis heute) nicht verstanden haben. Konkretes gut erklärtes Beispiel mit Sourcecodelisting findet sich in der Datei MPF-1_experimentManual.pdf (Link über http://electrickery.xs4all.nl/comp/mpf1/doc/index.html). Dort "Experiment 15" ab Seite 103 (109/152 der PDF). Gruss
Erich schrieb: > Ein fast geniale Struktur, die andere Hersteller (bis heute) nicht > verstanden haben. Ja, man spart viel Zeit, da man nicht erst umständlich ermitteln muß, wer den Interrupt auslöste. Daher bin ich auch nie mit dem PIC warm geworden. Ich fands ja schon nervig, daß sich beim 8051 UART Senden und Empfang einen Vektor teilen mußten.
Erich schrieb: > Die SIO (serieller Baustein) hat noch mehr Vektoren (8); sie > unterscheidet zwischen ihren beiden Channels A/B sowie direkt zwischen > Rx und Tx sowie Rx error und Tx error. > Ein fast geniale Struktur, die andere Hersteller (bis heute) nicht > verstanden haben. Was Du schreibst, ist mehr als gewagt! Einerseits muß ich schmunzeln, andererseits aber auch dieser Aussage widersprechen. Als Beispiel nenne ich den RX62; die Interrupt-Vektor-Tabelle zeigt die Details.
@m.n: Du vergleichst jetzt nicht wirklich einen aktuellen Renesas Controller mit dem Z80 System von 1976 und stellst die auf eine Stufe? @Christian: Ich sags nochmal: Einfacher ist der 8255 nicht. Der wird sogar richtig lustig wenn Du die Betriebsarten zur laufzeit ändern willst. Das Ding ist voll von Glitches und kann eine büchse der Pandora sein wenn es drauf an kommt. Zilog hat sich beim PIO schon ziemlich viel gedacht, das IM2 Vektorsystem ist genial, auch wenn es an der Signallaufzeit der Prioritätskette seine Grenzen findet. Das Teil ist auch nicht kompliziert zu programmieren, hast Du schon mal ins Datenblatt geguckt? Für den Z80 Kram gibts gute deutsche Beschreibungen, suche ggf. einfach nach einem Datenblatt vom U855, der DDR Variante des PIOs. Man sollte aber auch das Interruptsystem im Interruptmode 2 verstanden haben, bzw. verstanden haben wollen ehe man das irgendwie abtut. >Der 8255 ist einfacher und hat 3 Ports. Die PIO hat alle mögichen >Funktionenl die wohl mal für Drucker, Centronics, Lochkartenleser usw. >vorgesehen waren, die aber heute kein Mensch mehr braucht. Du bist eine Pappnase. Ich würde einiges darum geben einen Controller zu haben dessen Inputports ein komplettes Datenwort über ein Strobesignal latchen können. Diese Funktionalität braucht wohl heute kein Mensch mehr.. außer mir. Heute löst man einen Interrupt aus und liest per Software den Port ein, Scheiße nur wenn das viel zu lange dauert. Umgekehrt das Selbe, ein OutputRegister mit einer Variable vorladen und mit einem Enable Signal von hochohmig auf Ausgabe schalten... geht heute nicht mehr, also löte ich zusätzliche Three-State Driver / Latch ein. (Ok, die Anwendung eines Controllers als intelligentes Interface an einem Rechnerbus eines alten Computers ist heute obskur, das ändert aber nichts daran, das diese Funktionalität meistens fehlt. Der Olle 8042 Tastaturcontroller aka UPI konnte genau das, die PIO kann es auch) Nimm den Mund nicht so voll bei Sachen die du nie verstanden hast. Das war früher schon eines Deiner Probleme :-) Zum Deinem Amp: Röhren sind nicht wegen ihrer schlechten elektrischen Eigenschaften abgeschafft worden sondern wegen ihrer Baugröße und des Energeiverbrauches. Es wundert mich deshalb überhaupt nicht, wenn Dein 12 Jahre alter EL84 Amp immer noch zur Zufriedenheit tut. "...Kannst du mir das Radio reaprieren? Ist bestimmt nur eine Röhre.." Nein, es ist nahezu nie eine Röhre die den Geist aufgegeben hat, sondern andere Dinge wie Koppelkondensatoren.. Gruß, Holm
Holm Tiffe schrieb: > @m.n: Du vergleichst jetzt nicht wirklich einen aktuellen Renesas > Controller mit dem Z80 System von 1976 und stellst die auf eine Stufe? Auf die Gefahr hin, dass Du auch mich als Pappnase beschimpfst oder den Mund verbieten willst, wiederhole ich Erichs Kernaussage: Erich schrieb: > Ein fast geniale Struktur, die andere Hersteller (bis heute) nicht > verstanden haben. Damit wird dem Z80 ein (bis heute) unerreichtes Alleinstellungmerkmal angedichtet; das geht mir einfach gegen den Strich! Allerdings sehe ich auch, dass zum Beispiel die STM32F4xx immer noch viele Interrupts über einen einzigen Vektor abhandeln und man alle relevanten Statusbits in der ISR 'abklappern' muß. Das geht mir auch gegen den Strich :-)
m.n. schrieb: > Holm Tiffe schrieb: >> @m.n: Du vergleichst jetzt nicht wirklich einen aktuellen Renesas >> Controller mit dem Z80 System von 1976 und stellst die auf eine Stufe? > > Auf die Gefahr hin, dass Du auch mich als Pappnase beschimpfst oder den > Mund verbieten willst, wiederhole ich Erichs Kernaussage: > > Erich schrieb: >> Ein fast geniale Struktur, die andere Hersteller (bis heute) nicht >> verstanden haben. > > Damit wird dem Z80 ein (bis heute) unerreichtes Alleinstellungmerkmal > angedichtet; das geht mir einfach gegen den Strich! Er hat trotzdem recht. Es ist nämlich vergleichsweise simpel, die diversen on-Chip Interruptquellen eines µC auf verschiedene Vektoren zu legen. Schließlich ist deren Zahl ja bekannt. Das Z80 System beherrschte das aber für eine fast beliebige Anzahl an IO-Bausteinen und mit einer variablen Anzahl Vektoren pro Baustein. XL
m.n. schrieb: >> Ein fast geniale Struktur, die andere Hersteller (bis heute) nicht >> verstanden haben. > > Was Du schreibst, ist mehr als gewagt! Insbesondere Hersteller, die in ihre Mikroprozessorentwicklung Erfahrung mit Minicomputern einfliessen liessen, hatten deutlich besser entwickelte Interrupt-Systeme, als die meisten 8-Bitter von Haus an Bord hatten. TI hatte den TMS9900 von der 990 Familie abgeleitet, war damit vor Zilog auf dem Markt und bot 16 Interrupts mit jeweils eigenem Registersatz für Kontextswitch (eigentlich wars RAM). National Semiconductor hatte kurz nach Intel 8080 mit der aus den Data General Novas abgeleiteten PACE Familie immerhin 5 Interrupts. Intels 8080 war ohnehin eher ein Bausatz als ein Single-Chip Mikroprozessor. Eigentlich ein 3-Chip Prozessor, denn ohne speziellem Taktgenerator und Buscontroller ging wenig. Mit dem für bessere Interrupts notwendigen Interruptcontroller waren es dann 4. Aber immerhin - Interrupts mit Prioritäten und getrennten Vektoren waren möglich. Der im PC auch heute noch schlummernde 8259 geht darauf zurück. Das besondere am Interrupt-System der Z80 war der ziemlich geringe Aufwand an Pins und externer Beschaltung, so lange nur wenige Bausteine benötigt wurden und die daisy chain dementsprechend kurz war. Für Integration von Fremdperipherie in dieses IM2 Verfahren musste man dann eben den PIO als Interruptcontroller verwenden.
Angehängte Dateien:
-
z80inside2.JPG
520 KB
Hallo, na, jetzt gehen die Glaubenskriege aber los :-) Dass der 8255 Glitches hat war schon damals bekannt aber idr stellt man ihn einmal ein und damit hat es sich. Oder man stellt ihn um und wartet bis er fertig ist. Er ist schon einfacher, da er nicht so viel Innenleben hat. Sa mir doch mal wofür ich bei einem Bastelcomputer ein Bit Datenwort per Latch und Srobe übergeben muss? Maximal werded ich damit eine Bitbang SpI realisieren, die ein Arduino Display füttert. Und heutige Controller haben eben eine andre IRQ Struktur, die meisten eben Pins, die sich als IQ Quelle schalten lassen und dann weiss man woher er kommt. Der Z80 und Peropherie wurden aufenander abgestimmt als es noch für alles einen Baustein gab. Heute hast du alles in einem und jede Menge interne IQ Flags. die du auswerten kannst. Allein der ARM7 hat einen ganzen Korb voll, glaube es sind viele Dutzend. Aber es wächst, heute kam wieer der Postbote mit einer Hand voller Tüten an ... Einen Baustein für die CPU, einen Baustein für den Parallelport einen Baustein für das ROM einen Baustein für das RAM einen Baustein für die UART, einen Baustein für die Timer, einen Löffel für Papa und einen für die Mama :-) Wahnsinn, das hat man alles auf einen Attiny drauf und der ist noch 10 Mal schneller. Wieso nehme ich nicht gleich einen AVR? Bin ich denn gaga? ..... jetzt fehlt nur noch das passende T-Shirt dazu örks >>Das besondere am Interrupt-System der Z80 war der ziemlich geringe >>Aufwand an Pins Wie bitte? Man braucht 8 Datenleitungen, 4 Steuerleitungen, 3 Adressleitungen ..... das ginge doch auch alles Seriell mit I2c. Mfg Chris
Angehängte Dateien:
-
DSC08126.JPG
1,2 MB
So wird es werden, nur mal gesteckt. unten drunter Fädelkämme, daher die großen Abstände zwischen den Chips. Die I/O leiste kommt rechts neben den 8255 (oder Z80 PIO), dann ist noch ein Z80 CTC drauf (kein 8253 :-) und der 60B84 als Uart - Z80 SIO ist mir zu voll geladen -aber die habe ich in China bestellt und dauert noch. >> ein OutputRegister mit einer Variable vorladen und mit einem Enable >> Signal von hochohmig auf Ausgabe schalten Was geht nicht mehr ????? Wo ist das problem? Beim ARM7TDMI hast du Unterschiedliche register für Ein und Ausgabe. Du lädt die Ausgabe ins Output vor aber stellst den Port auf Input ein, damit wird er Tri-state. Dann geht das was dran ist ins Leseregister. Schaltest du die Datenrichtung um mit FIOSEL glaube ich geht das was im Output steht direkt auf den Port. Der ARM ist einer der genialsten Maschinen überhaupt, auch wenn man Romane schreiben muss, um nur die Clocks über die PLL einzustellen und die Teiler richtig zu berechnen. Da ist alles drin aber eben "unverdrahtet", die Drähte in Form von Code muss man selbst legen.
Christian J. schrieb: > Beim ARM7TDMI hast du Unterschiedliche register für > Ein und Ausgabe. Der ARM7TDMI ist ein Prozessorkern. Der hat keinerlei Ein/Ausgaberegister. Das ist Sache jenes Herstellers, der den Kern zusammen mit allerlei Peripherie zu einem LPC2000, STM7, ... zusammenklebt. Und je nach Genialität dieses Herstellers kommt da eine mehr oder auch weniger gute Lösung für I/O-Pins raus. Mit den Interrupts ist das ähnlich. Die ADuC7000 Serie darf man in dieser Hinsicht wohl als eher vorsintflutlich betrachten.
Hallo, > Wenn Du "richtige" Z80-Interrupts haben willst, also mit 255 Vektoren, > dann brauchst Du den. Es gibt nur 127 Vektoren, weil die auf geraden Adressen liegen müssen (das unterste, von der Peripherie gelieferte Bit muss null sein). > Für Integration von Fremdperipherie in dieses IM2 Verfahren musste man > dann eben den PIO als Interruptcontroller verwenden. Oder man baut sich einen IM2-Controller mit 8 Interrupts aus einem '148 (Encoder) und einem '541 (für den Vektor) zusammen. Allerdings muss die Hardware dann den Interrupt so lange aktiv halten, bis er verarbeitet wurde. Das geht aber auch hinter der Daisy-Chain noch. > Ich würde einiges darum geben einen Controller zu haben dessen > Inputports ein komplettes Datenwort über ein Strobesignal latchen > können. Schau' dich mal bei den kleinen PICs um, die können das wohl. Mein AVR lässt, weil er genau das nicht kann, den Z80 per Extra-Gatter so lange Waitstates drehen (und dreht ihm danach auch noch den Bus ab), bis er in aller Ruhe analysiert hat, was ich gerade von ihm will. > Sa mir doch mal wofür ich bei einem Bastelcomputer ein Bit Datenwort > per Latch und Srobe übergeben muss? Maximal werded ich damit eine > Bitbang SpI realisieren, die ein Arduino Display füttert. Für IDE brauchst du einen 16 Bit breiten Datenbus (Ausnahme: antike Festplatten, CF-Karten im IDE-Modus oder 50% Platzverschwendung). Das gemeinsam latchen zu können, ist schon hilfreich. > Und heutige Controller haben eben eine andre IRQ Struktur, die meisten > eben Pins, die sich als IQ Quelle schalten lassen und dann weiss man > woher er kommt. Das ist genau dann besonders sinnvoll, wenn es um die Controller-internen Einheiten geht. ;-) > Wieso nehme ich nicht gleich einen AVR? Bin ich denn gaga? Offensichtlich. ;-) Aber AVR kann ja jeder. >>>Das besondere am Interrupt-System der Z80 war der ziemlich geringe >>>Aufwand an Pins > > Wie bitte? Man braucht 8 Datenleitungen, 4 Steuerleitungen, 3 > Adressleitungen ..... das ginge doch auch alles Seriell mit I2c. Eigentlich reichen, um IRQs zu verarbeiten, 2 Steuerleitungen (/M1 und /IORQ) und ausreichend (max. 7) Datenleitungen aus. Gruß, Svenska
Angehängte Dateien:
-
p6cpusch.gif
220 KB
Hi, ich habe einen recht guten Plan gefunden, den ich hier mal anhänge. Vor allem die Decodierung gefällt mir besser als diese Gattergräber. Da ich für die Uart einen 6850 benutze und einen CTC Timer denke ich mal, dass es ein Problem werden könnte beide Bausteine an den INT Pin zu hängen. Der Z80 erwartet ja diese Kette. Andererseits wäre es denkbar, dass der 6850 mit seinem INT Pin an den INT Eingang des CTC geht und der CTC wiederum an den Z80. Ich will auf jeden Fall den Timer Baustein benutzen, um zb Anzeigen anzusteuern.
Es ist zum Heulen! Wenn ich den Z80 CTC Timer verwenden will, muss der an den INT Pin der CPU dran, da die Timer ja INTs auslösen sollen, um zeitgesteuerte Aufgaben zu erledigen. Timer will ich haben, basta! Aber ich brauche auch die INTs der seriellen Schnittstelle und da sitzt eben ein einfacher 28poliger 6850 dran, der auch von seiner Größe auf die Eurokarte passt. Die Z80 SIO ist ein 40 pinniger Trümmer und ich brauche grad mal 4 Leitungen nach außen: TX,RX,CTS,RTS. Und die SIO ist recht komplex, ich müsste die Routinen selbst schreiben um mit dem PC in einem Terminal zu kommunizieren. Es gäbe keine Möglichkeit die INTs des CTC und die des 6850 (Zeichen ist da) der CPU mitzuteilen, da die dann nicht weiss woher der INT gekommen ist. Denkbar wäre den CTC an die CPU zu pappen über den INTOUT Pin und am INT_IN den 6850 dran zu hängen, der aber nicht die Fähigkeit hat einen Vektor auf den Bus zu legen. Andere Alternative: Das Minimalsystem auf einer Eurokarte aufbauen CPU, RAM, ROM, Glue Logic, Decoder + Z80 SIO zum PC Interface und einen kompletten Bus mit Decodierungsleitungen (sagen wir mal 4 Stück) nach außen zu legen (bewahre mich vor dem Verdrahten) an den dann eine weitere Eurokarte anzuschliessen, wo nur Peripherie drauf ist. Falls jemand einen Schaltplan hat, wo wirklich alles drauf ist immer her damit!
Christian J. schrieb: >>>Das besondere am Interrupt-System der Z80 war der ziemlich geringe >>>Aufwand an Pins > > Wie bitte? Man braucht 8 Datenleitungen, 4 Steuerleitungen, 3 > Adressleitungen Klar. Aber die brauchte man doch sowieso. Stichwort Bus. Aber im Gegensatz zum z.B. IBM-PC kam ein Z80 System mit einer einzelnen /INT Leitung aus - für bis zu 128 Interruptquellen. Der PC mit seinem PIC (Programmable Interrupt Controller) hat statt dessen eine handvoll separater Leitungen, die man erst wieder manuell jumpern muß um seine Interruptquellen auf Vektoren zu verteilen. Eine Krücke halt. Wie so vieles beim PC. S. R. schrieb: >> Ich würde einiges darum geben einen Controller zu haben dessen >> Inputports ein komplettes Datenwort über ein Strobesignal latchen >> können. > > Schau' dich mal bei den kleinen PICs um, die können das wohl. Bäh. PICs (vor allem die kleinen) sind doof und riechen nach Lulu. Oder anders gesagt: vom Regen in die Traufe. Dann nehme ich doch wirklich lieber ein separates Latch in Hardware. XL
Christian J. schrieb: > Es ist zum Heulen! > > Wenn ich den Z80 CTC Timer verwenden will, muss der an den INT Pin der > CPU dran, da die Timer ja INTs auslösen sollen, um zeitgesteuerte > Aufgaben zu erledigen. Timer will ich haben, basta! > > Aber ich brauche auch die INTs der seriellen Schnittstelle und da sitzt > eben ein einfacher 28poliger 6850 dran Einmal darfst du raten, warum dir hier immer wieder eine Z80 SIO ans Herz gelegt wurde. Wer nicht hören will ... Wenn du eine PIO verbaut hast und da noch Pins frei sind: führe den INT des 6850 an die PIO und laß die PIO stellvertretend einen "richtigen" Interrupt auslösen. XL
Das Verheiraten von Z80 oder 8080 Bausteinen mit 68xx Bauteilen war ja früher schon fast so eine Sünde wie wenn ein Katholischer eine Evangelische (oder umgekehrt) geheiratet hat. Das Businterface beider Bausteinfamilien passt einfach schlecht zusammen.
Angehängte Dateien:
-
Grants_Z80.gif
100 KB
Axel Schwenke schrieb: > Einmal darfst du raten, warum dir hier immer wieder eine Z80 SIO ans > Herz gelegt wurde. Wer nicht hören will ... Sei mir nicht böse aber ich finde die SIO komplett unverständlich. Dagegen habe ich die vom LPC21xx noch ruck zuck kapiert und hatte auch schnell lauffähigen Code. Hasst du ne Ahnung wie das ist Routinen blind auszuprobieren wenn man "nichts sieht" weil kein Debugger da ist und eine nette printf(stdout,"Variable a =...%d",a) Funktion? Und das ist nicht nur meine Meinung denn die fand ich im Netz öfter, daher nimmt sie auch fast keiner, der ein Z80 System gebaut hat. Selbst der N8VM Rechner nimmt eine 8251 oder 16C550 Uart. http://www.izabella.me.uk/html/z80_sio_programming_hints.html The programming complexities of large scale integration components are usually directly proportional to the facilities and versatility of the device.In the case of the Z80SIO, it will probably take some time even for even the more experienced programmer to work out how to make it perform even the most rudimentary tasks. To the beginner at microprocessor programming, it is possible that the bewildering array of registers will cause a total confusion unless a logical approach is taken from the start. 6850 an PIO: Ok, die Idee hatte ich auch schon. Frage: Welcher INT Mode? 2 sicherlich denke ich mal. Und wohin springt die CPU, wenn der 6850 einen INT auslöst und keine Low Adresse auf dem Bus liegt? Ich erinnere mich schwach, dass auch M1 mit der SIO verdrahtet werden muss, hier im Plan verbindet er M1 mit dem CS0 des 6850.
Christian J. schrieb: > Ok, die Idee hatte ich auch schon. Frage: Welcher INT Mode? 2 sicherlich > denke ich mal. In dieser Schaltung IM1. IM0 und IM2 führen im IACK-Zyklus Code- bzw. Vektorzugriffe durch, die hier in den Wald laufen. > Und wohin springt die CPU, wenn der 6850 einen INT > auslöst und keine Low Adresse auf dem Bus liegt? Oeben. > Ich erinnere mich > schwach, dass auch M1 mit der SIO verdrahtet werden muss, hier im Plan > verbindet er M1 mit dem CS0 des 6850. Damit wird verhindert, dass der 6850 IACK-Zyklen als Zugriff auf seine Steuerregister interpretiert. In denen ist M1=0, CS0 muss aber 1 sein.
Christian J. schrieb: > nicht nur meine Meinung denn die fand ich im Netz öfter, daher nimmt sie > auch fast keiner, der ein Z80 System gebaut hat. Interessanter Ansatz. Ich kann ja verstehen, wenn jemand den 6850 verwendet, weil der weniger Pins braucht. Aber dass Leute ihn verwenden, weil sie vom Z80-SIO überfordert sind, das habe ich noch nicht erlebt. Jedenfalls sind mir Z80-SIOs oft begegnet, hab ihn auch selber schon verwendet, auch den neueren komplexeren Z8530 (an 68000). Z80 mit 6850 hingegen sah ich hier zum ersten Mal. Also das mit dem "fast keiner" ist eine reichlich gewagte Aussage. Meine Erfahrungen mit diesen Teilen stammen freilich aus der Zeit, als die aktuell waren. Für die heutige Retro-Generation mag sich das vielleicht anders darstellen. ;-) > nimmt eine 8251 oder 16C550 Uart. Als der 16C550 auf den Markt kam war die Z80 schon steinalt.
Helmut S. schrieb: > Das Verheiraten von Z80 oder 8080 Bausteinen mit 68xx Bauteilen war ja > früher schon fast so eine Sünde Ging auch nicht immer. Etliche 65xx/68xx Bausteine verwendeten E nicht nur als Strobe für den Buszyklus, sondern auch als Takt für diverse Timer. Abgeleitet aus RD/WR war das nicht eben hilfreich. Zudem passte das Timing einer 4MHz Z80 nicht zu den gebräuchlichen 1MHz 65xx/68xx Bausteinen.
Wenn Du Platz sparen möchtest, vielleicht gefällt Dir ja anstatt des 6850 ein SCC2691: 24-pol. schmales DIL-Gehäuse Und wenn Du noch viel Platz frei hast, ich hätte noch einen INS8154 :-)
Christian J. schrieb: > hier im Plan verbindet er M1 mit dem CS0 des 6850. Formal betrachtet ist 68xx Peripherie an Z80 nicht so einfach, wie hier in der Schaltung gezeigt. Denn beim 68B50 muss R/W mindestens 40ns for E anliegen. Das ist in dieser Schaltung mit E aus IORQ nicht gewährleistet. Und in einer anderen Variante, in der E aus RD+WR abgeleitet wird, natürlich ebenso wenig.
m.n. schrieb: > Wenn Du Platz sparen möchtest, vielleicht gefällt Dir ja anstatt des > 6850 ein SCC2691: 24-pol. schmales DIL-Gehäuse Wie wärs mit 18 Pins? Damit kommt der TMS9902 aus.
Warum nimmste nicht den NMI für deinen 6850 (ein 6551 hätte es ja schon sein können :-P )?
Christian J. schrieb: > Sei mir nicht böse aber ich finde die SIO komplett unverständlich. Erzähl mal noch einen vom Pferd, was soll an nur 8+3 Registern kompliziert sein. Die SIO braucht allerdings noch nen CTC für die Baudrate. Christian J. schrieb: > Hasst du ne Ahnung wie das ist Routinen blind > auszuprobieren wenn man "nichts sieht" Ach komm, ein SW-putchar ist ruckzuck mit nem PIO-Pin und Delay zusammen gebastelt.
Ich hatte mal einen Z80 vectored Interrupt-Controller mit einem CPLD ATF750 geschrieben. Er hat 8 Interrupteingänge und erzeugt eine 3-Bit Vektor, die restlichen 5 Bits macht man mit einem Tristate-Buffer. Die Eingänge können einzeln enabled werden. 2 Eingänge sind flankengetriggert und 6 levelgetriggert.
Hier stellt sich langsam nochmals die Sinnfrage dieses Projekts. Geht es um Bastelspass? Was für SW soll darauf laufen? Was sollen die I/O tun können? Irgendein Zusammenhang oder Erweiterbarkeit Richtung CP/M? Generell ist wenig zielführend, den DIP-40 Z80 mit artfremden Peripheriebausteinen aus anderen Herstellerfamilien verheiraten zu wollen. Das Resultat wird nur ein Gemenge an Inkompatibilität. CPU, PIO, SIO, CTC. Fehlt noch der Taktgenerator. Dann sind wir gleich beim TMPZ84C015 (ursprünglich Toshiba). Alles drin. Voll kompatibel. Cmos. Damit war auch meine letzte "Z80" Platine (ein Industriegerät, Serienprodukt) ausgestattet, Baujahr war irgendwann Anfang-Mitte 1990 Jahre. Mit Flashspeicher Amd29f010, mit 128 kByte Ram, MMU und weitere Spezialperipherie für die Anwendung. Fast alles Smd. Mit Bootloader über RS232, Applikationssoftware im Feld updatebar ohne Eprom-Wechsel (neu damals). Eine einfache Platine mit dem TMPZ84C015 ist als "Z80mini3" bekannt, siehe http://www.mct.net/product/z80mini3.html bzw. http://elmicro.com/de/z80mini3.html Gruss
Erich schrieb: > Hier stellt sich langsam nochmals die Sinnfrage dieses Projekts. > Geht es um Bastelspass? Was für SW soll darauf laufen? Was sollen die > I/O tun können? Irgendein Zusammenhang oder Erweiterbarkeit Richtung > CP/M? Wie in der Überschrift steht, handelt es sich um ein Retro-Fieber, dessen Verlauf schlecht vorherzusehen ist. Ich gehe allerdings davon aus, dass sich einige Viren so verzetteln, dass es zu einer Spontanheilung kommt. Sofern man selber nicht infiziert ist, kann man sich zurücklehnen und an die schönen, alten Zeiten denken, wo man die Bits noch in die Hand nehmen und auf Magnetband abspeichern konnte :-) Erich schrieb: > Dann sind wir gleich > beim TMPZ84C015 (ursprünglich Toshiba). Alles drin. Voll kompatibel. Da könnte man jetzt den 68000 ins Spiel bringen; falls ihn jemand braucht, den TMP68301 hätte ich noch im Angebot.
m.n. schrieb: > die schönen, alten Zeiten denken, wo man die Bits noch in die Hand > nehmen und auf Magnetband abspeichern konnte :-) Neumodischer Kram! Ich habe mit 5 Kanal Lochstreifen und einer Zuse angefangen. DAS waren noch Zeiten. > Da könnte man jetzt den 68000 ins Spiel bringen; falls ihn jemand > braucht, den TMP68301 hätte ich noch im Angebot. Ich biete einen National NSC600 "Scamp" mit Eprom 5204 (512 Bytes, Vorsicht, Programmierspannung 50V).
Georg G. schrieb: > Ich biete einen National NSC600 "Scamp" Für den ist doch der INS8154 doch (wie) geschaffen.
m.n. schrieb: > Für den ist doch der INS8154 doch (wie) geschaffen. Möchtest du einen haben? Liegt hier noch in der Restekiste. Auch RAMs mit 256*4 Organisation sind noch da.
Hallo, wie ich sehe drehe ich mich im Kreis, zumindest was meine Lösung angeht, bei der etwas mehr drauf sein soll als nur Minimal. Beim 8085 damals war das deutlich einfacher, ok da habe ich auch nur 80xx verwendet. Ich mag die Z80 SIO nicht, iel zu gross für das wenige was sie leisten soll. Woebi ich nach einmal drüber schlafen jetzt soweit bin, dass ich dem 6850 die INT Leitung abklemmen werde und etl Polling benutzen werde, da er sowieso nix zu tun hat solange er auf was wartet. Ziel soll einfach nur sein etwas damit zu spielen, vielleicht ein Basic Programm zu schreiben, eine 7-Segment Anzeige dran zu bauen, Teperazuren anzuzeigen usw. Mehr nicht. Und da ich mir den "Kult Z80" mal antun wollte versuche ich es eben. Nen Arduinoi ans Rennen zu kriegen ist zu langweilig, da funktioniert ja eben alles sofort.
Christian J. schrieb: > Arduinoi ans Rennen zu kriegen ist zu > langweilig, da funktioniert ja eben alles sofort. Wie meinen Euer Ehren? Letztlich mal hier im Forum gelesen? Mein Eindruck ist eher das Gegenteil. Das kann aber auch an der Zielgruppe liegen :-)
Georg G. schrieb: > Wie meinen Euer Ehren? Letztlich mal hier im Forum gelesen? Mein > Eindruck ist eher das Gegenteil. Das kann aber auch an der Zielgruppe > liegen :-) Wie man es sieht. Wenn man wie ich im Innenleben der IDE rumfummelt, neue CPUs einbindet und Libs ändert kann es schon kompliziert werden. Vor allem wenn man nicht weiss wie die IDE drin genau arbeitet. Denn diese setup-loop Konstruktion kommt ja nicht irgendwo her. Außerdem weren da Sachen eingebunden die man nicht sieht, die man aber bemekert wenn man den Weg verlässt nur die Standafunktionen zu benutzten, zb mal den Timer 0 mit Low Level Code ändert. Dann klappt ganz schnell nix mehr :-)
Christian J. schrieb: > Es ist zum Heulen! [..] > > Falls jemand einen Schaltplan hat, wo wirklich alles drauf ist immer her > damit! Da Du immer hinterher fragst brauchst du Dich über Deine Effekte nicht wundern, Du baust simpel Scheiß. Du bist derartig clever das Du wieder über Deine Füße stolperst. Wenn Du erst gefragt und dann kaufen gegangen wärest, hätte ich Dich auf dieses Ding aufmerksam gemacht: http://www.wfms.org/sb180/z180-prelim.pdf Das Ding ist schon lange nicht mehr preliminary, falls die Frage kommt, der Link auf das PDF war nur günstig. Ich habe so ein Teil hier als 25Mhz Version (IMHO) bei den spezifizierten 33Mhz dürfte sich Deine Aussage "AVR 10x schneller" auch in heißen Dunst auflösen. Im PLCC68 Gehäuse gut für Lochraster geeignet. Du aber kaufst lieber nicht passende Peripherie ICs und wunderst dic das Käse dabei raus kommt. Zum CTC: Hänge den Interrupt ausgang Deiner blöden Sio an CLK/TRG3 vom CTC, programmiere den CTC Kanal 3 als Counter mit der preloaded Value von 1, nach H-L auf CLK/TRG3 löst der Kanal dann einen Interrupt aus und der Kanal kann einen Interrupt mit Vector generieren. >Sei mir nicht böse aber ich finde die SIO komplett unverständlich. >Dagegen habe ich die vom LPC21xx noch ruck zuck kapiert und hatte auch >schnell lauffähigen Code. Ach? Christian bei "aller Liebe", das haben Tausende von Ossis schon vor Jahrzehnten kapiert... Es gibt Bücher mit fertigen Routinen in Assembler, ebi normaler Async Kommunikation ist die SIO doch easy. Ok, die meisten Uarts in den MCUs heute sind primitiver da der ganze SDLC/HDLC Kram einfach nicht enthalten ist. Diese Version gibts aucher auch als Z80-DART. Gruß, Holm
Angehängte Dateien:
-
DSC08127__1280_x_1024_.jpg
210 KB
Aber zum Vergleich mal die beiden Bastelprojekte: Links die Z80 Sache, rechts ein Arduino System mit Atmega. Glaubt jemand im Ernst er könnte eine grafische Anzeige auf dem Z80 für das Nokia 5110 in nur einem halben Tag mit Verdrahtung ans Laufen kriegen? Er würde sich die Füsse brechen die PIO zu programmieren, dann noch das Datenblatt des 5110 studieren müssen für den Treiber, dann noch Grafikfunktionen programmieren usw. usw. Früher waren Ingenieure die "Masters of Computer", heute machen das 14-jährige im Workshop an der Schule ...
Holm Tiffe schrieb: > Da Du immer hinterher fragst brauchst du Dich über Deine Effekte nicht > wundern, Du baust simpel Scheiß. Du bist derartig clever das Du wieder > über Deine Füße stolperst. > > Wenn Du erst gefragt und dann kaufen gegangen wärest, hätte ich Dich auf > dieses Ding aufmerksam gemacht: > > http://www.wfms.org/sb180/z180-prelim.pdf Also Holm....... ich frage nach einem Käfer und du kommst mit einem Panzer daher, für den es NICHTS irgendwo gibt. Google mal nach dieser CPU, die wird wohl nur in irgendwelchen Aktenschänken ihr Dasein vergammeln. Ich hoffe dieser thread wird einigen,die ähnlihes vorhaben bewusst mache vor welche Hürden man gestellt wird, wenn man alte Technik wieder beleben will. Und diese Vergewaltigung der CTC werde ich nicht machen ..... baue jetzt die SIO rein, dahinter einen USB Konverter, der ausnahmsweise auch RTC/CTS hat und fertig.
Christian J. schrieb: > Er würde sich die Füsse > brechen die PIO zu programmieren, dann noch das Datenblatt des 5110 > studieren müssen für den Treiber, dann noch Grafikfunktionen > programmieren usw. usw. Das ist aber dann nicht die Schuld des PIO, sondern desjenigen, der unbedingt in Assembler programmieren will. Nimm einfach nen Z80 C-Compiler und kopiere irgendeinen C-Treiber für das GLCD in Deinen Editor. Dann ersetze alle IO-Zugriffe auf das GLCD durch Aufrufe der PIO-Ausgabefunktion (falls die IO-Zugriffe nicht eh schon als Funktion gekapselt sind). Dann schreibe die PIO_Init und die PIO_Out Funktion (dauert ~5min) und fertig.
Christian J. schrieb: > Also Holm....... ich frage nach einem Käfer und du kommst mit einem > Panzer daher, für den es NICHTS irgendwo gibt. Google mal nach dieser > CPU, die wird wohl nur in irgendwelchen Aktenschänken ihr Dasein > vergammeln. Gleich Nebenan könntest Du Dich vom Gegenteil überzeugen. Beitrag "Z180-Stamp Modul"
Holm Tiffe schrieb: > Das Ding ist schon lange nicht mehr preliminary, falls die Frage kommt, > der Link auf das PDF war nur günstig. Datenblätter von Zilog sind fast immer preliminary.
Angehängte Dateien:
-
Z180.jpg
80 KB -
Z180_old.jpg
51 KB
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 :-)
Christian J. schrieb: [..] > > Also Holm....... ich frage nach einem Käfer und du kommst mit einem > Panzer daher, für den es NICHTS irgendwo gibt. Huh? Das Ding ist kein Panzer sondern ein Z180, HD64180.. > Google mal nach dieser > CPU, die wird wohl nur in irgendwelchen Aktenschänken ihr Dasein > vergammeln. Ich hoffe dieser thread wird einigen,die ähnlihes vorhaben > bewusst mache vor welche Hürden man gestellt wird, wenn man alte Technik > wieder beleben will. OMG. Christian ich schreibe kein aus den Fingern gesogenes Zeuch, ich weiß von was ich rede, Du wieder nicht. Ich empfehle Dir durchaus mal nach Z180 zu googeln, Beispiele gibts einige aber da die CPU einen Z80 Kern hat.. was soll es da für Beispiele nicht geben? Du vergleichst die Z80 mit heutigen ICs, die Z180 ist schon uralt aber offensichtlich bestehst Du auf unfairen Vergleichen? Und wieder schreibst Du ohne zu wissen... > > Und diese Vergewaltigung der CTC werde ich nicht machen ..... baue jetzt > die SIO rein, dahinter einen USB Konverter, der ausnahmsweise auch > RTC/CTS hat und fertig. Vergewaltigung? Das ist ein ganz normaler Betriebsmodus, bekannt seit Jahrzehnten und eine der hinlänglich bekannten und verwendeten Möglichkeiten einen systemfremden IC in die Interruptkette eine Z80 zu integrieren, genauso wie die mit PIO. Was soll der Käse mit dem Arduino? Du bekommst auch in einem halben Tag kein Atmel system mir grafischer Anzeige zum Laufen wenn Du alles zu Fuß programmieren mußt. Das man für den Z80, Z180 etc. bekannte und vorhandene Softwarebibliotheken nutzen kann, hältst Du offensichtlich auch für unwahrscheinlich. Ich frage mich nur warum? Wahrscheinlich deshalb, weil Du diese Dinge nicht kennst und deshalb hier behauptest das sie nicht existieren. Du hantierst wie selbstverständlich mit einem halbwegs modernen Atmel Prozessor, möchtest aber nicht mit einem halbwegs aktuellen Z80 vergleichen (und du kommst mit einem Panzer daher). Warum nicht? Weil Du dann nicht Recht hast? Was soll das? Von dem Verlinkten Datenblatt hast Du nichts gelesen sonst wüßtest Du das das ein Z80 Kern mir geringfügigen Erweiterungen, einer MMU und Peripherie ist, ohne ROM. Diese CPU ist älter als ein Atmel. Andere Hinweise über moderne Zilog Chips hattest Du auch schon erhalten, alles in den Wind geschlagen weil Du es besser weist. Wenn Du denkst das Du über einen ARM oder AVR mehr weist als ich hast Du wahrscheinlich auch Unrecht. Ich verdiene meine Brötchen mit solchen Sachen. Um Arduinos habe ich mich allerdings kaum gekümmert, ich Programmiere i.A. in C und Assembler. Ich empfehle Dir dringend Dich eingehend zu informieren bevor Du urteilst. Du manövrierst Dich sonst in Teufels Küche. Gruß, Holm
Christian J. schrieb: > die wird wohl nur in irgendwelchen Aktenschänken ihr Dasein > vergammeln. Auch die Originale von anno Dunnemal gibts noch, in PLCC68 und DIP64S beispielsweise bei http://www.kessler-electronic.de/Halbleiter/integrierte_Schaltkreise/Mikrocontroller/Zilog_Z80_c245.htm
Axel Schwenke schrieb: [..] >> Schau' dich mal bei den kleinen PICs um, die können das wohl. > > Bäh. PICs (vor allem die kleinen) sind doof und riechen nach Lulu. Oder > anders gesagt: vom Regen in die Traufe. Dann nehme ich doch wirklich > lieber ein separates Latch in Hardware. > > > XL :-) Sehe ich auch so. Ich mach PIC wenn es der Auftraggeber unbedingt möchte, aber eher nicht freiwillig. Ok, die neueren sollen ja besser sein und über die MIPS Architektur zanke ich auch nicht.. Gruß, Holm
Holm Tiffe schrieb: > Sehe ich auch so. Ich mach PIC wenn es der Auftraggeber unbedingt > möchte, > aber eher nicht freiwillig. Ok, die neueren sollen ja besser sein und > über die MIPS Architektur zanke ich auch nicht.. Die 16 Bitter sind auch ganz angenehm. fchk
Meine letzte Erfahrung da war mit einem 16F577 (?) in Assembler, mir ging da das Banking auf den Wecker. Für irgend ein Peripherieding (keine Ahnung mehr ob Timer oder was das war) gab es die Hälfte der Konfiguration in der einen, den Rest in der anderen Bank. Sowas bin ich nicht gewöhnt und finde das schräg.. Gruß, Holm
Holm Tiffe schrieb: > Meine letzte Erfahrung da war mit einem 16F577 (?) in Assembler, mir > ging da das Banking auf den Wecker. Für irgend ein Peripherieding (keine > Ahnung mehr ob Timer oder was das war) gab es die Hälfte der > Konfiguration in der einen, den Rest in der anderen Bank. Sowas bin ich > nicht gewöhnt und finde das schräg.. Das war wohl eher ein PIC16F677. Bei den PIC18F muss man nicht mehr banken, kann aber, wenn man 16'er Code portieren will, und die 16-Bitter (dsPIC, PIC24) und 32 Bitter (PIC32) brauchen das ohnehin nicht mehr. fchk
Axel Schwenke schrieb: >> Schau' dich mal bei den kleinen PICs um, die können das wohl. > > Bäh. PICs (vor allem die kleinen) sind doof und riechen nach Lulu. Ach Axel, dem Rest der Welt ist es klar, daß ein begeisterter Atmel-Fan wie du keine Gelegenheit ausläßt, die PIC's zu schmähen. Daß du mentale Probleme mit deren Architektur hast, ist dein Problem. Aber die PIC's (vor allem die kleinen) sind eben gar nicht so doof, sondern es haben davon einige genau diese Ports, mit denen man sie als periphere IC's in größere Systeme einbinden kann. Im Prinzip sind das alle, die einen PortD (für 8 Bit Daten I/O) und PortE (für die Steuersignale) haben, PIC16F87x wenn ich mich recht erinnere. Damit können diese Teile direkt an einen Systembus angeschlossen werden. Versuche mal sowas bei anderen µC zu finden. So, dieser Thread ist zwar ganz interessant, aber auch ziemlich gespenstisch. Nostalgie scheint in zu sein. Ich hätte da jedoch ganz andere Vorschläge, nämlich den beklagenswerten Wissensstand der Jüngeren zu aktueller Hardware zu verbessern, indem man sich um den Aufbau von Rechner- oder Controller-Architekturen - nun ja von benutzbarer Hardware mit aktuellen Bauteilen kümmert. Also kein Board mit nem Z80 und CP/M drauf, sondern z.B. eines mit nem Cortex M4 drauf, WVGA TFT Display dran, Tastatur und Maus und Drehgeber und Tipptasten und mit nem CODEC und so weiter und mit nem Monitorprogramm drauf, das von SD-Karte Apps laden und ausführen kann. Aber das Ganze mit leicht verständlichem Quellcode, so daß Neulinge sich dort abgucken können, wie man dies und das so macht. Kurzum so etwas Ähnliches wie eine drastisch modernisierte Art Lernbetty. Sowas hätte einen echten Sinn, nämlich den Sinn der Bildung unseres Nachwuchses. Und es würde auch sowas wie Spaß machen. Also! W.S.
W.S. schrieb: > So, dieser Thread ist zwar ganz interessant, aber auch ziemlich > gespenstisch. Nostalgie scheint in zu sein. Was am Titel "Retro Fieber" hast du grad nicht verstanden? > sondern z.B. eines mit nem Cortex M4 drauf Als Empfehlung für "Retro" etwas befremdlich. Oder ist bei dir alles, was älter als eine Woche ist, schon Retro?
W.S. schrieb: > Sowas hätte einen echten Sinn, nämlich den Sinn der Bildung unseres > Nachwuchses. Und es würde auch sowas wie Spaß machen. Na, solche Boards sehen aber sehr gruelig aus, wenn man "from scratch" loslegen will, d.h. mit einer leeren Editorseite. Außerdem habe ich gerade wieder die Erfarung gemacht, dass die "Cracks" es gar nicht wollen, dass "Expertenwissen" das der breiten Masse wird. Wo kämen wir denn da hin, wenn alles nicht "hochkopliziert" wäre, so dass es jeder versteht? Dann wären die Herren Experde ja überflüssig. Lach nicht, deswegen hatte ich eine handfeste Auseindanersetzung mit einem Ex Kollegen. Da ich im selbst verfallen bin ist der Raspeberry Pi das beste Lerngerät, wobei allerdings wohl keiner sein Innenleben vesteht, denn wer kann schon Treibr für eine GBU schreiben? Solche System sind ohne abstrahierte Hardware witzlos. Ach ja, um Holm noch eines vor den Latz zu geben.... PICs hatten schon immer Banking und seit ca 1996 benutzt mana auch C Compiler :-) Ich habe seit 1997 mit PICs gearbeitet, abertausende Zeilen Code, viele Dutzend Designs für die Industrie gemacht, ohne jemals auch nur eine einzige Zeile Asm geschrieben zu haben :-) Nie, nie! Bäh, das ist bei PICs ja wie das Gestammel eines Kleinkindes, dieser RISC Asm. Mit 35 Wörtern die Welt erklären zu wollen. Und es wurden tausende Geräte verkauft .... also so viel Retro muss es nicht sein. AVR hat mich nie interessiert, einfach weil alle es machten. Die PICS können alles was ein AVR auch kann und was sie mehr können braucht man eh nicht.
Christian J. schrieb: > gerade wieder die Erfarung gemacht, dass die "Cracks" es gar nicht > wollen, dass "Expertenwissen" das der breiten Masse wird. Weil du etwas Kritik angesichts deiner Aussage bezogen hast, dass der Z80 SIO für die breite Masse viel zu komplex sei? Wenn das alles ist - Code für SIO mit Interrupt anbei, entstanden in den 80ern. Der "STI" Kram gehört nicht zum SIO.
W.S. schrieb: > Also kein Board mit nem Z80 und CP/M drauf, sondern z.B. eines mit nem > Cortex M4 drauf, WVGA TFT Display dran, Tastatur und Maus und Drehgeber > und Tipptasten und mit nem CODEC und so weiter und mit nem > Monitorprogramm drauf, das von SD-Karte Apps laden und ausführen kann. Grundlagenwissen vermittelst du der beklagenswerten Jugend m.E. besser mit einem Z80-System als mit den komplexen, aktuellen Controllern. Während beim Z80 die einzelnen Bausteine wie CPU, Busse, Decodierer, RAM, ROM, Timer, SIO, PIO usw., sowie deren Verbindung umtereinander noch mit bloßem Auge sichtbar und quasi "zum Anfassen" sind, verschwindet dies alles bei den µCs unter einem schwarzen Klecks. Wenn man die einzelnen Leitungen der Busse noch zusätzlich mit LEDs illuminiert und die Taktrate auf fürs menschliche Auge nachvollziehbare Frequenzen runterschraubt, kann der wißbegierige IT-Jünger den Bits sogar bei der Arbeit zuschauen. Ein Z80 ist wie der Lanz Bulldog, bei dem es weder Steuergeräte noch Turbolader oder ABS gibt. Nur nackte, primitive aber nachvollziehbare Technik.
IMHO muss man beim Lernen noch weiter zurück gehen. Anfangen bei gattern, weiter zu flipflops, Zählern, Registern. parallel programmieren am pc. Erst dann mit Prozessoren und controllern...
Harald schrieb: > IMHO muss man beim Lernen noch weiter zurück gehen. Anfangen bei > gattern, weiter zu flipflops, Zählern, Registern. parallel programmieren > am pc. Erst dann mit Prozessoren und controllern... Nein.... in vielleicht 30,50 Jahren wird unsere Technik so komplex sein, wie die auf dem Raumschiff Enterprise. Displays in 3D aus Glas, Computer die dir zuhören, Computer die Teile von sich selbst neu konfigurieren können (gibt es ja teilweise schon) usw, usw. Die Elementartechnik wird ganz und völlig in Bausteinen oder Libraries verschwinden. Du kannst nicht immer weiter hinauf wollen und alles was unten ist noch wissen oder verstehen wollen. Ich habe an der Uni noch Karnogh Diagramme gehabt, Minterm, Maxterm und aus deren Lösungen Gatterlogiken gemacht. Ist längst aus dem Lehrstoff verschwunden. Mein Sohn geht mit einem Smrtphone und Computer wie selbstverständlich um mit seinen 10 Jahren aber er hat keine Ahnung wie er fnktioniert. Und es interessiere ihn auch nicht sagte er, "hauptsache es funktioniert".
Christian J. schrieb: > in vielleicht 30,50 Jahren wird unsere Technik so komplex sein, > wie die auf dem Raumschiff Enterprise. Displays in 3D aus Glas, Computer > die dir zuhören, Computer die Teile von sich selbst neu konfigurieren > können (gibt es ja teilweise schon) usw, usw. Hmm, das führt irgendwann dorthin: http://de.wikipedia.org/wiki/Technologische_Singularit%C3%A4t Der Mensch wird dann allerdings überflüssig, weil er die Entwicklung nur hemmt.
Christian J. schrieb: > W.S. schrieb: > > Ach ja, um Holm noch eines vor den Latz zu geben.... PICs hatten schon > immer Banking und seit ca 1996 benutzt mana auch C Compiler :-) Ich habe Mach doch. Ich schrieb das ich kein Problem mit den Dingern habe wenn ich mit den Dingern arbeiten muß. Ich komme nur nicht selbst auf die Idee mir die Rübe so zu verkorksen das ich auf steinalte GI Architekturen abfahren muß. Wenn Du Dir die Rute über den Arsch ziehen willst, bitteschön. Auch andere Mütter haben schöne Töchter, mich zieht es da eher in die Ecke Coldfire und Konsorten oder aber MSP430. Das nur um Dir eine vor Deinen Latz zurück zu geben. Gruß, HOlm
Christian J. schrieb: > Mein Sohn geht mit einem Smrtphone und Computer wie selbstverständlich > um mit seinen 10 Jahren aber er hat keine Ahnung wie er fnktioniert. Und > es interessiere ihn auch nicht sagte er, "hauptsache es funktioniert". Ja, diese Sorte Nachwuchs kenne ich, sinngemäss: "Papi, kannst du mal vorbei kommen (halb Deutschland liegt dazwischen). Der Handtuchhalter bleibt nicht an der Wand hängen. Im Computerspiel tut er das immer."
A. K. schrieb: > Christian J. schrieb: >> gerade wieder die Erfarung gemacht, dass die "Cracks" es gar nicht >> wollen, dass "Expertenwissen" das der breiten Masse wird. > > Weil du etwas Kritik angesichts deiner Aussage bezogen hast, dass der > Z80 SIO für die breite Masse viel zu komplex sei? Wenn das alles ist - > Code für SIO mit Interrupt anbei, entstanden in den 80ern. Der "STI" > Kram gehört nicht zum SIO. Was ist denn das für ein Code? Leider ist der Source wenig kommentert, so dass man zb nicht weiss welche Register bei welcher Routine mit was gefüllt sein müssen und welche Ausgabe eine Routine erzeugt. Ist das eine Makrosprache des Assemblers? /* start output sequence */ begseq:: { @imra = @imra & ~0x10; /* keyboard int off */ } /* end output sequence */ endseq:: { @imra = @imra | 0x10; /* keyboard int on */ if (xreq) { /* xoff request pending */ putnw (A=xreq;); xreq = 0; } }
Christian J. schrieb: > Ist das eine Makrosprache des Assemblers? Nö. Trivialcompiler Marke Eigenbau. Besseres Beispiel anbei - .PLZ der Quellcode, .s der resultierende Assemblercode. War auch nicht für 1:1 Übernahme gedacht. Sondern um zu zeigen, dass der Umgang damit kein Hexenwerk ist.
Hallo Grundlagen schaden aber nicht. Die Mathematik bis zum ABI ist auch schon "uralt". Mir hilft es jedenfalls mit dem Wissen aus 6502, Z80 und 68k Zeiten aktuelle System zu programmieren.
Christian J. schrieb: > Nein.... in vielleicht 30,50 Jahren wird unsere Technik so komplex sein, > wie die auf dem Raumschiff Enterprise. Displays in 3D aus Glas, Computer > die dir zuhören, Computer die Teile von sich selbst neu konfigurieren > können (gibt es ja teilweise schon) usw, usw. Die Elementartechnik wird > ganz und völlig in Bausteinen oder Libraries verschwinden. Du kannst > nicht immer weiter hinauf wollen und alles was unten ist noch wissen > oder verstehen wollen. Ich habe an der Uni noch Karnogh Diagramme > gehabt, Minterm, Maxterm und aus deren Lösungen Gatterlogiken gemacht. > Ist längst aus dem Lehrstoff verschwunden. Naja, ich stelle nur immer wieder - gerade hier im Forum - fest, dass gerade bei den Hobbyanwendern, wo auch ich mich dazuzähle, ein extremer Mangel an Grundwissen herrscht. Das Problem ist IMHO nur das, dass euch, die beruflich in dieser Branche unterwegs seid, die Grundlagen so vertraut und in Fleisch und Blut über gegangen sind, dass euch gar nicht auffällt, dass die teilweise blöden Fragen daher rühren. Ich arbeite zwar in einer ganz anderen Branche, aber mir fällt das genauso auf. Die Grundlagen sind halt jedem in seinem Fachgebeit selbtverständlich. Btw wenn die Programmierung von Controllern soweit abstrahiert wird, dass es jeder kann; wozu braucht man dann euch Spezialisten noch? Was die Studienpläne betrifft: wer sagt, dass das so sinnvoll ist. Auswirkungen der aktuellen Lehrpläne werden sich erst zeigen. > Mein Sohn geht mit einem Smrtphone und Computer wie selbstverständlich > um mit seinen 10 Jahren aber er hat keine Ahnung wie er fnktioniert. Und > es interessiere ihn auch nicht sagte er, "hauptsache es funktioniert". Das hat mit der Programmierung von Controllern etc. nun so gar nichts zu tun, sondern ist ein gesellschaftlicher Fakt. Anwenden ist nicht gleich Implementieren. Ich wollte den Thread zwar nicht OT führen, aber andererseits ist's eh schon egal, wenn man hier mitliest...
Icke ®. schrieb: > Christian J. schrieb: >> in vielleicht 30,50 Jahren wird unsere Technik so komplex sein, >> wie die auf dem Raumschiff Enterprise. Displays in 3D aus Glas, Computer >> die dir zuhören, Computer die Teile von sich selbst neu konfigurieren >> können (gibt es ja teilweise schon) usw, usw. > > Hmm, das führt irgendwann dorthin: > > http://de.wikipedia.org/wiki/Technologische_Singularit%C3%A4t > > Der Mensch wird dann allerdings überflüssig, weil er die Entwicklung nur > hemmt. Wenn du dir mal den genialen Jules Verne durchgelesen hast, der um 1828 geboren wurde, da liest du wie er viele Dinge bereits vorausah, die heute Normal sind. Noch sind wir nicht soweit, dass ein Haufen Silizium diese 2kg graue Pampe ersetzen kann, die als Analogcomputer hinter meiner Brille arbeitet. Im Übrigen wird diese Thematik auch in einigen Filmen erwähnt, zb "Flucht ins 21.te Jahrhundert", oder "Die Zeitmaschine" wo die "Söhne und Töchter" nicht mehr das Wissen besassen was ihre Väter geschaffen hatten, um die Maschinen und alles andere in Gang zu halten. Aber das hat jetzt nichts mit dem Z80 zu tun...
A. K. schrieb: > Nö. Trivialcompiler Marke Eigenbau. Sorry, übersteigt meine Fähigkeiten einen "Trivialcompiler" zu schreiben. Bin ich zu blöde für. Anbei mal der Quelltext eines Virus, den ich 1995 geschrieben habe, sieht irgendwie "anders" aus, mein Asm-Stil.
Harald Nagy schrieb: > Btw wenn die Programmierung von Controllern soweit abstrahiert wird, > dass es jeder kann; wozu braucht man dann euch Spezialisten noch? Diese Abstrahierung wird auf allen Fronten aber voran getrieben! Du sollst schnell Erfolg haben, auf bewährtes aufsetzen können und nicht das Rad ewig neu erfinden müssen. Nehmen wir die A20 CPU, die einen ARM Core hat so merke ich, je länger ich mich damit befasse, dass es UNMÖGLICH ist für eine Einzelperson diese CPU , besser "system on chip" zu verstehen, gschweige denn da noch Asm zu programmieren. Du würdest jahre brauchen überhaupt einen Grundstock zu haben. Erst mit Linux drauf wird sie zu einem nutzbaren System.
Christian J. schrieb: > Sorry, übersteigt meine Fähigkeiten einen "Trivialcompiler" zu > schreiben. Bin ich zu blöde für. Kein Drama. Rund 2400 Zeilen, die Hälfte davon Yacc.
A. K. schrieb: > Christian J. schrieb: >> Sorry, übersteigt meine Fähigkeiten einen "Trivialcompiler" zu >> schreiben. Bin ich zu blöde für. > > Kein Drama. Rund 2400 Zeilen, die Hälfte davon Yacc. Ok, ok. Ich erinnere mich schwach an Begriffe wie Keller-Automat, verkettete Bäume für die Strukuren, Parser usw. usw. Aber das sei denen vorbehalten die Informatik studiert haben, denen jeden Abend der Kopf explodiert und nicht jenen, die sie anwenden wollen :-)
Christian J. schrieb: > und nicht jenen, die sie anwenden wollen :-) Eben. Den Automaten des Parsers erzeugte Yacc. Ich war bloss der Anwender von Yacc, indem ich die Parser-Spezifikation schrieb (sowas wie BNF) und mit dem resultierenden Z80-Code verzierte. Das Ergebnis erreichte die Effizienz von Assembler, war aber viel besser lesbar. Einen Small C Compiler für 8080 (Z80?) gab es damals zwar wohl schon, aber dessen Ergebnis war schaurig.
A. K. schrieb: > Christian J. schrieb: >> und nicht jenen, die sie anwenden wollen :-) > > Eben. Den Automaten erzeugt Yacc. Ich war bloss dessen Anwender, indem > ich die Spezifikation für Yacc schrieb (sowas wie BNF). Das Ergebnis > erreichte die Effizienz von Assembler, war aber viel besser lesbar. Darf ich das so verstehen, dass du nur die Syntax definierst und Yacc erzeugt das für dich? Ich bin da Laie aber ein "LDA A,$05" für den 6502, Lade Accu mit 0x05 muss ja übersetzt werden in A0 09 05, wobei die 09 nur für die direkte Adressierung steht, es aber noch einie andere wie indirekt, indiziert indirekt, zeropage usw gibt. Wie bringt man diese Regeln Yacc bei.
Christian J. schrieb: > Darf ich das so verstehen, dass du nur die Syntax definierst und Yacc > erzeugt das für dich? Ich bin da Laie aber So ungefähr. Siehe Anhang.
A. K. schrieb: > Christian J. schrieb: >> Darf ich das so verstehen, dass du nur die Syntax definierst und Yacc >> erzeugt das für dich? Ich bin da Laie aber > > So ungefähr. Siehe Anhang. Ok, andere Welt ... verstehe nicht eine Zeile davon. Ist aber hier verständlich beschrieben: http://www.eike-meinders.de/Yacc
Christian J. schrieb: > Woebi ich nach einmal drüber schlafen jetzt soweit bin, dass ich > dem 6850 die INT Leitung abklemmen werde und etl Polling benutzen werde, > da er sowieso nix zu tun hat solange er auf was wartet. Und nochmal meine Frage: Matthias Sch. schrieb: > Warum nimmste nicht den NMI für deinen 6850?
Matthias Sch. schrieb: > Christian J. schrieb: >> Woebi ich nach einmal drüber schlafen jetzt soweit bin, dass ich >> dem 6850 die INT Leitung abklemmen werde und etl Polling benutzen werde, >> da er sowieso nix zu tun hat solange er auf was wartet. > > Und nochmal meine Frage: > > Matthias Sch. schrieb: >> Warum nimmste nicht den NMI für deinen 6850? ..und warum besorgst Du erst einen TTL zu USB serial Wandler mit RTS/CTS wenn Du die signale gar nicht brauchst? Gruß, Holm
Matthias Sch. schrieb: > Christian J. schrieb: >> Woebi ich nach einmal drüber schlafen jetzt soweit bin, dass ich >> dem 6850 die INT Leitung abklemmen werde und etl Polling benutzen werde, >> da er sowieso nix zu tun hat solange er auf was wartet. > > Und nochmal meine Frage: > > Matthias Sch. schrieb: >> Warum nimmste nicht den NMI für deinen 6850? Handbuch: NMI. Nonmaskable Interrupt (input, negative edge-triggered). NMI contains a higher priority than INT. NMI is always recognized at the end of the current instruction, independent of the status of the interrupt enable flip-flop, and automatically forces the CPU to restart at location 0066h. The Z80 CPU contains two interrupt inputs: a software maskable interrupt (INT) and a nonmaskable interrupt (NMI). The nonmaskable interrupt cannot be disabled by the programmer and is accepted when a peripheral device requests it. This interrupt is generally reserved for important functions that can be enabled or disabled selectively by the programmer. This routine allows the programmer to disable the interrupt during periods when the program contains timing constraints that wont allow interrupt. In the Z80 CPU, there is an interrupt enable flip-flop (IFF) that is set or reset by the programmer using the Enable Interrupt (EI) and Disable Interrupt (DI) instructions. When the IFF is reset, an interrupt cannot be accepted by the CPU. ## ----------------- Moin, Da noch nix läuft kann ich auch noch nichts ausprobieren. Der NMI ist nicht maskierbar, d.h. er kann mir dazwischen hauen, wenn ein anderer Interrupt aktiv ist, zb einer der Timer oder der PIO (ja, ich nutze sie doch :) und ganz schlimm auch dann wenn ich grad in einem solchen INT die Register noch nicht auf dem Stack habe. Ich erinnere mich schwach, dass ein EI in einer INT Routine vorne böse Folgen haben kann, zb kann er sich bei pegel getriggerten INT (was der INT zu sein scheint) dann rekursiv aufhängen. Fragen: 1. Legt der Z80 die Retrun Adresse dabei auf dem Stack ab, so dass er zurückkehren kann? Mir liest sich das so als wenn das wie ein Warmstart Reset wäre "restart", d h. er springt nach 0x0066 und macht da einfach weiter. 2. Beherrscht die CPU nested interrupts, wenn ich die Register im NMI IRQ auf dem Stack rette wenn er grad aus einem 0038+x Timer INT ausgerissen wird? 3. Hier ist doch ein Widerspruch drin: "The nonmaskable interrupt cannot be disabled by the programmer and is accepted when a peripheral device requests it. This interrupt is generally reserved for important functions that can be enabled or disabled selectively by the programmer." Also, nun enabled oder disabled? Ich gebe zu dass dieses Handbuch teilweise etwas verwirrend geschrieben ist, auch die Bedeutung der beiden Flags IFF1 und IFF2 ist mir nicht ganz klar. Diese sind nicht im Status Register, sondern werden durch Befehle gesetzt und gelöscht. @Holm: Weil ich sie dann habe wenn ich sie brauche und wenn nicht, dann benutze ich sie nicht. Ganz einfach, oder? An 2,95 Euro soll es nicht scheitern. An USB Konvertern sind solche Leitungen ja sonst "out of date".
Angehängte Dateien:
-
NMI-IM0.jpg
100 KB
Die Bilder stammen aus Kieser/Meder[1]. Ich könnte mir vorstellen, daß das Buch für Dich etwas wäre. Gerade habe ich gesehen, daß auch die SIO darin ausfürhlich erklärt ist. > 3. Hier ist doch ein Widerspruch drin: Der NMI kann durch den Programmierer nicht disabled werden, die Funktionen aber schon. Kein Widerspruch. [1] http://www.zvab.com/advancedSearch.do?title=Mikroprozessortechnik+%3A+Aufbau+u&author=Kieser
Leo C. schrieb: > Die Bilder stammen aus Kieser/Meder[1]. Ich könnte mir vorstellen, daß > das Buch für Dich etwas wäre. Das Buch ist wirklich gut. Sehr ausführlich und verständlich geschrieben. Ich habe seinerzeit allein damit den Einstieg in die Mikroprozessorwelt geschafft, obwohl ich keinerlei Vorkenntnisse besaß.
Leo C. schrieb: > Der NMI kann durch den Programmierer nicht disabled werden, die > Funktionen aber schon. Kein Widerspruch. Das Buch ist ja super, gesehen hatte ich es schon bei amazon. Ich habe aber den Zaks bestellt. Habe einige DDR Mathe und Technik Bücher, weil die vor allem in Deutsch geschrieben sind. Die Funktionen? Also es kann nicht verhindert werden, dass 66 angesprungen wird, richtig? Was sind denn die Funktionen des NMI? Natürlich kann ich eine ISR sperren per Softfware, so dass sie gleich wieder verlassen wird.
Schaut Euch mal das Kiwi-Projekt von Simon Ferber an: https://www.ist-schlau.de/ Ein ziemlich beeindruckender Selbstaucomputer auf 68K-Basis. Er hat das in relativ kurzer Zeit beeindruckend weit gebracht, finde ich.
> Da noch nix läuft kann ich auch noch nichts ausprobieren. Der NMI ist > nicht maskierbar, d.h. er kann mir dazwischen hauen, wenn ein anderer > Interrupt aktiv ist, zb einer der Timer oder der PIO (ja, ich nutze sie > doch :) und ganz schlimm auch dann wenn ich grad in einem solchen INT > die Register noch nicht auf dem Stack habe. Wo ist das Problem? Vor und nach dem NMI sind die Register doch gleich. Du hast eine maximale Rekursionstiefe von 3 (Anwendung, Interrupt, NMI), für die du ausreichend Stack bereitstellen musst. Und für die Interrupts wurde der zweite Registersatz mal definiert. > 1. Legt der Z80 die Retrun Adresse dabei auf dem Stack ab, so dass er > zurückkehren kann? Ja, denn sonst könntest du nie aus einem Interrupt oder NMI zurückkehren. > 2. Beherrscht die CPU nested interrupts, wenn ich die Register im NMI > IRQ auf dem Stack rette wenn er grad aus einem 0038+x Timer INT > ausgerissen wird? Wenn du in einer ISR "EI" ausführst, dann kannst du auch Interrupts verschachteln. Ein NMI wird aber normalerweise nicht (bzw. nur durch einen NMI) unterbrochen.
1 | void nmi(void) __interrupt __critical |
2 | {
|
3 | static char flag_nmi = 0; |
4 | if(flag_nmi) return; |
5 | |
6 | flag_nmi = 1; |
7 | /* hier der Code */
|
8 | flag_nmi = 0; |
9 | return; |
10 | }
|
> 3. Hier ist doch ein Widerspruch drin: > > "The nonmaskable interrupt cannot be disabled by the programmer and is > accepted when a peripheral device requests it. This interrupt is > generally reserved for important functions that can be enabled or > disabled selectively by the programmer." "Dieser Interrupt wird normalerweise für wichtige Funktionen reserviert, die vom Programmierer gezielt ein- oder ausgeschaltet werden können." Nicht für andere Funktionen. ;-) > Also, nun enabled oder disabled? Ich gebe zu dass dieses Handbuch > teilweise etwas verwirrend geschrieben ist, auch die Bedeutung der > beiden Flags IFF1 und IFF2 ist mir nicht ganz klar. > Diese sind nicht im Status Register, sondern werden durch Befehle > gesetzt und gelöscht. Diese Flags speichern den Zustand des I-Flags, wenn ein NMI eintritt. Ohne NMIs sind IFF1 und IFF2 immer gleich, und mehr kannst du mit den Befehlen auch nicht beeinflussen.
Christian J. schrieb: > Was sind denn die Funktionen des NMI? Nun, es wird 0066h angesprungen, wenn der NMI low wird - mehr passiert erstmal nicht. Am besten fragst du dann gleich ACIA im 6850 ab, löschst die IRQ Anforderung und behandelst dann dein Ereignis. Du musst natürlich nur die Register retten, die deine Routine zermanschen würde. Du könntest auch eine kleine Hardware (Steckbrücke) vorsehen, damit du den NMI aussperren kannst. Die Funktion des NMI (und so ist der Zilog Satz vermutlich zu verstehen) werden normalerweise eben für SingleStep, Breakpoints usw. verwendet, das ist aber kein Zwang und der NMI ist ein ganz normaler IRQ mit hoher Priorität. Solange du im 6850 keine IRQ Bits setzt, wird da auch nichts ausgelöst. Denke nur dran, das der 6850 eine OpenDrain IRQ Ausgang hat und der Z80 keinen internen Pullup. Da muss also ein externer mit ran.
Draco schrieb: > Schaut Euch mal das Kiwi-Projekt von Simon Ferber an: > https://www.ist-schlau.de/ > Ein ziemlich beeindruckender Selbstaucomputer auf 68K-Basis. Er hat das > in relativ kurzer Zeit beeindruckend weit gebracht, finde ich. Das erfordert auch deutlich mehr kenntnisse und Zeit als Normalbürger zur Verfügung haben und FPGA hört es bei mir eh auf und Videoprozessor, Audio usw. Danke für die wertvollen Infos! Kapiert! Ich sehe eh schon, dass ich den Monitor selbst schreiben muss, bin zu weit weg von allem was auf Grants Page zu sehen ist und mache auch die Decodierung anders als er mit 74138ern. Schätze aber mal, dass ich den basic Interpeter auch so hineinkriege. Also kriegt der 6850 den NMI spendiert, was natürlich auch heisst, dass wenn der PC spricht der Z80 zuhören muss,ob es im passt oder nicht, es sei denn ich disabel die INT im 6850, zb wenn der Z80 sein Programm gestartet hat. Meine Frage bezog sich darauf dass der NMI mitten in einen INT reinquatschen darf, also während die ISR grad abgearbeitet wird.
1 | void nmi(void) __interrupt __critical |
2 | {
|
3 | static char flag_nmi = 0; |
4 | if(flag_nmi) return; |
5 | |
6 | flag_nmi = 1; |
7 | /* hier der Code */
|
8 | flag_nmi = 0; |
9 | return; |
10 | }
|
Du bist ein Schatz! Da ich eh vorhabe den Monitor in C zu schreiben mit etwas inline asm. Welcher Compiler ist das? SDCC? Genau das habe ich gesucht, void nmi(void) __interrupt __critical ist doch sicher ein keyword, damit er eine INT Routine anlegt an der richtigen Stelle, oder? Legt der Compiler auch die Vektortabelle im ROM an und lässt sich dazu bewegen zu einer RAM Routine zu springen. Wohl nicht, oder? Mir schwirren da so Ideen durch den Kopf das ROM wegzublenden, so dass die RAM Adressen auf 0000 rutschen nachdem er ein Programm empfangen hat aber weiss nicht wie ich das realisieren soll. Im Ram müsste dann ja eine identische Kopie der Zeropage liegen, also auch die INT Einsprünge und dere ń Zeiger auf Userroutinen. Das ROM könnte sich ja erst dorthin kopieren, dann den Usercode drüber an der richtigen Stelle und ZACK, schaltet es sich weg und als letzte Aktion muss der Pogrammzeiger dann auf das userprogramm gerichtet werden. Die Adressierung ROM/RAM unterscheidet sich ja nur durch die A15 Leitung, 1 = ROM, 0 = RAM bei mir. Oder spinne ich zu weit? 8255 vs. Z80 PIO: Schaut man sich die Bausteine an fällt auf, dass sie scheinbar für die damaligen peripheriegeräte entworfen wurden. heute hängt ja alles am seriellen USB Bus dran, was früher LPT und Centronics waren. Bei allen beiden scheint es nicht möglich, das was heute normal ist, zb einen Port bitweise als Eingang und Ausgang zu schalten, also Bit 0 = In, Bit 1 = Out, Bit 3 = Tristate usw.
Christian J. schrieb: > beiden scheint es nicht möglich, das was heute normal ist, zb einen Port > bitweise als Eingang und Ausgang zu schalten, also Bit 0 = In, Bit 1 = > Out, Bit 3 = Tristate usw. Beim 8255 geht das wirklich nicht, weil dessen Richtung nur portweise schaltbar ist. Beim Z80 PIO lässt sich jedoch die Richtung sehr wohl pinweise steuern. Tristate ist überflüssig, weil von aussen nicht von einem Input unterscheidbar. Open drain lässt sich wie bei AVRs über die Richtung steuern.
Christian J. schrieb: > Meine Frage bezog sich darauf dass der NMI mitten in einen INT > reinquatschen darf, also während die ISR grad abgearbeitet wird. Ja. Und wo ist da das Problem? ;-) Der NMI kann durch einen weiteren NMI unterbrochen werden, davor musst du dich schützen. Ob die CPU gerade einen INT abgehandelt hat oder nicht, kann dir relativ egal sein: Dafür sind IFF1 und IFF2 da. > Welcher Compiler ist das? SDCC? Ja, aber ungetestet. Siehe SDCC-Manual. > Genau das habe ich gesucht, void nmi(void) __interrupt __critical ist > doch sicher ein keyword, damit er eine INT Routine anlegt an der > richtigen Stelle, oder? Nein. Siehe SDCC-Manual. NMI-Handler: "void nmi(void) __interrupt __critical" INT-Handler: "void int(void) __interrupt(1) __critical" > Legt der Compiler auch die Vektortabelle im ROM an und lässt sich dazu > bewegen zu einer RAM Routine zu springen. Wohl nicht, oder? Nicht für Z80, weil das vom Modus abhängt. Siehe SDCC-Manual. ;-) > Mir schwirren da so Ideen durch den Kopf das ROM wegzublenden, so dass > die RAM Adressen auf 0000 rutschen nachdem er ein Programm empfangen hat > aber weiss nicht wie ich das realisieren soll. Die Adressierung ROM/RAM > unterscheidet sich ja nur durch die A15 Leitung, 1 = ROM, 0 = RAM bei > mir. Wenn A15 == 1 ins ROM führt, dann sind das die oberen 32 KB. Da musst du erstmal hinkommen! Teilst du den Adressraum in zwei Hälften, je 32 KB ROM und RAM? Dann linke deine Programme an die richtigen Adressen und lass gut sein.
Zu den etwas selteren aber praktischen Bausteinen gehörte der Z80 STI, den Mostek einbrachte. 8 I/O Pins mit flankengetriggerten Interrupts, 4 Timer und eine UART. An diesem Baustein erkennt man recht gut, wozu die Interrupt-Vektoren gut waren. Denn davon hatte der immerhin 16. http://www.cpcwiki.eu/index.php/Z80-STI http://www.ebay.de/itm/1-Stuck-1-pieces-MK3801N04-Z80-STI-Serial-Timer-Interrupt-Contr-DIP40-NEU-NEW-/271339278196?pt=Bauteile&hash=item3f2d14cf74
Harald schrieb: > Es gäbe auch noch das All-in-one Paket Z80 KIO.... Klar, aber so richtig Retro ist der Klops von anno 2002 ja nicht mehr. Retro Board mit LQFP100, also nee, da kannste den Kram auch gleich im FPGA versenken. ;-)
A. K. schrieb: > Harald schrieb: >> Es gäbe auch noch das All-in-one Paket Z80 KIO.... > > Klar, aber so richtig Retro ist der Klops von anno 2002 ja nicht mehr. > Retro Board mit LQFP100, also nee, da kannste den Kram auch gleich im > FPGA versenken. ;-) PLCC84, ideal zum Verdrahten am Lochraster....
Moinse! Ist ja genial...... den Z80 STI habe ich mir direkt gekauft, spart geich 3 fette 40 Pinner ein! Ok..... ich könnte auch alles einsparen und einen Attiny84 einsam auf die Platine setzen :-)))) Der PLCC 84 "Klops" macht das Retro Design leider kaputt, das Auge isst mit und die kantige Ästehtik eines PLCC entspricht leider nicht dem Auge des Künstlers. PLCC auf Lochraster verdahtenn ist so als fährt man in einer Baustelle auf der Autobahn auf linken 2,50m Spur hat rechts neben sich die LKW. Nee... Ich teile den Adressraum üpbrigens in 8kb ROM und 56 KB Ram mit einem 128K RAM Baustein mit 30 Pins. Es wächst ...... danke an euch alle ! Supi! Gruss, Christian
Harald Nagy schrieb: > Naja, ich stelle nur immer wieder - gerade hier im Forum - fest, dass > gerade bei den Hobbyanwendern, wo auch ich mich dazuzähle, ein extremer > Mangel an Grundwissen herrscht. > Das Problem ist IMHO nur das, dass euch, die beruflich in dieser Branche > unterwegs seid, die Grundlagen so vertraut und in Fleisch und Blut über > gegangen sind, dass euch gar nicht auffällt, dass die teilweise blöden > Fragen daher rühren. Da täuschest du dich aber ganz gewaltig. Ich kenne genug junge Leute, die mit ihrem frisch erworbenen Master in der Tasche in die professionelle Elektronikentwicklung einsteigen wollen und die zwar einen Linux-Rechner benutzen können und geübt sind im Eingeben ihres Paßwortes und dem Benutzen der Kommandozeile, aber bereits den Sinn eines treiberinternen Ringpuffers für serielles I/O nicht zu erkennen vermögen und auch nicht verstehen können, warum ein Hintergrund-Monitor die empfangenen Zeichen echot, ebenso nicht wie man eine Leiterplatte designt und und und. Ich erwarte ja keine 100 Jahre Berufserfahrung von einem jungen Menschen, aber ich erwarte ein geschultes Denkvermögen und Auffassungsgabe - und da gibt es ganz häufig heftige Defizite. Sachlich interessierte Hobbyisten - sprich Amateure, zu deutsch "Liebhaber" obwohl das ne andere Assoziation mit sich bringt :-) kennen sich recht häufig viel besser aus als die sogenannten Profis. Nebenbei gesagt heißt "Profi" ja nur, daß einer das Thema nicht aus Liebe zum Thema beackert, sondern nur schnöd seinen Lebensunterhalt damit verdienen will. Von besserem Wissen ist da garnix gesagt. W.S.
PS. Zum SDCC:
Es scheint doch zu gehen, müsste mir das mal im Am Listing anschauen,
wenn ich dazu komme, was er dann produziert. Den Monitor in C zu
schreiben macht mir deutlich mehr Spass.
3.10.4
Z80 Interrupt Service Routines
The Z80 uses several different methods for determining the correct
interrupt vector depending on the hardware implementation. Therefore,
SDCC ignores the optional interrupt number and does not attempt to
generate an interrupt vector table. By default, SDCC generates code for
a maskable interrupt, which uses a RETI instruction to return from the
interrupt. To write an interrupt handler for the non-maskable interrupt,
which needs a RETN instruction instead,
add the __critical keyword:
void nmi_isr (void) __critical __interrupt
{
...
}
However if you need to create a non-interruptable interrupt service
routine you would also req
W.S. schrieb: > aber > bereits den Sinn eines treiberinternen Ringpuffers für serielles I/O > nicht zu erkennen vermögen und auch nicht verstehen können, warum ein > Hintergrund-Monitor die empfangenen Zeichen echot, ebenso nicht wie man > eine Leiterplatte designt und und und. Ich kann dir versichern, dass es in einer Firma für die ich früher mal gearbeitet habe - bevor ich den Kanal voll hatte - "Profis" gibt, zumindest halten die sich für solchen, die irgendwann mit 50 getrieben durch den Markt quer einsteigen mussten in uC und dabei Sachen produzieren, die einem die Haare zu Berge stehen lassen. Keine Ahnung was eine Statusmaschine oder ein Keller-Stack ist, nicht mal den Begriff gehört, Was ist ein Baum, was ein Zeiger - keine Ahnung von grundlegenden Programmiertechniken und Softwareplanung.... alles strotz vor globalen Variablen, die kreuz und quer verändert werden, einfach nur an den Rechner setzen und Code runtertippen, wo jede Variable i,jk,n heisst, jede Funtion func1,func2, func3 und kein Mensch mehr durchdblickt. Aber mit OP's, Transistoren und Dioden kennen sie sich aus..... darum sind sie Profis. Oder ein Bewerbungsgespräch 2004, wo ich zu hören bekam "Wir benutzen 8051 und programmieren alles in Assembler!", FPGA? CPLD? Wozu das! Warum? Weil der Entwicklungsleiter nichts anderes konnte und Angst hatte von einem Jüngeren "überflügelt" zu werden. Nicht nur über die Jungen kann man sich aufregen, da wir alle mal so waren, sondern ebenso über die Älteren die als Bremsklotz wirken, bloss weil die Panik haben entbehrlich zu werden oder etwas neues lernen müssen. Diese Mentalität hasse ich aber sie ist weit verbreitet. > ebenso nicht wie man eine Leiterplatte designt und und und Man sollte es als Ingenieur mal gemacht haben aber das ist fast überall Aufgabe von technikern und Layouter, die das besser und schneller machen und vor allem wissen wie es produziert werden kann. Hut ab vor manchen die 6 Lagen ohne Autorouter routen können! Es gibt ne Menge Funkamateure, die jeden Master Ingenieur in die Tasche stecken! Mein erster Chef hatte nie studiert und war ein Genie in Sachen Konstruktion am CAD System. Alles DIY .... Motivation ist durch nichts zu ersetzen.
Christian J. schrieb: > Aber mit OP's, Transistoren und Dioden kennen sie sich aus..... darum > sind sie Profis. Na, das ist dann ja doch wenigstens was. Aber mal ganz grundsätzlich: Heutzutage wird das Wort "Profi" von den meisten gleichgesetzt mit "besonders erfahrener Könner seines Gebietes" und das steckt nicht drin in dieser Büchse der Pandora. Ein Profi ist eben nur einer, der damit Geld verdienen will. Nix mehr. Und ein Amateur ist im Gegensatz zum Profi einer, der sich für die Sache interessiert aber damit kein Geld verdienen will. Beispiel Lernbetty: Die Betty-Fernbedienung wurde von Profis entwickelt, die damit gewaltig Knete machen wollten. Ist in die Hose gegangen. Als Fernbedienung ist das Teil lausig und relativ unbrauchbar, weil sie viel zu viel Strom frißt. Wenn ich hingegen mich hinsetze und abends bei einer Flasche Rotwein dafür eine Art Mini-Betriebssystem schreibe, damit man mit dieser Fernbedienung ein bissel was lernen kann, dann bin ich bezüglich Betty-Fernbedienung ein Amateur. Schließlich verdiene ich mein Geld mit anderen Dingen und eben nicht mit der Lernbetty. Es wäre sicherlich eine gute Sache gewesen für den Nachwuchs (sofern er nicht nur aus Möchtegern-Überfliegern besteht), wenn wesentlich mehr andere Amateure mit passendem Fachwissen sich dran beteiligt hätten. Die Crew damals war recht überschaubar. Aber damit sind wir wieder bei der unseligen Neigung von Profis, sich alles zuzuhalten was geht. Bloß das bißchen Wissen das man hat NICHT weitergeben, es könnte ja ein anderer verstehen und das schmälert die Berufschancen (wenn man im Grunde ein Schmalspur-Profi ist). Mentale Kleinkariertheit ist ein mächtiger Antrieb in unserer Gesellschaft. W.S.
Das mit dem ROM und RAM an der gleichen Addresse ist nicht so kompliziert: Das RAM kriegt immer die Schreibzugriffe. Die Lesezugriffe für den ROM Bereich werden halt umgeschaltet: mit ROM bekommt das ROM den Lesezugriff, und im RAM Mode kommt halt das RAM dran. Das CS Signal bekommen beide, Write Enable bekommt das RAM, nur OE wird halt getrennt. Das sollte nicht viel komplizierter sein als den Speicher in 8 K + 56 K zu teilen. Für ein einfaches System sollten aber auch 32 K RAM und bis zu 32 K EPROM reichen. Für die Interruptvektoren usw. ist es halt so, dass diese vor dem umschalten erst einmal ins RAM geschrieben (z.B. aus dem ROM) werden müssen. Ein Teil des Kodes kann ggf. auch Kopiert werden. Ein paar Bytes vom RAM sind also mehr oder weniger fest belegt, können aber natürlich auch angepasst werden (z.B. anderes Ziel für Interrupt-Vektoren).
N'abend! Mein Design wächst langsam mit der Demo Version des Eagle, denn auf dem Papier habe ich es schon länger aufgegeben. Falls jemand eine Z80 KIO als LIB hat bitte immer her damit. Die Eurokarte ist leider bereits randvoll, auch wenn CTC und SIO durch die Verwendung des KIO (tausend Dank an A.K. für den Hinweis), den ich mir bestellt habe wegfallen. Damit löst sich auc das INT Problem in Luft auf, da die Uart diesen erzeugen kann, 16 INT bietet der Chip. Über diesen Chip von Mostek gibt es sehr wenig, ich habe nur ein gescanntes uraltes Data Sheet gefunden. Musste auch 10 Euro für das Ding hinlegen. Was er drin hat reicht aber wohl auch, auch wenn ich den Horror habe vor "blind programmieren" (bin ziemlich LPCxxx Raspberry, und Arduino geschädigt mit Rundum-Sorglos-Paket durch die IDE), denn mehr als eine LED an HALT werde ich wohl nicht haben, um zb das Setup der KIO zu überpüfen. Bzw muss erst deren Uart laufen, um was zu sehen. Zuerst werde ich mir daher ein Debug Werkzeug schaffen müssen. Folgende Fragen tun sich mir noch auf: 1. Ich will kein Gattergrab erzeugen, was leider sehr schnell geht. Reicht ein 74HCT138 aus, um 3 I/O Bausteine zu decodieren? Viele machen es mit Einzelgattern aber die Lösung gefällt mir besser. 3 Adressleitungen auf 8 Demuxer Ports. 2. KIO Uart: Welchen uC Takt muss ich wählen, damit ich die bekannten Baudraten mit geringem Fehler erzeugen kann? Aktuell habe ich einen 3.6864 Mhz Oszillatorbaustein und einen 4.0000 Mhz Baustein. Der KIO wird sicherlich über einen Teiler die asynchrone Übertragung bedienen. 3. Damit das Design nicht rein digital und schnöde ist möchte ich den Uralt ADC0804 einsetzen, den ich noch reichlich hier habe und den man in "Schulungsbrettern" mit LED und Poti oft sieht. Was ist sinnvoller, wenn er keinen INT an die Z80 liefern kann bzw soll. weil das ja nicht decodiert werden kann: Ihn im free running mode laufen zu lassen, d.h. er wandelt dauernt oder die Wandlungen, die ja Zeit brauchen durch die CPU anzustossen? Wenn ich das Kuderwelsch da unten richtig deute wird ein I/O Lesezugriff die Wandlung anstossen. Aber nur anstossen. Beendet wird sie durch den INT, den ich ja nicht verwenden will. Und woher nehme ich das Clock Signal von 640 khz? RC Kombination? 10k, 150pf? Ich habe keinen Platz um den CPU Clock noch über Teiler zu jagen. Gruss, Christian Ich habe diesen Text jetzt 5 Mal gelesen und bin immer noch nicht schlauer :-( Datenbuch ADC0804: The converter is started by having CS and WR simultaneously low. This sets the start flip-flop (F/F) and the resulting “1” level resets the 8-bit shift register, resets the Interrupt (INTR) F/F and inputs a “1” to the D flop, F/F1, which is at the input end of the 8-bit shift register. Internal clock signals then transfer this “1” to the Q output of F/F1. The AND gate, G1, combines this “1” output with a clock signal to provide a reset signal to the start F/F. If the set signal is no longer present (either WR or CS is a “1”) the start F/F is reset and the 8-bit shift register then can have the “1” clocked in, which starts the conversion process. If the set signal were to still be present, this reset pulse would have no effect (both outputs of the start F/F would momentarily be at a “1” level) and the 8-bit shift register would continue to be held in the reset mode. This logic therefore allows for wide CS and WR signals and the converter will start after at least one of these signals returns high and the internal clocks again provide a reset signal for the start F/F.
Nimmst du nun doch den klops der das retrolayout kaputt macht und den A.K. so verflucht hatte? Tztztz
Christian J. schrieb: > Über diesen Chip von Mostek gibt es sehr wenig, ich habe nur ein > gescanntes uraltes Data Sheet gefunden. Da ich das Original-Databook von MOSTEK 82/83 vorliegen habe, mit ebendiesem STI drin: Mehr war auch damals nicht üblich. Datasheets wurden auf abgeholzten Wäldern an den Mann gebracht, nicht als PDF. > 1. Ich will kein Gattergrab erzeugen, was leider sehr schnell geht. > Reicht ein 74HCT138 aus, um 3 I/O Bausteine zu decodieren? Ja. Das war allgemein üblich. 2 Adressbits dekodieren reicht aus. Bei bis zu 4 Bausteinen tuts auch ein halber 74HCT139. > 2. KIO Uart: KIO war der PLCC 84 Klops. Du meinst sicherlich den STI. > Welchen uC Takt muss ich wählen, damit ich die bekannten > Baudraten mit geringem Fehler erzeugen kann? Wie bei so ziemlich jeder anderen UART ohne fraktionalem Baudratentimer auch. > Aktuell habe ich einen 3.6864 Mhz Oszillatorbaustein Also ein Baudratenquarz. Perfekt. > Was ist sinnvoller, wenn er keinen INT an die Z80 liefern kann Warum nicht? Die 8 I/Os des STI sind eigentlich Interrupt-Eingänge, die auch als Portbits verwendet werden können. > Und woher nehme ich das Clock Signal? RC Kombination? 10k, 150pf? Klar. > Ich habe diesen Text jetzt 5 Mal gelesen und bin immer noch nicht > schlauer :-( Schreibzugriff auf den ADC startet die A/D-Wandlung. Dann warten bis INTR aktiv und Ergebnis per Lesezugriff auslesen. Das wars auch schon.
Harald schrieb: > Nimmst du nun doch den klops der das retrolayout kaputt macht und den > A.K. so verflucht hatte? Tztztz Ich nehme an, dass er die grad verwechselt hat. Denn der KIO ist nicht von MOSTEK und gekauft hat er den STI wohl: Es war kurz drauf einer weniger im eBay-Angebot.
Harald schrieb: > Nimmst du nun doch den klops der das retrolayout kaputt macht und den > A.K. so verflucht hatte? Tztztz Nein! Nicht den Klops! den STI, sorry ! >>Schreibzugriff auf den ADC startet die A/D-Wandlung. Dann warten bis >>INTR aktiv und Ergebnis per Lesezugriff auslesen. Das wars auch schon. Und wieso schreiben die das nicht? umkipp Das interne Geschwurbel des Chips interessiert keinen. 30 Seiten Data Sheet für diesen einfachen Chip..... Ok, Schreibzugriff aber da er kein Register hat wo man reinschreiben kann wird es wohl egal sein was auf dem Datenbuss liegt. Nur RD wird den Inhalt auf diesen legen.
Christian J. schrieb: > Und wieso schreiben die das nicht? *umkipp* Tun sie doch. Erstens sieht das doch jeder im Functional Diagram ;-), zweitens wären da noch Fig 10A und 10B. > Ok, Schreibzugriff aber da er kein Register hat wo man reinschreiben > kann wird es wohl egal sein was auf dem Datenbuss liegt. So isses.
Angehängte Dateien:
-
12.JPG
28 KB
A. K. schrieb: > Ach ja: Richtig Retro wäre natürlich SN75188+189 statt MAX232. ;-) Das wird VOLL Retro .... ein kleiner Chinese schaufelt die Bits einzeln von der Uart zum PC hin und zurück. Nee..... habe schon sowas hier... Dumme Frage: Hast du die 74er Reihe komplett als "durchsuchbare" pdf's. Falls ja wäre eine dickes ZIP File Richtung meiner einer möglich?
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. Ich glaub ja. Bin letztes Jahr auf einer Retro-Messe (hehe, es waren immerhin ein Dutzend Tische ;-) über Leute gestolpert, die neue Z80 Platinen gezielt für Retro-Fans anbieten.
Diesen Quark hier habe ich mir in München angetan, nach 1h war ich wieder weg :-( Mir schien, dass einige dort zu lange radioaktive Strahlung von Monitoren inhaliert haben oer sonstwie "geschädigt" waren. http://blog.spielquader.de/wp-content/gallery/muenchen-vcfe-2013/img_3060.jpg SN75..... bah, der braucht ja -15,+15, noch einen Retro DC/DC Wandler (Recom) kaufen für teuer Geld. Oder eine extra Schaltstufe als Spanungspumpe......
Christian J. schrieb: > Dumme Frage: Hast du die 74er Reihe komplett als "durchsuchbare" pdf's. > Falls ja wäre eine dickes ZIP File Richtung meiner einer möglich? Wenn du das hast, stellst du keine Fragen mehr. ebay 121429871779
Michael_ schrieb: > Christian J. schrieb: >> Dumme Frage: Hast du die 74er Reihe komplett als "durchsuchbare" pdf's. >> Falls ja wäre eine dickes ZIP File Richtung meiner einer möglich? > Wenn du das hast, stellst du keine Fragen mehr. > ebay 121429871779 Jahr: 1985, 2. Auflage Was it mit HCT, HC? Wo hört der auf? Bei 74xx200? Kann ich mir das auf meinen Kindle laden? :-) Die hatte ich mal, habe sie idiotischerweise weggeworfen bei einem Umzug. http://www.auctionworld.at/eBay-Bilder/ttl.jpg
Christian J. schrieb: > Was it mit HCT, HC? Wo hört der auf? Bei 74xx200? Was willst du z. Bsp. mit HC? Bei den alten Z80 Chip und der Pheripheri mußt du die Lastfaktoren beachten. Die Z80 sind sehr empfindlich gegenüber Timing. Eigentlich mußt du die Baugruppen über Bustreiber entkoppeln. Christian J. schrieb: > Kann ich mir das auf meinen Kindle laden? :-) Ja, leg das Buch einfach drauf.
Michael_ schrieb: > mußt du die Lastfaktoren beachten. > Die Z80 sind sehr empfindlich gegenüber Timing. Eigentlich mußt du die > Baugruppen über Bustreiber entkoppeln. Moment.... ohne da jetzt nachgeschaut zu haben..... "schneller ist besser"? Der Z80 geht ja nunmal gemächlich daher, die Zeiten im Manual sind recht gemütlich alles über 100ns. Der Ram den ich habe hat 20ns Zugriffszeit. Die HCT, die ich einsetze (LS habe ich auch noch) takten bis fast 100 Mhz. Was muss ich also beachten? Logik Anlyszer habe ich, nachschauen geht also immer.
Christian J. schrieb: > Diesen Quark hier habe ich mir in München angetan, nach 1h war ich > wieder weg :-( Nicht München, sondern CH, aber war ganz lustig. Aber nicht so sehr das was da rumstand. Vielmehr hatte ich recht angeregte Diskussion mit 2-3 anderen "Oldies", darunter einer aus der Münchner Szene. > SN75..... bah, der braucht ja -15,+15 +/-12V tun es auch. Und jetzt weisst du auch, warum die Stromversorgung vom PC bis heute -12V drauf hat. ;-)
Michael_ schrieb: > Eigentlich mußt du die > Baugruppen über Bustreiber entkoppeln. Ach wo, nicht in der Dimension, also bei CPU, STI und 2xADC. Wenn er da einen externen Bus dran hängen wollte, ja dann.
A. K. schrieb: > +/-12V tun es auch. Und jetzt weisst du auch, warum die Stromversorgung > vom PC bis heute -12V drauf hat. ;-) Vielleicht macht hier ja noch einer einen Thread mit einem "4004" Design auf.... glaube der hatte auch -15V, +15V und brachte seine Programmierer schneller in die Klapse als der Z80. Das hier ist ein Die-Shot des 68000, gibt es bis 10000 Pixel, also ein 230 MG grosses Bild. Ich frage mich welche armen menschen da das Layout gemacht haben, so ohne Place & Route Tools, war doch Zeichenbrett Ära damals... http://www.visual6502.org/images/68000/Motorola_68000_die_20x_1a_top_1600w.png
Christian J. schrieb: > Die Eurokarte ist leider bereits randvoll, auch wenn CTC und SIO durch > die Verwendung des KIO ... wegfallen. [gemeint ist der STI, aber egal] > Über diesen Chip von Mostek gibt es sehr wenig, ich habe nur ein > gescanntes uraltes Data Sheet gefunden. Musste auch 10 Euro für das Ding > hinlegen. Was er drin hat reicht aber wohl auch, auch wenn ich den > Horror habe vor "blind programmieren" Tolle Wurst. Statt der gut dokumentierten SIO nimmst du also lieber den schlecht (bis gar nicht) dokumentierten STI, bei dem du noch nicht mal nachmessen kannst, ob du denn nun die Baudrate korrekt eingestellt hast. Ja, so wird das bestimmt was </ironie> Und eine Europakarte voll? Mit dem bisschen Zeug? Laß halt nicht so viel Luft dazwischen. Christian J. schrieb: > Das hier ist ein Die-Shot des 68000, gibt es bis 10000 Pixel, also ein > 230 MG grosses Bild. Ich frage mich welche armen menschen da das Layout > gemacht haben, so ohne Place & Route Tools, war doch Zeichenbrett Ära > damals... Das waren halt richtige Ingenieure damals. Die konnten sicher auch noch das Datenblatt der Z80 SIO lesen und verstehen ... SCNR XL
Axel Schwenke schrieb: > Tolle Wurst. Statt der gut dokumentierten SIO nimmst du also lieber den > schlecht (bis gar nicht) dokumentierten STI, bei dem du noch nicht mal > nachmessen kannst, ob du denn nun die Baudrate korrekt eingestellt hast. Keep cool. 16 Seiten, alles drin was man wissen muss. Da der keine synchronen Protokolle kann braucht man auch weniger Doku. Und da der Baudratentimer extern auf die Takteingänge der UART verkabelt wird, kann man problemlos nachmessen.
Christian J. schrieb: > Dumme Frage: Hast du die 74er Reihe komplett als "durchsuchbare" pdf's. > Falls ja wäre eine dickes ZIP File Richtung meiner einer möglich? Hier in linker Spalte Gruppe auswählen, und dann rein in die parametrische Suche: http://www.ti.com/lsds/ti/logic/home_overview.page A.K., von wann sind denn Deine TTL-Schinken? Bei mir ist das nur ein Band "Fifth European Edition 1982", 4cm dick.
Axel Schwenke schrieb: > Und eine Europakarte voll? Mit dem bisschen Zeug? Laß halt nicht so viel > Luft dazwischen. Du bist ein kleiner Klugsch..... denn solche Pingräber zu verbinden erfordert präzise und ordentliche Arbeitsweise. Und die wird bei mir unter der Leucht-Lupe mit Fädeltechnik gemacht, kleinen Stegen, die man drunter klebt vor jede Pinreihe, so dass das ganze Board mit einer Autobahn für 0,2mm Drähte versehen wird. Mit normalem Kupferlackdraht 0,5mm wird es schon zur Geduldsprobe zwei Kabel in einen Lötpunkt einzulöten, da der eine immer raushüpft, wenn du den anderen reinlöten willst. Mit 0,2mm passiert das aber nicht, da diese keine Eigenspannungen haben, du kanst locker 3-4 Kabel an einem Pin anbinden. In einem Kamm kann ich ca 30-40 Drähte parallel führen. 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. Das ist alles schon gut durchdacht und der STI hat "3 in 1" mit 40 Pins statt " 3 in 3" mit 100 Pins. :-)
Angehängte Dateien:
-
DSC08135__1600_x_1200_.jpg
220 KB -
DSC08137__1600_x_1200_.jpg
220 KB
So schauts aus bisher... wobei die rechte Platine eine andere ist.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.