О, прикольная статистика, она заметно усиливает подозрения в отношении S-CPU A, но автор немного неудачно подписал проценты. Это не вероятность отказа каждой ревизии, а доля неисправных чипов от всех 611 обслуженных консолей. Нам неизвестно, сколько среди 611 консолей было установлено S-CPU A, B и просто S-CPU.
Автор обслужил 611 SNES/SFC и обнаружил:
Все неисправные S-CPU 69 11,3%
S-PPU1 33 5,4%
S-PPU2 30 4,9%
Распределение 69 неисправных процессоров:
S-CPU 10 14,5%
S-CPU A 57 82,6%
S-CPU B 2 2,9%
однако все равно видно что отказов S-CPU B куда меньше, смотрите пикчу, что прикрепил.
и еще автор пишет, что более 200 восстановленных консолей он продал вместе с
качественными стабилизированными блоками Triad. За два с небольшим года вернулись только две консоли, причём одна пострадала от статического разряда, а у второй предположительно отказал CPU.
Ну и пользуясь случаем, вот вам еще одна ссылочка:
https://www.projectvb.com/nss/logs.htm и вот там уже есть действительно важный результат: неисправный CPU может проходить весь Burn-In
Например:
#16 -тесты пройдены, но некоторые игры зависали; замена CPU исправила плату;
CPU #13 -все тесты проходят, но не запускаются Street Fighter Alpha 2 и Yoshi’s Island;
CPU #16 и #25 — большинство игр не запускается, но тест проходит;
CPU #22 - тест проходит, но имеются ошибки спрайтов и зависания отдельных игр.
т.е. все операции, которые тест выполнил с использованными наборами данных и временными условиями, дали ожидаемый результат. Что бы сразу ответить на вопрос почему так, то вот по этому:
Burn-In не проверяет исчерпывающе:
все команды ядра 65C816;
все комбинации адресации;
каждый DMA/HDMA-сценарий;
все варианты прерываний;
поведение на границах тактов;
все линии контроллерных портов;
температурную стабильность;
редкие взаимодействия CPU, PPU, WRAM и картриджа.
