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.
Tim Allen