FitzRoy 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 |
|
Noxious Ninja 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 |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 31, 2005 4:19 am Post subject: |
|
The Giver wrote: |
TRAC writes SnEeSe. I'm sure he's willing to share info, but I doubt he'd want to merge the two emus. |
I know, I mean, besides that... That's all I know, seriously. He's very mysterious.
|
|
byuu 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.
Quote: |
Seriously, the level your emu is at now from when you started is crazy. |
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.
|
|
DataPath 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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Aug 31, 2005 4:56 pm Post subject: |
|
byuusan wrote: |
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. |
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.)
|
|
Nach 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.
byuusan wrote: |
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. |
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
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Sep 02, 2005 5:51 pm Post subject: |
|
Nach wrote: |
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. |
Whoa, that's awesome news!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Sep 02, 2005 9:01 pm Post subject: |
|
Quote: |
And we are teaming up in ways, although I won't give out any details on that at the moment. |
How mysterious.
Quote: |
Oh please, what progress am I making? |
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
|
|
Nach 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 |
|
badinsults "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. |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Sep 04, 2005 9:07 am Post subject: |
|
GOATSnEs wrote: |
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. |
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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
badinsults "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: |
|
grinvader wrote: |
GOATSnEs wrote: |
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. |
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.
|
Once I get a copier, the pieces will be set.
|
|
anomie Lurker

Joined: 07 Dec 2004
Posts: 168
|
Posted: Sun Sep 04, 2005 9:30 pm Post subject: |
|
grinvader wrote: |
Trial and error fill in the blanks where docs aren't explicit. |
... or are wrong.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Sun Sep 04, 2005 10:06 pm Post subject: |
|
anomie wrote: |
grinvader wrote: |
Trial and error fill in the blanks where docs aren't explicit. |
... or are wrong.
|
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 ^^; .
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
lockharte 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. |
|
adventure_of_link 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? |
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
Posted: Sun Sep 04, 2005 11:13 pm Post subject: |
|
SNEmul.
_________________
#577451 |
|
adventure_of_link 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? |
|
xamenus 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. |
|
lockharte Zealot
Joined: 02 Feb 2005
Posts: 1045
|
Posted: Mon Sep 05, 2005 2:42 am Post subject: |
|
is zsnes currently compatible with XBOX? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
adventure_of_link 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? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Sep 06, 2005 8:31 am Post subject: Re: bsnes appreciation thread, sound woes |
|
Quote: |
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. |
Hmm, perhaps this, or possibly this will help...
All your thanks are belong to anomie for the above.
|
|
Zuzma 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. |
|
|
Noxious Ninja 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 |
|
FitzRoy 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! |
|
Pepper 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/ |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
FitzRoy 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* |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Fri Sep 16, 2005 7:42 am Post subject: |
|
FitzRoy wrote: |
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!!!
|
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
|
|
byuu 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.
Quote: |
My 2.4ghz works hard to get ~50fps in bsnes as it is right now. |
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.
Quote: |
Looks like you already know what you are doing. Blargg has a pretty good snes sound emu and has some good resources. |
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.
Quote: |
Chrono Trigger opening screen shifts |
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'.
|
|
Clements 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 |
|
FitzRoy 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. |
|
Pepper New Member
Joined: 08 Sep 2005
Posts: 6
|
Posted: Fri Sep 16, 2005 10:13 pm Post subject: |
|
byuusan wrote: |
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.
|
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.
|
|
Dmog 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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Sep 18, 2005 10:36 pm Post subject: |
|
Dmog wrote: |
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. |
Wasn't really a "feature" request though, and I agree with you.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Sep 18, 2005 11:54 pm Post subject: |
|
Quote: |
Small request, byuu: can we get the .SFC extension added to the "open rom image" list? |
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...
Quote: |
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. |
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.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Sep 19, 2005 11:58 am Post subject: |
|
byuu's homepage wrote: |
I've
also been trying to fix up the offset-per-tile code, but for the life
of me, I can't even reproduce a bug in my own code; and all the games
that it screws up in (Chrono Trigger intro, Contra 3 first boss, etc),
I have to play several minutes to get to that part. It's too hard to
debug stuff so far into the games without savestates. |
Uh... implement savestates then, at least partially? 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu 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.
Quote: |
Can you highlight some games that your emulator runs better than ZSNES/snes9x/SNEESE? |
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...
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Tue Sep 20, 2005 12:00 pm Post subject: |
|
byuusan wrote: |
No savestates for now, for reasons I won't discuss just yet. |
You don't have to. 
byuusan wrote: |
They'll be there eventually, though. |
Great! 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
adventure_of_link 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? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Sep 21, 2005 2:25 am Post subject: |
|
adventure_of_link wrote: |
What games used Toaster now, or did I miss something ? |
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
|
|
adventure_of_link 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? |
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Wed Sep 21, 2005 2:44 am Post subject: |
|
Nach wrote: |
adventure_of_link wrote: |
What games used Toaster now, or did I miss something ? |
He was referring to the fact that ZSNES has Toaster support, but he doesn't ever plan on adding it.
|
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.
|
|
Nach 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 |
|
FitzRoy 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! |
|
byuu 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):
Code: |
mkfifo output.wav
bsnes_sdl <rom.smc> & mplayer output.wav
|
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...
|
|
PFUNK Lurker

Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA
|
Posted: Sun Oct 02, 2005 8:37 pm Post subject: |
|
FitzRoy wrote: |
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! |
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.
|
|
|
kode54 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.... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sun Oct 02, 2005 9:53 pm Post subject: |
|
PFUNK wrote: |
FitzRoy wrote: |
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! |
Ha ha ha.
I seriously doubt it will only be a "matter of time" before perfect emulation is achieved.
|
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 03, 2005 2:58 am Post subject: |
|
kode54 wrote: |
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. |
Kernel streaming in an snes emulator? Probably not the most practical
choice, but I think I would shit my pants if that happened.
|
|
Noxious Ninja 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 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 03, 2005 4:11 am Post subject: |
|
PFUNK wrote: |
Ha ha ha.
I seriously doubt it will only be a "matter of time" before perfect emulation is achieved. |
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.
Quote: |
All
in all, I hope byuu continues his great work and isn't assaulted by "I
WANT SUPER HQ2X EAGLE 2X FILTER SUPPORT NOW." ... Oh, and on a tangent,
my only real qualms with bsnes are its speed (too fast on my laptop)
and CPU usage. |
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 :)
kode54 wrote: |
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. |
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 >_<
Quote: |
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. |
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...
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 03, 2005 5:39 am Post subject: |
|
Noxious Ninja wrote: |
Why wouldn't it be a practical choice? |
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...
byuusan wrote: |
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. |
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*
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Mon Oct 03, 2005 6:34 am Post subject: |
|
byuusan wrote: |
Also, do me a favor and don't try Der Langrisser. That game has some screwy sound code... |
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.
Code: |
if(!(dsp_counter++ & 1) && status.key_flag) {
for(v=0;v<8;v++) {
uint8 vmask = 1 << v;
if(status.soft_reset()) {
if(voice[v].env_state != SILENCE) {
voice[v].env_state = SILENCE;
voice[v].AdjustEnvelope();
}
} else if(status.KOFF & vmask) {
if(voice[v].env_state != SILENCE && voice[v].env_state != RELEASE) {
voice[v].env_state = RELEASE;
voice[v].AdjustEnvelope();
}
} else if(status.KON & vmask) {
status.KON &= ~vmask;
status.ENDX &= ~vmask;
voice[v].brr_ptr = read_16((status.DIR << 8) + (voice[v].SRCN << 2));
voice[v].brr_index = -9;
voice[v].brr_looped = false;
voice[v].brr_data[0] = 0;
voice[v].brr_data[1] = 0;
voice[v].brr_data[2] = 0;
voice[v].brr_data[3] = 0;
voice[v].envx = 0;
voice[v].env_state = ATTACK;
voice[v].AdjustEnvelope();
}
}
status.key_flag = false;
}
|
|
|
byuu 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! |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Oct 03, 2005 11:09 am Post subject: |
|
byuusan wrote: |
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. |
*whispers: "Super Aleste !!"*
No, really. Stage 5 must be some kind of hellcode.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
anomie Lurker

Joined: 07 Dec 2004
Posts: 168
|
Posted: Mon Oct 03, 2005 12:41 pm Post subject: |
|
FitzRoy wrote: |
and frequency changes (non-32khz doesn't make it sound any better. It only complicates things.) |
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.
DMV27 wrote: |
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. |
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:
Code: |
KOFF = 1
KON = 1
// wait a while, at most 2 output samples
KOFF = 0 |
Can you show me the code in Der Langrisser that is 'fixed' by this behavior?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 03, 2005 5:06 pm Post subject: |
|
grinvader wrote: |
*whispers: "Super Aleste !!"*
No, really. Stage 5 must be some kind of hellcode. |
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...
|
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
Posted: Mon Oct 03, 2005 5:19 pm Post subject: |
|
byuusan wrote: |
Sorry for the lowest quality setting on the ogg encoding. |
Noxious Ninja wrote: |
Hey Byuu, if you want to conserve bandwidth, you can use Coral Cache. |
_________________
#577451
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Oct 03, 2005 8:29 pm Post subject: |
|
FitzRoy wrote: |
grinvader wrote: |
*whispers: "Super Aleste !!"*
No, really. Stage 5 must be some kind of hellcode. |
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? :lol: 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...
|
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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Oct 03, 2005 9:17 pm Post subject: |
|
anomie wrote: |
Can you show me the code in Der Langrisser that is 'fixed' by this behavior? |
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!!"
Quote: |
Hey Byuu, if you want to conserve bandwidth, you can use Coral Cache. |
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.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Oct 03, 2005 10:27 pm Post subject: |
|
grinvader wrote: |
RONG - that's stage 4, and neither bsnes nor zsnes have any trouble
with the warped transforming green background or the growing rocks.
|
Gruuuu... snes knowledge... failing....
|
|
PFUNK Lurker

Joined: 28 Jul 2004
Posts: 158
Location: Blacksburg, VA
|
Posted: Mon Oct 03, 2005 10:50 pm Post subject: |
|
byuusan wrote: |
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.
|
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.
|
|
anomie Lurker

Joined: 07 Dec 2004
Posts: 168
|
Posted: Mon Oct 03, 2005 10:57 pm Post subject: |
|
byuusan wrote: |
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. |
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.
Quote: |
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? |
anomie wrote: |
Also, your code would play sound for the following sequence of writes, where the real SNES would not:
Code: |
KOFF = 1
KON = 1
// wait a while, at most 2 output samples
KOFF = 0 |
|
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).
|
|
kode54 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:
- I see no cleanup code to delete so many random class instances on program shutdown, will that be handled eventually?

