I have been working a bit more on my Fusion-6502 project, which straps a real 65C02 to an FPGA.
What is interesting is the amount of noise the 65C02 generates - it can be seen on the screen.

Since I am just using a simple R2R DAC, small variations in voltage can cause slight noise on the screen.
This noise is quite noticeable when the 65C02 is sharing SRAM access time with the FPGA GPU.
If I bolt on my AVR based 6502 emulator instead, the noise is completely gone.
My AVR based emulator does exactly the same accessing as the 65C02.
Seems the 65C02 is a noisy little beast!

No amount of decoupling helps either.
The only way to eliminate the noise is to stop the 65C02 clock until the screen has passed vertical blanking.
This proves that the noise is actually generated by the 65C02.

This project is working out so well that I may invest in a real triple analog DAC, and that should clear things up.
It was just surprising how noisy this CPU is. It was so bad that I actually suspected a nanosecond bus collision!
I will probably see this same problem when I get further along on my other project - Vulcan-74 as well.

Perhaps I will dig out my 1980's analog scope and see if I can capture this analog noise.

Brad

I was going to suggest decoupling, knowing you're such a big user/fan of it, then you stole my thunder at paragraph three

What about clocks? Particularly if the FPGA is older tech that only provides a DCM (can introduce considerable jitter) to generate clocks.
Depending on the design, the noise could be jitter. Are you generating the 6502 clock via the same method you used for the AVR clock?

I don't think using a real DAC will show any difference to the current R2R. The current DAC is doing it's job just fine, the glitch/noise is present before reaching the DAC, so the DAC is showing you the glitch in analog form, a real one will/should do the same.

The FPGA does generate the clock, and it is only a single 40MHz clock.
The 6502 sees this as divided by 6 for 6.66 Mhz.

When I replace the 65C02 with an AVR doing IO emulation, the noise is gone.

I just found a tray of ADV7123s in my stash, so I am going to try soldering one up.
The digital DAC will be more resistant to this, as it will gate the data.

Here are some photos showing the noise, which manifests as slight changes in brightness.
There are subtle, so I added contrast in Photoshop so they were more visible.

Note that the vertical bands are called "moire lines", and happen when trying to photograph a screen.
These lines are not actually present in real life.


From a distance, the noise isn't all that noticeable.

Here is a closer image of the noise enhanced a bit with contrast.
The noise corresponds to about the time the 6502 is accessing SRAM.


The slight changes happen when the 6502 talks to the SRAM.

When I remove the 65C02 and put my AVR emulator in, the noise is completely gone.
The AVR does an IO exact clone of the 6502, so timing is precisely the same.


An AVR emulating a 6502 does not produce any noise at all.

I am thinking that the real DAC will completely eliminate this issue and offer a much better image as well.
Normally, this would be "good enough", but I really like this project as a platform for making 6502 games and demos!
I just finished the sound, and it is just like the Amiga. 4 channels with precise frequency and volume control.
The unit also acts as a USB mass storage device to the PC, so I can code in my 6502 assembler and see code run in a few seconds.

Anyhow, I will play around and see what develops.
Seeing the AVR pretend to be a 6502 with a clean signal makes me think that the 6502 is just more power hungry.

Thanks,
Brad

Something I've seen for myself as well as heard mentioned on the forum is that the outputs on a modern WDC 65c02 produce rather fast edge rates when they transition, as compared to a Rockwell 65c02 for instance. Based on your comments, I think we're seeing that the WDC edge rates are faster than the AVR's as well.

Decoupling is one piece of the puzzle when it comes dealing with this. But there's a big hole that's not plugged, and that is ground/Vcc routing. In an ideal setting, every signal line will have physically close to it a path for return current to flow. The area enclosed by the signal conductor and the nearest available return conductor needs to be as close to zero as can be arranged. That's because loops of non-zero area are depressingly good at transmitting and receiving magnetic fields. This includes the "noise" (high frequency content) associated with fast edge rates.



Breadboards will never be perfect in this regard. Toward the left of the photo above we see the groups of orange, green and blue signal lines that feed the DAC's and ultimately the VGA connector. We know the return current is bound to find one or more paths by which to flow... but is any of these paths physically close to the signal lines? Not especially (as shown below) -- there's certainly room for improvement. There's a fairly generous loop area.


The same is apparent when we look toward the right of the photo and see where the 65c02 signals flow, compared to where the corresponding return currents flow. Again there's a fairly generous loop. [Oops, I guess that's the AVR, isn't it. But still the same point applies.]

I'm suggesting the 65c02 loop transmits noise and the DAC loop receives it. (The reverse is also true but it doesn't produce an on-screen symptom.)


Try grounding the probe at one ground point -- on the FPGA board, say -- and placing the tip on another ground point -- such as that for the VGA output. I'm betting the trace on the screen won't be as flat as you might wish.

This indirectly illustrates the presence of magnetic fields. The same 'scope observation would reveal much less noise if the project had the same size and layout but used a PCB with a ground plane (ie, proximate return path for any current flowing in any direction).

(Edits)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've had similar problems with some DIP W65C02s, way back (8 years or so). At the time I thought that it had to be my design, somehow, but it was found to be a production problem (the bonding wires were too thin). This was fixed, and when I got my replacements, those were okay.

Could be you have these as well. Mine were date code 0841. The fixed ones were date code 0918.

Interesting.

The numbers on mine are...

W65C02S6TPG-14
SA0703G034A
D1838A
Taiwan

Brad