An Enhanced MK14 (MK14E)

[SiriusHardware]

If you are referring to the 'jail bar' effect I can think of no reason to emulate or retain such an obviously undesirable artefact and I think it should be eliminated if possible. OrtonView and RealView don't have it and are all the better for it. For the 1-pixel character shift I see no reason not to try to do as the original circuit did.

[ortek_service]

Yes, if the 'Jailbars' are fixed by Ortonview / Realview then does make sense to fix these in this 'VDU-E' version.

I was actually referring to Chris's original question about the 1 pixel shift, that I thought it would be nice to be able to correct - especially as Chris had already done & proven this, without having to add extra logic IIRC.
But if Ortonview / Realview don't fix this, then maybe keep it the same for consistency (Although still useful to provide the info, for anyone who did want to use the display without the shift).

[SiriusHardware]

I haven't looked into it but I would have thought that the character generator would try to generate black space both to the left and the right of the character. Although in the case of the MK14 the 'border' outside of the active screen area is the same colour / shade as the character background the designer of the char gen IC may have chosen to assume that this would not necessarily be the case, so maybe they placed a 1-pixel leading black space ahead of (to the left of) the character and a 3-pixel trailing black space after (to the right of) the character.

That way, any characters on the extreme left of the active display area would still be slightly separated from the surrounding 'border'

[Phil__G]

Whats the plan for the 'E' keypad Chris, Ian L's Cherry keypad looks good

[ChrisOddy]

I was going to stick with the same keypad as I used on my replica MK14 but then add a QWERTY keyboard using Cherrys.

[Phil__G]

Nice

[ChrisOddy]

On the subject of a QWERTY keyboard for the MK14, I know you guys have already been doing some work on this and used a matrix that matches keys with the existing keypad however I wonder if this is what it would have been like ?

The ZX80 has a similar 4x10 keyboard matrix so did they base this on the MK14 keyboard that never made it to market ? The matrix is a simple x/y based on the position of the keys.

[ortek_service]

Originally Posted by ChrisOddy

On the subject of a QWERTY keyboard for the MK14, I know you guys have already been doing some work on this and used a matrix that matches keys with the existing keypad however I wonder if this is what it would have been like ?

The ZX80 has a similar 4x10 keyboard matrix so did they base this on the MK14 keyboard that never made it to market ? The matrix is a simple x/y based on the position of the keys.

Unfortunately, Whilst the ZX80/81 (& Spectrum) all had a physical 4 rows of 10 keys, they are actually wired-up electrically as 8 x (half-rows of 5 keys).

Which on the ZX80 circuit is scanned by making each of the 8 scan-drive outputs to the matrix, connected to address line A8', A9 to A13, A14' & A15' low, in turn, then reading the 5 lines (With pull-ups on these) that go to the datalines D0..D4, via a 74LS365 Hex-Buffer (Enabled with nKBD low). See: https://www.8bity.cz/files/zx80_schema.pdf

(On the ZX81 & Spectrum, their ULA incorporates much of the keyboard-scanning circuitry, so not as easy to see what's going-on from the schematic alone)

So this is more-efficient on total number of matrix lines: only using 8+5=13 lines, rather than 4+10=14 lines.
But is rather incompatible with the MK14's hardware, without modifying it (and the SCIOS routines) quite a bit.
Although you could maybe use a small uC 'Keyboard Co-Processor' (Like PC keyboards have), to interface between two different systems.
With early ASCII-Output Keyboards effectively having an ASIC to do that.

[SiriusHardware]

We were looking at a scheme which placed the QWERTY 0-9, A-F, G, M , T keys at the same intersection points as they are in the standard 20-keypad matrix so that the QWERTY keypad at least did something before any additional software was loaded. With 'A' already allocated to hexadecimal 'A', some other key, like ESC, would have to be mapped to ABORT.

If you were going to put a microcontroller between a QWERTY keyboard with a relatively standard matrix and use that to translate between the connections of the QWERTY keyboard and the standard martix, you could just, as I have mentioned before use the microcontroller to interface with a PS/2 keyboard which is already ready made and wired up. There must be thousands of them still dodging landfill.

[ortek_service]

Yes, a PS/2 keyboard interface would probably be cheapest - And what's been done for Nascom's etc, where original keyboards are rather difficult to find.

But I suppose not that retro-looking as using a ZX80/81 (or even Spectrum one)
- Although any old PC keyboard would be rather better to do any typing on, and much easier to obtain (could even buy them new for a few pounds, although the lettering often rubs off after a bit of use, on many of the white-on black smooth top surface ones).

However, getting hold of Sinclair keyboards may not be too easy / cheap. Re-made membranes maybe available, but would really need something better over these, to make typing better
- Actually most PC keyboards now use a membrane, but with a metal plate below and individually-sprumg keytops above these, so they don't generally feel like the old Sinclair etc. membrane ones and more like proper keyswitches.

[Phil__G]

The RC2014 universal micro keyboard is a well-documented 2x4x5 matrix - the arduino code is a readable guide for DIY
https://rc2014.co.uk/full-kits/unive...icro-keyboard/

[ChrisOddy]

I've fixed the 'jail bars' fault by fitting a CD4050 buffer in the clock to IC16 (pin 2), this additional nominal 50nS in the clock prevents the extra clock pulse at the start of a block of 8 pixels occurring before the load signal.

You could probably implement the fix by putting a small RC delay on pin 2, 1K and 47pF ?, though I haven't tried it.

I've replaced the 74LS86s (74L86 replacements) with CD4050 buffers and that seems to be fine.

I've now moved to using a 2732 for the character font and because there's plenty of space I've added ZX80 and ZX81 fonts in addition to the original 8678CAB and ASCII fonts with space to spare, all selected by links.

Just finalising the control signal links (B9-b17) then it should be finished ?

[ortek_service]

Originally Posted by Phil__G

The RC2014 universal micro keyboard is a well-documented 2x4x5 matrix - the arduino code is a readable guide for DIY
https://rc2014.co.uk/full-kits/unive...icro-keyboard/

Thanks for info on this - I've not built an RC2014 yet (but have been considering one), although I have been recently finally completing an Z80 'MBC2' SBC +ARM uC 'uTerm' VGA / PC Keyboard Interface, so I've not really looked into small keyboards.

If matrix is the same as a ZX80/81/Spectrum, then could probably use as is, without a uC - And I just happen to have a ZX80 (now working after replacing a missing IC) PCB I got for 10p, but with no keyboard because soimeone had sawn it off!

I did buy a similar-looking 'TM1638' based PCB for < £5 assembled, from China. But these only had 16 (of the same-size switches) Keys and I couldn't find any larger ready-built ones

[Timbucus]

Just a reminder that the definitive letter on what was planned for the keyboard is here

https://www.computinghistory.org.uk/...Update-Letter/

Click on the picture and the PDF will load the two page letter.

[ortek_service]

Originally Posted by Timbucus

Just a reminder that the definitive letter on what was planned for the keyboard is here

https://www.computinghistory.org.uk/...Update-Letter/

Click on the picture and the PDF will load the two page letter.

Yes, I recall previously seeing that. And just re-reading the only mention / details of the planned (but never actually released) keyboard, copied below:

"40 way keyboard, this is to be run directly from the 14 way edge connector on the side of the MKI4, a new monitor is provided which tells the processor to recognise and respond to all 40 ways that the present 4 x 10 matrix can allow. Forty keys can provide all the alpha numeric characters."

Then it's still a little vague whether the new SCIOS Monitor (V3? - Also never released, until a different 'V3' we now have >45yrs later!), would have been compatible with the original keypad, or whether they 'started-again' with the Alpha-Numeric Keyboard Matrix, to make the matrix connections a bit easier to implement / more-logical for a standard QWERTY-layout.

They also say in this (no date on it but website says 1978) "Some of these will not appear until March next year, but we hope to bring out the V.D.U. in January at which time we are publishing a book called Programming with the MK14, a highly detailed guide to programming which will cover programming for control applications and will have sections concerning the above mentioned peripherals."

So I wonder if that book ever actually appeared (in Jan'79) and gave details on all these planned peripherals?


Before the above, they also said "The revised monitor proms are now issued as standard and another monitor is available for those who wish to link the MK14 to a teletype terminal."

- So if the "revised monitor proms" were V2, then was this 'another monitor' for linking to a teletype actually 'V3'? / 'V2B' ?
. Or was it just the original NS (Ibtro)KitBug, that required a teleprinter (or 'Glass' Teletype) ?


I also note some other planned (but never actually were?) releases:

"2K memory extension card, instructions exist for the adjustment of Issue 1, 2 and 4 hoards to accept this and issue 5 boards are already capable of expansion."

"Basic language board, this board will only’be reasonably used in conjunction with the V.D.U. and the 40 way keyboard described next. The language is a 4K basic known as NIBL, a language particularly useful when programming for industrial applications."

So it seems using NIBL (Before/after Elektor NIBL-E?) on an MK14 was planned - Despite all the original Memory-Map images.
And was the 2K memory expansion card also actually needed, to provide enough RAM for BASIC programs (and maybe solve some of the RAM-imaging?
Or was this BASIC language card also going to have extra RAM / replacement for original imaging-RAM ?
Also, was (a customised?) NIBL to run directly 'bare-metal' on the hardware, or is an (SCI)OS still needed to deal with Keyboard input / display?

[circuitryboy]

National Semiconductor 'Introkit' originally came with ROM "KITBUG". Which 'talked' teletype.
Then 'SC/MP Keyboard Kit' was available with a calculator connected as keyboard/display and a new ROM monitor, "SCMPKB".
SoC initially supplied MK14 with "SCMPKB". So had to replicate the keyboard matrix used in that calculator. Once SoC decided
to split the data bus down both edges of the board Nat Semi doubtless supplied pre-programmed M74S571 pairs.
SoC then (really did) improve the monitor to the one and only "SCIOS". This is "the revised monitor".
The "link....teletype" monitor is original "KITBUG".

[ortek_service]

Well if SoC were just supplying the original (NS Intro) "KITBUG" (but now in two PROM's rather than NS Introkit's original ROM), then that's really two versions backwards compared to SoC's later "Improved" version of SCIOS (V2, which added cassette support) and a version back from (NS Introkit) SCMPKB (= original SCIOS "V1") that NS had enhanced relative to "KITBUG".

So I would have thought it would have been better to start with SCIOS "V2" and substitute the Keypad / Display routines with the original "KITBUG" Serial Interface routines.

[ChrisOddy]

I've finished the MK14E VDU so an opportunity for any minor changes before going to manufacture ?, please see attached schematic and top view of the PCB.

I've kept as much of the original VDU as possible, the significant changes are:

• dropped the modulator and added a video output (phono)
• DM8678 replaced by EPROM
• 74L86 replaced by 4050 with similar delay (in two places where it matters ?)

I've also changed the graphics shift register for one with a synchronous load as this was causing problems with aligning characters and graphics and has also fixed the 'jail bars' fault.

The logic that drives the memory access/CPU is unchanged as I didn't want to risk messing up some critical timing though a fair bit of gate swapping has taken place to help with the layout.

I've added links that allow selection of configuration signals that should cover most requirements and if that's not enough both the 8154 ports are available.

Page Select has been extended to add the upper four address lines ready for the MK14E, though the board should still work fine with an original MK14.

Chris

[Buzby123]

You show the four unused gates in the bottom left as connected to 0v. This is good practice, but I would suggest you give each input a jumper to allow disconnect from 0v, and put the outputs to pads.

This makes it easier for anyone who wants to twiddle things to use those inverters without chopping tracks.

[ortek_service]

Rather than extra-hassle of normally always having to fit jumpers to tie unused gate inputs, an alternative is to still have pads on the unused inputs & ground for a jumper or wire link - But then have a thin track between these, that could be cut neatly, if needing to isolate the inputs to use them for other uses. Pre-jumpering with a thin 'default' track has been quite commonly done commercially, and back then by the likes of Acorn on their 'System' boards / some links on Beebs.
And having pads as well, does make it much easier to patch to other areas / restore tie to ground, if wanting to restore original track link.

Another alternative, for cost of a few resistors, is to just fit pull-ups on each of these (Which would then make inverter outputs low, so less liable to damage if they got shorted to ground) or pull-downs. Which you might be able to leave in place, if high-enough value, when connecting inputs elsewhere.