Home Page Forums MAME MAME Tape files....

I just saw that even Fire Force is available at archive.worldofdragon.org as a cas file, so as far as I know, only tapes that have also audio on them cannot be represented as a cas file, for obvious reasons.

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.



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

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)


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):

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.

PS - It is very possible that this rewriting is not as necessary in the Dragon world. If the Dragon ROM is more efficient and spends less time after the first CAS block is loaded, it is possible that the delays may be less necessary.

right, any format that doesn't accurately represent delays, or where the files have to tweaked post-conversion to that format, to insert some kind of fake data to simulate those delays isn't fit for purpose IMHO

it's bad enough that most (all?) cassette formats fail to properly represent tape length, so most of the time side a and side b of the same tapes are shown as different lengths, despite being the same amount of cassette tape.

archival formats should not be stripping away delay / spacing / blank are data.

I can try converting a CoCo cas file to wav, which creates a wav without delays, and try to load that on a real machine.

As far as I remember, I've done that with the Dragon and works well.

Maybe it works if the rom code stops the motor after the first block and then after processing it, starts the motor again and just takes the data in.


Certainly most these formats don't care about properly representing the tape, but as I said earlier, they weren't designed for that. The interest has been traditionally getting the program to work. For that wav files are the simplest solution (maybe CSW being close, but that already loses some info), but if the original media was flaky then the program becomes unusable even with an accurate representation of the tape.

By all means, and let us know about the outcome of this experiment! It would also be interesting to take the resulting WAV and to load that into MAME directly.

I suppose there are three possible outcomes:

• Converted "delayless" CAS files that require CAS rewriting on MAME fail to load on a real machine. If this is the case, well this is why I dislike CAS.
• Converted "delayless" CAS files get converted to a WAV that work on MAME and a real machine. This would suggest that MAME's CAS handling is wrong.
• Converted "delayless" CAS files get converted to a WAV that work on a real machine but not MAME (or vice versa). This would suggest that MAME's CoCo/Dragon emulation is incorrect.

That very well could be; I have not worked out the precise timings but I could imagine this problem not existing if the emulated system was aggressive at keeping the cassette motor off when not sampling CASIN.

I'd also expect the CoCo/Dragon's relay that controls the cassette motor to be very "clicky". If memory serves, I do remember cassette loading and saving in the EDTASM program in particular, being quite clicky.

Stopping and starting the tape motor takes time – it doesn’t instantaneously go from zero to playback speed. If you do that anywhere that isn’t a gap, you’ll get corruption while the motor is getting up to speed. If it’s starting and stopping the motor, it can only do that in gaps or parts of the data that it doesn’t care about. The CAS format is inadequate given that the machine needs gaps for tape loading to work at all.

That's why I'll be testing it on the real machine this weekend.

I've used wav files generated from cas files to load games on Dragons from my iPod classic (that doesn't have remote capability) on several events and never had a problem.

Of course, it may be just how the Dragon loading routine works.

I'm not trying to say that cas files are adequate for preservation, because they are obviously not, but we may find some interesting information that could help improve our understanding of these machines and its emulation.