Nach dem VCFe ist erstmal nicht viel aktive Entwicklung passiert. Vielmehr haben wir die Erkenntnis, dass wir ein grundsätzliches Timing-Problem haben (danke nochmal an Udo Möller) ein klein wenig sacken lassen. Im Grunde genommen ist es so, wie es sich aus dem vorletzten Post schon herauslesen läßt. Der WDC 65c02 hat eine Data Hold Time von 10ns, während der TMS9929 30ns braucht, sein Zeug vom Bus zu holen. Die verwendeten 16550er UARTs auch. Eine klassische Hold Time Violation also. Ein bisschen muss man sich da schon wundern, dass das Zeug überhaupt funktioniert und so erklärt sich auch der ein oder andere staunende Blick auf dem VCFe. Simon schlägt vor, das Projekt “Bumblebee” zu nennen, da Hummeln bekanntlich rein physikalisch gar nicht fliegen können, es aber dennoch tun, weil ihnen Physik total egal ist.

Nachdem das Timing vom Steckschwein grundsätzlich passt, sind auf einmal auch sämtliche Voodoo-Fehler verschwunden.

Jetzt lässt sich der VDP auch besser ansprechen, allerdings gibt es schon noch ein paar Probleme zu lösen, bspw. ist das DRAM sehr instabil irgendwie flackert ständig der Screen oder die Zeichen “Nullen” sich aus. Wir untersuchen das Steckbrett und die Spannungsversorgung. Wir beschließen, die Steckbrettkabel durch kurze blanke Drahtbrücken zu ersetzen und platzieren direkt am Vcc der einzelnen DRAMs die Abblock-Kondensatoren mit 100nF. Genauso die Spannungsversorgung des VDPs, hier auch nochmal kurze Drahtbrücken verwenden und einen Abblock-Kondensator direkt an Vcc vorsehen.

In den Posts http://8bit-gefriemel.blogspot.de/2014/03/murphy.html und http://8bit-gefriemel.blogspot.de/2014/04/murphy-ii.html sind einige merkwürdige Phänomene und deren Lösungsversuche geschildert. Wie sich heute gezeigt hat, konnten wir gar nicht weiter daneben liegen.

Alles Quatsch. Die Fehlersuche nach dem “K”-Problem. Stack und so. Alles super. Klar, das mit dem Initialisieren des Stackpointers war natürlich richtig und wichtig, und dass die uart_tx routine besser funktioniert wenn man auf Stack-Operationen verzichtet, hätte uns eigentlich eher stutzig machen sollen. Aber der Reihe nach.

Damit Klarheit darüber herrscht, worum es überhaupt geht, haben wir den Schaltplan in die einzelnen Gruppen (Prozessor+ Freunde, Speicher, UART) zerlegt.

Die aktuelle Stückliste liest sich laut Eagle folgendermaßen:

Der 65c02-Prozessor nebst Oszillator und RESET-Schaltung, welche aus dem Commodore-PET übernommen wurde und dem GAL, der zu Dekodierung des Adressbereichs von $8000 bis $ffff dient. Nicht zu sehen ist der Pull-Up-Widerstand für die BE (Bus Enable)-Leitung der WDC-Variante des 65x02, ohne den der Prozessor in einen Tri-State-Zustand geht und sich vom Bus abkoppelt.

Die Programmierung eines Computers, der nur aus einer gesteckten Schaltung besteht und weder Tastatur noch Speichermöglichkeit hat, ist eine mühsame Angelegenheit. Die allerersten Experimente bekamen ihr Futter auf einem 27128-EPROM serviert. Bekanntlich wollen diese vor dem Beschreiben mit neuem Code mit UV-Licht gelöscht werden. Also wurde für jedes Update ein EPROM mit neuem Code gebrannt, um die EPROMS anschließend in 10er-Packen ins Löschgerät zu schieben. 15 Minuten Kaffeepause.

Überhaupt, Code: Für die ersten Experimente hat es genügt, die reinen Hexcodes in einen Hexeditor zu tippen und die Daten dann zu brennen. Dies war vertretbar, da die ersten Programme etwa so aussahen: EA EA EA EA EA EA EA EA C9 C9 C9 C9 C9 C9 C9 C9 4C 00 0E

Flugs also ein ROM gebrannt mit der memtest-routine, in die nach der Reset-Routine eingesprungen wird. Gleiches Ergebnis. Beim ersten Auftreten des “K statt OK”-Fehlers ist erstmal die doch etwas windig anmutende Verdrahtung der Adressleitungen zwischen Prozessor, den RAM-Bausteinen und dem ROM mit “richtigen” Steckbrettstrippen statt Klingeldraht nachverdrahtet worden. Das war vermutlich etwas voreilig, schließlich hats vorher ja auch schon funktioniert. Schließlich stellt sich heraus, dass sich hier in der Tat ein paar Fehler eingeschlichen haben, die auch beim Durchklingeln der einzelnen Adressleitungen nicht aufgefallen sind: Kurzschlüsse.  Nachdem diese behoben wurden, läuft unser Speichertest auch wieder komplett durch.  Zeit also, sich dem eigentlichen Problem anzunehmen. Wo bleibt das “O”? Interessanterweise scheint das Empfangen von Daten nicht betroffen zu sein, denn die memtest-Routine funktioniert hochgeladen genauso wie aus dem ROM.  Also schaue ich mir die Routine an, die Daten (bytes) über den UART sendet.