A multi-core 6502...would that be possible

[carmel_andrews]

Following on from foft's post/thread about 'new ATARI hardware' and recent developments and attempts at replicating various classic processor core IPs (the only one's i've heard of relate to Z80, 6502 and 68000, there might have been others)

 

I thought it might be an idea to consider the possibility of having a 'multi-core' 6502 (forget the cack about x64/IA64 or whatever they are passing off as 64bit these days, just a plain vanila flavoured multi-core 6502)

 

Seeming as though people have found ways of replicating 6502 in software (emulation) and reproducing the 6502 in all it's glory as a new processor (as mentioned above) I think the possibility is probably nearer then we think

 

Since the whole idea of multi-core processors is or was to be able to run various machines, systems or operation systems'virtually' from a single system without slowdown or having to reboot/restart or reset the computer

 

One possibility for a multi core 6502 could be used to run various classic 6502 systems (as different configs) i.e A8, c64, apple II, vic 20/Pet, Acorn/BBC, Oric etc etc but built as one system and just so out games machine loving fanbois/girlies don't miss out have a multi core 6502 system running classic 6502 gaming systems (as different configs), like the vcs/7800, lynx, nes, pc engine etc built as one system

 

Obviously the multi core 6502 would be an actual processor and the hardware replicating the hardware based on the various classic systems (i.e. PAG, sid/vic2/vic, tube etc etc) would be either FPGA hardware or similar

 

 

The idea here is that you could switch between the different classic systems via a toggle key, once the toggle key is used, the previous systems config and state it was left in (before you pressed the toggle key) is dumped to flash memory and each time you keep switching systems with the toggle key, the dumping action is done again but to a different block of flash memory for the previous system you were running and when you come back to the system that was first dumped to flash memory, you enter it (the selected system) where you left off and subsequently for all systems that you dumped to flash memory, since when you reenter any different system config, it first checks to see if you've previously used that config and dumped it to flash memory, if you have then it simply retrieves what was dumped/saved and restarts it from the point you left the system

 

this approach would be ideal for those developing programs or games across different 6502 platforms (or cross developing as i believe the term is called) as well as having a multi system design built into a single h/w platform

 

For the keyboard and mimicking the keyboards of the classic systems, what you'd have is a standard Pc keyboard, the various system configs would have the particular code to convert the pc keyboard into the particular system you are running and you'd have different keyboard overlays (just like the joypad overlays you got with jaguar games or vectrex screen overlays) for the keyboard so you know which keys respond to the particular key for the classic system you are running

 

In regards to the use of IO devices (if you are using original media formats, like tape or disk or cartridge) a seperate IO box would be possible that connects via a usb cable to the main system and on the IO box itself it would merely contain the different IO ports for the various systems the multi system is capable of running, as for cartrdiges though, you'd have a standard cartridge connector and different cartridge 'overlays' (adapters) to using cartridges from different systems

 

In as far as new media formats that classic systems can now use (i.e usb, cf and sd cards) those connections or ports would also be included on the IO box (saves you having different floppy/tape or cart emulators running from the system)

 

If such a system became popular it could be adapted for using different multi core classic processors (i.e 6800, 6809, 65816, Z80, 68000 family and so on) since a the system mother board could be upgraded to handling another multi core processor but based on a different CPU family or alternately if you remember those adapter boards that allowed pentium systems to run celeron processors (or was it the other way around) the same apprach could be used for handling multi core versions of different classic cpu families (like the ones mentioned above)

 

Naturally the FPGA or whatever hardware was used to replicate the various classic hardware systems could be easily upgraded by just replacing the chips and the same goes for the various different system configs, you just replace the bios chip that holds the various different system configs for the with a new bios chip containing the new set (based on that cpu family)

[Rybags]

Multi core is essentially the same as multi processing in a logical sense, ie the architecture and OS supports multiple CPUs accessing the same Ram and sharing and serialization of resources.

 

6502 and most older budget CPUs of the era were never designed with that in mind. But of course the architecture could be expanded to support MP operations.

 

The thing is the OSes of target machines are a bigger hurdle and building MP support would essentially mean a vastly different system would emerge.

 

To run multiple machines at once in a task-switching type of arrangement e.g. C64 and Atari wouldn't necessarily need multi-core, it could be achieved with a single CPU with expanded architecture and a whole bunch of tricks to tie in the custom chipsets of both machines.

 

A whole bunch of expense there, for something essentially with novelty value.

 

But there are modern day systems that run multiple machines in low-level emulation, I can't think of the name but fairly sure there's one that does Amiga, C64, Atari 2600 and possibly others all in the one box.

 

Note I'm talking emulation of hardware by hardware and firmware here, not simple software emulation of hardware that most of us use daily.

[Bryan]

The greatest benefit would come from designing a more advanced/pipelined 6502 that would execute up to 1 instruction per cycle. Combine that with a faster clock and things would really scream.

[+Gemintronic]

I suppose you could use an FPGA to mimic multiple CPUs. You'd have to find a Unix clone and tweak it to access each processor.

 

Much easier to go for a comparable 8-bit propeller based device

http://www.xgamestation.com/view_product.php?id=51

[JamesD]

A multi-core 6502 is certainly possible but the 6502 hits memory on most clock cycles meaning you would have a lot of collisions attaching it to an old design.

Sharing page zero and the skimpy 256 byte stack space between multiple cores would not work well so you at least have to give each core some low memory of it's own. It's say at least 1K of built in RAM per core if not more. Then I'd suggest at least a shared unified memory cache for dealing with the rest of memory if not giving each core at least 16K of RAM.

I think a multi-core 65816 would make a lot more sense due to the large address space.

 

A multi-stage pipelined 6502 isn't really going to help because the CPU is constantly hitting the buss already and you won't have any cycles available to load additional instructions into the pipe.

One possible alternative would be to use burst mode RAM to pre-fetch the next several bytes from RAM and clock the CPU several times faster internally than the buss interface to reduce the clock cycles per instruction. I think that would reduce most instructions to 1 or 2 buss clock cycles and page zero indexed addressing to 3 buss clocks or less. It would probably be a simpler design than a multi-stage pipeline as well.

 

You would not want a Unix clone, it's not really designed for such small systems, however, you could implement some Unix like features for sure. A Unix like shell is available for the IIgs.

 

Frankly, the easiest approach to speeding up a machine would be to recreate the ZipChip CPU upgrade. It's basically a 6502 running faster than the system buss on top of some cache memory.

Edited August 16, 2013 by JamesD

[kenjennings]

As long as we're talking about pie in the sky processor capabilities.... A 6502/65816 accelerated to any arbitrary (or insane) clock rate without any RAM/DMA contention with ANTIC would be slick. Imagine a DLI that could change all the color registers every few color clocks.

[JamesD]

As long as we're talking about pie in the sky processor capabilities.... A 6502/65816 accelerated to any arbitrary (or insane) clock rate without any RAM/DMA contention with ANTIC would be slick. Imagine a DLI that could change all the color registers every few color clocks.

FWIW, even adding 1K of low memory and some additional logic on a regular CPU would let all page zero and stack access cycles operate without contention.

Since page zero and the stack get quite a bit of use it could offer a noticeable speed increase.

Put some speed critical code in the other areas of that 1K and you end up running at full speed more of the time.

[Chilly Willy]

There was a dual core 65C02 made back in the day. I've got the datasheet somewhere... need to find all that stuff one of these days.

 

From what I remember, it was two 65C02 cores that shared some pins, and had separate lines for other things (like ints and control lines).

[thorfdbg]

I thought it might be an idea to consider the possibility of having a 'multi-core' 6502 (forget the cack about x64/IA64 or whatever they are passing off as 64bit these days, just a plain vanila flavoured multi-core 6502)

What use would that have? I mean, the Atari Os is completely unprepared of handling that, leave alone the applications, leave alone the system design. Whenever you hit the hardware, you would need to coordinate the CPUs, but since the layer between the application and the hardware (the os) is so thin, there is hardly any chance of getting this to work from a software perspective. Unless you want to create a completely new machine, which you could surely do. But then why base the design on the 6502 in first place - it's utterly bad prepared for that.

 

 

Since the whole idea of multi-core processors is or was to be able to run various machines, systems or operation systems'virtually' from a single system without slowdown or having to reboot/restart or reset the computer

For that you would not use multiple cores. You would use virtual or programmable hardware, which is something entirely different.

Given that a modern PC can easily emulate most of the older systems, you have this already, in a sense.

 

Anyhow, even a multi-core 6502 has a couple of "problems" to say the least. Zero page need to be shared, and even worse, stack need to be shared, which is likely impossible. Thus, you would need at least two independent copies of page 1. Synchronization/locked instructions are missing, required to to build the synchronization primitives like semaphores and mutices, i.e. something like "test and set" or "compare and swap". Atomic instructions are missing. Independent interrupt handling is missing...

 

In the end, you get a completely different system than you had, with no software for it.

[kogden]

I thought it might be an idea to consider the possibility of having a 'multi-core' 6502 (forget the cack about x64/IA64 or whatever they are passing off as 64bit these days, just a plain vanila flavoured multi-core 6502)

 

Actually x64 is much cleaner than the old i386 architecture. Modern PC CPU's are RISC-ish CPUs that emulate the old instruction set. Similar to how the 65816 starts in 6502 mode and you have to tell it you want it to be a 65816.

 

