1. 25 Oct, 2017 1 commit
    • Talarubi's avatar
      Update version and license · 9e06857e
      Talarubi authored
      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).
  2. 26 Jul, 2017 1 commit
    • Screwtape's avatar
      Update to v103r21 release. · 80841dea
      Screwtape authored
      byuu says:
        - 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()
        - 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.
  3. 24 Jul, 2017 1 commit
    • Screwtape's avatar
      Update to v103r20 release. · d5c09c9a
      Screwtape authored
      byuu says:
        - 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
      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.
        - libco/fiber
        - libco/ucontext (I should really just delete this)
        - tomoko: hide main UI window when in exclusive fullscreen mode
  4. 23 Jul, 2017 1 commit
    • Screwtape's avatar
      Update to v103r19 release. · 8be474b0
      Screwtape authored
      byuu says:
        - tomoko: Application::onMain assigned at end of Program::Program()
        - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c
        - 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
        - ruby/video/xvideo: fail nicely without crashing (hopefully)
        - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV
      ¹: 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.
        - forgot to rename the configuration settings dialog window title to
          just "Settings"
  5. 22 Jan, 2017 1 commit
    • Screwtape's avatar
      Update to v102r02 release. · bdc100e1
      Screwtape authored
      byuu says:
        - 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,
        - split WonderSwan::Interface into WonderSwanInterface,
        - 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
  6. 14 Sep, 2016 1 commit
    • Screwtape's avatar
      Update to v101r18 release. · c6fc15f8
      Screwtape authored
      byuu says:
        - 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.
  7. 07 Jan, 2016 1 commit
    • Screwtape's avatar
      Update to v096r02 (OS X Preview for Developers) release. · 4d193d7d
      Screwtape authored
      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.
      - 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
      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
      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.
  8. 30 Dec, 2015 1 commit
    • Screwtape's avatar
      Update to v096r01 release. · 47d4bd4d
      Screwtape authored
      byuu says:
      - 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.
  9. 22 Jun, 2015 1 commit
    • Screwtape's avatar
      Update to v094r29 release. · 83f684c6
      Screwtape authored
      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'
  10. 20 Jun, 2015 1 commit
    • Screwtape's avatar
      Update to v094r28 release. · e0815b55
      Screwtape authored
      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
      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
  11. 18 Aug, 2013 1 commit
    • Screwtape's avatar
      Update to v093 release. · 4e2eb238
      Screwtape authored
      byuu says:
      - 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
      - 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.
  12. 28 Dec, 2010 1 commit
    • Screwtape's avatar
      Initial commit of bgameboy v000. · da7d9f26
      Screwtape authored
      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.
  13. 20 Oct, 2010 1 commit
    • Screwtape's avatar
      Include all the code from the bsnes v068 tarball. · a59ecb3d
      Screwtape authored
      byuu describes the changes since v067:
      This release officially introduces the accuracy and performance cores,
      alongside the previously-existing compatibility core. The accuracy core
      allows the most accurate SNES emulation ever seen, with every last
      processor running at the lowest possible clock synchronization level.
      The performance core allows slower computers the chance to finally use
      bsnes. It is capable of attaining 60fps in standard games even on an
      entry-level Intel Atom processor, commonly found in netbooks.
      The accuracy core is absolutely not meant for casual gaming at all. It
      is meant solely for getting as close to 100% perfection as possible, no
      matter the cost to speed. It should only be used for testing,
      development or debugging.
      The compatibility core is identical to bsnes v067 and earlier, but is
      now roughly 10% faster. This is the default and recommended core for
      casual gaming.
      The performance core contains an entirely new S-CPU core, with
      range-tested IRQs; and uses blargg's heavily-optimized S-DSP core
      directly. Although there are very minor accuracy tradeoffs to increase
      speed, I am confident that the performance core is still more accurate
      and compatible than any other SNES emulator. The S-CPU, S-SMP, S-DSP,
      SuperFX and SA-1 processors are all clock-based, just as in the accuracy
      and compatibility cores; and as always, there are zero game-specific
      hacks. Its compatibility is still well above 99%, running even the most
      challenging games flawlessly.
      If you have held off from using bsnes in the past due to its system
      requirements, please give the performance core a try. I think you will
      be impressed. I'm also not finished: I believe performance can be
      increased even further.
      I would also strongly suggest Windows Vista and Windows 7 users to take
      advantage of the new XAudio2 driver by OV2. Not only does it give you
      a performance boost, it also lowers latency and provides better sound by
      way of skipping an API emulation layer.
      - Split core into three profiles: accuracy, compatibility and
      - Accuracy core now takes advantage of variable-bitlength integers (eg
      - Performance core uses a new S-CPU core, written from scratch for speed
      - Performance core uses blargg's snes_dsp library for S-DSP emulation
      - Binaries are now compiled using GCC 4.5
      - Added a workaround in the SA-1 core for a bug in GCC 4.5+
      - The clock-based S-PPU renderer has greatly improved OAM emulation;
        fixing Winter Gold and Megalomania rendering issues
      - Corrected pseudo-hires color math in the clock-based S-PPU renderer;
        fixing Super Buster Bros backgrounds
      - Fixed a clamping bug in the Cx4 16-bit triangle operation [Jonas
        Quinn]; fixing Mega Man X2 "gained weapon" star background effect
      - Updated video renderer to properly handle mixed-resolution screens
        with interlace enabled; fixing Air Strike Patrol level briefing screen
      - Added mightymo's 2010-08-19 cheat code pack
      - Windows port: added XAudio2 output support [OV2]
      - Source: major code restructuring; virtual base classes for processor
      - cores removed, build system heavily modified, etc.
  14. 09 Aug, 2010 1 commit