z80 megadevice v5

[Black_Cat]

..и сколько лет он отводит на размышления потенциальным покупателям? ..вон на Спринтер до сих пор наверно покупателя с десятью килобаксами ждут

[fan]

56x16x16 это меньше 16К. Нафиг 128?

На самом деле нет никаких серьёзных аппаратных ограничений на высоту спрайта . Но даже если ограничение будет оставлено , то вполне в порядке вещей переписать таблицу имён тайлов спрайтов хоть под каждую строку . В результате спрайт может быть какой угодно высоты и состоять из каких угодно валяющихся в памяти тайлов .

А каждый новый (софтверный между прочим) "тайл" для подрисовки вручную каждый раз с хоста перезаливать, что ли?

А чёго в этом такого . Разве суть блиттера не в том чтоб кидать огрызки картинок в память сканера .

В то время как целых 64-96К спрайтовой памяти постоянно будут висеть мертвым грузом.

При особом старании ёе даже не будет хватать .

Касательно исходников проекта.
Автор, в принципе, не против открыть схемы/сорцы, когда проект будет в финальной стадии.
(если конечно никто не выкупит проект за большие деньги )

Дык вроде как сырки от четвёртого проэкта и так свободно лежат .
А вот схемку самой платки я бы глянул , уж больно интересно какие там тараканы и вчесть чего установлены .

Интересно, кто-то бы взялся делать такие платы (голые либо собранные)?

Под MINI-ITX бы переколбасить (со слотом расширения) . Внешний проц ИМХО нафиг нужен . Матрицу можно и пожирней поставить .

[Lethargeek]

На самом деле нет никаких серьёзных аппаратных ограничений на высоту спрайта .

Нету. Но высокие не так часто нужны, это ж не неогей.
Ну выделить 32К, чтоб с запасом, а остальное?

А чёго в этом такого . Разве суть блиттера не в том чтоб кидать огрызки картинок в память сканера .

Ну не из основной же памяти, где цпу (и мало ли кто еще) под ногами путается.
А тут блиттер еще и восьмибитный получится.

При особом старании ёе даже не будет хватать.

Ага, причем возместить ее за счет неиспользуемой фоновой памяти нельзя.
И в обратном случае, когда под задник памяти не хватает - та же картина.

Мне ваще непонятно, нафига такое дурацкое разделение? Никакой выгоды по сравнению с общей 16-битной шиной нет, напротив - двойной проигрыш получается. Во-первых по объему (см. выше) из-за жесткого разделения пополам - как ни крутись, дефицит будет в среднем возникать вдвое чаще; во-вторых по скорости (потому что суммарно спрайтовых точек в пике читается больше, чем фоновых и "фоновая" рама сканером на 100% не юзается) - то есть раздельная схема как раз дополнительно ограничивает (!) макс.кол-во спрайтов на строку, а вовсе не увеличивает! Причем сколько бы памяти ни добавить теоретически - проблема скорости никуда не денется, а проблема дефицита "решается" крайне нерационально.

[fan]

потому что суммарно спрайтовых точек в пике читается больше, чем фоновых и "фоновая" рама сканером на 100% не юзается

Нету никаких пиков , всё линейно . С общими мозгами спрайтовые регистры горизонтальных линий тогда будут набиваться только во время горизонтального гашения , т.к. задник будет сканиться в реальном времени (внезависимости от того тайловый он или блиттерный).

[Lethargeek]

Что "линейно"? Задник в любом случае одинаково тянется, регистры почти не влияют, а "пик" - это когда растровая строка вся забита спрайтами по максимуму, в случае таймингов сабжа 56*16=896 точек. Это только с одной рамы, а с другой стабильно тянется 256 точек в строке, хотя в случае общей памяти могло быть еще 896. Итого пиковая эффективность сканера 64% от совмещенного варианта, а вместо теоретически возможных ~90 спрайтов на строку получается всего-то 56.

И еще я не понял, нафига у него аж 12ns врама судя по кол-ву спрайтов всего-то на 16МГц пашет? Или больше, тогда непонятно зачем оставлен агромадный запас на бесконфликтный доступ 8МГц z80... и даже если на 16МГц выделять зетнику фиксированные окошки доступа, все равно 70+ спрайтов в совмещенном варианте выходит.

[bigral]

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

Сканер задника читает 256 байт на одну строку а движек спрайтов на каждой строке вычитывает sprite control block + сами спрайты (если надо) т.е. в минимальном варианте sprite engine считывает токо Y координату для каждого спрайта (56 байт) а в худшем варианте все sprite control block-и и по одной строке каждого спрайта 3?*56+56*16. Так как sprite engine не успевает сформировать буфер со строкой из линий спрайтов во время высвечивания бордюра и обратного хода луча к началу следующей строки то ему отведена отдельная шина и два буфера строки которые он заполняет поочередно, таким образом пока первая строка "накладывается" на текущую строчку "задника" и высвечивается на экране sprite engine формирует содержимое второй строчки во втором буфере а в момент когда текущая строка задника уже высветилась и новая строка спрайтов уже готова происходит swap буферов и начало формирования следующей строки спрайтов.

И тут как не крути а скорость на шине спрайтов всегда будет НЕпостоянной и потенциально большей в разы чем на шине задника.

[Advertiser]

[Lethargeek]

Сканер задника читает 256 байт на одну строку а движек спрайтов на каждой строке вычитывает sprite control block + сами спрайты (если надо) т.е. в минимальном варианте sprite engine считывает токо Y координату для каждого спрайта (56 байт) а в худшем варианте все sprite control block-и и по одной строке каждого спрайта 3?*56+56*16.

Не 56, а вроде бы написано все 127 (проверяет по крайней мере). Только чего-то слегка не сходятся тайминги для худшего случая на 60Гц кадр @ 16МГц рам, хм?

Так как sprite engine не успевает сформировать буфер со строкой из линий спрайтов во время высвечивания бордюра и обратного хода луча к началу следующей строки то ему отведена отдельная шина и два буфера строки которые он заполняет поочередно

Буфера внутренние нужны. Отдельная шина нафиг не нужна.

И тут как не крути а скорость на шине спрайтов всегда будет НЕпостоянной и потенциально большей в разы чем на шине задника.

Я и грю - сплошной проигрыш. Зачем, спрашивается?

[fan]

Что "линейно"?

->

Задник в любом случае одинаково тянется

Это и есть линейно .

регистры почти не влияют

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

а "пик" - это когда растровая строка вся забита спрайтами по максимуму, в случае таймингов сабжа 56*16=896 точек.

Не может быть никаких пиков у аппаратной железки , всё высчитывается из реализованного аппаратного максимума .

Это только с одной рамы, а с другой стабильно тянется 256 точек в строке, хотя в случае общей памяти могло быть еще 896. Итого пиковая эффективность сканера 64% от совмещенного варианта, а вместо теоретически возможных ~90 спрайтов на строку получается всего-то 56.

Вроде у него 320 на строку при одном заднике . Не важно... Уговорили

[Lethargeek]

Это и есть линейно .

Ну не ВСЕ же И вместо одной универсальной читалки - две разных.

Термин "почти" неприменим впринципе , регистров набивается столько сколько сколько реализовано (исходя из пропускнай способности памяти)

В смысле - набивка самих регистров мало % времени жрет

Не может быть никаких пиков у аппаратной железки , всё высчитывается из реализованного аппаратного максимума .

В смысле пик - возможный максимум загрузки шины для логики движка, а не теоретически допускаемый железом

Вроде у него 320 на строку при одном заднике

Ошибсо - моск привычно покатилсо в спековую колею

Не важно... Уговорили

Обломали кайф человеку

[fan]

В смысле пик - возможный максимум загрузки шины для логики движка, а не теоретически допускаемый железом

Так ведь речь была о спратйах/точках которые железный движёк может вытянуть из видео мозгов . Эта величина для движка всегда постоянная . Шину видео мозгов напрячь логикой нельзя ибо вся рулёжка реализованна в кучки регистров внутри матрицы (включая регистры палитры) , рулить ими можно в любое время .

Единственное узкое место - количество тайлов/точек которое проц/DMA смогут протащить за кадровое гашение . Вот здесь бы были бы очёнь кстати четырёхбитные тайлы с выбираемой палитрой .