Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Use this thread for official bug reports if possible.
Also, I ask all bugs be reported on our github repository. Though you are welcome (and encouraged) to post them here as well.
TAStudio bugs are reported here.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
* Extended soundchips for Famicom don't look supported (I guess it's because of mentioned lack of support for some Japanese ROMs). Also ability to adjust channels volumes would be nice.
* Covering emulator window with any other prodices weird effects:
http://i1139.photobucket.com/albums/n547/feos-theos/0b55812a.png
* Setting paths to non-bizhawk folders doesn't take effect.
* Can't open lua script with icon buttons.
EDIT: It's also deadly slow and requires .net framework. Most casual gamers I know still use fceu 0.98 or nestopia.
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 submitted a bug regarding high pitches in nes sound emulation.
I would also like to suggest a clear button on the joypad config screen. There were default joystick buttons already assigned as secondary inputs, and I assigned the correct joypad inputs but had no way to remove the defaults. Thus some of my buttons were doing double duty. I had to manually edit the ini to fix.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Yes, these have not been done yet and are mentioned in the Mapper List
Ok, Added this to the TODO list
I was not able to reproduce this, it worked fine for me when I tried. Can you be more specific?
Thanks, fixed.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I mean I keep my ROMs in totally different folder. I specified the path to ROMs to that folder and when I choose "Open ROM" it opens the BizHawk folder, and nothing can prevent it, even setting all bizhawk paths to my "different" folder.
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.
BizHawk does not verify NES "Galaxian (J)" ROM correctly. It says "Inferred from iNES header; potentially wrong" for a good dump. In dump status report, it says:But the hash value is not correct. This ROM has only 8KB PRG, but the .nes file contains 16KB mirrored PRG due to the limitation of iNES format. So, you should treat this PRG as 8KB to verify this ROM correctly.
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 extracted BizHawk.zip to a new folder. I get a crash when starting BizHawk.MultiClient.exe.
BizHawk.MultiClient has stopped working.
Problem signature:
Problem Event Name: APPCRASH
Application Name: BizHawk.MultiClient.exe
Application Version: 1.0.0.0
Application Timestamp: 4f52837f
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7600.16850
Fault Module Timestamp: 4e211485
Exception Code: e0434352
Exception Offset: 0000b9bc
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1053
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I compiled r1808 and confirmed it verifies NES "Galaxian (J)" correctly. Thanks!
I think the dump status report is easy to understand, if the reader has some knowledge about NES. But:
* I think the strings "mir=0" and "pa=0|1" are not so easy to understand. At least, I want some documentation about them.
* It would be nice if it also prints a MD5 hash for "PRG (8KB) + CHR" entry.
For the icons, I like them and I think they have no problem :)
----
Some other reports:
1) In this post, 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.
2) BizHawk does not seem to verify NES "Mahjong (J) (Rev B)" correctly. I guess the reason is written as the comment in BoardSystem.cs:
//notes: there can be multiple each of prg,chr,wram,vram
//we arent tracking the individual hashes yet.
It would be nice if this issue is fixed in the future :)
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.
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? Most of NES games don't use any unofficial opcodes, but some games do. And, if you use some memory-corruption glitch, some double read/write behavior may issue. Indeed, in my Double Moon Densetsu run, PPU registers are accessed via indirect-indexed addressing mode and some double read occur (about the double read, please refer to GetIYRD() macro of FCEUX).
Not sure if this was already mentioned or if it's still a WIP but the TAS studio is not working at all.
If I play a NES (also tested TG16) rom and press pause in the studio, the pause will work, but pressing the frame advance button resumes the emulation and none of the buttons in the tas studio will work again.
Also, you're unable to map left shift or right shift to the controller mappings.
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.
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 ^_^
Yes, we'll surely do this some day. I didn't know anyone would need it. This is sort of a big project though.
Joined: 4/2/2009
Posts: 376
Location: Porto Alegre - Brazil
I don't think the import button for movies works at all for MMV ... O_o tried many files here, none can be reproduced on Bizhawk @___@
Will it desync movies when the second version is released? (this is not a bug, at least not in this version) >_>'
Do I have to move all my SMS roms to the new folder? and the movies too?? @___@
Do I have to accept that frame counter so near the middle of the screen? Is there a way to move it? o_o (this is almost a bug) xP
EDIT1: Why do I have the Stop button clickable when the movie already finished running? x_x
EDIT2: Why 'Movies starting from a save state are not supported'?
EDIT3: My massive files conversion worked, and now I can see the files on the list ... all I've tried so far desync... badly +_+
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Configure on screen messages in Messages menu.
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.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
It creates a .tas file. It doesn't mean it will sync. In fact, it likely won't, there are sync differences between Bizhawk and dega.
I have no idea what you are talking about, but no you don't have to move anything.
Again, I have no idea what you are talking about. THe frame counter is in the top left corner of the screen by default, unless you changed it in the message config dialog.
If you are seeing (finished) after the frame counter, then the movie is done, but it is still loaded. Stopping it clears it from memory. This is the same functionality you will see in FCEUX, GENS, and Desmume
Bizhawk allows you to create movies from savestate. But maybe you mean importing movies that start from savestate? If so, explain to me how Bizhawk is supposed to understand a dega savestate in order to import it.
Joined: 4/2/2009
Posts: 376
Location: Porto Alegre - Brazil
Now I get it! My messages are all happening in the middle of the screen when I set them to lower left corner, 0, 0... middle left, actually, I think it's not recognizing the Screen 2x O__o
EDIT1: The emulator unpauses too often, usually because I changed to the browser and came back ... this is bad for frame advancing, because the game resumes running and can ruin a movie, or at least increase the rerecord count by some hundreds .. x_x
Also, the message window doesn't accept any Y value greater than 184, and I'm pretty sure my screen is bigger than that in pixels ._. (plus, it doesn't accept negative values, which means there is no use to the other corners, just upper left) O.o (is this supposed to be like that? I'm starting to figure that maybe it's supposed to be like this and I'm not using it right) o_O
BTW, thanks, I found the paths option and the folders are not a problem anymore... XD
I'm moving a project from Dega to Bizmark here to see if I can find more bugs +_+
Nope! Did not know there was such a thing. I changed the BizHawk page here to put that download link first, with a short comment. I have gotten it running now.
I tried out the SMS core a bit.
- I cannot assign frame advance to the right shift button. Is this intended? It's very helpful for keyboards that do not accept a lot of buttons at the same time.
- When saving a named savestate from disk via hotkey, the game's sound goes in a short choppy loop. (This does not happen if loading a named state, or saving a named state via the menues.)
@zeromus
Thank you for explaining about "pa=0|1" and setting svn:executable! I checked out the r1820, and I could build it without manipulating permission.
For unofficial opcodes, I found a Puzznic run desyncs on BizHawk r1820. This game uses an unofficial NOP (0x89). BizHawk implements unofficial NOPs, but it seems to forget to increment the program counter. So I tried this patch:
With this patch, the Puzznic run syncs. Of course, other unofficial NOPs need to be fixed in the same way. (Strictly speaking, other unofficial NOPs may have to read memory operand, even though they are named "NOP")
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 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.
Wrong reason, but genuine bug. I just fixed that. (it was parsing bootgod's db wrongly and ignoring games with multiple rom variants)
Ah yes, the infamous puzznic two-byte nop bug. Without proper support, it executes the 00 byte as a BRK, and the screen shakes like hell.
Edit:
Just tested out Slalom. I'm getting flashbacks of Rew and Famtasia here.
Scrolling is not that hard. The critical timing point is PPU pixel 251 of most scanlines. Y scroll bits are incremented, and X scroll bits are reset back to the latch's value. "Fine X" (how much the pixels get shifted) is updated instantly when 2005 is written for the first time, but "coarse x" is only updated at PPU pixel 251. The game is writing to 2005 to set horizontal scroll during "Hblank time", between pixel 256 and 320, so "Coarse X" should be a scanline late compared to "fine X" which is immediate.
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.