Two 6502 System

Guybrush · Post by **Guybrush** » Mon Jul 26, 2021 2:29 pm

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 · Post by **BruceMcF** » Mon Jul 26, 2021 6:35 pm

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 · Post by **Gromit337** » Wed Jul 28, 2021 7:30 pm

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 · Post by **BruceMcF** » Thu Jul 29, 2021 12:49 am

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

EMwhite · Post by **EMwhite** » Thu Jul 29, 2021 1:55 am

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 · Post by **ZeroByte** » Thu Jul 29, 2021 1:56 pm

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 · Post by **Scott Robison** » Thu Jul 29, 2021 3:00 pm

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 · Post by **Brad** » Thu Jul 29, 2021 3:01 pm

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 · Post by **Scott Robison** » Thu Jul 29, 2021 3:06 pm

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 · Post by **Scott Robison** » Thu Jul 29, 2021 3:10 pm

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.