Hi,

I am making an expansion board for a Vic-20 that uses 74LS245 for buffering the NMOS 6502 bus towards a SRAM chip with a 65C02 connected to the same side as the SRAM.

The multiplexing was supposed to be done by using Vic-20 IO signals so that the 74LS245 opens the bus towards the NMOS6502 (Vic-20) if it is needed, but only at the internal clock being HIGH. In theory one could do this with clock LOW (Vic-20 clock at 1MHz), but due to component latency it only works (for full memory space) by using the HIGH phase. The 65C02 gets access to SRAM at LOW phase (it has the same clock so goes towards SRAM at clk2 being LOW).

From the Vic-20/NMOS6502 side everything works fine and I can get to all the memory I want. I also did some remapping so that I can get to the 65C02 vectors >$FFF0. I can write and read the memory without problems.

Now, the 65C02 seems to start when I reset it after writing to its vectors, but then it either stops or goes into some kind of loop.

I am synchronising WR from both the 6502 and 65C02 with the respective clock phase being HIGH and LOW. The enable pin of the 74LS245´s are also synchronised with this clock and connected to the BE input of the 65C02. The idea is that when the 74LS245 opens, the 65C02 disables its bus through the BE pin.

Apparently this is not working. Anyone got any idea of what I am doing wrong here? It the BE input a bad way of disabling the 65C02 bus? Too slow?

Edit: the SRAM is a 1MBit Alliance Memory with 55ns latency. The 65C02 is the 14MHz version from WDC run at 1MHz. The NMOS6502 is from 1983.

Is the VIC IC VIC-I 6561 not in the way during phase 1?

It certainly is in the C64, but what I remember from the VIC-20, there is something happening on the bus also in the VIC-20 during phase 1 originating from the VIC-I 6561.

No, the 6560/6561 is on the other side of some internal 245 buffers along with the internal SRAM. For that same reason the internal SRAM is not accessible from the expansion port of the Vic-20. You can see that from the schematics here. My 65C02 unit is added onto the expansion port through another set of 245 buffers.

My current circuit look like this:

I could use it to get the NMOS6502 to access the SRAM at clock LOW as well (a period is 500ns and the SRAM only needs 55ns to get it), but the extra logic on IO2/3 excluded that area due to timing issues. So I moved it to clock HIGH instead of using delay lines.

