Charges made while servicing a device are the device's own time, not CPU
instruction retirement. Scaling those too compressed DMA and peripheral work by
the same factor, which is not an overclock but a speed hack on the whole
machine. DuckStation overclocks the CPU alone and device delays keep their
real-world duration; same intent here.
Correct, but NOT the boot failure. Measured after the change, with 8 MB on:
100% and 300% boot; 400/600/800/900/1000% all reach frames but never enable the
display. So the threshold sits between 300% and 400%, far below the >900% that
hueponik's pal100full8 requires.
What the failure is not:
- not performance. Frames advance steadily at ~39/s throughout (455 -> 2574
over 54s) while the display stays off, on a host that runs DuckStation at
900% fine;
- not device-service scaling, per this commit;
- not a hang. The guest keeps running, it just never turns the display on.
Prime remaining suspect is the deferred-charge batching: g_psx_cyc_batch
accumulates RAW cycles against g_psx_cyc_batch_limit, but the charge is scaled
only at publish, so the batch limit and the scaled deadline comparison are in
different units. Devices would then be serviced progressively later as the
factor grows, which fits a threshold rather than a clean break. Untested.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tetrisgm
a11e38314d