ПК8000 - Квазидиск

[b2m]

Можно сделать вообще на одной типа ATF15V8 или ATF22V10 вместе с мультиплексором. Я делал исходя из расспространнености логических элементов(которые у меня есть).

Если на одной, да распространённой, то логику лучше в ПЗУ-шку засунуть

[Mick]

И все-таки программать такую штуку не очень удобно.
Mick, может обдумаешь вариант, когда для хранения номеров страниц будут использоваться 4 полубайта из 155РУ2 (остальные 12 не будут использоваться)? Т.е. примерно как программирование палитры на векторе, задаем адрес (на векторе номер цвета, на ПК номер области памяти) и задаем содержимое (на векторе физический цвет, на ПК 8000 номер страницы).

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

[b2m]

запускать с одного и того же адреса и каждая программа в своей странице

Ну да, и переключать по прерыванию Даёшь линукс на ПК8000!

[Error404]

Ну да, и переключать по прерыванию Даёшь линукс на ПК8000!

Линукс-неЛинукс, а UZIX можно было бы портировать. Я уже запланировал себе на будущее полугодие - буду для Ориона пытаться портировать. Сейчас пока читаю исходники - в принципе все понятно, и главное есть и компилятор (HiTech C глючный) и исходники - ядро, либы и приложения. Осталось только взять да сделать. И переключать задачи как раз за счет диспетчера по 64к (почему я сразу про него и заявил). Одна задача - одна страница. Переключение контекста - одной командой OUT (упрощая). Что не поместится в странички памяти - свопить на HDD.

[b2m]

переключать задачи как раз за счет диспетчера по 64к (почему я сразу про него и заявил). Одна задача - одна страница

1. Использовать целых 64к ОЗУ на одну задачу - расточительно.
2. В современных ОС есть такое понятие, как разделяемая библиотека (.so или .dll), было бы логично разместить код таких библиотек в отдельной странице (например те-же 16кб) и использовать для всех задач.
3. Необходимо также иметь возможность меж-процессных коммуникаций, т.е. необходимо подключать часть пространства другого процесса.

[Error404]

1. Использовать целых 64к ОЗУ на одну задачу - расточительно.
2. В современных ОС есть такое понятие, как разделяемая библиотека (.so или .dll), было бы логично разместить код таких библиотек в отдельной странице (например те-же 16кб) и использовать для всех задач.
3. Необходимо также иметь возможность меж-процессных коммуникаций, т.е. необходимо подключать часть пространства другого процесса.

UZIX не поддерживает общую память для коммуникации, только сигналы, а для них в сущности не нужно ничего. С другой стороны, я ни в коем случае не буду спорить: 4 одновременных окна по 16к это более гибко, чем одно на 64к. Главное, что результат достигается - 64 к на процесс и быстрое переключение (без LDIR-ов и аппаратного копирования массивов ОЗУ). Ограничивать процесс заведомо меньшим объемом - это плохо, т.к. процессор адресует 64к, и это минимум в который на С можно скомпилировать хоть какой-то функционал (порядка 2000 строк исходника - всего навсего), в меньший объем поместится разве что hello world.
Разделяемые библиотеки это безусловно хорошо, и было бы полезно, но сложно реализуемо, т.к. потребуется внедреж в компилятор, а на него нет исходников. Ну, это опять же если говорить про UZIX / HiTech C. Другое не рассматриваю, т.к. написать свое с нуля ИМХО нереально, по крайней мере для меня - будь то хоть ядро ОС, хоть компилятор ANSI C.

[b2m]

64к, и это минимум в который на С можно скомпилировать хоть какой-то функционал

Это всё потому, что библиотеки прицепляются. А если будет внешняя C RTL, то будет гораздо меньше.

Разделяемые библиотеки это безусловно хорошо, и было бы полезно, но сложно реализуемо, т.к. потребуется внедреж в компилятор

Абсолютно нет необходимости изменять компилятор. Главное, это чтобы он мог пристегнуть вместо реальной библиотеки заглушку, которая загрузит и свяжет внешнюю библиотеку. Т.е. чтобы вместо библиотеки прицеплялась куча JMP-ов.

Добавлено через 2 минуты

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

Не совсем понятно, как загружать новые задачи, если переключать полностью всё адресное пространство.

[Error404]

Не совсем понятно, как загружать новые задачи, если переключать полностью всё адресное пространство.

Нужен некий непереключаемый сегмент. В Орионе он есть - аппаратно не переключаются верхние 4к, в которых 3к ПЗУ+порты (ненужные в-общем то) и только 1 к испольуется для обеспечения связи страниц. На другой железке с независимыми страницами (например эхотаге), ничто не мешает диспетчером 16к проинициализировать 64к-страницы - записать в верхний 1к одинаковый для всех страниц код обеспечения связи страниц, а уже затем при помощи процедур, размещенных в этих 1К, переключать страницы по 64к имея оставшиеся 63к под процесс.

Это всё потому, что библиотеки прицепляются. А если будет внешняя C RTL, то будет гораздо меньше.
Абсолютно нет необходимости изменять компилятор. Главное, это чтобы он мог пристегнуть вместо реальной библиотеки заглушку, которая загрузит и свяжет внешнюю библиотеку. Т.е. чтобы вместо библиотеки прицеплялась куча JMP-ов.

Вот про это то я и не уверен. Не припоминаю никаких опций компилятора или процедур в библиотеках, регулирующих связывание этапа выполнения. Компилятор тупо собирает большой выполняемый файл и все. На CP/M подругому в те времена еще не было придумано нигде. Были слабые попытки реализовать оверлеи, но пользоваться оверлеями было очень неудобно, т.к. там совсем другой подход.

А про заглушку я не понял. Обычную библиотеку, состоящую из набора jmp (или "dispatcher16k_on(); call(_func); dispatcher16k_off(); ret" ) собрать не проблема для любого компилятора. Имена функций в ней будут какие пропишешь, хотя бы и аналоги libc. Или имелось в виду что-то другое?

[b2m]

Или имелось в виду что-то другое?

Нет, не другое. Я имел ввиду: подменить библиотеку libc на такую, которая перед вызовом main просит ядро загрузить библиотеку и инициализировать адреса в имеющейся куче команд JMP. Хотя, библиотека всё равно будет по фиксированным адресам, так что ничего в этих JMP-ах менять не нужно. Разве что, инициализировать номер страницы, где находится библиотека.

Добавлено через 2 минуты
Если эти jmp-ы (ну или то, что ты написал) будут в начале программы, то она может даже перекрываться с libc, т.е. иметь размер в 64Кб без учёта libc

[Error404]

Нет, не другое. Я имел ввиду: подменить библиотеку libc на такую, которая перед вызовом main просит ядро загрузить библиотеку и инициализировать адреса в имеющейся куче команд JMP. Хотя, библиотека всё равно будет по фиксированным адресам, так что ничего в этих JMP-ах менять не нужно. Разве что, инициализировать номер страницы, где находится библиотека.

Добавлено через 2 минуты
Если эти jmp-ы (ну или то, что ты написал) будут в начале программы, то она может даже перекрываться с libc, т.е. иметь размер в 64Кб без учёта libc

В современных компиляторах можно опцией указывать точку входа в пользовательский код. Т.е. можно написать библиотеку с функцией init(), которая из своего тела вызывает _main. Компилируя бинарник, линковать его с этой библиотекой и указывать в опциях компиляции init как точку входа. Думаю, и HiTech С такое может (надо посмотреть). Даже если и не умеет, то это можно решить маленькой присадкой типа вируса, которой обрабатывать уже готовый бинарник получая на выходе init+main.

В-общем, надо браться за работу