A8 Motherboard: Is the 74LS08 chip Really Needed?

[+mytek]

So here's the deal. I'm messing around with the idea of creating a custom motherboard, and trying to determine what is absolutely needed, and what isn't. Specifically this particular topic is strictly about the 74LS08 gating circuits. So please don't launch into how people have talked about doing this before, or what you think I should implement in my motherboard design, blah, blah, blah. Because this is for personal use and understanding only, and not aimed at being a commercial product.

 

So with that said, let's proceed.

 

 

First the schematic, showing how Atari did it in an XEGS (my test system).

 

 

I've read the various discussions about why these gates are being used for buffering PH2, sometimes PH0, and for some odd reason the 74LS138 address decoder's GTIA CS line (in the case of the XEGS). The light pen usage is straight forward and perfectly understandable so no explanation really needed (it simply 'Y's the two trigger inputs). but for my custom system I'm not too concerned about things like Cart compatibility or PBI stuff other than what the U1MB and SIDE2 combination utilizes.

 

So my first test was to pull out the LS08 and jumper socket pins 1 to 3 and then jumper pin 9 to 8. I fired it up, and so far everything appears to be working just fine.

 

My Test System (this is all I intend to use, no BB, no MIO, no IDE, no VBXE)

 

XEGS

U1MB

TK-II

SIDE2

SIO2PC-USB

 

 

So for my first experiments what I want to do is a comparision between the jumpered setup (without LS08 chip) and with a LS08 chip in place. Basically I want to break it with some kind of software test, and I need to know what would be the best and fastest test to use?

 

- Michael

 

 

[Bryan]

The PH2 buffering may have one of two uses:

 

1. Better drive capability. Often CPU lines cannot meet timing specs if they drive more than one or two inputs.

2. Added delay. Sometimes adding 10-20ns of delay to a signal is beneficial to overall stability.

 

Perhaps a delay was desired for the GTIA CS line as well.

 

This is where logic analyzers are handy for seeing that everything meets its setup and hold times and also remember these values can change from chip to chip and are sometimes out of spec entirely for a batch of chips.

[+mytek]

The PH2 buffering may have one of two uses:

 

1. Better drive capability. Often CPU lines cannot meet timing specs if they drive more than one or two inputs.

2. Added delay. Sometimes adding 10-20ns of delay to a signal is beneficial to overall stability.

 

Perhaps a delay was desired for the GTIA CS line as well.

 

This is where logic analyzers are handy for seeing that everything meets its setup and hold times and also remember these values can change from chip to chip and are sometimes out of spec entirely for a batch of chips.

 

All good points.

 

Its been awhile since I read some of the reported problems with PH2, but if I recall correctly a lot of the issues seemed to be related to Carts and PBI usage. This does seem logical since those items are somewhat appended to the bus, and not as integrated as the actual motherboard components. In fact I remember once trying to build an A8 into a PC enclosure and having nothing but problems when running Carts on an extended ribbon cable connection. Some would be just fine, while others would crash and burn. So generally this looks like a need for bus buffering, which I believe was being looked at for at least some of the early 1090 prototypes.

 

Now I've also seen a lot of DIY single board computer designs based around the 6502 and it's 6500 series support chips (PIA and ACIA). In those designs I haven't seen any buffering of the PH0 or PH2 lines in use, and they seem to work fine. So this got me thinking, why did Atari decide to do this? Was it because of the other custom LSI chips loading down the bus, or is more related to expansion (i.e., Carts and PBI).

 

Anyway I don't have a logic analyzer , so I was thinking of going more old school and utilizing a test that reveals the problem so that I can better zero in on when and why it happens, and formulate the best approach to cure it for my purposes.

 

- Michael

Edited January 6, 2017 by mytekcontrols

[Bryan]

I just looked at the Rockwell 6502 datasheet and the rise and fall timing on the clock pins is guaranteed for 1 TTL load plus 30pF, so that's a reason to buffer it.

 

In electronics there's always good enough vs. technically correct. You can often use the signals directly if you don't need to meet the spec and if you've built something and it's stable enough for the intended purpose. But, if you're going to allow 3rd party things to hang on the bus you really should buffer the signals.

[Rybags]

The other thing is variance among Sally batches. It seems a lot of the trouble is with the later ones, and for a custom board you don't really want to expect the person to have half a dozen CPUs that they can do trial/error on to get a working system.

[+mytek]

I just looked at the Rockwell 6502 datasheet and the rise and fall timing on the clock pins is guaranteed for 1 TTL load plus 30pF, so that's a reason to buffer it.

 

In electronics there's always good enough vs. technically correct. You can often use the signals directly if you don't need to meet the spec and if you've built something and it's stable enough for the intended purpose. But, if you're going to allow 3rd party things to hang on the bus you really should buffer the signals.

 

Only one TTL load... pretty wimpy when you think about all the peripheral chips that normally need to tie into that signal. So in order to do this best, I would think using a very fast gate with a good fan-out would be in order. Obviously a high current capable output would be desirable, but not at the cost of introducing delay. So maybe go with a NL27WZ08 (ON Semi Dual And Gate), which has an output current capability of 24 ma, and 2.5 ns speed rating. Use this as the buffer to feed all PH2 inputs.

 

With such a fast switching speed there would be no side effects to the buffering (i.e., propagation delays).

 

- Michael

[Bryan]

Only one TTL load... pretty wimpy when you think about all the peripheral chips that normally need to tie into that signal. So in order to do this best, I would think using a very fast gate with a good fan-out would be in order. Obviously a high current capable output would be desirable, but not at the cost of introducing delay. So maybe go with a NL27WZ08 (ON Semi Dual And Gate), which has an output current capability of 24 ma, and 2.5 ns speed rating. Use this as the buffer to feed all PH2 inputs.

 

With such a fast switching speed there would be no side effects to the buffering (i.e., propagation delays).

 

- Michael

 

Just remember to check the circuit for overshoot when driving with very fast and powerful outputs.

[+mytek]

 

Just remember to check the circuit for overshoot when driving with very fast and powerful outputs.

 

I'll buy a few and put one on a carrier board that will plug in place of the original 74LS08 chip. Now I just need to get my hands on some good test software to check it out with.

 

- Michael

[+mytek]

The other thing is variance among Sally batches. It seems a lot of the trouble is with the later ones, and for a custom board you don't really want to expect the person to have half a dozen CPUs that they can do trial/error on to get a working system.

 

That is a very good point I've got quite a few chips that I can use as substitutes during the testing, and they range all over the map as far as age and manufacturer. So I'll be sure to give them all a try.

 

- Michael

[+mytek]

Well after testing without a 74LS08 chip buffering the PH2 output from the CPU, it appears that everything works just fine, including a U1MB. However if I try to use a SIDE2 or certain cartridges the system locks up. No surprise really since it appears that the buffering is probably really more about external devices plugged into the bus, and not so much a concern for resident chips on the motherboard. But at least I now have a good handle on what to expect and why. So in my mind the idea of providing FAST buffering of the PH2 signal to all devices that require it makes sense. The reason I say FAST is that I believe some of the twitchy behavior that is sometimes seen, might just be that the buffering although apparently needed and good, is not necessarily good if it also adds excessive propagation delays. Looking at the various Atari A8 schematics, there is a general inconsistency to when and where extra buffering has been added besides the main PH2 signal. Some have PH0 from Antic buffered and some have the GTIA CS decoded output from the LS138 buffered, and then in some cases all 3 signals mentioned are buffered. This makes me suspect that adjustments were being made in an attempt to offset some of the initial propagation delay introduced by the PH2 buffering (which is used on all A8's).

 

My plans are to test with a FAST buffer next.

 

- Michael

Edited January 9, 2017 by mytekcontrols

[+tf_hh]

Hmm, my 2 cents...

 

Don´t change too much. In the last 20 years most of the hardware expansions, enhancements and patches I know of will get instable if trying to change elementary things on the system bus. For example, the "PHI2 patch" (using the unused AND gate (74LS08) to combine PHI2 and PHI0) helps for SOME issues, but also is the source of trouble for NEW issues with special combinations of different expansions. Specially when mixing new technologies (CPLD, FPGA) and old parts some strange issues may occur when patching around the system timings and so on.

 

It´s better to use compatible ways, for example for write access to modern chips, flashes and so on using a shortened PHI2 phase (74xx123 solution), für read access correct driving /OE with PHI2 combined and so on. When the logic is correct and the 6502 system bus parameters hit, then such an expansion works in ANY system (in normal condition). This is easier for developer and user.

 

Jurgen

[+mytek]

 

It´s better to use compatible ways, for example for write access to modern chips, flashes and so on using a shortened PHI2 phase (74xx123 solution), für read access correct driving /OE with PHI2 combined and so on. When the logic is correct and the 6502 system bus parameters hit, then such an expansion works in ANY system (in normal condition). This is easier for developer and user.

 

Jurgen

Can you elaborate on the 74xx123 solution you mentioned?

 

Thank you,

 

- Michael

[+tf_hh]

Can you elaborate on the 74xx123 solution you mentioned?

 

Sure. It´s a tiny circuitry using one half of a Dual Monoflop, i.e. 74LS123 or 74HCT123. Goal of this thing is to create a shortened PHI2 high phase. Normally all chips on a 6502 buss system should be synchronised to PHI2. If PHI2=1, data/adresses are valid. This is the theory In real life there are some special conditions and combinations of CPU and other chips, which hasn´t a exact PHI2 timing. So the CPU changes datalines for example 10-20 ns before PHI2 goes low. Modern, fast SRAMs, Flashchips and so on then will take the wrong data, because they sample the data hold on the databus until the last few nanoseconds.

 

 

Generating a shortened PHI2 phase prevents all write accesses from that behavior. Standard PHI2 phase at 1,77/1,79 MHz is something around 260-280 nS. With this circuitry the new "PHI2S" high phase is only about 170 nS. This is absolutely long enough for all SRAMs, Flashchips and so on produced in the last 20 years. So if the logic of the new project uses /WE = PHI2S AND /RW, then no wrong data will be written. Read accesses should be synchronised with /OE = PHI2 AND RW.

 

I didn´t know who really make this little circuitry first, but it´s very helpful and mostly all expansions with Flashchips and/or external RAM make use of this.

 

Jurgen

 

P.S.: If you ever use this and make the usual correct way of connection unused inputs of the other half to ground or +5V, NEVER do this with C and R/C of the Monoflop! One of these are internally connected directly to GND or VCC - this will make your PCB burn. There´s no real standard, Hitachi differs from TI - I have learned this the hard way...

Edited January 9, 2017 by tf_hh

[+mytek]

 

Sure. It´s a tiny circuitry using one half of a Dual Monoflop, i.e. 74LS123 or 74HCT123. Goal of this thing is to create a shortened PHI2 high phase. Normally all chips on a 6502 buss system should be synchronised to PHI2. If PHI2=1, data/adresses are valid. This is the theory In real life there are some special conditions and combinations of CPU and other chips, which hasn´t a exact PHI2 timing. So the CPU changes datalines for example 10-20 ns before PHI2 goes low. Modern, fast SRAMs, Flashchips and so on then will take the wrong data, because they sample the data hold on the databus until the last few nanoseconds.

 

PHI2_Shortened.PNG

 

Generating a shortened PHI2 phase prevents all write accesses from that behavior. Standard PHI2 phase at 1,77/1,79 MHz is something around 260-280 nS. With this circuitry the new "PHI2S" high phase is only about 170 nS. This is absolutely long enough for all SRAMs, Flashchips and so on produced in the last 20 years. So if the logic of the new project uses /WE = PHI2S AND /RW, then no wrong data will be written. Read accesses should be synchronised with /OE = PHI2 AND RW.

 

I didn´t know who really make this little circuitry first, but it´s very helpful and mostly all expansions with Flashchips and/or external RAM make use of this.

 

Jurgen

 

P.S.: If you ever use this and make the usual correct way of connection unused inputs of the other half to ground or +5V, NEVER do this with C and R/C of the Monoflop! One of these are internally connected directly to GND or VCC - this will make your PCB burn. There´s no real standard, Hitachi differs from TI - I have learned this the hard way...

 

Thank you very much for sharing this

 

 

- Michael

Edited January 9, 2017 by mytekcontrols

[+mytek]

Now for a reality check...

 

So the CPU changes datalines for example 10-20 ns before PHI2 goes low. Modern, fast SRAMs, Flashchips and so on then will take the wrong data, because they sample the data hold on the databus until the last few nanoseconds.

- Michael

Edited January 9, 2017 by mytekcontrols

[+bob1200xl]

Look at the rise time of the input PH02 signal. See how it rises asymptotically? This indicates an output that is pulled up by a passive component, like a resistor, The fall time is much faster, indicating an active pull-down. The more load you have on a circuit, the worse will be the rise-time if you are passive. If you use active pull-up, like CMOS, you may get overshoot, like you see on the output signal. If you don't control the overshoot, you may double-clock fast devices.

 

29ns?

 

Ugh...

 

Bob

[+mytek]

Look at the rise time of the input PH02 signal. See how it rises asymptotically? This indicates an output that is pulled up by a passive component, like a resistor, The fall time is much faster, indicating an active pull-down. The more load you have on a circuit, the worse will be the rise-time if you are passive. If you use active pull-up, like CMOS, you may get overshoot, like you see on the output signal. If you don't control the overshoot, you may double-clock fast devices.

 

29ns?

 

Ugh...

 

Bob

 

Hi Bob,

 

Those readings came from my XEGS which at the time was fairly stock, with the exception of a U1MB being present. When I tested without the LS08 chip in place, at first it appeared to be OK (not the rise time, which still sucked). However when I tried to use the cartridge port things began to go bad very quickly. So yes PH2 buffering is required. However when it causes a delay of up to 29 ns that isn't a very good compromise. So that is the reason for what Jurgen described as the 74XX123 solution, which shortens the PH2 signal (thereby bringing the trailing edge back to where it should be). Of course in my way of thinking, I believe if we could do the buffering with a minimum of propagation delay that would be ideal, and likely fix this problem correctly without the need to resort to additional circuitry to put things back into proper form. On the plus side, getting rid of the propagation delay shouldn't affect operation of the 74XX123 solution either, assuming the amount of active high time for PH2 is still within acceptable parameters for SRAM.

 

- Michael

Edited January 10, 2017 by mytekcontrols

[ijor]

Look at the rise time of the input PH02 signal. See how it rises asymptotically? This indicates an output that is pulled up by a passive component, like a resistor, The fall time is much faster, indicating an active pull-down. The more load you have on a circuit, the worse will be the rise-time if you are passive. If you use active pull-up, like CMOS, you may get overshoot, like you see on the output signal.

 

But this is not the case here. Neither the input PH02 is really passive, neither the 74LS08 output is CMOS. What we have here is on one side NMOS, tied to a 5V pullup vs TTL without pullup on the other side. NMOS output is not normally open drain, but Voh (output high voltage) is at TTL levels. So the signal should be actively pulled up to 2.5V or so, then passively pulled up to 5V. That seems to match more or less the scope picture.

[ricortes]

Interesting stuff Michael. Kind of thought provoking! When I read your first post you had me thinking the 74ls08 was superfluous. Then you did your scope work and as someone who has mixed CMOS and TTL in the same circuit, wouldn't do to have the TTL switching before the CMOS so I like square edges => the 78ls08 is again wanted. Then Bob makes his post about pull up and I start thinking the circuit with the 3k Ohm pull up could probably be tinkered with for a faster rise time. Something like see just how much the PH2 is sinking in a naked circuit and pick something reasonable for that pull up, like a 1k Ohm would probably cut the rise time such that the 74ls08 was no longer needed. Then Ijor comes in with his analysis and I am still trying to digest it!

[+mytek]

Well stay tuned because my super-fast AND gates arrived today, so we'll see how that does

 

- Michael

[+bob1200xl]

I am not convinced that you have a simple timing problem. Moving the PH02 clock relative to data transitions may appear to work, but the real problem is the ringing on the clock line itself. You don't see the true waveform on a scope unless you have a very fast instrument and very high frequency probes. Even then, you need to examine the signal behavior at the input of the driven IC, not at the output of the driver. I have the feeling that some of these off-board circuits are getting really ugly clocks.

 

Bob

[+mytek]

I am not convinced that you have a simple timing problem. Moving the PH02 clock relative to data transitions may appear to work, but the real problem is the ringing on the clock line itself. You don't see the true waveform on a scope unless you have a very fast instrument and very high frequency probes. Even then, you need to examine the signal behavior at the input of the driven IC, not at the output of the driver. I have the feeling that some of these off-board circuits are getting really ugly clocks.

 

Bob

 

Yes that could very well be the situation, and I'll have to sniff around and see. However there is no doubt in my mind that PH2 buffering is a requirement.

 

My scope speed is quite good, rated for 500 MHz (Tektronix), although uncertain about the probes.

 

- Michael

Edited January 13, 2017 by mytekcontrols

[ijor]

Something like see just how much the PH2 is sinking in a naked circuit and pick something reasonable for that pull up, like a 1k Ohm would probably cut the rise time such that the 74ls08 was no longer needed. Then Ijor comes in with his analysis and I am still trying to digest it!

 

Comparing the raise time on the above waveforms is a bit misleading because they have different amplitude. You can see that the upper waveform, that corresponds to the input of the 74LS08, has a much higher amplitude than the bottom waveform. Should be in the order of 5V vs 3V. But what matters is the rise time to somewhere around 2V that would switch any TTL compatible component receiving the signal.

 

If you try to compare then, the rise time from 0V to 2V, the difference between both waveforms is not that dramatic. Still probably a bit shorter on the lower waveform, but not nearly that much. Note that Mike is more concerned about the propagation delay than about the rise time.

[+mytek]

 

Comparing the raise time on the above waveforms is a bit misleading because they have different amplitude. You can see that the upper waveform, that corresponds to the input of the 74LS08, has a much higher amplitude than the bottom waveform. Should be in the order of 5V vs 3V. But what matters is the rise time to somewhere around 2V that would switch any TTL compatible component receiving the signal.

 

If you try to compare then, the rise time from 0V to 2V, the difference between both waveforms is not that dramatic. Still probably a bit shorter on the lower waveform, but not nearly that much. Note that Mike is more concerned about the propagation delay than about the rise time.

 

Yep the output is just following the rules for an LS chip. You aren't going to see it go rail to rail like CMOS. Good observation

 

- Michael

[+mytek]

I decided to take an incremental approach on this (and I'm waiting for some other chips to arrive). So here is a test with a 74HCT08 chip.

 

 

Looks like I knocked about 8 ns off of the propagation delay as compared to the 74LS08 stock Atari chip. And here you can see that both the input and output are going nearly rail to rail, thanks to the CMOS output.

 

To really give this a good test I ran Yoomp off a SIDE2 cart and it seemed to be just fine. I also eliminated the extra buffer being used on the GTIA /CS pin, and didn't notice anything out of place graphic-wise. So basically I am only using the one AND gate PH2 buffer. Of course it would be nice to have a few other PBI devices to test with (oh well ).

 

Next on the agenda is to test with a 74ACT08 and then a 74ABT08 which is extremely fast (1-2 ns rated propagation delay). Should be interesting to see the results.

 

- Michael

Edited January 14, 2017 by mytekcontrols