Re: MK14 schematic revisions
 

Ian, yes, at least you know now that you have those five good PCBs waiting for you when you can finally get at them.

Tim, just to confirm, I also have the 2111 memory link made (as you might expect as my RAMs are AM9111s) and I have the JP2 (Sense-A?) link shorted, although the latter would normally only stop you from running entered programs if you missed that out.

Your display, has that been tested by any other means?

Edit: Aha! the old reset-switch-90-degrees-out-routine? We use that same type of switch in an old CPU PCB we still repair from time to time, so I'm used to not getting caught by that. ;)

Re: MK14 schematic revisions
 

I predict that Tim will probably have his VDU PCB built and connected to the new PCB by this time tomorrow.

Re: MK14 schematic revisions
 

Cool I did not notice that link I was going to use my little adapter - which has that and my cassette interface plug on it. I had wondered what to do when I put the DIN connector on ... that is easier.

By display do you mean my Large LED one or my VDU PCB - I would hope to have time to build it tomorrow... not sure if that will happen though.

Re: MK14 schematic revisions
 

I meant the LED display, disregard. We cross posted so I didn't realise you'd already fixed it by the time I hit 'submit'.

You can fit a dinky SM pulldown resistor at JP2 rather than a link and that will make Sense-A available for user programs. Did you also notice that Ian made the reset line available, finally, on the keypad edge connector? Another thing SOC should have done from day one.

As you have the luxury of having keypad switches fitted, check out the contents of 0000, 0200, 0400, 0600 to see if the unwanted PROM images have gone. That's another improvement Ian made, in fact that's the reason for the extra IC, because he wanted to do that and still have the option to use the alternative type of RAM.

Re: MK14 schematic revisions
 

The 2111 memory link is joined by default with a teeny trace because I assumed most people would use them. My prototype with the original board had this link broken and I tried the other kind of memory which fortunately worked. I wasn't able to test the RAM/io chip as it didn't fit with the heatsink so close! The chip has been moved to make space.

Re: MK14 schematic revisions
 

Good idea on the pulldown - I will have to buy some SMD - not something I use - maybe I can scavenge one off that board I got the Power connector from.

All those just return 0x1F now not ghosts so that seems to be working.

I did notice the RST was going to adapt my programmer to use it rather than the clips on the Cap - struggling to get that to work as is at the moment though. After a RESET it does not seem to enter the address to load at - maybe I am trying old HEX files.

Re: MK14 schematic revisions
 

Try leaving the reset clips off and just do a manual reset before each upload.

If that then works, it is probably still coming up out of auto-reset when the uploader starts sending the first address, in which case you need to increase the 'post-auto-reset' delay.

Also maybe worth just checking the keypad edge connections using key14 to see if the new board is reading individual external key presses correctly. I don't think Slothie ever had the opportunity or reason to test those connections on his original PCBs. I'll be connecting my own interface tomorrow, so Ill update with what happens for me.

Another thought, do your other machines have 4.43MHz crystals fitted? If so, this one will be running slower, so all delays will need to be lengthened a bit.

Re: MK14 schematic revisions
 

I expected that you might have made 2111 the default with a hair-link between the pads but, try as I might, I could not see it so I blobbed the pads just to be sure.

Re: MK14 schematic revisions
 

A quick update, I've had the new 'Slothie' Issue VI connected up to the pi-uploader, first of all I used the 'Key14' test utility to check the layout of the keypad connector and of course it was OK, all key presses individually sent to the PCB via the edge connector were coming up as the correct characters, commands or actions, including reset. This was to be expected as the timings for things like the length of a key press are much more generous in the key14 script than they are in the send14 script, where the delays were eventually pared to the shortest possible length consistent with everything still working - that was on my original issue II, 4.43MHz machine.

I used key14 to enter some test code, and naturally I chose the original test routine from #100 of this thread to honour the great man himself, image #1 attached.

The big surprise today was that the original 'send14' timings - including the original reset-hold and reset-release timings - work perhaps 98% of the time with this new PCB with a 4.00MHz crystal in it - I've uploaded the 'Message' program to it over and over and over again, and only once did I see a problem indicating that the timing was a bit tight, the letter 'J' of 'Jolly...' was corrupt on one occasion. I assume if I slow the timing a tiny bit that will then shift to 100% perfect entry. But otherwise, it's working better than I dared hope.

One way in which my PCB probably is different from Tim's is the four resistors near the upper left corner of the keypad and the four at the top right hand corner. The values originally given for these eight resistors is pretty arbitrary, all 1K2, but up to about 15K, I think.

