Submission Text Full Submission Page

Batman: The Caped Crusader for Commodore 64

Part 1: Penguin

For info relating to this game itself please see adelikat's original submission notes.

DrD2k9's comments

One of the biggest issues with C64 TASing is load times. The first major chunk of any game from a disk or tape based media is going to be a long, very boring loading sequence. This submission presents a method to minimize this loading time and shorten overall submission lengths. Should this method be accepted by the staff/community, it will provide the potential for many future C64 TAS submissions to be shorter than they otherwise could be.

Background on how this submission came to be:

I had previously known of various programs in existence that convert C64 tape images to disk images. I thought that doing this with any games which I could only find in tape image format would save some time, as tape loading typically takes longer than disk loading. Then I thought 'Why stop there?' and wondered if there were any programs available to convert from tape/disk to cartridge format.
I found some.
EasyFlash is a C64 compatible cartridge that can be flashed with .crt game/program images and then used in a real Commodore 64.
A program called Disk2EasyFlash is able to convert some (but not all) disk based games into cartridge format. For games where this is possible, doing so yields a cartridge image that can be flashed to the EasyFlash cartridge (or in our case, used in BizHawk).
While normal cartridge games start instantly with no load time, games converted to cart format using Disk2EasyFlash still retain a loading phase before the game starts. However, this load period is drastically reduced compared to loading the game from the original disk image.
To test the theory/method of converting disks to cart for use in BizHawk TASes, I contacted adelikat to find out exactly which disk version of Batman he used for his run.
Using the same disk image, I confirmed that his original inputs (made in BizHawk 1.13.0) synced in BizHawk 1.13.2
I then converted the disk image to EasyFlash cartridge format and loaded the new cart image up in TAStudio. As expected, the load time was shorter, so I copy/pasted adelikat's inputs from where he first takes control of Batman. The rest of the run synced perfectly without any necessary alterations.
To me, this was proof of concept for converting from disk image to cart image.

Other comments on this submission compared to adelikat's original

  • I changed the version from 'any' to 'Europe'
    • I tested the game with NTSC settings and the game froze on the first item pickup.
    • I assumed this to mean it was a PAL release of the game.
  • In addition to all the time saved from the loading changes; I was able to save a further 9 frames at the end of the run by optimizing the cursor movement.
    • I confirmed that these 9 frames could be saved using the disk image TAS as well.
    • The below temp encode does not have these 9 frames cut.
    • There may be other movements that can be optimized in the run, but it will likely affect RNG appearances of a villain (manipulation of said appearances are a big contribution to the run's overall optimization)--see previous submission
  • During the NTSC/PAL testing I deleted some inputs from lag frames; these deletions persist in this submission.

Is this submission publishable?

  • 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.

For the Judge

  • 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. Please feel free to contact me on Discord or via PM in the forums if necessary for verification.

adelikat's comments, if he so chooses:


feos: We recently have a lot of rule-clarifying submissions that I need to judge.
feos: Thanks for encouraging us to rethink our rules. The general staff agreement is to allow image conversions only if it's a standard practice for the platform in question, and if it's possible with unmodified official set.
There is no proof that the image conversion that happened here (writing to a cartrige) is possible on original stock C64. It can be done with extra devices like EEPROM programmer or a flash cartridge, but neither was a standard device for regular C64 users.
The original game has not been released on cartridges. Rejecting.

TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14875
Location: 127.0.0.1
Memory
She/Her
Site Admin, Skilled player (1523)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
*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...
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Post subject: Re: #6086: adelikat, DrD2k9's C64 Batman: The Caped Crusader "Part 1: Penguin" in 04:52.73
fsvgm777
She/Her
Senior Publisher, Player (221)
Joined: 5/28/2009
Posts: 1185
Location: Luxembourg
TASVideoAgent wrote:
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.
Steam Community page - Cohost profile Oh, I'm just a concerned observer.
Post subject: Re: #6086: adelikat, DrD2k9's C64 Batman: The Caped Crusader "Part 1: Penguin" in 04:52.73
DrD2k9
He/Him
Editor, Judge, Expert player (2057)
Joined: 8/21/2016
Posts: 1012
Location: US
fsvgm777 wrote:
TASVideoAgent wrote:
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.
Memory wrote:
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?
Post subject: Re: #6086: adelikat, DrD2k9's C64 Batman: The Caped Crusader "Part 1: Penguin" in 04:52.73
EZGames69
He/They
Publisher, Reviewer, Expert player (3967)
Joined: 5/29/2017
Posts: 2707
Location: Michigan
DrD2k9 wrote:
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.
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Post subject: Re: #6086: adelikat, DrD2k9's C64 Batman: The Caped Crusader "Part 1: Penguin" in 04:52.73
DrD2k9
He/Him
Editor, Judge, Expert player (2057)
Joined: 8/21/2016
Posts: 1012
Location: US
EZGames69 wrote:
DrD2k9 wrote:
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.
Memory
She/Her
Site Admin, Skilled player (1523)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
DrD2k9 wrote:
Memory wrote:
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.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 250
Location: Stafford, NY
Memory wrote:
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.
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
Judge, Skilled player (1288)
Joined: 9/12/2016
Posts: 1645
Location: Italy
GJTASer2018 wrote:
Memory wrote:
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.
Could we Pretty Please use the voting system just for expressing how much we feel entertaining from watching the movie? The voting system is not intended for saying that you think that a submission should be accepted or not; only use posts for that.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Memory
She/Her
Site Admin, Skilled player (1523)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
Is there a method of converting between formats on the C64 itself?
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
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?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Spikestuff
They/Them
Editor, Publisher, Expert player (2292)
Joined: 10/12/2011
Posts: 6337
Location: The land down under.
feos wrote:
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.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Memory
She/Her
Site Admin, Skilled player (1523)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
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.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
Spikestuff wrote:
feos wrote:
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?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
DrD2k9
He/Him
Editor, Judge, Expert player (2057)
Joined: 8/21/2016
Posts: 1012
Location: US
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).
Memory
She/Her
Site Admin, Skilled player (1523)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
From what I see...
DrD2k9 wrote:
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?
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
DrD2k9
He/Him
Editor, Judge, Expert player (2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Memory wrote:
From what I see...
DrD2k9 wrote:
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.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
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.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
DrD2k9
He/Him
Editor, Judge, Expert player (2057)
Joined: 8/21/2016
Posts: 1012
Location: US
feos wrote:
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.
TASVideosGrue
They/Them
Joined: 10/1/2008
Posts: 2738
Location: The dark corners of the TASVideos server
om, nom, nom... sweet!
DrD2k9
He/Him
Editor, Judge, Expert player (2057)
Joined: 8/21/2016
Posts: 1012
Location: US
I'm glad this submission helped with rule clarification. While it wasn't the original goal, I'm satisfied with the result.
Joined: 1/13/2007
Posts: 335
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.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
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.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.