Posts by Mac Bacon

    EDIT: zu langsam...

    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.

    Wobei das Spiel ja für den C64-Modus ist. Würde mich wundern wenn man dort etwas eingebaut hätte um die 2 MHz auszunutzen.

    Zum Entpacken ist das naheliegend und nicht ungewöhnlich, beim Exomizer wird es z.B. explizit in der Anleitung erwähnt. Dass die 2 MHz für das tatsächliche Spiel genutzt werden, kommt zwar auch vor (Uridium, Paradroid Redux, ...),, aber wahrscheinlicher ist wohl, dass der Coder einfach bei der VIC-Initialisierung die Schleife zu groß gemacht hat und versehentlich eines der beiden unteren Bits von $d030 setzt.

    Interessant finde ich bei diesen Klötzchenbildern immer, wie es der VIC schafft, soweit initialisiert zu werden, dass er überhaupt ein Bild macht.

    Mir fallen zwei Wege ein:

    1. Wenn die CPU in der Resetroutine den VIC initialisiert, kommen beim VIC falsche Daten an (kalte Lötstellen, schlechte Leiterbahnen, etc.). Nur müssten dann die aus RAM und Char-ROM gelesenen Daten ähnlich instabil/kaputt sein.

    2. Eine defekte PLA selektiert fälschlicherweise den VIC, so dass alle von der CPU auf den Bus geschriebenen Bytes in den VIC-Registern landen.

    Fallt dir zu den "B"s an $0328 bzw. $03A8 (relativ zur Basis) spontan was ein?

    Ich komme auf die Offsets $350 und $3d0 (jeweils 40 mehr)... aber nein, keiner der Werte sagt mir was.

    Die erste Zeile ist auch nicht immer gleich angefressen. Da scheint noch ein "Timingfaktor" eingebaut zu sein.

    Die vertikalen Scrollbits befinden sich im gleichen VIC-Register ($d011) wie das Bit für den 24-Zeilen-Modus. Wenn in den Scrollbits unterschiedliche Werte stehen können, sollte man eigentlich erwarten, dass auch das 24-Zeilen-Bit mal einen anderen Zustand bekommt.

    Das nächsthöhere Bit im Register ist übrigens "Display Enable", das könnte erklären, dass manchmal überhaupt kein Bild kommt - aber das ist jetzt wirklich schon sehr spekulativ.

    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...

    Files

    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.

    Files

    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...