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: 463
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,624
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: 463
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,624
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: 463
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,624
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:	21
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: 463
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,624
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
Reply

Thread Tools



All times are GMT +1. The time now is 1:53 am.


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.