Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Personally I like the decision to use the 1.1 version, it seems more like a finished product.
As TASing moves into newer systems I think we'll run into version differences a lot more, even games on disks get downloaded updates now. Seems like a bit of a grey area to me.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Wow, this really is a good looking Rom Hack and a good looking TAS of it as well.
I'm really impressed by everything here, the TAS, Dolphin, and the Hack too, voting yes.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
@feos: I guess I agree with removing them from the table. The tests DO provide some information, it's unfortunate they aren't timed strictly enough to be consistent though. But the behaviour is also tested in dmc_dma_during_read4/dma_4016_read, and in a stricter way, so I guess those other ones are redundant.
@Koh1fds: I'll add that to the list on the OP, but don't expect it to be worked out soon. It won't be easy to work backwards from an IPS patch alone, and there are many other mappers to work on first. If you know any other info about that hack it would certainly be helpful to have.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
^ Oops! Sorry about that, not sure how I missed it but it should be fixed now.
It will probably be a while before I get to look into that FDS stuff, at least it works by the 2 step eject and change side process, thanks for the report though.
Overclocking won't be happening in the near future unless someone else does it, sorry.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
void setchr1r(int r, uint32 A, uint32 V) {
if (!CHRptr[r]) return;
FCEUPPU_LineUpdate();
V &= CHRmask1[r];
if (CHRram[r])
PPUCHRRAM |= (1 <<A>> 10));
else
PPUCHRRAM &= ~(1 <<A>> 10));
VPageR[(A) >> 10] = &CHRptr[r][(V) << 10] - (A);
}
@feos: this is code from FCEUX cart.cpp. Do you know what it does when r=0x10? I have no idea what it is trying to tell me and I need it for a mapper.
The conflicts occur on an edge case of DMC fetches, I believe becuase there is a bus conflict but I'm not sure. The test is just rapid fire doing controller reads around DMCs, I don't think it is specifically timed to hit particular ones.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
Ok so I fixed the background draw check that was causing the stars to display improperly. This was certainly a bug, so I'm glad to have learned something from that troublesome scanline test. I'm surprised it didn't come up before.
I also went ahead and commited the pipelined check on grayscale drawing, as there is no other conceivable way to fix nmi_sync, and it makes sense that the greyscale check would run at the end of the rendering anyway since it's basically a post processing effect. This doesn't effect sync in any way, it's purely a visual effect, so if new information comes to light it can still be tinkered with easily.
The only thing odd is the first and fourth bar of the second test occasionally flickering in that video. It shouldn't be possible for only those 2 to flicker, as the sawtooth pattern of that test should either effect every bar or none, and it definitely shouldn't be itermitant like it is. For now i dont know what to make of it, although I would like to see if it also occurs in Famicom AV (+InviteNES) or powerpack as well. If so then that is surely something strange and unmodelled. @Sergunov would you be able to try out that case as well?
EDIT: I also noticed that the read_joy3/count_errors tests were changed to 'fail.' Having conflicts or errors does not mean a fail in there tests. Actually, having no conflicts at all is a sign of failure. the tet is checking if DMC causes misreads of controller input. It only fails if they are not recognized and reconciled (it would print a different message in this case. The reason older versions of NesHawk had no conflicts is becuase DMC was emulated as instantaneous, which was of course wrong. These tests should still be in the 'pass' category (punes should pass these as well, and FCEUX should fail them.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
Location: US
^Awesome, thank you!
Hmmm, so the stars are only partial afterall. The assumption in NesHawk is that the draw_background check is only done every 8 pixels, so I can definitely fix that.
The flickering of the bars in the last of the 3 tests is present in both NesHawk and PuNes, so that's good to see, it means nothing is grossly wrong.
The flickering in the middle set of bars is more interesting though, I don't think I've ever seen that befroe, going to require some research.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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
(3602)
Joined: 11/30/2014
Posts: 2752
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.
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.