My original MK14 has 4 * 4K7s for the four near the keypad and 4 * 6.8K for the four at the top right near the PROM, so that's what I have also fitted in the same positions in the new PCB.

Re: MK14 schematic revisions
 

Yes I had similar findings and had to slow send14 down a tad. Once I realised I was using the wrong keyboard connector (the one on the flying lead is for the JMP layout) I was away.

I have run MESSAGE (<256 bytes), LIFE(384 bytes in RAM/IO) and SEGTRIS (512 bytes BOTH RAM) fine on the board. One disappointment was that my INS8154 for the second MK14/SCRUMPI3 was dead as a doornail - too late to send it back now 10 months later... and I can't see anyone selling any either.

It has been a busy day with errands etc and not the least of which working out why my PC is resetting all the time - seems one of the disks in my array is failing... no spare to bring online either - so one on order and finding some spare spinning rust big enough for a backup run.

I did just finish the VDU and due to the risk with only one 8154 I rigged a few jumper wires in its socket to hold lines low as described in the manual. No video with or without the Char Gen - so looks like some work to do checking everything but, not tonight - I think I need to get out of this chair...

Looks like the V6 board is good though. One thing to watch out for is that the changes for NENIN (cutting link to IC10 etc) have been done on the board already but, it does need a pullup on NWDS to 5V - I fitted it on my VDU under the board as that comes through on the connector - I suspect others may find a place under the V6!

Attachment 207236

Re: MK14 schematic revisions
 

Ordinarily if you just strap a few control lines into certain states power it up and you have, oh, provided it with a clock the VDU will just display whatever nonsense it is seeing on the unterminated data lines. Did you remember to pick up the clock from the underside of the issue VI PCB? If not, the clock input on the VDU will be shorted to 0V at present.

Of the control lines the most important would be b13 'VDU OFF', which disables the VDU when high and enables it when low according to the manual.

On the PIC 'VDU driver' PCB I have b13 [Blank screen / VDU OFF] is just tied permanently low so the VDU is enabled, but when used with an actual system it will need to start off disabled because it has a very big effect on the system speed and none of the current loading methods (cassette, uploader etc) will work when it is enabled because the system is constantly being halted while the VDU reads data from its RAM.

What's therefore needed is a modest pullup on B13 which will hold the VDU -off- until such time as the user intentionally switches the 8154 PA0 output from input to output and then drives it low to turn on the VDU.

A reminder, attached, of how the MK14 top side and VDU 'b' row connections line up if they are connected together one-to one. b27 (Clock into VDU) and B15 (reverse pages) are the main ones which need sorting out.

Re: MK14 schematic revisions
 

In what respect does the 8154 appear faulty?

-Stops the system from working?
-Not storing data in memory at 0x0880-0x08FF?
-Port pins not working?

Bearing in mind this was a previously never tested board, I've just tried my (known good) second 8154 in my Issue VI PCB now, one thing I notice is that the machine doesn't always start up properly with it in - instead of the expected '0000 00' prompt I sometimes get '.... ..' even after manual reset. If it starts up in that state, usually power cycling will get it to the correct '0000 00' prompt and it's OK from there.

I can write data to the address range 0x0880-0x08FF and it 'stays', proving that there is RAM there.

I also ran this short test program which generates activity (a running binary count) on both ports, A and B, of the 8154, which you can check for with a scope.

This and the memory check both work on my PCB, so I don't think there is a problem with the connections from the 8154 to the bus, for example.

Edit: SC/MP and 8154 reset pins are connected together, as they should be. Thought maybe the 8154 NRST might be floating.

Re: MK14 schematic revisions
 

I've just realised I'm chasing wild geese here - obviously you have one 8154 which works in that machine or you could not have run the larger programs which utilise the 128bytes of RAM. But you have another, which you maybe meant to use for the 'Martin' replica?

Re: MK14 schematic revisions
 

Yes sorry I even tried the dead 8154 in my JMP just now just in case and I get the same effect RAM or IO space just shows as 0x1F and you cannot type anything in the monitor which seems to be what happens with RAM holes - I did not bother with the port test code - If I get time I may do that as well.

I do not get the startup problem with a working 8154 on either board though. As you suspected I have a few resistor differences. Initially because of a batch of bad 4.7K resistors which I found when building the SCRUMPI (and several of which had been liberally scattered to bags of bits for many kits) I thought to test the ones I had put aside for this and they were dead so I substituted 5K 1% blues ones - then I preferred the look on the board of all Blue so stuck with them. All my 1K2 ones are actually that value Blue 1% R7-10 and R12-R15 (Top)

