www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit 6502 uP


Autor: Benedikt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir eine Schaltung mit einem alten 6502 uP aufgebaut und wollte
damit ein paar einfache Programme laufen lassen.
An sich funktioniert auch alles, nur bei jedem Rücksprung aus einem
Interrupt hängt sich der uP auf.

Den Signalen nach passt aber alles.
Die Aufzeichnung des Logikanalysers beginnt in Zeile 30 des
Quellcodes.
Man sieht wie der uP den JSR Befehl läd, den Adresszähler auf den Stack
legt (= in den SRAM schreibt), das Unterprogramm ausführt und dann den
Rücksprungwert vom Stack holt.
Danach macht er aber seltsamerweise an irgendeiner anderen Stelle im
Programm weiter. Das angeschlossene LCD initialisiert und zeigt
"Hallo" an.

Autor: Benedikt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die vom Logikanalyser aufgezeichneten Signale

Autor: Benedikt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und das Programmlisting

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kriege Programm, Text und Schaltbild nicht in Deckung.
- Im Text wird ein Interrupt erwähnt. Im Listing kann ich aber nichts
davon erkennen.
- Im Listing wird ein LCD angesprochen, dass wiederum im Schaltbild
nicht auftaucht.

Ist hoffentlich ein 6502A, sonst keine 2MHz.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Schaltung: Traditionell wird beim 6502 der andere Takt, also phi2
(Pin 39), als Strobe verwenden, nicht phi1 (Pin 3). So steht's auch im
Rockwell Datasheet.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der uC hängt sich bei jedem Rücksprung auf, egal ob Interrupt oder
normale Subroutine.
Ja, es ist ein 6502A, der allerdings langsamer getaktet ist, damit das
LCD auch ohne Busy Abfrage initialisiert.
Aber auch mit 1MHz habe ich diesselben Probleme, nur das zusätzlich auf
dem LCD eben nichts erscheint.
A0 vom LCD ist A0, RW ist RW und Enable ist eine NAND Verknüpfung des
CS (=Pin11 des HC139) mit phi1.

Ich hatte Anfangs phi2 verwendet, dieses Signal invertiert (da es Low
aktiv sein muss) und dann in den HC139 eingespeist, aber da der uP das
Signal ja bereits invertiert liefert, habe ich den Inverter
weggelassen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ZPDATA = $8000  ;zero-page data area

Ist das zur gezielten Verwirrung des Lesers gedacht? Den Anfang vom ROM
als data area und dann auch noch also zeropage zu bezeichnen?

Wenn das LCD ein üblicher HD44780 ist, dann fehlen im Code sämtliche
Delays - der braucht ja 50µsec pro Zeichen und einiges mehr in der
Initialisierung.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit dieser Code ohne Delays funktioniert, müsste die CPU mit 1KHz
(1000Hz) oder so getaktet werden. Was wiederum ausserhalb des erlaubten
Bereichs liegt.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das

0067    FFFC               *= $fFFC;Rest Vektor
0068    .DB $00
0069    .DB $80
0070    .DB 12
0071    .DB 13

Reset- und Interrupt-Vektor sein sollen, das landet der Interrupt auf
Adresse $0D0C. Ist das korrekt?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß, laut Datenblatt muss der 6502 mit mindestens 50kHz laufen.
Der 6502 lief für diese Aufzeichnung mit 400Hz. Allerdings scheint das
kein Problem zu sein, ich hatte auch schonmal ein LED Display
angeschlossen das langsam hochzählte, und da lief der 6502 mit 5Hz.
Ich habe dasselbe aber auch mit 100kHz gemacht, mit Delays da passiert
genaus dasselbe: der uC macht den Rücksprung irgendwo dahin, wo kein
Code steht.
Nur die Aufzeichnung ist dann als Bild keine 3400 Pixel breit, sondern
irgendwas >50000, und das kann ich hier wohl kaum posten...

Das mit zeropage ist noch ein Rest vom alten Programm, das mit
Unterprogrammen wie PutString arbeitet.
Der ROM beginnt bei $8000 und das ist eigentlich das einzig wichtige,
das der Assembler auch richtig umsetzt:
.org $8000

0067    FFFC               *= $fFFC;Rest Vektor
0068    .DB $00
0069    .DB $80
0070    .DB 12
0071    .DB 13

FFFC ist der Reset Vektor
$00 und $80 sind die Startadresse des eigentlich Programms, das der uC
auch richtig startet
12 und 13 sind nur Testwerte, um zu sehen ob der uC nicht diese Adresse
beim Rücksprung läd. Den Interrupr verwende ich erstmal nicht,
(vielleicht später einmal wenn der uP richtig läuft...)
Aus genau demselben Grund habe ich auch hinter RTS ein paar weitere
Werte geschrieben, um zu sehen ob der 6502 einfach weitermacht.

.DB 10
.DB 11
.DB 12
.DB 13

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> nur bei jedem Rücksprung aus einem
> Interrupt hängt sich der uP auf.

> Den Interrupr verwende ich erstmal nicht

Lies: Beim Rücksprung aus dem nicht verwendeten Interrupt hängt er sich
auf. Hmm.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte doch zuvor schon geschrieben, dass er sich bei jedem
Rücksprung aufhängt, also nicht nur beim Interrupt, den ich daher
blockiert habe, da es das sichere Ende des Programms wäre, wenn ein
Interrupt auftritt.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schoen kurios. RTS ok, kriegt auch die richtigen Daten, landet aber an
$E1Fx. Kann ja nur heissen, dass der die Daten nicht korrekt verdaut.
Hänge doch mal OE vom SRAM direkt an die R/W Leitung - evtl. Hold-Time
Problem. Was für ein 6502 ist es den wirklich genau? Ggf BE bedienen,
falls das einer ist der damit was anfängt.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hänge doch mal OE vom SRAM direkt an die R/W Leitung

