6502 on 8080/Z80 Bus and Vice Versa

[cjs]

In this post BigEd points out a project that's using a 6502 on the RC2014 bus, which is designed for 8080 and Z80 CPUs. Myself, I use the RC6502 bus (that link includes a comparison of the two buses), but I've been thinking I'd like to build a Z80 CPU board for that so I could continue to use my existing peripherals. But of course an alternative would be to rework my RC6502-bus CPU boards (currently a 6502, but there will be 6800 and probably 6809 somewhere in the future) and peripherals all to use RC2014 bus.

The two major issues would seem to be translating between the bus protocols and dealing with I/O. For the former, obviously one translates between the Motorola R/WB signal and the two Intel /RD and /WR signals, and of course one must do the correct thing with /MREQ and /IOREQ. What else is involved there?

For I/O, one option is simply to continue using memory-mapped I/O for everything, which is kinda nice in its simplicity. But since I usually have address decode logic on the board with the CPU (my current CPU board includes ROM, RAM and a 6821 PIA, though all of those can be disabled) I've been planning to bring out some of the decode to the bus. (In the Third-party Modifications section of the link above you can see that another RC6502 user has already done this for his systems.) The same sort of idea is used on the RC2014 bus, with the USERn signals. But it occurs to me that on an RC6502 bus accesses to the I/O address space could be used to assert those select signals instead, maybe giving you an easy way of "moving" a 6502 peripheral to I/O address space when using a Z80.

These are just some random thoughts; I've not really worked out any of this in any detail. What are your ideas for the best way to go about this, or is it even a good idea at all?

[BigEd]

Not sure if this is helpful, but it seems to be that with modern components a CPU card can conveniently be, as yours is, almost an SBC, with RAM and ROM as well as the CPU. Which makes the bus more of an I/O bus anyway, no longer the main bus with everything on it.

Maybe that observation helps clarify? These days a bus need only serve to add peripheral cards.

(Of course one could also envisage a system with multiple CPU cards: the bus would not be for sharing of memory space, but for communication. In which case each CPU is a peripheral to the others.)

On second thoughts, if we allow for peripherals to perform DMA, the bus is a bit more sophisticated.

[Guus Assmann]

Hello,

Why not use a couple of 74LS646 to latch the I/O address when the Z80 outputs that.
Some not so complicated logic would enable to have the "normal memory" and I/O space coupled at the right moments.
A state machine in some programmable logic could do the I/O while the processor is on hold.

BR/
Guus

[cjs]

BigEd wrote:

Not sure if this is helpful, but it seems to be that with modern components a CPU card can conveniently be, as yours is, almost an SBC, with RAM and ROM as well as the CPU. Which makes the bus more of an I/O bus anyway, no longer the main bus with everything on it.

In fact, yes, my 6502 board is an SBC, and I often run it standalone (for example when I take it to meetings). But I also like to be able to do things such as put an AT28Cxxx EEPROM card on the bus, wired to go into a convenient unused part of the address space, program it using the "SBC," and then disable the SBC's ROM, move the EEPROM board up into the top of the address space, and reboot the SBC using that.

Another thing I might do one day is disable the clock on the SBC and instead supply it from an external board that adds single-step capability and the like.

Given the kind of flexability I want from this, it seems simpler just to think of the bus as a generic "system bus," rather than an "I/O bus," and consider the SBC's to be merely an integration of several boards. And an optional one at that: moving four jumpers turns the SBC into just a CPU board, with no clock, ROM, RAM or I/O.

[BigEd]

It's a good point: if you sometimes run with EPROM on a separate board, the inter-board bus is looking very like the usual microprocessor bus, not merely a peripheral bus.

[GARTHWILSON]

I would second Ed's recommendation of making it just an I/O bus. If you want to have something like another EEPROM, why not have half-postage-stamp-sized modules that you can plug into the SBC to load the material into RAM which is a lot faster than your 28Cxxx EEPROM (this is what SPI-10 and I2C-6 are for), or even use I/O (through the backplane) to load the EEPROM material into RAM. My workbench computer has a 72-contact edge connector, but none of those contacts go to the processor's own buses. They're all I/O (including analog and serial), power, interrupts, and clock I/O (so you could supply an external single-cycling clock if desired). However, I have found through a lot of experience that the edge connector is usually not as practical as using the many other smaller connectors (mostly pin headers) on the computer.

[BigEd]

cjs wrote:

The two major issues would seem to be translating between the bus protocols and dealing with I/O. For the former, obviously one translates between the Motorola R/WB signal and the two Intel /RD and /WR signals, and of course one must do the correct thing with /MREQ and /IOREQ. What else is involved there?

If you look at Z80 bus timings, I think you'll see that instruction fetches, on the face of it, are shorter accesses than data reads. But if you use M1 in the glue logic, to detect fetches, you get the same length of time. Overall then a design which makes best use of the clock frequency and the program memory will use M1 in this way - and that's quite different from the use of SYNC in the land of 6502. Might be worth consideration.

[cjs]

GARTHWILSON wrote:

I would second Ed's recommendation of making it just an I/O bus. If you want to have something like another EEPROM, why not have half-postage-stamp-sized modules that you can plug into the SBC...

Well, that feels as if it's going the wrong direction for a modular system designed for experimentation, since then if I want to substitute just a CPU I end up having to build a whole new SBC for it. Not to mention it involves designing a new bus.

If you look at the RC2014 and RC6502 buses (the latter being inspired by the former), I think you'll see that part of the idea behind them was that you can build and combine individual minimum-size pieces in any way you want. The SBC I'm using, which is the "Apple 1 Replica SBC", is actually a later addition to the original system, which had separate CPU, clock, ROM, RAM, etc. boards. (Each board did its own address decoding, but I am wanting to tweak things slightly to have four lines of address decoding supplied by one board on the bus.) The RC2014 idea is pretty similar, I think.

I guess what I'm asking here is, "Here are two nice modular systems for experimentation with microprocessors and peripherals, but they're separated into Motorola-style and Intel-style systems. Is there any way they can be combined, or is that not worthwhile?" The SBC part of things, to me, is really just about "Here's a convenient way to have something you can pop in a bag and take to a meetup," rather than a core part of the design.

Oh, and something I forgot to mention: another idea on the table is to be able to use this, via an interface, on existing microcomputers. So, for example, my 6800-based National/Panasonic JR-200 has an expansion connector on the back that brings out the full system bus, and various bits of address space available for it ($D800-$DFFF is checked for a ROM signature on boot, $8000-$9FFF is unused, and there's a signal on the expansion connector to unmap the internal BASIC ROM at $A000-$BFFF). So it seems like a reasonable idea to build an interface board that would connect that to an RC6502 bus and let you use those peripherals on the machine. Presumably you could do similar with, say, an MSX machine and the RC2014 bus. It would be nice to have "One bus to rule them all, one bus to find them, one bus to bring them all and in the addresses bind them."

BigEd wrote:

Overall then a design which makes best use of the clock frequency and the program memory will use M1 in this way - and that's quite different from the use of SYNC in the land of 6502. Might be worth consideration.

It's nice to know that. But I'm perfectly happy with non-optimal speed if optimizing it makes full modularity (being able to use any combination of boards, Intel-style or Motorola-style) more difficult.

[BigEd]

I would suppose that either bus will do the job: can be converted to the other bus. So perhaps the question of choosing which flavour to use comes down to the availability of useful boards in one or other flavour, and perhaps also the relative difficulty of the conversion in the one direction or the other.

Without considering the details of the busses, I'd probably go for the RC2014, just because I expect it to have the more viable ecosystem. But I say that not knowing anything about the RC6502 ecosystem!

[cjs]

BigEd wrote:

...and perhaps also the relative difficulty of the conversion in the one direction or the other.

Right. So that's basically what I'm interested in knowing; I have a general idea of what kinds of things need to be done to use Motorola peripherals on an Intel/Zilog CPU and vice versa, but I've not tried it, or even sat down to work out the details. So I'd like to hear from anybody more experienced than me who's done this, or at least thought seriously about it, about what needs to be done and what the problems are.

Or maybe it's really just Not That Difficult, there aren't really any non-obvious gotchas, and I'm just overthinking this?

[GARTHWILSON]

cjs wrote:

If you look at the RC2014 and RC6502 buses (the latter being inspired by the former), I think you'll see that part of the idea behind them was that you can build and combine individual minimum-size pieces in any way you want. The SBC I'm using, which is the "Apple 1 Replica SBC", is actually a later addition to the original system, which had separate CPU, clock, ROM, RAM, etc. boards. (Each board did its own address decoding, but I am wanting to tweak things slightly to have four lines of address decoding supplied by one board on the bus.) The RC2014 idea is pretty similar, I think.

That board is only 1MHz. Things change as you get up to 10, 14, 20MHz and beyond. (Actually, the faster parts' outputs' rise & fall times is the main issue, meaning you could even wind up with problems running these parts at a slow clock speed. The clock line is the most important one to keep clean.) It could still be done if you keep a pretty limited size and number of boards so the maximum overall connection length is not very long; but note that although commercially made backplanes go far above that speed, their design involves a lot of transmission-line theory which is not trivial. You can no longer just connect things and expect it all to work. We want you to be successful.

Quote:

I guess what I'm asking here is, "Here are two nice modular systems for experimentation with microprocessors and peripherals, but they're separated into Motorola-style and Intel-style systems. Is there any way they can be combined, or is that not worthwhile?"

I ran into that when I was making design choices for the automated test equipment at work around 1990. I chose STD Bus ("STD" stands for "simple to design," not "standard") partly for its low cost; but there were boards made for one system, and boards made for the other system, and you had to choose one or the other. I don't remember the details anymore. Here's one of the sets of the finished result:






The 65c02 CPU ran at 2MHz. Things were spec'ed to max out at something like 4MHz. I used several off-the-shelf boards, and designed several more. The backplane was something like 6" long. The boards to the left of it ran on I/O from the STD-Bus boards, and were not actually on STD bus. I know the company used this system for at least eight years after I built & programmed it.

Quote:

GARTHWILSON wrote:

I would second Ed's recommendation of making it just an I/O bus. If you want to have something like another EEPROM, why not have half-postage-stamp-sized modules that you can plug into the SBC...

Well, that feels as if it's going the wrong direction for a modular system designed for experimentation, since then if I want to substitute just a CPU I end up having to build a whole new SBC for it. Not to mention it involves designing a new bus.

What I advocate now is keeping the SBC smallish, with only memory and basic I/O onboard, and don't run the processor's own buses out on a backplane—not even buffered. This makes it much easier to get maximum performance. Then take advantage of the hundreds (or maybe thousands) of SPI, I²C, Microwire, and similar synchronous-serial chips on the market. Last I saw data, there were SPI devices that could run at 160Mbps, or about 20MB per second, full duplex. (My information might be outdated though. SPI has no specified speed limit.) Processor type won't matter; so you can use the same accessory boards with any processor. For external devices, there's also our super flexible and hobbyist-friendly 65SIB serial interface bus (named for the forum, not particular to the processor). SPI-10 and I2C-6 are intended more for the tiny modules you'd plug onto ports on the SBC, similar to inserting a camera card, but more hobbyist-friendly. I have a couple of them on the front page of my site.

The things that absolutely have to be on the processor's own buses are few.

[cjs]

GARTHWILSON wrote:

That board is only 1MHz. Things change as you get up to 10, 14, 20MHz and beyond.

Indeed they do! But I am struggling to see the relevance. Such speeds seem to me not only unessential for a set of experimental building blocks, but probably ill-advised. (Not to mention greatly restricting what components you can play with. I probably have a couple of dozen or more different CPU and peripheral chips in my parts bin right now, and I would be surprised if a single one of them ran at even 5 MHz, except for the Z80s.)

I think you may have a very different conception of the purpose of this system than I do. My main aim is to share peripherals amongst as many "machines" as possible, and experiment with different CPUs. So, for example:

Quote:

What I advocate now is keeping the SBC smallish, with only memory and basic I/O onboard.

I want to go much smaller than that: I want to be able to do boards with only a processor, or at least, only the processor and the bare minimum of supporting circuitry I need. That means no clock (if possible), no address decoding, no ROM or RAM, and certainly no I/O. Having to build all that stuff up every time I want to try a new processor would slow things down quite a bit, I think.

So the real question here is, I think, given I've got an RC6502 backplane with boards in it providing RAM, ROM, address decoding, a 6850 ACIA or similar, a couple of 6821 PIAs, probably some timers (perhaps integrated with the PIAs as in 6822s), and perhaps the system clock, what do I need to do to pull the 6502/6800/6802/6809/6309/whatever and plop in an 8085 or Z80 instead? What do I need to do to put in an Intel-style peripheral, such as an i8255? Or does it perhaps make sense to move to an RC2014 bus and do everything the other way around?

[GARTHWILSON]

cjs wrote:

GARTHWILSON wrote:

That board is only 1MHz. Things change as you get up to 10, 14, 20MHz and beyond.

Indeed they do! But I am struggling to see the relevance. Such speeds seem to me not only unessential for a set of experimental building blocks, but probably ill-advised. (Not to mention greatly restricting what components you can play with. I probably have a couple of dozen or more different CPU and peripheral chips in my parts bin right now, and I would be surprised if a single one of them ran at even 5 MHz, except for the Z80s.)

That's a good thing, as long as that's really your intention. For my own uses, there's no threshold where below it is not fast enough and above it is; it's just that more speed opens up more possibilities of what I can do with it. My workbench computer with 4MHz parts started having problems at just a hair over 7MHz as I slowly moved the clock speed up; so for some margin, I backed it down to 5MHz and that's where I run it. For probably 20 years or more, I've had plans for a huge upgrade with the 65816, at least three times the clock speed, at least 128 times as much RAM, more I/O, more of everything. But over the years, I've found ways to augment what I have, which keeps putting off the need for "the next one." (I'm not going to build the "next one" and have it go only 5MHz though.)

I have about 75 R65C02's and twice that many R65C22's, all rated for 2MHz, plus probably that many more again available to me, plus a lot of EPROMs, SRAMs, and 74HC logic ICs, and 100 LCDs, for which I have a pipe dream of being able to make an SBC for education, and have my Forth pre-installed. (I know everybody and their dog makes an SBC these days, but none have a display on them, none have Forth available upon power-up, and most have a lot of levels of software, at least in the bundled development system, which are beyond the ability of a relative beginner to understand. They're training paint-by-number people! Where are our engineers going to come from when the current crop is retired??)

Quote:

Quote:

What I advocate now is keeping the SBC smallish, with only memory and basic I/O onboard.

I want to go much smaller than that: I want to be able to do boards with only a processor, or at least, only the processor and the bare minimum of supporting circuitry I need. That means no clock (if possible), no address decoding, no ROM or RAM, and certainly no I/O. Having to build all that stuff up every time I want to try a new processor would slow things down quite a bit, I think.

It sounds you're down to individual ICs, with no board. The processor board should probably have at least the clock and reset circuits on it.

Quote:

So the real question here is, I think, given I've got an RC6502 backplane with boards in it providing RAM, ROM, address decoding, a 6850 ACIA or similar

How 'bout at least a 65c51 (although you might want to go for an older one, not the WDC one that has the bug). The 6850 doesn't even have a baud-rate generator onboard. Many here would advocate for a different family of ACIA/UART altogether. One that I like is the SPI-interfaced 14-pin MAX3100.

Quote:

, a couple of 6821 PIAs, probably some timers

Let me recommend the 65C22. Besides having the timers and serial port onboard, there are certain things the '22 is much more agile at than the '21.

Quote:

what do I need to do to pull the 6502/6800/6802/6809/6309/whatever and plop in an 8085 or Z80 instead? What do I need to do to put in an Intel-style peripheral, such as an i8255? Or does it perhaps make sense to move to an RC2014 bus and do everything the other way around?

It may make sense to devise a backplane that has the signals for all of them, and have jumper options on the non-CPU boards for dealing with the different CPUs' bus systems.

[cjs]

GARTHWILSON wrote:

For my own uses, there's no threshold where below it is not fast enough and above it is; it's just that more speed opens up more possibilities of what I can do with it. My workbench computer with 4MHz parts started having problems at just a hair over 7MHz as I slowly moved the clock speed up....

Yeah, you've got a somewhat different aim with your small systems hacking than I do. For me, it's mostly about learning what I can do within certain limits, as well as just the fun of hardware hacking. If I had an application where I needed any real speed, well, for less than I'm spending on '80s chips alone I could get an SBC with an 80 MHz or faster ARM on it.

Quote:

I have about 75 R65C02's....

Or so you think. How many of them are relabeled NMOS? :-)

