Timing

… on the way back to munich, we had some time to do a little code review of our gfx library. thinking about the cpu to video chip timings and again read the well known datasheets of the V9938/V9958. suddenly i got an enlightenment and we came to the following conclusion.

as described in the datasheet (V9958-Technical-manual_v1.0.pdf) of the V9958 there are different timings given for different kind of writes. so as far as we understand there are the following timings

Inzwischen sind die 74F00 eingetroffen und der 74HCT00 durch einen ebensolchen ersetzt. Das Oszilloskopbild sieht gleich deutlich besser aus:

gelb: /WE, blau: A9

Der Schreibvorgang wird also jetzt zumindest abgeschlossen, bevor sich die Adresse auf dem Adressbus ändert. Das ist schonmal viel sauberer.

Nur leider hat es das Problem nicht gelöst, das Steckschwein läuft mit den “richtigen” RAMs immer noch instabil, was sich insbesondere bei BASIC-Programmen bemerkbar macht:

Auf dem VCFe 18.0 gab es Dank Nick Müller die Möglichkeit, das Steckschwein mal mit einem Logic Analyzer “für große Jungs” zu untersuchen. Unsere USB-Logic-Analyzer sind zwar für vieles gut, aber um komplett Adress- und Datenbus sowie einschlägiger Steuerleitungen abzuhorchen, fehlen einfach Kanäle, und selbst dann wären sie nicht schnell genug.

Das Steckschwein am Logic Analyzer. im Hintergrund Nicks Finger.

Die Gelegenheit, ein solches Höllengerät (genauer: ein HP 1652B) und mit Nick auch noch jemanden greifbar zu haben, der selbiges beherrscht, gibt uns die Chance, ein merkwürdiges Problem zu untersuchen, welches schon länger Rätsel aufgibt: Die aktuell verwendeten Hyundai-SRAMs sind mit einer Zugriffszeit von 100ns eigentlich viel zu langsam für 8MHz, zumal der 6502 ja nur die 2. Takthälfte für Buszugriffe nutzt. Diese ist nur 62,5ns lang. Von dieser Zeit geht ausserdem noch die Durchlaufzeit der Adressdekodierung und weiterer Glue-Logik ab. Eigens angeschaffte neue SRAMs von Alliance Memory mit 55ns Zugriffszeit sollten also ganz knapp schnell genug sein. Trotzdem treten mit diesen immer wieder merkwürdig zufällige Abstürze auf, die 100ns-Chips laufen dagegen problemlos.

So langsam geht es weiter mit der Steckschweinentwicklung.

Die Timingprobleme mit dem VDP bedürfen einer eingehenden Prüfung und Messung, um genau zu verstehen, wo was nicht passt. Unsere Ideen mit Puffern und/oder versetzten Taktsignalen, um den VDP früher “kommen” zu lassen stellen wir zurück, bis wir gesicherte Erkenntnisse haben. Ein Herumdoktern aufgrund von Vermutungen halten wir nicht für zielführend. Vorher ist es auch nicht sinnvoll, irgendwelche Platinen zu löten.

Stattdessen stecken wir ein wenig Hirnschmalz ins aktuelle Design. Die Anbindung des UART fällt negativ auf. Hier wurde der Ansatz von Andre Fachat quasi 1:1 kopiert, sodass der GAL die Signale /RD und /WR für den UART abhängig von PHI2 und der angelegten Adresse erzeugt, während PHI2 ausserdem an CS1 des UART anliegt. Das funktioniert, fügt sich aber nicht ganz in unser Design ein.

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.

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.