Commit Graph

211 Commits

Author SHA1 Message Date
Tim Allen 7ec3077079 Revert "nall: Add needed #include <stdexcept>"
This reverts commit e658f50da2.

bsnes' compatibility with GCC 13 was already fixed in a different way in
5cefce5c08.
2023-06-10 19:22:40 +10:00
Tim Allen e658f50da2 nall: Add needed #include <stdexcept>
Taken from ares commit 6a7898396a14eef257e63cd002fb26ffbf6e2581

Apparently this is needed by GCC 13.
2023-06-08 22:01:59 +10:00
orbea 5cefce5c08 nall: Fix the build for gcc13 2023-03-08 17:35:32 +11:00
Benjamin FRANCOIS 6fc6bf14a3 Allow Haiku build of libretro target 2021-10-31 20:39:10 +11:00
Rupert Carmichael 063e645ff2 nall: File timestamp fix for OpenBSD and DragonFly BSD, add DragonFly BSD to PLATFORM_BSD definition 2021-08-01 14:50:01 +10:00
Morilli 41f30f348a Remove unnecessary WIN* defines.
We keep WINVER and _WIN32_WINNT because different versions of mingw-w64 have different defaults.

Fixes #198.
2021-07-28 15:09:19 +10:00
Morilli 64d484476d Fix vector<T>::acquire() arguments 2021-05-26 17:02:48 +10:00
Near 55e05c89c2 Fix critical undefined bit-shift length operation
Natural/Integer<T>.bit() (BitRange) was shifting by whatever type the source was to match the target bit length.
But this breaks when the target type is u64/s64 and the source type is u32/s32 or smaller. Shifting by >=32 becomes undefined behavior.
We have to cast the input source to the target type first, so that the source<<shift result is valid.
This is safe here regardless of source's signedness, because it's only used in =, &=, ^=, |= operations.
2021-04-14 22:55:36 +10:00
Ghislain Antony Vaillant 7a1d16bb3b Use XDG base directories 2020-11-10 17:59:14 +11:00
Tim Allen 216bcee66b nall: Support all the names endian.h provides on common platforms.
Also, moved the snippet that includes endian.h beneath the "Endian detection"
header, since I think it fits more neatly there.

Fixes #77.
2020-11-04 15:50:23 +11:00
jsd1982 9d262ed113 nall: fix bad memory access pattern in string.format 2020-10-28 18:35:28 +11:00
Alcaro b9ccb90324 GNU Make 4.3 compatibility
* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.

https://lwn.net/Articles/810071/
2020-09-19 23:22:13 +10:00
byuu d2211d8818 v114.5
* improved appended firmware detection [devinacker]
* added dynamic rate control support to ALSA and PulseAudio drivers [RedDwarf]
* added option to use native file dialogs
2020-02-23 20:23:25 +09:00
byuu c6918fc170 Fix "make clean" when using cmd.exe shell on Windows 2020-01-16 05:40:55 +09:00
byuu a64c1adaa8 v112.11
SFC: Disable color blending for first hires pixel with accuracy PPU
(fixes a green scanline on the left-edge of Jurassic Park)
libco: Don't include <sys/mman.h> when not using mprotect
nall: Detect Windows without invoking uname [Alcaro]
2019-12-02 19:54:03 +09:00
byuu 6b7e6e01bb v111.8
Serialize SDD1 decompressor
Major speedup to nall/serializer [Alcaro]
Removed fast PPU tile cache (major speedup for run-ahead mode)
2019-10-16 16:12:28 +09:00
Alcaro cd18cdb1d6 Optimize serialization stuff a bit 2019-10-15 20:29:04 +02:00
byuu 19f3cdfd5e v111.8
Added fully working deterministic save state support (non-portable.)
Rewind is now 100% deterministic, disk save states are still portable.
Added run-ahead support.
2019-10-15 22:12:10 +09:00
byuu e22167cf82 v111.1
More improvements to SameBoy audio interface for Super Game Boy.
Added a fix for a very rare crashing issue with SDL 2.0 joypad support.
2019-10-06 10:14:30 +09:00
byuu c6f92b782c Minor touchups. 2019-10-05 14:30:55 +09:00
byuu e3f2e634c8 Fixed audio crackling in Super Game Boy emulation. 2019-10-05 14:29:31 +09:00
byuu 18d2ab6435 v109.4
Rename hiro::Property to hiro::Attribute
Disable XChaCha20 CSPRNG on Android for now due to compilation issues
Add macOS IOKit joypad support [Sintendo]
2019-09-17 03:37:03 +09:00
byuu 1e626e75ef v109.3
Fixed crash when idling with the snow effect enabled.
Added Android target to libretro port [rtretiakov]
Various nall library improvements.
2019-09-13 22:15:11 +09:00
byuu 0b088b6b55 v108.9
* multi-monitor support
* improved pause/frame advance support
* added option to disable video dimming when idle
2019-08-16 19:44:16 +09:00
byuu 4d2244ed5f More macOS Cocoa improvements. 2019-07-27 01:27:56 +09:00
byuu 55799c4230 v107.11
* added cheat code support to Super Game Boy emulation
* added cheat code search support (not for Game Boy, sorry)
* compilation fixes
2019-07-22 01:39:32 +09:00
byuu 903d1e4012 v107.8
* GB: integrated SameBoy v0.12.1 by Lior Halphon
* SFC: added HG51B169 (Cx4) math tables into bsnes binary
2019-07-17 21:11:46 +09:00
Tim Allen d87a0f633d Update to bsnes v107r4 beta release.
byuu says:

  - bsnes: added video filters from bsnes v082
  - bsnes: added ZSNES snow effect option when games paused or unloaded
    (no, I'm not joking)
  - bsnes: added 7-zip support (LZMA 19.00 SDK)

[Recent higan WIPs have also mentioned bsnes changes, although the higan code
no longer includes the bsnes code. These changes include:

  - higan, bsnes: added EXLOROM, EXLOROM-RAM, EXHIROM mappings
  - higan, bsnes: focus the viewport after leaving fullscreen exclusive
    mode
  - bsnes: re-added mightymo's cheat code database
  - bsnes: improved make install rules for the game and cheat code
    databases
  - bsnes: delayed construction of hiro::Window objects to properly show
    bsnes window icons

- Ed.]
2019-07-07 19:44:09 +10:00
Tim Allen 4d7bb510f2 Update to bsnes v107.1 release.
byuu says:

Don't let the point release fool you, there are many significant changes in this
release. I will be keeping bsnes releases using a point system until the new
higan release is ready.

Changelog:

  - GUI: added high DPI support
  - GUI: fixed the state manager image preview
  - Windows: added a new waveOut driver with support for dynamic rate control
  - Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso]
  - Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering
  - Windows: fixed XInput controller support on Windows 10
  - SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4
    coprocessors
  - SFC: fixed a slight rendering glitch in the intro to Megalomania

If the coprocessor firmware is missing, bsnes will fallback on HLE where it is
supported, which is everything other than SD Gundam GX and the two Hayazashi
Nidan Morita Shougi games.

The Windows dynamic rate control works best with Direct3D in fullscreen
exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it
is not possible to target a single XAudio2 version on all Windows OS releases.
The waveOut driver should work everywhere out of the box.

Note that with DRC, the synchronization source is your monitor, so you will
want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync
monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 11:16:30 +10:00
Tim Allen fbc1571889 Update to v106r85 release.
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
right.

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.
2019-01-22 11:26:20 +11:00
Tim Allen 53843934c0 Update to v106r84 release.
byuu says:

Changelog:

  - 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]
2019-01-21 16:27:24 +11:00
Tim Allen 37b610da53 Update to v106r83 release.
byuu says:

Changelog:

  - 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.
2019-01-19 12:34:17 +11:00
Tim Allen 559a6585ef Update to v106r81 release.
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.
2019-01-16 13:02:24 +11:00
Tim Allen 25145f59cc Update to v106r80 release.
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.
2019-01-16 00:09:50 +11:00
Tim Allen 17fc6d8d51 Update to v106r79 release.
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.
2019-01-15 15:33:20 +11:00
Tim Allen 6871e0e32a Update to v106r78 release.
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.
2019-01-14 17:16:28 +11:00
Tim Allen bb1dd8c609 Update to v106r77 release.
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.
2019-01-13 17:25:14 +11:00
Tim Allen c9f7c6c4be Update to v106r76 release.
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,
BS1B.

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.
2019-01-11 12:51:18 +11:00
Tim Allen dbee893408 Update to v106r73 release.
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.
Sigh.
2019-01-07 18:59:04 +11:00
Tim Allen cb86cd116c Update to v106r72 release.
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!
2019-01-05 18:04:27 +11:00
Tim Allen 1a889ae232 Update to v106r71 release.
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.
2019-01-05 11:35:26 +11:00
Tim Allen aaf094e7c4 Update to v106r69 release.
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.
2019-01-02 10:52:08 +11:00
Tim Allen 3159285eaa Update to v106r68 release.
byuu says:

Changelog:

  - nall: converted range, iterator, vector to 64-bit
  - added (very poor) ColecoVision emulation (including Coleco Adam
    expansion)
  - 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.
2018-12-22 21:28:15 +11:00
Tim Allen 90da691717 Update to v106r67 release.
byuu says:

Changelog:

  - 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.
2018-12-21 11:01:14 +11:00
Tim Allen 4c4e79aa0e Update to v106r66 release.
byuu says:

Changelog:

  - moved to GCC 8.2 and C++17
  - fixed compilation under FreeBSD 12.0
  - don't read beyond the file size in
    SuperFamicom::Cartridge::loadMemory
  - 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,
however.
2018-12-20 11:55:47 +11:00
Tim Allen 03b06257d3 Update to v106r65 release.
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.
2018-10-04 20:12:11 +10:00
Tim Allen c58169945c Update to v106r63 release.
byuu says:
Changelog:

  - gb/mbc7: rewrote the 93LCx6 EEPROM emulation
  - sfc/slot/bsmemory: rewrote the flash emulation for Satellaview
    cartridges

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.
2018-09-11 21:16:58 +10:00
Tim Allen c2d0ed4ca8 Update to v106r62 release.
byuu says:

Changelog:

  - 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 ROM↔ROM, 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
    [hex_usr]
  - 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.
2018-09-10 12:11:19 +10:00
Tim Allen 3d34517f3e Update to v106r61 release.
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 CPU↔coprocessor 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.
2018-09-04 15:44:35 +10:00
Tim Allen a3e0f6da25 Update to v106r60 release.
byuu says:

I added (imperfect) memory conflict timing to the SA1.

Before:

  - WRAM↔↔ROM ran 7% too fast
  - ROM↔↔ROM ran 100% too fast
  - WRAM↔↔IRAM ran 7% too fast
  - ROM↔↔IRAM ran 7% too fast
  - IRAM↔↔IRAM ran 287% too fast
  - BWRAM↔↔BWRAM ran 100% too fast
  - HDMA ROM↔↔ROM ran 15% too fast
  - HDMA WRAM↔↔ROM ran 15% too fast
  - DMA ROM↔↔ROM ran 100% too fast

After:

  - ROM↔↔ROM runs 14% too fast
  - HDMA WRAM↔↔ROM runs 7% too fast
  - DMA ROM↔↔ROM 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.
2018-09-03 00:06:41 +10:00