View Single Post
Old 14th Dec 2018, 3:35 am   #9
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,483
Default Re: MK14 programming interface - MK2

Here it is, attached, the companion Python hex uploader script for the interface described in post #1, called 'send14'. I have also included a couple of the programs from the MK14 manual as hex files, namely 'Message' and the 'Moon Landing' game. As before, the script is a Linux / Unix format test file and is best viewed / edited on the Pi or a Linux PC. I don't claim this is beautiful code - but it does work.

It was originally written on a Pi Zero W but has also been tested on a Pi 3B. In theory it will work on any Pi with a 40-way GPIO connector. The 'alternative' SPI mode of some of the GPIO pins needs to be turned off in raspi-config otherwise they will clash with some of the pins used by this project.

Unpack the zip file into your home directory and move the 'send14' file into your home/bin directory. There, make it executable with

Code:
chmod +x send14 <enter>
On returning to your home directory you should be able to run it.

Example Usage:

Code:
send14 message.hex <enter>
If all is well you should see the MK14 display zooming rapidly through the address range as the code is typed in at superfast speed, and then, if you have uploaded either the message.hex or moonland.hex file included in the .zip file, the program will also auto-run. On an MK14 with the 'New' OS, 'Message' will upload and run in roughly three seconds. 'Moon Landing', probably the longest and most complex program in the MK14 manual, takes a little longer.

Limitations:

- Can only upload Intel Hex format files.

- No checks on whether the addresses in the hex file are legal addresses on an MK14 - it's up to you to make sure they are, by including .ORG statements in your source code.

- Can only upload code to the MK14 if it is at the 'ready' prompt, ---- -- for the old monitor and 0000 00 for the new - unless you have included the thirteenth 'Reset' opto in the interface, in which case the interface will reset the MK14 to force it back to the monitor before it starts uploading. The reset circuit is not directly available at the PCB edge connector, so connections from the reset opto to the reset circuit have to be made with spring test clips clipped onto the +ve and -ve leads of the reset capacitor close to the reset switch.

The Autorun feature is invoked by including something like the following
at the end of your source code - or in fact anywhere in the source code:-

Code:
    .ORG 0xFFFE
    .DB   0x0F
    .DB   0x12
(The exact syntax depends on which assembler you use). FFFE is a 'special' address for the uploader, not a real address on the MK14. It will use the two bytes at FFFE and FFFF in the file as the execution address from which the program should autorun after being uploaded.

The uploader expects the execution address bytes in the order high byte, low byte. If you use something like a .DW 0x0F12 statement to place a 16-bit word in memory, your assembler might actually place the bytes in reverse order - so I suggest always defining the execution address as two separate bytes, as in the example above, to make sure they are placed in the code in the right order.

The script was originally written to upload to an MK14 with the 'new' OS, but I modified it so that it could easily be made to work with an MK14 with the 'old' OS - to do that, load the script in a Linux text editor, locate the 'MK14_OS = 1' Line just a few lines into the program, edit it to say 'MK14_OS = 0' and save the modified file.

If you get it working or experience any problems, let me know.
Attached Files
File Type: zip send14.zip (4.4 KB, 155 views)
SiriusHardware is online now