This topic is for the purpose of discussing #6086: adelikat & DrD2k9's C64 Batman: The Caped Crusader "Part 1: Penguin" in 04:52.73

*Admittedly, the conversion of one image format to another, is a type of hacking/modification of the original data. *The vast majority of Commodore 64 games available for TASing are already cracked/modified versions. *This particular type of modification only serves to impact non-game-related aspects of a TAS. *Therefore, I see the conversion (which minimizes the boring loading phases) as an acceptable modification of the original game images and should be acceptable for publication to any tier.

Just because we're unfortunately limited to illegitimate images, doesn't mean we should be modifying them further to be even more illegitimate...

This submission's 'ROM' is a unique cartridge image file that I created. As it was created from the same disk image that adelikat used in his run, I assume anyone else using Disk2EasyFlash on that disk image should be able to create an equivalent cartridge format image to verify this submission.

Yeah....no. For one, the game was never released on a cartridge. So, we're limited to either the tape version (and deal with absurdly long load times) or the disk version (which is often a cracked release, which adelikat used in his TAS), not a cartridge image you created yourself with some tool.

This submission's 'ROM' is a unique cartridge image file that I created. As it was created from the same disk image that adelikat used in his run, I assume anyone else using Disk2EasyFlash on that disk image should be able to create an equivalent cartridge format image to verify this submission.

Yeah....no. For one, the game was never released on a cartridge. So, we're limited to either the tape version (and deal with absurdly long load times) or the disk version (which is often a cracked release, which adelikat used in his TAS), not a cartridge image you created yourself with some tool.

Thanks for your input. The whole point of this submission is to get feedback from the community's perspective. Also for clarification, most of the tape releases out there are cracked versions also.

Just because we're unfortunately limited to illegitimate images, doesn't mean we should be modifying them further to be even more illegitimate...

Thanks for your input as well. For the sake of debate and trying to consider all perspectives: What makes one illegitimate image any more/less valid than another illegitimate image?

The whole point of this submission is to get feedback from the community's perspective.

You could have easily did that if you made a topic about it in one of the other form threads. You didn’t have to make a submission just to ask the community what they thought of the idea.

The whole point of this submission is to get feedback from the community's perspective.

You could have easily did that if you made a topic about it in one of the other form threads. You didn’t have to make a submission just to ask the community what they thought of the idea.

I did it as a submission on adelikat's suggestion.

Just because we're unfortunately limited to illegitimate images, doesn't mean we should be modifying them further to be even more illegitimate...

For the sake of debate and trying to consider all perspectives: What makes one illegitimate image any more/less valid than another illegitimate image?

Well one is forced to be illegitimate due to lack of more legitimate images. One uses that original illegitimate image, and modifies it to be even further from the original release than before. In the event that somehow legitimate images were submitted, we would prefer them over all illegitimate images. EDIT: So qualitatively, this image is illegitimate in two ways instead of one.

So qualitatively, this image is illegitimate in two ways instead of one.

THIS = main reason I voted No. Submitting this was a bad idea from the beginning, even if it was adelikat that suggested you do it in the first page.

Is there a method of converting between formats on the C64 itself?

I would say the image is identical, only the contained is different. After hearing Nach's thoughts on this, I view such conversions the same as codes making cosmetic changes, or GameBoy games running in later console modes. Converting every game sounds scary though. Where would we draw the line?

Where would we draw the line?

If official then Yes (There should be a few C64 cases where it released on both formats). If something like this then No.

IMO if a system allows you to convert between formats without any additional tools, then it should be fine to allow anything for any game. If not, then only what it was released for should be allowed.

Where would we draw the line?

If official then Yes (There should be a few C64 cases where it released on both formats). If something like this then No.

That's not what I mean. The argument is that the platform itself allows you to copy a game from one medium to another, by having both inserted and executing some basic commands (it's a computer after all). It's like installing an OS from a CD/DVD versus a flash stick. The image is identical, and it behaves identically, but the physical characteristics of the medium can be used to improve the situation in some way. So the actual question is, will we ever be losing/missing something important if we convert every such game?

Some further thoughts from me on this whole concept: The C64 could copy between Tape and Disk formats using commands within the system itself. Much of the copy protection of the era was based on specific data positioning on whatever format was used for the game (which is why so many game versions currently available are cracked to begin with--to bypass this type of copy protection). I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible). The way I understand the Disk2EasyFlash program is that the C64 reads the .crt image as it would any other cartridge. The conversion basically makes the original disk-based game code run from the EasyFlash cartridge as if it's reading from a disk drive (only a much faster disk drive than the 1541). Basically, I see the conversion somewhat akin to reading the game information from a 48x speed rom vs a 2x speed CD rom. Or reading data from a USB drive instead of an old floppy drive. The game data remains effectively the same. It's just where the C64 looks for that information is changed from the 1541 Disk Drive to the cartridge slot. Then the converted .crt image mimics the disk drive to provide the C64 with the game data. It's why there is still a loading screen when using the converted image. The reason the converted image has faster loading is because data transfer from the cartridge slot was much faster on the C64 than data transfer from a 1541 disk drive--which itself had a known issue that made loading from the 1541 slower than it even needed to be (fastload carts were made to help this particular issue, thought that might be off topic a bit). So to answer feos' question about what is lost/missing...other than for games that won't convert in the first place, nothing from a game itself should be lost by the conversion. The only thing lost/missing is waiting periods for loading. As far as the C64 system itself is concerned...how long a game takes to load isn't important to the C64; only that the data is present in memory when it's time to actually run the program. Further, I can't imagine a programmer specifically tying whether or not a game works properly to how long it takes to load the game's information from a disk/tape; because that timeframe can vary slightly in a real-life situations from one C64 system setup to another. As far as load time affecting the game itself, the conversion shouldn't affect how the game plays aside from possible RNG effects as described below. There are two possibilities where a game's RNG may be affected using this conversion method: 1) Situations where a game bases its RNG on the C64's internal time value--how many jiffies (1/60th of a second) from 'power on'. Games using this RNG approach are equally affected by sitting idle on the boot screen before loading a game for any number of frames as they are by loading times. 2) Situations where games require multiple loading sequences during the course of gameplay. If these secondary loading sequences affect frame/time based RNG, it could potentially affect the RNG outcome of the game. If the loading sequences do not affect the frame based RNG, this is not an issue. So loading faster should only change RNG values, not the how the C64 runs the loaded game code itself. In either of the above RNG situations, the game should still play as it always would, just with different RNG. One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat. EDIT: For this specific submission, the RNG wasn't affected at all by the difference in loading time/system time. RNG is therefore affected only by in-game actions or by the time since the game-code was 'run' (which is equal between the submission and the published run).

From what I see...

One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat.

Contradicts

I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible).

What do you mean?

From what I see...

One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat.

Contradicts

I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible).

What do you mean?

I was saying that I'd gladly use an EasyFlash cartridge on my C64. As the disk2easyflash program is a PC program for converting from disk image to crt image format, the conversion wouldn't take place on the C64 itself. Regarding the part about converting from disk to cartridge on the system itself: I don't know what all would be required to create a classic cartridge. At minimum, you'd need all the cartidge hardware and an EPROM programmer to program the cartridge from the C64. It does appear that it's possible to create a .crt image on the C64 itself from data on other C64 media and then copy that .crt image to the EasyFlash cartridge. see here. http://skoe.de/easyflash/doku.php?id=writecrt I don't know how/if disk2easyflash is better/worse/equivalent to doing so in this manner....but it's a heck of a lot easier in my opinion.

Requiring devices that don't normally come with the console or the computer in question, nor with their games, and aren't even among common peripherals for casual use, sounds like using a devkit version of the system or the game: arbitrary requirement that one is not supposed to have to simply play those games. It's a shaky ground, and it might sound simple for simple systems, but with modern ones that support tons of peripheral types and approaches, it will drive us crazy if we allow arbitrary addons.

Requiring devices that don't normally come with the console or the computer in question, nor with their games, and aren't even among common peripherals for casual use, sounds like using a devkit version of the system or the game: arbitrary requirement that one is not supposed to have to simply play those games. It's a shaky ground, and it might sound simple for simple systems, but with modern ones that support tons of peripheral types and approaches, it will drive us crazy if we allow arbitrary addons.

