Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
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.

Page 2 of 3 1 2 3

Link Copied to Clipboard
Who's Online Now
4 members (Revenant, will, AJR, 1 invisible), 23 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