Май 2019
ПнВтСрЧтПтСбВс
  12345
6789101112
13141516171819
20212223242526
2728293031  

Календарь Календарь

Последние темы
» Эмулятор радио 86рк
автор parsec Вчера в 18:44

» Эмулятор ИРИШИ для тех, кто не имеет её реальной
автор barsik Вчера в 18:38

» Новинки. Книги. Часть 1.
автор Viktor2312 Вт Май 21 2019, 16:21

» Программирование для ИРИШИ
автор barsik Пн Май 20 2019, 21:14

» Новинки. Книги. Часть 3.
автор Viktor2312 Пн Май 20 2019, 16:38

» Модуль контроллера графического дисплея (МКГД).
автор barsik Вс Май 19 2019, 13:40

» ATM Turbo 2+ v7.10
автор alemorf Сб Май 18 2019, 20:03

» Схемы и документация на отечественные ЭВМ и ПЭВМ и комплектующие
автор Viktor2312 Сб Май 18 2019, 18:10

» Куплю микросхемы КР1818ВГ93 и КМ1810ВТ3.
автор Savoj Чт Май 16 2019, 07:51

» Радио-86РК: Расширение ОЗУ
автор barsik Чт Май 16 2019, 01:26

» Клавиатура ИРИШИ
автор barsik Ср Май 15 2019, 16:57

» ИРИША и магнитофон
автор barsik Пн Май 13 2019, 04:23

» Новости криптовалют: статьи, заметки, разное...
автор Viktor2312 Сб Май 11 2019, 03:01

» Жалобы/пожелания по работе форума
автор Viktor2312 Сб Май 11 2019, 00:50

» Альтернативные КНГМД для ИРИШИ
автор barsik Пт Май 10 2019, 01:12

» Видеокарты (GPU). Статьи, заметки, очерки, разное...
автор Viktor2312 Чт Май 09 2019, 19:55

» Алгоритм SHA-256 и др., хеш (hash), хеширование, майнинг.
автор Viktor2312 Чт Май 09 2019, 01:30

» Обсуждение желаемых новодельных плат расширения и мелких усовершенствований базовых плат
автор barsik Ср Май 08 2019, 16:06

» Разное
автор Viktor2312 Вт Май 07 2019, 19:19

» Для новичков (криптовалюта).
автор Viktor2312 Вт Май 07 2019, 17:32

» Ассемблер для современных CPU Intel.
автор Viktor2312 Вт Май 07 2019, 17:12

» МКНГМД Вариант-3. Версия на К1818ВГ93
автор barsik Вт Май 07 2019, 15:15

» Обзор крипто проектов.
автор Viktor2312 Вт Май 07 2019, 12:57

» 7 Мая. День Радио!
автор Viktor2312 Вт Май 07 2019, 12:00

» "Радио-86РК". Статьи, заметки, очерки, разное...
автор barsik Сб Май 04 2019, 20:20

Самые активные пользователи за месяц
Viktor2312
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
barsik
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
alemorf
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
demetrius2003
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
a.oleg.a
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
parsec
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
Savoj
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 
VladimirS
Модуль контроллера графического дисплея (МКГД). - Страница 2 Vote_lcapМодуль контроллера графического дисплея (МКГД). - Страница 2 Voting_barМодуль контроллера графического дисплея (МКГД). - Страница 2 Vote_rcap 

Поиск
 
 

Результаты :
 


Rechercher Расширенный поиск


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

Страница 2 из 2 Предыдущий  1, 2

Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Вс Ноя 20 2016, 17:27

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

№11:

С Я.Картинки у KokaF77:
Модуль контроллера графического дисплея (МКГД). - Страница 2 0_6c23f_c93522be_L

Ещё (копия):
Модуль контроллера графического дисплея (МКГД). - Страница 2 0_1a8161_f4b86401_L
Viktor2312
Viktor2312
Гуру+

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Вс Ноя 20 2016, 17:27

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

№12:

С Я.Картинки у KokaF77:
Модуль контроллера графического дисплея (МКГД). - Страница 2 0_6c240_8fbb9f5a_L

Ещё (копия):
Модуль контроллера графического дисплея (МКГД). - Страница 2 0_1a8166_f495c1e8_L
Viktor2312
Viktor2312
Гуру+

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Пт Ноя 25 2016, 01:37

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

