ПО. ПЭВМ "Ириша". CP/M для ИРИШИ.

Хотя, конечно, по хорошему для CP/M https://en.wikipedia.org/wiki/CP/M нужна не одна тема, а целый раздел с кучей тем, но попробую выкрутиться, хотя при этом получится каша и мешанина.

В этой теме речь о CP/M. А чуть точнее о CP/M версии 2.2 из 1977 года, которую разработал Гарри Килдэлл. Примечательно, что первая версия CP/M и все утилиты были написаны не на ассемблере, а целиком на каком-то экзотическом ЯВУ, который назывался PL/M. Это язык PL/M настолько эффективен, что в ряде случаев (для больших и запутанных программ) объём кода странслированного компилятором PL/M даже меньше относительно варианта программы написанной целиком на асcемблере.

Относительно максимально эффективно написанных ассемблерных программ проигрыш в объёме кода из под PL/M по утверждению его автора не превышает 15 % (а в среднем 10 %). Ни один ЯВУ, может быть за исключением форта, не может похвалиться такой эффективностью. Это объясняется низкой степенью абстракции языка PL/M, который близок к ассемблеру, из-за чего его использование не особо облегчает программирование (но зато позволяет избежать многих ошибок и огромных потерь времени на их поиск отладчиком).

Кстати, ещё одним минусом PL/M является отсутствие учебников на русском языке. В природе существует русскоязычный учебник из 80-тых, но его за бесплатно не скачать, надо покупать или бумажную книгу или платить за скачку PDF-файла. Также и с английскими учебниками. На халяву есть только описание языка от Intel на иностранном языке.

В общем в этой теме (разделе) речь пойдёт о разных вариантах CP/M для ИРИШИ и программах для неё, как старых, так и новых, написанных специально для ИРИШИ. Как известно, для CP/M как раз именно ИРИША является наиболее оптимальным компьютером из всех отечественных 8-ми разрядок, включая и КОРВЕТ.

Как следует из публикаций, для ИРИШИ ещё в 1986 году была CP/M, использующая громоздкий промышленный контроллер НГМД (причём не использующий ПДП), на котором, кстати, располагалось и бестормозное расширение ОЗУ содержащее две банки 565 РУ5 или РУ7, расширяющее объём ОЗУ ИРИШИ до 64 + 128 кб или до 64 + 512 кб (при применении 565 РУ7).

Как известно, для ИРИШИ промышленных контроллеров КНГМД было даже целых три. А скорее даже больше, т.к даты известных контроллеров - 1986, 1987 и 1989, но уже в 1985 ИРИША имела какую-то CP/M, о чём было написано в журнале МПСС 03.1985 http://sht-rajvo.narod.ru/irisha.htm. Что предполагает, что уже в 1985 году был работающий КНГМД, скорее всего заимствованный у СМ-1800. Такой вывод следует из того, что статья ссылалась на СМ-1800, и того, что больше заимствовать CP/M было неоткуда, т.к других ЭВМ на КР580 в СССР тогда просто не было. И все эти контроллеры НГМД содержат и расширение ОЗУ, выполненное на DRAM и расширение ПЗУ на 573РФ4 или РФ8.

Несколько лет назад группа энтузиастов даже сумела один такой контроллер (кажется из 1987) восстановить, проделав большую работу, а автор эмулятора EMU смог включить эмуляцию такого железа в эмулятор. С десяток печ.плат этого варианта КНГМД даже было произведено и распродано энтузиастам ИРИШИ. По крайней мере одну плату такого КНГМД даже удалось настроить (что доказывают фото с экрана при загрузке CP/M). Сведений о запуске остальных плат этих контроллеров пока нет.

Но для популярности ИРИШИ такой КНГМД в силу его громоздкости даже вреден, пугает людей. На мой взгляд промышленный КНГМД представляет лишь историческую ценность. Для практического использования людьми нужны намного более простые технические решения.

И оказывается такие решения позволяющие обойтись без дорогостоящего (тогда) дисковода были известны отечественным специалистам ещё в середине 80-тых.

Оказывается, что если DD-дисковода или винчестера (на маленькую емкость с 8-ми разрядным обменом) нет, то можно обойтись и без них. Идея заключается, в использовании виртуального, т.е немеханического, CP/M-привода в виде RAM-диска (а также опционально и ROM-диска). Сейчас ОЗУ на статике расширяется намного более простым способом, чем платой в 70 корпусов.

Понятно, что до 1990 года дисковод, даже б/у, вообще был недоступен для частных лиц. Даже в 1991/92, когда кооператоры и частные МП закупив на предприятиях МЭП дисководы наладили их продажу людям, дисковод всё ещё был слишком дорог, чтобы стать доступным всем любителям бытовых компьютеров.

Таким образом уже в 1985 году было известно решение позволяющее получить доступ к некоторым программам CP/M, в частности к макроассемблеру. Авторы ОКЕАНА изобрели электронный диск, организуемый из запасного ОЗУ компьютера. Для этого в ОКЕАН сразу при разработке установили ОЗУ в 128 кб и ПЗУ размера достаточного для хранения резидентной CP/M.

В ОКЕАНЕ из 128 кб ОЗУ (из которых 16 кб отнимает экран) 64 кб выделяется под эл.диск. CP/M на 48К там грузится из ПЗУ. Получается почти как в ОРИОНЕ, только в качестве DOS не ORDOS, а CP/M. Уже даже такая совсем минимальная конфигурация даёт существенные преимущества относительно магнитофонной версии машины. Это даёт возможность, загрузив их с МГ-ленты в эл.диск, использовать программы CP/M, сохраняя результаты работы также на МГ-ленте.

Авторы ИРИШИ ориентировались на промышленность и интересы бедных пользователей, в частности, любителей частников, их мало волновали. А стало бы большим плюсом для популярности ИРИШИ, если бы они почитали статьи про ОКЕАН-240 и заимствовали эту идею. И вместе с платкой расширения ОЗУ для ИРИШИ опубликовали бы ещё в 1987 году вариант минимальной иришиной CP/M, подобный океанскому. Это дало бы любителям инструментарий программирования за много лет до того, как стала доступна CP/M на базе дисковода.

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

