ZX-Poly™ platform

[andrews]

Но это как-то глупо :-) - доп проц быстрее основного

ну почему же глупо? просто ассиметричный кластер

[AlexCrush]

Нормальный use case так как данный механизм хорошо работает еще в следующих случаях
1) заливка подпрограмм считывание результата при многопоточной работе процессоров
2) работа в расширенных графических режимах без задействования всех процов, т.е. CPU0 может заменить себя и еще один проц (или несколько),записывая графические данные в его память, который в это время обсчитывает что то в фоне..

Всё это в разы удобнее и привычнее делать через память, а не через порты. Очень здорово будет через порты заливать 30-байтную процедуру в память по адресу #7FF0. А во временной смене адресного пространства ничего страшного нет.

Почему Вы боитесь признать что фишка с подменой портов в имеющемся виде бесполезна? Давайте её выкинем! Зачем усложнять железо ненужными вещами? Вот когда будет применение этой вещи + когда идея будет доведена до ума...

[ASDT]

"Контроллер SD/MMC само по себе простейшее устройство, вот кто программно поддержит это на спеке?"

Сейчас я делаю поддержку сом через вход-выход
магнитофона (пока только 38400 и ТАР-файлы)
Затем - 1 меговый+ диск, после карты ...

А "ZX-Poly" помрет не родившись ...

[icebear]

ну почему же глупо? просто ассиметричный кластер

Що? Вы, господа, когда тут перестанете генеталиями мерятся?

[Mikka_A]

Що? Вы, господа, когда тут перестанете генеталиями мерятся?

+1

до чегож народ у нас любит офтопить.....

(icebear это не про тебя.... )

[Lethargeek]

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

Хм. Предложение унификации атрибутов выходит за рамки простоты?
Кстати о простоте (и гибкости) - так называемые "видеорежимы 0-3" вообще не нужны в явном виде, они прекрасно получаются настройкой режимов 256x192x4 и 512x384x1, нужно (в дополнение к регистрам палитры) всего два байта-описателя пиксельных и атрибутных блоков 2x2 (то есть с какой плоскости брать соотв-й пиксел/атрибут в каждой четверке пикселов/атрибутов). При этом сразу появляются "режимы" 512x192 и 256x384 с прямоугольными точками (не считая остальных извращенных частных случаев), можно моргалки быстрые делать... В режиме 256x192x4 "лишние" цвета убиваются просто настройкой палитры.

[Advertiser]

[Romanich]

Що? Вы, господа, когда тут перестанете генеталиями мерятся?

Когда кто-то реально докажет и покажет
..своё железо в действии, разумееца...

[Lethargeek]

В нашем деле, самое страшное - именно выражение "всего то добавить"..

Самое страшное - это не видеть, "куда там доводить еще". Иметь четыре одинаковых псевдостандартных режима - это типа не страшно, а ведь там требуются те же переключатели. Описанные дополнительные настройки - ерунда по сравнению палитрой, тем более вроде как решено для логики юзать ПЛИС, какие проблемы-то? В случае трудностей спецы здесь всегда помогут.

Видать, реализовать более эффективную (а главное - полезную) архитектуру "инженерное мышление" не позволяет? Почему из разряда "невозможно" надо обязательно переводить в разряд "сложно", а не в разряд "просто, удобно и эффективно"?

[Black_Cat]

дискутировать" не намерен, ибо пустая трата времени

нет, не правильно, такое обсуждение полезно даже в случае "извращений ради извращений". Метод, при котором рассматриваются даже бредовые идеи используется в ТРИЗ и называется "мозговым штурмом". Это очень полезный метод , т.к. он позволяет в дальнейшем рассмотрении оперировать на всём поле возможных вариантов, а не зацикливаться на одном направлении, хоть возможно и перспективном с первого взгляда.

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

ну это в обычных переделываемых игрушках врядли есть, а если есть, то помена не частая (т.е. не несколько раз на строку или на кадр).

при отсутствии растровых прерываний такая эмуляция все время отображения растра сожрет (аналогично интерлейсовым смотрелкам моргалок)

Я ж не спорю что вариант прожорливый, но тут уже можно подумать об аппаратных возможностях нивелирующих фазовое рассогласование обсчёта и отображения, что-то типа отделения памяти видеопроцессора от общей памяти и синхронизация содержимого во время обратного хода луча.
Ладно, спасибо за участие в обсуждении и подведём итог:
1) Вариант атрибут на столбец 1х8 с построчным переписыванием атрибутов наезжающих друг на друга спрайтов в принципе может решить поставленную задачу в самом общем случае, хотя и ценой значительных затрат ресурсов процессоров, поэтому применение такому методу может быть демонстрационное.
2) Можно достичь решения задачи более простыми средствами, но ограничиваясь при этом меньшим количеством цветов на пиксель, чего при определённых условиях может быть достаточно. Для этого достаточно отдать один из битов цвета (например бит плоскости I) в качестве определителя палитры (сигнальный цвет как предлагал Lethargeek). При таком раскладе получаем 8 цветов на пиксель из 4х (16ти) пар 4х битных палитр адресуемых значением атрибута для данной группы пикселов и выбираемых в паре с помощью сигнального бита I на группу из 4х (8ми) пикселов (при этом ЦАП можно попробовать заменить тремя пятиразрядными R-2R матрицами). При этом группы из 4х и 8ми пикселей могут быть сконфигурированы как 1х4, 2х2, 4х1 и соответственно 1х8, 2х4, 4х2, 8х1.
Вопрос: есть ли какие соображения по обоснованию конфигурированию групп пикселей?

[Lethargeek]

нет, не правильно, такое обсуждение полезно даже в случае "извращений ради извращений". Метод, при котором рассматриваются даже бредовые идеи используется в ТРИЗ и называется "мозговым штурмом".

Мозговой штурм производится в соответствующих разделах. А здесь похоже уже все ясно: автор - гений, проект - совершенство, и что-то предлагать/критиковать не только бесполезно, но и кощунственно. Аллилуйя и вечная слава "инженерному мышлению".

ну это в обычных переделываемых игрушках врядли есть, а если есть, то помена не частая (т.е. не несколько раз на строку или на кадр).

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

2) Можно достичь решения задачи более простыми средствами, но ограничиваясь при этом меньшим количеством цветов на пиксель, чего при определённых условиях может быть достаточно. Для этого достаточно отдать один из битов цвета (например бит плоскости I) в качестве определителя палитры (сигнальный цвет как предлагал Lethargeek). При таком раскладе получаем 8 цветов на пиксель

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

Маскировать отдельные плоскости и сокращать количество цветов действительно полезно (тогда при соответствующей настройке палитры получаем полный аналог "стандартных режимов 0-3", или например два 4-цветных режима), нужен только байт безразличия плоскостей для определения атрибутнозависимых цветов, тогда и получится что-то похожее на твое описание. "Группы пикселей" - только 2x2 в режиме высокого разрешения - опять-таки только для "отключения" плоскостей.

А, бесполезно тут разоряться...