Doesn't sound very "human oriented."

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

I didn’t consider that option. I could place as many as I can on the main board, and include a bus connector in case it’s needed.

I’ll take that into account.




The NXP 26C92 isn’t easy to get here but my local supplier has the “XR 68C681 CP40 IC D-UART FIFO Timer Dil-40”.
http://images.ihscontent.net/vipimages/ ... 1566-1.pdf
If it’s not too hard to interface and not a pain... to program, I would consider this one.

I like your idea of having two uarts, one for the terminal and the other for software development from the PC.

Frankly, I don’t know. It’s most probably overkill.

are there EAGLE libraries available of the PLCC versions?

Why using the S-type of the VIA’s and the N-type of the ACIA’s. Is it because of the ACIA’s are so scarce available? I’m confused about that. I do understand the IRQ issue.

_________________
Marco

To clarify: Unless you're going to stick with really low frequencies like 1-2MHz, the stuff that's not on the board does not get connected to the processor's own buses. It gets connected instead to the ports of the I/O ICs. See http://wilsonminesco.com/6502primer/ExpBusIntrfc.html in the 6502 primer.


Any worthy CAD package should let you easily make your own components. Mine came with a lot of pre-made components, but I have re-made every one of them for increased board density. (I have hundreds, which is one reason I'm reluctant to change CAD packages-- I don't want to re-make all of them.)

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

That's the Motorola 68K compatible version of the 2692. I didn't think any of those things were around anymore. The bus interface will be...uh...interesting. The 2692 is much easier. BTW, you can use a plain 2692 in place of a 26C92. I started with the former on POC V and switched to the latter with V1.1. The 2692 may be easier to obtain.


I don't know. I'm not an Eagle user.


The 65C51N is the only version of this device available in PDIP-40 or PLCC-44. It has an open-drain IRQ output. The 65C51S is sold as dice.

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

I haven't even found EAGLE libraries for the DIL versions of the WDC chips (except for some old libraries that I couldn't get the current version of EAGLE for OSX to accept). I made up my own symbol for the 65C265, and used an 84-pin PLCC socket layout in the standard EAGLE distribution for it. This was no great chore, but it would obviously have been more effort if I had to create the physical layout as well.

Making your own symbols in Eagle is pretty easy with a bit of practice, and the advantage is that all your symbols will look consistent. With 3rd party symbols, they all look different (and often too bulky and poorly organized).

not really, I’ll keep looking.

I also only have the NMOS versions from Ruud’s website.

Yes, it really seem easy. I made an own new library and copied an existing part to it. Editing is straight forward. Creating from scratch takes somewhat more effort.

_________________
Marco

You can save a lot of time by adjusting the grid to the pad spacing. So, if you have 100 mil pitch, set the grid to 100 mil, draw one pad, and then just copy it one step over to make a whole row. This is especially nice if you have a whole row.

If you have a component with a bunch of odd measurements, it often easier to just open the properties and type in the coordinates by hand.

I changed the title to a more applying one.

Jameco has two versions of the 26C92
SC26C92A1A (856597) and SC26C92C1A (918647)
I don’t see a significant difference between those two.



I’m including the ‘245 bus drivers at this moment. Does a 65C02 or a 65C816 can do without them, even if one decided to go off the board?
I’m clearly uncertain.

_________________
Marco

I think their drivers are strong enough for anything you might want to connect; but the point in keeping the buses from going off the board is a different issue, having to do with speed and inductance and transmission-line effects. When connections get long compared to the wavelengths of the frequencies found in high operating speeds and fast edge rates, you'll get reflections and other unwanted effects that make a signal unintelligible unless special measures are taken. To make a real-life illustration of the reflections, think of echo. Recently I was in a parking structure where a car alarm was making the horn beep on and off a couple of times a second; but from where I was initially, it sounded like the horn was honking continuously because of all the echoing. As I got closer, I could start to distinguish the on-off-on-off and tell that it wasn't honking continually. Or think of the announcements in airport terminals that lack sound-deadening materials. It is extremely difficult to understand what they're saying. The same thing can happen with your longer connections through multiple connectors, and the ringing in the signal makes it unintelligible to the receiving end. We have a sticky topic for good construction at high frequencies, at viewtopic.php?f=4&t=2029 .

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