The reminder of the connection diagram and the IO line test on the V6 you have done are useful as I had not tried that, so I was running a bit blind on using the IO chip socket as a way to patch the VDU lines although I did tap them out for continuity as part of soldering up the connector on the VDU board.

As in the VDU manual I have grounded b9-b12 (using the pins on the IO socket for simplicity with jumpers to a breadboard - a sort of 8154 simulator :) and left b14-b17 unconnected but, I do not get the expected bitmap of the monitor.

Re: MK14 schematic revisions
 

No, given your other symptoms I think that would be pointless.

As to the VDU, you still didn't mention the clock? Even if you did remember to switch it over from bottom side to top side it might be worth checking to see if the issue IV PCB is outputting a clock on the appropriate pin. It's almost the only thing I can think of which would make it seem so 'dead'. That, or something wrong with the 'VDU ON' enable path into the VDU via b13. I'm assuming you have power to the VDU - is that going to it via the connections on the underside of the edge connector?

Re: MK14 schematic revisions
 

This sounds suspiciously like the resetting problem I had with my first prototype where it would sometimes power up with random stuff on the display and would only clear if power cycled. Strange it only seems to happen with the 8154 in now. I was never able to test it with the 8154-in. Its nice to know it seems to work ok when it resets properly.
Roughly what % of times does it reset incorrectly?

Re: MK14 schematic revisions
 

I have just put the VDU board on the Scope (I really was too tired last night and had to tidy up the desk for half hour to see the screen!)

I did remember my XOUT patch - unusually for me I reread the thread we discussed it all in as it was that that reminded me to bend up b15 as well to take over to b8 when I am ready.

My machine is a bit slow today as I am running a 1TB backup over USB2 to an external drive...

Attachment 207278

The bent out b27 makes a handy earth clip point as well!

So the clock is nice and strong 4V in and can be seem as nice clean square waves on Pin 3 of IC4 (no output on pin 5 of that latch so the feed from IC6 via the four gate NAND on IC13 and NOT on IC12 are doing nothing).

It is also an even cleaner square on Pin 14 of IC3 from the IC4 Flip Flop.

Just on the off chance the scope on the Composite (rather than the TV) shows a nice 1.5V p2p normally high with 10ms low pulses every 80ms so some counters are running.

Re: MK14 schematic revisions
 

I wouldn't worry about it too much for now because:
-Tim isn't having that problem.
-My DC power socket, salvaged llike Tim's is a very slack fit, needs to be replaced.
-I have a current limited (1.2A) 9V regulated PSU feeding a large (4700uF) input capacitor, which might be causing slow rise times - will disconnect or reduce the size of the input capacitor to see if that makes a difference.

Plenty of things to try. The main event for today is whether Tim can get the VDU running. ;)

Re: MK14 schematic revisions
 

No pressure then! Just on that point my smoothing CAP is only 220uF as it was bright yellow - from 1982 as I have a bag of 50 and the only axial I had handy. The PSU is a 9V noisy wall wart the one I use with everything except old Spectrums as it is the wrong polarity.

Re: MK14 schematic revisions
 

and another thing I was interested with the decoupling point on CAPS as the original had even dropped one from the BOM. I put in only the original two C3/C4 but due to the fact I know my PSU produces ringing I did add the two by the PSU in 15 and 17 - didn't really check where they were on the circuit but, assumed close to the Regulator...

Re: MK14 schematic revisions
 

Funny enough I was thinking the capacitor might be too big as I was using a wall wart style 9v power supply and they're noisy (it's a switching type) and not known for having good switch on characteristics. I'm not too worried, maybe the power to the cpu has too much inductance (ie too long a path) but it didn't happen often enough to be troublesome. That's why I asked how often it happened.

Re: MK14 schematic revisions
 

With the 8154 out, never, with the 8154 in, quite frequently, but it almost seems to depend on the angle at which I push the DC plug into the grotty socket I've fitted. That's why I'm saying don't churn over it too much for now.

The PCB has been a resounding success so far, amazing considering you put it out 'blind' without ever having been able to test it yourself. (I know you had one of your Rev 1.0 PCBs running, but you made a lot of changes after that).

Re: MK14 schematic revisions
 

I do use a 1000uF (edit from 100!) on my JMP with the same PSU - now we did have the reset problem on that occasionally although that seemed to be very infrequent now as the main culprit was a faulty 80C95 or its 74 series equivalent as Sirius will remember

Re: MK14 schematic revisions
 

On the VDU front I did run every chip through a simple function tester before use... except the character generator obviously as that was too obscure for the £30 device to have in its database.

