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

Rob,

I'm looking through the raw hex data of your file.

I'm looking at bits only, but I'm not finding the sort of variation of data that I think should be there.   Am I just missing it.  The file is big, so it's a bit like looking for a needle in a haystack?

Your file is 44.1 Khz.   I'be confirmed that less still works fine, certainly 22,050, maybe even lower.

There will be a number of bytes of sample data for each cycle.   I calc that at 44.1, for 1 Khz, there will about 44 samples, made up of 22 of minus, followed by 22 of plus.   If it needs to be a 2 Khz signal, then it'll be 11 bytes of minus followed by 11 of plus.   BUT, these numbers can vary by 1 or 2, I assume the timing has a few %% leeway, based on my study of the files I've created.

If I'd got to the point of trying to translate the data, I'd expect be finding the first (-) byte in the .WAV data, counting the following (-) bytes and then the following (+) bytes.   Note the total and reset the count.   If the total is say 30 or more, then that bit is a '1', if the total is less than 30, then the bit must be '0'.

One thing on 'reading' the data, but as suggested, how to make adjustments when 'writing' to keep the overall timing OK?

Geoff

robcfg

QuoteI'm looking at bits only, but I'm not finding the sort of variation of data that I think should be there.   Am I just missing it.  The file is big, so it's a bit like looking for a needle in a haystack?


Well, there's a lot of sync '1' bits, then at least 40 '0' bits, and then the actual data begins.


QuoteYour file is 44.1 Khz.   I'be confirmed that less still works fine, certainly 22,050, maybe even lower.


Indeed, but if you are trying to digitally process the wave data it makes things easier to have more samples, at least in my experience.


Anyway, I made a new wav with its waveform reversed. It shouldn't be that as the machine calibrates itself, but it doesn't hurt to try.


I'm trying to take a look at how HXTape works, but it's written in php...


I really think we're quite close to nailing it.

GeoffB17

Rob,

Thanks for Rob9 - however, tried the usual things, and nothing is detected by the HX.

I looked at the file within SNDREC32, and the image looks MUCH more like my last file (Rob6r was it?).   The wave is now more blocky, looks generally more like the files I've created.  However, still not a help if data not seen at all.

Regarding HXtape, I think I looked at that, but as far as I could see, it was simply mimicing what I can do already, i.e. save the normal tape output to a PC as an audio file, and re-load the same file again later.   I don't think it tries to do anything with the audio data.   However, if it does give any hints, well great.

PHP isn't really a problem as far as the language is concerned, it lies somewhere between 'C' and HTML, the problem would be setting up all the surrounding stuff, usually something like Apache to drive the HTML and the PHP module to be invoked via the HTML as it's processed by the Apache.   It is possible to set up Apache on a single user machine, but it seems a bit heavy handed.   Why this process was done via PHP I don't know.

Are we getting close?   I'll be pleased when the HX actually recognises SOMETHING, even getting an IO error would be massive

Geoff

GeoffB17

Rob,

I've looked again at the HXTAPE stuff, which I had tucked away on my HD.

Yes, there could well be a lot of useful info in there.   It's a bit back-to-front to what we're trying to do, hence my confusion, and in fact is maybe bypassing any supposed .WAV file.   The SAVE process is intended to write - say - a BASIC prog to a tape which can then be LOADed, or even in fact bypass the tape totally by sending the audio data (not even .WAV ?) in a form that appears to the HX as if it's coming from a tape.   Is that your understanding?   The LOAD process is the reverse.

I note it can cope happily with encoded BASIC, and will automatically translate the tokens for the BASIC keywords.   That's helpful.

The source is, as you said, php, but it looks substantially 'C' to me.   Many of the commands/functions have direct 'C' equivalents.   I see some that I'm not familiar with, but I'm sure the operation of those could be simulated.   I've got a couple of books here on PHP.

I'm trying to see if it uses any special libraries, but I think not.

The function to handle the CHK would be very helpful.

There may be stand-along processors for PHP, but note that PHP is usually interpreted rather than compiled.

So, on second/more detailed look, there IS prob a lot here worth checking.   May be able to bypass the whole .WAV thing?

