6502.org

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?

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.

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

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.

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.

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.

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."
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.

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!

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?

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

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.
Or so you think. How many of them are relabeled NMOS? :-)
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.
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.
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!
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.
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.)

(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.)