UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 12th May 2019, 11:47 pm   #81
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

I didn't realise the diagram for MK14man's version was available anywhere - I confess I have not been to his site for a while because he seemed to have gone completely off-grid for a number of years - but maybe the details were always there and I just missed them. I don't seem to be able to compete with your (by now legendary) data mining ability.

Although it's good that the programmer could work with the MK14man design after all, that design is so flexible in terms of how the address decoding is done that it ought to be quite possible to reserve an address range as PROM, map some of the non-volatile memory into that range and provide the machine with built-in serial download routines, if indeed that is not already the case. Or, the existing cassette handling routines and jump calculator could of course be replaced with serial download code.

For original machines I considered it essential that the method used should not require any modification at all to the hardware / firmware or consume any RAM or hardware resources not already used by the monitor, so that was why I ended up doing it the way I did.

It was an accidental bonus that it turned out to be possible to upload code at much higher speed than I had expected - I had thought the OS's key debounce delay would limit the upload speed far more than it does.
SiriusHardware is online now  
Old 25th Jun 2019, 6:35 pm   #82
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

Another little dribble of information, another forum member has confirmed that the external keypad connector on his original issue V MK14 has the same connection layout as the external keypad connector on my original issue II, around which this programmer project was made.

This implies that original issue III and issue IV MK14s probably have the same external keypad connector layout as well, although nothing is certain when it comes to Science Of Cambridge.

There remains the question of whether the 'Issue V' Czech replicas made by Martin L also have the original MK14 keypad edge connector layout. If anyone knows for sure, please let us know.
SiriusHardware is online now  
Old 25th Jun 2019, 7:59 pm   #83
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: MK14 programming interface - MK2

Good to know - we are slowly closing the knowledge gap!

Quote:
Originally Posted by SiriusHardware View Post
There remains the question of whether the 'Issue V' Czech replicas made by Martin L also have the original MK14 keypad edge connector layout. If anyone knows for sure, please let us know.
I am 99% certain it is - I have not built the board as yet but, tracing the tracks they seem to go to the same pins I can see in photos online on IC13 on real ones - which seems to support the same layout. The routing on the JM Precision is very different as a lot are taken from the switches rather than direct tracks.
Timbucus is offline  
Old 15th Jul 2019, 9:37 pm   #84
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

Another different, brilliant (and potentially very fast) way of getting code into an MK14, three videos (in chronological order) on the subject from the creator of the JMP replica MK14s.

https://www.youtube.com/watch?v=yg2P5I3URrw

https://www.youtube.com/watch?v=-_N0OOj-uvs

https://www.youtube.com/watch?v=0OytcbqWwAY
SiriusHardware is online now  
Old 15th Jul 2019, 10:12 pm   #85
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: MK14 programming interface - MK2

Had an OP80 on my watch list for sometime - that seals the purchase decision I think... nice spot on the videos.
Timbucus is offline  
Old 15th Jul 2019, 10:41 pm   #86
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

One I missed earlier (The fourth in the series).

https://www.youtube.com/watch?v=y6xaCgKht-I
SiriusHardware is online now  
Old 11th Aug 2020, 9:25 pm   #87
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

My thanks to our mods for re-opening this thread.

As mentioned elsewhere, a bug has been discovered in the uploader scripts for both the Arduino version and this Raspberry Pi version, originally posted in #9 of this thread, from which the Arduino one was derived.

The bug prevents any Intel Hex line with a checksum of '00' from being loaded. My bad.

You can fix an already established and fine-tuned setup just by swapping the two lines of code indicated in image [1] so they look like image [2], or you can replace the existing faulty script with this fixed version, attached. If you are replacing the original script you may have to make the replacement script executable by your username as explained in the body of the text in #9.
Attached Thumbnails
Click image for larger version

Name:	send14_checksum_bug.jpg
Views:	87
Size:	52.2 KB
ID:	213274   Click image for larger version

Name:	send14_checksum_bug_fixed.jpg
Views:	79
Size:	41.6 KB
ID:	213275  
Attached Files
File Type: zip send14.zip (3.8 KB, 106 views)
SiriusHardware is online now  
Old 18th Oct 2020, 12:05 pm   #88
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: MK14 programming interface - MK2

