Виртуализация ZX

[Eltaron]

Нет смысла\интереса в навешивании мега-куска силикона на котором можно было бы весь ibm/370 завести только ради виртуализации спектрума.

Какой-то кусок силикона всё равно понадобится, т.к. при переключении задачи надо считывать текущее состояние регистров процессора и куда-то сохранять.

0. Работает задача T1, пришло время переключиться на T2.
1. Подсунули процессору другую (временную) память, в которой по адресу #0066 (обработчик NMI) лежит процедура сохранения всех регистров в известную область память (пусть она, скажем, кидает всё на стек).
2. Сгенерировали NMI
3. По состоянию M1 и шине адреса отследили когда процедура выполнилась до конца, переложили все значения регистров в удобное место.
4. Выполняем процедуру, восстанавливающую значение регистров для продолжения выполнения задачи T2.
5. Подсовываем процессору память процесса T2.
Всё, переключились.

В п.1 есть вероятность, что указатель стека смотрит на адреса, где находится сама процедура обработки NMI, и придется всё чуть усложнить, подсовывая процессору по M1 код процедуры, не храня его в ОЗУ. В принципе, можно и запись в память точно так же перехватывать, ничего не реальности не сохраняя.

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

[SfS]

ИМХО нормальная виртуализация возможна и нужна только в современных клонах, таких как PentEvo.

Памяти много, можно организовать на ПЛИС схему виртуальных адресов и переключения страниц при обращении по нужным RST.

Задача интересная, но и сложная. ПО для такого режима нет.

[psb]

как доступ к железу разруливать? памяти много, ее можно поделить, а железо - одно.

[ZEK]

схему виртуальных адресов

для виртуальной адресации не хватает одной мелочи, исключения у процессора (выскакивают если не прошли какие либо проверки ДО выполнения инструкции)

[alone]

Схема может подсунуть пустышку вместо памяти, к которой незаконно обращается процесс. Так что проблема не в этом. Проблема в командах IM 0/1/2, DI, от которых невозможно защититься.

А хотя... схема может подменять опкоды во время их чтения.

[TSL]

Нужно или нужно - вопрос 90-х, когда действительно было актуальным запустить на одном спеке несколько системных программ. Сейчас - только и исключительно ради спортивного интереса.
Для з80 есть несколько проблем:
- непростой отлов состояния проца (включенные страницы, IM, стек наконец, который обязан быть в ОЗУ, иначе в задачу не вернемся, хорошо, если не грохнем ядро).
- отстутствие терминации кванта задачи, чтоб вернуть управление ядру или другим задачам, если задача не занимается полезным делом. ОК, можно отлавливать халт, но если задача будет висеть в цикле (опрашивая например клавишу), она будет просто грузить проц и ждать окончание своего заскедьюленого времени.
- банальная слоупочность зетника, которая в сочетании с предыдущим пунктом сильно уменьшит комфорт от работы. Ну допустим, турба, ОК.
- необходимость аппаратной доработки, которая будет а) помогать подменять/сохранять контекст, б) обеспечивать прерывание таски по скедьюлеру (приходит на ум только NMI).

Если очень захотеть, реализовать можно. Например ФПГА может вообще отлавливать все критичные изменения контекста процом (паги, стек, режим ИНТа) и хранить внутри доступными для чтения. Но это какбэ не то, а сделать подобное на ЛА3 - надо куча МГТФа.

---------- Post added at 10:15 ---------- Previous post was at 10:12 ----------

А, еще забыл про периферию. Придется виртуализировать все устройства, та же ВГ93 сойдет с ума, если ее трогать из 1+ задач.

[Advertiser]

[Error404]

А, еще забыл про периферию. Придется виртуализировать все устройства, та же ВГ93 сойдет с ума, если ее трогать из 1+ задач.

Как вариант, не виртуализировать - а сериализировать: устроить очередь на входе таких устройств: порезать обращения на неразрывные "кадры", которые выполнять последовательно в очереди. Ну собственно, как делается во всех многозадачных ОС (один хрен какая-то же программная прослойка все обеспечивающая там же будет?).

[Vadim]

Если очень захотеть, реализовать можно. Например ФПГА может вообще отлавливать все критичные изменения контекста процом (паги, стек, режим ИНТа) и хранить внутри доступными для чтения. Но это какбэ не то, а сделать подобное на ЛА3 - надо куча МГТФа.

Не проще ли для этих целей заюзать уже готовые решения? Тот же i386, в котором все вышеуказанные проблемы решены? Когда у нас для виртуальных процев (или машин) есть свои адресные пространства, свои пространства портов ВВ. Когда проц может сам это регулировать, оперируя реальным ОЗУ? Естественно не без помощи ОСи? Зачем велосипед изобретать? Я вот к чему. Всё равно в итоге вы придёте к общеизвестным механизмам. На базе Z80 это просто не сделать, в апофеозе, вы всё таки придёте к тому, что было сделано ещё в 1982-м году. К MP/M. Не стоит ли почитать как там это организовано?

---------- Post added at 23:22 ---------- Previous post was at 23:19 ----------

Схема может подсунуть пустышку вместо памяти, к которой незаконно обращается процесс.

Защита ОЗУ в простейшем варианте реализована в Z-280. Когда нельзя обратиться к странице, если у тебя нет прав на неё. Зачем изобретать велосипед? Читаем доки Алоний, читаем доки и учимся. Потом думаем, как это применить и надо ли оно нам?

[alone]

Я говорю про решения, которые можно применить в ZX Evo. Процессор там заменить не получится.

[Vadim]

Тогда советую тебе ознакомиться с ОСями, на Z80, где это уже давным давно реализовано. Да, у них есть недостатки, но они опирались на железо какое? Начала 80-х. У нас сейчас возможности шире. Подумай. Но далее того, что было сделан уйти вряд ли удастся, т.е. будет более красивее но не более.