«РАДИО-86РК» - 512 Кб / 16 Мб

[Alikberov]

Хотелось бы подчеркнуть название темы - «РАДИО-86РК» - 512 Кб / 16 Мб.
Здесь не рассматриваются варианты расширения до Специалиста (48 Кб) или Ориона (61 Кб).

Тема, в своём роде, теоретическое размышление на тему…
Выше я максимально развёрнуто уточнил, откуда растут ноги.

Тем самым, я не рассматриваю варианты расширения ОЗУ до 60 Кб и даже до 65520 байтов.
Только 65536 байт на страницу!

С MOV-префиксами страниц всего - восемь.
Тем самым - 512 Кб минимум.
Максимум - восемь MOV-сегментов, каждый из которых адресует 64 Кб из 16 Мб.

[aviator]

Только 65536 байт на страницу!

А стек? А таблица системных вызовов? Копировать в каждую страницу?

[Alikberov]

А стек? А таблица системных вызовов? Копировать в каждую страницу?

Видно, не очень понятно описал технологию переключения страниц?

System Mode / Режим «Монитора-16/32 Кб»
Так как код ПЗУ Монитора расположен в самом конце адресного пространства - F800…FFFF, счётчик команд PC никогда не покидает диапазона F800…FFFF и во всех циклах M1 на ША биты A11…A15 всегда находятся в лог. "1" и синхронно попадают на вход D-триггера ТМ2. Следовательно, на выводе 5 ТМ2 всегда будет присутствовать только лог. "1" и работа дешифратора ИД7 разрешается.
Следовательно, нижние 32 Кб 0000…7FFF будут под ОЗУ, а верхние 32 Кб - под ВВ55/ВТ57/ВГ75/ПЗУ.
Этот режим действует до тех пор, пока директивой G пользователь не запустит код, находящийся в нижних 32 Кб - 7626, где обычно прописан код C3 инструкции JMP.

User Mode / Режим «Пользователя 64 Кб»
Во время считывания кода инструкции C3 по адресу 7626 счётчик команд PC установится в значение 7626 с выдачей на шину адреса, при этом на A15 установится уровень лог. "0" перед сигналом SYNC, при котором на шину данных выдаётся слово машинного состояния с информацией о начале цикла M1. Следовательно, уровень A15 попадёт на D-вход ТМ2 как лог. "0" и триггер синхронно с Ф2TTL переключится в состояние сброса, а на выводе 5 ТМ2 появится лог. "0", что запретит работу дешифратора ИД7 и совсем отключит из всего адресного пространства 8000…FFFF все ВВ55/ВТ57/ВГ75/ПЗУ.

(В этом моменте я промолчу про наши 16/32 Кб ОЗУ, так как они - тоже подключены к ИД7 и, следовательно, отключаются.)

Т.е. процессор с отключенным ИД7 оказывается в полном вакууме!
(В этом моменте я промолчу про один дополнительный вентиль, который, вдруг, требуется для подключения ОЗУ обратно через вывод 6 ТМ2, на котором теперь, какая неожиданность, оказывается в состоянии лог. "1"!)

Тем самым, ТМ2 выводом 5 управляет включением/отключением ИД7 со всем "хозяйством" (ВВ55/ВТ57/ВГ75/ПЗУ), а выводом 6 управляет отключением/включением всех ИМС ОЗУ РУ3.
(Когда на выводе 5 ТМ2 лог. "1" и работа ИД7 разрешена, выбираются только 8 или 16 ИМС РУ3, в зависимости от объёма памяти.)
Именно выводом 6 ТМ2 мы должны активировать свой дополнительный ИД7, включенный практически параллельно, но выходами которого мы не выбираем никаких ВВ55/ВТ57/ВГ75/ПЗУ, а выбираем дополнительные 24 ИМС ОЗУ РУ3 вместе с 8-ю уже имеющимися. Итого, 32 ИМС РУ3 - 65536 байтов.
Процессор уже не увидит никаких ПЗУ/ВТ57/ВГ75/ВВ55 в адресах 8000…FFFF, так как его ИД7 сейчас отключён, а наш ИД7 активировался и перебирает все 4 банка ОЗУ - 32 ИМС РУ3.
Пользовательский код, работающий в пространстве с счётчиком команд PC в диапазоне 0000…7FFF всегда в цикле M1 устанавливает ТМ2 в состояние "0" заносом бита A15 на вход D-триггер как "0" и на выводе 5 теперь тоже "0", который запрещает работу ИД7 с выборкой ВВ55/ВТ57/ВГ75/ПЗУ, но разрешает выводом 6 и лог. "1" на нём работу нашего ИД7 с выборкой из всех 32 ИМС ОЗУ РУ3.
Таким образом, все команды пользовательского кода, работающие по любым адресам диапаазона 0000…7FFF уже не видят верхние адреса 8000…FFFF через ИД7 с выборкой ВВ55/ВТ57/ВГ75/ПЗУ и, следовательно, через наш добавочный ИД7 получаются доступ к дополнительным ИМС ОЗУ РУ3.
Работают все 32 ИМС ОЗУ РУ3!
Следовательно, все 65536 байт доступны программе пользователя на чтение и запись!
Включая и стековые операции.

Вызов подпрограмм Монитора
Пользовательский код всегда может выполнить, допустим, команду «CALL F803».
После того, как процессор прочитает все три байта этой команды и занесёт в стек значение счётчика команд PC, он загрузит в счётчик команд PC новое значение F803 и начнёт новый цикл.
Посредством сигнала SYNC с выдачей на шину данных флага M1 и адреса F803, линии A11…A15 установятся в лог. "1". Следовательно, так как ТМ2 D-входом подключён к A15, он синхронно по SYNC и Ф2TTL загрузит этот уровень и выставит на вывод 5 уровень лог. "1", разрешая работу ИД7 с выборкой ВВ55/ВТ57/ВГ75/ПЗУ. А так как на выводе 6, соответственно, выставится уровень лог. "0", это запретит работу нашему дополнительному ИД7 и он уже потеряет контроль над 32 ИМС ОЗУ РУ3.
Снова только 8 или 16 ИМС ОЗУ РУ3 будут адресоваться как всегда - пополам с ВВ55/ВТ57/ВГ75/ПЗУ и подпрограмма опроса клавиатуры начнёт исполняться как прежде, но только до команды RET.

Возврат управления пользовательскому коду
Так как по команде C9 RET процессор сначала извлечёт из стека адрес возврата в пользовательский код и поместит его в счётчик команд PC, на следующем цикле M1 адрес A0-A15 будет в диапазоне 0000…7FFF и уровень на A15 будет в лог. "0".
Следовательно, по сигналу SYNC синхронно с Ф2TTL, так как на D-входе ТМ2 будет от A15 идти устойчивый "0", триггер ТМ2 загрузит "0" и на выводе 5 выставит лог. "0", запрещая работу ИД7 с выборкой ВВ55/ВТ57/ВГ75/ПЗУ.
В то же время, на выводе 6 ТМ2 неожиданно выставит лог. "1", чем разрешит работу нашего дополнительного ИД7, который не подключён ни к каким ВВ55/ВТ57/ВГ75/ПЗУ, а выбирает только 32 ИМС ОЗУ РУ3, общей ёмкостью в 65536 байтов.
Пользовательские инструкции, работающие строго по адресам диапазона 0000…7FFF, теперь снова исполняются и в каждом цикле M1 битом A15 в ТМ2 всегда загружают лог. "0", так как счётчик команд PC не теперь прыгает по адресам диапазона 0000…7FFF до тех пор, пока любая команда (JMP/CALL/PCHL/RET) не перегрузит счётчик команд PC в адрес диапазона 8000…FFFF.

Следовательно, если мы начнём переключать страницы и организуем 8 страниц по 64 Кб, мы получим все 512 Кб, но только на пользовательском уровне, пока команды выполняются в нижних 32 Кб ОЗУ. Вызов и переход на любую подпрограмму Монитора запрещает работу дополнительному ИД7 и код монитора видит только 16/32 Кб ОЗУ и ВВ55/ВТ57/ВГ75.

[Mondx]

Alikberov, special for you! Всё таки, ещё какая то память да осталась. Должно работать.

z80_el_disk.PDF

