lordbubsy wrote:
I don’t know that much about the differences in the 74xx logic families. But it’s a bit clearer now.
Logic falls into two broad classes: TTL (which descriptive name is a bit of a misnomer, but widely accepted) and CMOS.
The grandaddy of TTL logic is the (still available) 74-series, the ancestral device being the 7400 quad NAND gate, which I first encountered c. 1967. 74-series logic (also 54-series, which is essentially the military equivalent of 74) has pretty good switching speed but high power consumption. The desire to improve switching speed led to the development of the 74S (S = Schottky) series, which used Schottky diodes to clamp the inputs to reduce state transition time. However, power consumption was higher than plain 74 logic. The latter issue eventually lead to the development of several other logic families, the most familiar being 74LS (LS = low power Schottky), which was the standard for many years. The "low power" monicker was relative to 74S—74LS is still pretty power-hungry by current standards.
CMOS logic was almost developed in parallel with TTL, the first devices being the CD4000 series from RCA in the late 1960s. 4000 devices, which are still made, can operate over a wider range of voltages (up to 15 volts, making them suitable for automotive applications), use significantly less power than 74LS and have better noise immunity, but have mediocre switching performance. You wouldn't want to build a computer around 4000—series logic.
CMOS development eventually caught up with and surpassed 74LS in all respects. 74C (C = CMOS) followed on the heels of 74LS, but was markedly slower than the latter. 74HC (high speed CMOS) combines the switching speed of 74LS with the reduced power consumption and noise immunity of CMOS. 74AC (advanced CMOS) further improves switching speed, making 74AC as much as five times as fast as some 74LS equivalents and typically twice as fast as 74HC equivalents. The fastest discrete logic that is readily available is 74ABT (ABT = advanced BiCMOS), with some gates (e.g., 74ABT00) operating as fast as 2.5ns at 25° C on 5 volts).
Devices that have T in the part number, such as 74ACT00, have TTL-compatible inputs, allowing them to be used as replacements for 74LS devices. Excepting 74ABT logic, you wouldn't use 74HCT or 74ACT devices in a new design unless a TTL device is driving a CMOS device. All CMOS devices have higher fanout (output drive strength) than equivalent 74LS devices, which becomes an important feature if a lot of hardware is connected to the same buses. As more hardware gets attached, bus loading (and parasitic capacitance) increases and may result in a DOA circuit if the device driving the bus(es) can't source or sink the bus(es) to the appropriate levels. Succinctly stated, 74LS should not be used in new designs unless no alternative exists.
Quote:
I’ve read a great deal on your website, and according to your schematics, it isn’t that much different from a “classic 8-bit” design.
That's correct, and I say as much in the narratives. I intentionally started out simple to avoid a DOA design.
Quote:
How does the glue logic with the 74 574 (or 74 273 ?) look like to connect and enable all the address lines?
You'd use a 74ABT573 or 74AC573 to latch A16-A23. WDC shows such an arrangement on page 46 of the 65C816 data sheet, but as drawn it has defects because it fails to account for the 65C816's
VDA (
Valid
Data
Address) and
VPA (
Valid
Program
Address) outputs, which indicate when addresses are valid. Failure to include VDA and VPA in the logic design can result in false bus accesses that may corrupt RAM and/or upset some I/O hardware (I discuss this on my POC website).
The data bus transceiver (74xx245) is optional—its functionality as a bus isolation device when Ø2 is low can be supplanted in most cases with simple gating. Bus transceivers, as a fairly general rule, are only needed when a lot of hardware is connected. That wouldn't be the case in a first-time (or even second-time) effort.
Quote:
Quote:
What are you going to use to read a keyboard?
At first I’ll use the 6551 and a terminal program. Later an AVR to provide PS/2 keyboard input, together with clock, single step, reset etc.
If you scrounge around, you may be able to find a retired dumb terminal like a WYSE 60 (hundreds of thousands of them were sold and many are still around) or a DEC VT-100 and attach it to your creation. That's what I did with mine and it was more convenient than running a terminal emulator on another computer.
Using an AVR for a PS/2 keyboard input sounds good, but I question using it as a reset and clock source. Your best bet for a clock source is a TTL can oscillator, optionally driving a flip-flop (the method I used—sharpens the waveform and assures a true 50 percent duty cycle), and mounted as physically close to the MPU as possible. The quality of the clock signal is very important, in that an asymmetric signal can result in timing issues that are not readily debugged. You won't have control over clock symmetry if you derive Ø2 directly from an AVR. If you're looking to have several Ø2 frequencies, you could use the can oscillator with cascaded flops—the 74AC74 I used has two flops per package—and just use a jumpers to tap into the cascade at the desired point.
The easiest way to generate a proper reset signal is with a Dallas DS1813 econo-reset, which reacts both to the rise and fall of Vcc and the grounding of the reset line by a push button. The DS1813 holds the '816's RESETB input low until Vcc has reached about 4.6 volts (DS1813-5), at which time a 150ms timer starts. When the timer expires, RESETB will be released and the '816 will go to work. The result is Vcc has plenty of time to stabilize before the '816 comes to life. Grounding the reset line will reset the 150ms timer, so you don't have to worry about debouncing the reset push button.
Quote:
Regarding the SID, I would be perfectly satisfied with the following:
A counter (‘293) provides 8, 4, 2 and 1 MHz. from a 16MHz. oscillator. A latch determines which of them will be selected as PHI2 system clock.
The 74LS293 (I couldn't find it in any other logic family) isn't a good choice, as it has way too much cumulative prop time. You'd have to drive the SID off the "Qd" output to achieve what you want, which output lags the master clock input by some 46ns (average). Unless the MPU were attached to "Qd" as well, the SID's Ø2 clock would be far out of phase with the MPU's Ø2 clock and timing would be completely in the toilet. I can't see how this would possibly work.
I already mentioned this, as did Garth. Not only does the SID's clock have to be a fixed 1 MHz, it
must be phase-locked to the MPU's Ø2 clock, meaning both must be high at the same time if I/O timing is to succeed. The SID's Ø2 signal would have to be powers-of-2 submultiples of the MPU's Ø2 clock, derived from a clock generator in which worse-case prop time from master clock to SID's Ø2 input is a vanishingly small number of nanoseconds. I can see doing this with cascaded flops—real fast ones, preferably inside a CPLD. The alternative would be with four 74ABT74 flops (fastest discrete ones available—two per package), which would still worst-case produce as much as a 17ns phase shift from clock source to SID. A CPLD could achieve an effective zero phase shift, since all prop times are rated pin-to-pin, which means the internal prop time from clock input to either of the clock outputs in question would be the same.
You'd also have wait-state access to the SID, with the number of wait-states being equal to MHz-1, where MHz is the MPU's Ø2 frequency (assuming the MPU's Ø2 frequency will never be less than 1). I may be wrong, but I don't think there's really another reasonably simple way to do this.
Quote:
The SID will be connected through two 74AC245. One for the data lines and one for the 5 address lines. (and perhaps a signal which is needed to cut off)
That seems reasonable.
Quote:
If the system clock > 1MHz., the bus lines will be in 3-state. Cutting off the SID completely from the system. Otherwise, the ‘245 provides the bus driver you mentioned which is needed for connecting NMOS to CMOS.
You should tri-state the bus driver at all times when the SID isn't being accessed—your I/O decoding logic would take care of that. It's something that is independent of the Ø2 clock. In fact, address decoding of any kind should be not qualified by Ø2. This is especially important with the WDC peripheral devices (65C22, 65C51, etc.), which require that the chip selects be valid before the rise of Ø2. It's likely that the SID has a similar requirement, but not having seen a data sheet for it in many years, I can't vouch for that.
Quote:
So I won’t be able to use the SID if the system clock <> 1MHz.
You can if you're willing to generate phase-locked clocks and wait-state SID accesses.
I understand why you'd like to use the SID, but think it's more trouble than it's worth (plus I'd be leery of designing around a device that hasn't been manufactured in decades).
Quote:
BigDumbDinosaur wrote:
Trying to incorporate too many features and/or an idiosyncratic memory map into the design almost guarantees that the unit with be DOA on first power-up and difficult to debug. In other words, it's best to learn how to pilot a single-engine light plane before stepping into the cockpit of a 747 or A380.
I agree, that’s why I build my first system with RAM:$0000-$7FFF I/O:$8000-$BFFF and ROM:$C000-$FFFF on breadboard.
Question is:
A. should I build the this breadboard version on PCB first (without bank switching, SID’s or even VIA’s), before I start with an ‘816 design?
I'd consider doing your next design in wire-wrap, and later when you are more confident of your design skills, on a PCB. Breadboard is notoriously unreliable at clock speeds slightly higher than those of a cheap pocket calculator. Those long wires throw all sorts of reactance (especially inductance) into the circuit, making for distorted waveforms and very sloppy timing. A good wire-wrap unit can be run quite fast. I've seen WW hobby units run at 8 MHz.
Quote:
B. Or buy a set of WDC chips (with the ‘816) and built the same as A. The design would be a little different regarding the control bus signals and system clock.
My approach would be to build a 64KB system with the '816 and immediately get familiar with it. The circuitry is very similar to that of a 65C02. The refinements needed to address more RAM add somewhat to the complexity and to potential timing problems. It's best not to take too big a leap with this.
Quote:
C. I buy a set of WDC chips (with the ‘816) and built the same as A. including the 628512 and a 29F010 and the ability to access the extra memory.
That's too much like trying to pilot the 747 with no prior experience.
Quote:
In all three cases I will include a bus connector. At first I wanted to use a backplane, but it seems to be better (and probably less work) to use a “sandwich” approach.
Not recommended. Going off-board with the buses drastically limits performance due to all the loading. Garth discusses going off-board with the buses at
this page (see item #2).
Login
Register
FAQ
Search
