Ein Atmega328 steuert einen Z80-Computer

Themabewertung:
  • 2 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 734
Registriert seit: Apr 2014
Bewertung: 5
#91
28.06.2019, 13:51

Hallo zusammen,

heute wollte ich mich mal darum kümmern, warum ich immer wieder Probleme mit meinen Programmen in Assembler habe. Sie stürzen immer dann ab, wenn ich bestimmte Speicherbereiche anspreche. Mir kam daher der Verdacht, dass es Probleme mit dem RAM gibt. Ich habe deshalb eine kleine Routine geschrieben, die den Speicher überprüft.

Die Routine "pflügt" sich durch den Speicher und ließt Byte für Byte ein. Das gelesene Byte wird dann verändert, in den Speicher zurück geschrieben, nochmals gelesen und dabei geprüft, ob der Inhalt der Speicherstelle mit dem zuvor generierten Byte übereinstimmt. Danach wird der Originalzustand wiederhergestellt.

Hier ist die Routine (in Z80-Assembler):

 
checkRAM: push hl
push bc
push de
 
ld hl,RAM_START ; Prüfung beginnt ab dem Ende des "Betriebssystems"
ld bc,0dfffh - RAM_START ; Und geht bis zum Bildschirmspeicher
checkLoop: ld a,(hl) ; Byte aus der Speicherstelle laden
ld e,a ; und in E sichern
set 7,a ; Bit 7 setzen
ld d,a ; und in D sichern
ld (hl),a ; Byte in den Speicher schreiben
ld a,(hl) ; und wieder lesen
cp d ; mit D vergleichen
jr nz,checkFail ; keine Übereinstimmung
ld a,e ; gesichertes Byte zurückholen
ld (hl),a ; und ins RAM schreiben
inc hl ; Adresse hochzählen
dec bc ; bis BC = 0
ld a,b
or c ; ist BC denn schon 0?
jr nz, checkLoop ; Nö
 
jr checkDone
 
checkFail: push hl
ld hl,txtMemFail ; Fehler im Speicher
call print
pop hl
call prtHex_Word ; an Adresse HL
checkDone: pop de
pop bc
pop hl
ret
 
 

Die Routine wird nun jedes mal, wenn ich meinen Z80Ardu starte/resette aufgerufen. Und jedes mal bekomme ich den Hinweis, dass bei Speicherstelle $D400 (Dezimal 54272) ein Fehler vorliegt.

Zunächst habe ich gedacht, der RAM-Baustein hätte einen Schlag und habe ihn mal ausgetauscht. Der Fehler besteht weiterhin! Jetzt fürchte ich eine kalte Lötstelle auf der Platine. Ich werde also die Adressleitungen und die Datenleitungen des SRAM und des Z80 noch einmal nachlöten (Dafür muss ich den halben Computer wieder zerlegen). Danach hoffe ich, den Fehler abgestellt zu haben. Denn wenn der Fehler dann noch besteht, muss ich wohl mein Schaltungsdesign noch einmal überprüfen.... Das wäre wirklich MIST!

Aber bevor ich jetzt zum Lötkolben greife, überprüfe ich zunächst einmal meine Prüfroutine... Es kann natürlich sein, dass die nicht fehlerfrei ist und dann hätte ich alles Andere umsonst gemacht.

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 734
Registriert seit: Apr 2014
Bewertung: 5
#92
28.06.2019, 15:48

Also...

die Routine ist in Ordnung. Keine Fehler im Programm gefunden. Extra noch einmal durch meinen Simulator gescheucht.
Also: Adressleitungen und Datenleitungen am RAM und am Prozessor nachgelötet und erneut getestet. Leider wieder der gleiche Fehler. Zumindest am Anfang. Als der Z80Ardu dann wärmer war (Terrasse, 30 Grad), war der Fehler weg. Ergo: Thermischer Fehler. Das muss ich mir noch einmal in Ruhe ansehen.

Trotzdem ist eines noch komisch. Wenn ich für den Stack eine hohe Adresse wähle, läuft der Mist nicht. Wähle ich eine Adresse im niedrigeren Speicherbereich, dann läuft alles stabil. Mir ist nicht bekannt, dass der Stack nich in einem hohen Speicherbereich liegen darf. Schließlich wird der Stackpointer beim Start des Z80 automatisch mit 0ffffx vorbelegt. Also der höchsten möglichen Adresse.

