Pull to refresh

Comments 23

Помнится мне в детстве я очень интересовался приблудой для соединения ZX-Spectrum и Денди. Но уже в 1997 году позвонив автору этой штуки чтобы узнать как её можно приобрести услышал от него, что мол это всё бесполезная фигня, не выгодна в производстве, и проще использовать IBM. Так собственно оно и вышло. Спектрум ушёл на дальнюю полку, а его заменил Pent… нет, август 1998 года изменил планы и место Спектрума занял 386DX4.

Идея прикольная, но четыре процессора с синхронизацией на мой взгляд сильно сложно.
По логике должно быть достаточно одного, но с «расширенной» разрядностью.
Условно говоря у каждого «настоящего» адреса памяти есть ещё несколько «альтернативных», значений, данные в которых могут отличаться, при этом операции для них делаются те же самые, но процессор принимает решения, например операции ветвления только по «настоящему» значению.
Помимо обычной эмуляции на «настоящих» данных можно будет «подкрасить» ещё несколько альтернативных данных, допустим ещё 4 варианта для 16 цветов.
При отображении учитывать не только «настоящие» данные, но и альтернативные.
Видимо, создание процессора с расширенной разрядностью было всё же сложнее синхронизации нескольких более простых до определённого времени.
платформа была придумана, когда фраза «разработать свой процессор» была равносильна — «открыть научный институт и два крупных завода». Предполагалось, что можно будет хоть и со сложностями, но имплементировать на элементах доступных в СССР конца 80-х.
Spec256 и пошел по такому пути. Как только они отказались от «реального устройства», то сразу убрали все ограничения и проблемы. У них получился Z80 с виртуальными 64 битными регистрами (как в статье и написано), цветов стало дофига, а проблема с рассогласованием пофикшена тем, что выполняется только оригинальная программа (которая ничего не знает о раскраске), а раскрашенные данные только пересылаются, а не исполняются (во всяком случае я так понял, поскольку на Spec256 очень мало инфы)
Про Spec256 не знал, мысль пришла после прочтения этой статьи — вдохновила :)
вот здесь есть описание на английском и какоето количество раскрашенных игр для Spec256. Я как то пытался их игры адаптировать под ZX-Poly, думал что просто возьму 4 снимка адаптированных, но не взлетело, так как если в ZX-Poly заехать при раскраске в область исполняемого кода это критично, то в Spec256 исполняется всегда неизмененная программа.
Прочитал с интересом, расскажите только — а в чем смысл этих устройств? Я понимаю демо- и экстремальное программирование на оригинальных моделях Спектрумов — это своеобразный спорт, демонстрация своих способностей выжать нечто этакое из старого, древнего и всем известного железа.
А когда начинаем создавать странных кадавриков и показывать, что они умеют — не совсем понятно, зачем? Это уже не классический Спекки, но и не современный ПК.
ну во времена когда изобреталось, это было неплохое денежное направление бизнеса, на котором многие поднялись, а сейчас это своего рода закрытие гештальта и пруф оф концепт, к томуже такие решения обычно имеют тенденцию перетекать на абстрактном уровне во что-то другое, так же как команда делавшая Pixar врядли имела мысль, что их подход как-то будет на ZX-Spectrum применен
Автору глубочайший респект, не забывает чудесное время.

В то время все концепции расширения глубины цвета в Спектруме так или иначе базировались на структуре уже существующих видеоадаптеров от ПК. Четыре цветовых плоскости (R,G,B, Y) это концепция видеоадаптера EGA (только там из битов в каждой плоскости формировался индекс регистра палитры, из которого уже и бралась цветовая информация). Концепция VGA предусматривала точку как индекс обширной палитры (256 цветов) и была очень привлекательной идеей. Концепция «прямого цвета», когда точка несла сразу три яркостных значения была слишком затратной и не достижимой по количеству памяти и скорости работы видеоконтроллера.

Сам лично над цветорасширителем серьёзно не работал, однако, сокурсники работали над «палитровщиком», который позволял расширить количество байтов атрибутов так, чтобы строка атрибутов была не для 8 строк, а для одной строки.

Статья — просто класс! Автору большое спасибо. Спектрум — это целая эпоха. И сейчас… периодически на Спектруме играю)

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

Если z80 получают рассинхрон, то машина "глючная", при полностью исправном железе рассинхрона не должно быть

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

А вот тут интересный момент: считывание состояния клавиш из порта клавиатуры по сути сопряжено с clock domain crossing — пользователь то асинхронен процессору. Представьте классический метастабильный «парад планет» — момент нажатия точно совпал с моментом защёлкивания состояния шины в регистр и каждый CPU «оцифровывает» в 0/1 некое промежуточное значение из середины фронта сигнала клавиши — на реальных CPU с вариациями в техпроцессе, да просто с чуть разными температурами результаты могут отличаться.