This perspective makes sense. Also, I had a brief, but good discussion with someone on discord who was concerned that this approach may set a bad precedent for other systems. To paraphrase that discussion, the concern was that finding a way to alter loading times on some systems can affect gameplay timing/strategy because gameplay occurs simultaneously with loading times. The example used was loading a Wii game from a USB instead of a disc, which might cause some rooms/map areas to load faster and alter whether or not certain glitches/strategies could (or couldn't) be utilized when they are for the standard/original media. While I'm unaware of any C64 games that have such loading periods simultaneous with gameplay, there may be a few out there that do. So, as much as I'd like to see the shorter loading times accepted for C64, I don't want to set a bad precedent for other systems. Unless the staff feels that there is still potential for this method to be accepted (via whatever rule/guideline updates may be necessary), I am willing to cancel this submission. If an official ruling would be better so as to set a precedent in the other direction--preventing such media conversions--I am also willing to let it stand and be 'judged' officially. Either way the decision ultimately goes, I feel the site stands to gain a more concrete approach to TASing across all systems. Thank you all for your perspectives and consideration.

om, nom, nom... sweet!

I'm glad this submission helped with rule clarification. While it wasn't the original goal, I'm satisfied with the result.

Here are things that were commonly done on the real c64. 1) snapshot carts. this converted a protected game to either a single or dual file backup copy of the game. this didn't always work, but when it did you get something that loads much faster than the original usually. they also have a bonus of setting the rng to a known state. These are non legit, but were applied to original disks and tapes. you can perfect this trick using a c64 emulator. this is legit because a god could freeze the game at the exact right time. using emulator specific features, i can TAS the freezing process. :) but if the freeze button was pressed at the exact right time, identical results can be created on real hardware. Of course many games don't require such precision to freeze properly, such as Mr. Do. (you just wait for the static title screen and press the freeze button.) 2) tape to disk transfers. there were c64 side utilities that could do this. novaload in particular was often converted this way. with an added fast loader, again it could load faster. Again there are PC side tools to do this faster, but this is something that WAS done on the real system. so we have some questions. 1) is attaching a speeder cart (commonly done with a real machine at the time) acceptable for speeding up load times? The standard available carts for NTSC are Epyx Fast Load, and AR 5.0. europe has a much greater variety. I vote yes, when it helps. 2) is using freezer snapshots okay provided it was done with an original? if so this can significantly decrease loading time. I vote yes, provided that it was done from an original, and it was done at the earliest possible safe freeze point. 3) is crunching said snapshot okay? this can be (and was often) done on the real c64, to create a smaller file, at the expense of decrunching time. generally, this is faster to get to the title screen. I believe yes, and that it's okay to use the PC side tool, because c64 side tools existed that could do the same thing. but it's understandable to rule that only c64 side tools can be used. 4) is using the vorpal utility disk to convert said freezer snapshot, along with the vorpal loader okay? this creates a .g64 image that would work on real unmodified hardware, if written back. This image will load at 25 times the speed of the original file. I would again say yes. 5) is saving an action replay snapshot in warp*25 format (equivalent to vorpal) okay? these again can be made to boot without the cart i think, but can boot easier with the cart. again .g64 image is required, and it's doable on the real computer. again this is a 25X speedup compared to the original loading time of the snapshot. I say maybe? 6) is using tape to disk transfers okay? Again i say yes, provided the game actually works and loads faster this way (possibly with the help of a cart speeder) 7) is memory injection okay? I'd say no, because it cannot be done on real hardware of the time period. easyflash and/or backbit can sorta do this now, but they were not available during the commercial lifetime of the system. 8) is non true drive emulation okay? again, no, because you can't do it on real hardware. 9) if it ever gets emulated, is using a sd2iec+easyflash jiffydos cart okay? If it is ever emulated, it provides a 20x speedup. Maybe. but it's unlikely to ever get emulated. 10) are REU loads okay? this IS emulated, so if the above tricks are okay, then super fast loading the onefile from an REU should also be okay, as that is doable on period hardware.

Only things that require no homebrew tools (software or hardware) are allowed: what you officially buy is all you have, in this case the C64 with original (and emulated) peripherals and the game.