mirror of https://github.com/bsnes-emu/bsnes.git
141 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
byuu
|
a15d15047c |
Update to bsnes v027r04? release.
Okay, I posted a new WIP. This one's source only again,
since the Windows port is still unchanged.
I went through and used std::min + std::max, rather than my own
#define, for the sole benefit of getting Nach's JMA code to compile
again (JMA includes a C++ standard header that doesn't like you
#defining min/max, apparently). I was kind of cheap with it though,
max(0, min(10, value)) -> max(0U, min(10U, value)), etc.
Geez, std::min/max can't even cast between uint16 and uint32. What a
joke, I'll have to write my own that takes advantage of type traits.
I also started killing off the "bheader.h" files. Since 90% of them
are just template classes, I figure I may as well stick them all in a
namespace and make something akin to boost / Loki. I'm calling this
one nall (I love making up all these names, lately). I also use gcc -I
to point to it, so you get #include <nall/array.hpp> instead of
#include "../../../lib/barray.h", much nicer.
Taking advantage of the new template library, I added any.hpp
(generic object container), traits.hpp (type traits) and static.hpp
(static assert, if), and with that, I made stdint.hpp, which is a C++
implementation of stdint.h. Since stdint.h is part of C99, it isn't
included with all compilers (eg Visual C++). By using sizeof() and
static_if, I was able to make my own compiler-independent version of
this file. Thus, the dependency on stdint.h was removed.
I'd be very interested in feedback on anything in nall/
(it's located in src/lib).
Specifically, could someone with a big-endian machine test any.hpp?
I'm worried that downcasting will reverse the order of data read back.
Example test app:
#include <stdio.h>
#include <nall/any.hpp>
int main() {
nall::any t = 0x01020304;
printf("0x%x\n",nall::any_cast<short>(t));
//should print 0x0304
return 0;
}
> Please byuu, can you extend the API, would you be so kind?
Of course, I want vai to be used for more than just SNES emulation.
Though I've yet to get anyone using any of my libraries before, so it
may be a fairly pointless endeavor.
It'll take me some time, though. I'm working on a lot
of other stuff first.
> Anyways, byuu, here's what I wrote of the OpenGL renderer so far, to
> prove its very much being worked on.
Really cool! My only concern is the use of Win32-specific code
(header, GetForegroundWindow(), HDC stuff, setting up the pixel format
stuff) ... no idea how this is going to compile on Linux :(
I don't know the Linux equivalents to all of the
Win32-specific stuff being done.
Nonetheless, please take your time. I'll check it out when you have
the Win version finished. Thanks a million for making this :D
> What about guys like me who just stick to Intel HDA.
Hah, I do the same. I'm not going to spend more on my
sound card than on my mainboard that comes _with_ onboard sound. HDA
sounds just fine to me :/
[No archive available]
|
|
|
byuu
|
f77aca7172 |
Update to bsnes v027r03? release.
I have a new WIP up. Again, this one has only source, as nothing has
changed on Windows since wip01.
This time, I've just cleaned up the OSS and OpenAL drivers. Nach will
probably want to kill me, since by cleaned up, I mean "removed lots of
not-so-helpful comments and safety checks", but I intend to add them
back. Before v028, I'd like to have vai init() functions return a
boolean success value, and have bsnes continue to fall back on lesser
drivers until there are none left, in which case it won't use one. But
it will keep the program from crashing.
Also, I tried some black magic on the OSS4 support. Because
soundcard.h is included in a different location than the OSS3 one, I
tried manually defining the new SNDCTL options and invoking ioctl
regardless of OSS version. This is supposed to be safe -- the ioctls
should just fail silently and it will behave just like OSS3. Let me
know if you have problems compiling or using the driver with OSS3,
especially on non-Linux boxen.
> Will you update the readme with recommendations for
which sound driver to use on which system?
I suppose I can do that. I was planning on writing up an article
about OSS4 and such, perhaps I can just link to that in the readme.
> I changed it to set_background_color(0, 255, 0) and sure enough I
had a green statusbar. The main window background color was still
black though. Assuming that set_background_color() is meant to be used
for the main UI this is very odd.
Okay, here's how this works. Inside the main window, there is a view
control, which is a gtk_drawing_area(). I draw the video to this. When
bsnes is in windowed mode, obviously this control fills the entire
window. And the view control draws a black background by default. But
when you go fullscreen, the view area centers itself on your screen
(or tries to, some issues in GTK+ size requests render it non-
perfect.) Now there's the problem that the window itself is exposed on
the sides. Therefore, I have to set the window background to black
here, otherwise it will show up gray, which is _very_ distracting in
fullscreen mode, to say the least.
Now, I only tell GTK+ to set the window to black. The reason I do
this is because just setting the formcontainer to black has no effect,
since containers do not draw a background. As for why that is causing
your statusbar to render black ... good lord, I have no idea at all
o.O
I don't know what to do to fix this, unfortunately ... but at least
we now know where the problem is so we can research it. Thank you very
much for tracking that down [vEX], I realize my request to have an
end-user look into that was unreasonable, but it's very much
appreciated.
> EDIT2: After some testing it doesn't appear that bsnes was guilty.
I can't reproduce the memory consumption, but it could be all the
recompiling bsnes that somehow ate all my memory.
bsnes does appear to have a tiny memory leak at the moment. It loses
about ~100k a minute on me. I'm not sure if it's specific to the Linux
port or not. This will certainly be a hard one to track down in such a
big program.
> I believe OpenAL is pretty smart in frequency handling.
Definitely. I don't really like complex APIs, but the buffering
system in OpenAL will actually come in handy. I failed with
DirectSound, but maybe with OpenAL I can manage to resample audio --
maybe even let OpenAL do the resampling for me by calculating the
frequency as a measure of "how many samples should have been created"
versus "how many actually were."
That would be awesome. Combine that with OpenGL triple buffering, and
SDL/libjsw joypad support, and wow ... I'll have something really,
really usable :)
[No archive available]
|
|
|
byuu
|
c32195cbd6 |
Update to bsnes v027r02? release.
Okay, here's the deal with sound.
wertigon's initial OpenAL driver was incomplete and produced no
audio, and _willow_'s had some Windows-specific bindings.
So, Nach took those, some OpenAL sample code, and some other
application's OpenAL code and produced a working driver for it. Then
Nach and I refined the driver -- I got rid of the crashing on exit and
frequency changing, and both of us wrote new sample() functions.
Nach's is vastly superior on CPU resources, so we'll probably go with
that one.
That code can be found here:
http://byuu.cinnamonpirate.com/temp/audio.openal.cpp
This code wouldn't be possible without the help from
wertigon, _willow_ _and_ Nach, so many thanks to everyone, and I'm
sorry I wasn't able to go directly with anyone's specific OpenAL
driver. Linux compatibility was a big concern here. You'll all be
getting full credit in the source and documentation for bsnes v0.028.
---
Now, as for the driver itself. It should work on Windows now with the
sample() and init() corrections, but maybe not. I don't have the means
at the moment to build a Windows binary with it, but maybe I can in
the future.
But anyway, I don't intend to compile in OpenAL/Win support by
default with bsnes, but rather leave it as an option for those who
compile it themselves. Why? Because Windows does not come with
alut.dll and OpenAL32.dll. I don't want to require another download to
use bsnes, and I don't want to package an extra 300kb of DLLs with it
either. Plus, it doesn't seem to be working too well for most people
anyway thus far.
Windows does come with DX9, and basically nobody has problems with
DirectSound. It's great, it has very low latency, and it seems to work
on everyone's sound cards, unlike the OpenAL stuff. So it's really not
needed for Windows.
---
However, on Linux, OpenAL has a lot of good points. Unlike with
Linux/OSS3, OpenAL backends to ALSA which supports software mixing.
Meaning audacious and bsnes can run at the same time. And OpenAL has
much lower latency than libao, as well as the ability to disable speed
throttling when necessary.
But! The OSS4 driver, with SND_DSP_COOKEDMODE,
absolutely _destroys_ even the OpenAL driver. In fact, it's even twice
as good as the DirectSound driver on Windows! No joke!
From http://wiki.freebsd.org/RyanBeasley/ioctlref :
> ... this ioctl is meant to give processes direct access to the
> hardware buffer, giving the application the most control possible
> (ex: minimizing latency by avoiding in-kernel processing).
With this, I get roughly ~15-20ms latency, at the very most, with
bsnes. It skips kernel processing entirely! It's hard to even describe
such a low latency. I've never heard Link's sword sound effect start
so quickly. It's really quite impressive. Remember when kode54 was
talking about ASIO or kmixer or whatever? That super low latency
kernel-level audio setup that bypasses the kernel and goes directly to
the sound card? This is it, but for Linux. It's that good.
But the problem, of course, is Linux' obsession with ALSA, even
though OSS4 is GPLv2 now (and not to mention portable). ALSA is, of
course, total garbage. Anyone who's programmed for it knows that.
It's very easy to install OSS4, download a DEB package, double click
it, hit install and reboot. But the problem is, many Linux distros try
their best to kill OSS now. Lots of apps are compiled by Linux distro
vendors to only support ALSA, so it does cause some problems, and you
have to reconfigure many apps to use OSS afterwards, so it's not a
very good solution to make bsnes default to the OSS driver.
Further, because ALSA is so terrible, it causes the OpenAL driver
(which is really just a wrapper to ALSA here) to suck, and it causes
lots of static in the sound. And ALSA's OSS emulation causes severe
video lag -- bizarre, but it has something to do with the blocking
mechanism in ALSA. Only installing OSS4 fixes this. For both drivers,
in fact.
So, because of ALSA's pathetically poor emulation of both OSS and
OpenAL, I can't default bsnes to either of these drivers. Therefore, I
have to leave the libao driver as the default, but I really recommend
the installation of OSS4 (if you haven't gotten that hint already) if
you really want the best audio possible, and don't mind losing a
couple of your favorite ALSA-only apps. If installing OSS4 is too much
of a plunge, then I still recommend experimenting with the OpenAL and
OSS (in that order) drivers under ALSA. If they work good, great. If
not, sorry, it isn't a problem with the bsnes drivers. You'll have to
stick with libao and it's terrible latency and forced blocking. Unless
someone else wants to write an ALSA driver. I have no intentions of
programming for yet another single-platform API, myself.
---
With all of that said, I have a new WIP up. I'll send the link to any
Linux users who want to test it, as well. Feel free to ask.
This WIP is source code _only_ (nothing changed on
Windows), and has both the new OpenAL and OSS drivers. Testing would
be greatly appreciated.
[No archive available]
|
|
|
byuu
|
161366df9b |
Update to bsnes v027r01? release.
I posted a new private WIP that adds the new statusbar. But much more
importantly, thanks to Nach, the Linux port now has an OSS driver.
It's current set as the default. You can get ao again by
setting system.audio to, yep, you guessed it, "ao".
Would some Linux users mind giving it a spin? For me, it appears to
be blocking and causing serious video lag (xv [XV_SYNC_TO_VBLANK=0] or
GTK+ video, 60hz monitor, speed regulation = normal). Not happening
for Nach ... it's quite possible the problem is just on my system.
The complete and utter lack of perceived latency lag though, makes
this sound a million times better than the ao driver.
[No archive available]
|
|
|
byuu
|
4c43e85141 |
Update to bsnes v027 release.
This version replaces libui with miu -- a new GUI wrapper library, and cleans up large portions of the source code.
Unfortunately, the GUI rewrite took far, far longer than I ever imagined. As a result, no work has gone into the core emulation for this version. But with the GUI rewrite out of the way, that should change in the near future. And thanks to the new UI library, I can now begin work on adding a cross-platform debugger to bsnes, at long last.
Changelog:
- Major source code cleanup (lib/, ui/miu/, ui/vai/)
- Cheat code editor was broken in v0.026, this is now fixed
- Cheat code file format simplified for human readability
- Makefile install target improvements [belegdol]
- libui replaced with miu GUI library
- Custom video / audio / input drivers replaced with vai HW library
- ppc and ppc64 libco targets added [Vas Crabb]
- x86 and x86-64 libco targets now work on OS X [Lucas Newman]
|
|
|
byuu
|
9da42c18c3 |
Update to bsnes v026r04? release.
Another WIP. Consider this one v0.027 RC1.
Bugs fixed:
- cheat code editor works once again -- cart/ was not loading or
saving the files, and memory/ was not reading from it. Yeah, it was
completely broken in v0.026
- miu/Win supports window.set_background_color(). The trick was to
capture WM_ERASEBKGND and use FillRect to draw the background myself.
- miu/Win menubar toggle in fullscreen mode works as expected now for
me. Testing would be appreciated. A total shot in the dark, I tried
using SWP_FRAMECHANGED when resizing the windows, and it worked. It
seems to be an issue due to having two windows that are both set to
use the same menu (I have a hidden window I use for resize-purposes
only, because AdjustWindowRect doesn't work right on multi-line menus,
but the resize window is never visible.) I'm not sure exactly why
SWP_FRAMECHANGED fixed the problem, or why it wasn't needed in libui,
but it works, so I'll take it.
- make install target uses "install" rather than cp+chmod, but
belegdol unfortunately removed his makefile patch, and I don't recall
where $(DESTDIR) and $(PREFIX) are supposed to go, so those aren't in
there yet ... belegdol, could you please repost that? You're of course
free to change my makefile with your packages as always in case it
gets missed before v027.
Bugs remaining:
- D3D renderer is still acting weird. If you start at 256x224 window
size, then the point video filter never works. If you resize to a
larger window and back to 256x224, the video image is linear filtered
no matter what. I tried to fix this tonight, but I had no luck. I'm
really not sure what's wrong, I don't think it's ever really worked
right. Should I fallback on the DDraw renderer for the next release?
It lacks the point filter mode (DDraw lacks an API to control mag
filtering), but that's it. Also, mudlord, PM me if I haven't given you
my WIP URL and you wanted to look at the latest stuff. I can never
remember who I gave the link to or not.
- system.video / audio / input are not checked, so you get the
compiled defaults only. All vai drivers have now been ported, however.
I changed the cheat code format. It is now:
code = status, "description" \r\n
Or for an example:
7e1234:56 = enabled, "Infinite Lives"
7e1235:67 = disabled, "Infinite Health"
A little easier to read. But maybe still not perfect. I'd really like
to unify the .cht file format with other SNES emu devs ... I don't
want to use a binary file format like ZSNES and SNES9x does.
I tried testing log audio data -- it seems to be working for me both
on Windows and Linux. FitzRoy, maybe the file isn't going to the
folder you are expecting? Or maybe I fixed it and didn't realize it?
Hmm ...
Anything else I'm forgetting before a new release? Anyone
see any new / show stopping bugs?
[No archive available]
|
|
|
byuu
|
d115c7f6aa |
Update to bsnes v026r03? release.
Another WIP. This one builds on Windows and Linux, and the binary has
the terminal window disabled.
Bugs fixed:
- Added WM_ENTERMENULOOP message. Fixes audio looping for
the 37th time since I started on bsnes.
- Esc toggles menu properly
- F11 fullscreen centers, but only to the screen, not to the window
(meaning when the menubar is visible, it isn't really centered) --
this is because GTK+ does not return the correct widget size after
calling gtk_window_fullscreen() for up to ~200ms after processing all
messages via gtk_main_iteration_do(), and thus I can't make a
window.get_size() function. I really hope
GetSystemMetrics(SM_CXSCREEN) and gdk_screen_width() only return the
width of the active monitor, and not both for multi-monitor setups
- Background of main window is black on Linux only. Only one
background brush per class for Windows. It may end up staying gray on
Windows for the next release ...
- miu/Win enable/disable works. Even for menu items now, so I can
disable features that aren't supported by certain drivers now.
Bugs remaining:
- bsnes/Win background in fullscreen mode is gray --
quite ugly
- D3D still blurring images even with perfect multiplier
- cheat code editor still doesn't load .cht files on ROM
load
New bugs:
- bsnes/Win menubar is ultrafucked in fullscreen mode if
you toggle it on and off with esc. I have _no_ idea what the hell is
up with that. Code to show and hide the menu is identical to
libui/bsnes v026. Not sure I can fix this one. Basically, when the
menu gets toggled back on, clicking it does nothing, and if you press
alt, it will pop up the menu, but it will be _below_ the visible
menubar, so you end up seeing two of them. And you can only access the
new menubar via keyboard. Weird stuff ... could use some help here.
Anyone ever seen or heard of anything like this before?
- I still need to work on that makefile cp+chmod ->
install thing for belegdol, I think ...
[No archive available]
|
|
|
byuu
|
2efce0fd83 |
Update to bsnes v026r02? release.
New WIP. Much, much closer to release quality. Linux port (probably)
won't compile at the moment due to minor changes to miu and vai. I
left the console enabled for this WIP.
Bugs fixed:
- Windows always appear at 0,0 instead of centered
- Input capture window doesn't actually read anything. I actually can
get this working now, I just don't like the hacky way I did it before.
- miu doesn't send Key events, so no F11 / esc shortcut
keys.
- miu/Win is still missing some event messages, so some controls may
appear unresponsive. miu/Linux should be complete.
- miu/Win may still send duplicate messages in some
cases, like that old log audio option bug was doing
- miu lacks an on_show event, so the config window can't
set focus to the listbox on show just yet
- bsnes will no longer crash when you try and load a GZ / ZIP / JMA
file with the support not built in (it obviously won't play the games
either) [Richard Bannister]
Bugs remaining:
- D3D still blurring image, haven't looked at it yet
- Cheat code list never populates when loading ROM, probably doesn't
save either (I probably removed that code when rewriting cart/ and
memory/ a while back)
- miu doesn't emit WM_ENTERMENULOOP, meaning audio cycles when going
into the menu. I wish there were a way to make it pre-emptive like
GTK+ without needing multiple threads ...
New bugs:
- Esc doesn't toggle menu yet
- F11 fullscreen doesn't center, and window background is gray. This
will be tricky, as I only have one RegisterClass() in miu, but you can
only have one HBRUSH per class. Hopefully there's a window message I
can hijack to add back window.set_background_color().
- miu/Win enable() / disable() doesn't work -- input
config dropdowns active, despite them not working yet
Other than that, any new bug reports would be appreciated. I hope to
have v027 out by Sunday, but I may not make it in time.
[No archive available]
|
|
|
byuu
|
f6732133e7 |
Update to bsnes v026r01? release.
Alright, it's been a full month now since the last private WIP.
I have Direct3D, DirectSound and DirectInput all working on the
Windows port now; and Xv, GTK+ Video, libao and XInput working on the
Linux port, so now's a good time for a beta.
Note that countless things are broken, still.
- D3D still blurring image, haven't looked at it yet
- Cheat code list never populates when loading ROM, probably doesn't
save either (I probably removed that code when rewriting cart/ and
memory/ a while back)
- Windows always appear at 0,0 instead of centered
- miu doesn't emit WM_ENTERMENULOOP, meaning audio cycles when going
into the menu. I wish there were a way to make it pre-emptive like
GTK+ without needing multiple threads ...
- Input capture window doesn't actually read anything. I actually can
get this working now, I just don't like the hacky way I did it before.
- miu doesn't send Key events, so no F11 / esc shortcut
keys.
- miu/Win is still missing some event messages, so some controls may
appear unresponsive. miu/Linux should be complete.
- miu/Win may still send duplicate messages in some
cases, like that old log audio option bug was doing
- miu lacks an on_show event, so the config window can't
set focus to the listbox on show just yet
Any bugs outside of this that seem serious, please tell
me about. Otherwise, I'm working on the rest still :/
[No archive available]
|
|
|
byuu
|
95547f4ff8 |
Update to bsnes v026 release.
- Major source code cleanup
- Completely rewrote memory mapper to support runtime MMCs
- Updated S-DD1 MMC to use new memory mapping interface
- Improved S-DD1 emulation, thanks to information from orwannon
- Added support for SameGame -- load via "Load Special -> Load BS-X Slotted Cart" menu option
- Completely rewrote cartridge loader to support BS-X, BS-X slotted carts and ST carts
- Created custom dialog windows for multicart loading
- Improved generic memory mapper, which eliminates the need for cart.db [Nach]
- Added BS-X slotted cart detection to generic memory mapper [Nach]
- Linux port will now ignore keypresses when window is inactive
- Linux port will use much less CPU power when idle
- Added detailed compilation instructions to Makefile for Linux port
- Added "make install" target and PNG program icon for Linux port
- Switched Windows compiler to MinGW/GCC4
- Windows executable is now packed with UPX to decrease filesize
- Removed .ufo, .gd7 and .078 ROM extensions; added .bs extension
- Added preliminary support for the BS-X base unit, BS-X base cartridge + MMC, and BS-X flash I/O
|
|
|
byuu
|
4f5bdfe347 |
Update to bsnes v025r12? release.
New WIP is up.
I fixed PSRAM size, it's now 512kbytes. SRAM was correct before at
32kbytes. I also now save these files to "bsxbios.psr" (PSRAM) and
"bsxbios.srm" (SRAM). I honestly don't know if the PSRAM is supposed
to be battery backed or not. If it's not, it'll be easy enough to
remove. I imagine it is, because that's where you'd store your games
on if you lacked a flash cart. Would be pretty lousy to have it wiped
every time you power cycle.
I also save the PSRAM+SRAM data only once, just as a real BS-X cart
would work, and it also makes the Ancient Tablets series work with no
file renaming needed. I may add an option later to save these files
separately per-game.
BS-X support overall is still pitiful. bs-x.txt doc says $03 has to
be set to mirror PSRAM, SNES9x thinks it needs to be clear. Neither
know whether it affects just $60-6f or also $70-77. bs-x.txt doesn't
say to mirror hi/lo on PSRAM based on $02 setting, but SNES9x seems to
try it. LoROM doesn't map well into 64k granularity banks. Still don't
emulate $0c/$0d flash i/o register enable. Base unit is still
completely unsupported, and it's apparently needed for some games. And
I have no intentions of including an internal database of times to
manually hack the clock (even while the system is running!) ala
SNESGT. I'm just going to map the BS-X base unit RTC to the PC clock.
Some stuff like Dragon Slayer Eiyuu Densetsu work fine under regular
mapping, yet don't work with BS-X mapping. No idea why. Still don't
hack-enable headers during load, so that has to be done manually still
(do this if the game doesn't show up in cart menu. Make a backup if
you care.)
Added SameGame support. Load it with "Load BS-X Slotted Cartridge"
(that's what it is, after all.) Unfortunately, I don't know what the
memory map is supposed to be, so the add-on cart doesn't appear to be
working. Or maybe I just can't figure out how to tell.
Nach or anyone else, would you mind sharing that info with me? The
code in SNES9x looks identical to what I have, but loading the FEoEZ
512kbyte cart doesn't seem to do anything. Well, at least the game
itself works under this menu option now.
Fixed config::path.save, and added realpath() for the Linux port, so
./ paths work too. Of course it won't be useful at all if you
"install" bsnes to /usr/bin, but if you keep it in its own folder,
it's helpful.
Fixed the SRAM mapping bug affecting Fire Emblem 776. Also optimized
the file loading stuff a little more, removing a couple redundant ROM
memcpy's. Still far from perfect.
If possible, please test this WIP a lot. I'd like to post
a new public release this weekend.
[No archive available]
|
|
|
byuu
|
49b0bed1a6 |
Update to bsnes v025r11? release.
New WIP up. Has a Windows binary this time. I completed the BSX cart MMIO registers. It definitely doesn't work too well. For one, I don't override the header bit in the emulator, so anyone testing will have to modify the bit as discussed first. It also doesn't work on my only other BS game, BS Dragon Quest. I don't know why, it throws a St. GIGA error (09). Maybe it needs base unit emulation ... who knows. There's probably bugs in the cart and flash reg support, too. > My notes on the subject tell me it's the year of download or'd with > other data. I haven't entirely figured out everything it's or'd with > though. Well, Lancer said the BIOS makes sure d15 of $ffd5,$ffd4 is not set. If it is, the game does not appear in the list of games you can start. I'm guessing certain (all?) games expired after a certain date. If that's true, then we're quite fortunate that only a header bit was set, rather than the entire cart erased. So then, most likely all of these games with $80 in $ffd5 appeared "blank", but were dumped and the games retrieved. Sigh, such a sad fate. Really makes you wonder why Nintendo hates their fanbase so much to go out of their way to destroy these games. [No archive available] |
|
|
byuu
|
1554170312 |
Update to bsnes v025r10? release.
Yeah, even if we still don't have the S-DD1 100% understood, we can at
least get all known software working properly. And now we at least
have all the registers understood, just the edge cases that need to be
tested. I'm honestly glad I was incorrect in that the original patch
worked on hardware. Given it will never be updated again, this means I
won't have to get bug reports from now unto infinity about it.
I posted a new binary WIP. If anyone wants to play through a few
levels of SFA2 or dungeons in SO and look for corrupted graphics, it'd
be appreciated. I'm sure it'll be fine, though. Oh, and the speedhit I
reported a few days ago was wrong. The old builds ran at the same
speed. Seems I have a ~6-8fps variance in that game per reboot.
New WIP also starts the BS-X mapping. You can map in a cart now, but
it immediately freezes because the flash I/O registers do not respond.
---
Also, I'd like to get serious about emulating the
SPC7110. But to do that, I need custom-made hardware.
I asked someone about this already, but I may as well throw it out
there publicly in case anyone else would like to help.
Here is the PCB for one of the SPC7110 games:
http://nsrt.edgeemu.com/INFO/chip-pix/SPC7110.JPG
What I would need is for the top two ICs to be desoldered, and socket
IC connectors to be placed on them instead. I would also obviously
need lots of compatible EEPROMs to connect to it (just two would
suffice, more would be better as it's quite possible I'd wear out the
write cycles with lots of intense testing, or bend up the pins like I
usually do when removing socket ICs).
I would also need software+hardware to actually flash the
EEPROMs, as I don't have anything like this presently.
More complex solutions, such as a ROM emulator with a parallel/USB
interface to the PC would be acceptable as well. So long as it's
something I can reprogram at my relatively low skill level.
One cart would suffice, but again, the more carts the better in case
of failure. And I'd also like to see about sending one to another
person who's been interested in the SPC7110 for a while. So, three or
four preferred.
I can supply the cartridges and money for time +
shipping. I'd prefer someone who _knows_ they can do this well try, so
that we don't ruin any unnecessary cartridges and so that the test
cartridges are as durable as possible. Especially since they most
likely won't be encased anymore.
So, any takers?
[No archive available]
|
|
|
byuu
|
ec137d6fb9 |
Update to bsnes v025r09? release.
I posted a new WIP last night. No binary this time,
sorry.
It redoes the memory mapping of the cartridge and moves it into the
cartridge class -- forking each slotted cart away from the base cart
memory.
This allows me to determine the proper sizes for each individual cart
again, so I can now map RPG Tsukuru II again correctly.
EDIT:
Ahahahahahah!! Finally! I figured out how the S-DD1
$4800 and $4801 registers work! :D
Original game transfer (should transfer
compressed->decompressed):
CC2418 LDA #$4000 A:00DA X:F458 Y:1C00 S:01FA DB:00 D:0000 P:01 e
CC241B PEA $00DB [0000DB] A:4000 X:F458 Y:1C00
S:01FA DB:00 D:0000 P:01 e
CC241E LDX #$E8ED A:4000 X:F458 Y:1C00 S:01F8
DB:00 D:0000 P:01 e
CC2421 LDY #$0800 A:4000 X:E8ED Y:1C00 S:01F8
DB:00 D:0000 P:81 e
CC2424 JSR $2470 [CC2470] A:4000 X:E8ED Y:0800
S:01F8 DB:00 D:0000 P:01 e
CC2470 STA $2116 [002116] A:4000 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:01 e
CC2473 SEP #$20 A:4000 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:01 e
;* enable $4800 *
CC2475 LDA #$01 A:4000 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC2477 STA $4800 [004800] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC247A LDA #$09 A:4001 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC247C STA $4300 [004300] A:4009 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC247F LDA #$18 A:4009 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC2481 STA $4301 [004301] A:4018 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2484 STX $4302 [004302] A:4018 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2487 LDA $03,S [0001F9] A:4018 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2489 STA $4304 [004304] A:40DB X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:40DB X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:40DB X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:4001 X:E8ED Y:0800 S:01F6 DB:00
D:0000 P:21 e
CC2495 PLA A:4001 X:E8ED Y:0800 S:01F5 DB:00
D:0000 P:21 e
CC2496 STA $420B [00420B] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:4001 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC249E RTS A:4001 X:E8ED Y:0800 S:01F6 DB:00
D:0000 P:01 e
Custom transfer (should transfer
decompressed->decompressed):
CC2428 LDA #$5008 A:00DB X:E8ED Y:0800 S:01FA DB:00 D:0000 P:01 e
CC242B PEA $00E9 [0000E9] A:5008 X:E8ED Y:0800
S:01FA DB:00 D:0000 P:01 e
CC242E LDX #$0400 A:5008 X:E8ED Y:0800 S:01F8
DB:00 D:0000 P:01 e
CC2431 LDY #$04E0 A:5008 X:0400 Y:0800 S:01F8
DB:00 D:0000 P:01 e
CC2434 JSR $244C [CC244C] A:5008 X:0400 Y:04E0
S:01F8 DB:00 D:0000 P:01 e
CC244C STA $2116 [002116] A:5008 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:01 e
CC244F SEP #$20 A:5008 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:01 e
;* disable $4800 *
CC2451 STZ $4800 [004800] A:5008 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
;* $43x0.d3 (fixed transfer flag) is irrelevent
to S-DD1 *
;* can be #$01 or #$09 here *
CC2454 LDA #$09 A:5008 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:21 e
CC2456 BRA $247C [CC247C] A:5009 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC247C STA $4300 [004300] A:5009 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC247F LDA #$18 A:5009 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:21 e
CC2481 STA $4301 [004301] A:5018 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2484 STX $4302 [004302] A:5018 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2487 LDA $03,S [0001F9] A:5018 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2489 STA $4304 [004304] A:50E9 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:50E9 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:50E9 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:5001 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:5001 X:0400 Y:04E0 S:01F6 DB:00
D:0000 P:21 e
CC2495 PLA A:5001 X:0400 Y:04E0 S:01F5 DB:00
D:0000 P:21 e
CC2496 STA $420B [00420B] A:5001 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:5001 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:5001 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:21 e
CC249E RTS A:5001 X:0400 Y:04E0 S:01F6 DB:00
D:0000 P:01 e
Original transfer right after custom transfer:
CC2438 LDA #$4000 A:00E9 X:0400 Y:04E0 S:01FA DB:00 D:0000 P:01 e
CC243B PEA $00DC [0000DC] A:4000 X:0400 Y:04E0
S:01FA DB:00 D:0000 P:01 e
CC243E LDX #$E0E8 A:4000 X:0400 Y:04E0 S:01F8
DB:00 D:0000 P:01 e
CC2441 LDY #$1080 A:4000 X:E0E8 Y:04E0 S:01F8
DB:00 D:0000 P:81 e
CC2444 JSR $2458 [CC2458] A:4000 X:E0E8 Y:1080
S:01F8 DB:00 D:0000 P:01 e
CC2458 STA $2181 [002181] A:4000 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:01 e
CC245B SEP #$20 A:4000 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:01 e
CC245D LDA #$7F A:4000 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC245F STA $2183 [002183] A:407F X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2462 LDA #$01 A:407F X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
;* $4800 enabled again *
CC2464 STA $4800 [004800] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2467 LDA #$08 A:4001 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC2469 STA $4300 [004300] A:4008 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC246C LDA #$80 A:4008 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC246E BRA $2481 [CC2481] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2481 STA $4301 [004301] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2484 STX $4302 [004302] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2487 LDA $03,S [0001F9] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2489 STA $4304 [004304] A:40DC X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:40DC X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:40DC X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:4001 X:E0E8 Y:1080 S:01F6 DB:00
D:0000 P:21 e
CC2495 PLA A:4001 X:E0E8 Y:1080 S:01F5 DB:00
D:0000 P:21 e
CC2496 STA $420B [00420B] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:4001 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC249E RTS A:4001 X:E0E8 Y:1080 S:01F6 DB:00
D:0000 P:01 e
I was completely wrong, and was thrown off by ZSNES' memory remapping
magic that worked due to an oversight with $43x0.d3, or the fixed
transfer flag. I never added a check for the fixed transfer flag
because it quite honestly made no sense. Why would the S-DD1 care
about that?
Turns out, it doesn't. What really matters is $4800.
The register everyone currently ignores completely.
I figured out what purpose it serves: it's a sticky
toggle, whereas $4801 is a loose toggle.
It works like this: in order for the S-DD1 to decompress a DMA
transfer, both $4800 and $4801 have to be set. Upon completion of the
transfer, $4801 is cleared. But $4800 is not.
If you look at the above logs, it becomes clear. And it's all
contained inside the S-DD1 code. It has nothing to do with $43x0.
Now, how can I verify this? orwannon made a flash cart for Star Ocean
and ran my old title screen patch on it. Sure enough, it did not try
and decompress the graphics data, despite the fixed transfer flag
being set. That tells us that the fixed transfer flag has nothing to
do with this.
What's interesting is that every single S-DD1 supporting emulator
works just fine with my title screen patch. Meaning that they've all
implemented these two registers wrong.
What was also interesting is that it's supposedly been confirmed that
the patched SO works on real hardware. That means the bug was in bsnes
after all. No excuses, I was flat out wrong. My sincere apologies.
I've added the above changes, and bsnes now works with the original
patch, and fails with my custom patch. This mimics the behavior of
real hardware.
Huge thanks to orwannon for the screenshot of my patch running on
real hardware. This fix wouldn't have been possible without that.
[No archive available]
|
|
|
byuu
|
aee683a475 |
Update to bsnes v025r08? release.
New WIP up.
I spent four hours completely rewriting everything but the generic
header parsing code in src/cart. I'm now happy with the code both in
src/memory and src/cart. Hoorah.
With the new load_cart() functionality, I made the "Load Special"
menu entries functional. For those of you stuck on Windows or without
WIP access, you can see how nice the load menus look on Linux below :)
http://byuu.cinnamonpirate.com/bsnes/images/ui_bsx.png
http://byuu.cinnamonpirate.com/bsnes/images/ui_st.png
There is one bug: because of the way I map the slotted carts into one
contigious chunk of ROM (and hence update the size accordingly), it
throws off the memory mirroring on some of the BS-X slotted cart games
(like RPG Tsukuru II). I need to work on that a bit. For now, you can
play it through the normal load cartridge menu option.
And of course, there's still that annoying Windows issue where the
main window steals focus after loading a ROM. Haven't looked into that
yet.
And I still need to rework the file extension stuff per previous
discussions. It'd be nice to have the BS-X / ST windows only show .bs
/ .st ROMs by default.
[No archive available]
|
|
|
byuu
|
cdbf07b642 |
Update to bsnes v025r07? release.
Ok, posted the new WIP with the LoROM map corrections. This one also modified the load special menu. They now bring up a new window that lets you select the base cart + slot cart(s). However, the menus do not work yet. There's also some odd issue that it loses focus when you select a ROM from the browse button, but only on Windows. Hitting load just hides the window. I also need to add code to automatically load / save the BIOS filenames where applicable. Also, forgot to mention last time, but I added a new config file option, cpu.wram_initial_value or something like that. It's purpose should be pretty obvious. [No archive available] |
|
|
byuu
|
8a857dada3 |
Update to bsnes v025r06? release.
Ok, new WIP up. Pretty much all of the credit goes to others, this
time.
Changelog:
- I forgot to set the region, so PAL games were running
as NTSC; this is fixed
- Added Nach's BS-X slotted flashcart detection (added
his Ys'3 SRAM detection earlier)
- Used BSC-1A7M-10 PCB mapper from Overload's documentation for the
generic BS-X slotted cart games; Derby Stallion '96, Sound Novel
Tsukuru and RPG Tsukuru II are all playable once again; hopefully the
rest of the slotted games work, too (sans the SA-1 game(s)). Please
test if you can
- Added krom's (and I suppose Nach's earlier submitted) MinGW32 icon
support; so FitzRoy's wonderful icon is there now on the EXE -- still
need to add it to the window titlebar (easy on Windows), and to Linux
in general, ugh
- Removed win-mingw4-lui target, simplifying Makefile. Use win-mingw-
lui now. Thanks again to krom's suggestion to just copy the MinGW4
-sjlj files, that worked great
- Some more cleanup work to src/cart. Still a lot to go
here.
Everything that was playable in the last release should now be
playable, excepting Yoshi's Island music. Please let me know if
anything is broken that wasn't before now.
As always, I'm really thankful to everyone for their contributions.
My program would be useless if not for all the help I've gotten from
everyone else.
---
Now then, I aim to support those BS-X slotted cart games as well. But
one thing I did not know until today was that you could actually
exchange those carts between games. That ruins the model I planned to
use for them (eg make romname.smc -> romname.bsf files).
Thinking about it -- I really need to completely redesign file
loading. BS-X and Sufami Turbo stuff really throws off the "Load ROM"
paradigm that is so popular amongst emulators.
I'm thinking ... remove the "Load Special" menu completely. Modify
the main ROM loading routine to parse what exactly is being loaded.
If it's a BS-X slotted cart, pop up a menu that lets one optionally
select to load an additional flash cart, or cancel the menu to load
nothing in the slot. This won't be hot-swappable in-game.
If it's a Sufami Turbo cart, assume Slot A for the cart. If this game
supports dual slotting*, pop up an additional menu to select the Slot
B game, which can also be left empty. (* perhaps popup the menu no
matter what, to more closely simulate that with real hardware, you
could stick incompatible games in both slots anyway?)
Same deal for Same Game, G-Next, and all that other crap,
if or whenever I end up supporting those.
I think it's best to keep the BIOS stuff in the config file, rather
than giving an optional popup menu to modify which BIOS to load. The
reason being that it will allow direct loading of BS-X games with no
need to ever show a popup menu.
Lastly, I will have to add a new Misc menu option to generate empty
BS-X flashcart files. Though it's really easy to make one, I imagine
end users might have trouble doing that.
Ideas or suggestions welcome.
[No archive available]
|
|
|
byuu
|
ab1975a6cb |
Update to bsnes v025r05? release.
I mentioned that it wasn't there. Exact reason was because I reloaded
Ubuntu and Windows, and I really hate installing Visual C++. It takes
forever. I posted a new WIP, and built it with MinGW4. Need to figure
out how to get the icon into the binary with MinGW.
Anyway, new stuff in the WIP:
- Much, much faster mirror() function; thanks to lots of help from
Nach (doesn't speed anything up, but might help with BS-X MMIO
registers)
- Removed cart.db and all database-related code, now that
Ys3 works
- Lots of code cleanups everywhere
- New help information for trying to run ./configure or
make by itself
- Cheap temporary MinGW fix for non-C99 vsnprintf
The BS-X slot games (Derby Stallion et al) won't work on this
release. Nach gave me the code to detect those, and I'll get that
mapper in eventually before the next release. Also, Yoshi's Island
won't play audio anymore most likely.
If anything else is broken, it's due to mapping. Please let me know
so I can fix it. If there are more than three broken games, that's
good -- please don't overwhelm me with a list of 500+ broken games in
the morning :)
EDIT: fixed the Windows issues I was having. The Realtek
HD Audio driver software is fucking stupid. You _have_ to unplug your
speakers, reconnect them, and then select line out (rather than the
option for speakers) to get audio. This is the _only_ way to get
audio. And apparently both regular Winamp (without visualization) and
Mozilla Firefox now need DEP turned off not to crash the fuck all over
themselves constantly. Wonderful.
EDIT2: forgot to set the region, so PAL games will run as though they
are NTSC. Most will probably give you an error splash screen. I'll fix
that.
[No archive available]
|
|
|
byuu
|
476a1c819a |
Update to bsnes v025r04? release.
New WIP up. This one's a bit better than last, but I
don't want bug reports yet. This one only maps generic LoROM and HiROM
games.
Took about four or five hours, but I reworked most of the new memory
mapper yet again. SRAM should be working now, and I managed to gain
back the speed lost by dropping the address masking and forcing Visual
C++ to inline (__forceinline). The masking was no good anyway, because
the ROM file loaded in is definitely not always a power of two, which
means I'd have to use modulus and holy fuck no I'm not adding a
division for every memory access.
The old memory mapper didn't have this either, as it stored a bunch
of pointers into memory chunks. The new one just stores one pointer
plus integer offsets into that pointer (a bit slower but cleaner and
necessary for abstraction), so it's really mostly the same thing.
Man, I was looking at my old generic LoROM / HiROM mapper, and the
difference from that and what I have now is astounding ... it would
seem I've certainly gotten better at programming since then.
/* new */
void sBus::map_generic() {
switch(cartridge.info.mapper) {
case Cartridge::LOROM: {
map(MapLinear, 0x00, 0x3f, 0x8000, 0xffff,
memory::rom);
map(MapLinear, 0x80, 0xbf, 0x8000, 0xffff,
memory::rom);
map(MapLinear, 0x40, 0x7f, 0x0000, 0xffff,
memory::rom);
map(MapLinear, 0xc0, 0xff, 0x0000, 0xffff,
memory::rom);
} break;
case Cartridge::HIROM: {
map(MapShadow, 0x00, 0x3f, 0x8000, 0xffff,
memory::rom);
map(MapShadow, 0x80, 0xbf, 0x8000, 0xffff,
memory::rom);
map(MapLinear, 0x40, 0x7f, 0x0000, 0xffff,
memory::rom);
map(MapLinear, 0xc0, 0xff, 0x0000, 0xffff,
memory::rom);
} break;
}
if(memory::sram.size() == 0) { return; }
map(MapLinear, 0x20, 0x3f, 0x6000, 0x7fff,
memory::sram);
map(MapLinear, 0xa0, 0xbf, 0x6000, 0x7fff,
memory::sram);
map(MapLinear, 0x70, 0x7f, 0x0000, 0x7fff,
memory::sram);
if(cartridge.info.mapper != Cartridge::LOROM) {
return; }
map(MapLinear, 0xf0, 0xff, 0x0000, 0x7fff,
memory::sram);
}
/* old */
void bMemBus::cart_map_generic(uint type) {
uint rom_size = cartridge.info.rom_size;
uint ram_size = cartridge.info.ram_size;
for(uint page = 0x0000; page <= 0xffff; page++)
{
if(memory_type(page << 8) !=
TYPE_CART)continue;
uint addr = page << 8;
uint bank = page >> 8;
//RAM mapping is incorrect in several games,
this is the most compatible
//layout I can create using only ROM header
information. Additional accuracy
//requires PCB identification.
//Unmapped region
//$[00-1f|80-9f]:[6000-7fff]
if((bank & 0x7f) >= 0x00 && (bank & 0x7f) <= 0x1f && (addr &
0xe000) == 0x6000) {
continue;
}
//HiROM RAM region
//$[20-3f|a0-bf]:[6000-7fff]
if((bank & 0x7f) >= 0x20 && (bank & 0x7f) <= 0x3f && (addr &
0xe000) == 0x6000) {
if(ram_size == 0)continue;
addr = ((bank & 0x7f) - 0x20) * 0x2000 + ((addr
& 0xffff) - 0x6000);
addr %= ram_size;
page_handle[page] = cartridge.ram + addr;
page_read [page] = &bMemBus::read_ram;
page_write [page] = &bMemBus::write_ram;
continue;
}
//LoROM RAM region
//$[70-7f|f0-ff]:[0000-7fff]
//Note: WRAM is remapped over
$[7e-7f]:[0000-ffff]
if((bank & 0x7f) >= 0x70 && (bank & 0x7f) <= 0x7f && (addr &
0x8000) == 0x0000) {
if(!(bank & 0x80) || type == Cartridge::LOROM)
{
//HiROM maps $[f0-ff]:[0000-7fff] to ROM
if(ram_size == 0)continue;
addr = ((bank & 0x7f) - 0x70) * 0x8000 + (addr
& 0x7fff);
addr %= ram_size;
page_handle[page] = cartridge.ram + addr;
page_read [page] = &bMemBus::read_ram;
page_write [page] = &bMemBus::write_ram;
continue;
}
}
//ROM region
switch(type) {
case Cartridge::LOROM: {
addr = (bank & 0x7f) * 0x8000 + (addr &
0x7fff);
addr = mirror(rom_size, addr);
} break;
case Cartridge::HIROM: {
addr = mirror(rom_size, addr);
} break;
}
page_handle[page] = cartridge.rom + addr;
page_read [page] = &bMemBus::read_rom;
page_write [page] = &bMemBus::write_rom;
}
}
Note that those two certainly aren't identical in function, and I'll
no doubt have some memory mapping bugs again (probably with Final
Fight, SFII and such), but it should only require minor changes to fix
that.
> byuu: is it possible there's supposed to be steam appearing there to
> create the illusion, but isn't?
That's a lot more likely, honestly. Hopefully someone
can make it to level 5, heh. I know I sure as hell can't.
[No archive available]
|
|
|
byuu
|
42d3f2a37f |
Update to bsnes v025r03? release.
New WIP up, and this one is _not_ for playing games on.
I replaced the memory mapper entirely with a new system that should
be infinitely easier to remap dynamically. This is a necessary step
for BS-X MMIO register emulation. It should also speed up S-DD1
emulation by eliminating the need for a special address conversion
routine to simulate its memory mapper.
However, the new bus memory mapper is anything but complete. Right
now, it only loads really, really basic LoROM games. Stick to Super
Mario World and Zelda 3.
Some good news is that it's ~1-2% faster with MinGW4, but the bad
news is that it's ~10% slower with Visual C++, and MS' compiler is
stupidly storing my 128kb array directly into the EXE, making the file
size bigger. And yet the ZIP of the whole thing is smaller! >_<
Bah. I think I can fine tune most of the performance lost back out of
Visual C++ with some forced inlining, and I'll make that WRAM array
allocate at runtime.
Surprised I was able to get any games playable in less than three
hours, replacing the entire memory mapping system like that. Lucky me.
> -O8 -mtune=prescott -ffloat-store -fforce-addr -finline-functions
> -fexpensive-optimizations -funroll-all-loops -ffast-math -fomit-
> frame-pointer
I didn't realize you could go above -O3 ... interesting. If you want,
try building with profile guided optimizations for another ~15% speed
boost. It's pretty unstable like that, though. Maybe you'll have
better luck than me.
The warning message is in src/cart/cart_file.cpp at the
top.
[No archive available]
|
|
|
byuu
|
c58e3af1b5 |
Update to bsnes v025r02? release.
Alright, posted a new WIP with the BS-X skeleton. The
BIOS needs to be named bsxbios.bin, and it can't have a header.
There's also "Load Special -> Load BS-X Cartridge ...", but it
doesn't work yet. It maps the flash cart into $[c0-ff]:[0000-ffff],
but that doesn't do much good. The BIOS then detects the flash cart
and starts probing the memory mapping registers and eventually
deadlocks.
To emulate the MMIO registers, I will have to
_completely_ rework my memory mapping code to support dynamic
remapping. Not necessarily a bad thing, I was planning to rewrite all
of that anyway (per my diagram yesterday). Might as well kill two
birds with one stone.
Gonna take at least a few days of planning before I go at that. I
want to get it right this time, so I don't have to do this again.
In the meantime, have fun walking around the dead St.
GIGA ghost town ;)
> Byuu, that's some sweet ass shiz. You are a man on a mission this
> week. Let me know when you feel you've supported it enough to remove
> it from the list.
Yeah, not sure what's up. I rarely have motivation to do anything
anymore, but it always comes in bursts. So I'll take advantage of it
now, and hope it doesn't burn out soon.
I've a long way to go with BS-X before we can remove it, sadly. I
think we can remove when I get >50-75% of games loading. I doubt we
can reach 100%. There's missing info, corrupted / hacked BS ROMs
galore, and I don't even have BS-X hardware to test with.
> byuu, you always show something cool in a new version RIGHT after
> your official releases
Sorry about that, it's not intentional. The thing is that no BS-X
games are even playable yet. I suppose when it's stable, I'll post
another public version, assuming the core is still stable with all the
plans I have for it.
> I really enjoy following your development of bsnes. I can't wait for
> the day I have a computer that is actually fast enough to play games
> with it (I'm currently using an Athlon 1.1 GHz).
Sorry about that :(
---
Side note: I also posted v0.025a, which removes the warning message
when SRM files don't exist. Nothing else is different, though.
[No archive available]
|
|
|
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]
|
