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

[Xrust]

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

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

[OrionExt]

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

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

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

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

[Xrust]

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

[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]

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

Эмм... Две (как минимум) изолированные магистрали? Или как? Чтоб одновременно, и не прибито гвоздями к растактовке? Мысля интересная и что-то напоминает... из древнего...

Будет кусочек ПЗУ, который так же можно отключить при желании.

ИМХО не стоит делать специфические "кусочки". Тут ПЗУ там еще что.
Пусть они все будут равноправные и гомогенные, что ли, однородные. Как в MSX, только действительно, как говорит OrionExt, несколько помельче.
Хотя конечно один придется сделать несколько равноправнее других на момент загрузки, по крайней мере.

автоматически подключается по сигналу подтверждения прерывания

Вот это интересная идея, надо обмозговать. Тоже что-то из области мини-ЭВМ, наверно...

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

И ещё надо выяснить у ИРИШИ или у MSX более грамотно в адресном пространстве коммутируются 4 окна по 16К.

У "Ириши" нужно посмотреть вспомнить как сделано. А у MSX точно можно сказать, что MMU (а их там по факту аж два, переключалка слотов и собственно маппер ОЗУ) там "может копать, а может не копать", т.е. как хочешь так и щелкаешь.
Другое дело, что "щелкнув" не подумав можно все "поломать".

[OrionExt]

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

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

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

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

[Advertiser]

[TomaTLAB]

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

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

[OrionExt]

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

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

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

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

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

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

[TomaTLAB]

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

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

[Xrust]

Но раз речь зашла о TSR с прерываниями, т.е о резидентном процессе, то это значит, что речь о многозадачной DOS на прерываниях.

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

Эмм... Две (как минимум) изолированные магистрали? Или как? Чтоб одновременно, и не прибито гвоздями к растактовке? Мысля интересная и что-то напоминает... из древнего...

Как я понял из даташита на 8237, там есть режим блочного и одиночного обмена.

Single Transfer Mode
In Single Transfer mode
the device is programmed to make one transfer only.
The word count will be decremented and the address
decremented or incremented following each
transfer. When the word count ‘‘rolls over’’ from zero
to FFFFH, a Terminal Count (TC) will cause an Autoinitialize
if the channel has been programmed to do
so.
DREQ must be held active until DACK becomes active
in order to be recognized. If DREQ is held active
throughout the single transfer, HRQ will go inactive
and release the bus to the system. It will again go
active and, upon receipt of a new HLDA, another
single transfer will be performed. In 8080A, 8085AH,
8088, or 8086 system, this will ensure one full machine
cycle execution between DMA transfers. Details
of timing between the 8237A and other bus
control protocols will depend upon the characteristics
of the microprocessor involved.
Block Transfer Mode
In Block Transfer mode the
device is activated by DREQ to continue making
transfers during the service until a TC, caused by
word count going to FFFFH, or an external End of
Process (EOP) is encountered. DREQ need only be
held active until DACK becomes active. Again, an
Autoinitialization will occur at the end of the service
if the channel has been programmed for it.

Если я правильно понял, то при одиночном обмене процессор и DMA попеременно занимают шину и при этом длительных затыков не возникает. Поправьте меня, если я что-то не так понял.

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

У меня модель памяти простая. Приложению выделяется сплошная страница. Если ему надо больше - пусть обращается к соответствующим функциям ОСи. В том то и особенность предложенной модели - она максимально совместима с обычными CP/M приложениями и не требует их доработки. Небольшого допиливания потребует только сама система, т.к. ее ядро будет размещено в отдельной странице и при запуске приложения оно (приложение) будет загружено в свою отдельную страницу.

ИМХО не стоит делать специфические "кусочки". Тут ПЗУ там еще что.
Пусть они все будут равноправные и гомогенные, что ли, однородные.

Я вообще считаю, что ПЗУ нужно только для загрузки системы. В нем должны размещаться специфичные для конкретного набора аппаратуры драйверы и программа конфигурации оборудования. Функцией этой программы должна быть настройка оборудования и компоновка БСВВ. Затем БСВВ загружается в верхнюю область ОЗУ, драйверы оборудования в страницу TSR, а ПЗУ отключается до следующего включения или перезагрузки.