Hallo Besucher, der Thread wurde 17k mal aufgerufen und enthält 60 Antworten

letzter Beitrag von Draco am

Neues von der Diagnoseplatine

    Zitat von JMP$FCE2

    ...und das die Adressleitungen nicht blockiert sind ;)


    Einen eingeschränkten NOP Genrator könnte man schon mit dem EasyFlash erzeugen:


    + Blöcke $8, $A und $E mit NOP befüllt. Am Ende der 8KB jeweils JMP zum nächsten Block


    + Falls der RAM funktioniert und die PLA: auf 64K RAM schalten und alles mit NOP füllen

    Zitat von Diddl

    Einen eingeschränkten NOP Genrator könnte man schon mit dem EasyFlash erzeugen:


    + Blöcke $8, $A und $E mit NOP befüllt. Am Ende der 8KB jeweils JMP zum nächsten Block


    + Falls der RAM funktioniert und die PLA: auf 64K RAM schalten und alles mit NOP füll



    Das macht aber keinen Sinn. Wenn eine der Adressleitungen blockiert ist (und das ist ja eigentlich der Hauptsinn des NOP-Generator Testes)
    dann wird ein EF auch nicht mehr funktionieren...


    Dann lieber Hartverdrahtet im Zwischensockel.

    Ok, dann macht es Sinn, erst mit dem NOP Gen + Prozessoranzeige zu testen. Falls das wie gewünscht gleichmäßig raufzählt kann man das Diagnoseprogramm in Einsatz bringen.


    Problematisch ist nur, dass die CPU meistens nicht gesockelt ist.


    ------


    Ich werde mal bei Donald eine Prozessoranzeige bestellen und das testen.


    -------


    Sinn würde es machen, anstatt einer Diagnoseplatine eine ganze Palette an Diagnose Hardware anzubieten:


    + Prozessoranzeige


    + NOP Genarator


    + Diagnose Modul


    + Diagnose Stecker für alle Interfaces: Userport, Kassettenport, Joystick, Keyboardstecker ...

    Zitat von Diddl

    Sinn würde es machen, anstatt einer Diagnoseplatine eine ganze Palette an Diagnose Hardware anzubieten:


    + Prozessoranzeige


    + NOP Genarator


    Den NOP Generator könne man auch gleich zuschaltbar auf der Prozessoranzeigeplatine unterbringen, sofern
    die Prozessoranzeige eine CPU Zwischensockelplatine ist.
    Da braucht es eigentlich nur 2x 4066 um die Datenleitungen vom Bus weg auf $EA zu schalten.



    Zitat von Diddl


    + Diagnose Modul


    + Diagnose Stecker für alle Interfaces: Userport, Kassettenport, Joystick, Keyboardstecker ...


    Sowas gibt es ja eigentlich schon seit langen.

    Zitat von JMP$FCE2

    Hmm. Schade, ein NOP Generator wird am Expansionsport nicht gehen.


    Ne, nicht wirklich.



    Aber wenn du eine NOP Adaptersockel anbietest, würde ich ihn sofort nehmen! Für 6510 und 6502, kann beide brauchen.


    oder würde sogar ein Adaptersockel gehen?



    Edit: Ne verflixt, Pin Belegung von 6502 und 6510 sind grund-verschieden ... :(



    6502.gifmos6510.jpg

    Zitat von Diddl

    Aber wenn du eine NOP Adaptersockel anbietest, würde ich ihn sofort nehmen! Für 6510 und 6502, kann beide brauchen.


    oder würde sogar ein Adaptersockel gehen?


    Anbieten wohl eher nicht, aber ich könnte mir mal was zum Nachbau ausdenken.


    Das Pinout vom 6502 weicht ziemlich vom 6510 ab, das könnte man aber notfalls auch mit 4066 erschlagen.


    Diddl: stell doch mal sowas wie ein Pflichtenheft für deine Wünsche auf.


    Ich könnte mir vorstellen: Anzeige der Adressleitungen und Datenleitungen über LED
    Anzeige ob Takt vorhanden oder nicht über LED
    Zuschaltbarer NOP-Generator
    Umschaltbar zwischen 6502 und 6510


    Zwischensockel ist aber unumgänglich.

    Zitat von JMP$FCE2

    Ich könnte mir vorstellen: Anzeige der Adressleitungen und Datenleitungen über LED
    Anzeige ob Takt vorhanden oder nicht über LED
    Zuschaltbarer NOP-Generator
    Umschaltbar zwischen 6502 und 6510


    Genial!


    Vielleicht noch ein Resettaster?


    Umschaltbar muss gar nicht sein, wäre aber optimal! Wenn es kompliziert oder gefährlich (Fehlbedienung) ist, wären vielleicht zwei Adapter besser?

    Zitat von JMP$FCE2

    2 Adapter kann man auch verwechseln ;)


    Aber ich würde es natürlich so gestalten das bei Fehlbedienung nicht gleich der Prozi oder der Rest gehimmelt wird.
    > Serienwiderstände z.B.


    Oder gleich David-65 (die 6502 Platine), von der ich mit Nils geträumt habe ...
    ... die kann das nämlich auch alles und viel mehr. ;)



    Aber natürlich wäre der Adapter auch suuuper!

    Ich hatte mir das so gedacht,daß auf die Prozessoranzeigeplatine ein Expansionsportsockel mit draufkommt,um bei Bedarf den NOP-Tester draufzustecken.
    Wenn ich das hier so richtig verstanden habe,geht das nicht?
    Ich hatte den Schaltplan von mir so verstanden,daß der NOP-Tester in den Expansionsport gesteckt wird. :gruebel

    Zitat von OSSI64

    Ich hatte den Schaltplan von mir so verstanden,daß der NOP-Tester in den Expansionsport gesteckt wird. :gruebel


    Richtig Sinn macht der NOP tester nur direkt an der CPU, da muss ich JMP leider recht geben. Mir wäre eine Expansionport Lösung auch lieber ...



    Der NOP tester beruht darauf, dass die CPU am Datenbus nur noch "NOP" sieht. Dazu muss natürlich der Datenbus der CPU getrennt werden. Denn sonst würde die CPU je nach Adresse etwas sehen, was das der Adresse zugehörige Peripherie Teil "sendet", bzw. am Datenbus anlegt.


    ===


    Weiter gehts da: Brainstorming C64 Diagnose Hardware

    Nachdem ein Programmierer gefunden wurde, wird es das Diagnosemodul ja vielleicht doch noch gebaut?!


    Um den EasyDiag-Thread nicht zu kapern, schreibe ich hier noch ein paar Ideen dazu auf.


    Ich fänd es gut, wenn möglichst viele Testergebnisse über die LEDs abzulesen wären. Was wäre zum Beispiel, wenn nur der HF-Modulator geschossen wäre? Man hätte keine Anzeige auf dem Monitor und über die Diagnoseplatine würde man auch nichts sehen. Man könnte sehen, dass kein Speicherfehler vorhanden ist aber alle Tests die nur eine Ausgabe auf dem Bildschirm machen bleiben geheim. Die Ursache für kein Bild könnte doch mehrere Gründe haben, oder?
    Ich stelle mir die Anzeige in etwa so vor: Wenn ein LED (nennen wir sie LED A) leuchtet, dann weiß ich, dass es einen Speicherfehler gibt und an den 8 LEDs kann ich den Speicherbitfehler ablesen. Wenn es keinen Speicherfehler gab, dann leuchtet LED A auch nicht aber ich sehe vielleicht, dass LED 1 und 3 leuchten, LED 2 blinkt und alle anderen LEDs aus sind. Daran könnte ich sehen, das Test 1 und 3 erfolgreich waren aber Test 2 einen Fehler festgestellt hat. Außerdem sehe ich, dass Test 4 gerade läuft oder das System sich bei Test 4 aufgehängt hat. Wenn LED A aus und LED 1 bis 8 alle an wären (nicht blinkend), dann wüsste ich, dass alle Test durchgelaufen sind und das Modul keinen Fehler feststellen konnte.
    Halt irgend eine Anzeige so in der Art. Wäre es möglich das so umzusetzen? Ist das nur eine Softwarefrage oder müsste da am Layout auch noch etwas für angepasst werden? Eine zusätzliche ausfürliche Anzeige auf dem Bildschirm wäre natürlich super falls der C64 noch ein Bild darstellt.


    In wie weit könnte man durch geziehlte Tests die Hardware unterscheiden? PAL/NTSC und die unterschiedlichen Kernal-Versionen sollte man ja unterscheiden können aber geht auch mehr? Könnte die Software auf dem Modul z.B. durch geziehlte Tests auch erkennen, welcher SID eingebaut ist, PLA und MMU unterscheiden oder vielleicht noch andere "Eigenheiten" von bestimmten Board-Revisionen erkennen? Ist natürlich nicht so wichtig aber ich fänd es klasse, wenn man noch so viele Informationen wie möglich auf dem Bildschirm angezeigt bekommen würde.
    Natürlich sind die eigentlichen Tests auf Fehler viel wichtiger und das hier nur Nice-to-have, wenn dem Programmierer zum Schluss langweilig wird. ;)

    Zitat von Cyberdyne

    Ich fänd es gut, wenn möglichst viele Testergebnisse über die LEDs abzulesen wären. Was wäre zum Beispiel, wenn nur der HF-Modulator geschossen wäre?


    Das sehe ich auch so. Die LED müssen in allen möglichen Situationen möglichst aussagekräftig sein.


    Was alles passieren kann bei defekten Boards können wir nur empirisch im laufen von Monaten oder Jahren ermitteln. Es wird immer Boards geben die die Grenzen der Diagnosesoftware aufzeigen werden. Ich denke an dem Teil kann man sehr sehr lange verbessern ...



    Zitat von Cyberdyne

    Halt irgend eine Anzeige so in der Art. Wäre es möglich das so umzusetzen? Ist das nur eine Softwarefrage oder müsste da am Layout auch noch etwas für angepasst werden? Eine zusätzliche ausfürliche Anzeige auf dem Bildschirm wäre natürlich super falls der C64 noch ein Bild darstellt.


    Mit Software ist prinzipiell alles umsetzbar.


    Man darf aber nicht vergessen dass der Software ohne RAM die Hände gebunden sind. Alles ist ziemlich schwierig wenn ich nix mehr zwischenspeichern kan, nur noch die drei 8 Bit Register habe.


    Auch die Modularität der Software lässt zu wünschen über wenn man nicht mal Unterprogramme (JSR) hat, weil kein Stack die Rücksprungadresse speichert.


    Beim EF kann man wenigstens die 256 Bytes des EF RAM benutzen. Bei der Diagnose Platine, ganz ohne RAM ist man sicher etwas eingeschränkt was die Diagnose eines RAM Fehlers angeht.


    Aber die Anzeige der Bank geht schon irgendwie. Es muss halt einfach die Code Länge herhalten ...



    Zitat von Cyberdyne

    In wie weit könnte man durch geziehlte Tests die Hardware unterscheiden? PAL/NTSC und die unterschiedlichen Kernal-Versionen sollte man ja unterscheiden können aber geht auch mehr? Könnte die Software auf dem Modul z.B. durch geziehlte Tests auch erkennen, welcher SID eingebaut ist, PLA und MMU unterscheiden oder vielleicht noch andere "Eigenheiten" von bestimmten Board-Revisionen erkennen? Ist natürlich nicht so wichtig aber ich fänd es klasse, wenn man noch so viele Informationen wie möglich auf dem Bildschirm angezeigt bekommen würde.


    Ich habe von Erkennung der Hardware Komponenten noch keine Ahnung. Dieses KnowHow muss ich/man erst zusammentragen.


    Machbar ist das sicher, das fällt aber schon eher in den Bereich des zweiten Projekt. Diagnose Hardware


    Die EasyDiag Lösung sehe weniger als Analyse Tool sondern als Werkzeug für Notfälle bzw. Erkennung defekter Bauteile.


    Die Diagnose Karte kann 8 oder 16 KB Eprom zur Verfügung stellen. Soviele Kernelvarianten kann ich gar nicht abbilden wie es gibt. Am PC bin ich da viel freier, soviele Kernelversionen gibt es gar nicht, wie ich im RAM Platz habe. Von der Festplatte ganz zu schweigen ...

    Zitat von Cyberdyne

    In wie weit könnte man durch geziehlte Tests die Hardware unterscheiden? PAL/NTSC und die unterschiedlichen Kernal-Versionen sollte man ja unterscheiden können aber geht auch mehr? Könnte die Software auf dem Modul z.B. durch geziehlte Tests auch erkennen, welcher SID eingebaut ist, PLA und MMU unterscheiden oder vielleicht noch andere "Eigenheiten" von bestimmten Board-Revisionen erkennen? Ist natürlich nicht so wichtig aber ich fänd es klasse, wenn man noch so viele Informationen wie möglich auf dem Bildschirm angezeigt bekommen würde.


    Suchst du sowas wie http://noname.c64.org/csdb/release/?id=89406?

    Hallo,


    da ich ja nun eine (wenn auch sehr kleine) software fuer die diagnose platine (DP) schreibe, wuerde ich mich doch sehr freuen, wenn die ein kleines bisschen EasyFlash (EF) kompatibel bei der ansteuerung ist.


    da ich aus dem lesen des schaltplans nicht so ganz schlau wurde, schreibe ich hier nun, wie ich gerne die platine bedienen wuerde.


    schreiben nach $de02 (oder, da ja kein adress dekoder vorhanden ist, schreiben nach $de00-$deff):
    bit 7:
    %0....... -> led9 aus
    %1....... -> led9 an
    bits 6..3:
    %.xxxx... -> frei, z.B. fuer led10
    bits 2..0:
    %.....100 -> RAM (modul aus)
    %.....101 -> Ultimax Modus (ist der start-modus beim DP)
    %.....110 -> 8k modus
    %.....111 -> 16k modus
    %.....00x -> RAM oder Ultimax je nach boot schalter (ist der start-modus beim EF)
    %.....01x -> reserviert
    aber da es (anscheinend) keinen solchen boot schalter auf der DP gibt, einfach beim schrieben das bit immer setzten, die platine ignoriert es aber


    und dementsprechned schreiben nach $df00-$dfff setzt die leds 1-8.


    durch diese minimale kompatibilitaet ist es moeglich das modul, auf dem EF oder in VICE zu testen - und das wuerde die programmierung erheblich vereinfachen. (natuerlich ohne led10, kein (manuelles) banking, leds 1..8 sind dann im EF-Ram auszulesen)


    wie waere es, anstatt der led10 ein ein bit banking register zu nehmen?


    wenn auf der DP nur baenke a 8k sind, kann man selbst das banking ueber einen trick EF kompatibel machen.


    vorschlag: "parallel" zum dip: per software kann von bank 0 nach 1 (bzw. 2 nach 3) (und zurueck) geschaltet werden, aber wenn bank 1 (bzw. 3) per dip eingestellt ist kann per software nicht geschaltet werden


    wie geasgt, bin ich da bis jetzt nicht so in der tiefe drinne... aber lernfaehig.


    und wenn man mir sagt, was moeglich ist, kann ich noch speziellere vorschlaege machen... skoe kennt das schon :-)


    EDIT: oder lese ich den schaltplan so, dass es ein 64k EPROM und 4 (manuelle) baenke a 16k sind? wenn ja, dann ist der banking vorschlag von oben nicht mehr so wichtig (und der trick, das banking EF kompatibel zu machen, funktioniert dann auch nicht mehr). aber mir wurde bis jetzt gesagt, dass es ein 32k EPROM mit 4 (manuellen) 8k baenken ist.


    Ciao, ALeX.