MK14 Programming Interface
 

I just built one of Siriuses Programming Interfaces using the send14 program here and it all seems to be working! I suppose now technically my MK14 is connected to WiFi!

Re: MK14 Programming Interface
 

Oh cute - did you design a PCB in the end?

Re: MK14 Programming Interface
 

You didn't have to fettle any of the time delays? For some some reason most people do. I'm guessing your issue VI has a VDU friendly 4.00Mhz crystal, which should theoretically make it even more sensitive to programmer overspeed - or maybe you currently have a 4.43MHz crystal fitted?

When you come to connect OrtonView the system slowdown caused by OV will mean that you will have to throttle back the keying speed of the uploader a little bit, unless you take pains to disable OV during uploads.

I see you've used a direct connection to the reset input (only available on your issue VI) for maximum neatness.

Did it 'Just work?' If so, yet another triumph for your board designing skills.

Re: MK14 Programming Interface
 

I was going to say that if you plan to use OrtonView, you'll need to round up and fit the additional RAM but of course I'm forgetting that your version of OrtonView already has a VDU friendly 1.5K of RAM on it.

Some of the 'Legacy' software for the VDU was designed to run in I/O RAM with both the main and 'extra' RAM used as screen RAM, so it might be an idea to fit it anyway.

Re: MK14 Programming Interface
 

The PCB is a cobbled together thing that started life as a protoboard layout and was turned into a PCB. If I was doing it again I would make a number of changes, like using the edge connector footprint like I did in the Ortonview instead of a dupont header with cables so I could just solder the edge connector on to the circuit board, and the Pi Zero W hangs over the edge of the board so you can't put in a securing bolt, and its a bit of a squeeze to get the optocouplers under it to fit because they are close to the Pi connector..... But it all just fits and it worked.
Also the GPIO connector is soldered onto the bottom of the Pi Zero, so using a ordinary Pi would be hard, although you could probably do something with a ribbon cable and a couple of IDC connectors to get around that if you are careful with the pin mapping and orientation of the connectors.

No, I left the time delays as standard. I am using a 4.43MHz crystal too. Guess I was lucky! I used the "key14" program to test all the keys worked, then tried send14 with the slothie.hex file. I discovered that the checksums put into the file (probably by my bin2hex program) were wrong, so I had to (temporarily) disable the checksum check in send14.py but I'll redo the checksumming properly and re-instate the check in send14. With permission I might even tinker with send14 to add some option arguments for timing etc.

