An Enhanced MK14 (MK14E)

[ChrisOddy]

Not sure how useful these spare gates are as they are not inverters but buffers ?

[ortek_service]

Originally Posted by ChrisOddy

Not sure how useful these spare gates are as they are not inverters but buffers ?

I'd just read they were inverters, from the previous post saying they were.
So may not be quite as useful if only buffers, but maybe no harm in having some zero-cost track / pad options, in case their extra delay / buffering may turn out to be useful to have somewhere.

[ChrisOddy]

I've just finished building the MK14E VDU board and the picture is looking good, graphics and characters, invert etc working and no jail bars !

Unfortunately I have spotted a problem, the first byte of screen RAM is being written to, $0F which is the default data bus 'value' given that there are pullups on D0-3? Looks like my low risk bit of gate swapping has upset something ! This must be a NENIN timing issue which has been mentioned on the forum before.

Chris

[Realtime]

Chris, does your MK14 have a pull-up on nWDS (it's not a standard fit)? I found I had to add a 1K pull up as part of the solution to memory corruption on RealView. Between bus cycles nWDS floats and can result in an unwanted write. Worth a try. I think it was an over site on the part of Science Of Cambridge. Nat Semi reference designs of the day include pull ups on nRDS and nWDS.

Good news that it's working other than that. The on-board character generator is a nice solution to the obsolete DM8678.

[ChrisOddy]

Yes I have 4K7 pullups on NRDS and NWDS on the main MK14E board. I did also wonder about adding pullups on the remaining data bus lines as well, it would at least make them look nicer on a scope !

I'm in the process of reverting my original (replica) VDU as it has several breadboards attached and a host of mods as it was my prototype MK14E VDU.
I should then be able to compare NENIN etc between the two.

I had a look at the circuit and the gate swapping, as far as I can see it should not have made any difference to any delays ?

[ChrisOddy]

Found the problem, it was down to the 4011 NAND gate that drives the NENIN transistor. On my original board I had used an RCA device and by chance picked a Toshiba for the new board and that significantly affects the RC delay ?

Really the whole thing is a bit iffy being dependant on gate delays and then an RC, NENIN could end up anywhere !

Anyway looks like the MK14E VDU is finished so next to see if I can get NIBL-E running and writing to the VDU.

[ChrisOddy]

I've been having a further look at the workings of the VDU.

The address buffers are enabled for 32uS for each line during a frame, NENIN is raised ~30uS prior to that to gain control of the bus. I assume this gives time for the CPU to respond by raising NENOUT but of course the VDU ignores that and carries on anyway !

The additional 30uS delay is provided by clock Q2 from the 4040 and is combined with the 32uS enable signal by the 4011 driving the NENIN transistor. However a small glitch occurs between the two, momentarily lowering NENIN, hence the RC to extend the Q2 clock. In fact on my original replica board there is still a very small glitch (~300nS) which I assume the CPU doesn't quite respond to ?

When I used the Toshiba 4011 it must be loading the RC more than a 'proper' RCA device and the glitch extends to nearly 800nS enough for the CPU to take the bus back. Tweaking the value of the C removes the glitch.

I'm still wondering what on earth the 74L86 and double 74LS04 buffers are achieving, the additional delays (50nS and 20nS respectively) are so small as to make little or no difference ? I might have a go at removing them and see . . .

Chris

[SiriusHardware]

Sounds like you are intent on taking Occam's Razor to the original design to see just how much it can be pared down. We may never know why the original designer (possibly Nick Toop?) did it the way he did and the approach may have very much depended on availability and knowing Sinclair, cost, of parts.

I suppose the delay following the assertion of NENIN is meant to be long enough to accommodate the longest possible time it will take the SC/MP to get off the bus, so in theory it isn't necessary to look at NENOUT to confirm that it is safe to venture onto the buses, although it would have been tidier and more efficient.

That's interesting to hear about the choice of 4011 being quite critical, though.

[ortek_service]

Originally Posted by ChrisOddy

>>
When I used the Toshiba 4011 it must be loading the RC more than a 'proper' RCA device and the glitch extends to nearly 800nS enough for the CPU to take the bus back. Tweaking the value of the C removes the glitch.
>>
>>
Chris

I recall many years ago (Keith Armstrong?) telling us on his EMC courses , that IC manufacturers often did 'die-shrinks', where they re-made original logic IC's etc. using more-modern sub-micron semiconductor processes that (as well as meaning that got more on a wafer, so cost each would be less) meant their performance was also often different.
- Usually 'better' / faster, but the higher slew-rate could then cause EMC problems where the older more-sluggish ones hadn't. But there may be no changes to package markings or the datasheets (if they only state min. speeds and didn't have a maximum).
So maybe the more-modern Toshiba one is responding much quicker to input changes / glitches, although it may also have different / faster propagation delay specifications than the original RCA ones.

Although I do recall even back in the 80's, that some makes of 4000/4500 were required (eg Mullard), as other makes didn't work.
I encountered this trying to use a (cheaper) Motorola MC14534 in place of a Mullard HEF4534 5digit counter in an Everyday Electronics Digital Capacitance project. But when I actually got a 'scope to it, I found they were feeding a rather bad clock waveform to it, so added another buffer gate to square it up, and that seemed to help make it work better so I suspect they too had a rather-marginal 'bad design' and were running things at / beyond the edge of the IC's specifications.

[ortek_service]

Originally Posted by ChrisOddy

>>
When I used the Toshiba 4011 it must be loading the RC more than a 'proper' RCA device and the glitch extends to nearly 800nS enough for the CPU to take the bus back. Tweaking the value of the C removes the glitch.
>>
>>
Chris

It might also be that there is some variation on the exact input voltage, between 1/3 and 2/3 of supply, at which the gates switch between low & high.

My CMOS Pocketbook gives a single 60ns @5V (25ns @10V) propagation delay for 4011's with 16 manufacturers of it listed.

A 4050 Non-Inverting buffer is listed as basically being the same: 60ns @5V (30ns @10V). With a 4069 Inverter as 50ns @5V (25ns @10V)

So all propagation delays quite-short, compared to the 800ns glitch.

[Mark1960]

I try to avoid CD4000 cmos in 5v systems. The propagation times from your cmos pocketbook are quoting only typical times. Max propagation time is more than double the typical time. Also the propagation time does not include the transition time and is only measured at 50% of the supply level, rather than the 1/3, 2/3 logic level input thresholds. Transition time is similar to propagation time so can make a significant difference. RC delays on the input could also cause a problem due to slow input transition time, causing both the input transistors to turn on.

Trying to rely on gate delays when you want a signal delayed is a bad idea, the minimum delay can vary a lot between devices and with temperature. RC delay into schmitt trigger inputs is probably a better method.

[Phil__G]

I was just putting my Retrofest stuff away and looking at the MK14 keypad had a thought - is it time to change Term & Abort to Data & Address?
No?

Ok

[SiriusHardware]

It would be good to travel back in time and remonstrate with whoever decided upon those command key legends originally, but they probably made sense for whatever it was that the National Introkit's add-on keypad was originally designed for. (The Introkit's keypad has the same Go, Mem, Abort, Term command keys of course).

As I understand it the aim of the MK14E is to offer an MK14 which:

-Does away with the exotic RAM and PROM memories and replaces them with more mainstream devices so that anyone who wants to can build a functional replica for a much more reasonable price.

-Provides quite a bit of extra memory onboard, which at one time would have had to be added offboard, and allows the memory to be configured in either maxed-out or in a legacy compatible array, with certain of the 'images' retained.

-Makes all the main bus signals available on the rear edge connector (much as the Issue VI did).

-Etc, etc, so it is basically an MK14 'Gti'

-...But is still recognisably an MK14 and immediately usable by anyone who remembers how to use one. So, I'm afraid for the purposes of familiarity and nostalgia, those non-intuitive command keys have to stay.

[ChrisOddy]

I've made a start on a QWERTY keyboard for the MK14E.

Bear in mind that this is not supposed to replace the standard keypad but is laid out to simplify reading the matrix and generating ASCII codes e.g. for NIBL.

With a 4x10 matrix its pretty limited what you can do. By the time you take out the 10 numeric and 26 alpha keys, Space and CR there are only 2 left.

I've included two shift keys (left and right) in parallel that leaves one key which could be used for as an additional 'shift' or 'function' key I think like the ZX80/81 ? (currently shown as 'spare')

Chris

[SiriusHardware]

I think a lot of the 'extra' characters can just be shifted 'standard' keys just as they are on PC keyboards. ' " ' = shifted '2', ' ^ ' = shifted 6, ' & '=shifted 7, ' ( ' = shifted 9, ' ) ' = shifted 0, and so on. When the presumed lookup tables to convert physical key matrix positions to characters are being developed it would be useful to retain as many of these traditional symbol / shifted symbol pairings as possible so that keytops from off the shelf PC keyboard sets can be used.

[Mark1960]

Adding shift or function keys might mean you need to add diodes to each keyswitch, if more than one key is pressed you might not be able to detect which combination of keys is pressed.

The keyboard input on the MK14 is read using a hex tristate buffer, if the two unused buffers were used you could have a 10x6 matrix. Extend the keypad edge connector by two contacts at one end to stay compatible with existing keypads.

[Phil__G]

Maybe use the same layout as the RC2014 Universal Micro Keyboard, which is also 40 keys?