Junior Computer ][

Hallo Zusammen,

FRAGE AN ALLE 6502 EXPERTEN !!!!!

---------------------------------------------------

Ich hatte letzte Woche mit der Portierung des XModem Codes begonnen, und dabei sind mir ein paar ziemliche Merkwürdigkeiten aufgefallen.

Um Unterroutinen im ROM zu testen, wollte ich sie via JSR aus einem kleinen Programm im RAM aufrufen. Dabei hat sich das System jedesmal vollständig aufgehängt. Nach einem Reset war dann mein Code im RAM modifiziert. Tests mit JSR vom RAM ins RAM crashten genauso. Als Beispiel:

300h : 60 - RTS

200h : 20 00 03 - JSR 0300

203h : 4C 1D 1C - JMP 1C1D ; 1C1D ist die Reset Routine des Junior Monitors

nach einem Sprung zu 200h chrased der Rechner und ab 200h steht dann dort

200h: 20 00 02

oder anders ausgedrückt: Das zweite Adress-Byte des JSR Befehls beinhaltet nun das höherwertige Byte der Adresse des Aufrufenden JSR Befehls.

Das sieht für mich so aus, als ob hier das Speichern der Rücksprungadresse auf den Stack völlig schief geht.

Ebenfalls waren immer mal wieder seltsame Ausgaben auf dem Terminal zu beobachten. Statt einer Hex-Zahl wie z.B. 5B wurde dann sowas wie 5H angezeigt. Ich hatte zuerst meine 6551 von 1983 in Verdacht, aber nach einem Tausch hatte ich ebenfalls immer wieder mal solche Ausgabeergebnisse.

Nach einigen Test stellte sich dann heraus, dass die UM6502CE CPU, die ich bei Mükra besorgt hatte der Übeltäter ist. Diese ist nämlich wie ich auch an dem CE hätte sehen können, wenn ich es gewusst hätte, tatsächlich eine 65C02. Eine Rockwell 65C02P2 macht bei mir den gleichen Ärger.

Ich vermute, dass es tatsächlich ein Timing-Problem mit den CMOS Versionen gibt. Auch gibt es bei den NMOS Versionen leicht verschiedene Read/Modify/Write Zyklen. Verstehen tu ich es aber trotzdem nicht, da es im oben stehenden Code faktisch nicht zu irgend einer Adressumschaltung mit den Adressdekodern kommt. Die CPU liest und schreibt alles im unteren KB, in dem sich auch der Stack befindet. Trotzdem wird die Sprungadresse modifiziert - STRANGE!!!!

Weiss jemand, was hier die Ursache sein könnte?

Quote from tante ju

Wie bekommst Du das Programm rein? Der Stack liegt ja bei 0x01.. und wächst rückwärts also von 01ff -> 0100. Also selbst wenn da ein Adressbit zu langsam wäre, schreibt der nicht nach 0202. Könnte da was am Datenbus sein?

Das Problem tritt auch in höheren Speicherbereichen (z.B. 4000h) genau so auf. Ich hatte es aber extra nochmal im unteren KB getestet, weil da kein switching des Adressbuss-Dekoders entsteht. Ich hatte auch schon an eine zu hohe Last am Datenbus gedacht. Aber alle meine "normalen" NMOS 6502er laufen völlig problemlos. Die anderen CMOS spacken genauso rum. Es wird auch immer nur das zweite Adress-Byte geändert also:

3100 : 20 00 03 wird zu 20 00 31 oder 2B00 : 20 00 03 wird zu 20 00 2B.

WTF.

Quote from mesch

Ich sehe da keine CMOS-CPU.

Allerdings haben die E-Varianten im Timing wohl Unterschiede zu den Versionen ohne E-Kennung.

Da müsste man genauer in beide Datenblätter reinschauen. Es sind aber m. M. nach keine CMOS-CPU's.

Das macht es für mich noch seltsamer. Hast du Informationen, wie hoch die Last an den Ausgängen der UM6502CE sein darf?

Quote from tante ju

Welche CMOS-Typen hast Du getestet? Die aus den 80ern oder moderne?

Rockwell von 92 und 94

Quote from Reinhard

Viele alte Schaltungen (KIM z.B.) beziehen nicht Phi2 in den Adressdekoder für das RAM ein.

da gebe ich dir Recht. Da ich den Junior 2 auf Basis des original Junior aufgebaut habe, gibt es weder Bustreiber noch eine besonders saubere Busarbitrierung bzgl. Phi2. Die fehlende Verknüpfung mit der High-Phase von Phi2 ist mir auch schon in den Sinn gekommen, da die CMOS 6502er eine schnellere delivery time der Adressen haben als ihre NMOS Kollegen, und bei einem Adresswechsel das RAM noch im Schreibmodus sein könnte. So wie es aussieht, scheint es dann aber wohl auch die schnelleren NMOS Versionen wie die UM6502CE, die ja laut mesch 's Datenblatt eine 4MHz Version ist, deutlich mehr zu Interessieren. Ich werde das mal mit dem Logicanalyzer angehen.

Wie auch immer, ich werde das Design wohl schon aus historischen Gründen nicht mit Bustreibern versehen weil sonst nicht mehr viel vom Original übrig bleibt. Aber eventuell findet auf einer neueren Version mal noch ein zusätzliches 74LS00 seinen Weg auf die Platine um das Problem zu beseitigen. Solange gilt also, alte MOS, Rockwell oder ST CPUs zu verwenden.

Quote from mesch

Wenn ich so in den Schaltplan schaue, müsste es doch reichen den CS2-Anschluss des 128KB RAMS von +5V zu trennen und mit Phi2 zu verbinden. Dann sollte das RAM nur in der Phi2-High Phase selektiert sein.

...da kann man mal sehen, wie blind man wird, wenn man immer das offensichtlichste vor Augen hat . Sehr gute Idee, Danke!!!. Allerdings ist Pin 30 auf der Platine auch das Via für die +5V Versorgung zum ROM. Cutten geht also als Patch erst mal nicht so einfach, ich schau aber nach Alternativen und probiere das ganze mal aus. Zuerst mal gibt es halt einen Zwischensockel mit rausgebogenen Pin.

Hatte eher daran gedacht, die Versorgung für das (E)EPROM vom Port-Connector Pin 1 hoch zu ziehen. Dann muss ich nur an Pin 30 des RAMs die Leitungen auf beiden Seiten trennen und kann direkt von Lötpad zu Lötpad eine Patchleitung ziehen. Ich werd aber trotzdem erst mal mit Zwischensockel testen, nicht dass das alles womöglich gar nichts bringt und der Wurm noch woanders sitzt.

SUCCESS!!!

Das Problem ist jetzt natürlich, dass die 32KB RAM Alternative gestorben ist, da 62256 kein zweites Chip Select besitzen. Empfinde ich aber nicht als tragisch

...und die 65C02er laufen auch. Das hat eventuell auch das alte Problem mit dem Original Junior Editor erschlagen, den ich immer auf die Nutzung von ungenutzten Opcodes für die Adressmarker zurückgeführt hatte.. Muss mal schauen, ob ich den Fehler von damals irgendwie reproduziert bekomme. Aber Hauptsache das JSR Problem ist vom Tisch.

Quote from Reinhard

Schade übrigens, dass die KIM-1 Macher damals ihr eigenes Datenblatt nicht gelesen/verstanden haben...

Der KIM 1 war da glaube ich auch eher eine Machbarkeitsstudie von MOS. Schon allein die Tatsache, dass die ROMs der 6530er genutzt wurde deutet auf das Prinzip "keep it simple stupid!" hin. Das Chuck Peddle allerdings Stephan Wozniak wegen seines "schlechten" Apple 1 Designs zusammengestaucht hat, ist tatsächlich in Anbetracht des KIM1 schon witzig. Mag trotzdem beide Rechner seeeehr gerne . Übrigens ist beim Apple 1 Phi2 sauber mit R/W verknüpft.

Hallo klaly , Reinhard hat es genau auf den Punkt gebracht.

Das bei mir aufgetretene Problem ist dadurch entstanden, dass es bei einem Jump To Subroutine Befehl zwischen dem Lesen des Befehls und dem Schreiben der Rücksprungadresse auf den Stack, einen Adresswechsel gibt. Die Adresse sollte (darf) nur während der High-Phase des Takt-Signals Phi2 als Stabil betrachtet werden. Das ist beim Junior Computer (und bisher leider auch bei meinem Junior 2) nicht garantiert. Deshalb gibt es bei den schnelleren CMOS und NMOS Versionen der 6502 (ab vermutlich 2MHz und schneller) ein kurzes Zeitfenster, in dem die Schreib-Daten für den Stack auf der Lese-Adresse des JSR Befehls am Datenbus anliegen und dort dann den Programm-Code überschreiben.

Die einfachste Lösung der fehlerhaften Busarbitrierung ist jetzt, den Chip-Select-2 Eingang des 64KB oder 128KB großen RAM-Bausteins mit dem Phi2 Takt zu verbinden. Hierdurch wird der Speicher dann nur während der gültigen Adress-Phase (Phi2 = High) des Taktes selektiert, und das Problem hat sich erledigt.

Allerdings konnten beim Junior 2 bisher noch alternativ auch kleinere statische Speicher (6264 - 62256) eingesetzt werden. Diese haben aber in ihrem 28 poligen Gehäuse keinen zweiten CS Eingang und sind für diesen Patch also nicht geeignet. Für die kleineren Speichertypen müsste dann /CS1 mit Phi2 verknüpft werden, also /CS1 = /PHI2 & /RAM_SEL , was dann am sparsamsten mit einem zusätzlichen 74LS00 4-fach NAND gelöst werden könnte.

Die Änderungen für die größeren Speicher werde ich morgen gleich im Layout einpflegen, 32KB Speicher oder kleiner werden dann nur noch mit 1MHz NMOS CPUs funktionieren. Das ist glaube ich verschmerzbar.

Für die bisherigen Platinen mache ich euch dann einen kleinen Patch-Plan fertig.

Danke nochmal an Reinhard und mesch für ihre zielführende Unterstützung!

BG

Jörg