Эмулятор ИРИШИ для тех, кто не имеет её реальной

Сейчас для ИРИШИ есть всего один эмулятор EMU от b2m. По эмуляции CPU и экрана это точный эмулятор, а вот клавиатуру он эмулирует хреново. И к сожалению, все конфиги ИРИШИ, которые были включены в дистрибутив, видимо, соответствуют каким-то заумным промышленным изделиям. Содержат какие-то мифические устройства и архитектура совершенно не соответствуют железу из журнала МПСС.

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

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

Не считая ценности от воссоздания в эмуляторе реального исторического железа, для обычного владельца двухплатной журнальной ИРИШИ в такой работе нет пользы. Программ или дискет для такой системы нет и не предвидится. Программы CP/M работают в любой системе. Потому, если уж требуется иметь и использовать на ИРИШЕ CP/M с дисководом, то гораздо проще применить на ИРИШЕ один из намного более простых вариантов установки дисковода (например, от РК86, ПАРТНЁРА, КОРВЕТА, ОРИОНА, ВЕКТОРА, ZX-Spectrum и др. на базе отечественного ВГ93 или без него).

В данных конфигах включён килограмм доп.ОЗУ непонятно каким способом, вместо стандартного предусмотренного стандартной прошивкой расширения на дополнительные 64 кб (банкой 1, в добавок к уже имеющейся банке 2, стоящей на плате граф.адаптера). В промышленной ИРИШЕ получается два диспетчера ОЗУ, один родной на 128К, который признали неудачным и дополнили более грамотным вторым, который управляет дополнительными 512К.

Для удобного тестирования разрабатываемых программ нужен эмулятор эмулирующий, во-первых, обычную базовую ИРИШУ с 64 кб, а во-вторых, как минимум, нужен эмулятор ИРИШИ, в которую стандартно добавлено ещё 64 кб дополнительного ОЗУ, что и предусмотрено стандартной прошивкой управления памятью.

Эти дополнительные 64 кб включаются в качестве банки 1, которая при стандартной прошивке выбирается в сегментах 4000...7FFF и C000...FFFF в картах 1 и 3. Такое расширение ОЗУ позволяет поиметь CP/M с высоким TPA с электронным диском в 64 кб из излишнего ОЗУ. Т.к эл.диск в такой CP/M выбирается как привод A, то можно пользоваться CP/M не имея дисковода или винчестера.

Понятно, что при использовании CP/M с крошечным эл.диском в 64 кб можно использовать только те CP/M пакеты, общий объём программ и данных которых не превышает этого объёма. Не считая интерпретатор бейсика от Microsoft (24 кб), из компиляторов это только компилятор PL/M и компиляторы ассемблера (причём, чем больше объём компилятора, тем меньше дискового пространства остаётся для текста программы). К сожалению, для использования компиляторов Паскаля или Си надо иметь привод с объёмом от 200 кб (это можно получить за счёт расширения ОЗУ до 256 кб или использования КНГМД, винчестера или флэш-карты). Даже скромный компилятор бейсика требует привод содержащий минимум 150 кб.

Т.о расширение ОЗУ до 128 кб, плюс наличие стандартного иришиного ROM-диска в 64 кб (или хотя бы наличие доп.ПЗУ +32 кб в локальной шине), - это условия для минимально приемлемого удобства пользования ИРИШЕЙ. При этом в иришин ROM-диск (или в дополнительное ПЗУ в локальной шине за счёт замены 2764 на 27256) прошивается CP/M и Нортон (для управления файлами и их загрузки с МГ или линии). Тогда по сбросу ИРИША сразу грузит CP/M и выходит в Нортон. Это похоже на работу ОРИОНА по сбросу, только DOS - нормальная, а приводы - наоборот (т.е ROM-диск - это диск B:, а диск A: - это RAM-привод).

Известно, что в конфигах EMU разобраться сложно. Опытным путём, используя как прототип конфиг ДИАЛОГА, я создал конфиг базовой ИРИШИ. Это обычная журнальная ИРИША к которой добавлена плата расширения ОЗУ на 64 кб (доп.ОЗУ включается там, где в базовой карте пусто).

Плата доп.ОЗУ 64 кб в реале это крошечная платка с панелькой для статики w24512 на 64 кб, включаемая в системную магистраль. Как добавить в эмулятор ПЗУ я пока не знаю (требуется добавить порт который содержит номер страницы ПЗУ в 16К, что читается на обычном месте ПЗУ в карте 0).

UPD: Надписи на клавишах PC-клавиатуры с этим конфигом соответствуют при зажжённом светодиоде CAPS LOCK на PC-клавиатуре.

конфиг обычной ИРИШИ:

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

Сейчас я уже примерно знаю, как добавлю в эмулятор вторую страницу ПЗУ и дополнительное ОЗУ в 128 кб. Для этого я истрачу биты PC1, PC0, которые в базовой ИРИШЕ не использованы, точнее под именем SO1, SO2 они выведены на локальный разъём. По видимому предполагалось, что этими сигналами можно управлять каким либо расширением на плате установленной в локальную шину, например, программно переключаться на другой процессор (например, на 8088 или 68008), программно переключать клок процессора, переключать две страницы ПЗУ по 16К, включать другую страницу ROM-диска по 64К или что-то подобное.

Т.о в эмуляторе (и реале) управлять картой памяти можно не только битами PC3,PC2, но и задействовать на это "безхозные" пока биты PC1 и PC2. Чтобы их использовать по тому же алгоритму, что применён в самом диспетчере памяти ИРИШИ, в реале потребовалось бы заменить прошивку карты памяти 155РЕ3 на 556 РТ5. Естественно, в реале это сделать невозможно (т.к вряд-ли кто захочет уродовать свою аккуратную плату).

Потому я как раз недавно удачно догадался как эту проблему обойти, причём без изменений на базовых платах ИРИШИ, но самое ценное, что такой вариант удачен тем, что реализУем и в скрипто-настраиваемом эмуляторе EMU.

Суть в том, чтобы битами PC1,PC0 переключать банку в единственной дополнительной странице памяти N1, которую поддерживает иришин диспетчер (при стандартной журнальной прошивке). Тогда ИРИША думает, что обращается лишь к дополнительным 64-м килобайтам через 4 окна по 16К в картах памяти 1 и 3, но в зависимости от битов PC1,PC0 попадает в одну из 4-х дополнительных банок.

Таким образом не меняя архитектуры и не вводя дополнительных портов, мы получаем при сохранении совместимости объём ОЗУ в 64 кб + 256 кб. Старым программам, буде случится так, что они обнаружатся, это не мешает, т.к все предыдущие программы при коммутации карт памяти аккуратно сохраняют неизменными все биты порта С (естественно, кроме битов PC3,PC2, которыми управляют картой).

Пока я не решил как именно наилучшим образом использовать эти два бита PC1,PC0. Т.к карту памяти можно менять только ими. Можно бит PC1 истратить на введение дополнительных 128 кб ОЗУ (всего 64+128= 192 кб), а бит PC0 истратить на введение второй страницы ПЗУ, что расширяет ПЗУ с 16 до 32 кб. Или можно оба бита истратить только на расширение ОЗУ, что даст 256+64= 320 кб памяти в ИРИШЕ.

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

В эмуляторе EMU для расширения числа карт памяти достаточно написать так:

PPA : K580ww55 {
 portB[0-6]=mmregB
 portB[7]=kbd.pressed
 portC[1-3]=mm.page         // в оригинале было 2-3
 portC[7]=mmregB.offset     // выбор функции порта B
}

Что даёт вместо четырёх восемь карт памяти. Причем бит PC1 управляет только тем ОЗУ что включается в окнах, где читается банка 1 (т.е доп.банка ОЗУ). На другие окна этот бит не влияет.

mm : MemMap {
 map[0][0000-3FFF]=bios[0000]
 map[0][4000-FFFF]=mem2[4000]
 map[1][0000-3FFF]=bios[4000]
 map[1][4000-FFFF]=mem2[4000]
 map[2][0000-3FFF]=mem2[0000]
 map[2][4000-7FFF]=mem1[0000]
 map[2][8000-BFFF]=mem2[8000]
 map[2][C000-FFFF]=mem1[4000]
 map[3][0000-3FFF]=mem2[0000]
 map[3][4000-7FFF]=mem3[0000]
 map[3][8000-BFFF]=mem2[8000]
 map[3][C000-FFFF]=mem3[4000]
 map[4][0000-FFFF]=mem2[0000]
 map[5][0000-FFFF]=mem2[0000]
 map[6][0000-3FFF]=mem2[0000]
 map[6][4000-7FFF]=mem1[8000]
 map[6][8000-BFFF]=mem2[8000]
 map[6][C000-FFFF]=mem1[C000]
 map[7][0000-3FFF]=mem2[0000]
 map[7][4000-7FFF]=mem3[8000]
 map[7][8000-BFFF]=mem2[8000]
 map[7][C000-FFFF]=mem3[C000]
}

Остаётся "нарисовать" ещё одну банку дополнительного ОЗУ, чтобы всего доп.банок стало две (а всего 64+128= 192 кб). Аналогично первой дополнительной банке mem1 добавляем ещё одну банку mem3. На самом деле правильно это назвать mem1', мэм-один-штрих, т.к она читается также как и mem1 в качестве банки 1 (т.е абсолютный адрес 10000), но я не уверен, что эмулятор воспримет апостроф, да и с цифрой меньше шансов ошибиться. Тогда вся секция памяти содержит описание трёх банок памяти, примерно вот так:

// базовая память на плате граф.адаптера (абс.адрес 20000)
mem2 : Memory {
 size=10000
}

// память на плате расширения ОЗУ 128К (абс.адрес 10000)
mem1 : Memory {
 size=10000
}

// память на плате расширения ОЗУ 128К (абс.адрес тоже 10000)
mem3 : Memory {
 size=10000
}

Теперь Вы поимели в эмуляторе EMU 192 кб ОЗУ. Из которых 64 кб стоит на плате граф.адаптера, а ещё две банки РУ5-тых с узлом регенерации (или просто две w24512) стоят на дополнительной плате расширения ОЗУ. Обе дополнительные банки памяти имеют одну и ту же адресацию, обе поочерёдно включаются как банка 1, и то какая из этих банок является текущей, т.е доступной в данный момент определяет бит PC1. По сбросу при инициализации ППА PC1=0. Затем если понадобится доступ во вторую дополнительную банку, достаточно программно установить бит PC1=1.

Минусом такой вариант расширения ОЗУ имеет то, что занимаются все 4 пустые окна в картах памяти, что означает, что в слот уже нельзя подключить периферийную плату, которая хочет включить в шину (например на C000 в карте 3) своё ОЗУ, например, плата текстового адаптера должна занимать в памяти не менее 2 кб (это в монохроме, а с цветовыми атрибутами - аж 4 кб). Также вариант скоростного винчестера нуждается в буфере в 512 байт, заполняемого на огромной скорости ПДП.

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

Как уже выше упоминал, с расширением в эмуляторе ОЗУ до 192 кб проблем не было, вставил в него вышеприведённые секции конфига и соответственно модифицировал CP/M, потратив не более 5 минут времени на всё. И сходу без отладки всё заработало (что бывает обычно редко).

Естественно, уже решил, что и с 320 кб проблем не будет и "раскатал губищи". А недавно отредактировал конфиг на 64+256= 320 кб, и странслировал соответствующую CP/M, но сразу же резко обломился, - зависает. Не то конфиг неверный, не то в программе ошибся. Через несколько дней попробовал снова, провёл пару часов в отладчике, но всё-равно безрезультатно. Ну что же, как говорил Семён Семёнович Горбунков (голосом Юрия Никулина) в одном советском к/ф 1968 года (c) "Будем искать...".

Вот такие были изменения в секциях памяти в конфиге на 320 кб при 4-х битах коммутирующих память портом C:

// базовая память на плате граф.адаптера (абс.адрес 20000)
mem20 : Memory {
  size=10000
}

// память на плате расширения ОЗУ 256К (коммутируется на адрес 10000)
mem10 : Memory {
  size=10000
}

// память на плате расширения ОЗУ 256К (коммутируется на адрес 10000)
mem11 : Memory {
  size=10000
}

// память на плате расширения ОЗУ 256К (коммутируется на адрес 10000)
mem12 : Memory {
  size=10000
}
// память на плате расширения ОЗУ 256К (коммутируется на адрес 10000)
mem13 : Memory {
  size=10000
}

PPA : K580ww55 {
  portB[0-6]=mmregB
  portB[7]=kbd.pressed
  portC[0-3]=mm.page // 4 бита для управления памятью
  portC[7]=mmregB.offset // выбор функции порта B
}

mm : MemMap {
  map[0][0000-3FFF]=bios[0000]
  map[0][4000-FFFF]=mem20[4000]
  map[1][0000-3FFF]=bios[0000]
  map[1][4000-FFFF]=mem20[4000]
  map[2][0000-3FFF]=bios[0000]
  map[2][4000-FFFF]=mem20[4000]
  map[3][0000-3FFF]=bios[0000]
  map[3][4000-FFFF]=mem20[4000]
 
  map[4][0000-3FFF]=mem20[0000]
  map[4][4000-7FFF]=mem10[0000]
  map[4][8000-BFFF]=mem20[8000]
  map[4][C000-FFFF]=mem10[4000]
 
  map[5][0000-3FFF]=mem20[0000]
  map[5][4000-7FFF]=mem11[0000]
  map[5][8000-BFFF]=mem20[8000]
  map[5][C000-FFFF]=mem11[4000]
 
  map[6][0000-3FFF]=mem20[0000]
  map[6][4000-7FFF]=mem12[0000]
  map[6][8000-BFFF]=mem20[8000]
  map[6][C000-FFFF]=mem12[4000]
 
  map[7][0000-3FFF]=mem20[0000]
  map[7][4000-7FFF]=mem13[0000]
  map[7][8000-BFFF]=mem20[8000]
  map[7][C000-FFFF]=mem13[4000]
 
  map[8][0000-FFFF]=mem20[0000]
  map[9][0000-FFFF]=mem20[0000]
  map[A][0000-FFFF]=mem20[0000]
  map[0xB][0000-FFFF]=mem20[0000]
 
  map[C][0000-3FFF]=mem20[0000]
  map[C][4000-7FFF]=mem10[8000]
  map[C][8000-BFFF]=mem20[8000]
  map[C][C000-FFFF]=mem10[C000]
 
  map[D][0000-3FFF]=mem20[0000]
  map[D][4000-7FFF]=mem11[8000]
  map[D][8000-BFFF]=mem20[8000]
  map[D][C000-FFFF]=mem11[C000]
 
  map[E][0000-3FFF]=mem20[0000]
  map[E][4000-7FFF]=mem12[8000]
  map[E][8000-BFFF]=mem20[8000]
  map[E][C000-FFFF]=mem12[C000]
 
  map[F][0000-3FFF]=mem20[0000]
  map[F][4000-7FFF]=mem13[8000]
  map[F][8000-BFFF]=mem20[8000]
  map[F][C000-FFFF]=mem13[C000]
}

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

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

Клавиатура при эмуляции ИРИШИ была сделана безответственно. Хотя вообще нет никаких проблем, чтобы все надписи на PC-клавиатуре совпадали, но было сделано западло всем пользователям ИРИШИ, а на просьбы исправить - ноль реакции. Целых 10 клавиш вообще не эмулируются, а незадействованные клавиши выдают случайные коды. Драйвер, похоже, был просто взят от другой машины с минимальной доработкой. Потому надписи спец.клавиш совершенно не совпадали, совпадали только буквенные клавиши, да и то только в латинском регистре.

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

Т.к мне приходится сейчас много пользоваться эмулятором ИРИШИ, теперь я решил экспериментальным путём добиться лучшего соответствия клавиш. К сожалению, уж не знаю как это для других компов в эмуляторе, но в эмуляции клавиатуры ИРИШИ сделана фатальная ошибка, - смена регистра работает неправильно. Включение CAPS должно менять только регистр букв и не влиять на цифры и клавиши со спец.символами. А в эмуляторе ИРИШИ влияет. Т.е включив другой регистр цифры исчезают, все спец.символы меняют раскладку. Т.е в верхнем регистре одна раскладка, а в нижнем другая.

Потому ранее приходилось всё вводить при включённом верхнем регистре, т.е всё вводить только большими буквами (как будто на машине использована КОИ-7, хотя реально КОИ-8 ). Оператор vk.xlat очень удобен, он позволяет задать коды выдаваемые клавишей в верхнем и нижнем регистре (кстати в этой секции kbd комментарий допустим только в первой позиции строки, если вставить комментарий в конце строки, то EMU просто не стартует, а аврально выходит в DOS). Проблемка лишь в том, как кодируется сама клавиша. Но экспериментальным путем мне это удалось определить. И я расставил коды так, чтобы все надписи на моей IBM-клавиатуре совпадали.

Понятно, что из-за ошибки коммутации регистра небуквенных клавиш, соответствия можно добиться только или в верхнем регистре, или в нижнем регистре. Я сделал соответствие в нижнем регистре, т.е когда коды вырабатываемые клавишами без SHIFT соответствуют маленьким (прописным, т.е не заглавным) буквам. Это удобнее для разработки на ЯВУ или написании писем бабушке, а вот для ассемблера полезнее большие буквы, но тут уж облом. Чтобы всё работало и надписи на PC-клавиатуре совпадали надо включать на клавиатуре режим CAPS, т.е расположенный на клавиатуре светодиод CAPS LOCK должен гореть. (UPD: Позднее, т.к собираюсь писать программы в эмуляторе ИРИШИ на ассемблере, то сделал также вариант совместимости надписей и для верхнего регистра.)

Замечу ещё, что клавиатура ИРИШИ в эмуляторе сделана еще более безответственно, чем кажется. Дело в том, что в иришиной клавиатуре вообще нет клавиши SHIFT. Это потому, что ИРИША рассчитана специально для одноруких инвалидов. Из-за этого на её клавиатуре есть только клавиши-фиксаторы <ВР> и <НР>. Эти клавиши делают тоже самое, что на PC-клавиатуре делает одна клавиша Caps Lock. Они переключают триггер регистра клавиатуры. Хотя их удобнее было бы задействовать, как часто делают в русификаторах, где левый и правый шифты выбирают язык.

Потому если работать аналогично реалу, то нельзя использовать отсутствующую в реале клавишу SHIFT, а можно использовать только клавишу CAPS LOCK, что как уже упомянуто, вообще перекорёживает клавиатуру. Потому, если бы SHIFT не работал, то и эмулятору ИРИШИ был бы конец.

Если вы ранее (т.е до сегодня 28.04.19) скачивали какие-либо мои конфиги, то сейчас вы можете их заменить на вот эти два конфига https://yadi.sk/d/APjkBMezo5mq9Q, что я использую для прогона программ ИРИШИ в эмуляторе (с КР580 и Z80). В них есть единственное отличие от предыдущих конфигов только в модуле Keyboard (добавлены строки vk.xlat задающие коды клавиш).

В этих конфигах, чтобы не возникало конфликтов с конфигами из дистрибутивного пакета, указано другое имя для файлов ПЗУ, но если хотите, то можете ПЗУ использовать старое (т.е или журнальное или из красной книги, что было в дистрибутиве эмулятора, оно имело имя irisha.rom). Естественно, тогда надо указать это в этих новых конфигах вот так:

rom="Irisha\irisha.rom".

Или два приложенных в архиве файла ПЗУ надо скопировать в каталог IRISHA. Это те же ПЗУ, что я использовал ранее для CP/M. Естественно, конфиги надо поместить в каталог ..\EMU\CONFIG. После того, как сделаю ПО, использующее 192/320 кб ОЗУ, выложу соответствующий конфиг.

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

К сожалению до сих пор не знаю какие коды выдают 5 функциональных клавиш на клавиатуре ИРИШИ. И надеюсь, этих кодов не 5, а 10. Что так, если ума у её изобреталей хватило сделать, как это сделано в других компьютерах имеющих функциональные клавиши. Тогда по нажатию функциональной клавиши без шифта (в случае ИРИШИ без <Control>, т.к <Shift> на клавиатуре ИРИШИ отсутствует) выдаётся один код, а по нажатию той же клавиши с шифтом (или с <Control>) выдаётся другой код. Эта даёт как-бы 10 функциональных клавиш из всего 5-ти физических.

Которые в программах могут использоваться для вызова функций программы, а также на уровне DOS для ввода ключевых слов. Ввод ключевых слов в приличных компьютерах программируется пользователем отдельной программой (так было, например, в Роботроне-1715).

Узнать какие коды выдают функциональные клавиши в ИРИШЕ можно спросить у того, кто спаял и настроил контроллер клавиатуры ИРИШИ. Таких людей огромное количество, но увы, они не посещают этот малоизвестный форум. Другой способ узнать это, - это с помощью огромного напряжения своего мозга вычислить эти коды по дампу прошивки ПЗУ клавиатуры.

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

Тогда я, возможно, смогу их встроить в эмулятор или, по крайнеё мере, использовать в программах рассчитанных на реал, а также лично для себя изменить прошивку 2732 на своей клавиатуре, которую я использую с ИРИШЕЙ (тем эппловская IIe клавиатура и удобнее, т.к, например, в клавиатуре КОНСУЛ коды не изменить, там жёсткая логика на 155-той серии).

В эмуляторе EMU вообще, похоже, функциональные клавиши не поддерживаются или как-то неправильно. У меня по нажатию функциональных клавиш в эмуляторе EMU выводятся буквы.

Возможно узнать какие коды дают функциональные клавиши ИРИШИ можно изучив документацию на промышленный аналог иришиной клавиатуры 15ВВВ-97-006. Если кто знает, пусть сообщит, хотя это и не означает, что коды функц.клавиш иришиной клавиатуры те же.

Таким образом по причине отсутствия в эмуляторе EMU поддержки функциональных клавиш, я не могу сделать в CP/M даже ввод ключевых слов. Это есть во всех моих CP/M, это очень просто - на выходе CONIN отлавливаются коды <$20, проверяется, есть ли данный код в таблице и, если есть, то в буфер клавиатуры кидается строка из таблицы.

Это свойство очень полезно при многократной линковке многомодульных программ, задаём ком.строку 1 раз, а затем вызываем, когда надо, избавляясь от необходимости всякий раз набирать длинную командную строку и это удобнее, чем использование SUBMIT. Примерно то же самое даёт и драйвер SL для ACP/M.

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

Вообще, я бы назначил функциональным клавишам коды так же как это было сделано в раннем СПЕЦИАЛИСТЕ (это лишь 2 года спустя после его опубликования, для якобы получаемой так совместимости с РК, эти коды поменяли на эр-кашные, хотя это явно глупо, т.к коды 00...04 вводятся и с <Control> а общее число кодов не увеличивается). Я бы сделал, чтобы коды от клавиш <F1>...<F5> нажатые без <Control> были 81...85, а с <Control> соответственно 86...90.

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

Сделать CP/M работающую на эл.диск в 256 кб по-прежнему не удаётся. Пока крошечного эл.диска на 128 кб хватает, с ним по-крайней мере, уже можно жить и бороться. За прошедшее время пытался трассировать несколько часов отладчиком, но энтузиазм на отладку пока закончился. Зато сделал два варианта на 128 кб. Попозже всё-же сделаю 256К, препятствий не вижу, за исключением нехватки ума у программиста (точнее его старческого слабоумия).

Зато изучив эмуляторные конфиги от других машин, теперь научился иметь в эмуляторе EMU хоть килограмм ROM-дисков, причём нормальных, т.е эр-кашно-орионовских, а не неудобных автоинкрементных иришиных. Такой ROM-диск позволяет любой произвольный (причём быстрый) доступ к лог.секторам на ROM-диске. Что позволяет на ROM-диске хранить не просто набор файлов (впритык один к другому), а повторить формат CP/M-диска, т.е иметь полноценный R/O CP/M-диск с файлами, который читается напрямую стандартными средствами CP/M.

Конечно удобнее было бы поиметь один огромный ROM-диск на 512 кб, разместив в этом приводе B: все часто нужные программы. Но как это сделать в эмуляторе никто не знает. Но и килограмм маленьких по 64 кб ROM-дисков пока устраивает.

Чтобы поиметь в эмуляторе ROM-диск по схеме ОРИОНА надо добавить в конфиг вот такой фрагмент.

CPU : Z80 {
 debug=cas
 mem=mm
 port[04-05]=kbd.keycode
 port[06-07]=comport.data      
 port[08-0B]=TIMER.data        
 port[0C-0F]=intctl.data      
 port[10-13]=PPA.data          
 port[14]=extrom.stream        
 port[40-4F]=app.data      // строка добавленная в эту секцию
 port[D8]=vid.mode            
 port[D9]=vid.color            
 port[DA]=vid.page            
 int=intctl.int
}

app : K580ww55 {
 portA=romdisk.data
 portB=romdisk.lsb
 portC=romdisk.msb
}

Постепенно выкристаллизовывается состав узлов мультикарты для ИРИШИ (для случая промышленного изготовления печ.платы, не для ручного монтажа проводками). ROM-диск по прогрессивной схеме как раз кстати, особенно, если напрячь мозг и сообразить как одним ППА обслуживать и ROM-диск и контроллер винта. Кроме контроллера винта и, возможно, ROM-диска на двух 27256, на плате д.быть 128 кб доп.ОЗУ на четырех w24257 (состав микросхем определяется их наличием  у меня, хотя теоретически выгоднее применить одну 27512 и две w24512). ROM-диск был актуален в 80-тые, т.к это полумера в случае когда нет настоящей массовой памяти в виде дисковода или винчестера.

Это в общем-то немного деталек для сравнительно большой платы конструктива ИРИШИ. Потому подумываю о включении в такую плату РК-КНГМД (это ещё ~15 корпусов, включая ППА). Но т.к это паять придётся мне вручную проводками, экономнее ставить что-то одно - или КНГМД или контроллер винта. Т.к винт у меня тормозной, а два ненужных дисковода 3.5" и ~70 дискет 3.5" пропадают без пользы, то пока склоняюсь к КНГМД, хотя он содержит намного больше корпусов. С дискетами в ретро-машине иметь дело как-то приятнее. Но конечно дико страшит необходимость вручную спаять проводками ~30 корпусов, для ручной самосборки придётся делать что-то намного более простое (например, лишь простенький адаптер винта).

Попутно, для тестирования ROM-диска странслировал для ИРИШИ М3-EXT ОРИОНА (только для ROM-диска, не для RAM-диска). Теоретически нет препятствий странслировать для ИРИШИ и бессмысленную систему ORDOS от ОРИОНА, но незачем, т.к всё, что она даёт умещается в 200 байт кода (с затратой в эти 200 байт мои текстовы редакторы, а также нортоны для CP/M ОРИОНА в банке 0 поддерживают квази диски ORDOS, причём без необходимости снижать TPA на целых 2 кб).

Если на плате мультикарты есть ППА, то появляется ещё один вариант электронного диска. Речь о том, чтобы организовывать его не из ОЗУ самого компьютера, а в виде RAM-диска аналогичного ROM-диску, такое называют ROM-диск с записью. Это когда в ROM-диск вместо 27256 ставят 62256 и содержимое ROM-диска можно быстро и оперативно программно менять.

Это уже только для реала, т.к эмулятор EMU не поддерживает ROM-диски с записью. Такой трюк полностью сохраняет исходную концепцию памяти ИРИШИ, эл.диск - внешний, не вторгающийся в архитектуру и не дополняющий её дополнительными диспетчерами памяти. Тогда достаточно в карту 1 включить 32 кб скоростного ОЗУ (это расход в одну панельку на 28 ног). Скоростное ОЗУ необходимо для задач реального времени, например, если надо делать обмен с МГ в формате РК86 или ZX-Spectrum.

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

Ну вот, наконец "порешал проблему" и теперь поимел для эмулятора версию CP/M с диском в 256 кб. Причём поднял уровень TPA до максимума в 48-ми килобайтном ОЗУ. Без обработки РУСЛАТ уровень TPA равен $AE00, т.е 43.5 кб, что намного больше, чем в родной CP/M ИРИШИ. Проблема, естественно, оказалась не в моём неграмотном программировании, а в особенностях обработки конфига эмулятора.

Попробовал сразу же сделать версию и для эл.диска в 512 кб (это при общем ОЗУ в 576 кб), но опять обломился, теперь не виснет, но наблюдается дохлота диска, скорее всего снова что-то не так эмулируется.

Впрочем, это уже не важно, т.к 512 кб - это реализуемо уже только для эмулятора, в реале это не повторить. Т.к для 512К на коммутацию банок берётся и бит D4 в порту C ППА. А в реальной ИРИШЕ он уже занят на запрет системной магистрали, чтобы плата ЦП могла отключиться от магистрали и работать независимо от системной шины.

Хотя это свойство для базовой журнальной ИРИШИ бесполезно, т.к на плате ЦП нет ОЗУ. Лишь включив в локальную магистраль дополнительное ОЗУ, от этого "отключения от системной магистрали" была бы хоть какая-то польза. Вставить доп.ОЗУ в локальную магистраль не проблема, т.к ИРИША специально для этого имеет разъёмы локальной магистрали, чтобы можно было добавить ещё что-то полезное на плату ЦП.

Если судить по текстам авторов, они хотели отключаться от магистрали, чтобы процессор КР580, отдав шину какой-то второй активной плате в крейте, например плате альтернативного процессора или ПДП (например, когда ПДП, но уже не в CP/M, а в МИКРОДОС, где есть многосекторный обмен, долго качает огромный файл в ОЗУ ИРИШИ из винчестера), мог в это время что-то делать. А что может процессор в это время делать? Он может делать лишь следующее: обслуживать джойстик, клавиатуру, играть музыку, читать байты из ROM-диска, из проводной линии или магнитофона, а также программно отмерять временнЫе интервалы (т.е освобождать магистраль лишь на нужное время).

Естественно, авторы не ради такой гипотетической возможности ввели локальную и системную магистрали. Они лишь буферизовали КР580 на самой плате (в соответствии с РТМ на процессор) и буферизовали внешнюю системную шину, что также необходимо. А затем заметили, что если системные буфера закрыть, то получится закрытое от остальных плат внутреннее МП-ядро и потому добавили возможность программно отключать магистраль. В программах эта возможность, естественно, не используется и в эмуляторе EMU не эмулирована (т.е бит PC4 свободен).

