ПК8000 - создание тестового ПЗУ и методики типовой проверки

[cy6]

Тестовое ПЗУ для ремонта, это все таки стандарт. В том числе и для "шагалки". Правильный набор кода, который помогает, а не усложняет проверку каждого элемента (будь то тестером, осциллографом или светодиодами). Сначала проверяются шины, затем более сложные проверки.

Предлагаю здесь предлагать мысли и идеи в эту сторону, что значительно упростит ремонт и создание новоделов.
Вставлять тест, можно вместо самой первой ПЗУ (из восьми).

С чего же начать разработку? Очевидно, что на схеме регенерации ОЗУ (и вывода на экран) нет специальных микросхем, которые нужно инициализировать и включить.
Следовательно, если этот блок включен постоянно, надо понять как его отключить, чтобы на шинах была тишина.
Верно ли я понимаю, и как это можно сделать?

Схема включения шагалки, видимо будет на одной из КТ, предусмотренной производителем. Верно?

[Advertiser]

[cy6]

Требуется ваша помощь, дорогие Гуру!

Сможет ли завестись орионовская шагалка на ПК8000?

Схема тут

Принцип работы компьютера в пошаговом режиме состоит в том, что после нажатия кнопки “шаг” на входе RDY (готовность) процессора устанавливается высокий уровень и процессор начинает выполнять очередной машинный цикл. При окончании этого цикла и начале следующего фронт сигнала SYNC на выводе 19 процессора возвращает триггер пошагового устройства в исходное состояние и, установив на шинах адреса, данных и управления сигналы, необходимые для выполнения этого цикла, процессор переходит в режим ожидания, в котором находится до очередного нажатия кнопки “ШАГ”.

Если да, то как ее подключать?

Уже готова написать тестовое ПЗУ, понимаю как это сделать. Но толку от него будет мало без шагалки, в случаях средней и большой тяжести.

[ivagor]

Пока гуру не подключились вставлю свои пять копеек. У Ориона процессор при обращении к памяти и портам не тормозится, у ПК8000 - тормозится с использованием READY.

[cy6]

Пока гуру не подключились вставлю свои пять копеек. У Ориона процессор при обращении к памяти и портам не тормозится, у ПК8000 - тормозится с использованием READY.

Ну да, для этого и есть КТ на верхней плате, чтобы остановить на первой команде.
А вот как шагать дальше?

И также неясно, нужно ли оно вообще, торможение, при обращении к ПЗУ. Или его можно игнорировать, подключая лишь торможение шагалки.

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

ivagor, а зачем оно вообще применяется, торможение?
Ведь шины все равно заняты процессором всегда (режим ПДП не задействован), и регенерацию обслуживает сам процессор по прерыванию?

Возможно, по шагалке нужно зайти с другой стороны.
Если посмотреть на схему


То это вроде уже готовая шагалка, синхронизированная по Sync-Strobe и по F1?
Есть КТ, которую можно не разрывать, а пропускать в нужный момент лишь один фронт 1=>0 (шаг).
Сам же фронт делает родная схема, выходит некий "феншуй" соблюдается.

Может из этого что то получится или бредятина?

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

Mick, этот подход оказался плодотворным, одна штука стала ясной. Теперь я уверен, что при выполнении программы из внутреннего ПЗУ и из памяти, подключенной к разъему расширения, на каждое чтение из памяти добавляется один такт задержки. Т.е. dad будет не 10 а 11 тактов, inx не 5 а 6 и т.д. Дополнительное подтверждение

Для чего же так сделано?

Видно, что режим вывода на экран на торможение внешней памяти (и скорее всего внутреннего ПЗУ тоже) не влияет.

Все что удалось понять, что торможение как то связано с работой видео. Возможно, какой то совместный доступ к видео-ОЗУ или еще чему то.

[ivagor]

зачем оно вообще применяется, торможение?
Ведь шины все равно заняты процессором всегда (режим ПДП не задействован), и регенерацию обслуживает сам процессор по прерыванию?

При обращении к озу шины заняты процессором 1/3 или 1/4 времени, остальное время занимает видеоконтроллер (бордюр вынесу за скобки), который выводит изображение на экран и попутно регенерирует озу. Для арбитража доступа используется READY. Если бы разработчики очень постарались, они могли бы сделать прозрачный доступ процессора к озу в режимах 0 и 1, но не в 2 (максимум скорости достижимый для 2 - тормоза как в векторе). Можно только предположить, что компьютер и так уже получился сложный и дорогой и они не хотели дальнейшего усложнения и удорожания. Дополнительное торможение, которое есть и при обращении к озу и к пзу можно попробовать игнорировать, по крайней мере при обращении к пзу и возможно так заработает (заработает некая тестовая прошивка пзу, которая не будет трогать озу).
Насчет реализации шагателя в ПК8000 я лучше помолчу, т.к. не думал на эту тему.

