TS Forum

я пол года кодил игру, и очень в плотном графике - последние два месяца до старта. уже отошёл даже от отходняка))
а демы - это хорошо. нездоровая критика - плохо)

тот форум со своими политиками отбил желание, если чесно. но вродь пришёл в себя.

VBI wrote:нездоровая критика - плохо)

вооооооот.

а вообще - пора уже железяку релизить

VBI, пойми, что релизить бадыль это тупо.
У меня все идет по плану, правда но не по расписанию, гг:
1. Исследовать аппаратные проблемы/решения - сделано.
2. Исследовать хдлные проблемы/решения - сделано.
3. Придумать концепты - в процессе.
4. Заимплементить.
5. Заняться софтом.

ХОРОВО

Не сцы, все будет horror show!

В общем докладаю, что сделано:
- прикручен кеш к ядру z80next (на ц3 частота 33мгц, на ц2 будет поменьше, но несильно) и сдраме 133мгц,
- спланирован в общих чертах движок 3D.

Сильно интересует:
1) длина, разрядность, кол-во строк буфера вывода на экран (хотелось бы 16 бит минимум и от 2 строк(и больше... больше ));
2) возможность субпиксельного сдвига для TSU и экрана;
3) возможность включения прозрачности для слоёв или их областей.( хотя бы 50 процентов)
4) что примерно представляет из себя 3d движок;
5) Приблизительная теоретическая производительность dma.

dnik75 wrote:1) длина, разрядность, кол-во строк буфера вывода на экран (хотелось бы 16 бит минимум и от 2 строк(и больше... больше ));

Битов будет скорее всего 18.
Зачем больше 1 строки?

dnik75 wrote:2) возможность субпиксельного сдвига для TSU и экрана;

Объясни зачем?

dnik75 wrote:3) возможность включения прозрачности для слоёв или их областей.( хотя бы 50 процентов)

Альфа будет, возможно до 8 бит.

dnik75 wrote:4) что примерно представляет из себя 3d движок;

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

dnik75 wrote:5) Приблизительная теоретическая производительность dma.

Сложно сказать. СДРАМ одна, контроллер только пишется. Частота сдрамы планируется 133, если не вылезут проблемы с разводкой, разрядность 16 бит.

TS-Labs wrote:Зачем больше 1 строки?

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

TS-Labs wrote:Объясни зачем?

Для плавности движения спрайтов и спецэфектов. Что-то вроде этого реализовано на snes(по горизонтали).

TS-Labs wrote:Альфа будет, возможно до 8 бит.

Круто, даже не надеялся на такое.

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

dnik75 wrote:Вроде как двойной буфер.

А, ну так и есть.

dnik75 wrote:Для плавности движения спрайтов и спецэфектов. Что-то вроде этого реализовано на snes(по горизонтали).

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

TS-Labs wrote:Это довольно накладно реализовать.
С альфой проще - в циклонах аппаратные умножители, тысячи их.

Ни ни ни ))) Всё довольно таки просто реализуется без аппаратных умножителей. Да и откуда в несчастном SNES видеопроце они, с его 64к видеопамяти????
например по горизонтали разрешение в памяти 360x288x256 ,в буфере cтрока 720x288x18 бит складываем по 2 точки и делим на 2, получаем 360x288x18 бит для вывода на экран, отсюда и вытекает необходимость запаса буферных строк.
Что-то вроде этого было применено для видеокарты для Commodore 64 недавно. Также интересны возможные простые логические операции при помощи DMA (сложение, умножение, вычитание, shl, shr, xor, or, and, ну и блиттеринг разумеется)
В теории можно узаконить построчный скролл(linescroll), храня смещение каждой строки линейно в памяти (лучше всего такие возможности как простой програмный шейдер для видеопроца). Ради интереса можно почитать http://zxpress.ru/article.php?id=8681, хотя тут далеко не всё, а так в принципе необходимое ТЗ должны выдать демомейкеры и игроделы, что действительно им необходимо.

Ну для субпикселя в 1/2 достаточно 1 сумматора, это по горизонтали. А по вертикали?
Полноценный блиттер будет.
Так же будет хороший, годный дисплей лист. Он будет содержать инфу про параметры видеорежима в каждой строке и количество и порядок слоев графики в ней.

