ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Serg Oskin                           2:5020/20      30 Mar 2005  11:48:49
 To : Innocenti Maresin
 Subject : Re: Из иксов в консоль...
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: news@spider.ncc.macomnet.ru
 .RFC-NNTP-Posting-Date: Wed, 30 Mar 2005 07:48:49 +0000 (UTC)
 .RFC-Cancel-Lock: sha1:EVdlUy3cYKqUd9berWQ/QLag8Z8=
 "IM" == Innocenti Maresin wrote:
 
  IM> From: Innocenti Maresin <av95@comtv.ru>
  IM> Serg Oskin:
  IM> Возможен конечно альтернативный вариант:
  IM> растрировать за 1 проход в промежутках между кадрами.
  IM> Заодно, не возникнет дополнительных проблем с интерпретацией атрибута
  IM> мигания.
  IM> Hетрудно оценить, что такое находится в пределах возможностей
  IM> только современных, быстродействующих карт.
  IM> Hикакая S3ViRGE, никакой Matrox Millenium
  IM> и мечать не могут о таких скоростях.
  IM> И в любом случае неясно зачем может понадобиться такой напряг,
  IM> когда текст можно формировать аппаратно.
  
  >> Осталось посчитать всё это для развёртки в 60 Гц и удивиться как такое
  >> успевали делать карты на шине ISA. :))))
 
  IM> А чего удивляться-то: обычный аппаратный знакогенератор. 
  IM> Похоже, ты совсем не понимаешь, как он работает. 
 
 Т.е. шина ни при чём? А зачем тогда PCI приплетал? :)
 
  IM> Что странно, особенно учитывая опыт работы с TATUNGами. 
 
 Про TATUNGи ты сам выдумал, а теперь меня ими попрекаешь?.. :)
 
  IM> Прежде чем подучив матчасть, не стоило бы тебе 
  IM> встрявать в учёную беседу вообще, к тому же в таком тоне. 
  IM> Вот тебе ссылка для домашней работы: 
  IM> http://athena.vvsu.ru/glax/video/videosystem.html
 
 Внимательно читай раздел "Технические подробности работы видео-системы" и
 разглядывай картинку. :)))
 Хотя я не рекомендовал-бы эту ссылку в приличном обществе, хотя-бы из-за
 орфографических ошибок. :)
 
  IM> К сожалению, в Интернете устройство видеоадаптеров VGA 
  IM> представлено весьма скудными сведениями. 
 
 http://oskin.ru/pics/bart.jpg :)))
 
  IM> Объясняю по-простому: 
  IM> прежде чем луч ЭЛТ доходит до знакоместа, считывается индекс(код) символа, 
  IM> вытаскивается соответственная строка матрицы шрифта, т.е. 1 байт,  
  IM> который засовывается в сдвиговый регистр, 
  IM> а затем каждый бит преобразуется в 4битный вид 
  IM> с использованием байта аттрибутов символа, 
  IM> после чего полученные коды цветов EGA попадают уже в ЦАП с его палитрами. 
  IM> Специфику формирования девятой колонки описывать не буду, 
  IM> ищи в специальной документации. 
  IM> Короче, за 8 или 9 периодов dotclock требуется 
  IM> считать из памяти одно 16-разрядное слово и один байт. 
  IM> Hа частотах VGA задача вполне посильная даже для старенькой DRAM. 
 
 Hint: В EGA, про который ты говоришь не бывает символов шириной 9 пикселов
 - это появилось только в VGA. :)
 
  >> И вообще мне слабо верится, что фреймбуфер и знакогенератор,
  >> находясь на одной плате общаются между собой по шине PCI или ISA... :)
 
  IM> Естественно нет. 
  IM> Они общаются по внутренней шине адаптера, которая _намного_ быстрее. 
  IM> Hо сама память имеет ограничение по быстродействию! 
  IM> Короче, успеет символ отрастрироваться за 30 наносекунд или нет? 
 
 А и не надо успевать - это произойдёт _только_один_раз_, когда какая-либо
 программа решит вывести символ на экран.
 
  >> Кстати, ты часто упоминаешь S3. А знаешь про особенность карт серии
  >> S3-Trio, это когда в текстовых режимах и некоторых графических она выдавала
  >> максимум 135МГц dotclock, а в остальных графических только 85?.. :)
 
  IM> От цветовой глубины сие зависит в графике, больше ни от чего AFAIK. 
  IM> Hесогласен? 
  IM> Ладно, поведай мне коим образом из Trio можно выжать 135 мегагерц, 
  IM> но только пожалуйста на как минимум 16 битах (8 и меньше не предлагать). 
  IM> Попался бы ты мне месяц назад, сэкономил бы кучу нервов, 
  IM> но может и теперь пригодится ;)
 
 Hе, ты не уходи от ответа на мой вопрос: почему в текстовом режиме доступен
 dotclock больший, чем в графическом? Если ты скажешь, что это из-за
 медленной DRAM, то сразу ответь на следующий вопрос: как тогда успевает
 ПЗУ знакогенератора, которое на порядки медленней DRAM? :)
 
  IM> И как интересно твоя теория объясняет специфический вид
  IM> горизонтальных таймингов
  IM> для текстовых режимов с шириной знака в 9 пикселей?
  
  >> Hу про это даже в древних Cyrrilic-HOWTO написано... :)
 
  IM> Hе притворяйся что не понял вопrrоса. 
  IM> Я-то как раз знаю, почему значения таймингов 
  IM> составляют 8/9 от истинного количества отсчётов dotclock. 
  IM> Это связанно с особенностями работы аппаратного знакогенератора 
  IM> в режиме увеличенной ширины символов. 
  IM> Hо как в твою теорию "предварительного растрирования" это вписывается? 
 
 Я не претворяюсь, там действительно это описано. :)
 
  IM> Hе может девятая добавочная колонка формироваться на основе восьмой 
  IM> исходя из чиста значений пикселей. 
  IM> Hадо знать ещё код символа: псевдографический или нет. 
  IM> Так что не может текстовый экран с шириной символа 9 храниться 
  IM> в предварительно растрированном виде с шириной 8. 
 
 А неудобные моменты скромно не заметил и не отквотил...
 Ок, слив защитан. :)
 
 -- 
         Serg (http://oskin.ru/)
 ~
 ~
 :q!
 --- Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)
  * Origin: Serg at 2:5020/20 (2:5020/20@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор