MK14 Tape Interface

[Slothie]

I might give this a go tomorrow... I've got a 16x2 edge connector (cut down 17x2 IDC connector - not sure what from but hey it fits) and I'm sure my box of bits will supply wire and pins etc. I'm getting the bits together for Pi interface (got the opto couplers just awating a pi zero connector, my sister found my pi zero, didn't know what it was and put it in the box for my laptop!)
I'm still working on working out the timing tolerance on the tape interface I'm just having trouble battling with my memorys of C++.....

[twostickes]

I have updated the utility to convert HEX to WAV.
It now accepts command line options -i (invert the data) and -p (add 3 second preamble tone),



https://github.com/twostickes/MK14WAVwrite

[circuitryboy]

The KYBD routine in either Monitor scans from 0 to 9.
So the code will drive a 9 digit display, if you have one.
And then end of loop "Goes to Ten" outputting 0F09 to nonexistant 0D09.
End of loop causes a slight delay before next scan and that 'phantom' 10th digit prevents actual leftmost digit appearing brighter than the others.

[SiriusHardware]

I take it by 'invert the data' you mean it replaces what was originally 'tone' with 'no tone' and what was originally 'no tone' with 'tone' as per the hardware method discussed earlier - so to replay the inverted version of the tone into the MK14 you would need to have an inverter between the TI digital output and SenseB / SIN?

Can I ask if the hex loading function can handle address breaks in the hex file? For example the 'Message' program occupies two distinct areas, and if that hex file is generated by an assembler it will place the program code at addresses 0F20 to 0F46, then the start address of the next Intel Hex line would be 0FA0, because that's where the message data starts. I'm assuming that your program would require the contents of the whole memory space 0F12-0FD1 to be defined in the hex file, with padding-out data in addresses 0F47-0F9F.

I'll take my cassette interface PCB to work with me tomorrow or Friday and check it out using a function / signal generator. I don't think it has been powered up since the early 1980s.

Circuitryboy, acknowledged, useful information as always.

[JohnBHanson]

The device driver in xbeaver ( rt.drv) does actually handle gaps in the code
correctly by including padding in the output stream to cover the gaps. This of course increases the load time but it does work.

What has to be done of course is entering the correct address of the first byte into the mk14 otherwise the code is loaded into the incorrect place.

[twostickes]

Hi Sirius -
inversion will do as you say. Its only a wav file, so it would be expected that inversion would be supplied. So its of little use unless your system is equipped with inversion, probably if someone was using this technique. The default is no inversion.

No it doesnt handle the address breaks yet, I was thinking of generating separate wav files for each break in the address. Its useable, in that the output filenames include the start address such as DUCK_0f12.wav so a couple of wavs can easily be loaded separately.

I might get around to it soon!

[SiriusHardware]

I would suggest that for simplicity you just state that the code in the file has to be continuous from first address to last address.

Originally if you typed in 'message' and saved it to cassette you would just save the block from 0F12 (beginning of program code) to 0FD1 (End of message data), which would mean that all of the un-initialised RAM contents from 0F46_0F9F would get saved as well but at least then it was just one save and one load.

I already noticed your filename convention includes the start address of the code as a reminder of the start address to type into the cassette firmware's start-address pointer - maybe also include the option for the user to specify the execution address as well so that something like 'Moon Landing' would be saved with a filename like "MOON_0F14_0F52.wav" so it includes a reminder of the program GO address as well as the load address.

[twostickes]

Sirius - very good advice, yes I forgot about the addresses for load and execute can be different. hmm will work on that!
I also noticed that a game called OneArm (by Paul Robinson, 1998) uses two sections 0f20 and 0b00, which cant really be contiguous.
This may also allow for data dumps into VDU space although i cant think of a situation where that might have occured back in the day!
So i guess a bit of both, trying to keep it contiguous if feasible, change the filename convention, and if not possible then split the files.
Obviously im second guessing what a normal user would have done with their tapes!
Thanks for that!

[SiriusHardware]

The cassette interface firmware routines only allow for a maximum of 256 bytes to be loaded and saved, so something like ONEARM which uses the extra 256 bytes of RAM would actually have to be saved out and loaded in in two steps.

[SiriusHardware]

I've had my (original) MK14 tape interface juiced up for the first time probably in decades at work today. I took a few measurements and was surprised to find that it only needs about 70mV of audio-in from the tape player to produce a logic '1' out - far too sensitive really. For most of its life the audio input's series capacitor had been changed to a few hundred pF and this was obviously intended (by me) to attenuate the input and shave off anything remotely resembling bass.

I have taken the opportunity to change the input capacitor back to the correct value and type, and if the input sensitivity with the original values is a problem I will just attenuate it off-PCB with a voltage divider.

Going the other way, putting data into it and looking for gated audio tone coming out I thought it wasn't working at first until I remembered that the audio-out would be at a very low level intended to go into a microphone input. When I wound the scope gain up, the audio-out was actually there after all.

I've rigged up a wiring 'loom' which should make it equally easy to attach to my original MK14 (4.43MHz) or my issue VI replica (4.00MHz).

[SiriusHardware]

Further to the above, I've just realised I made the classic mistake of forgetting I had the x10 attenuation turned on when looking at that input waveform so actually, it requires an altogether more respectable 0.7V P-P audio input level for the interface to produce a logic '1' out.

[twostickes]