Oh, there's an email address for the writer.   I tried that a while back, it's no good now.   I traced him also via some GitHub things, but that was out of date too.

Geoff

GeoffB17

Doing some further digging, the hxtape process is intended for use on a linux system, using the linux PHP CLI (command line interface) i.e. NOT as part of Apache, or connected with .HTML files

It seems there is a Windoze variant of this, usually known as PHP.EXE - this appears to be a similar system, although it may not support ALL the functions used in the hxtape progs.   Have to try it and see, any not supported may have to be recreated within the package.

PHP.EXE comes as 'thread-safe' and 'not-thread-safe' variants.  I'd guess that for what we might want to do, the non-thread-safe versions (smaller) will be perfectly OK.

According to one of my books, if the full cmd line activation does not work you need to do it via a batch file.

Geoff

GeoffB17

Hmm, found an item on the web.

Seems that hxtape package does use a linux library, something called OSS (Open Sound System), although how this is used in the progs I didn't spot.   This package may NOT be available to Windows.   In fact, it's not readily available for linux either, having been superceeded?

Do a google search for 'use of hxtape' and follow an item from Stephen Paukner - some usefull comments there?

Geoff

GeoffB17

Rob,

I've been trying some digging, both in the PHP code, and about the web to find out more about some things.

Firstly, there's the oddity in the progs, in that the SAVE process is actually doing the loading of the data onto the tape (for the HX to LOAD) while the LOAD process is the opposite.   I suppose it depends on your thinking from the computer end, or the HX end?

Yes, as noted, the system uses the OSS stuff.   Which is assumed to be part of the Linux system.   The prog defines a 'stream' via dev/dsp, and then opens this for input or output depending on the module.   So what happens within the 'dsp' area is outside of our control?

The BIG question is what is the relationship between whatever happens within dsp and our present use of the .WAV file?   It may be, not a lot.   When I SAVE a file from my HX, the HX turns it into audio, which would happen anyway.   This audio goes into the computer audio input, and I assume into the DSP system?   I assume then that SoundRecorder (prog) gets the data from DSP, and at this point it's raw data?   It becomes a .WAV, and a specific variety of .WAV, ONLY when I save the data from SR?   Is that so?

There are some WinDoze processes regarding DSP that seem to be accessible, unfortunately the process for getting data out of a dsp block is more accessible (it seems) that the process to put data back.   The former is specifically sound.   The latter seems to be video and sound, although it could (?) be just sound, but either way seems rather more complicated.

I like the idea of having a specific file for each prog, or data file.   The .WAV format is rather BIG, but with current HD sizes this isn't a major problem, and reducing the bit rate helps.   So .WAV is OK.   The hxtape stuff doesn't hint at the size of his files, it would be a big help to see one?   I wonder is anyone have saved one - there are certainly .WAV files for HX20 on the web.   I'll look!

Oh, I see that the hxtape process uses a few 'wait' spaces?   Not sure yet if that's time based, or a block of data?

Thanks.

Geoff

GeoffB17

Rob,

Talking to my brother just now.   He's got a number of linux machines, so may be able to sort out a run of hxtape with my HX-20 attached, to save something, and check load back.

Would that be any help, looking at the file that hxtape creates?

Brother is offshore just now, need to wait until he comes back.   So could be a couple weeks or so.

Actually, the laptop I've been using to save/load the files has linux on it, but I don't know too much about linux - just played a bit.   Linux is interesting, but it's such a chew on to do even the simplest of things.

Geoff

robcfg

It could be interesting to see hxtape's output and compare.


Most probably I have not enough sync waves or way too much.


I'll try to give it another go this weekend.


Cheers,
Rob

GeoffB17

Thanks Rob for the update.

I've looked again at the site I mentioned a couple of posts ago, re Stephan Paukner (NB, it's Stephan, not Stephen as I noted before).

I've sent him an email, in case he has a saved file he could let us have.   His blog posting suggests he HAS saved thing OK.

One thing I've just noted, he refers to the useage of the HXBASIC prog - the format of the use of this (to de-tokenise the prog) suggests that hxtape much be saving the file pretty much in the HX-20 format.   If you look at the code for the prog, it pretty much reads the file and replaces the tokens with the ASCII command, not much else.   Resulting in, in effect, the file as if it was saved with the ,A parameter (which to be honest is easy enough to do anyway).

If he sands anything/replies, I'll let you know.

Geoff

GeoffB17

Rob,

I've got a reply from Stephan Paukner, with some attached files.

Not very helpful, I suspect.

The .BIN files seem to be encoded basic, and could well be just the memory image (or however it's stored) that would be in the saved file.   The .BAS files are the ASCII translation.   No hint of any of the 'punctuation' present in the saved data.   Is there evidence that the .PHP prog is removing stuff, so as to save what's here, and adding the framing etc data bach when putting it back to tape?

Oh - don't know why yet, but I was medding with that little data file from a while back, the one with the AAAA, BBBB, etc.  I wrote a little prog to read it back in, and it didn't work.   I tried the FILES command, and nothing.   I tried to load a couple of the progs, and they worked fine.   So that DATA1 file is NOT reliable.   I'll try something again.  The FILES command should work OK with a data file, just giving a couple of different codes with the filename compared with a basic prog file. 

Geoff

GeoffB17

Rob,

I've re-done that test data file, very slightly altered.

This time, I did the usual save as a .WAV, which defaults to 44.1 Khz, 16 bit, stereo.   I then used the SndRec prog to cinvert the file, I did it to 8 Khz, 8 bit, mono, which VASTLY reduces the file size.

I then wrote another little prog to read the data from the reduced file, which worked fine.

I then tried the FILES command, this one correctly saw the file, and reported correctly on file name, type, etc.

So the earlier one was clearly dud in some way.

I then ran the reduced file through my own display prog (text wave only !) - this should display all samples (+) to the right, all samples (-) to the left, so should give a wave, of sorts, top to bottom.   Of course, a 1 Khz sample should have about 8 samples, and a 2 Khz wave should have 3 or 4.

For your info, I attach a zip with the new .WAV, also my processed wave.   Can you spot anything on the wave regarding data?

Geoff

GeoffB17

Rob,

Ooops, I forgot to mention, although it may not matter to you.

The HX data file is called DATA4.   My then modified version is DATA48.

Geoff

robcfg

I can read it right, my problem is saving the files back to wav.


[attachimg=1]



Most probably, as I said earlier, I have too many sync waves or less than needed.


Ok. Your file has almost 13 seconds of '1' bits before the first block, I have nowhere as much and that could be the problem.

GeoffB17

Rob,

Thanks for the note.

Can you tell me the line numbers in my file for the 'first block' you refer to, and any other significant things?

Oh, on your dump, the 'Penalty...' etc stuff should not be there.   It's not part of the data.   But it looks like stuff from a previous LOAD I did, so it may have been in the buffer.   Or might it have been in your buffer?   Did I even send you 'FOOTBALL' (re American Football !)

Geoff

robcfg


Hi Geoff!


Please try the attached wav file. I've make sure all the leading tones and spaces are exactly like the ones in your files. I hope it works this time!


Regarding the numbers, and assuming long gaps, they are as follows:


- 12584 '1' bits leading tone
- 1st copy of the header block, in the image from my earlier post, offset 0 to 85 (86 bytes)
- Interblock pause. 168 '1' bits followed by a small silence and then another 168 '1' bits.
- 2nd copy of the header block, offset 86 to 171 (86 bytes)
- 2344 '1' bits followed by a small silence and then another 2344 '1' bits.
- 1st copy of the data block, offset 172 to 433 (262 bytes)
- Interblock pause. 168 '1' bits followed by a small silence and then another 168 '1' bits.
- 2nd copy of the data block, offset 434 to 695 (262 bytes)
- 2344 '1' bits followed by a small silence and then another 2344 '1' bits.
- 1st copy of the eof block, offset 696 to 781 (86 bytes)
- Interblock pause. 168 '1' bits followed by a small silence and then another 168 '1' bits.
- 2nd copy of the eof block, offset 782 to 867 (86 bytes)
- 12584 '1' bits trailing tone


Cheers,
Rob

GeoffB17

Rob,

Tried your file.   No response.

I tried the FILES command, nothing.  I tried different volumes, nothing.

I tried to LOAD the file, not sure if it was prog or data, but like I've said before, even getting an IO error would be something.

Nothing.

Tried a known file (something I's saved), no problem.   Worked.  So connections OK.

Can't see that the HX is even getting into the header, may not be seeing even the start of the data?

Thanks for the notes on the data, but not sure what the numbers refer to.   Doesn't seem to be the line (sample) ##s in my file.  Might be numbers from one of your progs.   How might the numbers refer to time, maybe I could work something out, as in file has xxx samples and is yyy secs long, therefore xxx/yyy samples per sec so 10 secs in should be about line lll.

Geoff

GeoffB17

Just a couple of extra notes.

I think there was a comment in the PHP code regarding the sync bits, he said that the docs said 'at least 40 bits' but he's found that it needed to be exactly 40.   Bit, if you look at the code, where's there's a string of "000000000" ending with a "1", which should be the sync data, I think there are less than 40 "0" there.   Unless there's something else somewhere in the code.

Secondly, the wave form.   The docs refer to the 'normal' and the 'inverted' form, and I'm not sure they specify which to use.   The PHP code allows the use of a parameter to invert, but I think the default is normal.   I think I saw a note somewhere that suggests that the microcassette uses the inverted form, and the standard cassette (which all my bits should be) is using the normal wave (i.e. + part followed by - part).

Geoff

robcfg

Well,


I cannot do much more without having access to a HX-20 and testing it myself.


Every parameter I can check is identical to the ones in you files. I've check that there are indeed 40 '0' bits at the end of the sync data, we tried reversing waveform...


I'm not doing anything else until I can borrow a machine and test it, as it's taking too much of the time I don't have. Sorry.

GeoffB17

Rob,

Yes, I understand your point of view.   I'm sure that it's even more frustrating for you, when you have no control over parts of the process.

Thank you VERY much for what you've done so far.

I don't know what the chances of finding a HX-20 may be.   There seem to be quite a few still about, but in Spain?

There were some on the market just recently, someone in Poland selling some ex-Bundwehr.   Maybe someone in Germany as well.   Evidently, there had been quite a few machines, slightly modified re power supply and added ROM, but the basic function unaltered.

Even better, if you could find someone in Spain who has one?

As for next step, the only other thing I can think of right now would be to investigate the ROM code re the low-level routines covering the cassette system, to see if there are any low-level routines that can be used to provide any insight as to what data IS ACTUALLY getting in.   We know that data is getting OUT, we can see what's received.   So far, we've been depedant on the high-level routines to know what's getting back, and clearly they are fussy, i.e. they get the right data, or they get nothing.   The m/code is quite well documented.   I'm pretty sure that the bulk of the code is common to CAS0/CAS1 (microcas/ext cas) with specific entry points using common sub-routines, although lowest level ports will be different.

I've got the FORTH ROM in my HX, I can easily check the existing forth code for cass input, and maybe create a new version to report on the steps, or maybe even go in further?

Best wishes,

Geoff

GeoffB17

Rob,

I've still got the FORTH angle to pursue, but I've found another angle.

Looking on the web trying to follow various leads, I found some info about a prog to analyse a WAV file by frequency.   Uses some soft of FFT maths, (fast Fourier t?).   Prog is reading WAV.

Prog is in PERL.   Uses separate libs for reading the WAV, that lib allows writing the wav back again.

I've installed PERL, got it running, got the WAV lib, installed that, and tested it.   Works quite well.   May well be helpful.   Seems to allow easy re-gen of the wav with various settings, i.e. 44,100, mono, etc, and also generation of sine waves at specified frequency.

Got the FFT lib now as well, but not installed that.   May have to change that a bit more than the test prog re wav, if I want the graphical output?  But may not need that, just need quick conv to zero (?), 1k and 2k (1.8k ??) frequencies?   If this prog is able to analyse the frequency spectrum, then it much be able to detect the different frequency components?

The important this, the PHP code we had before is substatially dependant on some audio components that we have co access to.   The PERL stuff is NOT, it's processing the raw WAV data, I guess, in a similar way to how you were.

I'll let you know more when I see if this helps any.

Thanks.

Geoff

Powered by SMFPacks Menu Editor Mod