Fragen zu PHI2 Edge Recovery

Edge wird die Signalflanke sein, und Recovery in dem Fall
deren Wiederherstellung / Rettung / Wieder-Nutzbarmachung...

Zitat von c64user

Was mich wieder zur Ausgangfrage zurückführt: Was hat das für Auswirkungen, bzw. wie lässt sich begründen, warum es enabled oder disabled sein sollte, außer dass es halt mal so oder so besser funktioniert.

Wenn ich raten sollte, würde ich sagen, dass es da um die "Verbesserung" der Flanke geht. NMOS-Technik hat die Eigenschaft, schnell von HI nach LO zu wechseln, aber nur langsam von LO nach HI anzusteigen (keine steile Flanke). Diese "flache" Flanke wird eventuell "wieder hergestellt" / "verbessert" dadurch.

Hello,
Ich versuche englisch:

I can confirm, all CPLD/FPGA developers (Unicart64, EF3, Ultimate64, Chameleon etc.) know that problem very good on C64 .
Yes, transition 0-->1 is very very long. It means, the signal is very long in "undefined area" between LO and HI and FPGA interprets that as a random value, sometimes 0, sometimes 1.
It leads into effects called "jitter".
Just look at it ... two jitters, short falls to "0", this is only interpretation how my FPGA see that on Unicart64 board.
o2-clock-distortion.png

And this is totally not usable (nicht benutztbar) to use it like this ... And therefore there is a need to regenerate it or in other words to create internally the nice signal without jitters.
I hope it is more clear .
Peter

@Peto74 I think I also noticed that when interfacing the Raspberry Pi with the C64 at the expansion port (but was seemingly able to circumvent the issue). How do you regenerate the signal in practice?

@Frenetic I think only way is this:
1) to detect transition 1-->0, situation like "11110", or similar, simply more "1" in a row and "0". We know that this is no jitter, but regular 1->0 transition.
2) drawing internal signal with "0" in steps in time & count the steps (I use 50 MHz so I count 0..24).
3) If the counter=24 (or 25 ...), change drawing to "1" and continue with counting (25 .. max.~49/50/51)
4) when the index is let's say 40, start drawing as a copy of the real visible PHI2 to your internal regenerated signal (usually only "1")
5) goto step 1

Ok, so if I get this right then (in short) you're taking the falling edge and figuring out the time when the rising edge should occur. That's a good strategy for a hardware solution. I could try the same in software (trigger interrupt on falling edge and wait), but this would block a CPU core (might try this, but so far I didn't experience any problems -- but I also did not try emulating a kernal cartridge which has the most strict timing constraints)

Yes, this strategy is commonly used, probably only way how to do it, but you need fast and precise HW (CPLD,FPGA), not sure if interrupt & software can do it.
When Interrupt comes to processor , nothing happens, processor have to complete current instruction first (random delay!) and then int starts, all stuff copy onto stack and then jump to vector and usefull code ... very slow and delay flying in time. I don't believe, but you can try it. Good luck !

PS: not only Kernal, but also DMA transfer (e.g. REU) needs that clock.

Emulating a ROM/CBM80 cart, GeoRAM and SID at the expansion port works reliably... can't be that bad

(I measured the delay of the interrupt with an oscilloscope and it was quite predictable)

Ahh, you have GHz processor, ok, can be, I have never tried that ...

Yes, GHz definitely helps... when the instruction counter increases at nanosecond scale

What is also important ... how the Rasp see the signal. I don't know the input pins settings, but try (if it is possible ...) to enlarge logical "1" area in Volts to minimize random values.
Also, not so fast frequency helps ,

Example:
EF3 has only 25MHz, there is NOT used "anti jitter" strategy at all and it works, because EF3 see only max. 1 random value (--> edge is flying in time a little bit only)!
0 - flying, later transition 0->1
1 - flying, sooner transition 0->1

Unicart64 has 50 MHz, so I have problem, because I see sometimes 2 random values:
00 - flying, later transition 0->1
11 - flying, sooner transition 0->1
01 - perfect transition 0->1 in the middle
10 - Jitter !!! Problem !!! (it is like this 00000 10 11111 )

I guess for me it's half way in between. Reading GPIOs is in the order of dozens of MHz. But I need a level shifter which probably avoids some issues beforehand.