[BUGS] Sprite-Fehler bei EinsteinIV-Demo

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.

    Beim testen der neuen 9j-Firmware hab ich auch einige Demos durchlaufen lassen. Beim EinsteinIV von Cosmos gibt es mit TC64 Spritefehler.


    Startet man das Demo und drückt beim Intro "Space" geht es weiter zu Teil #2. Es kommt dann zuerst ein Text, dann das Cosmos-Logo... danach der Einstein-Kopf.


    Mit einem TC64 fehlen hier einige Sprites im Einstein-Kopf, zwei Spalten an Sprites fehlen komplett. Wenn ich das TC64 entferne dann funktioniert das Demo normal.


    Getestet an einem MK2 mit VIC 6569r5 und 1MHz.


    Mit 9i das gleiche, ist also kein neues "Problem" und vor allem kein dringendes Problem.

    Sorry für die späte Rückmeldung, aber gab viel zu tun.


    Ich hatte ja oben beschriebenes Problem das beim EinsteinIV-Demo im letzten Teil im Gesicht zwei komplette Sprite-Spalten fehlen, bzw. in der Mitte zusammengezogen sind. Das Problem war auch mit dem neuesten Core noch vorhanden.


    Ich hab noch ein zweites MK2 ohne TC64 aufgebaut, dort lief das Demo problemlos.


    Ich hab jetzt das funktionierende MK2 an die Anlage mit dem TC64v2 gehängt, damit Störungen durch die restliche Hardware auszuschließend sind.


    Also gleiche Umgebung, nur das andere MK2. Das funktioniert mit dem TC64 und dem Demo problemlos.


    Dann hab ich alle ICs über Kreuz getauscht.


    Das ursprüngliche Problemboard funktioniert jetzt am TC64, das andere Board zeigt jetzt den gleichen Fehler.


    Also wandert das Problem mit dem 6569r5 mit.


    Hänge ich jetzt aber das MK2 mit den evt. Problem-Chips an die andere Anlage ohne TC64, dann funktioniert das Demo ebenfalls problemlos.


    Ich hab dann nur mal den 6569r5 getauscht, dann ist das Problem mit dem TC64 wieder da. Es ist also der VIC.


    Das scheint ein 6569r5 zu sein den das TC64v2 nicht mag, der anderer 6569r5 (der aus einer Sammelbestellung von mehr als 100 NOS-Chips stammt und damit vermutlich aus der gleichen Produktions-Charge mit selben Datum) scheint mit dem TC64v2 zusammenzupassen.


    Vielleicht ist der Problem-Chip am Rande der Spezifikation, so das er ohne TC64 funktioniert und mit Probleme macht.


    Ich lasse die Chips jetzt getauscht, das Problem dürfte schwer einzukreisen sein.


    Markus

    So einen VIC hab ich auch in einem meiner Testrechner... ich probiere das Montag mal aus - nur der Vollständigkeit halber bitte einmal die komplette Beschriftung posten, danke!

    Quote from darkvision

    Vielleicht ist der Problem-Chip am Rande der Spezifikation, so das er ohne TC64 funktioniert und mit Probleme macht.

    Es ist nicht ausgeschlossen, dass eine ganze Reihe fehlerhafter Chips irgendwo gebunkert wurde und dann Jahrzehnte später als "NOS" verkauft wurde. Leider gab es bei Commodore (und später CSG) keine Chargen-Nummern die irgendwo dokumentiert wurden - es wurde einfach produziert und immer dafür gesorgt, dass genug Chips da waren: Sowohl in der Produktion, als auch in den Service-Centern. Aus einigen Memos die z.B. auch im Amiga-Wiki zu lesen sind, geht hervor, dass oft erst Monate später festgestellt wurde, dass bestimmte Chips Fehler haben. Diese Memos beschreiben dann, wie man die Fehler "meistens" beseitigen kann. Populäres Beispiel ist der 82p-Kondensator auf der CAS-Leitung bei bestimmten PLAs und natürlich eine Vielzahl an Agnus-Patches für den Amiga.


    Eine Art Chargen-Nummer gab es lediglich beim Bonding, denn das hat Commodore nicht in-house gemacht. Die Wafer wurden nach Hong Kong geschickt und dort gebondet. Auf die Unterseite hat der Dienstleister seine Chargennummer gedruckt. Bitte daher unbedingt die Nummern von der Unterseite ebenfalls notieren.


    Ich erwähne das nur, weil ich nicht möchte, dass wir hier "Geistern" hinterher jagen: Wenn sich der Fehler auf eine bestimmte Revision und einer bestimmten Charge begrenzt, sehe ich kaum Sinn darin, das im Chameleon abzudecken.


    Die andere Alternative ist, dass sich ein Fehler schlichtweg nur mit dieser Revision zeigt und ein Fix bei anderen Revisionen nicht zum Fehler führt. Dann ist es umso wichtiger, dass wir die Ursache finden, denn ein Fix wird uns nur noch näher an "die Wahrheit" bringen was Zyklusgenauigkeit unserer Emulation angeht.

    Dann warten wir mal auf den Vergleich der Chip-Bezeichnung und insbesondere der Chargennummer die auf der Unterseite des Chips aufgedruckt ist. Interessant wäre auch, ob der R5-VIC im C64RMK2 mit Chameleon irgendwas Besonderes macht.


    Vielleicht auch mal die Settings des C64RMK2 vergleichen: Ist da eine besondere Stereo-Config eingestellt die einen Einfluss auf dieses Demo haben könnte?


    Jens

    Quote

    Das scheint ein 6569r5 zu sein den das TC64v2 nicht mag, der anderer 6569r5 (der aus einer Sammelbestellung von mehr als 100 NOS-Chips stammt und damit vermutlich aus der gleichen Produktions-Charge mit selben Datum) scheint mit dem TC64v2 zusammenzupassen.

    Das deutet allerdings schon auch sehr auf "Grenzfall".


    Auf meinem C64RMK1, ebenfalls mit 6569r5 funktioniert es auch.... bevor ich jetzt rumbastle wüsste ich gerne die komplette Bestückung des Boards dass das Problem zeigt, also auch CIAs, SIDs, CPU (komplette Beschriftung der ICs bitte).

    So... jetzt auch die gesamten Platinen... auch mit der Unterseite der restlichen Chips...


    Alle CIAs scheinen aus der gleichen Serie zu sein (waren auch NOS aus einem größeren Lagerbestand), ebenso die CPU, beim SID müsstet Ihr nachschauen (falls möglich), hab ich bei euch mit den MK2 geordert, die Etiketten mach ich nicht ab.


    Das "bad" Board funktioniert ohne TC64 mit dem Demo perfekt...


    Hänge ich nur das TC64 an das "bad" Board -> Fehler ist da.


    Nehm ich r5 + TC64 vom "good" Board und packe das in das "bad" Board, dann funktioniert das Demo auch da...


    Nehm ich den r5 aus dem "bad" board und packe ihn in das "good" Board mit dem TC64, dann hab ich hier wieder den Fehler.


    Der zickige r5 und das TC64 mögen sich nicht, egal in welchem der beiden Boards. Und nicht falsch vestehen, das Board hat darauf keinen Einfluss... ich hab nur bad/good verwendet um das für mich auseinanderhalten zu können.


    Ich hänge mal noch zwei Bilder vom Demo an, ist aber schwierig die Bewegung festzuhalten :(

    wow, ein 6569R5 von 1991? Das klingt mir eher nach kreativem Umlabeln =) 8565R2 kam 1988, da ist doch relativ unwarscheinlich dass 3 Jahre später noch 6569R5 hergestellt wurden (wäre mir zumindest neu).


    Bitte mal gucken als was die beiden VICs erkannt werden (im remote Menu). Und vielleicht auch mal dieses Programm laufen lassen: https://csdb.dk/release/?id=89406


    (da meine 6569R5 von 1986 sind, und hier sogar zwei mit der identischen Aufschrift anderes Verhalten zeigen.... würde ich tatsächlich den einen als kuriosen Aussreisser einordnen wollen und weiteres Testen auf einen Zeitpunkt verschieben an dem ich tatsächlich auch "gleiche" ICs testen kann... das hat sonst alles eher wenig Aussagekraft)


    Spannend wären Tests von anderen Usern die selber auch solche ICs besitzen :)

    Quote from Tobias

    wow, ein 6569R5 von 1991? Das klingt mir eher nach kreativem Umlabeln =) 8565R2 kam 1988, da ist doch relativ unwarscheinlich dass 3 Jahre später noch 6569R5 hergestellt wurden (wäre mir zumindest neu).

    CSG hat sowohl NMOS als auch den HMOS2 Prozess (also 85xx Chips) parallel gefahren. Es ist also plausibel, dass 65xx Chips nach 1990 gebaut wurden. Einzig die identische Nummer auf der Unterseite ist interessant - eigentlich hat jeder Chip eine fortlaufende Nummer auf der Unterseite bekommen.

    Quote

    ich kann ja mal fragen ob jemand die gleiche Kombi (mk2+TC64+6569r5) aus dieser Bestellung hat und das reproduzieren kann...

    Das wäre wirklich interessant... Die Kombination von C64RMK2+TC64 ist nun nicht grade total selten, und 6569R5 generell ja auch nicht - mit diesem Datecode allerdings schon :)

    Quote from Jens

    CSG hat sowohl NMOS als auch den HMOS2 Prozess (also 85xx Chips) parallel gefahren. Es ist also plausibel, dass 65xx Chips nach 1990 gebaut wurden. Einzig die identische Nummer auf der Unterseite ist interessant - eigentlich hat jeder Chip eine fortlaufende Nummer auf der Unterseite bekommen.

    Dies ist definitiv nicht richtig!

    Sowohl die VIC-II, TED und SID die ich hier noch z.T. zu Hunderten liegen habe, weisen

    ALLE über weite Bereiche eine identische Chargennummer auf.

    (Ist ja auch keine Seriennummer - sondern wie weiter oben geschrieben - eine Chargennummer!)

    Den (im speziellen Fall) beanstandeten VIC-II habe ich mit ca. 150-200 weiteren vor einigen

    Jahren aus zuverlässiger Quelle (EU - also NICHT aus China!) gekauft.

    Die ESD Stangen haben z.T. sogar noch den Original Commodore Spare Part Aufkleber.

    Die meisten diese "HH172114" VIC-II sind in Umlauf gegangen - und dies ist die erste Reklamation bzw.

    Auffälligkeit. Eine komplett fehlerhafte Charge kann man also auch mit Sicherheit ausschliessen!


    - -


    BTW: Bis heute sind auch die Relabelten/Refubished Chips sehr leicht zu erkennen... man erkennt leicht,
    das der VIC-II einen Original-Druck hat also ganz sicher nicht "refurbished" wurde.

    Und das ein 6569R5 in dem CSG6569R5 tatsächlich drin ist kann ich deshalb eindeutig sagen,

    weil ich erst vor wenigen Wochen (exakt: 30. Nov. 2020) in genau so einen

    aus dieser Charge rein geschaut habe:


    Quote from androSID

    Sowohl die VIC-II, TED und SID die ich hier noch z.T. zu Hunderten liegen habe, weisen

    ALLE über weite Bereiche eine identische Chargennummer auf.

    (Ist ja auch keine Seriennummer - sondern wie weiter oben geschrieben - eine Chargennummer!)

    Dann sind die 6581 SIDs vermutlich anders bedruckt worden - oder bei einem ganz anderen Dienstleister gebondet. Es handelte sich um 1982er Datecodes, von denen ich ca. 400 Stück im Jahr 2002/2003 mit dem Catweasel MK3 unters Volk gebracht habe. Mit dem Posten hatte ich auch die CSG6582 eingekauft, die tatsächlich auf der Unterseite alle die gleiche Nummer stehen hatten. Ohne wirklich einen Hinweis auf eine Regel zu haben könnte man vermuten, dass es irgendwann zwischen "MOS" und "CSG" den Übergang von "Seriennummer und Chargennummer" zu "nur noch Chargennummer" gegeben hat [/Spekulation].


    Quote from androSID

    Den (im speziellen Fall) beanstandeten VIC-II habe ich mit ca. 150-200 weiteren vor einigen

    Jahren aus zuverlässiger Quelle (EU - also NICHT aus China!) gekauft.

    Ich glaube ich kenne die Quelle - noch heute Braunschweig tätig. Ich weiß nicht mehr genau wann es war, aber "so um 2004 herum" - mein Gebot auf den Posten ist wohl ein wenig zu spät eingetroffen, da war der ganze Kram schon an einen Recycler am Rande des Ruhrgebietes verkauft. Von dort aus hat wohl ein kleiner Teil den Weg zu Dir gefunden.

    Ich habe mal einige Stangen 8520, 8375, 8373, 8360 und 6502A (93er D/C!) gesichtet (was halt greifbar war):


    Alle haben bei gleichem D/C die gleiche Chargennummer unten drauf. Die 8360 sind noch "MOS" gestempelt; der Rest "CSG".


    Interessanter fänd' ich eher: Warum macht der eine VIC-II Fehler; aber das zu untersuchen kann ich nicht leisten.

    Ich kann nur (falls notwendig) gleiche VIC-II (aus dieser Charge) bereitstellen. Aber einen mit gleichem Fehlerbild

    zu finden dürfte schon schwer werden. Und: Ob's den ganzen Forschungsaufwand Wert ist? Fraglich...

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

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • 8|
    • :cursing:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3