lol, he was quoting byuu.mudlord wrote:Byuu's license prohibits that.Baron_Samedi wrote:"Should I release a new version with just this fix, after we test it?"
bsnes v0.035 released
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
True, however there is lines in byuu's license that explicitly prohibit forks. Which means the code must be non public, or peer reviewed and then given to byuu for him to add the code to BSNES.I should check with this byuu person first, just to avoid any legal troubles ...
Thats how I see his license. Which I certainly think is fair. Its his emu, after all.
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
If Nintendo "borrowed" an emulator for the Wii, it was almost certainly SNES9x.Baron_Samedi wrote: i wonder if nintendo looked at your source code before programming there virtual console snes emulator
i dont have a wii
but are there fx or sa-1 games available for it ?
by disassemble wiis virtual console ......
just an idea
i mean not copy the code.... just look at it how big n emulates the games, may be this will bring new ideas.....
Of course, the fact that Nintendo has things like technical documentation and original dev kits makes things EVER SO SLIGHTLY easier for them.
I'm sure they were laughing their asses off watching emulator authors try to figure out the SPC700 module.
And yes, there are SA1 games. If nothing else, there's the recent Mario RPG release.
FitzRoy wrote:Did you test Mario Kart and see if it, by chance, fixed the map bug in that as well? I was actually going to PM you about that...
Yes, it seems to have. Left is the official release, right is with the fix. The black line at the bottom of the top half doesn't flicker on either version, as it did in v033 and below.
Not enough of a userbase to attempt at the moment. Probably because so few people can run the emulator fast enough. Doesn't sound impossible, I've been extraordinarily careful not to introduce "core randomness" stuff that would throw off netplay. Not one I'm personally interested in working on, but who knows in the future. I also don't know much about network programming. I wrote a proxy server once, but that was it.Could you please explain the situation surrounding that one a little better for me?
That sounds awfully bitter; hopefully I'm misreading you. By all means, you're welcome to add mouse/super scope support yourself. Getting upset isn't making me any more interested in adding them.And I hope that you don't really feel that the mouse/super scope is too hard and just forgot about them when writing the reply and only thinking of the extra chips.
-
- Rookie
- Posts: 11
- Joined: Tue Sep 25, 2007 1:34 am
- Location: Germany
my opinion is that netplay is not so important
(at least for me )
i think that it is better to concentrate on game compatibility
(emulate the special ships like fx, sa-1 etc and hardware)
even if its difficult but there was a time when people thought that
street fighter alpha will never be emulated on snes
and after some years it was possible
first with gfx pack now it works without one
and people thought that cps3 will never be decrypted
but again after some years its possible
(i hope i sound not too much like sybok from star trek )
i learned that there is nothing people cannot achieve
so i hope that all special chips and hardware will be emulated by bsnes in the future
in the near future....
(at least for me )
i think that it is better to concentrate on game compatibility
(emulate the special ships like fx, sa-1 etc and hardware)
even if its difficult but there was a time when people thought that
street fighter alpha will never be emulated on snes
and after some years it was possible
first with gfx pack now it works without one
and people thought that cps3 will never be decrypted
but again after some years its possible
(i hope i sound not too much like sybok from star trek )
i learned that there is nothing people cannot achieve
so i hope that all special chips and hardware will be emulated by bsnes in the future
in the near future....
Hey FitzRoy.
Could you add the following to the list of un-emulated devices
The Super-Gameboy is interesting because some games have extra/secret/enhanced featues. Some games even have real snes games built into them.
Could you add the following to the list of un-emulated devices
The Super-Gameboy is interesting because some games have extra/secret/enhanced featues. Some games even have real snes games built into them.
Code: Select all
Super GameBoy
http://www.gamersgraveyard.com/repository/snes/peripherals/supergameboy.html
Super GameBoy 2
http://www.gamersgraveyard.com/repository/snes/peripherals/supergameboy2.html
Satellaview (i believe only the BS-X is emulated, and its emulation is not complete)
TeeV Golf
http://www.gamersgraveyard.com/repository/snes/peripherals/teevgolf.html
Twin Tap
http://www.gamersgraveyard.com/repository/snes/peripherals/twintap.html
Super Famicom Modem
http://www.gamersgraveyard.com/repository/snes/peripherals/sfc_modem.html
Barcode Battler
http://www.gamersgraveyard.com/repository/snes/peripherals/barcodebattler.html
XBAND Modem
http://www.gamersgraveyard.com/repository/snes/peripherals/xband.html
-
- Trooper
- Posts: 394
- Joined: Mon Feb 20, 2006 3:11 am
- Location: Space
Unless you have a flying DeLorean that can travel 30 years into the future to get computers capable of running those special chip games at full speed... those probably won't be done anytime soon.Baron_Samedi wrote:i think that it is better to concentrate on game compatibility
(emulate the special ships like fx, sa-1 etc and hardware)
so i hope that all special chips and hardware will be emulated by bsnes in the future
in the near future....
Not because it's not possible, because it won't be fast AT ALL. Byuu has mentioned time and time again why he hasn't done this yet, because modern computers probably can't get full speed. It's like emulating a separate processor which brings a terrible amount of overhead to the mix.
So, don't hold your breath on that at all.
[url=http://www.eidolons-inn.net/tiki-index.php?page=Kega]Kega Fusion Supporter[/url] | [url=http://byuu.cinnamonpirate.com/]bsnes Supporter[/url] | [url=http://aamirm.hacking-cult.org/]Regen Supporter[/url]
-
- Rookie
- Posts: 11
- Joined: Tue Sep 25, 2007 1:34 am
- Location: Germany
hmmm these chips are over 15 years old
fx is "only" a risc with 10.5 mhz
and sa-1 is a wdc 65816 cpu
if i am right the wdc 65816 is still sold by wdc, so getting infos about it should be possible
a normal core2duo should be able to emulate them without probs
i remember in the past that people were saying that emulating an amiga
would be impossible because a pc is not fast enough.....
on mame there seems to be no prob emulating cpus which are more powerfull than the fx and sa-1 cpus
is there no way to include the code from zsnes/snes9x and
improve it later little by little ?
fx is "only" a risc with 10.5 mhz
and sa-1 is a wdc 65816 cpu
if i am right the wdc 65816 is still sold by wdc, so getting infos about it should be possible
a normal core2duo should be able to emulate them without probs
i remember in the past that people were saying that emulating an amiga
would be impossible because a pc is not fast enough.....
on mame there seems to be no prob emulating cpus which are more powerfull than the fx and sa-1 cpus
is there no way to include the code from zsnes/snes9x and
improve it later little by little ?
Last edited by Baron_Samedi on Mon Sep 08, 2008 7:39 pm, edited 2 times in total.
-
- Trooper
- Posts: 394
- Joined: Mon Feb 20, 2006 3:11 am
- Location: Space
Them being 15 years old is irreverent. It may take another 15 years before they can be emulated fully for all we know.
It's pointless to ask for it. Even if it was included, everyone would be bitching about not being able to play Super Mario RPG, since it'd be SO slow. Hate to disappoint you, but it'll probably remain that way for awhile. If you want to play these special chip games, then I suggest having a copy of ZSNES or Snes9x around for that purpose.
Seriously, how fast would the games go if support was added? Half a single frame per second?
If it was that simple, do you think support for those chips would have been added ages ago? The answer is in the lack of support itself. Face it, modern computers cannot emulate those chips at full speed. And no, a Core 2 Duo probably couldn't emulate those chips at full speed. Core 2 100 perhaps? Too damn much overhead involved.Baron_Samedi wrote:a normal core2duo should be able to emulate them without probs
This will NEVER happen.Baron_Samedi wrote:is there no way to include the code from zsnes/snes9x and
improve it later little by little ?
It's pointless to ask for it. Even if it was included, everyone would be bitching about not being able to play Super Mario RPG, since it'd be SO slow. Hate to disappoint you, but it'll probably remain that way for awhile. If you want to play these special chip games, then I suggest having a copy of ZSNES or Snes9x around for that purpose.
Seriously, how fast would the games go if support was added? Half a single frame per second?
[url=http://www.eidolons-inn.net/tiki-index.php?page=Kega]Kega Fusion Supporter[/url] | [url=http://byuu.cinnamonpirate.com/]bsnes Supporter[/url] | [url=http://aamirm.hacking-cult.org/]Regen Supporter[/url]
-
- Rookie
- Posts: 11
- Joined: Tue Sep 25, 2007 1:34 am
- Location: Germany
i didn't know that emulating them would require so much cpu power
its hard to believe that u need a 10 ghz to emulate an old 10mhz cpu with environment
i just see mame and there emulating a complete system which is more powerfull than the "old" snes chips are not a big problem today
i don't want to blame byuu for not including it
he (and the ones who helped him) did a great job and bsnes is the best snes emu today
its hard to believe that u need a 10 ghz to emulate an old 10mhz cpu with environment
i just see mame and there emulating a complete system which is more powerfull than the "old" snes chips are not a big problem today
i don't want to blame byuu for not including it
he (and the ones who helped him) did a great job and bsnes is the best snes emu today
Last edited by Baron_Samedi on Mon Sep 08, 2008 7:59 pm, edited 1 time in total.
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
You're totally the first guy who thought that. You should get a medal or something. Now we're gonna press the big green button labelled 'go fast' and it's all gonna rock whoopee
...
...
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
I'll append the main thread with some notes on mouse and light gun emulation, I suppose.
As for SuperFX and SA-1. Of course you can get the games playable at full speed on modern computers. ZSNES, Snes9X and SNESGT do it just fine.
To get them bus accurate, well ... you'd need a new approach. Not state machines, not threading. Something else that I don't know much about. Maybe time stamping or something. Please don't start another discussion on this here. It's been beaten into the ground already.
The big issue is, once again, parallelism. With the S-CPU and S-SMP, we are quite lucky. They share only a 4-byte address window. So whenever the S-CPU is ahead of the S-SMP, it doesn't really matter until it tries to access one of those four bytes. You can sync up the other processor then. Ignoring the V/Hblank signals, the S-CPU and S-PPU are the same, sharing a 6-bit address bus. The S-SMP and S-DSP are slow enough at 1MHz, and the S-DSP simple enough to only need one state machine, that it's not as big of an issue.
But with the S-CPU and SuperFX, they both have access to work RAM, the cart (which can also be RAM or MMIO) etc. So your 2-bit shared address bus becomes nearly the entire 24-bit address bus. In other words, whenever either chip accesses nearly any memory address, you're going to have to sync the chips. And memory accesses make up at least ~65% of all processor cycles.
And now you're talking about two 21MHz chips communicating with each other and having to sync constantly. It's not just me who found it impractical, I believe even _Demo_ made a similar comment about the overhead truly proper SA-1 support would entail.
No, with bsnes' current precision, and the model it uses, extending it for SuperFX and SA-1 support isn't going to work. Could I do it, syncing only between opcodes? Sure. Would it work for all known games? Probably. Would it be as accurate as the rest of the emulator? Not a chance. So what then, is the point? Just use an existing emulator for these games. Sure, I added incomplete DSP-3 and DSP-4, because it took me two hours and Nach said it was okay to use his code. SuperFX and SA-1 will take many months each.
Will I eventually implement this less accurate model anyway? Doubtful, but maybe.
As for using ZSNES / Snes9X' code. One, the licenses are incompatible; and two, they're designed entirely within the frame of their respective emulators. Our ROM mapping models will be completely different, interactions with interrupts will be different, etc etc. It'd actually be easier to write my own.
Why am I not doing so? I'm not particularly driven to. It's a seriously complex under-taking, and there really aren't that many good games on these two co-processors. Yes, I know, the half dozen games they have are arguably some of the best on the system, but they're still only a half dozen games. I'd rather focus improvements on things that affect the other 4,000 games.
The number one issue that determines speed is how much parallelization you have between components.
I know it's hard to understand as an end-user, you'll have to trust me on this one.
As for SuperFX and SA-1. Of course you can get the games playable at full speed on modern computers. ZSNES, Snes9X and SNESGT do it just fine.
To get them bus accurate, well ... you'd need a new approach. Not state machines, not threading. Something else that I don't know much about. Maybe time stamping or something. Please don't start another discussion on this here. It's been beaten into the ground already.
The big issue is, once again, parallelism. With the S-CPU and S-SMP, we are quite lucky. They share only a 4-byte address window. So whenever the S-CPU is ahead of the S-SMP, it doesn't really matter until it tries to access one of those four bytes. You can sync up the other processor then. Ignoring the V/Hblank signals, the S-CPU and S-PPU are the same, sharing a 6-bit address bus. The S-SMP and S-DSP are slow enough at 1MHz, and the S-DSP simple enough to only need one state machine, that it's not as big of an issue.
But with the S-CPU and SuperFX, they both have access to work RAM, the cart (which can also be RAM or MMIO) etc. So your 2-bit shared address bus becomes nearly the entire 24-bit address bus. In other words, whenever either chip accesses nearly any memory address, you're going to have to sync the chips. And memory accesses make up at least ~65% of all processor cycles.
And now you're talking about two 21MHz chips communicating with each other and having to sync constantly. It's not just me who found it impractical, I believe even _Demo_ made a similar comment about the overhead truly proper SA-1 support would entail.
No, with bsnes' current precision, and the model it uses, extending it for SuperFX and SA-1 support isn't going to work. Could I do it, syncing only between opcodes? Sure. Would it work for all known games? Probably. Would it be as accurate as the rest of the emulator? Not a chance. So what then, is the point? Just use an existing emulator for these games. Sure, I added incomplete DSP-3 and DSP-4, because it took me two hours and Nach said it was okay to use his code. SuperFX and SA-1 will take many months each.
Will I eventually implement this less accurate model anyway? Doubtful, but maybe.
As for using ZSNES / Snes9X' code. One, the licenses are incompatible; and two, they're designed entirely within the frame of their respective emulators. Our ROM mapping models will be completely different, interactions with interrupts will be different, etc etc. It'd actually be easier to write my own.
Why am I not doing so? I'm not particularly driven to. It's a seriously complex under-taking, and there really aren't that many good games on these two co-processors. Yes, I know, the half dozen games they have are arguably some of the best on the system, but they're still only a half dozen games. I'd rather focus improvements on things that affect the other 4,000 games.
Your biggest mistake is assuming that the emulated processor's clock speed has any relevance in determining host system requirements. It does, but when we're talking about 1-100MHz with today's systems, it doesn't really matter much.its hard to believe that u need a 10 ghz to emulate an old 10mhz cpu with environment
The number one issue that determines speed is how much parallelization you have between components.
I know it's hard to understand as an end-user, you'll have to trust me on this one.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
That's absurd. Every single SFX and SA-1 game is 1000 orders of magnitude better than all other SNES games combined. It's not even worth having SNES emulation without SFX or SA-1 support, as not a single plain SNES game is worthwhile in the slightest.byuu wrote:It's a seriously complex under-taking, and there really aren't that many good games on these two co-processors. Yes, I know, the half dozen games they have are arguably some of the best on the system, but they're still only a half dozen games. I'd rather focus improvements on things that affect the other 4,000 games.
Thanks for keeping your emulator worthless
Peace!
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
bsnes is kind of like MAME. Accurate and other thing much as possible. No hacks and no other bullshit. Going by the real hardware and other things that have been documents. If there anything that isn't documents then no telling how it run or work.
People need start reading what came with bsnes from now on without thinking asking byuu on requests.
==================
Known Limitations:
==================
S-CPU
- Multiply / divide register delays not implemented
- "Glitch" when reading joypad registers during auto polling not implemented
S-PPU
- Uses scanline-based renderer. This is very inaccurate, but few (if any)
games rely on mid-scanline writes to function correctly
- Does not support FirstSprite+Y priority
- OAM / CGRAM accesses during active display not supported correctly
- RTO flags are not calculated on frames that are skipped when frameskipping
is enabled. This provides a major speedup, however it will cause in issues
in games that test these flags, eg the SNES Test Program Electronics Test.
Turning frameskipping off will allow RTO flag calculation on every frame
Hardware Bugs
- S-CPU.r1 HDMA crashing bug not emulated
- S-CPU<>S-SMP communication bus conflicts not emulated
=====================
Unsupported Hardware:
=====================
SA-1
Coprocessor used in many popular games, including:
- Dragon Ball Z Hyper Dimension
- Kirby Super Star
- Kirby's Dreamland 3
- Marvelous
- SD Gundam G-NEXT
- Super Mario RPG
Super FX
Coprocessor used in many popular games, including:
- Doom
- Star Fox
- Star Fox 2 (unreleased beta)
- Super Mario World 2: Yoshi's Island
ST-011
SETA DSP used by Quick-move Shogi Match with Nidan Rank-holder Morita
ST-018
SETA RISC CPU used by Quick-move Shogi Match with Nidan Rank-holder Morita 2
Super Gameboy
Cartridge passthrough used for playing Gameboy games
========================
Unsupported Controllers:
========================
Mouse
Super Scope
Justifier
People need start reading what came with bsnes from now on without thinking asking byuu on requests.
==================
Known Limitations:
==================
S-CPU
- Multiply / divide register delays not implemented
- "Glitch" when reading joypad registers during auto polling not implemented
S-PPU
- Uses scanline-based renderer. This is very inaccurate, but few (if any)
games rely on mid-scanline writes to function correctly
- Does not support FirstSprite+Y priority
- OAM / CGRAM accesses during active display not supported correctly
- RTO flags are not calculated on frames that are skipped when frameskipping
is enabled. This provides a major speedup, however it will cause in issues
in games that test these flags, eg the SNES Test Program Electronics Test.
Turning frameskipping off will allow RTO flag calculation on every frame
Hardware Bugs
- S-CPU.r1 HDMA crashing bug not emulated
- S-CPU<>S-SMP communication bus conflicts not emulated
=====================
Unsupported Hardware:
=====================
SA-1
Coprocessor used in many popular games, including:
- Dragon Ball Z Hyper Dimension
- Kirby Super Star
- Kirby's Dreamland 3
- Marvelous
- SD Gundam G-NEXT
- Super Mario RPG
Super FX
Coprocessor used in many popular games, including:
- Doom
- Star Fox
- Star Fox 2 (unreleased beta)
- Super Mario World 2: Yoshi's Island
ST-011
SETA DSP used by Quick-move Shogi Match with Nidan Rank-holder Morita
ST-018
SETA RISC CPU used by Quick-move Shogi Match with Nidan Rank-holder Morita 2
Super Gameboy
Cartridge passthrough used for playing Gameboy games
========================
Unsupported Controllers:
========================
Mouse
Super Scope
Justifier
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT