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

[Alikberov]

Пока только в рамках Chrome-расширения для онлайн эмулятора на уровне инжекции кода рассматривается экспериментальная доработка РЛК с расширением памяти.
(Думаю, термин «инжекторная эмуляция» здесь будет кстати…)

• Функция эмуляции процессора дополнена сигналом «Fetch» - аналогом цикла «M1»
• Функция эмуляции памяти дополнена условием Fetch-проверки, чтобы перехватывать коды псевдо-префиксов на псевдо-аппаратном уровне
• Процедура ассемблера дополнена дополнительными инструкциями для поддержки псевдо-префиксов

Псевдо-Префиксы
Наткнувшись в очередной раз на заметку (ссылка / цитата) на семь бессмысленных команд процессоров i8080 и z80, решил попробовать сделать набросок схемы для их аппаратного перехвата.
А именно, связка К155СП1 и К155ИР1 следит в цикле M1 процессора за считываемым кодом операции. Если байт кода является одним из набора MOV-инструкций с холостой пересылкой, то он ИМС СП1 его выявляет и сигнализирует ИМС ИР1 о его регистрации. Сам процессор эти коды отрабатывает как обычно, но схема страничной памяти на следующей инструкции при доступе к памяти подставит дополнительный банк памяти размером до 448 Кб.

• Код 40 / команда «MOV B,B» - префикс #6: Адресация 60000…6FFFF
• Код 49 / команда «MOV C,C» - префикс #7: Адресация 70000…7FFFF
• Код 52 / команда «MOV D,D» - префикс #4: Адресация 40000…4FFFF
• Код 5B / команда «MOV E,E» - префикс #5: Адресация 50000…5FFFF
• Код 64 / команда «MOV H,H» - префикс #2: Адресация 20000…2FFFF
• Код 6D / команда «MOV L,L» - префикс #3: Адресация 30000…3FFFF
• Код 76 / команда «HLT» - префикс #0 (по умолчанию): Адресация 00000…0FFFF
• Код 7F / команда «MOV A,A» - префикс #1: Адресация 10000…1FFFF

Чтобы в регистре всегда по умолчанию была выбрана страница #0, старшие два бита - инвертируются. Потому, в нормальном состоянии регистр хранит биты «000», будто после несуществующего псевдо-префикса с кодом 76…

В ассемблере появился набор инструкций для работы с дополнительными банками памяти:

• Код 7F+02 / команда «STAX B1» - запись в страницу 10000…1FFFF
• Код 64+1A / команда «LDAX D2» - чтение из страницы 20000…2FFFF
• Код 6D+6E / команда «MOV L,M3» - чтение из страницы 30000…3FFFF
• Код 52+77 / команда «MOV M4,A» - запись в страницу 40000…4FFFF
• Код 5B+96 / команда «SUB M5» - вычитание байта страницы 50000…5FFFF
• Код 40+C1 / команда «POP B6» - стековое извлечение из страницы 60000…6FFFF
• Код 49+D5 / команда «PUSH D7» - стековая запись в страницу 70000…7FFFF
• Код 7F+E3 / команда «XTHL1» - стековый обмен со страницей 10000…1FFFF
• имеются побочные команды «RET1…7» и т.п.

(Аналогично как и в процессоре ВМ1 с памятью до 128Кб и доступом через H1L1…)

Написан экспериментальный код:

• Редактор дампа с доступом к дополнительным банкам с простейщим механизмом отладки через исполнение одной инструкции
• Набросок файловой системы с форматом ORDOS для поиска и хранения файлов в дополнительных банках под именами псевдо-дисков «A: B: C: D: E: H: L:»
• Набросок игрового поля с графикой и цветом
• Механизм поддержки перегружаемого знакогенератор и тайлов

 Видео с демонстрацией

На практике выяснилось, что доступ к дополнительным банкам - статический (код страницы указывается непосредственно префиксов) и требует некоторых программных механизмов для динамического доступа (в редакторе дампов и файловой системе).
Так, для обеспечения виртуальной инструкции «MOV A,M#» для чтения из произвольной страницы (диска), сначала необходимо поместить код конкретной инструкции (7F+7E / 64+7E / 6D+7E / 52+7E / 5B+7E / 40+7E / 49+7E) в память (аналогично как директива G Монитора с записью кода инструкции JMP непосредственно в служебную область), чтобы обращаться к теневым банка посредством CALL-вызовов, что не очень практично…

Дескрипторы
Гораздо более гибкий способ с обеспечением памяти до 1 Мб - 16 Мб может предоставить более затратная доработка, где префиксы работают как дескрипторы страниц (аналогично как x86-сегментs CS: DS: ES: SS: FS: GS:), где из набора дескрипторов в 512 Кб можно разворачивать память до 16 Мб перенастройкой семи регистров, закреплённых за префиксами.

Знакогенератор КОИ7 и КОИ8
В очередной раз внимательно вчитываясь в официальную документацию по ИМС i8275, внимание привлекли коды E4 и E5, которые должны вентильной добавкой (довольно неудобной на практике) формировать, так называемые, символы рамок. Причём, в отличии от универсальных атрибутов с ограничением количества до 16 на строку, символы рамок не имеют ограничения на их количество в строке и не сбивают цикл ПДП, являясь как бы отображаемыми символами.
Именно два кода E4 и E5 выставляют на выводе LA0 ВГ75 устойчивый логический "1" на всю высоту знакоместа. Причём, вывод HLGT ВГ75, управляющий яркостью отображения, локально, на период отображения символа "рамки" может быть как выключеным (код E4), так и включён (кодом E5).
Если добавить пару вентилей и триггер ТМ2, можно обеспечить переключение с основного знакогенератора РК - КОИ7-С, на дополнительный знакогенератор - КОИ8:

• Набор КОИ7 включается всегда в начале строки сигналом HRTC и сбросом дополнительного ТМ2
• Код E4 выставит LA0 и разрешит поступление тактовых импульсов через вентиль на ТМ2. Первый триггер установится в "1" и переключит ПЗУ в режим ASCII с латиницей заглавных и строчных литер
• Код E5 выставит LA0 и разрешит поступление тактовых импульсов через вентиль на ТМ2. Первый триггер установится в "1" вместе со вторым триггером, переключив ПЗУ на набор КОИ8 с кириллицей заглавных и строчных литер с символами псевдографики

Тем самым, в отличии от других схем доработок знакогенератора, переключение происходит ни тумблерами, ни битами ППА, ни атрибутами.
Это позволяет в одном слове иметь нормальную смесь заглавных и строчных литер одного из алфавитов, что более естественнее и красивее, чем разделить знакогенератор на половину заглавных и половину строчных литер двух алфавитов.

Схема с доработкой - ниже.

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

[Alikberov]

Прежде всего, позвольте совершить маленькое лирическое вступление, чтобы подготовить читателя к сути данной темы.

Адресное пространство систем Windows
Как известно, в 32-разрядной версии систем всё адресное пространство делится пополам: Нижние 2 Гб (50%) приложения и верхние 2 Гб (50%) системы. Ключём реестра можно заставить систему грузиться только в верхний 1 Гб (25%), предоставив до 3 Гб (75%) приложениям.
Более подробно описывается всё здесь.
В 64-разрядных системах дело обстоит несколько грубее и из 16 экзабайтов адресного пространства только 256 Тб канонического пространства - подробнее здесь.

Но, вопрос не в том, что именно моим приложениям не хватает тех же 2 Гб или 3 Гб, а вообще по эстетическим соображениям!

Вот только представьте, что Вы владеете квартирой в 4096 м² или 16 комнатами по 256 м², но 2048 м² или 8 комнат из которой Вам не доступны, так как ЖЭК запрещает ими пользоваться!
Это, как минимум, просто не красиво, так как формально Вы владелец жилой площади в 4096 м², половиной которых заведует некое Управление.

То есть, пусть даже из всех сотен терабайт мне необходимо только 1 Гб, но вот почему я не могу прогуляться по всему обозримому пространству?

Порты ввода/вывода Windows
В системах Windows инструкции IN/OUT являются привелегированными и попытка использовать их приводит к исключению.

Теория
С помощью тематических ресурсов выяснилось, что используя собственный обработчик исключений можно отлавливать моменты, когда программа вдруг лезет в верхние 2 Гб или к портам ввода-вывода.
Чисто экспериментально, лет 16 тому назад мною писался код-оболочка, который при доступе к верхним 2 Гб памяти зеркально подставляет нижние 2 Гб. То есть, технически - исключения происходят, но формально они уже не обрушивают прикладной код и не завершают его.
Так же, исключения на командах IN/OUT мною обрабатываюсь особым образом и вместо регистра DX проверялся уже целый EDX, но никаких физических портов IBM PC даже не эмулировалось. Использовалась собственная карта портов:

• Порты камеры в 3D-сцене OpenGL
• Порты освещнения 3D-сцены OpenGL
• Порты аккустического окружения в OpenAL

Иными словами, вместо эмуляции портов устройств низкого уровня в моей экспериментальной оболочке организовывалась сеть устройств самого высокого уровня, в обход типичным CALL-вызовам.
То есть, запущенная в подобной среде приложение использет инструкции IN/OUT для взаимодействия с библиотеками Windows, а вот CALL используются только для вызовов внутренних подпрограмм приложения.

Да, постоянно вырабатываемые исключения и их обработка, конечно, жутко всё тормозило!
Но, экспериментальные программы работали уже как некие x86-скрипты в системе очень высокого уровня, которые нельзя уронить, так как в случае чтения/записи в несуществующие ячейки памяти либо просто возвращался рандом, либо ничего не происходило, кроме просадки производительности.

То есть, лет 15 тому назад, я убедился, что саму концепцию операционных систем изначально можно было строить несколько иначе.

РАДИО-86РК / 64 Кб
Как известно, во многих Микро-ЭВМ доля адресного пространства занимается УВВ и ПЗУ:

• ZX-Spectrum: 16 Кб ПЗУ подавляющим большинством игр и программ никак не используется
• Орион-128: ячейки F400…FFFF под УВВ и ПЗУ - 3 Кб
• Радио-86РК: 16/32 Кб нижнего адресного пространства под ОЗУ и верхние 32 Кб под УВВ/ПЗУ

Потому, чисто с эстетической точки зрения я задумался, а можно ли вообще открыть все 100% адресного пространства пользователю?

То есть, для системного кода в ПЗУ предоставлять традиционное адресное пространство РЛК, а для пользовательского кода, работающего обычно в нижних адресах 32 Кб, в верхних адресах открывать дополнительные 32 Кб ОЗУ и скрывать всё остальное (ПЗУ/ВВ55/ВТ57/ВГ75).

Так как i8080/z80/ВМ80 умеют выдавать сигнал начала цикла M1 с чтением кода очередной инструции, у счётчика инструкций PC легко проверить "уровень" кода - «приложение» или «Монитор».

• При A15="0" в момент Ф2TTL с SYNC и D5(статус M1) - читается код приложения
• При A15="1" в момент Ф2TTL с SYNC и D5(статус M1) - читается код приложения

Тем самым, если выполняется код в верхних 32 Кб (DOS или Монитор), дешифратор ИД7 активируется и доступно всё привычное пространство РК. А вот выполняемому прикладному коду в нижних 16/32 Кб не очень нужно читать содержимое того же ПЗУ, потому ИД7 блокируется и верхние 32 Кб открываются как дополнительное ОЗУ для чтения и записи. Тем самым, пользователь имеет все 64 Кб (65536 байтов) ОЗУ.

В то же время, любые команды, типа «CALL F803» или «JMP F86C» в цикле M1 вновь включит ИД7 и подпрограммы Монитора встанут на свои места (пользовательский код не может пересекать счётчиком команд PC границу адреса 7FFF//8000). Это позволит пользователю отдать все 64 Кб под чтение и запись, но только 32 кб доступно под исполнение кода.

Эскиз схемы
Так как ИМС D10.2 и D10.3 используется для выборки двух банков по 16 Кб, в модели с 64 Кб они ни к чему и могут использоваться по другому назначению.
Следовательно, ИМС D10.4 и D5.3 также освобождаются.

• На ИМС D10.1 и D10.4 собираем RS-триггер для принудительной выборки ПЗУ после сигнала Сброса, освобождая этим ИМС D13.1 ТМ2 (не D13.2, судя по нумерации выводов)
• На D-вход ИМС D13.1 ТМ2 вывод 2 подаём сигнал с ВМ80 бита адресации A15: Теперь триггер будет хранить режим «32/64 Кб» и включать/отключать ИД7 в зависимости от позиции счётчика команд PC - нижние или верхние 32 Кб кода
• На C-вход ИМС D13.1 ТМ2 вывод 3 с помощью элемента 3-И (или трёмя диодами с резистором) подаём сигнал стробирования из смеси трёх уровней: вывод 4 ВМ80 бит D5 слова статуса с флажком цикла M1, вывод 19 ВМ80 SYNC с сигналом о выдаче статусного слова и Ф2TTL синхронизации

Таким образом, чисто по прикидкам, половинка ТМ2 будет сигнализировать об уровне привелегированности выполняемого кода и включать либо ИД7, либо все 64 Кб.

P.S.: Ниже - эскиз доработки схемы с использованием диодов.
(С памятью и КП11 пока не разбирался.)

[imsushka]

а PCHL ?

[b2m]

а PCHL ?

Переключение происходит не в момент исполнения команды PCHL, CALL или RET, а в момент исполнения следующей команды (той куда указывал HL, параметр команды CALL или адрес на вершине стека).

Хотя на мой взгляд, страничная организация и проще, и удобнее, и памяти больше 64Кб можно поставить. Если использовать память только для данных, преимущество такой схемы - так себе. Другое дело - возможность автоматической смены страницы при выполнении комадны по определённым адресам.

[Alikberov]

Хотя на мой взгляд, страничная организация и проще, и удобнее, и памяти больше 64Кб можно поставить.

Ну, тема же про 512 Кб / 16 Мб. То есть, страничная память предусматривается.

Типа, нижние 32 Кб - 16 страниц из 512 Кб, верхние 32 Кб - 16 страниц из 512 Кб.
Куча в 512 Кб - общая (один ИР23 хранит и КП11 селектирует нижние/верхние 32 Кб).

Вообще-то, на D-вход нужно подавать не один A15, а логикой 3-И адреса A13/A14/A15, чтобы режимы переключались на границе DFFF/E000, чтобы под код пользователя отдать как можно больше адресации (до 56 Кб), что также, видимо, можно добавлением ещё двух диодов сделать?

Другое дело - возможность автоматической смены страницы при выполнении комадны по определённым адресам.

Другое дело - дать пользователю, для начала, все 65536 ячеек под запись и чтение (хранение) данных, без всяких "если" (F800-FFFF под ПЗУ и т.д.), чтобы программа чувствовала себя как дома - каждый сантиметр пространства в доступе.

А вот переключать страницы (нижние или вехние 32 Кб) - отдельная подпрограмма ПЗУ, которая и переключит их в ВВ55.

Короче говоря…

Шаг №1: Переключение режимов «16/32 Кб» / «64 Кб»
Сейчас вопрос в другом: Будет ли вообще по схеме на трёх диодах ТМ2 переключать режимы вообще?

Кстати…
Оригинальная (журнальная за 1986 год) прошивка ПЗУ Монитора по адресу FD83 содержит байты:

Code: Select all

     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FA83 -- -- -- 7E E1 C9 -- -- -- -- -- -- -- -- -- --
====================================================
FA83 7E       MOV   A,M
FA84 E1       POP   H
FA85 C9       RET

     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FD83 -- -- -- 77 FD 22 00 -- -- -- -- -- -- -- -- --
====================================================
FD83 77       MOV   M,A
FD84 FD 22 00 CALL* 0022

     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FDB7 -- -- -- -- -- -- -- 77 C9 -- -- -- -- -- -- -- <-- только версия ПЗУ 32 Кб
====================================================
FDB7 77       MOV   M,A
FDB8 C9       RET

     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
FDCF -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 02
FDD0 01 B0 F8 14 09 C9 -- -- -- -- -- -- -- -- -- --
====================================================
FDCF 02       STAX  B
FDD0 01 B0 F8 LXI   B,F8B0
FDD3 14       INR   D
FDD4 09       DAD   B
FDD5 C9       RET

То есть, так как в режиме «64 Кб» код пользователя видит верхние 32 Кб 8000…FFFF как дополнительное ОЗУ, доступ к ВИ53/ВВ55/ВТ57/ВГ75 закрыт, именно через CALL-обращения на перечисленные точки позволит получить доступ в привычном РК-виде.

Тем самым, получается подобие хака «User Mode» / «Kernel Mode»…

[aviator]

Правильно, это всё хаки. И не хватает двух вещей - регистров страниц и софтверных прерываний.
Я сам долго думал над подобными расширениями, правда на "Специалисте". И все наброски неминуемо приводили к 8086.

[Alikberov]

Правильно, это всё хаки. И не хватает двух вещей - регистров страниц и софтверных прерываний.
Я сам долго думал над подобными расширениями, правда на "Специалисте". И все наброски неминуемо приводили к 8086.

Ну, да. Потому-то в самом начале темы я и рассматривал вариант на СП1 и ИР1 для перехвата «сегментных префиксов»:

• Код 40 инструкции «MOV B,B» - виртуальный префикс «BS:»
• Код 49 инструкции «MOV C,C» - виртуальный префикс «CS:»
• Код 52 инструкции «MOV D,D» - виртуальный префикс «DS:»
• Код 5B инструкции «MOV E,E» - виртуальный префикс «ES:»
• Код 64 инструкции «MOV H,H» - виртуальный префикс «HS:»
• Код 6C инструкции «MOV L,L» - виртуальный префикс «LS:»
• Код 76 инструкции «HLT» - выбран по умолчанию как префикс «MS:»
• Код 7F инструкции «MOV A,A» - виртуальный префикс «AS:»

Что уже даёт, как минимум, 512 Кб: 8 префиксов по 64 Кб - 512 Кб.

То есть, концептуально идея не изменилась.
Просто, нашёл способ на уже имеющихся в схеме ИМС достичь переключения режимов «32 Кб» / «64 Кб».
При этом, перепрошивать ПЗУ Монитора вовсе и не надо.
Складывается ситуация как и с переходом от IBM PC/XT на PC/AT: Система стартует в реальном 16-битном режиме с 640 Кб ОЗУ, а затем уже опционально переключается в расширенный защищённый режим.

Потому я стараюсь не переходить границы в этом плане.
Даже ПЗУ Монитора не изменяется в качестве аргумента, что это - тот же старый добрый РК.

Тем более, если от ТМ2 вывод 4 дотянуть до одного из битов ППА D20, программно можно управлять переключениями режимов и заставить триггер находиться в режиме постоянного "1", тогда вся система будет полностью функционировать как 16/32 Кб в режиме полной совместимости.

[aviator]

А потом взять Verilog Z80 и добавить туда сегментную адресацию, новые регистры, с сохранением обратной совместимости. И понять, что это уже проходили...
Все мои эксперименты (а надо было где-то хранить и G-code и интерпретатор и операционку - оверлеи идут лесом, ибо фреза будет ждать пока оверлей подгрузится с флопика) привели к переключению страниц по 4K. 16 регистров страниц, доступных по IN/OUT. Максимум до 1МБ ОЗУ. У меня было меньше, но я был ограничен статическим ОЗУ, что было выковыряно из видеокарт. Почему по 4К? - а потому, что выровнено по границе тетрады. Удобно преобразовывать в железе - младшие 3 отправляются на шину адреса памяти, а старшие выбирают регистр страницы, и его значение тоже отправляется на шину адреса. И получается 20 разрядов.
Но я ушел от отображения портов на память, то есть, совместимости не было уже не было ни с чем. Велосиподостроение оно такое.

[Alikberov]

Прорисовал точнее и красивее.
Убрал диоды и добавил новый элемент - ЛИ3 (на схеме никак не обозначил его выводы).

• элементы D10.1 и D10.4 составляют RS-триггер "холодного старта"
• "плечо" на элементе D10.1 после Сброса устанавливается в "0" и через элемент D4.3 принудительно устанавливает выборку ПЗУ
• "плечо" на элементе D10.4 после Сброса устанавливается в "1" и блокирует работу ИД7 на выводе 4
• вывод 2 входа D ТМ2 подключён к A15 ВМ80 для запонимания уровня исполняемой инструкции (A15="0" - пользователь / A15="1" - код ПЗУ Монитора или DOS)
• вход тактов C вывод 3 ТМ2 управляется дополнительной ИМС ЛИ3 (любой элемент) для синхронного стробирования триггера в момент фронта Ф2TTL и лог. "1" на выводе 4 D5 процессора (флаг цикла "M1") и выводе 19 SYNC процессора
• вывод 4 входа S ТМ2 служит для включения 100% совместимости при подаче на него уровня с вывода 11 элемента D10.4 составного RS-триггера: Желательно довесить на него резистор к напряжению +5 Вольт

Ожидается (не гарантирую), что после Сброса и запуска Монитора всё будет почти как прежде (пользователи 16 Кб вообще ничего не заметят) и можно даже грузить программы, так как перемычка «16 / 64» гарантирует подавление синхронного переключения ТМ2, принудительно устанавливая его в "1".

Для активации экспериментального режима с 64 Кб перемычку следует удалить (желательно также подтянуть резистором вывод 4 ТМ2 к напряжению +5 Вольт).
Однако, прежде всего, необходимо расширить само ОЗУ до 64 Кб. Например, как это сделано в оригинале ПЭВМ "Специалист", блок из 24 ИМС РУ3 включить к имеющимся уже ОЗУ, предварительно организовав их выборку дополнительным ИМС ИД7, вывод 6 которого следует подключить к выводу 6 ТМ2.

[b2m]

Я сам долго думал над подобными расширениями, правда на "Специалисте".

привели к переключению страниц по 4K. 16 регистров страниц, доступных по IN/OUT.

"Специалист" с такой организацией памяти был, и называется он "Русич".

[aviator]

"Специалист" с такой организацией памяти был, и называется он "Русич".

Я даже с "Русичем" сталкивался во Дворце юных техников. Но нам документацию по внутреннему устройству не давали. Был доступен только бейсик, а уже притарабанил на дискетах CP/Mовский софт, что работал на "Орионе" и запускался на "Русиче", типа C, DBase, SuperCalc.
А свою станцию управления ЧПУ я велосипедил независимо примерно в то же время.
И несколько лет назад разговаривал с разработчиками, но доки все были утеряны. Его ж разработали и делали в моём родном Белгороде.

[aviator]

Но всё уже придумано до нас. Только что прочитал про eZ80. 24 бит адрес в расширенном режиме, либо переключаемые 64КБ окна в обычном (что кстати даёт возможность захачить что-то типа многопользовательского режима с изоляцией).

[Alikberov]

Но всё уже придумано до нас. Только что прочитал про eZ80. 24 бит адрес в расширенном режиме, либо переключаемые 64КБ окна в обычном (что кстати даёт возможность захачить что-то типа многопользовательского режима с изоляцией).

Zilog разработал множество вариантов z80 - даже нету такого разнообразия ZX-Spectrum на каждом из процессоров!

Конкретно в РАДИО-86РК - только К580ВМ80А.
Вот от этого и отталкиваюсь.

Если не ошибаюсь, ЮТ-88 использовал перехват доступа к стеку для каких-то нужд?
Этот вариант я тоже рассматривал, но из-за того, что только на i8080/ВМ80 это доступно и уже никак не реализуемо под i8085 и z80, его отверг.

Мои варианты доработок максимально универсальны в этом плане - используют только сигналы начала Цикла M1 и могут работать практически на всех процессорах: i8080 / i8085 / z80 / MOS 6502 (у которого вообще отсутствуют портовые инструкции IN/OUT).
(Да, в качестве эксперимента можно и на MOS 6502 собрать РЛК! Тем самым, ВК28/ВК38 не рассматриваются.)

То есть, хоть я и несколько вольно перебираю варианты доработок, но всех они - универсальны и способны работать:

1. на i8080 / ВМ80
2. на i8085
3. на z80
4. на MOS 6502

[aviator]

Если мне память не изменят, то Z80, Z180 и eZ80 производятся до сих пор. Z280 и Z380 вроде как нет.
Так что если и лепить что-то то на том, что можно относительно беспроблемно достать. И совместимость с РК-шкой легко сделать можно будет.

[Alikberov]

Если мне память не изменят, то Z80, Z180 и eZ80 производятся до сих пор. Z280 и Z380 вроде как нет.
Так что если и лепить что-то то на том, что можно относительно беспроблемно достать. И совместимость с РК-шкой легко сделать можно будет.

Вариантов по всем канонам с ВК28 и ВН57 - уйма. Смысл изобретать очередное?

Конкретно в данной теме я занимаюсь не изобретательством, а поиском теневых возможностей самого РК при незначительной доработке.
А так, РЛК с 48 Кб - Специалист, РЛК с 61 Кб - Орион.
На сколько мне известно, нету ни одной машины с линейным ОЗУ в 65536 байтов, так как в основном - страничность используется.

Иными словами, тема не про то, как конкретно в РАДИО-86РК расширить память, а про то, чтобы конкретно РАДИО-86РК использовать в качестве испытательной машины для проверки концепции линейных 64 Кб.