Hello, Guest the thread was viewed14k times and contains 67 replies

last post from bigby at the

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

  • 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


    Quote

    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.

  • :grab1:


    Nur ein kurzer Querverweis an dieser Stelle auf meinen eigenen Thread, in dem ich derzeit mit einem FE3 an einem PAL VIC-20 kämpfe, der massive Cross-Talk-Probleme verursacht:


    Final Expansion 3 - FE3DIAG meldet Fehler


    Falls in diesem Kontext damals also eine Lösung für dieses Problem gefunden wurde, wäre ich dankbar für weitere Hinweise.

  • Ich habe auch auf Denial bereits geantwortet, und vorher deine Anfrage vom Ultimem-Thread in den originären FE3-Thread verschoben, mit zusätzlicher Verlinkung.


    Das Problem bei der FE3 ist die Verwendung von CR/W für Speicherzugriffe und der Versuch, das striktere Timing-Fenster von VR/W mit Verzögerungszuständen im CPLD 'nachzubauen'. Für NTSC ist das Timing dann fast immer falsch und auch für PAL nicht immer passend und mit einem deiner Rechner hast Du jetzt leider Pech.


    Eine saubere Lösung würde eine Änderung sowohl der Logik-Gleichungen aber auch des Board-Layouts erfordern, damit CR/W, SPhi2 und VR/W berücksichtigt werden können. CR/W wird immer noch benötigt, zusammen mit SPhi2 macht das dann nämlich das korrekte Timing für alles was an /I/O2 und /I/O3 dran hängt (u.a. die Register, die der CPLD in I/Ox zeigt!) - darum hat deine FE3 auch die Grätsche gemacht, als Du CR/W auf VR/W 'umgehängt' hast. Die Anleitung von Jim, auf die Du dich da bezogen hast, war im wesentlichen ein Schuß ins Blaue zu einem Zeitpunkt als der Grund für die Probleme noch nicht bekannt war.


    Es gibt aber für deinen 'problematischen' VC-20 noch eine andere Möglichkeit, die FE3 wieder nutzbar zu machen: bau die +3K in $0400..$0FFF intern ein, so wie ich das mit meinem VFLI mod gemacht habe. Dann kann der Crosstalk als Nebeneffekt nicht mehr auftreten, da ja dann dieser Speicherbereich nicht mehr von der FE3 sondern bereits vom Mainboard bedient wird.

  • Mike Auch an dieser Stelle noch einmal vielen Dank für Deine ausführliche Antwort und Erklärung!


    Schade eigentlich, dass dieser Fehler auf dem FE3 noch in keiner neueren Revision korrigiert wurde. Mal schauen, vielleicht nehme ich mir das irgendwann mal selber vor. Zur Zeit würde mich das ein wenig überfordern, denke ich.

  • Danke für die Erläuterungen zu V R/W, C R/W und Phi2.



    Ich möchte das Problem beheben.

    Aber ich bin zu doof das inahltlich voll und ganz zu vesrtehen ...


    Zur Zeit verwenden wir C R/W und PHI2.

    Pin 40 und Pin 5 am CPLD wäre ja verfügbar ...

    Also könnte man V R/W ja an Pin 40 oder 5 anschließen.


    ==========


    Nun, in der C64 Wiki gibt es eine Port Beschreibung:

    https://www.c64-wiki.de/wiki/Expansionsport_VC20


    Da steht:

    - V R/W: Low: Lesezugriff vom VIC

    - C R/W: Low: Lesezugriff vom 6502


    Soweit so gut.



    Ich verstehe das Problem nicht wirklich.

    Schreibzugriffe vom VIC sind mir ja egal?

    Der VIC soll ja nicht in meinen SRAM schreiben.


    Wo liegt das Problem jetzt genau?

    Was passiert da, wenn ein Cross Bank Write passiert?


    Bzw. wie müsste man das verknüpfen und warum?

  • [...] - V R/W: Low: Lesezugriff vom VIC [...]

    Das ist totaler Quatsch.


    VR/W steuert das Timing auf Speicherbausteine und wird im VC-20 durch Einengung von CR/W in Verbindung mit SPhi2 gewonnen. Während SPhi2=1 ist (also, die CPU den Bus hat), wird dem VIC dadurch zusätzlich signalisiert, ob bei Zugriffen auf seine Register in $90xx selbige gelesen oder geschrieben werden. Während der VIC den Bus hat, wird VR/W hart auf High-Pegel - also lesend - gezogen, damit zu 100% gewährleistet ist, daß diese Speicherzugriffe das RAM nicht 'lustig' überschreiben.


    Hauptproblem am Expansionsport ist, daß das Timing dieser drei Signalgruppen:

    • /BLK1 .. /BLK3 und /BLK5,
    • /RAM1 .. /RAM3 und
    • /I/O2 und /I/O3

    unterschiedlich ist.


    Die I/Ox-Signale werden sehr früh erzeugt, kurz nachdem die Adreßleitungen der CPU stabilisiert sind. Das ist aber bereits der Fall, wenn der Video-Chip noch den Bus hat. Aus diesem Grund muß alles, was über I/Ox selektiert wird (u.a. der CPLD der FE3, aber z.B. auch VIAs am Expansionsport - wie in der IEEE-Cartridge) zusätzlich über SPhi2 qualifiziert werden. Und dann nimmt man CR/W zur Festlegung der Datenrichtung her.


    Als nächstes kommen die Select-Signale der /BLKx. Die werden von einem LS138 direkt aus den oberen 3 Bit der CPU-Adressleitungen erzeugt und sind bereits mit SPhi2 qualifiziert! Hier ist für die Festlegung der Schreib-/Leserichtung VR/W korrekt, und das Signal gehört *direkt* (<- dick, fett, unterstrichen, schräg gestellt!) an den Speicherchip.


    Zuletzt kommen die Select-Signale der /RAMx-Bereiche. Hierzu muß /BLK0 = 0 sein (also, CPU-Zugriff in $0000..$1FFF) und dann hängt aber noch ein weiterer Dekoder dran, der die /RAMx einzeln ausdekodiert, wovon dann /RAM1 .. /RAM3 an den Expansionsport gehen. Das Timing von VR/W ist aber auch hier so realisiert, daß es paßt.


    Es ist jetzt die Aufgabe des CPLD, sowohl bei /BLKx als auch /RAMx das Ergebnis des Bankings mit minimalem Verzug auf die 'oberen' Adreßleitungen bzw. /CS sowohl vom Flash- als auch vom RAM-Chip zu bringen. Waitstates haben hier nichts (mehr) zu suchen! VR/W gehört direkt an R/W beider Chips und soll nicht durch den CPLD - ohne wenn und aber.


    Zum Schluß braucht /OE von Flash und RAM noch eine Sonderbehandlung. Das sollte durch


    /OE = !(CR/W & SPhi2)


    erzeugt werden. Damit ist zum einen sichergestellt, daß bei Schreibzugriffen der CPU keiner der Speicher die Ausgangstreiber aktivieren kann, außerdem verlangen Flash-Speicher üblicherweise, daß bei Schreibzugriffen /OE definitiv auf High-Pegel ist.


    Viele Grüße,


    Michael

  • ** SOLVED **


    Siehe:

    Final Expansion 3 - FE3DIAG meldet Fehler


    Vielen Dank an Mike und bigby!!!! :)



    Download auf der FE-3 Seite verfügbar:

    https://oe7twj.at/index.php?title=Final_Expansion_3



    Test auf einer NTSC Maschine ist ausständig.

    Aber ich gehe eigentlich davon aus, dass sich auch das VIC Doom Problem und das NTSC Problem damit gelöst hat.

  • Aber ich gehe eigentlich davon aus, dass sich auch das VIC Doom Problem und das NTSC Problem damit gelöst hat.

    Vielleicht ist es noch etwas früh, die sprichwörtlichen Sektkorken knallen zu lassen:

    Final Expansion 3 - FE3DIAG meldet Fehler


    Weitere Untersuchungen stehen aus, für heute ist erst mal Feierabend.

  • Aber ich gehe eigentlich davon aus, dass sich auch das VIC Doom Problem und das NTSC Problem damit gelöst hat.

    Vielleicht ist es noch etwas früh, die sprichwörtlichen Sektkorken knallen zu lassen:

    Final Expansion 3 - FE3DIAG meldet Fehler


    Weitere Untersuchungen stehen aus, für heute ist erst mal Feierabend.

    Naja vielleicht ist das VIC Doom Problem ja auch ein ganz anderes.


    Die Hoffnung stirbt zuletzt 😁

  • Naja vielleicht ist das VIC Doom Problem ja auch ein ganz anderes.

    Möglich. Ich habe das FE3 inzwischen noch einmal an den anderen VC-20 angeschlossen, aber auch dort stürzt das Programm beim Laden ab.


    Ich habe auf der Seite von tokra noch ein kleines Basic-Programm namens MEMTEST.PRG gefunden und ausprobiert (mit "all RAM", F7). Das schreibt einmal den ganzen erweiterten Speicher voll und liest ihn wieder aus. Sobald es den Bereich bei $A000 erreicht, meldet es bei mir einen Fehler:


    24-06-04 23-44-12 3753b.jpg


  • Ich habe auf der Seite von tokra noch ein kleines Basic-Programm namens MEMTEST.PRG gefunden und ausprobiert (mit "all RAM", F7). Das schreibt einmal den ganzen erweiterten Speicher voll und liest ihn wieder aus. Sobald es den Bereich bei $A000 erreicht, meldet es bei mir einen Fehler:

    Nun, ich werde die CPLD Logik nochmals checken ...