ПЭВМ "Ириша". Модуль контроллера графического дисплея (МКГД).

Схема модуля контроллера графического дисплея (МКГД).
KokaF77:

Собственно схема, "распиленная" на функционально законченные блоки.
Может кому-нибудь и пригодится.
Фото кликабельны.

№11:

С Я.Картинки у KokaF77:

Ещё (копия):

Схема модуля контроллера графического дисплея (МКГД).
KokaF77:

Собственно схема, "распиленная" на функционально законченные блоки.
Может кому-нибудь и пригодится.
Фото кликабельны.

№12:

С Я.Картинки у KokaF77:

Ещё (копия):

Попробую разобраться, неспеша вдумчиво по тексту так сказать. Возможно другим это также пригодится, начнём:


Разбираться будем при помощи эмулятора (во вложении архив) естественно, так как собранной и рабочей ПЭВМ у нас пока нет.
Так читаем:

С точки зрения пользователя, составляющего программы для работы с модулем, он представляется как устройство, занимающее три адреса в области устройств ввода/вывода и некоторую зону в полном адресном пространстве ПЭВМ.

Так пока всё понятно, едем дальше:

Эта зона имеет размер 64 Кбайта. Записывая информацию в видеопамять, можно синтезировать изображение на экране монитора. При указанной на рис. 4.8 "прошивке" ПЗУ селектора адресов область дисплейной памяти распологается, начиная с адреса 0000H в странице 2 (Р0=0, Р1=1). На рис. 4.12 показана карта распределения внутренней памяти при работе модуля в различных режимах.


006

Вот тут лично мне немного не понятно насчёт второй страницы, а где первая и откуда появилась вторая страница. У нас на модуле имеется 8 микросхем ОЗУ К565РУ5 что даёт нам один полноценный банк памяти объёмом 64 Кбайт с адресами естественно 0000H по FFFFH. А вот второй банк начинается с адреса 20000H по 2FFFFH . Но у нас в минимальной конфигурации имеется только 8 микросхем, не понятно пока...

А рис 4.12 смотрим выше.

Так едем дальше:

Переключение режимов, выбор рабочих цветов точек и фона осуществляется записью соответствующих команд в регистры управления, имеющих следующие адреса управления режимом:
D8 (Hex) - регистр управление режимом, D9 (Hex) - регистр управления цветом, DA (Hex) - регистр выбора страниц на экране см. табл. 4.2). По фундаментальному назначению битов первые два регистра аналогичны графическому контроллеру ПЭВМ IBM PC.


007

Ну, вот тут пока всё понятно, если не вдаваться в подробности.

Так сохраним на всякий случай, а чуть позже продолжим. Надо всё ещё раз прочитать и осмыслить.

Продолжим...

Сначала запустим пожалуй эмулятор и определим, нет...

Сначала скажем пару неприятных слов по расположению бит в таблице --- Зачем их было распологать слева --> на право, это путает и сбивает с толку, покрайней мере меня. Ну что это такое - D0  D1  D2  D3  D4  D5  D6  D7 в итоге один глаз другого нет одно полушарие мозга другое посылает нах, правое говорит иди к левому, а левое говорит тут всё наизнанку я непонимать иди к правому...

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


008

и запуска программы МОНИТОР.


009

Итак монитор запущен и предлагает ввести нам команду.
Для того, чтобы посмотреть содержимое наших регистров воспользуемся командой I (Input) - ввод. При выполнении команды на дисплей выводится байт, принятый из порта ПЭВМ с адресом, заданным параметром команды.
Итак, команда нам известна это I адреса также D8H и D9. Смотрим:


010

Мы видим, что в регистре управления режимом записано значение 1AH (0001 1010 B) соответственно имеем:

D0 = 0 (*)
D1 = 1 (*) - на кой хрен не понятно (* - биты управления не используются)
D2 = 0 (*)
D3 = 1 (VIEN) - это сигнал VIEN (инверсный) пока не будем про него говорить...
D4 = 1 (MR/HR) - это сигнал MR/HR (инверсная первая часть)
D5 = 0 (*)
D6 = 0 (*)
D7 = 0 (HDCM ) - ага лог. 0  в соответствии с таблицей 4.3 см. ниже у нас выбран режим 1 (Монохромный среднего разрешения, 320 х 200 точек)
Так как не важно в каком состоянии будет находиться сигнал MR/HR (инверсная первая часть) решающее значение имеет бит D7 - HDCM (инверсный).


011

Вобщем пока что мы выяснили, что у нас включон режим 1...

Далее регистр Цвета D9H, тут мы будем пользоваться... хотя нет надоже дочитать далее про Режим 1:

В режиме 1 на экране отображается одна из страниц... Хотя стойте ... (Монохромный среднего разрешения, 320 х 200 точек)

Монохромный т. е. чёрно-белый, какого у нас всё синее, а буквы, то есть точки, жёлтые??? Непонятно.... Ладно тогда тем более, читаем далее:

В режиме 1 на экране отображается одна из страниц объёмом 8000 байт, причём в верхнем левом углу находится первый байт записанного изображения. (Старший бит соответствует первой засвечиваемой точке.) Через регистр управления цветом можно задавать окраску засвечиваемых точек (ага, в монохромном режиме, ну ну почитаем далее) и фона. Структура регистра управления цветом при работе в режиме 1показана на рис 4.13 ниже...


012

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


монохромный — Викисловарь
Значение:
одноцветный; выполненный в одном цвете; излучающий один цвет или цвета, различающиеся по яркости, но не по спектру.

Синонимы:
частичн. чёрно-белый, бесцветный, обесцвеченный; однотонный;

Что-то толи я дурак, толь колесо квадратное.

Монохромный значит чёрно-белый, ну в крайнем случае градации серого, но никак не Синий, Зелёный и т. д.

Ладно почитаем далее:

Регистр выбора страниц используется только в режиме 1 (Это тот третий о котором говорили в начале, с адресом DAH) и позволяет выбрать области отображаемой на экране памяти (две страницы). Это даёт возможность подготавливать информацию в невидимой странице и затем записью соответствующего байта управления вызывать её на экран.

Ну хоть тут всё как вроде бы понятно из рис. 4.12 как вроде всё видно - две области памяти по 8000 байт.

Давайте далее поэкспериментируем с монохромными (чёрно-белыми) цветами в соответствии с рис. 4.13...

Наш регистр управления цветом имеет на данный момент следующее значение, как мы уже убедились ранее - D9 = 0EH (0000 1110 B), посмотрим по рис. 4.13

Бит D5 (C4) = 0 D3 (C3) = 1 - это значит цвет фона синий, замечательно совпадае (чёрно-белый синий цвет). Далее посмотрим в какой монохромный цвет окрашена точка
Биты С2=1  С1=1 С0=0 получается Жолтый, тоже совпадает.

Замутим пожалуй так на зелёном фоне 00100 голубые точки 011. Тоесть нам надо записать в регистр управления цветом D9 следующую информацию 00100011 В или в шестнадцатиричной системе 23H. Попробуем:

О23,D9


013

как-то не очень видно шрифт лучше сделаем цвет точек красным 100
Записать придётся 00100100 В 24 H

O24,D9


014

