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 8th Mar 2019, 11:09 pm   #1
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Mk14 programming

I offer this suggestion purely as an idea (I haven't tested it) and it is in no way intended to compete with SiriusHardware's rather brilliant programming interface.

I believe that all but the earliest monitor ('SCIOS') included cassette routines to load and save programs. These used pulses to encode each bit - a short pulse (~4 millisec for a '1' and ~30 millisec for a '0' or something like that). This tape system had no means to delineate bytes - if a bit was missed the whole load was corrupted!

I often wandered about using a PC's serial port at, say, 200 baud. At this rate, sending the character 0xff sends a 5 millisec pulse (the start bit). A character 0xe0 sends a 30 millisec pulse. I rather suspect the system would work in reverse as well, i.e. the pulses produced by the Mk14 save routines would be interpreted as those characters by a PC.

As I said, it's a completely untested idea. It would need only a simple interface (the actual Mk14 cassette interface would not be required). But, it would involve pre-setting of memory (load start address) and manual program start, unlike SH's solution which gets you straight into the loaded program automatically.

Last edited by Karen O; 8th Mar 2019 at 11:11 pm. Reason: incorrect word fixed
Karen O is offline  
Old 9th Mar 2019, 10:14 am   #2
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

I've always been amazed by your left-field use of serial ports, not least to generate a video output, of course. I've also heard of people using them as primitive PWM outputs as well, for motor drive projects.

File I/O using the raw cassette data input and output streams has been tackled before, especially, once again, by Martin Lukasec, as in here...

http://www.8bity.cz/2018/tape-emulat...cambridge-mk14

...where he uses an Arduino to 'record' the raw cassette data stream from the MK14 and replay to it. All of his MK14 stuff is worth reading through (there is a 'translate' button upper right on the page, or your browser may offer to translate it).

Your suggested method has the theoretical advantage of needing hardly anything (other than a level shifter) between the PC and the MK14.

Why not have a go?
SiriusHardware is online now  
Old 9th Mar 2019, 4:24 pm   #3
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 programming

I will give it a try some time, on my Mk14 emulation of course

Serial ports for PWM, eh?
Karen O is offline  
Old 12th Mar 2019, 7:30 pm   #4
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

I've had a bit of a look around specifically at serial ports and it seems it might be quite difficult to get an old-school RS232 PC serial COM port to run at a non-standard baud rate, unless I'm missing something. (I realise that for you, 'difficult' is a novel concept).

In other situations (PIC microprocessors would be a good example) you have a freely programmable UART clock which is often taken advantage of in order to generate a non-standard baudrate of 31250 (For MIDI), and on the Raspberry Pi it is (was?) possible to alter the clock feeding the UART divider chain so that setting a near baud rate such as 38400 in, ie, terminal software, results in an actual baud rate of 31250.

Do standard PC serial ports lend themselves to being wrangled onto non standard baud rates without having to go straight to the hardware registers? I have to admit I have never looked into it.

(The newer USB serial comms cables / leads might be a lot more flexible in this respect).

Edit: Just came across this, which seems to suggest that FTDI based serial USB devices allow 'soft' reprogramming of one standard baud rate with a non standard one, so that when software selects the replaced baud rate it will actually select the modified baud rate.

https://www.ftdichip.com/Support/Doc..._BaudRates.pdf

Last edited by SiriusHardware; 12th Mar 2019 at 7:43 pm.
SiriusHardware is online now  
Old 12th Mar 2019, 8:23 pm   #5
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 programming

Hi SH,

Yeah, it might be a problem finding a suitable Baud rate. I think the Mk14 cassette interface uses a threshold of 16 millisec (or thereabouts) to distinguish short pulses from long. So long as the chosen Baud rate can meet this I think there's a good chance it'll work. 300 looks like a good choice: 3.3 millisec shortest pulse, 30 millisec longest. 33 millisec bit period.
Karen O is offline  
Old 18th Mar 2019, 10:56 pm   #6
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

I gave Karen's idea a go, but only in one direction (from the PC to the MK14) so far. I made up a little interface (diagram attached).

I don't have any sort of modern PC programming toolchain so I had to do a bit of OS time travelling, and dug out a Win '98 laptop on which I have Qbasic V4.5.

After a bit of experimentation - I had some difficulty remembering how to send a single byte to the com port - and twiddling with various values, I arrived at this:

Code:
CLS

'Define the RS232 '0' and '1' bit characters.

'For a zero, 0 11111111 1 = start bit (L) + 8 data H + Stop (H)
zero$ = CHR$(&HFF)

'For a one,  0 00001111 1 = start bit (L) + 4L data + 4H data + Stop (H)
one$ = CHR$(&HF0)

'Initialise COM port
OPEN "com1: 300, N, 8, 1, bin,cs0,ds0" FOR OUTPUT AS #1
'Adjust UART COM1 clock divider registers to get 320 Baud
'For 320 baud, UART DLM = 01H, UART DLL = 68H
'To write DLL and DLM set DLAB=1 (Base addr + 3, bit 7)
OUT &H3FB, &H83 'Dlab switch = 1, access second layer registers
OUT &H3F8, &H68 'Write DLL value H68 320bd
OUT &H3F9, &H1  'Write DLM value H01 320bd
OUT &H3FB, &H3  'Dlab switch = 0, return to primary layer registers

'With a load start address of OF12 this range of values should
'fill 0F12-0FF0 with the data 12H to F0H, so when looked through
'after loading, the data in each of those addresses should equal
'the low byte of the address.

FOR ValueToSend% = &H12 TO &HF0 ' Sequential values to send out

FOR BitNumber% = 0 TO 7 ' Bit pointer

BitMaskValue% = (2 ^ BitNumber%)

IF (BitMaskValue% AND ValueToSend%) = 0 THEN
         PRINT "0"; : PRINT #1, zero$;
ELSE
         PRINT "1"; : PRINT #1, one$;
END IF

NEXT BitNumber%

PRINT ' Move down one display line

NEXT ValueToSend%

CLOSE #1
I started off at 200 baud but found that the overall length of one 'MK14 bit' was rather longer than 32mS, enough to scramble the values being sent.

Twiddling around, I arrived at a baud rate of 320 as this resulted in an MK14 bit time of roughly 32ms according to my wheezy old scope, and I also modified the 'one' byte value from E0H to F0H so that one low start bit + 4 low bits + 4 high bits +one high stop bit gave the 'one' bit a roughly 16ms on, 16 ms off structure.

The penalty was that the 'zero' bit was then only one tenth of an MK14 bit time long instead of one-eighth which was what was really required.

In practice, however, it works.

I didn't go to the extent of loading in a binary file and sending its contents to the MK14 - anyone who wants to take it that far can easily do so, instead, I hit on the idea of just sending the consecutive values of a FOR-NEXT loop, from 0x12 to 0xF0, to addresses 0F12 to 0FF0. If the MK14 reads the characters correctly the locations 0F12 to 0FF0 end up containing data = the low byte of the address, so it's easy to see whether the code in any address in that range is what it should be.

To try this, do the following steps on the MK14:

Reset
0 F F 9 Term
0 F Mem
1 2 Mem
Abort
0 0 7 C
Go

(The MK14 displays go blank).

Run the Qbasic program and let it run to the end, until the interface LED stops flashing.

On The MK14, hit Reset and then look through the locations OF12 onwards, you should find the locations have all been programmed with values equal to the low byte of the address.

Interesting footnote: After all the trouble I went to to fiddle a non standard baudrate, I then tried it at 300baud. (Comment out the OUT lines in the code). It still worked!

So you could probably do this on a modern computer using Python or C or VBasic without having to worry about how to generate unusual baud rates.
Attached Thumbnails
Click image for larger version

Name:	MK14_Via_Serial.png
Views:	138
Size:	11.6 KB
ID:	180170  
SiriusHardware is online now  
Old 19th Mar 2019, 7:08 am   #7
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 programming

Blimey! It actually works!

Thanks for testing it out, SH.

The next challenge will be a bit-banged HDMI interface
Karen O is offline  
Old 19th Mar 2019, 11:10 am   #8
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

Given a fast enough device, I would not actually put that past you.

As with the other method, there is a caution concerning whether the MK14 involved has a 4.43MHz (as original) crystal or a 4.00MHz crystal, which some originals may have post-VDU and some replicas (like your PIC14) may have by default.

However, I think this is a rare case where having a 4.00Mhz crystal fitted / emulated will actually help, as it will extend the length of the MK14's tape stream 'bit time' slightly and may make it a closer match for 300baud.
SiriusHardware is online now  
Old 25th Mar 2019, 2:19 pm   #9
JohnBHanson
Heptode
 
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 661
Default Re: Mk14 programming

For those of you that use linux - setting the baud rate is possible, but rather intricate as it uses a different mechanism for standard/non-standard baud rates. Typically setting the baud rate takes about 300 lines of code!. However to save effort look at tty_host.c in

http://81.105.120.101/download/xbeaver.tgz

this will give a good starting point for the code.
JohnBHanson is offline  
Old 25th Mar 2019, 6:21 pm   #10
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

When time allows, I will try going in the other direction using plain 300bd - if that works then mucking about with the baud rate may prove unnecessary, although it is useful to know that Linux makes it possible.

I just need to build an interface to go the opposite way - for people less paranoid than I am, the interface for both directions can be a standard MAX232 level shifter circuit with inverters inserted in the TTL level data lines on the way to and from the MK14.

I have a mortal fear of directly connecting any independently mains powered equipment to the 0V line of the MK14, because so many switch-mode PSUs have tingle-inducing low-current 110VAC superimposed on their 0V output.

That's why I'm obsessed with using optocouplers to interface to it.
SiriusHardware is online now  
Old 25th Mar 2019, 6:36 pm   #11
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 programming

Quote:
I have a mortal fear of directly connecting any independently mains powered equipment to the 0V line of the MK14, because so many switch-mode PSUs have tingle-inducing low-current 110VAC superimposed on their 0V output.
Very wise, SH. I had troubles with an analogue circuit a while back. It turned out that a SMPS I was using was injecting mush into the system ground. The result was that, to my circuit, I, my bench, my 'scope, and everything even remotely earthed appeared to have mush on it.

Keep up the good work.

It has come back to me now: the Mk14 cassette interface does not have stringent requirements on pulse width. The crude ASK modulation scheme of the published cassette interface alters the pulse widths anyhow. I think there's a threshold of around 15 millisec. So long as long and short pulses comfortably straddle this threshold, the Mk14 should decode them okay.
Karen O is offline  
Old 25th Mar 2019, 7:18 pm   #12
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

It certainly seems to be that way for upload, which arguably is the most desirable direction of the two for it to actually work in since there are now so many ways in which a hex file can be prepared / generated off-MK14 for transfer to it.

What seems less predictable is how individual PC (and other) UARTs will choose to tolerate marginal RS232 bit lengths when going in the other direction, it may come down to whether they only sample the state of each bit in the middle of the bit, or sample the bit more often.

You would have to be some sort of masochist to want to always compose code initially on the MK14 and save it out to some sort of storage nowadays, but of course that was exactly what we did back in the day, when the MK14 was the only 'computer' of any sort that we had. Back then, the cassette interface was absolutely vital.
SiriusHardware is online now  
Old 25th Mar 2019, 8:11 pm   #13
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 programming

UARTs are all much the same. They wait for a falling edge, wait half a bit time to see if the line is still low. If so it just samples the line on full bit time spacings to gather in the bits. It then times half way into the stop bit to ensure that it doesn't start looking for a new character too soon.

Some (like the PIC) sample three times at each bit centre and take a best of three determination of the bit state. Others just sample once. Regardless, a UART won't be upset by a state change mid-bit but there is uncertainty about what it will latch for that bit.

The upshot is, you'll probably have to tolerate a character of 0x00 OR 0x80 for a long pulse, and 0xff OR 0xfe for a short pulse (or something like that)

I think the Mk14 inter-pulse gap is adequate but set the serial port for one stop bit though.
Karen O is offline  
Old 29th Mar 2019, 10:47 pm   #14
JohnBHanson
Heptode
 
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 661
Default Re: Mk14 programming

The tape interface connected to a pc could be a useful way of reading mk14 tapes and
recovering lost programs. Most PC RS232 inputs will accept 0/5Volt inputs directly from the tape interface - just connect the output from the tape interface to pin 2 of the 9 way d, pin 5 as ground and supply ground and 5 volts to the tape interface.

Good luck.
JohnBHanson is offline  
Old 30th Mar 2019, 12:56 am   #15
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 programming

I think you're right, JohnBH. Every RS232 receiver I've ever used sliced the signal at +1.5V or thereabouts. That's a better noise margin than a TTL input for an HCMOS source!
Karen O is offline  
Old 3rd Apr 2019, 10:16 pm   #16
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

Results just in:

I wrote another Qbasic program to read single characters from the com port and display them as 2-digit HEX in rows of 8 across, therefore each group of 8 received characters representing the LSB to MSB of one received byte.

I entered the values 0x00 to 0x0F in successive locations and saved those 16 locations out to tape.

I tried it first with baud=300 - the Qbasic program fell over with a 'device I/O error' as soon as the MK14 started sending.

I then changed the baud rate to 320bd using the method shown in the Qbasic program in post #6 of this thread, and got this:

Code:
FF FF FF FF FF FF FF FF FF
F0 FF FF FF FF FF FF FF FF
FF F0 FF FF FF FF FF FF FF
F0 F0 FF FF FF FF FF FF FF
FF FF F0 FF FF FF FF FF FF
F0 FF F0 FF FF FF FF FF FF
FF F0 F0 FF FF FF FF FF FF
F0 F0 F0 FF FF FF FF FF FF
FF FF FF F0 FF FF FF FF FF
F0 FF FF F0 FF FF FF FF FF
FF F0 FF F0 FF FF FF FF FF
F0 F0 FF F0 FF FF FF FF FF
FF FF F0 F0 FF FF FF FF FF
F0 FF F0 F0 FF FF FF FF FF
FF F0 F0 F0 FF FF FF FF FF
F0 F0 F0 F0 FF FF FF FF FF
This is exactly right, given FF = '0' and F0 = '1' and the bytes are sent from the MK14 LSB first.

So that's all good, as long as you have a way to set non standard baud rates. It looks as though 300bd is just 'wrong' enough to cause an RX framing error. The MK14 tolerates 300bd when going in the PC-to-MK14 direction, but the PC is more fussy going the other way.

This was me using an MK14 with a 4.43Mhz crystal, of course. If you have an MK14 with a 4.00Mhz crystal it may very well work with 300bd.
SiriusHardware is online now  
Old 3rd Apr 2019, 11:19 pm   #17
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

..The eagle eyed among you will have noticed there are nine values per byte in the output in the previous post.

That wasn't really the case, the extra bytes were 'gained in translation' when I hand-transferred them by manually typing up the values I could see on the screen of the old DOS PC.

...It's been a long day.
SiriusHardware is online now  
Old 4th Apr 2019, 9:11 pm   #18
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

After a bit more tinkering on, here is a short Qbasic program which reassembles each group of eight received 0xFF / 0XF0 characters into the original byte values and displays them as Hex. As mentioned earlier, I found it necessary to reprogram the baud rate to 320bd in order to get it to work in this direction. It falls over at 300bd.

Code:
OPEN "com1: 300,n,8,1,ds0,cd0,cs0,RS" FOR INPUT AS #1
'Adjust UART COM1 clock divider registers to get 320 Baud
'For 320 baud, UART DLM = 01H, UART DLL = 68H
'To write DLL and DLM set DLAB=1 (Base addr + 3, bit 7)

OUT &H3FB, &H83 'Dlab switch = 1, access second layer registers
OUT &H3F8, &H68 'Write DLL value H68 320bd
OUT &H3F9, &H1  'Write DLM value H01 320bd
OUT &H3FB, &H3  'Dlab switch = 0, return to primary layer registers

CLS
begin:
LET Chars% = 1 '  "Bytes displayed per line" counter
DO WHILE Chars% < 17
LET K$ = INKEY$: IF K$ <> "" THEN CLOSE #1: END '   Any key to exit
ByteValue% = 0
IF NOT EOF(1) THEN
  FOR BitNumber% = 0 TO 7
  LET RSinput$ = INPUT$(1, #1)
  IF ASC(RSinput$) = 240 THEN LET ByteValue% = ByteValue% + (2 ^ BitNumber%)
  NEXT BitNumber%
  LET H$ = HEX$(ByteValue%): IF LEN(H$) < 2 THEN LET H$ = "0" + H$
  PRINT H$; " ";
  Chars% = Chars% + 1
 END IF
LOOP
PRINT '  Move print cursor to new line
GOTO begin
I've also attached the full diagram of the interface. The lower portion is the interface going from the PC to the MK14, already seen earlier, above, but included again here for completeness.

The upper portion is the interface going from the MK14 to the PC: A lot more complicated than JBH's 'Direct connect' method, but as explained previously I am very protective of my 40+ year old antique machine, so this version uses the obligatory optocoupler while incorporating JBH's idea of not worrying about generating the negative RS232 input voltage swing.

Due to the isolation the MK14 obviously can not supply any voltage drive east of the optocoupler so the circuit relies for its pull up on DTR being high when the RS232 port has been initialised / is in use, which it usually is. The diode is there in case DTR ever goes to -9V while the interface is connected.
Attached Thumbnails
Click image for larger version

Name:	MK14_Via_Serial_Port.png
Views:	140
Size:	26.5 KB
ID:	180893  
SiriusHardware is online now  
Old 5th Apr 2019, 5:15 am   #19
TonyDuell
Dekatron
 
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 5,190
Default Re: Mk14 programming

The PC TxD line will swing -ve -- in fact it will be negative (-12V on many machines) most of the time. So shouldn't you add an inverse-parallel diode to the LEDs in the 'to MK14' section (the red indicator LED and the optoisolator) to protect them against reverse bias?

I also wonder (without trying it) if you could connect the red indicator LED in series with the optoisolator LED and have one series resistor and inverse-parallel diode.
TonyDuell is online now  
Old 5th Apr 2019, 8:57 am   #20
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 programming

I considered reverse protection for the PC-To MK14 LEDs as you have suggested but decided that the series resistance would be enough to keep the LEDs - which are themselves diodes, of a sort, safe for this experimental setup. I agree that powering the LEDs in series would also be perfectly valid.

I've never really looked into how much reverse voltage a LED can withstand.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 5:48 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.