..и сколько лет он отводит на размышления потенциальным покупателям? :) ..вон на Спринтер до сих пор наверно покупателя с десятью килобаксами ждут :)
Вид для печати
..и сколько лет он отводит на размышления потенциальным покупателям? :) ..вон на Спринтер до сих пор наверно покупателя с десятью килобаксами ждут :)
На самом деле нет никаких серьёзных аппаратных ограничений на высоту спрайта . Но даже если ограничение будет оставлено , то вполне в порядке вещей переписать таблицу имён тайлов спрайтов хоть под каждую строку . В результате спрайт может быть какой угодно высоты и состоять из каких угодно валяющихся в памяти тайлов .Цитата:
Сообщение от Lethargeek
А чёго в этом такого . Разве суть блиттера не в том чтоб кидать огрызки картинок в память сканера .Цитата:
Сообщение от Lethargeek
При особом старании ёе даже не будет хватать .Цитата:
Сообщение от Lethargeek
Дык вроде как сырки от четвёртого проэкта и так свободно лежат .Цитата:
Сообщение от Valen
А вот схемку самой платки я бы глянул , уж больно интересно какие там тараканы и вчесть чего установлены .
Под MINI-ITX бы переколбасить (со слотом расширения) . Внешний проц ИМХО нафиг нужен . Матрицу можно и пожирней поставить .Цитата:
Сообщение от Valen
Нету. Но высокие не так часто нужны, это ж не неогей. :)Цитата:
Сообщение от fan
Ну выделить 32К, чтоб с запасом, а остальное?
Ну не из основной же памяти, где цпу (и мало ли кто еще) под ногами путается.Цитата:
Сообщение от fan
А тут блиттер еще и восьмибитный получится.
Ага, причем возместить ее за счет неиспользуемой фоновой памяти нельзя.Цитата:
Сообщение от fan
И в обратном случае, когда под задник памяти не хватает - та же картина.
Мне ваще непонятно, нафига такое дурацкое разделение? Никакой выгоды по сравнению с общей 16-битной шиной нет, напротив - двойной проигрыш получается. Во-первых по объему (см. выше) из-за жесткого разделения пополам - как ни крутись, дефицит будет в среднем возникать вдвое чаще; во-вторых по скорости (потому что суммарно спрайтовых точек в пике читается больше, чем фоновых и "фоновая" рама сканером на 100% не юзается) - то есть раздельная схема как раз дополнительно ограничивает (!) макс.кол-во спрайтов на строку, а вовсе не увеличивает! Причем сколько бы памяти ни добавить теоретически - проблема скорости никуда не денется, а проблема дефицита "решается" крайне нерационально.
Нету никаких пиков , всё линейно . С общими мозгами спрайтовые регистры горизонтальных линий тогда будут набиваться только во время горизонтального гашения , т.к. задник будет сканиться в реальном времени (внезависимости от того тайловый он или блиттерный).Цитата:
Сообщение от Lethargeek
Что "линейно"? Задник в любом случае одинаково тянется, регистры почти не влияют, а "пик" - это когда растровая строка вся забита спрайтами по максимуму, в случае таймингов сабжа 56*16=896 точек. Это только с одной рамы, а с другой стабильно тянется 256 точек в строке, хотя в случае общей памяти могло быть еще 896. Итого пиковая эффективность сканера 64% от совмещенного варианта, а вместо теоретически возможных ~90 спрайтов на строку получается всего-то 56.
И еще я не понял, нафига у него аж 12ns врама судя по кол-ву спрайтов всего-то на 16МГц пашет? Или больше, тогда непонятно зачем оставлен агромадный запас на бесконфликтный доступ 8МГц z80... и даже если на 16МГц выделять зетнику фиксированные окошки доступа, все равно 70+ спрайтов в совмещенном варианте выходит.
чего-то я сосвем запутался, обьясните мне эту модель в деталях, вот как я себе это представляю:
Сканер задника читает 256 байт на одну строку а движек спрайтов на каждой строке вычитывает sprite control block + сами спрайты (если надо) т.е. в минимальном варианте sprite engine считывает токо Y координату для каждого спрайта (56 байт) а в худшем варианте все sprite control block-и и по одной строке каждого спрайта 3?*56+56*16. Так как sprite engine не успевает сформировать буфер со строкой из линий спрайтов во время высвечивания бордюра и обратного хода луча к началу следующей строки то ему отведена отдельная шина и два буфера строки которые он заполняет поочередно, таким образом пока первая строка "накладывается" на текущую строчку "задника" и высвечивается на экране sprite engine формирует содержимое второй строчки во втором буфере а в момент когда текущая строка задника уже высветилась и новая строка спрайтов уже готова происходит swap буферов и начало формирования следующей строки спрайтов.
И тут как не крути а скорость на шине спрайтов всегда будет НЕпостоянной и потенциально большей в разы чем на шине задника.
Не 56, а вроде бы написано все 127 (проверяет по крайней мере). Только чего-то слегка не сходятся тайминги для худшего случая на 60Гц кадр @ 16МГц рам, хм?Цитата:
Сообщение от bigral
Буфера внутренние нужны. Отдельная шина нафиг не нужна.Цитата:
Сообщение от bigral
Я и грю - сплошной проигрыш. Зачем, спрашивается?Цитата:
Сообщение от bigral
->Цитата:
Сообщение от Lethargeek
Это и есть линейно .Цитата:
Сообщение от Lethargeek
Термин "почти" неприменим впринципе , регистров набивается столько сколько сколько реализовано (исходя из пропускнай способности памяти) , даже если насамом деле ничего не набивается . (чувак конечно сделал возможность набивать регистры для других строк во время пустых , но на самом деле это практически не применимо , т.к. на следующих же строках начнутся дропы спрайтов).Цитата:
Сообщение от Lethargeek
Не может быть никаких пиков у аппаратной железки , всё высчитывается из реализованного аппаратного максимума .Цитата:
Сообщение от Lethargeek
Вроде у него 320 на строку при одном заднике . Не важно... Уговорили :DЦитата:
Сообщение от Lethargeek
Ну не ВСЕ же :) И вместо одной универсальной читалки - две разных.Цитата:
Сообщение от fan
В смысле - набивка самих регистров мало % времени жретЦитата:
Сообщение от fan
В смысле пик - возможный максимум загрузки шины для логики движка, а не теоретически допускаемый железомЦитата:
Сообщение от fan
Ошибсо - моск привычно покатилсо в спековую колею :)Цитата:
Сообщение от fan
Обломали кайф человеку :pЦитата:
Сообщение от fan
Так ведь речь была о спратйах/точках которые железный движёк может вытянуть из видео мозгов . Эта величина для движка всегда постоянная . Шину видео мозгов напрячь логикой нельзя ибо вся рулёжка реализованна в кучки регистров внутри матрицы (включая регистры палитры) , рулить ими можно в любое время .Цитата:
Сообщение от Lethargeek
Единственное узкое место - количество тайлов/точек которое проц/DMA смогут протащить за кадровое гашение . Вот здесь бы были бы очёнь кстати четырёхбитные тайлы с выбираемой палитрой .