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:
formatting link
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 ?
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
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Kosmologen: Die Geheim-Vorhersage.
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
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Kosmologen: Die Geheim-Vorhersage.
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:
formatting link
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%
90% der Zeit kosten :-/
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Kosmologen: Die Geheim-Vorhersage.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.