MC6802 läuft nicht

Am Tue, 30 Dec 2014 21:10:07 +0100 schrieb Johannes Bauer:

Wenn ich mich recht erinnere (es ist ja schon ein Vierteljahrhundert her), war der Grund die damalige Zugriffszeit der Speicher. Die Adressen

Das /OE wurde aus E und R/W geNANDet.

Immerhin hat der Motorola die Quarzfrequenz nur durch vier geteilt, lief also intern auf 1 MHz, nicht wie Intel mit Teilerfaktoren von 12 bis 15.

den 6808 nehmen, der hat keinen internen Ram, ist aber ansonsten identisch. Soweit ich mich erinnere, kann man auch Pin 36(RE) auf GND liegen, damit der interne Ram abgeschaltet wird.

eine Zeit abzuwarten. Allerdings benutzt Du ja den /Halt-Pin, da gab es

vom Atmel aus den HALT-Zustand des 6802 zu erkennen, da die Leitung BA

unkritisch.

Dann passiert beim Start folgendes: an den beiden Vektoren wird 0x0101

Vielleicht ist ja auch einfach der Prozessor defekt. In der 4ma im Keller habe ich noch ein paar Teile davon, auch PIAs und ACIAs, aufgehoben als stille Reserve, wenn mal einer kaputt geht. Aber die Dinger gehen anscheinend nicht kaputt, mir ist noch keiner ausgefallen. Wenn Du da was brauchst, lass es mich wissen. Meine Mailadresse funktioniert.

Sieht ungesund wie ein /CS am SRAM aus der zeitweise tristate geschaltet wird.

Ich hab die Orignalversion mal aufgepinselt:

Abgesehen von dem Fehler mit unbeschalteter E-Clock

eventuell auch auf low gepulst wird, wenn 6802 versucht das RAM zu schreiben. /WR und /RD gleichzeitig low ist nicht sinnvoll. Soll das RAM nur EPROM simulieren ?

MfG JRD

MfG JRD

Ah, interessant! Das werde ich auf jeden Fall jetzt gleich ausprobieren, klingt sehr gut. Auf jeden Fall muss der !OE Pulldown raus.

Einen Adressdecoder brauche ich nicht, in meiner Testapplikation gibts kein EPROM -- liegt alles dekadent im RAM :-)

in meiner Debugging-Applikation ein MC6802 mit RE = LOW. Die Dinger

SRAM einfach als 6808 gelabelt).

Ja, eine Millisekunde. Der AVR und 6802 wechseln nicht schnell hin und her, das liegt im Sekundenbereich. Da macht die Millisekunde keinen Unterschied mehr.

Hmmmmm. Das ist eine sehr coole Idee! Der RAM ist zwar nicht gesockelt (SMD), ABER: Ich habe da ja nen AVR drin. Das kann ich in Software machen, wenn ich den CS vom RAM ausknipse, den 68 auf dem Bus lege und PORTA vom AVR als Ausgang nehme :-)

Ich glaube schon eher dass ich einfach nur nicht verstanden habe, wie der richtig zu beschalten ist. Aber ich glaube langsam komm ich dahin. Werde mal den NOP-Test machen und dann seh ich ja was passiert.

Johannes

richtig(tm) und dann schaue ich, was passiert. Werde auch Andreas' Tipp

Bin schon sehr gespannt und melde mich wenn's was Neues gibt.

Finde es auf jeden Fall ziemlich cool dass man hier Leute findet die sich mit der Technik von damals noch auskennen :-)

Johannes

Ja, ich will sowohl mit internem RAM als auch ohne internes RAM testen. Vorerst erstmal mit internem RAM deaktiviert (RE = LOW).

Doch, die sind verbunden -- alle Netze, die benamt sind, sind verbunden.

Ja, der AVR ist definitiv Tristate, bevor der 68 den Bus bekommt.

Schreib- und Leseleitung sind direkt durchverbunden (PG1 = !RD, PG0 = !WR).

Ja, klar :-)

"Hello World" auf den Stack pushed und dann in eine Endlosschleife geht.

Johannes

Aha!

aktiv sind, liegt 0xfffe auf dem Adressbus.

1. Dann lasse ich RESET los. Der 6800 liest erst von 0xfffe und danach von 0xffff (Reset-Vektor). Daten sind konstant 0x01

