ПО. ПЭВМ "Ириша". Общая тема.

Данная тема предназначена для различного обсуждения программного обеспечения (ПО) для ПЭВМ "Ириша", "Ириша-Л", "Ириша-М" и других модификаций. Тут можно обсудить поиск уже имеющегося ПО или написание своего ПО. В общим тема для общения и обсуждения разного ПО для ПЭВМ "Ириша".

Из того, что по идее возможно найти, или оно уже есть:

---
1. Текстовый редактор IRITEXT
2. FORTH INTERV (разработка авторов Ириши)
3.  игра STAKAN
4. IBASIC
5. RTV
6. SMON
---

---
01. Резидентное ПО (в кодах, прошивках микросхем)
02. ОС "IRISHA" с утилитами POWER, DDT, CONFIG, M&O, LINK, SID
03. Бэйсик FS-III. Бэйсик = MBas + GRAFIC
04. FORTRAN (F80)
05. FORTH (разработка авторов "ИРИШИ")
06. PASCAL MT+
07. C BDS 1.50
08. Редакторы WORDSTAR, WORDMASTER, IRITEXT, графический монохромный редактор PIC (все это комплект программ "ДОКУМЕНТ")
09. D BASE II (база данных)
10. Демонстрационные программы 3-4 шт.
11. Игровые программы 3-4 шт.
---

Вчера/сегодня посидел помучил программу подсчёта контрольной суммы, что представлена в красной книжечке. Общий смысл того, что она делает уловил, использованные команды просмотрел, алгоритм для себя вычертил, для лучшего понимания, что она делает, в коды перевёл.
Но пока детально не разобрался, нужно ещё мучать теорию, как вообще подсчитывается контрольная сумма.
Но время провёл интересно, перед сном.

Вот её код:

Код:


0100 LXI D, 4000     ; Адрес начала программы
0103 LXI B, 380       ; Длина программы делённая на 2
0106 LXI H, 0000     ; Счётчик контрольной суммы
0109 LDAX D           ; Выборка байт
010A ADD L             ; И их суммирование в рег. H
010B MOV L, A        ;
010C INX D              ;
010D LDAX D           ;
010E ADC H             ;
010F MOV H, A        ;
0110 INX D               ;
0111 DCX B              ; Уменьшение счётчика слов
0112 MOV A, B         ;
0113 ORA C              ; Проверка на границу программы
0114 JNZ 109            ; Если не конец, то уход в цикл
0117 RST 1               ; Возврат в монитор


11 00 40 01 80 03 21 00 00 1A 85 6F 13 1A 8C 67
13 0B 78 B1 C2 09 01 CF




Буду потихоньку дальше мучать ПО от Иришки, довольно увлекательно...

Кину тут, пригодится...

Код:


; ПОДСЧЕТ CHECK SUM: (HL)...(DE) --> BC

CHSUM:   LXI  B,0
CHSLOO:   MOV  A,C            ; Неперемещаемо !!! 0F944H
   ADD  M
   MOV  C,A
   PUSH PSW
   CALL CMPDH
   JZ  POPRET
   POP  PSW
   MOV  A,B
   ADC  M
   MOV  B,A
   INX  H
   JMP  CHSLOO

POPRET:   POP  PSW
   RET

; ───────────────────────────────────────────────────

; HL-DE ??

CMPDH:   MOV  A,H          ; Неперемещаемо !!! 0F956H
   CMP  D
   RNZ
   MOV  A,L
   CMP  E
   RET


резерв.

Viktor2312 пишет:Кину тут, пригодится...

Вы неграмотно выкладываете исходники. На этом движке ни тэг {code}, ни тэг предформатирования {pre}, не работают. Тэг {code} лишь придаёт шрифту зеленый цвет и делает рамку и всё... Движок и внутри тэга {code} по-прежнему заменяет табуляции и более двух подряд стоящих пробелов на один пробел и даже не заменяет шрифт на моноширинный.

Я ещё несколько месяцев назад открыл способ, как на этом движке показывать преформатированные тексты. Для этого достаточно иметь лишь приличный текстовый редактор (UltraEdit - лучше него по возможностям не найдёте). Я уже где-то описывал методику, но сейчас не найду где.

Нужно сначала табуляции (код 9) заменить на пробелы. Затем вставить текст, обрамить его тэгом {quote} или лучше {spoiler}, что лучше (т.к цвет фона белый лучше и большой исходник не удлиняет страницу), а также незарегистрированные читатели не увидят исходник. Затем смените фонт ассемблерного фрагмента на 'Courier New' (это д.быть последней операцией) и кликните на кнопке "Отправить".

Тогда получится вот так:

; ПОДСЧЕТ CHECK SUM: (HL)...(DE) --> BC

CHSUM:  LXI     B,0        ; Неперемещаемо !!! 0F944H
CHSLOO: MOV     A,C
        ADD     M
        MOV     C,A
        PUSH    PSW
        CALL    CMPDH
        JZ      POPRET
        POP     PSW
        MOV     A,B
        ADC     M
        MOV     B,A
        INX     H
        JMP     CHSLOO
               
POPRET: POP     PSW
        RET    

; ---------------------------------------------------

; HL==DE ??

CMPDH:  MOV  A,H           ; Неперемещаемо !!! 0F956H
        CMP  D
        RNZ
        MOV  A,L
        CMP  E
        RET

А ещё лучше вот так:

Спойлер:

По программному обеспечению нужен раздел, т.к по-хорошему для компьютера должно быть много тем по программам, а темы про сборку это просто введение к ним. И должно быть больше любителей программирования, чем любителей гробить себе здоровье ядовитыми парами канифоли. Но почему-то на всех подобных форумах подавляюще преобладают любители трахаться с железом, а на этом форуме, если судить по темам, особенно.

ИРИША прямо сейчас не отличается изобилием программ, т.к оригинальные программы утеряны, а новые еще в процессе (я знаю лишь иришин текстов редактор, DDT и три игры, нет даже бейсика).

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

Самым простым и быстрым способом увеличить объём ПО является использование на ИРИШЕ программ из CP/M (якобы их 10.000, но на самом деле хоть как-то полезных программ в 100 раз меньше, причём 3/4 из них компиляторы и редакторы). CP/M-игр можно поиметь всего с десяток, да и с ними надо немного потрахаться, чтобы настроить искейп-коды. Ещё можно взять до полусотни убогих игр на бейсике из сезона 1977 года (в основном текстовые квесты).

Для использования CP/M-программ достаточно поиметь на ИРИШЕ любой массовый носитель, будь то дисковод, винчестер, RAM-диск или контроллер огромной флэш-памяти. А для этого нужно всего несколько подпрограмм - в основном процедуры чтения и записи сектора (неважно физического или логического). Скомпоновать это в исходник CP/M-BIOS несложно. Но увы, поиметь CP/M на базовой ИРИШЕ (т.е без наличия привода) - невозможно.

Без наличия привода что-то поиметь из программ можно только конверсией от других компьютеров с таким же процессором. Несложно адаптировать для ИРИШИ бейсик и любые системные программы РК и ОРИОНА, что не лезут в экранную область и матрицу клавиш. Адаптация любой корректной программы для машины имеющей аналогичные входы в ROM-BIOS при наличии исходника требует трудозатрат в 15 минут (это лишь поиск и коррекция вызовов F803, F809, F812 и F81B на аналогичные вызовы данной иришины).

Недисковые фирменные бейсики (типа TINY или альтаировского) адаптировать ещё проще. У них для вывода/ввода на консоль стоит всего одна команда OUT/IN, - достаточно заменить на CALL (иногда удобнее на RST). Но вот получить отличный бейсик типа Digital Research, MSX или Microsoft, которые имеют объём уже не в 4 или 8 кб, а в 28 кб, - это уже солидный труд, как минимум, на 50 человеко-часов. Имеется ввиду переделка в бейсике графических процедур (для использования только текстовых процедур ничего менять не надо).

У меня есть MSX-бейсик (32 кб) адаптированный для ОРИОНА А.Вакуленко, который работает в ORDOS и имеет графические операторы. При наличии Z80 его лучше всего будет адаптировать для ИРИШИ. Тогда у неё будет один из лучших бейсиков среди отечественных 8-ми разрядок. Но на порядки проще потратить полчаса и адаптировать для ИРИШИ эр-кашные бейсики (бейсик 1A20, я уже сделал, т.к имел исходник).

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

К сожалению, кроме авторов бейсика и пакета МИКРОН, практически никто не делал корректных программ. А первый текстов редактор МИКРОН настолько убогий, что бесценен, хотя второй, 4-х килобайтный намного лучше. Если он корректный, то и его несложно адаптировать.

Я уже когда-то конвертировал для ИРИШИ специалистовский текстов редактор SCREEN (он корректный за исключение стековых роликов экрана вверх-вниз) работающий с RAM-диском RAMDOS и специалистовский ассемблер МИКРОН. Чтобы получить минимальный инструментарий - текстов редактор с ассемблером.

Но сейчас лучше было бы странслировать текстов редактор (не иришин) и не с убогим ассемблером, а с макро ассемблером (т.к в 1993 в дистрибутиве РК-ДОС от Лианозово мне удалось поиметь РК-шный макроассемблер). При прошивке в ПЗУ получится резидентный инструмент для программирования на самой Ирише. Это займёт 12 кб ПЗУ - 4 кб редактор и 8 кб РК-шный макро ассемблер. У меня есть и свой макроассемблер, но он намного больше и не намного лучше. Конверсия бейсика и текстового редактора это задачи, что требуют совсем немного труда.

Ещё хотелось бы поиметь визуализатор РК-игр на ИРИШЕ. Чтобы в играх требовалась минимальная переделка лишь опроса клавиатуры (там, где прямое обращение в порт 8000), а экран визуализировать на прерываниях, скидывая несколько раз в секунду экран РК с 76D0 в экран ИРИШИ.

А вот, чтобы поиметь CP/М, требуется много электро-траха. Контроллер дисковода спаять не проблематично, но надо искренне любить МГТФ. Для чего у меня даже есть ещё одна раскуроченная плата граф.адаптера ИРИШИ (увы, микрошин РК-КНГМД не использовать, он слишком длинный). На плате можно спаять или КНГМД Корвета или РК-КНГМД (но только не родной иришин). К сожалению, я плохо дружу с паяльником и энтузиазм к железу у меня уже почти на нуле...

Наименее трудоёмким способом поиметь CP/M мне кажется установка в граф.адаптер ИРИШИ вторым этажом второй банки РУ5 (управляя доп.битом, целиком включаем то основную банку, то альтернативную). Это даст RAM-диск в 64 кб. Этого уже достаточно для некоторых программных работ, запуска кое-какого ПО CP/M и отладки аппаратуры и ПО для дисковых приводов.

Если 64К будет мало, тогда придётся попаять побольше и сделать эл.диск 256+ кб на статике. Это не особо сложно, только ППА ВВ55 с интерфейсным обрамлением и панельки на 28 ног (на 28 ног, узкие и широкие). Это даст возможность не только получить CP/M с минимальным эл.диском и уже из неё отладить работу с винтом и дисководом, но и использовать все компиляторы (у них объём кода обычно не превышает 200 кб, так что останется место для исходника).

Вот исходник альтернативного монитора работающего из ОЗУ (я использовал такой-же, но прошитый в ПЗУ вместо DDT, в 4 кб как раз влезает этот монитор 2 кб и RAMDOS для эл.диска 2 кб). Здесь интересно посмотреть директивы обмена по линии со Специалистом (DIR_I и DIR_O), что сделаны вместо МГ-загрузки (т.к ИРИША не может работать в реальном времени, отчего стандартные процедуры МГ-обмена не годятся). Сейчас у меня уже есть IBM PC с LPT-портом и можно сделать загрузку из неё. Посмотрите также на использование иришиных упр.кодов для переключения регистров (РУС/ЛАТ шрифт, КОИ-7/КОИ-8 ), инверсии и включения/выключения курсора.

Наличие такого монитора имеющего все РК-совместимые стандартные входы позволяет напрямую использовать некоторые программы Специалиста, а корректные программы РК нуждаются только перетрансляции вызовов F800 на C800. Использование входов на F800 в базовой ИРИШЕ проблематично, т.к в рабочей карте 2 экран на 80 символов (нужный чтобы уместить 64) занимает область C000...FFFF. Теоретически можно включить режим 1 (моно 320*200) с экраном на E000, но резидентный драйвер выводит только 40 символов в строке, а надо 64. 64 символа на экран 8 кб выводятся лишь мелкошрифтом размера 5*8, что некрасиво и очень тормозит.

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

монитор с РК-подобными входами:

эр-ка-шный ассемблер для ИРИШИ:

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

RAMDOS ИРИШИ для эл.диска 512 кб:

Данная DOS не годится для винта или флопа, только для RAM-дисков (они могут быть физически любыми, т.е из ОЗУ ЭВМ или внешними). DOS хранит файлы впритык и при удалении непоследнего файла массив схлопывается, что для дискеты неприемлемо (по этим же причинам не стОит иметь RAM-диск объёмом более 1 мб, это неприятно затормозит при удалении файлов при почти заполненном диске).

При переделке на другую схемотехнику (тип носителя) требуется переделать только п/п-ммы нижнего уровня (чтение/запись байта и массива). Переделку для эл.диска из излишнего ОЗУ ЭВМ уже делали, это несложно. Примечательно, что размер кода DOS всего 2 кб - никто не сможет сделать аналогичный код меньшего размера.

Описание пока в КОИ-7, не отредактированное и не конвертированное в нижний регистр. Позже м.быть сделаю это и заменю.

функции RAMDOS:

Текстовый редактор это одна из самых важных программ компьютера. К сожалению, на медленных машинах, а также на машинах с большим графическим экраном для текстообработки 8-ми разрядкам обычно не хватает скорости.

В то же время в текстовом редакторе процессор 95 процентов времени простаивает, ожидая нажатия клавиш. Нельзя-ли используя это обстоятельство улучшить динамические характеристики редакторов. Рассмотрим вначале какие критичные к скорости прогона ситуации возникают в ходе работы текстового редактора.

Для графических экранов очень тормозной процедурой является ролик, который бывает вверх или вниз. Ролик вверх понятно возникает, если нажать <ВК> в последней строке экрана. Эта процедура есть в ROM-BIOS-ах всех самодельных ЭВМ кроме Специалиста.

Но вот обратной процедуры, ролика экрана вниз нет ни в одном отечественном ROM-BIOS. Это естественно ошибка, т.к такой код есть во всех терминалах и его наличие существенно ускоряет текстовые редакторы (достаточно попробовать турбо-паскалевский редактор на ОРИОНЕ с грамотным драйвером и без него). Это делается искейп-кодом для вставки строки. Новая строка может вставляться в любой строке (не обязательно верхней) и при этом все строки ниже вставленной сдвигаются вниз экрана, происходит обратный ролик.

Естественно ролик вниз нужен не только при вставке строк, но и когда курсор находится в верхней строки и нажимается клавиша <Вверх>. Тогда все строки должны мгновенно отъехать вниз. Ясно, что не имея искейп-кода для вставки строки нет возможности стандартно сделать ролик вниз. Это означает, что хороший редактор нельзя написать в виде корректной программы, т.е написать текстов редактор, который прекрасно работал бы одновременно на ОРИОНЕ, РК86 и Львове.

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

В редакторах для текстовых машин из ситуации отсутствия ролика вниз выходят способом полной очистки экрана и выводом заново всего экрана. Для текстовой машины это тоже неприятно, но на графической это вообще катастрофа. Т.к на графической машине вывод одного символа отнимает в 50...150 раз больше времени, чем на текстовой. Особенно тормознуто получается при небайтовом шрифте и в цвете.

Если в редакторе ролик вверх быстрый, а ролик вниз медленный и с полной перерисовкой экрана это значит писал неграмотный автор. Ролик и вверх и вниз должен происходить с одинаковой скоростью и без очистки всего экрана и перерисовки заново. Нетрудно понять, что текстов редактор МИКРОН первой версии для РК86 неграмотный. Впрочем, он ещё более неудачен тем, что вообще не экранный, а нечто среднее. Такую концепцию авторы выбрали возможно ошибочно опасаясь, что скоростей РК не хватит на полноценный экранный режим.

Ролик экрана 12 кб стеком даже при клоке 2 МГЦ получается вполне приемлемым (проблема лишь в том, что не все авторы умели это делать). О проблемах со скоростью вывода и ролика почти все знают. Но есть более труднопреодолимая причина тормознутости текстовых редакторов на 8-ми разрядках. Это проблема сдвижки текста.

Есть два подхода хранения текста в ОЗУ. Первый - распакованный, применённый в родном текстовом редакторе ИРИШИ. Для медленных машин это позволяет выиграть скорость.

Суть в том, что весь текст, например с шириной в 80 символов в строке хранится в ОЗУ в распакованном виде и в таком виде и редактируется. Тогда любая строка, даже если в ней нет вообще ни одного символа занимает в ОЗУ ровно 80 байтов. Ясно, что ОЗУ тратится очень неэффективно. Из-за этого текстов редактор ИРИШИ и имеет ограничение всего в 300 строк (а даже РК может редактировать текст, где число строк в 10 раз больше), но зато никаких сдвигов и скорость работы не страдает.

Из этого ясно, что текстов редактор ИРИШИ не имеет практической ценности (вряд-ли существуют приличные ассемблерные программы умещающиеся в 300 строк) и даже в 80-тые был пригоден только для написания писем бабушке. Кстати, если при выводе на МГ редактор не нормализует текст, сокращая его табуляциями и отбрасывая пустоты в конце строк, то это совсем кошмар (глупо писать на МГ-ленту 40 кб, если можно писать всего 5 кб).

А теперь сообразим почему разработчики выбрали такой метод редактирования текста. Да, точно. Им тоже не хватило скорости процессора, т.к ИРИША очень тормозная в режимах 2 и 3.

Чтобы понять почему нужна скорость, рассмотрим, как хранит текст грамотный текстов редактор. Строки разделены разделителем. Это может быть CR или LF или CR+LF (в CP/M используют CR+LF). Пустые пробельные хвосты строк не пишутся и текст уплотняется табуляциями.

Алгоритм редактирования в грамотном текстовом редакторе построчный. Та строка на которой стоит курсор распаковывается в строчный буфер. Т.е все табуляции расширяются пробелами и конец строки после последней отображаемой буквы тоже заполняется пробелами. Таким образом при ширине строки в 64 символа размер строчного буфера д.быть не менее 64 байт (обычно делают немного больше, чтобы при случайной сдвижке за край экрана буквы не терялись). Когда курсор сдвигают с одной строки на другую без редактирования, то каждый раз в строчный буфер перезагружается новая текущая строка.

Если же ввести какие либо символы в строку, то в зависимости от режима (вставка/замена) новые символы будут вставляться с автораздвижкой или взамен старого текста. Допустим исходная строка содержала одно слово в 8 букв. После окончания редактирования строки и нажатия <ВК> выполняется нормализация строки, т.е в полной строке длиной 64 символа, там где можно вставляется табуляция, а пробельные хвосты строк отбрасываются. Допустим после редактирования и нормализации длина строки увеличилась до 30 символов. Но в исходном месте для этой строки было всего 9 байтов (8 символов и разделитель 0DH). Как же туда вставить 31 байт отредактированной строки?

Для этого надо выполнить раздвижку последующего текста на 31-9= 22 байта. Значит, если весь текст занимает в ОЗУ 40 кб, и редактируемая строка в начале текста, нам надо сдвинуть на 22 байта огромный массив в 40 кб. На скоростях ИРИШИ в режимах 2/3 это занимает ~3-4 секунды. Это значит, что после каждого изменения надо ждать 3 секунды. А если это последняя строка экрана, то одновременно делается ролик, т.е сдвижка экрана 16 кб и сдвижка текста в 40 кб, что ещё тормознее. Понятно, что такой редактор будет удобен только для маленьких текстов, т.к чем больше текст, тем медленнее редактирование.

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

Понятно, что текст при этом сделается рваным, строки будут следовать не подряд. Но зато скорость редактирования вообще не пострадала. Никаких долгих сдвигов огромных массивов. Чтобы быстро находить такие перенесённые строки составляется таблица адресов таких перенесённых строк.

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

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

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

