1. 25 Jan, 2019 2 commits
    • Screwtape's avatar
      Update to v106r88 release. · c9cdf909
      Screwtape authored
      byuu says:
      Couldn't sleep again.
      So, this updates all cores to the new options/properties setup, and
      connects onModify events to nall/settings.
      manifest.bml files are no longer required for .sys folders (I still need
      to delete a few of them, I forgot.)
      Currently, systems with slightly different properties (WonderSwan EEPROM
      sizes, Game Boy boot ROM sizes, ...) require per-system properties()
      functions. This in effect exposes a limitation with trying to share the
      properties from a single object. What's probably going to be necessary
      is to have each Interface class hold a `vector<Settings*>`, and during
      construction, add all the members said system needs. The same goes for
      options (Master System has controller ports whereas Game Gear does not.)
      This also means that we can't pre-declare the default values for all
      systems. We'll have to declare defaults inside each Interface instance.
      So in light of all of this, I'm probably going to reshape Settings to be
      a single-level class holding a ton of `Settings*` objects, and the
      serialization functionality will just have to build the tree from a flat
      list somehow. I could probably rely on Markup::Node itself to do this
      for me.
      Oh, nall/primitives gained explicit specializations for converting from
      a `const char*` (the string class isn't defined at this point,
      regrettably.) So with that, you can make a `Setting<T>` out of any `T` that
      can be explicitly constructed from a `const char*`. I want to do the same
      for the string class, and allow explicit casting to the nall/primitives
      types, as the toInteger(), etc classes are a little wonky to use.
    • Screwtape's avatar
      Update to v106r87 release. · 94c691e5
      Screwtape authored
      byuu says:
      These WIPs are gonna be unstable for a bit, sorry. Large amounts of
      changes. Right now, higan+bsnes compile, but only with cores="sfc gb".
      There's a new nall::Settings class, which I really dislike the design
      of, but as long as the classes that use it remain stable, then ... I'll
      have to live with it for now.
      Interface loses both the old get/set/cap interface, plus the
      configuration interface. It now returns either properties() or
      options(). Both return a Settings& object. There's also helpers for
      accessing individual properties and options by string lookup.
      Properties are immutable traits of the hardware itself: CPU version, PPU
      VRAM size, boot ROM information, etc.
      Options are mutable traits that users may change.
      The idea with nall/settings is to build out a kind of extremely complex
      configuration object that'll do everything we'd ever want:
        - allow recursive children settings similar to Markup::Node
        - access values directly without dynamic_cast (type erasure) or
          string conversion (Markup::Node style)
        - serialize to and unserialize from BML
        - support valid values to guarantee that the settings are never in an
          invalid state
        - support latching of values to cache reads without another separate
          variable (so the GUI can modify any variables at any time safely)
        - allow binding callback functions on assignment, so that eg changing
          video/colorEmulation will regenerate the video palette
        - provide a hint on whether an option can be changed dynamically at
          run-time, or only statically at first load
        - provide descriptions for each setting
      And then once the class is fully fleshed out, I want to build a tool
      that will generate a fancy modal hiro Window from a Settings& object.
      Once that is complete, we'll then have System → Options to configure
      per-emulator settings (like bsnes PPU stuff) that otherwise doesn't fit
      into higan's GUI. We will be exposing the extended Super Famicom options
      to the bsnes GUI, of course. That's the emulator tab there.
      Next up, higan's systems tab will need to generate blank default
      property files for each system, and let you configure system properties
      from this screen. That's going to mean that, by allowing the same system
      to appear multiple times, that each entry gets its own options file,
      which will have to be stored somewhere.
      And to do all of that, we really need to work out how to handle regions
      first. It may have to be something radical like FitzRoy's idea, or it
      may be that we can come up with something a little less drastic. But I
      have no idea right now ...
      What I'd really like to do is start trying to get bsnes v107 out
      already. The two things holding it up are: fixing the desync between the
      settings.bml GUI settings and options.bml SNES properties (I know what's
      wrong, I just have to fix it), and getting XAudio2 DRC working (I copied
      BearOso's implementation details, but it just doesn't work for me ...).
      Then I also have to install Windows, set up a dev environment with
      msys2, and build it all.
      Lots and lots of work ...
  2. 24 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r86 release. · 631baa40
      Screwtape authored
      byuu says:
      In addition to the restructuring changes mentioned previously, I've
      started on yet another attempt at unifying per-emulator core
      configuration settings.
      This time, everything is based on template<typename T> struct Setting;
      which has child elements similar to Markup::Node, but holds the exact
      type rather than a string that needs to be converted. If we had a
      setting checked millions of times a second in the core (say, a mute flag
      for a 2MHz audio chip), it would be too much overhead. I don't even want
      it to be a heap-allocated pointer that has to be dynamic_casted
      (nall::any), so it ends up more like an std::variadic object.
      Setting classes construct the same way hiro does: the children specify
      their parents in the variable declarations. From there, you can
      serialize (and soon, unserialize) to (and from) BML.
      Presently, I'm thinking we are going to want two separate settings
      structures: one for fixed system properties (CPU version, PPU1 VRAM
      amount, etc) -- basically, variables that describe a certain machine
      configuration. And another for user-configurable properties (interframe
      blending, color bleed, scanlines, speed hacks, etc.)
      The reasoning is for higan: under the systems tab, when you pick a
      system to add, it would be nice to display the system configuration
      there. Polluting that with options you'd likely change at run-time would
      be confusing and annoying.
      I'm also hoping to write a rather complex class that will generate a
      dialog window for editing all of the settings found. We could *really*
      use TreeView on all platforms for this, heh ... I may have to go attempt
      to merge hex_usr's previous work there.
      In the future, I'd like to flesh out the settings even more with
      optional additional things like lists of possible values, that can then
      result in drop-downs in the generated dialogs.
      The real question is ... is it time to use the new machine properties to
      separate NTSC, PAL, etc regions? There's gonna be cases like the Mark
      III having the YM2413 module, but only in Japan. The load dialog option
      dropdown was always kind of a hacky way of doing regions.
      Oh, I also wrote nall/instance.hpp, which is a grotesque delayed
      construction hack. The amethyst hiro bug was kind of the last straw in
      attempting to tame global construction order. I'm going to slowly kill
      off hiro::initialize and revert back to requiring hiro objects to be
      constructed -after- main().
  3. 22 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r85 release. · fbc15718
      Screwtape authored
      byuu says:
      The bad instruction was due to the instruction before it fetching one
      too many bytes. Didn't notice right away as the disassembler got it
      The register map was incorrect on the active 16-bit flags.
      I fixed and improved some other things along those lines. Hooked up some
      basic KnGE (VPU) timings, made it print out VRAM and some of the WRAM
      onto the screen each frame, tried to drive Vblank and Hblank IRQs, but
      ... I don't know for sure what vector addresses they belong to.
      MAME says "INT4" for Vblank, and says nothing for Hblank. I am wildly
      guessing INT4==SWI 4==0xffff10, but ... I have no idea. I'm also not
      emulating the interrupts properly based on line levels, I'm just firing
      on the 0→1 transitions. Sounds like Vblank is more nuanced too, but I
      guess we'll see.
      Emulation is running further along now, even to the point of it
      successfully enabling the KnGE IRQs, but VRAM doesn't appear to get much
      useful stuff written into it yet.
      I reverted the nall/primitive changes, so request for testing is I guess
      rescinded, for whatever it was worth.
  4. 21 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r84 release. · 53843934
      Screwtape authored
      byuu says:
        - fixed a few TLCS900H CPU and disassembler bugs
        - hooked up a basic Neo Geo Pocket emulator skeleton and memory map;
          can run a few instructions from the BIOS
        - emulated the flash memory used by Neo Geo Pocket games
        - added sourcery to the higan source archives
        - fixed ternary expressions in sfc/ppu-fast [hex_usr]
  5. 19 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r83 release. · 37b610da
      Screwtape authored
      byuu says:
        - reverted nall/inline-if.hpp usage for now, since the
          nall/primitives.hpp math operators still cast to (u)int64_t
        - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will
          now print 128 (unary operator+ and - cast to (u)int64_t)
        - renamed processor/lr35902 to processor/sm83; after the Sharp SM83
          CPU core [gekkio discovered the name]
        - a few bugfixes to the TLCS900H CPU core
        - completed the disassembler for the TLCS900H core
      As a result of reverting most of the inline if stuff, I guess the
      testing priority has been reduced. Which is probably a good thing,
      considering I seem to have a smaller pool of testers these days.
      Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000
      core at 128KiB. So it's now the largest CPU core in all of higan. It's
      even more ridiculous because the M68000 core would ordinarily be quite a
      bit smaller, had I not gone overboard with the extreme templating to
      reduce instruction decoding overhead (you kind of have to do this for
      RISC CPUs, and the inverted design of the TLCS900H kind of makes it
      infeasible to do the same there.)
      This CPU core is bound to have dozens of extremely difficult CPU bugs,
      and there's no easy way for me to test them. I would greatly appreciate
      any help in looking over the core for bugs. A fresh pair of eyes to spot
      a mistake could save me up to several days of tedious debugging work.
      The core still isn't ready to actually be tested: I have to hook up
      cartridge loading, a memory bus, interrupts, timers, and the micro DMA
      controller before it's likely that anything happens at all.
  6. 17 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r82 release. · 2d9ce59e
      Screwtape authored
      byuu says:
      Half of the disassembler is implemented now. Well, the decoding half
      anyway. I'm splitting the decoding and string building into separate
      components this time around, on account of the instruction encoding
      being in reverse order. The string building portion hasn't been written
      yet, either.
      We're up to 112KiB now, compared to 128KiB for the 68K.
  7. 16 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r81 release. · 559a6585
      Screwtape authored
      byuu says:
      First 32 instructions implemented in the TLCS900H disassembler. Only 992
      to go!
      I removed the use of anonymous namespaces in nall. It was something I
      rarely used, because it rarely did what I wanted.
      I updated all nested namespaces to use C++17-style namespace Foo::Bar {}
      syntax instead of classic C++-style namespace Foo { namespace Bar {}}.
      I updated ruby::Video::acquire() to return a struct, so we can use C++17
      structured bindings. Long term, I want to get away from all functions
      that take references for output only. Even though C++ botched structured
      bindings by not allowing you to bind to existing variables, it's even
      worse to have function calls that take arguments by reference and then
      write to them. From the caller side, you can't tell the value is being
      written, nor that the value passed in doesn't matter, which is terrible.
  8. 15 Jan, 2019 2 commits
    • Screwtape's avatar
      Update to v106r80 release. · 25145f59
      Screwtape authored
      byuu says:
      Any usage of natural and integer cast to 64-bit math operations now.
      Hopefully this will be the last of the major changes for a bit on
      nall/primitives, at least until serious work begins on removing implicit
      conversion to primitive types.
      I also completed the initial TLCS900H core, sans SWI (kind of a ways off
      from support interrupts.) I really shouldn't say completed, though. The
      micro DMA unit is missing, interrupt priority handling is missing,
      there's no debugger, and, of course, there's surely dozens of absolutely
      critical CPU bugs that are going to be an absolute hellscape nightmare
      to track down.
      It was a damn shame, right up until the very last eight instructions,
      [CP|LD][I|D](R), the instruction encoding was consistent. Of course,
      there could be other inconsistencies that I missed. In fact, that's
      somewhat likely ... sigh.
    • Screwtape's avatar
      Update to v106r79 release. · 17fc6d8d
      Screwtape authored
      byuu says:
      This WIP is just work on nall/primitives ...
      Basically, I'm coming to the conclusion that it's just not practical to
      try and make Natural/Integer implicitly castable to primitive signed and
      unsigned integers. C++ just has too many edge cases there.
      I also want to get away from the problem of C++ deciding that all math
      operations return 32-bit values, unless one of the parameters is 64-bit,
      in which case you get a 64-bit value. You know, so things like
      array[-1] won't end up accessing the 4 billionth element of the array.
      It's nice to be fancy and minimally size operations (eg 32-bit+32-bit =
      33-bit), but it's just too unintuitive. I think all
      Natural<X>+Natural<Y> expessions should result in a Natural<64> (eg
      natural) type.
      nall/primitives/operators.hpp has been removed, and new
      Natural<>Natural / Integer<>Integer casts exist. My feeling is that
      signed and unsigned types should not be implicitly convertible where
      data loss can occur. In the future, I think an integer8*natural8 is
      fine to return an integer64, and the bitwise operators are probably all
      fine between the two types. I could probably add
      (Integer,Natural)+Boolean conversions as well.
      To simplify expressions, there are new user-defined literals for _b
      (boolean), _n (natural), _i (integer), _r (real), _n# (eg _n8),
      _i# (eg _i8), _r# (eg _r32), and _s (nall::string).
      In the long-term, my intention is to make the conversion and cast
      constructors explicit for primitive types, but obviously that'll shatter
      most of higan, so for now that won't be the case.
      Something I can do in the future is allow implicit conversion and
      casting to (u)int64_t. That may be a nice balance.
  9. 14 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r78 release. · 6871e0e3
      Screwtape authored
      byuu says:
      I've implemented a lot more TLCS900H instructions. There are currently
      20 missing spots, all of which are unique instructions (well, MINC and
      MDEC could be considered pairs of 3 each), from a map of 1024 slots.
      After that, I have to write the disassembler. Then the memory bus. Then
      I get to start the fun process of debugging this monstrosity.
      Also new is nall/inline-if.hpp. Note that this file is technically a war
      crime, so be careful when opening it. This replaces ternary() from the
      previous WIP.
  10. 13 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r77 release. · bb1dd8c6
      Screwtape authored
      byuu says:
      So this turned out to be a rather unproductive ten-hour rabbit hole, but
      I reworked nall/primitives.hpp a lot. And because the changes are
      massive, testing of this WIP for regressions is critically important. I
      really can't stress that enough, we're almost certainly going to have
      some hidden regressions here ...
      We now have a nall/primitives/ subfolder that splits up the classes into
      manageable components. The bit-field support is now shared between both
      Natural and Integer. All of the assignment operator overloads are now
      templated and take references instead of values. Things like the
      GSU::Register class are non-copyable on account of the function<>
      object inside of it, and previously only operator= would work with
      classes like that.
      The big change is nall/primitives/operators.hpp, which is a really
      elaborate system to compute the minimum number of bits needed for any
      operation, and to return a Natural<T> or Integer<T> when one or both of
      the arguments are such a type.
      Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3
      breaks if we include operators.hpp. Zelda 3 runs fine with this, but I
      had to make a huge amount of core changes, including introducing a new
      ternary(bool, lhs, rhs) function to nall/algorithm to get past
      Natural<X> and Natural<Y> not being equivalent (is_integral types get a
      special exemption to ternary ?: type equivalence, yet it's impossible to
      simulate with our own classes, which is bullshit.) The horrifying part
      is that ternary() will evaluate both lhs and rhs, unlike ?:
      I converted some of the functions to test ? uint(x) : uint(y), and
      others to ternary(test, x, y) ... I don't have a strong preference
      either way yet.
      But the part where things may have gotten broken is in the changes to
      where ternary() was placed. Some cases like in the GBA PPU renderer, it
      was rather unclear the order of evaluations, so I may have made a
      mistake somewhere.
      So again, please please test this if you can. Or even better, look over
      the diff.
      Longer-term, I'd really like the enable nall/primitives/operators.hpp,
      but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help
      would be appreciated, but ... it's gonna be really complex and difficult
      to debug, so I'm probably gonna be on my own here ... sigh.
  11. 11 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r76 release. · c9f7c6c4
      Screwtape authored
      byuu says:
      I added some useful new functions to nall/primitives:
          auto Natural<T>::integer() const -> Integer<T>;
          auto Integer<T>::natural() const -> Natural<T>;
      These let you cast between signed and unsigned representation without
      having to care about the value of T (eg if you take a Natural<T> as a
      template parameter.) So for instance when you're given an unsigned type
      but it's supposed to be a sign-extended type (example: signed
      multiplication), eg Natural<T> → Integer<T>, you can just say:
          x = y.integer() * z.integer();
      The TLCS900H core gained some more pesky instructions such as DAA, BS1F,
      I stole an optimization from RACE for calculating the overflow flag on
      addition. Assuming: z = x + y + c;
          Before: ~(x ^ y) & (x ^ z) & signBit;
          After: (x ^ z) & (y ^ z) & signBit;
      Subtraction stays the same. Assuming: z = x - y - c;
          Same: (x ^ y) & (x ^ z) & signBit;
      However, taking a speed penalty, I've implemented the carry computation
      in a way that doesn't require an extra bit.
      Adding before:
          uint9 z = x + y + c;
          c = z & 0x100;
      Subtracting before:
          uint9 z = x - y - c;
          c = z & 0x100;
      Adding after:
          uint8 z = x + y + c;
          c = z < x || z == x && c;
      Subtracting after:
          uint8 z = x - y - c;
          c = z > x || z == x && c;
      I haven't been able to code golf the new carry computation to be any
      shorter, unless I include an extra bit, eg for adding:
          c = z < x + c;
      But that defeats the entire point of the change. I want the computation
      to work even when T is uintmax_t.
      If anyone can come up with a faster method, please let me know.
      Anyway ... I also had to split off INC and DEC because they compute
      flags differently (word and long modes don't set flags at all, byte mode
      doesn't set carry at all.)
      I also added division by zero support, although I don't know if it's
      actually hardware accurate. It's what other emulators do, though.
  12. 10 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r75 release. · 95d00202
      Screwtape authored
      byuu says:
      So tired ... so much left to do still ... sigh.
      If someone's up for some code golf, open to suggestions on how to handle
      the INTNEST control register. It's the only pure 16-bit register on the
      system, and it breaks my `map`/`load`/`store<uint8,16,32>` abstraction.
      Basically what I suspect happens is when you access INTNEST in 32-bit
      mode, the upper 16-bits are just undefined (probably zero.) But
      `map<uint32>(INTNEST)` must return a uint32& or nothing at all. So for the
      time being, I'm just making store(ControlRegister) check if it's the
      INTNEST ID, and clearing the upper bits of the written byte in that
      case. It's hacky, but ... it's the best I can think of.
      I added LDX, which is a 900H-only instruction, and the control register
      map is for the 900/H CPU. I found the detailed differences between the
      CPUs, and it doesn't look likely that I'm gonna support the 900 or
      900/H1 at all. Not that there was a reason to anyway, but it's nice to
      support more stuff when possible. Oh well.
      The 4-byte instruction fetch queue is going to have to get implemented
      inside fetch, or just not implemented at all ... not like I'd be able to
      figure out the details of it anyway.
      The manual isn't clear on how the MULA flags are calculated, but since
      MUL doesn't set any flags, I assume the flags are based on the addition
      after the multiplication, eg:
          uint32 a = indirect<int16>(XDE) * indirect<int16>(XHL);
          uint32 b = reg16; //opcode parameter
          uint32 c = a + b; //flags set based on a+b
      No idea if it's right or not. It doesn't set carry or half-carry, so
      it's not just simply the same as calling algorithmAdd.
      Up to almost 70KB, not even halfway done, don't even have a disassembler
      started yet. There's a real chance this could overtake the 68K for the
      biggest CPU core in higan, although at this point I'm still thinking the
      68K will end up larger.
  13. 08 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r74 release. · 41148b10
      Screwtape authored
      byuu says:
      So I spent the better part of eight hours refactoring the TLCS900H core
      to be more flexible in light of new edge cases.
      I'm now including the size information inside of the types (eg
      Register<Byte>, Memory<Word>) rather than as parameters to the
      instruction handlers. This allows me to eg implement RETI without
      needing template arguments in all the instructions. pop(SR), pop(PC) can
      deduce how much to pop off of the stack. It's still highly templated,
      but not unrolling the 3-bit register indexes and instead going through
      the switch table to access registers is going to hurt the performance a
      good deal.
      A benefit of this is that Register{A} != Register{WA} != Register{XWA}
      anymore, despite them sharing IDs.
      I also renamed read/write to load/store for the CPU core, because
      implicit conversions are nasty. They all call the virtual read/write.
      I added more instructions, improved the memory addressing mode support,
      and some other things.
      I got rid of Byte, Word, Long because there's too many alternate sizes
      needed: int8, int16, uint24, etc.
      Ran into a really annoying C++ case ...
          struct TLCS900H {
            template<typename T> auto store(Register<T> target, T source) -> void;
      If you call store(Register<uint32>(x), uint16(y)); it errors out since
      the T types don't match. But you can't specialize it:
          template<typename T, typename U> auto store(Register<T>, U) -> void;
          template<typename U> auto TLCS900H::store<uint32, U>(Register<uint32>, U) -> void;
      Because somehow it's 2019 and we still can't do partial template
      specialization inside classes ...
      So as a result, I had to make T source be type uint32 even for
      Register<uint8> and Register<uint16>. Doesn't matter too much, just
  14. 07 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r73 release. · dbee8934
      Screwtape authored
      byuu says:
      This probably won't fix the use of register yet (I imagine ruby and hiro
      will complain now), but ... oh well, it's a start. We'll get it
      compiling again eventually.
      I added JP, JR, JRL, LD instructions this time around. I'm also starting
      to feel that Byte, Word, Long labels for the TLCS900H aren't really
      working. There's cases of needing uint24, int8, int16, ... it may just
      be better to name the types instead of trying to be fancy.
      At this point, all of the easy instructions are in. Now it's down to a
      whole lot of very awkward bit-manipulation and special-use instructions.
  15. 05 Jan, 2019 2 commits
    • Screwtape's avatar
      Update to v106r72 release. · cb86cd11
      Screwtape authored
      byuu says:
      For this WIP, I added more TLCS900H instructions. All of the
      ADC,ADD,SBB/SBC,SUB,AND,OR,XOR.CP,PUSH,POP instructions are in.
      Still an incredible amount of work left to do on this core ... it has all kinds
      of novel instructions that aren't on any other processors.
      Still no disassembler support yet, so I can't even test what I'm doing. Fun!
    • Screwtape's avatar
      Update to v106r71 release. · 1a889ae2
      Screwtape authored
      byuu says:
      I started working on the Toshiba TLCS900H CPU core today.
      It's basically, "what if we took the Z80, added in 32-bit support, added
      in SPARC register windows, added a ton of additional addressing modes,
      added control registers, and added a bunch of additional instructions?"
      -- or in other words, it's basically hell for me.
      It took several hours just to wrap my head around the way the opcode
      decoder needed to function, but I think I have a decent strategy for
      implementing it now.
      I should have all of the first-byte register/memory address decoding in
      place, although I'm sure there's lots of bugs. I don't have anything in
      the way of a disassembler yet.
  16. 03 Jan, 2019 3 commits
    • Screwtape's avatar
      Update to v106r70 release. · 79be6f23
      Screwtape authored
      byuu says:
        - Interface::displays() -> vector<Display> → Interface::display() -> Display
        - <Platform::videoRefresh(display>, ...) → <Platform::videoFrame>(...)
        - <Platform::audioSample>(...) → <Platform::audioFrame>(...)
        - higan, icarus: use AboutDialog class instead of ad-hoc
            - about dialog is now modal, but now has a clickable website URL
        - icarus: reverted if constexpr for now
        - MSX: implemented basic CPU, VDP support
      I took out the multiple displays support thing because it was never
      really implemented fully (Emulator::Video and the GUIs both ignored it)
      or used anyway. If it ends up necessary in the future, I'll worry about
      it then.
      There's enough MSX emulation now to run Mr. Do! without sound or input.
      I'm shipping higan with C-BIOS 0.29a, although it likely won't be good
      enough in the future (eg it can't do BASIC, floppy disk, or cassette
      loading.) I have keyboard and (not working) AY-3-8910 support in a
      different branch, so that won't take too long to implement. Main problem
      is naming all the darned keyboard keys. I think I need to change
      settings.bml's input mapping lines so that the key names are values
      instead of node names, so that any characters can appear inside of them.
      It turns out my MSX set uses .rom for the file extensions ... gods. So,
      icarus can't really import them like this. I may have to re-design
      icarus' importer to stop caring about the file extension and instead ask
      you what kind of games you are importing. There's no way icarus can
      heuristically guess what systems the images belong to, because many
      systems don't have any standardized magic bytes.
      I'm struggling with where to put SG-1000, SC-3000, ColecoVision, Coleco
      Adam stuff. I think they need to be split to two separate higan
      subfolders (sg and cv, most likely ...) The MS/GG share a very
      customized and extended VDP that the other systems don't have. The Sega
      and Coleco older hardware share the same TMS9918 as the MSX, yet have
      very different memory maps and peripherals that I don't want to mix
      together. Especially if we start getting into the computer-variants
    • Screwtape's avatar
    • Screwtape's avatar
      Build with Ubuntu LTS instead of Debian Stable. · 1fd6d983
      Screwtape authored
      Debian has served us well, but byuu would like to start using C++17 features
      which generally requires GCC7. Debian Stable only has GCC6 right now, while
      Ubuntu LTS has the required version, so that should get things going again.
  17. 01 Jan, 2019 1 commit
    • Screwtape's avatar
      Update to v106r69 release. · aaf094e7
      Screwtape authored
      byuu says:
      The biggest change was improving WonderSwan emulation. With help from
      trap15, I tracked down a bug where I was checking the wrong bit for
      reverse DMA transfers. Then I also emulated VTOTAL to support variable
      refresh rate. Then I improved HyperVoice emulation which should be
      unsigned samples in three of four modes. That got Fire Lancer running
      great. I also rewrote the disassembler. The old one disassembled many
      instructions completely wrong, and deviated too much from any known x86
      syntax. I also emulated some of the quirks of the V30 (two-byte POP into
      registers fails, SALC is just XLAT mirrored, etc) which probably don't
      matter unless someone tries to run code to verify it's a NEC CPU and not
      an Intel CPU, but hey, why not?
      I also put more work into the MSX skeleton, but it's still just a
      skeleton with no real emulation yet.
  18. 22 Dec, 2018 1 commit
    • Screwtape's avatar
      Update to v106r68 release. · 3159285e
      Screwtape authored
      byuu says:
        - nall: converted range, iterator, vector to 64-bit
        - added (very poor) ColecoVision emulation (including Coleco Adam
        - added MSX skeleton
        - added Neo Geo Pocket skeleton
        - moved audio,video,resource folders into emulator folder
        - SFC heuristics: BS-X Town cart is "ZBSJ" [hex_usr]
      The nall change is for future work on things like BPA: I need to be able
      to handle files larger than 4GB. It is extremely possible that there are
      still some truncations to 32-bit lurking around, and even more
      disastrously, possibly some -1s lurking that won't sign-extend to
      `(uint64_t)0-1`. There's a lot more classes left to do: `string`,
      `array_view`, `array_span`, etc.
  19. 21 Dec, 2018 1 commit
    • Screwtape's avatar
      Update to v106r67 release. · 90da6917
      Screwtape authored
      byuu says:
        - added all pre-requisite to make install rule (note: only for higan,
          icarus so far)
        - added SG-1000 emulation
        - added SC-3000 emulation (no keyboard support yet)
        - added MS graphics mode 1 emulation (SC-1000)
        - added MS graphics mode 2 emulation (F-16 Fighter)
        - improve Audio::process() to prevent a possible hang
        - higan: repeat monaural audio to both left+right speakers
        - icarus: add heuristics for importing MSX games (not emulated in
          higan yet in this WIP)
        - added DC bias removal filter [jsd1982]
        - improved Audio::Stream::reset() [jsd1982]
      I was under the impression that the 20hz highpass filter would have
      removed DC bias ... if not, then I don't know why I added that filter to
      all of the emulation cores that have it. In any case, if anyone is up
      for helping me out ... if we could analyze the output with and without
      the DC bias filter to see if it's actually helping, then I'll enable it
      if it is. To enable it, edit
      higan/audio/stream.cpp::addDCRemovalFilter() and remove the return
      statement at the top of the function.
  20. 20 Dec, 2018 4 commits
    • Screwtape's avatar
    • Screwtape's avatar
    • Screwtape's avatar
      Update .gitignore. · 41eccf6e
      Screwtape authored
      At some point, higan moved system metadata from higan/profile to higan/systems.
      Also, higan's Super Famicom core added config options of its own, which it now
      writes out.
    • Screwtape's avatar
      Update to v106r66 release. · 4c4e79aa
      Screwtape authored
      byuu says:
        - moved to GCC 8.2 and C++17
        - fixed compilation under FreeBSD 12.0
        - don't read beyond the file size in
        - add missing I/O cycle HuC6280::instructionImmediate
        - serialize Mega Drive's Game Genie state
        - serialize SPC7110::Thread information
        - enable 30-bit color depth support under the GLX/OpenGL 2.0 driver
          (doesn't work with OpenGL 3.2 yet)
      The 30-bit color depth option isn't super useful, but why not? I need to
      update ruby to detect that the display is actually capable of it before
      exposing an option that can result in the driver failing to initialize,
  21. 16 Nov, 2018 1 commit
    • Screwtape's avatar
      docs: Review and update docs for v107. · 0b44399c
      Screwtape authored
      Changes include:
      - The "Library" menu was replaced with the "Systems" menu
      - The "Settings" menu was reorganised
      - Game Boy rumble is now under the MBC5 "controller" for the cartridge "port",
        instead of being presented as a part of the base console
      - Import instructions now mention that icarus ships with some firmware files,
        and describe the "Firmware" directory that icarus will use for firmware
        it needs.
      - Apparently the correct name is "MSU1", not "MSU-1"
      - v107 changes the way MSU1 data is stored in game folders
      - PowerFest '94 import instructions removed, since I can't get it to work
        with v107
      - Links to the official forum have been replaced with links to the unofficial
        forum archive, since the official forum is shutting down
      - Links to Mercurial Magic updated to point at qwertymodo's archive, since
        hex_usr is no longer developing it
      - Links to nSide updated, since hex_usr no longer uses GitHub.
      - Windows build instructions now describe a compiler that is actually
        maintained, instead of stale TDM64-GCC.
      - Linux build instructions now mention higan requires SDL 2.0.
      - minor wording changes, typos, broken links fixed, etc.
  22. 04 Oct, 2018 2 commits
    • Screwtape's avatar
      Update build instructions. · 23dd2895
      Screwtape authored
      The latest WIP renames icarus/database and icarus/firmware to
      icarus/Database and icarus/Firmware (in title case).
      Also, somewhere along the line we stopped building icarus for higan/Linux,
      which seems an oversight.
    • Screwtape's avatar
      Update to v106r65 release. · 03b06257
      Screwtape authored
      byuu says:
      This synchronizes bsnes/higan with many recent internal nall changes.
      This will be the last WIP until I am situated in Japan. Apologies for the
      bugfixes that didn't get applied yet, I ran out of time.
  23. 13 Sep, 2018 1 commit
    • Screwtape's avatar
      Update to v106r64 release. · 336d2012
      Screwtape authored
      byuu says:
        - sfc: completed BS Memory Cassette emulation (sans bugs, of course --
          testing appreciated)
        - bsnes: don't strip - on MSU1 track names in game ROM mode
      I'm going with "metadata.bml" for the flash metadata filename for the
      time being, but I'll say that it's subject to change. I'll have to make
      a new extension for it to be supported with bsnes.
  24. 11 Sep, 2018 1 commit
    • Screwtape's avatar
      Update to v106r63 release. · c5816994
      Screwtape authored
      byuu says:
        - gb/mbc7: rewrote the 93LCx6 EEPROM emulation
        - sfc/slot/bsmemory: rewrote the flash emulation for Satellaview
      As of this release, flash-based BS Memory cartridges will be writable.
      So without the bsnes patch to disable write limits, some games will lock
      out after a few plays.
  25. 10 Sep, 2018 1 commit
    • Screwtape's avatar
      Update to v106r62 release. · c2d0ed4c
      Screwtape authored
      byuu says:
        - sfc/cx4: added missing instructions [info from Overload]
        - sfc/cx4: added instruction cache emulation [info from ikari]
        - sfc/sa1: don't let CPU access SA1-only I/O registers, and vice versa
        - sfc/sa1: fixed IRQs that were broken from the recent WIP
        - sfc/sa1: significantly improved bus conflict emulation
            - all tests match hardware now, other than HDMA ROMROM, which
              is 0.5 - 0.8% too fast
        - sfc/cpu: fixed a bug with DMA→CPU alignment timing
        - sfc/cpu: removed the DMA pipe; performs writes on the same cycles as
          reads [info from nocash]
        - sfc/memory: fix a crashing bug due to not clearing Memory size field
        - bsnes/gb: use .rtc for real-time clock file extensions on the Game
          Boy [hex_usr]
        - ruby/cgl: compilation fix [Sintendo]
      Now let's see if I can accept being off by ~0.65% on one of twelve SA1
      timing tests for the time being and prioritize much more important
      things or not.
  26. 04 Sep, 2018 1 commit
    • Screwtape's avatar
      Update to v106r61 release. · 3d34517f
      Screwtape authored
      byuu says:
      This release adds ikari's Cx4 notes to bsnes. It fixes the MMX2 intro's
      boss fight sequence to be frame perfect to real hardware. It's also very
      slightly faster than before.
      I've also added an option to toggle the CPUcoprocessor cycle
      synchronization to the emulation settings panel, so you don't have to
      recompile to get the more accurate SA1 timings. I'm most likely going to
      default this to disabled in bsnes, and *maybe* enabled in higan out of
      the box.
      StaticRAM (wasn't used) and MappedRAM are gone from the Super Famicom
      core. Instead, there's now ReadableMemory, WritableMemory, and
      ProtectedMemory (WritableMemory with a toggle for write protection.)
      Cartridge::loadMap now takes a template Memory object, which bypasses an
      extra virtual function call on memory accesses, but it doesn't really
      impact speed much. Whatever.
  27. 02 Sep, 2018 1 commit
    • Screwtape's avatar
      Update to v106r60 release. · a3e0f6da
      Screwtape authored
      byuu says:
      I added (imperfect) memory conflict timing to the SA1.
        - WRAMROM ran 7% too fast
        - ROMROM ran 100% too fast
        - WRAMIRAM ran 7% too fast
        - ROMIRAM ran 7% too fast
        - IRAMIRAM ran 287% too fast
        - BWRAMBWRAM ran 100% too fast
        - HDMA ROMROM ran 15% too fast
        - HDMA WRAMROM ran 15% too fast
        - DMA ROMROM ran 100% too fast
        - ROMROM runs 14% too fast
        - HDMA WRAMROM runs 7% too fast
        - DMA ROMROM runs 4% too fast
      If you enable this with the fast PPU + DSP, your framerate in SA1 games
      will drop by 51%. And even if you disable it, you'll still lose 9% speed
      in SA1 games, and 2% speed in non-SA1 games, because of changes needed
      to make this support possible.
      By default, I'm leaving this off. Compile with `-DACCURATE_SA1` (or
      uncomment the line in sfc/sfc.hpp) if you want to try it out.
      This'll almost certainly cause some SA1 regressions, so I guess we'll
      tackle those as they arise.
  28. 26 Aug, 2018 1 commit
    • Screwtape's avatar
      Update to v106r59 release. · bd814f03
      Screwtape authored
      byuu says:
        - fixed bug in Emulator::Game::Memory::operator bool()
        - nall: renamed view<string> back to `string_view`
        - nall:: implemented `array_view`
        - Game Boy: split cartridge-specific input mappings (rumble,
          accelerometer) to their own separate ports
        - Game Boy: fixed MBC7 accelerometer x-axis
        - icarus: Game Boy, Super Famicom, Mega Drive cores output internal
          header game titles to heuristics manifests
        - higan, icarus, hiro/gtk: improve viewport geometry configuration;
          fixed higan crashing bug with XShm driver
        - higan: connect Video::poll(),update() functionality
        - hiro, ruby: several compilation / bugfixes, should get the macOS
          port compiling again, hopefully [Sintendo]
        - ruby/video/xshm: fix crashing bug on window resize
            - a bit hacky; it's throwing BadAccess Xlib warnings, but they're
              not fatal, so I am catching and ignoring them
        - bsnes: removed Application::Windows::onModalChange hook that's no
          longer needed [Screwtape]
  29. 21 Aug, 2018 1 commit
    • Screwtape's avatar
      Update to v106r58 release. · f9adb4d2
      Screwtape authored
      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
  30. 10 Aug, 2018 1 commit
    • Screwtape's avatar
      Update to 20180809 release. · 9a6ae6da
      Screwtape authored
      byuu says:
      The Windows port can now run the emulation while navigating menus,
      moving windows, and resizing windows. The main window also doesn't try
      so hard to constantly clear itself. This may leave a bit of unwelcome
      residue behind in some video drivers during resize, but under most
      drivers, it lets you resize without a huge amount of flickering.
      On all platforms, I now also run the emulation during MessageWindow
      modal events, where I didn't before.
      I'm thinking we should probably mute the audio during modal periods,
      since it can generate a good deal of distortion.
      The tooltip timeout was increased to ten seconds.
      On Windows, the enter key can now activate buttons, so you can more
      quickly dismiss MessageDialog windows. This part may not actually work
      ... I'm in the middle of trying to get messages out of the global
      `Application_windowProc` hook and into the individual `Widget_windowProc`
      hooks, so I need to do some testing.
      I fixed a bug where changing the input driver wouldn't immediately
      reload the input/hotkey settings lists properly.
      I also went from disabling the driver "Change" button when the currently
      active driver is selected in the list, to instead setting it to say
      "Reload", and I also added a tool tip to the input driver reload button,
      advising that if you're using DirectInput or SDL, you can hit "Reload"
      to rescan for hotplugged gamepads without needing to restart the
      emulator. XInput and udev have auto hotswap support. If we can ever get
      that into DirectInput and SDL, then I'll remove the tooltip. But
      regardless, the reload functionality is nice to have for all drivers.
      I'm not sure what should happen when a user changes their driver
      selection while a game is loaded, gets the warning dialog, chooses not
      to change it, and then closes the emulator. Currently, it will make the
      change happen the next time you start the emulator. This feels a bit
      unexpected, but when you change the selection without a game loaded, it
      takes immediate effect. So I'm not really sure what's best here.
  31. 09 Aug, 2018 1 commit
    • Screwtape's avatar
      Update to 20180808 release. · 1e4affe5
      Screwtape authored
      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
      The code is courtesy of Talarubi, I just botched it somewhere upon
      porting it to the newer version of ruby.