Мультипроцессор
 

Пока ковырялся со своим наладонником, продумывая масштабируемость, подумал грешным делом, а почему на спеке, в особенности для демосцены, нет мультипроцессорных решений. Мультисоунды есть.. Википедия дает общий ответ по "Мультипроцессор".

Так вот, сразу же возникло несколько вариаций на которые, возможно, у народа есть ответ/светлая мысль. :v2_cheer:

Предположим, что есть общее поле памяти и много CPU. Общий выполняемый код. Процессоры определяют свой номер по чтению из условного порта, допустим, мой уже любимый, порт #00h.

Определить же наличие и количество процессоров будет легко, учитывая то, что каждый выполняет свой код в зависимости от состояния порта. Количество зверьков до 256. :v2_yahoo: :v2_cheer:
На практике хоть 2-4-8, это вполне нормально для пробы.

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

Дело в том, что у меня в zx-palm для минимизирования зависимости от спецпрограммирования применяется "ход конем", а именно ez прогружает образ ппзу в рам-память Z80, дальше запрет записи, ez пускает и тормозит его в зависимости от задач. Z80+ram+2микрухи - получается отдельный модуль. В данной схемной реализации нет особых проблем в добавлении n-го количества Z80-модулей, т.е. это нужно учесть заранее.

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

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

боян..
http://www.zx.pk.ru/showthread.php?t=4564

:)
 

Я видел эту тему, но думаю, это не из области практики. Очень близко.
Возникли именно практические вопросы, т.к. в "наладоннике" изначально заложено два проца, так что огород городить, когда можно поднять затею "боян"'ов на практически реализуемый уровень и даже пойти дальше. Накладно для 256 камней, но вполне по силам для 2х(для всех), 4-8ми для масштабируемых. :v2_cheer:

Добавлено через 13 часов 12 минут
Ну и чего все замолчали?

Добавлено через 14 часов 18 минут
Какие мысли по поводу организации записи в память? :v2_conf2:

хмм ктото увеличевает CLK ктото толичество процов это мода щя такая или есть мысли?
а вапщето сушествуют такие уже давно но там кантроль процов сложно незя просто заставить один читать то другой читать се

архитектура это штука более сложная и основательная чем просто процы к памяти подрубать

Совсем забыл
 

Есть не только мысли. Я задумался в "Наладоннике" о том, что хорошо бы, чтобы у ВСЕХ реальщиков была возможность получить теже или близкие к моей разработке возможности. Это в свою очередь не оставит zx-palm в программном вакууме, который погубил много хорошего.
Так вот, очень долго (лет 12) крутилось в голове слово, - "как" (подразумевается, как объять все разбросы и шатания), - со временем пришло решение..
Для начала мне надо до конца года показать "Наладонник" на любой из zx-пати, т.к. многие к кому я обращался за софтверной поддержкой говорили дословно, - "для начала сделай zx-palm, а после мы включимся в проект со стороны софта", - и никакие разумные доводы, что для начала нужно хоть какое-то наполнение, по минимуму. Снова задумался, теперь уже меньше, года на три, минимизировал влияние программистов на проект особенностями схемы и тройкой лишних микрух.
Пока жду макетки, решил, что торможу зря, начал продумывать пошаговую отладку участков своей схемы на реальном спеке и вот оно. :v2_yahoo: Возможен апгрейд до 21MZh без переделки базовой платы. :v2_yahoo: Нет никаких проблем подключить шустрые процессоры к реальному спеку.
Прототип вообще соберу из того что уже есть, без заморочек (128+AY). :v2_smoke:

Если у каждого своя память, то какие проблемы-то. А вот когда они будут писать результаты своей работы в интересующую нас область, вот тогда и потребуется что-то особенное.
Сейчас вообще склонен к тому, чтобы контроллер в момент формирования экрана читал одновременно со всех памятей одновременно. Страшно подумать для скольки процессоров это прокатит, т.к. адреса для всех, тоже что и для одного, а данные вообще мимо ULA. Что и как миксовать, вот это придется решать.
Вот с ДМА'бы eZ'товским разобраться, вот это уже хорошие доп CPU по 50MZh каждый. :v2_finge:

Добавлено через 12 минут
Ну согласись, в решениях, где можно и так и сяк, да еще не теряя совместимость с базовой, добиться результатов превосходяшие топтание на месте, это если не прорыв, то хотя бы шаг вперед.
Кстати, ты не против, если я использую твои наработки. Проги есть?

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

zx-демо монстр
 

Ну естественно в некоммерческих целях, многопроцессорный zx-демомонстр.
Если в коммерческом, то никаких загрузчиков-пускателей, а один код и разные значения одного и того же порта для каждого из камней, синхронизация.. В любом случае для демосцены нужно что-то более конкретное.
Уже руки чешутся поднабрать макеток (сегодня видел в магазине под QFP) и намакетировать.. :v2_wink2: ..но нет, сначала zx-палм (в нем и так, в идеале, два проца).
Кстати, кстати, что-то из реала уже есть, когда сразу две экранных области используют, одну для графики, другую для атрибутов. Очень приличные картинки получаются. Правда по формуле 1x8. :v2_conf2:

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

А теперь сам конкретизируй, что тебя интересует. :v2_conf2: