Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
^ Thanks for the offer, I have done so.
I have also updated the opening post with current state of AtariHawk. There are still several things to look into, but things have really improved. There are only a couple of things left before I would say AtariHawk reaches parity with Stella, clearing with Late HBlank flag with a well timed HMove, and sound emulation. The first one should be pretty simple to work out, but I currently can't follow the code well enough to work out the sound emulation errors or how to fix them.
After that there are still some open questions with understanding delays at a low level and Cosmic Ark star pattern. I have some hope for the delays, but the stars remain mysterious.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Wow it really worked! That's great! Big thanks to DwangoAC for doing this test. This was the single way I had to test it and finally a definite result, awesome!
Well now I will work with Adelikat to get everything merged into BizHawk proper (which is really just updating the TIA file.) With the bug fixes Atari 2600 should have a much higher compatibility.
However more testing is needed, and while everything seems to work, I suspect there are some things that are subtly wrong, and might need a second look. But I won't know until a wider audience plays different games and bugs turn up.
For now though hurray it works!
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
It's been a while since I could touch this list, but now, largely thanks to feos, I can cross off 1 player Battletoads! A lot of challenging runs lay ahead, but their number is slowly decreasing, 17 to go!
But, losing all my working files has sapped my motivation a bit, so I think I will take a short break from this and work on something simpler.
Also if anyone wants to work on one of the remaining runs I'm happy to team up!
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
DwangoAC has kindly agreed to do console testing of FlapPing for me to check the ENAM delay case sometime soon. This is the last thing I need checked before getting the code committed to BizHawk.
This is a pretty obscure test and I couldn't find any other examples where it might come into play, so I thought I might make some example videos just to make sure the results are exactly what is needed.
The test case is an easily reproducible run that I have achieved real time on both BizHawk and Stella with little effort (usually under a minute.) This is convenient since it means console testing doesn't need a complicated playback device, just a few tries by hand until it works.
For the purposes of TAS, the inputs are pressing 'select' on frame 12 and then 'reset' on frame 24 after power on. Also the difficulty is on hard mode.
This first video is without ENAM delay, it is what will happen in the current version of BizHawk.
Link to video
This second video is what will happen with ENAM delay. This movie matches what you get from Stella.
Link to video
So this simple test produces some pretty easy to verify results. Current BizHawk loses, and the version with ENAM delay wins. As an aside this is the fastest win case I have found so far in Stella. Now all that is needed is to see what happens on console.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
This morning my laptop got corrupted somehow and I lost all my files , so looks like I'm out of action for a while. : (
Well at least 1 player warp less got done !
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Here's something interesting. The last level is currently faster 1 player then 2 player by 90 frames, so if we expand the category a little from '2 player warps' to just 'warps' it is faster to just leave player 2 dead after killing them off in zinger winger and just completing the game with player 1.
This would actually be 5 frames faster then my current 1 player only run. This category is really close!
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
http://tasvideos.org/userfiles/info/30188088951958534
This contains all the improvements I know so far, barring something new being found I don't think much will change.
For the 2 player run I can't find any new improvements so I might end up submitting this soon. I think a handful of frames can be saved in level 3 with feos' U+R trick, but that still leaves over a second to save somewhere and I can't find any.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
http://tasvideos.org/userfiles/info/30176761817516794
Please replace the movie file with this one.
I found a 2 frame improvement at the end of the Robo Manus fight while testing 1 player warps, so might as well add it here.
1 player warps is now 85 frames ahead of 2 player warps (even after improving the 20 frame entertainment trade off in Robo Manus in that run), not sure what will happen with branches if 2 player cannot be that much improved, but for now still testing.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
So I did some quick testing using the current warps run and the comparable portions of the new warpless 1 player run.
Basically from the intruder excluder to game end, 1 player is 750 frames faster.
Level 3 in 650 frames faster in 2 player then in 1 player.
Level 4 can be done faster 1 player then 2 player do to intense lag. I don't know by how much but my very brief testing was already 10 frames ahead. So maybe up to 1 second faster in an optimized case.
So, if level 1 and the snake level can be done fast enough, 1 player warps might be faster then 2 player warps. But I'm not sure if the snake warp can be hit fast enough. It will be very close though.
EDIT: currently 50 frames away from being faster
EDIT2: currently faster by 60 frames. This gets up intruder excluder but doesn't sync to the end (although it should be identical to warpless after this point.)
http://tasvideos.org/userfiles/info/30168575436228154
@feos: are any of the speed improvements you found in 1 player warpless applicable to 2 player warps? I don't think this can be improved too much more, so if you can save 1 second 2 player will still be faster.
EDIT3:
http://tasvideos.org/userfiles/info/30171946756063596http://tasvideos.org/userfiles/info/30172987039226829
Here is a slightly more optimized file that beats the game. So right now 1 player stands as faster then the published 2 player warps run by ~70 frames.
EDIT4: So the entertainment tradeoff feos originally put in his Robo Manus fight in the published run costs about 20 frames. I am at 39931 frames for 2 players right now and 39877 39861 for 1 player. Very close!
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Thanks for posting the WIP Odongdong.
Having something to look at is always way better then starting from scratch, so this is a big head start. It will probably be the next thing I work on after Atari 2600 and Battletoads is sorted out, whenever that may be.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
mklip2001 wrote:
This is great. Finally, this run has an up-to-date Turbo Tunnel skip in level 3. There are some amazing changes elsewhere too.
Of course, this raises the question of how many runs Battletoads should have. The any% and the 2-player warpless, I think, are pretty agreed-upon categories. Is this run valuable enough to be published separately from those other two? (This may just be a case of a legacy category that was more historically interesting, like the Princess SMB2 run.)
One strategy question: why don't you recover your walker stick to fight Big Blag in stage 5? Each time you headbutt him, he pauses the game with his landing. If you took one of his small jumps as time to get the stick back, you can juggle him with the stick and keep him from landing.
This is also something I thought about when working on this. My feeling is that if there is going to be a one player run of this game it should be this one, but as to whether or not 2 player warpless is preferred and obsoletes this one, I guess it depends on how interesting people find it.
2 player warpless also provides a level 5 skip, so the amount of overlap with 2 player warps will be pretty big.
There might not really be enough unique content to have 1 player warpless, 2 player warpless, and 2 player warps. My personal opinion is that if one of them has to go it should be 2 player warpless, but that's just me.
I did some testing with the stick, but yeah Blarg just bounces too high. I also tried to give him a kick with the walker head on the ground, but it seems he is not susceptible to that.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
http://tasvideos.org/userfiles/info/30145763783146691
So I've had this for a while without looking at it, with the 1-p run on the workbench I figured I'd just post it here for anyone interested.
This basically just expands the warps run into a warpless one. Levels 1 and 2 contain decent optimization. Level 3 is just the warps run version. level 4 uses some of what was learned in the warpless run but isn't optimized. Level 5 also uses the level skip similar to level 3.
This only syncs up to the robot boss, but from there on it will identical to the warps run anyway. I made no attempt at entertainment since it's just a rough draft.
Currently I'm not sure when I might come back to this, but here it is for anyone to use.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
With the implementation of PRG write delays, many graphical bugs are now fixed (such as the 'O' in power in H.E.R.O. above. )
This fix also correctly implements PRG delays due to HMOVE, which is what the hacked in original 3-2-1 code was trying to do.
This also fixes the rather annoying house moving bug in River Raid.
At this point pretty much all graphical bugs should be fixed.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
I also have to say that this seems like a pretty muddled case. The run's complexity as an optimization problem is definitely higher then other runs in the vault, so it seems rejection for triviality doesn't quite fit. Also this run is at least as complicated as the recent Fighters Destiny runs, which happen to follow the guideline of "in general, these would be games where the user competes against an AI opponent, and/or have a fixed clock time" to the letter. Fighting games get an exception from 'sport' category for some reason though despite being a perfect example according to that definition.
As Warp mentions, this game has all the goals and mechanics of a normal game, and none of a sport (there isn't even an opponent.) So despite the fact that 'golf is a sport', this game is not played as a sporting event.
Maybe this rule needs some attention sooner rather then later.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
I did make a fork of Bizhawk (linked in opening post) that has all my current changes, but that is as far as I know how to do. I don't really understand the pull request thing, but sure just tell me what to click on and everything can be integrated.
However I am still waiting for confirmation on the most critical fix which is the ENAM delay in the current FlapPing submission. Aside from just following Stella I have no concrete proof if it is true or not. I asked on AtariAge but have no replies yet. So unless I get something certain there or a console verification, integration into the official BizHawk might have to wait a bit, I wouldn't want a run rejected on uncertain grounds.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
So I have finally fixed the original bug that got me interested in all of this. This implements the same play field delays that Stella uses. While I don't understand why they would be true at a low level, they none the less have high compatibility and I haven't seen any deficiencies in my testing.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
jlun2 wrote:
Wow congrats!
For Stella, I'm not sure why. Given how it was mentioned that it uses a high level approach rather than a lower one, it (may be) the case that the devs simply made a random starfield effect and assumed it looked "close enough". Could be wrong however.
Doing a bit of research it seems that the pattern in Stella was hard coded to match observed behavior. I have no idea why this behavior occurs at this time, but this commercial of the game pretty clearly shows the pattern in Stella as opposed to the uniform one produced by the understood effect:
Link to video
This is what mirco500 was trying to figure out with his work I believe (the basic effect of not resetting movement latches is straight forward and pretty well understood)
Anyway I made some more clean up and commits to my fork. So if anyone wants to compile and play I put the link in the opening post.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Success!
After a bit of sleuthing a discovered what was missing to make the star pattern work correctly.
From the same hardware notes page as above we have:
I mentioned above that HMOVE sends extra clock pulses down
the same clock lines that are usually used during the visible
part of the scanline. In theory this means that performing a
HMOVE during the visible part of the scanline should have no
effect. However, looking at how the various clock signals
interact, I suspect it is possible. I did some preliminary
experiments (on a 2600 Jr) at some point, and I seem to
remember having some success.
So the key is that HMove is only effective during HBlank period. The existing code makes it happen during the entire scanline. Normally this is inconsequential since HMove ends correctly, but during this glitchy case it needs to be taken into account. Doing so gives the correct pattern, as can be seen in the video below.
Link to video
This still isn't quite the end of the story though. It seems there are some analog effects happening with the timer pulses using the same line, I don't think those have been effectively documented anywhere so this might be the as far as things go for a while. On the up side this is a proper implementation and should be correct. It still doesn't look like Stella, but at this point I'm not sure exactly why Stella uses the exact pattern it does.
I have updated my code in the github to reflect all current changes.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Well I have a possible solution that correctly displays cosmic Ark stars.
The problem was that the TIA code was looping the _Hmove counter instead of just resetting it after it reached 15. The effect of this is that the latch that normally would never would be cleared would just be cleared on the next pass of the counter. This prevented the stars from forming.
This 'fix' breaks DK JR though (well, in a different way) so I'll be consulting with micro500 to work out what's happening. I'm pretty sure the overall idea is correct though.
Here is a brief video though:
Link to video
Perhaps we are close to getting the star effect in a real non-hackish way!
EDIT: found the bug the messes up DK JR
if (_hmove.HMoveDelayCnt < 6)
{
_hmove.HMoveDelayCnt++;
}
if (_hmove.HMoveDelayCnt == 6)
{
_hmove.HMoveDelayCnt++;
_hmove.HMoveCnt = 0;
_hmove.DecCntEnabled = true;
Those 6's should be 5's. This 1 extra clock delay is what's breaking DK JR.
The stars still don't display exactly as expected so more research is needed there, but things seem to be shaping up.
EDIT2: I forked all my changes into github here: https://github.com/alyosha-tas/BizHawk
This contains the fixes for pterry, the ENAM fix, the starfield, DK jr fix, 3-2-1 fix.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
So I happened across an emulator bug that might hopefully also shed light on Cosmic Arc stars and properly emulating quirky HMove instructions.
I was browsing other Atari 2600 games that were known to behave badly in BizHawk looking at the list here. I looked at Donkey Kong Jr since it had some weird gameplay bug listed as the error.
The picture below is 4 consecutive movement frames. On frame 3 you can see quite clearly that DK gets pushed to the left rather far before snapping back to the right the next time.
What's happening here is (I think) related to the warning not to change HMove registers until 24 CPU cycles after HMove is executed, here is the relevant code:
So what we have is an HMove immediately following a WSYNC, this is the expected behavior, but then we have only 22 cycles in between that and the following HMP0 instead of the expected 24.
Quoting hardware notes we have:
In theory then the side effects of modifying the HMxx registers
during HMOVE should be quite straight-forward. If the internal
counter has not yet reached the value in HMxx, a new value greater
than this (in 0-15 terms) will work normally. Conversely, if
the counter has already reached the value in HMxx, new values
will have no effect because the latch will have been cleared.
Much more interesting is this: if the counter has not yet
reached the value in HMxx (or has reached it but not yet
commited the comparison) and a value with at least one bit
in common with all remaining internal counter states is
written (zeros or ones), the stopping condition will never be
reached and the object will be moved a full 15 pixels left.
In addition to this, the HMOVE will complete without clearing
the "more movement required" latch, and so will continue to send
an additional clock signal every 4 CLK (during visible and
non-visible parts of the scanline) until another HMOVE operation
clears the latch. The HMCLR command does not reset these latches.
This shove to the left only happens here when HMP0 is 7, the same code is obviously running constantly but only this value makes the big shove to the left happen.
Stella seems to cheat in this case and instantly applies the HMOVE and ignores how long actual execution should take.
This shove to the left doesn't happen on console (and makes the game unwinnable in BizHawk) so sorting this out seems like a good step in understanding this HMove stuff.
Either that or it's a simple bug that I just can't see yet.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
CoolKirby wrote:
I can confirm that the double sized player bug did not affect the sync of the published E.T.: The Extra-Terrestrial run. (The run does not sync on BizHawk 1.7.0 or later as it is though.)
I want to say thank you for fixing all those tough bugs - I was thinking of running Halo 2600 several months ago and now it should finally be possible.
Will your fixes be implemented into the next BizHawk?
Not sure, once micro500 or some other knowledgeable person confirms these findings are correct, it's easy to fix a few of the bugs just by changing some constants. The latch delay type bugs are more difficult though will probably take some time to sort everything out. Halo 2600 should work with the easy fixes though.
Yeah any run like E.T. made before the switch to fixed length frames / inputs will be difficult to reconcile with any new runs made. I thought about making some test runs but currently don't have the time.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
While I'm not an expert, I don't think Mari/o is strong enough to do anything serious like that. It's fine for a sandbox model but you won't get anything particularly impressive out of it for complex games like SMW.
If I were to offer a suggestion that would both seem doable and be impressive, I would suggest SNES Star Fox. The existing run is woefully obsolete just by nature of the emulator used, and the gameplay lends itself more to the Mari/o methodology.
However this would require a great deal of research, I guess it depends how much effort you want to put into it.
With the implementation of PRG write delays, many graphical bugs are now fixed (such as the 'O' in power in H.E.R.O. above. )
This fix also correctly implements PRG delays due to HMOVE, which is what the hacked in original 3-2-1 code was trying to do.
This also fixes the rather annoying house moving bug in River Raid.
At this point pretty much all graphical bugs should be fixed.
So I have finally fixed the original bug that got me interested in all of this. This implements the same play field delays that Stella uses. While I don't understand why they would be true at a low level, they none the less have high compatibility and I haven't seen any deficiencies in my testing.
What's happening here is (I think) related to the warning not to change HMove registers until 24 CPU cycles after HMove is executed, here is the relevant code: