News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Computer data recorded to Cassette Tape

Started by GeoffB17, 16:20, 28 October 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

GeoffB17

This is about another retro computer, but MIGHT have some connection with the new thread about the Spectrum loader.


I still have my Epson HX-20 (from 1983), and I still play with it from time to time.


A major inconvenience is saving/loading progs to tape.


I've recently been experimenting with saving progs (and data) to my laptop, using the same cable I would use to connect to a cassette player, SoundRecorder to save the signal. and then MediaPlayer to play it back for loading.


This works quite well, and seems pretty reliable, and has the massive benefit that each file will be saved as a discrete file, no need to search a tape for the correct file.


The data is stored as a .WAV, although the default is a serious overkill quality, but I've tried reducing the quality somewhat and determined that the reduced file will still LOAD back.


So far, this is OK.


BUT, I would like to try to do a bit more with the data stored in the .WAV - i.e. turn it directly into something readable/printable.


This will entail turning the .WAV data into binary, and then into ASCII.


I've been looking into the raw data inside the .WAV - hmm??   But, if the computer can do it, even the HX-20 (and even the Spectrum and the CPCs) then it cannot be rocket science!


In the case of the HX-20, the recording uses a process where a 1 Khz signal is used for a zero bit, and a 2 Khz signal is used for the one bit.   I cannot see that there is any 'gap' data, it's just a continuous stream of bits.  Do the other computers do something similar?   Then, it's just down to the relationship between the timing, and the data, to translate the sampled data??   I.e. there'll be twice as much data for each '1' bit as for each '0' bit?


My original .WAV looks pretty hopeless, prob just too much sampled data.   The reduced one I have looks more hopefull, you can more easily see sound ON and OFF, but this may be misleading.


Are there any sources on the technical structure of the cassette recorded data?   Has anyone looked into what's recorded on the tape?   And how that relates to the actual readable data?


Geoff

robcfg

Would you mind posting a wav file of a simple program for us to take a look?


Many computers have some sort of header tones or header bytes and data packed in blocks with a control value to determine if it is corrupted.


More when we have a wav file!  ;D

GeoffB17

Thanks for the interest.


Yes, I'd have expected some sort of 'punctuation'!


I'll try to attach the data file I created.


The prog I used to create this was:


10 open #1, "cas1:data"
20 print #1, "AAAA"
30 print #1, "BBBB"
40 print #1, "CCCC"
50 print #1, "DDDD"
60 print #1, "EEEE"
70 print #1, "FFFF"
80 close #1


the default operation of the W7 SoundRecorder saved this as a .WAV at 44100, 16 bit, stereo but I subsequently used the XP version of SoundRecorder to reduce this to 22050, 8 bit, mono.  Even with this reduction, there may still be 11 times more data than needed??


Hopefully, I'll attach the .WAV, but I might need to change the .ext!  Yes, changed to .MPG, but it IS a .WAV


Geoff

robcfg

Did you sent the right wav?


I mean, there's 3364 bytes there, and I would expect it to have no more than 48-50 bytes (24 data bytes, AAAABBBBCCCCDDDDEEEEFFFF, and some form of mark to indicate beginning of data).

GeoffB17

Yes, that's the right .WAV.


I'm not sure what you're thinking of?   I don't see how it could be anything like the size you mention.


The prog ran, and it took quite a few seconds to feed the data through.   Each second of playing produced 22050 samples.   I assume the recording process converts the bytes into bits, so you're looking (I guess) at the possible number of bits BEFORE the sampling.   The data rate (of bits) is either 1 Khz or 2 Khz (for a zero bit or a one bit).   The sampling will be sampling the cycles, I think, not the indiv bits.   So the data will be at least 2000 cycles per bit?   Multiply by (I suspect) 11 for the relationship between the 22050 and the 2000.


I don't fully understand it all myself, that's why I'm asking.


