Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Samsara wrote:
Brainstorming here so I don't forget later when I have time to work: Is that spawn based on a trigger? If so, do we know where it is? Could it still be faster to skip ahead then work backward to activate it?
The snowball looks like it just spawns at a particular screen scroll point. The snowman looks like it spawns somewhere around where the first snowman is after the big icicle falls down.
It looks like the time it takes for the snowball to hit you plus the agonizingly long time it takes to get up again is too long to save time, so I don't currently think this trick is a time saver.
feos wrote:
It also hasn't been proven that skipping checkpoints you can spawn the later checkpoints. Might need testing.
I have spawned the level end checkpoint while skipping other checkpoints, but it doesn't matter because the level still won't end.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ oh that is a clever trick I didn't think of that, thanks feos : )
yeah I tried something similar on that neighboring slope but once I noticed the snowman didn't spawn it proved too slow to be useful. I think the clear point is pretty far away.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
Here is a somewhat optimized level 4. I tried different tricks to change the route and / or avoid checkpoints but it seems you ultimately have to hit all the checkpoints to beat the level.
I don't have any new ides how to change the route and this follows the same route from the 2 player warps run. If anyone has any ideas I would like to hear them!
Here is the file:
http://tasvideos.org/userfiles/info/29170580927508065
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Mothrayas wrote:
If you still have criticism towards something the guidelines say, then please clarify again in a way that's unambiguously about the guidelines and not a judge's personal, unenforced opinion.
Well for me one outstanding issue is what precedent, if any, accepting a run on one difficulty has on possible future runs on another difficulty.
Let's take Return of the Jedi as an example but there are other recent ones as well (Oregon Trail comes to mind.) My question is, if a run of these games is made on 'hardest difficulty' and are deemed to be highly/sufficiently entertaining, what would happen to them? Surely Jedi mode in RotJ would be much longer then easy, so if it's accepted it seems it's branch would need a separate branch 'Jedi (hardest) difficulty' even though we don't currently treat difficulty formally as a branch. What's more, the two movies would be 'entertaining' for more or less their own reasons, yet would still be beating the game 'as fast as possible' in their own ways.
So, can difficulty setting ever be considered a 'branch' in this way? Should it formally be a branch?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I had some time to look over some of the other 2600 runs and see if any of them are impacted by these bugs. I found a couple that had tell tale signs of left edge of the screen glitchiness / double sized player bug.
[2898] A2600 Airlock by Gay in 01:51.68
In the encode of this run you can see that towards the left edge of the screen the player suddenly shifts a few pixels. This is not present in Stella. This is caused by the 3-2-1 bug. The run de-syncs after the bug is removed.
[2228] A2600 Bobby is Going Home by Lollorcaust in 01:16.13
You can see similar shifts in the encode of this run that shouldn't be there.
[2500] A2600 E.T.: The Extra-Terrestrial by CoolKirby in 00:25.13
ET's spaceship is incorrectly placed in the intro cutscene. Being a double sized player, it is one pixel too far to the left. Doesn't look like a sync issue though.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Samsara wrote:
Speaking of which, something I'd really like to see a lot more scrutiny given when people say why they chose a lower difficulty. What I see myself a lot is that if the author gave a reason, any reason at all, that is the final word on it and any further discussion or check on the veracity of those reasons is treated as a personal attack.
No. Never. This kind of behavior is what I'm trying to prevent. Difficulty should never be the focal point of a run. It serves no purpose to attempt to dispute it. The reason why the author's explanation is the final word is because it should be the final word.
Unfortunately, the way the guidelines are written, and the way they are tied to the blank (any%) branch for a game, encourages this behavior, in fact even gives it a great deal of importance.
What we have is what should be an objective requirement, beating the game as fast as possible, that is given the subjective modifier of 'following the difficulty guidelines.' Not only that, but this falls under the TECHNICAL requirements for the run. This encourages scrutiny not only of entertainment value, but whether or not the chosen difficulty is justified in being the any% branch run for that game. This is quite an impactful decision to make, and given that it has to be done on a game by game basis, it's no wonder we wind up in such a mess! 8D
In order to put the focus on entertainment, difficulty setting cannot be tied to technical validity. Either make fastest completion flat out fastest completion, or define the default fastest completion run to be on hardest difficulty, and make it a rule not just a subjective guideline. In both cases, other difficulty settings would naturally become branches and be judged as any other branch, by entertainment value.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ thank you feos! Should save us some time in working on that one part.
Well I guess it's time to move on to level 4. We'll try to post a WIP every few levels.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Samsara wrote:
So if a movie's already in Vault or destined for Vault, I would agree that easiest difficulty would be preferred.
* An easier difficulty run has to remove boring repetition to obsolete a harder difficulty run, unless it's a Vault run, in which case it just has to be faster
If nothing else this is at least consistent. Previously there seemed to be a mismatch between fastest completion and preferring hardest difficulty. This resolves it. If this is definitely the direction things are going I might suggest simultaneously updating the vault description:
Vault wrote:
The guidelines for difficulty settings, and password use still apply.
Difficulty guidelines are no longer relevant here. I might suggest instead replacing it with something that says 'choose the fastest difficulty setting' just for clarity.
About 1/4 of the current 'hardest difficulty' runs are in the vault, meaning they can immediately be obsoleted by runs that are truly the fastest.
It also makes clear that runs on different difficulty settings can both be accepted for their own reasons, which is a good thing as well.
I do disagree about disregarding votes that rely only on difficulty. If people don't find easy runs entertaining just because they are on easy, so be it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
hmm ok, I will do some experimenting and see if I can get that then.
So far going slower there is the only way I could change the pattern. Nothing I did after that point seemed to have any effect whatsoever. But 20 is one of the values I at least pretty commonly see, so getting it seems like it should be possible.
EDIT:
http://tasvideos.org/userfiles/info/29037157216232902
Here is a file that correctly gets into the bonus. You can see that I slowed down at 2 places. The first is at the midway barrel and the second is right before the bonus. The first seems to impact the cycle I get on, the second is just waiting a few frame ofr the correct value to show up once I get a good cycle.
I don't know really what's going on, this is just my random testing but I hope it gives you some insights.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Great! Finally some actual movement after so much discussion. Thank you Samsara for taking the time to do that!
It's not in the direction I particularly agree with, but I'm happy that at least something has changed to reflect community discussion, that's always a good start!
This is a pretty clear shift away from the previous standard of preferring hard difficulty to a much more subjective framework, but I think it still needs to answer one important question:
Can an any% run on hardest difficulty be obsoleted by one on easy difficulty if it is faster? Let's assume the run is in the Vault and is unlikely to leave just for simplicity.
Good example: [3042] Genesis Strider by Neofix & Alyosha in 07:22.39 . Would have been several seconds faster on easy, and pretty soundly in the vault.
I think answering this will clear up a lot of questions, at least for me. In particular in the section above difficulty in 'Choose your goals well' it says:
Most games have only one movie, simply going as fast as possible with any means.
Presumably 'any means' includes difficulty setting, does it?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Well I don't know what value I am supposed to be looking for. All I wanted to see is if I could reach the bonus with a different value besides 0x23. I watched the youtube encode of the current run and noticed that the way the barrel moved after you hit the midway point was slightly different then in this WIP. So I just randomly tried slowing down at that point and yup I got a different pattern of values on my way there.
What value are you looking for? Do you know why a kremgling death sound plays once I release the barrel?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^not sure if it helps, but when I release the barrel on frame 6530 it successfully opens the bonus, though I am still a good distance away from it.
When I release the barrel the sound of a kremling being killed plays, not sure if this is expected or perhaps related to the reason it doesn't work on the frame you want it to.
I've also reached the bonus area with different values of 000D4D while hitting the midway barrel at slower speeds, could be related to how it gets scrolled off screen
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Hmmm updated in what way? I'm not sure what the question is (or if it's directed to me)
If you mean by adding in the runs jlun2 found, then no I didn't plan on it. Maybe I will add it as an addendum after the initial list is complete. It would be nice to have those runs improved also, but I certainly have no plans for any of them. I also have no interest in a 'First 1000' or other equivalent.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So even though I found the bug that makes the car break apart and start in the wrong place in BizHawk, I am no closer to being able to reach a time of 5:51.
Stella has the same behavior as BizHawk for the actual race, and there is just nothing new to test at a per frame level that could possibly bring the time down.
Only a reduction of one of the speed pauses could bring down the time, but nothing (at the frame level at least) that I have found can make this happen.
This one is still a mystery. My only thought is something at the snanline or even cycle level, but I don't know what it could be.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
else if (maskedAddr == 0x11) // RESP1
{
// Borrowed from EMU7800. Apparently resetting between 68 and 76 has strange results.
// This fixes some graphic glitches with Frostbite
if (_hsyncCnt < 69)
{
_player1.HPosCnt = 0;
_player1.ResetCnt = 0;
_player1.Reset = true;
}
else if (_hsyncCnt == 69)
{
_player1.ResetCnt = 3;
}
else if (_hsyncCnt == 72)
{
_player1.ResetCnt = 2;
}
else if (_hsyncCnt == 75)
{
_player1.ResetCnt = 1;
}
else
This piece of code is responsible for both the exploding car in Dragster and the fact that Halo 2600 cannot be completed in BizHawk.
When I change the 3-2-1 to zeros, everything works fine. So whatever the 7800 is doing with the TIA seems to be specific to the 7800 and does not extend to the 2600.
I also have found no reason to believe these values are true from looking at any of the 2600 documentation.
So looks like another quick fix and another annoying bug is busted!
EDIT: Update on this, it also fixes Smurfs in that the game can now be beaten. I also looked at the moving houses in River Raid and I think the double sized player bug fix and/or the player register write delay will solve that problem, and likely the graphical glitch in Grand Prix as well.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/28953286712756335I tired to make a youtube upload but it just wasn't working out, sorry.
Alright! Finally we can present WIP 1 of Battletoads one player warpless. This run plays up through the turbo tunnel skip. The skip itself can probbly be improved a bit, but I wanted to make sure to give time for people to comment on everything up to that point before I finalize it, just in case some funny sync stuff happens.
Anyway the main improvements over the current published run are:
-Reduce lag as much as possible in level 1 by using the sword. The boss in this level fires when a time at $0B rolls over from FF to 00. So basically, you can play the level slower using the sword to save on super move lag while still beating the boss at the same time.
-Remove super move lag from killing first 4 chompers in stage 2. I found this trick by accident, somehow it removes the animation of actually hitting the enemy since you hit the wall simultaneously.
- Turbo Tunnel Skip: As demonstrated by feos in the GIF above as well as by real time runners.
A lot of optimization work has already gone into this so far and i am happy with the results the team has achieved so far, I do expect level 4 to take a while and we are simultaneously working on the 2 player warpless as well, so there is lot's of time if anyone has any input, do post it!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I have also found out why your paddle always rises after pressing start in FlapPing (after an otherwise normal startup)
The game actually only does a very short (9 scanline) frame after the end of the previous frame when it determines the button is pressed and it's time to start.
The problem is that BizHawk is detecting this frame exists as a seperate frame, (giving it it's own frame in TASstudio piano role as well giving a blank screen i.e. no video input) but at the same time is carrying over the input from the previous frame into it. This is easily demonstrated in Stella by just doing the same thing and carrying the button press through those 9 scanlines.
I don't know where this matmatch is happening in the code, I'm having a hard time following the C#, but this is the effect anyway.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Not sure about river raid, but Atari's memory has lots and lots of mirrors so that could be it.
Dragster probably has something else going on that I haven't gotten to yet, possibly related to how the paddles act a little differently here in BizHawk then Stella.
But, the reason 'O' in POWER in the game H.E.R.O. isn't properly drawn is probably the same reason the title screen here isn't correctly drawn. In that case writing to the GRP0 register is happening at the same time it's being drawn, when there should be a one cycle delay.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Well, this has been quite a treasure hunt!
After a lot of time staring at code and Atari documents and looking at many frames and scanlines, I think I understand what went wrong here.
All of this comes down to a color clock delay in drawing double sized players. Bizhawk misses this delay and thus double sized objects, such as Pterry and the countdown numbers in Flapping, are drawn one pixel too far to the left compared to real hardware. Those interested can download the neat test ROM from this thread and compare BizHawk and Stella, pretty neat demonstration!
http://atariage.com/forums/topic/239890-respx-nusizx-and-player-positioning/
Anyway, this is not simply a graphical glitch, for the TIA also does hardware level collision detection, and in a literal case of threading the needle, this is where things go wrong.
After I understood the difference between inputs in Stella and Bizhawk, I was able to compare frames and see where things went wrong, and it all comes down to that one pixel shift. Illustrated below is the frames right where the game diverges between Stella and BizHawk:
Stella:
BizHawk:
So in Stella we see that, in an amazing coincidence, the ball moves directly into the birds eye! So the TIA does not count this as a video collision, and the ball carries on for one more frame. But, this isn't the case in BizHawk, that one pixel shift means that the ball and the player collide 1 frame earlier, and everything diverges from there.
In the end, the Stella game goes on to lose, while the BizHawk one goes on to win, all because of 1 pixel of shift due to an obscure hardware level delay.
there is still more to research and AtariHawk is doing several other things differently from Stella, but for this game this is the deciding factor.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright! Turns out the number positioning bug is actually a pretty simple bug and was relatively easy to track down.
The problem is that there is an extra color clock needed to position double and quad size players. Pterry and the countdown numbers are double sized, and BizHawk isn't giving them that one pixel shift to the right.
See this thread for discussion and even test ROM results that show this:
http://atariage.com/forums/topic/239890-respx-nusizx-and-player-positioning/
Looks like a simple fix, hopefully this also fixes the car positioning bug in Dragster.
EDIT: I should clarify that it's not their position that changes, it just takes one extra clock to start drawing them. BizHawk looks like it already has the one pixel delay built in for normal sized players, it just needs one more for double/triple sized ones.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Ok first off let's start with the title screen drawing bug:
So I stared at BizHawk's code for a long time trying to find the reason that the 'P' in 'Ping' is not being outlined properly, but in the end, it just seems like it's doing everything properly. This is strange, as other emulator's draw the screen as intended with no problems. So I looked at the game code:
F19D 85 STA $02
F19F BD LDA $FE9E,X *
F1A2 85 STA $0D
F1A4 BD LDA $FEC1,X *
F1A7 85 STA $0E
F1A9 BD LDA $FEE4,X *
F1AC 85 STA $0F
F1AE EA NOP
F1AF EA NOP
F1B0 EA NOP
F1B1 BD LDA $FF07,X *
F1B4 85 STA $0D
F1B6 BD LDA $FF2A,X *
F1B9 85 STA $0E
F1BB BD LDA $FF4D,X *
F1BE 85 STA $0F
The first instruction, STA $02 calls a WSYNC which halts the CPU until a scanline is finished drawing. So the next LDA instruction happens only once horizontal blanking starts. This loop loads one line of the title screen. (The addresses $0D-F are the playfield registers that tell the TIA what to draw.)
The above code (minus the WSYNC) takes 48 cycles to execute. There are 3 color clocks (i.e. pixels) per cycle, which means we have 144 color clocks worth of code there. Horiztontal blanking takes 68 of those clocks, meaning we end at pixel 76 on the screen. The point here is that F1BE has stored a new value to the playfield register before the TIA has had time to draw the first half (80 pxels) of the screen. So the expected behavior is that the last block of 4 pixels will be drawn with the new values (the second half of the screen.) And this is what we see here, As that vertical bar is clearly a copy of the one on the right edge of the title.
So I can only conclude that BizHawk is correct, and this is what should actually be displayed. It's not even hard to test, the next instruction after STA $0F is DEY, and if you just swap the order of these instructions, you give the TIA 6 extra clocks and it gets safely past the half way mark.
Stella seems to be cheating a bit here, as in Debug mode you can see that the TIA has drawn past the half way mark despite the hsync counter and the cycle counter both agreeing that they haven't made it that far. I can't explain this behavior.
This is all very strange, but if anyone has any reason to believe that Stella is doing things correctly, or has pictures of this game being played on a real console to prove things one way or another, please let me know. I will also post asking this on AtariAge (once they let me post.) I also tried e-mailing Kirk Israel, but the address (flapping@alienbill.com) returns a 'no such user' error.
well a helpful poster at AtariAge gave a helpful answer!
Nukey Shay wrote:
Stella is correct. The midline PF2 store needs to happen @ cycle 48 or above (up to cycle 60 IIRC) so the left portion is not affected. The original code hits exactly at cycle 48.
So it looks like a quick patch to BizHawk to prevent midscanline updates to the playfield registers before this point is all that is needed.
It pays to ask the experts!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So I am making this thread as sorting things out in FlapPing is proving far more difficult then I thought. So I'll use this to sort out my thoughts/findings and if anyone with any sort of knowledge or can offer any insights please do so.
I will be using this opening post as a Tracker for things I find.
FIXED!
Midscanline playfield register updates are not immediately latched by TIA. This is why FlapPing intro screen doesn't draw correctly.
Player graphics register updates are also not immediately latched by TIA. Similar to above, this is why the 'O' in 'POWER' in H.E.R.O. isn't drawn correctly.
Double and Triple sized players take an extra color clock to draw. This is why FlapPing doesn't sync and the countdown numbers are slightly misaligned. Since this also effects collisions it is a pretty serious bug.
Special instructions that modify player resets that were borrowed from 7800 code are not necessary for the 2600. This is what casues Halo 2600 to be unwinnable and the car in Dragster to break into pieces.
Writes to timer should cause immediate decrements
RESPs in HBlank should set players at 3 pixels in not 5.
writes to ENAM registers have a one pixel delay in registering
check PAL timing. Lag frames are added when there is an off-nominal number of scanlines per frame, this is tied closely to frame definition but not an independent problem.
sound emulation.
TO DO
Implement HBLank cancelling (but need something to test it on)
Frame definition and input mismatch. This is not technically a bug, rather an architecture choice, but nonetheles produces some trouble in edge cases, such as the paddle always rising in FlapPing
investigate 6532 start up state. Is it uninitialized?
investigate HMove interaction with RESP commands. It looks like there is some trouble with RESP and Hmove happening on the same clock
BONUS
Cosmic Ark stars. Probably some analog or very low level timing effects, but is not currently understood. This seems to be tied to TIA revision. Unlikely to be resolved without circuit analysis of each revision.
second look at delays and timings. Many timing delays give correct results but it's not clear why they would be true from a low level. Partially resolved with revised HMOVE code, but questions remain particularly in RESB and PF.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Good to see you still making progress on this Tompa!
Keep it up!
You surely don't need my help, but I still want to work on this and help it get to completion, so if you want me to look at anything besides Croctopus Chase just let me know.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
BrunoVisnadi wrote:
I'm also planning a The Combatribes TAS. I'll probably take a while to finish these movies because I'm focusing on other projects right now, but I'll finish all 3 still this year (hopefully).
wow that would be amazing! Good luck!
Yeah as Spikestuff says this TAS isn't actually especially difficult, it's just too boring (in my opinion) so I never managed the motivation to do it. I hope your attempt goes better then mine!
Also I noticed you say 'snes' combatribes. This run has some dubious history (I guess form being self published) so you might want to just go to arcade as that is the preferred version it seems, but snes should be fine if obsoletion is the only goal.
BizHawk:
So in Stella we see that, in an amazing coincidence, the ball moves directly into the birds eye! So the TIA does not count this as a video collision, and the ball carries on for one more frame. But, this isn't the case in BizHawk, that one pixel shift means that the ball and the player collide 1 frame earlier, and everything diverges from there.
In the end, the Stella game goes on to lose, while the BizHawk one goes on to win, all because of 1 pixel of shift due to an obscure hardware level delay.
there is still more to research and AtariHawk is doing several other things differently from Stella, but for this game this is the deciding factor.
So I stared at BizHawk's code for a long time trying to find the reason that the 'P' in 'Ping' is not being outlined properly, but in the end, it just seems like it's doing everything properly. This is strange, as other emulator's draw the screen as intended with no problems. So I looked at the game code:
F19D 85 STA $02
F19F BD LDA $FE9E,X *
F1A2 85 STA $0D
F1A4 BD LDA $FEC1,X *
F1A7 85 STA $0E
F1A9 BD LDA $FEE4,X *
F1AC 85 STA $0F
F1AE EA NOP
F1AF EA NOP
F1B0 EA NOP
F1B1 BD LDA $FF07,X *
F1B4 85 STA $0D
F1B6 BD LDA $FF2A,X *
F1B9 85 STA $0E
F1BB BD LDA $FF4D,X *
F1BE 85 STA $0F
The first instruction, STA $02 calls a WSYNC which halts the CPU until a scanline is finished drawing. So the next LDA instruction happens only once horizontal blanking starts. This loop loads one line of the title screen. (The addresses $0D-F are the playfield registers that tell the TIA what to draw.)
The above code (minus the WSYNC) takes 48 cycles to execute. There are 3 color clocks (i.e. pixels) per cycle, which means we have 144 color clocks worth of code there. Horiztontal blanking takes 68 of those clocks, meaning we end at pixel 76 on the screen. The point here is that F1BE has stored a new value to the playfield register before the TIA has had time to draw the first half (80 pxels) of the screen. So the expected behavior is that the last block of 4 pixels will be drawn with the new values (the second half of the screen.) And this is what we see here, As that vertical bar is clearly a copy of the one on the right edge of the title.
So I can only conclude that BizHawk is correct, and this is what should actually be displayed. It's not even hard to test, the next instruction after STA $0F is DEY, and if you just swap the order of these instructions, you give the TIA 6 extra clocks and it gets safely past the half way mark.
Stella seems to be cheating a bit here, as in Debug mode you can see that the TIA has drawn past the half way mark despite the hsync counter and the cycle counter both agreeing that they haven't made it that far. I can't explain this behavior.
This is all very strange, but if anyone has any reason to believe that Stella is doing things correctly, or has pictures of this game being played on a real console to prove things one way or another, please let me know. I will also post asking this on AtariAge (once they let me post.) I also tried e-mailing Kirk Israel, but the address (flapping@alienbill.com) returns a 'no such user' error.
well a helpful poster at AtariAge gave a helpful answer!