Adresse 0x0101 los

einmal bei 0x5085 weiter!

Johannes

Ohne aktuellen Stromlauf wird das schwer zu erraten sein.

Man sollte das Ding mit /RES starten.

Floatende Pins suchen. Z.B. /IRQ und /NMI. Bzw. den Test wiederholen um zu sehen ob das Verhalten reproduzierbar ist.

MfG JRD

Am Wed, 31 Dec 2014 15:07:44 +0100 schrieb Rafael Deliano:

/IRQ macht nichts, der ist ja nie freigegeben worden. Und ein /NMI holte sich seinen Vektor 0x0101 ab, aber der beschriebene Sprung ist durch

Das auf jeden Fall. Ist denn der Atmel garantiert friedlich in der Zeit?

und Windows Schluckauf hat. Low tech mit Oszillskop stolpert man in manche Problem nicht rein.

MfG JRD

Ja, der hat damit gar nichts mehr am Hut, sobald er die Kontrolle abgegeben hat.

Stimmt. Ist aber auch wirklich so: Habe gerade mit dem Oszi nachgemessen, beim NOP-Test ist R/!W und VMA permanent HIGH.

Und die Glitches waren, wie Rafael richtig vermutet hat, ein Bug in der Acquisition-Software :-( Das Ding tut sein NOP einwandfrei, aber mit dem Memory will es nicht.

Johannes

Volltreffer. Obowhl ich hier kein Windows einsetze.

ich das Capture speichere und wieder lade habe ich diese seltsamen Glitches :-(

Wenn ich die gecapturten Daten direkt erfasse, dann sieht da alles

Habe jetzt auch mal den Clock runtergedreht auf 500kHz, aber mit dem RAM will er immernoch nicht.

Johannes

an der Software lag :-(

Nur mit dem RAM spielt es nicht zusammen.

Johannes

Datenblatt ansehen kann.

MfG JRD

S*it, sorry -- ich dachte das steht im Schaltplan. Tut es nicht.

Es ist ein EliteMT LP621024DM-70LL.

liest und versucht 0x00 zu schreiben. Werde mir mal den 245 genauer

Johannes

Da es ein 128kByte RAM ist: ist sichergestellt

MfG JRD

Ja, A16 wird immer vom AVR bedient und bei 6800-Betrieb auf LOW gezogen.

RAM-Seite und auf 6800-Seite passiert:

!CS = !VMA. !RD = R NAND E !WR = !R NAND E

Habe auch mit dem Oszi draufgeschaut, sieht alles ok aus.

Sektkorken knallen :-)

Johannes

Hier ist das 6800 und 6802 Timing nochmal durchgekaut:

Es sind glitche drinnen die von der Verwurstelung mit E kommen:

CPU 10nsec Hold aber moderne RAMs sind schneller und dieses hat 0 ... 25nsec im Datenblatt.

bei NMOS ist das nicht so einfach.

Wenn es nur um reinen Lesezugriff a la EPROM ginge

MfG JRD

das sehr knapp gehalten.

Also nur nochmal langsam, damit ich es wirklich richtig verstanden habe: Das kritische Timing ist t_DHR (Read Data Hold Time, im Datenblatt als [18] bezeichnet). Das muss >= 10ns sein.

Jetzt habe ich mir das auf dem LA nochmal genau angesehen. Bei der H->L Transition von E sehe ich aber auf dem Datenbus gar keine Action:

bis die Daten das "flackern" anfangen.

Habe noch ein Paar weitere Tests gemacht. Zum einen Mal ein RAM komplett

prima (soweit ich das beurteilen kann), selbes Verhalten wie wenn der AVR permanent 0x01 anlegt.

Soll also einen Stackpointer laden und dann 0xab, 0xcd, 0xef, 'H', 'e', 'l', 'l', 'o' auf den Stack pushen. Das "Hallo" wird dynamisch zur Laufzeit generiert.

hin soll. Es landet irgendwie bei 0x74ff statt 0x5ff. Wenn ich die

Ich stimme dir zu, dass das sicherlich ein Timing-Problem ist. Aber von

Mann ist das frustrierend. Du hattest echt recht, dass die letzten 10%

Johannes