ArduiTape

Page 7/9
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9

By Buleste

Master (158)

Buleste's picture

11-12-2015, 20:07

giangiacomo.zaffini wrote:

@ Buleste : good news !
Since I have a STM32F4 Discovery Board I'm interersted in the port, eventually I can help too! Cool

Awesome because I'm having an absolute nightmare understanding the damn thing. Lol

By hit9918

Prophet (2905)

hit9918's picture

12-12-2015, 20:49

"All issues were fixed by adding a couple of seconds of silence at the end of each wav", this smells no good.
I too had the issue "the last file hangs".
tool with sourcecode:
https://sites.google.com/site/tueftlerlabs/home/downloads/lw...
you can try suspicious BLOAD files with it, maybe it tells that the headers are wrong.
BLOADS who claim more bytes than actualy are in there, they hang.

silence is never needed. either there is a tweet, or there is data.
play the example wav of the package, EErrEErrrrrrrrrrrrr it blasts with tiny tweets and no silence.

By Buleste

Master (158)

Buleste's picture

13-12-2015, 12:28

I've tested lots of games all of which had issues with various players due to the buffer of the players they all now work perfectly. The issue was never with the files themselves just how they were played back and the added silence fixes the problem. No issue with unknown headers etc. just with the buffer fade out.

By SadKen

Rookie (17)

SadKen's picture

13-12-2015, 19:34

Because the Wav files data aren't a multiple of the buffer size the player cuts off the any buffer that doesn't fill completely. This means that when you play back a file you could miss the final stop bits of the last byte of data, causing the load to hang.

This was a particular issue with the Arduitape, as it uses TMRPCM which (as said before) drops any incomplete buffers. adding the 2 seconds of silence to the end of the WAV file means the Arduitape plays through all the data, and doesn't drop any.

Silence is very important to the MSX while loading as it dictates the end of one file, and the start of the next (if there is one) and so to stop looking for more data, and to return to searching for the next header.

When you load a basic, or binary file you get a long silence, a long header (the high pitched BEEEEEEP), file name, more silence, a short header, and finally the actual data you're loading.

due to the way cas2wav is written, if you have a crap CAS file it'll never convert it as it needs headers, and file types to be declared in a very particular way.

By hit9918

Prophet (2905)

hit9918's picture

13-12-2015, 21:03

the end of the file comes not with silence, but with the last properly transmitted byte.
there is just a bios function "read one byte".
there are only bytes, there is no way to detect a file end, it must be in the protocol.
how many bytes to read must be told in the BLOAD header.

when there are not enough bytes, silence will make the MSX just hang forever.
twiddeling thumbs for getting some start/stop bit cascade.
I could "fix" the hang by playing random trash to it. this works endless seconds later.
and from that trash it gotta have made its last trash byte and save that bad thing to RAM. it does not detect an error.

but, once the bugs fixed, things load well. not with a long silence and a long tweet, but with no silence and 0.5 seconds tweet.
the bios insists in minimum 0.3 seconds tweet.
made to time wobble mechanics, in digital form it is more than enough.
after a header it prints "found" and that takes 0.2 seconds cpu time Tongue
so then better the following tweet be 0.5 seconds.
whether a motor application can stay with 0.3 seconds I cant tell.

another question is: how does the API work.
does it append something to an audio DMA buffer. how long is that? maybe 1 second, adding some more confusion?
and is there a function to stop the sound? will that cut off sound immedeately?
maybe that DMA buffer had another second to be played.
with an audio DMA buffer of 1 second, things end up on the audio plug 1 second later than your program thinks!
that's the stuff I am trying to poke at.
the MSX will say motor on/off at times that dont fit aligned to 1k and not aligned to 1 second.

By Buleste

Master (158)

Buleste's picture

14-12-2015, 12:16

Tell you what. Go to the blog. Download and examine the Arduitape software. Build your own Arduitape. Use our version of Cas2Wav tools and test on a real machine and tell us how it doesn't work.

By SadKen

Rookie (17)

SadKen's picture

14-12-2015, 12:42

Go back and read what i said before jumping in telling us we're wrong....

"Because the Wav files data aren't a multiple of the buffer size the player cuts off the any buffer that doesn't fill completely. This means that when you play back a file you could miss the final stop bits of the last byte of data, causing the load to hang."

it has nothing to do with the MSX detecting the final silence (although it is still there for a reason), it only has to do with filling the buffer so the player doesn't ignore the last few samples.

The Arduitape uses TMRPCM which double buffers about 50 bytes of audio data, filling one while the other empties. any delay will be tiny fraction of a second, the motor start/stops happen during a silence to prevent any data loss as original tape players would take a moment to actually stop the motor (which is why they're there).

I've spent the last 3 weeks going through the finer details of this to try and make the Arduitape work directly from CAS files, which is (hopefully) on the right track Wink

By NYYRIKKI

Enlighted (5880)

NYYRIKKI's picture

14-12-2015, 13:00

SadKen wrote:

I've spent the last 3 weeks going through the finer details of this to try and make the Arduitape work directly from CAS files, which is (hopefully) on the right track Wink

Ah, thank you!

I know I've not said anything before, but I find it a bit sad that you have already used so much time and effort to fight with something like WAV-player routines etc. stuff that is just fundamentally stupid. I'm really happy that you have finally taken reasonable approach as in the end we are only talking about turning Arduino output pin on/off at correct timing.

By SadKen

Rookie (17)

SadKen's picture

14-12-2015, 15:31

I went with the WAV option at first because it was also designed to work with my Acorn electron. Sadly the tape format for that uses Zip compression which, as far as i'm aware, would be impossible to deal with directly on an arduino due to memory limitations. As there were more than enough (almost any tape format) to WAV converters we thought using WAV files would make it more universal (which it certainly did, worked on spectrum, c64, bbc micro, acorn electron, and MSX).

Hopefully i'll get it to a stage where you can have either universal WAV, or MSX only CAS playback depending on the firmware.

So far it's capable of recognizing each of the different headers, convert the data, and output the correct tones.
once the software part is done, i'll need to look at some extra components as standard headphone is a +ve to -ve signal, whereas the arduino is only kicking out 0v to 5v, so it might need some level shifting (and volume control).

By Buleste

Master (158)

Buleste's picture

14-12-2015, 15:39

To hopefully finally put this argument to bed that we are doing something wrong I performed and experiment.

I used the same cas file and produced a wav with the exact same settings using the old cas2wav and the new one. Tried loading on the same computer using the same Android phone at the same volume using VLC for Android.

Old cas2wav didn't finish loading.
New cas2wav worked perfectly.

Not the frequency. Not the baud rate. Nothing to do with the arduino. Nothing to do with Motor control. ALL to do with the buffers on players missing the last bit due to fade out and the adding of a little silence fixing the problem.

You too can try the same experiment using the same files.

Page 7/9
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9