Previous Thread
Next Thread
Print Thread
Page 1 of 3 1 2 3
#120001 11/14/21 04:21 PM
Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
Hi all,

With the Dragon / CoCo driver.

Is there any way to control the format of tape output files? Currently they seem to be saved as WAV files, is there a way of saving them as CAS files?

Cheers.

Phill.

PhillHS #120002 11/14/21 05:25 PM
Joined: Dec 2015
Posts: 143
Likes: 2
A
AJR Online Content
Senior Member
Online Content
Senior Member
A
Joined: Dec 2015
Posts: 143
Likes: 2
WAV is the only format which MAME currently supports for saving cassette images. This is partly because MAME emulates cassette tape interfaces on a lower level than many other emulators. Decoding data from the serial bitstreams MAME is designed to output would be difficult at best, though it would likely be more tractable for CPU-to-tape-drive interfaces based on USARTs and such than purely bitbanged interfaces such as the ZX Spectrum ULA which provide a much wider latitude for highly nonstandard formats.

PhillHS #120003 11/14/21 05:57 PM
Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
You can easily convert the wav output to cas with several tools, like the ones listed here: https://archive.worldofdragon.org/index.php?title=Tape%5CDisk_Preservation

robcfg #120004 11/14/21 08:48 PM
Joined: Nov 2003
Posts: 186
Likes: 1
P
PhillHS Offline OP
Senior Member
OP Offline
Senior Member
P
Joined: Nov 2003
Posts: 186
Likes: 1
Originally Posted by robcfg
You can easily convert the wav output to cas with several tools, like the ones listed here: https://archive.worldofdragon.org/index.php?title=Tape%5CDisk_Preservation
Yeah I know, I was just trying to save a step smile

Cheers.

Phill.

PhillHS #120005 11/14/21 10:52 PM
Joined: Nov 1999
Posts: 692
Likes: 5
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 692
Likes: 5
CAS is really a nightmarish format that really should not exist. Many of the CoCo/Dragon emulators patch the ROMs to emulate the cassette, resulting in a format that cannot be directly mapped to a waveform, but ends up in practice requires either partaking in the same hacks, or some processing step to essentially simulate the result of patching the ROMs.

At least this is what I remember when I first started working on the CoCo stuff two decades ago.

PhillHS #120006 11/14/21 11:16 PM
Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
The CAS file for Dragon/CoCo is just a bit dump, nothing else.

I proposed an extension to the format to the author of the XRoar emulator that consist on some data appended at the end of the CAS file (named CUE extension), so it's transparent for machines and emulator and allow for some better reconstruction of the wave.

So, the CAS format is dead simple.

robcfg #120007 11/14/21 11:57 PM
Joined: May 2009
Posts: 1,980
Likes: 24
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,980
Likes: 24
Originally Posted by robcfg
The CAS file for Dragon/CoCo is just a bit dump, nothing else.

Are you sure? This page would seem to indicate that it can be just a bit dump, but it certainly seems to be capable of a bit more than that, which I suspect is part of the issue at hand: http://archive.worldofdragon.org/index.php?title=Tape%5CDisk_Preservation#CAS_File_Format

PhillHS #120008 11/15/21 01:02 AM
Joined: May 2004
Posts: 1,684
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,684
I generally think that MAME should always output lossless formats; leave the conversions to an external tool afterwards.

Trying to reduce down tapes etc.to formats such as cas, tzx etc. has caused so many problems over the years due to ambiguity in the specifications, as well as features being added then dropped. This has resulted in different encoders producing different results, sometimes conflicting with the output of other encoders and giving us cases where no one decoder can decode everything. The knock-on effect of this is decoders flip-flopping between supporting the output of one piece of software and another.

There are there are just too many 'badly' encoded files out there without MAME contributing to that by also supporting such things as these custom output formats, again to our own interpretation of the specifications.

In most cases we would have been better off just keeping the wav files, and maybe using a lossless encoder such as FLAC on them.

The same happened with CDs; and floppy images; different software implementing things in different ways, often resulting in images that are only 100% compatible with the software they were created with, despite using 'standard' formats.

PhillHS #120010 11/15/21 04:39 AM
Joined: Jan 2021
Posts: 69
=
Member
Offline
Member
=
Joined: Jan 2021
Posts: 69
I think the widespread homecomputer emulator file formats should be supported, else nobody will use MAME for them at all. But plain audio (WAV) version must be still there. This may be done through a plugin (possibly realtime-converting data like a unix-stream or such) to make the emulation internally see audio signals.

