My tendency is to downplay the dangers of unmanaged parasitics - because most of us are making hobby boards which don't have to keep a passenger plane in the air, so we can accept lower standards and have easier projects.

That said, sometimes it becomes clear that, for example, inadequate decoupling capacitance can cause unreliability, and unreliability is a difficult thing to pin down and fix, and might result in a gloomy end to a project.

The one thing that's paramount though is to keep clocks and strobes clean. Any other signals should only have to be stable for some short window around the clock edge, but a stray glitch on a clock will always cause trouble.

That's very interesting in terms of the relative importance of clocks and strobes versus other signals (e.g. data and address) - I hadn't thought about it this way but it makes sense.

Also couldn't agree with you more about the purpose - for me it is a spare time hobby, no one will be damaged physically or commercially, and so breadboard is just fine for me! I think if it wasn't for BB I would not have gone ahead with this project at all, focussing on just software using RPi or Arduino.

Maybe there is a design bug hiding somewhere—it's hard to tell from here. But be sure to go through the links I gave earlier. Good engineering practice—that nebulous term for applying your understanding of the concepts when you can't adequately model something mathematically—goes a long way. The clock frequency is not the issue so much as the rise times. If a signal takes only a nanosecond to change logic states, it will be harder to avoid the problems than it will be if it takes three or five or eight nanoseconds for example. With 74HC and 1MHz parts, you can get away with murder. As you move up the scale, lines have to get proportionately shorter to get the same dependable behavior. Otherwise building techniques will have to improve. The Cray-1 ran at 80MHz, wire-wrapped, and had some awfully long connections; but those were all twisted pairs, with one of the wires of each pair being the ground return so they were all transmission lines, not inductors and antennas. Ideal transmission lines neither radiate signals to other lines to cause problems, nor pick up any. I'm not suggesting we make all our connections twisted pairs, but rather that extra measures and care will have to be taken as we move up the scale. In any case, I will definitely second the motion that the clock lines get the greatest care.

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

Very interesting! I never though of wire wrap.. I guess I have become affected by the plug-n-play generation. I will check it out once I get to order some more supplies.

This project has gone slowly forward and I tested different solutions to get multiplexing working. The basic problem at this time is stability which makes the 65C02 stop. The 6502 is happy and runs along well, and the 65C02 can also read the memory without problems, but once I get it to write something it becomes rude and difficult.

The problem seems to be in the RW signaling in which one usually put the NOT(RW) signal to the SRAM OE and clock the same signal through a NAND with the CLK2 to get WE for the SRAM (this can be seen in most projects here).

I have used the same thing within the multiplexed system, but have a common signal that contains both a stable READ and a CLK2 multiplexed WRITE:

In the Write phase, the signal goes low with CLK2 which will fulfill the write. OE=MRW here and WE=NOT(MRW) for the SRAM.

In comparison to the "normal" way, this gives the same signal to WE, but since OE is just NOT(WE) we get OE enabled in the write cycle once MRW goes low.

Edit: I also tested having two separate signals for Read (Output Enable for SRAM) and Write (WE for SRAM). I can't get this to work. Basically I am trying to do it like this:


For simplicity I haven't connected the other lines and some of the signal logic is lost here. Both CPUs are running contineously, but Bus Enable (BE) is clocked so that each get slightly less than half a cycle. Both CPUs will read from SRAM, but writing does not work. The WE seems to go high at the end of each clock (as it should) and thus terminate the write cycle correctly.

The strange thing is that it runs nicely as long as there is no writing. E.g. reading instructions work, but once one tries a write, the processor just halts.

After measuring all signals and reading I am leaning towards what was hinted at earlier in this tread: My write pulse shaping is not optimal and will need to add more logic to get a better write pulse.

Now, since my real circuit contains a programmable clock, I could solder in that and put a faster clock in the 65C02 timing phase as long as I reset that clock at the end of each 6502 pulse. It may not work very well since the end of that clock phase will certainly stop with an out-of-phase transition at the end. So the clock would need to be varied until it is stable. And it would need to be reset almost every 6502 cycle to not get out-of-sync!

For the next version I will certainly use a PLD to get the logic to stick better. Compared to the 20MHz superCPU (65C816) of the C64, the main problem here is the programmable clock that can change. The superCPU solves the need for slower access (when it acesses the internal RAM on the C64) with a prolonged read/write cycle (it keeps the clock high much longer). That would also work here, but I would need a separate SRAM for the Vic-20's 6502 that ran slower, which is something I don't want.

I have also looked at the 6502 vs 6504 of the Commodore 4040-like drives, but they run at the same speed and solve the multiplexing by using an adder on the clock source and can therefore get a clock with twice the 6502/4 frequency for the SRAM write signal (which is what Mr. Finch already pointed out earlier in the tread).

There are some ways to flawless switch two out-of-sync clocks with flip-flops, but they seem to be too slow to be able to switch-in a single 1MHz HIGH pulse within a 3-14MHz clock.

Nice schematic...
Having CPUs running at different clock frequencies sharing the same RAM can give you quite a headache,
and I never had tried to build something like that.

But some time ago I had a 6502 CPU and a "graphics card" wired together, both running at a different clock frequency.
Since there are no two consecutive write cycles on a 6502 (except when writing the stack area), my solution was to keep
the address and the data of a CPU bus write cycle to $0400..$7FFF in latches, so the "graphics card" could transfer the write
later to its own RAM "at the right moment"...
but I think that doing something like that might bloat your circuitry a little bit.

;---

Like Rob Finch, I would suggest to use dual port RAM, this certainly would give you less trouble.

Downside is, that dual port RAMs are a bit exotic, a little bit expensive, and they tend to draw quite some current from the power supply.
Don't know, how much current a VIC20 power supply can provide before the enabling smoke leaks out...
So even when not using dual port RAMs, please take care there.

Would suggest to try the 32kB IDT7007:
http://eu.mouser.com/Search/Refine.aspx?Keyword=idt7007

There also is the IDT7008 (64kB) and the IDT7009 (128kB).

I re-drew your last diagram above, a couple of times, trying to wrap my head around it. After that, I didn't get very far before seeing that on the memory, both WE\ and OE\ will always be low, because either one processor's BE or the other's will be low.

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

After staring some more at the schematic above, I'd say that Garth is right:
there _is_ something wrong with the schematic.

Would say, that WE and OE at the RAM actually might be low_active, means /WE and /OE.

Try, if this helps:



BTW: write timing could be a bit tricky here, it would make sense to spend some thoughts
on the propagation delays toward the RAM /WE pin, especially when aiming for speed.

;---

Edit: Hmm...



It's just a thought...

Could you please post the schematics in monochrome for the benefit of the color-blind bats who inhabit this forum?

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

I think I'm greyblind. I can scarcely make out what the grey text says.

Sorry, after some years of using Eagle I wasn't aware that those colors could be _that_ confusing.
Monochrome pictures as requested:



;---

I am not sure but I think there is a general problem with this approach. What happens if you have two directly consecutive accesses to memory first from the left then from the right CPU?

I haven't investigated the schematics too closely, but the lack of a second clock strikes me. I _think_ the /CE lines would be continuously active - so the chip would probably notice the change in address lines and reads would probably work, but writes?

I have done a coprocessor board that uses shared memory between two phase-shifted 6502, and it's using a "2phi2" clock, basically a phase-locked twice-the-frequency Phi2 signal control the signals. It might be a bit complicated, but there is a textual description with timing diagrams (in the desc text file accompanying the board)
http://www.6502.org/users/andre/csa/copro/index.html

On the other hand - the old Commodore disk drive that used a similar shared memory system between their both 6502 (resp. 6502 + 6504) uses a simple 74LS157 A/B switch for the select and R/W lines controlled by one Phi2 for the 2114 RAM chips...
http://www.zimmers.net/anonftp/pub/cbm/ ... index.html

Cheers,
André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Hmm... this depends... but this sure would be a problem for RMW operations like INC,DEC etc.
W65C02 has a /ML output signal that indicates a RMW operation and that maybe could be used for "stopping" the other CPU.


In my 74157 schematic above, the 74157 select was tied to a "main clock".
Two of the 74157 outputs then generate two (nearly) non_overlapping clock signals for both CPUs...
if one would be aiming for speed, having partially overlapping clock signals due to propagation delays
in the clock generation circuitry for both CPUs means trouble.

My schematics above only were intended to be a help for getting the concept for the timing a bit better,
so didn't take much care about address decoding, consecutive memory accesses and such.
Also, maybe some "tweaking" would have to be done for the propagation delays of the read/wite signals.

BTW: It is possible to tie /CS of a RAM permanently to GND, then to use only /OE and /WE for RAM read/write.
This might slightly improve speed of the RAM... by increasing standby power consumption of the RAM of course.
Did this when building my 68020 computer.


Looks complicated indeed, reading all this will take some time...

Having some circuitry in the design from the start that generates clock and timing signals for two CPUs
sure is less fuss than adding a second CPU to an already existing system as "an afterthought".
To me, it's only a theoretical discussion because I never had more than one CPU in my homebuilt stuff.


Using 74157 for switching the RAM address lines too is a nice idea.

Hmm... starting to wonder, if one could have two 6502s at each side of a dual port RAM... that's four 6502s in total.

Sorry for slow response. I have been tweaking my mind on learning Lattice Diamond & Verilog for CPLD and it took some days to get into it.

Here is my timing diagram for the different pulses:


The actual circuit has a short delay between BEL and BER going high (about 50ns) and is not constructed by a simple NOT (to remove bus contention). As you see, WE goes low for write, stays high for read.