What all is affected by this? I seem to remember that the VIC-20 uses the 6522 (and maybe the '51?) which has to have the R/W\, RS, and CS lines valid and stable some amount of time before Φ2 rises. The diagram does not show the whole thing, so I don't know if this affects what you're trying to do. BTW, if that's from Eagle CAD, Cadsoft says the colors can be changed by the user. The light gray pin numbers and labels on the ICs are awfully hard to read, so it would be good to darken them up.

_________________
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?

Sorry about the color/poor resolution. I updated the expansion schematics (above). The pin 36 of the 65C02 is also BE (its not specified in the package file I used). I only show the part that has been connected on my breadboard. The 65C02 clk2(in) runs at the same phase as the clk2 output on the Vic-20. Eventually I will run it on a separate clock to get it faster, but for now its ok to get it running at the 1MHz from the internal Vic-20 clock.

I am not accessing the 6522 or anything else in the Vic-20, its only NMOS6502-> expansion port communication that is used. If neither of the BLK1/2/3/5, RAM1/2/3 or IO2/3 lines are low, nothing happends in my expansion since it won't open the 74LS245N buffers I have on the address/data bus. So effectively the 6522 is isolated from the expansion port when its accessed (its in memory area IO1). I also run a test for crosstalk and there is little of that on the Vic-20 side at least.

My primary suspect at this time is the transition between NMOS6502 and 65C02. It takes 40ns for the 245 buffers to go tristate and it takes 30ns for the 65C02 bus to go tristate. That is maximum delay. If they don't do this at the same time, you may get bus collision for some nanoseconds and that has been seen to give bus problems before (with the 65C816 that uses both phases for memory access).

I will test the timing thing quite soon since I just recieved a 16ch logic analyzer (just need to find the time to set it up).

Update:
I tested the breadboard and as I suspected the BE goes high a little early. E.g. it tells the 65C02 to enable bus about 10-20ns before the 6502 data lines switches off. Now, the logic analyser doesn't show much of the actual signal execpt a 10-20 ns variation in the databus. Is this normal or is it due to a conflict? I don't really know yet.

When I run the 6502 (Vic-20) it drives BE high and accesses memory correctly. I then reset the 65C02 and trigger its reset-vectors so that it starts doing something. I am not sure it is doing what its supposed to, but the 6502 side continues to function for some milliseconds. Then it gets bus garbage and folds up.

I have looked further into the problem and it looks like there are two problems. The first is mentioned above - one can get bus collisions which will mess up the databus. About 1% of the data going over the bus gets this at the current state. I planned to use a delay chip (74LS31) and some logic to get shorter clock high pulses.

Now the second problem seems to be that my 65C02 is working slightly different. In comparison to the old Vic-20 NMOS 6502(that runs at 1.1MHz), it reacts faster and is slightly different with respect to the read/write cycle. At 1.1MHz one actually ends up having the read cycle during clk2 LOW while the write cycle keeps going during clk2 HIGH. So multiplexing with a NMOS 6502 becomes somewhat difficult if I choose HIGH or LOW for the 65C02.

Anyone else here had this problem? I am thinking that maybe a delay so that the 65C02 gets half the cycle HIGH and half LOW will do. According to the specs I can give the NMOS 6502 about 300ns (during high) and it should still work. By using around 50ns buffer between the two processors and 500ns for the 65C02, I end up with 300ns+50ns+500ns+50ns=900ns. I plan to run the 65C02 up to 14MHz later (using a programmable clock - the DS1077Z100).

Suggestions?

Can the phi2 clock to the 65c02 be adjusted so that it pulses during the 01 clock cycle rather than using the CLK2 line directly ? The 02 latches data on the falling edge of 02. So prop delays on read cycles probably wouldn't be a problem.
It looks like the RAM chip is enabled all the time. Could there be a write pulse timing problem to it ? The write pulse should be shaped so that it's completely done during 1/2 of the clock cycle. I don't think this can be done properly with just combo logic gates.
Since the goal is to run the 65c02 at a higher clock rate, it would be running for several cycles during the 01 time. At 8MHz for instance the clock could probably be pulsed high for two cycles during 01.
It would be easier to use a dual-port RAM chip.

_________________
http://www.finitron.ca

Ahhh, you are right! The WE logic would switch any read/write after 1/2 cycle in current state. Even if the buffers does not open towards the NMOS 6502. Not good.. I will have to rethink that part.

Thank you.

This is a very interesting project. I'm always interested in projects that work with vintage computers.

Sorry for my ignorance, but what are you trying to achieve with this project? Perhaps I didn't quite understand your original post.

I have two VIC-20's myself. I've been thinking of bringing them out and using them for something. Just not sure what yet.

_________________
Cat; the other white meat.

Achieve? Bring them out! Have fun! Its a friendly computer There is lots of activity on the Vic-20 Denial pages. New hardware, new games, lots of interesting stuff if you like the 8-bit era.

Actually if you heard about the superCPU for the C64 computer, this is like the Vic-20 version. Its fun to make it and I will try to finish it so that more Vic-20 users can enjoy programming the 65C02 in a dual-cpu setup.

In current state it is running but very unstable. That is partially due to my breadboard and partially due to some missing caps and a little more revisions to the logic.

To be more specific, I changed the BE/245 buffer select so that its only stopping the 65C02 bus when the 6502 access the external SRAM (=not very often). So now I can run a short program on the Vic-20 that plots some external memory location to the screen while the 65C02 changes the same memory.

So I implemented the changes that Mr. Finch proposed and the 65C02 is now running:

The Vic-20 runs a program that plots memory location $2F00-$2F80+ onto screen (initially "AAAA" all over). The 65C02 then starts a program at $2E00 that modifies memory $2F00-$2F80 with characters $00-$80. As you can see there are some bit errors, but that is due to my breadboard spaghetti at the moment. I will get it down to a PCB later..

Current schematic (without programmable clock or 65C22 at the moment - the 65C02 runs from the CLK2 output of the Vic-20):


The "only" problem that is left is bus collisions when both the 6502 and 65C02 access the SRAM within the same cycle:


I will need to differentiate the 245 OE signal and BE signal so that the two buses dont overlap. Well.. a fix will hopefully happen soon.

Well, the fix happened sooner than later so that I managed to rewire my delay logic to get these signals:

For a clock cycle (900ns) with each number being 25ns:
CLK=000000000000000000111111111111111111
BE_=011111111111111111111111000000000000 --> BE=1 means that the 65C02 bus is active
OE_=000000000000000000000000011111111111 --> OE=0 means that the 6502 gets access to SRAM

Here is the current schematic:


If I only run the left part without 65C22, bluetooth and logic it runs fine (at 1.1MHz). That is I only get around 1 error per 255 bytes. I know I should have been more proper with the databus lines instead of hanging them around, so if I connect the 65C22 and logic (74HC133 +), things fall apart. It is probably the capacitance of all the lines, but I am not 100% sure.

I am leaning towards making a PCB of the parts already up and going, with a connector so that I can add the 65C22 ++ later. The question on how that will perform at 10MHz+ remains... I will make space for the logic so that reset & memory can be controlled. Sockets so I can test different parts.

and

It's probably not so much the capacitance as the fact that all those hoops of wire can be viewed as portions of large coils, and there is inductance and inductive coupling all over the place.

If you don't want to go to custom PCBs, wire wrap works much better than solderless plug-in breadboards do for this kind of thing. As fewer and fewer people are doing it and we're losing the economy of scale, I have been noticing that socket prices have been rising, and of course custom PCB prices have been falling, so at some point they cross. Nevertheless WW is easier to make corrections or additions on later. I have a page on answering WW questions and doubts in the 6502 primer at http://wilsonminesco.com/6502primer/WireWrap.html .

We have a sticky topic on getting good behavior in high-speed (high for us!) circuits, at "Techniques for reliable high-speed digital circuits," and I address it in the 6502 primer's page on AC performance at http://wilsonminesco.com/6502primer/construction.html .

_________________
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?

(As an interesting generalisation, Garth, I realised that I tend to think of parasitic capacitance as the bugbear, and you tend to think of parasitic inductance. Possibly that's because I've spent time in MOS chip design, and you've spent time in TTL board design.)

Hi Garth and BigEd.

I bow to your fantastic knowledge and insight, it has helped me on many occasions with my own learning and project. But, @ 1.1Mhz is this really due to stray capacitance or induction, or is there a design bug hiding somewhere? It's a big effort to move from BB to wire wrap or even PCB if it doesn't fix the root cause..

The reason I wonder is that my own build is running off a 21.48Mhz master clock, divided down to 10.74Mhz for the video chip and 2.68Mhz for the 65c02. This works reliably including needing to create two non-overlapping CS and /CS signals from the 2.68Mhz clock for the video processor as well as decode circuitry for other chip selects. All of the glitches I encountered during the build turned out to be timing issues. And my build is all on breadboard?

https://hackaday.io/project/5789-6502-homebrew-computer