Beta-Test: Labman

[cm]

Nur zum Test: Beiliegendes ZIP entpacken, auf SD-Karte kopieren und INI-File starten. Benötigt externes 32 KByte SRAM wie auf/oder gleich die DACRAM-Karte und FPGA-Firmware ab Version 2.33. Viel Spaß!

Ist gleichzeitig ein Test, ob man das SRAM richtig angeschlossen hat. Für Selbstfädler: Reihenfolge der Daten- und Adressleitungen untereinander ist übrigens wurscht, weil wie's reingeht, kommts auch wieder raus.

cm

PS: Für manche Monitore ist der RGB-Ausgangspegel an der VGA-Buchse etwas zu hoch. Wenn die Farbdarstellung zu flau ist, drei SMD-Widerstände 100 Ohm an der VGA-Buchse von Pin 1, 2 und 3 nach Masse (nächste Pin-Reihe) löten.

ACHTUNG: Sorry, erstes ZIP war offensichtlich fehlerhaft. Neue Version in Pacman_neu.zip

[cm]

Und so (siehe Anhang) sollte es dann aussehen.

[cm]

Ach ja: Param 0 steuert die Spiele-Knöpfe: 1. Digit von rechts Richtung, 2. Digit Coin/Start 1 Player/2 Player.

[psclab38]

Tja, Labman gibt bei mir nur einen schwarzen Bildschirm auf dem LCD, so ähnlich wie ursprünglich mit dem QVGA vom Dezember. Die aktuelle Version von QVGA gibt ein sichtbares Bild, also ist das RAM eigentlich richtig gefädelt. Invaders bringt auch ein Bild.

Soll denn die Steuerung per Param 0 so brauchbar sein, daß man spielen könnte? Bei Invaders hab ich nicht den Eindruck, es zuckt zwar, aber spielbar ist das m. E. nicht.
Oder muß da jetzt, wie im letzten Absatz des Artikels für Asteriods beschrieben, jeder für sich eigene Taster "hinfädeln"?

[cm]

Nach Laden von pacman.INI: Blinkt die LED neben dem FPGA? Wenn ja: gut, dann funktioniert die Hardware und Video-Sync-Signale kommen. pacman.DAT wird durch das INI-File ins SRAM geladen. FW 2.33 verwendet?

main.bit zu laden reicht nicht, da ist das ins SRAM geladene ROM-Image nicht enthalten.

Und: Nein, mit dem Panel spielbar im eigentlichen Sinne sind beide Beispiele nicht. Die Buttons sind lediglich auf die Parameter verdrahtet. Einen Joystick über einen Tristate-Buffer an die Datenleitungen zu legen sollte aber eine leichte Übung sein.

cm

[psclab38]

Nach Laden von pacman.INI: Blinkt die LED neben dem FPGA?

Ja, die LED blinkt und der LCD zeigt auch Synchronparameter an, aber ein schwarzes Bild.

pacman.DAT wird durch das INI-File ins SRAM geladen.

Ist mir klar, ich hab ins Ini-File reingeschaut.

FW 2.33 verwendet

Ja:
#5:254=2.33 [FPGA by CM/c't 06/2008]

Ich hab jetzt eben das Modul mal in den Keller geschleppt, zu einem alten Röhrenmonitor. Gleiches Bild.
Halt, was war das? Manchmal sehe ich Bildinhalt nach Neuladen von pacman.ini, lauter farbige Kringel. Mal nur einen mal wenige, mal ein ganzes Feld. Die ändern dann noch zwei-drei Mal die Farbe und das war's dann.

Hat das vielleicht mit dem Zugriff auf's RAM zu tun? Meins ist ein BS62LV4006PIP55 ist, also 55ns und 3V. Sollte dicke reichen.

Und QVGA läuft, wie gesagt. Hmmm.

Die Buttons sind lediglich auf die Parameter verdrahtet. Einen Joystick über einen Tristate-Buffer an die Datenleitungen zu legen sollte aber eine leichte Übung sein.

Ahhh, jetzt geht mir ein Licht auf, ich zitiere mal:

"Param 0 (untere 16 Bit, "Port 0") beschreibt die Portleitungen FP20 bis FN141, Bit 0 von Param 1 steuert die LED neben dem FPGA. Strobe-Signal (2 SysClks? kurz) für Port 0 liegt auf FN132."

Richtig?

[cm]

Sieht danach aus, als ob ein oder mehrere Adressleitungen floaten. Dann geht natürlich das Laden oder das Auslesen schief. Guck mal nach, ob A14 bis A18 am RAM-Baustein nach der Konfiguration auf einer richtigen "0" liegen (versuchen, mit einem Pullup von 4k7 nach +3,3V zu ziehen), das 8080-Pacman-ROM benutzt nur A0 bis A13, also 16 kByte. Das BS62LV4006PIP55 nehme ich auch.

Komisch nur, dass das QVGA läuft, aber da ist ja auch kein Programm im SRAM.

[psclab38]

Sieht danach aus, als ob ein oder mehrere Adressleitungen floaten.

Hatte ich heute früh auch schon gedacht, aber das isses nicht. Liegen alle brav auf Low.

Was mir beim Abklappern der Anschlüsse am RAM aber aufgefallen ist, daß der /WE immer high ist bei Labman. Sollte doch mindestens beim Reinladen der Daten flackern. Auf den restlichen Adress- und Datenleitungen ist hingegen Hochbetrieb und der /OE hat bei 160ns Periode 38ns Low-time. Also gelesen wird, aber vermutlich nur Schrott, weil nie was Sinnvolles reingeschrieben wird.

Bei QVGA klappert /WE hingegen ganz im Takt der Änderungen auf dem Bildschirm. Komisch.

Viele Grüße
Paul

PS: zu dem Tristate-Buffer für den Joystick: Ist das Strobe-Signal high-aktiv? (die meisten Tristate-Buffer sind leider low-Aktiv)
Jetzt ist aber Strobe FN132 ein Adressbit: das kann ja im Normalbetrieb aktiv werden und dann? Muß man Strobe noch mit /CE oder /OE vom RAM verknoten? Das ct-Ports.lpf ist da nicht sehr klar.

[cm]

Mistekiste, main.bit im ZIP war wohl tatsächlich Matsch. Kamen nur ein paar Kringel. Sollte jetzt gehen, siehe oben.

[cm]

Zum Joystick: Ist noch gar nicht im FPGA implementiert. Ich mach mal eine kleine Schaltung. BTW: hat noch jemand einen alten C64-Joystick?

[HSiebrecht]

Hallo cm,

Mistekiste, main.bit im ZIP war wohl tatsächlich Matsch. Kamen nur ein paar Kringel. Sollte jetzt gehen, siehe oben.

Danke, mit dem neuen main.bit klappt es auch mit pacman.

Zum Joystick: Ist noch gar nicht im FPGA implementiert. Ich mach mal eine kleine Schaltung. BTW: hat noch jemand einen alten C64-Joystick?

Ein alter Aplle ][ Joystick sollte wohl auch funktionieren, IMHO waren das ja beide Analog-Joysticks, ggf. mit anderen Widerstandswerten. Werde mal den Keller dursuchen was es da noch an Apple-Joysticks gibt.


@psclab38

Bei QVGA klappert /WE hingegen ganz im Takt der Änderungen auf dem Bildschirm. Komisch.

Bei QVGA ist das FPGA-RAM der Videospeicher, wird ein anderes Grafikfile geladen wir erst geschrieben und dann ausgelesen,
nächstes File schreiben wieder lesen u.s.w. wie bei demovga.ini

Beim pacman wird der ROM Inhalt nur "einmal" ins RAM geschrieben und dann nur noch gelesen. Somit keine Änderungen bei /WE.

[psclab38]

@HSiebrecht

@psclab38

Zitat:
Bei QVGA klappert /WE hingegen ganz im Takt der Änderungen auf dem Bildschirm. Komisch.


Bei QVGA ist das FPGA-RAM der Videospeicher, wird ein anderes Grafikfile geladen wir erst geschrieben und dann ausgelesen,
nächstes File schreiben wieder lesen u.s.w. wie bei demovga.ini

Beim pacman wird der ROM Inhalt nur "einmal" ins RAM geschrieben und dann nur noch gelesen. Somit keine Änderungen bei /WE.

Das ist mir schon klar. Ich meinte nur "komisch," daß bei pacman die Leitung gar nicht klingelt (auch nicht beim Laden des ROM), weil sie doch offensichtlich funktioniert (bei QVGA). Aber die Ursache war ja das matschige Bit-file.
Funktioniert jetzt auch hier. Allerdings hab ich zuerst wieder einen Schrecken bekommen, weil das "intro" ja auch Datenmüll anzeigt, aber wohl gewollt.


@cm:

Zum Joystick: Ich mach mal eine kleine Schaltung.

Ja, das wäre nett. Ich lese lieber Schaltpläne...

Ist das Invaders.bit, das dem ZIP beiliegt, eigentlich schon gefixt bzgl. des Soundbugs? Den Kopf muß ich jedenfalls noch nach rechts legen.

[ompf]

Ein alter Aplle ][ Joystick sollte wohl auch funktionieren,

Apple hatte analoge Joysticks, das wäre mehr Aufwand. Monoflop bauen und Zeit messen.

Der C64 hatte einfach fünf Kontakte: links, rechts, oben, unten und Feuer. Die gehen direkt auf die Portbits.


Gruß
Patrick

[HSiebrecht]

Hallo Patrick,

Apple hatte analoge Joysticks, das wäre mehr Aufwand. Monoflop bauen und Zeit messen.

Der C64 hatte einfach fünf Kontakte: links, rechts, oben, unten und Feuer. Die gehen direkt auf die Portbits.


Gruß
Patrick

Danke für die "Aufklärung", hatte keinen C64, nur Apple ][. Somit sollten auch zur "Not" 5 Taster reichen.

[ompf]

hatte keinen C64, nur Apple ][

Geht mir genauso. Genau genommen habe ich immer noch zwei Dutzend von den Kisten, vom Apple II bis zur Lisa.

Aber die C64-Joysticks hatten wir damals Apple-tauglich gemacht (Widerstände umgeschaltet über 4066), und meinen letzten Competition Pro habe ich vor drei Jahren auf USB umgerüstet.


Gruß
Patrick