Naja, Inverter muss schon sein. Will aber den Takt mal da weg haben.

Was ist das für ein RAM?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommst du darauf, dass er an  $E1Fx springt ?
Ich würde eher sagen, er springt an $FC35, was aber genauso falsch
ist.
Der uP läd 00 als Befehl, das ist BRK.
Daher schiebt er wiederrum den Programmcounter auf den Stack und
springt zu der an FFFE und FFFF angegeben Adresse, in meinem Fall
$8100
Dahin habe ich ein RTI geschrieben.
Auch bei diesem Rücksprung ändert sich wieder die Adresse...
Jedesmal wenn ich das Programm laufen lasse, springt er andere Werte
an.
Wirklich seltsam.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der BRK Befehl speichert erst PCH, dann PCL+2, dann das Statusregister.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee mit dem RW direkt an OE war goldrichtig !
Damit gehts.
Aber nur wenn RW über einen Inverter alleine am SRAM liegt.
Hänge ich auch OE des EPROMs (eigentlich auch ein SRAM das von einem uC
mit Daten geladen wird) dran, geht es wieder nichtmehr...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich weiterraten soll, dann musst Du mal mit konkreten exakten
Bezeichnungen rausrücken. Von CPU,RAM,"ROM".

Autor: Benedikt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
uP:    MOS6502AD, 42.KW 1985 (läuft im Moment mit 60kHz)
SRAM:  IDT7164S
EPROM Simulator: CL63C256 über 74HC245 in den Daten, Adress und
Steuerleitungen.

Jetzt bleibt der uC nur noch beim Lesen des Busy Flags vom LCD hängen,
da dieses genauso gelesen wird, wie der SRAM.

Ich habe noch die komplette Schaltung mit LCD angehängt, so wie sie im
moment aufgebaut ist.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre mal interessant, mit einem Oszi die Phasenbeziehung zwischen phi1
und phi2 zu ermitteln. Wie schon gesagt, alles aus den 68xx und 65xx
Familien benutzt phi2 (aka E bei 68xx - rate mal warum das beim LCD so
heisst). Phi1 wurde bei den 65xx kaum je verwendet. Das Datasheet ist
an dieser Stelle auch nicht grad deutlich, nur bei den extern
versorgten Versionen 651x sind die Phasen genau spezifiziert.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie ich das Datenblatt verstanden habe, werden die Daten genau am
Ende des Taktzyklus gelesen (also genau dann, wenn OE\ schon wieder
auf High Pegel geht, d.h. mein Speicher ist zu schnell)

Benötige ich eigentlich überhaupt den Takt Phi x als Bestandteil des WR
oder RD Signals ?

Bei dieser Schaltung wird der Takt garnicht verwendet:
http://www.hytherion.com/beattidp/comput/x65tools/...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Speicher-Ansteuerung von meinem alten AIM65:

Die ROMs haben kein OE, CS leitet sich ausschliesslich von den Adressen
ab. Das war bei 65xx/68xx durchaus üblich.

Bei den RAMs (2114) ist ein invertiertes phi2 am enable vom CS-Dekoder,
WE ist einfach nur ein gepufferted R/W. Also CS controlled write. OE
gibt's nicht. Freilich: die RAMs sind "etwas" langsamer als dein
IDT, hold time Problem sind schon deswegen ausgeschlossen.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, dann werde ich alle OE\ ohne Takt laufen lassen (Adresse dekodieren
und an CS\, RW invertiert an OE\, RW mit Phi1 verknüpft an WE\)

Lege ich den dekodierten CS an Enable des LCDs und RW an RW, dann läuft
alles, aber so wirklich gefällt mir die Lösung nicht...
Mir wäre irgendein Schutz lieber, denn für einigen 10ns sind die
Adressen sowie RW undefiniert.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Benötige ich eigentlich überhaupt den Takt Phi x als
> Bestandteil des WR oder RD Signals ?

Nicht zwingend. Die Schaltung im Link ist ziemlich typisch für einfache
Systeme. Bei leidlich kurzem Kabel dürfte auch der Treiber vor dem LCD
nicht notwendig sein.

Das war ja der Charme vom 6502 in den Hobby-Microcontrollern der 80er.
Fast keine glue logic. 6504,6532,EPROM, 1 Inverter fürs CS vom ROM, 2
weitere Inverter für den Taktoszillator und fertig war ein Controller
mit 4KB EPROM, 128 Bytes RAM, 16 I/Os und 1 Timer.

Nebenwirkung diese etwas eigentümlichen Busses: Es finden ab und zu
auch Lese-Zugriffe auf falsche Adressen statt. Weil: es gibt keinen
Zyklus ohne Zugriff, und wenn die Adressrechnung einen Übertrag
produziert, dann gibt's erst einmal den falschen (Lese-)Zugriff, dann
den richtigen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nicht zwingend. Die Schaltung im Link ist ziemlich typisch für
> einfache Systeme.

Wobei da allerdings an RAMs von 250-450nsec gedacht war. Keine übrig
gebliebenen Cache-RAMs die jeden Glitch zum kompletten Zyklus erklären.
WE sollte also schon mit phi2 verknotet sein.

> Mir wäre irgendein Schutz lieber, denn für einigen 10ns sind die
> Adressen sowie RW undefiniert.

Nur relevant für Peripherie, die ein "zerstörendes Lesen" kennt.
Ansonsten: na und?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hilfe !

Ich habe die Schaltung jetzt mit OE\ ohne Takt und WE\ mit Takt
umgebaut. CS\ wird durch die Adresse bestimmt.
Damit läuft die Schaltung mit dem LCD jetzt auch bei 2MHz.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.