bsnes v0.039 released

FitzRoy · Post by **FitzRoy** » Fri Feb 20, 2009 1:03 am

PiCiJi wrote:You can't check each game from beginning to the end.

The premise behind testing every game five minutes was rooted in the observation that most games show you their entire hand of cards in first five minutes. In most cases, game progression brings more changes in scenery than in behavior. There are some exceptions to this. Super Castlevania IV doesn't show Mode7 within the first 5 minutes. But it didn't matter, because many other games played that card within their first 5 minutes.

Also, even though I can't play too many games to completion myself, in the aggregate bsnes has thousands of users completing a great deal of games. We don't get squat for reports, which is a testament to how well the original premise held up. The chance of any bug eluding us using this method is very unlikely. There was one, Lemmings 2, which I should have caught but didn't because it happens at the very end of a long intro I probably skipped. It was quickly found by a casual user anyway.

The PPU behavior we're talking about seems more like a highly clever (or highly stupid) trick that would not be casually whipped out for some brief purpose later in a game. I think we can logically assert that. But even though there's a slim chance, there's no reason to tackle imaginary issues over numerous known ones.

Snark wrote:That's the point of an accurate emulator, that's the point of bsnes. I understand for some "accurate emulation" is beneficial because it allows a compatibility close to (perceived) 100% as it did in the case of bsnes...and beyond that you don't really see the point as proven by your objections to the possible future PPU renderer... but I think most here disagree on this.

Your interpretation that I "don't see the point in a PPU renderer" is incorrect. Read again. I questioned not whether it should be done, but whether it makes sense to do it before other things. And don't speak for other people, I know what users think, they've already asked about it so much that byuu had to create rules against it. You are in the vast minority if you want to put another boring 1 year window between getting more games functional in ANY snes emulator. The scene is drowning in boredom as it is, it doesn't need any help from bsnes.

Panzer88 · Post by **Panzer88** » Fri Feb 20, 2009 1:11 am

I think the point is, whether or not many games used it, it's something that the SNES could do, and something that all emulators fail to do now. A behavior of the core system that has not been emulated yet.

what game in particular are you dying to play on bsnes that you can't already play on another emulator or on your own copier.

just gotta get your starfox? big mario rpg fan? yoshi's island nut? are you even gonna play through those games if you were given the opportunity? You seem very passionate about this for someone who doesn't play all the way through most games.

FitzRoy · Post by **FitzRoy** » Fri Feb 20, 2009 1:31 am

Panzer88 wrote:I think the point is, whether or not many games used it, it's something that the SNES could do, and something that all emulators fail to do now. A behavior of the core system that has not been emulated yet.

what game in particular are you dying to play on bsnes that you can't already play on another emulator or on your own copier.

Why are you even asking this question? Star Fox is one of the greatest games of its time. It beats the living shit out of Uniracers, and so does Kirby and SMW2, frankly. BS-X could be better supported right now with no speed concerns, there were some interesting remakes there. And I'm not waiting until I'm 97 when ZSNES 2.0 comes out to play SuperFX or SA1 games with a competent sound core. That has never been possible. And who knows which glitches are from the modest chip emulation or the horribly inaccurate cores they're interacting with. For all we know, the same level of SA1 emulation in bsnes doesn't crash Super Mario RPG every 10 minutes. And we can mau-mau the CPU requirements all day, PPU is the same or worse for nothing.

Gil_Hamilton · Post by **Gil_Hamilton** » Fri Feb 20, 2009 1:53 am

FitzRoy wrote: The PPU behavior we're talking about seems more like a highly clever (or highly stupid) trick that would not be casually whipped out for some brief purpose later in a game. I think we can logically assert that. But even though there's a slim chance, there's no reason to tackle imaginary issues over numerous known ones.

Except that there's historical precedent.

I may be mistaken, but I don't think anything was affected by not blocking illegal VRAM writes. Except some hacks that cease to work properly once the writes WERE blocked.
It was a known non-issue.

