Hi. I've been working on a Commodore 64 6567/6569 VIC-II replica project for a number of months now. I've written my own FPGA core in verilog and have a working prototype running on a MojoV3 FPGA development board with a custom 'hat' that I designed. If you want to know all the gory details about how I got to this point, here are the links to the videos I've been making:

Part 1: https://www.youtube.com/watch?v=idUfXag8pQo
Part 2: https://www.youtube.com/watch?v=VJFIvmkbCA4
Part 3: https://www.youtube.com/watch?v=HzgjMjqpOC8

I know a number of other cores have been written to reproduce the VIC-II but I don't think there are any projects that can actually plug into a real C64. (Copperdragon and Beamracer still require a real VICII). My core will be open source when it's done and the hardware design will be open as well. I'm aware that this is going to be many times more expensive that just buying a genuine chip. This project isn't for money, it's for interest and the challenge. It also makes for some other interesting projects possible (like adding a new graphics mode, more sprites, custom palette, math co-processor, etc.). Of course, all just for interest's sake for hobbyests.

A similar project was started by Rob Finch a few years ago but his project was never finished. (He is also a member of this forum). He posted an issue he was having re: noise on this forum

https://forum.digilentinc.com/topic/19410-cmod-a7-massive-gnd-noise/

The project has been quite successful so far. I have a working prototype that is functioning well enough to play games. I can leave it on overnight and it's still running in the morning. It is fairly accurate at reproducing the VICII as I've been validating behavior using VICE and a custom IPC bridge to my verilated simulator executable. I've also tested it against 280 VICE VICII test programs and they are all now matching what VICE produces pixel for pixel.

Unfortunately, I am also running into a noise issue and I think it's the same issue Rob described in his post. So I'm reaching out to the experts in this forum for some advice on how to proceed from here.

In a nutshell, this picture illustrates my issue:



This is the PHI clock signal measured from the input pin of the 6510. When I measure the clock on the corresponding FPGA pin (on the FPGA side of the transceiver), there is no noise. The signal is quite clean.

I am using five 74LVC4245 bus tranceivers between the C64 VICII socket and the FPGA. One is for dedicated read signals, one for dedicated write signals and 3 for bi-directional data and address buses. I have .1uF capacitors at every Vcc pin on each of the transceivers.

The C64 seems to deal with the noise for the most part as I can play games and run most demos with no problems. I do get the occasional CPU JAM when I run the more complex demos though. I'm hoping if I can address this last issue, that problem will be solved (hoping).

The noise in the image happens when I switch the address tranceiver's direction from input to output. On the LOW phase of the PHI clock cycles, the VIC owns the address bus and sets the address to read char and pixel data from ROM or RAM. I've run some experiments and the noise disappears if I keep the address bus transceivers to read direction only. The switch happens on AEC edges which is slightly delayed wrt to PHI.
Also, if I unplug the device from the C64 socket and measure the clock output pin, even with the direction switches in place, there is little noise.

Anyway, there is probably a lot more info you would need to diagnose so I'll leave it at that for now. I'm basically at the end of my abilities for this project and was hoping an EE could help me with trying to fix this. If anyone has any ideas I can try, please let me know. Thanks!

FWIW, these videos really helped me about noise and PCB design.

https://www.altium.com/live-conference/ ... d-stack-up

https://www.youtube.com/watch?v=XumNc480qYo&t=1135s

I found this helpful, as I'm not a C64 expert:
https://dustlayer.com/c64-architecture/ ... lationship

As I understand the situation, then, it's your FPGA which outputs the clock, and the noise happens when the two octal transceivers for the address bus start driving. The noise is seen at the receiver - the CPU, the 6510, but isn't at the original transmitter, the FPGA. It's slightly after the falling edge of the signal, which is when lots of things tend to happen in 6502 land.

I think there are two kinds of things to look for, maybe three:
- disturbance to the ground when 16 drivers start driving, just because they drive
- disturbance to the ground because these 16 drivers are momentarily driving against some other drivers which have not quite switched off
- disturbance to one signal because many other signals are switching, fast

It might be possible, as a fix or as an experiment, to put the 6510 into a daughterboard which conditions the incoming clock: the noise isn't so bad, and a suitable buffer or maybe even small resistor might damp it down enough to fix things.

Although you do have 0.1uF bypass caps at every chip, it might also be worth looking at how they are connected to ground. It might be that better (shorter, fatter, more direct) ground connections will still help. It's common to have a larger electrolytic on a daughterboard, as well as bypass caps on each chip.

I don't know offhand what the LVC transceivers are like, electrically, but it might be that they are too fast: they switch too quickly with very fast edges, which challenge a 1MHz design like the C64.

It might be that low-valued series resistors will help with that.

If the problem is switching too early, perhaps you can find a way to turn those transceivers on just a little later (or even to stagger the timing of the two chips.)

More experienced commentators will be along shortly, I'm sure!

I like BigEd’s suggestion of a low value series resistor to clean up the noise.

However, it looks like the noise is not crossing the threshold for 0-1 or 1-0 and you say the circuit is working in a C64 but crashes with more complex demos. Does it crash consistently at specific points in the demos, or is it random? If it’s specific that makes me think it is something other than the noise. Is the dram refresh happening as expected? I note the refresh counter for the VIC-II is a decrementing counter. Are all 256 rows refreshed? I am not sure if software would depend on whether its an up or down counter and the exact address output. Being able to look at code / schematics might help.

The circuit may need to be hooked up to a logic analyzer to capture what is going on when a crash occurs.

The following describes a few of the tricks that can be pulled with the VIC-II. It is a great chip, very capable for the time. I wonder if something like DMA trickery is causing issues.
[url]ist.uwaterloo.ca/~schepers/MJK/ascii/VIC-Article.txt[/url]

_________________
http://www.finitron.ca

If I'm reading that scope picture correctly, the highs at the clock input is 3.2v ish. Isn't that a little low for the clcok inputs?

I thought the clock inputs on the 6502 family needed to be more or less rail to rail ?

Thanks for the responses.

Yes, that's correct. Although, I think there are two observations that I shuold separate: 1) ringing after clock edges and 2) noise after switching transceivers to output. Even though they both might ultimately be the same issue (fast edges), I thought I would tackle one at a time.


Yes, you're right. I recently bypassed the transceiver I was using for PHI, BA, CAS, RAS and AEC signals on my prototype board. When they came from the transcevier, they were 5V but I saw even worse ringing than I do now. I have no control over the slew rate/drive from the transceiver like I do from the fpga. It seems 3.3V is still enough to register HIGH and it appears to make no difference in terms of stability.

Yes, I think you're right. The fast edges are causing the ringing after the clock edges I'm seeing on the scope.

As an experiment, I turned off address bus direction switching (so never output) and bypassed the transceiver for outputs PHI, BA, CAS, RAS & AEC. I set the slew rate to QUIETIO which is the slowest available on the Spartan6. Then I captured the PHI for 2ma, 4ma and 8ma drives. Here is what things look like under that setup:





The ringing gets worse as drive goes up but I think it's the rise/fall time that's the issue.

Here is a comparison of real chip vs fpga rise/fall.

REAL (why is voltage around 3V using a real VICII???)


FPGA with slowest slew rate/lowest drive available


I don't have any control over slew rate from the transceivers and things looked even worse from there. I was getting crazy spikes at the edges on RAS/CAS signals and without the transceivers it looks a little better.

Is there something I can do to slow the edge rates? Any particular values you would suggest for series resistors? I'm not sure if lowering current will have that much of an impact though.

I tried this today. Normally, the address direction is switched along with AEC. I narrowed the window where the transceiver is driving outputs to make sure there was no bus contention. So direction change looks like this now (instead of following AEC):



When AEC is low, the CPU should not be driving the address bus and I think I gave enough slack there to make sure the VIC actually owns the bus.

The noise just seemed to move later in the cycle slightly but did not change so I don't *think* its bus contention. I think it's fast edges and lots of switching as you suggested.

Yes, most of the time the swing isn't large enough to cause any issues. When I do get a JAM, it's usually in the same location in the demos I've been testing. So I think what might be happening is that the demos just happen to cause a lot of lines to switch at that point and it gets to be too much. That's just my guess though. I thought of hooking up my logic analyser as you suggested but haven't gotten around to it yet.

(It's also worth noting that I've also managed to get these same demos to crash on a real 6569. They really seem to push things to the limit.)

DRAM refresh seems to work okay. I can leave the computer on for hours and it doesn't look like anything is lost. I'm fairly certain the refresh counter is correct. I have a check in my VICE/simulator hook that would warn me if the output address does not match VICE at every half cycle so I would get a warning. It is cycling through all
256 rows. I ran Galencia with unlimited lives for over an hour the other day (ship just keeps respawning) and it kept running okay.



Yep, that doc was my bible for this project! That and VICE code....

Just a note about refresh: if you're not refreshing correctly (or at all) but the program still happens to visit all rows, or all rows that it needs to visit, on a millisecond timescale, then the DRAM will work. We found this in a 65C02 turbo board for an Acorn Master: short program loops would run fine, until they needed to access a value in a row which wasn't part of the loop. So, you don't need to run for hours to test refresh, a few seconds will do, but you do need to write to a row, not access it for some tens of milliseconds, then read back and require the correct value.

UPDATE

I put 33ohm resistors on the PHI/AEC/CAS/RAS lines and my clock (without any address bus switching still) looks much better. The ripple all but disappeared.



And rise time looks similar to what you get with the real deal.



Then I added the same resistor values to the 12 address lines but did not see a reduction in noise from direction switching.

This is a very exciting topic! I wished I could help more but my FPGA skills are very low end.

I do have a MojoV3 FPGA and I have several C64's (breadbin, PAL, NTSC and C64C). So not sure what I could do to help, but I'd be glad to try.

_________________
Cat; the other white meat.

Just watched your latest video. Great job. Amazing that buzzer caused so many issues. This is one more step towards totally recreate C64 using modern components (as I don't have a C64 and wants one). Love those new display modes. Looking forward to you open sourcing this so that I can add it to my 6502 SBC.

I recall a figure from Bil Herd that 68 Ohms was good for absorbing signal reflection. That might not be an optimal value but it would be a historically appropriate value.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Hi All, I dont mean to reopen this topic up again but I have some questions related to the FPGA development of the VIC-II.

I've been poking around at the c64FPGA source from 2008 and recent updated in 2014 by Dar for the MiSTer project and I have noticed some issued with this FPGA variant so I was hoping someone would be able to identify the accuracy of the current FPGA developments of the VIC-II.

The issue I am trying to resolve in MiSTer's FPGA source is related to the NTSC version randomly having character write delays of some sort and glitching as per the image below.



The timing of the 6510 to the VIC-II its a bit complicated and I have really not dug too deep into the detailed schematics here: http://archive.6502.org/datasheets/mos_6567_vic_ii_preliminary.pdf

I was wondering if anyone could help point me to the cause here or if there are existing problems with the older HDL sources.

Thanks!