- I
modified the Makefile for MSVC 8 LTCG, last used in the optimize stage.
Just remove the LDFlags bits, or use the Visual Studio 2005 Express
compiler toolkit to do the building. ( Express doesn't include the
resource compiler, though, but you only use that for the controller
art. )
- Sound
output was moved to the video_run function, so output may be used for
frame rate regulation. An extra function was added to snes_audio to
reset the buffer position.
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Tue Oct 04, 2005 5:54 am Post subject: |
|
anomie wrote: |
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. |
Der Langrisser SPC Soundtrack
Quote: |
Can you show me the code in Der Langrisser that is 'fixed' by this behavior? |
I only traced writes to KON and KOFF. BSNES crashes on my computer, so I couldn't use it to do any code tracing.
Quote: |
anomie wrote: |
Also, your code would play sound for the following sequence of writes, where the real SNES would not:
Code: |
KOFF = 1
KON = 1
// wait a while, at most 2 output samples
KOFF = 0 |
|
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).
|
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?
Code: |
// Format
event: voice, sample number
info: voice, envx, release time (samples)
// Intro Music
write koff: 08, 236922
run koff: 08, 236924
koff envx: 08, 0.425989, 109.00
write kon : 08, 237074
write koff: 00, 237074
run kon : 08, 237076
kon envx: 08, 0.000000
write koff: 02, 243372
run koff: 02, 243374
koff envx: 02, 0.372252, 95.25
write kon : 02, 243510
write koff: 00, 243510
run kon : 02, 243512
kon envx: 02, 0.000000
write koff: 40, 243540
run koff: 40, 243542
koff envx: 40, 0.422081, 108.00
write kon : 40, 243691
write koff: 00, 243692
run kon : 40, 243694
kon envx: 40, 0.000000
// Player Setup Music
write koff: 04, 513509
run koff: 04, 513510
koff envx: 04, 0.941378, 240.88
write kon : 04, 513792
write koff: 00, 513792
run kon : 04, 513794
kon envx: 04, 0.000000
write koff: 01, 516018
run koff: 01, 516020
koff envx: 01, 0.980459, 250.88
write kon : 01, 516311
write koff: 00, 516312
run kon : 01, 516314
kon envx: 01, 0.000000
write koff: 08, 517860
run koff: 08, 517862
koff envx: 08, 0.980459, 250.88
write kon : 08, 518154
write koff: 00, 518154
run kon : 08, 518156
kon envx: 08, 0.000000 |
|
|
kode54 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:
- DirectDraw: Requires fullscreen mode.
- Direct3D: Requires D3D9 interface for vertical refresh synchronization in a window.
I'll update with a Direct3D 9 interface in a bit, and eventually work in configurable support for both renderers.
|
|
byuu 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 |
|
anomie Lurker

