Hello, Guest the thread was called8.4k times and contains 144 replays

last post from kinzi at the

"Dead Test++" - Ideensammlung / Brainstorming

  • Wir müssen ja nicht beide das volle lehrgeld bezahlen.

    Das ist schon mal prima. :thumbup: Noch steht ja nicht fest, was es wird und wie es ausschauen soll, aber es ist gut zu wissen, dass irgendjemand schon mal ähnliche Probleme gewältzt hat. ^^

    Beim Swinsid gab es ja auch schon die Lese und Schreibproblematik, selbst bei 24Mhz Takt wollte es mit dem 8 Bit Datenbus schreiben nicht klappen (Padde Lesen), und wir brauchen noch 16 Pins für den Adressbuss...

    Man kann ja auch durchaus mal mit nur lesen anfangen und das darstellen, was da erkannt wird. Es muss ja nicht gleich die volle Dröhnung von Anfang an sein. Mir ist an anderer Stelle schon mal vorgeschwebt, nur A8..A15 zu belauschen, dann wüsste man schon mal die Page, wo s sich abspielt, das lässt schon viele Rückschlüsse zu, was geht und was nicht.

  • Ist die notwendige Hardware nicht bereits vorhanden? Nämlich die 1541U2:

    • Eigener Prozessor
    • Kann den 6510 in den Ruhezustand versetzen und die C64-Hardware mit einem eigenen Prozessor steuern.
    • Menüsystem, das auch bei defektem Speicher verwendet werden kann.


    Das Einzige, was geschrieben werden sollte, ist eine angepaste Software für den ZPU-Prozessor ins 1541U2, die die Hardwarekomponenten im C64 testet.


    Wenn man von vorne anfangen würden, würden man das Rad einigermaßen neu erfinden: Man braucht einen Prozessor auf der Cartdrigde und die gesamte Logik, die den 6510 in den Ruhezustand versetzt und dann den C64 über den Cartridgeanschluss steuern musst, neu aufgebaut werden. Obwohl es mit separaten Komponenten möglich sein sollte, denke ich, dass die anzahl 74xx-ICs nicht trivial wäre, und man in der heutigen Welt schnell mit FPGAs arbeiten werden, um die Anzahl der Komponenten zu reduzieren.

  • Nämlich die 1541U2:

    Die ist um eine halbe bis ganz Größenordnung zu teuer für ein Dead Test Modul, denke ich. Und bei weitem nicht jeder hat eine. Aber es wäre natürlich eine Idee. Ich habe jedenfalls leider keine.

  • Ich hab keine Ahnung. Auf jeden Fall was mit genug I/Os.

    Es gibt günstige Cortex M3 (z.B. STM32F10x), 72MHz, viele I/Os (zumindest teilweise 5V tolerant), ... irgendwo habe ich mal gesehen, dass jemand damit eine Gameboy Cartridge o.ä. emuliert hat, also auch sowas geht. Kleines Testboard ~1,50€ ;-)

  • Es gibt günstige Cortex M3 (z.B. STM32F10x), 72MHz, viele I/Os (zumindest teilweise 5V tolerant), ... irgendwo habe ich mal gesehen, dass jemand damit eine Gameboy Cartridge o.ä. emuliert hat, also auch sowas geht. Kleines Testboard ~1,50€ ;-)

    Ja, mit dem Gedanken damit ein EPROM zu emulieren, habe ich auch schon mal gespielt. Der Preis ist unwiderstehlich. Leider reichen die 5V toleranten Pins knapp nicht aus, wenn ich mich recht erinnere.

  • Wiso Schweineteuer? Ein 3.5er Teensy ist ab 25 Euro zu bekommen...

    Arduinos gibts halt ab 3 Euro.


    Leider reichen die 5V toleranten Pins knapp nicht aus, wenn ich mich recht erinnere.

    Wie sieht es denn mit den I/Os vom Teensy aus? Die sind ja auch 5V tolerant. Zum Lauschen ausreichend, aber als EPROM braucht man für den Datenbus wohl einen Pegenwandler, oder?

  • Ist die notwendige Hardware nicht bereits vorhanden? Nämlich die 1541U2:

    nicht jeder 8\| (zumindest auch ich nicht),.. würde seine "geliebte" :love: 1541U2 in einen möglichen defekten C64 rein stecken (wollen).. :smoke:

  • Ja, mit dem Gedanken damit ein EPROM zu emulieren, habe ich auch schon mal gespielt. Der Preis ist unwiderstehlich. Leider reichen die 5V toleranten Pins knapp nicht aus, wenn ich mich recht erinnere.

    Ok, scheint ein STM32F4 gewesen zu sein:


    https://dhole.github.io/post/gameboy_cartridge_emu_1/


    "Luckily the STM32F4-Discovery has 5V tolerance for most of the pins."


    Wenn Du Dich damit mal befassen willst, können wir uns ja mal kurzschließen. von den STM32F10x hab ich hier schon welche herumliegen, weil ich überlegt hatte sie als Interface zw. C64 und RasPi zu nutzen (ist schon fast billiger als die Levelshifter ;-))

  • Ok, ich habe mir jetzt mal ein Teensy 3.2 bestellt und werde versuchen damit ein EPROM zu simulieren.
    Wenn das funktioniert, hole ich mir ein Teensy 3.5 und versuche damit vom CPU-Sockel aus den Bus anzusprechen.


    Das mache ich aber alles im PET. Mit dem kenne ich mich besser aus. Den C64 überlasse ich den Experten hier. ;)

  • Ist die notwendige Hardware nicht bereits vorhanden? Nämlich die 1541U2:


    Eigener Prozessor
    Kann den 6510 in den Ruhezustand versetzen und die C64-Hardware mit einem eigenen Prozessor steuern.
    Menüsystem, das auch bei defektem Speicher verwendet werden kann.

    Wie funktioniert das denn mit dem Ruhezustand des 6510?
    Ist das ein Feature des 6510 oder macht das der PLA oder wie geht das?


    EDIT: Ok, habs gefunden. Über den Eingang AEC wird der Adressbus auf Tri-State geschaltet. Und der lässt wohl über den den DMA-Eingang am Expansionport steuern. Das eröffnet natürlich einige Möglichkeiten.

  • Wird schon kräftig (ge-)brainstormed hier. Na dann wird's vielleicht ganz was neues.
    Leute, das wird nur ein ganz schöner Batzen Arbeit werden. Vor allem softwaretechnisch. Bei dem Thema muss ich dann auch passen.
    Wiederum hardwaremäßig traue ich mir das durchaus zu, das dann auch umzusetzen. Na mal sehen, wie es weitergeht.
    Zuerst muss die Prozessor-Frage geklärt werden. Diese sollte zwar leistungsfähig aber nicht zu teuer werden, wie oben schon angemerkt.
    Eine 20€-CPU halte ich nicht unbedingt für das richtige und auch eine 1541-Ultimate sollte dafür nicht missbraucht werden.
    Die hat einen ganz anderen Anwendungszweck und wäre dafür auch viel zu wertvoll. Gar nicht daran zu denken,
    wenn ein defektes Board die U2-Hardware zerbrutzelt. Muss nicht unbedingt sein.

  • EDIT: Ok, habs gefunden. Über den Eingang AEC wird der Adressbus auf Tri-State geschaltet. Und der lässt wohl über den den DMA-Eingang am Expansionport steuern. Das eröffnet natürlich einige Möglichkeiten.

    Genau so. :) Nur der VIC kommt einem in die Quere in "seiner Phase". Da muss man dann halt schnell genug sein. :D

  • Zuerst muss die Prozessor-Frage geklärt werden.

    Nein, zuerst muss (experimentell) geklärt werden, ob die angedachten Ideen überhaupt brauchbar umgesetzt werden können. Kostenoptimierungen durch Auswahl einer möglichst günstigen, für den Job geeigneten CPU können später stattfinden.

  • zuerst muss (experimentell) geklärt werden, ob die angedachten Ideen überhaupt brauchbar umgesetzt werden können

    Bin ich komplett bei Dir. Aber auch "experimentell" benötigt man dafür irgend eine CPU, die die Arbeit übernimmt. Wie willst Du die angedachten Funktionen denn sonst testen?

  • Wird schon kräftig (ge-)brainstormed hier. Na dann wird's vielleicht ganz was neues.

    Jau. :D Und was ich so raushöre, sind da beim einen oder anderen bereits Code- und Gedankenfetzen vorhanden. Gut, dass wir darüber sprechen. ^^

    Leute, das wird nur ein ganz schöner Batzen Arbeit werden. Vor allem softwaretechnisch. Bei dem Thema muss ich dann auch passen.

    Ich denke, man muss sich dem ganzen schrittweise nähern. Als erste Ausgabe wäre z. B. schon toll, einen Controller auf A8-A15, D0-D7 und den ganzen Steuerleitungen lauschen zu lassen und deren Stati regelmäßig einfach über die serielle Schnittstelle rauszuschicken, Ja, da geht ein ganzer Haufen Informationen (Adressen) zwischendurch verloren, das ist mir klar - wäre aber erstmal egal, man sieht, ob auf allen Adress- und Datenleitungen "Betrieb" ist oder ob einzelne klemmen usw. Also erstmal nur passiv.


    Wenn das funktioniert, könnte man sich überlegen, einen "Takeover"-Mode einzubauen, der per DMA auch aktiv reingrätscht.


    Ich würde mal sagen, es sollte ein 5 V-toleranter Controller sein. Level-Shifter sind zusätzliche(r) Aufwand/Fehlerquelle.


    @GMP Wie sieht das eigentlich aus, darfst du hier mein erstes Post editieren? Weil dann könnte man es mal um ein paar Sachen ergänzen, dass das nicht zu unübersichtlich wird hier im Thread.


    [EDIT]

    nicht jeder (zumindest auch ich nicht),.. würde seine "geliebte" 1541U2 in einen möglichen defekten C64 rein stecken (wollen)..

    Ein sehr gutes Argument, würde ich unterstützen. Schon alleine deshalb sollte es auch was Kostengünstiges sein, was hierfür verwendet wird. Wenn ein verranzter C64 vom Grabbeltisch um 10 Euro eine U2 um hunderte Euro killt, ist das Preis-Leistungsverhältnis ... sagen wir "ungünstig". :D


    [/EDIT]

  • Interessante Diskussion hier...


    Nur wird die Lösung von Axorp und mir so was von weit von dem entfernt sein, was hier alles gewünscht wird, dass ich mich Mal ausklinken werde.


    Seine Vorgaben sind:
    So einfach und so kostengünstig wie möglich...


    Natürlich gibt es in der Industrie in-circuit-tests... Aber bei den vielen Varianten alleine der C64 Platinen (das Ganze soll ja auch noch für den CBM etc. funktionieren) halte ich das für ein unmögliches Unterfangen so etwas privat herzustellen... Vor allem wenn man das dann auch noch günstig halten will...


    Wie auch immer:
    Sobald axorp mit seinen Test-Platinen fertig ist (er wartet noch immer auf Bauteile) werden wir euch im Forum Teil haben lassen.

    Inventar:
    PET2001 (defekt), CBM3032 (defekt), Proxa 720 (leider auch defekt), mehrere C64 (manche davon defekt - kommt Zeit, kommt Hardware für ne einfachere Reparatur ^^), Modding C64 (mit neuem Gehaeuse, MixSID, Keyman64), Ultimate64 - definitiv einer meiner Favorits!, SX-64 (seit der CC2019 defekt - Netzteil), Amiga1200 (in der Lernphase :böse )
    PI1541, SD2IEC, Easyflash3, Tapecart, Tapduino...

  • Ich denke, man muss sich dem ganzen schrittweise nähern. Als erste Ausgabe wäre z. B. schon toll, einen Controller auf A8-A15, D0-D7 und den ganzen Steuerleitungen lauschen zu lassen und deren Stati regelmäßig einfach über die serielle Schnittstelle rauszuschicken, Ja, da geht ein ganzer Haufen Informationen (Adressen) zwischendurch verloren, das ist mir klar - wäre aber erstmal egal, man sieht, ob auf allen Adress- und Datenleitungen "Betrieb" ist oder ob einzelne klemmen usw. Also erstmal nur passiv.

    Absolut. Gut, protokollieren ginge evtl. auch schon mit einem Arduino. Wäre vielleicht sogar das richtige Werkzeug dafür.
    Die Auswertung wäre dann noch mal eine andere Hausnummer.


    Wie sieht das eigentlich aus, darfst du hier mein erstes Post editieren? Weil dann könnte man es mal um ein paar Sachen ergänzen, dass das nicht zu unübersichtlich wird hier im Thread.

    Ja, das darf ich. Gib mir Bescheid, was Du geändert haben möchtest. Mache ich gerne.

  • Ich denke, man muss sich dem ganzen schrittweise nähern. Als erste Ausgabe wäre z. B. schon toll, einen Controller auf A8-A15, D0-D7 und den ganzen Steuerleitungen lauschen zu lassen und deren Stati regelmäßig einfach über die serielle Schnittstelle rauszuschicken, Ja, da geht ein ganzer Haufen Informationen (Adressen) zwischendurch verloren, das ist mir klar - wäre aber erstmal egal, man sieht, ob auf allen Adress- und Datenleitungen "Betrieb" ist oder ob einzelne klemmen usw. Also erstmal nur passiv.


    Wenn das funktioniert, könnte man sich überlegen, einen "Takeover"-Mode einzubauen, der per DMA auch aktiv reingrätscht.


    Ich würde mal sagen, es sollte ein 5 V-toleranter Controller sein. Level-Shifter sind zusätzliche(r) Aufwand/Fehlerquelle.

    Das Lauschen ist kein Problem, die uC kann man auch einfach über Phi2 triggern (das mache ich ja mit meinem RasPi, aber das wäre ein etwas "arg großer" uC).


    Das Weiterschicken der Daten ist noch eher das schwierigste: USB stört m.W. oft das Mitlauschen (wg. IRQs) und serielle Schnittstelle ist zu langsam für alles :-) Würde also vermutlich erstmal auf Lauschen, dann anschließend Übertragen rauslaufen.



    Absolut. Gut, protokollieren ginge evtl. auch schon mit einem Arduino. Wäre vielleicht sogar das richtige Werkzeug dafür.

    Das sollte gehen, aber die kleinen Cortex Mirgendwas spielen mindestens eine Liga darüber, bei gleichen Kosten.

  • Bin ich komplett bei Dir. Aber auch "experimentell" benötigt man dafür irgend eine CPU, die die Arbeit übernimmt. Wie willst Du die angedachten Funktionen denn sonst testen?

    Mit einer CPU, die man sich für die Entwicklung ausgesucht hat - die Kosten sind da IMHO erstmal egal, da muss der Entwickler sich entscheiden was er investiert und das muss nicht viel mit den Kosten der CPU im fertigen Gerät zu tun haben. Aber zu fordern, dass man erstmal die CPU-Wahl ausdiskutieren muss, weil das vom Entwickler gewählte Modul aus Anwendersicht zu teuer wäre scheint mir eher kontraproduktiv zu sein.


    Schon vor Start der Entwicklung die Endgrösse abzuschätzen ist nicht einfach und manchmal ist es während der Entwicklung extrem hilfreich, mehr Resourcen nutzen zu können als die Zielplattform bieten würde um zB zusätzliche Ausgaben fürs Debugging einzufügen oder einen Trace-Buffer anzulegen, in dem ein Echtzeit-Ablauf für spätere Analyse mitprotokolliert wird.