nedoPC.org

Дошёл до переписывания директив и чуточку подправил их работу:

• «D» - переход в DOS (E000)
• «M<address>» - построчный редактор дампа памяти в режиме 64 Кб
• «M<start>,<end>» - печатает дамп памяти в режиме 64 Кб
• «M<start>,<end>,,1<00-FF>» - печатает дамп ROM-диска
• «M<start>,<end>,,200» - печатает дамп памяти в обычном режиме
• «T<start>,<end>,<target>» - копирует ячейки в режиме 64 Кб
• «T<start>,<end>,<target>,1<00-FF>» - копирует ячейки ROM-диска в память 64 Кб
• Директивы C/F/S теперь работают только в режиме 64 Кб
• «X» - упрощён и модифицирует регистры через директиву «M7614»

Тем самым, директива M выполняет расширенный функционал, в зависимости от количества параметров.
А директиву R заменяет расширенный функционал директивы T, потому R упразднил.

Код подпрограммы вывода символа на экран будет частично векторизован:
Если в ячейках 7600/7601 будет нулевой указаталь, то ячейки 7602/7603 указывают на пользовательский драйвер.
(Ни одна из известных программ не обнуляет эти ячейки, что гарантирует 100% совместимость.)

Исправил подпрограмму вывода символа:

