РАДИО-86РМ

[Alikberov]

Был «РАДИО-86РКилобайт»…
Стал «РАДИО-86РМегабайт»…

Как известно, в схеме РЛК дешифратор ИД7 играет практически основную роль и определяет всё адресное пространтство. В публикациях журнала «РАДИО» предлагались некоторые доработки на эту тему…
Но, в конкретной теме - речь совсем о другом…

Если в оригинальной схеме РЛК заблокировать ИМС ИД7 (не важно как: разрешающих входа у неё три), то процессор окажется «в вакууме». То есть, конкретная архитектура самого РАДИО-86РК отключится. Это понятно любому…

В который раз наткнувшись (ссылка (https://habr.com/ru/articles/410591/)) на заметку о наличии бессмысленных команд («В системе команд несколько раздражает наличие 6 бессмысленных инструкций типа MOV A,A – их могли бы не документировать»), подумал в очередной раз, как бы эти команды можно было бы использовать…

Аппаратно, используя ИМС К155СП1, очень легко в цикле выборке инструкции M1 отловить эти коды и защёлкнуть их в особом регистре, типа К155ИР1.
Оглядываясь на соседние архитектуры, типа К1810ВМ86 с набором префиксов сегментных регистров CS/DS/ES/FS/GS/SS, напрашивается мысль реализовать нечто похожее (аналогично как К1821ВМ85 с его 128 Кб через H1L1).

Получается как бы следующее:
код 40 (MOV B,B) - префикс #6
код 49 (MOV C,C) - префикс #7
код 52 (MOV D,D) - префикс #4
код 5B (MOV E,E) - префикс #5
код 64 (MOV H,H) - префикс #2
код 6D (MOV L,L) - префикс #3
код 7F (MOV A,A) - префикс #1
(Так как код 76 (HLT) как префикс не используется, он должен означать префикс #0 по умолчанию, потому биты кодов необходимо инвертировать.)

Для доступа к памяти через такие мнимые префиксы получаем набор виртуальных инструкций:
код «7F 7E» - инструкция «MOV A,M1»
код «5B 71» - инструкция «MOV M5,C»
код «64 12» - инструкция «STAX D2»
код «49 E5» - инструкция «PUSH H7»
(Здесь «M1» просто означает ячейку памяти «M» по «HL», но с префиксом #1; и т.д.)

Таким образом, бесполезные команды MOV аппаратно относительно легко отлавливаются и запоминаются, предоставляя дополнительные 3 бита к адресации, что уже даёт возможность доступа к 512 Кб адресного пространства.

В рамках онлайн-эмулятора https://rk86.ru/ разработал небольшое расширение для браузера Chrome, которое реализует эту идею без написания эмулятора с нуля.
В архиве имеется и RKR-файл с маленькой графической демонстрацией через дополнительный "сегмент" префикса.
(Естественно, это ещё не всё, так как три бита префиксов должны не сами участвовать в непосредственной адресации, а выбирать один из регистров, где будет храниться конкретная страница памяти, что даст до 16 Мб адресации и "защищённый режим"…)

Или просто - можно посмотреть видео:

https://www.youtube.com/watch?v=Xy9GrY0j5Wg

[NEO SPECTRUMAN]

чего только не придумают лишь бы страничную адресацию не делать

вот если бы в каждом из "адрессных прстрансств" было бы по 4 16К окна
это было бы интересно

и это вовсе не бесполезные команды
вы просто не умеете их использовать

бесполезными как раз могут оказатсо длинные префиксные команды
которые дольше выполняютсо


а еще
префиксы могли бы включать/выключать чтение/запись в другие адресные пространства и на совсем
до следующего префикса


а еще б интересней было бы и переключение текущего адреснного пространссва и на исполнение
ибо для кода тоже не хватает памяти
а тут можно было бы джампать прямо в другие 64К

[Alikberov]

чего только не придумают лишь бы страничную адресацию не делатьИменно с этого всё и начиналось.

вот если бы в каждом из "адрессных прстрансств" было бы по 4 16К окна
это было бы интересно

и это вовсе не бесполезные команды
вы просто не умеете их использовать

бесполезными как раз могут оказатсо длинные префиксные команды
которые дольше выполняютсоВот это - очень интересный вопрос, так как тот же ВТ57 способен обеспечить за цикл лишь до 16 Кб.


префиксы могли бы включать/выключать чтение/запись в другие адресные пространства и на совсем
до следующего префикса


а еще б интересней было бы и переключение текущего адреснного пространссва и на исполнение
ибо для кода тоже не хватает памяти
а тут можно было бы джампать прямо в другие 64ККонцептуально давно задумывалось примерно следующим образом…

Так как 32-битные системы Windows нагло проецируют себя в адресное пространство любого приложения в верхние 2 Гб адресного пространства, приложению из 4 Гб остаётся лишь 2 Гб (ковыряние реестра может дать до 3 Гб). И мне это всегда не нравилось именно как концепт.

Тем самым, если поступить подобным образов и по ВМ80, разделив адресное пространство на нижние 32 Кб пользователя и верхние 32 Кб под БСВВ, то пойдём «по граблям» Windows, отжирая у пользователя половину…

Потому я, после исследования многих вариантов, решил попробовать придумать ещё один.

Вариант №65280

В цикле выборки кода команды M1 адресное пространство 0000…FEFF работает обычным способом, тогда как FF00…FFFF служат триггером и всегда выдают код либо FF, либо C9, работая в двух режимах:
Для приложения вызов CALL FF00…FFFF аналогичен x86-команде SYSCALL и переключает дешифратор адреса в режим БСВВ кодом RST 7
Для БСВВ переход JMP FF00…FFFF аналогичен x86-команде JMP SEG:ADDR и переключает дешифратор адреса в режим приложения кодом RET
Тем самым, приложение имеет все 64 Кб и БСВВ имеет все 64 Кб, так как оба всегда находятся в параллельных теневых страницах.

То есть, имеется две пары страничных регистров - для БСВВ и приложения.

Каждая из страниц - это 8 регистров ИР23:

параграф 0000…3FFF - пара (БСВВ/Приложение) регистров ИР23 (младшая тетрада - страница для чтения; старшая тетрада - страница для записи)
параграф 4000…7FFF - пара (БСВВ/Приложение) регистров ИР23 (младшая тетрада - страница для чтения; старшая тетрада - страница для записи)
параграф 8000…BFFF - пара (БСВВ/Приложение) регистров ИР23 (младшая тетрада - страница для чтения; старшая тетрада - страница для записи)
параграф C000…FFFF - пара (БСВВ/Приложение) регистров ИР23 (младшая тетрада - страница для чтения; старшая тетрада - страница для записи)
То есть, два старших бита адреса процессора и бит "чтение/запись" адресуют один из восьми ИР23, что даёт 256 Кб адресации (A0…A13 процессора и A14…A17 от ИР23).

Тем самым, при сбросе все регистры обнуляются и адресуют четыре зеркала по 16 Кб.

Допустим, компилятор с языка Си может протребовать у БСВВ 192 Кб памяти:

Все 64 Кб под собственный код
Все 64 Кб под текст листинга (теневая страница #1)
Все 64 Кб под итоговый объектный код (теневая страница #2)
Если использовать MOV-префиксы, то получается, что читать текст листинга нужно по «MOV A,A; MOV A,M», а записывать сгенерированный код через «MOV H,H; MOV M,A».
Чтение из листинга и запись объектного кода - разовые операции, что не вызовет существенной просадки производительности…
А вот в пределах своих 64 Кб компилятора, параграфы по 16 Кб можно переключать, чтобы иметь оперативный доступ к дополнительным оверлей-библиотекам по мере компиляции. Здесь префиксы не помогают…

[cy6]

Был «РАДИО-86РКилобайт»
Был и есть Радио (журнал) 86 (год) радиолюбительский компьютер. :)

[Alikberov]

Как выше уже сказано, отключив в РАДИО-86РК дешифратор ИД7 мы отключаем и всю «архитектуру РАДИО-86РК» и можем спокойной использовать процессор по собственному усмотрению, обвешивая разными дополнительными модулями…

Не оглядываясь на обратную совместимость (сейчас любой бинарный код легко подогнать под что угодно и как угодно), но не исключая особенности аналогичных процессоров (i8085 и z80) дизайн обвязки процессора К580ВМ80А должен исполняться в определённом ракурсе:
Коды 40/49/52/5B/64/6D/7F просто учитываются и фиксируются в регистрах управления памятью как есть
Так как «CALL F830» и «SPHL» нужны именно для предустановки стека, сама инструкция «LXI SP…» выглядит как элемент хака. Аппаратно её можно перехватить и использовать для нужд новодельной архитектуры


Модуль памяти
Чтобы приблизить архитектуру к современному уровню, от принципа «страничной памяти» необходимо отказаться, чтобы виртуализировать всё аппаратное окружение.
В подавляющем большинстве 8-битных архитектур существует абсолютно жёсткая конкретика аппаратного исполнения, где проекция портов УВВ и экранной области не может реконфигурироваться программным образом.

Оглядываясь на 16-битные или 32-битные архитектуры, как MS-DOS или Windows, можно заметить так называемые «дескрипторы»:
Дексрипторы файлов
Дескрипторы терминалов вывода
Дескрипторы терминалов ввода
Дескриптор графических устройств
Дескрипторы сетевых ресурсов
и т.п.
Тем самым, в случае с префиксами «40/49/52/5B/64/6D/7F» адресация памяти должна быть не на уровне каких-то конкретных страниц памяти, а на уровне дескрипторов.
То есть, приложению за один момент всегда может быть доступно только до семи активных дескрипторов каких-либо ресурсов.
Допустим, если у РЛК «Специалист» область графики расположена по 8000…BFFF, а у РЛК «Орион» - по C000…EFFF, то в случае с так называемыми «дескрипторами 40/49/52/5B/64/6D/7F» не может быть конкретного способа доступа к ячейкам графики.
Например, если Приложение запросит у БСВВ настроить параграф 4000…6FFF «Префикса #3» (код 6D) настроить на графику в режиме «записи», то код будет иметь возможность строить графику только посредством префикса «MOV L,L» в конкретном параграфе - 4000…7FFF.

То есть, строго говоря, получаем модель памяти на уровень выше, чем, скажем, в том же PC-XT, где графика жёстко закреплена за сегментом A0000…AFFFF.
Практически, у БСВВ можно запросить закрепить все 64 Кб за графику CGA/EGA посредством одного из семи префиксов…

Обращение к БСВВ
В системах Windows существуют динамически подключаемые библиотеки DLL. В случае с обсуждаемой здесь архитектурой, аппаратно это можно реализовать.
Как уже сказано, инструкция «LXI SP…» в нормальных условиях (если не прокручивать экран и т.д.) используется крайне редко. В сочетании с префиксами код 31 можно подставлять процессору другим кодом (например, FF) и другой страницей памяти (страница «диспетчера памяти»).

Так, например код «6D 31 24 05» как инструкции «MOV L,L» и «LXI SP,0524H» могут представлять виртуальную инструкцию «LXI SP3,0524H» (где «SP3» - «SetPage#3»), когда по адресу 0x0524 размещается строка "/dev/cga/"…
Аппаратным образом процессор прерывается и управление получает код менеджера памяти, который обнаруживает сочетание кодов «6D 31» и указатель на строку "/dev/cga/", что и означает запрос от Приложения на переключение дескриптора #3 на память графики CGA…

Здесь, думаю, уже довольно хорошо становится ясным, что такая модель Микро-ЭВМ более гибче, чем любая традиционная со страничной памятью.

[cy6]

Как выше уже сказано, отключив в РАДИО-86РК дешифратор ИД7 мы отключаем и всю «архитектуру РАДИО-86РК» и можем спокойной использовать процессор по собственному усмотрению, обвешивая разными дополнительными модулями…
Отключив дешифратор, который формирует чип-селект для устройств в/в и ПЗУ, мы получаем мертвый компьютер, который навеки выполняет RST 7.

Все дело в чип-селектах, Карл! ) На адресацию, ИД7 вообще никак не влияет. На схемах с РУ5, озу вообще к дешифратору не подключена.

А также, размер ОЗУ больше 256кб для 8-битки, это бессмысленно и беспощадно.

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

Когда говорят о расширении памяти, говорят о дополнительных линиях адреса.
В нашем случае, достаточно две новые линии адреса. 00b, 01b, 10b, 11b. Что полностью соответствует номерам страниц.

Вопрос только как выглядит код, который к таким страницам обращается.
Можно вывести что то в порт регистра управления страницами, а можно написать MOV A, A.
Ну и какая разница? В обоих случая используются две разные команды. но второй путь более мудреный и нечитаемый.

[Vital72]

... а если ещё кто-то использует MOV A, A и т.д. для циклов задержки... ммм... красота

[Alikberov]

... а если ещё кто-то использует MOV A, A и т.д. для циклов задержки... ммм... красотаЭтот вопрос уже обсуждали.
В основном, подобные MOV'ы для задержки нужны в каких-нибудь самодельных контроллерах НГМД и т.д.
Даже подпрограммы магнитофонного ввода/вывода не используют их для задержки.

Так или иначе, таких программ ничтожно мало.

И потом, не нужно забывать: Что перехват таких префиксов с помощью К155СП1 легко заблокировать, форсируя сброс префиксного регистра и К155ТМ2.

Следует учесть и то, что поддержать функционирование "новой архитектуры" на порядок сложнее, чем вернуть всё в исходное состояние, заземлив вывод Сброса триггера ТМ2.


Отключив дешифратор, который формирует чип-селект для устройств в/в и ПЗУ, мы получаем мертвый компьютер, который навеки выполняет RST 7.Ну, не совсем «RST 7» с кодом FF, так как на шине данных РК в режиме чтения наблюдается либо код 82, либо 83…

Все дело в чип-селектах, Карл! ) На адресацию, ИД7 вообще никак не влияет. На схемах с РУ5, озу вообще к дешифратору не подключена.Принципиально рассматриваю только оригинальную схему, так как варианты с РУ5 - это уже «доработка доработанного клона».
А также, размер ОЗУ больше 256кб для 8-битки, это бессмысленно и беспощадно.Просто за всю историю восьмибиток таких экспериментов проделывалось крайне мало, а тем более, никто у себя дома не пытался развернуть подобие 8-битного мэйнфрейма и столкнуться с резкой нехваткой памяти.

Когда говорят о расширении памяти, говорят о дополнительных линиях адреса.
В нашем случае, достаточно две новые линии адреса. 00b, 01b, 10b, 11b. Что полностью соответствует номерам страниц.Через порт страницы и параграфы можно переключать на долговременной основе.

Как уже разъяснялось выше, в конкретном случае префиксы играют роль не «переключалок страниц», а служат «дескрипторами ресурсов»…
Вопрос только как выглядит код, который к таким страницам обращается.
Можно вывести что то в порт регистра управления страницами, а можно написать MOV A, A.
Ну и какая разница? В обоих случая используются две разные команды. но второй путь более мудреный и нечитаемый.Примерно, вот так:
MOV C,C ; Префикс для "CGA-графики"
LXI SP,CGA1 ; Ссылка на строку с указанием ресурса
; Теперь этим префиксом доступна графика
LXI H,8000H ; Иницируем указатель
LOOP:
MOV C,C ; Префикс "дескриптора CGA-графики"
MOV M,L ; Заполняем графический буфер паттерном
INX H
MOV A,H
ANA A
JP LOOP ; Заполняем все 32 Кб счёта
HLT
CGA1: DB '/DEV/CGA/',0Или с «адаптированной мнемоникой»:
LXI SP7,CGA1; Ссылка на строку с указанием ресурса
; Теперь этим префиксом доступна графика
LXI H,8000H ; Иницируем указатель
LOOP:
MOV M7,L ; Заполняем графический буфер паттерном
INX H
MOV A,H
ANA A
JP LOOP ; Заполняем все 32 Кб счёта
HLT
CGA1: DB '/DEV/CGA/',0Гораздо интереснее поглядеть на код, который всеми страницами управляет…

[cy6]

Ну, не совсем «RST 7» с кодом FF, так как на шине данных РК в режиме чтения наблюдается либо код 82, либо 83…
Откуда же они наблюдаются, где источник этих данных?
Может Вы со словом состояния процессора перепутали?

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


Через порт страницы и параграфы можно переключать на долговременной основе.

Как уже разъяснялось выше, в конкретном случае префиксы играют роль не «переключалок страниц», а служат «дескрипторами ресурсов»…
Никто же не мешает сделать схему, чтобы переключатель страниц "отщелкивался" после обращение к нужной странице. Но смысл то какой.

[Alikberov]

Откуда же они наблюдаются, где источник этих данных?
Может Вы со словом состояния процессора перепутали?В моём «КР-03» с 16 Кб ОЗУ директивой «D4000,7FFF» всегда выдавался дамп с кодом 82…
Как недавно пояснили, это - емкостной паразитный эффект с возвратом слова состояния процессора, так как никаких резисторов, подтягивающих ШД к коду FF, схема не имеет.

Никто же не мешает сделать схему, чтобы переключатель страниц "отщелкивался" после обращение к нужной странице. Но смысл то какой.В принципе, в моём случае получается как и с «КР-04», где графика просто на 4 цвета, а с модулем цветности - 4 цвета из 64.
Тут тоже получается: С префиксами - до 512 Кб памяти, а если добавить «регистры-дескрипторы» - то до 512 Кб из 16 Мб.
; Копирование блока памяти
; INPUT:
; HL - Источник
; DE - Приёмник
; BC - Размер блока
;;;;;;;;;;;;;;;;;;;;;;;;;
COPY: MOV A,A ; (5) Префикс страницы источника
MOV A,M ; (7) Читаем байт
MOV B,B ; (5) Префикс страницы приёмника
STAX D ; (7) Записываем байт
INX H ; (5)
INX D ; (5)
DCX B ; (5)
MOV A,C ; (5)
ORA B ; (4)
JNZ COPY ; (10) - 58 тактов
https://www.youtube.com/watch?v=9fM66vbfAQ8

[Alikberov]

Набросок кода ремейка игры «Бомба» (Электроника КР-04).

https://www.youtube.com/watch?v=7NVeuL0Y3ng
Глюков тьма, потому что уложился ровно в 388 байтов кода…
Код использует доступ в теневую страницу графики посредством MOV-префикса, обсуждаемого выше.

Разработка и отладка кода ведётся в онлайн эмуляторе (https://rk86.ru/) с использованием Chrome-расширения для обеспечения дополнительных префиксов и 512 Кб памяти.

[b2m]

Откуда же они наблюдаются, где источник этих данных?
Может Вы со словом состояния процессора перепутали?
Ну, это известная фича. Когда процессор читает из памяти, а все устройства в третьем состоянии, на внутренней шине остаётся слово состояния с предыдущего такта. Оно и читается.

[HardWareMan]

b2m верно говорит. Компы на ВМ80 и без явной подтяжки ШД действительно считывают слово состояния, а оно вот такое:
https://i.ibb.co.com/yYLpsJ1/image.png
82 это MEMORY READ, 42 это INPUT READ, а 83 это скорее из фантастики или какого-то внешнего воздействия на D0.

[cy6]

внутренней шине остаётся слово состояния с предыдущего такта
Если шина данных процессора одна (одни ноги), которые сначала выдавали слово состояния, а потом переключились в режим чтения.
Что они считают, призрак прошлых данных? Переключение происходит настолько быстро, что процессор сам себя оглушает эхом?
В РК нету другого устройства типа регистра, которое могло эти данные запомнить и ретранслировать.

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


без явной подтяжки ШД
Или же процессор читает данные из внутренней магистрали, потому что внутренней подтяжки тоже нет?

[HardWareMan]

Если шина данных процессора одна (одни ноги), которые сначала выдавали слово состояния, а потом переключились в режим чтения.
Что они считают, призрак прошлых данных? Переключение происходит настолько быстро, что процессор сам себя оглушает эхом?
В РК нету другого устройства типа регистра, которое могло эти данные запомнить и ретранслировать.
Открой уже для себя ёмкость шины данных, которая работает почти как DRAM. Открою для тебя секрет: 6502 тоже предыдущие данные схватывает, если в момент чтения ни одного активного устройства на шине нет.


Или же процессор читает данные из внутренней магистрали, потому что внутренней подтяжки тоже нет?
Никаких "или же". ВМ80 полностью отреверсирован и недосказанностей в его поведении нет.

[ivagor]

ВМ80 полностью отреверсирован и недосказанностей в его поведении нет.
Отреверсирован то он отреверсирован, но вот возьмем для примера отличие 580ВМ80 от 8080 (https://www.retrobrewcomputers.org/forum/index.php?t=msg&goto=5877) - чувак нашел его экспериментально, хотя к тому моменту реверс давно уже был. Т.к. там не написано, какого завода и года ВМ80, то мы не знаем, этот баг только "старой" 6 мкм версии или и новой 5 мкм.

[Alikberov]

Так как 512 Кб "теневых страниц" нужно хоть как-то поддержать интерактивно, начал писать скромную оболочку "RAM-DOS" с форматом хранения как в Орион-128.

Все диски - одноимённые:
Диск «A:» - доступ через «MOV A,A» (кодовый индекс #1)
Диск «B:» - доступ через «MOV B,B» (кодовый индекс #6)
Диск «C:» - доступ через «MOV -C,C» (кодовый индекс #7)
Диск «D:» - доступ через «MOV D,D» (кодовый индекс #4)
Диск «E:» - доступ через «MOV E,E» (кодовый индекс #5)
Диск «H:» - доступ через «MOV H,H» (кодовый индекс #2)
Диск «L:» - доступ через «MOV L,L» (кодовый индекс #3)
Вот небольшое видео:
https://www.youtube.com/watch?v=cUb-udLGsXo
Работают пока команды «CAT» и «SAVE».
Также, подправил оформлением ремейк игры «Бомба» (Электроника КР-04), но пока ещё не отладил коллизии мячика…
(Стандартные отладчики вылетают на префиксах.)


82 это MEMORY READ, 42 это INPUT READ, а 83 это скорее из фантастики или какого-то внешнего воздействия на D0.Да, я опечатался: Не 83, а A2. Но в дампах я видел только 82, так как A2 увидит сам процессор при JMP 4000.

[HardWareMan]

Отреверсирован то он отреверсирован, но вот возьмем для примера отличие 580ВМ80 от 8080 (https://www.retrobrewcomputers.org/forum/index.php?t=msg&goto=5877) - чувак нашел его экспериментально, хотя к тому моменту реверс давно уже был. Т.к. там не написано, какого завода и года ВМ80, то мы не знаем, этот баг только "старой" 6 мкм версии или и новой 5 мкм.
Ему ответили так:

That is pretty weird. First of all, I am not quite clear about the status word. It looks that 8080 should send 0x23 status word during the interrupt acknowledge cycle (see page 2-6 here).
Next, I am 99.9% sure that clones work correctly with 8259 PIC, which does exactly what you've described: It keeps the INT line active until it receives 3 interrupt acknowledge pulses, allowing it to feed CALL instruction to the CPU. This effectively results in INT line being active for 3 consecutive bus cycles.
So perhaps there is an issue in the way you do the status word decoding?
И, ВНЕЗАПНО, Корветы работают нормально. Когда стали выпускаться Корветы? Ну и вот это вот его "This looks like a microcode loop." вызывает гомерический хохот. Скажите ему кто-нибудь, что у i8080 нет микрокода.

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

PS Кстати, повторный вход в прерывание при удержании сигнала выглядит вполне логичным для обслуживания вложенных прерываний, если на 59й пришло новое, более высокое по уровню прерывание в момент, когда он скармливал вектор прерывания с меньшим приоритетом. Я не понимаю претензий того перла. Надо будет глянуть в схему для уточнения.

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

PPS: Схема говорит, что INTE сбросится после начала обработки прерывания.
https://i.ibb.co.com/Nj536Pt/image.png

[ivagor]

Ему ответили так:
?
На этом же дискуссия не закончилась.

И, ВНЕЗАПНО, Корветы работают нормально.
Так а почему они не будут работать нормально, там же ВН59 и про это написано.

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

И про логичность/нелогичность уже существующих (не разрабатываемых) процессоров - это разговоры в пользу бедных. Есть определенное поведение одних процессоров и другое поведение других процессоров.

[Alikberov]

Так как работа с интервалами - довольно специфическое занятие и без практической проверки не имеет гарантии, оставаясь в рамках чистой логики, подрисовал схему так, как вижу сам «идеальный РК»…

Что изменилось:

Элемент D13.1 ТМ2 после сигнала сброса устанавливается теперь не по сигналам A15+DBIN, а просто по фронту сигнала A15 (думаю, тоже не нарушит работу), освободив этим вентиль D10.1
Элемент D10.1 ЛА3 теперь подключён к ИД7 вместо D5.3 ЛП5
Элементы D10.1 и D10.4 подключены к D11 ИД7 перекрёстно и выборка основного банка ОЗУ производится по адресам 0000…1FFF и 6000…7FFF (дополнительное ОЗУ займёт адреса 2000…5FFF), что позволит использовать ПЗУ «Монитор» на 32 Кб и запустить многие игровые программы, расчитанные на 32 Кб (потому принцип расключения самого ИД7 не был затронут: выборка 8 страниц по 8 Кб)
Используются ИМС К573РФ4 за ПЗУ D12 знакогенератора и D17 «Монитора»
Элемент D5.3 ЛП5 теперь используется для инверсии видеосигнала по сигналу RVV атрибута ИМС D8 ВГ75 (перемычка «JP» - опциональна)
Добавлены ИМС ЛИ1 и ТМ2 с управлением сигналами LA0 и HLGT ИМС D8 кодами E4/E5 буфера экрана для выборки дополнительных таблиц знакогенератора (подробнее (https://zx-pk.ru/threads/26455-chto-maksimum-mozhno-vyzhat-iz-kr580vg75-intel-8275-obsuzhdenie.html?p=1186570#post1186570))
ИМС D21 К140УД6 удалён с основной части схемы и перенесён на плату клавиатуры (оригинальная схема клавиатуры РК идеально подходит и для подключения джойстика к линии клавиш управления курсором, что позволило бы на плате клавиатуры разместить два дополнительных разъёма: Джойстик и Магнитофон)
Если удалить два ППА ВВ55 D14 и D20 с основной платы и перенести D20 на плату клавиатуры, соединяющий шлейф сократится на восемь линий и освободится место на процессорной плате (возможно, понадобятся дополнительные буферы шин, чтобы поддержать функционирование ВВ55 удалённого на клавиатуру)


Интересно выслушать замечания по каждому из пунктов.
Спасибо!

[HardWareMan]

Элемент D13.1 ТМ2 после сигнала сброса устанавливается теперь не по сигналам A15+DBIN, а просто по фронту сигнала A15 (думаю, тоже не нарушит работу), освободив этим вентиль D10.1
Это было сделано не просто так, а как детект именно чтения с верхнего адреса, т.е. осознанного процессором действия а не просто случайного перекидывания A15, которое вполне может быть.

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

PS Схема - мелкая тумба. Выложи полноразмерную картинку.

[Alikberov]

Это было сделано не просто так, а как детект именно чтения с верхнего адреса, т.е. осознанного процессором действия а не просто случайного перекидывания A15, которое вполне может быть.Вот потому и хочу посоветоваться с инженерами-специалистами.
PS Схема - мелкая тумба. Выложи полноразмерную картинку.Хм. Забыл про временные нюансы форума. Выкладываю в архиве.

P.S: ИМС D14 и D20 из схемы пока не стёр, но, как и сказал выше, лучше перенести на клавиатуру их, а вместо них на процессорную плату добавить ВК28 (на место D20) и РУ8 (на место D14).

[Alikberov]

Вариант на 64 Кб
Как известно, в подавляющем большинстве Микро-ЭВМ адресация до того проста, что 64 Кб ОЗУ доступны лишь частично:
ZX-Spectrum/48Kb: 0000…3FFF всегда отдаются под ROM, что после загрузки любой игры просто остаётся в памяти как рудимент (большинство игр само выводит текст любым собственным шрифтом, играет музыку собственными алгоритмами и т.д.)
Орион-128: F400…F7FF - 1 Кб УВВ; F800…FFFF - 2 Кб ПЗУ (адресация ОЗУ только 61 Кб на страницу)
Чисто ради экспериментальных размышлений тут подумалось, а что, если…

Конкретно в РАДИО-86РК ввести поддержку 64 Кб ОЗУ…

То есть, включать ИД7 с адресацией ВВ55/ВГ75/ВТ57/РФ2 только в том случае, если счётчик команд процессора PC>8000, чтобы только код Монитора и КНГМД мог видеть все УВВ РЛК.
Соответственно, когда счётчик команд PC<8000, приложению открываются все 64 Кб (65336 байтов) ОЗУ для чтения и записи! Ограничение лишь в том, что сам код приложения не может выполняться за границей 8000.
В то же время, при любом CALL на E001 или F803…F86C управление получит привычный код.

В рамках теоретической мелкой доработки исходной схемы РАДИО-86РК я слегка перерисовал схему:
У ТМ2 выводы 2 и 3 отрываем от земли
Вывод 36 ВМ80 подаём на вывод 2 ТМ2, чтобы триггер хранил флаг режима адресации «РК»/«64 Кб»
На вывод 3 ТМ2 через элемент 3И (или три диода+резистор) подаём сигналы Ф2TTL ГФ24 вывод 6 и сигналы M1 и STB процессора с выводов 4 и 19 соответственно
На элементах D10.1 и D10.4 собираем RS-триггер для выполнения функции вместо ТМ2 - принудительная выборка ПЗУ после сигнала Сброс
Как практик, не пока не очень силён и нету уверенности, верно ли я всё набросал.

По плану, после Сброса D-триггер ТМ2 и RS-триггер D10.1/D10.4 обнуляются, элемент D10.1 принудительно выбирает ПЗУ, чтобы процессор с адреса 0000 прочёл инструкцию JMP F836, которая активирует в машинном слове статуса бит D5 цикла M1 и по стробу Ф2TTL и SYNC процессора загрузит бит "1" адреса A15 в ТМ2, который разрешит работу дешифратора адреса ИД7.
А вот при переходе на адрес 0000…7FFF по G0 циклом M1 процессор занесёт в ТМ2 бит "0" адреса A15 и дешифратор ИД7 отключится.

Естественно при отключении ИД7 необходимо к процессору подключать полный банк ОЗУ, чтобы пользовательский код имел все 64 Кб памяти.

В варианте РЛК с 16 Кб ОЗУ практически ничего не изменится.
Вывод 4 ТМ2 перемычкой «16 / 64» связан с выводом 2 D10.1 чтобы обеспечить полную обратную совместимость: Всё будет как прежде.
(Владельцы 16 Кб практически не заметят разницы.)

Если же перемычку «16 / 64» удалить (и резистором подтянуть вывод 4 ТМ2 к напряжению +5 Вольт), то для пользователя верхняя половина 8000…FFFF со всеми ВВ55/ВТ57/ВГ75 окажется вне доступа, так как там должен разместиться дополнительный банк ОЗУ. А ПЗУ E000…FFFF будет доступны только при обращениях к ним посредством команд CALL/JMP/PCHL/RET.

P.S.: Ниже - набросок схемы, которая теоретически должна обеспечить работу режима в 64 Кб.
Именно набросок, так как в работоспособности я не уверен.
Как и оригинальной схеме РЛК "Специалист", дополнительные ИМС ОЗУ можно подключить параллельно имеющимся (добавить ещё 24 ИМС РУ3), управлять которыми должен дополнительный ИД7, вывод 6 которого управляется с вывода 6 ТМ2.

[Alikberov]

Ниже прикрепляю файл с LogiSim-эскизом схемы переключения режимов.

Триггер ТМ2 просто сохраняет старший бит A15 счётчика команд PC во время выборки очередного кода инструкции в цикле M1 синхронно по Ф2TTL и SYNC, когда на ШД D5 выдаётся флаг M1.

Получается, что верхний ИД7 - системный на плате РЛК активируется только на командах, работающих по адресам выше 8000 и программа Монитор работает только с ним.
Напротив, дополнительный нижний ИД7 - пользовательский и служит лишь для выбора всех верхних ячеек дополнительного ОЗУ, которое не видно из-под Монитора и открывается лишь для пользовательского кода, работающего в нижних адресах 0000…7FFF.

Разметка памяти при этом может получиться такой (на вход D подаются A13…A15 через элемент 3-И):
ПАМЯТЬ ПОД БСВВ / ДОС (PC>DFFF) ПАМЯТЬ ПОЛЬЗОВАТЕЛЯ (PC<E000)

FFFF +-------------------------+ FFFF +-------------------------+
| ПЗУ "МОНИТОР" / ПДП | | |
F800 +-------------------------+ | ОЗУ |
| ПЗУ #2 / РЕГИСТРЫ КНГМД | | ПОЛЬЗОВАТЕЛЯ |
F000 +-------------------------+ | (ТОЛЬКО ДАННЫЕ) |
| ПЗУ "ДОС" | | |
E000 +-------------------------+ E000 +-------------------------+
| ВГ75 | | |
C000 +-------------------------+ | ОЗУ |
| D14 ВВ55 | | ПОЛЬЗОВАТЕЛЯ |
A000 +-------------------------+ | (ПРОГРАММЫ И ДАННЫЕ) |
| D20 ВВ55 | | |
8000 +-------------------------+ 8000 +-------------------------+
| БУФЕР ЭКРАНА | | БУФЕР ЭКРАНА |
76D0 +-------------------------+ 76D0 +-------------------------+
| РАБОЧИЕ ЯЧЕЙКИ МОНИТОРА | | РАБОЧИЕ ЯЧЕЙКИ МОНИТОРА |
7600 +-------------------------+ 7600 +-------------------------+
| | | |
| ОЗУ | | ОЗУ |
| | | |
| ПОЛЬЗОВАТЕЛЯ | | ПОЛЬЗОВАТЕЛЯ |
| | | |
| (ПРОГРАММЫ И ДАННЫЕ) | | (ПРОГРАММЫ И ДАННЫЕ) |
| | | |
0000 +-------------------------+ 0000 +-------------------------+

[Alikberov]

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


«D<начало>,<конец>» - вывод дампа в режиме 64 Кб¹
«D<начало>,<конец>,,<1XX>» - вывод дампа ROM-диска из страницы XX²
«D<начало>,<конец>,,<200>» - вывод дампа в режиме 16/32 Кб¹
«L<начало>,<конец>» - вывод текста в режиме 64 Кб¹
«L<начало>,<конец>,,<1XX>» - вывод текста ROM-диска из страницы XX²
«L<начало>,<конец>,,<200>» - вывод текста в режиме 16/32 Кб¹
«M<адрес>» - редактирование памяти в строчном формате (только в режиме 64 Кб¹)
«S<начало>,<конец>,<код>» - поиск кода в режиме 64 Кб¹
«S<начало>,<конец>,<код>,<1XX>» - поиск кода в ROM-диска из страницы XX²
«S<начало>,<конец>,<код>,<200>» - поиск кода в режиме 16/32 Кб¹
«T<начало>,<конец>,<куда>» - копирование блока (только в режиме 64 Кб¹)
«T<начало>,<конец>,<куда>,<1XX>» - копирование блока ROM-диска из страницы XX²
«X» - просмотр/редактирование содержимого регистров в строчном формате

¹-Режим «64 Кб» экспериментальный и на стандартном РАДИО-86РК никак себя не выделяет.
²-Поддерживается данная схема Апогея (https://zx-pk.ru/w/images/f/fd/Apogey_bk01_romdisk4.jpg).

Директива «R» исключена, так как расширенный режим директивы «T» её подменяет.

Подправил подпрограмму вывода символа:
Коды 1F/0C имеют наивысший приоритет³
Код 1F после очистки экрана сам вызывает F82D³
Неизвестные Esc-последовательности передаются ловушке
Прокрутка экрана производится только в прямоугольнике 64x25 с очисткой последней строки
³-При "холодном старте" код оригинального Монитора дважды вызывал F82D и очищал служебные ячейки также и для корректной работы кода 1F, иначе при любой комбинации в ячейке 7004 код проигнорировался бы и экран не очистился, что не позволило бы нормально запуститься при первой подаче питания.

Ограничив прокрутку областью 64x25 несколько ускорился и сам процесс (примерно на 8%).
Директива «D0,FFFF»:
В оригинале работает 434 секунды
С моими коррекциями - 396 секунд

Количество точек вызова API-Монитора несколько расширилось:
F836 - чтение ячейки памяти в режиме пользователя 32 Кб
F839 - запись ячейки памяти в режиме пользователя 32 Кб
F83C - сохранение контекста процесса
F83F - установка режима чтения памяти и страницы ROM-Диска
F842 - чтение ячейки ROM-Диска или УВВ
F845 - установка адреса на пользовательскую ловушку

Собственно, F845 выполняет специальную функцию и обрабатывает ситуации с выпадением сигнала магнитофона (как в Орионе), чтобы избежать вываливания в Монитор из Бейсика при загрузке с ленты или нажатия F4 / УС+C.
А также, ей передаются и все остальные Esc-комбинации из подпрограммы F809, что позволяет расширить их набор.

[max232cpe]

Возможно стоит заменить процессор на 8086 и расширить возможности ещё больше...

[Alikberov]

Возможно стоит заменить процессор на 8086 и расширить возможности ещё больше...Так вся соль вопроса в том, что добавляем три диода и резистор на исходную плату РК и получаем все 64 Кб.
Про перерезание дорожек я промолчу, как и про замену трёх диодов на одну ИМС К155ЛИ3, просто чтобы не завалить сигналы ВМ80.
А вот замена на ВМ86 будет настоятельно требовать совместимости с IBM PC/XT с обязательным запуском MS-DOS, для чего давно существует другой РЛК - «Поиск»…

[max232cpe]

Так вся соль вопроса в том, что добавляем три диода и резистор на исходную плату РК и получаем все 64 Кб.
Про перерезание дорожек я промолчу, как и про замену трёх диодов на одну ИМС К155ЛИ3, просто чтобы не завалить сигналы ВМ80.
А вот замена на ВМ86 будет настоятельно требовать совместимости с IBM PC/XT с обязательным запуском MS-DOS, для чего давно существует другой РЛК - «Поиск»…

Проблема в том что упрощенных пк на 8086 нет всё остальные совместимые с ibm pc как правило очень не маленькие и имеют кучу мс в отличии от того же р86рк

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

По уму конечно нужно всё с 0 разводить на базе проца 86

[Vital72]

По уму конечно нужно всё с 0 разводить на базе проца 86

т.е. не имеет к Радио-86РК никакого отношения

[Alikberov]

По уму конечно нужно всё с 0 разводить на базе проца 86Ну, если по уму, тогда нужно и IBM PC/XT с нуля переразработать и устранить проблему с FPU.
На одном из профильных форумов уже поднималась тема, почему i8086 имеет набор Escape-инструкций, перенаправляемый на любой сопроцессор. Но так как рынок в первую очередь требовал работу с бухгалтерскими таблицами, а Intel ничего кроме i8087 выпускать и не думала, то начиная с i80486 буквально забили гвоздь в гроб Escape-инструкций и намертво привязали весь набор к FPU. Хотя могли выпустить и GPU-сопроцессоры, которые интегрирровались бы в саму систему команд как тот же FPU: Вместе с FINIT-инструкцией с инициализацией FPU была бы и инструкция GINIT для инициализации GPU.
Но это выходит далеко за пределы данной темы.

[max232cpe]

Есть такое.

[b2m]

Проблема в том что упрощенных пк на 8086 нет
А как-же это: Радио-86РК на 8088 (или 8086) (http://www.nedopc.org/forum/viewtopic.php?p=160359#p160359) ?

[max232cpe]

А как-же это: Радио-86РК на 8088 (или 8086) (http://www.nedopc.org/forum/viewtopic.php?p=160359#p160359) ?

Не натыкался на это

[Alikberov]

Итак, основная работа над изменением Монитора практически завершена.

Подпрограммы вывода на экран

CALL F809 выводит символ на экран из регистра C
CALL F80F выводит символ на экран из регистра A (как в «Орионе»)
CALL F815 выводит байт на экран, сохраняя все регистры
CALL F818 выводит текст на экран с утерей регистра A (завершение строки по 00 или >128)

Код подпрограммы вывода символа на экран полностью переписан, поддерживает пользовательский буфер и оконность.
Рабочие ячейки:
CONADR: EQU 07600H ; Адрес символа под курсором в памяти;
CONPOS: EQU 07602H ; Координаты позиции X,Y курсора на экране;
CON@PX: EQU 07602H ; Консольная позиция курсора по X;
CON@PY: EQU 07603H ; Консольная позиция курсора по Y;
CONSTA: EQU 07604H ; Консольный статус в Escape-последовательности;
CONLEN: EQU 0760FH ; Ширина одного знакоряда в настройках ИМС ВГ75 (стандарт: 78);
CONORG: EQU 07610H ; Консольный организатор окна с позицией X1,Y1 относительно начала буфера;
CON@XO: EQU 07610H ; Консольная абсолютная позиция окна по горизонтали (стандарт: 8);
CON@YO: EQU 07611H ; Консольная абсолютная позиция окна по вертикали (стандарт: 3);
CONBOX: EQU 07612H ; Относительный размер бокса ограничителя окна на экране (стандарт: 63x24);
CON@XS: EQU 07612H ; Относительный размер окна по горизонтали с указанием крайнего правого столбца (стандарт: 63);
CON@YS: EQU 07613H ; Относительный размер окна по вертикали с указанием крайней нижней строки (стандарт: 24)
Тем самым, подпрограмма Монитора уже поддерживает оконность (от 1x1 до 80x64) и может полноценно работать с буфером в любом месте ОЗУ. Исключения составляют только коды:
19 - Перемещает позицию курсора лишь до верхней основной строки окна, затем - прокручивает область вниз;
1B - Помимо установки курсора в нужную позицию по Escape-команде «Y», все остальные комбинации перенаправляет в драйвер пользователя, вызываемый через ловушку;
1F/0C - Перезапускают ВТ57/ВГ75 в стандартный режим 78x30 в буфере 76D0…7FF3 с окном 64x25 в позиции 8,3;
1F - Очищает буфер 76D0…7FFF и перезапускает ВТ57/ВГ75 на стандартный режим

Подпрограмма управления режимом экрана
Для переключения режима ВТ57 и ВГ75 достаточно в HL загрузить адрес на таблицу с описанием режима и вызвать подпрограмму F83C.
Естественно, служебные ячейки с параметрами окна нужно корректировать непосредственно.

Ниже - сам образ ПЗУ Монитора и подгружаемый файл с режимом 80x64.

http://www.youtube.com/watch?v=UIiwSYm8gWY
После запуска программы с переходом по G0 режим экрана переключается и управление возвращается Монитору, что позволяет использовать все директивы в установленном режиме: Даже директивы «I» и «O»!
Выход из режима, как выше и говорилось, клавиша «Стр» или «Home»…

P.S.: Пришлось пожертвовать директивами «X» и «C»… :roll:
Для запуска игры «Volcano» следует сначала обнулить ячейки 03EA и 03EE…

[max232cpe]

Не совсем уместный вопрос...
Сколько страниц памяти доступно для рк с минимальными изменениями?

[Alikberov]

Не совсем уместный вопрос...
Сколько страниц памяти доступно для рк с минимальными изменениями?Минимальные изменения, предлагаемые здесь (https://zx-pk.ru/threads/35287-radio-86rm.html?p=1194790&viewfull=1#post1194790)?

ПАМЯТЬ ПОД БСВВ / ДОС (PC>DFFF) ПАМЯТЬ ПОЛЬЗОВАТЕЛЯ (PC<E000)

FFFF +-------------------------+ FFFF +-------------------------+
| ПЗУ "МОНИТОР" / ПДП | | |
F800 +-------------------------+ | ОЗУ |
| ПЗУ #2 / РЕГИСТРЫ КНГМД | | ПОЛЬЗОВАТЕЛЯ |
F000 +-------------------------+ | (ТОЛЬКО ДАННЫЕ) |
| ПЗУ "ДОС" | | |
E000 +-------------------------+ E000 +-------------------------+
| ВГ75 | | |
C000 +-------------------------+ | ОЗУ |
| D14 ВВ55 | | ПОЛЬЗОВАТЕЛЯ |
A000 +-------------------------+ | (ПРОГРАММЫ И ДАННЫЕ) |
| D20 ВВ55 | | |
8000 +-------------------------+ 8000 +-------------------------+
| БУФЕР ЭКРАНА | | БУФЕР ЭКРАНА |
76D0 +-------------------------+ 76D0 +-------------------------+
| РАБОЧИЕ ЯЧЕЙКИ МОНИТОРА | | РАБОЧИЕ ЯЧЕЙКИ МОНИТОРА |
7600 +-------------------------+ 7600 +-------------------------+
| | | |
| ОЗУ | | ОЗУ |
| | | |
| ПОЛЬЗОВАТЕЛЯ | | ПОЛЬЗОВАТЕЛЯ |
| | | |
| (ПРОГРАММЫ И ДАННЫЕ) | | (ПРОГРАММЫ И ДАННЫЕ) |
| | | |
0000 +-------------------------+ 0000 +-------------------------+
Конкретно данный вариант Монитора разрабатывается под одну страницу объёмом в 65536 байтов (пользователь имеет доступ ко всем 65536 ячейкам).
То есть, код пользователя видит только одно сплошное ОЗУ и к УВВ прямого доступа не имеет. Только через вызовы подпрограмм Монитора F836/F839/F83C приложение может читать УВВ, писать в УВВ и менять режим ВТ57/ВГ75.

С другой стороны, сам код Монитора не видит верхние 32 Кб непосредственно, но директивы D/F/L/S/T через трюковые механизмы получают доступ ко всем 64 Кб.
(Директивы I и O пока ещё не переработал: Они не видят верхние 32 Кб ОЗУ. То есть «OF800,FFFF» выгрузит содержимое ПЗУ Монитора, а не ОЗУ…)

[b2m]

Получается, что верхний ИД7 - системный на плате РЛК активируется только на командах, работающих по адресам выше 8000 и программа Монитор работает только с ним.
Область 8000-DFFF заявлена как "программы и данные", однако триггер устанавливается по значению только одного бита А15. Какой будет использован дешифратор, если программа будет выполняться в данной области?
Может необходимо добавить еще элемент И для А13-А15?

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

Может второй дешифратор и не нужен вовсе?

[Alikberov]

Область 8000-DFFF заявлена как "программы и данные", однако триггер устанавливается по значению только одного бита А15. Какой будет использован дешифратор, если программа будет выполняться в данной области?
Может необходимо добавить еще элемент И для А13-А15?В рамках доработки rk86.ru (http://rk86.ru/) я дополнил скрипт с проверкой на «cpu.pc < 0x8000»…
Однако, Виктор Пыхонин помог в плане сборки Emu80 с поддержкой переключений и в рамках «ночной сборки Emu80» конфигурация позволяет использовать память 0000…DFFF полностью под код также, как и "заявленно".
(В рамках rk86.ru я специально себя ограничил.)

А так, элемент К155ЛИ3 может помочь получить исполнение кода до самых DFFF.
Может второй дешифратор и не нужен вовсе?Второй ИД7 упоминается лишь формально, так как с заменой РУ6 на РУ5 выборка ОЗУ должна производиться минуя ИД7, так как на ТМ2 перекладывается эта функция

[Alikberov]

Как известно, микропроцессор 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 и т.п.