There's only two possible reasons to do it.
1 is you want absolute accuracy, even if it doesn't matter.
2 is you want to make something that is useful for developing new SNES code.

Both arguments can also be applied to this case.

byuu · Post by **byuu** » Fri Feb 20, 2009 1:56 am

Gil_Hamilton wrote:I may be mistaken, but I don't think anything was affected by not blocking illegal VRAM writes. Except some hacks that cease to work properly once the writes WERE blocked.

Allowing VRAM writes during active display causes graphic corruption in Hook, at least. I believe it's sometime during the intro. Ironic bit of history, Snes9X used to have a hack to do the right think and block VRAM writes for this one specific game :P

But yeah, I don't care if proper support breaks games. Broken code isn't my concern, even if I end up breaking my own translation patches.

Post by **badinsults** » Fri Feb 20, 2009 3:27 am

The fight posts have been moved to another forum. Let us continue with relevant discussion.

byuu · Post by **byuu** » Fri Feb 20, 2009 3:33 am

badinsults wrote:The fight posts have been moved to another forum. Let us continue with relevant discussion.

Thank you, it is much appreciated.

Very sorry to have to keep inconveniencing the mods to split topics here. Without the ability to at least temp. ban people from this specific forum, I can't keep things under control myself.

As always, if hosting this forum for me gets to be too much, let me know and I'll try and set up a dedicated forum where all posts are moderated.

Everyone else, believe me I know first-hand how hard it is to avoid responding to someone attacking your character (cough RHDN), but let's not get this thread locked. Need it to post WIP news ;)

Gil_Hamilton · Post by **Gil_Hamilton** » Fri Feb 20, 2009 3:33 am

byuu wrote:
Gil_Hamilton wrote:I may be mistaken, but I don't think anything was affected by not blocking illegal VRAM writes. Except some hacks that cease to work properly once the writes WERE blocked.
Allowing VRAM writes during active display causes graphic corruption in Hook, at least. I believe it's sometime during the intro. Ironic bit of history, Snes9X used to have a hack to do the right think and block VRAM writes for this one specific game

But yeah, I don't care if proper support breaks games. Broken code isn't my concern, even if I end up breaking my own translation patches.

HAHAHA!
That's the best hack ever.

exdeath · Post by **exdeath** » Fri Feb 20, 2009 3:56 am

Talking about things that are broken.

There is bugs on the Kaite Tsukutte Asoberu Dezaemon (Japan) game

---------------------Internal ROM Info----------------------
File: Kaite Tsukutte Asoberu Dezaemon (Japan).sfc
Name: DEZAEMON Company: Athena
Header: None Bank: LoROM
Interleaved: None SRAM: 1024 Kb
Type: Normal + Batt ROM: 4 Mb
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Good 0x1D16 Game Code:
---------------------------Hashes---------------------------
CRC32: 052167CC
MD5: E6F13860E50B921EC09A89FD5B585AC7

The pictures (look at game cursor).

powerspike · Post by **powerspike** » Fri Feb 20, 2009 6:22 am

You don't see too many snes games with a self test at the beginning. But huh I went to reset Dezaemon in the file menu and it froze.

adventure_of_link · Post by **adventure_of_link** » Fri Feb 20, 2009 7:13 am

byuu wrote:
badinsults wrote:The fight posts have been moved to another forum. Let us continue with relevant discussion.
Thank you, it is much appreciated.

Very sorry to have to keep inconveniencing the mods to split topics here. Without the ability to at least temp. ban people from this specific forum, I can't keep things under control myself.

As always, if hosting this forum for me gets to be too much, let me know and I'll try and set up a dedicated forum where all posts are moderated.

Everyone else, believe me I know first-hand how hard it is to avoid responding to someone attacking your character (cough RHDN), but let's not get this thread locked. Need it to post WIP news

you DO know you can split out all irrelevant posts and put them somewhere else, right?

byuu · Post by **byuu** » Fri Feb 20, 2009 6:05 pm

exdeath wrote:Talking about things that are broken.

There is bugs on the Kaite Tsukutte Asoberu Dezaemon (Japan) game

...

The pictures (look at game cursor).

The cursor is just appearing below the text layer. Given that it does this in every SNES emulator that supports the game, it seems extra-ordinarily unlikely that this is a bug in bsnes. Still, if you can get a picture of it not doing this on your copier+TV, I'll look into it further.

byuu · Post by **byuu** » Sat Feb 21, 2009 10:39 am

New WIP. Posted only for the sake of testing for regressions.

The only real change was adding nall::property as discussed earlier, and completely revamping the Cartridge class with it. Results:
http://byuu.cinnamonpirate.com/temp/cartridge.hpp

Compared to the old version, it's night and day. All stuff that can be hidden has been, end-user can't screw with important internal-settings while emulation is active, as many functions as possible were made const, ditched char* stuff to replace with string, removed a few useless structs, simplified the public interface, replaced a memory duplication in the cart loader that removes the header with a memmove() instead, blah blah blah.

If I screwed any of this up, it may break the following:
- special chip detection
- RAM / PSRAM / RTC data saving
- UPS patching
- cheat code loading
- relative path stuff
- etc

PiCiJi · Post by **PiCiJi** » Sat Feb 21, 2009 2:21 pm

It's much easier to rewrite bsnes as a state machine. So I have done this. It's a non public version with savestate support. It has the same accuracy like bsnes, in particular the bus accuracy between cpu and smp. If I remember right the main cause for using threads in bsnes was to reduce the code complexity to achieve bus accuracy.
Whow...

Did that incurred significant speed losses?

I would say my rewrite is about 20 - 30 fps slower than the latest bsnes relating to my hardware and by using only one application thread.

But I have catched most of this speed loss with a second ppu processing thread. That gives extra frames depending on the game. The ppu thread benefits from a dual core cpu. It runs a short time real parallel to the main thread. The ppu thread must finish his work, when a ppu mmio is accessed, so current accuracy is not harmed.

I don't know if the latest bsnes uses profile guided optimization.
I have used profile guided optimization with Act Raiser 2 as the only sample for this optimization.

results are with vsync deactivated in bsnes and the statemachine, and audiosync is deactivated in bsnes. The tests are in_game tests, no intro or title screen and so on. The following values in brackets mean, when I deactivate the second cpu core for the application in windows taskmanager.

Actraiser 2:
bsnes->125 fps
state machine->145 fps (115 fps)

Jurrasic Park:
bsnes->120 fps
state machine->115 fps (90 fps)

Donkey Kong:
bsnes->135 fps
state machine->145 fps (120 fps)

StarOcean:
bsnes->122 fps
state machine->135 fps (102 fps)

Zelda 3:
bsnes->133 fps
state machine->125 fps (106 fps)

belegdol · Post by **belegdol** » Sat Feb 21, 2009 2:36 pm

The hiro ui seems to be broken currently (wip 17). I think it broke with wip16, but I'm not sure. The hiro ui is still needed for RPM packages, as until qt 4.5 release RPM Fusion cannot legally ship the qt build. Even after it's released, it is still undecided whether qt-4.5 will be pushed to older branches.

g++ -O3 -fomit-frame-pointer -Ilib -DGZIP_SUPPORT -DJMA_SUPPORT -DVIDEO_GLX -DVIDEO_XV -DVIDEO_SDL -DAUDIO_ALSA -DAUDIO_OPENAL -DAUDIO_OSS -DAUDIO_PULSEAUDIO -DAUDIO_AO -DINPUT_SDL -DINPUT_X `sdl-config --cflags` -c lib/ruby/ruby.cpp -o obj/ruby.o
In file included from ui_hiro/main.cpp:24:
ui_hiro/event/event.cpp: In function ‘void event::modify_system_state(event::system_state_t)’:
ui_hiro/event/event.cpp:158: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:160: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:165: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:166: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:167: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:168: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:171: error: ‘class Cartridge’ has no member named ‘info’
ui_hiro/event/event.cpp:183: error: ‘class Cartridge’ has no member named ‘info’
lib/../cart/cart.hpp: In function ‘void event::load_image(const char*)’:
lib/../cart/cart.hpp:95: error: ‘struct Cartridge::cartinfo_t’ is private
ui_hiro/event/event.cpp:407: error: within this context
ui_hiro/event/event.cpp:408: error: ‘class Cartridge’ has no member named ‘inspect_image’
ui_hiro/event/event.cpp:415: error: ‘TypeBSC’ is not a member of ‘Cartridge’
ui_hiro/event/event.cpp:424: error: ‘TypeBSXBIOS’ is not a member of ‘Cartridge’
ui_hiro/event/event.cpp:433: error: ‘TypeBSX’ is not a member of ‘Cartridge’
ui_hiro/event/event.cpp:442: error: ‘TypeSufamiTurboBIOS’ is not a member of ‘Cartridge’
ui_hiro/event/event.cpp: In function ‘void event::load_cart_normal(const char*)’:
ui_hiro/event/event.cpp:464: error: ‘class Cartridge’ has no member named ‘load_cart_normal’
ui_hiro/event/event.cpp: In function ‘void event::load_cart_bsc(const char*, const char*)’:
ui_hiro/event/event.cpp:473: error: ‘class Cartridge’ has no member named ‘load_cart_bsc’
ui_hiro/event/event.cpp: In function ‘void event::load_cart_bsx(const char*, const char*)’:
ui_hiro/event/event.cpp:482: error: ‘class Cartridge’ has no member named ‘load_cart_bsx’
ui_hiro/event/event.cpp: In function ‘void event::load_cart_st(const char*, const char*, const char*)’:
ui_hiro/event/event.cpp:491: error: ‘class Cartridge’ has no member named ‘load_cart_st’
make: *** [obj/main.o] Error 1

FitzRoy · Post by **FitzRoy** » Sat Feb 21, 2009 2:49 pm

PiCiJi wrote:I would say my rewrite is about 20 - 30 fps slower than the latest bsnes relating to my hardware and by using only one application thread.

Not bad. Looks like without the second core, it's about 20% slower on average. Pretty even with it.

belegdol · Post by **belegdol** » Sat Feb 21, 2009 2:52 pm

byuu, could you please have a look at adding support for hats I wrote about? Playing with an analog stick is sort of hard

Chester · Post by **Chester** » Sat Feb 21, 2009 3:34 pm

PiCiJi wrote:

It's much easier to rewrite bsnes as a state machine. So I have done this. It's a non public version with savestate support. It has the same accuracy like bsnes, in particular the bus accuracy between cpu and smp. If I remember right the main cause for using threads in bsnes was to reduce the code complexity to achieve bus accuracy.
Whow...

Did that incurred significant speed losses?
I would say my rewrite is about 20 - 30 fps slower than the latest bsnes relating to my hardware and by using only one application thread.

But I have catched most of this speed loss with a second ppu processing thread. That gives extra frames depending on the game. The ppu thread benefits from a dual core cpu. It runs a short time real parallel to the main thread. The ppu thread must finish his work, when a ppu mmio is accessed, so current accuracy is not harmed.

Very impressive and interesting.
Any chance to see it somehow published?

FirebrandX · Post by **FirebrandX** » Sat Feb 21, 2009 5:39 pm

PiCiJi wrote:

It's much easier to rewrite bsnes as a state machine. So I have done this. It's a non public version with savestate support. It has the same accuracy like bsnes, in particular the bus accuracy between cpu and smp. If I remember right the main cause for using threads in bsnes was to reduce the code complexity to achieve bus accuracy.
Whow...

Did that incurred significant speed losses?
I would say my rewrite is about 20 - 30 fps slower than the latest bsnes relating to my hardware and by using only one application thread.

But I have catched most of this speed loss with a second ppu processing thread. That gives extra frames depending on the game. The ppu thread benefits from a dual core cpu. It runs a short time real parallel to the main thread. The ppu thread must finish his work, when a ppu mmio is accessed, so current accuracy is not harmed.

