The Z80 does not converge from a cold power-on

[isenbek]

Recorded as an expectation in tests/chips.rs rather than asserted away.

6502  power-on: converged
6800  power-on: converged
z80   power-on: did NOT converge

"Did not converge" means the solver hit MAX_SETTLE_ROUNDS (100) without
reaching a fixed point. That cap matches the reference implementation, which
silently gave up; here it is counted in Stats::nonconvergent_settles.

What this is not

It is not evidence that the Z80 oscillates. These tests perform no
chip-specific initialisation, and visual6502 ships a support.js per chip that
does. The useful half of the result is that the engine runs a die twice the size
of the one it was developed against and reports the failure instead of hanging
or returning a plausible wrong answer.

The lead

cargo run --example inspect -- extern/visual6502/chip-z80 reports:

WARNING: 32 transistors are gated by the supply rail

The 6502 has none. A transistor gated by the supply is permanently on in
silicon and permanently off in this model, because group evaluation never
crosses a rail. Thirty-two of those is easily enough to change what the chip
settles to, and might be enough to stop it settling at all.

Nobody has tested this. It is a lead, not a cause.

Things worth trying

• Perform the initialisation support.js does for the Z80 and see whether it
  converges then.
• Identify which nodes are still changing at round 100 — if they are a small
  cluster, that names the structure responsible.
• Check whether the supply-gated transistors are near those nodes.

[isenbek]

Two concrete leads, from the reference's own per-chip code

Found while writing the 6502 site's page on the 27C3 talk. Both point the same
way: the Z80's non-convergence is very likely missing per-chip setup plus a
solver rule we do not have, not a defect in the settle loop.

extern/visual6502 ships a support.js for chip-z80 and chip-6800 and none
for the 6502. Our tests/chips.rs runs all three through
force_power_on_state() + restore_layout_pulls() + settle_all() and nothing
else, so whatever those files do, we are not doing it.

1. The Z80 needs pins held before it will settle

Its initChip() holds several control inputs inactive and sequences reset
around a recalc of the whole node list. Ours leaves them wherever the layout
pulls put them. Floating _wait / _busrq alone is a plausible cause of a
network that never reaches a fixed point.

Cheap to test: add an optional per-chip list of (pin, level) to the test
fixture, hold the Z80's control inputs inactive, and re-run.

2. The Z80 replaces the floating-group resolution rule

This is the more interesting one, and it is a library concern rather than a
test-fixture one.

support.js overrides the engine's getNodeValue() for the Z80. Rails and
pullup/pulldown are resolved as usual. The difference is the last case, a group
with no driver at all: the stock rule is "any node already high wins", and the
Z80's replacement instead takes the state of the node with the most
connections (gates plus terminals), as a standing proxy for which node holds
the most charge.

halfphi has that rule hard-coded. Our Drive ordering

Floating < ChargedHigh < PullDown < PullUp < Vcc < Vss

encodes the stock behaviour: ChargedHigh beats Floating, so any charged node
in an undriven group carries it. That is right for the 6502, whose two-phase
clock never floats a node long enough for the difference to show. It is
apparently not right for the Z80.

So the fix is probably not a Z80 special case but a policy seam: let the
caller choose how an undriven group resolves, with the current rule as the
default. Something like a FloatingPolicy passed to Engine::new, with
ChargeWins (today) and MostConnected variants.

That keeps halfphi/src free of chip names, which is the constraint that makes
this library worth having: the policy is chip-agnostic even though the choice
of policy is per chip.

Why this matters beyond the Z80

It is the first evidence that "the netlist alone specifies the complete working
of the chip" needs a footnote. The netlist plus a charge model specifies it,
and for one of the three dies we load, the charge model is not the default one.
Worth stating in the README either way, since it is exactly the kind of thing
that silently makes a simulator wrong rather than broken.

Not yet done

Neither lead has been tried. Filing the evidence while it is in hand.