Но в реале бит PC4 занят и мне из-за этого придётся ограничиться размером ОЗУ в жалкие 320 кб (это базовые 64К + 256К на плате расширения ОЗУ). Как для больших программ, так и для небольшого эл.диска этого должно хватить, т.к вряд-ли кто напишет программу большего размера и многим компиляторам хватает диска в 256К. При таком диске теоретически можно написать программу на ЯВУ с использованием оверлеев с суммарным размером модулей до 256К. Впрочем, за 40 лет существования CP/M такой большой программы ещё никто не написал.

Впрочем, для реала даже жалкие 256 кб доп.памяти очень трудоёмко спаять проводками. Ведь, если делать 256 кб на 565РУ7, то это потребует ручного монтажа более 20 корпусов (это 8 шт. самих ОЗУ и схема их регенерации, которую ещё надо разработать). А если хочется 256К получить на 4-х банках 565РУ5, то выгоднее сразу повеситься. А если делать на статике, то 256 кб набранные корпусами по 32 кб, потребуют ручного монтажа 8-ми штук w24257 при общем числе корпусов ~12...13, что тоже достаточно трудоёмко.

Немного меньше проводков получается при Z80 и применении SIMM на 256 кб. Тогда, чтобы получить ещё 2 недостающие бита адреса регенерации, придётся добавить счётчик 561 ИЕ10. Схема выливается в три КП11, 561 ИЕ10, АП6 и ещё ~4 корпуса логики, что можно сократить за счёт применения 556РТ4. Такая схема попроще, но работает только при Z80.




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

Эмуляция клавиатуры в эмуляторе EMU сделана неверно и неполностью. Сделано как не для людей, по остаточному принципу, что-то с клавиатуры выдаётся и плевать на пользователей. Из 69 клавиш вообще не проэмулировано целых 10 клавиш ! Нет клавиш <ПС>, <ВР>, <НР>, <РУС>, <ЛАТ>, <F1>, <F2>, <F3>, <F4>, <F5>. Причём клавиши <F1>, <F2>, <F3>, <F4>, <F5> нажатые с шифтом дают ещё 5 кодов.

И это при том, что, т.к PC клавиатура тоже аппаратная, то вообще не было никаких проблем получить полную совместимость. В отличие от клавиатуры РК86 или ОРИОНА, флаг РУСЛАТ в клавиатуре ИРИШИ внутренний (т.е внутри клавиатуры), а не внешний программный в ячейке ОЗУ. Достаточно было таблично перекодировать скэн-код по нажатию в код КОИ-8 иришиной клавиатуры.

А ещё очень мешает то, что незадействованные клавиши всё-равно выдают коды, причём случайные, не связанные ни со скэн-кодами, ни с их назначением.

Если с отстутствием <ПС>, <ВР>, <НР> ещё как-то можно смириться, то вот отсутствие эмуляции <РУС>, <ЛАТ> создаёт неразрешимые проблемы. Без <ПС> в принципе можно прожить (хотя в связи с нехваткой клавиш и её бы в программах было удобно задействовать).  <ВР>, <НР> не выдают кода, а лишь переключают регистр у буквенных (только у буквенных !) клавиш.

Эти клавиши переключают внутренний триггер внутри клавиатуры. Если этот триггер 1, а введён код клавиши в интервале $41...$5A, $61...$7A, то делается команда XOR 20H. Даже эмулировать эти клавиши не обязательно, т.к тот же результат получался бы, если бы клавиша Caps Lock работала правильно (т.е не меняла бы кодов у абсолютно всех клавиш, а только делала бы XOR 20H для буквенных, если флаг CAPS=1).

А вот с <РУС>, <ЛАТ> вообще неразрешимая проблема. В эмуляторе этих клавиш нет как класса и даже их функций нет. Эти клавиши тоже не выдают кода на иришиной клавиатуре, но переключают внутренний триггер внутри клавиатуры. И если этот флаг RUSLAT=1 и нажата русская буквенная клавиша (т.е код символа в интервале $41...$5E, $61...$7E), то выдаётся код русской буквы в кодировке КОИ-8 (т.е код в интервале $C0...$FF). Иными словами, если это буква (т.е исходный латинский код в интервале $41...$5E, $61...$7E), то делается XOR 20H, а затем OR 80H. И естественно флаг RUSLAT вообще не влияет на коды небуквенных клавиш.

Т.е клавиатура ИРИШИ - 8-ми разрядная, а не 7-ми разрядная, она в отличие от клавиатуры Агата или Apple-II выдаёт не 7-ми битовый ASCII, а 8-ми битовый КОИ-8. Это видно из схемы. Хотя соответствующей прошивкой клавиатура ИРИШИ может работать и как 7-ми битовая.

Увы, у меня нет оригинальной иришиной клавиатуры, а лишь две 7-ми битовые аппаратные ASCII-клавиатуры (от Apple-IIe и венгерский Консул). Потому, я не знаю как вводить русские буквы в CP/M и вообще во все программы с русскими буквами.

Текстовый редактор ИРИШИ специально сделан так, чтобы им можно было пользоваться с 7-ми битовой промышленной клавиатурой 15ВВВ-97-006. Для чего, в этом редакторе регистр RUSLAT управляется не аппарататно, а эмулируется программно внутри редактора. При этом на родной иришиной клавиатуре для переключения языка приходится пользоваться не клавишами <РУС> и <ЛАТ>, а вручную вводить двухклавишные сочетания ^N и ^O, что выдают коды $0E и $0F, что крайне неудобно одноруким инвалидам.

Это неудобно при родной клавиатуре ИРИШИ, но зато позволяет пользоваться редактором с антикварной семи-битовой клавиатурой 15ВВВ-97-006 от ДВК. С клавиатурой 15ВВВ-97-006 никакого неудобства нет, т.к там сами клавиши <РУС> и <ЛАТ> выдают эти коды, а с родным иришиным контроллером клавиатуры неудобно.

Похоже, что из-за неточного эмулятора вводить русские буквы в КОИ-8 придётся также. Было бы проще, если бы в эмуляторе клавиатура возвращала скэн-код PC и флаг РУСЛАТ, тогда перекодировку можно встроить в ROM-BIOS.

Хотел выкрутиться используя то, что EMU обслуживает клавишу <HOME>, выдающую код ^L. Этой клавиши нет на клавиатуре ИРИШИ, но в эмуляторе она эмулируется (что м.быть полезно). Т.е хотел с помощью оператора конфига vk.xlat поменять выдаваемый этой клавишей код на ^N и этот код использовать как триггерный переключатель РУС/ЛАТ, но почему-то не сработало.

Из-за ограничения на макс.размер поста не получается написать один большой поэтапно дополняемый пост.

Если в реальной ИРИШЕ придерживаться только таких доработок, что можно повторить в эмуляторе EMU за счёт модификации конфига, то уже более менее можно отлаживать программы для разных DOS в эмуляторе. Естественно надо иметь вариант этой DOS, использующий эл.диск из ОЗУ. Вскоре странслирую для ИРИШИ еще несколько DOS (чьи исходники есть), хотя некоторые из них уже лишь для Z80 и конвертировать их нельзя (точнее слишком трудоёмко, т.к там задействованы все регистры Z80).

К сожалению, эмулятор EMU не поддерживает РК-КНГМД, но зато он поддерживает типовой КНГМД на ВГ93 (по крайней мере для Ориона и Корвета). Потому ещё возможно попробую в ближайшие годы разобраться в том, как устроен конфиг для ОРИОНА и если хватит ума, то по образцу введу подобный КНГМД в эмуляцию ИРИШИ. Дорабатывать DOS для дисковода не требуется (т.к, если КНГМД ОРИОНА заимствовать буквально, с совпадением битов в упр.регистрах, то достаточно лишь откомментировать строку INCLUDE FLOP.INC и зарезервировать место для CP/M-буферов доп.приводов).

Кстати, то что EMU не поддерживает РК-КНГМД, а поддерживает КНГМД на ВГ93, это сильный довод в пользу делать для ИРИШИ КНГМД именно от ОРИОНА, а не от РК86, даже с учетом того, что формат при КР580 из-за тормознутости будет SD 360 Кб (а Z80 на 5 МГЦ потянет и формат 1.44 Мб).

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

Кстати, раз EMU эмулирует прерывания через ВН59, то ничто (кроме наличия того, кто бы этим занялся) не мешает сделать прогон на ИРИШЕ по прерываниям тех РК-игр, что не лезут в ВГ75. Хотя даже таких РК-игр - не в оригинале (т.к РК-игры часто лезут в клавиатуру), - нужна небольшая переделка. Но найти место, где есть обращения в клавиатурный порт $8000 (и соответственно откорректировать код), - на порядки проще, чем сначала полноценно дизассемблировать игру, а затем изменить алгоритм игры под ИРИШУ. Для визуализации текстовый экран РК несколько раз в секунду "сливается" в экран ИРИШИ. Я уже пробовал эту идею эмуляции РК-программ на ОРИОНЕ, причём даже без апп.прерываний (а на программной имитации прерываний).

А если дополнить ИРИШУ аппаратной ловушкой на РК-порты (маленькой платкой втыкаемой в локальный разъём на плате ЦП), чтобы возникало одно из 8-ми прерываний ВН59 при обращении РК-игры по адресам $8000, $С000 и $E000, т.е к БИС-ам РК86, то можно сделать полноценную эмуляцию, причём абсолютно всех, РК-программ.

Понятно, что для эмуляции РК-игр на ИРИШЕ нужен запас скорости, как минимум в 1.5...2 раза (чем больше запас скорости, тем больший FPS достижим), а базовая ИРИША, увы, наоборот проигрывает по скорости РК86 на ~20 %. Так что без быстрого Z80 сделать эмуляцию игр в оригинале проблематично. Хотя, если РК-игры немного ковырять, находя в них и уменьшая константы тормозилок, то даже это возможно.

Можно существенно снизить требования к быстродействию ИРИШИ, если РК-экран не визуализировать покадрово, а эмулировать изображение побайтово за счёт отлова записей в экран. Тогда делается аппаратная ловушка на экранную область РК86 (76D0...7FF4). По записи в которую аппаратно возникает прерывание, причём адрес, куда идёт запись фиксируется в регистрах.

