Der Empfänger hat ein schön langes Kabel, man kann ihn also gut vom Störsender entfernen (falls das überhaupt stimmen sollte).
Na ja, wenn es NICHT am U64 betrieben werden soll, dann kann man den auch einfach ausschalten 
Und wenn ja: was hilft ein Stück Kabel, das Störsender und empfindliche Antenne doch wieder verbindet? Gerade die niedrigeren Frequenzen, auf denen DCF77 funkt(ioniert), werden hauptsächlich leitungsgebunden übertragen!
Dann dürfe aber die LED nicht ruhig im Sekundentakt blinken. Tut sie aber. Die Ursache für das Nichtfunktionieren dürfte nicht daran liegen, dass das U64 ein Störsender wäre.
Dann dürfe aber die LED nicht ruhig im Sekundentakt blinken. Tut sie aber. Die Ursache für das Nichtfunktionieren dürfte nicht daran liegen, dass das U64 ein Störsender wäre.
Das Sekundensignal kommt an 59 der 60s an, aber dessen Länge jeweils entscheidet über die übermittelte Information. D.h. kann die Empfangs-Elektronik möglicherweise auf das STARKE Sekundensignal an sich syncen, aber der U64 offenbar NICHT jedesmal die genaue Länge vermessen, da vermutlich Störungen überlagert sind...
Die Elektronik im Empfänger wertet üblicherweise das Signal gar nicht aus, das macht der C64 oder Uhrenchip oder was auch immer als nächste Stufe kommt. In dem von kinzi und mir gezeigten Modul von Conrad sieht man das auch sehr gut, es sind dort 2 Platinen drin, eine für den Empfänger (die offen liegende) und eine verdeckt hinter dem Display für die Uhr samt Decoder.
Um rauszufinden, ob das Blinken überhaupt vom Empfang abhängig ist:
Antenne mal in geschlossene Weißblechkiste und im Keller dann testen, oder auch Antenne probeweise ablöten (beide Anschlüsse!), wenns dann immer noch blinkt, ist es gar nur ein "Heartbeat" der Empfangselektronik.
Um den Fehler dann einzukreisen:
Oszi anschliessen und wechselweise am C64 und U64 das Signal vermessen. Oszi am Besten aber auch weit weg stellen, macht selbst ja auch einige Störungen (wiederum ganz unterschiedliche, je nachdem, ob alt, analog und mit Röhre oder neu, digital und mit TFT...).
Auf gute Masseverbindung achten beim Messen, sollte sehr nah am Messpunkt liegen.
Kabel vom Userport zu der Empfangselektronik sollte so kurz wie möglich sein.
U64 wenn möglich mal alternativ auch an einem anderen Netzteil betreiben (sofern man genau weiß, welche Spannung wohin muss...), falls verfügbar ein Lineares oder das vom C64, wenn ausreichend, dann herrschen von daher mal gleiche Voraussetzungen...
Ein Oszi-Tastkopf kann auch wunderbar als EMV-Sonde "missbraucht" werden: sucht man magnetische Kopplungen (M-Feld), dann Tastspitze mit der Erdungs-Krokoklemme kurzschliessen und die sich ergebende Kabelschleife als "Sucher" verwenden. Empfindlichkeit und Ablenkfrequenz entsprechend variieren. Bei E-Feldern entsprechend mit offenem Eingang arbeiten, Erdung an zentralem Punkt belassen und weit weg von der Tastspitze führen (parallel zum Tastkopfkabel etwas zurück...)
Hat das Oszi dann auch noch nen brauchbaren FFT-Modus, kann man sehen, welche Frequenzen an welchen Stellen dominieren. Mal in der Nähe von Trafos, Spulen, Oszillatoren und auch Multilayer-Kondensatoren "schnüffeln", um etwas Erfahrung mit dem Verhalten der E/M Sonden und den Ergebnissen zu bekommen.
Dann dürfe aber die LED nicht ruhig im Sekundentakt blinken. Tut sie aber. Die Ursache für das Nichtfunktionieren dürfte nicht daran liegen, dass das U64 ein Störsender wäre.
Mach' mal ein Video
Der Empfänger ist jetzt erst mal mit dem Userport-Stecker verlötet, daher finden in nächster Zeit keine weiteren Experimente mit dem U64 statt. Am echten C64 funktioniert der Empfänger ja wie gewünscht, deshalb widme ich mich erst mal meinem eigentlichen Plan und klöppel mir einen DCF-Analyzer in Basic zusammen. Und erst wenn der zufriedenstellend funktioniert und ich sämtliche Goldrandlösungen umgesetzt habe, dann kümmere ich mich vielleicht wieder um den U64-Userport.
Mir hat das keine Ruhe gelassen, also habe ich es doch mal schnell aufgebaut. Beim Anschluss des Conrad-Empfängers habe ich gleich gesehen, dass die LED zwar (sauber) blinkt, aber nicht komplett ausgeht. Sie ist dunkel und blitzt im Sekundentakt heller auf. Mein Testprogramm von oben funktioniert an einem echten C64 einwandfrei, liefert aber am U64 nur die 4.
Dann habe ich etwas weiter probiert: Der Anschluss M gehört ja zum Port A Bit 2. Testweise habe ich ausprobiert, was mit dem Port B ist: Dazu muss man in das Register 56579 den Wert 0 schreiben (damit sind alle Bits auf Input gesetzt), und den Wert von 56577 ständig lesen. Die Bits kann man an den Stellen CDEFHJKL einlesen, und das funktioniert auch richtig (Drahtbrücke jeweils gegen GND geschaltet; offner Anschluss = HIGH-Pegel). Das Brücken vom Anschluss M zeigt keine Änderung.
Port B klappt also, aber Bit 2 von Port A klappt nicht. Der Rest von A ist teilweise für die Datenleitung zur Floppy. Die habe ich nicht getestet.
Panther oder andere hier: Schaut doch mal bitte, ob die rote LED vom Conrad-Modul auch wirklich ganz ausgeht oder noch schwach halb leuchtet. Das Problem werde ich gleich mal an Gideon senden, vielleicht kann er etwas dazu sagen.
Ach ja, wenn man statt des Anschlusses M einen anderen zwischen C und L verwendet, kann man das Signal klar empfangen. Wenn man die Software entsprechend patcht, müsste sie notfalls mit einem anderen Pin funktionieren.
Noch ein Versuch: Ich habe die DCF-Software mal ganz simpel mit einem HEX-Editor auf Port B gepatcht.
Läuft! 
Man muss natürlich nicht den Pin M, sondern E benutzen (ich habe also das gleiche Bit benutzt).
Wurde das tatsächlich über ein normales Portbit gemacht? Ich hätte da eher auf die Trigger-/"Gating"leitungen (CAx/CBx) getippt, denn dann könnte man gleich die Länge auslesen als Anzahl der Timerpulse, während denen das Gate offen war, also genau wie eine Periodendauermessung an nem Frequenzzähler...
Und mea culpa: Nein, die Pinbelegung des Userports kenne ich nicht auswendig
So würde man es jedenfalls auch heute noch an jedem µC machen, der eine solche Funktion anbietet, denn dann läuft das im Hintergrund und belastet die CPU nicht...
Aber wenn Port A scheinbar beim U64 Probleme macht, dann dürften ja viele andere Erweiterungen wie Eprommer etc. auch nicht laufen?
Eigentlich dürfte nicht mal eines der HW-Testmodule/programme korrekt durchlaufen, die Readback-Dongles für die div. Ports abfragen...
Oder ist (vielleicht im Rahmen eines alternativen Kernals) ein logischer Kanal zur Floppy dauern offen und blockiert die Schnittstelle?
Es sieht so aus, als ob keine Timerpulse gezählt werden, sonst würde mein Patch ja nicht funktionieren. Was die Testmodule angeht, würde der Fehler nur auffallen, wenn PA2 auch getestet werden würde. Das ist offenbar nicht der Fall.
Die Pinbelegung des Userports habe ich auch nicht im Kopf, dafür gibt es ja Dokus.
Übrigens bekam ich gerade eine Antwort von Gideon:
"Hmm.. this happens to be the PA2 bit? I remember that there was an issue with that in the FPGA indeed. Right now, the PA2 bit can only be used as output, not as input.
I will need to see if it is possible to fix in the FPGA. There are some dependencies with the external I/O expander.
I think the reason for this, is the IEC timing when the CIA is accessed through DMA. I think this is less relevant now that there is an internal turbo mode. No need for accurate timing through DMA."
Es kann also gar nicht funktionieren. Bei Neuigkeiten werde ich berichten.
Right now, the PA2 bit can only be used as output, not as input.
Danke fürs Nachfragen. 
Gerne. Ich frage mich nur, warum das so wie es ist gelöst wurde. PA2 ist nämlich auch für die RS-232 Schnittstelle da, und zwar für den Output. Ich kann es mir eigentlich nur so vorstellen, dass man die Bits von Port B komplett für einen 8 Bit breiten Bus extra nicht benutzt hat (z.B. für eine Zeitgesteuerte Anwendung? Gab es dafür nicht auch Relaiskarten?). Die anderen Bits von Port A sind für den IEC Bus (3-7) und für die Memory Bank des VIC (Bit 0 und 1) zuständig, die kann man auch nicht verwenden.
Blieben noch die Signale CNT, SP, PC/ und FLAG/-Signale (der / steht für den Querstrich oben) übrig. Mit denen kenne ich mich aber ehrlicherweise nicht aus.
So würde man es jedenfalls auch heute noch an jedem µC machen, der eine solche Funktion anbietet, denn dann läuft das im Hintergrund und belastet die CPU nicht...
Das läuft ja auch im Hintergrund. Nur wird das über die Standard-IRQ-Routine erledigt. Dann muss man nicht umständlich den Timer in der CIA programmieren und man weiß ich ja auch nie, wer den sonst noch gerade benutzt. Das DCF-Signal ist so langsam, dass man das bequem in der IRQ-Routine auswerten kann.
Wenn das nicht über Interrupt gemacht würde, dann wäre der C64 ja während des DCF-Empfangs komplett blockiert.
Die Interrupt-Möglichkeiten des C64 sind sehr sehr eingeschränkt. Das kann man nicht mit einem modernen Mikrocontroller vergleichen.
nd man weiß ich ja auch nie, wer den sonst noch gerade benutzt.
Doch, gerade am C64 weiß man das recht genau! Theoretisch der Kernal oder die gerade laufende Anwendung.
Die Kernalroutine für die RTC wird aber doch durch die DCF77 Routine ersetzt und sobald man eine Anwendung jenseits eines Basic-Programms startet, wird in 99% der Fälle auch der IRQ-Vektor verbogen, damit der SID dudeln kann und/oder Farben in Abhängigkeit der Rasterzeile geändert werden können, Sprite-Kollisionen erkannt werden etc.
Gerade die CIA hat mit die meisten IRQ-Möglichkeiten im C64 und ist schon recht nah an dem dran, was kleinere µCs wie z.b. Pic16F auch MAXIMAL zu bieten haben.
Insofern bleibe ich dabei: das manuell zu machen, sprich über Tastatur-IRQ, zeugt nur von FEHLENDEM Systemwissen und/oder Programmiererfahrung!
Aber damit ist man heutzutage ja in bester Gesellschaft, sonst bräuchte man keine Gigabyte großen SSDs, nur um ein System innert 10s hochzufahren, mich erstaunt es nur eben, sowas hier zu finden.
Mit solcher Mentalität wäre die Demo-Szene nicht so weit gekommen mit der Hardware des C64!
Wäre mal interessant, über einfache Basic-Benchmarks nach zu prüfen, wie viel Rechenzeit die derart erweiterte IRQ-Routine "frisst" und ob vielleicht sogar das Ansprechverhalten der Tastatur dadurch noch weiter verschlechtert wird...
nd man weiß ich ja auch nie, wer den sonst noch gerade benutzt.
Doch, gerade am C64 weiß man das recht genau! Theoretisch der Kernal oder die gerade laufende Anwendung.
Die Kernalroutine für die RTC wird aber doch durch die DCF77 Routine ersetzt und sobald man eine Anwendung jenseits eines Basic-Programms startet, wird in 99% der Fälle auch der IRQ-Vektor verbogen, damit der SID dudeln kann und/oder Farben in Abhängigkeit der Rasterzeile geändert werden können, Sprite-Kollisionen erkannt werden etc.
Gerade die CIA hat mit die meisten IRQ-Möglichkeiten im C64 und ist schon recht nah an dem dran, was kleinere µCs wie z.b. Pic16F auch MAXIMAL zu bieten haben.
Den Pic16F kenne ich nicht, aber ein Atmega328 hat 15 Interruptverktoren für 15 unterschiedliche Interruptquellen die alle unabhängig voneinander mit unterschiedlichem Timing ablaufen können.
Der 6502/6510 hat exakt genau eine (wenn man den NMI mal außen vor lässt). Und diese eine IRQ-Routine muss sich im alles kümmern, was im Hintergrund läuft. Das war beim PET schon so, dass während die Datasette aktiv war, die Uhr falsch ging. Weil die Kassetenroutinen den Interrupt brauchten.
Aber das führt jetzt alles weg vom Thema. Die DCF-Implementierung ist so wie sie ist, schon sehr gut gelöst und ich hätte das genau so implementiert. Du kannst ja mal eine Alternative schreiben, wenn du der Meinung bist, dass man das besser machen kann. Am besten gleich mit konfigurierbarer Polarität und Port-Pin (ach ne, das geht ja bei deinem Konzept nicht).
Insofern bleibe ich dabei: das manuell zu machen, sprich über Tastatur-IRQ, zeugt nur von FEHLENDEM Systemwissen und/oder Programmiererfahrung!
Jetzt erklär doch mal, mit welchem Interrupt du das machen willst.
Ich hab jetzt nochmal nachgeschaut, weil mich das interessiert hat: Der PIC16F hat 82 Interruptquellen und 82 Interruptvektoren. Zweiundachtzig!!! 
Vermutlich hat da jeder einzelne Pin seinen eigene Interrupt, aber trotzdem!