Vielleicht ist es auch ein Fehler im Prozessor selbst. Den werde ich also auch mal noch tauschen. Aber nicht gleich. Momentan habe ich den Prozessorstack einfach mit in einen Bereich innerhalb des Hauptprogramms gelegt. Dort habe ich einfach mal 160 Bytes mit NOP's belegt und das letzte Byte dieses Bereichs als Anfang für den Stack deklariert. Das Programm liegt also drumherum. Und das funktioniert erstmal, so wie ich mir das gedacht habe. Ob der Stack so groß genug ist, weiß ich nicht. Er lässt sich aber problemlos vergrößern.

Das Ende des verfügbaren Speichers lege ich jetzt mal auf 0D3FFx. Damit fehlen mir 3072 Bytes verfügbarer Speicher. Ab 0E000x fängt der Videospeicher an, dort kann ich sowieso kein Programm ablegen.

Ich mache also jetzt erst einmal mit meinem Programm weiter. :-)

Grüße,
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 734
Registriert seit: Apr 2014
Bewertung: 5
#93
27.10.2019, 18:49

Hallo zusammen,

hier war ja jetzt eine ganze Weile Ruhe. Klar, im Sommer hat man gerne mal etwas Anderes zu tun. Und zugegeben: Ich hatte auch keine Lust.
Es gab ein paar Rückschläge: Die Serielle Schnittstelle will einfach nicht funktionieren (obwohl das als Prototyp wunderbar geklappt hat.). Den Entwurf des IDE-Controllers habe ich verworfen, da das Programm nicht zur Hardware passt (Da habe ich jetzt etwas Neues, aber noch nix entworfen).

Und auch das Tastaturinterface macht Probleme. Vermutlich ist das Kabel zwischen Tastaturstecker und Platine zu lang. Ich hatte auch hier keine Lust, das mal zu prüfen und ggf. zu ändern.

Und letztlich habe ich dann auch am "Betriebssystem" nicht weiter gearbeitet.

Ich habe jetzt parallel zur funktionierenden Z80-Karte noch eine weitere gebaut. Damit teste ich jetzt neue Hardware. Ich müsste sonst immer wieder das Gehäuse vom Z80Ardu öffnen.

Bald ist's ja wieder dunkel und kühl und das ist dann genau die richtige Zeit, um mal wieder ein wenig zu basteln.

Grüße,
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 734
Registriert seit: Apr 2014
Bewertung: 5
#94
09.11.2019, 20:04

Hallo zusammen,

jetzt ist's draußen ja wieder dunkel, also kann wieder ohne schlechtes Gewissen gebastelt werden. :-)

Der Z80Ardu funktioniert ja prinzipiell. Das rudimentäre Betriebssystem funktioniert auch soweit. Dort sind die wichtigsten Routinen für die Ein- und Ausgabe implementiert. Zu Testzwecken habe ich eine zweiter Version des Z80Ardu gebaut, den ich auch wieder auf ein Breadboard stecken kann. So kann ich leichter neue Hardware testen.

Gestört hat mich im Grunde immer, dass ich mit der Kombination aus Atmega328 und dem SD-Kartenadapter lediglich ein Programm von der SD-Karte in den Speicher übertragen kann. Somit liegt dieser Teil der Elektronik nach dem initialen Laden eines Programms in den Speicher des Z80-Teils brach und oxidiert nur rum.

Ich habe nun folgende Idee:

Ein Atmega328 (oder irgendetwas Ähnliches) ließt per I²C (TWI) ein serielles EEPROM aus und legt die gelesenen Daten Byte für Byte auf den Datenbus. Gleichzeitig gibt ein 10-Bit-Counter (z.B. SN74LS491) eine Adresse auf den Adressbus. So kommt ein initiales Programm in den Hauptspeicher des Z80-Teils.

Gegenüber dem "alten" Design könnte ich die Latches (74HCT573) einsparen. Die Adresse würde der Zähler auf den Bus legen, die Daten dann der Atmega. Der Zähler wird vom Atmega gesteuert. Ich hätte dann genügend Pins frei um trotzdem per SPI eine SD-Karte anschließen zu können- Da keine Latches mehr da wären (die nur in eine Richtung funktionieren), könnte man Daten bidirektional übertragen und so vom Z80 aus die SD-Karte über den Atmega direkt ansprechen. Ich könnte mir dann auch meine IDE-Schnittstelle sparen (die, wie Ihr ja wisst, grandios gescheitert ist). Und ganz zum Schluss wäre es noch denkbar, das Tastaturinterface ebenfalls dort zu integrieren.

Ich muss das Konzept natürlich noch testen. Ich hatte heute bereits meine Schwierigkeiten, das EEPROM auszulesen (Es zu programmieren geht dank meines TL866ii Plus super schnell und einfach). Ich muss dann, wenn der Atmega alle Dienste soweit übernimmt, noch testen, ob das Zusammenspiel zwischen SRAM und dann später auch mit dem Z80 (als "Festplatte"). Da wird es sicher noch ein paar Timingprobleme geben.

