Originally Posted by robcfg
Taking a look at the color computer archive files, the cas files seem to be the same as the Dragon ones. Here you can see a CoCo3 cas file, where the 0x55 bytes are sync or leader bytes, the 0x3C byte is the start of block byte and the 0x00 after that is the byte indicating that the block type is "name". Those are the bytes you see on the screenshot in my previous post.

Yeah, those bytes are there but the real question is "Where are the delays that need to be inserted while the emulated CoCo is not actively sampling the CAS port?". The answer is, of course "The CAS file format doesn't represent delays, despite the fact that any reconstructed waveform absolutely needs them".

To reiterate the CAS format is an accurate representation of the logical contents of the file. And a waveform generated from this data would definitely work without any processing if the playback of the waveform was magically suspended while the emulated CoCo was not actively sampling the cassette port. However, emulators are not magic and something needs to happen, whether it be intercepting ROM calls (a popular technique among CoCo/Dragon emulators), or by rewriting the waveform (as MAME does)

Originally Posted by robcfg
It would be nice to find a way to automate the test you suggested, but I suspect they'd all work.

I took a closer look at MAME's CAS rewriting code (its been two decades since I've worked on it!), and concluded (to my surprise) that it would be quite easy to run this experiment; simply disable the while loop at line 205 (https://github.com/mamedev/mame/blob/master/src/lib/formats/coco_cas.cpp#L205):
Code
/* try to find a block that we can untangle */
while(0 && get_cas_block(cassette, offset, block, block_length, synccount))
{
	...

The reason is that there is a fallback capability in the code to simply emulate the modulated waveform if the CAS processing ever fails, and to simply disable this loop turns that fallback into the primary path.

In any case, I went to www.colorcomputerarchive.com and grabbed three CAS files off the front page ("Audio Spectrum Analyzer (1983) (Tandy).cas", ""Coco Solitaire (Paul Shoemaker).cas" and "Kingdom of Bashan (Owls Nest Software).cas"). All three of these work in normal MAME, but fail when MAME's CAS rewriting code is not ran. Specifically, the first block is found (and the emulated CoCo starts showing the blinking "F"), but an "?IO ERROR" happens afterwards. What is likely happening is that without delays being inserted, the emulated CoCo gets confused because it burned a few CPU cycles after the first block is loaded.

Granted, this is a sample size of three, but the fact that three for three fail is suggestive of something.

In conclusion - the critical problem with the CAS format is its failure to represent delays. And any emulator that wants to work with this format is going to have to do something gross to accommodate this failure to explicitly identify said delays (options being intercepting ROM calls or by inferring where the delays need to be). It is clear that the need to do (while not 100% of the time) so goes beyond a handful of copy protected titles. Even the minuscule delays that happen between the processing of CAS blocks are significant.