Современный "Спектрум"

[PegasResearch]

Была бы _возможность_ делать one frame

Споры о "плавности" идут давно - ещё до появления 3D сторонники приставок убеждали хозяев ПК, что благодаря FPS>>24 обеспечивается "невиданная плавность" и т.п. Но это скорее философская сторона вопроса: смотреть надо на уже готовое приложение. Возможность будет как "работать во фрейм" (непонятная для меня терминология), так и выдавать 30FPS.

Дело в том, что может-же быть такой вариант, когда
пиксели чередуются в спрайте - прозрачный/не_прозрачный.

Абсолютно согласен. Но тут - либо автор спрайтов уменьшает в них количество дыр ;-), либо копируем программно. При этом не стоит забывать, что копирование фона всё равно производится DMA. Всё будет зависеть от общего количества и размера спрайтов.

Большие спрайты не скопируешь с учётом альфа-канала.

Согласен, но для режима 640х480 8bpp@75 скопировать можно ;-).

Хотя, в принципе, без альфы жить можно.

А вообще - проблема альфа-канала решается аналогично проблеме дырчатости: делаем меньше дырок/убираем альфаканал и все счастливы ;-)

А если серьёзно, то дырчатость - свойство хорошее, позволяет в том числе "альфа-канал" реализовать. Например, сделать тень с помощью маски "шахматная доска". Однако для начала надо сделать прототип, в будущем можно будет добавить в ПЛИС какой-нибудь хитрый DMA (в том числе с учётом альфа-канала). Но по-моему всё решиться программно - см ниже.

Задача. Есть источник 16 бит шириной w выстотой h, есть альфа-маска источника 8 бит, есть приёмник 16 бит. Необходимо скопировать источник в приёмник с учётом альфы.

Решение. Алгоритм основан на последовательном доступе к SDRAM. Источник, альфа-маска - в основной памяти, приёмник - видеопамять. Координаты не учитываются. Считается, что за один такт SDRAM контроллера CPU успевает сделать 2 такта. Выполнение любой команды CPU - 1 такт, все регистры - 32 бит.
Формула альфы:
результат = (1-альфа/255)*результат + альфа/255*источник = результат-альфа*(результат+источник)/255

1. Считать строку альфы в кеш (w байт) [SDRAM w/2 тактов | CPU 2*w тактов - чтение, addr++] - для CPU это последовательное чтение w байт памяти, с командой залочивания кеша.
2. Читать очередную точку источника в R1 [SDRAM 1 такт | CPU 2 такта - чтение, addr++]
3. Читать очередную точку приёмника в R2 [SDRAM 1 такт | CPU 2 такта - чтение, addr++]
4. Читать очередную точку альфа в R3 [SDRAM 1 такт | CPU 2 такта - чтение, addr++]
5. R1 = R1+R2 [CPU 1 такт]
6. R1 = R1*R3 [CPU 1 такт]
7. R1 = R1/255 [CPU 1 такт] - возможно реализовать сдвигом
8. R2 = R2-R1 [CPU 1 такт]
9. Записать очередную точку приёмника из R2 [SDRAM 1 такт | CPU 2 такта - запись, addr++]
10. Если ещё не вся строка, то перейти на 2 [CPU 2 такта]
11. Вычислить новые адреса [CPU~4 такта]
12. Если ещё не все линии, то перейти на 1 [CPU 2 такта]

Итого имеем 8hw 133МГц-тактов.
То есть если просто для пересылки память-видео 16-битного растра мы тратим порядка 2hw тактов шины (по сути, неважно, DMA или процессор), то с альфа-каналом - в 4 раза медленнее. Однако, для 640х480х16бит имеем время наложения 18.4мс, что неплохо.

Практически же, если имеем постоянно сдвигающийся экран и общую площадь спрайтов порядка 25% - или 75000 точек, то время на копирование экрана (307200 точек) плюс копирование спрайтов с альфой составит (в тактах SDRAM) порядка 8*75000+2*307200 = 914400 тактов или около 7мс. Замечу, что 75Гц - это периоды в 13мс. То есть минимум 40% процессорного времени у нас в распоряжении.

Так что программный альфа-канал не так уж и плох. Для 8 бит на точку вычисления будут сложнее, зато можно будет удвоить скорость перекачки точек ;-)

Какая планируется стоимость готового компа?

На сегодняшний момент оценена себестоимость, которая составляет сумму около 100$ ;-) ( 62$ стоит набор микросхем оптом ). Это для 64Мб ОЗУ и 1Гб флеш. Думаю, через полгода-год, когда начнётся серийный выпуск, можно будет за те же деньги ставить 128Мб/8Гб ;-) По крайней мере, плату исходя из этого развожу ;-)

P.S. Все вычисления и алгоритм даны в первом приближении!

newart,

то в текстовой читалке я бы тоже хотел иметь фрейм

- Вероятно, тоже имеешь в виду "работу в фрейм"? Откуда такая терминология? ;-)
Кстати, разница между кино (почему там хватает 24кадра) и анимациями в компе (почему не хватает) - была установлена довольно давно - нет размытия при движении, которое наблюдал бы глаз в случае реального движения. В кино размытие есть (время экспозиции кадра), а в играх - нет. Поэтому FPS поднимают заоблачно, чтобы глаз не заметил отсутствие разымытия. Если в набор 2D спрайтов добавить переходные картинки (с размытием), то 30FPS - предел мечтаний. Жаль, что разработчики игр плохо знакомы с подобными эффектами. С другой стороны, порой проще поднять FPS, чем дорисовывать спрайты (хотя при подготовке спрайтов из 3D моделей в той же 3DSMAX проблем не возникает).
В 3D движки (OpenGL, DirectX) добавили размытие при движении не так давно, и редко кто его использовал...

Ну вот теперь прикинь сколько ресурсов сьест этот альфаканал.

Расчёты я привёл. Вывод - альфа-канал использовать реально для 640х480 16bpp@75Hz до 50% спрайтов + скроллинг фона.

это дело на 1.4гг не тянет фрейм. Возможно тут дело в связке windows->dx->кривые дрова и т.д?

В своё время (года 4 назад) тестировал GeForce MX400. Вывод - на 40% быстрее, чем Riva TNT2 Vanta 8Mb (урезанная TNT2!!!, AGP1x!!!). Тест брал 3D Mark 2000, процессор был Celeron 566, Celeron 733, Pentium III не помню сколько, 700 вроде. Тест мне запомнился, т.к. показал, что карта стоитмостью 200 рублей не много хуже карты за 2000 рублей. Брал другие карты (MX200, какую-то попродвинутей MX400) - результат различался только когда размеры выходили за область видеоозу. Риторический вопрос - кто виноват и что делать?

1.4ГГц - вероятно, шина к памяти у тебя DDR400, то есть 64бит 800МГц = 6.4 Гб/сек пропускает. AGP 4x даст 66*4*32бит = 1 Гб/сек. Процессор может выполнять команду за такт (учтём кеш и т.п.) - 1400MIPS имеем (не RISC команд!). Вроде всё круто... И снова риторический вопрос - кто виноват и что делать?

Возможно, программист отключил аппаратные возможности видеокарты в своём приложении (использовал неверные флаги/не ту функцию). Возможно, программист не скопировал спрайты в видеопамять. А ещё, возможно, установленные дрова для DirectX 9.0c мешают жить плате, которая аппаратно девятый DX не тянет ;-) Уверен, что можно добиться небывалых высот в DX (благо, сам добивался) - но надо разбираться во всех тонкостях и не только софта. Если программист вырос на Яве/Питоне/С# - то не стоит ожидать быстродействующей программы. И вовсе не потому, что Ява этого не позволяет. А потому, что там будут настолько страшные места (в виде строк через list ;-) ), что об оптимизации говорить не приходится.

К сожалению, производителям ПК выгодно, если железо будет подтормаживать - это заставит пользователей покупать новое железо. Что мешает в Windows вставить код задержки CPU? ;-)))

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