Kurz zusammengefasst:
  • 3 Latches fallen weg
  • 1 10 Bit Counter kommt dazu
  • 1 Serielles EEPROM kommt dazu
  • Die SD-Karte dient als "Festplatte"


Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 734
Registriert seit: Apr 2014
Bewertung: 5
#95
09.11.2019, 22:02

Hallo zusammen,

ich schon wieder. Falls Ihr mein Geschreibsel hier verfolgt, dann erinnert Ihr Euch vielleicht, dass ich immer wieder Probleme mit dem Stack oder allgemein mit Speichezugriffen hatte, wenn dieser ab der Adresse $D000 stattfand:

(28.06.2019, 13:51)Unilein schrieb: Die Routine wird nun jedes mal, wenn ich meinen Z80Ardu starte/resette aufgerufen. Und jedes mal bekomme ich den Hinweis, dass bei Speicherstelle $D400 (Dezimal 54272) ein Fehler vorliegt.

Zunächst habe ich gedacht, der RAM-Baustein hätte einen Schlag und habe ihn mal ausgetauscht. Der Fehler besteht weiterhin! Jetzt fürchte ich eine kalte Lötstelle auf der Platine. Ich werde also die Adressleitungen und die Datenleitungen des SRAM und des Z80 noch einmal nachlöten (Dafür muss ich den halben Computer wieder zerlegen). Danach hoffe ich, den Fehler abgestellt zu haben. Denn wenn der Fehler dann noch besteht, muss ich wohl mein Schaltungsdesign noch einmal überprüfen.... Das wäre wirklich MIST!


Und jetzt weiß ich auch warum. Wenn ihr im Schaltplan einen Blick auf die Speichersteuerung für den Videospeicher werft (das sind die drei Gatter, ein Oder- und zwei Und-Gatter, dann fällt auf, dass das Oder-Gatter eine "1" ausgibt, wenn entweder die Adressleitung A12 oder die Adressleitung A13 an ist. Und das ist Falsch! Wenn nämlich A15, A14 und A12 an ist, dann haben wir die Adresse $D000. Der Videospeicher fängt aber bei $E000 an. Und dort sind wir, wenn A15, A14 und A13 an sind. A12 ist also für den Videospeicher gar nicht relevant!! Das bedeutet, dass ein Zugriff auf eine Adresse ab $D000 in den Videospeicher geht. Das MUSS ja schief gehen.

Aufgefallen ist mir das, weil ich gerade mal einen ersten Plan für meine im letzten Beitrag vorgestellten Anpassungen mache. Ob ich das ohne Weiteres korrigieren kann, weiß ich noch nicht. Für den Videospeicher werden 6144 Bytes benötigt, also speichertechnisch ein 8 Kilobyte-Block. Ich muss mal noch prüfen, wie sich das binär darstellt, damit ich prüfen kann, welche Adressleitungen tatsächlich benötigt werden.

Gruß,
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
Zitieren
Unilein
Fachgebiet Rauchentwicklung
*******

Beiträge: 734
Registriert seit: Apr 2014
Bewertung: 5
#96
10.11.2019, 19:04

Hallo zusammen,

in der vergangenen Nacht, so ab halb vier, noch einmal über das Konzept nachgedacht.

(09.11.2019, 20:04)Unilein schrieb: Ein Atmega328 (oder irgendetwas Ähnliches) ließt per I²C (TWI) ein serielles EEPROM aus und legt die gelesenen Daten Byte für Byte auf den Datenbus. Gleichzeitig gibt ein 10-Bit-Counter (z.B. SN74LS491) eine Adresse auf den Adressbus. So kommt ein initiales Programm in den Hauptspeicher des Z80-Teils.

...mit 10 Bit wird's für ein initiales Programm unter Umständen ein wenig eng. 10 Bit = 1024 Adressen =1024 Bytes. Ob ich darin ein Ladeprogramm für die Kommunikation mit einer "Atmega-Festplatte" unterbringe, wage ich zu bezweifeln. Der 10 Bit Counter ist also zu klein. Dodgy

Das ist natürlich insofern schade, weil ich dann wohl doch zwei Counter benötige. Zum Beispiel den 74HCT590, welcher ein 8-Bit-Counter ist (Die Idee ist nicht neu: https://micro-dev.de/showthread.php?tid=239).

Naja... Dann ist es eben ein Chip mehr. Die Latches fallen trotzdem weg.

Gruß
Uni
-----

Klopapier beidseitig verwenden und der Erfolg liegt auf der Hand!
(Dieser Beitrag wurde zuletzt bearbeitet: 10.11.2019, 19:29 von Unilein.)
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste