Here's the scenario.

I'm not above some hardware hacking, but I'm really more interested in the software side of the 65XX processor family. I'd like to have a shot at interfacing some newer I/O devices, but wouldn't mind helping put in more of the "sweat" on the software side of this too.

Plinking around with solderless breadboards is all right, but this has limits as far as long-term stability and the cost of significant real estate.

Then there is the I/O issue itself. Building SBCs has a lot going for it, but significant design changes mean starting from scratch. A multicard "bench" design is an alternative, but what do you use? KIM-1 bus? Some expanded version (multiplexed extra address bits or data bits for a 16-bit path with '816s)? Make up something and pick maybe STD Bus cards and modify that slightly?

Well geeze. I have a basement full of old Baby-AT cases with functional power supplies and usable drive bays. And I think I have found a source for a limited number of 8-bit ISA passive backplanes. These are 1/4 XT size, 8 8-bit slots, XT/AT P/S connectors... and ought to plop right into one of my old PC boxes.

Proto-boards for ISA aren't common or cheap now, but Jameco and JDR Microdevices have a couple in the under $30 range. I even found a wacky idea at:

http://members.tripod.com/~bbright/information/homebrewisa.htm ... and I am considering it.

I figure wire-wrap would be the way to go building a 65XX board on some sort of ISA proto-board.

I've seen Circuit Cellar articles suggesting cheap old ethernet ISA cards are easy to interface to, and others here keep saying they'd want VGA. Frankly I have plenty of old ISA cards that might be good candidates (even an old composite video card) and I have little trouble getting my hands on more. I haven't dug into it too deeply, but some of these cards ought to be easy to use in at least non-DMA modes.

So let the flames begin. Don't hold back. Tell me that I'm nuts. If you can, let me know why though. This sure seems easy to me... too easy?

Bob Riemersma

I believe Wally Daniels has done this successfully. You might want to E-mail him directly as I don't think he checks in here on the forum very often. (I'm not volunteering his services, but it might be worth seeing what he has to say.)

Do you have adequate info on any of these ISA-bus cards to program drivers for them though? That might be the only reason to really make it full ISA bus. Otherwise, you could use parts of the motherboards you have for the mechanical connections but implement your own set of signals and pinouts. I would just say however that if you expect to run the higher clock speeds (5-20MHz), don't try putting the actual processor's bus out on the board-edge connectors. I don't think ISA can go nearly that fast anyway; but regardless of the interface method, the capacitive loading and long lines will really put a lid on your speed if the interface bus is directly connected to the processor's own bus, unless you want to go for controlled-impedance lines, terminations, and things that are not suitable for hobby building.

As for expansion buses in general, there has been quite a bit of discussion about it on all three discussion groups that 6502.org gives the links to if you click on "Discussion Groups" from the opening page. I'm sure anyone interested could benefit from taking a few evenings to read through the archives. It usually comes up in subjects like "If we made a 6502 computer you guys would all like to use, what would it have?"

Garth

interfacing isa bus, at least 8bit wide is really simple, you just need to make few signals like ior, iow, memr, memw and basicaly this is it. you wont be able to use dma mode, but still - for ethernet cards, old vga's and multi io cards this is enought. but to use it fully you may need 65c816, or you simply run out of memory in your system...
64k is not enought...

candle

Thanks for these answers.



Garth, I scanned the last couple of months on the Yahoo group and it looked pretty chaotic. Maybe I need to be more patient, but the ads frustrate me and I really get burnt out on the clumsy, erratic, and chaotic over-quoting of previous messages that seems endemic to Yahoo's groups in general. Even with broadband access it can take hours to glean the smallest kernel of information. But I'll give it another try rather than solicit repostings of stale information everyone here is bored with.

I haven't found a lot here either, but this forum is a lot easier to work with so I think I have exhausted it already. I might try Wally Daniels too, thanks for the suggestion.

To clarify a bit:

I'm not really trying to make a "6502 PC" so much as I'd like to leverage some of the stuff I have on hand to make a more robust software testing platform. When it comes to adding "heavier" I/O than serial or parallel lines, I'd like to see whether or not I might be able to find a way to use fairly generic 8-bit ISA cards. Much cheaper than buying individual chips and building up something like an ethernet interface: my junk box runneth over.



I wouldn't even have started thinking this way if I hadn't seen a few articles on using old ISA cards with 8051's and other 8-bit uPs. In general however I am less interested in creating a full ISA 65XX PC than I am (1.) exploiting a $5, 8-slot backplane I can easily power in a cabinet & P/S I have on hand, and (2.) using just enough lines on it to be compatible with older simple 8-bit ISA cards. In other words I'm not looking at creating a 65XX co-processor card for PCs, just recycling a passive backplane, cabinet, and P/S (and maybe some ISA I/O cards).



You're right, I'd probably need to buffer the CPU card anyway unless I used a 2 or 3 slot backplane and was careful about what I plugged into it. The 8-slot ones I'm looking at were not chosen because I want 8 slots, but wire-wrapping means "thick" cards and in many cases I'll only be using every other slot. Still, long lines are scary. I believe that 5Mhz is perfectly feasible, maybe even 10. Going further would be pushing it, but I'm targeting 1 to 5 Mhz as I map this out in my mind anyway. I'm not trying to build a "screamer" anyway.



Heh. 64K is never enough. But my goal would be to handle custom CPU cards of almost any memory configuration from a 65XX with 8K RAM and 8K ROM, to 65XX with homebrew bank-switching, to a 65c816 with more than I might ever need. In most cases the memory would be on board the CPU card anyway, not on a separate ISA card.

The idea is to be able to play with different CPU cards for different purposes, using ISA I/O cards where I choose and pulling them out of the chassis when I don't need them. Even "single board" designs could just be plugged in there for the cabinet and P/S I gain out of it. This would be a testbed, not some prototype of a consumer product design.

It all hinges on the ISA backplanes though. I'm waiting to see if I can still get hold of them. They were surplus units, probably pull-outs, but supposedly in untested but clean and un-nicked condition.

And I am open to alternative backplane ideas too, this just looked cheap and easy. I'll do some more research of existing efforts and discussions though.

Thank you both.

Bob Riemersma

I agree. In the Amstrad CPC6128 (128K RAM), they used a Z80 (like the 6502, it can only access 64k of RAM). They set its hardware up somehow so it could switch between several banks, all made from 16k (from what I can remember). This 'switching' was controlled by a memory resident binary that was loaded into memory through BASIC if the programmer needed it. This could be used to create an almost unlimited ammount of addressable memory, at the cost of speed however.

Perhaps that could overcome the 64k limit?

_________________
There is no expedient to which a man will not go to avoid the labour of thinking.

same technique was used in atari 130xe, and later extensions - 6520 port b was used as bank selector, and additional memory appeared at 0x4000 (16kb banks) this is solution if you really don't have any way getting 65c816... :<

Sure, bank-switching is a typical way to add to the address space of 8-bit processors. The C64 did something similar on a small scale.

There are also "shadowing" functions one can implement. I'm looking at a design with 64K of SRAM and 8K of EEPROM. The I/O space would occupy about 1K up at the very top of the address space. All but 128 bytes at the VERY top to hold reset and interrupt vectors with a bit left over.

At reset, the EEPROM would "live" at the top 8K (except for the 1K minus 128 bytes I/O space at the very top). This gives my 7K + 128 bytes for "boot ROM." In this reset-mode the 6502 would run from EEPROM, but be able to write-through itself to load an OS or free-standing application into the whole of RAM (except for the 1K - 128 bytes of I/O space). After loading the new program, the EEPROM program would transfer control to code somewhere below the top 8K into a loaded bit of code. This code would "flip to run-mode" hiding the EEPROM and making the upper RAM fully read/write, then transfer control to the loaded program.

This still limits me to 64K, but in run-mode I get a full, linear 63K of RAM to work with, plus the 128 bytes at the very top (now RAM) for vectors plus some misc. data. The 1K - 128 bytes of I/O space woulds till be in place of course. I'll have to look at the address decoding logic for this - I don't really want to have to program a GAL or something for this if it can be avoided. The scheme might be too complex for just a couple of 7400 chips though.

To get more than 63K of RAM I might consider a run-mode banking scheme to swap chunks of additional RAM someplace, probably in 16K hunks. Much larger chops up the 64K space too much. Much smaller means I need too many "banking" bits to control things.

All this becomes so much simpler using an '816 though.

Oh, and the shadowing technique goes further...

Since in run-mode the upper 8K of RAM (minus the I/O chip space) is really running code that'd normally be in ROM anyway... you can locate video RAM there for designs supporting memory-mapped video. The program code would be read from these RAM locations, and programs would write to these locations (and actually write to video RAM) to display things on the screen. As long as you don't need to READ the video RAM you need do little more to gain this additional space within your 64K address space.

If you need read/write video RAM you're back to bank switching techniques again of course.

> I'll have to look at the address decoding logic for this - I don't really
> want to have to program a GAL or something for this if it can be
> avoided. The scheme might be too complex for just a couple of 7400
> chips though.

The 74AC521 and '688 (same thing) are 8-bit identity comparators with an E\ input as well, and have a maximum propagation delay of 8.5ns. You could have 64K of RAM minus 256 bytes for I/O rather simply this way:

connect the high 8 address bits (A8-A15) to the 521's A inputs
connect the 521's B inputs to power and ground to reflect what page you want the I/O in (probably FE00-FEFF)
connect the 521's E\ input to ground
connect the 521's Eq\ output to the CS\ input of all of the I/O ICs (like 65c22's)
connect the I/O ICs' CS (not the CS\) inputs to various address bits starting from A7 and going down.
. . (For 65c22's you'll need to leave A0-A3 for the RS inputs.)
For RAM, connect the 521's Eq\ output to one input of a 2-input NAND, and
connect the NAND's other input to phase 2.
The NAND's output goes to CS\ of the RAM.

The whole thing takes only one 74AC521 (or 688) and a quarter of a 74AC00 quad NAND gate. From phase 2 to the RAM's CS\, there's a max propagation delay of 8ns. Remember that the 65c22s' CS\ inputs must be valid before the rising edge of phase 2, and that the RAM's CS\ input must go true after the address and R/W are valid, and must go false before these go invalid; so you can't gate the entire '521 or '688 with an inverted phase 2 at the E\ input. (Doing so would put more prop delay between phase 2 and the RAM CS\ input anyway, slowing things down.)

You will have to load the boot-up code into the top of RAM (possibly with a PIC) before letting the processor loose; but although this loader circuitry will slightly increase the capacitive bus loading, it won't add more logic levels to the address decoding of the CPU once it's started.

Garth

Thanks Garth, valuable input.

One factor that seems important today is keeping the parts count down even if it means a slight cost penalty. This has always been beneficial in terms of board size, board interconnections, reliability (mostly due to those interconnections), and for anything mass-produced it is just cheaper to make something with fewer discrete pieces and parts. But the availability and low cost of "smart" components like PICs - or large SRAMs, EEPROMS, fancy 7400 family parts and the like gives us more leverage today than 25 years ago.

I'm still adjusting my thinking from 74x138s and 74x154s to things like 74x521s or MMUs.

Bob Riemersma

I received a few of those 8-slot, 8-bit ISA powered backplanes today. These should easily drop into 8-slot Baby AT cabinets.

For the most part this is just a row of 8 XT slot connectors, an XT/AT power connector with supplies bussed to each slot, and a few small ceramic bypass capacitors for the power lines on the backplane board. Ground planes both top and bottom.

One unexpected surprise is a crystal and an Intel D8264A clock generator/driver at 14.3Mhz bussed to the OSC pin of each slot. This can be ignored/disabled or divided down by 12 or less using a TTL divider chip as my CPU clock. There are also 4 spare 20-pin narrow DIP positions on the backplane with pin 20 prewired to +5 and pin 10 to ground, other pins unconnected though the holes are solder-filled.

One of the three boards I got has a broken trimmer capacitor in the oscillator circuit but this should be easily replaced if need be. Otherwise very clean looking. I think I have my 65xx backplane. I'd hate to see what a new one of these would cost today.