Quote:

...for which I have a pipe dream of being able to make an SBC for education, and have my Forth pre-installed. (I know everybody and their dog makes an SBC these days, but none have a display on them, none have Forth available upon power-up, and most have a lot of levels of software, at least in the bundled development system, which are beyond the ability of a relative beginner to understand. They're training paint-by-number people! Where are our engineers going to come from when the current crop is retired??)

Let me lend my support to that idea. I think it's a great one! And with decent software it could also well be a fine replacement for Arduinos and the like; there's no reason that things like EPROM programmers shouldn't be made with a system like yours, rather than an ATmega-based Arduino.

I think a Forth system that you can actually program on the system itself is a much better training and hacking tool than the Arduino world of GCC and an IDE that runs only on a host machine with a thousand times the power and leaves you programming in C against massive libraries written by someone else. Of course one wants to have some sort of host capabilities to let you easily have different projects, collect up your work in Git, use a good editor, and so on, but given a basic way of moving chunks of code (in the Forth case, screens I guess) back and forth between the two, I think developers would be set.

Quote:

It sounds you're down to individual ICs, with no board. The processor board should probably have at least the clock and reset circuits on it.

Pretty close, in many cases, yeah. For 6xxx systems I don't see any reason not to use a common clock, though, but I'm not sure about the Intel-style systems where the CPU clock is basically several times the "system" clock. Some peripheral chips, such as the 6821 and 6522 usually take input from the system clock (pin 25, called "E" on the 6821 and "Φ2" on the 6522) which looks to me just like another enable pin that lets you easily qualify your enable based on the system clock, as one typically wants to do in Motorola-style systems, but I'm not sure how to translate that.

As for reset circuits, I pretty much need just one anywhere, right? The RC2014 backplanes often include reset functionality, and I'm thinking it would make sense to hack that on to my existing RC6502 backplane, too, once I start using it with something other than my 6502 board that already has a reset button on it.

Quote:

How 'bout at least a 65c51 (although you might want to go for an older one, not the WDC one that has the bug). The 6850 doesn't even have a baud-rate generator onboard. Many here would advocate for a different family of ACIA/UART altogether. One that I like is the SPI-interfaced 14-pin MAX3100.

Actually, I do have a couple of RC65C51P2 chips in my parts bin, along side nine MC68B50CP chips. I'd not realized that the '50 doesn't have the baud rate generator, which is a mild annoyance, but I do have some 1.8432 MHz oscillators coming (as well as crystals at the same frequency), so even if I don't want to cons up a divider circuit I can still run them at 115.2 kbps just by running the oscillator directly into the pin, right? I know that there are much better UARTs out there, but I'm not feeling at the moment like I can't get along with what I've got. (Except for some 8251s and 8253s on order specifically for my MSX machines.)

But all that said, yeah, once I get going if I'm not happy with my UARTs, there's nothing stopping me from building another board with different UARTs. In fact, that's kinda the whole point of the system!

Quote:

Let me recommend the 65C22. Besides having the timers and serial port onboard, there are certain things the '22 is much more agile at than the '21.

Yup, I've got three 6522s alongside the nine 6821s in my parts bin. I certainly like the former better, but I think that there are probably plenty of things where the latter will do. In fact, I'd like to be using 6526s all over the place, but those tend to be expensive these days because so many C64 owners want them.

Quote:

It may make sense to devise a backplane that has the signals for all of them, and have jumper options on the non-CPU boards for dealing with the different CPUs' bus systems.

That's a thought. Though again, it's a new bus design rather than re-using an existing one (and any design work that's been done for CPUs and peripherals on that bus), and it feels like I might be duplicating a lot of work across boards to have the conversion circuitry on the peripheral boards rather than doing it in one place on the CPU board. (Assuming it can be done just on the CPU boards that need it.)

[BigEd]

(My feeling is that connecting a peripheral to an opposite-family bus is indeed not a big challenge: if you don't have to worry about DMA or any kind of arbitration, and you don't have a great mismatch of speeds.)