Lowering the clock speed will give time for ringing to die out on most lines, but the fast output edges of fast parts may keep poor construction from working no matter how low your MHz number gets when it comes to the clock line. As BigEd put it elsewhere recently, the bounces can lead to multiple trigger events that are too close together for especially the 65-family parts to work. Although I can't give any rule of thumb as to distances and so on, I would recommend putting the clock source especially close to the 65-family parts that have a phase-2 input. Having a slower rise time (or slew rate) will generally hold the ringing down, but can come with problems of its own. Whatever you do, I definitely wish you success; but until then, I would still caution about long connections and external buses, especially with the 14MHz+ WDC parts (not so much with older 4MHz parts).

In BDD's NAND-gate diagram above, another way to connect the 3.3K resistor is across the Shottky diode (instead of to Vcc), so when the gate's output is low, the current is nearly zero, but it still does its pull-up job if the gate's output is high. If the processor pulls RDY low internally, it still won't be fighting the gate.


Although WW sockets are expensive, I hardly think of PC boards as being any cheaper for one-off designs. I have only used one of the inexpensive houses once though, which was PCB Express or Express PCB (I never can keep those two straight-- I used the one in Oregon which allows you to submit industry-standard gerber files, not the one in California which requires you to use their CAD), and otherwise my experience has been with more-professional services that are more expensive but also don't have the limitations of the cheaper house I used that one time. Various ones here have used different PCB-manufacturing services and might comment on their experience. Do use my checking method at viewtopic.php?f=1&t=1888&start=49 . If the schematic is correct, the board will have the right connections too.

_________________
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 belatedly saw this. A ribbon cable can be made to work quite well IF correctly driven and terminated. My favorite example of this application is the single-ended SCSI bus.

