The Sinclair QL Forum

The 74HC03 has open drain (like open collector) outputs.

I should say that I have not tested this circuit.

Mark

I (was about to) agree about the need for DTACK(l) to be tri-state too, otherwise some chip or other is likely to source or drain more current that they can handle! Didn't realise that HC has open-drain

Coming back to the DSMC(l) point - I see now (that you pointed it out) that the tri-state part is addressed using that 74x125 and that, given that it is working, I guess the speed of effectively disabling the 8301 (or 2?) is still ok with just those two ICS and their inherent propagation delay in the chain.

I had been thinking that using the AS(l) line along with the A18+19 decoder was probably the 'fastest' way to disable DSMC(l) - as far as I recall, AS goes active (low) earlier in the bus-cycle than DS, so it's bound to beat DSMC(l) activating the internal 830x chips when we don't want them driving the bus...

We do need something to assure us that the values on the A18+19 lines are actually valid, don't we? And the fact that the BBQL doesn't even look at AS (as per Nasta) - only at DS (which is slightly later in the cycle) - makes AS all the more useful to us, no?

A moot point anyways, as it's working for you without either! Congrats!

===

Ever-so-slightly off-topic, but has anyone ever played with those 'holes' in the memory map around the peripheral chip register ports? I mean to say, the bottom 32k + top 16k of the second half of the first 256K of the memory map (that was a mouthful...) - it seems such a 'waste' given that this address range was never fully decoded.

Presumably the Trump-Card did something like this, in order to use all three remaining 256K areas up to 1M...

M.

I need to make clear that although It works with no problems so far, I have only tried a few programs that need lot of memory and just one peripheral the Micro P. Disk system so I cannot guarantee, test it yourself before making a PCB or something.

I have seen only one strange thing that I don't think it is because of the upgrade and this is some points like noise on the screen while loading tk2 from the disk and this only sometimes and the toolkit works fine. I think this has to do with the cabling mess or something because it doesn't happen every time. Anyway this is harmless.

Thought:
Even if 18 & 19 are not valid at some point they would be invalid for any peripheral to decode (and for the 8301 also) so there is no problem disabling the 8301 at that point and because AS and DS would be high the ram output would be disabled anyway so it 'll do no harm, is that correct?

martyn_hill wrote:Hi guys
I have a question regarding the driving of the DSMC(l) line - haven't we always been told that a 'fast switching transistor' should be used to drive this line, rather than TTL logic - something about either the latency or else the OC output?
It would certainly simplify things if I didn't have to add a transistor...