TS-Labs wrote:Так же будет хороший, годный дисплей лист. Он будет содержать инфу про параметры видеорежима в каждой строке и количество и порядок слоев графики в ней.

Звучит очень заманчиво))). Боюсь даже представить как извратятся демомэйкеры

С идеями у нас вообще все круто. А где бы взять девелоперов...

Хех, с радостью стал бы им. Правда начинать придётся практически с нуля.

dnik75 wrote:Хех, с радостью стал бы им. Правда начинать придётся практически с нуля.

Начните с 0.25:

MVV wrote:Начните с 0.25:

Эээээ.... с PhizX уже работал. правда гораздо скромнее использовал, чем в этой демке. Правда какое отношение это вообще имеет к девелоперству?

Итак, прокачал два направления.

1. Контроллер сдрамы на длинных бурстах и видеоконтроллер на нем через фифо. Стабильно собирается на частоте 133 (ДЕ1, ц2). На длине бурста 8 и памяти 16 бит скорость 163МБ/с.
Вдумчивое читание даташитов привело к рождению идеи использовать открытые банки с проверкой адреса, но это допилится потом.
Блочные девайсы (ДМА, видео) будут использовать бурсты, а штучные обращения (проц, аудио) - режим одиночных транзакций.

2. Хостовый проц - AVR classic, реализация Navré AVR от автора с благозвучной фамилией Бурдодюк.
Тестировал на той же ДЕ1 (циклон 2). Занимает 1600 ЛЕ, частота 55-57МГц (ограничил на 50) на оверклоке замечательно колбасит на 100МГц без визуальных глюков. Работает из внутренних м4к, которые легко заменяются на кеши, обслуживающие потенциально любую память, с оглядкой на ее тормознутость, хоть SPI флэш.
Добавление команд из атмеги (MOVW, xMULxx) раздувает корку и роняет частоту. Матан лучше реализовать на периферии.

Может глупый вопрос,а данные на аксель как закачивать будем,через тормозной zxbus без дма,туда же и звук пихать надо?
А если эвовский ИДЕ как мост к акселю прикрутить заместо видеоЦапа,а лучше бы порт иде был бы на видео,тогда с винта прямо на видео заливать,спековский код маленький он и с видеобуфера через zxbus нормально прокачается ,а вот всякие мп3 и например потоковое видео.

Не думаю, что кому-то нужно "потоковое видео" и "потоковое мр3".
Закинуть некоторое количество данных через зхбас - не такая уж проблема.

TS-Labs, глупая возможно мысль.
два выхода для аудио, для квадро.

дальше думай сам

TS-Labs wrote:Закинуть некоторое количество данных через зхбас - не такая уж проблема.

Зачем перекидывать через узкое место,если можно кидать прямо туда куда надо? А вот управляющий код в эву можно через ZX бас и перекинуть,это- не такая уж проблема
Зачем ограничивать аксель? ,ведь прикрутить IDE не великая проблема,зато будет винт с дма ,з80 надо только команды раздавать ,кучу тактов освободиться.
А так спрайты,фон, музон загрузил и на этом все,любая подгрузка будет вешать всю систему ,это как в GS МОД 500кб закинуть надо пол минуты ждать,а это 5 картинок всего даже не потоковое видео ,экран то не 6Кбт уже и одна картинка(фон) по 100Кбт,объемы то растут,аппетит приходит во время еды.Неужели я совсем глупости говорю.

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

AndyD wrote:прикрутить IDE не великая проблема

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

TS-Labs wrote:1. Контроллер сдрамы на длинных бурстах и видеоконтроллер на нем через фифо.

Загрузка данных в ПППУ на заданной частоте приоритетных запросов (что-то типа захвата SDRAM пока не загрузится/вращающийся приоритет) или по мере освобождения арбитра памяти? Я сейчас решаю как лучше сделать - реализовать 3-ри линейных буфера R(7..0), G(7..0), B(7..0), каждый длиной в одну строку 1Кх8 с возможностью доступа блиттера к ним, или делать один ПППУ с арбитражем и конвейером 8:8:8 для палитры.

TS-Labs wrote:2. Хостовый проц - AVR classic

Решил не усложнять, буду использовать более понятный спектрумисту - NextZ80@42MHz. Сейчас неплохо всё крутится с двумя процессорами.