Wav 2 Cas of Salmon Run

[Fred_M]

Hi Paul,

 

Try this one. This one works with my version of Altirra (XL, 128k, PAL)

Downhill_2.rar

Edited July 4, 2018 by Fred_M

[Mclaneinc]

Yup, that one works great..

 

Thanks fred...

[Kr0tki]

Please be aware when using A8CAS, that even if a CAS file loads properly in emulation, it does not automatically mean that the file is 100% correct. In case of the Buried Bucks CAS file, some data blocks were not decoded properly. This may result in loading errors when the file is recorded back to a real tape.

 

I'm attaching the corrected CAS files of both Buried Bucks and Downhill, please use them instead.

 

Actually, this is included in my wav2cas converter. It automatically selects the filter pair that provides the best recognition rate, evaluating the recording with all possible filter pairs available. This is also necessary to a certain degree as tape speed (not so much tape stretching) varies over time.

I remember we talked about this before. Your converter indeed compensated for signal frequency shifts, but it did not compensate for the changes in tape speed, so it could not decode data with large mid-byte speed changes. The latter feature is the one I was referring to when responding to Rybags above.

Buried Bucks-Downhill.zip

Edited July 6, 2018 by Kr0tki

[_The Doctor__]

Real equipment is the only way to know for sure... the emu's fudge stuff....

[+Allan]

Real equipment is the only way to know for sure... the emu's fudge stuff....

We need the Ipod/music player 2 SIO device.

 

Allan

[+remowilliams]

Sort of on the topic... is anyone using APE and SIO2USB under Windows 10 and having .cas images load correctly 100% of the time? I've tried it and have had issues with things that should work fine (and seemingly did under XP, even under virtualization)

[thorfdbg]

 

I remember we talked about this before. Your converter indeed compensated for signal frequency shifts, but it did not compensate for the changes in tape speed, so it could not decode data with large mid-byte speed changes. The latter feature is the one I was referring to when responding to Rybags above.

 

Actually, that is not correct, it does both. To adapt for frequency changes, it comes with multiple filter pairs and switches dynamically between them to find the one with the best decoded quality. Tape speed variations of course also change the bitrate of the data encoded through the filter modulation, and the adaptation logic there works the same as it does in the Os: The software looks at the 0101-patterns upfront the data and determines from that the baud rate.

 

What probably could be improved are the digital filters themselves.

[Kr0tki]

I am talking not about detecting baudrate of the whole data block, but about adjusting baudrate dynamically during decoding of a block, according to signal frequency shifts.

 

Real equipment is the only way to know for sure... the emu's fudge stuff....

That is not actually the case - structure of an Atari tape recording is so simple that in most cases a visual review of the resulting CAS file is enough to determine if the file was converted 100% correctly.

[Fred_M]

That is not actually the case - structure of an Atari tape recording is so simple that in most cases a visual review of the resulting CAS file is enough to determine if the file was converted 100% correctly.

 

How can I do a visual review of the CAS-file? Please tell us

[thorfdbg]

I am talking not about detecting baudrate of the whole data block, but about adjusting baudrate dynamically during decoding of a block, according to signal frequency shifts.

 

You cannot do much within a block - there are only start and stop bits you can try (and the program does try) to recognize, but once you are within a byte, and the baud rate changes so dramatically that you mixup bits within the byte, you are lost.

[baktra]

 

How can I do a visual review of the CAS-file? Please tell us

 

There are certainly tools that can display contents of a .CAS file.

Either visually or a text listing of all chunks.

 

I don't know what tool Kr0tki uses, but I know this one. An experienced eye knows immediately that this is a cassette boot file using the "data in EOF block" trick that loads a binary load file stored in absolutely standard tape records.

 

Edited July 7, 2018 by baktra

[Kr0tki]

How can I do a visual review of the CAS-file? Please tell us

Obviously, full knowledge of the CAS format is a requirement. Then you can use the tool mentioned by baktra, or, like me, simply convert the recording to HEX instead of CAS, and open the resulting file in a text editor. (Note: HEX format uses Unix newlines, so use an editor that supports them. I use Notepad++.)

 

Try converting your CAS files to HEX and do the same with the CASes of mine, and view them in a text editor. The gist of the issue is that, apart from the quite rare cases of copy-protected tapes, any "fsk " chunks are unwanted, and all "data" chunks should have correct checksum, as indicated by a "OK" at the end of each line. If there is an "fsk " chunk at the start or end of the file, it is most likely a bit of silence encoded, so it should be removed. But if a "data" chunk is ending abruptly and is immediately followed by an "fsk " chunk, then it means a problem in decoding of the data block, which should be fixed, probably manually. At this point I step in

 

You cannot do much within a block - there are only start and stop bits you can try (and the program does try) to recognize, but once you are within a byte, and the baud rate changes so dramatically that you mixup bits within the byte, you are lost.

I'm talking about using the changes in pitch as a guide for adjusting the lengths of individual bits. I have done it manually with Allan's warped "Player_Generator_APX_3.flac" recording, so it probably should be doable by software, too. I fixed two or three blocks this way before thinking "screw it, that's too much work, let him re-dump the tape."

[+Allan]

This tape has some issues but maybe you guys can work some magic. According to the manual there are suppose to be two programs on there.

 

Allan

 

APX_Drawit.flac.zip

[Kr0tki]

I'm back from vacation, so it's time to work some magic indeed. The recording has signal dropout in ca. 5 places, but nothing that could not be restored with the aid of block checksums.

 

 

The tape, as expected, contains two programs recorded back to back.

Drawit (1983)(APX)(US).zip

Edited August 2, 2018 by Kr0tki

[+Allan]

Thank again, Kr0tki,

 

Your the best!,

 

Allan