Работа с модулем контроллера графического адаптера (МКГД).

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

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

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

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ed8_d28b41d5_L
006

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

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

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

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ed9_b5acd768_L
007

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

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

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

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

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

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55edc_fde13e81_L
008

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55edd_4a35fa5b_L
009

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ede_ecaae710_L
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 (инверсный).

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee0_ef279bc5_L
011

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

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

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

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

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee1_264100f3_L
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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee2_c8f3f432_L
013

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

O24,D9

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee3_760ec01d_L
014

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

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

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee6_f6f1781c_L
015

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee7_a6abef37_L
016

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

Модуль контроллера графического дисплея (МКГД). - Страница 2 0_55ee8_c432cfd_L
017

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

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Пт Ноя 25 2016, 01:43

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

Кстати, да, 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 выключить экран (вроде бы)
дальше то же
Viktor2312
Viktor2312
Гуру+

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Сб Янв 21 2017, 11:43

30
резерв.
Viktor2312
Viktor2312
Гуру+

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty .

Сообщение  barsik в Пн Фев 04 2019, 04:04

31
Фотографии схем хорошо бы отфотошопить. Удобнее всего простым пакетом 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. Как видите в ИРИШЕ есть много способов увеличить ОЗУ для того, чтобы поиметь электронный диск.

_________________
***
barsik
barsik
Мастер+

Сообщения : 458
Дата регистрации : 2016-11-10
Откуда : С-Петербург

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty .

Сообщение  barsik в Пн Фев 04 2019, 13:38

32
чтобы посмотреть содержимое сист.регистров воспользуемся командой 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.


Последний раз редактировалось: barsik (Пн Фев 04 2019, 14:57), всего редактировалось 1 раз(а)
barsik
barsik
Мастер+

Сообщения : 458
Дата регистрации : 2016-11-10
Откуда : С-Петербург

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Пн Фев 04 2019, 14:35

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

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

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty .

Сообщение  barsik в Ср Апр 03 2019, 09:00

34
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).

_________________
***
barsik
barsik
Мастер+

Сообщения : 458
Дата регистрации : 2016-11-10
Откуда : С-Петербург

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Ср Апр 03 2019, 14:23

35
Третьим параметром искейп-команды передаётся так называемый "байт управления" (рисунок 9.13).


Модуль контроллера графического дисплея (МКГД). - Страница 2 092_0010


.
Viktor2312
Viktor2312
Гуру+

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty .

Сообщение  barsik в Пн Апр 29 2019, 00:16

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

Мне тут пришла в голову мысль, что текст на экране ИРИШИ в режиме 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

_________________
***
barsik
barsik
Мастер+

Сообщения : 458
Дата регистрации : 2016-11-10
Откуда : С-Петербург

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Viktor2312 в Вт Май 07 2019, 11:33

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

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

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

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


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


Модуль контроллера графического дисплея (МКГД). - Страница 2 0_7ecac_a165360e_L
МКГД_ver1.0






.

_________________
"ЛП & ТИ"
Viktor2312
Viktor2312
Гуру+

Сообщения : 11568
Дата регистрации : 2012-08-10
Возраст : 40
Откуда : Пятигорск

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty .

Сообщение  barsik в Вс Май 19 2019, 13:40

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

А техническим языком можно говорить о том, что в иришиной плате граф.адаптера применён самый неудачный принцип синхронизации обращений к ОЗУ видеочасти и процессора, худший, чем аналогичный принцип синхронизации использованный в последующих моделях отечественных 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, но это уже другое хобби.

_________________
***
barsik
barsik
Мастер+

Сообщения : 458
Дата регистрации : 2016-11-10
Откуда : С-Петербург

Посмотреть профиль

Вернуться к началу Перейти вниз

Модуль контроллера графического дисплея (МКГД). - Страница 2 Empty Re: Модуль контроллера графического дисплея (МКГД).

Сообщение  Спонсируемый контент

39

Спонсируемый контент


Вернуться к началу Перейти вниз

Страница 2 из 2 Предыдущий  1, 2

Вернуться к началу


 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения