<feed xmlns='http://www.w3.org/2005/Atom'>
<title>eglantine-cirakg/src/common/cpu_features.h, branch nx2</title>
<subtitle>Mirror of github.com/cira0100/Eglantine-public nx2, a fork of Djihads80/Eglantine.</subtitle>
<id>https://git.cirakg.xyz/eglantine-cirakg/atom?h=nx2</id>
<link rel='self' href='https://git.cirakg.xyz/eglantine-cirakg/atom?h=nx2'/>
<link rel='alternate' type='text/html' href='https://git.cirakg.xyz/eglantine-cirakg/'/>
<updated>2026-10-30T06:31:58+00:00</updated>
<entry>
<title>nx2: run the guest counter at 31.25 MHz for Switch 2 titles</title>
<updated>2026-10-30T06:31:58+00:00</updated>
<author>
<name>Takoroka</name>
<email>137927095+Takoroka@users.noreply.github.com</email>
</author>
<published>2026-10-30T05:55:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cirakg.xyz/eglantine-cirakg/commit/?id=0218eacfd560d0ce48b3ffe64d279ee85bbf1347'/>
<id>urn:sha1:0218eacfd560d0ce48b3ffe64d279ee85bbf1347</id>
<content type='text'>
The Switch 2 counter runs at 31.25 MHz and its SDK converts ticks with
that constant: Mario Kart World's sdk builds 31,250,000 in
nn::os::GetSystemTickFrequency, TickManager::ConvertToTimeSpan and
TickManager::ConvertToTick (19.2 MHz appears nowhere). Eglantine counted
at the Switch 1 rate for every title, so every tick-based time in a
Switch 2 game was off by 1.63x: elapsed times read short, and a deadline
of one 60 Hz frame converted to ticks waited ~27 ms.

The wall clock now has a guest counter frequency, set at boot: 31.25 MHz
for Switch 2 programs, 19.2 MHz otherwise, EDEN_NX2_CNTFRQ=&lt;Hz&gt; to force
one. CNTPCT reads, CNTFRQ_EL0, svcGetSystemTick, thread tick counts and
the time services' tick conversions follow it, and the CNTPCT spin
detection keeps its ~1.7 us threshold.

Mario Kart World, title screen and attract demo, 180 s, same build:
frame times unchanged (17-19 ms once warm), process CPU time 848 s
instead of 930 s.
</content>
</entry>
<entry>
<title>[common] Fix RDTSC nanosecond conversion (#4422)</title>
<updated>2026-09-17T17:50:19+00:00</updated>
<author>
<name>Feng Chen</name>
<email>vonchenplus@gmail.com</email>
</author>
<published>2026-09-17T17:50:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cirakg.xyz/eglantine-cirakg/commit/?id=0ce29be60874b24890ab9239cecf1bd67b924428'/>
<id>urn:sha1:0ce29be60874b24890ab9239cecf1bd67b924428</id>
<content type='text'>
Split the RDTSC ticks-per-nanosecond ratio into integer and Q0.64 fractional components. This avoids overflowing GetFixedPoint64Factor for TSC frequencies above 1 GHz while preserving the multiply-only conversion path.

Use the invariant clock only above 1 GHz because the reverse nanoseconds-per-tick factor cannot represent an exact ratio of one.

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.

-------------------

Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4422
Reviewed-by: lizzie &lt;lizzie@eden-emu.dev&gt;
Reviewed-by: MaranBr &lt;maranbr@eden-emu.dev&gt;
</content>
</entry>
<entry>
<title>[core/core_timing] better MWAITX and WAITPKG delays (#3984)</title>
<updated>2026-05-30T19:59:10+00:00</updated>
<author>
<name>lizzie</name>
<email>lizzie@eden-emu.dev</email>
</author>
<published>2026-05-30T19:59:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cirakg.xyz/eglantine-cirakg/commit/?id=7c32cf03a1ce2a88b5bda041a5aebc8405fe634d'/>
<id>urn:sha1:7c32cf03a1ce2a88b5bda041a5aebc8405fe634d</id>
<content type='text'>
This implements MWAITX and WAITPKG extensions (umonitor, mwait) for CPUs that support them.

Reduces wait times and bypasses the timing stuff from the OS that is slow (windows notably). generally it should answer within 0.2 to 0.5 microsecs (since most requests wait for that long).

Also does a general rework of static ctors and stuff

Signed-off-by: lizzie &lt;lizzie@eden-emu.dev&gt;
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3984
Reviewed-by: MaranBr &lt;maranbr@eden-emu.dev&gt;
Reviewed-by: crueter &lt;crueter@eden-emu.dev&gt;
</content>
</entry>
</feed>
