Полигон-2

Правильно ли я понял, что проверка идёт блоками по 10К слов?
Что произойдёт, если размер памяти не попадёт в ряд 256-512-1М-1,2М и т.д.
Какой размер будет передан процедуре теста Т4?

Странно вообще как то.

Могли бы совместить стирание с определением размера. Кстати, стирание нужно только при включённом Хэмминге, т.к. в момент начального включения код в памяти и контрольный код не совпадают и чтение в пользовательском режиме процессора будет вызывать "Trap to 4", если же не использовать Хэмминг, процедуру стирания можно выкинуть из кода пзу.

andyTh написал:

[q]

Надо бы как то уговорить коллегу ММ прикрутить 134 ПЗУшку к его плате.
Там похоже столько интересного...

[/q]

Если о 6СПП "Блок ВМ3А" - там для Пульта используется аж 32 ( тридцать два ) кбайт батарейного СОЗУ с адресами 000000-077777 режима пульта. Адреса пульта 100000 и выше - БКшные.
Так же участок пульта 000000-000177 виден в АП в зоне BS7 - для закачки в СОЗУ пульта текста.
Изначально такая конфа была выбрана из расчета закачивать в пульт копию экрана с ошипкой пользователя ( при отладке ) и выводить экран отладчика по типу DESSa - с капитальным патчем DESS.SAV такое реализуемо ( строго на БК0011/М ).

Вообще текст 134 ПЗУ не пойдет на блоке ВМ3А в связи с отсуствием терминала 177560 (хотя это можно устранить серьезным патчем 134 - вот тогда только сам текст уже никак нельзя будет назвать "134" ).
И еще маленький штришок в 134 - в особенностях работы участка СОЗУ МС1201.03/04 - его тоже понадобится как следует откорректировать.
Т.е. в общей сложности выходит суп из топора "134". Проще переписать основной ход с приставкой актуальных загрузчиков.
*
Как выйти из ситуации некорректного текста на дешовых доступных ПЗУ 134 ?
Недорогой выход - использование батарейного СОЗУ для эмуляции системного ПЗУ. Собственно управление эмулем ПЗУ целесообразно посадить на какой-нибуть новый регистр в адресах BS7. А само АП эмуля ПЗУ вывести в хвост АП ВМ3.
Такой ход реализован в блок ВМ3А - используется по крайней мере эмуль 326 ПЗУ ( КНГМД ), т.к. там в патченной версии должен был быть и драйвер IDE Самара+100 ( мультикарта БК ).
*
Софт для блока ВМ3А ( полный набор ) досих пор не написан. Ну разве что кроме краткого тестера СОЗУ.
*
Какие выводы сделаны по итогам проверки конструкции блока ВМ3А ?
1. Надо было использовать не монстров КР531АП2 (по 15 руб) , а ж. Н530АП2 ( по 85 руб ).
2. Надо было буферизировать не только внешнюю МПИ, но и внутреннюю.
3. Без синтезатора таймингов внешней МПИ блок получился несколько гавнистым, не позоляющим работать на стотах свыше ~6 мгц
по причине не очень хорошо сделанной МПИ БК ( т.е. полной отсуствии буферов на ней и чудовищным звоном ).
4. Разработка мультикарты была ошибочной - надо было приделать IDE и КНГМД на несколько расширенный блок ВМ3А.
5. Эмулировать надо было и стартовое ПЗУ БК0011/М - АП блока это позволяет.
В целом работа над ошипками блока ВМ3А сдерживается отсуствием 100 т.р. на решение задач по списку выше, с добавлением фич типа 0 таков видео-СОЗУ БК11/М и некотрых др.

Anonymous написал:

[q]

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

[/q]

А зачем тогда вообще городить всякие там микропроцессоры - ставим ОЭВМ пожирнее, баксов так за 50, и ВСЕ проблемы решены - и миллионное быстродествие, и полная совместимость с J11, и гибкий "микрокод" ...

( А детишек усыновим из детдома, т.к. резиновая баба Пока не в состоянии родить... ).

Ну и тоже... 1801ВП-хх не резина, а CPLD резина...
То же самое и с 1818ВМ01/18ххВЕ51.

Абидна понимаешь...