Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So I was asked to look at Compumate as the next big bug to sort out. I had some time today so I dug into it. It turns out there were numerous bugs in both the mapper and core that needed to be sorted out. But, by comparing tracelogs between Stella and BizHawk I was able to sort everything out and get it running pretty quickly.
(the program alternates drawing lines between frames, so it really does look like this if you only look at one frame)
Of course just getting it loaded up is only a small part of the battle, as there is currently no way to send it any meaningful input, but it's a start!
The most important things that came out of this is realizing that console startup needs to have improved accuracy for the compumate to work. The 'game' does not set the stack pointer appropriately before doing basic operations (as most games typicaly do) instead relying on the 6532 start up sequence. This sequence sends a reset signal to the 6507 which sets the stack pointer to FD.
The current code does not utilize this start up sequence instead just setting everything to default, which for the 6507 is stack pointer 0, which unfortunately overlaps TIA addresses, corrupting the return address of a JSR.
Anyway, I hardcoded in an initial stack pointer of FD simulating post reset behaviour, but I am ultimately not very satisfied with this approach and will probably try to use reset correctly, but right now I don't know how this will work with the current machinery.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Wow this is fascinating stuff! Seems like it might not come to anything but any step in the right direction is a good thing. I hope this is the start of finding a workable solution.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Mothrayas wrote:
If the only thing that would change is the encode, and not any of the run input, there's no reason to update the movie file. Just keep the movie file the way it was originally submitted and published, for authenticity reasons.
Some of the movie files would change due to different timnig. So you'd have to change the movie file to get the updated encode anyway.
I do like jlun2's idea of having an alternate movie file though alongside the original, seems like a good solution to both currency and authenticity. Is there a good way to do this at present ?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
After many hours trying to figure out the 4A50 mapper and what it was trying to do, and then giving up and looking at how Stella did it, I finally worked out the bugs to get it running.
It turns out there was a rather serious bug in AtariHawk itself where PeekMemory actually pointed to ReadMemory in the system. This caused chaos when I tried to trace log out what was going, as the tracelogger peeks changed banks too when it shouldn't have. Once that got fixed it was only a matter of tracking down where banks weren't being changed properly.
The ultimate problem was just an incorrectly placed closing bracket. :(
Anyway this is still displaying things a bit Different then Stella, so I'll have to see why, but the test program looks perfect and anyway this is the only example game I could find.
EDIT: turns out I just needed to add in a vblank delay in the same manner as the numerous other latch delays. The demo game draws the screen in a unique fashion using vblank and needed this delay to match up the drawing edges. With this inclusion the game draws perfectly, so it looks like 4A50 and the associated bugs are now resolved.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Spikestuff wrote:
Also, isn't this topic actually suited for Encoders' corner instead of Sites?
Well my intent was to include updating movie files too, not just encodes. A proper encode of Superman for example would need the Bkm replaced by a bk2 from the next BizHawk release, the run itself being optimal but the emulator used being outdated.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Really impressive glitch research. I like seeing how complex games always seem to get broken down bit by bit over time with ever more impressive and elaborate glitches and discoveries. The overlay and audio commentary really helped, and for me at least the run would have been kind of unwatchable without it since I'm not really familiar with the game, but it was fun being able to follow along.
I agree with calls for Stars and newcomer recommneded (only with the commentary and overlay though)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I do see the bug in the health bars now though, thanks for pointing it out! Looks like a bug in playfield priority setting, should be pretty simple to fix, I'm surprised it didn't come up before.
EDIT: oh yeah, I had trouble with that file too. mF8_sega.cs was included in the merge, and it shows up properly in the the folders, but for some reason isn't recognized by the project. I don't understand why though.
EDIT:
So it turns out this is a more complicated issue then I originally suspected. What the game is doing is setting playfield priority like this:
A5 04 LDA CXM0FB
85 0A STA CTRLPF
So it's loading A from the collision register that keeps track of collisions between missile 0 and playfield/Ball. Then it uses this to set playfield priority at 0A.
The problem is that the playfield priority bit is bit 2 of CTRLPF, but CXM0FB only uses bits 6 and 7. CXM0FB is a TIA read register, and as far as I know the CPU cannot write to the 2 bit of it (and anyway this would be a write to NUSIZ0 at 04 in the TIA write registers.)
This is all very confusing. I don't see how bit 2 of CXM0FB could be 1, as needed to change the playfield priority in this way, unless there is something unmodelled about the physical arrangement of these registers. Still researching an explanation.
EDIT AGAIN
Ok, apparently this is a well known issue of deciding what to do when there are unused pins on the data bus. Stella's solution is to simply use the last value that was there for each unused pin. It also however gives the option to randomly drive the pins.
Current AtariHawk code implicitly sets the pins to 0, since it's just returning a new byte with the appropriate collision bits set.
Apparently the unused ones are 'usually' in there previous state enough to make the Stella approach more desirable.
A bit sloppy to program something this way, but I'll try to account for it, since there are examples on real hardware that correctly display the health bar.
Ok, so on the left we see the old glitch version where the health bars show through the background. On the right the fixed version where they dont.
This is really just a programming error on the part of the game developer. Certainly he meant to write LDA #04, but forgot the '#' and simply wrote LDA 04 in whatever compiler he was using, a simple and common error. #04 is what is needed to change the playfield priority in the usual way. It is a stroke of luck that Loading CXM0FB doesn't change the bus state (04 being the last fetch and that register only effecting bits 6 and 7.) Any other situation would have made the error obvious.
Ultimately I simply added a bus state variable that is tracked along with everyhting else to fix this. Were it not for such an obscure case I surely would never have even thought of it. Maybe future work would be to make the bus state part of the CPU, but maybe not I'm not sure how practical / useful that would be.
Anyway that was an interesting excercise in bug hunting.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^that error with samples should have also been fixed with the last pull request, I even downloaded and compiled from master just to make sure, did you get that error message from a build after the pull request was merged hegyak?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Metal Storm is published so that means 16 to go!
These runs are getting grueling, and the longest ones still remain. Not sure which one I will focus on next, maybe it's time to give double dragon another look (again.)
I guess completely new submissions are one way to deal with it, but I just want to make sure. I don't think the times for games like Superman or Dodge Em will be improved, so will a new submission just be replacing an old run with one that is basically identical?
The score in A2600 superman does not shake, and the first zero is not extra wide as in that updated encode, these are the kinds of bugs I am referring too.
But I wasn't trying to be specific to A2600, just using it as perhaps the most relevent example.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So now that Atari 2600 graphical bugs are resolved, I thought it might be a good time to bring up Publication Updates again, since many (11) of the published A2600 runs contain obvious graphical bugs that are now fixed. Probably the worst case, mainly since it had the most going on in it, is Frogger, which has probably the worst encode I'm aware of on the site (not by any fault of feos, just the nature of emulation at the time.)
Here is a poor quality temp that is still better then the shaky current one:
Link to video
In updating the encode it would of course be necessary to update the movie file (in this case just converting to Bk2, but in others maybe more would be needed.) So maybe there can be a way to formalize this process?
There are other runs for other platforms that could use updates, but A2600 is probably the most warranted due to obvious defects, so I thought this would be a good place to start. I realize it's low priority, but I still think it would be good have a system in place. (And I think it's already understood that credit would remain with the original author, so I don't really consider that an issue.)
Any thoughts?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ sorry for the spam, I'll make sure the next one is more complete before posting it so I'm not constantly adding things. Now that the TIA is sorted out things should change much more slowly.
So it seems the simplest solution for Sega games that use F8 mapper but start in a different bank is just to list them out and make a mapper specifically for them that points the correct bank.
Congo Bongo started in the wrong bank before:
But with the latest fixes it now is correctly picked up and starts and runs just fine:
With the implementation of this change, I am not aware of any more graphical glitches in AtariHawk, hurray! (I'm not counting Cosmic Ark stars since that behaviour is still not understood.) The TIA still isn't perfect, but I don't have any tests I can perform that don't work, so maybe I'll have to scrounge around for some test roms to make some of the really obscure accuracy adjustments.
But I think next I'll work on that 45A0 mapper and maybe see if I can do something about the sound emulation.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
WhiteHat94 wrote:
I was testing out 4-2 on console and I couldn't get the warp. I can get really close but can't quite get it.
It should work exactly the same as in Normal mode but I can't get it. It might just be that there isn't a frame where you can get hit and grab the armor at the same time because the enemy's angle and speed are different than in Normal. If the enemy dies and disappears that just means you are picking up the armor too soon.
I've tried every possible approach to it that I can think of without success. You may be right that the angles/speed simply don't work out. It would be nice if it was possible but can't win them all.
I also tried the 1-2 warp as a continuation from normal mode without entering a password, but was also unsuccessful.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Samsara wrote:
Will do. Are you testing to see if the other warps work or is this the final version?
I've re-tested 4-2 in Cheez's old normal mode run and the warp works as expected there, so the reason is certainly that the enemy dies in expert but remains alive in normal, pretty unfortunate.
Same thing seems to apply in 1-2, the bullet dies after hitting you so there is no conflict.
I think it's done now.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
WhiteHat94 wrote:
Is there no way to get the wrong warp in 4-2? Looks like it should be close to the same as in the normal route but I haven't had a chance to try it out myself. Check out around 4:30 in the video for what I do in the normal route
https://www.youtube.com/watch?v=xgqiEp82tF4
I tried repeatedly to get it but never managed. But maybe I am missing something. I also tried in 1-2 and 6-2 without success.
EDIT: It looks like the crab like enemies die in one hit on hard mode from colliding with you while on normal mode in your video they remain alive. This seems to be the curcial difference. I'm not sure why the spike trick that worked for 2-2 warp doesn't work for 6-2 though.
EDIT2: Oh! It turns out it didn't work in 6-2 because I got the armor upgrade in 4-2. Improvement incoming!
http://tasvideos.org/userfiles/info/30990672414448074
please replace the movie file with this one, 6-2 warp implemented.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Alyosha, why won't you become an actual bizhawk committer?
Well I'm not really an IRC person, but I'm happy fixing bugs on the side, it's fun :)
Also it's a nice break from TASing.
CoolKirby wrote:
Unfortunately, I'm still getting the strange clicking/popping sound. It might just be a garbage noise. Here's a sample of it.
And you're right about NESHawk, it doesn't produce any sound when paused, just like it should.
Looking forward to seeing those TIA fixes when you have them done! It's been kind of exciting following these thread and seeing what progress you're making.
Oops! You are right I uploaded the wrong file, NOW it should be fixed.
Also, I finally got Tapper looking correct !
Here is Stella for comparison, note the slight graphical glitch at the end of each bar. This is the only graphical bug I've seen in Stella.
And now here is updated BizHawk, having come a long way from not running at all, to missing some mugs, to finally looking correct:
Tapper , Kool Aid Man, and Cosmic Ark are 3 of the harder games to emulate correctly, each one pushes the hardware and uses TIA quirks in it's own way so I'm pretty happy to have gotten all 3 working correctly (and with color clock correct code too, not just hacks.)
But there is still more to do (try loading up Congo Bongo) so the testing continues!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm not sure why a sound would play when the emualtor is paused, but anyway I implemented a check in AtariHawk to only even attempt to play a sound if there are non-zero samples available. Now there is no more clicking sound.
So try downloading again and make sure everything is fixed.
Quicknes does seem to have a similar problem but NesHawk seemed to work ok.
I've also been working more on TIA stuff and slowly getting it into a state where the last few bugs can be fixed. It might even be a small step up over Stella in some areas once it's done, since Stella has a graphical bug in Taper while BizHawk doesn't.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
var samples31khz = new short[_audioClocks]; // mono
it looks like _audioClocks is either 0 or ill defined when BizHawk tries to save a state (any time the game isn't just normally running, pausing for example.)
It looks like some of the commits since 1.11.6 have changed how inconsistancies in states are dealt with in BizHawk. Somehow, this code worked before the changes (I don't know how it could have muddled through this, but it did) but now it gets ill defined and throws an error.
Anyway, I patched it up for now, sound emulation is still rough so I'll change it again at some point in the future.
Please download and build from here and let me know if it works:
https://github.com/alyosha-tas/BizHawk
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Samsara is quite right that WIP was only synced up to that part in 4-2, sorry I should have clarified that.
Things Are going smoothly, mainly because aside from lag reduction there really isn't a lot to do in the run. I should be able to finish up in the next day or 2.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So in researching passwords a bit more it seems like you can get a pure 'start game on expert mode' password that is not just a continuation of a normal mode game.
Basically I took Cheez's normal mode run and hex-edited the score and power up state to 0 at the end of the game so that the pasword generator will give me a password for expert mode with 0 score and no powerup, exactly the same as normal mode start up.
The result is:
F,P,P,M,K,2,P,7,8,6
I feel it would be more correct to start the game in this way then with the flame powerup, so I think I will go with it even though it will be a bit slower in level 1.
http://tasvideos.org/userfiles/info/30857121059171598
Here is a WIP that implements everything so far. It still needs some work so probably 1-2 more seconds can be saved. It includes 2-2 and 4-1 skip as well as the new start from 0 password. This adds about 8 seconds to the run, but seems worth it to me.
Of course just getting it loaded up is only a small part of the battle, as there is currently no way to send it any meaningful input, but it's a start!
The most important things that came out of this is realizing that console startup needs to have improved accuracy for the compumate to work. The 'game' does not set the stack pointer appropriately before doing basic operations (as most games typicaly do) instead relying on the 6532 start up sequence. This sequence sends a reset signal to the 6507 which sets the stack pointer to FD.
The current code does not utilize this start up sequence instead just setting everything to default, which for the 6507 is stack pointer 0, which unfortunately overlaps TIA addresses, corrupting the return address of a JSR.
Anyway, I hardcoded in an initial stack pointer of FD simulating post reset behaviour, but I am ultimately not very satisfied with this approach and will probably try to use reset correctly, but right now I don't know how this will work with the current machinery.
It turns out there was a rather serious bug in AtariHawk itself where PeekMemory actually pointed to ReadMemory in the system. This caused chaos when I tried to trace log out what was going, as the tracelogger peeks changed banks too when it shouldn't have. Once that got fixed it was only a matter of tracking down where banks weren't being changed properly.
The ultimate problem was just an incorrectly placed closing bracket. :(
Anyway this is still displaying things a bit Different then Stella, so I'll have to see why, but the test program looks perfect and anyway this is the only example game I could find.
EDIT: turns out I just needed to add in a vblank delay in the same manner as the numerous other latch delays. The demo game draws the screen in a unique fashion using vblank and needed this delay to match up the drawing edges. With this inclusion the game draws perfectly, so it looks like 4A50 and the associated bugs are now resolved.
Ok, so on the left we see the old glitch version where the health bars show through the background. On the right the fixed version where they dont.
This is really just a programming error on the part of the game developer. Certainly he meant to write LDA #04, but forgot the '#' and simply wrote LDA 04 in whatever compiler he was using, a simple and common error. #04 is what is needed to change the playfield priority in the usual way. It is a stroke of luck that Loading CXM0FB doesn't change the bus state (04 being the last fetch and that register only effecting bits 6 and 7.) Any other situation would have made the error obvious.
Ultimately I simply added a bus state variable that is tracked along with everyhting else to fix this. Were it not for such an obscure case I surely would never have even thought of it. Maybe future work would be to make the bus state part of the CPU, but maybe not I'm not sure how practical / useful that would be.
Anyway that was an interesting excercise in bug hunting.
But with the latest fixes it now is correctly picked up and starts and runs just fine:
With the implementation of this change, I am not aware of any more graphical glitches in AtariHawk, hurray! (I'm not counting Cosmic Ark stars since that behaviour is still not understood.) The TIA still isn't perfect, but I don't have any tests I can perform that don't work, so maybe I'll have to scrounge around for some test roms to make some of the really obscure accuracy adjustments.
But I think next I'll work on that 45A0 mapper and maybe see if I can do something about the sound emulation.
And now here is updated BizHawk, having come a long way from not running at all, to missing some mugs, to finally looking correct:
Tapper , Kool Aid Man, and Cosmic Ark are 3 of the harder games to emulate correctly, each one pushes the hardware and uses TIA quirks in it's own way so I'm pretty happy to have gotten all 3 working correctly (and with color clock correct code too, not just hacks.)
But there is still more to do (try loading up Congo Bongo) so the testing continues!