Looking into timing diagrams and various schematics it seems to me that sharing memory between two 65xx-CPUs on the opposite phi's is quite easy, but sharing e.g. a 6522 VIA is rather difficult to impossible?

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

Hobbit1972, are you serious about implementing shared IO, or are you just curious? It's an interesting challenge, and shouldn't be terribly difficult.

The assumption here is that you've selected extra-fast memory devices, and/or the CPUs are operated below their maximum speed rating. (Slow things down, as Garth says.) With this approach arbitration is unnecessary because memory is capable of satisfying 100% of the accesses from both CPUs. This very same approach can certainly be applied for IO as long as the IO devices are fast enough.

An alternative to using opposite phases of Phi2 is to have the same cycle time apply for all devices -- ie; for both CPUs and for the IO. There would need to be arbitration logic that watches out for the (presumably rare) cases when both CPUs attempt to access the IO simultaneously. When this occurs, one CPU will get immediate access to the IO and the other will get a wait-state before its access. This approach becomes attractive if you're determined to have the CPUs running as fast as possible.

-- Jeff

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

Somewhere in the middle. For now I'm doing my tiny baby steps, getting one CPU running. But in the long-term I'm intrigued to implement shared I/O.




Starting point of my thoughts were the dual-CPU systems found in CBM dual-floppies, e.g. 4040. They share the memory between the two CPUs. This brought the question whether they could share their I/O as well. A look into timing brought that 6522 (1MHz) needs addresses setup 180ns before phi2 rises, so the approach sharing the VIA on opposite sides of phi doesn't work.
As Garth said, I/O not only has to have about double speed (or CPUs slowed down), but takes some logic to get the clocks of I/O and CPUs properly aligned - probably making it not worth to venture there. And of course it takes I/O that is double the speed of the CPUs.





But in this approach you'd have to have separate buses for both CPUs or one of them would be stalled all the time...?

In this case that means a 6522 rated for at least 2 MHz -- and these are easily available.

It's an interesting topic. As a general comment, maybe it's worth pointing out that, for the purposes of this discussion, IO and memory are the same thing. Both deal in two basic transactions -- reads and writes. The bus connections are the same. Both accept an address. During writes they also accept data; during reads they return data. It's true that an IO device talks to the "outside world" while memory talks to internally-retained information, but this nuance is invisible and irrelevant to the CPU(s) -- they don't know and don't care. I'm not aware of any memory-sharing scheme whose operating principle couldn't be applied to an IO sharing scheme.

Best to investigate before assuming defeat. Yes there's a challenge here but it's hardly insurmountable. Assuming 1 MHz CPUs, you could start with a 2 MHz "master" clock oscillator and, from that, have your logic (basically a divide-by-two flip-flop) derive two separate 1 MHz CPU clocks -- which would inherently always be aligned.

The shared IO device would itself require a 2 MHz clock, not 1 MHz like the CPU, but that's not a show-stopper. Nothing says the Phi2 waveform on the CPU has to be identical with the Phi2 waveform on an attached 6522, for example. It's sufficient merely to satisfy the pertinent setup and hold times listed in the datasheet -- and with a 2-MHz-rated 6522 that shouldn't be a problem. (During the 500 nS when the accessing CPU's Phi2 is high, the 6522 Phi2 would be low for 250 ns then high for 250 ns.)

-- Jeff

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

The fastest available 6522 has the same speed as the fastest 6502 - of course we could step on the CPUs brakes, but I can't see much gain in having a dual-CPU system running half of the speed of a single CPU-System.




I would be tempted to test feeding a 6526 CIA with phi1||phi2, but probably this won't work, for the datasheet requires phi low for 200ns (@1MHz)...

To me it looks the difference between I/O and memory is that memory is doing nothing in phi1 of a single CPU-system whereas I/O have some internal operation going on (sampling I/O-pins, counting...) relying on having a long enough phi1.

Question would be then, if I/O could be slightly overclocked to compress it's timing so that two of it's phi2's including address setup before and data hold after so that CPUs could still run at their nominal speed. But it seems that I/O would need to run at least 150% of CPU speed.

