Any interest in doing this?

_________________
Bill

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

For some reason, I'm getting some deja vu on this. I'm sure there have been discussions in the past around here on that topic.

Garth mentions SPI and 65SIB as possibilities. My interests are more along the line of a parallel I/O bus that could accept plug-in cards a la ISA, but hopefully without ISA's problems. Obviously, the bus would have to be buffered and clocked independently of the MPU so different types of cards could work together. Issues such as I/O addresses and interrupt sharing would have to be resolved and in an ideal world, cards could have ROMs to provide boot-time driver support.

Every so often I have thoughts about it but nothing of substance has materialized for me.

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

Here's a previous discussion which also mentions the venerable(?) S50 standard:
viewtopic.php?t=666

If you are talking backplane, I had some interest in this but it was a long time ago. I think backplane style busses are more a thing of the past. Everything's integrated onto the same board these days, with different boards connected via high-speed networks (hi-speed serial). With programmable logic it's possible to put a whole system on a chip, so what's left for the backplane ?
For a board to board serial interconnection I've thought of using DVI connections.

For internal-to-the-chip programmable logic busses a common free one is the WISHBONE bus. I use the WISHBONE bus for my FPGA cores.

_________________
http://www.finitron.ca

Actually, I was thinking of something fairly simple. Something that would promote quick hardware development and keep the programming to as simple a level as possible.

Here is the dilemma I have that I am trying to solve. I am constantly building up computers for specific tasks. A lot of them are quite temporary and are used for some experiment or amusement, then set aside. I must have 15 of them lying around. Most I'll never use again, and a lot of them have parts scavenged off them. I was thinking that a simple parallel back-plane would make this a far more efficient process. That way I could build butt-simple re-usable modules and configure the machine for whatever purpose I need.

Incredible speed was not my goal, besides there are other available means to skin that cat. If it could have a bandwidth of 2-4mHz, that would be fine. So, to allow for simple hardware and software just electrically buffer the CPU signals, add a few power lines, a few clock lines a couple of derived signals and a byte or two of uncommitted auxiliary lines that could be used for more advanced stuff like interrupt registers, 65SIB or whatever the user wanted. Maybe 60 lines in total. We could even dedicate 2 lines for I2C. However, in most cases I just want to cobble together something as quickly as possible, so sending out 8 bits of data using a simple STA instruction is far more attractive than writing a more complex driver subroutine or include a previously written one which may require considerable additional coding to use. I know such routines are not avoidable in all circumstances, but it would be nice to only go there when you have to and be able to abstain when you can.

The idea of approaching the forum is that if we can hash out something a lot of us can use, then we'd be able to share hardware and software designs and maintain a sort of library, thus increasing efficiency further.

_________________
Bill

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

I agree.

Here is a first cut of this for discussion's sake. I gave no thought to the actual pin-function assignment at this point, it may or may not be of importance - another discussion item. The first order of business would be, do I have the right signals?

The AUX signals are all user defined, but I'd like to preempt (for lack of a better word) 6 of them for serial I/O. In other words, use up AUX0-AUX9 for user defined needs before considering using AUX10-AUX15.

I left out the mode select lines for the 65C816 as I assume they would be taken care of on the CPU card.

OCA is a signal for Off CPU Address for those cases where the user wants to put addressable devices on the CPU card. It would control the enable of the data-bus buffer.

_________________
Bill

As I earlier posted, I really haven't given this much thought. However, I am of the opinion that an expansion bus should be fully isolated and buffered from the MPU's buses and that the isolation/buffer hardware should mediate all transfers. Incidentally, bringing signals such as /IRQ, RDY, VDA, etc., out to the bus is still effectively taking the MPU's buses off-board. The expansion bus' "slots" shouldn't know about signals like that, and should be driving an interrupt encoder rather than directly accessing /IRQ or /NMI. Signals such as BE, RDY and VDA are MPU bus management signals, and should be confined to the mainboard circuitry only.

Look at the PCI bus for answers. It doesn't have to be as complicated as PCI, but should try to adopt some PCI features. This may be a good application for some 65C22s to act as bus drivers.

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

BTW, shouldn't this topic be in the hardware section of the forum?

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

Hi BDD,

This goes a bit against what I'm after. Such a bus would need a lot of additional programming to use and that kind of beats the primary intent - to define something that makes it real simple to make cards for and to keep the programming as light as possible.

As far as interrupt control, that's something the auxiliary lines could be used for. A user that requires more sophistication for an interrupt driven system can use those lines so that the interrupting device can place a code into an interrupt register on the CPU card when it asserts /IRQ or /NMI. The first part of the interrupt routine would be to check that register. This would allow 'smart' devices the opportunity to define multiple interrupts. Or they could be used to facilitate 'slot' based interrupts or something even more sophisticated.

All that said, I can see the attraction of an arbitrated asynchronous bus for peripherals. Especially in systems where it is desirable for the CPU to run as fast as possible. So maybe there is room here for two bus structures. One that is simple, flexible and a bit unsophisticated, another more performance oriented that separates the CPU and memory on a faster, synchronous bus supporting maximum processor speed and multiple concurrent processes while keeping the peripherals on an arbitrated asynchronous bus that is more rigorously defined.

_________________
Bill

I guess the overwhelming apathy speaks volumes here.

Oh, well.

Personally, I have decided on a 44-pin bus and have put it into action. Since I don't use the 65C816 for anything, I was able to cut back a wee bit.

Not intending to beat the crap out of the PC market or anything, I've come to grips with simple and effective solution.

So, as you were.

Thanks for all the input folks...!

_________________
Bill

Sounds good to me...

_________________
Bill

Just my 5cents. I use a minimal IO Bus with only 32 signals


I use single Row DIN41612 connectors. I never used other signals for my "perihperals". Everthing more complex is on the main-board. Currently the bus runs with 4MHz and the CPU clock is the same, but I'm investigating to have the CPU clocked with at least 8MHz and have the IO Bus run at half the speed.

Cheers

Peter

Well, 5 cents is 3 cents more than most! I see your a fan of the venerable PDP-11.

My minimal bus is similar to yours. I have 8 block select lines instead of 4, one more address, 4 spares (for future consideration or SPI/I2C) and a couple of extra power lines. I also brought out the SYNC and RDY signals in just in case. I use the 2x22 .156" card edge connector.

Here is the pin out I'm using:

_________________
Bill