Да, и если говорить о "рывках" в Windows - так это нормально: режим soft time ;-) На приставках-то real time юзается.

[Advertiser]

[newart]

Споры о "плавности" идут давно - ещё до появления 3D сторонники приставок убеждали хозяев ПК, что благодаря FPS>>24 обеспечивается "невиданная плавность" и т.п.

Благодря Frame Rate = Refresh Rate.

- Вероятно, тоже имеешь в виду "работу в фрейм"? Откуда такая терминология? ;-)

Ее используют (даже юзеры) на спектруме лет 15, если не больше.

Кстати, разница между кино (почему там хватает 24кадра) и анимациями в компе (почему не хватает) - была установлена довольно давно - нет размытия при движении, которое наблюдал бы глаз в случае реального движения.

Дело не в этом. А в Frame Rate = Refresh Rate. Если TV/Моник будет иметь Refresh Rate = 25 то при 25 FPS все будет плавно.
К слову, на старых теликах есть "размытие" за счет после свечения люминофора, но оно не спасает.

В своё время (года 4 назад) тестировал GeForce MX400. Вывод - на 40% быстрее, чем Riva TNT2 Vanta 8Mb (урезанная TNT2!!!, AGP1x!!!). Тест брал 3D Mark 2000,

Тесты нужно самому писать.

Возможно, программист отключил аппаратные возможности видеокарты в своём приложении (использовал неверные флаги/не ту функцию). Возможно, программист не скопировал спрайты в видеопамять. А ещё, возможно, установленные дрова для DirectX 9.0c мешают жить плате, которая аппаратно девятый DX не тянет ;-) Уверен, что можно добиться небывалых высот в DX (благо, сам добивался) - но надо разбираться во всех тонкостях и не только софта. Если программист вырос на Яве/Питоне/С# - то не стоит ожидать быстродействующей программы. И вовсе не потому, что Ява этого не позволяет.

Если бы это был еденичный случай то можно было бы списать это на перечисленные тобой варианты. Но тормоза во ВСЕХ играх. Есть только 1 игра которая в винде стабильно работает во фрейм даже на 700 дюроне и RivaTNT это Bud Redhead: http://www.bigfishgames.com/download...ead/index.html
Возможно дело в том что он написана чуть ли не под DX3-5.

[PegasResearch]

Благодря Frame Rate = Refresh Rate.

Дело не в этом. А в Frame Rate = Refresh Rate.

Ага, если мы что-то выводим, то неравномерности будут наблюдаться и при >>24 FPS если FPS!=RPS - так как в каких-то группах кадров изменений может не быть вообще и FPS "локально" упадёт до 0.
Например, при RPS 60Гц и FPS 30Гц если первую половину секунды показать все кадры - то на вторую половину секунды останется один кадр ;-) Итого на второй половине секунды FPS = 0. Это всё мифы насчёт FPS==RPS: просто мало кто из программистов слышал про ФАПЧ или хотя бы таймер ;-) - а при работе FPS==RPS таких проблем не возникает, вот всё и крутится "гладенько". Но проблема, повторю, решаема. Надо только проги нормально писать ;-) А не полагаться, что "DirectX сам всё засинхронизирует" :-)

К слову, на старых теликах есть "размытие" за счет после свечения люминофора, но оно не спасает.

И не удивительно, так как это не размытие. На "старых теликах" эффекта "размытия" можно добиться, если полоса пропускания видеотраткта << частоты точек. Например, когда выпускался оригинальный ZX-Spectrum, он подключался через антенный вход и использовал кодирование цветов (PAL/NTSC) - в результате получался "анти-алиасинг" - размытие, вызванное инерционностью (читай - низкой полосой пропускания) цветового тракта. Кстати, на мониторах графика ZX смотрится уже по-другому - как раз из-за отсутствия такого эффекта. А вообще, почитай-ка по этому поводу "историю Спека" Конана.

Тесты нужно самому писать.

Насмешил :-) :-) :-) ОС тоже надо самому писать, а ещё желательно самому спаять монитор для Спека (про спек я уж и не говорю ;-) )

Если бы это был еденичный случай

Неужели ты думаешь, что игры на ПК пишут профессионалы?! DX3-5 должен нормально работать - для совместимости DX отживших версий не меняется. У меня на P-200 640x480 16bit DX5 всё работало "во фрейм" :-) И это без поддержки со стороны видеокарты.

А вообще, такие вопросы лучше обсуждать не на форуме про ZX!!! :-Z Есть куча ПСшных игровых форумов, там всё доступно объясняется ;-).

Вообщем, вопрос с "работой во фрейм" считаю закрытым. Будем двигаться дальше. Есть комментарии-пожелания по звуку?

[Valen]

То есть минимум 40% процессорного времени у нас в распоряжении.

К результатм твоих расчётов, в общем случае,нужно добавить ещё время уходящее на выборку каманд+данных из SDRAM.
Т.к. полностью уместить в кэше ЦПУ (16+16КБ), можно только либо демы
либо небольшие игры.

Возьмём общий случай, когда код+данные программы больше кэша
скажем раз в 10.
Как думаешь, какой процент попадания в кэш, будет в таком случае?

[newart]

У меня на P-200 640x480 16bit DX5 всё работало "во фрейм" :-) И это без поддержки со стороны видеокарты.

"Всё" это 1 или 10 слоев? это 100 или 1000 тайлов? refresh rate какой 50 или 100?

Ага, если мы что-то выводим, то неравномерности будут наблюдаться и при >>24 FPS если FPS!=RPS - так как в каких-то группах кадров изменений может не быть вообще и FPS "локально" упадёт до 0.

Я говорю о примере скроллирования экрана, а не про анимацию.
Тоесть каждый фрейм беграунд скролируется допустим на 3 пикселя.

Кстати, на мониторах графика ZX смотрится уже по-другому - как раз из-за отсутствия такого эффекта. А вообще, почитай-ка по этому поводу "историю Спека" Конана.

"Антилиасинг" есть и при scart>tv. Что мне конана читать, фирменный спектрум как и российские клоны стоят от меня в трех метрах на столе и не редко юзаются.

А вообще, такие вопросы лучше обсуждать не на форуме про ZX!!! :-Z Есть куча ПСшных игровых форумов, там всё доступно объясняется ;-).

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

[Vasil]

На сегодняшний момент оценена себестоимость, которая составляет сумму около 100$ ;-) ( 62$ стоит набор микросхем оптом ). Это для 64Мб ОЗУ и 1Гб флеш. Думаю, через полгода-год, когда начнётся серийный выпуск, можно будет за те же деньги ставить 128Мб/8Гб ;-) По крайней мере, плату исходя из этого развожу ;-)

Неплохая задумка (цена девайсины тоже разумная) и если этот проект выльется в реальное железо, то я купил бы это. Только одна непонятка - юзать в качестве замены винта флэш-накопитель ?!. Вот кусок статьи по флэшкам из журнала "Железо" за май 2007 года:

=== cut ===
Не работайте с файлами, открывая их непосредственно с flash-накопителей!. В этом случае операционная система и целевая программа производят множество операций чтения-записи на носитель, который на это не расчитан. Количество циклов записи flash-микросхемы ограничено!.
=== cut ===

Не думаю, что невозможность подключить винт - это хорошая идея. У конечного пользователя всегда должен быть выбор - кому интересно, может подключить флэш-накопитель, а кому не интересно - может юзать старый добрый винт. От такого подхода девайсина только выиграет. Или сложно будет прикрутить IDE-канал ?. Не уверен.



P.S. Только мне думается, что скоро весь этот флейм утихнет и разговоры так и останутся разговорами.

[PegasResearch]

Vasil

Вот кусок статьи по флэшкам из журнала "Железо" за май 2007 года

Да, любая flesh-память имеет ограниченный ресурс (также, как и жёсткий диск, кстати;-)). Поэтому для такого типа памяти разрабатываются специальные файловые системы - вводятся счётчики обращений к ячейкам (чтобы в очередной раз обращаться к наименее "пострадавшей" ячейке) и т.п. "Железо" - журнал, вероятно, не для инженеров, а для пользователей, а пользователи знакомы только с системой FAT на флешках.

Я собираюсь использовать NAND flash - изобретение Samsung, если не ошибаюсь. Данный тип памяти отличается большим размером блоков (несколько килобайт), что уже делает невозможным (чрезмерно растратным) использование FAT, наличием даже в новой микросхеме некоторого количества "битых" ячеек и наличием дополнительного объёма для решения проблем с битыми ячейками. Доступ к такому флешу производится командами (а не адресацией). Время последовательного доступа порядка 25нС, произвольного - около 20мкС (что ставит вопрос об оптимизации хранящихся данных). Данный тип флеша имеет наработку на отказ 100000 перезаписей ячейки и большие объёмы.
Соответственно, файловая система будет использоваться флешовая. О том, чтобы держать на флеше своп-файл речи не идёт - система дизайнится из расчёта удержания всего и вся в памяти и только. Набор приложений заранее известен и всё будет заточено под этот набор - включая требования к ОЗУ (но ограничений нет никаких - свободная часть флеша будет полностью доступна, и при желании можно там хоть своп организовать). Флеш (его системная область) будет использоваться в основном на чтение и играть роль большого ПЗУ. Для записи пользовательских данных предпочтительно использовать внешний накопитель - будь то USB-флешка либо SD/MMC-карта. А вообще - на дворе эпоха веб 2.0, товарищи - храните данные в Google :-) (это не реклама).

Не думаю, что невозможность подключить винт - это хорошая идея

А из чего такой вывод? Вроде как возможность подключить винт имеется. И не только винт - всё, что угодно. На это будет имется порт USB 2.0 High Speed (480Mbps). Для девайсов попроще - мышь, клава, ADSL модем - будет встроено 2 (или 4) порта USB 2.0 Full Speed (12Mbps).
Так что подключение винта никаких проблем не вызовет. Также, как и подключение DVD. И уже другой вопрос - зачем это делать? Предполагается, что 90% пользователей не захотят подключать внешний HDD. А оставшиеся 10% захотят подключить внешний DVD, чтобы фильмы смотреть ;-) А вовсе не HDD... хотя, как хранилище - идеальный вариант, поэтому и планируется USB 2.0 High Speed.

Или сложно будет прикрутить IDE-канал ?

Скоро сложно будет винт найти с IDE каналом. SATA везде (даже SATA II). Поэтому выбран компромисный вариант - будет юзаться микросхема NEC, обеспечивающая USB 2.0 High Speed. А дальше - через переходник (или бокс - это удобнее) хоть SATA, хоть IDE, хоть ISA (есть и такие переходники, встречал).

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

А чем ты можешь помочь проекту? Есть желание и возможность попрограммировать ради сабжа? Если есть - велком в личку ;-)

[Vasil]

Vasil

Да, любая flesh-память имеет ограниченный ресурс (также, как и жёсткий диск, кстати;-)). Поэтому для такого типа памяти разрабатываются специальные файловые системы - вводятся счётчики обращений к ячейкам (чтобы в очередной раз обращаться к наименее "пострадавшей" ячейке) и т.п.

И надо полагать, что всей этой диспетчеризацией занимается контроллер флэш-драйва. На счет винтов. Винчестеры появились гораздо раньше флэш-накопителей и как следствие - их технология изготовления отработана и проверена временем. Что не скажешь про флэхи. Хотя конечно бывает и винты "летят" даже брендовых производителей.

Я собираюсь использовать NAND flash - изобретение Samsung, если не ошибаюсь. Данный тип памяти отличается большим размером блоков (несколько килобайт), что уже делает невозможным (чрезмерно растратным) использование FAT, наличием даже в новой микросхеме некоторого количества "битых" ячеек и наличием дополнительного объёма для решения проблем с битыми ячейками. Доступ к такому флешу производится командами (а не адресацией). Время последовательного доступа порядка 25нС, произвольного - около 20мкС (что ставит вопрос об оптимизации хранящихся данных). Данный тип флеша имеет наработку на отказ 100000 перезаписей ячейки и большие объёмы.

Сто тыс. перезаписей - неплохо.

Набор приложений заранее известен и всё будет заточено под этот набор - включая требования к ОЗУ

Тебе не кажется, что эта "заточка под этот набор" - как-то не кузяво выглядит ?. Наверно все-таки лучше софт для железа, а не железо под софт ? .

Флеш (его системная область) будет использоваться в основном на чтение и играть роль большого ПЗУ.

Вот с этим согласен на 100%. Для флэхи будет самый благоприятный режим.

Для записи пользовательских данных предпочтительно использовать внешний накопитель - будь то USB-флешка либо SD/MMC-карта.

Логично. Либо винт на USB-порт .

А вообще - на дворе эпоха веб 2.0, товарищи - храните данные в Google :-) (это не реклама).

Точно и что б америкосы ковырялись в твоих данных (не важно в каких). А то им все мало.

Не думаю, что невозможность подключить винт - это хорошая идея

А из чего такой вывод? Вроде как возможность подключить винт имеется. И не только винт - всё, что угодно. На это будет имется порт USB 2.0 High Speed (480Mbps). Для девайсов попроще - мышь, клава, ADSL модем - будет встроено 2 (или 4) порта USB 2.0 Full Speed (12Mbps). Так что подключение винта никаких проблем не вызовет. Также, как и подключение DVD. И уже другой вопрос - зачем это делать? Предполагается, что 90% пользователей не захотят подключать внешний HDD.

Насчет предположений - человек предполагает, а Бог располагает. Предполагать за других - неблагодарная задача.

Да, вобщем-то сейчас всю периферию можно вешать на USB-порты. И наверно по-возможности надо избавляться от юзания USB 1-й версии. Если уж твой комп обещает быть производительным. А 4 USB-порта не мало будет ?. Принтер, флешка, клавиатура, мышка - уже все порты заняты. Куда подключать сетевую карту, DVD-ROM ?. Или сетевуха у тебя будет только в конфигурации с камнем ?.

Или сложно будет прикрутить IDE-канал ?

Скоро сложно будет винт найти с IDE каналом. SATA везде (даже SATA II). Поэтому выбран компромисный вариант - будет юзаться микросхема NEC, обеспечивающая USB 2.0 High Speed. А дальше - через переходник (или бокс - это удобнее) хоть SATA, хоть IDE, хоть ISA (есть и такие переходники, встречал).

Думаю здесь внесли ясность, вопрос можно считать закрытым.

хорошо иметь BIOS с эмулятором Спеки при включении...

А еще лучше иметь BIOS с тем, что нужно данному юзеру и что ему надо загрузить при включении... а не зацикливаться на эмуле Спека. Ессно содержимое Биоса напишет сам юзер (имея хорошую доку по девайсу от авторов). Ты же не собираешься грузить линукс (к примеру) из эмуля Спека ?.

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

А чем ты можешь помочь проекту? Есть желание и возможность попрограммировать ради сабжа? Если есть - велком в личку ;-)

Да я не профессиональный программер. Это так - маленькое хобби. После Спринтера, который не получил должного распространения, переходить на другие 8-ми битки уже влом - нет достойной альтернативы. Кроме всего прочего, давно хотелось по-иметь дело с чем-нить более производительней, чем 8-ми битки. Не знаю почему, но на PC (читай на Пни) меня не тянет, равнодушен я к ним (камням интеловским). Да и на персоналках уже давным давно фактически все есть и на все случаи жизни.


P.S. Не думал о варианте прикрутки DDR (DDR2) в качестве ОЗУ девайса ?. Выдет ессно чуть дороже, но зато обмен камня с памятью будет происходить шустрее, что только положительным образом скажется на потребительских характеристиках девайса. Ты же не собираешься делать его на один год ?. Кто знает - может через год DIMM-ы днем с огнем будет не найти.

