Final Expansion und NTSC-VIC20 Speicherprobleme-Crosstalk

  • Final Expansion und NTSC-VIC20 Speicherprobleme-Crosstalk

    Gibt es hier noch mehr User mit der FE3 und einem NTSC-VIC20? Ich habe da nämlich bei mir Probleme mit der Speichererweiterung festgestellt. Wenn man auf "All RAM" geht (also 35K RAM-Erweiterung) werden Schreibvorgänge in den Blöcken 1,2,3 und 5 manchmal nach BLK0 (in den 3K-Erweiterungsblock) gespiegelt. Das führt dann natürlich dazu, dass Programme, die die 35K brauchen nicht funktionieren, z. B. das VIC-Doom.

    Am selben Gerät läuft Doom mit der MegaCart einwandfrei und auf einem PAL-Gerät gibt es mit der FE3 diese gespiegelten Schreibvorgänge ebenfalls nicht. Es scheint also ein reines NTSC-VIC <-> FinalExpansion-Problem zu sein.

    Anbei mal das Testprogramm:

    Speichertest-Crosstalk-FinalExpansion

    Es gibt bei mir hier immer mehr oder weniger Crosstalk (also gespiegelte Speichervorgänge nach BLK0). Manchmal läuft es auch fehlerfrei durch. Erfahrungsberichte anderer NTSC-FinalExpansion User wären interessant oder noch besser: Ursachenforschung und Lösungsvorschläge
  • Das kann ich bestätigen:
    Ich habe diesen Effekt sogar bei einem PAL-VC20. Offenbar werden durch ein Timing-Problem Schreibzugriffe oberhalb $2000 nach BLK0 gespiegelt.
    Ich werde mal prüfen, was passiert, wenn man für das RAM ab $2000 nicht Seite 0 oder 1 vom SRAM verwendet, sondern mit Seite 2 beginnt. Das RAM in BLK0 teilt sich ja die Seiten 0 oder 1 im SRAM der FE3.

    Gruß Dirk
    gesendet über Robotron Lochbandtechnik mit A 5120
  • tokra schrieb:

    Wenn sich das Problem mit einem Firmware-Update lösen ließe, wäre das natürlich ideal.

    Prinzipiell geht das zwar, aber da sind dicke Bretter zu bohren:

    Wären die JTAG-Anschlüsse des CPLDs verfügbar geblieben, könnte man das Problem bequem in der Schaltung debuggen. Hier leider nicht: mangels verfügbarer Anschlüsse wurden aber in der FE3 die JTAG-Anschlüsse zu normalen Ein-/Ausgabe-Ports umdefiniert. Das bedeutet, die CPLDs werden einmalig mit den FE3-Definitionen programmiert und danach ist das nicht ohne weiteres zu ändern. Nur mit einem Hochvolt-Programmiergerät (wie z.B. ein GALEP 4) können die Chips gelöscht und neu programmiert werden. Dazu müssen sie aber dem FE3 entnommen werden, gelöscht und neu programmiert werden und wieder in das FE3 eingesetzt werden. Ob der verwendete CPLD-Sockel die Anzahl der notwendigen Debug-Zyklen und damit die häufige Entnahme und das Wieder-Einsetzen überlebt ohne Kontaktprobleme zu bekommen und damit neue Defekte zu erzeugen, darf mit einem Fragezeichen versehen werden.

    Wer das debuggen möchte, muss die verwendete Hardware-Beschreibungs-Sprache beherrschen. VHDL und Verilog helfen hier allerdings nicht weiter, da die CPLD-Logik in CUPL entwickelt wurde: eine durchaus unübliche Hardware-Beschreibungs-Sprache, die zudem veraltet ist. Zum Trost: sie ist deutlich primitiver als z.B. VHDL. Zum Entwickeln braucht man dann allerdings noch eine antike Software-Version von WinCUPL, da in den aktuellen Versionen der Atmel-Entwicklungsumgebung die Unterstützung von CUPL schon lange nicht mehr gegeben ist.

    Diddl (der Entwickler) hat sich leider hier vollständig zurück gezogen, so dass auf seine Hilfe leider nicht gebaut werden kann. Wer auch immer das an seiner Stelle angehen möchte: viel Spaß! :bgdev
  • Hierzu gibt es neue Erkenntnisse. In den USA bastelt Jim Brain gerade an der "UltiMem" für den VC20 und da habe ich vorsichtshalber mal nach dem Crosstalk-Problem gefragt. Dies war tatsächlich dann auch beim Prototyp der UltiMem vorhanden, ist jetzt aber dort gefixed:

    sleepingelephant.com/ipw-web/b…=11&t=7620&p=83337#p83337

    The fix: WE on the RAM needs to be gated with clock

    That is why the schematic on the linked topic had issues. the 7408 does not have PHI2 as an input.

    Ist das ein machbarer Hardwarefix auf der FE3 oder mit einer Revision fixbar?
  • Benutzer online 1

    1 Besucher