[Alikberov]

Alikberov, special for you! Всё таки, ещё какая то память да осталась. Должно работать.

z80_el_disk.PDF

Ну да, на схеме дешифратор на Q7 выставляет лог. "0" только когда:

• D0/D6/D7 = "1"
• D1/D3 = "0"

Следовательно, срабатывает на операциях с шаблоном маски «casex 8'b11_XX0_X01», что соответствует кодам операций C1/C5/D1/D5/E1/E5/F1/F5…
(Расходовать целый дешифратор под использование всего одной комбинации - не жалко ли?)

Конкретно в рамках данной темы меня волнует лишь перехват операций OUT/IN с кодами D3/DB (маска «casex 8'b11_01X_011», которые должны вызывать подпрограмму виртуализации УВВ в БСВВ с перенаправлением на соответствующий код:

• IN 03 - CALL F803
• IN 06 - CALL F806
• OUT 09 - CALL F809
• OUT 0C - CALL F80C
• IN 12 - CALL F812
• OUT 15 - CALL F815
• OUT 18 - CALL F818
• IN 1B - CALL F81B
• и т.д.

Тем самым, на Бейсике вместо «PRINT USR(-2045)» можно будет использовать «PRINT IN(3)», что гораздо изящнее!
(И довольно любопытно, так как во все программах трёхбайтовый CALL F8XX заменился бы на IN/OUT в два байта.)

Эскиз подобной системы

Code: Select all

HIBYTE: EQU     002H    ; Порт хранения старшего байта №2
GETKEY: EQU     003H    ; Порт "чтения символа с клавиатуры"
PUTCHR: EQU     009H    ; Порт "вывода символа на экран"
PUTEXT: EQU     018H    ; Порт "вывода текста на экран"
RETURN: EQU     06CH    ; Порт "завершения работы"
;;;;;;;;;;;;;;;;;;;;;;;;;
        ORG     01100H

        MVI     A,HELLO>>8
        OUT     HIBYTE  ; Передаём старший адрес ссылки на сообщение.
        MVI     A,HELLO
        OUT     PUTEXT  ; Печатаем приветствующее сообщение на экран.
WAIT:   IN      GETKEY  ; Ожидаем ввода с клавиатуры
        CPI     00DH    ; и реагируем только на код клавиши ВК
        JNZ     WAIT    ; с зацикливанием до её нажатия.
        MVI     A,007H  ; Код символа "звонок"
        OUT     PUTCHR  ; выводим в терминал.
        IN      RETURN  ; Завершаем работу программы.
        HLT             ; Заглушка (на случай отсутствия "аппаратной виртуализации портов").
;;;;;;;;;;;;;;;;;;;;;;;;;
HELLO:  DB      13,10
        DB      'PRESS <RETURN> KEY...',0

А вот как это должно отработаться системой на аппаратном уровне:

Code: Select all

1108 DB 03    IN    03  ; Команда ввода с порта (на шине данных в цикле M1)
     DD DD DD CALL* DDDD; Команда, подставляемая процессору

И затем - на программном уровне:

Code: Select all

DDDD .. .. .. .. .. ....; Подпрограмма обработки перехвата команд IN/OUT
        STA     ACCUM   ; Временно сохраняем аккумулятор.
        XTHL            ; Считываем адрес после вызова "CALL*".
        DCX     H       ; Корректируем счётчик команд
        DCX     H       ; на три позиции назад,
        DCX     H       ; чтобы прочитать обратно
        MOV     A,M     ; код замаскированной команды
        INX     H       ; и убедиться,
        CPI     0D3H    ; что это - либо код команды OUT,
        JZ      OUTSUB  ; и передать управление подпрограмме,
        CPI     0DBH    ; либо код команды IN,
        JZ      INSUB   ; с передачей управления на подпрограмму.
        ...             ; Какая-то непонятная команда?
INSUB:  MOV     A,M     ; Читаем код "виртуального порта"
        INX     H       ; и корректируем указатель на следующую команду,
        XTHL            ; возвращая его обратно в стек.
        PUSH    H       ; Запоминаем HL, чтобы пользователь "не потерял его",
        MVI     H,0F8H  ; перед тем, как прыгать на точки Монитора.
        MOV     L,A     ; Сохраняем "код порта" как младший байт указателя.
        XTHL            ; Переносим адрес в стек и восстанавливаем HL.
        LDA     ACCUM   ; Восстанавливаем значение аккумулятора (для подпрограммы F806 он важен!).
        RET             ; Теперь управление передаётся на (0xF800+<код_порта>).
        ...
OUTSUB: MOV     A,M     ; Читаем код "виртуального порта",
        INX     H       ; и корректируем указатель на следующую команду,
        XTHL            ; возвращая его обратно в стек.
        CPI     002H    ; Код "вспомогательного порта"?
        JZ      OUTHI   ; Сохраним его в "подстеке".
        CPI     009H    ; Код "порта печати символа"?
        JZ      OUTCHR  ; Переходим к исполнению.
        CPI     018H    ; Код "порта вывода текста"?
        JZ      OUTEXT  ; Переходим к исполнению.
        ...
OUTHI:  STA     HIPORT  ; Служебная ячейка.
OUTEND: LDA     ACCUM   ; Восстанавливаем значение аккумулятора
        RET             ; перед возвращением в код пользователя.
        ...
OUTCHR: LDA     ACCUM   ; Восстанавливаем значение аккумулятора
        PUSH    B       ; и запоминаем BC,
        MOV     C,A     ; так как код передаётся через регистр C
        CALL    0F809H  ; в попрограмме печати символа.
        POP     B       ; Восстанавливаем BC обратно
        RET             ; и возвращаем управление программе пользователя.
        ...
OUTEXT: PUSH    H       ; Операции IN/OUT не портят регистры - сохраняем!
        LDA     HIPORT  ; Восстанавливаем значение "порта 02",
        MOV     H,A     ; чтобы использовать его как старший байт указателя.
        LDA     ACCUM   ; Восстанавливаем текущее значение Аккумулятора
        MOV     L,A     ; для уточнения указателя на текст
        PUSH    PSW     ; Запоминаем все регистры,
        PUSH    B       ; которые будут испорчены
        CALL    0F818H  ; подпрограммой печати текста.
        POP     B       ; Затем - восстанавливаем все регистры
        POP     PSW     ; обратно, перед передачей
        POP     H       ; управления пользовательскому коду
        RET             ; как обычно.

[shiny]

Кстати на гф во вракипедии написано(https://zx-pk.ru/wiki/%D0%A0%D0%B0%D0%B4%D0%B8%D0%BE_86%D0%A0%D0%9A)

35D0h - 3FFFh 76D0h - 7FFFh ОЗУ. Видеопамять (может быть программно перемещена

Как реализовать перемещение памяти?

[Mondx]

Ну да, на схеме дешифратор на Q7 выставляет лог. "0" только когда:

• D0/D6/D7 = "1"
• D1/D3 = "0"

Следовательно, срабатывает на операциях с шаблоном маски «casex 8'b11_XX0_X01», что соответствует кодам операций C1/C5/D1/D5/E1/E5/F1/F5…
(Расходовать целый дешифратор под использование всего одной комбинации - не жалко ли?)

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

[vital72]

Кстати на гф во вракипедии написано(https://zx-pk.ru/wiki/%D0%A0%D0%B0%D0%B4%D0%B8%D0%BE_86%D0%A0%D0%9A)

35D0h - 3FFFh 76D0h - 7FFFh ОЗУ. Видеопамять (может быть программно перемещена

Как реализовать перемещение памяти?

перепрограммированием ПДП.
только это тут не в тему.

[Alikberov]

Спасибо у тебя не принято говорить?

За разглашение, некогда, военной тайны?
Спасибо!

Однако, как это мне может помочь конкретно в продвижениях развития темы?

Ключевой момент с ТМ2 я как бы уже набросал.
А вот перехват кодов D3/DB команд OUT/IN подобным образом не реализовывается.
И расключение дополнительных банков РУ3 всё ещё не очень ясно.

[shiny]

Кстати на гф во вракипедии написано(https://zx-pk.ru/wiki/%D0%A0%D0%B0%D0%B4%D0%B8%D0%BE_86%D0%A0%D0%9A)

35D0h - 3FFFh 76D0h - 7FFFh ОЗУ. Видеопамять (может быть программно перемещена

Как реализовать перемещение памяти?

перепрограммированием ПДП.
только это тут не в тему.

тогда где?

[Shaos]

Кстати на гф во вракипедии написано(https://zx-pk.ru/wiki/%D0%A0%D0%B0%D0%B4%D0%B8%D0%BE_86%D0%A0%D0%9A)

35D0h - 3FFFh 76D0h - 7FFFh ОЗУ. Видеопамять (может быть программно перемещена

Как реализовать перемещение памяти?

перепрограммированием ПДП.
только это тут не в тему.

тогда где?

Создал новый топик: viewtopic.php?f=93&t=22389

[aviator]

Вызов подпрограмм Монитора
Пользовательский код всегда может выполнить, допустим, команду «CALL F803».

Но вы же сами говорите, что пользовательский код имеет доступ ко всеми ОЗУ от 0 до FFFF. А если по этому адресу пользовательская подпрограмма в ОЗУ?
Вот поэтому я и говорил, что большой минус, что нет программных прерываний.
Гораздо экономнее (и функциональнее) будет не 2К отдавать под монитор, а использовать таблицу векторов, которая:
а) находится в ОЗУ, поэтому можно будет организовать переопределение функций при необходимости,
б) позволит размещать функции в разных страницах, хоть ОЗУ, хоть ПЗУ.
в) позволит перекраивать реализацию функций не заботясь о том, что адрес начала подпрограммы "уедет".

[Alikberov]

Но вы же сами говорите, что пользовательский код имеет доступ ко всеми ОЗУ от 0 до FFFF. А если по этому адресу пользовательская подпрограмма в ОЗУ?

Скажите пожалуйста, Вы же не читали ни строчки отсюда?
Там я подробно изложил, что использую бит #15 счётчика команд PC за флаг:

• PC<8000 - режим пользователя 64 Кб
• PC>8000 - режим БСВВ/Монитора

А значит, приложение может хранить по адресам 8000…FFFF данные, читая их и перезаписывая, но не может их использовать как часть программного кода непосредственно!

В системах x86 есть так называемый «защищённый режим» и так называемые «привилегии» - нструкции приложений имеют низкий уровень привилегий и не имеют возможность выполнять критически важные операции.
У меня бит #15 счётчика команд PC примерно так и работает: Прикладной код не может запускаться на адресах 8000…FFFF, но хранить данные - может…

[Shaos]

Мы где-то на просторах форума много-много лет назад обсуждали теоретическую возможность разделять код и данные, пользуясь словом состояния процессора ВМ80 и пришли тогда к выводу, что это бесполезно ибо M1 подсвечивает только ПЕРВЫЙ БАЙТ инструкции, т.е. например JMP #0123 увидится на шине как код только на первом байте #C3, а второй и третий (#23 и #01) уже пойдут вычитываться как данные...

[Alikberov]

Мы где-то на просторах форума много-много лет назад обсуждали теоретическую возможность разделять код и данные, пользуясь словом состояния процессора ВМ80 и пришли тогда к выводу, что это бесполезно ибо M1 подсвечивает только ПЕРВЫЙ БАЙТ инструкции, т.е. например JMP #0123 увидится на шине как код только на первом байте #C3, а второй и третий (#23 и #01) уже пойдут вычитываться как данные...

Это верно.
Но конкретно сейчас обсуждается не разделение на программу и данные, а разделение на память программы пользователя и память программы Монитор, где M1 перекидывает их всего 1 раз.

Если так же - всё ещё не очень понятно, вот схема.
Вверху - системный дешифратор ИД7 на плате РК с выбором ППА/ПДП/ПЗУ и ОЗУ до 32 Кб (два банка РУ3 - 16 ИМС).
Внизу - дополнительный ИД7 (пользовательский) для выбора ОЗУ всех 64 Кб (четыре банка РУ3 - 32 ИМС).
(Старший бит A15 счётчика команд PC фиксируется в триггере как флаг "32 Кб / 64 Кб" и активирует системный или пользовательский дешифратор, меняя конфигурацию памяти.)