ArduiTape | MSX Resource Center (Страница 4/9)

Prophet (2932)

01-10-2014, 15:26

cas2wav.c, the first function writePulse, maybe it is all in there.

Replace the whole for() loop with this:

if (f == LONG_PULSE) {
	putc(0, output);
	putc(0, output);
	putc(255, output);
	putc(255, output);
} else {
	putc(0, output);
	putc(255, output);
}

I hope the result is the desired

and set OUTPUT_FREQUENCY to 9600.

By SadKen

Rookie (17)

01-10-2014, 15:31

Woooo.... i can post

@hit9918 read this: http://en.wikipedia.org/wiki/Kansas_City_standard
it explains the Kansas City standard which the MSX (among many other machines) use to decode tape audio into a bit stream. Basically it detects one 1200hz cycle as a 0 and two 2400hz cycles as a 1. the reason 9600 sample rate is glitchy is because you have no nice clear transition through 0v for the MSX to detect, and so causes errors. Ideally you need 19200 sample rate, but the TMRpcm library starts getting read delays, and you get clicks in the audio (due to the SD cards needing to read in SPI mode and not 4-bit parallel).

2400baud mode is essentially the same, just twice as fast, so 1 x 2400hz cycle for a 0 and 2 x 4800hz cycles for a 1

By SadKen

Rookie (17)

01-10-2014, 15:45

void writePulse(FILE *output,long f)
{
  long n;
  double length = OUTPUT_FREQUENCY/(BAUDRATE*(f/1200));
  double scale  = 2.0*M_PI/(double)length;

  for (n=0;n<=(long)length;n++) {
    if(n<(long)length/2) {
        putc(0,output);
    }
    if(n==(long)length/2) {
        putc(127,output);
    }
    if(n>(long)length/2) {
        putc(255,output);
    }
  }

    //putc( (char)(sin((double)n*scale)*127)^128, output);
}

That's the edit to the wave generating routine in cas2wav. by simply converting the original sine wave generating code to output a square wave the loading reliability was hugely increased

By Buleste

Master (158)

01-10-2014, 16:32

hit9918 wrote:

cas2wav.c, the first function writePulse, maybe it is all in there.

Replace the whole for() loop with this:

if (f == LONG_PULSE) {
	putc(0, output);
	putc(0, output);
	putc(255, output);
	putc(255, output);
} else {
	putc(0, output);
	putc(255, output);
}

I hope the result is the desired

and set OUTPUT_FREQUENCY to 9600.

Does not compile. Again 14400 works on both bauds so why change to 9600 when it already works?

The games that do not work must have the custom file type within the cas files which cas2wav cannot handle which is why they don't work. TapDancer, however does seem to be able to decode these but unfortunately the source code for that is not available.

By hit9918

Prophet (2932)

01-10-2014, 16:52

@sadken, oh I somehow missed the earlier posting.
that thing about 3 data points and going thru 0 volts being a special deal,
that gotta be a special of your hardware with 1 bit DAC.

then it must be emphasized that this is a different case.
the thing that I was talking about is wav tool for the typical music device playing.

By SadKen

Rookie (17)

01-10-2014, 16:58

@hit9918 Ah i see, yes if you're trying to output music you would want a better sample rate, and resampling. But as the MSX doesn't care about any of that and just reads the frequency.

My post took ages to appear because it was my first one

Our current problem is handling the custom blocks in CAS files. cas2wav doesn't seem to convert them properly, and the only thing that does is TapDancer which is an android app....

By hit9918

Prophet (2932)

01-10-2014, 17:05

well I dont know why 3 data points are needed to go thru 0 volts.
all I see is that 3 data points square wave makes one arm longer and then there is messed timing.

and no, I was not about music, but about the right casette wav to replay on PC audio, CD player, etc etc.
and rather than "read frequency", the ppi pin does read rising and falling edges.

By SadKen

Rookie (17)

01-10-2014, 17:10

Ideally we need 4 data points, but the arduino can't get data from the SD card fast enough to do that 100% reliably, so 3 data points are used. in theory 2 would work, but TMRpcm library struggles with anything under 11025 as it uses timers and they start to overrun at that slow speed again causing glitches in the audio.

By hit9918

Prophet (2932)

01-10-2014, 17:16

" but TMRpcm library struggles with anything under 11025 "
lol it looks like in the end this whole story too is like a soundblaster legacy case

By SadKen

Rookie (17)

01-10-2014, 17:17

Used the tools available to keep the cost down, what can i say