i suspect psxjin is wholly wrong and archaic. it's almost entirely using lewpy's software renderer which was cutting edge circa year 2000. digging up bugs in it is like looking for a termite in an anthill. however you are still doing yourself a favor by digging in this deep, as the knowledge will assist mednafen and psxhawk (should it ever arrive); but youre not doing yourself a favor if youre wasting wishes for something of this magnitude to get revised in psxjin.
http://forum.fobby.net/index.php?t=msg&th=701
study the latest mednafen and perhaps attempt to discover its coefficients. this is the most cutting edge psx emulator right now, even if it isnt completely stable yet. you should also check out pcsx-reloaded.
ill wager this kind of stuff is too detailed for anyone to care about in psxjin, which is a turd. if you can present a better table and vouch for it, then itd be easy to check in.
fixed in r718. an inexplicable error in the pngout (later copied to the aviout) code would cause a rounding error which only manifested on the first column and would result in the first (leftmost) column appearing twice in the output (and the rightmost column being left out)
Zeromus also rubs me the wrong way. I often enjoy helping people work on their emulators, but I can't stand working with this guy.
I rub you the wrong way on purpose, because you rub me the wrong way. Run your posts through a condescension and pedantry filter and I'll do this same. I still truly appreciate whatever help I can get out of you regardless of the level of sass.
Don't get your hopes up. If and when the time comes, multiclient isn't going to sacrifice anything for portability unless an advocate appears to test and make workarounds.
DiscoHawk converts bolloxed-up crusty disc images to totally tidy cue+bin.
Do you have a cue+iso+ape? cue+bin+mp3? cue+wav? Do you have a cuesheet that nothing else can open without crashing? Try DiscoHawk!
It's positively useful right now for pce-cd emulation in bizhawk, but other folks have used it for other things entirely with other emulators.
I personally don't think numbers mean things, so I appreciate your informing me that two different things are not the same thing.
Zelda was broken because it wasnt using the increment-by-32 bit, and I had put in some speculative code which would do different increments during rendering in response to $2007 accesses, hoping to find a counterexample. Thanks for finding a counterexample. Now I do a vertical increment every time.
It was complicated to add for various reasons and we decided to defer it. We may have had philosophical objections, I can't remember, but they were probably pretty weak given that other programs can handle this one way or another.
Yeah.. we can't pass every test. The core needs to be fundamentally restructured to get it up to maximum level of detail. This would need to be done by someone who's not me. The goal now is just to get it respectable. That said, I think I'll try to fix the sprite hit tests because theyre causing some trouble, and theres a gap in my understanding of details in this area that would be fun to fill without requiring a complete renovation.
Thanks for the lesson. To be honest, I'm not sure how I made it this far on such a hard thing. To my surprise, I seem to have quite accidentally gotten it right, except for some little experimental junk that had got left in which I just fixed that caused the registers to latch at an additional illogical time.
p.s. coarse X is latched at cycle 257.
THe DMA Cycle bug in FCEUX is not present in Bizhawk -- But is the bug really fixed? I tested it with NES "Mahjong (J) (Rev B)", and I got the same hand as I got on FCEUX (about this issue, please refer to my post). Indeed, Exec_OAMDma() in Core.cs is as follows:
cpu.PendingCycles -= 512;
And I tried fixing the value to 513 from 512, then I got the same hand as I got on real console.
I just made this change, but I am unhappy, as after that, I read your thread. It breaks some games and fixes others?? This is called a called a timing hack and we shouldnt be doing it. Adelikat said he approved it in fceux so I will let it stand here against my better judgement. I don't really care personally, since the real situation is so much more complicated. The DMA may take any number of cycles depending on the state of the cpu at the time and what instruction it's executing. It typically ranges from 512-514 (I suspect it should be 512 inherently but is delayed since it can't start until a certain moment). But none of that can be emulated without way more detail than neshawk 1.0 is going to use, so I leave it to other people's judgement.
2) BizHawk does not seem to verify NES "Mahjong (J) (Rev B)" correctly.
Wrong reason, but genuine bug. I just fixed that. (it was parsing bootgod's db wrongly and ignoring games with multiple rom variants)
I think I will defer any handling of unofficial opcodes until the time comes to do it. If I do it then I need to understand it thoroughly first. However, your supply of test cases is valuable. I believe you sound competent to add the unofficial opcodes, if you wish. You're welcome to try. Keep in mind that the mos6502 code comes from the CpuCoreGenerator project.
* I think the strings "mir=0" and "pa=0|1" are not so easy to understand. At least, I want some documentation about them.
I tried to think of some ways to do this, but I don't want to turn that log into a tutorial. I'm not good at documentation so I don't know where to put this. But I'll explain it for you: pa=0|1 would indicate that pad_h=0 and pad_v=1. These are optional physical parameters of the board, which are specified in bootgod's database, and control the mapping in most cases. This is because the same PCB layout/name could be used and have its mapping configuration changed by soldering on pad_h or pad_v. So when describing a game's physical configuration, you must describe whether these pads are soldered, if theyre present. From this, the mapping mode can be inferred. However, this information is irrelevant for some boards, which don't have these pads, and wire the nametables right into the mapper. But, since the blobs of solder arent actual chips, like everything else, they cant go into a list of chips (well, i might have made 4 virtual chip types for this and rolled them into the chip system as "pad_h_filled, pad_h_unfilled, etc." but that isnt how it was done.) Therefore they are basic parameters of the board. I did just now add a memo in the output for mir= which was just the mirror mode as specified by the iNES header.
3) Could you set svn:executable property for *.exe, *.bat, *.dll files? I am using svn on Cygwin to checkout the source tree, and I have to set execute permission to these files to build successfully.
I think I did this. Let me know if I didn't hit enough of them. Or if you want commit permissions to set this yourself when necessary ^_^
4) For now, it seems that BizHawk's 6502 core does not implement unofficial opcodes and some double read/write behavior.
Do you have a plan to implement them in the future?
Yes, we'll surely do this some day. I didn't know anyone would need it. This is sort of a big project though.
Thanks for teaching me that. I didn't ever think of it. I fixed it just now; itll be supported going forward.
How do you like the dump status report and rom quality icon? We wanted to make it easy to understand how things are getting detected and loaded.
I think the name won't be changed. It's been called BizHawk for over a year. We're on revision 1774. BizHawk is an excellent name. Individual components can be called *hawk, like neshawk or discohawk or pcehawk. The biz part is because hawk biz is called bizhawk. The name is perfect. The only replacement I wouldve countenanced is StarHawk (because its *hawk) but that was already taken by various things.
Fun Fact: BizHawk _is_ the better name. For some months before then it was called PayrollPro.
i found a bug related to ppu bus address strobing which made was breaking your game in bizhawk and fixed it in r1773; also i added a catch-all for mapper 4 so that it can boot without a hash
It will support nonexistent boards by defining them in a structured way. This one probably through a newly defined CNROM-HOMEBREW board type which I will define and bind to iNES headers specifying mapper 3 which don't bind to anything else first.
You can't expect a new emulator to support every hacked up bogus 'mapper' ever conceived, unless it does so by having virtually no validation on anything, which guarantees bugs later.
Regarding the accuracy of bizhawk's nes core:
It is, at present, not the most accurate emulator. It is roughly on par with FCEUX, as per the original scope. More accurate in some ways, less than some others. So, bugs are expected.
The organizational business of the mappers and basic compatibility will be supported at maximum level.
Core timing precisions can't be supported very well without the assistance of someone willing to adopt the core as a primary programmer. But feel free to post the bugs for such a time.
This emulator uses a policy which I expect to be controversial.
Games are emulated strictly using boards. We have a table that relates iNES header parameters (including mapper number) to a board name. This table is pretty incomplete. At some point I got started adding a convention of board types like "NROM-HOMEBREW" which are more lenient in their validation. These can be added to the table as a catch-all. But unless it's added to the table, there is no possible way to load a ROM. I will be glad to do this when supplied details about what needs doing.
There is one other possible way to load the rom, which you seem to have found. The gamedb.txt #includes gamedb_user.txt ; you can supply this file with records from your personal build process to make sure it gets processed correctly by the rom loader.
Here's the problem. Different people have different opinions on what it means to have hacky HOMEBREW variants of mappers. Different conflicting opinions. Our policy is devised so that we have an explicit record of whose opinion we are accepting (the iNES header -> board type table) along with reasonably cleanly encoded rules in the board type validation. Incompatible opinions have a way to express themselves, via the gamedb system.
Yes, you may call this user unfriendly. But continuing the traditional clusterfuck of hacks and madness is user unfriendly, too. I thought we'd try something different here. Can you play along until we discover whether I was right or wrong?