3. Программно определить, что это Overdrive процессор невозможно. Специальный бит Overdrive команды CPUID не используется. Только две ранние версии (DX4ODPR75 и DX4ODPR100 v1.0) использовали этот бит. Похоже, для них создавался свой кристалл. В дальнейшем использовался кристалл штатных процессоров.
Фактически, это обычный DX4 3.3 вольт (CPUID 0480) с регулятором напряжения под радиатором (на фото).
4. Процессор имеет пассивное охлаждение и довольно сильно греется (TDP 5.4 Вт). Без нагрузки в чистом DOS температура радиатора достигает 64 градуса. При этом в Windows NT 4.0 температура намного ниже - 40 градусов. Очевидно, что планировщик Windows NT использует команду HALT во время простоя.

ASTRA for DOS 7.21 beta.

ASTRA for DOS 7.21 beta

Каждое поколение процессора имеет несколько моделей и может использовать разные ревизии ядра с исправленными ошибками. Хорошо бы знать точную ревизию процессора. Поэтому все процессоры от Intel 80386, выпущенного в 1985 году, до современных Core/Ryzen после аппаратного сброса содержат в регистре EDX специальный идентификатор. Этот идентификатор может прочитать BIOS, но он нигде не сохраняется и не доступен для прикладных программ. В некоторых версиях BIOS для IBM PS/2 и старых версиях AMI BIOS есть функция для получения идентификатора из прикладной программы, но я никогда не встречал такой BIOS.
Для решения этой проблемы в процессорах Intel Pentium в 1993 году появилась инструкция CPUID. Она возвращает производителя процессора, семейство, модель и степпинг. Фактически CPUID возвращает тот самый идентификатор из регистра EDX.
Постепенно эта инструкция появилась в новых вариантах 486 процессоров, а так же у других производителей.
Поддержка CPUID появилась в 1993 году у всех Intel 486DX/SX с поддержкой SL Enhanced (функция энергосбережения).
В процессорах AMD 486 поддержка CPUID появилась в версии Enhanced с Write-Back кэшем в 1994 году.
В процессорах Cyrix команда CPUID по некоторым источникам появилась в Cx5x86 в 1995 году, но по умолчанию она отключена. В эмуляторе 86BOX программно включить CPUID не удалось, настоящего Cx5x86 у меня для проверки нет.
Тем не менее, в процессорах Cyrix (начиная с Cx486SLC/DLC, 1992 год) есть свой механизм идентификации с помощью регистров конфигурации DEVID registers (DIR). Доступ к этим регистрам возможен из прикладной программы в любой момент (в отличие от идентификатора в регистре EDX, который так же присутствует в процессорах Cyrix).
Итак, в 1997 году когда началась разработка INFORMER (на Intel Pentium 166 МГц) процессоры без поддержки CPUID считались устаревшими, но еще использовались. Для определения старых процессоров использовалась сторонняя библиотека CPU/FPU feature detection library by B-coolWare. С исправлениями и модификациями эта библиотека используется в ASTRA до сих пор. Есть подозрение, что такие диагностические программы как NSSI и agSI тоже используют эту библиотеку.
Определение основано на анализе ошибок разных версий процессоров и попытке исполнения различных недокументированных команд, специфичных для данного производителя/модели. Точность определения такими методами не очень высокая. Но так как поддержка старых процессоров была сделана по остаточному принципу, то эта библиотека устраивала.
В 2000 году я увлекся ретро компьютерами, стал добавлять поддержку старого железа. В прошлой апрельской бете было добавлено определение sSPEC номера, коэффициента умножения и прочего процессоров семейства Intel 486. Разумеется, только SL Enhanced версий с поддержкой инструкции CPUID.
А как быть с более старыми процессорами Intel/AMD (с Cyrix проблем нет)?
Как я написал выше идентификатор процессора в регистре EDX появляется только после сброса процессора. Казалось бы, невозможно сбросить процессор и остаться в своей программе. Оказалось, что можно.

Историческая справка:
В 286 процессоре появился защищенный режим процессора. Перейти в него довольно просто, подготовив таблицу дескрипторов и установив всего один бит в служебном регистре CR0. А вот вернуться назад в реальный режим средствами процессора невозможно (в 386 процессоре это исправили). Поэтому разработчикам IBM PC/AT пришлось делать костыли для возврата в реальный режим без перезагрузки.
После выполнения сброса процессор передает управление BIOS, который анализирует байт отключения 0Fh в CMOS памяти. Если в этом байте записан 0, то происходит обычная теплая (без тестирования железа) перезагрузка. Если записано значение 5 или 0Ah, то вместо перезагрузки управление передается по адресу, записанному в области данных BIOS 0040h:0067h.
Этот метод можно использовать не только для выхода из защищенного режима, но и сброса процессора для сохранения идентификатора из регистра EDX.
Алгоритм примерно такой:
1 Запрещаем прерывания
2 Сохраняем сегментные регистры, т.к. их содержимое будет уничтожено после сброса
3 Записываем значение 0Ah в байт отключения 0Fh в CMOS памяти
4 В область данных BIOS по адресу 0040h:0067h записываем адрес нашей процедуры, которая получит управление после сброса и сохранит регистр EDX в переменную
5 В порт контроллера клавиатуры 64h записываем 0FEh. Это команда контроллеру клавиатуры произвести аппаратный сброс процессора
6 Ждем сброса процессора. Изначально в этом месте была небольшая задержка, по идее достаточная, чтобы дождаться сброса. Во время отладки никак не удавалось добиться стабильной работы. В 30% случаев компьютер намертво зависал. Перепробовал все что мог, потратил несколько дней. В конечном итоге вместо задержки стал ждать сброс процессора в бесконечном цикле вида
wait: delay
jmp wait
Зависания прекратились. Это первый случай в моей практике программирования когда от зависания помог бесконечный цикл :-)
7 После сброса BIOS передает управление по адресу 0040h:0067h, в котором хранится адрес пользовательской процедуры
8 Восстанавливаем сегментные регистры
9 Записываем значение 0 в байт отключения 0Fh в CMOS памяти, чтобы следующая перезагрузка была обычная
10 Сохраняем регистр EDX в переменную