Hallo Besucher, der Thread wurde 4,5k mal aufgerufen und enthält 8 Antworten

letzter Beitrag von Diddl am

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

    Zitat von tokra

    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:


    http://sleepingelephant.com/ip…=11&t=7620&p=83337#p83337


    Zitat

    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?


    Leider geht der Link nicht mehr ...

    Das Denial-Forum musste vorrübergehend umziehen wegen Hoster-Problemen, sollte aber in Kürze wieder unter sleepingelephant.com/denial zu finden sein.

    Aktuell ist der Link hier aktuell: http://denial.shamani.dk/bb/vi…=11&t=7620&p=83337#p83337


    Da sind deutlich mehr Informationen zu finden. Technisch bin ich da eher Laie, hab den Fehler aber mit der FE3 und Doom am NTSC-VIC nachstellen können und das Testprogramm hat es dann bestätigt.


    Hier findest Du den verbesserten RAM-Check von Mike zum Download, der auch explizit auf Crosstalk prüft:


    http://denial.shamani.dk/bb/vi…1&t=9090&p=102049#p102049


    Im Lemon-Forum hatte 2017 auch schon jemand auf das Crosstalk-Problem hingewiesen, aber darauf ist SkydivinGirl gar nicht eingegangen:


    https://www.lemon64.com/forum/viewtopic.php?p=816630


    Das Problem manifestiert sich nur bei Anwendungen, die den 3K-Erweiterungsbereich (RAM 1/2/3) zusammen mit enem anderen 8K-Block nutzen. Dies sind nur eine Handvoll Programme, aber insbesondere eben Doom. Die wengisten User werden das Problem jemals bemerken, außer wenn sie eben ein solches Programm wie Doom starten. Aber auch so schöne Sachen wie SJLOAD, die man z. B. in der 3K-Expansion-Area verstecken kann würden dann natürlich Probleme machen.