My starting and stopping of the recording left some margin, so there will be some sampling of nothing before and after the actual data., but I don't think that will have added too much.

GeoffB17

Rob,


Doing a bit more calc, your suggested 3364 might be reasonable.   Number of bytes x 8 bits x a multipler of about 11 to reflect the sample rate relative to the date rate and we're getting towards 4000.


The important thing is - how have you got from the data in the .WAV file to the 3364 bytes?


Geoff

GeoffB17

I've checked my 'C' prog which is reading the .WAV file - at the moment, it's just reporting on the detail in the headers, But as I learn more about the rest of the file, I'll add more to the prog.


I confirm that my data shows that the data in 28.4 seconds long.   It was slow doing it.


The file contains 627203 samples.   That is about 22050 samples per second.  So that agrees.


Still cannot see where your 3364 comes from?


Oh, looking through the file, I note that the wave numbers gradually reduce through the file.   Could this be due to the battery voltage slightly reducing over the duration of the recording?


Geoff

robcfg

Hi Geoff!


There's no direct relation between the number of samples in the wave file and the bits represented on it.


The wav file contains silences, which obviously don't count towards the amount of information stored, and neither sampling or the recording hardware and storage medium are that precise.



QuoteThe important thing is - how have you got from the data in the .WAV file to the 3364 bytes?


Well, I developed a program to help me visually correct wav recordings, either because the original medium was damaged or the recording was unstable.


It's really easy to see the problem, but no audio editor works at wave level, so I had to develop my own tools.


Here's a screenshot of the tool I'm using to take a look at your file:


[attach=2]


Bits are encoded as sine or square waves of given frequencies. In your case, there are 1000hz waves (most probably meaning a 0) and 1800hz waves (most probably meaning 1).


My program recognises the waves and lets me change the values if I see an error. It also allows me to export the bitstream to a file than can be checked in a hex editor.


Not all waves represent data bits, there will be header/sync bits (also known as pilot tones) and some may represent parameters such as the number of data bits or control sums.


In the case of a wav from a Dragon computer, there will be 128 or 256 bytes with value 0x55 used as pilot tone, then a byte marking the start of a block of data, followed by one that tells the kind of block, another which tells the size of the data, then the data itself followed by a control sum and then the end of block mark.


Our problem is that we don't know how the HX-20 organises the information. It may even use more than 8 bits to store a byte of information. Still, it amazes me that you'd need 3364 bytes to store 24 data bytes.


It'll be interesting to learn how the computer does it.

GeoffB17

Rob,
The wave on your illustration looks VERY similar (not as 'clean') to the wave shown in the Technical docs for the HX, although that says the '1' wave should be 2 Khz rather than 1.8 Khz.   But I suppose 1.8 is close enough, certainly seems to SAVE and LOAD happily enough.
Very interesting.
The same doc did not give any hints about any 'punctuation', or extra info along with the data.   The doc is really about the built-in microcassette, not an external cassette which I am in effect using, although I know that someone has rescued a recording from a microcassette to a .WAV, and that file then loads fine as if from an external cassette, so I assume the data formats are the same.
As I said, you say there are 3364 bytes in my file.   That could be correct. Yes, it's a lot more than the data should be, but there could be 'punctuation', there could be duplication.   I suspect from listening to the data, and the fact that the LOAD recognises and reports on the filename, that a filename is saved, and I think this is duplicated.  IfI listen to a recording, I hear the start of the data, and I hear a brief squalk, then a constant tone, then the same brief squalk, then more constant tone, then into solid data.  The 'header section may have some other data there, i.e. a single char filetype (i.e. B for Basic Prog).
If there's another data type I could try that might help more?
Massive thanks for your help.

Geoff

arnoldemu

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

GeoffB17

Don't know about BBC.


I've changes my prog, to incl 'bar chart' type listing.   I'll compare data about sample 6891.


I'll have to try a conv to ASCII, and just do repeated tries until valid text appears?


