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

[Xrust]

[Advertiser]

[barsik]

пятница, рыбный день

Пропаганда религии на сайте запрещена (в православии среда и пятница являются постными днями, в которые запрещается употребление мяса).

А при социализме рыбным днём был четверг.

Скрытый текст

Автором «рыбного дня», введённого 12 сентября 1932 года постановлением Наркомснаба СССР «О введении рыбного дня на предприятиях общественного питания», был А. И. Микоян. Позднее, 26 октября 1976 года, ЦК КПСС издал повторное постановление о введении «рыбного дня». За рыбным днём был закреплён постоянный день недели — четверг. Многие предприятия общественного питания в этот день не включали в меню никаких мясных блюд, что вызывало недовольство у рабочих и служащих. Тому, что рыбный день был назначен именно на четверг, было дано чёткое обоснование, подкреплённое статистикой и расчётами, сводящимися к тому, что реализация рыбы именно в этот день будет максимальной.

[свернуть]

не собираюсь дописывать или "адаптировать" чьи-то программы под свои нужды

А придётся, если нет желания иметь всего несколько программ, а точнее, лишь POWER, SuperText и DBase 2.50. Посмотрите на сайтах CP/M, там 90% программ это компиляторы ЯВУ. 10% это улучшенные клоны CP/M, утилиты, крутые текстовые редакторы и игры. Причём, если компиляторы универсальны, то игры и всё остальное надо адаптировать для конкретной ЭВМ. Игры с исходниками адаптировать несложно. А вот графические программы адаптрировать намного сложнее.

Поэтому CP/M вообще имеет смысл только для использования компиляторов. Или для использования от неё лишь только самой файловой системы для хранения и запуска программ конкретного компьютера. Поэтому, строго говоря, делать CP/M компьютер с нуля несовместимый с какой-нибудь платформой, где есть программы и при этом не имея задачи писать свои программы, - вобще бессмысленно. С пользой на таком компьютере можно будет использовать только вышеперечисленные программы. А узко специальные SuperCalc, MultiPlan и т.п - вообще бесполезны. CP/M игр в кодах - всего 20-25 и и-то их надо адаптировать. Даже бейсик игр во много раз больше.

Я не собираюсь переделывать ни СР/М ни ассемлеры ни, тем более, писать какие-то цветные коммандеры. Повторюсь. Есть платформа, на ней запущен СР/М - это основа, которая не переделывается. А вот все мои "железные" фантазии и эксперименты - вот здесь и пишу свой софт.

Ну переделывать CP/M уже не надо. На немецких сайтах я нашёл, как минимум, три заменителя BDOS (все для Z80), которые просто заменяют модуль BDOS в обычной CP/M 2.2, что даёт даты у файлов и ещё какие-то плюсы. Ассемблеры переделывать тоже бессмысленно. Во-первых, есть M80, лучше которого даже сейчас ничего нет, а во-вторых, я скачал более десятка самодельных ассемблеров CP/M (их делали бедные люди, кто не мог потратить 180...400 USD на покупку Microsoft M80). Свой макроассемблер нужен только для других ДОС, не CP/M, где вообще нет компиляторов, т.к самое минимальное ПО, что должно входить в ДОС - это текстовый редактор, макроассемблер и отладчик.

Вы упускаете из вида, что существовало более 400 типов CP/M машин. И всё приличное ПО для них писалось по железу. Кому было бы интересно ПО без цвета и графики? Поэтому, то что в литературе указывают на наличие 10 тысяч программ для CP/M, это рекламная ложь. 10 тысяч может и есть, но реально пригодны только внеплатформенные программы, а именно - компиляторы и текстовые редакторы. Общее число доступных программ (считая пакет компилятора ЯВУ за одну программу) не превысит полусотни. Но для конкретной развитой западной CP/M машины (из конца 80-тых) программ будет тысяча.

Странная логика - написать программу, что бы под нее сделать железку! Обычно наоборот...

Именно, всегда наоборот.

Я, например, больше люблю с железом ковыряться и это ничуть не менее интересно

Точно менее. И намного. Я тоже любил возиться с железом, пока не узнал правды. И из железа хоть какой-то интерес представляет разрабатывать своё, а не повторять чужое (особенно неинтересно повторять чужие конструкции на ПЛИС и МК). А при разработке своего всё-равно без программирования не обойтись.

[Xrust]

barsik,

Вы упускаете из вида, что существовало более 400 типов CP/M машин. И всё приличное ПО для них писалось по железу. Кому было бы интересно ПО без цвета и графики? Поэтому, то что в литературе указывают на наличие 10 тысяч программ для CP/M, это рекламная ложь. 10 тысяч может и есть, но реально пригодны только внеплатформенные программы, а именно - компиляторы и текстовые редакторы. Общее число доступных программ (считая пакет компилятора ЯВУ за одну программу) не превысит полусотни. Но для конкретной развитой западной CP/M машины (из конца 80-тых) программ будет тысяча.

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

[Xrust]

Вот такие идеи сейчас вертятся в голове по организации памяти. Промежуточный итог, так сказать. Отдельную страницу 64к выделяем системе, отдельную страницу(ы) для приложений, отдельную страницу для обработчиков прерываний (автоматически подключается по сигналу подтверждения прерывания). Ну и как ранее писал, возможен обмен между страницами через ПДП контроллер ВТ37. А он, как я понял из ДШ, может и полностью управление перехватить, а может и по очереди с процессором делать свою работу. Как быть с графикой пока не решил. Т.к. конструкция будет модульная и с открытой архитектурой, то надо предусмотреть установку видеоадаптеров различных конструкций. А значит, скорее всего, им при необходимости будут выделены свои страницы памяти.

[TomaTLAB]

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

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

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

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

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

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

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

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

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

[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, а ПЗУ отключается до следующего включения или перезагрузки.

[OrionExt]

Хм… Чет ничего не понял со страницами по 64Кб. А как же склеенный (общий) участок адресуемой памяти. Кто будет этим добром по 64К управлять?

Просто ни разу не встречал для 8-бит ЦПУ таких конфигураций памяти, чтобы страницы целиком по 64Кб щелкались. Кусочек памяти должен быть не переключаемый.

[Xrust]

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

[OrionExt]

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

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

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

[Xrust]

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

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