"Dead Test++" - Ideensammlung / Brainstorming


  • kinzi
  • 1340 Aufrufe 76 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • "Dead Test++" - Ideensammlung / Brainstorming

    Hello,

    ich mach hier mal einen Thread auf zu diesem Thema, obwohl ich eigentlich noch keinen genauen Dunst habe, wohin das führen soll. :D Die Idee wäre, ein leistungsfähigeres "Dead Test" zu entwickeln (wer auch immer ^^ ), das auch halbtote und ganz tote C64 diagnostizieren können soll (nicht nur: "Er ist tot, Jim!"). Bitte gerne um Ergänzungen, ich würde vorschlagen erst mal alles einfach zu sammeln und nicht groß einzelne features im Detail zu diskutieren (ob/ob nicht).

    Was mir da an Schlagwörtern/Ideen mal dazu einfällt wäre:
    • Microcontrollergesteuert. :)
    • Ein LCD :woot: zur Ausgabe der Diagnoseinformationen unabhängig vom C64 bzw. dem angeschlossenen Sichtgerät.
    • Karte für den Expansionport, vorzugsweise Standard-Modulgröße.
    • Harness ("Dongles") von Diag8k (586220) weiter verwendbar.
    • Möglichkeit, von außen den Bus zu übernehmen, um von außen eine Diagnose stellen zu können.
    • Möglichst alle Leitungen des Expansionports anzapfen, um z. B. die Frequenzen von Phi2, DotClock, AEC usw. messen zu können.
    • Microcontroller sollte das ROM für ein Ultimax-Cartridge gleich mit emulieren, damit kein EPROM o. ä. notwendig ist.
    Bitte gerne weiterspinnen und ergänzen. :)

    Gruß
    kinzi
    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten."
    (Quelle unbekannt)

    "Lege dich nie mit einem Idioten an! Er zieht dich auf sein Niveau hinunter und schlägt dich dann mit seiner Erfahrung!"
    (Volksmund)
  • kinzi schrieb:

    Ein LCD zur Ausgabe der Diagnoseinformationen unabhängig vom C64 bzw. dem angeschlossenen Sichtgerät.
    Aber bitte nicht den Fehler von Dave Curran wiederholen und bei so einem Diagnose-System die USB-Schnittstelle vergessen:
    blog.tynemouthsoftware.co.uk/2…t-diagnostics-update.html

    An welchen Prozessor hast du denn gedacht? Ein ATmega macht das nicht mehr. Da muss schon was größeres/schnelleres ran.

    Und wie man beim C64 den Bus bei vorhandenem 6510 testen kann, ist mir noch nicht klar. Ich kenne den Bus vom C64 nicht so genau. Kann man die CPU vom Bus trennen?
  • detlef schrieb:

    An welchen Prozessor hast du denn gedacht? Ein ATmega macht das nicht mir. Da muss schon was größeres/schnelleres ran.
    Ich hab keine Ahnung. Auf jeden Fall was mit genug I/Os. :D

    Wow, das Teil kannte ich noch gar nicht! Das geht ja schon weit in die Richtung. Open Source ist das wohl nicht?
    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten."
    (Quelle unbekannt)

    "Lege dich nie mit einem Idioten an! Er zieht dich auf sein Niveau hinunter und schlägt dich dann mit seiner Erfahrung!"
    (Volksmund)
  • kinzi schrieb:

    Wow, das Teil kannte ich noch gar nicht! Das geht ja schon weit in die Richtung. Open Source ist das wohl nicht?
    Ne, der Dave rückt nix raus. ;(
    Kann man alles für 50 Pfund aufwärts kaufen.

    Ich hatte ja auch schon solche Experimente am PET gemacht und mit einem Arduino am CPU-Sockel den Bus kontrolliert.
    Ich konnte auch auf ROM und RAM zugreifen. Aber das Video-RAM braucht eine Synchronisation mit Phi2 sonst hat man nur Schnee auf dem Bildschirm und kann das Video-RAM nicht testen.
    Dafür war der Arduino aber viel zu langsam. Deswegen habe ich das erstmal nicht weiterverfolgt.

    Aber das ist alles vom CPU-Sockel aus (ohne CPU). Wie geht das vom Expansion-Port?

    Ein Bekannter hat es gerade geschaft, mit einem Arduino im PET ein ROM zu simulieren. Das klappt aber nur in einem 64-Byte-Adressbereich. Für ein volles 4K-ROM ist der Arduino mit 16 MHz auch wieder zu langsam. Er versucht jetzt einen auf 25 Mhz zu tunen. Das ist alles experimentell und eine ziemliche Bastelei.

    Die Superkernel-Leute verwenden einen ARM-Prozessor. Das ist nicht meine Welt. :whistling:

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von detlef ()

  • kinzi schrieb:

    Bitte gerne um Ergänzungen, ich würde vorschlagen erst mal alles einfach zu sammeln und nicht groß einzelne features im Detail zu diskutieren (ob/ob nicht).
    Um es anwenderfreundlich zu machen, vielleicht eine Art
    Silikonstulp für die gesamte Platine, in dem die ganzen
    Diagnoseleitungen enden, mit nur einem äußeren Diagnosestecker
    dran, sodass man ohne weiteren Aufwand und Gesuche sofort an
    jeden Chip- und Steckerkontakt kommt.
    Kurze Anschlüsse für die Ports könnten dann schon dranbammeln.
    Für jede Revision müßte man eben ein Extra-Design haben.
  • Am besten so wie die Ultimate ein eigenes menu einblenden welches quasi kein C64 ROM/RAM braucht.
    Das zeigt dann direkt basierend auf den Messungen den jeweils naechsten Schritt an.
    "CIA1 defekt, bitte testen sie das Bauteil Uxy auf einer anderen Platine,
    alternativ messen Sie die Spannung an PIN 5 zu GND an PIN 0".
    dazu ein kleines Schaltbild in Hires Bitmap. Das ginge alles. Am besten auf Deutsch/Englisch und evtl. Franzoesisch.
    Das Tutorial hangelt den Anwender dann Schritt fuer Schritt durch die Diagnose.
    Wenn man einen etwas maechtigeren Atmega nimmt, koennten einzelne Schritte auch als Video via NUVIE erlaeutert werden.
    Vielleicht sogar mit Ton? Wenn man von SDcard streamt (das koennen ja alle Arduinos & Co) koennten das sogar direkt Samples sein.
  • Frag ich mich auch gerade. Das ganze soll doch letztlich nur ein paar Leitungen abfragen und dann dazu halbwegs sinnige Ergebnisse auswerfen. Mit 16Mhz sollten sich doch auch die Frequenzen noch "brauchbar" prüfen lassen wenn man es nicht permanent macht.
    Der alleinige Zweck dieses Beitrags ist es meinen Counter zu inkrementieren. Jeglicher Sachbezug dient ausschließlich der Dekoration.
    --- "Meine kleinen Projekte"
    --- "3D-Modelle" --- "Platinen" ---
  • Hucky schrieb:

    Der Atmega8 macht schon 8Mhz.
    Der macht sogar 20, je nach Typ.

    Hucky schrieb:

    An I/Os sollte es wohl auch nicht scheitern wenn man einen Typen wählt der gross genug ist.
    Das wird schon schwieriger, 40 müssten es schon sein. In DIP wohl nicht zu bekommen.
    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten."
    (Quelle unbekannt)

    "Lege dich nie mit einem Idioten an! Er zieht dich auf sein Niveau hinunter und schlägt dich dann mit seiner Erfahrung!"
    (Volksmund)
  • Also, ich hatte da mal was angefangen und auf dem Marburger Stammtisch gezeigt....


    Als CPU Plattform hatte ich das Teensy 3.2 und 3.5 ins auge gefasst, im Prototypen V02 hatte ich den 3.5.
    Warum?
    Einfach zu bekommen, in der Arduino IDE zu programmieren und "Fucking Fast 32 Bit zugriff auf die IO, bei 120Mhz, reichlich ram.
    Für Lötanfänger im DIL format noch lötbar, mein SMD Fetisch teilt halt nicht jeder.

    Die Beiden Clock Signale hatte ich über einen TTL Käfer runtergeteilt auf ein 16384tel und in SW ausgewertet.
    Die Reset Leitung wurde beim einschalten (5V Flanke High) zeitlich gemessen und bewertet.
    Die Versorgung war optional über einen 5V DC DC Wandler um die 5V Spannung vom C64 Messen/bewerten zu können

    AEC, IRQ etc auf plausibilität prüfen, signale wurden noch nicht ausgewertet..

    Ghost Mode:
    Lauschen auf welchen adressen der BUS Schreibt, liest, umgesetzt und auf OLED Display mit 1-2 FPS dargestellt

    Achja OLED
    128x64 Display in 1,3" für die Anzeige der Diagnosegebnissse, Serielle Massenausgabe was passiert über USB Schnittstelle des Teensy verfügbar, via SPI angebunden.

    RAM Test Extern, wurde nicht umgesetzt, zeitmangel
    ROM Text Extern, wurde nicht umgesetzt, Zeitmangel
    Daten und BUSleitungstest auf Immer LOW, HIGH, oder verbunden mit 2-3 wurde noch nicht umgesetzt, wegen zeitmangel
    Geführte Diagnose, RAM BIT 0-4 Defekt, Check U12 74LS257 and RAM 41464 U22

    Leider ist die Entwicklung aus Privaten gründen erstmal auf eis gelegt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von AREA51HD ()

  • Hucky schrieb:

    Ein Atmel soll zu langsam sein ?!
    Der Atmega8 macht schon 8Mhz.
    An I/Os sollte es wohl auch nicht scheitern wenn man einen Typen wählt der gross genug ist.
    Um ein EPROM zu simulieren, muss man innerhalb von 500ns (das ist der Wert vom PET, beim C64 weiss ich es nicht) nach Anlegen der Adresse die Daten bereitstellen.
    Man muss also im Atmel bei einem Select die Adresse einlesen und zusammenbauen, Daten aus dem ROM lesen und bereitstellen.

    Wie oben schon geschrieben, schafft ein Bekannter auf einem ATmega328 auf einem Arduino Nano mit einigen Kniffen gerade mal 650ns. Da ist das Problem hauptsächlich, dass zuviele I/O-Zugriffe notwendig sind, weil die Ports so zerstückelt sind. Und der Atmel tut dann auch nichts anderes mehr.

    Mit einem größeren Atmel mit mehr Ports geht's sicherlich etwas schneller. Aber nicht um Größenordnungen.
  • Ich habe noch Prototyp 1 gefunden, der Lief auf einem Vergleichtstyp vom Arduino MEGA @16MHz.

    Die Erfahrung zeigte, zum Bus Lauschen Reichen die 16Mhz, beim Schreiben schießt man ihn timing mäsig ab.

    PORT= Always LOW, High kann bei Timing problemen, C64 Chips zerstören!
    TRIS = Eingang = High Level Ausgang = LOW Level um vom C64 Bus kompatibel zu sein.


    Der Protoyp 2 mit dem M4F Core war schnell genug um auch wärend der Laufzeit mal ein paar Byte in das RAM zu schreiben, ohne das der C64 probleme bekahm, oder einen Externen RAM Test fahren zu können, ohne mit Refresh/VIC in timing probleme zu geraten.

    Leider ist die Hardware verloren gegangen, ich habe auf der Arbeit noch irgendwo die Eagle Daten und reste vom Programmcode im Alpha experientier status...

    Edit:
    Wiso Schweineteuer? Ein 3.5er Teensy ist ab 25 Euro zu bekommen...
    Bilder
    • 20181127_211519_resized.jpg

      299,33 kB, 747×1.328, 8 mal angesehen
    • 20181127_211528_resized.jpg

      275,25 kB, 747×1.328, 7 mal angesehen
  • detlef schrieb:

    Wenn der nicht so schweineteuer wäre.
    Also teuer ist relativ, wenn man sonst nicht viel braucht.

    @AREA51HD Wow, das liest sich klasse! :thumbup: Hattest du denn vor, das irgendwie zu veröffentlichen oder gar als Open Source freizugeben?
    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten."
    (Quelle unbekannt)

    "Lege dich nie mit einem Idioten an! Er zieht dich auf sein Niveau hinunter und schlägt dich dann mit seiner Erfahrung!"
    (Volksmund)
  • @kinzi
    Ich hatte vor das ganze freizugeben, so das es nachgebaut werden kann, oder jemand eine Sammelbestellung macht.

    Bis auf eine chaos zusammenstellung von halbgaren Routinen, die einzelne Signale auswerten, oder auf dem OLED darstellen wo der Prozesser grade
    zumreitet ist aber nichts fertig oder verwendbar.

    Leider habe ich seit März wegen familiären gründen keine freie zeit mehr, und das Projekt ist erstmal auf jahre eingestellt.
    Aber wenn du natürlich ein Hardware Diagnose Modul bauen willst, was in die gleiche Kerbe schlägt, helfe ich dir gerne mit dem bisher gesammelten wissen.

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


    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...


    Ich bin mir nicht mehr Sicher, aber ich meine mich zu erinnern, das der Teensy 3.5. 16/32 Bit breite IO Ports hat, das gibt natürlich einen Extremen Geschwindigkeits schub, 16 Bit Adressbus und 8 Bit daten in einem Schreibzyclus :ilikeit:
    Es ist inwischen auch schon eine weile her wo ich mit inline Assembler versuche gefahren hab auf der CPU...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von AREA51HD ()

  • AREA51HD schrieb:

    Bis auf eine chaos zusammenstellung von halbgaren Routinen, die einzelne Signale auswerten, oder auf dem OLED darstellen wo der Prozesser grade
    zumreitet ist aber nichts fertig oder verwendbar.
    Hast du das in Assember gemacht?

    Klaus bastelt da schon einige Zeit dran rum - 16 Mhz Nano als EPROM. Wie gesagt, aktuell >600ns bei 12Bit-Adressenraum (4K ROM).
    Die Daten sind so im Atmel-Flash abgelegt, dass sie ohne Bit-Manipulationen direkt rausgegeben werden könnten - also intern völlig zerstückelt.

    Vielleicht können wir da beim nächsten Stammtisch nochmal drüber sprechen.