Posts by FranticFreddie

    Aus aktuellem Anlaß möchte ich hier mal meine Erfahrung zum Thema abgeben.


    Ich hatte die letzten beiden Tage zwei 425er Boards getestet.

    Beide liefen absolut problemlos, C64 Diag. auch fehlerfrei.


    Jedoch funktionierte bei beiden Sam's Journey in der Modulvariante nicht (andere, wahrscheinlich einfachere Module liefen)


    Bei dem einen Board hat's beim Start nur zweimal kurz plöp plöp gemacht, Bildschirm blieb schwarz.

    Beim Anderen ist das Spiel ab uns zu mal gestartet, nach der Kartenauswahl folgte dann aber sofort der Absturz, manchmal auch noch ein Reset.


    Bei beiden hatte ich auf Verdacht die PLA getauscht

    --> Sam läuft wieder :)

    Moin,


    ich habe mir gerade die Pinbelegung vom HR 7506 angeschaut.

    Der nicht passende Pin ist auf diesem Plan mit 11 bezeichnet und steht direkt im Zusammenhang mit dem Screen und Focus Poti.


    Das könnte der Grund sein warum ein Verstellen dieser Potis bei dir keine Wirkung zeigt :)


    Also das "fump fump..." kenne ich auch und das ist wahrscheinlich das von mir bezeichnete "Übersteuern"

    Das sollte aber aufhören, sobald der Screen Regler runtergedreht wird.


    Wenn das bei dir aber nix bringt, dann bin ich leider überfragt... :nixwiss:

    Dann musst du wohl abwarten bis sich hier jemand meldet, der auch Ahnung von der Materie hat :)


    Welche Potis meinst du eigentlich mit "zur Einstellung von H/V & Co mal hin- und hergeregelt"

    Das Problem mit dem versetzten Masse Pin hatte ich auch schon einmal bei einem eBay Trafo.


    Ich habe es damals so gelöst, indem ich an der passenden Stelle ein weiteres Loch für diesen Pin gebohrt habe.

    An der Stelle ist eine große Massefläche, dort den Lack etwas entfernt und angelötet.

    Ich musste dann aber zusätzlich noch die anderen Löcher etwas aufbohren bis er endlich gepasst hatte :motz:


    Aber seitdem läuft er wieder ohne Probleme!


    Und ja, Screen und Focus musst du dann einstellen.

    Focus bis das Bild maximal scharf ist.

    Das Screenpoti nicht zu hoch drehen, sonst "übersteuert" man die Regelung.

    Aber das merkst du dann schon :)


    Viel Erfolg!

    Es gibt laut Dönbergs Homepage mindestens drei verschiedene AT2079 Typen (HR7488, HR7533 und der 7506)


    Ich habe mal in den Schaltplan vom CM8833 die Pinnummerierung von meinem 8802 eingetragen.

    Wenn man diese mit dem Schaltbild vom HR7506 vergleicht, dann sieht es passend aus (nur bei Pin 2,5,6 gibt es Abweichungen, aber ich denke das passt trotzdem)


    Der von mir gepostete Schaltplan weiter oben passt an der Stelle mit dem Zeilentrafo überhaupt nicht.

    Ich habe deshalb die Verschaltung anhand der Platine nachvollzogen und mit den Schaltplänen vom HR7506 und dem HR7533 abgeglichen.


    Der HR7506 scheint zu passen, der HR7533 passt von der Belegung gar nicht.


    Ich habe mir jetzt einen neuen auf Ebay bestellt.

    Der sieht dem Originalteil sehr ähnlich.


    Ich hoffe mit dem habe ich mehr Glück.


    Interessant wäre es natürlich zu wissen, welchen Typ und Hersteller SamW eingebaut hatte.

    Er hatte ja auch dieses Problem.

    Meinen Ersatz habe ich hier gekauft:

    https://www.donberg.de/descript/h/hr_7506.htm


    Ich war damals schon verunsichert ob es der richtige ist, aber der HR7488 hat 11 Pins, ich brauche aber einen mit 9 Pins.

    Es konnte also nur der HR7506 sein.

    In der Beschreibung von Dönberg steht außerdem beim HR7506 auch der AT2079 dabei.


    Den Originalen Trafo habe ich nicht mehr.

    Auf dem vom 1084 steht folgendes: E39144, TYPE AT2079, 30102 TY, 8915


    Bei dem hier

    http://www.williges-elektronik…fo-toshiba-at2079-17.html

    ist leider kein Pinout dabei...
    Muss ich mal anfregen, der ist ja vergleichsweise günstig.


    SamW: Bei welchen Trafos ist denn bei dir das Problem aufgetreten?

    Hallo Leute,


    nachdem die Fehlersuche mit Wärme auch nicht erfolgreich war, habe ich mir aus einem 1084 den Zeilentrafo geborgt und in den 8802 eingebaut.

    Und siehe da, der Fehler war weg!!!

    Zur Sicherheit auch noch die Gegenprobe gemacht und den Zeilentrafo vom 8802 in den 1084 eingbaut --> Das Flimmern ist mitgewandert.


    Die Ursache ist also endlich gefunden ---> Der Zeilentrafo!!!


    SamW hatte den Hinweis anfangs ja schon gegeben, ich hielt es aber einfach zu unwahrscheinlich, dass dieses Phänomen aufgrund von defekten Zeilentrafos auftreten soll, und das der Fall dann auch schon drei mal eingetreten ist. Zumal meiner ja auch "neu" ist.


    Oder kann es sein, dass die "neuen" Trafos andere elektrische Eigenschaften haben wie die alten und diese gar nicht defekt sind?

    Vielleicht muss irgendwo etwas angepasst werden, damit der Trafo verwendet werden kann?


    Original war ein AT2079 eingebaut, als Ersatztyp habe ich einen HR7506 besorgt.

    Schade um das Geld, einen weiteren HR7506 zu besorgen ergibt dann ja irgendwie auch keinen Sinn... :nixwiss:

    So, heute hat mich wieder einmal der Ehrgeiz gepackt und ich habe mich noch einmal einige Stunden an meinen Monitor gesetzt.

    Leider immer noch ohne Erfolg.


    Ich verstehe einfach zu wenig die Monitortechnik um messtechnisch den Fehler einzugrenzen bzw. um eure Ratschläge ohne weitere Hilfe umzusetzen.


    Da ich mittlerweile einen zweiten und baugleichen Monitor habe, kann ich Teile zum Testen quertauschen.


    Ich habe zur besseren Übersicht einen zusammenhängenden Schaltplan gebastelt.

    Im Schaltplan habe ich alle Stellen grün markiert, welche ich als Fehlerquelle bereits ausschließen kann.

    Außerdem noch alle Elektrolytkondensatoren, die sind schon von mir getauscht.


    Durch Kälte und mechanische Beanspruchungen (klopfen, biegen) konnte ich keine Beeinflussung des Fehlers feststellen.


    Ich habe auch einige Signale mit meinem Oszilloskop nachgemssen.

    Leider konnte ich nichts auffälliges feststellen, aber mir fehlt da auch die Erfahrung um beurteilen zu können ob das so in Ordnung ist.


    An welcher Stelle im Schaltplan finde ich den von Computerbastler genannten Sync-Separator und die Triggerschaltung? :rolleyes:


    Wenn Ihr mir sagt wo ich was messen soll, dann stelle ich die Ergebnisse gerne hier ein.


    Ich bin weiterhin für jeden Tip von euch dankbar und offenbar auch angewiesen.

    Ich will den nervigen Fehler endlich loswerden :)

    Hallo zoidberg,


    Im Beitrag 7 hatte ich nur das Problem mit der Abfrage der Rasterzeile behoben.


    Mein zweites Problem war, dass durch den Aufruf der Systemroutine $ffd2 (Zeichen ausgeben) mein vorangegangener Befehl SEI zum verhindern der Interrupts wieder aufgehoben wurde.

    Die Lösung ist einfach, der Befehl SEI muss nach dem Aufruf von $ffd2 eingefügt werden.

    Ich habe es jedesmal am echten C64 getestet.

    Im Emulator läuft es auch nicht sanft durch, aber das Verhalten ist ein anderes im Vergleich zur echten Hardware.


    Dachte so ein kleines Progrämmchen wäre gut für den Einstieg geeignet.

    Hab nicht geglaubt, dass es so viele Probleme bereiten würde.


    Gibt es noch irgendwelche Tests die ich durchführen könnte um das Problem weiter einzugrenzen?

    Mich würde wirklich die Ursache interessieren.

    Hallo Neptun und Mac Bacon,


    danke für die Hinweise, das leuchtet mir ein.

    Ich werde das auch mal mit dem Interrupt versuchen, würde aber trotzdem gerne verstehen, warum das so nicht klappt.


    Ich habe jetzt mal versucht die beiden Abfragen auf $fe und $ff in mein Programm einzubauen.


    Lieder ruckelt es immer noch.

    Drei mal pro Bewegungsablauf hakt es kurz.

    Hab ich bei der Abfrage was falsch gemacht oder gibt`s noch ein weiters Problem?


    @ Endurion

    In den Zeilen 28-30 frage ich bereits das Rasterregister auf Zeile 0 ab:


    loop2

    lda $d012 ; Warte auf Rasterzeile 0

    bne loop2

    Das verlangsamte schon, aber das Sprite flitzte trotzdem noch zu schnell über den Bildschirm, aus dem Grund noch der Aufruf der Verzögerungssroutine.

    Außerdem war meine Idee, immer die Rasterzeile 0 abzuwarten, und dann im nicht sichbaren Bereich die Positionsregister der Sprites neu zu beschreiben.

    Damit wollte ich das Ruckeln verhindern.


    Einen besonderen Grund das Programm bei $c000 abzulegen gab es nicht.

    Das könnte ich anpassen.


    @ oobdoo

    Mit dem SEI wollte ich während meines Programmablaufs die Interrupts deaktivieren um auszuschließen, dass das Ruckeln des Sprites von irgendwelchen Interrupts verursacht wird.


    Aber trotz deaktivierter Interrupts und warten auf Rasterzeile 0 ruckelt es trotzdem noch X(


    Was könnte das denn noch sein?