The reason why a transistor was used is that the DSMCL line needs to be forced HIGH, i.e. pulled up, not down. Itis NOT an OC output, rather OE (open emitter). However, there are no such chips amongst available standard logic of the time, i.e. TTL families.
The other reason why a transistor was user, rather than, say, a tri-state buffer wired to go into hihg-Z on it's output when the input is low, is that TTL drives asymmetrically. It can only source about 1/5 to 1/2 of the current it can sink. The DSMCL line is actually the CPU DSL connected through a resistor to the DSL input on the 8301 ULA. There is also a subtle clue here - 8301 is responsible for decoding anything on the QL motherboard, and it's qualifying input for this is DSL - it only looks at the address lines and RDWL if DSL is low. Hence ASL is NOT used at all.
Due to asymmetric drive, regular TTL or LSTTL cannot source enough current to 'override' DSL from the CPU on it's way to the 8301 ULA, hence an external transistor was used as an amplifier of sorts, because it's generally cheaper than providing one specialized advanced TTL chip (AS, F or similar family) just to generate DSMCL=high.
Given that HC/HCT logic is more likely to be used, one can take advantage of the fact that HC/HCT drives symmetrically. It has equal and greater than TTL current capability both sinking or sourcing current. Sinking occurs when the output is trying to pull a line low, sourcing when it's trying to pull a line high. With regular LSTTL using a tri state buffer wired to pull high only would not pull DSMCL sufficiently high for 8301 not to recognize it, or rather, the voltage is marginal and therefore one could not be certain what would happen - this is because 8301 inputs are not completely TTL compatible regarding voltage tresholds for input lines. Using HC/HCT there is no problem - there is actually sufficient current available that a HC/HCT output can drive DSMCL high through a regular 1N4148 diode, and even better through a schottky diode like the BAT42. The diode takes care that current can only be sourced, i.e. flow from the HC/HCT output to the DSMCL line. No further tri-stating is needed. It should however br noted that DSMCL must NOT be generated using ASL, or DSL. This will result in DSL to the 8301 being pulled low for a short time before the logic to decode DSMCL high figures out it should be high - because there is nothing but a resistor between the actual DSL and DSMCL, hence no logic, hence no delay. In case DSL was used to decode DSMCL, it would happen on every cycle, in case ASL was used, it would happen on every write cycle. In any case operation of the circuit would be marginal at best. In other words - DSMCL must ONLY be generated from the address lines and RDWL (which is valid at the same time as the address lines. There is a small point of contention which may occur when all the address lines are high that has to be taken care of, but this I will go into if someone asks me
On the last schematic, it is also advisable to use a regular HC(T)00 rather than 03. 03 is not commonly stocked and in fact, it being pull down on the output (i.e. open drain since it's CMOS rather than open collector in it's TTL variant) can slow down decoding of the RAM CS line which you do NOT want. The RAM in question is about 2 generations of IC technology advanced compared to the rest of the QL and it is, in that contest, quite fast. The CPU won't mind DTACKL hanging around a while after DSL goes high but delaying CS with respect to DSL might violate the data hold spec for the RAM - the CPU removes the data after DSL goes high, with sufficient delay due to pull up issues on the CS line of the RAM (relatively large resistor) the fairly slow transition to high on CS might push the point where the RAM writes data to a point where the data from the CPU might start being removed from the bus. Whether this is an issue will depend on the actual type of the RAM as some have more TTL like input line behavior, and others CMOS (different treshold voltages where it recognizes a high level as such).
So, what to do? Use a regular HC(T)00 in the logic and connect directly to RAM CS line. Use a BAT42 when connecting the gate that generates DTACKL to allow the gate to only pull DTACKL low. Because HC(T) pulls down to within millivolts of 0V, the added voltage drop on the schottky diode (about 0.3V) will still make it look like a genuine open collector output (and perhaps better). Granted, a BAT42 is more expensive than a pull up resistor, but a HC(T)03 may not be available (especially in the HCT version) and will be more expensive than the ubiquitous HC(T)00, the most used logic chip ever.

There was also the question of other areas of the memory map that are not fully decoded. Yes, people have used this, the first example being Trump Card. GC/SGC use it as well, so does Aurora (in fact it uses it in more complex ways). There is no restriction on what you can use as long as you 'take it' from the regular decoder in the 8301 by pulling DSMCL high. In other words, you can do this for any address and R/W combination you want - keeping in mind that not all of them make sense in the context of how the QL works.

Oh, one more thing. It is actually possible to implement the required logic using only HC(T)00, though two are needed. One can be used to make a XOR gate, but I'l leave it to you to figure it out

Hi,
I upgraded to SGC and Romdisk and have never had any problems with either.
steve.

stevepoole wrote:Hi,
I upgraded to SGC and Romdisk and have never had any problems with either.
steve.

How is that relevant to this thread?

Nasta - thank you for such a full explanation!

So, in summary, HC family can sink the current needed and fast enough from DS to disable the 8301's DSMC - the transistor approach wasn't necessarily just because the decoding through a couple of ICs wasn't fast enough... To this day, I still remember reading the description of this topic in the CONNEXIONS series of articles in QL World all those years ago!

And those lower I/O areas are up for grabs, again, as long as the 8301 is disabled (which is needed pretty much every where else in the memory map anyhow.)

I'm guessing that the internal I/O area of $18000 - $1BFFF is effectively 'mirrored' every 256Kb through the std QL map, unless the 8301 is disabled as above.

That's put some old mis-conceptions to-bed (for me at least)!

++++
Again, slightly off-topic, but what rule of thumb should one apply for when a solder-less breadboard reaches the limits of something usable for QL interfacing? Is it when a good ground-plane is needed, or signal transition speeds, or ???

martyn_hill wrote:Nasta - thank you for such a full explanation!
So, in summary, HC family can sink the current needed and fast enough from DS to disable the 8301's DSMC - the transistor approach wasn't necessarily just because the decoding through a couple of ICs wasn't fast enough... To this day, I still remember reading the description of this topic in the CONNEXIONS series of articles in QL World all those years ago!