Тогда по прерыванию ИРИША из регистров узнаёт куда именно была запись и имитирует запись символа в экранный буфер РК на своём, уже видимом пользователю, экране. Это хоть аппаратно потребует установку на доп.платку нескольких микросхем 155-той серии, зато для такой эмуляции хватит эффективной скорости всего лишь в 1.77 МГЦ, что даёт ИРИША, если в ней установлено ОЗУ не использующее циклы ожидания (т.е любое ОЗУ вне платы граф.адаптера).

Ещё бы кто написал эмулятор ИРИШИ для Андроида.

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

Кроме Low TPA версии CP/M ИРИШИ (с TPA на 43.5 кб, при которой экран доступен напрямую из CP/M), после долгого электротраха отладил наконец High TPA версию CP/M. Она работает в карте 1, отчего VDISK из ОЗУ сокращён до 216 кб (при загрузке из ROM-диска 224К) и даёт TPA более 59 кб. Т.к карта памяти ИРИШИ рассчитана работу программ в карте 2, а не в карте 1, то пришлось программно имитировать некоммутируемое ПЗУ из ОЗУ. Это достигается тем, что в разных картах по одному и тому же адресу записывается один и тот же код. Причём в случае CP/M есть только небольшой участок всего в 128 байтов ($FF80...$FFFF), где можно размещать код псевдо ПЗУ. Т.к ниже $FF80 раб.ячейки и экран, ниже $80 стек и RST, область $100...$DFFF в карте 1 это TPA.

Возможно теперь на ИРИШЕ можно будет использовать самые крутые компиляторы ЯВУ (хотя в CP/M-архивах встречаются компиляторы ЯВУ, что требуют TPA аж в 62 кб, но таких компиляторов очень мало, буквально несколько).

Среди отечественных ЭВМ на Z80/КР580 нет других CP/M-машин со столь высоким TPA (у ОРИОНА TPA всего лишь 51 кб, а у остальных бытовых машин TPA и того меньше). Это лишний раз доказывает, что ИРИША из всех отечественных 8-ми разрядок это самый удачный компьютер. Как единственную альтернативу по уровню TPA можно упомянуть только клон Синклера ПРОФИ, для которого уже в новодельные времена была сделана CP/M-совместимая DOS Профи-DOS, имеющая TPA в 58 кб. Но это уже как бы и не отечественная ЭВМ, т.к ZX-Spectrum не отечественная машина.

Кстати, TPA на всё адресное пространство (точнее 63.75 кб, т.к в вершине ОЗУ всё-равно остаются входы в BDOS и BIOS) на ИРИШЕ тоже можно сделать, т.к ИРИША это единственный отечественный компьютер в котором не только экранный буфер, но и ПЗУ не навсегда "вставлены" в адресное пространство процессора, а программно отключаются. Столь большое TPA пока не нужно и я это делать пока не буду (но может быть потом появится желание лишний раз показать насколько ИРИША крута, - хотя, я сам такого ещё не делал, но не вижу особых препятствий, кроме резкого падения скорости обмена с диском из-за дополнительных копирований).

В принципе для прикладных программ (и для игр тоже) более удобна CP/M в карте 2, т.е когда экранная область $C000...$FF3F находится в адресном пространстве. Т.к тогда можно писать программы работающие по экрану на ЯВУ. Для кого-то также важно, что такая CP/M работает в базовом железе, т.е без расширения ОЗУ (используя в качестве привода дисковод или винт). Эта версия CP/M при старте проверяет наличие 256 кб доп.ОЗУ и если его нет, то привод А: - это дисковод, а привода B: - вообще нет.

На ОРИОНЕ было два варианта CP/M - с низким TPA на 36 кб для пользователей и с высоким TPA на 51 кб для программистов. Программы легче и приятнее писать, когда экран присутствует в адресном пространстве. 43 кб TPA это сравнительно много. Даже для некоторых программ странслированных неэффективными компиляторами ЯВУ этого может хватить.

Для сравнения, аналогичная CP/M на ОРИОНЕ позволяющая цвет (т.е в банке 0) даёт TPA всего лишь в 36 кб, причём развитого цветного экранного драйвера вывода нет (т.е всё должна делать сама CP/M-программа). С учётом того, что более-менее приличный оконный драйвер занимает 8 кб, для кода программы, её дисковых и оконных буферов практически не остаётся места. Т.е ОЗУ в CP/M хватает только на что-то предельно примитивное использующее убогий драйвер вывода из ПЗУ в стиле РК86.

А в аналогичном случае ИРИШИ (т.е с видимым программе экранным буфером), даже несмотря на то, что экран у ИРИШИ намного больше (16 кб против 12), более грамотная архитектура ИРИШИ позволяет иметь для CP/M-программ аж 43.5 кб, причём только для программ (т.к мощный цветной оконный драйвер уже есть в ПЗУ и ещё можно загрузить 32 кб кода для работы с экраном в ОЗУ карты 0, а лучше прошить в расширение ПЗУ).



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

После размышления стало ясно, что в общём-то нет особых препятствий для совместимого с эмулятором расширения ОЗУ до 1 мб.  Ввиду того, что пока никому не надо было отключать системную магистраль от МП-ядра КР580, и похоже, что и в будущем без этого можно обойтись, то не вижу особых препятствий, чтобы использовать и биты PC4 и PC5 для управления памятью. Что позволяет к 64-м килобайтам базовой памяти добавить ещё 1 МБ памяти на дополнительной плате расширения ОЗУ.

Этого для всех нужд 8-ми разрядки хватит. PC4 сейчас занят на отключение буферов системной магистрали, но ничего не случится если отрезать печать от PC4 и заземлить эту цепь. Буфера будут работать по-пионерски (т.е всегда готовы передавать), но никто на других платах на это не обидится. Разряд PC5 сейчас делает выбор "аналоговый джойстик/звуковой генератор на ВИ53". Т.к аналогового джойстика для ИРИШИ ни у кого пока нет (и вряд-ли предвидится), то можно отрезав цепь от PC5 подать туда 0, что обеспечит постоянное управление таймером с выхода триггера D35.2.

Теоретически, раз измерять временные интервалы от резистивно-аналогового преобразователя на 1006ВИ1 не надо (и ставить его самого не надо), то строго говоря и громоздкая логика работы триггера D35.2 не нужна. Хотя и без 1006ВИ1 этот триггер полезен, - им затыкают ВИ53 по сбросу (т.к ВИ53 не имеет входа сброс, то при включении он обычно начинает пищать на случайной частоте).

Но раз 1006ВИ1 обслуживать не надо, то можно выкинуть триггер 176TM1, а ВИ53 по сбросу затыкать программно. Для этого ему задают режим выдачи меандра, а коэффициент деления счётчиков не записывают (отчего ВИ53 будет ждать записи в него двух чисел и пока это не сделать, то пищать не будет). Если выкинуть 176ТМ1, то освободится и PC6, отчего ОЗУ можно будет расширить уже до 2 мб. Но это уже не стоит делать, т.к тогда нарушится совместимость по управлению звуком с оригинальной ИРИШЕЙ.

Так что уже можно начинать думать о схеме как поставить в ИРИШУ SIMM-30 на 1 мб (у меня они как раз есть) и как дописать конфиг эмулятора EMU, чтобы ОЗУ стало 1 мб. При ОЗУ 1 МБ и Z80B на такте 8 МГЦ без WAIT ИРИША станет аппаратно самой лучшей отечественной 8-ми разрядкой.

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

Уже хотел из-за неверной работы клавиатуры в EMU продолжить дописывать свой эмулятор ИРИШИ, но вспомнил как 20 лет назад в своих эмуляторах ОРИОНА и РК решил проблему несоответствия клавиш при эмуляции матрицы работающей в КОИ-7 или КОИ-8.

Если известно, что программа работает в эмуляторе (отчего в русском регистре выдаёт коды не в соответствии с надписями на PC-клавиатуре) и известен флаг RUSLAT, то нет никаких проблем перекодировать коды в самой программе 8-ми разрядки. Новые программы ОРИОНА написанные универсально (и отлаживаемые в эмуляторе) определяли, что они в эмуляторе и сами делали перекодирование кодов полученных от п/п-ммы F81B подпрограммкой, что приведена ниже. После этого и в эмуляторе и в реале клавиши в программах соответствовали надписям.

Причём в реале было JCUKEN-ЙЦУКЕН, как и положено в реале, а в эмуляторе было QWERTY-ЙЦУКЕН, как и положено на PC. Так что вскоре сделаю и удобный ввод русских букв в эмуляторе EMU и смогу в нём пользоваться CP/M-редактором "SuperText" для набора текстов.

Единственное, что непреодолимо в EMU, это то, что он не поддерживает процессор MC6800. Хотя болгарский Пылдин-601 и американские Altair-680 и SWTPC произведены тиражом в сотни (или в тысячу) раз большим, чем Микро-80 или ЮТ88, и программ для них несравнимо больше. Потому имело больший смысл эмулировать их. Свой эмулятор ИРИШИ допишу позднее (он лишь для MSDOS), когда начну писать серъёзную программу для ИРИШИ в 1000 человеко-часов, а со своим эмулятором это делать удобнее.

PERECOD:                        ; буква в рег.C
        LD      DE,TBL2
        LD      HL,TBL1
PRK_LO: LD      A,(HL)
        OR      A
        JR      Z,NOPRK
        CP      C
        JR      Z,FOUND
        INC     DE
        INC     HL        
        JR      PRK_LO
       
FOUND:  EX      DE,HL
        LD      C,(HL)        
NOPRK:  LD      A,C
        RET

TBL1: defb "ABCDEFGHIJKLMNOPQRSTUVWXYZ,.[&'%;:abcdefghijklmnopqrstuvwxyz<>{+*}]",0
TBL2: defb 'FISWUAPR[OLDXT]ZJKYEGMC^NQB@H,.:v|fiswuapr{oldxt}zjkyegmc~nqb\hV\_?'

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

С высоким TPA, естественно, работают все CP/M-программы, в том числе работают и все компиляторы ЯВУ (кроме всего нескольких, что хотят TPA более 59 кб). Теперь уже можно пользоваться редактором "SuperText".