Re: MK14 schematic revisions
 

Indeed I echo that brilliant work - thanks very much, this has jumped my VDU project forward (without needing to wreck my lovely Issue II JMP for which now I will get an Issue 1 SCIOS burned by someone on some Tesla's -or maybe I will just get a PROM programmer going that looks a bit authentic on one of these...) and allowed me to have a better daily driver with the memory hole ready for expansion memory which will be needed to do anything serious.

Once I have collected enough parts I will then complete the Martin replica V as close as I can to period looking as a museum piece... working of course...

Re: MK14 schematic revisions
 

Why thank you. I'm not too worried, I'm actually relieved that it all seems to be basically functional. I ripped up and re-did most of the layout around the 8154, display and clock circuit and moved several tracks elsewhere as well as adding the extra chip for ROM decode, so the opportunity for errors was significant!
I'm really enjoying seeing these boards come together. Really hope tim gets the VDU working since that was the main point of the update (other than fixing the back to front display!) .

Re: MK14 schematic revisions
 

Well its not just me Sirius has an original (known working) VDU as well so once the correct connector is added he will be able to test - or are you waiting for me to prove I can get it working before risking yours...

Re: MK14 schematic revisions
 

:o Whatever can you mean?

Anyway, I am now unavoidably sidetracked for the better part of the day so I expect to see it all working by the time I surface again. Good luck!

Re: MK14 schematic revisions
 

Well made a bit of progress - I had to ground b13 as it is not hooked to Flag1 as on the original VDU (so would be GND on power on) but to PA0 so in its floating state at 2v or so I think it was turning off the VDU - does that just stop the DMA as the previous pulses were still there? I assume so as there is no reason the frame and line pulses could not continue to ensure just a black picture when it is OFF - it just needs to stop interrupting the CPU a bit similar to the FAST and SLOW mode on the ZX81... how history repeats itself.

I now get the below two traces at 0.5us per div on x5 Mag and the built in TV Trigger (seems more like 5v p2p now). I would swear that is likely line blanks and data on the tv lines - setting the b16 invert video gets the right hand trace... seems currect

Attachment 207296Attachment 207297

So I am missing a key part of the VDU signal it seems or overdrive the TV - I will try a resistor - probably just omitting the Modulator as on the Spectrum is not suitable composite mod for the MK14

Re: MK14 schematic revisions
 

Well success at last!!!!

After a whole afternoon chasing ghosts and going down rabbit holes of reading - all of the cz forum MK14 threads (which was useful for several things) - I was right it was the output overdriving the TV but, a 330ohm resistor just created a very distorted signal, it needed a divider really but, I tried just a resistor as Martin's photo of his replica had a resistor on it feeding the composite socket. I later found reference in the forum he used a 150ohm (as you can't see the bands in his photo) but he also telling says that modern monitors can handle a lot... he has an LCD...

https://translate.google.co.uk/trans...78640%23p78640

There is a very good part of the thread where MrStaff (the originator of the PONG game video) describes building his Video card and discovering the lack of back porch (which is visible if I try to invert the screen where it looks like a ZX81 with very poor letters... that is another topic to discuss moving forward).

He also simulates the output circuit:

http://www.falstad.com/circuit/circuitjs.html

Concluding: It is tuned, R7 = 1k5, "R9" = 47, R6 = 1k2

So I swapped miy R7 and R9 out and added R6 which is omitted (in the VDU manual as well) and bingo... the scope shows:

Attachment 207314

So I thought what the hell just plug in the TV again...

Attachment 207315

Then I ran around screaming for a while - putting b14 high allowed me to see graphics as well.

Attachment 207316

After a bit of playing I discovered (back in Text mode) and connecting B11 to the b17 Top Page connection while Pulling b10 and b12 high through resistors and keeping b9 Low (not quite what the manual says so I was confused for a while) I get a character display of F00 at top and B00 at bottom...

After trying to work out the character set by trial and error I remembered Sirius posted it once...

Attachment 207317

to save people searching:

Re: MK14 schematic revisions
 

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!'

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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:
and just after the reset
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.

Attachment 207332

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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.

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.

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.

Re: MK14 schematic revisions
 

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

Re: MK14 schematic revisions
 

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

Re: MK14 schematic revisions
 

None from me use what you like!

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

- 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.

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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...

Attachment 207509 Attachment 207510

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 :)

Re: MK14 schematic revisions
 

Lovely picture Sirius - they look great together...

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

Attachment 207511

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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.

Re: MK14 schematic revisions
 

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...

Re: MK14 schematic revisions
 

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.