Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Well I tried putting a boot rom loader in gambatte, I got it loading but I got a buggy result. I'm not really sure what its doing to get the title messed up like that, but doing the obvious thing of swapping out the first 256 bytes of the rom with the bios obviously is not sufficient. Oh well, I don't think I'll put any more effort into it, maybe once gambatte is replaced someday we'll have native suppport for it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
True wrote:
The issue of version will need to be decided. Because bootup times between versions vary, games using the R register in randomness calculations can result in very different outputs. Other than what could be copied into RAM with different BIOS versions, I'm not aware of any other impact BIOS will have. But these two are already very important.
v1.3 is the most "common" and the first / original retail version. These are arbitrary points for using it as a base. But what if the TAS is for a built-in game in a later BIOS? Should there be exceptions for this case? I would hope it isn't a "fastest BIOS" search... but who knows, maybe some game has an exploit that is more useful with a certain BIOS version?
I've done some testing on console with Alex Kidd in Miracle World on a v1.3 USA unit and found, if I remember, about 16 possible variations of randomness in powerups. None of these variations matched the emulator. I would need to test again to see if I delayed the emulator to match the frame count of the console...I don't have any notes about that written down.
For version I don't think emulation accuracy is at the point where we can reliably tell the difference, and loading times by themselves can always be discounted.
As for built in games, Vecna had the foresight to make it so that you can load BIOSes as you would ordinary ROMs as well, so any of the built in games should be accessible already.
PikachuMan wrote:
The Game Gear and Model 2 Genesis/Mega Drive have a BIOS file in the form of a Trade Mark Security System.
Not all GGs had the TMSS, so for that one at least I think we can spare people the tedium of having to wait through that screen.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Mothrayas wrote:
Do current TAS emulators for GB/GBC even allow starting runs from BIOS? If not, that obviously would need to happen first before we can do anything.
Even if it is, it will be hard to strictly enforce turning on BIOS for Game Boy runs, at least in any short term manner. It's like deprecating an emulator, and such processes typically take a long time (easily several months or years) for all TASers to transition through.
Looks like it's not yet an option in BizHawk.
SMS does have that option though (and is the intent of this thread) What about for that system? No time like the present!
Warepire wrote:
Adding GB(C) BIOS support should be easy, I've done it with an emulator I wrote. I can hold the hand of anyone that wants to add the support to BizHawk. (I don't have the time to configure the environment etc)
I'll probably look into doing this in the near future. It looks pretty easy (just have the BIOS loaded and start from $00 instead of $100.) If I need help I'll be sure to ask.
For SMS, BizHawk is only a couple lines of code away from insisting on a BIOS instead of just giving the option, so that isn't tough.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Spikestuff wrote:
Just like GB/C should. (I'm just saying)
I never noticed that it is not included on runs before 0_0
This does seem like something that should be stricter. There is a rule that says roughly 'use a real BIOS and not a hacked one', and BIOS skipping is basically a hacked BIOS of zero length / time that instantly advances to game execution, maybe it just needs to be enforced.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Fortranm wrote:
Doesn't this rule give Game Gear an edge over SMS when a game is available on both platforms?
I guess you could just discount the BIOS time, it's pretty easy to keep track of. Also there are multiple BIOSes, and I'm not sure if there is any preference or reason to choose a particular one.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
To my knowledge, all Sega Master System consoles contained a BIOS. The most common for USA/EU would be 1.3. Currently we allow publications of runs that don't use the BIOS (it isn't required for the system to work, but does exist on all consoles.)
I think it should be a rule that all SMS runs should use the start up BIOS.
This issue seems to have perpetuated since the early days of SMS/GG emulation since the BIOS isn't needed for games to work, and most GG consoles (which had almost identical components) did not contain any BIOS either. But since I'm not aware of any commercial non-BIOS SMS's, I think it's time to enforce a rule about it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/39872420970425783
Please replace the movie file with this one. It properly uses system BIOS, which is present on all US Master Systems.
Probably this should be a rule for Master System runs, since all Master Systems were sold with a BIOS. (Also while I'm thinking of it I should make BizHawk enforce this somehow.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
True wrote:
Just so it is known, even today's emulators do not emulate SMS well enough. For one thing, the startup state is known to be wildly incorrect. And for BIOS / post boot state, which should be chosen?
Still it will be nice to move from old emulators and finally get some console verifications done with SMS runs.
What would it take to quickly determine if Z80 R register is read by a game, as the easiest indicator of a console verifiable run? Static analysis? Analysis during gameplay?
Good point, the goal here isn't going from bad to perfect, its going from bad to better, and at least in an environment where analysis and improvements can be made, and BizHawk's z80 core is at least pretty strong.
The8bitbeast wrote:
This is really cool, I didn't realise that this was a big priority. It'll be interesting to see if the pause button can be used in any of these. Honestly about half of this list is on my list of possible future TASes so hopefully I can help to deal with this over time for any that are left over.
Well, it's a personal priority to me, not an offical site priority or anything. Still it's good to see other people share the same opinion.
Challenger wrote:
EDIT: I didn't aware about that bootup. I'll redo that Cyborg Hunter run to include this.
I forgot this as well, guess I'll have to include it in Kung Fu Kid, I'll be using BIOS 1.3.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
TASVideos in general has many runs that are obsolete just by virtue of their age. Some movies however are notably bad for their use of emulators that are not even considered acceptable by today's standards. There are a daunting number of these runs, so this thread is dedicated to dealing with a small part of the problem in Dega, a Sega Master System and Game Gear emulator. The total number of remaining runs using Dega is small, and all but 2 are under 20 minutes, so the goal is at least approachable.
If anyone is interested, feel free to post and I'll add you to the list.
_The8bitbeast/EZGames69_ [1019] SMS Sonic the Hedgehog 2 "best ending" by mike89 in 18:44.28
__Challenger__ [1061] SMS Wonder Boy by AngerFist in 43:05.02
_The8bitbeast_ [2152] SMS Zillion "100%" by caitsith2 in 18:30.38
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Challenger wrote:
EDIT: Obsoleting dega movies quest deserves a topic.
I considered making a thread for it, but I wanted to make it part of a larger thread about site currecny and which runs are the worst offenders in terms of being done on very outdated emulators. But, then I thought that such a thread would include basically all the snes9x and mupen movies, as well as VBA and probably others, so it seemed kind of pointless.
But since there seems to be some interest in focusing on Dega specifically, I'll go ahead and make that thread at least so we can keep organized and not duplicate efforts.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
That's ok, I've basically made no progess until now anyway. Hope things finally start improving for you True.
http://tasvideos.org/userfiles/info/39855636856675139
Here is the test run, play it on BizHawk 1.13.0. Dk Jr. will die shortly into the run, that's ok, just capture the inputs until the end.
The Rom is: Donkey Kong Jr. (W) (PRG1) [!].nes
SHA1:5D8CBA2011229DC67CCFF6C99E647238F260E7AF
This run is basically testing power on timing. As far as I can tell, the folllowing 3 outcomes (deaths) are most likely:
Left: BizHawk 1.13.0
Center: BizHawk Master
Right: Mesen 0.9.0
http://i1053.photobucket.com/albums/s468/daviomace/dkjr_zpsddevsf8s.png
I suspect that all 3 deaths might be possible on a NES, but I would really like to know how likely each one is, or if some other result all together happens.
This is testing power on at roughly the CPU cycle level. If all 3 results (or more) are possible, then power on variability is higher then previously thought. If possible running the test a large number of times would be good to get a broad statistical sample.
My hope is that only one or two outcomes actually happen though, which would be welcome.
let's see
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Nach wrote:
The rules should not be game dependent. It is unfair to players because they won't know until after submitting if they happened to trigger especially bad emulator behavior. We're not going to keep track of a whole list of exceptions for games and which areas in them and tricks and what not that are or are not implemented well.
At some point you kind of have to. FCEUX for example is capable of recreating SMB3 ACE just fine, but the arrangement of houses it gives at the start of Paperboy is impossible, making our current run of that game kind of pointless. Can a new run of paperboy be made on FCEUX? It would seem that it can't, even though FCEUX can make even console verifiable runs of other games.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Hi,
I found out that you can KO Apollo at least after the second knockdown. Here is a movie that does it (syncs in most recent version of BizHawk.)
I just used random button presses after the second knockdown, since I noticed there is some variation in the count if you randomly punch before the screen transitions, and by chance it led to a KO.
I imagine you can do this to the other fighters as well (maybe even after the first knockdown?) so this run can be improved significantly.
http://tasvideos.org/userfiles/info/39828386441038365
EDIT: also, GG and SMS runs really should be made using versions of BizHawk after 1.19, since significant accuracy improvements were made at that time. I know we're not real strict about bizhawk versioning, but in this case it does matter.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
After lots of searching and experimenting for the simplest test case that can provide useful data, I finally stumbled upon Donkey Kong Jr.
The FCEUX version of this run is completely wrong due to bad powerup timing, but Mesen and BizHawk differ by only a single instruction on Frame 242, right when play begins.
The difference is right at an NMI where an RNG routine is being performed. Eventually this change leads to the first red alligator going across the platform in BizHawk (where Jr. promptly runs into him) and down the vine in Mesen, (where Jr. passes but dies shortly there after on the third vine.)
This is much much easier to examine then trying to track pies in Streemerz several minutes into the run, so hopefully with some console testing we can actually learn something.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I've made a few more improvements to NESHawk. I cleaned up the code a bit and refactored some execution, so it got a little faster, and the code base is also in a better form for future testing as needed.
Also I noticed a bug in my ppu code, which was apparently impacting test 2 and 6 in test_apu_2. Having fixed that bug NESHawk now passes all 11 of those tests, so that's good.
I continue to look for things that can possibly impact console testing as well, but so far nothing promising has come up.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Also remember that the A2600 core has settings that control the output of the video window in Atari->Settings (NTSC/PAL) Top line /Bottom line. So you can open a game and make the cropping correct before dumping it. Not sure if this is what you want or not.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Just remembered. For encoding we have to crop top and bottom by 16 pixels each. Why are they even there if we need to remove them anyway?
Well, screen size for A2600 games was software controlled. Most games had 192 scanlines, but some had more (Tapper for example had 210.) The defaults are set for the maximum extent I believe.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
natt wrote:
Alyosha wrote:
My opinion though is that at some point we really should be raising the standards of accuracy for NES submissions, especially with Mesen becoming available, otherwise we'll never advance console verification.
Would that mean no more FCEUX?
Yes. If Nestaco improves in accuracy and/or Mesen gets some TAS tools I think it would be time to deprecate FCEUX (and quicknes as well.)
That's just my opinion, but I do think we're getting to that point.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
dwangoAC wrote:
Today I stumbled on Nintaco (http://nintaco.com) which is a new cross-platform open source cycle-accurate NES and FDS emulator and I was really floored with how many features it has. The main interface looks fairly standard:
...
This leads to an obvious question - if it proves itself as a reliable emulator that's in many ways more feature rich than even FCEUX, what's the possibility of allowing the emulator and its movie files to be accepted on the site for submissions?I have to say, before I saw this I wasn't thinking to myself "What the world needs is another NES emulator" but now that I see what it purports to have support for I'm rather intrigued. What are your thoughts? Discuss. :)
Not cycle accurate yet, it fails some of the more difficult tests, but it defniitely has some cool features.
My opinion though is that at some point we really should be raising the standards of accuracy for NES submissions, especially with Mesen becoming available, otherwise we'll never advance console verification.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I've been making some progress on NES audio lately. NESHawk now sounds correct in the APU_mixer tests (which previously sounded very poor) and I implemented correct behaviour to pass a few more of the test_apu_2 tests.
It doesn't really sound any different to me in actual gameplay, but the tests say its much closer to the real hardware, so maybe someone with a good ear might be able to tell the difference.
Currently only test_apu_2 tests 2 and 6 fail, but it's not clear that both of these should pass in the default ppu-cpu alignment. Tepples on NesDev had tested these previously and found that they randomly pass or fail on a real hardware, strongly indicating an alignment problem. Mesen passes both of these tests incidently, so this might be a good opportunity to test for emulation differences.
I've also fixed a number of buggy games recently, although probably no one is actually interested in playing them but hey they work at least.
There is still quite a bit left to do for test ROMs and mapper compatibility, but it's getting there.
Well I tried putting a boot rom loader in gambatte, I got it loading but I got a buggy result. I'm not really sure what its doing to get the title messed up like that, but doing the obvious thing of swapping out the first 256 bytes of the rom with the bios obviously is not sufficient. Oh well, I don't think I'll put any more effort into it, maybe once gambatte is replaced someday we'll have native suppport for it.