Недавно (вот здесь можно почитать https://ruecm.forum2x2.ru/t1024-topic#12797) я странслировал такой минимальный вариант CP/M для ИРИШИ, используя в качестве эл.диска плату расширения ОЗУ. Сначала сделал эл.диск на 64 кб по стандартному варианту, а затем уже с нестандартным, т.е самодеятельным расширением ОЗУ до 128 кб (за счёт использования бита PC1 в придачу к PC3,PC2). [UPD: Сейчас (08.05.19) я странслировал CP/M с эл.диском уже на 256 кб]

Пока, ещё не используя ROM-диск (его хлопотно прошивать в реале, но в эмуляторе оперативно менять содержимое ROM-диска не проблема). Для расширения ОЗУ пока проблема в эмуляторе. В реале можно расширить ОЗУ множеством способов. Но надо чтобы эмулятор EMU эмулировал ИРИШУ с большим ОЗУ, а как для этого изменить конфиг не очень ясно даже для средних умов; точнее нужны длительные эксперименты.

Имея такой исходник CP/M для эл.диска добавка поддержки любого механического привода, если есть соответствующие процедуры чтения/записи сектора отнимает 37 секунд (я засекал время) - чтобы добавить флоп (или винт), мне достаточно откомментировать пару строк в процедуре SELDSK CP/M-BIOS и также откомментировать строчку INCLUDE FLOP.INC (или INCLUDE VINT.INC).

Уже крошечный привод в 64 или 128 кб позволяет проверять программы, хотя пока это мягко говоря неудобно. Неудобно именно из-за того, что эмулятор EMU не поддерживает DOS, файлы могут попадать в этот эмулятор только через ввод с магнитофона или из иришиного ROM-диска. А в моих эмуляторах программа 8-ми разрядки имела прямой доступ к винчестеру (могла читать/писать файлы, считывать каталог папки CP/M, а при запуске в MSDOS даже читать/писать сектора по 512 байт и даже форматировать дискету в дисководе).

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

Эмулятор EMU мог бы стать в этом плане удобным, если бы в него (но можно и мимо него) ввести препроцессор. Суть идеи в том, чтобы перед запуском EMU, например BAT-файлом, стартовал этот препроцессор, а уж после его отработки стартовал бы сам EMU. Этот препроцессор, я могу написать на Турбо-Си, Турбо-Паскале или даже на голом ассемблере 8086. Но увы это будет программа только для MSDOS, для Windows я никогда не программировал и осваивать не собираюсь (это заняло бы много лет, мне столько просто не прожить).

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

Если никто из знатоков Си для Windows не поможет, то позднее я сам напишу такой препроцессор-формирователь ROM-диска. Это несложно (на Си это полчаса). Но я смогу написать лишь для MSDOS, причём у меня на ассемблере выйдет даже быстрее, чем на ЯВУ (т.к для ассемблера есть готовые куски считать/записать файл, а ЯВУ я уже лет 20 как основательно забыл, в то время как ассемблер забыть трудно).

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

Недавно наконец сообразил, как удобно и совместимо расширить ОЗУ, но, главное так, что такой вариант можно сделать и в эмуляторе EMU (без его переделки, простым изменением конфига). Это позволит мне вскоре сделать версию CP/M с эл.диском в 256 кб, чего хватит для всех компиляторов. При таком объёме ОЗУ уже можно будет сделать версию CP/M с высоким TPA, отчего будут работать все компиляторы ЯВУ и другие программы, что нуждаются в TPA в 57 кб. Хотя это не особо актуально. [UPD: Кстати, схемотехника ИРИШИ позволяет отказавшись от некоторых её возможностей сделать эл.диск до 1 мб]

Если ROM-диск не ограничен в 64 кб, то мне, по крайней мере при старте, удастся встроить в эмулятор автоматическую загрузку эл.диска. Как упомянуто выше, это легко достигается таким трюком.

Запуск эмулятора делаем BAT-файлом. Первой строкой будет запускаться как бы препроцессор компоновщик ROM-диска, который будет все файлы из каталога FILES.CPM или FILES.DOS (если стартует не CP/M) "слеплять" в файл ROM-диска и только потом запускать эмулятор EMU.
Соответственно изменённое ПЗУ ИРИШИ по сбросу не будет делать выход в иришино стартовое меню, а сразу будет считана CP/M из ROM-диска и запущена.

Получается нормальная CP/M машина с нормальным стартом и без кучи мороки с загрузкой через МГ-вход. Вот, как говорится, "что большой ROM-диск животворящий делает". В моём эмуляторе ОРИОНА при старте делается то же самое, только загрузку файлов делает сам эмулятор, а автозапуск происходит благодаря свойству ORDOS автостартовать файл с именем EXT$ в квазидиске B:

Для базовой ИРИШИ с ОЗУ всего в 64К, даже при грамотном программировании для работы с винтом или флопом удаётся получить CP/M с уровнем TPA всего лишь в 42 кб. Для носителя в виде эл.диска TPA получается чуть больше ~43 кб. Для этого надо иметь доп.ОЗУ в 64 кб (т.е 128 кб всего). В принципе, пока программ для ИРИШИ размером под 40 кб или более нет, а для меньших программ этого хватит.

Иметь CP/M ИРИШИ с высоким TPA для непрограммирующего пользователя не особо надо. CP/M с высоким TPA требуется, потому что не все компиляторы ЯВУ работают в PC-эмуляторе CP/M, например 22NICE (т.е в тех эмуляторах, где диск не эмулируется, а используется диск MSDOS/Windows, а функции CP/M заменяются функциями CP/M). При доп.ОЗУ всего в 64 кб (128 кб всего) для CP/M с High TPA в 59 кб для эл.диска остаётся всего 48 кб (т.к ещё 16 кб отнимает экран). Потому CP/M с High TPA имеет смысл только для механического привода или, если доп. ОЗУ 256 кб и более. При 256 кб доп.ОЗУ удаётся поиметь High TPA CP/M с эл.диском в 216 кб.

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

Т.к возможны (и уже даже странслированы) две разные версии CP/M для ИРИШИ, то чтобы не тратить двойные усилия, разумно выбрать какую версию CP/M стоит поддерживать делая для неё новые программы.

Версия с High TPA позволяет прогонять все имеющиеся программы CP/M, но требует установки в ИРИШУ дополнительной памяти. Нужно расширение ОЗУ, как минимум, ещё на 64 кб (тогда крайне необходим дисковод). Или же - на 256 кб. Тогда уже можно обойтись и без винта или флопа, используя эл.диск из доп.ОЗУ.

А версия с Low TPA хотя и не требует установки в ИРИШУ доп.ОЗУ, но с такой ущербной CP/M не работают 95 % фирменных программ CP/M. По сути работают только - единственный текстов редактор WordMaster, все CP/M-ассемблеры, а из компиляторов ЯВУ только компилятор PL/M. Больше ничего не работает, т.е такая CP/M пригодна лишь в качестве файловой системы и для этих целей она ничуть не лучше (точнее хуже), чем РК-ДОС размером всего в 4 кб или даже Hameleon-DOS с размером всего в 2 кб.

Доп.память в ИРИШЕ конечно лучше делать бестормозной, т.е работающей без WAIT. Хотя, если это ОЗУ используется лишь для эл.диска (что имеет место в CP/M с TPA на всего 43 кб), то не особо навредит, если доп.ОЗУ будет слегка вэйтованное, т.е тормозящее процессор не более, чем на 15 %. Что получается, если из каждых двух соседних маш.тактов процессору для доступа выделен лишь один из них, а соседний такт отдаётся на нужды регенерации DRAM-памяти.

В ИРИШЕ можно сделать 3 видеорежима и в каждом из них можно включить отображение на 20 или 25 строк. Ещё можно включить шрифт двойной ширины, но в режимах на 40 символов такие широченные буквы никому не нужны, а в режиме на 80 символов они позволяют вставить в текст заголовок растянутыми символами (равными по размеру символам в режиме 40-ка символов в строке). Для применения в DOS видеорежимы на 40 символов в строке совершенно неинтересны. Потому я считаю, что в DOS используются только два текстовых видеорежима - 80 на 20 и 80 на 25. По умолчанию (при старте DOS) включается режим на 25 строк.

Управляет переключением 20/25 строк бит D6 контрольного байта MODE, который располагается по адресу $FF45 в карте 2. Но управлять самим этим байтом нельзя. Этот байт можно только читать, когда надо узнать текущий режим. Для переключения режимов используются управляющие коды консоли. Это искейп коды, которые представляют собой цепочку из байта 1BH и ещё одного командного байта и опционально может быть ещё один или более передаваемых с командой параметров.

Такая цепочка символов целиком называется управляющей искейп-командой и программно выводится на консоль CP/M. При этом не важно используются функции BDOS или прямой вызов подпрограммы CONOUT в CP/M-BIOS. Но не вызов п/п-ммы CONOUT в ROM-BIOS ИРИШИ. Т.к у ПЗУ ИРИШИ и у CP/M разные искейп-коды. Да и выводить удобнее средствами CP/M, а не лезть в ПЗУ (т.к отпадает забота о коммутации карт памяти, перестановке стека, отключении прерываний перед коммутацией памяти и т.п.). Для включения видеорежима предназначен искейп-код 1BH,51H в котором третий параметр задаёт видеорежим.

Большинство CP/M-программ изначально настроено на экран 80 на 25. Но т.к в таком режиме строки на экране ИРИШИ слипаются, читать текст приятнее в 20-ти строчном режиме. Для ручного переключения числа строк видео режима я нацарапал крошечную програмку MODE. Она запускается из командной строки с одним параметром, который может быть или числом 20 или числом 25.

Исходя из возможностей ИРИШИ, по идее все текстовые редакторы должны поддерживать оба эти режима, т.е работать и на 20 строк и на 25. И в идеале - самонастраиваться на включённый, текущий видеорежим. К сожалению, я не дизассемблировал все текстовые редакторы и не знаю, как в них устанавливать формат экрана.

Но для текстового редактора WordMaster разработанного ещё в 1976 году я это делать могу, т.к мне удалось узнать, что там число строк и число символов в строке можно задать вручную изменив байты с оффсетом $B9 и $BA от начала программы (т.е абсолютные адреса $1B9 и $1BA). Зная это, я смог встроить в WM.COM крошечную заплатку, которая при старте автонастраивает WM.COM на текущий видеорежим. При этом WM.COM мог бы уже стать неуниверсальным, т.е перестал бы быть корректной программой для любой CP/M.

Чтобы этого избежать, в начале проверяется, что WM.COM запущен в High TPA CP/M ИРИШИ для чего контроллируется цепочка байтов характерная для конкретной трансляции CP/M для ИРИШИ. И если это High TPA CP/M ИРИШИ, то считывается байт $FF45 в карте 2 и в нём проверяется бит D6 (задающий число строк на экране). И соответственно настраивается WM.COM. Потому не надо иметь две версии WM для двух режимов экрана. А если эта программа запускается в иной версии CP/M (т.е в иной CP/M для ИРИШИ или вообще не на ИРИШЕ), то запускается стандартная версия на 80*25.

Все мои трансляции CP/M не просто тупые перетрансляции оригинальной CP/M из 1977 года. Чем они дополнены относительно оригинала? Даже самые первые версии для ОРИОНА уже были дополнены стартовой обработкой файлов AUTOEXEC.SUB и CONFIG.SYS. Назначение AUTOEXEC как и в PC. А CONFIG позволял задать параметры дисковода (что позволяло избежать кучи версий под разное железо). Сейчас уже не существует такого разнообразия ретро-флопов (1*35, 1*40, 2*40, 1*80, 2*80 и время шага головки 160/30/6 МСЕК), что было в начале 90-тых и потому CONFIG не нужен. Остались только дисководы формата 2*80 с шагом в 3-6 МСЕК, хотя возможно где-то сохранились дисководы 2*40 от ранних PC. Все более ранние дисководы, что использовали резиновые пассики и улитку для движения головки уже ни у кого не сохранились.

Все трансляции начиная с ACP/M-1.60 содержат кроме этого замену конкретных символов и программирование упр.кодов для одноклавишного ввода ключевых фраз, автоформат эл.диска с автопереназначением эл.диска (если ОЗУ для него есть) диском A:, RST-входы, программные часы и вектора для загрузки драйверов. Также исправлена ошибка CP/M-BIOS КОРВЕТА, - по BDOS функции DISK RESET выполняется автонастройка на формат диска. Некоторые версии имеют даже улучшенную функцию 10 BDOS (имеющую память на ранее введённые команды и полноценный редактор вводимой строки). Есть доработанный CCP (для Z80) и очень простой (всего 200 байт доп.кода) вариант введения дат у файлов.

Это подробно расписано в документации к ACP/M 1.60 25 лет назад, здесь напомню о доп.входах в CP/M-BIOS. Речь о входах BIOS+36H и BIOS+39H. Эти входы введены лишь начиная с 1995 года и являются аналогом стандартных подпрограмм ПЗУ ОРИОНА с аналогичными адресами F800H+36H и F800H+39H.

Естественно это входы чтения и записи ячеек в дополнительном ОЗУ. Они есть во всех версиях CP/M, что я транслировал после 1995. Наличие этих входов даёт независимость от конкретного железа и конкретной версии CP/M-BIOS. Потому было легко применить тот же код от ОРИОНА и для РК86 и для Специалиста и вот теперь для ИРИШИ. Т.е благодаря наличию этих входов не надо переписывать драйвер VDISK-а из ОЗУ или внешнего эл.диска на отдельной плате, всё что требуется сделать, - это обеспечить работу входов RRAM и WRAM.

Хотя как раз для ИРИШИ пришлось чуть доделать и драйвер VDISK-а, т.к для ИРИШИ работа этих подпрограмм чуть иная, потому что в ИРИШЕ коммутируются не банки памяти, а карты памяти. Потому при вызове RRAM или WRAM в регистре А передаётся не номер банки, а номер карты. Из-за этого нет сплошного массива памяти, как в машинах с коммутацией банок ОЗУ. Имеется ввиду, что вызывая эти ф-ции с инкрементом HL нельзя прогнать HL от 0 до FFFF, рассчитывая получить сплошной массив. В ИРИШЕ сплошной массив максимум на 16 кб, т.к именно такова дискретность диспетчера памяти ИРИШИ. Можно было бы сделать табличный перерасчёт, чтобы была совместимость с машинами имеющими банковую коммутацию. Но это невыгодно, т.к тогда есть доступ только к памяти входящей в VDISK, а с данной реализацией п/п-ммы RRAM/WRAM пригодны для доступа к любому ОЗУ использующему стандартный диспетчер памяти ИРИШИ управляемый битами PC0...PC3.

Таким образом для доступа к VDISK-у во всех моих CP/M, где есть поддержка эл.диска имеются подпрограммы RRAM и WRAM, адреса которых BIOS+36H и BIOS+39H соответственно. Конкретного адреса конечно нет, т.к точка BIOS в каждой трансляции CP/M своя. Адрес BIOS+3 программы узнают считав адрес перехода команды на адресе 0. Там стоит JMP Warm-Boot, т.е переход на BIOS+3. Таким образом, чтобы узнать адрес подрограмммы RRAM (чтения байта из доп.ОЗУ) достаточно считать слово из ячейки 0001 и прибавить к нему 33H. В итоге получится искомый адрес BIOS+36H.

Как упомянуто выше, подпрограммы RRAM/WRAM во всех моих версиях CP/M ИРИШИ сделаны так, что позволяют доступ к любой ячейке памяти ИРИШИ. Вот код вышеупомянутой заплатки автонастраивающей редактор WM.COM под текущее число строк. Здесь как раз п/п-мма RRAM необходима, чтобы считать ячейку MODE, т.к напрямую процессору эта ячейка недоступна, - её нет в адресном пространстве.

Т.о т.к High TPA CP/M работает в карте, в которой нет служебных ячеек ROM-BIOS, для чтения служ.ячейки MODE (FFF45) здесь и вызывается подпрограмма RRAM по адресу BIOS+36H (адрес BIOS вычисляется, чтобы программа могла работать на любой подобной CP/M с любым уровнем TPA).

        LD      HL,RETADR
        PUSH    HL

        LD      HL,(1)
        LD      DE,36H-3
        ADD     HL,DE
        PUSH    HL
        LD      HL,MODE
        LD      A,00001000B
        RET

RETADR: LD      A,C
        AND     01000000B
        JP      NZ,NO_KOR
        LD      A,20
        LD      (01B9H),A
NO_KOR:

Ещё одним очень полезным и востребованным нововведением в ACP/M 1.60 для ОРИОНА было добавление RST-входов. В CP/M всех отечественных компьютеров это сдуру не использовано. И только в моих CP/M перетрансляциях RST есть. Я узнал об этом, т.к с 1983 года был читателем библиотеки иностранной литературы и читал иностранные журналы с описаниями любительских компьютеров. Во всех моих CP/M перетрансляциях RST есть. Естественно RST сохранены и в моих перетрансляциях CP/M для ИРИШИ.

Работа RST-входов ясна из говорящих меток в нижеследующем листинге ZERO-блока, который кидается на адрес 0 при каждом Warm Boot CP/M. RST команды нельзя использовать в корректной CP/M-программе, т.к не у всех CP/M-компьютеров есть RST-входы. Потому их используют только для программ работающих по железу, т.е уже изначально не являющихся корректными по отношению к CP/M и рассчитанные работать только на данном компьютере. В реальности почти все программы любителей были некорректными.

Особенно полезны и чаще всего используются RST 10H - печать на экране символа из рег.A и RST 18H - вывод сообщения, стоящего сразу за командой RST. Стоп-байтом служит как байт 0, так и выставленный старший бит в последнем символе сообщения. RST 20H и RST 30H, дублирующие стандартные входы BIOS полезны лишь для экономии кода - это соответственно STATUS и CONIN.

Вход XF81B на ОРИОНЕ был нужен, чтобы в программах не останавливался вывод программных часов работающих без прерываний (хотя в ОРИОНЕ F81B можно вызывать из любой банки, но если вместо вызова напрямую делать RST это не только короче, но и часы не останавливаются). Для ИРИШИ это не актуально, - у неё нет п/п-ммы F81B, т.к принцип работы с клавиатурой другой и реализацию программных часов и много чего другого я в текущих вариантах CP/M для ИРИШИ ещё не сделал. Например, как делать ввод ключевых слов по нажатию функц.клавиш (с <Control> и без), если функциональные клавиши ИРИШИ в эмуляторе не работают (да и даже коды выдаваемые ими в реале неизвестны)?

Программные часы, используя прерывания от таймера ВИ53 можно сделать точными. Большой объём TPA в 59 кб, позволяет многое уместить, т.к без всяких потерь можно уменьшать уровень TPA до 52 кб, освободив для разных дополнений DOS аж 7 кб (это не даёт ни один другой CP/M бытовой или промышленный компьютер из СССР, хотя такой же высокий TPA возможен на развитых клонах ZX, но там CP/M не в ходу).

Например, имея существенный запас места, можно имплементировать поддержку нескольких ходовых терминалов. Тут сразу приходит на ум терминал Роботрона-1715, чтобы можно было использовать программы для него (в СССР имелись только программы для терминалов VT52 и Роботрона). А на западных архивных сайтах CP/M программы в основном для ходовых западных моделей. Если удастся узнать упр.коды их терминалов, то по крайней мере, их текстовые редакторы можно будет использовать.

Хотя в своё время я понял, что из импортных редакторов имеет смысл только WordMaster, т.к многие остальные импортные редакторы CP/M работают только в КОИ-7 (коды с выставленным старшим байтом используются иначе). В любом случае, лучшим редактором является SuperText, хотя для системы, где маленькая ёмкость привода, - остаётся мало места для текста. Т.к SuperText не только сам имеет объём своих файлов в 160 кб, но ещё и при работе создаёт на диске свои буфера и своп-файлы огромного размера.

Спойлер: