UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio 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.

Reply
 
Thread Tools
Old 8th Mar 2019, 11:09 pm   #1
Karen O
Hexode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 466
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.
__________________
Karen O

Temporal Paradox: Kills all known grandfathers. Dead.

Last edited by Karen O; 8th Mar 2019 at 11:11 pm. Reason: incorrect word fixed
Karen O is offline   Reply With Quote
Old 9th Mar 2019, 10:14 am   #2
SiriusHardware
Nonode
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 2,626
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 offline   Reply With Quote
Old 9th Mar 2019, 4:24 pm   #3
Karen O
Hexode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 466
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

Temporal Paradox: Kills all known grandfathers. Dead.
Karen O is offline   Reply With Quote
Old 12th Mar 2019, 7:30 pm   #4
SiriusHardware
Nonode
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 2,626
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 offline   Reply With Quote
Old 12th Mar 2019, 8:23 pm   #5
Karen O
Hexode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 466
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

Temporal Paradox: Kills all known grandfathers. Dead.
Karen O is offline   Reply With Quote
Old 18th Mar 2019, 10:56 pm   #6
SiriusHardware
Nonode
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 2,626
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:	29
Size:	11.6 KB
ID:	180170  
SiriusHardware is offline   Reply With Quote
Old 19th Mar 2019, 7:08 am   #7
Karen O
Hexode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 466
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

Temporal Paradox: Kills all known grandfathers. Dead.
Karen O is offline   Reply With Quote
Old 19th Mar 2019, 11:10 am   #8
SiriusHardware
Nonode
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 2,626
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 offline   Reply With Quote
Old Yesterday, 2:19 pm   #9
JohnBHanson
Hexode
 
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 303
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   Reply With Quote
Old Yesterday, 6:21 pm   #10
SiriusHardware
Nonode
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 2,626
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 offline   Reply With Quote
Old Yesterday, 6:36 pm   #11
Karen O
Hexode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 466
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

Temporal Paradox: Kills all known grandfathers. Dead.
Karen O is offline   Reply With Quote
Old Yesterday, 7:18 pm   #12
SiriusHardware
Nonode
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 2,626
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 offline   Reply With Quote
Old Yesterday, 8:11 pm   #13
Karen O
Hexode
 
Karen O's Avatar
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 466
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

Temporal Paradox: Kills all known grandfathers. Dead.
Karen O is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 9:10 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 - 2019, vBulletin Solutions, Inc.
Copyright ©2002 - 2018, Paul Stenning.