Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Very impressive run, to have improved the previous one by over 1 second is quite the technical achievemnet.
Any thoughts of working on the sequel as well?
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
You can also ask on nesdev directly.
I have now posted there about it, but my last 2 questions got no replies, well let's see.
feos would you be able to get a video of the console output for the scanline/scanline test please? I would really like to see the exact output it produces, might help clarify some things.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
So in continuing to research what is going on with the nmi_sync test, I just can't find anything wrong with any of the current implementation of PPU timing. Given that all the other relevent tests, Vblank, NMI timing pass, and that those tests are accurate down to the PPU clock, there was nothing I could really change to influence anything.
So I scoured the NESDEV stuff looking for any clues, the only thing I found was here in http://wiki.nesdev.com/w/index.php/PPU_rendering
Sprite zero hits act as if the image starts at cycle 2 (which is the same cycle that the shifters shift for the first time), so the sprite zero flag will be raised at this point at the earliest. Actual pixel output is delayed further due to internal render pipelining, and the first pixel is output during cycle 4.
My working theory is that since the rendering pipeline is longer then emulated in BizHawk (in which it is instantaneous) certain checks take place further down the pipeline then we account for. So if I do the $2001 color_render check at the end of the pipeline, the sync test passes exactly as it should.
I added a pipelining function to make this happen, and everything works fine. But I'm currently unsure what stuff to put into the pipeline, so perhaps more testing is needed there.
As for the scnaline function, it's obvious there what is failing. Every fourth frame NMI takes one extra insturction to trigger. So until this test can pass on console, my working assumption is that it is an innacurate test. (However, this seems odd given that it was written by Quietust, who is responsible for much NES work including Visual 2C02.) But the console has the final word.
I haven't commited the pipeline stuff yet, but I'm pretty confident it is correct, feedback would be appreciated though, as it is currently experimental.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
@Koh1fds: The Druid fix is trivial to port, it's changing probably 3 lines of code. I briefly looked through FCEUX's FDS audio code, it's certainly not as mature as BizHawk's, so would probably take some effort to get it there. I'm not involved in FCEUX so can't say when it might be included.
___________________
The following is highly speculative, but I'm about 90% sure I know why both the scanline test and NMI_sync test fail and what is needed to get them to pass.
Currently BizHawk syncs up PPU and CPU by performing 3 PPU cycles and then 1 CPU cycle. Both tests however are off by 1 pixel, which makes me think that writes to PPU registers are visible to the PPU earlier then currently emulated (by 1 PPU clock.) This should be possible in theory, since the 6502 would already be in the phi2 phase of the write cycle by the time the thrid ppu clock starts.
I'm currently thinking about how this might best be emulated/tested. Any ideas are welcome.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
^ interesting. That looks similar to the trouble I had with scanline/scanline. feos are you able to use these test roms on real console? If so, can you test scanline/scanline as well? That one does not have console test results on the accuracy tests page, and I suspect these 2 things are related.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Ok, so I adjusted FDS audio levels so that they wouldn't drown out the NES audio as much (helps Kid Icarus quite a bit.)
I couldn't find anymore errors with the acutal audio code itself. NESDev mentions a low pass filter that we might need to emulate to get a bit more accuracy out of it, but I think mixing between NES and FDS audio signals needs to be captured better first.
Things sound pretty good right now though, so I'm happy enough with the results to move on.
Using 'eject' for metroid did work instead of just immediately pressing 'side B', so that's interesting, I'll have to add that to the list of things to look into.
Anyway thanks for the reports Koh1fds, FDA audio is greatly improved!
Back to mappers!
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
jlun2 wrote:
Basically jumping into a wall gives you just enough of a push to the right to jump into the lever while still going forward. Like the clip, it only works in one direction though.
I can see that in the run, but how does that even work? You move right, but somehow that makes going left faster?
When you jump into a wall, the first thing the game does is move you straight down, not immeditaely eject you. At this point you are slightly further right then would otherwise be possible, just enough so that if you jump to the left you can hit the lever.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
ok progress report on FDS sound.
I fixed up several obvious glitches, mostly following the wiki and rainwarrior's NSFplay code.
This seems to have resolved numerous issues including:
-Zelda 1 sword sounds
-Zelda 2 taking damage sounds
-Kid Icarus reaper sounds.
I was not able to test metroid since I couldn't get it to load. Not sure if a ROM or emulator problem.
@Koh1fds: please test this out and see if you can find any more obvious errors. I think things still probably are not quite right, but should be much much better.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
That's a cool glitch! Hard to believe it wasn't known about until now.
I'm not sure about using it in this particular run though. Isn't it meant to be a glitchless category? The 'goals' of the orignal run said it avoided unintended exits, and this certainly seeems like one.
And if you do use it, why not use left + right and just call it a non-warp glitch run? Seems messy to me.
Still cool though!
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Yeah I didn't work on the sound yet, only the flickering in Druid.
I'll try to work on the sound maybe this weekend or next, when I can sit down and really look into the code.
In the mean time, if you know any other fds specific bugs do post them here, as I haven't looked at the system at all until you posted about it.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Koh1fds wrote:
It's good to see how pretty "important" and popular pirate mappers gets fixes. But how about not important and obscure FDS mapper? I don't have last version of BizHawk, but i think every problem from this list can be applied to it
https://sourceforge.net/p/fceultra/bugs/739/
Hi,
Sure I can work on FDS stuff. I can't promise any kind of timeline, but i can certainly attempt it.
EDIT: @Koh1fds: Ok I think I fixed timer IRQs, which fixed the flickering status bar on Druid. Try downloading and building from master and see if everything is ok. I believe this is correct, and I didn't notice any problems. Its hard to say why FCEUX did it the way it did, but as far as I can tell everything now works fine.
Let me know if you find any other games messed up as a result of this change.
I only changed a couple lines so the changes can easily be put into FCEUX etc to test as well.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Making steady progress on mapper fixes, thanks to FCEUX already running some of these it's pretty easy to compare trace logs and track down errors. Somari, Commandos, and Dragon Quest 7, amongst others, now work.
adelikat has done a bunch of mapper fixes as well, so thanks to him for that.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
So since 1.11.7 is now released, I thought I might revive this topic and suggest some updates to the A2600 runs.
Link to video
Here is an updated encode of Superman, the first zero in the score is no longer double wide and it doesn't shake up and down.
Here is a re-synced movie file to go along with it:
http://tasvideos.org/userfiles/info/33411156811406467
I don't know what/ if there is a process to go through for this, but I do plan to update the glitchy 2600 runs one way or another. For ones that can't be improved like Superman, I guess for now I will just post them here. Or if it is preffered, I can just re-submit them under the orignal authors name, either way seems preferrable to having all those glitchy movies hanging around.
Anyway let me know what you think.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Finally got Double Dragon down!
Only 14 left, I might yet get down to 10 this year afterall!
But now I think I'll take a bit of a break and work on some other things now that 1.11.7 is out. I'll probably work on the other battletoads run and that prince of persia run next.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
That happened to me before too, but I can't remember if/how I resolved it. Do you think that CPU stuff you were working on before will have an effect now feos?
I looked a little deeper into why the previous game end glitch run wasn't working on BizHawk. The final dominoe to falll to get the game end call is a check of $0078. Things seem to match up before this point. I looked at what set this address and found this:
$3FEF is palette data. It is different at this point between FCEUX and BizHawk but I'm not sure why at this point.
But since the current run syncs, I might not look too deeply into it.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
5.54 is what is possible with no slowdowns other then gear changes. Whether or not that is possible would probably need a disassembly of the game.
5.51 is only possible under 2 conditions:
-start the race sooner.
-change gears without slowing down.
As far as I can tell neither of those things can happen.
As I side note, I found some posts indicating that the record holder has other quesitonable records as well, so there is possibility 5.51 is not legitimate (although this is purely hearsay.)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
^ I'll put something together and put it on the opening post. It will be good to track from there.
@feos: so the current game end glitch battletoads run DOES sync on NESHawk (adjusting for power on timing), so maybe if someone is available to test it on console we can give it a try? The previous version didn't work with all the pausing, I think that is where the problems came from, but this one might just work.
http://tasvideos.org/userfiles/info/33374964026078379
Oh I am emulator coder now, that's cool :)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
google translate was almost readable, but not enough for me to grasp it.
Yeah feel free to move this to the battletoads game thread or the NESHawk tests thread, I would also like to see this console verified. I feel like it should be doable.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
feos if you can make a bizhawk movie that executes the game end gltich i can start testing differences between it an fceux to understand what's happening. The currenrly publised run, with some slight changes at the start to account for start up differences, only makes it to the glitch but behaves differently, I don't understand what I'm looking for to make the glitch work.
As for speed ups, yeah I do plan on improvements there, but so far the only thing I've done that even puts a dent in it is manually inlining funcitons in the ppu. I think some savings can be had in the APU, but I need to think about how.
I am curious exactly what pattern it gives.
Making steady progress on mapper fixes, thanks to FCEUX already running some of these it's pretty easy to compare trace logs and track down errors. Somari, Commandos, and Dragon Quest 7, amongst others, now work.
adelikat has done a bunch of mapper fixes as well, so thanks to him for that.