Interrupts

Interrupts sind ne feine Sache. Wenn ein Computer Peripheriegeräte wie Tastatur, Maus, UART u.Ä. verwendet, müsste er theoretisch zyklisch diese Geräte abfragen, ob sie neue Daten zur Verfügung haben. Wenn man also schnell auf einen Tastendruck reagieren will, müsste man entsprechend häufig die Tastatur abfragen, um die Reaktionszeit klein zu halten. Dieses ständige Abfragen nennt man Polling. Die Zeit, die für's Polling draufgeht, steht dann nicht mehr für das eigentlich laufende Programm zur Verfügung. Deswegen nimmt man (meistens) ein anderes Prinzip, nämlich Interrupts. Der Z80 hat einen Interrupt-Pin (eigentlich zwei, aber ich benutze nur einen). Der liegt im Normalfall auf High-Pegel. Wird nun eine Taste gedrückt, so wird von der Tastatur der High-Pegel auf low gezogen. Der Prozessor merkt dadurch, dass etwas passiert ist, um das er sich kümmern sollte. Dann kann er die Peripherie "auslesen", um festzustellen, was passiert ist. Er liest also die Tastatur nur dann aus, wenn wirklich eine Taste gedrückt wurde.
Der Z80 hat drei Interrupt-Modi. Modus 0 wurde aus Kompatibilitätsgründen zum Intel 8080 beibehalten. Löst das Gerät einen Interrupt aus, so bekommt es die Möglichkeit, eine Instruktion auf den Datenbus zu legen, die der Prozessor dann ausführt. Dies ist meistens der RST-Befehl, mit dem man ich glaube acht verschiedene (aber a priori festgelegte) Stellen in der Speicherseite 0 anspringen kann.
Im Modus 1 springt der Prozessor im Interruptfall pauschal zu 0x38. Und Modus 2 ist der flexibelste Modus: Der Programmierer legt im Speicher eine Tabelle mit Interruptvektoren an. In das Register I lädt er die Nummer der Speicherseite, in der sich die Tabelle befindet. Beim Interrupt legt nun das Gerät eine Nummer auf dem Datenbus, die dem Eintrag in der Tabelle entspricht. Der Z80 liest nun diesen Interruptvektor ein und springt an diese Adresse. Dort befindet sich dann die entsprechende Routine, die bspw. die Tastatur ausliest. Auf diese Weise lassen sich 128 verschiedene Interrupt-Routinen anspringen.
Soviel zur Theorie. Ich wollte ja eigentlich den Modus 2 benutzen, doch ich habe nen Layoutfehler drauf. Das wird so nicht klappen, weswegen ich erstmal mit Modus 1 Vorlieb nehme. Nur ein Interrupt ist besser als gar keiner :-) Das Problem ist folgendes: Der Interrupt wird ausgelöst. Der Prozessor weiß jedoch erstmal gar nicht, wer denn die Interruptleitung runtergezogen hat, er sieht nur, dass sie low ist. Deswegen löst er einen IORequest parallel zu einem M1 Zyklus aus. Dies signalisiert dem Interrupt-Gerät, nun die Nummer des Interruptvektors auf den Datenbus zu legen. Ich habe nicht bedacht, dass er ja gar keine Geräteadresse auf den Datenbus legt, weswegen kein entsprechendes Chipselect ausgelöst wird.
Ich hätte sogar alle nötigen Logikgatter auf der IOBoard-Platine noch frei um das zu fixen, jedoch wäre das mit einem SMD-Beinchenbiegen und rumpfuschen verbunden, das ist mir erstmal zu heikel. Hab kein Bock, mir wieder ein Pad abzureissen wie bei der Main-Platine. Interrupt-Modus 1 reicht mir erstmal :-)

Assembler-Spaß

Wo ich ja nun endlich ein funktionierendes System habe, kann ich mich mal etwas dem Z80-Assembler widmen. Das ist schon eine kleine Umstellung, wenn man sonst nur C programmiert und auch "in C" denkt. Die ersten Routinen, die ich programmiert habe, sind natürlich String über UART senden und String vom UART empfangen. Da mein Z80-Computer ein sehr freundlicher ist, wird man auch gleich angenehm begrüßt :-) Das sieht dann im Terminal so aus:

Ist er nicht nett? Ok- zugegeben nicht sehr spektakulär ;-) Aber es läuft auf meiner Hardware und ich habe jedes Byte selbst programmiert!