You're right -- it's not a solution that will make sense in every situation, but it might make sense in some situations. You haven't mentioned a specific goal you're trying to achieve, so I'm kind of guessing here, and have been keeping my remarks general.

No data transfer (read or write) occurs during phi1, but phi1 still serves to supply the setup time which memory and IO require prior to a transfer. (For example the /WR going to a memory chip is delayed because it's qualified by Phi2. A 6522 performs the same qualification with Phi2 internally.) It's true as you say that an IO device may have additional internal operations (besides setup) that occur during Phi1, but that's a factor which the datasheet timing figures already take into account.

There still may be room for novel solutions, but it'll take some careful study -- and possibly some experimentation, given that real-world timing limits can differ significantly from the figures published in datasheets. BTW, if you haven't already, you may wish to check out the Visual Guide to 65xx CPU Timing on my web site.

cheers,
Jeff

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

The "goals" that came to my mind:

One was theoretical - looking into CBMs strange overkill-design with two CPUs in their double floppies. I wondered why they only share memory and not I/O. Then I found out about the timing issue. And from that I started asking, if it would be possible --- to have two universally usable CPUs that both can handle the machine's I/O. This was also inspired by R65C29 with two 65C02 cores that both can access (internal) I/O.

The other one was more practical: if my project ever should lift off to that point, I would like to venture into a double CPU system, one supervisor CPU., the other one taking care of I/O (graphics to be specific). There it might be handy to let the supervisor CPU shovel data directly to slave I/O w/O copying first to slave memory. And w/o sending slave CPU to sleep in that time.

(That probably sounds weird.)



I actually have already - but thank you very much for that valuable resource!

Thanks for bringing the R65C29 dual CPU/MCU to my attention -- that's quite an intriguing device! I like how they saved resources by only having one set of internal buses and one ALU -- basically only one CPU! But the instruction register and all the programmer-visible registers are implemented twice, so it becomes multi-threaded -- a single CPU with two copies of its state. The two states are active on alternate system clock cycles. From the programmer's POV, the R65C29 has the appearance of two separate CPUs, operating in the same memory/IO space.

On page 3-16, the "Clock Oscillator" section describes timing. Unfortunately there's no magic here. Memory and IO operate at the system clock rate, with each system clock cycle featuring the familiar phase1 and phase2 periods. Each CPU operates at one-half the system clock rate. IOW it takes a Phase1 and a Phase2 for CPU A to complete a cycle; then it takes another Phase1 and Phase2 for CPU B to complete a cycle.

The datasheet says, "Programming and system design for applications which require simultaneous control of two or more independent asynchronous processes is thus simplified because one CPU may control one process while the other controls another one."

Hmmm. Like you, I find this hard to get excited about, as it seems only a few applications could benefit. (It would make more sense if each CPU had the ability to go dormant when unneeded, thus freeing up ALU/memory/IO bandwidth and doubling the execution rate of the remaining CPU.)

-- Jeff

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

It seems to me that one would want cpu#1 or cpu#2 to "own" an I/O device for an extended period of time. For instance if transferring a file via serial port a single cpu is likely to use the I/O port while the second cpu is locked out. Assuming the I/O ownership is long-term and not cycle by cycle could make it easier to use the I/O with multiple cpu's. You could have a flip-flop(s) that indicates which cpu owns the I/O and then stretch the phi clocks on the I/O devices for a single clock period to line them up with the owning cpu's phi clock. One might want to breakup the I/O into multiple groups so that both cpu's can use I/O (from a different group) at the same time. Each cpu could have exclusive ownership of an I/O group. It would require a lot of muxes on the address / data lines to support multiple I/O groups.
Another thing that would be required is semaphores.
Last time I played with multiple cpu's I had the RAM / ROM shared between cpu's but all the I/O on a single cpu. In order to perform I/O for the second cpu the cpu had to make bios calls which were serviced by the cpu with the I/O. Another issue is servicing I/O interrupts, which cpu services the interrupt ?

_________________
http://www.finitron.ca

This is an interesting approach.


And this the drawback.

So far all solutions are wasteful of efforts and the gain is probably not worth it.



This should be easiest to solve of all trouble involved with a dedicated IRQ enable register, so every CPU could decide whether to allow IRQ from one device or not.