P.S.S. Не думаю, что Линукс - это ОС всех времен и народов. Лично я, когда прочитал и увидел BeOS, сразу перелез со Слаквари в BeOS.

[Valen]

PC-133

Откуда вообще взялось 133МГц ?
В даташите ep9302 написано, о поддержке SDRAM 100МГц.

[PegasResearch]

Vasil

И надо полагать, что всей этой диспетчеризацией занимается контроллер флэш-драйва

Я имел в виду внутренний флеш - там контроллера нет - кроме центрального процессора ;-). По поводу внешних - нафряд ли дешёвые флешки имеют оптимальные "внутренние" ФС :-(

Насчет предположений - человек предполагает, а Бог располагает. Предполагать за других - неблагодарная задача.

Инженер как раз и должен предполагать аз остальных. И от его предположения и зависит - получится хит или так себе ;-) Задача неблагодарная, но решать её как-то надо. Надо как-то совмещать требования пользователя и технические ограничения.

Тебе не кажется, что эта "заточка под этот набор" - как-то не кузяво выглядит ?. Наверно все-таки лучше софт для железа, а не железо под софт ?

Неверно ;-) Правильный девих такой: "Софт для железа, а железо - для софта". :-) Платформа не будет отличаться расширяемостью (не считая USB девайсов).

по-возможности надо избавляться от юзания USB 1-й версии. Если уж твой комп обещает быть производительным

USB 1-й версии и не используется. Используется только USB 2.0. И комп производительным быть не обещает!!!! Он обещает только, что программам, для которых комп разрабатывается, ресурсов хватит. И всё - не больше, но и не меньше.
Ещё по поводу задачи инженера. Какие ограничения даёт наличие трёх, а не шести USB, если можно за 400 рублей приобрести хаб и подключить те же 6 устройств? А цена сабжа на те же 400 рублей уменьшается, и кому этот USB не нужен - не тратят 400 рублей. Это при условии, что сабж монтируется в корпус клавиатуры, внешней является только мышь. Два порта свободно - под принтер, флешку, модем, DVD...

Впрочем, у меня самого 5 портов на ноуте занято - вывод только один: портов всегда мало.

Вообще же, есть вероятность, что портов будет 5 (4 полноскоростных и 1 высокоскоростной).

Или сетевуха у тебя будет только в конфигурации с камнем ?

Не совсем понял - что значит "в конфигурации с камнем"? А по существу - Ethernet 10/100Mbit будет встроен.

Точно и что б америкосы ковырялись в твоих данных (не важно в каких). А то им все мало.

Ты же не собираешься грузить линукс (к примеру) из эмуля Спека

:-) Давно так не смеялся :-)

А еще лучше иметь BIOS с тем, что нужно данному юзеру...а не зацикливаться на эмуле Спека

А я и не зацикливаюсь на эмуле Спека. Судя по всему, в BIOS только простейший загрузчик влезет - а всё остальное будет на флеше (включая эмуляторы). Объём ПЗУ мал, чтоб туда что-то внести. Но есть флеш :-)

Не думал о варианте прикрутки DDR (DDR2)

Думал, но поднимается не только цена памяти - процессор тоже не укупишь. А если и укупишь, то только в BGA корпусе. В любительских условиях нереально припаять такой процессор...
Да и не в любительских - цена компа зашкалит 200$...

может через год DIMM-ы

Компьютер не использует DIMM. Микросхемы напаиваются непосредственно на плату :-)

Не думаю, что Линукс - это ОС всех времен и народов

Эта ОС стандартизирована, её код можно менять, под неё существует множество приложений. Опять же - задача инженера...

Valen
Intel никогда не соглашалась на SDRAM быстрее 125МГц - мол, практически это бесполезно (так как работать при произвольном доступе будет медленнее). Насколько мне известно, последняя спецификация от Интела - PC-100. Всякие PC-133 и PC-166 это уже "вне закона" ;-).

P.S. Почитал даташит более внимательно и обнаружил, что PC-133 EP9302 всё-таки не поддерживает. Предел ограничен частотой системной шины 100МГц - половина частоты ядра. Так что сорри :-(((.