Classic Home v6 beta 2 — cheats in the menu, and a video mode per core

Classic Home v6 beta 2

Two things a v6 beta tester asked for, and one of them changed how the front-end talks
to a display — so read the honesty section at the bottom before you install this on a
machine you need working.

"really great interface, i would just add cheats to core settings and its 100% gold,
and if possible ability to change resolution per core like 720x480i for GBA for that
3x integer scale on CRT"

Both are in. Firmware only — menu.rbf and the SNAC-rebuilt cores are unchanged
since v5.

---

Cheats

MiSTer has loaded your games' cheats for years; the only door to them was the classic
OSD, which is the thing this front-end replaces. Now there is a Cheats row in
Options while a game is running — and no row at all on a game whose pack has nothing,
rather than a row you cannot press.

You need MiSTer's cheat packs on the card (the Cheats folder, from the Downloader).

A switches a cheat on and the game changes while you are looking at it. X keeps
the set for that game, so it comes back next time you play it; X twice takes it
back. Toggling on its own is temporary and is forgotten when you close the game, which
is how MiSTer has always behaved — a cheat you switched on to look at something should
not follow the game around for ever.

Twenty-five thousand cheats

Some packs are enormous. Fire Emblem's is 25,087 entries and Mega Man Battle Network's
is 31,128, and almost all of that is a handful of cheats numbered over and over — 160
"Afas Drops", 176 "Sword". Throwing the duplicates away was the obvious move and it is
wrong: 31,032 of those 31,128 files have different contents, so they are different codes
that share a label.

So where a name repeats it becomes one row saying how many are on out of how many exist,
and A opens it. Fire Emblem's 25,087 come out as 367 rows:

A pack of twelve is still a list of twelve. There is no second way to navigate — the
folding simply does not happen when there is nothing to fold.

---

A video mode per core

What resolution one core comes up in, kept separately from every other core.

The reason to want it is integer scaling, and the request states it exactly. A Game Boy
Advance draws 160 lines. At 720p MiSTer's integer scaler fits four of them into 720 and
leaves bars; at 480p it fits three into 480 exactly and fills the screen. Nothing here
scales anything — vscale_mode=1, "integer scale only", is already MiSTer's default. All
this does is hand the scaler a height that is a whole multiple of the core's, and the
footer tells you which you are choosing:

Two corrections to the request, said plainly. 480i is not available — MiSTer's
video_mode has no interlaced form at all, and 480p is the same 3×. And under
direct_video the setting does nothing whatever, because the core's own timing goes
straight out of the DAC; the screen says so rather than offering you a choice that
changes nothing.

Why this is safe to offer, when the settings screen refuses it

video_mode is one of a handful of settings Classic Home deliberately will not let you
edit, because a wrong value is a black screen and a card that has to come out and go into
a PC. That still stands for the global setting. Three things make the per-core one a
different question:

• Your shelf is never affected. The setting is scoped to one core's section, so the
  menu always comes up in the machine's normal mode. Whatever a game looks like, you can
  always get back to a screen you can read and change it.
• Nothing is written until you have seen it work. Pressing A applies the mode and
  starts a fifteen-second countdown reading "Can you see this?". Press A again and
  it is saved. If you cannot see it — do nothing. After fifteen seconds the old mode comes
  back and no file has been changed.
• The list is seven standard 60 Hz modes, no 50 Hz and nothing exotic. The DE10-Nano's
  EDID is empty, so nothing can ask your display what it accepts; a short list makes a lost
  picture unlikely and the countdown makes it survivable when it happens anyway.

Automatic is the way back, and it takes the line out of MiSTer.ini rather than
blanking it.

The setting is written into a [<core>] section of your own MiSTer.ini — the same line
you could have typed yourself — so it keeps working with classicui=0, and the rest of
your file is copied through byte for byte with a backup kept as MiSTer.ini.bak.

---

Also in this build

• Where cover art comes from is written down. ART.md,
  shipped in the archive: the four places a cover can come from and why they are tried in
  that order, what the two files in classicui/ remember and why, how a disc is matched
  (by product number, exactly — a serial sent as a name is fuzzy-matched and answers
  confidently wrong), and where to look when something is off. The short version people
  keep asking for: the folder art is downloaded into is the same folder art is looked
  for in. There is no separate cache.
• Two settings that existed and were documented nowhere now have their lines in the
  commented MiSTer.ini: classicui_halfres — which defaults to on, so it is the mode
  everybody boots into — and classicui_ss_replace_pack.
• Two menu-bar labels are shortened at 240p where they were being cut, on a handheld core
  over analog.

---

Installing

ClassicHome-v6-beta2.zip unpacks to SD-CARD-ROOT, whose contents mirror your card.
Copy that folder's contents onto the card root and let it merge.

Back up MiSTer first — copy it beside itself as MiSTer.backup. That is your way
back, and it is also the only way to tell whether a problem is ours: turning a Classic
Home option off still leaves you running our binary.

If you are installing on a fresh card, take v5
first for menu.rbf and the SNAC cores, then this on top.

Firmware md5 98cadfa47dffdadb31df95f47a69104a — the same binary every test below ran
against.

---

What was tested, and what was not

This project's rule is that "tested" only ever describes checks that actually ran against
the binary being shipped. Everything else is named.

Automated: 3,238 host checks at zero failures, and 98 in the packaging suite. Nineteen
deliberate breaks were introduced and watched fail for their own reasons — the gate on the
cheats row, the folding, the refusal when a core is full, the two-press forget, re-applying
by name instead of by index, the countdown, the confirm, the section-aware ini writer, and
the rest. One of the nineteen came back green and had to be rewritten, which is the point
of doing it.

On hardware: the Cheats row on a real pack; Fire Emblem's 25,087 entries folding to 367
rows, the same number the host model computes from the same zip; opening a group and reading
its codes; switching a cheat on and off with the firmware's own log confirming the codes
reached the core both ways; and the Video Mode screen correctly refusing on a machine where
the setting would do nothing.

The video mode, end to end. An HDMI sink went on the test machine after the first build
of this release, and it immediately found a bug that would have made the whole feature
useless — so the binary above is not the one this release first carried. Changing the mode
reprograms the HDMI transmitter, the display re-asserts hotplug, and MiSTer's re-init put
the configured mode straight back about a second later. The countdown was still running
with nothing left to confirm, and no press could have kept it. That is not specific to one
display: moving the pixel clock is exactly what makes a sink re-assert HPD.

A mode set at runtime now survives that re-init, bounded by the same countdown. Verified on
hardware afterwards, from the firmware's own log:

• the mode applies and the front-end re-lays out at the new canvas;
• it survives the hotplug it caused;
• fifteen seconds with no press puts the configured mode back, which is the whole safety
  argument;
• a second press writes video_mode=2 into a [GBA] section — four lines appended to a
  450-line file, with [MiSTer] video_mode=8 untouched;
• Automatic removes exactly that one line again.

And the scale the feature exists for, measured from the scaler's own header rather than by
eye: a 240×160 Game Boy Advance at 1080p is drawn 1440×960 — six times up, with 120
lines of black bars. At 720×480 it is drawn 720×480 — three times up on both axes, no
bars. That is the report's "3× integer scale", and the screen tells you so while you are
choosing it.

Still not tested on hardware, and you should know which:

• That a display actually shows it. The sink here is an EDID dongle, not a screen. The
  modes are applied, the geometry is right and the countdown recovers — but nobody has
  looked at one of these modes on a television or a CRT, which is the last mile and the
  one the report was about.
• That a cheat changes the running game. The pack loads and the core receives the codes —
  that much is in the log, both directions — but nothing here got a game past its title
  screen to photograph the difference. The hop past that point is MiSTer's own cheat engine
  and is untouched by this change, but it is not proven.
• A controller. Every press in the hardware session was injected down /dev/MiSTer_cmd,
  which travels the front-end's own key path. A pad reaches it through a different one, and
  a keyboard-driven pass has hidden a total pad failure in this project before.

That is why this is a beta rather than a release. If you try the video mode on a real
display, the most useful thing you can tell me is whether the picture is what the footer
promised — and, if you pick a mode your display cannot show, whether it came back on its
own after fifteen seconds.