Work has started on a 6502 grid computer. The computer will be composed of 16 nodes in an X-Y mesh, each of which has two 6502 cores (32 cores total) along with associated memory. Interconnection will be via shared memory blocks. A topology map is shown here.

The plan is to use a basic interpreter to operate the thing.
The 6502 will have to copy messages between memory blocks for communication. Message copy will likely be periodic interrupt driven.

_________________
http://www.finitron.ca

While the software will be quite a challenge, it looks like it might be quite easy to express the design - I'll be interested to hear how well it fits on the FPGA and how fast it's expected to clock.

(As FPGAs have a physical floorplan, the on-chip RAM will actually be found in a particular organisation, typically several columns, so the placement of the compute cores and the wiring to and from the RAM might prove to be the dominant effect on speed and routability. It might even influence what X, Y sizes of grid would be a good fit: maybe square, maybe tall, maybe wide.)

Very impressive.

Now I must insert the obligatory "Can it run Crysis?" meme....lol

_________________
Cat; the other white meat.

By my count, there's still 4KB of address space per CPU unaccounted for in those nodes; presumably that's for zeropage, stack, and local memory?

Will some nodes on the edges have additional I/O to get things, well, in & out?

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

The 4k missing is reserved for any I/O in the node that might be needed. The 28k ram shared between the two cpu's will cover $0000 to $7000.

Memory Map:
$0000-$6FFF 28k shared ram
$7000-$7FFF 4k connection ram (east,west,north, south ram)
$8000-$8FFF 4k connection ram
$9000-$9FFF 4k connection ram
$A000-$AFFF 4k connection ram
$B000-$BFFF 4k I/O area
$C000-$FFFF 16k shared rom

Yes, some of the nodes on the edge will have I/O connected. One node will likely be for input (keyboard, buttons, switches). A second node will be for output (leds, text display). There may be an AppleII compatible node.

I may have to rethink the shared memory for interconnect as it may not map well to the FPGA. But I'm going to give it a try.
A 4x4 grid to start. BRAM is organized into 9 columns in the FPGA however. So a 9x2 grid might work better.
I've used a serial interconnect in the past.

_________________
http://www.finitron.ca

ooh, two nodes share zero page? And page one? That could be interesting. But then, I think I notice that all memory is shared, in one direction or another, so that was bound to happen. Is this why you have node pairs, so you can have two builds of your software to have half each of those two vital pages?

Sharing ZP and stack? Isn't that a bad idea?

The dual disk drives from CBM used two 6502/6504 cpus, but they didn't share $000-$1ff:
http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/old/4040/memorymap.txt

Unless you avoid all stack operations, which is pretty limiting... that isn't going to be easy..

It's quite OK if one stack pointer starts at FF and the other at 7F, and likewise if they carefully allocate their respective use of page zero locations. They can't both be running exactly the same code though.

I'd think that there are two ways you'd handle it. As BigEd has pointed out, one way is to give each processor half the stack space (128 bytes each instead of 256). The other is to have a single stack pointer between two processors.
I think the second one could potentially be more useful(quick data passing, generation of a jump address or one by the other, and probably more), but you'd have to be careful about how you used the stack so that nothing unintentional occurs(bad jumps and such).

An address bit (a9) will likely be flipped on one of the processor's so that the stack and zero page appears at $200 on the other processor.

_________________
http://www.finitron.ca