Commander X16

While thinking about the 65c816, it struck me that, because 6502s are relatively cheap, a board could be made with two of them.

i tried to imagine WHY one would want to do this, and I’m not sure.  I suppose one could handle graphics and sound while the other orchestrated the system.  Maybe.  That’s how graphics cards and sound cards work, right, except they don’t bother with a generic CPU.

I/O could perhaps be handled by one chip.  The 6502 was embedded in the disk drives. But I’m not sure about that either.

it seems that it’s a solution looking for a problem.  There already exist cheap ways to deal with each problem a small computer has.

Just idly thinking about what problems Another 6502 might be able to solve in general.  It would of course not work with the X16 very well, since it would require a fundamentally different board architecture and not be the same computer.

My personal and theoretical ultimate 8 bit machine, would have at least a second 6502 as a coprocessor.

This could serve many functions within the system, but the presence of the processor would make the development for the machine quite a bit more interesting.

It would probably be far too complex, especially if it involved shared memory space, but it is fun to think about.

Both the SNES and Sega Genesis had sound coprocessors (the SPC700 and Z80, respectively). These were typically used to run music playback routines independently from the main processor. Additionally, several SNES games included the SA1, a secondary processor based on the 65C816.

The 1541 disk drive had its own 6502 IIRC.

11 hours ago, rje said:

While thinking about the 65c816, it struck me that, because 6502s are relatively cheap, a board could be made with two of them.



i tried to imagine WHY one would want to do this, and I’m not sure.

In addition to the NES, SNES, and Sega Genesis sound coprocessors, and the 1541 disk drive's 6502, the Sega Saturn had something like 6 "stream" processors which each ran their own op in parallel to the others. This wasn't true "multithreading", this was more like being able to run 6 operations simultaneously, and the assembly code files were literally 6 operations per line. I'm not sure how such a design might be possible with 6502s (I thought I'd read somewhere about using a pair of 6502s to mimic 16-bit-like processing, but I can't find the sources and don't even see how that's possible from the pins on a 6502); but even if it were, it's worth noting that the Saturn was famously difficult to program for, which kinda shows this was only marginally practical.

I could see a use for having a second 6502 for spinning heavier math processing off to another domain, but I would agree with others that it would probably be more practical to look into a more bespoke math coprocessor, or at least a different CPU for certain math operations, the way some folks used Z80 expansion cards for C64s and Apple IIs, or the way some SNES cartridges had the 3Dfx chip.

The hardest part of a dual processor 6502 is going to be communication between the two if they try to share memory. I guess dual port RAM could help alleviate that, though I'm thinking a "better" way (in as much as it makes sense to create a multi 6502 based system) would be for each CPU to have its own 64K of RAM with DMA circuitry sitting between the two. Then when one CPU wanted the other to take up a task, it could use DMA to quickly copy RAM from one RAM bank to the other and signal it to run.

Two 6502's could also run on opposite phases of the clock, like 6510 and VIC-II run in the C64 and access memory without DMA or dual-port RAM. If they need to signal each other, they could use a VIA to signal interrupts. I'm not sure if both could access the same hardware (except memory, of course) because the timings might be a problem, but if you dedicate one of them to handle I/O, sound or video, then they don't have to both access all of the hardware.

25 minutes ago, Guybrush said:

Two 6502's could also run on opposite phases of the clock, like 6510 and VIC-II run in the C64 and access memory without DMA or dual-port RAM. If they need to signal each other, they could use a VIA to signal interrupts. I'm not sure if both could access the same hardware (except memory, of course) because the timings might be a problem, but if you dedicate one of them to handle I/O, sound or video, then they don't have to both access all of the hardware.

That's a good point. I had C= 64 stuck in my head where the CPU had to share time with the VIC, but that need not be the case for a new layout. In that case, communication between CPUs could be as simple as reserving a byte with flags. One CPU sets a particular bit to "interrupt" the other CPU, and the other clears the bit to acknowledge the interrupt. Eight bits allows four bidirectional channels or whatever combination is desired. More memory could be reserved for message passing depending on the amount of data needed.

Seems too simple. ?

16 hours ago, Scott Robison said:

Seems too simple. ?

Likely.  I had thought about the co-processor (e.g. math) but why use a 6502?  I didn't think about the clock-sharing aspect, and I'm sure there is peril there.

What is clear to me is that writing code for such a beast would be annoying IF both were used as CPUs.  What I mean by that is that in order for development to not be a pain, one would have to be running off of a ROM (as a math coprocessor perhaps, but again why a 6502?), doing lookups or something.  

Maybe one could be a blitter.  But again, why use a 6502 for that?

And so things degenerate back to "proliferation of FGPAs for kitchen sink purposes".

Well the Fujitsu FM8/7/77 series featured two Motorola 6809s;  one was the main CPU, and the other handled video, keyboard, and controller interface.

I'm toying with starting a thread in General Retro Chat about my idea of what the Commander X16 (by probably a different name) would have been like if Mr. Murray had been a bigger Apple II fan.  The use of two 65C02s in exactly that configuration (among other things) will figure highly in my concept.

That thread has started here.