Hold-Time-Violation

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.