Originally Posted by robcfg
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.

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.


Originally Posted by robcfg
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.

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.