|
Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment. |
|
Thread Tools |
9th Jan 2021, 4:06 pm | #61 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
Slothie has just made me realise that as I have two working MK14s I could type the software TTAPE routines into one of them and muck about with the 'soft' timing values on that to send logic-level tape data directly to the other MK14 at different data rates - that's if the logic levels are the same polarity in both directions (I have not checked).
However, that would involve climbing into the loft to get my real MK14, and I don't really want to spoil all the fun which Slothie is obviously having with this. |
9th Jan 2021, 5:43 pm | #62 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Tape Interface
You know that monster that lives in the loft misses you if you don't go up there from time to time....
|
9th Jan 2021, 6:16 pm | #63 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
I think you must be confusing it with the one which lives under my bed.
Thanks for the shout-out about the less than ideal behaviour of the Delay function in Arduino which I would have been bound to run into eventually - You'd think the compiler would warn if you try to specify an unsupported value. So have you solved that yet? Last edited by SiriusHardware; 9th Jan 2021 at 6:30 pm. |
9th Jan 2021, 7:40 pm | #64 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: MK14 Tape Interface
Not quite... some parts arrived for my Pi keypresser and I spent the day making up a 16 way cable and edge connector combo, and trying to get my head around the layout of the opto-couplers. It's surprising to me how few hours I get undisturbed without someone or other popping in to give me meds or take a test (we're being monitored twice a day for temp due to the covid thingie) or to bring in tea, or to chat.... I'm not complaining but it surprises me how little I get done considering I've basically only got to occupy myself.... Going to have another look at the tape thing tonight because its sparked my interest...
As for the delay thing, to be fair it does say in the Arduino docs online that the delay "becomes inaccurate" above about 16000 microseconds, although I'd say "wildly inaccurate" would be more the phrase. I'm going to just calculate the delay in milliseconds and microseconds and have 2 delays for the timings.I wasted a lot of time trying to do it in the preprocessor but that only seems to do 16 bit unsigned arithmetic and therefore percentage calculations were a bit beyond it. So I'm going to redo it all to do the calculations at runtime. |
10th Jan 2021, 8:35 pm | #65 |
Triode
Join Date: Dec 2020
Location: Durham, County Durham, UK.
Posts: 20
|
Re: MK14 Tape Interface
Hard to keep up with you guys, thanks for these efforts, I hope they are fun! I just pushed a new version to github, it now includes a silent gap at the start of the WAV file when -p preamble switch is not used so the user can press GO to read the tape after the tape drive / mp player initial bump.
still working on a split function for hex files with separate address blocks, hopefully soon. |
11th Jan 2021, 8:59 am | #66 |
Triode
Join Date: Dec 2020
Location: Durham, County Durham, UK.
Posts: 20
|
Re: MK14 Tape Interface
Here is an early copy of Practical Electronics page I found somewhere on the web, showing an (original?) TI design by Nick Toop, and some RAM based tape routines. So Im guessing it was the original intention to have the voltage dividers on board (but not on the production version).
The routines are showing different delays as the issue iv board, so this may indicate there may have been a difference in timing , so I suppose I could run these routines and compare timings on the 'scope , hopefully they are the same ! |
11th Jan 2021, 2:59 pm | #67 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
Good find, I've never seen that before.
I'll give the latest version a test drive tonight, thanks for sorting that out. With any luck the new lead-in silence will let it work with the little MP3 player. The final SOC TI PCB does have a voltage divider of sorts on the output (has to really, to take the TTL-level signal out from a logic IC down to something small enough to feed into a microphone input). To judge from what I found earlier it looks as though they decided to go with a line-level tone input, maybe not the wisest choice as most of the actual tape machines likely to be used would only have had a low-impedance 'phone' output. |
11th Jan 2021, 6:28 pm | #68 |
Pentode
Join Date: Jun 2012
Location: Bristol, UK.
Posts: 115
|
Re: MK14 Tape Interface
I use that PE tape input circuit.
It works well with RCA CD4001. I found long ago that some other makes don't function. The code is very similar to that in SCIOS monitor, with the same deficiencies. I run at 4MHz, so did some recalculation and select-by-test for the DLY parameters. |
11th Jan 2021, 7:37 pm | #69 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: MK14 Tape Interface
Yes that submission to Microbus which was published as an article in October 1978 (The one with Part1 of the PE VDU) pre-dates him working for Sinclair I suspect:
https://worldradiohistory.com/UK/Pra...cs-1978-10.pdf Look at Sheet 68 As he says in the article, it was originally developed for the SC/MP Introkit with the Keyboard Kit. Perhaps it got him the job at SoC, as he designed the Interface for them along with the PROM programmer and VDU cards. He reviewed the MK14 in Issue 2 of PCW May 1978 where he stresses he has nothing to do with SoC... " As an independent consumer I was very impressed by this kit. Its low cost and versatile but economic design are very pleasing. I am sure that it will have great success." The article is followed by one by W.G.Marshall that goes over the SC/MP in some detail. You may like this snippet from him as well: https://groups.google.com/g/comp.arc...m/g4mT2lHVzv4J |
11th Jan 2021, 9:59 pm | #70 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
TS, I've just given your latest version a quick try but the files generated don't seem to load from the XP netbook any more the way the ones from the previous version did.
Have you changed the data rate by any chance? Audacity shows that the silent lead-in time is just under two seconds, was that the interval you intended? I'm wondering if the whole file has been generated a bit too 'fast'. The machine is loading code and it loads it exactly the same way every time, but wrong. The first byte (should be 'C4') loads as '04' - the LSB of the byte is received first by the MK14 and the MSB last, so it looks as though it is loading the lower nibble of the byte OK but then going out of sync by the end of the byte. |
12th Jan 2021, 5:00 am | #71 |
Pentode
Join Date: Jun 2012
Location: Bristol, UK.
Posts: 115
|
Re: MK14 Tape Interface
Are all subsequent bytes distorted?
If the Toop loop 'gets confused' with first byte then the entire bit stream is 'sliced' into out-of-synch octets. |
12th Jan 2021, 10:27 am | #72 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
From the way it loads the same incorrect sequence of bytes every time I would say it's a timing problem, but I will try it again tonight with a file generated by the earlier version to make sure I don't suddenly have a hardware problem.
|
12th Jan 2021, 7:17 pm | #73 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
Quick update:
I've just loaded the DUCK_OF12.wav file which worked the other night into Audacity and that (leaderless) file is about 18 seconds long. I then loaded the DUCK_0F12.wav file generated with the newest version of MK14WAVwrite and that file, even with the two second silence on the front, is exactly the same length (18 seconds) - in other words it looks like the original 18 seconds of audio tones has been compressed into 16 seconds, which of course means that the data rate / byte lengths will be correspondingly higher / shorter. I don't know if this was an intentional change by TS so I'll await further input from him before trying any further testing. |
12th Jan 2021, 7:43 pm | #74 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
Further update, I used Audacity to alter (slow) the speed of that 2s +16s file so that the audio portion of the file came out at 18 seconds long, as per the version which originally worked. That altered version works perfectly, so it's definitely an issue with the data rate / bit length in files generated by the newest version of the MK14WAVwrite utility.
The speed of the (modified) working version of the WAV file is about 89 or 90 percent of the speed of the version produced by the latest version of MK14WAVwrite. Last edited by SiriusHardware; 12th Jan 2021 at 7:54 pm. |
12th Jan 2021, 7:54 pm | #75 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
And one further thing - I transferred the modified file (18 seconds of audio tones but with a silent lead-in header) over to the little MP3 player and that now works, so clearly the problem there was that the player was making some kind of extraneous sound when waking up from being paused. The new 'silent header' provides a space in which to press 'Go' between the start-up thump/click and the beginning of the audio tones proper, so that was worth doing.
|
12th Jan 2021, 11:46 pm | #76 |
Triode
Join Date: Dec 2020
Location: Durham, County Durham, UK.
Posts: 20
|
Re: MK14 Tape Interface
It was a bug!
Ive pushed a new release.. Fixed pip speed (bug in last release). Added -x switch. When set will create longer pips (ie 4.00MHz xtal) |
12th Jan 2021, 11:57 pm | #77 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
Well, that's what we beta testers are for
Bit late tonight, but will give it another test drive tomorrow. |
13th Jan 2021, 8:24 pm | #78 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
Initial results from V1.12 (Thanks for incorporating a version number): Both with a 4.00Mhz machine.
-DUCK file generated with no switch, ie, 4.43Mhz default data rate - loads OK -DUCK file generated with -x switch (geared down for 4.00Mhz data rate) - loads OK. |
13th Jan 2021, 9:59 pm | #79 |
Triode
Join Date: Dec 2020
Location: Durham, County Durham, UK.
Posts: 20
|
Re: MK14 Tape Interface
Unpaid Beta Testers! No really I do appreciate you doing this. The only other thing to do is to try and split files that need separate loadings.
I also did think of adding voice to the wavs (maybe a -v option to repeat the filename in voice form) but it gets quite cumbersome for a command line app, didnt really find a library but I did put together a set of pre-recorded wav file of letters and numbers using https://cloud.google.com/text-to-speech. Maybe I could just concatenate a few of those into the wav before the data stream, ive added a sound file to see what it would sound like. Its not quite Joanna Lumley! |
14th Jan 2021, 12:42 am | #80 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: MK14 Tape Interface
I suppose the value of this audio feature depends on how you think or how you mean the program to be used. If it's used to create tapes by playing the file it creates out to an actual tape recorder then it will be useful and the 'format' of the audio labelling of the file will be consistent - the only problem I can see is in getting it to say the name of the program which is being saved, like 'duck' or 'moon', can your method stretch to that?
If the main purpose of the utility is to create files which can be played out from digital devices then the spoken header is less useful and having the load and execution addresses embedded in the file name is the most useful aspect. With regard to handling split addresses, there are a few scenarios to consider: 1) A hex file with split blocks in the same 256-byte block of memory with a gap separating them. (Example: 'Message'). In this scenario the best approach would be to pad the empty space between the blocks with some byte value like 00 and then output the first block, the padding, and the second block as one audio file, similar to the way John (JBH's) program for the Gemini does it. 2) A hex file with split blocks which reside in different 256-byte blocks of memory. (Example: 'Onearm'). In this case the program will have to output two separate cassette data files. Reject files where -There are more than 256 bytes in one continuous run -A code block straddles a page boundary -The addresses in two blocks of code overlap In otherwise valid files, discard any code blocks with an address which does not exist on the MK14 (but do allow code which is designed to go into the range 0200-07FF since it is possible to map extra RAM into that area) |