Программа "Тест Устройств"

[Improver]

Решил изучить программу "Тест устройств" и понять, что там и как... Известно три версии программы: testustr.rom и testustr_.rom для Вектора (из каталога Базиса (http://caglrc.cc/scalar/ware/621/)), а также TEST_(PK6128TS).COM для ПК-6128ц (в Базисе нет, можно скачать тут: 1 (https://raregame.ru/files/TEST_(PK6128TS).COM), 2 (https://github.com/ImproverX/PK-6128c_PP/blob/main/ROM/TEST_(PK6128TS).COM) или 3 (https://disk.yandex.ru/d/LghpyNV_-5BfIw)). Ещё один файл в Базисе, "testustr [pack].rom" -- это копия "testustr.rom", только в запакованном виде.

Итак, программа "Тест Устройств", как и многие программы Счётмаша собрана на базе "Драйверов устройств (http://caglrc.cc/scalar/ware/575/)", отличия в версиях такие:

Тест ОЗУ -- в тестах для Вектора отличий нет, для ПК-6128ц этот тест обновлён в соответствии с конфигурацией его памяти.
Тест Клавиатуры -- отличий нет, но в тесте для ПК-6128ц есть ошибка -- перепутаны клавиши ВК и ЗБ.
Тест ПУ -- в варианте testustr.rom добавлено некое тестирование системной шины по кнопке "СТР", как оно работает я не понял, т.к. и на реале, и в эмуляторах выдаёт ошибку. Возможно для него нужна какая-нибудь заглушка на порт ВУ, как в тесте порта ПУ. Кому интересно на него взглянуть -- он есть в исходниках (https://github.com/ImproverX/Test_Ust/blob/main/t_PUn.inc), с адреса L_3A06. В остальном в тесте отличий нет.
Тест экрана -- отличия только на ПК-6128ц, связанные с его особенностями.
Тест электронного диска -- в testustr.rom есть небольшие добавления, но для чего -- не углублялся...
Тест дополнительного устройства -- в testustr.rom должен загружаться с адреса 6400h, в testustr_.rom -- с 6200h.
Остальные тесты существенных отличий, фактически, не имеют.

Кроме того, в "testustr.rom" добавлено отключение КД в начале, и в большинстве тестов есть незначительные изменения. В целом, тест для ПК-6128ц ближе к "testust_.rom" -- общая часть совпадает за исключением вырезанной заставки и отдельных тестов.

Ну и всё это исследование в конечном итоге привело к сборке нового объединённого "Теста Устройств":

80412

Что было сделано:

Тест базового микропроцессора -- добавлено автоматическое определение типа процессора.
Тест ОЗУ -- на ПК-6128ц тестируется 128кБ / 4 банки, в остальных случаях -- 64кБ.
Тест клавиатуры -- без изменений (для ПК-6128ц исправлена ошибка расположения клавиш).
Тест ввода-вывода на магнитную ленту -- без изменений.
Тест параллельного интерфейса -- тест системной шины вынес в отдельный подгружаемый модуль "t_VUn.r6E" (грузится на предусмотренное для теста дополнительного устройства место).
Тест устройства отображения информации -- на ПК-6128ц в конце тестируется переключение 12 экранов, в остальных случаях -- 4, как на стандартном Векторе-06ц.
Тест таймера и звукового синтезатора -- добавлен простой тест AY8910, если чип будет обнаружен.
Тест электронного диска -- добавлена возможность ввода вручную порта диска, можно протестировать несколько квази-дисков.
Тест манипуляторов типа джойстик -- добавлено определение и тестирование джойстика "С" (по схеме Вектор-06ц.02).
Тест матричного печатающего устройства -- без изменений.
Тест дополнительного устройства -- добавлено указание адреса для загрузки теста.
Добавлен тест часов реального времени.

Новый тест имеет автоматическое определение типа ПК (по контроллеру памяти), поэтому работает и на Векторе, и на ПК-6128ц -- мне он всё-таки нужен в моём проекте (https://zx-pk.ru/threads/34716-reinkarnatsiya-vektor-pk-6128ts.html), для проверок... :) Исходники выложил на гитхаб (https://github.com/ImproverX/Test_Ust), откомпилированный бинарник дублирую тут: 81069

В планах хорошо было бы ещё оптимизировать алгоритмы "Драйверов устройств", ускорить графику, как Бейсике 2.99 (тем более, что там алгоритмы схожи с Бейсиком 2.5, а значит и возможность ускорить есть), но я не настолько силён в оптимизации, как ivagor, поэтому ещё даже не пробовал.

[ivagor]

Вряд ли стоит заниматься разгоном данного теста, разве что отрезать заставку, чтобы не ждать запуска. Мелкое занудное пожелание - исправить фирму для Z80.
Тест системной шины интересный, но непонятный, надеюсь потом кто-нибудь разберется и расскажет.

[Improver]

исправить фирму для Z80Исправил и перезалил, спасибо.


разве что отрезать заставкуЯ думал об этом, но она не так то уж и много времени занимает, и места, да и без неё будет не так красиво, пропадает дух 1988 года... :)

[ivagor]

По поводу теста системной шины есть предположение, которое объясняет часть с чтением стека. Похоже в заглушке ВУ должны быть соединены выходы /ШАП со входами ШД. Насчет OUT и IN я не понял.

- - - Добавлено - - -

IN и OUT вероятно управляют сигналом /БЛК, чтобы читать стеком не из внутреннего озу, а с ВУ.

[Improver]

Исправил найденный баг: если в тесте джойстика первой нажать кнопку, то портится программа по адресам 0180h...018Fh. На гитхабе и первом сообщении архив с бинарником обновил.

[Ramiros]

Improver, у меня в VV в конфиге 6128 тест памяти заливает 1, 2 и 3ю банки синим цветом и все, дальше нет никакой реакции на клавиатуру и картинка не меняется, так и задумано, или где то баг?

[Improver]

Improver, у меня в VV в конфиге 6128 тест памяти заливает 1, 2 и 3ю банки синим цветом и все, дальше нет никакой реакции на клавиатуру и картинка не меняется, так и задумано, или где то баг?Да, это баг, но не теста, а эмулятора. :( Аналогично ведёт себя и оригинальный "Тест Устройств" от ПК-6128ц. Подвисание происходит примерно на этом участке:

CALL L_MC0B ; тестирование Банка 3
MVI A, 020h
OUT 00Eh ; Банк 0, Банк 1 (R) / Банк 3 (W)
CALL L_MC9C ; переброска данных
MVI A, 022h
OUT 00Dh ; Экран в Банке 3
MVI A, 066h
STA D_MDEA
;
XRA A ;
OUT 00Eh ; Банк 0, Банк 1 (RW)
STA D_MDE9
CALL L_MCA9 ; переброска данных из Банка 0 в Банк 1
MVI A, 055h
OUT 00Eh ; Банк 1, Банк 0 (RW)
STA D_MDEB
CALL L_MC0B ; тестирование Банка 0Вероятнее всего неверно отрабатывается конфигурация памяти 20h или 55h. К чести сказать, в других эмуляторах тут тоже не всё гладко...

Завтра погоняю тест и скажу точно, где виснет.

[ivagor]

Или вот еще (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1106242&viewfull=1#post1106242)

[Improver]

Ramiros, получается так: после MVI A, 055h; OUT 00Eh (память в конфигурации "Банк 1, Банк 0") запускается тестирование области 8000h..FFFFh, которое при первом проходе с обнулением памяти стирает само себя, от этого и зацикливается. Похоже, что там запись выполняется по адресам 0000h..7FFFh вместо 8000h..FFFFh.

Для "шпаргалки" сделал такую вот табличку (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1195134&viewfull=1#post1195134)...

[Improver]

Обновил программу -- добавил тест часов реального времени. Проверил на реале и эмуляторах, глюков не обнаружено.
Исходники также были выложены на гитхаб (https://github.com/ImproverX/Test_Ust), откомпилированный бинарник обновил тут в первом сообщении.

[rst]

Итак, программа "Тест Устройств", как и многие программы Счётмаша собрана на базе "Драйверов устройств (http://caglrc.cc/scalar/ware/575/)", отличия в версиях такие:
[LIST]
Тест ОЗУ -- в тестах для Вектора отличий нетВ моём "Векторе-06Ц" (купленном вроде в 1990г или в 1991г) был брак в одном из чипов КР565РУ6, который не обнаруживался этим тестом. В результате - брак был пропущен при проверке в магазине, и я получил "Вектор", на котором часть программ не работали (брак был в чипе в области видео-ОЗУ, поэтому большинство программ работали, но с иногда появляющимися артефактами на экране). Что это именно брак, а не криво записанные на кассеты программы - я понял не сразу, а только когда стал более-менее соображать в электронике и программировании. Потом и исправил его - заменил бракованную КР565РУ6. После чего заработали ранее не работавшие программы.

Брак заключался как я понимаю - в сбое регенерации содержимого некоторых ячеек ОЗУ после чтения процессором. Т.е. - для обнаружения такого рода брака, нужно читать ячейки памяти дважды. А этот тест видимо делает это только один раз. Подозреваю, что такой брак случался не только в одном моём экземпляре. И непонятно почему тест его не учитывал.

[Improver]

Брак заключался как я понимаю - в сбое регенерации содержимого некоторых ячеек ОЗУ
<...>
И непонятно почему тест его не учитывал.Вообще, в тесте памяти это учитывается, но немного другим способом, там тестирование выполняется так: запись -- ожидание -- чтение. По идее, за время ожидания проходит несколько раз регенерация памяти, и при этом брак можно выявить, но, видимо, не всякий...

[rst]

Вообще, в тесте памяти это учитывается, но немного другим способом, там тестирование выполняется так: запись -- ожидание -- чтение. По идее, за время ожидания проходит несколько раз регенерация памяти, и при этом брак можно выявить, но, видимо, не всякий...Так в моём случае не работала не периодическая регенерация, а регенерация после чтения. Насколько я знаю - содержимое ячейки динамического ОЗУ разрушается операцией чтения (заряд конденсатора тратится при операции чтения). Поэтому после любой операции чтения, заряд конденсатора должен восстанавливаться циклом записи, следующим сразу после цикла чтения. Это выполняется внутренней схемой в чипе дин.памяти. Вот это и не работало.
Да, я знаю что в Векторе видеоконтроллер тоже читает ОЗУ постоянно (да и сбойные биты находились как раз в области видео-ОЗУ). Возможно цикл регенерации после чтения сбивался при следующих друг за другом подряд двух операциях чтения - CPU и видеоконтроллером. Или ещё из-за какой-то комбинации причин. Тут можно только гадать. Но факт был в том, что после записи в эти биты, их содержимое не портилось сколь угодно долго, пока их не прочитает именно CPU. А как только читал CPU - сразу портилось (на экране появлялась россыпь точек в местах сбойных бит). И случалось это только в тех программах, которые и читали ОЗУ. Которые только писали в видеоОЗУ - сбойных точек не возникало.
Например - если в этой области нарисовать закрашенный прямоугольник, то он таким и оставался; сколько угодно долго. Но если выполнить закраску этого же участка при помощи заливки области, то сразу возникали точки (так как алгоритм заливки должен читать видеоОЗУ, когда ищет пути заливки).
Причём - первая операция чтения ячейки процессором возвращала правильное (неразрушенное значение). А уже последующие чтения - возвращали разрушенное значение.
Естественно - если в эти адреса расположить какой-то программный код, то он тоже портился после первого выполнения. Думаю поэтому на моём экземпляре не работали некоторые программы. Которые заработали сразу после замены сбойной КР565РУ6.

PS: Да и сам по себе алгоритм теста: "запись-ожидание-чтение", имхо - бессмысленный. Потому как ожидание тогда нужно делать очень длительным (на несколько десятков секунд минимум). Я как-то (уже на современных чипах SDRAM) в одном своём проекте (где были такие чипы) делал тест: выключал регенерацию SDRAM (как внешнюю так и внутреннюю) и делал паузу, потом заново включал регенерацию и проверял содержимое ОЗУ. Так вот - портиться ОЗУ начинала только после нескольких секунд выдержки без регенерации (или даже нескольких десятков секунд?... уже точно не помню, но при желании можно найти тот проект и заново измерить). А некоторые биты держались даже несколько десятков секунд. А тот тест ОЗУ (в "Тесте устройств") явно не ждёт достаточно долго и, даже если бы схема периодической регенерации вообще бы не работала, то он скорей всего тоже не находил бы сбоев.

[ivagor]

запись -- ожидание -- чтение. По идее, за время ожидания проходит несколько раз регенерация памяти, и при этом брак можно выявить, но, видимо, не всякий
Если ждать долго, а вернее если сначала все записывать и потом все проверять (https://zx-pk.ru/threads/30868-testy-pamyati.html), то это расширяет диапазон обнаруживаемых ошибок (https://zx-pk.ru/threads/8636-vektor-start-1200-obsuzhdenie.html?p=1025694&viewfull=1#post1025694).

- - - Добавлено - - -


в моём случае не работала не периодическая регенерация, а регенерация после чтения.
Вектор регенерирует "свои" РУ6 через полноценные циклы чтения данных для видео. А регенерация only RAS для кваза, подключенного к ВУ.

[rst]

Вектор регенерирует "свои" РУ6 через полноценные циклы чтения данных для видео. А регенерация only RAS для кваза, подключенного к ВУ.Вы хотя бы читайте то, на что отвечаете. Ещё раз:

Так в моём случае не работала не периодическая регенерация, а регенерация после чтения. Насколько я знаю - содержимое ячейки динамического ОЗУ разрушается операцией чтения (заряд конденсатора тратится при операции чтения). Поэтому после любой операции чтения, заряд конденсатора должен восстанавливаться циклом записи, следующим сразу после цикла чтения. Это выполняется внутренней схемой в чипе дин.памяти. Вот это и не работало.
wiki:
The storage cells on a memory chip are laid out in a rectangular array of rows and columns. The read process in DRAM is destructive and removes the charge on the memory cells in an entire row, so there is a column of specialized latches on the chip called sense amplifiers, one for each column of memory cells, to temporarily hold the data. During a normal read operation, the sense amplifiers after reading and latching the data, rewrite the data in the accessed row.
Это происходит внутри чипа и что там делает снаружи Вектор - не при чём.

Сбой происходил видимо при 2-х операциях чтения следующих подряд (CPU+видеоконтроллер). Так что - ко 2-й операции чтения заряд не успевал быть регенерирован.

[Improver]

Если ждать долго, а вернее если сначала все записывать и потом все проверять (https://zx-pk.ru/threads/30868-testy-pamyati.html), то это расширяет диапазон обнаруживаемых ошибок (https://zx-pk.ru/threads/8636-vektor-start-1200-obsuzhdenie.html?p=1025694&viewfull=1#post1025694).

Сбой происходил видимо при 2-х операциях чтения следующих подряд (CPU+видеоконтроллер). Так что - ко 2-й операции чтения заряд не успевал быть регенерирован.В таком случае, возможно, стоит обновить тест памяти в "Тесте устройств"... Либо пользоваться несколькими разными тестами. :)

[ivagor]

Вы хотя бы читайте то, на что отвечаете.
Рекомендую поступать аналогично. Где в процитированном посте я писал, что чтение конденсатора ячейки dram (в РУ6, насколько знаю, 1T1C) не является деструктивным и в конце цикла чтения исходное значение конденсатора не восстанавливается?
Скорее мне можно вменить в вину, что я развернул этот фрагмент

Да, я знаю что в Векторе видеоконтроллер тоже читает ОЗУ постоянно
Возвращаясь к сути. Если учесть эту информацию

Причём - первая операция чтения ячейки процессором возвращала правильное (неразрушенное значение). А уже последующие чтения - возвращали разрушенное значение.
то получается
1) Или все же первая операция не всегда возвращала правильное значение
2) Или дело не в двух чтениях (видеоконтроллер+процессор ) подряд


Да и сам по себе алгоритм теста: "запись-ожидание-чтение", имхо - бессмысленный. Потому как ожидание тогда нужно делать очень длительным (на несколько десятков секунд минимум). Я как-то (уже на современных чипах SDRAM) в одном своём проекте (где были такие чипы) делал тест: выключал регенерацию SDRAM (как внешнюю так и внутреннюю) и делал паузу, потом заново включал регенерацию и проверял содержимое ОЗУ. Так вот - портиться ОЗУ начинала только после нескольких секунд выдержки без регенерации (или даже нескольких десятков секунд?... уже точно не помню, но при желании можно найти тот проект и заново измерить). А некоторые биты держались даже несколько десятков секунд.
Современные SDRAM держат сигнал минимум секунд 10 (если не дольше), особенно если не жарко (а лучше холодно). Сам тоже с этим сталкивался, записывал в SDRAM плисовой девборды данные, потом ресет, потом заливка конфига в плис, старт - и все данные на месте. Советские dram (и их зарубежные прототипы) на такое не способны. Но в тестах для вектора это (ожидание за рамками забывания при отсутствии регенерации) использовать не получится, скорее в других компьютерах с 580ВМ80, у которых можно повлиять на регенерацию.

[rst]

Возвращаясь к сути. Если учесть эту информацию

то получается
1) Или все же первая операция не всегда возвращала правильное значение
2) Или дело не в двух чтениях (видеоконтроллер+процессор ) подрядПочему?

[ivagor]

Информация может испортиться в финальной части цикла чтения, т.е. здесь

the sense amplifiers after reading and latching the data, rewrite the data in the accessed row.
Если процессор прочитал правильно, получается теоретически испортить процесс (не дать нормально завершится зарядке конденсатора) может следующее чтение видеоконтроллера, если оно начинается слишком рано. Слишком рано не для РУ6 в целом, а для конкретной дефектной ячейки.
Если вышенаписанное верно, то признаю, одинарное чтение будет правильным.
Но тогда возможен и другой, очень специфический вариант: если вставим чтение процессора сразу после чтения этой дефектной ячейки видеоконтроллером (можно рассчитать по времени относительно прерывания), то уже первое чтение даст неправильный результат.

[rst]

Но тогда возможен и другой, очень специфический вариант: если вставим чтение процессора сразу после чтения этой дефектной ячейки видеоконтроллером (можно рассчитать по времени относительно прерывания), то уже первое чтение даст неправильный результат.Может в каких-то случаях и первое чтение процессором могло дать неверный результат, но мне такого добиться не удавалось.
Да и оба теста, что были на базовой кассете, ни разу не показывали сбоя. А ведь даже "Тест техпрогона" - он в процессе одного прохода читал сбойный чип несколько тысяч раз. А запускал я его много раз. А уж "Тест техпрогона" (вроде так называется маленький тест?) - его я запускал и на несколько часов кряду непрерывно.

Я не анализировал подробно диаграмму сигналов обращения к ОЗУ в пределах цикла из 4 тактов 3МГц, но возможно чтение CPU может идти сразу в следующем такте после чтения видеоконтроллером, а между чтением видеоконтроллером и чтением процессором - всегда есть дырка в 1-2 такта. Поэтому в первом случае регенерация сбивалась, а во 2-м - нет.
Это как гипотеза. Анализировать прошивку К155РЕ3, чтобы её доказать, я не стану. ;)