Просмотр полной версии : Вектор-06Ц: Эмуляция цветовой палитры
Нужна либо адекватная картинка со всеми 256 цветами , либо палитра в фотошёпских попугаях примерно в таком виде -
(MSX SCREEN 8)
_R____G____B__
255__255__255
219__219__xxx
182__182__xxx
146__146__146
109__109__xxx
_73___73___73
_36___36___xx
__0____0____0
fan, целиком схема есть здесь
http://sensi.org/%7Esvo/scalar/ware/514/
Какая цель преследуется, если не секрет?
Я не представляю как эту колбасу из резюков перевести в адекватные значения %)
Может создатели эмуляторов поделятся ?
Палитратра нужна для рисовательства в фотошёпе и т.п. , ибо некоторые цвета при такой спецефической палитре несколько безбашенные чтоб просто что-то нарисовать первыми попавшимися цветами а потом сконвертить .
Кстати в природе есть какиенить конвертилки картинок ?
Добавлено через 18 минут
Вобщем помучил эмуль VirtualVector_574 , получилось так -
вектор
_R____G____B__
252__252__252
220__220__xxx
192__192__188
164__164__xxx
136__136__124
104__104___xxx
_76___76___xx
__0____0____0
Добавлено через 50 минут
Странно как-то вышло , по моему уровни компоненты синего должны быть равны кратным значениям R/G , ибо резюки на на младших битах одинаковые и уровень синего 252 недостижим впринципе .
________R____G____B__
7_111__252__252__xxx
6_110__220__220__220
5_101__192__192__xxx
4_100__164__164__164
3_011__136__136__xxx
2_010__104__104___104
1_000__76___76___xx
0_000___0____0____0
Ща глянул палитру вектора в эмуле VirtualVector_574 , значение компоненты синего чёто совсем не кратны значениям компонент красного и зелёного , хотя по схеме должны быть кратны ( http://zx.pk.ru/showthread.php?t=9992 ).
Делал я конвертер в 2000 (а может в 2003) году. Сначала сделал так: R и G шаг 36, множитель 0-7; B - шаг тоже 36, множители 0,2,4,6. На реале не проверял, но в эмуляторе Романа Пантелеева конверснутые картинки с белым цветом смотрелись не очень. Переделал B - шаг 84, множители 0-3, в эмуляторе ve картинки стали выглядеть лучше. Первоначальный вариант был ближе к схеме (если я ее правильно понимаю), второй был лучше для эмулятора ve, а как нужно на самом деле - не знаю.
Вот значения в моем эмуляторе:
Const
RG : array [0..7] of byte=(0,19,26,34,41,48,55,63); // Красный, Зеленый
BL : array [0..3] of byte=(0,31,47,63); // Синий
Var
PallTable: Array [0..255, 0..2] of Byte;
B,G,R,k:Byte;
Расчет таблицы палитры:
for B:=0 to 3 do
for G:=0 to 7 do
for R:=0 to 7 do
Begin
k:=B*64+G*8+R;
Palltable[k,0]:=RG[R]*4;
Palltable[k,1]:=RG[G]*4;
Palltable[k,2]:=BL[B]*4;
end;
RG : array [0..7] of byte=(0,19,26,34,41,48,55,63); // Красный, Зеленый
BL : array [0..3] of byte=(0,31,47,63); // Синий
А почему значения компоненты синего не кратны значениям R/G как в схеме ???
Тогда уж и BL : array [0..3] of byte=(0,26,41,55)
Добавлено через 1 минуту
Делал я конвертер в 2000 (а может в 2003) году.
Он случием не сохранился ?
Сохранился, просто не очень хотелось выкладывать, т.к. программка слабоватая, хотя регулярно (раз в два года) я что-нибудь в нем (или в ней?) подкручивал.
Удалил вложение, т.к. SPRView теперь выложен в картотеке SPRView (http://sensi.org/%7Esvo/scalar/ware/720/)
А почему значения компоненты синего не кратны значениям R/G как в схеме ???
Тогда уж и BL : array [0..3] of byte=(0,26,41,55)
Добавлено через 1 минуту
Он случием не сохранился ?
Потому что, при значении 255 должен быть как мне кажется белый цвет, а не желтый. Я у себя помню перепаивал эти резюки, чтобы картинка не отдавала желтизной.
У меня:
0,50,90,130,165,195,225,255 - R G
0,90,180,255 - B
Скажу сразу - значения брал от балды, чтобы яркость более-менее равномерно увеличивалась.
Потому что, при значении 255 должен быть как мне кажется белый цвет, а не желтый. Я у себя помню перепаивал эти резюки, чтобы картинка не отдавала желтизной.
Так и должно быть (ибо великие схемотехники старались :D ). И на каждом компе именно так (не переделывать же их :D ). При одинаковых уровнях 6_110__220__220__220 как раз всё нормально .
А при изменённых значениях оттенки серого уходят в желтизну (неговоря уже про остальные комбинации оттенков).
В эмуляторе надо тогда хотя бы приделать возможнось подстраивать палитру (или что наверное проще выпустить эмулятор с правильной палитрой).
Сохранился, просто не очень хотелось выкладывать, т.к. программка слабоватая, хотя регулярно (раз в два года) я что-нибудь в нем (или в ней?) подкручивал.
Сенькью ! Щаз заценим :D
Конвертилка просто прелесть . Но у меня хавает только гифы сделанные через экспорт GIF98a . BMP , PCX , PNG и гифы сдеградированные до требуемого размера и цветности (в фотошёпе) не хаваются .
Мнеб ещё версию с правильной компанентой синего :)
В аттаче правильная палитра , далее вариант картинки под цвета из этой палитры , а третья картинка то что пулучилось :(
BMP , PCX , PNG и гифы сдеградированные до требуемого размера и цветности (в фотошёпе) не хаваются .
Можно на примеры взглянуть? У меня таких проблем не было, иначе бы я поправил (по крайней мере попытался бы).
Добавлено через 7 часов 10 минут
Добавил возможность выбора "эмуляторной"/"реальной" палитры и выложил в картотеку
SPRView (http://sensi.org/%7Esvo/scalar/ware/720/)
BMP, PCX и PNG, которые у меня есть, по-прежнему нормально открываются и показываются. Если будут "проблемные", попытаюсь разобраться.
С траблой при открытии файлов отчасти разобрался , просто при деградации картинки под 16цветную палитру нужно было повторно передеградировать под 4 бита %) Иначе судя по всему оно сохранялось как 8бит .
Но PCX и PNG всё равно не открываются (закинул в аттач).
При конверсии опять какой то косяк :( Подогнаная под правильную палитру картинка получается чертекак %(
Уровни компонент соответствуют этому? -
________R____G____B__
7_111__252__252__xxx
6_110__220__220__220
5_101__192__192__xxx
4_100__164__164__164
3_011__136__136__xxx
2_010__104__104___104
1_000__76___76___xx
0_000___0____0____0
Ещё баг обнаружил - если открытую картинку в песюковом формате сразу конвертнуть в песюковый формат , то палитра не меняется . Чтоб поменялась нужно принудительно ченить щёлкнуть в Scale Factor .
Но PCX и PNG всё равно не открываются (закинул в аттач).
эти pcx и png - 8 битные.
Приложил их же, но конверснутых в 4 bpp, так открываются
Удалил в связи с потерей актуальности
Уровни компонент соответствуют этому? -
________R____G____B__
7_111__252__252__xxx
6_110__220__220__220
5_101__192__192__xxx
4_100__164__164__164
3_011__136__136__xxx
2_010__104__104___104
1_000__76___76___xx
0_000___0____0____0
нет, использованные в SPRView уровни расписаны в readme.txt:
масштабирующий множитель для синей компоненты
Emulator - 84 (PCшные значения синей компоненты - 0, 84, 168, 252)
Real - 73 (PCшные значения синей компоненты - 0, 73, 146, 219)
Для красной и зеленой компоненты масштабирующий множитель всегда 36 (PCшные значения - 0, 36, 72, 108, 144, 180, 216, 252).
Перечисленные в скобках значения уровней используются при переводе Vector->PC.
Границы уровней, используемые на данный момент в SPRView при переводе PC->Vector:
B(Emulator):0-41->0; 42-125->1; 126-209->2; 210-255->3
B(Real):0-36->0; 37-109->1; 110-182->2; 183-255->3
R и G:0-17->0; 18-53->1; 54-89->2; 90-125->3; 126-161->4; 162-197->5; 198-233->6; 234-255->7
В принципе, могу сделать версию Special for fan, но хотелось бы узнать, как вышеприведенные уровни получены? (я не понял принципа их расчета). Кроме того, приведенной таблички хватит для перевода Vector->PC, но не наоборот, мне нужно знать желаемые границы PCшных уровней при переводе.
Ещё баг обнаружил - если открытую картинку в песюковом формате сразу конвертнуть в песюковый формат , то палитра не меняется . Чтоб поменялась нужно принудительно ченить щёлкнуть в Scale Factor .
Хм, а в чем тут баг? Если мы записываем не в векторовском формате и не трогали Scale Factor, то зачем трогать палитру?
эти pcx и png - 8 битные.
Приложил их же, но конверснутых в 4 bpp, так открываются
4bit_pcx&png_SARAH.rar
Похоже фотошёп дремучит (я в пятом мучую).
А эти четырёх битки как получены ?
Хм, а в чем тут баг? Если мы записываем не в векторовском формате и не трогали Scale Factor, то зачем трогать палитру?
Хэзэ , я так понял что полюбому конвертится . Например намолевал чёрте как в фотошёпе , прогнал через конвертилку и она всё под "стандарт" подправила .
В принципе, могу сделать версию Special for fan, но хотелось бы узнать, как вышеприведенные уровни получены? (я не понял принципа их расчета). Кроме того, приведенной таблички хватит для перевода Vector->PC, но не наоборот, мне нужно знать желаемые границы PCшных уровней при переводе.
Эти урувни непосредственно из эмулятора (со скриншёта с чистыми уровнями) + подправленный как надо синий . Именно такими они выглядят в фотошёпе (соотв из комбинации оных и складывается палитра http://zx.pk.ru/attachment.php?attachmentid=11623&stc=1&d=1239838620 ) .
Emulator - 84 (PCшные значения синей компоненты - 0, 84, 168, 252)
Real - 73 (PCшные значения синей компоненты - 0, 73, 146, 219)
Для красной и зеленой компоненты масштабирующий множитель всегда 36 (PCшные значения - 0, 36, 72, 108, 144, 180, 216, 252).
Ну это уж совсем нечему не соответствует %) Ибо то что творится в эмуле я вывалил в третьем посте .
Перечисленные в скобках значения уровней используются при переводе Vector->PC.
Границы уровней, используемые на данный момент в SPRView при переводе PC->Vector:
B(Emulator):0-41->0; 42-125->1; 126-209->2; 210-255->3
B(Real):0-36->0; 37-109->1; 110-182->2; 183-255->3
R и G:0-17->0; 18-53->1; 54-89->2; 90-125->3; 126-161->4; 162-197->5; 198-233->6; 234-255->7
Короче не то , тому что творится в эмуле не соответствует .
Наверное действительно проще сделать несколько вариантов чем уговаривать ALL прийти к общему стандарту %)
Было бы ооочень здорово добавить какойнить настройщик уровней компонент . Хотя бы в виде текстового файла (или ваще бинарника).
А эти четырёх битки как получены ?
через IrfanView
Было бы ооочень здорово добавить какойнить настройщик уровней компонент . Хотя бы в виде текстового файла (или ваще бинарника).
Сделал (загрузка уровней цветов из текстового файла), немного потестирую и выложу.
Добавлено через 42 минуты
Выложил доработанный вариант в картотеку
SPRView (http://sensi.org/%7Esvo/scalar/ware/720/)
fan, спасибо, что поднял эту тему!
Вопрос о правильной палитре для эмуляторов вектора считаю все еще открытым.
Респекты!!! Теперь всех порвём :D
Осталось ещё Ramiros'а уговорить приделать подобный настройщик ;)
Насчёт вопроса с палитрой согласен , теперь надо как-то по схеме высчетать точный шаг уровней %\ ибо при такой палитре малейший чих достаточно заметно её меняет .
Есть еще один важный момент в эмуляции вектора, который IMHO во всех трех нормальных эмуляторах (b2m, VV, ve27) сделан неправильно - палитра. Этот вопрос уже поднимался в этом треде
Где бы палитру глянуть .
Проще (и точнее) было бы сделать соотношение цветов по схеме вектора (этот фрагмент схемы даже я понимаю), но b2m и Ramiros не хотят. Может их поможет убедить тест 13736, который однако не так просто провести как предыдущие.
В тесте клавишами УС и СС можно пробежаться по цветам:
черный
три оттенка синего
семь оттенков красного
и семь оттенков зеленого
(РУС - переход на черный)
Нужно померить уровни сигнала для перечисленных цветов и лучше осциллографом. Tim0xA, что скажешь?
Еще раз отмечу (кому я это говорю :) ) - даже если Tim0xA соберется и померит, это будет менее точно, чем сделать по схеме, а у него получится скорее картина соответствующая его конкретному экземпляру вектора.
В качестве компромисса меня бы лично устроила возможность задания палитры из конфига или что-то в этом духе.
Что значит "по схеме"? Такая вещь, как калибровка цвета, имеется только у дорогих моделей мониторов, предназначенных для печатного дела. Оттенки цветов на обычных мониторах могут очень сильно отличаться. Конечно, можно задавать палитру и из файла, хотя на мой взгляд, это относится к разряду пожеланий типа "изменяемая ширина бордюра" :)
Оффтоп: в моём случае, чтобы сделать другую ширину бордюра, придётся в десятке мест изменить константы, а если сделать их вычисляемыми, то это отразится на производительности.
b2m, уточню, с чем я принципиально не согласен:
во всех эмуляторах диапазон изменения синего сделан примерно равным диапазонам изменения красного и зеленого, хотя, насколько я понимаю схему, цена каждого из двух старших разрядов всех компонент одинакова, просто у синего нет самого младшего разряда.
---------- Post added at 15:24 ---------- Previous post was at 15:23 ----------
Вдогонку - насколько я понимаю, сделать загружаемую палитру технически не представляет никакой проблемы и кучу констант (в отличие от бордюра) подстраивать не надо.
Нужно померить уровни сигнала для перечисленных цветов и лучше осциллографом. Tim0xA, что скажешь?
Можно попробовать, вот только осциллограф у меня лучевой, высокой точности не получим.
ivagor, есть еще интересная тема для исследований - определение корректного момента для перезаписи палитры. Если вычислить его с точностью до такта, можно будет обходиться и одним out $0c даже для недоработанных Векторов. Может напишешь и такой тест? Ради этого я даже готов откатить на время все изменения, сделанные в схеме.
есть еще интересная тема для исследований - определение корректного момента для перезаписи палитры. Если вычислить его с точностью до такта, можно будет обходиться и одним out $0c даже для недоработанных Векторов. Может напишешь и такой тест? Ради этого я даже готов откатить на время все изменения, сделанные в схеме.
Меня это тоже давно интересует, только жалко твой единственный работающий (по крайней мере на этом форуме) вектор. Может еще один починишь со временем :) ?
---------- Post added at 15:29 ---------- Previous post was at 15:28 ----------
Например, svofski доделает snail, чтобы его проверить опять паять :) ?
ivagor, истина дороже! :)
Tim0xA, серьезно, пока твой вектор не сломается, лучше бы его не трогать.
Еще есть исчезающе малая вероятность, что починят старый ТВ (юность ц404) и может на нем мой вектор что-нибудь покажет.
во всех эмуляторах диапазон изменения синего сделан примерно равным диапазонам изменения красного и зеленого, хотя, насколько я понимаю схему, цена каждого из двух старших разрядов всех компонент одинакова, просто у синего нет самого младшего разряда.
Диапазон одинаков от 0 до 255, и "вес" старших двух бит тоже примерно одинаков. Сравни:
красный и зелёный
0,50,90,130,165,195,225,255
синий
0,90,180,255
Т.е. например интенсивность зелёного 2 равна синему 1, зелёный 7 равен синиму 3, но вообще говоря, цифры эти взяты "от балды", чтобы с увеличением номера цвета интенсивность примерно одинаково увеличивалась. Для синего это примерно N*85, для зелёного и красного N*35 (с учётом того, что более тёмные цвета смещены в светлую сторону, иначе разницы не заметно).
Диапазон одинаков от 0 до 255, и "вес" старших двух бит тоже примерно одинаков. Сравни:
красный и зелёный
0,50,90,130,165,195,225,255
синий
0,90,180,255
Т.е. например интенсивность зелёного 2 равна синему 1, зелёный 7 равен синиму 3, но вообще говоря, цифры эти взяты "от балды", чтобы с увеличением номера цвета интенсивность примерно одинаково увеличивалась. Для синего это примерно N*90, для зелёного и красного N*45.
Именно это мне и не нравится. Ты не согласен, что по схеме вес двух старших разрядов синего, красного и зеленого одинаковый?
---------- Post added at 15:44 ---------- Previous post was at 15:41 ----------
Может мне этот фрагмент схемы сюда запостить?
Т.е. ты предлагаешь просто сделать немного темнее синий, как будто бы он тоже трёхразрядный, но младший бит всегда ноль?
А что, белый цвет (0xFF) был с зеленовато-красноватым (желтым) оттенком?
Сам я сейчас не поручусь головой, но вот свидетельство Ramirosa
Потому что, при значении 255 должен быть как мне кажется белый цвет, а не желтый. Я у себя помню перепаивал эти резюки, чтобы картинка не отдавала желтизной.
Т.е. видно что он сторонник одинакового диапазона для синего и красного с зеленым, но помнит, что реал желтил на 255.
Все же, как насчет загружаемой палитры?
В каком виде ты бы хотел это иметь? :)
Можно просто задавать вышеуказанные цифры (отдельно для R, G и B), а можно грузить все 256 цветов из файла, например .bmp 24-бит с картинкой, аналогичной тесту clrs, чтобы иметь возможность подстроить каждый цвет. Какой вариант нужен?
Лучше наверно так
Можно просто задавать вышеуказанные цифры (отдельно для R, G и B)
у меня в SPRView так и сделано:
B: 0 72 144 216
R и G:0 36 72 108 144 180 216 252
Второй вариант
а можно грузить все 256 цветов из файла, например .bmp 24-бит с картинкой, аналогичной тесту clrs, чтобы иметь возможность подстроить каждый цвет.
круто, но это для полных хардкорщиков, для меня это слишком.
Ладно, для начала градации цветов. Кстати уже сделал и выложил на сайт.
Магические строчки такие:
vid : V06c-Video {
color.level.blue="0,60,120,180"
color.level.green="0,50,90,130,165,195,225,255"
color.level.red="0,50,90,130,165,195,225,255"
...
Все три строки опциональны.
Спасибо, это был мой давний мечт.
Пожалуйста, делов-то на пять строчек кода. Только вот ч/б палитру таким образом не сделаешь, а вот с битмапом ... :)
Только вот ч/б палитру таким образом не сделаешь, а вот с битмапом ...
Универсальные решения - это хорошо, но не всегда удобно.
А для ч/б можно или опцию в конфиге ввести или кнопку, которая у тебя уже есть в некоторых других компах. Понятно, что на БК переключение цвет / ч/б значит несколько другое, чем на векторе, но кнопку поставить это не мешает.
---------- Post added at 18:06 ---------- Previous post was at 18:00 ----------
Еще ты можешь написать, что с битмапом можно сделать не только серый монитор, но и зеленый, и желтый и любой :)
Сам я сейчас не поручусь головой, но вот свидетельство Ramirosa
Т.е. видно что он сторонник одинакового диапазона для синего и красного с зеленым, но помнит, что реал желтил на 255.
Все же, как насчет загружаемой палитры?
Да я подтверждаю что реальный вектор немного желтил при цвете $FF
Ramiros, твой эмулятор и эмулятор b2m имеют свои уникальные фичи, так что очень здорово, что ты продолжаешь его совершенствовать.
Пара пожеланий:
1. Обрати внимание на скриншот (http://zx.pk.ru/attachment.php?attachmentid=13701&d=1255201679) с результатами тестика (http://zx.pk.ru/attachment.php?attachmentid=13694&d=1255185589) на реале.
2. Очень бы хотелось поддержки загружаемой палитры.
ivagor,
Еще ты можешь написать, что с битмапом можно сделать не только серый монитор, но и зеленый, и желтый и любой
это реализовано в эмуляторе VV, я ещё в прошлом году упрашивал ;)
а почему вы не сделаете загружаемую палитру.
настроил её как вам угодно, сохранил, загрузил.
так сделано например в эмуляторе Atari800WinPlus 4.0
вот так там это сделано:
http://pic.ipicture.ru/uploads/091013/wQ3wN91TRx.jpg
Tim0xA, Я обновил эмуль, выложи на сайт
Новая версия VV на сайте!
Ramiros, спасибо за введение регулируемой палитры! Rom2wav - тоже very good!
Составил табличку с указанием, в какие моменты палитра на моем векторе не программируется. В качестве примера использования сделал быстрый вариант полного программирования палитры (каждый цвет программируется одним out 0C), более чем в 2 раза быстрее, чем традиционные варианты. Тест, использовавшийся при составлении таблички, не прилагаю, т.к. он "недостаточно интерактивный", а подробно описывать как им пользоваться и что там нужно менять для разных участков экрана мне сейчас лень.
Не исключено, что доработка синхры повлияла на расстановку "участков непрограммируемости". К сожалению, тест я сделал уже после доработки.
Ramiros, добавь в эмулятор возможность просмотра значений текущей палитры (16 математических цветов).
Ramiros, добавь в эмулятор возможность просмотра значений текущей палитры (16 математических цветов).
в отладчике?
В закладке Options->Palette после [Color Levels Configurations]. В HEX-формате.
В закладке Options->Palette после [Color Levels Configurations]. В HEX-формате.
нужен только просмотр, или еще возможность изменить?
нужен только просмотр, или еще возможность изменить?
Изначально нужен был только просмотр. Но если ты добавишь возможность изменить значение, то это не помешает. Но изменение палитры в этом меню не должно блокироваться опцией "Screen - Rendering Method - Disable Change Palette". Эта опция должна блокировать только программное изменение палитры по команде OUT, ее кстати можно продублировать в этом новом меню. Еще можно также добавить переключение HEX/DEC формата отображения математического цвета. Нужно ли сохранять палитру в файл и загружать из файла? Это тоже может пригодиться. Формат файла текстовый. 16 значений через запятую одной строкой. HEX значения с "0x", иначе DEC.
---------- Post added at 23:38 ---------- Previous post was at 23:09 ----------
Еще было бы здорово там же видеть эти цвета, всю текущую палитру.
да я тоже хотел предложить когдато нечто подобное.
можно там где изменяешь палитру поместить какуюнибудь небольшую цветную картинку.
меняешь значения палитры, соответственно изменяются цвета на картинке и ты сразу видишь изменения.
можно такое устроить ?
сделаю, но быстро неполучается, времени нехватает
Ramiros выпустил новую версию эмулятора VV. Навороченные настройки палитры!
См. на сайте http://vector06c.narod.ru в разделе "Эмуляторы", версия 6.18
Баг:
В эмуляторе VV при включении опции "Disable Change Palette" блокируется не текущая палитра, а та, которая предусмотрена в эмуляторе по-умолчанию. Это хорошо видно, если включить опцию во время работы загрузчика.
Фичи:
Эмуляторы VV и b2m используют некую предустановленную палитру, которая загружается при открытии файлов ROM через диалог File-Open. Это было сделано для "красочного" отображения программ, портированных с "Криста-2". Но это не совсем правильно, т.к. из-за этого некорректно отображаются программы, которые используют предустановленную палитру загрузчика Вектора, например Landing (http://sensi.org/~svo/scalar/ware/409/).
Поэтому, по-умолчанию следует грузить палитру загрузчика, а для загрузки полноцветной палитры сделать отдельную опцию.
---------- Post added at 15:05 ---------- Previous post was at 14:36 ----------
Также по этой причине в некоторых программах на экране виден "мусор", пока они делают свои грязные дела в экранных плоскостях.
Баг:
В эмуляторе VV при включении опции "Disable Change Palette" блокируется не текущая палитра, а та, которая предусмотрена в эмуляторе по-умолчанию. Это хорошо видно, если включить опцию во время работы загрузчика.
Это не баг, это спец опция чтобы подсмотреть грязные дела, которые невидно при обычной палитре :)
А у кого-нибудь имеется 8-битовая индексная палитра Векторовского color space для Фотошопа? Сдаётся мне, натыкался на неё в какой-то ветке, но найти не смог. В Базисе вроде тоже отсутствует. Начал делать сам, и обнаружил, что равномерно диапазон чистых R/G цветов делить на 8 неправильно. Приблизительно Векторовский цвет 1 (тёмно-красный) - это R=128, т.е. 0x800000 в 24-битном цветовом пространстве. Дальше - с инкрементом по 16. А для синего соответственно с инкрементом по 32.
Mожет кто-то уже прокалибровал всё в Фотошопе, сидя напротив реала. Поделитесь палитрой please, а то свою сделаю :v2_dizzy_cowboy:
Такая палитра называется 3-3-2, или RGB332: по числу бит на компонент.
В эмуляторе VV есть навороченные настройки палитры, может пригодится.
http://savepic.su/2263942.png
А вот еще палитра RGB332 для Le Gimp:
http://uzebox.org/forums/viewtopic.php?f=6&t=396
Собрал все обсуждение векторовской палитры в одну тему http://zx.pk.ru/showthread.php?t=19774
Потом последние сообщения из этой темы перенесу туда же, но пока оставлю, чтобы читатели/писатели не потерялись )
Меня всегда интересовало, как можно на Векторе с RGB332 получить палитру, максимально похожую на монохромную: черный, белый и все возможные промежуточные градации цветов. Но чтобы не выбирать эти цвета самому по картинкам, подобным этой
http://belogic.com/uzebox/images/color_table.gif
а грамотно, по какой-то формуле/алгоритму. Это возможно?
Поскольку на синий отведено лишь 2 бита, то и градаций ч/б может быть только 4, и это с учётом чёрного и белого.
Поскольку на синий отведено лишь 2 бита, то и градаций ч/б может быть только 4, и это с учётом чёрного и белого.
А я в курсе, что синих на бит меньше ;-), поэтому отдельно про удвоенный шаг по синему писал.
А вообще- всем большое спасибо. Жаль вот только конкретного файла с палитрой под Фотошоп пока не удалось найти.
---------- Post added at 20:06 ---------- Previous post was at 19:31 ----------
Собрал все обсуждение векторовской палитры в одну тему http://zx.pk.ru/showthread.php?t=19774
Потом последние сообщения из этой темы перенесу туда же, но пока оставлю, чтобы читатели/писатели не потерялись )
Спасибо за линк, а мы постараемся не затеряться
Меня всегда интересовало, как можно на Векторе с RGB332 получить палитру, максимально похожую на монохромную: черный, белый и все возможные промежуточные градации цветов. Но чтобы не выбирать эти цвета самому по картинкам, а грамотно, по какой-то формуле/алгоритму. Это возможно?
Безусловно, и формула эта очень простая: зелёный и красный сдвинуты на бит левее, чем голубой, что даёт на Векторе только 4 чисто серых цвета (cм. табличку внизу) плюс белый и чёрный, итого 6 чисто серых тонов. Кстати, чисто "нейтрально-серый" у Вектора только один: цвет 0xAD (173 dec). Я так понимаю, при этом совпадают интесивности по всем 3м цветовым компонентам. Но точное совпадение цветовых весов не слишком принципиально на телевизорах, где многие "нечистые" смотрятся как святые ;-)
Но есть ещё 3 серых цвета с металлически голубым оттенком. Это всё-следствие того, что синих только 2 бита, а человеческий глаз различает синие оттенки хуже и при определённой освещённости и заднем плане путает серо-синие с серыми. Такие цвета на Векторе получают начиная с синего с весом 2 (10 binary) и добавляя 1 к red & blue, т.е.
B G R
10 011 011
11 100 100
11 101 101 - этот цвет не совсем "честный" потому что синий уже saturated мм..насыщен. Но он всё равно выглядит как оттенок серого из-за высокой яркости. Вот табличка серых и "металлически-серых" для наглядности:
HEX B G R DEC
WHITE
FF 11 111 111 255
GREY
F6 11 110 110 246
AD 10 101 101 173 Neutral
A4 10 100 100 164
52 01 010 010 082
METAL
ED 11 101 101 237
E4 11 100 100 228
9B 10 011 011 155
BLACK
00 00 000 000 000
PPC, спасибо за развернутый ответ. Именно это я и хотел узнать. Палитра получилась такая
http://i018.radikal.ru/1208/60/8019580ebefa.png
Металлик E4 (третий слева) и нейтральный серый AD придется видимо исключить - один синевой отдает, другой IMHO зеленит (или у меня монитор такой, ну вообщем какой-то этот цвет не в тон получается).
Вообщем, где-то так
http://s004.radikal.ru/i206/1208/3e/b878fc449dbc.png
Без металликов конечно вообще красиво
http://s010.radikal.ru/i311/1208/c3/b09d59b2b01c.png
Без металликов конечно вообще красиво
Красиво, и правда. Выходит, только 5 оттенков "незамутнённого" серого.
Занятно в этих 5 цветах попытаться сгенерить чисто ч/б картинку с фотографии. Я думаю, придётся серьёзно играться сглаживанием и dithering-ом в каком-нибудь фото-редакторе. Но 5 всё-же лучше чем 1 или 3 :).
А потемнее никак ничего нельзя выжать, получается коричневый? Очень уж яркий "темно серый".
Кстати, у b2m и в VV палитры разные
http://s019.radikal.ru/i620/1208/db/6c8c249f35fc.jpg
У кого правильно? Может пора делать настройки холодный/теплый цвет, как в мониторах?
А цветного реального Вектора с телевизором так ни у кого и нет?
А цветного реального Вектора с телевизором так ни у кого и нет?
Через денек у меня будет, что надо сделать? Нет, не так. Точнее расскажите, что нужно проделать чтобы составить/уточнить палитру.
Чтобы показать палитру нам, надо фотоаппарату выставить баланс белого по серому полю. То есть, надо: 1) Выкрутить цветность на 0, чтобы все стало чб. 2) Настроить баланс белого автоматом по картинке. 3) Выкрутить цветность у телевизора обратно в цвет и сфотать табличку.
Где взять табличку -- спроси у Тимохи =)
Чтобы показать палитру нам, надо фотоаппарату выставить баланс белого по серому полю. То есть, надо: 1) Выкрутить цветность на 0, чтобы все стало чб. 2) Настроить баланс белого автоматом по картинке. 3) Выкрутить цветность у телевизора обратно в цвет и сфотать табличку. Где взять табличку -- спроси у Тимохи =)
Записал. Обязательно сделаю.
А потемнее никак ничего нельзя выжать, получается коричневый? Очень уж яркий "темно серый".
Потемнее, наверное, никак. Цвет 0x52 (82d) содержит синий с минимальным весом 01:
B G R
01 010 010
В принципе, он не должен быть ярким, потому как цвета G и R имеют вес 2/7. Грубо, приняв функции яркости линейными и эквивалентными для всех трёх компонент, вроде как выходит следующее:
1/3 * (1/3 + 2/7 + 2/7) = 0.3 максимальной яркости, то есть 30%.
Правда, может я ошибаюсь. Вспоминается что в телевизоре
Luminance = 0.1*B + 0.7*G + 0.2*R
Если считать так, то выходит
0.1* 1/3 + 0.7 * 2/7 + 0.2 * 2/7 = 0.29, те же 30%
Не должно быть очень ярко-то. Возможно в симуляторах ярко потому что DAC levels выбраны высокие. Не утверждаю что так, просто я и сам предлагал компонентны начинать с уровня 80H, а это уже половина яркости в 24-битном пространстве.
Когда нам говорили, что в режиме 512x256 может быть 4 только цвета, то нас немножко обманывали. Это условное ограничение, просто цвета могут быть "полосатыми".
Пример (единственный?) грамотного использования - Minesweeper (http://www.sensi.org/~svo/scalar/ware/57/) (5 цветов). И довольно симпатично вышло.
http://s017.radikal.ru/i427/1208/79/d2c789d55729.png
http://s03.radikal.ru/i176/1208/c3/8614011a8bb2.png
svofski, разные палитры для четных и нечетных пикселей.
Теоретически, если всё делать штриховкой, максимум 7 цветов, но тогда смысл не велик (лучше уж 256х256 использовать). Но если для текста зарезервировать одинаковый цвет чётных/нечётных пикселей, то максимум 6 цветов.
predatoralpha
10.08.2012, 18:57
Прикольно!
Фото грейтеста с телика
Вроде горизонт завален немного и баланс белого тоже был.
http://rghost.ru/39864475
для баланса - в кадр поместить лист (кусок) белой бумаги
тогда баланс по нему сделать можно
для баланса - в кадр поместить лист (кусок) белой бумаги
тогда баланс по нему сделать можно
Мы же фотографируем телевизор, а с листом бумаги получится баланс белого по рассеяному свету в комнате. Надо насыщенность выкручивать в ноль и по телевизору ставить баланс.
Надо насыщенность выкручивать в ноль и по телевизору ставить баланс.
svofski, так и делалось. На фото 100% картинка того, что было на телике. /me гарантирует это.
BYTEMAN, да, я понял, иначе никакого подобия серого мы бы не увидели. Спасибо за фотки!
---------- Post added at 19:08 ---------- Previous post was at 19:07 ----------
Да, но вот откровенно желтый "белый" меня удивил. На глаз тоже желтый?
---------- Post added at 19:09 ---------- Previous post was at 19:08 ----------
И уж, а как будет выглядеть вот это: http://sensi.org/~svo/scalar/ware/768/ ?
Да, но вот откровенно желтый "белый" меня удивил. На глаз тоже желтый?
да, что странно, белый - "жёлтый" везде... У меня есть кое какие подозрения, кто я там в векторе малость с доработкой накосячил, но это надо будет уточнить когда dbk в топике появится...
---------- Post added at 19:08 ---------- Previous post was at 19:08 ----------
как я понимаю, один бит синего подсажен?
у вектора по умолчанию цвета инверсные, чтобы цвета стали правильные нужно было делать доработку, и тут уже делали кто как умел, так что за истину такие векторы принимать наверное нельзя.
у вектора по умолчанию цвета инверсные, чтобы цвета стали правильные нужно было делать доработку, и тут уже делали кто как умел, так что за истину такие векторы принимать наверное нельзя.
хм, а как по другому без доработки тогда? доработка сделана достаточно "тупо" - проинвертированы цвета через штатный "монохромный" инвертор, резюки на монохром отпаяны нафик, и выходы с инверторов заведены на "родные" резисторы, на которые подавался инверсный сигнал (Ессно, ноги предварительно подняты). Я вот только подумываю, что после такой доработки надо наверное химичить с номиналами резюков... Т.к. оно изначально мешало инверсные уровни (т.е. сейчас, видимо, самый "тусклый" оттенок стал самым ярким, возможно). Поправьте меня если я не прав.
резюки менять ненадо. черный должен стать белым, а белый - черным и. т.д.
Если номиналы резюков соответствуют тем что в схеме, и доработка сделана так, как ты говориш, то твоему вектору верить можно :)
хотя я в своем векторе вешал дополнительно микросхемку инверторов, а "монохром" не трогал. но цвета мне непонравились, бледные какие то были, и я резюки менял пропорционально на меньшее сопротивление.
Если номиналы резюков соответствуют тем что в схеме, и доработка сделана так, как ты говориш, то твоему вектору верить можно
да, именно так (если ничге не накосячил). Ещё не исключён вариант "вылетевшего" битика в РУ2. Надо как-то сделать такую хрень, чтобы вывести на экран четыре "градации" синего (чистого синего), и посмотреть, что будет на экране у dbk. Ибо жёлтый, если я правильно понимаю, означает траблы с синим.
да, именно так (если ничге не накосячил). Ещё не исключён вариант "вылетевшего" битика в РУ2. Надо как-то сделать такую хрень, чтобы вывести на экран четыре "градации" синего (чистого синего), и посмотреть, что будет на экране у dbk. Ибо жёлтый, если я правильно понимаю, означает траблы с синим.
набей такую програмку в бейсике и посмотри.
набей такую програмку в бейсике и посмотри.
Все будет сделано, но ближе к концу недели (на выходных), бытовые вопросы закрыть надо.
набей такую програмку в бейсике и посмотри.
Вот, что получилось + толика фоток "живого Вектора" (putup + invector)
http://rghost.ru/40039304
как видно синии битики РУ-ки живы
судя по номиналам резисторов для краного и зеленого (1,6кОм/820 Ом/430 Ом) и синего (820 Ом/430 Ом), чисто белый цвет будет 01101111b или 6Fh, а FFh должен немного отдавать желтизной.
Может всё-таки 11110110b?
bbgggrrr, или я попутал?
Может всё-таки 11110110b?
bbgggrrr, или я попутал?
да это я ступил :) чисто белый будет F6h.
вспомнил, зачем я резюки у себя менял - я подбирал их так, чтобы FFh стал чисто белый.
Ramiros, т.е. у нас всё гуд?
Ramiros, т.е. у нас всё гуд?
получается что гуд :) а в эмуляторе несовсем тру, но это я потом поправлю.
в новой версии я поправлю таблицу палитры по умолчанию (точнее уровни синего), красный и зеленый думаю оставить как есть.
Есть еще какие соображения по уровням красного/зеленого?
То есть чисто белый будет $F6? Я не знаю, честно говоря. Эталона у нас по сути нет, поскольку ни один заводской Вектор вообще не мог работать с цветом без модификаций. Стоит ли повторять все ошибки разработчиков и делать такие странные костыли? Очевидно, что они смотрели на MSX, где белый все-таки $FF. Или я ошибаюсь?
Эталона у нас по сути нет, поскольку ни один заводской Вектор вообще не мог работать с цветом без модификаций.
С Радугой 3УСЦТ он работал в цвете без модификаций. Это чтобы Спектрум подключить, приходилось инверторы ставить. А у MSX палитра 9 бит, а не 8.
Мое предложение:
Красный и зеленый - 0 38 75 113 142 180 217 255
Синий - 0 75 142 217
или более "равномерный" вариант
Красный и зеленый - 0 36 72 108 144 180 216 252
Синий - 0 72 144 216
ни один заводской Вектор вообще не мог работать с цветом без модификаций.
О чем речь?
О чем речь?
Сколько я ни слышал о подключении Вектора к цветным телевизорам, всегда всплывала тема о инверсии, или еще о каких-то переделках.
Не помню уже, как была сделана доработка, и что у меня был за телек но 255 у меня не желтил абсолютно, и был ярко белым. Следовательно, синий 0xC0 (192) соответствовал по яркости 111B красному и зелёному.
Вообще, существующая сейчас в VV палитра очень похожа на то что помнится с одним сущёственным исключением: самые тёмные тона красного 1 и зелёного 8 выглядят в VV почти чёрными, а они имели оттенки. Хотя, может это просто мой монитор.
При всех прочих я тоже за то чтобы оставить 255 белым цветом.
у MSX палитра 9 бит, а не 8.
Да, но в SCREEN 8 (Graphic 7) синяя составляющая перекодировалась 0->0, 1->2, 2->4, 3->7.
все же в реале 255 (по крайней мере у меня желтило). речь идет о палитре по умолчанию, ее же легко можно поправить кому как нравится.
Ну как вы это вообще себе представляете? Я буду каждый раз обновляя эмулятор, или ставя его на новое место, сидеть и настраивать 256 цветов?
Я считаю, что лучше оставить палитру по умолчанию нейтральной, но добавить выбор из разных предопределенных вариантов труъ. Пусть среди них будет и желтая. Я даже не против, если она будет названа единственной православной, но не надо делать ее по умолчанию.
Можно самому настроить палитру, можно загрузить готовую. Например вот (удалил в связи с неактуальностью) "желтая" и "белая". CPU->Options->Palette->Load Pal. Только я не уверен, что в CPU самое лучшее, интуитивно находимое место для палитры.
Кстати, вчера когда постил, не посмотрел, какой сейчас текущий (в 6.55) вариант. Оказалось, что красный и зеленый уже такие и есть, т.е. наверно Ramiros тоже по номиналам резисторов посчитал.
И я голосую за "желтую" палитру по умолчанию.
Еще можно поспорить о том, надо ли учитывать разную "гамму" для старых ТВ и современных мониторов.
про палитру есть такая мысля - пусть кто-нибудь с реальным вектором соберёт самый что ни на есть "православный" инвертор на 3-х транзисторах, как в радиолюбителе описан... Есть у мну подозрение, что белый станет белым... Ибо резюки то рассчитаны с "уклоном" на инверсные цвета.... Т.е. как бы не чем меньше номинал резюка, тем темнее, а наоборот... Есть у меня такая мысля...
Может голосование сделать по этому вопросу? Не уверен, что околотехнические вопросы нужно решать подобным образом, но так хоть большинство будет довольно.
ivagor, надо просто один раз проверить....
надо просто один раз проверить
На примере одного экземпляра? Кроме того, выбрав "нужную" методику проверки можно получить и желаемый результат, особенно если в проверке будет использоваться ТВ или монитор.
IMHO, если проводить объективные измерения, то нужно использовать осциллограф с выделением строки и несколько векторов с отсутствием доработок видеотракта.
Если использовать подключение к телевизору, как задумано разработчиками, то цвет FF, все таки белым должен быть. Если в палитру записан цвет FF, на выходах РУ2 будет 0, и на контактах 1,2,3 XS3 (R,G,B) соответственно тоже 0. На контакте 5 XS3 (Видео) будет максимальный уровень. Эти сигналы в телевизоре приходят на К174АФ5, которая из цветоразностных сигналов и сигнала яркости делает RGB. При цветоразностных сигналах с нулевым уровнем на выходе будет RGB одинаковой яркости.
Blade, спасибо тебе, голос разума!
Если использовать подключение к телевизору, как задумано разработчиками, то цвет FF, все таки белым должен быть. Если в палитру записан цвет FF, на выходах РУ2 будет 0, и на контактах 1,2,3 XS3 (R,G,B) соответственно тоже 0. На контакте 5 XS3 (Видео) будет максимальный уровень. Эти сигналы в телевизоре приходят на К174АФ5, которая из цветоразностных сигналов и сигнала яркости делает RGB. При цветоразностных сигналах с нулевым уровнем на выходе будет RGB одинаковой яркости.
Да, действительно железный аргумент. желтизна выходит недостаток доработки с применением инверторов (не транзисторных, а именно логики).
В общем убидили 255-белый.
IMHO, если проводить объективные измерения, то нужно использовать осциллограф с выделением строки и несколько векторов с отсутствием доработок видеотракта.
про отсутствие доработок - я и пишу, что надо не отдельно каждый битик инвертировать, а сделать полноценный аналоговый инвертор, на 3-х транзисторах. Это будет самое "честное" исследование.
---------- Post added at 22:56 ---------- Previous post was at 22:53 ----------
Если использовать подключение к телевизору, как задумано разработчиками, то цвет FF, все таки белым должен быть. Если в палитру записан цвет FF, на выходах РУ2 будет 0, и на контактах 1,2,3 XS3 (R,G,B) соответственно тоже 0. На контакте 5 XS3 (Видео) будет максимальный уровень. Эти сигналы в телевизоре приходят на К174АФ5, которая из цветоразностных сигналов и сигнала яркости делает RGB. При цветоразностных сигналах с нулевым уровнем на выходе будет RGB одинаковой яркости.
это я и пытался выше донести)))
Эти сигналы в телевизоре приходят на К174АФ5, которая из цветоразностных сигналов и сигнала яркости делает RGB. При цветоразностных сигналах с нулевым уровнем на выходе будет RGB одинаковой яркости.
Хорошо, а если подключить к ТВ с К174ХА17 по варианту, например из руководства к 06ц.02, разве тоже так будет? А если подключить к МС6106?
Хорошо, а если подключить к ТВ с К174ХА17 по варианту, например из руководства к 06ц.02, разве тоже так будет? А если подключить к МС6106?
у 06ц.02 неинвертированный видеовыход? Если да, но будет нормальная картинка. Мы подключали обычный 06ц к ХА17, ессно картинка была в инверсии...
Хорошо, а если подключить к ТВ с К174ХА17 по варианту, например из руководства к 06ц.02, разве тоже так будет?
Тогда FF будет желтым. У синего цвета младшего разряда не хватает. Чтобы получить белый FF, надо ставить еще один резистор в ЦАП и элемент И или ИЛИ для формирования младшего разряда из 2-х имеющихся. Тогда получатся уровни 0 -> 0, 1 -> 2, 2 -> 4, 3 -> 7 или 0 -> 0, 1 -> 3, 2 -> 5, 3 -> 7.
у 06ц.02 неинвертированный видеовыход?
Настраивается перемычкой CTV, а на входе каждой РУ2 стоят "исключающие ИЛИ" 555ЛП5, запараллеленные вторые входы которых идут к перемычке (она в левом нижнем углу листа 2 схемы).
Настраивается перемычкой CTV, а на входе каждой РУ2 стоят "исключающие ИЛИ" 555ЛП5, запараллеленные вторые входы которых идут к перемычке (она в левом нижнем углу листа 2 схемы).
жаль, в распоряжении нет 06ц.02, проверили бы тогда... Ну и ещё надо всё-таки вариант с аналоговыми инверторами проверить...
думаю за эталон надо брать обычный 06ц.
если FF получается белый, то тогда 00 т.е. черный должен быть не черный, а немного синий, т.к. уровни напряжений красного и зеленого будут больше синего ровно на значение младшего бита.
В общем решил оставить палитру как есть.
вот такой вот результат запуска парочки тестов. Вектор подключён "честно", т.е. инвертированный выход подключён к инвертированному входу строго по схеме подключения к МЦ-2.
В "сером тесте" самая правая полоска слегка желтит (слегка).
Чего-то улитка моя совсем странно выглядит.. ну и ладно.
svofski, где-то читал, что мол типа "палитра не прописывается", или что-то в этом роде...
---------- Post added at 04:14 ---------- Previous post was at 04:07 ----------
кучка фоток с экрана лежит тут: http://vk.com/album18720117_169699795
Странно, что никто не делал графику под "режим" ч/б монитора, а ведь там 19 градаций серого
45398
Самые плавные градиенты из возможных на векторе так и не были реализованы
Странно, что никто не делал графику под "режим" ч/б монитора, а ведь там 19 градаций серого
Проблема в том, что такая графика потом будет отвратно смотреться на цветном мониторе/ТВ. У меня когда-то был поначалу именно ч/б монитор, и я извращался с интенсивностями до тех пор, пока не увидел ту-же самую картинку на цветном TV :v2_dizzy_facepalm:
ПМСМ это не проблема, ведь это просто еще одна конфигурация вектора, и она не обязана быть на 100% совместима со всеми остальными. Никого ведь не удивляет, что цветные изображения на ч/б мониторе смотрятся не так, как на цветном, а тут обратная ситуация. Ну или использование квазидиска - не у всех же он был и т.д. Тем более сейчас, когда практически все пользуются эмуляторами, можно легко переключить цвет или ч/б (хотя на DE1 не получится больше 16 градаций серого, досадно).
Вот только не могу сообразить, почему в VV получилось 19 градаций, а не 1+7+7+3=18.
Самые плавные градиенты из возможных на векторе так и не были реализованы
А какое практическое применение? По горизонтали - круче, чем на этой картинке не сделаешь, а по вертикали - да, но при этом используется мультиколор, отъедающий 100% производительности процессора.
?
В самом простом варианте - задаем палитру (один раз, без всяких мультиколоров и т.п.) с 16 разными градациями серого и пользуемся (под такой режим легко и автоматом конвертить). Градиенты по горизонтали и вертикали с дискретностью изменения яркости в 1 точку, не вижу проблем.
Я непойму о каких 19 градациях речь, вектор способен выдать 256 уровней яркости от черного до белого, т.е. 256 градаций. другое дело, что без изврата с мультиколором одновременно можно только 16 выводить.
Ramiros, загрузи в своем эмуляторе тестик b2mа (http://asdasd.rpg.fi/~svo/scalar/ware/770/), включи Color Mode -> Black and White, сделай скриншот и в любом редакторе/просмотрищике посчитай, сколько цветов (градаций).
посчитай, сколько цветов (градаций).
Количество зависит от того, какие градации серого выбраны для градаций R,G,B. Если попарные суммы совпадают с имеющимися числами, то градаций будет немного.
Господа, я не скрываю, что я ноль в схемотехнике, но посмотрите на схему видеовыхода вектора. Тот "ЦАП", который на выходе ВИДЕО, по моим ламерским представлениям должен давать 18 градаций яркости, разве нет?
---------- Post added at 13:10 ---------- Previous post was at 13:09 ----------
Смотрел схему кишиневского вектора с герконовой клавиатурой, но вряд есть принципиальные отличия с другими версиями.
только что просчитал все варианты по схеме, получилось 133 градации.
R:
1= 5.10к - 1 (код = сопротивление - яркость)
2= 3.30к - 2
3= 2.00к - 3
4= 1.60к - 4
5= 1.20к - 5
6= 1.08к - 6
7= 0.89к - 7
G:
1= 3.30к - 2
2= 1.60к - 4
3= 1.08к - 6
4= 0.82к - 8
5= 0.66к - 10
6= 0.54к - 12
7= 0.46к - 14
B:
1= 5.10к - 1
2= 3.30к - 2
3= 2.00к - 3
Остается все эти яркости просумировать во всех 256 комбинациях и получится 133 значения.
Промежуточные сопротивления расчитаны по формуле 1/Rобщ=1/R1+1/R2+1/R3
Пришлось мне тоже посчитать. Никаких промежуточных значений не считал и у меня получилось 99 уникальных значений.
---------- Post added at 14:17 ---------- Previous post was at 14:16 ----------
Причем, если не считать микроскопических отличий, то уникальных значений остается 72
---------- Post added at 14:19 ---------- Previous post was at 14:17 ----------
Могу выложить скриптик для MATLABа
BWR: array [0..7] of byte=(0,1,2,3,4,5,6,7);
BWG: array [0..7] of byte=(0,2,4,6,8,10,12,14);
BWB: array [0..3] of byte=(0,1,2,3);
for B:=0 to 3 do
for G:=0 to 7 do
for R:=0 to 7 do
Begin
k:=B*64+G*8+R;
PallTableBW[k]:=(BWR[R]+BWG[G]+BWB[B]);
end;
Ramiros, зачем ты группируешь, не вижу в этом никакого физического смысла
Ramiros, зачем ты группируешь, не вижу в этом никакого физического смысла
это код расчета палитры из VV, уже исправленый
MATLAB не у всех установлен, прога выдает
1 99
1 72
1 72
1 72
т.е. округляем до десятых, сотых, тысячных - все равно 72
Посчитал с целыми - получил 72, даже без всяких округлений. 99 было из за микроскопических ошибок при вычислениях с плавающей точкой.
Хотя на реале номиналы резисторов с погрешностями, так что градаций будет больше, но эти "дополнительные" градации будут очень мало отличаться от "эталонных" и будут варьироваться от экземпляра к экземпляру.
---------- Post added at 14:47 ---------- Previous post was at 14:43 ----------
это код расчета палитры из VV, уже исправленый
Это ведь параллельный ЦАП, каждый разряд имеет свой вес, не понимаю, что ты считаешь.
при включении одновременно нескольких разрядов, токи в их резисторах будут сумироваться и яркость будет пропорциональна сумарному току
при включении одновременно нескольких разрядов, токи в их резисторах будут сумироваться и яркость будет пропорциональна сумарному току
Ну а я разве против?
Вот такой нелинейный ЦАП получается
А если строить "амплитудную характеристику", т.е. без убирания повторяющихся значений и сортировки, то выглядит страшненько
Сделал програмку для расчета палитры, действительно получилось 72 значения :)
Ramiros :v2_cheer:
Монохромные режимы в VV переделаешь?
уже переделал :) чуть позже выложу
---------- Post added at 17:22 ---------- Previous post was at 17:06 ----------
VV 6.80 (http://files.mail.ru/2367AD606B3F441EB7A9B3070C3A591F)
Обновил http://sensi.org/~svo/virtualvector
Добавил в SPR View поддержку режима "ч/б монитора".
Пример преобразования картинки. Оригинал
47432
При использовании цветной векторовской (в данном случае соответствует VV 6.82) палитры
47433
При использовании оттенков серого (под "ч/б ТВ")
47434
При загрузке на форум картинки (из за размера) преобразовались в JPG. Оригиналы
47435
Такие же палитры сейчас используются в v06cc для DE1-SoC, т.е. существует "современная аппаратная реализация". На DE1 разрядность видеоЦАПа маловата.
Особенность SPR View (про которую за огромные промежутки м/у версиями я, например, забываю) - векторовские палитры учитываются только при открытии и записи файлов в векторовских форматах.
Под влиянием прочтения корветовской темы. BYTEMAN, можешь с тюнера захватить картинку от теста b2mа (http://asdasd.rpg.fi/~svo/scalar/ware/770/)? Интерес тот же, что и на корвете - яркости соответствующие цветам в ч/б варианте.
Накропал "тест" показывающий на ч/б ТВ или мониторе 72 оттенка серого одновременно
Скриншот из VV 6.84 (Screen->Display Effects->Color Mode->Black and White)
UPD: убрал одну команду из начальной задержки, теперь должно работать корректно и на векторах с тугим программированием палитры. Ну и уточню "фишку" теста - она всего лишь в сортировке оттенков серого, а так тест b2mа лучше.
Я так понимаю, на реале так никто и не протестировал?
У кого-нибудь есть возможность запустить тест на реале, сняв картинку с черно-белого выхода?
Сейчас затрудняюсь точно вспомнить, кто проверял, кажется KTSerg и возможно svofski, результат был так себе. bwclrs подошел бы для подтверждения, что все похоже на правду, но раз непохоже, то намного информативнее захватить тюнером 256 цветный тест b2mа с ч/б видеовыхода, чтобы можно было примерно оценить соотношение яркостей.
Кажется у меня ни разу не складывалось так, что и реал работал, и был подключен именно по чб и при этом я бы еще и вспомнил про bwclrs. Сейчас увы, подключен в цвете и при этом не работает.
Мысли вслух -- доверия к тесту, снятому на скорую руку с тв-тюнера без модификации с привязкой к уровню черного, у меня не будет. Нас конечно интересуют относительные яркости, но в типичном случае они все будут относительно не совсем понятно чего (гриба). Не факт, что опорная величина останется неизменной на протяжении кадра. При этом понятно, что никто мучать себя такой переделкой ради не ахти какой загадки мироздания не станет. Может быть отчасти эту проблему можно сгладить, добавив белые вертикальные полосы слева и справа экрана.
Реал Вектор-06Ц, ч/б монитор Электроника.
https://s8.hostingkartinok.com/uploads/images/2021/04/f4dd090e9d5ee6b65d8815e740d969db.jpg
Реал Вектор-06Ц.02, ч/б монитор Электроника.
https://s8.hostingkartinok.com/uploads/images/2021/04/6e1a5b3fb01730ac03af6b64f9200947.jpg
На .02 горизонтальные полосы более контрастные.
Влияет ли на картинку наличие "уровня чёрного" сказать сложно. Когда кручу его регулировку, картинка просто становится темнее или светлее, контраст не пропадает.
Наличие контрастных вертикальных полос, даже предполагать не берусь.
KTSerg, спасибо, но по такой фотке можно сказать только, что цвета в bwclrs на реале не выстраиваются в градиент, что в принципе уже известно. Гигантов эмуляции спасет как минимум clrs с тюнера, и то svofski не совсем поверит. Если предположить, что в рамках строки яркости не уплывают, можно попробовать скомбинировать интересующие комбинации построчно и потом попробовать все это согласовать друг с другом, но возможно проще сделать привязку к черному или белую полосу или еще что-то для ориентировки.
KTSerg, спасибо! Еще бы хотя бы этот тест (http://sensi.org/scalar/ware/770/), и уже можно было бы подумать. Конечно, с тюнера было бы намного полезней, но хотя бы так.
А как теперь по этой картинке теперь сделать обратное преобразование, чтобы настроить палитру в эмуляторе? Без четко обозначенных строк не понятно, как разобраться, где что. По-моему больше шансов с clrs_.rom, потому что там по положению на экране можно опознать код цвета и хоть всю палитру задать таблично.
У простого Вектора нет доработки синхры, тюнер картинку рвёт.
Тюнер с .02 тест clrs_
https://s8.hostingkartinok.com/uploads/images/2021/04/f2727578fc374e17c58c59f17aba312e.png
Это с минимальной контрастностью, которой смог добиться регулировкой на самом Векуторе. Иначе таблица либо заканчивается большим количеством белых ячеек, либо начинается с большого количества чёрных ячеек.
Интересно, между столбцами 3 и 4 я не вижу отличий.
Прикинул теоретические токи для 02. В принципе, на глаз очень похоже, инверсию в 4 и 5 столбце видно.
Вечером попробую численно сравнить...
https://s8.hostingkartinok.com/uploads/images/2021/04/92204d2261cbff5dd1a95481769f6632.png
Интересно, между столбцами 3 и 4 я не вижу отличий.
Там даже немного хуже, яркость в столбце R4 чуть-чуть меньше, чем в R3.
Да, и это видно на гистограмме.
В этом плане версия Вектора 01 мне больше нравится - там нет таких инверсий. Интересно, из каких соображений вообще поменяли номиналы резисторов...
Результаты в emu80 на основании теоретических расчетов по номиналам резисторов с гистограммами для версий 01 и 02.
А я зашел с другой стороны, набросал в матлабе скриптик, который:
1. Применил к скриншоту KTSerg с тюнера медианный фильтр 31x15
2. Взял яркости в центрах прямоугольников
3. Привел яркости к диапазону 0-1, а потом масштабировал в диапазон 0-255
https://i.imgur.com/VUlIKA0.png
https://i.imgur.com/rLdKbbY.png
ivagor, ты меня опередил, я хотел вечером подобное же сделать. А можно в числовом виде таблицу из 256 чисел?
А вот что я меня получилось теоретически:
.01
0, 13, 20, 34, 42, 56, 63, 76, 20, 34, 41, 54, 63, 76, 83, 97,
42, 56, 63, 76, 85, 98, 105, 118, 63, 76, 83, 97, 105, 118, 126, 139,
82, 96, 103, 116, 125, 138, 145, 158, 103, 116, 123, 137, 145, 158, 166, 179,
125, 138, 145, 158, 167, 180, 187, 201, 145, 158, 166, 179, 187, 201, 208, 221,
13, 27, 34, 47, 56, 69, 76, 89, 34, 47, 54, 68, 76, 89, 97, 110,
56, 69, 76, 89, 98, 111, 118, 132, 76, 89, 97, 110, 118, 132, 139, 152,
96, 109, 116, 129, 138, 151, 158, 172, 116, 129, 137, 150, 158, 172, 179, 192,
138, 151, 158, 172, 180, 194, 201, 214, 158, 172, 179, 192, 201, 214, 221, 235,
20, 34, 41, 54, 63, 76, 83, 97, 41, 54, 61, 75, 83, 97, 104, 117,
63, 76, 83, 97, 105, 118, 126, 139, 83, 97, 104, 117, 126, 139, 146, 159,
103, 116, 123, 137, 145, 158, 166, 179, 123, 137, 144, 157, 166, 179, 186, 199,
145, 158, 166, 179, 187, 201, 208, 221, 166, 179, 186, 199, 208, 221, 228, 242,
34, 47, 54, 68, 76, 89, 97, 110, 54, 68, 75, 88, 97, 110, 117, 130,
76, 89, 97, 110, 118, 132, 139, 152, 97, 110, 117, 130, 139, 152, 159, 173,
116, 129, 137, 150, 158, 172, 179, 192, 137, 150, 157, 170, 179, 192, 199, 213,
158, 172, 179, 192, 201, 214, 221, 235, 179, 192, 199, 213, 221, 235, 242, 255
.02
0, 17, 22, 40, 37, 54, 59, 76, 21, 38, 43, 60, 57, 75, 80, 97,
40, 58, 63, 80, 77, 94, 100, 117, 61, 78, 84, 101, 98, 115, 120, 138,
81, 98, 103, 121, 118, 135, 140, 157, 102, 119, 124, 141, 138, 156, 161, 178,
121, 138, 144, 161, 158, 175, 180, 198, 142, 159, 164, 182, 179, 196, 201, 218,
16, 33, 38, 56, 53, 70, 75, 92, 37, 54, 59, 76, 73, 91, 96, 113,
56, 73, 79, 96, 93, 110, 115, 133, 77, 94, 99, 117, 114, 131, 136, 153,
97, 114, 119, 136, 133, 151, 156, 173, 117, 135, 140, 157, 154, 171, 177, 194,
137, 154, 160, 177, 174, 191, 196, 214, 158, 175, 180, 198, 195, 212, 217, 234,
21, 38, 43, 60, 57, 75, 80, 97, 41, 59, 64, 81, 78, 95, 101, 118,
61, 78, 84, 101, 98, 115, 120, 138, 82, 99, 104, 122, 119, 136, 141, 158,
102, 119, 124, 141, 138, 156, 161, 178, 122, 140, 145, 162, 159, 176, 182, 199,
142, 159, 164, 182, 179, 196, 201, 218, 163, 180, 185, 202, 199, 217, 222, 239,
37, 54, 59, 76, 73, 91, 96, 113, 57, 75, 80, 97, 94, 111, 117, 134,
77, 94, 99, 117, 114, 131, 136, 153, 98, 115, 120, 137, 134, 152, 157, 174,
117, 135, 140, 157, 154, 171, 177, 194, 138, 155, 161, 178, 175, 192, 197, 215,
158, 175, 180, 198, 195, 212, 217, 234, 179, 196, 201, 218, 215, 233, 238, 255
А вот что я меня получилось теоретически:
.01 совпадает с тем, что мы считали с Ramirosом, .02 теоретически не считал.
А цифры по (обработанному) тюнерному скриншоту с .02 такие:
0 7 12 21 20 31 35 48
10 20 25 36 33 46 49 63
23 33 38 49 48 61 66 79
36 48 53 66 64 77 84 100
46 59 66 79 76 92 99 115
64 76 82 99 97 114 122 140
81 95 102 118 117 135 145 165
100 117 125 143 141 163 171 194
8 18 21 33 31 43 48 61
20 30 33 46 44 56 63 76
33 44 48 61 59 74 79 95
48 59 66 77 76 92 99 115
59 72 77 94 90 109 115 132
76 90 97 115 112 132 138 158
95 112 118 138 135 155 165 186
115 135 141 165 161 184 192 220
10 20 25 35 33 46 49 63
20 31 36 48 46 59 64 77
35 46 51 64 63 76 82 97
49 63 69 82 81 95 102 118
63 76 81 97 95 110 118 137
79 95 102 118 115 135 143 165
99 115 122 141 138 160 169 191
120 138 146 169 166 189 199 227
20 30 35 46 44 56 63 76
31 43 48 61 59 72 77 94
46 58 63 76 76 89 97 114
63 76 81 95 95 110 118 138
76 89 95 114 110 128 137 158
94 110 117 137 135 153 163 186
114 132 140 163 158 181 191 217
138 158 168 191 188 214 225 255
Не очень гладкий градиент на фотке 06Ц связан на мой взгляд в основном с отклонениями номиналов резисторов от идеальных. Поэтому имеет смысл попробовать решить более простую задачу - найти 16 уровней серого приблизительно соответствующих линейной шкале, в этом случае небольшие отклонения номиналов резисторов не испортят картину. Предлагаю такой вариант (https://disk.yandex.ru/d/XxsBs0OyjoPixQ). Скриншот из ч/б режима VV, в котором реализованы "теоретические" значения серого.
75226
Я тоже думаю, что дело в отклонениях номиналов резисторов. Можно, кстати, попробовать подобрать, чтобы получить картину, как на фотке.
А в чем смысл выделения 16 уровней?
С запозданием, bwclrs .02 тюнер:
https://s8.hostingkartinok.com/uploads/images/2021/04/f1000bce2d6e82affdb089522cbcc70a.png
Настройки яркости/контрастности такие-же как в прошлом скрине для clrs_
gray1601 .02 тюнер
https://s8.hostingkartinok.com/uploads/images/2021/04/a3f8d3470a9d3883a65ded9b6b778f44.png
KTSerg, спасибо, но и bwclrs и gray1601 только для 06Ц, не для .02. Пробовал найти условно говоря общий серый знаменатель для 06Ц и .02 и даже частично получилось - нашлись 12 цветов, которые примерно одинаковые при одинаковых значениях палитры. Но хочется 16, а не 12 значений и чтобы примерно линейные.
А в чем смысл выделения 16 уровней?
4 бита, 16 оттенков серого, максимум того, что может показать вектор через ч/б видеовыход без мерцания.
gray1601 06Ц тюнер
лучший скриншот из нескольких десятков
https://s8.hostingkartinok.com/uploads/images/2021/04/036b43db6c8328a95d4c66eba8c7ba63.png
Если есть желание потестировать ч/б-выход в Emu80:
http://emu80.org/v4beta/Emu80qt_40355_test.7z
(Вектор, ПК8000 и Львов)
- - - Добавлено - - -
KTSerg, посмотреть бы еще на clrs_ на 01 - хотя бы фото с монитора...
Попробовал все же найти компромиссные 16 цветов дающие примерно одинаковую яркость ч/б выхода для 06Ц и .02, соответствующий тестик (https://disk.yandex.ru/d/E6xIFZzOh617TQ).
75227
Уболтали :)
Сделал доработку синхры на 06Ц по принципу, который предложил Tim0xA.
Единственно, на тюнере изображение темновато, выкрутил на Векторе всё на максимум... ещё чуток маловато...
В архиве тесты на тюнере, включая gray16u.
Попугаи в 64с не мерцают :)
О, здорово! :)
ivagor, раз уж у тебя есть готовый скриптик, проанализируешь clrs_ на 01 по аналогии, как уже делал с 02?
Яркости из 14235536.PNG растянутые в диапазон 0-255
0 9 13 21 26 36 41 52
13 21 24 33 40 50 55 67
26 35 41 50 57 67 73 85
41 52 57 67 73 85 91 103
57 67 72 84 90 103 108 121
73 84 90 102 108 121 129 143
93 103 109 124 131 146 155 171
111 124 131 146 155 171 183 202
6 15 19 27 33 44 49 59
19 28 32 43 49 59 64 76
35 44 49 61 67 77 84 95
50 61 66 77 84 95 102 113
66 76 82 93 102 112 118 133
82 94 100 112 120 134 142 157
103 115 121 134 144 160 169 188
122 135 143 158 170 188 200 222
10 18 23 31 37 48 54 64
23 32 37 46 53 64 70 81
39 49 54 64 72 82 89 100
55 64 71 82 89 100 107 120
70 81 88 99 106 118 126 139
88 99 106 118 126 139 148 165
107 120 128 140 151 167 176 196
128 142 149 166 178 196 209 232
18 26 31 41 46 57 63 75
31 41 46 57 63 73 80 91
48 58 63 75 81 93 100 111
64 75 81 93 100 111 118 131
80 91 98 109 117 130 138 153
98 109 117 129 138 153 162 182
118 133 139 155 165 183 193 216
140 156 165 183 194 216 229 255
Все же на мой взгляд это намного лучше, чем в .02, непонятно, зачем там решили испортить.
KTSerg, если будет возможность пожалуйста сграбь тюнером gray16u и с 02.
- - - Добавлено - - -
Попугаи в 64с не мерцают
Тюнер грабит два соседние кадра в четные/нечетные строки и если на это ориентироваться, то получился бы режим с удвоением разрешения по вертикали, но имхо это слишком специфично.
Хотя если применить простой деинтерлейсинг, то получится примерно как раз примерно то что нужно, т.к. он смешает соседние строки.
Моделирование показало, что если в модели 01 сопротивление резистора 7-го разряда (R26) изменить с 3,3к на 3,6к, то наблюдается очень хорошая корреляция между теоретическими и экспериментальными значениями (графики смогу выложить позже). Можно попросить уважаемого KTSerg посмотреть, какого номинала стоит резистор R26 в его экземпляре Вектора?
P.S. Результаты для 02 пока не смотрел.
Моделирование показало, что если в модели 01 сопротивление резистора 0-го разряда (R26) изменить с 3,3к на 3,6к, то наблюдается очень хорошая корреляция между теоретическими и экспериментальными значениями (графики смогу выложить позже). Можно попросить уважаемого KTSerg посмотреть, какого номинала стоит резистор R26 в его экземпляре Вектора?
P.S. Результаты для 02 пока не смотрел.
Странный результат. Если смотреть на остальные номиналы, то для линейности ЦАП нужен номинал 3.2к (или ещё меньше), т.к. предыдущий 1.6к, а следующий (на схеме не разборчиво, должно быть больше 6к) 5.1к.
KTSerg, в пределах одного цвета линейность соблюдается (3300-5100, 820-1600-3300, 1600-3300-5100).
Исправил ошибку в предыдущем сообщении, R26 - это 7-й разряд. относится к синему...
- - - Добавлено - - -
3300 все-таки максимально близко к требуемому 3200 из типовых номиналов резисторов.
А вот почему 5100 - не знаю, логичнее было бы поставить 6200 хотя бы...
- - - Добавлено - - -
Я имею в виду, что, возможно, в твоем экземпляре Вектора вместо 3300 поставили 3600, что вызвало еще бОльшую нелинейность...
По крайней мере такой вывод можно сделать по картинкам с тюнера.
Если бы авторы и изготовители вектора (и не только) серьезнее относились к точности цветопередачи, то могли бы сделать как в современных дешевых (без видеоЦАП) поделках - последовательное и параллельное соединение резисторов, тогда и одного номинала хватило бы. Да, крошечное усложнение схемы, зато линейность заведомо лучше.
Если-бы номиналы у разных цветов отличались, можно было-бы предположить, что не линейность сделана специально, что-бы отличить на ч/б-телевизоре например красный от зелёного (одной интенсивности).
В те времена не у всех были цветные телевизоры, да и доступные мониторы в основном были ч/б.
Мне для Вектора был выделен маленький ч/б автомобильный/переносной телевизор, а к цветному был доступ если оставался один дома, или приходили гости, и толпой играли на Векторе во что-то типа "Поле чудес".
Вряд ли в векторе для видеоЦАПа использовали прецизионные резисторы, в лучшем случае 1й класс точности (+-5%), и при неудачном стечении обстоятельств это может дать заметные отклонения. Пока неизвестно, но я бы предположил, что основная причина отклонений в этом, а не в другом номинале. А если еще и другой номинал, то совсем нехорошо.
- - - Добавлено - - -
Вобще все относительно, у вектора можно сказать жемчуг мелкий, а ведь бывает так, что яркости в ч/б режиме совсем не соответствуют стандартным (.6 G, .3 R, .1B).
Может быть все-таки это не .02 принципиально испорчен, а просто KTSerg-у достался такой экземпляр? Все равно прикольно конечно иметь возможность эмулировать в эмуляторе разброс резисторов.
svofski, так другие номиналы резисторов на .02 задокументированы в схеме. Так что не просто испортили, а еще и задокументировали это :(
В эмуляторе сделал пока просто версию .01 как более правильную и более распространенную (коэффициенты для .02 закомментированы в исходнике). Можно, конечно, и задание номиналов резисторов в конфиге реализовать, но что-то я не думаю, что в этом есть особый смысл...
- - - Добавлено - - -
Обещанные картинки. Корреляция между теоретическими и экспериментальными значениями при номиналах резистора R26 3,3K (как в схеме) и 3,6К:
https://s8.hostingkartinok.com/uploads/images/2021/04/96d370fd447cc91b2a69d41552f8bd36.png
https://s8.hostingkartinok.com/uploads/images/2021/04/4d0d768f04c37c070f52b10e0f3c1ada.png
Значимого улучшения корреляции при изменении номиналов других резисторов не заметил, так что стоит проверить именно R26.
...
Значимого улучшения корреляции при изменении номиналов других резисторов не заметил, так что стоит проверить именно R26.
R26 - это из простого Вектора?
На обеде успел посмотреть у 02-го, только один номинал R51 установлен 5.1к, хотя в схеме указан номинал 4.7к 8()
Остальные резисторы или с цветовой маркировкой, или установлены маркировкой к плате.
Вечером мультиметром проверю все номиналы резисторов ЦАП и простого Вектора и 02-го.
На счет значимости градаций серого.
Я говорил, что в 90-ых пользовался ч/б телевизором. в 92-ом к 8 марта сидел, рисовал розу для распечатки на принтере.
Естественно рисовал подбирая оттенки серого, и принтер настраивал на соответствие экранному изображению.
Вот открытие, что на разных экземплярах Вектора оказывается она выглядела по разному... из-за отклонений номиналов резисторов и в разных версиях Вектора из-за разницы в параметрах ЦАП...
KTSerg, да, R26 из простого.
Хотя думаю, что действительно нужно все посмотреть - и с простого, и с .02 - и сравнить со схемой.
Подозреваю, что практика установки деталей близких номиналов в то время была довольно распространена...
- - - Добавлено - - -
Оказывается, нумерация элементов на схемах отличалась: R15, R22, R20, R14, R24, R28, R30, R26 по схеме на обычном Векторе и соответственно R50, R51, R53, R54, R52, R58, R61, R63, R59 - на .02
...
Оказывается, нумерация элементов на схемах отличалась: R15, R22, R20, R14, R24, R28, R30, R26 по схеме на обычном Векторе и соответственно R50, R51, R53, R54, R52, R58, R61, R63, R59 - на .02
R50 - это резистор "уровень чёрного", а не ЦАП смешивающий RGB. (если я правильно помню)
Да, R50 я нечаянно "прихватил"...
svofski, так другие номиналы резисторов на .02 задокументированы в схеме. Так что не просто испортили, а еще и задокументировали это
В эмуляторе сделал пока просто версию .01 как более правильную и более распространенную (коэффициенты для .02 закомментированы в исходнике). Можно, конечно, и задание номиналов резисторов в конфиге реализовать, но что-то я не думаю, что в этом есть особый смысл...
Немудрено представить себе, что кто-то ошибся номиналом при перерисовке новой схемы. Не знаю, какие копии были на производстве, но по тем, что прилагались к потребительским экземплярам, часто можно только догадываться, что там было. А схема-то "цифровая", все знают, что +/- килоом тут никто не заметит.
Если бы это было как MOS6581, в котором исправили багу и куча музона стала звучать не так, в эмуляции разброса резисторов был бы смысл. Но на Векторе кажется нет таких требовательных произведений искусства. Но как же результаты таких дотошных исследований, взять и забыть?
Посмотрел еще корреляцию на .02 - явных расхождений не увидел, разве что кроме R51 еще может быть R61 не 1000, а в районе 1050 Ом, но это уже в пределах допуска 5%...
- - - Добавлено - - -
Но как же результаты таких дотошных исследований, взять и забыть?
в комментах формулу расчета напишу ;)
Посмотрел еще корреляцию на .02 - явных расхождений не увидел, разве что кроме R51 еще может быть R61 не 1000, а в районе 1050 Ом, но это уже в пределах допуска 5%...
...
Кроме R51 все номиналы как в схеме.
- - - Добавлено - - -
...
KTSerg, если будет возможность пожалуйста сграбь тюнером gray16u и с 02.
...
https://s8.hostingkartinok.com/uploads/images/2021/04/111d7546726de68109191858c9403cf2.png
Кроме R51 все номиналы как в схеме.
На простом (.01) Векторе тоже?
На простом (.01) Векторе тоже?
На простом Векторе все номиналы резисторов ЦАП соответствуют схеме.
Я говорю об обозначениях.
Реальное сопротивление очень сложно замерять, т.к. замеры делались внутрисхемно и плюс слой лака, даже иголкой тяжело протыкается.
У некоторых резисторов значения абсолютно совпадали с маркировкой, у других как ни старался, отличия были в 100-200 Ом (у больших номиналов).
В таком случае затрудняюсь объяснить расхождение. Может быть, по какой-то причине чуть ниже напряжение на конкретном выходе логического элемента...
В общем-то скорее все в пределах допусков. А заманчиво было бы объяснить разницу установкой резистора близкого номинала.
Может быть, как раз у R26 и была самая большая разница?
Вспоминая, как нас деды учили советской схемотехнике, - 20% отклонения в номинале отдельного элемента не должно приводить к изменению функциональности узла и 50% отклонения не должно приводить к выходу из строя - немного умиляют изыскания в поиске трушного цвета на Векторе.
Ну, исследовали, поняли, что отклонения номиналов могут довольно сильно влиять на цветовую палитру, не говоря уж о том, что в конкретном экземпляре вполне может оказаться и другой, близкий, номинал. На а средний трушный цвет наверное соответствует номиналам :)
Близкие друг к другу яркости в программах не стоит использовать (если ориентироваться на разные реалы), а 16 более-менее равномерно расположенных вполне приемлемо.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot