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

[msm]

Допустим у меня два z80 ядра работают одновременно Z80 instruction exerciser for Reverse. msm, что ещё нужно сделать, чтобы проверить вашу теорию? Могу добавить еще 2-ва, к примеру для простоты эксперимента и графику 640х480. Там разместить видео область 4-х спектрумов без бордюра, это 512х384.

Проверить...

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

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

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

То есть если был бит 1. В двойном разрешении он будет считаться как 11. Его можно преобразовать в 10, но никак не получится получить 01, что очень нехорошо. Чтобы было 01, нужно изначально выставлять на нулевом ядре пиксель в 0, но тогда при отключении других ядер, например при запуске программы на оригинальном спектруме получим ухудшенную графику, что плохо, концепцию еще нужно более подробно продумывать.

Если параллельно все запустить на существующем коде, получится тоже самое, что сейчас. Графика не изменится. Если же в одно из ядер допустим в ПЗУ бейсика для одного символа для буквы S поправить какой нибудь бит из 1 в 0, то получим в одном месте более тонкую линию .

[haywire]

Цена.

Есть такое неписанное, но всегда работающее правило. Софт *всегда* дешевле.

Энергоэффективность

Эмулятор работает на любом arm-е. Телефон, планшет. Я сильно сомневаюсь в более эффективном решении.

[Mick]

Еще немного мыслей.
На мой взгляд, надо развививаться не сколько в количестве ведер, а расширять разрядность. Если посмотреть на историю, до достаточно добавить корке Z80 еще 8 бит шины данных и интрукции работающие с 16 битной шиной данных, уже на мелких скоростях будет существенный прирост. Далеко не надо ходить - возможности Амиги.
Причем совместимость с обычным Z80 можно делать через специальный порт. Ну а если 32 бита, то вообще и операционка может взлететь какая нибудь.
Кстати, говоря современные изделия как Reverse или Aeon как раз годятся для таких исследований.
Только вот упрется все как обычно - кто софт напишет

[Eagle]

Софт *всегда* дешевле.

И чемодан батареек к часам... как в ералаше.

[Reobne]

Фактически всё уже сделано, дело только за софтом

Софт должен подходить от Spectrum128.
И какова цена, и сколько ватт кушает? Реально-ли это пик дешевизны и непрожорливости?

[Eagle]

Софт должен подходить от Spectrum128.
И какова цена, и сколько ватт кушает? Реально-ли это пик дешевизны и непрожорливости?

Смотрите в сторону Reverse и Aeon.

[Advertiser]

[AlexG]

Придумайте математический сопроцессор под zxbus

А под i2c или spi не подойдёт ?
Можно 32 или 64 бита флоат.
всего за $20

http://micromegacorp.com/



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

[Eagle]

А под i2c или spi не подойдёт ?
Можно 32 или 64 бита флоат.
всего за $20
http://micromegacorp.com/

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

[msm]

Да выполнить-то не проблема, но как вы синхронизировать потоки собираетесь? Это ключевая вещь в многопоточном выполнении. На z80 синхронизация возможна только извне.

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

[Максагор]

Драйверы - не на спектруме такое однозначно.

Почему? Привычное дело. Взять, например программу WDC - там вставляй свой собственный драйвер IDE и - вперед. Также были примеры с драйверами верхней памяти (например, в игре "Страна мифов"). Так что практика такая была и есть.

Оверхед черти какой.

В смысле?

И сложнее программировать.

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

Уже ОС нужна и тому подобное.

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

Уже ОС нужна и тому подобное.

ОС спектруму нужна (это мое убеждение) но вне зависимости от темы обсуждения. А в ее рамках могу только сказать - "ничего подобного".

Во времена PC, когда отдельно фигачили графику отдельно под CGA, EGA, VGA - по существу это был ад. С приходом винды немного все получше стало, уровни аппаратных абстракций и тому подобное

Ну сравнил - современные писишки с графическими карточками, где весь низкоуровневый вывод графики "зашит" в их железе и на ОС действительно приходится только "уровень аппаратных адстракций". Но если копнуть эти низкоуровневые процедуры, то наверняка мы найдем там разные варианты вывода под разные графрежимы. А Спектрум, хоть "параллельный", хоть нет - это и есть
"времена PC, когда отдельно фигачили графику отдельно под CGA, EGA, VGA". И ничего "адского" и зазорного в написании пакетов графики под отдельные режимы я не вижу. На том же АТМ/Ево есть идея так модернизировать старые игры - найти в дизасме вызовы подпрогамм по выводу спрайтов, текстов и проч. и Перенаправить их в область #0000-#3FFF, где предварительно мы отключим ПЗУ и вставить страницу ОЗУ пользователя, куда поместиьт свои подпрограммы вывода на экран и свои наборы справйтов. Фишка в том, что стандартизировав такие точки входа, можно подгружать 16Кб-странички уже под любой тип экрана (и подгружать их в зависимости от типа требуемого экрана).
Как только разберусь с текущими проектами под TASiS, попробую для эксперимента поработать с 48К-играми на этот счет... Вот это интересное направление, под которое возможно привлечь людей. А "Давайте создадим мегажелезку..." - это пусть в никуда.