Classic Home v5 beta 5 — every list scrolls, and the SNAC controls are where they belong

A firmware beta. The cores are unchanged — the FPGA side has not moved since
wave 3, so this does not
re-ship 322 MB of byte-identical .rbf files. If you are coming from beta 4 you already have them.

Installing

ClassicHome-v5-beta5.zip unpacks to SD-CARD-ROOT, whose contents mirror your card. Copy the
contents onto the card root and let it merge. Back up MiSTer first — copy it beside itself
as MiSTer.backup.

Every list scrolls now

Lists that grew past their panel used to just stop drawing. The row was still there and still
selectable — it simply never appeared. That is how Close Game came to be invisible at 240p, and
it was still true of the core options screen, where the PSX has 27 settings on one page and
about fifteen fit.

Both are fixed, and there is now a test that fails if any list at any screen size loses a row,
naming the screen. Both of the earlier cases were found by eye on a television, months apart.

The SNAC controls are in the core screen, with help

Pad1, Pad2 and SNAC MemCard used to be hidden — you had to leave Classic Home for the classic
OSD to get a light gun or real memory cards working. They are offered now, and each explains what
the selected value costs you, because that is where the difference lives:

Pad1	You get	You lose
Dualshock (and every other non-SNAC value)	Select+Start opens the menu; remappable	Light guns, wheels; memory cards are virtual
SNAC-port1	GunCon, NeGcon, wheels, rumble, real memory cards	The pad cannot open the menu

Who reads the SNAC port is no longer a setting of ours

snac_psx is gone, along with snac_psx_memcard and snac_psx_fallback. The core's own options
already said what you wanted, and we were overriding them — if you had deliberately set Pad1 to
GunCon, we stamped on it at every launch.

Now we read the port only when the running core has not claimed it, and that works for every
SNAC-capable core, not just PSX — the NES, Mega Drive, SNES, SMS and N64 each have their own SNAC
option, and turning any of them on hands that core the port. Changing your mind takes effect
immediately, with no relaunch.

If your card still has the old settings, the boot log names the replacement rather than ignoring
them quietly.

If something other than a PlayStation pad is on the SNAC port

Read this if you have a SuperDock and have used its bypass switch to route the SNAC bus to the
extension port, or have a SNES/Mega Drive/N64 adapter plugged in. We drive that port to read a
PlayStation pad, and on another console's adapter those pins land somewhere else:

snac_device=1     ; something other than a PlayStation pad is on the SNAC port

Nothing of ours will touch the port. We cannot detect this ourselves — nothing readable changes when
that switch moves. A wrong answer is not silent damage waiting to happen, though: a controller that
does not reply like a PlayStation pad is now refused rather than believed, where before it could
arrive as a pad with every button held down.

A fix worth calling out even though nothing on screen showed it

Core options whose bit spec the core writes in lowercase o form were read from, and written to,
the wrong place — 32 bits below where they live. So the row showed a value belonging to a
different setting, and changing the row changed that other setting instead. Silent in both
directions.

Affected rows you may actually have touched: Vertical Crop, Crop Offset, Orientation,
Flip Screen, Mapper, SMS BIOS, GG BIOS, Z80 Speed, SuperFX FastROM, VDPs,
PSGs, Gun Type. Making one of those a per-game setting was worse: it wrote over an unrelated
option's shared value, in a file you cannot inspect.

This was live in v4 and in every v5 beta before this one. If a core setting has ever behaved
oddly for you, this is a good candidate. Values written by the classic OSD were always correct —
it got this right and our screen did not.

Known limitations — please do not report these

• On S-Video and composite the menu is black and white. Games keep their colour; the colour
  encoder sits only on the core's video path. RGB SCART and YPbPr are in full colour.
• With an HDMI display attached the front-end leaves the analog output alone, so a CRT shows the
  game rather than the menu.
• No still picture behind the in-game menu over a disc game — you get black.
• Everything above 240p is verified in the test harness only. There is no HDMI display here.
• The SNAC ownership change is covered by tests but not yet confirmed on hardware — in
  particular snac_device=1 and handing the port to the core mid-game. That is the thing most worth
  reporting on.

Reporting a bug

Start with classicui/config-report.txt on the card. Then how your display is connected, whether
the set is PAL or NTSC, and what you saw. For a log, set debug=2 under [MiSTer] and copy
/tmp/debug.txt off the machine — note /tmp is a RAM disk inside the running MiSTer, not a folder
on the card.

If it goes wrong

Copy your MiSTer.backup over MiSTer. Or set classicui=0 for the stock menu with this firmware.