1. Более эконочиный вариант, жрущий стек на 6 байтов меньше
2. Коды 0C и 1F теперь обрабатываются вне зависимости от Esc-статуса
3. Код 1F дополнительно вызывает подпрограмму F82D (из "Холодного Старта Монитора они удалились)
4. Отличные от Esc+Y последовательности передаются пользовательской ловушке

Относительно темы виртуализации портов УВВ немного сдвинулся с места, в теории.

Бинарное представление кодов ключевых инструкций:

• 11010011b - OUT
• 11011011b - IN
• 11011111b - RST 3

Как видно, команды OUT/IN/RST находятся в одной строке таблицы с кодами D3/DB/DF.
При этом, RST 3 или RST 18h очень удобны тем, что вызывают подпрограмму по адресу 0018h.

Многим раннее, уже обсуждался момент в оригинальной схеме РАДИО-86РК, где D-триггер начального пуска ТМ2 по нажатию на кнопку Сброса отключает выходы дешифратора адреса ИД7 и элементом И-НЕ принудительно выбирает ПЗУ с программой Монитор.
Тем самым, с адреса 0000h по 07FFh и далее по "зеркалам" включается ПЗУ с кодом Монитора, где на ячейках 0000-0002 располагается первая команда - JMP F836h.

Таким образом, если внешней логикой в Цикле M1 по статусу процессора поймать момент, когда он должен из памяти прочитать код D3h или DBh, на Шину Данных процессору подставить код DFh и сбросить триггер начального пуска, чтобы отключить ИД7 и принудительно подставить ПЗУ.
Тогда процессор, выполнив код DFh - RST 3, прыгнет на адрес 0018h, что эквивалентно F818h, так как со сброшенным ТМ2 по этому адресу будет ПЗУ Монитора и команда JMP F922h.
Это позволит по каждой команде IN/OUT вызывать подпрограмму Монитора F818h.

Следующий шаг - подправить код подпрограммы вывода текста так, чтобы она начала различать CALL F818h от IN/OUT.
Таким образом, самыми малыми затратами, через трюк со сбросом ТМ2 активациии ИД7, мы получаем виртуализации портов УВВ на инструкциях IN/OUT путём их "горячего перехвата".
А так как конкретно в оригинальном РАДИО-86РК инструкции IN/OUT работают с обращением к памяти и практически не используются в большинстве программ, в основном ряде случаев мы ничего не заметим и программы будут работать как обычно.

То, что перехват IN/OUT через трюк должен срабатывать как RST F818h я считаю весьма удачным совпадением (opportunity), так как из всех подпрограмм Монитора "печать текста" наиболее подходит в силу своей непредсказуемости по тактам, так как всё зависит не только от длины выводимого текста, но и от позиции курсора и состояния опроса клавиатуры.
Короче говоря, добавив на вызове CALL F818h заголовок с проверкой на перехваченные коды D3h/DBh, пользователь практически ничего не заметит.

P.S.: Осталось лишь придумать схему логики детекции с перехватом кодов D3h/DBh с подстановкой процессору кода DFh.

А вот не получится ли твоя схема перехвата тяжелее простого защёлкивания слова состояния процессора, по которому можно отличить обращение к портам от обращения к памяти?

Ну, да, так было бы проще.
Это - так же, как реализована эмуляция текстового режима в ПЭВМ "Поиск": После записи в сегмент B800h формируется NMI и программным образом читается код записанного символа с рендерингом его в основной графической памяти.

Этот подход я обдумывал сотни раз.
Типа, по OUT происходит холостая запись никуда, а в следующем цикле вырабатывается прерывание и БСВВ анализирует адрес порта в коде команды и производит соответствующие операции.
Вот при IN всё несколько проще, так как читается что угодно и откуда угодно, но в следующем цикле вырабатывает прерывание и БСВВ анализирует адрес порта в коде команды и возвращает в Аккумуляторе что нужно.

Но, здесь требуются механизмы прерывания, ВН59.
Даже если на прерываниях вырабатывать FFh на Шине Данных под RST 7/38h, это снова затраты не меньше.

А по новому принципу - вроде всё как бы и проще:

1. Биты D2 и D3 подтягиваем к лог."1" (здесь какую-то развязку нужно сделать от ОЗУ к процессору)
2. Сбрасываем триггер начального пуска ТМ2

У ИМС ОЗУ выводы DI и DO объединяются. Думаю, придётся у двух ИМС сделать разрыв и вставить диоды, для таких трюков?

Как известно, микропроцессор i8086/ВМ86 "эффективным адресом" способен адресовать лишь до 64 Кб памяти, так как в качестве указателей могут использоваться 16-битные регистры BX/BP/SP/SI/DI. Этим он мало чем отличается от i8080/z80/ВМ80.
Главное его отличие - наличие сегментных регистров, которые тоже 16-разрядные, но при адресации их биты сдвигаются влево на четыре разряда и складываются с регистром-указателем, так как инженеры Intel посчитали, что суммарно 1 Мб - хватит всем!
(Хотя могли бы сразу выделить под сегмент гранулярность не 16 байтов, а все 256, что позволило бы с самого начала иметь перспективу масштабирования системы до 16 Мб!)

Но, это всё - лирика!

Сегменты у ВМ80
Конечно, не совсем сегменты в понимании ВМ86, но их подобие.

Идея очень простая. Вместо того, чтобы разбивать адресацию в 64 Кб на отдельные мелкие параграфы/окна по 4 Кб или 8 Кб, переключая в них страницы расширенной памяти, а в случае с Орионом-128 - не обойтись без вызова подпрограмм Монитора, так как страницы переключаются всеми 64 Кб, мною давно рассматривался вопрос имитации сегментных префиксов в ВМ80 как у ВМ86 на период исполнения только одной инструкции.

Вглядываясь в систему команд ВМ80, можно легко обнаружить семь документированных странных инструкций, который официально могли быть и недокументированными.

• MOV B,B - код 40h
• MOV C,C - код 49h
• MOV D,D - код 52h
• MOV E,E - код 5Bh
• MOV H,H - код 64h
• MOV L,L - код 6Dh
• MOV A,A - код 7Fh

Так как нормальные программы в нормальных условиях не могут и не будут изобиловать этими инструкциями, так как они работают как NOP'ы на 5 тактов, что нужно лишь в участках кода с жёсткой привязке к машинному времени, то их можно использовать за префиксы подмены сегмента памяти. Аналогично, как в ВМ86 префиксы «CS:»/«DS:»/«ES:»/«SS:» и «FS:»/«GS:» в более новых моделях процессоров x86.

Вот, примерно такая аналогия:

• «MOV A,A»+«LDAX B» => «LDAX AS:B»
• «MOV B,B»+«LDAX B» => «LDAX BS:B»
• «MOV C,C»+«LDAX B» => «LDAX CS:B»
• «MOV D,D»+«LDAX B» => «LDAX DS:B»
• «MOV E,E»+«LDAX B» => «LDAX ES:B»
• «MOV H,H»+«LDAX B» => «LDAX HS:B»
• «MOV L,L»+«LDAX B» => «LDAX LS:B»

В этом ключе обобщённая запись всех доступных под префиксами расширяемых инструкций выглядит так:

• «MOV x,x»+«LDAX YZ» => «LDAX xS:YZ»
• «MOV x,x»+«STAX YZ» => «STAX xS:YZ»
• «MOV x,x»+«MOV M,R» => «MOV xS:M,R»
• «MOV x,x»+«MOV R,M» => «MOV R,xS:M»
• «MOV x,x»+«ADD M» => «ADD xS:M»
• «MOV x,x»+«ADC M» => «ADC xS:M»
• «MOV x,x»+«SUB M» => «SUB xS:M»
• «MOV x,x»+«SBB M» => «SBB xS:M»
• «MOV x,x»+«ANA M» => «ANA xS:M»
• «MOV x,x»+«XRA M» => «XRA xS:M»
• «MOV x,x»+«ORA M» => «ORA xS:M»
• «MOV x,x»+«CMP M» => «CMP xS:M»
• «MOV x,x»+«R-CON» => «R-CON xS:»
• «MOV x,x»+«RET» => «RET xS:»
• «MOV x,x»+«PUSH YZ» => «PUSH xS:YZ»
• «MOV x,x»+«POP YZ» => «POP xS:YZ»
• «MOV x,x»+«XTHL» => «XTHL xS:SP»

Если хотите получить более-менее понятное представление.

• Префикс «MOV A,A» - код 7Fh, биты адреса A18_A17_A16 - «0_0_1»
• Префикс «MOV H,H» - код 64h, биты адреса A18_A17_A16 - «0_1_0»
• Префикс «MOV L,L» - код 6Ch, биты адреса A18_A17_A16 - «0_1_1»
• Префикс «MOV D,D» - код 52h, биты адреса A18_A17_A16 - «1_0_0»
• Префикс «MOV E,E» - код 5Bh, биты адреса A18_A17_A16 - «1_0_1»
• Префикс «MOV B,B» - код 40h, биты адреса A18_A17_A16 - «1_1_0»
• Префикс «MOV C,C» - код 49h, биты адреса A18_A17_A16 - «1_1_1»

Схематически просто следует выявить в Цикле M1 на Шине Данных коды 40h/49h/52h/5Bh/64h/6Dh/7Fh и сохранить биты D0-D2 в промежуточном регистре.
Сам процессор прочтёт этот код и выполнит холостую MOV-пересылку, затратив 5 тактов. Но схема на следующем цикле уже сможет подставить другую страницу памяти, преобразуя биты D0-D2 предыдущей MOV-инструкции в дополнительные разряды Шины Адреса - A16-A18.

Так как необходимо перехватывать коды команд с симметричными битами (200₈/211₈/222₈/233₈/244₈/255₈/277₈), можно использовать схему сравнения на К155ЛП5, хотя проще обойтись К155СП1.

На схеме:

• ИР27 просто сохраняет слово состояние процессора о текущем Машинном Цикле
• ИР1 левый служит для сохранения младших битов D0-D2 инструкции и флага-признака, что СП1 обнаружил MOV-префикс
• ИР1 правый хранит статус предыдущей команды, чтобы влияние обнаруженного MOV-префикса передавалось следующей команде, а не срабатывало на самом же префиксе
• промежуточные вентили НЕ между регистрами необходимы для дополнения кода с коррекцией до невозможного префикса «MOV M,M», что активен всегда по умолчанию
• ЛИ1 необходима для подавления любого паразитного кода, если код предыдущей команды не был префиксом
• ЛЕ4 управляет вентилями ЛИ1 и подавляет прохождение любого кода во время выборки команды, "начального пуска" и при отсутствии префикса
• ИД7 дополнительный - лишь для примера для дешифрации именованных сигналов, соответствующих каждый своему префиксу

P.S.: Схема не является принципиальной, так как не учитывается нагрузочная способность шим процессора с необходимостью буферного усиления, а всего лишь отображает базовый логический принцип к реализации поставленной задачи как вариант.
P.P.S.: Схема не является пособием к расширению ОЗУ до 512 Кб, а всего лишь иллюстрирует принцип вырабатывания дополнительных битов адреса A16, A17 и A18 для адресации пространства до 512 Кб, что может служить для расширения ОЗУ в частности, а также и для подключения внешних устройств с полной непосредственной адресацией (ROM-Диск, PC-Карточка CGA, PC-Карточка EGA и т.п.).