^No worries. Good Luck True.
I'll try to get some hopefully definitive tests ready in the mean time.
VS system is moving along nicely. Now you can insert coins and play games requiring the zapper. Should have full compatibility soon.
Update on VS System. Now all but one VS UniSystem games can be played! Contorls are are implemented in EmuHawk and can be used in TASing (although I'm not sure of the TASing potential of any particular game.)
The one notable exception is Hogan's Alley. The game boots and runs correctly, but light gun detection for that game is broken because the palette color appears to be slightly different then expected. I'm not sure if this is a problem of the emulated palette or a weakness in light gun detection emulation, but either way it doesn't work.
Dual System games also don't work, and it's not really obvious how they could be made to work, but maybe I'll work on it someday.
For some reason I can't get the controls to work. I tried messing with the controller settings but I don't seem to be getting any response from the games. Is there something I might be doing wrong?
Btw, nice work on getting the VS games to work :) I'm loving all the progress you're making
Oh yeah, you still have to use player 2 controllers since controller registers are backwards on VS.
I'll probably change this in the controller definitions to make it seemless for users, it is kind of annoying.
EDIT: OK I fixed it. Now you shouldn't have to worry about configuring the controller. But, some games like Super Mario Bros still require you to hit start on player 2 instead of player 1, for unknown reasons (maybe some kind of security feature.)
Thanks to natt for improving light gun emulation now VS Hogan's Alley works as well! I think that completes the list of Unisystem games now.
There is one more game out there called raid on bungeling bay. I can't seem to find much about it except for some strange security features it has, so maybe that is one more loose end to tie up but I'm not worried about it for now.
Can't use NesHawk core in latest interim build. For some reasons BizHawk ignores settings "Config -> Cores -> NES with Quicknes" and "NES -> Core -> NesHawk". No matter what - it uses quicknes core. Only by loading like Lagrange point or something that unsupported by QuickNes it uses NesHawk.
Thanks! I was trying to test other issue actually. So i want to test it on the last build. It's impossible to change volume of separate NES sound channels. You can move that things in this menu "NES -> Sound Channels", but settings doesn't apply.
^ wow I didn't even know that option was there :O
Yeah given that the APU now uses the nonlinear mixing formula from NESDEV I don't think those scaling bars really apply. Maybe I can look at putting it back in as an option, but I'm not promising anything in the near future.
Just posting this here: Post #444142FatRatKnight wrote:
An unexpected (but also minor) one came up near the end, when the game skipped the HP increase text on level up. I have no clue how it happened, but it did save a few more seconds (and looks funny) ...
At around frame 279000, the TAS crashes the game under FCEUX 2.2.3 now.
Curious if this glitch has something to do with a well-timed interrupt and some timing changes between FCEUX 2.1.3 and 2.2.3
I wonder how BizHawk and console behaves in that case?
The function at $C500 uses values currently at $0126 and $0127. Unfortunately, just as its about to use them an NMI occurs. The Stack pointer happens to be at $27 at this point, so it gets overwritten with the return address for the NMI. So when the $C500 function takes back over, it reads an incorrect value ($C5 when it should be $06) and crashes shortly after. Oops!
Whether or not the timing works out this way or not on BizHawk/console I don't know. It seems possible though.
Hey Alyosha, have you ever considered emulating the Famicom controller 2 microphone? There is a decent amount of information on it and it seems possible to emulate in some way. There is only a small amount of games that seem to use it but it could be useful in FDS Kid Icarus and the FDS Legend of Zelda.
^ I guess it would be pretty easy to pump pseudo random noise into the microphone port to simulate breathing, but that's probably as far as I could get easily, which is enough I guess for at least those games to work. Anything beyond that though would probably be rather hard. I can add it to the list though, but won't be a high priority.
v I think the microphone needs to have subframe inputs to work properly. I tested in FDS Kid Icarus in 1-2 item shop and nothing happend.
Hey Alyosha, have you ever considered emulating the Famicom controller 2 microphone? There is a decent amount of information on it and it seems possible to emulate in some way. There is only a small amount of games that seem to use it but it could be useful in FDS Kid Icarus and the FDS Legend of Zelda.
The microphone is already implemented and has been for a long time. Is it not working for you?
I didn't realize the microphone was implemented actually. I discovered that you have to switch the controllers to famicom and all that.
So, is it confirmed to work or is it not implemented fully? I would test it out in FDS Zelda 1 but I don't have a file with access to Pols Voice
So, is it confirmed to work or is it not implemented fully?
Neither of the above. I implemented to a spec, which apparently isn't enough for at least some games, but no investigation has been made into what is missing. If it needs subframe input, that will be hard unless we can fake it somehow...
I tested zelda and it does work for killing the rabbit enemies (basically just mashing the mic button.)
I'll test Kid Icarus with a strength upgrade as le Necroyeur suggested later in the week.
EDIT: tested kid icarus with a strength upgrade and still nothing happened, guess it needs subframe inputs after all for the mic.
For now I'm mostly interested in using this to compare execution traces with Mesen for the couple of tests it still doesn't pass and try to figure out why.
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.
Wow that's crazy! 8D
The online version was just too slow to be very useful, but I can see this version being a valuable asset and test bed in the future with a bit more development.
Very Cool!
Just came back here to give this thread a bump! Just curious if any progress has been made. I assume you guys have a lot more discussion on this in IRC so I was just wondering if there has been any advancements.
Just came back here to give this thread a bump! Just curious if any progress has been made. I assume you guys have a lot more discussion on this in IRC so I was just wondering if there has been any advancements.
Nothing lately. NESDEV is where most of the action is happening right now, but progress has stalled out due to a few serious bugs in VisualNES.
There are a few other interesting developments in effective write timing in the ppu, but nothing exactly groundbreaking.
My time has been pretty chopped up with Intellvision and ColecoVision and DTC6, but I do plan to continue work here once I can focus more.
I recently stumbled across a test rom that tests some bizarre NES sprite evaluation glitches that NES Hawk wasn't even close to passing. (Mesen and punes aren't close either.)
So I completely overhauled sprite evaluation and now I get all the correct reads and sprite data and all pathological behaviour accounted for.
The only difference between this and the results posted by Quietust in NESDEV is one extra 'FF' at the beginning. Quietust mentioned that there might be a variable number of those bytes at the beginning (which represents the tests starting a different pixel) but I currently don't understand why this would be the case or what the expected outcome should be.
This is actually good news since I didn't have any new good leads lately as to why some runs were failing to sync, so I hope this leads to some new information.
But all the behaviour is now emulated correctly, so this is a pretty big accuracy improvement. Let's hope there are more to come!
See this thread for more info:
http://forums.nesdev.com/viewtopic.php?t=2295
I've made a number of accuracy improvements to NESHawk lately, including getting Huge Insect to work. This game relies on an obscure hardware glitch in the PPU that I overlooked until now.
Also Micro Machines now runs without graphical glitches, but as always with this game this is tentative until proven totally accurate.
I've made numeroud changes recently, so if anyone notices any bugs please let me know. I tested pretty thoroughly with all the most difficult cases I know so I don't think anything is wrong but can't be certain.
Great stuff, Alyosha!
I always wondered about Micro Machines - I rented that game a few times as a kid, and it *never* ran without severe graphical glitches! Wouldn't Neshawk be more accurate if it ran the glitches in that case, or are there certain CPU or PPU revisions that actually did run Micro Machines correctly?
Update on VS System. Now all but one VS UniSystem games can be played! Contorls are are implemented in EmuHawk and can be used in TASing (although I'm not sure of the TASing potential of any particular game.)
The one notable exception is Hogan's Alley. The game boots and runs correctly, but light gun detection for that game is broken because the palette color appears to be slightly different then expected. I'm not sure if this is a problem of the emulated palette or a weakness in light gun detection emulation, but either way it doesn't work.
Dual System games also don't work, and it's not really obvious how they could be made to work, but maybe I'll work on it someday.
The only difference between this and the results posted by Quietust in NESDEV is one extra 'FF' at the beginning. Quietust mentioned that there might be a variable number of those bytes at the beginning (which represents the tests starting a different pixel) but I currently don't understand why this would be the case or what the expected outcome should be.
This is actually good news since I didn't have any new good leads lately as to why some runs were failing to sync, so I hope this leads to some new information.
But all the behaviour is now emulated correctly, so this is a pretty big accuracy improvement. Let's hope there are more to come!
See this thread for more info:
http://forums.nesdev.com/viewtopic.php?t=2295
I've made a number of accuracy improvements to NESHawk lately, including getting Huge Insect to work. This game relies on an obscure hardware glitch in the PPU that I overlooked until now.
Also Micro Machines now runs without graphical glitches, but as always with this game this is tentative until proven totally accurate.
I've made numeroud changes recently, so if anyone notices any bugs please let me know. I tested pretty thoroughly with all the most difficult cases I know so I don't think anything is wrong but can't be certain.