Please read my explanation carefully.
DSMCL is externally pulled HIGH not low, hence current has to be sourced into it (source current into a pin means it's voltage will attempt to go higher, depending on how much of a load is on that line/pin).
And, also, again, DCMSL must NOT be generated using DSL. Actually, let me unpack this: the signal used to pull up DSMCL must not be generated from DSL. This is because the DSMCL signal on the bus is actually equal to DSL - it is the CPu DSL pin passed through a series resistor to the DSMCL input on the 8301 ULA, also known as the MC (main chip), hence DS on the MC active L(ow).
This resistor has a fairly low value, and the load of the DSMCL pin makes practically no difference for the signal before and after it - there is practically no delay. So, DSMCL is actually active LOW and it is the pin on the 8301 that detects that the CPU is performing an access cycle on the bus.
The chip itself does not use A19 and A18 so the 256k of decoded address space actually repeats 4 times within the CPU address map (once for any of the 4 possible combinations of levels on A18 and A19). If one wishes to use an address that is decoded by the 8301 ULA - even if it is one of the repeated copies - the ULA must be prevented from recognising that the CPU is performing a cycle on the bus, and this is accomplished by pulling DSMCL high BEFORE the DSL signal from the CPU appears.
This is why DSL must not be used to generate the DSMCL pull-up signal - whatever logic is used will by definition be too slow as it will, unlike the resistor, have a delay.
Fortunately, the address lines (and RDWL) become stable well before DSL so an external decoder has time to decode if DSMCL must be pulled up for a given address. Of course, there are constraints so the decoder must be fairly fast - however, keep in mind we are talking 1980s standards.
Back then, LSTTL was he norm and it had the problem of relatively low current sourcing. So, what would happen? While the CPU was trying to pull the DSMCL line low through the series resistor to DSL, pulling DSL low, TTL logic would attempt to pull DSMCL high. However, the CPU signal lines are internally CMOS and capable of fairly high sink current. LSTTL has effectively a built in resistor in it's output that limits the output current. Hence a tug-of-war results and the DSCML line ends up at a voltage that is right in the undefined zone where it could be recognized as either low or high.
To solve this, an external transistor is used to help out the DSMCL decoder. It has to be fairly fast not to add to the overall delay of the decoder.
Nowadays, using HCMOS logic, there is enough current available for the decoder to win that fight, through a simple diode (to insure that current is only sourced from the decoder). Of course, other configurations are possible, for instance, programmable logic makes it possible to create pull up outouts so these could be used directly. Also, nowadays the decoding can be very fast, even too fast (and could catch gliches in the states of address lines as real legitimate states).

And those lower I/O areas are up for grabs, again, as long as the 8301 is disabled (which is needed pretty much every where else in the memory map anyhow.)
I'm guessing that the internal I/O area of $18000 - $1BFFF is effectively 'mirrored' every 256Kb through the std QL map, unless the 8301 is disabled as above.

Yes - everything is mirrored every 256k.
Also, some parts of $18000..1BFFF are officially 'taken' - the first and last 256 bytes.

Again, slightly off-topic, but what rule of thumb should one apply for when a solder-less breadboard reaches the limits of something usable for QL interfacing? Is it when a good ground-plane is needed, or signal transition speeds, or ???

[/quote]
That's a very broad question, well out of the scope of this thread. In any case it's a matter of neat and tight construction and when a certain wire lengt is reached, a ground plane is mandatory

Thanks once again Nasta!

(and apologies to lliont for effectively sabotaging your inspirational initial post!)

I think that clears it up for me! Back to the drawing board.

And lliont - good luck!

Thank you all for the info.
Martyn your participation is welcomed.

The circuit I'm currently using and I think will be the final for me is the following:
With this last version made after the advice from Nasta and 1024MAK there is no noise on the screen anymore when loading tk2 and it works fine after more tests I did. One last improvement one could make is to use 74LS00 instead of 74LS20 or in the above diagram to connect pin 8 of IC2 to 2,4,5 pins of IC4 and leave pin 3 of IC2 to connect with the IC4 only on pin 1.