1. 06 Sep, 2017 1 commit
    • Screwtape's avatar
      Update to v104r12 release. · 4fb8ce28
      Screwtape authored
      byuu says:
        - higan: URLs updated to HTTPS
        - sfc/ppu/background: use hires/interlace/mosaic-adjusted X/Y
          coordinates for offset-per-tile mode
        - sfc/ppu/background: hires mosaic seems to advance pixel counter on
          subscreen pixels
        - tomoko: added “Help→Credits” menu option (currently the page does
          not exist; should before v105)
        - tomoko: reduced volume slider from {0% - 500%} to {0% - 200%}.
          Distortion is too intense above 200%.
            - technically, I've encountered distortion at 200% as well in
              Prince of Persia for the SNES
        - nall/run/invoke: use program path for working directory
            - allows you to choose “Library→Import ROMs” from a different
              directory on the command-line
      I don't know how to assign credit for the mosaic stuff. It's been a
      work-in-progress with me, Cydrak, and hex_usr.
      The current design should be correct, but very unpleasant. The code
      desperately needs to be refactored, but my recent attempt at doing so
      ended in spectacular failure.
  2. 05 Sep, 2017 1 commit
    • Screwtape's avatar
      Update to v104r11 release. · 3dce3aa3
      Screwtape authored
      byuu says:
        - sfc/ppu/background: minor code cleanup and simplification
        - sfc/ppu/background: $2106 MOSAIC register was implemented
        - sfc/ppu/background: fixed mosaic effects in hires mode (temporary
        - sfc/ppu/background: fixed mosaic effects in interlace mode [Cydrak]
        - sfc/ppu/background/background.cpp:48: should be
          `if(!mosaic.enable) {`
      Turns out there is only one mosaic size, and the other four bits are
      per-BG mosaic enable. This matters a lot for hires/interlace, as
      mosaicSize=0 (2x2) is not the same thing as mosaicEnable=false (1x1).
      Although I've now implemented this, I really don't like how my mosaic
      implementation works right now. I tried to redesign the entire system,
      and completely failed. So I started over from v104r10 again and instead
      went with a more evolutionary improvement for now. I'll keep trying.
      Also, the combination of mosaic + offset-per-tile is still sketchy, as
      is mode 6 offset-per-tile. I'll get to those in the future as well.
  3. 01 Sep, 2017 2 commits
    • Screwtape's avatar
      Update to v104r10 release. · 28060d3a
      Screwtape authored
      byuu says:
        - processor/upd96050: per manual errata note, SGN always uses SA1;
          never SB1 [fixes v104r09 regression]
        - processor/upd96050: new OV1/S1 calculation that doesn't require OV0
          history buffer [AWJ]
        - processor/upd96050: do not update DP in OP if DST=4 [Jonas Quinn]
        - processor/upd96050: do not update RP in OP if DST=5 [Jonas Quinn]
        - resource: recreated higan+icarus icons, higan logo as 32-bit PNGs
      So higan v104r08 and earlier were 930KiB for the source tarball. After
      creating new higan and icarus icons, the size jumped to 1090KiB, which
      was insane for only adding one additional icon.
      After digging into why, I discovered that ImageMagick defaults to
      64-bit!! (16-bits per channel) PNG images when converting from SVG.
      You know, for all those 16-bit per channel monitors that don't exist.
      Sigh. Amazingly, nobody ever noticed this.
      The logo went from 78.8KiB to 24.5KiB, which in turn also means the
      generated resource.cpp shrank dramatically.
      The old higan icon was 32-bit PNG, because it was created before I
      installed FreeBSD and switched to ImageMagick. But the new higan icon,
      plus the new icarus icon, were both 64-bit as well. And they're now
      So the new tarball size, thanks to the logo optimization, dropped to
      Cydrak had some really interesting results in converting higan's
      resources to 8-bit palletized PNGs with the tRNS extension for alpha
      transparency. It reduces the file sizes even more without much visual
      fidelity loss. Eg the higan logo uses 778 colors currently, and 256
      represents nearly all of it very well to the human eye. It's based off
      of only two colors, the rest are all anti-aliasing. Unfortunately,
      nall/image doesn't support this yet, and I didn't want to flatten the
      higan logo to not have transparency, in case I ever want to change the
      about screen background color.
    • Screwtape's avatar
      Don't let gitlab cache .o files. · 9dcbd121
      Screwtape authored
      higan's makefiles don't always model dependencies properly, so caching
      .o files just invites stale .o files.
  4. 31 Aug, 2017 10 commits
  5. 30 Aug, 2017 2 commits
    • Screwtape's avatar
      Sufami Turbo carts are not memory paks! · 6b8c003f
      Screwtape authored
    • Screwtape's avatar
      Update to v104r08 release. · 25bda4f1
      Screwtape authored
      byuu says:
        - processor/upd96050: code cleanups
        - processor/upd96050: improved emulation of S1/OV1 flags [thanks to
          Cydrak, Lord Nightmare]
        - tomoko/settings/audio: reduced the size of the frequency/latency
          combo boxes to show longer device driver names
      Errata: I need to clear regs.sr in uPD96050::power()
      Note: the S1/OV1 emulation is likely not 100% correct yet, but it's a
      step in the right direction. No SNES games actually use S1/OV1, so this
      shouldn't result in any issues, I'd just like to have this part of the
      chip emulated correctly.
  6. 29 Aug, 2017 3 commits
  7. 28 Aug, 2017 1 commit
    • Screwtape's avatar
      Update to v104r07 release. · 9c25f128
      Screwtape authored
      byuu says:
        - md/vdp: added VIP bit to status register; fixes Cliffhanger
        - processor/m68k/disassembler: added modes 7 and 8 to LEA address
        - processor/m68k/disassembler: enhanced ILLEGAL to display LINEA/LINEF
          $xxx variants
        - processor/m68k: ILLEGAL/LINEA/LINEF do not modify the stack
          register; fixes Caeser no Yabou II
        - icarus/sfc: request sgb1.boot.rom and sgb2.boot.rom separately; as
          they are different
        - icarus/sfc: removed support for external firmware when loading ROM
      The hack to run Mega Drive Ballz 3D isn't in place, as I don't know if
      it's correct, and the graphics were corrupted anyway.
      The SGB boot ROM change is going to require updating the icarus database
      as well. I will add that in when I start dumping more cartridges here
      Finally ... I explained this already, but I'll do so here as well: I
      removed icarus' support for loading SNES coprocessor firmware games with
      external firmware files (eg dsp1.program.rom + dsp1.data.rom in the same
      path as supermariokart.sfc, for example.)
      I realize most are going to see this as an antagonizing/stubborn move
      given the recent No-Intro discussion, and I won't deny that said thread
      is why this came to the forefront of my mind. But on my word, I honestly
      believe this was an ineffective solution for many reasons not related to
      our disagreements:
       1. No-Intro distributes SNES coprocessor firmware as a merged file, eg
          "DSP1 (World).zip/DSP1 (World).bin" -- icarus can't possibly know
          about every ROM distribution set's naming conventions for firmware.
          (Right now, it appears GoodSNES and NSRT are mostly dead; but there
          may be more DATs in the future -- including my own.)
       2. Even if the user obtains the firmware and tries to rename it, it
          won't work: icarus parses manifests generated by the heuristics
          module and sees two ROM files: dsp1.program.rom and dsp1.data.rom.
          icarus cannot identify a file named dsp1.rom as containing both
          of these sub-files. Users are going to have to know how to split
          files, which there is no way to do on stock Windows. Merging files,
          however, can be done via `copy /b supermariokart.sfc+dsp1.rom
          supermariokartdsp.sfc`; - and dsp1.rom can be named whatever now.
          I am not saying this will be easy for the average user, but it's
          easier than splitting files.
       3. Separate firmware breaks icarus' database lookup. If you have
          pilotwings.sfc but without firmware, icarus will not find a match
          for it in the database lookup phase. It will then fall back on
          heuristics. The heuristics will pick DSP1B for compatibility with
          Ballz 3D which requires it. And so it will try to pull in the
          wrong firmware, and the game's intro will not work correctly.
          Furthermore, the database information will be unavailable, resulting
          in inaccurate mirroring.
      So for these reasons, I have removed said support. You must now load
      SNES coprocessor games into higan in one of two ways: 1) game paks with
      split files; or 2) SFC images with merged firmware.
      If and when No-Intro deploys a method I can actually use, I give you all
      my word I will give it a fair shot and if it's reasonable, I'll support
      it in icarus.
  8. 26 Aug, 2017 2 commits
    • Screwtape's avatar
      More cleanups. · c2732975
      Screwtape authored
    • Screwtape's avatar
      Update to v104r06 release. · afa8ea61
      Screwtape authored
      byuu says:
        - 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
        - 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
      ³: 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
      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.
  9. 25 Aug, 2017 1 commit
  10. 24 Aug, 2017 6 commits
    • Screwtape's avatar
      Update to v104r05 release. · b38a6571
      Screwtape authored
      byuu says:
        - emulator/random: new array function with more realistic RAM
        - 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
      I can't actually test the udev fixes, so I guess we'll see how that goes
      for Screwtape and ma\_rysia.
    • Screwtape's avatar
      Another doc cleanup. · a8f2bfc5
      Screwtape authored
    • Screwtape's avatar
      Revert an accidental ruby change. · d060904b
      Screwtape authored
      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 15b3dc8b as part of a documentation
    • Screwtape's avatar
      Clean up the higan Settings docs. · 56293c58
      Screwtape authored
    • Screwtape's avatar
      More cleanups and revision. · 15b3dc8b
      Screwtape authored
    • Screwtape's avatar
      Update to v104r04 release. · d621136d
      Screwtape authored
      byuu says:
        - higan/emulator: added new Random class with three entropy settings:
          none, low, and high
        - md/vdp: corrected Vcounter readout in interlace mode [MoD]
        - sfc: updated core to use the new Random class; defaults to high
      No entropy essentially returns 0, unless the random.bias(n) function is
      called, in which case, it returns n. In this case, n is meant to be the
      "logical/ideal" default value that maximizes compatibility with games.
      Low entropy is a very simple entropy modeled after RAM initialization
      striping patterns (eg 32 0x00s, followed by 32 0xFFs, repeating
      throughout.) It doesn't "glitch" like real hardware does on rare
      occasions (parts of the pattern being broken from time to time.) It also
      only really returns 0 or ~0. So the entropy is indeed extremely low, and
      not very useful at all for detecting bugs. Over time, we can try to
      improve this, of course.
      High entropy is PCG. This replaces the older, lower-entropy and more
      predictable, LFSR. PCG should be more than enough for emulator
      randomness, while still being quite fast.
      Unfortunately, the bad news ... both no entropy and low entropy fix the
      Konami logo popping sound in Prince of Persia, but all three entropy
      settings still cause the distortion in-game, especially evident at the
      title screen. So ... this may be a more serious bug than first
  11. 23 Aug, 2017 11 commits