Und weil's so praktisch ist, hier ein Screenshot meines Programmers, mit dem ich den EEProm (und auch den RAM) lesen und schreiben kann:

Lädt man ein assembliertes Binary, so gibt der Programmer erstmal den Inhalt als Hex aus. Im Offset-Eingabefeld kann man das Startoffset eingeben, wo die Bytes hingeschrieben werden sollen. Mit "write" werden die Bytes an den dsPIC (über UART) auf der Mainplatine geschickt. Der schreibt dann die Bytes an die gewünschte Stelle in den EEProm (oder RAM).
Durch "release" entlässt der dsPIC den Z80 wieder aus dem Reset und der neue Code wird vom Z80 direkt ausgeführt.

Es funzt!!

Mann mann, das war frustrierend! Manchmal hat die Schaltung funktioniert, sprich der Z80 hat über den UART mit mir gesprochen. Dann habe ich kleine Änderungen an der Z80-Software gemacht, nämlich Code in Subroutinen gepackt, die mit dem call-Befehl aufgerufen werden. Dann hat es sporadisch funktioniert, aber nach einem Reset wieder nicht. Dann habe ich die alte, funktionierende Version aufgespielt, die dann aber plötzlich nicht mehr funktionierte. Sehr seltsam, genau wie bei meiner alten, selbstverdrahteten Platine! Also habe ich heute eine kleine Display-Platine gebastelt, um zu schauen, ob diese denn ansprechbar ist. Hier trat das gleiche Phänomen auf. Das Problem musste also auf der Main-Platine liegen.
Mir ist dann aufgefallen, das die Masse der Displayplatine unsauber war. Und siehe da: Eine kalte Lötstelle an einer Steckbuchse auf dem Mainboard. Doch das hat das Problem immer noch nicht beseitigt. Da nur Probleme bei Aufrufen von Subroutinen auftraten, bin ich dann endlich mal auf die Idee gekommen, den RAM-Baustein zu testen. Bei einem Lese-/Schreibtest hat sich dann rausgestellt, dass der manchmal Daten nicht richtig speichert. Das erklärt auch, warum der Z80 Probleme mit den Subroutinen hatte. Denn beim Subroutinen-call wird der PC (Program Counter) auf den Stack kopiert, der sich im RAM befindet. Und wenn der RAM den Wert nicht richtig speichert, wird beim return der PC nicht korrekt zurückgesetzt und der Z80 springt sonstwo hin.
Die UART-Platine funktioniert nun auch wie gewünscht.

Hier ein Foto der Display-Platine:

Main-Platine bestückt und erste Tests

Ich habe gerade den dsPIC zum Laufen gebracht. Ich hatte ein paar Fehler in die µC-Firmware eingebaut, damit ich zwei Stunden lang Debuggen üben kann ;-) Nun lässt sich aber endlich per dsPIC der RAM und das EEPROM lesen und schreiben. Desweiteren kann er einen Takt mit Hilfe des integrierten Timers erzeugen, mit dem ich den Z80 betreiben kann, für Single-Step z.B. Das Testprogramm aus einem meiner ersten Posts habe ich dann in den EEPROM programmiert und den Z80 erfolgreich damit laufen lassen. Das scheint also zu klappen. Hoffentlich finde ich am WE Zeit, das IO-Board zu bestücken!

Hier sieht man das bestückte Mainboard von unten:

Blöderweise hatte ich das NAND (der kleine Käfer oben in der Mitte) falsch rum draufgelötet. Also musste ich ihn wieder runterlöten. Dabei habe ich ein Pad abgerissen. Hier sieht man die Korrektur in Nahaufnahme und etwas Fädeldraht, mit dem ich das betroffene Beinchen verbunden habe:

Der Fädeldraht passt praktischer Weise genau durch die durchkontaktierte Via.

So sieht die Oberseite der Platine ohne DIL-ICs aus:

Der rote PicKit3 ist ein Gerät, um (ds-)PICs zu Programmieren und zu Debuggen. Sehr zu empfehlen, vor allem, weil es preislich dem Hobbybastler entgegen kommt.

Und so sieht der Aufbau derzeit aus:

Platinen sind angekommen!

Endlich sind sie da, die beiden Platinen! Ich habe begonnen, die ersten Komponenten zu bestücken. So sieht sie aus:

Ganz hinten sitzt der Max232 für die serielle Schnittstelle RS232, der größte IC ist der dsPIC30F4012, und die beiden kleinen rechten IC's sind Schieberegister, in die der dsPIC Adressbits reinschiebt, um den Speicher zu adressieren. Morgen geht's weiter!!

CPLD-Programmer

Heute habe ich es endlich getan: Der JTAG-Programmer für Xilinx CPLDs ist bestückt! Die Platine dazu und zu einem Testboard für den XC9536 habe ich hier schon seit einem halben Jahr rumliegen. Mir fehlte nur bisher die Muse dazu, das endlich mal aufzubauen und zu testen.

Links im Bild ist der JTAG-Programmer. Und ja, das ist ein 25poliger Sub-D-Stecker für die parallele Schnittstelle :-) Die beiden ICs sind Bustreiber 74HC125. Die rechte Platine ist das Testboard für den XC9536. Die fertigen Layouts findet man schnell im Netz, einfach nach "xc9536 jtag programmer" suchen.
Die Software zur Programmierung so eines CPLDs ist von der Xilinx-Seite frei herunterladbar. Sie nennt sich ISE Webpack und hat mal eben flotte 3 GB. Sie ist nicht ganz so einfach zu bedienen, aber ich habe es geschafft, ein Test-Programm auf den CPLD zu brennen. Da ich mich irgendwann eh mal mit FPGAs beschäftigen möchte, ist das hier schon eine ganz gute Einarbeitung. Mit dem Webpack lassen sich nämlich auch die Xilinx-FPGAs programmieren.

Während die Z80-Platinen in der Fertigung sind, werde ich mir dann erstmal CPLD-Programmierung mit VHDL/Verilog zu gemüte führen. Irgendwann möchte ich nämlich eine kleine "Grafikkarte" für den Z80 basteln. Und dafür könnte sich so ein CPLD ganz gut eignen glaube ich.

Layout fertig

Es ist geschafft, das Layout steht. Ich habe nicht alles auf ein Board gepackt, sondern das auf zwei verteilt. Das Main-Board mit CPU, Speicher und dsPIC, sowie das IO-Board mit dem 74HC138 für das ChipSelect und dem 16c550.
Jetzt checke ich nochmal alles durch und werde dann nächste Woche die Boards in die Fertigung geben. Na hoffentlich ist kein Fehler drauf, sonst wäre das ein teurer Spaß...

So sieht das Main-Board jetzt aus:

Z80 Main-Board

Wie man sieht, ein zweilagiges Board mit SMD und DIL-Mischbestückung. Bei den 74er Bausteinen bin ich auf SMD gewechselt, um die Boardfläche klein zu halten. Den Z80 und den Speicher gibt's leider nicht als SMD, jedenfalls nicht bei Reichelt.

Neuer Aufbau

Ich kann einen Teilerfolg vermelden. Die UART-Platine hat (mehr oder weniger) funktioniert. Ich habe ein Programm geschrieben, welches über die serielle Schnittstelle empfangene Zeichen als Echo zurücksendet. Hat wunderbar funktioniert. Die ersten paar Minuten. Doch dann sind seltsame Probleme aufgetreten, und der UART hat keinen Mucks mehr von sich gegeben. Beim Messen mit dem Oszilloskop habe ich dann blöderweise nen Kurzschluss auf dem UART-Board verursacht, das hat die Isolation der 5V-Leitung beschädigt und evtl. noch andere Leitungen. Da ich mit dem Aufbau sowieso unzufrieden bin, (u.A. weil sich schlecht messen lässt), werde ich mir eine Platine fertigen lassen. Dann bin ich auch meine Drahtigel los. Mal sehen, ob ich das Layout dafür in der kommenden Woche fertig bekomme.

IO Select

Zur Erzeugung der Chip Selects der Peripherie muss ebenfalls ein Adressdecoder her. Dafür bietet sich der 74HC138 an, ein 3-8 Multiplexer mit invertierenden Ausgängen. Auf sehr einfache Weise lassen sich so Chip Selects für 8 verschiedene Geräte erzeugen, die jeweils 32 Byte Adressraum zur Verfügung haben. Den UART lege ich einfachheitshalber auf IO-Adresse 0x00.

IO-Decoder

Die Verdrahtung ist einfach:

