Ich habe mal etwas weiter an meiner 74299 Variante gearbeitet:
Ich die Logik muss ich morgen nochmal prüfen, dafür ist es heute zu spät.
Die Signale von JSPI1 sollen von dem noch nicht angeschlossenen Arduino Nanoboard kommen.
Die Steuerung von /GAME und /EXROM soll ebenfalls der Arduino übernehmen.
RDRF/INT wird ebenfalls vom Arduino generiert und ein ~{NMI} ausgelöst.
Please login to see this attachment.
Wer Fehler sieht oder Anregungen hat immer raus damit.
Jim Brain hat einen PS2 Adapter gebaut der PS/2 unter anderem auf Parallel wandelt: Please login to see this link.
Hier gibt es eine schöne Übersicht über existierende Diagnose Hardware für den C64 Please login to see this link.
Einige sind zumindest teilweise open source wobei sich das meist auf Hardware beschränkt, andere wurden reversed, und von einigen existieren nur ROM images.
Jedes Modell scheint seine Stärken und viel wichtiger auch Schwächen zu haben.
Ein all-in-one kann kaum eine Lösung sein.
Was fehlt scheint ein Open Source ROM zu sein.
DesTestMax und Full scheinen einer der besten Kandidaten für den RAM Test Teil zu sein leider Closed Source 
In besondere die SwiftLink Variante finde ich interessant.
Check64 hat eine schöne Hardware siehe weiter oben. Darüberhinaus hat es GiJoe's Ultimax-RAM-Checker Please login to see this link. hier habe ich nur BIN Files gesehen. Der Code basiert wohl auf Mac Bacon's Code Please login to see this link..
Die Frage ist, was funktioniert besser der DesTestMAX Code oder der von GIJoe/Mac Bacon?
Die Bildschirmausgabe beim DesTestMAX scheint mir sehr gelungen.
Was ich mich Frage, ob beide ROMs die Spriterregister als Data RAM Ersatz nutzen und was hier noch für schöne Tricks zum Einsatz kommen.
Darüberhinaus enthält es die von kinzi aktualisierten Dead Test und Diag 582200++ ROMs.
Weiß jemand zu fällig ob den Test ROMs die mit den Dongles u.a. den Tastaturanschluss testen, in beide Richtungen scannen?
Da die Ausgabe auch bei einem kleinen Fehler BAD, derzeit gibt es konkret einen Fall bei dem nur einige Tasten nicht funktionieren, vermutlich eine Leiterbahnunterbrechung um PB4 .
Hier wäre es schön wenn man wüsste lassen sich schon die Register nach dem beschreiben nicht mehr auslesen? ->CIA defekt.
Sind nur bestimmte Spalten und Zeilen betroffen? Wenn ja welche?
Oder verhält sich alles wie ohne aufgesteckten Testadapter?
kinzi hast du die ROMs direkt gepatcht oder disassembliert und neu assembliert?
Weiß jemand ob die C64 Diagnostic (Box) (CBM32517-02) und der Nachbau Roßmöller Doctor64 irgendwas wirklich gut können oder anders / besser als die bereit erwähnten ROMs?
Das gleiche für die von Jani gelisteten anderen Module.
Für das Modul ließe sich das noch deutlich vereinfachen, das Control-Register 74LS374 sollte nicht benötigt werden, die Schreibzugriffe gehen dann ins leere und gelesen wird Mist.
In der Regel wird dieses Register aber nur beschrieben, das Command-Register 74LS273 und 74LS244 wir auch nicht zwangsweise benötigt.
Dadurch können dann auch U1D, U6B und U6C weg. Das Statusregister U15 74LS244 muss bleiben. Damit können dann wohl auch noch ein paar weitere TTLs weg.
Eine Light Version die nur das Statusregister und die damit verbundene Interruptlogik enthält und den FT245R als Datenregister sollte wenn man ein GAL verwendet deutlich übersichtlicher sein.
Nein Original DesTest Switch max ohne Modifikation.
Nach PLA Tausch läuft der Test fehlerlos durch, kein RAM Fehler
Das sagt weniger über PLA aus als du denkst, es sagt eher aus das das original DesTestMAX-Switch design sehr fehlerhaft ist.
So, ich bin einen großen Schritt weiter: A0 war auf der Platine direkt am Lötauge unterbrochen.
Jetzt scheint noch PB4 und NMI zu zicken, vermutlich auch irgendwo unterbrochen.
Schade, dass ich den DeadTest von Kinzi nicht nutzen kann, GAME während des Betriebs zu ändern lässt sich mit KFF nicht simulieren und ich hatte kein kleines EPROM mehr vorrätig, nur EEPROMS ..512 oder ..Cxx.
Ich verstehe nicht was Ihr hier für Probleme habt.
Mit KFF ist zum derzeitigen Stand nicht geeignet als Diagnose Cartridge zumindest nicht für "tote" Geräte die wiederbelebt werden sollen.
Will ich testen ob einer der CIAs eine kleine Make hat und sonst läuft alles dann sollte es gehen.
Warum ist das so? Es liegt an der Firmware:
Please login to see this link.
Es handelt sich um Software definiertes Cartridge, und es arbeitet mit einem PHI2 offset um das richtige Timing zu treffen.
Man kann dieses zwar beeinflussen aber das ist eigentlich nur an einem funktionstüchtigen System sinnvoll machbar.
Leider ist die Firmware nicht soweit, das das Modul das C64 Timing ausmisst die notwendigen Werte selbst ermittelt oder ein Diagnose Log auf SD-Karte schreibt.
Im fall einer positiven Ausmessung sollte es den C64 neustarten und erneut testen.
Dieses würde zwar den Start um 1-2 Sekunden verlängern aber es würde zum einen die manuelle Calibration überflüssig machen und so einen Diagnosemodulbetrieb ermöglichen.
Einige C64 driften mit der Zeit enorm insbesondere defekt Geräte.
Daher müsste das Timing z.B. 1x in der Minute überprüft werden und ggf. nachjustiert werden.
Da die LED des KFF ansteuerbar ist sollte es möglich sein dem Benutzer durch blinke darauf aufmerksam zu machen das etwas nicht stimmt.
Ich denke diese Dinge liegen alle im Bereich des möglichen aber Kim oder jemand anderes müsste sie umsetzen.
Vom DesTest gibt es auch eine Max und Full version die man getrennt flashen kann.
Die Umschaltung ist eigentlich nur ein nicht unbedingt notwendiges Komfortmerkmal.
Wenn du kinzi's Test ohne Umschaltung laufen lässt testet der nur 4K RAM aber auf den Rest hat das keine Auswirkung.
Wenn Du das den Rest des RAMs ebenfalls testen willst machst du das halt in einem zweiten Durchlauf mit einer geeigneten Version.
Das Du einen Testharness besitzt besitzt du garantiert auch mehr als einen C64.
Außerdem hast du ein Oszilloskop.
Da der C64 CIAs für die Tastatur einsetzt und eine ideale 8x8 Matrix hat gibt es leider auch eine Besonderheit der Tastaturscan kann in beide Richtungen erfolgen.
So lange das Kernal ROM genutzt wird kann man von einer bestimmten Richtung ausgehen. für alles andere aber eben nicht.
Ich habe mir die Checks die den Harness benutzen nicht im Detail angesehen, insbesondere ob diese aus beiden Richtungen scannen.
Wenn Du mit dem Oszilloskop nicht per Du bist solltest du auf jeden fall einen funktionierendes C64 Board als Referenz nehmen um die korrekte Einstellung (Timebase, Amplitude und Trigger)
etwas sichtbar macht was du dann mit dem Fraglichen Board vergleichen kannst.
Die Kernal ROM Routine liegt bei $EA87, sie schreibt die zu scannende Zeile (PB) nach $DC00 und fragt über $DC01 ab in welchen Spalten (PA) Tasten gedrückt wurden.
Also sollte man auf Port PB ein durchlaufendes Bitmuster sehen bzw. eine periodische Aktivierung.
Bei einem Test ROM kann das durchaus umgekehrt sein, oder im Idealfall sogar wechseln.
Im ausgeschalteten Zustand solltest du mit einem Modernem Multimeter die Verbindungen zum Tastaturanschluß und den Joystick Ports einfach durchmessen können.
Wird es noch einen für Einsteiger tauglichen Fix geben?
Wie axorp bereits beschrieben hat, diskutieren wir (woanders) gerade, ob man die Sammelbestellung mit 3 Schottkydioden und einem Widerstand "retten" kann. Viele Tests sehen gut aus, bei einigen gibt es aber noch Probleme, die gerade analysiert werden. Daher ist die "Lösung" auch noch nicht beworben worden.
Das gehört aber nicht in diesen Thread, hier wird eine ganz andere Lösung/Idee von Natas diskutiert - die auch noch nicht spruchreif ist.
wdoelker Soweit ich keine Fehler eingebaut habe (eher unwahrscheinlich) wäre der Schaltplan für ein SwiftLink-USB mit ROM-Sockel für DesTestMAX-SK fertig.
Der Schaltplan der Version des DesTestMAX Switch mit 7-Segmente Display war auch vollständig, ob er fehlerfrei ist kann ich nicht sagen. Leider gibt es keine Software die das Display unterstützt.
Der Schaltplan der Version mit dem 74646 ist 3/4 fertig, das ich aber keine ATMega 2560 einsetzen möchte sondern einen Arduino Nano V3.0 ATmega328P mit CH340C und OLED gehen mir die GPIOs aus.
Somit werde ich diese Version einmotten und den 74646 gegen einen 74299 ersetzen und schauen ob die GPIOs dann genügen.
Display MoreIch habe als Sideprojekt den Schaltplan des Please login to see this link. für den C64 portiert.
Wenn ich nichts übersehen habe sollte das C64 USB Serial Cartridge kompatibel zum SwiftLink232, Please login to see this link.und Turbo232 Cartridge basierend auf dem 6551 sein.
Das Timing ist NICHT (!) überprüft kann also fehlerhaft sein, auch können noch weitere Fehler im Schaltplan sein.
Erst wenn mindestens eine Person die sich auskennt mal drüber geschaut hat kann es an ein Layout gehen.U4 74F138 und DSW1 8fach Dip-Switch brauchen nur bestückt werden wenn über Jumper J2 gewählte IO-Bereich weiter unterteilt werden soll.
Ist beides nicht bestückt muss Lötbrücke J6 geschlossen werden. Eine Bestückung ist wohl nur in Ausnahme Fällen sinnvoll (Einsatz im Port Expander).
Falls beides bestückt ist, lässt sich die Serielle Schnittstelle dadurch deaktivieren das alle Schalter aus sind. Für die Standardadresse nur den obersten Switch ein schalten (Dx00) das x wird über J2 gesteuert.
Jumper 5, 6 und 7 sind doppelt ausgeführt einmal als Lötbrücke und einmal normal. Standard ist J5 geschlossen, J6 offen und J7 geschlossen.
Jumper 8 man sollte den USB-Host wählen (2-3), wenn das Modul vom Host (PC) sofort nach dem Anschließen erkannt werden soll oder wenn das USB-Gerät auch nach einem Neustart des C64 auf dem Host konfiguriert bleiben soll. Man sollte den C64 (1-2) wählen, wenn das Gerät nur erkannt werden soll, wenn der C64 eingeschaltet ist.Ich habe noch ein EPROM Sockel für ein EPROM der Größe 2764 (8KB) - 27512 (64KB) eingebaut.
Über den Doppel-Jumper J3 kann gewählt werden ob das Modul wie ein 8 KB oder 16 KB Cartridge arbeiten soll und ob dieses im Ultimax Modus arbeiten soll.
Über den Doppel-Jumper J4 kann man wenn man ein 27256 (32KB) EPROM verwendet aus zwei 16 KB Bänken wählen und beim einem 27512 (64KB) EPROM aus vier 16KB Bänken.Es gibt zwei Möglichkeiten das EPROM abzuschalten: alle Jumper von J3 abziehen oder J7 öffnen.
Mit J5 kann man verhindert das bei einer gewählten 16K Konfiguration ein ROM bei $8000-9FFF eingeblendet wird dazu er geöffnet werden.In das ROM könnte man Terminal Software und evtl. auch BBS Software Brennen oder auch das Please login to see this link. ROM brennen.
Für dieses ROM wäre folgende Jumperung korrekt:
J1 auf 1-2 bei einem Interrupt wird ein NMI ausgelöst.
J2 auf 1-2 IO1 $DE00 als Basisadresse für die serielle Schnittstelle.
J3 1-2 gebrückt 3-4 offen.
J4 bei 2764 und 27128 egal, bei 27256 1-2 gebrückt um die untere Hälfte (Bank 1/2) des EPROMs auszuwählen, bei 27512 1-2 und 3-4 gebrückt um das untere 1/4 (Bank 1/4) zu wählen.
J5 sollte theoretisch offen sein spielt aber meiner Einschätzung nach keine Rolle, bei einem 2764 würde das ROM bei geschlossenem Jumper einmal bei $E000-FFFF und einmal bei $8000-9FFF auftauchen,
Bei einem 27128 EPROM wäre es wichtig das das 8K Image in der oberen Hälfte liegt, was auch immer sich in der unteren Hälfte befindet würde bei $8000-9FFF eingeblendet dürfte aber völlig ignoriert werden.
J6 je nach Bestückung siehe oben.
J7 geschlossen, über J3 lässt sich bei Bedarf das ROM immer noch deaktivieren.
J8 auf 1-2 Stromversorgung des USB Wandlers erfolgt vom C64.Please login to see this attachment.
Mir ist gerade etwas aufgefallen ich denke für den C64 kann man den Adressdecoder nicht so ohne weiteres umgehen, da dann die Verknüpfung zu PHI2 aufgehoben wird.
Entschluss J6 und J7 kommt weg, J5(a/b) bleibt erstmal. Damit ist das Thema für mich erstmal abgeschlossen.
Warum sollte man den 6551 mit Logikchips nachbauen wollen - der wird heute noch produziert und ist neu verfügbar, z.B. bei Mouser oder Digikey (als 65C51).
Weil, eine SwiftLink232 bei poly.play 99€ kostet, warum auch immer, darüber hinaus nicht mehr verfügbar.
Hier wird als Ersatz ein FTDI FT245R genutzt, bei einem Notebook ist halt USB viel praktischer.
Dieses Modul hat einen Sockel für eine spezielle Version des DesTestMAX-SL ROMs welches Diagnoseinformationen per ANSI Terminal ausgibt.
Für das Modul liesse sich das noch deutlich vereinfachen, das Control-Register 74LS374 sollte nicht benötigt werden, die Schreibzugriffe gehen dann ins leere und gelesen wird Mist.
In der Regel wird dieses Register aber nur beschrieben, das Command-Register 74LS273 und 74LS244 wir auch nicht zwangsweise benötigt.
Dadurch können dann auch U1D, U6B und U6C weg. Das Statusregister U15 74LS244 muss bleiben. Damit können dann wohl auch noch ein paar weitere TTLs weg.
Aber dann ist das Modul vermutlich mit anderer Software nicht mehr kompatibel.
Gegenfrage warum haben hier viele ein Wi-Fi-Modem bzw. WiC-64?
Ich habe als Sideprojekt den Schaltplan des Please login to see this link. für den C64 portiert.
Wenn ich nichts übersehen habe sollte das C64 USB Serial Cartridge kompatibel zum SwiftLink232, Please login to see this link.und Turbo232 Cartridge basierend auf dem 6551 sein.
Das Timing ist NICHT (!) überprüft kann also fehlerhaft sein, auch können noch weitere Fehler im Schaltplan sein.
Erst wenn mindestens eine Person die sich auskennt mal drüber geschaut hat kann es an ein Layout gehen.
U4 74F138 und DSW1 8fach Dip-Switch brauchen nur bestückt werden wenn über Jumper J2 gewählte IO-Bereich weiter unterteilt werden soll.
Ist beides nicht bestückt muss Lötbrücke J6 geschlossen werden. Eine Bestückung ist wohl nur in Ausnahme Fällen sinnvoll (Einsatz im Port Expander).
Falls beides bestückt ist, lässt sich die Serielle Schnittstelle dadurch deaktivieren das alle Schalter aus sind. Für die Standardadresse nur den obersten Switch ein schalten (Dx00) das x wird über J2 gesteuert.
Jumper 5, 6 und 7 sind doppelt ausgeführt einmal als Lötbrücke und einmal normal. Standard ist J5 geschlossen, J6 offen und J7 geschlossen.
Jumper 8 man sollte den USB-Host wählen (2-3), wenn das Modul vom Host (PC) sofort nach dem Anschließen erkannt werden soll oder wenn das USB-Gerät auch nach einem Neustart des C64 auf dem Host konfiguriert bleiben soll. Man sollte den C64 (1-2) wählen, wenn das Gerät nur erkannt werden soll, wenn der C64 eingeschaltet ist.
Ich habe noch ein EPROM Sockel für ein EPROM der Größe 2764 (8KB) - 27512 (64KB) eingebaut.
Über den Doppel-Jumper J3 kann gewählt werden ob das Modul wie ein 8 KB oder 16 KB Cartridge arbeiten soll und ob dieses im Ultimax Modus arbeiten soll.
Über den Doppel-Jumper J4 kann man wenn man ein 27256 (32KB) EPROM verwendet aus zwei 16 KB Bänken wählen und beim einem 27512 (64KB) EPROM aus vier 16KB Bänken.
Es gibt zwei Möglichkeiten das EPROM abzuschalten: alle Jumper von J3 abziehen oder J7 öffnen.
Mit J5 kann man verhindert das bei einer gewählten 16K Konfiguration ein ROM bei $8000-9FFF eingeblendet wird dazu er geöffnet werden.
In das ROM könnte man Terminal Software und evtl. auch BBS Software Brennen oder auch das Please login to see this link. ROM brennen.
Für dieses ROM wäre folgende Jumperung korrekt:
J1 auf 1-2 bei einem Interrupt wird ein NMI ausgelöst.
J2 auf 1-2 IO1 $DE00 als Basisadresse für die serielle Schnittstelle.
J3 1-2 gebrückt 3-4 offen.
J4 bei 2764 und 27128 egal, bei 27256 1-2 gebrückt um die untere Hälfte (Bank 1/2) des EPROMs auszuwählen, bei 27512 1-2 und 3-4 gebrückt um das untere 1/4 (Bank 1/4) zu wählen.
J5 sollte theoretisch offen sein spielt aber meiner Einschätzung nach keine Rolle, bei einem 2764 würde das ROM bei geschlossenem Jumper einmal bei $E000-FFFF und einmal bei $8000-9FFF auftauchen,
Bei einem 27128 EPROM wäre es wichtig das das 8K Image in der oberen Hälfte liegt, was auch immer sich in der unteren Hälfte befindet würde bei $8000-9FFF eingeblendet dürfte aber völlig ignoriert werden.
J6 je nach Bestückung siehe oben.
J7 geschlossen, über J3 lässt sich bei Bedarf das ROM immer noch deaktivieren.
J8 auf 1-2 Stromversorgung des USB Wandlers erfolgt vom C64.
Please login to see this attachment.
Hucky Wie du vielleicht an meinen Emojis gesehen hast habe ich das auch so verstanden.
Trotzdem finde ich es als Option gar nicht so schlecht, falls es tatsächlich jemand aus welchem Grund auch immer (schlechte Augen evtl.) eine Sprachausgabe möchte kann man sie nachrüsten.
Sicher hast du meine Antwort mit dem Docking Connector ebenfalls als Witz erkannt. Aber die Vorstellung das man zwei Leute benötigt um das ganze wieder auseinander zubekommen ist schon lustig...
Wie gesagt es ist einfach nur ein Thread um mal völlig offen drüber nachzudenken was kann man mehr oder weniger sinnvolles noch anstellen kann.
Den 74646 und den 74299 habe ich schon vor langer Zeit meine Liste mit interessanten Chips geschrieben mit denen ich irgendwann mal etwas machen möchte.
Leider braucht der 74646 deutlich mehr externe Logik um am C64 zu funktionieren als ich dachte, siehe letzten Schaltplan, außerdem braucht er auf der Atmel/Microchip Seite deutlich mehr GPIOs als mit lieb ist.
Daher werde ich die 74646 Version als Fehlversuch verbuchen und auf den 74299 umschwenken.
Den Verlust des 7-Segment Displays bedaure ich. Wäre ein guter Blindtest: 1-2-3... Und auf der Rückseite steht steht 1 = CPU, 2= RAM etc.
Wie gesagt auf dem Spannungs- und Taktdisplay wird die Zahl 1, 2.. oder sogar im Klartext CPU, RAM angezeigt.
Solange aber niemand das ROM entsprechend patched wird die Anzeige ungenutzt bleiben.
Ich habe jetzt doch noch eine alternative Lösung für den Swift Link Ersatz gefunden:
Please login to see this link.
Hier wird ein FTDI-245R genutzt.
Damit könnte man einen schönen Ersatz für das SwiftLink232/GLink232 Please login to see this link. bauen,
wenn man ebenfalls wie beim Coco einen ROM Sockel vorsieht kann man in dem Wahlweise eine BBS-, Terminal Software oder das DesTest Max SL ablegen.
Hucky Ich höre daraus du möchtest die Samples für die Meldungen einsprechen?
Hardware technisch brachen wir nur eine weitere Chip Select Leitung, da der SPI Bus eh schon für das Display da ist.
Please login to see this link.
Wenn wir so weiter machen ist die Platine so breit wie der C64 selbst hat aber auch einen Vorteil, man muss nur zwei mal stecken ein mal die Rückseite und ein mal die rechte Seite mit 2x Joystick und Power.
Und fertig ist der voll automatisierte sprechende C64 Tester, Mist ich wollte doch irgendwo noch KI unterbringen...
Achtung! da ist nur ein Zwischenstand es ist noch nicht viel weiter, aber hoffentlich korrekter.
Das ganze sit ein regelrechtes TTL Grab.
Please login to see this attachment.
Ich spinne nur rum... Please login to see this attachment.
Mfg Jood
Jood Ich würde dein GAL gerne verwenden aber es passt nicht so ganz zur neuen Schaltung, da ich eine separate Codierung für read und write benötige und einiges mehr siehe Schaltplan.
Auch wenn das ROM behauptet es nutzt keinen NMI dann stimmt das nicht.
Das Registers CY74FTC646T U2 ($DE00) ist für das DesTest Max Swift Link ROM das Daten Register des 6551 und für die DesTest Max Switch ist es die Modul Konfiguration.
Dieses Register kann geschrieben und gelesen werden und zwar sowohl von der 6510 als auch vom ATMega.
Hier ein zwischen Stand fehlt noch UDF Teil sprich ATMega32F4 Display usw..
Please login to see this attachment.
Das wird doch mehr tricky als ich angenommen habe den 6551 zu emulieren.
Den Verlust des 7-Segment Displays bedaure ich. Wäre ein guter Blindtest: 1-2-3... Und auf der Rückseite steht steht 1 = CPU, 2= RAM etc.
Die Version ist ja nicht weg.
Momentan schaue ich wie man das mit einem CY74FCT646TSOC lösen kann.
Die Idee ist einfach das OLED mit für die Anzeige zu nutzen.
Der ATMega würde zusätzlich zur Frequenz- und Spannungsmessung /GAME und /EXROM bedienen (Ultimax/8K/16K Umschaltung) und ein mögliches Banking übernehmen.
Mit einem größeren Schaltplanblatt müsste ich den 7-Segment Plan soweit auflockern können das sowohl ein 72AHCT273 mit Display als auch ein CY74FCT646TSOC drauf passt.
Für die Anzahl der benötigten GPIOs am ATMega kann das durchaus notwendig sein.
Eins steht fest in ein Stummel Cartridge passt das nicht.
Der 74FCT646T ist quasi ein 8-Bit Dual-ported RAM oft auch als Postbox bezeichnet mit dem zwei Systeme mit unterschiedlichem Takt sehr einfach asynchron Datentauschen können.
Meine Idee ist es von einem 6551 idealerweise nur das Datenregister zu emulieren Please login to see this link.
Der Handshake finden in Hardware statt ein Chip-Select mit Schreibzugriff auf das Register löst einen IRQ beim ATMega aus und dieser holt kurze Zeit später den im Register gespeicherten Wert auf der ATMega Seite ab.
Umgekehrt kann der ATMega etwas in das Register schreiben und danach einen IRQ beim C64 auslösen welcher dann das Byte abholt.
Wenn das Status register nicht gepollt wird sondern mit IRQ gearbeitet wird was ich hoffe kann dieses ignoriert werden.
Schreibzugriffe auf das Command- und Controlregister sollten man einfach ignorieren können, das ES Register ist für langsame Geräte wie den C64 nicht relevant.
Damit sollte mit etwas Glück das Please login to see this link. ROM auch ohne teure Swift Link Hardware laufen.
Please login to see this picture.
Wohl eher doch nicht 
NMI (not used)
Ich finde die Configuration etwas seltsam, es wird die gleiche Adresse IO1 wie für das Switch genutzt.
Warum einen NMI wenn auch ein IRQ geht?
Update: Anleitung gelesen und immer noch nicht schlauer.
Ist möglicherweise einfacher, solange der PC oder C128 auf dem das Terminal läuft nichts sendet passiert auch nichts.
Wenn doch ein Tastendruck gesendet wird hat das bei der NMI Einstellung den selben Effekt als ob jemand auf Restore drückt.
Die Baudrate sollte mehr oder weniger nur die Einstellung für den PC vorgeben wäre in unserem Fall vom ATMega bestimmt.
Selbst wenn 115200,8,N,1 oder halt wegen der Anzeige 38400,8,N,1 gewählt ist heißt das nur das einzelne Zeichen mit dieser Baudrate übertragen werden nicht das ein dauerhafter Stream mit dieser Geschwindigkeit genutzt wird.
Ich habe noch etwas drüber nach gedacht ich würde das 7 Segmente Display die 3 Inverter und den Treiber samt Widerstände entfernen.
Dafür wird noch ein weiteres Single-AND-(?)-Gate eingebaut welches Y0 und Y1 vom 74138 zu sync verknüpft. Y0 und Y1 gehen an je einen Interrupt Eingang des ATMegas, die Ausgänge des 74273 gehen ausschließlich an den ATMega. Der ATmega übernimmt über zwei Shottkey Dioden die Ansteuerung con GAME und EXROM.
Je nach Interrupt weiß der ATMega in welche Adresse der Inhalt vom 74273 geschrieben wurde. Ist es IO1 dient es der Modus Auswahl und Banking, ist es IO1 + 1 ist es 1 Byte welches Seriell übertragen werden soll.
Ein 74ACT646 müsste noch viel besser geeignet sein als ein 74AHCT273.
R/w müsste dann an den DIR Pin und nicht an den 74138.
Das Signal welches den Interrupt auslöst muss zusätzlich an den /Gate Pin und and CAB.
CBA müsste vom ATMega ausgelöst werden, nach dem ein Byte im 646 hinterlegt wurde gleichzeitig müsste am C64 ein IRQ ausgelöst werde.
Heute/Morgen früh geht's weiter.
Für gut 60 Cent bekommt man ein digitales Poti MCP4017T-104E/LTY leider nicht ganz optimal nur ein Bereich von 100kOhm in128 Schritten gesteuert per i2c.
Dazu brächte man noch einen Multiplexer und einen weiteren um den Widerstandsbereich mit zusätzlichen Widerständen zu erweitern.
Eigentlich sollten pro Joystick-Port ein 74HCT4052D für ca. 30 Cent genügen:
Please login to see this attachment.
X-COM würde an Pin 9 des Joystick-Ports kommen und Y-COM Pin 5
0X und 0Y gehen direkt an 5V Minimalwert (SID-Messwert ~0-10)
1X und 1Y gehen über je einen 160kOhm Widerstand an 5V Drittel-Ausschlag (SID-Messwert ~80-90)
2X und 2Y gehen über je einen 330kOhm Widerstand an 5V Zwei-Drittel-Ausschlag (SID-Messwert ~160-180)
3X und 3Y gehen über je einen 470kOhm Widerstand an 5V Maximalwert (SID-Messwert ~245-255)
VEE und VSS (nicht angezeichnet) geht an GND
VDD (nicht eingezeichnet) geht an 5V
INH (teilweise auch als /E bezeichnet) geht an GND
Die Eingänge A und B (teilweise als S0 und S1 bezeichnet) gehen and einen weiteren 74AHCT273 oder werden vom der MCU angesteuert.
Da es zwei Joystick-Ports gibt brauchen wir das ganze zwei mal.
Die SID-Messwerte sind Pi mal Daumen angenommene Schätzwerte der Gutbereich müsste experimentell ermittelt werden.
Please login to see this link.
Please login to see this picture.
Um bastelfreundlich zu sein wäre sowas vielleicht eine Lösung.
Beim Ali kostet das 10er Pack 44,59€ Ist der gleiche Chip wie auf dem Leonardo UNO R3.
18 verfügbare IOs
Please login to see this picture.
Von diesem kosten derzeit 5 Stück knapp 20€ inkl. Display
Dank CH340C USB Serial Wandler auch geeignet.
Ein wenig groß für meinen Geschmack.
20 verfügbare IOs davon 2 für das Display reserviert.
Die aktuelle Version Please login to see this attachment..
Ist doch exakt so präzise wie deine Variante. 
Aber hast recht so eine Referenz gibt's für unter 40 Cent. wäre also kein Beinbruch.
Ich poste dir mal den aktuellen Schaltplan für das UFD 3,
vielleicht hilft dir das bei deinen Planungen, z.B. vermisse ich in deinen Ausführungen die externe Referenzspannung.Mfg Jood
Die Referenzspannung ist an Pin 22.
Danke, und damit bin ich bei Revision 4 vom meinem Schaltplan habe das OR gegen ein korrektes AND getauscht. 
negative Logik.
Please login to see this attachment.
Die Idee mit den Paddels gefällt mir.
Ich habe fehlerhafte Zuordnungstabelle aus Posting Please login to see this link. entfernt und versuche es hier erneut:
| Pin Nr. | ATmega32U2 Bezeichnung | Pin Nr. | ATtiny84 Bezeichnung | Funktion | Anmerkungen und Status |
|---|---|---|---|---|---|
| 1 | PF0 (ADC0) | Frei (ADC) | Frei verfügbarer ADC-Eingang. | ||
| 2 | PD4 (T1/OC1B) | 10 | PA3 | Frequenz IN (T1/OC1B) | Eingang für Frequenzmessung |
| 3 | PF1 (ADC1) | 12 | PA1 | C64 EXROM-Signal | Eingang für das C64 EXROM-Signal. |
| 4 | PF4 (ADC4) | Frei (ADC) | Zusätzlicher Analogeingang verfügbar. | ||
| 5 | PF5 (ADC5) | Frei (ADC) | Zusätzlicher Analogeingang verfügbar. | ||
| 6 | PF6 (ADC6) | Frei (ADC) | Zusätzlicher Analogeingang verfügbar. | ||
| 7 | PB4 (PCINT4) | Frei (GPIO/Timer) | Vielseitiger I/O-Pin. | ||
| 8 | PB5 (PCINT5) | Frei (GPIO/Timer) | Vielseitiger I/O-Pin. | ||
| 9 | PB6 (PCINT6/OC1B) | Frei (GPIO/Timer) | Vielseitiger I/O-Pin. | ||
| 10 | PB7 (PCINT7/OC1C) | STROBE (IRQ) | Neu: Interrupt-Eingang für Bus-Routine. | ||
| 11 | PD5 (XCK1/OC1A) | 6 | PA7 | Frequenz IN (ICP1) | Eingang für Intervallmodus |
| 12 | XTAL2 | 3 | PB0 | Quarz 16 MHz | Anschluss für den externen 16-MHz-Quarz. |
| 13 | XTAL1 | 2 | PB1 | Quarz 16 MHz | Anschluss für den externen 16-MHz-Quarz. |
| 14 | PC0 (PCINT8/SCL) | Bus Bit 6 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 15 | PC1 (PCINT9/SDA) | Bus Bit 7 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 16 | AVCC | Analoge VCC | Spannungsversorgung für den ADC, mit VCC verbinden. | ||
| 17 | GND | 7 | GND | Masseanschluss. | |
| 18 | VCC | 14 | VCC | Standard-Spannungsversorgung. | |
| 19 | PD1 (SCL) | 8 | PA5 | I2C SCL (Display) | Haupt-I2C SCL Pin für das OLED-Display. |
| 20 | PD2 (SDA) | 7 | PA6 | I2C SDA (Display) | Haupt-I2C SDA Pin für das OLED-Display. |
| 21 | PD3 (TXD1) | 9 | PA4 | C64 GAME-Signal | Geplanter Input, benötigt Pull-up (z.B. 10k). |
| 22 | AREF | 13 | AREF | Analoge Referenz IN | Hier wird die Zenerdiode angeschlossen. |
| 23 | PC2 (PCINT10) | Bus Bit 0 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 24 | PC3 (PCINT11) | Bus Bit 1 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 25 | PC4 (PCINT12/TDI) | Bus Bit 2 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 26 | PC5 (PCINT13/TDO) | Bus Bit 3 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 27 | PC6 (PCINT14/TMS) | Bus Bit 4 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 28 | PD7 (T0/ICP1/HWB) | 5 | PB2 | C64 Reset & HWB | GPIO im Betrieb, HWB-Funktion beim Start (Taster SW1). |
| 29 | RST | 4 | PB3 | MCU Reset | Master-Reset-Eingang, benötigt 4,7 kΩ Pull-up. |
| 30 | PC7 (PCINT15/TCK) | Bus Bit 5 | Neu: Teil des 8-Bit Daten-Eingangs. | ||
| 31 | D- | USB D- | Dedizierter USB-Pin, benötigt 22 Ω Serienwiderstand. | ||
| 32 | D+ | USB D+ | Dedizierter USB-Pin, benötigt 22 Ω Serienwiderstand und 1,5 kΩ Pull-up. |
Mein Gedanke war es an der IOx Adresse +1 am ATMega32U2 einen IRQ auszulösen, so das über den 8-Bit Daten-Eingang der Datenbus ausgelesen wird.
Dieser kann dann auf der virtuellen seriellen Schnittstelle (über USB) and einen PC gesendet werden.
axorp alles mir bekannte ist behoben ob etwas weiteres gibt weiß ich nicht. Im erwähnten WhatsApp Chat sind genauso wenig Informationen wie im Post Please login to see this link., nein Du musst dir nichts ansehen, aber du darfst gerne.
Jood Warum sollte mir das missfallen? Tut es ganz und gar nicht.
Ich habe dieses Thema aus zwei Gründen gestartet einmal:
- Um meine Gedanken zu dem Thema festzuhalten aber gleichzeitig damit abzuschließen
- Andererseits zu überlegen wie kann man es verbessern.
Mir ging es nie darum das diese Version irgend jemand umsetzt.
Ich betreibe das Retro/Vintage-Computing-Hobby eher theoretisch, also ohne alte Geräte dafür eher mit Emulatoren und Foren Diskussionen.
Ich interessiere mich aber sehr für die Hardware Basteleien und wie diese funktionieren.
Aber vielleicht bringt diese Zusammenstellung noch ein paar neue Ideen.
Ich finde an der Check64 Idee gut, das man keine Kabel um den halben C64 legen muss, der Tape Port ist neben an und die Joystick-Ports sind viel näher am Expansion als am User-Port.
Da jetzt das User-Port Dongle sehr einfach ist und kein Kabel dranhängt finde ich Kinzis Idee dort die Spannungen zu messen sehr gut,
es ist im C64 einer der Eingangsbuchse mit am weitesten entfernte Punkt wo 5V und 9V AC anliegen sollte also auf dem Weg etwas nicht stimmen kann man es direkt erkennen.
Dazu passt das dein UFD ebenfalls sie Spannung anzeigt am Expansion-Port welcher sehr nahe beim Eingang ist. Gibt es hier bei den 5V eine deutliche Differenz stimmt auf dem Weg etwas nicht.
Ich habe eine Frage zum UDF warum ist PA3 und PA7 vom ATtiny84 mit PHI2 verbunden?
Wenn ich das im Schaltplan richtig sehe kann der ATtiny84 feststellen ob der C64 im Reset hängen bleibt und gleichzeitig die Taste als Eingabetaste benutzen,
also ein langer Druck auf Reset kann eine Sonderfunktion aktivieren.
Schade das der ATtiny84 nur so wenige Pins hat da gäbe es noch ein paar andere Signale die die man auswerten und anzeigen könnte.
z.B. könnte man auch DOT_Clk messen (die 12MHz sind dafür vermutlich zu langsam ohne Teile),
den Status von /IRQ, /NMI, BA und /DMA feststellen und anzeigen, man könnte bei Bedarf einen IO-Extender per SPI anschließen.
Zu einem Harness würde ich auf jeden Fall so etwas wie dem Please login to see this link. von bwack hinzufügen.
Das Addon erscheint mir etwas Overkill zu sein, da würde ich wohl eher eins dieser billigen Volt-Amperemeter für die 5V einbauen und eine simple LED die anzeigt, das 9V da sind.
Sven Petersen hat das Please login to see this link. verbessert man kann ihn stecken lassen um die Joystick Ports zu testen, aber er benötigt ein extra Kabel zum Tape Port.
Bzw. Im Fall vom Check64 alternativ zum Modul.
Mit einem Please login to see this link. Video Sync Separator, 2x 100nF und 1x 168kOhm und einem Stecker für den Audio/Video Port könnte man auch noch einen Test-Stecker für den AV-Port herstellen.
In Verbindung mit deinem Frequenzzähler könnte feststellen ob ein Verticaler Sync da ist und ob er 50 oder 60Hz hat, das C-Sync Signal sollte zumindest ungefähr die 15,6kHz haben.
Ob das wirklich nützlich ist? Gute Frage. Wenn die Signale nicht da sind würde ein angeschlossener TV "Kein Signal" oder ähnlich anzeigen.
Es gibt ja noch das DesTest SL (Swift Link Edition) bei dem die Ergebnisse über einen 6551 ACIA ausgegeben werden. Das empfinde als eine schöne aber nicht gerade preisgünstige Möglichkeit 99€ bei poly.play.
Jetzt könnte man statt des ATTiny84 einen ATmega32U2 als TQFP-32 7x7mm nehmen der über die gut 10 zusätzlichen IOs verfügt und eine USB Schnittstelle hat.
Der ISP-Anschluss kann dann weg, da er über USB programmiert werden kann.
Statt einen 12MHz Quarzes wäre dann ein 16MHz Quarz und statt der 12pF 22pF Kondensatoren zumindest bei dem Typ den ich mir angesehen habe.
Ein USB-Anschluss mit 2x 22Ohm in den Datenleitungen und ein 1,5kOhm als Pull-up von D+ nach Vcc so wie ein 100nF Kondensator an VBUS kommt dazu.
Der Programmieranschluss wird nicht mehr benötigt.
