fix: verify the POPS runtime by content, not just by presence - #64
Merged
Conversation
A drive whose POPS.ELF was a completely different file reported "PS1 READY", and every PS1 title black-screened and returned to the console browser. Nothing in the symptom pointed at the emulator: the VCDs verified byte-perfect against cue2pops, the launchers were byte-identical copies of POPSTARTER.ELF, OPL found and executed them, and stripping a title's name to something trivial changed nothing. The runtime check only listed the directory. POPS.ELF was 137,045 bytes where the real one is 3,166,988, and IOPRP252.IMG was 1,306,134 where the real one is 265,233 -- not corrupt copies, different files -- and "OK" was reported for both. CheckRuntime now hashes what it finds. POPS.ELF, IOPRP252.IMG and the two packages have one published release each that does not vary between POPStarter revisions, so they can be checked exactly. POPSTARTER.ELF changes with every revision and is deliberately left unhashed rather than guessed at. A file that is present but wrong is reported as wrong -- not as missing, which would send someone looking for a file that is already there, and not as OK. It reads WRONG FILE in the table, it makes the status NOT READY, and the explanation says what it means: every PS1 title fails identically with the wrong one, and nothing else in the setup will show why. POPS.PAK and POPS_IOX.PAK join the manifest so they are imported and reported. They are not marked required, because a setup without them is not necessarily broken and calling a working drive NOT READY would be worse than saying nothing. The hashes are the published ones, corroborated independently by the POPStarter documentation site and by PS2-HOME; ps2hdd carries no Sony code, only the means to tell whether yours is the real thing. Claude-Session: https://claude.ai/code/session_018eBAB3V9GRxNwgpQcpGje4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A drive whose
POPS.ELFwas a completely different file reportedPS1 READY, and every PS1 title black-screened and returned to the console browser.Nothing in the symptom pointed at the emulator. Ruled out first, in order: the VCDs (byte-identical to
cue2popsoutput), the launchers (byte-identical copies ofPOPSTARTER.ELF), OPL's launch path (it opens the ELF and only launches on success), the disc grouping, and the naming — stripping a title's name toSPYROchanged nothing.The runtime check only listed the directory:
POPS.ELFIOPRP252.IMG23× too small and 5× too big. Not corrupt copies — different files. Both reported
OK.Change
CheckRuntimenow hashes what it finds.POPS.ELF,IOPRP252.IMG,POPS.PAKandPOPS_IOX.PAKeach have one published release that does not vary between POPStarter revisions, so they can be checked exactly.POPSTARTER.ELFchanges with every revision and is deliberately left unhashed rather than guessed at —TestCheckRuntimeDoesNotHashThePOPStarterLauncherpins that.A file that is present but wrong is reported as wrong — not as missing, which would send someone hunting for a file that is already there, and not as OK:
POPS.PAKandPOPS_IOX.PAKjoin the manifest so they are imported and reported. They are not marked required — a setup without them is not necessarily broken, and calling a working drive NOT READY would be worse than saying nothing.Provenance of the hashes
ps2hdd carries no Sony code, only the means to tell whether yours is the real thing. The MD5s corroborate across three independent sources, and the SHA-256s come from the same published table:
POPS.ELF355a892a…355a892a…355a892a…IOPRP252.IMG1db9c602…1db9c602…1db9c602…POPS_IOX.PAKa625d0b3…a625d0b3…POPS.PAKis single-source, which is why it is not required.Tests
TestReadinessRejectsAWrongRuntimeFile— a drive with one wrong file is NOT READY, names that file, does not call it missing, and explains the consequence.TestCheckRuntimeRejectsWrongContents— wrong is distinguished from missing at the check level.TestCheckRuntimeDoesNotHashThePOPStarterLauncher— the one file that legitimately varies is never called wrong.scripts/demo-smoke.shpreviously asserted that importing placeholder files makes PS1 support READY. It now asserts the opposite, through the real CLI — that was the assertion encoding the bug.No test can hold Sony's binaries, so the manifest is pointed at a placeholder's hash where the ready path needs exercising; that swap is a helper with the reason written down.
Full suite,
go vet,gofmtand the smoke test pass.https://claude.ai/code/session_018eBAB3V9GRxNwgpQcpGje4