Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 31, 2005 4:13 am Post subject: bsnes thread | |
|
|
|
| bsnes is a super-accurate, cross-platform SNES emulator by byuu. You can read all about it and download new versions at: http://byuu.org. The title of this thread will change to reflect new releases. All commercially released games have been tested (~3000) and it is currently believed that 99.9% of games without special chips play with 100% perceived accuracy. The emulator contains no game-specific hacks and makes almost no compromises to compatibility for speed gains. This means that bsnes has very high minimum requirements: at least a 1.8ghz Core 2 Duo to achieve 60fps without frameskipping. bsnes' PPU is scanline-based rather than dot-based. A scanline-based renderer is technically a general hack that most emulators use to simplify the PPU and achieve massive speed gains with virtually no sacrifice to compatibility. Without it, bsnes wouldn't even come close to reaching 60fps on modern CPUs. That said, only a few obscure games have issues with a scanline-based renderer, and the issue is usually very minor and takes the form of an incorrectly displayed horizontal line on a menu screen (thus the .1% deduction above). Several advanced options have been created to make the scanline-based renderer behave closer to a dot-based one, improving accuracy without resorting to game-specific hacks. byuu has stated that he may in the future begin writing a dot-based renderer out of a desire to document the SNES' PPU. ORIGINAL POST: As some of us may or not know, byuu released a new version of his snes emulator last week. byuu, although I'm sure the resources for help are better today than in the past, you ARE a code monster. Seriously, the level your emu is at now from when you started is crazy. I am also pleasantly surprised by how often you post updates, and the detail with which you blog. It's interesting to see your train of thought in the progress of your emu. So yeah, just wanted to let you know that you rock since I've never seen anyone post a bsnes update here yet. I read your recent log and... until now I had no idea that you knew next to nothing about sound. Naturally, my hopes for a 1-2 punch emu were once again somewhat dashed. As an outsider who knows not much at all about code, I can only be so critical and frustrated with the stagnance in snes sound emulation right now. A lot of great, accurate emus out there, but the same ol "sound is a real bitch" issue that just puts a grinding halt to the possibility of snes ultimacy. I've pretty much given up hope of zsnes ever getting the sound issues fixed. We're lucky to get a gamefix at all anymore in the wips. Understandably, but true. Anyways, I'm sure TRAC knows how godlike his sound code is, and probably has his reasons for not wanting to entrust it to other emulators. Additionally, he probably knows that if he doesn't, any hope of snes ultimacy will continue to be snuffed out. I guess what I'm getting at here is: WHO IS THIS TRAC!?  : Why is he so good and what will it take to get him to team up with someone like you?Last edited by FitzRoy on Fri Mar 21, 2008 4:32 am; edited 272 times in total |
|
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Wed Aug 31, 2005 4:16 am Post subject: | |
|
|
|
| TRAC writes SnEeSe. I'm sure he's willing to share info, but I doubt he'd want to merge the two emus. _________________ #577451 |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 31, 2005 4:19 am Post subject: | |||
|
|
|||
I know, I mean, besides that... That's all I know, seriously. He's very mysterious. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 31, 2005 5:05 am Post subject: | |||
|
|
|||
|
Thanks for the kind words, much appreciated. TRAC is more than willing to help, and I've been nagging him the past couple of days on IRC for info. He's an awesome guy. I just hope I can keep from annoying him too much while I'm catching up to speed. I'm sure he wouldn't mind me using his sound code, the problem is that our emulators are very different, and it isn't exactly trivial to just merge his work into my emulator. Not to mention, it would be disrespectful to TRAC to do that. And, more importantly, I'm writing this so that I can understand the system. We won't get anywhere by cutting and pasting misc. emulators together.
Hm, you think so? I always thought development was kind of slow, especially given that old saying, "The road is always quicker for the second traveller"... Anyway, everyone else is still making a lot of great progress too (anomie, TRAC, Overload, pagefault, Nach, etc), they just don't talk about it as much as I do. They deserve more props than I do. |
|||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Wed Aug 31, 2005 12:32 pm Post subject: | |
|
|
|
| Byuu, you are doing some seriously crazy work in making sense of the hardware. I think you've brought new life to the research into the dark corners of the SNES's inner workings. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 31, 2005 4:56 pm Post subject: | |||
|
|
|||
True, true. I guess I assumed video and sound were so seperate that it would take only minor adjustments to port it over assuming it was the same language (and of course, TRAC would be credited as a co-author or something so as not disrespect him by just taking it). It's probably much more complicated than that, and I once again underestimate your willingness to learn what sounds like you're biggest challenge yet. Good luck to you. (PS. If you get to a point where you think it might help, I have an snes with digital output. If you have optical input on your computer, you can record bitperfect snes waveforms for comparison, analysis, whatever. Alternatively, I could send you recordings.) |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Aug 31, 2005 5:38 pm Post subject: | |||
|
|
|||
|
FitzRoy: If you would see what goes on in IRC for a while, it won't seem so mysterious. And we are teaming up in ways, although I won't give out any details on that at the moment. Regarding using TRAC's sound core, he gave permission for it to be put into ZSNES. pagefault is supposed to be working on that, and I'm waiting for that to be completed before I tackle any of the major things I wanted to do to ZSNES.
Oh please, what progress am I making? Yes I can spice up an emulator, but make progress on emulation? I barely know anything about emulation. I do for emulation what ipher does for the GUI. It's anomie, TRAC, Overload, you, and formerly people such as zsKnight, Gary, _Demo_, pagefault that do all the real progress. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 02, 2005 5:51 pm Post subject: | |||
|
|
|||
Whoa, that's awesome news! |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 02, 2005 9:01 pm Post subject: | |||||
|
|
|||||
How mysterious.
You've contributed direct fixes to my emulator, such that Mega Man X is now playable. You also fixed the RAM initialization stuff in ZSNES such that reset is now possible (me pointing it out is irrelevant, it wouldn't be fixed without you). Hopefully your work on NSRT will eventually result in us having a standardized emulator header for ROM images. Give yourself more credit :D |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Sep 04, 2005 1:09 am Post subject: | |
|
|
|
| Sure I gave you some patches and did some stuff for other emulators, but I haven't really done any emulation progress. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
"Your thread will be crushed."
Joined: 28 Jul 2004
Posts: 1038
Location: Not in Winnipeg
| Posted: Sun Sep 04, 2005 1:33 am Post subject: | |
|
|
|
| I have a question. Where would one start to learn to make a snes emulator? This is assuming that one has no knowledge on anything about the internal workings of the snes. | |
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Sun Sep 04, 2005 9:07 am Post subject: | |||||
|
|
|||||
No knowledge at all ? One must be lucky enough to be entrusted with docs, read them in their entirety, then read them again with some aspirin ready nearby. After that it's "just" a matter of defining how precise you want to emulate stuff. A copier and a real snes to run test programs don't hurt. Trial and error fill in the blanks where docs aren't explicit. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||
"Your thread will be crushed."
Joined: 28 Jul 2004
Posts: 1038
Location: Not in Winnipeg
| Posted: Sun Sep 04, 2005 5:55 pm Post subject: | |||||
|
|
|||||
Once I get a copier, the pieces will be set. |
|||||
Lurker
Joined: 07 Dec 2004
Posts: 168
| Posted: Sun Sep 04, 2005 9:30 pm Post subject: | |||
|
|
|||
... or are wrong. |
|||
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Sun Sep 04, 2005 10:06 pm Post subject: | |||||||
|
|
|||||||
Exact. I always (stupidly) assume docs are right. That's why we need to clean the garbage and only keep the real stuff. And by 'we', I actually mean you, byuu, and whoever is actually doing something about it ^^; . _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||||
Zealot
Joined: 02 Feb 2005
Posts: 1045
| Posted: Sun Sep 04, 2005 11:06 pm Post subject: | |
|
|
|
| we should see a whole new sleuth of snes emulators once his documentation is complete. btw, what other snes are out there besides snes9x, bsnes, and snese, and zsnes, of course. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Sep 04, 2005 11:08 pm Post subject: | |
|
|
|
| SNEeSe, Super Sleuth, and I've heard of NLKE, but I've never used it. _________________  <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Sun Sep 04, 2005 11:13 pm Post subject: | |
|
|
|
| SNEmul. _________________ #577451 |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Sep 04, 2005 11:19 pm Post subject: | |
|
|
|
| Here's a few more I just thought of: UOSnes, SnesGT, Snes9k (which is Snes9X, but it uses the Kailerra netplay client), and xSnes9x (Snes9X for the XBox  )_________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Mon Sep 05, 2005 12:12 am Post subject: | |
|
|
|
| There
was an old SNES emulator called CHAMPI that I liked for a long time
(well, several months at the most). It was fast, and the GUI was
entirely in Spanish. Of course this emulator doesn't compare to ZSNES
now. I believe it's available for download at emuxhaven. |
|
Zealot
Joined: 02 Feb 2005
Posts: 1045
| Posted: Mon Sep 05, 2005 2:42 am Post subject: | |
|
|
|
| is zsnes currently compatible with XBOX? | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Sep 05, 2005 2:50 am Post subject: | |
|
|
|
| http://board.zsnes.com/phpBB2/viewtopic.php?t=4352 _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Sep 05, 2005 4:41 am Post subject: | |
|
|
|
| IIRC pagefault will be porting ZSnes to XBox, if and when he gets one You'll have to have it modded though, nothing we can do about that -_- _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 06, 2005 8:31 am Post subject: Re: bsnes appreciation thread, sound woes | |||
|
|
|||
Hmm, perhaps this, or possibly this will help... All your thanks are belong to anomie for the above. |
|||
Guest
| Posted: Wed Sep 07, 2005 2:42 am Post subject: | |
|
|
|
| Okay
now I'm impressed. How do other games that are real trouble makers like
earth worm jim 2 sound? Even SNEeSe is kinda shaky on that game. I mean
the music is fine but the sound fx for it is weird. Edit:  Nevermind I just checked your homepage. That still doesn't change the fact that bsnes kicks ass. Good job. |
|
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Wed Sep 07, 2005 3:44 am Post subject: | |
|
|
|
| Hey Byuu, if you want to conserve bandwidth, you can use Coral Cache. _________________ #577451 |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Sep 07, 2005 4:55 am Post subject: | |
|
|
|
| Oh, w00t city! Course, the real test is the heavy SPCrape sound fx... things like: Chrono Trigger opening screen shifts, bats and lightning in Castlevania IV, and the Star Fox background engine sound (that'll have to wait). Regardless - good work and sooner than expected! | |
New Member
Joined: 08 Sep 2005
Posts: 6
| Posted: Thu Sep 08, 2005 5:31 pm Post subject: wow | |
|
|
|
| Looks like you already know what you are doing. Blargg has a pretty good snes sound emu and has some good resources. http://www.slack.net/~ant/nes-emu/ |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Sep 15, 2005 6:58 pm Post subject: | |
|
|
|
| More news: http://byuu.cinnamonpirate.com/?page=bsnes_news _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 16, 2005 5:29 am Post subject: | |
|
|
|
| Some
of it bad news, too. My 2.4ghz works hard to get ~50fps in bsnes as it
is right now. I guess it goes to show how difficult it is to have fast
and accurate code. Help the BYUU!!! By the way, it must be pretty exciting for byuu to see his emu almost becoming fully playable with sound and everything. *waits patiently for new versions* |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Fri Sep 16, 2005 7:42 am Post subject: | |||
|
|
|||
byuu and I just sped it up quite a bit. I might also add in *nix I have no trouble getting sound  _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 16, 2005 9:28 am Post subject: | |||||||
|
|
|||||||
|
Yes,
many many thanks to Nach for profiling the code for me. It's about
15-20% faster with only one function improved and one slightly touched
a little. The slowest function right now is a MONSTER of a routine that
handles ~80% of all rendering. Not an easy one to mess with without
breaking lots of stuff. Sound on Linux is /better/ than on Windows because the program that sends the sound to the soundcard automatically does resampling stuff that I don't know how to do yet... but it has terrible latency compared to the Windows port.
Must be an Intel. My 1.67ghz /got/ about that on v0.011... I agree with everyone that the speed is deplorable for an SNES emulator. I'd doubt that I'd ever see more than a 100% speed increase from v0.011 ever. But you never know.
I looked briefly at it. It looks mostly like libopenspc with improvements + the BOOST library for a few tiny things. Nothing I couldn't rewrite, but eh. From what I've seen of libopenspc, it isn't very good compared to modern emulators. It chokes pretty badly on Der Langrisser music. It was easier to go with anomie's work. And we can share bugfixes and such as he is actively developing his code still.
They sound fine to me. I don't have the other games. --- BTW, I tend to post updates once a week or so... just sayin'. |
|||||||
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Fri Sep 16, 2005 9:52 am Post subject: | |
|
|
|
| The speed with v0.11 is great for me, in fact the emulator runs too fast with most games. With frameskip off and any Window size (does not make a difference which) and running Aladdin, I get 80fps in menus and 66fps when playing the game. _________________  ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 16, 2005 8:22 pm Post subject: | |
|
|
|
| Yes,
but it still takes a really fast cpu to do that, and the cpu usage is
like 60% for me, sometimes spiking to 75%. Comparitively, other emus
use 15% or less to get 60fps. Like byuu said, though, there is some
rendering code that is doing that and it takes time to make make faster
without breaking stuff. Small request, byuu: can we get the .SFC extension added to the "open rom image" list? That's what all my headerless snes files are called and it's what NSRT renames them to. |
|
New Member
Joined: 08 Sep 2005
Posts: 6
| Posted: Fri Sep 16, 2005 10:13 pm Post subject: | |||
|
|
|||
cool. Awesome emu, I can play Apocalypse II (Beta), which snes9x does not. The only bug (I think it is a bug as I don't know what the real hardware does) I have even seen is graphics corruption on the character select screen of Seiken Densetsu 3 with Corlett's translation. |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Sep 18, 2005 10:09 pm Post subject: | |
|
|
|
| Yeah I'd also like to congradulate Byuu for his awesome progress. I do think Bsnes has progressed very quickly,and in a extremely promising direction.(edit*) No offense to anyone but I think it's way too early to ask for feature request in Bsnes. I mean,even though it's showing great promises, it's still in development after all. *Credit also goes to all who've contributed to Snes emulation of course. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 18, 2005 10:36 pm Post subject: | |||
|
|
|||
Wasn't really a "feature" request though, and I agree with you. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 18, 2005 11:54 pm Post subject: | |||||
|
|
|||||
Done. Slight oversight, I had .sfc in there before I rewrote the thing around April... :/ Been thinking about making one of those kawaks/snes9x-style ROM loaders, and obviously leaving the regular one there as well, but that won't be any time soon...
I'll look into it, thank you. There's actually quite a few games with graphical bugs (Energy Breaker, Contra 3 first boss, Chrono Trigger hi-res screens, ...) Most of them are offset-per-tile mode related. |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Sep 19, 2005 11:58 am Post subject: | |||||
|
|
|||||
Uh... implement savestates then, at least partially?  _________________ savestate editor: vSNES latest public version
|
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Sep 20, 2005 2:48 am Post subject: | |
|
|
|
| I'm excited to try out your next release. Can you highlight some games that your emulator runs better than ZSNES/snes9x/SNEESE? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 20, 2005 10:31 am Post subject: | |||
|
|
|||
No savestates for now, for reasons I won't discuss just yet. They'll be there eventually, though.
Better than ZSNES? Final Fantasy 5 title isn't misaligned Final Fantasy 6 cursor doesn't vanish randomly Star Ocean battles don't run too fast Madara 2 intro isn't chaotic Metroid 3 top status panel looks correct Goodbye, Anthrox mode7 zoom looks correct SNES test program passes Modes 3,4,7 direct color, Mode 7 mosaic + EXTBG work Interlaced sprites work (really only used in Blues Brothers) Anything that relies on open bus working correctly I don't test with SNES9x/SNEeSe enough to know any of its bugs, but I imagine they're far less common. Now as for games it runs worse... probably everything else not listed above. No support for DSP1-4, SA-1, Super FX/2, Toaster, BSX, ST, OBC, ST-01n, peripherals, lots of CPU/PPU/APU/DSP bugs to be found, sound buffering is non-existant... |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Sep 20, 2005 12:00 pm Post subject: | |||||||
|
|
|||||||
You don't have to. 
Great! _________________ savestate editor: vSNES latest public version
|
|||||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Tue Sep 20, 2005 10:11 pm Post subject: | |
|
|
|
| What games used Toaster now, or did I miss something ? _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 21, 2005 2:25 am Post subject: | |||
|
|
|||
He was referring to the fact that ZSNES has Toaster support, but he doesn't ever plan on adding it. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Wed Sep 21, 2005 2:28 am Post subject: | |
|
|
|
| Oh ok, thanks Nach. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Wed Sep 21, 2005 2:44 am Post subject: | |||||
|
|
|||||
I demand that you add the option of adding cheese between two slices of toast! I also demand that you include multiple types of bread, such as white, whole wheat, potato, etc. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 21, 2005 4:55 am Post subject: | |
|
|
|
| Demand denied. However you are welcome to search for the other easter egg I snuck in recently. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 02, 2005 12:42 am Post subject: | |
|
|
|
| Weee, an update! More accuracy goodness. Edit: And no sooner do I post this than does byuu release version .012! I was very eagerly awaiting this new version, just to see what the sound was like - and my friends - IT IS GOOD!
Even though the issues are there with the speed and cutting out of
things, I immediately tested out Chrono Trigger and Super Castlevania
IV to see if SPC Rape was correctly emulated - it is! Hearing all the
wonderful sound effects in their true form was a real treat, much like
sneese. I can't wait for this emu to reach full form. It's only a
matter of time before snes ultimacy is achieved. Good job! |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 02, 2005 8:29 am Post subject: | |||
|
|
|||
|
Damn you guys are quick to notice my updates o_O Be sure to use Misc > Log Audio Data if you want to hear what the sound should be like... it'll record to audioNNN.wav in the same folder as bsnes or the ROM you loaded (in that order). That way you won't get any distortion / crackling due to the samples not being updated at exactly 32000hz during emulation, as my code lacks any and all buffering / resampling support at present. I don't know how to do that. Linux users can play the sound a lot better already with this (thanks to Nach):
Glad it's working though... you're all basically my beta testers... muwahahahaha... Also, do me a favor and don't try Der Langrisser. That game has some screwy sound code... |
|||
Lurker
Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA
| Posted: Sun Oct 02, 2005 8:37 pm Post subject: | |||
|
|
|||
Ha ha ha. I seriously doubt it will only be a "matter of time" before perfect emulation is achieved. No offense to byuu (you're progress in emulation and in your emulator in general are both impressive and awesome), but I'm under the impression it will take a much longer time to achieve. Heck, the emulator doesn't touch some of the more advanced chips and whatnot, but hats off to you developers/reverse-engineer types. All in all, I hope byuu continues his great work and isn't assaulted by "I WANT SUPER HQ2X EAGLE 2X FILTER SUPPORT NOW." Leave that shit to (frontends?) like other emulators leave rerecording to other programmers. Oh, and on a tangent, my only real qualms with bsnes are its speed (too fast on my laptop) and CPU usage. Those two problems will probably be settled all in good time however, and I believe byuu is already aware of them. _________________ I'm hot for you and you're hot for me ooka dooka dicka dee. |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sun Oct 02, 2005 9:25 pm Post subject: | |
|
|
|
| Regulating
emulation speed by sound output is also a good solution. That way, you
also don't have to worry about systems having high resolution timers.
You just have to worry about having a nice way to defer execution while
sound output runs. With SDL, you have a nice callback to notify you when it needs samples. In native Win32, you can do the following: With WaveOut, send whole frames worth of audio per WAVEHDR, use either the callback mechanism, window messages, or events to defer execution according to audio playback. With DirectSound, you can try an exact sized SOFTWARE (IMPORTANT: never use hardware when you want to use event notifications) buffer with an event map tied to buffer offsets, OR you can use Sleep(1) until there's room for a frame worth of audio. But then, you only get context switching and time slices as fine as 10ms, or 1ms if you use timeBeginPeriod(1) on startup. With Kernel Streaming, you can send arbitrary packets similar to WaveOut, and you get to defer execution on synchronization Events just like with overlapped file I/O operations. You lose kmixer software mixing and resampling, so you only get sample rates supported by the hardware, and you completely take over the device if it doesn't do hardware mixing. There's also no easy way to associate an output device with a given WaveOut/Dsound device, or even select the correct default, and you could even BSOD the system if there's flaky drivers and you select a bad output filter. This API is also not future-proof. For the cleanest and safest for arbitrary sized block output with exact event notification, I would consider trying WaveOut on Win32, using the callbacks, and your own Event synchronization to defer execution in your sound output function. The general idea is you have a fixed circular array of WAVEHDRs and Events, all in set state on init, so your write block function prepares/outputs all of them at first. The queue function resets the Event as it sends that header. The waveout callback then sets it again as that header is finished, so the write function will continue. I will write a nice simple class that does this with WaveOut, preference on the ability to defer execution for up to one frame worth of sound, for regulating the remaining stages of the playback thread to the sound output. I already have such a class for Kernel Streaming, but you already know the drawbacks to that. I'd be interested to know how easy it is to have a low latency OSS file session open to /dev/dsp or similar, writing a frame worth of sound at a time, using the natural blocking behavior to regulate the emulaton thread, and how well it works in practice. I will share my simple sound output class and the waveout implementation as soon as I write it, which should be tomorrow. I was going to do that today, but my whole day seems to have gone by too fast. Blah, need sleep soonish. Tomorrow. Yes, tomorrow.... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 02, 2005 9:53 pm Post subject: | |||||
|
|
|||||
Ha? Have you even tried this thing? The accuracy is insane. bsnes handles every non-special chip game I've thrown at it to perfection. Only one of the wierd graphics bugs I'm aware of in zsnes happens in this version. The sound is as amazing as sneese. It emulates spc rape correctly, literally a bug that afflicts nearly the entire library of games in other emus. And special chip games, while most unsupported at this time represent an incredibly small fraction of snes games (and it's not like these won't get supported at some point). It sounds silly because we've been living with the same video/sound bugs in current emus for years, but bsnes is a lot closer than you think. Instead of being so pessimistic, maybe you should become a rabid fan like me. 
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 03, 2005 2:58 am Post subject: | |||
|
|
|||
Kernel streaming in an snes emulator? Probably not the most practical choice, but I think I would shit my pants if that happened. 
|
|||
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Mon Oct 03, 2005 3:01 am Post subject: | |
|
|
|
| Why wouldn't it be a practical choice? _________________ #577451 |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 03, 2005 4:11 am Post subject: | |||||||||
|
|
|||||||||
You're half right. Perfect emulation will never be achieved, but that doesn't mean I can't get damn close. I'm mostly finished with the CPU timing (sans HDMA and conflicting events like DMA overlapping an NMI). Then there's really only APU and PPU. The APU doesn't have anything special in it (no DMA or interrupts), and the PPU will probably never be finished because it requires a pixel-based renderer. I have no interest in emulating add-on chips. They have nothing to do with the SNES hardware. You could stick a PS2 on an SNES cart if you wanted. However, I have no objections to adding all of them sans SuperFX/2 and SA-1, at some point in the future. Hell, maybe even those if they're easy enough.
Don't worry. I'm not planning on adding bells and whistles until the core stuff is finished. I'm used to hearing it runs too slow, especially on laptops. Speed throttling isn't added yet (because I can't get >=60fps to test it on my machine...), but when it is -- if you're getting over 60fps then it won't consume all of your idle CPU time anymore. But it'll still consume probably 5-10x the CPU usage that ZSNES does. ZSNES really is a better choice if you're using a mobile processor and want to preserve your battery power. As far as it requiring so much more power than ZSNES... there's little I can do about that. I don't write code in x86 assembler, and I have to do things the hard way in a lot of cases. My processor emulators run cycle-to-cycle, my NMI / IRQ timing happens between bus cycles within an opcode, my H/DMA timing requires being able to cycle-step, and I actually time my SPC700 instructions. I even have CPU timing events happen in the middle of individual bus cycles. All of these things take a huge toll on speed. I'm also not a very good code optimizer. Super Sleuth is a good example. Overload does much of what I do but manages about 1.5-2x the speed. That's probably a best case scenario for me. BTW, hi PFUNK. Haven't spoken to you in years now. Good to see you're still around :)
Awesome, thanks for the help! As long as it works, WaveOut is fine. Basically, in src/snes/snes_audio.cpp, look at SNES::audio_update(uint32 data). That is called once per sample (pref. 32,000 times a second for 32khz). data = the right channel in the upper 16 bits, left in the lower 16 bits. sound_run() is a virtual function for platform-specific stuff. Problem is that you never know how long it'll take to get there. If the last tick was between a screen redraw, it could be as much as 50ms later or somesuch... now, what I was thinking was keeping 3 buffers, when one gets full, see how long it took to fill and then stretch that buffer to that amount of time (shorten or lengthen). But what I don't understand is that since that time has already passed, what bearing does the length of the last sample have on future samples? You needed sound to run that slow during that sample that's already finished... I also don't know how to resize the buffers without the sound being totally awful. As for buffer size, 1/60th of a second is fine. I prefer a buffer that holds 2,000 samples or less. But because sound is so choppy, it's at 8,000 samples (1/4th second) right now >_<
Wild Guns is the only game I know of that fails solely to CPU emulation. As far as games with video bugs: Energy Breaker, CT black omen, Contra 3 first boss, ToP opening battle does something odd to the gradient menu when that one dude casts that sealing spell, probably more... I haven't done anything with PPU accuracy, though. That's next. Star Trek: Deep Sleep Nine fails because that game is evil and stores a fake valid checksum where a HiROM header would usually go to screw with copiers. I say give it another year and see where I'm at then... |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 03, 2005 5:39 am Post subject: | |||||
|
|
|||||
I think it would be a cool option as it bypasses the kmixer, and anything that does that is much appreciated by audiophiles. There are probably other advantages besides that... But, IIRC, kernel streaming has issues with certain audio cards' drivers, and isn't even supported by some. That would be a problem if it's the only output method...
That black omen bug - was the one I noticed
That's still very good for a known buglist. I also like how simple you
implimented the sound. IMO, I can't think of a reason why some emus
have volume control (this is better to control via speaker knobs or
system tray), filters (what use are these? they sound worse than
default), and frequency changes (non-32khz doesn't make it sound any
better. It only complicates things.) The useful thing is to
mute/disable it altogether, which you've got. w00t for simplicity.Boy does that logged audio data sound good. *salivates* |
|||||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Mon Oct 03, 2005 6:34 am Post subject: | |||||
|
|
|||||
If you change the first block of code in bDSP::run to the code below, it should fix the problems with Der Langrisser. Also, you should remove the extra 'kon' variable in the Status struct and only use the real 'KON' register variable.
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 03, 2005 9:36 am Post subject: | |
|
|
|
| I
found kon odd, too. I asked anomie about this (remember, my DSP code is
a port of his)... he said that he clears kon but leaves KON with the
old value because the DSP will read back the last value written to KON,
but internally the key on flag is cleared so that the channel doesn't
continuously get keyed on... Still, if it fixes Der Langrisser, then that's awesome! I really appreciate the help :D I'll try and direct anomie here. EDIT: Indeed, it fixes it perfectly. And breaks no other games at that. Awesome. DL is my second favorite game, and now it fully works! http://byuu.cinnamonpirate.com/audio/bs04_dl.ogg Sorry for the lowest quality setting on the ogg encoding. Thanks again for the help! |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Mon Oct 03, 2005 11:09 am Post subject: | |||||
|
|
|||||
*whispers: "Super Aleste !!"* No, really. Stage 5 must be some kind of hellcode. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||
Lurker
Joined: 07 Dec 2004
Posts: 168
| Posted: Mon Oct 03, 2005 12:41 pm Post subject: | |||||||
|
|
|||||||
OTOH, some systems don't support 32000Hz (actually, based on our tests ~32060Hz is more likely). Frequency change is actually pretty simple compared to the calculations needed to handle over or underrun.
The thing is, when you read $4C (KON) you always get back the last value written. I've just re-verified this, in case i had been mistaken, and it still holds true. Also, your code would play sound for the following sequence of writes, where the real SNES would not:
Can you show me the code in Der Langrisser that is 'fixed' by this behavior? |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 03, 2005 5:06 pm Post subject: | |||
|
|
|||
I love that game. I remember that stage, too. I think it's the one with the planets that change sizes to destroy you. Lemme guess - they're invisible? That's the way it was on zsnes last time I played it. Had to disable a few layers to pass the stage. Ahh, memories...
|
|||
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Mon Oct 03, 2005 5:19 pm Post subject: | |||||
|
|
|||||
_________________ #577451 |
|||||
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Mon Oct 03, 2005 8:29 pm Post subject: | |||||||
|
|
|||||||
RONG - that's stage 4, and neither bsnes nor zsnes have any trouble with the warped transforming green background or the growing rocks. Stage 5 is the cavern with the underground river flowing using weird-ass scrolling code. bsnes is very close to it, the effect is just off by a couple tiles on the left but always on. zsnes... well, it does it right for 2 seconds, then it stops scrolling, then it resumes... and so on. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 03, 2005 9:17 pm Post subject: | |||||
|
|
|||||
I hope DMV27 can, because I sure can't... the problem is that the code runs fine either way, it just sounds like notes are being missed / keyed off too quickly in-game. The best I can probably do... is set a breakpoint for the intro for the first $4C read, and just log a bunch of code. Then do the same with the old code, and see what comes up. Actually... now that I'm looking at it... I think I see the problem. Right now, it's an if(soft_reset)/else if(KOFF)/else if(KON){} kon=0; So kon can get cleared if a KOFF bit was set. I would imagine kon should only be cleared inside the else if(KON){...} block. Of course, if the KOFF bit were set, that would still release the channel, but after KOFF was cleared, it would then process the KON event, right? Clearing the ENDX bits was also moved inside the if(KON){...} block, but I doubt that would matter much... "Konnnnnnnnnnnnnnnn!!! ..... Konnnnnnnnnnnnnn!!"
Meh... I doubt they'd want to host a 21MB wav, and I don't mind hosting a 1mb OGG... eh. I'll look into it eventually. Thanks. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 03, 2005 10:27 pm Post subject: | |||
|
|
|||
Gruuuu... snes knowledge... failing.... |
|||
Lurker
Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA
| Posted: Mon Oct 03, 2005 10:50 pm Post subject: | |||
|
|
|||
If it's of any relevance, I'm running bsnes on a new laptop: Centrino, 2.13 gHz 1.0 GB RAM XP SP2 ATI X700 Mobility In Super Mario World, I get around 76 FPS, in Megaman X around 79. If you need any more info. like that, just PM me. _________________ I'm hot for you and you're hot for me ooka dooka dicka dee. |
|||
Lurker
Joined: 07 Dec 2004
Posts: 168
| Posted: Mon Oct 03, 2005 10:57 pm Post subject: | |||||||||
|
|
|||||||||
That could work. Or if you can get an SPC that does the same thing (for me to plug into my SPC player), that would be even better.
I've just re-verified this. Note that if the wait is less than 2 samples, the KOFF=0 could happen before the KON=1 is processed and therefore actually play a sound (there's at least one game that does this). |
|||||||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Oct 04, 2005 1:33 am Post subject: | |
|
|
|
|
Resampling
may be a necessity for Linux systems, if their hardware doesn't support
32000Hz, and if the user isn't running a transparent mixer/resampler
output, such as OSS. On the other hand, on Windows systems, you won't need to worry about that as long as the user is either running Windows NT (2000/XP/2003) or using Windows 98 SE or newer with WDM sound drivers. In that case, you get free software mixing and resampling, thanks to the kernel mixer. Ideally, you can use both SDL display and sound output, regulating your emulation to the demands of the sound callback. Then to smooth out the frame display, you also synchronize frame display to the vertical refresh. The problem with that, at least on Windows, is that the IDIRECTDRAW7::WaitForVerticalRefresh function appears to do polling in most cases, hogging the CPU a great deal. I found a nice solution which I may be able to port into SDL, so you'll get the best of both worlds without having to worry about portability issues, unless vertical refresh handling is just as bad everywhere else... Although, ultimately, native frontends with platform specialization will probably be a more optimal solution, assuming you can find porters who want to do even more work, and you'd still be stuck if they ever quit updating. I have added my speed-regulating WaveOut sound code and modified the DirectDraw video code to use multimedia timer polling and event trigger locking for the vertical refresh synchronization, since DDraw seems to be using disgusting CPU hogging busy wait polling even now. I will also add my own input configuration system, which features full key and game controller binding, with each game controller event tied to the DirectInput device instance GUID. It will require a bit of modification to work nicely with a text-based configuration file, though. I will also need to write a function to build my dialog, since it is currently a dialog template, normally built into a window at runtime with DialogBoxParam. Here you go. [binary] [source patch] [Last updated: 2005-10-03 20:28 PDT] The above noted accuracy changes have not been integrated, yet. I will wait for a version which integrates the above before making another source patch, unless my changes are integrated into the main sources. Notes:
|
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Tue Oct 04, 2005 5:54 am Post subject: | |||||||||||||
|
|
|||||||||||||
Der Langrisser SPC Soundtrack
I only traced writes to KON and KOFF. BSNES crashes on my computer, so I couldn't use it to do any code tracing.
Der Langrisser does this (also see the event log below): KOFF = 1 (wait until ENVX is zero) (wait about 42 more samples) KON = 1 KOFF = 0 Maybe the SNES allows voices stuck in RELEASE mode + BRR loop to be keyed on? Or maybe Der Langrisser requires cycle accurate DSP timing?
|
|||||||||||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Oct 04, 2005 6:50 am Post subject: | |
|
|
|
Blah
@ DirectDraw vsync. I can't get consistent synchronization results
relative to sound output. Triple buffering would solve everything, but
the limitations suck:
I'll update with a Direct3D 9 interface in a bit, and eventually work in configurable support for both renderers. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 04, 2005 11:29 am Post subject: | |
|
|
|
| Hm,
the EXE you posted tends to crackle when it drops below 60fps, but it
sounds fantastic at exactly 60fps though. Definitely a big improvement. As for the DirectInput and D3D9... the former I've been planning to get to when I have time (I don't even have a gamepad to test with), the latter I didn't feel was necessary (and requires more recent software), but if you really think triple buffering would help, I already have a library for D3D9 that provides a DDraw-like abstraction layer I could throw in. Again, many thanks for your help, but please keep in mind I am really busy this week and next (training for a new job), so I won't be able to really merge many of your changes until then... :/ Last edited by byuu on Tue Oct 04, 2005 11:30 am; edited 1 time in total |
|
Lurker
Joined: 07 Dec 2004
Posts: 168
| Posted: Tue Oct 04, 2005 12:18 pm Post subject: | |||
|
|
|||
Nifty, which track is the problem? |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Oct 04, 2005 12:48 pm Post subject: | |
|
|
|
| I
find that even with Direct3D9, I either get cracking sound, or I get a
picture that doesn't sync perfectly all of the time. There seems to be
an issue with the number of samples generated and the sound output. (
Taking a running average, with NTSC, it seems to average ~31947.3
samples per second, assuming 60 frames per second. ) Needs more work... ( PS. You should be able to delete your own posts, if you check the "Delete this post." box. If that box is not present, somebody shoot the phpBB devs for allowing regular users to edit their own posts, but not delete them. ) |
|
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Tue Oct 04, 2005 1:10 pm Post subject: | |||
|
|
|||
Regular users can't delete their own posts. It sucks. _________________ #577451 |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Tue Oct 04, 2005 6:33 pm Post subject: | |
|
|
|
| Besides, there is no "Delete this post" box. It's a nice little letter X box next to the word "EDIT." Editing/deleting posts is adjusted through the permissions by the admin(s), right ? _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 04, 2005 9:35 pm Post subject: | |||||
|
|
|||||
All of them? >_< Leon, Story, Opening 1... they all seem to be missing some of the notes in the songs. Oh, and sorry anomie. I wasn't trying to nag you to fix this, I just thought we had the right fix for it already and all... it's definitely not a priority or anything.
Yeah. The NTSC SNES runs at (315 / 88 * 6000000) / (1364 * 524 - 4) * 2 fps. Interlace is (315 / 88 * 6000000) / (1364 * 525) * 2 fps. Or ~60.09fps and ~59.98fps. The SNES APU tends to vary between 32000hz (spec) and 32100hz (realistically). anomie says he gets 32060hz. There's no way to run at 60.09 / 59.98 fps without tearing, so the only option is to resize the audio sample lengths (or change the APU speed depending on region AND interlace enable, which is extremely sloppy)... PAL then also has to be handled. That's just 50fps. The NTSC CPU is ~21477272hz, PAL CPU is ~21281370, APU is ~24576000hz. DSP is APU / 768 -> ~32000hz. All three CPU speeds tend to have slight variance in the real world. Anyway, I have no checkbox for "delete this post", and no X next to edit. So yeah... I have no rights to delete my own posts. Smart. AOL> The "delete this post" box is usually inside the edit window next to the notify on reply / disable smilies options. |
|||||
Cap'n Gin | Admin
Joined: 27 Jul 2004
Posts: 748
Location: Missouri
| Posted: Tue Oct 04, 2005 10:13 pm Post subject: | |||
|
|
|||
Yes. |
|||
Lurker
Joined: 07 Dec 2004
Posts: 168
| Posted: Tue Oct 04, 2005 11:07 pm Post subject: | |||
|
|
|||
Hrm... I can set the program to tell me when a KON is missed (15-30%!), but i can't actually hear many missing notes in the songs... |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Wed Oct 05, 2005 3:33 am Post subject: | |
|
|
|
| That's what I thought, thanks Magus`. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 07, 2005 6:03 am Post subject: | |
|
|
|
| I've
been super busy or I would've posted sooner, but I wanted to comment on
Kode's post. Basically, replace the .012 exe with the one he patched,
and bsnes will become fully playable (if your comp is fast enough)! The
fps will cap at 60fps and the sound no longer cuts out. I enjoyed some
games tonight on bsnes for the first time. Nice job on the buffering! |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sat Oct 08, 2005 12:20 pm Post subject: | |
|
|
|
| It buffered all the same before, but now it only outputs sound every frame, so it can regulate emulation by sound output more smoothly. If that's not enough, there's also vsync, so you can see how much the sound / vsync regulation needs more work... ( Adjusting the sample rate, resampling, full frame rate conversion, whatever... Hmm... ) | |
Mugwump
Joined: 30 Jul 2004
Posts: 2966
| Posted: Tue Oct 11, 2005 1:33 pm Post subject: | |
|
|
|
| Congrats on the emu, byuu. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Oct 17, 2005 8:45 am Post subject: | |||
|
|
|||
|
After playing some time in the 1024x768 mode, 4:3 is now my preferred ratio. Well, on systems that don't produce scaling artefacts. _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Oct 19, 2005 4:59 am Post subject: | |
|
|
|
| Ooo, more updates from byuu. Squashing some more bugs, I see. Did you ever figure out those "kon" issues with der langrisser btw? | |
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Oct 20, 2005 8:04 pm Post subject: | |||||
|
|
|||||
Yes, more Bsnes goodness:
Nice to see Bsnes won't compromise on accuracy. Screw the translations that depends on emulator innacuracies (my opinion) |
|||||
New Member
Joined: 13 Oct 2004
Posts: 4
| Posted: Sat Oct 22, 2005 8:13 pm Post subject: | |
|
|
|
| I
was playing with bsnes, and I noticed a somewhat minor graphical error
in Tetris Attack. As the blocks scroll, the top graphic that forms the
top border around the block area moves up with the blocks. It is more
noticable if you use L/R to make the blocks scroll up faster. It is not that important; I just thought I would mention it. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 23, 2005 5:14 am Post subject: | |
|
|
|
| Byuu said he was planning to work on PPU accuracy soon, so I'd wait for that. On another note, I hooked up my usb gamepad finally today. Couldn't get it to work in bsnes, though  |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 23, 2005 12:23 pm Post subject: | |||||||||
|
|
|||||||||
The best example I've seen to date is in the Chrono Trigger intro. The top of (Magus'?) tower has that big moon. It looks terrible at 16:15, but actually looks circular at 4:3. Langrisser's character portraits also improve a lot. They become square rather than rectangles.
Nope.
It's probably more offset-per-tile problems. Those are really getting on my nerves. I can't reproduce them myself no matter what I do, so they're difficult to fix.
No joypad support. Use a joypad -> windows key mapping program. I don't know the names of any, but they do exist. |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 23, 2005 10:06 pm Post subject: | |
|
|
|
| Ah,
sweet thanks. After some searching, I found a simple program called
JoystickCursorTool that does the job fine at under 100kb. I had to mess
with the timings a bit (changed to 15/500/15) to get my hadoukens to
work in street fighter, but all is well now. Still can't use bsnes when a friend comes over, though. |
|
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Sun Oct 23, 2005 10:33 pm Post subject: | |||
|
|
|||
Will there ever be joypad support? I tend to shy away from an emulator that doesn't do it by itself... |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 24, 2005 12:47 am Post subject: | |
|
|
|
| Sure, as soon as someone buys me a gamepad to test with. (Seriously, I don't accept donations for a hobby. Wait a month or two until I can afford to throw money away on one.) |
|
"Your thread will be crushed."
Joined: 28 Jul 2004
Posts: 1038
Location: Not in Winnipeg
| Posted: Mon Oct 24, 2005 1:23 am Post subject: | |||
|
|
|||
Just ask Lik Sang for a Super Smartjoy. Considering you are a snes emulator author, I'm sure they will give you one for free. Hell, they even gave one to me. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 24, 2005 5:43 pm Post subject: | |
|
|
|
| .013
is out! More accuracy changes, and joystick 2 is now present (thanks)!
Kode's fps capping has not made it into this version, however, so I
guess stick with .012 if you want to play games. Or just start winking
at kode for a patched exe. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 24, 2005 8:24 pm Post subject: | |
|
|
|
| No,
the new version doesn't have kode54's changes, sorry. I've been putting
a lot of work into other things (see changelog) and haven't had the
time. It'll probably be in there by the next release. GIGO shared the code he uses to buffer sound through DirectSound, so I'll probably come up with a happy medium between the two. I don't know... I'm considering rewriting the Win32 specific code, just because it's a mess. Oh, and I really need to get MSVC8 or whatever. kode's build is a good 30% faster than mine... |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Oct 24, 2005 8:31 pm Post subject: | |
|
|
|
| If you don't plan on asking Lik-Sang for the Super SmartJoy, I could order you a gamepad of your choice. Let me know. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Lurker
Joined: 17 Sep 2005
Posts: 186
| Posted: Mon Oct 24, 2005 8:32 pm Post subject: | |
|
|
|
| I'll donate you a gamepad if needed as well. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 26, 2005 12:43 pm Post subject: | |||
|
|
|||
Thanks, this is fixed now. It was due to offset per tile mode being incorrect. It'll be in the next public release. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Oct 26, 2005 5:01 pm Post subject: | |
|
|
|
| sweetsweetsweetsweetsweet Next version is gonna rock. |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Wed Oct 26, 2005 11:15 pm Post subject: | |
|
|
|
| Now all this emulator needs is zip file support. Though I can understand if that's not a priority now. It's just that when I use bsnes with my QuickPlay frontend, zip files won't work.  Excellent work on the emulator so far. |
|
Mugwump
Joined: 30 Jul 2004
Posts: 2966
| Posted: Thu Oct 27, 2005 10:26 am Post subject: | |
|
|
|
| Holy Shit... your emu really kills my pc! I have a Sempron 2800, 512mb ram, with a Radeon 9200. FFVI was only getting about 30 or 40 frames per second! Has anyone achieved full speed at any setting? | |
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Thu Oct 27, 2005 11:10 am Post subject: | |||||
|
|
|||||
Some crazy dude runs bsnes 60/60 with hq4x... on a MAC. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Thu Oct 27, 2005 12:38 pm Post subject: | |||
|
|
|||
Yep, I have, using bsnes 0.12 with my home PC using either windowed or 10x7 fullscreen (4:3) stretch. With kode54's changes, it remains at fairly steady 60fps for most games. I've yet to try the very latest bsnes at home, but on the [P4 2.4GHz+Intel Extreme2 graphics] workstation I'm on now with the 0.13 version, it achieves ~55fps with most games. I'm getting much higher numbers with FFVI (ie. 60fps or greater) with this workstation than 30-40. I would have thought that a Sempron would achieve higher numbers than this P4. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 27, 2005 12:57 pm Post subject: | |
|
|
|
| kode54's build is 20+% faster than mine because he used profile guided optimizations in his build. A feature my compiler lacks. The difference is very noticeable when your PC can't reach 60fps to begin with. Anyway, v0.014 will likely be a good bit faster than v0.013... hopefully. I'm planning to rewrite the Win32 UI and make separate builds for the debugger-enabled and non-debugger-enabled, non-virtual class versions (the latter would run faster). I also plan to add P4 + Athlon (/G7) optimizations. It'll make it run a bit slower on older processors, but hell, not like they're getting playable framerates anyway. A good 5+% there as well. I get ~50fps on a 1.67ghz Athlon, myself. |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Thu Oct 27, 2005 1:14 pm Post subject: | |||
|
|
|||
|
30 FPS on first-gen p4 1.8GHz. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Fri Oct 28, 2005 4:27 am Post subject: | |
|
|
|
| It would be nice to have an option to play at 256x240 with fullscreen. ; ) | |
Seen it all
Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box
| Posted: Fri Oct 28, 2005 4:42 am Post subject: | |||||
|
|
|||||
Most Mac's have 64 bit CPU's in em since the power pc days. Would that have anything to do with it? _________________ My boring Site |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 28, 2005 12:05 pm Post subject: | |
|
|
|
| Having a second 2.5ghz CPU dedicated to performing the HQ4x scaling and an OpenGL hardware accelerated video card to perform the bilinear filtering / TV curve effect would. | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Oct 28, 2005 1:30 pm Post subject: | |||
|
|
|||
Ugh.. your obesession with adding a resolution/feature which inheritedly limits certain games to display properly and in which case you will most likely never use is.. stupidifying... |
|||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Fri Oct 28, 2005 3:17 pm Post subject: | |||
|
|
|||
|
|||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Fri Oct 28, 2005 3:18 pm Post subject: | |||
|
|
|||
If 256x240 is the original SNES hardware resolution, I think it's a valid suggestion. This and 512x480 for hi-res games. Btw, since I bought an ArcadeVGA (www.ultimarc.com), finally I dont need to mess with a lot of unstable solutions to get a working 15khz picture. So, everything is working for me now. |
|||
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Fri Oct 28, 2005 3:37 pm Post subject: | |||||
|
|
|||||
256x224 for lowres NTSC, x238 for lowres PAL. Twice for each hires mode (Hx2 / Vx2 / Hx2+Vx2). Since games suddenly start using a hires bg layer (and all the rest still lowres - see SD3 and similar), you cannot try and adjust the res on the fly, that would just make your screen flash back and fro. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Oct 28, 2005 3:43 pm Post subject: | |
|
|
|
 It's nice to see some text look like a blur. Speaking of hires, why doesn't ZSNES take "bigger pics" (512x480) when hires is used? |
|
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Fri Oct 28, 2005 3:48 pm Post subject: | |
|
|
|
| Text blurrienss in that one is partially due to the fact that Woolsey is an idiot. | |
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Fri Oct 28, 2005 3:48 pm Post subject: | |||
|
|
|||
|
The screenshot code doesn't check for it and uses the lowres (old graphic engine) buffer. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Fri Oct 28, 2005 4:02 pm Post subject: | |||
|
|
|||
I doubt he programmed that screen or picked out the font... Unless you're talking about something else. I never had problems reading it, and my vision is terrible. So eh. PS: Hating Woolsey is not cool. |
|||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Fri Oct 28, 2005 4:06 pm Post subject: | |||||
|
|
|||||
I'll hate on him if I want to. And don't listen to Tomato, he's an elitist asshole if ever there were elitist assholes. :p |
|||||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Fri Oct 28, 2005 4:07 pm Post subject: | |||
|
|
|||
Taking NTSC as a example... A normal SNES runs at 256x240. People usually say 224 because the remaining lines are often not visible on a TV screen. 224 comes from the fact that you can usually only see about 224 lines on your TV, but the SNES is really drawing 240 lines every frame. (the same goes for any NTSC device) |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Oct 28, 2005 4:30 pm Post subject: | |||
|
|
|||
Are you actually ARGUING with the people who emulate this piece of hardware? If the SNES really rendered 240 vertical lines (with stuff on them), I imagine they'd be emulated and viewable in at least some emulators. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Fri Oct 28, 2005 4:31 pm Post subject: | |||||||
|
|
|||||||
1: So I ask... What does the screen have to do with Woolsey? 2: There's no real reason to attribute relevance to anything you have to say without contextual evidence... |
|||||||
Hazed
Joined: 10 Aug 2004
Posts: 73
| Posted: Fri Oct 28, 2005 4:46 pm Post subject: | |
|
|
|
| I
don't really wanna turn this thread into an argument about Woolsey
(which has nothing to do with bsnes) but I felt I should at least post
this link: http://smc.smallcave.net/woolsey/mcgrath.php If translating something doesn't make one a translator, then bleh :/ |
|
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Fri Oct 28, 2005 4:47 pm Post subject: | |
|
|
|
| Disclaimer: I did not mention this thread to Tomato. Just a note. | |
Hazed
Joined: 10 Aug 2004
Posts: 73
| Posted: Fri Oct 28, 2005 4:54 pm Post subject: | |
|
|
|
| Nah, I watch this thread all the time and the dev board all the time. byuu's work is awesome |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Oct 28, 2005 6:38 pm Post subject: | |||||||
|
|
|||||||
That's not even the point.. if there even was stuff rendered there and not viewable by the TV.. then why even render it? (I'm not saying it wouldn't be interesting to see what could be there, but the majority of people wouldn't want it because it wasn't what they normally saw)
He's completely lost... there's almost no hope for reasoning at this point..
Well, wouldn't it be an idea to change that to support hires? I forgot to suggest it in my reply. I wasn't trying to derail this thread further... but in any case.. it's a very different emulator.. hopefully this will lead to a more perfect emulation that we currently have... |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 28, 2005 7:02 pm Post subject: | |||||||
|
|
|||||||
|
Yes,
the SNES is 256x224. You can make it 256x239 (not x240), but the
scanlines are only visible on PAL televisions (possibly? I don't have a
PAL TV so I can't tell). On NTSC, half the scanlines get chopped from
the top and half from the bottom in this mode. I doubt many video cards support bizarre resolutions such as 512x448. Basically, I'm planning to add a custom video mode option eventually where the user can type in any resolution they want. If the hardware supports it, they can use it. The image will then use bilinear filtering to scale to either 8:7 or 4:3, and center the image for the former.
Yep. Huge problem, no easy solution.
How would you take a picture of just interlace or just hires? (256x448 or 512x224) -- keep in mind things like video filter, etc. The image sent to the card could very well be 512x224, and stretched in hardware. The image would look skewed to hell if you dumped just like that (and that's what I do). I figure, the user can just resize the image to whatever they like from there.
' 'è'ª'Æ'¤'²'´'¢'Ü'·Aƒgƒ}ƒg'³'ñ :D |
|||||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Oct 28, 2005 7:30 pm Post subject: | |||
|
|
|||
I just meant the game in hires (isn't interlace just a TV/old monitor thing?). It seems kinda pointless to take a picture that is in hires mode to only come out lowres.. (I'm not talking about printscreen and resolution, I'm talking about the internal screenshot feature in ZSNES as rendered w/o filters). In other words.. when I take a snapshot (using the snapshot feature within ZSNES and not printscreen) of a hires game (such as Secret of Mana).. I should get a picture (whatever the size it should be) that matches what I get on the screen (w/o the filters). |
|||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Sat Oct 29, 2005 4:14 pm Post subject: | |||||
|
|
|||||
I
thought that with SNES, like MegaDrive, the x224 modes are configured
with top-bottom borders to add to the total number of lines. This is
necessary to keep below the 60Hz vertical scan limit.
This is true with NES. The not viewable part is usually screen garbage. Since playing NES and SNES, with the same resolution (256x240 - using Snes9x), I get a 100% fullscreen picture on my TV, with no stretch, I thought both shared almost the same way to output video. But then, there is another question: Why fullscreen with SNES, using 256x240, with no stretch ? The same thing happens using SNES emulator for PS2: since PS2 support 256x240, you have a perfect fullscreen picture, no stretched, just like a real SNES (I know this emulator sux, but I'm just talking about the picture).
You could do something exactly like Snes9x: if the resolution is available, you can select it. Last edited by vigi_lante on Sat Oct 29, 2005 5:16 pm; edited 2 times in total |
|||||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Sat Oct 29, 2005 4:25 pm Post subject: | |
|
|
|
| More recent video cards support custom resolution input, which allows for 512x448--I was able to get 512x448 in Windows once this way. Unfortunately, however, it didn't want to let me use that resolution for ZSNES. *sigh* | |
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Sat Oct 29, 2005 6:46 pm Post subject: | |
|
|
|
| I just tried bsnes. It's looking good so far. You've come a long way byuu, congrats. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 01, 2005 4:11 am Post subject: | |||||
|
|
|||||
I guarantee it's just the video card scaling the image automatically, and selecting the next highest resolution. I've always wondered why older cards didn't allow that for gaming modes (DDraw, etc., not the Win desktop). I don't see the point, but I guess you could do that. Try with 640x479, it will either double up a line, or more likely, blur the image despite only missing one line of pixels.
Thank you, your opinion means a lot. |
|||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Tue Nov 01, 2005 2:01 pm Post subject: | |
|
|
|
| Too
bad there weren't alot of girls interested in emulation, Byuu would be
a chick magnet! He'd be getting all the girls! They'd want to try out
his Procreation Emulation techniques! _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Nov 01, 2005 4:52 pm Post subject: | |
|
|
|
| Maybe he already HAS a girl, who DOES dig his l33t skillz. Hey byuu, get your girlfriend to sign up on the board! _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Wed Nov 02, 2005 12:03 am Post subject: | |
|
|
|
| ArcadeVGA does (true) 512x448. I think the best way would do something like Snake did with Kega Fusion... http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=40418&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1121281319 You just write what kind of resolution you want to use for each game that have a specific resolution, and it will automatically change your resolution, according to what the game displays. And the resolution change process also is very smooth. By the way, the vertical x224 resolution of SNES output signal are actually still 240 lines, with blank borders which make up the difference from, for example 224 lines to 240. This is because TVs cannot display resolutions lower than 240 lines. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Nov 02, 2005 1:57 am Post subject: | |
|
|
|
| I'm confused by this whole resolution thing. If the higher one were to be implimented, and it were stretched to fill a 4:3 screen, would we then have black bars around the whole image? Or is there actual picture data that bsnes could gain from this "more accurate" res? | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Nov 02, 2005 2:35 am Post subject: | |
|
|
|
| No,
not around the whole thing. Just on the top and bottom. Apparently, the
difference is (240-224)=16. So, I assume 16 split between the top and
bottom, so a whopping total of 8 lines above and below the image. Apparently some PAL games have output on 15 of those 16 lines? I get the sense that there would be no additional output for any NTSC games. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Wed Nov 02, 2005 9:43 am Post subject: | |||||
|
|
|||||
This is the last thing I'll say to you, since you're camping on your stupid. ANALOG STRETCH Moron. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed Nov 02, 2005 2:10 pm Post subject: | |||
|
|
|||
|
A took a look at what wikipedia has to say http://en.wikipedia.org/wiki/Super_Famicom I guess this is more or less correct:
In any case, I don't seem to understand vigi_lante's obsession with his "info" especially when even as little I know about TVs.. I know they stretch the image.. for sure on my REAL SNES (which, perhaps vigi_lante has never owned one). |
|||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Wed Nov 02, 2005 6:55 pm Post subject: | |
|
|
|
| Of
course SNES stretch the picture, that's because SNES resolution is not
4:3. But the aspect ratio would still be correct, since developers made
their games thinking about that. What I'm saying is that doesnt matter if you run with 256x224 or x240 because in the end you gonna still have the samething. And it's not necessary to be so rude. I'm treating everyone with respect. If you cant control yourself, just ignore me. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed Nov 02, 2005 8:07 pm Post subject: | |||
|
|
|||
I wouldn't be testing grinvader.. he has control - ignoring you to him could just be a ban for all that matters. You might want to rethink that. |
|||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Wed Nov 02, 2005 10:11 pm Post subject: | |
|
|
|
| At this point, I dont care... Everytime I post something, that "Aerdan" appears, saying "shut the fuck up, it's stupid etc" (at least he deleted a post on kode54 topic). But this kind of people I just ignore, it's not even worth... "grinvader", in contrast, looks a nice person. That's why I didnt expected this from him. But, if things here are really like this. It would be a favour for both of us. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed Nov 02, 2005 10:49 pm Post subject: | |||||
|
|
|||||
Well, one important factor is that Aerdan is a dev.
I'm just pretty annoyed that for the majority of your posts are in the same direction. Let me show what you are posting: "Please, add these resolutions that are not part of the the SNES resolutions." 256x240 doesn't make sense, since the minimum SNES res is 256x224, which is already implemented in the major SNES emulators. "Please, add the option to select color depth." This is not really important to the functionality of the emulator, since the requirement is at least 16-bit color depth (for transparancies). "Please implement specific feature so my 3rd party application will work properly/better" It is always up to the devs to want to do. Frankly it is not of particular importance to implement something for another app unless the dev has a stake in that application. (In other words, if a dev preferred using that app, he would assist in coding ZSNES or whatever emu to make it work for that app). Well people AND the DEVS tell you that your feature is NOT important/useful/a priority/whatever, and continue this track of mind when posting to the other emu authors (especially on this board), you're going to be flamed. If you stop this track of mind, perhaps people wouldn't go out of their way to tell you to shut up. I'm being nice to you about this. Just consider what I'm talking about. |
|||||
Hazed
Joined: 15 Nov 2004
Posts: 65
| Posted: Thu Nov 03, 2005 12:00 am Post subject: | |||
|
|
|||
Those things were just suggestions. There is a forum just for this, you can't expect to agree with all suggestions.
Today, the only way you can play a emulator on your TV, with a picture just like the real SNES, is through a video card called ArcadeVGA. It's becoming widespread, a few developers already support it, so I thought it would be nice to suggest an option to select 256x240, since people here are concerned about emulation accuracy, maybe "picture accuracy" would be a good idea. By the way, 256x240 is a built resolution for ArcadeVGA, so you cant use it with 256x224. Actually, it's not something I really really want. I just suggested this because I saw a few people asking if it was possible to use ZSNES with ArcadeVGA, for example. Right now I'm using Snes9x, and I can't tell the difference between ZSNES. The only problem I have with Snes9x is because I cant use it with Mamewah front-end. That's all. It was just a suggestion. You guys are making a scandal for nothing. Last edited by vigi_lante on Thu Nov 03, 2005 12:08 am; edited 3 times in total |
|||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Thu Nov 03, 2005 12:04 am Post subject: | |
|
|
|
| Deathlike2, quit feeding the troll. vigi_lante: Go to jail. Go directly to jail. Do not pass Go, do not collect $200. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Nov 03, 2005 1:04 am Post subject: | |
|
|
|
| Now, don't go and start fighting again and getting a good thread locked. Major changes shouldn't even be requested at this point anyway. | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Nov 03, 2005 1:30 am Post subject: | |||||
|
|
|||||
I'll just play the ignorance is bliss card. It's not worth seeing what he says.
Yea.. especially when a game like Castlevania: Dracula X has so many issues with BSNES that it needs work... like transparacy, proper layering syncing sound, less sound garbage.. it would be great But in seriousness, it is something to watch as it develops. |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Nov 03, 2005 1:35 am Post subject: | |||
|
|
|||
I can use the S-Video out on my laptop. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Regular
Joined: 30 Jul 2004
Posts: 229
| Posted: Thu Nov 03, 2005 2:06 am Post subject: | |||||
|
|
|||||
That's not the same though. That's whatever your computer resolution is processed through a TV encoder chip. The ArcadeVGA actually recreates the exact resolution/refresh used by older consoles and arcade boards. This is what it was designed for. So yes, you can use TV out to get emulated SNES on TV, but it's not exactly the same as the SNES. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 03, 2005 2:12 am Post subject: | |||
|
|
|||
I'm not aware of transparency or layering problems in this game. The sound problems have been explained a few times. When I can actually get a solid 60fps to test with, I'll merge kode54's changes to bsnes. Edit: Well, nevermind. Yeah, the first level... huh. I'll look into it. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Nov 03, 2005 10:46 pm Post subject: | |||
|
|
|||
I'm looking forward to a new release, especially knowing the following:
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Fri Nov 04, 2005 4:31 am Post subject: | |
|
|
|
| Might as well give this thread sticky status. |
|
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Fri Nov 04, 2005 5:26 am Post subject: | |
|
|
|
| Why not just spawn a new thread and sticky that instead? This thread's been full of stupid lately, thanks to the undying efforts of vigi_lante to get his retarded-ass TV-out adapter supported. |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Fri Nov 04, 2005 6:07 am Post subject: | |
|
|
|
| should
have mentioned something. i could have sent you a copy of visual
studio. my university gives it away for free. oddly enough, it's a
self-extracting zip. _________________  |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 06, 2005 5:59 pm Post subject: | |
|
|
|
| Just curious, are game specific hacks prudent for copy protected games? Or is there some hardware accurate way to handle these? | |
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Mon Nov 07, 2005 10:53 am Post subject: | |||
|
|
|||
|
There's always a hardware-accurate way to handle everything. That's the point of emulation. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 07, 2005 6:49 pm Post subject: | |
|
|
|
| I
guess I don't understand how copy protection works on snes games. The
snes hardware didn't have any protection, right? And how many roms do
this? All I remember are: Megaman x3? Star Trek Deep Space Nine Demon's Crest? They must do some kind of self-diagnostic to make sure it's a cart and not a rom. Whatever it is, it sounds wierd. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Nov 07, 2005 6:50 pm Post subject: | |
|
|
|
| iirc Megaman X v1.0 has copy protection in it. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Dark Wind
Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
| Posted: Mon Nov 07, 2005 7:02 pm Post subject: | |||
|
|
|||
As long as you emulate it accurately enough, there will be no problems. The trick is to figure out how the copy protection works. _________________ #577451 |
|||
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Mon Nov 07, 2005 7:58 pm Post subject: | |||||||||
|
|
|||||||||
Yeah. It's not a diagnostic. It has to do with how the snes sees a ROM. Mainly mirroring. Let's say you have 24 slots available, but it only fills 16, like this:
Now what happens in the real snes ? It wraps and restarts from a certain point:
Now make your game read A-H from the late area instead of the first area whenever you want... If the emulator doesn't emulate the mirroring, it will not return the correct value. So make your game react accordingly, like reset (mmx 1.1), make a boss invincible (aladdin, demon's crest), or other stuff. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Nov 09, 2005 3:12 am Post subject: | |||
|
|
|||
I'm greatly looking forward to v0.014.
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Nov 09, 2005 1:43 pm Post subject: | |||||||
|
|
|||||||
What if the desktop runs at 100/120 Hz? Would that help anything?
Me too. _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Wed Nov 09, 2005 5:48 pm; edited 1 time in total |
|||||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Wed Nov 09, 2005 4:00 pm Post subject: | |
|
|
|
| Yeah, running at 100/120Hz would help preserve your eyes much longer _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Nov 12, 2005 10:25 pm Post subject: | |||
|
|
|||
I'll beat everyone to it this time.
Get it here. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 13, 2005 12:18 am Post subject: | |
|
|
|
| Awesome
work, byuu and contributers. I'd be really excited right now, however
the audio for me is crackling badly, not at all like the old kode54
patch which seemed to work fine. Not sure what's happening, but is
anyone else getting this? I'm going to guess this is happening because of my fps, which shows 45-55 on every game I've tried and never 60. This makes no sense though, because when I turn off regulation, it goes up to 80-100. So it's not as though my computer is too slow... |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Nov 13, 2005 12:37 am Post subject: | |
|
|
|
| If you're getting below 60fps, then you may as well turn the sound off. It will sound horrible. It sounds like your sound card drivers are fucked. I've tested on three computers, and for whatever reason, its faster with the regulation on. Don't ask me why, but it's definitely not half the speed. Are you sure vsync isn't on? Hmm... are you on Win2k or above? Win9x without WDM sound drivers might not handle 32khz audio resampling... that could be the problem. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 13, 2005 1:33 am Post subject: | |
|
|
|
| Well, here are my specs: Intel 2.4c (northwood with HT) Windows XP SP2 slipstreamed (fairly new reformat) ati 9600xt catalyst 5.9 Egosys Juli@ sound card, latest drivers. My sound card and its drivers are awesome (500kb total package. Bloat free and nary an issue with anything). I run scores of different emus and apps without problems. And kode's old .012 build ran at 60fps without any audio abnomolies whatsoever. I did do some more troubleshooting, however, and seem to have hit something important. My sound card's control panel has latency settings that you can change from default. It's a list that looks like this: 48 sample 64 sample 128 sample 256 sample (default) 512 sample 1024 sample 2048 sample I was messing with those and found that doing so changed the frequency with which the crackling occured. 128 reduced the anomoly, 64 reduced it even more (crackling in equal intervals of 5 seconds), and 48 sample removed the cracking completely (awesome, now I can enjoy .014!). Increasing from 256 did the opposite and made the fps even lower. So you were right, the problem was on my end and rectifiable. And using the 48 sample seems to be working on all my other apps just the same. I guess the question now is, why does bsnes mess up at anything higher than that where other programs do not? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Nov 13, 2005 1:54 am Post subject: | |
|
|
|
| I've no idea... I've never heard of your sound card before. It's pretty much Creative or Santa Cruz here, or onboard AC'97 / Digital MAX. My sound buffer is relatively small, 8 frames worth of audio. I made it so short to prevent the sound from being TOO bad when its running too slow or too fast. The more samples, the more echo / repeat there is. I only really need three for the ring buffer effect. If anyone wants to shed some light on this issue, please do. And since this is the "official bsnes" thread... help with Dracula X would be nice, too, if anyone is familiar with emulation of the game. That game is just... weird. It has to be a CPU bug or something. The flame is on BG1 priority 1 with BG3 priority bit set and main screen with no color window clipping, so it can't possibly be behind BG1/2 as it is in other emus... |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Nov 13, 2005 2:13 am Post subject: | |||
|
|
|||
The most promising emu just keeps on getting better.
I don't experience any cracking with the sound. Here's my result on average: - 40fps with no frameskip. - Can achieve constant fullspeed 60fps (20frame) with 2 frameskip while getting clear audio. (speed regulation on) Specs: P4 (don't really know which generation) at 2.4ghz running on XP. (Btw, not that it matters much: Bsnes crashes on startup on windows98.I have a dual booting system) Last edited by Dmog on Sun Nov 13, 2005 2:24 am; edited 2 times in total |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Nov 13, 2005 2:22 am Post subject: | |
|
|
|
| The
hell... you must have other programs sapping your CPU power. I've only
got a 1.67ghz and easily manage 60fps in nearly all games with zero
frameskipping. Only Star Ocean manages to drop below 60 to about 56fps,
probably due to the S-DD1 among other things. Fitz' 2.4ghz is pushing 80+ fps, D-BOYs mobile 2ghz is pushing 80-100fps. Don't know how to fix it for Win98, but lord is that OS old... You might try turning off the speed regulation under settings, if it jumps up to 80+fps, then I clearly have a problem here that needs to be fixed :/ |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Nov 13, 2005 2:46 am Post subject: | |||
|
|
|||
edit: *Disregard* everything below. My results aren't constant. The cause probably comes from my end rather than being caused by Bsnes. [disregard]Just done some more testing: It seem with Video surface Off I get 30fps (0-fskip, no speed reg) With Video Surface On I get 100-110fps (again, 0-fskip no speed reg)(I made the change between On-Off then restarted B. Just to be sure.) Weird thing is: With Vid surface off, it start at 100fps, then it progressively drops to 30fps in a matter of seconds. I'm going to do a reboot. Just to confirm.[/disregard] Last edited by Dmog on Sun Nov 13, 2005 3:13 am; edited 1 time in total |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 13, 2005 2:50 am Post subject: | |
|
|
|
| Yeah,
I'm not surprised you haven't heard of it. It's one of those audiophile
cards with higher end DACs. Not terribly common because you need really
nice speakers/headphones to take advantage difference (and they're not
usually marketed to gamers even though they work with such just fine). I should have also said that lowering the sample to 48 did not just clear up the crackle, it improved the fps as well to a steady 60 (which, in effect, cleared up the crackle...) So I wasn't getting 45-55 with no crackle. Carry on. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Nov 13, 2005 3:21 am Post subject: | |||
|
|
|||
It's cool, I appreciate the feedback. Video memory surface on makes things a lot faster on most systems, but some systems throw a fit when I transfer the rendered image directly to VRAM. If things run faster with video memory surface off, then you definitely want to use 256x224 windowed mode. The video surface will perform hardware scaling to the window size, but the system surface will not. Hence, you're transferring a lot more data. You have no choice but to use a video surface for 32bpp desktops, as that does auto 16bpp->32bpp upgrading (which halves the data needed to be transferred to the card). |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Nov 13, 2005 3:22 am Post subject: | |
|
|
|
| (Edited my previous post) Btw I notice that when I delete Bsnes's folder and re-extract it somewhere else it still remembers the last rom folder (in my case D:\emulation\snesroms). Does Bsnes adds a key to the registry? (not that I would care about a harmless registy change) |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Sun Nov 13, 2005 3:51 am Post subject: | |
|
|
|
| I find that v0.14 works perfectly, and at fullspeed (at least on my laptop). Only really major bugs I noticed were with the MK series: Mortal Kombat (U) - flashing static when in-game Mortal Kombat II (U) - music is messed up Mortal Kombat 3 (U) - music is messed up Ultimate Mortal Kombat 3 (U) - music is messed up _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
I know where you live.
Joined: 19 Aug 2004
Posts: 744
| Posted: Sun Nov 13, 2005 7:28 am Post subject: | |
|
|
|
| Decided
to give bsnes a stab on a lower-end computer, this is what I got. I'm
honestly not sure how much input you have on these sorts, so forgive me
if this is redundant. Processor: 800Mhz P3 RAM: 256 MB Video Card: GeForce 4 Ti4200 Game: Romance of the Three Kingdoms 4, Wall of Fire. Completely unplayable on these specs. WIth or without limit speed, I get 25-30 FPS (sound gets muted, obviously). I'll try it on my better computer back at my apartment tomorrow and update. _________________ FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that. phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin. I smell spray paint. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Nov 13, 2005 5:41 pm Post subject: | |||
|
|
|||
That's funny. ZSNES used to have all those problems but were fixed. Well except for MK, ZSNES uses a hack around that. pagefault has been working on removing the MK hack recently but it seems to be breaking other stuff. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
New Member
Joined: 13 Oct 2004
Posts: 4
| Posted: Sun Nov 13, 2005 8:33 pm Post subject: | |||
|
|
|||
|
In
kode54's previous build of bsnes, I was able to get 60fps sustained in
Tetris Attack (of course, this was with the drawing error at the top) In the new version, the FPS is fine until I get to the area where the drawing error occured in the previous version, and I start getting like 51 FPS... I guess this is a side-effect of
? I have a P4 3ghz and can get 60fps on every single other game I try. Actally, it seems that the titlescreen of Chrono Trigger (where the wavy "Trigger" text scrolls over from the right) takes me down to 55fps, whereas with kode's build I would keep 60fps. Is this also affected by the new code? |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 13, 2005 10:22 pm Post subject: | |
|
|
|
| I just checked and the same thing happens to me, taezou. The emu slows down to ~50fps the instant that text starts scrolling (and the sound starts crackling because of it). There seems to be an issue here as we both have very fast computers and this particular render is making the fps dive. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sun Nov 13, 2005 11:24 pm Post subject: | |
|
|
|
| FitzRoy,
have you been able to get JoystickCursorTool to work with the latest
bSNES? It's no longer working for me. Perhaps the changes about
keyboard input makes JoystickCursorTool not work... _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Sun Nov 13, 2005 11:37 pm Post subject: | |
|
|
|
| The
Trigger text slows my framerate down from 123fps to 67fps when it
appears onscreen on my laptop, so with regulate speed on I don't
experience a slowdown. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 14, 2005 12:04 am Post subject: | |
|
|
|
| Hmm... I didn't run the PGO against any games that use offset-per-tile mode, so that's probably why. Sorry, I'll fix it in the next release. I noticed the CT slowdown, too. It's quite interesting. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 14, 2005 3:20 am Post subject: | |||||
|
|
|||||
Yeah, it still works for me. I dunno what could be wrong for you... You know how to use it right? You bind to the keyboard in bsnes, and then use the program to bind keyboard keys to the joystick. Maybe mess with the timings?
Awesome. And while I'm posting, I've noticed one bug that hasn't been mentioned - Super Double Dragon (U) - doesn't work at all. |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Nov 14, 2005 3:56 am Post subject: | |||
|
|
|||
Yeah, it was working for me in 0.013. I'll reconfigure everything and try again. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
New Member
Joined: 08 Sep 2005
Posts: 6
| Posted: Mon Nov 14, 2005 4:54 pm Post subject: | |
|
|
|
| Hmmm.... The game from the following thread doesn't seem to work past the start screen. http://board.zsnes.com/phpBB2/viewtopic.php?t=5407 |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Nov 14, 2005 6:01 pm Post subject: | |
|
|
|
| It may be a special-chip game that is not (yet?) emulated in bsnes. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 14, 2005 6:50 pm Post subject: | |
|
|
|
| Rendering Ranger R2 isn't a special chip game, but it is one of those "special timing" games. It was broken in zsnes for a really long time as I recall. Super Double Dragon is more of a mystery. I always thought that was one of the earlier games for the system. I guess it does something wierd as well. | |
I know where you live.
Joined: 19 Aug 2004
Posts: 744
| Posted: Mon Nov 14, 2005 11:13 pm Post subject: | |
|
|
|
| OK,
I tried it out on my newer computer; the extra guts did indeed fix the
framerate problem. (Athlon XP 2500+, Radeon 9700 PRO, nForce2
integrated sound) I have two bugs to report. 1) Really fucking weird; the Y button appears to be nonfunctional in Romance of the Three Kingdoms 4, Wall of Fire. On creating a ruler, the Y button is used to deduct 10 stat points from a certain area; it completely fails to register. I know the button is mapped correctly, because I immediately loaded up Megaman 7, and I could fire just fine. 2) As a direct result of 1, I realized that MM7's sound crackles even when the framerate is at a constant 60. I'll continue to look into this to see if it could be my end. _________________ FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that. phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin. I smell spray paint. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 15, 2005 12:25 am Post subject: | |
|
|
|
| 1
does indeed sound weird. This is another good game to try and track
down the bug in -- the NMI is likely what reads the joypad polling, so
a possible CPU bug might exist here. I do not experience 2. MM7's graphics aren't the most intensive I've seen, but with a frameskip of 1 on my 1.4ghz laptop, I experience no sound breakup. Another thing to try is the capture audio data option. If you're positive you're maintaining a full framerate (60fps for 9 of 10 frames, 61fps for the other), then the audioNNN.wav file will almost definitely have crackling in it too (emulation problem), otherwise it's your sound card. I may as well add my own bug reports here, too. Right now, a lot of games sometimes miss single short sound samples. I believe this is due to me using DMV27's KON register changes. Zelda 3's intro (the part where its raining outside) will miss certain song notes when Link's sword is charging and released), for example. Some games don't work due to my simplistic header detection. Star Trek: Deep Sleep Nine is one such game. Some will fail due to using non-standard memory mapping. Y's 3 SRAM is likely one such game. The regulate speed option does not return idle CPU time back to the system, so bsnes always consumes 99% of speed. I tried adding Sleep(1) into the speed regulation loop (I realize it takes longer than 1ms to return), but it causes the emu to drop below 60fps even when there are no other non-system processes running, no matter what. Ideas welcome here. SPC700 ADDW/SUBW opcodes set the flags wrong. Someone mentioned this to me, but I can't fix it with their explanation of what was wrong. I need really detailed info on what I'm doing wrong to correct it. |
|
I know where you live.
Joined: 19 Aug 2004
Posts: 744
| Posted: Tue Nov 15, 2005 3:10 am Post subject: | |
|
|
|
| Yeah,
after a few different tests, I'm somewhat sure that it's my sound
hardware that's to fault for 2. I get it even through a frameskip of 1,
but my headphones make a similar crackling noise when I throw them
through a Goldwave sample I found for testing them. _________________ FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that. phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin. I smell spray paint. |
|
Lurker
Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA
| Posted: Tue Nov 15, 2005 3:23 am Post subject: | |
|
|
|
| Question byuu, do you have a bugtracker to keep track of the reports you're getting here? As an aside, I was also getting crackling with bsnes 0.014 (my laptop was able to run bsnes >100 FPS prior so it wasn't a speed issue). I messed with my sound card's sampling rate, which changed the results but didn't rid the crackiling. The audio log in bsnes came out fine too. Then I updated my card's drivers and voila, problem solved. I like emulators that force me to fix my own computer's faults to get things working right. Great work byuu. _________________ I'm hot for you and you're hot for me ooka dooka dicka dee. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 15, 2005 4:42 am Post subject: | |||||
|
|
|||||
No, I really don't have time to set up and maintain these things. A message board wouldn't hurt either, but this thread seems to be working fine anyway.
Thanks. Since everyone can get working sound after fiddling, I'm going to pass it off as a systems-issue and not worry about it, then. Win9x users... sorry, the OS is almost (and in some cases, is) a decade old. I'm not supporting OS/2 and RedHat 3 (please don't argue on date semantics), so I'm not supporting 9x, regardless of userbase. If someone else wants to fix it, awesome -- I'll merge the changes. Ok, I just got done merging Nach's gzip, zip, and jma support, and added my own stuff to it to make it a compile-time option. JMA is broken, as msvc is complaining about undefined virtual inline functions. I'll talk to Nach when we're both awake. I also can't test gzip, but see absolutely no reason why it shouldn't work. Thanks again, Nach. Now to bug him about DSP and C4 support... hehe. Edit: JMA makefile wasn't linking against winout.cpp's object file. Now I'm damn curious how Nach managed to compile this, but anyway -- here's the log for Nach when he gets on: http://byuu.cinnamonpirate.com/temp/jma_errors.txt Last edited by byuu on Tue Nov 15, 2005 5:17 am; edited 1 time in total |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Nov 15, 2005 5:00 am Post subject: | |||
|
|
|||
Freakin' sweet! _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Tue Nov 15, 2005 5:33 am Post subject: | |||||
|
|
|||||
|
|||||
Lurker
Joined: 06 Aug 2004
Posts: 166
| Posted: Tue Nov 15, 2005 6:31 am Post subject: | |
|
|
|
| I tested a couple of games with lots of digitized sounds (I think). On one hand, Mortal Kombat II sounds atrocious and hurt my ears really bad ...but on the other hand, Donkey Kong Country 2 sounds pretty freaking rad!! In-fact the sound is really awesome in bsnes... good job! |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Nov 15, 2005 3:09 pm Post subject: | |||||||
|
|
|||||||
No problem with me :-P I agree win9x is terribly old and outdated. I mainly keep a dual boot XP/98 system because there are a few apps that just doesn't run properly on XP. Running Bsnes on XP or 98 makes no difference for me. |
|||||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Tue Nov 15, 2005 4:06 pm Post subject: | |
|
|
|
| I'd
dedicate a part of my board to you byuusan, but, as you all have
probably seen, my board won't install on PHP 5.x.x >.> _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Nov 15, 2005 4:13 pm Post subject: | |||
|
|
|||
I see every reason why it shouldn't work, you completely killed it several times over  As for bsnes board. It would have to be _Demo_'s decision wether we do that here, this is his server, and it's up to him what projects he wants to support on it. However I have no problem making a bsnes section on my forum. Although if if byuu has the server power and the throughput required, I don't see why he can't just install some decent BB software on his own server. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Tue Nov 15, 2005 6:03 pm Post subject: | |
|
|
|
| bsnes already has a forum on my board, so... | |
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Thu Nov 17, 2005 11:33 pm Post subject: | |
|
|
|
| Finally
got home and tested bsnes with my CRT and the colour curve option. In
short: colours look pretty much identical to how it looks on a real TV.
Great job with that. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 17, 2005 11:49 pm Post subject: | |
|
|
|
| I can't take credit for the color curve. Thank Overload for that. However, I am planning to add a special filter mode for (pseudo-)hires games to more closely match how they look on hardware, specifically due to color bleeding. On the subject of color effects... I know how to convert an RGB color to grayscale, but does anyone know how to convert the grayscale color to other tones, such as sepia, or maybe a gameboy monochrome look? I want to add those to my special color filters list. |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Fri Nov 18, 2005 2:16 am Post subject: | |
|
|
|
| HSB or YUV is probably a more natural representation of color for the types of transformations that you're describing. http://en.wikipedia.org/wiki/Color_space |
|
Lurker
Joined: 04 Sep 2004
Posts: 193
Location: USA
| Posted: Sat Nov 19, 2005 5:34 am Post subject: | |
|
|
|
| BTW
byuu, when will the news of this release make it to the major emulation
news sites? I don't mean to be pushy, but I still haven't figured out
why my computer can't correctly download bsnes from your site. _________________ This signature intentionally contains no text other than this sentence. |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Sat Nov 19, 2005 12:48 pm Post subject: | |||
|
|
|||
The latest bsnes is mirrored at Emulation64 as always: http://www.emulation64.com/files/info/489/ _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Nov 21, 2005 1:43 am Post subject: | |
|
|
|
| byuusan: If you still need a forum, I've got one: http://linksadventure.no-ip.org/phpbb2/viewforum.php?f=8 _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Nov 21, 2005 8:33 am Post subject: | |||||
|
|
|||||
What about AEP? _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 21, 2005 1:20 pm Post subject: | |
|
|
|
| I
appreciate the forum requests. I don't have SQL access, and I don't
want to consume a lot of bandwidth is why I don't stick phpBB or
whatever on my site. Anyway, I'll worry more about it later. I still don't know what's wrong with my host's downloads, and I probably never will :/ I've never once had a problem with it myself, either. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 21, 2005 5:50 pm Post subject: | |
|
|
|
| Fixed mosaic, tile mode pgo, better header detection.... nice. And Mega Man x2 and x3 will be supported in the next version! .015 - keepin the dream alive! |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Nov 21, 2005 5:54 pm Post subject: | |||
|
|
|||
Well, for some reason I can't seem to get op 0 subop 5 to work right, everything else works though. Although that one op is only used in X2 intro AFAIK. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Lurker
Joined: 06 Aug 2004
Posts: 166
| Posted: Mon Nov 21, 2005 6:17 pm Post subject: | |||
|
|
|||
It's kind of ridiculous that your host wont give you access to your SQL Server and Database, for your site If you ever do get SQL access, and if you're into the whole M$ thing (i.e. Visual Studio / SQL / .NET / .ASP)... then I recommend DotNetNuke for your Forums/Website! http://www.dotnetnuke.com DotNetNuke is an Open Source Framework ideal for creating and maintaining professional Web Applications. I have been playing with it lately, and I kind of like it. With DotNetNuke 4.0, you can install the "Starter Kit" with a Visual Studio 2005 .VSI file. Your host does have to have .ASP2 and .NET2 to run 4.0 though (SQL 2005 is also preferred) Kick your host in the ass, and give bsnes a better home !! I can't wait until you release the next version! |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Nov 21, 2005 6:45 pm Post subject: | |||||
|
|
|||||
His server is not running on Microsoft software, he's running Linux 2.4. Apache httpd 1.3.33 ((Unix) mod_ssl/2.8.22 OpenSSL/0.9.7e) MySQL 4.1.13-standard Sendmail 8.12.11/8.12.11 OpenSSH 3.6.1p2 (protocol 2.0) Now they do have MySQL, but I guess byuu doesn't want to pay the extra fee to use it (or convince his friend as the case may be). _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding Last edited by Nach on Mon Nov 21, 2005 10:32 pm; edited 1 time in total |
|||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Nov 21, 2005 6:57 pm Post subject: | |
|
|
|
| Nach: I use Apache 2.0.54 for the HTTPd. I use MySQL 4.x, since I've been familiar with it for some time. The OS is kubuntu Linux 5.1. And LDAWG: Remember this: REAL men host their own servers.  I think I oughta add that as another sig quote... _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Lurker
Joined: 06 Aug 2004
Posts: 166
| Posted: Mon Nov 21, 2005 7:59 pm Post subject: | |||
|
|
|||
That's not a very nice thing to say about byuu
|
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Nov 21, 2005 8:53 pm Post subject: | |
|
|
|
| I
made that post not paying to attention about anything, I assumed Nach
and you were discussing my server, and when I finally looked at it, it
made the post even more useless than it originally was... _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Nov 21, 2005 10:16 pm Post subject: | |||
|
|
|||
If I was discussing your server I would have said you're running: Apache httpd 2.0.54 ((Ubuntu) PHP/5.0.5-2ubuntu1 mod_perl/2.0.1 Perl/v5.8.7) Postfix smtpd OpenSSH 4.1p1 Debian-7ubuntu4 (protocol 2.0) Unreal ircd And other stuff. You also don't seem to have rebooted since Tue Nov 15 18:03:59 2005. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Tue Nov 22, 2005 1:36 am Post subject: | |
|
|
|
| How do you know about my computer Nach Tell me, please _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 22, 2005 5:53 am Post subject: | |||
|
|
|||
...and even that's working now, whee. I must admit, the C4 can do some pretty cool stuff. It would be nice to emulate the opcodes that the MMX games don't use. I can only imagine what the other ops do, and what kind of cool demo ROMs could be produced. Not sure how I feel about the emulation quality, though. Code isn't bit-accurate and is quite... messy, to say the least. Not that I could've done any better. I'd love to get my hands on a rig to run my own tests on that chip. And hell, all of the chips for that matter... |
|||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Tue Nov 22, 2005 9:06 am Post subject: | |||||
|
|
|||||
http://rapidshare.de/files/7982508/bsnes_win9x.zip.html bsnes.exe is compiled with mingw/gcc 3.4.4 ui_memory.patch contains the one line win9x fix. src_win.patch contains the win9x fix plus some other fixes (mostly DirectSound, some fixes for mingw/gcc). Some other things that need to be fixed: Classes with virtual functions should have virtual dtors The Der Langrisser sound fix should use 'kon' instead of 'KON' to match anomie's tests 65816 BCD math (check SimEarth; Snes9x is correct in cpumacro.h) bMemBus::read uses a static variable bDsp::run doesn't use noise_sample properly (uint15 -> int32; check the Dual Orb 2 opening). The code should be
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 22, 2005 2:01 pm Post subject: | |||||||||||||
|
|
|||||||||||||
I had this like this for a reason. First, I want to change the frequency. For a slowdown key, I need only swap the frequency to 16000hz, for a speedup key, 48000hz. Maybe 64000hz since Win9x+WDM/Win2k+ will remix it anyway, since I doubt many cards can handle that sampling rate. And the benefit there is that the audio is still crisp. The buffer needs to be in software, because older cards have problem with accuracy when getting the buffer playback position. I also don't know why you define and undefine my dsbufferdesc variable. Why can't it be in the body of the DSSound class?
I was wondering why I needed to delete classes through static casts to the derived class type to call the right dtors, thanks.
And yet with 'kon', it breaks DL. I'll change it back when we find out why that is.
Mine came from there. What did I copy wrong?
For? And why is this a problem?
Neat, thanks. Appreciated as always, I'll add your fixes when I get home tonight. |
|||||||||||||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Tue Nov 22, 2005 9:00 pm Post subject: | |||||||||||||||||||
|
|
|||||||||||||||||||
I tend to over-optimize sometimes, so you can just ignore most of the DSSound changes (except the ctor, that is needed).
I meant that you should still use the fix, but just change the 'KON' to 'kon' so that the KON register bits don't get cleared.
You only check for decimal overflow after doing an 8/16-bit add/sub, but for proper BCD math you need to add/sub and check for every 4-bits. For example, your code does not pass this test:
It uses 'static uint32 r' for the return value, but it should be 'uint8 r'. It's not a problem, just a very minor optimization. |
|||||||||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Nov 23, 2005 3:16 am Post subject: | |||||||||||||
|
|
|||||||||||||
Wasn't that the exact thing that was causing the problem before? What should I change here?
And how about on KON register read/write?
That seems to be exactly what I'm doing... what exact spot is failing in SimEarth?
Alright then, I'll take a look at it. I have a habit of using static on classes that don't need to be ctor/dtor'ed on each function call, so I do that to variables needlessly sometimes. I guess that prevents the variable from being a register or whatever, then...
Is there something wrong with the clip function? I know it isn't as fast, but the functionality should be identical. I use clip because it makes it clearer whats happening when you clip at different bit sizes. |
|||||||||||||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Wed Nov 23, 2005 6:38 am Post subject: | |||||||||||||||||
|
|
|||||||||||||||||
The problem was being caused by 'status.kon = 0' and not by the use of the kon variable. My fix took care of that problem, but it also wrongly used KON instead of kon. Here is the correct patch:
This: The numbers in this picture are completely wrong. They should be 3,000,250,000Ys. and 50/3000. The problem is that you check for decimal overflow after a 8/16-bit add/sub, but you need to individually check after each 4-bit add/sub. Taking your op_adc_w as an example, if regs.a.w = 0x09 rd.w = 0x07 regs.p.c = 0 regs.p.d = 1 then r = 0x10. After your BCD math checks, r will still be equal to 0x10, but the correct result would be 0x16. 9+7 is 16, not 10.
It's just an optimization. |
|||||||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Nov 23, 2005 6:53 am Post subject: | |||||
|
|
|||||
Yeah, after actually looking at it for five minutes I figured it out :/ I did some tests and if either the ENDX mask or KON clear is outside of the } else if(status.kon) { part, it will break sounds in DL (for kon) or SFA2 (for endx). I know that contradicts anomie's research. Writing KOFF=1, KON=1, wait... KOFF=0 supposedly won't play sounds, but that's exactly the problem games are having -- they are playing the sounds when you clear KOFF, for whatever reason... not emulating that causes many dropped samples. So that suggests writes to KOFF won't clear the kon bits. I also modified some other things to TRAC's research. Specifically, I made writes to VxSRCN not restart the sample, and just update the value for the next brr with end bit set block to reload the brr address. That fixed the horrible sound problems in Mortal Kombat 2+. Then I also changed the kon/koff checks to happen for each sample instead of every other. I don't know what's right here, but TRAC thinks its the former, so until I test it myself or hear otherwise...
Ugh. Well, luckily I just had to split the 16-bit addw op in the SPC into two 8-bit adds to pass Overload's SPC test, so I should be able to use the exact same method to make an add_nybble function and call that four times. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 28, 2005 6:23 pm Post subject: | |
|
|
|
| mmm, post-thanksgiving update. Go have a look y'all. Shaping up to be a big release. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 28, 2005 11:24 pm Post subject: | |
|
|
|
| I
could use some help with the triple buffering code... such an amazingly
simple concept yet I can't manage to maintain smooth video even with
High priority, 60hz video mode, and 2x the CPU power to spare. ZSNES manages, so I know it's possible... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 29, 2005 5:44 am Post subject: | |
|
|
|
| Hey Byuu, any chance you would want to use this snes pad for your mapping image instead? It's even 1/4 the size. http://home.mchsi.com/~s.daystrom/snespad.bmp |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 29, 2005 6:56 am Post subject: | |
|
|
|
| Don't like it :/ 0kb. Ugly, but eh. Lots of bandwidth saving. It lets you map a keyboard button AND joypad button to the same controller button, too. |
|
Seen it all
Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box
| Posted: Tue Nov 29, 2005 2:49 pm Post subject: | |
|
|
|
| Kick ass. Is there a link to the current build of bsnes? _________________ My boring Site |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 29, 2005 4:43 pm Post subject: | |
|
|
|
| Dude, that's even better. That was probably more work and you were using an image before, so I didn't suggest it. Kazaam. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Dec 03, 2005 2:46 am Post subject: | |
|
|
|
| I just noticed something of a minor inaccuracy. Shouldn't 640x480 be listed as 4:3? Just thought I'd let you know if you hadn't noticed already. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 03, 2005 4:11 am Post subject: | |
|
|
|
| The output is actually 512x446 centered in fullscreen mode 640x480. The new version takes care of this anyway. There are ten video modes, selectable through CTRL+[1-0], the first five are windowed modes, the last are fullscreen modes. All ten can be configured via bsnes.cfg Format for windowed modes is just "WIDTHxHEIGHT" Format for fullscreen modes is "RESXxRESY@REFRESHRATE:WIDTHxHEIGHT", with the latter being the size of the image, automatically being centered. So it should be trivial to create a 4:3 pixel mode even on 16:9 and 3:4 monitors. I also made 640x480 stretch to the full screen by default. It actually doesn't look half as bad as I thought it would. So yay me, I'll never have to deal with hundreds of requests for crazy weird resolutions. End users can use whatever the hell they want now. Oh, and for a sneak peek: +/- adjust frameskip rate, PAUSE/BREAK which is self-explanatory, CTRL+[+/-] to control base emulator speed. There are five speed modes, all user definable. By default there's 50%, 67%, 100%, 150%, and 200% modes. I don't even think there's a computer out there that can use the last one with no frameskipping, but eh. The option is there anyway. The audio frequency is actually adjusted, too, so the audio stays smooth and crisp, with only a change in tempo / pitch. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Dec 03, 2005 4:46 am Post subject: | |
|
|
|
| Nice! Thanks for the info. | |
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Sat Dec 03, 2005 5:02 am Post subject: | |
|
|
|
| That's amazing work you've been doing, byuu Anything the bsnes community can do to help you out? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 03, 2005 7:31 am Post subject: | |
|
|
|
| Sure!
In order: help fix the problem with my triple buffering code (since the
SNES runs at 60.09 fps, it should skip one frame every ten seconds, but
it seems like it gets jittery for 2-3 seconds every 10 seconds
instead), rewrite the Linux port to not suck royally, and add support
for any special chips I don't currently support. Hehe, you asked :D |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 04, 2005 3:01 am Post subject: | |
|
|
|
| v0.015 is up. Enjoy. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Dec 04, 2005 6:48 am Post subject: | |
|
|
|
I saw it first. It's mine, mine, mine, mine, mine.  Thanks again to byuu and company. |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Sun Dec 04, 2005 6:48 pm Post subject: | |
|
|
|
| This
is a fantastic release! bsnes seems like it is well on its way to
eventually outdo ZSNES! (and it already has accuracy-wise). Problem: I can't map the keys to the directional buttons on my Saitek P880 gamepad. I can map A, B, X, Y, L, R, Select, and Start just fine, but not U/D/L/R. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Dec 04, 2005 6:56 pm Post subject: | |||
|
|
|||
I kind of doubt that at least for a long while. Until bsnes gets save state support, we won't see it remotely close to ZSNES featurewise. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 04, 2005 7:10 pm Post subject: | |||||
|
|
|||||
Please make sure your controller is in digital mode before mapping the keys. It works with analog for me too, but eh. That's probably the cause.
Seconded, and I don't ever plan on adding most of ZSNES' features. And the only way I'll be beating ZSNES on speed is when quantum processors come out that aren't backwards-compatible with x86's, and ZSNES can't be recompiled due to the large amounts of x86 assembler. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Dec 04, 2005 7:17 pm Post subject: | |||||
|
|
|||||
Well, others do plan on adding features eventually, but a lot depends on save states. bsnes isn't even worth looking at for various things till it has save states. Rewind and Movie features depend on save states. Now take the nesvideos crew, they go around finding good emulators and adding a lot of features to it to make it nicer to work with and use, but only if it seems feasable for making movies with, and that absolutely depends on having good save state support. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 04, 2005 7:39 pm Post subject: | |
|
|
|
| Well,
I guess I can start on savestate support now. Just add one core part at
a time. I did want to wait for anomie so that we could create that
generalized SNES savestate format, but he seems MIA at the moment... :( I would hardly say it isn't worth looking at, but eh. Also, my licensing probably isn't very friendly to the nesvideos crew. Although I'm always willing to import others' code into my trunk. Speaking of rewind, I'd love to add something like blargg's rewind idea, where you actually emulate forwards but play backwards, but bsnes is hardly the emulator to be trying something that CPU expensive on... it would be cool as hell, though. |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Sun Dec 04, 2005 8:03 pm Post subject: | |||
|
|
|||
Thanks.
|
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Dec 04, 2005 8:41 pm Post subject: | |||||
|
|
|||||
I don't think they'll have an issue with your licensing. Their basic requirements these days seem to be that they can modify it for their own use and it runs on Linux. The biggest problem they have regarding this is: "No publically-released derivative works of this source code are permitted without my permission." But it's just a hop over from #nesvideos to ask permission which you'll probably grant, right?
It's not CPU exspensive at all. Although depending on what method you use exactly, it could be memory exspensive. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 04, 2005 9:19 pm Post subject: | |||||
|
|
|||||
I granted this permission to Richard Bannister because I never plan on releasing a mac port, nor buying a mac, for that matter. I basically don't want to fork the hell out of my userbase like the SNES9x project has. There are what, 15 separate builds of that emulator now? And then you go and fix bugs and add new features, but the other build maintainer is now gone, so you get people complaining about something you fixed half a year ago in the official release. And then you get certain people who rename your emulator and try and take all the credit. Plus it's wasteful. People should work together on the same codebase and improve that, instead of making a new version because one or two small features aren't in the main build. And the main thing that really upsets me are things like that one multi-platform emulator that's for sale, but takes 95% of its emulation code from free projects like 9x. Of course, anyone can break my license, but then I can just start releasing the source three versions behind like 1964 does, too. To answer your question, I might grant permission. Just video capture features alone probably won't matter much to me. I'll talk more about that when I get savestates, though.
It isn't the way ZSNES implements it. What blargg does is take periodic savestates, and then when the user hits rewind, he goes back one savestate, then emulates everything up to the present and stores it in a buffer. And then he plays that buffer backwards. So the audio sounds like it's reversed, and the video is smooth. e.g. it looks like a real rewind instead of like loading a savestate. Now, given it takes 1.8ghz or better for bsnes to reach 60fps in all games, you won't be able to generate more than one or two frames going backwards in real-time without there being pause delays, which ruins the effect. ZSNES might be able to pull it off, because it runs ten times faster. NES emulators can easily pull it off, because they run thirty times faster. |
|||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sun Dec 04, 2005 9:37 pm Post subject: | |
|
|
|
| Fantastic
work on bsnes thus far! I have a few suggestions/requests/questions if
you wouldn't mind giving them some consideration. 1. One of the advantages I can make use of in ZSNES is that it does not have a window tab border in window mode. I am able to have it fill the screen in window mode using a custom monitor res with my video card (512x448x60hz). I tried it out with bsnes, and it worked pretty close, except there was a visble window tab. If possible, the best would be a 512x448 window mode with no tab border. 2. There seems to be some interpolation going on with the graphics. I'm not sure how this works or if its fully being done by my video card, but I can't stand interpolated graphics. In ZSNES, there is minimal interpolation at 512x448, and I use 25% scanlines to give it a sharp, yet unblocky look. I'd love to see some scanline options and a way to turn off interpolation if possible at all. 3. This is most important to me. Its about smooth scrolling. While triple buffering does a decent job of smoothing out the scrolling, I much prefer timing based on vsync. Again, I program in my own custom timing modes on my card using power strip, which allows me to run ZSNES liquid-smooth. Ok, thanks a bunch for the great work so far! |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Dec 04, 2005 9:59 pm Post subject: | |||||||
|
|
|||||||
You must be out of the loop... You haven't seen what they did with Snes9x Improvement or their versions of famtasia, FCEU, and VBA have you? It is much much more than video features. This is a completely different crowd than your emulation scene and they demand very different features to be available.
I was and am fully aware what blargg does. It doesn't have to be CPU exspensive at all, I see right off the bat 3 different way it could be implemented. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 04, 2005 10:05 pm Post subject: | |||||||
|
|
|||||||
...that's what fullscreen mode is for. Edit bsnes.cfg and add a 512x448 video mode, and switch to that :/ No window border was one of the most annoying GUI things with ZSNES to me. If there's sufficient demand, I could add it, though.
It's your video card. ZSNES is way the hell faster, so it can handle copying 512x448 worth of video data to the card every frame. bsnes cannot, so by default it uses video RAM so it only has to copy 256x224 usually. One option is for me to add a D3D renderer, but those don't do fullscreen + menus. But it lets you turn off the interpolation, unlike DirectDraw. The other is for you to disable the "use video memory" under video options. Beware, you will lose a lot of speed. I'm not at a point to start adding video filters (scanlines, HQnX, etc), but I will eventually.
Triple buffering is identical to vsync, but requires no CPU stall time. Both wait until the start of the vertical blanking period, and then blit the current image to the screen. The difference, and this is very important, is that vsync means you need to wait until the retrace period begins. This will prevent the sound system from receiving new samples and being updated, and it will align the refresh to your monitor instead of the emulator speed. The result is choppy audio. The solution is to resample the audio and lose sound quality, which I'm not willing to do. Triple buffering just blits the most recent image, if any, to the screen at this time. Also, the SNES video in non-interlace runs at 60.09fps, and in interlace mode at 59.97fps. All other emulators run at 60.0fps, which is not correct according to the SNES stock specs. Triple buffering is the only way to handle that "extra" frame every ~11 seconds properly (basically, by skipping it). Plus, my triple buffering support has a bug that I can't find. When that's fixed, I'm certain the video will be just as smooth for you. |
|||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Dec 05, 2005 5:14 am Post subject: | |
|
|
|
| Thank you, byuu, for this emulator. I just had one of the most enjoyable Earthworm Jim 2 experiences I've had on my computer. Your emulator is definitely the go-to choice for games that need a highly accurate emulator, and, recently, people who need custom video modes. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Dec 05, 2005 6:35 am Post subject: | |
|
|
|
| After having byuu explain the difference, I'm all for triple buffering over vsync if it can be done. Wish list for .016: Working Triple buffering DirectInput Pad2 Game Fixes ------------- Mortal Kombat Super Double Dragon Dracula X Death Brade Ace wo Nerae! RPM Racing Wild Guns (ok, so I heard this was a bitch) By the way, way to go on Rendering Ranger R2. That apparently works now. |
|
Nestopia Developer
Joined: 05 Dec 2005
Posts: 24
| Posted: Mon Dec 05, 2005 1:33 pm Post subject: | |||
|
|
|||
Actually, they do support it if you tell them to. IDirect3DDevice9::SetDialogBoxMode(..) was added into D3D9 for this, which is essentially GDI support in fullscreen. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Dec 05, 2005 10:35 pm Post subject: | |
|
|
|
| I
didn't fix any CPU errors in the last release (that I remember), so
Rendering Ranger R2 is still broken. And I just confirmed, it freezes
at the start of a new level. Ace is a DSP-1 game. Marty, thank you. I suppose I can start on a D3D interface, now. The big problem is that all of my old D3D code is for D3D8... minor differences, I'm sure, but I always hate having to redo all of that stuff v_v' |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Dec 05, 2005 11:24 pm Post subject: | |
|
|
|
| Stupid question, but would D3D8 code work with Direct X 9.0c ? _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Mon Dec 05, 2005 11:32 pm Post subject: | |
|
|
|
| Yes. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Mon Dec 05, 2005 11:46 pm Post subject: | |
|
|
|
| That's what I thought, thanks Clements. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Dec 05, 2005 11:46 pm Post subject: | |||
|
|
|||
Thank you for taking the time to prove that I'm retarded. "SuPAr NinTeNdO derrrrr..." I stand firmly behind the rest of my bug list... I think. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Dec 06, 2005 10:33 am Post subject: | |||
|
|
|||
It can now poll the first 256 joypads in your system, and 128 buttons on each one (+4 for directional pad). So you can have up to 32k joypad buttons, plus your keyboard, to map to all 12*2 SNES buttons. Now I just need to add support for my PCTV Pro remote control (serial device with an IR sensor), and we're good. Also lowered the strength on the x/y axes for the d-pad, makes doing combo moves in fighters a hell of a lot easier when using the thumb stick. Also mapped the POV hat to the d-pad, so now digital and analog mode both work fine. Genjuu Ryodan is another game that doesn't work right. HDMA problems. |
|||
Hazed
Joined: 19 Jan 2005
Posts: 73
Location: 127.0.0.1
| Posted: Wed Dec 07, 2005 4:15 pm Post subject: | |||||
|
|
|||||
What the hell, is a hell of a lotta buttons you can use.. This emulator is getting on par with zsnes. _________________  Get Fire Fox now! If not, get ready to put up with spy-ware and ad-ware! 
|
|||||
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Fri Dec 09, 2005 1:07 am Post subject: | |
|
|
|
| Tiny
problem I've had with the Input (which may or may not be fixed with
your recent post 0.15 changes but I'll post it anyway). I can't bind
the Spacebar as a key. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Dec 09, 2005 3:46 am Post subject: | |
|
|
|
| Seems
to be working fine for me, but it triggers the button again right away.
The variable is updated, though, so just select another button or close
the window. I'll see if I can make it wait a moment for the spacebar to be released when setting that button for the next release, thanks. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Dec 09, 2005 8:48 pm Post subject: | |
|
|
|
| I
thought I remembered reading somewhere that bsnes polled the joypads
thousands of times a second for input. Is this right or wrong? How many
times per second does bsnes poll the joypads for input. My reason for asking is that bsnes feels more responsive than ZSNES while playing Donkey Kong Country 1. I feel my jump sequences and stuff are more precise and accurate in bsnes than in ZSNES. I'd also like to note that DKC is perfectly playable at 30hz (the output for 1 frameskip), and bsnes is much more able to keep a steady speed with 1 frameskip. Additionally, how much does output resolution affect speed for bsnes? Most of the time, I can get a fairly steady 60hz, but when bsnes does slow down, resolution doesn't seem to affect it. At least, 256x223 seems no faster than 1024x768. (I haven't experimented with resolutions above 1024x768). _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Dec 09, 2005 9:24 pm Post subject: | |
|
|
|
| The
input is polled whenever the SNES requests it, at exactly that time.
All buttons are polled then. So it's usually 60 times a second, but it
could be a lot more than that. The video is scaled by hardware, so any resolution runs at the same speed, unless you turn off the video memory surface. It may play fine with a frameskip of 1, but that's hardly an acceptable speed, especially in games where blinking animation is done by turning the sprites on and off after each frame :/ It shall have to be made faster, somehow... |
|
Hazed
Joined: 19 Jan 2005
Posts: 73
Location: 127.0.0.1
| Posted: Fri Dec 09, 2005 11:27 pm Post subject: | |
|
|
|
| After here the ToP theme song being played over Zsnes and Bsnes. The winner is: Bsnes. The reason is that it's much clearer than it is with Zsnes, i guess because of the spc code they are using. some things do sound the same but. I can here some diffrents. _________________ Get Fire Fox now! If not, get ready to put up with spy-ware and ad-ware! |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Dec 10, 2005 12:32 am Post subject: | |||||
|
|
|||||
So, is anything that is DirectDrawn interpolated? Or is this a video-card specific feature. As in, some cards interpolate all DirectDrawn stuff, some don't? Also, whenever I uncheck "Use Video Memory Surface" in windowed mode, the video becomes very messed up. Is this normal?
I haven't really noticed this problem. Does it occur during any time Triple Buffering is enabled, or only in combination with certain other conditions? What exactly are the symptoms? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sat Dec 10, 2005 9:14 am Post subject: | |||||||||
|
|
|||||||||
[quote="byuu"]
Actually your suggestion to edit the cfg worked great! Thanks! I like being able to customize the cfg like that.
That's what I was afraid of. I cannot stand interpolation. Maybe there's a way I can turn it off from my card's drivers (I have a Radeon 9800XT). I forget that in ZSNES, I use scanlines, which significantly reduces the look of interpolation from my card. However, if I go to a higher res, the interpolation becomes much worse on ZSNES as well. I admit I'm no fan of other video filters like "supersai" and "HQ2X" or whatever that stuff is called, but that's just because I prefer what reminds me of what I used to play from years back, hence the scan lines.
Ah I see. I had noticed in Gens, turning off auto frame rate and using strictly vsync caused the audio to become choppy at a ten-second interval. If I turned auto-frame rate back on, the sound would smooth out, but it caused a one-frame jump every ten seconds... Makes sense.
Cool. Maybe I should try programming in a 59.97 refresh rate mode with Power Strip. Or would that have any effect on the Gens example I gave? Thanks for the info on how all this stuff works. Makes a lot of previous annoying problems I've dealt with make a lot more sense now. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 10, 2005 10:32 am Post subject: | |||||||||
|
|
|||||||||
Hell yeah it is. I remember the first time I heard the song in ZSNES, I thought it was supposed to be inaudible, heheh. It helps a lot now that ZSNES defaults to 32khz gaussian stereo. That wasn't always the case.
I've already answered the first question. Scaling a video surface causes interpolation to be applied. Scaling a software surface does not because scaling is done by the CPU instead. Yes, the messed up video is normal. I never re-added support for 32-bit software mode after the rewrite (v0.006+). bsnes always renders a 15/16-bit image to video RAM, and the hardware auto-converts it to 32-bit before drawing to the screen. This cuts the bandwidth in half. Solution? Set your desktop to 16-bit or use a hardware surface, or wait for the D3D renderer. Sorry about that.
I'm currently trying to add Direct3D support, but I'm taking a major speed hit with the current code. And it's very well optimized, too. It's just... slower... than DirectDraw. Must be something I'm doing wrong... Anyway, that gives you the option of using point filtering (e.g. what you want), bilinear filtering (yes, its always bilinear on a 2D image), some triangular thing, and gaussian quad filtering. Gaussian gives me a serious headache, and my nVidia card doesn't support it so it only works with the reference driver (e.g. < 1fps glory). Fun. Maybe a Matrox or a $600 nVidia or something would support it in hardware? And all are nice and fast. I'm trying to think of a way to pull of true TV-style scanlines fully in hardware, but the D3D rendering style isn't very intuitive to doing that. I don't know how to say, blit a texture somewhere, then blit a scanline mask onto that, and then scale that image to fill the whole screen... D3D seems to want to draw all textures directly onto the backbuffer, or to surfaces which lack alpha blending capabilities (e.g. they're completely worthless).
60.09fps is non-interlace mode, 59.97fps is interlace mode. The former is more common, the SNES can swap between the two... even mid-frame, crazy and impossible as that may be. And I seriously doubt your monitor will have that kind of fidelity to control floating point-based refresh rates. If so, go for it, and good luck with that. |
|||||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Dec 10, 2005 4:22 pm Post subject: | |||
|
|
|||
Not to offend anyone here,but for me it allready surpasses it (though of course, it's all a matter of opinions) I just tried 0.15 and it's just A-freakin'-mazing. Someone mentionned that the input is more responsive than Z. Don't know the exact reason but it's true! With Bsnes the input react "au poil de cul" (with perfect accuracy iow) it react instantly with no delay at all. . With Zsnes, there's a slight delay for some reason (with or without Triple buffering), no more than a frame or two but it's there. I never really noticed before because I had nothing to compare it to I guess. I'm sure in time, Bsnes will have the recognition it deserve. Btw, small request Byuu: Could you add a keyboard hotkey for the load rom dialog,reset and hardreset? Something like alt-o,alt-r,alt-h or something? Last edited by Dmog on Sat Dec 10, 2005 5:30 pm; edited 1 time in total |
|||
Hazed
Joined: 21 Jan 2005
Posts: 70
Location: America's Penis
| Posted: Sat Dec 10, 2005 7:13 pm Post subject: | |||
|
|
|||
|
i'm looking for how to enable frameskip in the SDL port. this is the only reference i could find, and it's commented out: from sdl/bsnes.cpp
and as a total C++ noob, this function doesn't make much sense to me. any help? |
|||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Sun Dec 11, 2005 4:42 am Post subject: | |||
|
|
|||
the
stuff that's commented out looks to me like it just makes it so that it
always displays fps and doesn't display the frameskip. It doesn't
affect the operation of the emulation at all.
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 11, 2005 5:02 am Post subject: | |
|
|
|
| The SDL port has no GUI to toggle the frameskip rate, so you'd have to recompile it to change the frameskipping rate. Still looking for a Linux-savvy programmer to write a basic GUI consisting of a menu bar, load ROM dialog, and a video output buffer. Preferrably one that can be scaled in hardware. Until then, I know nothing about Linux coding so that port will remain lousy. Using bsnes through WINE is a much better option. |
|
Hazed
Joined: 21 Jan 2005
Posts: 70
Location: America's Penis
| Posted: Sun Dec 11, 2005 5:03 pm Post subject: | |||
|
|
|||
this is what i was getting at... I was looking for what to change so I could recompile with a frameskip. I only found that one reference to "frameskip" in the source though... |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Dec 12, 2005 12:19 am Post subject: | |||
|
|
|||
Try this:
|
|||
Hazed
Joined: 21 Jan 2005
Posts: 70
Location: America's Penis
| Posted: Mon Dec 12, 2005 1:27 am Post subject: | |||
|
|
|||
I hope to soon learn enough C++ to at least understand how to fix something like this... it seems pretty trivial. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Dec 14, 2005 6:57 pm Post subject: | |
|
|
|
| Sweet, an update! | |
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Dec 15, 2005 8:07 am Post subject: | |||
|
|
|||
You haven't heard anything yet... |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Dec 15, 2005 8:26 am Post subject: | |||||
|
|
|||||
How about this? http://nsrt.edgeemu.com/topintro.rar _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Dec 15, 2005 8:57 am Post subject: | |||
|
|
|||
byuu, in your eventual implementation of save states, do you have any interest in doing something like this?
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Dec 15, 2005 9:05 am Post subject: | |||||||
|
|
|||||||
Well, bsnes still sounds better in my opinion. But that's probably mostly due to the fact that your avi has lossy audio. Even with the lossy audio though, it's sounding a lot better than it old ZSNES builds. Great work, pagefault! The only way we're going to be able to prove who the victor is now is by capturing the raw digital sound output from a real SNES and comparing :) <evil> Now let's compare sounds in Earthworm Jim 2 ... </evil>
Not really, but I don't think it'd be that hard to do... |
|||||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Dec 15, 2005 10:23 am Post subject: | |||||||||
|
|
|||||||||
LOL, Give all the credit to Nach. We currently only have this sound working on movie writing. The entire realtime sound code is being rewritten turospeed now that we have this fixed properly. I still have yet to put my SPC noise fixes in as well. Hopefully when everything is done we will have mirror copies of eachother in various things. I mean you could only do it that way if you want to emulate things accurately. But we (ZSNES) still have a long way to go on some things. Good luck with your continued work on bsnes, it's a great project. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Dec 15, 2005 10:37 am Post subject: | |||||||
|
|
|||||||
So that's an entirely rewritten sound core? If so, is it using anomie's DSP emulation code?
Agreed. And with all of the accuracy improvements in the new ZSNES builds... that's getting closer to a reality. As you know, you're welcome to use any and all of my code in ZSNES for however you see fit. BTW, that color add/sub code is mostly done if you wanted to look at it. Still need to run more tests on hires add/sub, though.
Thanks. I am starting to wear out a little (mostly because I've been focusing on adding features instead of core emulation), but eh. Motivation comes and goes, I'll be fine. |
|||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Dec 15, 2005 11:48 am Post subject: | |
|
|
|
| byuu, you're missing the point. That AVI (aside from the lossy audio) demonstrates how ZSNES *really* sounds. Unforunetly ZSNES doesn't send it's audio to the sound card properly, but I got it being sent to AVI properly, which you can hear good in any movie player which sends audio properly. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Dec 15, 2005 2:01 pm Post subject: | |
|
|
|
| Ah, that's... odd. Thanks for the clarification. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Dec 15, 2005 2:56 pm Post subject: | |||
|
|
|||
Not really, the sound code was deisgned for Sound Blaster 16. The Windows audio isn't great but okay, and the SDL thing is hack upon hack. All I did was get the actual raw samples ZSNES generates and put then in the movie, ZSNES won't let you hear that on your speakers unless you have a nice PC with SB16 ISA on MS-DOS. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Dec 15, 2005 10:49 pm Post subject: | |||
|
|
|||
Please let your fanbase know if there's anything we can do to maintain/improve your motivation.  _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Dec 16, 2005 12:31 am Post subject: | |||||
|
|
|||||
How about more bug reports? lol Honestly though, you work so quickly as it is, and the amazing thing is you're fixing stuff without breaking other crap. If you keep this pace, I shudder to think of what we'll have in 6 months. I also think it's nice to see sound getting some emphasis. The spc700 was such an amazing chip for its day... still is! And it was looking pretty hopeless for a while there... until bsnes came. woot! Last edited by FitzRoy on Fri Dec 16, 2005 12:41 am; edited 1 time in total |
|||||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Fri Dec 16, 2005 12:34 am Post subject: | |
|
|
|
| We could just temporarily lock this thread, until byuu catches up on what he wants to do with bsnes. That might slow down requests. |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Fri Dec 16, 2005 2:23 am Post subject: | |||||||
|
|
|||||||
Hopeless? Things getting broken is not something anyone does on purpose. It is bound to happen to every emulator at some point. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Dec 16, 2005 4:57 am Post subject: | |
|
|
|
| Actually I was referring to the sound with that. It was a new paragraph, after all. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Dec 16, 2005 11:40 am Post subject: | |||||
|
|
|||||
Part of it due to fixing things the "right way", part of it because it's a newer project. As it gets closer to perfection, the number of games broken by each fix will undoubtedly increase.
Thank anomie, he wrote the sound core. I've just been fixing bugs in his code. As has DMV27. Speaking of which, I really need to write that revised about dialog to give proper credits... and the advanced config dialog... and restructure the CPU core to be more modular... and write that readme file... and start on savestate support (don't expect that in the next 6 months).... and... ugh. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Dec 16, 2005 7:07 pm Post subject: | |
|
|
|
| I
personally don't use savestates that much, so I'm not too disappointed
by that. Probably because I never used them on a real snes And yes, super thanks to anomie for his research and sound code. People helping each other = better emulators all around. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Dec 17, 2005 7:06 pm Post subject: | |
|
|
|
| About your new updates, what is "raster size"? Why is (7x * 21x/4) the best resolution? Are the interlace/non-interlace modes standard for SNES emulators? Or is this a relatively uncommon emulation? I've just never heard about it before you started talking about it. I'm interested, because my only experience with interlacing is the interlaced/progressive-scan modes on TVs. About the responsiveness stuff at the end, are you saying you just made a change that makes bsnes even more responsive? Two (humble?) feature requests: 1. Do you think you could make an option to allow bsnes to remember its window position? It appears bsnes centers itself on screen every time you open it. 2. Is it possible you could put the loaded ROM name in the window title bar (and on the taskbar)? Now, a possible bug report: Occasionally, when playing a game, the audio will start to get scratchy. This does not appear to be a result of sub-60 FPS. I will be maintaining 59-61 FPS, yet it sounds like sound samples are getting dropped. Turning up frameskip does not fix the problem. After several minutes of this scratchy sound, it will return to normal. Oh, and finally, do you think you could have a pubicly accessible archive of your past news posts (about bsnes)? I really would like to read through them all, and it might interest other emulator developers about the process and SNES emulation in general. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 18, 2005 4:42 am Post subject: | |
|
|
|
| Raster
size is video output. Say, at 640x480 resolution, you can specify the
screen itself be drawn at 512x448 centered. 512x448 is the raster size.
I sort of made the word up there, so don't feel too bad :P Raster traditionally refers to the CRT beam cannon position, though. 1792x1344... the SNES resolutions are from 256x224 to 512x448. TV scanlines show approximately 70% luminance to 30% darkness. The best way to emulate that is to draw two solid scanlines to every one black line. That gives you 67% to 33%. Throw in some luminance on that black line (10% or so) and you're golden. Now for interlace, you darken the previous field by 30% each field. So for the former, your new resolution has to be a multiple of 3, and for the latter, it has to be a multiple of 2. That said, the only way you can do both cleanly with no stretching is to use a multiple of 6 (3*2). 224*6 = .... 1344! Also, notice that the height evenly divides into 1344. That means the scanlines won't get distorted when stretching to fix the aspect ratio. Speaking of aspect ratio... (4/3)*(224*6) = ... 1792! A perfect fit! It's also a huge resolution, so you can even get away with point filtering to fix the aspect ratio and still have a good image. I have tricks for other resolutions, too, but this one is just perfect. No other resolution is an even multiple of 224's height with no black borders on the top or bottom. Yes, bsnes is infinitesmially more responsive to input vs. video updates. I doubt it's even noticeable, but hey. Window position? Maybe. I kinda like it always centering, but it's doable. Title in the window? I'd rather not... but another thing that's doable. I don't know why your sound is skipping. Mine does that RARELY with the D3D renderer, but never with the directdraw renderer, even with triple buffering enabled. Don't know what to tell you :/ Anyone else having this problem? Previous posts... I don't have any of the old ones archived, but it's doable in the future. I'm too lazy to write the archiving PHP code, and I don't want to move it all over manually :/ Not to mention, I don't always post when I find out my old information was wrong. I hate to make other developers go through the same process of bug tracking as I did. That's happened to me a lot reading over the 9x forums. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Dec 20, 2005 10:45 pm Post subject: | |||
|
|
|||
I played through Earthword Jim 1 the other night and noticed nothing of the sort. I do remember while playing King of Dragons, that almost on every sound effect there would be a crackling sound. Pretty annoying, but this could be normal behavior. I would need to hook up my digisnes to make sure. What makes me also think that this is normal is that sneese exhibits the same thing, and the Japanese version exhibits more pronounced crackling. I've seen this type of wierdness before between regions of roms. Super Aleste had more crackling in its music than Space Megaforce did. It's just bad, early sound code in the rom I think. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Dec 23, 2005 11:57 pm Post subject: | |
|
|
|
| With
the latest version of BSNES... I'm very impressed with the audio
quality (albeit a little quiet, but whatever)... unlike .13, it syncs
very well. Now only if ZSNES had it implemented (I'll definately be
waiting until the newest WIP with the SPC fixes comes along). As Nach said.. it does need savestate support.. what would really be nice is at the very least.. a definable save (.srm) location and some patching (.ips) support. As for another bug I found: Run Secret of Mana through its intro... to the text "and history repeats..." it then shows the overworld... and it is messed up. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 24, 2005 12:08 am Post subject: | |
|
|
|
| I
don't touch the volume level, I use whatever the default is. Try
adjusting your volume in the control panel, or turn up your speakers :/ Maybe a quick sound level option wouldn't hurt. It has support for bpf patches now (see my homepage). I will not support IPS, because the format is irreversibly broken. I'm not going to play guessing games as to whether or not the IPS was created with a headered ROM or not. bpf always ignores the header in SNES games, among several other features. I'll look at SoM, thanks. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Dec 24, 2005 1:10 am Post subject: | |
|
|
|
Here's a pic of the overworld from the Secret of Mana intro (as rendered in BSNES): It seems like a transparancy/Mode 7/layering prob (I have no idea what exactly is the cause, but it looks to be a combination of the 3) I hadn't given the obligatory screenshot in the Castlevania - Dracula X problem (as rendered in the current version of BSNES):  It seems like a transparancy/layering problem. (Though, I myself am not able to figure out which are color addition/subtraction probs.. oh well.) _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 24, 2005 1:41 am Post subject: | |
|
|
|
| Yeah, I saw it, thanks. I don't know what's up with either of them. The odd thing about Dracula X is that the flame is on BG3 priority 1, and the bg3 priority bit is set. So by definition, nothing can come in front of it, and yet that seems to be the case in all other emulators. So somehow, the priorities are getting screwed. I'm thinking the game is adding in weird bugs when it detects a copier (or inaccurate emulation in this case), but eh. I really don't know. Too bad none of the other emulators let you toggle specific priorities within background layers, or it would be trivial to find out what was going on here. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Dec 24, 2005 3:21 am Post subject: | |
|
|
|
Another bug, this time in Final Fantasy Mystic Quest: As you can see, the damage number appears behind the character.. It is supposed to be in front of the character. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 24, 2005 2:29 pm Post subject: | |
|
|
|
| This is a sprite priority bug. Both the number and the character sprite appear on OAM priority 3. Funny, I implemented anomie's notes on range-time over and sprite priorities verbatim. The only thing I haven't added was firstsprite+y priorities, because it doesn't make a damn bit of sense. And I seriously doubt that's what's causing this bug. Ah well, I'll have to do my own tests to figure out what's wrong here. It's possible it's a bug in my implementation of his notes. |
|
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Fri Dec 30, 2005 10:53 pm Post subject: | |
|
|
|
| I have problems with the scrolling in bsnes. I am using Powerstrip to force 60 Hz. In Zsnes (with vsync) the scrolling is smooth all the time. In Bsnes (triple buffer) the scrolling is smooth too but each 5-10 seconds there are a few short annoying hicups in scrolling. Changing the sync rate to 59,94 (I wonder if this is the correct sync rate for ntsc TV consoles?) improves the hicup behaviour a little bit but the problem is still there. | |
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Fri Dec 30, 2005 11:03 pm Post subject: | |||
|
|
|||
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 31, 2005 2:12 am Post subject: | |
|
|
|
| Triple
buffering is fixed in v0.016, which has not been released yet. But with
it on, the menubar does not render either in the DirectDraw or Direct3D
renderer. I'm sorry, but I don't have an estimate of when this version will be out. I haven't changed nearly enough to justify another release yet. This will probably end up being the second longest wait for a new release since the project began :( For most games (that use non-interlace mode), 60.09fps is the correct speed. For games that use interlace (I can't think of any off the top of my head), 59.97fps would be the correct speed. The next version of bsnes will simply drop one frame every ten seconds, which is nearly unnoticeable. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Dec 31, 2005 6:16 am Post subject: | |
|
|
|
| Cool. So one question: are you saying that the menu bar will be rendered now that youre dropping 1 frame every 10 seconds, or was that just to make triple buffering work? | |
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Sun Jan 01, 2006 10:33 am Post subject: | |
|
|
|
| thankyou for the info. I have used 60,090 Hz in Powerstrip for 800 x 600. The hicup problem in scrolling has decreased. (almost perfect) keep up the good work. This emu looks very promising. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 04, 2006 6:51 am Post subject: | |
|
|
|
| Argh, disappointing news regarding bsnes. Ah well, money's good too. I myself feel the need to upgrade. I'll probably wait for the new socket AM2. Not that it'll perform better or anything... |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Jan 04, 2006 9:57 pm Post subject: | |
|
|
|
| Well,
I'm rather satisfied with the current release. It seems many future
releases would be more about feature additions rather than the minute
improvements in emulation accuracy. byuu, don't let bsnes die! Let us know if there's anything we can do to help. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jan 05, 2006 3:04 am Post subject: | |
|
|
|
| As am I. Most of what I want is already implimented, and when .016 comes it will be even moreso. But it seems the remaining game bugs are going to be pretty tough to figure out. Where'd that dmv guy go? He seemed awfully comfortable with the code and even fixed a few things. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jan 05, 2006 3:30 am Post subject: | |
|
|
|
| Menubar
either won't render or will flicker like mad with triple buffering
enabled. It's fixable with D3D at least by changing the presentation
settings when the menubar is toggled on and off, but I haven't gotten
around to it. No reason to wait for the AM2, really. Unless you can afford a $1000 processor for it. I'm just planning on buying an FX-59 or X2 4800+ when they are on the low end of the price spectrum. A big help would be matching my 55+ hour/week salary, hell, I'd throw in a good 30+ hours for free :D ...of course, the only way that's hapening is if a certain console maker would hire me to develop an SNES emulator for their certain upcoming system (which might coincidentally advertise supporting the SNES) *cough* Anyway, fixing the bugs is (even more) difficult because I haven't had a functioning debugger since v0.013. With the win32 rewrite, it's going to take a ton of code to get that thing up again. |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Thu Jan 05, 2006 4:39 am Post subject: | |
|
|
|
| I'm willing to do some profiling work to see where we could slim things down to try to improve performance. Already built bsnes for linux with profiling and code coverage logging, and looked at some preliminary data. Granted, the problem of profiling bsnes is made more difficult by the fact that different games will have (I'm guessing) wildly different time-intensive code paths. So I guess what I should do is take suggestions for games that have sections that are slow, and probably shouldn't be, or games that don't use any extra chips or do any strange things, but get poor framerates. Any ideas what games to start with? |
|
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Thu Jan 05, 2006 2:50 pm Post subject: | |
|
|
|
| I
just built a new rig with a X2 3800+ running beyond 4800+ speeds at
2.5Ghz(didn't even get the chance to really push it beyond that yet.) I've been meaning to give BSNES a try on it. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Jan 05, 2006 5:00 pm Post subject: | |||
|
|
|||
But then, that would mean the death of bsnes no? I'm pretty sure if you were to work as a programmer for Nintendo they would prohibit you from making an open source,free Snes emulator. After all, it is Their (dead) console, and only They can make an emulator for it  You all know how the big N is.."All your emus are belongs to Nintendo" |
|||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Fri Jan 06, 2006 3:03 am Post subject: | |
|
|
|
| byuu - I've done an early round of performance tests using different optimizations. Test setup: Athlon64 3000+ socket 939 processor 256MB of RAM Gentoo Linux 64-bit gcc version 3.4.5 glibc version 2.3.5 Modified sdlmain.cpp loop to only run 400 frames Build bsnes_sdl using -O2 and -O3 Timed running first 400 frames of Secret of Mana 6 times in a row, and kept the times for the last 3 executions Timed running first 1000 frames of Secret of Mana 6 times in a row, and kept the times for the last 3 executions Results: Compiled with -O2 400 loops total time for the three runs: 0m13.154s 1000 loops total time for the three runs: 0m32.625s Compiled with -O3 400 loops total time for the three runs: 0m13.576s 1000 loops total time for the three runs: 0m33.804s I repeated the same tests, but adding things like -funroll-loops, generating profiling data, etc I consistently came up with about a 3.2-3.6% speed improvement by using -O2 I consistently had worse performance with -funroll-loops Conclusions: I went into this guessing that O3 would give slightly worse performance because this has been noted before with many other software packages on Linux. I expect this to be the case across the board with gcc < 4.0. I'm not willing to make any guesses as to how gcc4 does with O2 vs. O3. |
|
Rookie
Joined: 15 Oct 2004
Posts: 24
| Posted: Wed Jan 18, 2006 6:31 pm Post subject: | |
|
|
|
| Cycle
accurate SNES emulation? I wish I knew about this earlier. I had given
up on SNES emulators, which are notorious for being inaccurate. NES
emulation has Nintendulator and Nestopia, which are both cycle
accurate, and I just assumed that the popularity of SNES9x and ZSNES
would prevent any revolutionary progress in SNES emulation (such as
cycle accuracy). The sad thing is that the casual gamer doesn't care
very much about cycle accuracy, unless they notice the lack of it, such
as their game doesn't run or doesn't run correctly or it looks like
ass, sounds like ass, etc. I am bookmarking the bsnes page. http://byuu.cinnamonpirate.com/?page=bsnes Please keep the project alive. Once bsnes reaches a critical mass (of users, features, and game compatibility), hopefully it will become the new base standard for SNES emulation and get ported to every platform under the sun as is the case with SNES9x and ZSNES. I'd love to see an Xbox 360 port, if the 360 was capable of running bsnes at full speed. Is it capable? |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Jan 18, 2006 6:55 pm Post subject: | |||||
|
|
|||||
Uh, what? ZSNES has three ports. Windows, DOS, SDL. Just fyi, ZSNES is incapable of running on a non-x86 CPU.
I have a feeling there needs to be a lot more work on getting ANY homebrew app to run on the 360, before bsnes is ported. But, seeing as how it is written entirely in C++, it should be less hard than other more poorly programmed emulators. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed Jan 18, 2006 8:23 pm Post subject: | |||||
|
|
|||||
SING IT BROTHA'! (Seriously though, totally agree) To be fair Zsnes is becoming more accurate. But it's a long,long process I guess. The project (Z I mean,or rather, all who worked on it) has done a lot for Snes emulation.
Don't own a 360 but judging by the spec I'd say probably. Though the "Three symmetrical cores running at 3.2 GHz each" (there's three cpu@ 3.2Ghz inside?) would probably be useless for such a program. I doubt bsnes could take advantage of the other two core, the same way Mame cannot really take advantage of dual core PCs. And I have no idea how difficult it would be to port it to the 360 Last edited by Dmog on Wed Jan 18, 2006 9:23 pm; edited 2 times in total |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Jan 18, 2006 8:45 pm Post subject: | |
|
|
|
| On
the other hand, SNES emulators may be uniquely positioned to take
advantage of hyper-threading / dual processors. Since SNES emulators
already have to emulate multiple CPUs simultaneously, there might be
significant speed gains if you could emulate each SNES cpu on its own
PC cpu. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed Jan 18, 2006 9:10 pm Post subject: | |||
|
|
|||
That's been (overly) discussed in the Mame forum. There's no speed to be gain even with arcades that uses multiple Cpus. I don't see why this would be different for Snes emulation. I think there's an article in Aaron Giles's blog somewhere that explains in great details why this is so. Some of this stuff is a bit beyond me, but basically: I think even if you emulate multiples (virtual) Cpus on multiples (real) Cpus you still have to sync them so that they communicate with each other (if you care even a tiny bit about accuracy at least). And this process of syncing them defeats the speed gain you just obtain. The multiple Cpus end up running as only one Cpu so to speak,but their power is not combined. Dual cores works well with stuff that doesn't need real syncing. If you're trying to brute force some algorithm for example,or encoding a video or heck, running an OS. edit: Oh No! I actually noticed that this is my 256th posts! I'm becoming a nerd! Guarhh! |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 18, 2006 9:40 pm Post subject: | |
|
|
|
| There's no disrespect to ZSNES in saying that bsnes represents the new breed of snes emulators. As cpu power increases, cycle based for the snes becomes feasible from an enjoyment standpoint. We can play at full speed with what is considered budget today in tech. ZSNES will still have a larger userbase for some time yet, despite the fact that a fast computer costs a fraction of what it did 5 years ago. | |
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Thu Jan 19, 2006 1:51 am Post subject: | |
|
|
|
| that's
been an excuse for lazy coding for a long time. the fact that faster
processors will still be able to spit out 60 fps, even though they're
code is a steaming mess. nothing against anyone here, i just hate hearing that as any kind of feasible reason for anything it shouldn't be. _________________ |
|
Rookie
Joined: 15 Oct 2004
Posts: 24
| Posted: Thu Jan 19, 2006 2:39 am Post subject: | |
|
|
|
| I
realize it is restricted to x86, thanks for stating the obvious. ZSNES
is ported to far more platforms than many other emulators, which are
Windows-only. That was my point. As a Linux user, having a Linux and
Windows port is just about every platform I'd care for. Though a
console port (I have no bias), is also nice for an inexpensive solution
for playing the games on a big screen TV. Anyway, cycle accuracy is the next step. You can't fault ZSNES for lacking it because ZSNES was first coded many many years ago, when hardware could barely run it at full speed. It is nice to see SNES emulators following the progression that NES emulators have taken. Fast, but inaccurate (Nesticle, etc). Later followed by more resource intensive yet cycle accurate emulators (Nestopia, Nintendulator). Those that say you can't tell the difference between cycle accurate and not cycle accurate simply having compared emulation side-by-side with a real console. For some games that I have played for years on a real SNES, I don't even need a side-by-side comparison. For example, Super Mario Kart in SNES9x or ZSNES... I can tell the difference in a blind (can't see the hardware) "taste test". I hope that bsnes soon becomes the standard for SNES emulation. ZSNES vs SNES9x flamewars will be a thing of the past. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Jan 19, 2006 2:46 am Post subject: | |||
|
|
|||
True, but with bsnes (I'm not saying you were talking about bsnes but FitzRoy's comments were refering to it) that's not the case. It's slow because it's extremely accurate and because it's not written in assembler. A cycle-accurate Snes emu is simply not gonna run full speed on a PII 500Mhz even if you optimize the shit out of it (that's my non-programmer impression at least). |
|||
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Thu Jan 19, 2006 5:15 am Post subject: | |
|
|
|
| This I realize. That comment is just one of my hot-buttons, and I couldn't stop myself. I've tried bsnes, and I enjoy it, but I currently prefer zsnes, for feature and speed reasons. _________________ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jan 19, 2006 6:26 am Post subject: | |
|
|
|
| Lots of replies... neat. Thanks DataPath. I'll be sure to use -O2 for the gcc port. The only thing more than one CPU would do for bsnes is allow me to use the other(s) for software video filtering. bsnes most certainly isn't as optimized as it could be. I was going more for readable code, but I definitely could've made better choices even with that in mind. I'd say 1.2ghz for fullspeed would be the best I could manage in pure c++ with no reduced accuracy, probably around half that or a little more with assembler thrown in. And that's just guessing. Who knows. This is of course assuming I were to keep the crap inaccurate scanline renderer in there now. And I appreciate the complements, but bsnes still really isn't that hardware accurate. We can call it accurate when/if I write the dot-based PPU renderer. IF bsnes gets as popular as zsnes / snes9x, then you'll just have ZSNES vs SNES9x vs bsnes flamewars. I doubt that will ever happen, though. |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Thu Jan 19, 2006 3:07 pm Post subject: | |
|
|
|
| Byuu
- when I get some time (hopefully this weekend) I intend to go through
and clean up the arrangement of the source code - i.e. make it so that
.cpp files aren't included in .cpp files, be consistent about variable
types throughout the code (uint, uint32, etc will be changed to a more
standard uint32_t type throughout the code. IIRC, msvc doesn't define
these, even though it should in <stdint.h>, so I'll have an ifdef
for MSVC and define them properly). There's some crazy inlining going on that I'd like to fix up, but it's hard to track everything down to make sure that it gets fixed properly, thus the source code cleanup. Inlining should be used carefully, because used improperly it CAN slow down code, so I will probably also profile the speed with inlining turned off. |
|
Rookie
Joined: 15 Oct 2004
Posts: 24
| Posted: Thu Jan 19, 2006 5:41 pm Post subject: | |||
|
|
|||
I say go for it. As of now, most people will continue to use ZSNES anyway because the average user has a shite PC and likes feature-bloat. What is needed is a new emulation core for the future of SNES emulation. You might as well go all the way with regards to accuracy, readability, and portability, even if that means today's top of the line PC can't even run it at full speed. PC hardware will eventually catch up, and when it does, the portable bsnes core can be used in whatever feature-bloated SNES emulator somebody decides to make. Kind of like the Gecko HTML core used in Mozilla, Firefox, Netscape, etc. The GUI, networking, pixel filters, peripherial supprt, etc, can be included by 3rd party emulators that use the bsnes core, and that way bsnes core can concentrate on being 100% cycle accurate and not waste its time with feature-bloat. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jan 19, 2006 6:27 pm Post subject: | |
|
|
|
| Byuu
might be getting burned out of that kind of thing, but yes, there is
still some emulation stuff. New debugger->game fixes, dot-based
render, dsp1234. You can do whatever you want though, I'm just being a
whiny fanboy. |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Sat Jan 21, 2006 8:52 pm Post subject: | |
|
|
|
| all features are not bloat. holy cow. _________________ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jan 21, 2006 10:40 pm Post subject: | |
|
|
|
| Certainly not. Triple buffering, savestates = gold. I'm not entirely sure what Jagasian wants, but I doubt byuu is going to let a bunch of third party spinoffs come out. Doesn't really sound like there's much of a purpose to that there. Seems better to just let people contribute to bsnes for things byuu does not plan to add. |
|
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Sun Jan 22, 2006 11:09 pm Post subject: | |
|
|
|
| One thing I'd to know is why it takes [I'm exaggerating here] years for bsnes to actually get to doing anything overt. After about a minute or so, FFV [unpatched] gets around to playing, but I haven't gotten Super Mario RPG to play yet. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Jan 22, 2006 11:56 pm Post subject: | |
|
|
|
| iirc the SA-1 chip isn't emulated yet at least not in bsnes anyway _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Mon Jan 23, 2006 12:27 am Post subject: | |
|
|
|
| The
problem with implementing certain special chips (SA-1, SuperFX in
particular) is that exist code for emulating them is currently horribly
buggy and imperfect in all the emulators that have support for it. Byuu's aim is to make the emulator as perfect as possible, and not implement the imperfect code that exists right now for the sake of getting some games working. The S-DD1 had accuate code for it already well documented, so adding this chip wasn't as big of a problem. Byuu is also coding the emulator mainly for himself, and probably does not want to code a bunch of features which detract him from the whole purpose of this emulator - accurate emulation above everything else. It is a privilege that he has shared his work with us. If you desperately want a certain feature to be added, then it will need to be coded by yourself. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Mon Jan 23, 2006 1:50 am Post subject: | |||
|
|
|||
Your post was not particularly coherent but I think I got the gist of it. The reason "it takes [you're exaggerating here] years for bsnes to actually get to doing anything overt" is because your computer is not fast enough. Currently,bsnes needs something like a P4 2.0ghz up to 2.8ghz to achieve full speed with 0 frameskip. Sa-1 isn't implemented, so you'll have a hard time playing SM Rpg. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jan 23, 2006 7:47 am Post subject: | |
|
|
|
| I'm
also too lazy and time-constrained to add SA-1 emulation. I doubt I
could pull off cycle-stepping with an ~11mhz 65c816 in addition to
everything else, too. Hm, there could be a bug that causes it to take several minutes (or whatever) for games to start for you. Anyone else notice this? Things start quickly even on this 600mhz laptop, they just don't run quickly once they do ;) |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Jan 23, 2006 8:41 am Post subject: | |||
|
|
|||
|
Aerdan: The second-to-last section of this page has more info about the speed problem. _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jan 23, 2006 8:59 am Post subject: | |
|
|
|
| What special chips are well documented? DSP project, I'm assuming, is near perfect by now, yes? | |
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Mon Jan 23, 2006 7:31 pm Post subject: | |
|
|
|
| Okay,
well, I figured I'd ask, since Seiken Densetsu II/Secret of Mana loads
almost immediately, while FFV [as I mentioned before] does not. I'd
need to do some more testing with other SNES roms, but the ones I've
mentioned thus far [and Super Metroid] are currently the only ones I
have on this machine. [EDIT: And yeah, I forgot Super Mario RPG uses the SA-1. Oops. I think I'll start working on a compatibility list for bSNES, then, if that's okay; mainly so everyone knows what does and doesn't work.] [EDIT 2: If it matters any, my current system specs are: Sempron 2400+ [currently manually clocked at 1.52GHz [as otherwise my mobo'd have clocked it at 1GHz O.o] GeForce FX5200 768MB RAM [1x 256MB, 1x 512MB] Emulation is steady at 60fps once ROMs load, so I think your estimate about minimum/recommand processor speed is a bit high.] |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 24, 2006 1:28 am Post subject: | |
|
|
|
| A compatibility list would be appreciated. The specs are high due to games like Star Ocean and Mega Man X2 which require additional processing power. And then there are games that use hires, e.g. SD3's name entry screen. I can just barely hold ~70fps with full optimizations on an Athlon 64 3500+ that isn't overclocked in hires games... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jan 24, 2006 7:38 pm Post subject: | |||
|
|
|||
Hopefully, you mean a list of what doesn't work, from which we can infer what does work. A list of what does work would be really dang long. |
|||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Sat Jan 28, 2006 8:39 pm Post subject: | |
|
|
|
| only
for interest. Are there books how a Snes works? Where do you get the
basics for understanding how a Snes works? I don't mean the knowledge
what a cpu register does or what a opcode is and so on, only snes
specific. sorry english isn't my first language. |
|
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Mon Jan 30, 2006 1:44 pm Post subject: | |||
|
|
|||
There are lots of SNES hardware specific docs on the net. Here are several good ones. ROMhacking.net SNES Hardware Docs _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed Feb 01, 2006 12:01 am Post subject: | |
|
|
|
| Slighly OT, there was some talk of console emulation in general in the Mame forum (R. Belmont apparently is a big fan of bsnes) Anyway, there was a mention about how poor apparently the current Snes Rom format was...anyone (Nach,Pagefault,Byuu,Grinvader or any knowledgable person) care to explain/have a thought on this? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Feb 01, 2006 12:19 am Post subject: | |
|
|
|
| MK has been saying the same thing for years. We really lose some hardware info when we only have the ROM image. MK wrote up a spec for a new format, which got some people ticked off. I have his spec still, and perhaps byuu and I can actually do something along those lines one of these days. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 01, 2006 2:33 am Post subject: | |
|
|
|
| I would absolutely love to. Overload has a great idea and is documenting all of the cart PCBs. If we could merge that info into NSRT and generate a set of ROMs with that info in it, it would do a lot for ROM detection and handling special mappers such as Ys III's SRAM. Of course, we could also use an external database with a crc32 lookup too, if inserting into ROMs isn't good. Nach, if you'll add the new spec to ZSNES and/or SNES9x, I'll add it to bsnes. |
|
Regular
Joined: 30 Jul 2004
Posts: 229
| Posted: Wed Feb 01, 2006 2:56 am Post subject: | |
|
|
|
| I
still like the idea of a dedicated ROM database like MAME has where the
ROM file names match stamps/labels on the actual ROM chips, and each
game is clearly setup with all needed information. There is no need for
any kind of header this way, and special things like extra CPU's or
special SRAM setups are easy to detect. You could still have a special load option for homebrew/test roms/hacks/etc., but for the commercial stuff have a fully documented list. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Feb 01, 2006 2:58 am Post subject: | |
|
|
|
| If
we can agree on a ROM spec, and have some DB info, I'll add it to NSRT
for mass conversion, and make a lib for ZSNES and Snes9x, possibly
SNEeSe too. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 01, 2006 4:21 am Post subject: | |
|
|
|
| Sounds
good. I'll start on the basics tomorrow. I would like to allow it to
define the entire ROM map, but in 512 bytes that'd be pretty hard
unless we include arbitrary numbers (e.g. a 32-bit mapper number) to
pull that info from a database with. Then again, no reason we have to limit the header to that size. Nach, can we meet up this weekend? I'd like to finalize the patching thing, if possible. Also, I need to start on getting the synchronization more accurate than it currently is. I need to allow the PPU to run every 4 CPU clocks to prepare for the dot-based renderer, and break CPU / APU opcodes into "half-cycles" to emulate the bus hold times for read/write operations. That's going to take an insane amount of planning to pull off without doubling the system requirements :/ |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Feb 01, 2006 5:25 am Post subject: | |||
|
|
|||
Sweet Jesus! (Now with more sodium!) _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Feb 01, 2006 11:20 am Post subject: | |||||
|
|
|||||
Did I ever pass you MK's spec?
I should be around Sunday. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Feb 01, 2006 1:11 pm Post subject: | |||||
|
|
|||||
Maybe you could keep both renderers, via two builds or even switchable at runtime? You really shouldn't worry about system requirements. _________________ savestate editor: vSNES latest public version
|
|||||
New Member
Joined: 01 Feb 2006
Posts: 2
| Posted: Wed Feb 01, 2006 8:48 pm Post subject: | |||
|
|
|||
|
For reference, here are the posts on MAME forums about roms formats and console emulation state-art: Mame thread #1 Mame thread #2
I think the problem is not about head limitation but head itself. We need an independent database file with the info needed by the emulator to be able to execute the rom. We don't need rom heads , like Renzor007 told some posts above. Rom is only rom data found in the cartridge chips... no more no less. The head is extra information needed/added by copiers. If we add extra info in form of head: what's up if we change the head format or some rom info? massive conversion of all/some roms every time? Let roms rest in peace... headless .
We only need to update the database file when change the spec or rom
info, but the rom itself must rest intact. I think NSRT team (Nach et
al) and emulators authors like Byuu, Overload,... must define this
database spec and the NSRT Team mantain the info needed for each
commercial rom.The database file must be in a separated file (like Overload database) and the emulator only need to read this info to know the extra rom info needed to executed the game. The emulator don't need to determine 'every time' all this rom info when the rom is perfectly known. The format of the file could be a simple ini file (like Haze points on mame forum) or something more interesting like an XML file with an associated XSD schema. The problem of the rom names exposed by Reznor or Haze (mamedev), that is to say, to have separated files for each chip with its name associated is perhaps a little more difficult to solve since dumps of snes roms has been made from copiers, that linearly reads all the memory map. Re-dump all the cartridges one by one to obtain the data of each chip again separately is a serious & tedious problem .
Although perhaps it's possible to rebuild that information from present
dumps and cartridge pcb-number. In any case I see it somewhat
unnecessary.That's my 2 cent about the subject Sorry for my poor 'engrish' PD: Completely off-topic: big thanks anomie for your superbs snes docs. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 01, 2006 11:42 pm Post subject: | |||
|
|
|||
|
Agreed. No headers, then. Breaking carts into individual ROM files is stupid if we also have an ini. We can just document what each region of the whole binary file points to. Example: Game X contains 1x8mbit ROM, 1x4mbit ROM, 1x1mbit SRAM game_x.ini =
Obviously, better ways to represent mapping could work, too. Perhaps store pinout information to the address lines for each ROM? Perhaps use regex style ranges? e.g. map="[$00-$3f]:$6000-$7fff" |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Feb 02, 2006 12:51 am Post subject: | |
|
|
|
| Those that don't learn from history are destined to repeat it. byuu, come online we'll talk, there's been interesting info on this subject that's been documented. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Feb 08, 2006 12:26 pm Post subject: | |||
|
|
|||
|
Update! _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 09, 2006 6:30 am Post subject: | |
|
|
|
| Yeah I don't like these new updates. I can understand them Killed me when he talked code all the time. Nice to see you got a new card, byuu. Dig the gaia shot, too. Game rocks. Don't tell me it was random now, cuz I'll cry. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 09, 2006 6:44 am Post subject: | |
|
|
|
| It's because I'm too busy mucking with GUI features instead of working on the core like I should be... :/ I wanted v0.016 to be a mostly cosmetic upgrade. After that's out, it's back to the internals. Planning to split the CPU (and possibly APU) core down into half-cycles so I can synchronize bus hold times between the two. It'll also be needed for a dot-based PPU renderer to be able to dot-step, so to speak. Not looking forward to all the shit that's invariably going to break... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 12, 2006 1:40 am Post subject: | |
|
|
|
| This might sound stupid, but if dot-based is making things more accurate, why would the smaller breakdowns result in more bugs? | |
New Member
Joined: 07 Feb 2006
Posts: 5
| Posted: Sun Feb 12, 2006 3:17 am Post subject: | |
|
|
|
| Are you gona add filters like HQ2X or openGL. also, save states? love the emu great work! _________________ The 2 cowboys have emerged. beware of forum trolls. Joined: 28 Dec 2004 Posts: 605 <------ Last edited by error999 on Sun Feb 12, 2006 7:32 am; edited 1 time in total |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sun Feb 12, 2006 4:09 am Post subject: | |
|
|
|
| Leave your puerile feature requests out of this thread. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
New Member
Joined: 07 Feb 2006
Posts: 5
| Posted: Sun Feb 12, 2006 4:20 am Post subject: | |||
|
|
|||
Maybe you have a reading problem, let me quote my self. "Are you gona add filters like HQ2X or openGL. also, save states? love the emu great work!" key word ARE!. Pointing out the obvious.... I can bash you all day long, but i have no time for little forum trolls. _________________ The 2 cowboys have emerged. beware of forum trolls. Joined: 28 Dec 2004 Posts: 605 <------ Last edited by error999 on Sun Feb 12, 2006 7:29 am; edited 1 time in total |
|||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Sun Feb 12, 2006 4:35 am Post subject: | |
|
|
|
| Error
- just to update you - the main goal of bsnes isn't to have a fancy,
pretty emulator to take the place of Snes9x or ZSNES, but to have an
extremely accurate emulator with good debugging facilities. In concept, bsnes is aimed at romhackers. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Feb 12, 2006 5:00 am Post subject: | |
|
|
|
| In an pathetic attempt to be amusing by overlaying an image over an existing avatar, you have failed. Seriously though.. BSNES's primary goal is for accurate emulation at this point.. not adding features most other emulators already have (I do agree the savestates are probably the most lacking feature at the moment) but don't expect anything fancy just yet. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 12, 2006 6:09 am Post subject: | |
|
|
|
| More bugs because I have to rewrite everything. You never get things right on your first try. The emulator can't handle HQ2X at full speed, at least not on my computer, so probably not. But maybe, it would be good to at least get a single filter in there so others can contribute the code for other filters for me. I'll add savestates when I finish the core to 99% certainty. e.g. new pretty much everything :/ Otherwise, I'd have to keep changing the spec. Anyway, v0.015 is basically about adding GUI features, unfortunately. I need time to plan out how I want to rewrite everything, and when I start it'll be a long time before I can release a new version after that. That said, I have pretty much everything I want done for v0.016. The one I want that would be a royal pain would be to allow GUI key configurations for everything that also worked with joypad mappings. Just a lot of annoying recoding involved to pull that one off. |
|
New Member
Joined: 07 Feb 2006
Posts: 5
| Posted: Sun Feb 12, 2006 7:40 am Post subject: | |
|
|
|
| befour Deathlike2 and the other troll turn this into a flame topic. Wouldent bilinear filtering be easy to add into directdraw, corect me if im wrong. becouse ddw could do this as defalt no? _<(still new to this kind of stuff). i like how clean the source is it's not to hard to find what you need, im tryen to add in some stuff that i wont with my copy, wich gives reason for my asking if you where befour i atemped to even try to add. _________________ The 2 cowboys have emerged. beware of forum trolls. Joined: 28 Dec 2004 Posts: 605 <------ |
|
16-bit Corpse | Nyoron
Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
| Posted: Sun Feb 12, 2006 12:54 pm Post subject: | |
|
|
|
| "ok" _________________ My site with random stuff whicker: franpa is grammatically correct, and he still gets ripped on? sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Feb 12, 2006 2:55 pm Post subject: | |||||
|
|
|||||
error999,
you are sounding more like the troll.. I've contributed some towards
this topic.. and frankly you're acting very much like you are holier
than everyone... the lame avatar and the lame sig pretty much shows
that.
Well, seeing as the savestate spec in ZSNES has changed quite a bit post-1.42, I guess I can't blame you there.
Really? That really does suck.. I'm sure at some point you might spend time optimizing (though, I don't see that happening anytime soon) and make this a more reasonable possibility. Bilinear filtering is still better than nothing I suppose. Getting HQ4x enabled all the time does spoil me a bit. _________________ FF4 research never ends for me. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 15, 2006 1:34 pm Post subject: | |
|
|
|
| Alright, please take a look at the following diagram: Diagram (This also makes a good reference to show more what I'm referring to when I say that bsnes is a cycle-based emulator.) And read this for a more thorough explanation: http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods I'd like to get some feedback on which CPU emulation method I should implement into bsnes. The subcycle one or the clockcycle one? The big advantage of the clockcycle one is the decreased code complexity (and thus, greater readability), especially in updating all of the H/V counter information, and triggering NMI/IRQs. But it doesn't add any additional "accuracy" per se, and is quite a bit slower. One or the other is necessary if I ever hope to get a highly accurate dot-based PPU renderer. |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Wed Feb 15, 2006 2:59 pm Post subject: | |
|
|
|
| I'd say, if you think you can write a "perfect" clockcycle emulator, and it's more readable, then do that. It would be the perfect platform for researching more into nitpicky details of SNES operation, and it would provide a perfect reference implementation for ANYONE to write their own SNES emulator. They could even just start by writing their own core class, and plugging it into your emulator, taking advantage of the object-oriented scaffolding you have. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Feb 15, 2006 8:52 pm Post subject: | |
|
|
|
| I'd say go all the way to clockcycle-based interpretation. There's nothing "more" accurate than that is there? Don't give in to the Need for Speed. You can perfect the emulator now, even if it can't run full-speed. Hell, maybe the overclockers will start using it for benchmarks. Would the simpler code of a clockycle vs. subsycle interpretation mean it would be easier to optimize it in the future? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Feb 15, 2006 9:52 pm Post subject: | |
|
|
|
| I
don't know squat about code, but after reading that I have to vote for
subcycle. You said it yourself - clockcyle is no more accurate than
subcycle, and is a lot slower. Code readability doesn't seem like a
worthwhile tradeoff for that. In this way, I see subcycle as being a
huge optimization in and of itself. Also, on the subject of changing anything at all. The buglist we've compiled is interesting to me in that it shows mostly bugs which do not exist in other emus. This alone tells me that these bugs are possible to fix in the method you have already, because other emus (besides sleuth) use a more simplified method of emulation. As such, it is even worth considering a change at all when the current state seems so hopeful? Again, I can only offer logic. There is probably more to it than that. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 15, 2006 11:00 pm Post subject: | |
|
|
|
| Well,
due to the nature of bus hold delays being variable, I have a way to
implement the core using the subcycle approach, but I'm going to
increment the clock counters and such one cycle at a time. This should
turn a lot of multiplication statements into addition. Maybe I'll optimize it a bit and keep executing cycles until a non-I/O cycle is needed, if I can think of a nice way to do that. The bugs that exist in bsnes but not other emulators are mostly results of simple bugs that are non-obvious to myself. I'm not the best at hunting these things down. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Feb 16, 2006 12:28 am Post subject: | |||
|
|
|||
Word. I agree completely. bsnes is allready -the- most accurate Snes emu,might as well go all the way with regard to accuracy. Even if that result in a loss of speed,it shouldn't be a concern. Faster computer will arive in the future anyway*. *I'm aware of the apparent stall in the speed of today's Cpus and the shift toward multi-Cpus approach (which is,sadly, mostly useless for accurate emus like Mame or bsnes) edit: Also http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods is a great read. Those who'd like to know how different emulators operate at different levels (and how this ultimately affect the end results) should definitely have a look at it. |
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Thu Feb 16, 2006 2:45 am Post subject: | |
|
|
|
| after
a quick look at your emulator (i played zelda alttp) i could swear that
thats how the game was meant to be, on zsnes it just feels a little
weird, maybe even fakeish, but on bsnes it is just awesomness, keep up
the excellent work and i also agree with keeping stuff accurate over
speed. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 16, 2006 4:30 am Post subject: | |
|
|
|
| The
only really obvious difference I've noticed in the NTSC Zelda 3 is how
fast the triangles reach the front of the screen. Some emulators are way off here, especially on the PAL versions. The only problem with speed is that I want to be able to actually use the emulator, too :/ I think I'll go for the "more correct" approach of clock cycle stepping (what I explained earlier), and if the result is just too slow, then I'll add in another CPU core that is opcode-based. Not a total waste because even with an opcode-based core, I still know more about simulating these timing quirks that other top emulators don't do. And on the bright side, that version would be way faster than even the current bsnes. But I'm not too big on the idea of maintaining two CPU cores, so who knows what'll happen. Like DataPath said, bsnes would respond well with its OOP interface. Savestates, if ever added, would not be compatible between the two versions, though. As for CPUs, yeah. I do see the processor speeds still going up slightly, at least for a while. Think about when you have eight CPU cores. A bump of 200mhz is a PR advertisement of being "1.6ghz faster". It's even more fake than the current mhz speed increases are. But ultimately, I expect the speed of each individual core to become less and less of a priority. And scarily, they may even slow them down to reduce heat and power consumption in the future when most software is multithreaded. Multithreading will probably just be one more hurdle that makes software development one step harder for the hobbyist to pull off, compared to the big fortune 500 companies with gobs of BS programmers. There are far too many tasks I can think of that just can't be run in parallel without so many mutexes and locks that the benefits of the multicores are eliminated anyway. Here's to hoping I just don't know what I'm talking about or something. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Feb 16, 2006 5:59 am Post subject: | |||||||
|
|
|||||||
That's something that changed a lot in Zsnes,the speed of the triangles I mean. One version/wip it's correct,the next version it's too fast. I wouldn't have a clue as to the reason of this,but it shouldn't be too hard to figure out for someone that can understand Z's sourcecode and has access to a debugger of course.
Having an optional selectable opcode-based core (for those who haven't paid attention, emulators like Zsnes and Snes9x are opcode-based) in addition to the clock cycle stepping one would be awesome imo.
Ya, unfortunately it looks like muti-Cpus machines (take a look at the 360) is the direction the industry is taking for now...It MAY be a while (maybe even a 'long' while) before we see a real,significant speed increase in single Cpu. I know a few Mame "omgIwannaplayCruiseInUSA-but-it-said-I-Need-a-20GHZ machine" users that are in for a long wait... |
|||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Feb 16, 2006 11:42 am Post subject: | |||
|
|
|||
I think most people are missing the point about multiple cores and multiple CPUs for the average user. The point is to boost what most average users do - MULTITASKING. I want to be able to have one CPU ripping+encoding a DVD, while the other plays some fancy game, not having one program dominate all the available CPU power. Multithreaded should be reserved for OSs, server software, an optional setting for apps that need a ton of power, or used in the cases where it just makes more sense to use threads. Therefore, I think most apps should not be multithreaded, so I don't have to play with priority settings and other nonsense just to do something exspensive and still multitask. And I kind of doubt a lot of the devs out there can even write the apps in a multithreaded way where the costs don't negate the gains. Those making gaming systems with multiple cores, just "don't get it". It's added complexity for no reason, if you need more CPU power, boost the power of the one you have. And contrary to what a lot of people believe, you don't need a fraction of the power that some of these games use today if they would have been written properly in the first place. Unless someone somehow prevents all these developers from accessing fast machines, programs are just going to become bloatware that has it's own bloatware. I shudder to think what development attrocities developers will commit when they're told they have access to 25GB media for the PS3. It's funny to realize that some games were made for the PSX, and took up 350MB on the CD, and after a lot of work, they ported the game flawlessly to the N64 and it's only 16MB there. On the subject of bloatware, bad programming and such in games, I was talking to a Longhorn developer a while back, and he had some interesting info. He was testing a new memory access security feature, and found a bunch of games from one company were no longer working. He did some debugging, and seems they all shared a routine which allocated a lot of RAM, and then accessed it via a bad pointer. The problem here being twofold, whoever the developer was of that routine probably got random crashing, and instead of finding the bad pointer and fixing it, he enlarged the RAM, and it's usage was such that the bad pointer happened to be working within allocated RAM when there was a lot of it. So the games used way more memory than they needed, and they broke when the memory allocation style changed. After patching the bad pointer and setting the RAM allocation size properly, the games started working, and magically had a much smaller footprint, imagine that. On the flipside today, we also have developers who never bother learning what good stable libraries are out there, and pass of their ignorance as slandering the library as being bloatware. They then proceed to recreate the library in a way that seems good to them, which from an algorithmic standpoint is highly inferior, and sometimes introduce bugs; which in itself is the cause of the bloatware. An example of such was one such "wise" developer which ignored std::set and instead created his own class which was some clever array manipulation to contain a list of unique data. His array manipulation was much slower and more CPU exspensive than the Red & Black Tree most std::set implementations use. With Microsoft promoting 6 core game development, and Sony massive media, and both trying to push raw horsepower through the roof, the future doesn't look good. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Feb 16, 2006 12:53 pm Post subject: | |||
|
|
|||
Er I think that's simply because of the Psx using cd-quality audio (Wav tracks and/or Xa), which takes most of the space. |
|||
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Thu Feb 16, 2006 1:14 pm Post subject: | |||||||
|
|
|||||||
Yes, that's often the case (SotN for one). _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 16, 2006 1:34 pm Post subject: | |||
|
|
|||
|
I
agree with your points about what multi-core CPUs are for, although I
doubt the need to perform four or more processes that all peg out the
CPU will be needed anytime soon. I don't ever even see myself playing a
huge game and saying, "You know, I wish I could rip this DVD while I'm
playing and encode it to DivX, but only if I can then also burn this
other DVD I already ripped, render these huge 3D images in a high
quality rendering program, AND compress my 60gb collection of images,
all at the same time with no slowdown. Darn, if only my CPU had more cores..." I think two, maybe four would be the most ever needed. But I'd bet money we'll be hearing about eight core processors shortly after the new four core ones get released publically. And like you said, regardless of whether or not most applications should be single threaded, the hardware vendors will all be pushing for everything to be multithreaded, and those applications that are will be placed higher than single threaded apps when done right.
Perhaps it's easier and more fun to write your own library than learn another new syntax. Especially when you spent the last ten years using functional programming and don't want to jump into object-oriented programming for one of the most basic tasks in the language, e.g. string manipulation, to name a wild example :P |
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Thu Feb 16, 2006 1:42 pm Post subject: | |
|
|
|
| im
pretty sure that what i was talking about was related to your colour
system. also if you add a opcode based cpu will it be a sorta switch
where you switch between which cpu core you want to use? also bs zelda renders your emulator unable to load other roms without closing and reopening your emulator where as in zsnes it just freezes the emulation. (meaning in zsnes you can still load other roms without the need to close and reopen zsnes) also do you plan on adding a feature to disable the sound core like zsnes does? (disable spc emulation) and lastly don't change how your colouring sytem works unless you absoloutly need to because it makes it look awesome! _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Feb 16, 2006 1:47 pm Post subject: | |||||
|
|
|||||
What would be the point of that? Many games depend on it. _________________ savestate editor: vSNES latest public version
|
|||||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Thu Feb 16, 2006 2:09 pm Post subject: | |
|
|
|
| if you havn't noticed disabiling the sound core in zsnes allows the patched version of bs zelda to work. (patched so that it is english and beatable) _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Sun Feb 19, 2006 9:13 am Post subject: | |
|
|
|
| Why clockcycle or subcycle based emulation? It is only for the sake of perfect emulation or are there snes games which doesn't run correctly with cycle based emulation? I mean, can the human eye and ear notice differences between cycle based and clockcycle based emulation? | |
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Sun Feb 19, 2006 9:30 am Post subject: | |
|
|
|
| its for the sake of accuracy and bsnes goal i think is to be the most accurate snes emulator. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Feb 19, 2006 3:24 pm Post subject: | |||
|
|
|||
The human eyes and ears are limited and most people only notice the most God-obvious bugs and not the small stuff anyway.So when you have an accurate emu you know the games are emulated correctly. And using your above logic,we should just hack away all the games that are problematic. I mean,if most can't tell the difference anyway. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 19, 2006 8:45 pm Post subject: | |
|
|
|
| Compared
to an opcode-based CPU emulator, it will fix a few bugs, especially in
the area of really sensitive NMI/IRQ/HDMA games. Compared to a cycle
based one, you probably won't notice the difference. The difference is only really noticeable for the dot-based PPU renderer. In a sense, I need to use a subcycle or clock based core in order to accurately time when writes to video registers mid-scanline actually take effect. Although I'll never get close to getting the PPU renderer perfect, it'll be nice to actually try to emulate mid-scanline effects to an extent. And no, no game actually uses mid-scanline effects to my knowledge. They'd be unbelievably difficult to pull off in real-time. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Feb 20, 2006 2:27 am Post subject: | |||
|
|
|||
Yep, that's the idea...To create the most accurate SNES emulator. Think of it this way, bsnes will basically be the SNES equivalent of what Kega is to the Sega Genesis.
|
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Mon Feb 20, 2006 2:30 am Post subject: | |
|
|
|
| i would think that gens is better then kega but since ive never used kega i cant compare. now back on topic people. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Feb 20, 2006 2:42 am Post subject: | |||||
|
|
|||||
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Feb 20, 2006 2:44 am Post subject: | |||
|
|
|||
Errr, No. Again think of it this way, the goal for bsnes is accuracy. With Kega it is the exact same thing (And it's allready almost there). Kega is better than Gens in many aspects (Just like I think bsnes is better than ZSNES/SNES9x, in my own opinion of course). Last edited by King Of Chaos on Mon Feb 20, 2006 2:52 am; edited 1 time in total |
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Mon Feb 20, 2006 2:52 am Post subject: | |
|
|
|
| ah ok i must have been asleep sorry... it now makes sense. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Feb 20, 2006 2:59 am Post subject: | |
|
|
|
| Anyways, keep up the good work byuu. P.S. Thanks for restoring my faith in SNES emulation. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Feb 20, 2006 4:33 am Post subject: | |||
|
|
|||
Although Kega does have a large number of features, unlike bsnes. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Feb 20, 2006 4:53 am Post subject: | |||||
|
|
|||||
Yes, that's because Kega has matured over a long amount of time. bsnes is still growing up...And it will, someday.
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 23, 2006 3:56 am Post subject: | |||||
|
|
|||||
Alright, I'm a little confused by the direction bsnes is heading. Cycle-based was the perfect accuracy/performance hybrid. So, now let me get this straight... it's being ditched for less accurate opcode and a method that is unusably slow? Wha...? |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Feb 23, 2006 4:30 am Post subject: | |
|
|
|
| He's gonna do both. One's going to be very accurate and very slow, the other is going to be much faster, and playably accurate. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Thu Feb 23, 2006 4:52 am Post subject: | |
|
|
|
| And being able to swap one CPU core out for another, keeping the APU and PPU units the same should make it possible to debugging and tweaking an opcode-based emulator pretty effective | |
Veteran
Joined: 28 Jul 2004
Posts: 991
| Posted: Thu Feb 23, 2006 4:59 am Post subject: | |
|
|
|
| Would it be stupid to code Clockcycle based emulator in basic? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 23, 2006 5:59 am Post subject: | |
|
|
|
| I
change my mind a lot. Basically, I want more accuracy than I currently
have. But unfortunately, making things more accurate than they
currently are would render the emulator unusable on most hardware. So, I get my way and have more accuracy, and throw in an opcode-based core as well, so it runs fast on older hardware. It's a compromise. More people use bsnes, more people submit bugfixes, everyone wins. I'll mostly be focusing on the clockcycle-based core, of course. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 23, 2006 7:04 am Post subject: | |
|
|
|
| I'm
not at all surprised by the clockcycle endeavor. That sounds cool, even
though no one will actually be able to use it for about 10 years... and
no actual games will gain accuracy... The opcode thing struck me as
strange, though. I think it's nice to consider people with older hardware, but to some extent that niche has already been filled by older emus (which will still be much faster anyway). And that 30% speed increase you speak of: could that or near that not be gained from optimization of current code? Additionally, the advantage of having more people able to submit bugfixes isn't really an advantage when you consider that going opcode is going to be introducing those bugs. As for wanting to gain users in general, I gaurantee that savestates will probably have more a say in gaining users at this point than a 30% speed increase. You'd be amazed by how alluring this convenience and semi-cheat feature is. I'd even go as far to say that the average joe is not using your emu over others for this feature alone. He doesn't want to be faced with the prospect of losing and starting over! Accuracy and sound quality be damned! You also said that opcode is inherently flawed and cannot achieve perfect synch without hacks. Sounds like a good idea for starting an emu 7 years ago. Sounds like a lost cause today. With as few bugs as you have now (debugger hopefuls, too), I see this switch as strange and untimely. Something tells me there is more to all this than meets the eye... |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Thu Feb 23, 2006 7:53 am Post subject: | |
|
|
|
| This might come off as ignorant, but I'm just not sure about the answer. Is it really not possible for a 3000+ MHz machine to accurately emulate a 5 MHz machine at full speed? While I realize that there's a lot more to it than clockspeeeds, I'm just imagining that a decent pc by today's standards should be able to flawlessly run a accurate snes emulator without speed issues. I also realize that the emulator is in it's early stages, so I guess my question is more of a future thing. Will bsnes be optimized once the main core is done, or can it even be optimized enough to matter? I guess why i ask is because i would like to use it. it sounds FABULOUS, and the controls don't lag in it like they do with zsnes, whatever the reason may be. however, my aging 1.4 athlon isn't beefy enough to handle it. _________________ |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Feb 23, 2006 11:25 am Post subject: | |||||||
|
|
|||||||
|
sweener2001: Have you read the text at the end of this page?
You could add HQ?x...
Depends on your compiler. Some people are saying that FreeBasic is a good one. _________________ savestate editor: vSNES latest public version
|
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 23, 2006 1:08 pm Post subject: | |||||
|
|
|||||
|
One
of the rules of programming is to write clean, complete code first, and
optimize later. Yes, I'm sure I can increase the speed some later on
when everything's working fine, but I'm generally opposed to using ugly
hackish code to speed things up. The speed problem has little to do with the clock rate of the SNES CPU. It has to do with keeping four separate chips in perfect synchronization. CPU, PPU, APU and DSP. The overhead increases exponentially as you get closer to hardware. So take the CPU, which executes 2-8 cycles/opcode, and 3-6 clocks/cycle. At 21.477mhz (internal clock rate), you get: 10,738,636 calls a second to synchronize from the CPU alone for clockcycle-stepping 2,386,363 for cycle stepping 477,272 for opcode stepping And given that sync overhead is way greater than the actual CPU logic emulation, it's easily well above 22x more processor intensive to do things this way. Which is why it's never been done before by any emulator I'm aware of.
For one, I'd like to actually be able to play the emulator myself. Sorry that it bothers you so much, but accuracy is still the main priority by and large.
I was suggesting others do this :P I just wanted the filter ability there for the SNES NTSC filter. |
|||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Thu Feb 23, 2006 1:45 pm Post subject: | |||
|
|
|||
That's just it, emulating the 3Mhz CPU is basically NOTHING. You can do that with a Pentium 1. The enormous amount of extra power comes from emulating and synchronizing the rest of the system. When you need to syncronize the system, that in turn makes you have to use some MUCH more expensive methods to emulate the CPU as Byuu has been talking about and as he said, that's probably still NOT the speed bottleneck. Things become even more complex because the SNES, while truly and technically by nature renders by scanline, it is capable of changes mid scanline which requires you to do dot by dot rendering in your emulation if you want to be really accurate and catch all this. The complexity just grows exponentially. So get the CPU and CPU speeds out of your head because they don't mean much of anything. It's all in the syncronization and techniques needed to emulate the rest of the system. Hope that helps. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Feb 23, 2006 7:18 pm Post subject: | |||||||||||
|
|
|||||||||||
It doesn't seem strange to me at all. If I *had* to choose one core, then of course I'd choose the accurate clockcycle one. Even if it turn out to be too demanding to run fullspeed on a 3.0Ghz cpu. But having the option available to the user, that's the best of both worlds. I'm against innacurate 'emulation'. But I'm not against an 'option' for less accurate but faster emulation because I could always use the accurate core. I don't find it contradictory. I just call it "choice is good".
My guess is that even when bsnes would run with the opcode base core it would still exhibit 'way' less issues than Zsnes or Snes9x.
You could just say "don't report bugs when using the opcode core".
Allright just to make sure: You DID understand that it will only be an 'option' and that the accurate core 'will' remain,right? In fact,the reason why Byuu is considering a second,opcode based core is because bsnes is gonna be even 'more' accurate in the future (and thus, even slower) |
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 23, 2006 9:21 pm Post subject: | |||||
|
|
|||||
Actually... I was thinking that going opcode would make it easier for someone else to fix things, add things, and that you might have been in talks with that person. I never would have assumed that with your recent upgrade, you wouldn't be able to play your emu fullspeed. Obviously, that isn't bothersome to me. But my god, your comp is more powerful than mine... what's wrong? |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 23, 2006 9:48 pm Post subject: | |||||||||
|
|
|||||||||
Somehow, my point eludes you. Best of both worlds? The best of both worlds is a cycle core and a clockcycle core, not an opcode and a clockcycle. And "too demanding for a 3.0ghz cpu? Try too demanding for a 10ghz cpu, and with the multi-core fad taking off, you might not see that for another 15 years.
I don't doubt this. But I can't presume to know what the actual result will be. Those emus have been in development for years, and timing bugs that existed then still exist today. Byuu says he's not too great at tracking things like this down, so the first result could seem great, but the bugs could become a nightmare. But perhaps byuu will surprise us yet again.
I'm not entirely sure what you mean by this. Please re-read my statement. Bugfix is not a bug report.
The accurate core will not remain, if you're referring to the cycle core being used today. Cycle is being discontinued for an unusable clockcycle core and an opcode core that is inherently inferior to cycle. It's a double loss. I'm not sure you're fully informed about the "more accurate" future either. Clockcyle will not bring any additional accuracy over cycle, because no games perform the things that clockcycle will enable. Feel free to disagree, it is the bsnes thread. |
|||||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Feb 23, 2006 10:06 pm Post subject: | |||
|
|
|||
Yes but those emulators were started long ago when much less was known about the SNES. And some of those bugs are really hard to fix just becuase of the long, incremental development of those emulators. Byuu could probably make a quite nice opcode-based emulator. Why would byuu forsake the cylce-based core for a clock-cycle core? Because he wants to push the limits of SNES emulation accuracy. Speed is a secondary/tertiary concern. Here's an idea: perhaps the cycle-based core can remain as-is in bsnes. We shouldn't lose the progress made with the cycle core. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 23, 2006 10:19 pm Post subject: | |||||
|
|
|||||
Ok, before I hear this argument again, think about how ludicrous it sounds. We have a list of ~25 known inaccuracies that actually afflict games on the first page of this thread. Clockcycle will fix none of these. Instead, it will enable the performance of an operation that does not exist in any game. Are we done defending clockcyle with "accuracy" now? Is there a soul on this planet that will use this option, even 15 years from now, with the knowledge that it will do nothing but increase your energy consumption? |
|||||
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Thu Feb 23, 2006 10:43 pm Post subject: | |
|
|
|
| Alright, that makes perfect sense to me now. Thanks for the great answers, and thanks for a fantastic emulator. _________________ |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Feb 23, 2006 10:45 pm Post subject: | |
|
|
|
| Well, perhaps it's more of a theoretical exercise for byuu, not about playing games. Perhaps we can convince him to maintain the clock-based core, and not introduce an opcode core, since the clock-based core isn't too horribly bad. And then he can do what he wants with the clockcycle core. Or, maybe we'll see an opcode core that is still very compatible. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 23, 2006 11:56 pm Post subject: | |||
|
|
|||
It will affect every game, actually. The order of executed operations will change quite a lot. Whether or not that's visible on screen, I thought I've made abundantly clear by now that I could care less. I've said right from the beginning that I'm more interested in emulating the hardware. But yes, every now and then I like to fire up Mega Man X2 and play through a few levels on bsnes. So occasionally I'll add some frivilous GUI stuff here, some special chip there, little things. I haven't really done much since v0.015, I've just not had much time to program as of late :( You make a good point, though. I could keep the current cycle-based core instead of the opcode-based core. My opinion was that if it wasn't all the way accurate, why not just go for speed? No point in striking middle grounds. But if everyone disagrees with me, that's fine. System requirements will remain the same for the current breed, and much higher for the new breed of core components (going to do this for the PPU, and possibly the APU, even though no information is known on APU bus hold times). It'd save me time anyway to not have to write an opcode core. If I do this, I'm at least removing the pseudo-hold delays on reads and writes. They slow things down a lot and since they don't actually sync the chips, all they do is correct latch counter reads, which "affects nothing" as you put it. And as I said, I don't like hacks, which is exactly what the cycle core is doing now. This will be an easy 10% speedup, and the clock core will do it the right way. Also, 10ghz is a bit sarcastic. 5-7ghz will do just fine :P |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Feb 23, 2006 11:58 pm Post subject: | |||||||
|
|
|||||||
Ok sorry, I misunderstood you. So your main "beef" is with the future clockcycle core as opposed to the curent cylce-based core.I could understand your reaction if it was a 'downgrade' in term of accuracy...but unless I missed something it IS even more accurate than the current cycle-based core. edit:More specifically, you'd prefer a cycle+clockcycle instead of a opcode+clockcycle. And Byuu said he needs this core in order to achive his new dot-based renderer: quote
Ok, too demanding for a 10ghz (i.e: anyone's computer) then. For me that's a non-issue. Like I mentionned before,Mame has some drivers that demands 20Ghz machines and I still believe it's a non issue. Bottom line: With the clockcycle core Bsnes would reach an incredible level of accuracy = what matters most AND as an added bonus it would give the users the choice of an opcode based core that's playable on a 1.5ghz (or less?) and much mores solid then the current opcode based emulator like Z and 9x (i.e: the only thing we had before b* 'anyway') So yeah, I'm not gonna complain! Perhaps Byuu could go triple core (opcode,cycle,clockcycle) if he felt really generous but personally I feel there's no need for it. * Imo, bsnes deserve a Upper case 'B'!
|
|||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Feb 24, 2006 12:21 am Post subject: | |||
|
|
|||
Unless of course your mind is allready made up, but if you really don't have a strong preference between Opcode/Clockcycle or Cycle/Clockcycle then we could perhaps do some sort of poll maybe? |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Feb 24, 2006 12:43 am Post subject: | |
|
|
|
| I have a question about SNES emulation in general. Is this kinda how SNES emulation works right now: CPU - APU - PPU - DSP: Execute freely, independant of each other, until next sync. CPU - APU - PPU - DSP: SYNCHRONIZE CPU - APU - PPU - DSP: Execute CPU - APU - PPU - DSP: SYNCHRONIZE ? Is it possible to kind of, combine all four processing units, so they are constantly executing in sync with each other? Just a random thought that I had. Probably not worth anything. EDIT: Nevermind. The processors all run at different clock speeds right? That would prevent any "combination" of the processors, probably. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ Last edited by Jipcy on Fri Feb 24, 2006 3:04 am; edited 1 time in total |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Feb 24, 2006 2:10 am Post subject: | |
|
|
|
| I haven't posted here in a long time. Been very busy with C64 & Genesis stuff since Kega & Vice were the only accurate emus of 8-16 bit systems that I own. I heard abt this new emu called Bsnes so finally decided to give it a try... When trying it for the first time, it totally blew me away. Finally a Snes emu which main goal is total accuracy like Kega. Byuu, I'm totally impressed with your work and became an instant fan. The quality of it is on par with that of SteveSnake's Kega only you still need more time coz Bsnes is still fairly new but quality always shines through. From now on Bsnes is my primary choice for Snes emulation and thanks to it I'll be more in the mood again for playing snes games. Keep up the great work! @KingOfChaos: nice to find you here as well, hehe. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Feb 24, 2006 2:26 am Post subject: | |
|
|
|
| Accuracy
is a must. I can run basically any game at full speed with it only
using 50% of my overall system resources (3.2Ghz P4, 1 Gig RAM). In my opinion, hacks are a big NO NO. Besides, it won't be long till we see 4-5Ghz processers. *waves at Sith* |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 24, 2006 6:46 am Post subject: | |||||||||||
|
|
|||||||||||
I always understood your rationale for clockcyle. You're a perfectionist. For the same reason, I didn't quite understand dropping a perfectly wonderful cycle core for opcode.
If you think you can pull it off without introducing many new bugs, then I'm of the same opinion as you. However, the cycle core is plenty fast for 2ghz and higher, it's more accurate, and it's already been written. That saves time for you, and possible future headaches trying to work with a more finicky core. I don't agree with dmog's optimism. I don't think it's worth the effort or the risk for 30%. Especially when computers have never been cheaper, and 2ghz has been low end for over a year.
Absolutely.
Nice! I had no idea there was something like this present. So long as it has no effect on games, what an easy optimization. I like to see you thinking like this. In the end, you can always do as you will. I have always been aware that bsnes was a quest for hardware accuracy and not a program for us lowly gamers. But in doing this, and making it playable, you've inevitably garnered yourself a userbase that is as enthusiastic about experiencing accuracy as you are seeking it. And yet you haven't ignored our discussions or the community that you never intended to create... you've given and you've gained. I honestly believe that.
|
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 24, 2006 7:32 am Post subject: | |||||||||||
|
|
|||||||||||
The SNES runs all chips at the exact same time. What I do is see which of the four chips are the farthest behind in being run, and then run that chip as little as I possibly can, update its clocks (updating the CPU clock is the #1 most intensive function as revealed by code profiling), rinse, repeat.
Really? It doesn't even sleep, so it should be eating 99% and sitting idle anyway. That's cool, so you can probably run 2x mode (120fps) with no sound breakup. ToP's intro sounds awesome like that. I have to use frameskipping for that.
Thanks, I've always been a big fan of Steve's work since the original KGen for DOS.
Goes with the territory of being obsessive compulsive. So, anyone want to speculate the system requirements of bsaturn, which was what I was initially planning before deciding to go with the SNES instead? :)
Well, you were just commenting on accuracy gains that won't be "visible". The differences between opcode and cycle aren't "visible" in most games. Surely they will be in Earthworm Jim 2 and such, but not in the majority of games. It's mostly all the speed hacks and stuff that cause the problems in the top SNES emulators, I think. For example, a certain emulator doesn't even count clock cycles for the APU emulator, you know? Every APU opcode is treated as being equally as long. Absolute genius for the time it was made, and that it works so well even to this day. I'd have never thought of that myself. Before bsnes, xkas was the most widely used program of mine. It had a userbase of six people. With so many users, I feel kind of obligated to make it a little more user friendly than I usually make my programs. Speed is a major concern for a lot of people, even though I agree that 2ghz isn't that big of a deal since they typically cost less than $100 new, half that used. As always, thanks for the kind words all. I'll likely be posting a WIP build this weekend or next. |
|||||||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Feb 24, 2006 11:28 am Post subject: | |||||
|
|
|||||
Erm, more than 10 GHz... ? EDIT: Just wanted to add that speedrunners don't need 100% real-time speed... _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Fri Feb 24, 2006 12:50 pm; edited 1 time in total |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Feb 24, 2006 12:22 pm Post subject: | |||||||||
|
|
|||||||||
I hope you didn't meant that literally...It sounds a bit like "I only care about the speed and playability of bsnes as it has (way) less bugs and issues then Zsnes"
No idea either A wild guess would be: Future M.e.s.s Saturn emulation 3X requirements = so yes more than 10ghz.
Nestopia also deserve a mention! unless you really,truly hate Nes
|
|||||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Feb 24, 2006 6:50 pm Post subject: | |||
|
|
|||
Sweet Jesus, thank you! _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Feb 24, 2006 7:05 pm Post subject: | |||||||||
|
|
|||||||||
_________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|||||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Feb 24, 2006 9:13 pm Post subject: | |||||||||||
|
|
|||||||||||
Someone wrote on wikipedia, I dunno how valid that info is, that Steve Snake hinted that he may consider emulating the Saturn. (thus emulating every Sega console before the Dreamcast). Did you heard something to that effect? Knowing what an emulation God Steve is, that 'would' seriously rocks.. |
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 24, 2006 9:51 pm Post subject: | |||||
|
|
|||||
I'm a little confused by your accusation. I think I'll need an elaboration before I even attempt to defend myself. |
|||||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Feb 24, 2006 10:03 pm Post subject: | |||
|
|
|||
Actually it was on a post by me that he responded, hehe. I said sth like "We need at least 5GHz for decent Saturn emulation" ...and Steve replied with "Nah, just a better emulator "I would think that's a good teaser that he's at least considering it. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Feb 24, 2006 10:13 pm Post subject: | |||||||||||||
|
|
|||||||||||||
Ok,exageration on my part perhaps. You did express concern over bsnes's future speed though:
No "accusations" I just think speed shouldn't be a big concern. |
|||||||||||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Feb 24, 2006 10:35 pm Post subject: | |||||
|
|
|||||
Yep, using 2x mode (120fps) only uses 61% system resources with no sound breakup. (That's with multiple programs open, including iTunes and MSN messenger).
|
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Feb 24, 2006 11:45 pm Post subject: | |||||||
|
|
|||||||
As for me I'm excited by Blargg's NTSC filter! It's allready been implememted in Nestopia and it's 'amazing'. A-ma-zing seriously. It's the closest thing to a TV display you'll find on a Pc monitor. Can't wait it being implement in bsnes.Blargg did an amazing job. Oh and here's the complete bsnes news. I hope there's no problem copy-pasting it here:
By now,I guess it's getting redundant to say 'bsnes is getting more amazing each new update' but I can't think of another of way saying it
|
|||||||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Feb 24, 2006 11:58 pm Post subject: | |
|
|
|
| So Bsnes will have a plugin system like Kega? Cool! And yes, you'll always find ppl willing & able to write plugins. Kega currently has 20. Because Bsnes is damn good too, response for that should be quick. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Feb 25, 2006 12:04 am Post subject: | |||
|
|
|||
Ot question, but do you think there's any chance that this might cause input delay? I know what everyone is thinking: "What does rendering has anything to do with input responsiveness?" Well I'm not sure how it works either, but from what I gathered it can have an impact. I'm asking because bsnes is one of those emu completely free of any lags even when triple buffering is on. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Feb 25, 2006 2:30 am Post subject: | |||||||||
|
|
|||||||||
You
can maybe get SNES9x-level saturn accuracy with 5ghz. Which, really, is
good enough for that system. The faster the system, the less critical
perfect timing is.
Heh, I was under the impression everyone wanted me to avoid filters as they aren't needed. I only added the Scale2x filter in <10 minutes to test out the system for blargg's awesome SNES NTSC filter. I can make more if people want them. I have some ideas for my own filters at this point.
Amazing. My 3500+ gets 80-100fps -tops-. I realize that's 1ghz slower, but everyone always remarks how slower Athlons match faster Pentiums... looks like I might just have to buy Intel (and a higher wattage PSU) next time I upgrade :(
Internal only, but yes. Anyone is free to submit drivers and I'll add them in.
Nah, it'll be equally as responsive. This new code is inserted between two parts where the SNES is technically completely paused. |
|||||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Feb 25, 2006 3:15 am Post subject: | |||||
|
|
|||||
Well, I like the ScaleXx filters in particular. I like the way they look better than HQXx filters. Although I have noticed that the ScaleXx filters create some odd artifacts where HQXx does not. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Feb 25, 2006 10:14 am Post subject: | |
|
|
|
I saw the scale2x screenie. It looks stunning. As for wanting more filter  s, I'm sure someone will register soon to tell you their dying wish is vertical scanlines. |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sat Feb 25, 2006 4:18 pm Post subject: | |
|
|
|
| I love filters coz they make images less blocky. Filters are very usefull with 8-16bit systems coz of their blocky resolutions. Byuu, I hope you will include 2xSaI. It's my favourite. On a different note, could you include an 'assign path' feature for .srm files coz I like to have them in a seperate folder. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Feb 25, 2006 4:38 pm Post subject: | |
|
|
|
| byuu, can you add faster settings? I wanna push this thing to the max. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Feb 25, 2006 7:45 pm Post subject: | |||
|
|
|||
You can't add Scale2x without breaking the license, sorry. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Feb 25, 2006 8:32 pm Post subject: | |
|
|
|
| What exactly is different with the Scale2x license than with most of the others? I presume it is literally the reason that it was not implemented on ZSNES. _________________ FF4 research never ends for me. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Feb 25, 2006 8:47 pm Post subject: | |
|
|
|
| Well,
Scale2x appears to be licensed under the GNU GPL. I don't know what
specific incompatibilities exist between it and bsnes's license. I don't think that's why Scale2x isn't in ZSNES, though. Seeing as ZSNES also is licensed under the GPL. I think it's really just no one has bothered adding it. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Feb 25, 2006 8:51 pm Post subject: | |||||
|
|
|||||
Most of the other what? bsnes doesn't implement any other filters.
Scale2x license is compatible with ZSNES' _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Feb 25, 2006 8:58 pm Post subject: | |||||||
|
|
|||||||
I meant the other filters. I thought there was a reason as to why Scale2x was not implemented on ZSNES, but that's not the case apparently. Is there any reason why Scale2x isn't implemented in ZSNES then? _________________ FF4 research never ends for me. |
|||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Feb 25, 2006 9:00 pm Post subject: | |||
|
|
|||
Because no one implemented it. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Feb 25, 2006 9:33 pm Post subject: | |||
|
|
|||
|
I
did not use Scale2x' source code. I wrote my own implementation of it.
The algorithm itself is trivial, and as far as I know, was initially
created by a programmer at a game company (LucasFilm?). I actually read the algorithm off of a web forum post somewhere. Of course, now I can't find a damn bit of information on it anywhere. It's as if the post vanished from existance, but it has both the algorithm and link to the history of the filter effect, which was supposedly made before scale2x. Anyway, there's also this on the main sourceforge page:
My source is open, too. And anyone is free to use it for personal reasons. It is not compatible with the GPL because I don't "allow" (note that I can't stop anybody) forks of my emulator. Sorry, call me egotistical or hating of freedom or whatever you want, but I've spent nearly two years on bsnes and I don't want some nobody to come along, add one important missing feature, and rename the emulator and do what he wants with it, as has happened countless times to SNES9x. Sorry, I just don't agree with forking. If you don't like my work, great! Make your own, and feel free to look at the code to mine when you get stuck on something. Or better yet, fix the shortcoming in my work, and send me the change. There's a 99% chance that if it isn't a retarded idea, I'll add your code in. Back to scale2x -- it consists of turning one pixel into four. For each of the four pixels, check the two pixels by its side (for the top left, that'd be the top pixel and left pixel, etc), if they match, make that the new topleft pixel; otherwise, use what's already there. Being able to hold rights to an idea that can be expressed in a single sentence is a horrible precedent. However, if the scale2x author wants me to remove scale2x from bsnes, I'll be happy to comply. |
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Sat Feb 25, 2006 9:42 pm Post subject: | |
|
|
|
| Do you guys just want a forum for bsnes so we can avoid this 1000000 page thread business? | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Feb 25, 2006 9:46 pm Post subject: | |||
|
|
|||
Then you have nothing to worry about. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sat Feb 25, 2006 9:52 pm Post subject: | |||
|
|
|||
_________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|||
Redneck Gamer-Mod
Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
| Posted: Sat Feb 25, 2006 10:40 pm Post subject: | |
|
|
|
| I agree, IF you don't think _Demo_ would mind. Not that I think he would. _________________ SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!! Steelers no longer officially own your ass. Pittsburgh will miss The Bus. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Feb 25, 2006 11:15 pm Post subject: | |
|
|
|
| Yea, A seperate forum is a good idea. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 26, 2006 2:23 am Post subject: | |
|
|
|
| Sorry pagefault, I've been meaning to address this for a while now. No need to make bsnes' message board here, since this board is supposed to be for another SNES emulator :) I'll talk to Derrick (my web host) about setting me up a canned message board ala phpBB. I've been meaning to write my own for a while now, but I just don't have the time. I appreciate the hospitality in the mean time very much. Give me until next week and it should be up. |
|
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Sun Feb 26, 2006 10:43 am Post subject: Cheat thing. | |
|
|
|
| Is there going to be a cheat thingy on the bsnes? Have you thought about adding one on it? The ZSNES and some others have one already built in. Btw: I think scanners will be great to see on the bsnes. Please continue working on the scanners built in. Oh how about adding a roms scanner instead having it open a folder path. (There too many snes roms and open a path is a slowdown to me.) After it scan all the roms, you can click on it to play. Very nice and better this way. Look at ZSNES for exsample. |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Sun Feb 26, 2006 2:09 pm Post subject: | |||
|
|
|||
Ah it's no problem. I just thought it would make it easier for everyone. |
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sun Feb 26, 2006 4:02 pm Post subject: Re: Cheat thing. | |||
|
|
|||
Probably. But you'll probably need a powerful machine to run it.
|
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sun Feb 26, 2006 5:18 pm Post subject: | |
|
|
|
| There's still a lot of stuff Byuu needs to do, so don't expect everything to be implemented at once. Rome wasn't built in one day either, you know... _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Sun Feb 26, 2006 8:07 pm Post subject: ... | |
|
|
|
| Where is a bugs report area for the bsnes. I found 3 bugs on the bsnes v0.015. byuu, check your pm please. I send you the bugs report. |
|
16-bit Corpse | Nyoron
Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
| Posted: Sun Feb 26, 2006 8:31 pm Post subject: Re: ... | |||
|
|
|||
There will be one when bSNES gts its own forum section. _________________ My site with random stuff whicker: franpa is grammatically correct, and he still gets ripped on? sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really. |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Feb 26, 2006 9:44 pm Post subject: Re: ... | |||
|
|
|||
You can post them here for now I suppose. Though please don't tell me one of those bugs have anything to do with 'Mario Kart'... (or any special chip not implemented) |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Mon Feb 27, 2006 12:36 am Post subject: Re: ... | |||||
|
|
|||||
That's much better than bugging Byuu all the time abt things he already knows... _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|||||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Mon Feb 27, 2006 2:49 am Post subject: | |
|
|
|
| Or, you could just go use NSRT, which gives more information than ZSNES does and tells you if your ROM is corrupt. | |
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Tue Feb 28, 2006 5:48 pm Post subject: | |||
|
|
|||
I didn't know what NSRT was before and didn't bother to find out but now that I have, I can't be without it any more. Nach really did a great job with this. Edit 03/02: Nice 'About box' art Byuu. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam Last edited by Sith on Thu Mar 02, 2006 11:29 pm; edited 1 time in total |
|||
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Thu Mar 02, 2006 11:13 pm Post subject: Yep. | |
|
|
|
| bsnes_030206.jpg shown on his website look nice. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Mar 03, 2006 4:15 am Post subject: | |
|
|
|
| Thanks, hope I'm not forgetting anyone on the about screen this time. The art makes the program bigger, but it makes it feel less stiff to have some visual style in there, so what can you do right? Gotta figure out how to add little icons to the menu options, that would look good. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Mar 03, 2006 5:53 am Post subject: | |
|
|
|
| I see you added the controller image back in, despite your awesome idea to position buttons in the shape of one. Why? On the subject of style, SNESGT has great icons. The program icon of the super famicom console is really well done. Maybe you can mooch some of them off him. Okay, so maybe that won't happen officially, but I always have the ability to rip and replace icons from exe's with iconcooleditor for my own tastes. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Mar 03, 2006 7:19 am Post subject: | |||||
|
|
|||||
Unfortunately the lower right edge looks a bit dark on the gray that is the default menu background - fixable though. _________________ savestate editor: vSNES latest public version
|
|||||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Mar 03, 2006 4:37 pm Post subject: | |||
|
|
|||
Agreed, that is a great setup, plz don't ditch it Byuu... Maybe you could place a controller image fitted behind this setup? _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam Last edited by Sith on Fri Mar 10, 2006 7:30 pm; edited 1 time in total |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Mar 03, 2006 5:19 pm Post subject: | |
|
|
|
| No,
it's still in there, it's just that now a controller image accompanies
it. I guess I just saw it as redundant. Plus, I only see that window
once every... ever. I think it would be cool if the images were pointed to outside the exe. That way, the user could customize the art, or remove it entirely. Maybe I'm asking too much. I'll shut up now |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Mar 03, 2006 5:33 pm Post subject: | |||
|
|
|||
|
I did that with vSNES... turned out to be not so great (since they're not visible at design-time). The user can always exchange the EXE ressources, or recompile the source if s|he has the compiler. _________________ savestate editor: vSNES latest public version
|
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Mar 05, 2006 9:03 am Post subject: unified rom database | |
|
|
|
| Any updates on the rom database?? i would like to help out get this off the ground! | |
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sun Mar 05, 2006 4:28 pm Post subject: Re: unified rom database | |||
|
|
|||
Huh? Wrong thread, man. That's NSRT stuff. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam Last edited by Sith on Fri Mar 10, 2006 7:31 pm; edited 1 time in total |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Mar 05, 2006 4:45 pm Post subject: Re: unified rom database | |||||
|
|
|||||
Actually nash and byuu where working toghether to create a new database that will be included in both NSRT and bsnes/zsnes |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Mar 05, 2006 7:35 pm Post subject: | |
|
|
|
| SNESGT
has one awesome configuration screen, wish I knew how to make that
control he uses where you have a list with expandable entries and
listboxes / radioboxes inside. I could greatly simplify the UI and add
a ton more functions to an "advanced" section. Anyone know if that
control is part of the common controls? :/ Someone wanted the controller art back in there after I took it out, so I shrunk it and stuck it on there. Wouldn't look good behind the buttons. Don't want the art outside the EXE because it adds extra files. I'd like to keep the requirement of there only being one file necessary to run bsnes, the main exe. It auto generates the config and still works even if that fails. I guess I could just make an art/ folder and make it just skip drawing if the image doesn't exist. I don't think anything's happened with the ROM database. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Mar 05, 2006 9:04 pm Post subject: | |
|
|
|
| Yeah, it is pretty cool. You might lose convenience with some things, but it's neat to do it that way since many settings require a new window to open anyway (video filters, controller cfg, save paths). With this, you have one window opening for all. | |
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sun Mar 05, 2006 9:17 pm Post subject: | |
|
|
|
| Thanks for the info Byuu, keep us posted. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Fri Mar 10, 2006 2:47 pm Post subject: | |||
|
|
|||
|
http://rapidshare.de/files/15154041/bsnes-patch-2006-03-10.zip.html bcpu_mmio.patch fixes Castlevania - Dracula X bdsp.patch fixes the sounds in Earthworm Jim 2 bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code dinput.patch and ui_ppucfg.patch both fix macros for GCC Makefile.mingw can be used to compile bsnes with msys/mingw/gcc bsnes.exe is compiled without the DSBCAPS_LOCSOFTWARE flag because software sound mixing causes high cpu usage on my computer. A config file option for this would be useful.
TreeView |
|||
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Fri Mar 10, 2006 6:16 pm Post subject: Re: | |
|
|
|
| Edit. Everymine it my computer problem. Anyway thanks for the fixs on the games. _________________ "Zsnes is the best one there is." |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Mar 10, 2006 11:23 pm Post subject: | |||||||||||
|
|
|||||||||||
Awesome!!! You so totally rule! Thanks a million, as always :D
Hell! I've been trying to fix that one for weeks. Grah, I've been meaning to test what happens when you start a DMA transfer with HDMA active for a long time, too. I just assumed it'd kill the HDMA. So I wonder what happens if a DMA is in progress on a given channel and then the HDMA transfer starts ...
... there was a problem with them before?
I don't see the Sprite+Y priority code. This fix I really don't follow, other than that I see now that anomie's document was assuming OAMaddr was a word index and not a byte index. What's up with y-1 when oamaddr&3=3? I thought sprite+y was when oamaddr&0xf=0xa? And firstsprite is reset on each scanline? anomie's doc says it's done once per frame... guess not :/
Oh, I forgot to add that last time, sorry.
I'll do just that, thanks. I didn't think that would be an issue with only 128kb/s of data. |
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Mar 11, 2006 3:21 am Post subject: | |||
|
|
|||
OH MY FUCKING GAWD! LEFT FIELD!
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Mar 11, 2006 7:04 am Post subject: | |||||||||||||
|
|
|||||||||||||
Added. Works exactly as stated.
So it does, so it does... when an enemy hits you there was some minor crackling sounds, now it's crystal clear. Awesome. No other intensive APU game is affected, as far as I can tell. Chrono Trigger, Tales of Phantasia, Star Ocean, Final Fantasy VI and Dai Kaijuu Monogatari all sound find. Might I ask where you got your bugfix information from? Just want to make sure it's definitely sound (hehe) before I remove the old code entirely (it's commented out for now).
I see what you mean by the Sprite+Y code. Hmm, wonder if there's even a single game out there to test this with :/ Still not sure I totally follow the code, or if its definitely supposed to update every scanline instead of every frame. Went ahead and moved OAM address reset to 225/240, that's probably how it should be like you were commenting.
Added.
I'll include it with the release, but I can't maintain it as I don't have MinGW.
The program crashes immediately (can't create DSound device) when I set DSBCAPS_LOCHARDWARE, and if I don't set either, it just uses software mode anyway. Darn, I was hoping this might fix the sound skipping that occurs when triple buffering is enabled in fullscreen mode. Ah well. And for the bad news, I only found one other bug that was fixed by these changes. The SNES Test Program correctly doesn't show the middle sprite when sprite interlace is enabled during the character test. Before it was hiding a sprite near the right of the screen, which was wrong. Tested RPM Racing, Genjuu Ryodan, Mortal Kombat, and SNES Test 0x70 (it passes 1 in 3 tries, I have no idea what changed or when to break this, not even sure which test it is without my debugger) to no avail. Don't have the other games that aren't working. And for some good news on top of that, nothing new broke that I could find :D At any rate, absolutely awesome. This is exactly what I needed for a new release, some real bug fixes instead of just GUI fluff. Thanks again, DMV27! I'll have to start listing you as a main developer here soon ;) On a semi-related note, I guess now's a good time to mention that I added Game Genie / Pro Action Replay support. It saves to a config file, and that config file saves in your save_path with your SRAM files. One for each game. No GUI interface yet, and I'm also planning to make a cheat.db file to include with bsnes that stores CRC32 identifiers for games, along with lists of known cheat codes. The GUI will have an option to import all cheats it can find with the press of one button so you don't have to look all the cheats up online all the time. Might want a volunteer to maintain that, but let me wait till I get it in there first. |
|||||||||||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Mar 11, 2006 7:16 am Post subject: | |||||
|
|
|||||
And you call that bad...
Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support. _________________ FF4 research never ends for me. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Mar 11, 2006 7:21 am Post subject: | |||
|
|
|||
No. Goldfinger codes are bullshit. If someone writes the encoder/decoder for me, I might add it in. If it requires even one bit of information about the ROM to work (e.g. LoROM/HiROM), then I won't bother. Does anyone even use these worthless codes for anything? Pro Action Replay are the only sensible ones. They work on RAM addresses, address the entire 16mb memory map, and are in plain text with no drunken lunatic encoding ala Game Genie, so anyone can easily play around with them to make their own code variations. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Mar 11, 2006 7:27 am Post subject: | |||||
|
|
|||||
Hmm.. I'm not overly concerned.. I've never really gotten a total explanation of the cheat devices. Pro Action Replay is more powerful eh? I've never seen the Pro Action Replay stuff... (let alone the Goldfinger stuff)... I have seen two Game Genies.. and boy... it is kinda funky. I remember seeing the Game Genie for the NES and SNES.. the code system for the NES looked pretty fucked up. The SNES version seemed slightly more sensible.. as the codes seemed to resemble hex, but I'm no genius as to how it actually works. _________________ FF4 research never ends for me. Last edited by Deathlike2 on Sat Mar 11, 2006 7:40 am; edited 1 time in total |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Mar 11, 2006 7:36 am Post subject: | |
|
|
|
| Hm,
SNES test 0x70 is due to my overscan changes. I made it not take effect
until the start of the next frame, like interlace. The test doesn't
like that. I need to just run my damn tests on overscan already and get that out of the way :/ |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Mar 11, 2006 4:49 pm Post subject: | |||
|
|
|||
I had a Game Genie for the original Gameboy. That was one heavy combination. You can see what it looks like: http://en.wikipedia.org/wiki/Image:Game_Genies.jpg _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Mon Mar 13, 2006 10:42 am Post subject: | |||||
|
|
|||||
The y-1 is used instead of just y because sprite RTO is calculated one scanline before it is rendered. For example, bsnes will render sprites on line 1 that were setup on line 0 (bsnes will actually setup the sprites on line 1, so the y-1 is basically a hack). The "0xa" in anomie's regs.txt is actually the variable 'A' as in 'Address'. "oamaddr&3==3" is used because regs.txt says "e.g. so the next byte written would go to the last byte in the 4-byte sprite record". Firstsprite must be reset on each line, otherwise sprite+y priority wouldn't do anything (y would always be zero). Also, Uniracers 2-player mode updates oam mid-frame.
I can't test anything on a real SNES, but I got the info from sfsound.txt. In the ENDX section it says "When BRR decode of the block having the Source end flag is completed, the DSP section sets up a "1" 00-7 correspond to Voice0-7." This means that ENDX is only set when the BRR decoding for an end block is finished. For non-looping end blocks decoding stops immediately, so ENDX gets set as soon as the block header is read. For looping end blocks decoding does not stop until the block is fully decoded, so ENDX must wait until the end of the block before it gets set. I should have more patches for you soon. I have been going through the 65816 code and have found quite a few minor timing and open bus bugs. I also noticed that you do not handle stack overflow properly for 65816-only opcodes (see anomie's ob-wrap.txt). I can fix that too if you want, although it will require many changes to the cpu code. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Mar 13, 2006 1:13 pm Post subject: | |||||
|
|
|||||
Ah, I see. Also, I don't think Uniracers would quie work yet, doesn't that actually expect the OAM address to be updated by the PPU while the line is rendering? I recall we don't know how that address updating works.
Sounds awesome, thanks! If you want to just explain what's wrong with my stack overflow I can try and correct it, or if you prefer to patch it instead that's fine too. |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Mar 13, 2006 2:44 pm Post subject: | |||||
|
|
|||||
Almost all split-screen games should do that (e.g. Contra 3) ... _________________ savestate editor: vSNES latest public version
|
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Mar 15, 2006 12:09 am Post subject: | |
|
|
|
| The new update looks great byuu! I can't wait to try out the next release. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Mar 15, 2006 1:33 pm Post subject: | |
|
|
|
| Indeed, and DMV27 = bughunter extraordinaire. Eternal thanks. Keep up the great progress, everyone. | |
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Wed Mar 15, 2006 3:43 pm Post subject: | |
|
|
|
| I've just read the 'Bsnes news' update. This is only getting more awsome. Great stuff, Byuu & thx to DMV27 for the bugs as well. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed Mar 15, 2006 7:18 pm Post subject: | |
|
|
|
| YESSSSSS!!! Thanks man, I owe ya one for the PAR/GG support. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 16, 2006 8:46 am Post subject: | |
|
|
|
| How's this for the video mode configuration screen? You still have all ten video modes, but you can control everything below the first separator for each mode now. By default, it tries to auto-calculate the screen size for you, but you can of course opt to manually input any size you want. I actually forgot to put the screen size multiplier on there (1x-5x or so), so pretend that's in there somewhere. Oh, and pretend there's an overscan combo box on there for selecting NTSC mode (always render x224 height, clip x239 mode to fit in window), PAL mode (render at x239 height with x224 modes at the top of the screen -- e.g. as SNES9x does it now with the black bar), and PAL centered mode (render at x239 height with x224 modes centered). Grr, and also pretend there's a refresh rate box to the right of the fullscreen resolution. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Mar 16, 2006 8:51 am Post subject: | |
|
|
|
| Looks great byuu! your next version is probably going to look awesome on my TFT, i cant wait till blargg's ntsc filter is completely done and he makes a pal filter too (still hoping for the pal filter, fingers crossed) BTW my monitor supposedly supports 70hz refreshrate (Samsung Syncmaster 710t) any point in using 70hz? |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Mar 16, 2006 9:00 am Post subject: | |||||
|
|
|||||
No. Only a multiple of the base frequency (60/50 Hz should be close enough for emulation) would be useable. _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Thu Mar 16, 2006 10:44 am; edited 1 time in total |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Mar 16, 2006 10:18 am Post subject: | |
|
|
|
| crappy thing about tft is you have to use 60hz, thats why im hoping for a pal60 filter | |
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Thu Mar 16, 2006 2:23 pm Post subject: | |
|
|
|
| Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Mugwump
Joined: 30 Jul 2004
Posts: 2966
| Posted: Thu Mar 16, 2006 2:31 pm Post subject: | |||
|
|
|||
Why? I know nothing of these things, other than anythng less than 85Hz kills my eyes. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Mar 16, 2006 2:49 pm Post subject: | |||||
|
|
|||||
@byuu:
On the video settings page, where you have "Select video mode to
configure: Mode 0", this is the 10 customizable resolution modes? This
seems *kinda* like a misnomer, since there is also the SNES-internal
Modes 0-7. Maybe you can think of a different word to use? I know it
confused me at first glance.
Because LCDs don't flicker, no matter what the refresh rate. The screen still updates at only 60Hz, whereas a CRT would update at 120Hz if you had the resolution set to that. But LCDs don't flicker even if the refresh rate was 1Hz. You would just have mouse trails. Here's an excellent, and funny article on the subject: http://www.dansdata.com/gz021.htm _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ Last edited by Jipcy on Thu Mar 16, 2006 6:09 pm; edited 1 time in total |
|||||
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Thu Mar 16, 2006 2:51 pm Post subject: | |
|
|
|
| LCD
monitors do not flicker by design, whereas CRT's do. The flickering of
CRT tech can cause considerable eye strain, especially at low refresh
rates. Edit: Yep, Jipcy beat me to it. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Mar 16, 2006 4:46 pm Post subject: | |||||
|
|
|||||
Actually it's 0-7. _________________ savestate editor: vSNES latest public version
|
|||||
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Thu Mar 16, 2006 5:10 pm Post subject: Here is my screen setting. | |
|
|
|
| 1280 by 1024 pixels Screen refresh rate - 180 Hertz - It speed up and alot better than setting on 60 Hertz. My mouse point is fast when I move it. Btw: I uncheck the Hide modes that this monitor cannot display. I have Sony Display TFT LCD 5:4. Works fine here using a ATI Radeon 9550 graphics card. _________________ "Zsnes is the best one there is." |
|
Mugwump
Joined: 30 Jul 2004
Posts: 2966
| Posted: Thu Mar 16, 2006 5:29 pm Post subject: | |
|
|
|
| Thank you for asking my question. And thanks for that link. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Mar 16, 2006 6:10 pm Post subject: | |||||||
|
|
|||||||
Whoops. I think the intention of my words were clear, though.
Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Mar 16, 2006 7:36 pm Post subject: | |||||||||||||
|
|
|||||||||||||
Yeah. I was wondering about it as well.
Is the TFT actually fast enough that it makes a difference?  _________________ savestate editor: vSNES latest public version
|
|||||||||||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Mar 16, 2006 7:48 pm Post subject: | |||||||||||||
|
|
|||||||||||||
Refresh rates shouldn't really affect LCDs, but rather the game it is running on... _________________ FF4 research never ends for me. |
|||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 16, 2006 11:20 pm Post subject: | |
|
|
|
| LCDs
still have to have refresh rates, which is how the video data gets from
the video card to the LCD. They may not make a difference because the
pixel response time is lower than the refresh rate, but it does still
control how fast pixels are pumped through your VGA/DVI cable. So at
the very least, a faster refresh rate lets the pixel know to start
changing sooner... I wish the damn things weren't so overpriced. I desperately want a widescreen monitor. CRT or LCD, I could care less. I just want a true, 16:9 widescreen monitor. I'd even settle with those bastardized 16:10 ones so long as the pixels were still square (I could just crop some borders on the top and bottom for movies, etc). My 19" CRT cost me $130 new and is a high quality viewsonic with excellent color response. A 17"-19" widescreen CRT shouldn't cost more than $200. The cheapest widescreen CRT I've found is $999, and the cheapest LCD is $350, whereas the 4:3 (which ironically has more actual pixels) ones go for $200 easily. </rant> By the way, does anyone know for certain why some LCD monitors look exactly like plasma (yet definitely aren't plasma) with ultra vivid glossy picture-like images, whereas other LCD monitors look like the old DTSN laptop displays? |
|
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Thu Mar 16, 2006 11:31 pm Post subject: | |
|
|
|
| The Dell 2005FPW was recently going for less than $350 shipped. I purchased mine when MSRP was $1,200 and I paid about $580 I could not be more pleased with the performance of the display. It's is the best performing panel on the market in terms of colors and pixel response. It was worth every penny that I paid and Dell continually releases coupon codes that make me want to buy a bundle of them. Flaws? No component input, 16x10 aspect. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Mar 17, 2006 8:55 am Post subject: | |
|
|
|
| Alright,
I dropped the line 224 toggle. Too confusing for the average user. I'll
probably add the option back later on an advanced screen or something.
I think I should make the render width/height boxes gray out if the
manual render screen size box is unchecked. Same for fullscreen mode
settings. I also added in all the back-end code, so this is now completely functional. If anyone has a better name for the video mode thing at the top (so that it's less confusing), let me know. The ten video modes can be cycled via ctrl+[1-0] or Menu->Settings->Video Mode->[1-0] Also, what's everyone's opinion on this? I then make the filter config screen always on top, so you can adjust the screen size settings while still being able to see the screen itself. Obviously only works on Win2k and above. No idea what Win98 would do, but I could always encapsulate the call to SetLayeredWindowAttributes to safely fail or something I suppose. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Mar 17, 2006 9:11 am Post subject: | |
|
|
|
| Looks nice. As for the transparancy.. some Win9x user has test it to comment on it... I think you're using a Windows specific function or something? If it is, it will probably just not work at all. Then again, I don't know what would happen. _________________ FF4 research never ends for me. |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Mar 17, 2006 3:52 pm Post subject: | |
|
|
|
| AWESOME! _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Mar 17, 2006 3:54 pm Post subject: | |
|
|
|
| I am definitely in favor of a transparent options windows. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Mar 17, 2006 6:07 pm Post subject: | |
|
|
|
| Awesome indeed. So much control over the display settings...Custom resolution...'per Snes display mode configuration' (KegaFusion has something similar actually) plenty of filters,Blargg's amazing NTSC filter.. And the transparent windows effect is great imo. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Mar 17, 2006 6:32 pm Post subject: | |||
|
|
|||
What? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Mar 17, 2006 6:46 pm Post subject: | |||||
|
|
|||||
...The Snes has many display modes. And it looks like you can configure them individually in bsnes. In the display settings it says: Select video mode to configure. Unless I misunderstood something that means for example that you could apply a filter to say mode 7 and not mode 1. |
|||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Fri Mar 17, 2006 6:49 pm Post subject: | |
|
|
|
| Hey Byuu, that's pretty cool. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Mar 17, 2006 7:32 pm Post subject: | |||||||
|
|
|||||||
Read again:
SNES has only 8 modes. _________________ savestate editor: vSNES latest public version
|
|||||||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Fri Mar 17, 2006 10:40 pm Post subject: | |||
|
|
|||
I'd suggest the label "Video Preset," with each combobox items called "Preset n." If possible, it might also be a good idea to add a tool tip when you put the mouse over the label stating that bsnes allows users to store up to 10 video configurations that can be cycled during use. This would likely cut down on questions from people who don't RTFM. It's a bit wonky I admit, but most people have probably used a media player that uses the "preset" nomenclature. Back to minding my own business now...
|
|||
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Sat Mar 18, 2006 12:41 am Post subject: ... | |
|
|
|
| byuu, you getting me closer to it everytime I look at your wip screenshots. Now that is what I call a bsnes. _________________ "Zsnes is the best one there is." |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Mar 20, 2006 6:10 am Post subject: | |
|
|
|
| I
went with profile. I was actually meaning to go with your suggestion,
MajereDB8, but I guess I got it mixed up in my head or something. Ah
well. In other news, I added DSP-2 support so everyone can play the Atari E.T. equivalent for the SNES. Finalized video config screen: |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Mar 20, 2006 6:31 am Post subject: | |
|
|
|
| You're going to have to start writing documentation for your emulator now that you have all these complicated options. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Mar 20, 2006 8:53 am Post subject: | |
|
|
|
| One
thing I've been throwing around is a simple and advanced mode switch.
One takes the KDE approach of throwing a trillion features at you to
configure to your liking. The other like GNOME, keeps things as simple
as possible, options only where you'd need them. I'll think about it more tomorrow. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Mar 20, 2006 10:34 am Post subject: | |
|
|
|
| Ha, brilliant! Gotta love the "Hall of Champions" theme song, at least. Here is my first recording from the digisnes. It is the full initial intro loop of Super Castlevania IV, from konami logo, to title, to intro, to game demo, ending before next konami logo (3.5 minutes). This particular recording is great for analysis because it contains lots of different sound rape effects, music, and some sound effects alone without music. Since it is all automated and not gameplay, logging the same sequence of sound on bsnes was a piece of cake. I removed the silence at the beginning and end with a cooledit option to match the two wavs up as exactly as possible. The lengths are not exactly the same though, probably due to the timing discrepencies brought up earlier in the dev forum. A couple of things I've noticed after noob analyzing the two wavs: bsnes emulates the sound effects correctly, but the overall amplitude is higher and the distortion on the lightning effect seems more pronounced. http://rapidshare.de/files/15960765/castlevania4-real.rar.html http://rapidshare.de/files/15960372/castlevania4-bsnes.rar.html http://rapidshare.de/files/16055697/castlevania4-sneese.rar.html http://rapidshare.de/files/16044291/castlevania4-zsnes.rar.html http://rapidshare.de/files/16045306/castlevania4-snes9x.rar.html EDIT: Just thought I'd mention that data from the real should be objectively taken with a grain of salt. I've taken several more recordings of each to make sure the times are right. Turns out, I get differences (to the ms) from the real source, but bsnes always cuts to the same exact length. The analysis numbers seem to change for the real as well. Don't really know if this is my fault, or just something wierd the snes is doing that I have no control over. I also don't know if kmixer has any role in any of this. Bsnes does appear extremely close if not perfect with sound. Last edited by FitzRoy on Tue Mar 21, 2006 1:49 pm; edited 4 times in total |
|
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Mon Mar 20, 2006 5:21 pm Post subject: | |||
|
|
|||
No worries. "Profile" is a more neutral and appropriate term anyway, since the video modes aren't really "preset" but must be configured by the user. Can't wait to see what good stuff is coming in the future. I've gotten into a habit of hitting this thread and the board in general just to find out what interesting research is being done on the SNES. |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Mon Mar 20, 2006 11:45 pm Post subject: | |
|
|
|
| This new Bsnes-stuff just makes me drool. Byuu, you da man. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Mar 21, 2006 6:48 am Post subject: | |||
|
|
|||
Thanks for making these! It's very close, but work still needs to be done :) Once I get a digital SNES, and a high-paying part-time job (hahahahahahahahahaha), I'll probably start working on SPC700 emulation directly, instead of solely relying on anomie's (absolutely awesome) DSP core. I believe the real SNES one sounds better, not by much, but definitely better. The lightning is still kind of choppy on the real one, but much less so than bsnes. I wonder if you could get a sound rip from e.g. ZSNES / SNES9x to compare further? I've missed some rather obvious bugs in the past (eg Mortal Kombat 2 SRCn bug), so maybe those emus get the lightning better. BTW if you do others, Earthworm Jim 2 would be a good one (though impossible to line up, we could see if the sound effects cut out as frequently as they do in emulation), as would the ToP vocal intro (which could be lined up). I wouldn't do any just yet though, especially not EWJ2. DMV27 fixed some new bugs in the DSP that greatly improve at least EWJ2. The real SNES will always be different because of fluctuations in the timing crystals. So you'll get somewhere between 32,000hz - 32,100hz or so in realtime. I think it's most often ~32,040hz. The output on the SNES would be exactly the same every time if only the SPC700 was used by itself (though it may actually play faster or slower, the digital output would be bit-for-bit the same). But since there is communication between the CPU and APU, and they are running at slightly different speeds each time, you end up with minor timing differences every time. With a PC, the same fluctuations exist, but they don't affect the underlying output because all of the "SNES chips" are ran off the same CPU clock, so your output is always identical. I could emulate this fluctuation easily enough by emulating random "fractions" of opcodes (say, +/- 0.001%), but eh, why bother? I'd rather use the reference "stock" speeds of 21.477mhz and 24.576mhz instead. If a game can't run with that, it will very realistically die on the real console as well. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Mar 21, 2006 11:03 am Post subject: | |
|
|
|
| No
prob! Yeah, that info about the snes clocks really explains the length
discrepencies. Regarding the zsnes and snes9x samples you requested - I
made those tonight and edited my post with the links. I used a digital
loopback for both recordings. ZSNES is with latest wip and default
sound settings. Snes9x 1.43 needed to be set from 22khz (default) to
32khz. I'm not sure if you were hoping for zsnes or snes9x to show you something, but prepare to be disappointed. Things to look for: -konami logo fade gets cut off -bats and lightning very wrong (should we call this "konami rape" now?) -some sfx from "game demo" part are affected. As far as making new ones, I mentioned in another thread that I am without a copier these days and my cart selection is dwindling as well. Looks like EWJ2 and ToP will have to wait till you get yours up and running. I'll probably do the chrono trigger beginning sequence next, but these c4 wavs seem to satisfy much for comparison. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Mar 21, 2006 1:11 pm Post subject: | |
|
|
|
| Ah, no copier :/ Yeah, so no luck with those two. Lastly, how about SNEeSe? Does TRAC get the lightning effect right at least? If not, this is a good example of why emulation needs to keep improving, heh. CT sequence could be cool. I'd still wait for that new version just in case, though I don't think the ENDX changes would affect CT. Eh, you never know. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Mar 21, 2006 1:56 pm Post subject: | |
|
|
|
| Link of sneese now added. And yes, sneese gets it right. In fact, the sneese and bsnes wavs are indistinguishable to me. I'll wait to see if .016 changes anything before ct. Kind of was thinking today about something I saw on the alpha ii guy's site: "If you see only one chip under the heatsink, then you have the last revision of the APU." Hmm, could these revisions have had any effects on the quality of the system's sound? Important to know if we are to determine absolutely what is reference and what is wrong, since my console could be an earlier revision. Last edited by FitzRoy on Tue Mar 21, 2006 2:06 pm; edited 1 time in total |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Mar 21, 2006 2:06 pm Post subject: | |||
|
|
|||
No good. You can't get proper audio output with ZSNESW. Use the wav writer, and then do whatever digital recording you want of that if needed. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Mar 21, 2006 2:21 pm Post subject: | |||||
|
|
|||||
Not sure I understand. Is this a bug? If it's a bug, then the comparison stands. I can't be doing special commands to get it right if we can't play it that way. I can't seem to get any audio out of the dos version, anyhow. It's enabled, too. :/ |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Mar 21, 2006 2:44 pm Post subject: | |||||||
|
|
|||||||
ZSNESW does not output sound to your sound card properly, I mentioned this I think in two other threads and this one as well. ZSNES DOS, and now ZSNES SDL do output correctly. If you want to compare what ZSNES generates, instead of output which could be affected by CPU load and a bunch of other things, use the movie recording option and only output the audio. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Mar 21, 2006 5:09 pm Post subject: | |||||
|
|
|||||
To
be honest I don't really see a diference in regards to the lighting
effect. All I hear is a difference between volume and maybe slight
pitch difference or something but what do I know. Are you sure whatever
method you use to rip the audio is not responsible for those slight
differences?
That's interesting...Soooo...the real Snes is actually 'less' accurate than bsnes!! Seriously though, basically those slight variation (imperceptible to the naked eye/hear) are due to physical,real world variation in the timing crystal right?
Well, you probably guess what I'm gonna say but: Most of us "Just like on the real thing!" fanboys would probably enjoy such an addition. Now I realise this is not directly emulation related and that it could be argued that those fluctuations are in fact nothing more than slight inperfections of the original hardware, but (assuming it would be trivial to add in bsnes) it would be a neat addition nonetheless. Just like simulating the quirks of an Ntsc TV I guess. |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Mar 21, 2006 5:54 pm Post subject: | |||||||
|
|
|||||||
- you won't note a difference though - it makes the emulator slower - it's additional work _________________ savestate editor: vSNES latest public version
|
|||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Mar 21, 2006 6:21 pm Post subject: | |||||||
|
|
|||||||
True, but then we've allready talked about how there's more than meet the eyes when it comes to emulation. In many games, many people wouldn't notice a difference between b and Z, yet the underlying emulation is fundamentally different (well you know..more accurate in b)
Possibly.But the question is: by how much? If it's so insignificant that you couldn't even measure the impact than I guess it doesn't really count.
True again. But I did say "provided it's trivial to add". There's work: "Five minutes worth of coding" and then there's work: "Hours or even days worth of coding" |
|||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Mar 21, 2006 6:42 pm Post subject: | |||||||
|
|
|||||||
I meant you won't see a difference because the games will behave exactly the same as on the real console. bsnes emulates a "perfect" SNES that does not differ from the specifications. Emulating these slight real-world differences is not necessary because the games will ignore them anyway. They have to, or they would not run on all real-world SNES. _________________ savestate editor: vSNES latest public version
|
|||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Mar 21, 2006 8:23 pm Post subject: | |||||||
|
|
|||||||
My point was: On the real Snes ('any' Snes no matter how "perfect") you can't replicate the same exact results everytime because of fluctuations in the timing crystals like Byuu said. On bsnes (and probably every other Snes emu for that matter) if you do a test like FitzRoy did you WILL achieve the same exact results every time. That's not totally hardware accurate technically. It's not just about "Whether the games care or not" Now,before anyone starts exagerating... I obviously realise it's impossible to replicate every physical,real world details that could potentially affect the console (I wouldn't want to anyway). Unless of course you intend to create a program that virtually replicate the physical components of the console to the atomic level...and that's insane by an order of magnitude. But this particular hardware quirk (slight variations in the timing crystal) is quite possible to simulate. And it does have a (random) impact on the game, no matter how insignificant. Like I said, it's something that probably happened on 'all' Snes in 'any' condition.It's part of the hardware in a way. We're far from "simulate random earthquake" or "simulate little brother pounding on the console" here. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Mar 21, 2006 9:23 pm Post subject: | |||||
|
|
|||||
I'm assuming you mean the bsnes/real comparison, because zsnes and snes9x are really quite off for sfx. And yes, I had to listen many times with my high end headphones very closely to spot any difference other than the amplitude. It's hard to put my finger on it, but the real snes is just a tad "smoother" sounding. It's really, really close. In fact, I could see some preferring the bsnes/sneese sound as it is. Unless kmixer did something, the digital input recording should be clean for the real.
I think byuu already gave a good reason not to. In fact, you did a pretty good job yourself. When I said length discrepencies, we're talking milliseconds to minutes. Really, really small and humanly impossible to detect, i.e.: 3m 28.452s file 3m 28.660s file Edit: omg I'm a math tard. It was late Last edited by FitzRoy on Wed Mar 22, 2006 2:43 am; edited 2 times in total |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Mar 21, 2006 9:54 pm Post subject: | |||||||||||
|
|
|||||||||||
Yes. Don't have to check Z and 9x to guess they sound way off. 9x in particular is probably the worst of them all I think.
Yes I understand that. And I understand the games don't care either. It's just something you could say: "The original ran like that and so does the emulator". Now that being said can't say I care too much about it (yes,I actually argue over points I don't really care about, go figure). |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Mar 21, 2006 11:22 pm Post subject: | |
|
|
|
| Well,
I could allow adjustment of the CPU<>APU clock speeds with no
slowdown to emulation whatosoever. In fact, it's trivial and I should
have already done it. That said, this will stay a config file option only and will not appear in the emulation interface. I could add a special flag in there for variance as well, e.g. cpu.clock_speed = 21477272 cpu.variance = 6000 Then at power on, cpu.clock_speed = cpu.clock_speed + (bool(rand()) ? 1 : -1) * rand(cpu.variance); This would result in different CPU<>APU ratios upon each power on. Just enough to give subtle differences like a real SNES. However, this variance occurs during each clock cycle to an absolutely infinitesimal degree, and not at system power up. To emulate that would cause an absolutely brutal performance penalty, so I won't be adding that unless there's a real demand, or until the day when someone mentions they only have a 2.0ghz and everyone tells them to put that shit in a museum ;) Anyway, the variance would be 0 and clock_speed would be stock speeds by default, and I would refuse bug reports if these options were changed. It would also make debugging and fixing CPU<>APU sync problems a lesson in pain if variance was used. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Mar 21, 2006 11:52 pm Post subject: | |||
|
|
|||
Awesome Don't worry, I won't pester ya to make the variance occur during each clock cycle like on the real Snes And a .cfg option is definitely the best solution, so people that don't know what this option is for don't even have to know it exist or modify it, and most people would probably want it off by default anyway I guess. Last edited by Dmog on Wed Mar 22, 2006 2:27 am; edited 1 time in total |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sun Mar 26, 2006 3:12 pm Post subject: | |
|
|
|
| OBC1 added. I know you don't like all those special chips Byuu, but looks great anyway. You won't hear anyone complaining abt increasing Bsnes' compatibility list. Nice job. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Mar 28, 2006 11:47 am Post subject: | |||||
|
|
|||||
Do you just want to get the currently selected item? I think that's different because in a listview, several items can be selected. You probably could use the index of the currently focused item. _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Mar 28, 2006 1:13 pm Post subject: | |
|
|
|
| That's
what I did. There's no API to do that so you have to reiterate through
all items to find the currently focused item. I also have
LVS_SINGLESELALWAYS set, so it shouldn't allow multiple selections at a
time. Anyway, I've written get+set. I actually just started last night on a new object-oriented wrapper for the win32 API because the difference between the generic windows control APIs and the common control APIs is just ridiculous and I can't keep up with all these new messages and helper functions. Going to try and completely hide the win32 API 100% with it. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Mar 28, 2006 2:00 pm Post subject: | |||||
|
|
|||||
Ah, didn't know that... Delphi just provides the property 'ItemFocused' and "hides the win32 API 100%". EDIT: Just looked at the source... they also iterate through the list. _________________ savestate editor: vSNES latest public version
|
|||||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Tue Mar 28, 2006 5:31 pm Post subject: | |
|
|
|
| Now also a cheat code editor? Oh man, I can't wait for v0.16 Byuu is the Snes-God! _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Fri Mar 31, 2006 2:13 am Post subject: | |
|
|
|
| 'm
aware of the rescaling bug, it will be corrected probably in the next
WIP. DirectX is trying to stretch the 600x446 surface to fit onto the
screen so I will have to rewrite the code to not use hw filtering and
it should be good after that. We had the same problem with scanline a
long time ago. The entire code base is converted to Direct3D so that
should also clear up a lot of problems. As for the framecounter it's
working properly. I will take a look to see what was changed, perhaps a
bug was created. We are making a lot of changes to the video code
lately after we overhauled the sound, input, video was the next thing
on the list. I didn't really had a lot of time to test the NTSC filter
on Windows as Linux is my main development environment but I will see
to it that he filter is working properly later on. I was wondering since the NTSC filter doesn't output a buffer that is compatible with most 4:3 screens, I guess using a letterbox effect here would be best. |
|
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Fri Mar 31, 2006 2:40 am Post subject: | |||
|
|
|||
How about an option to change the 4:3 to anything. For exsample here, my screen is a Sony TFT LCD 5:4 not a regular 4:3 screen. Many people doesn't have a regular 4:3 screen when they use a TFT LCD or what ever they use beside of regular 4:3 screen. I know Mame got this option in the Mame.ini and I set it to 5:4 for the screen correction on full screen. But if it doesn't matter then don't bother messing with it. _________________ "Zsnes is the best one there is."
|
|||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Fri Mar 31, 2006 3:39 am Post subject: | |
|
|
|
| We don't need to support people too stupid to request a proper 4:3 or 16:9 screen. Really, we don't. 5:4 and 3:2 and the rest of the nonstandard ones were made to make money off fucking morons. |
|
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Fri Mar 31, 2006 4:04 am Post subject: | |||
|
|
|||
So you saying that pagefault need to remove the 4:3 support then? Not going to happen. Your not using your head wise. _________________ "Zsnes is the best one there is."
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Mar 31, 2006 4:15 am Post subject: | |
|
|
|
| Thanks pagefault. What I do is scale the image horizontally only. This leaves the scanlines intact but lets me get perfect scanlines. For example, 512x448 -> 448 * 4 / 3 = abs(597.333) = 597 x 448. Perfect. I do this for all filters, and use bilinear resampling for it. And capture cards seem to output at 582x448, so I need to look into this. I'll let you know when I do. As far as fixing the aspect ratio, the thing to keep in mind here is not the aspect of the monitor being used, but the pixel aspect on the real SNES vs the monitor pixel size. If your monitor is 4:3 or if its 16:9, and you still have square pixels, then you would use the same output size for the actual video content for correct aspect ratio. The only thing that changes is the size of the screen in fullscreen mode (eg more blackspace is added for 16:9). I'll try and get code for this correction up as well if I ever get around to it :/ |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sat Apr 01, 2006 12:22 am Post subject: | |||
|
|
|||
Not every one uses a computer to play games and watch videos. A 5:4 monitor is better for desktop useage. Like coding, word processing, viewing webpages or whatever. It's slightly wider and taller then a 4:3 one, plus the cost is cheaper then getting a 16:9 LCD monitor. They'd only look silly if they brought one just for multimedia use. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Apr 03, 2006 1:36 pm Post subject: | |
|
|
|
| Byuu,
I recently bought an XBox 360 Controller. I noticed that bsnes does not
detect all button presses from the controller. For example, it doesn't
detect the d-pad at all. Furthermore, it does detect left, right, and down on the left analog stick, but not up. So I'm wondering if there's any way you can look into this issue for the next release. I can possibly provide you with more details in the near future. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 03, 2006 8:35 pm Post subject: | |
|
|
|
| I think that's one of the things I've fixed since v0.015. The RC1 release would have that fix if you were able to run that build... | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Apr 03, 2006 10:18 pm Post subject: | |
|
|
|
| Where is the RC1 release available, even if I can't run it? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Lurker
Joined: 26 Feb 2006
Posts: 152
| Posted: Mon Apr 03, 2006 11:05 pm Post subject: | |
|
|
|
| Here you go. They have it upload here at - http://www.emu-france.com/?page=fichiers&idFile=3126 - The download works. _________________ "Zsnes is the best one there is." |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Apr 05, 2006 1:11 pm Post subject: | |
|
|
|
| too bad that build is for SSE2 only |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Apr 05, 2006 4:01 pm Post subject: | |||
|
|
|||
Yes, its fixed. I'm also absolutely stunned! I haven't experienced Scale2x on an SNES game before, and I love it! I also like bilinear filtering at those higher internal resolutions (resolutions that the video card doesn't have to scale as much, and thus less bilinear filtering). I would use that as a filter/option by itself. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 14, 2006 8:22 pm Post subject: | |||
|
|
|||
|
Fantastic! I finally figured out how to truly play videos on SNES hardware! I'm so stupid for not realizing this immediately... FORCE BLANK. Damn. There's no reason to limit VRAM transfer times to just standard vblank if you're not rendering to the top and bottom of the screen. Techno-babble:
 The white border is additional room that my example image couldn't fill. I could run an image of this size and quality (150x128, or 160x120) at 30 frames per second on stock SNES hardware. And I have every other frame entirely free for things like video decompression, audio transfer (potentially ToP intro quality audio, though something like Wild Arms intro music would be fine too I guess), etc. Now, problems? You betcha. 150x128 or 160x120 at 8bpp RGB332 would be 576kb/s. Youch. I'd fill a 4mb ROM in <8 seconds. Compression could easily halve that, as could lowering the framerate. Or, my next idea, a bit more radical... How does everyone feel about "emulating" an MPEG decompression "chip"? It'd basically act just like the S-DD1. You ask it to decode a frame, wait a bit, and then DMA transfer right off the cart. Maybe use MPEG2 for higher compression rates, but not MPEG4, as that isn't standardized enough yet... The ROM size is still a problem. So I'm thinking, combine the PCM "chip", the MPEG "chip", and a large ROM chip (128-256 megabytes is feasible) on the cart, call it something like the "S-AV chip". The emulation code would be 100% ANSI-C++ and cross-platform portable, so other emulators could use it if they wished. It would allow redbook audio, and MPEG1/2 quarter-screen video at 30fps. It could allow for some absolutely amazing ROM hacks if people were interested enough in hacking games. And it would be designed with wait delays in mind, and absolutely nothing would be "impossible" to do on a real SNES cart if a talented FPGA programmer were to come along ;) I'd require something like the .smc file and .rom file (and hopefully a .ups patch file so we aren't distributing hacked ROMs), the .rom being the contents of the special chip's ROM. Being any size up to 256/512mb. It'd just be completely optional, and I'd use it myself for Der Langrisser to make the SNES port rival the quality of the PC-FX port. I really think this is the winning strategy for my SNES-enhancement ideas. Opinions? |
|||
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Fri Apr 14, 2006 9:42 pm Post subject: | |
|
|
|
| I think you have a great money-making idea, Byuu. If it was 8 years ago and the Super Nintendo was still popular. Well, you could get a custom SNES flash cart with the chip (that has the extra flash memory like you said)... that decompresses the video on the fly? It'd probably cost quite a bit... but, it'd still be cool. Too bad I don't have an electrical degree and a lot of time/money or I'd do it. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Apr 14, 2006 9:45 pm Post subject: | |
|
|
|
| It's a little over my head, but it definitely looks impressive. Is this all ROM-side stuff we're talking about? Or is any part dependent on the emulator? Give that you said this could theoretically be run on a stock SNES console, I assume it's all ROM-side. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 14, 2006 10:03 pm Post subject: | |||||
|
|
|||||
Eight years ago a 512mb ROM chip would be psychotically expensive. If I wanted to make money, I'd make my own version of the Windows XP Media Center applications that was highly and easily themeable and extensible and charge $10-$20 for it. Anyone wanting to use their existing WinXP disks could use that instead of buying another copy of XP, or hacking the MCE apps to work on vanilla XP.
The audio would require a special cart+chip, so that the audio output lines could be written to. These lines exist on the SNES, but only the BS-X makes use of them for its streaming satellite audio. The video can be done entirely in the ROM, but there isn't enough space for even a single full-length video. You could add on 512mb easily enough by putting the ROM chip on the PCB, and throwing a special memory mapper on the cart, similar to the S-DD1. However, I want to add video and audio data compression so that the "extended" ROM space is kept small. MPEG decoder cards were very tiny even in the Sega Saturn days. Nowadays, all of this stuff could easily fit on an SNES PCB. The cart would probably run for $100 in parts at mass production, but of course, no real carts will ever exist. The chip will only exist in emulated form in certain emulators. |
|||||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Apr 14, 2006 10:12 pm Post subject: | |
|
|
|
| I don't understand the techno-babble but your credentials with Bsnes already speak for themselves. Do what you think is best. Go for it Byuu! _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Apr 15, 2006 3:56 am Post subject: | |
|
|
|
| Woo, this place was all crickets for a while there Although I don't understand the practical applications of this, I think it's pretty impressive. Let's say someone wanted to modify the psx chrono trigger rom to include the videos as well, and make it playable in bsnes. Would this then make that possible? It's too bad Dracula X was such a cut-up job compared to the PC-Engine version, or people may also have something to work with there. In the end, it seems like a lot of work to pull these things off in light of the alternative which is to simply play the better version on its respective emulator. Though for Der Langrisser, I don't know shit about PC-FX emulators or iso rarity. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Apr 15, 2006 5:18 am Post subject: | |||
|
|
|||
One would modify the SNES ROM. No reason to mess with the PSX one. But yes, you could add in the MPEG movies (maybe a little smaller though) and the accompanying audio with this. There's only one PC-FX emulator and it's by the Magic Engine team. Not sure if it's been released yet, but I'm sure they'll want money for it, so I could care less. There's also the fact that you'd have to hack the game to English. Hence, it's easier to just extend DL SNES instead. |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Apr 16, 2006 2:33 am Post subject: | |||
|
|
|||
If I understand, this could be actually achived on real hardware using few, relatively simple physical modifications, right? Even so, I think it's a bad idea (just my impressions). I'm not too enthusiast on the idea on "improving" a console/game media via emulation. It kinda defeats the purpose of emulating a system which, from a technical standpoint,is completely outdated and outclassed by today standards (again, speaking from a pure technical specifications pov. Compare the Snes to the PS3 and you get the idea) . Why not just create/translate a game on the system which is allready capable of achiving what you want to go for? Yeah some probably say I'm going overboard but I fear that, in 100 years from now, every Snes games will have Cd audio quality and have PS4-quality graphics [/slight exageration] but you get the idea.(edit: and yes, I understand the idea proposed would only be optional) Wasn't it you Byuu that said that you could play PS2 games on the Snes? All one would need (in theory) is to insert all the PS2 hardware in one giant Snes cartridge. Anyway, that being said,if Byuu wants to go with it, then by all means, ignore my ramblings. Last edited by Dmog on Sun Apr 16, 2006 2:57 am; edited 2 times in total |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sun Apr 16, 2006 2:49 am Post subject: | |
|
|
|
| Well,
I imagine that sometime in the indefinite future, when SNES emulation
is perfect, and, should the console manufacturers be so inclined, we
are allowed to execute homebrew code on said consoles, then we can just
burn a Blu-Ray Disc with an SNES->PS4 emulator and all our roms. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Apr 16, 2006 2:53 am Post subject: | |||
|
|
|||
I'm willing to bet said emu will be called "PS4SNES" (PS4/for-Snes) get it? )Edit: Just to make things clear, I really did meant: A PS4 Emulator that would run on (modified) Snes hardware, and not vice-versa. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Apr 16, 2006 5:39 am Post subject: | |||||||
|
|
|||||||
Yes. If one were to use standard SPC music, it could be done with no modifications at all, other than a larger ROM and an MMC. The S-DD1 MMC would probably even be sufficient. The only problem with the video is space, and the two problems with audio are space and lack of any carts that utilize the audio out pins that truly exist on the system. In fact, Nach says hardware exists that can play CD audio on the SNES, but I've never heard of it nor seen it. The BS-X plays CD-quality audio streamed over satellite, so this is obviously all doable.
I understand your point and this is why I wanted opinions on the matter, thank you. You see, I realize I could port Der Langrisser to the PC, and blow all of the other ports the hell out of the water. The problem is now I have to worry about it working on 50,000 different hardware combinations, and it only runs on Win98-XP. Probably won't even work on Vista. Nor Mac, nor linux, nor PS4SNES. And instead of hacking a game to English, I'd have to program the entire thing. The game engine, the AI, the maps, everything. Months, nay, years of work. Whereas, with a tiny modification to the SNES hardware, and very little programming work on my part, I can easily match Der Langrisser FX, and enjoy platform independence. It's really the same thing as those Zelda 64 texture expansion packs (only possible on hardware). It hurts nothing, and in theory could turn out some really cool stuff.
Yes. But there's one key thing I also mentioned. The video hardware in the SNES cannot be enhanced. The best you could do would be to have all of the PS2 hardware running inside a cart (and it would need an external power supply), and have it transfer the PS2-generated video at 150x128x256 colors@60hz non-interlace with audio at 32khz 16-bit stereo. You'd also probably need external input (eg on the cart) for the controller, for things like the analog sticks and rumble pack support. And at this point why not just stick component + SPDIF out on the cart as well? Because now you're not even using the cartridge connector to the SNES, so there's no point. It's just a waste of power for the SNES to sit there idly doing nothing. The point was just that you can put whatever the hell you want on an SNES cart. So long as it has enough power, it'd run fine. There's just very little the SNES can do with the output. And my ideas on this page are within those limits of the SNES. I'm not blatantly making shit up like adding DVD 720x480x24bpp progressive video playback with 5.1 dolby digital surround sound or anything. But anyway, if no one wants this then I won't add it. There's no point if no one will use it. |
|||||||
Seen it all
Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box
| Posted: Sun Apr 16, 2006 5:58 am Post subject: | |||
|
|
|||
It all depends on what you want to do, not what everyone else wants isnt it? _________________ My boring Site |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sun Apr 16, 2006 6:05 am Post subject: | |||
|
|
|||
Given that you say it would take relatively little work, I say go ahead. And show us a proof-of-concept or something. End-users (non-programmers) seem to have relatively little use for it. Romhackers and other types can do the rom creation. End-users, however, would certainly enjoy some very cool "ports" and such, and new PD roms or something. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Apr 16, 2006 11:30 am Post subject: | |
|
|
|
| Well,
obviously Der Langrisser is one of your favorite games. I personally
understand what you're trying to do after listening to the difference
in some DL videos on a PC-FX site. In fact, I may even relate a little
bit. I love the Ultima series of games and one day I hope to track down
the "FM Towns" version of Ultima VI which includes speech fx. Nuvie, a
U6 game engine for windows, now supports this fx. It's friggin cool and
I want it. But the problem you face with this feature is, who else has the drive to hack this stuff into a rom? Only time will tell if other people use the feature for other games. Der Langrisser is a strange circumstance and there may not be many comparable ones to warrant this as a popular feature. Pop it in though, see what happens. P.S. Have you given any further thought on putting a forum on your site? New feature announcements like this really deserve their own thread if you're looking for feedback. It's also more organized than the hodge podge we've got going on in here. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Apr 16, 2006 2:39 pm Post subject: | |||||||
|
|
|||||||
Never thought you were. Your explanations above help me understand how this could be achieved on real hardware. . Once,someone suggested emulating the Snes cd-rom add-on that never was released...Now that was bullshit. What you suggested though is perfectly achievable in real life.
By all mean if you want to do it then go for it. I'm pretty sure plenty of people would like it actually I agree with Jipcy:
Agree. If someone first shows it running on real hardware, then it's perfecty legitimate in my book. Last edited by Dmog on Sun Apr 16, 2006 2:56 pm; edited 1 time in total |
|||||||
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Sun Apr 16, 2006 2:50 pm Post subject: | |
|
|
|
| http://www.gba-video.com/ | |
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Apr 17, 2006 2:18 am Post subject: | |
|
|
|
| Yes, it is easy to understand that extending the SNES like this is a lot easier than learning how to translate one of those other ports of the game which has all the fancy music and videos built-in. It's not like you won't provide Portable ANSI C (TM) source code so all emulators can support it, and eventually the encoding so anyone can buy their own FPGA to turn into this coprocessor chip, the necessary extra logic chips in the event that you can't cram that alongside the decoder in the FPGA, and a handy dandy printed circuit board. Or, on the cheap, a template pattern which can be printed onto a transparency for the do-it-yourself-ers who have their own PCB kits. For extra manlitude, you can even try cutting the board out in the dark before you etch it. | |
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Mon Apr 17, 2006 3:15 am Post subject: | |||
|
|
|||
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 17, 2006 3:24 am Post subject: | |
|
|
|
| I'm in the process of working on the forum thing. I can't make this idea run on real hardware. I know next-to-nothing about hardware design :( With the help of the SA-1, it might be possible to write a decent, low-quality video decoder to get some 20-30+ second videos on a single cart. Using just the 2.68mhz main processor would be incredibly difficult. LZSS+keyframes would probably be my best bet. I do have 1-1/2 frames (~516,000 master cycles) for decoding, though. I also don't really see a problem with just using a fake MMC to address 512mb of space either, though. That'd give me ~15 minutes of lossless video, way more than enough for most games. And that would be an absolutely trivial task to design. And it really depends on the video, too. Something like Lunar: TSS's slideshow videos could probably easily fit in much less space. In fact, that whole game fits in 7mb of space, sans redbook audio. And kode, I can't understand if you're being supportive of the idea or sarcastic >_< |
|
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Mon Apr 17, 2006 4:07 am Post subject: | |
|
|
|
| oh. I forgot to mention. Since the snes has 8-bit display mode, how are you going to handle more than 256 colors in the video? Dithering is doable, but kind of fugly (I've seen it first-hand. I've had to get video clips to play on a 256-color Siemens WinCE 3.0 touchpanel). I just had another thought. You could, for starters, not even need a decoder chip. Just put the raw footage on a CF card, and use its simple ATA mode to read out the data. |
|
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Mon Apr 17, 2006 4:21 am Post subject: | |
|
|
|
| Byuu: Do you think that you could write a program that converts MPEG files to SNES roms? In the way that Avi2GBA does. | |
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Mon Apr 17, 2006 5:19 am Post subject: | |
|
|
|
| this
would be interesting. square games come to my mind as games that will
get hacked. the FF's with their cutscenes, CT with its cutscenes. but
the 256 color question is a good one, i think. _________________ |
|
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Mon Apr 17, 2006 5:28 am Post subject: | |
|
|
|
| Er, what? The SNES supports 32767 colours max. Whoever told you there was a 256-colour limit, whicker, is a dumbass. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 17, 2006 6:01 am Post subject: | |
|
|
|
| 32,768.
And you can only hold 256 colors in the palette at once. You can get
more colors onscreen by changing the palette mid-frame, or by using
color add/sub effects. I suppose it's technically possible to pull off 150x128@15bpp video. But wow, that would require some true evil, as well as mid-scanline palette changes. You would even need to be writing to the palette while the scanline in question was rendering. I could probably pull it off with some unbelievable timing tricks. Unfortunately, no SNES emulator even supports dot-by-dot PPU rendering, so it wouldn't work through emulation, nor on actual hardware. I figured 8bpp would be fine for cartoon animation sequences :/ The only other option is to just ignore the SNES and play a real video inside the window at full 256x224@24bpp. It would make rom hacks easier as you don't have to worry about the video playback nuking your VRAM, having to change video modes, and all that jazz. But... that's just not as cool :( |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Mon Apr 17, 2006 6:39 am Post subject: | |
|
|
|
| i
was referring to the pallette thing. but the switching is interesting.
i think that this would make for some very interesting hacks. gundam
games would also benefit, i imagine. or any game that had some sort of
cartoon going for it. _________________ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Apr 17, 2006 10:47 am Post subject: | |
|
|
|
| EDIT: Errr, I was just about to entertain the thought of having bsnes play back spc files until I found out that the Der Langrisser spc set from zophar is a bad rip. Thought it was the player's fault. Good thing I'm a google expert, though. Carry on. | |
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Mon Apr 17, 2006 12:48 pm Post subject: | |||
|
|
|||
SNES Music owns you, bitch. And I've yet to come across a bad rip there. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 17, 2006 6:51 pm Post subject: | |
|
|
|
| Alright, thanks for the feedback with the S-AV chip ideas. Next up, one change "for the worse" in the new version (no, not out yet) I wanted to go over: fullscreen mode. The current problems with fullscreen mode: page flipping and the Windows GDI are incompatible. This means eg double and triple buffering cannot be enabled with the menu. Vsync is not an option, bsnes isn't fast enough even on an FX-57 to run with vsync and experience zero tearing. Even ZSNES tears for me with only vsync on. To switch from triple buffering to standard mode is semi-doable with D3D, but requires me to kill DDraw and reinitialize it, thusly you get lots of monitor resolution switching when entering and exiting the menu. There's also the problem of the UI inside fullscreen mode. Since the main emulator window must be always on top for fullscreen mode, it conflicts with the UI. You cannot keep the UI windows always on top of the emulator window, and if page flipping is on, they flicker like mad. Last problem is toggling the menu bar in fullscreen mode crushes the image slightly, ruining the aspect ratio correction. I've basically decided that for the time being, it's easier to just disable the UI all together in fullscreen mode and switch back to windowed mode for this. I've added default profile selections for windowed and fullscreen mode, so you can hit F11 to switch between the two, or esc to exit fullscreen mode, and the esc key toggles the menu in windowed mode. I'm planning on adding an overlay mode (see Winamp AVS for an example of this) and/or a "quick" fullscreen mode, so you can just double click the window to quickly swap back and forth with no resolution change necessary. I realize it'll be a little inconvenient, especially for switching games. Is this going to be a show-stopper for anyone? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Apr 17, 2006 7:14 pm Post subject: | |||
|
|
|||
I once had better info on the subject, right now here's what I got: Emit advertising special "remote control" Back of box with CD mentioned and an interesting device shown. Finally for Emit, some info I found a side which mentions it syncs CD audio in time with the game: http://www.insertcredit.com/wiki/doku.php?id=emit I just wish I still had those other pics... It showed another game with an SNES cart, a CD, and an interesting device hooked up to an SFC. Edit: grinvader dug up some more info: http://www.famicom.biz/all/htmls/4988615006203.html http://www.proc.org.tohoku.ac.jp/~hoshi/voicer/ Edit: Another page: http://www.segagagadomain.com/saturn8/emit-vol1.htm _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Mon Apr 17, 2006 7:41 pm Post subject: | |||
|
|
|||
Not a showstopper really. Although is there a chance that within the profile menu, the user could have options to a) choose whether to start the emulator in windowed mode or full-screen mode, and b) if the user chooses to start in windowed mode, a second option that switches to full screen mode when a game is loaded? That seems to me at least to be a logical workaround, with the added bonus of giving the user added choice. Keep up the good work! |
|||
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Mon Apr 17, 2006 7:57 pm Post subject: | |
|
|
|
| The dongle was an emmitter, correct? Or was it a receiver? | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Apr 17, 2006 8:18 pm Post subject: | |
|
|
|
| Not a problem for me, although I've gotten used to having that "line refresh" since triple buffering never worked right for me. If I were to guess, it probably has something to do with the fact that I have to use the lowest latency setting on my soundcard to get the emu's sound static free. We never did figure out why that was on your implimentation as opposed to kode54's. Maybe I'll ask him to look at your source. I should probably offer him $25 if he fixes it since it appears to be a rare affliction. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 17, 2006 9:18 pm Post subject: | |
|
|
|
| Nach>
The pages you link to describe Voicer (-kun... ugh... so dirty) as a
remote control adapter. I can't exactly picture how this would work,
but it almost definitely is not playing CD audio directly through the
SNES. Perhaps it intercepts your commands to your actual CD receiver to
know when to skip to a new lesson in-game, maybe? That, or there's a
special CD player that communicates with this device, which then
communicates with the game itself. Very clever design to eliminate the
need for any kind of special SNES hardware (eg special chip), that
Nintendo would no doubt charge a fortune for. A true CD player would either hook into the SNES and run carts via "passthru", or it would connect to the extension port, and listen on the 8-bit address bus (A or B, I can never remember which is which) -- $2100-$21ff. Either would require either special 32khz CDs, or a resampling mechanism to downgrade the 44khz redbook audio. 123> It was both, according to one of those websites. Funny, I wasn't aware the SNES controller ports could receive more than one bit of data at a time. Shows how much I know. So perhaps the force feedback controller is possible after all. And this would be by far and large, the easiest thing of all to make for real :D FitzRoy> I know kode used waveout instead of directsound. However, I do not know why my audio is choppy with triple buffering enabled. It is my understanding that triple buffering does not in any way at all lock the system while calling ->Flip(), but it has to be doing this anyway. It's the only explanation. Essentially, it should just be flipping, and eventually every 600 frames, skipping a frame because two Flips() were called. However, more likely it's probably waiting for vblank each time it does a page flip, so every 600 frames it lags out the audio buffer causing skipping to occur. So then, if anyone knows how to make DDraw/D3D ->Flip() not lock the system when called, I can fix the choppy audio. And I'd be very grateful, as this would give me perfectly fluid audio and video, and along with NTSC mode sans merge fields, would look absolutely fantastic. |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Mon Apr 17, 2006 11:05 pm Post subject: | |
|
|
|
| Bsnes does have a screen tear that seems to appear once every 10 secs going from bottom to top when there's scrolling activity. At least this is so on my PC. Anyway, I'm not complaining since Bsnes aims for accuracy like Fusion. Keep up the good work, Byuu. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam Last edited by Sith on Mon Apr 17, 2006 11:07 pm; edited 1 time in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Apr 17, 2006 11:07 pm Post subject: | |||
|
|
|||
Ah, thank you. Well, the two issues could be related I suppose. Is it out of the question to impliment a WaveOut solution as well, with an option to use WaveOut or Directsound a la Foobar2k? It could clear up one or both issues for certain people (if it is in fact my card's drivers which are inadequate for directsound). |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 17, 2006 11:11 pm Post subject: | |
|
|
|
| Sith-Smasher>
The tear every ten seconds is because the SNES runs at 60.09fps, and
your monitor runs at 60fps. So the screen is being redrawn during
display and it overlaps once every ten seconds. The tearing is usually
less obvious when timing isn't as precise as in bsnes. FitzRoy> It's more to do with my video rendering than it is DSound vs WaveOut. kode had some interesting tricks to polling the scanline position for vblanking. It works ok, but still desyncs the video due to the audio absolutely requiring a perfect rate of 32khz to prevent choppy audio. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Apr 19, 2006 1:50 am Post subject: | |
|
|
|
| K, well if he was doing something less accurate, then I guess I'll stop clamoring for it. In other news, I've added a few games to the buglist. I've discovered something odd happening at the beginnings of the Super Star Wars games. They all use similar introductions. The demos of gameplay just end as they start, and any buttons pressed to start the game are ignored. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Apr 19, 2006 2:05 am Post subject: | |
|
|
|
| There's
something seriously wrong with my input system, or something. Lots and
lots of games do this, and I have no idea why. The input system is
implemented exactly as all technical docs explain it, so I must be
overlooking something simple. I'm guessing the games are thinking the keys are permanently pressed down or something. :: flashes the DMV signal into the sky :: |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Apr 19, 2006 5:16 am Post subject: | |||
|
|
|||
Bahahaha Well said. I take it you haven't heard from him since he revealed that he knew about certain inaccuracies. Hopefully he's still in the shadows working his magic. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Apr 19, 2006 6:35 am Post subject: | |||||
|
|
|||||
Yay! Fixed two myself!
See case 12-15? Those weren't there before, so it was hitting default: and returning 1 instead of 0. The games were reading $4016/$4017 sixteen times, and testing if any buttons at all were pressed. If any were pressed, it took it as a key being held down and skipped the intro. Nevermind the fact that there aren't any buttons mapped to bits 12-15... still, my mistake, and corrected. This should fix all of the games that skip over the intros now. Super Double Dragon:
Before, I was testing if(value == 1). However, Super Double Dragon was writing 0x07 to $4016, so no latch was occurring. Both of these bugs are fixed for both $4016 and $4017. This should hopefully eliminate all joypad input bugs. Anyone interested in beta testing v0.015 rc2 for me? Don't want to release it publically, as v0.016 should be out soon enough. |
|||||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Wed Apr 19, 2006 7:25 am Post subject: | |||
|
|
|||
I not sure whether this would work but it is more technically correct. The joypad continually returns the connection status unless the device has been strobed in which case the device will output a set number of data bits. The device will then continue outputing the connection status. Reallistically, there is no 16th or 17th bit (this information is technically incorrect). |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Apr 19, 2006 7:54 am Post subject: | |||||||
|
|
|||||||
snestech.txt
I'm trying to implement the shift buffer he describes. The only inconsistency in his document is what happens when a controller is unplugged after read 16. He says 1 is always returned here, then goes on to say that unplugged gamepads always turn 0's. Which is it? I'd strongly believe it was 0, leading me to believe that $4016 stops at the joypad connected bit and continues returning that until strobed again. I don't now what your code is doing exactly. The strobe value already has to be 0 to reach the case 15 condition. And you never return the controller connected bit (which is the 17th read after strobing $4016), nor stop the joypad read pos from overflowing back to zero. I'm going to kill the "seventeenth bit", and instead use a fake "sixteenth" bit to return the status of whether or not a joypad is connected. Sound good? ----- EDIT: Ok, OAM sprite list caching removed, raised speed by ~1.5% in most cases, heh. I have the same bug in Super Conflict as Super Sleuth :( Fixed joypad support, and in such a way as to still allow a key + joypad button to be mapped to a single SNES key, so you can switch between the two at will without having to remap everything. For v0.017, I'll add an option to swap controller ports 1 and 2. So that leaves beta testing for the new features, and this release should be ready to go. 9-10 of 26 bugs should be fixed. Not too bad, I suppose ;) |
|||||||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Wed Apr 19, 2006 10:01 am Post subject: | |
|
|
|
| My bad. I read your code incorrectly http://users.tpg.com.au/advlink/temp/keybtest.rar I posted this on CR for reverse engineering the X-Band keyboard but you might also find it useful. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Apr 19, 2006 10:45 am Post subject: | |
|
|
|
| Woohoo! Great news! I volunteer to beta test. PM me at your convenience. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Apr 19, 2006 11:29 am Post subject: | |
|
|
|
| Alright, hopefully tomorrow. It'll be non-SSE2, possibly non-PGO. Not sure yet. I'll let you know when it's ready. | |
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Wed Apr 19, 2006 2:00 pm Post subject: | |||
|
|
|||
_________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Wed Apr 19, 2006 2:09 pm Post subject: | |||||
|
|
|||||
_________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed Apr 19, 2006 4:31 pm Post subject: | |||||||
|
|
|||||||
|
|||||||
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Wed Apr 19, 2006 4:57 pm Post subject: | |
|
|
|
| I just tried BSNES on my superfast dual-core laptop and I'm very impressed. One thing annoys me though. Do I need to configure my video drivers to get rid of the annoying interpolated blurriness? I want my clean pixels dammit! VisualBoyAdvance did the same thing...EXTREMELY ANNOYING. I hate to complain...but why do emulator authors allow interpolation to be enabled by default and not have a way to disable it? | |
16-bit Corpse | Nyoron
Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
| Posted: Wed Apr 19, 2006 5:13 pm Post subject: | |||
|
|
|||
What happens if you disable DirectDraw Acceleration? _________________ My site with random stuff whicker: franpa is grammatically correct, and he still gets ripped on? sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really. |
|||
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Wed Apr 19, 2006 5:15 pm Post subject: | |||||
|
|
|||||
BSNES refuses to open. |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Apr 19, 2006 7:29 pm Post subject: | |||
|
|
|||
As has been mentioned before, it's just how DirectDraw works. No way around it. Something along the lines of: if requested output resolution is different (and larger) than source resolution, use bilinear interpolation. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Apr 19, 2006 7:38 pm Post subject: | |||
|
|
|||
Are you using the RC1 version? That particular version has a "pixel filter" and "bilinear filter" that you can choose between. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Apr 19, 2006 11:28 pm Post subject: | |
|
|
|
| I'll
just post RC2 here later on. I do need actual testing, though. I redid
a lot of stuff, especially in the GUI. The important things are trying
to add a bunch of game genie / PAR codes, and then editing and deleting
them and hoping it doesn't botch anything in the process, making sure
no UI elements that aren't disabled do nothing, verify all the
different joypads+keys work ok, and of course looking out for crashes. The new version uses Direct3D (you need DX9 installed), and that lets you turn off the bilinear filtering. Though you'll hate the way anything looks when you enable aspect ratio correction without it, even at massive resolutions like 1600x1200. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu Apr 20, 2006 12:01 am Post subject: | |
|
|
|
| Oh, the GameGenie / PAR code stuff I can do. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Apr 20, 2006 4:44 am Post subject: | |
|
|
|
| You must copy and paste these links into your address bar, as I disable offsite linking. Please post any and all feedback you can. What you think of the new configuration system (how the UI works for you. Is it too complex now? Is it better to have more power? Is anything not clear enough?), how the new cheat system works for you, how the Direct3D9 interface works for you, how the new input system works for your digital and/or analog controllers, what you think of the adjustable axis tolerance setting for analog joysticks ... whatever you can give me. You can edit the config file by hand and modify video.renderer to "dd" if you want to use the old DirectDraw7 renderer (in case the Direct3D9 renderer isn't working too well for you). There's some new changes since the last post. I reverted the windowing code back to my old for loop, I kept finding crashing bugs with the direct memset method, and it makes no difference in speed, so screw it. Code is cleaner this way, anyway. I also tried to fix up the SRAM memory mapping at the request of Jonas Quinn. It's really difficult, because I basically have to simulate all 40 or so different PCB layouts using only two generic templates. See src/memory/bmemory/bmemory_mapper_generic.cpp for more details on the new SRAM mapping. SSE(1 or 2) is not required, since that was a big problem last time. bsnes v0.015 rc2 : byuu.cinnamonpirate.com/files/bsnes_v015_rc2.zip bsnes v0.015 rc2 source code : byuu.cinnamonpirate.com/files/bsnes_v015_rc2_src.zip Let's keep a list of issues. So far, I've noticed I left "use triple buffering" in the video options menu, despite it being configured on a per-video-profile basis now. Ignore that option, please. |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Thu Apr 20, 2006 5:20 am Post subject: | |
|
|
|
| Took
me a little while to work out how to set up the Fullscreen modes, but
once I figured that out, it works great. I'm using the D3D9 renderer
here. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Apr 20, 2006 6:34 am Post subject: | |
|
|
|
| Fixed : captain novolin castlevania - dracula x earthworm jim 2 final fantasy - mystic quest krusty's super fun house super conflict super double dragon super empire strikes back super return of the jedi - controls worked in v0.015 too, though... --- Still broken : battletoads in battlemaniacs captain america & the avengers mighty morphin power ranges - the movie mortal kombat genjuu ryodan RPM racing wild guns /new game/ jurassic park 2 - hangs before intro if you don't press start first --- The rest are untested, as I don't have the European or Japanese sets, sadly. SoM would take too long to get the world map up, so I didn't bother testing that. I didn't fix anything that would fix SoM anyway. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Apr 20, 2006 6:38 am Post subject: | |||
|
|
|||
I'll probably check the games that are fixed.. (though that'll be many many hours from now). As for the SOM comment, I don't exactly follow what you mean by getting the world map up (you mean the intro takes too long or something? I have a working SRM you can use so you can see the overworld with Flammie)... although I do know you haven't fixed it yet. _________________ FF4 research never ends for me. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Apr 20, 2006 7:16 am Post subject: | |
|
|
|
| Don't bother, I fully intended to update the buglist with this release. It did clean it up quite a bit First though, commentary on the new config system as requested: I like it a lot. However, things I recommend to make it better. a. I don't really like the transparent window idea. I can't really see what's behind it very well, and I don't know why I would need to anyway. It's kind of hurting my eyes to look at. I'd go solid, even if you can't figure out a way to make windows overlap each other on clicking. b. It would be nice if the config menu pauses the emulation while it's up. As it is, the menu coming up slows my games 80%, which results in the sound crackling and becoming super annoying. c. Most emulators come with a filtered image off by default. I think bsnes should follow suit and have things like scanlines and interpolation off to start with. Now on to the bugs. For some reason, the games with the "interlace issue" as I thought it was are working now, and no longer crash the emulator. Did this get addressed silently, or was this hi-res, not interlace? Secondly, one of the bugs seems to have changed since last release. Rendering Ranger R2 will always get to the title menu if you do fresh "load rom." However, if you reset the game, it has a chance of hanging after either of the two company logos. Welp, off to sleep... |
|
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Thu Apr 20, 2006 1:54 pm Post subject: | |
|
|
|
| Cannot get it to run comes up with the message user32.dll error and it is already in my windows/system directory | |
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Thu Apr 20, 2006 4:23 pm Post subject: | |||
|
|
|||
|
|||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Thu Apr 20, 2006 4:37 pm Post subject: | |
|
|
|
| I only wish that the input configuration interface would actually show which keys have been assigned to the controller. Other than that, it's excellent. :D | |
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu Apr 20, 2006 5:05 pm Post subject: | |
|
|
|
| Blah, why do I get Direct3D9 errors when I have the latest DirectX installed? EDIT: I got it to work by changing the settings from Direct3D9 to DirectDraw7... But the configuration flashes and lags the emulator whenever you open it. Also is there anyway to get a link from File or Settings menu to open the GameGenie / PAR cheat console? Otherwise, good work! I'll be testing the Cheats in a couple minutes... |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Thu Apr 20, 2006 5:26 pm Post subject: | |
|
|
|
| I got Firefox this time to dl the file as it doesn't like IE. Smooth sailing. I'll give it a go and report anything unusual. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Apr 20, 2006 5:33 pm Post subject: | |||
|
|
|||
Direct3D9 is used for everything now, by default, correct? Works fine for me, here. My thoughts: Under "Video Options," should you maybe make "Use Video Memory Surface" and config-only setting? This seems like a pretty advanced setting that end-users should not need to see. Triple buffering, as you said, is moving to the Video Configuration page. Can you eliminate the Video Options menu and just put "Show FPS" on the top-level of the Settings menu? "Mute Sound Output" might be shortened to just "Mute Sound." "Output" is just another word that could confuse end-users. Under "Speed Regulation," you might want to make Enabling/Disabling it a config-file only option. Some people might be screwing around, disable it, then freak out. It seems like you would want to have it enabled pretty much all the time. Also, having the audio sample rates on that list is also confusing. It seems to me most end-users would only be confused by that. It would be nice for the About box to have a title bar and an X button (just to make it a more "standard" window, to fit in with the rest of the dialogs in the emulator). Settings-> Configration It definitely needs configurable transparency and always-on-top (if even only on/off). Video Settings: The default windowed/fullscreen profile choosers should be the first thing on this page. As they are now, underneath "Profile to configure," it makes them seem that they could be a setting dependent on the current profile. Perhaps you can move these default choosers out of the Configuration page and into the Settings menu. The video settings page is somewhat confusing to me. I realize that an SNES emulator does require this level of complexity for accurate and highly configurable video settings. But the video configurations are not very apparent. Two suggestions: 1) Perhaps you can visually order the settings like a schematic, showing the order in which each setting is applied to the native SNES video output. This would increase clarity somewhat. 2) Maybe create mouseover tooltips with expanded explanations of each setting. I'm particularly confused about: The relationship between Multiplier, Render width/height, and Resolution width/height. And how those interact with the software filters. And "Correct aspect ratio." There's just a lot of settings that aren't very apparent as to what they do, for someone unfamiliar with how it all works. Should the "Direct" software filter be re-named to "None"? Also, which of Pixel and Bilinear is nearer to "No" Hardware filter? Ideally, there should be a "None" for both software and hardware filter. Color Adjust: Maybe rename it to "Color Adjustment" in keeping with the noun phrases you use to label the other pages? Raster Settings: Needs a restore defaults. Input Configuration: I concur with Xamenus, we need to see what the current assignments for the keys are. Also, it might be good to have a "Restore Defaults" button on the Input page, to automatically but Resistance back to 75%. Also, are there any default key mappings? It might be good to create some, for both P1 and P2, so people can play right out of the box. And make sure the buttons don't conflict between P1 and P2 (I think the default mappings for ZSNES conflict between P1 and P2). Nestopia has a nice controller set up page, as does PSX Emulator (for examples). Because you plan on supporting mutliple input keys for a single SNES button, how are you going to show this? Completely free-form, so that each SNES button could have an infinite number of input keys? Or, only one keyboard key and one joystick/gamepad key per SNES button? If you move away from the input screen using the SNES controller schematic, it might be nice to use a simplified image of the SNES controller, as you had before. People may not be intimately familiar with these emulated systems as the systems get older and the people using the emulator get younger. Finally, why do you release your emulator with the config file? This is somewhat confusing, seeing as how the released package should probably use the "default" settings, which are the settings used with no pre-existing configuration file, correct? Also, it might be good to create a few pre-existing video settings, so that people have more ability to use your emulator right out of the box. Few people would probably be satisfied with the default video settings. At the very least, it may be time to start including documentation with your emulator. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Apr 20, 2006 7:08 pm Post subject: | |||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
The joys of supporting 8-10 year old software... I swear I can't keep Win9x working to save my life :( This is likely due to the layering settings for translucent config box.
Will do.
What can I say, my web server has discerning tastes :)
Sure.
Sure.
No. I like turning it on and off, it's the best way to find out the raw speed of the emulator. Perhaps I'll change it to a title you don't want to uncheck, eg: Speed Regulation -> <checked> (I am not a dumbass / I always read software documentation) --- Slowest Slow Normal Fast Fastest Sound good? :) I might drop the audio sample rates and turn it into a % of speed, that's good enough. The reason it's there is because your sound card must support that sampling rate on really shitty sound cards, even with kmixer. But since most users won't be modifying the defaults, it should be fine.
How many about boxes have you seen that look like win32 forms? That's kind of the idea. You can move the main emulator window and the about box by right clicking and dragging on the forms. I realize that isn't documented anywhere. You can also switch video modes with Ctrl+<numpad number> (not with ctrl+<number> because they aren't in order, they are 1-0 and not 0-9), adjust frameskip with +/-, adjust speed regulation with ctrl+[+/-], pause with F12, toggle the menubar with esc, and swap fullscreen mode with F11. Eventually there will be a config page to adjust these options and more.
For now, look at bsnes.cfg last option, misc.config_window_alpha_level.
I'll swap them. I want the menu as clean as possible.
I thought it would be too tough for most to use. I'll just make a simple mode for the emulator. It will run in simple mode unless you read the documentation to learn how to enable advanced mode.
Direct to none is fine. Pixel is none. I thought that was obvious, guess not.
Color adjust, sure. Raster settings, why? There's only two sliders there.
I explain this option in detail using that scrollbox thing. It lists the default right inside the box.
So that smart people can edit hidden options, and because I have to save your configuration settings somewhere. I'd rather store it in a plain english text file than in the windows registry (hello, SNES9x "delete your registry keys" problems) or in gibberish binary (hello, older pre-PSR ZSNES "delete your config files" releases).
There are pre existing settings. Five of ten are currently configured. I guess I'll just remove the filtered modes. How's this? 1x scale windowed 2x scale windowed 2x scale + aspect correct windowed <default> 3x scale + aspect correct windowed 4x scale + aspect correct windowed 2x scale 640x480 fullscreen 2x scale + aspect correct 640x480 fullscreen <default> 2x scale + aspect correct 800x600 fullscreen 3x scale + aspect correct 1024x768 4x scale + aspect correct 1280x960 Good? Triple buffering will be off until I can fix the crackling audio problems I get with it.
Apathy. |
|||||||||||||||||||||||||||||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Apr 20, 2006 7:28 pm Post subject: | |||||||||
|
|
|||||||||
In
summary: I think that for best "portability", there should be a very
compatible, useable set of default settings stored in the bsnes
executable, so that the first time a user runs the bsnes executable
(without config files), bsnes generates a config file with those
defaults. The defaults should have everything required for play,
including default key settings.
What I meant here is, why do you release the emulator with an already pre-configured config file along with the executable? I don't want registry settings either. What I meant is that I'm used to the behavior of ZSNES, where there is no configuration file included in the archive. It generates the config files on first run of ZSNES. So ZSNES stores all the default behavior in the executable (or something). But I noticed that the settings you have in the config file that you release with bsnes is not the same settings as are generated after I delete the config file.
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Apr 20, 2006 7:32 pm Post subject: | |
|
|
|
| Jipcy had many good suggestions, but I will say that: -I don't like the tool-tips idea. Tool-tips and pop-ups in general suck, IMO. -most things did not appear "too complex" for me. If anything, adding a simple and advanced mode in addition to everything makes it even more complex. -and I agree with byuu about documentation. Chances are people won't read it anyway. Everything seems self-explanatory. Documentation increases download size and is a total mess to deal with. Look at ZSNES. And yes, D3D9 works for me, too. Get with the times people, it's nothing new. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Apr 20, 2006 7:37 pm Post subject: | |||
|
|
|||
I think byuu was suggesting that simple mode would be on by default. Complex mode would not be visible to the user at all (initially), and the only way to enable complex mode would be to set a switch in the configuration file. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Apr 20, 2006 7:41 pm Post subject: | |
|
|
|
| Yes, but is it really worth the trouble to do that? There aren't that many settings, and where's the line between simple and complex? | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Apr 21, 2006 3:08 am Post subject: | |||
|
|
|||
I'm renegging on this report. What happened was I recalled trying it, but only once, on .015, and it got into the level. So I thought it worked better, but I actually just got randomly lucky. I dled .015 again to see if I could reproduce what's happening now, and sure enough it is the same behavior. The game will make it to the title screen if you do a fresh load, but if you reset the game, it has a chance of hanging before that. If memory serves, zsnes used to have reset issues where memory wasn't getting flushed properly or something. I'm foggy on it, and it might be unrelated. I think I'll mention while I'm at it, that for Mortal Kombat, the (E) version curiously does not exhibit the wierd bug in battles. Maybe that info will be of use. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 21, 2006 8:10 am Post subject: | |
|
|
|
How's this? Ideally, I'd like the SNES joypad image stuck on there somewhere, but the screen is pretty cramped as it is, and I hate to increase EXE size with another bitmap :/ EDIT: Or how's this? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Apr 21, 2006 8:55 am Post subject: | |
|
|
|
| I
really like that. It addresses the issue of knowing what's bound to
what. The loss of the image or controller layout only has one drawback
for me, and that is remembering that B comes before A on the
controller. Am I just crazy or does anyone else think this way? If so,
I would suggest placing B before A, Y before X on the list. Edit: Aww, wierd you edited as I posted. Ok, I still prefer the first one, and I think you can get away without an image by just ordering the buttons as above. Furthermore, it looks like if you got rid of the top title for each config window (i.e. "Input Configuration"), you may have the space available to do away with that scrollbar completely and just have a full-view list window. But yeah, what do other people think? Last edited by FitzRoy on Fri Apr 21, 2006 9:04 am; edited 1 time in total |
|
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Fri Apr 21, 2006 8:56 am Post subject: | |||||
|
|
|||||
Yes i am running win98 |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 21, 2006 9:22 am Post subject: | |
|
|
|
| Third try: <third try removed, too similar to fourth> Edit: or fourth. With FitzRoy's suggestion for key ordering. Helps a lot for quickly configuring the controllers. Look good? Heheh, just kidding Ok, unless someone doesn't like this, this'll probably be what goes into v0.016. I'll go ahead and share my ideas for v0.017 now, however. Also, you can click update or just double click the line you want to update. I'm going to remove the joypad axis resistance setting from this page and rename it to "joypad configuration". I'm going to add controllers (renamed to joypads) 1-5 (or 1-8?), and you can configure whichever ones you want. Then, there will be a new input configuration page. This page will give you two combo boxes, one to select what connects to SNES controller port 1 (left port), and what connects to controller port 2 (right port). I'll try and draw a bitmap demonstrating this for the page, as well. You can select "None" for no controller, or any of the 5 (8?) controllers to be plugged into either port. Eventually, there will be a multitap option here, and there will be a multitap screen to configure what controllers are connected to which multitap ports. Hopefully one day there will also be SNES mouse, super scope 6, and 1-2x justifier options as well. Last edited by byuu on Fri Apr 21, 2006 10:20 am; edited 1 time in total |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Apr 21, 2006 10:14 am Post subject: | |||||
|
|
|||||
Well, some emulators crash on certain machines if you use the default settings. Happened to me with a build of SNES9x that has "use video memory" enabled. _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Fri Apr 21, 2006 2:34 pm Post subject: | |
|
|
|
| See this post: http://board.zsnes.com/phpBB2/viewtopic.php?p=108720#108720 I'm sorry, but byuu got out of hand, I banned him. Guys, you'll have to take your emulator affection somewhere else. Besides less face it, no one really likes bsnes, no developer in their right mind would add a single line of code for it except for byuu, so why are we keeping up this facade of making believe we like bsnes? I doubt anyone really likes that thing, so slow, has an awful website, no mirrors for binaries... _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Fri Apr 21, 2006 2:40 pm Post subject: | |
|
|
|
| Great, I hate that emulator, good riddance. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Apr 21, 2006 3:57 pm Post subject: | |
|
|
|
| This is weird...... _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Apr 21, 2006 5:21 pm Post subject: | |
|
|
|
| edit by dmog edit edit edit edit edit Last edited by Dmog on Sat Apr 22, 2006 1:51 am; edited 1 time in total |
|
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Fri Apr 21, 2006 5:30 pm Post subject: | |
|
|
|
| My post was edited by a moderator to say that. | |
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Fri Apr 21, 2006 5:42 pm Post subject: | |||
|
|
|||
|
|||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Fri Apr 21, 2006 5:48 pm Post subject: | |
|
|
|
| For some reason this whole occurance seems like something out of "This is Spinal Tap." | |
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Apr 21, 2006 5:55 pm Post subject: | |
|
|
|
| edit edit edit edit edit edit edit (so we all saw the 'edit') Yeah ok. Great joke I guess (rolleyes). Would have actually been funny if it was around April 1st though... I did find it weird that Nach said that "no one would want to contribute one line of code", seeing as he did contributed himself but heh... Last edited by Dmog on Sat Apr 22, 2006 1:50 am; edited 2 times in total |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Apr 21, 2006 6:03 pm Post subject: | |
|
|
|
| I LOVE BSNES. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Apr 21, 2006 6:04 pm Post subject: | |
|
|
|
| Oh my, I leave for 12 hours and the shit hits the fan... Dmog is right too, and I'd like to also point out the fact that byuu's SNES emulation information is quite true (in fact, SteveSnake himself has said the exact same stuff, and nobody took him seriously). bsnes will be the Kega of the SNES emulators (In fact, it allready is). Last edited by King Of Chaos on Fri Apr 21, 2006 11:07 pm; edited 3 times in total |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Fri Apr 21, 2006 6:13 pm Post subject: | |
|
|
|
| Posting in shitty thread. DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU |
|
Rookie
Joined: 10 Sep 2004
Posts: 32
| Posted: Fri Apr 21, 2006 6:14 pm Post subject: | |
|
|
|
| This is so ridiculous that it must be a joke. Sad thing is I can only see one person laughing. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 21, 2006 10:25 pm Post subject: | |||||
|
|
|||||
|
I'm not banned. It was a joke by Nach, in response to my post on "Nice Board". Apparently in bad taste :/ He probably shouldn't have posted in this thread as well, but he did leave plenty of hints.
Nach himself has contributed 250kb of code to bsnes thus far, adding ZIP, GZ, JMA and Cx4 support.
http://nsrt.edgeemu.com/forum/viewtopic.php?t=490 Anyway, you have my apologies. Especially to Joe. I would've replied much sooner before anyone got upset, but I was asleep and just woke up. And as per IRC, Nach is gone for the next ~16 hours or so. Please don't be upset with either of us, Nach has contributed an unbelievable amount of work to bsnes, and will be hosting my next release for me, and I'm very grateful. |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Apr 21, 2006 10:33 pm Post subject: | |
|
|
|
| Sarcasm translates badly on forums. See the responses... _________________ FF4 research never ends for me. |
|
Lack of Imagination
Joined: 31 Jul 2004
Posts: 379
Location: In your closet!!!!
| Posted: Fri Apr 21, 2006 11:00 pm Post subject: | |
|
|
|
| HoLY SHEEP SHIT COCKS AND BALLS tis what you suck yea you no not you that guy right there |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Apr 21, 2006 11:05 pm Post subject: | |
|
|
|
| Still a little late for April Fools day. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Apr 21, 2006 11:05 pm Post subject: | |
|
|
|
| Yeah,
a little too elaborate for me, bad timing in the middle of an RC test,
and sarcasm is indeed very hard to detect from text alone, even with
hypocritical statements. What was funny, though, were the people who were ready to start an emulator war over it Last edited by FitzRoy on Fri Apr 21, 2006 11:06 pm; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 21, 2006 11:05 pm Post subject: | |||||
|
|
|||||
themewin, please die.
Or more generally, on the internet as a whole. Such a shame, I grew up around sarcasm and satire. It's second nature to me.
You're not kidding... :/ Again my apologies (my name is the embodiment of internet drama), and I hate to seem insensitive but can we please move on with the beta testing? I'd like to keep this thread from getting derailed as it is "THE bsnes board" for the time being :/ I want to get v0.016 out very soon. I've added all of Jipcy's suggested changes. Is the fourth input config screen adequate? Any other suggestions before release? I'm frankly sick and tired of supporting Win9x, but should I revert the translucency settings to support pre-2000 Windows? |
|||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Apr 21, 2006 11:12 pm Post subject: | |
|
|
|
| Yea, I have one quick suggestion... Add a menu item for the Cheat Code Editor to either the "File" or "Settings" menu. Either that or hotkeys to open it quickly. One more thing, how hard would it be to have the emulation pause anytime you get in the Configuration? Because it get's a little annoying to have the config dialog open while the game is still running. Other than that, it's good to go. About the Win9x support, I say dump it completely as there isn't many people out there anymore with ME and below. Oh yes, I forgot to add the File History request. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter Last edited by King Of Chaos on Fri Apr 21, 2006 11:24 pm; edited 1 time in total |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Apr 21, 2006 11:15 pm Post subject: | |||
|
|
|||
I think I said something about this earlier. Frankly you should support Win9x.. remember that the translucency is a neat thing, but nothing required for the operation of the emulator... it makes no sense to break Win9x compatibility based on this feature. I wonder whether it is make sense to dump Win9x... considering that BSNES needs a hefty processor in the first place to run it. _________________ FF4 research never ends for me. |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Fri Apr 21, 2006 11:21 pm Post subject: | |
|
|
|
| Since this was all a joke, I owe Nach an apology. He still has my respect. Oh well he had me completely fooled. Kudos to him. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Apr 21, 2006 11:22 pm Post subject: | |||
|
|
|||
Exactly. It makes more sense to dump pre-Win2000 compatibility. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 21, 2006 11:25 pm Post subject: | |||||||||
|
|
|||||||||
File is for ROM manipulation, Settings is for emulation manipulation. I'll add a quick link that takes you to the cheat code screen under Misc, ok?
That's doable. I'm going to leave this setting off by default, and add it to the config file for now. The reason I leave it on is because the raster settings do not take effect until the next frame is rendered, thusly you won't see your changes if emulation is paused. Eventually, I'll add another panel for config screen configuration, heheh. Throw in options to toggle always on top and pause emulation on show.
Fine, I'll remove it. I'll have to post another build for people on Win9x to test, as I won't be able to see if it works myself.
Grah. Do we need a poll for this? You either get win2k+ features, or winME- compatibility :/ Maybe I can add Win2k+ detection and call the SetLayeredWindowAttributes function via LoadLibrary/GetProcAddress, so it works on WinME-, just without any translucency. I know DMV27 uses WinME-, and his assistance is always invaluable, so I should probably just support it for him alone. |
|||||||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Apr 21, 2006 11:33 pm Post subject: | |
|
|
|
| Thank you. And yes, a poll seems like the logical solution. EDIT: It seems I might of found 2 bugs... 1. The cheat code editor dosen't ignore the : in PAR codes (Example: 7E045B:00 for War Of The Gems). 2. Under the Windows XP theme, the Configuration looks messed up (white on grey) Although this won't probably happen if you're using the Windows Classic theme. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 21, 2006 11:40 pm Post subject: | |
|
|
|
| PAR codes do not contain a : Try 7e045b00. Do you know of a lot of codes that have : there? I'll try and support it if so. The main cheat issue I was worried about was manipulating a list of like 20+ codes for a single game. Are weird corruption issues occurring when you add/remove codes, or no? I'll include a manifest file so XP themes are enabled, but I'm unable to bit twiddle the interface to perfection as I like with XP themes :/ |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Apr 21, 2006 11:43 pm Post subject: | |||
|
|
|||
|
Yes,
almost all PAR codes I've ever seen include the : (Infact all that are
made in Kega and Gens, and the majority of the SNES ones made on
gscentral.org include the : ) Well, to fully test that for ya, I'll load up SMW and input about....40 codes and see what happens. EDIT: Ok, I have 25 codes in SMW right now, and I'm testing combos of turning some on and some off, and there are no crashes yet... EDIT 2: Ok, I'm finding some PAR codes don't work in bsnes (GameGenie seems to work fine), but they do work in ZSNES/Snes9x...
I've also found that X-Men - Mutant Apocalypse's PAR codes don't work either... But those codes *should* work. Ehh, I just hope they're not incorrectly made codes... _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter Last edited by King Of Chaos on Sat Apr 22, 2006 12:27 am; edited 3 times in total |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Apr 22, 2006 12:23 am Post subject: | |
|
|
|
| It's
doesn't hurt convenience much to not have translucency, and if it
breaks win9x support completely... well... I think it's beyond saving. You also previously expressed that you didn't want to add unnecessary space to the emu. With the Y/X B/A thing, I wonder if a reference image is further needed. I know you want .016 out soon, but so far I'm the only one commenting on this stuff :/ We need more input. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Apr 22, 2006 1:46 am Post subject: | |||
|
|
|||
Oh, fuck me :( It mirrors addresses. Just wonderful. Use the code 001490FF and it works fine. Sigh, this is going to add a lot of overhead. I hope mirroring RAM alone is good enough. I'd really hate to have to mirror RAM+ROM+SRAM... Anyone have more technical info on this? |
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Apr 22, 2006 2:00 am Post subject: | |||||
|
|
|||||
I'll try to get some information about this... In the meantime, I'll just reverse the addresses... _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||||
Rookie
Joined: 03 Mar 2006
Posts: 14
| Posted: Sat Apr 22, 2006 2:51 am Post subject: | |
|
|
|
| Anyone else have no sound at all in the new release candidates? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Apr 22, 2006 5:09 am Post subject: | |
|
|
|
| Ok, to try and make up for all the trouble this morning... byuu.cinnamonpirate.com/files/bsnes_v015_rc3.zip byuu.cinnamonpirate.com/files/bsnes_v015_rc3_src.zip Please download the source only if you intend to do something with it. Changelog: - Added ten default video modes - Removed bsnes.cfg with archive - Removed audio frequency from speed regulation menu for simplicity - Removed Video Options submenu and placed Show FPS under main settings menu - Updated video settings panel to be more clear - Completely rewrote input configuration screen, now shows currently assigned key - Added support for PAR codes in "aaaaaa:dd" format - Added mirroring to GG/PAR codes for WRAM addresses only - Fixed bugs in GG/PAR support when two codes shared the same address, but had different override values - Turned off transparency on configuration panel by default Errata: - Still does not run on WinME or below - Still did not add Cheat Code Editor quick link to misc menu - Still uses .cht extension, which may/may not cause horrible problems with ZSNES' completely different binary .cht file format I decided to stick with "mute sound output", looks too empty next to speed regulation without it, and I really don't want to cater to that low a denominator -- "output? what that thar sapposed ta meen! geez teh ZNES izznt so kanfuzzalin!" :/ |
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Sat Apr 22, 2006 5:25 am Post subject: | |||
|
|
|||
|
http://rapidshare.de/files/18518397/bsnes-patch-2006-03-18.zip.html Some of these fixes are redundant now, but the timing changes should be accurate. I don't know if they fix any games though. bcpu_dma.cpp.patch initializes the dma regs to 0xff on reset. Ignore this patch if that is incorrect. bcpu.cpp.patch updates the open bus value in mem_write. It also has changes for irq/nmi/power/reset. bcpu_int.cpp.patch adds support for emulation mode irq/nmi, and makes nmi have a higher priority than irq. bcpu_mmio.cpp.patch fixes joypad strobing for $4016/17, which fixes Super Double Dragon. Also, (H)DMA is now blocked from accessing $420B, $420C, and $43xx. I know that writing 0 -> 1 to $4016 will latch the joypad state, but does writing 1 -> 1 also latch the state, or does the previously latched state persist? cart.cpp.patch changes the checksum scoring to allow Choujikuu Yousai Macross to work. If the graphics are corrupted, deinterleave the rom with NSRT. op_misc.b.patch fixes brk/cop timing, txs flags, and wai timing. With the wai timing fix, bsnes now passes your original timing test:
op_pc.b.patch fixes the timing of rti. Also, there are some things I did not fix: Reading from OAM should not update the oam latch. Writing to CGRAM should update the cgram latch (regs.txt). Stack over/underflow in emulation mode. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Apr 22, 2006 5:52 am Post subject: | |||||||||||||||||
|
|
|||||||||||||||||
Yay! Always a delight to see a new post from you.
It happens on power-on for sure. I don't know what happens during reset. A lot of registers are reset at power-on only. I've been avoiding this area as my copier is bad test for power-on register states.
Ah, maybe that'll fix Captain America. I can't wait to get that fixed so I can delete it. Bad, bad game.
I thought it already had a higher priority. It always tests for NMI first, and when NMI is invoked, it sets I, meaning IRQ can no longer trigger. I'll look at the patch, I guess.
Yep, found that one. And two other input bugs. See the rc3 source above. Good question about 0->1 or 1->1. For now, I latch during both cases. Also, $4017 has no strobing logic. Only $4016, and it affects both controllers (shared pin). Again according to Charles MacDonald. Weird, hm? Got the (H)DMA stuff. Not sure I fixed $2180 transfers right. I know there are some ways you can use $2180 and have it work, I don't know if I've inadvertedly blocked some of those methods. I will need to test on my copier.
Holy crap, the graphics were corrupted because I was detecting the header from the wrong place?! Geez, that's absolutely wild that it worked at all. I take it the game mirrors its header to both $7fc0 and $ffc0?
Wow, the first CPU core fixes in forever.
I've tested this extensively. I'll have to look very closely at your timing fixes.
I'll see what I can do, thanks for the heads up. I'm holding off on the stack over/underflow cases, as they are quite bizarre and will take some effort. |
|||||||||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Apr 22, 2006 6:43 am Post subject: | |
|
|
|
| Wow, nice DMV! Any chance we could see this stuff in by .016, byuu? |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sat Apr 22, 2006 9:39 am Post subject: | |||||
|
|
|||||
Woah, so the problem was just that? I dunno if you remeber, but I pmed you awhile back about the game not working. That's great that you have a fix for it now.
I know what I'll be playing when bsnes 0.016 comes around. Hmm I guess
that's also the reason why I have to force high rom detection to play
it in SNEeSe.
|
|||||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Sat Apr 22, 2006 10:20 am Post subject: | |||||
|
|
|||||
You should always check the reset vector before you look at checksums. Obviously a reset vector of $0000 is bad. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Apr 22, 2006 1:59 pm Post subject: | |
|
|
|
| Byuu.. Please do not Remove the Tripple buffering On my radeon 9600se connected to my Samsung 710T 1280x1024@32bbp 60hz, i get a constant tear, it only gets fixed by enabling tripple buffering. Also my sound does not seem to get corrupted? can you describe the soundproblem you are having as i do not seem to have any problems with this setting enabled bsnes is unplayable without this setting on my tft monitor. also it seems that Front Mission v1.0 J with the english patch does not work, it doesnt load at all. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Apr 22, 2006 2:13 pm Post subject: | |||
|
|
|||
Major prop goes to DMV. Good to see others Snes gurus/knowlegable people lending a helping hand
If the original game work, then it's maybe just a faulty patch...or worse, a translation that doesn't actually work on the real hardware.According to byuu there are a lot of them out there. |
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Apr 22, 2006 3:06 pm Post subject: | |||
|
|
|||
Yep, that fixed those mirroring problems. All codes now work perfectly _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Apr 22, 2006 3:30 pm Post subject: | |||
|
|
|||
My vote goes for transparency in menues. The way I see it: if you have a PC fast enough to handle bsnes, why would you only have win98 installed? (instead of a dual-boot 98/XP for example) The only reason to have win98 installed anyway is to be able to run some very old program that XP doesn't like. In fact, that's the reason I had a dual boot system, but I'm ditching 98 in favor of Linux. |
|||
Lack of Imagination
Joined: 31 Jul 2004
Posts: 379
Location: In your closet!!!!
| Posted: Sat Apr 22, 2006 4:04 pm Post subject: | |
|
|
|
| AHAHAHAHAHAHA o helo internets |
|
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Sat Apr 22, 2006 7:20 pm Post subject: | |
|
|
|
| Is
there any way bsnes can butter my toast? Forget this transparency
business, let's worry about the most important features first . |
|
Hazed
Joined: 29 Jul 2004
Posts: 86
Location: USA
| Posted: Sat Apr 22, 2006 7:30 pm Post subject: | |||||
|
|
|||||
I have tried the translation on a GDSF7 copier, and it does work. tetsuo55, are you sure you correctly patched your ROM? Make sure you patched a headerless version 1.0 ROM, using version 1.0b of the patch. |
|||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Apr 22, 2006 8:03 pm Post subject: | |||
|
|
|||
Please die. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Apr 22, 2006 8:14 pm Post subject: | |||||
|
|
|||||
I don't think it's too farfetched to think that some people with slower cpus would happily run bsnes with frame-skipping in a win98 environment. Besides, it's so much easier on the eyes to read things in the config without the transparency. And since it only works in windowed mode, it's quite easy to move it out of the way and see the game image regardless of whether it's transparent. |
|||||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Sat Apr 22, 2006 8:25 pm Post subject: | |
|
|
|
| Silly bug report: Attempting to do either a hard reset or a soft reset while no game is loaded will crash bsnes, at least under Windows XP Pro SP2. Maybe you'll want to grey out those options while no game is loaded. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Apr 22, 2006 9:19 pm Post subject: | |||||||||||
|
|
|||||||||||
It's still there, I just removed the menu option as it's set on a per-video-profile basis now.
Wow, good to know. It messes up badly for me :(
There are, but FH is very attentive to details like this, I believe he has the ability to test his code on real hardware. Is anyone else having a problem with Front Mission?
Ok, I think I can satisfy both. I'll add another config page and add an slider to adjust window luminance that will only show up on 2k+, and an always on top option for all OSes.
I often run it on my 600MHz Pentium III at 50% speed. Great for puzzle games like Wordtris. The music in that game is so bad it actually sounds better at half tempo :) |
|||||||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Apr 23, 2006 5:06 am Post subject: | |||||||||||
|
|
|||||||||||
Yeah,on second thought, I suppose having support for an additional OS might be more useful. Basically, it's pretty equal to me one way or another.
Sounds good |
|||||||||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sun Apr 23, 2006 7:00 am Post subject: | |||||
|
|
|||||
My God, it's full of sarcasm. Apparently, all disbelief is suspended automatically when it comes to this topic. Reach for the stars, young prince. One day soon, your computer shall butter your toast, and brew your coffee. Getting back on topic, there really is no sensible way to make translucent menus, short of hacks, or rendering your own menus. Although I'm sure figuring a way around that is almost as constructive as turning the SNES into a Sega Saturn without actually shoving a couple of SH2s inside, because I hear programming for those things is a real bitch anyway. Maybe hotwire a couple of P4s into a cartridge instead... Now we're talking. :D |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Apr 23, 2006 8:59 am Post subject: | |||||||
|
|
|||||||
The one i am using is from a goodsnes set, i did not patch it myself, i need to get my snes to see if it actually works on that, the game does work in snes9x and zsnes though also in zsnesxbox |
|||||||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sun Apr 23, 2006 10:56 am Post subject: | |
|
|
|
| It's quite simple really. The rom in goodsnes is a dud. This was taken directly from the readme for the patch: "The unpatched file size should be 3146240 bytes. The patched file size should be 3441152 bytes. Any variation in the patched file size would be down to your patching utility and not the IPS file; it would also cause problems with running the ROM image." Goodsnes prepatched rom: 3,440,640 bytes My patched rom: 3,441,152 bytes Also you need to apply the 4MB fix patch to run the game in bsnes. However it wont work with the prepatched rom in goodsnes for obvious reasons. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Apr 23, 2006 2:51 pm Post subject: | |
|
|
|
| NSRT > GoodSNES at this point _________________ FF4 research never ends for me. |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sun Apr 23, 2006 2:53 pm Post subject: | |
|
|
|
| Bah, currently I'm drowning in work, not much time to test the new RC of Bsnes. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Apr 23, 2006 8:04 pm Post subject: | |
|
|
|
| Hmm... nice job.. all the filters run beautifully.. close to 60fps on my system... A list of stuff to look into: 1) The config file BSNES generates needs to be cleaned up a bit and there's a few descriptions missing. (If you need a list, I can probably put one up.) 2) Using Video RAM needs an actual menu option or maybe a profile option. 3) Setting the default ROM directory should be like what ZSNES does currently.. ZSNES sets the ROM directory when you load a ROM... though you might want a switch to stop changing the ROM directory to use. 4) For the save path, it should be definable via the GUI (or configuration screen). Edit: Updated this post for clarity and because it might not have been obvious... _________________ FF4 research never ends for me. Last edited by Deathlike2 on Tue Apr 25, 2006 9:19 pm; edited 2 times in total |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Apr 23, 2006 8:57 pm Post subject: | |||
|
|
|||
wow thanks for clearing that up, ill patch the original rom myself then. Would it be at all possible to store savegames in a completely different path from the roms?? |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Apr 23, 2006 9:02 pm Post subject: | |||||
|
|
|||||
Um.. you can already do that in BSNES RC3 version byuu released... look in the config file after running BSNES for the first time. _________________ FF4 research never ends for me. |
|||||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Sun Apr 23, 2006 10:20 pm Post subject: | |
|
|
|
| english translation of bs zelda works fine... unlike in zsnes where it just fails to load. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sun Apr 23, 2006 10:37 pm Post subject: | |||
|
|
|||
Sure no problem. Oh and you need to convert the rom if it doesn't have
a super magicom header. One I found in the goodsnes set had it's header
stripped off. Use ucon64 to convert it to the proper size.http://ucon64.sourceforge.net/ here's the two patches if you need them: http://romhacking.net/?page=translations&transpage=362 |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Apr 23, 2006 10:45 pm Post subject: | |
|
|
|
| Well I finally updated directx to the latest version, so I finally had the chance to tried RC1 and RC3. At the risk of sounding repetitive, Blargg's filter is indeed amazing. The new video configurations are great too. Imo, the mutiple profiles could be a bit more intuitive,but it works well once you're used to it. One thing I noticed in RC3 is that if you enable the NTSC filter and you set the frameskip to something above 0 (like frameskip2) the image becomes quite "shaky". This doesn't occur in RC1 even with frameskip enabled. edit: I guess this is related to how merged fields work in the NTSC filters. edit2: I was going to suggest to change "allow invalid input" to "allow opposite axis" but it looks like you allready did. It's something that could be done on the real hardware anyway (provided you actually removed the d-pad cross thing) so they are not really "invalid" per-se (unless I missed something) |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Apr 24, 2006 12:13 am Post subject: | |||
|
|
|||
Well, perhaps an appropriate time to stop supporting pre-Win2k would be the same time Microsoft stops: http://support.microsoft.com/gp/lifean18.
Is it possible to display the chosen resolution of a given Video Profile on the profile select menu? This may help users remember what each of their profiles is. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Mon Apr 24, 2006 1:33 am Post subject: | |||||||||||||||||
|
|
|||||||||||||||||
The game still did not work the last time I tried it.
The corruption is caused by having an interleaved rom. The header is not mirrored, but the lorom header has a checksum of 0000/FFFF. The patch causes checksum values of zero to be treated as invalid.
The rti code was not calling last_cycle() in emulation mode, so I fixed it.
They are actually fairly simple once you understand them. You will need four new stack functions:
Use the "new" functions for each stack access, and the "new_end" functions for the last stack access of each opcode. If there is only one stack access in the opcode, just use the "new_end" function. Only opcodes that are new to the 65816 (not 6502 or 65C02) need to be fixed: JSL; JSR (a,x); PEA; PEI; PER; PHD; PLD; RTL. PHB, PHK, PLB are not in ob-wrap.txt, but they are 65816-only so they should also be fixed. The stack relative mem modes are already correct in bsnes. Also: Win9x support: http://www.catch22.net/source/files/TransparentWindow.c D3DX9 problems: http://www.toymaker.info/Games/html/d3dx_dlls.html |
|||||||||||||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Apr 24, 2006 3:35 am Post subject: | |||
|
|
|||
You can also get it from Microsoft here. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Apr 24, 2006 4:59 am Post subject: | |||||
|
|
|||||
Unfortunally I've done all that, and I still can't use D3DX9 for this... _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Mon Apr 24, 2006 5:20 am Post subject: | |||||||
|
|
|||||||
What video card are you using? If you are using integrated graphics... then don't expect DX9 to help you much... if anything. _________________ FF4 research never ends for me. |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 24, 2006 5:37 am Post subject: | |
|
|
|
| Thank you all for helping me beta test. I'll let you all be the first to try the final build of bsnes v0.016. [files deleted] I ask that no emulation news sites post links to these files, please. I am waiting on the files to be mirrored by Nach, at that time I will update my website with a changelog and links to the files. The immediate changes are that I corrected the crash on reset/power, added most of DMV27's changes (the interrupt-related ones I want to test myself on hardware before committing), added DMV27's notes on CGRAM/OAM latches, and added a quick menu link to the cheat code editor. I wasn't able to find anything that all of the emulation-level changes fixed. Only newly fixed game is Chou Jikuu Yousai Macross, due to the header detection fix. Please let me know if the new changes break (or fix) anything. Edit by Nach: Download bsnes 0.16 from http://nsrt.edgeemu.com |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Apr 24, 2006 7:40 am Post subject: | |
|
|
|
| No, thank YOU! This turned out to be a monster release over .015! One thing that did get "fixed" that I never commented on, was that removing the transparency also cured the massive slowdown during emulation while the config menu was up. Guess that thing was pretty intensive Yay.Semi-bug report (more aesthetic than anything): using the cheat code editor quick link will bring up the config menu, but the highlighted section will be where it last was, possibly not cheat editor. I've updated the buglist a little to note strange regional findings. I did this after discovering two more since Mortal Kombat: RPM Racing (J) actually draws the track correctly, and Earthworm Jim 2 (E) still exhibits sound issues despite DMV27s recent sound fixes that seem to have fixed the (U) version. Wierdness. But now I'm off to enjoy this. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Apr 24, 2006 9:33 am Post subject: | |
|
|
|
| Hi, bsnes released on my site, have fun. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Mon Apr 24, 2006 11:59 am Post subject: | |
|
|
|
| Does it work in Win98 yet ???? | |
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Apr 24, 2006 2:07 pm Post subject: | |||
|
|
|||
Get with the times. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Apr 24, 2006 2:46 pm Post subject: | |
|
|
|
| It should work with win98. Let me know if it doesn't. I built against the win95 APIs and dynamically mapped the translucency call, it will fail safely if on WinME or older. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Apr 24, 2006 4:05 pm Post subject: | |
|
|
|
| Is there any case when using system RAM would be faster than video RAM? What are the RAM requirements for bsnes? "Correct aspect ratio" makes the render width be 4/3 the render height, right? Not the render height be 3/4 the render width? "Bug" reports: 1. Requesting a manual render height of 22 pixels or less will give an error "Failed to create Direct3D9 device". If a game is loaded when you request this render height, or you load a game after setting it, bsnes will crash. 44 pixels is the smallest render height that will display video. bsnes can render any requested render width, without crashing. 2. Requesting an invalid (or unsupported) fullscreen refresh rate and/or resolution: - While a game is not loaded: You can go into and out of full screen without a crash, however, you can only use ESC to leave full screen. Pressing F11 does nothing. - While a game is loaded: bsnes will enter full screen, but will not render anything. Pressing ESC will crash bsnes. Pressing F11 has no effect. 3. Full screen resolution of 320x240 works for me, although the rendered video is somewhat messed up. This resolution is not listed as a supported resolution for my video card. Few modern video cards support full screen 320x240 resolution, as far as I know. 4. Setting a multiplier that causes the rendered screen size to be larger than the full screen resolution results in no video (but sound continues). 5. Some very weird things happen if you set the default windowed and full screen profiles to the same profile, then check the Fullscreen box, then Apply Settings. For example, it's impossible to escape full screen at that point. You can alt-tab out, then go back to the Config dialog, uncheck Fullscreen, then click Apply Settings, but then you get "Failed to create Direct3D9 device". 6. Select Misc->Cheat Code Editor. Close the Config dialog. Select Settings->Configuration. Configuration page is still Cheat Code Editor. Furthermore, as mentioned above, the highlighted page on the left side of the Config dialog does not correctly reflect the displayed Config page. 7. In the config file, are the video.filter.software and video.filter.hardware variables depracated? Or are these used for DirectDraw rendering? "Feature" requests: 1. Can you set a tab order so that you can tab between fields in the configuration screen? 2. You will probably already be taking care of this if/when you do the simple/advanced configuration modes, but should you grey-out (ghost, make unselectable) the Render width and height fields while "Manual render screen size" is unchecked? And, when checked, should the multiplier and correct aspect ratio boxes be greyed-out? 3. I don't think there should be default windowed/fullscreen profile selections. I know it confuses me, and probably confuses others. If I want to use different settings for windowed vs. fullscreen, I'll just configure two different video profiles, then switch between profiles as desired. F11 should attempt to use the current active profile settings for full screen, NOT the settings of the default full screen profile. Pressing ESC should return the user to the windowed settings of the current active profile, NOT the settings of the default windowed profile. 4. Alt+Enter is a much more common key combination for entering/exiting full screen than F11. Is it possible you can add this? 5. Furthermore, pressing ESC will not escape the Configuration Settings dialog if that window is active. 6. If "Half Gamma Adjust" is in fact less accurate to a real SNES, can you please not enable it by default? (Edited for correctness, after further research.) _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Mon Apr 24, 2006 9:38 pm Post subject: | |
|
|
|
| Ah v0.16 is out. Dl now, I'll test it as soon as I've got the time for it. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Tue Apr 25, 2006 1:27 am Post subject: | |||||
|
|
|||||
I ask a simple question and all the trolls come out to play I am up with the times but i don't like XP i prefer Win98 so no problem
|
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Apr 25, 2006 1:54 am Post subject: | |||||||
|
|
|||||||
The question, rather, is, does it work in Windows 98? If you are using Windows 98, please try out the program, and tell us if it works. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Apr 25, 2006 2:18 am Post subject: | |||||||||||||||||||||||
|
|
|||||||||||||||||||||||
It's a bad idea, and causes failure when on a 32-bpp desktop. It's almost always much slower, especially when scaling video.
Yes. Height is kept at a multiple of 224 to keep scanlines looking decent.
Do I really need to stupid-proof the emulator? I assume most of these issues won't affect anyone half intelligent. I guess I can work at it.
It's designed to save the last page you were on. Closing the window in reality only hides it. I didn't think making it select the right list option was important enough to hold up a release, but it'll get fixed.
I should be able to remove those now, thanks for mentioning them.
If I knew how I would. I set WS_TABSTOP and all the required flags, but tabs never work for me.
Yep, in due time.
Well I disagree, but I'll think about it.
Nope, windows is a bitch about letting the application see when the alt key was pressed. With the new key input detection being tied to DirectInput, I can't get the state of the alt key, and still let the menu bar function normally.
And why would it?
It's a gamma adjustment, it depends on your monitor if it's more or less accurate to an SNES game on your television. Personally, I like the way it looks, so it stays on. Takes a few seconds to uncheck. Thanks for the feedback, I'll improve what I can. |
|||||||||||||||||||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Apr 25, 2006 2:42 am Post subject: | |
|
|
|
| Thumb up on the 0.16 release Just a question: I tried various settings but I can't seem to achieve the same display as I get with 0.15 RC1. (that I absolutely love) edit: Never mind,problem solved. Last edited by Dmog on Tue Apr 25, 2006 3:31 am; edited 3 times in total |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Apr 25, 2006 3:03 am Post subject: | |||
|
|
|||
Depends. Do you want bsnes to be a general-purpose SNES emulator (with the obvious caveats of not including special chip support)? Then you probably need to check for (close to) edge cases that can crash the emulator. Nobody likes a program that crashes as a result of normal user input. Some of these crash-inducing conditions could be avoided with fewer options. For example, enumerating resolution and refresh rate choices with only those reported as supported by the video card. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ Last edited by Jipcy on Tue Apr 25, 2006 3:08 am; edited 1 time in total |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Apr 25, 2006 3:03 am Post subject: | |
|
|
|
| Double post sorry. Doh again...Wanted to edit my previous post. | |
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Tue Apr 25, 2006 3:11 am Post subject: | |
|
|
|
| Thank
you it works on Win98 and a quick bug Adventures of Dr. Franken, The
(E) on the title screen there is a glitchy line through the middle of
the screen does not happen in the (U) version |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Apr 25, 2006 3:24 am Post subject: | |
|
|
|
| Sorry if this is a known issue. I know triple buffering is considered "buggy" for now, but I still experience tearing even when it's set to 'true'. Does anyone else experience that? edit: Works for me in window mode but not fullscreen for some reason.. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Apr 25, 2006 5:22 am Post subject: Donkey Kong Country bug report | |||||
|
|
|||||
|
Question:
Are software filters applied before or after Aspect Correct? I would
suspect after, since I guess both Multiplier and Aspect Correction are
easy options for changing the render size, and that software filters
need to have a minimum of 2x render size to be effective. Anyway, I was
just wondering if there is perhaps any merit (visible difference) in
applying software filters before aspect correction? Also, is there any chance of a Recent Files list being added to the File menu? Bug report: I'm not sure if this has been reported before, but the Nintendo logo on the startup screen for Donkey Kong Country is only half-width when using the Scale2x filter and 2x multiplier. It also affects DKC 2. No other software filters have this problem.
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Tue Apr 25, 2006 12:38 pm Post subject: | |||||
|
|
|||||
Care to elaborate? I don't follow. I've written D3D/DirectInput applications before that use Alt-Enter to switch between fullscreen and window mode. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Apr 25, 2006 12:50 pm Post subject: | |
|
|
|
| Just a heads up: I updated the source archive on my site. The SDL Makefile can now be used to compile on BSD, or on Linux if you change sdl11-config to sdl-config. I also compressed the source archive better. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Apr 25, 2006 3:15 pm Post subject: | |
|
|
|
| Thanks. So then it builds ok? Neat. Do you know an easy way to use a single define that will toggle the inclusion of entire object files in the Makefile, and still work in the C source files, that works with both windows make and gcc make? If so, I'll make all of the video/audio/input renderers optional in preparation for merging the src/win port with the src/sdl port. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Apr 25, 2006 3:34 pm Post subject: | |||||
|
|
|||||
Now it does, yes.
Elaborate. BTW, I spend today making you a new unified Makefile. It has the following options: linux freebsd win-msvc win-msvc-sdl win-mingw win-cross It's not quite working yet, but it's getting there. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Zealot
Joined: 28 Jul 2004
Posts: 1336
| Posted: Tue Apr 25, 2006 6:27 pm Post subject: Re: Donkey Kong Country bug report | |||||||
|
|
|||||||
|
|||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Apr 25, 2006 6:43 pm Post subject: Re: Donkey Kong Country bug report | |||||||||||
|
|
|||||||||||
Yup. Standard message dialogs have that feature built-in, and other windows (forms) need just a few lines of code. _________________ savestate editor: vSNES latest public version
|
|||||||||||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Tue Apr 25, 2006 8:13 pm Post subject: | |
|
|
|
| Hey,
does anyone here have all the older versions of bsnes and its source
code available online for download? Since I haven't been a bsnes user
since the very beginning, I was just a little curious about bsnes'
history and how much it has progressed since the first version. BTW, how is BPF coming along? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Apr 25, 2006 9:08 pm Post subject: | |
|
|
|
| Update on unified makefile. I had to add some #defines in a few places to keep MinGW happy. So far I tested: linux win-cross Works like a charm. I'm guessing: freebsd win-mingw Would work great too. These: win-msvc win-msvc-sdl Definitly need testing. I want to clean these up a bit though. byuu, I can also make a batch file menu to pass all the various options if you want. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding Last edited by Nach on Tue Apr 25, 2006 9:47 pm; edited 1 time in total |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Apr 25, 2006 9:09 pm Post subject: | |
|
|
|
| Did any of my earlier input reach deaf's ears or something? _________________ FF4 research never ends for me. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Tue Apr 25, 2006 10:42 pm Post subject: | |||
|
|
|||
Probably because the SNES runs at 60.09FPS and your monitor runs at 60.00FPS. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Apr 25, 2006 10:43 pm Post subject: | |||
|
|
|||
What specific input is that? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Apr 25, 2006 11:13 pm Post subject: | |||||
|
|
|||||
http://board.zsnes.com/phpBB2/viewtopic.php?p=109068&highlight=#109068 _________________ FF4 research never ends for me. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Apr 26, 2006 12:05 am Post subject: | |
|
|
|
| Okay got new unified makefile cleaned up, it seems to work nicely in my tests. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed Apr 26, 2006 4:41 am Post subject: | |||||
|
|
|||||
So it does work for you in full screen? (i.e no tearing) I think byuu mention it's actually variable, it doesn't always run at 60.09FPS..but that's not the point.Afaik, triple buffering doesn't need to be matched with an exact refresh to remove potential screen tearing. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Apr 26, 2006 11:56 am Post subject: | |
|
|
|
| Dmog, try setting frameskip to 1, seems to help for me Byuu, are you using the latest NTSC filter?? it doesnt seem like it, the newest version is a lot faster and offers several options of quality http://www.slack.net/~ant/libs/ntsc.html#snes_ntsc Also, when the configuration screen is open, and i switch to fullscreen, i get stuck the only thing that i can do is ALT+F4 or ALT+TAB and then kill the application |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Apr 26, 2006 3:21 pm Post subject: | |||||||
|
|
|||||||
|
Deathlike2, not ignoring you, just horribly limited for time. I like the set ROM path on ROM load idea. NTSC filter is the latest version. If you aren't running at 60hz, edit the config file and changes snes.filter.ntsc.merge_fields (or whatever it is, just search for merge_fields) from false to true, and it won't bounce around. That should've been left as true for an official release, oh well.
No idea why. I'll close it when you go fullscreen, then. I have as old as bsnes v0.0.002 ir11 stored away somewhere. BPF became UPS. It's waiting on libraries and utilities to go live. The spec is pretty much finalized in src/libbpf.cpp, but the source needs to be rewritten as libups.cpp, and the code needs to be cleaned up.
Fine, fine.
Sure, alt+<key> combinations are sent as WM_SYSKEY(UP|DOWN) messages. I use a 50ms timer that polls the keyboard and joypad, and looks for keys that weren't down but now are, or that were down but now aren't, and sends the appropriate message to my window event handler. It does receive alt, when pressed, but it does not detect when enter is pressed once alt is down. |
|||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed Apr 26, 2006 8:54 pm Post subject: | |
|
|
|
| Bug report (I don't see it on the first page) In Tales of Phantasia (J)   After you win the battle:notice the purple in the second pic, it's looks like the dark green in the forest is replaced by this color Used bsnes 0.16. I'm pretty sure this doesn't happen on Z. Someone could probably check if it happens or not on real hardware. edit: crap...The image doesn't show up anymore..I guess imageshack is overloaded or something. Last edited by Dmog on Wed Apr 26, 2006 10:15 pm; edited 3 times in total |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed Apr 26, 2006 9:01 pm Post subject: | |||
|
|
|||
tetsuo, I started to experience some really weird issues after I updated directx, so I'm pretty sure that's the cause of the problem actually. Just another example: Since I updated directx, Nestopia has been running like three times the normal speed (and I haven't played with the settings or anything like that) Weird.
|
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed Apr 26, 2006 9:47 pm Post subject: | |
|
|
|
| I'm not really surprised. Never download the bi-monthly DX9 refreshes unless you have to. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Thu Apr 27, 2006 2:01 am Post subject: | |
|
|
|
| Here are a few minor fixes which fix at least one game. 65816: In emulation mode, the IRQ/NMI vectors are not correct (native mode vectors are always being used). They should be 0xfffe/0xffee and 0xfffa/0xffea. PPU: In "bPPU::is_sprite_on_scanline", the first line of code is "if(spr->x > 256 && (spr->x + spr->width) < 512)return false;". The last part should be "<= 512" because an 8 width sprite at x=504 is still off-screen. In bppu_mmio.cpp, r213e updates ppu1_mdr and r213f updates ppu2_mdr. Is this correct? ob-wrap.txt does not list these regs as updating the ppu mdr. SPC700: "mov_sp_x(0xbd, sp, x)" should not be setting the N/Z flags. SDSP: In "bDSP::read", the PITCH is being returned wrong (the low/high bytes are swapped). Fixing this will fix Battletoads in Battlemaniacs. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Apr 27, 2006 7:11 am Post subject: | |||||||||||||
|
|
|||||||||||||
Hooray, thank you! :D
I noticed that, just apathy on my part... fixed.
Nice catch. Fixed.
Yes, it is. It was extremely difficult to test, too. $213e is STAT77, which reports the status and version number of the PPU1 chip, $213f is STAT78, which reports the status and version number of the PPU2 chip. I forget how I tested $213e (only that I did), but I remember $213f because it was particularly difficult. Here's what I did: CGRAM entries are 15-bits, when you read the low value, you get all 8 bits, but when you read the high value, you only get the low 7 bits. The top bit is PPU2 open bus. Therefore, what I did was set $2121, then read from $213b, so the next CGRAM read would have the high bit as open bus. I then read from $213f until bit 7 transistioned from 1 to 0 ($213f.d7 is the interlace field bit). I then loaded A with #$ff, and read from $213b. I got the low 7 bits of the palette, and the top bit was clear. I did the reverse, waited for $213f.d7 to transistion from 0->1, set a to #$00, then read from $213b. Yep, now the top bit was set. The CGRAM entry was #$7fff for both tests. It seems easy when you know how to test for it, but it was quite difficult to think that test up :/ Now what I'm curious about is what happens for PPU1/2 writes to $2100-$2133? Do they update the PPU MDRs like CPU writes do?
Whoops, same thing in the CPU core, too. Fixed.
Hahah, how'd that go unnoticed for so long by myself? Fixed. Battletoads sounds great now. The source was getting kind of cramped with all of anomie's old S-DSP code commented out and replaced. Since he hasn't been around for so long, I finally caved and pulled all of the old dummied out code from the core, and cleaned things up while I was at it. Hopefully I didn't mess anything up in the process :) We still have v0.016 as a reference, and I'm going to make a text document for when/if he gets back of all changes we make in the mean time. As always, thanks a million. Your help is absolutely invaluable. Please let me know if there's any way I can return the favor. |
|||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 28, 2006 6:55 am Post subject: | |
|
|
|
| New stuff. Optimized the PPU BG renderer a tad. I literally stared at the ~5 pages of code for over 8 hours and only found three or four spots to optimize. Not much of a speed difference, but eh. Went ahead and enforced render width/height to be no less than 256x224. Now accept 0x0 resolution width/height as "use current screen size", much like how a resolution of 0 results in using the current refresh rate. Removed two profiles to give 8 total profiles. I did this so there is no profile 0-9 / 1-0 confusion (thank you, jackass who invented QWERTY for placing the 0 after the 9, instead of before the 1). Now there are profiles 1-8, and CTRL+[1-8] sets each mode. By suggestion, there's no longer a fullscreen checkbox, nor default windowed/fullscreen mode selections. You now just specify the resolution info for each mode and hit F11 to go fullscreen. When you exit and restart, you always begin in windowed mode with the last used profile. I think I'll make left ctrl+[1-8] set profile [1-8] windowed, and right ctrl+[1-8] set profile [1-8] fullscreen. Sound good? |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Apr 28, 2006 7:16 am Post subject: | |||||||||||
|
|
|||||||||||
For example, I would like to be able to render video at less than native resolution to see what it might theoretically look like to play an emulated SNES game full screen on a Gameboy Advance or Nintendo DS.
If you don't want to write it yourself, I could write some simple documentation for your emulator. Do prefer a specific format? I can do plaintext and html. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Apr 28, 2006 7:26 am Post subject: | |||||||
|
|
|||||||
I don't know. Maybe something to do with the titlebar. I'll see if I can get it working at < 256x224. It stuck at 256x224 even when I tried 64x56, so meh. To emulate the SNES as though it were on a GBA I'd need something like screen border clipping. It'd be good to simulate the ~16 or so pixels on all sides that TVs chop off, so maybe I'll add that in sometime.
Because I like even numbers.
Thanks, but I'll make a readme file shortly. --------------------------- Ok, can anyone with programming experience and familiarity with the concept of cooperative multithreading and coroutines take a look at this? http://byuu.cinnamonpirate.com/temp/state.txt This is a mockup of the state machine wrapper I'm thinking of using for bsnes to remove the current switch/case tables all over the place, and to allow r_cpu->run() to be "reentrant", without requiring true platform-specific reentrant code. It doesn't really simulate coroutines, it instead simulates a stack (which is just a FILO buffer of states), and the thread suspend function really just sets a new state to occur immediately after the return that is added before it. The entirity of the fine details have not been worked out, hence the mockup. I'll probably have to use global/static variables, and something a little different for any for loops. Real subroutine calls should be fine, so long as suspend() isn't called within any actual subroutines. In the actual implementation, I'd either use a precompiler to add some clarity that #define macros simply can't handle (such as generating the case numbers), or use some really evil tricky macros (eg with __LINE__ thrown all around and such) to avoid the use of a precompiler. |
|||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Apr 28, 2006 7:56 am Post subject: | |||
|
|
|||
With v0.016 as it is, I already CAN see what it might look like on a GBA or DS screen. I hadn't really thought D3D capabale of scaling to less than the original resolution, but apparently it can. The scaling would be 240x160 (3:2) for the GBA, and 256x192 (4:3) for the DS. EDIT: I was going to mention, do you think there is any way we can give custom names to the profiles and have them show up in the seleciton menu(s)? Obviously, they could be character-limited. It would really help to remember what each profile was. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Apr 28, 2006 4:54 pm Post subject: | |
|
|
|
| byuu, (or someone with a real ToP cart or a copier) could you confirm if the Tales of Phantasia bug I posted on page29 happens on real hardware? It's about two to three minutes from the beginning. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Apr 29, 2006 1:42 am Post subject: | |
|
|
|
| Yeah, I think byuu only has a super UFO, which is 32mbit IIRC. Someone else will have to test, because it's too slight of an anomaly to assume it's an emulator bug. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Apr 29, 2006 7:50 am Post subject: | |
|
|
|
| i cannot test TOP either, only 32mbit, we would need to find someone with a super wildcard DX2 with the 64 mbit upgrade | |
Hero of Time
Joined: 30 Jul 2004
Posts: 3592
Location: In front of the monitor
| Posted: Sat Apr 29, 2006 8:26 am Post subject: | |
|
|
|
| Grinvader has ToP on the real hardware. Maybe he can confirm the bug. _________________ Try CCleaner  |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Sat Apr 29, 2006 9:56 am Post subject: | |||
|
|
|||
|
Let me hook it up. I didn't notice anything like it, but checking twice is always good. After all I saw that this...  ... was in the real thing after spending several hours in the game (had to grab origin to trigger it... - also I'm not talking about the garbage on the first line, just all the weird 8x8 tiles). Edit: this purplish background seems to be a bug. At least I couldn't make it appear after a dozen battles. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Apr 29, 2006 8:04 pm Post subject: | |
|
|
|
| K, I've added it. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Apr 29, 2006 9:27 pm Post subject: | |
|
|
|
| I
have the actual ToP cartridge. I'll compare the two later on. No idea
what could be causing that, and it would be quite hard to track
something like that down. Jurassic Park 2 is another game that needs to be added. It freezes before the intro starts playing, unless you press start quickly. I don't know if Super Conflict was tested on hardware before or not, but I'm missing the same tile that Overload is (the smaller 's') on the title screen. We also might want to sort the bugs based on their severity, too. Maybe come up with two or three categories for bugs. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Apr 30, 2006 2:41 am Post subject: | |
|
|
|
| Wow, you're right. Didn't notice that small c was screwed up. I've added it for now, since it seems to be a genuine bug (zsnes screws up on the same text, but worse. It chops off the sides.) Added Jurassic Park II also. I do hope more people start reporting bugs for bsnes if they find them. I'm more than happy to maintain an accurate list. As for the severity classifications - I dunno, that might be kind of hard. For example, the Jurassic II bug is a show-stopper, but it can be easily prevented and doesn't affect gameplay. Kind of subjective to determine the severity. | |
New Member
Joined: 30 Apr 2006
Posts: 2
| Posted: Sun Apr 30, 2006 7:39 am Post subject: Some Bugs | |
|
|
|
| Here are some bugs I have come across thus far (using bsnes 0.016): All names are taken from GoodSNES. Games that have a black sreen at startup and go no further: Asahi Shinbun Rensai - Katou Ichi-Ni-San Shougi - Shingiryuu (J) Chou Aniki - Bakuretsu Rantouden (J) Derby Stallion 96 (J) Destructive (J) Final Stretch (J) [!] Gamars Puzzle (Unl) Habu Meijin no Omoshiro Shougi (J) [!] Hashiriya Tamashii - Rider's Spirits (J) Hayashi Kaihou Kudan no Igo Oodou (J) Killer Instinct (Beta 8MB) Killer Instinct (Beta) Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J) Other Bugs: Ballz 3D (U) [!] - When gets to PF Magic Screen at start up stops with different colored lines flickering on screen. Battle Racers (J) - Black Screen after initial Banpresto screen. Goes no further. Corn Buster (E) - When you first start the game and are on map screen, as soon as you move it freezes. Death Brade (J) - When you start a fight it says time over straight away and you lose. Does not happen in ZSNES V1.41. Hope this helps. I'll report more as I find them. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Apr 30, 2006 9:15 am Post subject: Re: Some Bugs | |||
|
|
|||
Thanks, but maybe I should have been more specific. If you guys want to report bugs, please use NSRT for its more accurate names and database and make sure that under "type" the game does not utilize a special chip. You'll see that most of these games are not bugs, but unsupported hardware. Asahi Shinbun Rensai - Katou Ichi-Ni-San Shougi - Shingiryuu (J) - SA-1 Chou Aniki - Bakuretsu Rantouden (J) - confirmed Derby Stallion 96 (J) - confirmed Destructive (J) - works for me Final Stretch (J) - DSP-1 Gamars Puzzle (Unl) - no idea what this is Habu Meijin no Omoshiro Shougi (J) - SA-1 Hashiriya Tamashii - Rider's Spirits (J) - DSP-1 Hayashi Kaihou Kudan no Igo Oodou (J) - SA-1 Killer Instinct (Beta 8MB) - not in NSRT Killer Instinct (Beta) - confirmed Super Robot Taisen Gaiden - Masou Kishin - The Lord of Elemental (J) - SA-1 Ballz 3D (U) - DSP-1 Battle Racers (J) - DSP-1 Corn Buster (E) - confirmed Death Brade (J) - already in the list on page 1 of this thread |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Apr 30, 2006 9:21 am Post subject: Re: Some Bugs | |||
|
|
|||
It's an underdump, it shouldn't work. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Apr 30, 2006 9:22 am Post subject: | |
|
|
|
| KI beta 8mb is a useless underdump that only someone as special as Cowering would index. Hey, gotta collect 'em all, right? Derby Stallion '96 is one of those fun carts with the BS-X flashcart ports on top of the cartridge. It probably fails due to the generic memory mapper I use, but I could be wrong. Thanks for the other reports. I'll try and make v0.017 and above give error messages when unsupported special chip games are loaded. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon May 01, 2006 5:46 am Post subject: | |||||
|
|
|||||
Wierd. So I should remove it?
A splendid idea. |
|||||
New Member
Joined: 30 Apr 2006
Posts: 2
| Posted: Mon May 01, 2006 12:10 pm Post subject: | |
|
|
|
| Using Bsnes V0.016 with no graphical filters applied. Small graphical bug in Bugs Bunny - Rabit Rampage (E) (Also appears in (J)) On the first level on the first screen there are several white tiles that seem to be out of place, hard to miss (I tried to capture screenshots but it wouldn't work for some reason ).Does not show up in Zsnesw141. File: Bugs Bunny - Rabbit Rampage (E).smc Header: No BUGS BUNNY TYPE:NORMAL INTERLEAVED:No BANK:Lo CHKSUM:OK VIDEO:PAL CRC32:91B3DB54 |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon May 01, 2006 12:42 pm Post subject: | |
|
|
|
| version 16 is coming along awesomely! My only dilemma is with the d3d mode fullscreen. If I select triple buffer, I get smooth scrolling but the sound goes crackling every few secs. If I turn it off to fix the sound, then the scrolling looks bad. If there was some way to get both at the same time, that would kick some serious ass! | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon May 01, 2006 12:54 pm Post subject: | |
|
|
|
| Triple buffering is bugged right now, as noted right next to the checkbox for it. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon May 01, 2006 12:57 pm Post subject: | |
|
|
|
| Yes I know, but its still my dilemma. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon May 01, 2006 3:03 pm Post subject: | |||||
|
|
|||||
Nah, it should probably still work anyway; and it is technically "broken".
I completely agree. Perfect audio and smooth scrolling would be awesome. However, I don't know how to fix it. I've spent hours trying to. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue May 02, 2006 4:56 am Post subject: | |||
|
|
|||
Confirmed and added. Also reminded me about another NSRT naming problem. Some games include the subtitles, some don't, even though Nach is against them. Many have forced him to make exceptions to what is already a flawed rule, but he hasn't fully given in. Example: Legend of Zelda, The - A Link to the Past, when shortened, then would have shared the same name as one of its prequels. Basically the equivalent of calling "The Godfather, Part 3" "The Godfather." So yeah, the exceptions fix that, but they 1. prevent a standard 2. mean extra work for rom researchers who have to then find out if prequels/sequels existed for every other system. So here comes this game which is named "Bugs Bunny" in NSRT. Let's say this "no-subtitles" standard spanned every system, as it would if NSRT grew. Now let's take the following roms: Bugs Bunny - Double Trouble (genesis) and Bugs Bunny - Rabbit Rampage (snes). Under NSRT, they would both be named "Bugs Bunny." You would then think they're the same game, but they aren't ... at all. Then if you zipped them up, you wouldn't be able to have them in the same folder without renaming them manually... and they're different games on different systems! So, what are the negatives to having subtitles, you might ask? Well... they... uhhh.... make the filename longer.
|
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue May 02, 2006 5:07 am Post subject: | |
|
|
|
| Whatever
the reasons for omitting subtitles, I think it is more important to
give each ROM a sufficiently unique name, which in some cases is
obviously impossible without subtitles. But let's not get off-topic here. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue May 02, 2006 5:28 am Post subject: | |
|
|
|
| Yeah, I should take it to nsrt forums actually. Kind of got on a spiel, as usual. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 02, 2006 8:02 am Post subject: | |
|
|
|
| Merry Christmas. 99% of this code comes from Overload's website. Thank you, Overload! Adding the last opcode, op06, will fix sprite placement and mostly finish the job. It's just a pain the ass thanks to the SNES9x code mess. Not that I'm not grateful for their source to use as a reference, of course... Ah well, hopefully I can figure out the DSP-1 command interface a little better, and release a much cleaner (complete) source implementation for DSP-1 emulation, and actually use ::gasp:: comments while I'm at it! |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue May 02, 2006 9:17 am Post subject: | |
|
|
|
| Wow! Thanks byuu! I can't wait for the next release, as always. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue May 02, 2006 10:22 am Post subject: | |
|
|
|
| A surprise! Thank you thank you! SMK and Pilotwings rock. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue May 02, 2006 2:24 pm Post subject: | |
|
|
|
| Goodness. Thanks indeed to byuu and Overload. It's nice to see an implementation of an add-on chip that doesn't just try to be playable but accurate too. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue May 02, 2006 7:49 pm Post subject: | |||||
|
|
|||||
SNES9x' implementation may not be perfect, but I wouldn't go that far. _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Tue May 02, 2006 8:55 pm Post subject: | |||
|
|
|||
Obviously you have no idea what you are talking about. Everyone is using the same DSP-1 source at this point. |
|||
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Tue May 02, 2006 9:59 pm Post subject: | |
|
|
|
| Delicious. Thx Byuu & Overload. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue May 02, 2006 10:28 pm Post subject: | |||||
|
|
|||||
Ok ok,I take back what I said. But some add-on chips implementations (in Zsnes or 9x) like the SuperFX and SA1 are indeed very inaccurate and not very complete, are they not? Last edited by Dmog on Tue May 02, 2006 10:30 pm; edited 1 time in total |
|||||
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Tue May 02, 2006 10:29 pm Post subject: | |||
|
|
|||
How far has the emulation progressed at this point, accuracy-wise? |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue May 02, 2006 10:47 pm Post subject: | |||||||||
|
|
|||||||||
I have no idea on what the status for SuperFX (probably the second version of the chip is still yet to be emulated fully). However... the discussion on SA-1 was already made. http://board.zsnes.com/phpBB2/viewtopic.php?t=6919&highlight=
So.. adding this to BSNES would have a performance problems far greater than can be currently imagined. The requirement is slightly exaggerated for ZSNES, but it can give you a decent idea of what would be needed if you did accurate SA-1 emulation+filters. _________________ FF4 research never ends for me. |
|||||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue May 02, 2006 11:13 pm Post subject: | |||||||||||||
|
|
|||||||||||||
Good stuff! (and yes, I read the high requirments correctly)
At that level, I think the filters wouldn't make a difference honestly. I wouldn't mind having SA-1 in bsnes actually, even if it would require a 20GHZ computer or something. But of course, it all depends if you want to have constant performance in bsnes with all games or not. So I would understand if byuu don't want to add it for now. |
|||||||||||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed May 03, 2006 1:25 am Post subject: | |||||
|
|
|||||
You haven't really used any of the HQx modes to know how CPU demanding they are.
For the record.. SA-1 research is still not complete. What is currently implemented is pagefault's build is only the SA-1 knowledge that is KNOWN by all SNES devs/documentation at this time. Whatever is not known is not emulated yet. So... it won't happen anytime soon unfortunately. _________________ FF4 research never ends for me. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 03, 2006 1:37 am Post subject: | |||||
|
|
|||||
Seriously? Look at SNES9x' DSP-1 code sometime. Their status register emulation consists of always returning "ready" (0x80), and nothing more. It ignores all known information (bit 2 is the transfer size indicator, for example). Not emulated since the known DSP-1 games don't rely on it. Look at their chip interface. It uses buffers that the real chip doesn't have and has hacks all over for ops 06, 1f, and especially 0a. None of which are documented to explain what the hell is going on. I think I can do a better job, but we'll see. The actual ops, yeah. We're all using the same code there. One single op away from being totally bit perfect. Why we're using true floating point for it when we know the chip isn't that accurate, however, is beyond me. At least it isn't as bad as the 50/50 split of integer vs fp for the C4 opcodes.
I don't want to say I'm not emulating that chip (because you never know), but... I'm not emulating that chip. Anyone else is free to, but if I have to add hacks all over the place to support it, then I won't bother. There's far too much left with the main system itself to worry about an obscenely complex chip that has maybe four good games that use it. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed May 03, 2006 8:37 am Post subject: | |
|
|
|
| I
just received my Super Smary Joy in the mail today (usb adapter for
snes pad). I thought I'd wait until I got it before making the
following suggestion. On the subject of presets this week, I thought
you might be interested in setting the preset for bsnes' joypad buttons
to the actual snes controller. Here's what I got after assignment. It's different than what the default is now (don't know what you used for reference): Up > up Down > down Left > left Right > right Y > button3 X > button0 B > button2 A > button1 L > button6 R > button7 Select > button4 Start > button5 I might be assuming that a parallel adapter would map the same way, so if someone with one of those would confirm sameness, I'd appreciate it. |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Wed May 03, 2006 8:51 am Post subject: | |||||
|
|
|||||
I have 2 kinds of 10-buttons gamepads and they map out as: - 4 faces, 4 shoulders, 2 extras up/down/left/right Y = 2 X = 3 B = 0 A = 1 L = 4 R = 5 Select = 8 Start = 9 - 6 faces, 2 shoulders, 2 extras up/down/left/right Y = 3 X = 4 B = 0 A = 1 L = 6 R = 7 Select = 8 Start = 9 The fact some pads have 'B' (the lowest-leftmost button) as anything but 0 - like yours - proves it's useless to make any preset follow any kind of logic. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed May 03, 2006 9:14 am Post subject: | |
|
|
|
| I
knew that every controller would map differently, but I just thought,
if you're going to have a preset, it may as well be the real deal, yes?
Still, all for naught if the parallel adapter maps differently. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 04, 2006 9:26 am Post subject: | |
|
|
|
| Can any x86 assembler programmers take a look at my post here? http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=73286&page=0&view=expanded&sb=5&o=&fpart=1&vc=1 If I get help with this, I can potentially greatly increase the code readibility, speed, and accuracy of bsnes. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun May 07, 2006 9:13 am Post subject: | |||||
|
|
|||||
|
Ok, I've solved this problem. Aaron Giles was very helpful. http://byuu.cinnamonpirate.com/temp/libco_v03.zip Now, time for another poll. This time, it's really important. I've managed to implement cooperative multithreading in c++ that is only 6x slower than a standard function call. However, I will no longer need a state machine (or multiple nested state machines like bsnes uses now) to resume where I left off from a given function call, or to return in the middle of a function call. What this means is that I can implement an opcode like this :
Instead of like this :
The difference? A significant speed improvement, a step closer to dual/quad core CPU support (preemptive multitasking), much cleaner code, and more accurate than bsnes v0.016. These are the goals of bsnes. And now, the problem. Save states. I can't save the execution context of each cooperative thread and restore it on the fly in a platform-independant way (or worst case, even per-execution-run). So... I either give up savestates (or possibly have really hackish savestates that only work on one computer, or one OS), or I give up huge benefits to coding clarity, speed, and accuracy... But there's more to it than just save states, bsnes will never catch on mainstream without savestates. Which could affect code contributions in the future, etc. Geez, such a tough decision :( --------- Hmm, epiphany! What if I were split this up? Keep one core that has savestates and is semi-accurate, and one core that does not have save states, and is dead-on accurate? More work for me, but it's the only way everyone will be happy :/ Perhaps with some tricky defines I could make opcode vs bus synchronizations an option? I'd basically be turning bsnes into two SNES emulators, though. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun May 07, 2006 11:29 am Post subject: | |
|
|
|
| Wow, you're not kidding. That's tough. I know I've already expressed my feelings about savestates. A lot of people like them and can't live without them. I try not to use them unless I have to. It's a nice feature to have, but from the impressive list of benefits you claim to gain from libco, it would be ridiculous to choose savestates over that. The question is whether or not you should maintain two cores. That's a last resort option in my mind. You work hard enough, I can't see any user in his right mind asking you to upkeep two versions for the sake of savestates. I see one sensible suggestion: go for the multi-threading and think about adding savestates as an afterthought. If you can one day hack them in for windows users only as you say, that would probably be sufficient to get the larger audience you seek. Big deal if they're not perfect. I like the sound of those improvements and you working less. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun May 07, 2006 11:42 am Post subject: | |||
|
|
|||
|
Could
you save the state only at those points in time where all the
subthreads are at the same "position"? Sorry if this is a stupid
question. Anyway, I'd say "hackish" savestates are still better than no savestates at all. Like FitzRoy said, two cores seems like too much work just for that feature. _________________ savestate editor: vSNES latest public version
|
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun May 07, 2006 2:02 pm Post subject: | |
|
|
|
| Goob job on the recent progress, w00t. Personally, I don't use save states,even when they're supported. But I know a few users can't live ("Can't LIIIIIIIIIIIIIIIIIIIVE!!!!!") ahem.. without them. They're a good way to quickly test bugs though. So yeah,I'd say go for libco support. |
|
Hazed
Joined: 29 Jul 2004
Posts: 86
Location: USA
| Posted: Sun May 07, 2006 5:34 pm Post subject: | |
|
|
|
| Like the other people have said, the list of benefits of libco sounds impressive enough that if it means no savestates, so be it. | |
Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
| Posted: Sun May 07, 2006 6:46 pm Post subject: | |||
|
|
|||
Same here. _________________ Zsnes WIP Bsnes by Byuu Kega Fusion by SteveSnake Vice by Viceteam |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sun May 07, 2006 7:16 pm Post subject: | |
|
|
|
| Your
goals include accurate SNES emulation. Save states weren't a feature of
the original SNES, and they seem to be somewhat "hackish" in all SNES
emulators. Screw em'. Maybe you can figure out a way to do them later. Maybe you can wean people of save states. Don't do two cores either. "Save states are for pussies." I do realize, however, that the speed-run communities won't be able to use your emulator very well. But maybe those guys can come up with a crazy way of implementing save states that would work for them. Maybe Nach can figure something out. Anyway, no need to give up one of your stated goals just for save states. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun May 07, 2006 8:02 pm Post subject: | |||||
|
|
|||||
It's not just them, save states are good for bug reports too. And Bisqwit's community needs save states which can be saved every frame.
This is a very tricky subject. First glance says no way no how. However more thought tells me we might be able to be tricky using normal relocation ideas coupled with tracking all allocated stacks to give frame accurate save states. However these save states would be per platform, and save state capable builds will probably be slower. Overall the whole thing will be quite annoying, and it'll be hard to say until I see the final product and study it. And getting it to work across platforms seems quite difficult, unless we come up with some sort of stack description format which is cross platform, but that's much easier said than done. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Mon May 08, 2006 12:46 pm Post subject: | |
|
|
|
| Here's the irony many of you don't see with savestates: The most accurate SNES emulator we have available is less than useful for any actual reverse engineering of existing games or or new homebrew code because of not having not save states. If you can't get to it in the first few seconds of gameplay or immediate after a natural savepoint, you can't test or look at that portion of code without painstaking annoyances of playing to that point EVERYTIME which could be 2 minutes, or an hour. Certainly not practical in any case. It just seems like a travesty to have an active, accurate, SNES emulator but have it be useless for many tasks that would be much better off with a more accurate emulator. Of course, none of this even matters right now since the current version of BSNES has no debugger either anymore. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Tue May 09, 2006 1:13 am Post subject: | |
|
|
|
| Time permitting, try making two versions. One optimised code without save states, and the other a feature-flush version with save states. One can be used to bug-shoot, while the other would be an accurate alternative. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 10, 2006 5:45 pm Post subject: | |||||||
|
|
|||||||
|
So ideas I have now... 1) Opcode-based cores that support savestates and bus-accurate cores that don't. Possibly use tricky #defines to turn this into a compile-time option. 2) Elaborate #define system to obfuscate the state machine needed for bus-accuracy + savestates, take the 2-3x speedhit and be unusable on any PC. 3) Give up on any semblance of code readability and come up with some sort of complex timestamping system. 4) Master-slave implementation that will ruin debugging capabilities for everything but the main CPU. What you need to realize is that the original SNES hardware had separate ICs for each component of the system. The S-CPU, the S-PPU, the S-SMP, and the S-DSP. With c++ and no threading, this all gets bunched together, along with a new GUI component. It's simply not possible to cleanly design around the reentrancy problems of c++ without taking either a massive speed hit for using a sloppy state machine, or using multithreading which eliminates save states. It only makes sense from an emulation perspective to simulate the original hardware by breaking each component into its' own unique context (lightweight-process). Of course, we have to simulate parallelism that truly is impossible on modern hardware by running to bus accesses and synchronizing, however this isn't very difficult and results in no accuracy loss, other than emulating bus conflicts.
Agreed. Changing anything in the program code will result in addresses moving all around. So even a tiny code modification would break context save states.
Pretty much. It's most(ly) useful for emulating the original hardware, and not much else.
Yep, hence why I can't fix many of the bug reports. Believe me, I'd love to get the debugger up and running again, but at this point I don't even know what to do with the CPU and APU cores that are absolutely pivotal to the debugging interface. |
|||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed May 10, 2006 6:42 pm Post subject: | |||
|
|
|||
Can you elaborate on this option? I don't pretend to know much about save states, but just for the sake of argument, how might someone, hypothetically, make a save state on a real SNES? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Regular
Joined: 09 Aug 2004
Posts: 221
Location: Confirmed
| Posted: Wed May 10, 2006 7:15 pm Post subject: | |||
|
|
|||
there is a device called a "game saver" (By Nakitek) which came out for the SNES that allows you to "freeze/save" a moment and then load it up later. Similiar devices has been sold for the Gameboys too, guess Genesis/MegaDrive got one too. _________________ ~empty zig space for rent~ |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed May 10, 2006 7:29 pm Post subject: | |||||
|
|
|||||
By using a device that dumps the content of the RAM chips into its own ones, and saves the status of the other components. I don't know how that could work though... some of that info is very difficult to get and set. EDIT: Apparently there's also this device: link _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Thu May 11, 2006 6:33 am; edited 1 time in total |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed May 10, 2006 10:37 pm Post subject: | |
|
|
|
| As
far as the potential for perfect game accuracy goes, you are on the
correct core right now. I remember the last time you wanted opcode, you
were considering compromising that feat for a speed increase. This
time, it's savestates. Savestates has more of an argument for that this
time, but it still falls short to me. The stuff Nightcrawler mentioned
is all good and dandy, but you have to remember that zsnes is
constantly improving as well, and would likely satisfy any
developmental savestate needs as an opcode core. As for bug report
easiness? bsnes has a shortlist. Big deal if a few games have to be
played into a bit from the srm to see the bug. You saw the post by the guy in zsnestalk who cast aside bsnes because of its lack of savestates. For every one of those guys, there is a guy who feels the opposite. You question whether or not bsnes will become mainstream, but if you look at the numbers it already has. On AEP-EMU, bsnes has 8000 downloads to zsnes' 20000 and snes9x' 18000. People might not be registering left and right to express their support or satisfaction, but there are a lot of people using your emulator as well. That's just how most people are. Silently appreciative. Heck, if you think about how many regular posters this board has, it's probably around 150. People only bother to register to get help, report a bug or ask for something. You don't see many "thank you thank you thank you" posts anymore, but that doesn't mean shitloads of people don't love zsnes. So to summarize, I think you're on the right course to achieving both a super accurate emulator and a large userbase. It might not seem blatantly obvious, but it's true. So savestates = meh. Carry on with your work, loads of people have been and will still use bsnes without them, and even more people with the speed and accuracy improvments from libco. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 11, 2006 12:45 am Post subject: | |||
|
|
|||
Hmm? The current core is cycle-accurate, but fakes bus-accuracy by incrementing the H/V counters and triggering NMI/IRQs correctly, but not synchronizing the APU (meaning there's an infinitesimal desync between CPU<>APU communications). The new core using libco would be truly bus-accurate. At present, I'm thinking this weekend I'll port the APU core (since it's just an opcode emulator with no interrupts or DMA to worry about) to use libco, and post a version for people to compare, or something. Then we can worry about coming up with macro and preprocessing tricks for a /much/ slower (or slightly less accurate) savestate-enabled version. Preferrably in a way that I don't have to maintain >1 CPU+APU core. |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu May 11, 2006 1:29 am Post subject: | |||||
|
|
|||||
(taken from another thread)
herzog is right on target,byuu. Obviously you can't please everyone and some folks only knows how to demand and complain...that's part of the emulation scene unfortunately. Heck, the great and venerable MAME has seen countless of "OMG teh mAMe s0cks, m8ke it faster,I want KaillERA sppoRT!! Give me teh r0mz!! Yo MAME iz s0 fat!!" . "Lamerz" come and goes but MAME stayed. And speaking of MAME,I believe there are plenty of MAME drivers that do not support savestates. Anyway, if you allready decided what to do next then simply ignore this, but I agree with Fitzroy and others that savestates is not that big of a deal for now. Basically, it's very possible that there are 'more' people that do not care about savestates. But naturally,only those who care about it will manifest themselves, which can give a false representation...Fitzroy is right when he says:
The complain(ers) tend to be louder,unfortunately. |
|||||
Regular
Joined: 25 Jan 2006
Posts: 297
| Posted: Thu May 11, 2006 6:29 am Post subject: | |
|
|
|
| only noisy people make noise, while the content remain quiet. ..except when they make pseudophilosophical sounding posts like this anyway, i'd say go for pure accuracy. there's enough of a following that for any bug that has noise made about it, at least *someone* will probably break their neck looking to prove it. if not, so what? it is YOUR emulator, byuu, not bsnes9x or bzsnes or bSNEeSe etc. there will always be another emulator to fill any shortcomings (perceived or otherwise) in bsnes, just as there is snes9x and bsnes and SNEeSe which fill each other's shortcomings now. and as for any potential "massive performance hits"... i remember back in '98 or so when snes9x was around .20 and zsnes had just started, and someone threw out that "there's no way a snes can be emulated on anything less than a 2GHz cpu"... well, you know what? worst case, in a few years, that hardware limit will be passed. and more than likely, other architectural improvements will make that limit lower than expected. do it whatever way you see fit, as long as you're satisfied. satisfaction with your emulator is what will keep you working on it, the same satisfaction that i presume keeps nach, pagefault, anomie, kode54, fx3, steve snake etc working on theirs! |
|
Inmate
Joined: 26 Sep 2004
Posts: 1637
Location: Place.
| Posted: Thu May 11, 2006 7:37 am Post subject: | |
|
|
|
| For
me, when I first got into emulation, savestates were a fun new way to
play with the games I'd finished a long time ago. But now, they're in
no way essential to me, really. In fact, they make some games a lot
more boring, IMO. If a perfectly accurate SNES emulator came out today
without savestates, rewind, speedup or slowdown, it would be my first
choice (provided it would run full speed on my PC, which is really the
only reason I don't use Bsnes as much). Oh, and perfectly accurate TV output would be nice too, but I guess that's just a pipe dream. :p _________________ Procrastination. Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu May 11, 2006 8:25 am Post subject: | |||||||
|
|
|||||||
Sorry, I forgot that you simulated subcycle in that regard. All I had on my mind when saying that was "moving to opcode would be less accurate, which is not a good tradeoff." So what kind of core will bsnes be when libco is used?
Cool, looking forward to it. |
|||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu May 11, 2006 9:05 am Post subject: | |||
|
|
|||
I don't think those are dependent on save sates. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 11, 2006 9:13 am Post subject: | |||
|
|
|||
The code will be identical to an opcode-based core, with the exception of 2-4 cleverly placed yield() commands that will freeze the CPU context during bus accesses. But the difference will be that the main CPU run routine is a neverending loop. So before one would have: cpu_run() { execute_opcode(); return; } And now it will look like: cpu_run() { for(;;) { execute_opcode(); yield(); } } Now that I think about it, in that regard, an opcode-based CPU core and bus-accurate core can use identical code. The differences will all be above the actual opcode implementations, eg I'd need different DMA/IRQ/NMI handlers, and not much else. Coolness. And then I'll be able to stick the CPU core into a potential SA-1 emulator, should hell freeze over and I decide to work on that in the future. Thanks for all the positive feedback. I believe I will go with my cooperative multithreading library after all :) I made a more intensive test today that verified local function variables, nested for loops, etc all work fine with the library. I also cleaned it up a tad more, which should make Linux compilation easier. My benchmarks indicate the context switching is 6x as intensive as a function call on an Athlon, and 10-12x as intensive on a P4 (which is because P4's have way more pipelines that get thrased when you switch contexts). Let's all pray that this doesn't turn out to slow things to a crawl when I actually do add it into the emulator, like my switch/case define trick did. |
|||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Thu May 11, 2006 11:54 am Post subject: | |
|
|
|
| Re savestates: Use a text-based format [a la PSR] and bzip2-compress it. ZSNES will be moving to PSR-based savestates eventually, anyway, so... :p | |
Inmate
Joined: 26 Sep 2004
Posts: 1637
Location: Place.
| Posted: Thu May 11, 2006 1:13 pm Post subject: | |||||
|
|
|||||
I know. Just listing things I don't really care for in an emulator. ;) _________________ Procrastination. Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu May 11, 2006 4:36 pm Post subject: | |||
|
|
|||
What does this mean? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 11, 2006 5:12 pm Post subject: | |||||||||
|
|
|||||||||
It means that :
is 6-12x times faster than :
depending on what type of processor you have. Athlons are twice as efficient because they aren't pipelined to all hell with 20x multipliers like P4 chips. However, you make up for a good deal of that by avoiding the switch/case tables to get from the beginning of cpu_run() to the small part of the code you need to execute (eg a cycle of an opcode). So,
becomes :
However, we'll see how fast/slow it ends up this weekend, I suppose. It should be way faster, and it will be much cleaner code-wise. And yet, I wouldn't be surprised if things ended up as slow / slower with this approach, as that's just my luck. |
|||||||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu May 11, 2006 8:40 pm Post subject: | |||
|
|
|||
byuu, just so I get things right: basically bsnes won't be cycle-based (or even subcycle or clockcycle based) anymore, correct? And yet it will remain as accurate (if not more) as it is today while (theorically) gaining a big performance boost? :shock: Basically,what I'm asking is: the emulation method you're gonna use does not really figure within the ones you mentionned here,right? http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods Again, if I get things right, it will be functionally similar to an opcode based method,but without the tradional limitations and innacuracies that normally goes with it? |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 11, 2006 9:15 pm Post subject: | |
|
|
|
| Well,
basically I had to differentiate between opcode/cycle/subcycle accuracy
before, because I had to break the CPU down to parts small enough that
could be returned after each part. But now, thanks to cooperative multithreading, I can return right in the middle of the CPU core, so there's no reason to break anything down. The code will look just like an opcode-based core, but with yield() stuck in there in 2-4 places. I'll even get to pull off syncs between each HDMA write now, something v0.016 can't quite do. Should help even more with games like EWJ2 that use HDMA<>SPC700 spooling. So then, if you enable cothreading, you lose savestates and get even more accuracy than bsnes currently has. If you disable cothreading, then you get massive speed gains over v0.016 (easily 30+%), (eventually) savestates, and only a moderate hit to overall accuracy (it would be on par with SNES9x then, basically). |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri May 12, 2006 5:01 am Post subject: | |
|
|
|
| Wow, cothread will be uber awesome if there's no speed hit over .016. If there is, it will just be awesome |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Fri May 12, 2006 8:08 am Post subject: | |
|
|
|
| Getting back to the triple buffer/ choppy sound issue, I noticed that the megadrive emulator "Gens" gets around this by occasionally skipping a frame to keep the action synced to the sound properly. If I turn the auto-framw adjust feature off, Gens sound also will intermittently become choppy. So while the scrolling is liquid-smooth most of the time, it will skip a frame only when needed to stay in sync with sound. Might want to see if this is a viable option for bsnes too. | |
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri May 12, 2006 2:48 pm Post subject: | |||
|
|
|||
Agree. Seems to me Snes9x-level accuracy would be like a big step backward for bsnes in term of accracy...(not to bash on 9x or anything) |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri May 12, 2006 4:17 pm Post subject: | |||||
|
|
|||||
It's only a step backward if it were the only option. With the presence of opcode+cothread, it's apparently more accurate than cycle based. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 12, 2006 4:20 pm Post subject: | |||||
|
|
|||||
I agree. The thing is, the difference between an opcode-core and a bus-accurate core is a #ifdef around all 2-4 calls to co_return(). The CPU might be a little trickier than the APU, but still very little actual work. So I'll make it a compile-time option, and with that I can release two separate versions. One for low-end machines, say 800-1600mhz or so, not sure yet. And the more accurate one for high-end machines. I figure it's better to have something playable, rather than nothing at all. And it will be a requirement for the G5 version of Mac OS X, unless someone kind can port libco to the G5 architecture.
My code is supposed to do exactly that. But for some reason, the Flip() command is forcibly waiting for the next vsync anyway. Ideally, this function would accept the two writes in one frame that happen once every 10 seconds and end up discarding one of the frames. But I guess that would mean writes could update the pointer mid-frame and cause tearing... well, that gives me an idea, at least. I'll create a function wrapper for Flip() and set a high performance timer to copy it over sometime near the end of vblank each frame. |
|||||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Fri May 12, 2006 5:24 pm Post subject: | |
|
|
|
| Would
it really need ifdefs? An "if(bus_accurate) co_return();" would add
just a few processor cycles* of overhead versus ifdef, and doing so
would allow you to change at run-time, which could allow you to have
per-game settings very easily. * OK, back of the envelope, on a cold cache you're probably looking at ~80cycles for the memory load, 2 cycles for the test/branch, and a max of 20 cycles for backing out the pipeline because of a branch misprediction, 100 cycles. But in the bus_accurate == true case, the overhead is negligible compared to a context switch anyway, and in the bus_accurate == false case, if you give the compiler a hint that it's likely to be false, then you cut the branch misprediction overhead, and you're down to basically just the load time for bus_accurate. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri May 12, 2006 7:11 pm Post subject: | |||||||||
|
|
|||||||||
Yes,that's what I meant. If making two separate builds is only a matter of changing a few lines of code before compile then I'm all for it.
That's what I understood. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 12, 2006 7:19 pm Post subject: | |||||
|
|
|||||
It would work there, but I would have to redo the core, at least for the CPU, probably not for the APU. With the CPU, hmmm... I might be able to work something else out. Essentially, an opcode-based core will need to have DMA implemented so that it can return after each byte transfer, whereas the bus-accurate one with cothreading will not need to do this. And I don't intend to do it either, as it will make the code more readable. And there's all the magical fun of DMA synchronization timing... I don't intend on adding that in the opcode core since nothing relies on it, and that core won't be cycle accurate anyway, so why bother? So... the main SNES timing routine will call r_cpu->run every time it needs to have the CPU catch up to the APU. If I add a check for "bus_accurate" there, or whatever, the overhead could be quite severe. I know I took a ~5fps frame hit simply for adding an add+bitmask in the add_cycles function, and a ~3-5fps speed hit for a boolean if(cheat.enabled) inside the memory bus *read* (not write) function... I'd take a speed hit of ~1-3 million boolean comparisons per second by adding if(bus_accurate)co_return() into op_read/op_write, as well. I could always just enable polymorphism for r_cpu if I wanted a build that could swap between the two on-the-fly. That takes a performance hit of ~10%, though.
Yep, my explanantions must be lousy, but let me try again... because the CPU is running in a separate thread, I can stop right in the middle of a function, whenever I want, wherever I want, and go to another core to synchronize back up. So I essentialy now have infinite precision, but the code is written just like an opcode based core. Without the cothreading, I would have no choice but to split the core up by breaking the opcode apart into 6-8 subopcodes, or "cycles". For bus accuracy, I would have to split each one of those in half. That would be so that I could return from the CPU core and run the APU/PPU/DSP/etc to catch those up when necessary. Does that explain things better? GRAH, I can't wait to get off of work today so I can start on this already >:D |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri May 12, 2006 7:36 pm Post subject: | |||||||||
|
|
|||||||||
Yes, I got the gist of it thanks. edit: Although, I think for most non programmers, it will remains a bit theoretical (even though they can understand the general idea without too much problems) edit: Obviously meant: "For most NON-programmers" of course
|
|||||||||
A. Lagopus
Joined: 16 Aug 2004
Posts: 702
| Posted: Sat May 13, 2006 8:16 am Post subject: | |
|
|
|
| Regarding savestates: Why not use PSR for it? That way, changing stuff won't break the format. | |
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Sat May 13, 2006 8:59 am Post subject: | |||
|
|
|||
|
This context-switching sync method will probably require more than simply 'PSR'. PSR is great to work on set variables, but doesn't do anything about stacks. To restore everything, a save state should hold all the context stacks, along with something telling which thread was active when the state was saved. Tricky. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||
Lurker
Joined: 04 Sep 2004
Posts: 193
Location: USA
| Posted: Sat May 13, 2006 7:36 pm Post subject: | |
|
|
|
| Quick
question: How do you suggest resolving the issue where there is a
slight tearing/desync of bsnes' image between the two triangles created
by D3D? See this screenshot (link).
I had to take the picture using a digital camera since I found it
essentially impossible to capture the proper frame using the Print
Screen key. The camera used a shutter speed of 1/10 or 1/13 (can't
remember which). The ROM in the photo is Memblers' NSF player for SNES
with the 32Mbit library patch, after pressing Start to select one of
the built-in NSFs. _________________ This signature intentionally contains no text other than this sentence. |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Sat May 13, 2006 8:03 pm Post subject: | |
|
|
|
| tripods for the win. could you also provide proof this affects things outside of that NSF player? _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon May 15, 2006 8:22 am Post subject: | |
|
|
|
| Ok, didn't get much time this weekend to work on anything, sadly. Me and my roommate "came across" a nice 36" television for only free ninety-nine this weekend, so obviously we had a lot of cabling to buy and movie watching to do :) While small to most I'm sure, the thing is absolutely massive compared to any TV I've ever owned. Anyway, I really wanted to try out libco this weekend, so I managed to rewrite the APU core in less than three hours, whee. Sadly, performance went from ~80-82fps to ~75-77fps. Now, there's still plenty I can optimize. I can reduce the number of synchronizations when accessing certain areas of RAM easily enough, for example. I should also be able to eliminate the virtual derived class function calls to r_apu->run() all the time now. It will only need to be called once since when I switch contexts the class instance handle is still on the stack anyway. But I need to think about it for a few days to come up with a clean way of doing it, that will still allow the old method to work. I suspect I can probably match the old framerate, but not exceed it by much. The benefit, however, is that the APU core is now much cleaner. I really like it. And I can make those quick checks to swap between an opcode-core and bus-accurate core. So, everything worked out exactly as I had planned, excepting that the speed benefit didn't work out like I wanted. One interesting side note is that I get the same 80-82fps with a purely opcode-based core. Not too surprising, really. The APU was never really that processor-intensive to begin with. And actually, now that I'm thinking about it... I had to add a new function call (op_io) to each APU cycle that didn't have a read/write operation, which is probably where the speed loss came in. I also moved from 256 functions inside a jump table to a switch/case for the opcode table (eh, it's easier, code size is smaller, and compile time is faster, so why not take a small speed hit?). Not much I can do about the call to op_io... since I no longer split each cycle apart, I have no other way to count I/O cycles. I'll also split up the read/write cycles to simulate bus hold times here soon. That will affect speed by a little, but not much. So, too early to say. Still need to implement the CPU core, but that's going to be a several week project since it's far more complicated with its interrupts, H/DMA, etc than the APU core was. And I'm less hopeful that a quick hack will allow opcode<>bus accuracy swapping. However, the 256 opcodes should be compatible between the two, at least. |
|
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Mon May 15, 2006 7:21 pm Post subject: | |
|
|
|
| I have some info about Captain America. The graphics should be fixed by returning 0x00 or 0x80 in some invalid memory areas on read. I think it needs to be done in banks 00-3f 4900 - 5fff and 80-bf 4900 - 5fff. And in some membank0 stuff that I don't understand. For further reference look here. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon May 15, 2006 8:15 pm Post subject: | |
|
|
|
| I'm
not so sure. Foremost is that $[00-3f|80-bf]:[2000-5fff] is supposedly
all mapped to open bus, with the obvious exception of registers mapped
there (most notably $21xx and $42xx/$43xx, but also special chips like
the S-RTC, S-DD1 and SPC7110). Next, the code you referenced has the xor removed. Not that it matters since al is overwritten on the next opcode anyway. All versions (v1.45, v1.46 and v1.84) return the upper byte of the address ($4920 would return $49, $52ff would return $52, etc), which is essentially another inaccurate speedhack to simulate open bus, rather than keeping a true MDR. It would return the incorrect value if you used any indirect addressing mode, for example. To fix it, you need to add a new CPU register that is set upon each read, and return that value here instead. But I imagine you'll take a good speed hit for ~1-2 million additional copies a second in your CPU core, especially for the SA-1. Thank you for looking for a fix though, I appreciate it very much. |
|
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Mon May 15, 2006 9:09 pm Post subject: | |
|
|
|
| You
might also look at Snes9x' source code or ask some of the Snes9x
developers about it since it was fixed in Snes9x 1.37 to behave
correctly. Edit: More information that might be of use: http://snes9x.com/forum/topic.asp?TOPIC_ID=7293 |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 17, 2006 9:16 am Post subject: | |
|
|
|
| Geez,
implemented a speedup to libco that helped P4s by 20%, but I get home
and it hurts my Athlon by 15%. Apparently, mov dword[eax+16],ebp is
faster than push ebp on Athlon processors. Oh well, it's still a better
processor since it isn't pipelined to all hell and back. Anyway, cleaned up the CPU<>APU synchronization a -tad-. I'm pretty sure my dividing of the CPU/APU clocks by eight was causing infinitesimal sync misses, so I went ahead and removed that and cast the counter to a 64-bit variable so that it won't overflow anymore when using the full clock amount. Surprisingly enough, this resulted in no speed loss whatsoever. I also added bus synchronization to the APU core. So yay, the first emulated SNES processor to ever have true bus synchronization is now in bsnes. No speed hit. In fact, it's faster now at 76-78fps. I don't know of any games that will ever benefit from this, but hey... it's there, right? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed May 17, 2006 9:54 am Post subject: | |||
|
|
|||
You can put in an ifdef based on processor. And I have code to pretty much detect all the main processors for you _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 17, 2006 10:14 pm Post subject: | |||||||||
|
|
|||||||||
1) I don't have the time nor resources to profile the code on every x86-compatible processor architecture. 2) A compile-time compare will only be fast if the end user compiles it, or I release separate builds. And I need to avoid separate builds. So far, I want a debugger build (10% speed hit for having it), an accurate (bus-accurate) build, a fast (opcode-based) build, and maybe SSE2 builds. So many options... :( 3) A runtime compare will slow things down everywhere. The compare alone would make performance worse on the A64 build, regardless of which I use. I'd rather optimize for one processor or the other. Here are the comparison results so far. I'm at work so I can't post accurate A64 timings until I get home. The numbers below are pretty accurate, though.
The x is the number of times slower it is to use co_call(newproc) + co_return() or co_jump(newproc) + co_jump(oldproc) than it is to call newproc() + return() (eg standard subroutine calling and returning). P4 stack method :
A64 memory method :
co_call and co_return are identical. The only differences are that co_call saves the old context in the new context stack heap, and co_return lacks an argument and reads the new context to jump to from the stack heap (which is the old context). I have absolutely no idea why co_call / co_return is so much slower than co_jump in the A64-optimized memory-based method. I really, really don't. Also note that bsnes uses co_call / co_return so that I can nest context switches as needed. That said... should I just use the P4 optimized code in all versions? The P4 gains a lot more than the A64 code loses. But dammit, I personally use an A64 and I don't want my version running slower :( Last edited by byuu on Wed May 17, 2006 10:49 pm; edited 1 time in total |
|||||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed May 17, 2006 10:34 pm Post subject: | |||||||||
|
|
|||||||||
Don't. Just do it for the few that can basically run bsnes. Athlon XP, K8, Pentium M and 4.
(someone bring on the grasshopper quote) You can make libco have multiple versions of the functions that matter, use a pointer which at run time is set based on CPU detection to the propper function, the libco function(s) is only accessed via this/these pointer(s). With this method you don't even need to compile multiple times. Also if you don't want the pointer (which AFAIK is the same as direct on modern x86 processors), you can use objcopy magic to make binaries twice the size, but contain two archs in one.
As stated above the trick is to do it once, not every time. Long live pointers, or multiarch. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 17, 2006 11:05 pm Post subject: | |
|
|
|
| I
have serious doubts that indirect memory accesses are equally as fast
as direct memory accesses, pipelines be damned. Maybe even simply
better for cache or something. And if they are, then the direct
accesses are woefully underoptimized. But anyway, the direct accesses
for the stack push/pops are faster than the memory accesses for
saving/restoring regs in the code above. At least on P4s... I prefer to not use pointer magic. But if it really is the same speed on every system... then what choice do I have? :/ I'm only targeting an AMD and Intel version. To hell with their variants. The only way you can compile two versions and be as fast as only having one non-virtual/pointer function is to manually overwrite all references to the function call address with the new function address in the actual program code. Otherwise, you're making a sacrifice somewhere. This of course assuming indirect is slower than direct accesses. |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Wed May 17, 2006 11:22 pm Post subject: | |
|
|
|
| Reading the AMD manual I interpret it this way. There is no speed reduction using near indirect jumps as long as the data is aligned properly, in the case of a far jump the processor adds 1 cycle. So there really isn't any difference on a modern CPU. I would assume gcc or MSVC, whatever you are using would align the data properly so this wouldn't be a problem. Also pushing/pop from stack and memory, at least on an Athlon 64 has the same cycle count of 3 cycles so it wouldn't matter what you did. I will look up what it is on an Athlon XP but I would expect it is about the same or perhaps 1 cycle difference. It's not really something I would worry about unless I was trying to make code to run in a P5. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 18, 2006 12:01 am Post subject: | |
|
|
|
| Well, you can see from my code timing that the indirect memory writes are significantly faster than the stack push/pops. I'd love to get the same speed on both, as the manual says I should. Then I would only need one version. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu May 18, 2006 12:02 am Post subject: | |||
|
|
|||
If it's not the same, use two versions, run time detect, and a pointer, you really have no reason not to, and it's not a big deal. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 18, 2006 12:59 am Post subject: | |||||
|
|
|||||
Well, it is to me. I prefer simplicity above all else. I would have to change the implementation details to allow for a profiler to determine which to use, and something to swap all of the function variables with.
Directly to memory, you are right, however... mov mem32,reg32 -- 3 cycles mov reg32,mem32 -- 3 cycles mov mreg32,reg32 -- 1 cycle mov reg32,mreg32 -- 1 cycle push reg -- 3 cycles pop reg -- 3 cycles pushad -- 6 cycles popad -- 6 cycles It doesn't say if the 1 cycle rule applies to mov mem32+index,reg32 and mov reg32,mem32+index, but it probably does. That or the addition makes it 2 cycles, most likely. pushad and popad are obviously no good since there's only four registers we're saving and restoring. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu May 18, 2006 2:10 am Post subject: | |||||
|
|
|||||
I must be misunderstanding what you're doing, because you shouldn't have to change the implementation or function variables in any way. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Thu May 18, 2006 3:32 am Post subject: | |
|
|
|
| I'm
sorry if this is a common problem, but whenever I start bSNES, I get an
error box that reads, "Failed to create Direct3D9 device". I have the
correct Direct X drivers installed, and I have the latest driver for my
video card installed. I am using bSNES version 0.016. Thank you in advance. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Thu May 18, 2006 3:43 am Post subject: | |
|
|
|
| Yeah, I've gotten that in Vista (5342 and 5365, iirc) as well as when I nuked and reformatted my XP. You can deal with the vista at your leasure, just giving you a heads up for when, oh say, you know, it gets released. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu May 18, 2006 5:04 am Post subject: | |||
|
|
|||
Set the video setting in the .cfg file from D3D to DD. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 18, 2006 5:29 am Post subject: | |
|
|
|
| I
need to add reasons for errors. Most likely you don't have enough VRAM.
You need more than 4MB, which lots of onboard video cards lack.
Otherwise, I don't know why it's failing. I'll try and lower VRAM requirements for the next release. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu May 18, 2006 9:49 pm Post subject: | |
|
|
|
| Yea, I just ran this Windows Vista tool for Win XP, and it told me I need a little more VRAM for Vista. My question is, how do you increase the VRAM in Windows? _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Thu May 18, 2006 10:15 pm Post subject: | |
|
|
|
| You don't. If you have onboard video, see if there's an option to increase/decrease your vram in the BIOS, or buy a new video card. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu May 18, 2006 10:28 pm Post subject: | |||
|
|
|||
Thanks. _________________ Kega Fusion Supporter | bsnes Supporter | Regen Supporter |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Thu May 18, 2006 10:29 pm Post subject: | |
|
|
|
| No problem man. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Fri May 19, 2006 1:02 am Post subject: | |||||||
|
|
|||||||
Example time !
Hopefully this example makes it clearer and not worse. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 19, 2006 1:56 am Post subject: | |
|
|
|
| Thank
you for trying to help, but I learned how to program in C ten years
ago. By the way, since when has ATI been developing x86 processors? :) I'd rather just aim for the best tradeoff between the two and leave it at that, than add all of this extra complexity. Even at +20 cycles for the originally ~20 cycle function, overhead only increased from 6.5x to 7.5x on the A64 processor. So clearly the real bottleneck is the unavoidable pipeline stall and cache invalidation of switching contexts. Oh, by the way... today I thought that for the call/return functions I could just use xchg [eax+index],ebp etc to swap registers out, rather than mov [eax+index],ebp + mov ebp,[ecx+index]. The result was ___102x___ slower than normal function calls. An order of magnitude slower than the 2x mov approach. Holy shit am I ever seriously concerned about the future of processor development. Clock speeds really don't matter anymore with things like this thrown in there. This was on the P4, by the way. On the Athlon, xchg mreg,reg takes 2 clock cycles compared to mov mreg,reg's 1. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri May 19, 2006 6:59 am Post subject: | |||||
|
|
|||||
Those special purpose opcodes are a "relict" from the CISC era. Newer RISC-based processors often sacrifice their speed in favor of the opcodes that are used more often by compilers. EDIT: link _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Fri May 19, 2006 12:23 pm Post subject: | |||
|
|
|||
Yeah these opcodes are often emulated in microcode rather than implemented in silicon. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 19, 2006 5:17 pm Post subject: | |||||
|
|
|||||
That's how I figured obscure MOVZQRIIWNP mreg16,reg16 (move double-precision floating point integer in hyperspace into precached single-precision doublequad phase inducing capacitor-space memory) opcodes would be implemented, but not a basic opcode like xchg. And wow, what an amazing performance hit for silicon->microcode. They should really have manuals out there indicating for each chip what is silicon and what is microcode, so that the latter can be avoided like the plague. Well for now, push + pop method wins. The memory-method stalls out the P4 co_call + co_return functions badly. Probably because it has two unavoidable switches between mem->reg and reg->mem, whereas the push + pop method only has one. As a result, push + pop does not stall out either processor on either method. Edit: ok, optimized the memory read vs write and address accesses as much as possible, and aligned all code+variable accesses, and I now have :
co_call and co_return are identical, but co_call has one extra opcode to save the current context inside [ptrNew+4], co_return accesses [ptrOld+4] instead of [esp+4]. -- all tests below on Pentium IV 1.7ghz processor -- windows fibers method : co_call = 9562 clocks, 21.88x overhead co_jump = 7422 clocks, 16.98x overhead subroutines = 437 clocks memory method : co_call = 7359 clocks, 16.84x overhead co_jump = 5141 clocks, 11.76x overhead subroutines = 437 clocks stack method : co_call = 4594 clocks, 10.49x overhead co_jump = 3656 clocks, 8.35x overhead subroutines = 438 clocks Basically there's a ~64% speed increase for co_call method and a ~41% speed increase for co_jump method using the stack approach vs memory approach. Whereas on the Athlons, 7.5x / 6.5x = ~15% speed hit for both methods. That plus the greater dominance of P4s (sadly), means the best choice is clear. But compared to windows fibers, writing the library myself has gained me ~108% speed increase for co_call method, and ~103% over co_jump method. Both more than twice as fast. It's too bad the windows fiber code pretty much had to be written in assembler. This would make a great argument for my case that hand-optimized x86 assembler written by a talented programmer can easily beat out optimized c++ code by 50-100% or more, at least on the x86 architecture. Although I now believe that claim is heavily dependant on the exact processor + memory configuration in use :/ |
|||||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Fri May 19, 2006 8:40 pm Post subject: | |
|
|
|
| Out of curiosity, have you tested this bad boy on both XP-32 and XP-x64? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 19, 2006 8:57 pm Post subject: | |
|
|
|
| I
do not have WinXP 64-bit edition, nor access to a computer with it
installed. However, the x86 version will not work with the processor. I
can port the soruce code (and know exactly how to already), but I have
no idea how I'll be able to assemble it. It will be slower. It has to push twice as much data per register, and two additional registers onto the stack, and then pop the same amount. 32-bit { ebx, esi, edi, ebp, esp } -> 64-bit { rbx, r8, r9, r10, r11, rbp, rsp }. 160*2 bits -> 448*2 bits, 2.8x more information. I'm going to wait until 64-bit stuff is a bit more common, or wait until someone ports my existing code for me and gets it to build :) |
|
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Fri May 19, 2006 9:21 pm Post subject: | |||
|
|
|||
Figured so much, but it was worth asking. My Athlon64 runs xp-x64 and it's a mixed bag, but utterly unstable due to pretty bad nforce3 chipset drivers. Be happy you're stuck with 32-bit stuff for now .
|
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Fri May 19, 2006 9:58 pm Post subject: | |||
|
|
|||
Um, while is this is logically correct, it is incorrect at the same time. 64-bit CPU's also move more data per clock than 32-bit so the difference is hardly noticable. We wouldn't be using 64-bit code if it was going to be that much slower. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 19, 2006 10:38 pm Post subject: | |
|
|
|
| I realize moving 64-bits of data at once on a 64-bit processor is faster than moving 64-bits of data as two separate operations on a 32-bit processor. But we can both agree the 64-bit context switching code will be slower. By how much, I've no idea. | |
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Sat May 20, 2006 12:12 am Post subject: | |||||||||||
|
|
|||||||||||
I don't think XCHG is emulated, but this is the real reason it is so slow:
"Align 16" would be better for functions. "__fastcall" can also be used to speed up function calls by using ecx/edx to pass args instead of the stack. Also, "co_delete" randomly leaks memory because MOV does not set any flags on x86. "_free" checks for null anyway, so the entire _co_delete function can simply be replaced by "jmp _free".
|
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat May 20, 2006 12:46 am Post subject: | |||||||||||||||||||
|
|
|||||||||||||||||||
Ah, that definitely explains why it's so slow... thanks.
Just noticed that NASM defaults to align 16 for code sections. I'll use align 16.
Hahahah, oops. Nice catch. You can tell I'm used to the SNES processors. I've read though that the behavior of calling free on an invalid (null) memory address is undefined. Are you absolutely certain that is not the case? I even see most programmers writing code like :
EDIT:
Hmmm, it would be nice to avoid calling free twice resulting in undefined behavior, but there's no way I could account for that anyway.
I was actually just talking about __fastcall on the mameworld.info forums. I was saying I didn't want to use it because of the name decorations that result from it. I decided to go ahead and give it a try anyway, and got surprising results : co_call as a __fastcall went from 4562 clocks to 4516 clocks, an improvement. co_jump as a __fastcall went from 3610 clocks to 4469 clocks, a major speed hit. Apparently, the Pentium IV is one stupid, stupid processor. That, or MSVC is a bad compiler. Or both ;) The __fastcall co_jump function :
The only difference between the two functions is the one stack access at the top being enabled/disabled. Same for co_call. co_return was left as a normal function since it doesn't take any arguments anyway. The only other thing changed was the c++ define from : extern "C" void co_jump(thread_t cothread); to : extern "C" void __fastcall co_jump(thread_t cothread); Absolutely bizarre. This should definitely be faster, but isn't. I have no idea why. If this helps, here is the CPUID output :
This should be faster on my Athlon64. Should I use the __fastcall convention anyway, and just ignore the P4 stupidity? EDIT: I think I might know what it is :
It's probably using ecx for i, and the fastcall is causing that register to save / restore itself. So the compiler is just being stupid. So then, what do I optimize for? Though uncommon, it's possible my libco will be used in loops just like that, after all. And it's the only way I presently have to profile the code speed. Still, if it used ecx for i, then it would have to push / pop it either way, since callees are not required to save ecx. Eh, I'll disassemble the code when I get home tonight. |
|||||||||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 23, 2006 9:23 am Post subject: | |
|
|
|
| Eh, I think I have it now. Page is here: http://byuu.org/?page=libco Has a general description of the library (basically a rehash of what's already been said here, on the NESdev forum, and the mameworld forum) and download. If anyone has any obscure processors (VIA processors, older 486's, etc), I'd appreciate if you were to run the included two programs (main_x86 and main_win32) and post the output you get here. My theory is that we'll get a bell curve in performance between the processors. 80386 will have poor performance, Pentium (maybe 2) or AMD K6-2 will have the best performance, and Pentium IV will have the worst. We'll see, though :) And better yet, if anyone wants to port the library to their favorite OS cothreading API, or write their own implementation in assembler (even better!), please do! I'm not going to make a sourceforge page for this, but I would like to help create a fast, simple, general purpose cothreading library that is as platform-independant as possible. And presently, the Mac OS X version of bsnes cannot be compiled with the new APU core due to not having a library available for that processor / OS. --- I also tried reducing the VRAM requirements in Direct3D, and modified an option or two, in hopes of solving the "failed to create direct3d9 device". If anyone is receiving this error and wants to see if its fixed now, please PM me and I'll send you a link to a WIP build. Don't ask for it if you aren't having the problem. This build isn't optimized at all and runs ~40% slower than release versions. I just want to know if the problem is fixed or not now. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue May 23, 2006 10:25 am Post subject: | |
|
|
|
| Good writeup on libco, sounds like it's coming along nicely. It's pretty ingenious, really, if it works out. I'm upgrading to a core 2 duo this summer. Should be good for bsnes Both AMD and Intel are now going to be using short pipeline strategies from here on out I'm guessing.Last edited by FitzRoy on Tue May 23, 2006 10:28 am; edited 1 time in total |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Tue May 23, 2006 10:27 am Post subject: | |
|
|
|
| Yeah the preformance on my P4 2Ghz really isn't that different between the exes. I'd test it on my P 100Mhz, but I think I need something higher then windows 95 to test it with. Atleast the kernel doesn't support those functions it needs. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue May 23, 2006 12:00 pm Post subject: | |
|
|
|
| byuu: "Any code submitted to this library must fall under this same library, and be submitted to me as public domain for inclusion." Doesn't sound right. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Tue May 23, 2006 12:47 pm Post subject: | |
|
|
|
| main-win32 clocks per second = 1000 4109 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2516 clocks / 100,000,000 co_jump calls (50000000 iterations) 265 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 15.505660x co_jump skew = 9.494340x main-x86 clocks per second = 1000 1625 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 1516 clocks / 100,000,000 co_jump calls (50000000 iterations) 265 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 6.132075x co_jump skew = 5.720755x done |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 23, 2006 3:19 pm Post subject: | |||||
|
|
|||||
Basically, any code submitted must be license-free, that way it can be included. Obviously, BSD-license would be fine, too, since that's what I'm using. I should clarify that when I get home tonight. ---
Great scores, thanks pagefault! Definitely can tell that's an AMD processor, heheh. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue May 23, 2006 3:22 pm Post subject: | |||||
|
|
|||||
Well, remove the "must fall under this same library" clause, and replace with something more readable _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue May 23, 2006 4:16 pm Post subject: | |
|
|
|
| Not sure if this relevant as I have a P4 @ 2.4ghz Prescott but here's my result: main_win32 cooperative multithreading test test should return '1234567' 1234567 context-switching timing test application must be compiled with optimizations disabled for this to work clocks per second = 1000 6562 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 4594 clocks / 100,000,000 co_jump calls (50000000 iterations) 250 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 26.248000x co_jump skew = 18.376000x done main_x86 cooperative multithreading test test should return '1234567' 1234567 context-switching timing test application must be compiled with optimizations disabled for this to work clocks per second = 1000 2687 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2625 clocks / 100,000,000 co_jump calls (50000000 iterations) 250 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 10.748000x co_jump skew = 10.500000x done |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Tue May 23, 2006 4:34 pm Post subject: | |
|
|
|
| For the fun of it, here's my P4 at 3.2ghz... main-win32 clocks per second = 1000 4109 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2516 clocks / 100,000,000 co_jump calls (50000000 iterations) 265 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 26.611872x co_jump skew = 18.264840x done main-x86 clocks per second = 1000 1625 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 1516 clocks / 100,000,000 co_jump calls (50000000 iterations) 265 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 11.083744x co_jump skew = 9.926108x done Oh, and I sent you a PM byuu about the D3D thing. |
|
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Tue May 23, 2006 6:04 pm Post subject: | |
|
|
|
| Results on linux (debian etch) with gcc 4.1: P4 NW 2.26@2.6 GHz unoptimized: clocks per second = 1000000 3070000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2860000 clocks / 100,000,000 co_jump calls (50000000 iterations) 300000 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 10.233333x co_jump skew = 9.533333x optimized with "-O3 -fno-inline-functions -fomit-frame-pointer" (still valid I think): clocks per second = 1000000 3000000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2850000 clocks / 100,000,000 co_jump calls (50000000 iterations) 200000 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 15.000000x co_jump skew = 14.250000x K6-III 450 MHz unoptimized: clocks per second = 1000000 6580000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 6360000 clocks / 100,000,000 co_jump calls (50000000 iterations) 1130000 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 5.823009x co_jump skew = 5.628319x optimized with "-O3 -fno-inline-functions -fomit-frame-pointer" (still valid I think): clocks per second = 1000000 6690000 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 6230000 clocks / 100,000,000 co_jump calls (50000000 iterations) 570000 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 11.736842x co_jump skew = 10.929825x |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Tue May 23, 2006 6:48 pm Post subject: | |
|
|
|
| tonight I'll post results on my a64 x2 using debian sid x86_64. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Tue May 23, 2006 6:51 pm Post subject: | |||||||
|
|
|||||||
Any code submitted to this library must be submitted under the libco license. or something to that effect. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 23, 2006 7:29 pm Post subject: | |||||
|
|
|||||
|
Anyone without P4s or Athlon K8s? :) sinimas, glad to see it works on linux. I imagine you had to change _malloc and _free to malloc and free. Need to add some define magic to it. Optimizing is a bad idea (for timing code, at least), and will break the test. Compiler optimizations turn code like:
into
Not exactly ideal when you're trying to benchmark the speed of calling myproc, hm? So far, results are consistent as I'd imagine. The older K3 with less pipelining than modern processors performs better. My last prediction is that the oldest processors (386, maybe 486) will perform even worse, due to the extremely limited pipelining not being able to cache the opcode instructions quickly enough / completely. So due to there being so many more opcodes than a simple call, overhead will go up to ~15x or so. It's a good thing the processor speeds are increasing so rapidly to counter the speed loss of thread switching. With a multitasking OS, or a true pre-emptive database server, I imagine this overhead can make a serious impact on performance. |
|||||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Tue May 23, 2006 7:54 pm Post subject: | |
|
|
|
| Will test on the following tonight or tomorrow at the latest: Athlon-XP with xp-x64 AMD Duron 800 with FreeBSD Pentium-M laptop with xp-32 Edit: I think I also have a 1GHz first-gen Athlon to test on, running win2k3. That too. |
|
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Tue May 23, 2006 8:29 pm Post subject: | |||||||
|
|
|||||||
I commented the linker macros from libco_x86.asm, defined __fastcall __attribute__((fastcall)) in libco_x86.h, and replaced <conio.h> with <curses.h> in main.cpp. I don't think the optimizations invalidated the test, since I defined global_i volatile and disabled inlining. If I allow function inlining and don't mark global_i volatile, number of clocks for the subroutine calls becomes 0, since it's all optimized away. |
|||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue May 23, 2006 9:19 pm Post subject: | |||||||||
|
|
|||||||||
However there isn't a "libco license" but there is the BSD license which is what libco is curerently using. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||||
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Tue May 23, 2006 10:33 pm Post subject: | |||||
|
|
|||||
|
Probably late, but scores are almost the same as pagefaults. I have an X2 @2.4GHz. main_win32:
main_x86:
_________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group Last edited by Clements on Tue May 23, 2006 11:56 pm; edited 1 time in total |
|||||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Tue May 23, 2006 10:34 pm Post subject: | |
|
|
|
| Pentium-M 1.5GHz, xp-32, tested using binaries from byuu.org: main-x86 clocks per second = 1000 2613 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2324 clocks / 100,000,000 co_jump calls (50000000 iterations) 310 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 8.429032x co_jump skew = 7.496774x done main-win32 clocks per second = 1000 6329 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 4085 clocks / 100,000,000 co_jump calls (50000000 iterations) 311 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 20.350482x co_jump skew = 13.135048x done |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Tue May 23, 2006 10:38 pm Post subject: | |
|
|
|
| Sorry byuu, I should of posted my scores before. main_win32: test should return '1234567' 1234567 clocks per second = 1000 7046 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 4985 clocks / 100,000,000 co_jump calls (50000000 iterations) 375 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 18.789333x co_jump skew = 13.293333x main_x86: test should return '1234567' 1234567 clocks per second = 1000 4875 clocks / 50,000,000 co_call + co_return calls (50000000 iterations 4484 clocks / 100,000,000 co_jump calls (50000000 iterations) 375 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 13.000000x co_jump skew = 11.957333x Edit: Pentium IV Northwood 2Ghz @ 100Mhz FSB Last edited by powerspike on Wed May 24, 2006 2:04 am; edited 4 times in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 23, 2006 11:40 pm Post subject: | |
|
|
|
| I
need to know the processor type. And there's no need to test the same
processor again (eg Pentium IV) if it's already been tested. Though I
guess it's good to know this is stable on all systems tested so far, at
least. I'm very glad to see that the Pentium M performs better than the Pentium IV. That's definitely a good trend. Faster clocks through faster busses, with less multipliers and less pipelines. More cores for multitasking. The future looks good :) |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Wed May 24, 2006 12:26 am Post subject: | |
|
|
|
| For the record mine is currently an Athlon XP 2400+ o/ced to 2.2ghz at 182mhz FSB. | |
Veteran
Joined: 28 Jul 2004
Posts: 991
| Posted: Wed May 24, 2006 12:57 am Post subject: | |||||||
|
|
|||||||
|
On my Athlon XP 3000+ Barton @ 2.154ghz main_win32
main_x86
_________________
θάνατος |
|||||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed May 24, 2006 1:20 am Post subject: | |
|
|
|
| byuu, I'm kinda interested in knowing how well the tests did on your system... | |
Redneck Gamer-Mod
Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
| Posted: Wed May 24, 2006 1:32 am Post subject: | |||
|
|
|||
Righto, on it. 486, k6-2+, and MediaGX coming up. Check this post. EDIT1: Whoops, not Win95 supported! What OS does this need? its linked to missing export KERNEL32.DLL:ConvertThreadToFiber and IsDebuggerPresent. If you require 2k/xp, there's nothing I can do. _________________ SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!! Steelers no longer officially own your ass. Pittsburgh will miss The Bus. Last edited by kevman on Wed May 24, 2006 1:44 am; edited 1 time in total |
|||
saskatchewanite
Joined: 26 Apr 2006
Posts: 317
| Posted: Wed May 24, 2006 1:37 am Post subject: | |
|
|
|
| I have access to athlon xp barton 3200+ and k8 4000+ machines. would those be of any use? _________________ everything i say is a lie the above line is true |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 24, 2006 1:42 am Post subject: | |||
|
|
|||
|
MediaGX?? o_O I get maybe 5% better scores than pagefault's Athlon 2400+ with my 3500+, however mine isn't overclocked.
Nope. K7 and K8 already tested, thanks anyway. |
|||
Redneck Gamer-Mod
Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
| Posted: Wed May 24, 2006 1:47 am Post subject: | |
|
|
|
| Yeah, the MediaGX runs 98, though. Will the build work with it? So does the k6-2+. The 486 is 95. _________________ SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!! Steelers no longer officially own your ass. Pittsburgh will miss The Bus. |
|
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Wed May 24, 2006 11:04 pm Post subject: | |
|
|
|
| Follow-up: the following are results are from an Athlon64 2800+ running Windows XP-x64. main_win32.exe clocks per second = 1000 5234 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 3329 clocks / 100,000,000 co_jump calls (50000000 iterations) 312 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 16.775641x co_jump skew = 10.669872x done main_x86.exe context-switching timing test application must be compiled with optimizations disabled for this to work clocks per second = 1000 1937 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 1875 clocks / 100,000,000 co_jump calls (50000000 iterations) 328 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 5.905488x co_jump skew = 5.716463x done Conclusion: your library works just fine in 64-bit Windows. I think I've got a beta copy of the 64-bit Vista so in a few days I'll test on that as well once I get it installed. Last edited by MajereDB8 on Thu May 25, 2006 2:06 am; edited 3 times in total |
|
Cap'n Gin | Admin
Joined: 27 Jul 2004
Posts: 748
Location: Missouri
| Posted: Thu May 25, 2006 3:26 am Post subject: | |
|
|
|
| Athlon 64 3200 X2 X86 - clocks per second = 1000 1750 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 1656 clocks / 100,000,000 co_jump calls (50000000 iterations) 265 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 6.603774x co_jump skew = 6.249057x Win32 - clocks per second = 1000 4343 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2766 clocks / 100,000,000 co_jump calls (50000000 iterations) 281 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 15.455516x co_jump skew = 9.843416x |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 25, 2006 10:09 am Post subject: | |||
|
|
|||
Doesn't the X2 line start at 3800+? A 3200+ dual core would be really nice, though. As it is, sub $200 dual core processing requires going back to Intel. Which isn't going to happen. |
|||
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Thu May 25, 2006 11:57 am Post subject: | |||||
|
|
|||||
main_win32:
main_x86:
Athlon Thunderbird 1 ghz |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 25, 2006 4:49 pm Post subject: | |||||
|
|
|||||
Ok,
I just thought about this: my debugger. I haven't rewritten it so I
can't just test this. I mainly only plan to allow changes when one is
between opcodes. Now, would there ever be a chance with any compilers that variables would be on the stack, instead of inside their respective variables? eg :
Now, see I basically increment regs.pc before switching contexts, and then increment regs.pc again afterwards. My question is, will all (and all is very important here) c++ compilers recognize that the non-inlined function may access the variable regs.pc and appropriately NOT try and leave the new regs.pc on the stack, eg
The above would result in printf writing out 0x8001, and regs.pc becoming 0x8004. Whereas the c++ should end up printing 0x8003, and the code would end with regs.pc = 0x8005. Can I be certain that this is always the case? It seems like the answer is obvious, but since I am messing with stack-related stuff now, which is supposed to be hidden to the programmer, and since I know c++ has a penchant for evil optimizations (replacing entire loops with function calls into single mov instructions, etc)... is this something to worry about? If it is, then I won't be able to use a debugger with the cothreaded code. And if I can't use a runtime debugger, then this entire approach will have very little value to me :/ |
|||||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Thu May 25, 2006 6:12 pm Post subject: | |
|
|
|
| p3 1000 @ 750(don't ask) coppermine win32: clocks per second = 1000 12850 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 7850 clocks / 100,000,000 co_jump calls (50000000 iterations) 830 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 15.481928x co_jump skew = 9.457831x x86: clocks per second = 1000 5220 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 5160 clocks / 100,000,000 co_jump calls (50000000 iterations) 830 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 6.289157x co_jump skew = 6.216867x _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. Last edited by funkyass on Thu May 25, 2006 6:38 pm; edited 1 time in total |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu May 25, 2006 6:17 pm Post subject: | |
|
|
|
| main_x86 clocks per second = 1000 2843 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 2532 clocks / 100,000,000 co_jump calls (50000000 iterations) 281 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 10.117438x co_jump skew = 9.010676x main_win32 clocks per second = 1000 8953 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 7390 clocks / 100,000,000 co_jump calls (50000000 iterations) 313 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 28.603834x co_jump skew = 23.610224x From the 2.8 ghz Xeon we have here at work. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 25, 2006 6:48 pm Post subject: | |||
|
|
|||
Hoooooooooly crap thats slow. Man, I bet my library would allow for a huge speedup on Xeon servers using the cothreaded versions of SQL server / etc, as they use the exact same Fiber API that I use in that test. Maybe I should make a #define list to clone / drop-in replace Windows Fiber implementations. |
|||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Thu May 25, 2006 7:02 pm Post subject: | |
|
|
|
| P4 1500 Williamette: win32: clocks per second = 1000 9673 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 6940 clocks / 100,000,000 co_jump calls (50000000 iterations) 481 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 20.110187x co_jump skew = 14.428274x x86: clocks per second = 1000 5848 clocks / 50,000,000 co_call + co_return calls (50000000 iterations) 5047 clocks / 100,000,000 co_jump calls (50000000 iterations) 471 clocks / 50,000,000 subroutine calls (50000000 iterations) co_call skew = 12.416136x co_jump skew = 10.715499x whats the cache info on that xeon PF? _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu May 25, 2006 10:22 pm Post subject: | |||||||
|
|
|||||||
First under WINE:
Now under 32 bit Linux:
Now 32 bit Linux linked against Google allocator:
_________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu May 25, 2006 11:48 pm Post subject: | |||
|
|
|||
I don't know what Google Allocator is, but it looks like it just slows things down. Now WINE, on the other hand ...
Hooooooooooooooooooooooooooooly fucking Moses. What in the hell is WINE doing for these functions? o.O Wow. Perhaps I should submit my code to the WINE team, as well. Only problem is mine doesn't break apart the global stack heap into subsections, it allocates new memory and uses that for each stack heap. I can't imagine that being too much of a problem, but who knows. |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu May 25, 2006 11:59 pm Post subject: | |||
|
|
|||
Why do you say that? Aren't lower scores better? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 26, 2006 12:15 am Post subject: | |
|
|
|
| http://cvs.winehq.org/cvsweb/wine/dlls/kernel/fiber.c?rev=1.7&content-type=text/x-cvsweb-markup Heh. In pure c++, too. Confusing code. Anyway, lower skew numbers are better, but you're only getting a better score because it took longer for the standard subroutine calls to complete. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Fri May 26, 2006 12:27 am Post subject: | |||
|
|
|||
And you're sure that's the only reason? You're using malloc and free inside your x86 code, and the Google allocater is supposed to run those functions in 1/6 the time. And that AFAIK, is the only changes it makes. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri May 26, 2006 1:30 am Post subject: | |
|
|
|
| I only use them to create the threads, the malloc / free time is not counted in the actual timing tests, so yes. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri May 26, 2006 2:09 pm Post subject: | |||||||
|
|
|||||||
CPU info _________________ savestate editor: vSNES latest public version
|
|||||||
Lurker
Joined: 04 Sep 2004
Posts: 193
Location: USA
| Posted: Sat May 27, 2006 8:04 pm Post subject: | |
|
|
|
| Quick
question: "Goodbye, Anthrox (PD)" no longer seems to run in bsnes
0.016. (It's the ROM that was used to demonstrate the 16-bit accuracy
limitation of the Mode 7 hardware.) Does anyone know why? Should someone create a separate thread for bsnes bug reports? _________________ This signature intentionally contains no text other than this sentence. |
|
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Sat May 27, 2006 8:35 pm Post subject: | |||
|
|
|||
|
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Mon May 29, 2006 7:39 am Post subject: | |
|
|
|
| Feature request for byuu: and well it's actually a "please emulate X hardware" request (yes I should held my head in shame ) Anyway, a recent post on the zsnes talk ("piggyback rom" or something) made me remember that I made the same request long ago.Suprisingly enough that request has appeared a few times actually, so I wouldn't actually be the only one to enjoy it, if that's any convincing argument. Basically the user is asking to emulate the Snes Game-Genie. Not just GG code support but the actual hardware support. So basically the GG bios would be executed, enter the codes,press start (or whatever that was) and then rom is executed with loaded codes. edit Of course, I do realise it's more complicated than just "piggyback" the Snes rom on top of the GG bios... And yes,it's only real use would be a pure nostalgic one. Anyway, if it's something hard to implement,or if there's not enough info or if you feel hardware GG support aren't worth the effort then never mind my request. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 30, 2006 10:07 pm Post subject: | |||||||||
|
|
|||||||||
|
Ok, I've logged reads+writes to all unmapped registers for Captain America. It isn't accessing anything it shouldn't. It isn't touching any unmapped regs anywhere from $2000-$5fff. I've even made sure to check inside the CPU and PPU regions that have some read or write only registers. So, let's try some other things. The corrupted tiles are on BG1. Super Sleuth state inspector says that : BG1 NBA = 0000 BG1 TD = 5900 (eg 0xb000 VRAM addr) BG1 HSCROLL = 0 BG1 VSCROLL = 255 BG1 char size = 8x8 BG1 map size = 32x64 Verified all of this is the same with bsnes : 2105 = 09 <BG Mode 1, 8x8 BG1 tiles, BG3 pri> 2107 = 59 <b000, 1 - 32x64 scsize> 210b = 40 <0000 tdaddr> 210d = 0 (0 hscroll) 210e = 00ff (255 vscroll) Ok, check VRAM dump. Hmm, problem. VRAM for BG1 NBA (tiledata) is all 0x0000 up to VRAM offset 0xc00. ZSNES has lots of data for this region. Everything after 0xc00+ is different, too. So corrupted tiles? Check. Tilemap, tilemap... identical from b000-b77f, b780+ is different. Shouldn't affect the first screen of data, at least not the top part. Gotta track down tile corruption, which is likely a DMA. Ugh, I hate this game so much. ---
Pretty stupid. You can't save your codes, you're limited to five codes, you get to input them manually, and at least in software there's no code enable / disable toggle. Oh well, doesn't seem too difficult to do. ROM completes and jumps into RAM execution code :
RAM completes and jumps to the reset vector :
This is where the BIOS loops forever because it's jumping right back to the regular BIOS ROM. The GG hardware is communicating via writes to ROM in the range of $00:8000-$00:8016 :
... etc. I haven't bothered to decode the writes yet. It will require modification to bsnes since by default ROM writes are ignored, but I at least already separate read / write handlers, so it won't be too bad. Not sure if I'm going to bother adding support for this or not. |
|||||||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Tue May 30, 2006 10:56 pm Post subject: | |
|
|
|
| I personally don't think it's worth the time and effort to support when built in cheating facilities are far superior. If it were up to me I would spend more time on stuff that was actually important. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue May 30, 2006 11:10 pm Post subject: | |||||
|
|
|||||
Agreed. Well, it was only 20 lines of code, so :
This would be trivial to add. Just saying ... dumber features have been added in the past. So, emulation approach : Load ROM normally. Right after loading the ROM and mapping all registers, add check for GG ROM enable. If enabled, bypass loading .cht file and load GG ROM. Map GG ROM. Accept input codes and when #$07 is written to $008000 by mapping each code as though they were read from .cht file. Main GUI interface can now be used to toggle cheat codes on and off, as would be the case on the original hardware with that little toggle switch on the side. Then map original ROM instead, and free the GG ROM from memory (or keep it aside for reset, possibly?). Once the ROM is unloaded, do not save .cht file if GG ROM is enabled. Done. There. Captain America is fixed. Top log is ZSNES, bottom is bsnes v0.013, which also has the CA bug.
It's reading the VRAM transfer address from $006ff0,$006ff1; which is unmapped in this case since there is no SRAM chip in this game. I've unfortunately not accounted for this space (instead using only $[20-3f]:[6000-7fff]) and bsnes as a result fell back on mapping this space to ROM. Reading from ROM at this space was returning different data, making it transfer the tiledata to the wrong offset. Ok, so what happens when you read $[00-1f]:[6000-7fff]? Return open bus. In this case, lda $0010,x just happens to have the last byte be 0x00 [ad 10 00], so open bus will return 0x00, 0x00 in this case. Which just happens to be the correct offset to transfer tile data to. Boy, isn't the SNES a fun little system? |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Wed May 31, 2006 4:51 am Post subject: | |||||||
|
|
|||||||
Ether way thanks for considering it. I'm not gonna try to convince anyone that hardware GG support is superior in term of pure functionality. Just something to recreate the old interface (primitive and limited as it was) that many people used back then. edit:
Awesomeness. Anyway, even if you do decide not to implement it thanks again for looking into it.Ideally, the little GG on/off toggle switch could be mapped on the keyboard instead of going through the GUI every time, but at this point I'll just shut up
|
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed May 31, 2006 5:22 am Post subject: | |
|
|
|
| Congratulations on the Captain America fix. Strangely, I was reading an old comic book yesterday and there was an advertisement inside for the game's release on SNES. One of the pitches was "plays just like the arcade version!" Got a good chuckle from that one. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 31, 2006 5:36 am Post subject: | |
|
|
|
NTSC filter fix : The textbox is hires, whereas the background is lores. Even when the textbox disappears, the lores part of the screen looks the same. There is no sharpness difference as in the normal direct filter. Captain America fix : To hell with this game D:< |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed May 31, 2006 5:47 am Post subject: | |
|
|
|
| Is it just me, or does Captain America look really goofy in that icon by his health? | |
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Wed May 31, 2006 12:33 pm Post subject: | |
|
|
|
| So,
from what I understand, the Captain America bug was because the
programmers had a bug in Captain America code which coincedentally
happened to return the desired value anyway via open bus? Congrats on that one. Those kinds of issues are a real bitch to track down. But, in the end it was worth it because you have one more additional piece of the SNES emulated accurately. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed May 31, 2006 4:13 pm Post subject: | |||||||||||
|
|
|||||||||||
Yes.
I generally consider open bus as reads from write-only registers (eg
$4210), but of course it even applies to unmapped cart regions as well.
One down... 21 to go :( The bug list seems to grow faster than I fix things ... Edit: Rendering Ranger R2 (J) - hangs sometimes at new game start, earlier random hangs with "reset" I can no longer reproduce this bug. I can on v0.016 official. No idea what fixed it, or if I've just been very lucky in it not occuring after ~15 tests. Looking at Jurassic Park 2 now ... Getting stuck waiting on an IRQ to occur at V=167,H=130. Hmm ... suppose I'll wait until I redo the CPU core to fix this one. The NMI / IRQ code is a mess in the current version. Ok, Tales of Phantasia, CGRAM dump :
Colors 49-51 (CGRAM 0x62-0x67) is being corrupted somehow. Palette colors are being overwritten with 0x31's.
Happening during HDMA. Fun, more HDMA bugs.
Added a hack to fix Tales of Phantasia. In bCPU::hdma_run() ...
... hahah, just kidding. That got the log above. No hacks :) Still working on it ... this is going to be a pain because all the other emulators suck at debugging HDMA. |
|||||||||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed May 31, 2006 10:40 pm Post subject: | |
|
|
|
| Man, you almost shocked me there when mentioning a hack to fix that game. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 01, 2006 12:09 am Post subject: | |||
|
|
|||
|
Heheh. Well, that code above does fix the problem ... ;) But yeah, just using it for logging data.
That's the best I can do. Both ZSNES and bsnes are using HDMA channel 5 to draw the gradient window effect in ToP battles. However, bsnes for some reason keeps on going and ends up writing into the background colors. I don't have any idea why. The HDMA table hex code is identical between the two emulators. I won't be able to compare HDMA processing code between any other emulator to find the bug so I don't think I'll be able to fix this bug either :( At least I know it's an HDMA bug, probably similar to the one in Genjuo Ryodan. |
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Jun 01, 2006 12:57 am Post subject: | |
|
|
|
| I am not very familiar with HDMA, what address is it writing to when it does this writing to the background. It sounds like it might be something timing related, but that would surprise me since ZSNES HDMA timing is almost non-existant right now. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 01, 2006 1:11 am Post subject: | |||||||||
|
|
|||||||||
I've tracked this bug a bit further back.
Look at address $7e62bb. It goes from 0x00 to 0x31. So the HDMA table is being overwritten with this data somewhere...
Fun.
Hmm. The trb / beq branch is not taken, causing an mvn to occur that overwrites it. In ZSNES, it is always true until a bit after the corruption occurs in bsnes. I have tried and tried to track the code backwards, but every damned code point I try has different variables in A, X or Y between the two trace logs. The further I go back, the more differences I find. I can't keep up with this. |
|||||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Jun 01, 2006 7:16 am Post subject: | |||||
|
|
|||||
Nice. _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 01, 2006 8:20 am Post subject: | |
|
|
|
| Ok, so today I spent all day trying to fix Tales and failed miserably. At home, I went ahead and cleaned up the CPU disassembler (still need to do the same for the APU disassembler). I then added in tracing (no masking) and a better debug message system and the option to enable / disable debug, cpu and apu messages individually to the debug interface. Of course, this does no good since I don't actually have the debugger at all functional yet. But it's one step closer to getting the v0.013 debugger back. Also tried once again to turn the fullscreen surface into an overlay for either Direct3D or DirectDraw, and failed. Is it even possible to make an overlay surface with D3D? Whatever Winamp AVS does, its overlay support seems to work fantastically. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Jun 01, 2006 9:15 pm Post subject: | |||
|
|
|||
Nice work with the libco implementation and the recent emulation fixes,woot But now I kinda feel bad about the ToP bug I reported seeing as this bug seem to be a bitch to track down... Though sooner or later someone else would have reported it I guess
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 01, 2006 9:59 pm Post subject: | |
|
|
|
| No, it's a serious problem. It's corrupting an HDMA table which in turn corrupts CGRAM data. Thusly screwing up palette colors. It needs to be fixed, but I'm at a loss for how to track down where the error starts. It's basically CGRAM write error due to HDMA error due to overwrite error due to ... ad infinitum. Where I'm at now, it's just a million conditional branches for all kinds of random memory address values and other emulator logs are completely different from mine, so I have no point of comparison of where things go wrong. |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Jun 01, 2006 10:42 pm Post subject: | |
|
|
|
| Many cards do not support RGB overlays, ATI and nVidia cards included. You will have to convert to YUV to use the overlay. Since you have to most likely do this in software it almost defeats any advantage overlays would give you. I looked into this a while ago and decided it wasn't a viable solution. Funny thing is that in linux RGB overlays are supported by Xv. So it must be a driver thing. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 01, 2006 11:22 pm Post subject: | |
|
|
|
| I
managed to get the DirectDraw overlay up. Supposedly overlays with GDI
and D3D are impossible. You can rig up a hybrid by creating the
surfaces through DD and attaching them via D3D, though. Anyway, overlays have their advantages : - No overhead in switching to fullscreen mode - Surfaces can be flipped for smooth triple buffering even in windowed mode - Nothing can appear on top of the overlay, so pseudo-fullscreen no longer will have issues with the damn taskbars and other always-on-top apps popping up on top of your emulator window - Dual monitors will automatically pop the overlays onto the second monitor. Great for debugging with a fullscreen video display on the second monitor So, I of course can't get an RGB overlay because video card manufacturers are lazy assholes D:< Supposedly UYVY is supported on every card under the sun now. But it's near impossible to render a UYVY image in DirectDraw :/ The format is supposedly : byte[U] byte[Y] , byte[V] byte[Y]. The idea is you get a full 8-bit Y sample every pixel, and one U or V sample every other byte. The video card just shares the U+V between the two pixels. Already unusable to me. But I can't even get anything to display using only the Y channel. The video should be grayscale, but instead is completely psychotic colors. I know my Y calculation is correct, and I've tried putting the Y on the low byte and high byte of each pixel to no avail. Now then, take a look at Winamp and it's advanced visualization studio. Enable the overlay option and it works fantastically. I'm certain they aren't actually rendering in UYVY or whatever. Somehow, it has to be possible to blit an RGB565 image to a UYVY overlay surface and have the hardware do the conversion for you, but damned if I can figure out how to do so :( Failing all of that, it would at least be nice if there were a way to prevent other always on top apps from screwing with your fullscreen mode DD / D3D video modes without being forced to redraw 100% of the screen every single page flip. The lack of code / documentation on the internet for RGB<>UYVY conversion, or just using overlays in general is astounding. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jun 02, 2006 12:18 am Post subject: | |
|
|
|
| Nice try on the ToP bug. Don't get too discouraged, I'm sure some of the others on the list are less psychotic. As for Rendering Render, perhaps your bus accurate APU core fixed it Battletoads, of course, is fixed (thx dmv), which leaves Earthworm Jim 2 (E) as the only known remaining sound issue. |
|
Regular
Joined: 30 Jul 2004
Posts: 229
| Posted: Fri Jun 02, 2006 12:47 am Post subject: | |
|
|
|
| Byuu, check into using VMR9(video mixing renderer 9). It is used by Media Player Classic(on Sourceforge), and allows it to operate like an overlay with no video mode switches, but it uses D3D. | |
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jun 05, 2006 3:29 am Post subject: | |
|
|
|
| byuu,if you need help with the overlay,you could ask Justin,the creator of Winamp himself He will probably help you. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jun 05, 2006 6:16 am Post subject: | |||
|
|
|||
|
Ok,
2 hours and 300mL of 80 proof vodka later ... got the CPU core
rewritten and created a working implementation using libco (called
sCPU). So far, it only emulates the main CPU and has the most generic
h/v counters possible (1364/scanline, 262/frame, nothing more). No
(H)DMA, no NMI/IRQ, no WAI (o rly?), no MMIO and really nothing else. So, it's enough to run a quick demo that sets the BG color and hangs. Gets 135 fps, compared to 120 fps with the old core. So, probably going to end up with a slowdown with the new CPU core, too. Damn. At least I can make opcode-based cores for slow computers (an emulator with some accuracy is better than no emulator at all, right?). And no worries, the old bAPU + bCPU pair is there as well. From here on, I plan to just rebuild the CPU core piece by piece, little by little. Maybe I can come up with some new tricks for NMI / IRQ trigger detection and such to speed things up, who knows. So yeah, first emulator to support true bus accuracy for both the CPU and APU cores, ftw. Now I just need to release it before Overload or TRAC catch up :)
I strongly doubt I'm that well revered in the programming world to ask someone of his stature for help. |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Jun 05, 2006 10:35 am Post subject: | |||||
|
|
|||||
lol asking justin frankel about video overlays. let's see, most of those videos will definitely be YUV, and probably color key (some hardware even requires this, I think). Oh, and lol holding him in high regard. Yeah, I suppose he was the king of hacks. Now he's the king of selling his shit out, and now a minimal gang of idiots maintain it and fix critical bugs. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jun 05, 2006 2:11 pm Post subject: | |||||||
|
|
|||||||
I try and be polite :)
Have you seen the AVS? They're not really videos (more like cheap math tricks that look cool when you're anything but sober), and the overlay output looks identical to the RGB standard output. So either they have working RGB->UYVY conversion, or they have a trick to blit RGB surfaces to overlays and let the hardware do the conversion for them.
And bundle his software with as much AOL adware as possible, but even still. My point was that someone of his popularity would not waste their time talking to relative nobodies in the programming world, let alone help them. Hell, I wouldn't help someone who e-mailed me out of the blue asking for help on a subject almost completely unrelated to what I am known for. |
|||||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jun 05, 2006 2:46 pm Post subject: | |
|
|
|
| kode & byuu: He doesn't develop Winamp anymore.He quit his job at AOL a long time ago.Now he does this: http://www.reaper.fm and his previous projects: http://www.cockos.com/ He's still the king (not of hacks,lol). |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Jun 06, 2006 4:16 am Post subject: | |||
|
|
|||
I like the way you work. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jun 06, 2006 4:56 am Post subject: | |
|
|
|
| Finlandia Lime, if you're interested. Tastes like lime kool-aid. | |
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Tue Jun 06, 2006 5:20 am Post subject: | |||
|
|
|||
Yuck. Personally, I hate lime kool-aid. Now if it came in an orange flavor, I'd drink it. |
|||
Devil's Advocate
Joined: 02 Aug 2004
Posts: 3321
Location: Hillo. Son. Mx.
| Posted: Tue Jun 06, 2006 5:44 am Post subject: | |||
|
|
|||
My father bought me a bottle when I graduated from Junior High School. Although it was the regular one. Good Stuff. Now carry on with your thread.. I can't contribute even if my life depended on it. _________________ *Sometimes I edit my posts just to correct mistakes. I DON'T PLAY ON NETPLAY, DON'T ADD ME TO YOUR MSN TO ASK ME STUFF, I JUST PLAY ON MY LAN, HAVE A QUESTION? ASK ON THE BOARD. |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Jun 06, 2006 10:41 am Post subject: | |
|
|
|
| AVS does not appear to use overlays. Or at least, not on my system. Maybe that lack of RGB overlay support is preventing it. I know when something is using overlays, such as Media Player Classic forced to use the overlay mixer for output, PrintScreen grabs a big empty colorkey nothing. Not so with AVS in a window, and I doubt it would matter much what it uses fullscreen. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jun 06, 2006 3:20 pm Post subject: | |
|
|
|
| Winamp AVS Editor->Settings->Fullscreen->Use fullscreen overlay mode (current bpp is used) I know it is using an overlay on my system. And I want the overlay support for fullscreen. Why? Because non-fullscreen causes other always-on-top windows to flicker on top of my emulator on occasion. Plus the automatic monitor redirection most video card drivers have for dual head displays would be a nice copout for true multi-monitor awareness. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jun 07, 2006 8:45 am Post subject: | |||
|
|
|||
|
Horray!
While working on the CPU core rewrite, I stumbled across a rather
obvious HDMA bug in mmio_w420c() that fixes (most likely) about half of
all known bsnes bugs! At least, it fixes three of the five bugged games
I have copies of. I'm sure it fixes many more, too. No wonder I couldn't find this bug... No more epilepsy vision! Hooray, the HDMA code is in fact hardware-accurate after all! GIGO's assumption that this bug was a result of my HDMA line counter loading code was in fact incorrect.
|
|||
Rookie
Joined: 04 Jun 2006
Posts: 24
Location: kansas
| Posted: Wed Jun 07, 2006 2:22 pm Post subject: | |||||||
|
|
|||||||
I didn't mean to push this awesome achievement off the page...
Byuu vs Bugs Byuu=Winnar!
[edit] Wrong account...doh! |
|||||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed Jun 07, 2006 3:55 pm Post subject: | |
|
|
|
| Wow, nice catch. Good work byuu! |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jun 07, 2006 4:58 pm Post subject: Re: bsnes thread (v.016 & updated buglist) | |
|
|
|
| Awesome!!! Edited buglist to reflect your findings. | |
16-bit Corpse | Nyoron
Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
| Posted: Wed Jun 07, 2006 5:04 pm Post subject: | |
|
|
|
| Wht exactly was wrong with these games before the bugfix? _________________ My site with random stuff whicker: franpa is grammatically correct, and he still gets ripped on? sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Wed Jun 07, 2006 5:29 pm Post subject: | |
|
|
|
| According to byuu's post that Ichinisan quoted, it was something to do with HDMA. or so that's what I gathered. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jun 07, 2006 5:30 pm Post subject: | |
|
|
|
| Graphical stuff. In ToP, a background behind the trees would turn purple instead of green. In Mortal Kombat, the screen would start showing static and flipping out during battles. In GR, I dunno. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jun 07, 2006 5:41 pm Post subject: | |
|
|
|
| I said what the problem was under each screenshot. GR was corrupting the bottom statusbox when text would appear onscreen. Eh, numbers aren't looking as good anymore. This doesn't fix SoM's intro, JP2 intro, RPM racing tracks nor EWJ2's audio. So that's three fixes to four nonfixes. Still, there's plenty of other games and surely this fixes at least one more of the bugs. I hope. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jun 07, 2006 6:19 pm Post subject: | |
|
|
|
| I think Accele Brid and Death Brade are prime candidates for a checkup. The important thing is, even if it isn't fixing a bunch more on the list, the fixes that have been made thus far haven't been breaking other things. So accuracy is actually improving, not just shifting around. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jun 07, 2006 8:23 pm Post subject: | |||
|
|
|||
Exactly. It's possible that I might fix something which breaks something else by understanding the matter incorrectly. But given I'm willing to spend as much time as needed, to implement even the tiniest hardware quirk I know about, even if it means rewriting the entire emulator in the process (and I've done this multiple times); the accuracy will only continue to improve. And eventually, we'll be able to run every last known game, with zero game-specific hacks :) Either that, or I'll burn out and hopefully other emulator authors will follow and reach this goal one day. The good news is that all of my fixes thus far have been simple oversights. It's a strong sign that the actual cores, eg the really important parts, are mostly correct. EDIT :  Ignore the version number, it's my work build that's behind my home build. No idea what fixed it, probably the same thing that fixed the lockups in Rendering Ranger R2. Seems to get a lot further (it did not lock up at all on me). I'd like someone who can actually play the game to verify it's fixed. Along with other bugs such as Rendering Ranger R2, etc. The lockup issues in games seems to be mostly resolved overall, though. Excepting the IRQ not firing issues, of course. Deathbrade still does the same thing. That's a pretty hillarious bug, actually. "Ready? Set? TIME OVER, YOU LOSE!" Heh, consider that one a "feature" :) Hmm, going into the options screen shows the counter starts at 00, and you can change it and get time to play the game with. The bug still needs to be fixed, of course. Probably an invalid memory read somewhere. And as for the game itself, are you actually supposed to be able to do anything in it, or is the game basically just to get grabbed by the opponent and thrown. And then have the opponent walk on top of you when you're on the ground and repeat the process over and over until you're dead? There's not many fighters where my first ever round ends without me damaging the opponent at all. Hmm... |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jun 07, 2006 11:11 pm Post subject: | |
|
|
|
| Both
games are pretty awful in terms of gameplay. Although, for Death Brade,
you can tell it's going to suck from the moment it starts. Good to hear that Accele Brid appears to work now. It would hang about 7 seconds into gameplay. If you got farther than that and noticed nothing odd, there's a good chance it's also fixed. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 08, 2006 12:37 am Post subject: | |
|
|
|
| Looks like I was a bit overzealous with the HDMA fix. Bugs Bunny - Rabbit Rampage (E, U, J) - gfx tile issue during gameplay - Still there BETA Corn Buster (NL) - intro gfx garbled, sound issues, hangs during gameplay - Still there, great test ROM with immediate problem to look at BETA Killer Instinct () - fails to play - Didn't test Chou Aniki - Bakuretsu Rantou Hen (J) - fails to play - Refuse to test :P Death Brade (J) - fight ends as it starts - Still there Derby Stallion 96 (J) - fails to play - Didn't test Earthworm Jim 2 (E) - sound issues (U region does not exhibit) - Still there Hungry Dinosaurs (E) - small gfx issue on transition change - VERY subtle, I think it's still there. It looks the same as v0.016 Jurassic Park II (E, U) - hangs after ocean logo is allowed to play. - Still there Mighty Morphin Power Rangers - The Movie (E, U) - garbled/missing sprites - Still there. Odd one, looks like sprite wrapping problem, but thats not the case as I've verified my sprite wrapping is very accurate with lots of complex test ROMs :/ Has to be something else, most likely. Power Drive (E) - letters garbled at namescreen, can't drive car - Still there Radical Psycho Machine Racing (U) - track draw issues (J region does not exhibit) - Still there Secret of Mana (E, Fr, G, J, U) - mode7 overworld issues - Still there (MAYBE a color add/sub bug? an odd one for sure) Super Conflict (E, U) - small gfx issue on title screen - Still there, not much hope on this one. Both me and Overload are stuck on this one. Wild Guns (E, J, U) - hangs before level starts - Still there, not much hope on this one either. NMI+DMA timing required, no idea how ZSNES9x play this game. World Class Rugby (E) - garbled gfx during gameplay - Can't even get in-game on either v0.016 or v0.016.17. The game completely dies before starting. --- I'm kind of interested to know what my compatibility rate is at this point. Also, I forgot. Are we not listing special chip game bugs because they could be bugs in the special chips and not the core emulation itself? I'm honestly not sure where the two small problems in MMX2 come from. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jun 08, 2006 1:01 am Post subject: | |
|
|
|
| Aerdan had that Mega Man bug on his list, but I never noticed anything odd when I played it, so I didn't list it. I don't really know what it is. Anyone care to post screenshots and describe the problem? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 08, 2006 1:29 am Post subject: | |
|
|
|
| There's
two problems. The first one is during the opening stage. When you get
past the three things in the start, you go down and there's a rail line
that's assembling these flying robot things. However, the robots start
off fully assembled, rather than being pieced together at each "stop"
on the rail. Hard to explain, you'd have to see it in ZSNES to follow
it. Second, the alligator stage has some graphical corruption on the swap / poison / lava / whatever the hell liquid stuff it is. I don't know if this one has been fixed. I haven't played that far into the game since I first saw it when Nach and I first added C4 support. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Jun 08, 2006 2:54 am Post subject: | |||||||
|
|
|||||||
Perhaps the odds side is throwing off your memory mapping? A quick "nsrt -pad" should be good enough to see if that's your problem.
And which is this? Could be it's a bad ROM.
Requires special memory map. This game uses special BS-X carts. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 08, 2006 3:28 am Post subject: | |||||
|
|
|||||
Yep, that would be the problem. Thank you, Nach :) What the hell kind of size is 15mbit? Does the cart really have 8+4+2+1mb ROM chips, or is Cowering just being a dumbass as always?
Ah, I'll probably count it off to the side then along with Y's III SRAM, until I get in a CRC32 ROM database and custom cart mappers. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jun 08, 2006 6:01 am Post subject: | |
|
|
|
| K, I've added MMX2. As for the BETA Killer Instinct rom, it's in the NSRT database and it works in zsnes, so I'm thinking it's a bug. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 08, 2006 7:01 am Post subject: | |
|
|
|
| You can nuke Corn Buster, if you like. Padding to 16mb solves all three issues. Interesting game. Stupid, but interesting. Fascinating. Before writing an SNES emulator, I never realized just how many truly awful games there really were for this platform. Lucky me ;) I'll take care of this and other odd ROM sizes by allocating blank memory up on the "second" chip. Getting tired of this hacking around memory mapping issues, though. Need to get started on that mapper database already. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Thu Jun 08, 2006 8:55 am Post subject: | |||
|
|
|||
Errr...ya,agree. Not that I'm thinking about another (very well known) Snes emulator or anything like that...but I should just shut up at this point. Anyway,nice work to byuu for finding out what was wrong, even if was a simple oversight. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Jun 08, 2006 1:57 pm Post subject: | |||
|
|
|||
Is there any way i can help you getting the database together |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 08, 2006 3:17 pm Post subject: | |
|
|
|
| Sure, buy every SNES game ever made and submit the PCB strings to Overload and myself ;) | |
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Thu Jun 08, 2006 4:11 pm Post subject: | |||
|
|
|||
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jun 08, 2006 6:07 pm Post subject: | |||
|
|
|||
Killer Instinct (Beta) problem :
Header detection is failing. I think I'll start outputting the scoring info to make debugging these problems easier. The game still has some graphical glitches (ones ZSNES doesn't have) and the real KI has some in battles still. Again, ZSNES doesn't have these. I might as well test all the "doesn't load" games for header detection problems. Well, that leaves the worst game ever made (Aniki) and the dumbest (Derby Stallion 96). The former is getting stuck waiting for an NMI to trigger that never does (haven't bothered to research why, rewriting the NMI / IRQ stuff for the new CPU core anyway, same thing with Jurassic Park 2), the latter needs BS-X mapping stuff, even though it's an actual cartridge (I know, it has a slot for BS-X memory carts on the top, I've owned the cartridge in the past). Also, you might want to add Uniracers, which needs a hack or something nobody knows how to emulate (mid-frame OAM address writes require PPU emulation to update the address as it processes, but we don't know how this address gets incremented by hardware just yet). |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jun 08, 2006 9:34 pm Post subject: | |
|
|
|
| K, I added Killer Instict, Uniracers, and Ys III. | |
New Member
Joined: 19 Jun 2006
Posts: 1
| Posted: Mon Jun 19, 2006 10:53 pm Post subject: | |||
|
|
|||
I actually implemented overlay support on linux for fceu and found the performance benefits to be significant. I was lucky enough to develop on a box that supports RGB overlays (this made development easier); without overlay support the CPU was pegged when drawing at 3x scale, and with it the CPU sat at a nice 20%. I ported the code to a box that supports only YV12 overlays and found performance wasn't that much better than without overlays, until I pre-calculated the RGB-to-YUV conversions (one nice thing about 8-bit graphics is your color lookup tables stay small). I was able to get fullscreen 640x480 at 30fps with overlay support, whereas I couldn't get half that before the changes. I'd rather run at 320x240 and get a higher framerate, but the linux X drivers don't support 320x240 on my epia when I'm using TV out (oddly this does work on windows, iirc). As for whether overlays would have benefit an snes emulator, pre-calculating the YUV conversions might work, but I suspect that might also have negative implications for cache performance. The only way to know is to try, and I think it's at least worth a shot. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jun 20, 2006 12:06 am Post subject: | |
|
|
|
| I cache BGR->RGB transformations already. While I could do this prior, I'd then have to hardcode RGB555<>RGB565<>RGB888 transformations directly into the PPU core rendering routines, and I'm willing to sacrifice speed to isolate all components of base emulation from the platform-specific implementations. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jun 26, 2006 9:03 am Post subject: | |
|
|
|
| My webserver won't let me upload files without instantly terminating the connection so I can't update my site. So I'll just post here for anyone who cares. I have most of sCPU working now. Sadly, I simply can't find any ways to improve the way add_cycles() and poll_interrupts() work, so it's pretty much just going to be implemented the exact same way. I have NMI, IRQ and WAI support in there now, and most games run fine. But all of the really intensive ROMs (my NMI and IRQ timing tests, EWJ2 sound effects, ToP vocals) fail still. Just need to track down the differences between the two (bCPU and sCPU) to find out what's going on. It'll probably be another week or two, but then sCPU should be ready excepting perfect DMA+HDMA timing (it'll be within 6 clock cycles of accuracy). Oh well, nice to see this cothreading idea is most likely going to work, and at least the CPU core is cleaner. But all of the more important timing stuff (interrupts, H/DMA sync timing, etc) are going to be just as ugly as ever. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Mon Jun 26, 2006 10:50 pm Post subject: | |
|
|
|
| Good work man, thanks for the update. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jun 27, 2006 7:35 am Post subject: | |
|
|
|
| Mmm, can't wait for sCPU. If it ends up being more accurate and as fast/faster, I take it you plan to drop bcpu entirely? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jun 27, 2006 8:46 am Post subject: | |
|
|
|
| Not anytime soon. It's the only way to compile on PPC Macs, for one. Or really, any non-x86 architecture. Since it's faster than bCPU anyway, and "twice" as accurate between CPU<>APU communications (or more accurately, as accurate as is necessary for 100% accuracy), I don't see any reason not to replace bCPU with something like an opcode-based core that runs for speed and has savestates and all that jazz sometime far into the future. The real question is how to go between the two. Enabling polymorphism (the ability to switch between bCPU and sCPU during runtime) takes a 10% speedhit. And I really don't feel like making separate builds for all the different compile-time options and core combinations. Then more for with and without debugger. Etc, etc. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 06, 2006 1:53 pm Post subject: | |
|
|
|
| Alright,
I can upload to my site again. sCPU is completed. Runs all the fun
stuff fine. My exact clock position timing tests, ToP, EWJ2, etc, and
passes the infamous electronics test. Any, quick question. Nach brought up an interesting point the other day on IRC about bsnes' memory usage. I haven't really been paying attention to it and it has nearly doubled since v0.013. It has gone up because I've been adding more memory lookup tables to speed things up. I figure, bsnes already requires a powerful PC, so I might as well equalize RAM requirements vs CPU requirements. But would you guys prefer speed or RAM conservation? For about a 5-10% speed hit, I can cut the RAM usage back in half again. Right now, it needs up to 22mb for the largest 6mb ROMs to run, and 13mb for the smallest. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 06, 2006 2:17 pm Post subject: | |
|
|
|
| Pff. 20mb is nothing. I'll take the speed. Good job on sCPU btw. |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Thu Jul 06, 2006 2:28 pm Post subject: | |
|
|
|
| Firefox
can easily sop up 90+MB of RAM, and people frequently have a web
browser running at the same time as other programs (Word Processing,
Solitaire, whatever). None of which are really thought of as being
terribly intensive tasks. So I agree with FitzRoy - 20MB is nothing. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Jul 06, 2006 6:17 pm Post subject: | |||
|
|
|||
|
You can start to worry when it hits 200 MB. _________________ savestate editor: vSNES latest public version
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 06, 2006 6:48 pm Post subject: | |
|
|
|
| I doubt (read: hope) it will never need more than 64mb, unless I decide to get really extravagent. So ok then, I won't worry about it so much. And now Nach is advising his concerns are over memory leaks and not memory usage. I don't see any active leaks, in that I can load and unload games, and play them for several hours without the memory usage going up any, but apparently Valgrind goes crazy when you run bsnes in it. I'm guessing it's all stuff that's only called at program start/exit, such as the configuration file parser. The actual emulation code is pretty good about not allocating memory except when absolutely needed. I'll either need someone to give me Valgrind logs so I can fix the problems, or install Linux one of these years and do it myself :/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 06, 2006 7:13 pm Post subject: | |
|
|
|
| Linux, eh? Cat out of the bag? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jul 08, 2006 9:12 am Post subject: | |
|
|
|
| New news has nothing to do with Linux. Some really good news though that I'd like to share: I was messing around with some #defines to swap between the CPU and APU cores. I made a FAVOR_ACCURACY / FAVOR_SPEED switch. The difference is that FAVOR_ACCURACY will sync in between each opcode cycle for both the CPU and the APU. Whereas FAVOR_SPEED will sync between each opcode. However, I was thinking about it... right now I have a CPU, APU and PPU that runs the system. There's no need to sync against the memory bus as the processors emulate bus hold times themselves. And right now, the PPU is a scanline-based renderer, meaning bus accuracy does it absolutely no good whatsoever. So really, all I need to do to get the same degree of CPU<>APU communication accuracy is to call co_return() when polling the CPU<>APU bridge ports ($2140-$217f<>$f4-$f7) -- similarly, CPU<>PPU syncs with a dot based renderer could be done by syncing on CPU accesses to $2100-$213f (shared bridge). This way, the communication between these two is now bus-accurate, which is as accurate as I can possibly imagine code being. However, all of the stuff that isn't visible outside the respective core now runs as if it were an opcode based core. So the true magic of sCPU and sAPU show off now. The result? [ FAVOR_ACCURACY ] DL title: 101fps Zelda 3 save select: 80fps [ FAVOR_SPEED ] DL title: 120fps Zelda 3 save select: 96fps [ FAVOR_SPEED + PGO - debugger ] DL title: 174fps Zelda 3 save select: 137fps Hmm, 75% faster than a straight build of bsnes v0.016. Impressive enough for you? :) Of course the official v0.016 has PGO enabled, so this is really only ~20-25% faster than the last release. Now, the question is... should I distribute release builds using FAVOR_ACCURACY, or FAVOR_SPEED? Please keep in mind, the two perform identical to every last little bit / clock. The input and output is 100% bit-identical, as can be compared by logging APU data and checking PPU latch counter positions. However, there's a 20% speed boost for FAVOR_SPEED. There's another advantage, too. By lowering the CPU and APU requirements by so much, the bottleneck is shifted far more towards the PPU. This means frameskip becomes much more effective. For example, FAVOR_ACCURACY from frameskip 0 to 9 results in a ~62.5% speedup. FAVOR_SPEED from frameskip 0 to 9 results in a ~87.5% speedup. Meaning with the simple mode3 DL title screen, I can push a blistering 324fps on a 3500+ with maxed out optimizations, and no accuracy loss! And in case you think I'm exaggerating... Frameskip = 0 Frameskip = 9 |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sat Jul 08, 2006 10:12 am Post subject: | |||
|
|
|||
|
Awesome news! So FAVOR_ACCURACY is not needed any more? Or are there still cases left where it is required? _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jul 08, 2006 10:25 am Post subject: | |
|
|
|
| It's nice to guess wrong this time. That's plain AMAZING! This should get a lot more people playing full 50/60fps. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jul 08, 2006 11:11 am Post subject: | |||||
|
|
|||||
Technically, no, it isn't. I want to leave it as a compile-time option. It will be useful for seeing CPU<>APU intermixing when debugging code. Technically, the current code could execute the opcode cycles out of order. But it doesn't matter since accesses between each other are synced to bus accuracy still. Which is pretty much as accurate as is possible through emulation, so there's zero room for timing/accuracy improvements over the CPU<>APU bridge at this point. It is technically impossible for the actual bytes transferred across the CPU<>APU bridge to differ between these two implementations. And thusly, the user experience is 100% identical. I played the entire ToP intro in both modes and hex compared the PCM dumps of each. Bit-perfect match. Now, the thing is... by not truly running them in perfect parallelism, it deviates from the true SNES hardware... the inputs and outputs are identical, but they aren't truly being emulated as parallel tasks, but rather as slaves to each other, running until they need input from the other. So, that's why I wanted to know what everyone would prefer me to use as the default when I compile new public release builds. The truly pedantic could argue this differs from my stated academic programming approach to the emulator. grinvader and Bisqwit recommended the speed mode on IRC so far. Anyway, I'd like some beta testers for v0.017. I plan to make a release soon. I wanted to get that "news item" thing taken care of, but that ran into some snags, sadly, and I see no reason to hold things up any longer. Ideally, I want to release tomorrow. But maybe next week if I run short on time.
Agreed. I took a hell of a longshot in the dark with this whole cothreading thing from the beginning. I believe it's an emulation first. Lucky for me, it paid off in the end :D Heh, so I wonder if I can "persuade" some other emu authors to look at libco now. Twice the accuracy, 30% faster and way more readable code than a cycle-based core. I even have a trick for savestates now (which I won't be adding anytime soon to bsnes, so don't bug me about it :P ). |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jul 08, 2006 11:22 am Post subject: | |
|
|
|
| If the output is the same as an snes, then I would consider that an optimization. It's a good one, too. You can always make a note of real hardware discrepencies, but for releases people are going to take the speed if it comes at no cost of accuracy. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sat Jul 08, 2006 11:53 am Post subject: | |||||
|
|
|||||
If someone is pedantic enough to insist on theoretic aspects that have no effect on the final quality... then they're probably nerdy enough to compile the source by themselves with the changed #defines. _________________ savestate editor: vSNES latest public version
|
|||||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Jul 08, 2006 4:11 pm Post subject: | |
|
|
|
| Wow
this is awesome news. Personally, I think it should be FAVOR_SPEED
that's used. Gee, I can't wait to let this new version rip on my
system. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 09, 2006 1:38 am Post subject: | |||||
|
|
|||||
|
Here's a WIP to try out, it's 20-40% slower than it should be, due to PGO crashing the compiler*. Please copy and paste link, and do not post this on emulation news sites or I will remove the file. byuu.org/files/bsnes_v016_wip27.zip Even though it's slower, could I get some people to try running through a bunch of games and look for new bugs? Given I rewrote the entire CPU+APU, it's possible some new bugs crept in. * No release this weekend. Please be sure to thank Microsoft personally for the delay.
What is on sapu\core\core.cpp(16) that's too complex for Visual c++ to handle?
Please, if anyone can simplify that for me, let me know. Seriously, though, if anyone can take a look at the source and fix this compiler error I'd really appreciate it, and I'll get a release out this weekend. I'm using Visual C++ 2005 Professional. Otherwise I'll have to set it aside because I don't have time. |
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Jul 09, 2006 2:30 am Post subject: | |||||||||
|
|
|||||||||
I understand that the actual emulation would not be more accurate with FAVOR_ACCURACY enabled ( clearly,you took the time to explain this in a way that even the thickest of us would understand ) but like you said the Snes hardware technically didn't ran this way (even if the end result is unaffected)FAVOR_SPEED is probably a better default option for most I guess, but at least I hope you'll always keep Favor_accuracy in the source code...ya know, for us pedantic folks lol Anyway, I'm going to test wip27 right now!
Last edited by Dmog on Sun Jul 09, 2006 2:47 am; edited 1 time in total |
|||||||||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sun Jul 09, 2006 2:48 am Post subject: | |
|
|
|
| I
found a quick bug. The scrolling text at the beginning of Memblers nsf
player is all messed up. Though I guess it's kind of iffy since I don't
know what it looks like on the real hardware. bsnes v0.016 27  bsnes v0.016  Edit: Battle toads and double dragon seem to have a similer problem.   |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Jul 09, 2006 3:20 am Post subject: | |
|
|
|
| Secret of Mana Mode 7 overworld looks correct now. _________________ FF4 research never ends for me. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 09, 2006 4:11 am Post subject: Re: bsnes thread (v.016 & updated buglist) | |
|
|
|
| Ok,
went through the list on the new core version. Several bugs are now
fixed. Secret of Mana bug is gone, Jurassic Park II no longer hangs,
Mighty Morphin Power Rangers - The Movie gfx are now unscrambled, and
Wild Guns now gets ingame, but the gfx are screwed up. As for new bugs: Battletoads bug confirmed on both regions. Also, high-res/interlace/whatever the hell it's called doesn't look right anymore. Just go through the starting menus on RPM Racing to see what I mean. DSP1 is now supported, but not completely just yet, so I'll leave that as is. I also noticed the infamous fitzroy exclusive sound crackling bug has resurfaced where it wasn't on 016 official. I want to wait before PGO optimizations are in before I officially complain about this one. PS: You said to nix Corn Buster from the list, but it's still exhibiting the same stuff as before. What's the status on this one? Also, something new I just noticed. Should frameskip settings be saved on emulator exit? Because right now, they're not. |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Sun Jul 09, 2006 5:46 am Post subject: | |
|
|
|
| Looks good but I get lots of graphical corruption in KI whenever the player sprites move. I can also verify the Battletoads bug. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 09, 2006 8:13 am Post subject: | |
|
|
|
| I'll
look into NSF + Battletoads and compare them against bCPU. It's either
the recent HDMA fix or the replacement CPU core. Damn, I was hoping
bsnes wouldn't end up reverting working games to broken status :( I guess that's what happens when you rewrite the entire core. Yay, three bugs gone! Wild Guns I know about. HDMA sync delay timing is what breaks it completely. It can be fixed by swapping the order of two opcodes, but I'm not willing to do that, so... oh well. I don't know what's up with sound crackling. I've sort of noticed it myself, but the sound output code hasn't changed. RPM racing looks fine to me. All hires+interlace games do. I'm not sure what you mean. Corn Buster and KI beta need some memory map tricks. I'm waiting until I add all of the "true" memory mappers before I fix them properly. In the mean time my fix was to just pad the games to their proper size. They're very likely underdumped simply because the end of the ROM was all 00s. DSP-1 was the "surprise", but as you can see, there's a bug with sprites not displaying. KI graphics bug is already known and on the bug list. Thanks for verifying Battletoads. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 09, 2006 9:10 am Post subject: | |
|
|
|
| Oops.
Ok, for the hires/int thing... I had frameskipping on, and that was
screwing up the gfx in RPM Racing. Is that normal behavior for these
types of games? And regarding DSP1: if you didn't know, it seems to go beyond sprites not showing up. Ace wo Nerae! for example, hangs at start. Might be unrelated to chip support, though. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 09, 2006 9:34 am Post subject: | |
|
|
|
| Ok,
I tried converting the switch/case table to a jump table for both
CPU+APU cores. Results? EXE is 70kb larger, compile time is 5-10%
slower, and speed is identical. Needless to say I reverted that change
back. I then tried narrowing down the cause of the PGO error. Found out
it was Dai Kaijuu Monogatari. If I don't run that, I can build with
PGO. Unfortunately, this is the ROM I use to stress optimize color
add/sub. So as a result, this game will run a little slowly now (sort
of like how Chrono Trigger's OPT title screen effects were before).
But, better one game than all, right? byuu.org/files/bsnes_v016_wip27a.zip Once again, please do not submit news about this to an emulation site. The file will be removed if I notice anyone mentioning it anywhere. That will be 20-25% faster than wip27, but otherwise everything is identical. DSP1: there's either a bug in op02, op06, or in the getSr/getDr/setDr functions. We have so far been unable to spot the error and correct it. Help is always welcome, as always. Please consider DSP-1 support as not being there at all. I doubt any games will work right with it right now :( This is how interlace works : I call each frame a "field", meaning even or odd fields on your television / monitor. When interlace is off, I draw to the even fields every time, so you don't notice anything. However, when interlace is on, I alternate between which one I draw to each field. So depending on your frameskip, this can cause serious problems for interlace mode. I also only physically draw to "half" the resolution each field, much like a real TV would. This makes 512x448 mode just as fast as 512x224 mode. I can't think of an easy way to cheat the system with frameskipping. Luckily, very very few games use interlace at all. Most use hires 512x224 and that's it. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 09, 2006 10:37 am Post subject: | |
|
|
|
| I
suspected that was normal behavior with skipping frames on interlaced
games. Thus the oops. I've only a basic understanding of
interlace/progressive, but thanks for explaining it better. Better to
ask though and be certain it wasn't a bug or anything... The sound crackling every 10 second interval thing is still there for this version. I'm going to see if I can test it on my friend's computer tomorrow. He has a different sound card than me. I'm at the lowest latency setting on my card (48 sample) and setting it higher only makes it worse. Are you guys certain you aren't getting this stuff on your comps? Did Kode54 do something inaccurate, like drop a frame in order to fix this, that you weren't willing to impliment? I recall that on his build, every sample setting worked on my setup. Maybe we can compromise with an option or something. I really don't want to downgrade my sound card |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sun Jul 09, 2006 11:17 am Post subject: | |
|
|
|
| Sorry in advance as I haven't followed the conversation, but is Super Mario Kart supposed to have so many sprites missing ? In fact, you can only see your own driver... | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Jul 09, 2006 1:00 pm Post subject: | |||
|
|
|||
|
stifu: Read byuu's last post; SMK is a DSP1 game. <offtopic> re: http://byuu.cinnamonpirate.com/images/bs_225.png Is "englisch version" the real original spelling? Because the proper german form would be "englische version". </offtopic> _________________ savestate editor: vSNES latest public version
|
|||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sun Jul 09, 2006 2:29 pm Post subject: | |||
|
|
|||
Heh okay, I didn't realize. I'm not very familiar with chip names either, although I knew SMK used a special chip, I had forgotten it was the DSP1... |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 2:06 am Post subject: | |
|
|
|
| Latest bsnes 016.27a WIP testing report and some questions: - All Donkey Kong Country games are broken,only the top half or quarter screen is visible. - Black Screen in Killer Instinct battles - SNES Test Cartridge Electronics test - FAILED! when Frameskip is enabled,otherwise it passes - The Screen Width and Screen Refresh are swapped (mixed up) in the Options Menu - Why there's no "Pause when Inactive" option? Even if the emu is minimized to taskbar,it still runs - Why there's no "sleep" (use less CPU) option? It uses 100% CPU all the time and makes the OS extremely sluggish while bsnes is running (even if I need only 1/3 of that 100% CPU time to get 60fps) - Is bsnes using the latest version of the NTSC filter? (because it's *much* more CPU intensive than HQ2x,but I don't notice such a slowdown with the newer versions of NEStopia or ZSNES WIP) - Why there's no TURBO button in bsnes,just for skipping long intros while testing? - I would like to see a mode that downgrades 60fps(Hz) NTSC-U / J games to 50Hz(fps),so I can simulate the NTSC-to-PAL converter I use in my PAL SNES.It slows down 60fps NTSC games to 50fps. - Sound pops for me only when framerate drops below 60fps (at 32kHz/100% speed setting) At 60fps sound is OK. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 2:10 am Post subject: | |
|
|
|
| I'll do even more testing later. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 10, 2006 3:07 am Post subject: | |
|
|
|
| - All Donkey Kong Country games are broken,only the top half or quarter screen is visible. Same bug as Battletoads. Ok, this has to be fixed before a new release. - Black Screen in Killer Instinct battles Odd. - SNES Test Cartridge Electronics test - FAILED! when Frameskip is enabled,otherwise it passes Very odd. Nice catch. - The Screen Width and Screen Refresh are swapped (mixed up) in the Options Menu I don't seem to have a problem there... will double check code though. - Why there's no "Pause when Inactive" option? Even if the emu is minimized to taskbar,it still runs I added it as "f12" to pause. "f11" is fullscreen toggle. I like having bsnes run in the background, especially when I'm building PGO releases as the framerate is 5-15fps when I do that. I'll see about making it an option. - Why there's no "sleep" (use less CPU) option? It uses 100% CPU all the time and makes the OS extremely sluggish while bsnes is running (even if I need only 1/3 of that 100% CPU time to get 60fps) Because even if I add the tiniest micro sleep function when something is running at 180fps uncapped, the emulator will no longer run at 60fps and sound pops :( - Is bsnes using the latest version of the NTSC filter? (because it's *much* more CPU intensive than HQ2x,but I don't notice such a slowdown with the newer versions of NEStopia or ZSNES WIP) Yes. I don't know, maybe because HQ2x was optimized by blargg? - Why there's no TURBO button in bsnes,just for skipping long intros while testing? Use ctrl+ and ctrl- to adjust speed. I prefer it sticking like that so that I can play games like MMX2 I would otherwise be left out in the cold on. My reflexes aren't good enough anymore to beat games like that without slowing the games down :( - I would like to see a mode that downgrades 60fps(Hz) NTSC-U / J games to 50Hz(fps),so I can simulate the NTSC-to-PAL converter I use in my PAL SNES.It slows down 60fps NTSC games to 50fps. Well, you can change the region code in the ROM to do that. I can't think of any legitimate reasons for doing this. I will however see about adding "force" ROM load options in there somehow in the future. Thanks for the feedback. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 3:25 am Post subject: | |||
|
|
|||
I mean the values in the input boxes. There's now 0 in the screen width box and 480 in the refresh rate one. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jul 10, 2006 9:04 am Post subject: | |
|
|
|
| DKC's are RARE developed games. Battletoads in Battlemaniacs hasn't been mentioned and also has the issue. Killer Instinct is RARE. I checked Ken Griffey Jr for shits, but its problem free. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 10, 2006 2:26 pm Post subject: | |||||
|
|
|||||
Hmm, did you delete your old config file and replace it with the new one? I can't reproduce this problem... anyone else noticing this?
Indeed, they're both RARE games. Either way, the problem is now fixed. I moved the line render check code from cycle_edge() to opcode_edge() since it didn't require perfect time, and opcode_edge() was called less often. However, DMA+HDMA were only calling cycle_edge(), so DMA and HDMA were not rendering scanlines when they should have been. This is now corrected, with screenshots on my homepage. DKC1-3+both Battletoads should be safe to remove. The only problem left then that wasn't in v0.016 is that the SNES test program fails with frameskipping on. I wouldn't add that one to the bug list though, it's not a problem with the core emulation. I'll hopefully have a fix here for it soon anyway. bCPU+bAPU fail the test too, so compatibility appears to be the same between the two cores once again. But if anyone has a problem with not adding it, then feel free to stick it in the list anyway. |
|||||
Nestopia Developer
Joined: 05 Dec 2005
Posts: 24
| Posted: Mon Jul 10, 2006 4:11 pm Post subject: | |||||
|
|
|||||
Ah, the unreliable Sleep(). Had a few battles with that one too. The solution I came up with for my emulator was to maintain a variable that keeps record of how long it's safe to Sleep() without overflow. It starts at zero and increases in small doses until it stabilizes. In case it becomes greater than the full frame wait time, Sleep() gets skipped completely. Here's a simplified code example of how I do it:
I usually reset the threshold variables on each emulation pause. Oh, and another important step to make sure Sleep() has the best granularity is to call timeBeginPeriod( min_period ) before use, e.g app-startup, and timeEndPeriod( min_period ) when done. Have you tried that? |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 10, 2006 4:56 pm Post subject: | |
|
|
|
| Hmm,
didn't know about timeBegin/EndPeriod, thank you. It makes CPU usage
spike up quite a bit, but that's better than crackling sound. Doesn't appear to lose too much frames per second, but I can't fully test it since it's only called with speed regulation enabled. I don't have a calculation to tell how many ms I need to sleep for, I base it on the playback position of the DirectSound buffer. I suppose I could work something out to do that, but I'm happy just calling Sleep(1) for now. |
|
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Mon Jul 10, 2006 6:55 pm Post subject: | |||
|
|
|||
What seems to be the problem and what game(s) does it affect? |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 7:10 pm Post subject: | |
|
|
|
| I did some more testing today. It's not only the RARE games having this bug,but a good deal of other games are also affected. Here's some more issues and interesting bits I found: - Spectre (U) - black screen instead of the intro and the options menu is garbled. - Porno Manga (PD) doesn't work - Black screen Getting this rom working is sort of a requirement for any good SNES emulator, *LOL* - Rock'n'Roll Racing (U) - Music in the settings menu between races gets muted after a random number of races.Sometimes it even mutes at the character select before you start the first race! This also happens in ZSNES. - Realm (U) - This is interesting : the music in bsnes sounds *great* ,ZSNES has a problem of several sound channels cut/missing.They reappear only when shooting like mad Indeed,it was the old .cfg that was causing the problem: If you just overwrite the old .exe with the new WIP and keep the old config file,you get this issue If you delete the old config,there are no problems. Last edited by kick on Mon Jul 10, 2006 7:30 pm; edited 6 times in total |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 7:13 pm Post subject: | |
|
|
|
| Oh,I remember now: HDMA Fish Demo (PD) and HDMA demo (PD) also weren't working,so it's definitely an HDMA issue Last edited by kick on Mon Jul 10, 2006 7:16 pm; edited 3 times in total |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Jul 10, 2006 7:14 pm Post subject: | |||
|
|
|||
Yup...
timeBeginPeriod/timeEndPeriod... And if for whatever reason you feel
like checking the minimum supported resolution before setting it:
Oh yeah, and what about using DirectSound buffer position events and WaitForSingleObject instead of polling for the current buffer position? Of course, this only works reliably with software buffers. And then you'd size the whole buffer to N frames in length, and events on every frame interval. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 10, 2006 7:42 pm Post subject: | |||||||
|
|
|||||||
I don't know of any DSP-1 games that work properly. I only have Super Mario Kart, and the problem there is that no sprites ever show up other than your own character on the top half of the screen. No other sprites on the top or bottom.
Yeah, H/DMA should hopefully be fixed now. Don't know about rocknroll racing. Was this verified to not happen on real hardware?
Sounds way more complicated. Any serious advantages to doing things this way? |
|||||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 7:42 pm Post subject: | |||
|
|
|||
Wild Arms? Was there a Wild Arms game for the SNES? LOL Maybe it was some unreleased beta by SONY Imagesoft
|
|||
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Mon Jul 10, 2006 8:36 pm Post subject: | |||||
|
|
|||||
Super Mario Kart PAL doesn't start either. |
|||||
New Member
Joined: 20 Jan 2005
Posts: 3
| Posted: Mon Jul 10, 2006 8:59 pm Post subject: | |||
|
|
|||
I think he means Wild Guns. I don't know if it was already mentioned, but the following screenshot of Seiken Densetsu 3 doesn't look right.  The second screenshot was captured with ZSNES, where it looks correct.  Maybe there is something wrong with the hi-res rendering? |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Jul 10, 2006 9:02 pm Post subject: | |||||||||
|
|
|||||||||
For one thing, the process is suspended for the duration of the WaitForSingleObject call, until the buffer reaches one of the indicated positions. Or, if you specify a delay, it can also fail if the event was never signaled. VisualBoyAdvance already uses this method for its speed regulation. Anything which doesn't peg the CPU at 100% is better, especially for laptops, where that eats your battery faster and fries your nuts.
That would be the new pixel blending for high res modes, where every pixel along the scanline is blended 50% with the pixel to the left of it. The result is similar to a real video signal and display. |
|||||||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Jul 10, 2006 9:35 pm Post subject: | |||
|
|
|||
Not to mention getting BSODs when your CPU overheats in these hot summer days by running at 100% all the time,when you only need 1/3 of that 'juice' to get bsnes at full framerate anyway. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jul 10, 2006 10:45 pm Post subject: | |
|
|
|
| Yay, the wierd screen draw bugs are fixed. Thank you in advance kode54, if indeed your suggestions end up fixing my wierd sound crackling issues. And thanks kick for testing more games. I'll verify your other bugs with a new version, but I don't know what effects byuu's DKC fix might have. Find those bugs, people! |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Tue Jul 11, 2006 12:10 am Post subject: | |
|
|
|
| Say I'd like to compile bsnes with FAVOR_ACCURACY enabled.. what do I need installed? (running XP) And what command line need to be entered? | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Jul 11, 2006 6:38 am Post subject: | |||||
|
|
|||||
There might even be some games that use that feature. Jurassic Park 1 maybe (unless that's another effect), Kirby Superstar 3 (water?), ... _________________ savestate editor: vSNES latest public version
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jul 11, 2006 9:20 am Post subject: | |
|
|
|
| creaothceann has the 1000th thread reply! YOU WIN A NEW CAR! |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Jul 11, 2006 12:24 pm Post subject: | |||
|
|
|||
|
_________________ savestate editor: vSNES latest public version
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 11, 2006 3:28 pm Post subject: | |||||
|
|
|||||
This has actually been a bug from v0.015 onward, possibly even further back. When I separated PPU::render_scanline() from PPU::scanline() (to render a few dots into the scanline to fix some line flickering issues) and rewrote some OAM rendering stuff, I ended up causing the OAM RTO testing to only happen when the frame was not being skipped. So, this is now fixed. However, calculating the RTO status bits is expensive. I have to traverse all sprites on every scanline and do lots of calculations. As a result, frameskipping effectiveness drops from 70% speedup (at frameskip 9) to 42.5% ... a 27.5% loss. This only affects $213e reads. RTO sprite clipping still applies either way. The only known game that checks these bits is the SNES Test Program, and checking them really doesn't do a game a lot of good anyway. Further, one would fathom that nobody uses frameskipping unless they had to for the game to be playable. So I'm thinking I should add this to FAVOR_SPEED mode, and only calculate the RTO status flags *with frameskip on* when FAVOR_ACCURACY is defined. The flags would be calculated either way with frameskipping off. Anyone disagree with this?
They require it to display the effects correctly. Hires and Pseudo-hires blending work exactly the same way for both. It may not look as pretty in an emulator, but it's more technically correct. I may eventually make this an option, but it isn't a priority for me right now. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jul 11, 2006 9:39 pm Post subject: | |
|
|
|
| I agree with your logic. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Jul 12, 2006 6:59 am Post subject: | |||||
|
|
|||||
Take a look at the yellow flowers. I've always wondered why they have those darker pixels in them (see ZSNES' output), and thought that the rendering code might not be correct. Now it turns out that the devs used them to make those flowers a bit darker! _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 12, 2006 12:53 pm Post subject: | |||
|
|
|||
I sort of noticed this in EWJ2, myself. Nach pointed out that Super Bomberman 4 was hanging, and that turned out to be because I wasn't syncing the DSP with the APU on accesses to ($f0-$f3)+($f8-$ff). It's rather unbelievable that this is needed, since approximately eight APU opcodes execute between each DSP cycle, but whatever. After correcting this for SB4, I went back and played through EWJ2 again. I wasn't able to notice a single crackling sound after beating the entire first level, so I think this will resolve the issue for you as well. Let's see... I also added Marty's timeBeginPeriod / timeEndPeriod suggestion and made the emulator return unused CPU time back to the system, so if you get >60fps and enable speed regulation, the emulator won't eat 99% CPU time anymore. Modified frameskipping with FAVOR_ACCURACY to calculate RTO status flags even on unrendered frames. Takes a major speed hit, and is bypassed with FAVOR_SPEED defined instead. Started merging src/sdl and src/ui ports, while Nach has been helping create a unified Makefile. This should make compiling for other platforms far easier in the future. Let's hope someone steps up with some GTK+/QT wizardry once I'm finished so we can get a true UI into the Linux port. Added PLATFORM_, COMPILER_ and PROCESSOR_ defines that are specified by the makefile to control non-portable code usage inside the emulator. |
|||
New Member
Joined: 20 Jan 2005
Posts: 3
| Posted: Wed Jul 12, 2006 10:17 pm Post subject: | |||||
|
|
|||||
Thanks for your explanation. I don't think that an additional option is necessary. By the way, I found a bug that wasn't in v0.016. The game "R-Type III - The Third Lightning" freeze after a certain time, but it's dependent on which version of the game you're using. (E) (5711) after about 40 seconds (E) (21451) after about 100 seconds (U) [!] after about 35 seconds (J) after about 35 secons I tryed it several times with a clean config file, but the game freezed every time after the specified seconds. Can someone confirm this problem? |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 12, 2006 11:03 pm Post subject: | |
|
|
|
| I have confirmed your bug report jezze. And I've also confirmed that it does not happen in .016 official. As for the Rock N Roll Racing report earlier from kick: this is normal behavior for the game, I believe. There's not supposed to be any music between races. I've logged countless hours on this game as a kid on the real cart, so I'm pretty darn sure. Spectre (U): Seems to have been fixed. All the PD roms: god knows because I don't have any. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 12, 2006 11:20 pm Post subject: | |
|
|
|
| R-Type III confirmed. It never ends. It breaks when sCPU is used, but works with bCPU. FAVOR_ setting doesn't affect it. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 13, 2006 6:11 am Post subject: | |
|
|
|
| Found
a new bug for you. In Fatal Fury Special, a few of the characters have
scrambled gfx. Same on .016, so no worries there. (E) region seems to
not have the problem. (U) has 3 bad characters, (J) has 2/3 of the (U)
ones. ZSNES has similar problems, just not the same characters. What's funny is it has more, but not the 3 you have. Super Sleuth does not exhibit this in any region. Hope that helps. PS: Game is known as Garou-something in (J) region. |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Thu Jul 13, 2006 6:47 am Post subject: | |||
|
|
|||
Garou Densetsu Special... |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 13, 2006 3:02 pm Post subject: | |
|
|
|
| Wild Guns is fixed, and KI beta now loads. Should we merge the KI+KI beta bugs since they are basically the same game and suffer the exact same problem, or no? |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu Jul 13, 2006 4:37 pm Post subject: | |||
|
|
|||
Yes. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 13, 2006 6:46 pm Post subject: | |
|
|
|
| Done. And yay for Wild Guns. Fun ass game. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 13, 2006 7:28 pm Post subject: | |||
|
|
|||
|
Ok, DSP-1 works now. From http://users.tpg.com.au/advlink/dsp/dsp1.html
This indicates that the DSP-1 maps to: [00-1f]:[6000-7fff]. It does not, however, suggest that it also maps to [80-9f]:[6000-7fff]. I had assumed since most games worked 95% correctly that I had the mapping right. Ah well, I'm glad it's fixed now. You can remove DSP-1 from the list of unsupported chips now if you like. EDIT: here's a pic. Ignore the version number. 
|
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu Jul 13, 2006 9:53 pm Post subject: | |
|
|
|
| Good work man. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 13, 2006 10:10 pm Post subject: | |
|
|
|
| Hooray! I was hoping that would get in before .017. Well done. | |
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Thu Jul 13, 2006 11:07 pm Post subject: | |
|
|
|
| So all DSP-1 games work now? Some of them wouldn't work at all in WIP 27a. | |
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu Jul 13, 2006 11:13 pm Post subject: | |||
|
|
|||
I would have to assume so. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 13, 2006 11:22 pm Post subject: | |||
|
|
|||
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 13, 2006 11:41 pm Post subject: | |
|
|
|
| Oh my god, you got cow-mapping working?! What CAN'T you do? |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Thu Jul 13, 2006 11:46 pm Post subject: | |||||
|
|
|||||
Indeed.
|
|||||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Fri Jul 14, 2006 5:20 pm Post subject: | |||||
|
|
|||||
Technically, what I have is correct as address line A23 is not connected in Mode 21H. The decoder would never see an address higher than $7f:ffff. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 14, 2006 6:00 pm Post subject: | |
|
|
|
| HiROM
ignores A23? I thought LoROM ignored A23... hmm. Or maybe they both do,
and it's just ExHiROM and/or ExLoROM that use them. Well, might make a nice note to mention your addresses assume A23 is ignored for idiots like me :/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jul 15, 2006 8:48 am Post subject: | |||
|
|
|||
I've gone 5 minutes into all the dsp1 games and it does appear to be fully functional now. Byuu: The only oddity I came across was Super Mario Kart (E). There's a discrepency between bsnes and zsnes. While playing, zsnes enlargens the view area and displays more info on the top and bottom. I don't know which is right and which is wrong. What's wierder is that when you go to the menu in zsnes, it reverts back to the height that yours is. It's 256x224 vs 256x239. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jul 15, 2006 10:22 am Post subject: | |
|
|
|
| That's
overscan. In PAL mode, it really should show the extra lines, ZSNES is
correct. My overscan emulation however is correct for NTSC, whereas
ZSNES gets that wrong. I would like to get PAL overscan working correctly one day, but right now I don't want to deal with window resizing issues such as those you experience when entering the GUI in ZSNES. By the way, does Corn Buster work correctly now? I hopefully fixed those incorrectly sized games with some new cart loading code. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jul 15, 2006 10:47 am Post subject: | |
|
|
|
| Ah, well that explains that. Corn Buster is working. Forgot about that one since you made me take it off the list. So the story on that and Killer Instinct BETA are that they're under/overdumps? If that's the case, should they even be in NSRT? Do they work on a copier? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jul 15, 2006 12:05 pm Post subject: | |||
|
|
|||
Let's make that bug list a little smaller, shall we?
Friends, this is why you should all support Overload and submit your SNES cartridge PCBs to him. I still need to create a database lookup (I forced memory mapping to use that mapper), but that shouldn't take too long. |
|||
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sat Jul 15, 2006 5:37 pm Post subject: | |
|
|
|
| Good work as always man. FitzRoy, how well does Pilotwings work? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Jul 15, 2006 9:59 pm Post subject: | |
|
|
|
Linux, native AMD64, excellent sound output, constant 60FPS, 60-80% CPU usage depending on game and stuff. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jul 15, 2006 10:38 pm Post subject: | |||||
|
|
|||||
I said I tested all games, yes? It works fine. You guys can test them much farther when its unleashed, but everything I've seen is flawless.
Whoa, Linux version. Very nice. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jul 15, 2006 10:57 pm Post subject: | |||
|
|
|||
|
Ok,
I have a textual database for now, but I'm going to make a
text->binary convertor, as I imagine eventually parsing 4,000+ text
DB entries at startup would be a bit of a pain. I'll include source for
the convertor and everything, of course. I look forward to supporting NSRT headers in the future, as an alternative to the DB lookup.
Very cool, indeed. Have to go to bed now, but I look forward to implementing these improvements shortly. Did you port libco to AMD64 for that, or did you fall back on bCPU/bAPU? I'd be very interested in an x64 port of libco. As for sound output, does that now tie into src/ui/audio? Lastly, what's your processor speed again? I usually get ~40-70% CPU usage on my 3500+ at 60fps. |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Jul 15, 2006 11:04 pm Post subject: | |||||||
|
|
|||||||
Bisqwit wrote libco_amd64.asm, I did everything else.
No, I'd like to discuss source changes with you later.
3800. Note I did not attempt to optimize my build at all. I can do that later and let you know if you like. BTW errors and memory leaks are way down with last source you passed me. However there is still a signifigant amount of problems. I have it logged. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Jul 15, 2006 11:26 pm Post subject: | |||
|
|
|||
|
Okay more testing done. SSF2 missing sprites which I reported last week is still a problem. And SFA2 flat out freezes, that was not a problem in .27. I recompiled bsnes with optimizations.
bsnes now uses ~20%-50% CPU normally, but it creeps up a bit towards 60% on a really demanding game. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Jul 15, 2006 11:53 pm Post subject: | |
|
|
|
| Super Street Fighter II now added to the list. Happens in .016 as well. zsnes had similar problems with that very gfx in the past, IIRC. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Jul 15, 2006 11:57 pm Post subject: | |||
|
|
|||
I don't recall ZSNES having a bug like that... I do recall though ZSNES having garbage on that screen, which was a compile time misalignment problem. And it's just not that graphic which I snapped, it's the entire game in bsnes is missing sprites. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 12:12 am Post subject: | |
|
|
|
| Tested more. MK 3 freezes at start. UMK3 has screwed up graphics, and then freezes shortly after. Edit: DKC3 is missing notes at the beginning. Edit: Actually not just the beginning, throughout the game... Bleak doesn't laugh anymore. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding Last edited by Nach on Sun Jul 16, 2006 12:25 am; edited 1 time in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 12:24 am Post subject: | |||||
|
|
|||||
K, maybe I don't RC. I thought it was just the arms and head that used to mess up in zsnes. If there's even the slightest chance that they're related, I thought it was worth mentioning. And indeed, the character gfx are messed up ingame as well. Looks a lot like the Killer Instinct effect, actually. Quite a few fighting games now with problems, not forgetting Mortal Kombat which was fixed. Byuu's not gonna like waking up to more bugs. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 12:28 am Post subject: | |
|
|
|
| PAL detection is screwed up, Korean Leauge won't start. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 1:07 am Post subject: | |
|
|
|
| Both South Korea games don't work. They're added. Mortal Kombat 3 and Ultimate added. I couldn't get SFA2 to hang, and I don't know what to look for in DKC3. I never played through it before. It seemed like everything was okay. Is it possible that some of these bugs are specific to the linux build? | |
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Sun Jul 16, 2006 1:11 am Post subject: | |||
|
|
|||
Well, the way I see it, better finding them now, than later. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 1:15 am Post subject: | |
|
|
|
| Of course, but he's still not going to like it. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 1:25 am Post subject: | |||||
|
|
|||||
And they're fixed in my tree. So Korean Leauge and that Dragonball game should be off the list.
I kind of doubt it, I can make a Windows build and report back. As for DKC3, sound notes are missing, I don't know how much you'd realize it if you don't know the game. I didn't find any graphical bugs in DKC3 though (yet). _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 1:55 am Post subject: | |
|
|
|
| Yes SFA2 is screwing up for me in Windows, Linux x86 and Linux AMD64. But only the U version. E is fine. (or perhaps it's level related and I only tested some levels and that was different between U and E). If it's not screwing up for you, then I'd wager a guess we're not running off the same source. I'm using source byuu passed me Friday afternoon, not sure what you're testing with. As for DKC3, it seems to lack sound when I use profiling in AMD64, but not otherwise, odd to say the least. I'm thinking perhaps the profiler doesn't like libco AMD64 so much... Edit: I'd have to double check, but I think my profile problem was using a profile from older source compiling a newer one, so some code which shouldn't have been was optimized out. Edit: Korean Leauge snapshot: _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 4:13 am Post subject: | |
|
|
|
| Must be a brand new bug then, because I get nothing with the (U) version on .016.30. Played Ken and beat it after about 12 stages... must've been on easy mode. As for Korean League, I get a cart error message and then a button press will go to that title screen. But if I try to start a game, it goes right back to the error message. Dragon Ball just gets a black and red error message. This is all on .016.30 of course... so I took it off the list. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 16, 2006 10:06 am Post subject: | |
|
|
|
| Korean
games don't work because I didn't even know what one was to test it. I
never added Korean region as an NTSC region, so it runs in PAL mode. I
don't even know what region code is for Korea. If SFA2 is freezing because of sCPU, then I'm going to stop enabling it. I've made bCPU and sCPU identical and can't find the R-Type bug anywhere. Apparantly, all fighters on the SNES use some special OAM code that doesn't render at all on bsnes. I'll have to go dig over SNES9x sources and their OAM code again since it affects 25+ games. At any rate, I'm sick and tired of fixing bugs mostly alone, so I'm going to keep working on my database and PCB memory mappers. I'll just not release v0.017, then. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 11:11 am Post subject: | |
|
|
|
| Yeah, SK is apparently NTSC. I didn't run the fps counter on zsnes Hey, sCPU fixed a lot of bugs, too. I'd hardly want bcpu just because r-type iii is screwing up. SFA2 isn't screwing up for me on scpu, either. I don't know why Nach is getting problems. None of the fighter game problems are reversions. They've always been there, we just didn't know it. So unless Wild Guns, Jurassic Park 2, Power Rangers, and Secret of Mana now work in bcpu, I still think scpu is going in the right direction. Nobody expects you to figure out all these bugs before .017. Some of us just can't help you in any other way other than finding them. As for getting help, I have no advice because I'm not a coder. I don't know the skill levels of all the people you correspond with. Everyone who's learned enough seems to be heading their own project, and I couldn't understand the snes9x revival project enough to even comment on it. Is it time to use the DMV27 signal? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 12:19 pm Post subject: | |||||||
|
|
|||||||
Not good to miss out on data everyone has known for years
You guys really need to test more games...
What revival? We've been working on it steadily since the prior release. Just because we don't have a WIP release every other month doesn't mean we're dead. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Jul 16, 2006 12:55 pm Post subject: | |||||
|
|
|||||
Wouldn't it be better to default to NTSC mode? _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 1:25 pm Post subject: | |||||
|
|
|||||
I added code to my tree to handle it, it fixes Korean games and some pesky betas. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 1:31 pm Post subject: | |||||
|
|
|||||
I try to test about 15 a day. But everything seems to work and I get discouraged Really, though, there aren't that many out there. 3 of your 5 were legit, and even then, MK3 and UMK3 are pretty much the same bug. I personally held off testing .016 knowing that it would be pointless with the new core coming. Others may be thinking the same way. With all the changes since .016, there's a good chance anything one would find is already fixed. And wip27a was only up for a day.
Well portions of it were so bad and outdated that they were unsalvagable, yes? Is it really worth the effort with only the hope that someone comes along and rewrites it all? Even if they do, then what? Last edited by FitzRoy on Sun Jul 16, 2006 1:39 pm; edited 1 time in total |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 1:39 pm Post subject: | |||||
|
|
|||||
I found more than 4, and they are legit. byuu has the SFA2 bug too.
anomie rewrote mose of Snes9x prior to the v1.43 release. We didn't release the new code in v1.43 since we didn't fully test it in time, and we didn't feel like breaking Windows just yet. We don't wait for people to come and rewrite the core, we do that our selves. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 1:41 pm Post subject: | |
|
|
|
| Damn you refuted me before I could edit it to 3 of 5! Well, that SFA2 bug must be on a newer build than 16.30 then. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 1:47 pm Post subject: | |||
|
|
|||
Actually it's not. It's a run time bug because bsnes uses unitilized variables. Edit: Found bsnes does not calculate CRC32 correctly. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 1:56 pm Post subject: | |
|
|
|
| Well, you're already over my head. I'll leave you both to it then |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 2:03 pm Post subject: | |||
|
|
|||
To put it simply. You can run bsnes today, and it would seem fine, yet you can run it tomorrow and run into various errors, even if it's the exact same build and everything. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 16, 2006 4:06 pm Post subject: | |||
|
|
|||
|
There. All or most of these third-rate fighters are now fixed. Another problem thanks to the wonders of using hacker maps. I'm going to do everything in my power to wipe the terms HiROM and LoROM off of the internet.
Yes, yes. We get it. Everything has to be perfectly initialized and freed or my emulator is shit. I really wish I could catch them all, but given I have at least 4,000 variables in my emulator, I make mistakes sometimes. I'll work with your Valgrind logs and eliminate as many uninitialized variables as I can. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Jul 16, 2006 4:47 pm Post subject: | |||
|
|
|||
Hopefully you're being sarcastic, but this is very unlikely since these terms have been used for a long time. You are always welcomed to try and change the norm though... _________________ FF4 research never ends for me. |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Jul 16, 2006 5:21 pm Post subject: | |||||
|
|
|||||
What would you suggest then? _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 5:23 pm Post subject: | |||||
|
|
|||||
It's not just your emulator, it's all applications.
It is inexcusable to not use debugging tools to catch this stuff. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 5:25 pm Post subject: | |||||
|
|
|||||
I would suggest waiting for me to add hardware info to NSRT headers, so when you get a ROM, it's like getting it in a cart, with all the included hardware, instead of just one chip and scratching your head about the rest. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Jul 16, 2006 5:29 pm Post subject: | |||
|
|
|||
|
... and then refuse* to load any ROMs that have no NSRT header? *unless the emulator is started with a secret cmdline switch _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 5:44 pm Post subject: | |
|
|
|
| Exactly, the header idea seems a little less practical than the database. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 6:02 pm Post subject: | |||
|
|
|||
How is a database practical? The SNES didn't use a database. Should we need a new emulator release for every ROM dumped when anyone can edit the header with a hex editor or a tool desiged for that purpose for a moment? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Jul 16, 2006 6:24 pm Post subject: | |||
|
|
|||
Nice work. I think the vast majority of Snes fighters were pretty crappy. Just wasn't the console strong suit. So those problems were actually caused by incorrect ROM format detection? |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 16, 2006 6:27 pm Post subject: | |
|
|
|
| There won't be any new carts officially released, and yes we will have to update the database for any new dumps that do appear. I'd like to make the database public and possible to share between all emulators. The format is open and as simple as possible. Dmog, no it was caused by me "fixing" Dezaemon and Tokimeki Memorial, which map SRAM to [f0-ff]:[8000-ffff]. This then broke all of the fighters because they don't. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 7:13 pm Post subject: | |||||
|
|
|||||
True, but it doesn't seem like nsrt is in a popularity position to pull that off. Now everyone who downloads roms is going to stream into the forums and report xxx doesn't work because goodsnes is the standard of the site they obtained their roms from. Most emulator users are clueless. It's simply asking too much of them to use your program when a database can do it automatically for them. And can someone please explain to me why emulators need a complete db, and not just the carts that do strange shit? Would it be too hackish or something? |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 7:22 pm Post subject: | |||||||||
|
|
|||||||||
Most of the clueless won't use bsnes anyway. And considering bsnes doesn't have any real forum associated with it, they really don't have anywhere to complain to.
I disagree with a DB at all. But using a full DB means one system for everything that's proper coding. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 7:31 pm Post subject: | |
|
|
|
| Well, I thought other emus besides bsnes were planning to do this. And I only asked about the necessity of it because it seems like a LOT of friggin work to get that cart info. Most games seem to be working just fine without one, so if there's a way to get around that, by all means... get around it. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Jul 16, 2006 8:19 pm Post subject: | |||
|
|
|||
Well, I plan to add the data to NSRT, then have ZSNES and Snes9x parse the header and follow it. If it doesn't exist, just fall back on the old code which works 95% of the time. I do not plan on adding a database to other emulators. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 16, 2006 11:18 pm Post subject: | |
|
|
|
| Updated
the buglist after confirming the fighters work and ran through the
rest. There doesn't appear to be any further fixes, but at least it's
looking rather short again PS: I did not check Megaman X2 |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Jul 17, 2006 7:09 am Post subject: | |||||
|
|
|||||
If you distribute it with an emulator, people'd just have to download a new version and wouldn't have to modify their ROM files. _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Jul 17, 2006 11:19 am Post subject: | |||||
|
|
|||||
And how often do we have official emulator releases? Setting up the header can be done immediatly. And regardless, having an emulator database driven is just wrong, any time a game gives you trouble you can start using special settings for that game, it's evil. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 17, 2006 12:06 pm Post subject: | |||
|
|
|||
|
Well, my database contains four fields. Name (region) (revision) (verified good dump?), PCB ID, ROM size, RAM size. I use name to display in the emulator, looks way better than internal ROM names. I use PCB to select the appropriate memory mapper. ROM size and RAM size for underdumped/overdumped games. The last two I could probably even remove. I pull the rest from the SNES cart header. Region, vectors, etc. The use of the DB is optional, just delete cart.db and it'll run fine without it and use the old hacker memory maps. Anyway, it's mainly only needed for problem games like Ys 3 and such. I'll probably add it for games like MMX because they have evil copy protection checks galore. Once your NSRT header spec is finished, I will default to using that. If no NSRT header, then I will fall back on the database. If that fails as well, then as a last resort I will use hacker mapping (HiROM and LoROM), and display a popup each time with a settings box to let the user override the sticky points of these maps.
I hope you know I would never do that. Though I can't speak for others. Even still, it'd be better to do that than to turn on hacks based on the internal ROM name, wouldn't it? |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Jul 17, 2006 12:15 pm Post subject: | |||||
|
|
|||||
Why? First of all, hacks are hacks, if you now have a system for a per game thing it's just going to enourage extension. Second of all if you did happen to hack and based in on the internal name, it would be one hack for all revisions and probably regions since they share internal name, with a per DB setup you're going to make that hack per ROM edition for a game. I would also like to point out your whole DB would need to add enteries for every translation and what not. A header would not have this problem. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Jul 17, 2006 12:55 pm Post subject: | |||||||||
|
|
|||||||||
I didn't say official. WIP versions could do the same. _________________ savestate editor: vSNES latest public version
|
|||||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Jul 17, 2006 1:03 pm Post subject: | |||||||||
|
|
|||||||||
So the emulator should be considered broken because we don't do WIPs? And we should start catalogging every translation? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Jul 17, 2006 1:13 pm Post subject: | |||||
|
|
|||||
1. ZSNES does WIPs, and every other emulator could also have them, even if only the DB is changed. Even better if the same DB can be used by all participating emulators. 2. Nope. The selection could be done before an IPS/NINJA/... is applied. Hardpatched ROMs would of course not be supported. Anyway, it's your decision guys. I'm just pointing out some things. _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 17, 2006 1:15 pm Post subject: | |||||||||||||
|
|
|||||||||||||
My license disallows derivative works and I won't be adding any hacks, ever. So for me at least, you really don't have to worry about that. I don't consider the DB a hack, I consider it adding back information that was lost with the ROM dump.
Exactly my point, and that's a good thing. You shouldn't apply a hack to all revisions of a game unless you know how each revision works. Once you do, you can just as easily add two or three entries for each revision. But I'm not even talking about using my DB for hacks.
I'm not planning on doing that. Both because translations aren't official carts and shouldn't be in an official database, and to respect the translator and prevent ROM hoarders from seeking pre-patched ROMs for the purpose of having a "complete database".
And by all means, as soon as such a header exists, I will use it. Until then, Ys 3 now works*, whereas it didn't before. * Still need to add J/E releases when I have time. Speaking of which, before I forget... we need to work on UPS::SNES format some more. It would be a good thing to somehow include an optional header so that translators can take advantage of soft-patching and still enjoy the benefits of NSRT headers. I say we include both, since neither contain copyrighted information, and it's possible the source ROM could have a different copier header yet still be the same ROM. If one of the ROMs patched (or both) lack a header, then store the header as all 0x00s. This way, it would only add 1k extra per SNES patch. We can use one of those bits for flags to specify whether or not a header exists.
That's what I was going for, an open source, open tool database to be used by all emulators. My format is pointlessly simple.
Oh wow, I love this idea. It's perfect. It makes total sense. If they want to hard patch for a copier, it won't matter that emulators don't detect proper memory mapping. If they want to use it in an emulator properly, they soft-patch. The ROM hacker can then detect the correct PCB mapping as a way to verify the ROM was soft-patched and alert the user that the ROM was hard patched, and thusly might be a) missing readme files and b) mirrored incorrectly, causing possible unknown bugs. I say we support it both ways, pre-patch and post-patch CRC DB checks, with pre-patch CRC taking precedence. |
|||||||||||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Jul 17, 2006 1:28 pm Post subject: | |||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||
ZSNES does WIPs, sometimes. Snes9x doesn't. And most people don't use WIPs.
So break hard patching... And if a patch changes the mapper requirements (and several do, Front Mission patch IIRC, among others), this breaks soft patching too.
Well, you're encouring it in other emulators.
How isn't it a hack? You're putting the missing PCB info into the emulator instead of the ROM dump where it belongs.
Check all the times we had hacks added in the past and people complained because we made it specific to a particular version. You should apply to all revisions unless you know it's only needed for one. It's rarely the case a particular hack is only for one revision. (and I'm talking from experience here in seeing many many hacks in SNES emulators and watched how many of them were elliminated)
So basically you're going to make the patch scene even more confusing with this setup.
Add J/E? Oh so you needed a hack for all 3 versions now, and not just one of them, proving my point above. And I hardly see as what you currently have implemented as any proof as to which method is superior one way or the other.
I'd like to discuss this online with you. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||||||||||||||||||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Jul 17, 2006 3:18 pm Post subject: | |||||||||
|
|
|||||||||
Like I said, emulators could start releasing WIPs as soon as the database changes. EDIT: If people come complaining we can just tell them to download the current WIP.
IMO hardpatching doesn't have to be supported. For the other issue there could be a second database that handles these special cases. (Yes I'm aware that's not a perfect solution...)
That's a very good point. I'd also prefer it if all the required info was in a *.sfc file. But fact is that since ROM dumping started, people used only the [copier header + ROM] files. The copier header doesn't contain the required info (or does it?), hence it's useless for emulators. Therefore I always thought of *.smc, *.sfc etc. purely as files containing the ROM, and nothing else. These simple file formats can't store all info that is available about a game. Some emulators (eg. MAME) might want to display cover art, the manual etc. This info has to be stored elsewhere. To include this in the "cartridge dump file" you'd need a chunk-based format, which probably won't happen soon. So if you store all that info in other files, then why not the PCB info as well? PS: There are enough tools already that can't handle headerless/headered ROMs. *eyeroll* IMO it's better to get rid of it at last. EDIT @ byuu: Weren't Lo/HiROM the official Nintendo terms? _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Tue Jul 18, 2006 6:44 am; edited 2 times in total |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 17, 2006 3:36 pm Post subject: | |
|
|
|
| From
what I know, HiROM and LoROM were generic representations by Nintendo,
yes. The emulation scene took them and applied them to every game. But
the reality is that there are >20 memory mappers that map images
differently. And HiROM+LoROM combined cannot cover all games, just a
large majority of them. We need more detail than just these two. Now then, if we include all the info in an NSRT header, what happens if that information turns out to be incorrect? I think a database with a version number would be a lot easier for people to deal with upgrading than downloading the latest NSRT and running it on all of their ROMS, getting those seeded out to all users again, etc. By using a database with a problem, we just fix it. We require the DB version number be included with the bug report, and if it's older, we tell them to upgrade. We could even add a Firefox-style "check for DB updates" option to our emulators that goes online and retrieves updates on the fly. We make a page that allows user submissions and bug reports, and it turns into something like freedb for audio CDs. |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Mon Jul 17, 2006 5:32 pm Post subject: | |
|
|
|
| A wild idea would be to get bsnes to use this database to actually write the info to the ROM's NSRT header, so that you can get the benefits in other SNES emulators that won't use the database. Sort of like how you can make Nestopia write its database info to a NES ROM's header if you wish. | |
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Mon Jul 17, 2006 5:42 pm Post subject: | |
|
|
|
| Xamenus
has an interesting, although unintended, point - someone might decide
at some point to make their own NSRT-header writing tool, and you could
have ROMs with NSRT headers, but with incorrect information. It represents a decision that any emu author would have to make - accept the header info as gospel, or do validation to some degree or another. Byuu already has to do validation for non-NSRT headed ROMs, why not just do it for every ROM? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Jul 17, 2006 5:58 pm Post subject: | |
|
|
|
| To clueless people: NSRT updates older headers automatically. Other tools already write NSRT headers. NSRT headers contain version numbers. I'd appreciate if people actually look into things before spewing, thanks. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jul 17, 2006 6:07 pm Post subject: | |
|
|
|
| I'm
not buying the header argument. A real snes wouldn't read the memory
map from a header, that's something copiers use. So having a db with
that info apart from the rom isn't really much different what you're
doing. And as for emulator updates being a problem- that's just ridiculous. How often do new games get dumped these days? A few every year, with a 99.9% chance they'd work perfect on the fallback map. And the end-user confusion issue still stands. It's simply WAY harder with the state of distribution to do what you're proposing every time someone downloads a rom. edit: removed "hackish" because it's not Last edited by FitzRoy on Tue Jul 18, 2006 5:59 am; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 18, 2006 2:46 am Post subject: | |
|
|
|
| EDIT: no reason for this to be here, either. Last edited by byuu on Tue Jul 18, 2006 1:27 pm; edited 2 times in total |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Jul 18, 2006 6:45 am Post subject: | |||||||||||
|
|
|||||||||||
I think this should be kept here...
_________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Fri Jul 21, 2006 1:01 pm; edited 1 time in total |
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 19, 2006 12:07 am Post subject: | |
|
|
|
| Thanks for getting the thread back on track guys, and I'm glad bsnes will share a db with super sleuth. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 19, 2006 12:34 am Post subject: | |
|
|
|
| We don't currently share the same database, just the idea of using one. Although with Overload's permission, I could add support for bsnes to read his database if it exists in the bsnes base directory. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 19, 2006 12:46 am Post subject: | |||
|
|
|||
Oh, well that would be cool if they did (and future emus), but you guys will probably want different formats.
Just to clarify something. As I understood it months ago when this even came up, I got the impression that this quirk of randomness could not be emulated, only simulated. As such, you said that you were going to add a compile time option or something for people who were interested, not a full blown implimentation. I put this in the same category as having an snes emulator running progressive on a pc monitor despite the original system's incapability of such. There are some things that you just naturally overcome in the conversion from console to pc. I didn't think it was too much accuracy, I just thought it was impossible do in the same manner on a pc, thus unnecessary. Hopefully that explains some things. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 19, 2006 8:03 pm Post subject: | |||
|
|
|||
|
Hm,
I can fix Death Brade and both bugs in Power Drive (and possibly fix
others, and possibly break others) by initializing WRAM to 0x55/0xff on
power-on. Right now, I initialize it to 0x00. The question is, should
I? There is no officially defined value that WRAM is initialized to on
power on, and it's technically a bug in the game, reading uninitialized
memory and relying on those values. Also, The bug in Hungry Dinosaurs occurs in Super Sleuth and ZSNES. Are you sure this doesn't happen on the real SNES? It would be good to test it, because as it stands I have no idea how to fix that. I can barely even see it. Also, say hello to my little friend, infinite mirror recursion.
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 19, 2006 10:28 pm Post subject: | |
|
|
|
| The
Death Brade and Power Drive bugs look like a similar situation to
Krusty's Super Fun House, where the game code is doing something that
goes against what makes sense, but nevertheless avoids issue on the
real console. Those have got to be some of the hardest for you to
figure out I don't think we're seeing the same thing on the Hungry Dinosaurs bug. After you start a game, a weird transition effect happens. On bsnes, it almost seems as though a whole vertical part of the right side is erroneously ending up on the left part of the screen, which does not happen in zsnes or super sleuth. Here are some caps pointing it out. imgs removed, issue resolved Last edited by FitzRoy on Sat Jul 22, 2006 3:21 am; edited 1 time in total |
|
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Wed Jul 19, 2006 11:14 pm Post subject: | |||||||||||||||||||
|
|
|||||||||||||||||||
Hmm. I feel like I'm gonna sound like an ass, so sorry in advance. This post is not intended to be offensive. I want to criticize your algorithms constructively so that you get a better, more logical approach to functions like that. Let me explain: your realloc logic looks overcomplicated: a loop with several exit points depending on apparently complex checks. Proposed replacement:
Why store an index, then use it as a shift-mask in a check, then do additional checks, when you can flatten the logic and put it simply ? Next, your rom mirroring code. It's not recursive. This means that you have to handle all the cases in a go. Those who're used to recursive algos can skip the next paragraph + code blocks rant. Recursive algos dive in themselves until they meet their special case, then process the data along the way back out of the recursion ladder. That makes it easy to support all sorts of wicked inputs, as long as you find the way to reduce them all to the special case. On the other hand, non-recursive algos have to deal with ALL the cases in a single go. This is simple for some, much less for others. Simple example: factorial x: Recursive:
Straight:
Minimal difference. Processing 'any case' seems to be as easy if not easier than splitting into 'special' and 'default' cases. I didn't try to see which was faster, but I'm gonna guess the latter, since it's gonna skip all the call overheads. ** resume reading if you're not byuu. So, you imbricate 2 loops, the inner one stores the first 2 memory blocks of size = power-of-2 (called 'blocks' from now on) bottom-to-top, then mirrors the last block, updating size on the fly. the outer loop repeats the inner one as long as the rom is made of several blocks. ** byuu can skip up to here :) It's a perfectly valid 'any case' implementation, no issues about that, it'll work correctly with anything. Good. Now... of course mirroring is trivial, since it's only done once per rom load... but if you need a complex algorithm like that in a speed-critical segment, you want to be able to write fast code. I found several places where you can improve speed at no cost: - you run a bottom-to top loop starting over from 0 every outer loop. You can make it instantly aware of the next block by simply setting i to maskhi*2 before looping. - the " if(i > 31)break; //no mirroring necessary " line is superfluous. If no mirroring is needed, the outer loop won't run at all. No need for extra checks within the inner loop. - again, you use i++ in your loops, then test against 1<<i for each iteration, it wastes time. Make the loops use directly the mask and update it with <<= 1 - you can save a relatively negligeable amount of time per (masklo < maskhi) loop if you do:
Sorry about that last one, I'm just being silly, but it *would* save some time, honest. ^_^ Anyway, that would make a better 'any-case' implementation in my opinion. I hope it also does in yours. Now if you want the latest zsnes recursive algo... I refined Nach's code a bit, to reach:
The realloc happens outside (uses the code I pasted earlier). And for kicks, the sickhead version
Oh, almost forgot: The code snippets from zsnes are under GPL2, so don't forget to give credit if the awesome gives you inspiration. ;) _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach Last edited by grinvader on Wed Jul 19, 2006 11:29 pm; edited 3 times in total |
|||||||||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 19, 2006 11:15 pm Post subject: | |||
|
|
|||
|
Ah, that's a generic mosaic problem. I've implemented mosaic according to spec, though :/ It affects a lot of games that use heavy mosaic. I thought you meant that color change that happens after you beat a level. I'll see what can be done, then. So should I commit the "fix" for DB and PD? Kind of sucky since the games are technically "broken" from a programming standpoint by requiring certain values in undefined variables. Sort of like a certain emulator sometimes does, right Nach? But, that's two less bugs if I add it.
And that's why I'll continue to use my own :) Richard Stallman and his horde of hippie lawyers can suck it. Thanks for the optimization ideas, but I wasn't going for speed since this function's only called once. You do have some points about some things, and technically the while(r < size) isn't needed because of the if(i > 31)break, but I added it because it looks nicer than an "infinite loop" ala for(;;). |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 19, 2006 11:39 pm Post subject: | |
|
|
|
| Maybe I'm just not getting this, but if DB and PD only work in your emulator by accessing undefined variables, how did they work on a real system unless the real thing allowed this as well? | |
ZSNES Plasma Prinny
Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
| Posted: Thu Jul 20, 2006 12:09 am Post subject: | |||
|
|
|||
|
The 'real thing', being an electronical device, has init values set by noise. It just happened that these games work with FF, or 55 (or maybe AA). Basically, those games are not programmed right, and only work due to the 'imperfect' behaviour of the original hardware. _________________ 皆黙って俺について来い！！
Pantheon: Gideon Zhi | CaitSith2 | Nach |
|||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Thu Jul 20, 2006 3:08 am Post subject: | |||||||
|
|
|||||||
In bppu_render_bg.cpp, it looks like hoffset is affecting the starting position of the mosaic pixel blocks. This is not correct; the first block should always start on pixel 0 of the scanline, not xpos = 0 of the bg. From regs.txt:
Also, I don't think the mosaic_countdown code in bppu.cpp will work with this test:
I think writing to $2106 has to reset mosaic_countdown in order for this to work. |
|||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Jul 20, 2006 7:08 am Post subject: | |||||
|
|
|||||
Well, correct emulation would be to fill the WRAM (and maybe VRAM? nah...) with a pattern that comes close to the real one. Unless the cartridge affects these values somehow, they should always be the same - or at least some regions. You could test the WRAM a couple of times and note which regions change and which don't. I think blargg or somebody else already did that... _________________ savestate editor: vSNES latest public version
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 20, 2006 7:59 am Post subject: | |
|
|
|
| And
in case you weren't aware of this (you probably are), Derby Stallion 96
is verified on Overload's cartlist. You previously suspected this
game's failure had to do with the generic memory mapper you were using.
Now that you have a db, you might be able to get this one off the list,
too |
|
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Thu Jul 20, 2006 11:23 am Post subject: | |||
|
|
|||
Derby Stallion '96 uses a Broadcast Satellaview Cartridge. There is no way of detecting BS Carts using the ROM header. The mapping is not a standard 24mbit mode 20H mapping. If you break the ROM into 8mbit chunks it goes $00-$1F (A), $20-$3F (B), $80-$9F (A), $A0-$BF (C). The BS cartridge also allows a flash cartridge to be mapped in the $C0-$EF region. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 20, 2006 3:23 pm Post subject: | |||||||||||||||||||||
|
|
|||||||||||||||||||||
Correct, thank you for pointing that out. I haven't found a good way of doing this correctly just yet, and it's causing up to one tile to spill over from the right to the left of the screen as a result.
IIRC, I implemented just enough of TRAC's notes on mosaic to support Sim Earth. I don't currently do anything on writes to MOSAIC, mostly because SNES9x uses a count-up counter that doesn't directly work the way mine does. I need to fix this, yes.
Ok, as most of the CPU regs are power-on to 0xff, I'll use that for now. If that causes bugs in those two lame games, I will turn it back to 0x55 as a last resort. So I guess consider those two games "fixed", now. Even though they are fundamentally broken to begin with.
Indeed, I actually used to have this game. I smashed it apart to take a look at the connector, heh (really need to buy a bit already). It has the little cart connector on the top for the BS-X flash cart. Very interesting that it has a BSC- PCB prefix. I don't recall seeing that in the list before, and certainly not on the PDF file. I will add support for this mapper as soon as possible, thanks Overload! EDIT: not having any luck... the game still blackscreens upon load. Verified it was loading as it should. I'm treating the game as a LoROM in that all banks are mapped to $8000-$ffff and not $0000-$ffff... Format is map(bank_lo, bank_hi, page_lo, page_hi, type, start = 0);
Any ideas? :/ Also, even though I'm sure we don't have any BS-X flash cart dumps for this game, I'd like to go ahead and add support for them anyway. I assume the BS-X flash cart works just like SRAM? eg I should map a 24mbit file to $[c0-ef]:[0000-ffff], say <romname>.bsx, and then allow the cart to freely read/write to this memory area? Or does it require special control registers to access this memory in write mode similar to the BS-X base unit? EDIT 2: $00-$1F (A), $20-$3F (B), $80-$9F (A), $A0-$BF (C) should be $00-$1F (A), $20-$3F (B), $80-$9F (C), $A0-$BF (B)  Hooray, database! Ok, that's three down. Death Brade, Power Drive and Derby Stallion '96. Now, onto Hungry Dinosaurs...
And for reference :
To me, it looks like that code does apply after scrolling but before clip windows, color windows or math. I'm not sure how to correct this problem :/
In that case...
Obviously, I will adjust the code at home to use hoffset and voffset instead of copying the values back to mosaic_x and mosaic_y. But for now...  Can we consider this bug fixed as well? Next issue: most emulators do this. Super Sleuth, ZSNES, and bsnes v0.016.32+.  This is the title screen for Energy Breaker. It flickers for two frames with just the top half of the display visible. In bsnes v0.016 and SNES9x v1.5, this does not happen. We need to verify the correct behavior on hardware. It's possible this is the correct behavior, though. Note: this appears to be another difference between bCPU and sCPU, as the flickering does not occur with bCPU in the latest WIP. So that's two differences now :/ I will try my best to track down these differences this weekend. I see no reason to list this as a bug until we verify the correct behavior on hardware. Next, here's a comparison of the mosaic effect when going between "screens" in Energy Breaker.  I imagine ZSNES has the bug here, but it would be good to go ahead and verify this while checking for the title screen flicker issue. It will be necessary to use a TV capture card to see the edges, most likely. That, or mess with the flyback transformer or somesuch to force your TV to show the left-most edge of the display. Last edited by byuu on Thu Jul 20, 2006 5:50 pm; edited 2 times in total |
|||||||||||||||||||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Jul 20, 2006 5:26 pm Post subject: | |||||||
|
|
|||||||
Are you filling the entire area with FFh or 55h? If the game starts every time then I'd say that the referenced memory locations contain always the expected value. _________________ savestate editor: vSNES latest public version
|
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 20, 2006 5:57 pm Post subject: | |
|
|
|
| I'm
filling all 128k of WRAM with 0xff for now. It works for Death Brade as
well as Power Drive. I know this will break a couple demoscene games
that rely on WRAM starting at 0x00. They do this because copiers often
clear this memory to 0x00 for them before starting their demos. Qwertie
in particular was bad about relying on this behavior in his demos. Also, as far as I know, some BS-X games (Zelda remake) rely on WRAM being 0x00 on power-on. I will worry about this when I start adding support for the BS-X hardware. I will likely initialize WRAM differently for these games. The games themselves aren't technically supposed to load directly anyway, as far as I know. I'd bet the BS-X BIOS sets WRAM before starting the games. |
|
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Thu Jul 20, 2006 7:24 pm Post subject: | |||||||||
|
|
|||||||||
Yeah, I own the cart too. Sound Novel Tsukuru (BSC-1A7M) is another that maps this way. I will add it to the pdf.
The flash cart has a special sequence of reads/writes to enable writing to flash ram. The flash cart is identical to the cart used with the BS-X cartridge.
You are correct, my mistake.
I also think ZSNES is incorrect in this case (window effects). |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 20, 2006 9:00 pm Post subject: | |||||
|
|
|||||
Ok
then, I will try and find the difference between bCPU and sCPU causing
the EB title screen to flicker, and test the behavior on my copier this
weekend and let you know the results. Looks like it's going to be a
tough one to track down. My first guess is an IRQ not firing in sCPU.
Hmm, fun. Sound Novel Tsukuru (Japan) [!] ZSNJ BSC-1A7M-10 Derby Stallion '96 (Japan) [!] ZDBJ BSC-1A5M-01 Are these two identical, mapping wise? I can get Sound Novel working using BSC-1A5M-01, but I prefer not to add PCB mappers without verifying they are correct first :/ Also, if you wouldn't mind linking to your latest PCB PDF, I'd appreciate it. That thing is extremely useful.
I don't suppose you have more detailed information on this? If it works the same for the BS-X BIOS as it does for Super Derby '96, I might as well add support for that as well. If not, I can probably RE the info by logging reads+writes to banks $c0-$ef. The Game Genie was particularly easy to decode like this. Implementing a cart passthru in software, however, turned out to be a good deal more difficult (hence why I haven't added support for it, nor currently plan to). |
|||||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Fri Jul 21, 2006 4:42 pm Post subject: | |||||||||
|
|
|||||||||
It's always been in Super Sleuth. I had a look at it last night and it seems to be a windowing problem but I am not sure what is causing it. The HDMA data looks fine.
The only difference is the amout of sram on the PCB.
I normally keep a copy at http://users.tpg.com.au/advlink/temp/pcb.pdf
I don't have any more detailed information. I would like to add support for the flash cart too. I might take a look at it next week. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 21, 2006 4:54 pm Post subject: | |||||||||
|
|
|||||||||
I don't believe it's a windowing problem. Since replacing my CPU cores whilst leaving my PPU core alone corrects the problem, it's isolated to the CPU. I will do my best to find the fix for this, but you might have an easier time tracking it down than me since I lack a debugger.
Perfect, thank you.
Awesome!
Then I'll do the same and let you know what I find, thanks. I imagine we won't be so lucky and the flashcarts will require certain data to already be on them in order to work. But you never know until you try, right? |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 21, 2006 5:36 pm Post subject: | |||||||
|
|
|||||||
|
Well
that sucks. When I remove HDMA bus sync timing from bCPU, EB title
starts flickering. I know for a fact SNES9x does not implement bus sync
timing (it can't), so we probably need a better compromise between the
two. EDIT: dug into this a little more, the title screen never calls HDMA init, only HDMA run. I tried adding a simple "wait a cycle or two before running HDMA" delay, but that didn't work too well. Nor did I think it would. Also tried adjusting when HDMA triggers, moving it forward and backward, again no avail. I tried logging the differences between bCPU and sCPU and all of the writes are the same, they just tend to happen ~30-40 clocks later in bCPU. So, move sCPU forward 40 clocks for the hell of it ... no go. Still broken. Very annoying. EDIT2: problem solved. Timing issue. bcpu.cpp :
scpu.cpp :
By the way Overload, that last line could be used in Super Sleuth to fix Wild Guns if you wanted. Change it to a cycle count of ~20-24 or so if you want to be more accurate, mine is just an opcode counter for now :/ It needs to go into dma_run() and hdma_init() as well. I knew this already, too. It was an oversight on my part porting the old code to the new version. From anomie's SNES timing document :
Specifically, "Each active channel incurs another 8 master cycles overhead for every scanline, whether or not a transfer actually occurs". |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jul 21, 2006 9:05 pm Post subject: | |
|
|
|
| Good work! Discovered and fixed before I could even add it to the list Any chance this fixes r-type as well? edit: new bug discovery regarding your recent wip, which may have to do with your WRAM changes: in Radical Psycho Machine Racing, the car gfx are now corrupt. Some look like tiles from the title screen |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 21, 2006 10:37 pm Post subject: | |
|
|
|
| That's because Interact hired mentally retarded chimpanzees to peck out the code for RPM Racing. Games that bad should not be allowed to exist in a just and fair world. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jul 21, 2006 10:43 pm Post subject: | |
|
|
|
| It's
a truly shitty game, and the port looks like it fixed some things.
Wasn't RPM Racing followed up by Rock N Roll Racing by the same team
(silicon & synapse a.ka. Blizzard). If so, you may have to eat your
words On another note, Super Sleuth handles DB and PD fine (does it do anything to WRAM?), as well as RPM Racing. |
|
Veteran
Joined: 30 Jul 2004
Posts: 921
Location: Mexico
| Posted: Fri Jul 21, 2006 10:53 pm Post subject: | |||
|
|
|||
Yep Blizzard is not known by their great coding anyway. WC3 scripting language (JASS) has a lot of bugs, and Diablo 2 has many performance issues. _________________ _-|-_ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jul 21, 2006 11:01 pm Post subject: | |
|
|
|
| Strange story, really. "If at first you utterly suck, try again... and end up with the best racing game on the system." | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 21, 2006 11:06 pm Post subject: | |||
|
|
|||
I don't see what having the worst racing game on the SNES (a true honor given some of the shit Nintendo let through quality control) has to do with what the company did later on. I didn't change anything that would break RPM racing, but whatever. I even backported the one change that's different into my work WIP and the game still runs fine. Sigh. EDIT: alright, seems to happen every other time you play the game. I'm not worried about it right now since the game's a piece of shit and already has other bugs anyway. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jul 21, 2006 11:34 pm Post subject: | |||
|
|
|||
|
Semi-joking
with that, but to the matter at hand: yeah, I just realized that the
bug is somewhat spontaneous. Sometimes the sprites will all start
garbled and stay that way, and sometimes only 1 will start garbled and
it will go back to normal when it moves... I'll just add this info to the current symptoms, no big deal. I just hope it's the only new bug added from this. It's good to take notice when things pop up that weren't there before, lest it get buried in wips and becomes harder to track down.
Alright, I have time to elaborate on this now. If it was indeed the same team, then it shows a level of improvement that you have to admire. It goes beyond a retarded chimp. If I remember correctly on this bit of history as well, RPM Racing was one of the first games for the system. As such, despite the fact that it was a noob effort, it probably got rushed to release also, to take advantage of sales from lack of competition. Might explain why the game not only sucks, but is full of bugs (and the J version free of them). |
|||
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Sat Jul 22, 2006 6:45 pm Post subject: | |||
|
|
|||
Byuu, What brand and model of television set are you connecting your SNES to? Most TV's manufactured within this decade have a secret service menu that brings up controls similar to a computer monitor (trapezoid, h-size, v-size, rotation, whatever). |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Sat Jul 22, 2006 10:12 pm Post subject: | |
|
|
|
| RPM
Racing from Silicon & Synapse/Interplay/Blizzard has bugs that
happen after a random number of plays.Do you see a pattern here? Rock'N'Roll Racing has a similar issue,but with the sound.It mutes after a random number of plays. The game is also by S&S...hmmm.... Speaking of Silicon & Synapse,you forgot an even better game they made for the SNES than Rock'N'Roll Racing - anyone remember the legendary "Lost Vikings"? This was an awesome game for the SNES...and surprisingly,it comes with no bugs at all Sadly,the second part of the LV series was not that great as the first one. I had loads of fun with this game back in the days. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 23, 2006 2:07 am Post subject: | |
|
|
|
| Fixed
a bug no one noticed. Super Conflict was showing the logo before
zooming in because I was clipping m7[abcd] with sclip<15>(n) and
not sclip<16>(n). Might fix some other unnoticed mode7 glitches,
too. I wrote a litmus test to run through all 64k possible values for m7[abcd]+center[xy] just to be safe. Identical to the old code now and Super Conflict doesn't glitch out at that part anymore. But the missing 's' is still there. whicker> I have a Magnavox TV, I don't know what model it is. Looks to be 21" or so, silver. I'd be interested in a test menu. My TV's alignment is terrible. It would make testing some PPU edge cases easier, too. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 23, 2006 2:31 am Post subject: | |||
|
|
|||
Cool. Kick, can you be more specific about that RNRR bug? Is the music stopping altogether, races and all? I'll give it a try tonight. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 23, 2006 2:38 am Post subject: | |
|
|
|
| And is that a bug in bsnes or on the real game? Or are you not sure? | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jul 23, 2006 3:27 am Post subject: | |
|
|
|
| Well, now I'm really not sure what he means. I played the whole first planet and noticed nothing out of the ordinary. The only game bug I ever came across on the real cart (and I played this game for 200+ hours), was that sometimes at the end of the game, when they start showing all the fake clips from your season, sometimes it would hang at the black screen between transitions. It was very rare though, and completely random. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 23, 2006 8:21 pm Post subject: | |
|
|
|
| Ok, horrible things happen when HDMA occurs on the same channel as an active DMA transfer. The behavior is currently too complex for me to decode using only a copier and probing known registers. Suffice to say it is not any kind of standard behavior: the real hardware goes "nuts" when this happens. Now, I can fix Bugs Bunny by blocking HDMA transfers when a DMA transfer is active. This is not correct, but neither is my old behavior of allowing them and making them act normal. I don't think I'll be able to figure this one out alone. So then, what should I do? Leave the code alone, or "fix" Bugs Bunny, albeit improperly? Even if the game looks correct, it will still not behave like hardware either way. This only applies to DMA+HDMA on the same channel, if they're on different channels they act properly, so my other tests and Dracula X still work fine either way. Bugs Bunny is the only known game to exhibit this bug. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sun Jul 23, 2006 8:59 pm Post subject: | |||||
|
|
|||||
Since both method are technically incorrect,I guess it doesn't really matter one way or another. I would probably leave it alone since the new method could give the false impression that this issue was accurately "fixed". I've wondered before about the limitations of RE through software-only (in this case: running your own custom programs with the help of a copier) Do you think this is one such case where the aforementionned method cannot give you new information? Or could it still be theorically possible but just incredibly complex? Anyway,nice job on the recent reduction of the bug list. Your (and Overload)'s database is showing great promises.
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 23, 2006 10:58 pm Post subject: | |||
|
|
|||
The work is all Overload's, so please direct all credit towards him. Anyway... back to DMA+HDMA... I accidentally left force blank off, hence the wild results. If DMA + HDMA is enabled on the same channel, DMA runs, and then HDMA triggers on that same channel during the transfer, the HDMA transfer will kill the remaining part of the DMA transfer. This means $43x5 != 0 after the DMA transfer, and $43x2 is similarly $43x5 bytes shorter than what it should be (or greater for backwards transfer). Both Bugs Bunny: Rabbit Rampage (U) and World Class Rugby (E) rely on this behavior to work correctly. I have tested this in all emulators, none implement this behavior. So if they run either of these two games correctly, it is due to another bug in emulation that just happens to make it right. eg they block HDMA VRAM writes during force blank, or block HDMA when DMA is transferring on the same channel. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jul 24, 2006 2:38 am Post subject: | |
|
|
|
| So are you saying you've fixed them now, properly? I can take them off the list? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 24, 2006 2:26 pm Post subject: | |
|
|
|
| Yes, they are fixed properly now and can be removed, thanks to help from TRAC and zones. Still battling R-Type III and RPM racing. Those, Chou Aniki and EWJ2e are probably the only ones I'll be able to fix. Uniracers and Super Conflict probably require some currently unknown PPU dot rendering information to fix properly, and I really don't even know where to begin with Mega Man X2. It's such a weird bug. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 24, 2006 9:34 pm Post subject: | |||
|
|
|||
Overload, a little logging on the BS-X flash cart :
$c080xx appear to be control registers, I think the first six enable the cart, and $c1ffxx is information about the cart, seemingly $14 bytes, possibly more. Games then start accessing $dfxxxx regions. I'd take a wild guess the 8mbits is mapped to $d0-df and mirrored to $e0-$ef. |
|||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Tue Jul 25, 2006 12:03 am Post subject: Re: bsnes appreciation thread, sound woes | |
|
|
|
| I'm sure this isn't important, but when frameskip 1 is enable while in game in R-Type 3 (U) it'll pause the game before it locks up. Ah I was using 016.32 by the way and no one gave it to me. You just happen to have it using the same link as the beta you posted before. =o | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 25, 2006 12:52 am Post subject: | |
|
|
|
| Yeah, I noticed it made the pause sound before crashing. The R-Type bug is seriously kicking my ass, and holding up a new release as well. | |
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Tue Jul 25, 2006 2:51 am Post subject: | |
|
|
|
| That's a shame about the release. Atleast R-Type III is a game worth fixing. It seems to be one of the better shooters for snes. I'm surprised I never brought the game when it was released. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 25, 2006 3:42 am Post subject: | |||
|
|
|||
Well this is embarassing ...
It would be good to test vertical scanline positions against vcounter instead of the horizontal clock counter. Makes it a lot easier to stop games from getting stuck in infinite loops waiting for that bit to be set. Also added DMA per-channel initialization delay. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 25, 2006 5:10 am Post subject: | |
|
|
|
| http://byuu.cinnamonpirate.com/temp/aniki.txt That's the problem with Chou Aniki. The game is turning NMI off and then immediately turning it on. Since the read pin is low and the line pin is high, this causes an NMI to trigger. Because the Aniki programmers are writing in 16-bit mode to $4200 (screwing up PIO in the process), bsnes triggers the NMI at the end of the sta $4200. The Aniki programmers chose to save the updated $0201 variable with the bit that says "yes, keep NMIs enabled" after the write to $4200. And then during the NMI, it reads $0201 and writes it into $4200 again, killing all future NMIs forever. I've tried a few solutions, and at least two got Chou Aniki working, but broke my test_nmi.smc file. Therefore, these won't be added. I must be missing some obscure NMI quirk, but it eludes me at the moment. For the record, ZSNES and Super Sleuth work by not triggering an NMI at all, as if the $01 write to $4200 clears the pending NMI. That's not the case on real hardware according to my test programs. I suspect the reality is that if NMI is enabled immediately before the opcode's last cycle, it's not lowering the NMI pin, delaying the NMI for one more opcode. That would also allow Chou Aniki to work. I shall have to run a lot more NMI tests to fix this one :( |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jul 25, 2006 8:40 am Post subject: | |
|
|
|
| Good good good. And then there were 3. | |
Rookie
Joined: 27 Jan 2005
Posts: 16
| Posted: Tue Jul 25, 2006 2:51 pm Post subject: | |
|
|
|
| I'm
not sure if this is actually a bug or merely the consequence of high
cpu usage while running the emulator. I've noticed in Tales of
Phantasia that some sound studder is present when walking on the world
map, almost like the sound is degrading due to frame drops or something. Also noticed that Far East of Eden Zero won't run. Even without the graphics packs you should still get an error message on screen. These may have been reported, but I couldn't search this thread for them. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 25, 2006 3:06 pm Post subject: | |||
|
|
|||
|
Next
version will be faster. The emulator must run at full speed to prevent
choppy sound, as I lack the skill to dynamically resample audio on the
fly. FEoEZ lacks all support, including for its memory mapper. I wouldn't expect anything from the game until I get hardware to start running my own tests and start emulating the chip. An update to aniki :
From what I know, you can continually trigger NMI interrupts by not reading $4210, and continuously writing 0, then 1 to NMI enable bit in $4200. The game appears to be doing just that... |
|||
New Member
Joined: 07 Dec 2005
Posts: 4
| Posted: Tue Jul 25, 2006 5:24 pm Post subject: | |
|
|
|
| FFVI (J): During the opening demo, the smoke effect from the smokestack seems wrong. Is it a bug? I've never seen it on a real cart. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 25, 2006 5:53 pm Post subject: | |
|
|
|
| It happens in the real game, from what I've read elsewhere. Something to do with the game trying to perform more effects than it has HDMA channels for, and subsequently when text is onscreen you lose the translucent smoke effect, or something like that. I forgot the exact details. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jul 25, 2006 9:38 pm Post subject: | |||||
|
|
|||||
If you're on the fringe of getting full speed, as I am, it's possible your fps is dipping to 58/59 in parts of games that have more intensive renders. I wouldn't worry about it in the wip versions. The official will likely clear this up. Then again, that ToP stuff could be normal. Didn't the game use tricks to get more sound channels? If you're getting crackling, it's probably an fps issue.
Thanks for mentioning this. I forgot all about SPC7110. It's a data decompressor chip. The following games use it: Far East of Eden Zero, Momotarou Dentetsu Happy, and Super Power League 4 |
|||||
Rookie
Joined: 27 Jan 2005
Posts: 16
| Posted: Tue Jul 25, 2006 10:09 pm Post subject: | |||||
|
|
|||||
Is v0.016 posted on Byuu's site considered WIP? I don't know if other versions/builds are out there, but I used this version from his site. And v0.017 is supposed to have massive speed-ups, then?
I think you're right in that it's a slow-down issue that's causing the crackling. ZSNES doesn't have this problem so I think it's a speed-related issue. On another note, are there plans on implementing some sort of save state function? |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jul 25, 2006 10:23 pm Post subject: | |
|
|
|
| Sorry,
I thought you were using the 27a wip that got posted. In any case, you
should be getting more speed in the next version which may resolve it
for you. What byuu has revealed thus far about savestates is that they might be possible with the new core, but they were thought to be a tradeoff for improved accuracy, and everyone voted for accuracy. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jul 25, 2006 10:43 pm Post subject: | |
|
|
|
| I
can implement savestates, but I can only capture them when all units
are at a suitable stopping point. The more "safe" savestate points I
have, the slower emulation gets. The less I have, the longer it will
take to capture a savestate. I'm thinking of making a tradeoff where I disable synchronization and run each component to a safe sync spot. The worst case is that your savestate has one opcode that is opcode-accurate instead of bus-accurate, but savestates are as finely grained as in ZSNES and SNES9x. But I don't know just yet... I'm not interested in adding savestates right now. And FitzRoy, you're also missing the ST010, ST011 and ST018 special chips that I don't support. I also don't support the BS-X flashcart, or any input devices other than the joypad. Quite a lot of progress, but at the same time quite a ways to go, heh. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jul 25, 2006 11:22 pm Post subject: | |
|
|
|
| Yeah, I'll just group all the BS stuff together for now, and I've added the seta chips. I'm sure you're aware of peripherals like the mouse, multitap as well. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 3:01 am Post subject: | |||
|
|
|||
|
Fans of homosexual fighters the world over rejoice. This game uses some truly evil code.
The write to $4200 enables NMI during the second to last cycle (technically at the very end of it), and NMI tests to see if it should be fired at the very start of the last cycle, so thusly an NMI triggers before sta $0201, and then the game reads $0201 and updates $4200 with it, and then jumps into an infinite loop. On hardware, there is a slight delay between writing to $4200 and when NMIs can trigger. Figuring out how long this delay really is is nigh impossible, sadly. I was able to use a delay of 2 clocks (the smallest time measurement possible) which should always account for this edge case, and it's the only way to execute this edge case that I'm aware of. As a result, Chou Aniki is now playable. As well, all of my NMI and IRQ tests plus timing tests still pass, so this is a correct hardware pass with no inaccurate reversions. An interesting side note, other emulators manage to play this game because they do not properly trigger the NMI after the write to $4200. On a real SNES, it is possible to repeatedly trigger NMIs by strobing $4200.d7, so long as V>=225, and $4210 was not read once it was set at V=225. Other emulators thusly skip right over the interrupt, and get stuck for a frame until NMI triggers, and then emulation continues. This code required clock-fine IRQ delay timing, so I thusly modified the Wild Guns fix to use the same code. Very surprisingly, there was no speed loss! But now the "Wild Guns fix" is much more hardware accurate. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 26, 2006 3:24 am Post subject: | |
|
|
|
| Good stuff. And then there were 2. Should be interesting to hear what EWJ2 is doing. | |
Rookie
Joined: 27 Jan 2005
Posts: 16
| Posted: Wed Jul 26, 2006 3:26 am Post subject: | |
|
|
|
| Just
tested the new NINJA beta prog. by hard-patching my star ocean ROM with
the dejap release. ZSNES renders it fine but this is what bsnes shows
at the title screen: |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Jul 26, 2006 3:53 am Post subject: | |||||
|
|
|||||
Two what? How are you sub-dividing the buglist so that there are only "two" left?
I don't think byuu gives a shit about hard-patched ROM translations. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 4:04 am Post subject: | |||||
|
|
|||||
|
Another fix. If HDMA or
HDMA init trigger on a channel while a DMA is active on that same
channel, the DMA transfer will be stopped. The new finding was that
this also applied to HDMA init. It doesn't fix any games. It's another
one of those "nobody will ever notice" fixes that just give me a bit
more hardware accuracy. For emulator authors only : byuu.cinnamonpirate.com/files/snestest_072506.zip Copy and paste link. test_dma.smc will verify this behavior. It does not require H/DMA bus sync timing and is pretty flexible to non-exact timing. But it's still too strict for ZSNES since that emu runs an extra scanline per frame, making the test miss HDMA init.
I think he means two left that I can likely fix. There are five known confirmed bugs at this point.
You thought correctly. If someone makes an SO cart and verifies this doesn't happen, I might look into it. Most likely the translation is abusing an inaccurate memory map or writing to VRAM outside of vblank, probably the latter. My suspicions are likely confirmed by the fact that the original Japanese game plays just fine. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jul 26, 2006 10:30 am Post subject: | |
|
|
|
| Well,
after going through plenty of roms, I think I've finally found some
more bugs to report. They do not occur in zsnes or super sleuth, and
are also present in .016. Cosmo Police Galivan II (J) - hangs at stage start. G.O.D - Mezameyo to Yobu Koe ga Kikoe (J) - upper part of screen flickers in character menu transitions. Kessen! Dokapon Oukoku IV - Densetsu no Yuusha-tachi (J) - hangs at king's throne after first character selection. La Wares (J) - hangs right after title screen. If I've erred on any of these, let me know. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 2:20 pm Post subject: | |
|
|
|
| I'd like verification that GOD doesn't do that on hardware if possible. Which it's probably not. | |
Hazed
Joined: 29 Jul 2004
Posts: 86
Location: USA
| Posted: Wed Jul 26, 2006 4:54 pm Post subject: | |
|
|
|
| Actually, I do see some sort of flicker on menu transitions on the top half of the screen in G.O.D. on my SF7. This may or may not be irrelevant, but on the real snes, the flicker was solid, while it looked like a bunch of bars on bsnes. (NOTE: only some of the menu transitions exhibit the sort of flicker that shows up as a bunch of bars in bsnes.) | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 5:28 pm Post subject: | |
|
|
|
| Thank
you zidanax, the black area is solid on my latest WIP. At least I think
they all are. I've only tested a few menus. Some don't flicker at all,
some show a ~40-80 pixel black box at the top for a single frame. If wip37 is still exhibiting the scattered black bars, then we still have a problem possibly. So then this exists on real hardware. Thanks a million for confirming this for me. Also, good news. anomie fixed Super Conflict because he is the ubercoder :D Hats are off to him on this one. Full credit to anomie. When OBJ is exactly at 256 (and only 256), it's a special case and all the tiles of the sprite still count for time over (of the 34 possible tiles loaded), even though none of them are visible. So, at least one, possibly two bugs to safely remove. |
|
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Wed Jul 26, 2006 6:00 pm Post subject: | |||
|
|
|||
That's not correct for Super Sleuth. The only time a pending NMI is cleared is when $4210 is read and at the start of scanline 0. Last edited by Overload on Wed Jul 26, 2006 6:25 pm; edited 2 times in total |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 6:09 pm Post subject: | |||
|
|
|||
http://byuu.cinnamonpirate.com/temp/aniki.txt
Super Sleuth v1.04.5 does not trigger an NMI, it keeps running until it gets stuck in a loop waiting for NMI, that waits until presumably the next frame, but well after the sta $0201 where it should fire. Also, my apologieis if I appear condescending about this. I'm just trying to share my findings and help get these bugs fixed in all emulators. |
|||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Wed Jul 26, 2006 6:24 pm Post subject: | |||||
|
|
|||||
Sleuth doesn't trigger an nmi because the code is executed on scanline 82, well before the nmi trigger point.
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 7:28 pm Post subject: | |||||
|
|
|||||
o.O well then one of us has some serious timing issues :P
|
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Jul 26, 2006 10:56 pm Post subject: | |||
|
|
|||
It won't *hang* if when asked do you want Human or CPU, you answer CPU for the controllers you don't have plugged in. If you answer Human, make sure to press A on the appropriate controller. It's not a hang, as it's just waiting for you to press A, and you are not. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jul 26, 2006 11:11 pm Post subject: | |
|
|
|
So then, GOD was not a bug. This is not a bug. Player 2 has to select a character, and then Player 1 has to select a player for Player 3. The game is expecting a Super Multitap 5, but you can botch your way through it if you can read the menus.   Input bug. When auto joypad polling is off ($4200.d0 = 0), you can still read the last values updated to $4218-$421f. These two games turn that off, and bsnes was returning 0x00 in that case. Both are now fixed. As always, ignore the version number. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 27, 2006 2:25 am Post subject: | |
|
|
|
| Thanks, I can not read Japanese. Nice to know that two of those were not bugs, and it's cool that the other two were the same one. I'll have to find a list of multi-tap (j) games sometime. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Jul 27, 2006 2:44 am Post subject: | |||
|
|
|||
Isn't it funny that NSRT has this option to printout a list of multitap games? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 27, 2006 4:43 am Post subject: | |
|
|
|
| Not really, because I just spent the last ten minutes trying to find it. | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Jul 27, 2006 4:51 am Post subject: | |
|
|
|
| Right clicking is your friend (this is a huge hint). _________________ FF4 research never ends for me. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 27, 2006 5:04 am Post subject: | |
|
|
|
| Oh, so it's front-end specific. I was looking in the readme files and found nothing. Turns out Kessen is not among those listed anyway, so it wouldn't have helped any. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Jul 27, 2006 5:09 am Post subject: | |||||
|
|
|||||
Multitap is considered a special controller. This feature is not frontend specific anyways. _________________ FF4 research never ends for me. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jul 27, 2006 5:32 am Post subject: | |
|
|
|
| Yeah, I just didn't see it. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jul 27, 2006 8:06 pm Post subject: | |
|
|
|
| Eh,
little harm done. Wasted 5 minutes of time I'd otherwise be listening
to music and chatting on IRC testing them. And you did find a valid
input bug that affected at least two games, so yay for that. Now then, I found a fix for Earthworm Jim 2 (E). If I bump the clocks per scanline up from 1364 to 1366 or above, the sound is identical to EWJ2 (U). The only problem is I can't test this on real hardware since I lack a PAL SNES + copier + TV + adapters - whatever of that stuff I don't need. Point being, I can't verify it's correct. But it's a good indication it is since the game works now. The fix would only apply to the PAL region, and not the verified NTSC region. Should I add the fix, or can anyone confirm/deny how many clocks there are per scanline on PAL systems? I could make a test ROM to determine this if anyone can run it on a PAL copier for me. EDIT: I can also fix this by underclocking the CPU. Since we don't definitively know the CPU speed of PAL SNES units, I think that might be a better option. The CPU then operates at the same clock/scanline rate as NTSC, but technically since the CPU is running a little slower, the CPU gets APU updates quicker, and it also fixes the problem. So now I need to decide between increasing the clock/scanline ratio, underclocking the CPU, or doing neither since they cannot be verified on hardware by myself. Last edited by byuu on Thu Jul 27, 2006 8:32 pm; edited 1 time in total |
|
Retrosexual
Joined: 28 Jul 2004
Posts: 1534
Location: the tug boat
| Posted: Thu Jul 27, 2006 8:27 pm Post subject: | |
|
|
|
| I could run it on my copier, and set the snes to pal timing. should fully simulate a PAL snes. _________________ ultimate immortality  |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 28, 2006 4:09 am Post subject: | |
|
|
|
| Ok,
this WIP rewrites the input code and modifies the PAL clock speed.
Fairly major changes. Ideally, this will wipe out four bugs without
causing any new ones since wip37. Bug fixes : Earthworm Jim 2 (E) - adjusted PAL CPU clock speed. Please test for *new* sound problems in PAL games La Wares (J) + Galivan 2 (J) - no longer return 0 when auto joypad is off for polling $4218-$421f Super Conflict (J) - added anomie's new OAM RTO findings to fix title screen The input code was almost completely rewritten to simulate real hardware more. As such, it's very possible there are new input bugs. Ok, so then byuu.cinnamonpirate.com/files/bsnes_v016_wip38.zip Please only download if you intend to test games and report feedback. This version is slower than normal, lacks ZIP+JMA loading, and has the debugger enabled (that is only useful to me, it lacks a functional user interface) which slows down emulation even more. eg you're better off with v0.016 official if you just want to run games. As always, please don't post this link anywhere else, or I will be forced to remove the file to conserve bandwidth. If anyone posts bugs that hasn't tested against wip37, can I please have someone with wip37 verify/deny the bug presence in wip37 as well as in 016 official? wip37 isn't on my website because I don't have a lot of web space to spare. Thank you to everyone in advance for helping. |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Fri Jul 28, 2006 4:51 am Post subject: | |
|
|
|
| Bsnes
doesn't seem to like ufo headers. The Mortal Kombat 3 (U) rom I have
doesn't seem to load up at all unless I strip it or change it to a
different one. You could just have it ignore them I suppose. Edit: I took a peek at the info in the debugger and it's detecting it as a lo-rom for some reason. Ucon64 said it was a Hi-rom though so something isn't right. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 28, 2006 5:36 am Post subject: | |||
|
|
|||
Seems to work fine for me.
bsnes ignores headers. The only thing that will throw it off is if the ROM size is not an even multiple of 32k (or multiple of 32k + 512-byte header), so eg a 32,769 byte file would make bsnes unable to determine if the image has a header or not. Anyway, now that I have a database and support for various PCB mappers, I've no intentions of continuing these header detection games. If a game fails my detection code at this point, that game will get added to my database so that it will no longer fail. My time is too limited to play games with. --- Didn't mention this before, but aside from a hackish Uniracers fix I won't be adding to the emulator, I can't fix any of the remaining bugs myself. Hopefully they will resolve themselves somewhat with time. But I think 3 known bugs is the shortest you're ever going to see my bug list. And I expect it to grow quite a bit as more people get to try out the newer builds with more games. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jul 28, 2006 7:16 am Post subject: | |
|
|
|
| Good
job squashing all those bugs this past week, byuu. Kudos to anomie for
fixing Super Conflict. I think for "shared" bugs like that and
Uniracers, it's only a matter of time. I also hope someone steps up and
helps you verify those PAL mysteries. There HAVE to be people on this
forum who live in Europe and have copier setup, but you might want to
ask on your website as well. So far on the new wip, I haven't run into any new issues. I'll be on vacation for the next 3 days, though, so let's hope people are seriously going through lots of games, and not just playing the ones they like. Just a few things I want to mention in case you're close to a release: 1. In windowed mode, bsnes does not suppress the windows screen saver, so it pops up annoyingly while you're playing if you use gamepad. 2. In windowed mode, if you mouse over something like the windows clock while a game is playing, the emu slows to a crawl (similar to what was happening when you had the transparent config menu). If this is unfixable, I understand. Just being thorough. 3. I'm wondering why the frameskip setting does not save on exit. If there's a reason for this, I'd like to know. I think users would like this feature. |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Fri Jul 28, 2006 7:41 am Post subject: | |
|
|
|
| God I'm such a fucking dope. It was because the rom was interleaved. Ho ho sorry for the false bug report byuu. Anyway as far as reporting bugs I really have no more to report. I only play a hand full of snes games and don't want to go through thousands of awful games. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jul 28, 2006 3:21 pm Post subject: | |||||||
|
|
|||||||
|
That's cool. Someone will eventually test the obscure ones and find problems. So long as everyone's favorite games are all working though, the WIPs are at least at a release-grade quality now. If everyone's input controls are working fine in games, then likely my controller changes are safe. I'd actually be pleasantly surprised if that turned out to be the case. I completely rewrote the way it works to truly use a bitshifter on $4016/$4017, and buffered registers for $4218-$421f.
Don't know how to do this.
Maybe setting bsnes priority to high would fix it? I wouldn't want to do that for the default, because it would make other apps sluggish on slower systems.
It was intentionally not saved on exit. Though it's a one word change to make it save. I've been meaning to tie a default frameskip rate for speed regulation modes, such that say 2x speed would raise the frameskip for you, whereas 0.5x would not. Perhaps I'll tie in frameskip saving at that time. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Jul 28, 2006 7:00 pm Post subject: | |
|
|
|
| Someone on the zsnes team might know about the screensaver thing, since it behaves that way. As for the frameskip - only reason I mention is that for a person using a 1ghz computer with bsnes, they're likely going to want a frameskip setting of 1, always. Currently, though, they have to set it back every time they start the program. |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Jul 29, 2006 12:42 am Post subject: | |
|
|
|
| Nice
to see the degugger is back in(even if it's not fully functional for
regular users). Will it stay in the next major release? Anyway, the speed by which you've been recently fixing emulation accuracies/game bugs issues is nothing short of amazing.( not forgetting everyone who has helped either of course) I'll try to test a number of games (mostly obscure japanese games). |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Jul 29, 2006 3:13 am Post subject: | |||
|
|
|||
Probably not, since I think it decreases speed slightly, and I think byuu puts a high priority on speed, right now. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jul 29, 2006 4:07 am Post subject: | |
|
|
|
| It incurs a 10% speed hit and is only useful to me. It makes no sense to enable it in official releases in its current form. I'm thinking about a two-way communication between the core and UI (probably through the SNES base class) to allow toggling of tracing features directly from the core. This would bring bsnes up to par with say, SNES9x LT, and work on Unix platforms as well. That might be something I can squeeze in before v0.017 is released, but don't count on it :/ |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Jul 29, 2006 12:00 pm Post subject: | |
|
|
|
| Byuu, i actually do have a pal snes, with a pal WildcardDX and a pal tv. if you host your test roms somewhere i can run them on my snes and send you the results my wildcard can run upto 32mbit I also have an extremely sucky tv capture card, but as there is so much static on it its not really usefull for extracting information |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jul 30, 2006 10:03 am Post subject: | |
|
|
|
| Thanks, I'll try and think up some tests and then send them your way :D Side note: rewrote the UI-side input system so that my ui/input class is platform-independent. As a result of the rewrite, there is now primary+secondary button mappings instead of key+joy mappings. So you can now map say the start button to keyboard.q + joypad0.button1, keyboard.q + keyboard.p, or joypad0.button1 + joypad1.button1. You can also use the secondary input to make key pairs, such as up+down both mapped to q, and left+right both mapped to w. Not very practical, but it's there. |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon Jul 31, 2006 8:04 am Post subject: | |
|
|
|
| By chance were you able to resolve the crackling sound issue with tripple buffering? That would be spectacular to have smooth scrolling and sound. Also would be awesome is a resharping dial for bilinear filtering. I've seen this function in other programs and it really helps get rid of the blurring effect caused by bilinear filtering, while still retaining the advantage of non-warped looking pixels. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jul 31, 2006 12:44 pm Post subject: | |
|
|
|
| Nope, not been able to resolve triple buffering issues. I agree, smooth video+audio would be awesome. My idea for bilinear filtering was to make a hybrid system where draw a pixel filtered image to the screen, then a translucent bilinear filtered image on top of it. You have a slider to control the luminance of the bilinear filtered image. The only problem is it looks terrible when you're at a non-native multiple of the SNES internal resolution of 256x224. So I was thinking, scale the image to 512x448 in this manner, and then use bilinear to get it up to 1024x768, etc. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 04, 2006 5:33 am Post subject: | |
|
|
|
| Ok, one semi-large change if anyone wants to test. byuu.cinnamonpirate.com/files/bsnes_v016_wip42.zip This is built for maximum speed. No debugger, PGO enabled, favor speed, no c++ EH (so no ZIP/JMA), and a new addition: links against msvcrt instead of libcmt. By using msvcrt and some evil linker hacks I was finally able to build the SDL port again on Windows. So now I just need to focus on cleaning that up so the next release will build on Linux out of the box. Anyway, I tried it on the non-SDL port for the hell of it, and noticed not only a 20% drop in EXE size, but a ~10-11% speedup as well. Only problem is it requires msvcr80.dll, and I have no idea how common that file is. So, that's what this wip is for. Does this version work for you, and if it does, does it run faster? A direct FPS comparison between v0.016 and v0.016.42 would be helpful if you're not sure. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Aug 04, 2006 6:32 am Post subject: | |
|
|
|
| Hmm, won't run for me. Says: this application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Aug 04, 2006 6:34 am Post subject: | |||
|
|
|||
|
Do you have that DLL? _________________ savestate editor: vSNES latest public version
|
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Aug 04, 2006 6:38 am Post subject: | |
|
|
|
| I get the same error, so I guess I'm missing the DLL. edit: Dled the dll (or what is supposed the be the DLL anyway), copied it to the windows system directory but I get the same error. I suppose the dll need to be registered or something. Last edited by Dmog on Fri Aug 04, 2006 6:45 am; edited 1 time in total |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Aug 04, 2006 6:41 am Post subject: | |||||
|
|
|||||
Don't guess, do a search. _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Fri Aug 04, 2006 1:48 pm; edited 1 time in total |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Aug 04, 2006 8:30 am Post subject: | |
|
|
|
| I had the dll in my system and system32 directories. No go. File won't register either. Loaded but no entry point found. | |
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Fri Aug 04, 2006 9:18 am Post subject: | |
|
|
|
| Hrm
on my xp system it loaded msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fd8b3b9b1e18e3b_8.0.50727.42_x-ww_0df06bcd\
Instead of the C:\windows\system32 folder. It's probably something with
the registry, but I haven't looked that closely at it yet. Edit: Ah it needs special policies and whatnot. I think it was either installed with the .net 2.0 framework or when I installed visual C++ 2005. Edit2: I changed the directory name just incase those numbers specifically identify the file I have. I haven't a clue how this actually works. I don't mess around with windows enough, sorry. |
|
Rookie
Joined: 30 Jul 2006
Posts: 29
| Posted: Fri Aug 04, 2006 12:35 pm Post subject: | |||
|
|
|||
yeah, winsxs is confusing. you need to find the manifest for the dll and stick both it and the dll in the apps folder. if im not too busy doing your mom tonight, i'll upload it for you. _________________ abusing your punk ass since 2006 |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Fri Aug 04, 2006 12:46 pm Post subject: | |||
|
|
|||
That is because you already have the correct runtime installed. You really shouldn't mess with anything inside the WinSxS folder. Read this. Also the post about an installed binding redirect policy here. This file should be installed with Visual Studio 2005 RTM, or the redistributable package. The older version number in the manifest would seem to indicate that it was either compiled with beta 2, or an older manifest file was left over and not regenerated by the newer compiler/linker. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 04, 2006 2:23 pm Post subject: | |
|
|
|
| It's too bad Microsoft can't get their shit together anymore. I'm not adding another DLL hell to my app. If this doesn't work out of the box for you guys, then I'll just take out /MD. Thanks for testing. | |
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Fri Aug 04, 2006 3:54 pm Post subject: | |||
|
|
|||
Oh well. When you said a 10% speed gain, you meant compared to 0.016? OutrightOwnage, please don't stink up the thread with your gettho crap. Thank you. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 04, 2006 4:02 pm Post subject: | |
|
|
|
| A 10-11% speed gain from v0.016.38. In other words, adding /MD causes DLL hell and gains 11% speed. Removing it increases EXE by 200kb, lowers speed by 11%, and removes Microsoft-incompetence hell. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Aug 04, 2006 4:06 pm Post subject: | |
|
|
|
| Works for me, out of box. I just unzipped and ran the EXE. I haven't loaded a game yet or done any speed tests yet. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Fri Aug 04, 2006 4:33 pm Post subject: | |
|
|
|
| Works well out of the box for me too. Framerate is well in excess of 100fps, so you have done an excellent job on speed here. The single issue I do have is that I am having problems forcing a fully stretched fullscreen resolution that corresponds to the native resolution of my LCD. Going out of fullscreen causes the emu to be permanently minimised to the taskbar. So, you have to use multipliers to get a larger image to avoid this issue. I have found that "0;1;0;3;true;false;false;256;224;1280;1024;60;false" works pretty well for me (but with borders all around the image). _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group Last edited by Clements on Fri Aug 04, 2006 5:50 pm; edited 2 times in total |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Fri Aug 04, 2006 5:11 pm Post subject: | |||
|
|
|||
Oh I wasn't about to change anything around. I was just trying to figure out how it was installed. I know enough not to screw up my system thankfully. Ah, thanks for that link by the way. |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Fri Aug 04, 2006 6:17 pm Post subject: | |||||
|
|
|||||
Well, you did say you installed Visual Studio 2005, which includes the CRT/STL/ATL/MFC debug and release runtime modules in WinSxS, and the .NET 2.0 Framework. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 04, 2006 6:53 pm Post subject: | |||
|
|
|||
Yes, that is a problem. I tried reducing the render size to the current screen size, but this still fails. If I force the window size to be even smaller to accomodate for the window borders, it works. But that seems sloppy. Honestly, I liked my old system more, with allowing the user to select a default windowed and default fullscreen mode, and have each mode give you the option to set it as a windowed or fullscreen mode. |
|||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Fri Aug 04, 2006 6:55 pm Post subject: | |
|
|
|
| Haha l I spend more time drinking then chatting with people so I tend to screw up alot. Er if I'm talking all weird just ignore me I guess. | |
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Fri Aug 04, 2006 8:03 pm Post subject: | |
|
|
|
| msvcr80.dll is very common.You can find it in your Mozilla Firefox folder Just copy this one and paste to your bsnes folder and you'll be doing great.No need to put it in System32 (DLL hell) ...at least it's included in the Bon Echo (2.x) and Minefield (3.x) builds,not sure about 1.5.0.6 |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Aug 04, 2006 9:48 pm Post subject: | |
|
|
|
| I don't have that dll in my firefox 1506 folder, nor does bsnes work when I put the dll in my bsnes directory. I'd be surprised if byuu changed his stance. Too much of a hassle and too much to ask if it requires installing Visual Studio. If the required file(s) could somehow be bundled with bsnes to work, then I can see it being used. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 04, 2006 10:11 pm Post subject: | |||
|
|
|||
I'm going to make it a compile-time option, much like SSE2 support is now. If you compile it yourself, and add in SSE2 and MSVCRT linking, you'll gain a 20% speedup. Or if someone wants to be generous and host the binaries, we could do that as well. I'm also considering either runtime checking for d3dx9*.dll, or just making screenshot capture with D3D a compile-time option as well. No more DLL hell for me. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Aug 04, 2006 10:36 pm Post subject: | |
|
|
|
| Good
stuff. That way, not even the least savvy xp user will be hit with a
missing dll message. Bsnes will just work for everyone out of the box.
Although when SP3 comes out, you might be able to stick that screenshot
one in again. PS: Anyone running a vista beta know how well bsnes works with it? |
|
Rookie
Joined: 30 Jul 2006
Posts: 29
| Posted: Fri Aug 04, 2006 10:52 pm Post subject: | |
|
|
|
| for whoever doesn't have .net 2.0 installed: http://rapidshare.de/files/28215411/Microsoft.VC80.CRT.rar.html just extract the whole folder in there into where bsnes is, it should work. you're very welcome. whatever. _________________ abusing your punk ass since 2006 |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Aug 04, 2006 11:14 pm Post subject: | |
|
|
|
| Yep, that works. Thank you. It was the manifest file I was missing. It's too bad all these files can't be bundled with the exe, then the choice would be simple. | |
New Member
Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
| Posted: Sat Aug 05, 2006 3:49 am Post subject: | |
|
|
|
| Hi there! I may or may not have two bugs to report with bsnes v0.016, depending on whether Secret of Mana and Secret of Evermore use any sort of special chipsets. Is there a place that I can get information on which chipsets went into which cartridges? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Aug 05, 2006 4:01 am Post subject: | |
|
|
|
| Hi Mr. Business. Download NSRT 3.3 for windows from here: http://nsrt.edgeemu.com/forum/viewtopic.php?t=602 In the front end program, browse to the folder containing your roms and scan them. Under "type", if it says anything other than normal, that's a special chip. SoM and SoE do not use special chips. However, there's a good chance the bugs you're referring to have already been fixed since .016. If you're using .016.42 though, we would be interested to hear about them. |
|
New Member
Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
| Posted: Sat Aug 05, 2006 4:18 am Post subject: | |
|
|
|
| I'm
dreadfully sorry to follow a question with another question, but where
can I download the current working version of bsnes from? I've only
managed to find 0.016 links. Is it somewhere in the thread here? I
could definitely determine whether or not the bugs occur in the latest
version, were I in possession of the latest version. Again, I apologize for my ignorance. The thread is very large, and so finding these things out is slightly difficult. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Aug 05, 2006 5:19 am Post subject: | |
|
|
|
| It's on the previous page: byuu.cinnamonpirate.com/files/bsnes_v016_wip42.zip Make sure you download the files from the link 5 posts up and put them in your bsnes folder. |
|
New Member
Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
| Posted: Sat Aug 05, 2006 5:45 am Post subject: | |
|
|
|
| Does this new version not read roms from inside of zip and rar files? Well, whatever the case: 1. The bug that I found in Secret of Mana has been resolved in the latest version. 2. The Secret of Evermore bug appears to still linger.  Any games saved under bsnes become corrupted like so, and the saves cannot be reloaded at a later date. So, if one utilizes the game's save feature while running the game in bsnes, the save will be corrupted. Hopefully that second one hasn't already been reported. If it has, I apologize. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Aug 05, 2006 6:07 am Post subject: | |||
|
|
|||
No zipped file support in this wip build |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Aug 05, 2006 6:58 am Post subject: | |
|
|
|
| Thanks for your input, I've confirmed the bug. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sat Aug 05, 2006 7:38 am Post subject: | |||||
|
|
|||||
ipher? _________________ savestate editor: vSNES latest public version
|
|||||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Aug 05, 2006 12:14 pm Post subject: | |
|
|
|
| Speed regulation doesn't seem to work for me in wip42. I get 75+ fps in most games | |
Rookie
Joined: 30 Jul 2006
Posts: 29
| Posted: Sat Aug 05, 2006 12:21 pm Post subject: | |||
|
|
|||
why couldn't they be? bandwidth issues? _________________ abusing your punk ass since 2006 |
|||
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Sat Aug 05, 2006 1:36 pm Post subject: | |||
|
|
|||
|
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Aug 05, 2006 2:02 pm Post subject: | |||||
|
|
|||||
Ah. My bad. It does make more sense for speed testing purposes obviously I'll report the results later on. |
|||||
New Member
Joined: 24 Jul 2006
Posts: 3
| Posted: Sat Aug 05, 2006 2:42 pm Post subject: | |||
|
|
|||
Running Vista 5472 build here. bsnes WIP42 works pretty good, but the sound is ultra crappy. This could be the beta Creative drivers, but I kind of doubt it. Sounds just like it would on XP if frames dropped below 60fps ... except on Vista it is CONSTANT. Edit: Found a problem however... If you shrink bsnes, then restore it, video is lost, black screen. Got to restart emulator to get video back. Last edited by Kazuma on Sat Aug 05, 2006 2:54 pm; edited 2 times in total |
|||
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Sat Aug 05, 2006 2:47 pm Post subject: | |
|
|
|
| The
.srm created by bsnes for Secret of Evermore isn't loaded in ZSNES
either. After comparing it to a .srm created by ZSNES most of the empty
space was filled with 0x00 in bsnes where it was filled with 0xFF in
ZSNES. Edit: I just changed this and it's still not fixed. There is probably some problem in the SRAM access functions. Big Sky Trooper seems to have similar issues. Edit 2: Big Sky Trooper is fixed by actually mapping SRAM to banks F0-FF for LoROMs and by initally filling the SRAM with 0xFF. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Aug 05, 2006 4:49 pm Post subject: | |||||||||||
|
|
|||||||||||
Please don't expect RAR support in any of the major SNES emulators.. JMA is the compression of choice if you need the space.
Worry about Vista being out first before worrying about Vista compatibility.
Make sure triple buffering is NOT enabled. Any sensitive frame drops will always cause choppy sound. It is because that is how the original system (and also emu) works
byuu is already aware of this and it will probably be corrected soon. _________________ FF4 research never ends for me. |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Aug 05, 2006 5:00 pm Post subject: | |||||||
|
|
|||||||
I will add a PCB mapper to Secret of Evermore and see if it helps. I'll also set SRAM to 0xff, then.
Mirrors SRAM to $[20-3f|a0-bf]:[6000-7fff]. Fairly typical HiROM game. Might be failing due to overmapping instead, as I map HiROM and LoROM SRAM into the generic "FuckROM" map used for PCB-less carts.
Nobody has volunteered the PCB code for this cart. I will have to either hackishly add f0-ff always for LoROM only, or leave it as is until we get PCB info.
kode54 gave me a fix for it. I forgot to e-mail it to myself, though, so it isn't on my home PC. But it should be easy enough to find. |
|||||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sat Aug 05, 2006 6:17 pm Post subject: | |||
|
|
|||
Oh wait, what's this? Did you just RAR up and upload something that Microsoft provides their own redistributable installer package for, which I just linked to a few posts ago? And uploaded it to RapidShare no less? You fail. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Aug 05, 2006 8:43 pm Post subject: | |||||
|
|
|||||
Legal issues, I'm thinking. |
|||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sat Aug 05, 2006 10:30 pm Post subject: | |
|
|
|
| I think the EULA only forbids redistributing VC++ debug builds, but I don't feel like digging out the DVD and digging through the EULA to find the exact terms. | |
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Aug 06, 2006 12:33 am Post subject: | |||
|
|
|||
Well, it's best to get out the word that there's possible bugs in their software when ran in vista, that way you can expect the possible zomg it doesn't werk in vista posts they'd get. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||
Rookie
Joined: 30 Jul 2006
Posts: 29
| Posted: Sun Aug 06, 2006 12:35 am Post subject: | |||||
|
|
|||||
hmm, 434 kb vs 2.6 mb. maybe it makes no difference to you, but some people still care. _________________ abusing your punk ass since 2006 |
|||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sun Aug 06, 2006 1:24 am Post subject: | |
|
|
|
| Haha, dialup. I had no trouble pulling CD images over 56k years ago, so what's a few megabytes? It's still better to point people to the official download, especially since it can stick the files in the correct place if users are running Windows XP or newer. Plus, the link is likely to last a lot longer than an anonymous RapidShare download. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 06, 2006 2:22 am Post subject: | |||
|
|
|||
|
Secret of Evermore is fixed. Thank you for the bug report, Mr Business. Game is performing a DMA from $2180 to SRAM. I'm pretty sure I read somewhere that this wasn't possible. But apparently, it is. The game has actually been broken since the Krusty Super Funhouse fix. This may or may not fix other games.
|
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Aug 06, 2006 9:03 am Post subject: | |
|
|
|
| Great Work on fixing Secret of Evermore Bsnes gets better every day! |
|
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Sun Aug 06, 2006 4:03 pm Post subject: | |||
|
|
|||
You can't transfer from WRAM to WRAM using dma. There is nothing wrong with transferring from WRAM to SRAM. WRAM to WRAM doesn't work because dma is trying to read and write to WRAM in the same cycle which obviously isn't going to work. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 06, 2006 6:03 pm Post subject: | |
|
|
|
| I
see, thank you. TRAC was very helpful explaining this to me as well.
Though I'm still fuzzy why the WRAM chip has pins for A0-A16+A22...
very weird, specifically the A22 pin. Anyway, since $2180 reads always
end up accessing WRAM, we can just check AAddress. Something like... read = bbus == 0x80 && ((abus & 0xfe0000) == 0x7e0000 || (abus & 0x40e000) == 0x000000)) ? regs.mdr : bus->read(abus); Obviously, other checks go in there as well. Such that DMA/HDMA regs are blocked this way, and A bus accesses to the B bus range go to open bus, as only carts could possibly respond to an A bus access of $0021xx, but none do to our knowledge. Also, I have a question Overload... in your PCB documentation you describe HiROM boards such as SHVC-1J3M-20 as : $[00-3f]:[8000-ffff] ROM (mirror) $[80-bf]:[0000-ffff] ROM (mirror) Is that a mistake, where both should only map to 0x8000+? I know 0x0000-0x1fff would be overasserted by WRAM, and 0x2000-0x5fff would be MMIO, but this is saying that: $006000 = open bus $806000 = ROM $006000 Is that correct? |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Mon Aug 07, 2006 12:55 pm Post subject: | |||
|
|
|||
Another bug bites the dust. Btw, after performing a few speed tests I've concluded speed testing bsnes would not be very useful on my system. I set frameskip to 0 and disable speed regulation, but what happens is that I get a steady fps decrease that doesn't have anything to do with the game itself. Example: wip42 1st try with the above settings: Super Puyo Puyo 2 selection screen. Start at 80 drop progressively at 55. 2nd try Close and restart wip42 load same game. Start at 60 drop to 45... 3rd try: start at 50 drop to 35... And then it pretty much stays there no matter how long I wait or how often I restart b. I experience that with wip30 and 0.016 too... Basic PC specs are 2.4ghz P4 512ram. Not sure what's causing this. |
|||
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Mon Aug 07, 2006 7:56 pm Post subject: | |||
|
|
|||
Definately a mistake, I don't know how I missed those. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 07, 2006 9:09 pm Post subject: | |
|
|
|
| Ah, so it's supposed to be $[00-3f]:[8000-ffff] and $[80-bf]:[8000-ffff], right? I assume that's pretty obvious, but just in case. This also throws off my whole "simple memory mapper" approach. I was just mapping as: map(bank_lo, bank_hi, page_lo, page_hi, type, start = 0); map(0xc0, 0xff, 0x00, 0xff, ROM); //map &ROM[0] to $[c0-ff]:[0000-ffff], mirror ROM as needed But now with the way the ROM is actually half-mirrored, I'll be forced to loop for each bank ala : for(int i=0x00;i<=0x3f;i++) { map(i, i, 0x80, 0xff, ROM, 0x8000 + (i * 65536)); } Which is much less... language friendly. Was trying to design all of the memory maps using define wrappers so that any language with decent macro capabilities could easily use them. If it's just this one thing that uses this, I guess I could make a special mapping mode like ROM_SHADOW or something stupid like that for it. |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Tue Aug 08, 2006 1:20 pm Post subject: | |
|
|
|
| Hmm
whenever I download the wips and try to open them in winrar, I get an
unexpected end of archive error. Just checked with the latest wip link
byuu.cinnamonpirate.com/files/bsnes_v016_wip44.zip and still getting
the archive error. Am I doing something wrong? Edit: Found a solution. Instead of downloading the zip, I can have it opened instead and it will fully download the files that way. Very strange error there. |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Aug 08, 2006 2:35 pm Post subject: | |||
|
|
|||
I tried now, and I could download and decompress it just fine. I use WinRAR as well, but there might be something wrong with your version... Anyway, keep up the good work byuu. Edit: Weird stuff... I was testing the wip44 with Super Mario Kart, and I couldn't drive forward. It seems like the B button doesn't work right during tracks (it just does during the start, but not after). Edit 2: Looks like it's a joypad-related problem... The game works fine using the keyboard. |
|||
New Member
Joined: 24 Jul 2006
Posts: 3
| Posted: Tue Aug 08, 2006 3:00 pm Post subject: | |||||
|
|
|||||
WIP44 works fine here joypad or keyboard on XP. I'll test it on Vista later. |
|||||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Aug 08, 2006 4:46 pm Post subject: | |
|
|
|
| I've got XP and a Saturn USB joypad. The pad has never given me any problem with any other emulator or game. The bug happens 100% of the time. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 08, 2006 7:47 pm Post subject: | |
|
|
|
| Does it recognize your keypresses if you go into the input configuration screen and try and assign the button to it there? | |
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Aug 08, 2006 8:01 pm Post subject: | |||
|
|
|||
Yes. The B button also works in the menus of the game and all, as I need to press B a couple of times before getting in a track. Then, once in the track, I can get a super boost if I get the right timing, but then it stops recognizing the B button no matter what. Sorry I wasn't clear. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 08, 2006 9:22 pm Post subject: | |
|
|
|
| No issues with controls here. You're saying this doesn't happen on previous wips? PS: I've noticed that it is possible to assign the same key to the same button on both primary and secondary. It's harmless, but should proper behavior should be to clear the other side? What about multiple key assignments? Last edited by FitzRoy on Tue Aug 08, 2006 9:38 pm; edited 1 time in total |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Aug 08, 2006 9:38 pm Post subject: | |||
|
|
|||
Huh well, I dunno... The previous wip I checked didn't support SMK properly (no DSP1 emulation). I guess the bug has always been there. I don't even know whether that bug also occurs in other games... I can check older wips if that could help. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 08, 2006 10:08 pm Post subject: | |||
|
|
|||
I'm not worried about assigning the same key to both buttons. It doesn't hurt anything :/ Anyway, I wanted primary and secondary so that I didn't need overcomplicated key+joy mapping combinations packed into the same key assignment value. Mostly to simplify SDL input support that will be added in eventually. And I needed two so that you could use both controller or keyboard and switch between the two without reinputting all of your controls. Lastly, you can make diagonals and stuff if you're clever. Eg assign q to up+down on secondary, or w to left+right. Not quite enough to make complicated combos, but at least enough to use the secondary inputs to map out things like CT's "press up+left+r+start to proceed" for keyboards, and you can map them all to the same key. Of course, I'll probably still get hundreds of bug reports that the input is broken anyway, heh. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 09, 2006 3:16 am Post subject: | |
|
|
|
| You're
right, it should probably stay the way it is. I've checked other
emulators and they behave the same way. Initially, I thought it would
be harder to see a configuration mistake if you allowed duplicate
assignments. I've been doing a lot more "5 minutes in" tests the past two weeks, but haven't noticed any more bugs yet. Good sign. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 09, 2006 4:32 am Post subject: | |
|
|
|
| Clements
had a good point about the video settings. I too had the same problem
with the fullscreen toggle not working very well when
windowed+fullscreen modes shared the same video profile when the
fullscreen video filled the entire screen. So, I readded the fullscreen checkbox, and now F11 checks the current video mode, and then scans for the first video profile (0-7) that is the opposite of the current fullscreen setting (fullscreen->windowed or windowed->fullscreen), and sets that mode. Failing that, it just reinitializes the current video mode again to let you know something happened. I'm hesitant to readd default modes again, then you run into the issue of the default mode not being the right fullscreen setting and confusing idiots. I figure, just make the first windowed video mode your favorite windowed setting, and the first fullscreen the same, or stick to Ctrl+n to switch to your video mode of choice. Also, created InputSDL class. Now SDL port has video+input support. No joypad support just yet, but it should be easy to add now. I just need someone to create a unix audio wrapper for src/ui/audio, and the unix port will have sound and speed regulation, and thus, actually be quite useable :) |
|
New Member
Joined: 01 Aug 2006
Posts: 7
Location: Birmingham, AL or Dallas, TX
| Posted: Wed Aug 09, 2006 7:18 am Post subject: | |
|
|
|
| Well, I had a small problem in WIP42 with my buttons being assigned conflictingly so that my start button didn't register presses, but clearing the secondary button configuration fixed it. Conflicts appear to be possible, to some extent. | |
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Wed Aug 09, 2006 7:43 am Post subject: | |
|
|
|
| By the way, I don't know if this is a known problem, but... ZSNES:  Snes9x:  Bsnes:  Colors are too bright and a bit off with bsnes, it seems... I'm sensitive to this issue as I'm working on a SMK hack, and I can see the colors I chose for my new sprites look wrong with bsnes. SNESGT displays about the same colors as ZSNES and Snes9x, but since it doesn't give a very clear picture (too blurry), I didn't take a screenshot. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 09, 2006 8:15 am Post subject: | |
|
|
|
| I've been thinking pretty hard about how you could simplify the video settings tonight. Here's what I mocked up: -Consider removing profiles for simplicity's sake. What kinds of users would benefit from having this feature? -I moved aspect ratio up to a drop down box after video standard. -I also created a separate multiplier for full screen, which then pairs beside the windowed mode multiplier. This is because someone's full screen setting might be higher than their desktop. -I added resolution information after the multiplier numbers. This not only gives the native snes res at the 1 setting, it also serves as a nifty reference for getting things to correspond to your full screen mode res. -The scanline enabler checkbox was removed because I feel it is redundant as well as strange that you would have to enable something in one area, and set them up in another. 0% can serve as "off" and any other setting can serve as "on" -I reordered and reworded some things. There should probably be a hotkey section at some point for things like F11 to be looked up. -This can't be expressed in the mock-up, but "non-desktop" and "manual screen render size" should be grayed out when unchecked. When "manual screen render" is checked, it should gray out the following areas: Multipler (Win), Multiplier (Full), and Aspect Ratio. This implies that the two cannot coexist and makes all the interconnecting settings easier to "take in" and think about. Here's the mockup (visualize the drop downs paired, I just can't express it): Video Settings Software Filter [None, NTSC, HQ2x, Scale2x] Hardware Filter [None, Bilinear] Video Standard [NTSC, PAL] Aspect Ratio [4:3, 8:7] Multiplier (Win) [1 (256x224), 2 (512x448), 3 (768x672), 4 (1024x896), 5 (1280x1120), 6 (1536x1344), 7 (1792x1568), 8 (2048x1792)] Multiplier (Full) [1 (256x224), 2 (512x448), 3 (768x672), 4 (1024x896), 5 (1280x1120), 6 (1536x1344), 7 (1792x1568), 8 (2048x1792) [checkbox] Use manually defined screen render size: [597 ]x[448 ] [checkbox] Use non-desktop resolution for full screen mode: [0 ]x[0 ]@[0 ]hz [checkbox] Enable triple buffering (buggy, causes sound desync) |Apply Settings| EDIT: Apparently, I didn't understand Clement's problem as much as I thought. That would be really cool if you could fix that. Last edited by FitzRoy on Wed Aug 09, 2006 9:43 pm; edited 7 times in total |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Aug 09, 2006 9:32 am Post subject: | |||
|
|
|||
It's a known problem. In video settings disable the color curve thing. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Aug 09, 2006 1:26 pm Post subject: | |||||
|
|
|||||
It's not a bug, it's a feature. A filter, to be precise.The SNES uses 5 bits per color channel (Red, Green, Blue) and the PC uses 8 bits*. ZSNES and SNES9x just fill the lowest bits with zeroes, but the "color curve" uses the first 3 top bits again, afaik. So "SNES white" will be "PC white" and "SNES black" will be "PC black". Of course this doesn't take into account how your TV is set up, so it might be still different to what you see there. *6 bits in the old "DOS" video mode 13h. _________________ savestate editor: vSNES latest public version
|
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Aug 09, 2006 1:49 pm Post subject: | |||
|
|
|||
Nah it's a bug _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 09, 2006 2:28 pm Post subject: | |
|
|
|
| It
actually doesn't fill in the lower three bits, that relies on your
video card to do that in hardware, most do. See, it's much faster to
blit a 16-bit surface to the screen than a 24-bit one. It does fill in
the missing green bit correctly in RGB565, at least. It also filters
the lower half of the colors with a bent curve, courtesy of Overload
for the algorithm. People complained the image was too dark, so I
lowered gamma by 20% to increase brightness. Set gamma to 1.0 and turn off the color curve if you want dull colors that don't look anything like your TV. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Aug 09, 2006 2:47 pm Post subject: | |||
|
|
|||
With the color curve, it doesn't look like the TV I had my SNES connected to either. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Aug 09, 2006 3:07 pm Post subject: | |||||
|
|
|||||
So you're just specifying the number of bits of the source, and the hardware does the rest? _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 09, 2006 3:32 pm Post subject: | |||||
|
|
|||||
It looks just like my Magnavox 27" TV. If you'd like to donate your TV to me for testing, I'll be glad to make a color profile for it as well.
Pretty much. It is supposed to upscale to RGB888. I'm pretty sure it does on nVidia / ATI hardware at least. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Aug 09, 2006 4:00 pm Post subject: | |||||
|
|
|||||
So now we're going to have 500 TV emulation options? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Eternal Witness
Joined: 02 Aug 2004
Posts: 223
Location: I am and am not here.
| Posted: Wed Aug 09, 2006 5:20 pm Post subject: | |
|
|
|
| I think byuu's proposal would be more precisely defined as "an assload of TV emulation option projects".
They wouldn't have to necessarily be succesful, as long as he gets
assloads of donated TV's. I assume he'd prefer big LCD's or similar. _________________ What? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 09, 2006 6:03 pm Post subject: | |
|
|
|
| Nah,
just two really big LCDs would be fine. Must be HDTV and do 1080p. No
projection or plasma displays, those suck and burn in. I shall continue to fight for my color filtering support enabled by default, rawr! It looks good, dammit, ::sobs to self::, it, looks... good ;_; Maybe I'll make a big popup, "Do you like washed out colors? [Yes] [No]" when you first start the emu and no config file exists. Agreed? |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Wed Aug 09, 2006 6:50 pm Post subject: | |
|
|
|
| Screw
LCDs. I personally am waiting for SED TVs to come out. They're supposed
to hit end of next year, giving "the slim form factor of LCDs and
Plasma displays with the high contrast ratios, refresh rates and
overall better picture quality of CRTs. Canon also claims that SEDs
consume less power than LCD displays." (Wikipedia.org) They also don't suffer the lamp-life problems of LCDs, or the burn-in of plasmas and projection screens. Get a nice one, keep it for a long time. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 09, 2006 10:05 pm Post subject: | |
|
|
|
| I
want an SED as well, I just hope when they release it that it doesn't
emit a whine like old tubes, or is stuck at 60hz. 120hz out of the box
would be nice. Unfortunately, I don't think there are any immediate
plans for pc monitors in this tech. It's going straight to big screens.
Probably be late 2008 at best before we see anything in America. They
keep delaying it in Japan. More recommendations, this for the input configuration (in case anyone still cares): -take out the "select button to update" and the horizontal divider above it. This would look better and they're not necessary in light of the new buttons + the next addition: make it so that the primary or secondary text is red (possibly flashing?) when waiting for a press. Now instead of having to read something, you understand with color. -Add "Clear Primary" and "Clear Secondary" fields if you don't want to clear the whole line. This would also make it more aesthetically pleasing by having no extra space beneath the controller image. Minor recommendation for Color settings: make "Half Gamma Adjust" "Half gamma adjust." Making all the options follow the same capitalization schemes looks better. |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Wed Aug 09, 2006 10:17 pm Post subject: | |
|
|
|
| The color filtering definitely does look nice. I'd actually like to see it added to other SNES emulators. Last edited by xamenus on Wed Aug 09, 2006 10:36 pm; edited 1 time in total |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Wed Aug 09, 2006 10:34 pm Post subject: | |
|
|
|
| The color filter doesn't look that bad, but it's a bit too special, I think. As you know, many of us didn't have such colors on TV back then. From my personal experience, it looks almost like the scart is badly plugged. :p | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 09, 2006 10:38 pm Post subject: | |||
|
|
|||
Me, for one. I like running at 2x+aspect correct by default, but 2x-aspect is good for hires bugtracking. It's also good for making separate modes for NTSC and PAL that work based on your own monitor speeds. I'd rather not set refresh rate based on your currently loaded ROM and have to "guess" what works well. Filter modes is another good one. Do you want to go into the config mode all the time to toggle filters? I toggle pixel and NTSC all the time. The only other thing I could think of would be a bunch of other hotkeys, ctrl+n to set multiplier, ctrl+tab to toggle aspect ratio correction, etc. Then have both NTSC + PAL mode settings and have the emulator reconfigure itself each time a ROM is loaded, or perhaps only if the region changed. -The scanline enabler checkbox was removed because I feel it is redundant as well as strange that you would have to enable something in one area, and set them up in another. 0% can serve as "off" and any other setting can serve as "on" What if you want scanlines in some modes and not in others? Another keyboard shortcut? :/ -I reordered and reworded some things. There should probably be a hotkey section at some point for things like F11 to be looked up. In the future, yes. And it should allow key+joy mapping to all hotkeys... -This can't be expressed in the mock-up, but "non-desktop" and "manual screen render size" should be grayed out when unchecked. When "manual screen render" is checked, it should gray out the following areas: Multipler (Win), Multiplier (Full), and Aspect Ratio. This implies that the two cannot coexist and makes all the interconnecting settings easier to "take in" and think about. I can't seem to disable textboxes. When I do, it does block input, but the boxes stay white and not gray. If they aren't gray, they don't look disabled, which is a bad thing :/ As of now, I set WS_DISABLED and call InvalidateRect(hwnd, 0, TRUE) on the control. It works for checkboxes, but not editboxes. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 09, 2006 11:10 pm Post subject: | |
|
|
|
| Yeah,
definitely the scanline recommendation was dependent on profiles being
removed. The way I see it, the average user simply isn't going to need
them. Most people will set up their preferences once and keep them
there, and it is rare that they will feel like switching between ten
different resolutions and settings often enough to justify adding
profile selection, scanline checkbox, "activate this profile", etc. If
you're still intent on keeping them because you and testers personally
find them convenient, so be it. But for releases, I think "power
features" like this add a bit of unneeded confusion. I'm trying to go
against anything that could resemble a nuclear switchboard. If you do end up keeping them for releases, I suggest the following solution for the scanline dilemma. Leave the checkbox out, but move the scanline adjustment sliders to the middle of my previous "video settings" mockup. Like this: Progressive scanline intensity: % [slider] Interlace scanline intensity: % [slider] In fact, that sounds like a good idea even if you do remove profiles. As for the not being able to gray out certain boxes- that is really unfortunate. What about the drop drown boxes? If only those could be grayed out, I think that would be sufficient. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Aug 10, 2006 3:47 am Post subject: | |
|
|
|
| On
the other hand, most users can probably just ignore the profile
feature, and set up the default profile how they want it. Works the
same as not having profiles. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 10, 2006 5:28 am Post subject: | |
|
|
|
| byuu
pretty much confirmed it is convenient for one kind of person: a heavy
tester who uses a filtered image for fun, but unfiltered while testing.
Not even I fall into that category, I use unfiltered all the time. The video settings area is complicated enough as it is. Joe isn't going to ignore it, he's going to wonder what the hell it is, and why he's on the third one. Then he's going to dick with it needlessly until he either figures out he doesn't need it, thinks it does something it doesn't, or suspects it is responsible for something else not working. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Aug 10, 2006 5:38 am Post subject: | |||||
|
|
|||||
In vSNES I only set the color of a textbox to gray* if it contains no text, since that's more important to me. Disabled textboxes don't look different to enabled ones. You could disable labels though. Normally they're black, but disabled ones are gray. *Actually I set the "ParentColor" property to true. _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 10, 2006 2:25 pm Post subject: | |
|
|
|
| I found the correct API call to disable textboxes, EnableWindow(HWND, BOOL); Nice and easy. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 11, 2006 6:59 am Post subject: | |
|
|
|
| wip46 up. Adds all kinds of things, please test. First, no more d3dx9_27.dll requirement to run the application, but screenshots still work if you have any d3dx9_nn.dll files. I specifically want to know if any of the other versions (24, 30, etc) cause the emulator to crash when use. I'm pretty sure the function is backwards-compatible, but we should probably make sure before I make the next release and start getting bugreports about screenshots crashing the program. Note: there is no error message for failed screen captures, I'll add that in eventually. Next, the video options finally enable/disable controls depending on certain settings. Should make using the video options a little easier. Next, to enable SDL audio on Windows and remove the win32 port's wMain.hwnd reference, I now pass GetDesktopWindow() to DirectSound's SetCooperativeLevel function, since no sound comes out if you pass a null handle. This is because I don't know how to get the window handle from SDL, and I prefer to keep port-specific code out of there if possible. Note: SDL is not a windows port, but it builds on windows, and thus needs DirectSound to output audio on windows. I'm hoping this doesn't cause audio problems for anyone else, but honestly I have no idea what DSound uses the window handle with DSSCL_PRIORITY for anyway. The $2100 luminance stuff was improved by adding rounding support to the double-to-int casts, so fades should appear a little smoother now in games. Possibly fixed a bug where RTO wasn't being calculated when brightness=0 and the screen is enabled. Didn't see any improvements in the three known bugged games. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Aug 11, 2006 7:54 am Post subject: | |
|
|
|
| Wow,
this is great. I'm really glad you got those gray-outs working, it
definitely helps. There's only one thing I still voice my support for: 1. The resolutions in the multipliers- if only to avoid accidentally going over the desktop res. Because if you set the multiplier too high, the video window disappears and there's no way to revert back other than deleting the cfg. Course, if bsnes could sense what your desktop res is and prevent you from doing it at all, that would be even better. I've already noticed what might be a possible bug: going into fullscreen and back out again results in bsnes reverting back to Profile 1. It didn't behave this way for me in 44. Thanks and keep up the good work! EDIT: Ok, I think I just realized what's going on. The fullscreen option does go to fullscreen when you enable and apply it. And when you exit, it reverts to the first windowed profile. So in essence, this encourages using different profiles for full screen and windowed modes. So if you've got windowed on profile 1 and full screen on profile 2, the problem clements described no longer exists. This is not without problem though. For example, if the first three profiles are full screen enabled, the minimization bug happens. When you restart, you're on Profile 4 where you should be. *phew* So if I'm understanding this now, and I think it's awesome once you do, I would suggest halving the number of profiles and renaming them to: Windowed 1 Full Screen 1 Windowed 2 Full Screen 2 Stupid proof, and 2 different for each would be sufficient for testers and users, wouldn't it? And of course, the video settings would be changed accordingly to remove the full screen option, triple buffering from windowed modes, etc. Any of this worth a damn? |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Fri Aug 11, 2006 9:18 am Post subject: | |||
|
|
|||
I'm using xp pro sp2. It seems to work fine with d3dx9_24 to d3dx9_30. I swapped them out of the system32 directory and made sure to take more then one shot with each one. Then just for the heck of it I tried taking them all out and it still didn't crash. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Aug 12, 2006 6:49 am Post subject: | |
|
|
|
| The
bug in Megaman X2's Wheelgator boss screen was due to a bug in the C4
bitplane wave opcode. Every other tile was generating gibberish. The
problem was due to incorrect loop nesting, interestingly enough. Unfortunately, the last three bugs appear to be far more insidious than this one. Though perhaps the most complex to fix, at least I have a clue what's going on with Uniracers. I'm at a complete loss with MMX2 intro and RPM Racing (U). Especially since RPM Racing (J) runs just fine. EDIT: ok, RPM Racing, the problem with the sprites showing up as corrupted graphics is due to initializing WRAM to 0xff. If I initialize it to 0x55, the cars work every time. Likewise, if I initialize ZSNES WRAM to 0xff, the car sprite bug appears there as well. I will not be "fixing" this "bug". The game is fundamentally broken from a programming standpoint, relying on uninitialized memory to function properly. This game is in the same league as Death Brade and Power Drive. If you want to trip this bug on real hardware, try turning the power on and off in rapid succession, and you will eventually encounter errors in all three of these games. I've no need to fake emulation to allow these games to work properly. The official SNES documentation explains this just as I have in the past. The WRAM values at poweron vary per console manufactured for a variety of uncontrollable and unpredictable reasons. Furthermore, if you turn power off, the WRAM data slowly decays over time, but only parts of it at a time. If you turn the unit back on quickly enough, WRAM will be mostly the same as it was when you turned the unit off. Thus, any game relying on uninitialized WRAM can and will fail on real hardware. What I might be willing to do is add a special WRAM initialization value to the cart database to allow games such as these to function. Does anyone agree/disagree with this idea? My other idea would be to create UPS patches for each game that overrides the reset vector with a WRAM initialization routine, and host them on my site as bugfix patches. The track draw problem still remains, regardless of WRAM init value. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Aug 12, 2006 7:49 am Post subject: | |
|
|
|
| I agree with the special case fix idea. DB and PD as well if they apply. | |
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sat Aug 12, 2006 8:47 am Post subject: | |||
|
|
|||
I do. I wouldn't go for the patch idea. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Aug 12, 2006 9:12 am Post subject: | |
|
|
|
| Maybe
those special cases could also show a little popup on screen or in the
screen stating that this game has bugs that happen on the real console,
but is patched through the database so the game works. This way we will know that the game has a fix in the database, The ips on your site would also be a good idea, but less easy to use I'm Wondering if this will be possible: 2 directories 1 for roms 1 for ips if the ips and rom name match, bsnes automatically applies the ips file to the rom, if no ips is found bsnes runs the clean rom |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sat Aug 12, 2006 9:24 am Post subject: | |||
|
|
|||
|
I'm also for patches. And I think initialising all the RAM areas to random values would help the PD scene. EDIT: Unless they use it as a random generator. _________________ savestate editor: vSNES latest public version
|
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Aug 12, 2006 11:01 am Post subject: | |
|
|
|
| I
just read on Haze's blog that there are some plans to redump genesis
and maybe also other systems like snes. The plans are to dump each
individual chip instead of a romdump via the pins on the cart, this
could also result in a full dump of the dsp's removing the need for
fully emulating them intersting |
|
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Aug 12, 2006 12:05 pm Post subject: | |||
|
|
|||
At the risk of exasperating some people... I don't get it: What are the initial WRAM values of a real Snes, and wouldn't it be simpler to just go along with these in bsnes? Are you saying the values differ between each Snes units, or at each new power on? edit: Of course, I do think that bugs that appeared on the real console should appear in emulators as well. But I didn't quite get if the RPM racing bug does or not. Last edited by Dmog on Sat Aug 12, 2006 2:52 pm; edited 3 times in total |
|||
Trooper
Joined: 31 Aug 2004
Posts: 417
| Posted: Sat Aug 12, 2006 12:19 pm Post subject: | |||
|
|
|||
Where is that? Browsing his blog I didn't see any mention of it. He just released a Megadrive only Mame derivative. Looks to be progressing pretty well. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Aug 12, 2006 1:39 pm Post subject: | |||||
|
|
|||||
http://haze.mameworld.info/2006/08/11/hazemd-001a/
http://haze.mameworld.info/2006/08/11/hazemd-002a/
And yeah his megadrive/genesis driver rewrite is simply awesome. |
|||||
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Sat Aug 12, 2006 5:06 pm Post subject: | |||||
|
|
|||||
...Are you incapable of reading (this wouldn't surprise me AT ALL)? He says it right there!
Go back to school please, Dmog. _________________ "Dearly beloved, we gather here today to join this wooden stick, with Aerdan's butt, in holy matrimony, and may they not part until death, or perhaps extremely powerful bowel movements." - Metatron at the wedding of Aerdan's butt and a stick |
|||||
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Sat Aug 12, 2006 8:47 pm Post subject: | |||
|
|
|||
|
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Aug 12, 2006 9:09 pm Post subject: | |||||
|
|
|||||
_________________ FF4 research never ends for me. |
|||||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Sat Aug 12, 2006 11:58 pm Post subject: | |
|
|
|
| -quote of dmog heer- It should stay deleted _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 13, 2006 1:02 am Post subject: | |
|
|
|
| I don't have the game so I can't determine how often it happens on the real system, but I'm certain the bug can be triggered. Anyway, the point is this. In an emulator, the WRAM init value is always going to be the same. I'd love to make it initialize to rand(), but then you have a problem with games that rely on those anyway. Sort of the same reason ZSNES can't do netplay and has some sporadic movie recording issues: you don't want randomness in an emulator. I'm going to stick with 0xff. I don't see much difference between 0x00 and 0xff initialization values, but always using 0x55 because it just so happens to work with all of the commercial games we're aware of (excluding BS-X games), is, quite simply, a hack. And adding this to the database is a hack as well. I'll just include a readme from now on with bsnes v0.017+ explaining that these three games have problems and why, and that it has nothing to do with emulation accuracy. |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sun Aug 13, 2006 2:01 am Post subject: | |
|
|
|
| Not too sure if you'd like this idea byuu, but it's only a suggestion. Maybe add an option in the gui or a command line switch to change the wram to 0x55. Then since you'd probably never use it, just leave it off by default. It keeps your database clean and you don't have to make any specific game patches. Eh though I guess if you wanted it to be user friendly the database idea would probably work better. Either way they're all hacks I guess. | |
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Aug 13, 2006 4:00 am Post subject: | |||
|
|
|||
I concur. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Aug 13, 2006 5:29 am Post subject: | |||
|
|
|||
I'm sure eventually bsnes will get a "Paths" area in the configuration for people to define their own destinations for saves, patches, roms, special bios', etc. As for patches vs discreetly "fixing" them, I'm not opposed to either. I don't like an option, because it doesn't fit with any current configuration area, and a popup is annoying compared to just saying something in a readme file. My rationale is that whenever there is an attribute of randomness at work, one should always take the optimum case and emulate that. If that means hacks, so be it. I think the word itself is scaring people from believing that this could be an appropriate use for them. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 13, 2006 6:03 am Post subject: | |
|
|
|
| May
I request the car sprite graphics bug in RPM Racing be removed from the
buglist since it is due to the game relying on uninitialized WRAM
variables? If everyone else prefers, I will go against my personal
judgment and initialize WRAM to 0x55, though I really don't want to. That brings us down to three issues: 1) Mega Man X2 - Jonas Quinn recently noticed the same assembly line bug exists in SNES9x' C port of the Cx4 code. Appears to be a bug with op00-00 OAM table building code. When this is corrected, I can backport the changes into bsnes and MMX2 should no longer have any known bugs. 2) Uniracers - Will require me to start deciphering mid-frame OAM address invalidation. A very involved and complicated process. This requires use of my copier, so I can only work on this one with my extremely limited free time at home. Don't expect this bug to be fixed any time soon. 3) RPM Racing - Track draw issues. This is the only known bug now where I have absolutely no idea what the hell is going on. My plan of attack is going to be dumping logs of register values between the U and J versions of the game. Perhaps the U version is relying on uninitialized registers being a certain value as well? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Aug 13, 2006 6:13 am Post subject: | |
|
|
|
| Done. Did you and kick ever do those PAL tests btw? |
|
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Sun Aug 13, 2006 6:22 am Post subject: | |||
|
|
|||
Honestly, I'd think an option would be the best solution. Default it to whatever you want, but add a checkbox option to initialize it to 0x55. That should make everybody happy except super-hardcore zealots on both sides. Besides whatever GUI changes you'd need to make (which I imagine is WAY easier to do in bsnes than in ZSNES), it sounds like a simple 'if/else' statement the way it's been put (I'm getting the strong implication you just need to change one setting to go from 0xff to 0x55). Think of it as a filter if that helps. _________________ "Dearly beloved, we gather here today to join this wooden stick, with Aerdan's butt, in holy matrimony, and may they not part until death, or perhaps extremely powerful bowel movements." - Metatron at the wedding of Aerdan's butt and a stick |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Aug 13, 2006 7:23 am Post subject: | |
|
|
|
| Byuu if you make an ips patch, does that mean the game will work normally on all emulators(excluding those maybe that have a special hack for the game) and on the real snes every time? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 13, 2006 7:45 am Post subject: | |||||||||
|
|
|||||||||
Thanks :)
Nope, I forgot about writing them. Maybe I can dig up anomie's dot timing test, that would be a great start at least.
Definitely :) I guess I can hide it in the config file to let you specify anything from 0x00 to 0xff. Perhaps I'll even add some supersecret options to initialize WRAM to rand() [all the same byte] or rand() [every byte random], for the purposes of homebrew development.
Yes, a patch would make the game work on all emulators regardless of WRAM init value. However, every other SNES emu just initializes WRAM to 0x55. On the bright side, it would make triggering the bug impossible when played on a copier, at least. |
|||||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Aug 13, 2006 7:48 am Post subject: | |
|
|
|
| In
that case i say go for the IPS patch, and state it in the documentation
and on your site, you could even include the IPS in the bsnes zip. That would solve the whole problem once and for all When you get those pal tests ready ill pop them in to my snes and send you the results |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Aug 13, 2006 8:20 am Post subject: | |
|
|
|
| Oops, wasn't kick, it was tetsuo. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Aug 13, 2006 7:48 pm Post subject: | |
|
|
|
| I
don't claim responsibility because I don't have the power, but the
reason for the posts being deleted is probably because of excessive
stupidity due to byuu already explaining his point. After all, being stupid on any internet forum is just never tolerated in the first place... _________________ FF4 research never ends for me. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Aug 13, 2006 8:33 pm Post subject: | |
|
|
|
| -quote of x-user-d/Dmog deleted- "ok" I would have loved to be responsible for removing those posts. Alas, I am not. _________________ FF4 research never ends for me. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Aug 13, 2006 8:43 pm Post subject: | |
|
|
|
| and yes that was me deleting the posts _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Mon Aug 14, 2006 12:39 pm Post subject: | |||
|
|
|||
I disagree here. I don't think it's a hack at all. Yes, these games have poor programming practices, however they rely on the fact that GENERALLY, WRAM is 0x55 in MOST cases. Wouldn't it be more closely emulating the system by using 0x55? That is the value WRAM initializes to the MOST. It sounds dumb to me use another value and then call the value most frequently found on the actual hardware to be a hack. That defies my logic. Even if you DID use Rand(), to be REALLY accurate, you'd want to make it so 0x55 came up MORE times than other values because that's what seems to effectively happen on the real hardware. These games work the majority of the time on the real hardware. If they NEVER work on BSNES, you have failed to meet that goal in my opinion. Those are overly strong words for such a minor issue, but you get the point. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 14, 2006 2:14 pm Post subject: | |
|
|
|
| I'd love to see proof that the default WRAM value is more frequently 0x55 than any other value. As I said though, I'll go against my better judgment and use 0x55 if that's what everyone else prefers. | |
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Mon Aug 14, 2006 2:37 pm Post subject: | |
|
|
|
| Well, is there a tangible benefit to making it anything but 0x55? I.E., does setting this value to 0x55 break anything? If not, and there's a benefit with no penalty, logic clearly dictates that it should be 0x55. _________________ "Dearly beloved, we gather here today to join this wooden stick, with Aerdan's butt, in holy matrimony, and may they not part until death, or perhaps extremely powerful bowel movements." - Metatron at the wedding of Aerdan's butt and a stick |
|
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Mon Aug 14, 2006 2:54 pm Post subject: | |
|
|
|
| It seems to me that the only real way to get proof of that is starting RPM Racing a thousand times and seeing how often it works.. but that might not be very realistic. | |
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Aug 14, 2006 4:33 pm Post subject: | |
|
|
|
| Another brilliant idea would be to write a test program that samples the contents of WRAM on startup, then power cycle repeatedly to see if you can get any other results. Preferrably an automated system where the test program can report results to an external device, and the external device power cycles the system for a random duration upon test completion. Have fun with that. | |
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Mon Aug 14, 2006 9:17 pm Post subject: | |
|
|
|
| Yes. I forgot for a moment that you could. | |
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Aug 14, 2006 9:52 pm Post subject: | |
|
|
|
| Although it seems that it would require a flash cartridge or other custom setup, as most copiers erase the WRAM on startup. I wouldn't be surprised if there were copiers that also mess with the SPC to play sound effects and/or music. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 15, 2006 6:20 am Post subject: | |||||
|
|
|||||
|
As soon as someone donates a flash cart to me, I will verify this, as well as PPU/APU/etc power/reset values, once and for all. FreeBSD apparently treats malloc differently than Win32/Linux. FreeBSD modifies the size argument on the stack. Example:
Solution :
Result : http://byuu.cinnamonpirate.com/images/desktop081506.jpg Linux/FreeBSD port is working. Lots of warnings to work out, though. |
|||||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Tue Aug 15, 2006 7:54 am Post subject: | |
|
|
|
| Is that video in mplayer dnagel? That was an okay series. Er anyway thanks for making a linux/bsd port of it. I don't use it nearly as much as I do windows, but it'll be nice to have. | |
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Tue Aug 15, 2006 12:23 pm Post subject: | |||
|
|
|||
I assume the proof to be the fact that this commercial game was 1.) released and 2.) people played it without issue as there is nothing that says otherwise. I wouldn't imagine a company would release a game it didn't test to at least work when they tested it. Number 2 is weak and could use confirmation though. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 15, 2006 2:29 pm Post subject: | |||||
|
|
|||||
Yes. I was going to use a screenshot from Condor Heroes, but I figured it just wouldn't be a Linux mplayer screenshot without anime playing. Ok series. Cute, but not too great on plot. I've found two series I've really liked thus far. Fushigi Yuugi and Houshin Engi.
Many games are released with sporadic bugs. The biggest problem with using 0x55 is it makes these games work every time you power on the system. I don't believe that is correct behavior. Even if 0x55 happens 90% of the time, that's not correct emulation to have the game work 100% of the time. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 15, 2006 4:32 pm Post subject: | |
|
|
|
| Team neo is working on a new flash card, that will run any rom, it should act like a regular game | |
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Aug 15, 2006 5:23 pm Post subject: | |||
|
|
|||
Apart from special chip ROMs, heh ? :\ |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 15, 2006 7:49 pm Post subject: | |
|
|
|
| they claim it runs everthing except FX | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Aug 15, 2006 8:37 pm Post subject: | |||
|
|
|||
If FX is not possible, I'm pretty sure SA-1 won't work either.. and that's the only chip that demands lots of power. _________________ FF4 research never ends for me. |
|||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Tue Aug 15, 2006 9:48 pm Post subject: | |||||
|
|
|||||
Haha, how true. You should of made it Evangelion just because.
Who doesn't like Fushigi Yuugi. That was a great series if you ask me. It was neat because I'd never seen any anime that used a setting in ancient china at the time. The whole idea of the book reminded me of the movie the neverending story in way. I'm not too big on folklore so that's the only thing I could think of to comapre it to. Ah I wasn't really expecting the two friends to be enemies either.. that kind of sucked since I liked both of the characters. Oh do you watch anything else? Like mecha anime or horror? Edit: I shouldn't derail your bsnes topic. Sorry, I'll chat about this some other time.
|
|||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Wed Aug 16, 2006 3:16 pm Post subject: | |||||
|
|
|||||
Yeah, but how far do you intend to take it? Are you going to turn your unit on and off 1000 times, record the values and precentages of frequency values come up and make your emulator mimic that? That sounds a little mad/obsessive to me. However, that just may be you. I suppose the best idea is to gather some data before making a decision about this. At this point, it's just speculation until we can see what does happen. Also, when you do your power cycling, I would do tests with quick cycling and slow cycling ie 30 seconds or 1 minute apart. I'd imagine the values in WRAM will differ with allowing the SNES substantial time to discharge. Since WRAM requires such little voltage and power to maintain it's data, it may not lose it's data for several seconds or it may still retain SOME of the bits if the cycle is turned back on too quickly. Manufacturers generally claim an UNKNOWN state at startup(which you'd expect), but in practice with systems I've worked with at work, I have observed the values of RAM tend to generally see the same numbers many times at startup. It's absolutely foolish to rely on this no doubt, but it seems to be an interesting anomoly that occurs. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 16, 2006 4:30 pm Post subject: | |||||
|
|
|||||
|
I
agree, there's definitely precedence for there being general proximity
values at startup. The biggest problem is if every emulator initializes
to 0x55, and then some homebrew programs rely on WRAM being 0x55 (eg to
determine if the emulator was powered on or reset, rather than using a
WRAM key). We're basically saying, "WRAM is always
0x55 on poweron", which isn't the case. I've tried pretty hard up until
recently to not add speculative changes just to fix games, but this is
one thing I cannot test personally. But then, supposedly this has been somewhat tested and the value is usually 0x5n (n being anything). And I have to use a fixed value every time or I make movies impossible due to "randomness" issues.
While theoretically possible (log timestamps of accesses to games and decay WRAM based on how recently you used poweron), I think that's a bit too extreme even for me. We do have to realize we're working with computers and make some concessions sometimes. But that works both ways, so I need to keep trying to emulate every detail I can, while conceding only when necessary. But, for now, the newest WIPs initialize WRAM to 0x55, SRAM to 0xff. I might as well add the SPCRAM patterned-init while I'm at it... everything else does 0x00 for VRAM, OAM and CGRAM, so unless I hear otherwise, that should cover every significant memory init.
Definitely not those two genres. I watch maybe one series every 3-6 months. Mostly a matter of being too busy doing other things to watch TV. I kind of wish they'd subtitle the Chinese stuff too for us monolinguals. The Condor series looks awesome as hell :/ (obligatory mplayer condor heroes screenshot here) |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Aug 16, 2006 7:48 pm Post subject: | |
|
|
|
| Yeah all TVB releases should be english subbed |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Thu Aug 17, 2006 12:18 am Post subject: | |||
|
|
|||
Nice. My friend said he wanted to show me the 1990ish version of condor heroes. He liked that version better since the actors were better looking. Lol I don't know about the acting quality, but I guess the whole story is still there. It's going to be a pain having him translate while it's going on though. I saw some parts of the book were translated so I might just go ahead and read those before hand. What I should really do is learn some cantonese so I can watch all those kung-fu dramas that he likes. I'm sure he'd be more willing to show me other stuff too. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 17, 2006 5:37 am Post subject: | |||
|
|
|||
New
mirror function. This one mirrors an offset, rather than mirroring the
entire ROM. Before, I was having reallocate a 40mbit ROM (Dai Kaijuu
Monogatari II for instance) to a 64mbit ROM, losing 3MB of RAM. Now I
take advantage of my page table lookup, and use the below routine. Same
speed, but less RAM usage.
Code is public domain if anyone wants it. Example: for(int i = 0; i < 32; i++) { printf("%x", mirror(11, i)); } Output: 0123456789aa89aa0123456789aa89aa |
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Thu Aug 17, 2006 5:55 am Post subject: | |||||
|
|
|||||
Rather, n being any combination where bits 0 and 1 are not equal, and bits 2 and 3 are also not equal. 5, 6, 9, and A all fit that requirement.
Or, like, you can record the initial state in the movie, and then not worry about future changes to the emulator which affect power on state breaking existing movies, or possibly playing the movie in another emulator which has its own inconsistent power on state. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 17, 2006 6:24 am Post subject: | |||
|
|
|||
|
Before anyone reports this and annoys me : This is not a bug in bsnes. The line of "gibberish tiles" under the text line is due to initializing WRAM to 0x55. ZSNES has the same "problem". Copiers almost always initialize WRAM to 0x00, which is why the demo works there.
A movie would never play between two emulators, unless both were virtually bit-accurate to a real SNES. Otherwise, the movies would desync. Yes, I could just record the initial state. I suppose I'll put off movies until I have savestate support, then. That way I can just save the poweron state into the movie, or allow the move to start recording anywhere. |
|||
Rookie
Joined: 17 Aug 2006
Posts: 12
| Posted: Thu Aug 17, 2006 6:49 pm Post subject: | |||
|
|
|||
Microsoft Visual C++ 2005 Redistributable Package (x86) http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE Microsoft Visual C++ 2005 Redistributable Package (x64) http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B There's also this but I think it's kinda old... Visual C++ 2005 Runtime Libraries Package Beta 2 http://www.microsoft.com/downloads/details.aspx?familyid=25ae0cd6-783b-4968-a841-38a2743307d9 |
|||
Rookie
Joined: 17 Aug 2006
Posts: 12
| Posted: Thu Aug 17, 2006 7:00 pm Post subject: | |||||
|
|
|||||
Maybe you can get some help from the guy that made VirtualDub. He seems to *really* know his way around the ins and outs of D3D and video cards and RGB<>UYVY... http://www.virtualdub.org/oldnews From his contact page... http://www.virtualdub.org/contact
While what you want to do isn't related to VirtualDub per-se, it's something he happens to know a lot about and maybe he'd be inclined to help out. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 17, 2006 9:16 pm Post subject: | |
|
|
|
| His software is far more valuable than mine, I'd prefer not to waste his time with my boring questions. Luckily, non-overlays work good enough 99% of the time, I just need to find a better way to keep the black borders of the display clear is all. Maybe a "clear entire window every 60 frames" option. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 18, 2006 6:44 am Post subject: | |
|
|
|
| Ok, I was finally able to get an output buffer to render on with unix. This uses GTK+, and also has a menubar. Problem is, it's slow. The pixel fill loop gets ~1950 fps, whereas when blitting the pixelbuffer to the screen, performance drops sharply to ~480 fps. I think part of the problem is that GDK pixbufs are forced to be 24bpp, and there's conversion from GdkPixbuf to GtkImage, and then GtkImage to the video card. Too many costly translations involved. If anyone knows more about GTK+ (specifically using gtkglext or gtkgllib), I'd appreciate help in speeding this up. If I can get a superfast blitter working, especially with scaling, I'll make a full-fledged unix port, complete with working menu options, UI, etc. http://byuu.cinnamonpirate.com/temp/test.cpp (compiles with g++ test.cpp -o test `pkg-config --cflags --libs gtk+-2.0`) |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Fri Aug 18, 2006 7:27 pm Post subject: | |
|
|
|
| Be aware that GDK is also using software scaling. If you want to do hardware scaling you will have to go with something like Xv overlays, it's pretty much the only option for hardware scaling besides OpenGL. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Aug 18, 2006 9:06 pm Post subject: | |
|
|
|
| I'm
going to implement this very modularly. I'll create a generic
GtkDrawingArea box for the video output, and have multiple hooks to it. I think I know how to hook SDL to the DrawingArea now (set SDL_WINDOWID environment variable), and it looks like I can save a step and use GtkDrawingArea + GdkRGB to get a little closer to hardware. Probably won't help much. Then later I can add SDL-GL support. I'm very interested in Xv. Do you know where I can find a tutorial / minimial example to get an Xv display up? I intend to use GDK_WINDOW_XWINDOW(mydrawingarea)->window (native X window handle) to draw Xv data on. EDIT: hmm, supposedly I can use overlays in SDL and have it fall back on Xv / XVideo... works on Windows, too. Imagine that, SDL actually can do hardware scaling, you just have to convert your video from RGB to YUV first. pagefault, I don't suppose you ever figured out an efficient algorithm for doing that? It's always eluded me in the past, despite understanding how to convert RGB<>YUV, and how the packed format works. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 20, 2006 6:02 am Post subject: | |
|
|
|
| Linux/FreeBSD users will like this :D http://byuu.cinnamonpirate.com/images/desktop082006.png |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Aug 20, 2006 8:51 am Post subject: | |||
|
|
|||
Not if that file open menu is the buggy GTK one. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 20, 2006 6:13 pm Post subject: | |
|
|
|
| It
has its issues, but it isn't buggy AFAIK. I fixed the dialog when you
hit ok or cancel to merely hide rather than destroying itself, so that
it remembers what folder you were in. But clicking on the X kills the
window even if you override the destroy event. Meaning you get to start
back at your startup path the next time you open the box. I'm not aware of any alternative GTK+ file open dialogs included with the base library. Though I suppose I could always write my own with enough patience and stick the folders and files in the same window like they should be. Personally, I like QT's more, with the exception of the default one-click-activation thing. But I don't know how to program for QT. I should revise my statement: half of Linux/FreeBSD users will be happy with the new interface, and the other half can compile the GTK+-free pure SDL port with no UI at all. Still, broken or not, I think an ugly file open dialog box beats out no file open dialog box at all. |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Sun Aug 20, 2006 7:29 pm Post subject: | |
|
|
|
| If
you can actually get it going fast in an all-in-one window like that
it'd be cool. I normally just punt and have the GUI separate from the
emulator output (GTK or Qt for the UI, SDL for the output) but it'd be
nice for my NEStopia port if I could make it "one piece" like the Win32
original BTW, it's confirmed by 20+ years of GUI studies that files and folders should be in separate windows and that it's much faster to navigate that way. Changing that in Win95 remains Microsoft's biggest crime against usability
I haven't actually tried making it remember the path yet, but doing a
getcwd() in the destroy handler for the requester and a chdir() to that
value before you start it should help it's memory. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Aug 20, 2006 7:41 pm Post subject: | |||||||
|
|
|||||||
It defaults to your KDE settings. So if it's single click for you, you have KDE (or KDE some libs) set to single click. When I installed KDE I told the install Wizard I like Redmond GUI style and it's all double click for me.
I'll be happy if I can easily type in the directory. So if you still have loading via command line great.
My 12+ years of GUI using has proven that the fastest navigation (for me anyway) is typing in the directory and having a good auto complete. I love the Windows one because it allows me to type it in, same reason why I love the Qt one, and the auto complete is excellent. The GTK one just seems horribly broken, as I'm typing it in, the autocomplete when it uses it seems to just screw it all up. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Aug 20, 2006 10:11 pm Post subject: | |
|
|
|
| I
may have finally found a new bug. Space Football (U) is crashing the
emulator after starting a new game. The game works in .016 official.
Will wait for confirmation. Regarding the folder navigations... they're both ridiculously easy. And you can type the start of the rom name in both. I will say this though... spaces between entries on the list? Sorry, but score 1 for Redmond on that one. It does not make things easier to see, and it needlessly decreases the effectiveness of the scrollbar. A list of files is not a term paper. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 2:29 am Post subject: | |||
|
|
|||
Wow. That was a really hard one to fix. The initial reason this bug appeared was because I started rendering when display_disabled == false && display_brightness == 0. It was crashing because bg_tiledata_state[COLORDEPTH_256] was being overwritten. This variable was being overwritten because I set regs.hires = (regs.bg_mode == 5 || regs.bg_mode == 6) immediately when the MMIO reg $2105 is written to. I set line.width according to (regs.bg_mode == 5 || regs.bg_mode == 6) ? 512 : 256 during PPU::scanline(), and then rely on that variable during PPU::render_scanline(), which is of course called later on. This game was changing regs.bg_mode from 5/6 to 0 between these two points, and the BG renderer was then rendering 512 pixels to the pixel_cache buffer. Problem was that since regs.hires was now false, but line.width was 512, it was writing past the end of the pixel_cache by 256 pixels, screwing up all of the memory after pixel_cache[256] { ... }. If regs.hires were true, it would've halved x before writing to the cache (and alternated between updating the main pixel cache and sub pixel cache instead). Took forever to track down this bug because MSVC's debugger was giving me all kinds of useless information, crashing at completely different code parts, etc. I fixed this by removing the transient variables line.width and regs.hires, and instead hardcoded their calculations into the routines that need them, so that their values are always current. Anyway. Also, thank anomie for this bugfix, and Nach for telling me where to get the codefix from. I had no hand in fixing this bug. RPM Racing continues to elude me. The J version does not use hires(!!), which is why it works fine. The U/E versions look fine. VRAM is the same for BG1 tiledata + tilemap as in ZSNES, and all PPU registers are identical to Super Sleuth. I've tried modifying all of the masks and ranges for scroll registers, SC masks, screen masks, etc, even setting them by hand, to no avail. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 4:46 am Post subject: | |||||
|
|
|||||
|
bsnes now builds with no warnings on Linux: http://byuu.cinnamonpirate.com/images/desktop082106.png However, input is not working unless you build the non-GTK+ port (see below for more info). I'm planning on releasing next weekend. This will likely be the last public WIP, unless something major is found before the weekend: byuu.cinnamonpirate.com/files/bsnes_v016_wip52.zip <- copy/paste link
I can. Please take a look at my above sourcecode, and check your private messages for another note. Specifically, src/ui/video/sdl.cpp and src/ui/gtk/gtk_mainwindow.cpp. I am able to merge the SDL output into the GTK+ window by setting the environment variable "SDL_WINDOWID=%ld", GDK_WINDOW_XWINDOW(mydrawingbox->window). One important thing to note is that you must not initialize SDL video until the render window has been realized. Simply showing the window is not enough. You need to also clear all pending events in GTK+ after showing the window before calling SDL video init, or it will die. You can do that with this code:
However, one problem I am having is that by calling gtk_main_iteration_do(), it steals all SDL input, and I'm not able to poll any keypresses. This happens whether I embed the SDL video output into the GTK+ window or not. The only way to get SDL input is to ignore all GTK+ events, effectively freezing the window completely. I don't suppose you'd mind sharing how you got SDL input working with GTK+ with me? |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 9:25 am Post subject: | |
|
|
|
| Good news, Front Mission (J) (V1.0) [T+Eng1.0b_FH].smc works in the latest WIP, where it doesnt boot at all in .16 Also none of the problems that zsnes have show up. it looks just like on the snes! Edit: started testing games backwords starting at Z, games where tested up to halfway though a level or 1 fight in a fighting game, RPG's where tested up to the point where i got control of the character. All tested games are verified from Goodsnes, and are supposed to be the correct clean dumps. Yuujin - Janjuu Gakuen 2 (J).smc > there is random garbage errors in the bottom right corner of the textboxin the intro story, i was unable to capture a screenshot or test on my snes if its a game problem. Yuujin - Janjuu Gakuen (J).smc >> no matter what characters i unput at the seemingly "name" screen i cannot get passed this screen, maybe someone who can read japanese can confirm Zan III Spirits (J).smc > Dots show up in the lower right corner, the dots are sometimes red and sometimes black, they are not visable in zsnes, i have made screens of this behaviour. Zenkoku Koukou Soccer Senshuken '96 (J).smc > after setting all the settings the game goes black instead of starting the soccer match, game works in zsnes Yuu Yuu Hakusho Final - Makai Saikyou Retsuden (J).smc, game seems to work but the screen stays black, only menu and story text is shown, the rest is black, works in zsnes |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Mon Aug 21, 2006 12:46 pm Post subject: | |
|
|
|
| Waaay
back in Modeler I got that to work by running the actual emulation
entirely in a separate thread from the GTK+ stuff, but I don't know how
well that would work with it all in one window. You might need to just make the drawing area a custom GTK widget and get the keyboard & mouse input through GTK (and then use SDL for joysticks). |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 1:31 pm Post subject: | |
|
|
|
| More bugs found, please forgive me if any of these games use special chips, i didnt find them in the lists i found. Yogi Bear (J).smc and Yogi Bear (U) [!].smc > crackling noises seem to come from nowhere, doesnt happen in the E version X-Terminator 2 Sauke (J) [!].smc > Doesnt boot, doesnt work in Zsnes either, maybe this is a special chip game? WWF WrestleMania - The Arcade Game (J).smc and WWF WrestleMania - The Arcade Game (U) [!].smc > crackling noises seem to come from nowhere, doesnt happen in the E version Maybe we could make a list of non working games? non working due to missing emulation of the needed chip or accessorie? the list shouldnt be too long right? Yoshi's Safari All versions > needs Lightgun, unemulated X Zone All versions > needs Lightgun, unemulated BS*, all games starting with BS > Needs BS emulation, unemulated |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 2:27 pm Post subject: | |||||
|
|
|||||
|
Well then, give me some time to verify these. I'd like the non-obvious ones tested on hardware first if possible, especially the one with the dots. Ah well, it was a good run while it lasted. Looks like two is the lowest number of known bugs an SNES emu is ever going to see :P
That's what I was afraid of, having to use GTK+ input for keyboardsas well as SDL input for joypads :/ Why the custom widget, though? Can't I capture keypresses in a GtkDrawingArea, if I tell GTK to capture keypress+release events?
A copier BIOS, actually. Cowering strikes again. It should still probably show a menu. Perhaps I can find an emulation-mode CPU bug in it. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 2:33 pm Post subject: | |
|
|
|
| i expect you to fix em all!! lol thats only 68 games tested of the 1870 7zips in the dir, and most of those contain games for multiple regions, as i have to test all regions. Im planning on going through the entire list that will give a realistic view of all "obvious" bugs in the first 5 mins of every game. Edit. i left out the X-Band Modem BIOS which shows black screen because its a bios. too bad i wasted my time with X-Terminator 2 Sauke (J) [!].smc if its only a bios dang... Funny thing is i found a mame bug too About testing on a real snes, my guess is those games will have to be tested on a J or U snes, as mine is E and might not give accurate results, or am i wrong? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 3:15 pm Post subject: | |||||
|
|
|||||
It
very likely would not give correct results. Probably fairly close in
most cases, but I'm pretty sure, special board mods or not, the CPU
still runs at a slightly different speed. Different physical timing
crystals in each CPU core.
Well, you weren't able to save in Secret of Evermore for over 4+ months, and nobody noticed. I suspect there are many bugs remaining in bsnes that simply have not been discovered, and the majority appear to be with obscure Japanese games coded on a serious budget. If you were able to test all 1,870 of your 7zips, that'd be pretty cool. I could make a fairly accurate compatibility percentage rate that way. Of course, then we would need to classify what defines not-compatible (completely broken, minor dots on the screen, or somewhere in the middle?). EDIT: Looking at X-Terminator first.
O__O It sets the stack pointer to the MMIO region (open bus), and then pops values from it. Somehow, Super Sleuth works with this. I've no idea how. Perhaps Overload has partial support for this BIOS and maps WRAM here? As far as I know, SP >= $1fff does go to MMIO, and some games use this to write PPU registers via pushes to the stack... Unless I hear otherwise, I'm considering using $2dff as some sort of RAM area related to using special hardware (the copier). So I'm crossing this one off the list (again, unless I hear otherwise), and moving on. Last edited by byuu on Mon Aug 21, 2006 3:35 pm; edited 1 time in total |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 3:30 pm Post subject: | |
|
|
|
| Well
following mame, everything that doesnt happen on the real console is a
bug, but none of the bugs i submitted bar one make the game unplayable,
they are just graphical and sound problems. I say list it as is Game XX, has bug xx, you dont have to say if it makes the game unplayable or not per se, and its up to you to decide if a bug is worth fixing another one Winter Olympic Games - Lillehammer '94 (E) (M .smc and Winter Olympic Games - Lillehammer '94(U) (M .smc > black line appears after the selected event starts to move and load, the blackline stays visable as the background fades out. screenshot will be uploaded, possible ingame bug, also happens in Zsnes. Its probaly also a good idea to compile a list of bugs, that are gamebugs and not emulation bugs Last edited by tetsuo55 on Mon Aug 21, 2006 3:42 pm; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 3:41 pm Post subject: | |
|
|
|
| Ok, you might want to slow down just a little. Let me classify these reported games first. Not base SNES emulation bugs: X-Terminator 2 Sauke (J) [!] - BIOS, uses unemulated copier hardware Yuujin - Janjuu Gakuen (J) - The screen you're stuck at is asking for a password, not a name. Heh, rule of thumb: if the game doesn't crash, but you can't get it to go past a certain screen, and you can't speak Japanese -- it's probably not a bug. If you do speak Japanese, it probably is. Yogi Bear (J/U) - I cannot hear any sound corruption or crackling. This is likely due to you dropping slightly below 60fps, or maybe bad sound drivers. Try using log audio data and listen to the resulting WAV. 1 minute into the game with no errors on BGM or SFX. WWF WrestleMania - The Arcade Game (J/U) - Same as Yogi Bear. Played a full match (>1 minute), no BGM or SFX errors. Again, try making a wav log and play that back, you shouldn't hear any crackling. Confirmed in emulation, needs testing on copier: Yuujin - Janjuu Gakuen 2 (J) - single tile shows a tiny corrupt box at bottom right of window. This is due to writing outside of vblank, very likely to be a bug on the real SNES. Zan III Spirits (J) - Has little red dots on the title screen, could be due to mode7 algorithm, could be due to bug, could be anything. Very bizarre. Very minor detail, definitely needs hardware verification. This is also due to writing outside of vblank, very likely to be a bug on the real SNES. Winter Olympic Games - Lillehammer '94 (E/U) - does show black line, happens with ZSNES, SNES9x and bsnes. Super Sleuth corrupts most of the screen at this point (and then recovers), SNEeSe does not play this game at all. I'm betting the line appears on hardware, will need to confirm this one on hardware. Possibly an emulation issue we all share, but unlikely. Confirmed in emulation, almost certainly is a bug not present on hardware: Zenkoku Koukou Soccer Senshuken '96 (J) - does indeed crash. I have a hard time believing the game is supposed to crash on hardware. Happens way too far into the game, will have to extend debugger to trace error. Yuu Yuu Hakusho Final - Makai Saikyou Retsuden (J) - appears confirmed. I'll look into it. You won't see bugs with Yuujin2 or Zan3 on any other emulators (except maybe SNEeSe), because no other emus block VRAM writes outside of vblank. Edit notes: Yuujin issue previously mentioned was due to bad incremental link when I was testing. Game works fine in .52. Last edited by byuu on Mon Aug 21, 2006 5:39 pm; edited 10 times in total |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 3:43 pm Post subject: | |
|
|
|
| Shall
i compile a full list and submit when ive gone trough the entire list,
only submitting those that bugs that make a game unplayable before
submitting the full list? i wonder what is causing the audio problem in those ntsc games Edit: ive started making an excel sheet with more information so its easyer to read and confirm ill post it when i finish testing, i will not be able to check these bugs on my pal snes till i get it here at my new house, which will hopefully be in a week or 2. More good news Guru has already started re-dumping console games, i guess for a fixed mess set in the future? who knows good news is here: http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=83736&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1156115844 The problem is that little white blocks appear in the lower right corner of the testbox lines, the garbage begins to happen when the girl in the screenshot starts talking During this second test at the fountain the characters and text started to flicker. whats the CRC of the rom you are using? * Loading "E:\Emulation\Nintendo\SNES\Bsnes\wip\test\Yuujin - Janjuu Gakuen 2... * CRC32 : 70fbff3b * Name : "JANJYU GAKUEN 2 " * PCB : UNL-LOROM * ROM Size : 2mbit * RAM Size : 0bit * Region : NTSC * Coprocessor(s) : None * Reset:803a NMI[n]:f000 IRQ[n]:f8d1 BRK[n]:ffa4 COP[n]:ffa0 * NMI[e]:f000 IRQ[e]:f8d1 BRK[e]:f8d1 COP[e]:ffac |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 4:51 pm Post subject: | |
|
|
|
| Same checksum, I'm not getting any flashing, though. Tried five times, can't get the characters to flash. I see the box, quite a ways into the game, actually. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Aug 21, 2006 5:24 pm Post subject: | |||
|
|
|||
There's been a known bugs list on the first page for months now. It's even referenced in the title. All are free to report new bugs. I'll take a look at some of these reports when I get home tonight from class. You'll want to scan the roms with NSRT to make sure the games aren't using unemulated hardware. I suppose I should add peripherals, but I don't think a list of games is necessary. If you notice something wrong, scan it and see if it corresponds to unemulated hardware. If it does, the list has served its purpose and you need not report it. PS: NSRT can also output lists of games that require special hardware. I just recently was told of this. PPS: Regarding the sound crackling you experienced with certain games. Here's another suggestion to confirm for yourself whether or not this is legitimate: enable frameskipping to "1." That should clear up any distortion due to fps drops and verify whether or not it's the game or your computer. Last edited by FitzRoy on Mon Aug 21, 2006 5:49 pm; edited 1 time in total |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 5:44 pm Post subject: | |
|
|
|
| Also,
please don't add bugs until I can confirm them. Too many false bug
reports. Please dont misunderstand: I'm glad to get the feedback, I
just don't want non-bugs to get added is all. Zenkoku Koukou Soccer Senshuken '96 (J) and Yuu Yuu Hakusho Final - Makai Saikyou Retsuden (J) do appear to be verified. And we need someone with a copier to test Yuujin - Janjuu Gakuen 2 (J), Zan III Spirits (J) and Winter Olympic Games - Lillehammer '94 (E/U). I suspect at least two of these happen on real hardware, but I could always be wrong. As for the sound bugs, I don't experience them. If someone else wants to test, that'd be cool. I can always overclock the APU a little, as other people have reported the DSP frequency at >=32040hz, and not 32000hz as I use now. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Aug 21, 2006 5:53 pm Post subject: | |
|
|
|
| No, I wasn't going to. I learned my lesson the last time I did that. And you know it's getting harder to find stuff when you're reporting possible bugs in bsnes that actually turn out to be game bugs that are inaccurately fixed in all the other emulators (G.O.D.). | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 6:00 pm Post subject: | |
|
|
|
| thats why i suggested the games buglist, i dont see a link to a know games buglist in the first post though? from now on i will confirm sound bugs by checking framerate and recording the audio. Finished W X Y and Z, about 250 games tested, about 12 skipped for unsoported hardware. Compatibility is awesome!!! 1 more bug to report World Heroes 2 (J).smc Blackscreen when starting game, game does seem to work though, works in zsnes World Heroes 2 (U) [!].smc Blackscreen when starting game, game does seem to work though, works in zsnes Last edited by tetsuo55 on Mon Aug 21, 2006 6:57 pm; edited 4 times in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Aug 21, 2006 6:15 pm Post subject: | |
|
|
|
| Oh, I see what you're saying. I won't be interested in that myself, but you can feel free to make one. The thing is, most emulator bugs are blatantly obvious not to be game bugs or glitches. When they aren't, it's usually just a matter of testing on the real snes via a copier. So compiling a massive list of game bugs and glitches isn't really a good use of time. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 6:20 pm Post subject: | |
|
|
|
| Ill keep the list mostly to myself then, although in a finished state it would be of great help to other emulator authors and mess. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 6:51 pm Post subject: | |
|
|
|
| Confirmed that World Heroes 2 is not working. Man, 120 unsupported special chip games in W-Z alone?? x.x |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 6:58 pm Post subject: | |
|
|
|
| Doh!! how did that zero get there i ment to type 12 Actually a lot of the BS games worked partially, so did the superscope games, only 1 superfx game there and that didnt do a thing |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Aug 21, 2006 7:30 pm Post subject: | |||||
|
|
|||||
Offtopic, but...
Is there a special reason that causes hex. digits to be converted to lowercase? It's just that personally, I prefer uppercase... _________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 7:46 pm Post subject: | |
|
|
|
| Yes, because I prefer lowercase :) I use %x, you use %X. So then, 100 - 3 / (250 - 12) = ~98.75% compatibility rate. Eh, not too shabby. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 8:28 pm Post subject: | |
|
|
|
| Actually Tested W-Z exactly 122 7zips, all containing several regions Exactly 193 Roms Non working 5 x bs 2 x SuperScope 2 x bios 1 x FX chip 3 x Bug that makes game unplayable total non working in Bsnes, excluding baddumps(2 untested baddumps not counted in above list) and bios 11 Total working in Bsnes 183 100-3/(193-8 ) = 99.98 % compatibilty rate for W-Z (excluding 2 games which are known bad dumps) And are those bioses even supposed to do anything on a emulator? Last edited by tetsuo55 on Mon Aug 21, 2006 8:32 pm; edited 1 time in total |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Mon Aug 21, 2006 8:31 pm Post subject: | |||
|
|
|||
BS-X? Not surprising. I don't know what exactly that falls under (special chip?) Lack of Super Scope (mouse) obviously will have problems. BIOSes generally don't matter at this point. _________________ FF4 research never ends for me. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 8:37 pm Post subject: | |||
|
|
|||
|
The
BIOS I looked at was setting the stack pointer into the memory mapped
IO region. Therefore, it requires emulation of special copier hardware
to display anything at all. Super Sleuth does emulate it (at least to
some extent), but I do not. Oh wow, my compatibility math was wrong, heh. 99.98%... nice :)
Will have to update that ;) Thanks for testing so many games, tetsuo. |
|||
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Mon Aug 21, 2006 10:10 pm Post subject: | |
|
|
|
| Stack in MMIO? I guess it makes sense that copiers would want to disturb WRAM as little as possible. BTW, Aaron Giles added a new raster timing system to the MAME/MESS core. I pointed him to your SNES Doc Project dot timing page so he'd understand "necessary additional features" And Nach: yeah, there's no substitute for good auto-complete, that's for sure. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 21, 2006 10:16 pm Post subject: | |
|
|
|
| I will say this one time and one time only. Don't mess with my compatibility list, or suffer this fate :P    Apparently, you should mask the upper seven bits of VTIME and HTIME. Same bug in all three games. tetsuo, thanks very much for reporting these bugs, this is a fairly important fix just in time for the next release. tetsuo, would you mind recalculating your algorithm, now? 100 - 0/(193-8) = ? :D |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Mon Aug 21, 2006 10:43 pm Post subject: | |
|
|
|
| Congrats
on your fixes, byuu... Keep up the good work. I don't post much in this
thread but enjoy seeing you improve your emulator. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Aug 21, 2006 10:54 pm Post subject: | |
|
|
|
| Byuu you truly are awesome!, i knew youd fix those quickly. Could i get the current version where this bug is fixed for further testing? just in case any other games have this bug in the buildi have |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Aug 21, 2006 11:53 pm Post subject: | |
|
|
|
| Damn, fixed before I could add them again. And wow, what are the chances all three in W-Z shared the same bug? If it's that prevalent, I can't help but agree with tetsuo's request. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Aug 22, 2006 12:11 am Post subject: | |
|
|
|
| And
what if we split the testing,so one can start from A-Z and Tetsuo can
continue from Z to A? It would speed up the testing and make it twice
as reliable as a bonus? Great work,byuu.This is the best thing since MAME and NEStopia |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 22, 2006 8:10 am Post subject: | |
|
|
|
| I
can do all of the US and E region games since I've gone through most of
them already. I've done 1/3 of the J games, but it was mostly random. Someone with an NTSC system and copier needs to step up and confirm the Zan III and Lilehammer anomolies, as well as future discoveries. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 22, 2006 9:34 am Post subject: | |
|
|
|
| Working toghether on this would be quicker if everyone follows these guidelines i can add the information to my database Count all tested games for each letter of the alphabet, make a list of all games that did not work for whatever reason, and keep an eye open for graphics bugs once the list is complete we will have to test them against a real snes so i can finish the list of snes game bugs vs bsnes bugs and then byuu can fix them all, and maybe add a comment in his database for those games that have gamebugs., after that maybe byuu can start adding more of those unsopported peripherals and chips After that all the bugs are fixed well have to do another run to check for any regressions. Edit: I was thinking maybe if we give byuu a list of all the non working games, bsnes could give some kind of warning when someone is trying to play a superFX game or something like that. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 22, 2006 11:37 am Post subject: | |
|
|
|
| Unless byuu expresses uncertainty on a certain bugfix, I would say regression testing is unnecessary on anything but major rewrites. Usually, he or someone else finds out exactly what was wrong and corrects it. That's why I thought those PAL tests with you were important, because that was one that he wasn't sure about. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 22, 2006 11:59 am Post subject: | |
|
|
|
| cool i hope i get those pal tests soon then maybe blargg could make some ? i blieve his tests are ment for ntsc right? EDIT: V Untested > none Tested > 12 roms Problems found: Verne World (J).smc > shows a green bar at the bottom of the screen, doesnt happen in zsnes, music sounds a lot different from zsnes, needs hardware verification. Vortex (E/J/U) [!].smc > black screen, SuperFX game U Untested > Undercover Cops, no good dump known Tested > 47 roms Problems found: Super Daikoukai Jidai (J).smc > this game looks cropped at the top, looks normal in zsnes. Uchuu Race - Astro Go! Go! (J).smc > audio real low, needs verification on real hardware UFO Super Drive PRO 3 BIOS.smc > black screen, because its a bios! |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 22, 2006 3:34 pm Post subject: | |||||||||||||||||||||||
|
|
|||||||||||||||||||||||
I didn't have a chance to get on my main PC and build another WIP. If you can compile the source, edit src/cpu/scpu/mmio/mmio.cpp and change mmio_w420[7-a] functions to mask status.[vh]irq with 0x1ff after updating it. Otherwise, I might be able to get one up Wednesday night. Got a lot of real life stuff going on, so I'm quite busy as of late. Hopefully not too busy to miss this weekend for a release date. If I can't get the SDL input working before the weekend on Linux, I'm just going to release it and let people use the pure-SDL / non-GTK version.
Quite lucky indeed.
Agreed. And that dating sim one, too. Someone will need a damn good TV to see that one, though. I'm pretty sure Zan and the dating one will happen on hardware, but I could be wrong. Winter Olympics I'm not so sure about.
I do break things on occasion. Most of the time it seems to be memory map modifications that cause it. But I usually test all of the major memory map offenders before releasing a new WIP. I know Dezaemon and Tokimeki saves might be a little screwy right now, but eventually those'll get added to the DB. Their issues have nothing to do with core SNES emulation.
Soon as I have free time ;) Which means probably 3+ months from now, heh. -----
I show line 224, ZSNES does not. Lots of games don't bother setting the data there, but some do. I asked about this and most people wanted me to show line 224, so I did. I can add cropping options for it if demand is there.
Try it in SNEeSe. If SNEeSe sounds like bsnes, it's likely correct. If it sounds like ZSNES, bsnes likely has a bug.
Guilty, fairly obvious. SA-1 games are far more insidious, most people know which games used the SFX chip, but few know which ones actually used the SA-1. Lots of obscure golf games and such use the chip. Detection and warnings in the emu would be good, another issue of time.
Uses overscan mode, despite being an NTSC game. Set video standard to PAL and it looks just like ZSNES.
Same thing, compare to ZSNES and SNEeSe.
Indeed :) |
|||||||||||||||||||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 22, 2006 4:10 pm Post subject: | |
|
|
|
| I'm going to test all those buggy games on my pal snes at least, but someone with an ntsc snes needs to step up and help out. Well the good news then is that none of the problems in V and U seem to be caused by bsnes. awesome! although it would be nice if uncharted waters autoselected pal display mode hehe, as its strange for a ntsc game to need that. sorry to hear your so busy, but as always real life comes first I removed all my compiling tools so i will have to wait till you have time to compile a wip then. The option to disable that last line would be nice though. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 22, 2006 4:19 pm Post subject: | |
|
|
|
| I'm thinking about getting one of those tototek flash carts. Anyone here have experience with one of these? Any drawbacks vs a standard copier? I'm leery because they are less expensive... seems like they might have some limitations. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 22, 2006 4:31 pm Post subject: | |
|
|
|
| Hmmm,
i have started retesting BS games, and a lot of them work completely,
so i will be retesting these and adding them to the bug reports the handfull that dont work can probably be fixed EDIT: BS testrun: BS Wai Wai Check 3-7 (J).smc > Game seems to work but there is no audio and the graphics are garbage BS Wario no Mori (J).smc > seems 100% working BS Yung Hakase no Shinsatsu Shitsu 1 (J).smc > seems to work completely, but fonts are garbage BS Yung Hakase no Shinsatsu Shitsu 1 (J).smc > seems to work completely, but fonts are garbage BS Zootto Mahjong! Event Version (J).smc > seems 100% working BS Zootto Mahjong! Preview Version (J).smc > seems 100% working BS Panel de Pon - Event '98 (J).smc > seems 100% working BS Tantei Club - Yuki ni Kieta Kako 1 (J).smc > Black screen BS Tantei Club - Yuki ni Kieta Kako 2 (J).smc > Black screen BS Tantei Club - Yuki ni Kieta Kako 3 (J).smc > Black screen BS Tora no Maki 5-17 (J).smc > Black screen BS Tora no Maki 5-31 (J).smc > Black screen BS Treasure Conflix (J).smc > game works but fonts and some spirtes are messed up BS Yoshi no Panepon (J).smc > seems 100% working PS, FitzRoy could you make that list of special chip/add-on games from NSRT??, and i have never heard about those carts before sorry. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 22, 2006 5:03 pm Post subject: | |||
|
|
|||
The biggest one is that it has a BIOS on-cart. Even if you only have one game, the BIOS runs and ruins your chances at getting a clean power-on state to test with, which is what I desperately need at this point. Other than that, it probably works fine. The price does seem pretty high though, but I guess the Tototek guy does not have volume pricing on his side. I can't hear sound that well with these shoddy headphones at work. Can someone please compare audio from Verne World and Unchuu Race in ZSNES<>SNEeSe<>bsnes and post results? |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 22, 2006 5:57 pm Post subject: | |
|
|
|
| Well,
that's cool. Maybe I'll pick one up. Then we'll finally have someone
with a copier, a tv input card, and a prompt willingness to help I'd test those roms but I'm at work for another 4 hours. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 22, 2006 6:22 pm Post subject: | |
|
|
|
| Verne
World and Unchuu Race sound the same on SNEeSe as on Bsnes, Unchuu Race
however sounds a bit less loud on SNEeSe, but so does Verne World So those can both be removed |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 22, 2006 6:36 pm Post subject: | |
|
|
|
| Thanks for confirming. Much as I'd hate to add a bug that isn't really one to my list, it'd be worse to skip over a real bug. We should report this potential audio bug in Verne World to the ZSNES dev team, then. Of course, ZSNES may have it right, but probably not since SNEeSe is well regarded as having the best S-DSP emulation of them all. Uchuu Race is probably just different default volume levels between emulators... volume knob fixes that easily enough :) So yay, U-Z sans special hardware = perfect :D |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 22, 2006 6:49 pm Post subject: | |
|
|
|
| audio sounds different to real snes in a lot of games in zsnes though.. Were goin for 100% compatibility here Why do you think those bs games have messed up fonts? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 22, 2006 10:54 pm Post subject: | |
|
|
|
Apparently,
BGnVOFS is not doubled for interlace. Even though it is for hires. This
took a really, really, really long time to figure out.  Now then, if you want to make my ultimate dream come true... help me find a bugfix for Uniracers (that isn't a hack) before another bug I'm unable to fix is reported. Even if other bugs pop up in the future, that's fine. But just knowing I was able to reach zero known bugs... even for one brief moment in time... would really mean a lot to me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 22, 2006 11:21 pm Post subject: | |||||||
|
|
|||||||
|
Here is a log of Uniracers OAM accesses: Legend: w21nn - MMIO port written to <vcounter, hclock> vcounter - scanline when action occurred hclock - exact clock position on scanline, divide by 4 for estimated hcounter addr - absolute OAM address where write will go (for $2104), or new OAM address after write (for $2102,$2103). Note that this is 2 * value written to $2102-$2103 data - data written to MMIO register OAMreset - known OAM address reset after start of vblank
Basically, the problem is with these writes here:
Both of these should go to addr=0218, and the game will work fine. I don't know how correct that is. If I block the writes, the game fails to work correctly. If I force them to 0218, it works. But I cannot say for certain that hardware is writing to 0218 here. SNES9x uses a hack to force these two writes to $0218 for Uniracers alone. ZSNES somehow manages to run Uniracers correctly, and supposedly does not have any hacks. I do not know how this is possible, but perhaps a ZSNES dev could shed light on how their OAM address invalidation code works, possibly? From what I can tell...
OAM $0218 = extended attributes for sprites 96-99. By alternating between 5a and a5, the game is toggling X.d8 (moving sprite onscreen or offscreen, in this case) and the OAM size attirubute, which I'm sure is meaningless in this case (if it's offscreen, size does not matter). I'm guessing it's using 96,97 for the top screen, and 98,99 for the bottom screen (I might have those two pairs switched around). |
|||||||
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Wed Aug 23, 2006 12:14 am Post subject: | |
|
|
|
| Maybe looking at the fix zsknight did can help Check out Revision 1.39. http://zsnes.cvs.sourceforge.net/zsnes/zsnes/src/vcache.asm?sortby=log&view=log |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Aug 23, 2006 6:06 am Post subject: | |
|
|
|
| Its gonna take a little while for me to get through T 160+ roms in that letter alone Thinking of the uniracer bug, i didnt test any 2p modes, so there could still be 2p bugs somewhere? maybe ill have to retest all 2p games sometime with a friend. I hope NSRT can pop out a list of all 2+player games also? Im not too worried about unfixable bugs, even better maybe if a find another game that has the same bug as uniracers it will help you fix it quicker as there will be more hints to whats causing it, although i have a lot of hope for that link bob posted I'll try to get my snes back this sunday and then test those reported games for bugs on PAL hardware. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 23, 2006 2:16 pm Post subject: | |||
|
|
|||
Unforunately, that link only supplies this one line of changed code:
That... doesn't explain anything to me :/ However, I think I have an idea that -might- just work. I noticed the last write to $2104 before the start of the frame went to $0218... what if the "OAM reset" address is set by the last write to $2104 (and not $2102-$2103), and the OAM address is restored at the start of hblank for every line instead of just at V=225,HC=~0-6? |
|||
ZSNES Developer
Joined: 29 Jul 2004
Posts: 116
Location: Germany
| Posted: Wed Aug 23, 2006 2:50 pm Post subject: | |
|
|
|
| Zsknight fixed more than that. This is the correct fix: https://zsnes.bountysource.com/svn/!revision/419 |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Wed Aug 23, 2006 2:58 pm Post subject: | |
|
|
|
| Maybe nach or pagefault can explain zsknight's fix to mid-screen OAM updating and if it is indeed correct to the hardware. P.S. Snv presentation is a lot better than the cvs. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 23, 2006 3:26 pm Post subject: | |||||
|
|
|||||
It definitely isn't. It's a hack that specifically checks for the values written by Uniracers to get the game working :(
|
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Aug 23, 2006 4:24 pm Post subject: | |
|
|
|
| Too bad byuu maybe ill find another game that has a similar bug and you can combine the information from both games to fix it By the way, has the "rom" been verfied to work perfectly on hardware? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 23, 2006 5:46 pm Post subject: | |
|
|
|
| My theory fails. It works in Uniracers but breaks Donkey Kong Country. Yes, Uniracers works on hardware. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 23, 2006 5:50 pm Post subject: | |
|
|
|
| @
tetsuo: If you're suspecting it's a bad rom, keep in mind that this
problem occurs in all three regions of the rom. The chances that all
three are bad, and bad with the same affliction, is quite frankly, zero. I tested Verne World last night and noticed nothing out of the usual on either zsnes or bsnes. Perhaps you've got your zsnes sound settings messed up, since that emulator offers you the opportunity of doing so (something I never understood). I did notice the "clipping" in Super Daikoukai Jidai. What's happening here, byuu, is similar to what I reported about Super Mario Kart (E). Looks like the game uses overscan, except this time it's not PAL. Good job on the RPM Racing fix. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Aug 23, 2006 6:25 pm Post subject: | |
|
|
|
| I tested it with default settings, no cfg file or anything. I notice a distinct difference in the pitch and lenght of certain notes, its subtle but noticable. Maybe ill get my snes tommorow and ill be able to so some early testing what happens with Donkey Kong country when you try the fix for uniracers? |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Wed Aug 23, 2006 6:50 pm Post subject: | |||||
|
|
|||||
So I heard it's quite common for NTSC games to use overscan, although not so common for US NTSC releases. Try Destructive (J) while you're at it. It's probably not common to find a TV which recenters any image fed to it, regardless of the number of scanlines between vertical blank. What happens when overscan is enabled after NMI? Oops, PPU resumes drawing. Then what happens to the magic centering? Oh yeah, and any display which recenters the image would have to be displaying a frame behind the signal. That may also count in anything which displays interlaced signals as progressive scan, with or without frame rate doubling or motion interpolation filter. Hmm... |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 23, 2006 7:15 pm Post subject: | |||||
|
|
|||||
|
Here's an updated log with force blank status (fb): (EDIT: and Super Sleuth tracelog output) (EDIT2: commented on each action)
I don't know what happens when you enable overscan between V=225 and V=239. Regardless, the image *is* recentered on my TV if you enable overscan normally and leave it on. I imagine if you enable it that late, it will look the same as if the frame did not use overscan at all. It could even be the PPU that's modifying its output based on overscan setting at the start of a new frame (similar to how it works with interlace). Last edited by byuu on Wed Aug 23, 2006 10:11 pm; edited 1 time in total |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 23, 2006 9:34 pm Post subject: | |
|
|
|
| My
bad on the superfluous overscan report. I think I'm going crazy, I
could have sworn I read a comment like "I don't notice it" from byuu on
that game. Anyhow, I'd like to propose my middle finger to both PAL and snes overscan mode. Both are fucked up ideas that have fucked with the possibility of a simpler world. I've noticed Super Sleuth has its display window permanently heightened to account for those games. Is that seriously what's going to have to be done? Edit: In the future, I'd appreciate being corrected for stupidity. I realize now that adding resolutions to the multipliers would be stupid because the snes is capable of many different resolutions when you include regions, overscan, hi-res, and interlace. I also think what you're doing right now isn't that bad, but setting to PAL for an NTSC game seems weird. Have you thought about adding a new setting, or just doing what Sleuth does? |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 24, 2006 2:53 pm Post subject: | |
|
|
|
| Got my snes, but the powersupply is damaged, need to fix it Its good to see my Super Wildcard DX again, although im still hoping to get a wildcard DX 2 some day. i have another copybox but im not sure which one, i think its a Wildcard 32m But it doesnt work, need to check every IC and rom/ram chip with a voltage meter to check which one is acting up. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 24, 2006 3:46 pm Post subject: | |
|
|
|
| Ok,
basically I was able to find out a little bit about mid-frame OAM
writes. But not enough to emulate Uniracers. Unfortunately, it does not
look like I'm going to be able to fix this game properly before v0.017,
and consequently, before more bug reports come in. Sigh. I did my best,
at least. Basically, this is where SNES emulation at this point really stands: CPU - 99% of games run, 95% hardware accurate, little headway on bus/event conflicts. APU - same as CPU. DSP - 99% of sound in games works fine, ~80% hardware accurate, DSP cores currently read in multiple bytes from DSPRAM "immediately" and run it at 32khz. In reality, it probably runs at 1.024mhz and performs sequential reads that could cause 1-sample differences based on timing of APU memory accesses. This would undoubtedly be the hardest area to get hardware accurate. It's very hard to run timing specific tests on the DSP, and the difference at best is probably only a sample anyway. No tangible benefits and no perceived difference. Very tough work indeed. PPU - 99% of games display no graphical errors, I would go so far as to say not hardware accurate at all. We're treating the PPU as if it runs at ~13.5khz by rendering entire scanlines at a time. In reality, it needs to be run at ~5.37mhz, *possibly twice that*. An unbelievable difference that has all kinds of consequences and internal variables that have yet to be discovered. We've only discovered how to match SNES output in the most basic cases. Luckily, unlike the NES, very few SNES games attempt to exploit the renderer much more than modifying windows and scrolling regs during HDMA. But the second you start doing things like mid-frame OAM/CGRAM writes, all hell breaks loose and no emulator even comes close to real hardware. The PPU is going to need massive work and a whole new emulation approach if we're ever going to get true hardware accuracy. We're going to have to decode all kinds of insane internal state machines based solely on megabytes of data logs. This isn't like emulating a CPU. With a CPU, you control what it executes, it runs your program. And your program can analyze what's going on. With the PPU, you're feeding a custom program input, and reading its output (think DSP-1-4 and how long those took to emulate, and imagine this being even more complex than that). What we essentially have to do is emulate the internal PPU "program" and run it in sync with the CPU and its clock. I can't begin to estimate how much more power this will require, but suspect it will be quite a lot more than currently used. But I'll try and leave bPPU in there for gaming purposes. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 24, 2006 4:28 pm Post subject: | |
|
|
|
| Dude, one known bug is stellar, and .017 will be an incredible release. Libco had some regressions, but you ended up finding them all, and in the end it kicked bcpu's ass. I think the question on everyone's minds though, is what will you work on next? Do you think you'll start doing more unemulated chips and peripherals, or will you start tackling this big PPU thing? | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 24, 2006 5:30 pm Post subject: | |
|
|
|
| Fixed the power supply test run on PAL snes with PAL superwildcard DX Yuujin - Janjuu Gakuen 2 (J) - single tile shows a tiny corrupt box at bottom right of window. This is due to writing outside of vblank, very likely to be a bug on the real SNES. Graphics corruption in bottom right of window do NOT happen on hardware, however the flashing sprites at the fountain DOES happen. Zan III Spirits (J) - Has little red dots on the title screen, could be due to mode7 algorithm, could be due to bug, could be anything. Very bizarre. Very minor detail, definitely needs hardware verification. This is also due to writing outside of vblank, very likely to be a bug on the real SNES. Corrupt dots do NOT show on hardware Winter Olympic Games - Lillehammer '94 (E/U) - does show black line, happens with ZSNES, SNES9x and bsnes. Super Sleuth corrupts most of the screen at this point (and then recovers), SNEeSe does not play this game at all. I'm betting the line appears on hardware, will need to confirm this one on hardware. Possibly an emulation issue we all share, but unlikely. black line does NOT show on hardware, tested U and E Verne World sounds exactly like on hardware Tested uniracers(U/E) both roms crash my snes, bad dumps after all? i know the original game worked. EDIT: the beta works normaly on my snes, but still shows the bug in bsnes Sorry Byuu |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 24, 2006 6:18 pm Post subject: | |
|
|
|
| Nice follow-up tetsuo. There goes the 1 known bug, but it's still not the weekend yet.
I'm testing more U roms today, but for the last hour or so I played
Arkanoid to make sure the level 22 gfx bug in zsnes does not also occur
in bsnes (it doesn't). Regarding Uniracers not working, is it possible your headers are messed up or absent on those roms? Copiers need roms with clean headers, but emulators ignore them. Use SNESTool or NSRT if so. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 24, 2006 6:21 pm Post subject: | |
|
|
|
| All
the roms where headerless, and special SWC header was added, they all
have the same header, so why would the beta work when the finals dont
if its a header problem? too my dismea i found out that NSRT is not able to add SWC headers and ucon64 cannot add them either so i used snestool1.2 All other games worked fine, i dont think its a header problem ---- Also there doesnt seem to be a (J) version of unirally. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 24, 2006 6:32 pm Post subject: | |
|
|
|
| Well that's really odd. Why the heck wouldn't the game work on a copier :/ And you're right about the J region. Fixt. By the way. I just tested your three confirmed bugs on .016 official. Zan III and Yuujin are both fine in .016, so they appear to be regression bugs. XIII Olympics still has the bug in .016. That info ought to help. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Aug 24, 2006 6:42 pm Post subject: | |
|
|
|
| tetsuo55, SNEeSe does not support special chip games. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 24, 2006 7:06 pm Post subject: | |||
|
|
|||
Sorry for what? Not testing NTSC games on an NTSC system so that the bugs could be properly verified? There are CPU speed differences and vblank frame delay differences that could easily cause your results to not match hardware. Even if you have some rigged up toggle switch, I wouldn't trust it vs using it on an NTSC system. I will test with my UFO since nobody else has. For one, PAL hardware runs 312 scanlines instead of 262, so it has more time for vblank. I bet if I force those two games into PAL mode, they will work fine in current bsnes. And on the bright side, while other emulators are getting bug reports of games crashing and displaying full screens of garbled tiles, I'm getting nitpicks about two tiny red dots appearing on the bottom right of the screen when they shouldn't. That's actually good news, not bad :) Anyway, I'm not worried about it. They probably are bugs. Report it as bugs or don't, your call FitzRoy. I'm getting 0.017 out this weekend, and then I'm going to start working on a dot-accurate PPU core. Expect that to take at least two years to be usable. No exaggeration. And that's assuming I succeed at all. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 24, 2006 7:21 pm Post subject: | |
|
|
|
| Sorry for raising the buglist by at least 1 i know the 2 others still have to be verfied against NTSC |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 24, 2006 7:32 pm Post subject: | |
|
|
|
| Hmm,
every oddity we've noticed thus far arising from the scpu addition has
been a regression bug, and something tells me these will end up being
no different. Anyway, I agree that they still need to be verified on
the native system. I never added them because of that. I won't have my
tototek cart until next week, so I'm sorry you had to do this yourself. And before you consider that 2 year project, I really wish you'd to consider adding the special chips that you're capable of doing. I know about SA1 and FX, but is there hope for the others? |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 24, 2006 8:04 pm Post subject: | |||
|
|
|||
*nods* ---- Winter Olympic Games - Lillehammer '94 (E) has been verfied on hardware so that can be added to the list, both E and U did not show the black bar |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 24, 2006 8:07 pm Post subject: | |
|
|
|
| What
others? You know of any *good* special chips that aren't emulated?
DSP-3/4 is too experimental for my tastes and probably mostly in asm --
if you want to prove me wrong and link to pure c++ cores, please do :D The anonymous people who emulated these two chips did an awesome job, but I don't want to add incomplete stuff and end up with bugs I cannot fix myself, eg like in MMX2. ST01n lacks any good games for them. SPC7110 would require a special devsystem so I could (try to) RE the decompression. BS-X, too little info. ST, give me the cart mapping info and I'll add it. Extra controllers, all requires a mouse but the multitap. I'm not adding anything requiring a mouse anytime soon. SGB, Game Genie, ... no. Maybe in a few years. SFX, maybe in a few years. SA-1, probably never. Marvelous may be cool, Kirby 3 may be nice (if slow), and SM:RPG may be popular (despite sucking), but none of the other games are any good to warrant taking several months/years away from core SNES emulation. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 24, 2006 8:24 pm Post subject: | |
|
|
|
| okay... Question about libco, could it be combined with multicore cpu'sfar faster results?? What about things like sse4 and 64bit? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 24, 2006 11:47 pm Post subject: | |
|
|
|
| Actually,
C4 and DSP1 turned out alright in the end, didn't it? So long as Nach
didn't mind helping you fix that. You also won't have to worry about it
messing up the buglist. I would include a new section called partial
hardware support. It's better than having nothing, since there are not
likely to be many major developments. Plus that, would those fixes have
even been made or discovered if you hadn't tried to emulate these in C++? It's strange to me that the zsnes team has been porting asm code to C, but the recent additions of DSP3/4 are in ASM? Super Sleuth seems to have partial support, but maybe you and Overload could work together on it? SPC7110 sounds hopeful. If the ST chips can be added, I'd love to see them, despite the fact that the games aren't too good. Supporting more games is good, even if you happen to dislike them. I mean hey, they can't be worse than dungeon master
Since I'm a user, if I had to choose between getting more game support
first, or a more accurate PPU, I'd choose the games. If you just do
what you can, I'll bet nobody but you would be disappointed And just getting multitap is fine for the peripherals. Lots of good games use this, too. @tetsuo: I can answer the second question. SSE2 was made a compile-time option because people with older processors couldn't even run bsnes with it. 64-bit would probably be pointless and make bsnes incompatible for LOTS of people. And byuu has said he isn't going to offer a zillion different versions of his emu. Don't worry about your fps dropping, the official .017 release will be faster than the wips. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Aug 25, 2006 6:46 am Post subject: | |
|
|
|
| i
was actually thinking more into the future, now that conroe is out
there are some changes in the world of CPU, for one its performance
with existing code is excelent, and binaires specifically compiled for
conroe chips should be even faster! with cpu's like conroe and beyond in mind, i bet that even the new ppu could get 60/60 fps for multi cpu i was thinking 1 thread does syncing 1 thread does cpu 1 thread does spu 1 thread does ppu Even if its only 1 fps faster with this setup, in the future i think we could gain a lot, just think about it, 32 core cpu's are on the way, we should be able to emulate everything more accurately |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Aug 25, 2006 12:11 pm Post subject: | |||||||
|
|
|||||||
http://byuu.cinnamonpirate.com/?page=libco&bg=2&browser= _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Sat Aug 26, 2006 12:22 pm; edited 1 time in total |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Aug 26, 2006 9:48 am Post subject: | |
|
|
|
| ok i understand it now, thanks. EDIT: Almost finished with T, 26 roms to go... found a few graphics bugs but all supported hardware games worked up till now need to verify the bugs on hardware first, although none of them occur in zsnes. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 27, 2006 5:47 am Post subject: | |
|
|
|
| bsnes v0.017 released. Since the Winter Olympics bugs is so trivial and not tested on NTSC hardware, I've decided not to mention it in the readme with this release. Besides, I worked too hard to get that list down to one bug to have you guys ruin it for me at the last minute :P http://byuu.org/ Also redesigned the site to be a little more simplistic and upped the contrast of all the colors. I'm planning on adding a low-contrast stylesheet for those who prefer darker colored sites. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Aug 27, 2006 5:54 am Post subject: | |
|
|
|
| Your timing sucks byuu. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 27, 2006 7:24 am Post subject: | |
|
|
|
| Why's that? I'm in no competition with SNEeSe. In fact, I'm trying out the latest release right now :) For those visiting my site about an hour ago, I thought I had reintroduced that sound gibberish bug, but it went away when I restarted the emulator... go figure x.x The binary and source are back up on my site again. |
|
New Member
Joined: 27 Aug 2006
Posts: 1
| Posted: Sun Aug 27, 2006 9:24 am Post subject: | |||
|
|
|||
|
First of all I want to say hi to all and especially Byuu for his awesome emulator. The new version is very good and very fast!!! With the last version I couldn't run a normal game full speed, now I can run Mario Kart full speed. I have a suggestion: you should disable the screensaver in widowed mode. To do it you must simply intercept the WM_SysCommand windows message and if the command is SC_SCREENSAVE (screensaver) or SC_MONITORPOWER (shut down the monitor) and set the message resul to 0. I have a sammple code but unfortunately is in delphi (i never wrote a gui program in C or C++):
|
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Aug 27, 2006 10:26 am Post subject: | |
|
|
|
| Byuu great work on .17 the binary is a lot smaller and the emulation is a lot faster. Your new site layout is much easyer to read but, has also lost its charm. Also i would like to note that the pal version of Winter Olympics is 100% verfied to not have the bug on hardware, eventhough its trivial I finished with T, some things i still need to verify but here is a list of stuff i can not 100% verify Taz-Mania (U) [!].smc A green line that looks like the gras texture constantly passes over the road Zsnes looks OK NEEDS HARDWARE VERIFICATION This happens on the E version too, but i have to verify on hardware. Top Gear 2 U/E/J Black lines appear in bridge Ok in Zsnes NEEDS HARDWARE VERIFICATION All the bugs i found so far look like the Winter Olympics bug, there is a good chance they are all related somehow, and maybe could all be fixed with 1 bugfix Full report on T to follow after hardware verification The best news is all supported hardware games worked!!!, so compatibility in 1 player mode excluding small graphic bugs is 100% for T-Z S is going to take even longer, i guess there is going to be about 600-700 roms in there. |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sun Aug 27, 2006 10:44 am Post subject: | |
|
|
|
| Super
Mario Kart (the only game I test, let's face it ! :p) has a 1-line
flickering at the bottom of the first half screen, during race. (And I still have that gamepad problem, unfortunately...) |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Aug 27, 2006 10:59 am Post subject: | |
|
|
|
| Flickering line verfied in Bsnes, need to test on hardware, but im sure i dont remember a flickering line there. We have Mario Kart running all day in the store. | |
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sun Aug 27, 2006 11:02 am Post subject: | |
|
|
|
| Having played SMK for years when I was a kid, I'm also pretty sure it doesn't happen on real hardware. | |
New Member
Joined: 27 Aug 2006
Posts: 2
| Posted: Sun Aug 27, 2006 4:28 pm Post subject: | |
|
|
|
| Kirby Superstar (U) [!] isnt working in v0.017 |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Sun Aug 27, 2006 4:32 pm Post subject: | |||
|
|
|||
That's because SA-1 games aren't supported yet(?) by bsnes. |
|||
New Member
Joined: 27 Aug 2006
Posts: 2
| Posted: Sun Aug 27, 2006 4:54 pm Post subject: | |||||
|
|
|||||
yes, i just read the readme.. probably should have done that before. i noticed that starfox is the same case, but i could swear i played it on an emu before.. |
|||||
Veteran
Joined: 30 Jul 2004
Posts: 921
Location: Mexico
| Posted: Sun Aug 27, 2006 5:08 pm Post subject: | |||||||
|
|
|||||||
Other emulators have SA-1 support. _________________ _-|-_ |
|||||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Aug 27, 2006 7:22 pm Post subject: | |
|
|
|
| And Super FX support. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Rookie
Joined: 03 Mar 2006
Posts: 14
| Posted: Sun Aug 27, 2006 8:04 pm Post subject: | |
|
|
|
| Erm, any reason why sound isn't working for me?... logging audio data works... but I can't hear anything while a game is running. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Aug 27, 2006 8:10 pm Post subject: | |||||
|
|
|||||
That is indeed a strange issue. Perhaps your soundcard lacks 32khz support? What kind of soundcard do you use?
Alright, I get the hint -_- |
|||||
Rookie
Joined: 03 Mar 2006
Posts: 14
| Posted: Sun Aug 27, 2006 8:19 pm Post subject: | |||||
|
|
|||||
http://www.emu.com/products/product.asp?product=10447 This is also a recent problem, because previous versions of bsnes worked fine (can't think of which version off the top of my head) The card should be automatically resampling to 44.1 or 48khz, considering it does that when I play the 32khz file that bsnes creates...
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Aug 27, 2006 10:05 pm Post subject: | |||
|
|
|||
.017 hath arrived!
Uhhhh, no audio card should do that, but you can download .016 and tell us if that one works. Also, try deleting the cfg file, and make sure you don't have "mute sound output" enabled. Oh, and I hope that suggested screensaver supression code (a) works and (b) is implimented for the next version. |
|||
Rookie
Joined: 27 Jan 2005
Posts: 16
| Posted: Mon Aug 28, 2006 1:31 am Post subject: | |
|
|
|
| Byuu,
version 0.017 is a VAST improvement over 0.016 in terms of bugs and
speed. I salute you for your excellent hard work. Well done. I very
much look forward to your continuing progress with this project. many thanks! |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Aug 28, 2006 9:42 pm Post subject: | |
|
|
|
| I found a (cosmetic) issue in bsnes 0.017: The pictures of the SNES controller in the Input configuration and the artwork in the About box are gone. Not a big deal,but it looks kinda ugly now. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Aug 28, 2006 10:12 pm Post subject: | |
|
|
|
| Agreed that it looks much worse, but I did it to save bandwidth. The images were taking 337kb of space in both the main ZIP and source ZIP. Since MS GDI can *only* load BMPs, this was a direct 337kb executable size increase for two images, so until I can find a better way to both embed the images and store them in source... they shall be omitted :/ |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Aug 28, 2006 10:24 pm Post subject: | |
|
|
|
| Just as I thought I don't care about the artwork in the About Box,but there should be at least *some* kind of SNES controller layout description (even if it's in ASCII Art in the Input Config.This won't increase the size of the .exe at all. Also,I would like to see a button that clears all primary and secondary key mappings of all controllers with just one button press.Clearing all controls manually button by button can be tedious. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Aug 28, 2006 10:33 pm Post subject: | |||||
|
|
|||||
Well I'm back from my vacation. Someone else could host for you...
Can it load BMPs from memory? If so you can include a PNG file or something, and convert it to BMP in memory. Heck, just zlib compress it and and unzlib it in memory. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon Aug 28, 2006 10:47 pm Post subject: | |
|
|
|
| What
makes me thrilled with byuu's work is when I load Super Castlevania 4.
The sound is very accurate to what I remember, while other top
emulators have pretty messed up sound for this game. The patched
BS-Zelda rom works fantastic on this release too! I look excitedly forward a future release that fixes the sound issue during tripple buffering. Excellent work thus far! |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Aug 28, 2006 10:52 pm Post subject: | |
|
|
|
| FirebrandX,have you ever tried SNeESe? It's sound emulation is *almost perfect* (even more accurate than bsnes) You have to try the latest version and see for yourself |
|
Rookie
Joined: 27 Jan 2005
Posts: 16
| Posted: Mon Aug 28, 2006 11:41 pm Post subject: | |
|
|
|
| Small request: Ability to rename video profiles once customized. | |
Veteran
Joined: 30 Jul 2004
Posts: 921
Location: Mexico
| Posted: Tue Aug 29, 2006 12:00 am Post subject: | |||
|
|
|||
I was just pointing out that when he said he remembered playing sa-1 games before on an emu Still, OTHER EMULATORS SUPPORT SA-1 GAMES! AND SUPER FX! _________________ _-|-_ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 29, 2006 12:05 am Post subject: | |||||
|
|
|||||
I'm
interested to know what games you think sneese does better in sound vs
bsnes. zsnes and snes9x were a far cry, but these two sounded the same
in wav output tests. I'm on an egosys Juli@ with Sennheiser HD580s.
That's not what makes me thrilled. What makes me thrilled is this + a dream gui + almost every useful configuration option + the most accurate emulation and game support. After so many years of snes emultion, this is the all-in-one I was clamoring for 12 months ago when this thread began.
Already recommended it. Sort of. Yours would be too dangerous to put near the others. I only recommended a Primary + Secondary clear button. If the mouse could be made to highlight more than one entry, you could very easily wipe out a whole controller setup without the danger of having an apocalypse button. Last edited by FitzRoy on Tue Aug 29, 2006 12:24 am; edited 4 times in total |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Aug 29, 2006 12:12 am Post subject: | |||||
|
|
|||||
The performance characteristics would be awful in BSNES... Snes9x seems to be slightly ahead in the SuperFX support, but SuperFX has not been perfectly emulated to this date (I could be wrong here). _________________ FF4 research never ends for me. |
|||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Aug 29, 2006 3:41 am Post subject: | |
|
|
|
| One little feature request: I'd like to be able to load a ROM by drag-n-drop of a .zip/.smc/.jma file in the bsnes window. Almost all emulators support this feature and it's quicker for me for example to drag and drop a file from 7-zip File Manager (Total Commander-style) to bsnes than opening the ROM load dialog and navigating to the folder. I also would like an option to set the sound latency value (I don't know what bsnes is now using as default) I compared the sound of SNEeSe and bsnes and just noticed how the sound in SNEeSe was noticably better (even with that sound skip problem I'm having). SNEeSe sounds a bit cleaner,more dynamic,with emphasized bass and highs. Are you also hearing a difference or it's just my imagaination? It really sounds different to me. Last edited by kick on Tue Aug 29, 2006 7:47 am; edited 1 time in total |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Aug 29, 2006 4:13 am Post subject: | |||||||||||
|
|
|||||||||||
It's using d3dx library to save PNG screen shots, so you're looking at about 100KB of extra binary code just for libpng, and then the images only compress to 175KB, so that's barely 100KB savings. On the other hand, just by reducing snes_controller.bmp to 8bpp with Fireworks without dithering, and then converting the result to RLE8 BMP, we shave off 48,378 bytes. Then if you compress about.bmp to JPEG using Fireworks, at 85 quality, the result is very slightly blurred, but you'd have to actually toggle between the original and output to notice the difference. Shaved off another 259,599 bytes. Then for less than 10KB, you can use an OLE function to import that JPEG as an IPicture object, copy the resulting bitmap out for the life of the dialog, then destroy the object. I'll share that code in a minute.
Or you can apply one of the source patches I've made, which adds both Rar and 7-Zip support.
All of the terms you use are more commonly associated with placebo. Cleaner? More dynamic? Emphasized bass and highs? Sheesh. Maybe if you could capture the output of SNEeSe and actually ABX the difference, I'd take you more seriously. :P Anyway, bsnes v0.017 binary, and source patches which I've separated all of the changes into. Although I separated them from one big patch, and I haven't tested whether they all apply cleanly as separate patches. GUI changes for the image compression and JPEG loading coming soon. Last edited by kode54 on Tue Aug 29, 2006 4:33 pm; edited 2 times in total |
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 29, 2006 4:36 am Post subject: | |||
|
|
|||
Indeed. And we already did comparisons months ago with wav outputs of the first 90 seconds of Super Castlevania IV on most emulators, which also included a digital recording from a real snes. The resulting discussions are in this thread somewhere, but I doubt the files links are still alive. On another note, I've added tetsuo55's latest bug findings. These are obvious in my opinion. The middle line in Taz-Mania is not aligned correctly. The grass is being drawn where the road should be. Top Gear 2's bridge should be solid, but there are black lines being introduced. Both of these are also regression bugs, as they do NOT occur on .016. The consensus on Super Mario Kart seems to be that this is a bug as well. I, too, played this game a great deal and don't remember any flickering. It's going on the list. The XIII Olympics bug is not a regression bug, but if you choose training mode, the screen looks fine. But once you choose an event, some fancy effect triggers the black line to appear. tetsuo confirmed that this does not happen on the E version of the game on an E console. So it's on the list as well. |
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Tue Aug 29, 2006 5:34 am Post subject: | |||
|
|
|||
Except I found SneESe to have a lot of visual emulation problems. It ran quite poorly for me. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Aug 29, 2006 5:43 am Post subject: | |||||
|
|
|||||
True, but no emulator is really perfect right? It's been worked on, but for games it has no problems in, it does sound rather good. _________________ FF4 research never ends for me. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 29, 2006 8:21 am Post subject: | |||
|
|
|||
|
Super
Mario Kart will likely never be fixed properly. It makes heavy use of
the DSP-1 which, while emulated bit-perfectly, does not include timing
emulation in any way. So don't expect the flickering to ever fully go
away. As of now, the DSP-1, DSP-2 and C4 all suffer from the same bug. As far as single complete line errors, these are also most likely due to the scanline-based renderer. I'll try moving the render clock position for the time being. In addition, I'll add a config file option so these bugs can be isolated and classified. Please note that when/if I add a dot based renderer, lots of "micro-line" errors are going to start appearing, such as Metroid 3's status bar showing 3-4 pixels of black onto the next line that should be the overworld. Lots and lots of games use IRQs for hblank effects and severely overlap it and write during active display. We know this works on hardware (mid-scanline writes), and most TVs cut off too much to see it. Of course, some of these could be real bugs. It'll be tricky, indeed.
It's been well known for a long time that SNEeSe is/was king of SNES audio. And for good reason, Charles Bilyue and Brad Martin spent a ton of time researching audio a great deal. However, anomie's DSP core is based heavily off of their work, and bsnes' is almost directly derived from anomie's work (I'd call it more of a port than a rewrite). In addition, it's had countless bugfixes by the talented DMV27. Therefore, I have to agree with kode54. With no confirmed audio bugs in bsnes, I'm also very interested in actual wave graphs showing problems in bsnes (FitzRoy can use his S/PDIF connection to confirm, hopefully). Not to brag, but so that I can fix the problems and catch up to SNEeSe eventually one day. kode54, I don't want to add OLE stuff to bsnes. I will simply remove the about image, as it isn't really necessary anyway. The controller image sounds like a good idea. Also, in the future, could you guys include updated files as well as those diff files? I don't use diff, so it's kind of a pain to read those things all the time. I would like the complete files if possible. And I also prefer zip format for things. They're just text files, so no need to compress with 7-zip. Actually, I'd like your recent changes as well in ZIP as complete files, there's way too many changes. I'd also like to know what you've done and why to DirectSound. I don't see why you want to use WaitForSingleObject as well as a manual event loop. I don't generally enable exceptions because it slows the code down and is only used by JMA. My local builds do not include ZIP+JMA support, so there's no reason to slow down the emulator. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Aug 29, 2006 8:47 am Post subject: | |||||
|
|
|||||
I'm disappointed.. it sounds like adding more special chips will exhibit the same problems? (If true, well I guess there's a reason to use other SNES emus of course )
Oh, you're gonna make the ROM whores cry. "OMG, WHERZ MY 7Z/RAR/INSERT SILLY FORMAT HERE SUPPORT"_________________ FF4 research never ends for me. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 29, 2006 9:12 am Post subject: | |||||
|
|
|||||
Precisely. You can add all the timing hacks you want to them.
Yeah, not sure if I want to add kode54's patches for RAR/7z support or not. I personally can't stand the formats. |
|||||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Aug 29, 2006 9:49 am Post subject: | |
|
|
|
| Byuu, why can't you emulate the timing properly ? Because it would make bsnes much slower, or because you lack some information/data ? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 29, 2006 9:52 am Post subject: | |||||||||
|
|
|||||||||
I lack information, and more importantly hardware to test this on. Furthermore, the DSP-1 emulation core is written in such a way as to make this very complex to add. I'm more interested in emulating the base SNES than the DSP-1, sorry. This is why I didn't want to add any special chips period, I do it as a favor to everyone else who use the emulator. I make zero claims as to the accuracy of special chip code.
DSP-1 timing related. I am not researching this unless someone donates adequate hardware to test DSP-1 on to me.
Both fixed by setting render_line position to HC=192 from HC=128. These games are basically writing to the display well after hblank ends. Expect these bugs to happen on real hardware, but be more like partial lines. You wouldn't notice Taz-Mania because the road doesn't often (ever?) touch the left-hand side of the screen. Requires dot accurate PPU emulation. Otherwise, we're just playing games moving this render position back and forth, causing different bugs to appear each time. The scanline renderer itself is basically a huge speed hack, end of story. If you want to keep track of these bugs, or keep them in a separate list, or not; that's fine by me. I'm not going to research them until I have my dot renderer, sorry. In the mean time, I'll leave render_line at HC=192 like v0.016, since it seems more compatible.
Alright, I'll look into it. |
|||||||||
Rookie
Joined: 03 Mar 2006
Posts: 14
| Posted: Tue Aug 29, 2006 10:36 am Post subject: | |
|
|
|
| Sound works for me with v0.013, and I'm fairly certain v0.014 & 5 as well, but not the WIP versions. I remember having this problem (sound not working at all) with some WIP versions until the final was released, where it worked fine. This is not the case with 0.017... where I don't get sound output at all. Yes, mute sound is not checked. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 29, 2006 10:43 am Post subject: | |
|
|
|
| I
don't have your sound card to test with. It could be any number of
problems, but my DSound driver uses standard DirectSound API calls,
exactly as defined in the DirectSound SDK sample source code. If it does not work for you, I am unfortunately unable to assist, sorry. Nothing has changed in src/ui/audio/dsound.cpp since the last release except for a call to Sleep(1) that keeps processor usage from hitting 100% when the emulator is running at full speed. Side note: Zan3 and Yuujin2 are not fixed by moving render_line position. Both are fixed by allowing VRAM writes outside of vblank, which isn't going to happen. I will have to look into this more. I can't see Yuujin2 on a copier, and I'm too apathetic to test Zan3. I'm guessing it's the fault of sCPU not having H/DMA sync timing (and using a rounded average sync delay). Mostly a complexity issue of adding that back in, I want the code for it to be readable unlike bCPU's code here. Still trying to think of a good way to do it. |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Aug 29, 2006 4:28 pm Post subject: | |||||||||||||
|
|
|||||||||||||
Is there any particular reason? It should work fine all the way down to Windows 98, and possibly Windows 95 with Internet Explorer installed.
I'll include a list in the future, but for now, you can search or grep the files for "diff -u". I only provide patches since I assume you would prefer a summary of the changes, rather than having to compare the files yourself, but whatever.
Or maybe you would prefer ZIP in ZIP, or .tar.something, since solid compression is better for text files.
Sure.
There's probably no reason for that, as it's not likely that the event setup will fail.
You can always just enable exceptions for the relevant source files, namely cart.cpp and the JMA, Rar, and 7-Zip readers, and disable them for everything else. Anyway, new binary, source, and patches uploaded. The only change is the addition of the original artwork, using the evil OLE loader. Use it, or don't. Edit: Woohoo, for the patches, tar.gz is only about 1KB larger than tar.bz2, and then non-solid ZIP is only 1KB larger than that, so ZIP it is. |
|||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 29, 2006 4:44 pm Post subject: | |
|
|
|
Ok, Winter Olympics... ... in bsnes v0.017, SNEeSe v0.853, and SNES9x v1.502. Line error at X=128-255, Y=128.  ... in ZSNES SVN + v1.42. Line errors at X=0-255, Y=127-128.  ... in Super Sleuth v1.04e. I do not see the black line error, but the screen glitches badly shortly after. --- In bsnes, the background image is made entirely from OAM OBJ priority 0. By disabling it, the entire background screen goes black so I cannot determine if determine if that layer is the source of the program. However, disabling OAM1-3+BG1-4 does not prevent the black line from appearing. So it's either a problem with OAM pri0 or with something like windowing or add/sub effects. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 29, 2006 5:32 pm Post subject: | |
|
|
|
| Byuu, should i still submit everything i find? You could check if they fall under bugs that will be fixed by the rewrite, or which ones need to be looked at seperately unless you have some way for me to discover which is which? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Aug 29, 2006 5:43 pm Post subject: | |
|
|
|
| Yes, thank you. We might as well categorize all of the scanline-render errors now. Though I won't be able to fix them properly until the PPU rewrite is finished. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Aug 29, 2006 6:30 pm Post subject: | |
|
|
|
| You're doing a good job, tetsuo. You've noticed some things I probably wouldn't have. It's definitely important to keep going with this bughunt. 3500 roms is a lot of games, and it will take some time, but whatever's left needs to be found. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Aug 29, 2006 7:30 pm Post subject: | |
|
|
|
| Okay
i will continue my bughunt, this are gonna slow down a little though
over the coming weeks, as i have finally got a place for myself. Going to move in there over the coming month, need to paint and stuff, but once there i will finally have my own little corner for research and testing (i do a lot of hardware repair on consoles too, Although snes are usually quite hopeless) |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 30, 2006 5:13 am Post subject: | |||
|
|
|||
kode54, I can't add your DirectSound code. It fails to work on my system here:
This fails and dsbNotify is null. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 30, 2006 5:58 am Post subject: | |
|
|
|
| Alright byuu, I hope you see this because it's really important. Remember how I reported that my soundcard was experiencing crackling in all latency settings higher than the most extreme of 48ms? Kode's .017 build with the directsound changes fixes this. I get no crackling on any setting. I have no idea what he did, but it is absolutely wonderful to have this fixed and I hope one of you can figure out why so it gets included. Thank you! | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed Aug 30, 2006 6:22 am Post subject: | |||||
|
|
|||||
Quick google comes up with this: http://www.gamedev.net/community/forums/topic.asp?topic_id=202998 This appears to be the same problem you are experiencing byuu (I could be wrong). _________________ FF4 research never ends for me. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 30, 2006 7:50 am Post subject: | |||
|
|
|||
His ring buffer seeking is also backwards, meaning the sound latency is 4-5 frames behind in his build. That's probably why it works better for you :/ On a similar note, I tried redoing some of the audio code myself while I wait for kode54 to determine what the problem with my notify event is. Check out wip2 and let me know how it sounds for you, please. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Aug 30, 2006 8:33 am Post subject: | |
|
|
|
| T Untested > Tri-Star Super 8 BIOS (NES-SNES Adapter).7z, Total Football.7z (beta), Tinhead.7z (beta), Tested > 167 roms Problems found: Taz-Mania (E).smc/Taz-Mania (U) [!].smc A green line that looks like the gras texture constantly passes over the road Zsnes looks OK Looks fine on hardware Top Gear 2 U/E/J Black lines appear in bridge Ok in Zsnes Tested the E version on hardware, a black line appears here too for about1/2 second a black line happens at the top of the bridge, but never in the bridge, tested several times, black line always shows in the exact same spot. Toy Story (U) [!].smc +U/E sometimes sound buzzes when the game is loading Happend several times, with different region versions Unable to test in hardware as NONE of the region version will go ingame on my snes Games not working due to missing hardware support: Taikyoku Igo - Idaten (J).smc Black screen, SA-1 Takemiya Masaki Kudan no Igo Taishou (J).smc Black screen, SA-1 Tengai Makyou Zero - Shounen Jump no Shou (J) [!].smc black screen, SPC7110 Tengai Makyou Zero (J) [!].smc black screen, SPC7110 Top Gear 3000 (E) [!].smc Top Gear 3000 (U) [!].smc Planet's Champ TG3000, The (J).smc Black screen, DSP 4 Does anyone know how to upgrade the bios of a Super Wildcard DX, and if the bios in the goodsnes set is actually "usable" and if not where i might be able to find the bios? I now hjave 2 games that dont use special chips that dont work, i hope the new bios will help. |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Wed Aug 30, 2006 9:01 am Post subject: | |||
|
|
|||
DirectSound interfaces prior to 8 require DSBCAPS_CTRLPOSITIONNOTIFY. Although I thought DSBCAPS_GETCURRENTPOSITION2 was sufficient as well, maybe it's better to use the other flag instead. Also, when using buffer position notification events, it's probably a good idea to force DSBCAPS_LOCSOFTWARE, as I've heard from another developer that buggy drivers have been known to trigger events for the wrong buffers when using hardware buffers. Maybe older Creative Sound Blaster Live! drivers? Probably best not to chance it, heh. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 30, 2006 9:09 am Post subject: | |||||
|
|
|||||
Damn, it had to be something like that didn't it Oh well. I appreciate the help, but wip2 still behaves the same as official.
|
|||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Wed Aug 30, 2006 12:16 pm Post subject: | |
|
|
|
| My
code also keeps a running write position and always writes new blocks
one frame ahead of the previously written block, regardless of the play
cursor. It only uses the play cursor to determine whether it should
wait before writing, in the event that other parts of the emulation
thread delay it past one frame, making the wait worse than not waiting. Not really an ideal buffering scheme, but it seems to work slightly better. Maybe I can get someone else to look at the code when they have free time and see if it could be improved even more? |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Wed Aug 30, 2006 6:01 pm Post subject: | |
|
|
|
Worked out a bug in our line caching engine and: Was right to begin with, just was not being displayed properly. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 30, 2006 8:36 pm Post subject: | |||
|
|
|||
Winter Olympics:
It changes OBSEL's OAM tiledata pointer during hblank at V=127. At this point, the OAM data for V=128 would already be cached by the real SNES PPU. Not so on emulators. Fixing the problem will require caching OAM objects one line before drawing them. This is something that's much better suited for a dot-based renderer, but can be done easily enough with a scanline-based renderer as well. I would be very impressed if ZSNES were doing this already, considering not even SNES9x does this. More probably, it works for similar reasons that Uniracers does. But if not, that's truly impressive work. |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Wed Aug 30, 2006 8:50 pm Post subject: | |
|
|
|
| I
noticed the sound in 0.017 crackles less if Triple Buffering is
ON,compared to 0.016 and the older 0.017 WIPs.Interesting.But I get a
big performance drop when I enable Triple Buffering and a Software
filter.With no filter,there's no difference between TB and no TB. I would like to be able to set the DirectSound latency to 20ms = the best value for Creative/E-MU cards and the default in many emulators. Anything higher or lower than this is no good by my experience. <20 = crackling,40ms = laggy. Testing this Kode54 build now. Last edited by kick on Wed Aug 30, 2006 9:45 pm; edited 1 time in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 30, 2006 8:54 pm Post subject: | |
|
|
|
| Interesting, this PPU rewrite is sounding more important by the day. Still, I hope you can fix this and possibly others with the scpu + scanline based. I'm beginning to find more regressions concering mid-screen horizontal line issues. Prince of Persia 2's title screen among them. tetsuo confirmed taz-mania on (E). Attack of the horizontal line bugs! | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Aug 30, 2006 9:11 pm Post subject: | |||
|
|
|||
Did you try these on wip2? Taz-Mania and Top Gear 2000 issues should be gone. I've moved the dot render position back to HC=192 until I can rewrite the PPU. Prince of Persia 2 should be the same as v0.016 now. Also, you can consider Winter Olympics as "fixed" now, if you like. I've moved OAM caching to Vn, and OAM rendering to Vn+1. I'll add this to my main source tree tonight. |
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Wed Aug 30, 2006 9:18 pm Post subject: | |
|
|
|
| It currently works by toggling the next line to be cached on writes to OBSEL. The next line can be cached setting the variable NextLineCache to 1. See regsw.inc in reg2101w. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Aug 30, 2006 10:45 pm Post subject: | |||
|
|
|||
Oh, excellent! I had not tested them. Consider them all removed. I suppose I should test to see if the screensaver gets suppressed tonight when I'm off. Never heard anything about that either. Another pleasant surprise? edit: nope edit2: May have found another bug tonight. Sink or Swim (U) is glitching up pretty badly in the levels. Just walk up and down the ladders for a bit, it'll happen. Happens in .016 as well. Super Sleuth seems to play the game fine. ZSNES gets a garbage screen and crashes to desktop. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 31, 2006 6:36 am Post subject: | |||
|
|
|||
|
Add F-1 Grand Prix to the list. I know what's wrong, but I cannot fix it. The game sets VTIME to 9 on VCOUNTER=9, which triggers an IRQ. This completely and utterly destroys my NMI / IRQ triggering methods. I've spent the last three hours trying to figure out how the fuck the SNES internally determines these triggers and can't come up with even a working theory. I can't fix this, at least not any time soon. Don't bug me about it or give me meaningless encouragement, please. The following five IRQ rules are now all verified on hardware, and all false in every version of bsnes:
I went ahead and fixed Winter Olympics locally, but that's the best I can do. EDIT: Setting DSBCAPS_CTRLPOSITIONNOTIFY works. But now I take a significant (~15%) speed hit even when speed throttling is turned off, by using the event notification code. EDIT2: Ok, made a little progress on interrupts, in exchange for a massive speed hit. Removed the need to have two separate IRQ/NMI trigger points, so now I can allow IRQs to be triggered "instantly" in a more correct fashion. But no luck trying to get it to actually do this without breaking my various IRQ test ROMs. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 31, 2006 11:35 am Post subject: | |
|
|
|
| is there any point to running those tests on pal hardware. | |
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Thu Aug 31, 2006 5:34 pm Post subject: | |||
|
|
|||
Earthworm
Jim 2 (Beta) has garbled sound during the intro and does not reach
in-game. Don't know if this game worked on real hardware, but it is in
NSRT's database.
_________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 31, 2006 6:03 pm Post subject: | |||||||
|
|
|||||||
This is the same bug as F-1 Grand Prix. The same hackish fix for F-1 fixes this game as well. I just need to keep thinking about it. Somehow, the real SNES keeps certain internal variables to know when an IRQ needs to trigger and when it already has. So far, nothing I try satisfies all known IRQ conditions we've discovered. The reason this is giving me so much trouble is because there are so many variables involved at one time. I can focus on any three or four at a time, but it's hard to visualize the "big picture" of how IRQs work, at least for me. At the moment, I'm trying to figure out if the SNES internally keeps its own "previous H/V counter positions" each time IRQ is tested, or if IRQ is tested every clock tick, or if the IRQ test is a direct comparison (eg trigger when VCOUNTER==VTIME && HCOUNTER == HTIME), or within a range (eg trigger when HCOUNTER >= HTIME && !TRIGGERED), or something else.
Nope :/
We haven't really been focusing on betas. A lot of them really are bugged (eg KI Beta). If someone wants to verify on hardware though, I suppose I could take a look at it. |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Aug 31, 2006 6:15 pm Post subject: | |
|
|
|
| i will try to verify asap, but i agree that testing beta's is not a good idea at this time. | |
New Member
Joined: 31 Aug 2006
Posts: 4
| Posted: Thu Aug 31, 2006 6:59 pm Post subject: | |
|
|
|
| I have tested the EJ2 Betas: The normal beta and an alternative beta, The alternative beta works the normal not, so i guess the dump is faulty. Same goes for zsnes (latest cvs). |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Aug 31, 2006 7:40 pm Post subject: | |||
|
|
|||
Tested on real hardware? Can you post the CRC32 for each? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Thu Aug 31, 2006 7:54 pm Post subject: | |
|
|
|
| I
tested kode54's bsnes 017 build,and I get severe sound crackling and
popping problems.With byuu's official 017 release and the 017 WIP
builds,there's no problem (sound is smooth). Also,I noticed a *very slight* performance increase with the kode54 build. OK,kode54's build supports archives,but I still can't drag and drop a .ZIP file from 7-zip's file manager window and drop it in the bsnes window to open it. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 31, 2006 8:16 pm Post subject: | |
|
|
|
| I'm
not ignoring requests for user interface enhancements (disable screen
saver, drag and drop, etc), but I'm too busy with core emulation issues
to work on the user interface at this time. I consider the IRQ bug very serious at the moment. The sound crackling in kode54's build is because he is setting readbuffer to prevbuffer. This *is* going backwards (playing that sample block requires looping over the entire ring buffer - 1 block). I get the same crackling (especially when enabling speed throttling where it was off before) with my method when I set readbuffer to prevbuffer instead of readbuffer + 1 (which is really +2, since the next buffer will have started by this point). However, the whole point of the modular AVI abstraction was to allow multiple interfaces. If kode54's soundcode works better for some (FitzRoy), then I will include it as an alternative. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Aug 31, 2006 9:06 pm Post subject: | |
|
|
|
| I had no idea kode's build was having adverse effects on other people's cards. If that's the case, there's no reason to add something just for me. 48ms works fine. Just strange, because if it was my card, you would think all my other programs would crackle on higher settings, too, but they don't. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Aug 31, 2006 11:33 pm Post subject: | |
|
|
|
| With TRAC's help, I think I have the new IRQ stuff (mostly) working. At least, it passes both of my extremely rigorous IRQ test ROMs, as well as runs F-1 Grand Prix and Sink or Swim properly. Now I just need to make it use the fast clock increment code again, which is sure to be a pain, and we should be good. |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Fri Sep 01, 2006 2:58 am Post subject: | |
|
|
|
| TRAC is awesome.....Enough said. |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Fri Sep 01, 2006 5:10 pm Post subject: | |
|
|
|
| Could you go over what the correct IRQ semantics are then? Or is there a thread somewhere else where you and TRAC figured it out? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 01, 2006 6:18 pm Post subject: | |
|
|
|
| To be honest, we're still not 100% on it. I need to run a lot more tests to try and determine a few things. As per my webpage, I only have access to the internet at work, so I should have plenty of time to work on this (read: nothing else to do x.x) ... I'll try and write up a document detailing all currently known knowledge of NMI and IRQ. But I warn you now: it's very, very complex and hard to implement properly :/ My test ROMs mostly test the most extreme edge cases possible and thus require perfect CPU core timing to work, so my test ROMs will be of little help to other emulator authors, unfortunately. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Sep 01, 2006 7:10 pm Post subject: | |
|
|
|
| actually
thats exactly what arbee needs, as he is going to use the info for
mame/mess, and their target is accurately documented emulation of the
hardware. Apart from that i also thing that it would be a great idea if you could write the things you have discovered in documents, and host that with your testroms in a central place they probably wont be accessed a lot, so you probably could take the bandwith hit from those files. But its up to you ofcourse PS I'm putting all tests on hold untill you fix this timing thing, as i dont want to provide any useless bugreports at this point, please upload a wip as soon as youve got this fixed so i can continue testen, cheers! EDIT: Arbee, ill be willing to do these tests too for Snes emulation in mess once you think the time is ready for it, hopefully we will be able to provide a list of gamebugs not caused by emulation to prevent fixing of games that shouldnt be fixed (would be great to have fixed sets like haze suggests) |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Fri Sep 01, 2006 9:38 pm Post subject: | |
|
|
|
| Actually
I'm not aiming for 100% accuracy first, but at the same time I'd like
to know as much as possible about the proper operation ahead of time so
I have an idea what things are critical and what can be approximated at
first (and replaced later with a more accurate version). My plan is to
finish up the new raster timing system and then rework the 65816 for
cycle-by-cycle operation (and along the way fix things like the
sei/cli/sei follies - amusingly some versions of Asteroids in the
arcade were recently discovered to rely on the same pipelining behavior
in the original 6502!) Those 2 things are fundamental to correct timing. I've got some related questions if byuu or pagefault or anyone else can answer them: - What HCNT does HDMA start on? - When does drawing occur relative to HCNT? - How many master clock cycles do (H)DMA transfers take? - What's this OAM caching I've seen reference to? And yes, a list of known test ROMs and what they test would be nice too. I've got a nice document on the inner workings of the famous Nintendo electronics test, but anything else would be good too. Feel free to PM me here or on any other board I'm on if you'd rather not clog this thread |
|
New Member
Joined: 01 Feb 2006
Posts: 2
| Posted: Fri Sep 01, 2006 11:24 pm Post subject: | |||
|
|
|||
I think one of the best references are anomie's docs on Romhacking BTW, where i can find this document about Nintendo electronics test? |
|||
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Sat Sep 02, 2006 3:03 am Post subject: | |
|
|
|
| That's
good stuff! I think Anomie's various documents actually cover most of
the questions I just posted (except the OAM caching). The electronics test doc was sent to me privately and isn't really formatted for distribution, but I can maybe throw together a decent summary. |
|
New Member
Joined: 01 Feb 2006
Posts: 2
| Posted: Sat Sep 02, 2006 9:40 am Post subject: | |||
|
|
|||
ok, thanks! |
|||
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Mon Sep 04, 2006 1:51 am Post subject: | |
|
|
|
| Ok,
it's pretty easy, but you need something with a debugger to really
understand what's going on. Basically each test it does as part of the
electronics test has a status byte at 7E/0060-7E/0075 or so. Once the
test completes you can check that RAM area to see what passed/failed.
If a test passed, it's byte is 0xff, otherwise it's 0x00. The tests are: 0x60 = test WRAM 0x61 = tests NMI, also insures 00/1000-1005 and 20/1000-1005 are mirrors 0x62 = tests read/write from 7e/2000-7f/ffff 0x63 = test 2180-2183 read/write WRAM 0x64/0x65 - test VRAM even and odd locations to make sure they retain data 0x66 = test DMA registers read/write 0x67 = test read/write OAM 0x68 = test read/write palette RAM 0x69 = test hardware multiply at 4202-4203 0x6a = test hardware multiply at 211b-211c 0x6b = test hardware divide at 4204-4206 0x6c = test DMA to 2118-2119 + DMA from 2139-213a 0x6d = test HCNT and VCNT. --- subtest 1: wait until immediately after VBlank. Latch the counters. VCNT must be 0, HCNT must be between 0x10 and 0x40. --- subtest 2: wait until immediately after VBlank, then wait until HBlank starts. Latch the counters. VCNT must be 0, HCNT must be between 0x110 and 0x140. --- subtest 3: wait until the start of VBlank and latch the counters. VCNT must be 0xe1 and HCNT must be between 0x10 and 0x40. 0x6e = sets HIRQs and VIRQs at various screen positions and makes sure they fire appropriately 0x6f = test DMA from VRAM to WRAM 0x70 = same as subtest 3 of 0x6d, but tests both 240-line and 224-line modes. In 240-line VCNT must be 0xf0 at the start of VBlank rather than 0xe1. 0x71 = Turn on interlace mode and make sure the even/odd field bit (I forget which register) toggles appropriately 0x72 = test bits 6 & 7 of 4212 (Vblank and Hblank status) against HCNT and VCNT 0x73 = test OAM range/time over flags 0x74 = apparently not used 0x75 = A few basic 65816 tests, if you don't pass this you have a real problem Credit goes to TRAC and anomie for these. Any errors are likely my fault though. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Sep 04, 2006 8:25 pm Post subject: | |
|
|
|
| Question: Where along the line is aspect ratio correction applied to the video image? Is it before or after software filters? Before or after resolution multiplication? Bug? Am I failing to see an option? A while back, you removed the default windowed/fullscreen profile selections. In v0.017, the default profile on first run is Profile 3. Then, using F11 to switch to fullscreen, the fullscreen profile appears to be Profile 6. Then, using F11 again or pressing ESC to leave fullscreen, the active profile is set to 1. Very inconsistent. It seems like there is still default windowed/fullscreen profiles, but now it's impossible to change them. Feature Requests: In my opinion, Alt+Enter is a much more common key combination than F11 for entering and leaving full screen. (F11 is used to enter/leave "fullscreen" modes of Internet Explorer and Firefox; anything else?) The ESC button has inconsistent behavior. When in windowed mode, it shows or hides the menu bar. In fullscreen, it is used to leave fullscreen. I think that ESC should not be used to exit fullscreen, but rather only one key combination be used to enter and exit fullscreen (F11 or Alt+Enter). Additionally, ESC can be used in fullscreen to show/hide a menu if/when you figure out how to draw a menu in fullscreen. It would be nice if Ctrl+O was mapped to Load ROM and F12 was mapped to Unload ROM (consistent with Project 64). ESC and F11 need menu items showing and performing their function, and showing the key combination. Ctrl+1 through Ctrl+8 need to be shown next to the Video Profile menu items. The more information about the functions of your emulator that you present to your users in the emulator itself, the fewer dumb questions you will get, and the less documentation you will have to write. The underlined letter of particular menu items (used to select that menu item while viewing the menu) is the same for multiple items on the same menu. Examples: Settings Menu. Show FPS and Speed Regulation. Under the Speed Regulation menu, two items using are S and two items are using F. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Sep 04, 2006 11:00 pm Post subject: | |||
|
|
|||
Dreadfully confusing, isn't it? It took me 15 minutes of testing to figure out the behavior of profiles. If I had it my way, there would be only 2 profiles to switch between, one for windowed and one for full screen, and I would call them "Windowed" and "Full Screen." Having 8 is a problem, and having the emu start on "Profile 3" is a problem. Other emulators don't have profiles and I never see anyone request them. It's just too confusing and 99% of users don't need them. But this and many of your requests are in the territory of author vs. user. I only disagree with the underlined letters, though. This is ugly and the lists are short enough to use the up and down arrow keys (or a mouse for god's sake). |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Mon Sep 04, 2006 11:12 pm Post subject: | |
|
|
|
| I need only 4 profiles: 2 for PAL,2 for NTSC (fullscreen and windowed). I can also use it with only 2 profiles - in that case,there would be one for windowed and one for fullscreen if I set the mode to PAL in both (240 scanlines visible) I just wish the black bar/area at the bottom (the difference between 224 and 240 lines) to shift upwards,so I get even "borders" at the top and bottom.I find it better-looking than having a big "chunk" at the bottom. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Sep 04, 2006 11:41 pm Post subject: | |
|
|
|
| I
like the "video standard" option rather than adding more profiles and
taking away the simplicty of the 1/2 switch. I doubt many people switch
regions enough to consider this an inconvenience. And that chunk you speak of only appears when you play ntsc games on pal mode. I'd think you'd want to switch modes, then you have no bars to worry about. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Sep 05, 2006 12:13 am Post subject: | |
|
|
|
| Since even some NTSC games *do* use 240 lines (overscan),I always keep the video standard setting to PAL. Either a "smart switch" to enable 240 lines for only those ROMs which use overscan,or a shift downwards of the viewable 224 lines to get a "letterboxed" kind of display . |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 05, 2006 12:45 am Post subject: | |||
|
|
|||
|
I
remember discussions of this, and I think an auto switcher like zsnes
would've created more problems than it solved. Also, I think I would
find two smaller black bars between an image more distracting than a
large one at the bottom. And if I think that way, others do as well. So
count out this behavior as default. Lastly, I don't think this
preference is worthy of adding a whole new option to the config. So I
don't really have an answer for you. July 15:
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 05, 2006 1:33 am Post subject: | |
|
|
|
| Hm, ok. I will relabel profile 1 to windowed, and profile 2 to fullscreen. Ctrl+(1-5) will switch multipliers, Ctrl+A will toggle the "fix aspect ratio" option. The changes will only apply to the currently active mode. I'm happy with the behavior of ESC, and I do not know how to capture the Alt+Enter key combination in Windows. Alt does not get returned by my key capture methods, because it goes to the menubar. Ctrl does not have this problem. Windows sends a special message when Alt is pressed, but then checking the status of enter at that point does not work. I'm not interested in researching the matter further. Likewise with the menu options showing their respective key shortcuts. Don't know how to do it, not concerned enough to research the matter further. Two labels using the same key? Ok, press 's' once to go to the first option, press 's' twice to go to the second. It seems smarter than making "slowest" use S and "slower" use L. Same for fast and "F / A". I'll use F for Show FPS, though. Thanks. Overscan centering... is a problem. It's possible to toggle overscan between 224 and 239, leading to any resolution from 224 to 239. It's also possible to toggle it frequently, making the screen image jump up and down. I might add 239-centering later, but for now the images stay like they are. I will add some options for NTSC vs PAL refresh rates and reset the modes when a ROM is loaded, so you can define 50/60/100/120/whatever. I'll change video standard a little to be "Always NTSC, always PAL, autodetect". F12 is way too close to F11, and that's one damn annoying key mistake to make. Ctrl+O... maybe. I want to add an input editor for GUI shortcut keys. That will be there eventually. Good enough? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 05, 2006 2:46 am Post subject: | |
|
|
|
| Yes, but a few points regarding these: I am assuming you will remove full screen options from the profile named "Windowed." If yes, splendid. As it should be. I don't know how Alt+Enter came to be the standard among programs for going full screen. The F keys do seem like a better choice, one key press vs two (and what else are they there for?). In case it makes any difference, I've noticed that pSXEmulator behaves in this way: it won't go to the menu until you press AND release the ALT key. When you do a key combo, you're essentially hitting ENTER while ALT is held down. Simply pressing ALT in bsnes goes to the menu before it even gets released. Also, do you think it would be good to add a small section to the readme regarding these hotkeys? Users need to find out how to operate these somehow. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Sep 05, 2006 2:53 am Post subject: | |
|
|
|
| My
minor beef with the profiling system is simple... the cfg file doesn't
match up the way it is displayed. Profile 1 in BSNES == Profile 0 in
the cfg file. This can appear as nonintuitive/confusing. Personally, I'd only use one profile.. maybe two if I felt like it. 4 is nice if you really bother to use NTSC/PAL... _________________ FF4 research never ends for me. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 05, 2006 6:44 pm Post subject: | |
|
|
|
| I agree that should be changed. And I think at least two profiles are needed to separate windowed and full screen preferences. There was also some kind of invisible window bug on returning to the same profile from full screen, which wouldn't happen with two. Having two also eliminates the problem of switching from 3 to 6, and having it go back to 1 instead of 3. EDIT: All "A" (J) games tested. Core emulation problems found: 0. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 06, 2006 3:42 pm Post subject: | |
|
|
|
| Ok, there are now two profiles: Windowed and Fullscreen. And for Deathlike's sake, the config file entries are "profile_win" and "profile_full". I'll work on hiding the fullscreen options rather than just disabling them, as well as adding an "autodetect" option to the video standard list later. Also, multiplier now only shows 1x-5x. If you need to, you can edit the config file by hand to set 6x-8x. I figure most people won't be using resolutions > 1600x1200 and want to stretch the image that far with them. Corrected all of the & conflicts as well in the menu. And I even managed to get some work done on actual SNES emulation, imagine that :) Added a new counter system aimed for speed, it only runs when at least one counter is > 0. I used this to emulate both the IRQ delay after H/DMA, and a new one to SNES emulation, as far as I know: hardware delay for multiply and divide operations. Now, if you read from $4214-$4217 before the multiply or divide is given time to complete, it does not return the correct result. Unfortunately, I don't know what it should return (probably some hybrid partial calculation or something, but hopefully just the last completed mul/div result -- will test later), so it just returns 0x00, but it's at least enough to cause errors when democoders / romhackers try using them without waiting like they should. No change in any commercial games that I'm aware of. Still trying to get the new IRQ code working without having to step clock-by-clock... a real losing battle, but I'll keep trying as always. |
|
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Wed Sep 06, 2006 6:38 pm Post subject: | |
|
|
|
| hi i am trying to wirte a snes emu too. my motivation is to understand how it works. currently I am trying to understand how NMI/IRQ timing is working. bsnes helps me a lot, Thank you byuu for your work. But I am convinced, it is more interrest than work at least for me. I have a short fix for Sink or swim and F1 I have tried the fix in bsnes 0.015 and it works insert in update_irq() function after the line hpos = (hpos != 0) ? ((hpos << 2) + 14) : 10; following: if ((time.v==vpos) && (exception)) hpos = 1360; exception is a bool parameter : update_irq(bool exception) exception is allways false, except for the two mmio functions VTIMEL and VTIMEH. After updating virq_pos call update_irq(true); Byuu do you know which exact hpos the IRQ fire, if there is no hpos set and Vtime is set during the current scanline. My assumption is the end of the scanline or beginning of the next. It works with any hpos at the end of the scanline. |
|
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Thu Sep 07, 2006 4:39 am Post subject: | |
|
|
|
| byuu, are you plainning on putting a mouse support? How about cheats saving to .cht? Just right after you getting the fixes done first. We are not in a hurry. Time your time on everything. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Sep 07, 2006 5:04 am Post subject: | |
|
|
|
| T-Doomdays: http://board.zsnes.com/phpBB2/viewtopic.php?p=125859&highlight=mouse#125859 _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 07, 2006 3:18 pm Post subject: | |||||||
|
|
|||||||
|
Ok,
I was able to get NMI/IRQ working with only a single interrupt poll
during each add_clocks() call, but the code was fairly nasty. And then
there was a new problem: how do you set the IRQ trigger delay when your
IRQ test is (hclock+cycles) <= irq_trigger_pos? Since
(hclock+cycles) can be anything, that makes triggering the IRQ even
more nasty. So, I'm going to stick with alwaysinline functions and clock stepping for the forseeable future. The code is just way easier to read and maintain. I'd rather get this emulated right, and then worry about speedup tricks. 112fps instead of 127fps, IIRC. That also includes the overhead for the new hardware math delay counter.
Uhh.... thanks?
It fires four clocks earlier than a V+HIRQ at HPOS=0.
Already there, though I don't support ZSNES/SNES9x binary cht files, mine are stored in plaintext and allow for much longer descriptions. The two formats will probably conflict with each other as I doubt any emulator is doing any integrity checking on the files before attempting to load / save them. |
|||||||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Thu Sep 07, 2006 6:58 pm Post subject: | |
|
|
|
| I
would talk about a few things I have noticed till my current state of
the emu. Sorry english isn't my home language, hopefully it's
understandable I have build the Cpu opcodes with the official document of Western Desgin Center mainly for the adressing modes. For Cpu logic I have used the book 65816/65802 Assembly Programming Language from 1986. It seems there are few mistakes in this book or the 65c816 in the Snes is a little bit modified. For example the mvn and mvp opcodes always uses a 16 bit accumulator. The book considers the m flag in status register for this op. Byuu it seems you don't handle the break bit right in emulation mode. tell me if I am wrong. The brk opcode do's following in cycle 6: if (mode_e) reg_p.b = 1; write_stack(reg_p); if (mode_e) reg_p.b = 0; the break bit is needed in emulation mode, because the brk vector is the same like the irq. So with the code below for example it is possible to check after the irq or brk, if it was a hardware or software interrupt: PLA PHA AND #$10 BNE was_brk I have coded the opcodes, which can have an additional cycle in native mode, depending of x bit in status register like this: if(mode_e || (!mode_e && reg_p.x)) so mode_e means that x bit is always 1. So I have the x-bit in emulation mode free for the b-bit. The b-bit will be only true temporally in the sixth cycle of brk opcode. It is not needed to set the break bit 0 during a hardware interrupt, because it is 0 already. In the xce opcode I use this: if(mode_e) {reg_p.m = 1; reg_p.b = 0; reg_x.h = 0x00; reg_y.h = 0x00; reg_s.h = 0x01;} else reg_p.x = 1; in opcodes, which read p_reg from stack I use this code: if(mode_e) {reg_p.m = 1; reg_p.b = 0;} if(mode_e || (!mode_e && reg_p.x)) { reg_x.h = 0x00; reg_y.h = 0x00; } reg_p.b and reg_p.x uses the same memory via union. Last edited by PiCiJi on Thu Sep 07, 2006 7:07 pm; edited 2 times in total |
|
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Thu Sep 07, 2006 7:06 pm Post subject: | |
|
|
|
| From byuu: "I'm not adding anything requiring a mouse anytime soon." lol Thanks. I will stick on the zsnes for now until bsnes get a mouse support. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 07, 2006 7:52 pm Post subject: | |||||
|
|
|||||
Nope. I'd like to fix this, but I have more important issues with IRQs and such to work on at the moment. Started fixing the first half of it (checking e rather than just m/x for 16-bit opcodes), but it's still a work in progress.
Sounds good to me. |
|||||
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Thu Sep 07, 2006 8:03 pm Post subject: | |
|
|
|
| It doesn't matter if BRK is handled properly in a SNES-only emulator. BRK in a SNES game is pretty much always due to some emulation failure, so you want to trap it. (It's possible some clever game uses it - some Apple IIgs software trapped WDM and used it as a syscall - but I doubt it). | |
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Thu Sep 07, 2006 8:28 pm Post subject: | |
|
|
|
| Yeah my old book is from the Apple 2gs time. An other issue in the book is: An reset terminates the wait state, save the program bank register (if in native mode), the program counter and processor status register onto the stack and transfers programm control to the appropriate interrupt-handling routine. Hmm I thought only a nmi or irq save the program counter and processor status register? I wonder if a snes game consider this? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 08, 2006 12:10 am Post subject: | |
|
|
|
| Going
through the B's, I found a new bug. Using .017.04, Battle Blaze (J)'s
title screen is having "horizontal line issues". This might have been
introduced with the Taz-Mania and Top Gear 2 fix, as it does not happen
in .017 official. Possible to fix without breaking the others again? No other problems were found in that letter. |
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Fri Sep 08, 2006 6:03 am Post subject: | |||||||||
|
|
|||||||||
The X/B and M/1 flags are already correct for emulation mode. This is the table from the GTE 65816 document:
During Reset the cpu tries to save PC and P to the stack, but the R/W signal is always set high during reset. This causes the cpu to read from the stack instead of writing to it. Also, the PB does not get read because E = 1 at the beginning of reset. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 08, 2006 6:34 am Post subject: | |||||||
|
|
|||||||
I'll make the HCLOCK position to render the line a config file option for the next release. If you want to keep a list of games that have issues and their acceptable HCLOCK ranges, we could choose the best general purpose one; but I don't want to keep hacking around this issue personally. I need to focus on a dot based renderer and get away from this hackery instead, but now the CPU interrupt stuff is requiring all of my immediate attention :/
I don't do anything with M/1 being forced to 1 in emulation mode, nor do I push P&~0x10 when in emulation mode when calling hardware interrupts, if I recall correctly. Maybe I do... I'll look into it "shortly".
Odd, my tests seemed to indicate that PC+P was pushed onto the stack when resetting. I had some demo a few years ago that let you scroll around memory and I could've sworn the program counter at reset was showing up after each reset. I'll have to retest it, that was quite possibly the oldest test I ever wrote, and was probably full of bugs. |
|||||||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Fri Sep 08, 2006 7:47 am Post subject: | |
|
|
|
| That means the Snes sets x (break) bit by switching in emulation mode to one? But why says my book that the brk op writes a 1 for the break bit on the stack and resets afterwards the break bit to 0? Is the GTE version different the WDC version of the CPU? | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Fri Sep 08, 2006 10:55 am Post subject: | |||||
|
|
|||||
Just do:
_________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Fri Sep 08, 2006 12:08 pm Post subject: | |||||||
|
|
|||||||
You're right about the M/X flags. I just assumed that the code was correct, but it is not. The interrupt code in sCPU::op_irq looks like it is correct.
In both the GTE and WDC docs it says that "R/W remains in the high state during Reset" and "RWB remains in the high state during the stack address cycles". I have a question about the TSC opcode: Are the N/Z flags set based on the full 16-bit value in emulation mode, or just the low 8-bits like bsnes does? I think it should be 16-bits like TDC.
Both the GTE and WDC docs state that the M/X flags are always high during emulation mode and cannot be changed. During an emulation mode hardware interrupt (IRQ, NMI, ABORT, RESET), the Break bit / X flag is set to zero on the stack only. The value in the P reg is not changed. When the interrupt ends with an RTI, the cpu will load the P reg from the stack. If the cpu is still in emulation mode, then the M/X flags will be forced back to 1. |
|||||||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Fri Sep 08, 2006 12:51 pm Post subject: | |||||
|
|
|||||
It seems you are right, N/Z is based on 16 bit value in native and emulation mode. At least my book says it.
Yeah it`s the same, but when the b bit is always true in emulation mode, then there is no need for this anymore. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 08, 2006 5:37 pm Post subject: | |||
|
|
|||
Sounds good. I'm wondering if there is a magic number that will avoid this issue in all games under a scanline based renderer. .016, for example, has no issues with taz-mania or battle blaze. Odd. EDIT: All "C" (J) games tested: 1 bug found. Circuit USA (J)'s title screen has missing gfx. Occurs in all .017 versions, but not in .016. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 10, 2006 4:31 am Post subject: | |
|
|
|
| All
"D" and "E" (J) games tested. A couple of small problems that do not
happen in zsnes or super sleuth, but will probably need to be verified
on hardware unless you suspect them to be more obvious than I do. Dokapon 3-2-1 - Arashi wo Yobu Yuutou (J) - after title screen, the leftmost vertical line has a transparent effect that looks out of place Doraemon 3 - Nobita to Toki no Hougyoku (J) - during intro, as soon as text box pops up, the leftmost vertical line becomes black Both occur in all versions of bsnes. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Sep 10, 2006 8:00 am Post subject: | |
|
|
|
| I can probably test those on monday. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 10, 2006 11:23 pm Post subject: | |||
|
|
|||
|
Yeah, and you'll definitely need a video-input card to see the left edge. Ooo, an update:
I also noticed your website changes. Got the border... very nice. Only thing I don't like is the 2px sides. All "F" (J) games tested. Problems found: 0 |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Sep 11, 2006 12:11 am Post subject: | |
|
|
|
| If there's a new icon, I'd appreciate a 32x32 PNG of it, so I can update NF. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 11, 2006 5:08 am Post subject: | |||
|
|
|||
Why's that? I like them. Gives it a nice shadowed effect. Need a good background image instead of the solid light blue. Stuck your icon on the about screen in bsnes. Looks really good there. Not as nice as the old Bahamut Lagoon fanart image, but saves ~300kb of bandwidth per download. Thanks again. |
|||
New Member
Joined: 07 Dec 2005
Posts: 4
| Posted: Mon Sep 11, 2006 5:13 am Post subject: | |
|
|
|
| Umihara Kawase (J): Water in level 1 seems to flicker off every few seconds, especially when scrolling. Bug? Zelda ALttP (J): As the item window slides down, it makes a sound, but the sound effect is missing when it slides back up. Also, was the pause button taken out or am I missing something? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 11, 2006 5:56 am Post subject: | |||||||
|
|
|||||||
F11. DirectInput cannot detect pause/break key 90% of the time. You have to keep tapping it because for some reason DirectInput is reporting that you are constantly holding the button down and releasing it, unlike all the other keyboard shortcuts. In my WIPs, I've added a forced delay between pausing and unpausing, because I have no idea what the fuck's wrong with DirectInput. I might just say the hell with DirectInput for the keyboard and use it only for gamepad input.
Hmm, need someone to test that on hardware, please. If confirmed, try screwing with smp.ntsc_clock_rate and cpu.ntsc_clock_rate and see if any changes to those fix it. As it stands, the S-SMP is slightly underclocked compared to a real system, as I'm going by official specifications rather than observed realtime speed tests. Note that this only happens when you start a new game.
Couldn't tell you. Hopefully fixed with the recent IRQ changes? |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Sep 11, 2006 6:27 am Post subject: | |
|
|
|
| After reading your latest news update what hardware do you need? maybe we could hold somekind of fundraiser, or ppl could lend/donate stuff, or buy it from ebay or something and send it to you?? or do tests for you? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Sep 11, 2006 6:58 am Post subject: | |||||||||
|
|
|||||||||
pmed you.
Oh, I guess I didn't see it that way. Only 1px larger solid black didn't get me thinking "shadow." Though if you increase it, it would become even less convincing with the 90 degree corners.
No problem.
It is at least a step up from what you had before. I'm only unsatisfied
with the way it looks on the desktop. Without borders or shadows around
the colors, it looks washed out on lighter schemes. And believe me, I
added them, tried enclosures, and tinkered with it to worse results.
Icon art is really difficult, but I'm learning. Don't hesitate to
remove or relegate mine if something better gets made (the guy who did
snesgt's is great). Heck, I'm working on a console atm that seems to be
working better on the desktop.
first bug: I didn't notice anything unusual in this or the new wip. The water never disappears on me. It does flicker steadily and looks like a somewhat shitty implimentation, but not a bug. second: I don't think there is supposed to be a second sound effect. You may simply be remembering incorrectly. But hey, if I'm wrong, oatmeal cookies for everyone. EDIT: uh oh, Taz Mania (U) is hanging before title screen in the new wip. (E) remains okay. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 11, 2006 7:58 am Post subject: | |||||||
|
|
|||||||
Looks like a lousy effect to me. Happens on all emulators, so I'll wait for hardware verification before acknowledging this one.
Nah, it's there. If you try it during a resumed game you can hear it. Another good game to verify on hardware, as this also happens in ZSNES, SNEeSe, etc.
I didn't change anything timing related to the best of my knowledge. Maybe I should just blacklist shitty games and save myself a lot of headache. Last edited by byuu on Mon Sep 11, 2006 8:01 am; edited 1 time in total |
|||||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon Sep 11, 2006 7:58 am Post subject: | |
|
|
|
| Edit: Nevermind. Didn't realize secondary button functions were active. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 11, 2006 3:16 pm Post subject: | |||||||
|
|
|||||||
|
Yow >_< FitzRoy, have you seen your bsnes icon in 256-color mode? It's only displaying four colors for some reason. And of course since Windows is retarded and uses the 256 color icons in 16-bit mode (rather than downsampling the 24-bit ones), this is a problem... are you able to store copies of the 24-bit one, only downsampled to 256 colors, manually? Taz-Mania (U) problem found. It's the new hardware multiply / divide counters. The game is reading them too soon and expects non-zero results. Wonderful.
44 clocks between write to $4203 and read from $4216 ... Sigh, you might want to stick with wip4 for testing... or use both, whatever works.
Yeah, sorry. I realize it's a little complicated; but it's important to me to be able to switch between keyboard and joypad without having to remap all of my keys all the time. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Sep 11, 2006 5:49 pm Post subject: | |||||
|
|
|||||
Ehhh, crap. Why can't I ever do something right on the first try. I'll look into this tonight. I know my icon program can create these.
Alright. I'm glad you figured this out. Really don't want to retest those thousand or so games By the way, is there any advice you can give me on the hclock number? What was .016, for example? What is the range of acceptable values? I've already tried some numbers and haven't been able to fix the battle blaze issue. Is it possible this is just a separate regression that has nothing to do with the taz-mania and top gear 2 issues? |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 11, 2006 7:45 pm Post subject: | |||
|
|
|||
|
Have
a new idea for my GTK+ UI wrapper. I can use GtkFixed container to put
my widgets at specific x,y positions and gtk_set_size_request to
specify width,height. Then the magic touch to handle theme issues: a
scalar value for all x,y,width,height values. Starts as 1.0 for
pixel-precision, but can be anywhere from 0.1 to 10.0 to resize the
entire interface as needed to get things looking good. Now I just need to split off some base abstract classes from libwin32.h, simplify, create some generic cross-platform types, and then write the GTK+ wrapper, and the linux port should be able to mostly share the Windows GUI code in its entirity. Limitations would only be what GTK+ were missing. HCLOCK was 48*4 (192) for v0.016. Timing has changed between 016 and 017, obviously, so that may account for some fluctuation. Generally, I've found that ~128-256 works in most cases. The emulator will clip the value if its too high, so that it always renders before hblank begins (at 274*4, 1096).
Maybe, I don't know. |
|||
New Member
Joined: 07 Dec 2005
Posts: 4
| Posted: Mon Sep 11, 2006 8:22 pm Post subject: | |
|
|
|
| Tested Zelda on an SNES, guess I did remember wrong. No bug. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 12, 2006 7:59 am Post subject: | |
|
|
|
| All "G" (J) games tested. Problems found: 1 possible issue. Ganso Pachinko Ou (J) - Appears to show an error message. ZSNES as well. Super Sleuth plays the game okay. Special cart? NSRT lies? "Get in the Hole (J)" also has an error message, but I found out why. Here's why http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%203.jpg http://fantasyzoneparis.free.fr/images/Adol%20LasaBirdie%202.jpg Didn't even know that thing existed. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 12, 2006 9:02 am Post subject: | |||
|
|
|||
What did I tell you guys about Japanese text -_- 'QƒRƒ"ƒgƒ[ƒ‰'̃RƒlƒNƒ^'É'ÍA 'Ήžƒpƒ`ƒ"ƒRƒRƒ"ƒgƒ[ƒ‰ˆÈŠOAÚ'±'µ'È'¢'ʼnº'³'¢B Translation: "Dirty otaku, do not attempt to play games from The Land of the Rising Sun." Or perhaps it says something like: "Please do not connect a second controller other than the corresponding Pachinko controller." (My Japanese is rusty, but you get the idea). Hmm, lots of special new hardware turning up here, heh. We should catalogue this stuff. |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Sep 12, 2006 4:04 pm Post subject: | |||
|
|
|||
NSRT tells you it uses the Lasabirdie in both ports. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 12, 2006 5:41 pm Post subject: | |||||
|
|
|||||
Indeed, that's how I found out. :/ The images are just to show people what it is. Pachinko, on the other hand, has "gamepad" on both ports. And since I can't understand Japanese, I had to allow the possibility of another problem. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 12, 2006 6:19 pm Post subject: | |
|
|
|
| If you want to, try and find some pictures of the Pachinko controller, because I can't. The Japanese really have a hate-on for images on websites. | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Sep 12, 2006 6:29 pm Post subject: | |||||
|
|
|||||
I have no idea what you're talking about
And I have to remember to release another WIP one of these days... _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Sep 12, 2006 7:03 pm Post subject: | |||
|
|
|||
Byuu, I admire your goals of bit-perfectly emulating the SNES. Did you believe that this was a realistic goal at the outset? In my opinion, the goal of using software to emulate a physical object, a complex machine such as the SNES, is unrealistic. One thing that seems to guide you when programming bsnes is to make software that runs on the real thing also run (identically) in bsnes. Additionally, software that doesn't run on the real thing should not run in bsnes. I think that this could continue to be a good secondary goal for bsnes. Obviously, bit-perfectly emulating some parts of the SNES are going to be prohibitively time-consuming and require more processing power than most users have available. Is it possible to find a happy medium between fine-grained approximation and bit-perfect emulation? You're the only one holding yourself up to such high standards (of emulation). I don't think a single one of your users expects you to spend 4 months researching math operation delays, for the very reason you said (no results). Work smarter, not harder. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Tue Sep 12, 2006 7:38 pm Post subject: | |||
|
|
|||
is this it? http://cgi.ebay.com/SFC-SNES-PACHINKO-SLOT-CONTROLLER-RARE-NEW_W0QQitemZ8275056164QQihZ020QQcategoryZ3592QQssPageNameZWDVWQQrdZ1QQcmdZViewItem not to good of a pic though. BTW thanks for the great emulator!! |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 12, 2006 8:43 pm Post subject: | |||
|
|
|||
That it is. Good find.
Right on. The Super Nintendo is a game system. The original hardware was designed to entertain people with games. If there are attributes of the system that have no influence on any commercial game, why spend exorbitant amounts of time trying to emulate them? Achieving perfect game compatibility through accurate hardware emulation/implimentation is a reasonable and obtainable goal. Emulating all hardware behavior regardless of its effect on games or emulator performance is not. |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Sep 12, 2006 8:57 pm Post subject: | |
|
|
|
| ２コントローラのコネクタには、 対応パチンココントローラ以外、接続しないで下さい。 Hmmm...My translation is like this: " Do not connect anything else other than the supported Pachinko controller into the second controller port." (more accurate) When it comes to Kanji...my Japanese is never rusty. And,in the future,could you please use Unicode? BTW,the two profile system of 0.17 wip7 is a great improvement.Much easier to set up and more intuitive. Last edited by kick on Tue Sep 12, 2006 9:29 pm; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 12, 2006 9:19 pm Post subject: | |||||||
|
|
|||||||
Yes, it is! Thanks :) I would've never suspected eBay would have it, after not even finding the game itself on Yahoo! Japan Auctions... go figure. Too bad they want $50 for it, it looks pretty simple to RE. No, don't anyone buy it. $50 is crazy for a gamepad, even if you're rich.
Much more? ... alright then, thanks.
Nope :P |
|||||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Sep 12, 2006 9:28 pm Post subject: | |
|
|
|
|
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 12, 2006 9:29 pm Post subject: | |||||
|
|
|||||
I must post to agree. Recent tangents kind of buried this great concession from byuu. I love always knowing what "profile" I'm on, the ease of initial setup, as well as having designated names and options for both modes. woot!
Pff. That's actually pretty reasonable for as rare as it is. You just hate charity. |
|||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Tue Sep 12, 2006 9:44 pm Post subject: | |
|
|
|
| Can I get the link to the latest wip? I tried guessing the link from previous wips, but that didnt work. Thanks! | |
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Sep 12, 2006 9:49 pm Post subject: | |||
|
|
|||
Yeah... And being a collector of NeoGeo and other arcade games, $50 really seems like nothing for some apparently rare hardware. If it's for a good cause, I don't mind. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 12, 2006 9:58 pm Post subject: | |
|
|
|
| I'm
serious, though. He wouldn't even let me lend him something I already
owned. And I'm not buying that thing anyway, so if he changes his mind,
it's up to you. Fuck pachinko when I can buy something I care about. |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Sep 12, 2006 10:29 pm Post subject: | |
|
|
|
| Heh, if byuu is that uncomfortable with donations, he shouldn't see them as charity, as everyone will benefit from them in the long term, through the improvements of his emulator... | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 12, 2006 10:51 pm Post subject: | |
|
|
|
| For one, it's a Pachinko controller. That works with one lousy Japanese game to our knowledge. Two, it's money. I don't like money that isn't mine going into my projects. Three, it's Pachinko. Even if I get the hardware, I wouldn't much enjoy figuring it out. Although admittedly, it would be very easy to do. Four, if someone really wants to waste their money, then I suppose I could do it. I would demand the sender receive the hardware back when I'm finished, and not bug me about progress on it, though. And don't even ask about the golf controller or MIDI keyboard. I'm not touching those with a 10ft pole. As for the S/PDIF SNES... I'm learning about all of this resistor, capacitor, transistor, oscillator, voltage + current regulator, watts, joules, ergs, ohms, volts, coulombs, amperes, farads, anodes, cathodes, resistance, current, capacitance, force, impedance, elastence, etc etc etc etc crap now. I should be able to make my own in a few months, assuming I don't electrocute myself to death first :) Seriously, I'm most worried about switching polarity on these electrolytic capacitors by mistake and having them blow up in my face at the moment x.x And I still have no clue as to how the hell I'm going to pull off getting 100-pin surface mount IC such as the SPC7110 into a breadboard or something. There's no way any human mortal could solder wires onto all of those legs with no crosstalk between them. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Sep 12, 2006 11:05 pm Post subject: | |
|
|
|
| The golf controller isn't worth emulating,but I would LOVE to see that MIDI keyboard supported. And what about ASCII's 'Tsukuru' series of games that use the "Turbo File" memory cards,so you can save data in Ongaku Tsukuru Kanaderu for example,and load it into RPG Tsukuru 2 ? Or exchange between Sound Novel Tsukuru and Ongaku Tsukuru Kanaderu? I would love to see this implemented. No emulator has ever done this. It's interesting how only SNES9x actually runs the BS Zelda Kodai no Sekiban games,but none of them are playable.(controls don't respond) I would like to see an emulator that will support these 'series' to be playable at last. Also,about SuperFX emulation,SNES9x has great SuperFX support,but emulation is way too fast.On the other hand,ZSNES has the emulation running too slow.Emulating the SuperFX at correct speed still seems difficult to achieve. |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Sep 12, 2006 11:12 pm Post subject: | |||
|
|
|||
That doesn't sound bad, except I wouldn't want the thing back, I've got too much junk on my hands as is... |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 12, 2006 11:22 pm Post subject: | |
|
|
|
| My order of desire: 1. Core game fixes 2. Multitap support 3. Any new Special Chip 4. BS-X |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Tue Sep 12, 2006 11:24 pm Post subject: | |||
|
|
|||
In bsnes, achieving this in an accurate sense would probably take a real beefy processer and system for full speed emulation. Stifu, are you going to buy that Pachinko off eBay? It says it's $24.99 buy now here. Edit: Ahh, ok, $24.50 shipping is a little much for that thing. |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 13, 2006 1:18 am Post subject: | |
|
|
|
| Work smarter not harder? Seriously, been smoking Dilbert PHB much lately? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Sep 13, 2006 5:07 am Post subject: | |
|
|
|
| All "H" and "I" (J) games tested. Problems found: 1 possible. Okay, so what's the story on this one. Reports as normal type with gamepad/gamepad in NSRT: Honkaku Shougi Fuuunji Ryuuou (J) - hangs at "Virgin" logo. Happens in all emulators. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 13, 2006 6:26 am Post subject: | |||
|
|
|||
This game is a bit wierd. It doesn't like more than two controllers plugged in and is a bit finiky on timing, but I didn't have a problem running it in ZSNES. Screenshots: _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Wed Sep 13, 2006 8:10 am Post subject: | |||
|
|
|||
When I get byuu's final confirmation, about me not keeping the item and all. :p Also, it seems like the whole thing bothers him more than it pleases him... o_o |
|||
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Wed Sep 13, 2006 12:41 pm Post subject: | |||||
|
|
|||||
no problem mod edit: please don't post long URL's like that which invoke use of the horizonal scrollbar, either make the link a text-based hyperlink like above, or use www.tinyurl.com |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 13, 2006 1:33 pm Post subject: | |
|
|
|
| I just tested Honkaku Shougi Fuuunji Ryuuou in Snes9x and bsnes, works fine in both of them as well. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Wed Sep 13, 2006 3:14 pm Post subject: | |||||
|
|
|||||
Personally, I'd buy it and keep it even if byuu didn't wan't it.
|
|||||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Wed Sep 13, 2006 4:35 pm Post subject: | |||
|
|
|||
The thing is I'm not interested in that pad at all. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Sep 13, 2006 5:03 pm Post subject: | |||
|
|
|||
hhhwwhat? What am I doing wrong? I'm posting the md5 of my rom tonight after work. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 13, 2006 5:19 pm Post subject: | |||||
|
|
|||||
Exactly why you shouldn't buy it. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 13, 2006 7:06 pm Post subject: | |||||||
|
|
|||||||
Did you press A after waiting at the Virgin logo for 5 seconds?
_________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 14, 2006 12:34 am Post subject: | |||
|
|
|||
Alright, it works. What I was doing last night was mashing buttons trying to get it to go in. Apparently "A" in this game doesn't register if you're holding down another button, even if it's directional. WOW. I don't think I've ever seen that kind of behavior, let alone a game that requires a button press to get to the title screen. What a piece of shit game. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Sep 14, 2006 12:43 am Post subject: | |||||
|
|
|||||
It must've been in the manual or something. At least this pales in comparison to those people who can't seem to start FF3 for instance... _________________ FF4 research never ends for me. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Sep 14, 2006 2:36 am Post subject: | |||||
|
|
|||||
The game isn't that bad actually. I just wish I really knew how to play Shougi. It's too different from Chess, and nothing like Siami Shougi which seems to be a variation on Othello. I know how to play and enjoy Chess, Othello, and Siami Shougi, yet this looks like fun and I'm stumped what's with the peice promotion and stuff. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 14, 2006 4:17 am Post subject: | |
|
|
|
| Certainly
I'm not referring to the gameplay with that, because I don't know how
to play either. I'm just hating on it for tricking me. All "J" (J) games tested. 1 bug found. Jumbo Ozaki no Hole in One (J) - name screen gfx screws up badly. Does not occur in zsnes or sleuth. Happens in all bsnes versions. On the list it goes... |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 14, 2006 7:26 am Post subject: | |
|
|
|
| Worked on joypad input stuff. The core emulation now takes a device type and device id for each port (of two). So now you can set the device to 'none' or 'joypad', and then set device id to 'joypad 1', 'joypad 2', etc. Yes, this allows you to set both ports to the same joypad id. Makes for a fun game in 2-player fighters, even if left and right aren't mirrored for it to be a true 'shadow fight'. No, I won't stop this from happening. You could do this on hardware, too, if you wired one controller into both ports, and that's good enough for me. Eventually, if I ever get around to adding the MP5 (I've no plans to add it), it will just use input settings for 'joypad 2' - 'joypad 5/6'. Or maybe 1-5/6-10. I don't know yet. The input configuration page is kind of busted right now, but things work on the emulation settings page, and you can now get in-game with that shougi ROM. As a side note, I'm not going to be spending much (if any) time fixing bugs for a while. I'm pretty much intent on studying electronic circuits at the moment. Feel free to keep looking for them, though. It'd be cool if we ever get all games tested. Then we can create a much more accurate compatibility rate %, albeit only covering up to 5 minutes in-game. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 14, 2006 7:54 am Post subject: | |
|
|
|
| I fully intend on having all games tested by the end of the month. I'm also keeping a list of possible bugs so that I can verify them all when I get my tototek cart. Even though it's 5 minutes into each game, that still should give a very accurate projection. Intro, title, menus, and a few minutes of gameplay for every snes game covers a LOT of emulation. The chances of an unseen effect or a bug existing beyond all of that is very slim, but possible. In any case, when testing is done, that's it (thank god). The only way further issues can be found is from people who actually play and beat games for fun. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Sep 14, 2006 2:41 pm Post subject: | |||
|
|
|||
Which one are you getting? Doctor SF7? From what I've seen on that website, you can max out your SF7 with 128MB RAM and the DSP adapter. What's the advantage of having more memory in one of these things? Which games require it? And what is inside the DSP add-on? Just a DSP-1 chip? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 14, 2006 8:20 pm Post subject: | |
|
|
|
| I'm getting the tototek flash cart. SF7 is a third party product. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Sep 14, 2006 8:48 pm Post subject: | |
|
|
|
| Which one? Are the Tototek products functionally equivalent to the GDSF7? I can't really make sense of how the Tototek product works, what with all the broken English. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 14, 2006 11:09 pm Post subject: | |
|
|
|
| It's
a kit. Super-Flash 64m. You get a flasher that connects to your
computer via usb. You install the software on your computer to flash
and dump devices connected to the flasher. The flash cart goes on the
flashing device to be flashed. Once it's flashed, you remove it from
the flasher and put it in the snes like a normal cart. The T-Connector
is an option for playing DSP chip games. The CIC chip is for C4 chip
games. All "K" (J) games tested. 1 obvious problem found. Koushien 2 (J) - after playing for a while, music stops, then game hangs. Does not occur in zsnes. Occurs in all bsnes versions. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 14, 2006 11:36 pm Post subject: | |||
|
|
|||
Played for over five minutes with no problems. No idea what you're talking about. Very strange that you play the batter for both teams in this game. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 14, 2006 11:49 pm Post subject: | |||||
|
|
|||||
Errr, I wasn't batting for both teams. I just hit start 7 times. Can't read the options so I don't know what kind of game I picked. Maybe you chose a different one where it doesnt happen. This time the sounds went all screwy before dropping out :/ EDIT: weird, this time I went two innings before it happened. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 14, 2006 11:56 pm Post subject: | |
|
|
|
| Ah, I see. The batter was just switching sides. Could've sworn the uniform colors were reversed too. You have to play way the hell into it to crash it. Alright. Don't expect me to work much on this one even when I do get back to fixing bugs, since I don't have savestates. Jumbo Ozaki no Hole in One (J) - gfx messes up in name screen VRAM corruption at 0xa800+. Too busy learning to work on bsnes at the moment, though. Sorry. Interesting find, though. bsnes being the only actively-developed emulator with this bug. Damn, I started on bsnes with the goals of working on emulating and improving the classics. Zelda 3, Mario World, Super Metroid, Castlevania IV... instead, I'm tracking down shady coding problems in Jumbo Ozaki no Hole in One ;_; |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 15, 2006 12:02 am Post subject: | |||
|
|
|||
How dare you mention those four travesties in the same sentence as the great Jumbo Ozaki no Hole in One!
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 15, 2006 12:07 am Post subject: | |
|
|
|
| You reply too fast :P Circuit USA looks to be the same problem as Jumbo no Bad Game in One. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 15, 2006 12:13 am Post subject: | |||
|
|
|||
Yeah I've got the forum refreshing as I hunt for bugs. Circuit USA is okay in .016, whereas the golf game still screws up in .016. Can they still be the same problem? |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Fri Sep 15, 2006 12:59 am Post subject: | |||
|
|
|||
If this occurs in ZSNES v1.36 but not in later versions, I might know what the problem is. Can you look into that? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 15, 2006 2:49 am Post subject: | |
|
|
|
| Sure. Doesn't occur in 1.36 or ipher's latest wip. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 15, 2006 6:28 am Post subject: | |||
|
|
|||
|
Ah, well at least Circuit USA will be easier to fix, then. EDIT: problem with sCPU.
Remember how I said I removed DMA bus sync delay? In the current bsnes, the write to $420b starts DMA immediately. But you see, this write happens before the $420c write. HDMA is still on before this write, though. So basically, HDMA kicks in, kills the DMA transfer, and then starts causing all kinds of havoc on CGRAM. bCPU works with this game because it has the one-cycle delay before starting DMA. Opcode-stepping CPU emulators (ZSNES et al) work with the game because they perform DMA between opcodes. I can fix this by adding DMA bus sync timing to sCPU, but I really don't want to right now. That code is always a pain in the ass to write :( I'd rather spend my weekend playing with real circuits rather than Circuit USA ;_; |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 15, 2006 10:07 pm Post subject: | |||
|
|
|||
Jumbo Ozaki no Hole in One (J):
Essentially, bsnes is running a bit slower than a real SNES. The real game sets $0006 to the location in WRAM of the name entry screen tilemap. In bsnes, an NMI then triggers and updates $0006 to the wrong address. This doesn't happen in other emulators because they run faster (or 2+ scanlines slower, possibly). The game then loads $0006 and uses it for a DMA transfer from WRAM to VRAM. One solution to fix it in bsnes is to remove the HDMA per-channel delay. But that causes flickering to reappear in Energy Breaker. I'll just have to cave in and work on HDMA bus sync timing again :( |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 15, 2006 10:21 pm Post subject: | |
|
|
|
| Hmm, sounds awful. All "#" and "L" (J) games tested: no bugs found. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 15, 2006 10:41 pm Post subject: | |
|
|
|
| T-Z in all regions is already taken care of, thanks to tetsuo. So that means we're almost finished with crazy Japanese games :D So then, M, N, O, P, Q, R and S. And we both know which of those letters is going to Suck the most, heh. Keep up the great work, thanks :) |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Sep 16, 2006 3:21 am Post subject: | |
|
|
|
| No problem. All "M" (J) games tested. 3 bugs found: Mahjong Taikai II (J) - KOEI intro gfx corrupt, gfx issue on stage during intro (occurs in all bsnes versions) Mega lo Mania (J, E) - horizontal line issue during intro (does not occur in .016 or .017 official) Might and Magic II (J) - horizontal line issue on title screen (line is gone completely in .016 and .017. In .017.07, it flickers.) No doubt, a lot of these I'm finding are related. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Sep 16, 2006 6:09 am Post subject: | |
|
|
|
| FitzRoy if you get to S dont do that one as i have already started it, but its HUGE Byuu, maybe you could do other stuff while you wait for the full list of bugreports and then start fixing them all at once? i would think 90% of them are related anyway. |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Sat Sep 16, 2006 6:31 pm Post subject: | |||
|
|
|||
I hear you. I started changing the MESS driver so I could play Super Metroid and Castlevania IV properly with good sound on Linux and I've somehow ended up at "rewrite the entire 65816 and then the rendering" even though the 2 benchmark games seem to work properly. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Sep 16, 2006 6:55 pm Post subject: | |||
|
|
|||
That is a good idea, thanks. Two thirds of my buglist now appears to be those "horizontal scanline issues" bugs, which is quite simply due to not having a dot-based PPU renderer. I really need a good solid week off of work to start on that properly (which I won't have anytime soon), and I'm still not certain I can even pull it off without requiring more CPU power than anyone even has... |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Sep 16, 2006 8:22 pm Post subject: | |
|
|
|
| All "N" (J) games tested. No problems found. byuu, what was the hclock position for .017 official? |
|
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Sat Sep 16, 2006 8:23 pm Post subject: | |
|
|
|
| I was wondering.. these two things may be completely unrelated, but I don't know so don't hit me if it's nonsense ^_^; But.. don't the newer graphics cards use per-pixel rendering? So wouldn't they be rather good at processing dot-based rendering work? |
|
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Sat Sep 16, 2006 9:53 pm Post subject: | |
|
|
|
| Nevermind byuu. Your talking about something else. Btw: I using BSNES with MAMEWAH. Because I can pick the roms from the list on the screen. It much easyer to pick a game. ================================================ Edit. The capture snapshot doesn't work on bsnes 0.17?  I made a snapshots folder and snaps folder. But still nothing in those folders. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 17, 2006 4:00 am Post subject: | |||||
|
|
|||||
|
Hooray! built my first working circuit :D Negative to 5v voltage regulator to 2.2kohm resistor to photoresistor to 5mm 2.1v LED to positive looped across a 9vdc battery of unknown amperage. Result: LED turns on with light in the room, turns off without light. $110 in parts well spent. Going to try and use an NPN transistor to make a NOT gate on the photoresistor signal next so it only turns on in the dark. 100-pin 2cm surface-mount SPC7110... you're on notice.
128.
Not if you use the DirectDraw renderer (you have to set it manually in the config file, so you're probably not using it) or if you're missing d3dx_*.dll. I've decided not to throw out an error message just yet. Mostly because I'm planning to rewrite it to use my own code instead of d3dx code. It will only output bitmaps this way, but won't require any extra drivers. |
|||||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Sep 17, 2006 4:02 am Post subject: | |||
|
|
|||
pry around 150-200mAh (best guess I can give, basing these findings off rechargeable batteries shaped like 9volts, also my psone battery project, using TWO 9v duracell alkaline batteries) _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Sun Sep 17, 2006 4:57 am Post subject: | |||
|
|
|||
Where do I need to enable it at? I'm confused. I have DirectX 9.0c install. Last edited by T-Doomdays on Sun Sep 17, 2006 5:00 am; edited 1 time in total |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 17, 2006 4:57 am Post subject: | |
|
|
|
| Yeah, it kind of bothers me that my multimeter only goes up to 200mA for voltage measurement x.x How am I supposed to test my 9VDC, 1000mA power source that I plan to permanently wire to my breadboard? The 10A port is only for resistance and/or current measuring, right? |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sun Sep 17, 2006 5:03 am Post subject: | |||||||
|
|
|||||||
I'm going to feel sorry for you when soul sees this thread, but voltage != current. Volts are a measure of force/pressure/etc in a circuit. Current is a measure of electricity flow, measured in amps. Watts are a measure of TRUE power. Volt-Amps are a measure of APPARENT Power. And Resisitance is a measure of the resistence of current flow in a circuit, measures in ohms.
As long as you don't go over 200mA when testing current flow, you're fine. If you're measuring voltage, you're fine there too.
Eh.. what ? I'm half-inclined to say 1000mA = 1 Amp, but I don't think that's what you mean. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||||||
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Sun Sep 17, 2006 5:26 am Post subject: | |
|
|
|
| byuu, I download the d3dx9_26.dll (Lates) and put it into the BSNES folder. Now I getting the snapshots made. I don't know why the DirectX 9.0c doesn't have any of the d3dx*_*.dll files. |
|
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Sun Sep 17, 2006 5:26 am Post subject: | |||
|
|
|||
When the red lead is plugged into the 10A plug, the meter must be set at the 10A Current reading setting. For all other measurements, it goes into the normal plug. Always remember this and take this to heart: Voltage is measured ACROSS a load. Current is measured by breaking the circuit and measuring IN SERIES with the load. I can remember watching in horror as my father ripped my new christmas present from my hands and attempted to measure the voltage in the 110V outlet. Hmm, 122V, a little high. Now to measure "current" in a 110V outlet. He moved the probe to the 10A lead, and set the meter at 10A, and just as he started to move the two leads to the power outlet, I asked him if that was such a good idea... Oh, nonsense, these things are built to handle that current... Bright flash of white light, the smell of smoke, there went any possibility of measuring current ever again ;_; but since there was no blown fuse I could still measure voltage with the thing... There are non-contact ways to measure current, but in a multimeter, the current is calculated from the voltage drop across a shunt (a low-value resistance). Byuu, Voltage measurement should not draw more than a single milliAmp from the source, if even that. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 17, 2006 5:39 am Post subject: | |||
|
|
|||
Thank you. Needed this info to finish my hclock testing. My conclusions are as follows: Despite seeing horizontal line issues in quite a few games, it seems that there are two different issues at work here. One, is the hclock number issue. The games in this camp are: Taz Mania (E, U) Prince of Persia 2 (E, U) Top Gear 2 (E, U) Might and Magic II (J) In .016 (hclock of 192), just "MMII" has an issue. In .017 (hclock of 128), all games have issues. In .017.07 (hclock set to 128), all games have issues, like .017. In .017.07 (hclock set to 192), just "MMII" has an issue, like .016. In .017.07 (hclockset to 256), no games have the issue. It appears 192 was not quite high enough. Despite version changes, game response to hclock changes remained consistent. I also tested 1200 japanese roms with no further issues, so it seems a safe improvement to increase hclock to 256 for future releases. The next camp of games with horizontal line issues seem to be caused by a regression bug that was introduced in .017.04 with either the "Winter Gold" fix, or the "IRQ" fixes. These games are: Battle Blaze (J) Mega lo Mania (J) In .016 (hclock of 192), neither has a problem. In .017 (hclock of 128), neither has a problem. In .017.07 (hclock at 128), both have problems. In .017.07 (hclock at 192), both have problems. In .017.07 (hclock at 256), both have problems. I tried many other hclock settings with .017.07, but nothing had an effect. The fact that these games work in .017 official proves that despite the new core, and a lower hclock (which broke our last four games), the games still worked. The problems came up with .017.04 when those two fixes were made. A doubt you could express would be: the IRQ fixes changed the timing to make a different hclock work. But if that were the case, the behavior in the previous four games would have also become warped. But they didn't. Behavior with hclock remained fairly consistent with only the slight difference of an MMII line flickering instead of not showing up. Also, I've tried many other values to no avail. Since the scanline renderer will be the renderer of choice for users because of its speed and near-identical compatibility, I recommend not treating these as inherent see-saw bugs of a hackish implimentation, but a possible bug that can be rectified in the current renderer. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Sep 17, 2006 6:33 am Post subject: | |||
|
|
|||
That is because DX9c does not come with them by default, you would have to obtain them as those post DX9c updates. _________________ FF4 research never ends for me. |
|||
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Sun Sep 17, 2006 9:30 am Post subject: | |
|
|
|
| How I keep the saves, cheats and snapshots out of the roms folder? How I config the paths for those? | |
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sun Sep 17, 2006 10:00 am Post subject: | |
|
|
|
| Byuu,
I have a rendering request I was wondering if it were possible to
implement. Basically what I'm after is a cropped overscan ability. What I'd like to do in fullscreen mode is set the "rendering" resolution to 1280x1120, which is exactly 5x the original resolution. This makes scanlines appear evenly. Now the tricky part is I want to set the "screen resolution" to 1280x1024 and have the remaining 96 lines cropped evenly from the top and bottom of the screen (48 lines each). As it is now, anything set in the rendering options that goes beyond the screen res settings get automattically squeezed down into a messy fit. Let me know what you think of this. Thanks! |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Sep 17, 2006 10:09 am Post subject: | |||
|
|
|||
There is a cfg file for BSNES for the save files... try looking in it. For the latter two, there's nothing you can do at the moment... only byuu can change that (if he wants). _________________ FF4 research never ends for me. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 17, 2006 8:26 pm Post subject: | |||||||||
|
|
|||||||||
Thank you, but I know that. My point was that there is a positive (red) connector and a negative (black) connector, and I want to measure voltage. The positive connector clearly states under it "MAX 200mA", which suggests to me that it can read voltages up to the amount specified by the click position I set it to, and that it can only handle, at maximum, 200mA from whatever voltage power source that is. Which is why I'm worried, since my power supply is going to be 9VDC 1A. Ignore my question about the 10A port. Let me read over measuring ohms and amps before messing with that again.
Ouch x.x My roommate tried to measure the amps on a non-rechargeable 9VDC fire alarm battery we bought. Thing heated up extremely quick. No bright white flash or blown fuse (hopefully), though. Then I tried hooking up a LED without a resistor and found a cool way to make smoking LEDs. Ah, but this is how we learn.
If we find an hclock position that works for everything, ok. Otherwise, it would require game-specific hacks, to store the hclock positions needed for each game. I'll look at Battle Blaze and Megalomania shortly.
I did want an inverse clip mode for simulating TV borders anyway... I'll think about it. |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 17, 2006 8:51 pm Post subject: | |||
|
|
|||
Thanks. But like I said in the report, a 256 hclock resolved all issues with the four known hclock-sensitive games. If Battle Blaze and Mega lo Mania are indeed a separate bug as I suspect, and you are able to fix them, theoretically all issues would be resolved without resorting to hacks. |
|||
New Member
Joined: 23 Nov 2005
Posts: 6
Location: México
| Posted: Sun Sep 17, 2006 10:50 pm Post subject: | |||
|
|
|||
whicker is right. You shouldn't worry about the "MAX 200mA" stuff, it's a warning only if you try to measure current (as whicker said, breaking the circuit and in series). |
|||
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Mon Sep 18, 2006 2:09 am Post subject: | |
|
|
|
| Hey byuu, why my saves games aren't going into the saves folder? Here is what it is doing. savesLegend of Zelda, The - A Link to the Past (U).srm Here what I did. # Default path for all save RAM and cheat files ("" = use current directory) # (default = "") fs.save_path = "saves" So what I'm doing wrong? I can't find a snapshot path setup. All I found is this. # Image format for screenshots # Valid formats: "bmp", "png", "jpg" # (default = "png") misc.image_format = "png" Everytime that I go into the roms folder and get the snapshots... I get lagging slowdown on my computer because I have too many roms. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Mon Sep 18, 2006 4:34 am Post subject: | |||
|
|
|||
It should be rather obvious judging by its behavior. Entering in "saves" is not valid, since it is being interpreted as a name parsed as part of the the filename, and not part of a directory. If you were to do "saves\" I would guess that it would try to store it in "current BSNES directory\saves\". Of course, using an absolute path would have made your life easier though. Something like "C:\some\path\to\save\dir\" would work better. _________________ FF4 research never ends for me. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 18, 2006 7:30 am Post subject: | |||
|
|
|||
Ah, thank you. Seems like you're really limited as far as measuring current goes. But that should be ok, as long as I get voltage and resistance, I should be able to figure out current anyways, at least approximately. Hopefully the multimeter/fuse wasn't damaged by testing the current on the 9V battery (most 9Vs appear to be <200mA anyway). RE: directory stuff: I used to automatically append "\", but modified my config loading system to not allow for overloaded operators on the Setting class type to simplify it. Never bothered redoing that code. I'll get around to it. For now, add on your "\" and be careful about where your ROMs are, "..\" in your paths may not work like you expect in all cases. Images don't have a path to save them in, they go where the ROM is. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Sep 18, 2006 8:21 am Post subject: | |
|
|
|
| When
you have a folder of over a thousand roms, creating these files in the
same directory makes them a bit harder to find and manage. Just about
every emulator these days generates a set of folders for "cheats,"
"patches," "saves," "screenshots," etc. and has a gui area called
"paths" where users can define their own destinations should they want
to deviate. Are you opposed to this, or have you just not gotten around
to it? All "O, P, Q, R" (J) games tested. 1 possible problem found: RPG Tsukuru - Super Dante (J) - hangs and plays wrong music before gameplay, appears to think there are save games when there aren't. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Sep 18, 2006 9:01 am Post subject: | |
|
|
|
| Holy moly your fast FitzRoy. | |
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Mon Sep 18, 2006 9:13 am Post subject: | |
|
|
|
| Ok I got the cheats and saves setup the path correcty. D:\BSNES\Saves\ Deathlike2, thanks point that one out on how to fixs it. |
|
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Mon Sep 18, 2006 9:46 am Post subject: | |||
|
|
|||
sorry but what IS true power exactly? and define apparent power.... i wanna know so that it makes sense lol. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|||
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Mon Sep 18, 2006 11:34 am Post subject: | |||
|
|
|||
Do you actually own the cartridges for the roms or are you just a pirater who goes around bragging about how many roms you have and likes to get attention from Nintendo 
|
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Sep 18, 2006 11:52 am Post subject: | |||||
|
|
|||||
He seems to be one of those guys who owns a bunch of games, but likes to have a full dumped SNES set so he can test bsnes. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Sep 18, 2006 12:04 pm Post subject: | |||||
|
|
|||||
Do you always read only the last post and then respond? If you had read better you would know what he's doing |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 18, 2006 1:49 pm Post subject: | |||
|
|
|||
Awesome, thank you. One more letter... and we'll finally be at the end of Japanese ROM hell x.x |
|||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Mon Sep 18, 2006 3:34 pm Post subject: | |||||
|
|
|||||
You said you have a 10A port on your multimeter, right? Then, you're not limited at all. Just use that port when measuring current you suspect may be above 200mA and it will operate just fine up to 10A!! That port will also measure current under 200mA, but it will not be as accurate as the 200mA stage. If you build or have something that outputs more than 10A of current, you've graduated into a relm of needing more than a new multimeter.
Not to mention, 10A is like vacuum cleaner current. I don't think
you'll be making any circuits sucking up that much juice without some
sort of motor.As for voltage, it's already been pointed out to you that voltage measurement is a SEPARATE measurement. You can measure voltages as high as your meter scales allow you to go without damaging the meter. You can measure the several hundred volts coming off a flyback transformer in a CRT monitor or TV with a simple multimeter without issue because the meter is not in series with the circuit and the current isn't going through it. Lastly, I'm sure you've heard of Ohm's Law? If you haven't, that's a fundamental principle anybody tinkering with electronics should learn. A good excersise would be to draw a little schematic of your simple circuit and put in the known values. Then see how everything works out mathmatically. You can then verify it with your meter. An important concept concerning wall adapters: The rating on a wall adapter such as 9VDC 1000mA is what the adapter is capable of putting out under load. Listen to me when I say this. If you use this adapter for a circuit you build, yours probably will NOT measure 1000mA of current in your circuit. A circuit only draws as much current as it needs. It's a common misconception to think that current levels of devices using a wall adapter are magically using the rated current on the adapter. That's why many times you can get away with using a variety of differenly rated adapters to power the same device. That number is a rated maximum current output at a given voltage for that power supply. It is NOT how much current will be output at any given time on any circuit connected to it. Also be aware that if you use an adapter such as 9VDC 1000mA and you use that to power a lower current circuit, your supply voltage will creep up as a result. For example, it can put out 1000mA at 9VDC, but if you're only using 800mA, you may actually see 10 or 11 VDC as the actual output. Simple test, hook up your adapter and use your meter to measure the voltage coming out of it. You're going to see it will be higher than the rated voltage because there is no load. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 18, 2006 4:29 pm Post subject: | |||||||||
|
|
|||||||||
I understand they are separate, and am familiar with Ohm's law. My thinking was this: I = V / R. So if I have no resistance, and 9V, then I would be putting out > 200mA of current from the power source. Despite the fact that I was only measuring voltage, the higher amperage during the measurement of volts was what I was afraid would cause problems. But you're saying that current doesn't flow through the multimeter in voltage reading mode...
Funny, I have a 36" TV with a dying flyback transformer. I can replace it myself for $40, or pay some scam artist >$200 to do it for me. I'm thinking the latter is a much smarter move at this point, heh.
But of course.
Yes. Tried that, and indeed I wasn't sure why I was getting such a higher voltage. I plan to feed the cathode directly into this: http://www.radioshack.com/sm-5v-fixed-voltage-regulator-7805--pi-2062599.html I have tried this with a 6-cell 9V battery and was able to read output of 5V, so it apparently seems to work ok and doesn't burn up on me. I'm not confident enough to try and measure the output current, but according to what you're saying, the current level does not matter, individual parts will only use what they need and pass on the rest (I assume all the way to anode connection where most of it will be recycled and passed right through cathode again). So then, question... if there is only one device consuming ~10mA in a circuit, then you're saying that chip only draws 10mA of current? I would assume Ohm's law is correct in that I = V/R in all cases, so if the device had a resistance of 100ohm's, 9V, it would consume 90mA, but actually receive all ~1A (a little less since you said voltage would be higher with nil load) of current from the DC adapter, and pass through ~910mA of current out of anode/positive for other devices to use? In that case, I need a bit of help with resistors. With my LED, I am putting a 2.2kohm resistor to keep it from catching fire like my first one did. I've read that you take LED voltage (let's say 2.1V) and resistance (let's say 20mA). So you want (5V - 2.1V) / (0.02) = 145 ohm or greater resistor. Now what I'm curious about is why does this work with 145 or greater ohms resistance, and get the same average luminance either way? Wouldn't increasing the resistance weaken the luminance of the LED? Surely a 2.2kohm resistor would be too resistance to light up the LED at all. Also, on my breadboard I have to connect the circuit like this for it to work: (cathode [-]) -> resistor (2.2kohm) -> LED cathode -> LED -> LED anode -> (anode [+]) If I put the resistor on the other end, it no longer works. And yet, most of the documents I read online say the resistor goes after the led, such that: (cathode [-]) -> LED cathode -> LED -> LED anode -> resistor (2.2kohm) -> (anode [+]), which does not power on the LED for me. Is this just due to us swapping + and - (thanks to Ben Franklin's famous mistake)? I assume that energy flows from negative (cathode) to positive (anode) in my examples, but still notate cathode as negative and anode as positive. |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Sep 18, 2006 5:51 pm Post subject: | |||
|
|
|||
Actually, that took up most of my weekend. I was sick, so I was able to get it done. Plus that, "Q" was only one game. And believe me, djohnson, after trudging through every pachinko, mahjong, and horse-racing simulation on the snes, the last thing I want to do is brag. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Sep 18, 2006 8:17 pm Post subject: | |
|
|
|
| Had
to wait for a delivery today, so i had some time to get further along
through S, still a lot to go though, only bugs found sofar have to do
with BS. BS roms are scarily compatible though almost all of them work, my theorie is that BS only adds some work ram or something judging from the bugs.... |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 18, 2006 8:36 pm Post subject: | |
|
|
|
| RPG Tsukuru is fixed. Wasn't mapping SRAM to $f0-$ff in LoROM due to logic bug (have to block them in HiROM games or lots and lots of games go nuts). | |
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Mon Sep 18, 2006 8:47 pm Post subject: | |
|
|
|
| Are
you fixing the Super Nintendo or your moding it to where it can hookup
to your computer so that you can dump the roms through the snes from
the cart? It would be cool to dump the cart roms from the snes which you get a better dumping this way rather than getting a hacking dumping tool to do it. Actually I don't know if it will work this way or not because I haven't seen it done this way yet. |
|
New Member
Joined: 31 Aug 2006
Posts: 4
| Posted: Tue Sep 19, 2006 12:39 am Post subject: | |
|
|
|
| i found another obscure game thats not working: Bananas de Pijamas (Unl) it frezzes @ the gamescreen, the same with zsnes |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 19, 2006 1:28 am Post subject: | |||||
|
|
|||||
Sweet. Didn't even add it yet.
Thanks, but that rom is not in NSRT and this is a GoodTools-free zone. Not speaking for byuu, but I have to assume that hacks and pirate carts are not currently going to be looked at when commercial games still have issues (if ever). In fact, I've gone ahead and added a notice to my first post with the hopes that people see it. Without the luxury of a separate forum and fancy ass announcement stickies on how to file a proper bug report, it's the best I can do. |
|||||
New Member
Joined: 20 Apr 2006
Posts: 7
| Posted: Tue Sep 19, 2006 9:34 am Post subject: | |||||||
|
|
|||||||
yes i have read it and i know what he is doing but do you see anyone else say "I got a folder of over a thousand roms " NOOOO!!!! to me that is bragging
|
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 19, 2006 10:01 am Post subject: | |
|
|
|
| This
is not the place to make those kind of bogus inferences. Lots of people
have a thousand or more roms. It gives them the ability the discover
fun games they would have otherwise never known existed, not to mention
try out new translations without having to go hunt something down
first. It's also a matter of convenience for testers such as myself,
and also allows greater circulation and preservation of games. Plus that, if I were bragging about the number of roms I had, why would I hate GoodSNES so much? |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Sep 19, 2006 10:56 am Post subject: | |
|
|
|
| Djohnson, you are totally off, just leave this thread. Flitz is actually a great help for byuu, you are not. |
|
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Tue Sep 19, 2006 1:16 pm Post subject: | |||||||||||||||||
|
|
|||||||||||||||||
I'm
going to provide you with a bunch of information to help clear up some
of these concepts here. I'll try to not to give too much for fear
you'll hit that viscious circle where you'll just get a bit more
confused and ask more questions.
Well technically.. to be 100% correct, current DOES flow through the multimeter, but it's very little and can be ignored in most applications. http://www.ee.duke.edu/~cec/final/node32.html That's how it actually works. It is in parallel with a portion of the circuit to measure a voltage drop. The internal resistance of the meter is high enough to allow very little current to flow through at all, but it's enough to give you a voltage drop measurement from the meter. When you have two resistances in paralell, they will share the same voltage drop(giving you an accurate voltage measurement) however the current will be split proportionately(NOT evenly) between them. Since the multimeter resistance value is so high, it has little to no effect on the circuit and consumes very little current in most applications. So, you can stick that on a power supply such as your 9VDC 1000mA and it won't blow up because it will only draw a very small amount of current from it. Do some quick math here. Say the internal resistance is 100Meg Ohms(100 million). Generally, this value varies depending on your meter scale and quality of the meter. Anyway, for arguement sake, let's say it is 100Meg ohms. You've got: 9V/100,000,000 Ohms = .09mA of current. That's so small, it's almost insignificant.
Be careful.. You may not have any problems with your meter measuring the voltage here, but these transformers ARE dangerous to the human body. If you attempt this, make sure not only that you unplugged your TV, but that it has been unplugged for several HOURS so it is fully discharged. no joke man, some of these that are faulty can output over 1000 volts at a current large enough to really hurt you.
That's the whole purpose regulators exist. They regulate the voltage to what you need. Regulators aren't magic of course. The way they turn 9volts into 5 volts is by dropping the necessary voltage within themselves. The tradeoff of course is heat. That's why they recommend a heatsink in some applications where the power disspitation is higher. You'll only be dropping 4 volts on the regulator. That's probably less than a 1/4 Watt power dissipation. You should be fine. However, if you used say the maximum of 35 volts, you'd hav ea 30 volt drop which would be several watts which would probably burn out the regulator without a heatsink.
That's what I'm saying. But listen, your example device here draws 90mA. So.. 90mA is ALL the current that flows through the circuit. There is no 910 other miliamps. The power supply CAN output 1000mA but it WON'T unless the circuit can draw that much. Generally this excess potential is given off as heat(power dissipation) from the power supply itself. That's why your wall adapters will generally be warm to the touch even if the device they are plugged into is completely off. That's another lesson for another day though. Power supplies are a big subject. Just don't expect to see 1000mA of current in your circuit just because that's the rated current of the supply. That's all you need to know. The multimeter is proof of this. It can measure voltage without burning out. Why? Because it only draws a tiny bit of power from the big 1000mA supply. LED's though are a bit different type of bear.. I'll explain those next.
An LED is not a resistor and such is why it's rated in volts. LED's are basically diodes that give off light instead of heat(technically heat is light though, it's just not visible to us). What this means is it will drop it's rated voltage and draw INFINITE current(or until it burns up). You NEED a resistor to limit the current going through it. If you just hooked up an LED to your 1000mA supply, just like you experienced, it will draw the whole damn thing and burn right out. That's the way LED's work. They will eat as much current as they can having no regard for their own wellbeing. When you put that resistor inline, you've now limited how much current can flow through the LED to a finite number. And of course, the amount of light it gives off is proportionate to the amount of current. If you used a larger resistor value, it will start to grow visibly dimmer until it won't even give off visible light anymore. So, you've got the right idea. a 2.2K Ohm resistor will probably not work very well, but you may still see some light. Typically, for our designs here at work we use 330 Ohms as our typical LED current limiting resistor. For portable battery powered devices, we use a higher value sometimes as high as 780 Ohms. This gives good luminance and limits the current to a nice level. From my experiences, you will probably still have decent light output up to 800 Ohms or so. I'd say with 1K, you'll probably notice dimming if not before that depending on the LED. An LED is a diode, therefore current will only flow in ONE direction. On an LED it's anode to cathode. The resistor should be able to go on EITHER side of the LED so long as the anode side of the LED is on the anode side of the battery. You can flip the resistor to either side, but you can't flip the LED or battery. The resistor can go on either side because it isn't changing anything in the circuit. The series resistance and current values are still going to be the same. I'm not sure why it didn't work for you. Maybe you got something mixed up. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 19, 2006 3:33 pm Post subject: | |||||||||||||
|
|
|||||||||||||
Thanks, I appreciate the help :)
Indeed, I've read how lethal the stored charges inside TVs can be, even whilst power is off. Hence, I probably won't ever attempt to repair it myself.
Odd. If the resistor resists 300ohms, then wouldn't that mean the LED itself would try and consume all available current from the power source minus 300ohms? Hence, a 2.2kohm resistor would take all power minus 2.2kohms, thus the LED would get less current, thus it would get darker.
Actually, it was quite bright, heh. But I didn't compare against 300ohms, so maybe it wasn't near its potential.
Wouldn't current always flow negative to positive?
I guess that sort of makes sense. If it were water, and the resistor were just a smaller tube length, it would slow water before or after it (eg in the entire tube)... maybe I just connected it wrong. I need to experiment more, but this is yet another thing I can only really work on at home, and I think everyone here knows how limited/stretched my time is there :( I think what I'm doing wrong now is getting confused between so many different variables (voltage, current and resistance), multiple directions (some things being positive to negative, some being negative to positive, current flowing one way, voltage going another?), and still not clear on resistors entirely. I'll keep looking online for better resistor tutorials. --- EDIT: hmm, I think I understand the resistor thing now... Say with 9V,1A power supply and 2.1V LED... I can't determine how to get amperages going through the LED from this (9V-2.1V)/(0R?)... but let's say with resistors: (9V-2.1V)/300R = LED gets 23mA of current (9V-2.1V)/2200R = LED gets ~3mA of current So, more ohms = less amps. Resistance does take away current, but you can only have as much current as your LED takes in volts. The resistor itself doesn't affect the voltage level of your circuit, the voltage usage is entirely from (Vtotal - Vparts), where in this case Vparts is just the LED voltage rating, right? Surprising my LED was so bright with only ~3mA current, though. |
|||||||||||||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Tue Sep 19, 2006 7:25 pm Post subject: | |||||
|
|
|||||
Yes, but the LED doesn't let anything through if you put it in the wrong way around (try it with a variable current, it should flicker (though at the standard 50Hz, you might not notice)) As for current going one way and voltage the other, that's just a problem of definitions. Back when electricity was first discovered, they had to lay down some definitions; so they said current flows from the positive to the negative pole (whatever they're called, I'm bad with terms). This isn't true, as it turns out, because electrons are negatively charged, and so are attracted to the positive pole - but they never bothered to change the definition for the sake of tradition, and because it's not that much of a problem. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 19, 2006 8:09 pm Post subject: | |||||
|
|
|||||
I understand that the definition is backwards. So if current flows from negative to positive, then why does Nightcrawler state that the current flows from anode (+) to cathode (-) in LEDs?
If current flows from negative to positive (in reality), then the same should be true for the LED, right? Sidenote, this is my "LED turn on only in the dark" circuit I'm presently working on, hopefully it works. I'll try it tonight and see what happens. 
|
|||||
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Tue Sep 19, 2006 8:28 pm Post subject: | |||
|
|
|||
You have that backwards the cathode is + and the anode is - |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 19, 2006 9:08 pm Post subject: | |
|
|
|
| Conventially,
historically, and mostly still presently, anode is referred to as
positive. For the fourth time now I repeat, I am aware this is
backwards, but this is how it's referred to. And I know why it's
backwards and I understand that. I have read this page completely: http://www.allaboutcircuits.com/vol_1/chpt_1/7.html This is causing me nothing but confusion because literally everybody swaps the definitions of the two based on their preferences and/or lack of understanding that there are two alternatives, and as a result, I have no idea what's really going on because nobody bothers to explain which interpretation they are using for positive/negative or anode/cathode. Here is an example image:  So let's get rid of these terms all together and rephrase things. Basically, in a LED, the current flows through it like this: (power source, electrons moving right) -> resistor -> LED pin left -> LED (electrons still moving right, LED works because the LED also moves electrons from left to right) -> LED pin right -> (other end of power source, completes a loop) So... problem solved. Nightcrawler is using Electron Flow Notation. |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Tue Sep 19, 2006 9:47 pm Post subject: | |
|
|
|
| ha ha ha. be glad this isn't an AC ciruit. wiring DIAGRAMs don't care about current direction, just as long as the plus and minus are lined up in the right way the minus sign is generally to the left and to the top, and the plus is to the right and to the bottom -and most parts are well labled in that regard, and beyond that is of little real issue to the average non-ubergeek which way current flows. I use the heat ananlog, current flows towards there is none. tho, IIRC, anode and cathode don't switch places in the notations. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 20, 2006 4:06 am Post subject: | |
|
|
|
| New
WIP should fix: RPG Tsukuru, Circuit USA, Jumbo Ozaki no Hole in One
(not a permanent fix, I'm not entirely happy with the HDMA timing, but
at least the name entry screen works again for now), and Taz-Mania. The two games you said started flickering since v0.017.07 might be fixed now, but I'm not worried about these horizontal-line issues regardless of when they started occurring at the moment. The other ones you said would be fixed by setting HCLOCK=256 should be fixed as well, as this is the new default value. Super Mario Kart's line doesn't appear to flicker now, but I think it's because I'm technically running the emulation a little too fast again, due to the Ozaki fix. Another game you shouldn't expect to stay fixed, and again another game I'm not worried about remaining fixed. Koushien 2 and Mahjongg Taikai 2 are very likely still broken. Uniracers definitely is. These appear to be the only three serious known bugs remaining. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Sep 20, 2006 4:44 am Post subject: | |
|
|
|
| Cool. I'm having a big problem assigning buttons in this wip, though. Doesn't seem to recognize my controller or keyboard presses during assignment. Tried deleting the cfg file - no go. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 20, 2006 6:15 am Post subject: | |||
|
|
|||
|
Well,
my LED circuit doesn't work at all. I can't tell the difference between
my two PNP and NPN transistors, so I tried both. One of them makes the
LED work as if there was no transistor at all (turns on with light,
turns off without light), the other results in the LED always being off. Even more fun is I can't use the power lines on my breadboard, probably because I don't know how. I have it like this:
The LED just burns up like this. I know those lines are supposed to only be used for power, but eg when I use them just for that, nothing ever works right. I really hate that there's no way to "debug" this stuff. I don't have patience for things that either "work or don't work" like this... Anyway, key assignments... yes. As mentioned previously, I added the controller port assignment settings to the configuration options panel. Doing that broke the input configuration panel. I haven't gotten around to fixing that yet, so key assignment is busted. Edit the config file, or copy/paste your settings from 0.017.07, or just use the defaults for now, please. Last edited by byuu on Wed Sep 20, 2006 6:21 am; edited 1 time in total |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Sep 20, 2006 6:20 am Post subject: | |
|
|
|
| That works. Thanks. Going to start testing again this weekend, and it'll be nice to control stuff. |
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Wed Sep 20, 2006 8:17 am Post subject: | |||
|
|
|||
The problem with Mega lo Mania is caused by the Winter Olympics fix. The game is probably writing to $2101 just before the PPU caches $2101. Winter Olympics must be writing to $2101 after the caching. To fix both games, OAM caching must be done at the correct time. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Sep 20, 2006 10:29 am Post subject: | |
|
|
|
| Fitzroy, which games are you gonna test?, im still working on S(ALL regions) E and U from A to T still need to be done |
|
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Wed Sep 20, 2006 1:09 pm Post subject: | |||||||||||
|
|
|||||||||||
I see what your logic is, but it doesn't quite work like that. Think of it like this. The resistor only allows x current to pass through it based on it's resistance value. So your (5V-LEDV)/300ohms = xxmA. So.. only xxmA flows through/past that resistor. Therefore, ONLY xxmA can flow through the LED. Does that make sense to you? A resistor is acting as water flow control device in a case like this speaking in terms of water(current). So, even if the resistor is after the LED, it will still limit the flow to 16mA. The LED doesn't limit flow at all, therefore the resistor is the only thing to limit it. So even though you have a supply that can output 1000mA, with the resistor inline, the LED sees that all it can draw is xxmA and it will draw just that.
Life will be easier for you if you disregard the direction electrons flow. This information is not necessary for schematics or circuit building really. It's more of a physics thing. Believe me the physics behind electronics is a whole nother world as well. While you're free to study the internal structure of a diode or LED, it's not necessary to use them. When you design your circuits, keep it simple. + to +, - to -. Don't worry about which direction electrons actually flow. Therefore, connect the + side of the battery to the anode + side of the LED. You're making it more difficult on yourself to bring it down to a physics level immediately. That's alot to handle. You can learn about electron holes, junctions, substrates, and doping to learn how these things work on an electron level, but I'd stay away from that for now.
Yes. That's pretty much how it works. I a series circuit with just an LED and resistor, there will be voltage drop on both parts. You've got your 2.1V drop on the LED and you'll measure the other 6.9V drop across the resistor. In a series circuit like that, the voltage will always be divided amongst the parts which will all add up to the source voltage. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 20, 2006 2:22 pm Post subject: | |||
|
|
|||
Ah, thank you. Unfortunately, the PPU only runs at HCLOCK=0 and HCLOCK=n (set by the config file, presently 256). So I can only cache one line in advance, or not at all. Or in other words, either Winter Gold is fixed or Mega lo Mania and the other game is fixed :/ So, yet another limitation of the scanline-based PPU. That leaves only two issues that aren't directly related to the PPU. I guess I'll look into Mahjongg next then. |
|||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Wed Sep 20, 2006 2:31 pm Post subject: | |||||
|
|
|||||
First, with your schematic, your design is for an NPN transistor. The difference between NPN and PNP transistors is the collector is designed to be at a more positive potential than the emitter on NPN and the reverse on PNP. You'll see what this means in a minute. Second. The way you laid out your circuit, the transistor turns ON when light is present. I would expect the LED to turn ON when there is light and off when there is not. That is what you are experiencing with one of the transistors, right? That's what I would expect to see happen. Think about it. The transistor turns on with current at the base. Your LDR conducts when light is present, therefore the transistor turns ON when light is present thus lighting your LED. You want an opposite effect. you want the LED to turn on in the dark. Therefore, you need the transistor to turn on when the LDR is NOT conducting. To do this, you can use a PNP transistor. HOWEVER, you must connect it like this..  I don't have a scanner, so this is ripped from another site. Your Load will be the LED and resistor. The Rb will be your LDR and resistor. Ignore chip output. With this setup, the transistor is ON when there is NO current to the base and is OFF when current is there. This will make the transistor OFF in the light and ON in the dark when the LDR is not conducting thus turning on your LED. You can 'debug' this stuff. That's what math and your multimeter are for. You can calculate on paper what the current and voltage will be for every part of your circuit. When your meter observation does not match the math, you'll know where the problem is, or at least where to start. However, to effectively do this, you need a good understanding of what SHOULD be going on to begin with which takes some time to build that knowledge up. It's really the same as programming. You have a debugger, but the debugger is useless to you unless you KNOW how to use the debugger and what you should expect to see. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Wed Sep 20, 2006 4:54 pm Post subject: | |
|
|
|
| Now
I understand the confusion. The cathode is the positive terminal of a
voltaic cell, but the negative terminal of an electrolytic cell. I
guess I can blame my physics and chemistry teachers for not explaining
this better . |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 20, 2006 5:51 pm Post subject: | |||||||
|
|
|||||||
My design used a PNP transistor, as the arrow was pointing at the base. But if you mean it was an for an NPN transistor due to the placement of my LED, then I guess I don't understand how to arrange these components correctly yet... With my circuit, my idea was that power would go through the LED, to the PNP collector. Then, the LDR would go to the base. If the LDR was illuminated, it would have a signal, and the signal would block current flow to the emitter. Otherwise, it would have no current flowing through it, and the collector would allow current to flow to the emitter. Apparently, this is not the case, heh.
Yep. Be nice if I could tell the NPN and PNP transistors apart, heh. Damn package I bought has both stuck next to each other unlabeled. I'll have to go by Radio Shack and get some more in labeled packages.
With an NPN transistor, yes. But my diagram showed a PNP transistor, which is supposed to turn OFF when there is current at the base x.x With current off between collector and emitter, it should break the circuit and turn off the LED. But I'll try with your diagram tonight I suppose, and put the LED after the emitter instead...  This look ok? Energy should flow from +5V to resistor where it's capped to a safe value for both the LDR (though the LDR may not need one) and the LED. The +5V line splits, one going to the PNP collector, one going to the LDR, the LDR then connecting to the PNP base. The PNP emitter will forward +5V to the LED only when the LDR resistance is low (eg the room is dark), the LED forwards current to ground, forming a circuit loop. Result should be that the circuit only completes when the room is dark, and thus the LED only lights up in the dark. |
|||||||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Wed Sep 20, 2006 6:20 pm Post subject: | |
|
|
|
| I
was going to suggest using a relay, but try not attaching the wire from
the LDR back before the transitor, but to the wire that leads back to
the battery from ground. Im thinking you don't need to worry about ground anyways for these type of simple ciruits, it might causing some issues in and of itself. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
New Member
Joined: 20 Sep 2006
Posts: 2
| Posted: Wed Sep 20, 2006 7:31 pm Post subject: | |
|
|
|
| Just a thought... Are there any software available which simulates electronic conponents? Then you could "wire" your circuit with the software by simply picking the components and filling in voltage and resistance values and so on, and debug it on your PC. Would save a lot of time and effort I think... | |
Lurker
Joined: 25 Apr 2005
Posts: 110
| Posted: Wed Sep 20, 2006 8:00 pm Post subject: | |||
|
|
|||
electronic workbench or smth like that. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 20, 2006 9:33 pm Post subject: | |||
|
|
|||
Basically, the game's NMI routine checks $4b bit 0 to determine if it should transfer 544 bytes of WRAM data to OAM, and then clears $4b. However, the game does not bother to set the OAM write address. The game sets $4b bit 0 twice, however, even though the transfer only needs to happen once. Bad programming from a Japanese game company? Whhhhhhhhhhhhhhhhaaaaaaaaaaaaaa???? In ZSNES, the first write to $4b happens really early in the frame, then the second write occurs a bit later on the frame, both before any NMIs trigger. Then NMI gets called, and the game transfers WRAM data into OAM as described above. In Super Sleuth, the first write to $4b happens just after NMI, and the second write before NMI on the next frame. Result: only one DMA to OAM is performed. In bsnes, however, the first write happens shortly before NMI. This causes the NMI routine to perform the DMA to OAM. Then, during the next frame, the game sets $4b again. So at the next NMI, another DMA to OAM is performed. This time though, things don't go so well. Since OAM addr was never reset, it transfers the same data again, starting at OAM addr = #$0220. 544 bytes transferred twice ends up corrupting the OAM high attribute table, and the first 64 bytes of the OAM low table. The problem is basically timing related. I really don't have any fucking clue how I can get absolutely perfect clock latch positions in bsnes after running tens of thousands of NMIs, IRQs, DMA transfers, HDMA transfers, and executing nearly every opcode that the SNES CPU supports, and yet be off by so much timing-wise. So, I can't fix this bug; because I have no idea where the hell the problem is. I have to be off, at minimum, by at least 32,736 clock cycles after only ~18 frames or so, which is absolutely insane. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 21, 2006 3:14 am Post subject: | |||
|
|
|||
Sounds like Uniracers has company. Unfortunately, there aren't any other bugs left to pray for collateral damage.
Hmmm, I wasn't aware of this. Normally, I would be the first one to discount a non-commercial cart, but this time I think it reveals a better conclusion. Even though it's a PD rom, I don't think the cause is bad coding. I think this is another genuine hclock issue from a rom that simply renders something later than all the others. In other words, no commercial game may exist to display an error at this setting, but is nonetheless possible. 192 may not have flickered, but there was still a stagnant line error right below the checkboard area. A setting of of 384 reduces the flickering seen in 256, and a setting of 512 aligns the data correctly so that there is no line issue. It also continues to work for all other games. Noticing a trend here? A higher setting is always proving better. My suggestion now is to set the default to 1096 and be done with it. All known games relating to this issue continue to be flawless at 1096, and since it is the highest setting, it would probably eliminate any possible further issue. Last edited by FitzRoy on Thu Sep 21, 2006 3:17 am; edited 2 times in total |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Thu Sep 21, 2006 3:15 am Post subject: | |||||
|
|
|||||
Yes, that would be it. I used to use this back in my IMT class, around the middle of the year. However I think it's only winders 98se. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||||
Rookie
Joined: 29 Aug 2006
Posts: 25
| Posted: Thu Sep 21, 2006 4:04 am Post subject: | |
|
|
|
| Nevermind. Sorry guys. Last edited by T-Doomdays on Thu Sep 21, 2006 10:25 am; edited 2 times in total |
|
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Thu Sep 21, 2006 6:03 am Post subject: | |
|
|
|
| electronic workbench (if its what i think it is) works fine under windows 2000 cause my school had it. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 21, 2006 6:58 am Post subject: | |||
|
|
|||
The only problem with this is that the line between the mode7 and mode0 backgrounds is supposed to be there on real hardware, and it doesn't flicker. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Sep 21, 2006 7:28 am Post subject: | |
|
|
|
| So you're saying the blue scrambled stuff on the left side is supposed to be there, or just a solid black line? | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Sep 21, 2006 8:08 am Post subject: | |||
|
|
|||
Please stop while you're ahead on this. _________________ FF4 research never ends for me. |
|||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Thu Sep 21, 2006 12:41 pm Post subject: | |||||||||
|
|
|||||||||
Your arrow went to the base from the collector. That's wrong for EITHER transistor. I just made an assumption based on your collector emitter labeling. Take a look at this: http://en.wikipedia.org/wiki/Bipolar_junction_transistor Look at the section for NPN and PNP. You can see the schematic symbol for both. The arrow is always at the emitter. The EMITTER on an NPN setup goes to ground. The COLLECTOR on PNP goes to ground. (technically it's negative potential rather than ground, but for your purposes it's ground) That's the difference between the two. They are reverse polarity and current at the base has a reverse effect as far as swtiching On and Off.
Ok. Well you have the right idea then. It is just laid out wrong. Now that I have a better understanding of what you did wrong and what's going on. Let's scratch your latest drawing and look at your original schematic.. You almost had it right. http://i73.photobucket.com/albums/i221/byuusan/ldr.png The ONLY thing you need to do now is flip your collector and emitter. For a PNP setup, the LED/1K branch should flow *INTO* the EMITTER and *OUT* the COLLECTOR to Ground. Your arrow in the schematic should be INTO the base FROM the EMITTER.
Give me the part numbers on your transistors. I will lookup the datasheets for them and tell you which is NPN or PNP. If you plan on advancing in electronics, the data sheets for parts are important. You don't need to understand everything on them, but it will provide some useful information such as it's pinout, maximum ratings, and if it's NPN or PNP! I wish I had a scanner so I could draw some things to help you out. Hopefully you understand what you need to do now. Just flip your E and C sides on the transistor only. The rest of the original schematic is fine. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 21, 2006 3:44 pm Post subject: | |
|
|
|
Still can't get it to work... This is my third attempt. The holes are for my breadboard. I don't use the power lines because they don't seem to work right (that or I'm screwing it up, probably the latter). The gray lines represent the long columns that are connected behind-the-scenes on the breadboard. Now, as for the transistor... I don't know if it should be { Tc, Tb, Te } or { Te, Tb, Tc }. I've tried with both PNP and NPN transistors in both orientations (basically, I flipped them around since I have no clue which side is the collector and which is the emitter). With the PNP, in one orientation the LED is always on. In the other, the LED is only on with light, and off with darkness. With the NPN transistor, the light never comes on regardless of which direction I insert the transistor. Ideas? |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Thu Sep 21, 2006 4:19 pm Post subject: | |
|
|
|
| I should crack out my 1000-in-1 electronics kit. I need wires for it tho. you can't use an NPN for this anyways, if I am reading that article right. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Sep 21, 2006 4:34 pm Post subject: | |||
|
|
|||
|
Back on the subject of the SNES for a brief moment... I tested hardware interrupts (NMIs, specifically, but IRQs will be the same). Ran four tests, with both FastROM enabled and disabled, and with the non-interrupt code executing in $008xxx and $808xxx. All four times, the NMI fired at $00xxxx (where your NMI interrupt was set to). I tested this because I noticed ZSNES starts its NMIs in FastROM ($80xxxx) for whatever reason. So, bsnes didn't have any problems there, works as I expected. Next, I tested auto joypad polling. I knew it didn't consume any CPU timing (it runs in the background), but I'm kind of desperate. Something has to be throwing my time way the hell off, and I don't know what. Seeked to V=0,HC=0, turned on auto joypad polling, ran for 128 frames and then latched the counters. Identical latch positions in bsnes as on my UFO. So, auto joypad polling definitely isn't consuming any CPU time. So then... I have the following timing elements emulated: - DRAM refresh (perfect) - NMI timing (perfect) - DMA timing (perfect) - IRQ timing (near-perfect, withing ~12 clocks of being correct each IRQ) - HDMA timing (near-perfect, within ~6 clocks of being correct each HDMA) - opcode timing (perfect, excluding maybe emulation mode) - long dot timing, short line timing, and basically all frame timing (perfect) - CPU/APU synchronization (~99.8% perfect, syncs between bus hold delay timing, impossible to get more accurate in emulation, as the difference is due to hardware not running at stock speeds) And yet, I'm still off by tens of thousands of clocks in Mahjongg, assuming the game works on real hardware. My last floppy disk died on me as I was trying to load the game on my UFO to see, though I'm sure it wouldn't have been released if the first damn screen didn't work right on the real thing. I don't know what else to look at. My last resort is going to be to hack the Mahjongg ROM and latch counters and kill the game at varying points and compare the counter latch positions against emulation, hopefully tracing back to the point where things go straight to hell. I seriously doubt I'll have any luck. --- Here's my next idea for the "glow in the dark LED circuit":
T is PNP, of course. The thing that's bothering me at the moment is the LDR<>Tb connection. If Tb activates Tc<>Te passthru based on voltage levels, then what good is using a resistor that only affects amperage levels? And why even use a standard resistor before the LDR in this case if resistors don't affect voltage? |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 22, 2006 12:14 am Post subject: | |
|
|
|
| New
information regarding hclock behavior. Apparently some games break when
hclock is too high, just like some games break when hclock is too low.
Found this out while testing with 1096. T2 - The Arcade Game breaks
after 1054 (and there are probably many other games breaking even
lower). So here's what we know so far: T2 - The Arcade Game - 0-1054 works, 1055-1096 breaks Prince of Persia 2 - 0-182 breaks, 183-1096 works Goodbye, Anthrox - 0-398 breaks, 399-1096 works Might and Magic II - 0-216 breaks, 217-1096 works Taz-Mania - 0-140 breaks, 141-1096 works Knowing all this, I have to think somewhere in the middle is ideal. Like 548. I'll start testing this weekend at this number and see what happens. Still, I am in full support of PPU based rendering at this point. I just hope it isn't any more than a 30% speed hit. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 22, 2006 5:31 am Post subject: | |||
|
|
|||
Once again, that "garbled" line is supposed to be there x.x Also, I do apologize for this, I just noticed you're testing each value rather than ever two... the CPU can only step in two-clock-tick steps minimum, so testing eg 256 and 257 yields the exact same results. Also, because I test the clock position to draw the line between CPU cycles rather than after every clock tick (because it's faster), the actual position the line is rendered can vary between n and n+12 (or n+52 if DRAM refresh occurs, but this is irrelevant since nothing from the CPU can affect the PPU during this time anyway). --- I fixed the input configuration panel. Also switched to Comic Sans MS font for it, so the options are a little bigger. I wanted something that was more widely spaced vertically to separate the entries better... I'll probably have to replace the listbox control with a custom one if I want to make it look really nice, though. Also disabled the hwmath counter updating for now since I've blocked the hwmath behavior until I can find something safer that doesn't break any games. What's your opinion about Battle Blaze and Mega lo Mania? Should I leave these two broken, or revert the Winter Olympics change to get these two working again? Can't have both for now, sadly. The only spot I can cache OBSEL is where you set hclock to in the config file, so it's either cached a line in advance, or not at all. Also, I have an idea for the user interface... I was thinking of taking away the menubar and replacing it with a pseudo-toolbar instead... what do you think? It would have say, 32x32 or so icons (I could even make a "small icons" version). The default buttons would be: Load, Reset, Configuration, About And I would move the rest of the menubar options into the configuration panel. I could also add a toolbar editor to the configuration panel to add and remove additional icons, such as: Unload, Power (hard reset), Mute sound, Capture screenshot, etc The basic goal would be to make bsnes "stand out" a bit more than a plain old boring win32 app, and make commonly accessed features easier to get to. I don't, however, feel like adding this as well as the menubar. It's one or the other. And of course, a nicer file load menu has been on the agenda for a long time now, too. I will allow one to use the default windows file open dialog as a replacement there, though. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 22, 2006 7:18 am Post subject: | |
|
|
|
| I
guess I'm having a difficult time believing that someone spent all that
time making a homebrew and didn't notice a major gfx anomoly like that.
I'll just have to be convinced when I get my flash cart and its staring
me in the face. As for changing the menu and stuff. I'm not for it. I use a lot of emulators and it's nice to have fairly uniform menu bar implimentations across the board. Navigation doesn't need to be pretty or stand out from other emus. I just want simple, well-organized text-based menus, and that's exactly what you've got right now. In fact, bsnes navigation and configuration as a whole is a shining example at this point. Icons in menus look goofy because some options have them and some don't. What would look okay is putting one next to each entry in the cfg white area. SNESGT is a good example of this done right. They use pro looking icons that come stock with windows. Video settings = monitor icon. Color adjustment = monitor icon with the painter's tool. Etc. You'd have to revert back to arial to do this, but I think you should do that anyway... not digging that new font. Battle Blaze and Mega lo Mania can stay broken. That line caching stuff is accurate hardware behavior. The inferior scanline renderer shouldn't compromise its addition. Would it not be logical to use scanline-renderer specific hacks for these games, knowing that there is no possible way to overcome them with a renderer that is a speedhack in itself? By the way. I found another bug today. Touge Densetsu Saisoku Battle (J) - at bike selection screen, choose an option. The game's colors will mess up. happens in all bsnes versions. happens in super sleuth. Doesn't happen in zsnes. |
|
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Fri Sep 22, 2006 8:23 am Post subject: | |||||||||||||
|
|
|||||||||||||
Battle Blaze does not do any mid-frame writes to $2101, so the problem must be caused by the other IRQ timing updates. Assuming that my HDMA timing is correct, Mega lo Mania writes to $2101 at <0, ~1140> and <128, ~1140> while Winter Olympics writes at <127, ~1260-1280> and <225, ~476-500>. In Anomie's timing.txt it says that the PPU uses 256+16+68=340 vram reads per line. My guess is that cycles 72-1096 and 1096-1160 are used for BG reads and RTO calculation, while 1160-72 are used for OAM reads. So in order to fix all games, OAM caching should be done at <V, 1160> and rendering should be done at <V+1, dram_refresh_pos>.
The timing of the polling does have an effect on Mahjongg Taikai II, although nowhere near enough to fix the game. According to the SNES dev manual, polling starts at 18us (48 machine cycles @ 2.68MHz) after vblank and ends 214.55us (576 m.c. @ 2.68MHz) after vblank. This means that joypad reading starts at cycle 48 * 8 = 384 and ends (576 - 48) * 8 = 4224 cycles later, which seems to match Anomie's tests. The manual then states that "Standard CNTRL Enable" (which is $4200 bit 0) cannot be set during joypad reading. Also from the wording it looks like "machine cycle" is the same as "cpu cycle" and not "8 master cycles".
When does this occur? In older versions of bsnes, it is at 534/538. In newer versions it is at 538 for bcpu and 530 for scpu.
Is it possible to trigger 2 NMIs like this?
And finally, is $213E bit 4 PPU1 open bus or is it always zero? |
|||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 22, 2006 2:39 pm Post subject: | |||||||||||
|
|
|||||||||||
Eh, oh well. I'm seriously burning out spending 6+ hours on each of these obscure Japanese games to fix tiny little graphical glitches. It'll have to stay broken.
$4200.d0 is auto joypad read enable. I'm aware there's probably a hundred thousand anomalies involved with toggling $4200.d0 at odd times, reading the joypads during auto joypad polling, with toggling overscan around V=225-240, with the start and end positions of auto joypad polling changing every frame based on the weather in Guatemala, etc etc. I guess I could set the status flag for auto joypad reading to be a little more accurate than just "during scanlines 225-227". I think investigating CPU opcode timing is the next best bet for Mahjongg, maybe there's some big transfer loop that has one of its opcodes timed wrong (missing/extra opcode cycle?).
On CPU revision 1, it always happens at 530. On CPU revision 2, it changes every scanline between 534 and 538, except for the scanline with the missing dot, it doesn't change there. Basically, CPUr2 has something like a separate timer that ticks every 8 clocks. The newer bCPU is probably more than a little broken at this point.
Wouldn't know off the top of my head, and unfortunately I'm out of floppies to test with at the moment.
That's probably the bit that gets set when PPU1 registers aren't read for 40 frames or something like that. I haven't looked into it. By the way, I don't suppose you've looked at Koushien 2, by chance? It looks like the S-SMP is what's crashing (bad opcode?), but I really don't want try and investigate a bug that occurs so far in game without savestates. Hmm, maybe I'll generate a running SMP log that strips out all the register info from each line, that way the log from game start to crash is only 20gb instead of 60gb. |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 22, 2006 4:38 pm Post subject: | |||||
|
|
|||||
Koushien 2 S-SMP log:
IPLROM is disabled ($00f1 = #$03) at this point. spcdas disassembly from SPCRAM dump from ZSNES:
EDIT: dammit! The S-SMP is overwriting code somewhere, but it varies every time you run it. In the above example, it's at $1440. So I set a log for all $1440 writes and only get one. So either I trace back 1.6gb worth of S-SMP log data to locate the stray write to $1440, or I leave this one broken. It would probably be easier to reverify every single S-SMP opcode and its addressing mode stuff to check for page wrapping errors or somesuch that could cause a write to go to the wrong place. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Sep 22, 2006 10:19 pm Post subject: | |||||||
|
|
|||||||
The programmers didn't feel like setting $4356. It just assumes the high byte of DMA channel 5's transfer length will be 0x00. Well, it's not. HDMA occurs on the screen before, with the biker guy talking about whatever. Not just HDMA, indirect HDMA. Which loads the indirect address into the same register used by transfer size. I'm seriously not going to last much longer with this. I think I'll just track down the developers of this game and bash their fucking heads in until they die. After all, Japanese prison has got to be more fun than fixing these games the rest of my life. STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 : STZ $4356 EDIT: more logs for me for when I get home.
ZSNES also has $7e0c6d = #$f0 here, so the HDMA table is correct. |
|||||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sat Sep 23, 2006 4:21 am Post subject: | |
|
|
|
| Hey byuu, I'll give you a US game to look into. Its Pilotwings, and I've noticed an interesting glitch with every emulator I've tried. If you the game play through its various demos, when it gets to the bi-plane landing sequence, the plane will crash short of the runway. On the actual console, the plane lands perfectly. I'm guessing its a timing issue with how the input commands are processed on a real console versus an emulator. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Sep 23, 2006 8:45 am Post subject: | |
|
|
|
| I
hacked the fucking game to pieces and ran it on my UFO until I was able
to log the behavior and figure out what the hell was going on: http://byuu.cinnamonpirate.com/temp/touge.txt Sigh... and before I hear anything else about this godforsaken game, the biker picture with the mosaic effect when you start a new game is supposed to fuck up on three different sections of the screen. I saw the same thing happen on the UFO. |
|
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Sat Sep 23, 2006 7:58 pm Post subject: | |||
|
|
|||
I... seriously... cannot stop laughing... omg. This is candidate for a sig quote. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 24, 2006 4:54 am Post subject: | |
|
|
|
| Good job. That's hardcore. Retested "T" through "Z" of (J) and didn't find anything else. Tested all minority regions and found no problems. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 24, 2006 5:57 am Post subject: | |
|
|
|
| Would
you mind testing S (J), as well? Just so we can say you tested them
all, and in case tetsuo55 missed anything (like Touge). If not, no big
deal. Also, I'm getting quite upset and worn out, but I do definitely want to know of any new bugs you find. Though if indeed all Japanese games have been tested, I'm extremely relieved that I'm almost done fixing these crazy games -- sans regressions, of course. Some more news on Mahjongg Taikai II. I tested latch positions against the real SNES and bsnes. Good news, my timing isn't off by much after all. The game really does write to $4b.d0 during two separate frames, and that does cause the OAM DMA to occur twice. I can disable either one, and the game still works. I found the reason, too. But it isn't a simple fix. It's basically working because OAM address reset is setting the OAM write address back to $0000 again. But it's weird the way it works. The game disables video for an entire frame after the first OAM DMA, and then during the NMI for the second frame, it re-enables the display at V=225,HC=~484. It then performs the DMA at V=225,HC=~766. So, basically, OAM address reset has to be occuring somewhere between HC=484 and HC=766. I had to use 650 to get the stage -and- title screen to work. So, I need to come up with some extreme tests to figure out where OAM address reset happens. Even once I find the exact clock position (or a close estimate, as it probably bounces around a little between frames), there's no easy way to add the reset to that position. The PPU only gets called at HCLOCK=0 and HCLOCK=<config file position>. I don't want to be forced to put the config file variable at ~650 to get this game working, so basically the CPU is going to have to tell the PPU to reset OAM address, which is going to look ugly. Again, this is another good thing for a dot based renderer, but I will add it to sCPU+bPPU for the time being anyway, if possible. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 24, 2006 7:27 am Post subject: | |
|
|
|
| byuu:1, Japan:0 Brand new SNES technical information: 1) OAM address reset occurs at exactly V=225(240),HC=10 if the display is not disabled. 2) OAM address reset also occurs if $2100.d7 (display disable) transistions from 1->0, and only on 1->0 transistions. Not for 0->0, 0->1 or 1->1 writes. This is true during vblank, I do not know if it is true during active display (it probably is), because reads/writes to OAM are unreliable during active display. Note that you can transistion $2100.d7 multiple times, and reset OAM address every single time. While I can't check Super Sleuth because it is closed source, no other emulator implements the second finding (yet). If Mahjongg Taikai II works in any other emulator, it is because the timing is inaccurate by more than 128 scanlines. I've confirmed timing issues allow the game to work in SS and ZSNES, because they have debuggers and I can see where the two $4b writes occur. I have compared emulator latch positions to the game running on real hardware. I'm mostly pointing this out so that other authors don't assume that because the game works for them, that my findings are not correct. Here are two test ROMs verifying the above two findings. The first is test_oamreset.smc for verifying the exact position auto OAM reset occurs. Don't expect this to work in most emulators, due to the use of libclock. Also, ignore the OPVCT/OPHCT output at the bottom of this test, it latches the counters way after reading OAM. I got the timing position of the read from $2138 from bsnes' debugger. The second is test_oamresetm.smc, which verifies the second finding. This one should work in any emulator. http://byuu.cinnamonpirate.com/temp/oamreset.zip EDIT: yeah, ran test_oamresetm.smc on the latest public releases of all active emulators. All of them fail the test. Had to modify the STP instruction to BRA $FE since SNES9x and SNEeSe don't like that opcode. A shame too, it's very useful ;) Last edited by byuu on Sun Sep 24, 2006 8:21 am; edited 1 time in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Sep 24, 2006 8:01 am Post subject: | |||||
|
|
|||||
Yes, I will. And if someone wants to go over mine again, knock yourselves out
Gah, don't even mention the word regression! Horror. We were lucky to have caught the Battle Blaze and hanging Taz-Mania issues. They ended up being pretty rare. However, it was the right time to do all that testing. The emulator had gotten so accurate that the only ones left were these obscure games that did weird shit or somehow got away with sloppy code. But seeing as how regressions do still happen, and given that I can't go back and retest all those (J) games, the best thing you can do is fix what you can before I start with (E) and (U). Because as long as there's 1000+ games for me to test, you still have an opportunity to test the durability of recent fixes. That's the smart way to do it, but there's no timetable here. I probably won't even get to (E) and (U) games for at least another month. Edit: wow, just saw your last post. Awesome news. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Sep 24, 2006 2:21 pm Post subject: | |
|
|
|
| Wow great news Byuu, thanks to these horrible games you found some unemulated stuff and were able to make new tests Ive also started with S, but yes they are on hold for now, i will be able to continue testing in about 2 weeks anyway i started from the top alphabetically sorted, so maybe fitzroy can start S from the bottom up? i have not found any bugs yet that are not caused by the missing BS emulation. I still think BS simply has a little more ram to play with |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Sep 24, 2006 8:35 pm Post subject: | |||||
|
|
|||||
Unfortunately, it's not a very big finding. It only fixes one known game thus far, which is undoubtedly why nobody's ever noticed this behavior before. I'm hoping though that this is part of the puzzle with Uniracers, which is still broken.
BS has a lot of stuff. There's at least one document explaining a lot of the stuff in vague detail. I'd want a real BS I could run test code on before I started trying to emulate it. Same for non-bit-accurate special chips (SFX, SA-1, SPC7110, etc), I want hardware to test on before I waste my time. Running BS games by themselves is a hack to begin with, you need that BIOS and all of that to setup the system first. I probably won't ever support direct loading of BS games. If they load directly anyway though, great. By the way, I killed the debugger since I know I'll never get around to it again. There's a tracer+console+memory editor there now instead, and this will be enabled even in public releases. There's no DEBUGGER variable, so the 10% speed hit with debugging enabled is now gone. Sorry to those who wanted a powerful debugger. It's too hard to keep the emulation code clean and maintain platform-specific debuggers that need to hook as many things as one needs control over. Perhaps one day when emulation is more complete, I can add a more full-featured debugger like bsnes v0.013. I also plan on making the tracer far more useful, allowing logging of hardware edge cases, DMA/HDMA transfers, etc. |
|||||
New Member
Joined: 20 Sep 2006
Posts: 2
| Posted: Sun Sep 24, 2006 9:23 pm Post subject: | |||
|
|
|||
MESS has a powerful debugger. You and Arbee could cooperate on improving that SNES driver instead...
|
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Sep 25, 2006 6:48 am Post subject: | |
|
|
|
| If anyone is interested: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=8286480888 _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 25, 2006 7:18 am Post subject: | |
|
|
|
| Holy fuck, $320 with shipping for a system you can't even use anymore >_< Well, I guess it's safe to say I won't be picking one of these up. And no one else should either. That's a horrible ripoff. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Sep 25, 2006 7:36 am Post subject: | |
|
|
|
| There are some cheaper ones available: http://search.ebay.com/search/search.dll?satitle=satellaview _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Hazed
Joined: 17 Sep 2004
Posts: 94
| Posted: Mon Sep 25, 2006 7:42 am Post subject: | |||
|
|
|||
http://users.tpg.com.au/advlink/dsp/dsp1.html#OP28 |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 25, 2006 6:53 pm Post subject: | |||
|
|
|||
Well, perhaps some day then. I don't even know if I'll be able to run my own code on it. I'd probably have to figure out a way to dump/flash the little addon carts first. Could possibly do it with a BS-X cart connected to a GDSF7 that allows passthru of the cart flashing registers. Who knows. Here's a mockup of my potential alternate cart loading screen:  Ideas? The default is still going to be the windows file open dialog, and this one will only have carts added to the database. Not sure if I'll add a scan button to only show available carts, or just do a scan at each startup, or something else like that. |
|||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Mon Sep 25, 2006 6:58 pm Post subject: | |
|
|
|
| you are adding a rom library to bsnes? oo-err _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 25, 2006 7:47 pm Post subject: | |
|
|
|
| "oo-err"?
I'm not including the ROMs, and only adding official releases to the
textual database. I already require the database to determine the PCB
for memory mapping purposes, so this is really just a glorified
frontend to that database. Why, does that seem to go against my goals of writing a hardware emulator or something? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Sep 25, 2006 7:54 pm Post subject: | |||
|
|
|||
Yes. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Mon Sep 25, 2006 8:03 pm Post subject: | |||
|
|
|||
http://www.futurlec.com/Transistors/C9015.shtml This may not be your exact C9015, however, the pinouts for TO-92 package transistors are generally the same. Ok.. Still not quite right. I happen to have found a schematic online for doing exactly what you want to do using an NPN transistor. I couldn't find one for PNP. And as I said, I have no means to draw one for you aside from paint or something and well I suck at that. Since pictures speak louder than words: http://www.kpsec.freeuk.com/trancirc.htm#sensors That's exactly what you're doing with some decent explanation of what's going on. You don't need the variable 10K as it shows. You can use the resistance values you have. The variable resistor would just allow you to adjust the sensitivity of the LDR. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Sep 25, 2006 8:28 pm Post subject: | |||||||
|
|
|||||||
Saw that, I'm working on a PNP version of this. I still can't believe it was done with an NPN. The only part of that I don't understand is when that circuit has light, the energy should flow from 0v to the LDR, where it passes through, but then it goes right over the intersection in the middle to the top left of the circuit through the resistors, then to the right to +9v. Why doesn't the current still flow from 0v to the NPN emitter, through the base, and enable the transistor flow from emitter to collector, thus turning on the LED in both cases? Personally, I found the explanation on that page extremely lacking.
Well, I guess I'll have to contradict myself, then. The memory mapper info stored in carts may not be part of the hardware, but until cartridges start storing that info in them, I've no choice. If you can store all needed info in the 512-byte ROM headers (cart name, region, special hardware, PCB ID, genre, year, etc) then I can just use that instead. Until then, however... |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Sep 26, 2006 11:12 am Post subject: | |
|
|
|
| Did some more testing(in the newest wip ofcourse), found a real bug i think Ranma Nibunnoichi - Chounai Gekitou Hen (J).smc > interlacingproblems all over the place and probable some missing hardware bug Same Game + Tengai Makyou Zero Jikei - Data Pack (J).smc > black screen, special hardware? Byuu, i like that cartridge loading menu good work |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Sep 26, 2006 1:02 pm Post subject: | |||
|
|
|||
Last I checked only ZSNES supports dual cart games such as Sufami Turbo, Same Game, and SD Gundam GX. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
New Member
Joined: 31 Aug 2006
Posts: 4
| Posted: Tue Sep 26, 2006 1:36 pm Post subject: | |
|
|
|
| Ranma Nibunnoichi - Chounai Gekitou Hen (J).smc > interlacingproblems all over the place looks correctly for me, atleast a lot more correctly as in zsnes edit: works correctly with the old grafigengine in zsnes without interlacing |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Sep 26, 2006 3:19 pm Post subject: | |
|
|
|
| Nach, the none datapack version do run however are those singel cart, or merged or hacked? dragoonmaster, which version did u use? |
|
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Tue Sep 26, 2006 3:20 pm Post subject: | |||||
|
|
|||||
The current that enters the base is based on the voltage drop of LDR. Basically, you've got a voltage divider between the resistor and LDR. Assume LDR is 1MegOhm when there is no light. When there is no light, the resistance of LDR is very large as opposed to your 10K, therefore most of the voltage will be dropped across LDR which in turn is high voltage at the base. If LDR is 100Ohms when there is much light, it is much smaller than the 10K and therefore the voltage drop across LDR will now be very close to zero or ground which in turn is practically ground at the base. YES, there IS current to the base in BOTH cases, however the current is so small in one, it is not enough to turn the transistor on. Transistors have a rated base current or voltage to turn the transistor ON. Check out Wikipedia for more in depth information on transistors. They are probably one of the most complicated components in electronics, yet are simple at the same time. http://en.wikipedia.org/wiki/Bjt As for using the PNP. I had a few spare minutes today and some extra parts at my desk, so I constructed the circuit to refresh and make sure I still knew what I was talking about. I made the circuit and it worked perfectly using a PNP transistor. THIS is what I did: 1. Positive Battery terminal goes directly to the EMITTER. 2. Positive Battery terminal also goes to LDR. 3. The other end of LDR goes to the BASE. 4. The COLLECTOR goes to a resistor(R1 for LED). 5. The other end of R1 goes to the anode of the LED. 6. Catchode of the LED goes to GROUND. 7. Ground also goes to a second resistor R2. 8. Other end of R2 goes to the BASE. Behold my mad MS Paint skills. It looks something like this:  _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Sep 26, 2006 4:26 pm Post subject: | |||
|
|
|||
This is on my "to verify on hardware" list. One of the interlace fields seems to persist rather than disappear during transitions, but I'd hardly call it "all over the place." Maka Maka is another one. Correct non-GoodSNES name - Ranma One Half - Chounai Gekitou Hen (J) |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Sep 26, 2006 4:56 pm Post subject: | |
|
|
|
| There
might be some issues with the video blitter outputting the interlaced
scanlines... simulating interlace on a progressive monitor is easier
said than done. But this is certainly not an emulation bug. The game
does enable interlace, despite not using a "hires" mode to take
advantage of it. The developers probably thought they were clever
eliminating the "scanlined-look of the display" by enabling interlace,
but they just resulted in making the video twice as choppy, even on the
real system. Note that to save speed, I only draw to the currently active "field". If the game turns off the display AND interlace at the same time, then bsnes would not erase the odd fields. I could make it do this if nobody minds a 40% speed hit in hires video games. No, I'm not going to write hackish code to detect screen enable and disable to clear both lines. Unless monitor manufacturers start including native interlace modes, the best I can do is add options to forcefully disable interlacing in 224-height modes, or implement some sort of 30/25fps interlace frame blending filter. |
|
Rookie
Joined: 17 Aug 2006
Posts: 12
| Posted: Wed Sep 27, 2006 6:16 am Post subject: | |||
|
|
|||
Hmm... That reminds me... When I was 10, I built a small device using a schematic I found in a book in the library. They called it an "electronic rooster". It basically made noise when light hit it. I distinctly remember driving all over hell and creation to find a "light activated transistor". I can't remember if it was PNP or NPN but it sure was a bitch to find. It looked like a normal transistor but the top was transparent. I remember that the circuit was really simple and used a 9 volt battery for power. It used a small standard speaker for sound because I don't think that piezo speaker devices were common yet. EDIT: I just found some interesting circuits here... http://www.michaelsharris.com/electronics/week3/transistorSwitches.htm |
|||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Wed Sep 27, 2006 2:01 pm Post subject: | |
|
|
|
| Somewhat off-topic: http://www.intel.com/cd/software/products/asmo-na/eng/294797.htm "Thread like an expert, without being one. Intel® Threading Building Blocks 1.0 is a C++ runtime library that simplifies threading for performance. It provides parallel algorithms and concurrent data structures that eliminate tedious threading implementation work. It's a tested and performance-tuned parallel substrate for your application. "Introduce threading that unleashes the performance of multi-core platforms. Write applications once and deploy on multiple OSs. Intel® Threading Building Blocks enables your application performance to scale as the number of cores grow." How does this compare to libco? |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Sep 27, 2006 2:41 pm Post subject: | |||
|
|
|||
I don't believe in merging. Hence NSRT's -split option. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Sep 27, 2006 3:12 pm Post subject: | |||||
|
|
|||||
Sigh. 1) Intel's library is preemptive. Includes stuff for mutexes, semaphores, critical sections, all of that shit. Mine is cooperative, there's only one thread as far as the OS is concerned. You can think of cooperative as having multiple stacks. In fact, that's all I do. Allocate a new stack, then to switch cothreads, switch the stack pointer and push/pop volatile registers like a callee typically would. 2) Intel's library is ridiculously priced, mine is public domain. You can do whatever you want with mine for free. 3) Intel has developers that are paid to improve and port it. I'm the only one who would ever work on mine for free. So no doubt, Intel's works on more platforms.
Yeah, I really need a multi-file loader system in place, so I can load "multi-file" games like SameGame and Sufami Turbo. |
|||||
Rookie
Joined: 08 Oct 2005
Posts: 18
| Posted: Wed Sep 27, 2006 3:52 pm Post subject: | |||
|
|
|||
Price tag aside, Intel's deal seemed like a lot of PR and little substance. Sorry to threadjack, I certainly didn't want to suggest anything that would be discouraging. The libco page is pretty straightforward and honest, and based upon the results from bsnes it's working. Maybe I'm just old-fashioned, but I'd rather trust somebody who is open about his work than some faceless company with flashy PR, and it's always really inspiring to flip through your WIP stuff. Thanks. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Sep 29, 2006 4:02 am Post subject: | |
|
|
|
| Got
my tototek kit in the mail today. Unfortunately, I couldn't find my
bloody snes power adapter. I have a universal, but none of the plugs it
came with are big enough Ordered a replacement on ebay which should hopefully come in next week. I'll probably test the (J) S games this weekend. There's a huge college football game this saturday and my city is going to clog to a stop. So it's either stay inside or brave the drunken mayhem. I was thinking about audio options the other day. I think it would be a good idea to add sound channel disable/enable checkboxes to the "emulation settings" area. Reason being, what if someone wanted to record audio, but just sound effects or just music, and the game had no sound test. SPC isn't always an option - Lord of the Rings anyone? Otherwise, I see no need for an audio section or other audio options. The ability to choose worse/less accurate interpolation options is complete bloat. Frequency selection gives you the ability to increase your sound frequency, which has NO tangible benefit. Reverse stereo? Uhhhhhhhh... drawing a blank. Someone have their speakers plugged in wrong? |
|
Inmate
Joined: 26 Sep 2004
Posts: 1637
Location: Place.
| Posted: Fri Sep 29, 2006 4:16 am Post subject: | |||
|
|
|||
Heh, actually I found this useful back when the most convenient placement for the speaker connected directly to my PC was actually on the wrong side. I've never been able to find an option like that in windows. _________________ Procrastination. Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Sep 29, 2006 4:23 am Post subject: | |||||
|
|
|||||
I forget if it was related to the sound card and/or speakers.. but such an option was needed back in the day. _________________ FF4 research never ends for me. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Sep 30, 2006 4:50 pm Post subject: | |
|
|
|
| Sooo, laziness and vague recollections of past importance. I'm totally for it now! |
|
Lurker
Joined: 08 Nov 2005
Posts: 106
| Posted: Sat Sep 30, 2006 6:21 pm Post subject: | |
|
|
|
| I seem to remember that the volume control was on my left speaker once, but I wanted it on the right side of my screen where it was easier to reach... that was the only time I can think of that I used reverse stereo. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Sep 30, 2006 6:46 pm Post subject: | |
|
|
|
| You're going to need to post a picture to tell me what you mean. What kind of wonky setup would absolutely force you to place your left speaker that much farther away than the right? | |
Redneck Gamer-Mod
Joined: 04 Aug 2004
Posts: 1126
Location: Pittsburgh
| Posted: Sat Sep 30, 2006 7:16 pm Post subject: | |
|
|
|
| I
have an ultra-ultra-ultra cheap PCI soundcard "asound 120" or
something, that outputs reversed audio all the time. Probably a driver
typo or something; even the balance in mixer is wrong. _________________ SHREIK!!!!!!! DDdddnnnnnnaaaa! GESTAHLLLLLLLLLL!!!!!!!! Steelers no longer officially own your ass. Pittsburgh will miss The Bus. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Sep 30, 2006 7:25 pm Post subject: | |
|
|
|
| Fitzroy,
a Reverse Stereo option is rather harmless for emulation.. it does help
those people that need it though (it's not like the option harms sound
emulation in any way). I wasn't being vague earlier, but I remember a number of DOS games that deployed such an options in their sound tests. It was problematic back in the day, and there are still reminences of it in today's hardware setups. Even though 95% of the time, you will never need to use it.. this option is relatively helpful for some. _________________ FF4 research never ends for me. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Sep 30, 2006 8:52 pm Post subject: | |
|
|
|
| I
disagree. When we see the people who "need" this option, we see far
better solutions. If you're using a sound card that is so old and is so
bad that the drivers can't even separate the stereo channels correctly,
guess what the best thing to do is? No, it' isn't asking all the
authors of programs you use to add a software option because you belong
in the 1% of the population who is so incredibly cheap and lazy as to
not want to spend $10 to get a decent soundcard. It's not harmless, either. The more useless options you add to your emulator, the harder it is for people to find what they really need, and the more confusing it becomes to new users. Once, it might seem so. Then comes the frequency selection by the same token. Then the sound buffering. Then hey, while we're at it, let's make our emulator seem even more powerful with interpolation selection. Add a clock... a little calendar... some nice snow effects and a rubber chicken that dances across the screen because, you know, that's harmless, too. C'mon... |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Sat Sep 30, 2006 9:33 pm Post subject: | |||
|
|
|||
i call BS. it's all in the GUI whether extra options confuse or not. zsnes executes flawlessly here. and no matter how streamlined the gui is, or how stripped and basic your program is, you'll still always have someone who can't figure out how get a game of FFVI started. i personally like to have a choice when it comes to configurations in any program. even if i don't make use of them, the fact that the choice is there is appreciated. _________________
|
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Sep 30, 2006 10:10 pm Post subject: | |
|
|
|
| I'd
also argue Sound Buffering is still useful.. but obviously "it is
useless" even if mainstream (including the high end) cards at times may
not simply work unless such a setting exists.. I guess all "sound card
assisting features" that "don't change emulated sound output" are
completely useless huh? sweener2001, I'm sure we will get another of those posts before the end of 2006. _________________ FF4 research never ends for me. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Sep 30, 2006 11:57 pm Post subject: | |||||||
|
|
|||||||
That's defeatist reasoning. Should we stop teaching people to use condoms because there will always be kids who don't listen? The idea here has always been about reduction, and doing what we can. Eliminating all user confusion is impossible, but when it comes to the GUI, we can do something to alleviate it. We can make it better without "stripping it" or "dumbing it down" simply by removing UNNECESSARY OPTIONS that nobody WOULD/SHOULD be using. ZSNES is wrong on this. Period.
I'm glad you're not writing the emulator then, because if you're the type that would appease every idiotic request, I would vomit at the download size, the source code, and the overall wading through useless stuff given the same precendence as the useful. @Deathlike: sound buffering may indeed be useful still. But I wonder if this addition has more to do with a program's shortcomings in its code than sound card drivers. None of my PC games, for example, have buffering settings, but work perfectly. |
|||||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Oct 01, 2006 12:17 am Post subject: | |||
|
|
|||
I believe that has more to do with how the SNES audio has to sync with the picture you are seeing.. and that is vastly different than normal games that play their audio. The problem with this method is that some audio cards aren't exactly friendly to this. _________________ FF4 research never ends for me. |
|||
Inmate
Joined: 26 Sep 2004
Posts: 1637
Location: Place.
| Posted: Sun Oct 01, 2006 1:04 am Post subject: | |||
|
|
|||
The cable that goes into the main speaker isn't long enough to have it reach the proper side of the monitor from where the PC is standing, as opposed to the secondairy speaker which is only connected to the main one via another cable. Do you really need a picture for that? >_> I don't care about the option now (and I'm not gonna get into this argument about which options should exist) but back then it was pretty damn handy whether you ridicule it or not. _________________ Procrastination. Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 01, 2006 1:37 am Post subject: | |
|
|
|
| To be honest, as much as I dislike the GNOME mindset, I actually do think minimal options work good when done right.
GNOME just so happens to take it too far and think simplifying things
back to 1993-levels is a good thing. XFCE is a good example, though.
Every option that you need is there, nothing is missing that I'd want.
Takes about 5-10 minutes tops to fully configure the entire system. I don't mind adding options like reverse stereo if someone really needs it, but I won't add it to the GUI. I think a good mindset would be, add useful options that more than 50% of people would use to the GUI, and add the rest to the config file. If you need reverse audio, search for "settings.reverse_audio" and set it to true. I already have a few such hidden options in the config file, such as CPU<>APU clock execution rates, PPU render position, etc. Now, frivilous things like cubic spline and 8-point filtering, I will not be adding. It isn't accurate, and it breaks sound effects in some games. We know the SNES uses gaussian, and that's all I'm personally adding. By the way, anomie found the proper HDMA fix for Touge Densetsu. I'll be adding that when I can. I'm also considering reverting the HDMA fix for Jumbo Ozaki no Hole in One. I just don't feel comfortable with it. Mahjongg Taikai II showed that there were some semi-important timing problems elsewhere, so I think I should leave this game broken until I find out where those timing issues are coming from. I can't verify the Ozaki fix because my HDMA timing lacks DMA bus sync code. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 01, 2006 1:54 am Post subject: | |||||
|
|
|||||
For the last time, the solution is not requesting that programs add an option to account for your external problem. Guess what the REAL solution is, that will not only enable you to hear correct separation in bsnes, but EVERY program on your computer. Buy a $5 extension cable. It's that simple! I can NOT BLOODY BELIEVE the resistance I am meeting with this. |
|||||
Inmate
Joined: 26 Sep 2004
Posts: 1637
Location: Place.
| Posted: Sun Oct 01, 2006 2:38 am Post subject: | |||||
|
|
|||||
_________________ Procrastination. Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. |
|||||
Devil's Advocate
Joined: 02 Aug 2004
Posts: 3321
Location: Hillo. Son. Mx.
| Posted: Sun Oct 01, 2006 2:55 am Post subject: | |||||||
|
|
|||||||
I can't BLOODY BELIEVE some people can't even read. _________________ *Sometimes I edit my posts just to correct mistakes. I DON'T PLAY ON NETPLAY, DON'T ADD ME TO YOUR MSN TO ASK ME STUFF, I JUST PLAY ON MY LAN, HAVE A QUESTION? ASK ON THE BOARD. |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 01, 2006 2:59 am Post subject: | |
|
|
|
| Sigh. Back on topic, I've added a buglist to my bsnes page. No reason to stop maintaining yours FitzRoy, as it will probably be updated a lot faster. The main reason is just so that people who don't read this board will know which bugs to expect. And it also has more detailed information (severity and cause). Also notice the reversion of the Jumbo Ozaki fix. I took it back out for now, as I'm not happy with it, and I recently remembered that this was the cause of Energy Breaker splash screen flickering. I am now happy with the Touge Densetsu fix, so there's not much need to monitor that one in the future if you don't want to. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 01, 2006 4:39 am Post subject: | |||
|
|
|||
I flipped out a bit, but that wasn't your entire post, and it's not just you. Impossibly shitty sound card was another excuse in reverse stereo's favor, and I had to waste time explaining that this was something that you people need to fix, and not program authors. Again, this was something I thought was obvious, so I think I was just frustrated that two people offered their positive view on the option, but never showed themselves willing or aware of fixing it themselves for little cost. @byuu. That's a good idea. I take it you don't want to mess with having a forum? |
|||
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Sun Oct 01, 2006 8:07 am Post subject: | |
|
|
|
| i
never said that every single option anybody would ever try and request
needed to be added. but i will concede that my logic was faulty in that
chunk you quoted. users have an option for a visual filter and color palette, but when it comes to sound, they're refused? you can't argue for minimalism and streamlining for only half of the experience. my argument was that if the gui is configured properly, nobody with half a brain will get confused by the options offered. clutter and confusion is not your real reason for being against it. you just don't feel it's necessary. there is a difference there. i fail to see how the source would all of a sudden become a mess to read, just because there are more options. do you just assume that someone who adds extra options into the gui is a sloppy coder? i also fail to see how an executable that is a few KB bigger hurts anyone, especially today. if you're against an option because you feel it's unnecessary, that's fine and dandy. before you get all uppity and "flame" me, just realize that i never disagreed with you on people just needing to get newer hardware so that devs can code easier. i wasn't defending the guy trying to play with his 10 year old box. my point was that a choice is nice and appreciated(like whether i want the ntsc filter, or hqx), and that a well-configured gui can basically eliminate confusion. respond to this if you want, i won't be derailing this thread anymore on this subject. _________________ |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sun Oct 01, 2006 8:30 am Post subject: | |
|
|
|
| Hmm,
sorry to break in out of nowhere, but I had a little something to say:
quite weirdly, I no longer have those gamepad problems with SMK, yet
I'm still using v1.7 and didn't change anything. o_o Good thing, anyway. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 01, 2006 8:35 am Post subject: | |
|
|
|
| I
have gamepad problems when my USB floppy drive is connected. No idea
why. I sincerely doubt it's my code, since the Joypad control panel
applet doesn't recognize input, either. http://byuu.cinnamonpirate.com/temp/ups_100106.zip Format is subject to change, still. But this is pretty much near finished. Right now, the patcher is command-line only, and there are no subformats. I don't suggest using this for any releases, but if anyone wants to try out creating and applying patches, then by all means... I intend to have this out in time for bsnes v0.018, which will support soft-patching with the new format. The license will probably be near public domain, with the only rule being that no modifications to the file format are allowed, for the sake of compatibility. Included is a sample patch for Tekkaman Blade (J)->(E). EDIT: fixed disk I/O mode. use create_d or apply_d to access files from hard drive if you are making a patch from files that are larger than your available physical memory. Expect these modes to be much slower than create and apply for obvious reasons. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Oct 01, 2006 10:05 am Post subject: | |||||
|
|
|||||
Noone was suggesting that it should/must be added, but rather why it has existed and still has value. It's like arguing against Triple Buffering because your system (specifically video card+cpu combo) should be able to handle BSNES. On the other hand, patches other than DMV27 submitted to byuu have fallen on deaf's ears at times. However, for you to say the following is appalling.
Source code growth is only as horrible as the code that is used to implement said feature. With that said, adding filters will induce a greater code size than reverse stereo, but with the same line of logic.. I could suggest that the removal of the cheat code feature if I disliked cheating. There's nothing we can do if you do not benefit from a feature.. noone is forcing byuu to enable/include/add/disable/remove/delete it. It is still worth debating the merits. </end rant> _________________ FF4 research never ends for me. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 01, 2006 10:29 am Post subject: | |||||||||||
|
|
|||||||||||
So you admit that some options don't deserve to be added, but you make no mention of where you draw your line.
Here is where your lack of a line comes back to confuse me. You're basically putting video filters and reverse stereo in the same camp here to defend the latter. You also seem to be saying that since video and sound are equally important, that somehow that makes sound preferences necessary in light of all the video options. But that's not a given. Reverse stereo, for example, is a workaround for 1/1000 of users who are afflicted with a self-resolvable issue and are too cheap/lazy to do it. It's not a preference by any stretch.
It's not so much about the confusion when you're only talking about the one. But when you add something that undeserving, and you've got a whole new sound section to fill out, everything else would probably come with it. And don't forget, now that an utterly useless option is in there, users can use that to argue for new ones by comparitive worth, and win.
If you say "I call BS" to a well-thought out, detailed, and irrefutable post, naturally I'm going to get a little hostile. I don't disagree with you that video filters are nice and appreciated. Lots of people use them and there is a clear discrepency between their usefulness and the usefulness of reverse stereo or a rubber chicken dancing across the screen.
Contrary to what others might think, we are technically talking about something that should or shouldn't be added to bsnes. Besides, it's hard to derail a thread this all-encompassing. And if byuu feels differently, and wants to add an audio section with the stuff to fill it out, I'm not going to go on a tear. I would have done so already with the inverse colors option *what? you mean you don't want to see what the snes looks like as The Predator?* @Deathlike: the source code comment was to say that if EVERY option asked for was gotten, not just Reverse Stereo. |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 01, 2006 10:50 am Post subject: | |||
|
|
|||
Like most of my bugfixes sent to the ZSNES team that are in SNES9x SVN the same day? I always add DMV27's patches because they have all been very useful and appreciated. I'm mostly focused on core emulation, and that is what he has helped me fix. I try and add as many patches as I can even still. The only patches I haven't really added are some of kode54's, such as 7-zip+RAR (due to the formats being stupid and placing additional licensing burdens on my source code), WaveOut support (DirectSound works just fine for 100% of people so far...), and a few minor things due to there being far too many changes. He releases his own custom builds anyway, so what's the problem there? And then bisqwit's libco_amd64 port. I didn't add that, once again, for licensing reasons. That is a separate project and it is public domain only. Anything else is just due to time. I have a lot going on in life. My hobbies include: programming, emulation, translation, learning foreign language, electrical engineering and music; I sleep too much and I work full time. |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Oct 01, 2006 11:10 am Post subject: | |||||
|
|
|||||
I never said they were unappreciated. On the other hand, I don't think it as simple a matter as you suggest (I dare not touch the core/rendering for the most part because of unfamiliarity). _________________ FF4 research never ends for me. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sun Oct 01, 2006 12:03 pm Post subject: | |||||
|
|
|||||
patches or just general data on how to fix the bug? Not all of us can interpet your data or if we can, it may not be so easy to implement. Rejecting a working patch though is an entirely different matter. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sun Oct 01, 2006 1:11 pm Post subject: | |
|
|
|
| Hey byuu, I think it would be cool to have the emulator auto-revert to window mode when you hit escape in fullscreen. The way it is now, I have to "set as active" each time I want to go back to window mode to tweak some video settings. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 01, 2006 1:28 pm Post subject: | |
|
|
|
| Esc does switch to windowed mode when in fullscreen. If you're not using a WIP, maybe you're just not understanding how switching works between the two in the last release... | |
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Sun Oct 01, 2006 6:03 pm Post subject: | |
|
|
|
| AS An aside, reverse stereo is only valid in a DOS port. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sun Oct 01, 2006 9:19 pm Post subject: | |
|
|
|
| I am using a wip, but what happens when i hit escape is the only thing that I see on the desktop is the configuration screen. I have to go into that and set window as active to see the game display. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 01, 2006 9:36 pm Post subject: | |
|
|
|
| Sorry, I don't have that problem on any of the four computers I've tried bsnes on, so I wouldn't know how to fix that. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 02, 2006 3:14 am Post subject: | |
|
|
|
| "S" (J) games that don't begin with "Super" tested. 1 bug found. *Street Racer (J) - track area flickers to wrong coordinates. Does not occur in .016, but does occur in all .017 versions. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 02, 2006 3:35 am Post subject: | |
|
|
|
| Congratulations on finding the 832nd reversion due to sCPU. If and when I ever get sCPU caught up to bCPU, you can bet I'll never be rewriting that code again. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Oct 02, 2006 8:14 am Post subject: | |
|
|
|
| But we still think youre doing an awesome job byuu I read some awesome news on nesdev, blargg has finally started on the pal nes timing tests hopefully soon we will have a pal and pal60 filter |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon Oct 02, 2006 8:41 am Post subject: | |
|
|
|
| I figured out what's causing the problem byuu. In my windowed mode in bsnes, I have a manual screen res set of 1024x896. My fullscreen mode is also set to the same res (I use powerstrip to add custom res modes to my video card). When I escape out of fullscreen mode, this display is invisible and I have to "set as active" for it to become visible. If I uncheck manual res and use one of the default res multipliers, the problem stops. Conversly, if I change my fullscreen mode to a standard res, the problem also stops. | |
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Mon Oct 02, 2006 3:42 pm Post subject: | |||
|
|
|||
User error. no bug filed. bug closed. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 02, 2006 4:59 pm Post subject: | |||
|
|
|||
To those of you who don't think cycle/bus accuracy is needed for SNES emulation... here is yet another example of a game that fails when it's off by more than 4 clock cycles. HDMA triggers on the first opcode cycle edge where HCLOCK >= 1106. HDMA bus sync then begins, and one last CPU opcode cycle is executed. This puts HCLOCK at 1112 - 1118, depending on the next opcode's memory access speed. With sCPU not having HDMA bus sync timing, it performs the HDMA at 1106 each time. This 6-12 clock difference causes the track to flicker. However, if you always execute HDMA at HCLOCK >= 1118, the problem goes away. But then you have new problems in other games because you might not have enough time to complete HDMA transfer before hblank ends. So you need to at the very least, delay HDMA transfer for one CPU cycle after it begins. I don't really know how this could happen, since 1106+ is hblank anyway... and the screen redraw happens at HCLOCK=256 on the next scanline. I didn't disassemble any of the game code to see what it was doing. I had a feeling it was related to HDMA bus sync timing, and I was right. I'll try and add in HDMA bus sync timing tonight, and hope it doesn't break Wild Guns like in bCPU. |
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Mon Oct 02, 2006 5:36 pm Post subject: | |||
|
|
|||
Incorrect. It is either an error in how the video card reverts from a custom res, or how the emulator does. I made no error at all because the emulator ALLOWS for custom resolutions, not to mention the fact that my custom res works perfectly fine, its only on escape that the window version comes up invisible and has to be reset as active. Thank you for being a jerk. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 02, 2006 6:30 pm Post subject: | |||||
|
|
|||||
|
Battle Blaze (J): Correct:
Incorrect:
My recent tests indicate that toggling HIRQ from $4200 triggers another IRQ. Battle Blaze suggests it doesn't. That, or there's something evil about the HIRQ occuring at HPOS=0. My code doesn't handle the 14-clock delay between the IRQ timing and core timing very eloquently. I'm obviously missing something as Overload seems to have it right in SNEeSe. |
|||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Oct 02, 2006 6:31 pm Post subject: | |||||||||
|
|
|||||||||
I'm not sure what licensing burdens you speak of. If I recall, 7-Zip falls under the LGPL, similar to SDL which you already use. The UnRar source code is under an even looser license, which is basically "Do whatever the hell you want, as long as you don't try to reimplement the compression utility." I also added compile time options for disabling them.
My latest mess of changes does not include WaveOut support. I only use it in my own emulator because it, like kernel streaming, supports outputting variable sized packets, in case the emulator should ever decide to vary a frame by one or two samples. That wouldn't really matter, except that I also use the sound output for speed regulation, and I want it to wait on whole frames, no matter how many samples a frame may be. It's probably easier for DirectSound code to just Sleep(1) until the buffer has at least N samples free for the next frame or so worth of audio.
The only other useless change I can think of is using an OLE object to import that JPEG logo. Since I don't even use OleInitialize/CoInitialize or whatever before importing that IPicture object, I'm not even sure what the problem is, other than maybe going to way too much trouble just to keep your old About dialog background. Although I suppose it could be further trimmed to unload the OLE crap as quickly as possible, by copying the bitmap from the IPicture to a newly created offscreen bitmap instead of keeping it resident. It may even be possible to dupe or increment the reference count on its HBITMAP, but I doubt it.
All acceptable. Especially considering that none of my changes affect the core. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 02, 2006 6:59 pm Post subject: | |
|
|
|
| I
decided that the about image was too much effort, and even as a JPEG it
was adding to filesize. So there was no reason to keep it. I'm not big
on OLE for the same reasons I'm not big on MFC. It's more my own
personal dislike for them more than anything rational. No big deal, the
new about screen looks fine, and uses the already included icon on it
at 48x48. Looks really sharp. I don't know who drew that old picture
anyway to give proper credit or ask permission to use it. Ok, then the licensing of RAR and 7-zip don't bother me. But I'd rather not add them for a few other reasons: - size. adds to source code size and executable size. adds to the former regardless of compile-time flag, and I'd have to turn them on for official releases anyawy, otherwise what's the point of it being there? - annoyance. I don't like the formats, and I already support ZIP. I don't want to encourage people to uses 7-zip and RAR, and start bugging other emulator authors about why they don't add these formats since bsnes has them. - more annoyance. the only reason people care about even more compression is because they're trying to hoard the entire GoodSNES set, and are too stupid to realize that the 1GB of space savings max equates to about ~$1 worth of hard disk space, or 30 cents more worth of DVD-R space. and since this is primarily used for the sake of distributing ROMs, it would look bad for emulators to support them. I feel the same way about ZIP, but I gave in because literally everybody has their ROMs in ZIP format. at least ZIP has been around for 10 years or so already. WaveOut stuff... yeah, Sleep(1) works really well, and doesn't cause any issues on anyone's system so far. It just seems good enough. I could always add the WaveOut / DSound Notification stuff as derivative audio wrappers (eg has its own derived Audio class). Then the user can select the playback device they like from the config file. I just saw no reason to add these two to my main audio playback since it works pretty good in nearly all cases so far. There's also the ctrl+alt+delete fix you added for D3D that I need to add in there. It's on my backlist of things to do. I have about 300 of those to work through at this point x.x Anyway, I don't want to seem unappreciative of your help. You're one of three people who have actually submitted code to me. Power of open source, indeed. I'll try and add as many of your contributions as possible. --- Side note, I verified DMV27's finding. Mega lo Mania is due to Winter Olympics fix. It's either one or the other until the dot-based renderer. That leaves us with: Battle Blaze (J) - horizontal line issues on title screen - IRQ issue. Not sure if I can fix this, but I'll try. Jumbo Ozaki no Hole in One (J) - name screen gfx corrupt - Timing issue. Also not sure if I can fix this. Koushien 2 (J) - sometimes the sound stops and game hangs - S-SMP opcode error? I doubt I can fix this, it happens way too far into the game with a log file >2gb in size. Occurs at different times during each run, as well. Mega lo Mania (J, E) - horizontal line issues during intro - need sPPU. Street Racer (J) - track area flickers to wrong coordinates - I can most likely fix this by the weekend. Uniracers (E, U) - 2 player mode issues - need sPPU. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Oct 03, 2006 3:58 am Post subject: | |
|
|
|
| Got
the adapter. All kinds of testing going down up in here. Checked on my
possibles list first. Miraculously, no new bugs were found. First we have the "leftmost vertical line appears black/transparent" issue. This was the most prevalent on my list, and usually occured when some kind of text box was using a transparency. Just a few of many games showing this: *Captain Tsubasa IV (J) - ingame when bottom map shows up *Doraemon 3 - Nobita to Toki no Hougyoku (J) - intro *Popeye - Ijiwaru Majo Seahug no Maki (J) - title screen This line occurs on bsnes and has been confirmed on the real thing. ZSNES ends up being wrong on this one. Next we have some oldies that appear to be the same bug. *PGA Tour Golf (J, U) - little flickering box on bottom left *Yuujin Janjuu Gakuen 2 (J) - little flickering box on bottom right *Zan III Spirits (J) - flickering dots on wolfteam logo These have been confirmed to not occur on the real snes. bsnes had them broken for a while, but a recent wip fixed them (dma bus syc?), and interestingly, they are still fixed in .017.15 Here's some stuff that looked like bugs but were confirmed to occur on a real snes: *The King of Rally (J) - missing/flickering textures at race beginning (zsnes wrong) *Captain Tsubasa J (J) - parts of goal disappear when stuff comes in front (zsnes wrong) *Gambling Hourouki (J) - Character portraits blink black during effect (zsnes wrong) *Gegege no Kitarou (J) - possible mosaic issue on left side *Great Battle IV, The (J) - in gameplay, flickering garbage for a split second at top of screen *Jissen Bass Fishing Hisshouhou in USA (J) - line of water shows through boat (zsnes wrong) *Kamen Rider SD (J) - bikes flicker heavily when ontop of eachother (zsnes wrong) *Pop'n Twinbee (Sample) (J)- fails to load *Takeda Nobuhiro no Super League Soccer (J) - top horizontal line during gameplay looks odd *Tom and Jerry (J) - far right of first level has messed up vertical line *Top Management II (J) - when car comes in, it is under line *Sim City (J) - edges of of screen mess up when you scroll any direction Next, I tested Goodbye, Anthrox (PD). You're right. 0-224 displays for this rom what a real snes displays for it. I now realize that a lot of homebrews were probably never tested on real hardware, but on yesteryear emulators. Anyway, bsnes should still be outputting what the real snes outputs. The hclock breaking point list is now as follows: *T2 - The Arcade Game - 0-1054 works, 1055-1096 breaks *Prince of Persia 2 - 0-182 breaks, 184-1096 works *Goodbye, Anthrox - 0-224 works, 226-1096 breaks *Might and Magic II - 0-216 breaks, 218-1096 works *Taz-Mania - 0-140 breaks, 142-1096 works That now makes the most determinable window of accuracy 218-224 for all known games to work. Lastly, Super Mario Kart has regressed with .017.015 as you warned it might. I've added it to the list. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 03, 2006 5:17 am Post subject: | |||||
|
|
|||||
o_O What in the hell are the odds of that? Man, awesome work determining which games to not mention to me as possible bugs. With all of those games to look at at once, I may very well have snapped, heh. Especially if after each one I found out the real SNES was supposed to act that way x.x
Keep in mind, I still don't consider this a bug with bsnes, nor of its' emulation of the base SNES hardware, but with the DSP-1 emulation lacking timing. DSP-1 calculations are completing way too fast (instantly, in fact). This is throwing off timing. I doubt this will ever be fixed. The same problem is in the Cx4 and DSP-2. Games run too fast when special chips that had timing delays on real hardware are used. Nonetheless, you're free to keep listing it. I might make a more clear note somewhere on my site indicating that I am not counting nor interested in bugs on special chips, unless they are related to base SNES emulation in some way (can be difficult to determine, I know). Wow, all of those games and no errors... seriously, what are the odds? 218-224 is very narrow. Should I move the hclock test into the clock tick, instead of in the opcode edge? It will probably slow down the emulator by 3-5%, but will make results much more stable. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 03, 2006 7:25 am Post subject: | |||
|
|
|||
|
Oh
wow, found a major simplification. There's no need to have separate
routines to sync DMA, HDMA and HDMA init events. I can actually combine
all of them into one global DMA bus sync event, and then just make HDMA
and HDMA init check and see if DMA bus sync has already begun. If so,
just perform the HDMA/init immediately, otherwise perform bus sync
before performing HDMA. Seems to work ok, though I can't guarantee HDMA timing is perfect, especially not when DMA is active when the HDMA event begins. Had to move HDMA trigger position forward from 1106 to 1110 to fix flickering with Street Racer, but it seems to work fine now. I will need to investigate further to see why it needs a later value than bCPU. I consider this one "half fixed" for now. Wild Guns still works, unlike with bCPU, so this approach appears to be better. Super Mario Kart still flickers, and I still don't care. Zan 3 Spirits and Yuujin 2 still work, with no flickering dots / garbled boxes. The girl flickers in the intro, but I think she's supposed to, as it's showing her "transform" into that catgirl thing.
Perhaps you'll trust what I say in the future :P 224 doesn't work well for me, it still flickers. I left it at 256 for now, as I'm not too concerned about homebrew at this time. This PPU HCLOCK stuff is identical to ZSNES/SNES9x' CPU execution ratio stuff. Ugly hacks >_< If I can get Koushien 2 and Battle Blaze fixed without breaking anything else, I'll get a new version out and try and start on sPPU (what I'm going to call the dot-based renderer). My polymorphism code takes a significant speed hit (~10%) by not allowing inlining between objects, but I think I may just have to turn that on so that I only need one binary release that allows one to toggle between bPPU and sPPU at runtime (and while we're at it, bCPU<>sCPU and bSMP<>sSMP). Lastly, I'm getting ~119.5fps on demo_mode3.smc, whereas v0.017 official ran at ~126fps. Looks like the next version speedhit won't be so serious after all, thanks to lots of code inlining and optimizations to sCPU. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Oct 03, 2006 8:25 am Post subject: | |
|
|
|
| wow great work guys!! i can also confirm that any character flickering or disapearance in yuujin2 also happens on hardware, so thats definatily not a bsnes problem hope those wrongly hacked/fixed games in zsnes get their bugs back I was wondering if anyone could document those ingame bugs? I dont have any hosting to hold them, byuu, maybe you could host the list +screens perhaps in your documentation section?? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Oct 03, 2006 12:36 pm Post subject: | |||
|
|
|||
K, I removed Super Mario Kart.
Appears to have gone down to 222 before breaking with the new wip Also, hate to bear bad news, but it looks like Kamen Rider SD (J) broke after .017.13. At least, it no longer works in .017.15 and .017.16 |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 03, 2006 4:08 pm Post subject: | |||||
|
|
|||||
Well, thanks for giving me a moment to fix it before adding it to the buglist at least :P
Reverted that change to always initialize all of SPCRAM to 0x00 and it works fine. Either bsnes is encountering another S-SMP bug (possibly related to Koushien 2), or bsnes is getting something right that other emulators are not, thus breaking the game when this pattern is in SPCRAM. It's probably the former, but for now SPCRAM initializes to 0x00. |
|||||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Wed Oct 04, 2006 4:58 am Post subject: | |||||||||||
|
|
|||||||||||
Huh, comparing OLE to MFC. Well, whatever. For some reason, this reminds me of how a certain BitTorrent client author won't include URL drag-and-drop support in his software because of the OMG XBOX HUEG memory bloat that appears just after the necessary CoInitialize() call. (In this case, the project is already using something else COM-based, namely DirectX.)
All of my crap is gzipped, I only converted a few files to these formats for the sake of testing the compression support. In fact, I don't really know why I bothered to add it in the first place.
I'm not sure how it's 30 cents more worth of DVD-R space since the whole set fits on a DVD-R either way, unless OMG WOW now you can cram more consoles' worth of merged and compressed ROM sets onto the same disc.
On a side note, kernel streaming method works with event notification per audio packet you feed into it, and that notification receives full precision time slices even without setting the timer resolution manually. At least, when I was using kernel streaming in my NES emulator, it didn't need vsync to output almost a smooth 60fps, while WaveOut mode outputs in bursts and requires vsync to smooth out the frames.
I think that's the only change in the D3D display code, so you can just replace the source file. |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 04, 2006 6:27 am Post subject: | |||
|
|
|||
|
Ok, reverted the SPCRAM initialization pattern, which should fix Kamen Rider SD. Verified DMA timing steps, I had them right. Still need to verify HDMA/HDMA init, but they're almost definitely the same anyway. Also, I noticed the spc700.txt doc by anomie on romhacking.net was more recent than mine, and had info on $00f0 - TEST o_O So, went ahead and added emulation for 5 out of 8 of these bits. Notably, the CPU speed control bits and the RAM write enable bit. The other three aren't well understood enough to add support for them just yet. Now, the CPU speed control in the S-SMP means the SMP core is taking a significant speed hit to support this register. ~5% total speed hit, though I can probably get that number down a little with some more optimizations. I know the register is never used by any games, but you know how I am. I added support for it anyway. Note that the WIP doesn't like my inlining combination and is taking a much more significant speed hit with global optimizations turned on, so the WIP is ~13% slower than the last one.
If you wouldn't mind turning that into a compatible derived Audio class, I'd love to add this as an option into bsnes :) It'll be drop-in and compile, so you don't have to worry about me not adding the code this time. No problem if you don't have the time / desire / patience to do this. Although, I wouldn't want to do this if it requires 3rd-party libraries / loading a special .sys driver into the kernel space / Windows DDK to compile / something else crazy like that. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 05, 2006 9:08 pm Post subject: | |
|
|
|
| All remaining "S" (J) games tested. No bugs found. However, more hclock fun. "Super SWIV (J)" screws up on its title screen from 0-284. Adding to that, "Super F-1 Hero (J)" has a flickering line during gameplay which actually happens on the real system. But I can't seem to get any hclock setting to look the same way, because the line actually spans two horizontal lines and shifts around differently. It's really odd, and probably will only look the same with a pixel-based renderer. Anyway, if we ignore PD carts, it appears the next best thing is around 300. Due to the results of my possibles testing, I went ahead and confirmed that the old Hungry Dinosaurs bug was indeed a bug in bsnes, so no worries about leaving that fixed. Lastly, if Nach reads this thread, the following roms are suspected to be PD roms erroneously in NSRT's database. I say this because they all have porn in them, and they're also not on Overload's list. Riverse Kids (J) SM Choukyoushi Hitomi - Bangai Hen 2 - Maki no Love Love Panic (J) SM Choukyoushi Hitomi - Bangai Hen (J) SM Choukyoushi Hitomi (J) SM Choukyoushi Hitomi Vol. 2 - Trial Version (J) SM Choukyoushi Hitomi Vol. 2 (J) SM Choukyoushi Hitomi Vol. 2 Remix (J) SM Choukyoushi Hitomi Vol. 3 - Test Version (J) |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Oct 05, 2006 9:34 pm Post subject: | |
|
|
|
| I checked my DB none of them was dumped by anyone on my team. I do remember hearing how some games were from some crazy magazine. Are these those? If you think they should be removed, I'll see to that. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 05, 2006 9:41 pm Post subject: | |
|
|
|
| I just figured Nintendo would never license anything with that kind of content. And if they're from a magazine, that would essentially make them... a commercialized homebrew? Its existing in tangible form makes it no more deserving of being included. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 05, 2006 10:29 pm Post subject: | |||
|
|
|||
Hooray!!!!!!!!!!!!!!!!!!!!!!!!!!!! Five more to go, and no more Japanese hell! Thanks for testing all of those awful games, FitzRoy :) I believe the CIC pretty much eliminated pirate carts on the SNES. Of course, I could be wrong. But compared to the NES and Genesis, where I know of hundreds of pirate carts per system... I have to say, it definitely helped cut down on them. Which, while it sucks for homebrew (have to ruin a cart to make your own flashcart from a blank PCB), I'm glad they did. Those games are always of ass quality, have crazy weird banking protections, and tend to have the same programming quality as PD ROMs. |
|||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Thu Oct 05, 2006 10:30 pm Post subject: | |
|
|
|
| Unrelated to what you guys are talking about: D4s released a German translation of Breath of Fire 2 featuring many modifications and additions. D4s said this about this release "oh, and the game will also reliably detect if its running on a real snes and will display an additional warning telling the user that the patch is freeware and not be sold.". Considering the goal bsnes is to behave as closely as possible to a real SNES, I figure it should then display that warning that only shows on real hardware ? It doesn't at the moment... And I have no idea how d4s made that "real SNES check", but I can ask him, or you can do it yourself if you prefer... Links: http://www.ultrasnes.de/snes.html http://bof2.blogspot.com/ Your opinion ? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 06, 2006 1:20 am Post subject: | |
|
|
|
| I
asked on the ROM hacking board how to get in touch with him. If you
can, please ask how he determined the presence on an emulator with
bsnes. Also please ask him if the audio is supposed to crackle two
times very softly during the second intro character screen (the angel
girl). It does in all emulators at present, but I'm thinking it's a
flaw with the original audio (or its transcoding to the SNES) and not
in emulators. If he doesn't want to say how he detected bsnes, then I have no choice but to attempt reverse engineering. And I know d4s wouldn't have made that easy :) Anyway, determining the presence of an emulator isn't too hard. I can think of quite a few ways to do that, which will never be possible to emulate. |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Fri Oct 06, 2006 1:55 am Post subject: | |||||
|
|
|||||
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 06, 2006 4:41 am Post subject: | |||
|
|
|||
w00t! No problem. I'm most excited about understanding the menus from here on out. Should be faster to get into gameplay. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 06, 2006 6:05 am Post subject: | |
|
|
|
| Ok,
d4s replied. Looks like I have to disassemble his work to find out how
he's detecting bsnes, fun. The sound pop is due to wave -> brr
conversion. Not a bug, thankfully. Nothing emulation related for now. I instead rewrite huge chunks of libstring, renamed libvector to libarray, and added a new libvector that works with objects instead of memory buffers (libarray is now the memory buffer template class). I then merged all of that into bsnes and got everything mostly working again. Tons and tons of internal changes. My next task is libconfig. I'm thinking of using templates to specify type, instead of passing parameter types to the functions. This should get rid of get<>sget and set<>sset ugliness. Huge thanks to Nach, many of my libraries are dramatically simplified now. They should also leak less memory, as the string class even has a valid copy constructor now. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Oct 06, 2006 9:26 am Post subject: | |
|
|
|
| Did some testing of the memory leakadge. In bsnes .17 memory usage is higher and keeps rising and rising in the latest wip memory usage is higher when idle, but lower with a game loaded. also the wip hardly uses any more ram during gameplay whereas .17 keeps eating more ram every few seconds. When i open bsnes it uses about 14 mb, when i load dkc2 it uses 22 mb, when i unload dkc2 it uses 18 mb so bsnes is not releasing everything it created for that cartridge session tested some more, when opening the "load diagologue screen" memory ususage obviously increases, but after closing it, not all ram is released, so memory usage is higher. but when i open de dialogue again it has the exact same high value as the first time, tried this 10+ times, and everytime the low ram usage is a different amount but the high ram usage is always the same wierd? |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Fri Oct 06, 2006 3:08 pm Post subject: | |||
|
|
|||
He refused to share ? Aww, that's uncool of him. Although he's certainly all proud of his work, hoarding harmless info for no reason is pathetic. It will only result in making you waste your time... |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Fri Oct 06, 2006 5:34 pm Post subject: | |
|
|
|
| I would love to see Kernel Streaming implemented in bsnes (even in ZSNES).ZSNES SVN builds do not have this option.Is this available only in your custom builds of ZSNES? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 06, 2006 6:31 pm Post subject: | |||
|
|
|||
Exactly right, I could be fixing bugs that affect real games now instead. But I don't mind a challenge. And it looks like he has a sense of humor, at least. Makes it more interesting. 
|
|||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Fri Oct 06, 2006 6:39 pm Post subject: | |
|
|
|
| Haha. :p Good luck with that, although I don't think it'll be all that challenging for you... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 06, 2006 6:47 pm Post subject: | |
|
|
|
| byuu, did you see that badass snes dev unit? How useful would that be for an emulator author? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 06, 2006 11:59 pm Post subject: | |||
|
|
|||
It wouldn't, but you could buy me one anyway :) Anyway:  I can't emulate his check. I won't give away the secret, so nobody tries to remove that screen for the purposes of selling his translation on a cartridge, but suffice to say it's something I figured he was doing, and is one of the very few things I can never emulate properly due to absolutely massive difficulty compared to payoff. Of every SNES game ever released, not a single one relies on this behavior. |
|||
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Sat Oct 07, 2006 4:47 am Post subject: | |||||
|
|
|||||
I'll chip in on it |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Oct 07, 2006 5:00 am Post subject: | |
|
|
|
| Hehe, pretty sure he was joking. Guy says there's only four left in the world, which is why I was curious about its usefulness. | |
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Sat Oct 07, 2006 12:11 pm Post subject: | |||
|
|
|||
ahh damn, and I thought there was something he'd finally except for his great emu he has given us
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 08, 2006 3:44 am Post subject: | |||||
|
|
|||||
|
Fixed a major memory leak with the new library -_- Wasn't deleting the temporary object buffer copy. Memory usage dropped by about 800kb after loading a ROM as a result.
Implemented a proper "clear line" routine for when display is disabled, that now takes screen width and interlace field into account. All interlace games should now clear the screen properly during transitions. EDIT: Not as bad as I thought it was going to be. F1 Grand Prix, Sink or Swim and Battle Blaze all work. However, I'm now failing test_irq.smc. Basically due to the trickery that is the +10 VIRQ, +14 H[V]IRQ timeshifting. I'm no longer firing extra interrupts nor missing any interrupts, but the IRQ trigger positions for VIRQs on the start of a scanline is now off by exactly 8 clocks. Which is obviously a lot less severe than before with Battle Blaze triggering multiple interrupts on every scanline. Also, I'd like to note now, Battle Blaze is buggy as hell. Even on real hardware. The game locked up and died with corrupted palette data on the final boss fight on my Super UFO. I also saw countless graphical glitches on the map and in battles. bsnes seems to play the last boss fight correctly, so perhaps it's open bus related (the Super UFO somehow prevents open bus from functioning). However, there's some shadiness when you beat an enemy and the soul thing flies around. I think this is due to PPU mid-frame writes. A lot of the graphical glitches are. I'm thinking, get test_irq.smc passing again, and move on until sPPU is as compatible as bPPU. So that leaves me with two more "fixable" bugs. Koushien 2 and Jumbo Ozaki no Hole in One. Completely stumped on both at the moment. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 09, 2006 5:04 am Post subject: | |
|
|
|
| This game really frustrated me at first, but I figured out a trick to beat them all without much effort Didn't run into any game bugs like you, so maybe it is your copier. I was using the (U) version, btw. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 09, 2006 6:13 am Post subject: | |
|
|
|
| Yeah,
the sword stab takes them all out easy, excluding the last boss, who's
a bit harder. What a short game, huh? I'd be pissed if I spent $50 on
that game. So, how about the soul floating around scene? Are there blank scanlines in between it while its flying around? It might just need a different HCLOCK value in bsnes if there aren't. Who knows. ---------- Thanks to a genius observation by TRAC, I was able to finish implementing proper IRQ timing. It should be virtually clock perfect, excluding some unbelievable edge cases. Right now, bsnes is passing all of my tests, and still runs Battle Blaze + F1 Grand Prix + Sink or Swim :D I lost more speed though, as a result. I'm now getting ~105fps, from ~125fps in bsnes v0.017. Sigh, just can't seem to keep that number up there. Oh well, this pretty much gives me infinite precision, so even if there are new IRQ findings (and there will be, it never ends), speed should no longer be taking any beatings as a result of them. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 09, 2006 7:02 am Post subject: | |||
|
|
|||
In bsnes, yes there are some strange issues during that effect, as well as the last boss "coming apart" effect on the ending (same issue probably). On the real system, these issues don't exist. You're saying that despite your new IRQ fixes, these things still happen? If so, it could be a separate issue. hclock doesn't seem to be affecting it. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 09, 2006 4:51 pm Post subject: | |
|
|
|
| Well,
anomie and I have noted many mid-frame PPU writes in this game. The
authors of this game have apparently never heard of HDMA, and decided
to do all of their effects with much more costly HIRQs. I'll wait for the dot renderer on this one, the title screen looks a lot better now at least. Up to you if you want to consider it a bug. But at least serious improvements to the IRQ handler resulted from the title screen bugfix for now. Now, remaining bugs: Koushien 2 - same as always. Too much code to trace through (~2gb worth). Exact position of error changes every time you play. No cleanly written, C/C++ (no nested #defines) S-SMP (SPC700) emulation cores to compare against. As it's the only game known to crash the SMP, it's likely an obscure bug that would be hard to spot anyway. I've been unable to fix it with about ~16-20 hours sunk into it thus far. Jumbo Ozaki - has to be a CPU timing bug. Still need to double verify HDMA timing (especially now with HDMA bus sync support readded), but I'm pretty sure it's CPU related. Of that, it looks like the game sets (regs.d & 0xff) != 0, which causes an extra math I/O cycle on all direct accesses. Perhaps I'm adding the work cycle in some opcodes I shouldn't be? Unfortunately, I can only test this one from home. I've implemented my CPU core to spec with the 65c816 manual as best I could read it, so hardware opcode timing tests will be needed to track this down. Expect very slow progress since 90% of my time is spent at work. Mega lo Mania and Uniracers - both waiting on sPPU. Hmm, doesn't look like I can get any more fixes in before the weekend. Please go ahead and test the latest WIP as a release candidate in that case. I'd like to get v0.018 out on 10/14 for the two years in development mark for bsnes. Let me know if there's anything major that needs to be addressed before another public release. Next release probably won't be until 01/07 or so (and will probably not have any of sPPU included with it). Lastly, I might revert the Street Racer fix, if my testing reconfirms HDMA triggers at HC=1106 (anomie's tests indicate it starts at HC=1112). If I do, then that game likely also suffers from slight CPU opcode timing flaws. Can someone please get me total counts for number of real SNES cartridges (sans revisions of the same game and betas) released per region? Perhaps a count with revisions for the hell of it as well. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Oct 09, 2006 5:49 pm Post subject: | |
|
|
|
| great work, as far as i know no mayor bugs need to be fixed so if i dont find anything new your release is a go. ill try to look at the total game list tommorow if fitzroy doesnt beat me to it. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 09, 2006 6:50 pm Post subject: | |
|
|
|
| Mmm, an anniversary edition. Any chance of these things being added?: "Auto-detect" for overscan screensaver suppression in windowed mode (although you said you didn't know how) I might add the Battle Blaze to the list, if only because hclock doesn't affect it. I'm definitely leaving out all of the hclock affected games, since they can be corrected individually at least by messing with the hclock option. And sPPU will wipe these all out anyway, so thank god for that. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Oct 09, 2006 7:44 pm Post subject: | |
|
|
|
| Its
pretty cool that bsnes is only 2 years old, basically made by 1 guy,
mostly hardware accurate and as far as we know 99.something% compatible
with non special chip games |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Oct 09, 2006 10:47 pm Post subject: | |||||
|
|
|||||
And it's been maturing amazingly well. Congrats in advance! _________________ savestate editor: vSNES latest public version
|
|||||
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Tue Oct 10, 2006 7:20 pm Post subject: | |||
|
|
|||
http://www.nintendo.com/gamelist?category=classic here a link from nintendo.com. My stupid work computer doesn't have acrobat reader on it so I can't open and give you a count. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 11, 2006 4:59 am Post subject: | |||||||
|
|
|||||||
No longer. I was correct, a CPU timing bug. A really embarassing one, too. CPU I/O condition 4 was wrong. "Add 1 cycle for indexing across page boundaries, or write, or X=0. When X=1 or in the emulation mode, this cycle contains invalid addresses." bsnes code:
Correct code:
Slows down the CPU (not the emulator!) a good deal. It fixes Ozaki by moving the write into $0006 until after the NMI that resets the value, other emulators were all executing it before, so I figured bsnes was running too slow. It was actually running too fast. That was a major, major timing bug to be missed for so long. I shall have to make a generic test ROM to clock CPU opcode timings. I'm suspecting my store opcodes (sta $nnnn,x) may be wrong. I don't currently force those to consume another cycle, but the above says "or write". I'll make that my last test for today. I also added in the CPU revision 1,2 differences for HDMA init and DRAM refresh trigger positions. But it isn't perfect, my HDMA init timing test is still off by ~2-4 clocks. But, don't celebrate too soon. I decided to revert the Street Racer fix, at least until I can get this HDMA init timing test passing and verify the HDMA trigger position on hardware against emulation. Much like the Ozaki fix, I don't feel good about the Street Racer fix. EDIT: yep, writes always consume the CPU IO condition 4 cycle. Fixed as well. |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Oct 11, 2006 6:13 am Post subject: | |
|
|
|
| Tetsuo55 does the Bsnes just got more hardware accurate dance thats a great gift just in time for its 2 year birthday!! |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Oct 11, 2006 6:22 am Post subject: | |
|
|
|
| Heck yeah! Awesome job, byuu. Both Jumbo and Energy Breaker now work at the same time. That's never happened before. New wip seems solid... no regressions. | |
Hazed
Joined: 29 Jul 2004
Posts: 86
Location: USA
| Posted: Wed Oct 11, 2006 8:21 am Post subject: | |
|
|
|
| OK, you wanted a count of games from each region. Here's a count, using NSRT, plus a few new dumps not in the latest NSRT: NOTE: The counts for games that don't include revisions, etc. are surely off by a few, as I probably missed a few variants (I almost missed a "doritos promo" variant of George Foreman's KO Boxing (U), for example). So take those figures with a grain of salt. Australia: 3 Brazil: 1 Canada: 1 China: 1 Europe (with revisions/betas/alternates/bioses): 581 Europe (sans revisions/betas/alternates/bioses): 533 France: 29 (28 not including revisions) Germany: 44 (42 not including revisions) Italy: 2 Japan: (with everything): 1715 Japan: (sans revisions/betas/alternates/bioses):1625 Japan & USA: 4 Japan, USA, Europe: 3 (all Super Gameboy BIOSes) South Korea: 2 Spain: 11 Sweden: 2 (1 of which is a copier BIOS) The Netherlands: 2 (1 of which is a beta) Unknown: 130 (Pretty much all of these are betas or BIOSes or pirates. 1 sample ROM) USA (with everything): 803 USA (sans revisions/betas/alternates/bioses): 733 |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 11, 2006 4:34 pm Post subject: | |
|
|
|
| Thanks,
zidanax. That's actually really good news. The Japanese games (all of
which have been tested) make up more than every other region combined,
not to mention many of the other region games are just translations of
the Japanese versions (so they shouldn't have problems). So,
hopefully... no more than five bugs will be discovered with testing all
of the remaining games. Hopefully, heh. EDIT: Battle Blaze can be removed from the buglist. The game actually is supposed to only fire an IRQ every other scanline. The HIRQ routine consumes 2000+ clocks, with only 1324 clocks available on each scanline. The game is writing to PPU register $210d (BG1 horizontal scroll position) anywhere between HCLOCK = 100 - 280, and that's just what I personally observed. The range could be even greater. I tested with HCLOCK=768 (because I hate the game and didn't want to play it repeatedly to find a good value) for PPU scanline render position, and the effect worked just fine. You could probably get away with 300-400, but I wouldn't push it much further than that. So then, why the black scanlines? Because $210d requires two writes to set the scroll register. What's happening is, my scanline renderer at HCLOCK=256 (the default) is triggering right in between the two writes, so the BG1 scroll register is completely off, causing it to render an area where there are no tiles mapped, hence some of the scanlines get black lines. On a real SNES, these late writes will be visible, but will be much harder to notice. Basically, you'll either see 3-12 black dots at the very leftmost edge of the screen on some scanlines, or the scroll positions will be slightly off. But it will be very hard to notice with the effect moving so quickly, and with TV horizontal overscan cutting off most of it anyway. Amazing what crap NoJ's QA program let slip through. Indirect HDMA would've worked just as well for this effect, and in fact would've allowed twice the fidelity of the wave pattern to be shown. And all without mid-scanline PPU writes. With all of these HCLOCK ranges, there's no getting around it. I'm basically going to have to make this a GUI option until I get a proper dot-based PPU renderer in there. There are just too many games that rely on different settings to work right :( |
|
New Member
Joined: 11 Oct 2006
Posts: 1
| Posted: Wed Oct 11, 2006 7:03 pm Post subject: | |||
|
|
|||
See for example: http://page8.auctions.yahoo.co.jp/jp/auction/h42988253 If you are going to ignore those games, please also include Super 3D Noah's Ark in this list as well.
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Oct 11, 2006 8:06 pm Post subject: | |||||
|
|
|||||
@byuu:
Interesting, I'll have to add it to the my hclock list. There are
really only two fixable bugs left then in Street Racer and Koushien 2.
Everything else is just dependent on a dot-based PPU.
Good info, thanks. At the very least then, these games should be given a [unl] or something to denote this, as well as Noah's Ark. I think a pirate is different in that a pirate is an official game or compilation of games that are copied and resold illegally. Could be wrong. I don't know how to feel about [unl] carts being included in the database. But I think I would keep official test cart roms, store demo carts, and official add-on bios files, remove pirates and copier bios, and remove all BETA roms that saw official release. Many of the BETA roms we have are unverifiable and could simply be bad dumps. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 11, 2006 8:34 pm Post subject: | |||||
|
|
|||||
Pretty much. I'm debating adding hacks for bPPU to play those last two games once I have a working sPPU. Since I already know sPPU will prevent pretty much everything but Core 2 Duos from playing bsnes, it seems like a good idea. The accuracy is there, if you can afford the power requirements. I might also put off sPPU development until I get a nice C2D. I don't want to have to stress out at the framerates at first, I can always optimize later. That might be a while though, as I'm presently living paycheck to paycheck.
I really don't know about this anymore, myself. Official, released, for sale carts should absolutely be in there. Other than that... I can see reasons to index them, but the fact is many of these authors don't want their works indexed in such a manner as to appease to ROM collectors. However, it's needed for cartridges since ROM dumps lack PCB layout info. I'm hoping that UPS and the anti-hard patching code I have in mind will help cut down on this whole situation. You should be able to embed your readme inside a UPS file, and there's an info section to put authoring information in there. I'm hoping we can also disallow soft patching when the UPS file is inside a compressed archive. It will help prevent Cowering and co from just distributing patched ROMs as SMC+UPS pairs. I don' think many fan translators would mind their patches as standalone files in their own archives being distributed. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Oct 11, 2006 9:50 pm Post subject: | |
|
|
|
| You could make an argument for that. But there are a few games off the top of my head that were developed with the intention of being released commercially, and for various reasons, never were. Star Fox 2, Apocalypse II, Corn Buster... However, indexing BETAs of games that were released commercially is kind of pointless. I suppose the novelty of differences from the final product can be interesting, but most of the time these were near-finished games which were lent out to magazines and shit, and thus, the difference between versions is more likely to be bugs than game changes. Additionally, we have no way of verifying what these games claim to be. There have been a lot of betas that simply ended up being bad dumps of the official release, and we've also had a lot of betas that are dumped improperly and need special emulator fixes. Then you've got ones that don't even work at all. Take Pop N Twin Bee (Sample) for instance. The damn rom doesn't work in any emulator, or the real system, so aside from the internal naming, how on earth do we know or trust what it is? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 11, 2006 10:25 pm Post subject: | |
|
|
|
| Funny
story, someone on romhacking.net actually posted a link to two SNES
tech demo ROMs. One wasn't running on any emulators so I decided to
take a look at it. Hmm, completely missing any trace of a header, just
like the SNES Test Program. But this time, even the reset vector was
0000! Curious. As it turns out, the ROM was actually a Gameboy game. Someone apparently tried loading it in bgb and it actually worked. |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Thu Oct 12, 2006 4:27 am Post subject: | |
|
|
|
| I
believe I found a bug in 0.017, either that or in the ROM/game (Don't
have the HW to test it out). The game in question is Robocop Versus The
Terminator (U). Frame skip set to 1 When I entered game play by repeatedly pressing the B button (not using the start button at all) it starts up with a black screen, but music is still playing and I can still hear that regular game play is going on. When I press the start button and enter game play I see the game play just like I do on snes9x 1.502. I don't know If the pressing of the B button versus the start button is a clue to the problem or just a coincidence, but 5 tries of each yielded identical results. Frame skip set to 0 The game play screen flashes like crazy and this is independent of what button is used to enter the game play. In snes9x (as mentioned earlier) the screen does not flash like crazy. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 12, 2006 5:11 am Post subject: | |
|
|
|
| Thanks
for the report. Flickering bug occurs in .017 but not .017.21. In other
words, it's been fixed in recent test WIPs. Lots of timing/IRQ
improvements since .017. Last edited by FitzRoy on Thu Oct 12, 2006 5:12 am; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 12, 2006 5:12 am Post subject: | |
|
|
|
| This
is fixed in my WIP builds, but thanks. One more game to add to the
"fixed" list. So, that's 12 games fixed and 4 still broken. Should make
for a decent release :) ---------- I'm trying out some wild ideas with my base libraries. Specifically, libvector is now using a giant shared memory pool. Objects are created with the placement new operator, and deleted with explicit destructor invocations. Both libvector and libarray now mimic the API of boost smart_ptr style template classes. Man, this version's really going to take a beating in terms of speed :( Still should be trivial to get 60fps on an A64 3500+ or above, at least. Ok, I asked about this a while ago, before we knew that sCPU and sSMP would be as fast and accurate as they are... but how about I rewrite bCPU and bSMP to opcode CPU emulators with somewhat weaker accuracy (no worse than SNES9x, obviously), but greatly enhanced speed? I figure, the timing and all that is still just as accurate, it's just the synchronization between core components (CPU<>SMP, CPU<>PPU and SMP<>DSP) will be a little fuzzier. And the benefit would be that with lower system requirements, more people would be able to use the software. Opcode based cores could also one day lead to savestates. bsnes still stays an experimental emulator that pushes for as much accuracy as is possible in software, and yet can appeal to end users with virtually no maintainence costs. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 12, 2006 6:08 am Post subject: | |
|
|
|
| Always first to express his opinion... is me! I have a 2.4c Northwood that gets 80-115 fps in .017. This processor debuted in 2003, and was the lowest end mid range model. My guess is you could go as far as four years back and still have technology capable of running bsnes at 60fps. With a frameskip of 1, you could go back even farther for playability. I don't think there's any need to cater to people who haven't upgraded their computers in five years, especially at a time when computers are cheaper than ever. And you know that as time goes on, even these people eventually upgrade. When that happens, in another five years, who's still going to need a crippled version? Savestates, however, are probably a better argument for this. It's probably not what you want to hear, but special chips would be far more effective at getting more users. Even if the emulation speed is off, or its not completely accurate, or SA1 is too slow and you have to use frameskip, we've heard more jabs about that than speed in this thread. Star Fox, Super Mario RPG, and TG3K carry a lot of weight. A lot of weight. TG3K alone needed a board filter for years just to stave off the requests for this game. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 12, 2006 6:28 am Post subject: | |||||
|
|
|||||
You'll get 60-95fps with v0.018.
Again, savestates are technically impossible at present. I might try it with an opcode-based core, but that'd be about it. I don't mind adding DSP-3 and DSP-4 (even if they're not 100% accurate), but I need generic classes that I can stick in bsnes first. And you're going to have to try a lot harder to convince me to add SA-1 and SuperFX, sorry. Maybe when sPPU is out publically, all other games have been tested, and zero known bugs remain :) |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Oct 12, 2006 6:44 am Post subject: | |
|
|
|
| I
would appreciate the re-written opcode cores. I'm in college, so I
don't really have the money to spend on upgrading computers. However, if it's going to take a lot of work to re-write the cores, I'd rather see work start on sPPU. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 12, 2006 7:14 am Post subject: | |||||
|
|
|||||
True, but I've got a Core 2 Duo e6300 sitting here waiting for a 7650gs to be built. Because unlike bum kids, I enjoy computer games and applications and am willing to work hard enough to afford this luxury. And I don't bloody expect people like you to compromise your work so that I can use it on my mother's 486.
I wouldn't ask for it any sooner. But in regards to creating a bigger userbase, neither old computer users nor Koushien 2 getting fixed has a thing to do with that. Star Fox, Super Mario World 2, and Super Mario RPG are three of the most popular games on the system, and they're quality, Nintendo developed games. Average joe, who has no idea what a special chip even is, downloads your emu and none of them work. That's that. I also think your own forum would help, because people appreciate community and an easy place to ask questions or discuss things with organized threads. It helped zsnes and snes9x and it can help you. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Oct 12, 2006 9:22 am Post subject: | |
|
|
|
| I really doubt we are going to find any none ppu related bugs in the rest of the games. my opinion is the same as Haze's and that is that all games every sold on carts should be in the list, even if they are pirates. that also means that all homebrew and patched stuff shouldnt be. I have almost finished moving, soon i will be able to continue going through the list of snes games, and then we should have finished testing all know games. at least untill someone starts redumping all roms correctly by dumping each individual eeprom instead of reading the cart pins I also vote for adding special chips and hardware before doing sPPU, eventhough some stuff isnt fully known yet, at least you can add partial emulation of what is known. Then after sPPU is done there might be more info out there about how those special chips work... |
|
Rookie
Joined: 23 Nov 2005
Posts: 10
| Posted: Thu Oct 12, 2006 11:42 am Post subject: | |||
|
|
|||
Hi byuu, In harmony with FitzRoy statement, just my humble two cents in following this thread and bsnes for awhile now and concerning creating a bigger userbase in discussing what features to add or/and fix; many (most) "Average Joe" end users are playing or want to play the games full screen. While bsnes does have full screen support it unfortunately contains screen tearing due to lack of (or buggy) vsync or/and triple buffering support. While triple buffering support is present, it does exactly as noted next to the option in the current public beta, cause problems with sound. If possible fixing triple buffering support so games can be played without screen tearing would be a nice fix to make the emulator more appealing. Understandably, vsync and/or triple buffering can be forced/enabled at the driver level - but again - many do not want to change or modify video driver settings for the sake of an emulator. Again, just giving my humble two cents on the topic. -Trebor |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 12, 2006 2:33 pm Post subject: | |
|
|
|
| The
larger userbase thing was more to the point that it would be a nice
side effect of faster alternative cores for bsnes. It would also mean I
could worry a little less about speed. If someone complains I can just
refer them to the "fast" version instead of saying, "go use another
emulator." As for triple buffering, that's one of the many things I've asked for help on several times in the past. I tried to add it in. Microsoft's piece of shit drivers always force sync immediately, so the second I call device->Present(...), the emulator is locked by the system until vblank, desyncing sound. If anyone knows how to make Present queue in a buffer and only occur when one is actually in vblank (without the need for a 1ms precision timer to constantly poll the raster status of D3D), I'll add the code. This is common sense stuff that seems omitted by Microsoft's graphics library. |
|
Rookie
Joined: 23 Nov 2005
Posts: 10
| Posted: Thu Oct 12, 2006 4:23 pm Post subject: | |||
|
|
|||
I was beta-testing and working with Marty (Nestopia's author) for the longest time on tearing problems/triple buffer issue with Nestopia. Marty also was having problems with the ridiculous way video buffering was being handled by Microsoft's library. I forgot all the details. Thankfully, he was able to fix it and locate the source of the problem. Marty is extremely nice and friendly. Perhaps you can ask on the Nestopia Message Boards, or parse the Nestopia source? http://nestopia.sourceforge.net/ -Trebor |
|||
Rookie
Joined: 23 Nov 2005
Posts: 10
| Posted: Thu Oct 12, 2006 4:57 pm Post subject: | |
|
|
|
| I'm
"challenged" to say the least in the field of programming. However, in
the Nestopia source zip (Nestopia134src.zip), there are two files that
may be of interest: NstDirect2D.cpp and NstDirect2D.hpp. They may assist in understanding how to handle video buffering. -Trebor |
|
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Thu Oct 12, 2006 5:21 pm Post subject: | |
|
|
|
| I just got a core 2 duo e6600, so I'm good to go with speed |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Oct 12, 2006 5:53 pm Post subject: | |
|
|
|
| found a possible bug didnt have time to verify, fitzroy could you test on your hardware?? SD Gundam Gaiden - Knight Gundam Monogatari - Ooinaru Isan (J) (V1.1).smc > tiles leak over to the other side of the screen when scrolling sideways. |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Thu Oct 12, 2006 6:28 pm Post subject: | |||
|
|
|||
There is some new discussion about this at nesdev http://nesdev.parodius.com/bbs/viewtopic.php?t=2174 |
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Thu Oct 12, 2006 7:04 pm Post subject: | |||||
|
|
|||||
Yes, Marty's Nestopia seems to handle sound with triple buffering flawlessly. I'm betting he could offer some tips on how to get around that problem. For me, this should be even more important to fix than adding in super fx support or other chips. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 12, 2006 11:08 pm Post subject: | |||
|
|
|||
Not a bug, but verified on hardware anyway. I saw this, too, but it was the same thing as Sim City (J). Bad scrolling code that wouldn't appear on most old tvs because it's in the overscan area. Several games out of the thousand had this or similar. Another would be 7th saga while walking south. Oh, and agree about triple buffering. Lots of people like this feature, not sure how I forgot about it. Good idea to ask Marty, he knows his stuff. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 13, 2006 12:15 am Post subject: | |||||||
|
|
|||||||
Actually, for a ~10-15% speed hit, I think I can pull that one off... the only problem I see are "super DMAs". Basically, worrying about the theoretical "maximum" time the CPU cothread could be consumed in processing. It could be as great as ten full video frames between pressing save state and actually having it saved. But really, we're talking theory. No game in the world is going to actually do that. The game would appear absolutely frozen even if it did. There's not even a place to transfer the limit (512kb) of memory to. And I believe ZSNES et al does the same, it completes DMAs instantly. This just means that the CPU savestate, in the absolute worst condition, could dump as much as 512kb to the file. Not really a big deal, since it will only dump a few bytes 99.9% of the time.
Oh, wow. You saw that on a TV? Neat. I saw that myself, and assumed emulation might be running a bit too slow, but figured it was most likely missed because the developers didn't see it.
Nice. Hey, remember you were talking about donating something ...? Heheh, just joking. Seriously, is that the 4MB L2 cache one? Would you mind telling me what kind of framerates you pull with that baby on v0.017 official with speed regulation disabled? Preferrably in a "typical" game like SMW or Zelda 3 in-game. |
|||||||
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Fri Oct 13, 2006 11:56 am Post subject: | |||||
|
|
|||||
[quote="byuu"]
I'd gladly donate some money to you to help get one yourself. Yes I will test this out for you this weekend. It is the 4mb L2 cahce one. Do you want me to try the newest WIP also? |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Oct 13, 2006 1:14 pm Post subject: | |||||||||||
|
|
|||||||||||
Same thing as in the Axelay stage that has the giant walker at the end? That stage also updates its BG tiles quite slowly.
Personally I wouldn't care if the emulator needs ten seconds to save a state. As long as it's faster than examining GBs of logfiles it's OK. Actually such long saving times could even get me out of the savestate whoring that corrupts my gameplay. _________________ savestate editor: vSNES latest public version
|
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 13, 2006 6:57 pm Post subject: | |||||
|
|
|||||
Yeah, not a TV, though. I'm hooking up my snes to a s-video input card in my computer and running dscaler to view the output. This way I can see on my monitor what would normally be cut off by a regular tv. I suppose if you had an lcd tv though, you could achieve the same. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 13, 2006 8:24 pm Post subject: | |||
|
|
|||
Koushien 2 (J) S-SMP opcode count log:
The reason for the huge stop count should be obvious. The processor crashed there. If Koushien 2 is indeed due to an S-SMP opcode problem, it has to be in one of the above opcodes. Immediately, tset,tclr,clr5 dp and mov1 are jumping out at me as "likely" opcodes with problems... low opcode counts, obscure... hmm. Could be due to flags being incorrect, could be due to opcode semantics being incorrect. |
|||
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Fri Oct 13, 2006 10:45 pm Post subject: | |||
|
|
|||
I have this model and my system is quite fast: - bsnes 0.017 - SMW: typical speeds between 150 and 200 fps Zelda 3: typical speeds between 150 and 250 fps _________________ "Change is inevitable; progress is optional" |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Oct 14, 2006 10:10 am Post subject: | |||
|
|
|||
Hopefully releasing this without much beta testing doesn't turn out to be a bad idea ... |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Oct 14, 2006 10:34 am Post subject: | |
|
|
|
| Did you make a lot of changes since the last wip? If not then there shouldnt be any problems with this version |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Sat Oct 14, 2006 10:46 am Post subject: | |
|
|
|
bsnes speed hit and version comparison on a Core 2: I've used the stock speed for my processor (2.4 GHz). Nevertheless, awesome release _________________ "Change is inevitable; progress is optional" |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Oct 14, 2006 10:52 am Post subject: | |
|
|
|
| Ah,
so it's a bigger speed hit on Intel processors than AMD processors,
great. I get 115fps in Mario World with v0.017, and 99fps with v0.018. Oh well, it may not be a permanent speed hit. But don't get your hopes up on that, we'll have to see what happens when the last bit of IRQ testing is conducted. I didn't want to release until I could try and remove the speed hit, but it's kind of an important date :/ Side note for EMu-LoRd: I'd be much more impressed with the Core 2 Duo if both of those were running at the same time at those framerates ;) |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Oct 14, 2006 11:18 am Post subject: | |
|
|
|
| If bsnes was optimised for core2duo it might be able to exceed 200fps Maybe a SSE3 version could be compiled? |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sat Oct 14, 2006 11:50 am Post subject: | |
|
|
|
| Yeah,
I used to get 60 FPS with SMK with v0.17 (ie: perfect, no lag unless I
used a graphics filter), and with v0.18 I have something around 50 FPS.
:\ Still, I approve of your accuracy over speed changes. PS: how about making it so Alt + Enter switches to full screen ? May have been requested before, no ? Edit: ugh, remember the B button problem I used to have with SMK, with it not working during tracks ? It's back again, but seems somewhat random (didn't happen at first)... |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Sat Oct 14, 2006 12:03 pm Post subject: | |||
|
|
|||
They ARE running at the same time! This may look like a show-off, but here's a taste of what this processor is capable (fps) of: http://www.xs4all.nl/~vdnoort/emulation/bsnes_core2duo_18x4.jpg _________________ "Change is inevitable; progress is optional" |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Oct 14, 2006 12:58 pm Post subject: | |
|
|
|
| EMu-LoRd, is that 2 bsnesses on each core? how high is the fps with 1 instance on its own core? |
|
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Sat Oct 14, 2006 1:47 pm Post subject: | |||||
|
|
|||||
can't wait to try mine out tonight
|
|||||
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sat Oct 14, 2006 1:50 pm Post subject: | |||
|
|
|||
I can't even reach such a high FPS with just one bsnes. :p (Celeron D, 2.4 GHz, 512 MB RAM) |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sat Oct 14, 2006 3:40 pm Post subject: | |||
|
|
|||
Yes, it has been requested before (by me). EDIT: I have to use frameskip 2 to get 60 fps. I'm testing on an Athlon T-Bird 1.1 GHz. I'll test on my laptop later (which has a Pentium M 1.6 GHz). _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Sat Oct 14, 2006 5:26 pm Post subject: | |||||
|
|
|||||
IIRC Byuu explained that polling the Alt key does something strange, and so he doesn't know how to catch the Alt + Enter.. |
|||||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Sat Oct 14, 2006 5:39 pm Post subject: | |
|
|
|
| Please excuse my noobness if there is, but is there a key I can press to reset the emulation while in fullscreen mode? Currently I'm having to exit back to window mode and select the reset function from the menu options. | |
New Member
Joined: 31 Aug 2006
Posts: 4
| Posted: Sat Oct 14, 2006 5:56 pm Post subject: | |
|
|
|
| iNTERESTING with my ATHLON 64 @2400mhz I GET 111 Frames, which means it is 22,5 % slower as the duo core | |
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Sat Oct 14, 2006 10:45 pm Post subject: | |||
|
|
|||
With or without using separate cores for each, it doesn't really affect speed much. Using both for all seems just slightly faster. _________________ "Change is inevitable; progress is optional" |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 15, 2006 9:29 pm Post subject: | |||||
|
|
|||||
Yep ... now I'm impressed :)
I don't currently have a hotkey for reset in fullscreen mode. I'll add it to my (rather large) todo list. Eventually I'd like to have a big list of actions you can assign hotkeys to, using either keyboard or joypad. |
|||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Oct 17, 2006 3:09 am Post subject: | |
|
|
|
| Testing with SMW or Zelda3 doesn't give the true picture of bsnes' (018) speed. Those are the least demanding non-special chip games when it comes to CPU requirements. I get solid 73fps in SMW,but these suckers aren't even playable with an AthlonXP 2200+ box: - Nitro Punks Might Heads (Rocky Rodent): 56 fps (gameplay, level 1 and 3) The shocker ! - DKC1: in the first bonus area in the first level,after getting Rambi the rhino and ramming through the first 'wall' you see -> ~59fps, sound crackles (In the main level,it's about 63fps : running fast through the level,bashing enemies to stress the CPU) - Front Mission: 54 fps at the weapons specs display demo. _SLOW_ .OK,this one is playable (66 fps ingame),but that demo is super sluggish. I'd love to see joypad-assignable emulation-specific controls. P.S. How many FPS do you get in SMW with the Core2 Duo if both cores are used 100% by one instance of bsnes? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Oct 17, 2006 4:47 am Post subject: | |
|
|
|
| Yes, but SMW or Zelda3 are games most people would have. It's hard to ask for performance comparisons on an obscure rom. There should be no surprise about performance dips when certain special effects have to be rendered. The most demanding effect I've seen in my testing is "Liberty or Death" at the end of setup. |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Tue Oct 17, 2006 8:06 am Post subject: | |||||||||||
|
|
|||||||||||
I'm using 2 cores at the same time for these and 1 instance of bsnes.
 
 
See first screenshot _________________ "Change is inevitable; progress is optional" |
|||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 17, 2006 1:09 pm Post subject: | |
|
|
|
| bsnes does not and cannot take advantage of both CPU cores. libco is cooperative, so no two threads are ever running at the same time. Honestly, by the time you even have a dual core processor, you're getting framerates like EMu-LoRd, or slightly lower. There's no reason to slow down single core CPUs to split the workload from 50% on one core to 25% on two separate cores. Especially since doing so would raise tons of new issues in coding. Mutexes, semaphores, critical sections, locks, forget about debugging, etc etc. Not worth it. | |
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Oct 17, 2006 7:52 pm Post subject: | |
|
|
|
| That's some very nice performance from the E6600 Now I just want to see a screenshot of Rocky Rodent level 1 with the NTSC filter on. BTW,what's that XP theme you're using? Or is that Vista RC2? |
|
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Tue Oct 17, 2006 8:04 pm Post subject: | |
|
|
|
| On
my crappy outdated p4 3gig, nothing has dipped below 70fps yet, but
that's cool with me since I only need 60 fps for smooth scrolling at
60hz. I haven't tried bsnes out on my newer comp yet, mainly because the graphics card is a littl weak in it, but the cpu is a lot faster and I have 2gigs of ram in it as well. I'll probably try it out today just to see how it performs. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Oct 17, 2006 9:26 pm Post subject: | |||||
|
|
|||||
I'll try that. Btw. have you tried Rendering Ranger? _________________ savestate editor: vSNES latest public version
|
|||||
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Tue Oct 17, 2006 9:47 pm Post subject: | |||||
|
|
|||||
Normal (left) NTSC (right)  
Here you go: http://www.crystalxp.net/galerie/en.id.130.htm _________________ "Change is inevitable; progress is optional" |
|||||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Tue Oct 17, 2006 10:39 pm Post subject: | |
|
|
|
| thats a notable performance difference _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Wed Oct 18, 2006 1:09 am Post subject: | |
|
|
|
| still 60+, i'm impressed. _________________ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Oct 18, 2006 5:33 am Post subject: | |
|
|
|
| I've
written a new scheduler for bsnes to take 100% full advantage of
cooperative multithreading. Now, bsnes only performs jumps directly
from one thread to another (CPU->SMP instead of
CPU->main->SMP), and even then only when absolutely needed (eg
CPU is accessing SMP when CPU is currently ahead of SMP). This unfortunately makes bCPU and bSMP no longer compile. However, it does yield some impressive speed gains. From 109fps to 125fps. By comparison, bsnes v0.017 yielded 128fps with my test ROM. The speed gain though is dependant upon how utilized the CPU<>SMP communication is, the difference in speed between v0.017 and my WIP can be anywhere between 1% and 10%, with the WIP always being slower. The better news is that this is still without IRQs fully optimized. I don't know how easy it will be to optimize these, if it's even doable at all... but if I can, that would yield another very important speed increase, making the next release the fastest ever. Here's to hoping. The bad news though is that cothreading's advantages are pretty much maxed out completely now. Don't expect any future leaps in performance from this. Still, overall... a 40% total speed increase and double the processor synchronization precision was definitely worth the effort, even for the potential loss of savestates. The scheduler should also make sPPU much faster when and if that's ever started upon, but that's still going to take a very significant speed hit over bPPU. One last benefit of the scheduler is that the new synchronization method isn't limited to only two clocks. I can now easily add another clock, eg for SFX/SA-1. Not that I'll be emulating either of those within the next year or two, though. Just saying... I might also make two schedulers, one for cothreaded cores and one for non-cothreaded cores. One thing is for certain though, I won't be writing schedulers for every combination of cothreaded<>non-cothreaded cores (there's 4 of them, CPU, SMP, PPU and DSP). And this will also rule out run-time polymorphism's compile-time option, so expect that to change to a compile-time only setting, meaning possibly two versions of bsnes in the future. Now then, I also fixed up S-CPU emulation mode opcodes. Direct page wrapping, stack wrapping with native mode opcodes and processor status flag fixes. No games use emulation mode, but accuracy is always nice. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Oct 18, 2006 7:25 pm Post subject: | |||||
|
|
|||||
Thanks, byuu. So you suspect stability issues with these changes? Because I sure haven't noticed any thus far.
If you mean for slowdowns, I went through three stages and stayed at 60fps. Comparitively, the Liberty or Death effect brings it down to 53fps. RRR2 though, is fun. Half platformer, half space shooter. I remember using it as opposition to nsrt including genres, but Nach just created two fields.
Speaking of NSRT, I checked out No-Intro the other day and I'm
impressed. The databases are great, although the website is nonsensical
and the name is dumb. I'll have to recommend them as well on the first
page.
|
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Oct 18, 2006 10:51 pm Post subject: | |||||||
|
|
|||||||
Yep
I see. LoD goes down to 29/30 fps here on this screen; RRR2 averages around 32 in the first stage. (P4 Celeron 1.7 GHz) _________________ savestate editor: vSNES latest public version
|
|||||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Thu Oct 19, 2006 4:21 am Post subject: | |
|
|
|
| [EDIT] R2 seems to be the most demanding non special chip game I've seen so far. Getting steady 60fps throughout 99% of the game requires an AthlonXP 2500+ at least,but there is one small part in this game that will put even a much more powerful CPU to it's knees - the small part at the beginning of the first shooter level where the blue lightning strikes. But the LoD effect is even mire CPU-munching. (surprisingly R2 is actually a *good* game,created by Manfred Trenz,the creator of the famous Turrican series).The shooter part is very good. I see a 10% speed improvement with 018wip2 (over 017wip22) The old 017 (final) is about 15% faster on my machine than 018 final,so 10% is a notable improvement. WIPs tend to be ~25% slower,as always,so Last edited by kick on Fri Oct 20, 2006 1:11 am; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 19, 2006 6:47 am Post subject: | |
|
|
|
| Ok, bsnes v0.017 ran at 128fps. Yesterday's scheduler raised the framerate of v0.018 from 109fps to 125fps. Today, I regressed the IRQ timing code to v0.017's method of testing ranges of positions at once, and then patched it to work with F1 Grand Prix, Sink or Swim, Battle Blaze, and my three IRQ test ROMs + two NMI test ROMs. In other words, it works with everything I have. The good news, it raises speed from 125fps to 145fps. This is way faster than even v0.017 now. Note, as always, these frame rates are comparisons with PGO disabled. The official builds use PGO and so are much faster than WIPs. The bad news, while the new code does work with all known examples, I simply do not feel good about it. I hate range testing the SNES interrupts, and I'm afraid extreme edge cases may still be missed. Not to mention the code is sloppy (by nature of what it is, a speed hack), and very hard to read / edit. But the speed difference is absolutely incredible for no perceived differences in any known games. Therefore, I'm going to use #define FAVOR_[SPEED | ACCURACY] to toggle between the two IRQ testing methods. I ask that you guys test the next WIP with all of the troublesome IRQ games, and let me know if any are broken. If none are broken, I'm planning on compiling v0.019 official with FAVOR_SPEED. Perhaps if someone wants to host the files, I can post a FAVOR_ACCURACY build for those of you with computers that can handle a significant speed hit with no perceived differences in emulation. |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Thu Oct 19, 2006 8:56 am Post subject: | |
|
|
|
Liberty of Death effect: _________________ "Change is inevitable; progress is optional" |
|
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Thu Oct 19, 2006 10:40 am Post subject: | |
|
|
|
| i'll be happy to host (and allow hotlinking) a v0.19 for you byuu _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. Last edited by franpa on Sun Oct 22, 2006 1:23 am; edited 1 time in total |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Fri Oct 20, 2006 1:17 am Post subject: | |
|
|
|
| I'm
also for the FAVOR_ACCURACY build.The ~10% speed gain from the new
scheduler is more than enough,while still keeping bsnes very accurate. A small overclock will do the trick for now,until the new PPU,but I'll upgrade to a C2D till then I'm very impressed with the E6600 Previous post edited and corrected,Emu-Lord.Read it again. P.S. Is the PGO final build MMX or SSE optimized? Switching to SSE[(1 at least)] makes a difference,especially on C2D and A64 CPUs. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 20, 2006 1:51 am Post subject: | |
|
|
|
| I
would probably agree with kick. Still, if it works with all the known
finicky games, and the test roms, that's impressive. You'll have to
decide if 10% is worth an extra version and the possibility of issues,
though. I barely notice a speed difference on my 2.4c. 52 dip vs 55 dip
on the LoD effect. #-C of (U) games tested. No bugs found. Your forecast of 5 bugs is probably a bit conservative, considering a lot of these games have (J) versions. I'm gonna say we might find one more in (U) and (E), but wouldn't be shocked if it was 0. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Oct 20, 2006 1:56 am Post subject: | |||
|
|
|||
I think, in this case, you meant his forcast was liberal. You're saying his forecast is too large, which would be liberal, rather than too small, which is conservative. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 20, 2006 2:09 am Post subject: | |
|
|
|
| Hmm,
I could be wrong. But wait... if bugs are a bad thing... then guessing
more will happen would be a conservative outlook, right? Guessing 0
would be more liberal/generous of an outlook? conservative = cautiously moderate liberal = favorable/generous Numerically, in this case, less is better. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Oct 20, 2006 2:48 am Post subject: | |
|
|
|
| Yes, you could think about it like that too. I think your explanation is technically right. The only problem being that, usually, when using the terms liberal/conservative in regards to estimates, a larger estimate is "better" and a smaller estimate "worse." But in this case, it's reversed. Ah, English. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 20, 2006 6:17 am Post subject: | |
|
|
|
| FitzRoy wins the AP English award :) I was being conservative by bracing for more (bad) bugs in advance. But I'm quite the pessimist, so that's normal for me. Anyway, I didn't notice much difference on P4 processors. I guess they're better at loops than A64s. I will try and optimize the "accurate" code, then. If they end up with <= 10% speed difference, I'll stick with just the accurate one in the next release. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 20, 2006 7:59 am Post subject: | |
|
|
|
| Ok, please
be courteous to my webhost and only download this WIP if you're going
to test it on a processor that hasn't been tested thus far. byuu.org/files/bsnes_v018_wip4.zip byuu.org/files/bsnes_tests.zip This has two separate builds. Neither have PGO, SSE, SSE2, ZIP or JMA support. They are identical except for the FAVOR_ flag define and title of the program. FAVOR_ACCURACY [bsnes_accurate.exe]: - Always tests OAM RTO flags even on skipped frames - Tests NMI/IRQ trigger every clock cycle FAVOR_SPEED [bsnes_fast.exe]: - Only tests OAM RTO flags on rendered frames (always with no frameskipping) - Tests NMI/IRQ trigger using ranges If you'd like to test, please run demo_mode3.smc on both versions of bsnes, turn off speed regulation, and report the framerate both with a frameskip of zero and a frameskip of nine (max), along with your processor speed. The other test ROMs are just to verify that IRQ behavior is still reliable in both versions. A blue screen indicates passing, they all pass on both versions. Don't expect test_* ROMs to pass on other emulators, but demo_* ones should. Example (my main PC): AMD Athlon 3500+ Accurate: - 121.5 fps w/o frameskipping - 171 fps w/max frameskipping Fast: - 146.5 fps w/o frameskipping - 271.5 fps w/max frameskipping ----- As you can see, there are major speed differences on my A64. Personally, I'm all for accuracy, but I also want people to actually be able to use this program in the interim. Perhaps in the future when a low end computer is a current low-end Core 2 Duo, we can remove all of the "speedhack" code. And in the meantime, the full 100% precision is there for people who have the CPU power to afford it. ----- If anyone wants to try and help, heh. src/cpu/scpu/timing/irqtiming_accurate.cpp and src/cpu/scpu/timing/irqtiming_fast.cpp are the two versions of the IRQ testing code. If you see any ways to optimize either (preferrably the former, obviously), I'd greatly appreciate it. Understand that both the CPU counters (VCOUNTER, HCLOCK) and the IRQ timing positions (VIRQPOS, HIRQPOS) can wrap not only the horizontal clock position (1362->0), but the vertical position as well (261->0). And also that they are "misaligned" by 10 clocks (which is really more of an internal CPU IC delay thing, we aren't entirely sure why the difference is there). You probably shouldn't mess with the code if you don't understand the implications of this on eg range testing :/ |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Fri Oct 20, 2006 8:40 am Post subject: | |
|
|
|
| Main PC: Intel Core 2 Duo 2.4 GHz (@stockspeed) Accurate: w/o frameskipping (left) - w/max frameskipping (right)   Fast: w/o frameskipping (left) - w/max frameskipping (right)   _________________ "Change is inevitable; progress is optional" |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 20, 2006 9:12 am Post subject: | |
|
|
|
| Cool. I like this better than doing a different core. Very generous to the people on the fringe without compromising perceived accuracy. | |
New Member
Joined: 12 Sep 2006
Posts: 9
| Posted: Fri Oct 20, 2006 2:24 pm Post subject: | |
|
|
|
| Since
Emu lord did the C2D I decide to do my work computer so you can get the
far end of the spectrum. It locked down from me being able to check the
exact processor in the bios(i don't have admin rights) BUt I know it's
an AMD runing at 1.0ghz with a big wopping 128km of ram. accurecy: no frameskip 32 FPS max frameskip 70FPS Speed no frameskip 35fps max frameskip 101 fps |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Oct 20, 2006 3:10 pm Post subject: | |||
|
|
|||
And much less effort on my part. Since we're discontinuing the PPC port due to not having a port of libco, I don't feel as bad about dropping bCPU/bSMP. Now the last problem to solve is how to pull off both bPPU and sPPU at the same time. Preferrably without needing to write two schedulers and riddle the whole project with #ifdefs. Pentium 4 1.7ghz Note: PC is loaded with 45+ background processes. Typical work PC. Accurate: - 29.5fps, 0fs - 82fps, 9fs Fast: - 31fps, 0fs - 108fps, 9fs Amazing that the difference on a P4 is only ~3-5%, but the difference on modern processors like the A64 and C2D is ~20-25%. |
|||
Paladin
Joined: 30 Jul 2004
Posts: 182
| Posted: Fri Oct 20, 2006 5:39 pm Post subject: | |
|
|
|
| CPU: Athlon64 X2 4400+ @2.2GHz Accurate no frame skip: 121fps max frame skip: 167fps Fast no frame skip: 146fps max frame skip: 272fps BTW, great work on the emulator so far, byuu. _________________ System Specs: 2.2GHz Athlon64 X2 4400+, 2GB DDR 400 SDRAM EVGA Geforce 7600GT 256MB Realtek AC '97 Microsoft Windows Vista Home Premium |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 20, 2006 6:41 pm Post subject: | |||
|
|
|||
Yeah, maybe it will have a bigger use for these new cpus when sppu is in. Any cpu that came out before 2002 is looking pretty sorry. P4 2.4C, Super Mario World intro: Fast: 76fps Accurate: 70fps "D, E" (U) games tested: no bugs. |
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Fri Oct 20, 2006 7:50 pm Post subject: | |
|
|
|
| Yeah I'm only seeing a 6-frame increase from accurate to fast on the P4 3Ghz. | |
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Fri Oct 20, 2006 10:29 pm Post subject: | |
|
|
|
| On an Athlon 64 X2 3800+ @ 2.5 GHz: Accurate: 137 FPS with frameskip 0 195 FPS with frameskip 9 Fast: 164 FPS with frameskip 0 305 FPS with frameskip 9 |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Sat Oct 21, 2006 2:53 am Post subject: | |
|
|
|
| Hmmm...not that shabby for a 'retro' AthlonXP 2400+ box @ stock speed (1.83GHz) w/1GB ram: Accurate ----------------------- Demo: 95 fps fs=0 128 fps fs=max SMW: 66 fps fs=0 Fast ----------------------- Demo: 109 fps fs=0 198 fps fs=max SMW: 74 fps fs=0 Tests: All tests pass (Blue Screen of Quality ).Is this some kind of MS joke?Just as expected,the 'F' version is about 14% faster than the 'A' version. I'm expecting about 84 fps in SMW with the final PGO'd 'A' version,and 96 with the 'F' version. I got the same difference when comparing wip3 to wip2. DKC2 will gain even more speed this time,thanks to the new scheduler. Note:PGO can improve performance greatly,something like ~29% in SMW So,the difference between Accurate and Fast builds is very dependent on the CPU type P4 CPUs will get a 5% boost plain Athlons get a 10% boost AthlonXPs get up to 15% Athlon64s get a 20% boost Core2 gets the most - up to 25% Not bad at all Interesting,this can also be used roughly as an indicator of the 'quality' of each CPU architecture:from P4 being the worst,to Core2 being the best so far. Now we need more P4 and D Celerons for testing.I think Celeron Ds can gain more than 5% Anything below a Pentium4/AthlonXP is just not enough,unless you use the fast version P4 Northwoods are actually _very good_,but those &^%$ "Press-Hots" are just terrible,so that 'old' P4 3.0GHz must be one of the 'good ones'A fullscreen reset key,sound channel enable/disable and gamepad 'shortcut' keys will be an added bonus for 019. BTW,does bsnes perform even faster if you don't have/use a gamepad? (joystick polling speed penalty) Cause I use one in all of my tests Also,where did the dd/d3d option go? It's not in the .cfg anymore. |
|
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Sat Oct 21, 2006 4:16 am Post subject: | |
|
|
|
| --bug-- start emulator go to configuration engage in full screen (while playing a game) press escape the game will minimize except for the configuration dialog and i cant restore the program unless i set it to window mode then to full screen mode. is it possible to access a gui while in fullscreen mode? _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Oct 21, 2006 4:32 am Post subject: | |
|
|
|
Opinions? |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sat Oct 21, 2006 4:41 am Post subject: | |||
|
|
|||
For consistancy, use white text for the "B" button and see if you can try a different color to blend it with. Though, I'm not sure if anyone needs to point out the directional keys with arrows... _________________ FF4 research never ends for me. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Oct 21, 2006 7:36 am Post subject: | |
|
|
|
| Good
crit. However, yellow simply needs to be paired with dark lettering.
Trying to get white to appear on yellow requires me to set it all the
way down to a dark gold, and even then it barely stands out. This way
also allows me to exactly match the icon's colors. EDIT: going with the bold crosshairs as well for balance and better use of space. Last edited by FitzRoy on Sat Oct 21, 2006 6:31 pm; edited 1 time in total |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sat Oct 21, 2006 10:10 am Post subject: | |
|
|
|
| Pad looks good, good job. | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sat Oct 21, 2006 12:17 pm Post subject: | |||
|
|
|||
|
What's wrong with how it's in bsnes 0.18? Anyway, pads from some games: link _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 22, 2006 7:26 am Post subject: | |||||
|
|
|||||
Not a lot, mainly just a few blending oddities and dullish colors. Shoulder buttons sink in. Y and B are misaligned. Controller is a bit shorter than real.
Thanks, I've seen those and at least fifty others (ah, the "benefits" of testing 1500 games). But last week I hit the holy grail of representations in Firepower 2000. Some time with me in photoshop, and you have another option. |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Oct 22, 2006 7:43 am Post subject: | |
|
|
|
| The
left pic looks much much better. I wonder if you could make the letters
a little thicker/bolder... it's not necessary, but the text is slightly
tiny. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 22, 2006 7:44 am Post subject: | |
|
|
|
| I
actually drew mine off a real SNES controller in Photoshop. The reason
for the blending oddities is due to scaling the original (~500x300)
image down to fit on the input configuration screen. Anyway, I don't like the blueish background much. Doesn't flow well with windows GUI colors to me. White or a grayish color I think would be best. Other than that, my only gripe is the B button color being different from the other buttons. No easy solutions there, of course. Nice jab with the icons on the bottom, too :P Now then, how about a logo while we're at it? Any takers? :D If so, I'm picky about the spelling, all lowercase please :) |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Oct 22, 2006 8:10 am Post subject: | |
|
|
|
| That left controller is awesome, i would use that one! as is! | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 22, 2006 8:49 am Post subject: | |||
|
|
|||
Was it a third party controller? But really, this is why I wished the controller image was referenced externally. Then users can replace it with their own, and I wouldn't have to try to argue for something that to me is superior. Apparently, I got lucky with the new icon The navy background with white text matches the area selection highlight, and the uppercase, white text is easier to pick up quickly or peripherally than black on gray or white (which is exactly what deathlike is picking up on, but fails to see the best, not better, solution). Also notice the left one's d-pad, and how the dark gray isn't different enough from the darker gray markings within it. This is aesthetically unpleasant and creates a distracting focal point. The reason I posted the icons is to show that no one besides myself saw or attempted to improve upon the color or shape problems, but that they nonetheless existed. Last edited by FitzRoy on Sun Oct 22, 2006 10:06 am; edited 1 time in total |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Oct 22, 2006 9:22 am Post subject: | |||||
|
|
|||||
Yep, that one looks good, too. Shame though that it's using the US colors.  _________________ savestate editor: vSNES latest public version
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Oct 22, 2006 9:43 am Post subject: | |||||
|
|
|||||
See: Super SWIV (E, J) If you're ever on "Who Wants to Be a Millionaire?" and they ask you anything pertaining to regional name differences on the SNES, go ahead and phone me. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Oct 22, 2006 10:46 am Post subject: | |
|
|
|
| Fitzroy we're slowly becoming living Snes databases |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Oct 22, 2006 2:16 pm Post subject: | |||||
|
|
|||||
Good to know. _________________ savestate editor: vSNES latest public version
|
|||||
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Sun Oct 22, 2006 11:06 pm Post subject: | |
|
|
|
| Does noone here use vector graphics? Like, Inkscape, or Xara Xtreme Linux? :/ | |
Veteran
Joined: 30 Jul 2004
Posts: 921
Location: Mexico
| Posted: Sun Oct 22, 2006 11:11 pm Post subject: | |
|
|
|
| I remember some dude did not long ago a snes controllers in vectors. It could turn out handy if it is still available. _________________ _-|-_ |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Mon Oct 23, 2006 3:58 pm Post subject: | |
|
|
|
| Here you go, in full glory: http://www.xs4all.nl/~vdnoort/misc/snes_controller.jpg _________________ "Change is inevitable; progress is optional" |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 23, 2006 4:25 pm Post subject: | |
|
|
|
| Are there any good freeware vector art tools for Windows? I wouldn't mind learning the basics of vector art. Side note, noticed an error with my S-SMP emulation of most of the mov opcodes. Apparently, they read the source address before writing. I think I remember reading that before, but never added it. This doesn't fix Koushien 2, but the game does seem to get to the third inning every time now, instead of dying on the first or second, so it's a start. I wonder how this behavior was discovered, since no games seem to rely on it. Now I also need to find out / test whether cmp opcodes actually write back the value read from memory, or if the last opcode cycle for cmp opcodes is simply an I/O cycle. Ah, also appears cmpw timing is taking 5 cycles. anomie's doc lists 4. Possibly a timing error. Also doesn't fix Koushien 2 (nothing ever does). |
|
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Mon Oct 23, 2006 11:37 pm Post subject: | |||
|
|
|||
Xara Xtreme and Inkscape are the only freeware vector art programs that are of professional quality that I know of .
|
|||
Veteran
Joined: 30 Jul 2004
Posts: 921
Location: Mexico
| Posted: Mon Oct 23, 2006 11:39 pm Post subject: | |||
|
|
|||
Not that one. The one I mean looked more like out of a blueprint, or something. Plus, that one is rasterized already. _________________ _-|-_ |
|||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Tue Oct 24, 2006 2:52 am Post subject: | |
|
|
|
| I have the .svg source for one that I did up tonight in Inkscape. I have a larger exported .png of it hosted on my linux box at http://wpage.homelinux.net/SNES%20Controller.png. It would take moments to add the "Start" "Select" "X, Y, A, B" labels, but I wanted to get some feedback. |
|
New Member
Joined: 19 Oct 2006
Posts: 2
Location: Waterloo, Ontario, Canada
| Posted: Tue Oct 24, 2006 3:05 am Post subject: | |
|
|
|
| You could use POV-Ray.
It is even useful for 2D graphics. I've never used it, but a couple of
my friends have made some nice icons with it. It might just be the sort
of thing you'd like to use, byuu, considering your apparent love for
precision. It's not a typical vector graphics program. Or you could just ignore POV-Ray and stick to typical vector graphics software. I'm no expert. |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Oct 24, 2006 4:32 am Post subject: | |||
|
|
|||
Go back to school and learn a thing or two about perspective. Or try Povray and model it in 3D so you don't even have to figure that perspective thing out. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Oct 24, 2006 8:57 am Post subject: | |
|
|
|
| Just following through on what my eyes picked up: Is that the vector art you're talking about MisterJones? Obvious problems are no color, and no shoulder buttons. Does give nearly exact positions and proportions though (like Super SWIV's) I was experimenting with windows schemes today, and realized that the navy selection doesn't stay navy with different schemes. For some reason, I thought that might have been defined in the program. So one strike against mine (still looks good on my windows scheme, though *grumble grumble*) FGHIJK (U) games tested. No bugs. Last edited by FitzRoy on Sun Apr 20, 2008 7:59 am; edited 2 times in total |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Oct 24, 2006 9:01 am Post subject: | |||
|
|
|||
lol, that might sound a bit harsh considering the guy was trying to help, but still, the perspective is indeed fucked up. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 24, 2006 9:25 am Post subject: | |||||
|
|
|||||
I see now. $00f1 (CONTROL) also has the ability to interface with the S-CPU, because if bits d4 or d5 are set, it clears port values to #$00. So S-CPU needs to sync CPU<>SMP on accesses to $2140-$217f, and S-SMP needs to sync SMP<>CPU on accesses to $f1,$f4-$f7. Super Bomberman 4 now works again, and better yet -- I understand why this time :D EDIT: aw. I accidentially edited my post instead of quoting it :( Background: I removed the SB4 fix hoping I could find out what was causing the "fix" to work, and maybe it would be related to Koushien 2. Sadly, it wasn't related. But still good that I know why the old fix worked, at least. Last edited by byuu on Tue Oct 24, 2006 4:04 pm; edited 2 times in total |
|||||
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Tue Oct 24, 2006 11:23 am Post subject: | |
|
|
|
| Stifu's about got it right. I have no eye for perspective or color, just giving it a shot. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Oct 24, 2006 6:40 pm Post subject: | |
|
|
|
| Koushien
2 has to be the weirdest bug ever. Fairly random each time. Sometimes,
the sound will speed up a minute before it crashes. Others, it just
cuts out completely. Sometimes the cut out and crash happens at the
same time (usually during a transition). EDIT: "L, M" (U) games tested. 1 bug found. *Mighty Morphin Power Rangers - The Fighting Edition (U) - corrupt sprite gfx during gameplay. Does not occur in .016, but does occur from .017-on. If it's WRAM related, I'm not counting it against my guesses |
|
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Thu Oct 26, 2006 1:54 pm Post subject: | |
|
|
|
| Currently I am following up with the apu opcodes. Koushien 2 reaches during gameplay the stop apu opcode (seems randomly like the crash bug) and loops in it. I don't know if only a reset can kill the stop state like the CPU. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 26, 2006 2:36 pm Post subject: | |||||
|
|
|||||
Didn't I already fix this game before? It's probably the damn memory mapper again. I can't seem to find a perfect map that works for all of these games that have to screw with what's at $[70-7d|f0-ff]:[0000-ffff]. If someone could please get me the PCB ID for this game, I can fix it for good by adding it to the ROM database. Overload's list does not have this game yet.
I've known that for a while. Something (likely S-SMP, possibly even S-DSP) is overwriting opcodes in the main program (stored in SPCRAM of course), and when the main program hits those overwritten opcodes, things crash. Problem is, the address overwritten never shows up in tracelogs, and every time I run another tracing set with explicit checks for writing to said memory location, the location overwritten changes. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 26, 2006 3:49 pm Post subject: | |
|
|
|
| You know, I was just praying to myself... "Please god, I want to spend the rest
of my life backtracing fixes to sCPU from bCPU. Fixing the first 287
regressions as a result of the CPU rewrite just wasn't enough... you
know? So please let new bugs just keep appearing forever and ever.
Thank you." ... and it looks like my prayers have been answered! Hooray! Well, whatever the hell the problem is this time, hopefully it's related to Street Racer, because I have no idea about that game either. M7A,B,C,D,X,Y + M7HOFS+M7VOFS all appear completely normal, even when the screen is glitchy, so tracking that bug would be quite difficult. (Street Racer also works with bCPU, of course.) |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 26, 2006 4:26 pm Post subject: | |
|
|
|
| "N, O" (U) games tested. 1 bug found (redundant) Outlander (E, U) - horizontal line issue on title screen. same issue as Mega lo Mania, not affected by hclock. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 26, 2006 6:12 pm Post subject: | |
|
|
|
| If it's the same problem as Mega lo Mania, then we should revert Winter Olympics to fix two games instead of one. EDIT: yeah, same issue. Swap Mega lo Mania with Winter Olympics, then, and consider Outlander "fixed". |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Oct 26, 2006 7:40 pm Post subject: | |||
|
|
|||
Nice to know you consider yourself a deity. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Oct 26, 2006 9:00 pm Post subject: | |||
|
|
|||
Bah. Why bother? It's very likely that Winter Olympics isn't alone either. Check on "The Adventures of Dr Franken (E)" bugging out similarly in .016-.017. Plus that, I just tested 1000 games since the Winter Olympics fix, and there's no way to know what that might have added for that side of things. Besides, line caching is not the problem. The problem is the scanline renderer. That is as I understand it. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Oct 26, 2006 10:05 pm Post subject: | |||||||||
|
|
|||||||||
Oops, nice catch. "I was just praying to $deity..." Alle hageln der grammatik nazi!
Because I want my bug list small dammit >_< If these are counting against me as emulation bugs, then I want to fix them... sPPU is not going to be an option for a very long time, and even then it's going to require a Core 2 Duo to possibly get 60fps, most likely. EDIT: damn. Yeah, Winter Olympics fixed Adventures of Dr Franken. Why do games insist on doing this weird crap >_< I'll try and look into something that gets all of them running, but don't get too hopeful.
Problem is, when you perform a DMA, there is a delay before an NMI will fire if the DMA goes over on top of the NMI trigger position. A delay too low and wild guns breaks, a delay too high and apparently power rangers and street racer both break. EDIT: Wild Guns needs a delay >= 2. I'm guessing the opcode for DMA is sta $420b in 16-bit mode, so the IRQ is firing immediately after the write to $420b, at the last_cycle event. I also believe this is where our false misunderstanding that DMA requires a 24-clock delay after writing. I think the DMA delay is the same as the sta $4200 NMI enable delay. If you write sta $4200 in 16-bit mode, an NMI will not fire at the last_cycle of that opcode, it pushes to the next opcode. I think DMA is doing the exact same thing. Anyway, Power Rangers needs a value <= 8, and Street Racer <= 16. So, a value of 2 allows all three games to work. Consider them fixed, and I'm somewhat confident it's a proper fix, but we're talking an extreme edge edge case (yes, an edge case of an edge case, gotta love the SNES). EDIT 2: Futher example of my DMA->NMI theorem:
Now, see in the correct one... DMA triggers at the sta $420b. It's actually only 8-bit so the opcode ends, and then one last CPU cycle executes (well, a work cycle but let's not get into pipelining here...), which is the opfetch for lda #$02. So now the only cycle left in lda #$02 is the operand load, as it's a 2-cycle opcode. So the DMA completes, and it's way past time to fire an NMI. So your last_cycle test trips NMI and it triggers. Once the lda #$02 opcode completes. And of course, this is incorrect, causing the massive screen flickering. My hypothesis is that both NMI and IRQ have an edge case where if the NMI or IRQ pin goes high immediately upon last_cycle event, the NMI or IRQ does not happen at this time. You can verify this behavior via rep #$20 : lda #$ff80 : sta $4200 : nop. The NMI fires after nop, not before. I believe DMA is invoking the same thing. NMI testing is forced to not trigger until the end of the DMA somehow, so it also hits this same edge case of "NMI tripped" and "we're at the last cycle of the opcode" at the exact same time. Therefore, a delay of 2 clocks means that last_cycle fails for lda #$02, and the next opcode, tsb $66 executes. This opcode's last_cycle event passes, and you get your NMI after this opcode. And hence, you get the correct result, and Wild Guns works. The theory does tend to complicate NMI/IRQ testing somewhat, however. I figured the CPU would be polling to trip these opcodes all the time, but it now seems more practical that it "catches up" when the CPU is active and [H]DMA is inactive. How this works, I don't know. I'd have to know EE a lot better than I do and see the hardware schematics to be certain. But I can at least emulate the effect using only a 2-clock "delay" after any [H]DMA events occur to protect against this edge case. The output results should be 100% identical to the SNES, given the same inputs -- hopefully, at least. |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Oct 27, 2006 12:01 am Post subject: | |||
|
|
|||
It is small! And you just made it smaller
I'll just add "needs sPPU" to these, and at least now it seems there is
only one oddball left. Besides, you can "fix" these any way you see fit
when testing is done, but we can't find them if line caching is taken
out.
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Oct 29, 2006 7:27 am Post subject: | |
|
|
|
| Sufami Turbo emulation: The way you have to load the carts is kind of screwy for now (you use a text file that lists which carts to load). I need to flesh something out that works well for end users. Ideas welcome. Note that both carts need to maintain their own separate save RAM files in order for it to be possible to play dual mode games. |
|
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sun Oct 29, 2006 10:31 am Post subject: | |||
|
|
|||
Hmm I have an idea of sorts..
Make sure the unload button gray out so they can tell there's no cart inserted. Other then that you could probably change the names. I didn't really put much thought into them. Edit: Fuck, that didn't turn out very well. The crap after the Surfami turbo name is supposed to be a single pop out menu. Also one thing I forgot was don't start the emulation automatically after they load one of the slots. Have them click power to start the emulation. |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Oct 29, 2006 10:49 am Post subject: | |||||
|
|
|||||
Sort of like this?
_________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Sun Apr 29, 2007 10:53 am; edited 3 times in total |
|||||
Regular
Joined: 21 Nov 2005
Posts: 216
| Posted: Sun Oct 29, 2006 10:51 am Post subject: | |
|
|
|
| That's exactly what I meant, thanks. |
|
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Sun Oct 29, 2006 10:57 am Post subject: | |
|
|
|
| Byuu,
there seems to be a bug in the scale2x rendering code; here's me
testing it in Seiken Densetsu 3 (using Jap original for testing
purposes): Normally it's fine: http://img120.imageshack.us/my.php?image=scale2xokaypk9.jpg But when dialogs are displayed... (pseudo hi-res mode?): http://img100.imageshack.us/my.php?image=scale2xbugme8.jpg I also wish filtering would actually work in that mode
but that's not so important.. this behaviour doesn't happen with any of
the other filters, though the NTSC one looks a bit off when no dialogs
are displayed, as it displays the very right edge of the last dialog on
the right edge of the screen.Edit: oh, I tested in bsnes 0.018 official, and that accuracy/speed testing build you posted the other day. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Oct 29, 2006 12:33 pm Post subject: | |||
|
|
|||
COOL!!!! thank you for adding this special hardware! |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 30, 2006 7:35 am Post subject: | |
|
|
|
| Hmm,
bad news. I misstepped and tried creating a new class to handle lists
of files associated with each ROM for the purpose of ST emulation. In the end, it turns out I went a little too far with overarchitecting the code. It makes more sense to leave things as they are, but modify Cartridge class to handle all files associated with it. Too many major code changes trying to redo that to safely undo, so I just went ahead and restored from the wip6 backup I had. Meaning, no more ST emulation, but only temporarily. wip6 was six days old, but I don't really recall working on bsnes much last week. I readded the Street Racer DMA<>NMI sync fix, and the newer versions of my base libs. Hopefully by next weekend I can have ST emulation added back in again, and on the plus side, this gives me more time to think how I want to add support for it. |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Mon Oct 30, 2006 5:23 pm Post subject: | |
|
|
|
| you should set up a SVN/CVS repository, if just for yourself. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Oct 30, 2006 5:57 pm Post subject: | |
|
|
|
| Cool, ST support. I wanted to wait for the new WIP to post this, because I wondered if it was related to street racer. It's not: "P, Q, R" (U) games tested: 1 bug found. R-Type III (U) - corrupt gfx during gameplay. Appears to have been introduced between .017 and .018. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Oct 30, 2006 6:30 pm Post subject: | |
|
|
|
| Funny
how it's always the same games that keep having problems. Ok, I'll use
revision tests to find out what change broke it, and hopefully fix it. S (U) is going to suck, as will likely T (U)... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Oct 31, 2006 6:52 am Post subject: | |
|
|
|
| "U, V, W, X, Y, Z" (U) games tested. No bugs. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 31, 2006 3:33 pm Post subject: | |||||||
|
|
|||||||
|
What happened to S, T (U) ? Heh. Working on R-Type III, I have the change narrowed down to v0.017.18 - v0.017.20. I didn't make a backup of v0.017.19, but that's ok. Also, the problem is with sCPU changes between those versions. That was the addition of timeshifting, so it may just be something like an IRQ going off on line 261 that isn't working correctly or something. We'll see... --- EDIT: alright, problem found.
The above code is basically writing #$20 to d5,d4 of $4200. My test ROMs indicate this continues to trigger IRQs repeatedly. However, R-Type III indicates this should not happen. There's obviously yet another factor at work here. My current theory is that testing may not occur at all when the I flag is set. This would cause testing to not occur until after the IRQ completes, once VCOUNTER is on another line (8 instead of 6), which would be too late for a VIRQ test to cause another IRQ to trigger. I will need to write more tests at home to verify. And I may have to wait until tomorrow to do this, have some plans for tonight. Last edited by byuu on Tue Oct 31, 2006 5:16 pm; edited 1 time in total |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Oct 31, 2006 5:13 pm Post subject: | |
|
|
|
| Im almost done with S and T-Z was already done | |
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Oct 31, 2006 6:28 pm Post subject: | |
|
|
|
| i have a question: I know taking advantage of dual cores is not possible for emulation itself, but wouldn't it be possible to use the other core for the rendering filters (such as NTSC) or possibly any other task not directly related to emulation? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Oct 31, 2006 7:19 pm Post subject: | |
|
|
|
| Ideally,
yes. Software video filtering could be passed onto another core. The
more important question would be if it was worth the speed gain for the
added problems. Especially since every dual core on the market can
already easily hit 60fps with current builds. If you were trying to use a monster filter like HQ4x which is more computationally expensive than emulating an entire frame of video, it would probably lead to a very decent speedup, of course. But now I have to worry about mutexes, critical sections, semaphores, locks, deadlocks between the two threads, even more complex debugging issues, etc. In short, I'm not really interested in all the additional work for the small gains associated with offloading the software filtering. Further that with the fact that most of these filters are now being performed using pixel shaders which require no CPU power at all. I think time would be better spent supporting those than in utilizing dual core CPUs; but that's also not a priority at this point. |
|
Regular
Joined: 29 Jul 2004
Posts: 203
Location: The Netherlands
| Posted: Tue Oct 31, 2006 10:20 pm Post subject: | |
|
|
|
| I
wonder however what kind of speed hit I'd get when turning on filters
like HQ4X with bsnes. NTSC already gave me speed drop but is still way
over 60fps. _________________ "Change is inevitable; progress is optional" |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Nov 01, 2006 5:52 am Post subject: | |
|
|
|
| "S, T" (U) games tested. No bugs found. Overall, I have a small list of possibles. Will wait until after R-Type to explore. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Nov 01, 2006 9:05 am Post subject: | |||
|
|
|||
Damn :( I don't think the R-Type III fix will correct anything else. But, cross your fingers I guess. The new WIP fixes the aforementioned game. My SNES tests seem to indicate that writing #$20 to $4200 when VCOUNTER==VIRQ will trigger an IRQ, even after an IRQ has already fired on said line. My tests today indicate that it will not trigger an IRQ under the above circumstances when the I flag is set. I don't know why, it's the only thing other than the final IRQ trigger test that cares what the I flag is set to. I'm not happy with the fix, but it's the only explanation I can come up with, and all IRQ sensitive games are running, as well all IRQ tests are still passing. So for now, it'll have to do. I'm going to attempt to document all of SNES IRQs and see if I can figure out a more simple method of emulating them, but I'm not hopeful. I also removed the "guessed" entries from my database. I've decided not to add anything unless we definitively know its' PCB ID, or in the case of ST games, if it doesn't have one. Lastly, rewrote my SDP page on my site. It now uses XHTML 1.0 + pure CSS2, so it should be a little easier on the eyes and a lot easier to write documentation pages for. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Nov 01, 2006 4:07 pm Post subject: | |||
|
|
|||
Did you test that page in IE6 or below? IE doesn't like the XML declaration (the first line), and it's not *required*, you might as well leave it out. However, that means that character encoding would have to be UTF-8, although I don't know if that matters to you. You definitely seem to like your tables . Don't like <div>s?_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Nov 01, 2006 4:22 pm Post subject: | |||||
|
|
|||||
Holy crap the entire page is flashing between no stylesheet and the full stylesheet in IE6. I better replace the @import with a PHP file copy/paste. Thanks, IE.
No. They don't work properly, they don't work the same in any major browser, and they're equivalent to using a chainsaw on a stick of butter when you're trying to design a site that utilizes the concept of columns (eg left-side is content, right-right is navigation index). The tables are done in 100% CSS2, so I don't see a problem with them personally. But if you have an easy way to implement columns in <div>s that work in all major browsers, I'll be happy to take a look at it. EDIT: ah, and no reason to clutter this thread with HTML programming stuff, please. PM is fine. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Nov 01, 2006 11:46 pm Post subject: | |
|
|
|
| Alrighty, the end of (U) brings a few more confirmations. J.R.R. Tolkien's The Lord of the Rings - Volume 1 (E, G, U) - flickering boot/head on intro Michael Jordan - Chaos in the Windy City (E, U) - corrupt gfx behind map, and second map effect has line issues Ninjawarriors, The (E, U) - sprites flicker during gameplay Toy Story (E, J, U) - sound effects linger or buzz sometimes between transitions I should note a few things here. First, Toy Story was already reported by tetsuo a while ago, and I just got around to verifying it. It's kind of hard to reproduce, you have to die a lot sometimes. Almost seems like you have to die in the middle of some sound effect or note to trigger it. The real system always cuts out silent with no issues. Seems related to Koushien, but this game never crashes. Second, I think Ninjawarriors and LOTR are the same issue. Seems to have been introduced between .017 and .018. If you stand in front of the green bikes and allow yourself to be hit, the sprites will flicker there as well. However, this flickering DOES happen on real, and .016 and .017 behave as they should. In .018, however, there is much more flickering which should not be happening. For whatever reason, the (J) version is without issue on any bsnes. For Michael Jordan, the real system displays black behind both map effects. All emulators I tested appear to display some kind of corrupt gfx grid behind the first map. It's a bug. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 02, 2006 12:26 am Post subject: | |
|
|
|
| Well
then, I'm pretty much done with this then. I simply don't have the
patience or perseverance to keep tracking these bugs down. I can't even
keep up with the new bugs anymore. Besides, there's simply no chance in hell I'm going to be playing Toy Story for several weeks trying to track down a sound bug that's only barely noticeable if at all. I got into this to work on emulating great games like Final Fantasy, Metroid 3, Chrono Trigger, Tales of Phantasia, Star Ocean ... and all I find myself doing is fixing absolute shit I never knew existed like Toy Story, Bugs Bunny, Koushien 2, three different Power Rangers games, RPM Racing, Battle Blaze, Super Conflict ... Consider them all broken for good. I have no intentions of working on any of these bugs anymore. Sorry, two years is enough for me. I'll keep working on other useless stuff like a dot renderer and the ever elusive cross-platform GUI library, but that's about it. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Thu Nov 02, 2006 1:45 am Post subject: | |||
|
|
|||
I'm saddened to hear this. Note that I couldn't agree more about the crap like Power Rangers or any other crappy games like that (and God knows the Super NES had it's share of crappy games), but I guess from an accurate emulator point of view "All games are created equals" lol Imo the bug regressions thing is probably unavoidable. Until not so long ago, bsnes almost had zero regressions. But as you said yourself, the closer you get to perfect accuracy, the more often one fix will break another thing...Even if say version 0.19 has bugs that weren't present in 0.18 it's not that big of a deal.Hell, Zsnes had counless fix/regressions/fix/regressions/fix... over the years. But ultimately, it's your emulator. /Snarkarob (praying byuu was only momentarily pissed...) |
|||
Deus ex Machina
Joined: 28 Jul 2004
Posts: 1323
| Posted: Thu Nov 02, 2006 5:54 am Post subject: | |
|
|
|
| Hey, Bugs Bunny in Rabbit Rampage is a decent game. _________________ "Dearly beloved, we gather here today to join this wooden stick, with Aerdan's butt, in holy matrimony, and may they not part until death, or perhaps extremely powerful bowel movements." - Metatron at the wedding of Aerdan's butt and a stick |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Nov 02, 2006 2:22 pm Post subject: | |||||
|
|
|||||
Sounds like fun. Might simplify the code a bit, too._________________ savestate editor: vSNES latest public version
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 02, 2006 4:10 pm Post subject: | |||
|
|
|||
No, I'm quite serious. I'm obviously incapable of fixing S-APU related bugs (Koushien 2, Toy Story, ...), require a dot-based renderer to fix some bugs (Mega lo Mania, Outlander, Uniracers, ...), am just plain embarassed to be seen "playing" some of these games at work (Toy Story, Michael Jordan, ...), and am absolutely sick of regression bugs (LoTR, Ninjawarriors). Besides, fixing any of these will just break other games anyway. I think it's best to just leave the crappy games broken. And who knows, maybe if I start working on core emulation and my own custom tests again, some of these will fix themselves. Sorry. --- So anyway, I've probably mentioned this in the past, but how does everyone feel about a raster based UI, ala ZSNES but attractive? I'll either have to create a more limited UI than I currently have and a cross-platform wrapper for Win32 API + GTK+, etc etc. and only allow building on ports that have said wrapper, or I can design a raster UI that will build on any platform one can get a framebuffer on (including consoles like the PS3, assuming the newer systems ever get cracked, heh). The raster UI also has the key advantage of being 100% completely controllable using a joypad; as well as allowing the UI to be visible in fullscreen mode with triple buffering. I would basically design it to run at any resolution and be totally themeable. The only thing I see as very impractical would be using 256x224 mode. The downside of a raster UI is that even the prettiest raster would still look a lot worse than one's native UI, IMO. I really don't want to maintain two separate UIs, though I guess I could do that for just Windows, and let Linux et al use the other one. Yeah, that's probably what I'll end up doing... |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Thu Nov 02, 2006 8:16 pm Post subject: | |||||||
|
|
|||||||
Oh. I was afraid you were thinking of abandoning bsnes and/or your goal of making bsnes a highly accurate emulator. I definitely agree with your logic then. Request: could you post some of the past binaries on your site? 0.17 would be nice to have, since it plays fine some of the games that broke between 0.17 and 0.18 (R-type for example)
Sounds good, although I think visually Zsnes's GUI is pretty solid. Personally I tend to prefer GUIs that move away from the very generic windows-style interface (a la Snes9X) but I know there are as many people that prefer the more traditional style, so it's all personal preferences. |
|||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Nov 02, 2006 9:39 pm Post subject: | |
|
|
|
| I'd be interested in seeing what you can do with a raster-based UI. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 02, 2006 10:08 pm Post subject: | |||||
|
|
|||||
Fine, fine. Yes, same issue as Mega lo Mania and Outlander: OAM caching. So now that's four games broken with it, two games broken without it. I'm making it a config file option, and I'll even stick it on the emulation settings page. Default will be off, sorry TRAC. Too many games are affected by this. And again to reiterate, there's no way in hell you're getting me to play Toy Story for the next three weeks at work. Not going to happen. Perhaps we can beg DMV27 to take a look at this one? :) Otherwise, see if it happens in another emulator, and I can see if any other emu authors care to investigate. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Nov 02, 2006 10:42 pm Post subject: | |
|
|
|
| If you're referring to me, I said I wanted you to not spend any more time on Toy Story or Koushien. I'm satisfied with the line caching option, though I'll have to shuffle my buglist. So technically, that means sPPU is once again needed to fix those games proper. That leaves Jordan all alone. Now this is one you might be able to get someone else to look at, as it happens in all emus. As per request, I'm finishing (E) this weekend. "#, A, B, C, D, E, F, G, H, I" (E) games tested. No bugs or possibilities. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 02, 2006 11:19 pm Post subject: | |||||
|
|
|||||
I say keep all the games that are there already; and add Winter Olympics + that European game as well. I recommend moving them to a separate section and mentioning the config file option to toggle the behavior and which it needs. I'm going to name the option something like "bppu.hack.___" or "hack.bppu.____" or something, just so it's clear what it is. The scanline render position option shall be similarly renamed. I've been planning to write an article for SDP explaining in detail the accuracies and shortcomings of all emulators. I'll be sure to discuss the above two issues involving the PPU there, so you have something to link to explaining the issue in more detail. sPPU is going to be really, really really really hard to make. And I doubt it will even fix these issues for a long, long time. Not to mention the monstrous CPU requirements it will need. As for Michael Jordan, yeah. I can't test SNESGT because it crashes when I load the game, but all five other emulators have the exact same corruption on BG2, and line glitchiness on the next screen. I posted about this on the SNES9x forum to see if anyone wanted to help. Still interested to know about Toy Story in other emulators; especially the grandmaster of the S-DSP, SNEeSe.
Neat! I was exepecting a lot worse from PAL region timing. Would you mind testing all of the other regions while you're going through (E), since there's only ~40 of them anyway? :) Up to you though, we can do a separate run through those after (E) as well. Once again, I thank you for so graciously testing all of these games. We now have a clear understanding of the exact importance of truly accurate PPU emulation. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Nov 02, 2006 11:27 pm Post subject: | |
|
|
|
| I did those smaller regions a while ago. I could go through them again, but I doubt we'd find anything new. | |
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Nov 02, 2006 11:28 pm Post subject: | |||
|
|
|||
In brief, why? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Nov 02, 2006 11:38 pm Post subject: | |||||
|
|
|||||
Oh, really? Neat. Less to worry about. So then, (E) will finally finish this. Yay!
Think of the PPU as a signal processor, and not as an instruction processor. The PPU has its' own internal program that we cannot see. The only way we can give it input is by writing to the CPU at very specific times. The only way we can see the results of that input is by looking at blurry images produced on TV sets. We have to basically reverse engineer the entire internal logic of the PPU through experimentation. Think of it as the same issue as the DSP-1. Only the PPU is an order of magnitude or two more complex, by nature of having 64 different registers, each with several controls each, that all interact in strange and frightening ways. Further, the PPU is actually two separate processors. So I either need two separate cothreads for PPU emulation, or I have to find a way to merge their behavior into a single thread. Either way will not be easy. Trust me, there's a reason this has never been done before. And why even the NES scene still doesn't have a fully functional dot-based renderer despite having people smart enough to design actual physical hardware for testing the internal behavior of these chips. |
|||||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Thu Nov 02, 2006 11:51 pm Post subject: | |||
|
|
|||
In regards to LOTR, I remember pf telling me something to the effect that when you told him some info on correcting IRQ, he tried it and it worked good but broke LOTR. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 03, 2006 12:39 am Post subject: | |||
|
|
|||
Yes, unfortunately IRQs are ridiculously complex. I keep finding out new stuff every few days. I can try and get an updated document on IRQ behavior for pagefault if he's interested. But I'm still not confident I have the behavior down 100%. No emulator does, for what it's worth. Regarding that little flickering dot in the intro of LOTR, that is definitely related to the OAM caching code, because I changed exactly that and the problem went away. Reverted it and the problem reappeared. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Nov 03, 2006 2:00 am Post subject: | |
|
|
|
| byuu, why is a dot-based PPU any harder than a scanline PPU? Or, conversely, why are scanline PPUs comparatively easy to create? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 03, 2006 3:47 am Post subject: | |
|
|
|
| I thought I just explained why x.x Ok, think of it like this. There are ~224 scanlines in a frame. There are ~341 dots (256 visible) dots on a scanline, ~76,384 dots in a frame. The PPU clock runs at 2-4 times that (2x from the CPU's perspective). So, essentially, the dot based renderer has to break things down to be 682x more precise than a scanline-based renderer. Just stepping dot by dot as if it were a scanline based renderer would be easy, just a lot slower. But actually gauging what happens when you write to registers during the active display, is quite a lot more complex. If you still don't follow, I'm sorry. Just trust me that it's a lot harder :/ |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Nov 03, 2006 4:06 am Post subject: | |||
|
|
|||
I've changed my description of this bug to elaborate that this is not intro specific. If you start a new game and walk in front of one of the sitting hobbits, cancelling out the dialogue, you'll see that whenever a sprite tries to occlude another sprite, it flickers heavily - just like Ninjawarriors. It's just easier to see on the intro because that pixel is the only place where a sprite was positioned occluding part of another. Most of the time, this is supposed to happen on real hardware (Contra III 2 player, Kamen Rider), but I noticed LOTR as a possible bug because that was one of the games I used to own as a kid and I've seen the intro a hundred times before. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Fri Nov 03, 2006 5:51 am Post subject: | |||
|
|
|||
That's what I was looking for. Thanks for the explanation. I trust you that it's a lot harder; I'm just interested though. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 03, 2006 7:58 am Post subject: | |
|
|
|
| Ok,
the new WIP adds ppu.hack.obj_cache = [true/false], and renames the
scanline render pos to ppu.hack.scanline_render_position = [dec]. OBJ cache defaults to off now, as two bugs are better than four. Made SDP a bit more friendly to view now. I may port that style over to my main website, too. Specifically the non fixed width part. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Nov 03, 2006 9:33 am Post subject: | |
|
|
|
| byuu,
I think I'm going to appeal for hclock to be defaulted to ~512 for
future versions. I've been testing with it for a while now, and it
seems stable while fixing line issues with: Battle Blaze (swirling ghost, final boss effect) Super SWIV/Fire Power 2000 (title screen) Super F-1 Hero (gameplay) Jurassic Park (intro effect) While true that Super F-1 Hero has an issue on real hardware, the scanline renderer can't reproduce it correctly anyway. At least 512 looks nice. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Nov 03, 2006 11:28 am Post subject: | |
|
|
|
| Fitzroy your on a roll! Great work man. Byuu, im glad your finally pissed at these bugs! Its better to tackle the core emulation with all know bugs in hand, than to try and fix those horrible games one at a time. Eventhough the final buglist is going to be +/- 5 to 10 games or so, keep in mind that your emulator still has the highest compatibility without hacks of any snes emulator. Also im guessing your emulator is the first to have a full testrun of all know snes games done for it, as we have found at least 3 bugs that happen in other emulators. As far as i can see, exclusing those bugs your core emulation is basically finished, as you say yourself the only further core enhancement that can be don is the dot based renderer. The rest would be special chips and hardware |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 03, 2006 4:23 pm Post subject: | |||||
|
|
|||||
Ok, I'll try and remember to set it to 512 tonight. Remind me if I forget, please.
Eh, the differences between bsnes and other emulators are infinitesimal compared to the differences between bsnes and real hardware. It's also debatable that my entire PPU core is a giant hack (hence the config file hack options) targeted toward speed and compatibility. The first thing I need to do is add a timing system into bPPU, and add cothreading support to it, so that I can actually build both bPPU and sPPU into the same emulator. Right now, I can't even start on sPPU without having a completely unplayable emulator result. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Nov 03, 2006 7:52 pm Post subject: | |||
|
|
|||
Cool, thanks. Now users will hopefully not have any reason to dick with hclock and bsnes will be better out of the box. 400-700 seems to be the sweet spot. I don't think anyone's going to care much about anthrox or super f-1 hero not showing their graphics anomalies if that's what it takes to prevent the ones your emulator might introduce. Scanline-based renderer may be a hack, but it's a hell of a good one to achieve 99.98% identical game output without being per-game specific, and have a 50% speed benefit. Practically an optimization if it weren't for a few shitty games wanting line caching. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 03, 2006 9:06 pm Post subject: | |||||||||
|
|
|||||||||
Well, we can't have that, can we? Before:  After:  
I was hoping so, but my impatience got the best of me again. What can I say, "if you want something done right...", heh. For those interested (read: all SNES emulator authors): Our old formula for all scrolling registers, $210d-$2114 was:
Now, this makes sense. The &~7 is identical to the effect seen in offset-per-tile mode. However, the effect does not apply to OPT VOFFSET modifications. The reason is obvious for OPT, the SNES can easily update VOFFSET, but since it renders tile by tile, it has trouble with those low 3-bits of HOFS. So then, why were we applying to to BGnVOFS as well? We shouldn't be. The following fixes Michael Jordan: Chaos in the Windy City to work exactly as FitzRoy and I have observed on a real SNES:
Since I'm at work, I can't write any tests on the real SNES. And honestly, I'm kind of not wanting to. This seems to work great and makes perfect sense, so I'll leave that to someone else. Theme Park should be retested with these changes, since that was the game that convinced anomie to continue reverse engineering these registers in the first place. Anyway, long story short, the old algorithm was resulting on all of the "hidden" scanlines being indexed at Y=VOFFSET+BG2VOFS==224, excluding every 8th line, which hit the &~7 edge case and caused the backscreen area to get rendered instead (see those white lines in the before screenshot at the bottom? that's where they come from). With the above changes, it always indexes at Y=VOFFSET+BG2VOFS==223, which is black tiledata. Much better. EDIT: yeah, Theme Park (J) still works fine with the above changes. No differences at all that I can see. Previous reference for those who need a refresher on how these registers work: http://www.snes9x.com/phpbb2/viewtopic.php?t=1715& |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Nov 04, 2006 12:19 am Post subject: | |
|
|
|
| Brutal |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Nov 04, 2006 10:38 am Post subject: | |
|
|
|
| Redesigned
my site a bit. Look ok? Mostly just moved everything I could into a CSS
stylesheet, allowed the content window to expand to the full width of
the window, added in a proper firefox scrollbar hack (so it's always
visible and doesn't cause harsh repositioning of the contents menu),
and took advantage of the CSS3 opacity property for browsers that
support it. Hopefully the text isn't too hard to read, opacity is an inherited attribute, so the entire page acquires the attribute, even text o_O. No way to override that, but this is a million times easier than four separate translucent PNGs, and even better -- it doesn't totally break the color scheme in browsers that do not support opacity. I should be able to design a few alternate stylesheets now as well. |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Sat Nov 04, 2006 11:30 am Post subject: | |
|
|
|
| Site looks good, text is totally legible, no worry... | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Nov 04, 2006 1:35 pm Post subject: | |
|
|
|
| Wohoo another bug fixed! byuu, the site looks great now! the old feeling back but with a new better look |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Nov 04, 2006 10:48 pm Post subject: | |
|
|
|
| "J, K, L, M, N, O, P, Q, R" (E) games tested. 2 bugs found. Mystic Quest Legend (E) - hangs on mountain entrance transition. -Appears to have been introduced between .017 and .018 offical. (J) and (U) versions of the game seem unaffected. RoboCop vs the Terminator (E, J, U) - screen flickers during gameplay -We knew about this one earlier, but it appears to have been re-introduced from the R-Type III fix between .018 official and the latest WIP. Don't flip out too much, byuu, this isn't that bad of a result. By the way, I have some other interesting news to report. Koushien 2 randomly crashes Sneese, and Toy Story's sound issue is also present in TRAC's emu. So you two have something in common here. Surprisingly, neither game has issues in ZSNES. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Nov 05, 2006 2:09 am Post subject: | |||||||
|
|
|||||||
FAVOR_SPEED it is from now on. Wonderful. I don't know what the fuck is wrong with the other IRQ testing method. Whatever, it'll work in future WIPs, and they'll be faster too.
It's either this game or R-Type III, then. They expect the exact opposite behavior of each other. And since R-Type doesn't suck, this one stays broken. All IRQ stuff as usual. I can't get IRQ emulation that works everywhere no matter how hard I try. I've spent probably 20-30% of all bsnes development time trying to understand them. The SNES just has an absolutely ridiculously complex IRQ system.
Hopefully TRAC won't mind taking a look at these games, then. I guess Koushien 2 is most likely S-DSP related then. Perhaps the echo buffer writes are going to the wrong address, I don't know. I know barely anything about the S-DSP. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 05, 2006 3:43 am Post subject: | |||
|
|
|||
Could you elaborate on this a bit? I just want to know if there's any chance that this could break more games than it fixes. I can't really backtest 3000 games and was under the impression that favor_accuracy was something of a safety precaution that could never exhibit more issues than favor_speed. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Nov 05, 2006 3:47 am Post subject: | |
|
|
|
| The two FAVOR_ switches just go between the two separate IRQ testing routines. Apparently, FF:MQ (E) is hitting some sort of edge case in the ACCURACY one, causing the game to crash. I'm not sure what's causing it, just that SPEED works fine, so for now, SPEED it is. I'd prefer you finish testing S-Z (E) with the WIP you have (which is set to ACCURACY, obviously), and I'll work out what's wrong with ACCURACY later when I'm feeling more masochistic again. | |
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Sun Nov 05, 2006 1:45 pm Post subject: | |
|
|
|
| Aah...the WIP News page scrolls very,very slowly with Firefox 2.0. 100% CPU usage and slow as &^*% with smooth scrolling.Haven't seen any page do this before (and I'm even using a PGO SSE optimized Firefox) Weird. | |
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Sun Nov 05, 2006 11:44 pm Post subject: | |||||
|
|
|||||
That seems to be exactly what the game is doing.
When the game wants to change the echo buffer address, it first sets EDL to zero, then changes ESA, and finally it disables echo writes. However, sometimes an echo write will happen between ESA and FLG, which can be seen by the change in ad -> ad + 4. The write can happen anywhere between 0xF800 and 0x1800. Either the game requires insane sub-sample accurate timing, or one of those register writes sets "echo_index = 0" and possibly sets "echo_target = echo_size". In Toy Story, if you pause the game while a sound effect is playing (such as an airplane or helicopter) sometimes the effect keeps playing with the music muted. I don't know if this happens on real hardware. Also, this problem might be related to the extended buzzing sounds that happen in "Dokapon Gaiden - Honoo no Audition" and also the BS version which NSRT labels as "Hono" instead of "Honoo". The sounds usually occur during screen fades from the battle action to the battle menu. These bugs might have something to do with the KON/KOFF register decay that breaks Der Langrisser, but I haven't tested it yet. Also for anyone interested: Clay Fighter 1 and 2 both require BRR decoding to never stop, even after KOFF is set or a sample ends. This is mentioned in anomie's dsp document, but these are the only games that I know of that require this behavior to work properly. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 05, 2006 11:48 pm Post subject: | |
|
|
|
| "STUVWXYZ" (E) games tested. 1 bug found. Secret of Mana (all regions) - mode7 map after intro flickers. Pretty much the same thing as Street Racer. Welp, first run-through has come to an end. Won't be doing that again for another few years. Basically, all that's popping up anymore are these IRQ edge cases affecting good as well as bad games. So if you ever figure out the last pieces of this IRQ puzzle, you'll be sitting pretty. Lastly, I take back what I said about hclock. Removing line caching changes the behavior of some games and 512 is no longer recommended. Everything except Jurassic Park now works okay at 224, including anthrox. 256 breaks Super SWIV. I'll just stfu about hclock from now on since it's confusing the hell out of me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 06, 2006 2:58 am Post subject: | |||||||||||
|
|
|||||||||||
Hmm... if you can think up any tests for this, we can try it on hardware to see. I'd probably need an SMC to run on the copier, though. I'm incredibly awful at writing tests for the S-DSP. Though obviously it's time I start learning... I hope we don't need sub-sample timing, because there's no way we're going to be able to reverse engineer that kind of information without some special testing hardware I don't have access to. Though simply increasing the clock rate >32khz won't be a problem for me, at least.
It's a real shame anomie isn't around much anymore, because I really can't offer you any insight here. Perhaps I can direct TRAC to this thread to see what he thinks. Thank you very much as always for looking into these issues for me. If you can think of any way for me to help, I'll be very happy to.
Does anomie's S-DSP core always run BRR indefinitely? I haven't noticed any issues in Clay Fighter 1 or 2 yet.
Thanks a million for testing all of those games for me. We shouldn't have to retest everything anyway. We know it's the same games that keep breaking and rebreaking again, so we really only need to retest those on occasion. The majority of SNES games, it appears, were written by people with a clue. But by testing all of them, we've uncovered a dozen or two of the worst games ever written. Lucky us.
... so what do you want hclock to be set at from now on? >_< Yeah, this is why I dislike hacks so much. But this one's going to be necessary for a long while, unfortunately. As an aside, I'm working on adding back in ST support. I have the single cart mode mostly working now. I've decided to go with fixed names for the BIOS files, and add a new "path.bios" config file variable for specifying the folder to find all of these files. I'm also going to give in and start sticking folders in with releases of bsnes. The default for path.bios is "./bios" now. |
|||||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 06, 2006 4:06 am Post subject: | |||||||
|
|
|||||||
No problem, glad it's done. On the IRQ thing, yeah we seem to have enough example games. My list now looks like this: Watchables ---------- Zan III - Spirits Energy Breaker Jumbo no Ozaki Hole in One Sink or Swim World Class Rugby Bugs Bunny - Rabbit Rampage IRQ Watchables -------------- Chou Aniki Mystic Quest Legend Wild Guns Street Racer Robocop versus The Terminator R-Type III Might Morphin Power Rangers - The Fighting Edition Secret of Mana If you can get all the games on the second list working at once, and the fix makes sense to you, the likelihood that you've figured out IRQ is that much greater. That's the benefit that hopefully all this testing has given you. By the way, I just investigated DMV27's suspicion regarding the sound effects persisting after pausing the game (Toy Story). I just verified that this does NOT happen on the real hardware. It cuts off clean every time, and zsnes does it right but bsnes and sneese sometimes persist the plane engine sound effect through pause. This is MUCH easier to trigger and hear than the other bugs, so hopefully that helps you guys track this down, whatever it is. Great discovery, DMV27.
Which is why I've been trying so hard to find the best value. A perfect value apparently doesn't exist. 224 would be perfect if it weren't for stupid Jurassic Park. At 512, NHL 94/Super SWIV screw up and Anthrox/Super F1 are further from their true output. Line caching was apparently Battle Blaze's problem, and it works fine now at lower hclocks. So I recommend 224, I guess. If new information comes up, great, we can change it again. Not a big deal, I guess.
thankyouthankyouthankyou.
|
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 06, 2006 7:51 am Post subject: | |
|
|
|
| Ok, the new WIP is extremely fragile with ST stuff, but it should work if you're careful. It took a lot of rewriting to get those damn dual carts booting. Right now, everything but the SD Gundam games are in the database. I need to think of a way of combining those. So, the only other dualable game is SD Ultra Battle - Ultraman Densetsu + Seven Densetsu. Otherwise, test with just one ST cartridge at a time. Anyway, it's definitely a work in progress, so be gentle with it. You need "stbios.bin" in bsnes.cfg::path.bios for it to work. It probably won't even give you an error if it isn't there. Suggestions for how to layout the file menu are welcome. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Nov 06, 2006 10:36 am Post subject: | |
|
|
|
| Damn fitzroy, your lightning fast! where do you find the time!! I'm glad the testrun is finished, now that all games have been tested we have the final buglist. with this information in hand all there is left to do is figure out those IRQ's do PAL timing/irq tests and hope blargg soon creates the PAL filter (because then i can retire my snes) |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 06, 2006 6:15 pm Post subject: | |||
|
|
|||
Mystic Quest Legend (E) mystery solved.
See, after the WAI instruction, it's waiting an entire scanline. Problem was that I was never testing IRQ when IRQ lock was set, even for HIRQs. That was incorrect, the IRQ lock was only something that occurs with VIRQs. Since VIRQs do not test HCOUNTER at all, it needs a lock to prevent IRQs from firing repeatedly on the same scanline. With HIRQs, it's an exact comparator, so since HIRQPOS == 232*4, and HCOUNTER == 882, the IRQ should fire at V=7, not V=8. This is fixed, so Mystic Quest Legend (E) now works with both FAVOR_ methods. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 06, 2006 6:35 pm Post subject: | |||||
|
|
|||||
|
And here's info on Robocop <> R-Type III: Robocop:
Robocop expects that writing $4200.d5,4 = #$00, $4200.d5,4= #$20 with IRQ flag set and when VCOUNTER==VIRQPOS, that upon clearing the I flag (with rti in this case), that an IRQ will immediately fire. R-Type III expects the exact opposite.
Same exact behavior, writing #$00,#$20 to $4200.d5,4 during an IRQ where the I flag is set, and then returning. If an IRQ triggers upon returning, R-Type III breaks. If an IRQ does not trigger upon returning, Robocop breaks. I have no idea what I'm missing. |
|||||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Mon Nov 06, 2006 11:32 pm Post subject: | |||||
|
|
|||||
The
only difference that I can see is that Robocop first clears the VIRQ
flag before setting it, while R-Type does not clear it before setting
it. Also in Robocop the IRQ triggers at VCOUNTER(32) == VIRQPOS(32)
while in R-Type the wrong IRQ triggers at VCOUNTER(8) != VIRQPOS(207).
The problem most likely has something to do with the echo_index and echo_target variables. Setting "status.echo_index = 0;" and "status.echo_target = status.echo_size;" after writes to the EDL and/or ESA registers should be enough to fix Koushien 2, although it might not be hardware accurate.
Yes it does. If you disable it, the intro song in CF1 will break and the game will freeze after a while. In CF2 the game will freeze before reaching the first menu. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 06, 2006 11:43 pm Post subject: | |||||||
|
|
|||||||
Nothing happens when you write #$00 to VIRQ. The VIRQ will have already triggered so lock will be on. It's the #$20 write that's re-enabling it. R-Type III also changes $4209 (VTIME) to something other than what VCOUNTER is currently set to, I think that's somehow unlocking IRQ. Almost as if the IRQ poistion always has to be tested, and the I flag is just delaying the trigger point of a positive test, or as if the $4209 write is clearing the "pending IRQ" flag. Not sure which is happening right now. The former is unrealistic and complex, the latter breaks demo_nmi.smc test 2 (I'd need to be at home to look at the documented source for it). I also noticed that Robocop is not reading $4211, which supposedly causes repeated IRQs to fire. Maybe that has something to do with it? Sigh...
Hmm. I'll have to research this and come up with tests to run on the SNES, then. Thanks for the info at any rate, it gives me a good starting point for trying to figure out what's going on.
Ah, thank you. Good news :) I spoke with TRAC about the S-DSP stuff, I don't think he's going to be able to assist unfortunately. Though we were heavily discussing the idea of a subsample-based S-DSP core running at 1.024mhz (well, both the S-SMP and S-DSP running at 2.048mhz, interleaving bus accesses to APURAM, but effectively executing at 1.024mhz each). That's going to be... very very difficult to try and emulate, to say the least. Not to mention the $00f0 TEST register S-SMP clock speed setting throwing things off even more. But that, a clock accurate S-PPU, and fixes to S-CPU and we should be about as accurate as we can possibly get with emulation. Look forward to this in about 12 years from now :P |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 07, 2006 6:40 am Post subject: | |||
|
|
|||
I hear ya, buddy. You at least got the Japanese design, though. Mine is a yellow, gray, purple, boxy piece of dog crap. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 07, 2006 8:55 am Post subject: | |
|
|
|
| Ok,
Sufami Turbo is finished. Now I just need to add back in cheat/patch
loading, and that should do for src/cart modifications for a while. Maybe I'll add split ROM support while I'm at it just for fun. There's now some safety code regarding ST loading, but it's not all there. Specifically, if a file fails to load, then you won't get any errors, the game will just not work, obviously. I now protect against loading oversized ROMs and SRAM files. The database now lists each Sufami Turbo cart only once, and the cart loading code handles matching up two ROMs from the database. It is also now possible to play ST games with invalid checksums, so eg translations/hacks of these games should now be possible, however unlikely. FF:MQ (E) is fixed now too, so we're back to FAVOR_ACCURACY in WIP builds again. A little more src/cart polishing and I'm going to start documenting all that's known about IRQs, and try and figure out how they work once and for all (hahah, yeah right -- I give it 2-3 weeks after fixing it again before more problems are found). |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Tue Nov 07, 2006 6:41 pm Post subject: | |
|
|
|
| Hmmm... There must be another game that relies on the same IRQ behavior as Robocop that can help shed light on this. Robocop was fixed in a WIP without you realizing it was even glitched, so there must be another game that prompted the initial fix. | |
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Fri Nov 10, 2006 11:44 am Post subject: | |
|
|
|
| Is the crackling sound in RPM Racing a known bug? It works fine on my real pal snes. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 10, 2006 3:39 pm Post subject: | |||
|
|
|||
No, your computer speed is a known bug. I do not interpolate samples when emulation runs too slowly, hence crackling. |
|||
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Fri Nov 10, 2006 9:20 pm Post subject: | |
|
|
|
| Gaussian interpolation? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Nov 10, 2006 10:04 pm Post subject: | |
|
|
|
| You
all should have the fpscounter on so that you can see when a game dips
you below 60. Some games use rarely used effects and it'll expose your
cpu power if you're on the fringe. You can always use frameskip on
these games, or, as byuu implies, upgrade your comp. I wonder why nintendo even allowed stuff like interlace or psuedo hi-res at all. They both seem fairly pointless. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Nov 10, 2006 10:23 pm Post subject: | |||
|
|
|||
Consider the user base. _________________ FF4 research never ends for me. |
|||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Fri Nov 10, 2006 10:49 pm Post subject: | |
|
|
|
| I get 60 fps with RPM Racing but the sound crackles. Other games work fine. Maybe its related to my onboard sound? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 10, 2006 11:14 pm Post subject: | |
|
|
|
| I wouldn't know. It doesn't happen for any of us, and none of us have your hardware. Sorry, I know of no way to simplify my sound code any more than it already is. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Nov 10, 2006 11:29 pm Post subject: | |||
|
|
|||
The (J) version smartly removed interlace and pseudo-hi-res. Try that. I have to warn you, though. It doesn't make the game any less torturous to play. |
|||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Sat Nov 11, 2006 8:40 am Post subject: | |
|
|
|
| The
J version of RPM Racing shows the same behaviour. I have used the audio
log of bsnes and have uploaded a short sample (72 kb packed). Can
anyone check this please? http://www.file-upload.net/download_11.11.06_u3s87.rar.html |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Nov 11, 2006 9:24 am Post subject: | |
|
|
|
| Happens just the same on the real system. Were you comparing different outputs? You're probably not going to be able to hear the crackling on muddy ass tv speakers. | |
Rookie
Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
| Posted: Sat Nov 11, 2006 9:38 am Post subject: | |||
|
|
|||
By the way, I have a weird problem with sound. Somtimes when I start bsnes, load rom and switch to fullscreen, sound becomes choppy. Either right after switching to fullscreen, or after several seconds. Sometimes this does not happen. Currently I set high priority to bsnes process before loading rom and switching to fullscreen and it helps. But even in this case in some rare cases sound becomes choppy after going to fullscreen. I can only guess it somehow related to sound buffering, either internal or directsound. Extending buffer size should solve this problem completely. edit: I have Athlon 64 3000+ / GeForce 6600GT PCI-E / 1GB RAM / SB Live! with kX driver / XP SP2. Emu runs at 60 FPS flawlessly all the time. |
|||
Rookie
Joined: 30 Dec 2005
Posts: 15
| Posted: Sat Nov 11, 2006 11:01 am Post subject: | |||
|
|
|||
yeah you are right, I have used my headphone on the TV and could hear the crackling. So the crackling is normal. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 13, 2006 1:47 am Post subject: | |||
|
|
|||
While it's fresh... does this have any implications for bsnes? I can't remember what you said before about SETA chips... |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 13, 2006 5:26 am Post subject: | |
|
|
|
| Not really. The code would have to be ported to pure c++, and encapsulated into a class before I could use it. Only one game even uses this chip anyway. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 13, 2006 5:56 am Post subject: | |
|
|
|
| Same
with DSP3 and 4 then... Pretty sad that we can't find anyone to do this
for you in two years. It's probably the one thing that doesn't need
your oversight, and it would be a great contribution. Too bad I can't
fucking do it |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 13, 2006 7:16 am Post subject: | |
|
|
|
| It
really isn't anyone else's responsibility to do it for me, I was very
lucky to receive the libraries from Andreas Naive for S-DD1 and DSP-1,
and the code porting help from Nach for the Cx4. But on the other hand,
since I've no interest in adding these chips myself, it probably won't
get done, or at least not until virtually nothing else is left to do. In other news, I've completely rewritten NMI and IRQ handling. It passes all of my tests, and all of the tricky games I know of. Including both R-Type III and Robocop at the same time. Funny, too. I rewrote the IRQ code in less than two hours, and with a really high fever (I'll be fine). Rather strange the way I tend to excel mentally when I have a fever. So anyway, please don't freak out and add 40 new games to the buglist for me in the morning. The code will no doubt have some issues here and there, given the complete rewrite of arguably the most important aspect of SNES emulation, but the code is so much simplier now, that I think future fixes will be a lot easier. The new code is of course not perfect yet, still need to test a lot of edge cases first. And of course, this one took another major speed hit. I'm sure you're all used to that by now, though. It's right about at the speed of v0.018 official again. To save you some time, the flickering is still there with SoM. I think it's related to DMA<>IRQ conflict timing that I recently modified. I'll look into it later. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Nov 13, 2006 7:35 am Post subject: | |
|
|
|
| Is
it not true that the simpler your C++ "reference" code is, the easier
it would be for someone to come along later and write an optimized
version of it, in either a high- or low-level language? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Veteran
Joined: 30 Jul 2004
Posts: 921
Location: Mexico
| Posted: Mon Nov 13, 2006 11:20 pm Post subject: | |||
|
|
|||
If by simpler you mean "readable", well, sort off. Extensive use of c++ features (mostly template metaprogramming) would make a nightmare to port to other languages, though. I don't know if much of these features would be of use in a hardware emulator. _________________ _-|-_ |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Mon Nov 13, 2006 11:41 pm Post subject: | |||
|
|
|||
A lot of that stuff isn't that hard to port. The hardest part to port is STL. Templates can be replaced with macros 98% of the time. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 13, 2006 11:56 pm Post subject: | |
|
|
|
| I hope that the code will be clean enough to be used as a reference for improving / writing other emulators. As far as the use of templates and c++-only features, I don't have any intentions of opening up my license to allow derivative works ("forks"), so that really isn't much of a concern anyway. I really only make light use of templates. It's mostly when you start getting down into the library code (the code below the SNES emulation core code, like the vector and string classes) that you start running into template code. Even that isn't anything too complex to port. And templates really are the smallest problem of all. As explained a few dozen times so far, the use of cooperative multithreading makes bsnes about as portable as ZSNES is now. A huge tradeoff, but accuracy came before portability in my book, when 98% of my audience was using x86/amd64 Windows/Linux anyway. Funny that I'm so stubborn about assembly code going in there, given that. So no one's noticing any new problems with the complete NMI/IRQ rewrite, then? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 14, 2006 1:16 am Post subject: | |
|
|
|
| Everything works on my watchlist except Secret of Mana. Watchlist --------- Bugs Bunny in Rabbit Rampage Energy Breaker F-1 Grand Prix Jumbo no Ozaki Hole in One Secret of Mana Sink or Swim World Class Rugby Zan III - Spirits IRQ Watchlist ------------- Battle Blaze Chou Aniki - Bakuretsu Rantou Hen Might Morphin Power Rangers - The Fighting Edition R-Type III - The Third Lightning Robocop Versus The Terminator Street Racer Wild Guns Last edited by FitzRoy on Wed Nov 15, 2006 3:00 am; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Nov 14, 2006 4:59 pm Post subject: | |
|
|
|
| Thanks
for testing. I'm honestly quite surprised at how much simpler IRQs
turned out to be. I'll try optimizing the speed a little now then,
since there are no known bugs involving IRQs at this time. Also, note to self: sync S-SMP<>S-CPU upon writes to S-SMP $00f1. Fixes Super Bomberman 4 (for the fifth time). |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Nov 14, 2006 5:10 pm Post subject: | |
|
|
|
| gonna test a few more annoying games tonigh on the latest wip just have to find something to put the latest wip on.... (still no internet at home) |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Nov 15, 2006 10:02 am Post subject: | |
|
|
|
| I
"fixed" Secret of Mana's map. HDMA bus synchronization was interfering
with DMA. So I disabled it for HDMA alone and went with the averaging
approach again until I have time to fix it (DMA still uses bus
synchronization). Since it was technically broken before, this is
"technically" more hardware accurate, but it's somewhat cheating. But
hey, since the old method was broken anyway causing missed HDMA
transfers, this is definitely an improvement. This also fixed a very
minor one frame flicker that was still occurring in Street Racer, both
games appears totally stable with mode7 rotozooming now. Now that CPU IRQ hell appears over (at least for now ...), I should be able to focus on HDMA bus sync here soon enough anyway. Also finally added that $00f1 SMP<>CPU sync to my main branch, so Super Bomberman 4 (J) is working again. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Nov 15, 2006 5:18 pm Post subject: | |
|
|
|
| Alrighty then!!! only 2 more non sPPU related bugs left. As you stated before, you cannot solve these with your current paradyme so i suggest you indeed move on to perfecting the hdma and dma could you tell us what you still need to do with the core? |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Nov 15, 2006 11:08 pm Post subject: | |||
|
|
|||
Any word or ideas on this raster UI? I'm very interested in the idea.
How about make the minimum resolution 512x448, and get that much more resolution for your UI? Hi-res games need that minimum resolution anyway, right? For people that *must* run it at less than 512x448, bsnes could accept command-line arguments or something. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Wed Nov 15, 2006 11:27 pm Post subject: | |
|
|
|
| make it a config file option to go lower in res. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|
Regular
Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
| Posted: Fri Nov 17, 2006 4:49 am Post subject: | |
|
|
|
| It's been a while since I've been around, but good job on all the improvements byuu. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 17, 2006 9:09 pm Post subject: | |
|
|
|
| Neat,
so apparently people have already successfully booted PPC Linux on the
PS3. Given bsnes gets >60fps on a 2ghz G5, a dual-core 3.2ghz should
have no problems. Just need to get libco ported, and it should be a
viable emulator. Only competition would be SNES9x, as it's the only
other emulator not dependent on Win32 and/or x86. Speed obviously no
longer matters on a console since as long as you get 60fps (and can do
fastforward), you're good. And since SNES9x' X-Windows user interface
is supposedly not very good, I see potential here to get a little more
name recognition, and perhaps attract a little help in getting more
special chips and stuff supported :) Now then, who wants to donate a PS3 so I can get started on this? :) [or more realistically, is anyone with knowledge on how to compile applications and a PS3 willing to throw a PPC Linux on it and try compiling and profiling bsnes? And most importantly, snap some screenshots?] |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Nov 17, 2006 10:23 pm Post subject: | |
|
|
|
| I
was just thinking about this same thing the other day. I've been
keeping up with the latest PS3 announcements and was surprised to see
how easy it was to disassemble the PS3 compared to the 360. Even the HD
can be replaced with a custom one, and combined with the ability to run
linux, I have no doubt that we're going to see a lot of emulator ports
for this puppy in the years to come. There's a lot of buzz around the
PS3, and it's a big opportunity for bsnes if it can be the first SNES
emu ported. My first curiosity, though, is if one core on the cell is enough to run at 60fps. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Nov 17, 2006 10:46 pm Post subject: | |
|
|
|
| It
should be, yes. It's an IBM PPC, and the 2ghz G5 was enough to get
60-80fps on Mac OS X. Now, of course, ghz don't mean everything, it's
possible that the 3.2ghz Cell is slower than the 2ghz G5 ... but at the
very least, the Cell is a dual core processor so bsnes will have an
entire core to itself. I would be willing to increase the flexibility
of the FAVOR_SPEED build to guarantee >60fps on a PS3 if people
would be willing to use it there. The recognition would go a long way to garnering programming help from other people, but if SNES9x gets ported quickly (and it probably already has been), I doubt anyone would bother. I'm going to have to focus on a really spiffy and complete GUI interface for my Linux port, and quickly. The good news is, as a console, it doesn't matter how much CPU usage an emulator takes. It's a console. You're running a game on it, and you have two cores anyway. Anyone with a PS3 will get the same framerate, so the speed is no longer an issue, so long as you get full speed. I could even release binary packages that are profile optimized like the Windows releases. It's also possible to run ZSNES and co on the PPC anyway, by use of an emulator, but even ZSNES will likely have problems keeping a steady 60fps inside an x86 emulator on the PS3. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Nov 19, 2006 3:57 am Post subject: | |
|
|
|
| Too
bad I'm not getting one for like a year, or I'd test stuff out for you.
Also, too many old games sitting on my shelf that I haven't played...
shadow of the colossus, eternal darkness... and this new dat site that
I've yet to launch is sucking up all of my time now that I'm done with
initial testing. Make no mistake, though, I'm still a whore for accuracy. After hdma bus sync, I'd like to see you take a shot at those last two fixable bugs since getting new info on them. Because if those get wiped, it would mean something fairly remarkable. And I wouldn't be shy to say it in your next release notes that get posted on news sites. Something along the lines of "All 3000 non-special chip games have been tested and only 3 known bugs remain, all of which are dependent on a dot-based renderer." |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Nov 20, 2006 2:14 pm Post subject: | |
|
|
|
| Although
it could be my mind playing tricks on me, i have the feeling that the
audio sounds different in the latest wip, also Toy story seems to be
less buggy, but still has problems, it just seems to recover quicker
now... Did you change anything to the sound? or is this being caused by the new IRQ behaviour. The new sound sounds a lot better! The game i noticed it the most on is may all time favorite "zombies ate my neighbours" i know every song and sound effect by heart, en they sound very different between the last wip i tried, 12 i think and the new wip 18 |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Nov 20, 2006 8:49 pm Post subject: | |
|
|
|
| I don't notice a difference in any of the games you mentioned. In fact, I don't think anything has changed with regards to sound quality since .016... unless you count EWJ2, which was from the pal clock being too slow. | |
Rookie
Joined: 25 Aug 2004
Posts: 24
Location: spb, ru
| Posted: Mon Nov 20, 2006 9:10 pm Post subject: | |||
|
|
|||
I'm sorry, do I have a chance to get these wip builds? |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 21, 2006 1:34 am Post subject: | |
|
|
|
| The bsnes WIP builds are not public like zsnes. I think byuu has indicated that .019 will be released sometime around January if things go well. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Nov 21, 2006 9:48 am Post subject: | |
|
|
|
| okay
i recorded the audio for 0.17 and 0.18wip18 and then compared them with
the EAC compare tool, and it flagged all the sections i thought sounded
different as different! I also tested 0.18 and it was 99% the same as 0.18wip18 the change in audio code must have happened somewhere between 0.17 and 0.18 I didnt notice it before because i had a crappy soundcard , got an X-Fi now... |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 21, 2006 10:13 am Post subject: | |
|
|
|
| Hmm... could have something to do with the change from 32000hz to 32040hz. I couldn't perceive any difference. Maybe I just don't know what to look for. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Nov 21, 2006 10:30 am Post subject: | |
|
|
|
| that has to be it! That would greatly alter the wav output the new frequency does make a huge difference with a very good soundcard and speakers, but is hardly noticeable on my onboard sound. When testing a month ago i mentioned some sound differences in some games i tested, they now sound on my pc like they do on the tv! But that still doesnt explain why toy story is less bugy.. that must come from the irq changes |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Nov 22, 2006 12:55 am Post subject: | |
|
|
|
| Glad
to see the change to 32040hz helped. It's only the internal
CPU<>SMP timing that was affected by the change, the actual
output is still forced to 32000hz (basically, emulation runs ~1/8th of
1% too slow), as the resampling penalties would be very rough with
maximum frequencies on sound cards being typically 48khz to 96khz. Some people disagree with me in changing the S-SMP clock rate to match observed rates of real hardware (in fact I was rather adamant against it for a long time myself), but it is known that the stock speeds break real games released for the system (eg EWJ2 (E)). At this point in time, I think I'd rather try and emulate the actual SNES box myself, than to emulate the specification sheets that don't reflect reality. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Nov 22, 2006 6:53 am Post subject: | |||
|
|
|||
|
Might have a bug to report, but I'm not sure... It has to do with one of the Test Cartridge roms. It's known as "SNES Aging Test Program" in NSRT. Runs okay in zsnes, but won't run in any bsnes version. The other two dumped test carts run okay, and supposedly this rom is a verified dump. EDIT: Okay, something that might be useful: the rom runs at 60fps in zsnes and works on my ntsc snes, but Overload insists that it is a PAL cart despite being (J) internally.
Lastly, the "SNSP" on the title screen seems to confirm this because SNSP-001A is the UK SNES model number. Weird. Anyway, going on vacation now. Happy Thanksgivings. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 27, 2006 5:55 pm Post subject: | |
|
|
|
| Hmm,
still working on the GUI wrapper for Win32<>GTK+. I doubt anyone
will add any other toolkits in the future, but this at least makes it a
possibility. One thing I'm doing is specifically designing the new UI wrapper to be as minimalist as possible. That means giving up a lot of tricks that I know are possible in most GUI toolkits such as windows inside of windows (see the current bsnes configuration screen for an example). Something that most definitely will not be possible is the highly customized debugger memory editor in current bsnes Windows builds, however a less intuitive and speedy interface can be designed that works on Linux as well. So then, should I just keep the current Windows port and all of its platform-specific code, or should I redesign the GUI to be more generic to support both Windows and Linux? This would entail having separate windows for all of the various configuration panels, for one. Not necessarily a big deal, I think. It'd save time and allow the Windows and Linux ports to remain mostly synchronous, but obviously won't look as good as custom tailored solutions on each individual platform. The biggest problem I foresee is that I have no idea how to switch to fullscreen mode with GTK+ (I doubt it's even possible), so I've no idea how that's going to work if I decide to use this new library for the main Windows port as well. So far, I just have the window creation working on Windows, and window creation + menus on the Linux port. The code is easy, but highly monotonous to write, hence why it's taking so long. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Mon Nov 27, 2006 6:25 pm Post subject: | |||
|
|
|||
Any chances that you might implement a way to start emulation fullscreen? |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Nov 27, 2006 6:45 pm Post subject: | |||
|
|
|||
So did you scrap the idea of a raster-based GUI? Or is this in addition to that?
I personally hate using GTK applications on Windows. However, I hate them less if the GTK libraries are statically linked to the program, instead of "shared" or whatever (I hope what I've said makes sense; my knowledge of this stuff comes from using various X-Chat builds, Gaim, and GIMP on Windows). So, ideally, I'd prefer to use a native Win32 interface, or a raster-based GUI. But if you go with more generic GUI code, and use GTK on Windows, please statically link the GTK libraries. Altogether, though, I'm for anything that makes the code simpler / more portable / easier for you. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Nov 27, 2006 7:56 pm Post subject: | |||||
|
|
|||||
How does that affect the program? _________________ savestate editor: vSNES latest public version
|
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Nov 27, 2006 8:46 pm Post subject: | |||
|
|
|||
From what I know of GTK programs and using them on Windows, this is how it works: You can install "system-wide" GTK libraries. Any program that has shared or dynamically linked GTK libraries will use the system-wide libraries. Any program that uses statically linked libraries has the libraries compiled right into the program, or something. The difference being that any change to the system-wide GTK libraries affect all programs using them. With statically linked GTK, the program only uses the libraries that are built into the program. So changes to the shared libraries don't affect it. The problem with shared libraries is evident when using Gaim. Before the release of Gaim 2.0.0beta4, it required an old version of GTK, v2.6. Some info here. This old version could sometimes affect newer versions of GIMP. Also, I've sometimes installed a new version of X-Chat or GAIM, and the new GTK libraries sometimes affect the other program. The point is that some programs might expect a certain version of GTK, while others expect a different version. It just seems that sharing GTK libraries among different programs on Windows is a bad idea. There's just too many compatibility problems, etc. This is just all from my experiences. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 27, 2006 9:50 pm Post subject: | |||||
|
|
|||||
Probably not. Without a menu, it would only annoy most people unaware of how to switch to windowed mode. The really ignorant would possibly not be able to exit fullscreen mode, despite there being at least six key combinations to get you out of fullscreen mode (esc, f11, windows key, alt+tab, ctrl+alt+delete, ctrl+lshift+esc, etc).
As do I, which is why I'm writing a cross-platform user interface library, rather than simply using GTK+ because it's portable. GTK+ looks great on Linux. It's fast, has a nice selection of themes that are easy to select from the OS control panel (in my case, XFCE theme applet), and works good. It also looks like all of my other apps. On Windows, it's clear the port was half assed. GTK+ apps stick out like a sore thumb as most apps use the Win32 API and are consistent whereas GTK+ look and sometimes act completely different, they have redraw issues, flicker issues, etc etc. Hence, on Windows bsnes will use the Win32 API. On Linux, it will use GTK+. On Mac, you can use Richard Bannister's port which I assume uses Aqua. The only thing is, in order to support multiple APIs, I'm forced to implement the library to use only the lowest common denominator of functionality (basically, I can only do things that can be done on all of the platforms, so I can't tweak each platform to look just perfect anymore, and I'll lose a little of the refinement features in the GUI such as the memory editor keyboard hook). Note: you can technically build the Windows port to use GTK+ with the library, but ... why? The raster GUI? Eh, I'd like to work on it, but it's a huge undertaking to make it anywhere near half decent. This seems like it'd be a lot faster, and it'd be a lot smoother for most. As a plus, it should give a nice GUI for PS3 bsnes using GTK+. |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Nov 27, 2006 10:31 pm Post subject: | |||
|
|
|||
Fair enough. I'm more than happy to use a standard Win32 GUI. Just out of curiosity, what's your "plan" for version 1.0 of bsnes? It seems that you are versioning your emulator with sub-1.0 numbers because you consider it a beta of some sort, or not ready for general use. Perhaps you're planning 100% base SNES accuracy for 1.0? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Nov 27, 2006 10:38 pm Post subject: | |
|
|
|
| v1.0
would assume total completion and perfection of the emulator. Since
that will never happen, I'm not ever planning a v1.0. I might make the
final version 1.0 just for the hell of it, but most likely not. The version numbers are just exact numbers of official full releases. Only the first two versions were a little sketchy since I was releasing most of the WIPs publically back then. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Nov 28, 2006 1:27 am Post subject: | |
|
|
|
| Raster GUIs have maintenance and space issues galore. I think gtk for linux is fine. Hopefully, the Windows config scheme doesn't suffer too much from linux support. It's awfully nice at the moment. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Nov 28, 2006 12:35 pm Post subject: | |||||
|
|
|||||
Mmh. They should've secured all shared files (& other resources) with version numbers... ...but whatever. /offtopic _________________ savestate editor: vSNES latest public version
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Dec 01, 2006 1:27 am Post subject: | |
|
|
|
| Tetsuo, can you do me a favor and test George Foreman's KO Boxing (E) on your PAL unit? I want to know if the sound stutters like that for real. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Dec 01, 2006 8:39 am Post subject: | |
|
|
|
| Will do! | |
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Dec 05, 2006 5:30 am Post subject: | |||||
|
|
|||||
|
OT: Haze on the recent CPS2 CHD 4GB each (for now that is) http://shortlink.co.uk/h7s (mameworld board)
We're fortunate to have bsnes and two other accurate Snes emus (and maybe in the future Zsnes will figure in that list) |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Dec 05, 2006 8:10 am Post subject: | |
|
|
|
| actually,
unless someone starts dumping the rom chips with an ic reader and maps
the pcd layaout of each game cart there is a similar loss of data. snes games are basically the same as the cps2 board but without the protection that needs a 4 gig CHD a lot of the memory mappers used in snes emus are a pretty accurate guesses |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Dec 05, 2006 8:22 am Post subject: | |||
|
|
|||
ah, I admit I wasn't aware of this. I was mentionning this more in reference to documenting the Snes hardware, before there's no more functionning Snes units. Didn't know it also extended to the game dumps themselves (which make better sense for the analogy actually) |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Dec 05, 2006 10:31 am Post subject: | |||
|
|
|||
There is almost no difference in sound it doesnt stutter for me on my system nor in bsnes wip18 |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Dec 05, 2006 9:17 pm Post subject: | |
|
|
|
| Thank you, but it does stutter in bsnes. I'm referring to the "Forema- Foreman for Real." and other sound effects that do it which sounds really wrong. And it doesn't do it in the (U) version. Could be that the developers thought it made a neat "echo" effect, but I thought it might be a bug instead. The ref's voice gets completely jacked by it. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Dec 07, 2006 7:54 am Post subject: | |
|
|
|
| this game doesnt stutter on bsnes nor my real snes. maybe your using a different version? or i tested the wrong game NSRT v3.3 - Nach's SNES ROM Tools ---------------------Internal ROM Info---------------------- File: 1.SMC Name: FOREMAN'S KO BOXING Company: Acclaim Header: Exists (type?) Bank: LoROM Interleaved: No SRAM: 0 Kb Type: Normal ROM: 8 Mb Country: Euro/Asia/Oceania Video: PAL ROM Speed: 200ns (SlowROM) Revision: 1.0 Checksum: Good 0xF3E9 CRC32: 09FE6EC1 MD5: B3DF09E19706763E5EAD764D384C891F --------------------------Database-------------------------- Name: George Foreman's KO Boxing Country: Europe Revision: 1.0 Port 1: Gamepad Port 2: Gamepad Genre 1: Sports Genre 2: Boxing |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Dec 07, 2006 8:01 am Post subject: | |
|
|
|
| Gah,
my fault. I told you to check "George Foreman's KO Boxing (E)" but the
game in question is actually "Foreman for Real (E)". No wonder we're
confused. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Dec 07, 2006 9:44 am Post subject: | |
|
|
|
| lol okay ill test the other game Edit: I got some interesting results here, all version of the game have the "echo" on pal hardware U/E/J, but the ntsc version hang on a "this pack si not for pal " screen. So it looks like Bsnes is emulating corretly. Byuu, i assume Bsnes automatically choses either pal or ntsc mode when loading a cartidge, is it possible to force Bsnes to work as either pal or ntsc, this way we sould get to see the "not ment for your region screen" |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Dec 07, 2006 2:47 pm Post subject: | |
|
|
|
| It's
not possible at present. I didn't see a need to add support for that,
as we've now officially tested every last commercial SNES game we have
dumped and the header+region detection is 100% accurate. I guess I could add an option to choose the region, but it seems more like feature bloat. You could change the region in the ROM header file and achieve the same result, btw. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Dec 08, 2006 6:52 am Post subject: | |
|
|
|
| okay sounds fair enough changing a pal game to ntsc or vice versa, can i use the fix for pal/ntsc option in snestool 1.2 for that or do i need to change it in a different way? |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Dec 16, 2006 1:15 pm Post subject: | |
|
|
|
| Does Bsnes support multiple roms in 1 zip? like the pal, us and jap version of a game in 1 zip |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Dec 16, 2006 6:55 pm Post subject: | |
|
|
|
| There's one byte in the ROM header to set NTSC/PAL. 0x00, 0x01 and I think 0x13 (whatever Korea is) are NTSC. The rest are PAL. I don't support multiple ROMs in one ZIP yet. I might add that functionality when I design my own little mini container for multiple files, but I don't know how zlib or libjma work, so I won't be able to add the support there anyway. There's no advantage of this with any of the containers supported in bsnes, as none offer solid state archiving anyway (I believe JMA does, but I don't believe the version of the library I am using does. And even if mine does, it can't be used now anyway since I don't support multiple ROMs in one archive). A small update, libui is ~90% complete for GTK+, and ~60% complete for Win32. Windows users really aren't going to like the less stellar UI, but Linux users should be very happy with it. By the way, I'm looking for a way to display UTF-8 text inside Win32 native and common controls, is that possible? GTK+ supports it out of the box, and I want to use that for internationalization. |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Sun Dec 17, 2006 1:14 am Post subject: | |||
|
|
|||
Sorry, you'll have to translate to UTF-16 for Windows. Your options include:
Then, on Windows 9x, you still need to translate back to ANSI, so that's a trip back through WideCharToMultiByte with CP_ACP. Things also get a bit complicated if you want to support both NT and 9x, since a few of the Common Controls have separate window messages for ANSI and Unicode. Microsoft has released a library to simplify Unicode support under legacy systems, but it pretty much wraps everything, so it's kind of big. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 17, 2006 2:03 am Post subject: | |||
|
|
|||
Easy enough, I can make that transparent. I'm willing to drop support for Win9x if it means being able to display apps in any language, regardless of locale setting. Not sure how I want to do the language stuff just yet. Probably just a UTF-8 text document with a list of "File"="Fairu", etc lines. |
|||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Sun Dec 17, 2006 4:22 am Post subject: | |||||
|
|
|||||
you'd need flow control for dialogs too. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|||||
Trooper
Joined: 05 May 2006
Posts: 367
| Posted: Sun Dec 17, 2006 7:33 am Post subject: | |
|
|
|
| 9x needs to die already, along with support for it. | |
saskatchewanite
Joined: 26 Apr 2006
Posts: 317
| Posted: Sun Dec 17, 2006 8:11 am Post subject: | |||
|
|
|||
_________________ everything i say is a lie the above line is true |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Dec 17, 2006 8:17 am Post subject: | |||||
|
|
|||||
Yes. Though, but killing DOS will make me cry... or not. If you can't help it, go kill the support. It is still a viable platform for some. (I still should get around to testing BSNES under 98SE.) _________________ FF4 research never ends for me. |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Dec 19, 2006 4:47 pm Post subject: | |
|
|
|
| FitzRoy could you test "Star Ocean (J) [T+Eng1.0_DeJap].smc" on your NTSC hardware The problem we are looking for is corruption on the title screen and slow displaying of items from itemboxes. I can confirm that the unpatched version runs fine in bsnes, no slowdowns or corruptions |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Dec 19, 2006 6:28 pm Post subject: | |||||
|
|
|||||
2-12 are PAL, the rest are NTSC.
You believe wrong. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Dec 19, 2006 10:18 pm Post subject: | |||
|
|
|||
I'll try but I don't think it's going to work since Star Ocean uses a special chip (SDD-1). Could be that zsnes is allowing the patchers to do something that they weren't supposed to be doing. Someone who knows what they're talking about is going to have to look into it. |
|||
Hazed
Joined: 29 Jul 2004
Posts: 86
Location: USA
| Posted: Tue Dec 19, 2006 11:32 pm Post subject: | |||
|
|
|||
NTSC Hardware? As in on a copier? I do know that if you have a GDSF7 with 96Mb+ of RAM, you can run the translated ROM on it (I've tried), but you have to use a special hack made by Neviksti. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Dec 20, 2006 5:06 am Post subject: | |
|
|
|
| As expected, it didn't work on my flash cart because the game requires a special chip. And the Neviksti version won't work on what I have because 96M is too big for my 64M flash cart. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Dec 20, 2006 5:44 am Post subject: | |||
|
|
|||
|
I replied to the DeJap Star Ocean issue on the pSX emulator forum page, where said discussion started. I suppose I might as well start documenting "flaws" like this and Gideon Zhi's older Y's 4 translation patch. This isn't the first board where I've seen people suggesting this was a problem with bsnes.
Hence why I said believe, because I knew no matter how I answered, you'd post that I was incorrect. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Dec 20, 2006 8:18 am Post subject: | |
|
|
|
| Yeah i should dig up the bugs that arnt emu bugs that i listed when testing the games, FitzRoy did you make such a list? Too bad the rom is so big, as some special chip/hardware games do work partially on bsnes eventhough the chip is not emulated byuu im sorry the wip got posted there, i was asleep when that happend or i would have removed the link instantly, |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Dec 20, 2006 8:46 am Post subject: | |
|
|
|
| Bugs That are NOT emulation Bugs Special Chip/Hardware Games BS Test Results BS Nichibutsu 4 Player Mahjong 1 (J).smc > seems to work fine, but there is no audio. BS Nichibutsu 4 Player Mahjong 2 (J).smc > seems to work fine, but there is no audio. BS Nichibutsu Mahjong (J).smc > seems to work fine, but one of the titlescreens fonts is messed up. BS Same Game Koma Data (J).smc > black screen BS Satella Walker 2 - Sate Bou wo Sukuidasu! (J).smc > black screen BS Sousa Sentai Wappers 1 (J).smc > fonts messed up BS Sousa Sentai Wappers 2 (J).smc > fonts messed up BS Sousa Sentai Wappers Soushuu Hen (J).smc > fonts messed up BS Special Tee Shot (J).smc > 2 words overlap in the level select screen, apart from that the game works fine and is a lot of fun too! (midget golf with a blob) BS Spriggan Powered (J).smc > game seems to be working perfectly, but i cannot get passed the japanese dialogue. BS St.Giga 10 Gatsu Gou (J).smc > fonts messed up BS Super Mahjong Taikai (J).smc > koei logo and game logo messed up, i cannot get passed the japanese name/password part so i didnt see ingame BS Super Mario Collection 3 (J).smc > i can only change the button layout, but i cannot get ingame. BS Super Mario USA 1 (J).smc > Game works perfectly but there is no music, and it seems like mario characters are talking to you in japanese, but their voice is not heard. BS Super Mario USA 2 (J).smc > Game works perfectly but there is no music, and it seems like mario characters are talking to you in japanese, but their voice is not heard. BS Super Mario USA 3 (J).smc > Game works perfectly but there is no music, and it seems like mario characters are talking to you in japanese, but their voice is not heard. BS Super Ninja-kun (J).smc > might be missing some soundFX, but seems 100% working BS Super Tsume Shougi 1000 (J).smc > game works, but audio might not be 100% BS Sutte Hakkun 2 6-3 (J) [!].smc > looks good, but i cannot get passed the japanese menu to get ingame. BS Sutte Hakkun 2 10-8 (J).smc > looks good, but i cannot get passed the japanese menu to get ingame. BS Sutte Hakkun 98 Winter Event Version (J).smc > looks good, but i cannot get passed the japanese menu to get ingame. BS Sutte Hakkun (J).smc > looks good, but i cannot get passed the japanese menu to get ingame. SuperFX Vortex (E/J/U) [!].smc > black screen DSP 4 Planet's Champ TG3000, The (J).smc > Black Screen To p Gear 3000 (E) [!].smc > black screen To p Gear 3000 (U) [!].smc > black screen SA-1 Taikyoku Igo - Idaten (J).smc > black screen Takemiya Masaki Kudan no Igo Taishou (J).smc > black screen SPC7110 Tengai Makyou Zero - Shounen Jump no Shou (J) [!].smc > black screeb Tengai Makyou Zero (J) [!].smc > black screen Bugs in games and not in emulation Yuujin - Janjuu Gakuen 2 (J).smc > Sometimes the Characters will disappear or flash heavily, happens on hardware in the same places. Thunderbirds - Kokusai Kyuujotai Juudou Seyo! (J).smc > smoke effect as 1 launches looks wrong, looks the same on hardware. Tiny Toon Adventures - Wild & Wacky Sports (E) (V1.1) [!].smc +U/J > feet missing 1 pixel line on character select screen, looks the same on hardware. Top Gear 2 U/E/J > A black line appears in the bridge on level 1, happens on hardware too, but in a different part of the bridge and for a shorter time.(needs sPPU) Toy Story (U) [!].smc +U/E > Sometimes a buzzing is heard on loading screens, unable to test in hardware as none of the releases will run on my copier. Aqutallion (J).smc > no visable battle damage, same on hardware. Sim City > Scrolling causes a 1 tile wrap around to happen on the direction your scrolling in., not visable on TV's only on plasma/lcd. this is the list so far, i seem to have forgotten to test about 10 games on hardware. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Dec 20, 2006 9:33 am Post subject: | |||||||
|
|
|||||||
If you would've posted correctly, I would not have told you that you were incorrect. I don't know why you think I crippled the JMA decompression lib I've been passing out every where. Especially a quick glance in jma.h and you notice:
_________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Dec 20, 2006 9:55 am Post subject: | |
|
|
|
| I
didn't bother keeping documentation on real glitches because I know the
list would just be too damn long. After seeing what was real and what
was truly a bug, I can safely say that a. no graphical anomaly occuring only in the "overscan area" is a real bug. b. no flickering sprite with line caching disabled is a real bug This accounts for just about every "common" game glitch I've seen. Real bugs will usually consist of something distractingly noticeable within the first five minutes of gameplay: corrupt gfx, wrong colors, missing effects, scrambled bg layers, unresponsive controls, and freezing. There are very likely other games affected by the random Koushien hang, which is why it's somewhat important that it gets fixed eventually for reasons other than obsessive accuracy. We're lucky to have found one example because it's apparently a fairly obscure bug. But one known game is all you need for collateral damage (and who knows, maybe Toy Story and Koushien are related). Also, unsupported hardware is already documented, just not on a game-by-game basis. I think that byuu's readme is sufficiently inclusive for users, although I would be interested in having a text file with a complete list of unsupported games followed by their hardware (in alphabetical order and this format). Star Fox (U) *SFX Super Mario World 2 - Yoshi's Island (E) *SA1 Super Mario World 2 - Yoshi's Island (U) *SA1 etc... Oh, and pSX emulator forum drama?
Summary for the lazy: KingHanco posts WIP link, young spriggans bash
bsnes for its speed, byuu comes in and chastises KingHanco, then
tommy-guns everyone (not really). |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Dec 20, 2006 6:56 pm Post subject: | |
|
|
|
| I guess I can change my unsupported games list to be completely alphabetical, then. No real drama at pSX forums. I'll just change where I stick WIP builds in the future. I intentionally left the link as something fairly easy to guess before. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Dec 20, 2006 7:50 pm Post subject: | |
|
|
|
| byuu isnt the latest link password protected??? | |
Trooper
Joined: 05 May 2006
Posts: 367
| Posted: Wed Dec 20, 2006 9:20 pm Post subject: | |||
|
|
|||
That's a SuperFX2 game. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Dec 20, 2006 10:21 pm Post subject: | |
|
|
|
| Yep. Tried to remember for the example and failed. All the more reason for a list! | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Dec 21, 2006 12:35 pm Post subject: | |||||
|
|
|||||
|
I made a list with all the info i could find on games with special chips inside them, im currently building the add-on list. (EDIT: Super Scope info added) I could not find all the games as roms, i believe some might be misnamed. Games that i could not find where marked as (!NOT FOUND!) Games that where never released are marked as (Unreleased BETA) The rest is standard naming fair, all names are from the latest Goodsnes. You can copy and paste the following lists in Excel, and then edit them and them resort them, you can even add everything to 1 list and sort it alphabetically, i decided to simply list everything so everyone can use it in whatever way they like it. For Bsnes documentation its probably best to combine all the lists remove the fully working games from it, then resort alphabetically. ,
All Super Scope games show the menu, but a lot of them cannot go ingame.
|
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Dec 22, 2006 1:05 am Post subject: | |||
|
|
|||
I
made a complete NSRT scan and searched for each chip to make this list.
Should be accurate, but no unreleased games are included. Watch out for
the board filter on Top Gear you know what, though (never mind, someone
fixed it).
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Dec 22, 2006 3:20 pm Post subject: | |
|
|
|
| For
my custom ROM loader that will scan the directories and give you a list
of available games ... I was thinking there were two ways to identify
available games: 1) By CRC32 This means that I have to actually read in the entire file, and process the CRC32 of the file to match it to the database. This will also require decompression of ZIPs. Scanning will be slow (possibly several minutes for a complete set), even on the fastest of machines. 2) By filename Each file would have a special abbreviation, hopefully no more than eight letters long. The emulator could then just scan the directory and match via filename. Intentionally lying about the filename would yield a false positive for a game being present, but I could always verify upon actually trying to play the game and report a message about the ROM being invalid. However, scanning a directory should only take a second or two, even on slow machines. Would be difficult as you'd probably need a ROM renamer in the first place that would have to scan by CRC32 anyway. Which one should I go with? |
|
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Fri Dec 22, 2006 4:44 pm Post subject: | |
|
|
|
| MD5 hash _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Fri Dec 22, 2006 4:47 pm Post subject: | |
|
|
|
| Always scanning everything might be overdoing it a bit; you could let the user create a database of roms on his PC which you'd store in the same folder as Bsnes; ask for it on the first run, let the user choose to refresh it at will. By filename seems somewhat restrictive to me, and would probably lead to a lot of whining from people who don't read the instructions. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Dec 22, 2006 6:05 pm Post subject: | |
|
|
|
| Yeah take the best scanning method, crc32 or md5 and store in a updateable database | |
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Fri Dec 22, 2006 6:12 pm Post subject: | |
|
|
|
| Here's a question: do you need to scan the entire ROM to uniquely identify it? _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Dec 22, 2006 7:45 pm Post subject: | |
|
|
|
| yeah because the built in crc check roms have only scans the first XX bytes | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Dec 22, 2006 7:57 pm Post subject: | |
|
|
|
| I
could store a database that only matches a small portion of the ROM,
but the bottleneck isn't really scanning the file once it's open. It's
decompressing the file from GZ/ZIP/JMA archives to memory so that I can
then calculate the CRC32. Plus, it's technically much easier to get false positives this way. Though of course, CRC32s can easily be faked to begin with if someone really wanted, but at least it's a 4,000,000,000 to 1 chance of a false positive without deliberately forging the sum. I've never seen an MD5sum algorithm that was short and concise enough for me to use. If I can get a c/c++ MD5sum routine that is less than 100-200 lines of code, and well written so that I can derive my own from the code (to avoid any licensing issues), I'd love to use MD5 instead. |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Fri Dec 22, 2006 9:20 pm Post subject: | |
|
|
|
| Yeah, I think the mame or Project64 method would be best. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Dec 22, 2006 10:38 pm Post subject: | |
|
|
|
| /me chants: maem mame mame |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sat Dec 23, 2006 12:12 am Post subject: | |
|
|
|
| This
rom loader thing is an option, right? I want to just do database checks
on a per-load basis and use my own file preferences. Meh, I suppose I would like it. It would make it easier for newbs, and I'm guessing it would still allow you to run roms that weren't in the database, like betas and so forth. Plus, I'm guessing it would instantly recognize BIOS files so people wouldn't have to move them around and rename them like in zsnes. Last edited by FitzRoy on Sat Dec 23, 2006 1:11 am; edited 2 times in total |
|
Hazed
Joined: 07 Feb 2006
Posts: 79
| Posted: Sat Dec 23, 2006 12:29 am Post subject: | |||
|
|
|||
The psuedocode on the Wikipedia page for MD5 is pretty well written, and only 62 lines. Even if it does wind up being a bit long and messy in C, that's excusable because it's implementing a messy concept. |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Sat Dec 23, 2006 4:44 pm Post subject: | |||
|
|
|||
I do not agree with databases with emulators, however if you're looking for a hash of the files, or a hash of the ROM and you know it's not headered, not interleaved, don't care about corrupt archives, you could just read the CRC32 right out of the archive header and not even bother calculating it. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Dec 25, 2006 9:06 pm Post subject: | |
|
|
|
| Hmm,
so I've brought this up for discussion at least ten times already, but
it's a very serious point. So I'll bring it up again for more input. As everyone who follows this thread knows, there are three serious bugs in bsnes, and two line flickering bugs. Three require a cycle-based PPU renderer, two require S-DSP knowledge and testing equipment that I lack. Now, I could also work on things that quite literally no game relies on, like half-calculated math results and such ... and indeed I intend to eventually, but it won't make any difference in any games, so releasing new versions with these fixes would have no merit outside of the five people writing new SNES code nowadays. These issues require months of time to throw at them, and for zero gain. It would be better to focus on the visible bugs first, especially considering I cannot go on forever working on this project. So then, that only leaves me with rewriting the S-PPU. I've analyzed my code again, and I can think of no way to allow both the scanline and cycle based renderers to coexist as selectable options. The way the cycle based renderer would have to work would make the scanline one inoperable, and vice versa. And the bigger problem being, a cycle-based PPU renderer would be too slow. If my recent modifications to S-CPU IRQs is any indication, I'm expecting a loss of 200-500% speed. If we were lucky, only a high-end Core 2 Duo would be fast enough to run bsnes at fullspeed. Probably not even then. We would be increasing the workload of what is already the most CPU intensive part of the emulator from ~225 complex operations a frame to ~76,500 less complex operations per frame. Multithreading (to take advantage of multiple cores) won't work at all, nor will super optimizations over time, and I think we can expect even less emphasis on raw processing speed as Intel and AMD both move toward "multiple cores, minimum power consumption" models. A cycle-based renderer will also completely destroy all benefits of frameskipping. So my basic problem is: either I settle for a scanline renderer as a necessary evil, let my work stagnate, and eventually forget all that I currently know regarding SNES internals long before PCs are fast enough; or I completely destroy everyone's ability to ever enjoy any future releases of bsnes because they will, quite simply, be far too slow to be usable. The idea behind perfect accuracy at any cost is nice, but I never expected bsnes to take as much CPU power as it already does. I still like the ideal behind all the accuracy, but I wanted something usable, too. Asking an end user to at least own a modern low-end $50 processor wasn't much. Asking them to own a $1,000 C2D Extreme, is. With only one actual game benefitting to a degree anyone will ever notice, and my ever-fleeting time, I can't see a strong reason to try and write a cycle-based renderer. And yet, if I don't, then bsnes really won't get much better in regards to core accuracy. I can only add frivilous shit like special chips and add-on peripherals. I've also been considering stripping away some features from bsnes that take away from its current accuracy. For example, I'd like to completely remove frameskipping so I can calculate RTO flags every frame. Frameskipping would just be stupid if it only offered a ~3% speedup at a frameskip of 9. Special features are nice, but they only serve to complicate my code and make it less maintainable. I'm at a point that I don't expect the underlying architecture to change much, so I want to start simplifying and streamlining it all to something I can reasonably call "finished" one day. So once again, I'd like some opinions. This time, before just saying "yeah, go with accuracy!", realize what you're saying. It will very well mean bsnes becoming completely irrelevent as an alternative to ZSNES and SNES9x for at least the next several years. It could also potentially mean that bsnes can become near-immortal in the sense that no future emulator could really do any better, even when the hardware to run it is finally available and mainstream. It's also very likely that we'll never convince end users of the advantages of accuracy, and they'll stick with ZSNES9x forever anyway. Even if their computers can run bsnes without breaking a sweat, if ZSNES is quite literally 100x faster, it could be enough for people to avoid using bsnes anyway (there's also power consumption / battery life, game consoles, handhelds and cell phones to worry about in the future). I would essentially be turning bsnes into a reference emulator that serves only to document hardware, rather than something people can use and enjoy, and I would for all intents and purposes, be doing it to fix only one game that's arguably already broken to begin with. |
|
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Mon Dec 25, 2006 9:35 pm Post subject: | |
|
|
|
| Is
there a way to find a happy ground where you still draw per scanline,
but somehow trap an event that would require a cycle based render for
that line? I guess the difference is detecting a write to some area at such a time, and then using some sort of mathematical method to go back and change how that line looked. What I'm trying to say is, don't perform the intense calculation unless it needs to happen, because just think of how rare that event is for all the games. What I'm saying may help a little with this analogy: Highschool physics and the toss a ball up in the air problem, and find out what time it was at such a height or whatever: They typically give the students the quadratic function right away describing the path of the ball (plugging in some starting conditions), without them understanding why. There is the other way using discrete time slice math, which is very simple summation but you have to start at time offset 0 and keep looping until you get there. What you keep doing is shrinking your time slices, making stuff take drastically longer time. What I'm getting at, and I haven't studied your code, is that if the event that requires a dot based renderer happens somewhere within a critical time period, maybe there is a way to figure out what really happened previously just by knowing the specific tick at which it happened, what the data was, and an algorithm that describes it, to be able to redraw that line differently. Does this help any? |
|
Zealot
Joined: 29 Jul 2004
Posts: 1218
| Posted: Mon Dec 25, 2006 9:38 pm Post subject: | |
|
|
|
| I'm
trying to be open-minded about both sides of the issue, and I still
think going for accuracy would be the best choice in the long run. I
think in the future it would be regretted if you did otherwise. Plus, I
thought that accuracy and SNES documentation was the original goal of
this project anyway. We still have the old versions, and the source code. Those can be used if needed. |
|
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Mon Dec 25, 2006 10:00 pm Post subject: | |
|
|
|
| So I take it a cycle based renderer could not be optimized for minimal to zero interaction during scanline rendering? I'm guessing optimization for rendering whole scanlines, or partial scanlines when interaction would affect rendering, but since you mentioned that switching scanline or cycle based renderer would not be possible at runtime, I guess the two can't be mixed easily. Plus I guess that scenario could even result in worse slowdown in an extreme scenario where some cycle timed code is messing with the PPU constantly, and while I don't expect that to be too common, I suppose a reference implementation should handle everything consistently rather than optimizing for "common" cases. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Dec 25, 2006 10:01 pm Post subject: | |||||||
|
|
|||||||
I'm sure there is. The more speed I squeeze out, the messier the code gets. And I could very easily design around expecting something to not be possible, and have it turn out that it is very much possible. Quick example: I write code that detects something that would change a scanline halfway through drawing, so that the end, I redraw the scanline again. Now, what if that change happens twice? I lose the middle result. It's pure complexity vs speed, and I don't like the idea of aiming for a compromise. Either I implement it like real hardware would operate, or I don't implement it. Not trying to be close-minded about this. ZSNES and SNES9x took similar approaches with the other portions of emulation (SNES9x even had code to detect when the CPU was waiting for vblank and skipped the entire clock ahead to that point), and we all see how inadequate their opcode-based cores are now. And how many people are capable of modifying / maintaining either emulators' cores at this point? I really want to avoid probability, emulator state rewinding and speed hacks at all costs, and have thus far.
And indeed, it was the original goal. And yet now, I have maybe 5,000 - 10,000 people downloading and using each new version of bsnes. Given it has the highest compatibility among base games of any emulator, it is useful to a lot of people. So everyone would be happy if bsnes v0.019 was the last release they could ever use? What would the motivation for following the project be if no one could use it? Who would volunteer to help? I would not have the time nor energy to backport any new findings into older versions, as I have no interest in maintaining two forks of the emulator. This would essentially seal v0.019 as the final version of bsnes, give or take any new bugs that are discovered, any new features that are added (special chips, controllers, savestates, etc) after v0.019.
Precisely. The most intensive SNES game will bring bsnes to 40% of its' peak potential speed at present. The difference is almost entirely related to the scanline renderer (eg Star Ocean will choke bsnes, but Tetris will not). With a cycle-based PPU, bsnes' slowest speed would be roughly ~80% its peak performance. Compare that to SNES9x, where I could easily choke performance to a crawl (~1-2% optimal performance) with the right combination of trickery (writing to $420d recalculates a giant lookup table, imagine evil code that toggles that value nonstop as fast as possible). I should also add, that simply redrawing part of the scanline when a mid-scanline write is detected is a very complex thing to do. I would have to know the entire state of the S-PPU from a certain point to redraw the screen correctly. This could essentially get really messy when you think in terms of "worst case scenarios" that I would undoubtedly have to support. What if there were 50 modifications to S-PPU during a single scanline? That's quite the buffer log of events to unwind through to attempt to redraw the scanline. Also, more complex things could very well come into play: imagine if the exact details of per-scanline rendering changes somehow per actual scanline onscreen. Simply having a solid scanline renderer and a cycle-scanline renderer would no longer be sufficient. The emulation code would have to become even more complex. |
|||||||
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Mon Dec 25, 2006 10:52 pm Post subject: | |
|
|
|
| I said what I said knowing you're smart enough to come back with what you did, byuu. Yes, going back and recalculating something has the potential to cause a huge variance in real time performance. But doing something all the time that always takes an incredible hit on performance (dot based renderer all the time) for something that a SNES program just should not be doing anyways. Is that justifiable? I agree about "What if there were 50 modifications to S-PPU during a single scanline? That's quite the buffer log of events to unwind through to attempt to redraw the scanline." But you know that buffer is not infinite, and at what point do we reach absurdity about mode changes / data changes that could very well crash the real state machine in the PPU itself? Maybe there is some cool new screen mode that can be entered by crashing the PPU? How could an emulator writer ever know that before the fact? Is it okay to assume that writing to $420d is a valid thing? It should be, because maybe there are some fast rom chips and some slower registers of something else inside a cartridge. Writing outside of blanking is NEVER valid. What's more likely? Some code loop runs too long past blanking. Some new mischevious code does something to determine if it's running on an emulator. Guess what? Somebody is always going to be able to have their code determine that it is probably running on an emulator. I'm not saying you lose, I'm saying you've pretty much won at this point and maybe need to pass on your knowledge before you completely burn out. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Dec 25, 2006 11:13 pm Post subject: | |||||||
|
|
|||||||
Again I'm not trying to outright dismiss your idea, and in fact it really truly is the best long-term solution. The ideal emulator would do things exactly like this. It's no coincidence all of the bright minds in the SNES emulation scene keep telling me to do things this way. However ... The alternative is writing buggy, hackish code that implements the same functionality no less than twice to accomodate both the majority of games as well as special case games. Not a very good thing for the purposes of clean, self-documenting code :/ I also think that it may just be above my abilities. I've never written code to handle prediction and rewinding. I probably could, but it's not a skill I currently posess. One reason I wanted a dot-based renderer was to personally write brand new rastering demos that blow the socks off of all existing PD ROMs out there, and to show off what you can do by truly harnessing the full power of the SNES. One thing I wanted to try (don't know if it's possible, probably not) was a horizontally split mode7/mode3 screen.
Oh, there's no doubt I'll ever be able to reach perfection and beat out those trying to detect the presence of an emulator. If I were trying to do that, I'd be going after a different fruit right now to have the last laugh at d4s :P
I really, really do need to start writing documentation. I just have to ... find more time, somehow. Perhaps I should stop posting here so much, heh. |
|||||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Mon Dec 25, 2006 11:19 pm Post subject: | |||||
|
|
|||||
No, that's simply not possible! Posting on the zboard hasn't really slowed people down. I think doc writing is probably the hardest thing... but meh. It will certainly take some time..._________________ FF4 research never ends for me. |
|||||
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Tue Dec 26, 2006 1:25 am Post subject: | |
|
|
|
| I have not followed this thread very carefully, but I take it you have solved Koushien 2 bug. I don't think slowing down the emulator immensely to only support one game better is worth it. I know this may be a bad suggestion, but perhaps you can maybe work on SA-1 support as it seems to have the most games of all the unsupported chips. I know this would slow down the emulator a lot, but at least the slow down would be for more than one game. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Dec 26, 2006 1:48 am Post subject: | |
|
|
|
| No.
The two S-DSP issues remain. Koushien 2 randomly freezes, and Toy Story
has some sound repetition errors at various points in the game. I'm
really hoping anomie comes back around, because I haven't a clue what's
causing the problems nor how to fix them. Thanks to DMV27, as best we
know, Koushien 2's problem is due to ESA/EDL writes right around
disabling of the echo buffer. Both issues also affect SNEeSe, so
there's hope TRAC may one day look into the issues as well (but don't
bug him about it, I've already asked politely). The nice thing about SA-1 support is that even though it probably won't be playable at fullspeed on anyone's PCs, it will at least not slow down emulation of non-SA-1 games by much. And no, that doesn't mean I'm going to start working on it just yet. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Dec 26, 2006 4:52 am Post subject: | |
|
|
|
| I
would much rather prefer the dot-based renderer and any accurate ways
of emulating the system you feel capable of pulling off, even if no
visible end-user benefit is produced. Yes, I understand the implication
that the new renderer would render bsnes unplayable even on a high-end
PC but I think in the long run it's the better solution. Honestly, for speed and compatibility the current bsnes version is extremely capable and it's not like anyone's life depended on being able to run the very last version at 60fps or anything. Not to mention *Zsnes* is an extremely capable emulator too, overall. And we have Snes9x...and Trac's emulator and Overload's and the Snes emulation in MESS is getting better too and...Am I forgetting any major player? Well you get the idea. Don't worry, you won't get any "But but..! What happened to the SPEED..!" from this side of the screen. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Dec 26, 2006 7:37 am Post subject: | |
|
|
|
| The
benefits of pixel renderer on a game compatibility level are
practically nil. So if you're going to do it, the other reasons should
be worth it, because two years is a big piece of someone life for
uniracers. I'm not like Snark. I don't really like using an arsenal of emulators for each system. It's even more annoying than plug-ins. So I will continue waiting for special chips and sane peripherals. That's just my personal preference, though. I'm thankful for each day that you continue working on the thing. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Dec 26, 2006 11:25 am Post subject: | |||||||||
|
|
|||||||||
Geez, toss that thing out already if you don't want speedhacks...
Then don't go for the cycle-based renderer. Document all that has to be done and how your approach would be, comment the source etc., basically make it ready for other people to take over. The best thing would be if the components are separate enough that you can work on adding special chips while others can implement the new renderer.
Seconded. That should be the long-term goal. Special chips might get the attention of potential supporters. _________________ savestate editor: vSNES latest public version
|
|||||||||
Hazed
Joined: 30 May 2006
Posts: 65
Location: Centreville, VA
| Posted: Tue Dec 26, 2006 11:38 am Post subject: | |
|
|
|
| Writing
code that only works well on computers that only exist in theory never
stopped Bethesda Softworks from making The Elder Scrolls series popular. Frankly, if this were me I'd find this a tough decision as well, but I think I'd personally end up sticking to my guns and go for accuracy... after releasing one last version that works on slower computers. Moore's Law is still going to be in effect for the rest this decade, hopefully. Besides, you're doing this as a monument to the SNES, and taking emulators where they haven't gone before; there's no point in coming this far only to stop, when you could just take that extra mile that means that nobody will ever bother to do it better than you did (The Codex Seraphinianus is probably the perfect example of what I mean here). ...but if it were me, this project wouldn't have gotten too far in the first place; or if I did, this is where I'd stop, flip out, run away and only ever be seen again once, two decades later, gnawing on my wrist in the middle of the Sonoran desert surrounded by a pack of loyal coyotes. If that sounds like something you'd do... then by all means, don't do it. _________________ Only a couple screws loose. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Dec 26, 2006 1:06 pm Post subject: | |||
|
|
|||
Yes. And most importantly, regardless of what you choose, go for what YOU want instead of trying to decide according to what you think the majority of users want (one way or another)...I mean, bsnes is not a commercial product and there's no "satisfaction guaranteed" or anything. And if you ever need inspiration about not caring too much about the end-user: take a look a M.A.M.E
|
|||
Veteran
Joined: 28 Jul 2004
Posts: 789
| Posted: Tue Dec 26, 2006 3:53 pm Post subject: | |||||||||
|
|
|||||||||
No, no. Something pokes at the PPU mid-scanline, so you render the scanline up to the pixel that corresponds with the current cycle. There, now you have one partial scanline that corresponds with the PPU state up until it was prodded. Something prods it again during the same scanline, so you render more pixels. Up until the end of the scanline, where changes shouldn't have a visible effect until the next scanline. Or something like that, I think. Isn't your PPU already cycle accurate for register accesses? Or does it also rely on the renderer to keep its state up to date? (Wait, I could be reading the release version source, but that's probably a bit out of date now.)
Oops, forgot about that. Darn you, fancy sprite scaling trickery.
Nefarious!
Sounds like a project of extreme dedication and/or boredom for somebody else, then. |
|||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Dec 26, 2006 4:09 pm Post subject: | |||
|
|
|||
Oh, ok. Yes, that's what I was planning to try. That's pretty much how my CPU<>SMP synchronize now. I run one until one tries to access the other, then run the other until it tries to access the former. There's a fallback in case synchronization differs by too much, it will forcefully sync to avoid overflowing the cycle difference counters and such. This might have limited success with the S-PPU, but breaking everything down into individual steps really will hurt performance still. Take for instance a BG scroll register. Now, instead of preloading and manipulating it at the start of the scanline, I have to use the non-local variable that the MMIO register writes the new scroll location to, in case that value is changed in the middle of the scanline rendering routine. Only, it's not just the BG scroll register. But all 64 MMIO registers used by the S-PPU. I still think that even with this hack, things are going to get really slow, really quickly. I can only just barely hit 100fps right now with PGO. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Dec 26, 2006 4:16 pm Post subject: | |
|
|
|
| You probably dont want to hear this but i say take this path... You could always add bugfixes and new chip support to the current bsnes if your new code isnt too reliant on the sPPU. Dont base your decision on coding or not coding the sPPU on Unirally, the game sucks to much for that, at this point i could go as far to say either hack it or leave it broken. My vote is for adding special chips and hardware first... |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Dec 26, 2006 4:31 pm Post subject: | |
|
|
|
| If I were byuu,I would do this: Ditch the frameskip code (who needs this anyway?),improve the Windows port UI,add only the most important accessories/special chips: Multitap,SuperScope,SA-1,Super FX 1/2 and DSP-4 (yes,TG3000 is _that_ good) support and release a *final* version of bsnes for normal computers. Document everything and then go for accuracy,regardless of how much processing power it may require to run bsnes at full speed. By the time the dot-based renderer is completed,CPUs will become more than capable to run bsnes at full speed. Also,you can start to optimize everything after the PPU is done,lowering the requirements even more. If you fear the chip industry is only interested in cramming more cores,while not increasing the clocks at all,you should think twice. AMD's secret weapon (reverse hyperthreading) and IBM's GHz race are not too far away It's not only more cores we need but more GHz as well,and they now that. byuu.I would love to see your demo showing what's possible to do with a SNES if you use all of it's capabilities. But when I think of it,isn't it possible to do the same if you had one of those SNES Emulator SE dev boxes? You don't need to program a dot-based PPU renderer in this case. Last edited by kick on Tue Dec 26, 2006 4:50 pm; edited 3 times in total |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Dec 26, 2006 4:44 pm Post subject: | |
|
|
|
| i totally forgot about reverse multithreading, that could solve the whole sPPU problem | |
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Tue Dec 26, 2006 5:07 pm Post subject: | |
|
|
|
| Reverse Hyperthreading does not exist - it was a rumour initially spread by The Inquirer that they later debunked: http://www.theinquirer.net/default.aspx?article=32885 _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|
Rookie
Joined: 03 Mar 2006
Posts: 14
| Posted: Tue Dec 26, 2006 9:20 pm Post subject: | |
|
|
|
| Damn... the only thing stopping me from using bsnes right now is lack of vsync. Is there any way to turn that on without triple buffering or do they go together? Turning on force vertical sync in my ATI drivers for D3D doesn't do anything either. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Dec 26, 2006 11:06 pm Post subject: | |
|
|
|
| vsync doesn't work, I've tried it in the past. Even blitting immediately upon vsync edge being detected, the blit to the screen takes so long that the image still ends up tearing. It's just a standard video->video hardware fullscreen blit, too. Nothing special about it. A shame, too. That would be one less frame of delay between input on the controls and visual response on the screen. Something some people are apparently very perceptive to. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Dec 27, 2006 12:23 am Post subject: | |||
|
|
|||
What's wrong with triple buffering? Works for me, no tearing. |
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Wed Dec 27, 2006 3:03 am Post subject: | |
|
|
|
| Triple buffring causes my sound to crackle horribly. In fact, the only thing I ever could wish from bsnes right now is a fix to the sound crackle on tripple buffer. If I could have that, I'd even pay for it. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Dec 27, 2006 3:33 am Post subject: | |
|
|
|
| I've
spent several days trying to fix it. Basically, when I call the triple
buffer "Present()" function, it automatically locks the entire process
until a flip occurs. This essentially locks the framerate at 60fps. But
the video simply must run at 60.09fps (or 59.97fps in interlaced mode)
to generate the correct amount of audio samples. Even a hair off, and
sound will eventually "crackle" to a certain extent. Ideally, Microsoft would offer a PresentWhenPossible() function, that I could call to queue a flip to automatically occur the next time vblank is reached. When things get too far behind, no flip occurs. When they run too fast, a frame gets skipped. While it gets trickier to handle non-native refresh rates (60hz/NTSC and 50hz/PAL), those would still at least work without crackling or tearing with such a function. However, trying to add high performance timers to detect vblank edges and do the Present() call myself always results in tearing anyway. Much like SDL input inside a GTK+ window, this remains a major issue that I need outside help with. For all the perceived benefits of open source software, I've had at best 3 contributors help me with bsnes thus far. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Dec 27, 2006 8:50 am Post subject: | |
|
|
|
| Using external tools for triple buffering causes the same crackling. Wouldnt it be easyer to just cut off the 0.09 frame, and buffer add the 0.03 ? |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Dec 27, 2006 12:12 pm Post subject: | |||
|
|
|||
|
Stupid question: Does the same issue happen with OpenGL? _________________ savestate editor: vSNES latest public version
|
|||
"God"
Joined: 27 Jul 2004
Posts: 1171
| Posted: Thu Dec 28, 2006 7:53 pm Post subject: | |
|
|
|
| I
think tripple buffering is only useful for apps like Media Player
Classic and ilk, its probably a bad match for more interactive software. _________________ Does [Kevin] Smith masturbate with steel wool too? - Yes, but don't change the subject. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Dec 31, 2006 7:29 am Post subject: | |||
|
|
|||
My god. I'm not sure if whoever implemented listboxes in GTK+
was an evil genius, or absolutely retarded when it comes to designing
clean, intuitive, easy to use interfaces (eg libraries). But I won. I
beat the motherfucker and implemented listboxes into libui anyway.
|
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Dec 31, 2006 6:18 pm Post subject: | |
|
|
|
| i guess an evil diabolic laugh is in place here Byuu: Muhahahahahahahaha~~ |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Sun Dec 31, 2006 9:49 pm Post subject: | |
|
|
|
| Found some interesting info: http://news.com.com/A+peek+at+faster+Power6%2C+Cell+chips/2100-1006_3-6146309.html?tag=nefd.lede A bit old,but still an interesting read. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 02, 2007 2:33 am Post subject: | |||
|
|
|||
bsnes v0.019 has been released. But I'm afraid it's mostly just bad news all around.
|
|||
New Member
Joined: 02 Jan 2007
Posts: 1
| Posted: Tue Jan 02, 2007 6:25 am Post subject: | |
|
|
|
| would it not be possible to still remain accurate and lower the system requirements if you reprogrammed the emulator in ASM oppssed to the much slower pure C++ coding? | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Tue Jan 02, 2007 6:29 am Post subject: | |||
|
|
|||
Without even knowing the response, C++ is not "slow". Only poor code will always make things run slow. It matters not the language. _________________ FF4 research never ends for me. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Jan 02, 2007 6:59 am Post subject: | |||
|
|
|||
It would be possible. However, one of byuu's goals is writing portable code, and ASM is much less portable than C++. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Jan 02, 2007 7:28 am Post subject: | |
|
|
|
| Thanks for the release, byuu. You are the master of downplaying your emulator.
This release brings the latest accuracy improvements from the .018 wips
to the public, albeit at another speed hit. Those of us with newer cpus
will be all over this like a dog on a frisbee. |
|
New Member
Joined: 26 Mar 2006
Posts: 7
| Posted: Tue Jan 02, 2007 11:15 am Post subject: | |
|
|
|
| Hi
byuu, I really look forward to the day that bsnes accurately emulates
the SNES 100% regardless of speed. That code may be used as a reference
to other snes emulators, just like MAME is used as reference for other
arcade emulators. I hope that you continue your work and thanks a lot! |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Jan 02, 2007 11:37 am Post subject: | |
|
|
|
| I
don't know about you guys... but I just tested bsnes v0.019, to check
the speed differences with v0.018 on my computer (Celeron D, 2.4 GHz,
512 MB RAM). I tested them with my Super Mario Kart hack. 1- Title screen, around 57 FPS on both versions 2- Player selection screen, around 55 FPS on both versions 3- During tracks, around 53 FPS on v0.018, and 60 FPS (full speed !) with v0.019 (I retried a couple of times to make sure those numbers are correct and stable) Not only that, but the 1-pixel line flickering that used to be there during tracks at the bottom of the first screen half is gone with v0.019. Doesn't look like such a bad release to me, byuu. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Jan 02, 2007 12:32 pm Post subject: | |
|
|
|
| Stifu: You're only going to notice that 40% speed up byuu was talking about in games and sequences similar to the ones byuu profiled against. Odds are byuu didn't profile any DSP-1 games. And on the flip side, any game that acted in an opposite manner that byuu profiled against would run slower, so in those cases (which are probably rare to get the exact opposite) this release would be faster. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Tue Jan 02, 2007 12:46 pm Post subject: | |
|
|
|
| Nach:
ah, okay. Actually, considering byuu's somewhat "sad" tone in his
message above, I was sure he meant bsnes got slower. I misread, I
thought it was a 40% decrease. Also, the fact he said "I'm leaving v0.018 up, as it may very well be the last stable, fast version of bsnes ever released." made me assume v0.019 was supposed to be slower. |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Tue Jan 02, 2007 1:38 pm Post subject: | |
|
|
|
| It is sad to be playing DKJM and others 40% slower. There are also some general cases which will now be slightly slower. But it won't be for everything, that's not how PGO works. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 02, 2007 2:07 pm Post subject: | |
|
|
|
| Thanks for the kind words, as always. Typically, when I run PGO, I run it on the following: - Chrono Trigger title screen The mode2 offset-per-tile code always make bsnes' framerate drop significantly, PGO mitigates much of this huge speed loss whenever OPT occurs in any games; not just Chrono Trigger. - Zelda 3 The rain on the world map speeds up color add/sub in every game I test the final build against. - Super Mario World It's a classic. Has a lot of common SNES stuff to optimize against here. By profiling against these three games, the resulting EXE is faster in nearly every game. On a completely unprofiled game (Der Langrisser scenario commander select screen), my framerate was at 126fps on my main PC with v0.018. It is now at 83fps with this latest release. I get similar results with most every other game I play. We've already known in the past that all of my speedup attempts (incl PGO) only seem to help newer processors. Look at the last set of posts on the topic of v0.018's speed and subsequent speedups: - Celerons showed virtually no differences - Pentium IV CPUs barely showed a difference - AthlonXPs showed a small difference - Athlon64s showed a big difference - Core 2 Duos showed the biggest difference of all The most obvious difference for those of you not in "the know" is that the above list is roughly in order from the highest pipeline count to the lowest. It isn't just because the chips are "newer" or anything like that. PGO isn't just beneficial for the exact games they are profiled against, as all SNES games share similar characteristics (eg opcode "beq" will always be used more than "stp" in any given game). Take for example a switch table with eight cases. Let's say case 0 virtually never happens, and case 3 almost every single time. PGO will see this and reorder the table to test for case 3 first. Now you're thinking, "ok, why not do that in your code?" Two reasons. One, it's more logical to order the table from cases 0 - 7. Human beings trying to read the code won't understand why the table is out of order, in fact: seemingly in random order. Two, I don't always know which parts of the code PGO optimizes. It doesn't provide a list of changes for me to pick out the biggest overall speed gains. I will agree with Nach though, that PGO won't result in a 40% speed drop everywhere. But there are games that are that much slower for me, and many that are still 20+% slower than the last build. I've yet to find any game that was slower as a result of running PGO, but I wouldn't be surprised if such games did exist. They would be the exceptions, however. Anyway, I have some ideas I'd like to try this weekend to see if they help. I'd suggest not getting one's hopes up, but maybe it'll build with PGO again. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 03, 2007 11:34 pm Post subject: | |||
|
|
|||
Hmm,
some (stolen) code from DeSmuME's GTK+ port. Posting here so I remember
to add it to libui. This should hopefully allow (keyboard-only) input
for the GTK+ port. Hey, it's a start.
|
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Fri Jan 05, 2007 6:36 pm Post subject: | |
|
|
|
| Wow
this is interesting! If I set bsnes 19 to my custom res settings for
fullscreen, I no longer have crackling sound with tripple buffer! It
may be by pure fluke, but I'll take it! My custom fullscreen res is 1110x1024 with the bsnes res set to 1024x896x60. Required the use of power strip to add 1110x1024 to the video card. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Fri Jan 05, 2007 10:14 pm Post subject: | |
|
|
|
| byuu,can you add hue/saturation (or rgb) controls to bsnes? That's the only thing I find missing from bsnes. For now,the colors in bsnes look a lot different than what I used to get on my TV. For example,the color output of Samsung TV sets is more on the blue side (compared to a standard computer monitor),while old TV sets of the 80's are more on the yellow side.Sometimes the differences can be huge,like the menus in Breath of Fire (J). NEStopia and ZSNES have this feature and it helps a lot to get the colors close to the real thing. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Jan 06, 2007 4:37 am Post subject: | |||
|
|
|||
|
kick, please take a look at bsnes/src/snes/video/video_colortable.cpp. If you can provide me with algorithms in compatible form to eg:
Then yes, I will add these sliders for you. The algorithms must take as input and return as output, either BGR555 or RGB888 (and not YUV, unless you want to convert back and forth inside the function). I have not been able to find the appropriate algorithms myself. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Jan 11, 2007 11:32 am Post subject: | |
|
|
|
| A few people have been confused about switching modes in bsnes. Here's a recommendation for .20: - Change "Video profile to configure" to simply "Configure for" - Elongate the selection box and then change "Fullscreen" to "Fullscreen (F11)" If .20's different GUI makes this moot, then just ignore this and I'll wait for WIPs. Truly, I should have thought of this before .018, though. |
|
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Fri Jan 12, 2007 1:29 pm Post subject: | |||||||
|
|
|||||||
|
Byuu,
here are the funtions for altering the colour based on hue, saturation
and value adjustments.. I have tested them and they should be (close
to) as efficient as possible, though I do think it would be more
efficient to use one function for all three (but right now I can't be
buggered to make one It'd be an extended version of the hue_adjust) hue_adjust, hue is a floating point value stored in degrees - will not work right if adjustment pushes it below -360° or above 720°:
saturation_adjust, saturation is an floating point value between 0.0 and 1.0:
value_adjust, value is an integer in between 0 and 255:
|
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jan 12, 2007 4:29 pm Post subject: | |
|
|
|
| I'm
not sure I understand why people would want to adjust HSV in an SNES
emulator ... HSV is neither native to the SNES, nor to the YUV/YIQ
televisions people mostly played SNES games on. It's really just
graphics artist fodder that has little use in actual display technology. I would think YUV/YIQ style adjustments (tone, etc) would be what people are expecting. I do have an algorithm for high-precision RGB<>YCbCr, but I don't really know how to make TV-style adjustment options from manipulating those values, other than the obvious brightness adjustment. Should I just make scalers (~0.25 - 4.0x intensity) for the Cb and Cr channels? |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Jan 12, 2007 4:33 pm Post subject: | |||
|
|
|||
"Because, we want it." Note, this is generally the same group of people who want to "overclock" the SNES. Though, I'm pretty sure everyone wants to have TV-ish control altogether. _________________ FF4 research never ends for me. |
|||
Veteran
Joined: 27 Nov 2004
Posts: 621
| Posted: Sat Jan 13, 2007 7:39 am Post subject: | |
|
|
|
| if
bsnes runs in an overlay, couldn't one muck around with the overlay
sliders in the display settings? (system and graphics card dependent, I
suppose). Or mess with the monitor's tint until mario looks like an
oompa-loompa man? hey byuu, could you model the distortion of the obviously imperfect second order low-pass filter for the audio output, taking into accound the imperfections of the particular capacitors and op-amps used? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Jan 14, 2007 12:48 pm Post subject: | |
|
|
|
| I
just got my Core 2 Duo rig installed last night (was on a P4 2.4c).
First thing I did was run through the Chrono Trigger intro in bsnes
.019. Never went under 60 and the sound never crackled, even on the
black omen effect. POWAR! |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Jan 14, 2007 8:14 pm Post subject: | |
|
|
|
| But how many frames per second do you get with speed throttling disabled? :) | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jan 15, 2007 4:25 am Post subject: | |
|
|
|
| First screenshots of libui in bsnes: Same exact codebase. The current WIP is obviously missing any semblance of a GUI, other than the menubar and a ROM file loader. Lots of issues on both ports, of course. I'm aware of the audio repeating issue on the Windows port and already know how to fix it (had the same problem with the old Windows UI). Linux of course simply has no audio or input. I'm planning on moving the framerate counter to display inside the image, rather than on the titlebar this time. That of course won't happen anytime soon. I don't expect to be adding fullscreen support back in anytime soon, either. Once this port gets stable enough, I intend to remove the "ui/win" and "ui/sdl" ports completely. After that, I'm going to have to start seriously rewriting a lot of internal stuff. I'm also planning to go with a simpler user interface this time around. bsnes v0.019 had too many options and features. I think I may scale back this time and make things a lot simpler. Move a lot of the control settings back into the menubar, rather than in the custom options panel (which will most likely still exist). |
|
Regular
Joined: 10 Dec 2004
Posts: 307
| Posted: Mon Jan 15, 2007 9:07 am Post subject: | |
|
|
|
| I like the framerate counter better inside the title bar, personally, so that the game screen is still totally intact... But maybe you want to put it over the game screen so that it can still be seen in fullscreen mode, or something. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jan 15, 2007 10:10 am Post subject: | |
|
|
|
| Nice to see the rewrite is coming along. To answer your earlier question: 1.86ghz e6300 / Chono Trigger title screen .018 - 140 on pendulum, 90 max dip on wavy text .019 - 105 on pendulum, 60 max dip on wavy text So I'm losing around 33% without PGO. Still above the the magic 60 on the worst case scenarios, though. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Mon Jan 15, 2007 10:36 am Post subject: | |||
|
|
|||
|
Can you play with 4 players in Streetracer? The 4 split-screens might slow things down... _________________ savestate editor: vSNES latest public version
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jan 15, 2007 11:26 am Post subject: | |
|
|
|
| Players 3 and 4 are grayed out. Probably because bsnes doesn't support multi-tap. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 17, 2007 8:05 am Post subject: | |||||
|
|
|||||
|
http://byuu.cinnamonpirate.com/images/bsnes_x2.png Look closely to see what's new. You can pretty much thank Nach for that. Also, if anyone's good at makefiles, can you please take a look at: http://byuu.cinnamonpirate.com/temp/Makefile.txt ? I'm trying to create an implicit rule that can match: %.$(OBJ) : $(<D)/%.cpp However, gmake seems to be ignoring $(<D) completely. I've tried countless variations on this, such as $(dir $<)%.cpp, $(basename $<).cpp, etc, but none seem to work. I know it's possible to use $< in the dependency list, because %.$(OBJ) : $< matches all targets. As it stands, I have to use a really evil trick to get around this, by recursively invoking make with $< as a variable so that I can use the conditional calculations to figure out what filetype $< is. EDIT: nevermind. I figured out another trick that works. Replace the recursion block with the below, and you get the same effect whilst only needing to invoke make one time.
Basically, we simulate the conditional compilation (based on file suffix) by using nested variables and pattern substitutions on the first dependency, which is hardcoded as the source target in individual object definitions. How intuitive! Hooray, open source software! Now if only gmake could automatically deduce dependencies from these files, eliminating the need for the individual object rules to point at every file that is part of said object. Hahahah, yeah, just dreaming :) I think I may just make an alternative to gmake, but I'll hold off for now, since I've found a workaround in gmake for the time being. EDIT 2: The above still wasn't sufficient for Nach's plans. Fair enough, let's step things up another notch.
Last edited by byuu on Wed Jan 17, 2007 7:29 pm; edited 1 time in total |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Jan 17, 2007 5:50 pm Post subject: | |||
|
|
|||
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Jan 18, 2007 12:53 pm Post subject: | |
|
|
|
| Cool! sound in linux. Byuu i dont know if you knew this already http://www.slack.net/~ant/libs/ntsc.html#nes_ntsc blargg relased a new version of his ntsc filter |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Jan 18, 2007 3:23 pm Post subject: | |
|
|
|
| tetsuo, obviously you hadn't been following this thread: http://board.zsnes.com/phpBB2/viewtopic.php?t=6433 _________________ FF4 research never ends for me. |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Thu Jan 18, 2007 11:40 pm Post subject: | |
|
|
|
| Nice work on libui - how did you get fast drawing inside the GTK window? | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Jan 19, 2007 9:36 am Post subject: | |
|
|
|
| doh, i just realised i have not been in the developement secrtion for over 3 weeks, thanks for waking me up Deathlike | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jan 19, 2007 9:51 am Post subject: | |||||
|
|
|||||
Thanks, you're free to use it with no strings attached if you like. I implemented two video blitters for GTK+. One uses GTK+'s own gdk_draw_rgb_image function (not that good, it only accepts RGB888, so you have to convert the SNES renderer output from RGB565 -> RGB888, then transfer that to video memory, and somewhere along the way convert back to the display format (which, in my case, is RGB565). The other is just the SDL_WINDOWID environment variable hack. Neither support hardware scaling, and neither allow me to use SDL input for keyboard input support. I'm planning on adding an Xv renderer next, to perform hardware scaling. The only problem with that is there's absolutely no way to vsync / triple buffer with Xv, and hardware bilinear filtering is always enabled. I'd also like to add an OGL renderer, but that seems like too much work for me. It took me months to really get the hang of D3D9, and I don't feel like learning another 3D API just to blit 2D rects to the screen. As for input, I'm going to go with Nach's suggestion, and just capture key_press_event + key_release_event on the GTK+ window. To avoid sticky keys when the application loses focus (and thus misses key_release_event messages), I'm going to catch window focus gained/lost messages and clear the keyboard buffer. Best I can do since X-Windows lacks an alternative to Windows' GetAsyncKeyState. Not great, but better than no input at all. I'm hoping to still use SDL input for gamepad support one day. --- In other news, the Makefile is now updated to the most recent work. I've also simplified libco a little more (co_init and co_term are called automatically; pre-defined stack sizes are now multiplied by sizeof(void*) for semi-consistent behavior across different platforms) and ported it to two new targets: x86-64 and ucontext. The x86-64 port is currently broken, as I lack a 64-bit OS to test the code on. I could really use some help if anyone is familiar with x86-64 programming to tell me where the problem is. It's a 1:1 port of libco_x86, but with registers changed according to the SysV ABI (I'll make another for Microsoft's when I get the SysV/Unix port working). Bisqwit also gave me an AMD64-optimized version which will be included on the libco page as an optional download. This one works but is licensed under CC BY-SA. The ucontext port just uses <ucontext.h> from Unix. For those of you who've said I should just use pth instead of "reinventing the wheel" by making libco, feel free to try this port out. pth uses ucontext for its' Unix wrapper, and setjmp magic for Windows. To say ucontext is slower is a severe understatement: it is fifty times slower than libco_x86. Even windows fibers are only twice as slow as libco. But, don't take my word for it, see for yourself: http://byuu.cinnamonpirate.com/temp/libco_ucontext.h.txt http://byuu.cinnamonpirate.com/temp/libco_ucontext.cpp.txt Lastly, the ZIP for the latest beta:
Again, if anyone could take a glance at libco_x86_64.asm and give me suggestions, it'd be appreciated greatly. |
|||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Fri Jan 19, 2007 1:19 pm Post subject: | |
|
|
|
| If
it's worth anything, OpenGL works in the exact same way as D3D9 for the
most part. Slightly different function calls are the main difference.
If you now understand the 3D hardware drawing process and concepts to
get things going in D3D, it should be MUCH easier for your to learn
OpenGL if you choose to than it was D3D. It's just alternate syntax to
the same thing. That's a generalized statement of course, but mostly
true. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Fri Jan 19, 2007 10:53 pm Post subject: | |
|
|
|
| OpenGL
is pretty easy - it took me only a few hours to get it working in
SDLMAME initially. Check out the NeHe tutorials, they're quite good.
The one issue is that on Linux the ATI binary driver is very
performance-sensitive about 15/16 bit texture formats - it prefers
either 1-5-5-5 or 5-5-5-1 (I don't recall which off the top of my head)
and is really slow with 5-6-5 or the "wrong" 5-5-5 format. The NVidia
binary driver and most open source 3D drivers don't care - they're
always fast. Also, older OpenGL (pre 2.0) required power-of-2 sized textures, which isn't much of a problem on the SNES since the framebuffer width already is (and you can just pad the height with black and adjust the U/Vs so everything works out). |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Jan 19, 2007 11:14 pm Post subject: | |
|
|
|
| Might I get a link to that code to take a look at it, please? That's a shame about RGB565, but I think everything should still work. I believe my filters apply to BGR555 and finally output via one single color lookup table, so I should be able to do any 16-bit format (but not 24/32-bit formats) with it with zero speed loss. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Jan 20, 2007 11:24 am Post subject: | |
|
|
|
| Maybe switching to openGL will fix the crackling sound with tripple buffering | |
Trooper
Joined: 05 May 2006
Posts: 367
| Posted: Sat Jan 20, 2007 6:33 pm Post subject: | |
|
|
|
| Why would it? | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Jan 21, 2007 1:01 pm Post subject: | |
|
|
|
| Magic | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Jan 21, 2007 2:00 pm Post subject: | |||||
|
|
|||||
|
Firon: Why wouldn't it? *is interested*
I don't know anything about OpenGL, but maybe it handles VSync better since it uses a different driver set? _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Sun Jan 21, 2007 8:14 pm; edited 1 time in total |
|||||
Rookie
Joined: 20 Aug 2006
Posts: 35
| Posted: Sun Jan 21, 2007 7:27 pm Post subject: | |
|
|
|
| The NeHe tutorials are at: http://nehe.gamedev.net/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jan 22, 2007 8:28 am Post subject: | |
|
|
|
| Found a regression bug that unfortunately made it into v0.019 official. HDMA bus sync timing is required for BoF2 German ( sigh, and d4s went out of his way to ask people to use bsnes, too ;_; ). I turned off HDMA bus syncing since it was glitchy with either Battle Racers or SoM2 map (I think it was the latter). I'll have to look into it further. For now I have two workarounds: 1) temporarilly raise the HDMA sync delay from 12 to 18 clocks (from best case timing to average timing, still not great of course), 2) revert to the old HDMA bus sync code and take the hit from the other game. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jan 22, 2007 7:58 pm Post subject: | |
|
|
|
| Before anyone asks what it is, I think I just figured it out. If you don't jump to the title screen, the game will hang after the team bof2 screen. Only happens after the first run though, with a .srm generated. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jan 22, 2007 8:35 pm Post subject: | |
|
|
|
| Since it runs on hardware, it's clearly my fault, but I have to admit, the translation is quite
sensitive to timing. Moreso than any commercial game on the system. Not
saying that's a bad thing: you'll always get correct results on
hardware, and that's all that counts. If anything, it shows d4s pushed
the hardware even harder than commercial devs could. Since a difference of ~6 master clock cycles/scanline (roughly the length of 1/4th of an opcode) broke it completely, I'm really quite impressed that it runs on other emulators at all. The next release should address the problem. I will continue to be cheap and use the ~18 clocks fix that works for everything. I'm way too far into the UI to switch up and work on the core again just yet. Should I post an interim release for this fix, or just an advisory to please use v0.018 for this game for now? The new UI is still in shambles, but the old one still compiles. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Jan 22, 2007 10:33 pm Post subject: | |
|
|
|
| Question is, how many bsnes users aren't still using .018 already? And how many of those are German? What exactly was it that broke PGO anyway? New IRQ code? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jan 22, 2007 11:15 pm Post subject: | |
|
|
|
| I suspect I don't have that large of a userbase. Probably 5,000 or so, tops. Unfortunately, I don't know exactly what broke PGO or when. I know it was already very, very flaky and I would often have to try several times to get it to work. I had a list of games that I knew I couldn't profile. Now, I can't profile anything at all. Very annoying. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Jan 25, 2007 8:38 pm Post subject: | |
|
|
|
| Byuu,
you have asked for help about certain code problems you have, but it
seems you get little response from those requests for help. I imagine
that you could do two things to increase interest in bsnes and get more
people to look at the code: - Have a forum hosted on your own website. As it is now, it's kind of hard to find information in this really long thread. - Have your code hosted on some kind of public repository (SourceForge/BountySource). I would definitely love to see some of the work you do to the code between releases. It would also make the code more accessible to everyone. I'm sure you've already thought about these things, I just wanted to put it out there. To some extent, I want to learn C/C++ just so I could contribute to your program (mainly GUI stuff and extra features). I like your coding philosophy. I have become frustrated with documenting ZSNES because it so freakin complex and has so many features with complex behavior. Any contributions I would (theoretically) make would have complete, predictable behavior and be self-documenting where appropriate. If you don't feel you have the time to change/maintain your website and a forum, I would feel honored to take on that task for you. I have experience administering my own private phpBB2 forum. And, of course, I have extensive experience with HTML (~7 years). _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Jan 25, 2007 9:01 pm Post subject: | |
|
|
|
| I dislike phpBB, and don't have SQL access anyway. I've been meaning to write my own board, but I always have something more important to work on :/ I definitely dislike SourceForge / BountySource. I work on the codebase locally, so I'd have to upload all of the changes. And since I don't have any full time coders working on bsnes with me, it's not really very productive ... It doesn't help that the most important things I need help with are so highly specialized that there's maybe three or four people who might be able to help still around :( Luckily, thanks to Nach and some tricks on my end, the Linux stuff should be taken care of. Nach's libao port has audio working, and I'll have input working here shortly. Then all we need is a better renderer to do hardware video scaling. Otherwise you're stuck with a 256x224 window only. |
|
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Thu Jan 25, 2007 11:04 pm Post subject: | |||
|
|
|||
Is it cos of all the spambots But meh. I know you said you don't have SQL access, and you're going to write your own board, but you might wanna give SMF a try. _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Fri Jan 26, 2007 1:53 pm Post subject: | |
|
|
|
| SMF
as of version 1.1 has been spambot proof on ROMhacking.net without any
modifications. It's probably only a matter of time, but it does seem to
be one step ahead of some other PHP based free forum software. Also, don't forget about SQLite. It's built right into PHP5, NO database server required! It uses SQL with flat files. Any piece of forum software with a database abstraction layer can probably use it. I've seen mods for a few popular boards. Just something to keep in mind for somebody who doesn't have access to any database server software. Because it's flat file, SQLite is in many cases faster than say MySQL. So, even if you want to code your own, that's definitely an option to consider. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|
saskatchewanite
Joined: 26 Apr 2006
Posts: 317
| Posted: Fri Jan 26, 2007 5:39 pm Post subject: | |||
|
|
|||
SMF is unsecure as hell imo. I ran it on my domain for a while. It was hacked within a week. Though this may have changed because I have not tried the newer versions. I was using the RC2 build for 1.1. _________________ everything i say is a lie the above line is true |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Fri Jan 26, 2007 10:11 pm Post subject: | |
|
|
|
| Thats whatcha get for running RC versions of stuff in a production enviournment But in all seriousness, the old school 4 life boards were using SMF 1.1 RC2 (or was it 3 when I first signed up?) and it worked fine _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Jan 29, 2007 8:04 am Post subject: | |
|
|
|
| I
now have an Xv renderer for Linux/BSD users. This means hardware
accelerated video scaling. It also supports all video modes (hires,
interlace and overscan settings all work as expected). This version also has a bit more of the UI rewrite done, but not much. I've been having a lot of troubles with making a unified API that works the same on both Windows and GTK+. I still have some problems (you can't get the absolute size of a window in GTK+, so snapping windows to screen edges like in the Windows port is not possible), but I've also made some progress as well (managed to create a unified API for controlling listbox column sizes on both platforms). Well, here's a screenshot. Pretty much the only thing stopping the Linux port from being usable now is the lack of input support. In due time ... http://byuu.cinnamonpirate.com/images/bsnes_x3.jpg |
|
New Member
Joined: 12 Aug 2005
Posts: 4
| Posted: Tue Jan 30, 2007 3:42 am Post subject: | |
|
|
|
| byuu, that's looking great! thanks for the port. | |
Hazed
Joined: 07 Feb 2006
Posts: 79
| Posted: Tue Jan 30, 2007 10:05 am Post subject: | |||
|
|
|||
To be fair, under X11 that sort of thing is really the responsibility of the window-manager, not each individual app. I know Metacity (the standard GNOME window manager) works like that out of the box, many others have it as an option. |
|||
Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
| Posted: Tue Jan 30, 2007 11:23 am Post subject: | |
|
|
|
| It's been a long time since I tried bsnes and it seems it's progressed quite a bit, great work, seriously . Sorry if I mention something that has already been stated but I just don't feel like reading 87 pages... so go ahead and tell me if I say something redundant. I recently downloaded it again to see how it emulates Star Ocean as compared to ZSNES, and the first thing I noticed is that bsnes doesn't auto patch IPS files. So I manually patched SO with SNESTool and gave it a shot and that's when I noticed the DeJap logo displays as a bunch of messed up pixils. What could possibly be the reason for that? Other than that, so far so good. It doesn't seem to have the sound bugs which ZSNES has with it (the sound pausing after a battle). bsnes' sound in general is fine... except for when it drops down below 60 frames per second to say... 59, then the sound is thrown completely off sync (or is the framerate/sound thing just a coincidence?) and sounds like garbled crackling. In some situations for some reason it just drops down to 59 frames such as Chrono Trigger's first page in it's menu, it doesn't matter what filters or whatever I use it seems to always run at 59FPS and the sound is thrown off sync, when I move to any other page of it's menu the sound goes back to normal. Could any of you try this out to see if it that's how it is in general or if it's just me? I know the emulator is a work in progress and some of these questions may have been answered in the previous pages but I was wondering if bsnes will ever include the following things: -Auto IPS patching (I dunno about you guys but I prefer to have separate IPS files) -Filters such as 2xSaI -vSync -Sound options -Save states -Save directory options |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Jan 30, 2007 1:09 pm Post subject: | |||||
|
|
|||||
The garbled gfx is probably the result of a faulty patching. Try NSRT. edit: also in regard to translations in general keep in mind that if a patch fail on real hardware it will probably fail on bsnes as well. Some patches will work fine with Zsnes but not on hardware because they were coded primarly with Zsnes in mind (which doesn't quite emulate the Snes to the same extend as bsnes does)
Two reason it might drop below 60. 1) Either you're hiting a particularly demanding part of the game and you don't have the horsepower to get a consistent 60fps. or 2) This has something to do with the internal Snes framerate versus monitor refresh rate in which case the crackling sound should be fairly consistent (like every 10 seconds) Since you said it only occur in a specific place it most likely caused by 1. Try unthrottling bsnes and check the framerate. If it goes from 72 to 59-60 there's your reason The only solution to 1) is of course to get a better CPU. As for 2) Someone (FirebrandX) mentionned they were able to get rid of the cracking sound with triple buffering on using Powerstrip. http://board.zsnes.com/phpBB2/viewtopic.php?t=4510&start=2100 |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 30, 2007 3:30 pm Post subject: | |||||||
|
|
|||||||
Probably the same reason Gideon Zhi's Ys 4 translation doesn't show any of the dialogue font in bsnes or on real hardware: the patch author was unable to test on hardware (though in this case due to the use of a special add-on chip that copiers do not support), and relied on ZSNES. The game looked fine on ZSNES, so it was assumed correct. Though we can't be certain how this translation works on hardware since none of us can test it, I'm willing to put my money on it being a problem with the translation; given that out of 4,000+ games, only two minor OAM graphical issues have been found in bsnes. Perhaps I'll have to start displaying a popup when you load these fan translations or something, this question is way too common.
Your processor is too slow. Unfortunately, I lost 30-40% of the speed in bsnes because Microsoft's multi-thousand-dollar-per-license "enterprise-class" compiler is unable to build bsnes with profile guided optimizations. The linker simply bails out halfway through. Another 30% was lost to IRQ accuracy improvements that really only fix one or two games. Every time I try and range test IRQs, I end up with bugs. So I rewrote the IRQ handler to test every clock position. The code is much simpler, but much slower as well. So I share the blame with a lot of the recent speed losses. Even my processor can't keep up with 60fps in all games anymore. To make matters worse, the big conundrum now is whether to slow down bsnes another 200-300% to fix those two aforementioned graphics bugs affecting only three games. The idea of having 100% compatibility is nice, but at the same time, I wanted to be able to actually use bsnes one day, too :(
IPS is defective. No two ROM hackers can agree on whether to make all patches against headered or unheadered ROMs (even though the former is retarded), IPS doesn't specify, and I can't simply guess. bsnes will one year have auto UPS patching (IPS' successor). Vertical sync / triple buffering is hopelessly broken. I can't fix it, so no. bsnes will never, ever have this. bsnes has all the sound options necessary. Mute and playback frequency (this is how fast forward / slow motion work in bsnes). No, I'll never have statestates. Not ever. Save directory options have been there for over a year. I keep the lesser used functions outside of the configuration screen. Hint: look in the config file. |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 30, 2007 6:34 pm Post subject: | |
|
|
|
| So,
easily the most desirable thing for bsnes would be liquid smooth video
and audio. Unfortunately, as we know, it's completely impossible to be
100% faithful to the original hardware, exactly match the speed of a
real system, and maintain perfect reproductions of video and audio at
the same time. So something would have to give. As best I can see it, there are videophiles and audiophiles, so ideally I should cater to each individually. Either way, it's not possible to run the SNES emulation at the exact speed of a real system and get smooth video or audio. Monitors cannot run at 60.09hz and sound cards cannot output 32040hz. So that's out either way. So then, two options. First, video synchronization: Scale video playback to refresh rate. That is, 60/120hz for NTSC, regardless of interlace setting. 50/100hz for PAL. If your monitor doesn't support one of those (and most LCDs won't do 50 or 100hz), you're out of luck. Sorry. Now, we resample the audio to accomodate this. 32040hz becomes (60/60.09*32040)=~31992hz. Finally, that would need to be resampled to 32000hz. Perfect video, always smooth. Slight sound distortion. Input response time might be slightly higher with this approach, and in turn audio response time might be slightly lower. Second option, audio synchronization: There's no getting around the pitch being a tad off due to the sound card outputting at 32000hz instead of 32040hz, but we can avoid resampling the audio, at least. So then, we play the audio back at 32000hz, and still sync the video to the output of the monitor. Too many or too few video frames may be generated, which can cause a skipped / duplicate frame on occasion. (32000/32040*60.09)=~60.015hz. So, one dropped frame every (1/0.015)=~66.7 seconds. Crystal clear audio, but every minute or so, you'll notice a slight stutter. Especially in animations and scrolling backgrounds. Has to be one or the other. Otherwise you deal with shearing video and/or cracking audio. I'm thinking, offer both, but make the default the video synchronization method. Despite more people claiming to be audiophiles, I've noticed that many simply don't know what they're talking about (not saying that about anyone here, just in general -- especially toward the people who don't even have SNES systems to compare against and go from memory alone) :/ Video skipping or duplicating frames would be far more noticeable to the majority of users. Feel free to present counterpoints and I'll consider them. And now, the bigger problem: I don't know how to implement either of these. But I can at least add the options and APIs into bsnes, in case someone, somehow, is able to help implement this stuff in the future. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Jan 30, 2007 7:15 pm Post subject: | |
|
|
|
| Having both options would definitely be nice. It would allow the user to choose which thing they want to be "perfect." How does bsnes work currently, in terms of this stuff? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 30, 2007 9:53 pm Post subject: | |
|
|
|
| It
uses the audio synchronization (audio is not resampled at all, but
plays back at 32000hz instead of 32040hz due to sound card limitations
-- cheap cards probably resample anyway to 44050hz or 48000hz
internally), but the triple buffering on the video doesn't work, so the
video shears badly. It gets worse and worse as your refresh rate
lessens. At 60hz (the limit on my new monitor), it's almost unbearable. Last edited by byuu on Tue Jan 30, 2007 9:54 pm; edited 1 time in total |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Jan 30, 2007 9:53 pm Post subject: | |
|
|
|
| would a tool Like Reclock be of any help in this case? Its made for syncing audio and video to monitors, fixes a lot of problems for me on lcd http://reclock.free.fr/ What is it ? The purpose of ReClock is to definitely get rid of jerky playback of AVI and MPEG material on a PC (or a HTPC driving a TV, a flat panel, or a video-projector). It's a DirectShow filter which is loaded in place of the default directsound audio renderer. It provides a new reference clock that is locked to the video card hardware clock, in order to ensure that frames are played at the exact speed of what is expected by the video card vertical sync. It also provides a frame rate adaptator for media files that do not match a multiple of the video card refresh rate (ex: playback of 23,976fps IVTC NTSC on a PAL TV). The combination of the two will give you the true experience of smooth playback with your PC. Finally it is an audio renderer with hardware or software rate adaptation in real-time, multi-channel audio, audio timestretching (pal speedup compensation) and dynamic range compression capabilities. For a full description of ReClock, please read carefully the README file in the distribution. There is also a little FAQ at the bottom of the page that answers common questions. You can also visit the forums here to meet other users. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Jan 30, 2007 10:34 pm Post subject: | |||
|
|
|||
|
Thank you for the emphasis. It makes the paragraph much easier to read :P No, doesn't look helpful. But thanks anyway. Ok, I worked this out on paper. My idea is to keep a 3-stage ring buffer. Call them r0, r1, r2. The size of each ring will be determined at startup, and will be constant. We will call the size of each stage l. Latency of sound will be 3l samples. We also create a temporary ring, called rt. rt will be special in that it resides in system memory and is at least 8l in size. Now, start playback at r0. Run emulation and write all samples into rt. When playback reaches r1, we take the data in rt and perform a point interpolation to fit rt into r2, regardless of the size of rt. rt can be bigger or smaller than r2 (or l), it doesn't matter. However, it's paramount that resampling the audio is guaranteed to be much faster than it takes to play back one block. This should not be a problem at all. Now, after resampling rt into r2, we clear out rt (reset the write counter position to sample #0). During this resampling phase, and for a while after, r1 will be playing. r1 should already contain valid sound data, just as r0 will. Finally, advance the ring buffer by one internally. Emulation now continues. Samples get written into rt again, until r2 is reached. Once this happens, rt is point interpolated to fit into r0, and we repeat. Finally, video synchronization works by either setting a high performance interrupt to keep testing the playback position of audio so that the video card wait-for-vblank doesn't allow the audio playback to pass two rings. That, or use the historically more difficult approach of manually polling the video card to determine vblank edge, and draw at the start of this. Lock emulation until vblank edge is reached to ensure 60fps video output. Unfortunately, the above will not work with libao/Linux due to it's much more simplistic design. It automatically freezes your application when you fill the audio buffer, so I cannot sync to video without audio failing to work. Also, I'll admit that point interpolation is the worst case resampling method for audio, but it should work for the immediate time being. I guess we'll find out how well it works when I get the code in, and then if it's bad enough we can work on adding additional filters.
Don't laugh. If you want to do better, feel free :P |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Jan 31, 2007 12:01 am Post subject: | |||
|
|
|||
Triple buffering has always worked for me in bsnes (no video tears/shearing). Do you mean it doesn't work anymore caused by recent change? (sorry if I don't know what I'm talking about, just asking) |
|||
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Jan 31, 2007 1:31 am Post subject: | |
|
|
|
| Regarding
Star Ocean, neviksti made a decompressed graphics patch for it to play
on a copier. I recall people saying that it ran fine with the Dejap
patch except for one place late in the game with garbled graphics
because the graphics for that part weren't decompressed right. If that is correct, then yes it works fine on a real SNES... Or perhaps neviksti modded the Dejap patch to fix bugs, I don't remember. Anyone still have his Star Ocean patch? _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 31, 2007 1:31 am Post subject: | |
|
|
|
| I
was messing around with triple buffering tonight. From what I could
see, it completely eliminated tearing @60hz and 75hz on my CRT. Chrono
Trigger was a good test, to see the pendulum breaking up with TB off
and not breaking up with TB on. The sound, of course, crackled
throughout in windowed modes. In fullscreen, TB appeared to work okay
on everything above 60hz. At 60hz, the sound crackled. Weird... can
anyone confirm these results? You mentioned resampling the audio before, byuu. I was just going to wait to see it implemented. It sounds like a good tradeoff to get triple buffering working without crackling the audio. Something tells me that it won't be humanly possible to detect the difference. I'll try anyway, of course |
|
Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
| Posted: Wed Jan 31, 2007 3:17 am Post subject: | |
|
|
|
| Aren't
headers just for copiers anyway? So why not have auto IPS patching work
for ROMs which don't have a header? A nice example would be Bahamut
Lagoon, the DeJap IPS for it (both the emulator and copier versions)
automatically patch in ZSNES only if it has a header... I don't see the
point to that. As for the vsync and triple buffering... that's bad to hear, it's kind of essential for a clear view. At 1024x768 (which I think is the most common resolution used these days) the shearing becomes horrible without vsync. I'm interested in knowing why vsync in bsnes is broken beyond repair, can you explain a bit? You say you will bsnes will never have save states, what's the reason for this? Also you didn't mention whether or not bsnes will ever have filters such as 2xSaI. I was reading over you wrote about having either having audio or video sync... how is it that ZSNES seems to sync both so well? |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Jan 31, 2007 3:40 am Post subject: | |||||||
|
|
|||||||
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||||||
Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
| Posted: Wed Jan 31, 2007 3:46 am Post subject: | |||||
|
|
|||||
Yes I use 2xSaI whenever possible. ScaleXx becomes all chunky in fullscreen resolutions and seems to take more resources than 2xSaI so SaI would probably be better for those with older computers. As for regular interpolation... it really doesn't filter much at all, the only thing it could be good for is to have a basic filter on extremely old computers. Last edited by Cyrus on Wed Jan 31, 2007 3:51 am; edited 1 time in total |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 31, 2007 3:49 am Post subject: | |||
|
|
|||
The answer to savestates is on the first post of this thread. A more elaborate answer is on byuu's website.
|
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 31, 2007 4:00 am Post subject: | |||
|
|
|||
Personally, I don't know how noticable a 1 frame drop in 4000 is either, so I can't really fault zsnes for dropping these weird remainders if they do. Sry for the dbl post, hit the wrong button. |
|||
Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
| Posted: Wed Jan 31, 2007 4:15 am Post subject: | |||||||
|
|
|||||||
I tested it (though my monitor is an LCD) @60Hz and 75Hz in fullscreen (1024x768), with and without triple buffering and in all 4 cases there was horrible crackling.
Ah I see. Well that's as good as an answer for such a thing can get. Edit: Typo fixed. Last edited by Cyrus on Wed Jan 31, 2007 6:01 am; edited 1 time in total |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 31, 2007 5:19 am Post subject: | |||
|
|
|||
Alright, I'm in a semi-good mood.
This one uses the old win32 interface, and adds a new feature I'd like people with sound troubles to try out. The config file now contains "audio.latency". Don't mess with "audio.frequency", it won't do you any good and gets overridden by the speed regulation settings for now. The audio.latency is a precise measurement of the millisecond delay between sound being output by a real SNES and hearing that same sound in bsnes. It takes into account the current playback frequency, as well as the three-ring buffering system used by bsnes' audio system. Formula: sample_latency = CURRENT_playback_frequency / 1000 * config_file_latency * 3 (so 32khz + 75ms latency means each ring buffer is 800 samples long). The new formula should make latency sound better (it's consistent now) on fast / slow emulation speed throttling settings as well. I also cut out the fourth ring, since it was redundant. This should make bsnes appear ~25% more responsive to sound with the same buffer latency. As a result, I increased the latency to 75ms (it was at ~45 before). I'd like to know what the lowest good value is that works on 95% of sound cards, so I can use that. I'll let people with cheap sound cards increase their latency setting manually (eventually it will be an option in the GUI). NOTE: this version does nothing for triple buffering/vsync/whatever. You must disable triple buffering to try out the latency settings. This version is strictly to test audio playback support. I also added in my audio point resampler. Good god, it sounds terrible. Regardless of the latency setting (either really high or really low), the pitch difference between each audio ring is extremely noticeable. The code is there now in src/ui/audio/dsound.cpp : AudioDS::run_videosync(), if anyone would like to take a look. I'll hold my breath ;) ----- Comparisons against ZSNES at this point are rather silly. Aside from much more flexible timings, it probably has a nice audio resampler, which I don't. If I faked CPU/SMP clock timings, I could get the SNES spitting out 60 frames a second and 32khz audio a second. I'm not going to do that, so I have to figure out how to resample the two. All of my attempts at resampling video and audio have both failed miserably to date. I really only need one of those to work to get smooth video+audio, but both would be nice so the user can decide what's more important to them. I don't care to add 2xSaI. I'm planning on redoing the filter stuff soon to support 32-bit output for Xv, so if someone wants to add 2xSaI support to bsnes after that, I'll add it in. Otherwise, HQ2x is superior and Scale2x looks about the same, yet is way faster. Regarding the IPS thing, exactly. As I said, IPS is a bad format. You can't tell if you need to patch against a headered or unheadered ROM unless you read the documentation that fuckheads like Cowering remove in their ROM sets ("at least it's already prepatched"), or try patching twice to see which one works. UPS will eliminate both of these problems. Readmes will be included inside the patches, and UPS will work regardless if your ROM has a header or not. It will also be reversible. It'll be better in every regard over IPS, so I have no reason to support IPS. Lastly, I don't have any intention of working on fixing DeJap's patch, regardless of where the problem is, as I have no way to run the game on my copier. Maybe when and if the last two serious bugs (Uniracers and Koushien 2) get fixed, I'll take a look at it then. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Jan 31, 2007 6:54 am Post subject: | |
|
|
|
| The resampling method used in X-fi cards and windows Vista is near lossless (like 99% lossless), i wonder if vista automagically fixes the crackling sound due to the new audio engine. | |
Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
| Posted: Wed Jan 31, 2007 9:03 am Post subject: | |||
|
|
|||
I'll give this a shot sometime in the near future (since I have to format anyway) and post my results. |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Jan 31, 2007 1:23 pm Post subject: | |||||||
|
|
|||||||
|
Did some testing with 0.19 wip9... Tested with Final Fanatsy II (U) and Crono Trigger (U)
bsnes settings: Full screen @ 60hz triple buffering On and Off (see below) |||| NTSC filter scanline enable |||| hardware filter: bilinear |||| Multiplier: 2x |||| Correct aspect ratio enable |||Resolution 640 x 480 ||||Refresh Rate 60 Frameskip = 4 (sorry, my PC 's not fast enough to get 60 with no frameskip) << 60 fps - (12frames) >> Sound latency results(edit: with triplebuffering on):
edit:sigh...Just noticed your NOTE...sorry. I'll test without triplebuffering right now Sound latency results without TripleB:
edit 543: Lowest good setting with zero cracking for me is 65ms. But that's pushing it I guess. Considering I get no tearing PLUS no cracking at 75ms I consider these results EXCELLENT... byuu, are you sure it's not something with your PC/ drivers that's messing up? I'm telling you, these are smooth results (granted, since I can't get 60fps with 0 frameskip regardless if I select any filters, I don't know if the results would be the same without frameskip) Personally, I wouldn't really mind the occasional skip in video caused by the 60.09 Snes framerate thing. edit: Needless to say the classically problematic Square sound efftects sound extremely close to the real thing afaict. edit 542: Sorry, my post is a mess... |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 31, 2007 4:38 pm Post subject: | |
|
|
|
| Sound Card: EgoSys Juli@ CPU: Core 2 Duo E6300 XP Fully updated Okay, so my card has a variety of its own latency "sample" settings. It goes 48, 64, 128, 256, etc... The 256 is the default and bsnes was the only program that had sound issues with that setting. Changing to 48 sample fixed this in older versions. At my card's 256 setting, I can go down to 60ms without crackling. This appears to be the reason why previous bsnes versions crackled, because they were at 45ms. At my card's 48 setting, I can go down to 45ms without crackling. 44ms and below crackles, I'm not kidding. I must have been just making the cut back there! Also, triple buffering appears to be benefiting from a higher latency. Provided that I set my latency high enough (75ms has been sufficient for me, personally), it no longer crackles in any scenario, windowed or fullscreen. Last edited by FitzRoy on Thu Feb 01, 2007 1:41 am; edited 1 time in total |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Jan 31, 2007 5:06 pm Post subject: | |
|
|
|
| I'll check if I can found similar latency settings with my soundcard. edit: None that I can see. If I'm not mistaken my sound card was plug-and-play supported by XP meaning no installation CD that came with it were necessary. If there's a way to change the setting in WindowsXP I don't know where is it. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 31, 2007 5:31 pm Post subject: | |
|
|
|
| Also
note that you can raise frameskipping to 9 if you need to get 60fps, it
won't affect this audio test at all, but should be less taxing on your
CPU. 45ms in the old version is also an estimate. It actually varied based on frequency setting (speed setting adjusts frequency), and was basically "buffer = however many samples are generated in one frame of video". So 32000 / 60 = 533.333 sample buffer. At default speed, 32000hz, that should be: (32000 / 1000) * (l / 3) = 533.333 32 * l / 3 = 533.333 l * 10.667 = 533.333 l = 533.333 / 10.667 l = ~50ms The true latency was actually 25% higher than this (~62ms), but the actual samples that could fit into one ring buffer went from 533 to 800 with a latency setting of 75 in the current WIP, which is probably why it's working better for everyone. So go with ~75ms as the default, then? Seems rather conservative so far, but I guess I'll wait for a few more reports. I can't really cut down my current ring buffer anymore than 3. I might be able to with audio resampling, but not for unmodified audio output. The problem is the sample data copy to the sound card happens when emulation fills the sample buffer, not when the sound card reaches a current point, so the sound card could very well start reading the current ring being written to during the data transfer and cause some horrible sound problems. As it stands, I detect the current ring being played, and skip two forward, so that even if the current ring finishes during the sound data transfer, I have one more ring as a buffer while the sound transfer from emulation/RAM -> sound card occurs. But man, I don't know how the hell I'm going to pull off audio resampling. I've read some posts by some absolute DSP masters ( http://www.dsprelated.com/showmessage/42289/1.php ) and even they don't have any idea how this could be done in software without dedicated clocks (I can detect edges of the S-DSP emulated clock; that's easy, whenever a new audio sample is generated); but the problem is that due to emulation, it isn't consistent. The S-DSP may output ~32,040 samples a second, but that doesn't mean you get exactly one sample every 1/32040th of a second. The reality is that it depends on a million variables: how complex the video display is (PPU overhead), what other applications are running and consuming CPU time, etc etc. So the number of generated audio samples in a given timeslice varies wildly. And then the PC sample rate clock is -somewhat- detectable by using DirectSound::GetCurrentPosition (which calling 32,000 times a second cuts the speed of bsnes *in half*, the hell is it doing to be so slow?? I can reduce the calls to it by testing every n samples generated, but that will create even greater variations between two sample rings/blocks due to rounding). In truth, I really have no idea how I can pull off audio resampling, aside from faking the emulation clock speeds. But it would appear that even a miss of ~1-3 samples will cause very audible clicking and popping sounds, so my only solution would be to fake S-DSP timing and force it to generate however many samples I need when it really shouldn't. I believe this is what ZSNES/SNES9x do to generate their audio, but the downside is that the S-SMP can then poll the S-DSP registers and detect this odd behavior. It can also distort delicate timers / sound effects. Not sure what to do, and given how amazingly specialized my case is, there doesn't appear to be any real documentation or examples out there. And before anyone offers, resampling libraries do me no good. The big problem here is that my audio stream is infinite and asynchronous. Resampling libraries would be great if I were just resampling a wave file on a hard disk, or if my input/output sample rate clocks were constant, rather than variable (only the input is variable, but still). I don't really have anyone to ask for help on this. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Jan 31, 2007 5:53 pm Post subject: | |||||
|
|
|||||
Yes, I think the requirements to get 60fps at 9 frameskip aren't that high...Like 1.2-1.5ghz maybe less.
Following Fitzroy's post I guess the reason why I only get crackling bellow 65-64ms is because my soundcard sample latency thing is set to...64. That would make sense actually. Yeah 75ms is a bit conservative but better to be slightly too much conservative than not enough I suppose. Just one thing no matter what you choose for now: Please keep the ability to manually change the latency in the .cfg file (unless you see good reasons for not keeping it in the future, such as changes that would render the option useless) |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 31, 2007 6:21 pm Post subject: | |
|
|
|
| Ah,
I have no reason to remove the setting. I may even add it into the GUI
if enough people need to change it. I typically like to "hide" lesser
used options like this, however. Good to keep the UI as uncluttered as
possible. Just note that the setting will have no effect on AudioAO (Linux / FreeBSD audio output driver), as libao doesn't let you control this (at least, not to my knowledge). |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Jan 31, 2007 6:31 pm Post subject: | |||
|
|
|||
Linux, FreeBSD, Solaris, Mac OS X, OpenBSD, NetBSD, IRIX, KDE, GNOME, and possibly others too. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 31, 2007 6:36 pm Post subject: | |
|
|
|
| KDE and GNOME have their own kernels now? Why would that not surprise me? :P Mmmm ... ls /dev khdd0 khdd1 kmouse kkeyboard kpci kisa kdsp ... That's neat that it works on Macs, too. Now if only it were more powerful of a library. But, that's the problem with library encapsulations. You have to aim for the lowest common denominator, which usually means minimalist features. The fact that libao automatically freezes your program when the audio buffer fills up means that ports that use it will never be able to have 100% fluid video output :( |
|
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Jan 31, 2007 6:51 pm Post subject: | |||||
|
|
|||||
They have their own sound systems. So even if libao doesn't support the Kernel's system if KDE or GNOME is there and they support it, you're still good.
Look at ZSNES v1.51, it when using libao can fast foward despite it pausing, or frame skip as needed, you'll just get choppy audio. _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 31, 2007 7:15 pm Post subject: | |
|
|
|
| I'd rather not read ZSNES' source code, and shall assume you're merely skipping/duplicating audio samples? :P | |
ZSNES Developer
Joined: 27 Jul 2004
Posts: 4328
| Posted: Wed Jan 31, 2007 7:47 pm Post subject: | |
|
|
|
| Skip as needed, it's in src/linux/audio.c _________________ May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it. _____________ Insane Coding |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 31, 2007 8:47 pm Post subject: | |
|
|
|
| I'm curious to see more tests, now that we know frameskipping doesn't affect results. If Snark and I have no issues with triple buffering at the new default latency, I question if any resampling is even needed for windows users. What is your card and results, byuu? | |
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Wed Jan 31, 2007 9:26 pm Post subject: | |
|
|
|
| This may be a silly question, but I'd like to help out by testing this on my laptop's crappy onboard SoundMAX chip (and my PC's X-Fi if needed).. Are there any specific games/scenes in games I should test this with? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Jan 31, 2007 9:44 pm Post subject: | |
|
|
|
| Triple buffering + no audio resampling = fail, always :( If it's working now, I have no idea why. It shouldn't. I'll try when I get home, but even if it does work, it's by fluke and not by design. I'll try again with D3D and manual vblank status polling. I'm adding ::tick() functions to audio and video for this purpose, so while the audio sleeps, the video can keep polling the monitor raster position. Though I've done this before, who knows ... maybe with the extra latency it'll work. We can hope. |
|
New Member
Joined: 31 Jan 2007
Posts: 2
Location: London
| Posted: Wed Jan 31, 2007 10:26 pm Post subject: | |||||
|
|
|||||
Just to let you, aep-emu.de are linking to this post. Thought I should let you know as I think you once said you couldn't really afford the bandwidth for more then a few people to download. Dunno if this is still the case, but just to give you a heads-up. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Jan 31, 2007 10:41 pm Post subject: | |||
|
|
|||
Just use Super Mario World or Chrono Trigger. Make sure you've got your frameskip high enough to avoid crackling in the first place, then apply TB off and on while its running. We want to know if your sound becomes crackly with TB on. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 01, 2007 1:52 am Post subject: | |||||
|
|
|||||
I'm used to it, sadly. I posted about this WIP publically so I could get the attention of the regulars here who usually give me feedback. I doubt anyone downloading the WIP from aep-emu will be providing feedback, but if they do, then I thank them in advance. It would be nice if sites linking here anyway could advise that these WIPs are intentionally "crippled" both to save bandwidth and compilation time: eg this WIP will not run ZIP/JMA archives and lacks full optimizations (though not as bad as it used to be since PGO is out of the picture now).
Well, you do at least, so alright :P |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 01, 2007 3:34 am Post subject: | |||
|
|
|||
TB could be working for the first time ever, and you don't care? Blasphemy! Oh well. I can't explain why it works over here and not for the author. If nothing else works, it wouldn't hurt to check your IRQs with msinfo32 to see if it's sharing any. My sound cards have historically hated not having their own IRQs. By the way, where is that donate button? You really shouldn't have to use an SB16... http://www.newegg.com/Product/Product.asp?Item=N82E16829120103 |
|||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Thu Feb 01, 2007 3:55 am Post subject: | |
|
|
|
| Q: What happens if I set the sound frequency and default speed frequency to 32040 Hz? Does bsnes use its crappy built-in resampler in that case,or the resampling is handled by the soundcard/windows resampler? 32040Hz works here and it doesn't sound that bad. Your CRT monitor _can_ emulate a real NTSC refresh rate display. Setting a custom NTSC resolution with a 60.09 Hz refresh is easy with PowerStrip. Having your monitor set to a refresh rate higher than 60Hz that's not a multiple of 60 (such as 85Hz) still gives you less 'jumps' and smoother video with triple buffering. Latency test --------------- 45ms seems very stable _with_ triple buffering - No crackling at all Without TB,it can go as low as 40ms System: AthlonXP 2400+ SB Audigy2 with kX Project drivers XPSP2 Tested various titles of different genres in both fullscreen and windowed modes. I had to use frameskip=1 or 2,cause this WIP is a good deal slower than the 019 release. It would be interesting to do the same test with a WIP using 4 buffers instead of 3 and see the difference in sound latency. P.S. Get at least a dirt-cheap Audigy 2. SB16 is an old dinosaur P.P.S. Emu-France were even quicker with the news |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 01, 2007 8:45 am Post subject: | |||
|
|
|||
If
you modify the speed throttling setting to 32040hz, then your sound
card/hardware will do the resampling. Modifying audio.frequency does
nothing for now.
It wasn't enabled in the last release. But is this better for you? http://byuu.cinnamonpirate.com/temp/audio.txt Point, linear, cosine and cubic filtering are now supported. Ironically, it doesn't seem to matter which you use: bsnes is slow enough so as to make the speed difference virtually non-existant :) I notice that while cubic sounds the best, there's a tiny bit of banding. It's either a bug in my filter, or just the way cubic works (probably the former). Since they all sound virtually identical to me anyway, I'll probably go with the cosine method as the default setting. Cosine and cubic look extremely similar on a graph, but cubic tends to handle sample point edges better since it has four sampling points. I suppose I can add hermite interpolation if you want. I just didn't want to have to add tension and bias controls into the config file. That's getting a bit heavy for the average user. Anyway, what I'm thinking about doing now is based on a suggestion by blargg over at nesdev: combine buffering and resampling to sync to video output. The idea is I start with a base resampling rate: 32040hz->32000hz or something (whatever gives a good ~60fps video rate). Then, I monitor the buffer usage to see how many extra samples or missed samples are occuring, and slightly adjust the resampling rate to compensate and attempt to keep the audio buffer exactly two ring buffers ahead at all times. It should be able to learn a best-case value before any SNES game even begins to play audio, so it should sound good. tepples advises that the perceivable pitch difference for humans is 0.35 percent, so for 32khz, that's ~112 samples/second. I should be able to sync to video and stay within that range fluctuation so that minor pitch changes will not be perceivable. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Feb 01, 2007 9:18 am Post subject: | |
|
|
|
| Does this open source near lossless sample rate conversion tool help? its called SSRC http://shibatch.sourceforge.net/ |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 01, 2007 9:31 am Post subject: | |
|
|
|
| Libraries don't help me. I need algorithms, heh. He doesn't even bother to say what interpolation algorithms he uses :P You're not going to get better than cubic until you start using window-sinc functions and all of that fun trig stuff, and that really begins to become impractical for realtime resampling. Seriously, cubic and cosine sound fine. I didn't notice any distortion, even in Chrono Trigger / FF3. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Feb 01, 2007 10:28 am Post subject: | |||||
|
|
|||||
They're mirroring it now. _________________ savestate editor: vSNES latest public version
|
|||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Thu Feb 01, 2007 4:18 pm Post subject: | |
|
|
|
| Cubic is a big improvement,but I'd go for 6-point hermite. It's the best compromise between speed and resampling quality.It's almost as fast,but sounds better than cubic. I won't need resampling anyway (the kX drivers resampling to 96kHz do a better job),but most of those on-board audio and Creative card (with CT drivers) users will need it. I had this idea before: If I had a dual-core CPU (but no X-Fi),I would've run bsnes on one core and connect the 32040Hz output of bsnes via Jack [mp build] (yes,there's a Windows port too) to a very high-quality resampler running on the second core,so I'd get very high-quality low-latency output. But I see this may be too difficult for the average user,so... Last edited by kick on Thu Feb 01, 2007 6:02 pm; edited 2 times in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 01, 2007 4:43 pm Post subject: | |
|
|
|
| Does resampling occur by default now? In other words, will there be some way to disable it if a user doesn't need it? | |
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Thu Feb 01, 2007 6:59 pm Post subject: | |
|
|
|
| Was going to ask the same question actually. A way to enable/disable it (be it via the .cfg or the UI) woud be welcomed. | |
New Member
Joined: 31 Jan 2007
Posts: 2
Location: London
| Posted: Thu Feb 01, 2007 10:35 pm Post subject: | |||||
|
|
|||||
Joy cookies. That was nice of them.
|
|||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Thu Feb 01, 2007 10:52 pm Post subject: | |
|
|
|
| Extremely
minor (possible) bug to report in 0.19wip9. In Chrono Trigger, at the
beginning of the game during the fair when the "vortex" first appears,
the lowest line where the black area is acting erratically. Possibly caused by the ppu.hack.render_scanline default 512 position. Or it happens on hardware... In either case, it's probably too minor to even bother with but just in case you'd thought it might be significant. edit: playing with the "scanline_default_position" in the cfg seem to affect the "glitchy" bottom line behavior, so it's probably related to that. *disregard* |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 02, 2007 1:06 am Post subject: | |||||||
|
|
|||||||
I really wish I knew what you guys were hearing. The only one that sounds different from the others is point, and that's obvious why. Linear and cubic sound identical to me. I think I should make samples for each filter, not label them and post them for comparison. See which one people find best via blind audio tests against the original. If you have an algorithm for 6-point hermite I can add it. Do note that 6-point is going to have even sharper resampled buffer edges due to the way interpolation works. I don't currently have a good method for pulling in previous buffer samples for the left and future buffer samples for padding the right, but I suppose I'll have to figure something out as soon I'll be asked to add 64-point Lagrange 3D spatial hermite filtering to 7.1 channels :(
It will by default, and yes you can turn it off. But triple buffering will no longer work without crackling audio if you turn it off.
Yep, I'm both afraid of the massive workload to writing a dot-based renderer, as well as seriously not looking forward to quadripling bsnes' system requirements ... sorry about that. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 02, 2007 1:43 am Post subject: | |||
|
|
|||
Well, hopefully that's the last sacrifice to the linux gods.
I have confidence in the resampling strategy, though. I just learned
that my sound card supports linux through something called ALSA
ice1724, whatever the hell that is. Something about modules and
compiling the kernel... Maybe one day when I'm feeling up to it, I'll
install linux on my second HD and find out why no one uses it.
|
|||
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Fri Feb 02, 2007 3:26 am Post subject: | |||||
|
|
|||||
Linux is really quite nice; just find the right distribution for you.
|
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Feb 03, 2007 1:10 pm Post subject: | |||||
|
|
|||||
|
Ok, I tried my best to add the audio synchronization method (drop video frames) yet again, and once again failed completely. The below WIP is completely unusuable as it stands, so please don't link to it, host it anywhere else, or even download it unless you can help with the programming. I'm not going to be able to fix this myself as I've tried countless times over the last two years in vain to fix it.
The included config file is important: it uses the DirectDraw renderer instead of the D3D renderer, and has triple buffering enabled. The relevant code is in src/ui/video/ddraw.cpp and src/ui/audio/dsound.cpp. The most important code is below, but obviously any tests would need the above WIP to build and try out.
What I'm basically doing is: Audio keeps a ring buffer, and waits until the temporary buffer fills up before forcing the emulator to sleep until the audio playback catches up. Every time an audio sample is generated, and every time the emulator sleeps for one millisecond, it gives Video a chance to run. Video has two backbuffers (a poor man's triple buffering, since that doesn't work in windowed mode for DDraw). The PPU renders the entire screen line by line, but it doesn't go from the PPU to the video card until Video::video_lock is called. At this time, the current buffer sets a flag to say it's contents are invalid, then it draws to the frame, then sets a flag saying the current contents are again valid. Finally, it calls the Video tick function to finish. Every time the Video tick function is called from Audio (well over 32,000 times a second, so it should have good precision for detecting vblank edges). First, it will see if any frames have completely rendered. If not, it will give up and return. Next, it will see if "triple buffering" (really a vsync now, but emulates triple buffering at least) is enabled. If so, it will return and do nothing if not in vblank. Otherwise, or if triple buffering is disabled, it will continue. Next, it finds the most recently rendered video frame that was valid and blits that to the screen, and then sets that frame to invalid, so that it is not rendered again (though it wouldn't hurt, it wastes CPU time to blit the same image twice). I've tried even adding in a 1ms interrupt timer to try and help with any emulation code that might be freezing the emulator for over an entire vblank (nothing in bsnes should be that intensive), and this did not help either. Basically, it's like I'm missing an unbelievable amount of frames, like five out of six end up never getting drawn at all, so the video is so choppy it's completely unusable. In reality, only one frame should be dropped every 11 seconds. And when I enable the resampler, that should change to only one frame every 66 seconds. As a side note, I added a four-tap hermite resampler in. It sounds good too, but I have no idea if it's better or worse than cubic. |
|||||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sat Feb 03, 2007 1:36 pm Post subject: | |||||
|
|
|||||
Does it freeze the entire program, or only the responsible thread? Maybe multiple threads could help there. _________________ savestate editor: vSNES latest public version
|
|||||
Randomness
Joined: 28 Jul 2004
Posts: 2313
Location: Britain
| Posted: Sun Feb 04, 2007 12:04 am Post subject: | |||
|
|
|||
Found a potential bug with MKII:
Character sprites glitch up in-game and in the Character Select. This happens in bsnes v0.019 and the wips. Note: I also tested MK1, MK3 and UMK3, and they seem to be unaffected by this. Just affects MK2. _________________ ZSNES Documentation Project | bsnes Fan | ZSNES Facebook Group |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 04, 2007 12:52 am Post subject: | |
|
|
|
| My first assumption is that it's related to the hdma bus sync stuff that messes up BoF2 German. Will test the wip tomorrow night. This SC420 dell server I got my mom for cheap is great for basic apps, but the castrated E7221 onboard video can't do any direct3d and has limited directdraw. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Sun Feb 04, 2007 1:28 am Post subject: | |||
|
|
|||
Confirmed here as well. Happens with 1.1 and 1.0. Doesn't affect (E) |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 04, 2007 7:30 am Post subject: | |
|
|
|
| I give up. Video and audio synchronization at the same time is impossible for me to implement. For audio synchronization, I've hooked polling vblank status as much as possible, I had something like 40,000 vblank tests per second as well as zero Sleep() commands. The result is that I still miss 20% of all vblank periods entirely. For video synchronization, it doesn't matter how close I get each buffer, even a difference of ten samples with a hermite resampler results in unbelievably noticeable pitch distortion. A lowpass filter only makes the situation worse as the rounding error eventually builds up until it overflows, resulting in an even more vastly different pitch rate for that sample block. Neither are possible, so I'm not going to keep wasting my time anymore. I've removed all traces of my attempts at doing this and I will not be trying this again. If you want perfect audio, expect video tearing. If you want perfect video, you'd better mute the audio. Don't like it? Use ZSNES. I don't know how they pull it off, and I really don't care anymore. End of topic. As for Mortal Kombat II, the problem began between v0.018 wip14 and wip16. The only change there was the total rewrite of IRQs. Motherfucking hell if I'm touching IRQs again. Mortal Kombat II, fuck you. You're staying broken forever, unless someone else fixes you (like triple buffering, hahahahahah). Let's not kid ourselves: even if I did fix this bug, it would just break three other games, guaranteed. Why bother anymore? I no longer have the motivation or passion to continue to put myself through this physical and emotional pain to work on these issues in bsnes anymore. bsnes has become nothing but a headache for the last year now. Either someone else can join up with me to work on this stuff, or we can consider v0.018 the final version of bsnes for public use, and I'll take development in a personal, private direction once again. As of now, I'm refactoring and cleaning up the code. I've been chasing down so many bugs and doing so many things at once to make everyone happy that my code is now almost a complete trainwreck. I scrapped the D3D-specific scanline renderer and will be rewriting a software renderer for that purpose. I also removed the D3D-vertex-specific pause gamma adjustment, video profiles, D3D-specific screenshot capturing, and DD/D3D fullscreen support (I'll still support pseudo-fullscreen mode in the future). I'm going to continue cleaning up and refactoring my codebase. Filters are going to be moved out of the core of the emulator, along with other things that don't belong there. I'll continue to scrap wanton features that are better suited for ZSNES and clutter up my code. Sorry everyone, I'm going to make working on this emulator fun again, even if it kills my userbase and my original project goals. |
|
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Sun Feb 04, 2007 7:39 am Post subject: | |||||||||||
|
|
|||||||||||
Sorry to hear that.
I've noticed MKII is uber sensitive to IRQ changes when pf made changed to the core recently. I can't really blame you for that.
Take a deep breath and exhale. Lots of things are stressful.. you should never make your hobby one of those things.
Sorry to hear this as well.
That's a tough pill to swallow man. _________________ FF4 research never ends for me. |
|||||||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Sun Feb 04, 2007 7:58 am Post subject: | |||||
|
|
|||||
As was said before, I do get scratch-free audio + plus no tearing (provided the latency is set to something above 64ms), as do Fitzroy so unless I simply don't understand what is the real problematic issue here, I don't actually see the need to rewrote those aspects of bsnes. If it work for most people (whether by design or accident is not really that important I would say) then isn't that good enough?
Kind of a downer but if you really think this is the best or only way to keep bsnes alive and for you to have the motivation to keep working on it then I won't complain. Fwiw, I personally consider (from a user pov) the latest stable 0.019wip9 version to be by far the most usable Snes emulator around. The only thing that's not perfect for me is I have to set the frameskip to 2 or 3 to achieve 60fps...but that's more an issue of my CPU than the program. Other than that, aside from special chips games it does play 99.xx% of games wonderfully. Of course, I'd still love to see (regardless of speed) a dot-based renderer and any improvement to the core Snes emulation in the future. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 04, 2007 8:38 am Post subject: | |
|
|
|
| If
you're using frameskipping, then you aren't getting clear scrolling
video. Anyway, if people out there can manage to rig bsnes to get
perfect video and audio, then that's great. But it doesn't work on most
PCs, so there's no sense stating I support something I can't. I really don't have the motivation right now to write a dot-based PPU renderer. Maybe that will change in the future, maybe not. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Sun Feb 04, 2007 9:00 am Post subject: | |||||
|
|
|||||
Allright, so anyone with a PC fast enough, I'd be curious to hear the results. edit: Still, I doubt the results would vary for me if I had a 3.2ghz dual core and thus able to achieve 60fps with 0fskp. Anyhow, I don't want to come off as annoying, just saying what has been my experience regarding this.
|
|||||
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Sun Feb 04, 2007 9:23 am Post subject: | |||||||
|
|
|||||||
|
You
shoudn't use triple buffering and poll for vblank. You should use a
call that waits for vblank. Triple buffering is not meant to be used as
a way of syncronizing to the refresh rate. This is pretty much how I do it:
If you use triple buffering you'll get no tearing, but some frames will last longer than other, making it choppy. This example uses triple buffering, or no vblank blitting at all since triple buffering is transparent:
If you only have access to fill the sound system's output buffer in one big go, you should preferably use a callback function in a different thread that fills up from a large intermediate buffer that you fill samples into each frame. The number of samples that you fill the intermediate buffer with, needs to be dynamically determined based on how many samples are left in it after the sound system has taken it's bite out of it. This can be quite tricky. EDITed for saner placement of resample-calls Last edited by sinamas on Sun Feb 04, 2007 10:13 am; edited 1 time in total |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 04, 2007 9:54 am Post subject: | |
|
|
|
| I
shouldn't poll for vblank, period. I can't possibly poll frequently
enough to reliably detect vblank edges no matter how much I try. It's
not possible. As I've stated above at least twice, I've already tried resampling the audio based on how many samples were generated during one video frame. It sounds absolutely horrible because the number of samples generated per frame varies wildly, and the constant resampling to different amounts causes horrible pitch distortion. Your first example won't work for this reason. As for your second example, if triple buffering is locking (eg nothing happens and your program freezes until vblank), then the audio buffers will empty while the video API freezes my app waiting on vblank. If I manage to buffer audio enough to avoid that, it still won't matter anyway, as once again, I cannot simply resample audio from arbitrary amounts every video frame. It simply won't work. I could solve this problem if PCs supported a feature twenty-year-old Nintendos supported: NMI. Simply tell DD/D3D to call a function when vblank is first hit, and my problems would be solved. But then, we can't expect modern computers to have caught up to the functionality of the NES, can we? |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 04, 2007 10:04 am Post subject: | |||
|
|
|||
LOL |
|||
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Sun Feb 04, 2007 10:08 am Post subject: | |
|
|
|
| Triple
buffering should never lock, that's the whole point of triple
buffering. As long as your audio buffers are large enough they
shouldn't empty while waiting for vblank anyway (it's only like 17 ms). The number of samples generated internally by bsnes shouldn't vary, since it should emulate the same number of cycles each frame. The number of samples played back by the sound system shouldn't vary much, since each frame should last as long as the previous one. My previous placement of the resample calls wasn't very well thought through, and I've edited my previous post for saner placement. Anyway this works for me, so it should be possible to do for bsnes too afaics. If the sound system is unable to report accurate playback position (as you said the number of samples varies too much), you could use the big intermediate buffer strategy anyway, but it can get really tricky to calculate how many samples to output each frame. Last edited by sinamas on Sun Feb 04, 2007 10:27 am; edited 1 time in total |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 04, 2007 10:26 am Post subject: | |||||
|
|
|||||
You'd think, wouldn't you? Unfortunately, that's not the case. Using D3D with triple buffering (two backbuffers) still causes lockng when calling Present(). DirectDraw does the same thing and locks with Flip(), and that is further limited to only working in fullscreen mode.
They do vary. Greatly, in fact. It's due to my emulation model. I don't run the CPU and SMP in perfect parity. If the CPU doesn't read from the SMP, then there's no reason to switch cooperative threads and run the SMP. I guess I can take a rather large speed hit to keep the two more in parity and see if it helps. But I doubt it. Again, even tiny resampling amounts (~10 samples/25ms buffer) cause serious problems for audio playback. |
|||||
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Sun Feb 04, 2007 10:29 am Post subject: | |
|
|
|
| Is there any reason why you can't just force a sync at the end of each frame? If your emulator doesn't generate the same number of samples internally each frame, then it sounds like we're pretty screwed indeed. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 04, 2007 10:41 am Post subject: | |
|
|
|
| For
one, emulating up to 1/8th of a second on either the CPU or the SMP is
quite processor-intensive, and easily enough to miss any narrow cutoff
windows I have for video or audio buffering. You made a good point, I had forgotten about my libco optimization before. In that case, I will try disabling the out-of-order execution entirely (and take the ~15% speed hit) and try one last time to see if it helps any. Hopefully I can still get 60fps on my PC to even test it :( That will give us a much closer number for samples/frame generated, but it still won't be perfect. Hopefully we can get it within the magic 1-5 samples/difference per buffer, so that audio resampling won't be detectable. |
|
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Sun Feb 04, 2007 10:49 am Post subject: | |
|
|
|
| I'm
possibly not getting something here, but a context switch (or hundred)
each 16 ms shouldn't really cost you much in itself. I mean, you'll
have to do the emulation of it sooner or later anyway, and if the
context switch isn't the overhead, then what is? If anything syncing
cothreads each frame should make the actual system time used for
emulating each frame _more_ consistent, since you're never bulking up a
large amount of stuff that needs to be done in some other frame. As a side note, the only way to get perfectly smooth video is to sync completely to the refresh rate. This either means approximating the speed of the original platform, or resampling the video output to the refresh rate (doing weighed blending between frames, causing blurring in motion and latency depending on the number of frames you blend between). If you don't sync to the refresh rate, you're basically doing nearest point interpolation. If directx blocks when using triple buffering then directx is broken. It should not be necessary to poll for vblank. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Sun Feb 04, 2007 5:11 pm Post subject: | |||
|
|
|||
Sounds good to me. Anything that keeps you working on bsnes makes me happy. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 04, 2007 11:35 pm Post subject: | |||||||
|
|
|||||||
I average about 20,000 context switches per second. That number would rise to 200,000 or so per second without my speedup trick.
I'd basically be doing the former. I don't mind always running at 60hz rather than 60.09hz. Nobody can tell the difference. As it stands, syncing to audio at 32000hz instead of 32040hz already slows down emulation all the same anyway.
Thanks. Who knows, maybe I'll get over this hangup if I give myself enough time off. |
|||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Feb 05, 2007 2:06 am Post subject: | |||||||
|
|
|||||||
Byuu, I have the slowest core 2 duo and I can tell you that WIP9 worked wonders without frameskipping. It worked for 3/4 of the users who tested with it. From that information alone, it probably DOES work on most PCs. You even said it yourself that frameskipping has nothing to do with whether the TB code is working or not. I have to assume that that is the best implementation to go with. Sure, it won't work on linux, but neither did anything else, and that's only 3% of users. The way I see it, if a linux user is complaining about something like TB when they are lucky just to have a port, then that's a little strange to me. Unless you're converting to linux yourself, then I get it. There's no question that an author should be able to enjoy his own emulator. However, it wouldn't make sense if you're blaming good code for something that is the fault of your sound drivers. |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Feb 05, 2007 3:29 am Post subject: | |
|
|
|
| Ok, I had to track down a truly evil bug to disable the out-of-order execution speedup. The CPU, during reset(), was calling add_clocks(186) to sync to the delay seen on real systems when resetting the console. Without the out-of-order execution, this caused the SMP to start running before it's reset() function was called for the first time. Because SMP::reset() was not called, the SMP clock ratio was never set, and so the SMP attempted to execute an opcode to catch up to the CPU, and then continually executed when all clock cycle counts were zero, so the emulator froze hard. I'm now rethinking how to perform CPU reset timing emulation, but in the meantime I have a quick workaround. Oh, and I hereby declare 4576849921 as "byuu's constant". Have fun figuring out the meaning. Disabling out-of-order execution results in a frameloss from 82.5fps to 77.5fps, or ~6%, due to having to call libco::co_switch hundreds of thousands of extra times per second. Not as bad as I was thinking. This is all overhead of libco, which will be worse on 64-bit processors, especially on win64 with Microsoft's awful ABI. It didn't help much anyway. With an audio buffer of 750ms, combined with hermite resampling, I was able to synchronize to the video refresh, getting the following (generated samples) -> (needed samples) ratio: 8000 -> 8000 7952 -> 8000 7984 -> 8000 7968 -> 8000 7968 -> 8000 7952 -> 8000 That's with a 16-sample lowpass filter. The pitch difference is virtually inaudible to my ears. However, that 750ms latency is terrible. Anything lower and the sound becomes very noticeably distorted. To give you an idea, you can have Link swing his sword twice, and then stop. And only after you stop will you hear the first swing. Oh well. |
|
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Mon Feb 05, 2007 7:34 am Post subject: | |||||||||
|
|
|||||||||
Which is why I'm asking why you can't just keep using your speed trick, but force a sync between cothreads at the end of every frame, before resampling (meaning every 16/17 ms). If you reread my last post, my argument should be pretty clear. Many emulators are coded in a way that only syncs parts when needed. I don't see what's so different about bsnes that you can't just sync up before resampling like I do.
Are you buffering up 750 ms worth of samples internally to get more uniform resampling ratios? Could this be solved by forcing a sync before resampling? I'd think the number of samples between frames shouldn't have to vary by more than one or two (because of an uneven ratio with the frame rate). If the 750 ms buffer is the external buffer, then I don't see why that helps anything.
A 33-bit number, ouch! |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Feb 05, 2007 11:00 pm Post subject: | |||||
|
|
|||||
Just wanted to note that this does affect (E) as well. It does for me, at least. We had a good list of IRQ sensitive games, too. Apparently the SNES IRQ system is insane.
|
|||||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Tue Feb 06, 2007 12:39 am Post subject: | |
|
|
|
| do
whatever you need to do byuu, you're always learning more and that is
important. I'm sure as it becomes more common and affordable to have
faster processors, emulators will become more accurate. and all you
emuwizards will know far more by then. _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Feb 06, 2007 2:41 am Post subject: | |||||||||||
|
|
|||||||||||
Weird. I've double tested...no character' sprite glitch like the one in the (U) version. I'll post the NSRT info: NSRT v3.3 - Nach's SNES ROM Tools
Tested with 0.019.09 bsnes
|
|||||||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Feb 06, 2007 2:54 am Post subject: | |||
|
|
|||
Does this change the internal framerate of the emulation? Or does this only change the external video output and doesn't affect the internal workings of the emulation (an analogy would be an HQX filter running on top of emulation)? Bluntly put: could this be technically considered a hack? Btw it IS possible to run a monitor at 60.09 using Powerstrip, but I think you mentionned that the actual framerate of the Snes actually may varies during gameplay. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Feb 06, 2007 3:14 am Post subject: | |
|
|
|
| It
may not bug out as bad on the character select screen, but you need to
go further than that. The gfx corrupts during gameplay just like the
other regions. Last edited by FitzRoy on Tue Feb 06, 2007 3:37 am; edited 2 times in total |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Feb 06, 2007 3:33 am Post subject: | |||
|
|
|||
Well, I tested during gameplay too (just for half a minute though) and didn't see any garbage/corrupted gfx. I'll play longer to see if I can see anything. edit: My bad...it does crap out... Just seem less severe than (U). Guess it depends of the stage and character because it really didn't when I first tested (or it's more or less pseudo-random) |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 12:39 am Post subject: | |||
|
|
|||
Thank
you again DMV27 for looking into this in the past for me. I'm sorry I
took so long to get to it, but your notes were (and are) very helpful
to me.
Since I'm not touching Mortal Kombat II with a ten foot pole, I figured I'd look at this issue again. Perhaps even learn some S-DSP stuff this time. So ok, anomie believes that (most likely) writes to EDL are cached. The echo buffer continues to increment until the value wraps. At that time, the echo buffer size is reloaded from EDL. TRAC, however, believes that EDL's write takes effect immediately. In light of observations with Koushien 2, I agree with his synopsis that simplicity is key. Caching a value and reloading from that would complicate the S-DSP design slightly, and doesn't really do a whole lot of good. Given no definitive tests have been done, nor can be at this time due to there being nobody left in the scene who can do these sorts of tests ... I'm going to go with TRAC's opinion. Myself and TRAC continue to have the same problem with Koushien 2 crashing though, of course. But now, the matter becomes much simpler. Koushien 2 sets EDL to zero (meaning the echo buffer becomes only 1-sample long), and then updates ESA to the near the of SPCRAM. Lastly, it disables FLG. Now the problem is, a sample sometimes gets generated here. With anomie's approach, the sample would be written, and indeed samples would continue to be written, well past where the programmer wanted them to go. In fact, it keeps going until the echo buffer wraps, which is well past wrapping SPCRAM and writing into program code at the start of SPCRAM. TRAC's method does the same, but only one time. After the one write, it would recover. But one write into critical code is quite bad indeed. And sure enough, Koushien 2 can crash in SNEeSe as well. DMV27's idea is that writes to either EDL or ESA reset the write index to zero. I don't believe this would be desirable from a hardware standpoint, as this would mess with the FIR filter which reads from the echo buffer, distorting the pitch. So then, TRAC and I believe that the range test for echo index >= EDL *512*4 happens before writing into SPCRAM. Hence, you set EDL to zero, so the very next time a sample gets generated, it will see that echi index >= EDL, and wrap it to zero. The result is that the echo writes are bound to ESA<<8, and nothing else, immediately after EDL is set to zero. This could very well be incorrect from a hardware standpoint, but without being able to test it, we'll just have to go with it and see what happens. If other games break, we can look at how they work and see why. Gain more info from them and come up with a fix that gets all games working again. Kind of sad, but what can you do? So, I've implemented this, and indeed Koushien 2 now plays fine without crashing. No idea about Toy Story, probably the same since that's a different issue anyway. I refuse to play the game to find out. I'll try and post a build with a fixed Koushien 2 tonight or tomorrow if possible. |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Fri Feb 09, 2007 4:40 am Post subject: | |
|
|
|
| I just tested Koushien 2 and Toy Story wip 0.019w9 and saw the bugs myself. This might be a naive question but are we sure the bugs don't appear on hardware? The Toy Story lingering sound during pause doesn't seem that severe for a commercial game. Koushien 2 randomly freezing would be of course critical...then again, I'm sure there are really obscure commercial games that have been terribly coded to the point of unplayability. I know they don't happen in Zsnes, but we can't be sure Zsnes is correct either. If I'm not mistaken Fitzroy has access to a copier...it would be nice to confirm if they happen on hardware or not. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 6:48 am Post subject: | |||
|
|
|||
|
I
was mistaken. Moving the pitch wrap to test before writing seriously
flattens the echo effects in pretty much every game. In that case,
let's go with DMV27's idea. EDL now clears echo_index. I also renamed
echo_target to echo_length, and removed echo_size, since it can be
calculated from EDL when needed. Koushien 2 is now playable.
Unbelievably tough game, that. Since finally fixing that awful baseball game left me in a good mood, and since I'm apparently a masochist, I took a quick look at MK2.
Extra interrupt, fun! Trying to toggle on VIRQs right at the end of the scanline, causing another IRQ to fire on line 216 when it should not. Copied the IRQ into a demo ROM, tested it on hardware. bsnes is behaving the same way as hardware, just slightly off somewhere. How slightly off? By _four clock cycles_. One pixel. Yes, if MK2's interrupt handler was one quarter of one opcode faster, the game would break totally on real hardware. Don't believe me? See where the game is setting the dot position above? (lda #$0118) Go there in the ROM and change that to lda #$0119. For the less technically skilled, hex edit a headerless MK2 ROM and go to hex offset 0x86db and change 0x18 to 0x19. The game now works just fine. Set that to 0x17 (or maybe 0x16 in case the wai wraps another iteration) and watch it break on real hardware just like in bsnes. This is getting psychotic. For four clock cycles to completely break a game brings on a whole new world of shitty programming. It's frightening that code like this even exists. How do other emulators do it? As usual, they don't have proper IRQ handling and their timing is off, so the game plays when it really shouldn't. Deathlike wasn't kidding. This game is absolutely sick. And no, I don't know how to fix it. EDIT: fun log. http://byuu.cinnamonpirate.com/temp/irq.txt Last edited by byuu on Fri Feb 09, 2007 7:06 am; edited 1 time in total |
|||
Inmate
Joined: 31 May 2005
Posts: 1453
Location: Canada
| Posted: Fri Feb 09, 2007 7:02 am Post subject: | |||
|
|
|||
PCs don't support non-maskable interrupts? You'll have to forgive my utter lack of knowledge but can you explain why that is? Last edited by Cyrus on Fri Feb 09, 2007 7:03 am; edited 1 time in total |
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Fri Feb 09, 2007 7:03 am Post subject: | |||
|
|
|||
/jokes_________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Feb 09, 2007 7:48 am Post subject: | |||
|
|
|||
snark, these games where tested on 3 different copiers to confirm the problems do not happen on hardware. We try to check every bug on hardware because bsnes is so accurate most of the bugs that we see happen on hardware too. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 8:05 am Post subject: | |
|
|
|
| <post removed, see next page for updated post> Last edited by byuu on Fri Feb 09, 2007 8:51 am; edited 1 time in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 09, 2007 8:19 am Post subject: | |||||
|
|
|||||
I have confirmed Toy Story's bug on hardware. I could dig up my post from this thread, but... nah.
That is insane. At least the other fixes make sense again. Pretty good news if you look at it that way.Big props to you, TRAC, and DMV27 for Koushien. That makes Toy Story the last known mystery bug, if it still exists. EDIT: Yep, still there as you expected. Last edited by FitzRoy on Fri Feb 09, 2007 8:56 am; edited 2 times in total |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 8:27 am Post subject: | |
|
|
|
| Please hold up on testing wip13. TRAC found the bug with my echo buffer adjustment. I'm fixing it now, and will upload wip13 again. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 09, 2007 8:33 am Post subject: | |
|
|
|
| My config options were not saving as well in that wip, but it's not a big deal. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 8:50 am Post subject: | |||
|
|
|||
|
(Repost, since this got bumped by another page, but updated message.) Ok, this build has TRAC's and my idea for an S-DSP EDL fix applied. EDL writes take effect immediately, and echo index bounds checking occurs before FIR filtering and echo buffer writes. Please test this with all of the really really picky/sensitive audio games you're aware of, and see if you notice a difference between this and v0.019 official. Obviously, the sound differences should only exist in echo effects, but luckily just about every game out there uses the echo buffer. Note any differences you find either way, but I'm particularly interested if things get worse, which will imply this fix is incorrect (assuming the difference is verified in hardware as being correct in v0.019 official), and we can try out the fix idea suggested by DMV27. If no one finds any new audio bugs, we'll assume the fix was correct. And no, there's no audio resampling in this. I think log audio data might still work, if that'll make it easier. It might not, the win32 port is falling apart as I rewrite the cross-platform port.
If anyone insists on posting about this on some other site (I'd prefer not, as always), please at least mirror the file. Update: audio logger works. I binary compared two files. The only difference is that audio is being output four samples sooner now, they're otherwise exact matches. Doesn't seem to be a bad thing by any means. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Feb 09, 2007 11:27 am Post subject: | |
|
|
|
| I don't hear any differences in Chrono trigger, FF3, Killer instinct or Zombies ate my neighbors. However i have the "feeling" that the audio sounds more accurate now. did find a bug in one of my favorite games though. Zombies ate my neigbours: bug 1: line error on titlescreen, when the title is waving, 1 line wraps around to the other side of the screen, i usually skip the title screen, but this one scanline bug has been there as far back as 0.17 public. bug 2: This bug seems to happen in most emulators, but its especially annoying in bsnes, and worse than ever in 0.19wip13. when i play on my original cart, if my sprite touches an item or person i will immidiately pick it up or save them. but in bsnes i seem to have to touch a certain pixel before it gets activated. seems like a problem with the collision detection in the game? i have no idea what could be causing this to happen in bsnes |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 3:37 pm Post subject: | |
|
|
|
| The one line error thing is quite well known. Not much can be done about that at present. The SNES doesn't contain any sprite collision hardware code. All of that is done in software, and I have serious doubts that I have core CPU opcode logic bugs this far into bsnes' development that have gone unnoticed. Maybe it has something to do with the way I present video earlier than most emulators ... this would probably be the hardest possible bug to investigate because I would have to disassemble the game and figure out how it's collision detection even works to attempt to fix anything with it. I'd want serious confirmation on this before even acknowledging it, but this would almost definitely be out of my hands to fix. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 09, 2007 4:40 pm Post subject: | |||
|
|
|||
Tested
some games today with no problems, notably Earthworm Jim 2, Chrono
Trigger, Der Langrisser, and Super Castlevania IV. I heard no
differences in sound to wip9, and I'll bet a wav analysis confirms
that. Seems like you guys may have figured out that critical bug.
I got suspicious of this "bug" after enabling line caching in the config with no result. Here's a screenshot from real hardware. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 5:14 pm Post subject: | |||||
|
|
|||||
The output should actually be identical (excepting that output seems to begin faster by four samples), except when changing ESA/EDL while echo writes are enabled. This is a dangerously stupid thing to do (at the very least, it screws up the FIR filtering for at least one sample), but that's never stopped game programmers before. I don't expect many games to have any audible differences. I don't know whether to be happy that they allow us to emulate the hardware more accurately, or upset that they make my life hell. Unfortunately, without anomie around, we can't verify why he believes that EDL is cached until the echo index wraps around. So I'm simply going with TRAC's suggestion for a simplified approach. I have to agree with that due to all of my IRQ findings. My original IRQ setup had tons of internal variables and all kinds of special cases. The more I learn, the more simplified the IRQ routines become.
Hooray! Less bugs to fix :D Thanks for testing, FitzRoy. --- My theory for MK2, based on that IRQ log, is that the SNES is only testing to set the IRQ valid flags during lastcycle edges. That would essentially be saying that the SNES hardware is range testing the IRQ positions, rather than just testing on every clock edge. That seems more complex, implementation wise, so maybe it's something else. Maybe it simply doesn't lock the IRQ except on lastcycle edges ... hmmm. In the off chance someone skilled enough is reading this thread anymore: http://nesdev.parodius.com/bbs/viewtopic.php?p=21883#21883 I go into detaisl on my potential fix. I'm really starting to think that the "delay" I'm currently implementing on $4200 writes is in reality not a delay, but simply the CPU acknowledging the old $4200 variable instead. This would be very, very bad if true. It would require SNES CPU pipeline emulation to emulate properly. That basically means I would have to split the S-CPU in half, separate the bus cycles from the work cycles (the latter being one cycle behind). Very, very difficult to do, and libco will not help at all. Then again, maybe I can hack things up again, and cache the old $4200 variable and use that as a substitute. That's going to be messy and hackish, though :( |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Fri Feb 09, 2007 7:29 pm Post subject: | |
|
|
|
| Good
work fitzroy, i do not remember that line being there on my cart, so to
verify what i posted i want to check my cart (the one in goodsnes might
be a bad dump or maybe my cart is a 1.1) but the box is empty and i
cant find it anywhere, i'm afraid it got stolen . |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Fri Feb 09, 2007 8:18 pm Post subject: | |
|
|
|
| I know this is a test build,but there are some differences between WIP9 and this WIP build: - Using frameskipping leads to zero performance gain in this WIP.Even setting it to "9" doesn't change anything,this is unlike WIP9 in which setting it to 1 made a huge difference - Limit (throttle) speed doesn't work at all - Speed (performance) has gotten noticably slower in this WIP.For example,this machine now tries hard to get steady 50fps in SMW,LOL Tested some titles,no bugs found so far.Now to test some of the more problematic stuff like EWJ,Aero the Acrobat,etc. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 09, 2007 9:17 pm Post subject: | |||||||
|
|
|||||||
This was built with FAVOR_ACCURACY, which means RTO is calculated even on skipped frames. You'll fail the SNES Electronics Test with FAVOR_SPEED and frameskipping used. Was an accident though releasing with that on.
Nope, that code got nuked while I rethink how to handle speed throttling.
Nothing changed since v0.019 official to slow the emulator down, other than disabling the out-of-order execution for CPU<>SMP (it doesn't affect accuracy, but was hindering my audio resampling. I'll add that back in since the audio resampling thing won't work anyway). Sorry you can't get 60fps anymore, I'm sure that makes testing the audio quality quite difficult. Log audio data should help, you can toggle it on and off mid-game, then listen to it in an audio player. --- I have another idea of what might be wrong with MK2. I was too busy looking at the IRQ code, but I'm now thinking ... wait a minute, a four-clock error? I remember DMV27 submitted some fixes for WAI timing a while back, but I never really verified I had it right. If that were off by even one cycle, that could be the difference needed to fix MK2. But, who knows. I'll try it out tonight and see what happens. I was pretty sure I added DMV27's correction properly, though. |
|||||||
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Sat Feb 10, 2007 1:49 am Post subject: | |||
|
|
|||
Byuu wrote (taken from NESDev forums) :
Have you installed any _drivers_ for your monitor(s)? No monitor in Windows (even the most expensive ones) can go above 85Hz without the drivers. For example a high-end CRT supporting 2048x1536 and 200Hz refresh can only display 1600x1200 and 85Hz (max) without its driver. You have to disable the Refresh Rate Override setting for all resolutions in your graphics card drivers as well. Also you should be aware that Linux doesn't support all refresh rates and resolutions your monitor(s) can provide.Most distros don't even support 100Hz and/or 1600x1200
|
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Sat Feb 10, 2007 7:24 am Post subject: | |||||
|
|
|||||
|
Can you hear that? That's the sound of thousands of Japanese Besubaaru enthusiasts rejoicing in unison at the prospect of playing one of Super Famicom's greatest classic again on bsnes (ok, that's a mouthful) Seriously, good to hear that Koushien 2 is finally working (even if probably nobody will ever play it haha) and that the emulation is yet again a little more closer to the real hardware. Perhaps like you said, those crappy coded games do serve a purpose after all lol
Yeah, most CRTs at least should support 100hz at 640x480 or 800x600. Well, all the ones I've ever used did. |
|||||
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Sat Feb 10, 2007 1:15 pm Post subject: | |||
|
|
|||
X11 supports custom modelines to set pretty much any resolution you want, within the specs of your monitor and display adapter. Some drivers are fucked though, or need to be told to ignore EDID. |
|||
Locksmith of Hyrule
Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
| Posted: Sat Feb 10, 2007 2:43 pm Post subject: | |
|
|
|
| ...Don't you specify refresh rates in the xorg.conf anyway? _________________ <Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours? |
|
Gambatte Developer
Joined: 21 Oct 2005
Posts: 109
Location: Norway
| Posted: Sat Feb 10, 2007 2:54 pm Post subject: | |
|
|
|
| Those are mainly used as a fallback if getting EDID information fails. Some monitors, for some stupid reason, have incorrect EDID information which you can override. Usually you only get a default list of modes, but you can add custom ones, within the sync ranges of your monitor, using modelines. | |
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sat Feb 10, 2007 8:52 pm Post subject: | |
|
|
|
| i checked out the box for zombies today, seems i might really have an undumped version unless all pal releases where identical and they only changed the box and stickers. | |
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Sun Feb 11, 2007 2:07 am Post subject: | |||
|
|
|||
Off topic, Speaking of artboxs...I know you're currently extremely busy with the core emulation and rewritting certain parts of bsnes but I figure I might ask right now when the idea is fresh. I think it would be a great thing, sometimes in the future, to have some sort of game loader similar to Mame32 where you can see the game box, manuals, catridge, game information etc (obviously all these would be external files) Not only does this help to make the emulation feel more "real", but it might also encourage people to preserve all those things. I guess it could either be integrated in bsnes itself or work like an external frontends like the dozens availbale frontends for M.a.m.e (not to confuse with derivatives M.a.m.es) |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 11, 2007 4:27 am Post subject: | |||
|
|
|||
|
Alright,
sorry to get so upset over Mortal Kombat II. I'm still burning out
pretty badly, not sure what to do about it. But I do appreciate you
pointing out the bug, Clements. As it turns out, it wasn't a problem with my IRQ support, but with wai timing. After reading the w65c816s manual a little closer, and running some tests on hardware, I've figured out how WAI is supposed to work:
The only last minor detail is whether or not last_cycle() happens on cycle 2 (3 in the manual, I number my cycles 0-2 instead of 1-3, 0 is opcode fetch) or not. It would be exceedingly difficult to test, though. The manual reads as if it does not. I also wrote a test ROM to verify WAI timing is correct. I really don't think it's possible for a non-cycle-based CPU core to emulate WAI correctly, due to it's locking nature. To get MK2 working when your emulator has proper interrupt support and timing, the important part is the I/O cycle at the end of the opcode, otherwise WAI can end earlier and throw off MK2's HIRQ interrupt code. Then again, extending the opcode length rather than fixing it properly could potentially break other games that rely on it not taking too long ... So, one more game to scratch off the buglist. I also tested all of the following games and they still work fine: - Battle Blaze - Battletoads & Double Dragon - Final Fantasy IV - Final Fantasy Mystic Quest + Mystic Quest Legend - R-Type III - Robocop Versus The Terminator - Secret of Mana - Street Racer - Wild Guns Everything looks good. Now if we can just fix Toy Story's audio effects, we'll have the buglist back down to just Uniracers, which remains as the only critical bug left. Edit: new private WIP is up for testing out the WAI fix. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 11, 2007 6:30 am Post subject: | |
|
|
|
| Byuu you rock!!!!!!!!!!!!!!!!!!!!!!! That "wai timing" stuff fixed zombies!! now its just like on the snes!!! I tested several more games now, i think this wai timing has fixed hundreds of subtle bugs, games now feel much more fluid and i no longer feel a difference in playing them compared to the snes (except for the graphics/colors) games tested: Zombies chrono trigger final fantasy 3 front mission eng patch mario kart everything feels perfect now Last edited by tetsuo55 on Sun Feb 11, 2007 7:03 am; edited 2 times in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 11, 2007 7:02 am Post subject: | |||
|
|
|||
Amazing. Could this truly mean the end for IRQ hell?
I know there are websites out there that try to database the manuals in txt format. But to obtain 3000 games in complete condition, without any damage to the flimsy boxes and manuals... is pretty much not going to happen. Cabinet art is way more durable and MAME has a much bigger following than the SNES. |
|||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Sun Feb 11, 2007 7:29 am Post subject: | |
|
|
|
| this
is true, but there is still a large SNES following, and a lot more
people had snes games than an actual arcade machine. It would take
awhile, and some games wouldn't have all the stuff for a long time, but
it'd be cool. Also it would premote people actually learning more about
games and seeing it all. Can't wait for the next release byuu, from the sound of it things are great. any particular next step after you fix toy story and possibly uniracers. Are there other parts of the main system you want to work with, or possibly sound stuff or would you look into specialty chips. No matter what, this emu is really great and everyone should see it. Sooner than most think this is going to be a great emu to play with as people's computers get faster. _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 11, 2007 8:56 am Post subject: | |||||||
|
|
|||||||
Lucky me, that'd be a really tough one to try and fix.
Very likely, let's hope. However, I am not able to test every single edge case for NMIs and IRQs. Mostly because with all the variations, there's probably over 10,000 unique tests to be made. But the differences would be much like the one edge case I can't test with wai. To trigger an IRQ twice, one CPU cycle apart, would be unbelievably difficult, even using specialized tests that I came up with for exact clock position seeking, I would probably need to manually try 50+ combinations of opcodes to get the right timing to test it. I really truly can't imagine any game ever relying on such an edge case of an edge case. And if it does, that game really is utterly broken. Such behavior probably even varies per revision of the chip. We really have to draw the line at some point and say, "Whoa, whoa. This may have worked on the real system by the grace of the gods, but this game simply should not exist or be catered to!" Not so sure we have to worry about that though, given how small the buglist currently is. It seems IRQ emulation is accurate enough to run all commercially-released games now. As nice as perfect hardware emulation is, we'll never achieve that. It'll be nice to know that 100% of all known games will be forever preserved with only a single hack-free emulator, at least. Now unfortunately, DMV27's notes on Toy Story aren't enough to give me a headstart on trying to fix it. I'll just have to learn more about the S-DSP and test sections at a time until I accidentally fix the bug. It's at least minor enough that not many would really even notice it.
Honestly? I'm not sure if I want to take on the dot-based PPU needed to fix Uniracers, and I lack the knowledge on how to fix Toy Story. I'll probably focus on the latter, and polish up some details of S-DSP operation. I want to try and emulate the S-DSP without the need for subcycle emulation. Basically, subcycle-accurate emulation of the S-DSP and S-PPU is going to require the assistance of someone with a master's in electrical engineering. We would absolutely need custom hardware built to interface with these chips and determine exactly what they're trying to do during each and every clock tick. Unfortunately, I still can't build a simple LDR+PNP transistor circuit, and I really can't see myself studying EE for half a decade just to support this in bsnes. The reason I can emulate the S-CPU and S-SMP so well is because they are general-purpose processors that I can run my own code on to analyze their behavior. The S-DSP and S-PPU1/2 are DSPs with their own custom programs that I cannot see. You all saw how long it took to get DSP-1 emulation bit-perfect, and the absolute geniuses that worked on that. I don't think so highly of myself as to think that I could recreate their success with these chips. Even more daunting is the fact that the exact bit-perfect binary data could be read back from the DSP-1. We do not have such luck with video and audio output data. Such data, even through an S/PDIF or RGB output port which I lack, is probably at least slightly altered from the original values, and even then probably has some fluctuations after each run due to all of the crosstalk occuring through imperfect timing crystals. So basically, I want to try and fix Toy Story if I possibly can, and then write a ROM patch to "correct" Uniracers' non-standard behavior, if it's at all possible. I also want to try and get HDMA bus sync timing working once and for all. Special chips would be nice, too. But I won't be adding SA-1 or SuperFX myself. They are simply too demanding, especially considering the lowest-possible-level approach I take to processor emulation. After that, I want to start polishing up the code. Moving all non-core related code (such as filters and WAV file writing, and much later on the file loading code) outside of the core, and into the platform-specific code. Then I want to clean up and document all of my work. Then clean up the user interface and its' code as much as possible, and get the code ready for the inevitable final release. I'd like to release my final SNES emulation core as a work of the public domain, so that others can benefit. But I have a long, long way to go until then (probably 2-4 years), and the code stays under my current license until then. |
|||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Sun Feb 11, 2007 9:28 am Post subject: | |||||||||||
|
|
|||||||||||
True, true. But even if preserving all manuals, box scans etc is probably never gonna happen, an emulator support would give it more mainstream visibility, thus further encouraging preservation of everything that's not directly strictly binary ROM dump related... Plus it's a great thing to have imo. Of course it's always up to the end user to find the manuals,scans,txt etc. like with Mame32
Do you mean the bug2 collision detection you mentionned? Or the bug1 line?
Ideally,if you ever decide to tackle the dot-based PPU. would be to release one final "for public usage" version of bsnes with the current scanline-based renderer, one that plays every non-special chips games correctly (and maybe either a hack or like you said a ROM patch for Uniracers) and then try the dot-based PPU that would serve more as a reference than anything that's actually intended to use. Thing is, I doubt there are many people, if any, that would actually try to do it if you don't. Not complaining but merely stating the situation. Of course, beggars (i.e: end-users) can't be choosers and considering the insane ammount of work you've done these past few years it's fair game either way whatever you decide. |
|||||||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 11, 2007 10:42 am Post subject: | |
|
|
|
| Byuu, i would like very much for you to pursue the remaining audio issues. The audio is still slightly off compared to my hardware, but its extremely close. ofcourse my sound could be different because of little differences in clock frequencies. Snark: I ofcourse mean "bug2 collision detection", fitzroy already reproduced bug1 on hardware. Byuu, do you think it would be possible to later create a winamp plugin for you audio engine? this way i could have the best possible snes music emulation. Finally, do you still have contact with Arbee? I see a lot of interesting things happening around mame and mess, a lot of people there can do things like decapping chips and reading outputs from dsp's, cpu's Maybe if someone wanted to help with the snes we could somehow donate the hardware and games needed so we could get the technical documentation needed of the DSP's and Special chips? |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 11, 2007 11:28 am Post subject: | |||||||
|
|
|||||||
It's really not an emulator's job to encourage people to care about ROM or packaging preservation, especially when the latter has greater nostalgic than gameplay implications. If you're talking about a front-end, though, I have to believe that there already is one. I swear I've seen stuff like this being made for people wanting full read-outs for their games: names, release dates, genres, screenshots, etc. And they work with stand-alones. Sounds easier than convincing every stand-alone emulator to be more like MAME32, yes? |
|||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 11, 2007 12:29 pm Post subject: | |
|
|
|
| Still i think byuu wanted something similar too. i too would like a mame32 like interface, with game screens, box shots, info about the game, cheatcodes and all that stuff in a pane, but without losing the "open cart" option |
|
New Member
Joined: 30 Nov 2004
Posts: 8
| Posted: Sun Feb 11, 2007 2:45 pm Post subject: | |
|
|
|
| Byuu, have you considered using the open-source cross-platform GUI library wxWidgets, instead of writing your own? I haven't tried it myself, but it's the same library used by Audacity, Code::Blocks, and VLC, and it's licensed under a more permissive variant of the LGPL. | |
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 11, 2007 8:42 pm Post subject: | |||
|
|
|||
That was a long time ago, before he even decided to go cross-platform. Maybe that changed his plans a little, because he doesn't mention this on his agenda. But like I said, why wait? There may already be a front-end out there that will let you construct your own database, and not just for bsnes, but for every other system. It doesn't make sense for every emulator to integrate their own front-end. What games get included/excluded in the games list? Who's going to update it when new dumps are discovered ten years from now and he's not working on bsnes anymore? Are the benefits of an official front-end really worth the trouble over referencing an external database? Etc, etc. |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Mon Feb 12, 2007 3:01 am Post subject: | |||||||
|
|
|||||||
No, probably not.
If it works with bsnes then yes, fine with me.
What I had in mind, it wouldn't necessarily work with a database, so no maintining there (Although I wouldn't necessarily be against a integrated system either) But, in it's basic form, the user would simply point to the relevant files that links them to one particular ROM/file. So let's say: 'Select ROM.smc /Right click/Select Jpg for "screenshots"/Select Jpg for Boxarts'...and so on. Entirely local, no maintining needed whatsoever.Would work with any and all future Roms. Anyway, if there are indeed frontends that accomplish just that, than I guess that works just as well. edit I'll see if I can find something that works well with bsnes and reports here if I find anything. edit: Well a generic frontend named "Gamebase" http://www.bu22.com/ works well enough. although obviously, since it's aimed at emulators in general, it's not nearly as intuitive but there's a little guide included that tells you everything you need to start. It works well with 0.019w9. Supports screenshots for individuals games and possibly even music (  ) although I haven't tested that and seem like an overkill, but anyway overall it works fine.Last edited by Snark on Mon Feb 12, 2007 4:49 am; edited 5 times in total |
|||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Mon Feb 12, 2007 3:38 am Post subject: | |||
|
|
|||
Whow...considering what byuu said earlier that's pretty amazing, and a little scary I guess. Bugs like this could go completely unnoticed despite extended testing, because the only people who could notice them are the ones who are very familar with the game...scary. |
|||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Tue Feb 13, 2007 4:40 am Post subject: | |||||
|
|
|||||
I
tested Toy Story a while ago, but I never got around to posting this
info. It seems that Toy Story and Der Langrisser require opposite KON
behavior.
In TS, the game sets KOF/KON = FF then about 2000 cycles later it sets KOF/KON = 00. If the flags are updated by the DSP between the last KOF/KON = 00 write, then KOF = 00 and KON = FF which will cause the sound effects to start playing. In DL, the game first stops a voice using KOF, waits until envx == 0, then it enables the voice using KON and immediately sets KOF = 00. The game expects that the voice will always start playing when using this process. Possible solutions: * After the DSP flags are updated every other sample, if status.KOFF == FF then set the internal status.kon = 00. * Create a var "bool kon_changed". After writes to the KON reg, set kon_changed = true. After the DSP flags are updated:
This solution allows KON to decay fast enough to fix TS, but slow enough to allow DL to work. It's possible that either game could require subsample timing, but that seems unlikely. What we really need is more info on KON. Does KON get read once at the beginning of each sample, or 8 times per sample as each voice gets processed? Does KON really decay as fast as anomie's tests indicate, or is there some special case that is being missed? |
|||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Feb 13, 2007 10:26 am Post subject: | |
|
|
|
| How could we be able to test con decay on hardware? EdIt: None of the video settings work in the latest wip. Edit2: Byuu, i would like to help and update the cartDB, how can i add info to it? i have access to a lot of pcb info now.. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Feb 13, 2007 4:48 pm Post subject: | |||||||||||
|
|
|||||||||||
It can't be said enough, so thank you again for the info :D Learning about the echo buffer was surprisingly easy (though I still don't understand how that FIR filter works), but the KON/KOFF registers seem far more involved. I'll keep studying the code. It doesn't look particularly complex, but there are so many little subtleties that will completely destroy audio output ... Do you think I would be able to test and verify this stuff if I continued to learn about the S-DSP? Or would I require some sort of digital linkup to record SNES audio output to analyze? I'm thinking maybe I can get a high quality RCA input sound card and just record from line in. The results won't be perfect, but should hopefully at least be able to catch 80 consecutive samples of sustain vs release. At any rate, it's a lot easier to do this than capture echo buffer data and transmit it back to the S-CPU to display onscreen as binary data. With a sound linkup, I could just simply get an S-SMP program running and log the audio output directly.
I'm at your mercy as to which you believe is more correct :/ I should be able to implement either one. The latter sounds more plausible, but if I've learned anything from the SNES, the more reasonable approaches are quite often wrong. It would be really nice if we could implement the S-DSP without going into subsample timing. The problem with subsample timing is that we really, really, really cannot test and verify anything that we try and implement. Even trickier is that the S-SMP and S-DSP probably run exactly one read access length apart (and take enough time for two reads), so that bus conflicts do not occur. Talk about something fun to try and emulate.
If you're not busy ... are you able to program tests that I could run on my copier, and have me give you the results? If you are busy, I'll do my best to test these things when I can.
I know, but thanks.
src/cart/db. I'm hoping to rewrite it in a few months anyway. I'll be sure to make a graphical table editor at that time. |
|||||||||||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Tue Feb 13, 2007 6:41 pm Post subject: | |
|
|
|
| thanks byuu, that version of the db is much more readable than the .db binary | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 15, 2007 9:01 am Post subject: | |||||||
|
|
|||||||
|
DMV27, I forwarded your reply to anomie, here is his feedback:
However, obviously by setting kon to 0 every time kon_changed is set, Der Langrisser starts dropping ~30% of its' samples. My S-SMP and S-DSP cores are as closely synced as is possible (down to subcycle bus hold delays) without subsample-accurate emulation of the S-DSP. Now, I'm looking at your Toy Story log ...
Am I missing something? There are 33 full S-DSP samples being generated, isn't this far more than enough time for the S-DSP to kill voice 0, without the need for buffering kon_changed (thus resulting in basically an 8000hz polling rate for KON/KOFF/FLG)? anomie also updated his apudsp.txt file in SNES9x repository. PM me if you'd like a link, but here's the important info he posted.
|
|||||||
Rookie
Joined: 27 Jan 2005
Posts: 32
| Posted: Fri Feb 16, 2007 7:16 am Post subject: | |||||||||||||||||
|
|
|||||||||||||||||
With the right tests you should be able to verify some things, but I don't know how accurate an RCA input will be. You could also just get an RCA to 3.5mm adapter instead of a new sound card.
I would go with the second one. It seems to work well with DL, TS, EWJ2 and other games.
I should be able to come up with something, but I want to finish working on my audio regulator (video sync) code first. It's possible to get smooth audio with a 75ms buffer, but it does require a bit of math to keep the audio from sounding horrible.
The best thing to do would be to just record the output of DL from a real SNES and then compare it to bsnes to see if the notes all match up. If they do, then no notes are being dropped. That still won't (dis)prove that the game requires subsample timing, but the only way to do that would be to examine the game's sound code.
The "..." in the middle of the log indicates the unneeded part of the log that I removed (notice the large jump in clock cycles). The top of the log is the start of the pause, and the end of the log is where the game is unpaused. Everything from cycle 61150012 to 62083238 (or 62087085) is where the sound effect on voice 0 (or 5) gets stuck during the pause because the KON=FF at cycle 61146244 did not decay. Although this only covers about 0.91 seconds, it would continue on forever if the game was left paused. Also, kon_changed would only set the KON decay rate to 8000 Hz. The polling rate would still be 16000 Hz.
The code in bDSP used to do this before the DL fix, but then it was changed to only clear ENDX for voices that were actually keyed on. If this is verified on real hardware, then it can be changed back. In either case, I don't know of any games that are affected by the change. |
|||||||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 16, 2007 3:08 pm Post subject: | |||
|
|
|||
|
DMV27,
blargg suggested the following to fix both Der Langrisser and Toy
Story. I don't have the latter to test, but the former works correctly
now, and using anomie's old "kon instantly gets cleared" hardware
findings. blargg also confirms those findings. The idea is that we
perform KOFF test, and then kon test, even if KOFF were set. This gives
games times to clear KOFF and still have the sound effect play. Nothing
plays immediately because we wait 8-9 samples before playing a new
keyed on channel anyway. Everyone else, please try the latest WIP with DL, TS, etc and see if any regressions have occurred. This does work for DL for me, and should fix TS once and for all. Consider this a private experimental WIP. If it works ok, I'll get a new version up by tomorrow for everyone to try out.
|
|||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Fri Feb 16, 2007 4:37 pm Post subject: | |
|
|
|
| where
can we get the latest wip? I know it isn't a public release, but I
wouldn't mind knowing how to check em out as this stuff interests me.
That is of course unless this is only for select testers, in which
case, never mind. _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. Last edited by Panzer88 on Sat Feb 17, 2007 1:29 am; edited 1 time in total |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 16, 2007 5:24 pm Post subject: | |
|
|
|
| Toy
Story's not fixed in the new wip16 for me. DL, EWJ2, and Battlemaniacs
all sound fine, as they did in wip14, but Toy Story's problem seems to
actually have gotten worse (or better, if you wanted it to become
consistent). The repeating and persisting sounds used to be somewhat
random, happening ~50% of the time. Now they happen 100% of the time.
Woody says "Yee-ha" twice at the beginning, and the plane engine sound
always persists after pressing pause. Just to clarify, neither of these
happen on hardware. Here's a bsnes wav output with a really good example of the insanity that sometimes happens in the middle. That part still seems random and dependent on where you end the song. Sometimes it catches the middle of a note and then goes screeeeeeeeeeech. The end is just me pressing pause during gameplay. http://upload2.net/page/download/m20ZIcOfZPfi0rQ/toystory.rar.html |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Fri Feb 16, 2007 6:02 pm Post subject: | |
|
|
|
| Does Der Langrisser drop sounds once in awhile on hardware? I know Earthworm Jim has some sound variances on hardware. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 16, 2007 6:13 pm Post subject: | |||||||||
|
|
|||||||||
Sigh, alright. I'll try and be a bit more mature about this one than Mortal Kombat II. Ok, so now it's always repeating the audio effects ...
Ok, so FLG doesn't set anything here except echo buffer write disable. So the `if(soft_reset()) { ... } else { ... }' isn't the problem. What I see happening from the above code is: - KOFF disables all channels. KON then says, "no, actually, let's play them", and clear internal kon to zero. However, KOFF is still set on all channels. So two samples later, all of the sound effects stay off, long before any sample from the KON write would get output. Then finally, KOFF is released. But since internal kon is clear, no sound effects should play. Why they still are, I don't know. Sigh, I'm going to have to play this game at work to track this down. Maybe I can just color adjust the image to be virtually pitch black or something. EDIT: Here's my TS log:
I was looking over anomie's ported emulation code and I think I've found the problem.
anomie recently mentioned that the only reason for the key_flag was to prevent performing the below code when it wasn't needed. But now that we no longer have the `else' in the kon&(1<<channel) key-on test, it appears that Toy Story is turning off all channels, then turning them all back on. Now, key flag doesn't get set again until later when KOFF is cleared entirely. So the result is that all channels stay on, because key_flag isn't set again with KOFF=$ff. Some channels get killed later on with KOFF=$f6, but some remain on. I should have a fix for this tonight. Last edited by byuu on Fri Feb 16, 2007 7:43 pm; edited 1 time in total |
|||||||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Feb 16, 2007 7:39 pm Post subject: | |||||
|
|
|||||
From what I could tell, no. Nothing sounded different than the way bsnes does it. I was even button mashing on the naming screen for a while trying to get something to happen.
lol. At least it's not Barbie Vacation Adventure. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Feb 16, 2007 9:59 pm Post subject: | |
|
|
|
| Ok,
I think I have it fixed now. Removed status.key_flag, and Der
Langrisser still sounds correct. I made a before and after recording of
Toy Story, and you can see at the end of the latter recording that the
audio drops to all null samples. The sounds definitely stop in the
latter one, but it sounds a bit rough during the ~20ms key off release
state. I'm guessing real hardware sounds the same, but who knows.
Killing audio channels completely rather than fading them out slowly
typically causes popping in audio. Here's the samples: http://upload2.net/page/download/HtXNsJQX8DC42wg/toystory.zip.html I'll post a new build later tonight. This one should be fixed now. EDIT: release takes up to 8ms, per TRAC. By setting KOFF=$ff, KON=$ff, KOFF=$00, the game is forcing release a lot faster, as KON clears ENVX to zero. This causes a much faster, much harsher release. Hence the crackly sound. Had the game only used KOFF=$ff, release would have taken longer but sounded better. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 18, 2007 4:29 am Post subject: | |||
|
|
|||
Ok, as promised, a public WIP build:
As always, please be generous with this one. If you must link to it elsewhere, please at least mirror it. This should finally take care of the Toy Story bug. Yes, the audio should halt roughly. The developers felt the need to use an evil trick to force the audio to release faster than it normally should. |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 18, 2007 7:07 am Post subject: | |
|
|
|
| I can vouch that it sounds just like hardware now. With only three dot-based dependent bugs remaining, you've really proven libco to be a great strategy. I hope future authors, especially on earlier systems, will consider it. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sun Feb 18, 2007 8:14 am Post subject: | |
|
|
|
| Good times, thank you for verifying. I tried out the tougher games: EWJ2, ToP, SO and CT, they sound good still. By the way, wasn't it Mega lo Mania and Winter Olympics that had the scanline issues? I thought Adventures of Frankenstein flickered with the other setting (with line caching enabled, IIRC) ... I suppose I should look into that line caching a little more in the future. I wonder if I can just modify bPPU to poll twice per scanline to get those two working correctly. But first, I'm thinking I'd like to stay in sync with blargg's work on a subsample-accurate S-DSP emulator. Though it clearly isn't needed, that's never really stopped me before. Luckily, this shouldn't be anywhere near as processor-demanding as a dot-based PPU renderer. Probably won't even be more than 3-5% slower, tops. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 18, 2007 8:57 am Post subject: | |||
|
|
|||
Frankenstein and Winter Olympics show their line bugs with line caching disabled, and are unaffected by hclock. Their issues disappear with line caching enabled, but enabling line caching then results in Mega lo Mania having a permanent line issue, as well as sprite flickering in games like Ninjawarriors and The Lord of the Rings. The flickering would usually occur when one sprite occluded another one. Since this specialized fix for dot-based games started affecting untold numbers of normal ones, you moved it to disabled by default. So, technically, I could say that "line caching" is a work around for these two games on my buglist, but I don't really like the idea of suggesting that. People could turn it on and forget to turn it off, which has the potential to screw up a bunch of better games and get you false bug reports. If you can fix it, great. But if not, consider removing the line caching option and doing this: People throw the word hack around like it's a wholly bad thing. I think that if an emulator uses game-specific hacks by default, with no transparency to the user that they even exist, then that's a bad thing. But if you were completely transparent about it and had them disabled by default, then what's the big deal? It beats modifying the original data, and it wouldn't break other games by having them on. It also doesn't rule out the possibility of one day getting a dot-based renderer. The only problem is that some people are going to act like these bugs should be fixed instead of hacked. But these bugs aren't like the other ones. Spending two years to fix three shitty games ceases to be a purely emulation related decision. That's friggin two years of your life. Anyone who thought less of your project for offering hacks would be completely misinformed. But meh, I guess you know people... |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 18, 2007 10:05 am Post subject: | |
|
|
|
| What
you could do is add those games to the Database and have bsnes enable
that fix automatically when the game is loaded, the enableling of
individual game fixes could be enabled/disabled in the configuration
options. this way everything would work before moving over to sPPU. Although i would rather see special chips/hardware support at this point i do think it would be a good idea to further improve on S-DSP, as sounds are still off slightly compared to my snes. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Sun Feb 18, 2007 12:07 pm Post subject: | |||
|
|
|||
|
You sure? (link) _________________ savestate editor: vSNES latest public version
|
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 18, 2007 1:55 pm Post subject: | |
|
|
|
| Good
post, I actually am assuming that the last difference in audio is
caused by my crystals rather than anything emulation related. At this point its as good as impossible to find any difference in audio between bsnes and the snes except for tiny pitch differences. The only part of the audio that still sounds off to my ears is the echo effect, and the audio cut off. however if have not yet had the chance to try the latest Wip, which might solve those last problems. As i have no hard proof for any of this i currently account everything to my snes crystals, but maybe an sample accurate S-DSP will close the gap even more. I hope when thats finished we could get a bsnes S-DSP plugin for winamp2 that is compatible with the current music sets so the soundtracks sound better Edit: Fitzroy, could you compare the sound output for Zombies ate my neighbors, just keep pressing start till you get ingame. Then compare the "Woo Haa" sound, and the falling text sound. Thanks in advance |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Feb 19, 2007 1:05 am Post subject: | |
|
|
|
| http://upload2.net/page/download/zcFZdlcARrQJh82/zombies-realthenbsnes.zip.html Isolated sound comparison. First the sound from real plays, then bsnes. The konami logo seems overly amplified compared to real. The "woo-ha" sound is nearly identical. And the falling text sound is nearly identical, save for the harsher ending. So for you S-DSP experts trying to improve things even more, this might be a nice reference. |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Mon Feb 19, 2007 2:23 am Post subject: | |
|
|
|
| The konami logo sounds less muffled. This could be due to the reasons byuu pointed out in the romhacking thread. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Feb 19, 2007 3:37 am Post subject: | |
|
|
|
| Unfortunately,
even an S/PDIF link from a real SNES isn't good enough, as we can't
verify/match its' CPU<>SMP communications. Our best bet for
verification is still the echo buffer. I uploaded a new private WIP. This build is just demonstrating part of the new UI. I'm trying to move back to putting everything commonly used in the menubar, and moving all of the obscure/complex stuff out into separate windows. So far, lots of stuff is still missing, and the speed setting (not enable) doesn't work. How does the video mode configuration feel in this WIP compared to v0.019's video settings panel? Easier, better, worse? I realize it loses a bit of flexibility (eg with custom resolutions), but eh. I'd rather go back to simplicity than feature bloat. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Feb 19, 2007 5:36 am Post subject: | |
|
|
|
| I
like it. The only problem I see in doing away with separate
windowed/fullscreen is that it might be overly difficult or even
impossible to get fullscreen to fill the whole screen with video data.
As it is, if you set your multiplier too high in windowed mode, the
video just disappears and bsnes has to be restarted. I'm sure you're
aware of this and are thinking of something. This behavior has always
existed in bsnes, but the separate modes made it avoidable. As far as speed regulation, I'm wondering why we need anything other than [check] "Regulate Speed." Who would want to regulate faster or slower than normal? If it's simply enable/disable, you can still find out how many fps your system can push. Semantics: The "(off)" under frameskip seems superfluous. I would guess that most people, even newbs, could infer that a separated 0 means off. I also like "Load" better than "Load Cartridge." I'm guessing you're probably going to combine color/raster settings as a popup window like input and cheats. Sounds fine to me. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Mon Feb 19, 2007 6:42 am Post subject: | |||
|
|
|||
Provided none of those differences are caused by the equipment used, I pretty much agree on all points. The very beginning of the sound of the 'Konami' intro I cannot detect any differences, but after that (aroud the 5th "note") the difference is clearly heard, being louder. "Woo-Ha..ha..ha..." I cannot detect any difference at all. Falling text sound: The small "pop" sound marking the end of the sound are more apparent on bsnes. edit: Ok, since it appear, from what was said, that the small differences could indeed be caused by the process of logging the audio just disregard this post. Last edited by Snark on Mon Feb 19, 2007 8:19 am; edited 2 times in total |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Mon Feb 19, 2007 7:19 am Post subject: | |||
|
|
|||
Do you think you can put up some screenshots for the curious [me]? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Mon Feb 19, 2007 7:58 am Post subject: | |||
|
|
|||
I agree. It could just be that bsnes is more clear. Maybe kmixer is resampling my snes input just enough to muddle the sound. Could also be attributable to the parts with which the mod was performed. The snes isn't natively digital, we know, and it outputs at a strange 32040hz. There's also something complex to do with sample randomness. As I understand it, it's just a hardware quirk that can only be simulated, not emulated. bsnes opts for ideal output vs slightly random output, and I think it makes sense to stay that way. The point, though, is that we can hear just how close it is. Anyone who claims Chrono Trigger's sounds are still off as per the romhacking thread is going to have to provide recordings to back it up. That guy wasn't even using the same speakers in his comparison. Plus, it's so damn easy for people to be tricked with placebo. That's why I constructed the wav the way I did. One right after another, so your memory doesn't screw with you. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Mon Feb 19, 2007 9:49 am Post subject: | |
|
|
|
| Thanks for the Wav file, the difference in your WAV file is exactly the same as the difference i hear between my snes and bsnes byuu: I like the new settings a lot |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Mon Feb 19, 2007 12:15 pm Post subject: | |
|
|
|
| byuu, how difficult would it be to implement an auto-frameskip feature? I know for example Zsnes and SSF and many other emulators have such a feature and I honestly have no idea how it works or whether or not it would be desirable to have in bsnes Hypothetical scenario: Someone has a system fast enough to get full speed with 0fskp 99% of the time...but on those few occasions where you're hitting a particularly demanding part the emulation will actually slow down for a short while...Not very fun. One solution is of course to set the frameskip to something like 1, which should pretty much guarantee full speed in all situations...Except it's kind of a waste to constantly play a +1 frameskip just for those rare occasions where your CPU can't keep up...Ideally, it should only skip frames when it can't reach 60/60. You can see why it's be a good option to have. In any case I'd be curious to hear how auto frameskip works. |
|
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Mon Feb 19, 2007 6:08 pm Post subject: | |
|
|
|
| Can I ask what you are using to record these sounds. I hope it's not some crappy card that re samples everything to 48khz, I've found the only reliable way to record sound from the SNES is by SPDIF or use a tv tuner card on it since they better support the NTSC rate of noise. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Feb 19, 2007 7:17 pm Post subject: | |
|
|
|
| Sound comparison stuff : S/PDIF is flawed, too. The SNES outputs at ~32040.nhz. This is of course because oscillators are not perfect. And really, they can't be. Further, there are two oscillators. One for the CPU, one for the SMP. And due to the differences, you get different rates of communication every single time you run the SNES. That means you can run the same game and record its' output, and get different results every single time. Though, due to the DSP design, it'll probably only mean being off by a sample or two for each channel being keyed on and off, but it could possibly be more severe. And even then, when you're trying to record the S/PDIF output, you have to somehow capture samples. I can't say I know how a sound card would record this input. It would have to have a pulse that tells it when to capture a sample, otherwise it would only be able to poll the S/PDIF at roughly 32khz, in which case you're duplicating and/or dropping samples on occasion, which is no good. Really, the best way to verify is to get a program into the S-SMP, and cease all communications with the S-CPU. Once this is done, you need to get the S-SMP to a known position. We do not have code to do this yet, and it will be significantly more complex than my S-CPU code to do this. Once here, we can generate sound and compare echo buffers on a real system to emulation, and the results should be stable. There's really no other way we can guarantee bit-perfect emulation. As it stands, we have no way to get bit-perfect comparisons. We can get "really, really" close, but not perfect. Because of this, and the aforementioned issues I pointed out on romhacking.net, I am not interested in investigating personal opinions on audio issues gauged by imperfect human ears, unless they are very obviously wrong, eg Toy Story's old bug. It's not to be mean, but we can't tell why the sound is different, and I can't verify when I have it right, so there's no way I can even attempt to try and fix any problems. GUI stuff :  This is basically what I'm going for. Yes, less flexible. You can't specify exact resolutions. But really, how often do end users need this? I'm trying to go with simplicity. I'll probably add some kind of manual override to the config file for power users, but I want to make everything simple for the majority. I like regulate speed settings. The only way I can play Mega Man X2 is by playing the game at 50% speed. Sorry, my reaction times are low. I'm more of an analytical thinker who spends a lot of time on detail, rather than a fast reactionary kind of person. I can't seem to change that, and I want to enjoy games too, so I "cheat" by slowing them down. Also, Der Langrisser will drive you batshit insane if you don't have a speedup ("fast-forward") mode. This is my approach to ZSNES' fastforward/slowdown keys. I prefer to keep the options permanently on, rather than keep a key you have to hold down. It's very hard to play a game at 50% speed when youre holding down a slowdown key the whole time, for instance. I use "Load Cartridge" because of the need for a separate option for ST dual cartridges. However, I am trying to think up a way to not require a separate menu option for such obscure hardware. I'm thinking about enabling multiple file selection inside the file open window, though I'm not sure how tough that will be, or if it's even possible for GTK+, yet. Auto frameskip is possible, but I've never implemented such a thing before. I'd basically have to predict how fast things are going and adjust for it. I'd honestly rather not code such a thing, as I was wanting to remove the frameskipping support eventually to begin with. The reason is because fast frameskipping is not hardware accurate as it skips RTO calculations. Enabling RTO calculations but not rendering results in virtually no speed increase, so it doesn't really serve a purpose other than to complicate the code. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Feb 20, 2007 12:26 am Post subject: | |||||||
|
|
|||||||
The mod is this: http://www.alpha-ii.com/Info/snes-spdif.html It was recorded using an egosys Juli@'s spdif input and wavepad. My driver's control panel allows me to select an external clock instead of the internal one. That's what I select when recording and it detects the 32khz rate being output from the modded unit. But yeah, these tests are only useful in that we can get a general impression better than that of analog.
Oh, hehe.
K. Only reason I brought it up is because bsnes can load homebrew data as well. A minor warning on the simplicity thing... it seems simpler to put as much as you can in the drop down menu, but the fact is that you're still going to need separate menus for cheats and input, and possibly the color/raster sliders if you're still planning them. And if you're going to need separate menus for that, then what you had before probably wasn't as bad as you think. The beauty of the previous design was, you go into config to set up all the major stuff once, and then you leave it alone. The stuff that people were likely to toggle was left to the drop down menus. And it isn't as though the previous design couldn't have been made simpler, too. Color/raster settings could have been combined with "enable raster settings" removed. Most of the emulation settings could have been removed. Manual screen render could have been removed. Axis resistance could have been relegated to the cfg. I think the result is going to depend on how you implement fullscreen. If a person has to mess with the scale setting every time they toggle fullscreen/windowed, then it might be more a of headache. By the way, if you want an example of dropdown menus gone apeshit, look at Kega Fusion. |
|||||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Tue Feb 20, 2007 1:47 am Post subject: | |
|
|
|
| You don't have to hold down any keys in ZSNES you can have it toggled on keypresses. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Feb 20, 2007 1:48 am Post subject: | |
|
|
|
| Yes,
I need to work out some sort of embedded window-in-a-window system for
GTK+, so that I can make an oldschool window configuration panel. For fullscreen, I'd like to make it just a hotkey, maybe a menu option as well. I don't intend to support true fullscreen anymore, merely I plan to stretch the window to consume 100% of the screen, and draw the video inside there. I was planning to just add some sort of scaling control to the fullscreen mode, such as "force fit all four corners", "force fit as much as possible, but keep aspect", "scale, but only by even multiples, as much as possible" ... I don't know. Let me go home and work on it some more. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Feb 20, 2007 2:01 am Post subject: | |||
|
|
|||
Totally sufficient, if possible. |
|||
Lurker
Joined: 19 Apr 2005
Posts: 128
| Posted: Tue Feb 20, 2007 8:04 am Post subject: | |
|
|
|
| Let
me say I am against the new direction for fullscreen modes. One thing I
cannot stand is the "stretch to fill the screen" style fullscreen
methods in emulators. This is because they cause warped pixels in order
to acheive that end. You know where every 10 pixels or so, one of them
is doubled in length in order to have the total image width reach the
edge. This is why I don't use fix aspect ratio options either, they do
the same thing in order to trick the eye into seeing a corrected image,
but the keen eye notices the warped pixels from enabling that. The
whole point of accuracy should be to allow users to avoid that method
should they have the means and knowledge to make their own custom
resses on their system. The way version 19 allows me to set custom resses while setting the fullscreen res in separate function is exactly what I always wanted and works perfectly. If the later versions of bsnes end up being forced scale toggles or "stretch and skew the image pixels to fill the screen" I'll stick with version 19's far superior display options. |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Feb 20, 2007 8:25 am Post subject: | |||
|
|
|||
I think this mode may satisfy your concern:
_________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Feb 20, 2007 10:08 am Post subject: | |||
|
|
|||
I realise that RTO (though I don't know what "RTO" actually stands for :P ) is not calculated when frameskip is enabled (hardware test failing when fskp enabled for example). But I figured it's allright, because you can always disable frameskip althogether and thus having RTO enabled. In that sense I don't see the need to remove frameskip support. I'll be honest, I'm not just in favor of having a highly accurate emulator but also a playable one. So needless to say I'm for added features like the NTSC filter, joypad support, frameskip support etc...And yes, that means I'm also in favor of options that actually reduce the accuracy of emulation (before anyone jumps, let me stress 'as long as they remains options' and the accurate way remains), because of the obvious speed benefits. Even that being said, I'll still support bsnes even if you decide to take it to a more "pure" level meaning removing stuff that benefit end users but has little or zero value in terms of accuracy or documenting the hardware. But, in a ideal situation, there would be a way to imbue both accuarate and less accurate method into the program and having the possibility of switching (having both a scanline and dot based renderer for example). I know you said that you don't see how this could be coded given the structure of bsnes, but surely there must be a way somehow?* The current RTO disable/enable function is actually a good concrete example of this concept. Unless of course you feel it start to go against your emulation philosophy and that even supporting the less accurate alternative would go against your goals, in which case that's an entirely different matter and a perfectly valid choice you can make as the author. ( Yeah, praise the Lord I'm finally done talking for now lol) edit: * Anyway, I don't want to come off as whining or begging for features. Needless to say I believe the author is free to take his emulator in the direction he sees fit. edit2: It also didn't occured to me initially that keeping support for the less accurate method while implementing more accurate ones might render the code hellishly complex and difficult to deal with as things progress. |
|||
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Tue Feb 20, 2007 2:38 pm Post subject: | |||||
|
|
|||||
Range Time Over. It's about calculating if sprites are skipped or not. anomie's register doc (link) has more details, see address 213E. _________________ savestate editor: vSNES latest public version
|
|||||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Tue Feb 20, 2007 2:58 pm Post subject: | |||
|
|
|||
Not to mention potentially slower.. if not directly, then because the code is too complex to easily optimise. Myself, I'm all for clean code, and if that means having to remove features that make it impossible, then so be it.. but I'd prefer a modular approach, which by-and-large seems to be what you're going for anyway. My suggestion is, take out whatever features inherently make the code hackish, and clean everything up, rewriting where you want.. then see what things you can put back in or let others put back in. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Feb 20, 2007 4:57 pm Post subject: | |
|
|
|
| Let's see ... other ideas for fullscreen mode ... How about a list of options under "Window Mode" : - "Windowed" - "Fullscreen" -- use windowed mode settings - "Fullscreen (scaled)" -- use windowed mode settings, but increase the multiplier as much as possible for the best fit - "Fullscreen (fill)" -- just fill the entire screen. Compensate for widescreen/portrait monitors? (the menu will always be visible because GTK+ makes it nigh impossible to hide the menu, you'll have to deal with that) This is all a good ways down the road. It's going to be a long time until v0.020 is out. Now, moving on to the other config stuff, I need : - input configuration window - cheat code editor - raster settings - debug console -> moving emulation settings here, end users should have no need to understand / toggle BG layers, as this isn't 1996 anymore when nobody could figure out tile layering Now, I have two options for how to design these. Separate windows: The good thing here is that I don't have to have the listbox on the left, so that means more room for stuff to be put on the window. I can also resize the windows to use just what's needed. One window: This just looks sharp. Everything all in one place is very nice, but I'd need to go back and extend libui to support windows inside of windows, which may or may not work well with GTK+ ... Broken stuff: - hardware scanline rasterer removed for simplification, will be moved to software - software filters need to be moved outside of SNES class - NTSC/PAL switch doesnt affect internal rendering at the moment - no fullscreen support - no linux input support - need sync control menu (sync to video or audio, maybe add this to the top of speed regulation menu, eg "No sync / Sync to video / Sync to audio") - need to fix speed controls (25,50,150,200% synced execution speed), will be much more difficult for video than for audio - need missing windows (input config, raster settings, cheat code editor, debug console / memory editor / tracer / emulation settings) and tools (log audio data, capture screenshot) |
|
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Tue Feb 20, 2007 5:03 pm Post subject: | |||
|
|
|||
I'm all for that. Although you have to decide if it's worth the extra work for a sharper-looking config. Separate windows is similar to other emulators too. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Feb 20, 2007 5:55 pm Post subject: | |
|
|
|
| /Agree with Jipcy For raster settings, you could skip having a separate window for this by adding a "Video Scanlines" drop-down with denominations 0, 25, 50, 75, 100. Sure, you lose a little bit of flexibility, but that reduces separate windows to input, cheats, and debug. Color control could be taken out completely. If people want to simulate their tv, they can adjust their monitor's colors. *flamesuit on* |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Feb 20, 2007 9:07 pm Post subject: | |
|
|
|
| I
like gamma control. Real TVs do not have linear gamma curves. Just as
most are not willing to manually scale their monitor horizontal width
and distort all other applications, you can't expect them to ruin their
colors just for an emulator's sake :/ The gamma adjust is free anyway. I have to convert bgr555->native format (right now only rgb565, but this will be needed for rgb555, rgb888, etc in the future). So, I have to convert anyway, may as well perform color adjustments. Right now, I'm not sure where I want all of this stuff. Do I want class SNES to be an "intermediate" piece of emulation that sits between the core and UI, or do I want it to be strictly part of the core and use SNESInterface for all of that stuff? Hmm. Ok, so I should go for separate windows, then? That will also remove the problem I have with fonts. I don't have a way to select specific fonts, as the names and sizes vary per OS. I could round things out somewhat, but not completely. This way I can just use the defaults for everything, and throw in one fixed-width font for the debugging stuff. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Feb 21, 2007 12:10 am Post subject: | |||
|
|
|||
I like Overload's gamma curve as well. But that wouldn't need a separate window like sliders. Not that brightness/gamma control is bloat... it's just an idea that went in hand with the scanlines. And personally, I could live with having an original and gamma adjusted choice. Last edited by FitzRoy on Wed Feb 21, 2007 12:28 am; edited 1 time in total |
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed Feb 21, 2007 12:26 am Post subject: | |
|
|
|
| I'm very disappointed that the Fullscreen modes are being replaced with a Windowed facsimile. Oh well. _________________ FF4 research never ends for me. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 21, 2007 12:39 am Post subject: | |||
|
|
|||
Please donate code to switch video modes with GTK+/X and I will be happy to add the support back in. I'm not conditionally adding it on one port. |
|||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Wed Feb 21, 2007 10:19 am Post subject: | |
|
|
|
| By the way, byuu, how far do you intend to take this api you're writing? (libui?) Do you intend to place it on your website as something like libco or will it stay something exclusively for bsnes? | |
Lurker
Joined: 31 Dec 2005
Posts: 145
| Posted: Wed Feb 21, 2007 9:16 pm Post subject: | |
|
|
|
| Byuu: Does the GTK function, gtk_window_fullscreen(), not work? |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Wed Feb 21, 2007 9:38 pm Post subject: | |
|
|
|
| It's there in the manual so I am pretty sure that is not byuu's problem. My guess is he is having problems switching between fullscreen and windowed or he just doesn't feel like working on it in favor of core related stuff??? | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 21, 2007 10:32 pm Post subject: | |
|
|
|
| I
am planning to simulate gtk_window_fullscreen() for the Windows port.
This is what Deathlike2 is unhappy about. I'm assuming he wants the
actual screen resolution to be selectable, as well as the refresh rate.
Fullscreen also allows page flipping / triple buffering. And that would
indeed be very nice if there were a single API out there that
automatically queued page flip requests and didn't lock your
application waiting on vblank. The only problem with gtk_window_fullscreen() is that it does not hide the menubar. In fact, thanks to GTK+'s "boxes" concept, I simply can't easily hide the menubar at all like I can with windows. So fullscreen will always have the menubar visible at the top. Good or bad, you can decide. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Wed Feb 21, 2007 11:05 pm Post subject: | |||
|
|
|||
Kind of defeats the point of "full" screen... Wasn't expecting linux support to result in so many sacrifices.
|
|||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Thu Feb 22, 2007 12:03 am Post subject: | |||||
|
|
|||||
Dude, I may not be pro-Linux here, but complaining about this issue when byuu wants portability is not helpful. _________________ FF4 research never ends for me. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Feb 22, 2007 1:20 am Post subject: | |||||||
|
|
|||||||
Just pointing out that the point of fullscreen is to make that external stuff not visible. So it probably qualifies as "bad." The ideal functionality is to able to toggle it on and off in fullscreen mode. I'm more disappointed and confused at GTK+ than in bsnes. How do these things get missed or added? Is it just "welp, it's fucked" or is there some lead developer that you can appeal to? |
|||||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Feb 22, 2007 3:04 am Post subject: | |
|
|
|
| There is many ways to init full screen XRanR or XVidMode, it's not a GTK issues. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 22, 2007 3:12 am Post subject: | |
|
|
|
| GTK+'s box system is the issue, so yes it is GTK+'s fault. Windows makes the menubar part of the window decoration, so you can easily add and remove it. No such luck with GTK+, where it's part of the client area. XRandR and XVidMode aren't going to hide the menubar for me. As if I knew how to use them, anyway. Like everything Linux, they're virtually undocumented. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 22, 2007 6:13 am Post subject: | |
|
|
|
| Alright,
if everyone really cares about it ... I'll try and special case the
Windows port to allow toggling the menu on and off, at the cost of
consistency. It'll just not be there on the Linux port. Similarly, it should be possible to add config file options for changing the refresh rate. Will that be sufficient for everyone, or is there really a pressing reason why the resolution should need to be changed as well? I still think everyone should stick to v018 or v019 for a while though. It will take a long time to get all the features moved over to the port rewrite. |
|
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Thu Feb 22, 2007 9:47 pm Post subject: | |
|
|
|
| The menubar is just another part of the widget hierarchy with the same visibility attributes that all the other widgets have. Are you using glade for the UI? You can just give the menubar a name, and then get the widget by name in your code, and then pass it to gtk_widget_hide() |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Feb 22, 2007 11:05 pm Post subject: | |
|
|
|
| If I hide the menubar, the container will still be there. Can I hide a container and have it automatically resize my window without leaving a gap there? | |
Lurker
Joined: 28 Jul 2004
Posts: 144
| Posted: Fri Feb 23, 2007 12:49 am Post subject: | |||||||||||||
|
|
|||||||||||||
|
You can alter the properties on the container for it - void gtk_box_set_homogeneous (GtkBox *box, gboolean homogeneous); void gtk_box_set_spacing (GtkBox *box, gint spacing); void gtk_box_set_child_packing (GtkBox *box, GtkWidget *child, gboolean expand, gboolean fill, guint padding,GtkPackType pack_type); The "homogeneous" property:
The "spacing" property:
The "expand" child property:
The "fill" child property:
Another thing you could do is the window is a container for the container, so you could change the widget hierarchy thusly:
to
|
|||||||||||||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Sat Feb 24, 2007 5:24 am Post subject: | |
|
|
|
| uh,
byuu, the address to your wip17 doesn't seem to work. Could you please
check it out? Also I know you are not concerned with emulating special
chips right now, but have you checked out the bs-x emulation in SNESGT,
it uses the BS-X bios and does a splendid job. as far as I know there
isn't any special graphical feats accomplished on the bs-x that aren't
part of the regular SNES hardware, so it's not like other enhancement
chips that alter gameplay. If it is to much work then forget about it.
But you have fixed certain other chips making, star ocean, sfa2,
megamanx, the sufami turbo and a whole slew of dsp games work, as well
as some bs-x games, so just thought you might take a look _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Feb 24, 2007 7:57 am Post subject: | |||
|
|
|||
BS-X
is partially documented, but there's far too much "I don't have any
idea what this does" parts, and I don't have a way to run my own test
code. If someone has a BS-X setup that I can use to run my own tests
on, I might be willing to purchase this from them and work on
supporting it. In the mean time, I'd do no better at guessing than
other emulators, and probably much worse since they most likely can run tests on the BS-X hardware.
I will try hiding the VBox I use for the menubar and see if GTK+ can compensate and resize properly. I'm hoping that it can, though that seems a little too easy, having implemented support for GTK+ listboxes and all -_-' |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Sat Feb 24, 2007 11:32 pm Post subject: | |
|
|
|
| Good news and bad news. Good news first. anomie just confirmed blargg's suggestion for the Toy Story fix, so that is permanently fixed. He also pointed out a tiny difference in the current code (kon gets tested even with FLG set), so I'll fix that as well. You won't hear a difference anywhere as no sane programmer would write KON with soft reset FLG on, sound output will be null either way as well. Bad news. Both blargg and anomie verified the fix for Koushien 2 (EDL reset) is not what the real hardware does. We'll keep looking into it, but I'll be reverting that fix sometime soon. I need to get a little clarification first, though. --- EDIT: ok, figured out how to hide the menubar in GTK+, and added support to libui. So fullscreen will by default not have a menubar, and vsync will allow it to work with smooth refreshes (though you still get audio distortion as usual, still one or the other). So the only difference is you no longer directly control the resolution and refresh rate for fullscreen, it just relies on your current monitor settings. The good news is that means instant switching between the two modes, the bad news is that CRT monitor users probably won't like running their monitors at 60hz. I'll probably add config file options for manually changing the refresh rate for the Windows port. |
|
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Sun Feb 25, 2007 8:41 am Post subject: | |
|
|
|
| am I the only person who finds the address to the latest public wip not working? _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Sun Feb 25, 2007 9:49 am Post subject: | |||
|
|
|||
It was probably taken down. Why do you want it? The configuration settings don't even work. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Sun Feb 25, 2007 1:02 pm Post subject: | |
|
|
|
| When a new public or private wip gets released the previous one gets removed. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Feb 27, 2007 9:16 am Post subject: | |
|
|
|
| Ok, more good news and more bad news. - I renamed bDSP to aDSP. - I modified aDSP to run in its' own separate thread, rather than be enslaved to the S-SMP. This means aDSP can now run at any clock speed, indepdendent of S-SMP. It now runs at 3.072mhz instead of 32khz, in preparation for subsample-accurate emulation. Note that only 1.024mhz is needed. I use 3.072mhz only for documentation (it's the true S-DSP bus clock rate), and at no speed loss. - I corrected a bug in aDSP for FLG/KOFF/KON processing, that has been confirmed by both anomie and blargg. - I reverted the improper echo buffer fix, so Koushien 2 is broken again, but my fix was not hardware accurate so it had to be removed. Koushien 2 gets added back to the buglist again, sigh. I at least simplified things a tad by removing the unnecessary echo_index variable. Now, the reason for the aDSP changes was so that I can add in blargg's S-DSP emulator. He's graciously allowing me to use his work, ala his NTSC filter. His is subsample accurate, and he is making phenominal progress with some truly innovative testing methods. I will allow users to choose which DSP core they would like to use, hence I modified aDSP so that the two can coexist. I also now have faith that I may be able to modify bPPU to run with threading, given how well modifying aDSP went. Hopefully this will also benefit ZSNES, as it will give another point of comparison for determining if new sound issues are due to a bug in blargg's DSP, ZSNES' core or bsnes' core. I will continue working with anomie's DSP as well. The downside to this is a slight speedloss, surprise surprise. Since the S-DSP is no longer enslaved to the S-SMP, there is additional overhead in maintaining a synchronization counter between S-SMP and S-DSP. It's roughly ~4% slower now (mainly because the S-SMP runs at such a high clock rate that has to constantly sync test with S-DSP), but I've been meaning to unenslave the S-DSP for a long time now, so I believe it is worth it. The last thing to note is that blargg's approach will undoubtedly be a lot slower than anomie's sample S-DSP core, by virtue of running at 32 times the resolution. How that will pan out in bsnes is currently unknown, but I suspect bsnes has enough overhead as it is with its' S-CPU and S-PPU cores so as to make it not too noticeable. And this will officially put the S-PPU as the last non-cycle accurate piece of core SNES emulation ... |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Tue Feb 27, 2007 1:43 pm Post subject: | |||
|
|
|||
Whow. Looking very promising
|
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Feb 28, 2007 8:19 am Post subject: | |||
|
|
|||
Ok, I keep getting this warning with gcc:
-Wno-conversion -Wno-implicit -Wno-traditional combined can't turn it off. I've read: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options.html And found no way to disable it. Therefore, unless anyone knows which option I should be using, Linux/gcc port is getting -w. Yes, the evil disable all warnings flag. Like hell if I'm letting GNU hippies yell at me because I use implicit conversions without explicitly casting. This is a feature of c++, not a bug. |
|||
Hazed
Joined: 07 Feb 2006
Posts: 79
| Posted: Thu Mar 01, 2007 1:02 am Post subject: | |
|
|
|
| Implicitly
converting from a super-accurate format (double) to a super-inaccurate
format(uint16), like many features of C++, sounds a great way to shoot
yourself in the foot if you don't know what you're doing. Luckily,
programmers who do know what they're doing have a convenient way to
soothe the compiler's fears: the explicit cast. Surely the most pragmatic thing to do would be to just add the explicit casts where gcc wants them, and then leave warnings turned on so you'll have, well, warning of other impending doom that might arise? |
|
New Member
Joined: 09 Jul 2005
Posts: 6
| Posted: Thu Mar 01, 2007 6:08 am Post subject: | |
|
|
|
| Technically,
uint16 is more accurate than a double in that it most certainly
represents the number you think it does. Also, one can safely compare
uint16s to each other, whereas one must take extra care around
floating-point representations due to various architecture quirks. I agree, though -- this is what explicit casts are for. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 01, 2007 7:00 am Post subject: | |
|
|
|
| If
explicit casts were required by the language, it would be fine. The
compiler wants to force me to either kill all warnings, or explicitly
cast everything, and I'm not cool with that. GNU is thankfully not in
charge of the c++ standard, and they should keep their warnings in line
with said standard. Anyway, for the particular code in question, I know what I'm doing and a uint16 to double cast is fine. It's for my audio sample interpolation filters. My point is more out of principle than reason. The code in question would require about 60 extra int->double casts, and there's no real reason I should have to do that. GCC just likes to be annoying. |
|
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Thu Mar 01, 2007 1:26 pm Post subject: | |
|
|
|
| Just
to get this straight, you mean the principal of having to type all that
stuff out when it should just work without complaining, right? What you said is a little confusing because I can't tell whether or not you're implying that the 'extra' casts would have an effect of the code's efficiency (which they shouldn't as they would just be replacing the implicit ones) I agree that you should be able to turn the warning off; if you're going to discern different types of warnings in your compiler at all, and it's rather obvious to do so, there's no reason to exclude certain types from being disabled independently of others. Last edited by Verdauga Greeneyes on Thu Mar 01, 2007 4:19 pm; edited 1 time in total |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Thu Mar 01, 2007 4:06 pm Post subject: | |||||||
|
|
|||||||
Just because it's a feature doesn't mean it's not a stupid one.
But there is: it sounds like a bad idea. You have one implied (=hidden) rule: "this is valid code, ignore it". If you want to make the source more understandable then you'll need to include that rule in one way or another anyway. You need the verbosity. </IMO> _________________ savestate editor: vSNES latest public version
|
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 01, 2007 5:01 pm Post subject: | |||||
|
|
|||||
Yes. Most of the "stupid" things I do are out of principle. I wouldn't even mind if there were a way to turn off this warning. I'm absolutely not the type of person to just blindly follow rules for no reason. Half the time they are good rules and I eventually change my mind, half the time they really are stupid and need to be changed / ignored.
And this is why I work alone. I love the level of control so as to disagree with another, and still do things my way anyway ;) Ah well, sorry to bug you guys about this. Was hoping someone knew the -Wno flag I needed. Back on track: I fixed a serious bug with the lui port in Linux, so that's working again. I also readded the speed throttling code, and now the system.speed_* config file options take percentages rather than audio samples rates. Also, audio.frequency in the config file sets your base playback rate now. I'm debating whether I should add a master_frequency value and apply resampling to it, for the shitty onboard cards out there that lock up with arbitrary sample playback rates (Windows has kxMixer, so it should accept any playback frequency rate by default). |
|||||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Thu Mar 01, 2007 6:08 pm Post subject: | |
|
|
|
| to
each his own. I guess the way I figure you have your way and method,
and the results have been pretty good thus far. Keep up the good work. _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Fri Mar 02, 2007 7:05 am Post subject: | |||||
|
|
|||||
PS:
Right, you have enough fans who can do that for you. _________________ savestate editor: vSNES latest public version
|
|||||
Regular
Joined: 30 Jun 2005
Posts: 206
Location: USA
| Posted: Sat Mar 03, 2007 12:36 am Post subject: | |||||||||
|
|
|||||||||
|
As
far as I know, the standard only requires that diagnostics be generated
for some kinds of erroneous code, and that a program be generated for
valid code. What else a compiler prints is outside the standard. I too have a problem with warnings whose solution causes more problems than the warning solves. As an example, I've used a compiler with an optional warning for any possible loss of bits, i.e. 32 bit int->16-bit short, unsigned int to int (and vice-versa), etc. The required casts themselves become a source of bugs, since the types involved might change in the future but the cast will stay the same. In your case, where you're doing calculations on a sample value and then writing it out, a semi-safe solution is to use a typedef:
But this still isn't very safe, since it's a C-style cast, so this would silently accept even a pointer, yielding its raw bits.
OK, so we use static_cast<>:
That's pretty verbose and ugly. On the other hand, if a compiler warns of precision loss only in cases where there could easily be unintended truncation (double/float->int, int->char), then it might be worth adding the casts. It would be nice if a functional-style C++ cast could only perform static_cast<> conversions, rather than reinterpret_cast<> as well, as that would allow this to be safe and concise:
The main problem I've encountered is not compiler warnings themselves, but people who demand that code compiles without generating any. If these warnings were really that useful, such conversions would not be implicit in the first place. |
|||||||||
Romhacking God
Joined: 28 Jul 2004
Posts: 1899
| Posted: Mon Mar 05, 2007 1:19 pm Post subject: | |||
|
|
|||
You got it. THAT is the real problem. Warnings for any language should be treated as an advisory. What I mean by that is take a look at the warning, understand what it's telling you and why it's happening. Then make an intelligent decision on whether or not something needs to be done about it. Often times you may have done something ON PURPOSE in your code for design reasons that generates a warning. WHY should you change it just to make the warnings go away? That's silly. There is no problem in your program in that case. It is a false assumption to think that code that generates no warnings is better than code that does generate a warning. _________________ TransCorp - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations. ROMhacking.net - The central hub of the ROM hacking community. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Mon Mar 05, 2007 4:07 pm Post subject: | |
|
|
|
| Ah, I'm in complete agreeance. You guys have a much more eloquent way of expressing the base point I was getting at. Here, gcc is giving me a useless warning that I know will never cause me issues. But it doesn't only give me the warning once, but several times in a row, spamming an entire console window, every single time I ever make any chances to that specific object file. And if I release a version with this warning, people will complain that my software is somehow defective for triggering warnings. There's no reason for there to not be a specific warning disable flag for this issue. As I tend to do most of the annoying things I do out of principle, I'm not going to just go with the mass-accepted "just change it to fix the warning" line. No, the problem isn't with my code, but with the compiler. The standard explicity supports what I'm doing for a reason. I trust the standards-body over the GCC authors. Moving on though, I've rewritten libkeymap to take a more standard approach (keysyms are constants rather than variables, remapping done in realtime rather than startup), and created translators for most of the keys on both the win32 and GTK+ ports. I now need to hook this into the Input class, and Linux users should finally have input support. The exact details are sketchy, in that GTK+ tends to send key messages regardless of which control on a window is active, whereas win32 only sends when no control has focus. I'll need to unify the behavior, but for now, the main output window has no controls anyway so it's not relevent for bsnes at the moment. --- Ok, have a real fix for Koushien 2, courtesy of blargg. This one is an approximation. Basically, the S-DSP fetches ESA at clock 29 for use on the next sample. That value isn't used until clock 22 on the next sample. Right now, anomie's core allows ESA writes to take effect immediately. By using a close approximation, we can cache ESA after echo buffer write, and use the old value before. This one-sample delay is a lot closer to hardware timing, and indeed is enough to fix Koushien 2. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Tue Mar 06, 2007 5:20 am Post subject: | |||
|
|
|||
Great! Thanks blargg. |
|||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Mar 06, 2007 10:15 am Post subject: | |
|
|
|
| Ok, added blargg's changes. Played four levels, seems to be working fine. Posted a new WIP with this change. I also replaced libkeymap with a new implementation of it, this one is designed to work with window key messages, meaning we can finally have input configuration for GUI events and such in the future, and Linux users will finally have input support shortly. Still not now, though. Input on Windows might be a little sketchy, as well. Just need to create an InputWM class for Linux. |
|
Regular
Joined: 01 Mar 2006
Posts: 288
Location: UTSC120
| Posted: Tue Mar 06, 2007 1:12 pm Post subject: | |||
|
|
|||
Looks like your site is down at the moment P.S. Is this new WIP public or private? |
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Tue Mar 06, 2007 3:27 pm Post subject: | |
|
|
|
| We love you blargg. _________________ Watering ur plants. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Tue Mar 06, 2007 4:57 pm Post subject: | |
|
|
|
| Yes, site down. Appears to be something specific to subdomains. Not much I can do about it, but be grateful I have free hosting. This one's private because it's pretty broken, but I'm getting close to good enough for another public one. I want to at least have Linux input working for that first, for all two people that use bsnes/Linux :) --- blargg's subsample-accurate S-DSP merged into bsnes, and working. Sounds really good. I'll try and get a public WIP out with both and WAV recording so everyone can have fun comparing, heh. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Mar 07, 2007 10:27 am Post subject: | |||
|
|
|||
Ok,
this is a very important WIP release. Note that this file is rather
large, please mirror it if you must link to it elsewhere.
Included are two executables: bsnes_adsp.exe - This version uses anomie's S-DSP emulator, clocked at 32khz bsnes_bdsp.exe - This version uses blargg's S-DSP emulator, clocked at 1.024mhz Please note that blargg's code is experimental and in-progress. That said, I have been unable to find any errors with it so far. I hope I haven't missed anything blargg wanted me to do before release. Everyone, please give your thanks to blargg for creating this emulator and allowing me to use his code :) This day marks an important milestone, at least in bsnes, possibly in the SNES emulation scene: the addition of a subsample-accurate S-DSP emulator brings us one major step closer to the most faithful SNES emulation that will ever be possible. Excepting bugs, this now gives us bus-accurate S-CPU, S-SMP and S-DSP cores. It is not possible (nor desirable) in software to get more precise than bus-level accesses. The only core component remaining using an older, less faithful approach is the S-PPU[1/2], and is not so coincidentally the source of the only remaining bugs in bsnes. This will very likely be the biggest leap forward in accuracy that will ever be seen for S-DSP emulation from this date on. The old win32 interface is now completely broken, so I am forced to distribute using lui. As such, I've fixed the NTSC/PAL mode switches, and added software video filter selection to the UI. Any configuration changes that are not in the menu will have to be done via the config file for the time being. I have also added the log audio data option back to the misc menu. If you are not able to get 60fps in bsnes, or would like to analyze the audio output between adsp and bdsp in another program, you can use this option. Also, I'm aware of the lui-specific issues, such as audio repeating when entering menus. lui is still a work in progress. Please test all of the games you can, and look for subtle audio differences and the like. Bugs, improvements, whatever, would be very useful to know. Please keep in mind that every commercial game ever released was tested by both FitzRoy and tetsuo55, and there are currently zero known problems with anomie's S-DSP emulator. Also note that blargg's emulator will be slower, by nature of being more low-level. I'll leave the decision on which core to enable by default to you guys. Eventually, I'll have polymorphism fully functional, and this will be a runtime-selectable option, and not require two separate builds. But still, we unfortunately have to pick one to be the default setting, which I hope does not offend anyone :( I'm very appreciative and in debt to both anomie and blargg for their help with S-DSP emulation. They have both done a very large service to us all by creating these cores, so I thank both of them again for all their hard work, and for allowing me to use their work in bsnes. |
|||
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Wed Mar 07, 2007 11:44 am Post subject: | |
|
|
|
| Thank you Blargg!!! thank you Byuu!!! Eventhough controls are completely fubar for me in this build (whenever i press a button on the keyboard ik gets repeated like 8 times(winxp sp2)) The sound with blarggs core sounds exactly like my snes!! (well my snes doesnt crackle )The minute differences in sound i reported before are now gone. I suggest you default to Blargg's core as that one is being emulated most accurately. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Mar 07, 2007 4:29 pm Post subject: | |||
|
|
|||
Yes, thank you blargg for your great research and RE work :D To be honest, I can't detect a clearcut difference where I can say "yeah, there you have it, right there. Obvious difference" *Note that I'm not doubting you if you say it's much more accurate. And yes I know, accuracy is not always visible to the end-user but I'm all for it anyway. Then again, I haven't had/played a real SNES for years. So I wouldn't exactly call myself a connoisseur. Perhaps testuo could post a wav where the difference is most noticable for him. byuu, how much of a speed hit do you estimate this sub-sample accurate core cause? Right now, there are times where I can't reach 60/60fps, even with frameskip set to 9 with wip23-B...something that does not occur with wip23-A If you don't mind either way, perhaps for now the default should be set to the old core...Or just go with whatever Fitzroy suggest, democracy style :P small edit above * Last edited by Snark on Wed Mar 07, 2007 4:53 pm; edited 3 times in total |
|||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Wed Mar 07, 2007 4:34 pm Post subject: | |
|
|
|
| Accuracy is your goal, so I say go for accuracy until you can make things modular
Great development, it's very impressive how close we've now gotten to
perfect emulation (or as perfect as feasible anyway). Are you still
planning to take a step back after you 'finish' libui to see if you can
clean up your code? Or have the recent advancements inspired you to
work on sPPU? (personally, I think you should only start on that when you feel the bsnes codebase is ready for such a significant change) |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Mar 07, 2007 5:01 pm Post subject: | |
|
|
|
| I
was also unable to perceive a difference between anomie's and blargg's
DSP cores. I regret not thinking of this sooner, but I shouldn't have
labeled the binaries. It would've been a lot more fun to rule out the
placebo effect. Sigh. Unfortunately, I cannot gauge the speedhit for blargg's S-DSP. My framerate display was only in the old UI port that no longer compiles. I don't care to fix it, so I'll need to add the framerate display to the lui port, then I can tell you how much of an impact it has on performance. I still have a long way to go with the new port, the hardest part will probably be sticking windows inside of windows for GTK+. I believe I get lots of assertion failures when I try and reparent windows like that, but it's needed to get a nicer configuration panel. Once I get it all cleaned up, I still want to work on cleaning up the codebase. Nothing major really, just refactor all memory to the 'memory' class so that eg DSP doesn't have to request memory from the SMP (in reality, it works the other way anyway), etc. Then I also want to move all the video filtering stuff out of the core. I don't see a reason why the core should do stuff like this that is unrelated to SNES emulation, and it'd be a cool pet project to be able to build each core component by itself. Perhaps then I can ease up my licensing requirements some. A shame it's impossible to release under PD, yet still bar the code or derivatives from ever being relicensed under GPL. I shudder at the thought of my work being forever locked into that license. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Wed Mar 07, 2007 5:13 pm Post subject: | |||||
|
|
|||||
Well, nothing's preventing another zip release with unlabeled version just for the heck of it. But aside from the hearable or un-hearable differences, the fact is it's more internally precise and that's worth its weight in gold imo.
|
|||||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Wed Mar 07, 2007 6:44 pm Post subject: | |||||||
|
|
|||||||
Not to mention the fact that the inaccuracies make themselves perceptible instantly if you know what to look for (I always tend to start with Chrono Trigger, and then go to a few other games I know of that have notoriously hard sounds to emulate correctly). byuu, I'll keep testing blargg's sound emulator against anomie's to see if I can find anything that doesn't seem to stack up or seems odd. I'll also say that if blargg's sound core is implemented into zsnes, it'll probably sound 1000 times better than it does right now. Last edited by Talbain on Wed Mar 07, 2007 6:59 pm; edited 1 time in total |
|||||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Wed Mar 07, 2007 6:46 pm Post subject: | |
|
|
|
| I'm really glad to hear the progress on your emulator! I'm glad you haven't burnt out and stopped working. A couple questions: - Can you remind me if you ever fixed PGO compiling? I remember that broke a while back. - Also, which parts of bsnes use/require libco? Following the progress of your emulator make me want to learn how to program. Overall, you seem to prefer to work on the emulation-related aspects of your program more than the interface/GUI. And, obviously, your priority with bsnes is to make it easy to compile on multiple platforms and have a consistent interface. However, doesn't this limit what you can do on each individual platform? For example, isn't it possible to achieve more* by writing a custom Direct3D interface or something like that? What I'm really saying here is that at some point in the future, I think it would be cool to learn how to program C/C++ and the DirectX API so that I could make a very cool Windows interface and video output engine, etc. *I only have a vague understanding of what I mean by more. After you get your current to-do list finished, do you plan on starting in on the new PPU, or do you plan on working on other hardware (special chips)? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|
Hazed
Joined: 28 Jan 2006
Posts: 93
| Posted: Wed Mar 07, 2007 7:25 pm Post subject: | |
|
|
|
| I
don't see much left for byuu to work on, except special chips. I hope
there is a way of improving the current ppu to work correctly with
uniracers. Optimizations, of course, would be great, since a 2.9 GHz P4
is still too slow . |
|
Hazed
Joined: 29 Jul 2004
Posts: 86
Location: USA
| Posted: Wed Mar 07, 2007 7:58 pm Post subject: | |||||
|
|
|||||
Perhaps you already know about this, but:
|
|||||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Wed Mar 07, 2007 8:09 pm Post subject: | |||||||
|
|
|||||||
I know. The SPC sounds fine as far as I can tell; I haven't tested a few of the wackier games like Uniracers yet though, so I'm holding out reservations until I see what's actually released. I'm looking forward to the release that sees the implementation of blargg's sound core though, in both bsnes and zsnes.
|
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Mar 07, 2007 9:17 pm Post subject: | |||
|
|
|||
|
PGO
is still broken, and this one I can honestly say is not my fault, but
the compiler's. The error even says as much. So far, S-CPU, S-SMP and
S-DSP require libco. S-PPU is the last piece that eventually will, but
currently does not. I already have a D3D renderer. My limitations are
in customization to controls. Eg on the old bsnes, my memory editor was
able to subclass an editbox control. I can't do that with GTK+. There
may be ways to get the same effect, but it'll be a completely different
interface. One thing I'm considering allowing is for others to develop
their own UIs, provided that they do not use the name bsnes, and they
do not modify the core (don't want hacks being added in). All ideas at
this point in time. I'd like to do the S-PPU next, but I don't know if I can. I will wait and see how much faster a Core 2 Duo is compared to my Athlon 3500+. If I think I can push at least 30fps with a cycle-renderer, I'll try it, if only for the sake of utter completion.
I'm not sure why we're still calling it an SPC700. pagefault is referring to the S-SMP, they are using _Demo_'s version of this. Typically, the S-SMP runs a program that writes to the S-DSP to play sound back. So long as that program works correctly, sound output should be fine. I can't really speculate on _Demo_'s S-SMP emulator, but I believe it is an opcode-based emulator. I could very well be wrong. If it is, then it will lose the benefits of the precise interation between the SMP and DSP on a cycle level. This isn't really a big deal, and blargg's filter still has a lot of new findings (pitch modulation, echo buffering, etc) that seem to make up the bulk of the improvements everyone is noticing in Chrono Trigger et al. As ZSNES is currently using an even older DSP core than anomie's, blargg's should be a huge leap forward. I doubt most people will be able to tell the difference in sound between the two emulators when we are both using his DSP emulator. The difference will likely be about the same as the very real variance in sound you get every time a sound effect plays on a real system, for very similar reasons. In fact, ZSNES will sound better on Vista, as I have no plans to rewrite my DirectSound driver, and apparently Vista emulates DirectSound in software, so you have forced audio resampling. Apparently someone at Microsoft didn't understand why they put the 'Direct' in 'DirectX'. I really don't know what the S-SMP has to do with Uniracers' mid-frame OAM writes, but admit to being almost tempted enough to not reply, just so I could watch how the discussion continued to evolve :P --- EDIT: I want to start reducing my dependency on my custom libraries in my code. One step is to use <stdint.h>. Unfortunately, Microsoft hasn't had the time to implement this eight year old standard, so I cannot simply use it directly. Should I attempt to implement the types I need myself in my own library file, or should I just start referencing stdint.h in my code, and add documentation to the src folder instructing Visual C++ users to seek out free implementations of stdint.h to put in their include folders? |
|||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Wed Mar 07, 2007 10:51 pm Post subject: | |
|
|
|
| byuu, I've always been curious, is the SNES's sound processor that hard to emulate? What exactly is it that makes it so much (seemingly) harder to emulate than say... the Saturn processor, or the PSX, or the WSC, or GBA, or NES, or Game Gear, or Genesis? I mean, I think until I heard blargg's sound core today, I don't think I've ever heard an accurate SNES sound processor. Is there just a lack of documentation or intense complexity to it? Or does it do something strange that none of these other sound processors do? | |
Seen it all
Joined: 03 Jan 2005
Posts: 2324
Location: Germany
| Posted: Wed Mar 07, 2007 11:06 pm Post subject: | |||||||
|
|
|||||||
Can't you include such an implementation with the source code?
As far as I remember it was used in the manual... "5A22" was definitely used - well, it's a bit more specific than "S-CPU". EDIT: Anti Resonance calls it SPC700 (link), even though it seems to say "S-SMP" on the chip. _________________ savestate editor: vSNES latest public version
Last edited by creaothceann on Wed Mar 07, 2007 11:21 pm; edited 1 time in total |
|||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Wed Mar 07, 2007 11:19 pm Post subject: | |||||
|
|
|||||
I'm the wrong person to ask, I've never attempted to personally emulate the S-DSP.
I can, but it will choke on reference to <stdint.h>, as such a file will most certainly not be in the compiler's include path. The user would have to manually move the file to their compiler's include folder. |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Wed Mar 07, 2007 11:48 pm Post subject: | |||
|
|
|||
It is relatively sensitive perhaps? Note that some games explicitly rely on such timing (not that other consoles wouldn't have this issue, but it is rather prominent on particular notable games). Besides, the documentation has been lacking when the DSP/SPC has been referenced. You can search the board, and the Snes9x board and you will come to the same conclusion. _________________ FF4 research never ends for me. |
|||
Regular
Joined: 30 Jun 2005
Posts: 206
Location: USA
| Posted: Thu Mar 08, 2007 12:18 am Post subject: | |||
|
|
|||
The DSP in the sound processor (separate from the S-SMP, an 8-bit CPU also in the APU) performs heavy signal processing using complex algorithms. We don't even know how fast it runs internally. The DSP itself is probably another processor and ROM running at a fairly high clock rate. Since we don't know this code, we have to figure out what it does by poking at it and seeing how it responds. This makes it a lot more complex to figure out. The S-SMP CPU that's in the APU runs at around 1024000 instruction cycles per second. It can access the DSP during any one of these, so we need to know what the DSP does every one of these clocks. Fortunately, it uses a pattern of actions that repeats every 32 clocks, so we only need to reverse-engineer 32 individual clocks. The main units of the DSP are 8 independent voices and an echo unit. The voices do many things in a particular order internally, and several things only in some cases, so it's fairly difficult to determine exactly when it's all occurring. The DSP has about 110 registers that the SMP can access, so the times that each of these are read/written have to be known for accurate emulation. I've pretty much determined all the timing and actions performed each clock, summarized in the link. This lists the various things performed, along with what DSP registers are used and what memory accesses are made. S-DSP Timing Summary The timing grid on the left shows how everything fits together. Voice processing is significantly overlapped between successive voices. If the table doesn't make much sense, here's an example: on clock 22, the following actions occur in order: - Voice 0 performs step V3a (calculate pitch) - Voice 6 performs step V9 (update ENVX, perform gaussian interpolation) - Voice 7 performs step V6 (OUTX-related stuff) - Echo performs step E22 (read right echo sample, use FIR1 and FIR2) |
|||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Thu Mar 08, 2007 12:31 am Post subject: | |||
|
|
|||
and just because these guys are making it extremely accurate doesn't mean that we haven't had emulated SNES sound for awhile. What I'm trying to say is, who says those other systems have accurately emulated sound yet? Saturn emulation is barely anywhere at all at this stage. _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Mar 08, 2007 2:57 am Post subject: | |
|
|
|
| byuu:
ZSNES will not sound better on vista, it's just a different way of
accessin the card and making it easier to the user. And _Demo_'s core
is now cycle based after a lot of overhaul. _________________ Watering ur plants. |
|
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Thu Mar 08, 2007 3:28 am Post subject: | |||||
|
|
|||||
You did all that by testing. o.O Wow. Heh. Thanks for all the info blargg. Helps to understand a lot of why it takes so long. Panzer88, yes, but I'm referring to accurate sound, and for the most part, there are emulators out there with accurate sound for the respective systems I've mentioned (Kega, Mednafen, VBA, ePSXe, pSX, SSF, Magic Engine, MAME, et al). Some are even so far along as to be able resample (as an option) the sound and make it sound better than the original machine could. For as long as I can remember, the SNES emulators have never had accurate sound cores. That isn't to say they haven't progressively gotten better either. I'm not here to deride anyone's work, in fact, I think the very fact that they're attempting to make such improvements to their emulators just proves how skilled and dedicated these people are. Also, if you think Saturn emulation is "barely anywhere at all," clearly you haven't been to ngemu recently. Even Dreamcast emulation will likely be a new reality once nullDC is formally released. It's already getting better speed and runs more games than Chankast. Emulation is moving, and at a faster pace than ever before, and I applaud them for their work. I'm simply here because I want to help with sound more as a tester, because realistically that's the most I can do; I've studied sound, music, and the theory of sound and I've become very adept at telling even slight differences. The fact that Chrono Trigger (and a few other games) sound correct in my recent tests with blargg's new sound core is delightful to me, it made me giddy even. As a result, I became increasingly more interested in more of the background work that goes on in all of this. As such, I was merely stating that I've heard more accurate emulation on other newer emulators, and it somewhat bewildered me as to why. With blargg's explanation, I now know. Thanks for the explanation. Sorry for my long-winded reply. |
|||||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Mar 08, 2007 4:41 am Post subject: | |||
|
|
|||
Welp, I can't perceive any differences between the two, which is good. Also, somebody asked what the speed hit was between the two. It's interesting that my situation is unique enough to estimate this. On .019, which uses anomie's and has an fps counter, I get no lower than 60 on EWJ2's accordian screen (regulation off btw). On blargg's new dsp, I get slight intermittent crackles, which tells me its dipping to about 58 at most. So the speed hit is about 3% on my architecture. That's a really small tradeoff and I don't see why you should need to keep anomie's in addition to blargg's. I'll pin my own hopes on you getting that bit of speed back with optimizations. It's just my luck that I'd be dipping to 59 on certain scenes. I knew I should have gotten the e6400... By the way, I don't know if you're aware of this, but "log audio data" creates two wav files for some reason and one of them is useless. Could be a bug. |
|||
Inmate
Joined: 21 Aug 2005
Posts: 1345
Location: Australia, Brisbane
| Posted: Thu Mar 08, 2007 6:54 am Post subject: | |||
|
|
|||
what you hear and how it is produced is two different things... they can use hacks to get the sou nd to sound right... does that make it accurate? yes it sounds like it would if it was played on a real console... but no it is not accurate in the sense of coding... there should be no need for hacks. _________________ Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig ddr2 800 ram DC, 200 gig sata2 hdd, x-fi xtreme sound, nvidia geforce 8800gt 512mb pcie, windows xp home sp2, Thermaltake 750watt toughpower power supply. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Mar 08, 2007 6:56 am Post subject: | |||
|
|
|||
That's one of the first intelligent things I've seen you say. Congratulations. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Thu Mar 08, 2007 7:08 am Post subject: | |
|
|
|
| in
bsnes wip23 in Donkey Kong Country III, I noticed something odd and was
wondering if someone could confirm that it is like this on real
hardware also. NSRT v3.3 - Nach's SNES ROM Tools ---------------------Internal ROM Info---------------------- File: Super Donkey Kong 3 - Nazo no Krems Shima (J) (V1.1).smc Name: SUPER DONKEY KONG 3 Company: Nintendo Header: None Bank: HiROM Interleaved: No SRAM: 16 Kb Type: Normal + Batt ROM: 32 Mb Country: Japan Video: NTSC ROM Speed: 120ns (FastROM) Revision: 1.1 Checksum: Good 0xB8F9 CRC32: 5B337FB6 MD5: D0CEFE1D11D0F84F98227A549E6E93B6 --------------------------Database-------------------------- Name: Super Donkey Kong 3 Country: Japan Revision: 1.1 Port 1: Gamepad Port 2: Gamepad Genre 1: Platform Genre 2: Side Scrolling Ok this is the bug, at the very beginning when Kiddie and dixie are spinning the xylophone. Look at Kiddie's eye on the left, every few frames, part of it flashes an aqua color. Does this happen on real hardware? _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. Last edited by Panzer88 on Thu Mar 08, 2007 8:08 am; edited 1 time in total |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Mar 08, 2007 7:26 am Post subject: | |
|
|
|
| I don't have my snes hooked up at the moment, does the bug also happen with pal and usa versions? | |
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Thu Mar 08, 2007 7:43 am Post subject: | |
|
|
|
| yes
it happens in this us version as well, not sure about the pal yet. It
seems to look like some compression of filtering bug rather than the
emulation. NSRT v3.3 - Nach's SNES ROM Tools ---------------------Internal ROM Info---------------------- File: Donkey Kong Country 3 - Dixie Kong's Double Trouble (U) [!].smc Name: DONKEY KONG COUNTRY 3 Company: Nintendo Header: None Bank: HiROM Interleaved: No SRAM: 16 Kb Type: Normal + Batt ROM: 32 Mb Country: USA Video: NTSC ROM Speed: 120ns (FastROM) Revision: 1.0 Checksum: Good 0xB28C CRC32: 448EEC19 MD5: 120ABF304F0C40FE059F6A192ED4F947 --------------------------Database-------------------------- Name: Donkey Kong Country 3 Country: USA Revision: 1.0 Port 1: Gamepad Port 2: Gamepad Genre 1: Platform Genre 2: Side Scrolling here is a screen print, I don't know how to do screencaps in this build of bsnes, nor do I know how to turn off the standard filtering (I'm not using any of the extra filters) http://i163.photobucket.com/albums/t282/Numonohi_Boi/Kiddy.jpg _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Thu Mar 08, 2007 7:55 am Post subject: | |
|
|
|
| No way that's a bug. I don't even have to check. | |
Zealot
Joined: 11 Jan 2007
Posts: 1181
Location: Salem, Oregon
| Posted: Thu Mar 08, 2007 8:07 am Post subject: | |
|
|
|
| my
apologies, if it hasn't already been done we should create a list of
bugs that exist on the hardware so that people can check those first,
I'm sure a lot of you testers already know many of them, but I'm sure
it would be helpful. Just a thought _________________ I have a Sega Genesis XBAND Modem and I'll send it to someone if you can do something with it. |
|
Regular
Joined: 04 Mar 2006
Posts: 301
| Posted: Thu Mar 08, 2007 8:21 am Post subject: | |
|
|
|
| The best thing would be to have something similar to mameinfo.dat, with all the game info and known game bugs. | |
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 08, 2007 9:51 am Post subject: | |||||||||
|
|
|||||||||
|
Good
news, v0.019's settings configuration panel is possible to implement in
GTK+. I figured out how to embed a window inside another. This is technically not supported by the API, as the authors severely underestimate the worth of such a direct function, however I was able to rig up a cheap hack to pull off the same thing mostly transparently. What I did was create a GtkFixed window called Panel. Then I added Panel::attach, which takes a Window as a parameter. This function reaches inside the referenced window, and grabs its' master container that encapsulates the entire window and its' menubar, and reparents this child widget from one window to another. It also makes sure the owner window is hidden, as there'd be no point in showing an empty window. The Panel class keeps track of multiple calls to attach and detach, and can reparent windows back to their owner as needed. So, with this, I can reimplement my listbox + panel style GUI.
Nach doesn't like databases, mine will probably be removed when NSRT starts adding PCB IDs to ROM headers.
Nah, you really shouldn't need such a powerful processor. It's my fault for putting code integrity completely over speed. I should be able to get back a couple of recent slowdowns. Since that audio sync method failed, I can add back in the CPU<>SMP drifting. Unfortunately, the SMP<>DSP sync will still take a speed hit, as before I had anomie's core enslaved to SMP. Much faster that way, but I just don't feel right implementing enslavement in an emulator, regardless of whether or not it has an effect on the end result ...
Probably a UI issue calling clicked() twice or something. I've been running into some problems of when exactly to call the clicked() function for menu actions. I'll look into it.
Ah, I figured bypassing the resampling algorithm of DirectSound in Vista would help. Good to know that it will be less work for me. Hmm, may I ask why you chose to make both the CPU and SMP cycle-based? The SMP is easily enslavable to the CPU for a significant speedup (your CPU no longer has to be cycle based -- so long as the SMP is, they will communicate at cycle-level precision), this is the method TRAC used. The end result is the same, and I'm sure your reason is not to create a "pure" implementation from a hardware standpoint (irrelevent to accuracy) at the cost of speed, given your choice of x86 assembler for the language ... At any rate, congratulations. I'm glad you are improving this stuff, even if end users don't care about it, as it's very important for historical preservation. If anyone can pull off what I've done and fast, it's you guys. That should give you roughly the same implementation-level accuracy of bsnes (though we'll still obviously have different bugs in our cores), so you can reclaim all 30 of my users. I'll have to wait and see your finished result, but it sounds like I can go ahead and work on that cycle-based PPU, since ZSNES can take my current place. Not to mention, nobody can even run bsnes anymore, not even with Core 2 Duos, apparently -_-; Unless of course, you've already implemented a cycle-based PPU too ... Looks like we're finally moving SNES emulation as a whole from the NESticle days to the Nestopia days. I'm in your debt for this. |
|||||||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Mar 08, 2007 3:01 pm Post subject: | |
|
|
|
| It
was just easier for us to make everything cycle based than to do it
elsewise. I don't think zsnes will replace bsnes completely there are
lots of quirks that we don't emulator or I have no idea if we will get
around to emulating. From a developers standpoint bsnes is better to
work on than ZSNES because it is closer to the real thing and you would
get similar results by using that. Each emulator will have a special
place to do something. We also have an option to use blarg's S-SMP or
_Demo_'s it's a compile time option. _________________ Watering ur plants. |
|
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Thu Mar 08, 2007 3:03 pm Post subject: | |||||
|
|
|||||
Supposing that hacks could be used, there certainly haven't been any that I've heard that sound accurate. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 08, 2007 4:22 pm Post subject: | |||
|
|
|||
Ah, well I can definitely understand making things easier :) I'm also not so sure you won't be able to catch up on the quirks. Many of the ones I've added were done so because they fixed games, and the others only a handful of us care about. Since you'll likely be doing the same thing, that shouldn't be a problem. I think you'll be pleasantly surprised with how bugs start staying fixed with these new cycle cores, though I still strongly recommend regression test ROMs. Highly underrated, those. Nonetheless, I'm more than willing to give you a hand if you get stuck on anything. Again though, I have a serious problem that bsnes won't even run on a Core 2 Duo anymore. The biggest drain on speed is the IRQ stuff, and I really don't have the heart to touch that again. It took me over two years to get that working right :( Well, we'll see. Perhaps I can find another niche to focus on. Maybe a really fancy cross-platform graphical debugger. |
|||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Mar 08, 2007 4:22 pm Post subject: | |||
|
|
|||
Are you saying that you have used emulators in which you know what specific hacks are being used and how they relate to the audio of a specific game? _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Mar 08, 2007 5:03 pm Post subject: | |
|
|
|
| Your latest build gets 110 fps on my rig. _________________ Watering ur plants. |
|
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 08, 2007 5:19 pm Post subject: | |||||
|
|
|||||
Give me time v_v;
o.O Is that air cooled? |
|||||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Thu Mar 08, 2007 5:37 pm Post subject: | |||||
|
|
|||||
To a limited extent, yes. But this is mostly because most emulators I have used have little released documentation; I simply know that some games are using hacks in order to increase accuracy. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 08, 2007 6:09 pm Post subject: | |
|
|
|
| The
reality is that the majority of emulators for most systems are using
hacks (especially newer systems), though I don't think you have the
ability to personally tell as a casual emulation user :/ Try using upx -d <file> && strings <file> > log. You'll find game titles in many, many emulators. Again, nothing wrong with it unless you specifically say that you're not using them. |
|
Inmate
Joined: 06 Dec 2004
Posts: 1571
Location: WA
| Posted: Thu Mar 08, 2007 6:53 pm Post subject: | |||||||
|
|
|||||||
...to increase compatibility. using a hack to increase accuracy is an oxymoron. as an aside, i'm really glad that there are still dedicated programmers on the snes emulation scene. _________________
|
|||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Thu Mar 08, 2007 7:08 pm Post subject: | |||||||
|
|
|||||||
Personally, I love the concept of selectionable cores and if like you said
|
|||||||
Regular
Joined: 30 Jun 2005
Posts: 206
Location: USA
| Posted: Thu Mar 08, 2007 7:10 pm Post subject: | |||
|
|
|||
Using hacks to get a games running better is a perfectly reasonable and accuracy-improving thing to do if your goal is to be a game emulator (for example, Nintendo's Virtual Console). A console emulator, on the other hand, should be concerned only with what the hardware does, not what games happen to do with the hardware. |
|||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Thu Mar 08, 2007 7:40 pm Post subject: | |||
|
|
|||
Maybe not whether they're hacks all the time, but I can certainly tell the difference between what is accurate and what is not, regardless of hacks. There are many that I somewhat "assume" to be hacks simply because of the fact that even to a casual emulation user, the information gets passed down on what's working and how; and the hacks are usually the first to be put into these types of categorization. The unfortunate consequence of this however is that misinformation is usually quicker to spread than correct information. This is just my observation on the whole though, and case by case it may be different. Also, byuu, this is just my opinion, but I'm not really a huge fan of the selectable cores idea. Somehow I picture that in the future the cores will diverge and then basically a choice will be made, and there may be lots of code, implemented or unimplemented, that will have to be trashed or re-arranged in order to accommodate the selected core. I dunno... I just kinda foresee a lot of potential problems for this (such as whether or not both cores work the same way, whether or not one will get more focus than the other...), but it's up to you. Just thought I'd toss in my two cents. Last edited by Talbain on Thu Mar 08, 2007 7:48 pm; edited 1 time in total |
|||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Thu Mar 08, 2007 7:45 pm Post subject: | |||
|
|
|||
Agree. If the goal is only to preserve the games themselves. you could see some innacurate emulators as being game-preserving in many cases, as opposed to hardware-documenting. Nothing inherently wrong with it I guess. From an "historical" perspective it's better than losing the game forever. *edit: and yes, if an hack makes a game look and sound closer to the original you have indeed raised the 'game''s accuracy, so to speak. Of course, I'm still highly in favor of hardware-accurate emulators, and against hacks. If only because hardware-accurate emulators also makes better "game-emulators" programs due to their nature. Sort of like how *thinking of an analogy* how...errr...better...errr... water...makes...errr...better wine. (Okay that was awful) edit above:* Last edited by Snark on Thu Mar 08, 2007 8:10 pm; edited 2 times in total |
|||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Thu Mar 08, 2007 7:50 pm Post subject: | |||||
|
|
|||||
That's one way to look at it, but when it can't work without a hack, sometimes you just have to accept the lesser of two evils. Losing it altogether or getting it working with a hack. Thankfully, there are not many problems with that for the SNES because there are so many SNES emulators, but it's certainly a possibility. Unfortunately for me, my wanting an accurate emulator is somewhat juxtaposed with my idea of wanting an emulator that can play games. If this idea seems odd, think about it from the perspective of one who doesn't have an extremely fast computer. |
|||||
Inmate
Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
| Posted: Thu Mar 08, 2007 8:41 pm Post subject: | |||
|
|
|||
You might just want to stick with ZSNES for right now. As far as I understand it, byuu will never add game-specific hacks to bsnes. Also, ZSNES, is much faster. _________________ Official ZSNES Docs http://www.flickr.com/photos/jipcy/ |
|||
Rookie
Joined: 24 Feb 2005
Posts: 14
| Posted: Thu Mar 08, 2007 9:31 pm Post subject: | |||||
|
|
|||||
I'm actually currently using snesgt. It seems to have the leanest code and the most working games. It's Windows only though and closed-source. Also, the info given by gigo and hii is rather sparse as to what they're doing with it. Maybe they'll implement blargg's sound core somehow, as the graphical core looks great. Toss in cheat support and you've got just about everything I could think of for an emulator (aside from an emulator used for romhacking purposes). But hey, I'm just pipe-dreaming right now. I sincerely hope to see blargg's sound core implemented as the standard, because right now, it really is the most accurate I've heard amongst emulators; and I've heard a lot. |
|||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Thu Mar 08, 2007 10:36 pm Post subject: | |||||
|
|
|||||
|
I
really do like blargg's analogy. The problem is that the first word
always tends to get dropped, and people refer to programs as just
'emulators'. The exact same problem occurs with 'free software'. Free
what? Free to use and distribute? Free to modify and redistribute? Free
to use the work in a proprietary application? Not even the "free" GPL
grants all freedoms, nor does public domain software. It's a
compromise, and the term needs a qualifier to say what exactly is meant
by free. We can either take Stallman's approach and try and proselytize the terms emulator and simulator to mean something they don't, or we have to, as a community, make a collective effort to qualify what we mean by emulator when we refer to them. But I agree, I'm totally and utterly fine with the concept of a game emulator. I just got sick and tired of my fan translations breaking for unexpected reasons in emulators but not on hardware. This was because there was only one viable hardware emulator at the time, SNEeSe, which lacked a critical debugger needed for said translations. It also at the time was unable to perform even color add/sub. I'm happy to say SNEeSe is now extremely usable in all respects. Calling both the old ZSNES and SNEeSe the same thing urked me, and has been the source of a lot of snide comments I've made that have unfortunately upset a lot of people I respect in the community :/ But now, it looks like even ZSNES is moving in the direction of being a hardware emulator, so I guess my point is now moot. A shame, I had really grown to like our symbiotic relationship of having one shining example of a game emulator focused on features and compatibility, and another of a hardware emulator, focused on raw accuracy. Now we just have a blend, as both of our primary objectives have become dilluted over time. ZSNES focusing more on accuracy at the cost of (some) speed, me focusing more on frivilous stuff like GUIs, video filters, special chips and not pursuing massive tradeoffs like the ~10.2mhz S-PPU renderer.
And this is why we still don't have the SPC7110 decompression algorithm reverse engineered. We found a hack to get the games running now, and so nobody has any motivation to fix it properly. Same for the Uniracers bug that absolutely nobody knows how to fix. Same for why it took us nearly a decade for someone to finally put Razoola in his place and crack CPS2. I can think of nothing more detrimental to progress than hacks, they put off the problems, not solve them.
He could, but he'd be violating the LGPL unless he used a dynamically linked library version of it, and included blargg's source with his emulator. |
|||||
ZSNES Developer
Joined: 17 Aug 2004
Posts: 887
Location: In your garden
| Posted: Thu Mar 08, 2007 11:00 pm Post subject: | |
|
|
|
| Yes that is on air cooling using Intel's HSF. _________________ Watering ur plants. |
|
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Fri Mar 09, 2007 12:14 am Post subject: | |||
|
|
|||
Lol Even with Zsnes' recent accuracy improvements (which I applaud) I doubt we'll see it reaching the same level of accuracy as bsnes for a long, long time. (and besides, wouldn't it become just as slow as bsnes if it ever reach that level? which would destroy the point of being a fast emulator in the first place anyway) So I think it's a wee-bit early to call bsnes near evolution extinction :P |
|||
Zealot
Joined: 04 Aug 2004
Posts: 1078
| Posted: Fri Mar 09, 2007 12:24 am Post subject: | |||||||
|
|
|||||||
You really think that a 3% performance hit is worth keeping a lesser core in the code and offering it as an option? Anomie's served us well, but it's been completely superceded by blargg's. A core option will make sense when S-PPU drops performance 50%.
byuu's just being his self-deprecating self again. Simply put, if you have the power to run it, and don't care about savestates, bsnes is money. No other SNES emulator has a better gui or accuracy rate on games. .020's portability and uniformity between ports will just be another feather in its hat. Last edited by FitzRoy on Fri Mar 09, 2007 12:48 am; edited 1 time in total |
|||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Fri Mar 09, 2007 12:37 am Post subject: | |||||||
|
|
|||||||
I suppose a 3% performance drop would indeed not justify the option, although I would wait for byuu to re-integrate the fps counter to confirm the drop is indeed only around 3%...Because it feels like more. Like I mentionned, it's the first time ever I can't reach 60/60 regardless of option selected... (i.e: even with 9 frameskip) Of course, my cpu is not that powerful to begin with either (middle range P4) edit: then again. and not to start an argument but I personally see no harm in having both anomie and blargg's core into one .exe. Anyway, whatever byuu decide I'll have no problem with it either way. |
|||||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Fri Mar 09, 2007 1:00 am Post subject: | |||||
|
|
|||||
yup
With no disrespect to the Zsnes team, accuracy issues aside, from a user perspective the biggest problem with Zsnes has always been the bug regression problem...and I guess the shear number of them (one only needs to look at the bug report page for confirmation) Although, 1.60 should be interesting. It looks like it's finally heading towards a better direction. |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Mar 09, 2007 1:07 am Post subject: | |||
|
|
|||
The fact that emulation in general is like this, this is rather insulting. _________________ FF4 research never ends for me. |
|||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Fri Mar 09, 2007 1:15 am Post subject: | |
|
|
|
| Modularity or em, polymorphism? is always a good thing, if not for speed then from a programmer's point of view; that is, clean, readable code, being able to work on a component without having to worry about it breaking something that should be unrelated, et cetera. As byuu has said, of course. I agree that Blargg's core is the way to go if it should be a choice, but better if it isn't. | |
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Fri Mar 09, 2007 1:23 am Post subject: | |||||
|
|
|||||
Sorry if I came off as lacking respect, this was certainly not my intention. I was simply giving the reason why imo, some users might have made the switch from Zsnes Last edited by Snark on Fri Mar 09, 2007 1:30 am; edited 4 times in total |
|||||
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Mar 09, 2007 1:24 am Post subject: | |||||||||||
|
|
|||||||||||
You do realize you are under no specific obligation to use one emulator, or one particular version of ZSNES as has been said many many times. _________________ FF4 research never ends for me. |
|||||||||||
Trooper
Joined: 07 Mar 2006
Posts: 371
Location: The Netherlands
| Posted: Fri Mar 09, 2007 1:40 am Post subject: | |
|
|
|
| Let's not treat eachother with an air of hostility here. Byuu's work on a library unifying the Win32 API and the GTK+ API seems to be coming along well, and that will ensure portability atleast so far as Linux is concerned. Opinions about GUIs differ, but let's not get upset about stating opinion like fact - just add a mental 'to me'! From the other posts I've read, I don't think anyone is trying to offend. | |
ZSNES Developer
Joined: 28 Dec 2004
Posts: 5599
| Posted: Fri Mar 09, 2007 1:50 am Post subject: | |||||
|
|
|||||
There is nothing wrong with what byuu is doing to make it happy on all ports.. but I've also already read some really silly opinions and conclusions based on the "difficulty of supporting linux". On the other hand, IIRC there was a specifically a thread on compiling BSNES in Linux out of the box.. I'm sure it will be successful, but just something that needs to be noted when it is near completion.
It helps to add in IMO, because that's exactly what it is IMO. I've seen too many things that get spouted "as fact" unfortunately. _________________ FF4 research never ends for me. |
|||||
Trooper
Joined: 31 Oct 2006
Posts: 433
| Posted: Fri Mar 09, 2007 1:51 am Post subject: | |||||||||||||
|
|
|||||||||||||
Yes, and it wasn't my goal to say one emulator is better than the other. One might be prefered by some, another one by other users, some will even use both, it's all good. |
|||||||||||||
bsnes Developer
Joined: 12 Oct 2004
Posts: 2414
| Posted: Fri Mar 09, 2007 2:02 am Post subject: | |||
|
|
|||
The fun thing about polymorphism is that there is no speed loss in having anomie's core alongside blargg's, other than the initial polymorphism hit which is ~10% for all four cores, ~1% for the DSP alone. It does benefit us in the meantime, as we have not tested all 4,000 games with blargg's S-DSP core yet, and this gives us a point of comparison. If you all really want it removed just because it takes up hard drive space, I'll be willing to consider that for v0.021 and above ... Re: ZSNES discussion, The above comment is equally impolite to anomie's work, as the comments that Deathlike has taken offense to. Unfortunately, this is just the way emulation is. I can guarantee you that if someone pops up tomorrow with something more accurate than bsnes, I'll get the same negative comments. And if you go to a thread discussing speed, features or total compatibility, of which I could link you at least a dozen if not for me clearing my referrals daily, you'll see even more condescending topics about my work compared to ZSNES. We all get the flack, and believe it or not, but I get a lot more as the little guy. My site doesn't have 30 million hits, but more like 80,000. I'm really deeply sorry if my attitude encourages this negative behavior, but it's just that I'm very frank in what I say, and am quick to point out in what I believe. One thing I don't do, as it is impractical, is add "this is a personal opinion, but ..." before everything I mention. However, I hope that it's implied. I realize my opinion is in the extreme minority, of roughly 0.1% of emulator users. That doesn't mean it's right or wrong, but it's extremely far from popular opinion, and should not be taken as being insulting nor as fact. The biggest problem, is that this is the ZSNES boards. The ZSNES authors should not have to take flack from anyone posting here. The unfortunate thing is that if I want a board, I want to personally control it on my domain. And to do that, means I'll have to write my own. And to do that, takes time away from emulator development. I don't want to spend 3 weeks writing a nice board, nor do I want to use someone else's prepackaged board. But back to the point, people will always attack things. Look how quickly anomie's work came under fire. It was compared to SNEeSe, the holy grail at the time of S-DSP emulation. And now it's deemed a lesser core that has been completely superceded. Give it time and you'll see even greater insults to anomie's work. This is just the way everyone is. I may be a pessimist and self-defeating, | |||