Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
arflech wrote:
hegyak wrote:
For those that are curious, 32X emulation will not work at all.
Is that just for now, or is it the policy of the BizHawk developers to refuse to add 32X support?
That's kind of harsh, innit? There are about 9 million things I could be doing with my life. Some, I'm doing right now; the rest are goals of various importance and urgency. Am I "refusing" to do anything that I'm not currently in the process of doing, right this very instant?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
You are correct. When cropped to 256x224, NES should assume a roughly 4:3 DAR.
I think more flexible output aspect ratio control is something we'll probably be looking at once the new video output changeover is done.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Tee-N-Tee wrote:
BizHawk seems to store the input in an "UDLRABCS" pattern,
but a gmv to bkm converted file does it in an "UDLRSABC" pattern, i.e. the converted bkm will perform the wrong inputs.
Thanks for the report. I believe I have fixed this on trunk (but didn't really have any time to test it.)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Yagamoth wrote:
On a sidenote, adding to Patashus comment:
As far as I'm aware, there is no way to use all 3 players in an SNES emulation. I tested it with Secret of Mana, but it did not work. I once had someone somehow involved in the development of BizHawk where I also mentioned it to him.
In the release notes I read, that in version 1.1.1 "SNESHawk - Hooked up controller 3 & 4"
But that was in 2012, so I assume there was no recent change to the 3+ player inputs on BizHawk for the SNES.
For those unaware: For the SNES you need to hook up and activate (!) a multitab device for the SNES tor recognize the 3rd and 4th player. There is specifically a switch on those multitab devices, where you can turn on or off those 'modes'.
--> It's probably not as simple like adding more controllers for other consoles
Edit: @Patashu, there are various small timesavers in Secret of Mana, but no actual big skip ^^
-> You can get past the guard in 2 other ways too
Yeah, there are only 2 players supported in sneshawk. The "3 and 4" was a misunderstanding of a variable. What's actually emulated is 2 standard controllers plugged in; no multitaps at all.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Yeah, hold on while I check every rom in existence to guess which ones you were using.
Anyways, due to the help of helpful people (not you), it's been determined that something went wrong in the build process of the build that was uploaded. We didn't see it here because everything but that specific build works fine. A new build will be up soon.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Tee-N-Tee wrote:
adelikat wrote:
Ok, I updated the link in the first post. If you downloaded it before reading this post and were using GenesisHawk you need to redownload, all your savestates have been invalidated.
Sorry, for that, trying not to do any fixes that affect savestates (or sync).
I downloaded it anew, but now it crashes when I try to open a Genesis ROM.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Fortranm wrote:
The guy who uploads the Pier Solar rom says that GenesisPlusGX will detect the ISO as long as it's in the same directory as the bin.
The enhanced audio pack provided on Pier Solar's official website only contains an ISO for you to burn a disk.
So yes, those are all I have, a bin and an ISO. I wonder if a corresponding cue has ever existed.
Pier Solar? I thought we were talking about Sanic CD? Your last post says Sanic CD.
Pier Solar's companion CD is not an audio CD; it's actually all data. (It plays using the RF5C164's PCM streaming capabilities, I believe). I imagine it would work correctly in Bizhawk without a cue file if Bizhawk loaded it, but I haven't checked.
Edit: To clarify: Bizhawk does not play Pier Solar's enhanced alternate music simply because it does not load the companion CD with the game.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Fortranm wrote:
It seems PCM disks for Genesis games are still not supported in 1.6.0 release?
This was answered 4 posts ago. In order to get CD audio in Genesis, you must have cue\bin. Discohawk may be able to help you with conversion, depending on what you started with; but if all you have is an ISO, you're likely missing needed information.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I've been talking to vec and we've identified potential Mega-CD desync problems that will be corrected before retail. So there will be another pre-release soon (as soon as I wake up tomorrow, mostly).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
An ISO does not carry audio CD data in it, it just has the data track. A proper dump of sanic CD will be in cue\bin format, and the CD sound works with that.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
JohnnyG wrote:
amazing news but there is something that i don't understand. wouldn't it make more sense to put effort into adding emulator cores of systems that have no rerecording emulator yet instead of having a new core of a system that got lots of runs already?
What existing core out there is useful for Bizhawk that we don't have already? I'm aware of a few, but each has its reasons for either why we're avoiding it or what else needs to happen before it can come in, or who's working on it.
There is of course writing new cores from scratch, but the effort that takes can't be compared to the effort to port in an existing core. If there's anyone interested in writing a new core for the Bizhawk project, and who has the time to do so, send them my way.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Fortranm wrote:
Q: What's the difference between the MMC3 and MMC5 versions?
A: The MMC5 version is technically superior. There is less slowdown and the charging sound doesn't interrupt the music.
The author guarantees that the MMC5 version will work in FCEUX and that the MMC3 version will work in VirtuaNes. Other emulators may have issues, ranging from minor visual bugs to completely not working.
Go ahead and try either version in your preferred emulator, but I personally recommend just playing the MMC5 version in FCEUX.
MMC3 and MMC5 are chips that NES cartridges contained. The MMC5 is a later, more advanced chip. Mega Man 4 was originally made for the MMC3 chip, but PureSabe ported it to the MMC5 chip for his romhack to take advantage of its more advanced capabilities.
Bizhawk can't run MMC5 version of Rockman 4 Minus Infinity.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
synnchan wrote:
The game is "Cotton - Fantastic Night Dreams" (for PCE CD)
The Bizhawk version I'm using is 1.5.3. And I dunno how to check the core. PCEHawk by vecna?
It appears to be mostly a PCE problem. I'm looking into it; might be hard to do anything for you; apparently the real hardware was kind of wonky when it came to this sort of thing.
Fortranm wrote:
A file named mupen64plus.cfg appears in D:\ when Bizhawk runs N64 games.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
synnchan wrote:
Why is the audio of Bizhawk so dreadfully low?
I put the volume at 100 on the Emulator, plus almost at the max on my speakers and I still can barely hear the music. Is there not a way to circumvent this?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Relevant paper:
http://www.rfidsec07.etsit.uma.es/slides/papers/paper-12.pdf
In short, it claims that individual bits in SRAM are not likely to be heavily affected by external sources. However, each bit will have a probability distribution (which is a fingerprint of the chip and determined by manufacturing variances), and some of them will strongly tend to '0' or '1', others will be close to 50-50 and subject to random variance from heat, etc.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I always thought of the power on state used by RAM in various emulators as a sort of nothing up my sleeve situation.
It's most likely true that the NES can assume any value for any single bit in RAM on powerup. It's also most likely true that the probabilities for each bit are not a simple 50% and not even independent (as a lot of '1' or '0' bits in a single row will change the overall electrical situation of that row). I know there is at least one example of a game that will not boot with FCEUX's initial ram state, will boot with an alternate initial ram state, and usually boots correctly on a real console.
I agree that a '1' in 1000 bits of ram as a startup state is much more unlikely than the latch requirements in Cheetahmen II.