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

[OrionExt]

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

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

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

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

[Advertiser]

[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б.

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

[Xrust]

А как эта модель памяти связана с компиляторами? Для прикладной программы горизонтом является TPA. Как раз компилятору не надо думать об организации памяти. И для TSR все удобно сделано. По прерыванию автоматически подключается страница с TSR областью и можно особо не мучаясь обрабатывать прерывания и т.п. А можно и не пользоваться этой возможностью. Главное, чтобы эта возможность была и имела хотя бы минимальную программную поддержку на уровне ПЗУ BIOS. И этим практически любой желающий сможет воспользоваться.
Эта модель памяти очень проста и не обязывает программиста подстраиваться под систему. Нет жесткой страничной модели как в Спектруме или Орионе. Можно вызвав стандартную процедуру переместить участок памяти любого размера из любой страницы в любую. Можно один байт переслать, а можно и 64к. А процессор в это время в своей текущей странице будет заниматься своим делом.

[OrionExt]

А как эта модель памяти связана с компиляторами?

Компиляторы пишутся под конкретные модели памяти, а их не так уж и много на 8-битках. А точнее две small и banked (large). Small - это обычная сплошная до 64Кб. Banked (large) – пример на рисунке.

А процессор в это время в своей текущей странице будет заниматься своим делом.

Ну, так глубоко не копал. А разве такое возможно для ПДП и ЦПУ? Шина та у них общая. Это надо арбитр для доступа к памяти делать (прозрачный доступ) или дуал-озу использовать.

[OrionExt]

Xrust, переубеждать вас не буду. Попробуйте на своей модели памяти, время покажет насколько это удобно. По мне таки нужен общий кусочек памяти. Чет вспомнил и решил найти такую штуку на MSX. Очень неплохой показатель 61K TPA на классической модели памяти.

[Xrust]

OrionExt, а какие конкретно функции должен выполнять общий участок памяти?

[OrionExt]

OrionExt, а какие конкретно функции должен выполнять общий участок памяти?

Ух. Список функций зависит от ОС. На вскидку стек, таблица прерываний, п/п менеджмента страниц памяти, таблицы вызова п/п Биос-а, ... В инете уйма примеров с подробными описаниями что да как и куда.

нужно смотреть в сторону менеджера памяти Z180.

Очень удобно и универсально на 3 регистрах, без излишеств, совместимость с 8-бит софтом (ОС, компиляторы и т.д). Никто не мешает сделать эту штуку на рассыпухе, пускай даже в упрощенной реализации.