Commit Graph

99 Commits

Author SHA1 Message Date
Tim Allen f9adb4d2c6 Update to v106r58 release.
byuu says:

The main thing I worked on today was emulating the MBC7 EEPROM.

And... I have many things to say about that, but not here, and not now...

The missing EEPROM support is why the accelerometer was broken. Although
it's not evidently clear that I'm emulating the actual values
incorrectly. I'll think about it and get it fixed, though.

bsnes went from ~308fps to ~328fps, and I don't even know why. Probably
something somewhere in the 140KB of changes to other things made in this
WIP.
2018-08-21 13:17:12 +10:00
Tim Allen 1e4affe5f9 Update to 20180808 release.
byuu says:

This release fixes the XAudio 2.1 and WASAPI drivers on Windows, and
extends XAudio to support device selection (eg headphones, speakers,
monitor, etc.) It also adds DRC to XAudio, however it's not currently
working.

The code is courtesy of Talarubi, I just botched it somewhere upon
porting it to the newer version of ruby.
2018-08-09 14:16:46 +10:00
Tim Allen 93a6a1ce7e Update to v106r57 release.
byuu says:

I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.

I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.

I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.

Starting now, I'm feature-freezing bsnes and higan. From this point
forward:

  - polishing up and fixing bugs caused by the ruby/hiro changes
  - adding DRC to XAudio2, and maybe exclusive mode to WGL
  - correcting FEoEZ (English) to load and work again out of the box

Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 18:46:58 +10:00
Tim Allen 3b4e8b6d75 Update to v106r56 release.
byuu says:

I fixed all outstanding bugs that I'm aware of, including all of the
errata I listed yesterday.

And now it's time for lots of regression testing.

After that, I need to add Talarubi's XAudio2 DRC code, and then get a
new public bsnes WIP out for final testing.

New errata: when setting an icon (nall::image) larger than a Canvas on
Windows, it's not centering the image, so you end up seeing the overscan
area in the state manager previews, and the bottom of the image gets cut
off. I also need to forcefully disable the Xlib screensaver disable
support. I think I'll remove the GUI option to bypass it as well, and
just force screensaver disable always on with Windows. I'll improve it
in the future to toggle the effect between emulator pauses.
2018-08-06 17:46:00 +10:00
Tim Allen 5da4532771 Update to v106r55 release.
byuu says:

Everything *should* be working again, but of course that won't
actually be the case. Here's where things stand:

  - bsnes, higan, icarus, and genius compile and run fine on FreeBSD
    with GTK
  - ruby video and audio drivers are untested on Windows, macOS, and
    Linux
  - hiro is untested on macOS
  - bsnes' status bar is not showing up properly with hiro/qt
  - bsnes and higan's about screen is not showing up properly with
    hiro/qt (1x1 window size)
  - bsnes on Windows crashes often when saving states, and I'm not sure
    why ... it happens inside Encode::RLE
  - bsnes on Windows crashes with ruby.input.windows (unsure why)
  - bsnes on Windows fails to show the verified emblem on the status bar
    properly
  - hiro on Windows flickers when changing tabs

To build the Windows bsnes and higan ports, use

    ruby="video.gdi audio.directsound"

Compilation error logs for Linux will help me fix the inevitable list of
typos there. I can fix the typos on other platforms, I just haven't
gotten to it yet.
2018-08-05 19:00:15 +10:00
Tim Allen 5d135b556d Update to v106r53 release.
byuu says:

Okay, so the WIPs-within-WIPs thing wasn't achieving its desired effect,
and it ended up causing me to have to redo some work on hiro since my
last local snapshot was of r52. So, heck it. I'll just do mostly
non-functional WIPs for a bit, and worry about the fallout years later
when I'm trying to find an emulation regression and cursing that the
WIPs aren't compiling.

I ported all of the ruby input drivers to the new syntax, as well as the
OpenAL driver. If you patch the ruby drivers for Linux with this in
mind, bsnes should compile and run there again.

Also, the bsnes program icon has returned, now that the new hiro layout
code is mature enough and I can simply add and remove the icon as a
Canvas instead of having to try and render into a viewport. The icon
shows up instantly with the main window.
2018-08-01 19:07:28 +10:00
Tim Allen 2335bb0df8 Update to 20180731 release.
byuu says:

I've completed moving all the class objects from `unique_pointer<T>` to
just T. The one exception is the Emulator::Interface instance. I can
absolutely make that a global object, but only in bsnes where there's
just the one emulation core.

I also moved all the SettingsWindow and ToolsWindow panels out to their
own global objects, and fixed a very difficult bug with GTK TabFrame
controls.

The configuration settings panel is now the emulator settings panel. And
I added some spacing between bold label sections on both the emulator
and driver settings panels.

I gave fixing ComboButtonItem my best shot, given I can't reproduce the
crash. Probably won't work, though.

Also made a very slight consistency improvement to ruby and renamed
driverName() to driver().

...

An important change ... as a result of moving bsnes to global objects,
this means that the constructors for all windows run before the
presentation window is displayed. Before this change, only the
presentation window was constructed first berore displaying it, followed
by the construction of the rest of the GUI windows.

The upside to this is that as soon as you see the main window, the GUI
is ready to go without a period where it's unresponsive.

The downside to this is it takes about 1.5 seconds to show the main
window, compared to around 0.75 seconds before.

I've no intention of changing that back. So if the startup time becomes
a problem, then we'll just have to work on optimizing hiro, so that it
can construct all the global Window objects quicker. The main way to do
that would be to not do calls to the Layout::setGeometry functions for
every widget added, and instead wait until the window is displayed. But
I don't have an easy way to do that, because you want the widget
geometry values to be sane even before the window is visible to help
size certain things.
2018-07-31 20:56:45 +10:00
Tim Allen 212da0a966 Update to 20180730 release.
byuu says:

These WIPs-within-WIPs are getting more and more broken ... this isn't
going the way I wanted.

But ... this time around, I've revamped the entire ruby API again, to
solve a bunch of tough problems that have always made using ruby really
clunky.

But there are *so many* ruby drivers that it's going to take a long
time to work through them all. This WIP is only going to run bsnes, and
only on FreeBSD, and only with some drivers.

hiro's Application::initialize() now calls hiro::initialize(), which you
define inside of your hiro apps. This lets you call
Application::setName(...) before anything else in hiro runs. This is
essential on Xorg to set program icons, for instance.

With the ruby rewrite and the change to hiro, I can get away from the
need to make everything in bsnes/higan pointers to objects, and can now
just declare them as regular objects.
2018-07-31 12:23:12 +10:00
Tim Allen 5deba5cbc1 Update to 20180729 release.
byuu wrote:

Sigh ...

asio.hpp needs #include <nall/windows/registry.hpp>

[Since the last WIP, byuu also posted the following message. -Ed.]

ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.

I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.

Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.

I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.

I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 23:24:38 +10:00
Tim Allen 716c95f279 Update to 20180728 release.
byuu says:

Sigh, I seem to be spiraling a bit here ... but the work is very
important. Hopefully I can get a solid WIP together soon. But for now...

I've integrated dynamic rate control into ruby::Audio via
setDynamic(bool) for now. It's very demanding, as you would expect. When
it's not in use, I realized the OSS driver's performance was pretty bad
due to calling write() for every sample for every channel. I implemented
a tiny 256-sample buffer and bsnes went from 290fps to 330fps on my
FreeBSD desktop. It may be possible to do the same buffering with DRC,
but for now, I'm not doing so, and adjusting the audio input frequency
on every sample.

I also added ruby::Video::setFlush(bool), which is available only in the
OpenGL drivers, and this causes glFinish() to be called after swapping
display buffers. I really couldn't think of a good name for this, "hard
GPU sync" sounds kind of silly. In my view, flush is what commits queued
events. Eg fflush(). OpenGL of course treats glFlush differently (I
really don't even know what the point of it is even after reading the
manual ...), and then has glFinish ... meh, whatever. It's
setFlush(bool) until I come up with something better. Also as expected,
this one's a big hit to performance.

To implement the DRC, I started putting helper functions into the ruby
video/audio/input core classes. And then the XVideo driver started
crashing. It took hours and hours and hours to track down the problem:
you have to clear XSetWindowAttributes to zero before calling
XCreateWindow. No amount of `--sync`, `gdb break gdk_x_error`, `-Og`,
etc will make Xlib be even remotely helpful in debugging errors like
this.

The GLX, GLX2, and XVideo drivers basically worked by chance before. If
the stack frame had the right memory cleared, it worked. Otherwise it'd
crash with BadValue, and my changing things broke that condition on the
XVideo driver. So this has been fixed in all three now.

Once XVideo was running again, I realized that non-power of two video
sizes were completely broken for the YUV formats. It took a while, but I
managed to fix all of that as well.

At this point, most of ruby is going to be broken outside of FreeBSD, as
I still need to finish updating all the drivers.
2018-07-28 21:25:42 +10:00
Tim Allen 22bd4b9277 Update to v106r52 release.
byuu says:

I stand corrected, I managed to create and even larger diff than ever.
This one weighs in at 309KiB `>__>`

I'll have to create a changelog later, I'm too tired right now to go
through all of that.
2018-07-25 22:24:03 +10:00
Tim Allen 393c2395bb Update to v106r48 release.
byuu says:

The problems with the Windows and Qt4 ports have all been resolved,
although there's a fairly gross hack on a few Qt widgets to not destruct
once Application::quit() is called to avoid a double free crash (I'm
unsure where Qt is destructing the widgets internally.) The Cocoa port
compiles again at least, though it's bound to have endless problems. I
improved the Label painting in the GTK ports, which fixes the background
color on labels inside TabFrame widgets.

I've optimized the Makefile system even further.

I added a "redo state" command to bsnes, which is created whenever you
load the undo state. There are also hotkeys for both now, although I
don't think they're really something you want to map hotkeys to.

I moved the nall::Locale object inside hiro::Application, so that it can
be used to translate the BrowserDialog and MessageDialog window strings.

I improved the Super Game Boy emulation of `MLT_REQ`, fixing Pokemon
Yellow's custom border and probably more stuff.

Lots of other small fixes and improvements. Things are finally stable
once again after the harrowing layout redesign catastrophe.

Errata:

  - ICD::joypID should be set to 3 on reset(). joypWrite() may as well
    take uint1 instead of bool.
  - hiro/Qt: remove pWindow::setMaximumSize() comment; found a
    workaround for it
  - nall/GNUmakefile: don't set object.path if it's already set (allow
    overrides before including the file)
2018-07-16 16:16:26 +10:00
Tim Allen 6090c63958 Update to v106r47 release.
byuu says:

This is probably the largest code-change diff I've done in years.

I spent four days working 10-16 hours a day reworking layouts in hiro
completely.

The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.

Windows, GTK2, and now GTK3 are fully supported.

Windows is getting the initial window geometry wrong by a bit.

GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.

Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.

Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.

The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.

Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.

higan crashes when you load a game, so that's not good. bsnes works
though.

bsnes also has the start of a localization engine now. Still a long way
to go.

The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 13:59:29 +10:00
Tim Allen 372e9ef42b Update to v106r45 release.
byuu says:

Changelog:

  - sfc/ppu-fast: added hires mode 7 option (doubles the sampling rate
    of mode 7 pixels to reduce aliasing)
  - sfc/ppu-fast: fixed mode 7 horizontal screen flip [hex_usr]
  - bsnes: added capture screenshot function and path selection
      - for now, it saves as BMP. I need a deflate implementation that
        won't add an external dependency for PNG
      - the output resolution is from the emulator: (256 or 512)x(240 or
        480 minus overscan cropping if enabled)
      - it captures the NEXT output frame, not the current one ... but
        it may be wise to change this behavior
      - it'd be a problem if the core were to exit and an image was
        captured halfway through frame rendering
  - bsnes: recovery state renamed to undo state
  - bsnes: added manifest viewer tool
  - bsnes: mention if game has been verified or not on the status bar
    message at load time
  - bsnes, nall: fixed a few missing function return values
    [SuperMikeMan]
  - bsnes: guard more strongly against failure to load games to avoid
    crashes
  - hiro, ruby: various fixes for macOS [Sintendo]
  - hiro/Windows: paint on `WM_ERASEBKGND` to prevent status bar
    flickering at startup
  - icarus: SPC7110 heuristics fixes [hex_usr]

Errata:

  - sfc/ppu-fast: remove debug hires mode7 force disable comment from
    PPU::power()

[The `WM_ERASEBKGND` fix was already present in the 106r44 public
beta -Ed.]
2018-07-02 11:57:04 +10:00
Tim Allen 91bb781b73 Update to v106r39 release.
byuu says:

Changelog:

  - ruby/video: implement onUpdate() callback to signal when redraws are
    necessary
  - ruby/video/GLX,GLX2,XVideo,XShm: implement onUpdate() support
  - bsnes: implement Video::onUpdate() support to redraw Viewport icon
    as needed
  - bsnes: save RAM before ruby driver changes
  - sfc/sa1: clip signed multiplication to 32-bit [Jonas Quinn]
  - sfc/sa1: handle negative dividends in division [Jonas Quinn]
  - hiro/gtk3: a few improvements
  - bsnes: added empty stub video and audio settings panels
  - bsnes: restructured advanced settings panel
  - bsnes: experiment: input/hotkeys name column bolded and colored for
    increased visual distinction
  - bsnes: added save button to state manager
2018-06-10 18:07:19 +10:00
Tim Allen 15b67922b3 Update to v106r38 release.
byuu says:

Changelog:

  - hiro: added Qt5 support
  - hiro: added GTK3 support (currently runs very poorly)
  - bsnes: number of recent games and quick state slots can be changed
    programmatically now
      - I may expose this as a configuration file setting, but probably
        not within the GUI
  - nall: use -Wno-everything when compiling with Clang
      - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 18:06:02 +10:00
Tim Allen 77ac5f9e88 Update to v106r35 release.
byuu says:

Changelog:

  - sfc/ppu-fast: fixed overscan crash
  - sfc/ppu-fast: fixed direct color mode
  - sfc: reconnected MSU1 support
      - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
      - bsnes: game.msu, game-#.pcm
  - bsnes: added cheat code editor
  - bsnes: added cheat code database support
  - sfc/ppu-fast: clear overscan lines when overscan disabled
  - sfc: output 223/239 lines instead of 224/240 lines
  - bsnes: fix aspect correction calculation
  - bsnes: crop line 224 when overscan masking is enabled
  - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
    devices
  - bsnes: tools menu is hidden until a game is loaded
  - ruby/input/keyboard/quartz: fixed compilation error

So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.

We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.

I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:

    cheat
      description: foo
      code: 7e2000=20+7e2001=30?40
      enabled

    cheat
      description: bar
      code: 7e4000=80

Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.

