[C64] Support `.t64` format

[DrD2k9]

There are multiple file types for C64 tape images; namely .tap and .t64

These file types are different, but both represent tape-stored data as opposed to disk/cartridge.

While BizHawk supports mounting both types, only the programs on .tap images can be loaded and run within the emulator.

When using .tap files, BizHawk automatically "presses" 'PLAY' on the tape drive for the user, allowing the system to load the program.

When trying to load a program from a .t64 file, the system asks the user to to "PRESS PLAY ON TAPE". There is however no way of doing so in BizHawk (at least from what I can find), thus .t64 files are currently unusable even though they are recognized.

I suggest one of the following solutions: 1) Implement some sort of interface to be able to "PRESS PLAY" on the virtual tape drive so that t64 files can be fully loaded and run. 2) Implement the same automatic pressing of the 'PLAY' button for .t64 files that the .tap files already use. 3) Eliminate BizHawk's recognition of .t64 files if no other solution is possible to allow use of a .t64 file.

[DrD2k9]

After a bit more experimentation, BizHawk seems to think the .t64 file is a disk image, not a tape image. Still...trying to load the .t64 based game using syntax for disk based games does not work either.

Perhaps another potential solution to the above three options is to have BizHawk recognize .t64 files as tapes instead of disks (though this would be similar to number 2 above).

[SaxxonPike]

Option 1 will probably be the fix going forward. Automatically pressing Play was to work around a shortcoming in the UI (we weren't mapping a button to it or any of the other buttons on the Datasette for that matter).

As inconvenient as it is, there is the possibility of there needing to be a way to delay pressing Play (to seed an RNG, perhaps) so we'll need to have the users type PLAY and press the button themselves later on.

[SaxxonPike]

T64 isn't currently a supported format and has many of the same complexities as D64.

These kinds of images don't contain the complete information of the media. Emulators (and hardware!) all need to fill in the missing bits (gaps, etc) which may differ between implementations.

We have chosen a specific implementation for D64 so we will need to decide one for T64 as well, given that it really is functionally equivalent to a ZIP of PRGs. It's even higher level than D64.

If I had my way, we would only ever do G64 and TAP since they are 1:1. Alas, many titles and homebrew are only conveniently available on D64.

This issue should be named after the need for T64 support, given that it is popular enough to have been requested by multiple people.

It'd be even easier and faster to go T64->D64 like we do with PRG. But some games might still require or expect a tape drive.

I'll experiment.

[SaxxonPike]

Some interesting info about T64 files, which are apparently unrelated to tapes whatsoever and are a relic of really old emulators: https://www.lemon64.com/forum/viewtopic.php?t=71839

Now that I know they aren't related to tapes (and even have "1541 file types" on them!) I could probably just stick the contained files into a disk image the same way we do with PRGs and be done with them.

[YoshiRulz]

RetroArch supports this because VICE supports it.

[SaxxonPike]

Having reviewed how the community is using T64 and how we are handling PRG currently, I think this is a good feature to add.

We already do PRG -> D64 -> G64. This process involves creating a formatted disk image and writing the PRG as the single file as close to the directory as possible (something Commodore drive ROM already does.) We can replicate this process on tape (T64 -> TAP) by writing the appropriate signals with the gap that the Commodore system ROM uses already also.

There's a lot of variance within magnetic media as it is (which makes replay of TAS on real systems nearly impossible) but all that matters is we pick the coefficients deliberately and are consistent- they shouldn't change. I'll work out what that should look like.