Two 6502 System

[Scott Robison]

Idea for this hypothetical dual 6502 machine.

64K of private RAM for CPU 0

64K of private RAM for CPU 1

16M of shared RAM (256 64K banks)

16M of shared ROM (256 64K banks)

ZP register to control which page of shared RAM is seen per CPU

ZP register to control which page of shared ROM is seen per CPU

ZP register to control the size of private RAM / shared ROM windows

8 values of private RAM window would allow sizes (starting low) of 512B, 1K, 2K, 4K, 8K, 16K, 32K, 63.5K (so the top 512B of address space is always "ROM")

8 values of shared ROM window would allow sizes (starting high) of 512B, 1K, 2K, 4K, 8K, 16K, 32K, 63.5K (so the bottom 512B of address space is always private RAM)

The two remaining bits could be used to enable / disable each of the windows if one really wanted to be extra cute, but more than likely you just leave them reserved or unused.

Some rule would be defined to control which of private RAM / ROM takes precedence if incompatible windows were chosen.

So each CPU can control how much address space is used for each purpose in a relatively straightforward way.

There is no IO in that map. Borrowing a page from X16, I would reserve a single page of address space for IO. In my model, page FF is always ROM bank 0 (effectively; could just copy the same page to all ROM banks so that it never matters what ROM bank is active) and would include the ROM vectors and support code to handle RESET/IRQ/NMI vectors. page FE would always be IO space.

So the minimum private RAM size of 512 covers ZP and stack. The minimum shared ROM space covers IO and vectors.

Okay, someone go build it! ?

Note / disclaimer: This is just a thought exercise, not a serious suggestion of how to design such a machine. Just riffing on the "let each CPU do what it wants" idea and dialing the amount of RAM and ROM up to 11 (at least 11 relative to the 6502 architecture).

[BruceMcF]

1 hour ago, Scott Robison said:

...



Some rule would be defined to control which of private RAM / ROM takes precedence if incompatible windows were chosen.



So each CPU can control how much address space is used for each purpose in a relatively straightforward way.



There is no IO in that map. Borrowing a page from X16, I would reserve a single page of address space for IO. In my model, page FF is always ROM bank 0 (effectively; could just copy the same page to all ROM banks so that it never matters what ROM bank is active) and would include the ROM vectors and support code to handle RESET/IRQ/NMI vectors. page FE would always be IO space.



So the minimum private RAM size of 512 covers ZP and stack. The minimum shared ROM space covers IO and vectors.



Okay, someone go build it! ?



Note / disclaimer: This is just a thought exercise, not a serious suggestion of how to design such a machine. Just riffing on the "let each CPU do what it wants" idea and dialing the amount of RAM and ROM up to 11 (at least 11 relative to the 6502 architecture).

In the asymmetric version, I'm going to be more parsimonious with memory: 1 32K RAM and 4 512K RAM chips, and a 512K FlashROM.



CPU#1 / CPU#2 divided into 16K slots:

$0000-$3FFF Local RAM. ZP at $00xx, Stack at $01xx, Device page at $03xx

$4000-$7FFF Local RAM / Common RAM1

$8000-$BFFF Common RAM2

$C000-$FFFF ROM



3bits in one memory byte controls the base within 128K of ROM

5bits in the same memory byte controls the RAM1 base within 512K of RAM

1bits in the second memory byte controls whether Local or Common RAM1 are selected.

5bits in a second memory byte controls the RAM2 base within the 512K of RAM



Also CPU#1:

One memory control byte provides the high two bits of the external RAM for CPU#1 and CPU#2 and ROM for CPU#1. One bit controls ROM for CPU#2, which has the high bit tied high from ROM segment select.

When accessing ROM, or when accessing RAM when the RAM segments are the same, inverted clocks allow the use of "first come, first served" ... if selecting a chip the other CPU has selected in the previous half cycle, that CPU is suspended with RDY until the deselect and that CPU's rising clock, so for that CPU, the first clock phase will have just been stretched one clock cycle.

 

[Starsickle]

This would be better off like a Dual Core computer but with entire chips. XD Two 6502s, a ROM controller acting as the thread/task manager (HAAAHAHAHAHA) and for the awesome power of...6MHz.

[BruceMcF]

1 hour ago, Starsickle said:

This would be better off like a Dual Core computer but with entire chips. XD Two 6502s, a ROM controller acting as the thread/task manager (HAAAHAHAHAHA) and for the awesome power of...6MHz.

In what way?

[Starsickle]

On 8/2/2021 at 5:27 PM, BruceMcF said:

In what way?

Well, It kinda fits the way we have our computers right now, doesn't it? There's an Arithmetic CPU and a whole other computer inside our computer doing more specific sorts of computations. I'm not sure how good the 6502 would be at that, but I don't see why you could have it designed as OP. In my Morning-no-coffee head, I'd say the bottleneck would still be the rate of synchronization between the two for tasks. I'm not sure what it'd be really good for in the world of 8 bits...

The previous discussion really centered around arranging the electrics of the memory spaces, but my gut tells me that anything that creates more complexity invites errors.

Don't want to be negative about the discussion though - the other posters have brought up some challenges in design, and I'm trying to look at it from other angles.

[BruceMcF]

4 hours ago, Starsickle said:

Well, It kinda fits the way we have our computers right now, doesn't it? There's an Arithmetic CPU and a whole other computer inside our computer doing more specific sorts of computations. I'm not sure how good the 6502 would be at that, but I don't see why you could have it designed as OP. In my Morning-no-coffee head, I'd say the bottleneck would still be the rate of synchronization between the two for tasks. I'm not sure what it'd be really good for in the world of 8 bits...

It seems like one of the things we know secondary general purpose CPUs were good for in the world of 8bit, playing audio, gives some idea about how to avoiding creating a bottleneck in whatever synchronization is necessary between the tasks. The point there was freeing up the main CPU from the necessity of constantly interrupting it's program execution to do another step in playing an audio sequence, having the secondary CPU keep the audio playing while the main CPU only has to make sure to keep it fed with the data as to what to play next.

[codewar65]

This thread should be in the non-cx16 retro channel, but:

I've been thinking of tinkering with two 65c02s to build a breadboard machine. The first would be the main system, the secondary would handle screen and keyboard (ala terminal). They'd communicate through 6522's. The secondary would just take VT52 or VT100 style codes for video as input and send keyboard / escape code response codes back as output. That would free up the main CPU to run full bore, while the terminal CPU could buffer and state-machine the ANSI codes and handle keyboard voodoo while in vblank/hblank when driving video.

[Scott Robison]

28 minutes ago, codewar65 said:

This thread should be in the non-cx16 retro channel, but:

I've been thinking of tinkering with two 65c02s to build a breadboard machine. The first would be the main system, the secondary would handle screen and keyboard (ala terminal). They'd communicate through 6522's. The secondary would just take VT52 or VT100 style codes for video as input and send keyboard / escape code response codes back as output. That would free up the main CPU to run full bore, while the terminal CPU could buffer and state-machine the ANSI codes and handle keyboard voodoo while in vblank/hblank when driving video.

I was thinking of something similar a couple days ago. Except I'm not a hardware guy typically. So I bought the Ben Eater kits and just starting putting them together tonight to try to get a handle on some of this kind of stuff. Not the exact split, but the separate CPUs with their own RAM and communicating through VIAs.

Good luck!

[codewar65]

14 minutes ago, Scott Robison said:

I was thinking of something similar a couple days ago. Except I'm not a hardware guy typically. So I bought the Ben Eater kits and just starting putting them together tonight to try to get a handle on some of this kind of stuff. Not the exact split, but the separate CPUs with their own RAM and communicating through VIAs.



Good luck!

I'm old school and love old dumb terminals! I was thinking of building a 6502 based VT100 terminal VERA. haha

I was actually thinking of grabbing Ben's kit as well, but want to get a better breadboard setup.

And writing my own terminal, I could 'add' my own special codes to redefine the character glyphs, play sound, sprites, etc. Even upload 65c02 code via ANSI to run as a background process and report back on a separate VIA port with results.

 

[Scott Robison]

40 minutes ago, codewar65 said:

I'm old school and love old dumb terminals! I was thinking of building a 6502 based VT100 terminal VERA. haha

I was actually thinking of grabbing Ben's kit as well, but want to get a better breadboard setup.

And writing my own terminal, I could 'add' my own special codes to redefine the character glyphs, play sound, sprites, etc. Even upload 65c02 code via ANSI to run as a background process and report back on a separate VIA port with results.

It's good that you have an actual use for it, and nothing wrong with dumb terminals. In my case it was just a solution in search of a problem. ?