Did you ever post the final fixes for the corrupt execution address for the PI? Just more relevant for the VDU now.

I have two custom versions of the script I use as I have added extra Opto's so that I can control all the lines - to use it to simulate a full matrix KB in future and allow me to not have flying leads with different wired connectors for the JMP and Standard connector layouts (easier to just use the script for the layout).

I would love to merge the scripts and make the key layout a command line switch but, have not had time or sufficiently developed python skills... I am hoping a DIFF from the original to yours or mine will allow to create bug fixed version for the moment.

If not maybe I can look at the arduino one for what needs to be done.
Timbucus is offline  
Old 18th Oct 2020, 9:39 pm   #89
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

As you know I've 'released' a fixed version for the Arduino version just in the past day or so but not yet for the Pi version, I just have to do the same edits. I'll get to that some time this week, and then you can maybe compare the differences between that 'mainstream' version and your custom versions.

If you want to have a go yourself the main differences are:

- Variable 'OutputMode' no longer initially declared near the beginning of the script.

- There is no longer an 'If...' querying the state of 'OutputMode' in function 'PressMK14Key'

- The part of function 'SendFileToMK14' which looks to see whether the current line commences at FFFE, or whether the current line commences at an address which does not follow on from the most recent address programmed, has been rearranged quite a bit so that the program's response to the value of 'OutputMode' is dealt with locally within that function.

The variable 'OutputMode' has the default value=1, meaning that whatever data is found in the current line should be written out to the MK14. If the line address is found to be 'FFFE', 'OutputMode' is set to 0, which instructs the script to continue to process and checksum the line as a valid line of Intel Hex, but not to write it out to the MK14.

Although this was always the intention, it wasn't actually working as originally written and the two data bytes in the execution address line were being written out to FFFE-FFFF. Due to the incomplete address decoding, the actual result of this was that the bytes were written to 0FFE and 0FFF.

I should warn you that if you try to make any substantial edits to a python script, work on a copy of the script and not your working original. This is because it is incredibly easy to mess up the indentation which indicates code blocks which follow if.. statements, etc. and if that happens it can be very difficult to get the script back into shape.
SiriusHardware is online now  
Old 19th Oct 2020, 10:59 pm   #90
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

A mere three posts later, yet another revision of the 'send14' python script which powers the Pi version of the MK14 uploader. Hopefully this is the last one for a while. This revision addresses the problem whereby, as a side effect of using the 'autorun' feature of the uploader, the 2 bytes of the execution address would also be written to address 0FFE / 0FFF and therefore also to the status register which controls the hardware flag outputs.

To run this script under Linux you will need to make the script executable by your username, just as you would have had to do with the earlier versions. Also as with earlier versions, you may find that you have to increase the delay constants for the length of a keypress, the after-release delay and the length of the reset phase and the post-reset delay from my defaults - if you are already running an earlier version, edit those timings to be whatever worked for you in that version.

A reminder that if you use the uploader to load actual code which overwrites address 0FFF, that data will also be copied (by the monitor) to the status register and therefore to the flags. The workaround is to load the data intended for 0FFF into some other RAM location at the uploading stage and then copy it to 0FFF after the monitor has handed control over to your user program.
Attached Files
File Type: zip send14.zip (3.8 KB, 98 views)
SiriusHardware is online now  
Old 20th Oct 2020, 11:31 am   #91
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: MK14 programming interface - MK2

I watched your video, the keying speed is impressive and watching it key in a program is much more fun than a serial hexloader
Phil__G is offline  
Old 20th Oct 2020, 11:47 am   #92
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

It goes a lot faster than I originally expected.

I thought the key debounce routines in the MK14 monitor would limit the maximum 'typing' speed more than they do. The main reason for doing it that way - (having the uploader 'type' the code in) - was for zero impact on genuine original machines, no reason to add extra hardware or make changes to the firmware, it also uses no 'soft' resources (like RAM) or 'hard' resources (Flags or Sense inputs) which are not already used by the monitor.
SiriusHardware is online now  
Old 20th Oct 2020, 11:53 am   #93
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: MK14 programming interface - MK2

Quote:
Originally Posted by SiriusHardware View Post
It goes a lot faster than I originally expected.

I thought the key debounce routines in the MK14 monitor would limit the maximum 'typing' speed more than they do. The main reason for doing it that way - (having the uploader 'type' the code in) - was for zero impact on genuine original machines, no reason to add extra hardware or make changes to the firmware, it also uses no 'soft' resources (like RAM) or 'hard' resources (Flags or Sense inputs) which are not already used by the monitor.
Having looked at the monitor code briefly, I'm not sure there is much de-bouncing code in there. I think it just relies on how slow the SC/MP scans the keyboard! I'm getting minor problems with key bounce on my PIC14 (probably due to the cheap switches I'm using) although I can''t say I noticed it much on my prototype replica and I've not heard you or Tim mention it - although I think there we're using bigger higher quality tact switches.
Slothie is offline  
Old 20th Oct 2020, 12:49 pm   #94
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

I have very low force switches fitted to the issue IV, so the nearest thing I get to key bounce is when I inadvertently press a key again as I'm taking my finger away. That's the other reason the uploader can go so fast of course, the optos are electronic switches and never bounce.

The very first time I used a scheme like this for programming large amounts of data into something through its keypad, I used relays, because I happened to have a lot of small relays available. You can imagine the noise it made when working but it was totally worth it for the amount of work it saved.

It was for programming all the parameters - held in RAM and therefore dependent on constant power - back into a very large alarm panel in a rural area. If the mains failed for long enough to run the backup battery down, which it did about once a year or so, hundreds of alarm nodes and their names, etc, had to be programmed back in by hand through the front panel keypad, a highly tedious and potentially very error prone process of course. I only did that once, and then immediately afterwards I made a gadget to do it for me while I sat having a cup of tea and a biscuit. It was a bit slower than this uploader but the main thing was that it entered every character correctly, first time, every time.
SiriusHardware is online now  
Old 20th Oct 2020, 12:52 pm   #95
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,080
Default Re: MK14 programming interface - MK2

CMOS bilateral switches like the 4066 would be another alternative
Phil__G is offline  
Old 20th Oct 2020, 1:18 pm   #96
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: MK14 programming interface - MK2

Quote:
Originally Posted by Phil__G View Post
CMOS bilateral switches like the 4066 would be another alternative
Or try two of 4051 if you don’t need the isolation of optoisolators.
Mark1960 is online now  
Old 20th Oct 2020, 1:28 pm   #97
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

Yes, I've mentioned the possibility of using two back to back 4051s a few times - the main thing I don't like about that is the lack of isolation - I wanted to be able to upload demo software into the MK14 and then unplug the interface to leave the MK14 running stand-alone. Otherwise the use of a pair of 4051s is a great way to do it and requires very few lines of I/O (...7) from the controlling micro.
SiriusHardware is online now  
Old 9th Dec 2020, 10:06 pm   #98
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: MK14 programming interface - MK2

I debated if this was the place to document this to some extent but, my current project needed an ASCII keyboard and a way to type in BASIC programs. So this topic may get its own thread eventually as might my Triton - anyone out there with one of these ETI machines that makes it worth starting a thread?

Anyway I have jury rigged my MK14-PI-Key-Programmer (c) Sirius as a way to generate a 7 bit ASCII keyboard output and strobe for my Triton. I will adapt Karen's PIC based one to provide a full keyboard but, this works for testing and will allow data entry once I have adapted the send14 script...

I basically use one of the Column Opto Isolators to connect 5v to the common rail and then use the Row ones (which have a 4.7K pulldown - I know not a good idea on TTL) to provide the data bits and the Strobe line - there are two more that could become the Parity and a different strobe.

There are limitations obviously the biggest that CTRL C and Z have a meaning on Linux - I have just rigged CTRL D to be CTRL C for the moment as my Python is limited. I also map LF to CR so the return key works as I would expect.

Also the Triton in real terms should have strobe high for the duration of the key press - again this is beyond my low level Python - I will probably just write it in C eventually but do a Python version of the SEND14 that can talk Triton monitor for HEX entry and do entry of long BASIC programs from Text files.

Hopefully this might give others a launch point anyway as it gives the same isolation benefit for Vintage machines...

Click image for larger version

Name:	Pizero_Interface ASCII.jpg
Views:	69
Size:	74.8 KB
ID:	222233 Click image for larger version

Name:	IMG_4387.jpg
Views:	65
Size:	78.6 KB
ID:	222234

The script at the moment is just:

Code:
#! /usr/bin/env python3

# PI Key ASCII programming interface test utility.

import curses
import RPi.GPIO as GPIO
import time

scan=curses.initscr()
curses.noecho()
scan.nodelay(1)

# Minimum length of one keypress (seconds)
StrobeLength=0.04

# Initialise all GPIO ports used by this program
def SetupGPIOs():              
    GPIO.setmode(GPIO.BCM)
    GPIO.setwarnings(False)
    Pins=[27,18,17,4,22,23,24,9,25,8,5,7,12,6,16]
    for x in range (0,15):
        GPIO.setup(Pins[x],GPIO.OUT)
        GPIO.output(Pins[x],GPIO.HIGH)
    GPIO.output(4,GPIO.LOW)
    GPIO.output(5,GPIO.LOW)

# Momentarily assert the binary bits of the character submitted 
# together by activating their associated GPIO port pins
def PressKey(k):
    b = 0

    Pins=[22,23,24,9,16,25,6,8]

    for x in range (0,7):
         b = (k >> x) & 1
         print (b, end="")
         if b == 1:
              GPIO.output(Pins[x],GPIO.LOW)


def ClearKey():
    Pins=[22,23,24,9,16,25,6,8]

    for x in range (0,7):
         GPIO.output(Pins[x],GPIO.HIGH)


# Tidy up before exit    
def CleanUp():
    GPIO.output(4,GPIO.HIGH)
    GPIO.cleanup()
    curses.endwin()

# Main program: Exit with ESC or CTRL-C 

#Initialise GPIO pins
SetupGPIOs()

try:        
    while(1):
        inp=scan.getch()
        if inp>1:

            inp=chr(inp)
            # inp=inp.upper()
            inp=ord(inp)

            if inp==10:
                inp=13

            if inp==4:
                inp=3

            print (inp,end=" ")    # Show the character pressed
            PressKey(inp)

            GPIO.output(5,GPIO.LOW)

            time.sleep(StrobeLength)

            GPIO.output(5,GPIO.HIGH)

            print ("\r")
            ClearKey()

            if inp==194:      # £ is BREAK 
                CleanUp()
                break

except KeyboardInterrupt:
    CleanUp()
Timbucus is offline  
Old 10th Dec 2020, 12:38 am   #99
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: MK14 programming interface - MK2

Ah! Well, it's finally happened, someone taking the basic setup and using it to phantom-press the keys on an entirely different machine. I always expected that it would be an Acorn System 1 or Kim-1 or another micro-trainer not too different to the MK14.

I have no problem with the thread widening out this way but bear in mind that it will probably swing back onto the original topic if we find we have to make further amendments to the MK14 send14 script or the opto hardware.

I remember the Triton but I don't know it, so I don't know whether the Triton keyboard had totem-pole data and strobe outputs. If so you'll have to disconnect the keyboard when this interface is active otherwise the optos will try to pull the totem-pole outputs of the keyboard to hard+5V regardless of their actual state.

Does the Triton's real keyboard use a dedicated key matrix to binary output encoder, similar to the 74C923 (...which only supports up to 20 keys, so obviously not that one).
SiriusHardware is online now  
Old 10th Dec 2020, 1:19 am   #100
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: MK14 programming interface - MK2

I remember the Triton, it was a kit made by Transam and published as a series of articles in ETI. It looked like a great project but at the time it was out of reach for me.
Slothie is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 5:43 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.