When making a save state, all the system components are "fast forwarded" to a
safe state that can be serialised. If delayedSync (called "Coprocessor Fast
Sync" in the UI) is enabled, this works perfectly. If it is disabled, the
accurate coprocessor synching interferes with the save-state creation, leading
to the game crashing or (worse) the emulator freezing.
Star Fox is a good test case - repeatedly saving state and loading it will very
quickly cause the game to run super-slowly, hang, or crash.
Ideally, somebody should dig into exactly what coprocessor syncing is doing
that breaks the assumptions of the state-saving code, but given how complex
the whole thing is, and given that it doesn't affect hardware emulation
accuracy (real hardware can't save states at all), it's easiest to just force-
enable delayedSync while a save-state is in progress.
Fix from the jgemu bsnes fork:
8b4d1b8ae5
Many specializations of stringify store a reference to the wrapped
value. Therefore, passing arguments to make_string() by value can be
disastrous if the compiler does not perform copy elision and stringify
stores a reference to a variable that goes out of scope when
make_string() returns.
Cherry-picked from ares commit 3d826f5b266027529f0c12211c744a23bbe25a56.
Commit 712ed9b6b0 changed the way that the Sufami
Turbo base cartridge was detected, but it caused crashes. Apparently the way we
were converting the binary ROM data to a string for comparison, was actually
calling the wrong `string` constructor. Let's more explicitly create a
string_view instead of hoping for the compiler to pick a suitable constructor
chain.
The Sufami Turbo base cartridge is listed in the Super Famicom verified dump
database, so it did not use the heuristics. It turns out the heuristic detection
wouldn't have worked anyway - although the game's header does contain the serial
A9PJ, the heuristic revision() method does not report that serial at all.
Meanwhile, the serial A9PJ is *also* used by the game Bishoujo Senshi Sailor
Moon SuperS - Fuwafuwa Panic, so loading this game would prompt for Sufami Turbo
mini-cartridges even though the game could not make use of them.
Fixes#323
Since we have different hosts for different builds, let's try linking to them
directly. I vaguely recall this stopped working at some point, but we'll try
again.
>Regarding PLB, it looks like it reads from $200 and snes9x, mesen,
bsnes, and the official CPU manual all got it wrong.
Reproduced and verified on real hardware via
https://github.com/gilyon/snes-tests
Although Nintendo made many different cartridge circuit boards with different
memory mappings, ROMs do not indicate which specific board they are intended
to work with. Super Famicom emulators traditionally group mutually-compatible
mappings together and use heuristics to guess which family of mappings the
game expects.
There's one family of mappings that maps ROM data to the top half ($8000-$FFFF)
of memory banks in the Super Famicom address space. For historical reasons,
this family is called "LoROM" and has three main variants:
1. ROM only, mapped to the top half of every possible bank.
The boards database calls this "LOROM".
2. ROM mapped to the top half of every possible bank,
RAM mapped to the bottom half of banks 70-7d,f0-ff.
The boards database calls this "LOROM-RAM"
3. ROM mapped to the top half of low-numbered banks,
RAM mapped to both halves of banks 70-7d,f0-ff.
The boards database calls this "LOROM-RAM#A"
The largest official game that used variant 3 was 1MiB, so a common heuristic
is "if the ROM is 2MiB or less, use variant 3, otherwise use variant 2".
2MiB is used as the threshold instead of 1MiB, perhaps so somebody can expand a
commercial ROM that uses variant 3 without having to rework it to suit a
different mapping.
Since v107 or so, higan (and by extension, bsnes) has implemented variant 3 by
mapping ROM to banks 00-3f,80-bf, which exactly fits a 2MiB ROM. However,
other emulators like Mesen, snes9x and higan v106 implement it by mapping ROM
to banks 00-6f,80-ef, all the space that is left after the RAM is mapped.
This doesn't affect any verified games in the `Super Famicom.bml` database,
since those have specific, accurate memory maps. It also won't affect
well-written games that only read from memory addresses they have populated.
However, homebrew games and ROM hacks that have never existed on a real circuit
board depend on these heuristics across all devices that read Super Famicom
ROMs, including software emulators, flash-carts, and FPGA implementations, so
bsnes should match what other emulators do.
Fixes#278.
Natural/Integer<T>.bit() (BitRange) was shifting by whatever type the source was to match the target bit length.
But this breaks when the target type is u64/s64 and the source type is u32/s32 or smaller. Shifting by >=32 becomes undefined behavior.
We have to cast the input source to the target type first, so that the source<<shift result is valid.
This is safe here regardless of source's signedness, because it's only used in =, &=, ^=, |= operations.
GTK+3 is designed for automatic layout, where widgets are automatically sized
and positioned according to the size of their contents. However, hiro has to be
compatible with Windows, which lacks an automatic layout system, so hiro apps
tend to position widgets manually.
Unfortunately, the GTK+3 default theme uses much bigger widgets than GTK+2 or
Windows, so hiro apps using the GTK+3 backend tend to have ugly, overlapping
widgets. To make GTK+3 behave more like other hiro targets, we add custom CSS
and override the default theme at runtime.
Fixes#168.
The GTK2 and GTK3 backends for hiro implement a source-code editing widget
based on gtksourceview. gtksourceview2 in particular is quite old and
unmaintained, and Linux distros are keen to drop it, so removing the dependency
helps keep bsnes portable to future platforms -- especially since bsnes doesn't
*use* the source-editing widget anywhere. It's only used by Near's text-editor,
amethyst.
We could just rip out the gtksourceview-related code and be done with it,
but since Near is still around and still working on his own copy of hiro, I
asked him to contribute his implementation so that it will be easier to merge
any future changes too.
This adds two new hiro targets, "gtk2-se" and "gtk3-se" which include the
source-code editing widget and the gtksourceview dependency. Since bsnes
defaults to "gtk2" (without the dependency) we no longer need that package
installed to build bsnes.
Fixes#137.
Currently, value_to_string and debugger_value_to_string use an
error-prone calculation to avoid overflow. This was once adjusted
already, and one of the codepaths is still vulnerable. Put this in a
symfile:
01:5678 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
and execute `p 1:$5679`. On Linux, the canary terminates the process.
I've registered https://bsnes.dev to be the new homepage for the project.
Screwtape and I are still working out how we're going to handle the page, but I want to get away from the old domain, and this is where we start that process.
These examples were originally included in various standalone libco
releases, not as part of any higan or bsnes release. test_timing in
particular is a benchmark and smoke-test as well as a basic example
of how to use libco.
To resize a window on X11, the window manager tells the X11 server to change the
window size, then the X11 server tells the application to paint itself, and then
(eventually) the application tells the X11 server what to draw. This adds an
arbitrary amount of latency to resizing, so to make things feel more responsive,
the X11 server will paint any newly-exposed parts of the window with a default
background colour. If it happens to be the same colour as the appplication would
paint anyway, this gives resizing a much better user-experience.
Since most of bsnes' window is occupied by the viewport, which is always black,
bsnes accordingly set its window background colour to black for the best
resizing experience. However, this had two additional effects:
- When no game is loaded, bsnes displays the bsnes icon in the main display
area. Black canvas widgets are used as spacers to position the icon
correctly, but the spacers don't cover the entire background, and the window
background shines through.
- GTK+3 draws widget transparent by default, so the background colour of the
parent widget shines through child widgets. In particular, setting the
window background to black makes the menu background black, even if the menu
text is also a dark colour.
In order to get the menu to display properly in GTK+3 builds, we have to stop
bsnes from setting the top-level window background colour, and we also have to
ensure that the spacer widgets around the icon cover the entire surface of the
window.
Fixes#108.
On X11, hiro uses the xdg-screensaver helper tool to disable the screensaver,
which detects the screensaver that is running and uses the appropriate
mechanism to communicate with it. The tool's API expects an X11 window ID,
but at least some screensavers ignore it, so it can be set up however. The
GNOME backend *does* care about the window ID, but its expectations are not
documented anywhere, so byuu spent a frustrating few days trying things
at random to get it working, and failing.
It turns out, GNOME does *not* require the window to be mapped, but it *does*
require the window to have a name. Using XStoreName() to name the window fixes
screensaver suspension for me under GNOME 3.38.
Note: while XStoreName is technically deprecated, it's not going to go away
while X11 is still around, and the reason it's deprecated is because it doesn't
include character encoding data. We don't care — no user should ever see the
window name, and it's plain ASCII so it should be fine.
Fixes#102.
This corrects the reporting bit of HVBJOY to be set during the auto joypad
polling sequence.
This change will fix *SpellCraft - Aspects of Valor*. SpellCraft works by
polling JOY1 nonstop once menus are entered on every scanline, so with incorrect
HVBJOY bit 0 reporting, the game was thinking it was safe to read JOY1 during
the auto joypad polling sequence, so partially shifted in results were being
read back as valid. With this patch, you'll find that the game stops polling
between V:225 H:130 and V:228 H:256, which is the auto polling time range.
Before, it was polling during that time. As a result of this fix, the password
menu can be accessed safely without it closing immediately.
Fixes#86.
- Fixes a bug where the program may crash or display improper buttons
when changing the selected row during assignment.
This appears to just be a mistake, accidentally using the 'batched'
rows instead of the activeMapping row.
- Fixes a bug where starting multiple assignments without finishing
one leads to stale "Assigning..." text in some rows.
This appears to be an oversight. Simply refreshing the mappings
before starting an assignment fixes this.
This commit reworks when the screensaver suppression kicks in.
Previously, bsnes would only engage screensaver suppression once, on
application launch. Now that the option is exposed and can be toggled at
any time, we have to be a little more clever.
Additionally, screensaver suppression is now only engaged while
emulation is active, because it doesn't make much sense otherwise.
The setting already existed and could be changed by manually editing the
configuration file, but wasn't exposed in the UI. This commit adds the
corresponding check box.
As I was doing the research for #51, I figured I should write down what I
learned before I forgot it, and if I was going to do that, I might as well
write it down in Markdown so we can make a website from it.
In f09c45f, we fixed native file picker dialogs, so they would correctly set the
"option" field to Auto when loading games, instead of leaving it set to an empty
string which effectively forced NTSC mode. However, this wouldn't fix up the old
entries in the Recent Games menu, so we will patch them up if we encounter them.
Specifically, we don't know what happens when reading from 4016-4017 or 4218-421f, or when writing to 4016 or 4200, during the auto joypad polling sequence.
Presumably, nothing good.
anomie's notes indicate that polling begins between cycles 32.5-95.5, but his
notes were slightly off. 32.5-95.5 is referring to the PPU dot clock. If you
multiply by 4 you get the cycle count, 130-382. It's pretty clear that in
256-cycle units, that would need to be 130-384 or you'd have no event when it
lands on cycle 384. Jonas Quinn confirmed that with his testing in any case.
I chose to split the cycle range in half and run things every 128 clocks. So
that reduces us to 32.5-64.0, or 130 to 256 + 258-384. The reason I chose 128
over 256 was so I could emulate the time it takes to perform the joypad
latching. I don't believe you can set the controller latch to 1 and then 0
immediately. It needs time to let the controllers see this happening and then
release the latch, and time to let that take effect. Polling the controllers is
only one operation so it makes sense that happens once every 256 cycles, which
is why I have the (counter&1) test for that.
Think about it this way: we know the polling sequence takes 4224 cycles, and
4224/256 is 16.5. Isn't that a little strange to have half a cycle? But if we
consider the latching is actually twice as fast, then it's 2x128 + 16x256. If we
run on a 128-clock counter, it becomes 2x128 + 16x2x128, or 34 total states. But
now since we don't actually poll on the second half of each 16x2x256 states, we
don't need to bother running the event there, so we can stop at 33 instead of 34
and it's the same thing. And by doing that, it turns our polling duration into
4224 cycles, just like we've observed.
Fixes#61.
Previously, we didn't have control of byuu.org and it wasn't obvious what we
should do about hosting. Now we can update byuu.org, though, we should continue
using it as the authoritative source information.
Fixes#2.
hiro has two confusingly-named file-picker dialogs. "BrowserDialog" is the
custom dialog built entirely with hiro widgets, "BrowserWindow" is a wrapper
around the native file-picker. bsnes is built for BrowserDialog, but if you tick
"Use native file picker" in the Emulator options, when it needs a file it will
construct a BrowserDialog, copy the relevant config options across to a new
BrowserWindow and invoke that.
Unfortunately, BrowserDialog and BrowserWindow have different capabilities.
Specifically, BrowserDialog includes an "options" list which bsnes uses to let
the user override region detection when loading a game. BrowserWindow has no
such widget. Thus, when using a BrowserDialog the options list worked as intended,
but when using a BrowserWindow the options list was never initialised and no
option was ever chosen. As a result, when opening a game with the native file-
picker, bsnes always used NTSC emulation mode, instead of auto-detecting.
Previously, constructing a BrowserDialog and calling setOptions would leave the
BrowserDialog in an inconsistent state (with no option selected). This was OK if
you immediately displayed the dialog to the user (this would complete the
initialisation and choose a default), but bsnes also used BrowserDialog as an
*interface* typee, to represent the parameters and results of a file-picker
operation that was implemented elsewhere. For this use-case, the inconsistent
state caused problems.
Therefore, BrowserDialog has been changed:
- setting the list of options always chooses a default, maintaining the
invariant that `.options()` always returns one of the available options.
- The internal BrowserDialogWindow class now takes a reference to a Response
object, instead of constructing one from scratch and having to duplicate
the "set .option to a reasonable value" code.
Fixes#44.
Previously, bsnes would turn the cheat text into a list of cheats by splitting
on '\n', producing an empty "cheat" after the last line of the editor:
"7e0003=00\n".split("\n") -> ["7e0003=00", ""]
That empty "cheat" is not a valid cheat, so the result would be marked invalid.
Teaching bsnes to silently skip empty lines worked, but it would preserve
multiple blank lines between two cheats, which was silly.
Now we iterate over all the lines of the cheat editor, putting valid codes in a
new vector, and setting a flag for invalid codes.
Fixes#63.
This is lightly adapted from the implementation in Higan. For more
information, see that PR in higan-emu/higan#118.
The main difference is that we only compile one binary here, and
packaging is similar to (but adapted from) packaging byuu.
This includes changes to SameBoy (updating the README to be clear about
provenance, and adding a GNUmakefile to integrate with bsnes' build system),
updates the SameBoy version number in the about box, and adds SameBoy to the
list of subtrees updated by update-subtrees.sh.
* WARNING: Backward-incompatibility!
Previously appending using '+=' to an empty variable would result in a value
starting with a space. Now the initial space is only added if the variable
already contains some value. Similarly, appending an empty string does not
add a trailing space.
https://lwn.net/Articles/810071/
Apparently there's two versions of the ISC license; the original says "and"
while the updated one says "and/or". This was copied from the ares v115 release,
so it should be the variant byuu intended by "ISC".
Fixes#19.
When Near took down byuu.org, he also removed the images that the bsnes
README was ointing to. He gave me backups of data from the site, including the
images used on the bsnes homepage, but apparently the README used different
images hosted in a different location.
I've replaced the missing images with ones from the bsnes homepage that
look reasonable.
The official libco repository was created as a snapshopt of the then-current state of libco
in the higan repository. However, it would be a shame to lose all the
development history and changelogs that led up to this point.
This commit merges in the change history extracted from the higan repository,
including reconstructed history from the bsnes-history-kit project. Note that
many commit messages mention changes outside of libco, and some *only* mention
non-libco changes because the libco change was relatively minor compared to the
overall changes. Hopefully it's generally clear what libco changes were made and
why... but even if it isn't, this is all the information we have.
Fixes#2.
updateControls assumes that when activeMapping is set, an item from
mappingList is guaranteed to be selected. However, there are several
scenarios that break this assumption:
- changing port during an active mapping
- changing device during an active mapping
- reloading the input driver during an active mapping
In all of these cases, updateControls is eventually called. It sees an
outstanding activeMapping and proceeds to figure out the offset of the
currently selected item, but since there are no selected items it ends
up dereferncing a null pointer.
The assumption can be honored by having reloadMappings cancel the
outstanding activeMapping, thus preventing a crash.
Fixes#4.
Improves thread-switching performance using the following techniques:
- Interleave stores/loads
- Restore the stack pointer and link register as early as possible
The calling convention specifies that d8-d15 (the lower 64 bits of
vector registers q8-q15) are callee-saved. However, libco was
erroneously saving and restoring general-purpose registers x8-x15
instead.
SFC: disable math color bleed for first pixel
(fixes green line on the left-edge of Jurassic Park)
SFC/GG: attach Screen settings to Screen node, not PPU/VDP node
(fixes remembering Screen settings)
The existing ppc implementation in libco only supports
the ELFv1 ABI on PowerPC 64 and therefore can't be used on
Little Endian systems and Big Endian systems running ELFv2
distros.
This commit introduces a new implementation of the libco
API for ppc64 elfv2. It has been tested with bsnes and higan.
The original ppc implementation is maintained for non-ELFv2
targets.
The logo is compressed using PB8, a form of RLE with unary-coded
run lengths. Each block representing 8 bytes consists of a control
byte, where each bit (MSB to LSB) is 0 for literal or 1 for repeat
previous, followed by the literals in that block.
PB8 compression is also used in a few NES games. A variant called
PB16, where 1 means repeat 2 bytes back, is used in the Game Boy
port of 240p Test Suite and in Libbet and the Magic Floor.
Switching from logo-compress RLE to PB8 decreases the compressed
logo data size from 287 bytes to 253 bytes, saving 34 bytes.
The decompression code is also about 10 bytes smaller.
byuu says:
- ruby: fullscreen support for Windows OpenGL 3.2, DirectDraw 7.0, GDI drivers
- ruby: output(width, height) support for all drivers on all platforms
- hiro: improve focus capture for Canvas and Viewport widgets
- hiro: added two hotfixes for the macOS Cocoa target [Sintendo]
- higan, bsnes: focus the viewport after leaving fullscreen exclusive mode
- freebsd: moved from GCC 8.2.0 to Clang 6.0.1
- higan: added video display emulation option to Famicom and Mega Drive cores
The reason I moved to Clang was because GCC keeps deadlocking my FreeBSD system.
I don't know if it's GCC's fault, or suddenly running 32 copies of any high-CPU
usage program, heh. But at any rate, it's worth a try. The performance is the
same, but compilation takes a tiny bit longer with Clang.
byuu says:
I finally pass blargg's dmg-sound and cgb-sound tests, but at quite a cost.
Reads and writes can't happen on an exact T-cycle (clock cycle) point within an
M-cycle (opcode cycle) for the DMG. Writes to trigger take effect two clocks
after writes to wave RAM, for instance. Probably going to be a lot more of this
in low-level PPU emulation, so I'm biting the bullet and slowly converting the
Game Boy bus handler to this new format, which I'll use as a test bench for
doing this later to other systems with, since Game Boy performance isn't as
critical (it's a drop from 220fps to 200fps to have to poll the bus four times
per memory access and synchronize the CPU four times as often, so a lot less bad
than I'd feared at least.)
[This WIP was made after byuu's forum closed, so byuu only gave a one-line
description -Ed.]
byuu says:
This splits ColecoVision, SG-1000/SC-3000 away from Master System/Game Gear.
Was getting too crowded in there.
Normally, SameBoy would use executable-relative paths for any
resource files, which posed problems for packaging the software
by distributions, which usually prefer FHS-compliant file locations.
This commit makes it possible to specify an alternative base
directory with a compile-time environment variable.
```
Core/z80_cpu.c: In function ‘add_hl_rr’:
Core/z80_cpu.c:341:31: error: suggest parentheses around ‘+’ in operand of ‘&’ [-Werror=parentheses]
if ( ((unsigned long) hl) + ((unsigned long) rr) & 0x10000) {
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
```
This change makes it so that there is a return value when a kind doens't match. Allows -Werror=return-type to pass.
```
Core/debugger.c: In function ‘read_lvalue’:
Core/debugger.c:239:1: error: control reaches end of non-void function [-Werror=return-type]
}
```
Previously the Makefile, when run on Windows, expected the uname command to report either "MINGW" or "windows32". This was unfortunate because the uname included in Git for Windows reports "MSYS".
With this change, the Makefile will work properly with any uname, whether it comes from MinGW, GnuWin32 or Git for Windows.
Instead of the legacy SDL_OpenAudio() method, we now use the newer
SDL_OpenAudioDevice() functions. This fixes audio in Windows if the SDL
version is 2.0.6 or higher.
It also allows us to use 48kHz audio for Windows (96kHz somewhat works
too, but since we don't get absolutely smooth audio with it, I'd stick
with 48kHz for now until we find a solution. 44.1Khz is available as
fallback for SDL 2.0.5 and lower. Yes, the 2.0.5 to 2.0.6 transition was
quite harsh in terms of Windows audio support...
Before performing the GB reset, we should perform a GB_save_battery.
Otherwise, resetting the emulation will kill ("kill" as in simply don't
write them into the .sav) all changes made to the battery save since
sameboy was started.
Because SDL_SCANCODE_0 comes *after* SDL_SCANCODE_9 in the SDL keycode
table, we have to check if the keycode is between >=1 and <=0. We also
have to substract SDL_SCANCODE_1 in order to set command_parameter
properly.
Errata: Currently, the savestate created with CTRL+0 is created, but
refuses to load on Windows (working fine on Linux).
Sampling at the edge between texels causes one or the other to be chosen
semi-randomly, depending on rounding errors. Add half a pixel so they
sample at texel centers instead.
This corrects the pitch parameter for the video refresh callback to be the actual pitch instead of 0.
Setting it to 0 seems to work fine for OpenGL, but it causes the graphics to be broken with Vulkan, at least with an AMD card on Linux.
byuu says:
Changelog:
- higan: readded support for soft-reset to Famicom, Super Famicom,
Mega Drive cores (work in progress)
- handhelds lack soft reset obviously
- the PC Engine also lacks a physical reset button
- the Master System's reset button acts like a gamepad button, so
can't show up in the menu
- Mega Drive: power cycle wasn't initializing CPU (M68K) or APU (Z80)
RAM
- Super Famicom: fix SPC700 opcode 0x3b regression; fixes Majuu Ou
[Jonas Quinn]
- Super Famicom: fix SharpRTC save regression; fixes Dai Kaijuu
Monogatari II's real-time clock [Talarubi]
- Super Famicom: fix EpsonRTC save regression; fixes Tengai Makyou
Zero's real-time clock [Talarubi]
- Super Famicom: removed `*::init()` functions, as they were never used
- Super Famicom: removed all but two `*::load()` functions, as they
were not used
- higan: added option to auto-save backup RAM every five seconds
(enabled by default)
- this is in case the emulator crashes, or there's a power outage;
turn it off under advanced settings if you want
- libco: updated license from public domain to ISC, for consistency
with nall, ruby, hiro
- nall: Linux compiler defaults to g++; override with g++-version if
g++ is <= 4.8
- FreeBSD compiler default is going to remain g++49 until my dev
box OS ships with g++ >= 4.9
Errata: I have weird RAM initialization constants, thanks to hex_usr
and onethirdxcubed for both finding this:
http://wiki.nesdev.com/w/index.php?title=CPU_power_up_state&diff=11711&oldid=11184
I'll remove this in the next WIP.
Added LICENSE.txt and GPLv3.txt. Also updated libco documentation.
After discussion with byuu, libco gets a more specific ISC license
to match nall, ruby and hiro. higan, as clarified in LICENSE.txt,
continues to be GPL version 3 only (no "or later" clause).
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.
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
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"
- Fixed a bug where low sampling rate or disabled sound resulted in wrong APU behavior.
- Added API to get the current number of pending samples.
- This change broke save state compatibility with v0.8 and older
Closes#8.
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.
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.
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.
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.
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'
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.)
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.
byuu says:
Basically just a project rename, with s/bsnes/higan and the new icon
from lowkee added in.
It won't compile on Windows because I forgot to update the resource.rc
file, and a path transform command isn't working on Windows.
It was really just meant as a starting point, so that v091 WIPs can flow
starting from .00 with the new name (it overshadows bsnes v091, so
publicly speaking this "shouldn't exist" and will probably be deleted
from Google Code when v092 is ready.)
byuu says:
Most notably, this release adds Nintendo DS emulation. The Nintendo DS
module was written entirely by Cydrak, so please give him all of the
credit for it. I for one am extremely grateful to be allowed to use his
module in bsnes.
The Nintendo DS emulator's standalone name is dasShiny. You will need
the Nintendo DS firmware, which I cannot provide, in order to use it. It
also cannot (currently?) detect the save type used by NDS games. As
such, manifest.xml files must be created manually for this purpose. The
long-term plan is to create a database of save types for each game.
Also, you will need an analog input device for the touch screen for now
(joypad axes work well.)
There have also been a lot of changes from my end: a unified
manifest.xml format across all systems, major improvements to SPC7110
emulation, enhancements to RTC emulation, MSU1 enhancements, icons in
the file browser list, improvements to SNES coprocessor memory mapping,
cleanups and improvements in the libraries used to build bsnes, etc.
I've also included kaijuu (which allows launching game folders directly
with bsnes) and purify (which allows opening images that are compressed,
have copier headers, and have wrong extensions); both of which are fully
GUI-based.
This release only loads game folders, not files. Use purify to load ROM
files in bsnes.
Note that this will likely be the last release for a long time, and that
I will probably rename the emulator for the next release, due to how
many additional systems it now supports.
byuu says:
Changelog:
- removed bsnes/supergameboy (libgameboy -> libgambatte binding)
- added direct ICD2-R coprocessor emulation
- linked in bgameboy to the ICD2-R module
- Makefile removes -Isnes, all files adjusted from <name.hpp> to
<snes/name.hpp> [relic from asnes split]
You can now play Super Game Boy games with the core bsnes library.
The source tarball also included empty obj/ and out/ directories which
git does not support.
byuu says:
Project started, so basically everything is new.
It's basically a rough skeleton that mimics bsnes project structure.
Eventually the src/gameboy folder will be copied into bsnes-official and
used by the chip/supergameboy core.
The middleware layer (supergameboy/interface) will be merged into a new
chip/icd2 folder that will represent direct Super Game Boy emulation in
the future.
At least, if all goes according to plan.
There is a simple GUI that can load ROMs, but do nothing after it. It's
not hooked up to ruby yet.
There is a basic system class and interface to expose the
video/audio/input functions.
There is a basic memory bus that doesn't support any MBCs yet.
There is a CPU skeleton that only handles easy read/write access to the
CPU registers (AF is a really fucked up register.)
The core is not hooked up to libco yet, but I intend for it to be, so
that I can run the CPU + LCD how I like.
If it turns out the LCD+audio is easily enslavable, then I'll probably
drop libco and just run it like a regular emulator, using a thread
wrapper around it in bsnes only. We'll see.
The CPU doesn't actually support any opcodes, and loading a ROM won't
actually execute anything.
byuu says:
This release marks a major step forward, offering full low-level
emulation of all four DSP coprocessors based on the NEC uPD77C25
processor core. Many people were responsible for this milestone: Dr.
Decapitator for the actual decapping and extraction; Lord Nightmare for
the cartridges and some special analysis tools; myself, Jonas Quinn and
Cydrak for the uPD77C25 emulation; and all of the donors who raised the
necessary $1,000 for the necessary hardware and equipment needed to pull
this all off. To say thanks to the donors, I am releasing the uPD77C25
emulation core to the public domain, so that everyone can benefit from
it.
All four DSP emulations will be improved by this by way of having
realistic timing; the DSP-4 will benefit further as the high-level
emulation was incomplete and somewhat buggy; and the DSP-3 will benefit
the most as the high-levle emulation there was not complete enough to be
playable. As a result, most notably, this means bsnes v073 is the first
emulator to fully be able to play SD Gundam GX (J)!
As bsnes' primary goal is accuracy, the LLE DSP support renders the old
HLE DSP support obsolete. Ergo, I have removed the 166KB of HLE source
code, and replaced it with the uPD77C25 core, which comprises a mere
20KB of source code. As this LLE module supports save states, this also
means that for the first time, DSP-3 and DSP-4 games have save state
support.
On the other hand, this also means that to run any DSP game, you will
need the appropriate program ROM. As these are copyrighted, I cannot
distribute them nor tell you where to get them. All I can do is provide
you with the necessary filenames and hashes.
Changelog (since v072 release):
* added NEC uPD77C25 emulation core
* added low-level emulation of the DSP-1, DSP-1B, DSP-2, DSP-3, DSP-4
coprocessors
* removed high-level emulation of the DSP-n coprocessors
* added blargg's libco::ppc.c module, which is far more portable, even
running on the PS3
* added software filter support via binary plugins
* added debugger (currently Linux-only); but it is as yet unstable
* added pause shortcut
* updated mightymo's cheat code database
byuu says:
This fixes libsnes and debugger builds, and collapses bsnes/ppu/bppu to
bsnes/ppu and bsnes/dsp/sdsp to bsnes/dsp. It also introduces
bsnes/sync.sh, which will synchronize all of asnes/ with bsnes/,
excepting the custom speed-focused modules. So far, that's bsnes/ppu
(scanline renderer) and bsnes/dsp (state machine.)
Should make keeping the two ports in sync much, much easier. It's
basically the same thing as before, only you run sync.sh and have a few
duplicated folders now. May make it clearer by creating a stub/ or src/
folder inside bsnes to do all of the copying, so that you only see the
custom folders in bsnes/' root directory.
This release greatly polishes the user interface, adds a new cheat code search utility, adds the snesfilter library, and adds Qt-based GUI support to both snesfilter and snesreader. snesfilter gains 2xSaI, Super 2xSaI and Super Eagle support, plus full configuration for both the NTSC and scanline filters; and snesreader gains support support for multi-file ROM archives (eg GoodMerge sets.)
Statically linking Qt to bsnes, snesfilter and snesreader would be too prohibitive size-wise (~10MB or so.) I have to link dynamically so that all three can share the same Qt runtime, which gets all of bsnes and its modules to ~1MB (including the debugger build); and Qt itself to about ~2.5MB.
However, there is some bad news. There's a serious bug in MinGW 4.4+, where it is not generating profile-guided input files (*.gcno files.) There is also a serious bug in Qt 4.5.2/Windows when using dynamic linking: the library is hanging indefinitely, forcing me to manually terminate the process upon exit. This prevents the creation of profile-guided output files (*.gcda files.) It would be tough enough to work around one, but facing both of these issues at once is too much.
I'm afraid I have no choice but to disable profile-guided optimizations until these issues can be addressed. I did not know about these bugs until trying to build the official v053 release, so it's too late to revert to an all-in-one binary now. And I'm simply not willing to stop releasing new builds because of bugs in third-party software. As soon as I can work around this, I'll post a new optimized binary. In the mean time, despite the fact that this release is actually more optimized, please understand that the Windows binary will run approximately ~10% slower than previous releases. I recommend keeping v052 for now if you need the performance. Linux and OS X users are unaffected.
Changelog:
- save RAM is initialized to 0xff again to work around Ken Griffey Jr Baseball issue
- libco adds assembly-optimized targets for Win64 and PPC-ELF [the latter courtesy of Kernigh]
- libco/x86 and libco/amd64 use pre-assembled blocks now, obviates need for custom compilation flags
- added a new cheat code search utility to the tools menu
- separated filters from main bsnes binary to libsnesfilter / snesfilter.dll
- added 2xSaI, Super 2xSaI and Super Eagle filters [kode54]
- added full configuration settings for NTSC and scanline filters (12+ new options)
- further optimized HQ2x filter [blargg]
- added Vsync support to the Mac OS X OpenGL driver
- added folder creation button to custom file load dialog
- fixed a few oddities with loading of "game folders" (see older news for an explanation on what this is)
- updated to blargg's file_extractor v1.0.0
- added full support for multi-file archives (eg GoodMerge sets)
- split multi-cart loading again (BS-X, Sufami Turbo, etc) as required for multi-file support
- cleaned up handling of file placement detection for save files (.srm, .cht, etc)
- file load dialog now remembers your previous folder path across runs even without a custom games folder assigned
- windows now save their exact positioning and size across runs, they no longer forcibly center
- menus now have radio button and check box icons where appropriate
- debugger's hex editor now has a working scrollbar widget
- added resize splitter to settings and tools windows
- worked around Qt style sheet bug where subclassed widgets were not properly applying style properties
A new version of bsnes has been released. It contains a few minor emulation fixes, as well as user interface improvements. Behind the scenes, the source has been cleaned up more in preparation for running the CPU and PPU (video processor) separately from each other (eg with no enslavement.) This is required for implementing a clock cycle based PPU renderer.
- Greatly improved invalid DMA transfer behavior, should be nearly perfect now
- Major code cleanup -- most importantly, almost all PPU timing-related settings moved back to PPU, from CPU
- Added option to auto-detect file type by inspecting file headers rather than file extensions
- Rewrote video filter system to move it out of the emulation core -- HQ2x and Scale2x will work even in hires and interlace modes now, 50% scanline filter added
- Re-added bsnes window icon
- Added new controller graphic when assigning joypad keys [FitzRoy]
- Redundant "Advanced" panel settings which can be configured via the GUI are no longer displayed
- Improved speed regulation settings
- XP and Vista themes will now apply to bsnes controls
- Added "Path Settings" window to allow easy selection of default file directories
- Tab key now mostly works throughout most of the GUI (needs improvement)
- Main window will no longer disappear when setting a video multipler which results in a window size larger than the current desktop resolution
- Added two new advanced options: one to control GUI window opacity, and one to adjust the statusbar text
Changelog:
- OpenGL (with hardware filter mode support) and SDL video drivers added to Linux port
- OpenAL (with speed regulation disable support) and OSS audio drivers added to Linux port [Nach]
- SDL input driver (with joypad support) added to Linux port
- Emulator pause option added
- Added option to select behavior of bsnes when idle: allow input, ignore input or pause emulator
- Added support to remap common GUI actions to key/joypad presses on the "Input Configuration" screen
- bsnes will now clamp the video output size when it is larger than the screen resolution
- GUI library has been enhanced, and renamed to hiro
- Fullscreen mode now always centers video, rather than approximates
- Fullscreen mode now works correctly on Linux/Openbox
- Extra layer of abstraction in src/ui has been removed, as GUI lib unifies all ports anyway
- Video, audio and input drivers unified into standard library, named ruby
- All custom headers have been merged into a new template library, named nall
- Makefile rewritten, vastly improved. Allows quick toggling of compiled-in drivers
- Makefile: all object files now placed in /src/obj, binary placed in /
- libco greatly enhanced, no longer requires an assembler to build [byuu, blargg, Nach]
- libco SJLJ driver added; bsnes should now build on any Unix-derivative now (Solaris, OS X, PS3, etc) [Nach]
- Fixed register $213e.d4 PPU1 open bus behavior [zones]
- Windows port will not activate screensaver while bsnes is running [Nightcrawler]
- Visual C++ target no longer requires stdint.h
- And lots more -- mostly code refactoring related
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]
2007-12-22 18:26:54 +00:00
446 changed files with 54911 additions and 5508 deletions
BESS is a save state format specification designed to allow different emulators, as well as majorly different versions of the same emulator, to import save states from other BESS-compliant save states. BESS works by appending additional, implementation-agnostic information about the emulation state. This allows a single save state file to be read as both a fully-featured, implementation specific save state which includes detailed timing information; and as a portable "best effort" save state that represents a state accurately enough to be restored in casual use-cases.
## Specification
Every integer used in the BESS specification is stored in Little Endian encoding.
### BESS footer
BESS works by appending a detectable footer at the end of an existing save state format. The footer uses the following format:
Every block is followed by another block, until the END block is reached. If an implementation encounters an unsupported block, it should be completely ignored (Should not have any effect and should not trigger a failure).
#### NAME block
The NAME block uses the `'NAME'` identifier, and is an optional block that contains the name of the emulator that created this save state. While optional, it is highly recommended to be included in every implementation – it allows the user to know which emulator and version is compatible with the native save state format contained in this file. When used, this block should come first.
The length of the NAME block is variable, and it only contains the name and version of the originating emulator in ASCII.
#### INFO block
The INFO block uses the `'INFO'` identifier, and is an optional block that contains information about the ROM this save state originates from. When used, this block should come before `CORE` but after `NAME`. This block is 0x12 bytes long, and it follows this structure:
| 0x10 | Bytes 0x14E-0x14F from the ROM (Global checksum) |
#### CORE block
The CORE block uses the `'CORE'` identifier, and is a required block that contains both core state information, as well as basic information about the BESS version used. This block must be the first block, unless the `NAME` or `INFO` blocks exist then it must come directly after them. An implementation should not enforce block order on blocks unknown to it for future compatibility.
The length of the CORE block is 0xD0 bytes, but implementations are expected to ignore any excess bytes. Following the BESS block header, the structure is as follows:
| 0x04 | A four-character ASCII model identifier |
BESS uses a four-character string to identify Game Boy models:
* The first letter represents mutually-incompatible families of models and is required. The allowed values are `'G'` for the original Game Boy family, `'S'` for the Super Game Boy family, and `'C'` for the Game Boy Color and Advance family.
* The second letter represents a specific model within the family, and is optional (If an implementation does not distinguish between specific models in a family, a space character may be used). The allowed values for family G are `'D'` for DMG and `'M'` for MGB; the allowed values for family S are `'N'` for NTSC, `'P'` for PAL, and `'2'` for SGB2; and the allowed values for family C are `'C'` for CGB, and `'A'` for the various GBA line models.
* The third letter represents a specific CPU revision within a model, and is optional (If an implementation does not distinguish between revisions, a space character may be used). The allowed values for model GD (DMG) are `'0'` and `'A'`, through `'C'`; the allowed values for model CC (CGB) are `'0'` and `'A'`, through `'E'`; the allowed values for model CA (AGB, AGS, GBP) are `'0'`, `'A'` and `'B'`; and for every other model this value must be a space character.
* The last character is used for padding and must be a space character.
For example; `'GD '` represents a DMG of an unspecified revision, `'S '` represents some model of the SGB family, and `'CCE '` represent a CGB using CPU revision E.
| 0x18 | The values of every memory-mapped register (128 bytes) |
The values of memory-mapped registers should be written 'as-is' to memory as if the actual ROM wrote them, with the following exceptions and note:
* Unused registers have Don't-Care values which should be ignored
* Unused register bits have Don't-Care values which should be ignored
* If the model is CGB or newer, the value of KEY0 (FF4C) must be valid as it determines DMG mode
* Bit 2 determines DMG mode. A value of 0x04 usually denotes DMG mode, while a value of `0x80` usually denotes CGB mode.
* Sprite priority is derived from KEY0 (FF4C) instead of OPRI (FF6C) because OPRI can be modified after booting, but only the value of OPRI during boot ROM execution takes effect
* If a register doesn't exist on the emulated model (For example, KEY0 (FF4C) on a DMG), its value should be ignored.
* BANK (FF50) should be 0 if the boot ROM is still mapped, and 1 otherwise, and must be valid.
* Implementations should not start a serial transfer when writing the value of SB
* Similarly, no value of NRx4 should trigger a sound pulse on save state load
* And similarly again, implementations should not trigger DMA transfers when writing the values of DMA or HDMA5
* The value store for DIV will be used to set the internal divisor to `DIV << 8`
* Implementation should apply care when ordering the write operations (For example, writes to NR52 must come before writes to the other APU registers)
| 0x9C | The offset of RAM from file start (32-bit integer) |
| 0xA0 | The size of VRAM (32-bit integer) |
| 0xA4 | The offset of VRAM from file start (32-bit integer) |
| 0xA8 | The size of MBC RAM (32-bit integer) |
| 0xAC | The offset of MBC RAM from file start (32-bit integer) |
| 0xB0 | The size of OAM (=0xA0, 32-bit integer) |
| 0xB4 | The offset of OAM from file start (32-bit integer) |
| 0xB8 | The size of HRAM (=0x7F, 32-bit integer) |
| 0xBC | The offset of HRAM from file start (32-bit integer) |
| 0xC0 | The size of background palettes (=0x40 or 0, 32-bit integer) |
| 0xC4 | The offset of background palettes from file start (32-bit integer) |
| 0xC8 | The size of object palettes (=0x40 or 0, 32-bit integer) |
| 0xCC | The offset of object palettes from file start (32-bit integer) |
The contents of large buffers are stored outside of BESS structure so data from an implementation's native save state format can be reused. The offsets are absolute offsets from the save state file's start. Background and object palette sizes must be 0 for models prior to Game Boy Color.
An implementation needs handle size mismatches gracefully. For example, if too large MBC RAM size is specified, the superfluous data should be ignored. On the other hand, if a too small VRAM size is specified (For example, if it's a save state from an emulator emulating a CGB in DMG mode, and it didn't save the second CGB VRAM bank), the implementation is expected to set that extra bank to all zeros.
#### XOAM block
The XOAM block uses the `'XOAM'` identifier, and is an optional block that contains the data of extra OAM (addresses `0xFEA0-0xFEFF`). This block length must be `0x60`. Implementations that do not emulate this extra range are free to ignore the excess bytes, and to not create this block.
#### MBC block
The MBC block uses the `'MBC '` identifier, and is an optional block that is only used when saving states of ROMs that use an MBC. The length of this block is variable and must be divisible by 3.
This block contains an MBC-specific number of 3-byte-long pairs that represent the values of each MBC register. For example, for MBC5 the contents would look like:
An implementation should parse this block as a series of writes to be made. Values outside the `0x0000-0x7FFF` and `0xA000-0xBFFF` ranges are not allowed. Implementations must perform the writes in order (i.e. not reverse, sorted, or any other transformation on their order)
#### RTC block
The RTC block uses the `'RTC '` identifier, and is an optional block that is used while emulating an MBC3 with an RTC. The contents of this block are identical to 64-bit RTC saves from VBA, which are also used by SameBoy and different emulators such as BGB.
The length of this block is 0x30 bytes long and it follows the following structure:
| 0x00 | Current seconds (1 byte), followed by 3 bytes of padding |
| 0x04 | Current minutes (1 byte), followed by 3 bytes of padding |
| 0x08 | Current hours (1 byte), followed by 3 bytes of padding |
| 0x0C | Current days (1 byte), followed by 3 bytes of padding |
| 0x10 | Current high/overflow/running (1 byte), followed by 3 bytes of padding |
| 0x14 | Latched seconds (1 byte), followed by 3 bytes of padding |
| 0x18 | Latched minutes (1 byte), followed by 3 bytes of padding |
| 0x1C | Latched hours (1 byte), followed by 3 bytes of padding |
| 0x20 | Latched days (1 byte), followed by 3 bytes of padding |
| 0x24 | Latched high/overflow/running (1 byte), followed by 3 bytes of padding |
| 0x28 | UNIX timestamp at the time of the save state (64-bit) |
#### HUC3 block
The HUC3 block uses the `'HUC3'` identifier, and is an optional block that is used while emulating an HuC3 cartridge to store RTC and alarm information. The contents of this block are identical to HuC3 RTC saves from SameBoy.
The length of this block is 0x11 bytes long and it follows the following structure:
| 0x00 | UNIX timestamp at the time of the save state (64-bit) |
| 0x08 | RTC minutes (16-bit) |
| 0x0A | RTC days (16-bit) |
| 0x0C | Scheduled alarm time minutes (16-bit) |
| 0x0E | Scheduled alarm time days (16-bit) |
| 0x10 | Alarm enabled flag (8-bits, either 0 or 1) |
#### SGB block
The SGB block uses the `'SGB '` identifier, and is an optional block that is only used while emulating an SGB or SGB2 *and* SGB commands enabled. Implementations must not save this block on other models or when SGB commands are disabled, and should assume SGB commands are disabled if this block is missing.
The length of this block is 0x39 bytes, but implementations should allow and ignore excess data in this block for extensions. The block follows the following structure:
| 0x00 | The size of the border tile data (=0x2000, 32-bit integer) |
| 0x04 | The offset of the border tile data (SNES tile format, 32-bit integer) |
| 0x08 | The size of the border tilemap (=0x800, 32-bit integer) |
| 0x0C | The offset of the border tilemap (LE 16-bit sequences, 32-bit integer) |
| 0x10 | The size of the border palettes (=0x80, 32-bit integer) |
| 0x14 | The offset of the border palettes (LE 16-bit sequences, 32-bit integer) |
| 0x18 | The size of active colorization palettes (=0x20, 32-bit integer) |
| 0x1C | The offset of the active colorization palettes (LE 16-bit sequences, 32-bit integer) |
| 0x20 | The size of RAM colorization palettes (=0x1000, 32-bit integer) |
| 0x24 | The offset of the RAM colorization palettes (LE 16-bit sequences, 32-bit integer) |
| 0x28 | The size of the attribute map (=0x168, 32-bit integer) |
| 0x2C | The offset of the attribute map (32-bit integer) |
| 0x30 | The size of the attribute files (=0xfd2, 32-bit integer) |
| 0x34 | The offset of the attribute files (32-bit integer) |
| 0x38 | Multiplayer status (1 byte); high nibble is player count (1, 2 or 4), low nibble is current player (Where Player 1 is 0) |
If only some of the size-offset pairs are available (for example, partial HLE SGB implementation), missing fields are allowed to have 0 as their size, and implementations are expected to fall back to a sane default.
#### END block
The END block uses the `'END '` identifier, and is a required block that marks the end of BESS data. Naturally, it must be the last block. The length of the END block must be 0.
## Validation and Failures
Other than previously specified required fail conditions, an implementation is free to decide what format errors should abort the loading of a save file. Structural errors (e.g. a block with an invalid length, a file offset that is outside the file's range, or a missing END block) should be considered as irrecoverable errors. Other errors that are considered fatal by SameBoy's implementation:
* Duplicate CORE block
* A known block, other than NAME, appearing before CORE
* An invalid length for the XOAM, RTC, SGB or HUC3 blocks
* An invalid length of MBC (not a multiple of 3)
* A write outside the $0000-$7FFF and $A000-$BFFF ranges in the MBC block
* An SGB block on a save state targeting another model
GitHub Issues are the most effective way to report a bug or request a feature in SameBoy. When reporting a bug, make sure you use the latest stable release, and make sure you mention the SameBoy frontend (Cocoa, SDL, Libretro) and operating system you're using. If you're using Linux/BSD/etc, or you build your own copy of SameBoy for another reason, give as much details as possible on your environment.
If your bug involves a crash, please attach a crash log or a core dump. If you're using Linux/BSD/etc, or if you're using the Libretro core, please attach the `sameboy` binary (or `libretro_sameboy` library) in that case.
If your bug is a regression, it'd be extremely helpful if you can report the the first affected version. You get extra credits if you use `git bisect` to point the exact breaking commit.
If your bug is an emulation bug (Such as a failing test ROM), and you have access to a Game Boy you can test on, please confirm SameBoy is indeed behaving differently from hardware, and report both the emulated model and revision in SameBoy, and the hardware revision you're testing on.
If your issue is a feature request, demonstrating use cases can help me better prioritize it.
## Pull Requests
To allow quicker integration into SameBoy's master branch, contributors are asked to follow SameBoy's style and coding guidelines. Keep in mind that despite the seemingly strict guidelines, all pull requests are welcome – not following the guidelines does not mean your pull request will not be accepted, but it will require manual tweaks from my side for integrating.
### Languages and Compilers
SameBoy's core, SDL frontend, Libretro frontend, and automatic tester (Folders `Core`, `SDL`&`OpenDialog`, `libretro`, and `Tester`; respectively) are all written in C11. The Cocoa frontend, SameBoy's fork of Hex Fiend, JoyKit and the Quick Look previewer (Folders `Cocoa`, `HexFiend`, `JoyKit` and `QuickLook`; respectively) are all written in ARC-enabled Objective-C. The SameBoot ROMs (Under `BootROMs`) are written in rgbds-flavor SM83 assembly, with build tools in C11. The shaders (inside `Shaders`) are written in a polyglot GLSL and Metal style, with a few GLSL- and Metal-specific sources. The build system uses standalone Make, in the GNU flavor. Avoid adding new languages (C++, Swift, Python, CMake...) to any of the existing sub-projects.
SameBoy's main target compiler is Clang, but GCC is also supported when targeting Linux and Libretro. Other compilers (e.g. MSVC) are not supported, and unless there's a good reason, there's no need to go out of your way to add specific support for them. Extensions that are supported by both compilers (Such as `typeof`) may be used if it makes sense. It's OK if you can't test one of these compilers yourself; once you push a commit, the CI bot will let you know if you broke something.
### Third Party Libraries and Tools
Avoid adding new required dependencies; run-time and compile-time dependencies alike. Most importantly, avoid linking against GPL licensed libraries (LGPL libraries are fine), so SameBoy can retain its MIT license.
### Spacing, Indentation and Formatting
In all files and languages (Other than Makefiles when required), 4 spaces are used for indentation. Unix line endings (`\n`) are used exclusively, even in Windows-specific source files. (`\r` and `\t` shouldn't appear in any source file). Opening braces belong on the same line as their control flow directive, and on their own line when following a function prototype. The `else` keyword always starts on its own line. The `case` keyword is indented relative to its `switch` block, and the code inside a `case` is indented relative to its label. A control flow keyword should have a space between it and the following `(`, commas should follow a space, and operator (except `.` and `->`) should be surrounded by spaces.
Control flow statements must use `{}`, with the exception of `if` statements that only contain a single `break`, `continue`, or trivial `return` statements. If `{}`s are omitted, the statement must be on the same line as the `if` condition. Functions that do not have any argument must be specified as `(void)`, as mandated by the C standard. The `sizeof` and `typeof` operators should be used as if they're functions (With `()`). `*`, when used to declare pointer types (including functions that return pointers), and when used to dereference a pointer, is attached to the right side (The variable name) – not to the left, and not with spaces on both sides.
No strict limitations on a line's maximum width, but use your best judgement if you think a statement would benefit from an additional line break.
The primitive types to be used in SameBoy are `unsigned` and `signed` (Without the `int` keyword), the `(u)int*_t` types, `char *` for UTF-8 strings, `double` for non-integer numbers, and `bool` for booleans (Including in Objective-C code, avoid `BOOL`). As long as it's not mandated by a 3rd-party API (e.g. `int` when using file descriptors), avoid using other primitive types. Use `const` whenever possible.
Most C names should be `lower_case_snake_case`. Constants and macros use `UPPER_CASE_SNAKE_CASE`. Type definitions use a `_t` suffix. Type definitions, as well as non-static (exported) core symbols, should be prefixed with `GB_` (SameBoy's core is intended to be used as a library, so it shouldn't contaminate the global namespace without prefixes). Exported symbols that are only meant to be used by other parts of the core should still get the `GB_` prefix, but their header definition should be inside `#ifdef GB_INTERNAL`.
For Objective-C naming conventions, use Apple's conventions (Some old Objective-C code mixes these with the C naming convention; new code should use Apple's convention exclusively). The name prefix for SameBoy classes and constants is `GB`. JoyKit's prefix is `JOY`, and Hex Fiend's prefix is `HF`.
In all languages, prefer long, unambiguous names over short ambiguous ones.
alert.messageText=@"Should SameBoy check for updates when launched?";
alert.informativeText=@"SameBoy is frequently updated with new features, accuracy improvements, and bug fixes. This setting can always be changed in the preferences window.";
[alertaddButtonWithTitle:@"Check on Launch"];
[alertaddButtonWithTitle:@"Don't Check on Launch"];
Fernap