E.g. Atari XL datassette has a stereo tape head and could play speech/music from cassette during load of a program. E.g. cassette games by Europa played a long music track from cassette while loading. Some programs also started and stopped the tape to output speech (quiz questions and such) although this of course only worked in fixed order (you could not wind the tape through software). It would make sense to support such audio tracks through an additional MP3 file since WAV eats much disk space.

Last edited by =CO=Windler; 11/15/21 04:40 AM.

MAY THE SOFTWARE BE WITH YOU!

{weltenschule.de}
Joined: May 2009
Posts: 1,980
Likes: 24
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,980
Likes: 24
Originally Posted by =CO=Windler
It would make sense to support such audio tracks through an additional MP3 file since WAV eats much disk space.

Ah, yes, because we live in 1999 and terabyte-sized drives are still a dream of the future.

Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
Originally Posted by Just Desserts
Originally Posted by robcfg
The CAS file for Dragon/CoCo is just a bit dump, nothing else.

Are you sure? This page would seem to indicate that it can be just a bit dump, but it certainly seems to be capable of a bit more than that, which I suspect is part of the issue at hand: http://archive.worldofdragon.org/index.php?title=Tape%5CDisk_Preservation#CAS_File_Format

Yes, I'm sure. The extra bit of information at the end is something Sixxie and myself designed in order to keep more information about the original layout. But the original cas file is just a bit dump.

Joined: May 2004
Posts: 1,684
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,684
Originally Posted by =CO=Windler
It would make sense to support such audio tracks through an additional MP3 file since WAV eats much disk space.

It didn't make sense 20 years ago to use MP3 for archival, yet people did it, and in quite a number of cases (even rare prototypes) we're now stuck with awful MP3s rather than quality images.

Quite a few of your posts are now pushing a 'do it wrong because of space/speed/whatever' narrative which is something that has caused more long lasting issues than many other things in the emulation scene.

You're not alone in this, nor is it a problem exclusive to emulation. I've worked a person who had been asked to restore film to a better quality before, and couldn't do it because it turned out that a major company had decided to 'archive' all of their film and audio in cable TV broadcast quality MPEG many, many years ago, disposing of the originals years ago because they took up too much space. For that media, you're only ever going to see new releases that have ugly MPEG macroblocking going forward even when we now we would have otherwise have had the capacity to offer it at a higher quality than consumers would ever have seen back in the day. All because somebody wanted to save a little space.

Joined: Apr 2005
Posts: 589
Senior Member
Offline
Senior Member
Joined: Apr 2005
Posts: 589
Originally Posted by =CO=Windler
It would make sense to support such audio tracks through an additional MP3 file since WAV eats much disk space.

Wait, I thought you were convinced that listening to MP3 files damages your hearing? And now you want support for such a dangerous format in MAME?

PhillHS #120021 11/16/21 02:04 AM
Joined: Mar 2001
Posts: 16,840
Likes: 45
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,840
Likes: 45
"WAV eats much disk space" was a somewhat reasonable argument in 2001. It's not in 2021. My phone has an order of magnitude more storage than my PC in 2001 did, and it's faster.

PhillHS #120022 11/16/21 03:11 AM
Joined: Dec 2012
Posts: 245
L
Senior Member
Offline
Senior Member
L
Joined: Dec 2012
Posts: 245
Speaking of tape files, I was attempting to load this copy of Planet Miners in the a400/800 drivers and kept getting timeouts. I was able to load the Apple II version on the same side fine (seek to 753 before loading). Is it due to the volume of the capture? The command line I used was
Code
mame a400 -sio cassette -cass planet_miners_side_a.wav -cart1 OSSBasicXL103.car

PhillHS #120023 11/16/21 03:59 AM
Joined: Apr 2021
Posts: 21
Likes: 3
K
kmg Offline
Member
Offline
Member
K
Joined: Apr 2021
Posts: 21
Likes: 3
I don't think cassette support is implemented for Atari 8-bit.

Haze #120025 11/16/21 05:05 AM
Joined: Jan 2021
Posts: 69
=
Member
Offline
Member
=
Joined: Jan 2021
Posts: 69
Originally Posted by Haze
You're not alone in this, nor is it a problem exclusive to emulation. I've worked a person who had been asked to restore film to a better quality before, and couldn't do it because it turned out that a major company had decided to 'archive' all of their film and audio in cable TV broadcast quality MPEG many, many years ago, disposing of the originals years ago because they took up too much space.

