Да я вроде понимаю. Но тогда у нас на замену чёрному будут довольно тёмные цвета. 3бита на компоненту дадут 1/8=32/256 интенсивности, А какой-нибудь #200000 вполне заменит чёрный.
Хотя сейчас я тоже гляжу, овчинка врядли стоит выделки.
Да я вроде понимаю. Но тогда у нас на замену чёрному будут довольно тёмные цвета. 3бита на компоненту дадут 1/8=32/256 интенсивности, А какой-нибудь #200000 вполне заменит чёрный.
Хотя сейчас я тоже гляжу, овчинка врядли стоит выделки.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Один из битов яркости задается для всей строки (это бит определяющий палитру), а один из битов индивидуально для выбранного цвета.Сообщение от Keeper
Биты P0-P2 берутся из регистра отображения, а бит Y задается в регистре цвета. Регистр цвета задает какие сигналы Y и PL0-PL2 будут выдаваться при заданной комбинации битов в битпланах. Через регистры цвета можно сделать так, что независимо от состояния битпланов все время будет высвечиваться яркий белый.Не понял сути постабиты управления яркостью (Y, P0-P2) задаются на строку и берутся из регистра, биты непосредственно RGB (PL0-PL2) берутся из битпланов (памяти) Где я не прав?
Белый только в нулевой и седьмой палитре (серый и белый).
Ну если так, то яркий белый должен быть в седьмой палитре (при неинвертированной яркости). А в данном случае я хотел сказать, что биты в битпланах не задают значения сигналов RGB, а задают номер тетрады в регистре цвета, из которого значения сигналов YRGB и выбираются.
Ну да) Биты в битпланах выбирают 8 из 16 цветов одной из 8 палитр. Палитра фиксирована для одной строки (если не используются специальные ухищирения для записи в регистр палитры в середине строки, при условии, что регистр палитры существует).
Я уже писал ранее, что регистры цвета и отображения считываются во время обратного хода луча по кадру и их изменение в середине строки не имеет смысла.
Теперь по поводу существования регистров в диапазоне 177030-177052, описанных в старой документации. Да, в нынешних версиях УКНЦ этот диапазон откликается на запись, но при чтении происходит TRAP4.
Ну а теперь взглянем на схему УКНЦ - адресным пространством ПП управляет БМК 1515ХМ1-032. Именно в ней расположены регистры из диапазона 177010 - 177054. При обращении к регистрам адреса/данных и спрайтовому механизму она через линии RQ,CC0,CC1 управляет видеоконтроллером 1515ХМ1-033, который в свою очередь имеет доступ ко всему ОЗУ и при необходимости передает/получает данные от 1515ХМ1-032. В тоже время видеоконтроллер 1515ХМ1-033 имеет доступ ко всему ОЗУ, но не имеет доступа к шине адреса-данных, и поэтому не может прочесть их из адресного пространства. Можно предположить, что он может запросить их значение через линии RQ,CC0,CC1, но однако запрашивать он их будет только во время обратного хода луча. С другой стороны 1515ХМ1-032 при записи в эти регистры может по линиям RQ,CC0,CC1 известить 1515ХМ1-033, но тоже в это не верится.
К тому же формат общения по линиям RQ,CC0,CC1 неизвестен. Могу только предположить, что по линиям CC0,CC1 выставляется код запроса, а по линии RQ запускается запрос.
Keeper, нам ничто не мешает рассмотреть pl0, y и p0 как 3 бита. Другое дело, что результат получится хоть и цветастый, но неудобный. Так что бесперспективняк =)
---------- Post added at 23:02 ---------- Previous post was at 22:46 ----------
036? У меня на обоих схемах 036.
Ммм, а как это? DC0-15 и DG0-7 это получается локальная шина между матрицами для видео данных?
Как кстати расшифровываются эти CC, DC, DG, CCM, CGM и CSM?
Да, я пользовался старым вариантом документации - там видеоконтроллер 1515ХМ1-033, а в текущей документации (как и компьютерах) стоит 1515ХМ1-036 (или 1515ХМ1-136).
Работа этих БМК частично описана в ПК УКНЦ № 1-95.
С денди вообще неплохо переносится, но приходится дорисовывать, особенно более тёмные цвета.
На всякие статусы хорошо идёт отдельная палитра.
А вот на игровом поле приходится экономить =\
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