Der 16C550 lässt sich direkt an den Bus anschließen. Die meisten Bussignale liegen als low- und high-active vor. Die Interruptleitung ist high-active.

Serial Board

Als nächstes kommt die serielle Schnittstellenkarte dran. Ich habe einen Z80-SIO und einen 16C550. Der Z80-SIO ist jener Baustein, der früher typischerweise in Verbindung mit einer Z80-CPU für RS232 benutzt wurde. Der 16C550 ist ebenfalls schon älter, wird aber heute noch auf seriellen Erweiterungskarten für den PC verbaut.

Ich kenne beide Chips nicht. Die Datenblätter sind beide ziemlich komplex, ich bin noch unendschieden, welchen der beiden ich verwenden werde.

Der SIO wurde ja zur Verwendung mit dem Z80 designt, aber es gibt nicht allzu viel Infos dazu im Netz. Zum 16C550 findet man deutlich mehr, und er ist nicht ganz so komplex.

Erster Erfolg!

Endlich hab ich den Z80 dazu bewegt, das zu tun was ich sage!! :-) Das Testprogramm ist erfolgreich gelaufen.
Die bidirektionalen Bustreiber (74HC245) der RAM-Karte und der CPU-Karte haben manchmal gegeneinander getrieben. Das hätte ich gar nicht richtig gemerkt, da das nur im Memory-Refresh-Zyklus geschehen ist. Das Symptom war dabei, dass sich der dsPIC resettet hat. Gut, dass die Bustreiber kurzschlussfest zu sein scheinen, jedenfalls ist keiner kaputt gegangen... Ach ja, Empfehlung: Datenblätter ganz genau lesen, das erspart viel Frustration und abkotzen!!

Ich poste hier schon mal die Schematics der beiden Boards:

RAM-Board

CPU-Board

Und in Natura sieht das jetzt so aus:

CPU-Board Rückseite

RAM-Board

Gesamter Aufbau

Mit diesem Aufbau kann man bisher noch nicht so viel anfangen:

Ein dsPIC ist über die serielle Schnittstelle mit meinem PC verbunden. Über Terminal kann ich nun dem PIC sagen, die Bustreiber der RAM-Karte hochohmig zu schalten. So kann dann das EEPROM und den RAM gelesen und beschrieben werden, ohne mit der CPU in Konflikt zu geraten.
Ansonsten "lebt" die CPU in ihrem eigenen Mikrokosmos und hat keinen Kontakt zu Aussenwelt, was das Ganze noch etwas nutzlos erscheinen lässt ;-)
Das wird sich aber bald ändern, denn als nächstes ist eine serielle Karte geplant, mit der die Kommunikation zwischen dem Z80 und einem PC möglich wird.

Erstes Testprogramm

Wenn die beiden Boards fertig sind und (hoffentlich!) auch noch funzen, muss der Z80 ja auch was zum Ausführen bekommen. Ich habe leider nur etwas Ahnung von Assembler, da muss ich mich noch reinfuchsen. Aber als Erstes werde ich wohl folgendes Programm in den ROM schreiben:

(1) LD A,37     
(2) LD (9509), A
(3) HALT        

Zeile (1) lädt die Zahl 37 in den Akku. Zeile (2) schreibt den Akkuinhalt an Speicheradresse 9509. Und Zeile (3) hält den Prozessor an.

Das als Opcodes sieht dann folgendermaßen aus:

Addr      Codes   
0x00      3E 25   
0x02      32 25 25
0x05      76      

Wenn alles geklappt hat, sollte dann an Position 9509 des RAMs die Zahl 37 stehen.

Resetschaltung

Die Resetschaltung der CPU ist sehr wichtig, wie ich feststellen musste. Denn das Resetsignal muss ein paar CPU-Takte lang sein, damit der Reset wirklich vollständig durchgeführt wird. Folgende Schaltung verwende ich für den CPU-Reset:

Der Schalter zieht bei Druck !RESET sofort auf Masse. Lässt man den Schalter los, so lädt sich der Kondensator "langsam" wieder auf 5V auf. Der Schmitt-Trigger sorgt mit seiner Hysterese für ein ständig gültiges TTL-Signal. Eine Tastenentprellung bekommt man auch gleich mitgeliefert.

Memory Management

Beim Z80 sind die Adressräume für Speicher und externer Peripherie getrennt. Dies vereinfacht das Memory Management etwas, da beim Speicher nur noch entschieden werden muss, ob EEPROM oder RAM angesprochen werden soll.
Nun hat das EEPROM 8192 Byte Speicherkapazität und soll an den Anfang des Adressraums "gemapt" werden. Adressen von 0..8191 sprechen also das EEPROM an, 8192-65535 adressieren den RAM.
Mit folgender Schaltung wird das Chip Select generiert:

Simple Z80-MMU

Auf Pin 2-3 wird ein Jumper gesteckt. Das Signal !MREQ ist low active und signalisiert einen "Memory Request". Sind die Adressleitungen A13, A14, A15 und !MREQ low, so wird !ROM_CS runter gezogen, welches an !CS des EEPROMS angeschlossen ist. Ist eine der Adressleitungen high, so wird !RAM_CS runter gezogen und so der RAM selektiert.

Das EEPROM:

Und der RAM:

A16 ist auf GND gelegt. Später werde ich evtl. dies um eine Banken-Logik erweitern, um mehr Speicher ansprechen zu können. Dazu muss ich mir aber erst noch ein paar Gedanken machen, wie das funktionieren könnte.

Z80 Computer

Der Z80 ist ein 8-Bit Prozessor aus dem Jahre 1976. Verwendet wird/wurde er z.B. im Nintendo Gameboy, TI-Taschenrechnern und vielen Arcade-Game-Automaten. Er ist leistungsmäßig verlgeichbar mit dem 6502, der in C64 Computern zu finden ist.

Z80 im 40 Pin DIP-Gehäuse

Mein Ziel ist es, einen kleinen funktionsfähigen Computer um diese CPU herum zu bauen. Ich habe mir diesen Prozessor ausgesucht, weil der Chip noch gut für einen Hobbybastler zu "handlen" ist, und auch der Verdrahtungsaufwand - im Gegensatz zu moderneren Chips - relativ gering ist. Die Z80-CPU besitzt einen 8-Bit Datenbus und einen 16-Bit Adressbus. Es können also bis maximal 64kB RAM direkt adressiert werden. In meinem ersten Design soll er mit 1 MHz betrieben werden.

Und dies ist das Pinout des guten Stücks:

Die Ax-Leitungen sind die Adressleitungen, Dx sind die Datenleitungen. An die Phi-Leitung wird der CPU-Takt angelegt.

Für ein Minimalsystem muss ROM und RAM angeschlossen werden. Das ROM enthält den "Bootstrap"-Code, um den Rechner zu starten. In diesem Projekt wird es wohl gleich das ganze Betriebssystem sein :-)

In den RAM können dann weitere Programme aus externen Quellen nachgeladen werden und er wird als Arbeitsspeicher benutzt.

Wird die CPU neu gestartet, liest sie vom Byte an Adresse 0 (dem ersten Byte des Speichers, in diesem Projekt liegt es im EEPROM) an den Speicher aus. Das "Betriebssystem" muss also gleich am Anfang des Speichers liegen. Wie kommt es dort hin? Dafür werde ich einen Mikrocontroller vorsehen, der über eine serielle Schnittstelle mit einem PC verbunden ist. Auf dem PC wird man so die Software entwickeln und kompilieren können, um sie dann in den EEPROM zu schreiben. Der µC wird ebenfalls den RAM lesen und schreiben können. So werde ich dann auch anfangs die Funktion der CPU prüfen können, da sie ja noch keine Schnittstelle zur Aussenwelt hat.

Ich teile das Projekt für den Anfang erstmal auf zwei Karten auf: Die Prozessorkarte, auf der die CPU, der 1MHz-Quarz und Bustreiber sitzen. Auf der anderen wiederum Bustreiber, EEPROM, RAM und der Controller.

Folgende Bauteile habe ich ausgewählt:

• Zilog Z80 CPU 4MHz
• 1 MHz Quarz
• Invertierender Schmitt-Trigger 74HC14
• Bustreiber 74HC244, 74HC245
• Controller dsPIC30F4012
• 8kB EEPROM Atmel 28c64
• 128kB RAM 628128
• NAND 74LS00
• OR 74LS32

...sowie natürlich die obligatorischen 100nF an jedem IC.

Das Ganze werde ich auf Lochrasterplatinen aufbauen und mit Kupferlackdraht verdrahten.

First Post!

Dies ist ein Blog zur Dokumentation meiner Hobbyaktivitäten.