Of course that's a pity. But better than completely discarding movies by fear of self-combusting nitro celluloid material. That is to say, in 1950th cinema film copies still got systematically destroyed by their publishers to avoid spoiling rental of their new movies.

seen in docu "Nitro-Archipele"/"Archipels nitrate"
https://www.imdb.com/title/tt1718723/

And the first seasons of "Doctor Who" even got deleted by the BBC to reuse the (at that time fairly expensive) video tapes, because they considered themself workers of performing art (like a stage theater), not makers of art objects (and were threatened to pay a fine for broadcasting repeats). Also "Monty Python's Flying Circus" only got saved from deletion because the actors bought the video tapes back. E.g. I am still missing many of the 1970th German school TV educational docus (like "Einführung in die Digitaltechnik") seen in childhood, those likely got discarded too by the broadcast stations by lack of monetary value.

Last edited by =CO=Windler; 11/16/21 05:14 AM.

MAY THE SOFTWARE BE WITH YOU!

{weltenschule.de}
robcfg #120030 11/16/21 05:21 PM
Joined: Nov 1999
Posts: 692
Likes: 5
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 692
Likes: 5
Originally Posted by robcfg
The CAS file for Dragon/CoCo is just a bit dump, nothing else.

I proposed an extension to the format to the author of the XRoar emulator that consist on some data appended at the end of the CAS file (named CUE extension), so it's transparent for machines and emulator and allow for some better reconstruction of the wave.

So, the CAS format is dead simple.

If the CAS format is "dead simple", then why did you need to submit anything to better reconstruct the wave?

It is correct to say that it is a "bit dump", in that it is a bit dump of the logical file, but it does not directly translate to a waveform. I know this from experience.

As food for thought, I present to the reader a sample from the XRoar source code, specifically tape.c. The fact that any so-called "tape rewriting" is necessary at all is why CAS is a problematic file format.
Code
// Tape rewriting intercepts the returns from various ROM calls to interpret
// the loading state - whether a leader is expected, etc.

static struct machine_bp bp_list_rewrite[] = {
	BP_DRAGON_ROM(.address = 0xb94d, .handler = DELEGATE_INIT(rewrite_sync, NULL) ),
	BP_COCO_ROM(.address = 0xa719, .handler = DELEGATE_INIT(rewrite_sync, NULL) ),
	BP_COCO3_ROM(.address = 0xa719, .handler = DELEGATE_INIT(rewrite_sync, NULL) ),
	BP_DRAGON_ROM(.address = 0xbdac, .handler = DELEGATE_INIT(rewrite_bitin, NULL) ),
	BP_COCO_ROM(.address = 0xa75c, .handler = DELEGATE_INIT(rewrite_bitin, NULL) ),
	BP_COCO3_ROM(.address = 0xa75c, .handler = DELEGATE_INIT(rewrite_bitin, NULL) ),
	BP_DRAGON_ROM(.address = 0xbdeb, .handler = DELEGATE_INIT(rewrite_tape_on, NULL) ),
	BP_COCO_ROM(.address = 0xa780, .handler = DELEGATE_INIT(rewrite_tape_on, NULL) ),
	BP_COCO3_ROM(.address = 0xa780, .handler = DELEGATE_INIT(rewrite_tape_on, NULL) ),
	BP_DRAGON_ROM(.address = 0xb97e, .handler = DELEGATE_INIT(rewrite_end_of_block, NULL) ),
	BP_COCO_ROM(.address = 0xa746, .handler = DELEGATE_INIT(rewrite_end_of_block, NULL) ),
	BP_COCO3_ROM(.address = 0xa746, .handler = DELEGATE_INIT(rewrite_end_of_block, NULL) ),
};

Last edited by Bletch; 11/16/21 05:39 PM.
Bletch #120048 11/17/21 10:09 PM
Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
Ok, here we go...

Quote
If the CAS format is "dead simple", then why did you need to submit anything to better reconstruct the wave?

Precisely because it's dead simple it does not contain information about the gaps between blocks, or the frequency of the pulses. It is a raw bit sequence. You can generate a wav file from it that will work on actual machines, but for a couple of titles like Fire Force that do have a slightly more complicated loading scheme and need the empty spaces between tape blocks.

Quote
It is correct to say that it is a "bit dump", in that it is a bit dump of the logical file, but it does not directly translate to a waveform. I know this from experience.

You're wrong here. I've dumped over 330 Dragon titles, and if you translate each bit in the cas file to a waveform, the result is a valid wav file that will load on a real machine, except for some titles as mentioned above.
On top of that, I made several tools to recover and repair damaged Dragon/CoCo tapes and can even show you visually the 1 to 1 correspondence between bits in the cas file and the actual waveforms.

[Linked Image from k3pi.chickenkiller.com]

Quote
As food for thought, I present to the reader a sample from the XRoar source code, specifically tape.c. The fact that any so-called "tape rewriting" is necessary at all is why CAS is a problematic file format.
Code
I fail to see how a specific emulator implementation is a problem of the format. MAME supports cas files and doesn't have a 'tape rewriting' option.

In a nutshell, the Dragon/CoCo CAS format (and it's important that is the file format for these machines, as other machines also use the CAS extension for their formats, but are completely different files) is barely a format because it's a 1 to 1 bit dump and nothing more. It wasn't designed with reconstruction of the original wave in mind, even though you can create a functional wave from it in a majority of cases.

robcfg #120049 11/18/21 01:52 AM
Joined: Nov 1999
Posts: 692
Likes: 5
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 692
Likes: 5
Originally Posted by robcfg
I fail to see how a specific emulator implementation is a problem of the format. MAME supports cas files and doesn't have a 'tape rewriting' option.

You're right - MAME doesn't have an option to rewrite the tape; it does it all the time:
https://github.com/mamedev/mame/blob/master/src/lib/formats/coco_cas.cpp

Originally Posted by robcfg
In a nutshell, the Dragon/CoCo CAS format (and it's important that is the file format for these machines, as other machines also use the CAS extension for their formats, but are completely different files) is barely a format because it's a 1 to 1 bit dump and nothing more. It wasn't designed with reconstruction of the original wave in mind, even though you can create a functional wave from it in a majority of cases.

I suppose this is precisely the point I was trying to make. Any emulator trying to simultaneously trying to accurately emulate the hardware, and be compatible with the CAS file format has to apply a set of gymnastics and heuristics to (in the case of reading the format) generate an accurate waveform, or (in the case of emitting the format) parsing the waveform into bit pulses. Or one can "cheat" and patch the ROMs - but this is an unacceptable solution given MAME's goals. Admittedly, its been a while (e.g. - ~18 years) since I've sampled CAS files from the wild to gauge how many of them actually needed such processing; my recollection is that postprocessing was necessary much more often than you describe.

I call this nightmarish; not because of some fiendish complexity but rather the amount of heuristics that are involved.

It would be an interesting exercise to try to grab a large amount of CAS files from www.colorcomputerarchive.com, and see how many of them fail to load if one changes coco_cas.cpp to interpret the CAS format as a straight series of bit pulses. Any takers?

And if the CAS files that you've dumped don't need this processing, well my hat is off to you.

PhillHS #120051 11/18/21 06:55 AM
Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
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.

[Linked Image from k3pi.chickenkiller.com]

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

PhillHS #120054 11/18/21 02:47 PM
Joined: Nov 1999
Posts: 692
Likes: 5
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 692
Likes: 5
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.

PhillHS #120055 11/18/21 02:48 PM
Joined: Nov 1999
Posts: 692
Likes: 5
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 692
Likes: 5
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.

PhillHS #120056 11/18/21 03:04 PM
Joined: May 2004
Posts: 1,684
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,684
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.

Haze #120057 11/18/21 05:58 PM
Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
Originally Posted by Bletch
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.

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.

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

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.

robcfg #120058 11/18/21 07:32 PM
Joined: Nov 1999
Posts: 692
Likes: 5
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 692
Likes: 5
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.

PhillHS #120062 11/19/21 01:19 PM
Joined: Feb 2004
Posts: 2,290
Likes: 19
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,290
Likes: 19
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.

PhillHS #120063 11/19/21 01:58 PM
Joined: Mar 2008
Posts: 216
Likes: 2
R
Senior Member
Offline
Senior Member
R
Joined: Mar 2008
Posts: 216
Likes: 2
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.

Page 1 of 3 1 2 3

Link Copied to Clipboard
Who's Online Now
1 members (AJR), 30 guests, and 4 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,993
Posts118,149
Members5,005
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com