такие проблемы решаются установкой регистра, в котором фиксируются данные порта клавиатуры, по тактовому импульсу скажем или можно по сигналу INT, врядли кто будет играться с кнопками с частотой выше 50 герц, ну а если непосредственно считывать, то конечно возможно такое, что в рамках одного цикла как-то так вышло что для одного нажата, а для другого отпущена, в такой системе вообще это хорошая идея пропускать все данные из всех внешних портов (магнитофон, клавиатура, fdd) через регистры, обеспечивая удержание информации в течение одного машинного цикла к примеру
Прочитал статью несколько раз, но не понял почти ничего. Автор, как мне показалось, собирался победить конфликт атрибутов оригинального спектрума, не переписывая уже существующие игры. Так? Как я понял в качестве инструмента решения задачи использовались эмуляторы спектрума (на физических процессорах тестов не проводилось). Хорошо. Имеем новый «видеоконтроллер» с 4 бит (16 цветами) на пиксель. Каждый процессор трудится над оцифровкой своего бита. Но я не понял главное — какой цвет будет иметь каждый пиксель? Кроме пояснения для mode 6 (где цвет берется из атрибутов при совпадении цветов INC и PAPER), остальное в тумане. Допустим герой игры в виде спрайта 8х8 с персональными INC/PAPER проходит сцену, где есть свои обьекты со своими атрибутами INC/PAPER. Имеем в данной точке наложение спрайтов героя и фона. Какой алгоритм выбора цвета в данном случае? Большая часть игр оригинального спектрума обычно не трогает атрибуты, перерисовывая только пиксели. Либо «тащит» за героем атрибуты (в виде цветного кирпича). Это и есть конфликт атрибутов… Как не ковыряясь в коде каждой игры решить какой цвет правильный для каждого пикселя?
на выходе стандартного спектрума мы имеем YRGB сигнал (всего 16 вариантов), YRGB в обычном случае формируется INK если бит пикселя выставлен или PAPER если бит сброшен. В ZX-Poly четыре процессора работают каждый на свой компонент один на Y, один на R, один на G, один на B. при базовом режиме ZX-Poly 256 на 192 без использования атрибутов, просто берутся байты из видеообластей каждого «параллельно-работающего компьютера» по одному и томуже адресу, и вместо одного бита на пиксель, получается четыре бита на каждый пиксель, вместо прогона этого значения через атрибуты как в стандартном спеке, они просто превращаются в четыре бита YRGB и идут прямиком на формирователь видеосигнала. Исполняемый код (позволяющих это) игр, не меняется, просто меняются графические данные игр, где-то стираются биты, где-то выставляются. Если игра выводит спрайт на фон без маски, например через XOR, то будет думаю неочень хорошо, но большинство игр имеет маску, которую накладывает сначала на фон и потом выводит на неё пиксели, так работают те игры что показаны в примерах — например After The War 2 и Flying Shark. Маски при адаптации не изменяются и пиксели не смешиваются с фоном.
Решить какой пиксель должен иметь какой цвет, можно в момент раскрашивания, просто глядя на спрайт в памяти
image
Если игра выводит спрайт на фон без маски, например через XOR, то будет думаю неочень хорошо, но большинство игр имеет маску, которую накладывает сначала на фон и потом выводит на неё пиксели, так работают те игры что показаны в примерах — например After The War 2 и Flying Shark. Маски при адаптации не изменяются и пиксели не смешиваются с фоном.

Я как раз про это… Допустим у нас герой и проч. подвижные персонажи размером в один спрайт (8х8) путешествуют на фоне картинки (у которой свой битмап и свои атрибуты). Простейшее перемещение делается довольно непросто: сначала копирование исходного фрагмента фона (размером 16:8, 8:16 или даже 16:16) для его сохранения, потом наложение маски and (очистка зоны персонажа), дальше маска or или xor (вклейка персонажа). После экспонирования кадра надо вернуть сохраненный фон и всё по новой. Т.е. работа с видеопамятью очень насыщенная и разнообразная (я даже не упомянул возможность вертикального или горизонтального скроллинга фона и столкновения/сближения спрайтов различных персонажей). Как в этом разобраться в автоматическом режиме!? Оригинальный спектрум на каком то этапе вынужденно «портит» цвета (из-за атрибутов). Но как это расшифровать? Какие цвета правильные, а какие артефакты? Вопрос имхо не в количестве процессоров…

Спектрум - это в первую очередь клэшенг, с клэшенгом было создано много потрясных игр, которые смотрелись лучше, чем на других платформах без клэшенга - это и Dizzy, Joe Blade, Flying Shark, CHRONOS и многие-многие другие. Почему? Во-первых, чтобы снизить эффект клэшенга некоторые разработчики игр использовали 2х цветную палитру в игровом окне - это как в Joe Blade, Flying Shark, CHRONOS, Robocop, Batman, а это особый стиль графики, называется Карандаш !!! Во-вторых, чтобы снизить эффект клэшенга другие разработчики игр использовали черный фон - это как в DIZZY, Dan DAre3, Буратино и многие-многие другие, а на черном фоне игры смотрятся интересней, чем на светлом на других платформах без клэшенга (тот же DIZZY на IBM PC не вызвал такого фанатизма). Так что именно клэшенгу появилось много культовых игр!!! Спасибо Клэшенгу!!!. Разработчикам нового Спектрума нужно было бы увеличить разрешение экрана до 384*288 или 512*384, но с клэшенгом и стандартной 8 цветной палитрой! тогда игры будут смотреться ещё более интересно, особенно в 2х цветной палитре!!! Ну а если совсем хочется красивой графики на ZX - так может нужно было добавить какой-нибудь VGA-процессор, чтобы можно было делать новые игрушки с нормальной графикой 320*200 256 цветов или выше, а старые запускать через z80 с клэшенгом, как это развивается на ПЦ ??? Без Клэшенга чем Спектрум лучше других 8 / 16-битных систем ? да ничем, а с клэшенгом это другой стиль графики, другая атмосфера в играх !!! Но я понимаю, в 90е годы всем хотелось красивой графики, но сейчас ZX-Spectrum никого красивой графикой без клэшенга не удивит, а вот другим стилем графики может. Нужно увеличивать разрешение, да проц нужен побыстрей, чем z80.

это сейчас клэшинг смотрится как ретрофича, до середины 90-х это рассматривалось как баг который все искали способы победить

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

Sign up to leave a comment.

Articles