SCSI-1986 (original ANSI standard) specified a maximum 8-bit ("narrow") bus speed of 5 MB/sec in synchronous mode or 3.5 MB./sec in asynchronous mode. The revised SCSI-2 standard of 1994 upped the synchronous bus speed to 10 MB/sec (known as "fast SCSI") and the 1996 addendum to SCSI-2 upped the synchronous bus speed to 20 MB/sec (known as "ultra SCSI"). The single-ended bus passes a byte on the fall of the relevant signals (it's an active low bus), so the effective frequency of the bus is the same as the transfer rate, e.g., 20 MB/sec is effectively 20 MHz. The 16 bit or "wide" version operates the same as the narrow version, but at 40 MB/sec, since a word is transferred per bus cycle instead of a byte.

Despite these speed improvements, the physical bus implementation remained unchanged. SCSI-1986 (and its progenitor, SASI) specified Thevenin bus termination, as well as detailed timings for deskew delay, bus settle delay, etc., since the bus is essentially a bunch of transmission lines bundled as a unit. Implied is that strong drivers must be used on each active signal (48ma is typical). Narrow SCSI uses a 50 pin connector and matching cable, with a characteristic impedance of 100 ohms. There are nine data lines (8 bits plus parity) and nine control lines. The pinout on the connector results in each active line on the cable being "surrounded" by a ground, which reduces crosstalk and mutual inductance effects to a minimum. Therefore, a minimum of 37 conductors is required to implement the narrow bus. The wide bus uses a 68 pin HD connector and matching cable, but has many of the characteristics of the narrow implementation.

Now, here's the kicker. Despite the speed at which the narrow bus can operate, the cable length can be considerable, up to 12 meters when running at fast SCSI speeds (10 MB/sec)! Even at ultra SCSI speeds, a cable length of 3 meters is allowed. So it's obvious that a correctly engineered bus can work over a distance.

In order to take the 65C816 buses off the board, you are going to be extending at least 26 lines: D0-D7, A0-A15, RWB and Ø2 (you might also need an interrupt line). So you will need N+1 grounds, where N is at least 26, for a total of N × 2 + 1 leads in your expansion bus cable.

The point to all this is if you are willing to properly design your expansion bus you can get acceptable performance. So be prepared to either do it right or not have it work. You will have to allocate sufficient leads in your ribbon cable to surround each active lead with a ground. You will have to terminate each active lead at each end of the bus. You will have to provide enough drive to overcome capacitive loading. And...you will have to keep the effects of signal skew in mind as you design your bus. It's not simple, but it is possible.

Food for thought.

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

You can wire-wrap and have a successful circuit—you just need to be reasonably meticulous. Starting right off with a PCB does have the advantage of reducing assembly effort and time, as well as the likelihood of miswiring, but of course doesn't guarantee that your device will work. And as Garth points out, there's a potential cost-tradeoff due to the much higher cost of wire-wrap sockets. On the other hand, going the PCB route allows you to build with SOIC parts without too much effort. Decisions, decisions...

I took these things into consideration when I was designing POC V1.0. In the end, I elected to start right off with a PCB instead of WW because worsening eyesight at the time was causing me to be concerned about making unseen wiring errors in a WW unit. With that decision made, I also decided to use a 4-layer board with internal ground and power planes, as I knew that the resulting layout would be denser and quieter than 2-layer. There wasn't enough of a cost difference between 2- and 4-layer for me to consider a 2-layer board. The POC V1.1 update version, as well as the SCSI host adapter, was also 4-layer and thanks to insight gleaned from the performance of V1.0, quieter and capable of operating faster than the first version.

Only you can decide which way to go. It depends on whether you are willing to trade money for a shorter build time and reduced likelihood of assembly errors. If you decide to go the PCB route, I do suggest you look at a 4-layer design. However, for your first design, WW should be more than satisfactory—plus a lot easier to fix if you find an error after the fact.

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

Express PCB is in California. Funny thing is I've noticed that when I've placed an order with EPCB, the shipping origin for the goods is in Oregon...

Either way, both source produce high quality boards. Express PCB's software is a form of vendor lock-in, of course, since their PCB CAD doesn't generate Gerbers. However, from a hobbyist's point of view, that may be unimportant.

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

Overcooked advice again, BDD. A long ribbon cable needs termination but a short one will not. System speed and edge rates will also figure. Please try to stay on-topic - a low tech project does not need and will not benefit from high-tech approaches.
Thanks
Ed

That's good to hear!


Or, even if there's no error, it's also easier to modify or augment later.

Now about the SCSI rabbit trail: BDD, is there a Thevenin termination at each end of the long connection? That would take a drive current of 50mA per line (pulling both up and down) if the characteristic impedance of the transmission line is 100Ω (and the drivers' output voltages are close to 0V and 5V), but would make it quite well behaved. Also, what are the voltage thresholds of the inputs of the logic used?

The delay of a 12-meter-long cable would be somewhere around 60ns in one direction; so at 120ns for a round trip, it is of course not an option for sending out an address and receiving data on a 65-family bus in the same cycle at more than a few MHz max (the 120ns does not include memory-access time, time for glue logic, or set-up times) but SCSI is not used in the same way, so that doesn't bother it. If there's poor (or no) control of transmission-line impedance (like a hobbyist might have on a PC board) and it's not properly terminated, the rise times that are common in this hobby can become troublesome with connections anything over just a few inches long. Dr. Howard Johnson has a short article on the trouble caused by fast rise times where impedance is not controlled, at https://web.archive.org/web/20160409232 ... gswtch.htm, and another at https://web.archive.org/web/20120302190 ... kforit.htm. I've been bit by this myself (at work).

Card cages and large motherboards and memory SIMMs and so on, running at high speeds, definitely can be (and are) made; but the transmission-line math that goes into it, including things like the modeling of connectors, is way beyond the expertise of most hobbyists, so the easier thing (and my recommendation) is to just keep it small and make connections as short as possible, in order to avoid the complications. If you do this, you don't have to understand the hard stuff. I want to see success, and not have the beginner discouraged because he bit off more than he understands (although there have been times that I bit off more than I understood and happened to get lucky, and I didn't realize how lucky I was until years later).

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

Thevenin or active termination is required at both ends of the bus, so your calculations concerning drive per line are very close. The Thevenin resistor values are 220 ohms to Vcc and 330 ohms to ground. Note that all bus signals are active low—the attached devices are open drain. Hence, termination biases the signals to 3.3 volts when the bus is quiescent or when a particular signal is false. The attached device must be able to reliably sink at least 45ma when active. The 53C94 I have in POC V1.1 is rated at 48ma per pin. Cursory testing in the past showed that an NCR 53C80 SCSI bus driver (the grandfather of the 53C94 I'm using with POC) could sink a line to about 0.2 volts.

An alternative to Thevenin termination is active termination, in which a 3.3 volt regulated source is connected to each signal through a 100 ohm resistor, and no connection is made to ground. This is the preferred arrangement for all single-ended implementations, and is required with ultra SCSI (20 or 40 MB/sec). The regulator has to produce at least 900ma to handle the worst-case scenario of all 18 narrow bus signals being simultaneously active. Host adapters that implement the wide bus typically have two regulators.


Of course, I wasn't advocating the use of a 12 meter bus. Even 12 inches would be pushing it. Also, I wasn't offering "...Overcooked advice again...", as I don't advocate taking the MPU's buses off-board at all. My point was that correct implementation makes it possible to extend a bus and not get into trouble. The SCSI implementation, which design was conceived c. 1978, is good for illustrating that, as it reliably operates at high speed.


Which fact illustrates why a simple solution isn't all that simple. My above diatribe may seem overcooked to some, but the reality is a simplistic approach to a reliable expansion bus design usually isn't possible.


I as well, which is why I will sometimes intentionally complicate the discussion to discourage the neophyte from designing something that isn't likely to work, and instead encourage him/her to be more conservative.

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

I didn't read all of the new posts yet, but let me set some concrete simple goals for "round 1" of this project:

Get a simple '816 board running at 14MHz.
Include an off-board bus to interface to an FPGA dev board (to develop the DMA controller).
Use a VIA and ACIA as basic I/O on the '816 board end... place the I/O, ROM, and RAM (if necessary- I can use the FPGA SRAM) in separate banks to test the bank circuit. I can worry about using the address space effectively later in round 2. Round 2 is not going to be backwards-compatible most likely.

The reality is, I could start the DMA controller while I build this... hell, in theory I could just buy an 816 core from WDC and just use the FPGA for now... but where's the fun in that?

From what I've gathered, my desired clock speed and "low-tech" are mutually exclusive XD. Although that's deliberate- I want to use a high clock speed from the beginning.


I took a course in transmission line theory a while ago... though I'd have to do some studying (like re-deriving the telegrapher's equations) to get back up to speed.

I started a topic a little over four years ago, "I/O not in bank 0" which migrated a bit but I think at least the first several posts will interest you. I do anticipate programming inefficiencies though in putting I/O, RAM, and ROM in separate banks.

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

Garth pointed this out, but I'll reiterate. Scattering ROM and I/O into different banks is not efficient, particularly in the case of ROM.

When an interrupt hits the 65C816 will automatically load $00 into PB after pushing it, PC and SR to the stack (which itself can only exist in bank $00 absent bank remapping logic). Therefore, you must have code and data (vectors) in bank $00 for the '816 to access. Otherwise, the '816 will load garbage for an interrupt vector and your machine will likely crash.

Yes, it is possible to have a short ISR preamble in bank $00 and then JML from there to another bank for the rest of the ISR. However, that is not efficient, especially since an ISR should be as succinct and fast as possible. Yes, JML only uses six cycles and it would only happen once per interrupt, but it's six cycles repeated as many times per second as interrupts occur, which could be a lot during I/O.

Similarly, when the '816 is reset, it reverts to emulation mode and forces bank $00. Therefore, code must be available in bank $00. There is no other way to initiate the reset procedure.

As for I/O hardware mapping, you have to consider that reads and writes with the '816 are always directed to the bank set in DB, unless long or indirect long addressing is used. Therefore, you must be prepared to either change DB on every interrupt and restore it before returning to the foreground process, or use 24 bit addressing on every I/O access. 24 bit addressing is slower than 16 bit addressing by one cycle, which really isn't something that you want in an ISR or an operating system kernel (a single I/O transaction could potentially involve several thousand device register accesses ). Also, a number of instructions are not available with 24 bit addressing, so you may find yourself using more code and clock cycles than really necessary.

For test purposes on a new design, having ROM and I/O in bank $00 assures access in emulation mode, which will simplify initial hardware debugging. You can always write a checkerboard routine that runs in bank $00 to test your bank logic after you have leaped the hurdle of getting the unit to work.

Don't make it complicated.

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

BTW, be sure to read this article.

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

Point taken, 14MHz has to count as high tech! BTW I'm not sure if many projects (or any projects?) use RDY to produce long clock cycles to talk to slow peripherals. It seems like the right way to do it - think of it as wait states if you will. An alternative way is to build a fancy clock generation which swallows clock pulses for slow accesses.

It's possible that a long bus/highly extended machine would work at 14MHz with a single wait state - it would be faster than a 7MHz system, especially if it had some fast memory close to the CPU.

Cheers
Ed

I don't recall the details, but I think the CMD TurboCPU cartridge for the C-64 wait-stated the '816 via RDY during I/O. Both the 'C02's and '816's implementation of the ReaDY logic is timing-friendly, so would probably less a hassle to use than clock stretching. The stock C-64 and C-128 both used clock stretching on I/O accesses, as RDY doesn't halt a write operation in the NMO MPUs.


I'm thinking that if a bus is going to be run that fast it would be isolated from the MPU buses by suitable logic (a 65C21 or 65C22, perhaps?) so as to maintain both signal strength/quality and accurate timing. However, such an arrangement most likely would not require that the full width of the address bus be present. Instead, chip selects could be generated by the bus logic to select a particular card(?), and only the low address lines (e.g., A0-A4) would be needed for accessing individual registers in each card's I/O hardware. In other words, this would be the makings of a poor man's ISA bus.

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

The fact that you've written as an addendum that 5V logic GALs are disappearing isnt comforting.
In any case I have some money now... So it's time to create a custom '816 board! IO map to follow tonight for critique