Эмулятор Союз-Неон ПК-11/16 - NEONBTL
Благодаря совместным усилиям участников этого форума - @xolod, @Alex_K, @Titus и моих - создаётся второй эмулятор Союз-Неона!
Репо: https://github.com/nzeemin/neonbtl
Скачать: https://github.com/nzeemin/neonbtl/releases
https://pic.maxiol.com/thumbs2/16731...7142419106.png https://pic.maxiol.com/thumbs2/16737...4124847911.png
Состояние:
Загружается до командной строки RT-11. Заработала запись на диск. Загружаемся в Аспект.
Есть поддержка IDE HDD (драйвер HZ).
Заработал Covox.
Недоделки:
- Зависает на демо на передаче файла мелодии в устройство SN.
- Звук с ВИ53 пока не работает.
- Не сделана запись в память по маске - проявляется на демо в тенях надписей, в игре Tetris.
Маппинг клавиатуры:
К1..К5 = F1..F5
ПОМ УСТ ИСП = F6..F8
СБРОС = F11, СТОП = F12
АР2 = Esc, ЗБ = Backspace
Таб = Tab, ВВОД = Enter
НР = LShift, УПР = LCtrl
АЛФ = RShift, ГРАФ = RCtrl
Руководство пользователя эмулятора:
https://github.com/nzeemin/neonbtl/b...r-manual-ru.md — русский
https://github.com/nzeemin/neonbtl/b...r-manual-en.md — английский
Веб-версия эмулятора: https://nzeemin.github.io/neonbtl-wasm/index.html?run=1
Борьба с переходом через границу памяти в прошивке ПЛМ P3.
Собственно известно, что в Союз-НЕОН 22-разрядный физический адрес памяти образуется сложением соответствующего регистра диспетчера памяти, где располагаются разряды с 21 по 12, и виртуального адреса, откуда берутся разряды с 12 по 0. Как видим, общими являются разряды 12, а значит при сложении возможен перенос. В ТО написано, что перенос осуществляется в разряды 13-19, но по анализу прошивки P3 это не так. Сам перенос осуществляется в разряды с 13 по 20. А вот с последним 21-м разрядом интересная ситуация. Если в нём будет реализован полноценный перенос, то он может очистится и физический адрес будет указывать на самое начало памяти, что может привести к её порче, а там находятся регистры виртуальных устройств. Поэтому разработчики поступили следующим образом, вот логическое выражение формирования 21 разряда физического адреса: MMBA21*/PG7+MMBA15*MMBA14*MMBA20*/PG7*CA14*MMBA17*MMBA16*MMBA19*MMBA18. Суть в том, что он будет в единице в том случае, если он уже был в единичном состоянии или был перенос в него. В нулевом состоянии он останется, если он уже был в нулевом состоянии и не было переноса в него. Таким образом не будет портится самое начало памяти, а будет портится, в случае чего, самое начало 2 Мб.
Буфер контроллеров FDD и HDD
По анализу прошивки ПЛМ P10 предусмотрен режим работы буфера - запись или чтение. Соответственно перед работой с буфером его надо перевести в необходимый режим. Перевод в режим чтения осуществляется обращением (чтение или запись) к регистру HD.CSR 0161056, а в режим записи - обращением к регистру HD.SDH 0161054. Это также отражено в исходника ВПО в процессе P16HDC:
;----------------------------------------
; bdir = wr : rd/wr hdsdh ;
; bdir = rd : rd/wr hdcsr ;
;----------------------------------------
В режим записи может его так же перевести контроллер HDD, но только в режим записи, т.к. в режим чтения буфер переводится при записи команды в регистр HD.CSR. Для всех других операций, как адресное чтение и запись буфера, а также для работы дисковода, его необходимо выставить. Для дисковода при чтении данных буфер должен быть в режиме записи, а для записи данных - в режиме чтения.
Также в ПЛМ P10 предусмотрена защита от неправильного использования буфера во время адресного обмена через регистр HD.BUFF 0161040. Т.е. если буфер установили в режим чтения, то запись в него идти не будет и счетчик не будет переходить на следующий адрес. Так же, при установке буфера в режим записи, не будет идти чтение и счетчик не будет переходить на следующий адрес. Это такая защита при исполнении команды MOVB, у которой в цикле записи источника делается пустое чтение этого источника, а затем запись.
Во время обмена с буфером контроллеров FDD и HDD такой полной защиты нет, т.е. операция чтения и записи в память не будет исполняться, но счетчик будет переходить на следующий адрес.
