Skip to content

v2.7

Latest

Choose a tag to compare

@Coder787-source Coder787-source released this 15 Aug 17:54
· 6 commits to main since this release

KytyPlus v2.7 — CPU Instruction Emulation + DualSense HID + Bandwidth-Aware iGPU Control
Tag: v2.7 · License: GPL-2.0

Downloads

  • Windows: KytyPlus-Windows-x64.zip
  • macOS: KytyPlus-macOS-x86_64.zip
  • Linux: KytyPlus-Linux-x86_64.zip

Unified PS4/PS5 Auto-Dispatch (New)
KytyPlus is the only emulator that runs PS4 and PS5 games in one window, automatically. When you load a game, KytyPlus reads the ELF and auto-detects whether it's a PS4 or PS5 title — no manual toggle, no settings menu. PS4 games dispatch to the embedded ShadPS4 core; PS5 games run through the native path. The window is unified (ShadPS4's output is reparented into Kyty's window on Windows), and save data is shared across both platforms in a unified user/ directory.

This is wired and build-verified across Windows/Linux/macOS. Honest caveat: the PS4 dispatch path has not been validated against a real PS4 game yet — the maintainer doesn't own a PS4 to dump games. The auto-detection mechanism is confirmed; the end-to-end PS4 gameplay is untested.

CPU Instruction Emulation (New)
The PS5's CPU is x86-64 (Zen 2), same ISA as the host — so most guest instructions run natively with no translation. But a handful of PS5-specific or AMD-specific instructions fault on hosts that lack them, or return values the guest doesn't expect. Until now, hitting one meant an illegal-instruction crash. v2.7 extends the existing fault handler to software-emulate these so guest code keeps running.

The newly emulated set:

  • RDTSC / RDTSCP — returns a PS5-consistent ~2.0 GHz timestamp counter instead of the host's clock, so guest timing math doesn't break
  • CPUID — intercepts hypervisor leaves (0x40000000 reports "SonyPS5", 0x40000001) so a guest probing for the hypervisor sees a PS5-consistent environment
  • XGETBV / XSETBV, RDMSR / WRMSR, RDPMC / RDPRU / RDPID, CLZERO, WBINVD / INVD, MWAIT
  • Descriptor-table / machine-status-word ops: LLDT / LTR / STR / LMSW / SMSW
  • Pre-existing MONITORX/MWAITX, SSE4a (EXTRQ/INSERTQ), and SHA-NI are kept

Why this matters: it's strictly additive — it only fires on instructions the host cannot run natively, so existing behavior is unchanged for everything else. It can't break a game that currently boots. The mechanism is self-validatable (trigger one of these instructions on your host and confirm you get an emulated value instead of a crash); the game-level benefit is not validated without a PS5.

DualSense HID Driver (New)
Previous KytyPlus builds used SDL's generic game-controller abstraction for pad input, and PadSetVibration / PadSetLightBar were no-op stubs that just logged. v2.7 adds a native DualSense HID driver wired into the real pad path (libs/controller.cpp + libPad.cpp).

On the input side, it parses native HID input reports and feeds them into the real ControllerButton / ControllerAxis flow that the SDL path already used:

  • Buttons and analog sticks
  • L2/R2 analog triggers
  • Gyroscope / accelerometer (IMU)
  • Touchpad (2 points)

On the output side, it constructs spec-accurate output reports:

  • Rumble motors
  • Lightbar RGB
  • Adaptive trigger effects (Feedback / Weapon / Vibration / Slope modes)

PadSetTriggerEffect, previously a log-and-return stub, now forwards to the driver. Windows uses real SetupAPI enumeration plus HidD_*/CreateFile/WriteFile on VID_054C & PID_0CE6; non-Windows (Linux/macOS) compiles as a no-op stub so cross-platform builds stay green.

This is implemented against the publicly documented DualSense HID protocol, not validated on a physical DualSense. USB-vs-Bluetooth report framing, feature-report handshakes, and trigger-resistance calibration may need adjustment once tested on a real controller.

Bandwidth-Aware Adaptive LOD Bias (New)
iGPUs like the reference platform's Radeon 780M share system DDR5 with the CPU — roughly 86 GB/s instead of the PS5's dedicated ~448 GB/s GDDR6. v2.7 adds an adaptive controller that reduces texture bandwidth pressure to fit the iGPU's actual budget.

The controller:

  • Monitors frame timing in the present path
  • Under bandwidth pressure (frame time over budget), increases the LOD bias so textures sample coarser mip levels — less memory traffic
  • With headroom, relaxes back toward the base bias to recover image quality
  • Invalidates stale samplers via a generation counter so the new bias actually takes effect
  • Uses hysteresis to avoid oscillation, and logs every decision for self-validation

MMIO Bus + NVMe LLE Foundation (New, infrastructure)
v2.7 adds a real MMIO bus subsystem (common/mmioBus.h/.cpp) — an address-range router for memory-mapped devices, thread-safe, registered in the main.cpp boot path. Alongside it, the NVMe controller is rewritten as an MmioDevice that talks to the real Kyty::Common::MMU (ReadBlock / WriteBlock) instead of a standalone fake RAM, so doorbell writes route through the MMIO bus into command processing and disk I/O.

This is real infrastructure wired into the boot path, but no HLE game routes doorbell writes through it yet. It's groundwork for a future LLE storage path, not a working storage replacement.

Ray-Tracing On-Ramp (New, enablement only)
rt/hardware.cpp's RT extension loading (AppendHardwareRayTracingDeviceExtensions and LoadHardwareRayTracingFunctions) was defined but never called from the real device-creation path. v2.7 wires them in so RT extensions actually enable on capable GPUs and RT device functions load.

This is enablement only:

  • RT shader translation (GCN ray-query ISA to SPIR-V OpRayQuery*KHR) is not implemented
  • Acceleration-structure translation from the PS5's proprietary format is not implemented
  • A game requesting ray tracing will not trace rays — full RT is blocked on undocumented PS5 BVH format reverse-engineering

EXIT Diagnostics (Improved)
When a game hits an unimplemented path, the previous behavior was a raw condition string plus a stack trace — "Not implemented (cmd_id != 0xc0016900)" — which tells a tester nothing useful. v2.7 upgrades 24 of the highest-impact guards to descriptive messages, e.g. "Not implemented: depth control: unexpected PM4 opcode header, expected 0xc0016900 (condition: cmd_id != 0xc0016900)".

Upgraded paths:

  • PM4 command handlers (AA config, blend color, clip control, color control, depth clear/control, HTILE surface, EQAA, guard bands, hardware screen offset, window offset)
  • Audio (audio out/in handles)
  • AGC (null buffers)
  • Shader (VGPR user_en flags)

Why this matters: this is no-regression (it only changes crash message text, not behavior) and directly improves tester log quality. A tester hitting an unimplemented path now gets a legible error they can file a useful issue with. It's backward-compatible — the old EXIT_NOT_IMPLEMENTED(x) macro is untouched, with a new EXIT_NOT_IMPLEMENTED_MSG(x, ...) overload added.

PUP Firmware Installation (New)
v2.7 wires the PUP firmware subsystem into the boot path. Previously the PUP parser existed but was never called; now it's reachable from the command line and runs at startup:

  • --install-firmware <pup> CLI flag — parses a .pup, optionally decrypts with user-supplied keys.bin, and extracts firmware modules to firmware/ps5/
  • FirmwareManager::Initialize() called at startup so previously-installed modules load at boot
  • SLB2 version check fixed to accept version 3 (Sony's newer firmware) as well as version 1
  • Nested-PUP recursion: detects inner .PUP entries and attempts to parse them as SLB2 containers

Validated against a real Sony PS5 firmware file: SLB2 parsing, inner payload extraction, and encryption detection confirmed working. Decryption + module extraction require user-supplied keys.bin (not provided by the emulator) and remain untested.

This is the first feature in KytyPlus validated against real Sony-distributed content — the PUP container parsing is proven working against a genuine firmware file downloaded from Sony's official servers.

Help test
This project's bottleneck is validation, not implementation. If you have a PS5 and can run a game:

All specs welcome — dGPU or iGPU. Reports are reviewed and added to COMPATIBILITY.md.

This is experimental software. "Boots to menu" is not "playable." You must legally obtain any game content you use with it.