Ну хоть, что-то начало проясняться...
Думаю, что и остальные цвета будут совпадать, но одно беспокоит, зачем писать Монохромный режим? Это же полноценный цветной режим и имеем мы 7 цветов, а учитывая цвет фона Чёрный, то и все 8 цветов - (Чёрный, Белый, Синий, Зелёный, Голубой, Красный, Малиновый (в игрушках хоть новые русские выглядеть будут натурально, заранее предусмотрели), Жёлтый и и всё потом ещё раз белый (111 В).

Ну с первым режимом как вроде немного разобрались...

А вот код 000 когда С2, С1 и С0 равны 0 не белый цвет точек даёт, а чёрный в таблице опечатка получается, если фон чёоный и точки как в первой строке код - 0000 0000 (00H) имеем цвет фона и цвет точек чёрный т. е. чёрный квадрат гелевича, как мы на работе говорили...


015

Для того, чтобы был обычный дисплей получается требуется цвет фона чёрный 0000 0 , а цвет точек белый из последней строки таблицы 111 итого имеем 0000 0111 (07 H)


016

Ну и интересно будет так: 0000 0010 (02 H)


017

А далее, думаю будет сложнее, намного сложнее...

Для сохранности...

Кстати, да, ESC+Q+N включает третий режим, подобрал методом тыка. Только почему-то снизу экран обрезан. И экран не очищается.

---------- Post added at 23:49 ---------- Previous post was at 23:47 ----------

ESC+Q+G - второй режим (4х цветный).

---------- Post added at 23:50 ---------- Previous post was at 23:49 ----------

ESC+Q+E - первый режим (стандарт)

---------- Post added at 23:55 ---------- Previous post was at 23:50 ----------

На разные буквы реагирует, в чём разница - пока не понятно.

---------- Post added at 23:58 ---------- Previous post was at 23:55 ----------

ESC+Q+D и ESC+Q+E выбирают разные страницы.

---------- Post added 14.11.2011 at 00:05 ---------- Previous post was 13.11.2011 at 23:58 ----------

Я понял, почему снизу обрезано - межстрочное расстояние меньше, а количество строк осталось то же (видимо, задаётся другими командами).

---------- Post added at 00:11 ---------- Previous post was at 00:05 ----------

Сведём воедино:
ESC+Q+A 320x200 страница 1 (E000-FFFF)
ESC+Q+B 640x200
ESC+Q+C 320x200 4 цвета (второй режим)
ESC+Q+D 320x200 страница 0 (C000-DFFF)
дальше повторяется до буквы P
ESC+Q+P выключить экран (вроде бы)
дальше то же

резерв.

Фотографии схем хорошо бы отфотошопить. Удобнее всего простым пакетом Foto Angello. Т.к достаточно лишь увеличить чёткость и контрастность и опустить уровень белого, чтобы бумага стала белой, а линии чёрными.

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

Что можно сделать? Можно напаять парочку РУ5 вторым этажом, чтобы поиметь 2 бита для раскраски монохромных режимов. Кроме второэтажных РУ5-тых это выливается в КП11 на видеовыходе (чтобы выдавать 4-х цветный RGB при сигнале VIDEO=0, т.е закраска цвета фона, цвет самих символов всегда чёрный или белый). На входы РУ5 можно подать 2 бита от резидентного ППА или смонтировать на плате триггер, записываемый по записи в порт $DB. Это простейшими средствами даст быстрый цветной режим (по идее цвета А.Волкова).

Но для базовой ИРИШИ более полезно поиметь расширение ОЗУ, а не улучшение цветовых возможностей, которые пока никого не волнуют. Можно заменить РУ5 на РУ7. При этом придётся найти 2 управляющих бита и резать печать адресов на мультиплексорах, чтобы переставить адреса (иначе РУ7 не регенерируются).

Но не каждый владелец ИРИШИ может позволить себе 565РУ7. Зато установка двухэтажных РУ5 в плату граф.адаптера без особых хлопот увеличивает объём ОЗУ в два раза, причём не мешая и дальнейшему расширению ОЗУ за счёт дополнительных плат ОЗУ.

Альтернативная банка РУ5-тых включается вместо основной банки. А для выбора используется коммутация всего одного сигнала /CAS. Кстати, непонятно зачем /CAS формируют на D47.4 и D47.2, включённых повторителем. Ведь D38.1 тоже мощный 531-ой серии, как и D47.2. Это потенциально даёт нам уже целых два свободных вентиля на плате.

Впрочем, у D47.2 есть целых 3 свободных входа, которыми можно запрещать /CAS банки ОЗУ, что позволит при двух банках коммутировать /CAS-ы даже не прибегая к установке ценных мультиплексоров, т.к то же самое с упехом сделает один вентиль из 531 ЛА3 (осталось лишь найти этот свободный вентиль на плате, - увы, авторы не отобразили свободные вентили).

В качестве управляющего бита для переключения банок можно задействовать незанятый бит резидентного ППА, но чтобы не волочить сигнал через системную магистраль и разъёмы, проще смонтировать на свободном посадочном месте триггер ТМ2 записываемый стробом записи в порт $DB. Сигнал выборки порта $DB это D4/3. Объединив его двумя диодами или на вентиле ЛЛ1 с /IOWR и получаем сигнал для входа C триггера.

А если доработать схему так, чтобы видеочасть всегда читала из банки 0, то одновременно получается не только доп.ОЗУ, но и улучшение архитектуры ИРИШИ. Это даёт в банке 1 сплошное ОЗУ для программ размером в 64 кб. Тогда как в исходной архитектуре было только 48 кб сплошного ОЗУ, т.к старшие 16 кб в карте 2 (в которой работают программы) заняты экраном.

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

Без этого будет два экрана. При записи в триггер банки нуля текущей будет банка 0 и будет отображаться экран из неё, а при включении банки 1 экран будет отображаться из неё. Если вторую банку использовать для эл.диска, то, чтобы избежать мигания экрана, лазить в неё придётся только во время бордюра.

Таким образом расход деталей на увеличение ОЗУ (кроме двухэтажной банки РУ5) минимален - несколько TTL-корпусов и немного проволоки МГТФ-0.03. Как видите в ИРИШЕ есть много способов увеличить ОЗУ для того, чтобы поиметь электронный диск.

чтобы посмотреть содержимое сист.регистров воспользуемся командой I (Input) - ввод. При выполнении команды на дисплей выводится байт, принятый из порта ПЭВМ с адресом, заданным параметром команды. Итак, команда нам известна - это I адреса D8H и D9. Смотрим...

Что-то я не въехал как Вам удаётся считывать содержимое сист.регистров задающих режим платы граф.адаптера. В реале у Вас такое не получится.

Если не полагаться на чтение красной книги, а посмотреть на схему граф.адаптера на странице 38, то мы увидим, что из портов $D8, $D9, $DA (и даже $DB...$DF, которые пока не используются, но это исправимо) нельзя ничего считать.

Выборки для этих трёх портов формируются на дешифраторе D4 (ИД7). На схеме видно, что эти выборки объёдиняются на трёх вентилях ЛЛ1 (D10.2...D10.4) с сигналом /IOWR (с выхода D3.1), который в свою очередь формируется из сигналов IO/*M, R/*W и /TE (так приходится делать, потому что магистраль моторолловская, а не интеловская). Таким образом на выходах трёх ЛЛ1 формируются стробы записи в три порта $D8, $D9 и $DA (которые реализованы на ТМ2 и ТМ8 ).

И больше никуда выборки этих 3-х портов не идут. Т.е сигналов для чтения портов вообще нет. Так что никак не получится программно считать то, что было ранее записано в порты $D8, $D9, $DA. Единственный способ узнать какой режим включён, это анализировать служебные ячейки ROM-BIOS в области FF40.

Что-то я не въехал как Вам удаётся считывать содержимое сист.регистров задающих режим платы граф.адаптера.

Это в эмуляторе делалось, 101 год тому назад...

barsik пишет:у владельцев ИРИШИ к плате граф.адаптера "так и тянутся их грязные ручонки", чтобы сделать усовершенствования. Что можно сделать?

barsik пишет:Напайка двух РУ5 вторым этажом даёт 2 доп.бита для раскраски монохромных режимов.

barsik пишет:установка двухэтажных РУ5 в плату граф.адаптера без особых хлопот увеличивает объём ОЗУ в два раза

Два бита для раскраски фона символов в 4 цвета в режиме 640*200, это несколько громоздко, т.к меняется видеовыход. Да и не особо надо, т.к режим 640*200 нужен только для текстообработки, а здесь можно обойтись и монохромом (с инверсией знакомест).

Проще и полезнее добавить лишь одну РУ5, которая даст один доп.бит переключающий палитру для каждого видеобайта в цветном режиме. Большее число цветов нужно лишь для графики игр. Т.к палитр всего две, то больше битов для управления палитрами и не надо. Это даст с некоторыми ограничениями 8 цветов одновременно видимых на экране.

А напайка целой доп.банки РУ5, порта для выбора банок и коммутатора /CAS, чтобы поиметь 128 кб, - это уже сложнее и существенно изуродует внешний вид платы. К тому же благодаря использованию статики получить дополнительные 64 кб, намного проще спаяв крошечную платку расширения с панелькой для w24512 (или двумя панельками для w24257), включаемую в магистраль или в локальную шину.

Потому единственное имеющая смысл доработка граф.адаптера - это как описано выше добавка бита для побайтового переключения палитр. Но и она имеет смысл только если кто-то возьмётся массово писать в огромном количестве для ИРИШИ игры уровня ПРИНЦА ПЕРСИИ.

Для игр с менее продвинутой графикой (особенно, не с человеческими, а с абстрактными фигурками) достаточно 4-х цветов. Кроме того, не стоит забывать, что CGA-режим для целей заливки сплошных объектов позволяет цветовой мозаикой пикселей изобразить гораздо большее число цветов.

Viktor2312 пишет:ESC+Q+A 320x200 страница 1 (E000-FFFF)
ESC+Q+B 640x200
ESC+Q+C 320x200 4 цвета (второй режим)
ESC+Q+D 320x200 страница 0 (C000-DFFF)
ESC+Q+P выключить экран (вроде бы)

А далее, думаю будет сложнее, намного сложнее...

Если переключать режимы вручную, то да. Управление цветами с помощью вывода на CONOUT вручную вводимых с клавиатуры байтов или прямой записи отладчиком вручную байтов в порт цвета $D9 утомительно. Переключать режимы и изучать установку цветов монитором-отладчиком неудобно, да и не получится.

Потому что в формировании графики на экране и цветов участвует не один байт, а сразу 16 байтов так называемого "файла управления CONOUT" (в адресах FF40...FF4F) и соответствующие ему 3 аппаратных байта записанные в порты $D8, $D9 и $DA.

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

Потому менять режим дисплея следует только программно. Для этого есть 3 способа.

Можно эти 16 байтов задающих режим вручную подготовить в специальной резервной области ASRAR (FF74). А затем выдать на консоль искейп-команду 'ESC,O' (это коды 27, 4FH), что вызовет загрузку этих 16-ти байтов из ASRAR в "файл управления" и автоматическое соответственное программирование апп.портов задающих режим граф.адаптера.

Можно то же самое сделать своей программой, для чего где-то подготовить 16 байтов и командой LDIR скопировать эти байты на FF40, что задаст режим программно, а затем нужно выполнить ещё 3 команды OUT в порты управления, чтобы включить соответствующий апп.режим адаптера и задать общеэкранный цвет.

Но самый простой способ задать режим и общеэкранный цвет, - это использование предназначенного для этого искейп-кода ESC,Q (27, 51H). Третьим параметром искейп-команды передаётся так называемый "байт управления" (рисунок 9.13). Этот байт никак не связан с железом, а чисто программный. Этот байт просто переносится в ячейку MODE (FF45) и программа CONOUT в ходе работы анализирует отдельные биты этого байта соответственно изменяя алгоритм работы.

Код "искейп-кю" только перестроит драйвер и запрограммирует порты, но общеэкранный цвет останется тем же, что был установлен в предыдущем режиме. Для задания цветов потребуется вывести ещё один искейп-код ESC,P (27, 50H) и передав тем самым (в третьем параметре команды) общеэкранный цвет. Причём этот байт цвета из "искейп-пэ" в разных режимах кодирует общеэкранный цвет по разному.

При этом, если в режимах 1 и 3 (которые моно) задаётся цвет PAPER и INK (причём из ограниченного набора цветов для INK и ещё меньшего для PAPER) сразу на весь экран, то в режиме 2 всё немного сложнее. Там в формировании цвета участвуют байты маски из "файла управления". Что позволяет их изменяя, выводить на экран буквы в 4-х разных цветах.

Ограничения на общеэкранные цвета в монохромных режимах следующие. В режиме 1 - четыре цвета для PAPER и восемь цветов для INK. А в режиме 3 всего один (белый) цвет для INK, хотя и целых 16 цветов для PAPER. Т.о чёрного цвета символов на цветном фоне не получить, хотя используя инверсию знакомест (см.ниже) можно вывести символы цветом PAPER на белом фоне.

Благодаря развитым искейп-кодам программирование текстового вывода не сложнее, чем на ОРИОНЕ с грамотным цветным оконным драйвером для CP/M. Хотя для программистов некоторым разочарованием может показаться отстутствие управляющих кодов ВКЛ/ВЫКЛ режима вывода символов в инверсии (Reverse Video on/off). В распространённых терминалах это коды или 27,36 / 27,37 или 27,70 / 27,71.

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

По счастью ИРИША это не убогий РК86, а имеет средства (пусть и не в соответствии с терминалом VT52) позволяющие поиметь инверсию знакомест. Для получения инверсии знакомест в монохромных режимах надо использовать XOR-маску вывода. Можно как напрямую писать её в ячейку FF42, обозвав флагом INVERSE, так и использовать искейп-код ESC,U служащий для задания XOR-маски вывода.

Оценивая программно-аппаратные возможности ИРИШИ сразу ясно, что развитые искейп-коды подпрограммы CONOUT позволяют иметь полный доступ к железу из программ написанных на ЯВУ. Увы, тут развитые ЯВУ типа СИ, Паскаля, PL/I, Кобола, Алгола, Фортрана и т.п подходят намного хуже в силу тормознутости кода. Т.о пользователям ИРИШИ разумнее всего программировать или на форте или на PL/M, т.к только они сохраняют полученному коду приемлемую скорость. Или надо турбировать ИРИШУ до максимума (и лучше на Z80).

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

Мне тут пришла в голову мысль, что текст на экране ИРИШИ в режиме 40*20 выглядит так печально потому, что используется тот же жирный IBM-овский фонт, что и в режиме 80 символов. Этот жирный фонт необходим для экрана 640*200, т.к тонкий шрифт в этом режиме из-за узкой полосы пропускания телевизоров и CGA-мониторов становится бледным, т.е с пониженной яркостью. В этом режиме 640*200 стремятся все вертикальные линии сделать максимально жирными, точнее шириной в 3 пикселя.

Но при экране 320*200 жирный шрифт не требуется и симпатичнее выглядит тонкий шрифт. Например, в ZX-Spectrum, где пиксель клок 14 МГЦ (в ИРИШЕ 16 МГЦ) шрифт толщиной в один пиксель выглядит вполне нормально и красиво, в то время как жирный фонт выглядит уродливо. В ИРИШЕ тоже можно поиметь тонкий шрифт на экране 40*20 или 40*25. Причём его даже не обязательно грузить из внешнего ROM-диска, а можно прошить в ROM-BIOS. Т.к в родном иришином ПЗУ в 16 кб уже изначально свободно $7C0 байтов, а после выкидыша разного ненужного хлама типа поддержки локальной сети и антикварных дисководов освобождается аж 9 кб пустоты.

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

В 9 кб успешно влезают не только дополнительный фонт, причём достаточно КОИ-7, т.к этот режим лишь для игр, и это отнимет всего $60*8= $300 ячеек, останется свободно еще $700 ячеек, чего хватит для размещения некоторых полезных для жизни процедур и данных. То что часто надо, а волочить это в код программ накладно. Например, таблицы перекодирования кодировок АЛЬТ в КОИ-8 и обратно, это полкилобайта. Также, как это было сделано в моих драйверах для ACP/M ОРИОНА достаточно добавить в служебные ячейки флаг текстовой кодировки (это кажется 0-КОИ-7, 1-КОИ-8, 2-АЛЬТ, но не суть), а в CONOUT на входе и в CONIN на выходе достаточно влепить заплатку CALL на перекодирование. Это легко сделать, это непыльная работа работа на 6.5 минут.

Перекодировка табличная по принципу XLAT, так что это не тормозит. Благодаря этому все мои нортоны выводят текст по команде T (Type) во всех кодировках. Если кто-то мечтает о кодировке CP-1251, то я это издевательство из вредности придуманное врагами из Microsoft (и внедрённое в 1987 вместе с Windows 2.0) вообще не использую. Пользуюсь только такими редакторами Windows, что поддерживают АЛЬТ-кодировку. А ещё есть ещё более гадкие кодировки UTF, это вообще кошмар, необходимый только для тех, у кого письменность использует 5000 иероглифов.

Все мои исходники и другие тексты в АЛЬТ-кодировке. АЛЬТ-кодировка и КОИ-8 позволяют иметь полноценные псевдографические рамки, а CP-1251 нет, потому она намного хуже. Потому в LINUX, который делали уже руские люди, а не подлые американские враги, применили КОИ-8, а не идиотскую CP-1251. КОИ-8 была бы удобнее, но раз КОИ-8 в MSDOS и Windows вообще не применяется, то приходится довольствоваться АЛЬТ-кодировкой.

АЛЬТ-кодировка конечно хуже, чем КОИ-8, т.к в АЛЬТ-кодировке нет простого перехода (а надо повсюду таскать громоздкую таблицу перекодирования), а текст набранный в КОИ-8 читается даже со сброшенным битом латинскими буквами. Потому все русские компьютеры до засилья IBM PC использовали КОИ-8, а АЛЬТ-кодировка, и менее удачные кодировки ГОСТ и MIC это вынужденная мера, т.к позиции кириллицы, т.е коды $C0...$FF оказались в фонте IBM PC подлыми американскими врагами специально заняты псевдографикой, которую непременно надо было сохранять, чтобы использовать вражеские программы.

Кстати, по поводу небайтовых шрифтов. Написать небайтовый драйвер шрифта например 6*8 для ИРИШИ несложно (ну может полчаса), - не с нуля конечно, а взяв исходник драйвера 6*8 для ОРИОНА и чуть-чуть его переделать (там буквально немного менять, всего лишь ~50...75 команд).

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

Небайтовый драйвер можно попробовать сделать лишь для прошивки в ПЗУ, естественно, при его расширении с 16-ти до 32 кб, т.к программа в ПЗУ прогоняется намного быстрее. Так что пока на моей ИРИШЕ не будет эффективного такта 5 МГЦ (вместо ~1 МГЦ) не особо нужен такой драйвер.

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

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

А вот когда я посмотрел на фото платы граф.адаптера от MV1971 (что по ссылке ниже), то сразу обнаружил, что MV1971 - крутой корифан. Он догадался на одно из двух свободных посадочных мест поставить на плате граф.адаптера задающий генератор на 16 МГЦ. И теперь он может ставить какой угодно кварц на плате ЦП, т.е получить ИРИШУ с тактом процессора в 3 МГЦ (что даст эффективный такт в режимах 2 и 3 в ~1.5 МГЦ, а в режиме 1 более 2.5 МГЦ).

https://zx-pk.ru/threads/29598-irisha-chernye-platy-ot-mv1971-sborka.html?p=981437&viewfull=1#post981437

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

Вы, что-то путаете, я разводил плату, только для заводского изготовления, то есть она была только с маской, с шелкографией, и всем остальным, у меня только один вариант печатной платы МКГД.

И как было договорено с Кокой, это точная копия платы из красной книги, но с исправлением явных ошибок. Напомню, на плате нет ошибок и при правильной сборке, она включается и начинает работать сразу, естественно если детали исправны и ПЗУ имеют правильное время задержки, если не правильное, то 1 конденсатор, как сделал MV1971 и тоже всё работает.

Те, что без маски, мне кто-то придарил, уже не помню кто, они родом из 80-х.


Вот моя плата, других я не делал, если не считать, недоделанный вариант, для АТХ версии.







.

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

А техническим языком можно говорить о том, что в иришиной плате граф.адаптера применён самый неудачный принцип синхронизации обращений к ОЗУ видеочасти и процессора, худший, чем аналогичный принцип синхронизации использованный в последующих моделях отечественных 8-ми разрядок. Тогда как синхронизатор ИРИШИ в видео режимах 2 и 3 приводит к потере скорости до 50%, в разработанных на несколько лет позднее " РК86", "Львове" и Векторе" инженерам удалось уменьшить потери на синхронизацию до 20%, а в "Океане", "Корвете" и "Специалисте" эти потери удалось довести аж до нуля. Кстати, насчёт "Львова" у меня есть обоснованное подозрение, что в нём в цвете также торможение вовсе не на 20%, а на ~35% (т.к там такт КР580 2.2 МГЦ, а ОЗУ всего одна банка).

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

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

Каждому, кто в курсе устройства диспетчера памяти ИРИШИ ясно, что с имеющимися прошивками безтормозное ОЗУ можно включить в 4-х 16-ти килобайтовых окнах с адресов $4000 и $C000 в картах 1 и 3 (что не использованы в базовой ИРИШЕ). Таким образом, если добавляемое ОЗУ безтормозное или лишь слегка вэйтованное (слегка вэйтованное значит, что оно тормозит на 10 %, а не вдвое, как тормозит ОЗУ на плате граф.адаптера), то в картах 1 и 3 из 64 кб адресного пространства на 32-х килобайтах программа будет прогоняться со скоростью определяемой клоком процессора, а в 32-х килобайтах ОЗУ, что читается из граф.адаптера программа будет прогоняться вдвое медленнее.

Слегка печально, что и в карте 0, которую можно вызывать из карты 2 имея стек на $4000...$BFFF, а из карт 1 и 3 имея стек лишь на $4000...$7FFF стек оказывается в тормозном ОЗУ и без перепрошивки 155 РЕ3 или 556 РТ4 на плате граф.адаптера это не изменить. Т.е в карте 0 вообще нет безтормозной памяти. Это приводит к торможению вывода на экран, хотя сама программа вывода работает из ПЗУ без тормозов, но стек в ОЗУ тормозит.

Исправить обе эти ситуации позволяет перепрошивка 556 РТ4, стоящей в плате граф.адаптера.

Сейчас это РТ4 прошито так, что память в граф.адаптере "отзывается" при обращении по всем 64-м килобайтам в банке 2. Если же прошить РТ4 так, чтобы граф.адаптер занимал в карте 2 только 16 кб с $C000 (при этом, кстати, 565 РУ5 можно заменить на РУ6), лишь экранный буфер, чтобы остальные 48 кб читались из безтормозного ОЗУ на плате доп.ОЗУ, то почти все проблемы при программировании для ИРИШИ исчезнут.

Причём совместимость нисколько не пострадает, т.к программе всё-равно откуда в адресное пространство включена память. Такого же ускорения можно достичь и перепрошивкой карты памяти 155 РЕ3, но это хуже, т.к тогда утратится совместимость. Кстати, и остальные (т.е вне экранного буфера) 48 кб из 565 РУ5 на плате граф.адаптера можно использовать. Их можно включить в то окно диспетчера, которое используется лишь для целей эл.диска, где скорость доступа не играет особой роли.

Я не хотел делать прошиватель 556 РТ4 и 155 РЕ3, т.к нельзя заменить иришину карту памяти не потеряв совместимости с огромным количеством, когда-то существовавших (хотя возможно лишь в параллельном мире) классных игр уровня ZX-Spectrum для ИРИШИ. Но теперь понятно, что для полного избавления от тормознутости, разумно перепрошить 556 РТ4, т.е прошивку реализующую логику дешифратора на плате граф.адаптера.

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

Естественно, даже при наличии безтормозного ОЗУ для хранения программ, доступ в экранный буфер на плате граф.адаптера будет происходить с торможением тактами WAIT, как и ранее. Однако это уже вовсе не фатально. Во-первых, программа реального времени для чтения с МГ-ленты не работает из экранного ОЗУ. Во-вторых, обращения в экран происходят относительно редко. Даже в сами моменты вывода на экран программной петлёй в среднем лишь одна команда из ~десятка делает обращение собственно в экран, т.е примерно из 20-25 маш.тактов только один приходится на доступ к ОЗУ экрана. Т.о даже сам непосредственный процесс вывода на экран тормознётся всего лишь на ~5%, что нас не особо опечалит.

На плате граф.адаптера применены ОЗУ 565 РУ5 на такте 2 МГЦ. Но, как показывает практика, они без всяких проблем и даже без излишнего перегрева тянут такт /RAS-/CAS в 4 МГЦ (в клонах ZX работают на 3.5 МГЦ и никто даже не жаловался). Таким образом, теоретически, даже параметры применённых в оригинальной плате граф.адаптера ИРИШИ, антикварных деталей позволяют переконструировать графический адаптер ИРИШИ, сделав прозрачный доступ к ОЗУ в режиме 1 и торможение всего на 10-15% в режимах 2 и 3.

Естественно, в наше время уже не осталось настолько грамотных инженеров аппаратчиков, как разработчики ИРИШИ. Потому сейчас просто некому переработать плату граф.адаптера ИРИШИ. Хотя, если это сделать применив DIP-статику, то можно не только убрать торможение и резко сократить число деталей, но и добавить цвет в режим моно-640*200. У современных людей из-за отравленной экологии и ГМО, уровень IQ понизился настолько, что теперь никто даже не в состоянии понять, как работает схема граф.адаптера ИРИШИ, и всё, на что им хватает ума, - это запихать ту же схемотехнику в какой-нибудь мощный контроллер типа AVR или STM32, но это уже другое хобби.

Никто не пытался мультиплексоры 555(531)КП2 поменять на 1533КП12. Логика работы вроде такая же. Вот только разница в быстродействие может быть критична

Microsha пишет:Никто не пытался мультиплексоры 555(531)КП2 поменять на 1533КП12. Логика работы вроде такая же.

КП2 не всегда можно заменять на КП12. Например, в видеовыходе ОРИОНА нельзя, т.к там на вход /CS КП2 подаётся сигнал BORDER и используется факт, что у КП2 при её запрете на выходе 0, что и требуется для гашения луча во время его обратного хода.

Отличие КП12 от КП2, во-первых, в том, что КП2 обнуляет выходы при запрете (а КП12 при запрете наоборот освобождает свои выходы переводя их в третье состояние), а во-вторых, выходы КП12 рассчитаны на 50 TTL-входов, тогда как выходы КП2 рассчитаны, как и все TTL-микросхемы без 3-го состояния, на нагрузку всего лишь в 20 входов. Т.е выходы КП12 мощнее и потому лучше работают в скоростных схемах.

В адресных мультиплексорах платы видеоадаптера ИРИШИ входы /CS заземлены, потому там без разницы - КП2 или КП12 (но как упомянуто выше, КП12 ставить всегда лучше). А вот в качестве D44, раз в ней /CS не заземлены, правильно ставить именно КП2. Но у меня на двух платах видеоадаптера почему-то (явно сдуру) и в качестве D44 стоят КП12, но всё работает.

На моих платах видеоадаптера (спаянных ещё в 1988 году) вместо всех микросхем 155-той и 555-той серий изначально были применены 1533 аналоги. А из 531 серии оставлены 531-ой только ИР19, ЛА1, ЛА3 и ТВ10. Вместо 531ИР18 я ставил 1533ТМ9, т.к регистра ИР18 в 1533 серии не производилось, а схема позволяет замену. Несомненно и эти ИМС 531 серии можно в ИРИШЕ заменить на маложрущие импортные скоростные аналоги.

Кстати, и на моей плате ЦП тоже все ИМС 155/555 серий кроме ЛП10/ЛП11 заменены на 1533 (замена ТТЛ на ТТЛШ в грамотно спроектированных схемах, т.е в схемах, где нет "гонок сигналов", всегда возможна и выгодна). ЛП10/11 пришлось применять 155-той серии, т.к в 555-той серии их не смог найти (вероятно они вообще не производились в СССР). Хотя их тоже разумно заменить на 555 (если они есть) или 74LS. Сейчас импортные аналоги 74LS365/367 доступны. Такая замена вполне возможна, например, в Apple-II в качестве таких же буферов адреса стоят 74LS365, а нагрузка шины там не меньше. Вместо 176ТМ1 в плате ЦП я ставил 561ТМ2, т.к 176-туя серию при питании 5 вольт применять неправильно, она рассчитана на 9 вольт, а для 561-й серии это нормально, она работает с 3-х вольт.

В ИРИШЕ с базовым кварцем (т.е с клоком CPU всего в 1.77 МГЦ) и всей мелко-логикой на 1533 серии думаю, что и буфера D27, D28, D29 ставить не обязательно (вместо них запаяв перемычки). В ОРИОНЕ на Z80 я без проблем заменял адресные буфера ВА86/ИР82 перемычками, от этого надёжность только повышалась, а токо-потребление резко падало.

Кстати, резисторы подвязки сигналов магистрали (т.е на магистрали на ШД и сигналах управления резисторы 470 и 330 Ом на землю и +5В) поставлены предположительно для повышения помехозащищённости (и полезны лишь при подключении плат через плату удлинителя магистрали, что удлиняет цепи магистрали и добавляя паразитные ёмкости). Но думаю, что и без них будет прекрасно работать, а 589АП16 даже станут меньше греться.

Лично я не пытался, не вижу смысла. Во-первых они у меня есть, свободно заказал в магазине где покупаю микросхемы, во-вторых, ну не дефицит это сейчас, либо есть в наличии, и для меня, например, это подождать доставку 15 суток максимум, либо можно под заказ привезти и тогда 1 месяц. Даже сейчас посмотрел, и...

В одном магазине, есть в наличии:

К555КП2 --- 800 шт. --- 18.27 руб. (то есть если заказать, то через 2 недели будут на месте)

Во втором, 108 шт. со склада г.Москва, срок 1-2 недели

К555КП2 --- 108 шт. --- 23 руб. (от 2 шт. — 16 руб.; от 4 шт. — 14 руб.)

К тому же у предложенных вами имеется возможность перевода в высокоимпедансное состояние, то есть дополнительный вывод управления им и придётся кидать провода.
Также они потребляют больше, например, К555КП2 - (P_ср = 55 мВт (11 мА)) и КР1533КП12 - ((P_ср = 70 мВт (14 мА)), так в чём смысл...
По быстродействию, они конечно имеют задержку распространения в 2 раза меньшую 15 нс, против 33 нс, но опять же а смысл.
Ну и ещё нужно смотреть параметры КР565РУ5 которые будут применяться, какие у них входные токи при лог. 0 и лог.1, так как каждый выход будет нагружен 8-ю входами, тут думаю всё будет с этим в порядке, но нужно проверять, сейчас лень.

Вывод:  лично я, не вижу смысла заменять!


И по поводу КР531 серии, она очень много потребляет, а соответственно как следствие даёт много помех, а К555 серия, самая чувствительная к помехам, поэтому крайне не желательно применять эти серии совместно.

а во-вторых, выходы КП12 рассчитаны на 50 TTL-входов

Вы ошибаетесь, серия КР1533 имеет N = 40 только для входов этой же серии КР1533, для К555 серии N уже будет равен 20, а для К155 серии итого 5.
Но, дискутировать по этому поводу не буду, любой справочник можно открыть и посмотреть.

Viktor2312 пишет:Лично я не пытался, не вижу смысла. Во-первых они у меня есть, свободно заказал в магазине где покупаю микросхемы, во-вторых, ну не дефицит это сейчас, либо есть в наличии, и для меня, например, это подождать доставку 15 суток максимум, либо можно под заказ привезти и тогда 1 месяц.

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

Microsha пишет:Так я вроде и не утверждал что КП2 - дефицит.

Так я как вроде, тоже особо и не напирал, на то, что вы утверждали, что это дифицит, так в общем контексте сообщения, уточнил.

Ну, а раз хотите экспериментировать, так вперёд, творчество - это хорошо. Как я мельком глянул на схему, то выходы нагружены только адресными входами микросхем ОЗУ К565РУ5, так что ничего криминального по нагрузке нет как вроде, хотя желательно уточнить какой входной ток у этих входов в состоянии лог.0 (I⁰_вх). И убедиться, что общий ток не будет превышать 8 мА. По схеме на каждый выход подсоединено 8 входов, ну а по быстродействию вообще не вижу проблем, ну будет адрес появляться на 18 нс. быстрее и всё, ну и с выводами 1, 15 вообще не нужно ничего делать, они в состоянии лог.0, а значит НЕ в высокоимпедансном состоянии. И цоколёвка в остальном совпадает. Попробуйте, должно всё работать.

Viktor2312 пишет:так что ничего криминального по нагрузке нет как вроде, хотя желательно уточнить

Если 1533КП12 в ОРИОНЕ на Z80 при такте /RAS-/CAS в 5 МГЦ прекрасно тянули 4 банки РУ5, то уж всего одну банку РУ5 на частоте 2 МГЦ явно потянут. Но вот D44 всё-равно лучше как указано в оригинале ставить именно КП2, не КП12. Хотя у меня с D44= КП12 всё работало лет десять (по крайней мере в монохроме), но потом плата сдохла и до сих пор не починил (по счастью имелись запасные платы).

Viktor2312 пишет:я не пытался, не вижу смысла... они потребляют больше... не вижу смысла заменять!

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

Как раз, чтобы не надрываться с изготовлением отдельного корпуса клавиатуры и отдельного системного блока в форме кирпича с вертикальным расположением плат, удобно использовать корпус "Корвета" (или клонов). Он же одновременно и корпус клавиатуры, а 2-3 платы ИРИШИ горизонтально и даже винт или дисковод там вполне умещаются.

Кстати, ИРИША похоже, не критична к деталям и работает даже, если всё, что возможно 555-той серии в ней заменить на более дешёвую и доступную 155-тую серию. Я видел такие платы работающими в конце 80-тых. Так что, то из деталей, что есть в наличии, то и следует ставить. Но при необходимости закупки уже нет никакого смысла закупать 155-тую и 555-тую серии, - 1533 серия доступнее и лучше по всем параметрам ? А если планируется повысить такт CPU, то желательна как раз 1533 серия (можно применить также современные скоростные КМОП-аналоги TTL-серий, хотя они стоят дороже).

Viktor2312 пишет:по поводу КР531 серии, она очень много потребляет, а соответственно как следствие даёт много помех, а К555 серия, самая чувствительная к помехам, поэтому крайне нежелательно применять эти серии совместно

Авторы ИРИШИ этого не знали и применяя в основном 555-тую серию, там где самые высокочастотные сигналы поставили 531-ю серию (т.к 1533 серия в 1984 году ещё не выпускалась). Скорее всего и при замене шести оставшихся корпусов 531 серии на 1533 серию тоже всё будет работать. У меня эти микросхемы запаяны, - желательно, чтобы тот, у кого эти микросхемы на панельках, это проверил. Если замена шести корпусов 531 серии на 1533-ю серию возможна, то это с'экономит огромное количество электроэнергии.

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

Прекрасно, но не вижу проблем, вообще, любой перегрев решается радиаторами на конкретную микросхему и активным охлаждением, 1 вентилятор на вдув, например 120 х 120 мм и можно дополнительно один на выдув, и никаких проблем с теплом, для устранения пыли можно и фильтр добавить, для уменьшения шума, если вдруг кто-то про него вспомнит, можно питать пониженным напряжением, не 12 В, а на 30 % меньше, например, так что - пустое это всё...

Как раз, чтобы не надрываться с изготовлением отдельного корпуса клавиатуры и отдельного системного блока в форме "кирпича" с вертикальным расположением плат, удобно использовать корпус "Корвета" (или клонов). Он одновременно и корпус клавиатуры, а 2-3 платы ИРИШИ горизонтально и даже винт или дисковод там вполне умещаются.

Это уже каждый сам решает, какой конструктив применить, и как кому удобно...

Кстати, ИРИША похоже, не критична к деталям и работает даже, если всё, что возможно 555-той серии в ней заменить на более дешёвую и доступную 155-тую серию. Я видел такие платы работающими в конце 80-тых. Так что, что из деталей есть в наличии, то и следует ставить. Но при необходимости закупки уже нет никакого смысла закупать 155-тую и 555-тую серии, - 1533 серия доступнее и лучше по всем параметрам ?

Не лучше она по всем параметрам, нужно смотреть на конкретный экземпляр, как видим те же К555КП2 и КР1533КП12 последняя потребляет больше, или например ЛА1, по потреблению только чуть меньше 1 мА потребляет, не большой выигрыш, а по быстродействию 2 нс всего, а вот по нарузочной способности К1533, такая же как К555 серия или в два раза меньше, чем у К155 серии 8 мА против 16 мА. Так что нужно смотреть и сравнивать конкретные экземпляры и на схему смотреть. А ваша панацея, что вот только К1533, а остальное всё не то, лично мне уже надоела, да К555 серия более доступна и дешевле.
Но по сути, всё это уже давно устаревшая и очень медленная электроника.

Авторы ИРИШИ этого не знали и применяя в основном 555-тую серию, там где самые высокочастотные сигналы поставили 531-ю серию...

Всё они прекрасно знали и думаю поболее знали моих и ваших знаний вместе взятых.

и еще вопрос по плате графического модуля. С основного разъема идут два сплетенных провода обозначенных CLC до микросхем D37, D38. Чем вызвано такое решение? Плотной трассировкой платы? Забыли развести? Или сплетенный кабель обеспечивает лучшую помехозащищенность?

Microsha пишет:два сплетенных провода обозначенных CLC... Чем вызвано такое решение?

Разработчики ИРИШИ уже недоступны, спросить не у кого. Потому каждый может для себя придумать своё объяснение в меру своих знаний и опыта.

Вероятно это сделано для того, чтобы уменьшить электро-магнитное излучение, т.к в этой цепи мощный меандр (с выхода буфера) самой высокой в схеме частоты 16 МГЦ. Т.к прямоугольный сигнал содержит огромное число гармоник с высокой амплитудой, то даже неэкранированный проводок длиной в 30 сантиметров работает как антенна, сильно излучает и создаёт радиопомехи во всех диапазонах.

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

Это витая пара, по ней передаётся тактовая частота.

обеспечивает лучшую помехозащищенность?

Можно и так сказать...

Доброго времени суток!

Хотел узнать ваше мнение по модулю графического контролера.
Что если заменить D49-D51, D55, D56, D37.4, D43.4, D43.3, D46.1, D46.2, Одной микросхемой LM1882 (74ACT715)
Datasheet

Или CD22402

Хотел узнать ваше мнение по...
Что если заменить...

Лично моё мнение. Зачем, там всё сделано идеально. Но, если у вас хватит знаний это сделать, и оно будет работать, почему бы и нет. Возможно такое решение кому нибудь и когда нибудь и пригодится. А вот насчёт возможно это или нет, я если честно не хочу заморачиваться и читать datasheet, я глянул микросхемка интересная, но я не сторонник пхать в Иришу всякие импортные непотребства, но в том плане, что я делаю для себя лично, так, по возможности без импорта. А другие для себя могут делать что угодно, лишь бы работало.