Du kannst dir Bits nehmen, so viele du willst.
Nur kotzen gilt nicht.
![]()
Du kannst dir Bits nehmen, so viele du willst.
Nur kotzen gilt nicht.
![]()
Bald habe ich verstanden, wie das Ding funktioniert.
Ähm ... die Erkenntnis ist dann, dass es eigentlich nicht funktionieren kann, sondern nur so aussieht. ![]()
Dann leg ich mir endlich auch sowas zu.
Sag Bescheid, ich nehm auch zwei! ![]()
Aber immer wieder aus dem ROM? Nicht aus $0400-$07E7 (->Screen RAM)?
Aus dem RAM wird der Zeichencode gelesen. Die zum Zeichencode zugehörigen Char-Daten (pro Zeichen acht Byte zu je acht Bit) werden aus dem Char-ROM gelesen. D. h., der 40x12-Videopuffer wird eben mit den Screencodes aus dem RAM gefüllt.
Details siehe Bitte melde dich an, um diesen Link zu sehen. .
Ein Char = 8x8 Pixel - die normalen Buchstaben sind aber nur 6 Pixel breit, also links und rechts einer leer. Sonst würden sich zwei nebeneinanderstehende Buchstaben berühren, wie es bei den Linien ja möglich und gewollt ist.
Wo du recht hast ... ![]()
Ach so? Ich dachte das wird nur einmal aus dem ROM gelesen und in den Bildschirmspeicher geschrieben und der VIC zeigt dann nur aus dem das Bild an. Aber wenn das bei jedem Frame neu aus dem ROM gelesen wird, ist ja richtig was los auf dem Bus.
Nein, der VIC hat nur eine (Text-) Zeile Zwischenspeicher (40 Chars x 12 Bits; 8 Char-Bits und 4 Color-Bits).
Das wird bei jedem Frame neu eingelesen. Zeile für Zeile.
Ja, hab ich inzwischen auch so (wieder)entdeckt. Da der Pixel in jeder der 8 Zeilen pro Char fehlt, klemmt Bit 6 offenbar auf "Null".
Eher Bit 7, MMN.
Natürlich nur, wenn auch vom CHAR gelesen wird. Das dürfte bei der Einschaltmeldung ja nur relativ kurz sein. Aber beim Diag ist da vielleicht mehr Bewegung.
Naja, "kurz" ... halt in jedem Frame die oberen Zeilen.
Vielleicht ist es auch Bit 1? Bin mir jetzt nicht sicher, wie ein Char aufgebaut ist, ob von links nach rechts oder rechts nach links.
Nein, Bit 7 ist ganz links im Char, Bit 0 ganz rechts.
Nur /CS. Die Datenleitung sind am Bus. Der Bus funktioniert augenscheinlich. Wenn da ein Bit hängen würde, würde wohl kein Programm laufen.
Genau.
Wenn es das CHAR ROM ist, dann spuckt das bei Bit 6 eben immer ein Null statt der eigentlich gespeicherten Daten aus. Dann ist vermutlich im IC die Verbindung zwischen dem Die und dem Pin wegkorrodiert.
Genau.
Äh, ja, aber das Prinzip bleibt gleich. Der '373 ist IM 64-Pin-Custom-IC integriert. ![]()
Links von den Zeichen fehlt etwas. Beim Deadtest ist es nicht, aber bei Diag
und Normalbetrieb.
Da es beim Dead Test klappt -> VIC OK.
Der Dead Test bringt seinen eigenen Zeichensatz im RAM mit.
Der VIC greift auf das Char-ROM zu, in dem er selbiges über A0..A7 via 74LS373 adressiert und die Daten über den Datenbus holt. Also wird entweder das Char-ROM nicht richtig adressiert oder der Pin D7 am Char-ROM hat keinen Kontakt (oder das Char-ROM ist defekt).
Könnte man überprüfen, wenn man das Char-ROM ausliest. Man braucht ein kleines BASIC-Programm, das Interrupts ausschaltet, das Char-ROM via $01 einblendet und dann ausliest.
Was kommt beim Diag nach "PLA BAD", wenn er die ROMs testet?
Aber ohne Modul Hellblauer Rand, dunkelblauer Hintergrund (wie CBM original),
aber keine Buchstaben.
Das:
Eher BASIC. Ist beim EPROM brennen vielleicht was schiefgegangen. Oder hast du die Originale drin?
1 x BASIC reicht vermutlich nicht. Was hast du mit Pin 1 (A15) des 27C512 gemacht? Auf der Platine liegt das auf Vcc, WIMRE. Dann müsstest du brennen:
Dann kommt es noch auf A14 an, da weiß ich jetzt nicht, wo dieser Pin am Sockel hinführt. Abhilfe, um ganz sicher zu gehen:
Läuft soweit.
D. h., es war wirklich R/W?
Korrektur - das RAM bekommt R/W vom PLA:
Bitte melde dich an, um diesen Anhang zu sehen.
Wie gehabt, immer einmal weiß blinken und der
Ultimate Ram Test von GI Joe lauter C auf dem Screen.
Einmal weiß blinken: Vermutlich schlägt bereits der allererste RAM-Zugriff fehl.
Stellt sich die Frage: Was lässt ROM-Zugriffe unberührt, beinflusst aber RAM-Zugriffe ... ?
Ist die R/W-Leitung intakt von CPU zu Expansion Port, RAM, CIAs, SID, VIC, ... ?
das ist mir bekannt
Idealerweise sollte es so sein. Hast Du das persönlich verifiziert ?
Ja, ich habe den Dead Test disassembliert, kommentiert, verschlimmbessert und neu assembliert. Das mit dem RAM ist so.
ZitatIch hatte nämlich schon den Fall, dass das Deadtest-Modul kein Bild gebracht, das ULTIMAX-RAM-Checker-Modul jedoch schon, wenn auch mit wirren Zeichen, wovon man dann zumindest weitere Schlüsse ziehen könnte ...
Das hatre ich auch schon ein paar Mal undmich immer gewundert, warum das so ist. Aus dem Code kann ich keine Erklärung ableiten.
ZitatBei einem "initialen RAM-Test" ohne irgendeine Ausgabe kommt man wenig weiter, wenn Dieser fehlschlägt/sich aufhängt
Das ist der Grund, warum ich den Dead Test gepatcht habe.
nimm mal nicht den DeadTest sondern das ULTIMAX-RAM-Checker - Modul.
DAS benötigt keinen RAM im StepBitte melde dich an, um diesen Link zu sehen. (auch keinen Stack !)
Das benötigt der Dead Test auch nicht, der startet auch im Ultimax Mode.
Der gesamte "Initial RAM Test" wird ohne RAM, nur unter Zuhilfenahme der Register A, X, Y und S durchgeführt.
und auch ohne die oben entfernten IC's!
Bei einer 250469 musst du dann aber PA0 und PA1 von CIA2 (aka. VA14 und VA15) manuell auf VCC legen, sonst stimmt die VIC-Bank nicht. Das 64-Pin-Custom-IC mag keine offenen Eingänge und interpretiert diese nicht als "H".
Unabhänig davon: Welche Revision ist es denn nun? Frage für kinzi.
Du hattest recht mit Rev 3. Weiß nicht wie ich auf C gekommen bin
... ich werd alt ...
Willkommen im Club. ![]()
Wieso, ist jetzt das ROM schon draußen?
Jo, dann Rom raus und ein Winbound EEprom brennen.
Habe keine Eproms mehr
Habe zwar nur 27C512, aber dann kann ich 1. 8k Basic und 7malCBM draufbrennen
Ich würde kein EPROM brennen.
Der Dead Test läuft ohne ROM. Kommt die Kiste nicht hoch, sind es [vermutlich] die RAMs.
Jjau, jetzt sind wir gleich weit
...
ROM oder RAM? ![]()
Keine Ausreden!
Durchführen!
![]()
..Ich glaube ich fahre morgen Abend das Teil holen
Bitte melde dich an, um dieses Medienelement zu sehen.