Обнаружилась серъёзная неприятность с родным фонтом ИРИШИ, точнее с псевдографикой. Разработчики ИРИШИ встроили в резидентный фонт псевдографические символы в интервале $80...$BF не по стандарту КОИ-8. А правильно делать по одному из стандартов, имеющих псевдографику. Например, по раннему варианту КОИ-8, который описан на странице 281 в книге В.Э.Фигурнова "IBM PC для пользователя", издание 2, 1992, М. Финансы и статистика. Там приведён стандарт кодировки КОИ-8 с псевдографикой. Я использовал эту кодировку в 90-тые. Но в LINUX и в Интернете сейчас используется другая интернациональная кодировка под названием KOI8-R (русскими буквами это уже не пишется).





Видно, что в редакторе SED странслированном для псевдографики ОРИОНА (там она тоже неверная в большинстве драйверов) горизонтальные линии нарисованные псевдографикой КОИ-8 отображаются другими графическими символами. То же будет для любых программ с псевдографикой.

Кодировка псевдографики в ИРИШЕ не только не совпадает ни с основной ГОСТ, ни с MIC, ни с болгарской, ни с альтернативной, ни с любой из КОИ-8 кодировок. Более того кодировка ИРИШИ - не только от балды, но и совершенно бессмысленная. И не только потому, что в 1984 году не было стандартов.

Символы псевдографики не только переставлены, но и половина символов для рисования рамок просто выкинуты. Без них даже полноценно не начертить ни одинарную, ни двойную рамки. А вместо необходимых символов псевдографики для рисования рамок вставлены никому ненужные математические значки и подстрочные цифры. Возможно вывод формул полезен для учёных химиков из МГУ, но обычным людям вместо вывода формул нужнее рисовать рамки. Придётся перешивать ПЗУ-1, где резидентный фонт.

Т.е набор псевдографики - бесполезный. Фонт псевдографики надо менять на стандартный, ПЗУ перезашивать. Вид псевдографики в машине д.быть один и именно стандартный.

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

Исправить это в эмуляторе - работа на полчаса ручного редактирования фонта. А вот для реала перешивать ПЗУ сейчас мне хлопотно. Временно попробую выкрутиться программно, загрузкой недостающих граф.символов и перекодированием. Для High CP/M (в карте 1) это не приведёт к снижению уровня TPA, но вот для CP/M на 43 кб в карте 2 это приведёт к понижению уровня TPA на размер доп.фонта, таблиц и доп.кода, т.к в карте 0, где работает CONOUT нет другого ОЗУ, кроме ОЗУ из банки 2. Потому-то и выгоднее перезашивка фонта в ПЗУ.

При добавлении только отсутствующих значков и использовании имеющихся в ПЗУ значков псевдографики за счёт табличного перекодирования получится меньший расход памяти, чем при добавке полностью нового фонта, хотя добавляется программирование. Т.о для себя пока ПЗУ перешивать не буду, но путём ухищрений и извращений вывод псевдографики сделаю по стандарту КОИ-8, хотя для Low TPA CP/M в карте 2 это понизит TPA.

В DOS я буду использовать фонт KOI8-R, т.е текущий стандарт. Точнее в DOS будет два стандарта - АЛЬТ и KOI8-R, т.е можно использовать обе кодировки без ограничений. Прошит будет естественно KOI8-R (т.к русские буквы КОИ-8 уже прошиты в ПЗУ и это менять нельзя), а АЛЬТ будет получаться табличным перекодированием. При включении АЛЬТ-кодировки будет выполняться незаметное табличное перекодирование при вводе и выводе. Применение стандартной кодировки позволяет использовать стандартные перекодировщики кодировок для MSDOS, в то время как для уникальной иришиной кодировки пришлось бы писать свой перекодер.

Кодировка КОИ-8, что приведена в книге Фигурнова (она повторена из первого издания 1989) уже к началу 1990-тых устарела. Эта кодировка основана на использовании псевдографики из текстового адаптера PC XT, т.е содержит те же символы псевдографики, они лишь порядно (т.е рядами по 32) сдвинуты на другие позиции. Т.о это вариант КОИ-8 для MSDOS.

В этом раннем варианте графического КОИ-8, как и в КОИ-7, нет буквы "ё", т.к изначально ни в КОИ-8, ни в КОИ-7 не было буквы 'ё', что и нанесло огромный вред русскому языку, - люди имеющие дело с компьютерами вынужденно привыкли обходиться без буквы 'ё', в результате чего её использование существенно сократилось. Лишь с появлением в 90-тые годы IBM PC с АЛЬТ-кодировкой буква 'ё' вернулась в компьютерные тексты. Обычно в стандартном варианте кодировки КОИ-8 букву "ё" добавляли в позициях $7F и $FF. Но такой вариант кодировки всё-равно не прижился. Сейчас вариант КОИ-8 из книги В.Фигурнова вообще не применяется (и сохранился возможно лишь на 8-ми разрядках).

Если разбираться, что такое КОИ-8 или KOI8, то это слово вообще ни о чём. Т.к это означает лишь, что в данной кодировке в позициях $20...$7F американские ASCII, в позициях $C0...$FF русские буквы (причём не по алфавиту, а по соответствию латинским). А в позициях $80...$BF может быть всё-что угодно, например, пиктограммы, клинопись или иероглифы, но всё равно это будет КОИ-8. Потому сейчас существует с десяток кодировок называемых KOI8.

К середине 90-тых для целей Интернета был принят другой стандарт, который назвали уже не русскими, а латинскими буквами (KOI8) и он базировался уже не на кодировке из текстового адаптера XT (или АЛЬТ-кодировке), а на кодировках для Windows и Интернета. При этом добавилось много символов из кодировки CP1251, в том числе наконец стандартно появилась и буква "ё", а позиции псевдографики полностью изменились. Именно такой вариант и стал применяться в Интернете и в LINUX.

Но некоторые страны, которые также используют кирилицу (или нечто производное) ввели свои модификации в эту кодировку, чтобы добавить национальные буквы, причём в порядке своего алфавита. При этом позиции символов псевдографики снова изменились. Потому говорить о стандартном положении символов псевдографики можно только для одной кодировки называемой KOI8-R.

Из-за разнообразия стандартов псевдографики в КОИ-8 можно подумать о использовании в DOS только АЛЬТ-кодировки. Т.к в ней единственный стандарт псевдографики и он хорошо документирован. При АЛЬТ все ответы пользователя придётся получать лишь латинскими буквами. При КОИ-8 можно было написать: "Форматировать винчестер [Д/Н] ?" и т.к на клавиатуре 8-ми разрядки похожие латинские и русские буквы на одних клавишах, то пользователь мог нажать хоть "D" или "d" или "Д" или "д", т.к после команды AND 5FH получался код $44 и достаточно было одной команды сравнения. А при АЛЬТ кодировке такой трюк не пройдёт, придётся делать кучу сравнений.

Но сам русский фонт в ПЗУ даже при АЛЬТ-кодировке в CP/M менять нельзя, т.к если заменить его на АЛЬТ, то неверно будет выводиться КОИ-7 и придётся переделывать драйвер в п/п-мме CONOUT в ROM-BIOS ИРИШИ, т.к перестанут правильно работать коды $0E и $0F. А КОИ-7 нужен для программ адаптированных от РК86 и Микро-80.

ё:

____This is my small review of 8-bit cyrillic encodings universe. I didnʼt try to say anything for encodings not interesting for me (e.g. Tajik); if you didnʼt find enough information, go to links section. In this article, "encoding" is used as alias for more standard "character set". I hope this wonʼt be problem until next major rewriting.
____As of 2016, this material gets more and more historic. There are some areas where 8-bit encodings are still in use (for example, I have a FidoNet point and keep reading and writing there), but majority has been already moved to Unicode. I appreciate this process.
____All pictures shows top half (0x80-0xFF) only. Range 0x00-0x7F is equal to the same of us-ascii and iso-8859-1. Most pictures were got from Andrew Porokhnyak and Fingertipsoft, thanks to both:)
____Encoding groups:

1. KOI8 group
   
   
2. ALT group
   
   
3. ISO
   
   
4. Microsoft CP1251
   

____KOI8 group was the most widespread for the long time in traditional russian and ukrainian Internet due to historical reasons: it was used in first localizations of Unix systems. KOI stands for Russian abbreviation of "Information exchange code". Current group consists at least of:

• KOI8-R
  
  
• KOI8-U
  
  
• KOI8-RU
  
  
• KOI8-F (KOI8-unified)
  
  
• ISO-IR-111 (ECMA-Cyrillic, KOI8-E)
  

____KOI group falls into KOI8 group and KOI7 group (now historic). KOI7 encodings were used on RSX-11, RT-11 and similar systems. All KOI8 encodings have identical contents of codes 0x00-0x7F (the same as in US-ASCII) and 0xC0-0xFF (32 russian letters, i.e. full alphabet without Io/io, in both cases). Order of russian letters isnʼt alphabetical, but bound to order of latin alphabet letters with the same of similar pronounciation. Unrelated letters are bound in almost arbitrary way (Ю(Yu) - @, Я(Ya) - Q, Э(E) - \). Also, big letters are placed after small ones; this is compatibility issue with KOI7 encodings. In original KOI8, contents of 0x80-0xBF is absent at all (for 8-bit meaning) or identical to 0x00-0x3F (for 7-bit meaning). Different encodings in KOI8 group defines contents of 0x80-0xBF area in very different way.
____KOI group originates from Soviet standard GOST 19768-74, which defined three KOI7 variants and one KOI8. Donʼt mix this with GOST 19768-87, which defines completely another encodings (see later for ISO-8859-5 and ALT group).
____Some words for encodings unlisted here. DIS-8859-5 is generally known as another name for KOI8-R, but I suppose it had defined only standard letter group and Io/io. A KOI8-C is known to me as rarely seen mix of KOI8 in 0xC0-0xFF and CP1251 in 0x80-0xBF; I didnʼt see any standard for it. There is another KOI8-C which had added letters for old (before 1918) Russian alphabet, and also for most Slavonic alphabets based on Cyrillics; use Google for details. KOI8-RUB is yet another invention to support Ukrainian and Belorussian letters, not popular now. This list isnʼt complete...
____The following encodings: KOI8-K1, KOI8-L2, KOI8-CS2 are not Cyrillic; they was created for Czech and Slovak languages. Common name "KOI8" was used for them due to socialism camp traditions. They doesnʼt fit into requirements listed above for cyrillic KOI-8 encodings.



