Skip to content

feat(accuracysnes): a headless ares host — builds and links, does not yet run - #303

Merged
doublegate merged 1 commit into
mainfrom
feat/ares-headless-host
Aug 1, 2026
Merged

feat(accuracysnes): a headless ares host — builds and links, does not yet run#303
doublegate merged 1 commit into
mainfrom
feat/ares-headless-host

Conversation

@doublegate

Copy link
Copy Markdown
Owner

Committed labelled as incomplete. build.sh produces a linked binary; running it against the cart dumps core during setup. What is finished is the part that was recorded as the blocker.

Why this matters

Several findings are stuck at 2 versus 1 with no tiebreaker, because this project's own provenance rule counts ares and bsnes as one reference:

  • A2.10 — Mesen2 fails it, RustySNES and snes9x pass, and it is deliberately not recorded as settled because a harness bug upstream of every implementation produces the same signature (and one did — the $F8/$F9 retraction).
  • OBJ/screen interlace field parity — RustySNES's row + field and its $213F bit 7 are both ares', so this is the bsnes/ares lineage against the other two rather than RustySNES alone.

Both name the same missing thing: ares actually running the cart. The recorded reason it had not happened was that ares would have to be built and had no headless mode.

What is now established

ares' SFC core builds standalone yes-DARES_CORES=sfc, ~76 targets, a couple of minutes
a headless host compiles against it yesares::Platform is a small interface whose methods all have no-op defaults
it links yes
the results block is reachable yes, by constructionares::SuperFamicom::cpu.wram[0xF000 + n]
it runs the cart no — dumps core during setup

So the feasibility question is answered, and what remains is bounded debugging. The README names the three likely causes in the order worth trying.

Two traps the recipe records

  • hiro is not optional for a headless host. mia/mia.hpp includes it, and its generated resource/resource.hpp does not exist until hiro has been built once.
  • nall/main.hpp must be included by the host translation unit. It emits ::main only when NALL_MAIN_IMPL is undefined, and nall's own main.cpp.o defines that. Omit it and the link fails with a bare undefined reference to 'main' out of crt1.o, which reads like a missing object file rather than a missing shim.

Scope

Docs plus two new files under scripts/accuracysnes/ares_host/. Nothing in the build, the emulator, or any gate is touched; ref-proj/ is not modified.

🤖 Generated with Claude Code

… yet run

Several findings are stuck at 2-versus-1 with no tiebreaker, because this
project's provenance rule counts ares and bsnes as ONE reference: A2.10, and
the OBJ-interlace field parity where RustySNES's `row + field` and its $213F
bit 7 are both ares'. Both name the same missing thing -- ares actually
running the cart -- and the recorded reason it had not happened was that ares
would have to be built and had no headless mode.

The first half of that is now known to be cheap. -DARES_CORES=sfc configures
and builds the SFC core standalone in a couple of minutes; ares::Platform is a
small interface whose methods all have no-op defaults, so a headless host is
~120 lines; it links; and the cart's results block is reachable by
construction at ares::SuperFamicom::cpu.wram[0xF000 + n]. What remains is a
crash during setup, which is a bounded debugging job rather than a feasibility
question.

Committed labelled as incomplete, because the recipe is the deliverable: the
next attempt starts from a linked binary instead of from "ares would need
building". Two traps are recorded in build.sh because each cost a round --
hiro is not optional for a headless host (mia/mia.hpp includes it, and its
generated resource header does not exist until hiro has been built once), and
nall/main.hpp must be included by the host translation unit or the link fails
with a bare `undefined reference to 'main'` from crt1.o, which reads like a
missing object rather than a missing shim.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings August 1, 2026 09:40
@coderabbitai

coderabbitai Bot commented Aug 1, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@doublegate, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 5eff9eda-ba0f-4af0-9377-cbbf9670aaf9

📥 Commits

Reviewing files that changed from the base of the PR and between 390848e and 8f1481d.

📒 Files selected for processing (4)
  • CHANGELOG.md
  • scripts/accuracysnes/ares_host/README.md
  • scripts/accuracysnes/ares_host/ares_host.cpp
  • scripts/accuracysnes/ares_host/build.sh

Comment @coderabbitai help to get the list of available commands.

@github-actions

github-actions Bot commented Aug 1, 2026

Copy link
Copy Markdown

Antigravity review (Gemini via Ultra)

This PR adds an incomplete C++ host harness and build script under scripts/accuracysnes/ares_host/ to link against the ares SFC core for running AccuracySNES test ROMs.

Blocking issues

  • scripts/accuracysnes/ares_host/ares_host.cpp:L60: port->name().find("2") evaluates to npos (non-zero) when "2" is not present in "Controller Port 1". In C++, non-zero values convert to true, causing Controller Port 1 to incorrectly select PAD2_CONTRACT instead of PAD_CONTRACT. Change the condition to check against npos (e.g. port->name().find("2") != string::npos or port->name() == "Controller Port 2").

Suggestions

  • scripts/accuracysnes/ares_host/ares_host.cpp:L103: port->allocate() is called without specifying the cartridge pak type. Pass the cartridge medium name (e.g., port->allocate("Super Famicom Cartridge") or platform_.game->name()) so the SFC core connects the loaded ROM node during setup instead of dereferencing a missing slot.
  • scripts/accuracysnes/ares_host/build.sh:L23-L25: Directly referencing Ninja internal object paths (nall/nall/CMakeFiles/nall.dir/main.cpp.o) is brittle across different CMake/Ninja releases. Build nall as a static library target instead.

Nitpicks

  • scripts/accuracysnes/ares_host/ares_host.cpp:L50: The method argument input is shadowed by auto button = input->cast.... Rename the local button or argument to avoid shadowing.
  • CHANGELOG.md:L14-L31: The changelog entry contains extensive narrative around WIP debugging steps. Keep changelog entries focused on user-facing additions or test harness state.

Automated first-pass review by agy on a self-hosted runner -- not a human review.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new, headless ares host prototype under scripts/accuracysnes/ares_host/ to establish that ares’ SFC core can be built standalone and linked into a minimal runner that can (eventually) execute the AccuracySNES cartridge and read its WRAM results block for cross-validation.

Changes:

  • Add a build recipe (build.sh) that configures/builds the ares SFC core and links a small C++ host binary.
  • Add the headless host implementation (ares_host.cpp) that wires ares::Platform, runs for a frame budget, and prints the AccuracySNES results block in the existing runner output shape.
  • Document current status/known traps in a new README, and record the milestone in CHANGELOG.md.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
scripts/accuracysnes/ares_host/README.md Documents purpose, current incomplete status, and likely crash causes/traps for debugging.
scripts/accuracysnes/ares_host/build.sh Build/link recipe for a minimal headless ares SFC host binary.
scripts/accuracysnes/ares_host/ares_host.cpp Headless ares host that drives the core and dumps the AccuracySNES WRAM results block.
CHANGELOG.md Records the new headless ares host milestone and its motivation (third reference feasibility).

OUT=${OUT:-${TMPDIR:-/tmp}/ares_host}
HERE=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)

[[ -d $ARES ]] || { echo "no ares clone at $ARES — set REF_PROJ" >&2; exit 1; }
@doublegate
doublegate merged commit 5482eb3 into main Aug 1, 2026
15 checks passed
@doublegate
doublegate deleted the feat/ares-headless-host branch August 1, 2026 10:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants