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.
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>
Most systems will use an accurate refresh rate calculated from display timing
N64, PS1, PC-Engine and Neo Geo Pocket use 50hz and 60hz until we determine how to calculate.
Ares checked each of the two input arguments to three-ops functions
separately, but this is not correct. Conditions causing unimplemented
operation on either input (sNAN, subnormal) take precedence on
conditions causing invalid operation on either input (qNAN).
After this fix, Ares passes n64-systemtest COP1 stress test.
Not required anymore, possibly for a long time. IPL3 does that, plus
this creates correctness issues with open source IPL3 which *doesn't*
initialize those memory locations.
I've lately discovered that misaligned PI DMA is also affected by RDRAM
writes that must cross RDRAM row boundaries (2048 bytes). It is obvious
in retrospect that the DMA implementation cannot generate a write burst
across different rows, so its internal buffering must be segmented on
RDRAM row boundaries.
The PI DMA testsuite has been updated to cover this edge case as well:
https://github.com/rasky/n64_pi_dma_test
Ares now passes the updated testsuite in full (timing aside, which is
close but not perfect).
ISViewer is currently gated by the homebrew mode flag. It seems like
this is not ideal for rom hackers because they would still need a way to
log but homebrew mode is too verbose for them and hide the ISViewer
messages in streams of actual problems in game code that they don't
intend to fix. So restore ISViewer functionality without homebrew mode.
Currently, the n64 core is limited to ROMs whose size is 63.9375 MiB
(also known as 64 MiB - 64 KiB). The reason is twofold: first, only 64
MiB are actually mapped in the PI bus; second, the last 64 KiB are
shadowed by the ISViewer debugging device.
ISViewer addresses sit in the last 64 KiB of the 64th MiB, so when the
ROM is larger than that (for instance, it is exactly 64 MiB), we should
simply disable ISViewer. In the long run, there will be a better
debugging solution which doesn't sit in the PI address space anyway.
Moreover, N64 supports basically ROM of unlimited size, there is no 64
MiB limit. This commit also allows that by simply mapping the whole ROM
into the PI address bus, whatever the actual size is.
When doing PIF HLE emulation, we run the HLE state machine just once per
frame. This is OK in general, but there can be a few situations where
this can cause PIF to miss one command from CPU. For instance, a ROM
might send the PIF boot termination command (0x8) and then shortly after
issue a SI DMA to identify controllers. If the two happen within the
same frame, our HLE emulation would miss the boot termination command.
This commit updates the HLE state machine also after each write to PIF
RAM.
To make sure to intercept all possible errors, the check are now
performed by the RDRAM module, whenever a RDRAM read/write behind a
cacheline happens.
CPU writes to cache is now tracking dirtyness at the byte level rather
than whole cacheline level, so that hardware accessing memory does not
trigger a false positive for false-shared variables. An initial round of
testing has shown that the check would trigger far too much otherwise.
Error reporting is also much improved to provide more context to analyze
the issue, including tracking the PC at which the hardware DMA was
triggered.
For RSP DMA, we do even more: instead of reporting an issue when area of
a cached memory is DMA into RSP DMEM/IMEM, we actually just mark those
memory locations as tainted, and emit the warning only if RSP later
reads them. This is necessary because it is extremely common for RSP
ucode to read data beyond the actual buffers it cares about, even though
that data is then never accesses.
Some of the warnings issues by Ares have been analyzed on Super Mario 64
and Zelda OOT and in both cases they have been confirmed to as real bugs
in cache management made by the game.
For instance, in Mario 64, the programmers forgot to invalidate the
cache before loading data for the initial Mario head animation, as
reported by Ares now:
```
[unusual] PI DMA writing to RDRAM address 0x390650 which is cached (missing cache invalidation?)
Cacheline was loaded at CPU PC: 0xffffffff80183b38
PI DMA started at CPU PC: 0xffffffff80328558
```
The game just happens to work because after loading, the game does
something else and manages to get the cache invalidated by touching
other locations, but otherwise it would be a real bug.
As another example, in Zelda OOT, we get these warnings at boot:
```
[unusual] AI reading from RDRAM address 190820 which is modified in the cache (missing cache writeback?)
Cacheline was loaded at CPU PC: ffffffff800b54fc
Cacheline was last written at CPU PC: ffffffff800b5528
[unusual] RSP reading from DMEM address fe0 which contains a value which is not cache coherent
Current RSP PC: d10
The value read was previously written by RSP DMA from RDRAM address 00199e40
RSP DMA started at RSP PC: abc
The relative CPU cacheline was dirty (missing cache writeback?)
Cacheline was loaded at CPU PC: ffffffff800b5244
Cacheline was last written at CPU PC: ffffffff800b5264
```
These warnings appear to be real bugs in the audio library. Quoting
Thar0:
```
* AudioHeap_ClearCurrentAiBuffer/AudioHeap_ResetStep wipe the AI buffers with CPU writes and
then don't write back the cache, and I guess an AI DMA is either in progress or starts before it can
be properly flushed. On boot this shouldn't matter as gAudioHeap is BSS and is already zero, but
if the driver is reset later it might cause some minor issues?
* The RSP cache coherency problems is from loading filters in AudioHeap_LoadLowPassFilter.
The heap allocator returns a pointer to which the CPU writes the filter data.. but the allocator
writes back the cache before the CPU writes the data 😂
```
Moreover, this PR also implements all the known SysAD-related CPU
freezes that cause the console to crash. We now pass the
[n64-systemcrash](https://github.com/rasky/n64-systemcrash) testsuite in
full.
In addition to approximating the correct values in SI STATUS fields,
this commit also fixes a bug: I/O writes to PIF RAM do trigger an
interrupt just like DMA does.
The CPU will freeze until power-off if a cached access is performed to a
non RDRAM area. This obviously never happens with games, but it is a not
so uncommon error when doing very low level development on the system.
This patch emulates the freeze for the data cache, and for the
instruction cache when using the interpreter. Implementation for
instruction cache and recompiler is left as a followup.
To prevent undue performance losses, the extra codegen only occurs when
tracing is enabled. To support toggling tracing on/off during execution,
the recompiler cache is flushed on setting changes.
Flushing the recompiler cache has its own side effects, but that's
already an issue, and it seemed the least bad way to isolate the impact
of this feature.
Add ability to enable/disable N64 4MB expansion pak.
Similarly to the video settings window, I've added a Nintendo 64
specific section in the options window, which was mostly empty. Existing
options fall under a generic "Emulator Options" section. Seems like a
reasonable place to add a few console specific options.
Addresses issue: https://github.com/ares-emulator/ares/issues/939
Level 2 warnings are considered "significant" and turning them on
revealed one issue that could, in the future, have affected MSVC-ABI
builds using either CL or Clang.
MSVC's C++ name mangling distinguishes between classes and structs, and
throughout the ares codebase there were friend declarations using
"class" to refer to types that were defined with "struct".
I don't see any value in retaining this inconsistency, especially
considering that ares otherwise avoids the "class" keyword (though I
spotted a few uses that crept in from recent commits).
- add more details to the dd time.rtc format as comments for readability
- fix dd rtc skipping december entirely (wrong comparison)
- I feel really dumb for this one.
- add validity checks on every rtc second tick to avoid glitchy rtc time
& date
- This also avoids the user to be able to skip the time & date error
into a glitchy rtc by simply restarting.
- add validity check on load if the time is valid or not, if not valid,
destroy the rtc info to get the user to input new rtc info
This adds:
- 64DD Disk Swapping for both 64DD standalone games and N64 Combo games
(only if a disk is loaded).
- Safety checks to prevent corruptions.
- Change manufacture timestamp and line to differenciate different disk
files from each other to avoid confusion
This PR adds a new general setting called "homebrew mode", that can be
used as an umbrella setting for all kind of developer-related aids in
the emulator. This will also allow resource intensives checks to be
added (eg: N64 RDP command list validation).
For now, we hook this to the N64 core only in two ways:
* ISVIewer emulation is now only performed in homebrew mode. This is
obviously not resource intensive, but it would have naturally been an
homebrew mode feature, if it existed at the time. Normally, games should
behave exactly like on a real N64, where there is no ISViewer peripheral
plugged in into the PI bus.
* A new cache coherency check is added to PI DMA. If a DMA is performed
to/from RDRAM locations for which the CPU holds a valid cacheline, a
warning is emitted to the console as the game is probably buggy.
Slightly unrelated, a commit also adds a new "DCache" memory viewer, to
see the memory from the point of view of the CPU (so with data cache
taken into account). This is useful to ROM hackers which don't care
about the physical RDRAM contents but rather the memory contents as
written by the CPU.
sljit performs a single (potentially) oversized executable memory
allocation before generating code. Instead of reserving the requested
amount of space, we can reserve only the used amount and eliminate some
dead space between code blocks.
In some cases sljit may write extra data beyond the generated code.
Because of this, it is no longer safe to assume the remainder of the
code cache is zero initialized. In practice, this assumption only
affected pools which can easily zeroed on demand. This also saves time
on code cache flushes, as we no longer zero the entire cache at once.
This PR adds a generic GDB server to ares with the ability to be used by
all systems.
For now only the N64 systems was implemented here.
Most documentation on how the server/TCP socket works can be found in
comments.
A detailed documentation for ares developers on how to add this to other
systems is included in the `Readme.md` file.
The feature itself was also already tested by a few people on both linux
and windows (with WSL) and seems to be stable now.
On Windows and Linux, ares uses a buffer in the bss section for the
recompiler code cache. On macOS this buffer must be dynamically
allocated for security reasons. The distance between the code cache and
the rest of the ares executable has a large influence on performance on
all platforms because there are microarchitecural thresholds beyond
which branches will never be correctly predicted by the CPU.
To make performance more consistent on macOS, we can make this dynamic
allocation sooner, at the top of main(), before the address space has
become too cluttered with allocations made by other code.
In addition to detecting the pattern `beq 0,0,<pc>` for idle loops,
detect the pattern `j <pc>`.
From a selection of about 60 games, about half used beq, a quarter used
jump, and a quarter had nontrivial idle loops.
Additionally, this commit returns the step time for idle loop
acceleration to 64 CPU cycles (128 system cycles). This was accidentally
halved in commit ffcce5823c.
Some instructions should complete faster for simple inputs (notably
mul), but this is not yet implemented. The extra cycle delay imposed by
the next instruction depending on the output of the previous is also not
implemented, as there is currently no framework for emulating pipeline
effects in the main CPU.
守矢諏訪子
Giovanni Bajo