Two 6502 System

[rje]

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.

[Yazwho]

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.

[Elektron72]

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.

[Ed Minchau]

The 1541 disk drive had its own 6502 IIRC.

[StephenHorn]

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.

[Scott Robison]

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.

[Guybrush]

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.

[Scott Robison]

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.

[rje]

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".

Edited July 26, 2021 by rje

[Kalvan]

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.

Edited July 29, 2021 by Kalvan

[Guybrush]

A second 6502 could be used for playing complex music scores, generate PCM effects, bit-bang the I/O, anything that a simple DMA couldn't do. And it wouldn't take much extra logic on the board or an expensive FPGA (if the timings aren't too big of a hurdle).

And both could be running code from ROM or RAM, you'd just start the secondary CPU after the first one initializes some RAM locations to signalize the second one that it is, in fact, a secondary CPU. Of course, paging would be a real pain in the a$$ because each CPU will most likely need access to different pages, but I guess that it could be solved with another set of page registers and a few extra logic gates that would switch active page registers depending on the clock phase. Now, stack would be a whole different problem .

[BruceMcF]

Surely a 65816 and a 6502, so you know which one is boss and which one is auxiliary support. A 512K static RAM (expandable) and a 32K RAM and 512K flash ROM. The 6502 memory map is:

$0000-$7EFF local RAM

$7F00-$7FFF local devices

$8000-$9FFF external RAM window 1

$A000-$BFFF external RAM window 2

$C000-$FFFF ROM window

All the RAM banking is controlled in an I/O slot in the 65816 memory map ... the I/O server 6502 looks where it is told to look. It had a 4bit ROM bank register, as it is hardwired to the top 256K of the Flash ROM (which conveniently gives the 6502 and 65816 different power up ROM banks when their ROM bank registers are reset to zero on power up).

[Gromit337]

As the OP said, from a technical point of view it's an interesting idea, but practically, it's just a solution looking for a problem to solve.

Back in 1979, Atari 8 bits had Antic, Pokey, CTIA/GTIA etc. But they were custom chips and each served a specific purpose. The same with their spiritual successor, the Amiga. Even Atari equipped later machines with a DSP. None had a 2nd general purpose CPU running concurrently. The BBC micro had the brilliant 'Tube' interface, but the co-pro essentially took over the whole system.

Anything the 2nd 6502 could do, a dedicated chip will do it better. It would be more interesting to have say a Z80 along with the 6502, then you could run CP/M. Or perhaps something similar to the 'PiTube' for the BBC?

[BruceMcF]

The Sega Megadrive, aka Sega Genesis, had a Z80 for audio, in addition to it's main 68000 CPU.

[EMwhite]

I have two 6502 'systems' working in unison in my '8-Bit Wall of Doom' intro but really it's not cooperative or parallel but rather, a semaphore with one KIM-1 (an Uno) waiting on a signal (SIGWAIT) from another 6502 (a Corsham) system; one counts down and the other counts up in Space-Shuttle-Lauch-Sequence style.  Not really that exciting since they aren't exactly in Parallel. 

 

[ZeroByte]

A common application for a second general-purpose CPU "back in the day" was for a dedicated audio co-processor. Arcade machines very often used a Z80 (and less commonly, a 6502) as a sound CPU. This was so that the sound CPU could do all of the "tracker player" type stuff without taking bundles of CPU cycles away from the main CPU. I imagine that one reason this was as common as it was is that the various Yamaha FM chips are notoriously slow to access. As these chips all used their own clocks, it was relatively straightforward to clock a CPU and ROM/RAM from this same source, and put in a few latches as communication ports between them.

As to the comment above that "whatever a second CPU can do, a dedicated ASIC can do better" - that's not the case. Tasks which require logic (such as parsing and executing tracker-style music data) aren't easily done by an ASIC. ASICs are better than CPUs whenever a very specific operation is done repetitively. Decode compressed audio and video? Sure! Drive a display by converting between a block of data (screen memory) and outputting raster information? Absolutely. Play a MOD file? Not so much. That's why a GPU is great for many things, but not everything. It's great for massively parallel simple calculations. It's like having millions of adding machines linked together, but sharing a single "plus" button. If you have millions of "what's X + Y?" questions to answer, then you can load up thousands at a time, press + and then have thousands of operations done at once.

[Scott Robison]

I will agree with the basic premise "whatever a second CPU can do, a dedicated ASIC can do 'better'" for some fuzzy value of 'better'. The value of a general purpose CPU is that it can do many things because it can be modified through programming. Any program can be re-expressed as an ASIC (after all, a 6502 is an ASIC to execute 6502 instructions, which it does "more efficiently" [for some fuzzy value of efficient] than another CPU because of bookkeeping overhead on the foreign system). That ASIC can include bits of RAM and conditional logic, just enough to satisfy the application.

But at what cost? Design and development of hardware is hard (hence the name #haha). It is far more expensive than equivalent non-trivial software.

So sure, a dedicated ASIC could do just about anything, but that doesn't mean a general purpose CPU isn't a better choice in many cases. It just depends on what level of expense you can afford to design and implement, the volume you expect to produce, etc.

[Brad]

59 minutes ago, ZeroByte said:

A common application for a second general-purpose CPU "back in the day" was for a dedicated audio co-processor. Arcade machines very often used a Z80 (and less commonly, a 6502) as a sound CPU. This was so that the sound CPU could do all of the "tracker player" type stuff without taking bundles of CPU cycles away from the main CPU. I imagine that one reason this was as common as it was is that the various Yamaha FM chips are notoriously slow to access. As these chips all used their own clocks, it was relatively straightforward to clock a CPU and ROM/RAM from this same source, and put in a few latches as communication ports between them.

As to the comment above that "whatever a second CPU can do, a dedicated ASIC can do better" - that's not the case. Tasks which require logic (such as parsing and executing tracker-style music data) aren't easily done by an ASIC. ASICs are better than CPUs whenever a very specific operation is done repetitively. Decode compressed audio and video? Sure! Drive a display by converting between a block of data (screen memory) and outputting raster information? Absolutely. Play a MOD file? Not so much. That's why a GPU is great for many things, but not everything. It's great for massively parallel simple calculations. It's like having millions of adding machines linked together, but sharing a single "plus" button. If you have millions of "what's X + Y?" questions to answer, then you can load up thousands at a time, press + and then have thousands of operations done at once.

Well isn't that the trade-off between general purpose CPUs and ones designed for a specific purpose? You can either do all sorts of stuff at varying degrees of efficiency, or one or two things extremely fast with other tasks being sub-optimal. While ASICs are great when you know exactly what to expect, they are lousy when you start throwing them edge cases or weird stuff programmers like to do to show off. Hence, like you imply, there is no singular solution.

[Scott Robison]

3 minutes ago, Brad said:

Well isn't that the trade-off between general purpose CPUs and ones designed for a specific purpose? You can either do all sorts of stuff at varying degrees of efficiency, or one or two things extremely fast with other tasks being sub-optimal. While ASICs are great when you know exactly what to expect, they are lousy when you start throwing them edge cases or weird stuff programmers like to do to show off. Hence, like you imply, there is no singular solution.

A perfect example of that is the demo scene with VIC II (and I'm sure other platforms, but this is a good example). People have figured out ways to make the VIC II behave in ways it was never intended.

[Scott Robison]

My post about CPU vs ASIC led me to: That idea is a corollary to the idea that a bespoke algorithm can solve problems more efficiently than a general purpose algorithm. Take memory allocation on a modern operating system. The malloc and free functions are designed to work well across a broad range of cases and needs of varying sizes of data. But if you only need 16 byte allocations, a special purpose allocator that is tailored to that can greatly improve the efficiency of code.

I think about garbage collected languages. So much time, effort, money has been spent on automatic garbage collection to ensure the programmer doesn't have to think about it. Yet it involves overhead that is "easily" (another fuzzy word) overcome if one "simply" keeps track of ones own data and frees it at the appropriate time. In fact, even in garbage collected languages it is possible to leak data through circular references.

I was hired to work on a self-service media kiosk 15 years ago. The person who had implemented the touch screen interface used a web-page-like paradigm implemented in C#. It included a back button. Each new page stored a reference to the previous page so that the user could tap the back button to instantly return to the previous page. It didn't take many forward transitions to run out of resources and crash the system.

[SlithyMatt]

2 hours ago, Scott Robison said:

Each new page stored a reference to the previous page

That's an impressively bad design.

[ZeroByte]

HW-accelerated heap-management -> heapRAM = He-RAM.

By the power of hardware.... HE-RAM! ... I--- HAVE--- THE GARBAAAAAGE!!!!

[Scott Robison]

9 minutes ago, SlithyMatt said:

That's an impressively bad design.

It was just a thoughtless choice. "We don't have to worry about objects, allocate all we want, the system will collect them later!" without the corresponding "We need to make sure we forget all references to objects at *some point*." The bandaid I applied to that was to only keep the most recent X pages to give the instant back button for the majority of cases, then back becomes a home button if there are no previous pages.

To be fair to that programmer: he was young, and he was bright, he just had been tasked with implementing something quickly, and thoroughly analyzing the approach fell by the wayside. I wish I had a nickel for every time I was in a similar circumstance!

Edited July 29, 2021 by Scott Robison

[Kalvan]

6 minutes ago, SlithyMatt said:

That's an impressively bad design.

Why store each entire page web-cache style?  I''m pretty sure only storing the file location and/or previous answers to questions would have been sufficient.  Did the kiosk also feature artificial intelligence routines that required the user to input entire answers to essay questions?

[Scott Robison]

We had a much bigger problem, actually, that was the fault of no one in our office. Someone noticed that if you left the kiosk running long enough (after I fixed the memory starvation problem due to crisis of infinite page references), the screen stopped refreshing correctly. It didn't crash, but things like album art (it was a self serve media sales platform) wouldn't be drawn correctly.

In analyzing it, I noticed in task manager that the handle count for the process was climbing and climbing and climbing, and when it finally hit the 10,000 handle limit imposed by XP it couldn't allocate more handles. So we had a resource leak. But we didn't do anything directly with handles.

As it turns out, there was a bug in a C# implementation that would duplicate a region handle, do some work with it, then never discard the handle. The fix I implemented was to just rewrite that C# method and change all calls from the original to my bespoke version. It was not a routine that would be often used, but we did use it ... a lot!