Несколько недель назад в первом приближении CP/M для ИРИШИ сделал.

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

В самОм имеющемся эмуляторе писать программы неудобно, из-за того, что в эмуляторе без поддержки DOS пользоваться CP/M-текстовыми редакторами неудобно. Например, чтобы воспользоваться SuperText-ом надо сначала полчаса вручную загружать 165 кб его кода, т.к SuperText такой большой по объёму. Думаю, что позже кто-то сделает эмулятор ИРИШИ, где таких проблем не будет.

Архитектура ИРИШИ не идеал, но привыкнув к ней, особых проблем нет. Просто надо всегда помнить, что сегменты 0 и 8000 не переключаются при смене карты. Всяко архитектура ИРИШИ лучше архитектуры ОРИОНА или ЭРИКА.

Но пока занимался программированием для ИРИШИ очень мало, в последние 3 недели вообще и двух часов не наберётся. Лишь начал делать Нортон. Потому, что всегда сделав DOS, затем делается Нортон.

Но тут выяснилось, что 80 символов в строке, как я всегда и полагал, ни для чего невыгодны и особенно невыгодны для Нортона CP/M. Собственно, почти весь процесс написания Нортона ИРИШИ для меня сводится к написанию рамы и глюкала (это обслуживание движения балки выбора по панелям). Для двух-колоночных панелей глюкало уже есть готовое. Код команд работающих с дисками тоже писать не надо, он тоже есть готовый от Нортонов для других CP/M-систем.

Ранее мне доводилось делать Нортоны только для экрана на 48 символов в строке. И для DOS без даты этого вполне хватало. Вот стандартная горизонтальная раскладка рамы, что я применял в Нортонах ОРИОНА:

00        10        20        30        40
012345678901234567890123456789012345678901234567
| 88888888.333 | 55555 || 88888888.333 | 55555 |

Как видите 48 символов в строке (что есть в ОРИОНЕ и Специалисте) идеально подходят для 2-х панелей файлов с именами типового вида (т.е когда в имени 8 символов до точки и 3 символа расширение), а размеры файлов не превышают 99999 байт. Когда приходилось делать Нортон для экрана в 64 символа, то справа от панели делал вывод статистики.

А для 80-ти символов в строке для CP/M просто не придумать доп.столбцов, чтобы вставить в раму. Делая NC для MSDOS, Питер Нортон выкрутился вставив даты файлов. Это позволило растянуть раму на все 80 символов. Но увы, с этим у нас облом, - в стандартной CP/M нет дат у файлов.

Дату ввести несложно, причём никак не мешая программам. Я это уже делал, это совсем немного кода. А вот Digital Research перемудрили, - они вставляли отметки даты в стандартный каталог CP/M. Так тоже можно, но это увеличивает объём каталога вдвое и значит вдвое тормозит работу с каталогом. Я поступил проще, ввёл параллельный каталог, причем на той же дорожке, но на другой стороне дискеты (отчего чтение даты никак не тормозит, т.к головка уже стоит на нужной дорожке).

Например, чтобы узнать дату выполняется стандартная функция поиска в каталоге. При возврате в переменных TRACK/SECTOR стоит позиция и в регистре A возвращается код оффсета каталогового экстента в буфере чтения. После чего чтобы получить дату файла достаточно вместо трека 4 в переменную трек подставить 5 и выполнить чтение сектора, после чего в буфере с полученным ранее оффсетом мы имеем дату без всяких дополнительных хлопот.

При введении дат в CP/M моим способом общий объём доп.кода не превышал 200 байт, введение дат было написано и отлажено за один день. Называлась CP/M-Plus (т.к имела и другие преимущества перед CP/M), но работала только на ОРИОНЕ с Z80CARD-II. Так, что я могу без особых усилий ввести в CP/M для ИРИШИ даты файлов. Хотя это и бесполезно без наличия часов 512ВИ1.

Т.е сейчас я рассматриваю два варианта. Это писать драйвер более широкого шрифта для ИРИШИ. Речь о шрифте 12*8, что даёт 640:12= 53 символа в строке или о шрифте 10*8, что даёт 640:10= 64 символа в строке. 64 символа в строке мне слишком много, склоняюсь к 53, это кстати, мой любимый формат экрана для написания программ (потому у меня в текстовом адаптере было 53 символа в строке). Небайтовый шрифт конечно будет предельно тормозным, но для компенсации этого достаточно применить процессор Z80 тактируемый клоком в 8 МГЦ.

53 символа в строке это вполне нормально для двухпанельного Нортона с двумя колонками в каждой панели. Причём даже нормально и для РК-ДОС, т.к там формат имени файлов более длинный - 10 символов имя и 3 символа расширение.

Ещё одним доводом за вариант шрифта с широким знакоместом является необходимость каким-то образом делать маркировку отмеченных в панелях файлов в монохроме. Инверсия знакомест уже занята на балку подсветки в панелях. При большой матрице можно попробовать сделать маркировку редкой мозаикой точек, т.е снег из точек в фоне символа. Если будет плохо, то придётся ограничиться галочкой показывающей маркированность, как было сделано в моих Нортонах для РК86 или менять шрифт у маркированных файлов на жирный или же использовать подчёркивание.

А второй вариант это, естественно, доработать CP/M до дат файлов и сделать раму один к одному как в NC для IBM PC. Трудозатрат на это даже меньше, чем написать полноценный экранный драйвер.

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

В минимальную систему программного обеспечания новой машины как минимум должны входить DOS, Нортон для этой DOS, текстов редактор и ассемблер.

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

WordStar и подобные импортные развитые текстовые редакторы (называемые текстовыми процессорами) - все в основном семибитовые, а WordMaster хоть и маленький, простой и 8-ми битовый, но его команды мне не удобны. Так что возможно, как изучу PL/M и напишу на нём Нортон , перетранслирую для ИРИШИ свой примитивный редактор.

Он примитивный, аналог турбо-паскалевского редактора, написан ещё в кодах КР580 для карты 2 и магнитофонный, не для дисковода (переделать под CP/M несложно, надо заменить МГ-процедуры на дискетные LOAD/SAVE). Хотя в примитивном редакторе размер редактируемого файла ограничен размером TPA за вычетом размера кода самого редактора, но т.к сам редактор имеет объём всего 5 кб, то при TPA в 58 кб можно редактировать текст размером более 50 кб, чего с избытком достаточно.

Маленький размер позволяет сделать резидентный инструментарий для бездисководных систем (тех, где нет ни винта ни флопа, а только эл.диск из ОЗУ). Тогда в ПЗУ храним CP/M (чтобы грузилась по сбросу) и примитивные дисковые текстов редактор и макроассемблер (отдельными программами).

Примитивный текстов редактор означает, что он редактирует только текст в ОЗУ. А примитивный ассемблер означает, что он транслирует только исходник, что уместился в ОЗУ, причём не линкует, а сразу даёт объектный код.

Заметим, что все отечественные самодельные текстовые редакторы для КР580 (кроме SED-а) и все ассемблеры (кроме ассемблера А.Вакуленко с линковкой) - примитивные. Потому любителям программирования и было так трудно писать программы с размером более, чем в 2 кб. Потому программы отечественных бытовых машин заметно слабее, чем иностранных. Т.к иностранные любители программирования имели DOS и у них были редакторы, могущие редактировать текст любого объёма и ассемблеры могущие транслировать исходник любого размера.

Это потому, что в написанных профессионалами CP/M редакторах и ассемблерах используется дисковый свопинг. Текстов редактор или ассемблер располагает в ОЗУ не весь текст (размер которого больше, чем TPA), а только кусок, окно, с которым именно в данный момент производится работа. А весь остальной текст скидывается в swap-файл (иногда называемый spill-файл или дисковым буфером) и куски из него подгружаются в ОЗУ по мере перемещения курсора по тексту. Именно потому текстов редактор WordMaster имеет размер в 12 кб, а текстов редактор МИКРОН имеет размер всего в 2 кб.

Только полные новички в программировании пишут программы на ассемблере, Си или Паскале в виде одного файла, т.к эти ЯВУ поддерживают модульность, а все дисковые ассемблеры тоже имеют оператор INCLUDE. Потому и достаточно самодельного текстового редактора, что может редактировать файл размером хотя бы в 40 кб.