6502.org

Ok. That sounds great. I'm still not sure what the best solution for the SID chip is.

Note that only FPGAs have PLL feature. CPLDs don't have those, but they will let you build counters to divide down a fastclock.

Ok. Good to know. So I'm not sure where I can find information on the SID chip and how I can implement it. I'm pretty sure it would be limited to 1 MHz as well. I'm hoping I can just connect it to the 1 MHz side of my dual port ram, but I'm not certain if that will work (I'm almost positive it won't, I'm pretty sure it has to be on the CPU side). I'm pretty sure that chip is limited to the 1 MHz speed, but I will need to look at the C64s schematics again to see how it is connected to everything.

Hi. Welcome to the site.

The SID chip does require a 1MHz clock (1.022 MHz in an NTSC C64). It also requires a 9V supply in addition to 5V. There is also the swinSID to look at which is a SID replacement based on an ARM processor.
The SID needs to be driven by a bus master, so it would probably be connected to the cpu. Another way to connect the SID might be to use 65c22 I/O ports.

Generating the color clock for the VIC-II might be a challenge, it needs to be fairly accurate for proper color generation. I’d suggest using the clock generator chip (8701 chip) from a C64 which should generate the correct frequency. It will provide a color (3.58MHz) and 8.18MHz dot clock.
If using an FPGA the 8.18MHz clock could be multiplied upwards to generate a processor clock.

One thing about FPGA’s is that they are 3.3V. The 65C816 should run at 3.3v at a lower clock frequency.

Have you heard about the C=1 (Commodore One) computer ? It uses FPGA’s to generate video and interface to SID chips.

Yes, I have heard of the C1. Clever project, but I want to use some genuine hardware. I basically want to build a C64s that is still a C64 but with a faster CPU and memory and IO bus. So using lots of parts from a C64 is not a problem. The tricky part is integrating the chips that can't be sped up.

I'll have to look at how the c1 does it.

Ok, forgive my ignorance, but what exactly is a PLA?

PLA stands for Programmable Logic Array. It's basically a small custom logic chip. The one in the C64 is mask-programmed(programmed during manufacture). According to Wikipedia, the programmable equivalent is an FPGA(Field-Programmable Gate Array).

Ok, so I replace it with a FPGA. In a C64/128 what is its primary function?

An FPGA is massive overkill for this sort of thing. I'd recommend replacing it with a GAL(Gate Array Logic), like a 22V10 or a 16V8, depending on how many I/O pins you need.

I don't actually believe that an FPGA is the programmable version of a PAL. Wikipedia isn't the best source for information, and I should have said that. A GAL is almost certainly closer to the mark. A 22V10 or a 16V8 might do the job, but I don't know enough about the C64s PAL to be able to say(I know next to nothing about it).

FPGAs are often programmed to be used as CPUs, and they are usually surface-mount parts with lots of small pins. I wouldn't use one in a project involving a 65-series processor. That said, it can be done.

I know next to nothing about the PAL in the C64, but I'd imagine that you'd probably be able to find out what it is used for, and how it is used, by searching the internet.

In the C64, it mostly drives the chip select lines, on both phases of the clock pulse. It selects chips based on if a cartridge is plugged in and the state of the CPU's IO pins which configure the memory map, mostly which ROMs should be swapped in. There's quite a variety of memory configurations you can fiddle with it, and it's what allows writing RAM under ROM even when the ROM is swapped in.

As far as the implementation of the chip, I believe it's a pretty straightforward grid of logical ANDs/ORs that can be combined together to operate a truth table, which is burned in during production.

Ok, I've been fiddling with my schematics over the holiday. I'm in favor of using a single 64k dual port RAM. IDT makes one in a socket form. Also, the VIC chip in my setup no longer halts CPU operation to access RAM, since it is isolated. However, I'm not sure if I can directly connect the IRQ to the CPU. I would think it would still work correctly, but I'm no expert.

On the SID issue, I'm trying to figure out the best way to handle it. I need to kind of buffer that operates at the CPU bus speed and then passes the SID values to the SID chip(s). One way I could think is if there is a way to read the ram values on the 1 MHZ side and push them to the SID.

Also in regards to the ROMs, how to I interface the ROMs at their slower speed into the equation?

For the IO chips, I'm planning on replacing the 6526s with 65c22s. That way I can run them at bus speeds.

You can add some extra wait cycles by using the RDY pin on the 6502. When accessing slow peripherals or memory, you pull that pin down as long as necessary to pause the CPU.

Ok, that's should work, but I'm not sure how to actually do that. The software itself will not be aware of anything, the switch needs to be transparent. Is there a way to trigger that by an address range? Forgive my ignorance, this project is very involved.

Also one other thing, the 65xxx stuff all runs on +5 V power, but the ram I can find runs on 3.3v. Is that a problem? I'm planning on running things at 20 MHz.

Your glue logic would determine when to invoke a wait-state based upon the device being selected.
You would have to use level converters to adapt the RAM to the rest of your system. Note that level converters add propagation delay to the affected signals, which delay you must consider in your timing calculations.

Ok, one more issue solved. IDT makes a 5v version of the same RAM chip.