mirror of https://github.com/bsnes-emu/bsnes.git
12 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
80841deaa5 |
Update to v103r21 release.
byuu says:
Changelog:
- gb: added TAMA emulation [thanks to endrift for the initial notes]
- gb: save RTC memory to disk (MBC3 doesn't write to said memory yet;
TAMA doesn't emulate it yet)
- gb: expect MMM01 boot loader to be at end of ROM instead of start
- gb: store MBC2 save RAM as 256-bytes (512x4-bit) instead of
512-bytes (with padding)
- gb: major cleanups to every cartridge mapper; moved to Mapper class
instead of MMIO class
- gb: don't serialize all mapper states with every save state; only
serialize the active mapper
- gb: serialize RAM even if a battery isn't present¹
- gb/cartridge: removed unnecessary code; refactored other code to
eliminate duplication of functions
- icarus: improve GB(C) heuristics generation to not include filenames
for cartridges without battery backup
- icarus: remove incorrect rearrangement of MMM01 ROM data
- md/vdp: fix CRAM reads -- fixes Sonic Spinball colors [hex\_usr]
- tomoko: hide the main higan window when entering fullscreen
exclusive mode; helps with multi-monitor setups
- tomoko: destroy ruby drivers before calling Application::quit()
[Screwtape]
- libco: add settings.h and defines to fiber, ucontext [Screwtape]
¹: this is one of those crystal clear indications that nobody's
actually playing the higan DMG/CGB cores, or at least not with save
states. This was a major mistake.
Note: I can't find any official documentation that `GL_ALPHA_TEST` was
removed from OpenGL 3.2. Since it's not hurting anything except showing
some warnings in debug mode, I'm just going to leave it there for now.
|
|
|
Tim Allen
|
d5c09c9ab1 |
Update to v103r20 release.
byuu says: Changelog: - ruby/audio/xaudio2: ported to new ruby API - ruby/video/cgl: ported to new ruby API (untested, won't compile) - ruby/video/directdraw: ported to new ruby API - ruby/video/gdi: ported to new ruby API - ruby/video/glx: ported to new ruby API - ruby/video/wgl: ported to new ruby API - ruby/video/opengl: code cleanups The macOS CGL driver is sure to have compilation errors. If someone will post the compilation error log, I can hopefully fix it in one or two iterations of WIPs. I am unable to test the Xorg GLX driver, because my FreeBSD desktop video card drivers do not support OpenGL 3.2. If the driver doesn't work, I'm going to need help tracking down what broke from the older releases. The real fun is still yet to come ... all the Linux-only drivers, where I don't have a single Linux machine to test with. Todo: - libco/fiber - libco/ucontext (I should really just delete this) - tomoko: hide main UI window when in exclusive fullscreen mode |
|
|
Tim Allen
|
8be474b0ac |
Update to v103r19 release.
byuu says:
Changelog:
- tomoko: Application::onMain assigned at end of Program::Program()
[Screwtape]¹
- libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c
[Screwtape]
- ruby/audio/openal: fixed device driver string list enumeration
- ruby/audio/wasapi: changing device re-initializes the driver now
- ruby/audio/wasapi: probably a pointless change, but don't fill the
buffer beyond the queue size with silence
- ruby/video/xvideo: renamed from ruby/video/xv
- ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists
before setting it [SuperMikeMan]
- ruby/video/xvideo: align buffer sizes to be evenly divisible by four
[SuperMikeMan]
- ruby/video/xvideo: fail nicely without crashing (hopefully)
- ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV
formats²
¹: prevents crashes when drivers fail to initialize from running the
main loop that polls input drivers before the input driver is
initialized (or fails to initialize itself.) Some drivers still don't
block their main functions when initialization fails, so they will still
crash, but I'll work to fix them.
²: this was a **major** pain in the ass, heh. You only get one chroma
sample for every four luma samples, so the color reproduction is even
worse than UYVY and YUYV (which is two to four chroma to luma.) Further,
the planar format took forever to figure out. Apparently it doesn't care
what portion of the image you specify in XvShmPutImage, it expects you
to use the buffer dimensions to locate the U and V portions of the data.
This is probably the most thorough X-Video driver in existence now.
Notes:
- forgot to rename the configuration settings dialog window title to
just "Settings"
|
|
|
Tim Allen
|
bdc100e123 |
Update to v102r02 release.
byuu says:
Changelog:
- I caved on the `samples[] = {0.0}` thing, but I'm very unhappy about it
- if it's really invalid C++, then GCC needs to stop accepting it
in strict `-std=c++14` mode
- Emulator::Interface::Information::resettable is gone
- Emulator::Interface::reset() is gone
- FC, SFC, MD cores updated to remove soft reset behavior
- split GameBoy::Interface into GameBoyInterface,
GameBoyColorInterface
- split WonderSwan::Interface into WonderSwanInterface,
WonderSwanColorInterface
- PCE: fixed off-by-one scanline error [hex_usr]
- PCE: temporary hack to prevent crashing when VDS is set to < 2
- hiro: Cocoa: removed (u)int(#) constants; converted (u)int(#)
types to (u)int_(#)t types
- icarus: replaced usage of unique with strip instead (so we don't
mess up frameworks on macOS)
- libco: added macOS-specific section marker [Ryphecha]
So ... the major news this time is the removal of the soft reset
behavior. This is a major!! change that results in a 100KiB diff file,
and it's very prone to accidental mistakes!! If anyone is up for
testing, or even better -- looking over the code changes between v102r01
and v102r02 and looking for any issues, please do so. Ideally we'll want
to test every NES mapper type and every SNES coprocessor type by loading
said games and power cycling to make sure the games are all cleanly
resetting. It's too big of a change for me to cover there not being any
issues on my own, but this is truly critical code, so yeah ... please
help if you can.
We technically lose a bit of hardware documentation here. The soft reset
events do all kinds of interesting things in all kinds of different
chips -- or at least they do on the SNES. This is obviously not ideal.
But in the process of removing these portions of code, I found a few
mistakes I had made previously. It simplifies resetting the system state
a lot when not trying to have all the power() functions call the reset()
functions to share partial functionality.
In the future, the goal will be to come up with a way to add back in the
soft reset behavior via keyboard binding as with the Master System core.
What's going to have to happen is that the key binding will have to send
a "reset pulse" to every emulated chip, and those chips are going to
have to act independently to power() instead of reusing functionality.
We'll get there eventually, but there's many things of vastly greater
importance to work on right now, so it'll be a while. The information
isn't lost ... we'll just have to pull it out of v102 when we are ready.
Note that I left the SNES reset vector simulation code in, even though
it's not possible to trigger, for the time being.
Also ... the Super Game Boy core is still disconnected. To be honest, it
totally slipped my mind when I released v102 that it wasn't connected
again yet. This one's going to be pretty tricky to be honest. I'm
thinking about making a third GameBoy::Interface class just for SGB, and
coming up with some way of bypassing platform-> calls when in this
mode.
|
|
|
Tim Allen
|
c6fc15f8d2 |
Update to v101r18 release.
byuu says: Changelog: - added 30 new PAL games to icarus (courtesy of Mikerochip) - new version of libco no longer requires mprotect nor W|X permissions - nall: default C compiler to -std=c11 instead of -std=c99 - nall: use `-fno-strict-aliasing` during compilation - updated nall/certificates (hopefully for the last time) - updated nall/http to newer coding conventions - nall: improve handling of range() function I didn't really work on higan at all, this is mostly just a release because lots of other things have changed. The most interesting is `-fno-strict-aliasing` ... basically, it joins `-fwrapv` as being "stop the GCC developers from doing *really* evil shit that could lead to security vulnerabilities or instabilities." For the most part, it's a ~2% speed penalty for higan. Except for the Sega Genesis, where it's a ~10% speedup. I have no idea how that's possible, but clearly something's going very wrong with strict aliasing on the Genesis core. So ... it is what it is. If you need the performance for the non-Genesis cores, you can turn it off in your builds. But I'm getting quite sick of C++'s "surprises" and clever compiler developers, so I'm keeping it on in all of my software going forward. |
|
|
Tim Allen
|
4d193d7d94 |
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
|
|
|
Tim Allen
|
47d4bd4d81 |
Update to v096r01 release.
byuu says: Changelog: - restructured the project and removed a whole bunch of old/dead directives from higan/GNUmakefile - huge amounts of work on hiro/cocoa (compiles but ~70% of the functionality is commented out) - fixed a masking error in my ARM CPU disassembler [Lioncash] - SFC: decided to change board cic=(411,413) back to board region=(ntsc,pal) ... the former was too obtuse If you rename Boolean (it's a problem with an include from ruby, not from hiro) and disable all the ruby drivers, you can compile an OS X binary, but obviously it's not going to do anything. It's a boring WIP, I just wanted to push out the project structure change now at the start of this WIP cycle. |
|
|
Tim Allen
|
83f684c66c |
Update to v094r29 release.
byuu says: Note: for Windows users, please go to nall/intrinsics.hpp line 60 and correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before compiling, otherwise things won't work at all. This will be a really major WIP for the core SNES emulation, so please test as thoroughly as possible. I rewrote the 65816 CPU core's dispatcher from a jump table to a switch table. This was so that I could pass class variables as parameters to opcodes without crazy theatrics. With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^= stuff, and all of the template versions of opcodes. I also removed some stupid pointless flag tests in xcn and pflag that would always be true. I sure hope that AWJ is happy with this; because this change was so that my flag assignments and branch tests won't need to build regs.P into a full 8-bit variable anymore. It does of course incur a slight performance hit when you pass in variables by-value to functions, but it should help with binary size (and thus cache) by reducing a lot of extra functions. (I know I could have used template parameters for some things even with a switch table, but chose not to for the aforementioned reasons.) Overall, it's about a ~1% speedup from the previous build. The CPU core instructions were never a bottleneck, but I did want to fix the P flag building stuff because that really was a dumb mistake v_v' |
|
|
Tim Allen
|
e0815b55b9 |
Update to v094r28 release.
byuu says: This WIP substantially restructures the ruby API for the first time since that project started. It is my hope that with this restructuring, destruction of the ruby objects should now be deterministic, which should fix the crashing on closing the emulator on Linux. We'll see I guess ... either way, it removed two layers of wrappers from ruby, so it's a pretty nice code cleanup. It won't compile on Windows due to a few issues I didn't see until uploading the WIP, too lazy to upload another. But I fixed all the compilation issues locally, so it'll work on Windows again with the next WIP (unless I break something else.) (Kind of annoying that Linux defines glActiveTexture but Windows doesn't.) |
|
|
Tim Allen
|
4e2eb23835 |
Update to v093 release.
byuu says: Changelog: - added Cocoa target: higan can now be compiled for OS X Lion [Cydrak, byuu] - SNES/accuracy profile hires color blending improvements - fixes Marvelous text [AWJ] - fixed a slight bug in SNES/SA-1 VBR support caused by a typo - added support for multi-pass shaders that can load external textures (requires OpenGL 3.2+) - added game library path (used by ananke->Import Game) to Settings->Advanced - system profiles, shaders and cheats database can be stored in "all users" shared folders now (eg /usr/share on Linux) - all configuration files are in BML format now, instead of XML (much easier to read and edit this way) - main window supports drag-and-drop of game folders (but not game files / ZIP archives) - audio buffer clears when entering a modal loop on Windows (prevents audio repetition with DirectSound driver) - a substantial amount of code clean-up (probably the biggest refactoring to date) One highly desired target for this release was to default to the optimal drivers instead of the safest drivers, but because AMD drivers don't seem to like my OpenGL 3.2 driver, I've decided to postpone that. AMD has too big a market share. Hopefully with v093 officially released, we can get some public input on what AMD doesn't like. |
|
|
Tim Allen
|
a59ecb3dd4 |
Include all the code from the bsnes v068 tarball.
byuu describes the changes since v067: This release officially introduces the accuracy and performance cores, alongside the previously-existing compatibility core. The accuracy core allows the most accurate SNES emulation ever seen, with every last processor running at the lowest possible clock synchronization level. The performance core allows slower computers the chance to finally use bsnes. It is capable of attaining 60fps in standard games even on an entry-level Intel Atom processor, commonly found in netbooks. The accuracy core is absolutely not meant for casual gaming at all. It is meant solely for getting as close to 100% perfection as possible, no matter the cost to speed. It should only be used for testing, development or debugging. The compatibility core is identical to bsnes v067 and earlier, but is now roughly 10% faster. This is the default and recommended core for casual gaming. The performance core contains an entirely new S-CPU core, with range-tested IRQs; and uses blargg's heavily-optimized S-DSP core directly. Although there are very minor accuracy tradeoffs to increase speed, I am confident that the performance core is still more accurate and compatible than any other SNES emulator. The S-CPU, S-SMP, S-DSP, SuperFX and SA-1 processors are all clock-based, just as in the accuracy and compatibility cores; and as always, there are zero game-specific hacks. Its compatibility is still well above 99%, running even the most challenging games flawlessly. If you have held off from using bsnes in the past due to its system requirements, please give the performance core a try. I think you will be impressed. I'm also not finished: I believe performance can be increased even further. I would also strongly suggest Windows Vista and Windows 7 users to take advantage of the new XAudio2 driver by OV2. Not only does it give you a performance boost, it also lowers latency and provides better sound by way of skipping an API emulation layer. Changelog: - Split core into three profiles: accuracy, compatibility and performance - Accuracy core now takes advantage of variable-bitlength integers (eg uint24_t) - Performance core uses a new S-CPU core, written from scratch for speed - Performance core uses blargg's snes_dsp library for S-DSP emulation - Binaries are now compiled using GCC 4.5 - Added a workaround in the SA-1 core for a bug in GCC 4.5+ - The clock-based S-PPU renderer has greatly improved OAM emulation; fixing Winter Gold and Megalomania rendering issues - Corrected pseudo-hires color math in the clock-based S-PPU renderer; fixing Super Buster Bros backgrounds - Fixed a clamping bug in the Cx4 16-bit triangle operation [Jonas Quinn]; fixing Mega Man X2 "gained weapon" star background effect - Updated video renderer to properly handle mixed-resolution screens with interlace enabled; fixing Air Strike Patrol level briefing screen - Added mightymo's 2010-08-19 cheat code pack - Windows port: added XAudio2 output support [OV2] - Source: major code restructuring; virtual base classes for processor - cores removed, build system heavily modified, etc. |
|
|
Tim Allen
|
165f1e74b5 | First version split into asnes and bsnes. |