28th Sep 2021, 11:29 am | #101 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
..he means issue VI. (On the diagram, and in the above text). Not issue IV.
|
28th Sep 2021, 1:19 pm | #102 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Programming Interface
|
28th Sep 2021, 2:20 pm | #103 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
Well, at least you got it right on the issue VI PCBs. That would have been awkward, two competing issue IV PCBs...
|
28th Sep 2021, 5:04 pm | #104 |
Tetrode
Join Date: Feb 2020
Location: Crawley, West Sussex, UK.
Posts: 77
|
Re: MK14 Programming Interface
Thanks for confirming what I thought for the reset connections.
Looking at the PCB it seems that the pins placement for the opto-isolators are neatly aligned so I can us a strip of SIL sockets to mount them, and not have to use 4 pin sockets, although they are cheap enough to just solder them Did you have a special foot print in the design tool to do that or was it just careful placement of the opto-isolators? |
28th Sep 2021, 5:53 pm | #105 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Programming Interface
It was careful placement... (well, I set the snap to 0.1" and placed them). Its designed for 1 16 way DIP and 2 18 way DIP sockets but you can use the strips you show too.
|
28th Oct 2021, 11:15 am | #106 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Programming Interface
I have made a 3D printed box for the uploader! It hides the bodged alignment of the Pi Zero and the opto board, and supports things somewhat. The power, USB and HDMI plugs are available on the front, there is a slot for the ribbon cable on the side (if you have soldered a connector to the board other than the dupont style I used you may need to dremel out the opening!). The lid is fixed with 2 2.9mm x 6.5mm / No.4 x 1/4" self tapping screws.
I've included a zip with the 2 STL files for use on the 3D printer, and the FreeCAD file in case that's useful to anyone that wants to modify it. |
29th Oct 2021, 4:34 pm | #107 |
Tetrode
Join Date: Feb 2020
Location: Crawley, West Sussex, UK.
Posts: 77
|
Re: MK14 Programming Interface
Very neat box - 3D printers can make a project look very neat
|
29th Oct 2021, 4:36 pm | #108 |
Tetrode
Join Date: Feb 2020
Location: Crawley, West Sussex, UK.
Posts: 77
|
Re: MK14 Programming Interface
I've got the programming interface working and I send the hex files to the MK14, but I was wondering if there was any way of adding comments into the hex files. It would sometimes be good to have just a little bit of information on the program stored in a hex file - like how to play moon landing ?
|
29th Oct 2021, 5:04 pm | #109 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
Intel Hex files are just carefully arranged text files which can be edited in a plain text editor like Notepad. You can't (easily) edit the actual lines of hex that way because any change in the data on a line will also require a change in the checksum byte at the end of the line.
I've never tried it but if you try adding your instruction text on to the very end of the hex file the send14 script may just read and ignore / discard the extra lines. Just try it and see. Try to avoid using the Colon ':' character because the uploader script uses that as a 'start of Intel Hex Line' marker. Last edited by SiriusHardware; 29th Oct 2021 at 5:18 pm. |
29th Oct 2021, 8:32 pm | #110 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Programming Interface
I just tried adding some lines after the auto-exec address bit and unfortunately 'send14' stops before automatically running the program with the "Invalid hex file" message. It does seem to put the whole program into memory though. The last key pressed is the "abort" key but the address does not get entered or the "go" button pressed. This is because the program doesn't stop when it gets the ':00000001FF' record at the end.
It wouldn't be hard to make the reader stop when it does, or ignore lines beginning with "#" (the comment character used on most unix and derivative files). I keep meaning to massage this program, to add a few options, but my todo list keeps growing Last edited by Slothie; 29th Oct 2021 at 8:33 pm. Reason: Defined what 'it' is |
29th Oct 2021, 10:01 pm | #111 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
I have no objection to that idea - especially of allowing comment lines prefixed by '#' but I'm not sure how many hex file editors or readers will accept files with so much non-code outside of the code portions of the file.
Basically, you risk creating Hex files which are compatible with send14 but very little else. I can't think of any common hex file format which actually makes specific provision for the addition of text comments - they are supported as standard in source code, yes, but rarely or never in hex files. Instead of the end of the file try appending your text to the right hand end of each line instead - the uploader does not look at anything in the line beyond the checksum byte and it does not look for CR or LF so it doesn't depend on those characters to know where the end of the line is. From memory, the way it parses the line is, it looks for the 'start of line' character ':' Then it gets the 'number of data bytes in this line' figure from the appropriate offset into the line, and it uses that data byte count to determine how many data fetches to do from the line. Try adding a space + "Hello World" to the end of the first line of an otherwise standard Intel Hex and see if that makes it throw a wobbler. You're right that the script does not specifically deal with the 'end of file' record, there wasn't actually a need for it do do so until now. |
29th Oct 2021, 10:13 pm | #112 |
Tetrode
Join Date: Feb 2020
Location: Crawley, West Sussex, UK.
Posts: 77
|
Re: MK14 Programming Interface
Thanks for the thoughts - I thought there was no "proper" way of entering comments.
I tried adding the comments to the end of the lines which seems to work. I also found that I could enter "dummy" lines which did not cause the keys14 program to fail. e,g, :000F2000D1 Dummy line to add a comment basically a line containing 0 bytes |
30th Oct 2021, 10:03 am | #113 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
Consider going at it another way - Moon Landing, like all the other programs in the manual, was written to fit in the base 256 bytes of memory which was all that an MK14 was guaranteed to have, because the additional 256 bytes at 0b00-0bFF and the I/O RAM at 0880-088F were optional.
Back in the day 256 bytes was more than enough to have to type in, knowing that the whole lot was just going to vanish into oblivion the moment you turned the power off. Nowadays we don't have that problem, so consider writing a '640 byte enhanced' version of Moon Landing which starts up with a scrolling 'Attract Mode' message detailing the control keys and the aim of the game - You'd just need a slightly adapted version of the 'Message' program with exit to the main game on 'Go'. That's really more the sort of playing around which I hoped to encourage by making the uploader, which, combined with a decent cross assembler like SBASM, gives us the kind of MK14 code development system we would have killed for in 1978. |
30th Oct 2021, 2:51 pm | #114 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: MK14 Programming Interface
Actually for those with a VDU you could display your moon landing mockup graphic as a "loading screen" as well until someone gets around to actually writing it.
|
30th Oct 2021, 4:47 pm | #115 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
Mmm, or display a fixed lunar landscape showing an Apollo type lander whose vertical position is determined by the altitude figure. My original idea was to have the upper half of the VDU (Graphics) representing a changing 'view out of the porthole' and the lower half (Characters) showing the Altitude / Rate of descent / Fuel remaining as text labels / values.
Then there's that demo we talked about... I actually think the easiest(?) genuinely fun graphic game to write for the MK14 would be 'Pong', just need to figure out how to interface a couple of analogue pots - switched up and down wouldn't 'play' right, you need to be able to whizz to about where the puck will be and then fine-adjust to return the puck in the desired direction. Rotary encoders might be easier but they would be too 'clicky', they need to turn very smoothly. Last edited by SiriusHardware; 30th Oct 2021 at 5:01 pm. |
30th Oct 2021, 5:48 pm | #116 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
Looking around at 'traditional' AD-Converters like the ZN448 / ZN449 they are quite expensive now. Since the pixel resolution of the screen is only 64 pixels you could get away with reading only the 6 most significant output bits from the A-D for the bat vertical position but there are a few control pins which have to be wiggled as well.
Could use a PIC16F628 as a dual-joystick to MK14 parallel interface.. it would be easy to make one of those 'be' a dual-analogue-input to 6-bit-parallel-output chip, with one other pin used to tell the PIC which analogue channel to output the data from. Would that be cheating? I think so. But who really cares? Last edited by SiriusHardware; 30th Oct 2021 at 6:01 pm. |
30th Oct 2021, 10:43 pm | #117 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Programming Interface
I remember building a joystick interface for my PET back in the day that used a capacitor charging up through the potentiometer in the joystick and a comparator, so you would pulse a line to short out the capacitor and time how long it took for the capacitor to charge up. Thus you could get a very el-cheapo A-D conversion. I think I got it working well enough, but I don't recall actually writing any games to use it! But it might be an interesting and era-appropriate way to do it. Alternatively you could use a 555 to make a variable width pulse and time that, which would also be era-appropriate.
|
31st Oct 2021, 12:06 am | #118 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
I think the capacitor charge / discharge principle is the way a lot of the analogue stick interfaces worked at the time, possibly even the then standard PC analogue 'Game' port worked that way, I'm not sure.
I did also consider voltage to frequency / resistance to frequency converters or variable one-shot length (send a pulse, wait to see how long it comes back) using 7212x monostables, but the problem with those methods is they don't really produce a linear range of output values corresponding to the control resistance, so you probably end up having to have a look-up table to compensate. So my inherent laziness kicked in and took me back to something which will give me a nice linear 6-bit position value in one easy (and instant) parallel read. The 'historically nice' way to do that would be using two ZN448s or one ZN448 and a 4051 switching one of two pot wipers onto the analogue input of the ADC. From the point of view of making something which other people can easily follow / reproduce I like the idea of using a PIC with at least two analogue inputs and 6-bit parallel output rather better. I don't think we should get too hung up on the use of a microcontroller to emulate old school peripheral / interface ICs, after all, Ortonview uses a PIC family device which didn't exist when the MK14 was originally around. |
1st Nov 2021, 6:29 pm | #119 |
Tetrode
Join Date: Feb 2020
Location: Crawley, West Sussex, UK.
Posts: 77
|
Re: MK14 Programming Interface
Just saying that I've got my interface PCB working. It uses Charlieplexing which allows me to control all buttons using just 7 lines - which allows it to work with the ESP8266 module which does not have as many GPIO pins to use as the arduino.
It works with both the arduino and ESP2866 module when working like the original MK14send program - just amended o handle the Charlieplexing. My hope is to load a web server into the ESP8266 which can store the program and allow you to select the program to load from a web page. I'll let you know how I get on. |
1st Nov 2021, 6:36 pm | #120 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: MK14 Programming Interface
Woosh! (The sound of what you just said going right over my head...)
My original 2012 PIC based uploader charlieplexed the opto LEDs but there was never a PCB for it so it would have been a nightmare for anyone to try to replicate that original design on veroboard. Having a PCB available changes everything though, all the builder has to do then is put the right parts in the right places. Nice PCB - will be interested to see how this progresses. |