mirror of https://github.com/bsnes-emu/bsnes.git
120 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
byuu
|
8226e243b8 |
Update to bsnes v025a release.
My apologies, I added code to display an alert when the Sufami Turbo BIOS was not present at the last minute before the recent release. What I failed to realize was that I added the alert to the same routine that loads save RAM files. Meaning that whenever one loads a game that has not yet created a .srm file, one will get a warning that the save RAM file does not exist. Oops. You'll never see the warning more than once, and it's harmless, but for those it annoys, and for people who haven't upgraded yet, I've posted bsnes v0.025a. This version changes absolutely nothing other than disabling the warning box in question. I'll be sure to get a proper, tested fix into the next release. Again, I apologize for any inconveniece this may have caused. [No archive available] |
|
|
byuu
|
9ab3fa6227 |
Update to bsnes v025r01? release.
I'll bet this will surprise you all, I already have a
private WIP for the v0.025 series up :P
Absolutely no emulation changes, just lots of major code changes I
held off on as I didn't want to break anything last minute.
- Polymorphism through pointers using compile-time flag is dead. It
took a ~10% speed hit, so it was never feasible to use anyway. This is
also a required step to encapsulating the entire emulator inside a
single class which can support multiple instances. r_cpu-> becomes
cpu. , r_smp-> becomes smp. , etc.
- Greatly cleaned up interface.h as much as possible for now. Right
now, bsnes takes a lot longer than it should to compile because every
single object includes every last header for all objects. In the
future, I want to move headers so that only objects that need others
include those headers. Will increase compile speed a good bit.
- Created chip/chip.h to start on the above.
- Finally renamed chip/c4 to chip/cx4. Class name also
changed from C4 to Cx4.
- Removed libsort, as it's not used (yet?). Was
needlessly slowing down compile time.
- Created src/doc. This will be a folder that contains source code
documentation, diagrams, maps, to-do lists, etc. Started things off by
creating a _very_ basic overview of bsnes as a whole.
Much more radical stuff to come. I don't anticipate making another
public release for quite a long time, so I should be able to go wild
here with restructuring things.
> I just checked out the new bsnes version 0.025, but I could not find
> any option in the config file to change the memory / mem via PRNG
> initialization byte, that we were talking about earlier to help get
> some old pd stuff working...
Oh, I'm sorry about that. Didn't get a chance to add it this time. I
need to work a PRNG with a consistent seed value into the core first.
Not sure how I want to do that.
For what it's worth, initializing RAM to 0x00 unfortunately did not
fix Sidmania's graphical issues as I had hoped. Given FitzRoy reports
the glitches occur on real hardware as well, I'm afraid there's not a
whole lot I can do about it. I will pay attention to it when working
on my cycle-based PPU in the future, though.
> On another note your emulator has inspired me to do my first
> translation for the snes "Albert Odyssey", and has been very useful
> for this purpose.
Neat! Be sure to check out bsnes v0.013 on RHDN for its debugger.
It's the only SNES emulator with VRAM breakpoints, as far as I know.
Also be sure to try out xkas for your cross assembler :D </shameless
self-promotion>
> Oct. 14 also happens to be the 10th anniversary of the first public
> release of ZSNES, interestingly enough.
o.O
Holy crap, why didn't I ever hear about this before? That's really,
really interesting ... of course, the difference is that bsnes was
started on 10-14, ZSNES was first released then but obviously started
much sooner. Still cool, though.
I wonder if anyone knows the exact date zsKnight started on ZSNES, or
Jeremy Koot on SNES9x. It would be really cool to have a history of
the SNES emulation scene. So many emulators most have never even heard
of ... RSRSNES, GrimSNES, TrepSNES, Moonlit Coalition's emulator (that
played one game, heh), Simkin's simulator thing ... heh, I wonder if
anyone here knows the name of the SNES emulator I tried (and failed)
making way before bsnes, back in 2001. Google doesn't even know of it
:)
[No archive available]
|
|
|
byuu
|
85fa3cc968 |
Update to bsnes v025 release.
bsnes is exactly three years old today. I've posted a new version which adds DSP-3 and DSP-4 special chip support. The DSP-3 is used by SD Gundam GX, and the DSP-4 is used by Top Gear 3000. Please note that the DSP-3 is not fully emulated, thusly SD Gundam GX is not fully playable. Also, due to lack of timing emulation with the DSP-4, the Top Gear 3000 track sometimes flickers in split screen mode. However, it is believed that Top Gear 3000 is fully playable.
I should also note that I have started on SuperFX emulation, as some will inevitably see said code in my source releases. What I have now is nothing more than a skeleton implementation, and absolutely nothing using it is playable yet. I am making absolutely no promises that I will ever be able to emulate this chip. It will take at least several months of work, and even then, the speed will probably be too slow to reach 60fps on any system, but ... I'm working on it. While I have no way to run tests on the actual SuperFX hardware, I will do the best I can to emulate the chip accurately. I will be emulating the caching and cycle delays as best I can, but the information I have on this chip is extremely limited, so don't expect miracles.
Lastly, as promised, I have released the special chips I have personally emulated to the public domain. See license.txt for more information if interested. I cannot release the special chips whose code I did not write to the public domain, but all of that is already available under the GPLv2 (from ZSNES) or the SNES9x license.
Changelog:
- Added DSP-3 support, thanks to John Weidman, Kris Bleakley, Lancer, z80 gaiden
- Added DSP-4 support, thanks to Dreamer Nom, John Weidman, Kris Bleakley, Nach, z80 gaiden
- Started on support for SuperFX, no games playable as chip emulation is less than 1% complete
- Unsupported special chips will now display an alert
- Missing stbios.bin file when loading Sufami Turbo cartridges will now display an alert
- Video settings now saved separately for windowed and fullscreen mode
- Advanced option video<.mode>.synchronize can be enabled for vsync, but will cause sound crackling
- Added menu option to toggle FPS counter
- Minor source code cleanup
|
|
|
byuu
|
d1fcddee9c |
Update to bsnes v024r01? release.
New WIP up.
This one merges the most recent DSP-3 / DSP-4 work. Not sure if it
fixes any bugs or not, but good to be up to date, right? Testing would
be appreciated.
I also cleaned up the cart stuff a bit. Nicer enums,
removed some unused variables and such.
Then I turned all of the special chip class object pointers into
actual objects. It was kind of stupid to dynamically create them all,
and was just wasting performance.
I also finished adding all of the SuperFX registers, and mapped them
all to the GSU interface range ($3000-$32ff). Fixed an oversight with
the mapping, and added a new PCB database entry to get the memory map
for Yoshi's Island perfect. If you want to hear something nice, try
loading the USA version in this WIP with sound + speed regulation
enabled.
Then I added a 'Show FPS' option to the misc menu. I also didn't
realize I was still embedding the SNES controller bitmap even though
it wasn't displayed anywhere, so for now that's been removed. Makes
the EXE and archive a bit smaller.
Lastly, I redid the bsnes section of my site to look a little more
polished. Getting ready for 10/14. I've always hated the way SNES
emulator authors always cherry picked most of their screenshots to
show off their special chip support (jealousy because I didn't have
any for a long time), so I decided I'd do the exact same thing myself
this time :P
Ripped off Overload yet again, this time I stole his screenshot
layout style. Sorry, Overload ... but imitation is the sincerest form
of flattery, right? :)
Also, note that all of the ?page=bsnes_* URIs have changed to
?page=bsnes/* ... so if you get redirected to the main page from a
bookmark or something, that's why.
Whew, busy day today ...
[No archive available]
|
|
|
byuu
|
9fd379613a |
Update to bsnes v024 release.
This is an interim release between some major changes to the video mode support, which may take a long time to complete. It also fixes a bug with CGRAM access timing, re-adds the Sufami Turbo load menu, and adds support for the ST-010 coprocessor, used by F1 Race of Champions. To load Sufami Turbo cartridges, stbios.bin must be placed inside a folder named bios in the bsnes folder. There is not currently a warning if this file is missing. |
|
|
byuu
|
aabf52d678 |
Update to bsnes v023r01? release.
Alright, I've posted the new WIP.
Changelog:
- CGRAM fix for WWF Super Wrestlemania
- Updated to blargg's snes_ntsc library to version 0.2.2
- Added ST and ST dual cart loading menu options (*)
- Redesigned the video mode configuration panel a bit --
let me know what you think (**)
(*) - You have to set path.bios to an -absolute- path, ./ is
currently broken and I need to fix that. So, set it to eg
"c:/path/to/bsnes/bios" where stbios.bin is inside that folder.
(**) - The video menu obviously doesn't do anything, it's
just there for design advice / suggestions for now.
You'll notice the icon is gone. This is because I built this version
with MinGW 4, and I'm not sure how to add the icon to MinGW apps.
You'll also notice it's ~6% faster on Core 2 processors as a result.
The 16% speedup was only when PGO was enabled. But I can't enable
that, because it causes bsnes to crash randomly. GCC gets too risky
with its optimizations and ends up generating bad code (the GCC manual
states as much, I'm not just trying to blame problems in my app on GCC
here.)
So, 6% is the best speedup we can do for now. Compare to v0.023
official if you like. You probably won't see the speedup on older
processors like the Pentium IV.
EDIT: it seems like that MinGW vsnprintf problem is based on DLL
files on the local computer. Probably the MS VisualC runtime files.
The WIP works fine on my home PC (WinXP Pro), but not on my work PC
(Win2k). I'm going to have to stick with Visual C++ builds until I am
able to completely remove all sprintf-style calls from the emulator.
If you get an error about memory at 0xffffffff which cannot be read,
you know why. Try building with Visual C++ if you have it, or maybe
there's some way to upgrade libc DLLs that the app is binding to.
Whatever DLL has vsnprintf is the one that needs to be updated, if at
all possible.
Here's what the video config screen looks like at the
moment.
[image]
I tried putting the text at the top, that way there won't be any odd
gaps between the text and combo box dropdown, due to different sized
fonts on different platforms.
[No archive available]
|
|
|
byuu
|
c9ca01fe20 |
Update to bsnes v023 release.
I've recently fixed a bug in bsnes that I feel is serious enough to warrant a new release, even though little else has changed.
I attempted to build this release with MinGW, but ran into problems with profiling and JMA support, so this release was built with Visual C++ once again.
Changelog:
- Fixed serious bug in S-SMP incw and decw instructions -- fixes sound bug in Emerald Dragon
- Added Nach's MinGW fixes -- can now be compiled with MinGW/GCC3 or MinGW/GCC4
- Fixed const char* cast warnings in GCC 4.2, thanks to [vEX] for the feedback
- Updated source to use latest libraries for libco, libui, etc.
- Added new advanced options to adjust aspect ratio correction
- Cleaned up source code a bit
|
|
|
byuu
|
becf122aaa |
Update to bsnes v022r04? release.
Ok, I've posted a new WIP with the Emerald Dragon bug
fix. This time, I'm not posting the WIP publically. My last request
not to link directly to the file elsewhere was ignored, and ended up
on at least two emulation news sites (I won't mention names.) I'm not
trying to be a jerk about it, I really can't spare that kind of
bandwidth.
If anyone has contributed any code or bug fixes, reported any
confirmed bugs, or is an emulator author I've spoken to in the past,
feel free to request a link to the WIP page from me in PM if desired.
Sorry to everyone else. I'll have the new version out
as soon as possible.
> As for the AR advanced option, I think option 2 looks perfect.
Done. I didn't add any sanity checks, so that people can have a
little fun with it. It's not going to be a GUI option, so only
advanced users can play with it anyway. Try setting a crazy aspect
like 3:1 and play a platform game. It's guaranteed to mess with your
mind.
I also added the ... stuff, but I did not add the pause support back
in yet. Not sure if that'll make the next release, because it requires
some changes to the main loop functions that have been missing for a
while now. I usually like to leave more of a beta testing window
before messing with that stuff.
> byuu, you may know this, but on the front page of your web site, the
> link to your Philosophical Ramblings page is
> "http://localhost/index.php?page=articles/philosophy".
Hahah, oops. No, I didn't notice that. I must have
copied the link from my browser instead of typing it manually.
It's a stupid article, anyway. Didn't come out like I planned. I was
also reading some comments by Miguel de Icaza (supporting patent
pacts) and Linus Torvalds (bashing the hell out of C++ programmers),
and came across an interesting comment that got me thinking. Basically
that people who have any kind of notability really shouldn't go around
talking about things outside their specific expertise, because it
makes them look foolish when people take them too seriously (and
people do) as those two comments by de Icaza and Torvalds did. Lucky
for me I really _don't_ have any kind of notability, but it's a good
principle to adhere to anyway. Stick to talking about what I know
best. That goes against my whole personality though, so I probably
won't change at all anyway.
[No archive available]
|
|
|
byuu
|
1e130d7872 |
Update to bsnes v022r03 release.
Double post!
I've uploaded a new WIP, which I'll make public (only to this forum,
please don't post about it anywhere else unless you mirror the file):
http://byuu.org/files/bsnes_v022_wip03.zip
This version adds all of Nach's MinGW fixes, updated libco, libui and
libfunctor, cleans up the code that detects if the main window has
focus or not (if not, ignore keyboard input), adds the new makefile
target win-mingw-lui, finally fixes all of the char* conversion
warnings with GCC 4.2.x (thanks [vEX]), and I'm sure there's more, but
I don't remember.
The ZIP includes a Visual C++ generated binary, but it also works
with MinGW GCC4. It won't work with MinGW GCC3 because that one lacks
a C99-compliant vsnprintf function. You can hack your way around that
by editing src/lib/libstring_sprintf.cpp if you really want to use
MinGW GCC3.
You may also need to change the CC / CPP variable names. I went with
the generic names mingw32-gcc and mingw32-g++, but the GCC4 binaries
have -sjlj or -dw2 appended to them. You'll also need to set
-I/path/to/directxheaders, or copy them all into
/path/to/mingw/include, since MinGW seems to ignore the include
environment variable.
And finally, a bit of good news. It appears that MinGW GCC4 builds
binaries that are ~6% faster than Visual C++. That means with PGO
enabled, they should be at least ~16% faster than v0.022 official. If
I can figure out how to hide the ugly terminal window in the
background, I'll start making official releases with MinGW GCC4 from
now on.
|
|
|
byuu
|
c57c733d7d |
Update to bsnes v022 release.
Today marks a milestone for bsnes, and possibly for SNES emulation as a whole. With this new release, bsnes' compatibility has now reached 100.0%, with zero game-specific hacks. With every last commercially released game tested by both FitzRoy and tetsuo55 for at least five minutes each, all known bugs have been resolved.
Now, needless to say, I am referring to the emulation of the base SNES unit. As many SNES cartridges contain additional coprocessors on their PCBs, there are still unplayable titles. So how can I claim compatibility of 100%? Because I don't consider special chips inside game cartridges as part of the base SNES hardware. I realize that many people enjoy these games, and I do actively attempt to emulate as many coprocessors as possible (six are supported thus far). However, coprocessors such as the SuperFX and SA-1 continue to pose very significant challenges.
So, after nearly three years of development, I've finally achieved my primary goal. But it wasn't a complete victory ... I've learned a lot over the years. Emulation accuracy is not black and white -- there are heavy costs to pay and forced tradeoffs to achieve it. I no longer believe there is only one absolute path for emulation, as I did in 2004.
So does this mean bsnes is now perfect? Of course not. There are many technical details that are not emulated correctly. This also does mean that there are no bugs, merely that there are no bugs that we are aware of. While absolute verification of 100% compatibility is obvioulsy impossible, even by actually beating every single game from start to finish, this very well should be the first time any SNES emulator could claim zero known bugs with all known games tested. I very much expect this announcement to entice many new users to begin actively searching for bugs, in an effort to discredit my above claim. My response? Go for it! I would very much appreciate any and all discovered bugs to be posted here, so that they can be verified and addressed.
One major thing that needs to be said, is that there consists of one major hack in all SNES emulators, including bsnes: the use of scanline-based PPU renderers. This necessitates global hacks in all emulators to minimize their inaccuracies. I was going to write up a very long post here, going into specifics, but I've decided an article would be a better place for that. I will hopefully be writing up this article in a few days to post here.
In the meantime, one very important issue does need to be addressed. This version fixes a bug in Uniracers 2-player mode, where the game writes to OAM during active display. Like other PPU global hacks, Uniracers required a special consession. But because this hack only affects one game, it can very fairly be seen as cheating. Suffice to say, bsnes does not contain a game-specific hack, and the change made to fix Uniracers affects all games, but I do still very much consider it to be a hack. The fix I have added is quite literally and honestly more accurate than the behavior of bsnes v0.021. Before, writes to OAM and CGRAM during active display went where a programmer would expect, which would cause bugs when ran on real hardware. Uniracers is the only game known to do this, and it is very dangerous to do so. The writes do go through, but not where one would expect. The access address basically changes as the screen is rendered. With a scanline-based PPU, it is not possible to emulate the individual
steppings of the PPU, as there is not enough precision. Further, the entire SNES emulation community has virtually no information on how active display OAM and CGRAM writes work. Now, as Uniracers is the only game known to do this, I had the choice of either intentionally remapping the writes to an arbitrary location, or change it to the address Uniracers expects. Neither would be more accurate than the other, as both are completely wrong from a haradware standpoint. So the decision was to either fix Uniracers and deal with some calling it a game-specific hack, or to leave it broken with absolutely no gain to accuracy. Rather than decide for myself, I asked those who have supported me over the past three years for their opinions. The decision was unanimous to fix Uniracers. You can read the discussion, along with a more technical explanation of the issue, here. I will be addressing this topic in much greater detail in the article I will be writing up shortly.
Changelog:
- Fixed buffer overflow that was manifesting as corrupted tiles in Lemmings 2
- OAM and CGRAM addresses are now invalidated during active display, however the algorithms for how this address invalidation occurs is currently still unknown, so reads/writes are mapped to static addresses for now
- Re-added cheat code editor.
- Windows only: keypresses when main emulation window is not active are ignored once again
|
|
|
byuu
|
e41aa25887 |
Update to bsnes v021r02? release.
I've posted a new private WIP. This one just adds the cheat code editor back in again. Feedback on how it works is appreciated. You'll notice it's a lot simpler than v0.019's cheat editor ... I was going for simplicity this time. Editing a code means deleting and re-adding it (or edit the text file directly). Yes, I realize it's damn annoying entering codes because the emulator detects your keypresses as controller presses (unless you're using a joypad). Sorry, I still need to add code to determine if the active window is the main emulator window or not for GTK+ before I can fix this on both ports. Hopefully I can get that in before v0.022, but no promises. Worst case, I'll add a dummy Window::active() function that always returns true for GTK+ if needed. The cheat editor works the exact same on Windows and Linux, so this should be the first release to allow Linux users to use it. Looking more at how useful bsnes is in its' current form ... I'm simply not going to be able to walk away from it. Fuck it, I'll just have to split the emulator and maintain two separate versions. It may cost me some time, but whatever. It'll be good practice in trying to streamline things to share as much code as possible. I'll keep them together in one version as long as possible, too (using #defines and such). If I do this, any suggestions on how to differentiate the two versions? Different names? Different acronyms after bsnes (eg bsnes/AE and bsnes/SE ...)? Different icons? > One important point imo is the potential for "code longetivity". > That is, I'd like the original, untouched code to continue to exist > (while permitting derivative works) many decades from now. No matter the license, that won't change. People can close derived works with PD, but it's their code that they added which becomes closed, not mine. It won't make my code cease to be. It's not like it all matters that much. Regardless of license, anyone is always free to get PD access to my code by asking. This is just me trying to get a public consensus on whether or not I should allow people to use my code without my permission, and to what extent I should allow it. I was hoping the votes would be less 'all over the board' like the Uniracers fix ... this vote isn't going very well. Sigh. It'd be annoying specifying licenses on everything. Maybe I'll just bundle the core components (cpu, smp, ppu, dsp, memory, chip sans c4 (I don't own the rights to that)) and stick them in a separate downloadable archive that's PD [or GPL w/permission exception]. That way, I'm giving away the stuff that's important and can help others the most, the emulation core. If someone can't be bothered to ask me for mine, then they can write their own GUI. Call the package something like 'libbsnes'. Meh. [No archive available] |
|
|
byuu
|
435f7d4371 |
Update to bsnes v021r01? release.
Alright, I've posted the new WIP.
This one's really important, so please test it
thoroughly! :D
I've ran it through my usual list of troublesome games, and
everything looks good, but it's possible I've overlooked something.
The new config file settings are:
ppu.hack.oam_address_invalidation
ppu.hack.cgram_address_invalidation
Set to true, OAM goes to 0x0218 (for Uniracers), CGRAM to 0x0000
(address is insignificant, we know of zero examples of this behavior,
so the address chosen does not matter for now). Set to false, the
writes are allowed and go where 'expected' (by programmers, not by
hardware).
There's a slight difference in that OAM access is invalid even during
hblank, whereas CGRAM is obviously not (that's how games draw those
gradient fades and such).
This WIP also has the Lemmings II fix.
---
Now, I know I said I wouldn't bring this up again, but meh. So,
assuming I decide to go full force at this PPU renderer ... I still
want to let bsnes live on in its' current form, even if that means
losing my userbase to a competitor :(
I'm planning for the next release to allow derivative works, in hopes
that someone will continue it. Does anyone have any objections to
that? Would it be better to use GPLv2/3 to ensure source availability
(even though I disagree with the notion of 'freedom through
restrictions' -- I liken it to becoming your enemies to defeat them),
or better to use PD to ensure the widest possible use of the code
(even if that means the source can be closed off to the public, and
the binary sold for profit -- which I also detest as immoral)? I
realize the latter means the value of all of my work will be lost, but
I never intended to profit from any of this anyway, so ...
If you prefer GPL, please specify either v2 only, v2+ or v3. I can
use v3 and grant ZSNES an exception to use it under v2, so their v2
only license won't be a problem.
Some examples:
ZSNES is GPLv2, which got them the source to Zsnexbox.
PocketNES is PD, which got the emulator used in commercial software
by Atlus, Hudson and Jaleco (though the assholes couldn't even be
bothered to send a thank you letter to the PocketNES devs).
EDIT: I can also stick with the current license, a no-derivative one,
and do my best to maintain bsnes' old PPU renderer, if you like. But I
won't lie ... the pace of development _will_ slow down a lot on the
older version (it shouldn't affect my new PPU development speed much)
if we go with this option.
Once again, I'll go with community opinion this time. I'm
personally not casting a vote for either.
[No archive available]
|
|
|
byuu
|
a1980fab09 |
Update to bsnes v021 release.
This is a maintainence release. I am mostly releasing this for the sake of the recently released Der Langrisser translation. Changelog: Windows port can once again map joypads through the Input Configuration panel Using enter or spacebar to assign a key should no longer instantly map those keys F11 now toggles fullscreen mode Esc now toggles menu on and off (use F11+Esc combined to hide UI completely) Fixed a bug in King of Dragons (J, U, E), KOFF was not cleared during S-DSP power(), thanks to FitzRoy for the report, and blargg for assistance fixing the bug Fixed serious crashing error with File->Load on Linux/amd64 port Hopefully fixed min/max undefined error on GCC 4.2.0, but I am unable to test to verify Fixed many cast const char* to char* warnings for GCC 4.2.0, but some probably remain, as again, I am unable to test as I lack GCC 4.2.0 Set XV_AUTO_COLORKEY to 1 for Video/Xv renderer. Should fix some video drivers where there was no output, especially after running mplayer, etc. Thanks to sinimas for the fix Added clear_video() to Video/Xv renderer. Green edges at the bottom and right sides of the video output are now gone, and unloading a ROM will clear video I have finally figured out how to poll the keyboard status in real-time through Xorg: the XQueryKeymap function. I will be rewriting the Linux key capture system to use this, instead of capturing window key up / down messages through GTK+. This will finally allow me to completely abstract the UI from the hardware video, audio and input interfaces: a necessary step toward Linux joypad support. |
|
|
byuu
|
ebb234ba5f |
Update to bsnes v020 01 release.
[No changelog available] |
|
|
byuu
|
2cc7fe30b4 |
Update to bsnes v020 release.
Five months and 43 WIP releases in the making, today I am releasing bsnes v0.020. I'd really like to express my thanks to blargg, for he has written a new S-DSP emulator that is an impressive 32 times more precise than all existing S-DSP emulators. It is now bus-accurate, and should produce bit-perfect sound output to that of a real SNES, excepting very minor, very extreme edge cases. Not only did he do this, he went out of his way to develop a special version exclusively for bsnes to ease licensing concerns and take advantage of bsnes' unique features, notably cothreads. I can't thank him enough. Unfortunately, bsnes has taken a ~10% speed hit over v0.019 by using this new S-DSP emulator, but I must stress the speed hit is entirely due to the way bsnes is implemented. blargg's standalone S-DSP emulator is very, very fast. Anyone is free to take a look at his S-DSP emulator, as he has released it as open source under the LGPL, by visiting his homepage, here.
Unfortunately, the new cross-platform UI is not entirely finished. Some sacrifices had to be made to support libui. Specifically, the following features are missing from v0.019, but will hopefully be added back in future releases:
- Fullscreen support
- Input Configuration panel cannot capture joypad input. Joypad support is still present, but it must be mapped manually through the Advanced panel or through editing bsnes.cfg by hand
- The Cheat Code Editor is missing, but cht files can still be used from bsnes v0.019, and created by hand
- Sufami Turbo support is not accessible from the UI
- The UI on Windows is slightly less polished due to compromises to allow the UI to be readable on Linux.
I am sorry for the rough edges listed above, but I wanted to get a new release out, as it has been over five months since the last release, and I really want the world to be able to experience blargg's new S-DSP emulator.
Changelog:
- Added blargg's new S-DSP emulator, runs at 1.024mhz. Many thanks to blargg for this, as this puts all portions of SNES emulation except for the S-PPU at bus-accuracy
- blargg's S-DSP core fixes bugs in both Koushien 2 (J) and Toy Story (U)
- Corrected all S-SMP cycle timings to be hardware accurate. Thanks to blargg for creating an amazing test ROM that tested every possible opcode
- Corrected S-CPU wai instruction timing, fixes Mortal Kombat II
- Reverted HDMA sync emulation once more to fix Breath of Fire II (G) and Secret of Mana (U)
- Completely rewrote user interface to use libui, which is a wrapper that allows the same code to produce the same UI on both Windows (through the Win32 API) and Linux (through the GTK+ API)
- Corrected $2100.d7 OAM reset behavior, thanks to research from anomie
- Massively revamped the Linux port, should compile with no warnings or errors now
- Added 64-bit support to libco, tested on FreeBSD/amd64, should work on Linux as well
- Revamped makefile with suggestions from Nach
- Improved Linux Xv renderer to use the far more common YUY2 format, which should work on most Xorg drivers, allowing hardware accelerated video scaling
- Completely rewrote config file system. bsnes.cfg is now saved to user's profile folder on both Windows and Linux, allowing multi-user support
- A lot more work has been done behind the scenes, including massive code cleanups and portability improvements
You may download the new version on the main bsnes page.
|
|
|
byuu
|
5c3c872b78 |
Update to bsnes v019r41? release.
New WIP up.
I've replaced the interface::input setup, since Visual C++ was having
problems with it. I wanted something that wasn't so seemingly directly
linked to SNESInterface, anyway. Now I have InputManager, which will
handle not only all of the joypad mappings, but the GUI shortcut keys
as well. Yes -- I finally have all the code in place to support user-
defined shortcut keys. See? Something good did come out of the rewrite
after all. Dynamic keyboard mapping works on Windows now, but there
probably won't be joypad capture support until v0.021.
Further, I have added SHGetFolderPath to the Windows port. libbase.h
sadly requires shell32.lib now. I haven't tested this on 9x, but I
don't believe bsnes has worked on 9x in a long, long time now. I've
also heard you can copy shfolder.dll or something to use it on 9x
anyway.
Anyway, the config file now saves in your 'Application Data' folder
on Windows, and in your local directory on Linux. There's no need to
worry about what happens when you update bsnes and don't delete the
file ... as I use a text-based config file, like ZSNES / PSR, no harm
will come of it. Old variables will be flushed out, new variables will
be added with default values upon first load of the new version.
Thanks again to Nach for the code and help with this.
Lastly, I've added a bsnes license page. So instead of
debating whether to look up four letter English words in Perens',
Stallman's or Webster's dictionary, you can just link to that page
instead :)
Again, the license applies to current and previous versions of bsnes.
If and when it forks, the fork will likely be licensed in a way that
others can take over the old version.
Opinions on how to fix contradictions / loopholes welcome, blanket
statements that it's totally flawed without describing why or how are
not. Thanks in advance.
[No archive available]
|
|
|
byuu
|
36bf915244 |
Update to bsnes v019r40 release.
Ok, here's a public WIP for everyone:
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip40.zip
Please ... if you link to this post or file elsewhere,
please mirror it.
Fixes since wip39:
- menu enter event captured, audio no longer hangs when
entering the menu.
- multiple click problems resolved for all menu items plus list box
controls. Behavior should now be the same on both Windows and Linux,
but further polish is definitely needed here.
- buttons to set values on input config and advanced
panels are now disabled when no item is selected.
Known problems:
- Windows/VC++ port is still complaining about that
interface::input.bind() thing. I believe it is a compiler problem. I
am not working around it, as I prefer a real fix. If anyone can help,
please see src/ui/lui/settings/ui_inputconfig.cpp, look for that line.
It is #if !defined(_MSC_VER) blocked at the moment. Until this is
resolved, you must restart before input settings take effect.
- Joypads cannot be auto polled on input config screen. You can set
the values manually on the advanced tab, they use the same values as
bsnes v019, IIRC.
- When pressing enter (or spacebar on Linux) on the input config
panel, the dialog pops up and closes right away assigning that key. I
have no easy way to fix this, since I can't poll the realtime status
of those keys on Linux to wait for them to clear before showing the
input capture window. It would really be immensely useful to be able
to do that.
- Linux with ati driver requires you to move the window one time to
make the image visible ... I have no idea why this is needed. nv and
nvidia drivers work fine. Use the gtk renderer if you don't like the
chroma blending that using YUY2 mode requires.
- Linux port does not focus properly to panel list when
opening config screen.
- Config file still saves to startup working directory, rather than
the user folder. Still planning to work on that.
- UI is still pretty ugly on Windows, but overall it's not too bad.
Looks beautiful on Linux, though ... maybe if I could find a way to
enable theme support for Windows. I tried making a .manifest file and
using mt, and setting WINVER + _WIN32_WINNT to 0x0500, none of those
did anything.
- Cheat code editor has not been reimplemented yet. Really the last
major thing holding back a new release, but the above are pretty
important, too.
Let me know if anything else major pops up.
> Plus it prevents a smart user/admin from making their program
> directory read-only.
Once again, blargg has the most convincing argument :)
Wouldn't want that config file on a read-only medium,
eg CD-ROM.
I was wanting to implement this on Windows anyway, but
this makes it something I simply have to do.
[No archive available]
|
|
|
byuu
|
045a0f7e79 |
Update to bsnes v019r24? release.
New WIP. This one adds a GDI renderer for windows. If anyone wants to test it, edit bsnes.cfg and set system.video to "gdi". It will be very slow, obviously. It's just there for the hell of it, as another fallback I guess. I'd be interested if it didn't work for someone. I had to add the code to libui to support pixel buffer images, so now I can add things like the controller art into the new lui port, and it'll work on Windows and Linux. The best part is that I can make these image buffers anywhere, so things like PPU VRAM / OAM / CGRAM viewers in the debugger will now not only be possible, but trivial, to add in the future. Refined libui a lot more, but I did not merge that into this bsnes WIP, because it would break the source pretty bad. Still working on the API, too, so I'll probably hold off a bit longer. After I get the new libui merged in, I can start working on that configuration settings window. That window is the only thing holding up a new official release. I'm trying to figure out how the hell you enable WinXP themes now. I tried making a manifest file, even attaching the manifest to the EXE directly with the mt tool, but it's still drawing the controls using the old win32 compatibility mode. > I can see that he hesitates to add "MAXI" codes and has no multiple > codes for any game, despite how prevalent I've found them to be. You have cartridges where it's the exact same game (eg bit-for-bit identical ROM dumps), with the only difference being the PCB codes? Care to cite an example? The last two digits may change for revisions of the same game, obviously. That complicates things, but there's no harm in just picking one in that case. If the game didn't work with that PCB, it wouldn't have been released with it, so ... [No archive available] |
|
|
byuu
|
a209e6ffbe |
Update to bsnes v019r23 release.
Ok, this is a very important WIP release. Note that
this file is rather large, please mirror it if you must link to it
elsewhere.
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip23.zip
Included are two executables:
bsnes_adsp.exe - This version uses anomie's S-DSP
emulator, clocked at 32khz
bsnes_bdsp.exe - This version uses blargg's S-DSP
emulator, clocked at 1.024mhz
Please note that blargg's code is experimental and in-progress. That
said, I have been unable to find any errors with it so far. I hope I
haven't missed anything blargg wanted me to do before release.
Everyone, please give your thanks to blargg for creating this emulator
and allowing me to use his code :)
This day marks an important milestone, at least in bsnes, possibly in
the SNES emulation scene: the addition of a subsample-accurate S-DSP
emulator brings us one major step closer to the most faithful SNES
emulation that will ever be possible. Excepting bugs, this now gives
us bus-accurate S-CPU, S-SMP and S-DSP cores. It is not possible (nor
desirable) in software to get more precise than bus-level accesses.
The only core component remaining using an older, less faithful
approach is the S-PPU[1/2], and is not so coincidentally the source of
the only remaining bugs in bsnes. This will very likely be the biggest
leap forward in accuracy that will ever be seen for S-DSP emulation
from this date on.
The old win32 interface is now completely broken, so I am forced to
distribute using lui. As such, I've fixed the NTSC/PAL mode switches,
and added software video filter selection to the UI. Any configuration
changes that are not in the menu will have to be done via the config
file for the time being. I have also added the log audio data option
back to the misc menu. If you are not able to get 60fps in bsnes, or
would like to analyze the audio output between adsp and bdsp in
another program, you can use this option. Also, I'm aware of the lui-
specific issues, such as audio repeating when entering menus. lui is
still a work in progress.
Please test all of the games you can, and look for subtle audio
differences and the like. Bugs, improvements, whatever, would be very
useful to know. Please keep in mind that every commercial game ever
released was tested by both FitzRoy and tetsuo55, and there are
currently zero known problems with anomie's S-DSP emulator. Also note
that blargg's emulator will be slower, by nature of being more low-
level. I'll leave the decision on which core to enable by default to
you guys. Eventually, I'll have polymorphism fully functional, and
this will be a runtime-selectable option, and not require two separate
builds. But still, we unfortunately have to pick one to be the default
setting, which I hope does not offend anyone :(
I'm very appreciative and in debt to both anomie and blargg for their
help with S-DSP emulation. They have both done a very large service to
us all by creating these cores, so I thank both of them again for all
their hard work, and for allowing me to use their work in bsnes.
[No archive available]
|
|
|
byuu
|
3bf672dd97 |
Update to bsnes v019r19? release.
Ok, added blargg's changes. Played four levels, seems to be working
fine.
Posted a new WIP with this change. I also replaced libkeymap with a
new implementation of it, this one is designed to work with window key
messages, meaning we can finally have input configuration for GUI
events and such in the future, and Linux users will finally have input
support shortly.
Still not now, though. Input on Windows might be a little
sketchy, as well.
Just need to create an InputWM class for Linux.
[No archive available]
|
|
|
byuu
|
157ddf3e8f |
Update to bsnes v019r18? release.
Unfortunately, even an S/PDIF link from a real SNES isn't good enough,
as we can't verify/match its' CPU<>SMP communications. Our best bet
for verification is still the echo buffer.
I uploaded a new private WIP. This build is just demonstrating part of
the new UI. I'm trying to move back to putting everything commonly
used in the menubar, and moving all of the obscure/complex stuff out
into separate windows.
So far, lots of stuff is still missing, and the speed
setting (not enable) doesn't work.
How does the video mode configuration feel in this WIP compared to
v0.019's video settings panel? Easier, better, worse? I realize it
loses a bit of flexibility (eg with custom resolutions), but eh. I'd
rather go back to simplicity than feature bloat.
[No archive available]
|
|
|
byuu
|
ea23bf53ae |
Update to bsnes v019r17 release.
Ok, as promised, a public WIP build:
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip17.zip
As always, please be generous with this one. If you
must link to it elsewhere, please at least mirror it.
This should finally take care of the Toy Story bug. Yes, the audio
should halt roughly. The developers felt the need to use an evil trick
to force the audio to release faster than it normally should.
[No archive available]
|
|
|
byuu
|
d4598e1d01 |
Update to bsnes v019r13a release.
(Repost, since this got bumped by another page, but
updated message.)
Ok, this build has TRAC's and my idea for an S-DSP EDL fix applied.
EDL writes take effect immediately, and echo index bounds checking
occurs before FIR filtering and echo buffer writes. Please test this
with all of the really really picky/sensitive audio games you're aware
of, and see if you notice a difference between this and v0.019
official. Obviously, the sound differences should only exist in echo
effects, but luckily just about every game out there uses the echo
buffer. Note any differences you find either way, but I'm particularly
interested if things get worse, which will imply this fix is incorrect
(assuming the difference is verified in hardware as being correct in
v0.019 official), and we can try out the fix idea suggested by DMV27.
If no one finds any new audio bugs, we'll assume the fix was correct.
And no, there's no audio resampling in this. I think log audio data
might still work, if that'll make it easier. It might not, the win32
port is falling apart as I rewrite the cross-platform port.
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip13.zip
If anyone insists on posting about this on some other site (I'd
prefer not, as always), please at least mirror the file.
Update: audio logger works. I binary compared two files. The only
difference is that audio is being output four samples sooner now,
they're otherwise exact matches. Doesn't seem to be a bad thing by any
means.
[No archive available]
|
|
|
byuu
|
f9a8564af0 |
Update to bsnes v019r11 release.
Ok, I tried my best to add the audio synchronization
method (drop video frames) yet again, and once again failed
completely.
The below WIP is completely unusuable as it stands, so please don't
link to it, host it anywhere else, or even download it unless you can
help with the programming. I'm not going to be able to fix this myself
as I've tried countless times over the last two years in vain to fix
it.
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip11.zip
The included config file is important: it uses the DirectDraw
renderer instead of the D3D renderer, and has triple buffering
enabled.
The relevant code is in src/ui/video/ddraw.cpp and
src/ui/audio/dsound.cpp.
The most important code is below, but obviously any
tests would need the above WIP to build and try out.
void AudioDS::run(uint32 sample) {
uiVideo->tick();
data.buffer[data.buffer_pos++] = sample;
if(data.buffer_pos < latency)return;
uint32 ring_pos, pos, size;
do {
Sleep(1);
uiVideo->tick();
dsb_b->GetCurrentPosition(&pos, 0);
ring_pos = pos / data.ring_size;
} while(config::system.regulate_speed == true
&& ring_pos == data.ring_pos);
data.ring_pos = ring_pos;
void *output;
if(dsb_b->Lock(((data.ring_pos + 2) % 3) *
data.ring_size,
data.ring_size, &output, &size, 0, 0, 0) ==
DS_OK) {
//Audio::resample_hermite((uint32*)output,
data.buffer, latency, data.buffer_pos);
memcpy(output, data.buffer, data.ring_size);
dsb_b->Unlock(output, size, 0, 0);
}
data.buffer_pos = 0;
}
bool VideoDD::lock(uint16 *&data, uint &pitch)
{
if(video_buffer[video_active]->Lock(0, &ddsd,
DDLOCK_WAIT, 0) != DD_OK) return false;
video_valid[video_active] = false;
pitch = ddsd.lPitch;
data = (uint16*)ddsd.lpSurface;
return data;
}
void VideoDD::unlock() {
video_buffer[video_active]->Unlock(0);
}
void VideoDD::refresh() {
video_valid[video_active] = true;
video_active ^= 1;
tick();
}
void VideoDD::tick() {
if(video_valid[0] == false && video_valid[1] ==
false) return; //nothing to render
uint idx = video_valid[!video_active] == true ?
!video_active : video_active;
// if(video_valid[!video_active] == false)
return;
//uint idx = !video_active;
if(settings.triple_buffering == true) {
BOOL in_vblank;
lpdd7->GetVerticalBlankStatus(&in_vblank);
if(in_vblank == false) return;
//DWORD scanline;
// lpdd7->GetScanLine(&scanline);
// if(scanline < screen_height()) return;
//
lpdd7->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, 0);
}
HRESULT hr;
RECT rd, rs;
snes.get_video_info(&vi);
SetRect(&rs, 0, 0, vi.width, vi.height);
POINT p = { 0, 0 };
ClientToScreen(hwnd, &p);
GetClientRect(hwnd, &rd);
OffsetRect(&rd, p.x, p.y);
hr = screen->Blt(&rd, video_buffer[idx], &rs,
DDBLT_WAIT, 0);
video_valid[idx] = false;
if(hr == DDERR_SURFACELOST) {
screen->Restore();
video_buffer[0]->Restore();
video_buffer[1]->Restore();
}
}
What I'm basically doing is:
Audio keeps a ring buffer, and waits until the temporary buffer fills
up before forcing the emulator to sleep until the audio playback
catches up. Every time an audio sample is generated, and every time
the emulator sleeps for one millisecond, it gives Video a chance to
run.
Video has two backbuffers (a poor man's triple buffering, since that
doesn't work in windowed mode for DDraw). The PPU renders the entire
screen line by line, but it doesn't go from the PPU to the video card
until Video::video_lock is called. At this time, the current buffer
sets a flag to say it's contents are invalid, then it draws to the
frame, then sets a flag saying the current contents are again valid.
Finally, it calls the Video tick function to finish.
Every time the Video tick function is called from Audio (well over
32,000 times a second, so it should have good precision for detecting
vblank edges).
First, it will see if any frames have completely rendered. If not, it
will give up and return. Next, it will see if "triple buffering"
(really a vsync now, but emulates triple buffering at least) is
enabled. If so, it will return and do nothing if not in vblank.
Otherwise, or if triple buffering is disabled, it will continue. Next,
it finds the most recently rendered video frame that was valid and
blits that to the screen, and then sets that frame to invalid, so that
it is not rendered again (though it wouldn't hurt, it wastes CPU time
to blit the same image twice).
I've tried even adding in a 1ms interrupt timer to try and help with
any emulation code that might be freezing the emulator for over an
entire vblank (nothing in bsnes should be that intensive), and this
did not help either.
Basically, it's like I'm missing an unbelievable amount of frames,
like five out of six end up never getting drawn at all, so the video
is so choppy it's completely unusable. In reality, only one frame
should be dropped every 11 seconds. And when I enable the resampler,
that should change to only one frame every 66 seconds.
As a side note, I added a four-tap hermite resampler in. It sounds
good too, but I have no idea if it's better or worse than cubic.
[No archive available]
|
|
|
byuu
|
6d66b1136d |
Update to bsnes v019r09 release.
Alright, I'm in a semi-good mood.
http://byuu.cinnamonpirate.com/files/bsnes_v019_wip9.zip
This one uses the old win32 interface, and adds a new feature I'd
like people with sound troubles to try out. The config file now
contains "audio.latency". Don't mess with "audio.frequency", it won't
do you any good and gets overridden by the speed regulation settings
for now.
The audio.latency is a precise measurement of the millisecond delay
between sound being output by a real SNES and hearing that same sound
in bsnes. It takes into account the current playback frequency, as
well as the three-ring buffering system used by bsnes' audio system.
Formula: sample_latency = CURRENT_playback_frequency / 1000 *
config_file_latency * 3 (so 32khz + 75ms latency means each ring
buffer is 800 samples long). The new formula should make latency sound
better (it's consistent now) on fast / slow emulation speed throttling
settings as well.
I also cut out the fourth ring, since it was redundant. This should
make bsnes appear ~25% more responsive to sound with the same buffer
latency. As a result, I increased the latency to 75ms (it was at ~45
before).
I'd like to know what the lowest good value is that works on 95% of
sound cards, so I can use that. I'll let people with cheap sound cards
increase their latency setting manually (eventually it will be an
option in the GUI).
**NOTE:** this version does nothing for triple
buffering/vsync/whatever. You must _disable_ triple buffering to try
out the latency settings. This version is strictly to test audio
playback support.
I also added in my audio point resampler. Good god, it sounds
terrible. Regardless of the latency setting (either really high or
really low), the pitch difference between each audio ring is
_extremely_ noticeable. The code is there now in
src/ui/audio/dsound.cpp : AudioDS::run_videosync(), if anyone would
like to take a look. I'll hold my breath ;)
-----
Comparisons against ZSNES at this point are rather silly. Aside from
much more flexible timings, it probably has a nice audio resampler,
which I don't. If I faked CPU/SMP clock timings, I could get the SNES
spitting out 60 frames a second and 32khz audio a second. I'm not
going to do that, so I have to figure out how to resample the two. All
of my attempts at resampling video _and_ audio have both failed
miserably to date. I really only need one of those to work to get
smooth video+audio, but both would be nice so the user can decide
what's more important to them.
I don't care to add 2xSaI. I'm planning on redoing the filter stuff
soon to support 32-bit output for Xv, so if someone wants to add 2xSaI
support to bsnes after that, I'll add it in. Otherwise, HQ2x is
superior and Scale2x looks about the same, yet is way faster.
Regarding the IPS thing, exactly. As I said, IPS is a bad format. You
can't tell if you need to patch against a headered or unheadered ROM
unless you read the documentation that fuckheads like Cowering remove
in their ROM sets ("at least it's already prepatched"), or try
patching twice to see which one works. UPS will eliminate both of
these problems. Readmes will be included inside the patches, and UPS
will work regardless if your ROM has a header or not. It will also be
reversible. It'll be better in every regard over IPS, so I have no
reason to support IPS.
Lastly, I don't have any intention of working on fixing DeJap's
patch, regardless of where the problem is, as I have no way to run the
game on my copier. Maybe when and if the last two serious bugs
(Uniracers and Koushien 2) get fixed, I'll take a look at it then.
|
|
|
byuu
|
b01f18c34c |
Update to bsnes v019r01? release.
First screenshots of libui in bsnes:
[image] [image]
Same exact codebase. The current WIP is obviously missing any
semblance of a GUI, other than the menubar and a ROM file loader.
Lots of issues on both ports, of course. I'm aware of the audio
repeating issue on the Windows port and already know how to fix it
(had the same problem with the old Windows UI). Linux of course simply
has no audio or input.
I'm planning on moving the framerate counter to display inside the
image, rather than on the titlebar this time. That of course won't
happen anytime soon. I don't expect to be adding fullscreen support
back in anytime soon, either.
Once this port gets stable enough, I intend to remove the "ui/win"
and "ui/sdl" ports completely. After that, I'm going to have to start
seriously rewriting a lot of internal stuff.
I'm also planning to go with a simpler user interface this time
around. bsnes v0.019 had too many options and features. I think I may
scale back this time and make things a lot simpler. Move a lot of the
control settings back into the menubar, rather than in the custom
options panel (which will most likely still exist).
[No archive available]
|
|
|
byuu
|
1ebdb69516 |
Update to bsnes v019 release.
I´m releasing bsnes v0.019 today. This version contains Bandai Sufami Turbo support, new IRQ emulation code, and some various bugfixes. Unfortunately, this release is not entirely cause for celebration. Due to fatal errors in Microsoft´s "enterprise class" c++ compiler package, I am no longer able to compile bsnes with profile guided optimizations. I have tested v0.018 with and without these optimizations, and the difference is a 40% speedup when PGO is used, even more significant than I had previously believed. However, bsnes has now become too complex for Visual C++ to handle. Unfortunately, there is nothing I can do about this, except wait for Microsoft to fix their compiler. (Warning: this paragraph contains personal opinions, skip it if you can´t handle that) As if this wasn´t enough, I´m now doing my best to wean my dependence from Microsoft´s line of operating systems, as I´m particularly concerned about the black box nature of Vista and its´ DRM control mechanisms. This isn´t a road I wish to begin traveling down, and thusly have no interest in upgrading to future versions of Windows. Therefore, as of late, I´ve been writing a UI wrapper that will allow me to code applications that are truly platform independent. The biggest goal for this library is to design a GUI for bsnes that runs virtually identically on both Windows and Linux/BSD. This is mostly complete, however there were many tricks I used in bsnes using the win32 API that I simply cannot do with GTK+ on Linux/BSD, such as the memory editor window subclassing. I will be porting bsnes to use this new UI wrapper, and in turn this will lessen the attractiveness / functionality of the bsnes UI to a certain degree. Perhaps the most devastating news is that I am still contemplating the idea of designing a dot-based PPU renderer for bsnes. As if the loss of PGO wasn´t bad enough, this will likely eat away an unimaginable level of performance as well. I can only estimate the speed loss being between 100-500%. Yes, it will be that bad. And despite weeks of planning, I cannot think of a way to allow a scanline-based and dot-based renderer to coexist as selectable options, given their massive differences in implementation. And let´s not even joke about SA-1 or SuperFX support ... those processors are each four to eight times more powerful than the SNES´ main CPU. All of these speed losses will basically make bsnes mostly irrelevant as an alternative to ZSNES, SNES9x et al. Although I believe I really came close to a viable alternative with v0.018, I know that I cannot both create a mainstream emulator, as well as keep with my original goal to emulate the SNES as accurately as possible. The past few months have been very tough for me; trying to decide which of the above two goals to pursue. I´ve still not absolutely made up my mind. But for now, I´ve been sitting on a mostly untouched version of bsnes for the last few months, and have decided to release it to the public, profile guided optimizations be damned. I´m once again asking for help, if anyone can figure out why bsnes won´t compile with PGO support, please let me know. I´d very much like to get one last PGO build of bsnes released before starting on a dot-based PPU renderer. But given the usual response I get from these requests for help, I´d suggest no one getting their hopes up that bsnes will ever be as fast as it once was again. The new version can be downloaded at the usual place. I´m leaving v0.018 up, as it may very well be the last stable, fast version of bsnes ever released. |
|
|
byuu
|
add0f74387 |
Update to bsnes v018r10? release.
Ok, Sufami Turbo is finished. Now I just need to add back in
cheat/patch loading, and that should do for src/cart modifications for
a while.
Maybe I'll add split ROM support while I'm at it just for
fun.
There's now _some_ safety code regarding ST loading, but
it's not all there. Specifically, if a file fails to load, then you
won't get any errors, the game will just not work, obviously. I now
protect against loading oversized ROMs and SRAM files.
The database now lists each Sufami Turbo cart only once, and the cart
loading code handles matching up two ROMs from the database. It is
also now possible to play ST games with invalid checksums, so eg
translations/hacks of these games should now be possible, however
unlikely.
FF:MQ (E) is fixed now too, so we're back to
FAVOR_ACCURACY in WIP builds again.
A little more src/cart polishing and I'm going to start documenting
all that's known about IRQs, and try and figure out how they work once
and for all (hahah, yeah right -- I give it 2-3 weeks after fixing it
again before more problems are found).
[No archive available]
|
|
|
byuu
|
b20f70f333 |
Update to bsnes v018r09? release.
Ok, the new WIP is extremely fragile with ST stuff, but it should work
if you're careful.
It took a _lot_ of rewriting to get those damn dual carts
booting. Right now, everything but the SD Gundam games are in the
database. I need to think of a way of combining those. So, the only
other dualable game is SD Ultra Battle - Ultraman Densetsu + Seven
Densetsu. Otherwise, test with just one ST cartridge at a time.
Anyway, it's definitely a work in progress, so be gentle with it. You
need "stbios.bin" in bsnes.cfg::path.bios for it to work. It probably
won't even give you an error if it isn't there.
Suggestions for how to layout the file menu are welcome.
[No archive available]
|
|
|
byuu
|
9aebf7bc6b |
Update to bsnes v018r08? release.
Ok, the new WIP adds ppu.hack.obj_cache = [true/false], and renames
the scanline render pos to ppu.hack.scanline_render_position = [dec].
OBJ cache defaults to off now, as two bugs are better
than four.
Made SDP a bit more friendly to view now. I may port that style over
to my main website, too. Specifically the non fixed width part.
[No archive available]
|
|
|
byuu
|
a7bf219d5d |
Update to bsnes v018r07? release.
> Overall, I have a small list of possibles. Will wait until after
> R-Type to explore.
Damn :(
I don't think the R-Type III fix will correct anything else. But,
cross your fingers I guess. The new WIP fixes the aforementioned game.
My SNES tests seem to indicate that writing #$20 to $4200 when
VCOUNTER==VIRQ will trigger an IRQ, even after an IRQ has already
fired on said line. My tests today indicate that it will not trigger
an IRQ under the above circumstances when the I flag is set. I don't
know why, it's the only thing other than the final IRQ trigger test
that cares what the I flag is set to. I'm not happy with the fix, but
it's the only explanation I can come up with, and all IRQ sensitive
games are running, as well all IRQ tests are still passing. So for
now, it'll have to do.
I'm going to attempt to document all of SNES IRQs and see if I can
figure out a more simple method of emulating them, but I'm not
hopeful.
I also removed the "guessed" entries from my database. I've decided
not to add anything unless we definitively know its' PCB ID, or in the
case of ST games, if it doesn't have one.
Lastly, rewrote my SDP page on my site. It now uses XHTML 1.0 + pure
CSS2, so it should be a little easier on the eyes and a lot easier to
write documentation pages for.
[No archive available]
|
|
|
byuu
|
04118be59a |
Update to bsnes v018r04 release.
Ok, _please_ be courteous to my webhost and only download this WIP if
you're going to test it on a processor that hasn't been tested thus
far.
byuu.org/files/bsnes_v018_wip4.zip
byuu.org/files/bsnes_tests.zip
This has two separate builds. Neither have PGO, SSE, SSE2, ZIP or JMA
support. They are identical except for the FAVOR_ flag define and
title of the program.
FAVOR_ACCURACY [bsnes_accurate.exe]:
- Always tests OAM RTO flags even on skipped frames
- Tests NMI/IRQ trigger every clock cycle
FAVOR_SPEED [bsnes_fast.exe]:
- Only tests OAM RTO flags on rendered frames (always
with no frameskipping)
- Tests NMI/IRQ trigger using ranges
If you'd like to test, please run demo_mode3.smc on both versions of
bsnes, turn off speed regulation, and report the framerate both with a
frameskip of zero and a frameskip of nine (max), along with your
processor speed.
The other test ROMs are just to verify that IRQ behavior is still
reliable in both versions. A blue screen indicates passing, they all
pass on both versions. Don't expect test_* ROMs to pass on other
emulators, but demo_* ones should.
Example (my main PC):
AMD Athlon 3500+
Accurate:
- 121.5 fps w/o frameskipping
- 171 fps w/max frameskipping
Fast:
- 146.5 fps w/o frameskipping
- 271.5 fps w/max frameskipping
-----
As you can see, there are _major_ speed differences on my
A64. Personally, I'm all for accuracy, but I also want people to
actually be able to use this program in the interim. Perhaps in the
future when a low end computer is a current low-end Core 2 Duo, we can
remove all of the "speedhack" code. And in the meantime, the full 100%
precision is there for people who have the CPU power to afford it.
-----
If anyone wants to try and help, heh.
src/cpu/scpu/timing/irqtiming_accurate.cpp and
src/cpu/scpu/timing/irqtiming_fast.cpp are the two versions of the IRQ
testing code. If you see any ways to optimize either (preferrably the
former, obviously), I'd greatly appreciate it. Understand that both
the CPU counters (VCOUNTER, HCLOCK) and the IRQ timing positions
(VIRQPOS, HIRQPOS) can wrap not only the horizontal clock position
(1362->0), but the vertical position as well (261->0). And also that
they are "misaligned" by 10 clocks (which is really more of an
internal CPU IC delay thing, we aren't entirely sure why the
difference is there). You probably shouldn't mess with the code if you
don't understand the implications of this on eg range testing :/
|
|
|
byuu
|
f24d17859f |
Update to bsnes v018r01? release.
I've written a new scheduler for bsnes to take 100% full advantage of
cooperative multithreading. Now, bsnes only performs jumps directly
from one thread to another (CPU->SMP instead of CPU->main->SMP), and
even then only when absolutely needed (eg CPU is accessing SMP when
CPU is currently ahead of SMP).
This unfortunately makes bCPU and bSMP no longer compile. However, it
does yield some impressive speed gains. From 109fps to 125fps.
By comparison, bsnes v0.017 yielded 128fps with my test
ROM.
The speed gain though is dependant upon how utilized the CPU<>SMP
communication is, the difference in speed between v0.017 and my WIP
can be anywhere between 1% and 10%, with the WIP always being slower.
The better news is that this is still without IRQs fully optimized. I
don't know how easy it will be to optimize these, if it's even doable
at all... but if I can, that would yield another very important speed
increase, making the next release the fastest ever. Here's to hoping.
The bad news though is that cothreading's advantages are pretty much
maxed out completely now. Don't expect any future leaps in performance
from this. Still, overall... a 40% total speed increase and double the
processor synchronization precision was definitely worth the effort,
even for the potential loss of savestates.
The scheduler should also make sPPU much faster when and if that's
ever started upon, but that's still going to take a very significant
speed hit over bPPU.
One last benefit of the scheduler is that the new synchronization
method isn't limited to only two clocks. I can now easily add another
clock, eg for SFX/SA-1. Not that I'll be emulating either of those
within the next year or two, though. Just saying...
I might also make two schedulers, one for cothreaded cores and one
for non-cothreaded cores. One thing is for certain though, I won't be
writing schedulers for every combination of cothreaded<>non-cothreaded
cores (there's 4 of them, CPU, SMP, PPU and DSP). And this will also
rule out run-time polymorphism's compile-time option, so expect that
to change to a compile-time only setting, meaning possibly two
versions of bsnes in the future.
Now then, I also fixed up S-CPU emulation mode opcodes. Direct page
wrapping, stack wrapping with native mode opcodes and processor status
flag fixes. No games use emulation mode, but accuracy is always nice.
[No archive available]
|
|
|
byuu
|
35fd80bde7 |
Update to bsnes v018 release.
I began working on bsnes on October 14th, 2004. I am releasing bsnes v0.018 today to celebrate bsnes' two year anniversary. Please note that this release incurs a ~15% speed reduction since v0.017, due to IRQ and S-SMP timing improvements.
Changelog:
- Fixed many critical errors in IRQ timing, should be *very* close to real hardware now
- Corrected major CPU timing bug involving CPU I/O condition 4
- Corrected bug with generic HiROM / LoROM memory maps
- Corrected bug involving HDMA indirect channel termination [anomie]
- OAM address reset now occurs when screen display is enabled, per recent research
- Readded full DMA, HDMA and HDMA init bus sync timing
- Added preliminary emulation of S-SMP $00f0 TEST register (6 of 8 bits are supported)
- Readded emulation of known timing differences between CPU revisions 1 and 2
- Config file can now control scanline-based PPU render position. This will only be needed until a proper dot-based PPU renderer is added
- Removed core debugging hooks so that debugging console can remain in public releases, it now functions as a tracer and memory editor
- Config file paths once again work correctly even if missing trailing backslash
- Video configuration simplified, sorry in advance to those who enjoyed the profile mode used before
- Added new configuration screen to control some emulation settings
- Replaced bsnes program icon with a much nicer one [FitzRoy]
- Optimized memory speed detection algorithm
- Preliminary UPS soft-patching support (do not use this yet!)
- Decreased memory usage and optimized generic libraries used by bsnes (/src/lib)
- Now caching OAM by one line, somewhat similar to a real SNES. Fixes Winter Gold, but causes line rendering error in Mega lo Mania
- Lots more, as usual
The following games have been fixed since v0.017 by the above bugfixes:
- Battle Blaze (J, U)
- Circuit USA (J)
- F1 Grand Prix (J)
- Funaki Masakatsu no Hybrid Wrestler - Tougi Denshou (J)
- Jumbo Ozaki no Hole in One (J)
- Mahjongg Taikai II (J)
- RPG Tsukuru - Super Dante (J)
- Robocop Versus The Terminator (U, E)
- Sink or Swim (U, E)
- Street Racer (J)
- Touge Densetsu Saisoku Battle (J)
- Winter Olympics (U, E)
|
|
|
byuu
|
ccf1c00b58 |
Update to bsnes v017r16? release.
Ok, reverted the SPCRAM initialization pattern, which should fix Kamen Rider SD. Verified DMA timing steps, I had them right. Still need to verify HDMA/HDMA init, but they're almost definitely the same anyway. Also, I noticed the spc700.txt doc by anomie on romhacking.net was more recent than mine, and had info on $00f0 - TEST o_O So, went ahead and added emulation for 5 out of 8 of these bits. Notably, the CPU speed control bits and the RAM write enable bit. The other three aren't well understood enough to add support for them just yet. Now, the CPU speed control in the S-SMP means the SMP core is taking a significant speed hit to support this register. ~5% total speed hit, though I can probably get that number down a little with some more optimizations. I know the register is never used by any games, but you know how I am. I added support for it anyway. Note that the WIP doesn't like my inlining combination and is taking a much more significant speed hit with global optimizations turned on, so the WIP is ~13% slower than the last one. > On a side note, kernel streaming method works with event > notification per audio packet you feed into it, and that > notification receives full precision time slices even without > setting the timer resolution manually. At least, when I was using > kernel streaming in my NES emulator, it didn't need vsync to output > almost a smooth 60fps, while WaveOut mode outputs in bursts and > requires vsync to smooth out the frames. If you wouldn't mind turning that into a compatible derived Audio class, I'd love to add this as an option into bsnes :) It'll be drop-in and compile, so you don't have to worry about me not adding the code this time. No problem if you don't have the time / desire / patience to do this. Although, I wouldn't want to do this if it requires 3rd-party libraries / loading a special .sys driver into the kernel space / Windows DDK to compile / something else crazy like that. [No archive available] |
|
|
byuu
|
f4520d41ec |
Update to bsnes v017r06? release.
New WIP should fix: RPG Tsukuru, Circuit USA, Jumbo Ozaki no Hole in One (not a permanent fix, I'm not entirely happy with the HDMA timing, but at least the name entry screen works again for now), and Taz- Mania. The two games you said started flickering since v0.017.07 might be fixed now, but I'm not worried about these horizontal-line issues regardless of when they started occurring at the moment. The other ones you said would be fixed by setting HCLOCK=256 should be fixed as well, as this is the new default value. Super Mario Kart's line doesn't appear to flicker now, but I think it's because I'm technically running the emulation a little too fast again, due to the Ozaki fix. Another game you shouldn't expect to stay fixed, and again another game I'm not worried about remaining fixed. Koushien 2 and Mahjongg Taikai 2 are very likely still broken. Uniracers definitely is. These appear to be the only three serious known bugs remaining. [No archive available] |
|
|
byuu
|
e308cf4275 |
Update to bsnes v017 release.
- This version adds major accuracy improvements, countless bugfixes and DSP-1 support. At the time of this release, the only remaining known bug in bsnes is with Uniracers 2-player mode, with well over 300+ games tested.
Changelog:
- DSP-1 support added [Andreas Naive, byuu]
- Added cooperative multithreading library, written by myself
- Rewritten CPU core, now bus accurate
- Rewritten APU core, now bus accurate
- Added cartridge database
- Added several PCB mappers, thanks to research from Overload
- Added several games to database, fixing several mapping-related bugs
- Improved mirroring [Nach, grinvader, byuu]
- vscroll bug in hires, interlaced mode fixed. Fixes RPM racing
- RTO X=256 bug corrected. Fixes Super Conflict title screen [anomie]
- Fixed bug in NTSC filter with hires games
- Updated snes_ntsc to version 2.0.1 [blargg]
- Fixed bugs in HiROM / LoROM memory mapping. Fixes countless games
- Fixed major bugs in HDMA routine. Fixes ToP, Mortal Kombat and Genjuu Ryodan
- Added out-of-order execution to CPU, APU synchronization for major speedup with no accuracy loss
- IRQs are now delayed after H/DMA transfers. Fixes Wild Guns
- HDMA transfers now kill active DMA channels that are on the same channel. Fixes Bugs Bunny and World Class Rugby. Special thanks to zones for researching this
- CPU emulation mode accuracy was improved
- Cleaned up port-specific code to ease porting
- Created unified Makefile, used by all ports [Nach]
- Created GTK+ port of bsnes (although input is currently broken)
- WRAM is now initialized to 0x55, SRAM to 0xff. Fixes Power Drive, Death Brade and RPM Racing
- Fixed extreme NMI / IRQ edge case. Fixes Chou Aniki
- Adjusted PAL execution speed. Fixes Earthworm Jim 2 (E) sound effects
- Fixed auto joypad polling bug. Fixes La Wares
- Fixed H/DMA bug that was preventing saves from working in Secret of Evermore
- bsnes low loads d3dx9_*.dll dynamically at runtime, it is no longer required
- Added support for 239-line PAL mode rendering
- As usual, there have been much more changes I've forgotten about since the last release
- Two C4 bugs fixed. Mega Man X2 / X3 have no remaining known bugs [anomie, byuu]
|
|
|
byuu
|
192e53bb87 |
Update to bsnes v016r52 release.
bsnes now builds with no warnings on Linux:
http://byuu.cinnamonpirate.com/images/desktop082106.png
However, input is not working unless you build the non-
GTK+ port (see below for more info).
I'm planning on releasing next weekend. This will likely be the last
public WIP, unless something major is found before the weekend:
byuu.cinnamonpirate.com/files/bsnes_v016_wip52.zip <-
copy/paste link
> If you can actually get it going fast in an all-in-one window like
> that it'd be cool. I normally just punt and have the GUI separate
> from the emulator output (GTK or Qt for the UI, SDL for the output)
> but it'd be nice for my NEStopia port if I could make it "one piece"
> like the Win32 original
I can. Please take a look at my above sourcecode, and check your
private messages for another note. Specifically, src/ui/video/sdl.cpp
and src/ui/gtk/gtk_mainwindow.cpp. I am able to merge the SDL output
into the GTK+ window by setting the environment variable
"SDL_WINDOWID=%ld", GDK_WINDOW_XWINDOW(mydrawingbox->window).
One important thing to note is that you must not initialize SDL video
until the render window has been realized. Simply showing the window
is not enough. You need to also clear all pending events in GTK+ after
showing the window before calling SDL video init, or it will die.
You can do that with this code:
gtk_widget_show(mainwindow);
while(gtk_events_pending() == true) {
gtk_main_iteration_do(false);
}
However, one problem I am having is that by calling
gtk_main_iteration_do(), it steals all SDL input, and I'm not able to
poll any keypresses. This happens whether I embed the SDL video output
into the GTK+ window or not. The only way to get SDL input is to
ignore all GTK+ events, effectively freezing the window completely.
I don't suppose you'd mind sharing how you got SDL
input working with GTK+ with me?
|
|
|
byuu
|
0ed9edfcdb |
Update to bsnes v016r46 release.
wip46 up. Adds all kinds of things, please test.
First, no more d3dx9_27.dll requirement to run the application, but
screenshots still work if you have any d3dx9_nn.dll files.
I specifically want to know if any of the other versions (24, 30,
etc) cause the emulator to crash when use. I'm pretty sure the
function is backwards-compatible, but we should probably make sure
before I make the next release and start getting bugreports about
screenshots crashing the program.
Note: there is no error message for failed screen
captures, I'll add that in eventually.
Next, the video options finally enable/disable controls depending on
certain settings. Should make using the video options a little easier.
Next, to enable SDL audio on Windows and remove the win32 port's
wMain.hwnd reference, I now pass GetDesktopWindow() to DirectSound's
SetCooperativeLevel function, since no sound comes out if you pass a
null handle. This is because I don't know how to get the window handle
from SDL, and I prefer to keep port-specific code out of there if
possible.
Note: SDL is not a windows port, but it builds on
windows, and thus needs DirectSound to output audio on windows.
I'm hoping this doesn't cause audio problems for anyone else, but
honestly I have no idea what DSound uses the window handle with
DSSCL_PRIORITY for anyway.
The $2100 luminance stuff was improved by adding rounding support to
the double-to-int casts, so fades should appear a little smoother now
in games.
Possibly fixed a bug where RTO wasn't being calculated when
brightness=0 and the screen is enabled. Didn't see any improvements in
the three known bugged games.
[No archive available]
|
|
|
byuu
|
764fe1974a |
Update to bsnes v016r44 release.
[No changelog available] |
|
|
byuu
|
a55d640459 |
Update to bsnes v016r42 release.
Ok, one semi-large change if anyone wants to test.
byuu.cinnamonpirate.com/files/bsnes_v016_wip42.zip
This is built for maximum speed. No debugger, PGO enabled, favor
speed, no c++ EH (so no ZIP/JMA), and a new addition: links against
msvcrt instead of libcmt.
By using msvcrt and some evil linker hacks I was finally able to
build the SDL port again on Windows. So now I just need to focus on
cleaning that up so the next release will build on Linux out of the
box. Anyway, I tried it on the non-SDL port for the hell of it, and
noticed not only a 20% drop in EXE size, but a ~10-11% speedup as
well. Only problem is it requires msvcr80.dll, and I have no idea how
common that file is. So, that's what this wip is for. Does this
version work for you, and if it does, does it run faster? A direct FPS
comparison between v0.016 and v0.016.42 would be helpful if you're not
sure.
|
|
|
byuu
|
6010bffe5d |
Update to bsnes v016r38 release.
Ok, this WIP rewrites the input code and modifies the PAL clock speed.
Fairly major changes. Ideally, this will wipe out four bugs without
causing any new ones since wip37.
Bug fixes :
Earthworm Jim 2 (E) - adjusted PAL CPU clock speed.
Please test for *new* sound problems in PAL games
La Wares (J) + Galivan 2 (J) - no longer return 0 when
auto joypad is off for polling $4218-$421f
Super Conflict (J) - added anomie's new OAM RTO findings
to fix title screen
The input code was almost completely rewritten to simulate real
hardware more. As such, it's very possible there are new input bugs.
Ok, so then
byuu.cinnamonpirate.com/files/bsnes_v016_wip38.zip
Please only download if you intend to test games and report feedback.
This version is slower than normal, lacks ZIP+JMA loading, and has the
debugger enabled (that is only useful to me, it lacks a functional
user interface) which slows down emulation even more. eg you're better
off with v0.016 official if you just want to run games.
As always, please don't post this link anywhere else, or
I will be forced to remove the file to conserve bandwidth.
If anyone posts bugs that hasn't tested against wip37, can I please
have someone with wip37 verify/deny the bug presence in wip37 as well
as in 016 official? wip37 isn't on my website because I don't have a
lot of web space to spare.
Thank you to everyone in advance for helping.
|
|
|
byuu
|
e492268025 |
Update to bsnes v016r27a release.
Ok, I tried converting the switch/case table to a jump table for both
CPU+APU cores. Results? EXE is 70kb larger, compile time is 5-10%
slower, and speed is identical. Needless to say I reverted that change
back. I then tried narrowing down the cause of the PGO error. Found
out it was Dai Kaijuu Monogatari. If I don't run that, I can build
with PGO. Unfortunately, this is the ROM I use to stress optimize
color add/sub. So as a result, this game will run a little slowly now
(sort of like how Chrono Trigger's OPT title screen effects were
before). But, better one game than all, right?
byuu.org/files/bsnes_v016_wip27a.zip
Once again, please do not submit news about this to an emulation
site. The file will be removed if I notice anyone mentioning it
anywhere.
That will be 20-25% faster than wip27, but otherwise
everything is identical.
DSP1: there's either a bug in op02, op06, or in the getSr/getDr/setDr
functions. We have so far been unable to spot the error and correct
it. Help is always welcome, as always. Please consider DSP-1 support
as not being there at all. I doubt any games will work right with it
right now :(
This is how interlace works :
I call each frame a "field", meaning even or odd fields
on your television / monitor.
When interlace is off, I draw to the even fields every
time, so you don't notice anything.
However, when interlace is on, I alternate between which one I draw
to each field. So depending on your frameskip, this can cause serious
problems for interlace mode. I also only physically draw to "half" the
resolution each field, much like a real TV would. This makes 512x448
mode just as fast as 512x224 mode.
I can't think of an easy way to cheat the system with frameskipping.
Luckily, very very few games use interlace at all. Most use hires
512x224 and that's it.
|
|
|
byuu
|
a36c26c997 |
Update to bsnes v016r27 release.
Here's a WIP to try out, it's 20-40% slower than it
should be, due to PGO crashing the compiler*.
Please copy and paste link, and _do not_ post this on
emulation news sites or I will remove the file.
byuu.org/files/bsnes_v016_wip27.zip
Even though it's slower, could I get some people to try running
through a bunch of games and look for new bugs? Given I rewrote the
entire CPU+APU, it's possible some new bugs crept in.
* No release this weekend. Please be sure to thank
Microsoft personally for the delay.
rc /r /fobsnes.res bsnes.rc
cl /Febsnes.exe /nologo /O2 /GL /EHsc main.obj
libco.obj libstring.obj
libconfig.obj libbpf.obj reader.obj cart.obj
cheat.obj memory.obj bmemory.obj
cpu.obj scpu.obj bcpu.obj apu.obj sapu.obj
bapu.obj bdsp.obj ppu.obj bppu.ob
j snes.obj srtc.obj sdd1.obj c4.obj dsp1.obj
dsp2.obj obc1.obj adler32.obj co
mpress.obj crc32.obj deflate.obj gzio.obj
inffast.obj inflate.obj inftrees.obj
ioapi.obj trees.obj unzip.obj zip.obj zutil.obj
jma.obj jcrc32.obj lzmadec.obj
7zlzma.obj iiostrm.obj inbyte.obj lzma.obj
winout.obj bsnes.res kernel32.lib use
r32.lib gdi32.lib comdlg32.lib comctl32.lib
d3d9.lib d3dx9.lib ddraw.lib dsound
.lib dinput8.lib dxguid.lib /link
/PGD:bsnes.pgd /LTCG:PGOPTIMIZE
Merging bsnes!1.pgc
Generating code
\bsnes\src\apu\sapu\core\core.cpp(16) : fatal
error C1001: An internal er
ror has occurred in the compiler.
(compiler file
'f:\rtm\vctools\compiler\utc\src\P2\main.c[0x10CB9ABB:0x00000025]
', line 182)
To work around this problem, try simplifying or
changing the program near the l
ocations listed above.
Please choose the Technical Support command on
the Visual C++
Help menu, or open the Technical Support help
file for more information
LINK : fatal error LNK1000: Internal error
during IMAGE::BuildImage
What is on sapu\core\core.cpp(16) that's too complex
for Visual c++ to handle?
status.in_opcode = false;
Please, if anyone can simplify that for me, let me
know.
Seriously, though, if anyone can take a look at the source and fix
this compiler error I'd really appreciate it, and I'll get a release
out this weekend. I'm using Visual C++ 2005 Professional. Otherwise
I'll have to set it aside because I don't have time.
[No archive available]
|
|
|
byuu
|
a3945e5772 |
Update to bsnes v016 release.
- Added Direct3D renderer with options for disabling hardware filtering and scanlines
- Screenshots can now be captured in BMP, JPEG, or PNG format
- Added config file option to specify default ROM and SRAM paths
- Config file is always loaded from path to bsnes executable
- Added support for analog mode joypad input
- Up to 32 joypads can be used at once now
- Fixed bug regarding enabling interlace mid-frame
- Moved PPU rendering to V=240, from V=0
- Started on new debugger. So far only debug messages and memory editor added
- Added joypad axis resistance option for analog input mode
- Added config file option to set window style attributes
- Added color adjustment settings for brightness, contrast, gamma, and scanline intensity
- Added grayscale, sepia, and invert color settings
- Added NTSC filter by blargg, HQ2x filter by MaxSt, and Scale2x filter
- PPU now renders scanline 224
- Revampled about box
- Added Game Genie / PAR cheat code support + editor, saves codes to .cht files
- HDMA channels are no longer disabled when starting DMA, fixes Dracula X [DMV27]
- Fixes to OAM priority mode (not perfect), fixes Final Fantasy: Mystic Quest [DMV27]
- Fixed ENDX sound bug, fixes voices in Earthworm Jim 2 [DMV27]
- bsnes should now compile with MinGW [DMV27]
- Added DSP-2 support
- Added OBC-1 support
- Major rewrite of SNES address bus mirroring and MMIO handlers
- Many address mirroring corrections, fixes Dezaemon, etc
- Blocked invalid (H)DMA transfers, fixes Kirby's Super Funhouse
- Wrote Win32 API wrapper and ported all GUI code to use it, should help to create Linux GUI later on
- Revampled input system, should lead to customizable GUI shortcut keys later on
- Fixed numerous bugs with input registers. Fixes many games that previous had their intro cut off (Super Conflict, etc), and many that never accepted input (Super Double Dragon, etc)
- Moved auto joypad strobing from V=225 to V=227
- Killed OAM table caching and window range caching, as they were actually hindering speed
- Rewrote input configuration screen to show currently mapped keys
- Greatly enhanced configuration options for each video profile
- Modified fullscreen mode to exit to windowed mode when menu is activated, use F11 to toggle fullscreen mode
- Fixed bugs in txs, wai, brk, cop, and rti opcodes [DMV27]
- Fixed bug with emulation-mode IRQs [DMV27]
- Initializing DMA registers to $ff [DMV27]
- Memory writes now update CPU MDR register (open bus) [DMV27]
- Improved ROM header detection, fixes Chou Jikuu Yousai Macross [DMV27]
- Reading OAM no longer updates OAM latch
- Writing to OAM high table no longer updates OAM latch
- Writing CGRAM now updates CGRAM latch
- Improved pseudo-hires rendering [blargg]
- Much, much more
|
|
|
byuu
|
6b6233b3af |
Update to bsnes v015 rc3 release.
[No changelog available] |
|
|
byuu
|
9f63cb1b99 |
Update to bsnes v015 rc2 release.
[No changelog available] |
|
|
byuu
|
49c39e0e4d |
Update to bsnes v015 release.
- Added GZ / ZIP / JMA archive support [Nach, NSRT team]
- Fixed bug in APU ADDW/SUBW opcode flags, thanks to DMV27, anomymous for info
- Mosaic support is now (mostly) hardware accurate, thanks to TRAC for info
- Fixed a bug in SC tilemap clipping, fixes Seiken Densetsu 3
- Emulated pseudo-hires mode, uses a fairly poor color filter to simulate TV effect, the same one that SNES9x and Super Sleuth use
- Rewrote the ROM loading code to be more port-friendly, and improved header detection
- Added C4 emulation -- mostly correct. Only minor bugs remain, possibly not C4 related [Nach, byuu], also uses code from zsKnight, Overload, and anomie
- Fixed noise channel generation for DSP, fixes Dual Orb 2 opening. Thanks to DMV27 for info
- Fixed bug with DSP VxSRCN registers, fixes horrible sound corruption in Mortal Kombat 2/3
- Modified DSP KON register reading to act according to anomie's research, while still allowing Der Langrisser, etc. to play sounds correctly
- Fixed a bug in CPU BCD math, fixes numbers in SimEarth, thanks to DMV27 for info
- Rewrote the windows port from scratch
- -- Added triple buffering support (buggy)
- -- Added DirectInput (joypad) support, allows both keyboard and joypad to be mapped to the same SNES controller button. Only one controller supported for this release, will be improved shortly
- -- Added pause key (mapped to Pause/Break)
- -- bsnes no longer consumes CPU time when paused or when no ROM is loaded
- -- Updated DirectDraw to 7, and added video mode configuration options to configuration file
- -- Video modes can specify screen width+height, refresh rate, and render width+height
- -- Added CTRL+[1-0] hotkeys for swapping video modes
- -- Added +/- hotkeys for adjusting frameskipping rate
- -- Added adjustable speed regulation. There are five modes, all can be adjusted inside the configuration file. CTRL+[+/-] will adjust the speed mode.
- -- Added PPU options to toggle any BG / OAM layers with any priority, HDMA effects, and offset per tile effects
- -- Added option to accept invalid button combinations (up+down, left+right) to joypad config menu
- -- bsnes now properly clears the main window when unloading games
- [code] Made destructors for base classes virtual, so the correct destructors will be called now
|
|
|
byuu
|
7dec0b2a3c |
Update to bsnes v014 release.
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
I disabled the debugger and polymorphism, and enabled profile guided optimizations for this build, to maximize speed. The debugger and polymorphism can be re-enabled via uncommenting the respective #defines in src/base.h and recompiling, or bsnes v0.013 can be used. I may start releasing two separate builds in the future... not sure yet.
|
|
|
byuu
|
f288280ceb |
Update to bsnes v013r02 release.
[No changelog available] |
