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

[Xrust]

Error404, что тут скажешь. В этом моменте и заключается главная проблема. Самый оптимальный вариант - переключать страницы уже после сохранения адреса в стек. Реализовать это наверное достаточно сложно, особенно учитывая наличие контроллера прерываний и требование к совместимости с разными процессорами (8080, 8085, Z80). Но, возможно, не все так страшно. У меня правда нет исчерпывающей информации о том, как работает со стеком CP/M и приложения. Насколько я знаю, стек расположен в верхней части TPA и без большой необходимости его никто не перемещает. Конечно, приложения могут пользоваться стеком для быстрого перемещения данных. Но я не знаю, насколько часто и в каких случаях пользовались этим приемом. Для данной системы в этом нет необходимости, т.к. будет более быстрый и удобный способ - ПДП. Хорошим вариантом проверки будет построение стенда, моделирующего эту систему в упрощенном виде. Вот пожалуй и ТЗ для следующего этапа: построить тестовую систему с оперативной памятью 128к в виде 2х страниц и контроллером прерываний.

[barsik]

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

Стек CP/M и приложения ставят в любое место от ~60H до BDOS (CP/M ставит стек на 80H и он опускается до ~60H). Но драйверы загруженные на входы CP/M-BIOS могут переставлять стек на некоммутируемую область ОЗУ и затем переключать банку. Если прерывания организовать за счёт чтения с шины байта FF (т.е без контроллера прерываний), то удобнее всего, если в области 38H находится ПЗУ (как в Синклере). Если во всех банках в области 38H расположить один и тот же код, то не вижу никаких проблем со стеком из-за прерываний (если не допускать рекурсивности прерываний), тем более если есть некоммутируемое ОЗУ выше FE00.

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

Но встречный вопрос, а зачем Вам нужны прерывания?

Чтобы считать время по импульсам 50 Гц? - Для этого предназначена 512ВИ1. Или периодически проверять неактивную клавиатуру? Или по прерываниям мгновенно реагировать на клавиши, как в IBM PC, если клавиатура активная (т.е сама даёт сигнал и символ или скан-коды)? Но как раз в CP/M без этого прекрасно обходятся, т.к не волнуют затраты ресурса на опрос клавиатуры и нет процедур настолько надолго прерывающих опрос клавиатуры, что символы теряются. Некоторые программы CP/M, если они вынуждены надолго прервать опрос клавиатуры, сами берут на себя периодический опрос клавиш, так например редакторы, делая вывод (ролик экрана) после вывода каждой строки контроллируют STATUS (и делают ввод, если что-то нажато), и по окончании долгой процедуры, код клавиши нажатой в это время будет взят из буфера (хотя в отличие от MSDOS буфер только на 1 символ).

Поэтому, единственная вещь, ради чего стоит трахаться с прерываниями, это многозадачность, о чём я и упомянул, когда прочитал о TSR обслуживаемых по прерываниям. Вы отмахнулись, что многозадачность не нужна. Это и ежу понятно (если нет межпрограммного обмена или хотя-бы клип-боарда), но как ещё ранее я упоминал, имеется ввиду не многозадачность с равноправными задачами, а однозадачность, но с одновременно выполняемыми маленькими резидентными процессами, в основном предназначенными для контроля флагов, датчиков, событий и обслуживания периодических явлений, типа счёта времени, иными словами для обслуживания периферии в реальном времени.

Процесс это маленькая, короткая по времени прогона подпрограмма, которая должна прогоняться периодически (неважно, раз в 20 МСЕК или раз в 10 минут). Для обслуживания периферии достаточно одного прерывания. Резидентные процессы организованы в цепочку. По апп.прерыванию программа смотрит в таблицу загруженных процессов. В таблице зафиксированы адреса обслуживания загруженных процессов или 0000, если это последний процесс в цепочке. По очереди каждый из загруженных процессов получает управление. Ясно, что для однозадачности с процессами, рекурсивность прерываний абсолютно не нужна. Если надо (т.е процессы ресурсоёмкие или их очень много), можно за одно прерывание обслуживать только один процесс, а в следующем прерывании следующий.

Резидентный процесс может, например, регенерировать динамическую память, выводить текущее время в правом верхнем углу экрана, печатать на принтере в фоновом режиме (в CP/M есть программа для такой задачи, но там апп.прерывания эмулируются за счёт перехвата функций BIOS работающих с клавиатурой), обслуживать клавиатуру (не важно активную ли пассивную матричную), контроллировать запрос на начало передачи по линии, в общем обслуживать любую периферию, что работает в реальном времени. В любом случае, все процессы, вместе взятые, не должны занимать более 50% времени периода апп.прерываний. Если процессу нужно больше времени, он должен разделить задачу на куски и выполнять за одно прерывание только часть своей задачи.

Вот такую многозадачность я имел ввиду. Не стоит думать, что это сложно, объём кода вряд-ли превысит 256 байт. А практически это эквивалентно, как многоядерная ЭВМ, где есть основной процессор и несколько одновременно работающих очень медленных процессоров прогоняющих TSR-программы, обслуживающие периферию и не мешая при этом прогону основной программы.

