(Link to video)
This movie is a movie for Atari 2600 "Dragster." The game itself is incredibly short and fairly straightforward, but it has some historical significance for gaming and speedruns in general. The primary goal is simple: clear a quarter-mile track by holding your engine in red-line and shifting at opportune times. This was among the first games to emphasize speed as a primary metric for success as opposed to score.

Game objectives

  • Emulator used: BizHawk 1.12.1
  • Aims for fastest in-game time (Player 1, top half)
    • Secondary goal: aims for maximum distance
  • Aims for track completion with fewest input frames (Player 2, bottom half)
    • Sacrifices time for entertainment
  • Does not early start or blow up (disqualifications)
  • Inputs should be compatible with all known releases of Dragster

Comments

There's quite a history for this game. It initially released with a challenge in the manual to beat "Activision's Best" by matching or beating a time of 5.74. The actual time an Activision employee achieved prior to launch was a 5.64, but they wanted to advertise a more generally achievable time. In 1982, player Todd Rogers claimed a time of 5.51, which was supposedly verified in front of Activision staff and received wide acclaim. To this day, that time has not been beaten or tied.
I took interest with the game based on this story and the fairly suspicious fact that nobody beyond Rogers has ever achieved better than 5.61. Clearly there must be some obscure bug that he used to gain such a significant advantage, right?
Thus, I disassembled and reverse engineered the entirety of Dragster. This was key in understanding the major pieces of the speed and distance system, but also gave me a chance to check for what shenanigans you might be able to pull off with oddball inputs or otherwise.
And I came up with nothing. The game has some very strict checks for inputs, and on every reset and boot will completely clear all memory related to any of the interesting values. Checks related to major mechanics are all fairly straightforward, and errant inputs have no sway in most of them. Player 1 and 2 inputs are handled on opposing frames, and they each have their own distinct memory addresses for each mechanic. So there's not a whole lot you can do outside of just playing normally. Mechanics explained in more detail below.
Based on all this reversing, I built a model of the speed system so that I could easily identify impacts of shifting at certain times. The inputs can be directly used in emulator, and I verified that they give the correct times and behavior.
This movie covers both the best solution we've developed so far in terms of in-game time and distance on Player 1, as well as the minimum number of frames of input to reach the finish on Player 2. Both were theorized in the spreadsheet and later verified in BizHawk.

Game Mechanics

Relevant Addresses

AddressDescription
0x01Global frame counter
0x0DCountdown timer
0x0FActive player
0x28Tachometer value
0x33IGT Seconds (BCD)
0x35IGT 0.xx digits (BCD)
0x37IGT 0.00xx digits (BCD)
0x3ADistance
0x40Speed
0x42Subdistance
0x4CShift state & current gear
Add 1 to any of the above addresses for equivalent Player 2 address.

Victory Conditions

You complete the track as soon as your distance exceeds 0x60. If you shift into first gear before the countdown is 0, you are marked as "Early" and disqualified. If you push your tachometer value too far into the red, your engine will blow out, and you'll also be disqualified.

General Operation

You have only two gameplay-related inputs: the gas (button) and clutch (left on stick). You can also reset at any time, but it just starts from the countdown. There is a second mode where you also must steer with up/down, but that mode isn't used in this movie. You start in gear 0, and every time you engage and then release the clutch the gear value increments by 1, up to a maximum of 4. You can rev your tachometer up to a maximum value of 0x1F; at 0x20 or higher, you will blow out.

Speed and Distance Mechanics

The game sets up a moving "speed limit" of sorts based on your tachometer value and current gear. On every active player frame, the game checks if your current speed is less than the current "speed limit;" if the speed is less than, it increases speed by 2. If equal, no change. If the limit is less than your speed though, speed decrements by 1. Additionally, if the clutch is currently engaged, speed does not decrement or increment.
The speed limit itself is equal to the tachometer value rotated left by the current gear value minus 1. If the tachometer is in redline condition (value equal or greater than 0x20), an extra 1 is also rotated in, giving you an extra limit overhead of +1 at gear 2, +2 at gear 3, and +4 for gear 4.
Every player frame, the current speed is added to the subdistance. If subdistance overflows, the distance value is incremented.

Tachometer and Shifting Mechanics

Since the tachometer is the lone direct influence on your maximum speed, it's important to maintain as high a value as possible throughout play while avoiding blowouts. However, the game has a fixed acceleration window for the tachometer based on the difference between the current speed and the speed limit. If the current speed is more than 0x10 below the speed limit, the tachometer value is decremented by 1, affecting the speed limit for the next player frame. This mechanic discourages shifting up too quickly.
The tachometer value will change based on a frame rule to check whether the gas is currently engaged. As the gear increases, the frame rule for checking whether the gas input is held also increases. At gear 1, it checks every player frame. 2 is every other player frame; 3 every 4th; 4 every 8th. If the gas is held when the frame rule is engaged, the tachometer value increments by 1. If it is not held, the value will decrease by 1. This frame rule occurs based on the global frame counter, which means that the frame counter value itself influences the incrementing pattern of higher gears.
The tachometer also behaves differently while the clutch is engaged or in gear 0. In either case, rather than incrementing or decrementing by 1, it will instead change by 3. This is still dependent on whether the gas is also held during the frame that the clutch is engaged. This activity occurs instantly regardless of the frame rule.

Strategy

The general strategy is to maintain as high of a tachometer value for as long as possible, and then shift after reaching the maximum possible speed for your current gear. However, since the distance between your max speed and the current speed affects tachometer increments and decrements, it is sometimes better to shift earlier and maintain a higher entrance value to a particular gear. Additionally, once in gear 4, successive shifts are used to re-raise the tachometer value once speed reaches a point it can no longer increase. This temporary rise in the speed ceiling allows for optimal progression.
Shifting as late as possible without affecting speed is beneficial to the subdistance; for every frame earlier that a shift occurs, 2 subdistance units are lost. Removing a shift entirely would save a lot more than that, but you generally can't remove a shift without losing speed incrementing opportunities elsewhere.
Until you reach the speed ceiling, there is no benefit to letting the speed fall by 1 unit during a player frame. The loss of an effective 3 speed cascades throughout the rest of play and makes a huge difference in distance. At the speed ceiling, however, you can briefly lose 1 speed in order to gain 2 and then lock in your max speed of 253 instead of 252. This helps a fair bit as soon as I reach 252 for the first time, but is detrimental any time before that.
Finally, since the frame counter influences the tachometer increment pattern, it's key to play around with all of the 8 possible seeds to find an optimal shifting pattern. A different seed alone can have a significant influence on end time; getting a 5.57 is not possible under all seeds.
For completing the game in the fewest frames, the goal was instead to get to a fast enough speed and rev the tachometer to max before stopping all inputs. This allowed the speed to continue advancing for a dozen or so frames before the tachometer had gone down far enough to force the speed into decreasing. Then it was just enough to have it limp across the finish line under its remaining momentum.

Closing Comments

I opened these comments with mentioning Rogers's claimed 5.51. Over the course of this investigation, I've pretty well determined that a 5.51 is not possible according to the available game model. Since there are no details on what actually happened when he claimed it or who might have witnessed it, there's no way to say if it was cheated or a result of a hardware problem or if it even happened at all. Either way, this research and model should be enough to show that it's not possible on normal conditions. Even with some types of cheating (starting in gear 1 without shifting, starting with 2 speed, etc), a 5.51 is not possible.
As for the movie itself, this is the best I've been able to find that maximizes the remaining subdistance after crossing the finish line with a 5.57 (this specific solution originally pointed out by Reddit user Kragnir). In this case, you end up with 98 units of "spare" subdistance; still about 158 units away from the next best timer value of 5.54. The inputs for this are demonstrated by the Player 1 slot, and the last input frame is 508. Note that there is a delay at the beginning in order to align the correct frame rule.
As a secondary goal, I went for the typical TASVideos goal of least frames of input to finish, regardless of in-game time. This is demonstrated by Player 2, and the last input occurs on frame 343. Note that this could be improved by 2 frames but would require a different frame counter value than the IGT goal, so this tradeoff was made to be able to show off both at once.
There might be room for improvements, but I've checked all of the obvious alternatives that follow the general strategy rules. Even if improvements are found, I expect that they would only provide small amounts of additional subdistance on the shown 5.57; 5.54 is a long way off, yet. The number of possible positions for 9-10 shifts over the course of all ~250 optimizable frames is tractable, so it is possible to brute-force a true optimal solution. Until then, feel free to toy around with the spreadsheet model and see what you can come up with.
~Omni

feos: Judging...
feos: Updated the movie file.
feos: This is a great movie in so many aspects.
First, it deconstructs this advertising myth that lived for so long.
Second, it includes extremely elaborate research, to the point of full simulation.
Third, it showcases 2 types of goals in the same run: fastest real time and fastest in-game time.
Fourth, in optimizing in-game time, it uses a special goal: achieving farthest distande and subdistance in the shortest time. So by that it beats the known run by Samsara, who likely hasn't set such a goal, so the runs are probably not very comparable. They are probably also not comparable due to heavy emulation improvements of the A2600 core that has happened since that run was made. Though Samsara's run stops sooner while getting the same in-game time, it doesn't reach the subdistance reached in this run, so basically it's overall speed is lower.
If someone reimplements that movie to reach farther subdistance than this run does, in the same amount of time, or to reach the same subdistance sooner, it might obsolete this run. Finding the perfect formula for real time movie length against farthest subdistance might be a challenge, if we default to getting the same in-game time for fair comparison.
But since we're not here to make and publish only unbeatable movies, especially when the improvement is only potential, I'm accepting this gem to Moons.
Fog: Processing.

TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14776
Location: 127.0.0.1
This topic is for the purpose of discussing #5517: Omnigamer's A2600 Dragster in 00:08.49
Spikestuff
They/Them
Editor, Expert player, Publisher (2254)
Joined: 10/12/2011
Posts: 6324
Location: The land down under.
Oh it happened. Oh it's short. Oh it's a Yes Vote.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. These colours are pretty neato, and also these.
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
A long overdue and excellently researched TAS. Maybe this game will finally be put to rest? It's not looking like 5.54 can easily be hit, but who knows?
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Nice work researching this Omnigamer. This level of research definitely seems sufficirnt to me.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
Joined: 8/1/2006
Posts: 428
The strategy at the end is to achieve a speed 1 higher than the highest possible speed limit and hold clutch until the finish line, right?
Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host
Player (33)
Joined: 2/16/2012
Posts: 282
Based on JSmith's comment, I went back and fiddled with the race end a little to eke out an extra 24 units of distance. Dropping the speed to get an odd speed value in general is never beneficial in terms of your total distance, but once you've reached the speed ceiling you sacrifice much less. Thus I came up with a new addition before going full-clutch that goes to 251 speed for 2 frames, then 253 for the remainder. This led to an additional 24 units of subdistance. I also checked the other 7 frame counter values to be sure this didn't change anything for them; it allowed more of them to hit 5.57 at all, but 12 was still the optimal seed by quite a bit. I updated the movie to reflect this. It's still the same length, and only 4 frames of input were changed. The submission text and temp encoding were updated to reflect the change. New movie file below: https://www.dropbox.com/s/n3ny4bhh5u18ced/Dragster%20%281980%29%20%28Activision%29%20%5B%21%5D.zip?dl=0
Joined: 8/1/2006
Posts: 428
The submission also doesn't mention your starting strategy. Revving the engine doesn't trigger a false start. It appears you start with just barely enough tacheometer not to pass out the top of the acceleration window. An alternative strategy would start with almost the maximum tacheometer, let it drop into the window. Playing with the spreadsheet, this strategy appears to let you postpone your first gearshift for one frame. It's not clear whether this saves anything overall given the frame rule.
Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host
Player (33)
Joined: 2/16/2012
Posts: 282
The opening strategy is pretty much fixed. Since in gear 1 the frame rule is every frame, you can get to the optimal gear 1 ceiling (32) on the same frame regardless of the frame counter. So long as you start with 15 or greater tach value, you can always hit this point with some selective gas presses and without dropping the speed at all. There is an alternative strategy where you'd shift up in gear 1 when you reach a speed of 28 (corresponding to tach value 28). This lets you start gear 2 with 31 instead of 28 tach. In almost all cases I tested though, this performed worse than letting it get to 32. You can see this strategy used for the gear 2->3, though.
Skilled player (1648)
Joined: 7/1/2013
Posts: 433
How does this TAS compare to the 5.57 runs by Samsara and Scepheo? I was not able to play either of these .BK2 files in BizHawk version 1.12.2. Samsara's run: 483 Frames http://tasvideos.org/userfiles/info/33353116652920969 Scepheo's run: 481 Frames http://tasvideos.org/userfiles/info/16829498686422249
Player (33)
Joined: 2/16/2012
Posts: 282
I am on vacation presently, so I can't check either of those. If anybody tries to load them up, you can use the finishing subdistance of player 1 ($42) to draw a comparison between their runs and my own. The updated TAS finishes with 98 additional subdistance units.
Joined: 6/4/2009
Posts: 893
since i read someones theory about this run (was it omni's there, or somone ( omni?) on a A2600 emulator in minecraft on /r/speedrun ?) i was expecting someone to try to TAS this game and i'm not diapointed; yes vote.
EgixBacon
He/Him
Player (181)
Joined: 4/15/2013
Posts: 331
Location: In the attic
Wow, someone actually submitted a run of this? That's cool I guess, considering how long ago Samsa and I first tested TASing this game. It's kind of a shame that anything less than a 5.57 doesn't seem to be achievable (not trying to claim Rogers was a cheater or anything...) but it's abundantly clear how much research the author put into this so I'm giving it a Yes.
FanFiction|Youtube Still on Win7! Take that, Microsoft!
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Samsara's run reaches Distance 0x61 at frame 499, the in-game time (reached the next frame) is the same as in this run, 5.57. Not sure how much emulation differences affect that, but they might, just like in HERO, where in a more recent a2600 core version the HERO is falling slower. Omnigamer's latest movie reaches Distance 0x61 at frame 513, and in-game timer stops the next frame, at 5.57. Interestingly, if I cut Omni's movie at frame 483, where Samsara's run ends, it still gets the same in-game time at the same frame. Scepheo's movie reaches Distance 0x61 at frame 529, and the time set the next frame is 6.07 (no idea why the movie is called 5'57). But Scepheo's movie lets me truncate it at frame 469 and get the same result.
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.
Player (33)
Joined: 2/16/2012
Posts: 282
I can't test either at this exact moment, but scepheo's movie is circa 2014. I don't know which BizHawk version was used, but there have been numerous Atari accuracy improvements since then. The discrepancy (6.07 instead of 5.57) is likely due to a faster or slower system startup. An adjustment of even one or two frames can throw off the frame rules and drastically change the effect from shifts. Judging from just the time characteristics feos listed in the prior post, the difference between my run and Samsara's is likely just the starting frame counter value. I include an additional delay at the beginning to optimize distance traveled over the finish line. I go for frame_ctr%16 = 12, but I believe a 5.57 is also possible at frame_ctr%16 = 0. That accounts for most of the difference, while the rest may be from further accuracy improvements. I'll check it when I get home.
Joined: 8/1/2006
Posts: 428
"If you shift into first gear before the countdown is 0, you are marked as "Early" and disqualified." -> says you can hold clutch during the countdown and shift into first gear on frame 0 instead of 1. But the actual game works differently?
Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host
Player (33)
Joined: 2/16/2012
Posts: 282
You can hold the shift for as long as you want during the countdown, it doesn't actually increment the gear until you release it. This same code path is what checks for whether the countdown is currently at 0, and marks you as early if it isn't and the gear increments. Thus, you can legally complete the shift into first on the first actual frame the countdown is 0.
Joined: 8/1/2006
Posts: 428
The sim spreadsheet does not appear to allow holding the clutch before frame 0.
Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host
Player (33)
Joined: 2/16/2012
Posts: 282
Holding clutch before frame 0 has no gameplay impact. You don't shift into first until the clutch is released, and your speed is also locked at 0 for as long as you hold it. The spreadsheet represents the entire prior sequence as the frame 0, so the first actual frame that the shift "activates" is correct as shown in the spreadsheet. On the other hand, if you're asking about cases where you might cheat the "start early" flag, then you can approximate it with custom distance and/or speed at frame 0. Based on some quick n' dirty calculations, you could start at frame 0 with a distance of 8 and a speed value of 32 if you automatically start the countdown in gear 1. This leads to a best time in the neighborhood of 4.77. You could do quite a bit faster if you somehow could advance to 2nd/3rd gear during the countdown as well, but starting in 1st is enough of a stretch as it is.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
To clarify, I'm waiting for Omnigamer to check the movie I mentioned and tell whether its results are relevant or not. Also, I need to know if I should use the trimmed movie, that would accomplish everything at the same time with the same results, but just end sooner by a few frames (see my previous post).
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.
Player (33)
Joined: 2/16/2012
Posts: 282
Samsara's movie starts with a frame counter that is equivalent to 0, and also releases the clutch some frames early to just barely cross the finish line with a 5.57. That movie's subdistance going over the finish line is 1. This is fine by itself, but it doesn't meet the secondary goal I described in my notes. There are many combinations of ways to get a 5.57 time. What I optimized for was crossing the finish line with as many additional subdistance units as possible, which is a more challenging problem and represents as close as I can get to the next time increment. If there are improvements found down the line that might enable a 5.54, the strategies available in this movie are of much greater value for future TASers when it is optimized for remaining subdistance. If you're saying for submission purposes that the movie should aim only for the soonest possible 5.57 time in term of gameplay frames, then I would have to re-optimize and re-submit. But overall, I think the movie I have posted is more significant in terms of technical achievement than finding a slightly sooner 5.57.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Ah, you mean your subdistance is farther than if you release the buttons a bit sooner. I'm just brainstorming, no need to redo if it meets the set (solid) goals and ends up being entertaining.
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.
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14776
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [3430] A2600 Dragster by Omnigamer in 00:08.49
Joined: 12/30/2013
Posts: 12
amazing work omni. do you have disassembled/annotated dump of the code on GH or anything? i'd like to take a peek my *guess* is that there's some small inaccuracy in our emulators, and that's why we can't TAS a 5.54. but who knows.
Player (33)
Joined: 2/16/2012
Posts: 282
I am not going to release the disassembled code for legal reasons. The best course if you want to work through the code yourself is to obtain a copy and perform the disassembly. The information in the notes and in the thread should be a good headstart in understanding the major game functions. A small bit of inaccuracy is extremely unlikely to be an issue here. There's just a significant mathematical barrier to hitting the next time increment that would require a lot more to change. The simulator is also built off of the code itself, so it shouldn't be affected by any inaccuracies in the Atari emulation core.