[cy6]

При обращении к озу шины заняты процессором 1/3 или 1/4 времени, остальное время занимает видеоконтроллер (бордюр вынесу за скобки), который выводит изображение на экран и попутно регенерирует озу.

А точно ли только процессор считывает ОЗУ, а не и счетчики тоже?

На ША ОЗУ есть "задняя дверь" на мультиплексорах, в виде VD0..VD7, а также других сигналов, в противовес ША процессора.
Похожая "задняя дверь" есть и для РУ2 на его мультиплексорах, в виде VD3..VD7 (младшие 8 группируем).

Все что мне удалось найти на схеме, это два разделяемых ресурса, РУ2 и РУ5.
При этом, шины процессора не затрагиваются, у видео свои шины VD0..VD7 (шина данных, битмапа и указателей) и CD0..CD7 (шина цвета).
Процессор должен стоять в ожидании (READY), для чтения ОЗУ, пока не произойдет подключение моста MD0..MD7(выходная шина данных ОЗУ) => VD0..VD7 => ШД.
В качестве КПП моста, выступает буферная DD39.

Хотелось бы подробнее это все понять, где и что происходит.
Что в прерывании, а что на счетчиках (которые не останавливаются при отладке).

[ivagor]

А точно ли только процессор считывает ОЗУ, а не и счетчики тоже?

Я собственно и написал, что процессор меньше обращается к озу, в основном видеоконтроллер.

Что в прерывании, а что на счетчиках (которые не останавливаются при отладке).

Не понимаю, о чем речь. Есть процессор (и с прерываниями и без) и видеоконтроллер.

[cy6]

Не понимаю, о чем речь. Есть процессор (и с прерываниями и без) и видеоконтроллер.

Имела ввиду какую работу выполняет процессор по прерыванию, а какую видеоконтроллер (сердцем которого является генератор на счетчиках).

Как я поняла, большую часть времени именно видеоконтроллер обращается к памяти, иногда давая доступ процессору. Соответственно, задача регенерации тоже на видеоконтроллере?
А те волшебные байты "05 06 0D 0E 00", как именно они работают?
Кто нибудь заметил, что у ОЗУ циклические параметры VD0..VD7. Они (VD0..VD7) считываются из ОЗУ, по адресу, который может быть частично записан в VD0..VD7.
Ну и доступ на чтение к регистру 90-93 (DD35) у видеоконтроллера судя по всему есть. А значит, он может брать видео-адреса и перебирать в нужный для синхронизации с видеосигналом момент.

[ivagor]

задача регенерации тоже на видеоконтроллере?

Кроме написанного

остальное время занимает видеоконтроллер (бордюр вынесу за скобки), который выводит изображение на экран и попутно регенерирует озу.

добавить мне практически нечего. Особенности регенерации в режиме SCREEN 0 было бы интересно узнать. Неудачная попытка была (кажется в теме про исследование архитектуры), но я тогда не вникал в схему, а без этого за малое количество попыток не угадал. В этом вопросе карты в руки реальщикам.

[ivagor]

Что касается "магических" чисел в хвостах строк SCREEN 0, то с ними в первом приближении все не так уж сложно.
У РУ5 надо перебрать 128 адресов RAS за 2 мс. В активной области видеоконтроллер пробегает 80 (0-39 и 64-103) из 128 значений за 2 символьных или за 16 пиксельных строк (1024 мкс<2 мс, период регенерации соблюдается).
Остаются 128-80=48 значений: 40-63 и 104-127. Насколько понимаю, на бордюре сбоку в SCR0 выборка из озу тоже есть, но не "на все деньги", а скорее всего только 8 символов в конце строки. Поэтому записываем туда коды символов, которые обеспечат перебор оставшихся значений. Символы по 8 байт, значит: 40-47 - 05h; 48-55 - 06h; 56-63 - 07h; 104-111 - 0Dh; 112-119 - 0Eh; 120-127 - 0Fh
Остается один момент - штатное пзу в отличие от описания не записывает 2 из 6 значений (07 и 0F) в последние байты и все работает нормально. У этого есть простое объяснение, которое фактически уже написал ранее - последние 8 символов каждой строки и так выбираются, поэтому 07 и 0F не обязательны. Учитывая, что нужно обеспечить перебор 128 младших адресов можно использовать не только перечисленные значения, но и остальные с шагом 128 байт (16 символов). Т.е. вместо например 05 можно использовать 15h, 25h, ... F5h. И порядок служебных значений в конце строки может быть любой.
Не могу претендовать на истину в последней инстанции, но пока написанное не противоречит наблюдаемому на реале.
Мне немного стыдно, что несколько лет назад не понял такие простые вещи, но лучше поздно, чем никогда.