Программирование для CP/M Специалиста

Обработка дисковых ошибок в CP/M Специалиста (также и в CP/M для других ЭВМ). Извиняюсь, что излагаю давно известное всем программирующим для CP/M, это не для вас, а в помощь новичкам в программировании для CP/M.

В документации по инсталляции CP/M и в популярной книге Дж.Ангермейера не встречал информации об обработке в программах дисковых ошибок CP/M. Некоторые думают, что обработка дисковых ошибок в CP/M ограничена выводом обидных сообщений, типа "BDOS ERROR ON A:", "BAD SECTOR" и т.п.

Это отчасти так, т.к сама CP/M не обрабатывает дисковые ошибки (как она может, она же не знает особенностей железа), но она даёт возможность программе пользователя самой делать обработку дисковых ошибок. Фирменные CP/M программы это делают. А вот некоторые самодельные программы для CP/M ОРИОНА это не делают (обычно это не вызывает проблем пока не возникает дохлота дискеты). Т.к информации не было, узнать об этом можно было только ковыряя фирменные программы. Некоторые программисты любители просто не знали о такой возможности предоставляемой BDOS. Потому в некоторых программах любителей, если возникает ошибка BDOS, то выводится обидное сообщение и программу приходится завершать по ^C (если это не сделать, то может расплодиться дохлота).

В некоторых продвинутых программах любителей обработка дисковых ошибок всё-же есть, но сделана химией. Для этого в программе весь вывод делается или своим драйвером или входом ROM-BIOS, т.е минуя стандартный вход CONOUT в CP/M BIOS. А адрес перехода на входе CONOUT (BIOS+12) подменяется на адрес своего обработчика ошибок. Потому пока программа работает никаких вызовов входа CONOUT не делается. А вот когда возникнет ошибка и BDOS захочет выдать своё обидное сообщение об ошибке, вызвав для этого в цикле подпрограмму CONOUT, то из-за подмены адреса перехода происходит вылет в процедуру обработки ошибок предусмотренную автором программы.

Для обработки дисковых ошибок в BDOS имеются 4 вектора дисковых ошибок, которые располагаются с адреса BDOS+3 (потому, если BDOS работает в ПЗУ или реальный адрес кода BDOS не соответствует адресу в ячейке 0006, то код BDOS д.быть соответственно откорректирован). Эти 8 байтов представляют собой четыре адреса обработчика четырёх типов дисковых ошибок:

BADSEC: DW      ERRBAD
BADSEL: DW      ERRSEL
DISKRO: DW      ERRDRO
FILERO: DW      ERRFIL

Эти 8 байтов должна подменять программа, которая не хочет, чтобы при дохлоте дискеты, или например, при нехватке места на диске (или в каталоге), обращении к дисководу с открытым карманом и тому подобным ошибкам, программа не вылетала бы в CCP, а выводила бы аккуратное окно с запросом пользователю, что ей следует делать, чтобы исправить ситуацию. Грамотная CP/M-программа в начале своей работы сохраняет старое содержимое этих векторов (командой LDIR) и подставляет (командой LDIR) на их место адреса своих соответствующих процедур. А при выходе из программы (командой LDIR) восстанавливает ранее сохранённые стандартные вектора или просто делает RST 0, чтобы CP/M сама восставила весь свой код BDOS по процедуре Warm Boot.

Если CP/M-программа делает ввод символов функциями BDOS (в т.числе и убогой ф-ей ввод строки), то по нажатию ^C происходит вылет на Warm Boot. Чтобы этого избежать, надо подменять и адрес стандартного перехода на Warm Boot по адресу 0001 (или на адресе BIOS+3). Или проще вводить символы подпрограммами CP/M-BIOS. Вызов подпрограмм CP/M-BIOS не является нарушением, это общепринятая практика в программах CP/M.

Такой механизм обслуживания ошибок прост и удобен, но имеет свойство конфликтовать с загружаемыми под вершину TPA резидентами. В CP/M принято узнавать о адресе BDOS считав два байта из адреса 0006. Однако, есть программы (можно по аналогии с MSDOS называть их TSR), которые загружаются ниже CCP резидентно, переставив адрес в ячейке 0006 на себя (некоторые даже меняют при этом код BDOS). Понятно, что такие резиденты в CP/M недолговечны, - при первом же ^C CP/M восстановит все ячейки и код BDOS.

Потому, кстати, нежелательно менять оригинальный код BDOS, даже сдвигать на байт. Если это сделать, то, например, DESPOOL, XSUB, MOVE перестают работать. Если после загрузки такого квази-TSR запустить программу, что обрабатывает дисковые ошибки BDOS, то в худшем случае будут разрушены 8 байтов в начале кода TSR-программы и может произойти улёт, а в лучшем даже, если улёт не случится, то обработка ошибок не сработает. Потому и невозможно (точнее можно только с привязкой к конкретной системе) сделать загрузку драйверов в CP/M в ОЗУ на вершину TPA.

Полноценные резидентные драйвера в CP/M могут быть только уникальными (т.е для конкретной системы), т.к их можно грузить только вне TPA, - или вообще в иную банку ОЗУ или выше кода BDOS (точнее выше адреса, считаемого адресом BDOS согласно числу в ячейках 0006/0007). Потому в однобанковой ЭВМ, если нужна загрузка драйверов, то место для них надо предусматривать специально (например, в теле CP/M-BIOS). В Специалисте с его изобилием ПЗУ удобнее всего разместить драйверы консоли, последовательного COM1: (на входах пунчера/ридера), принтера, джойстика и мыши в страничном ПЗУ C000. Тогда для инсталляции драйвера программе достаточно проверить, что в Специалисте есть страничное ПЗУ, что в нём присутствует нужный драйвер и остаётся только подключить его к CP/M.

В принципе, загрузку TSR в TPA под вершину BDOS можно сделать и в CP/M, если или код CCP убрать из TPA (в случае Специалиста, например выше экрана) или сделать CCP перемещаемым (т.е способным работать на любом адресе). Тогда, когда TSR грузится, то сообщает CP/M-BIOS-у о смене адреса вершины TPA. И соответственно, CCP будет грузиться уже ниже новой RAMTOP и не будет удаляться из ОЗУ по ^C. В случае архитектуры Специалиста, где TPA и без того крошечный, это не вариант.

Из-за архитектуры Специалиста код BDOS не может быть оригинальным, т.к реальный код BDOS размещается выше экрана, а на адресе 0006 стоит лишь адрес промежуточного JMP-ра на адрес 8FB6, откуда делается переход уже на реальный код BDOS. Естественно, вектора дисковых ошибок располагаются с адреса 8FB6+3, а код BDOS изменён соответственно. CP/M-программы считают адресом BDOS число из ячеек 06/07, соответственно подменяя вектора ошибок. Но проверка кода BDOS на оригинальность не сработает, т.к по адресу 8FB6 BDOS реально отсутствует. Из-за этого XSUB не работает.