"Dead Test++" - Ideensammlung / Brainstorming

Zitat von kinzi

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:
http://blog.tynemouthsoftware.…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?

Zitat von kinzi

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.

Klasse Idee . Da kann ich nur leider nicht viel beitragen

Blöde Frage, wofür wäre die USB Schnittstelle?

Wäre es möglich, es mit einem externen Netzteil zu betreiben, wenn der Cevi z.B. ganz tot ist, oder Teil Tod ist.

Wo z.B. angezeigt wird, was fehlen würde, wie z.B. IRQ , Reset oder ähnliches?

Zitat von kinzi

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.

Zitat von Spider1982

Blöde Frage, wofür wäre die USB Schnittstelle?

Um vom PC / Laptop aus das Diagnose-Modul zu steuern, die Ergebnisse zu protokollieren, Softwareupdates hochzuladen...

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.

Danke für die Info.

Nur ein Stecker wird wohl nicht gehen. Beim jetzigen Modul wird ja jeder externe Anschluss überprüft.

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

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.

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.

Zitat von Hucky

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.

Zitat von AREA51HD

Als CPU Plattform hatte ich das Teensy 3.2 und 3.5 ins auge gefasst, im Prototypen V02 hatte ich den 3.5.

Ja, der Teensy schafft das sicherlich. Wenn der nicht so schweineteuer wäre.

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

@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
Es ist inwischen auch schon eine weile her wo ich mit inline Assembler versuche gefahren hab auf der CPU...

Zitat von AREA51HD

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.