Second Steps (Building R0)

[cr1901]

I created a circuit that attaches to the GPIO/I2C bus of my Raspberry Pi that probes the bus of the 65816, making sure to switch bus direction between PHI2 low and PHI2 high. There IS bus contention in my circuit for a short period when the bus switches from read data back to write bank, but so far I haven't had any issues doing probing with my setup.

Control signals PHI2, RDY, RWB, VDA, VPA, and RESB are attached to the Raspberry Pi GPIO port.
The bank/data bus is connected to PCF8574 I2C I/O expander. It has push-pull output (whatever that means), and output is as simple as writing the required value to the device. Input is implemented by writing a logic 1 to each pin for the I/O device. It's up to other devices, in this case the Bank/Data bus, to drive the bus when the I/O expander is in input mode. I only switch the I/O expander's direction to output (CPU read) when PHI2==1 and RWB==1, and switch it back to input when PHI2==0.

I wrote a program on my Raspberry Pi to monitor the data bus and control signals, toggling the PHI2 GPIO to simulate single-stepping to probe the bus. My Pi runs NetBSD (that's a discussion for another time), so unless some of you use that instead of Linux, my program isn't exactly ready to be used by others who want to experiment . Therefore, I'll hold off on the circuit diagram/source code for now.


The answer to my question conclusively: The 65816 does NOT drive the bank address while RDY is low. Therefore, there must be some means to prevent a new garbage bank address from accidentally being latched. The big hint for me is that the I/O expander sees the value 0xFF when RDY==0 and PHI2==0. This indicates the bus is not being driven, so the I/O expander goes into pullup mode (or whatever the equivalent is for push-pull).

If RDY is driven low during PHI2 high, the '816 will NOT drive a bank address onto the bus during the next PHI2 low.

If RDY is driven low during PHI2 low, a read during PHI2 high will occur as normal, and during the same situation as above applies. Have not tested writes yet.

If RDY is driven high during PHI2 high, the '816 WILL drive a new address onto the bank bus during the next cycle. Obviously, the I/O device better in fact be ready, and have some breathing room to satisfy setup time. Otherwise it is probably best to drive RDY high while PHI2 is low.

If RDY is driven high during PHI2 low, a read during PHI2 high will occur as normal, and the '816 WILL drive a new address onto the bank bus during the next cycle.

Here is some sample output. RDY changes directions before PHI2 is toggled on any line with an 'r':

Code: Select all

PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: 0

PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: E8
r
PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: FF
PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: E8
r
PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0
PHI2 1, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: E8

PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: 0
r
PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: E8
PHI2 0, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 0, Bank/Data bus: FF
r
PHI2 1, RESB 1, RWB 1, VDA 0, VPA 0, RDY: 1, Bank/Data bus: E8
PHI2 0, RESB 1, RWB 1, VDA 1, VPA 1, RDY: 1, Bank/Data bus: 0

Something else is bothering me about my setup however... according to what I'm seeing from my program, NOP is in fact 4 cycles on the '816, not 2! o.0; And I don't think it's an error either, b/c other Implied address mode instructions, such as INX (see above- 0xE8), are 2 cycles in length. Something's very wrong... or something very interesting is happening.

EDIT: Ignore the above paragraph- I miswired/swapped D2 and D1... so 0xEA (NOP) was in fact 0xEC (CPX absolute) XD. Taking that into account, the behavior I saw (4 cycles, emulation mode) makes sense. Above results are not affected since D2==D1==0 in 0xE8.

[BigEd]

Thanks for doing the experiment and letting us know!

[Dr Jefyll]

BigEd wrote:

Thanks for doing the experiment and letting us know!

Yes, indeed -- thanks, cr1901! Good to have the doubt removed.

[cr1901]

BDD's solution will work for fixing RST, but I'm trying to determine whether I can't reduce the prop-delay from his implementation to keep 14MHz operation with discrete components.

Thinking about buying a GAL programmer. I'd like to do a design without using GALs, but again, since Joachim's design of his first SBC proves 14MHz operation is possible with 74xx glue logic, I feel less obligated to do that now.

Additionally, fun fact: I do not have the funds for an EPROM programmer either. If it weren't for a generous donation from a professor back in 2011 (Needham's PB-10 ISA card- currently in my 286), I wouldn't have an EEPROM programmer, and would have to find some makeshift solution to program EEPROMs or something. Making my own GAL programmer doesn't seem all that appealing either.

If I decide to go this route for the time being, would someone be willing to program a few GALs for me if I give them a design (chessdoger... I live in the US, so I'm not sure how much it would cost to mail a letter or manila envelope with GALs inside)? Payment is offered for your trouble/reduced stock .

[nyef]

cr1901 wrote:

Thinking about buying a GAL programmer. I'd like to do a design without using GALs, but again, since Joachim's design of his first SBC proves 14MHz operation is possible with 74xx glue logic, I feel less obligated to do that now.

Note that Joachim's design uses 74F logic, which is old, power-hungry, and fast. As in, worst-case prop times lower than ACT, and power usage measured in mA rather than uA.

[BigDumbDinosaur]

cr1901 wrote:

BDD's solution will work for fixing RST, but I'm trying to determine whether I can't reduce the prop-delay from his implementation to keep 14MHz operation with discrete components.

[BigDumbDinosaur]

nyef wrote:

cr1901 wrote:

Thinking about buying a GAL programmer. I'd like to do a design without using GALs, but again, since Joachim's design of his first SBC proves 14MHz operation is possible with 74xx glue logic, I feel less obligated to do that now.

Note that Joachim's design uses 74F logic, which is old, power-hungry, and fast. As in, worst-case prop times lower than ACT, and power usage measured in mA rather than uA.

Even faster than 74F is 74ABT, which isn't as power hungry.

[nyef]

BigDumbDinosaur wrote:

nyef wrote:

cr1901 wrote:

Thinking about buying a GAL programmer. I'd like to do a design without using GALs, but again, since Joachim's design of his first SBC proves 14MHz operation is possible with 74xx glue logic, I feel less obligated to do that now.

Note that Joachim's design uses 74F logic, which is old, power-hungry, and fast. As in, worst-case prop times lower than ACT, and power usage measured in mA rather than uA.

Even faster than 74F is 74ABT, which isn't as power hungry.

Oh, nice. Max prop times on a '00 less than half of a 74F. Now if only we could get a '138 in ABT...

[BigEd]

(At one time I thought it would be good to have a sticky thread summarising the strengths and weaknesses of the various 74 series families. I can't find such a thread, so evidently I didn't act on the thought. If anyone feels qualified to summarise, please start the thread, and update your head post as information comes in. If it looks good, perhaps it can be promoted to sticky. There's some supportive commentary at viewtopic.php?p=909 but I think a summary in a dedicated thread would be helpful.)

[BigDumbDinosaur]

nyef wrote:

BigDumbDinosaur wrote:

Even faster than 74F is 74ABT, which isn't as power hungry.

Oh, nice. Max prop times on a '00 less than half of a 74F. Now if only we could get a '138 in ABT...

The '138 is available in 74AC, which is about as fast as 74F, without the power consumption. I used the 74AC138 in POC, which will run at 15 MHz without the SCSI host adapter plugged in.

74ac138_decoder.pdf

74AC138 3-8 Decoder

(668.04 KiB) Downloaded 115 times

[Dr Jefyll]

nyef wrote:

Oh, nice. Max prop times on a '00 less than half of a 74F. Now if only we could get a '138 in ABT...

Hmmm, the figures (below) for the CY74FCT138 are about half of those for 74F.

cy74fct138t.pdf

(463.29 KiB) Downloaded 98 times

Notice with this particular product there's a suffix that denotes different speed grades, with "C" being the fastest. Of course package options and availability are two potential show-stoppers for the hobbyist, but I'm glad to see that Mouser presently has the A version in stock in SOIC, offered in single-unit quantities.

BigEd wrote:

it would be good to have a sticky thread summarising the strengths and weaknesses of the various 74 series families

Perhaps that'd be helpful, but let me remind everyone that the filtered part searches offered by major suppliers on their web sites are an excellent way to find the best part for your needs. You just apply successively finer filters, filtering for the attributes you deem most important first.

The advantage of the filtered part search is it allows you to find options you were unaware of, or had perhaps forgotten. It lets you express the goal. In this case, the goal isn't to find an ABT or FCT or whatever. The goal I sought was a fast, 138-type decoder that'll run on 5 volts. The logic family was determined last -- not first.

Although there are other good examples, it's the DigiKey site I use most. From their main page, go to Product Index (not Catalog).

cheers,
Jeff

[BigEd]

Good point Jeff!

[BigDumbDinosaur]

BigEd wrote:

(At one time I thought it would be good to have a sticky thread summarising the strengths and weaknesses of the various 74 series families. I can't find such a thread, so evidently I didn't act on the thought. If anyone feels qualified to summarise, please start the thread, and update your head post as information comes in. If it looks good, perhaps it can be promoted to sticky. There's some supportive commentary at viewtopic.php?p=909 but I think a summary in a dedicated thread would be helpful.)

I too thought that there was such a thread, but evidently not the case. Here's a by-no-means-complete summary.

• 74xx
  
  The original "high speed" TTL logic, developed during the 1960s. A MILSPEC version is 54xx. Good switching speed, weak fanout, high power consumption. 74xx should only be used for historical restorations.
• 74Sxx
  
  "Schottky" TTL logic, released as an upgrade to 74xx. Better switching speed, better fanout, higher power consumption. 74Sxx should only be used for historical restorations.
• 74LSxx
  
  "Low-power Schottky" TTL logic, developed to address the power consumption issues of 74Sxx. Switching speed comparable to 74S, but with slightly weaker fanout. 74LSxx was the mainstay of computer circuits for a long time, but is no longer recommended for new designs.
• 74Cxx
  
  The 74xx series in CMOS, developed to further reduce power consumption, as well as improve noise immunity. Switching speed is not as good as 74LSxx, and is affected by operating voltage. Fanout tends to be weak. The inputs of 74Cxx devices cannot be interfaced with the outputs of 74xx, 74Sxx or 74LSxx devices due to differing voltage thresholds. 74Cxx is generally obsolete and should not be used except in historical restorations.
• 74HCxx & 74HCTxx
  
  "High speed" CMOS devices that are faster than 74Cxx. Switching speeds are generally comparable to 74LSxx devices when operated at 5 volts. The inputs of 74HCTxx devices are compatible with the outputs of TTL devices, although a given 74HCTxx device will be slightly slower than its 74HCxx equivalent. Good fanout, low power consumption and suitable for designs that do not demand maximum performance.
• 74ACxx & 74ACTxx
  
  "Advanced" CMOS devices that are substantially faster than 74HC and 74LS. Many devices possess propagation times in the single digit nanosecond range when operated at maximum recommended voltages. The inputs of 74ACTxx devices are compatible with the outputs of TTL devices, although a given 74ACTxx device will be slightly slower than its 74ACxx equivalent. Wide selection of devices and in some cases, package styles. Very rapid output switching speeds and moderate power consumption, depending on the applied loads, but with excellent fanout. Recommended for new designs, especially if elevated clock speeds are important.
• 74ABTxx
  
  Very high speed CMOS devices that combine the switching speeds of bi-polar TTL logic with the noise immunity and fanout of CMOS. 74ABTxx possesses propagation times in the single digit nanosecond range when operated at maximum recommended voltages, with some devices very close to a 1ns prop time. Somewhat limited selection of devices and in some cases, package styles, with most being SOIC or similar. Extremely rapid output switching speeds and moderate to high power consumption, depending on the applied loads, but with excellent fanout. Recommended for new designs, especially where high clock speeds will be used.
• 74Fxx
  
  A "fast" type of TTL logic, with some devices being as much as four times as fast as their 74LSxx equivalents. Good fanout but with high power consumption and limited selection. Not recommended for new designs.
• 74FCTxx
  
  Similar in many ways to 74ABTxx, as well as 74Fxx, with TTL compatible inputs. Many devices possess propagation times in the single digit nanosecond range when operated at maximum recommended voltages. Limited selection of devices and in some cases, package styles. Extremely rapid output switching speeds and relatively high power consumption, depending on the applied loads, but with excellent fanout. Recommended for new designs, especially where high clock speeds will be used.

[cr1901]

BigDumbDinosaur wrote:

cr1901 wrote:

BDD's solution will work for fixing RST, but I'm trying to determine whether I can't reduce the prop-delay from his implementation to keep 14MHz operation with discrete components.

I meant RDY. I was thinking out loud; I want to avoid adding numerous components to the CLK circuit as seen by the bank latch and data transceivers- b/c at 14MHz, every nanosecond counts.

[cr1901]

Re: bootstrapping using a microcontroller... I decided to try making a RDY circuit that is controllable by a microcontroller. Events are clocked during the rising edge of PHI2. If the microcontroller's (ucon) address space is chosen (USEL), RDY is driven low. If the ucon has not already done so, it must drive its own GPIO pin low (UPROCESS) to represent that it is ready to process new data. When the ucon is done processing, it sets UPROCESS high. Upon receipt of the next positive edge of PHI2, this will force RDY high for one bus cycle; if USEL is chosen again, RDY will immediately be driven low again after the positive edge of PHI2, and the process repeats.

A microcontroller is not going to be able to set/unset its GPIO pins once per 6502 bus cycle at high speeds. While this significantly cuts the speed of microcontroller accesses, this is a simple arbitration circuit so a ucon can communicate with a 65xx reliably.

This is as simple as I can get it, but I don't think it's enough anyway o.0;

Code: Select all

RDY=Q*USEL + ~UPROCESS
Q'=UPROCESS * ~USEL

Q is the output of a positive-edge triggered flip-flop, such as the SN74HCT74. The circuit requires 5 gates (2 NOTs, 2 ANDs, 1 OR).

Here is the truth table:

Code: Select all

Q USEL UPROCESS | Q' RDY
0 0    0        | 0  1
0 0    1        | 0  1
0 1    0        | 1  0
0 1    1        | 0  0
1 0    X        | X  X ;USEL=0 while in state 1 is impossible.
1 1    0        | 1  0
1 1    1        | 0  1

At 14MHz, I think the prop delay on the critical path is too much, the way I have my schematic drawn. I wonder if I can find an more compact/IC solution...