It looks like I'm designing a modular computer composed of five board on a backplane.

Memory Board
- on reset the ‘259 is output is cleared causing the ‘688 to decode the rom address into bank zero $00xxxx.
- ram range is from $000000 to $3FFFFF there is a mirror image of the ram at $400000 to $7FFFFF.
- ram and rom occupy the same range at reset, however the ram outputs are disabled when rom is selected. Ram can still be written however.
- the reset routine will copy a partial image of the rom to ram then set the ‘259 ff so that rom is mapped to $FE0000.
- The ‘259 latch is selected at $FDFFxx in the IO address range.

_________________
http://www.finitron.ca

And now for the cpu board. The cpu is just running at 1MHz to keep things simple. I tried to come up with an interface between a higher operating speed and lower speed peripherals but it was just too complicated, complicated by the fact that the VIC-II chip is a bus master on alternate cycles.

CPU Board
- contains the ‘816, address latch and data buffer
- also decodes the I/O address range as $FDxxxx
This all hinges on me being able to find an '816 processor.
I've been working away on pc board layouts as well. It's all being save in my GitHub account.

_________________
http://www.finitron.ca

Audio Board
- contains a 6581 SID chip, 65C22 to connect a keyboard, and a 65C51 to connect a TTL level serial port.
- decoded to address range $FD8000 to $FD801F for the SID and $FD80820 to $FD803F for the 65c22 and finally $FD8040 to $FD805F for the 65c51.

A C64 keyboard connector was used as a keyboard is available in my junk drawer.

_________________
http://www.finitron.ca

Updated schematics and board layout for FAL6567. Added a latch on the address bits which ultimately allows 9 bit color instead of 6 bit.
Placed the resistor dac right next to the module to reduce emi.

_________________
http://www.finitron.ca

This project is still evolving.

I created another version of the board that uses an ADV476 color palette for the dac output. The reason to use the palette is it requires fewer pins from the cmoda7. A second reason is it allows more accurate color rendition. A four-bit color code can be fed to the dac rather than using nine pins. It ends up saving three pins as a clock and blanking signal are needed in addition to the color code. The three pins could be put to use to generate a composite output signal for at least monochrome output. It’s somewhat dubious to use the ADV476 as it’s an obsolete part.

One thing I’m not sure about is if the two four bit dacs for used for generating sync, luminance and color components will work. The color output is open source on the VIC-II and recommended there be 1k to ground. So on the assumption that that output has a 1k resistor attached to it I made the dac so that the voltage at the output is approximately 1v at maximum output. According to the C64 schematic there is a pot available to adjust this a little bit.

The other output for sync+lum is open drain with a recommended 500 ohms to +5v. So I adjusted the dac resistors to have this output at about 1v again.

I seem to remember reading somewhere signal measurements in the range 0.0 to 1.0V.

_________________
http://www.finitron.ca

I had to adjust FAL6567’s base clock frequency slightly from 33.750MHz to 32.727MHz. The MMCM (clock pll) can only multiply by up to 64 and I thought it could go up to at least 128 so I had it set at an illegal value of 66. 1 clock cycle was trimmed off all the timing shift registers. This may cause a problem of the ras high time (90ns instead of 120ns) being too short in the case of extra sprites mode. This shouldn’t affect the default operation.

The 32.727MHz is exactly 32 times the phi02 clock rate and exactly 4x the 8.1818MHz dot clock rate. There is also an exact divide for the color burst frequency of 3.58MHz.

_________________
http://www.finitron.ca

The Commodore 128 disabled the VIC-II chip when running at 2 MHz.

But then there'd be no video output. Simply disabling the chip is a good way to get a lot better performance.

I've toyed with a couple of ideas. The a6, a7 address lines on the VIC-II can be made to be inputs on the emulator. then with a few jumper wires to the C64 motherboard the emulator would be able to tell when the cpu is writing memory and maintain it's own copy of the memory. It could then scan the memory internally to generate the display while not using the external bus. That would speed up the system a bit because it would never need to steal bus cycles.

I note also the VIC-II has access to the R/W line so in theory it could be writing to memory. That allows for possibly an accelerator of some sort. For instance memory to memory copy.

I think I found a way to implement a 2MHz turbo mode but only for the test system. By doubling (or even tripling) the frequency of an internal clock the whole bus can be made to run twice as fast but it wouldn't work in a C64. Since there's a scan converter it doesn't matter that the VIC emulator is running too fast. Unfortunately I don't think chips on the C64 can keep up with a speed doubled bus access. I wonder just how fast the chipset in the C64 could be made to run. With heat sinks and a good power supply perhaps the system could run at a slightly faster clock rate.

_________________
http://www.finitron.ca

I would suspect that the PLA would be the primary problem. It's notoriously finicky. Especially in dealing with the cartridge port, the sub-cycle position & order at which transitions propagate are part of the hackery that keeps the whole system somehow running stably. However, the PLA is pretty easy to replace with a modern non-quirky equivalent, so that limitation can be bypassed.

Some of the C64s use the 6526A for its CIAs, and those are rated for 2MHz. I don't the SID was changed for the C128, so it should be fine at 2Mhz. Of course as you mention, you certainly should manage heat more aggressively.

Regarding the RAM chips, though, you'd probably want them running at current speeds while the rest of the chips are clock doubled to take both phases, which might mean simplifying some existing circuitry.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Okay, I've come up with a turbo mode that runs the bus about 20% faster than normal guessing that there might be enough leeway in the components to handle it. (40 MHz base clock instead of 33). It also changes the screen size to 384x200 from 320x200 to keep the video timing about the same. A problem that hasn't been worked out yet is how to handle the additional color ram requirements. It needs an extra 200 nybbles of color ram. Otherwise the colors would repeat on screen. If the screen is all the same color this wouldn't be noticeable.

The total width of a scan line in turbo mode is 632 clocks instead of 520. The screen can't be easily be made much wider because then sprites couldn't be hidden on the right hand side as sprite co-ordinates only allow up to 511.

_________________
http://www.finitron.ca

I don't see why you can't run the CPU and Vic-II at different speeds. There is no direct communication between them; they only share memory (which is what the registers are as well), so you only need to handle memory access at different speeds. The obvious answer to that is dual-port memory. The easiest implementation being to host it inside the FPGA?

The DRAM and PLA in a C64 wouldn't work at higher speed, but if you have a P500, that was essencially slowed down to work with the Vic-II (B600 & B700 runs at higher speed, but without the Vic-II). So it may be easier to get a P500 to work with a high-speed Vic-II.

There aren’t enough address inputs to the vic-ii chip to support an internal memory. A stock C64 only provides bits a0 to a5 to the vic-ii. With enough outside wiring of the C64 almost anything is possible though. It may be possible to use some memory on the module as a ram disk however because the address could be set indirectly using a handful of registers.

I had a look at implementing the vic-ii emulator as an expansion port device partly for this reason. Then found out that the Turbo Chameleon is available as an expansion port device already. It may be an alternate route to obtaining VGA output from the C64.

I designed (really copied some of it) an additional pmod board for composite output.
I’m currently trying to work out the code to allow the board to output at least monochrome video through the c64 as well as vga.

What is the P500 ? B600 / B700 ?

_________________
http://www.finitron.ca

The Vic-II uses A0 to A13 to access memory, so shouldn't be a problem to plug that into the Vic-II socket, include a dual-port SRAM and some logic to get graphics memory into that (from the C64). But since that is not possible here, it seems like you intend to have a unit to plug into the C64 expansion port? Or am I missing something?

The CBM-II series of computers. The Commodore P500 was the only one that contained a Vic-II chip (and ran at 1MHz), the others had a 6545 running at 2MHz (no color). But apparently the processor of the P500 (6509) also ran at 1MHz, same speed there as well..

While the VIC-II outputs a0 to A13, only a0 to a5 from the cpu goto the VIC. a0 to a13 are output in a multiplexed fashion and on the bus when AEC is low. When AEC is high the cpu has the bus, but only a0 to a5 goto the VIC-II. So the VIC-II would be able to read the dual port memory but the cpu wouldn't be able to update it.

Sorry for my ignorance, but even the VIC-I chip has access to a 16KiB memory space. And in the C64, the memory is filled up, so I don't see why you can't get access to the required bytes just because there is no direct access from the cpu. If fact, none of the VIC chips have internal memory, but that is no argument for not including an internal buffer to get better resolution?