Компьютер для CP/M. Формулировка ТЗ.

[Xrust]

Будет кусочек ПЗУ, который так же можно отключить при желании. Например, предварительно скопировав его в нужные страницы ОЗУ при помощи ПДП.

[Advertiser]

[OrionExt]

Будет кусочек ПЗУ, который так же можно отключить при желании. Например, предварительно скопировав его в нужные страницы ОЗУ при помощи ПДП.

Хитро. А как же на языке Си писать. Там такие номера не пройдут. У нас ведь не х86.

Если уж делать страничную организацию памяти. То нужно смотреть в сторону менеджера памяти Z180. Даже у MSX c самым продвинутым движком управления памятью не всегда удобно по 16Кб щелкать. Надо меньше.

[Xrust]

У нас ведь не х86.

Ну как бы поэтому на С никто особо и не пишет на 8-битках ) И для пользовательской программы это прозрачно будет. Все равно ей за пределы одной страницы лезть незачем. Этими делами будут TSR и ОС заниматься.

[OrionExt]

Ну как бы поэтому на С никто особо и не пишет на 8-битках )

Как не пишет? А как же Uzi, Fuzix, UZIX. Пускай не СP/M

А компиляторам такая модель памяти даже в страшном сне не присниться. ПДП это прекрасно. Но с моделью памяти точно не стоит паровоз изобретать.

Да и TSR написать далеко не тривиальная задача. Это уже высший пилотаж.

[barsik]

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

Насчёт предпочтительности, т.е с точки зрения выбора платформы для которой было больше всего CP/M программ, ничего сказать не могу. Я немного знаю лишь о тех компьютерах, которые сам имею или имел, а о других компьютерах я знаю не больше любого другого. Понятно, что могу по памяти перечислить с десяток западных 8-ми разрядок, что у всех на слуху и упоминания на которых встречаются на сайтах ретро компьютеров и CP/M. Но не только не знаю сколько у каждого компьютера программ, но даже параметров их железа не знаю.

Я могу лишь высказать своё мнение о том, какую графику считаю оптимальной для себя. Опыт показал, что графика должна быть такой, чтобы допускать символы шириной в байт (вывод втрое быстрее, чем символы с шириной не кратной байту), а организация цвета такой, чтобы максимально упростить цвет для текста. Смешивать в одной плоскости цвет и графику (как в MDA XT) нет смысла, лучше две плоскости (возможно даже включённые в одном адресном пространстве). Что касается цвета для полноценной цветной графики, т.е возможности задавать цвет попиксельно, то это полезно только для игр.

Из этого получается, что оптимальным будет организация графики 512*256 (размер экранной плоскости 16К) и один режим цвета, позволяющий задавать два цвета в пределах 8-ми экранных точек. Т.о получается расширенный экран ОРИОНА в 16-ти цветном режиме.

поэтому на С никто особо и не пишет на 8-битках

На самом деле на СИ для 8-ми биток много писали, но увы, не у нас. Т.к когда наши 8-ми разрядки были популярны, то не было доступа к компиляторам. А когда в 1994-96 такое появилось, то профессионалы (разработчики ПО в КБ заводов выпускающих 8-ми битки) уже исчезли, а любители просто не успели освоить компиляторы ЯВУ. Я думаю, что главным ограничением использования СИ является не архитектура ЭВМ, а объём ОЗУ для компилятора и скорость прогона программы на СИ. ЯВУ не волнует архитектура машины. ЯВУ желательно сплошное ОЗУ максимального размера. А то, используется для интерфейса с драйвером экрана из другой банки некоммутируемый кусок ОЗУ или всегда включённое ПЗУ, - ЯВУ совсем не волнует. Я предлагал отказаться от некоммутируемого участка ОЗУ лишь из экономии, т.к без этого можно обойтись (хотя и за счёт усложнения программы).

Даже у MSX c самым продвинутым движком управления памятью не всегда удобно по 16Кб щелкать. Надо меньше

Вообще-то самый продвинутый диспетчер памяти для CPU с 16-ю адресами - в машинах DEC. Такой диспетчер ОЗУ с 8-ю окнами размером по 8К - не удастся использовать. ПК11/16 имеет в DOS многозадачность, т.е одновременно прогоняется много процессов, каждый из которых имеет полученный у DOS свой набор участков ОЗУ, который и включает в 8-ми килобайтовых окнах, в моменты, когда этот процесс активен. Если многозадачной ДОС нет, то бОльший смысл имеет коммутация по 60/64К.

Просто ни разу не встречал для 8-битных ЭВМ таких конфигураций памяти, чтобы переключались страницы целиком по 64 кб

Железо в ИРИШЕ позволяет коммутировать ОЗУ целиком по 64К, но так не делают, всегда общий кусок 16К остаётся для связи между картами памяти (из-за чего сокращается объём ОЗУ, т.к число карт памяти всего 4). У ИРИШИ диспетчер похож на MSX (в адресном пространстве коммутируются 4 окна по 16К), но, увы, управление этими окнами сделано не оптимально.

По прерыванию автоматически подключается страница с TSR областью

Круто.

Вообще, просто драйвер загружаемый в другую банку (например драйвер принтера или другой клавиатуры), это тоже TSR, но без прерываний. Они грузятся на вектора стандартных входов CP/M-BIOS.

Но раз речь зашла о TSR с прерываниями, т.е о резидентном процессе, то это значит, что речь о многозадачной DOS на прерываниях. Вот тут уж нельзя отказываться от некоммутируемой области. Иначе с прерываниями будут большие проблемы и сложное программирование. Причём в прерывании должна быть возможность считать текущую конфигурацию (чтобы иметь возможность восстановить по выходу из INT). В ОРИОНЕ не предусмотрели возможность считать текущий номер банки, отчего сложно делать многобанковое ПО с прерываниями (т.к надо долго извращаться, чтобы узнать в какой банке нас застало прерывание).

[TomaTLAB]

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

Отнюдь. Первое, что в голову приходит, где можно гембель огрести с цветами - это отрисовка собственно графиков. Кривых на сетке координатной.

[OrionExt]

У ИРИШИ диспетчер похож на MSX (в адресном пространстве коммутируются 4 окна по 16К), но, увы, управление этими окнами сделано не оптимально.

Похож, да не похож. Даже смотреть не буду.

Штатный MSX диспетчер памяти у не окрепшего 8-ми битного ума (пользователя) может разорвать все шаблоны

Максимальный объем адресуемой памяти 64Мб !!! (4096Kb x 16 slots). И все это тасуй, как хочешь в четырех окнах по 16Кбайт.

- - - Добавлено - - -

Чутка соврал. За вычетом ПЗУ – 56Mб.

[TomaTLAB]

Чутка соврал. За вычетом ПЗУ – 56Mб.

И это если использовать только "каноничный" маппер ОЗУ. А если слегка отойти от стандарта (как это сделано напр. в маперах ПЗУ кариков) то...