letzter Beitrag von ADAC am
Warum haben die das Charrom überhaupt geändert? Ist doch gut lesbar...
Ja, über S-Video mit gutem Kabel. Über HF-Out an TV [EDIT] - und das war wohl der Standard-Anschluss beim Erscheinen des C64 - [/EDIT] wird's eng ... die Breite der Pixel wurde ja ca. halbiert vom VIC-I zum VIC-II hin.
wird's eng ... die Breite der Pixel wurde ja ca. halbiert vom VIC-I zum VIC-II hin.
Die Breite der Pixel muss breiter als eine Periode des Farbtaktes sein damit der NTSC/PAL-Dekoder im Monitor sauber arbeitet. Das war beim VC-20 noch der Fall, beim C64 aber nur wenn man immer 2 Pixel hintereinander hat.
Je nach Dekoder kann das trotzdem gut aussehen, oder eben Farbsäume und Falschfarben geben.
Da dürftest du recht haben, siehe "PLA BAD"-Anzeige bei Diag ... beim C64-CHAR-ROM passiert das nicht, und der "PLA-Test" ist im Wesentlichen ein Bank-Switching-Test (ROMs aus-, RAM einblenden). Geht dem 64er wohl nicht schnell genug ...
Eigentlich müsste er das Char-ROM als 'bad' anzeigen, denn es hat eine andere Prüfsumme als das Original. Tut er nicht, er zeigt die PLA als bad an und ich kann mir nicht vorstellen, daß das Diag-Cartridge das Char-ROM des VC-20 korrekt erkennt und seine Prüfsumme hat. Fehler im Dia-Code?
Das ROM ist jedenfalls schnell genug, ein zu langsames Char-ROM ergibt Schneesturm auf dem Monitor.
Zitat von GerritEigentlich müsste er das Char-ROM als 'bad' anzeigen, denn es hat eine andere Prüfsumme als das Original.
Das verbesserte Diag (586220++) zeigt die Prüfsummen der ROMs an, vergleicht sie aber nicht mehr mit gespeicherten Werten. "PLA BAD" kommt definitiv, wenn das ROM-RAM-Banking nicht klappt. Steht zumindest so im Original-Diag-Handbuch.
Das ist js auch alles, was das Diag an PLA-Test machen kann, andere Funktionen der PLA sind nicht direkt für Code zugänglich.
Das verbesserte Diag (586220++) zeigt die Prüfsummen der ROMs an, vergleicht sie aber nicht mehr mit gespeicherten Werten.
Schlechte Idee. Ich hätte schon gerne einen Hinweis wenn die Prüfsumme nicht stimmt.
"PLA bad" kann nicht am VC20-Char-ROM liegen, denn das ist ja nur Empfänger der PLA. Es sei denn der PLA-Test fährt auch einen Vergleich und erwartet bei eingeschaltetem Char-ROM irgendwo eine Liste bekannter Werte im ROM. Die dann mit dem VC20-Char-ROM natürlich nicht stimmen.
Zitat von Gerrit
"PLA bad" kann nicht am VC20-Char-ROM liegen, denn das ist ja nur Empfänger der PLA.
Doch, das wäre möglich, wenn vom ROM auf RAM umgeschaltet wird und das ROM den Wegfall des CS nicht schnell genug verarbeitet. Dann kracht es beim RAM-Zugriff und Diag gehr davon aus, dass die PLA defekt ist.
Ich werde diese These noch mit einem EPROM überprüfen, einmal mit C64-Inhalt und einmal mit VC-20-Inhalt.
Einmal nur so off topic. Ich habe bis hier jeden Post gelesen.
Für mich seid ihr voll die Cracks. Einfach Hammer, wie ihr euch mit den ganzen Adressen etc. nur
mal so aus dem Stehgreif auskennt. Ich würde das wohl nicht mehr hinkriegen.
Wenigstens habe ich es nun gerafft, warum beim Eprom brennen 2 Byte mehr sein müssen (Kernal).
Ich hoffe, mein Lob bleibt stehen . OFf Topic aus 
Doch, das wäre möglich, wenn vom ROM auf RAM umgeschaltet wird und das ROM den Wegfall des CS nicht schnell genug verarbeitet. Dann kracht es beim RAM-Zugriff und Diag gehr davon aus, dass die PLA defekt ist.
Nein, eben nicht... Das Char-ROM ist ja nur aktiv wenn es auch angesprochen wird, /CS geht spätestens am Ende des halben Zyklus wieder offline und das ROM ist garantiert offline bis das RAM nach /CAS LOW die Daten liefert.
Ansonsten würde der C64 gleich beim Einschalten abschmieren.
Wird eher so sein, daß das Diag-ROM eine Bytesequenz aus dem Char-ROM kennt und beim Test der RAM/ROM-Umschaltung nach dieser sucht. Sequenz gefunden => ROM vorhanden. Sequenz nicht gefunden => ROM nicht da, also PLA kaputt wenn ROM aktiv sein sollte.
Eigentlich müsste er das Char-ROM als 'bad' anzeigen, denn es hat eine andere Prüfsumme als das Original. Tut er nicht, er zeigt die PLA als bad an und ich kann mir nicht vorstellen, daß das Diag-Cartridge das Char-ROM des VC-20 korrekt erkennt und seine Prüfsumme hat. Fehler im Dia-Code?
So, nochmals nachgelesen. Du hast recht 
, es wird beim PLA-Test jeweils das erste Byte (sic!) aus den ROMs gelesen und mit abgespeicherten Werten verglichen. Meine These ist für den Hugo 
...
Die Prüfsummenbildung kommt erst später bei den einzelnen ROM-Tests. Dieser Teil wurde verändert, um mit alternativen Kerneln keine "KERNAL ROM BAD"-Fehler zu bekommen, und es wurde eine Liste mit 49 alternativen Kerneln (bzw. deren Prüfsumme) eingebaut; diese werden namentlich ausgegeben oder aber bei unbekannten nur die Prüfsumme. Das finde ich jetzt nicht so verkehrt.
Dass das Diag nicht mit einem VC-20-CHAR-ROM rechnet verzeiche ich ihm jetzt mal. 
[EDIT: Typos]
Etwas OT ... wer noch das Gegenbeispiel sehen will, einen VC-20 mit C-64-CHAR-ROM, bitte schön:
Sieht aber nicht so schön aus wie umgekehrt, finde ich.
(Ich hatte grad Gelegenheit dazu und offensichtlich zu viel Zeit 
... erfordert: C-64-CHAR-ROM in VC-20 stecken, Pin 21 hochbiegen und auf +5 V legen)
Ich finde das aber garnicht so schlecht... hat auf jedenfall was. 