I chose to use .cht for the extension when using game files (eg
gamename.cht)
2018-06-03 23:14:42 +10:00
Tim Allen 685cec6583 Update to v106r30 release.
byuu says:

Changelog:

  - nall/GNUmakefile: fixed findstring parameter arguments [Screwtape]
  - nall/Windows: always include -mthreads -lpthread for all
    applications
  - nall/memory: code restructuring

I really wanted to work on the new PPU today, but I thought I'd spend a
few minutes making some minor improvements to nall::memory, that was
five and a half hours ago. Now I have a 67KiB diff of changes. Sigh.
2018-05-28 11:16:27 +10:00
Tim Allen 2b8df2e70e Update to v106r27 release.
byuu says:

Changelog:

  - nall: merged Path::config() and Path::local() to Path::userData()
      - ~/.local/share or %appdata or ~/Library/ApplicationSupport
  - higan, bsnes: render main window icon onto viewport instead of
    canvas
      - should hopefully fix a brief flickering glitch that appears on
        Windows
  - icarus: improved Super Famicom heuristics for Starfox / Starwing RAM
  - ruby/Direct3D: handle viewport size changes in lock() instead of
    output()
      - fixes icon disappearing when resizing main window
  - hiro/Windows: remove WS_DISABLED from StatusBar to fix window
    resize grip
      - this is experimental: I initially used WS_DISABLED to work
        around a focus bug
      - yet trying things now, said bug seems(?) to have gone away at
        some point ...
  - bsnes: added advanced settings panel with real-time driver change
    support

I'd like feedback on the real-time driver change, for possible
consideration into adding this to higan as well.

Some drivers just crash, it's a fact of life. The ASIO driver in
particular likes to crash inside the driver itself, without any error
messages ever returned to try and catch.

When you try to change a driver with a game loaded, it gives you a scary
warning, asking if you want to proceed.

When you change a driver, it sets a crash flag, and if the driver
crashes while initializing, then restarting bsnes will disable the
errant driver. If it fails in a recoverable way, then it sets the driver
to “None” and warns you that the driver cannot be used.

What I'm thinking of further adding is to call emulator→save() to
write out the save RAM contents beforehand (although the periodic
auto-saving RAM will handle this anyway when it's enabled), and possibly
it might be wise to capture an emulator save state, although those can't
be taken without advancing the emulator to the next frame, so that might
not be a good idea.

I'm also thinking we should show some kind of message somewhere when a
driver is set to “None”. The status bar can be hidden, so perhaps on the
title bar? Or maybe just a warning on startup that a driver is set to
“None”.
2018-05-25 18:02:38 +10:00
Tim Allen 5961ea9c03 Update to v106r26 release.
byuu says:

Changelog:

  - nall: added -static-libgcc -static-libstdc++ to Windows/GCC link
    flags
  - bsnes, higan: added program icons to main window when game isn't
    loaded
  - bsnes: improved recent games menu sorting
  - bsnes: fixed multi-game recent game loading on Windows
  - bsnes: completed path override support
  - bsnes, higan: added screensaver suppression on Windows
  - icarus: add 32K volatile RAM to SuperFX boards that report no RAM
    (fixes Starfox)
  - bsnes, higan: added automatic dependency generation [Talarubi]
  - hiro/GTK: appending actions to menus restores enabled() state
  - higan: use board node inside manifest.bml if it exists
  - bsnes: added blur emulation and color emulation options to view menu
  - ruby: upgraded input.sdl to SDL 2.0 (though it makes no functional
    difference sadly)
  - ruby: removed video.sdl (due to deprecating SDL 1.2)
  - nall, ruby: improvements to HID class (generic vendor and product
    IDs)

Errata:

  - bsnes, higan: on Windows, Application::Windows::onScreenSaver needs
    `[&]` lambda capture, not `[]`
      - find it in presentation/presentation.cpp
2018-05-24 12:14:17 +10:00
Tim Allen 2f81b5a3e7 Update to v106r2 release.
byuu says:

Changelog:

  - Super Famicom: added support for loading manifests without embedded
    mapping information¹
  - genius: initial commit
  - various Makefile cleanups

¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.

For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.

The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.

Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.

Give it time, we'll refine this into something nicer.
2018-02-01 19:20:37 +11:00
Tim Allen f8e71b50d0 Update to v105 release.
byuu says:

This release provides several major improvements to Mega Drive emulation
which enhances compatibility a good deal. It also includes important
Super Famicom mosaic emulation improvements, plus a much-needed SuperFX
save state issue fix.

Changelog (since v104):

  - higan: many improvements to Emulator::Interface to support
    forks/frontends
  - higan: refreshed program icon
  - icarus: new program icon
  - Game Boy Advance: slight emulation speedup over v104
  - Game Boy Advance: synchronize APU FIFO updates better
  - Mega Drive: added automatic region detection [hex_usr]
  - Mega Drive: support 8-bit SRAM
  - Game Boy Advance: fixed bug when changing to THUMB mode via MSR
    [MerryMage]
  - Master System: fix bug in backdrop color and background 0 priority
    [hex_usr]
  - Mega Drive: backgrounds always update output priority bit [Cydrak]
  - Mega Drive: emulated interlaced video output
  - Mega Drive: emulated shadow/highlight mode [Cydrak]
  - Super Famicom: auto joypad polling clears the shift register when
    starting
  - Super Famicom: added new low-entropy RAM initialization mode to more
    closely match hardware
  - Game Boy Advance: rumble will now time out after being left on for
    500ms
  - ruby: improved rumble support in udev input driver [ma_rysia]
  - M68K: `move.b (a7)[+/-]` adjust a7 by two
  - M68K: illegal/lineA/lineF opcodes do not modify the stack register
  - Mega Drive: emulate VIP status bit
  - uPD7725: improved emulation of OV1/S1 flags [byuu, AWJ, Lord
    Nightmare]
  - uPD7725: improved handling of DP, RP updates [Jonas Quinn]
  - Super Famicom: improved emulation of mosaic effects in hires,
    interlace, and offset-per-tile modes [byuu, Cydrak]
  - ruby: improved Direct3D exclusive mode monitor selection [Cydrak]
  - Super Famicom: fixed save state bug affecting SuperFX games
    [Cydrak]
  - Mega Drive: added workaround for Clang compiler bug; allowing this
    core to work on macOS [Cydrak, Sintendo]
  - higan: hotkeys now also trigger when the main window lacks focus yet
    higan is set to allow input on focus loss
  - higan: fixed an edge case where `int16_t` ↔ `double` audio
    conversion could possibly result in overflows
  - higan: fixed a crash on macOS when choosing quit from the
    application menu [ncbncb]

Changelog (since the previous WIP):

  - higan: restored `make console=true`
  - tomoko: if you allow input when main window focus is lost, hotkeys
    can now be triggered without focus as well
  - hiro/cocoa: fix crash on exit from menu [ncbncb]
  - ruby: smarter `double` → `int16_t` conversion to prevent
    underflow/overflow
2017-10-07 19:49:07 +11:00
Tim Allen 6524a7181d Update to v104r15 release.
byuu says:

Changelog:

  - processor/huc6280,mos6502,wdc65816: replaced abbreviated opcode
    names with descriptive names
  - nall: replaced `PLATFORM_MACOSX` define with `PLATFORM_MACOS`
  - icarus: added `Icarus::missing() -> string_vector` to list missing
    appended firmware files by name
  - ruby, hiro: fix macosx→macos references

The processor instruction renaming was really about consistency with the
other processor cores. I may still need to do this for one or two more
processors.

The icarus change should allow a future release of the icarus
application to import games with external SNES coprocessor firmware once
again. It will also allow this to be possible when used in library mode.
2017-09-29 20:36:35 +10:00
Tim Allen fbc58c70ae Update to v104r14 release.
byuu says:

Changelog:

  - Emulator::Interface::videoResolution() -\> VideoResolution renamed
    to videoInformation() -\> VideoInformation
  - added double VideoInformation::refreshRate
  - higan: added `binary := (application|library)` — set this to
    `library` to produce a dynamic link library
  - higan: removed `-march=native` for macOS application builds; and for
    all library builds
  - higan: removed `console` build flag; uncomment  `link += -mwindows`
    instead
  - nall/GNUmakefile: `macosx` platform renamed `macos`
      - still need to do this for nall/intrinsics.hpp
  - Game Gear: return region=NTSC as the only option, so that the system
    frequency is always set correctly
  - hiro/cocoa: fixed typo [Sintendo]
  - hiro/Windows: removed GetDpiForMonitor, as it's Windows 8+ only; DPI
    is no longer per-monitor aware
  - icarus: core Icarus class now has virtual functions for
    directory::create, <file::exists>, <file::copy>, <file::write>
  - icarus: Sufami Turbo can import save RAM files now
  - icarus: setting `ICARUS_LIBRARY` define will compile icarus without
    main(), GUI components
  - ruby/video/Direct3D: choose the current monitor instead of top-left
    monitor for fullscreen exclusive [Cydrak]
  - ruby/video/Direct3D: do not set `WS_EX_TOPMOST` on fullscreen
    exclusive window [Cydrak]
      - this isn't necessary for exclusive mode, and it just makes
        getting out of the application more difficult
2017-09-24 11:01:48 +10:00
Tim Allen afa8ea61c5 Update to v104r06 release.
byuu says:

Changelog:

  - gba,ws: removed Thread::step() override¹
  - processor/m68k: move.b (a7)+ and move.b (a7)- adjust a7 by two, not
    by one²
  - tomoko: created new initialize(Video,Audio,Input)Driver() functions³
  - ruby/audio: split Audio::information into
    Audio::available(Devices,Frequencies,Latencies,Channels)³
  - ws: added Model::(WonderSwan,WonderSwanColor,SwanCrystal)()
    functions for consistency with other cores

¹: this should hopefully fix GBA Pokemon Pinball. Thanks to
SuperMikeMan for pointing out the underlying cause.

²: this fixes A Ressaha de Ikou, Mega Bomberman, and probably more
games.

³: this is the big change: so there was a problem with WASAPI where
you might change your device under the audio settings panel. And your
new device may not support the frequency that your old device used. This
would end up not updating the frequency, and the pitch would be
distorted.

The old Audio::information() couldn't tell you what frequencies,
latencies, or channels were available for all devices simultaneously, so
I had to split them up. The new initializeAudioDriver() function
validates you have a correct driver, or it defaults to none. Then it
validates a correct device name, or it defaults to the first entry in
the list. Then it validates a correct frequency, or defaults to the
first in the list. Then finally it validates a correct latency, or
defaults to the first in the list.

In this way ... we have a clear path now with no API changes required to
select default devices, frequencies, latencies, channel counts: they
need to be the first items in their respective lists.

So, what we need to do now is go through and for every audio driver that
enumerates devices, we need to make sure the default device gets added
to the top of the list. I'm ... not really sure how to do this with most
drivers, so this is definitely going to take some time.

Also, when you change a device, initializeAudioDriver() is called again,
so if it's a bad device, it will disable the audio driver instead of
continuing to send samples at it and hoping that the driver blocked
those API calls when it failed to initialize properly.

Now then ... since it was a decently-sized API change, it's possible
I've broken compilation of the Linux drivers, so please report any
compilation errors so that I can fix them.
2017-08-26 11:15:49 +10:00
Tim Allen b38a657192 Update to v104r05 release.
byuu says:

Changelog:

  - emulator/random: new array function with more realistic RAM
    initializations
  - emulator/random: both low and high entropy register initializations
    now use PCG
  - gba/player: rumble will time out and disable after being left on for
    500ms; fixes Pokemon Pinball issue
  - ruby/input/udev: fixed rumble effects [ma\_rysia]
  - sfc/system: default to low-entropy randomization of memory

The low-entropy memory randomization is modeled after one of my SHVC
2/1/3 systems. It generates striped patterns in memory, using random
inputs (biased to 0x00/0xff), and has a random chance of corrupting 1-2
bits of random values in the pool of memory (to prevent easy emulator
detection and to match observed results on hardware.)

The reasoning for using PCG on register initializations, is that I don't
believe they're going to have repeating patterns like RAM does anyway.
And register initializations are way more vital.

I want to have the new low-entropy RAM mode tested, so at least for the
next few WIPs, I've set the SNES randomization over to low-entropy.
We'll have to have a long discussion and decide whether we want official
releases to use high-entropy or low-entropy.

Also, I figured out the cause of the Prince of Persia distortion ... I
had the volume under the audio settings tab set to 200%. I didn't
realize there were SNES games that clipped so easily, given how
incredibly weak SNES audio is compared to every other sound source on my
PC. So with no entropy or low-entropy, indeed the game now sounds just
fine.

I can't actually test the udev fixes, so I guess we'll see how that goes
for Screwtape and ma\_rysia.
2017-08-25 00:24:34 +10:00
Tim Allen d060904b8d Revert an accidental ruby change.
I made a change to ruby/input/joypad/udev.cpp while diagnosing a problem
with higan's rumble behaviour on Linux, and accidentally committed it
in 15b3dc8b0b as part of a documentation
change.
2017-08-24 22:09:49 +10:00
Tim Allen 15b3dc8b0b More cleanups and revision. 2017-08-24 18:34:37 +10:00
Tim Allen 0b6f1df987 Update to v103r27 release.
byuu says:

Changelog:

  - hiro/windows: set dpiAware=false, fixes icarus window sizes relative
    to higan window sizes
  - higan, icarus, hiro, ruby: add support for high resolution displays
    on macOS [ncbncb]
  - processor/lr35902-legacy: removed
  - processor/arm7tdmi: new processor core started; intended to one day
    be a replacement for processor/arm

It will probably take several WIPs to get the new ARM core up and
running. It's the last processor rewrite. After this, all processor
cores will be up to date with all my current programming conventions.
2017-08-06 23:36:26 +10:00
Tim Allen c2975e6898 Update to v103r25 release.
byuu says:

Changelog:

  - gb/cpu: force STAT mode to 0 when LCD is disabled (fixes Pokemon
    Pinball, etc)
  - gb/ppu: when LCD is disabled, require at least one-frame wait to
    re-enable, display white during this time
      - todo: should step by a scanline at a time: worst-case is an
        extra 99% of a frame to enable again
  - gba/ppu: cache tilemap lookups and attribute parsing
      - it's more accurate because the GBA wouldn't read this for every
        pixel
      - but unfortunately, this didn't provide any speedup at all ...
        sigh
  - ruby/audio/alsa: fixed const issue with free()
  - ruby/video/cgl: removed `glDisable(GL_ALPHA_TEST)` [deprecated]
  - ruby/video/cgl: removed `glEnable(GL_TEXTURE_2D)` [unnecessary as
    we use shaders]
  - processor/lr35902: started rewrite¹

¹: so, the Game Boy and Game Boy Color cores will be completely
broken for at least the next two or three WIPs.

The old LR35902 was complete garbage, written in early 2011. So I'm
rewriting it to provide a massive cleanup and consistency with other
processor cores, especially the Z80 core.

I've got about 85% of the main instructions implemented, and then I have
to do the CB instructions. The CB instructions are easier because
they're mostly just a small number of opcodes in many small variations,
but it'll still be tedious.
2017-08-04 23:05:12 +10:00
Tim Allen 571760c747 Update to v103r24 release.
byuu says:

Changelog:

  - gb/mbc6: mapper is now functional, but Net de Get has some text
    corruption¹
  - gb/mbc7: mapper is now functional²
  - gb/cpu: HDMA syncs other components after each byte transfer now
  - gb/ppu: LY,LX forced to zero when LCDC.d7 is lowered (eg disabled),
    not when it's raised (eg enabled)
  - gb/ppu: the LCD does not run at all when LCDC.d7 is clear³
      - fixes graphical corruption between scene transitions in Legend
        of Zelda - Oracle of Ages
      - thanks to Cydrak, Shonumi, gekkio for their input on the cause
        of this issue
  - md/controller: renamed "Gamepad" to "Control Pad" per official
    terminology
  - md/controller: added "Fighting Pad" (6-button controller) emulation
    [hex\_usr]
  - processor/m68k: fixed TAS to set data.d7 when
    EA.mode==DataRegisterDirect; fixes Asterix
  - hiro/windows: removed carriage returns from mouse.cpp and
    desktop.cpp
  - ruby/audio/alsa: added device driver selection [SuperMikeMan]
  - ruby/audio/ao: set format.matrix=nullptr to prevent a crash on some
    systems [SuperMikeMan]
  - ruby/video/cgl: rename term() to terminate() to fix a crash on macOS
    [Sintendo]

¹: The observation that this mapper split $4000-7fff into two banks
came from MAME's implementation. But their implementation was quite
broken and incomplete, so I didn't actually use any of it. The
observation that this mapper split $a000-bfff into two banks came from
Tauwasser, and I did directly use that information, plus the knowledge
that $0400/$0800 are the RAM bank select registers.

The text corruption is due to a race condition with timing. The game is
transferring font letters via HDMA, but the game code ends up setting
the bank# with the font a bit too late after the HDMA has already
occurred. I'm not sure how to fix this ... as a whole, I assumed my Game
Boy timing was pretty good, but apparently it's not that good.

²: The entire design of this mapper comes from endrift's notes.
endrift gets full credit for higan being able to emulate this mapper.
Note that the accelerometer implementation is still not tested, and
probably won't work right until I tweak the sensitivity a lot.

³: So the fun part of this is ... it breaks the strict 60fps rate of
the Game Boy. This was always inevitable: certain timing conditions can
stretch frames, too. But this is pretty much an absolute deal breaker
for something like Vsync timing. This pretty much requires adaptive sync
to run well without audio stuttering during the transition.

There's currently one very important detail missing: when the LCD is
turned off, presumably the image on the screen fades to white. I do not
know how long this process takes, or how to really go about emulating
it. Right now as an incomplete patch, I'm simply leaving the last
displayed image on the screen until the LCD is turned on again. But I
will have to output white, as well as add code to break out of the
emulation loop periodically when the LCD is left off eg indefinitely, or
bad things would happen. I'll work something out and then implement.

Another detail is I'm not sure how long it takes for the LCD to start
rendering again once enabled. Right now, it's immediate. I've heard it's
as long as 1/60th of a second, but that really seems incredibly
excessive? I'd like to know at least a reasonably well-supported
estimate before I implement that.
2017-08-04 23:05:06 +10:00
Tim Allen 7022d1aa51 Update to v103r23 release.
byuu says:

Changelog:

  - gb: added accelerometer X-axis, Y-Axis inputs¹
  - gb: added rumble input¹
  - gb/mbc5: added rumble support²
  - gb/mbc6: added skeleton driver, but it doesn't boot Net de Get
  - gb/mbc7: added mostly complete driver (only missing EEPROM), but it
    doesn't boot Kirby Tilt 'n' Tumble
  - gb/tama: added leap year assignment
  - tomoko: fixed macOS compilation [MerryMage]
  - hiro/cocoa: fix table cell redrawing on updates and automatic column
    resizing [ncbncb]
  - hiro/cocoa: fix some weird issue with clicking table view checkboxes
    on Retina displays [ncbncb]
  - icarus: enhance Game Boy heuristics³
  - nall: fix three missing return statements [Jonas Quinn]
  - ruby: hopefully fixed all compilation errors reported by Screwtape
    et al⁴

¹: because there's no concept of a controller for cartridge inputs,
I'm attaching to the base platform for now. An idea I had was to make
separate ports for each cartridge type ... but this would duplicate the
rumble input between MBC5 and MBC7. And would also be less discoverable.
But it would be more clean in that users wouldn't think the Game Boy
hardware had this functionality. I'll think about it.

²: it probably won't work yet. Rumble isn't documented anywhere, but
I dug through an emulator named GEST and discovered that it seems to use
bit 3 of the RAM bank select to be rumble. I don't know if it sets the
bit for rumbling, then clears when finished, or if it sets it and then
after a few milliseconds it stops rumbling. I couldn't test on my
FreeBSD box because SDL 1.2 doesn't support rumble, udev doesn't exist
on FreeBSD, and nobody has ever posted any working code for how to use
evdev (or whatever it's called) on FreeBSD.

³: I'm still thinking about specifying the MBC7 RAM as EEPROM, since
it's not really static RAM.

⁴: if possible, please test all drivers if you can. I want to ensure
they're all working. Especially let me know if the following work:
macOS: input.carbon Linux: audio.pulseaudiosimple, audio.ao (libao)

If I can confirm these are working, I'm going to then remove them from
being included with stock higan builds.

I'm also considering dropping SDL video on Linux/BSD. XShm is much
faster and supports blurring. I may also drop SDL input on Linux, since
udev works better. That will free a dependency on SDL 1.2 for building
higan. FreeBSD is still going to need it for joypad support, however.
2017-07-30 23:00:31 +10:00
Tim Allen e1223366a7 Update to v103r22 release.
byuu says:

Changelog:

  - ruby: ported all remaining drivers to new API¹
  - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan]
  - gb: emulated most of the TAMA RTC; but RTC state is still volatile²

¹: the new ports are:

  - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao}
  - input/{udev, quartz, carbon}

It's pretty much guaranteed many of them will have compilation errors.
Please paste the error logs and I'll try to fix them up. It may take a
WIP or two to get there.

It's also possible things broke from the updates. If so, I could use
help comparing the old file to the new file, looking for mistakes, since
I can't test on these platforms apart from audio/directsound.

Please report working drivers in this list, so we can mark them off the
list. I'll need both macOS and Linux testers.

audio/directsound.cpp:112:

    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false;

²: once I get this working, I'll add load/save support for the RTC
values. For now, the RTC data will be lost when you close the emulator.

Right now, you can set the date/time in real-time mode, and when you
start the game, the time will be correct, and the time will tick
forward. Note that it runs off emulated time instead of actual real
time, so if you fast-forward to 300%, one minute will be 20 seconds.

The really big limitation right now is that when you exit the game, and
restart it, and resume a new game, the hour spot gets corrupted, and
this seems to instantly kill your pet. Fun. This is crazy because the
commands the game sends to the TAMA interface are identical between
starting a new game and getting in-game versus loading a game.

It's likely going to require disassembling the game's code and seeing
what in the hell it's doing, but I am extremely bad at LR35092 assembly.
Hopefully endrift can help here :|
2017-07-28 21:42:24 +10:00
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
2017-07-24 15:23:40 +10:00
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"
2017-07-23 19:18:16 +10:00
Tim Allen 284e4c043e Update to v103r18 release.
byuu says:

Changelog:

  - tomoko: improved handling of changing audio devices on the audio
    settings panel
  - ruby/audio/wasapi: added device enumeration and selection support¹
  - ruby/audio/wasapi: release property store handle from audio device
  - ruby/audio/wasapi: fix exclusive mode buffer filling
  - ruby/video/glx2: ported to new API -- tested and confirmed working
    great²
  - ruby/video/sdl: fixed initialization -- tested and confirmed working
    on FreeBSD now³
  - ruby/video/xv: ported to new API -- tested and mostly working great,
    sans fullscreen mode⁴

Errata:

  - accidentally changed "Driver Settings" label to "Driver" on the
    audio settings tab because I deleted the line and forgot the
    "Settings" part
  - need to use "return initialize();" from setDevice() in the WASAPI
    driver, instead of "return true;", so device selection is currently
    not functioning in this WIP for said driver

¹: for now, this will likely end up selecting the first available
endpoint device, which is probably wrong. I need to come up with a
system to expose good 'default values' when selecting new audio drivers,
or changing audio device settings.

²: glx2 is a fallback driver for system with only OpenGL 2.0 and no
OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards.

³: although I really should track down why InputManager::poll() is
crashing the emulator when Video::ready() returns false ...

⁴: really bizarrely, when entering fullscreen mode, it looks like the
image was a triangle strip, and the bottom right triange is missing, and
the top left triangle skews the entire image into it. I'm suspecting
this is a Radeon driver bug when trying to create a 2560x1600 X-Video
surface. The glitch persists when exiting fullscreen, too.

If anyone can test the X-Video driver on their Linux/BSD system, it'd be
appreciated. If it's just my video card, I'll ignore it. If not,
hopefully someone can find the cause of the issue :|
2017-07-20 21:52:47 +10:00
Tim Allen 0b4e7fb5a5 Update to v103r17 release.
byuu says:

Changelog:

  - tomoko: re-hid the video sync option¹
  - tomoko: removed " Settings" duplication on all the individual
    settings tab options
  - ruby/audio/wasapi: finished port to new syntax; adapted to an
    event-driven model; support 32-bit integral audio²
  - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³

¹: still contemplating a synchronize submenu of {none, video, audio},
but ... the fact that video can't work on PAL, WonderSwan games is a
real limitation for it

²: this driver actually received a ton of work. There's also a new
ring-buffer queue, and I added special handling for when exclusive mode
fails because the latency requested is lower than the hardware can
support. It'll pick the closest latency to the minimum that is possible
in this case.

On my Audigy Rx, the results for non-exclusive mode are the same. For
exclusive mode, the framerate drops from 60fps to ~50fps for smaller
buffers, and ~55fps for larger buffers (no matter how big, it never hits
60fps.) This is a lot better than before where it was hitting ~15fps,
but unfortunately it's the best I can do.

The event system used by WASAPI is really stupid. It just uses SetEvent
at some arbitrary time, and you have to query to see how many samples
it's waiting on. This makes it unknowable how many samples we should
buffer before calling `WaitForSingleObject(INFINITE)`, and it's also
unclear how we should handle cases where there's more samples available
than our queue has: either we can fill it with zeroes, or we can write
less samples. The former should prevent audio looping effects when
running too slowly, whereas the latter could potentially be too
ambitious when the audio could've recovered from a minor stall.

It's shocking to me how there's as many ways to send audio to a sound
card as there are sound card APIs, when all that's needed is a simple
double buffer and a callback event from another thread to do it right.
It's also terrifying how unbelievably shitty nearly all sound card
drivers apparently are.

Also, I don't know if cards can output an actual 24-bit mode with three
byte audio samples, or if they always just take 32-bit samples and
ignore the lower 8-bits. Whatever, it's all nonsense for the final
output to be >16-bits anyway (hi, `double[]` input from ruby.)

³: unfortunately, this driver always crashes on FreeBSD (even before
the rewrite), so I'll need someone on Linux to test it and make sure it
actually works. I'll also need testing for a lot of the other drivers as
well, once they're ported over (I don't have X-video, PulseAudio, ALSA,
or udev.)

Note that I forgot to set `_ready=true` at the end of `initialize()`,
and `_ready=false` in `terminate()`, but it shouldn't actually matter
beyond showing you a false warning message on startup about it failing
to initialize.
2017-07-19 23:14:00 +10:00
Tim Allen f87c6b7ecb Update to v103r16 release.
byuu says:

Changelog:

  - emulator/audio: added the ability to change the output frequency at
    run-time without emulator reset
  - tomoko: display video synchronize option again¹
  - tomoko: Settings→Configuration expanded to Settings→{Video,
    Audio, Input, Hotkey, Advanced} Settings²
  - tomoko: fix default population of audio settings tab
  - ruby: Audio::frequency is a double now (to match both
    Emulator::Audio and ASIO)³
  - tomoko: changing the audio device will repopulate the frequency and
    latency lists
  - tomoko: changing the audio frequency can now be done in real-time
  - ruby/audio/asio: added missing device() information, so devices can
    be changed now
  - ruby/audio/openal: ported to new API; added device selection support
  - ruby/audio/wasapi: ported to new API, but did not test yet (it's
    assuredly still broken)⁴

¹: I'm uneasy about this ... but, I guess if people want to disable
audio and just have smooth scrolling video ... so be it. With
Screwtape's documentation, hopefully that'll help people understand that
video synchronization always breaks audio synchronization. I may change
this to a child menu that lets you pick between {no synchronization,
video synchronization, audio synchronization} as a radio selection.

²: given how much more useful the video and audio tabs are now, I
felt that four extra menu items were worth saving a click and going
right to the tab you want. This also matches the behavior of the Tools
menu displaying all tool options and taking you directly to each tab.
This is kind of a hard change to get used to ... but I think it's for
the better.

³: kind of stupid because I've never seen a hardware sound card where
floor(frequency) != frequency, but whatever. Yay consistency.

⁴: I'm going to move it to be event-driven, and try to support 24-bit
sample formats if possible. Who knows which cards that'll fix and which
cards that'll break. I may end up making multiple WASAPI drivers so
people can find one that actually works for them. We'll see.
2017-07-17 20:32:36 +10:00
Tim Allen 4129630d97 Update to v103r15 release.
byuu says:

Changelog:

  - ruby: rewrote the API interfaces for Video, Audio, Input
  - ruby/audio: can now select the number of output channels (not useful
    to higan, sorry)
  - ruby/asio: various improvements
  - tomoko: audio settings panel can now select separate audio devices
    (for ASIO, OSS so far)
  - tomoko: audio settings panel frequency and latency lists are
    dynamically populated now

Note: due to the ruby API rewrite, most drivers will not compile. Right
now, the following work:

  - video: Direct3D, XShm
  - audio: ASIO, OSS
  - input: Windows, SDL, Xlib

It takes a really long time to rewrite these (six hours to do the
above), so it's going to be a while before we're back at 100%
functionality again.

Errata:

  - ASIO needs device(), setDevice()
  - need to call setDevice() at program startup to populate
    frequency/latency settings properly
  - changing the device and/or frequency needs to update the emulator
    resampler rates

The really hard part is going to be the last one: the only way to change
the emulator frequency is to flush all the audio streams and then
recompute all the coefficients for the resamplers. If this is called
during emulation, all audio streams will be erased and thus no sound
will be output. I'll most likely be forced to simply ignore
device/frequency changes until the user loads another game. It is at
least possible to toggle the latency dynamically.
2017-07-17 15:11:18 +10:00
Tim Allen 17697317d4 Update to v103r14 release.
byuu says:

Changelog:

  - tomoko: by popular choice, default to adaptive mode on new installs
  - hiro/windows: fix bug that was preventing the escape key from
    closing some dialog windows
  - nall/registry: use "\\\\" as separator instead of "/" ... because
    some registry keys contain "/" in them >_>
  - ruby: add ASIO driver stub (so far it can only initialize and grab
    the driver name/version information)
2017-07-15 22:00:20 +10:00
Tim Allen 434e303ffb Update to v103r12 release.
byuu says:

Changelog:

  - ruby/video: cleaned up Direct3D9 driver and fixed catastrophic
    memory leak
  - ruby/video: added fullscreen exclusive mode support to the Direct3D9
    driver¹
  - ruby/video: minor cosmetic code cleanups to various drivers
  - tomoko: added support to always allow input when in fullscreen
    exclusive mode
  - tomoko: fixed window to not remove resizability flag when exiting
    fullscreen mode

¹: I am assuming that exclusive mode will try to capture the primary
monitor. I don't know what will happen in multi-monitor setups, however,
as I don't use such a setup here.

Also, I am using `D3DPRESENT_DISCARD` instead of `D3DPRESENT_FLIP`. I'm
not sure if this will prove better or worse, but I've heard it will
waste less memory, and having a BackBufferCount of 1 should still result
in page flipping anyway. The difference is supposedly just that you
can't rely on the back buffer being a valid copy of the previous frame
like you can with FLIP.

Lastly, if you want Vsync, you can edit the configuration file to enable
that, and then turn off audio sync.

Errata: "pause emulation when focus is lost" is not working with
exclusive mode. I need to add a check to never auto-pause when in
exclusive mode. Thanks to bun for catching that one.
2017-07-09 12:23:17 +10:00
Tim Allen 2461293ff0 Update to v102r19 release.
byuu says:

Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)

Changelog:

  - GBA: rewrote PPU from a scanline-based renderer to a pixel-based
    renderer
  - ruby: fixed video/gdi bugs

Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.

Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.

The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.

Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.

However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.

What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.

I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 13:16:44 +10:00
Tim Allen 1ca4609079 Update to v102r18 release.
byuu says:

This WIP fixes all the critical pending issues I had open. I'm sure
there's many more that simply didn't make their way into said list. So
by all means, please report important issues you're aware of so they can
get fixed.

Changelog:

  - ruby: add variable texture support to GDI video driver [bug
    reported by Cydrak]
  - ruby: minor cleanups to XShm video driver
  - ruby: fix handling of up+down, left+right hat cases for XInput
    driver [bug reported by Cydrak]
  - nall: fixed vector class so that compilation with GCC 7.1 should
    succeed [SuperMikeMan]
  - sfc: initialize most DSP registers to random values to fix Magical
    Drop [Jonas Quinn]
  - sfc: lower PPU brightness when luma=0 from 50% scale to 25% scale;
    helps scenes like Final Fantasy III's intro
2017-05-30 17:48:41 +10:00
Tim Allen 2fbbccf985 Update to v101r16 release.
byuu says:

Changelog:

  - Z80: implemented 113 new instructions (all the easy
    LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones)
  - Z80: used alternative to castable<To, With> type (manual cast inside
    instruction() register macros)
  - Z80: debugger: used register macros to reduce typing and increase
    readability
  - Z80: debugger: smarter way of handling multiple DD/FD prefixes
    (using gotos, yay!)
  - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan)

I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so
that's probably wrong for now. HALT is also mostly a dummy function for
now. But I typically implement those inside instruction(), so it
probably won't need to be changed? We'll see.
2016-09-06 10:09:33 +10:00
Tim Allen ffd150735b Update to v101r07 release.
byuu says:

Added VDP sprite rendering. Can't get any games far enough in to see if
it actually works. So in other words, it doesn't work at all and is 100%
completely broken.

Also added 68K exceptions and interrupts. So far only the VDP interrupt
is present. It definitely seems to be firing in commercial games, so
that's promising. But the implementation is almost certainly completely
wrong. There is fuck all of nothing for documentation on how interrupts
actually work. I had to find out the interrupt vector numbers from
reading the comments from the Sonic the Hedgehog disassembly. I have
literally no fucking clue what I0-I2 (3-bit integer priority value in
the status register) is supposed to do. I know that Vblank=6, Hblank=4,
Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm
supposed to block interrupts when I is >, >=, <, <= to the interrupt
level. I don't know what level CPU exceptions are supposed to be.

Also implemented VDP regular DMA. No idea if it works correctly since
none of the commercial games run far enough to use it. So again, it's
horribly broken for usre.

Also improved VDP fill mode. But I don't understand how it takes
byte-lengths when the bus is 16-bit. The transfer times indicate it's
actually transferring at the same speed as the 68K->VDP copy, strongly
suggesting it's actually doing 16-bit transfers at a time. In which case,
what happens when you set an odd transfer length?

Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's
all kinds of weird shit going on when you target VSRAM, CRAM with VDP
fill/copy modes, but whatever. Get to that later.

Also implemented a very lazy preliminary wait mechanism to to stall out
a processor while another processor exerts control over the bus. This
one's going to be a major work in progress. For one, it totally breaks
the model I use to do save states with libco. For another, I don't
know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could
actually keep running if it was executing out of RAM when it started
the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip
stall.) That'll greatly change how I handle the waiting.

Also, the OSS driver now supports Audio::Latency. Sound should be
even lower latency now. On FreeBSD when set to 0ms, it's absolutely
incredible. Cannot detect latency whatsoever. The Mario jump sound seems
to happen at the very instant I hear my cherry blue keyswitch activate.
2016-08-15 14:56:38 +10:00
Tim Allen 07995c05a5 Update to v100 release.
byuu says:

higan has finally reached v100!

I feel it's important to stress right away that this is not "version
1.00", nor is it a major milestone release. Rather than arbitrary version
numbers, all of my software simply bumps version numbers by one for each
official release. As such, higan v100 is simply higan's 100th release.

That said, the primary focus of this release has been code
clean-ups. These are always somewhat dangerous in that regressions are
possible. We've tested through sixteen WIP revisions, one of which was
open to the public, to try and minimize any regressions. But all the same,
please report any regressions if you discover any.

Changelog (since v099):
FC: render during pixels 1-256 instead of 0-255 [hex_usr]
FC: rewrote controller emulation code
SFC: 8% speedup over the previous release thanks to PPU optimizations
SFC: fixed nasty DB address wrapping regression from v099
SFC: USART developer controller removed; superseded by 21fx
SFC: Super Multitap option removed from controller port 1; ports
    renamed 2-5
SFC: hidden option to experiment with 128KB VRAM (strictly for novelty)
higan: audio volume no longer divided by number of audio streams
higan: updated controller polling code to fix possible future mapping
    issues
higan: replaced nall/stream with nall/vfs for file-loading subsystem
tomoko: can now load multi-slotted games via command-line
tomoko: synchronize video removed from UI; still available in the
    settings file
tomoko, icarus: can navigate to root drive selection on Windows
all: major code cleanups and refactoring (~1MB diff against v099)

Note 1: the audio volume change means that SGB and MSU1 games won't
lose half the volume on the SNES sounds anymore. However, if one goes
overboard and drives the sound all the way to max volume with the MSU1,
clamping may occur. The obvious solution is not to drive volume that high
(it will vastly overpower the SNES audio, which usually never exceeds
25% volume.) Another option is to lower the volume in the audio settings
panel to 50%. In general, neither is likely to ever be necessary.

Note 2: the synchronize video option was hidden from the UI because it
is no longer useful. With the advent of compositors, the loss of the
complicated timing settings panel, support for the WonderSwan and its
75hz display, the need to emulate variable refresh rate behaviors in the
Game Boy, the unfortunate latency spike and audio distortion caused by
long Vsync pauses, and the arrival of adaptive sync technology ... it
no longer makes sense to present this option. However, as stated, you
can edit settings.bml to enable this option anyway if you insist and
understand the aforementioned risks.

Changelog (since v099r16 open beta):

- fixed MSU1 audio sign extension
- fixed compilation with SGB support disabled
- icarus can now navigate to root directory
- fixed compilation issues with OS X port
- (hopefully) fixed label height issue with hiro that affected icarus
  import dialog
- (mostly) fixed BS Memory, Sufami Turbo slot loading

Errata:

- forgot to remove the " - Slot A", " - Slot B" suffixes for Sufami
  Turbo slot loading
  - this means you have to navigate up one folder and then into Sufami
    Turbo/ to load games for this system
- moving WonderSwan orientation controls to the device slot is causing
  some nastiness
  - can now select orientation from the main menu, but it doesn't rotate
    the display
2016-07-08 22:04:59 +10:00
Tim Allen 13ad9644a2 Update to v099r16 release (public beta).
byuu says:

Changelog:
- hiro: BrowserDialog can navigate up to drive selection on Windows
- nall: (file,path,dir,base,prefix,suffix)name =>
  Location::(file,path,dir,base,prefix,suffix)
- higan/tomoko: rename audio filter label from "Sinc" to "IIR - Biquad"
- higan/tomoko: allow loading files via icarus on the command-line
  once again
- higan/tomoko: (begrudging) quick hack to fix presentation window focus
  on startup
- higan/audio: don't divide output audio volume by number of streams
- processor/r65816: fix a regression in (read,write)DB; fixes Taz-Mania
- fixed compilation regressions on Windows and Linux

I'm happy with where we are at with code cleanups and stability, so I'd
like to release v100. But even though I'm not assigning any special
significance to this version, we should probably test it more thoroughly
first.
2016-07-04 21:53:24 +10:00
Tim Allen 8d5cc0c35e Update to v099r15 release.
byuu says:

Changelog:
- nall::lstring -> nall::string_vector
- added IntegerBitField<type, lo, hi> -- hopefully it works correctly...
- Multitap 1-4 -> Super Multitap 2-5
- fixed SFC PPU CGRAM read regression
- huge amounts of SFC PPU IO register cleanups -- .bits really is lovely
- re-added the read/write(VRAM,OAM,CGRAM) helpers for the SFC PPU
  - but they're now optimized to the realities of the PPU (16-bit data
    sizes / no address parameter / where appropriate)
  - basically used to get the active-display overrides in a unified place;
    but also reduces duplicate code in (read,write)IO
2016-07-04 21:48:17 +10:00
Tim Allen 82293c95ae Update to v099r14 release.
byuu says:

Changelog:
- (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel
  like they were contributing enough to be worth it]
- cleaned up nall::integer,natural,real functionality
  - toInteger, toNatural, toReal for parsing strings to numbers
  - fromInteger, fromNatural, fromReal for creating strings from numbers
  - (string,Markup::Node,SQL-based-classes)::(integer,natural,real)
    left unchanged
  - template<typename T> numeral(T value, long padding, char padchar)
    -> string for print() formatting
    - deduces integer,natural,real based on T ... cast the value if you
      want to override
    - there still exists binary,octal,hex,pointer for explicit print()
      formatting
- lstring -> string_vector [but using lstring = string_vector; is
  declared]
  - would be nice to remove the using lstring eventually ... but that'd
    probably require 10,000 lines of changes >_>
- format -> string_format [no using here; format was too ambiguous]
- using integer = Integer<sizeof(int)*8>; and using natural =
  Natural<sizeof(uint)*8>; declared
  - for consistency with boolean. These three are meant for creating
    zero-initialized values implicitly (various uses)
- R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees
  up struct IO {} io; naming]
- SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {}
  (status,registers); now
  - still some CPU::Status status values ... they didn't really fit into
    IO functionality ... will have to think about this more
- SFC CPU, PPU, SMP now use step() exclusively instead of addClocks()
  calling into step()
- SFC CPU joypad1_bits, joypad2_bits were unused; killed them
- SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it
- SFC PPU OAM moved into PPU::Object; since nothing else uses it
  - the raw uint8[544] array is gone. OAM::read() constructs values from
    the OAM::Object[512] table now
  - this avoids having to determine how we want to sub-divide the two
    OAM memory sections
  - this also eliminates the OAM::synchronize() functionality
- probably more I'm forgetting

The FPS fluctuations are driving me insane. This WIP went from 128fps to
137fps. Settled on 133.5fps for the final build. But nothing I changed
should have affected performance at all. This level of fluctuation makes
it damn near impossible to know whether I'm speeding things up or slowing
things down with changes.
2016-07-01 21:50:32 +10:00
Tim Allen ae5d380d06 Update to v098r11 release.
byuu says:

Changelog:
- fixed nall/path.hpp compilation issue
- fixed ruby/audio/xaudio header declaration compilation issue (again)
- cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the
  file was whitespace overkill)
- added null terminator entry to nall/windows/utf8.hpp argc[] array
- nall/windows/guid.hpp uses the Windows API for generating the GUID
  - this should stop all the bug reports where two nall users were
    generating GUIDs at the exact same second
- fixed hiro/cocoa compilation issue with uint# types
- fixed major higan/sfc Super Game Boy audio latency issue
- fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions
- major cleanups to higan/processor/r65816 core
  - merged emulation/native-mode opcodes
  - use camel-case naming on memory.hpp functions
  - simplify address masking code for memory.hpp functions
  - simplify a few opcodes themselves (avoid redundant copies, etc)
  - rename regs.* to r.* to match modern convention of other CPU cores
- removed device.order<> concept from Emulator::Interface
  - cores will now do the translation to make the job of the UI easier
- fixed plurality naming of arrays in Emulator::Interface
  - example: emulator.ports[p].devices[d].inputs[i]
  - example: vector<Medium> media
- probably more surprises

Major show-stoppers to the next official release:
- we need to work on GB core improvements: LY=153/0 case, multiple STAT
  IRQs case, GBC audio output regs, etc.
- we need to re-add software cursors for light guns (Super Scope,
  Justifier)
- after the above, we need to fix the turbo button for the Super Scope

I really have no idea how I want to implement the light guns. Ideally,
we'd want it in higan/video, so we can support the NES Zapper with the
same code. But this isn't going to be easy, because only the SNES knows
when its output is interlaced, and its resolutions can vary as
{256,512}x{224,240,448,480} which requires pixel doubling that was
hard-coded to the SNES-specific behavior, but isn't appropriate to be
exposed in higan/video.
2016-05-25 21:13:02 +10:00