Come up with a filename extension for a new clean P2000 cassette format which uses 32-byte headers

[dionoid]

@yqxq suggested creating a new 'clean' cassette format for the P2000 which uses 32-byte headers, compared to .cas which uses 256-byte headers of which 224 bytes are random/unused.

To prevent problems with other P2000 emulators (e.g. Mame), this new cassette format needs a different file extension. Suggestions:

• .p2000t
• .p2k
• .tap
• .mdc - Mini Digital Cassette
• .mc - Mini Cassette
• .casx

[dionoid]

My 2 cents: I prefer .tap because:

• It is short
• It is clear this is a tape file
• It also works on the MSDOS version of M2000
• It is in line with M2000's -tape command line argument. The default created tape file could then be named Default.tap
• It conforms to the commonly used file extension for retro-system tape files:

[ifilot]

I have the following to add to this discussion:

• I would warmly recommend using a 3-digit extension. .tap looks good to me. I personally also like .p2k. I find consistency with other retro projects a strong argument for going for .tap
• When developing a new format, we should critically think whether we want to add additional features outside of saving 224 bytes. On modern operating systems with huge storage space, that is by itself not a very strong argument to develop a new file format. In terms of new features, I would propose the following

New features

• Support for CRC. I have recently implemented a CRC-16-XMODEM checksum on all my files for every 0x400 byte chunk. CRC-16 is supported on Z80 and can be evaluated relatively fast. CRC ensures that an end-user can always validate the integrity of the data. Note that P2000T also uses checksums, but these are relatively weak.
• If we truly believe size reduction is a criterion, we can consider adopting compression. bzip2 is supported on Windows, Linux and MacOSx and gives good compression in short execution times. That being said, I would not be in favor of this as the files are very small as it is.
• Consider whether we want to use a fixed-format file or whether we want to adopt more modern storage solutions using "key-value" alternatives as used by programs such as Word and Excel. The advantage of "key-value" storage is that you can easily expand such storage types, making them more robust in terms of feature creep.
• If we adopt key-value type of storage files, we could embed a comment and copyright section to every file, acknowledging the author(s) of the code, the distributor or sharing some nice trivia. M2000 could even have a menu showing this information upon request.

[dionoid]

Note that size reduction isn't important to me: it's the fact that the headers in a .cas file have 224 "wrong" bytes that were not read from the tape header + data blocks. Also, I think it should remain straight-forward to transfer the cassette data from a P2000 to a PC (and vice versa) using RS232, so that's why I prefer to keep the format just a dump of the cassette header + data blocks.

[yqxq]

I'm tweaking the dump tool to fix the glitch, it is actually quite simple to have it send/receive less, it also speeds up transfers by 20%. .p2000t has the benefit that you can attach an app to it in Mac/Win/Linux. 3 char ones won't work, as most are already claimed by the vast amount of other emulators. Having double-click in the Finder/Explore work is a massive benefit to open files from the menu. And you see right away what it is. CRC is not needed IMO, as I mod the heck out of cas files in a HEX editor. Then for every edit you need to fix the CRC. It is not that 2400 baud messes up a lot...

[dionoid]

I see the added value of being able to choose a default app for a specific extension, but I would like to keep it 3-chars so it will also work with the DOS version of M2000 without having to make exceptions in the code. What about .p2k ? Seems like a reasonable compromise and no other emulator is using that extension.

[ifilot]

Also, I think it should remain straight-forward to transfer the cassette data from a P2000 to a PC (and vice versa) using RS232, so that's why I prefer to keep the format just a dump of the cassette header + data blocks.

Very clear. Given that scope and intention, the features I proposed would only complicate matters.

but I would like to keep it 3-chars so it will also work with the DOS version of M2000 without having to make exceptions in the code

I agree with this. For optimal backwards compatibility, we should natively support a 8+3 filename which puts a 3-character limitation on the extension.

[dionoid]

To bypass this discussion: M2000 actually doesn't care about the file extension for cassette files. In the next release M2000 will auto-detect and support 256-byte and 32-byte headers and handle both appropriately. New cassette files created by M2000 will remain using 256-byte headers.

Closing this item for now. Feel free to reopen.