With 1 MHz signals, it's not that hard. Control the slew rate, and add some termination at the end of the bus. And with slow logic, the slew rate is automatically controlled.

P/N 856597 is specified as the industrial temperature range. P/N 918647 is the commercial version, which is what you should order. I've attached the 26C92 data sheet in case you don't have it handy.


The answer would substantially depend upon your construction methods. The 'C02 and '816 do drive the buses harder than the NMOS MPUs, so they can cope with more bus loading. It helps if all silicon is CMOS, of course.

Bus drivers and transceivers (you'd use the latter on D0-D7) will help—their purpose in life is to strengthen bus signals to cope with increased loading. However, bus drivers may introduce problems with ringing. Also, as Garth noted, transmission line effects related to the effective "wave length" of the signal relative to the length of the bus can result in a variety of problems, e.g., signal reflections, that are not easily resolved by the average hobbyist. As the ideal waveform in a digital circuit is rectangular, very strong odd-order harmonic content is theoretically (and usually) present. Anything that delays or attenuates the higher order harmonics will have the effect of transforming the rectangular waveform into something more akin to a trapezoid, and may cause switching problems in the device that is at the receiving end of the signal.

Schottky diode suppression at the far ends of the bus can be applied to get ringing under control and possibly reduce reflection (see attachment). Higher order harmonic attenuation is more difficult to counteract, however—a good knowledge of transmission line theory is essential. Best practice is to develop an expansion bus that doesn't require direct connection to the MPU's buses and control lines. This is what is done in virtually all professionally-designed computer systems that accept plug-in cards. You can build such an arrangement with some 65C21s or 65C22s driving the expansion bus, along with some adroit glue logic design.

I was able to take the MPU's buses off-board to interface the SCSI host adapter to POC V1.1, suffering a small reduction in maximum stable Ø2 speed from 12.5 MHz to 10 MHz in the process (side-view of the interface between host adapter and mainboard attached). I was careful to keep the overall length of the connections to a minimum and it does work. POC V2 will have the 53C94 SCSI ASIC on the mainboard, which will eliminate the need for the separate host adapter.

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

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

Slightly off-topic, but is this similar to the transition between quantum and classical physics when dealing with the DeBroglie wavelength of electrons orbiting within an atom as compared with free electrons (such as in an electron beam), with the low-speed, one-board-only case corresponding to the quantum mechanical model?

[Update, 6:40PM EDT]: Actually, a further question comes to mind: Can we use this model (classical correspondance limit / wavelength vs. size of area in which the wave propagates) to predict the maximum stable speed for a system based on the length of the longest bus lines, and to what degree would variation in signal path length (for phi2, r/w, A and D lines) affect this speed?

Recall that the original eight bit x86 ISA bus ran at a relatively sedate pace of 4.77 MHz (same speed as the Intel 8088), and that it was part of the motherboard, where presumably the connections would be point-to-point. In fact, IBM went to a fair amount of trouble to minimize spacing between the slots, presumably to avoid signal distortion.

I could see a 65xx system mimicking that arrangement, using 65C21s or 65C22s (or other devices that are similar in function), probably at a clock speed that is a subintegral of Ø2 to ease the problem of reflections and ringing. A scheme would also have to be worked out to deal with IRQs, card selects, etc.


The protection diodes at CMOS inputs are there for ESD purposes and aren't guaranteed to have any particular recovery time. Also, the diodes' zener voltage is not specified as well, but would presumably be somewhat higher than the device's rated input voltage maximum (Vin) to avoid inadvertent input signal clipping.

The Schottky array that I earlier linked is designed to both limit over- and under-shoot, and has a typical recovery time of 8ns. I doubt that a device's internal protection diodes can do that.

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