Joined: 07 Dec 2004
Posts: 168
|
Posted: Tue Oct 04, 2005 12:18 pm Post subject: |
|
Nifty, which track is the problem?
|
|
kode54 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. ) |
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
Posted: Tue Oct 04, 2005 1:10 pm Post subject: |
|
kode54 wrote: |
(
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. ) |
Regular users can't delete their own posts. It sucks.
_________________
#577451
|
|
adventure_of_link 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? |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Oct 04, 2005 9:35 pm Post subject: |
|
Quote: |
Nifty, which track is the problem? |
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.
Quote: |
( Taking a running average, with NTSC, it seems to average ~31947.3 samples per second, assuming 60 frames per second. ) |
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.
|
|
Magus` Cap'n Gin | Admin

Joined: 27 Jul 2004
Posts: 748
Location: Missouri
|
Posted: Tue Oct 04, 2005 10:13 pm Post subject: |
|
adventure_of_link wrote: |
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 ? |
Yes.
|
|
anomie Lurker

Joined: 07 Dec 2004
Posts: 168
|
Posted: Tue Oct 04, 2005 11:07 pm Post subject: |
|
byuusan wrote: |
All of them? >_<
Leon, Story, Opening 1... they all seem to be missing some of the notes in the songs. |
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...
|
|
adventure_of_link 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? |
|
FitzRoy 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!  |
|
kode54 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... ) |
|
kieran_ Mugwump

Joined: 30 Jul 2004
Posts: 2966
|
Posted: Tue Oct 11, 2005 1:33 pm Post subject: |
|
Congrats on the emu, byuu. |
|
creaothceann 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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
FitzRoy 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? |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Oct 20, 2005 8:04 pm Post subject: |
|
FitzRoy wrote: |
Ooo, more updates from byuu. |
Yes, more Bsnes goodness:
Quote: |
Lastly,
I finally feel that the accuracy of the emulator is good enough to
block VRAM writes outside of vblank. This means a few fan-translated
games that won't run on hardware will no longer work in bsnes. |
Nice to see Bsnes won't compromise on accuracy. Screw the translations
that depends on emulator innacuracies (my opinion)
|
|
taezou 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. |
|
FitzRoy 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  |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Oct 23, 2005 12:23 pm Post subject: |
|
Quote: |
4:3 is now my preferred ratio. |
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.
Quote: |
Did you ever figure out those "kon" issues with der langrisser btw? |
Nope.
Quote: |
I was playing with bsnes, and I noticed a somewhat minor graphical error in Tetris Attack. |
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.
Quote: |
On another note, I hooked up my usb gamepad finally today. Couldn't get it to work in bsnes, though |
No joypad support. Use a joypad -> windows key mapping program. I
don't know the names of any, but they do exist.
|
|
FitzRoy 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.  |
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Sun Oct 23, 2005 10:33 pm Post subject: |
|
byuusan wrote: |
No joypad support. Use a joypad -> windows key mapping program. I
don't know the names of any, but they do exist. |
Will there ever be joypad support? I tend to shy away from an emulator that doesn't do it by itself...
|
|
byuu 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.) |
|
badinsults "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: |
|
byuusan wrote: |
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.) |
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.
|
|
FitzRoy 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.
 |
|
byuu 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... |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
p00f 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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Oct 26, 2005 12:43 pm Post subject: |
|
taezou wrote: |
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. |
Thanks, this is fixed now. It was due to offset per tile mode being
incorrect. It'll be in the next public release.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Oct 26, 2005 5:01 pm Post subject: |
|
sweetsweetsweetsweetsweet
Next version is gonna rock. |
|
xamenus 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.  |
|
kieran_ 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? |
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Oct 27, 2005 11:10 am Post subject: |
|
Kieran wrote: |
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? |
Some crazy dude runs bsnes 60/60 with hq4x... on a MAC.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
Posted: Thu Oct 27, 2005 12:38 pm Post subject: |
|
Kieran wrote: |
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? |
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
|
|
byuu 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. |
|
grinvader 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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
vigi_lante 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. ; ) |
|
SquareHead Seen it all

Joined: 21 Jan 2005
Posts: 2503
Location: the cracker box
|
Posted: Fri Oct 28, 2005 4:42 am Post subject: |
|
grinvader wrote: |
Kieran wrote: |
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? |
Some crazy dude runs bsnes 60/60 with hq4x... on a MAC.
|
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
|
|
byuu 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. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Oct 28, 2005 1:30 pm Post subject: |
|
Quote: |
It would be nice to have an option to play at 256x240 with fullscreen. ; ) |
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...
|
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Fri Oct 28, 2005 3:17 pm Post subject: |
|
vigi_lante wrote: |
It would be nice to have an option to play at 256x240 with fullscreen. ; ) |
|
|
vigi_lante Hazed
Joined: 15 Nov 2004
Posts: 65
|
Posted: Fri Oct 28, 2005 3:18 pm Post subject: |
|
Quote: |
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... |
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.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Fri Oct 28, 2005 3:37 pm Post subject: |
|
vigi_lante wrote: |
If 256x240 is the original SNES hardware resolution, I think it's a valid suggestion. This and 512x480 for hi-res games. |
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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Deathlike2 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? |
|
Aerdan 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. |
|
grinvader 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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Fri Oct 28, 2005 4:02 pm Post subject: |
|
Aerdan wrote: |
Text blurrienss in that one is partially due to the fact that Woolsey is an idiot. |
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.
|
|
Aerdan A. Lagopus


Joined: 16 Aug 2004
Posts: 702
|
Posted: Fri Oct 28, 2005 4:06 pm Post subject: |
|
Metatron wrote: |
Aerdan wrote: |
Text blurrienss in that one is partially due to the fact that Woolsey is an idiot. |
I doubt he programmed that screen or picked out the font... Unless you're talking about something else.
PS: Hating Woolsey is not cool.
|
He
hardly deserves the title 'translator', particularly given he was
simply 'head translator' at the time and didn't actually do much in the
way of translation, I'm told.
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
|
|
vigi_lante Hazed
Joined: 15 Nov 2004
Posts: 65
|
Posted: Fri Oct 28, 2005 4:07 pm Post subject: |
|
Quote: |
256x224 for lowres NTSC, x238 for lowres PAL. Twice for each hires mode (Hx2 / Vx2 / Hx2+Vx2). |
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)
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Oct 28, 2005 4:30 pm Post subject: |
|
vigi_lante wrote: |
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) |
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/
|
|
Metatron Deus ex Machina

Joined: 28 Jul 2004
Posts: 1323
|
Posted: Fri Oct 28, 2005 4:31 pm Post subject: |
|
Aerdan wrote: |
Metatron wrote: |
Aerdan wrote: |
Text blurrienss in that one is partially due to the fact that Woolsey is an idiot. |
I doubt he programmed that screen or picked out the font... Unless
you're talking about something else.
PS: Hating Woolsey is not cool.
|
He
hardly deserves the title 'translator', particularly given he was
simply 'head translator' at the time and didn't actually do much in the
way of translation, I'm told.
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
|
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...
|
|
Tomato 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 :/ |
|
Metatron 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. |
|
Tomato 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  |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Oct 28, 2005 6:38 pm Post subject: |
|
Quote: |
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. |
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)
Quote: |
Are you actually ARGUING with the people who emulate this piece of hardware? |
He's completely lost... there's almost no hope for reasoning at this point..
Quote: |
The screenshot code doesn't check for it and uses the lowres (old graphic engine) buffer. |
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...
|
|
byuu 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.
Quote: |
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. |
Yep. Huge problem, no easy solution.
Quote: |
Speaking of hires, why doesn't ZSNES take "bigger pics" (512x480) when hires is used? |
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.
Quote: |
Nah, I watch this thread all the time and the dev board all the time. byuu's work is awesome |
' 'è'ª'Æ'¤'²'´'¢'Ü'·Aƒgƒ}ƒg'³'ñ :D
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Fri Oct 28, 2005 7:30 pm Post subject: |
|
Quote: |
How would you take a picture of just interlace or just hires? |
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).
|
|
|
vigi_lante 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.
Quote: |
That's not even the point.. if there even was stuff rendered there and not viewable by the TV.. then why even render it? |
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).
Quote: |
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. |
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
|
|
Aerdan 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* |
|
pagefault 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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 01, 2005 4:11 am Post subject: |
|
Quote: |
More recent video cards support custom resolution input, which allows for 512x448 |
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.
Quote: |
I just tried bsnes. It's looking good so far. You've come a long way byuu, congrats. |
Thank you, your opinion means a lot.
|
|
Nightcrawler 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. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
vigi_lante 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. |
|
FitzRoy 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? |
|
Jipcy 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/ |
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Wed Nov 02, 2005 9:43 am Post subject: |
|
vigi_lante wrote: |
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. |
This is the last thing I'll say to you, since you're camping on your stupid.
ANALOG STRETCH
Moron.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Deathlike2 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:
Quote: |
Resolution:
between 256x224 and 512x448. Most games used 256x224, 320x224, 512x224
pixels since higher resoulutions caused slowdown, flicker, and/or had
increased limitations on layers and colors (due to memory bandwidth
constraints); the higher resolutions were used for less
processor-intensive games, in-game menus, text, and high resolution
images. |
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).
|
|
vigi_lante 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. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Nov 02, 2005 8:07 pm Post subject: |
|
Quote: |
And it's not necessary to be so rude. I'm treating everyone with respect. If you cant control yourself, just ignore me. |
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.
|
|
vigi_lante 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. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Wed Nov 02, 2005 10:49 pm Post subject: |
|
Quote: |
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... |
Well, one important factor is that Aerdan is a dev.
Quote: |
But, if things here are really like this. It would be a favour for both of us. |
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.
|
|
vigi_lante 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.
Quote: |
256x240 doesn't make sense, since the minimum SNES res is 256x224, which is already implemented in the major SNES emulators. |
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
|
|
Aerdan 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. |
|
FitzRoy 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. |
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Nov 03, 2005 1:30 am Post subject: |
|
Quote: |
Now, don't go and start fighting again and getting a good thread locked. |
I'll just play the ignorance is bliss card. It's not worth seeing what he says.
Quote: |
Major changes shouldn't even be requested at this point anyway. |
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.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Nov 03, 2005 1:35 am Post subject: |
|
vigi_lante wrote: |
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. |
I can use the S-Video out on my laptop.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Reznor007 Regular
Joined: 30 Jul 2004
Posts: 229
|
Posted: Thu Nov 03, 2005 2:06 am Post subject: |
|
Jipcy wrote: |
vigi_lante wrote: |
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. |
I can use the S-Video out on my laptop.
|
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Nov 03, 2005 2:12 am Post subject: |
|
Quote: |
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 |
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.
|
|
Jipcy 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:
byuu wrote: |
Most
importantly, I received my copy of Visual Studio 2005 Pro, so now I can
use profile guided optimizations on bsnes. This will give the emulator
a 10-20% speed increase, depending on the game. I'll only be using this
feature on final builds, and not WIP versions, as it takes
significantly longer to compile this way.
Next, to speed things up some more, I added #ifdefs around all of the
debugging functions inside the core. That means a Windows port can now
be compiled with no debugging extensions, which gives a nominal ~10%
speed increase as well. |
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
xamenus 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.  |
|
Aerdan 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. |
|
|
sweener2001 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.
_________________
 |
|
FitzRoy 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? |
|
grinvader 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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
FitzRoy 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. |
|
adventure_of_link 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? |
|
Noxious Ninja Dark Wind

Joined: 29 Jul 2004
Posts: 2713
Location: teh intarwebs
|
Posted: Mon Nov 07, 2005 7:02 pm Post subject: |
|
FitzRoy wrote: |
They must do some kind of self-diagnostic to make sure it's a cart and not a rom. |
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
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Mon Nov 07, 2005 7:58 pm Post subject: |
|
FitzRoy wrote: |
They must do some kind of self-diagnostic to make sure it's a cart and not a rom.
(...)
I guess I don't understand how copy protection works on snes games. |
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:
Code: |
ABCDEFGHIJKLMNOP00000000 |
Now what happens in the real snes ? It wraps and restarts from a certain point:
Code: |
ABCDEFGHIJKLMNOPABCDEFGH |
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.
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
Jipcy 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.
byuu.org wrote: |
Thanks
to ideas and help from kode54, GIGO, and Richard Bannister, I finally
added speed regulation to bsnes. It synchronizes via sound, as I feel
one lost frame of audio is far more noticeable than one lost frame of
video every 10 seconds or so (the former would cause a loud popping
noise each time). I took everything I could think of into account, as
well. It adjusts the regulation based on NTSC (32khz / 60
samples/frame) or PAL (32khz / 50 samples / frame), clears the sound
buffer whenever a modal event occurs (such as entering the menubar),
etc.
I also (finally) fixed a longstanding
issue where pressing enter to select a menu option would cause the
keypress to go through to the emulator, causing an unwanted keypress to
occur in-game.
I don't plan on supporting vsync in windowed mode, as the video would
be extremely choppy unless the desktop were ran at 50/60hz, which I
can't imagine anyone sane doing, at least on a CRT. For fullscreen, I
plan on setting the refresh rate to 60hz and then using triple
buffering, and dropping the occasional extra frame when needed (as the
SNES does not run at exactly 60fps). This should allow fluid audio and
video output at nearly the exact speed of a true SNES. No idea what I
want to do about PAL, yet.
I'm putting off the vsync code until the next version, as well as the
possible Windows port GUI rewrite. v0.014 should hopefully be released
by next week. |
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Nov 09, 2005 1:43 pm Post subject: |
|
byuu.org wrote: |
I don't plan on supporting vsync in windowed mode, as the video would be extremely choppy unless the desktop were ran at 50/60hz |
What if the desktop runs at 100/120 Hz? Would that help anything?
Jipcy wrote: |
I'm greatly looking forward to v0.014. |
Me too. 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Wed Nov 09, 2005 5:48 pm; edited 1 time in total
|
|
adventure_of_link 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? |
|
byuu 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.
Quote: |
11/12/2005 - bsnes v0.014 released
This version adds speed regulation, greatly improves PPU rendering, and
increases speed by ~30% over the previous version.
Changelog:
* Rewrote offset-per-tile mode emulation, should be correct now. Fixes
Chrono Trigger, Contra III, Tetris Attack, etc.
* Fixed a bug with HDMA occuring during interrupts. Fixes Tales of Phantasia souond test screen
* Updated compiler to Visual Studio 2005, and enabled profile guided optimizations
* Added conditional compilation of debugging functions (faster without them)
* Added conditional compilation of core classes as pointers (allowing
polymorphism) or objects (allowing inlining). The latter results in a
speed increase
* Small fixes to BG and OAM rendering routines
* Corrected sprite tile bounds wrapping
* Corrected sprite rendering in hires video modes
* Rewrote color add/sub routines, should be correct now. Fixes Illusion of Gaia menu, etc.
* Optimized video blitting routines, will temporarilly break mixed video mode screenshots
* Prevented selecting menu options via return key from being recognized as keypresses by the emulator
* Added system speed regulation (60hz/NTSC or 50hz/PAL)! Many thanks to
kode54, GIGO, and Richard Bannister for their assistance |
Get it here.
|
|
FitzRoy 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... |
|
byuu 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. |
|
FitzRoy 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? |
|
byuu 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... |
|
Dmog 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.
Quote: |
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 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
|
|
byuu 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 :/ |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Nov 13, 2005 2:46 am Post subject: |
|
byuusan wrote: |
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. |
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
|
|
FitzRoy 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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Nov 13, 2005 3:21 am Post subject: |
|
Quote: |
edit:
*Disregard* everything below. My results aren't constant. The cause
probably comes from my end rather than being caused by Bsnes. |
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).
|
|
Dmog 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) |
|
Clements 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 |
|
ThunderClaw 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. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Nov 13, 2005 5:41 pm Post subject: |
|
Clements wrote: |
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 |
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
|
|
taezou 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
Quote: |
* Rewrote offset-per-tile mode emulation, should be correct now. Fixes Chrono Trigger, Contra III, Tetris Attack, etc. |
?
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?
|
|
|
FitzRoy 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. |
|
Jipcy 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/ |
|
Clements 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 |
|
byuu 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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Nov 14, 2005 3:20 am Post subject: |
|
Jipcy wrote: |
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... |
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?
byuusan wrote: |
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. |
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.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Pepper New Member
Joined: 08 Sep 2005
Posts: 6
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
FitzRoy 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. |
|
ThunderClaw 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. |
|
byuu 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. |
|
ThunderClaw 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. |
|
PFUNK 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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 15, 2005 4:42 am Post subject: |
|
Quote: |
Question byuu, do you have a bugtracker to keep track of the reports you're getting here? |
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.
Quote: |
I like emulators that force me to fix my own computer's faults to get things working right. Great work byuu. |
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
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Tue Nov 15, 2005 5:00 am Post subject: |
|
byuusan wrote: |
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. ... Now to bug him
about DSP and C4 support... |
Freakin' sweet!
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Tue Nov 15, 2005 5:33 am Post subject: |
|
byuusan wrote: |
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. |
That's good news, now I can more easily test my ROMs without worrying about uncompressing them first. 
Quote: |
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. |
Just
a thought, but maybe the admins would be kind enough to make a bsnes
board here at the ZSNES board? DeJap is already hosted here, so why not
bsnes?
|
|
LDAWG 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! |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Tue Nov 15, 2005 3:09 pm Post subject: |
|
byuusan wrote: |
Quote: |
Question byuu, do you have a bugtracker to keep track of the reports you're getting here? |
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.
Quote: |
I like emulators that force me to fix my own computer's faults to get things working right. Great work byuu. |
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.
|
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.
|
|
adventure_of_link 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? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Tue Nov 15, 2005 4:13 pm Post subject: |
|
byuusan wrote: |
I also can't test gzip, but see absolutely no reason why it shouldn't work. |
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
|
|
Aerdan 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... |
|
Clements 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 |
|
byuu 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. |
|
DataPath 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 |
|
-_pentium5.1_- 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. |
|
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
adventure_of_link Locksmith of Hyrule

Joined: 08 Aug 2004
Posts: 4533
Location: 255.255.255.255
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Nov 21, 2005 8:33 am Post subject: |
|
-_pentium5.1_- wrote: |
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. |
What about AEP?
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu 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. |
|
FitzRoy 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! |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 21, 2005 5:54 pm Post subject: |
|
FitzRoy wrote: |
And Mega Man x2 and x3 will be supported in the next version! |
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
|
|
LDAWG Lurker

Joined: 06 Aug 2004
Posts: 166
|
Posted: Mon Nov 21, 2005 6:17 pm Post subject: |
|
byuu wrote: |
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. |
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!
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 21, 2005 6:45 pm Post subject: |
|
LDAWG wrote: |
byuu wrote: |
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. |
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!
|
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
|
|
adventure_of_link 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? |
|
LDAWG Lurker

Joined: 06 Aug 2004
Posts: 166
|
Posted: Mon Nov 21, 2005 7:59 pm Post subject: |
|
adventure_of_link wrote: |
And LDAWG: Remember this: REAL men host their own servers. 
I think I oughta add that as another sig quote... |
That's not a very nice thing to say about byuu
|
|
adventure_of_link 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? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Mon Nov 21, 2005 10:16 pm Post subject: |
|
adventure_of_link wrote: |
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.
I made that post not paying to attention about anything, I assumed Nach and you were discussing my server.
|
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
|
|
adventure_of_link 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? |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 22, 2005 5:53 am Post subject: |
|
Quote: |
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. |
...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...
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Tue Nov 22, 2005 9:06 am Post subject: |
|
byuu wrote: |
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. |
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
Code: |
if(status.NON & (1 << v)) {
// sample = status.noise_sample;
sample = int16(status.noise_sample << 1) >> 1;
} else {
d = voice[v].pitch_ctr >> 4; //-256 <= d <= -1
sample = ((GaussTable[ -1-d] * S(-3)) >> 11);
sample += ((GaussTable[255-d] * S(-2)) >> 11);
sample += ((GaussTable[512+d] * S(-1)) >> 11);
// sample = clip (15, sample);
sample = int16(sample << 1) >> 1;
sample += ((GaussTable[256+d] * S( 0)) >> 11);
sample = clamp(15, sample);
}
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Tue Nov 22, 2005 2:01 pm Post subject: |
|
Code: |
- dsbd.dwFlags = DSBCAPS_GETCURRENTPOSITION2 | DSBCAPS_CTRLFREQUENCY |
- DSBCAPS_GLOBALFOCUS | DSBCAPS_LOCSOFTWARE;
+ dsbd.dwFlags = DSBCAPS_GETCURRENTPOSITION2 | DSBCAPS_GLOBALFOCUS; |
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?
Quote: |
Classes with virtual functions should have virtual dtors |
I was wondering why I needed to delete classes through static casts to
the derived class type to call the right dtors, thanks.
Quote: |
The Der Langrisser sound fix should use 'kon' instead of 'KON' to match anomie's tests |
And yet with 'kon', it breaks DL. I'll change it back when we find out why that is.
Quote: |
65816 BCD math (check SimEarth; Snes9x is correct in cpumacro.h) |
Mine came from there. What did I copy wrong?
Quote: |
bMemBus::read uses a static variable |
For? And why is this a problem?
Quote: |
bDsp::run doesn't use noise_sample properly (uint15 -> int32; check the Dual Orb 2 opening). The code should be |
Neat, thanks.
Appreciated as always, I'll add your fixes when I get home tonight.
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Tue Nov 22, 2005 9:00 pm Post subject: |
|
byuu wrote: |
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 tend to over-optimize sometimes, so you can just ignore most of the
DSSound changes (except the ctor, that is needed).
Quote: |
Quote: |
The Der Langrisser sound fix should use 'kon' instead of 'KON' to match anomie's tests |
And yet with 'kon', it breaks DL. I'll change it back when we find out why that is.
|
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.
Code: |
} else if(status.kon & mask) {
status.kon &= ~mask; //new code
status.ENDX &= ~mask; //new code
|
Quote: |
Quote: |
65816 BCD math (check SimEarth; Snes9x is correct in cpumacro.h) |
Mine came from there. What did I copy wrong?
|
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:
Code: |
// 0x00 + 0x10 = 0x10 == 10
// 0x09 + 0x07 = 0x10 != 16 |
Quote: |
Quote: |
bMemBus::read uses a static variable |
For? And why is this a problem?
|
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 23, 2005 3:16 am Post subject: |
|
Quote: |
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. |
Wasn't that the exact thing that was causing the problem before? What should I change here?
Code: |
// status.ENDX &= ~status.kon;
// status.kon = 0;
status.key_flag = false; |
And how about on KON register read/write?
Quote: |
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. |
Code: |
inline void bCPU::op_adc_w() {
int32 r = regs.a.w + rd.w + regs.p.c;
//bcd
if(regs.p.d) {
if(((r ) & 15) > 9)r += 6;
if(((r >> 4) & 15) > 9)r += 6 << 4;
if(((r >> 8) & 15) > 9)r += 6 << 8;
if(((r >> 12) & 15) > 9)r += 6 << 12;
} |
That seems to be exactly what I'm doing... what exact spot is failing in SimEarth?
Quote: |
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. |
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...
Quote: |
// sample = clip (15, sample);
sample = int16(sample << 1) >> 1; |
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.
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Wed Nov 23, 2005 6:38 am Post subject: |
|
byuu wrote: |
Quote: |
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. |
Wasn't that the exact thing that was causing the problem before? What should I change here?
Code: |
// status.ENDX &= ~status.kon;
// status.kon = 0;
status.key_flag = false; |
And how about on KON register read/write?
|
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:
Code: |
diff -dr src_old/dsp/bdsp/bdsp.cpp src/dsp/bdsp/bdsp.cpp
148c148
< // status.kon = data;
---
> status.kon = data;
224c224
< //status.kon = 0x00;
---
> status.kon = 0x00;
304,305c304,305
< } else if(status.KON & mask) { //status.kon
< status.KON &= ~mask; //new code
---
> } else if(status.kon & mask) {
> status.kon &= ~mask; //new code
diff -dr src_old/dsp/bdsp/bdsp.h src/dsp/bdsp/bdsp.h
66c66
< //uint8 kon;
---
> uint8 kon;
|
Quote: |
Code: |
inline void bCPU::op_adc_w() {
int32 r = regs.a.w + rd.w + regs.p.c;
//bcd
if(regs.p.d) {
if(((r ) & 15) > 9)r += 6;
if(((r >> 4) & 15) > 9)r += 6 << 4;
if(((r >> 8) & 15) > 9)r += 6 << 8;
if(((r >> 12) & 15) > 9)r += 6 << 12;
} |
That seems to be exactly what I'm doing... what exact spot is failing in SimEarth?
|
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.
Quote: |
Quote: |
// sample = clip (15, sample);
sample = int16(sample << 1) >> 1; |
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.
|
It's just an optimization.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Wed Nov 23, 2005 6:53 am Post subject: |
|
Quote: |
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. |
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...
Quote: |
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. |
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.
|
|
FitzRoy 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.  |
|
byuu 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... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
|
byuu 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. |
|
SquareHead 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 |
|
|
FitzRoy 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. |
|
FitzRoy 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. |
|
byuu 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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Dec 03, 2005 4:46 am Post subject: |
|
Nice! Thanks for the info. |
|
DataPath 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? |
|
byuu 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 |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 04, 2005 3:01 am Post subject: |
|
v0.015 is up. Enjoy. |
|
FitzRoy 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. |
|
xamenus 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.  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 04, 2005 6:56 pm Post subject: |
|
xamenus wrote: |
This is a fantastic release! bsnes seems like it is well on its way to eventually outdo ZSNES! |
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
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 04, 2005 7:10 pm Post subject: |
|
Quote: |
Problem: I can't map the keys to the directional buttons on my Saitek P880 gamepad. |
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.
Quote: |
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. |
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.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 04, 2005 7:17 pm Post subject: |
|
byuu wrote: |
Quote: |
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. |
Seconded, and I don't ever plan on adding most of ZSNES' features.
|
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
|
|
byuu 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. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Sun Dec 04, 2005 8:03 pm Post subject: |
|
byuu wrote: |
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. |
You're right. Thanks.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 04, 2005 8:41 pm Post subject: |
|
byuu wrote: |
I would hardly say it isn't worth looking at, but eh. Also, my
licensing probably isn't very friendly to the nesvideos crew.
|
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?
byuu wrote: |
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. |
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
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 04, 2005 9:19 pm Post subject: |
|
Quote: |
But it's just a hop over from #nesvideos to ask permission which you'll probably grant, right? |
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.
Quote: |
It's not CPU expensive at all. |
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.
|
|
FirebrandX 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! |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sun Dec 04, 2005 9:59 pm Post subject: |
|
byuu wrote: |
Just video capture features alone probably won't matter much to me.
|
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.
byuu wrote: |
Quote: |
It's not CPU expensive at all. |
It isn't the way ZSNES implements it. What blargg does is take periodic savestates
|
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
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sun Dec 04, 2005 10:05 pm Post subject: |
|
Quote: |
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). |
...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.
Quote: |
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 |
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.
Quote: |
While triple buffering does a decent job of smoothing out the scrolling, I much prefer timing based on vsync. |
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.
|
|
Jipcy 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/ |
|
FitzRoy 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. |
|
Marty Nestopia Developer

Joined: 05 Dec 2005
Posts: 24
|
Posted: Mon Dec 05, 2005 1:33 pm Post subject: |
|
byuu wrote: |
One option is for me to add a D3D renderer, but those don't do fullscreen + menus. |
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.
|
|
byuu 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' |
|
adventure_of_link 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? |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
|
adventure_of_link 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? |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Mon Dec 05, 2005 11:46 pm Post subject: |
|
byuu wrote: |
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.' |
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.
|
|
byuu 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.
|
|
Shinrin Hazed

Joined: 19 Jan 2005
Posts: 73
Location: 127.0.0.1
|
Posted: Wed Dec 07, 2005 4:15 pm Post subject: |
|
byuu wrote: |
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.
|
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!
|
|
Clements 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 |
|
byuu 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. |
|
Jipcy 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/ |
|
byuu 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... |
|
Shinrin 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!  |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Dec 10, 2005 12:32 am Post subject: |
|
byuu wrote: |
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. |
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?
byuu wrote: |
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) |
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/
|
|
FirebrandX Lurker
Joined: 19 Apr 2005
Posts: 128
|
Posted: Sat Dec 10, 2005 9:14 am Post subject: |
|
[quote="byuu"]
Quote: |
...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. |
Actually your suggestion to edit the cfg worked great! Thanks! I like being able to customize the cfg like that.
Quote: |
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. |
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.
Quote: |
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. |
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.
Quote: |
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. |
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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Dec 10, 2005 10:32 am Post subject: |
|
Quote: |
ToP intro ... The winner is: Bsnes. |
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.
Quote: |
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'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.
Quote: |
That's what I was afraid of. I cannot stand interpolation. |
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).
Quote: |
Cool. Maybe I should try programming in a 59.97 refresh rate mode with Power Strip. |
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.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Dec 10, 2005 4:22 pm Post subject: |
|
Quote: |
This emulator is getting on par with zsnes. |
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
|
|
aminalshmu 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
Code: |
void bSNES::video_run() {
if(r_ppu->status.frames_updated) {
char s[512], t[512];
r_ppu->status.frames_updated = false;
// if((bool)config::gui.show_fps == true) {
sprintf(s, "%s : %d fps", BSNES_TITLE, r_ppu->status.frames_executed);
// if(w_main->frameskip != 0) {
// sprintf(t, " (%d frames)", r_ppu->status.frames_rendered);
// strcat(s, t);
// }
SDL_WM_SetCaption(s, 0);
// }
}
|
and as a total C++ noob, this function doesn't make much sense to me. any help?
|
|
DataPath 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.
Code: |
void bSNES::video_run() {
if(r_ppu->status.frames_updated) {
char s[512], t[512];
r_ppu->status.frames_updated = false;
// if((bool)config::gui.show_fps == true) {
sprintf(s, "%s : %d fps", BSNES_TITLE, r_ppu->status.frames_executed);
// if(w_main->frameskip != 0) {
// sprintf(t, " (%d frames)", r_ppu->status.frames_rendered);
// strcat(s, t);
// }
SDL_WM_SetCaption(s, 0);
// }
}
|
|
|
byuu 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. |
|
aminalshmu Hazed

Joined: 21 Jan 2005
Posts: 70
Location: America's Penis
|
Posted: Sun Dec 11, 2005 5:03 pm Post subject: |
|
byuu wrote: |
The SDL port has no GUI to toggle the frameskip rate, so you'd have to recompile it to change the frameskipping rate. |
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...
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Dec 12, 2005 12:19 am Post subject: |
|
Try this:
Code: |
int g_frameskip = 1; //2, 3, ...
int g_frakeskip_pos = 0;
void bSNES::video_run() {
if(r_ppu->status.frames_updated) {
char s[512], t[512];
r_ppu->status.frames_updated = false;
if((bool)config::gui.show_fps == true) {
sprintf(s, "%s : %d fps", BSNES_TITLE, r_ppu->status.frames_executed);
if(g_frameskip != 0) {
sprintf(t, " (%d frames)", r_ppu->status.frames_rendered);
strcat(s, t);
}
SDL_WM_SetCaption(s, 0);
}
}
g_frameskip_pos++;
g_frameskip_pos %= (g_frameskip + 1);
if(r_ppu->renderer_enabled())dd_renderer->update();
r_ppu->enable_renderer(g_frameskip_pos == 0);
} |
|
|
aminalshmu Hazed

Joined: 21 Jan 2005
Posts: 70
Location: America's Penis
|
Posted: Mon Dec 12, 2005 1:27 am Post subject: |
|

Code: |
c++ -O3 -fomit-frame-pointer -ffast-math -march=prescott -pipe -fno-rtti -c sdlmain.cpp `sdl-config --cflags`
sdlmain.h:17: warning: non-local variable '<anonymous struct> screen_info' uses anonymous type
bsnes.cpp: In member function 'virtual void bSNES::video_run()':
bsnes.cpp:21: error: 'gui' is not a member of 'config'
bsnes.cpp:31: error: 'g_frameskip_pos' was not declared in this scope
bsnes.cpp:33: error: 'dd_renderer' was not declared in this scope
../snes/snes.h: At global scope:
../snes/snes.h:23: warning: inline function 'virtual void SNES::runtoframe()' used but never defined
make: *** [sdlmain.o] Error 1
|
I hope to soon learn enough C++ to at least understand how to fix something like this... it seems pretty trivial.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Wed Dec 14, 2005 6:57 pm Post subject: |
|
Sweet, an update! |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Dec 15, 2005 8:07 am Post subject: |
|
Shinrin Alex Cole wrote: |
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. |
You haven't heard anything yet...
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Dec 15, 2005 8:26 am Post subject: |
|
pagefault wrote: |
Shinrin Alex Cole wrote: |
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. |
You haven't heard anything yet...
|
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
|
|
Jipcy 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?
grinvader wrote: |
1-
Easiest case once the binary 94-char packing is done in parsegen would
be to use it to generate states. Each var would get assigned and read
independently, any extra variable wouldn't be read and if a var was
missing we could add an auto-initializer for those. Big advantage:
states would now be plain text and extremely easily editable for
hacking or debugging, at the expense of a fair size increase. |
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
byuu 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>
Quote: |
byuu, in your eventual implementation of save states, do you have any interest in doing something like this? |
Not really, but I don't think it'd be that hard to do...
|
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Thu Dec 15, 2005 10:23 am Post subject: |
|
byuu wrote: |
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>
Quote: |
byuu, in your eventual implementation of save states, do you have any interest in doing something like this? |
Not really, but I don't think it'd be that hard to do...
|
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.
|
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Dec 15, 2005 10:37 am Post subject: |
|
Quote: |
LOL, Give all the credit to Nach. We currently only have this sound working on movie writing. |
So that's an entirely rewritten sound core? If so, is it using anomie's DSP emulation code?
Quote: |
Hopefully when everything is done we will have mirror copies of eachother in various things. |
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.
Quote: |
Good luck with your continued work on bsnes, it's a great project. |
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.
|
|
Nach 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 |
|
byuu 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. |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Dec 15, 2005 2:56 pm Post subject: |
|
byuu wrote: |
Ah, that's... odd. |
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
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Dec 15, 2005 10:49 pm Post subject: |
|
byuu wrote: |
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. |
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/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Dec 16, 2005 12:31 am Post subject: |
|
Jipcy wrote: |
byuu wrote: |
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. |
Please let your fanbase know if there's anything we can do to maintain/improve your motivation.
|
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
|
|
xamenus 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.  |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Fri Dec 16, 2005 2:23 am Post subject: |
|
FitzRoy wrote: |
Jipcy wrote: |
byuu wrote: |
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. |
Please let your fanbase know if there's anything we can do to maintain/improve your motivation.
|
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!
|
Hopeless? Things getting broken is not something anyone does on
purpose. It is bound to happen to every emulator at some point.
|
|
FitzRoy 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. |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Dec 16, 2005 11:40 am Post subject: |
|
Quote: |
Honestly though, you work so quickly as it is, and the amazing thing is you're fixing stuff without breaking other crap. |
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.
Quote: |
I also think it's nice to see sound getting some emphasis. |
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.
|
|
FitzRoy 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.  |
|
Jipcy 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/ |
|
byuu 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. |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Dec 20, 2005 10:45 pm Post subject: |
|
byuu wrote: |
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?
|
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.
|
|
Deathlike2 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. |
|
byuu 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. |
|
Deathlike2 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. |
|
byuu 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. |
|
Deathlike2 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. |
|
byuu 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. |
|
PiCiJi 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. |
|
xamenus Zealot

Joined: 29 Jul 2004
Posts: 1218
|
Posted: Fri Dec 30, 2005 11:03 pm Post subject: |
|
PiCiJi wrote: |
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. |
If you would read the bsnes changelogs or website, you'd know that the triple buffering code is buggy in .015.
|
|
byuu 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. |
|
FitzRoy 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? |
|
PiCiJi 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. |
|
|
FitzRoy 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... |
|
Jipcy 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/ |
|
FitzRoy 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. |
|
byuu 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. |
|
DataPath 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? |
|
Nightcrawler 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. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Jan 05, 2006 5:00 pm Post subject: |
|
byuu wrote: |
...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* |
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"
|
|
DataPath 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. |
|
Jagasian 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? |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Wed Jan 18, 2006 6:55 pm Post subject: |
|
Jagasian wrote: |
and get ported to every platform under the sun as is the case with SNES9x and ZSNES. |
Uh, what? ZSNES has three ports. Windows, DOS, SDL. Just fyi, ZSNES is incapable of running on a non-x86 CPU.
Jagasian wrote: |
I'd love to see an Xbox 360 port, if the 360 was capable of running bsnes at full speed. Is it capable? |
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/
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Wed Jan 18, 2006 8:23 pm Post subject: |
|
Jagasian wrote: |
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. |
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.
Quote: |
I'd love to see an Xbox 360 port, if the 360 was capable of running bsnes at full speed. Is it capable? |
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
|
|
Jipcy 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/ |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Wed Jan 18, 2006 9:10 pm Post subject: |
|
Jipcy wrote: |
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. |
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!
|
|
FitzRoy 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. |
|
sweener2001 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.
_________________
 |
|
Jagasian 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. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Jan 19, 2006 2:46 am Post subject: |
|
sweener2001 wrote: |
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. |
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).
|
|
sweener2001 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.
_________________
 |
|
byuu 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. |
|
DataPath 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. |
|
Jagasian Rookie
Joined: 15 Oct 2004
Posts: 24
|
Posted: Thu Jan 19, 2006 5:41 pm Post subject: |
|
byuu wrote: |
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. |
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.
|
|
FitzRoy 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.  |
|
sweener2001 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.
_________________
 |
|
FitzRoy 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. |
|
Aerdan 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. |
|
|
adventure_of_link 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? |
|
Clements 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 |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Mon Jan 23, 2006 1:50 am Post subject: |
|
Aerdan wrote: |
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. |
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.
|
|
byuu 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 ;) |
|
creaothceann 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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
FitzRoy 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? |
|
Aerdan 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.] |
|
byuu 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... |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Tue Jan 24, 2006 7:38 pm Post subject: |
|
Aerdan wrote: |
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.]
|
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.
|
|
PiCiJi 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. |
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Mon Jan 30, 2006 1:44 pm Post subject: |
|
PiCiJi wrote: |
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. |
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.
|
|
Dmog 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? |
|
Nach 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 |
|
byuu 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. |
|
Reznor007 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. |
|
Nach 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 |
|
byuu 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 :/ |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Wed Feb 01, 2006 11:20 am Post subject: |
|
byuu wrote: |
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.
|
Did I ever pass you MK's spec?
byuu wrote: |
Nach, can we meet up this weekend? I'd like to finalize the patching thing, if possible.
|
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
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Wed Feb 01, 2006 1:11 pm Post subject: |
|
byuu wrote: |
[...] That's going to take an insane amount of planning to pull off without doubling the system requirements :/ |
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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
oxid 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
byuu wrote: |
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. |
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.
|
|
byuu 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 =
Code: |
crc32=0xdeadbeef
title="Game X"
publisher="Nintendo"
region="US"
language="EN"
genre="Action"
;below is a linear breakdown of the file
[rom]
size=8mbit
;do we need ranges in case some ROMs get clipped?
map="$c00000-$cfffff"
map="$e00000-$efffff"
[rom]
size=4mbit
speed=120ns ;overkill?
map="$d00000-$d7ffff"
map="$d80000-$dfffff"
;how about implied mirroring when map size > rom size? e.g.
map="$f00000-$ffffff"
[sram] ;not actually stored in cart, although we could change that... ;)
size=1mbit
map="$700000-$701fff"
map="$702000-$703fff"
...
[dsp1b]
dr="$006000-$006fff"
sr="$007000-$007fff"
|
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"
|
|
Nach 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 |
|
creaothceann 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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
FitzRoy 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. |
|
|
byuu 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... |
|
FitzRoy 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? |
|
error999 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 |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
error999 New Member

Joined: 07 Feb 2006
Posts: 5
|
Posted: Sun Feb 12, 2006 4:20 am Post subject: |
|
Jipcy wrote: |
Leave your puerile feature requests out of this thread. |
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
|
|
DataPath 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. |
|
Deathlike2 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. |
|
byuu 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. |
|
error999 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 <------ |
|
Agozer 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. |
|
Deathlike2 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.
byuu wrote: |
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. |
Well, seeing as the savestate spec in ZSNES has changed quite a bit post-1.42, I guess I can't blame you there.
Quote: |
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. |
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.
|
|
byuu 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. |
|
DataPath 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. |
|
Jipcy 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/ |
|
FitzRoy 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. |
|
byuu 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. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Feb 16, 2006 12:28 am Post subject: |
|
Jipcy wrote: |
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. |
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.
|
|
franpa 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. |
|
byuu 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. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Feb 16, 2006 5:59 am Post subject: |
|
byuu wrote: |
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. |
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.
Quote: |
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. |
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.
Quote: |
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. |
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...
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Thu Feb 16, 2006 11:42 am Post subject: |
|
byuu wrote: |
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. |
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
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Feb 16, 2006 12:53 pm Post subject: |
|
Nach wrote: |
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. |
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.
|
|
grinvader ZSNES Plasma Prinny


Joined: 28 Jul 2004
Posts: 4019
Location: PAL50
|
Posted: Thu Feb 16, 2006 1:14 pm Post subject: |
|
Dmog wrote: |
Nach wrote: |
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. |
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.
|
Yes, that's often the case (SotN for one).
_________________
皆黙って俺について来い!!
Code: |
<pagefault> franpa is pedobear
<pagefault> he has been hiding posting stupid comments |
Pantheon: Gideon Zhi | CaitSith2 | Nach
|
|
byuu 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.
Quote: |
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. |
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
|
|
franpa 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. |
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Feb 16, 2006 1:47 pm Post subject: |
|
franpa_9 wrote: |
also do you plan on adding a feature to disable the sound core like zsnes does? (disable spc emulation) |
What would be the point of that? Many games depend on it.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
franpa 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. |
|
PiCiJi 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? |
|
franpa 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. |
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Feb 19, 2006 3:24 pm Post subject: |
|
PiCiJi wrote: |
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? |
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.
|
|
byuu 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. |
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Feb 20, 2006 2:27 am Post subject: |
|
franpa_9 wrote: |
its for the sake of accuracy and bsnes goal i think is to be the most accurate snes emulator. |
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.
|
|
franpa 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. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Feb 20, 2006 2:42 am Post subject: |
|
franpa_9 wrote: |
i would think that gens is better then kega but since ive never used kega i cant compare. |
Well, you're wrong.
franpa_9 wrote: |
now back on topic people. |
What's off topic? The brief mention of a Sega emulator?
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Feb 20, 2006 2:44 am Post subject: |
|
franpa_9 wrote: |
i would think that gens is better then kega but since ive never used kega i cant compare. |
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
|
|
franpa 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. |
|
King Of Chaos 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.  |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Mon Feb 20, 2006 4:33 am Post subject: |
|
King Of Chaos wrote: |
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).  |
Although Kega does have a large number of features, unlike bsnes.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Mon Feb 20, 2006 4:53 am Post subject: |
|
Jipcy wrote: |
King Of Chaos wrote: |
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).  |
Although Kega does have a large number of features, unlike bsnes.
|
Yes, that's because Kega has matured over a long amount of time. bsnes
is still growing up...And it will, someday.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 23, 2006 3:56 am Post subject: |
|
byuu wrote: |
I
would estimate that bsnes would run 2-3x faster if it used the typical
approach of emulating processors opcode-by-opcode. But this would be
less hardware-accurate, and that's simply unacceptable to me. |
byuu wrote: |
So
the cycle-based CPU core is 4-8x more synchronized than the
opcode-based core. Now think of splitting each cycle into 3-6 separate
functions. That's what I'm working on now. And yes, it is very, very
slow. About 27x slower. Good thing the CPU isn't the major bottleneck
to speed. Or at least, it wasn't. But fear not, those of you with
slower processors! I'm also planning to make another CPU core that will
be opcode-based. Much as the clock-stepping core lowers speed by 30%,
the new opcode-stepping core should increase speed by 30% over v0.015.
The current cycle-based CPU core I may or may not continue to maintain.
I don't really even want to maintain two CPU cores, let alone three,
but I don't really have a choice. |
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...?
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
DataPath 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 |
|
Starman Ghost 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? |
|
byuu 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. |
|
FitzRoy 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... |
|
sweener2001 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.
_________________
 |
|
creaothceann 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?
byuu wrote: |
Now then, anyone up for writing some filters? :) |
You could add HQ?x... 
Starman Ghost wrote: |
Would it be stupid to code Clockcycle based emulator in basic? |
Depends on your compiler. Some people are saying that FreeBasic is a good one.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
byuu 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.
Quote: |
Something tells me there is more to all this than meets the eye... |
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.
Quote: |
You could add HQ?x... |
I was suggesting others do this :P
I just wanted the filter ability there for the SNES NTSC filter.
|
|
Nightcrawler Romhacking God
Joined: 28 Jul 2004
Posts: 1899
|
Posted: Thu Feb 23, 2006 1:45 pm Post subject: |
|
sweener2001 wrote: |
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. |
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.
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Feb 23, 2006 7:18 pm Post subject: |
|
FitzRoy wrote: |
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. |
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".
Quote: |
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). |
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.
Quote: |
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. |
You could just say "don't report bugs when using the opcode core".
Quote: |
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! |
Quote: |
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. |
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)
|
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 23, 2006 9:21 pm Post subject: |
|
byuu wrote: |
Quote: |
Something tells me there is more to all this than meets the eye... |
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.
|
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?
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 23, 2006 9:48 pm Post subject: |
|
Dmog wrote: |
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".
|
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.
Quote: |
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. |
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.
Quote: |
You could just say "don't report bugs when using the opcode core". |
I'm not entirely sure what you mean by this. Please re-read my statement. Bugfix is not a bug report.
Quote: |
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) |
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.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Feb 23, 2006 10:06 pm Post subject: |
|
FitzRoy wrote: |
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. |
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/
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Thu Feb 23, 2006 10:19 pm Post subject: |
|
Jipcy wrote: |
FitzRoy wrote: |
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. |
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.
|
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?
|
|
sweener2001 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.
_________________
 |
|
Jipcy 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/ |
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Thu Feb 23, 2006 11:56 pm Post subject: |
|
Quote: |
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? |
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
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Thu Feb 23, 2006 11:58 pm Post subject: |
|
FitzRoy wrote: |
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. |
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
Quote: |
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 |
Quote: |
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. |
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'!
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Feb 24, 2006 12:21 am Post subject: |
|
byuu wrote: |
No point in striking middle grounds. But if everyone disagrees with me, that's fine |
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?
|
|
Jipcy 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 |
|
Sith 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 |
|
King Of Chaos 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* |
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 24, 2006 6:46 am Post subject: |
|
byuu wrote: |
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  |
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.
byuu wrote: |
You make a good point, though. I could keep the curren
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. |
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.
byuu wrote: |
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. |
Absolutely.
byuu wrote: |
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. |
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.
byuu wrote: |
Also, 10ghz is a bit sarcastic. 5-7ghz will do just fine  |
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Fri Feb 24, 2006 7:32 am Post subject: |
|
Quote: |
Is this kinda how SNES emulation works right now: |
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.
Quote: |
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). |
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.
Quote: |
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. |
Thanks, I've always been a big fan of Steve's work since the original KGen for DOS.
Quote: |
I always understood your rationale for clockcyle. You're a perfectionist. |
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? :)
Quote: |
For the same reason, I didn't quite understand dropping a perfectly wonderful cycle core for opcode. |
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.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Feb 24, 2006 11:28 am Post subject: |
|
byuu wrote: |
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?  |

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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Fri Feb 24, 2006 12:50 pm; edited 1 time in total
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Feb 24, 2006 12:22 pm Post subject: |
|
FitzRoy wrote: |
So long as it has no effect on games |
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"
creaothceann wrote: |
byuu wrote: |
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?  |

Erm, more than 10 GHz... ?
|
No idea either 
A wild guess would be: Future M.e.s.s Saturn emulation 3X requirements = so yes more than 10ghz.
Quote: |
The best emus around:
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
Nestopia also deserve a mention! unless you really,truly hate Nes
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Fri Feb 24, 2006 6:50 pm Post subject: |
|
byuu.org wrote: |
In
preparation, I went ahead and rewrote a bunch of the video rendering
code, so that software filters can be used. So far, so good. I've added a Scale2x filter for now. It's actually not as slow as I thought it would be, especially for being completely unoptimized. |
Sweet Jesus, thank you!
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Fri Feb 24, 2006 7:05 pm Post subject: |
|
Dmog wrote: |
Quote: |
The best emus around:
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
Nestopia also deserve a mention! unless you really,truly hate Nes
|
I don't hate NES, just never had one. Anyways, there's no more room left in my sig.
creaothceann wrote: |
byuu wrote: |
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? |
Erm, more than 10 GHz... ?
|
Not according to Steve, accurate Saturn emulation can be achieved with less than 5GHz
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Feb 24, 2006 9:13 pm Post subject: |
|
Sith-Smasher wrote: |
Dmog wrote: |
Quote: |
The best emus around:
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
Nestopia also deserve a mention! unless you really,truly hate Nes
|
I don't hate NES, just never had one. Anyways, there's no more room left in my sig.
creaothceann wrote: |
byuu wrote: |
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? |
Erm, more than 10 GHz... ?
|
Not according to Steve, accurate Saturn emulation can be achieved with less than 5GHz
|
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..
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Fri Feb 24, 2006 9:51 pm Post subject: |
|
Dmog wrote: |
FitzRoy wrote: |
So long as it has no effect on games |
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"
|
I'm a little confused by your accusation. I think I'll need an elaboration before I even attempt to defend myself.
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Fri Feb 24, 2006 10:03 pm Post subject: |
|
Dmog wrote: |
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 rock.. |
Yes, he hinted abt that in Sega Emulation Forums so he might at least be considering it.
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
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Feb 24, 2006 10:13 pm Post subject: |
|
FitzRoy wrote: |
Dmog wrote: |
FitzRoy wrote: |
So long as it has no effect on games |
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"
|
I'm a little confused by your accusation. I think I'll need an
elaboration before I even attempt to defend myself.
|
Ok,exageration on my part perhaps.
You did express concern over bsnes's future speed though:
Quote: |
Cycle-based was the perfect accuracy/performance hybrid |
Quote: |
Cycle is being discontinued for an unusable clockcycle core |
Quote: |
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 |
No "accusations" I just think speed shouldn't be a big concern.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Fri Feb 24, 2006 10:35 pm Post subject: |
|
byuu wrote: |
Quote: |
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). |
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.
|
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).
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Feb 24, 2006 11:45 pm Post subject: |
|
Jipcy wrote: |
byuu.org wrote: |
In
preparation, I went ahead and rewrote a bunch of the video rendering
code, so that software filters can be used. So far, so good. I've added a Scale2x filter for now. It's actually not as slow as I thought it would be, especially for being completely unoptimized. |
Sweet Jesus, thank you!
|
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:
Quote: |
So
blargg is working on an absolutely stunning SNES NTSC video filter. And
lucky me, he's going to let me use his code in bsnes. If he's able to
figure out hires color blending, then we should finally have proper
pseudo-hires emulation at long last. Whether you like his NTSC filter
or not, this is the only accurate way you'll ever be able to view
pseudo-hires, and for that matter all hires color math the way it was
intended. I can't wait. In preparation, I went ahead and rewrote a
bunch of the video rendering code, so that software filters can be
used. So far, so good. I've added a Scale2x filter for now. It's
actually not as slow as I thought it would be, especially for being
completely unoptimized. It only drops the framerate from 80 to 74 on my
Athlon 3500+. But of course, the extra translation layer needed for the
renderer drops the original renderer by 6fps as well. But that can't be
helped. I can't expect the filters to accomodate the potential variable
width of each SNES scanline (e.g. hires can be toggled mid-frame). So
as of now, the PPU renders each line into a buffer, and each line has
information on whether hires and/or interlace is enabled. Then at the
end of the frame, an internal function is called to "normalize" the PPU
buffer. Or in other words, make the width even for all scanlines and
double scanlines where needed if interlace is toggled mid-frame. Then
that buffer is passed to the software renderer, which performs its
magic on the raw BGR555 data, and outputs the resulting data directly
into video memory, which is then scaled and blitted to the screen.
For now, the filter system can be viewed here, and a screenshot of the
Scale2x filter in action can be viewed here. Now then, anyone up for
writing some filters? 
02/21/2006 - aCPU
Short for accurate CPU. Basically, for future plans and increased
accuracy, it's neccesary for me to move bsnes to a new clock-stepping
CPU core. Think of an opcode-based CPU core where one opcode is
executed at a time. Then think of a cycle-based CPU core that splits
each opcode into 4-8 separate functions, and after each cycle,
everything is synchronized. So the cycle-based CPU core is 4-8x more
synchronized than the opcode-based core. Now think of splitting each
cycle into 3-6 separate functions. That's what I'm working on now. And
yes, it is very, very slow. About 27x slower. Good thing the CPU isn't
the major bottleneck to speed. Or at least, it wasn't.
But fear not, those of you with slower processors! I'm also planning to
make another CPU core that will be opcode-based. Much as the
clock-stepping core lowers speed by 30%, the new opcode-stepping core
should increase speed by 30% over v0.015.
The current cycle-based CPU core I may or may not continue to maintain.
I don't really even want to maintain two CPU cores, let alone three,
but I don't really have a choice. And just to say this now: savestates
(when I finally add them) between the two CPU cores won't be
compatible, sorry.
Now as far as finishing these things, I've actually been moving through
the new clock-based core surprisingly fast. It'll probably be 2-3
months before it's ready. The hard part is going to be porting all of
the NMI/IRQ/(H)DMA stuff over, and especially breaking those down
enough to step by individual clock cycles.
In other news, I've added two new filter options to control both the
non-interlace and interlace scanline intensities. 0% being disabled,
100% being solid black, adjustable by increments of 1% at a time. I
removed the "Enable scanlines" checkbox as it's redundant. 0% can be
used to disable scanlines now. Hopefully that won't confuse anyone.
You can take a peek at the source code to the new aCPU here. I'd love
to get some feedback from programmers on this new design, specifically
for timing/timing.cpp:aCPU::run_clock(). Any optimizations here would
be a huge help. |
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
|
|
Sith 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 |
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sat Feb 25, 2006 12:04 am Post subject: |
|
Quote: |
So
as of now, the PPU renders each line into a buffer, and each line has
information on whether hires and/or interlace is enabled. Then at the
end of the frame, an internal function is called to "normalize" the PPU
buffer |
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.
|
|
byuu 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.
Quote: |
Sweet Jesus, thank you! |
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.
Quote: |
Yep, using 2x mode (120fps) only uses 61% system resources with no sound breakup. |
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 :(
Quote: |
So Bsnes will have a plugin system like Kega? Cool! |
Internal only, but yes. Anyone is free to submit drivers and I'll add them in.
Quote: |
Ot question, but do you think there's any chance that this might cause input delay? |
Nah, it'll be equally as responsive. This new code is inserted between
two parts where the SNES is technically completely paused.
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Sat Feb 25, 2006 3:15 am Post subject: |
|
byuu wrote: |
Quote: |
Sweet Jesus, thank you! |
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.
|
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/
|
|
FitzRoy 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. |
|
Sith 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 |
|
King Of Chaos 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.  |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Feb 25, 2006 7:45 pm Post subject: |
|
byuu wrote: |
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.
|
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
|
|
Deathlike2 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. |
|
Jipcy 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/ |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Feb 25, 2006 8:51 pm Post subject: |
|
Deathlike2 wrote: |
What exactly is different with the Scale2x license than with most of the others?
|
Most of the other what? bsnes doesn't implement any other filters.
Deathlike2 wrote: |
I presume it is literally the reason that it was not implemented on ZSNES. |
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
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Feb 25, 2006 8:58 pm Post subject: |
|
Nach wrote: |
Deathlike2 wrote: |
What exactly is different with the Scale2x license than with most of the others?
|
Most of the other what? bsnes doesn't implement any other filters.
Deathlike2 wrote: |
I presume it is literally the reason that it was not implemented on ZSNES. |
Scale2x license is compatible with ZSNES'
|
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.
|
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Feb 25, 2006 9:00 pm Post subject: |
|
Deathlike2 wrote: |
Is there any reason why Scale2x isn't implemented in ZSNES then? |
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
|
|
byuu 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:
Quote: |
It is also used in some closed source projects (which use rewritten implementations due the license restrictions) :
* Nebula
* Kawaks (with the name KScale)
* Pocket RPG Maker 2005/10 |
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.
|
|
pagefault 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? |
|
Nach ZSNES Developer


Joined: 27 Jul 2004
Posts: 4328
|
Posted: Sat Feb 25, 2006 9:46 pm Post subject: |
|
byuu wrote: |
I did not use Scale2x' source code. I wrote my own implementation of it. |
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
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Sat Feb 25, 2006 9:52 pm Post subject: |
|
pagefault wrote: |
Do you guys just want a forum for bsnes so we can avoid this 1000000 page thread business? |
Yes, please.
_________________
Zsnes WIP
Bsnes by Byuu
Kega Fusion by SteveSnake
Vice by Viceteam
|
|
kevman 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. |
|
King Of Chaos 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. |
|
byuu 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. |
|
KingHanco 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. |
|
pagefault ZSNES Developer


Joined: 17 Aug 2004
Posts: 887
Location: In your garden
|
Posted: Sun Feb 26, 2006 2:09 pm Post subject: |
|
byuu wrote: |
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. |
Ah it's no problem. I just thought it would make it easier for everyone.
|
|
King Of Chaos Regular

Joined: 20 Feb 2006
Posts: 315
Location: Branson, Missouri USA
|
Posted: Sun Feb 26, 2006 4:02 pm Post subject: Re: Cheat thing. |
|
KingHanco wrote: |
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. |
Probably. But you'll probably need a powerful machine to run it.
|
|
Sith 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 |
|
KingHanco 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. |
|
Agozer 16-bit Corpse | Nyoron


Joined: 01 Aug 2004
Posts: 5361
Location: Nokia Land
|
Posted: Sun Feb 26, 2006 8:31 pm Post subject: Re: ... |
|
KingHanco wrote: |
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. |
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.
|
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Sun Feb 26, 2006 9:44 pm Post subject: Re: ... |
|
KingHanco wrote: |
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. |
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)
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Mon Feb 27, 2006 12:36 am Post subject: Re: ... |
|
Dmog wrote: |
KingHanco wrote: |
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. |
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)
|
You can run games on Zsnes to verify use of special chips since it displays any special chips used in the rom info.
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
|
|
Aerdan 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. |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Tue Feb 28, 2006 5:48 pm Post subject: |
|
Aerdan wrote: |
Or, you could just go use NSRT, which gives more information than ZSNES does and tells you if your ROM is corrupt. |
Oh, yes. Thanks for that info. 
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
|
|
KingHanco 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.  |
|
byuu 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. |
|
FitzRoy 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.  |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 03, 2006 7:19 am Post subject: |
|
FitzRoy wrote: |
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.  |
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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Fri Mar 03, 2006 4:37 pm Post subject: |
|
FitzRoy wrote: |
..., despite your awesome idea to position buttons in the shape of one. Why? |
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
|
|
FitzRoy 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  |
|
creaothceann 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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
tetsuo55 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! |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
Posted: Sun Mar 05, 2006 4:28 pm Post subject: Re: unified rom database |
|
tetsuo55 wrote: |
Any updates on the rom database?? i would like to help out get this off the ground! |
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
|
|
tetsuo55 Regular
Joined: 04 Mar 2006
Posts: 301
|
Posted: Sun Mar 05, 2006 4:45 pm Post subject: Re: unified rom database |
|
Sith-Smasher wrote: |
tetsuo55 wrote: |
Any updates on the rom database?? i would like to help out get this off the ground! |
Huh? Wrong thread, man.
That's NSRT stuff.
|
Actually nash and byuu where working toghether to create a new database
that will be included in both NSRT and bsnes/zsnes
|
|
byuu 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. |
|
FitzRoy 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. |
|
Sith 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 |
|
DMV27 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.
byuu wrote: |
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? :/ |
TreeView
|
|
KingHanco 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."  |
|
byuu 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
Quote: |
bcpu_mmio.patch fixes Castlevania - Dracula X |
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 ...
Quote: |
bdsp.patch fixes the sounds in Earthworm Jim 2 |
... there was a problem with them before?
Quote: |
bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code |
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 :/
Quote: |
dinput.patch and ui_ppucfg.patch both fix macros for GCC |
Oh, I forgot to add that last time, sorry.
Quote: |
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. |
I'll do just that, thanks. I didn't think that would be an issue with only 128kb/s of data.
|
|
FitzRoy Zealot

Joined: 04 Aug 2004
Posts: 1078
|
Posted: Sat Mar 11, 2006 3:21 am Post subject: |
|
DMV27 wrote: |
http://rapidshare.de/files/15154041/bsnes-patch-2006-03-10.zip.html
[list]
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.
|
OH MY FUCKING GAWD! LEFT FIELD!
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Mar 11, 2006 7:04 am Post subject: |
|
Quote: |
bcpu_mmio.patch fixes Castlevania - Dracula X |
Added. Works exactly as stated.
Quote: |
bdsp.patch fixes the sounds in Earthworm Jim 2 |
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).
Quote: |
bppu.patch fixes the sprites in Final Fantasy - Mystic Quest and adds some untested Sprite+Y priority code |
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.
Quote: |
dinput.patch and ui_ppucfg.patch both fix macros for GCC |
Added.
Quote: |
Makefile.mingw can be used to compile bsnes with msys/mingw/gcc |
I'll include it with the release, but I can't maintain it as I don't have MinGW.
Quote: |
bsnes.exe is compiled without the DSBCAPS_LOCSOFTWARE flag because software sound mixing causes high cpu usage on my computer. |
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.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Mar 11, 2006 7:16 am Post subject: |
|
byuu wrote: |
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  |
And you call that bad... 
Quote: |
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. |
Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support.
_________________
FF4 research never ends for me.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Sat Mar 11, 2006 7:21 am Post subject: |
|
Quote: |
Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support. |
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.
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Sat Mar 11, 2006 7:27 am Post subject: |
|
byuu wrote: |
Quote: |
Nice... but no Goldfinger? I'm only suggesting it to be complete with the cheat support. |
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.
|
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
|
|
|
byuu 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 :/ |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
DMV27 Rookie
Joined: 27 Jan 2005
Posts: 32
|
Posted: Mon Mar 13, 2006 10:42 am Post subject: |
|
byuu wrote: |
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 :/ |
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.
Quote: |
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 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.
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
Posted: Mon Mar 13, 2006 1:13 pm Post subject: |
|
Quote: |
The "0xa" in anomie's regs.txt is actually the variable 'A' as in 'Address'. |
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.
Quote: |
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. |
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.
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Mon Mar 13, 2006 2:44 pm Post subject: |
|
DMV27 wrote: |
Also, Uniracers 2-player mode updates oam mid-frame. |
Almost all split-screen games should do that (e.g. Contra 3) ...
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
FitzRoy 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. |
|
Sith 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 |
|
King Of Chaos 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.  |
|
byuu 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. |
|
tetsuo55 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? |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Mar 16, 2006 9:00 am Post subject: |
|
tetsuo55 wrote: |
BTW my monitor supposedly supports 70hz refreshrate (Samsung Syncmaster 710t) any point in using 70hz? |
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
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
Last edited by creaothceann on Thu Mar 16, 2006 10:44 am; edited 1 time in total
|
|
tetsuo55 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 |
|
Clements Randomness

Joined: 28 Jul 2004
Posts: 2313
Location: Britain
|
|
kieran_ Mugwump

Joined: 30 Jul 2004
Posts: 2966
|
Posted: Thu Mar 16, 2006 2:31 pm Post subject: |
|
Clements wrote: |
Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz. |
Why?
I know nothing of these things, other than anythng less than 85Hz kills my eyes.
|
|
Jipcy 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.
herzog wrote: |
Clements wrote: |
Refresh rates are only important in CRT monitors, and not LCD monitors. Leave the LCD @ 60Hz. |
Why?
I know nothing of these things, other than anythng less than 85Hz kills my eyes.
|
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
|
|
Clements 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 |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Mar 16, 2006 4:46 pm Post subject: |
|
Jipcy wrote: |
... since there is also the SNES-internal Modes 1-7. |
Actually it's 0-7.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
KingHanco 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."  |
|
kieran_ 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. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
Posted: Thu Mar 16, 2006 6:10 pm Post subject: |
|
creaothceann wrote: |
Jipcy wrote: |
... since there is also the SNES-internal Modes 1-7. |
Actually it's 0-7.
|
Whoops. I think the intention of my words were clear, though.
KingHanco wrote: |
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.  |
Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh.
_________________
Official ZSNES Docs
http://www.flickr.com/photos/jipcy/
|
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Thu Mar 16, 2006 7:36 pm Post subject: |
|
Jipcy wrote: |
creaothceann wrote: |
Jipcy wrote: |
... since there is also the SNES-internal Modes 1-7. |
Actually it's 0-7.
|
Whoops. I think the intention of my words were clear, though.
|
Yeah. I was wondering about it as well.
Jipcy wrote: |
KingHanco wrote: |
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.  |
Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh.
|
Is the TFT actually fast enough that it makes a difference? 
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
Deathlike2 ZSNES Developer

Joined: 28 Dec 2004
Posts: 5599
|
Posted: Thu Mar 16, 2006 7:48 pm Post subject: |
|
creaothceann wrote: |
Jipcy wrote: |
creaothceann wrote: |
Jipcy wrote: |
... since there is also the SNES-internal Modes 1-7. |
Actually it's 0-7.
|
Whoops. I think the intention of my words were clear, though.
|
Yeah. I was wondering about it as well.
Jipcy wrote: |
KingHanco wrote: |
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.  |
Wow, that's impressive. I wish my video card and monitor supported 180Hz refresh.
|
Is the TFT actually fast enough that it makes a difference?
|
Refresh rates shouldn't really affect LCDs, but rather the game it is running on...
_________________
FF4 research never ends for me.
|
|
byuu 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? |
|
Ichinisan 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. |
|
|
byuu 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. |
|
Deathlike2 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. |
|
Sith Trooper
Joined: 19 Jul 2005
Posts: 358
Location: Belgium
|
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Dmog 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. |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
Dmog Trooper
Joined: 31 Aug 2004
Posts: 417
|
Posted: Fri Mar 17, 2006 6:46 pm Post subject: |
|
Jipcy wrote: |
Dmog wrote: |
'per Snes display mode configuration' |
What?
|
...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.
|
|
adventure_of_link 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? |
|
creaothceann Seen it all

Joined: 03 Jan 2005
Posts: 2324
Location: Germany
|
Posted: Fri Mar 17, 2006 7:32 pm Post subject: |
|
Dmog wrote: |
...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. |
Read again:
byuu wrote: |
The ten video modes can be cycled via ctrl+[1-0] or Menu->Settings->Video Mode->[1-0] |
SNES has only 8 modes.
_________________
savestate editor: vSNES latest public version
FitzRoy wrote: |
Seriously, people need to stop arguing with me on this. |
|
|
MajereDB8 Rookie
Joined: 08 Oct 2005
Posts: 18
|
Posted: Fri Mar 17, 2006 10:40 pm Post subject: |
|
byuu wrote: |
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. |
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...
|
|
KingHanco 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."  |
|
byuu 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:
 |
|
Jipcy Inmate

Joined: 03 Feb 2005
Posts: 1368
Location: Shenandoah Valley
|
|
byuu bsnes Developer

Joined: 12 Oct 2004
Posts: 2414
|
|