Posts by Mac Bacon

    VICE emuliert derzeit nicht das Grafik-Gewusel, das im 2-MHz-Modus entsteht. Falls da so ein kewl phat crass brontaler uberhaxxor zum Entpacken auf 2MHz schaltet, das Zurückschalten auf 1MHz vergessen hat und das Ergebnis nicht auf realer Hardware testet, dann...


    ...kann sowas passieren, ja.

    Danke überhaupt, dass du das hier gebastelt hast

    Da nich für, ich konnte ja schlecht die Inspiration verfallen lassen. :D

    (nämlich diese: Der "Trick" bei dem Programm ist, dass das Testprogramm überhaupt keinen Testcode enthält. Frei nach der alten Weisheit: Wer keine Entscheidungen trifft, trifft auch keine falschen...

    Man kann zwar über die Kollisionsregister herausfinden, ob der VIC wirklich gerade die Bank anzeigt, die er anzeigen soll, aber das Programm benutzt eine andere Methode: es verteilt die Spritedaten einfach so im Speicher, dass in der richtigen VIC-Bank der Spritezeiger auf "OK" zeigt und in den falschen VIC-Banks auf das entsprechende Fehlermeldungs-Sprite.)

    Bank wird per Raster-IRQ umgeschatet

    Nicht mal das, der Code pollt einfach das Register. Ich wollte das Programm möglichst simpel halten, um Beeinflussungsmöglichkeiten durch andere Defekte zu minimieren.

    im Hintergrund der jeweilige Textschirm-Ausschnitt?

    Genau wie Colts Programm aktiviert auch meins einen ungültigen Bildschirmmodus, so dass nur Sprites auf schwarzem Hintergrund sichtbar sind.

    nur ein paar Ideen:

    [...]

    dann wäre das ultimative "Visual Test Tool" fertig.

    Das sind alles gute Ideen, aber das sollte(tm) man eher als separates Programm machen. Mir ging es hier darum, ein möglichst simples Tool zu haben, das einfach nur VA14 und VA15 überprüft, ohne überhaupt Benutzereingaben zu benötigen. Also das einfach nur die Fragen "können Daten aus allen vier Bänken angezeigt werden? und wenn nicht, warum nicht?" beantwortet.


    Tools die den ganzen Speicher durchsteppen und als Textseite anzeigen, gibt es sogar schon - nur sind die normalerweise nicht als Diagnose- sondern als Ripping-Tool gedacht. Ich meine mich da dunkel an ein paar sehr kurze Programme aus dem 64er-Magazin zu erinnern ("Sprite-Dieb, Grafik-Räuber und Charakter-Klau" oder so...), davon sollte eins in die richtige Richtung gehen.

    Wenn ich keinen Mist gebaut habe,

    Da ich Mist gebaut habe, gibt es hier eine neue Version. Wenn VA14 und VA15 auf unterschiedlichen Pegeln festhängen, zeigt die vorige Version allen Ernstes "this cannot happen" an. War spät gestern... :drunk: :anonym

    Jetzt ist das behoben, in solchen Fällen wird "both wrong" angezeigt und die tatsächlichen Leitungspegel sind an den Anzeigen der ersten und letzten Bank ablesbar.


    Das Zip-File enthält den Source, den werde ich auch noch irgendwo separat veröffentlichen, entweder als github-Projekt oder im examples-Verzeichnis von ACME. Wer den Code in ein Diagnosemodul packen will, hat hiermit mein Einverständnis - vorher sollte man das Programm aber erst noch richtig testen, d.h. auf einer Maschine mit definitivem VIC-Bank-Defekt: Ich hab zwar diverse Fälle getestet, aber in Ermangelung karpotter Hardware waren die Tests natürlich alle gefälscht...

    Das erinnert mich daran, dass ich für solche Fälle noch ein spezielles Diagnoseprogramm schreiben wollte...

    Ich hab da jetzt mal was zusammengeworfen. Wenn möglich, bitte das angehängte Programm auf der Maschine laden und starten und vom Ergebnis einen Screenshot machen. Wenn ich keinen Mist gebaut habe, sollte man dann sehen können, ob VA14 oder VA15 (oder sogar beide) problematisch sind und auf welchem Pegel sie festhängen.


    Ja, den Source gibt es auch in Bälde.

    Das Fehlerbild spricht dafür, dass der VIC das Bildschirm-RAM nicht richtig ansprechen kann. Da er dieses Problem aber offensichtlich nicht immer hat, muss es mit der Auswahl seiner Bank zu tun haben.

    This.


    Das erinnert mich daran, dass ich für solche Fälle noch ein spezielles Diagnoseprogramm schreiben wollte...


    Bis dahin siehe Colts Testprogramm, der Beitrag sollte über die Lesezeichen auf meiner Profilseite auffindbar sein.

    Nach Bild 3 sieht es nach RAM-Problem aus.

    Finde ich nicht. In den falschen Zeichen weichen zuviele Bits vom Sollwert ab; da müssten mehrere unterschiedliche Chips ihre Fehler an den gleichen Adressen haben. Nur das Doublequote geht als "echtes" RAM-Problemzeichen durch, ich tippe daher auf ein grundlegenderes Problem (Müll auf dem Bus oder so).

    Das Cursorblinken kann man komplett dem System überlassen, das Konvertieren von/zu Screencode ebenso. Hier ein Beispiel:

    Einsprung via @entry, den END_CHARACTER muss man selbst festlegen.

    Ich habs jetzt nicht getestet, sondern nur aus dem Sourcecode meiner Eingabepuffer-Routine zusammengestückelt.

    Muss "secondary address nicht = 1" sein? 15 ist doch der Fehlerkanal!?

    Korrekt. Da im Eingangspost OPEN benutzt wird, kann das so nicht gehen. Würde SAVE benutzt, ginge es aber, denn LOAD und SAVE benutzen intern immer die Sekundäradressen 0 und 1, und die vom Benutzer angegebene Sekundäradresse wird anders verwendet (siehe Unterschied zwischen ",8" und ",8,1").

    U38 bis U45 sind eigentlich(tm) Bank 0, U46 bis U53 sind Bank 1 - der Rechner sollte so also gar nicht erst starten können.

    An R29 und R30 wurde nichts geändert.

    Ich nehme alles zurück und behaupte das Gegenteil... ich hab aufgrund der Kondensator-Komponenten-ID "C40" angenommen, das IC im Bild sei U40. U40 sitzt im ersten Bild aber links von dem Kondensator und ist im Bild daher gar nicht zu sehen. Der IC im Bild ist U48 (rechts daneben dann der Kondensator C48), gehört also zu Bank 1, d.h. die Bänke sind gar nicht vertauscht.

    Auf der vorder- und Rückseite gibt es einige Brücken.

    Das ist normal für einen 128er.

    Das kleine Testprogramm gibt in der Tat komischen Output.

    Einmal Ram umgedreht und es funktioniert.

    Ok, dann waren die beiden Bänke vertauscht. Sind bei dem Rechner die Widerstände R29 und R30 über Kreuz gelötet? Das solltest Du dann rückgängig machen - der Rechner funktioniert zwar auch so, aber bei jeder zukünftigen Reparatur an den RAMs ist das ein unnötiger Stolperstein, der einen erst mal in die Irre führt.


    EDIT: Korrektur weiter unten

    Kann sein er sitzt in der zweiten RAM Bank, die vom C64 Modus gar nicht genutzt wird. Und im c128 Modus wird RAM nicht getestet!

    U38 bis U45 sind eigentlich(tm) Bank 0, U46 bis U53 sind Bank 1 - der Rechner sollte so also gar nicht erst starten können.

    Es kann natürlich sein, dass bei diesem Rechner der "löte zwei Widerstände um, um die RAM-Bänke zu tauschen"-Trick versucht wurde...

    Lief das am Ende auf möglichst reines R/G/B hinaus? Dann wird das mit einem Speccy bestimmt auch gut funktioniert haben.

    Weiß ich nicht mehr. Wer einen CPC hat, kann das ja einmal nachprüfen. Einen Speccy hab ich zwar auch nicht, aber die Speccy-Palette kann ich ja per VDC am 128er nachstellen, das probiere ich mal aus.

    Erinnerst Du Dich noch, ob Ihr auch den umgekehrten Weg versucht habt, also nach Farben zu suchen, die in einem Filter möglichst gleich aussehen?

    Ich gehe davon aus, dass wir das genau so versucht haben. Also erst alle Farben gleichzeitig dargestellt und dann nach Paaren gesucht, die man durch ein Brillenglas nicht unterscheiden kann. Ich meine, dass es auch durchaus einige solcher Paare in der VIC-Palette gab, nur gab es leider keine Farbe x, die durch das eine Brillenglas genau wie Farbe y und durch das andere Brillenglas genau wie Farbe z aussah - und nur so eine Farbe hätte als gemeinsame Hintergrundfarbe getaugt.

    Ach ja, es gibt noch ein weiteres Hindernis: Angenommen, in der Palette des vorliegenden Rechners findet man eine solche perfekte Farbe x - dann kann es immer noch passieren, dass die Farben y und z so liegen, dass man durch das eine Brillenglas helle Linien auf dunklem Grund und durch das andere Brillenglas dunkle Linien auf hellem Grund sieht, und das macht dann auch keinen Spaß. :D