Would 4 cores be of advantage for you on this, or does the concept only benefit from 2 cores. Just curious for us folks with quads

creaothceann · Post by **creaothceann** » Sat Feb 21, 2009 6:44 pm

There are only 2 threads, so more cores won't help.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Sat Feb 21, 2009 6:48 pm

creaothceann wrote:There are only 2 threads, so more cores won't help.

Not unless CPU makers implement reverse hyperthreading anyway. (which would require very fast intra-core communication, I guess)

But I think he meant: would it be useful to split the process into more threads?

FirebrandX · Post by **FirebrandX** » Sat Feb 21, 2009 7:03 pm

Verdauga Greeneyes wrote:
creaothceann wrote:There are only 2 threads, so more cores won't help.
Not unless CPU makers implement reverse hyperthreading anyway. (which would require very fast intra-core communication, I guess)

But I think he meant: would it be useful to split the process into more threads?

yep, that's what I meant. As in using 2 more cores for other processes that might give an even greater speed boost.

creaothceann · Post by **creaothceann** » Sat Feb 21, 2009 7:15 pm

Depends on what can be turned into threads.

- GUI (main program)
- SNES CPU
- SNES PPU
- SNES APU (sound)
- cartridge chips (Super FX / SA-1 / ...)
- graphics filters
- ?

byuu · Post by **byuu** » Sat Feb 21, 2009 10:28 pm

I would say my rewrite is about 20 - 30 fps slower than the latest bsnes relating to my hardware and by using only one application thread.

That sounds about right to what I was getting when I had the S-CPU / S-SMP cores encoded with state machines for each cycle. You must've found some clever workaround to get the bus hold delays supported properly without another state machine for each read/write cycle, then ... not bad. Especially for the S-CPU DMA, tons of cycle access functions there where they call several levels deep to simplify the code.

I don't know if the latest bsnes uses profile guided optimization.

No, doing so adds another +10-20% speed over v039 official.

The ppu thread benefits from a dual core cpu. It runs a short time real parallel to the main thread. The ppu thread must finish his work, when a ppu mmio is accessed, so current accuracy is not harmed.

The current PPU lends itself to these optimizations well. With v037 or so, you only need 262*60, or ~15,720 synchronizations a second. With v039, it split the S-PPU into ~4-6 sync points per scanline, so that's going to hurt the advantage a lot (though rendering at H=512 is still the only really painful part), and a purely cycle-based one that can sync at any point is going to murder performance without super-fast thread syncing primitives -- ~100x faster than standard mutexes.

The hiro ui seems to be broken currently (wip 17). I think it broke with wip16, but I'm not sure.

Yeah, sorry. I'll make sure it works for release. Just kind of apathetic to keeping it up to date with each WIP.

byuu, could you please have a look at adding support for hats I wrote about? Playing with an analog stick is sort of hard

Mine maps the D-pad as axes. It'll be harder to support something my controller doesn't even support, but I can try sometime yes.

Very impressive and interesting.
Any chance to see it somehow published?

If he wants to post it here, I don't mind. Kind of curious how he managed to state machine all ~150kb of relevant code -- it's incredibly monotonous making those things. But I really don't want to see it end up on every emulator site ala Snes9X forks if at all possible. Really need the testers to spot new bugs and such, and I doubt PiCiJi and I can keep our releases in sync, given the massive amount of changes it must require.

It's certainly a lot of work to do just for a personal fork, as was the C# rewrite someone did a while back. I'm extremely impressed.

PiCiJi, don't suppose you'd mind looking into savestates with the current cothreaded method? You'd gain back that ~30% speed loss, and all your other optimizations would make it way faster than the official release ;)
Plus, I could integrate your code if you wanted, which would be awesome.

henke37 · Post by **henke37** » Sat Feb 21, 2009 10:38 pm

I doubt that he is skilled enough at asm to pull off my crazy idea, but he sure is free to try. He is most definitely mad enough since he did this already.