The reset connections are brought out to a 4 pin header (which I've had to make right angle because it sits under the Pi :-[ ) so you can either jumper it with a couple of links like I have or connect 2 dupont style female connectors connected to croc clips if you dont have an Issue VI.

As for the I/O Ram, as I was typing this it occurred to me it would be easy to make a small board to take a couple of 2111/4 RAM chips that plugs into the RAM/IO socket and gives an extra 256 bytes for people without an 8154 (assuming you don't need the I/O)....!

If I can manage to find a way to get stuff posted to people (tricky at the moment due to being in a care home) I can post a board to anyone, as I accidentally got 15 made which is about 14 more than I need. If I work something out I'll announce it here. As I say its not perfect at all but was done quickly because I got the chance of some free PCBs!

Re: MK14 Programming Interface
 

A few points arising:

The fact that you've used a wired connection rather than a 'hard' one for one connection accidentally makes the PCB equally JMP-replica-compatible - you just need to make the connections differently at the MK14 key connector end.

I suppose If you'd made the layout direct one-for-one compatible with the 'Legacy' layout seen on original MK14s, Martin issue V replicas and your own issue VI you would still have the option of soldering wires to the edge connection on the interface PCB and taking them to an edge connector wired as per JMP connection order.

My prototype also has the 40-way connector coming out of the bottom of the Pi Zero - since they are usually supplied minus the 40-way male connector it's up to you how to solder one in, but I agree that the form factor chosen makes it slightly harder to use a 'big' Pi which will have the 40-way male connector already fitted and pointing upwards. My solution there was to fit a 40 way male pin connector to the opto PCB, pointing upwards, and use a short ribbon cable with 2 x [2 x 20) female connectors on the ends to connect the opto interface to any standard 40 pin Pi including a zero with the pins fitted pointing upwards.

If you do a V2 consider redesigning it as a 'hat', Raspberry's equivalent of the Arduino 'shield', so that it will fit directly on top of any Pi. If you want to get it into the same form factor as a Pi Zero though, it might have to use SMD versions of the optocouplers.

As regards the send14 'support software' I have stated several times in the past that the project is public domain and that anyone is free to improve it in any way they like - I would love to see a GUI version of send14 but I just can't get interested in TkInter for long enough to do anything with it.

Let me also state for the record that I would be perfectly OK with you selling these opto interface PCBs either as bare boards or kits, in fact I would appreciate the opportunity to buy one myself.

Re: the problem with checksum verification not working, does the uploader load the included Message.Hex and Moonland.Hex files OK? It's not impossible that I might have broken something else when I fixed the 00 checksum bug a revision or so ago.

Re: MK14 Programming Interface
 

Yes, every other hex file is fine with it. Its definitely a bug in my bin2hex because I tried a different binary file and the checksums were wrong in that one too!

I'm going to see if can get some kind of cheap laser printer, then I can buy postage online, print it out and put packages in the postbox and won't need to get to a post office. Then I will be able to send out PCBs etc! I had a quick look on ebay but nothing grabbed my attention. I might be able to connect to one of the homes printers which will be less convenient but might be an option....

Re: MK14 Programming Interface
 

If we were to do it old-school and send you some self addressed and stamped padded envelopes, could that work?

From what you say your residence does have a postbox for outgoing mail provided you can find a way to stamp, address and package it?

Re: MK14 Programming Interface
 

Well I can get the staff to drop post off at the post box, I think I also get close to a postbox when I go out for a walk with one of the carers from time to time, so yes if I had some post paid padded envelopes then I could send them. presumably that would depend on weight, but a PCB or 2 isn't much...
I think any post that gets sent out usually gets dropped in the box by the manager here, so if there's not too much I can get away with giving to them :)
I'm sure it can be worked out!

Re: MK14 Programming Interface
 

From your point of view / the residence's admin point of view I think probably one thick package outgoing from you and then distributed onwards by one of us would be the easiest arrangement for you.

Tim probably thinks I'm about to volunteer him for the job, but I would be happy to do this. I would suggest waiting until the OrtonView PCBs also turn up and in the meantime maybe we can gather expressions of interest which can be converted into a guesstimate of outgoing weight / cost.

Re: MK14 Programming Interface
 

That sounds like a plan. I'm going to need 2 of the 5 Ortonviews so there are 3 up for grabs and up to 14 programming interface boards !!

Re: MK14 Programming Interface
 

I (Sirius) would definitely like one OrtonView PCB and one programming interface PCB.

Mark1960, if you want either / or, it will not be a problem sending them to Canada. The least we can do after all your help in the epic PET repair thread, and for keeping us entertained with your leading edge SC/MP projects.

Re: MK14 Programming Interface
 

Same here - one of each and happy to be volunteered if needed.

As regards the JMP compatibility I just added three more opto isolators and modified the code to use the correct ones... That made it more flexible when I did the Triton as I needed more lines and also to simulate the 40 key keyboard they were proposing...

Re: MK14 Programming Interface
 

I can't help but wonder what Slothie intends to do with two VDUs... a dual-screen MK14...?

Re: MK14 Programming Interface
 

Its really just contingency for when I break one of the boards, lift a track, set light to something with a short.... So if I get it working first time there might be another up for grabs!

There will almost certainly be a V2 board for people feeling left out and when I get feedback on what bits need changing or improving.

I cant imagine how the bus arbitration would work for a dual screen Ortonview.....maybe thats a subject for Marks expertise!

Re: MK14 Programming Interface
 

Its always good to have at least one spare as it makes it less painful to hack the first one during development.

If nobody else wants the third spare orton view pcb then I would be interested, but please give priority to anyone else in uk first.

Not so sure about the loader as I don’t have a Pi and my opto couplers are 6 pin, but it probably wouldn’t increase postage to include one and

Re: MK14 Programming Interface
 

I’m still not sure if I can get the bus arbitration to work with a single orton view and multiprocessor. Simple enough to put an OR gate between NENIN from orton view and NBUSRQ to provide NENIN to the SCMP, but not sure about the effect on ILD and DLD.

Re: MK14 Programming Interface
 

..I think there was a glitch in The Matrix there.

The same interface PCB can be wired to an Arduino or almost anything with 13 output port pins (ie, medium range PIC?) as long as the port pins have enough current sink capability to drive LEDs.

DeltaAlpha52's Arduino 'fork' of the uploader uses more or less exactly the same interface circuit.

Go on, you know you want to. It makes a world of difference to be able to fire code into the MK14 in a matter of seconds, they're so much more fun to play with when you can do that.

Re: MK14 Programming Interface
 

Yes, it does use 4 pin optocouplers, the type I used were PC817 (Or LTV-817/EL817...) because they were cheap on eBay :)
I might try wiring one of my boards to a Pi Pico because thats 3.3v as well and runs Micropython...

Re: MK14 Programming Interface
 

I have a Pico too but haven't done much with it as I would rather programme it in 'C'- they haven't got the working environment for that language set up very well yet, although there is a script which sets everything up on the (Linux Computer) Pi if you don't mind using that as your main development machine. I really wish they had not used the 'Raspberry Pi' brand name for the Pico. The Arduino IDE is supposed to be bringing in support for the Pico as well as a few other PCBs which will use the same microcontroller.

My impression (unconfirmed) is that the Pico has quite a lot of onboard RAM and is also very fast so you could do something like the MK2 Arduino version (which currently uses an external SRAM as a serial buffer) but try using the internal RAM on the Pico instead.

If just not having the right optocouplers is an issue for Mark, fear not, I can easily populate the opto positions (if desired) by soldering SMD versions to the through hole pads on the upper side of the PCB - wouldn't add much to the weight and I have more than enough of them lying around at work.

As regards 3.3V vs. 5V drive, the optocoupler LEDs are 'lit' for such a short time during each key press that running them from 5V through 330R doesn't stress them much, so I did not bother to change those values for the Arduino version. The reset opto is lit for longer, but only rarely.

Re: MK14 Programming Interface
 

The pico micropython interpreter also maps unused flash memory as a file system (about 1600k) which holds the python code you write but also can hold data files (like mk14 hex files,,,,) so you could make a mini standalone "program disk" device. I believe you can "partition" the flash like this when using C too.

I agree that it would have been less confusing to have branded it the Raspberry Pico without the "pi".

Re: MK14 Programming Interface
 

Not sure what happened there, I don’t even remember typing “and”.

I was thinking about connecting an ft245, with ram instead of prom and /OE disabled until one of the flag outputs is set. Then connect rx ready to NHOLD and send code over the ft245 to write data to ram. That was before I just set the links on the ram to bootstrap ram from the prom as the code in the prom executes.

I need an easier way to load code, but not sure if the proms are going to get in the way.

Re: MK14 Programming Interface
 

There's always the prospect of using NENIN to kick the SC/MP off the bus and then directly flood the RAM with code from something directly attached to the address, data and control lines and presumably isolated from them all by tristate buffers. When released again the SC/MP will try to resume where it left off even though the code it was executing may have vanished, so you'd probably need to assert Reset as well, to force predictable behaviour after loading of new code.

The 'keypad injection' method obviously only works when the OS is present and working as it literally types the code into the machine exactly the same way as a human operator does - but quite a bit faster - using the normal user interface provided by the OS.

Re: MK14 Programming Interface
 

I also like the way you see the display quickly changing a bit like on Star Trek when Data is speed-typing into the shipboard computer.... :D

Re: MK14 Programming Interface
 

Maybe that's what I should have called the project... "Data". It still amazes me how rapidly the MK14 allows keypresses to be entered. If you watch the data field digits on the display during upload, they are just a blur.

Re: MK14 Programming Interface
 

A rookie marketing blunder, it can only lead to little Johnny or Mary asking for a "Raspberry Pi" like the ones they use at school only to be given a (cheaper) and incompatible Pico, which has 'Raspberry Pi' in the name.

Raspberry = Brand
Pi = Model, or model range.
Pico = An entirely different model, not a Pi at all.

This should have been pretty obvious to anyone. That said, I am looking for 'proper' jobs (like the uploader) for the undeniably powerful little Pico to do - once the programming environment catches up with the hardware.

Re: MK14 Programming Interface
 

There is this project https://github.com/earlephilhower/arduino-pico that implements the pico into the Arduino IDE board manager, but it still looks a little complex to me. I expec that you'd be happier with some kind of "official" project. The main attraction of the Pico to me is the fact that it can be programmed in Micropython, there have been Micropython microcontrollers before but they have been expensive or fiddly to use. The Pico also uniquely has the "Programmable I/O" (PIO) feature that should make tight timings on interfaces a bit easier too.
If I want an ARM core microcontroller to program in Arduino IDE I'd probably use one of the STM32 boards I picked up for almost nothing from China :D

Re: MK14 Programming Interface
 

Yes, when the Arduino IDE has a 'Choose Board' drop down box for the Pico 'out of the box', that's when I will revive my interest in the Pico. Apparently it is coming.

As a point of interest, the little BBC Micro:Bit which was offered / given to schoolkids of a certain generation (and now in its second hardware version) can also be programmed in Micropython and there is a nice mature offline Micropython IDE for it, similar in operation to the Arduino IDE, called 'Mu'.

Re: MK14 Programming Interface
 

Yes, I had a Micro:Bit back in the day and I was quite impressed with it. I even bought some peripheral bits for it but never did much with it, not sure what became of it. At the time I was working for the BBC co-incidentally and I may have loaned it to one of my collegues to play with and not got it back. The "Thonny" IDE supports the Micro:Bit too if you're using micropython.

While we are on the subject of IDE's all the cool kids are using "Geany" these days I am told, I tried it and it seems quite good, although I tend to use Sublime Text which is almost an IDE these days just because its what I'm used to and I bought a licence that you can port about onto any computer you use. You can use it without a licence, it just nags you from time to time, but I worked with companies that have conniptions about using unlicensed software even if its free so I bought one to shut them up :D

Re: MK14 Programming Interface
 

I've also noticed I only got 10 uploader PCBs, I misread the packet. Not that I'm in danger of runnng out!

Re: MK14 Programming Interface
 

I use Geany (which has been bundled on the Linux Pi for a while now) as an editor (only), it's quite useful as it recognises the syntax of various languages and renders everything in soothing context-sensitive colours, which, of course, is important.

I didn't realise 'Back In The Day' now meant 'several years ago!' Mind you, it's slightly longer ago than I thought, the Micro:Bit having been introduced in 2014.

Swerving more back on topic, please let us know when the Ortonview PCBs arrive, in the meantime anyone else interested in an OrtonView PCB or uploader opto-interface PCB please pipe up.

Re: MK14 Programming Interface
 

Yes I will, They're coming by parcel post because I chose the cheapest option :) They might be a week or 2.

If it helps, I'm regretting that decision already!

Update: Its cleared customs already, so may not be that long....

Re: MK14 Programming Interface
 

Well, it will give you lots more opportunities to toss and turn at night, wondering whether you've made any fatal mistakes on the OrtonView PCBs. (Fairly unlikely, given your past record).

Re: MK14 Programming Interface
 

(Brought across from the Ortonview PCB thread, so the uploader PCB can be discussed in more detail without bouncing that thread too far off topic)

I'm probably going to solder SMD TLP185s to the opto pads as they grow on trees at work so for me at least, clearance should not be a problem. Since you've already built one and it works I don't expect to have to remove any of the optos once fitted.

I take it the output connections from P4 are in 'conventional MK14' (not JMP) order and spacing and are an exact one for one match to the edge connector on the MK14 - I notice there is nothing connected to pads 9 and 11 counting up from the 'R1' end. It might be an idea to include a drawing of the wiring of the [uploader -> MK14] interconnection lead if you have not already put one in. To be fair, consider also including the alternative wiring which will be required if the target MK14 is a JMP replica.

Re: MK14 Programming Interface
 

The wiring for a Issue VI and the standard MK14 is 1-1 from the uploader to the MK14, I wired all 16 wires even though the uploader doesn't use pads 9 & 11. When I do the "manual" for the board I will include wiring for the JMP which I recall you documented earlier. I did it this way in case I decided to use a 2x16 dupont style connector on the MK14 which I prefer to edge connectors since the MK14 doesn't have a location slot for an alignment key.

Its worth soldering in the optos. I've found the 4 pin DIP chips are a bit "wobbly" in the sockets because they have so few pins! Its not caused problems yet, but its possible it might in the long run if the springiness of the sockets deteriorates. And it shouldn't be too hard to desolder a 4 pin chip should the need arise.

Re: MK14 Programming Interface
 

If you do document the wiring for the JMP replica watch out for the fact that the top two pins from the Pi are swapped over on the JMP version. Since these are hard wired for the standard MK14 on your uploader PCB, it will instead be necessary to swap the top two column lines over as they go from the uploader to the JMP.

This is best illustrated by the first of two circuit images in this post in the original uploader thread.

https://vintage-radio.net/forum/show...4&postcount=30

The second circuit looks tidier because the Pi pins used to operate the upper two optos have been discreetly swapped, but on your PCB that would involve having to cut and redirect the connections to the Pi.

In the real world, better to leave the Pi connections untouched and swap the wires over as they go from the uploader to the MK14 (as per the first of the two diagrams).

Re: MK14 Programming Interface
 

Yes, I was only intending to show how to wire from connector to connector, if people have a JMP and want to make a plug arrangement then they'll have to hack the PCB appropriately. Again, a V2 PCB would probably take this into account, since presumably there are a number of JMP owners out there.

I presume the change of mapping of the GPIO pins could be done in software.

Re: MK14 Programming Interface
 

Yes, Tim's already done that - his version of the opto interface has more than the 'standard' 13 optos and the software modified so it can just select which optos to drive to write to either connection scheme, standard or JMP.

This is of course because Tim has one of each type of MK14 parked in the garage, three if you count the 'Martin' kit he hasn't even built yet. I originally reasoned that most people would only have the one and would build the interface version to match their machine - the current version of send14 drives either version of the opto interface without any modification.

If or when you make a rev 2 version of the uploader PCB, you are welcome to provide for Tim's mod and continue development of the send14 software to encompass this change to make it the new 'mainstream' version. I wouldn't really want to go down the road of having one version of the software for Standard MK14s and another for JMPs because then both versions have to be maintained side by side. I like the idea of one version of software, one version of the interface better.

As I said though, it's no big task to have to swap two wires over on the way from the uploader to the JMP.

Re: MK14 Programming Interface
 

I wouldn't want 2 versions either, I'd provide a flag or configuration option for it. In fact a config file would allow it to remember timing settings so people could tune the settings for themselves and not have to provide them every time.

Re: MK14 Programming Interface
 

Since the program is just a text file you can obviously edit the timings in the program itself and they stay set to whatever you eventually find works best for you - putting that functionality (of playing with the values while the program is running, and saving them in a named config file) is more the sort of thing which would suit a GUI version of the program, with menus from which to pick or tweak parameters such as the timing and also the 'OS mode' in which the program runs, currently set by the value of a flag in the early part of the program.

It's not ideal to have to edit the program itself to modify its behaviour, but when I made it originally I made it for one type of MK14, the theory being that all machines had the exact same hardware and would work with one experimentally determined set of timing values which would not need to be changed once arrived at. I didn't initially support the 'old' OS, so the need to be able to select that was an afterthought as well, and I had absolutely no idea that the designer of the JMP replica had gone with a different keypad connector connection layout so that wasn't factored in either - hence the creation of a JMP specific version of the interface, once Tim had made that discovery.

Re: MK14 Programming Interface
 

Uploader PCBs (along with Ortonview PCBs) have just gone in the post to Tim and Mark today, Saturday.

Mark, sorry but I did not get the opportunity to fit optos - had they arrived a day earlier I would have taken yours to work and populated it with the TLP185s which we have in abundance there.

Re: MK14 Programming Interface
 

Thinking about making send14 configurable in a more friendly way, we could make it so that any 'switch' command issued when send14 is run creates a config file which is always looked for first when the program starts, so

If no config file found and no optional switch commands issued, run using the settings embedded in the program.

If switch command issued and no previous config file found, create a new config file with all settings including the new setting saved in it and apply the switch command setting for this run

If there is an existing config file and there are no switch commands issued, run using the settings found in the config file.

If there is an existing config file and there is a switch command issued, update the config file with the new setting and then run using the new setting.

The point of this is that it lets you issue switch commands on a one-shot basis, after which the program continues to run in that mode until you issue another switch command so you don't have to remember to type e.g 'send14 moonland.hex OS=old' every time you run it. After the first time, the config file will 'remember' that your preference is to run in Old-OS mode.

Examples of parameters we might control in this way:

-OS output mode (Output keypresses as required by the old or new OS)

-Speed parameters, either singly or as a set

-Standard MK14 or JMP MK14 (only for use with opto interface with more optos than the current one has)

-VDU inactive / active (Increase all timing values by x% when an active VDU is connected).

-4.00MHz / 4.43MHz (select between two sets of timing values, one optimised for 4MHz machines, the other for 4.43MHz machines).

Re: MK14 Programming Interface
 

If you do that then it becomes easier to have a profile that changes all parameters as at least several of those items are different per machine so you could do send14 -P1 and that just saves that profile to DEFAULT and uses it from then on - so you can edit it - so you could store known profiles in the release but, still make it easy for people to tweak locally if they need without editing.

Re: MK14 Programming Interface
 

Obviously as you say send14 will create default if there is not one of the most likely.

Re: MK14 Programming Interface
 

No problem, fairly sure I can get suitable optos from a local shop here.

Re: MK14 Programming Interface
 

From OrtonView thread -- Is this what you want?

Attachment 238577

Re: MK14 Programming Interface
 

Hmm interesting. Seems like a PCB with this layout would be easy, just not fit the col 7 & 8 optos if you don't need them, then change the pin mapping in the software to suit the kind of board you are connecting to.

Re: MK14 Programming Interface
 

I also needed the extra optos to allow me to use them as pull downs for a resistor pack in my Triton adapter as I use the same board with a small conversion PCB to type ASCII into it - this would also work with things like an Apple 1 etc.

Re: MK14 Programming Interface
 

Ref #46, exactly so. Since you (Tim) have already made yours as per that diagram, that can be the new standard opto interface diagram on which Slothie can base his V2 uploader PCB, should he get to the point of doing one.

We'll then make a new 'mainstream' (V2?) version of send14 which can work with both standard and JMP edge connections through the same 15-opto interface.

I think at that point we'll ask for the original thread to be reopened so it can all be put into one chronologically linear thread, similar to Slothie's epic 'MK14 schematic revisions' thread.

Re: MK14 Programming Interface
 

Progress: (Attached).

Just need to make up the connecting cable + plugs for each end. I have to say this PCB makes the interface an absolute doddle to build, thanks, Slothie. There's no excuse for anyone not to make one now.

As you can see I used SMD optos because I have whole reels of them here but it would no doubt be even quicker to build with DIP optos, the SMD ones have to be positioned quite precisely so each leg just reaches the nearest pad.