Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
We've ran test roms on Everdrive + Famicom AV today, and while checking some of them in bizhawk, we found out nmi_sync/demo_ntsc doesn't work the same as it's intended to work in the readme. It's interesting, since out of all emulators I tried, only Nintendulator outputs the same as bizhawk, all of the rest are different from each other and from the console.
The lines should have the same length, and the first pixel of the second line should be blinking. In none of the emus it is exactly so, only on console.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
^ 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.
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!
Thank you! Actually, I asked before like 5 emulator developers / mapper writers / etc and no one was interesting in fixing this. So you are the real Hero!
But there is one question...
Is it possible to port this to FCEUX? We want that overclocking!
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Alyosha wrote:
^ 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's what we did today. Everdrive outputs stars in the scanline test, as most of the emus. The problem is, to make the tests perfectly reliable on soncole, one needs to actually put them on a real cart. Bugs we're still getting when running flash carts on console are most likely due to how their firmware is set up.
Alyosha wrote:
That one does not have console test results on the accuracy tests page, and I suspect these 2 things are related.
It does. For 2 console+flashcart combinations now.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
@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.
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.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
You can also ask on nesdev directly.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
The pic is steady on the tuner snapshot, because both fields are shown, which basically translates into frames at 60fps: that pixel flashes every frame.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
^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.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Considering how nmi_sync/ntsc_demo passes on Famicom+Everdrive, the above picture is probably also correct. These are not actual stars after all, like in some emulators.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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.)
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
The joypad tests need clarification about what purpose they even serves exactly. FHorse also said they should be errors and conflicts for official console+controllers, but I don't understand why. If absence of errors there is in fact a failure, then the initial fceux info was wrong. Readme tells nothing helpful. If only some special errors should be considered success, then we need to know which. Otherwise, the test is bullshit.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I know nothing about mappers. Try asking CaH4e3 (reads as "sanchez") in #fceu.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I just tested latest version of BizHawk and there is annoying gray vertical line in the right side of image in every game i tested. It also appears on recorded avi.
http://i.imgur.com/gIZlCB5.png
edit: sorry, but this commit causing the problem "Fix BG check timing, implment pipeline"
Also i read op post. It says something about fds version of metroid. Maybe because there is a problem with start of the game. I didn't mention before, but fds game "Yume Koujou Doki Doki Panic" also can't start if you just press "Insert side 1". You have to do same thing -> eject then put other side
Also we really want an overclock )
^ 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.
I want to point out another "problem". There is a chinese translation for TMNT3 and it doesn't work properly. I understand that this can happen because they modified mapper code specially for this translation and maybe no one interesting in fixing and maybe modification it requires can considered as innacuracy, but still. Just pointing out. It also doesn't work in FCEUX
http://i.imgur.com/QUG8XwY.png
Here is ips patch for japanese version of the game:
http://s000.tinyupload.com/index.php?file_id=01126658513231411526
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Try puNES.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
puNES can't start the game and says "illegal opcode"
As far as i know this translation properly works only in chinese Nestopia mod called Nestopia Plus. Nestopia Plus is the most powerful emulator in terms of correctly launch everything you trow at it, but it's not publicly available. You can trow at it like crazy corrupted multicard dump that doesn't work anywhere and it magically works in Nestopia plus.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Yes. I now why it's not available for public, but i don't care. Everything i care is about proper works of the games. And nothing can beat that mod. Nothing.
It's crazy how there is like hidden chinese nes/famicom universe with crazy amount of unavailable awesome pirate dumps / romhacks and their own emulators.
I am curious exactly what pattern it gives.