____KOI8-R is the first IANA-standardized encoding in this group; it is defined in IETF RFC 1489. IANA alias: CSKOI8R. The only used for russian Internet in mid-1990s and widespread now (but less and less, in preference to cp1251 and Unicode). It is applicable for English and Russian languages. It doesnʼt applicable even for Ukrainian; KOI8-R developer, Andrey Chernov, wanted pseudographic characters instead of additional letters.
____KOI8-R is also known as CP878 in OS/2 and as CP20866 in Windows, csKOI8R.




____KOI8-U is modification of KOI8-R with inclusion of Ukrainian letters. First versions of KOI8-U had appeared in 1992, rather full localization package for Unix systems is known since 1994, but it wasnʼt tried to codify it for other world until 1997 after appearance of KOI8-RU draft (see below). Standard source is IETF RFC 2319. Now it is standard de facto for Ukrainian Internet.




____KOI8-RU was invented as private innovation of Yuri Demchenko from Kiev Politechnical Institute to provide KOI8-R-compatible encoding with letters of Slavonic exUSSR Cyrillic alphabets (Ukrainian, Belorussian), with positions borrowed from ISO-IR-111. In 1997 support of this encoding was added to Microsoft Outlook Express. This charset wasnʼt supported by Ukrainian Internet community due to presence of uncodified but used KOI8-U; the latter one was pushed instead to IETF. Not registered at IANA, but also supported by GNU iconv.
____Microsoft defined CP21866 as KOI8-U but for a long time it really was KOI8-RU. In practice, there is too small difference between them as to be easily mixed.




____KOI8-F is innovation of Fingertipsoft which contains all letter of Russian, Ukrainian, Belorussian and Serbian alphabets. It isnʼt known to IANA or Windows, but is supported by newest Perl and used in some IRC networks because it covers letters from all Cyrillic charsets.




____ISO-IR-111 (aliases: ECMA-Cyrillic, KOI8-E, ECMA-113:1986) is ECMA and ISO standardized cyrillic coding of KOI8 group. (Donʼt mix with ECMA-113:1988 which is effectively ISO-8859-5.) With KOI8-R compatibility in Russian letters, it defines many additional letters for Ukrainian, Belorussian and Serbian alphabets. But it doesnʼt contain ukrainian "ghe with upturn" and so has limited value for Ukrainian.
____ISO-IR-111 has problem in IETF definitions: see ISO-IR-111 sore letter by Michael Sokolov. In a few words: while ISO/ECMA definition really has encoding of KOI8, RFC 1345 has erroneous definition of completely another encoding (identical to CP1251 in 0xC0-0xFF). This means high probabillity of implementations which erroneously use another encoding named as ISO-IR-111 or ECMA-Cyrillic.




____PC adaptation of Soviet standard GOST 19768-87 defined new encodings: "main" ("osnovnaya") and "alternative" ("alternativnaya") in order to provide compatibility for new generation of computers based on IBM PC clones. The main idea was that "main" encoding shall be used for home-grown programs, and "alternative" one shall be used for programs developed outside of USSR. Formally they were created in the following way:

• "Alternative" encoding is IBM cp437 modification that non-English alphabet and rare codes areas (0x80-0xAF and 0xE0-0xEF) were refilled with Russian alphabet. 32 russian letters (full alphabet without Yo) were placed: big ones on 0x80-0x9F, small ones in 0xA0-0xAF and 0xE0-0xEF. Other areas was unchanged from cp437. (See also for Io/io in 0xF0/0xF1.)
  
  
• "Main" encoding differs from "alternative" that areas 0x80-0xAF and 0xB0-0xDF were inter-exchanged: pseudographics was moved to 0x80-0xAF, Russian letters - to 0xB0-0xDF. This variant has Russian letters in the same place as in ISO-8859-5 because ISO-8859-5 is based on it.
  

____"Main" encoding very quickly died because it was incompatible with huge flow of programs developed outside of (ex-)USSR, but ISO-8859-5 is based on it. "Alternative" encoding, on the other side, had given a bunch of encodings compatible with cp437 and so with IBM PC pseudographics. Most used now are cp866 and ruscii.
____Picture for "main" encoding of Soviet IBM PCʼs clones. This picture is somewhat broken because it shows Io/io in 0xF0/0xF1. This differs from original encoding which had there the same symbols there as in cp437, ≡(U+2261) and ±(U+00B1).


____Picture for "alternative" encoding of Soviet IBM PCʼs clones. This picture is somewhat broken because it shows Io/io in 0xF0/0xF1. This differs from original encoding which had there the same symbols there as in cp437, ≡(U+2261) and ±(U+00B1).




____CP866 is Microsoftʼs invention based on PC clonesʼ "alternative" coding. It has some extensions after 0xF2 - Ukrainian Ji/ji, Ukrainian Ie/ie and Belorussian short U/u. It hasnʼt got Ukrainian "ghe with upturn" which wasnʼt officially restored yet at the moment, and Ukrainian/Belorussian I/i which was supposed to be unnesessary when having Latin I/i.




____RUSCII (a.k.a. IBM CP1125, a.k.a. x-cp866-u in UUPC/Ache) is Ukrainian government standard (RST 2018-91) for DOS, based on common "alternative" encoding, but different from cp866 in 0xF2-0xF9. FreeBSD also has console fonts for it (cp866u-*) and map file (koi8-u2cp866u). It is known by GNU iconv as CP1125.
____It seems this coding is also known as CP866NAV in TeX and Emacs, CP866NAV/IBM866NAV/866NAV in new GNU iconv. It is incompatible with CP866 in definition of Ukrainian letters, this caused some mess between encodings.




____ISO-8859-5 is the ISO standard for cyrillic charset. Symbol range 0xB0-0xEF is the same as in "GOST main" encoding (see ALT group), due to its history. Ranges 0xA0-0xAF and 0xF0-0xFF contains many symbols of different Cyrillic alphabets including Ukrainian, Belorussian and Serbian. Same as in for ISO-IR-111, it doesnʼt contain Ukrainian "ghe with upturn".
____Its usage in Internet and in other practice is very limited; really, it only was source of pain because no really widespread systems and system classes used it (used Alt, KOI8-*, cp1251 instead). The only class of systems for it known to me is big DBMS (DB/2, Oracle) but administrators systematically patched them to support more traditional codings. Using modern jargon, ISO-8859-5 is "epic fail". On the other side, the Cyrillic section of Unicode copies its main part (0xA0-0xFF) to U+0400...U+044F with minor changes.
____IANA alias: Cyrillic. See also dramatic history for ECMA/ISO charset mutation. I have said it already: GOST 19768-87 had defined totally another encoding that was in previous GOST 19768-74. Donʼt ever mix them.
____Aliases: ISO-IR-144, ISO_8859-5, ISO_8859-5:1988.
____IBM name: CP915.
____Windows name: CP28595.


____ISO-IR-153 is "restricted" variant of ISO-8859-5: it defines only 0xB0-0xEF, 0xA1 (Io) and 0xF1 (io). Often it is erroneously named as GOST_19768-74.



____CP1251 was invented by Microsoft and ParaGraph (Moscow) as Cyrillic coding for Windows. A legend says that it was initially invented as a result of conversion cp437 -> iso-8859-1 applied to an early version of CP866 encoding, to simplify conversion process for DOS documents which encoding canʼt be determined. It contains most additional symbols for Ukrainian, Belorussian, and Serbian alphabets. Now it is one of the most popular encodings for Russian and Ukrainian, and the most popular one for Belorussian and Bulgarian, among 8-bit codings, used de facto in some areas (e.g. ICQ IM network, video subtitles...)
____IANA name: windows-1251



Источник

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


Это мой небольшой обзор вселенной кодировок 8-ми битовой кириллицы.  Я не включил в обзор кодировки, которые мне не интересны (например, таджикские);  если вы не нашли достаточно информации, перейдите в раздел ссылок.  В этой статье слово «кодировка» используется в качестве псевдонима для более стандартного термина «набор символов».

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

На всех рисунках показана только верхняя половина кодировок (0x80-0xFF). Символы диапазона 0x00-0x7F одинаковые с ASCII и ISO-8859-1. Большинство картинок были получены от Андрея Порохняка и Fingertipsoft.

Группы кодировок с кириллицей:

1. группа КОИ-8 кодировок
   
2. группа АЛЬТ кодировок
   
3. ISO
   
4. Microsoft CP1251
   

Группа КОИ-8 долгое время была наиболее распространенной в традиционном русском и украинском Интернете по историческим причинам: она использовалась в первых локализациях систем UNIX. КОИ является аббревиатурой от «код обмена информацией». Текущая группа КОИ-8 состоит как минимум из:

• KOI8-R
  
• KOI8-U
  
• KOI8-RU
  
• KOI8-F (KOI8-unified)
  
• ISO-IR-111 (ECMA-Cyrillic, KOI8-E)
  

Группу КОИ можно разделить на группу КОИ-8 и группу КОИ-7 (которая в настоящее время уже лишь историческая). Кодировки группы КОИ-7 использовались в CP/M, RSX-11, RT-11 и аналогичных системах с устройствами отображения и печати допускающими лишь 7-ми битовые символы.

Все кодировки КОИ-8 имеют идентичное содержание для кодов 0x00-0x7F (те же, что в US-ASCII) и 0xC0-0xFF (32 русские буквы). То есть к ASCII добавлялся полный русский алфавит без Ё (хотя отсутствующую в первом стандарте букву ё иногда добавляли в позиции 0xFF вместо заглавного Ъ).

Порядок русских букв в КОИ не является алфавитным, а определяется порядком букв латинского алфавита с близким звучанием. Несозвучные буквы распределены произвольным образом (Ю - @, Я - Q, Э - \). Также большие (заглавные) буквы следуют после маленьких; это чтобы была простая конверсия из КОИ-7 в КОИ-8 для заглавных букв (модификацией лишь одного бита).

