I have a VIC 20 that I have put a 65C816 into via the CPU socket. This is a work in progress as I am working on implementing four banks of 64K. I was thinking of running the '816 at 7 Mhz, derived from the 14.31818 mhz clock, but switching to 1 mhz when accessing the IO section of bank zero. Would it work to use a 2 to 1 multiplex bit to downshift to a slower speed when accessing slower areas of memory? Or would it also work to use the RDY signal to slow things down temporarily?

RDY would work. (I'm not sure what you mean by a multiplex bit.) You'd have an address decoder that looks at every address produced by the '816. RDY would get pulled low if the address matches the I/O range (and the ROM range, too -- right?). And there'd be a counter or shift register to ensure RDY stays low only for six clocks.

What's the status of your project at present -- have you got the '816 working at all? Even sticking entirely to the original memory and the original clock speed you might encounter some difficulty.

Edit: here is some basic circuitry for generating wait states.

-- Jeff

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

I'd go with Jeff's suggestion that you wait-state the 65C816. It's technically less difficult to accomplish than trying to divide the 14.31818 MHz raw clock down to (approximately) 1 MHz with each I/O or ROM access—without glitching and possibly crashing the '816 in the process.

A couple of "gotchas" come to mind. Firstly, you can't just plug a 65C816 into a 6502 socket and expect it to work—the '816 is not pin-compatible with the 6502. There is discussion on this around here, which you can find via searching. Furthermore, the 65C816 doesn't have the PHI1O and PHI2O clock outputs of the 6502. These are used in the VIC-20 for clocking other devices, such as the 6522 VIAs that control much of the I/O. You'd have to synthesize those signals, such as with the below circuit.


Secondly, the kernel ("kernal") ROM code tasked with running the serial bus is timing-dependent in some places. Having the MPU running at seven times the expected speed may result in the serial bus not working at all.

Thirdly, the VIC-20's glue logic is 74LS, which in addition to having weak fanout, has limited switching speed. While any one 74LS device could readily keep up with a 65C816 running at 7 MHz, problems may arise with cascaded logic and the total propagation time of any given circuit.


As Jeff hinted with his question, you should begin by establishing that you can get the '816 to work at the standard VIC-20 Ø2 rate, which is approximately 1.02 MHz. As far as I can recall, the VIC-20 kernel does not use any illegal instructions, so that matter shouldn't trip you up.

However, in attaching the '816 to the VIC-20, you will have to pay attention to the clock situation, as well as the different pin-out, plus making sure inputs such as ABORT and BE are pulled up to Vcc (3.3K resistors will suffice). In particular, watch out for pin 1 (VPB), which is an active output on the '816 and must be treated as a "no-connect." That pin is a ground on the 6502.

You likely will have to isolate the 65C816 from the data bus with a bus transceiver (e.g., a 74ACT245), as during Ø2 low, the '816 emits the bank address on the data bus, which the VIC-20's circuitry will not be expecting. For example, if a ROM read is about to occur, the ROM may start emitting data before the rise of Ø2, which is when the '816 will still be driving D0-D7 with the bank bits. Bus contention will occur.

If memory correctly serves me, the revision B version of the VIC-20's mainboard is fitted with slow DRAM. You will probably be wait-stating every read and write operation carried out by the 65C816, as it is not likely RAM can keep up at 7 MHz (we already know ROM and I/O can't). I don't wish to discourage you in any way, but if all RAM, ROM and I/O accesses must occur at approximately 1 MHz, the performance gain of using a 7 MHz 65C816 will probably be quite small. The main benefit you would gain would be access to the advanced 65C816 instructions. However, you won't be able to use the 16 bit registers, because the '816 would have to stay in emulation mode in order to be compatible with the VIC-20 kernel.

You should consider these things as your proceed with this project.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Not to squash any ideas, but it may make a lot more sense to try to achieve what you want with a 65C02 before trying it with a 65816.

The 6560 VIC chip in the Vic20 uses a two phase clock via a 74LS02 and xtal with a frequency of 4X color burst, which accounts for the trimmer cap so you get the color burst frequency lock on a NTSC composite monitor. The 6560 divides this frequency by 14 internally to drive the 6502 CPU, i.e. The 1.0227 MHz clock speed.
As noted the Vic20 does use both of the clock outputs from the 6502, and the clock is synced to the 6560 VIC chip for memory access for video (the 6560 provides this sync). I would also note that a Rockwell 65C02 works perfectly fine in the Vic20, but the WDC65C02 does not (pin 1 needs to be floated and an additional pull-up resistor added). In general, it works briefly before locking up, likely caused by the fact that WDC specifically state that the clock outputs should not be used.
The early/original Vic20 used all 2114 RAM chips, 11 in all. The later version used a pair of 6116 RAM chips and 3-2114 RAM chips (a single 2114 was for video color memory). I don't recall any version using dynamic memory, but if so, would require additional circuitry to handle DRAM refresh. Note, the C64 used DRAM and the 6567 VIC-II chip handled the refresh.
To swap in a 65816, I would suggest using Daryl's adapter board, to ensure that you can get the Vic20 working first, then start with some modifications to extend the memory, etc.

_________________
Regards, KM
https://github.com/floobydust

(edit: posted while unaware of floobydust's submission.)


There'd be no need to divide 14.3818MHz down to 1.02MHz; the VIC-I vid controller already does that to clock the 6502. I believe what A0CBM might have meant by multiplex was to switch from 14MHz/2 to the already existing 1MHz clock as needed. For a very short time, I considered doing something similar.

The basic idea was to use the VIC-I 14MHz clock IN while the original 1.02MHz Clk Out is high...

...giving an effective 7MHz. If an I/O access is detected while 1MHz=0 the next 1MHz=1 is used to clock the cpu. If I/O access is detected while 1MHz=1, that is, while the cpu is being clocked by 14MHz, the following 14MHz ticks are suppressed and the cpu gets clocked by 1MHz the next time it goes high.

Existing I/O -- 6522 VIAs -- would be clocked by 1.02MHz delayed approximately 20nS, emulating what the Commodore schematic calls SØ2 (PH2O ORed with 1MHz).

There'd be several problems with this. As has already been pointed out, the "glue" couldn't keep up and neither could the existing built in Static RAM. The entire effort would be a waste of time if the system slowed to 1MHz for ROM access because the Kernal is accessed 60 times a second when VIA timer IRQs cause system housekeeping. And obviously, running a Basic program would access the interpreter ROM in between the system IRQs. Overall operation would be considerably slower than the desired 7MHz.

4MHz operation might be doable, though.

Four 7Mhz high states neatly fit within one 1MHz high. The method for slowing down for I/O would be the same as in the pie-in-sky 7MHz scheme. There's still the problem of the slow ROMs, but that can be solved by copying them to fast enough RAM while in Slow mode-- however, the existing RAM in the lowest 8K of address space would also present a problem. If the system has to slow down every time ZP or the stack are accessed -- not to mention screen memory that resides in that 8K -- performance will again be slower than what is hoped for.

I'm planning something less ambitious: 2MHz operation.

A low-going 80nS pulse from a one-shot creates a "0" gap in the middle of the 1MHz high, leaving more than 200nS on either side of that gap, more than enough time for the 120 or 100nS existing RAM, but still not enough for the 1980s era ROMs. I plan to replace them with a 70nS eeprom.

For Slow mode the 80nS one-shot would be inhibited when I/O access occurs while 1MHz=0. If I/O access occurs while 1MHz=1 the "defer" line keeps clock In low until the next time 1MHz=1. Obviously, there's more to the design than this brief description. Any criticism/suggestions regarding this idea would be appreciated.

I hate wait states.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

I rather suspect that the problem with WDC's is that it requires (according to the data sheet, which we all know has problems) that the input clock have a rise and fall time of no more than 5ns, while the 4MHz Rockwell part only requires 12ns and the 1MHz only requires 25ns. Actually, I don't know why the rise and fall time should matter for the Rockwell part since it has a Schmitt-trigger input and you can even use an RC, which I did on our top-of-the-line aircraft intercom model in 1993, and we sold it for 13 years and never had a problem with it. I ran the Rockwell R65C02 at approximately 1MHz with just an RC hung on the processor itself. WDC does not test the timings of the Φ1 and Φ2 outputs, but they are there and they do work.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

This is the circuit I have used on my VIC20, and I have gotten it to work with no other mods to the VIC 20. I have read plenty of good advice on what I want to do.

I have also succeeded in putting an 8K SRAM in place of all the BLK0 ram. This was done simply by tying the select lines of the decoder to ground and having the 8K sram enabled by output zero. This takes care of the data bus enable logic so the 3K section can be used by the VIC also.

I have used discrete logic to allow RAM beneath the Basic, Kernal, and Character ROMs, plus fill all the other 32K of memory. Character ram and blk0 are each separate 8K ram chips, and the rest of memory uses a 128K sram. I am currently working on putting all that logic on a Xilinx XC9572. While I'm at it, I might as well have some logic to use all the memory of the 128K sram, plus one more, so I'm not wasting the capabilities of the 65C816. The 628128 ram chips are 35ns, so I was also thinking of having the 65C816 run at 7mhz during access to at least banks 1, 2, and 3, knowing I need to slow things down for at least part of bank 0 access. Basic and Kernal roms can be copied to ram so it can run at 7mhz, but that sounds like it could cause issues with IO. Bank 0 is qualified by address lines A16 and A17 being zero. I like the idea of using a flip flop, set up like was done on the CPM cartridge, to change clock speeds, but I don't think that would work for bank 0.