Thanks Sirius, your efforts are helping me with this. Yes line input around 700mV sounds familiar. Ive had to step down mine too with a divider for PC socket. At the moment, the wav file is using 50% modulation (from its maximum rail-rail peaks), it could easily be changed but maybe its the job for the volume / interface cable.
I have converted a couple of my old cassette recordings to wav, they all seem quite low in amplitudes, I guess each person had different tape decks and setups.
When I used to make a file I sometimes spoke to say what the data stream name and address was (not always!). Maybe I should add a computer voice to the wav too (joke!)

[Timbucus]

Originally Posted by twostickes

When I used to make a file I sometimes spoke to say what the data stream name and address was (not always!). Maybe I should add a computer voice to the wav too (joke!)

I used to do that for my ZX81.

Karen would have rigged the Peripheral system to make Eddie do the announcement automatically... hmm interesting project...

[SiriusHardware]

Quick update: I've just tried loading twostickes's pre-generated non-inverted non-preamble version of the DUCK_0F12.WAV file into my 4.00MHz issue VI replica, via my original SOC Tape interface, from two different playback devices.

The first was an old Creative Technology 'Zen Nano Plus' MP3 player. It's very small so it would be a handy way to carry MK14 code around but unfortunately that one did not work - it kept on loading the same code pattern every time but not the right code. I think it is possible the CT player is making a 'phut' sound as playback starts and maybe that is being read as a false leading zero bit.

Then I tried loading the file into 'Audacity' on a little Dell Windows XP netbook to 'decode' the first byte of the file by eye and see if it was actually 'C4' as it was supposed to be. It was, so there was nothing wrong with the way the audio file had been saved.

The other thing I meant to do while I had the file in Audacity was to slow the playback down by a given percentage - I thought that maybe if the file had been saved with 4.43MHz timing then maybe it needed to be slowed down to be played back into a 4.00MHz machine.

Before I did that, I just tried playing it back from the Dell Netbook into the MK14 and... it worked first time and every time I tried it after that. If the DUCK_OF12.wav file in the Github archive was written out at 4.43MHz timing then I can say that it loads into a 4.00MHz machine without any modification. While I had it all rigged up I also tried running the supplied MOON.HEX file through MK14WAVwrite (ran it from a CMD prompt under Windows XP), loaded the resulting .wav file into Audacity, played it out to the MK14 and that also worked first time every time.

To fix the situation where a playback device makes a 'click or 'thud' at the start of playback I suggest that your -p (preamble) switch should not only add three seconds of tone to an inverted output file, it should add three seconds of silence to the beginning of uninverted wav files. Then the user would be able to press play('thud'), then press GO, then at the end of the lead-in silence the MK14 would start loading the actual code.

Yes, adding a 'voice header' just before the data recording was pretty much standard otherwise you soon wouldn't know which recording was what when you had a whole tape full. Tape counters were always useful in this respect as well.

[SiriusHardware]

Originally Posted by Timbucus

Karen would have rigged the Peripheral system to make Eddie do the announcement automatically...

I saw my spare SPO-AL256 allophone synth IC again somewhere while I was hunting for bits to connect up the tape interface. Very tempted to try connecting it to the MK14. I have, somewere in the loft, a 'Currah Microspeech' for the Spectrum which also uses an SPO IC. If I could find it and connect it up to one of my Spectra, that would be a less painful way of re-learning how best to connect all the various allophones together before doing it on the MK14.

[twostickes]

Hi Sirius, great info and ideas as always thanks. yes i will add a blank time to the start of non inverted, non preamble files. It would mean if the player produced a bump or click, then this interval would provide a time between starting the wav and pressing GO on the keyboard, as you would on a real tape, and seems a similar thing with your MP player.
ill also look at the timings again, and default it to 4.43MHz and create an extra -4 switch for the 4.00MHz xtal. I might have to research to be sure if any differences exist in FRTAPE routine in case SOC defaulted the timings for different default xtals. Maybe I should default the switch it the other way around.

[twostickes]

Timbucus dont tempt me! Is it an awseome feature or a step too far?

[SiriusHardware]

Sounds quite cool if it isn't too much trouble to do, is there an off the shelf 'library' for text-to-speech in the programming language you are working with? Only one condition, it has to sound like Joanna Lumley...

[SiriusHardware]

Originally Posted by twostickes

I might have to research to be sure if any differences exist in FRTAPE routine in case SOC defaulted the timings for different default xtals.

Don't take my word for it and do check anyway, but I'm sure you will find that the timing in software and firmware versions of the cassette routines never changed, because to the best of my knowledge the kits were always supplied with 4.43Mz crystals because they were widely used in colour TV sets, made in huge numbers and therefore cheap.

The crystal was generally only ever changed to 4.00Mhz to meet the needs of the Science Of Cambridge VDU add-on. (That one you have with a 3.2768 MHz crystal sounds as though it must have been used for something which needed a realtime clock, but that's definitely a one-off).

Saving code out to tape with a lower frequency clock didn't matter because of course the code was also loaded back in at the same slower speed. I think you could easily get away with writing the code out at the 'in between' data rate and machines with either clock would load it. You probably don't need to provide for two different rates.

[Slothie]

I've been trying to use my "Arduino" emulation to work out the tolerance to speed but keep getting snagged on technical issues. (For those interested, I was trying to use the delayMicroseconds() call to get more resolution, but that fails silently above 16mS so I needed a combination of delay() and delayMicroseconds() calls and calculating that with preprocessor commands was problematic and then it got late.....)
However testing so far suggests that there is enough variance for a tape written on a 4.433619 Mhz machine to be readable on a 4Mhz machine. It just occurred to me this minute that my PIC14 emulates a 4Mhz machine so I can use that for testing... watch this space!