Chameleon Core update 9k veröffentlicht

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Wir meinen es ernst - Ab jetzt gibt es monatliche Chameleon updates - und wir bewegen uns in grossen Schritten hin zum finalen nicht-beta Release. Dieses behebt lang bekannte VICII Bugs und bewirkt dass fast alle "real world" Testfälle 100% funktionieren. Im einzelnen sind das:

    ... und warscheinlich mehr die vom gleichen Timing Bug betroffen waren.


    Da dieses ein fundamentaler Bug-Fix ist, welcher fast alle fehlerhaft laufende Programme von unserer Liste streicht, möchten wir alle Chameleon Besitzer ermuntern alles das nach diesem Update noch immer nicht funktioniert zu melden. Bitte beachten Sie unser wiki um zu sehen welche Probleme bereits bekannt sind.


    Bitte schauen Sie auch in den Chameleon C64 Core - Compatible Monitors Thread und melden Sie ihre Erfahrungen (hoffentlich erfolgreiche) mit dem neuen VGA-Controller im Zusammenspiel mit ihrem Monitor.


    Die Änderungen im Detail:


    Code
    1. - Merge incomming system reset with local reset, so CPU is held in reset while external reset is pending.
    2. - Fix in scaler for the scale factor 1.5x only used by 640x480, that caused pixels to be lost reducing the picture quality.
    3. - Fix in VIC-II emulation, changes to D011 yscroll value to preform DMA delay effects were one cycle off.
    4. - Fix in VIC-II emulation, changed the architecture of the internal 40 character buffer to match observed addressbus bahavior during DMA delays.


    Wie immer können Sie das Update auf der Chameleon Seite in unserem wiki downloaden.


    Viel Spass!

  • Wir meinen es ernst - Ab jetzt gibt es monatliche Chameleon updates - und wir bewegen uns in grossen Schritten hin zum finalen nicht-beta Release.

    Daumen hoch dafür. :)



    Wie immer können Sie das Update auf der Chameleon Seite in unserem wiki downloaden.

    Das Update 9k meldet sich in der System Info als 9j vom 30.11. Die RBF-Dateien im Download sind aber nicht die von 9j.

  • Quote

    Das Update 9k meldet sich in der System Info als 9j vom 30.11. Die RBF-Dateien im Download sind aber nicht die von 9j.

    Kann ich hier nicht nachvollziehen - wurde auch der richtige Core gestartet? Ich hab hier grade mal das zip runtergeladen und das update geflasht - im Sysinfo steht 12.Dezember und 9k

  • Hm, das ist ja merkwürdig. Hier ein paar mehr Details. Das Update auf 9k hatte ich per update.prg auf dem Chameleon selbst im Cartridge Modus durchgeführt. Es lief ohne Fehler durch und anschließend war auch meine Config gelöscht, wie das nach einem erfolgreichen Update eben immer so der Fall ist. Danach war laut Sysinfo mein TC aber eben immer noch bei 9j.


    Nächster Versuch eben gerade vom PC aus (momentan Win10), immer noch Cart Modus. Nach dem starten von flasher.exe (das in der readme immer noch als update.exe bezeichnet wird), wird ein TC64 V1 erkannt, obwohl ich hier jetzt ein V2 habe. Das Update habe ich daher abgebrochen und direkt Chaco gestartet.


    Nun also 9k "von Hand" geflasht und jetzt meldet sich das TC auch mit 9k. :)


    Edit: Eine Sache noch. Schon vorhin, als das Update auf 9k noch nicht geklappt hat, bekam ich über VGA kein Bild mehr auf meinem Monitor. Dabei war das mit diesem Screen überhaupt erst ab 9j möglich, per VGA etwas zu sehen. Und auch jetzt nach dem erfolgreichen 9k-Update und mit unter 9j erfolgreich getesteter VGA-Einstellung gibt's kein Bild mehr.


    Edit2: Muss ich nicht verstehen, VGA geht jetzt doch wieder. Naja, soll mich nicht stören.

  • Quote

    Hm, das ist ja merkwürdig. Hier ein paar mehr Details. Das Update auf 9k hatte ich per update.prg auf dem Chameleon selbst im Cartridge Modus durchgeführt. Es lief ohne Fehler durch und anschließend war auch meine Config gelöscht, wie das nach einem erfolgreichen Update eben immer so der Fall ist. Danach war laut Sysinfo mein TC aber eben immer noch bei 9j.

    War da vllt noch ein alter Core im UPDATE verzeichnis auf der Karte? Eventuell auch mal scandisk über die Karte laufen lasen, wenn das Dateisystem nicht 100% in Ordnung ist können komische Dinge passieren :)

    Quote

    Nächster Versuch eben gerade vom PC aus (momentan Win10), immer noch Cart Modus. Nach dem starten von flasher.exe (das in der readme immer noch als update.exe bezeichnet wird), wird ein TC64 V1 erkannt, obwohl ich hier jetzt ein V2 habe.

    Das klingt merkwürdig - die Erkennung sollte eigentlich sicher funktionieren. Ist das reproduzierbar?


    (readme hab ich mal gefixt :))


    Quote

    Nun also 9k "von Hand" geflasht und jetzt meldet sich das TC auch mit 9k.

    Das ist ja die Hauptsache :)

  • War da vllt noch ein alter Core im UPDATE verzeichnis auf der Karte?

    Ups, das ist mir ja noch nie passiert. Da war tatsächlich neben 9k noch 9j mit im Updateverzeichnis. Als Anregung: da nach einem Update die Datei update.prg automatisch gelöscht wird, wäre das auch mit der rbf-Datei möglich?


    Das klingt merkwürdig - die Erkennung sollte eigentlich sicher funktionieren. Ist das reproduzierbar?

    In der Tat ist das nicht reproduzierbar.


    (readme hab ich mal gefixt :))

    Danke!

  • Quote

    Als Anregung: da nach einem Update die Datei update.prg automatisch gelöscht wird, wäre das auch mit der rbf-Datei möglich?

    gute Idee - hab ich grade mal eingebaut :)

  • Das Einstein IV-Demo hat noch immer die Sprite-Fehler.


    Im 2ten Part, nachdem der COSMOS-Schriftzug einfliegt, erscheint der Einstein-Kopf. Es fehlen auch mit 9k zwei Spalten an Sprites. Also zumindest hier ist das nicht gefixed.


    Getestet mit einem MK2 und VGA-Ausgang am TC64/1MHz. Dafür geht jetzt der RESET über das MK2 :thumbup:

  • Bitte mal das Setup komplett beschreiben, welche Chameleon Hardware, was ist alles angeschlossen, was für ICs stecken im MK2 - und welche optionen wurden im Chameleon setup aktiviert. (am besten mit default Settings ausprobieren).

  • Bitte mal das Setup komplett beschreiben, welche Chameleon Hardware, was ist alles angeschlossen, was für ICs stecken im MK2 - und welche optionen wurden im Chameleon setup aktiviert. (am besten mit default Settings ausprobieren).

    Ich hab hier zwei identische MK2 jeweils mit 6510, 2x6526A, 6569R5 und 8580. Die Chips waren zuvor nie in anderen C64 eingebaut, also nichts was irgendwann ausgelötet wurde.


    Am einen hängt das TC64v2 und am anderen aktuell nichts. Video ist beim TC64 über VGA, beim anderen MK2 über die Video-Buchse. Am MK2 ohne TC64 funktioniert das DEMO.


    Ich hab dann mal das TC64 auch in das 2te MK2 gesteckt... und da geht das Demo dann auch. Also scheint es was mit dem ersten MK2 zu tun zu haben.


    Ich hab dann mal die Gegenprobe gemacht und am Problem-MK2 das TC64 weggelassen und die Video-Ausgabe über die Videobuchse gemacht. Da funktioniert das Demo dann. TC64v2 wieder rein und jetzt ist der Fehler wieder da, sowohl über die Video-Buchse als auch über den VGA-Ausgang.


    Ich müsste mal die beiden VIC über Kreuz tauschen. Denn selbst wenn am Problem-MK2 alles andere ausgesteckt ist (nichts am ser.Port, kein Joystick usw...) dann zeigt das Demo den Fehler wenn das MK2 eingesteckt ist.


    Die 2 Spalten fehlen im übrigen nicht... die sind nur um 1 Spalte verschoben, d.h. die Position stimmt nur nicht. Bei einer Spalte wird die linke und die rechte "zusammengezogen", es liegen dann die drei Spalten übereinander. Sieht man daran das die Spalte kaum zu erkennen ist, zu viele Pixel.


    Ich muss die beiden Kisten mal aufmachen und ggf. mal auch das Problem-MK2 auf Werkseinstellungen zurücksetzen. Hab da zwar nie was verstellt, aber wer weiß. Seltsam ist nur das es ohne TC64 funktioniert.


    Alle Tests mit dem TC64 waren direkt nach dem Update, nichts umgestellt, Standard C64-ROM (kein JiffyDOS usw).

  • Ich müsste mal die beiden VIC über Kreuz tauschen. Denn selbst wenn am Problem-MK2 alles andere ausgesteckt ist (nichts am ser.Port, kein Joystick usw...) dann zeigt das Demo den Fehler wenn das MK2 eingesteckt ist.

    Bitte nicht nur den VIC; sondern auch die CIA#1 kreuz-tauschen, denn da gibt es noch eine Verbindung über den Feuerknopf von Joystick Port 1, der auch Lightpen-Trigger weiter gibt. Im Cartridge-Mode nutzt das Chameleon noch recht viel der "echten" C64-Hardware, so dass diese Chips tatsächlich einen Einfluss haben könnten.

    Ich muss die beiden Kisten mal aufmachen und ggf. mal auch das Problem-MK2 auf Werkseinstellungen zurücksetzen. Hab da zwar nie was verstellt, aber wer weiß. Seltsam ist nur das es ohne TC64 funktioniert.

    Das geht ohne Öffnen, einfach über das Remote Control Menü. Bei der Gelegenheit bitte auch mal die MCU-Version vergleichen, eventuell den Updater mal laufen lassen.

  • Lightpen trigger wird wohl nicht benutzt (zumindest macht space drücken nichts kaputt)

    Quote

    Die 2 Spalten fehlen im übrigen nicht... die sind nur um 1 Spalte verschoben, d.h. die Position stimmt nur nicht. Bei einer Spalte wird die linke und die rechte "zusammengezogen", es liegen dann die drei Spalten übereinander. Sieht man daran das die Spalte kaum zu erkennen ist, zu viele Pixel.

    Das klingt halt wirklich seltsam, das lässt sich nicht durch einen Timing-Fehler erklären - sondern da müssen wirklich die falschen x-Positionen der Sprites im Register angekommen sein. So wie der Effekt aufgebaut ist würde ich auch vermuten dass das komplett unkritisch ist (und eh nur einmal pro Frame passiert). *kratz*

  • (zumindest macht space drücken nichts kaputt)

    Das könnte schon durch Programmieren auf "input" auf der anderen Seite der Tastaturmatrix erreicht werden, insofern würde ich "Blick in den Code" abwarten, bis dieser Teil komplett ausgeschlossen ist. Oder mal Feuer in Port 1 drücken - wenn das nicht den Demo-Teil beendet, aber auch sonst nichts kaputt macht, würde ich mir spontan das Disassembeln sparen.

    Das klingt halt wirklich seltsam, das lässt sich nicht durch einen Timing-Fehler erklären - sondern da müssen wirklich die falschen x-Positionen der Sprites im Register angekommen sein.

    Die Aussage macht den Blick in den Code umso interessanter, aber mit Abstand einfacher ist der Kreuztausch der Chips um herauszufinden, wie man den Fehler von A nach B überträgt. Wenn z.B. das MSB der X-Koordinate mit einem read-modify-write Kommando gemacht wird (was naheliegend wäre) und der VIC beim Lesen der Daten ein Problem hat (Chip-Treiber könnte zu schwach sein), wäre die Erklärung recht einfach. Und der Fix offensichtlich :-) Aber wir wollen keine voreiligen Schlüsse ziehen.

  • Quote

    Das könnte schon durch Programmieren auf "input" auf der anderen Seite der Tastaturmatrix erreicht werden

    nene, das macht keinen Unterschied (das wäre schön :))

  • The last reply was more than 365 days ago, this thread is most likely obsolete.