nedoPC.org

Ну, фонт для консоли должен все-таки лежать не в основном ОЗУ, чтоб не мешался. А вот возможность подзагрузки фонта юзера должна быть в АТМ3 - это точно.

эт хорошо. на чём ? sram дорого, dram под бооольшим вопросом (хотя Камиль вроде где-то берет 2м*8 ), sdram опять же - не хватит скорости epm70xx...



а не пофиг, когда 4мб памяти ?

Че, даже 66МГц не осилит? Тогда EDOшки, но там скорость максимум 50нс (20МГц).

Дык Ромина-то идея - что основная память - у ЦПУ, а если он в неё пишет по дисплейным адресам, то автоматически копируется в СРАМ видеоконтроллера! А в ней не обязательно дублировать всю основную, значит и для кракозябров место найдётся.

ЕДОшки - это не СДРАМ, а ДРАМ. Почуй разницу =)
А имхо, даже если 133мгц СДРАМ прикрутить, всё равно её скорости не хватит при рандомном доступе зетника на 20 мгц. Ведь там только в пределах ряда можно рандомно читать (по ворду на байт, причём адреса кормятся на несколько (2-3) тактов раньше, чем данные приходят; видали в пц-биосе CAS latency? - это оно), а если вылез - надо текущий ряд закрывать, а новый открывать. Хорошо для процов с резиновым кешем и предвыборкой, а для зетника?... Имхо ДРАМ нужно боле-мене шуструю, как раз у зетника и место для регенерации предусмотрено в циклах шины.

15-битные. Т.е. по 5 бит на компоненту. Чтоб цветастые картинки казать =)

RGB555? Маловато будет - надо как минимум RGB565 (то бишь 16 бит на пиксел)

Ну я знаю разницу и что? А CAS Latency я знаю не из BIOSа PC, а из датащита на SDRAM. Есть у них пакетные режимы BURST, и никто не отменял интерливинг. В PC то его применяют. Не забываем про рефреш. А в общем, при PC133 получается следующие тайминги по датащиту http://www.chipinfo.ru/vstock/search.ht ... IC42S16800 :
Чтение: 5 тактов (CL2) и 6 тактов (CL3)
Запись: 4 такта (CL2) и 5 тактов (CL3)
* Запись длинная из-за precharge. Тайминги для рандомного чтения/записи 1 слова (совпадающего по разрядности с микросхемой ОЗУ).
Отсюда следует: 133М/5=~26М обращений при CL2 и 133М/5=~22М обращений при CL3. Для записи соответственно ~33М и 26М. И при этом еще надо ее регенерировать. Нда, для вашей затеи не хватит... Думаю задумка с теневым видеобуфером "только на запись" более реальна. Только ее надо инициализировать, во избежания разных данных на экране и в ОЗУ.

Не пофиг. ОЗУ предназначено для программ пользователя, и нечего ее всякими лишними данными забивать.

Не надо инициализировать . Запись в видеопамять и основную память идет одновременно (хоть они и разделены).

Для спека оптимальное 1мб, ну ЛВД например считает что 2мб (2 образа диска+ аласм)... больше ставить туда памяти безсмысленно.
ПОэтому наверно оптимальное использовать СРАМ, не такая уж она и дорогая. Хотя конечно у ДРАМ выводов меньше, но для нее рефреш нуно делать.

Как это не надо? При включении инфа в них различается. Нужно как минимум одно полное стирание экрана.

Ну, у меня тут ориентир - Спринтер. Не считаю лишними еще два дополнительных метра. Особенно если-таки будет (а она будет) графическая ОС под расширенные экраны: вот куча спрайтов и прочей графики как раз без проблем и разместим...

А кому от этого холодно ли жарко? Ведь по любому, когда комп рестартует BIOS, перед тем как что-то начать на экран выводить, его почистит...

Ага что и делает любая программа работающая с экраном.
Зачем какие дополнительные фигни придумывать- не нуно...
Т.е. я хотел сказать, что это по любому делается, в схеме и софте это учитывать НЕ НУЖНО.