MK14 schematic revisions

[Slothie]

Well I did a little happy dance for you Tim, well done. Seems like I can assume there are no major issues with the v6 board, and it's capable of working with the Sinclair VDU. Thanks for the tribute on the screenshot!'

[SiriusHardware]

Well done Tim. I really was otherwise engaged for the afternoon, but I was pretty sure you would have drilled your way through to the heart of the problem and so you have. Of course I never had that problem because mine has always had a modulator and has mainly been used with a 'period correct' B&W portable TV which I keep for use with this and the ZX81s. It does also give me a brilliant picture on my Philips CM8524 CRT monitor if I jump the composite signal across from the input of the modulator to CVBS-in on the monitor.

Now that you have it going you can probably see what I meant previously about the text character lines being far too close together, it should only really be regarded as a 16-line display for any purpose other than ASCII art, perhaps.

For the character set, one of the programs provided in the VDU manual prints all of the MK14 VDU's characters in sequence and for the original S.O.C. supplied CG IC that character set is as per the table you have just reposted. However I'm not sure if the substitute char gen ICs supplied by Martin L have the SAME character set, that will be one thing we will need to find out.

Now that we have at least one actual working MK14+VDU combo to talk about maybe discussions about using / connecting / programmming that should continue in the VDU specific thread which is still lying around here somewhere.

I will make a short adaptor PCB to connect mine, I'll probably just cut two short lengths of 32 way wide stripboard and solder them non-copper sides together to make double sided stripboard, and then solder an edge connector on one end and a DIN connector on the other. I can then do any necessary mods on that short link PCB, such as cutting the EXCLOCK track at the same place on the top and the bottom, then feeding a wire through the drilled cut to carry the EXCLOCK signal from the lower side to the upper side. I can also add the pullup(s) on that PCB, and even another 7805 regulator to give the VDU its own independent 5V supply.

What's really needed, though, is everything I have just described above with some memory on it as well, mapped at 0200-07FF.

[Timbucus]

Agreed we will switch to a VDU thread for the next steps...

Although development of memory will probably happen here...

And for those following...

I did also modify mine to lift B13 (from PA0 as I planned) and put it over to FLAG1 as recommended by the manual and Martin actually. Then you can just enter 02 into FFF and hit GO to turn it off. I have done a version of SEND14 that does this just after the RESET so that you can still download programs... This also means in the absence of an INS8154 the system is very usable. I suppose FLAG2 would be the Graphics and Text switch most usefully as the tape uses Flag0. I may just do that - the other stuff will remain permanently wired I think on my Virtual INS8154 - I may even squeeze two 9111 RAMS on a little board...

For send14:

KeyPressLength=0.006
KeyReleaseLength=0.008
ModeChangeSettleTime=0.01

and just after the reset

    # That will have enabled any VDU so we need to disable
    # Note we have to use a very long delay in this case....
    print ("Disabling any VDU... (Flag1=1)")
    time.sleep(ModeChangeSettleTime*4)

    Press_MK14_Key('F')  # Enter FFF
    time.sleep(ModeChangeSettleTime)
    Press_MK14_Key('F')  # Enter FFF
    time.sleep(ModeChangeSettleTime)
    Press_MK14_Key('F')  # Enter FFF
    time.sleep(ModeChangeSettleTime)
    Press_MK14_Key('t')  # End address entry - works same on both OS

    # Allow settle time after mode change
    time.sleep(ModeChangeSettleTime*2)

    Press_MK14_Key('0')  # Enter 02 to set FLAG1 to 1
    time.sleep(ModeChangeSettleTime)
    Press_MK14_Key('2')
    time.sleep(ModeChangeSettleTime)
    Press_MK14_Key('g')  # No execute - starts monitor setting Flag1 to 1
    time.sleep(ModeChangeSettleTime)

Here is the bottom of the VDU PCB with the patch to Flag1, the move of B15 to B8 (for page swap onto PA3 as it joins to INTR otherwise)... You can also see the Pullup for NWDS... and my notes on creating the virtual INS patches.

[SiriusHardware]

In fact the 8154 was an option, not standard fit, so the VDU manual assumed you might not have an 8154 fitted and used the flag outputs to control the main VDU functions. I think it was only when this notion of hard-connecting the two PCBs together came up that we noticed that nearly all of the VDU control inputs or status outputs landed on I/O pins, so that was why we were originally thinking it would go that way.

I like your ingenious send14 mod, you realised that with the VDU enabled, the key presses for entry of the address, data and GO command needed to be a lot longer and ploddier. If you modified all of the uploader timing that way it would no doubt work even with the VDU running, but it would have to run a lot slower for all the keypresses to register.

Actually the same principle (slow entry and execution of some code prior to the real upload at normal speed) could be used to set the 8154 data direction registers and output the necessary port state patterns to turn off the VDU and set up the VDU display mode, address select lines etc.

Code loaded into the lower part of the I/O IC RAM can access the I/O port registers directly with a 'ST' (Store) instruction. This setup code would need to end with a jump to 0000 so that when executed it would set up the I/O port states and then return control to the monitor without doing a hardware reset, which would otherwise clear the I/O port pins back to their default state.

Actually better still, just have send14 enter the values for the I/O port DDR and Data registers directly into the addresses of those registers as per the method I outlined ages ago when you thought your original 8154 was dud - can't remember exactly where that post is.

[SiriusHardware]

Here we go, using the monitor (new version) to turn off the VDU - if controlled by the 8154 - by making PA0 an output and setting it high. It is no more difficult to use send14 to do this than it is to use it to set Flag 0 high.

Abort
0 8 2 2
Term
01
Mem

You won't see the data digits change, but doing the above writes 01 to the port 'A' data direction register to define PA0 as an output. Then, write 01 to the data register to set PA0 high and turn off the VDU.

Abort
0 8 2 0
Term
01
Mem

You can obviously also set the other Port A pins to outputs and set the other VDU control lines to sane states at the same time.

[Slothie]

Tim, Sirius - any objections to me placing some of the photos from here on my Facebook page? Fully credited of course.

[SiriusHardware]

Of course no objection from me - go ahead. S.

[Timbucus]

None from me use what you like!

[SiriusHardware]

Now that we know the Issue VI rev 1.2 PCB works well, it is worth reviewing what, if any, finishing touches might need to be made before any more are made.

As far as I can see they are mainly cosmetic (screen printing).

-Make the chip outlines more conventional with a distinct notch to show chip orientation.
-Separate the U11 part number and chip type number, currently overlaid on one another.
-Add polarity symbols to capacitor C6 outline
-Move the U6 part number to the right hand side of the chip outline to match the rest.

Also

-Route the NENOUT signal to the rear edge connector.

-Consider removal of keypad dome contact pads and replacement with layout for an alternative type of switch (Cherry?) alongside the existing tact switch pads.

[Timbucus]

- Maybe consider space for the needed NWDS pullup for the VDU - it could always remain unpopulated if wanted.

- On the screen printing move the Key functions out the way (centred at top?) so you can still see them when the switches are fitted - it looked cool with just black key tops and makes it still usable without any printing.

-change the screen from 7805 for authenticity...

- consider what is needed back inwards to disable onboard memory/PROM/IO when external pages >1 are latched and used.

I wonder if the Dome pads could be retained even with both switch allowances - as you can still get them and someone may want to get an authentic looking one.

[SiriusHardware]

I think the problem with using domes is then finding an overlay - Martin L's are the obvious ones to use, but I don't think Slothie had an original PCB to make measurements from, therefore the spacing on these keys may not match up well with Martin's overlay which is scaled for the key spacing on an original MK14, issue V of which his PCB is an exact scan or clone.

Therefore, if you are going to retain / improve the pads for dome contacts then it might be best to take the opportunity to also get the keypad positioning and spacing historically exact. As you (Tim) have an unbuilt Martin PCB, now might be a good time to scan / photocopy it so that its keypad can be used as a position / scale template for key spacing on any future revisions of this one.

[SiriusHardware]

- consider what is needed back inwards to disable onboard memory/PROM/IO when external pages >1 are latched and used.

I think that will be more likely to come in a future V2.0 version on which I would also like to see a change to more conventional 8-bit wide RAM and EPROM memory. By that point you're going well down the road of MK14man's noughties MK14 reproduction, but still hopefully only using reasonably 'historic' ICs, no FPGAs etc.

[Slothie]

I believe the spare gates on the board may be sufficient to provide a signal to disable NRDS and NWDS for on board devices thus permit multiple pages, but without my laptop I can't be certain. I would like this signal for a NIBL board I'm thinking of.
As far.as the switches are concerned the domes require a central contact in exactly the position the MX style switches have a locating pin that required a hole. Admittedly this pin could be cut off but I'd rather not as it ensures alignment. So it's dome switches or Cherry switches but not both.
I'd really like high resolution scans of an original board or close replica as I'd like to get the dimensions of the keyboard and spacing etc as I just took measurements off some grainy photos and compared them to the size of nearby ICs. The same went for the overall board size - it would be interesting to know how close I got!! Also one of my intended software projects is a program to take images of PCBs and make gerber files for them. Mostly for all those lovely projects in ETI and Elektor etc that have gorgeous hand drawn PCBs.

[SiriusHardware]

Originally Posted by Slothie

The same went for the overall board size - it would be interesting to know how close I got!!

Well, here we have the rare sight of my issue II MK14 (almost) as nature intended, side by side with your issue VI.

You got pretty close with both the length and width, perhaps 6mm wider and 5mm longer than the real thing. Not bad at all.

Don't be too alarmed by how much more closely packed my keys are than yours, the spacing of those keys is determined by the fact that they are inserted and soldered into veroboard underneath the black 'skin' I laid on top. However I will say that I think the real key positions are slightly closer together than on yours. I prefer not to remove the keypad as the row / column wiring is quite short and tack-soldered onto the tracks below to keep it looking neat, so there's no clear line of access to take measurements with a ruler. Tim's unbuilt issue V clone is definitely your best hope for a scan or photocopy.

If Tim does do that I would suggest laying a ruler along one edge while the scan or photocopy is taken so that you'll always be able to tell when the image really is actual size - just increase or decrease the size of the image on-screen until the size of the ruler on the screen is exactly the same size as an actual ruler, then you know the image on-screen really is actual size and can make measurements from it.

[Timbucus]

Nice - the NIBL Board is why I want to do so as I am sure SoC (Nick Toop at least) had a working prototype as he published a NIBL program and their letter mentions a BASIC addon to go with the 40 key keyboard - which I also want to build with a built in PI0 programmer feature - seems the ideal place for one.

Your PCB is just slightly larger than the JMP and Lukasek ones 5mm longer and 7mm wider - the other two seem identical with the same component layouts so I assume they are based from scans of actual machines. These two photos should give some indication of how minor the variations are...



I like the sound of your scanning PCB's there are several I want to make - maybe even the Elektor SCMP system... Definitely S68 but, with a SC/MP CPU card

[Timbucus]

Lovely picture Sirius - they look great together...

You are correct I should have included a ruler... so here it is:

[SiriusHardware]

I forgot to agree that the Elektor PCB art always was actual art, I would have been quite happy to hang one of their larger PCBs on the wall. A bit of software which can capture PCB art into a digital format sounds amazing.

[Slothie]

Considering I was basically estimating the size and position of everything I really do seem to have got it close! Even the chips are in roughly the right place. It looks like if I move the keys closer vertically so the caps almost touch then they'd be in the right position. Probably the best idea would be to get the JM keyboard and use that to get the hole position and layout correct, so they'd be no reason to reinvent the wheel.

[Timbucus]

Originally Posted by Slothie

Considering I was basically estimating the size and position of everything I really do seem to have got it close! Even the chips are in roughly the right place. It looks like if I move the keys closer vertically so the caps almost touch then they'd be in the right position. Probably the best idea would be to get the JM keyboard and use that to get the hole position and layout correct, so they'd be no reason to reinvent the wheel.

Yea - funny enough the first thing I did was take my plastic overlay off the JMP and try to put it on yours as it looked like it would make it look good - that is when I realized the holes were in different places...

[SiriusHardware]

Slothie, I imagine your rev 1.0 was even closer, before you had to shuffle things around to make way for the extra IC.

The JM PCB is consistently described as an 'issue 0' which confuses me as I've never seen one of those, or issue I come to that. Martin's PCB is a precise copy of a known SOC original, as far as I know the only change he made was to accommodate four-feet dome contacts instead of the original three-feet types.

I'm sure if Tim sticks his Martin PCB on a flatbed scanner with a ruler next to it and scans only the keypad area in the highest available resolution, then emails it directly to you - posting it here automatically shreds the resolution - then that will be as close as you can get to the real thing, and, if you decide to keep the dome contact capability, Martin's overlay will fit it perfectly.