Hi. Has anyone ever designed a multiprocessor system using only the 6502 as the computing device for everything? That is, one 6502 dedicated to sound, one for video, one for running the main program, one for handling I/O, etc?

The idea I am thinking is just to have a system capable of doing all these tasks without having to use ASICs for things, and all the programming is done with 6502 assembly language, no need to rely on ASICs. The main 6502 would delegate tasks to the other 6502s which call the main 6502 with interrupts. If one 6502 is not enough then you can have two to handle the video, etc. The idea is just to use only 6502s.

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

Thanks, will examine those. And thanks for your Primer too. Read that a while back.

And by the way, just to clarify, when I mention sound and video, I don't mean anything fancy. Just for human interface needs. Simple beeps and alerts or basic tones (it is arguable whether we allow usage of the 555 timer or keep it "purely 6502"). And the graphics can be either text only (with a few colors for highlights) or text and simple graphics. It would be mainly used for programming and interacting with programs.

Actually one of the harder things will be finding the relevant analog CRT-ish displays for this instead of modern HDMI screens (maybe using X/Y mode on CRT oscilloscopes? But that might potentially damage CRT scopes?) Just thinking out loud.

This multiprocessor machine would be sort of a step up from the AIM-65 types with only thermal paper and single line LED/LCD displays. It doesn't need to run super fast. That is to say, the multiprocessing is not for speed. It is for replacing ASIC dependency. It also has an educational value (at least to me) to do all the stuff using 6502 assembly language and pushing the experimentation of hardware signal timings down to individual cycles.

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

Ok thanks for the info.

It was not unusual for arcade video games to have multiple processors, and I have a feeling at least one used a 6502 for sound. (For example, the family of games built on Atari System II use a 6502 for sound.)

And it was not unusual to have a micro to perform disk I/O: from the PET onwards, Commodore put a 6502 in the disk drive, and initially they actually put two in: one for low level and the other for high level actions. Most other cases, I think, used a Z80 for I/O but the principle is the same.

Acorn's BBC Micro was conceived as a 6502 front end and a second processor to run the application. The first second processors were a 6502 model and a Z80 model. (Eventually there were 32 bit second processors.)

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

For me, the biggest challenge wouldn't be in programming multiple 6502s to divide the labor to provide a suitable user experience, but rather how to get them to communicate cheaply and efficiently with one another. Yin-Yang clocking? Dual-port RAM? DMA? Byte-wide message passing? Private/public memory-mapped segments? My hardware chops would need significant improvement before I could imagine attempting any of them ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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

I've also toyed with the idea of building a multiple processor based system... separate subsystems to handle various I/O (filesystem, text/graphic system, user entry (keyboard), etc., along with a main processor board that coordinates the rest.

For communication between them, I was thinking along the lines of serial, but at high speed (230.4Kb). Each subsystem would have a DUART on board, and could use one channel for sending and receiving commands and data. The basic idea is to have a continuous packet of data (sorta like the old iBM token-ring) where each subsystem can get commands and data and update their part of the packet with status and data. This would result in a constant amount of CPU bandwidth (overhead) to keep all of the subsystems in sync, so to speak.

Of course, one might think this is too slow for doing video, but it all depends. Back in the mid 80's we (IBM) released the Professional Graphics Adapter... a large two-slot card that had it's own processor, ROM, lots of RAM (at least at the time) and the onboard firmware provided a rich set of graphic drawing functions along with flexible text capabilities. Implementing something like this could reduce the amount of command and data that needs to be sent to the video subsystem perhaps.

Then again, I don't currently have any hard plans on building this... too many irons in the fire right now, so my 8-bit time is limited, but I do think it's an interesting project to work on.

_________________
Regards, KM
https://github.com/floobydust

A VIA is a ready made way to have a couple of byte-wide ports with handshaking. But two other approaches spring to mind: simple octal TTL devices for simple byte-wide ports on the one hand, and FIFOs on the other.

Coordinating the tasks of the various subsystems needs to be right - you could lose a lot of time debugging that. It's much easier if the flow of data is unidirectional. For example, if the keyboard CPU only produces keystrokes (and doesn't need to be told to light LEDs), and if the graphics CPU only produces video (and is not queried for what's in the buffer or where the cursor is.)

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

The key to this is inter-processor communication... and has been discussed here in the past and there are real-life examples - My favourite BBC Micro and its Tube interface - the Commodore PET (and derivatives) with it's IEEE link to the disk drives with their own CPU and possibly many others.

Non 6502 systems I've worked on in the past have had high speed (for the time) serial links and/or shared memory systems.

The BBC Micro Tube is a FIFO (or set of FIFOs) but to make that in a compact way today would need an FPGA, but a shared memory interface using small size dual-port RAM is do-able - with good address decoding then perhaps a 256 byte RAM region per peripheral is usable - the host CPU would write data, then send a signal to the peripheral which can then read the data and send a signal back to the host to say "done". (Signal being a byte in the shared RAM or interrupt).

The VIA solution is also a possibility but one VIA per peripheral.

Either way might work on a bus system - with the bus exposed to each peripheral which carries it's own shared RAM IC or VIA. If the video interface was high level then all you might need to send over the communication system might be simple commands like "print character", "draw line from x1,y1 to x2,y2" and so on. This is similar in principle to the TI Video chip of the era and pretty much how the BBC Micro does it.

My own Ruby project uses a mutually exclusive shared RAM system so the 'host' CPU (not 6502) does the serial, disk, 'video', with the user code running on the 6502/816. The video is done via high level commands send via the 'serial' interface to a 'smart' video terminal - which could be another 6502 system (e.g. BBC Micro) or (in reality, right now) an SDL application running on my Linux desktop.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/