Впрочем, как показала практика, удобно встроить в ДОС на машине с несколькими банками ещё одну основную задачу. А именно, так называемый Супервизор, (являющийся расширением драйвера клавиатуры). Это программа, которая всегда хранится в ОЗУ какой-либо банки, никому не мешая. Затем, по нажатию сочетания клавиш, прикладная программа прерывается, в центре экрана очищается окно и в нём стартует Супервизор. В простейшем случае это отладчик или многобанковый RAM-монитор. Я делал такое для ДОС ОРИОНА, оказалось очень удобно. Конечно не так, как в ПК11/16, где в процессоре есть второй набор регистров, что более просто позволяет реализовать отладку. Но и для Z80 это лучше, чем CP/M-отладчик, т.к не требует в TPA ОЗУ для него. У меня в Супервизоре был RAM-монитор и HELP по функциям ROM-BIOS, CP/M, упр.кодам консольного драйвера и кодам для рисования рамок, т.е вся та справочная информация, что постоянно нужна при разработке ПО. Супервизор просто запускался, как обычная программа, после чего становились доступны его функции.

В системе с TSR на прерываниях управлять ими удобно с помощью такого же Супервизора.

[Xrust]

barsik, если вы это называете многозадачностью, то именно это я и хочу реализовать. Тем более, что для CP/M старших версий требуется прерывание от таймера.
Прерывания способны упрощать решение ряда задач, освободить процессор от ненужных действий, упростить работу с периферией.

[shurik-ua]

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

Если на заре восьмидесятых это ещё было актуально, то сейчас это выглядит как если приделать мерседесу деревяное колесо ).
Имхо.

[barsik]

Если на заре восьмидесятых это ещё было актуально, то сейчас это выглядит как если приделать мерседесу деревяное колесо

Прерывания использовались в большинстве западных ЭВМ на Z80. Ничего плохого в том, чтобы их использовать в аналогичной ЭВМ и сейчас. Это выгодно и профессионально и топик стартер вполне разумно собрался их использовать. Я лишь изложил стандартный механизм использования TSR, используя современную терминологию. Да и почему не использовать, если это полезно и просто? Если подключать драйвера периферии без прерываний, то это тормозит намного больше, да и программирование сложнее. Например, попробуйте сделать загружаемый драйвер мыши в компьютер без прерываний и TSR.

Я как раз против неоправданных, бессмысленных усложнений архитектуры и ПО. Я всегда за простоту, потому что знаю, что только простые вещи реализуемы. Лучшее враг хорошего. Я часто убеждался, что если не довольствоваться простыми улучшениями, которые легкодоступны, а стремиться к более сложному и трудоёмкому идеалу, то вообще нет движения (или надо ждать ровно 5 лет). Потому-то ОЗУ РК86 до сих пор всего 32 кб. Потому и топик стартеру советую всё делать как можно проще.

[Xrust]

Некоторым здесь прерывания явно не по душе. Это наверное признак РК головного мозга Это конечно шутка и я никого не хотел обидеть, но доля правды в этом есть.

[Advertiser]

[shurik-ua]

Меня неправильно поняли - я как раз за прерывания - например крайне полезно получать прерывание при получении байта через COM порт.
Я про то что регенерацией должна заниматься какая-нибудь отдельная схема, но никак не программа )
Ну и к тому ещё что в современных чипах почти везде есть режим self-refresh - это я про SIMM-72.

p.s. С РК дел не имел если что )

[barsik]

регенерацией должна заниматься какая-нибудь отдельная схема, но никак не программа

Применительно к Z80 проблема регенерации вообще не стоит т.к в него это уже встроено. Если используется ОЗУ с вектором регенерации более 7-ми, например 11, то легко добавить счётчик, и даже это, возможно, будет проще, чем изобретать схему как использовать режим 'RAS before CAS'.

Я упомянул программную регенерацию, т.к топик стартер использует КР580 и оттого, что вспомнил, что прерывания в IBM PC XT и AT использовались именно для регенерации ОЗУ (и это тормозило CPU очень мало). Такая регенерация - это вариант для бедных, т.к схема для регенерации динамического ОЗУ обходится намного дороже, чем введение прерываний (например, смотрите, как громоздко это сделано в блоке динамического ОЗУ МИКРО-80).

А для богатых рекомендуется применение специальных БИС для динамических ОЗУ - Intel 8202, 8204, 8208, MC3242 и др. Они не только заменяют мультиплексоры, но и сами регенерируют ОЗУ в паузах доступа. Такой вариант лучше, т.к при использовании прерываний для регенерации, их нельзя запретить, отчего машина не может работать в реальном времени. А это создаёт большие проблемы при необходимости программно отмерять короткие задержки, в частности, при программной реализации передачи по последовательному интерфейсу или в формате МГ. Поэтому скорость программного обмена по линии между двумя 8-ми разрядками - 8-10 кб в секунду, а такой же точно обмен между IBM PC и 8-ми разрядкой составляет всего 150 байт в секунду.

[TomaTLAB]

Грамотные люди утверждали, что для таких целей нет ничего лучше, чем 555ИР26

Именно, т.к. это двухпортовка по сути. У них не только входы/выходы раздельные (что тоже хорошо), но самое главное раздельные адреса для чтения/записи. Что очень сильно упрощает жизнь

[Error404]

Именно, т.к. это двухпортовка по сути. У них не только входы/выходы раздельные (что тоже хорошо), но самое главное раздельные адреса для чтения/записи. Что очень сильно упрощает жизнь

Вроде же у ИР26 какой-то мизерный объем памяти, т.е. это как есть регистр, из него дешифратор на кучу состояний не сделаешь даже если несколько ИР26 поставить? Т.е. они годны именно как регистры в какую-то "фиксированную" схему где заранее известно какой порт (уже готов его селект) и сколько и каких страниц памяти будет (как будут соединены регистры через коммутаторы с адресами ОЗУшек). А не так чтобы можно было на лету перепрограммировать и адрес выборки порта/регистра, и количество портов (один/два...), и "схему соединения" между регистром и адресными ножками ОЗУ. В этом смысле, большое ОЗУ дает функционал приближающийся к CPLD.