Вложений: 1
Промежуточный вариант Монитора на 32 / 64 Кб
Итак, к настоящему времени удалось несколько доработать Монитор и добавить в него некоторый функционал.
- «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РК никак себя не выделяет.
²-Поддерживается данная схема Апогея.
Директива «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, что позволяет расширить их набор.
Вложений: 2
Набросок схему узла расширения до псевдопрефиксов
Как известно, микропроцессор 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 и т.п.
