1. pass mmc3/3-a12_clocking.nes
2. refactor the ppu/var and ppu/scroll
3. fix ppu var and scroll read/write($2005/$2006/$2007)
4. inc serialization to v144
5. fix the color generator
6. fix the game Burai Fighter (USA)
7. pass issue #151
Currently, gdb is polled once per frame, which seems enough for
interactive usage. Some ROM hacks would like to use the gdb interface to
provide additional emulation-only features such as online multiplayer,
but that requires a faster turnaround.
A quick solution is to poll gdb more frequently within the n64 core.
This patch does that once per screen line, approximately. Notice that
the poll is only scheduled and run if there is a gdb client connected so
it should not cause any performance impact on normal users.
Just a small fix to account for the new video settings in Metal; the
threaded renderer, native fullscreen behavior and color space option.
These options were not fully persistent because the `videoDriverUpdate`
function (run on startup, among other times) did not account for them.
They would be set correctly in `settings.bml` and the settings object,
but would never actually be set correctly on the driver struct.
Co-authored-by: jcm <butt@butts.com>
* The behaviour of bits 0-3 and 7 in the control/status port were a
complete guess and had no reflection in hardware testing. They have been
adjusted to match hardware.
* The EEPROM interface always writes and reads out 16 bits to/from the
EEPROM, including the initial zeroes in the command value. The M93LCx6
code has been updated to support this case in line with the datasheet.
* The read and write data port have been separated. This was a detail
which every community documentation in existence got wrong, so no
worries about that one ^^
* Internal EEPROM protection has been implemented.
* The handling of invalid control commands (more than one bit set) has
been fixed.
* Emulation of the 93C46-family internal EEPROM on SPHINX in ASWAN mode
has been implemented. In particular, this fixes running any mono
WonderSwan game which takes advantage of the internal EEPROM on the
WonderSwan Color system's compatibility mode.
All of these changes pass the relevant tests in
[ws-test-suite](https://github.com/asiekierka/ws-test-suite)
(mono/eeprom/internal.ws) both as a WonderSwan and a WonderSwan Color.
This isn't 100% accurate (particularly, timing is not reflected; but
there are also some questions about more edge case-y behaviour), but
it's much closer.
The paraLLEl-RDP build was broken on macOS because of a change from
February to Granite in regarding platform ifdefs for pthreads.
A PR that applies a fix has been opened
[upstream](https://github.com/Themaister/Granite/pull/131), but until an
upstream fix lands, this PR will unbreak the build for ares without
needing to roll back the recent paraLLEl-RDP update entirely.
Co-authored-by: jcm <butt@butts.com>
Reduces the synchronization interval between the GBA CPU and other
components from 64 to 16 cycles, which significantly improves PPU
timings in the performance profile. These PPU timing improvements can be
observed in
[status-irq-dma.gba](https://github.com/nba-emu/hw-test/tree/master/ppu/status-irq-dma),
which now frequently gets results within a few cycles of the correct
values in situations which were previously off by dozens of cycles.
While this does impact performance by ~5-10%, in my testing this is
still faster than versions from before [commit
b145f0f](b145f0f000).
This PR improves handling of BIOS open bus edge cases that previously
were handled incorrectly, such as unaligned 8-bit and 16-bit accesses,
and cases where the last value read from BIOS was not a 32-bit value.
Compiling with GCC 14.1 in MSYS2 caused a lot of warnings of the
`-Wcast-user-defined` variety. This PR adresses that.
Note: This PR does not address
https://github.com/ares-emulator/ares/issues/1399 . Those warnings
happen at the link stage, they don't seem to be GCC-only (since issue OP
also reports them with clang), and they don't appear at lower
optimization settings (I tested `build=debug` and `build=stable` which
compiled cleanly).
pass blargg_ppu_tests_2005.09.15b/power_up_palette.nes
pass "Hello World" PPU test:
https://github.com/PeterLemon/NES/tree/master/HelloWorld
In https://forums.nesdev.org/viewtopic.php?t=567#top,
blargg say: "The power-up values of the palette are what my test program
reads back after powering the NES. I have one of the older units that
shows a green screen (I think newer front-loading ones had a gray
screen). These values probably vary slightly from one console to the
next."
Palette at power-up
0x09,0x01,0x00,0x01,
0x00,0x02,0x02,0x0D,
0x08,0x10,0x08,0x24,
0x00,0x00,0x04,0x2C,
0x09,0x01,0x34,0x03,
0x00,0x04,0x00,0x14,
0x08,0x3A,0x00,0x02,
0x00,0x20,0x2C,0x08,
To read/write a cgram, it needs to and 0x03, not 0x13
In https://www.nesdev.org/wiki/PPU_palettes#Memory_Map
$3F00 Universal background color
$3F10 Mirror of universal background color
$3F04 Normally unused color 1
$3F14 Mirror of unused color 1
$3F08 Normally unused color 2
$3F18 Mirror of unused color 2
$3F0C Normally unused color 3
$3F1C Mirror of unused color 3
For IPS patches that extend the original ROM beyond its initial size, we
will now resize the target buffer when patches extend the size of the
original.
Originally found testing out the Shin Megami Tensei patch by Orden
(https://www.romhacking.net/translations/2616/), which will now work
correctly.
Latches writes to timer registers for 1 cycle. This fixes common
off-by-one errors with precise timer use, which for example positively
impacts the test cases in #154.
This PR applies several minor fixes and improvements to macOS driver
settings and the driver settings pane.
#### Remove the "exclusive mode" video option on macOS.
* There is no real notion of exclusive presentation on macOS beyond what
already exists in normal fullscreen. If an application is covering the
screen and no other application or window is visible, the system
automatically switches to a "direct" presentation mode that optimizes
for single-application presentation performance. There is not a good
reason to show this option on macOS, even disabled.
* By contrast, it is possible (though not implemented by ares) to enter
exclusive mode on the audio device with CoreAudio, so leave that option
there, just disabled.
#### Add a "use native fullscreen" option on macOS.
* There are various good reasons to prefer either native platform
fullscreen behavior, or a custom borderless windowed fullscreen. Rather
than guess what the user wants, offer an option.
* If unchecked, make the window title bar enlarge the window rather than
fullscreen it, so we don't mix behaviors.
#### Implement fullscreen monitor selection behavior for Metal, and
correctly enumerate the user's monitor names.
* Fullscreen display on the selected monitor in the settings pane was
previously not implemented on macOS. This implementation only works if
"Use native fullscreen" is disabled, since the macOS fullscreen idiom
doesn't feature selecting a specific display.
* Additionally, the old function to retrieve the monitor's localized
name did not work reliably on newer macOS versions. Use the modern
property `localizedName` on NSScreen for macOS versions above 10.15, and
fall back to the old implementation otherwise.
* Implementing this meant adding a `uintptr` handle to the NSScreen
instance in the `Monitor` struct in ruby that uses a bridged cast to
interface with Objective-C. I would have preferred not to do this, but I
didn't see another good way to handle getting the `NSScreen` instance
that didn't involve a serious refactor.
#### (all platforms) Disable monitor selection if the video driver's
`hasMonitor()` is false.
* Just a minor fixup; the existing behavior is that the dropdown list
can be navigated and selected, but the selection does not persist. It
makes more sense to just disable it if the driver doesn't support it.
Co-authored-by: jcm <butt@butts.com>
- v2 will be unavailable from the end of June 2024
- v4 can be up to 98% faster than previous versions according to
[Github's
notification](https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/)
This PR only changes the version number, and I'm submitting it to see if
it works.
It is possible that further changes are necessary, as there were some
[breaking
changes](https://github.com/actions/upload-artifact?tab=readme-ov-file#breaking-changes),
but I don't think any of them apply to ares.
Testing:
- See if CI passes
- See if warnings regarding using v2 of `upload-artifact` and
`download-artifact` are gone (There will still be other warnings
regarding `checkout` and `cache`)
- (Optional) Compare times for the tasks using `upload-artifact` and
`download-artifact` with previous CI runs
Turns out the problem some folks experienced trying to load 64DD games
was due to run ahead not being disabled by default. An exception for
this system has been added.
#1463 renamed the `macos` build to `macos-latest` and introduced
`macos-compat`. We need to address the rename in the release workflow. I
believe this PR accounts for every use of the package name. Also adds
macos-compat to the release (for now).
Co-authored-by: jcm <butt@butts.com>
守矢諏訪子
曾耿森