О развитии ретрокомпьютеров вообще и спектрума в частности

[AlexG]

Воткните это пожалуйста в слот пентевы, тогда будет ясно.

Кто такой "пентевы" я не знаю - но всегда можно соорудить "переходник" zxbus (или что там) в ram/i2c/spi/uart интерфейс.

[msm]

Чем сложнее? И в твоем и в моем случае надо писать отдельный обработчик графики под каждый графрежим. С точки зрения кода - примерно одинаково.

Не не не. Никакого отдельного обработчика графики под каждый графрежим нет. Даже такого понятия как графрежим нет, вот в чем дело. С точки зрения каждого из ядер, у нас обычный спектрум 256 на 192, с его родной адресацией, с аттрибутами 8 на 8 и тому подобное.
Просто если добавляется ядро, то экранные области мержатся особым образом, чтобы формировать картинку более высокого разрешения и с дополнительными фичами вроде 32 битного цвета. Графика изначально рисуется под максимально навороченный режим. С возможной кастомизацией небольшой вроде начальных условий, чтоб нормально смотреться на оригинальном спектруме, а также в случае небольшого количества ядер.

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

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

[Eagle]

Кто такой "пентевы" я не знаю - но всегда можно соорудить "переходник" zxbus (или что там) в ram/i2c/spi/uart интерфейс.

Вот только без колхоза, а в виде красивой платы расширения для zx-evo.

[MVV]

Предполагаю что это эмулятор.

Скорее FPGA песочница:

FPGA (Field-Programmable Gate Array) – что переводится как «программируемая пользователем вентильная матрица», которая представляет из себя полупроводниковое устройство, конфигурацию которого можно изменять уже после изготовления, т.е. в любой момент времени при эксплуатации. Это возможно благодаря тому, что у пользователя есть возможность вносить изменения в логику работы принципиальной схемы, используя, к примеру, исходный код на языке проектирования VHDL или Verilog.

Нужно 2 абсолютно идентичных ядра, которые работают от одного тактового генератора, такт в такт.

Уже сделано, чтобы не усложнять взял 2-ва z80 ядра, тактируются от одного источника 3.5МГц.

Далее нужно как то сделать мержилку экранной области. Если 2 ядра только, то либо 1 строка дополнительная, либо столбец.

Добавил двух портовую память 16 Кбайт, одним портом управляет первое ядро, вторым - второе. Выход идет на видео автомат, который строит 640х480@60Hz, для наглядности слева в верхнем углу первое поле 256х192 правее сразу от него второе 256х192.
Ниже можно попробовать разместить их мержилку.
На фотке в левом углу выводится пока один полный видео экран первого ядра. Решил по быстрому попробовать, нужно еще синхронизировать его с основным 60Hz:

[Reobne]

И как соединять цвета? 4 бита с одного ядра, 4 с другого, вот тебе и 256 цветов? И палитра для каждой игры постоянна, от автора "раскраски"?

[breeze]

Зачем пэцэ там, где и без него можно обойтись?

Дооо! ну давайте ещё будем сидеть на ч/б тёплом ламповом «Рекорд'е», попутно угробим без того и так почти севшее зрение, долбить будем строго на 40 клавишах и сохранятся строго на ленту

Раньше других возможностей не было, поэтому и корячились на чём бог послал. Отказываться сейчас от редактора в котором отрыто 100500 вкладок с сорцами, где на экране отображается одновременно далеко не 32 строки, с подсветкой синтаксиса, и быстрой и удобной сборкой модулей. Ну уж нет, увольте, я конечно мазохист, но отказываться от удобства работы на экране 1920x1080 не собираюсь.

А для тёпловости и ламповости у меня есть PentEvo. На который при необходимости, без лишних телодвижений я закину свой софт через COM-шнурок.

Зачем крылатыми ракетами с термоядерным зарядом комаров в лесном домике убивать?

Затем, что не надо бредовые сравнения приводить, и уж точно не надо ровнять всех под свои мерки.

[msm]

И как соединять цвета? 4 бита с одного ядра, 4 с другого, вот тебе и 256 цветов? И палитра для каждой игры постоянна, от автора "раскраски"?

А здесь очень много вариантов . Добиваться нужно не 256 цветов, а как минимум 24 бит на пиксель. Насчет альфаканала не уверен в целесообразности. Соответственно, учитывая весьма своеобразную организации экранной области стандартного спектрума, там мерж будет мягко говоря не совсем тривиальный. Но если за базу брать какой нидь Commondore 64, Или ATM с его расширенным режимом - здесь тоже все гораздо проще было бы.

Если брать за основу всякие хитрые режимы всяких ZX EVO, то тупо смешением средних цветов. Если брать за основу базовый спектрум, то здесь нужно хорошо продумывать, там явно будет весьма непростой способ. Навскидку вижу решение - разбивание на ядра определенной группы по знакоместам, а далее тупое смешение цветов. Да, с клешингом ! И да, вручную там вообще будет нереально разобраться как это все оптимально смешивать. Только в автоматическом режиме преобразовывать! Или как вариант - забить за 1 цвет на пиксель, кто захочет выпендриться - пусть мультиколором программным добивает .

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

Но игрушки вроде цивилизации, героев и т.д - это можно делать со вполне приличной графикой. С анимацией будет сложнее конечно.
Если брать за базовое разрешение 2048 * 1536, для монохромного режима потребуется 64 ядра. При этом если делать скроллинг, то просто это сделать только с шагом 8 пикселей, для меньших шагов придется весьма хитрые алгоритмы придумывать, и я не уверен что это вообще реально. То есть ограничений до фига и больше, естественно это не панация, полноценный современный ПК не сделать даже на миллионе ядер таким образом. Но ИМХО это намного круче было бы любого Спринтера.

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

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

[Eagle]

Дооо! ну давайте ещё будем сидеть на ч/б тёплом ламповом «Рекорд'е», попутно угробим без того и так почти севшее зрение, долбить будем строго на 40 клавишах и сохранятся строго на ленту

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

[breeze]

Да, давайте для замены пары байт в работающей программе

Зачем заменять пару байт в РАБОТАЮЩЕЙ программе?

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

Нет блин) я буду на 3.5MHz подгружать проект в 450кб и ждать каждый раз по полчаса пока всё соберётся. Юморист.

[Eagle]

Зачем заменять пару байт в РАБОТАЮЩЕЙ программе?

Никогда игры не ломали? Не было у вас скорпиона с проф. ПЗУ, тоска-печаль.

---------- Post added at 17:01 ---------- Previous post was at 16:57 ----------

Нет блин) я буду на 3.5MHz подгружать проект в 450кб и ждать каждый раз по полчаса пока всё соберётся. Юморист.

Как же раньше люди игры писали для спектрума на спектруме? А ещё, как же я умудрялся переделывать игру на орионе под 2МГц и компилировать её по сто раз на дню? Может я все ресурсы вроде оцифровок звука, графики, знакогенератор хранил отдельно? Загадка...