Программатор 1801РР1 к УКНЦ.

[Ynicky]

Есть в наличии много КМ1801РР1 и две УКНЦ. Одна "уникальная", а другая
"стандартная". А программатора нет. В исходниках Дябина Михаила нашел
программу PROGR.MAC. Как сказал Михаил - она для программатора к ДВК.
По исходному коду вроде понятно как работает программатор, поэтому
решил сделать похожий для УКНЦ. Схему набросал. Перед разводкой хотел
бы уточнить несколько вопросов.
Создал .SAV файл и запустил на УКНЦ.
[IMG][/IMG]
Как я понял эта программа запускается в ЦП. Это значит программатор
должен быть вместо контроллера СА. А можно ли запустить ее из ПП?
Чтобы использовать два разъема сверху УКНЦ.
И если у кого-нибудь есть время и желание - посмотрите схему на наличие ошибок.
Адреса регистров немного изменил для лучшей оптимизации логики.
Элементы в программаторе применил те, которые у меня есть в наличии.

https://cloud.mail.ru/public/4aCe/w8EvJ3FBQ - исходник.
https://cloud.mail.ru/public/CyPE/3m346utM7 - схема.

[Advertiser]

[MM]

схему

Сигнал RPLY 1801РР1 никуда не идет ?

А программатора нет

См. "Стенд БК" :
https://zx-pk.ru/threads/21762-stend...-opisanie.html
Адреса регистров - 177670-177672, доп. окно - 177770-177772 ( не используется в 32-бит варианте ).
Для ДВК это выпускалось в виде полных плат, на выходе были КР531АП2. Для УКНЦ - специальное исполнение в виде 2 шт. полуплат, для слота СА ЦП через маленькую корзинку на 2 шт. полуплаты ДВК.

В данный момент софт остро заточен под БК0010 - 019 ПЗУ, и т.н. 1285 - ссылки на образы дисков для БК11М в наличии.

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

По Э3 ТС - задерживать RPLY в УКНЦ нет необходимости - можно обойтись простым германиевым диодиком Д9Б вместо транзистора с конденсатором, от вых. ДД1.3

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

П.С.
"Ушатанные" РР1 можно "реанимировать" подстройкой вх. напряжения программатора в рамках +22....30 в. - ПВГ будет неплохим.
*
ДПП Стенда БК и Программатора к нему до сих пор в продаже.

[AFZ]

Могу подкинуть идею программатора. Когда я нашел свою коллекцию прошитых РР1 (279, 183, 184 и 093), то, не долго думая, взял АТмегу8515 (ради 40 ног, лежат у меня несколько штук в коробочке) и сочинил читалку. Склепал ее, по-простому, лазерным утюгом, вычитал все м/с, слил через USART на писюк и опубликовал. Потом, почитав ДШ на эту РР1 понял, что добавить туда ключик на повышенное напряжение, переписать софтину и получится программатор для этих РР-ок. Но, поскольку их у меня нет и не предвидится, идея так и осталась в воздухе.

Да, по слухам, у этой РР-ки регистр адреса банка, в который ляжет массив ее памяти, программируется однократно, стереть его нельзя.

[Ynicky]

Сигнал RPLY 1801РР1 никуда не идет ?

В программе есть эмуляция этого сигнала, но на всякий случай объединю его и эмулируемый через диоды с резистором на питание.

[SuperMax]

Да, по слухам, у этой РР-ки регистр адреса банка, в который ляжет массив ее памяти, программируется однократно, стереть его нельзя.

это не слухи это официальная позиция производителя.
однако, есть соображение, что можно попробовать стереть рентгеном.

[AFZ]

Говоря "по слухам", я имел в виду, что я в этом не совсем уверен, читал об этом достаточно давно, мог и перепутать что-нибудь с чем-нибудь.

А о стирании рентгеном у меня противоречивые данные. Лет 15-20 назад потрошилось много старья (по тем временам), и там часто попадались 27256-27512 в пластике без окошка, фактически, однократки. Их тоже пытались тереть рентгеном и у кого-то получалось нормально, а у кого-то стиралось, но потом не записывалось. Естественно, вопрос в спектре излучения и в дозе облучения, но, во-первых, оно, скорее всего, индивидуально для разных чипов, а, во-вторых, подбирать эти параметры - упаришься, и микросхем перепортишь...

И вообще, РЕ-мулятор никто не отменял. Правда по нему у меня тоже есть пара вопросов. Во-первых, странно, что пришлось применять экстремальные меры по ускорению работы в виде написания софтины на асме и переноса ее в ОЗУ МК. Когда я отлаживал AZ на F103, я никаких проблем, связанных со скорострельностью МК, не заметил. И, во-вторых, мне категорически не нравится вариант втыкания круглых штырьков в панельку для м/с. А так...

Впрочем, подозреваю, что ответ на первый вопрос достаточно прост. Виновата, скорее всего, разводка. На такой мелкой платке, скорее всего, не разведешь так, чтобы AD00 приходил на GPIOB00, AD01 - на GPIOB01 ... AD15 - на GPIOB15. А развести, как получится, так собирать адрес из разнообразных битов, да еще, возможно, и считанных из разных GPIO, а потом раскладывать данные назад по этим же битам - процесс достаточно канительный, там не один десяток команд понадобится...

Интересно было бы попробовать: а вдруг разведется? Тогда STM32F103C8T6 - дешевка, плата - тоже копейки.

А по второму вопросу я бы пооткусывал выводы у ненужных непаянных микросхем в пластике, край платы оформил бы в стиле известных ESP-32 и припаял те самые ножки к этим краям.

[SuperMax]

И вообще, РЕ-мулятор никто не отменял. Правда по нему у меня тоже есть пара вопросов. Во-первых, странно, что пришлось применять экстремальные меры по ускорению работы в виде написания софтины на асме и переноса ее в ОЗУ МК. Когда я отлаживал AZ на F103, я никаких проблем, связанных со скорострельностью МК, не заметил. И, во-вторых, мне категорически не нравится вариант втыкания круглых штырьков в панельку для м/с. А так...
Впрочем, подозреваю, что ответ на первый вопрос достаточно прост. Виновата, скорее всего, разводка. На такой мелкой платке, скорее всего, не разведешь так, чтобы AD00 приходил на GPIOB00, AD01 - на GPIOB01 ... AD15 - на GPIOB15. А развести, как получится, так собирать адрес из разнообразных битов, да еще, возможно, и считанных из разных GPIO, а потом раскладывать данные назад по этим же битам - процесс достаточно канительный, там не один десяток команд понадобится...
Интересно было бы попробовать: а вдруг разведется? Тогда STM32F103C8T6 - дешевка, плата - тоже копейки.

если что я готов попробовать развести
надо только проверить саму концепцию в железе
касаемо скорострельности - нам никто не мешает разогнать - те 160Mhz без проблем (но это только в конфигурации с кварцем)

[AFZ]

Ну, голубую пилюлю никто не отменял... Будет время - попробую.

[Vslav]

И вообще, РЕ-мулятор никто не отменял. Правда по нему у меня тоже есть пара вопросов. Во-первых, странно, что пришлось применять экстремальные меры по ускорению работы в виде написания софтины на асме и переноса ее в ОЗУ МК.

Это не экстремальные меры, обычные
Самый тесный момент - это успеть ухватить надежно адрес по ниспадающему SYNC.
Это может быть фатально - потратить лишние 50-60нс, если случайно код ARM выпадет из мини-кеша флеш-акселератора STM32.

Когда я отлаживал AZ на F103, я никаких проблем, связанных со скорострельностью МК, не заметил. И, во-вторых, мне категорически не нравится вариант втыкания круглых штырьков в панельку для м/

100-ая серия не очень, 200 уже намного удобнее (выпускал серийные изделия на 100/200/400), по цене там разница не особо.

Виновата, скорее всего, разводка. На такой мелкой платке, скорее всего, не разведешь так, чтобы AD00 приходил на GPIOB00, AD01 - на GPIOB01 ... AD15 - на GPIOB15. А развести, как получится, так собирать адрес из разнообразных битов,

Вы меня обижаете - я все-таки Full-Stack Embedded Engineer . При проектировании учитывается весь стек проблем, трассировка и распределение портов ввода-вывода тесно связаны и приоритеты всегда смещаются в нужную сторону. В РЕ-муляторе вся шина адреса/данных собрана на одном порту В, при этом было учтено что порт А содержит линии программатора (РЕ-мулятор можно перепрограммировать прямо в системе, не вынимая из панельки), а порт C не полностью 5V-толерантный.

Я вижу надо РЕ-мулятор выкладывать на github, а то тут тема потерялась. В планах было сделать PE-мулятор с Web-сервером на борту, чтобы упростить заливку и перейти на более дешевые китайские GD32. Но народ чего-то РЕ-муляторы только ругает, то с монтажем проблемы, то залить сложно, то имадж построить, поэтому как-то оно без лишнего энтузиазма у меня.

А по второму вопросу я бы пооткусывал выводы у ненужных непаянных микросхем в пластике, край платы оформил бы в стиле известных ESP-32 и припаял те самые ножки к этим краям.

Да, вариант, я заранее даю добро (если оно Вам требуется ) на модификацию.

[AFZ]

Самый тесный момент - это успеть ухватить надежно адрес по ниспадающему SYNC.
Это может быть фатально - потратить лишние 50-60нс, если случайно код ARM выпадет из мини-кеша флеш-акселератора STM32.

Так не отпускать RPLY, пока не приготовился ловить фронт SYNC

Вы меня обижаете - я все-таки Full-Stack Embedded Engineer . При проектировании учитывается весь стек проблем, трассировка и распределение портов ввода-вывода тесно связаны и приоритеты всегда смещаются в нужную сторону.

Круто! Снимаю шляпу и приношу свои извинения. Правда, мою вину несколько уменьшает тот факт, что я так и не смог вспомнить, кто сочинил этот РЕ-мулятор, и в какой теме он описывается. Еще раз прошу прощения.

Кстати, именно РЕ-мулятор навел меня на мысль сделать обслуживание МПИ на STM32 в моем контроллере AZ, так, что благодарю за идею.