cluster of 6502 to handle disk, serial, I/O, keyboard, and video with serial or dual port memory as interprocessor communication should be quite do-able. The biggest challenge may be a decent performing (VGA or better) video. If you keep the video 6502 circuit simple, it is reasonable to overclock 65c02 to 25.175mhz to drive video output directly. Such video 6502 also has enough throughput left to receive serial data at 230400 baud. viewtopic.php?f=4&t=6517
Bill

Ok great. Thanks for highlighting the importance of unidirectional flow. I had thought about something similar too, just delegate the task to the subsystem, but didn't realize asking for feedback (say, to confirm the command finished) would incur much more complexity.

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

So I read in the other thread it's possible to run the 65C02 at 25.175MHz?

Is this pretty "de facto standard" or only a few lucky chips? Officially I was told WDC rates the 65c02 at 14 MHz max.

What about the supporting RAM and ROM chips? And glue logic?

I haven't come across any newbie instructions (category of this sub-forum ) that use that high of a clock speed to give examples, so my concern is whether these chips (usually are obsolete by today's standards and bought/used by vintage hobbyists like us) won't burn up at that speed?

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

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

As Spock would say, FASCINATING!

Thanks for all the undocumented tips guys!

So, maybe there can be a startup routine to copy certain parts of ROM into RAM and then run only from RAM addresses from that point on.

My experience with overclocking W65C02 is based on one lot of 10 new W65C02 from Mouser. The same lot of parts are used across 4 SBC designs with different top speed depending on the designs. 24Mhz is the slowest for the more complex design to 29.5mhz for the simplest design. 65C02 may not be the limiting part in maximum clock; it could be other parts and even physical wiring. Different lot of parts and different designs will have different top speed. Video 6502 is closely related to CRC65 (viewtopic.php?f=6&t=6440) which is a simple design good to 29.5mhz, 7 out of 7 tries.
Bill

My recent design approach uses a small (32-64 bytes) ROM in CPLD which has 10-15ns access time and copies a bootstrap program resided in the CF disk to RAM and executes in RAM.
Bill

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

Is this what all the "Zero Wait State" marketing was about in the 1980s?

Aloha, on Anycpu.org I posted regarding a dual-processor 6809 system, and the same ideas could easily transfer to a 6502 multiprocessor system.

Inter-processor communication couldn't be easier, as the two CPU's share access to main memory. And, in support of video, one of the processor sometimes functions as a DMA controller (avoiding the need for a dedicated chip), which also seems in line with your goals. Good news! If you adopt this approach I guarantee you will get some experience dealing with "hardware signal timings down to individual cycles."

Nowadays it makes more sense to use SRAM (not DRAM). A single SRAM chip would be sufficient. Its address inputs could be fed by a multiplexer that accepts addresses from the two 6502's. (Or you could have more than two, but that might be rather challenging.)

Another option (instead of a multiplexer) is to tie the two CPU address buses directly to each other (and to memory), and to drive the CPU Bus Enable inputs so that only only one CPU will output at a time, with the other CPU's address bus high impedance or "floating" until it gets its turn.

Besides eliminating the multiplexer, this approach also offers a potential mechanical advantage. If you wanted, you could save time and space by soldering one CPU directly on top of the other! Almost all the pins will connect together anyway, and the few that don't can be managed fairly easily by bending those pins outward on the upper CPU and adding individual flying leads in those cases.

(I seem to recall this "piggyback CPU" idea being mentioned elsewhere on this forum.)

-- Jeff

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

Hmm. I've just had a thought. Because the 6502 (and 6800 and 6809, perhaps) only needs active use of the bus for one half of the cycle, it's a common idea, often enough implemented, to have two CPUs sharing the same memory bus. So far so good.

So, if we had a chain of CPUs, each separated by a shared memory, the same odd/even timing could be used. The CPUs at the ends of the chain have only one memory, but it's still shared by the adjacent one. All the others have two memories, one to the left and the other to the right. Any mailboxes or semaphores or data buffers would of course be in the appropriate shared memory depending on which direction the relevant resource is to be found.

One might imagine the keyboard and disk drives at one end, and the video and sound at the other end, with application processing done in the middle, but it needn't be that way.

If the resource isn't directly attached, there would need to be store and forward. For sound, that might be too much latency (or jitter) but for keyboard or serial devices it might be fine.

And now I realise that a chequerboard has the same property: a 'white' CPU operating on one phase shares memory with 2, 3 or 4 neighbours all on the other phase.

We do need some isolation - bidirectional tristate buffers perhaps - but they are available in TTL. Previous sketches used dual port RAM, and we're able to avoid that.

I'd still guess that the major difficulty with this whole area of ideas lies not with the hardware, but with the software. Relatively sophisticated techniques and reasonably good discipline will be needed, or the thing will lock up, or drop or duplicate data.

This is very interesting, and I have come across it in some other places (for example, on one website discussing modifications to the HP-48 calculator by piggybacking RAM chips). However, in that case, the clock speed is trivial. In this case, I wonder if there will be heat problems?