Since the whole idea of multi-core processors is or was to be able to run various machines, systems or operation systems'virtually' from a single system without slowdown or having to reboot/restart or reset the computer

 

Ummm.... no. You're thinking of hardware virtualization which is a whole other can of worms. That can also be done with a single core CPU. It's also been used in data centers since the 1960's on IBM mainframes.

 

Multiple cores generally just lets you handle load better and split tasks across multiple CPU's or run more concurrent tasks. This is also not as easy as it sounds, at least with any real performance in mind. Talking to RAM becomes a hell of a lot more complicated, etc. Without a real multitasking (preferably multithreaded) OS and software to go with it, it would be useless. And it certainly wouldn't be an Atari 8-bit anymore. Compatibility would go out the window pretty quick.

 

One possibility for a multi core 6502 could be used to run various classic 6502 systems (as different configs) i.e A8, c64, apple II, vic 20/Pet, Acorn/BBC, Oric etc etc but built as one system and just so out games machine loving fanbois/girlies don't miss out have a multi core 6502 system running classic 6502 gaming systems (as different configs), like the vcs/7800, lynx, nes, pc engine etc built as one system

 

Again, multicore wouldn't help you with this. What you would need is a chipset capable of emulating all the custom chips of those platforms. Just having a second 6502 isn't going to help you much there.

 

Hardware capable of "emulating" several platforms has already been built using FPGA's.

 

What made the 8-bits and early 16-bitters unique and "special" were the custom chipsets, not the CPU.

[+remowilliams]

A better question would be, why do people keep answering this type of rambling nonsense?

[TracMan]

I found this article interesting for a theoretical useful example where this might be useful.  If there were multiple 6502 cores on an Atari 8 and Antic pulled down the ROY line on each so that they all got interrupted at the same time, you could have each execute a horizontal interrupt/ kernel on the same scan line.  This might be very useful for changing hardware registers on the same line, since normally you can't get very precise timing, nor can you afford to lock the main CPU into the screen drawing for very long.  In it's most basic use, each additional CPU kernel would do their own timing of various lengths and change the hardware registers they needed to, before exiting the DLI.  The 1st core could simply exit the interrupt straight away to carry on with the main code.   When you additionally need to execute a STA WSYNC to control multiple lines for the kernel, only one CPU core would be able to do this (ie. either the one that does the last changes on the scanline nearest the right hand side or just one with a long dummy timing loop) so this can be programatically done.  The only issue would be there is only one vector pair for the horizontal interrupt.  I can only think that there would have to be a change to the O/S to jump through each vector and this would use some extra RAM.

 

For horizontal aligned games ie. where you have many sprites per line, you could have multiple kernels that just stuff the sprite details into the hardware register (avoiding DMA) and then just manipulate the vectors for each based on the scanlines.   Not saying this is not just rambling nonsense but this may certainly enhance the Atari's longevity into the future and allow more games to be converted.

 

 

[Rybags]

In multicore systems it's usually the case that 1 core handles interrupts and the others run masked unless sufficient interrupt activity makes it necessary for more to handle them.

 

For simultaneous DLIs there'd be contention for register writes (or any writes) so they'd be effectively queued.  Same for reads as well.

[TracMan]

On 6/10/2020 at 1:42 AM, Rybags said:

In multicore systems it's usually the case that 1 core handles interrupts and the others run masked unless sufficient interrupt activity makes it necessary for more to handle them.

 

For simultaneous DLIs there'd be contention for register writes (or any writes) so they'd be effectively queued.  Same for reads as well.

Ok thanks, didn't realise that was the case.

[atarixle]

I'd like to see a multi processor setup that just works like a C64 and his disk drive - but built-in and may be having access to its own 64k, but sharing the RAM-disk. Or 64k of the RAM-Disk is the main-memory of each other CPU. That would make sense since it does not need a patched OS.

[Kyle22]

Why would anyone want to multi process on an evil commie and slow drive? Use an Atari with Veronica cart and be part of The Great Awakening. Commies are in the dust bin of history.

 

[Eriknoc]

On 6/18/2020 at 3:05 PM, atarixle said:

I'd like to see a multi processor setup that just works like a C64 and his disk drive - but built-in and may be having access to its own 64k, but sharing the RAM-disk. Or 64k of the RAM-Disk is the main-memory of each other CPU. That would make sense since it does not need a patched OS.