Вся группа КОИ происходит от советского стандарта ГОСТ 19768-74, в котором определены три варианта КОИ-7 и один КОИ-8. Не смешивайте это с ГОСТ 19768-87, который вводит совершенно другое кодирование (см.далее ISO-8859-5 и группу АЛЬТ кодировок) .

В оригинальном стандарте для КОИ-8 1974 года символы с кодами 0x80-0xBF отсутствуют. В дальнейшем все различные кодировки в группе КОИ-8 определяют содержимое области 0x80-0xBF совершенно по-разному.

Несколько слов о кодировках, не перечисленных здесь. DIS-8859-5 (draft ISO, предварительный проект из 1987) обычно известен как другое название для KOI8-R, но я предполагаю, что он определил только стандартную буквенную группу и Ё/ё. Мне известен KOI8-C как редко встречающаяся смесь KOI8 в 0xC0-0xFF и CP1251 в 0x80-0xBF. Я не встречал стандарт для него. Существует еще один KOI8-C, в котором добавлены буквы для старого (до 1918 года) русского алфавита, а также для большинства славянских алфавитов, основанных на кириллице. KOI8-RUB - еще одно изобретение для поддержки украинских и белорусских букв, не популярное сейчас. И этот список КОИ кодировок далеко не полный ...

Кодировки KOI8-K1, KOI8-L2, KOI8-CS2 не являются кириллицей; они были созданы для чешского и словацкого языков. Общее название "KOI8" было использовано для них лишь из-за существовавших в то время традиций лагеря социализма. Они не вписываются в перечисленные выше требования для кодировки кириллицы КОИ-8.


KOI8-R - это первая в этой группе стандартизованная IANA кодировка; это определено в IETF RFC 1489. Alias IANA: CSKOI8R. Единственный используемый для российского Интернета в середине 1990-х и широко распространенный в настоящее время (но всё реже и реже, чем CP1251 и Unicode). Это применимо для английского и русского языков, но не подходит для украинского языка; разработчик KOI8-R Андрей Чернов разумно предпочёл сохранить традиционные графические символы для рамок вместо введения дополнительных букв.

KOI8-R также известен как CP878 в OS/2 и как CP20866 в Windows, csKOI8R.



KOI8-U является модификацией KOI8-R с включением украинских букв. Первые версии KOI8-U появились в 1992 году. Полный пакет локализации для систем UNIX известен с 1994 года, но он не пытался кодифицировать его для другого мира до 1997 года после появления проекта KOI8-RU (см.ниже). Стандартным источником является IETF RFC 2319. Теперь он является стандартом де-факто для украинского Интернета.



KOI8-RU был изобретен как частная инновация Юрия Демченко из Киевского политехнического института для получения кодировки, совместимой с KOI8-R, буквами славянского алфавита ex-USSR кириллицы (украинский, белорусский), позиции заимствованы из ISO-IR-111. В 1997 году в Microsoft Outlook Express была добавлена поддержка этой кодировки. Эта кодировка не была поддержана украинским интернет-сообществом из-за наличия некодифицированного, но используемого чаще KOI8-U; последний был выдвинут вместо IETF. Не зарегистрирован в IANA, но также поддерживается GNU iconv.

Microsoft определила CP21866 как KOI8-U, но долгое время это на самом деле был KOI8-RU. На практике разница между ними слишком мала, так что их можно легко спутать.



KOI8-F - это инновация Fingertipsoft, которая содержит все буквы русского, украинского, белорусского и сербского алфавитов, но отсутствуют символы для рисования двойных рамок. Он не известен IANA или Windows, но поддерживается новейшим Perl и используется в некоторых сетях IRC, поскольку охватывает буквы из всех кодировок кириллицы.



ISO-IR-111 (Aliases: ECMA-Cyrillic, KOI8-E, ECMA-113: 1986) соответствует стандарту ECMA и ISO кириллического кодирования группы KOI8 (не путайте с ECMA-113: 1988, который по сути является ISO-8859-5). При совместимости с KOI8-R по русским буквам, он определяет много дополнительных букв для украинского, белорусского и сербского алфавитов, но в нём полностью отсутствуют графические символы для рисования рамок. Также не содержит украинского слова "ghe with upturn" и поэтому имеет ограниченную ценность для украинского языка.

У ISO-IR-111 есть проблема в определениях IETF. В двух словах: хотя определение ISO/ECMA действительно имеет кодировку KOI8, RFC 1345 имеет ошибочное определение совершенно другого кодирования (идентично CP1251 в 0xC0-0xFF). Это означает высокую вероятность реализации, в которой ошибочно используется другая кодировка, названная как ISO-IR-111 или ECMA-Cyrillic.




Для использования на IBM PC и клонах в 1987 году советский ГОСТ 19768-87 ввёл две новые кодировки: «основная» и «альтернативная». Идея заключалась в том, что «основная» кодировка должна использоваться для отечественных программ, а «альтернативная» - для программ, разработанных за пределами СССР. Формально они были получены следующим образом:

• «Альтернативная» кодировка - это модификация IBM cp437, согласно которой области с неанглийским алфавитом и редкими кодами (0x80-0xAF и 0xE0-0xEF) были заполнены русским алфавитом. Было размещено 32 русские буквы (полный алфавит без Ё): большие на 0x80-0x9F, маленькие на 0xA0-0xAF и 0xE0-0xEF. Другие области не изменились относительно CP437 (заметьте также Ё/ё в позициях 0xF0/0xF1).
  
  
• «Основная» кодировка ГОСТ отличается от «альтернативной» тем, что области 0x80-0xAF и 0xB0-0xDF были переставлены: псевдографика была перемещена на позиции 0x80-0xAF, русские буквы - на 0xB0-0xDF. Этот вариант имеет русские буквы в том же месте, что и в ISO-8859-5.
  

«Основная» кодировка очень быстро умерла, потому что была несовместима с огромным числом программ, разработанных за пределами СССР, но ISO-8859-5 основан на ней. «Альтернативная» кодировка, с другой стороны, породила множество кодировок, совместимых с cp437 и, следовательно, с псевдографикой IBM PC. Наиболее используемыми сейчас являются CP866 и RUSCII.

Ниже рисунок символов "основной" кодировки советских клонов IBM PC. На этом рисунке кодировка несколько изменена, потому что в ней Ё/ё в позициях 0xF0/0xF1. Это отличается от оригинальной кодировки, в которой были те же символы, что и в cp437, ? (U + 2261) и ± (U + 00B1).


Картинка для «альтернативной» кодировки советских клонов IBM PC. Эта картина несколько изменена, также изображены Ё/ё в позициях 0xF0/0xF1. Это отличается от оригинальной кодировки тем, что там были те же символы, что и в cp437, ? (U + 2261) и ± (U + 00B1).



CP866 - это изобретение Microsoft, основанное на «альтернативной» кодировке советских клонов PC. У него есть некоторые расширения после позиции 0xF2 - украинский джи/джи, украинский то_есть/т.е. И белорусский короткий U/u. Но он не имеет украинского "ghe with upturn", который еще не был официально восстановлен в то время, и украинский/белорусский I/i, который, как предполагалось, был излишним при наличии латинского I/i.



RUSCII (он же IBM CP1125, он же x-cp866-u в UUPC/Ache) - это украинский государственный стандарт (RST 2018-91) для DOS, основанный на обычном «альтернативной» кодировке, но отличающийся от cp866 в позициях 0xF2-0xF9. У FreeBSD также есть консольные шрифты (cp866u- *) и файл карты (koi8-u2cp866u). GNU iconv известен как CP1125.

Похоже, это кодирование также известно как CP866NAV в TeX и Emacs, CP866NAV / IBM866NAV / 866NAV в новой GNU iconv. Это несовместимо с CP866 в определении украинских букв и вызывает некоторую путаницу между кодировками.



ISO-8859-5 является стандартом ISO на кириллицу. Диапазон символов 0xB0-0xEF такой же, как в кодировке «GOST main» (см.группу АЛЬТ ), из-за его истории. Диапазоны 0xA0-0xAF и 0xF0-0xFF содержат много символов различных кириллических алфавитов, включая украинский, белорусский и сербский. Как и в случае с ISO-IR-111 , он не содержит украинского слова "ghe with upturn".

Его использование в Интернете и в другой практике очень ограничено. На самом деле, это стало только источником проблем, потому никакие распространенные системы и системные классы его не использовали (вместо этого использовали ALT, KOI8-*, CP1251). Единственный известный мне класс систем - большие СУБД (DB-2, Oracle), но администраторы систематически исправляли их для поддержки более традиционных кодировок. Используя модное выражение, ISO-8859-5 является «эпическим провалом» (epic fail). С другой стороны, кириллическая часть Unicode копирует свою основную часть (0xA0-0xFF) в U + 0400 ... U + 044F с небольшими изменениями.

Alias IANA: Cyrillic. Смотрите также статью dramatic history for ECMA/ISO charset mutation. Я уже говорил это: ГОСТ 19768-87 определил совершенно другую кодировку, которая была в предыдущем ГОСТ 19768-74. Никогда не путайте их.

IBM name: CP915.
Windows name: CP28595.


ISO-IR-153 является «ограниченным» вариантом ISO-8859-5: он определяет только 0xB0-0xEF, 0xA1 (Ё) и 0xF1 (ё). Часто его ошибочно называют ГОСТ_19768-74.


CP1251 был изобретен Microsoft и ParaGraph (Москва) в качестве кириллической кодировки для Windows. Легенда гласит, что он был первоначально изобретен в результате преобразования cp437 -> iso-8859-1, примененного к более ранней версии кодировки CP866, чтобы упростить процесс преобразования для документов DOS, кодировка которых не может быть определена. Он содержит большинство дополнительных символов для украинского, белорусского и сербского алфавитов. Сейчас это одна из самых популярных кодировок для русского и украинского языков, и самая популярная для белорусского и болгарского языка среди 8-битных кодировок, используемых в некоторых областях (например, в сети ICQ IM, субтитры с видео ...)

IANA name: windows-1251


Ссылки:

http://czyborra.com/charsets/cyrillic.html
http://www.fingertipsoft.com/ref/
http://porokhnyak.org/cyr/
http://www.iana.org/assignments/character-sets
http://www.jbrowse.com/text/charsets.html
http://ext.by/libcyrillic/

2001-2017 текст Валентина Нечаева

Источник