Rather like Bletchley park 1942, using similar methods until valid German text starts to appear!


Geoff


WAVE1.ZIP contains TEST.TXT

GeoffB17

I've had a further play with my file.


Looks like samples 1 to 346 are a flat tone, no wave.


Samples 347 to 5737 seem to be a mix of '0' and '1', and look like they may be valid binary.


Samples 5749 onwards look like a fixed, static, '1' wave, i.e. the 2 Khz.


I've checked samples up to 50,000 only.   Out of 627203.   Could be the HX went into a 'wait' or something, or the PC receiving the signal did something odd.   I always thought that the 28.45 seconds for my 8 line BASIC prog was long, but it finished cleanly.   I'll look again at the binary .WAV file?


Anyway, there is NO correlation between MY samples about 6891 and the wave shown in your graphix/screen image.


?????


Geoff

robcfg

Success!  8)


I managed to find detailed info on how the data is stored, and I managed to get the data out of the last block of your file (just using a small set of data to test my code, you know).


The funny thing is that, according to the data, you saved the file from your HX-20 machine on October 22, 2017 at 18:42:08 (local time I guess).


[attachimg=1]


You can find the documents I mentioned above here: http://www.vintagecomputer.net/fjkraan/comp/hx20/doc/info.html


The one detailing the tape format is tmS_06-07.pdf.


I'll try to decode the whole file and then I'll upload the source code somewhere.


Take a look at the spec and you'll see that it's possible to waste 3364 bytes just to store 24 of them.


Thanks for giving me an interesting challenge!

GeoffB17

Rob,


Thanks.


Yes, I'd seen those docs.   I pored through them - I thought - all of them, looking for just this info.   There's some detail in an earlier doc about the general operation of the tape system, which gives some info, but I didn't get to this bit.   Maybe the somewhat indistinct heading got me missing it.


Yes, this doc does explain everything.   Incl the 'punctuation, and the blocks, and the chks.


I've just about worked out my own logic for reading the .WAV data and getting the bin and thereby the ASCII.


Clearly, it WILL be possible and practical to process the saved file, and product an ASCII version.   That's part one.   Then the possibility of taking a changed ASCII file and producing a SAVE file as a .WAV for re-load into the HX - more of a fiddle, but possible.   Need to re-build the .WAV file header, etc.


Editing progs on the HX is of course possible, but it is a fiddle with the 20x4 screen, and not much better with a larger 'virtual' screen with the 20x4 actual screen as a window on it.   Back when my TF disk drive was working, I would save larger progs to the disk as ASCII, transfer to another machine (at first the PCW, later a PC) do the major editing there, and then transfer back.


Re one point, I think that the system uses 'reverse waveform'.   Is that so?   All the indics seem to show the low part of the waveform first, then the high part.


I'm thinking I can just count the data bytes in the .WAV, using the specific format of .WAV I've chosen.  I'll need to step through x low bytes, followed by x high bytes.   There seems to be 2 or 3 of each for '0' bits, and 4 or 5 of each for '1' bits.   So, if the total is less than 8, that bit is a '0', and if more than 7, then it's a '1'.   That should do the job?


THANKS again.


Geoff

GeoffB17

Rob,


Just for your info, the date stamp on the PC files for the original .WAV data files are 22/10, and a time 23:40 something.   The timestamp in the file will be generated by the HX, and the time set on that will prob be a little out as the battery and charge is a bit hand-to-mouth.


I was never aware there was a timestamp put into the file.   Nothing in the normal use of the HX ever shows it!


One of the BASIC commands is FILES <device> which will play through the complete tape and list the filename of each file found in turn, but it takes a while to do a long take with xx files on it.  The filename is in the header block.  Rather more useful if you've got the Disk BASIC loaded, as FILES "A:" for example does a DIR of the disk - a LOT faster!!


Geoff

robcfg

Hi Geoff,


Definitely reading/saving programs from/to wav files is possible and even not that difficult.


I'd like to finish parsing your file and report the results back to you and then try to create a wav file from data for you to test on the machine.


Could you save a basic program and post the wav file here?


Cheers,
Rob

GeoffB17

Rob,


Thanks again.


Got one here, not too large.   Saved as ASCII, so should be readable.


Geoff

robcfg

Does your program look like this one?



10 PRINT"EPSON BIG PRINTER"
20 PRINT:WIDTH"LPT0:",8
30 PRINT"WHICH SYMBOL DO YOU"
40 INPUT"WANT TO USE";A$
50 CLS
60 PRINT"ENTER THE WORDS"
70 PRINT"YOU WISH BIG PRINTED"
75 PRINT"ON ONE LINE ONLY"
80 INPUT B$
90 G=LEN(B$):IFG>20GOTO60
100 X=G*6-1:DIMP(X,n D7):CLS
110 PRINT B$
120 FORY=0TOX
130 FORZ=7TO0STEP-1
140 P(Y,Z)=POINT(Y,Z)
150 NEXTZ,Y
160 FORY=0TOX
170 PRINT
180 FORZ=7TO0STEP-1
190 IFP(Y,Z)THENC$=A$ELSEC$=" "
200 LPRINT C$;
210 NEXTZ,Y
220 WIDTH"LPT0:",24:END



;)


Enough for today though.


I should be able to write it back to a wav file but I'll need to implement the CRC computation code first.


Also, I'm using the list of pulses that comes out of my DragonCas program which, given the good quality of your recordings, works quite well and I had only to discard only the pulses incorrectly detected in the silences between blocks.


We can discuss the preferred format of supplying the list of waves to the program, as it may not be something that can be done automatically.


Have a good night!

GeoffB17

Rob,


No!


;)


OK, almost yes!


Actually, you show line 100 slightly off.


Should be:


100 .......:DIMP(x,7):CLS


so you've got a couple of spurious chars in the DIMP bit.   Maybe a bit of 'punctuation' not spotted?


Everything else seems spot on.


Wonderful!!


Thanks again.


geoff

robcfg

Such are the perils of copying and pasting late at night...  ;D


The program is ok, I just copied the text from the resulting binary and accidentally copied the crc bytes along.


I'll integrate the HX-20 support into DragonCas as that way it'll be easy to check and convert wav files.


Then, I'll make a small command line program to turn any file into something the HX-20 can load.

robcfg

Well, not bad for a couple of hours of work:


[attachimg=1]


I still have to check how to compute the CRC and fix a couple of minor things. But all in all, I think it's coming along nicely  8)

robcfg

Ok, I tested the first wav file you posted, and it seems that both copies of the header block are damaged (looks like it started writing as the motor was starting to spin up).


As header blocks contain the length of the data blocks, my code was reading them without data. So I forced them to have 256 bytes, and I got the expected result:


[attachimg=1]


In yellow you can see the full data block and in green your data.


I'll take a look at the CRC algorithm this weekend.

robcfg

Success!


I discovered hot to compute that damned CRC, so now I can try to pick a file on my computer and convert it into a wav file for the HX-20.


The information on the HX-20 is quite good, but I had to investigate to learn that the start value of the CRC computation depends on the block number... times 0x911!


Anyway, I'm glad I got it working  8)

GeoffB17

The crunch will come when I try to LOAD something.


Can get around that a little, if you just create a different data file, as long as you tell me the format, I can try to INPUT #1 from it, and if I can do that OK, then the format must be OK.   If a data file is OK, then a prog file should be OK too.   I believe!


Thanks.


Geoff

robcfg

Hi Geoff!


The time has come!  ;D


Please try the attached wav file on your HX-20. It will most probably fail due to some weird thing I wasn't aware of, but it will be worth the try.


It's a small basic program. If it loads, run it and, if it works, please post a picture!

Powered by SMFPacks Menu Editor Mod