The Apple IIe with the extended 80-column card (and IIc's) added and additional 64K bank of RAM (totaling 128K).  There was Main memory (64K) and Aux memory (64K).  You could read from or write to either one by toggling the right soft-switches in memory.  You could even transfer execution to Aux memory and you could even select between Main stack and Aux stack.  I always thought it would be nice if we could coordinate the execution of 2 different lines of code at the same time (1 on Main, 1 on Aux) and just have each one use their own stack.  I could never understand why the Main memory had to "transfer control" to Aux memory, where in my view, why not just have Main start the execution of Aux while continuing on in Main, and Aux can stop execution when it's done (or if Main signals to Aux to stop execution).  Makes sense to me, but what do I know.  I don't design processors.  I wonder if a separate processor could have been equipped on the 80-column card to provide that ability?

[JamesD]

On 8/17/2013 at 12:52 AM, Chilly Willy said:

There was a dual core 65C02 made back in the day. I've got the datasheet somewhere... need to find all that stuff one of these days.

 

From what I remember, it was two 65C02 cores that shared some pins, and had separate lines for other things (like ints and control lines).

Pretty sure it was a Rockwell microcontroller. 
They also had a microcontroller with a multiply instruction.  If you look at any of the math intensive stuff I've speed up by rewriting the MC-10 ROM, or with the CoCo 3 multiply patch, you'll see it can make a lot of difference.
Sadly, it's not on their regular 65C02.

 

[Rybags]

Off topic a bit, where's carmel?

 

Last active almost 9 years ago.

[JamesD]

6 hours ago, Rybags said:

Off topic a bit, where's carmel?

 

Last active almost 9 years ago.

Disappeared after being on the site 9 years with no goodbye and without closing the account... that's not a good sign

[Ricky Spanish]

More MHz is what's needed.

[Chilly Willy]

On 9/28/2022 at 12:41 AM, JamesD said:

Pretty sure it was a Rockwell microcontroller.

Yeah, it was a Rockwell chip. Don't remember the number offhand, but it was definitely Rockwell.

 

EDIT: The R65C00/21 and R65C29. You can find the datasheet as part of the larger book, 1985 Rockwell Data Book: https://archive.org/details/bitsavers_rockwelldaDataBook_80778847

Specifically, page 3-3 (which is pg 530 in the PDF).

 

On 9/28/2022 at 5:48 PM, Ricky Spanish said:

More MHz is what's needed.

You can probably get more MHz with an FPGA 6502 than any of the 6502 (or equivalents) on sale. At the same time, you can make it multi-core and add some extras to it.

Edited October 2, 2022 by Chilly Willy
more info

[Mclaneinc]

On 9/28/2022 at 2:32 PM, JamesD said:

Disappeared after being on the site 9 years with no goodbye and without closing the account... that's not a good sign

I sort of knew Carmel as he was a mate of Noel Daniel, programmer of Sidewinder and Thunderfox etc, I met him while reviewing Sidewinder for Atari User. He also worked for Silica Shop in London, I was a frequent visitor there as well. Carmel heard me talking about Sidewinder and introduced himself in a message. Seemed an ok guy, but he was a little on the odd side (I don't mean that in a nasty way, he was just odd). I remember him getting stick a few times for quoting facts that were not actually factual (Can't comment, done it myself by accident). He told me a few things I found a little uncomfortable (nothing sinister) and then suddenly he was gone..

 

Hope he's OK.... I've searched for him in the past and nothing turned up..

[+Spaced Cowboy]

> You can probably get more MHz with an FPGA 6502 than any of the 6502 (or equivalents) on sale. At the same time, you can make it multi-core and add some extras to it.

‘Probably’ seems a little over-cautious

 

I synthesized a 6502 core with 8K of 1-cycle RAM yesterday (for … reasons … ) targeting a bargain-basement $15 FPGA board (the Tang Nano 9K I’m using here) and got a ~40MHz clock speed (fMax) with a resource-cost of about 10% of the FPGA. Moving up to the newer-but-still-cheap-and-definitely-not-state-of-the-art 20K device will get you an fMax of ~76MHz at a resource-cost of only ~4% of the device. It’s also $21 not $15 for that better FPGA though. A really good FPGA will get you into the hundreds of MHz for a design as simple and concise as the 6502.

 

unless there’s a stash of *really* fast 6502’s out there that I’m unaware of [grin], the FPGA route is the best option for a fast 6502, unless you plan on making your own chip. One day, I will indeed fabricate my own chip, just to do it, but today is not that day…

[Chilly Willy]

I mainly said "probably" because I haven't checked on the 6502 market in years, and had no idea if anyone was making like an MCU using the 6502, but at stupid fast speeds. You can find 68xx MCUs like that still. Or 80xx MCUs. I've finally coughed up the dough for a MiSTer, and one thing I'd like to do is play around with my own FPGA cores for things.

 

Thanks for the link on efabless - that looks pretty cool.