Просмотр полной версии : ZX-Poly™ platform
moroz1999
12.01.2007, 12:41
как реализована раскраска спрайтов?
Error404
12.01.2007, 12:55
Читал pdf-ник, много думал :) о том, за что же разработчики так не любят диспетчер по 64к (или - что за странная любовь к диспетчеру по 16к в единственном окошке, т.е. негодного ни на что кроме свопинга для единственного процесса). Чтобы написать многоПРОЦЕССОВУЮ систему полезнее не 4 процессора (что, конечно, тоже не лишнее) а диспетчер, позволяющий за минимальное число тактов переключать весь контекст процесса (т.е. в идеале - всё куцее 64к адресное пространство Z80). Т.е. нужно 1 диспетчер по 64к или 4 одновременно и независимо работающих диспетчера по 16к (каждый в своем окне: 0..3FFF, 4000..7FFF, 8000..BFFF, C000..FFFF).
--
Что понравилось - наконец то есть возможность выключения дурацкого ПЗУ, занимающего четверть адресного пространства. И режим экрана, на котором можно организовать нормальный терминал 80х25.
Что понравилось - наконец то есть возможность выключения дурацкого ПЗУ, занимающего четверть адресного пространства.
Да уж сколько лет есть, Kay, Scopion и т.д.
Но не юзал ведь почти никто.
Вот, чесное слово, раз на жесткой логике - собрал бы. Самая сложность - в ограниченности свободного времени, сложности заказа этой самой логики (город провинциальный, логика дешевая, почтой не вышлют мелочь такую), ну... и может быть в отсутствии платы под такой девайс. А так - руки просто чешутся.
Error404
12.01.2007, 13:38
Процессор легко может переключать смещение своего ОЗУ в общем блоке, единственная проблема подготовить переход, что бы не вылететь в пустоту
Ага, вот этого то я и не уловил, просмотрев "по диагонали" описание. "Общий блок" - это все 512к? Тогда это то, что нужно.
А какие-то аппаратные стенды уже делались (хоть когда0нибудь) под это? Или это пока только модель?
Error404
12.01.2007, 13:42
Да уж сколько лет есть, Kay, Scopion и т.д.
Но не юзал ведь почти никто.
Ну, я ничего про эти модели не знаю.
А как можно это не юзать, если без этого CP/M нормально не запустить (там все ПО странслированo на работу с 100h).
CityAceE
12.01.2007, 13:54
Основная идея раскраски старых игр, что одновременно работают четыре спека каждый выводит видеоинформацию на свой битовый план,
Spec256 работает по тому же принципу, только там 8 Спектрумов параллельно трудятся, создавая 256 цветов. Но, к сожалению, такая реализация пагубно сказывается на те игры, где спрайты одинаковы, но раскрашиваются атрибутами. В иных случаях это может оказаться критично.
По такой схеме 24 проца будут TrueColor выдавать с немерянной скоростью, проблема в том, платформа должна не только отрабатывать этот Use case, но и:
1) быть адекватной в программировании
2) не быть сверхсложной для сборки
3) Быть способной к работе не только на фазе эмуля
Я посмотрел, что 4 проца наиболее оптимально
на 24 проца эмуль тоже есть? с эмуляторами хотелось бы поработать...собирать в железе на рассыпухе? возможно найдутся желающие, какова стоимость?
Lethargeek
12.01.2007, 15:54
Целых четыре проца всего лишь для раскраски игрушек - "непропорциональное применение силы", как говорится. Имхо время подобных монструкций прошло - чисто как игровой автомат оно может представлять интерес, но не как "развитие Спектрума". Не для всех задач многопоточность эффективна, это раз (уж лучше воткнуть один камень побыстрее). Юзать потоки одновременно с новой 16-цветной графикой нельзя (как минимум сильно неудобно), это два. Ориентация только на старый размер экранчика и отстойную адресацию - тоже очень плохо и эффективности не прибавляет, это три. Да и всякие 512x192 итп уже делали...
Всем интересующимся битплановыми режимами советую почитать доки по EGA (не обращая внимания на пц-маразмы в деталях), чтобы понять - не нужны четыре (итд) процессора для сохранения скорости работы старых игрушек, да и переделок в них тоже понадобится минимум (вместо перерисовки спрайтов по всем плоскостям нужно будет вставлять однократные команды выбора цвета). Единственная загвоздка - программный скроллинг, но и с учетом сих трудностей даже до предела упрощенный вариант "один Z80 на 21МГц + EGA-подобный (не "ATMEGA"!) режим" выглядит универсальнее и перспективнее, чем "четыре Z80 на 3.5МГц (да сколько бы ни было) + четыре процесса".
Не то чтобы я был вот прям именно за такую схему... ;) Конечно существует некий "порог монструозности", переходя который, становится невыгодно использовать жесткую логику (в чем меня убедили товарищи железячники). Да и завязывать пора с кучей не в меру "оригинальных" клонов и переходить наконец на слотную архитектуру (разрабатывать не "новые Спектрумы" целиком, а периферию).
Кстати моя схема позволяет избежать атрибутных траблов
Да ну? --->
Spec256 работает по тому же принципу, только там 8 Спектрумов параллельно трудятся, создавая 256 цветов. Но, к сожалению, такая реализация пагубно сказывается на те игры, где спрайты одинаковы, но раскрашиваются атрибутами. В иных случаях это может оказаться критично.
Этим дело не ограничится. Подгрузка графики в многоуровневых игрушках - уже проблемы. Запакованные данные - то же самое. Любая вычисляемая графика (3D в том числе, но не только) - тоже не прокатит. Слишком узка область применения у девайса, если так уж хотим обойтись без копания в коде. Хотя, как уже писал, в качестве эдакого автомата для "ретрогеймерства" - вполне годится. Если эмулятор не торкает. :)
P.S.
По такой схеме 24 проца будут TrueColor выдавать с немерянной скоростью...
:D
Вы или плохо прочитали или плохо уяснили, раскраска старых игрушек там - один из возможных эффектов архитектуры, многопоточность и одновременный вывод цветной графики вполне реальна.. Если бы мне захотелось очень удобную железку :) то я непременно сделал бы очень удобную железку, но мне нужен был именно Спектрум :) а не EGA c Z80 на 21 МГц. Что же касается слотных компов, то Спек всетаки не совсем из их класса и порог "монструознусти" я старался не переходить :) так как "что сложно - не нужно" :) Я бы назвал эту спецификацию не более клоном Спека чем Спек 128 был клоном Спека 48 го :)
Из выложеной документации совершенно непонятно, как осуществляется синхронизация этих самых ПМ. Как осуществляется загрузка софта? В каждый ПМ по отдельности, сиречь одна и та же программа с "разными цветами" по одному и тому же адресу в четыре ПМ? А как потом осуществляется синхронное выполнение когда? Имеют ли все 4 ПМ общие магистрали (а судя по описанию прерогатив ПМ0 они должны быть), как они организованы, как организован доступ к ним? Как вообще делятся общие ресурсы между всеми ПМ?
Игорь, а торговая марка (ТМ) "ZX-Poly" реально зарегистрирована или это так - между нами? :).
Lethargeek
12.01.2007, 17:40
многопоточность и одновременный вывод цветной графики вполне реальна...
Если что-то полноцветное надо вывести на экран, должны работать все четыре Z80 (причем крррайне желательно, чтобы синхронно), а это значит - надо останавливать все четыре активных процесса, если одному из них приспичило что-то вывести (даже только в "свое" окошко). Иначе - понадобится писать спецбиблиотеку с несинхронной отложенной записью только в теневой экран - то есть фактически полноценную видео-биос, причем весьма специфическую. Либо вешать вообще весь видеовывод только на прерывания (в очередь), что тоже не есть хорошо.
один из сценариев:
CPU0 грузит программный блок, затем грузит измененные блоки графики в адресное пространство других CPU (которые на WAIT), после окончания загрузки на все процессора передается RESET с записанной командой перехода на старт программы, далее они работают синхронно, не взаимодействуя друг с другом.. конечно могут быть и другие варианты
Я в выходные еще допишу доку, для уточнения вопросов, а то мне то она понятна и на низком уровне, но постораюсь написать поподробнее..
Хм, надеюсь дописаная дока ответит на многие вопросы. Настораживает "один из сценариев", я так думал, что с конца 90-х это всё уже продумано от и до. Может я просто себе всё сложно представляю?
Lethargeek
12.01.2007, 19:17
А что такого? Думаю что Вы бы в 82 вообще были бы до крайности возмущены нелинейной организацией видеопамяти
Гы, в 82 я не знал, что такое программируемый калькулятор, не то что цомпутер. :) А так конечно был бы возмущен, но только не самой "нелинейной организацией", а лишь не самым эффективным вариантом реализации оной.
только это мелочи
Я херею, дорогая редакция... :v2_wacko: Но если главная цель - попаять, тады ладно. ;)
Спек вообще неудобная платформа это его концепция в какой то степени
Аццкий отжиг!! :v2_clap2: :v2_clap2: :v2_thumb:
А мужики-то не знают... 10000+ софта на него накатали, мазохисты... :v2_laugh:
Простой - да, но неудобный - очень спорно. Удобство с простотой или мощностью вообще никак не связано.
Lethargeek
13.01.2007, 06:08
Да предлагаю, описываю... поиск по форуму рулит... ;)
moroz1999
13.01.2007, 10:19
Основная идея раскраски старых игр, что одновременно работают четыре спека каждый выводит видеоинформацию на свой битовый план, видеосистема берет информацию с этих планов и переводит в цветовую, к примеру в AfterTheWar я просто в тупую постирал спрайты в разных версиях программы загружаемой в разные спеки (неоптимально, знаю, но делалось на время)мдаа, всё гениальное - просто :D
А эмулятор или скриншоты где можно скачать?
4 спека в параллель для формирования битпланов - это 16 цветов с потерей атрибутов. Если ещё учитывать и атрибуты, то диапазон использованных цветов сильно расширится - виртуально получим 16 цветов в пределах одного знакоместа из виртуальной палитры в 64K цветов. Результирующий цветовые составляющие можно считать так (составлено из отдельных битов):
B=I3,I2,I1,I0,B3,B2,B1,B0
R=I3,I2,I1,I0,R3,R2,R1,R0
G=I3,I2,I1,I0,G3,G2,G1,G0
казало бы идея интересная, но мне что-то не очень нравится, да и надо ли такой огород городить ради 16 цветов на каждую точку=\ вся система на 4х процах... все гениальное, как известно из пословицы просто, а здесь все не просто... мультиколор кто-то кодил? ну и как? можно... но геморрой!? так мне и предложенная система не видится проще, да и делать надо все с нуля, а что там получится... в общем imho, шкурка выделки не стоит=\
да, кстати, такой режим уже реально существует (кто не знал, читайте ig#8, 9) уже можно поиграть в несколько игр - pang, одна из них. мене существующая реализация нравится больше, да и сколько можно изобретать велосипед. если же хочется получить под этот режим многопроцессорный более производительный спек, то мне кажется лучше задуматься, как к уже существующему железу прикрутить второй zilog в 21MHz. насколько я знаю, я уже не первый кто о подобной идее задумывался, вот только до последнего времени я не осознавал где в этой красивой идее скрыта проблема (ну не железячник я), а проблема заключается в доступе к памяти и портам ввода вывода, конечно как кодер я понимаю, что часть проблем можно будет решить программно, но кое-что все же необходимо решать аппаратно.
на счет отключения пзу и подключения вместо нее озу. полностью согласен с newart'ом=\ только хочу добавить, что не только на скорпах и каях этого можно добиться, но также на профиках, и я думаю что не ошибусь, сказав, что и на атм, а быть может и на метровых и полуметровых пентагонах.
кажется лучше задуматься, как к уже существующему железу прикрутить второй zilog в 21MHz
а еще лучше существующее железо нафиг выкинуть, оставив только z80 и все обращения к нему перехватывать и выдавать на другое, современное и "правильное" железо :) которое убрать в ПЛИС...сам же z80 оставить ислючительно для выполнения ранее разработанного кода, да и то не всего, а менее всего тормозного
Вот именно, что сделать...а выше перечисленное как говорится отдай деньги - и спи спокойно!
Lethargeek
15.01.2007, 06:14
задача всетаки сделать Спектрум,
В том-то и беда, что все постоянно "делают новый Спектрум", вместо того чтобы создавать решения, пригодные к использованию на любом уже существующем Спектруме (я конечно только про видео).
абсолютно согласен, я собственно выше об этом и говорил.
В том-то и беда, что все постоянно "делают новый Спектрум", вместо того чтобы создавать решения, пригодные к использованию на любом уже существующем Спектруме (я конечно только про видео).
Что бы к имеющемуся спеку приделать видяху, надо будет напаять кучу соплей, нарезать кучу дорожек и т.д. как обычно, просто слотом расширения не отделаешься. А если все эти сопли развести на новой матери, так, что бы их не было, то это и будет новый спек. А если ещё добавить обычные PS/2 и IDE - контроллеры, то получится как раз то, чем занимались спринтеровцы, недоПЦ (последние к счастью и сейчас занимаются).
Поэтому железо должно быть избыточно мощным с перепрограммируемыми режимами, чтобы собрав один комп, получать из него на свое усмотрение любой клон. Только не надо матерится, называя это эмулятором. Это не эмулятор! Просто отдельные железные компоненты поддерживают кучу режимов и настраиваются на нужный.
Поэтому железо должно быть избыточно мощным с перепрограммируемыми режимами, чтобы собрав один комп, получать из него на свое усмотрение любой клон. Только не надо матерится, называя это эмулятором. Это не эмулятор! Просто отдельные железные компоненты поддерживают кучу режимов и настраиваются на нужный.
Просто некоторым людям спать спокойно не даёт "идеология" о эмуляции и монстростроении. Если им нравится считать это монстром, эмулятором и вообще бредовой идеей - их право, а кого такие тараканы не беспокоят, пусть разрабатывают и юзают в удовольствие, не сходя с ума по "идеологиям". Главное, не надо превращать это в религию, высказал мнение - молодец, а навязывать в каждой ветке не надо.
Что бы к имеющемуся спеку приделать видяху, надо будет напаять кучу соплей, нарезать кучу дорожек и т.д. как обычно, просто слотом расширения не отделаешься. А если все эти сопли развести на новой матери, так, что бы их не было, то это и будет новый спек. А если ещё добавить обычные PS/2 и IDE - контроллеры, то получится как раз то, чем занимались спринтеровцы, недоПЦ (последние к счастью и сейчас занимаются).
Это мягко говоря не так :) Более того, иначе чем через системный разъём вообще быть не должно.
Пожалуй беда не в том, что кто-то постоянно делает новый спектрум ,беда в том, что кто-то вообще ничего не делает
Вот тут в точку :)
Игорь, хорошо, это все великолепно, идея правильная, почитал документацию - в общих чертах можно сложить впечатление и даже можно представить что это таки реально создать, оно сможет раскрасить даже более чем 60% существующих игрушек, и будет пользоваться спросом.
Собственно теперь вопрос - когда Вы планируете предоставить это хотя бы в виде программного эмулятора, чтобы можно было реально погонять и потестировать идею (а увидеть ее "в лицо" - это лучшая реклама для проекта), и что будет дальше - я уже конкретно о "железной реализации" - что и как Вы планируете делать (я так понимаю что будет вариант полностью нового "железа", а будет ли вариант "примочки" к любому существующему спеку?), и если планируете то как скоро, и если не скоро - то почему - вообще, как я понимаю - изначально этот топик ориентирован на оценку Вашей идеи и последующее привлечение инвестиций под развитие идеи? ;)
Обновил описание в виде PDF файла по старой ссылке. Включил больше графических представлений, нашел несколько злостных (!) опечаток (всетаки документ одновременно с написанием эмуля делался. Эмуль выложу тоже но чуть позжее..
Повторная ссылка на документ http://www.igormaznitsa.com/zxpoly/zxpoly_rus.pdf
Ещё вопрос: видеоконтроллеров сколько, тоже 4? А если он один, то как делится доступ к видеопамяти между ним и четырьмя ПМ? Кстати, на с. 14 хороший рисунок, от тебя, Летаргик, я подобного уже добиваюсь не знаю сколько.
иначе чем через системный разъём вообще быть не должно.
Да это понятно. Но реальность накладывает свои коррективы. На скорпионы, пентагоны 1024, каи и прочее, что имеет системный разъём, видяху только через него, без всяких соплей подключать пока не получается. Если я не прав, покажите мне пример такой видяхи.
Если я не прав, покажите мне пример такой видяхи.
Что бы показать тебе пример, надо иметь саму видяху, а её ещё нет. Однако ZX-BUS имеет весь набор необходимых сигналов для подключения видеокарты. Единственный момент, если как-то хитро/умно захочется сделать доступ видяха к хостовой памяти, то придётся немного порезать, но всё равно, не много.
Конечно один видеоконтроллер, последовательно отображающий видеообласть (ти) согласно показателям смещения окон памяти процессорных модулей.. т.е. так же как на спеке.. он не производит каких либо акселераций, сервисных функций или чего то подобного.. прсто в тупую перебирает адреса с заданными смещениями и отображает содержимое
В таком случае память должна быть физически построена отдельными микросхемами (скажем 4 штуки по 128К) и чтении из областей видеопамяти каждого ПМ происходит параллельно, так? Есть ли у ПМ общие ресурсы? Если есть (а память уже не может быть общим ресурсом из-за ВК), как они делятся? Не много-ли накладных расходов получается, если фактически иметь четыре порта 7FFD и т.п.?
В документе написано что 4е порта, значит четыре порта :)
В одновременную работу процессоров с памятью (если она медленная) можно вводить сигналы WAIT, так что все девайсы могут работать хоть с одной микросхемой (и видеоконтроллер так же). Я описываю теоритеческую архитектуру, факт что она может быть реализована аппаратно, как она будет реализована это уже вторая задача, так как вариантов масса.
Короче по сути это просто идея и тогда, когда ты мне в 99-м писал об этом, это тоже была идея, так?
Эмулятор надо всетаки в какой то божеский вид привести, но думаю что версию на этой неделе выложу, правда работа там только с TAP файлами и на Java он, система диагностики происходящего - зачаточная..
Мне инвестиции под него не удалось в 97-99 м получить а сейчас думаю ситуация еще хуже, так как с коммерческой точки зрения ZX-Spectrum уже практически несуществует, это fun-platform так что топик организован, что бы ознакомить окружающих с идеей, получить трезвые оценки и послушать размышления, если кто из железячников захочет имплементировать данную архитектуру, то в документе условия определены. Просто из всего того что выдвигается на звание "нового русского спектрума" эта платформа наиболее подходит под определения выдвинутые мною в одной из веток форума про то, что может называться "спеком"
Да вид пофиг какой вид у эмулятора, на самом деле - главное чтобы можно было его запустить, да погонять на нём несколько десятков игрух, посмотреть как будет, отсюда собственно сразу и будет ясно - интересно это или нет, в принципе, вероятно это даже поможет привлечь инвестиции, хотя бы на тестовую модель в железе.
Просто, по моему мнению, эта идея - наиболее интересная из всего, что я читал на этом форуме о железе за последние несколько лет.
В плане именно самой платформы - я стойкий поклонник только одного спектрума - Скорпиона, в свое время для него было создано практически все, что можно было сделать. Почти все я и достал себе, кроме GMX (никто не хочет продавать, а предлагал много денег :(
Я те как спец скажу ( учитывая мое почти годовое сотрудничество с Actel.ru ), что 4-е z80 потянут на $35-40 плисину и за 1.5 месяца (работая каждый день по 10 часов)ты все это хозяйство не верифицируешь.
Ок, тогда на этой неделе выложу точно.. некоторые игрухи не запускаются почему то (TAP файлы), но у меня подозрение что они криво записаны, так как Unreal Speccy тоже не запускает их..
Думаю если на ПЛИС делать, то реализация такой архитектуры месяца полтора займет (если не на базе готовых модулей), в 99м и была попытка схему под ПЛИС разработать, но тут надо спецов по ПЛИСам спрашивать так как я к примеру в основном жесткой логикой да микроконтроллерами оперировал..
В общем, ждем наглядной презентации в виде эмулятора, было бы очень интересно глянуть, то что не все запускается - не проблема.
По поводу реализации - да, в наш век явно стоит попытаться это реализовать на ПЛИС, и как можно в меньшем количестве корпусов, и, конечно, наиболее интересный вариант был бы - не в виде совсем нового компа, а именно в виде дополнительного модуля, который можно прицепить на все основные (известные нам) типа Спеков, и как я понимаю, видеовыход будет заложен именно в этой карте? Сразу делать реализацию с возможностью подключения VGA монитора, времена телевизоров и старых тазиков типа МС уже прошли. Вот тогда, я полагаю, идея получит довольно интересное развитие..
BTW, запихивание всех Z80 в ПЛИСину опять же не самый критический момент, не будет большой проблемы если будут стоять именно процы, а ПЛИС рулить всем остальным. Хотя конечно вариант конечной реализации - это уже прерогатива автора.
Уж больно мне охота посмотреть на старые шедевры в нормальной раскраске :v2_cheer:
Вот если сделаешь нормальную связку на плисине, к 4 обычным z80, уложишься в 10-12 микросхем и в 60 евро по деталям (без учета печатной платы и конструктива), тогда это будет комп.
Думаю все же какую-то часть вентилей оставишь на умножители ( а еще даже лучше "бабочку") и не забудешь про нормальную внешнюю шину.
Raydac, пробовать надо, в итоге. Если делать в виде отдельного компа - тогда упрощать до безобразия - не пытаться напихать в новый спек магнитофонные порты, контроллеры дисковода и тп - просто ограничиться флеш-драйвом, в который можно будет набить кучу образов игрух и балдеть. Ну, муз.процессор обязателен. Вот и будет в итоге игровой комп с огромным количеством готовых игр и софта под него, свою нишу займет вполне, среди тех кто ценит подобное а не игры на PS2 (это просто отдельный контингент и вопрос вообще).
По цене - да пофиг, даже если прототип таки заработает, будет доведен до ума, сможет реально раскрасить хотя бы 60% софта, быть с флешкой (ну а под остальное можно оставить системную шину - ее никто не отменял) - пусть стоит хоть 300 евро, я куплю.
Вот смотри, например вот так реализовали MSX:
http://www.bazix.nl/onechipmsx.html
Судя по информации - их размели еще на уровне предварительного заказа.
А если сделать что-то тоже красивое и аккуратное со спеком, да еще, если он будет перекрашивать игры просто на лету - бомба будет, причем не только для русского рынка. Главное стараться реализовать максимально просто и делать упор именно на то что это игровой комп - кто захочет к нему подключить полноценную клаву, бетадиск, контроллер винта и тп - для них просто шина в попе девайса и все.
andrews, а Ваша идея тоже хороша, но в ней нет изюминки, кроме как очередная реализация того, что все давно сделали на рассыпухе, а не красиво в 2х чипах.
Может стоит таки объединить усилия с Raydac опять и работать над одним проектом? Не знаю, возможно ли это по Вашим тактическим соображениям, тут не буду лезть глубоко, просто мысль вслух.
Здоровая конкуренция на пользу прогресса. Относительно дисковых устройств...лучше иметь отображаемые диски. Просто цепляешься к ноутбуку или писи и заливаешь на виртуальные диски что надо. При достаточном объеме статической памяти и хорошей батарейке не надо и париться с контроллерами sd, а usb-device в сети корка есть. Да, лишняя софтина для писюка, придется слегка поступиться принципами...дабы купили не 10 человек за 300 евро, а 300 человек за 120, но тут уж не мне об этом говорить, Игорь -бизнесмен, а эту загогулину(цена-спрос) каждый студень на первых курсах чертит. Все улучшения наступают не с первой версии.
Конкуренция это хорошо в любом случае, главное чтобы результат был хоть у кого-то.
Нет, вариант с виртуальными дисками однозначно неприемлем и не пойдет, разве что сделать универсально - и с флешкой и с возможностью заливки на виртуальный диск. Поясню даже почему:
Ко мне пришло несколько друзей детства кто помнит спек, я достал сей девайс, подключил его к плазме что висит на кухне и мы сели побалдеть под пиво. В варианте с флешкой - я просто принес девайс на кухню, включил и все. В варианте с виртуальными дисками - будет менее удобно, у меня конечно компами вся квартира забита, но на кухне нет компа, а сидеть там с ноутом неинтересно - я тогда на ноуте эмуль амиги лучше запущу друзьям.
Это как раз и есть рассуждение о маркетинге, это должно быть реализовано максимально удобно, а не так как решил разработчик сам для себя :)
Думаю, что при попытках коммерциализации проетка, возникнет очень много вопросов с правообладателями адаптированных игр и владельцами стандартной спековской ОС.
А кстати не факт, тут стоит немного проконсультироваться с юристом хорошим, если таки наступит момент коммерциализации, ведь можно трактовать по разному, тут вообще интересный момент - это и не ремейк, это и не нарушение копирайта, это примерно на уровне подключения к спеку черно-белого или цветного телека - визуал только меняется ;)
и с флешкой и с возможностью заливки на виртуальный диск. Поясню даже почему:
Ко мне пришло несколько друзей детства кто помнит спек, я достал сей девайс, подключил его к плазме что висит на кухне и мы сели побалдеть под пиво. В варианте с флешкой - я просто принес девайс на кухню, включил и все. В варианте с виртуальными дисками - будет менее удобно, у меня конечно компами вся квартира забита, но на кухне нет компа, а сидеть там с ноутом неинтересно - я тогда на ноуте эмуль амиги лучше запущу друзьям.
8Гб флэшь -сейчас эксклюзив, стоит больше 150 евро,
120 Гб диск в ноуте стоит что-то около того же.
А размер современного ноута обратно пропорционален толщине кошелька.
Вопрос: как долго надо сидеть с друзьями на кухне, чтобы прокрутить им на 8Гб спековских демок?
И есть ли их столько в природе?
Надо словом считать. Взять 4-12 часов времени просмотра и посмотреть в какую память это влазит.
Да и о времени выборки списка файлов не будем забывать. В 8Гб влазит более 8000000 10кб файлов, дать с этим парится z80 или послать запрос через usb на писи, в данной задаче являющейся сервером несоизмеримо большей производительности? Есть такая критическая емкость носителей для z80 при которой подобные операции не вызовут ничего кроме тихого помешательства. А помнить где-что лежит ( не забудем что диски даже удаленные и виртуальные опять-таки trdos-овские)...я лично очень активно пользуюсь на компе операцией поиском по ключам.
120 Гб диск в ноуте стоит что-то около того же.
110$
Да и о времени выборки списка файлов не будем забывать. В 8Гб влазит более 8000000 10кб файлов...............
У меня 512 мб флешь.
забит на 80 процентов.
и то найти что нужно,пипец,праутически невозможно...
пришлось применить древний как мир способ - каталагизировать все,и сделать файло екселевое на КПК. Только так стало возможно чтото найти.
На мой взгляд ГИГАБАЙТЫ спеку никчему....
Нет, тут скорее нарваться на сопутствующие авторским права можно, в частности "права на переработку"..
Согласен, надо консультироваться с юристами, что скажут :)
8Гб флэшь -сейчас эксклюзив, стоит больше 150 евро,
120 Гб диск в ноуте стоит что-то около того же.
А размер современного ноута обратно пропорционален толщине кошелька.
Вопрос: как долго надо сидеть с друзьями на кухне, чтобы прокрутить им на 8Гб спековских демок?
И есть ли их столько в природе?
Надо словом считать. Взять 4-12 часов времени просмотра и посмотреть в какую память это влазит.
Тоже согласен, но винт не интересен в принципе, ни мне, ни подавляющему большинству других потенциальных пользователей, хотя есть и перекос в цене - винт я пьяный уроню на той же кухне и хана, флешка же выдерживает довольно много G (доказано), 2 гиговый Mini-SD стоит менее $40, его с головой хватит чтобы мы на моей кухне ушли в коматоз с друзьями ;) Плюс вопрос мобильности и размера. Но я еще раз повторюсь - пусть будет шина сзади - кому нужно - включат туда контроллер винта (а кстати, вот его на ПЛИС реализовать тоже бы, а? Размером со спичечный коробок платку) и получит кайф.
Я за то - чтобы контроллер флеш был на плате (это более универсально), а контроллер винта как опция.
То есть при создании подобной платофрмы стоит оттолкнуться именно от миниатюризации, я не просто так привел линк про One-Chip-MSX, это довольно интересный маркетинговый и инженерный пример проекта.
Время выборки флешки некритично, оно будет выше времени доступа к диску в Beta-Disk. Можно конечно упомянуть еще и количество циклов перезаписи на флешку.. Но я думаю их будет достаточно, либо она стоит довольно малых денег, чтобы купить новую.
Давайте продолжим дальше - из этого можно сделать относительно портативную консоль - типа PSP. При этом энергопотребление винта будет в разы отличаться от флешки.
<OFFTOP>
Памяти сколько не дай...сами знаете. Речь шла лишь о возможности поиска в массиве процессорами Pentium IV и Z80. А упорядочивать данные лучше всего спустя какое-то время-все самое ценное разложить по папочкам, остальное или в куче заархивировать и убрать с глаз долой, или сразу в корзину. В идеале, надо что-то поменять в файловых системах, чтобы кроме даты сооздания,имен и расширений,которые для большинства людей неинформативны при огромном количестве было еще нечто как у html-файлов в поле "Keywords", при первом сохранении система могла бы группирвать файлы не только по директриям, но и скрыто от пользователя по контенту- тогда бы поиск сократился по времени. Но для этого нужна большая избыточность объема дисковой памяти. А как быть с нетекстовыми файлами? Не давать сохранять, пока создатель не заполнит короткий формуляр. А ту музыка и графика если надо искать - полный...
Я за то - чтобы контроллер флеш был на плате (это более универсально), а контроллер винта как опция.
вы не поняли..."виртуальные диски" это просто ССЫЛКИ. При попытке к нему обратится, возникает надпись "включи меня через USB к серому новому ноуту"...комментарий создает конкретный владелец при создании "диска" ...на самом компе при достаточно большой статической памяти с батарейками можно иметь несколько "электронных дисков".
вы не поняли..."виртуальные диски" это просто ССЫЛКИ. При попытке к нему обратится, возникает надпись "включи меня через USB к серому новому ноуту"...комментарий создает конкретный владелец при создании "диска" ...на самом компе при достаточно большой статической памяти с батарейками можно иметь несколько "электронных дисков".
Я примерно понял, сенкс что пояснили. Но это удобно не во всех случаях, я же как раз и пояснил - что при варианте сидения на кухне (а более 60% именно так будут юзать потенциальный новый комп, на кухне, с друзьями по спекки-детству), ноут тащить с собой еще будет неудобно. Безусловно это хороший варинт - но как вариант расширения, ну пусть таки будет все это реализовано на плате сразу (не сильно удорожит ведь конструкцию). Но флешка - основное. Флешка становится стандартом де-факто сейчас, просто очень много плюсов - надежность, потребление, форм-фактор и тп.
Lethargeek
15.01.2007, 21:49
Пожалуй беда не в том, что кто-то постоянно делает новый спектрум ,беда в том, что кто-то вообще ничего не делает
Беда в том, ЧТО делают. Почему-то (а почему?) наши доблестные железячники имеют тенденцию ничтоже сумняшеся делать именно то, чего им не хватало 10-15 лет тому назад, и что тогда считалось крутым.
Поэтому железо должно быть избыточно мощным с перепрограммируемыми режимами, чтобы собрав один комп, получать из него на свое усмотрение любой клон. Только не надо матерится, называя это эмулятором. Это не эмулятор! Просто отдельные железные компоненты поддерживают кучу режимов и настраиваются на нужный.
Вот токо следующий новоспекостроитель пошлет все эти "избыточные мощности" подальше (они все равно будут не особо поддержаны) и будет ваять свой "новый клон", с другими встроенными "избыточными мощностями".
История учит, что она никого ничему не учит. :D
Просто некоторым людям спать спокойно не даёт "идеология" о эмуляции и монстростроении. Если им нравится считать это монстром, эмулятором и вообще бредовой идеей - их право, а кого такие тараканы не беспокоят, пусть разрабатывают и юзают в удовольствие, не сходя с ума по "идеологиям". Главное, не надо превращать это в религию, высказал мнение - молодец, а навязывать в каждой ветке не надо.
Зато другие точно спят спокойно, аки младенцы, не ведая никаких сомнений:
Что бы к имеющемуся спеку приделать видяху, надо будет напаять кучу соплей, нарезать кучу дорожек и т.д. как обычно, просто слотом расширения не отделаешься. А если все эти сопли развести на новой матери, так, что бы их не было, то это и будет новый спек.
Это мягко говоря не так Более того, иначе чем через системный разъём вообще быть не должно.
Вот и я о том же... Нафиг думать, если можно сразу броситься в бой с паяльником наперевес. :) А кто паяльником не размахивает на каждом шагу, тот по определению ничего знать не может, это ж известно всем новоспекостроителям. :D
Просто из всего того что выдвигается на звание "нового русского спектрума" эта платформа наиболее подходит под определения выдвинутые мною в одной из веток форума про то, что может называться "спеком"
Вся моя критика сводится вот к чему: ну зачем сейчас лепить четыре Z80, кучку мелкой логики, и ВК (все равно на ПЛИС), если можно в одну ПЛИСину впихнуть пресловутый "Z80 с 32-битными (запараллеленными по 8 бит) регистрами" вместе с ВК и логикой. И дешевле, и технологичней, и результат в плане раскраски софта тот же самый. Была хоть попытка оценить целесообразность многопоточной архитектуры с независимыми процами? Имхо никто эти навороты софтом не станет поддерживать - как я погляжу, народу тут нравится исключительно перспектива раскраски игрушек.
В одновременную работу процессоров с памятью (если она медленная) можно вводить сигналы WAIT, так что все девайсы могут работать хоть с одной микросхемой (и видеоконтроллер так же).
Тады прощай "раскраска"...
Уж больно мне охота посмотреть на старые шедевры в нормальной раскраске
Ну если только посмотреть - EmuZWin (плюс TV-out для полноты очучений).
Думаю, что при попытках коммерциализации проетка, возникнет очень много вопросов с правообладателями адаптированных игр и владельцами стандартной спековской ОС.
А какие проблемы? Ну мало ли что там может девайс... Образ ROM (как и гамы) тоже можно с флешки грузить - она типо в комплект не входит по умолчанию. :)
Кстати, на с. 14 хороший рисунок, от тебя, Летаргик, я подобного уже добиваюсь не знаю сколько.
Если б я еще мог посмотреть, чего тебе надо.
Я этот pdf два раза скачивал - не открывает сцуко, который акробат ему нужен?
Lethargeek, я даже не буду комментировать, ибо я написал своё мнение, а Вы своё. Насчет .pdf поржал - перед тем как писать тут - я изучил доку ;)
Насчет спека - да умер он, умер давно, равно как и коммодор и ямаха и амига и многие другие платформы, осталось только то, что гениально коммерчески было продвинуто.
Да, меня интересует только возможность посмотреть на старый софт в цвете, по поводу остального я не испытываю иллюзий, я отлично знаю, что такое спек (с 1991 года общался с ним), что такое Скорпион и что такое все его навороты (общался даже с Зоновым неоднократно), что такое расширенные графические режимы на АТМ и Профи и отлично понимаю, что нет смысла сейчас много говорить о создании концептуально новой платформы - вся прелесть Спека именно в том, что был создано под него (от души) в те года, к чем сам лично тоже чуть прилагал руку (кто знает - тот знает о чём я). И пытаться сейчас долго и мудро рассуждать о том что надо бы супер-новое все и тп - не надо притягивать это к спеку - спек есть спек, и им останется ровно в том виде, к которому все привыкли.
Обсуждаемый здесь проект интересен ТОЛЬКО раскраской, и возможным рождением новой полуплатформы на базе этой идеи, а идея все же довольно гениальная. Как Вы видите - я не особо многословен был на этом форуме, но тут, даже писать начал :)
Все мои рассуждения - моё видение, и если этого (к сожалению) никогда не будет - ну что поделать.. Скорпион у меня лежит вон, собрать тока надо платы в целое :)
PS Lethargeek, я только про emuzwin не понял - он умеет что-то раскрашивать, или воспроизводить оригинальный Спек? Если оригинальный - так с этим нет проблем, есть и оригинальный спек, не только эмуляторами я пользуюсь. Я искренне надеюсь что Вы читаете, перед тем, как что либо пишете ;)
Lethargeek
15.01.2007, 23:59
Супер.. Вы уже которую страницу рассуждаете, даже не прочитав доки
Сам принцип-то здесь описан, вопросы к целесообразности, а дока - уже детали реализации... Какие я там откровения обнаружу?
я только про emuzwin не понял - он умеет что-то раскрашивать, или воспроизводить оригинальный Спек? Если оригинальный - так с этим нет проблем, есть и оригинальный спек, не только эмуляторами я пользуюсь.
"...перед тем как писать тут - я изучил доку" :)
- читаем доку на EmuZWin (256 colours mode)... А еще лучше просто запускаем и смотрим ;)
"...перед тем как писать тут - я изучил доку" :)
- читаем доку на EmuZWin (256 colours mode)... А еще лучше просто запускаем и смотрим ;)
Доку по сабжу топика ессно ;)
А насчет EmuZWin - хм, тоже интересно, почитаю обязательно, спасибо :v2_cheer:
с самого начала очень противоречивый проект затевается. вот только почему к нему такой не большой интерес? обсуждает в лучшем случае десяток человек, причем я не заметил ни одного интересующегося, активного сегодня кодера...
мне в принципе такая идея не нравится, ведь уже есть (в железе и эмуляторе) не плохая реализация режима 16 цветов на точку, притом на одном штатном проце, а тут огород городить предлагают.
мне кажется, что нас рассудит только эмулятор. если тем, кому эта идея нравится, займутся грамотной переделкой старых игрушек (чего ради как я понял все и затевается - переделанная игрушка по объему будет стремиться к исходной, а не превышать ее объем в разы - как происходит с процами:)) и их количество в короткие сроки превысит несколько десятков, вот тогда быть может и стоит говорить о смысле реализации всего этого в железе.
demon_zx
16.01.2007, 08:53
Читал вот, читал... И пришел к мнению что гонево все это. Дальше эмулятора дело не уйдет, я сомневаюсь что будет даже создан прототип. Летаргик прав, очередной монстр, который нафиг никому не нужен.
Сейчас не только Спектрум реанимируют. Тот же Comodore выпущенный на одном чипе в джойстике просто смели с прилавков, разбирали и на основе его делали полноценный комп. Дело в том, что идти дальше вперед с современными компами стоит недешево, мы не USA и не Европа(я о России, не говоря об Украине и Молдове). Для стран третьего мира, к каковым я отношу Россию по финансовому положению 80% населения, весьма актуальным является (внимание: не мертвая, а развивающаяся платформа) альтернативная мэйнстриму. Компьютерный андеграунд проживет еще лет 20, а то и 100. Вы что же думаете? Впереди вас ждут райские кущи? Мне надоело биться с вами в 98-ом, когда тоже каркали "мертв,мертв,мертв"...прошло 9 лет и вы благополучно сидите здесь целыми днями. Разве только для того, чтобы повздыхать о прошлом? Я старше большинства из вас, и вынужден призывать к прекращению пессимизма...вот театр абсурда!
Что такое андеграунд надо кому-то объяснять?
Я ищу чипы для своего проекта, не знаю как Игорь, то есть не только по характеристикам, но и цены на www.efind.ru и поставщиков желательно из Питера...но не проблема найти их и в Китае. Когда мне нужно было встретить чип на московском вокзале транзитом из Китая, я ночь не спал, потому как живу не в центральном районе и это в моем возрасте...а вы полные сил, цветущие молодые люди...эх выиииииии!!!
Супер.. Вы уже которую страницу рассуждаете, даже не прочитав доки :v2_lol:
у меня Acrobat Reader 6 открывает
Справделивости ради, в этой доке не описана концепция. Зато целая страница под копирайт отведена :) Летаргик прав хотя бы в том, что ставить 4 процессора, кучу логики - это как бы 19 век, хотя бы по потреблению. Я не упрекаю и ничего личного.
2Летаргик: могу pdf заслать на мыло.
Lethargeek
16.01.2007, 11:46
чего ради как я понял все и затевается - переделанная игрушка по объему будет стремиться к исходной, а не превышать ее объем в разы
Как раз и будет превышать, правда не в 4 раза, но в 2-3 точно - графика-то непакованная (или пакованная независимо по битпланам)... Как я уже писал - чтобы переделанная игра занимала не больше оригинала, нужен EGA-подобный (не АТМ!) битплановый режим - тогда переделки в основном сведутся к вписыванию в процедуры вывода спрайтов (или фоновых блоков) однократной команды выбора цвета данного битмапа и возможно упрощению текста сих процедур (это конечно не значит, что при желании графику нельзя сделать жирнее/сложнее).
Сейчас не только Спектрум реанимируют. Тот же Comodore выпущенный на одном чипе в джойстике просто смели с прилавков, разбирали и на основе его делали полноценный комп.
В том комоде емнип ничего принципиально не улучшили (точно не больше, чем уже имеем на Спеке), одна только миниатюризация на новой элементной базе. "Полноценный комп" (полученный из сего девайса подрубанием клавы и дисковерта) называется "Комодурь-64 обыкновенный". Все затевалось ради ностальгирующих ретрогеймеров.
2Летаргик: могу pdf заслать на мыло.
В смысле переконверченый или как? Ну ладно, давай на всякий случай.
Тут похоже акробат переставить с нуля придется с предварительной чисткой реестра ручками... :mad:
Логику Игорь согласился засунуть в плисину (хотя для него это оборачивается реальными затратами на ее проектирование). 4 процессора у него наверняка не только для раскраски, что мешает работать 4-м пользователям одновременно?
Lethargeek
16.01.2007, 11:51
что мешает работать 4-м пользователям одновременно?
Экран.
Четыре пользователя - это конечно круто, а еще надо ввести график учета машинного (в данном случае - "экранного" времени), и получится почти что советская "машиносчетная станция". :)
copperfeet
16.01.2007, 12:08
Супер.. Вы уже которую страницу рассуждаете, даже не прочитав доки :v2_lol:
у меня Acrobat Reader 6 открывает
Доки прочитать руки не доходят тоже.. Есть неск. вопросов:
1) Каким образом планируется синхронно загружать софт в четыре почти независимых компа и синхронно его стартовать?
2) Что делать с компрессированой графикой? Четыре разных битплана сожмутся по разному, наверняка, при распаковке синхронность работы будет потеряна..
3) Почему так мало цветов - 16? Это несерьёзно на сегодняшний день.
4) опрос портов ввода придётся делать со всех процов одновременно. Не заглючит?
Логику Игорь согласился засунуть в плисину (хотя для него это оборачивается реальными затратами на ее проектирование).
Да вы чё блин!!!! Есть такое понятие "схемный ввод", если не можешь на каком-нибудь HDL, рисуешь схему в квартусе(например) и всё. Какие реальные затраты там? Ведро мелкой логики будет дороже одной маленькой ПЛИС? В его случае хватит объёмной CPLD кстати.
copperfeet
16.01.2007, 13:00
Для этого введен специальный механизм, позволяющий синхронно стартовать все процессора с заданных адресов, впрочем можно стартовать с заданного адреса и выбранный процессор
.
А расскажи поподробнее.. Если остальное я себе представить могу, то этот механизм - нет. :frown:
в плене раскраски игр жалко все же, что в режиме 16 цветов на точку атрибуты не учитываются. во многих игрушках (диззи например) один и тот же спрайт повторяется в разных местах разным цветом
Что же тут поделать... но может в таких играх устроит режим 512 на 384 точки с атрибутами? т.е. игра будет не раскрашена, а будет поднято её графическое разрешение.. незаметно для неё самой... для некоторых игр самое оно.
но ИМХО если б к режиму с 4-мя битовыми планами еще составляющую атрибутов добавить, было б круче. :rolleyes:
Black_Cat
19.01.2007, 03:04
но ИМХО если б к режиму с 4-мя битовыми планами еще составляющую атрибутов добавить, было б круче.прикрутить то можно, было бы желание :), правда расчёт атрибутов придётся в играх менять. Например это сделать так, что бы каждые 4 бита в 4х байтах атрибутов отвечали за 16 палитр для каждого пиксела строки знакоместа, тогда будем иметь 16 вариантов раскраски одного и того же спрайта в его конкретной строке конкретного знакоместа, а в целом по всему спрайту таких вариантов будет дикое количество. А палитры прописывать в 16 регистрах по каким-то адресам xxFF.. ..и получим некое 4х процессорное подобие SamCoupe :) (может даже стоит его адреса регистров взять да ещё и его игры сломать и присвоить :) шутка :)).
Lethargeek
19.01.2007, 06:08
но ИМХО если б к режиму с 4-мя битовыми планами еще составляющую атрибутов добавить, было б круче.
Блин, я сто лет назад предлагал что-то похожее с атрибутами по своей теме... Конкретно для ZX-Poly - лучше всего сделать просто знакоместные четвертушки, работающие одинаково и в режиме 256x192x4, и в режиме 512x384x1; только в 256x192x4 атрибуты действуют на два цвета из 16 (например 0 для PAPER и 15 для INK), а в 512x384 и так всего два цвета. Ну и соотв-но, если все четвертушки одинаковы, получается полная совместимость по атрибутам со стандартным экраном. И в игрушках менять ничего не надо, если неохота. Имхо палитры общей хватит на весь экран.
..и получим некое 4х процессорное подобие SamCoupe
Хе-хе, там раскладка экрана совсем другая, так что не выйдет "подобия".
Black_Cat
19.01.2007, 06:26
так что не выйдет "подобия".да и небыло цели, просто по количеству палитровых регистров похожесть есть.
Вариант Летаргика конечно проще, но и качество картинки в нём упрощённей, т.к. атрибуты присваиваются четверти знакоместа(4х4), а в моём варианте каждому столбцу знакоместа (т.е. 1х8). Естественно, в обоих вариантах можно извратиться и каждую строку менять атрибуты если производительности процессора хватит, хотя в моём варианте переписать 16 регистров на строку быстрее будет чем 64 или 32 атрибута. Хотя конечно можно ещё и аппаратно извратиться с построчной заменой или перетасовкой.
Что же тут поделать... но может в таких играх устроит режим 512 на 384 точки с атрибутами? т.е. игра будет не раскрашена, а будет поднято её графическое разрешение.. незаметно для неё самой...
каким это образом графическое разрешение повысится? ты получишь в итоге скалированого диззи, не больше.
Lethargeek
20.01.2007, 22:06
Естественно, в обоих вариантах можно извратиться и каждую строку менять атрибуты если производительности процессора хватит, хотя в моём варианте переписать 16 регистров на строку быстрее будет чем 64 или 32 атрибута. Хотя конечно можно ещё и аппаратно извратиться с построчной заменой или перетасовкой.
Ну кто этим будет заниматься? В переделке игрушек подобные извращения просто так не применишь (в смысле, без перелопачивания кода), а еще ведь растровые прерывания нужны. А для нового софта уж лучше нормальная видеокарта, не требующая обязательных извращений для получения нормальной картинки.
в то время как для режима 256x192x16 требуется "зажигать" или "гасить" точку в графическом блоке для получения заданного цвета, в 512x384 точки выводятся шахматкой, т.е. откорректировав графику с расчетом шахматки и 2-х кратного увеличения и разместив полученное в графических блоках программы, мы получаем игру, идущую в 512 на 384 с атрибутами, при этом для неё физически это всё тот же 256 на 192 с атрибутами, но все персонажи на экране имеют удвоенное разрешение..
Опять-таки, оно надо? Существующим игрушкам как-то хватает стандартного разрешения... разве что растягивать растр без бордюра на большом мониторе... но тогда уже 256x192x4 будет отвратно выглядеть (а в 512x384 остается клэшинг). Проволочная графика типа Elite будет конечно выглядеть симпатичнее, но там надо в код лезть однозначно. А для текста в принципе достаточно увеличенное разрешение только по горизонтали, так что можно еще подумать насчет четырехцветного режима 512x192x2.
кстати играя шахматным расположением закрашенных точек и атрибутами, можно смешивать цвета в блоке, как в свое время было на БК0010, где удавалось до 40 цветов получать из 4-х базовых
И куда тогда денется высокое разрешение? А атрибуты - тоже "расслоенные" получается?
Какой-то извращенный вариант gigascreen, не лучше ли просто юзать палитру в 256x192 режиме...
Похоже для автора "высший пилотаж программирования" (читай извращения) - действительно самоцель. Впрочем, это ж национальная черта - самим создавать себе трудности, чтобы потом их героически преодолевать. :) Одна фраза о концепции Спека как "неудобной платформы" чего стоит...
Black_Cat
21.01.2007, 03:26
Впрочем, это ж национальная черта - самим создавать себе трудности, чтобы потом их героически преодолевать.Ну пока только рассматривается академическая возможность создания трудностей, и в этом рассмотрении есть определённая польза. Дык что не стоит сразу отбрасывать вариант с 4х процессорностью, а наоборот стоит обсудить его возможности, а не зацикливаться на росте частоты камней, т.к. в некоторых вариантах 4 медленных камня бывают полезней/дешевле/производительней одного быстрого, и в таких случаях лучше иметь возможность комбинировать полезные свойства. По крайней мере при таком подходе вероятность зайти в тупик (как например Р4 упёрся в тепловой барьер, а в случае Спектрума такими барьерами могут стать цена/технологическая доступность и т.д.) на порядки ниже, т.к. рост производительности возможен по двум измерениям - частоте и количеству процессоров.
Black_Cat
21.01.2007, 05:19
Попробую немного формализовать постановку задачи в соответствии с критерием поставленным boo_boo - дать возможность использования одного и того же спрайта в разных объектах с разными атрибутами, что вариант Raydac’а 16 color per pixel не предусматривал. В случае реконструируемой игры минимальный 8х8 спрайт может иметь в соответствии с выставленными атрибутами 15 цветовых вариантов. Из этого и будем исходить в анализе вариантов.
Вариант «атрибут на четвертушку».
В предложенном Летаргиком варианте присутствуют 2 режима: с атрибутами, когда r=g=b=i=0 или =1, и без атрибутов, когда rgbi разные. В случае атрибутного режима фактически имеем стандартный спековский режим, но с атрибутом не на знакоместо 8х8, а на 4х4. При этом имеем и все недостатки спековсого режима (клешинг, 15 цветов на четвертушку 4х4).
Вывод: улучшение неудовлетворительное т.к. не соответствует поставленной задаче 16 color per pixel.
Вариант «атрибут на столбец».
В мною предложенном варианте тоже возможно 2 режима – с атрибутами и без. При этом 4 байта атрибутов делятся на половинки и распределяются между всеми пикселями строки знакоместа, так, что каждому столбцу пикселей знакоместа присваивается некий 4 битный атрибут, который может служить идентификатором палитры пикселя, т.е. имеем 16 вариантов палитр. Но т.к. для возможности реконструкции достаточно 15 вариантов, то шестнадцатый может обозначать отсутствие атрибутов или дополнительный вариант. Недостатком моего варианта является необходимость увеличения разрядности цветового сигнала за счёт разрядности атрибута, т.е. фактически в этом варианте имеем 16 color per pixel из палитры 256 цветов, что потребует установки в формирователе видеосигнала 8 разрядного ЦАПа, с другой стороны это даже и плюс :). При этом возможно разрешить всем процессорам управлять своими атрибутами, а атрибутная составляющая будет непосредственно подаваться на ЦАП, но возможен вариант реализации, когда атрибут только адресует один из 16и 4х разрядных регистров палитры, в такой реализации возможно с малыми затратами (записать 8 байт в регистры палитры) менять палитру сразу для всей строки экрана.
Вывод: этот вариант затратнее материально (за счёт введения ЦАПа) и по загрузке процессоров, но поставленную задачу с трудом, но всё же может решить без клешинга если в каждой строке переписывать атрибуты краевых накладывающихся спрайтов. И даже даёт определённые бонусы в виде возможности быстро менять палитру для всей строки переписав 8 байт регистров палитры.
Есть ещё частично документированный Летаргиком вариант реализации видеоконтроллера отдельной платой, но о возможности его использования 4мя процессорами я судить не могу – это вопрос к автору. Также я не могу судить о затратности переделки игр под эти три варианта – прошу оценить это Летаргика и других игроделов. Интересно было бы узнать мнения по этому поводу.
Lethargeek
21.01.2007, 06:39
Вариант «атрибут на четвертушку».
В предложенном Летаргиком варианте присутствуют 2 режима: с атрибутами, когда r=g=b=i=0 или =1, и без атрибутов, когда rgbi разные. В случае атрибутного режима фактически имеем стандартный спековский режим, но с атрибутом не на знакоместо 8х8, а на 4х4. При этом имеем и все недостатки спековсого режима (клешинг, 15 цветов на четвертушку 4х4).
Вывод: улучшение неудовлетворительное т.к. не соответствует поставленной задаче 16 color per pixel.
Пурга! :mad: Я ж ясно написал, что только два цвета зависят от атрибута, остальные 14 - берутся напрямую из палитры, куда они денутся? Ты фтыкни, что на каждые восемь точек стандартная юла читает два байта (один из которых - атрибут), а в четырехпроцессорном варианте - те же два байта, но четыре раза, то есть четыре бита на пиксел, да еще четыре атрибута (из которых в варианте с четвертушками в одной строке используются только два).
Вывод: перед тем, как постить такие "выводы", надо "много думать" - (c)
Есть ещё частично документированный Летаргиком вариант реализации видеоконтроллера отдельной платой, но о возможности его использования 4мя процессорами я судить не могу – это вопрос к автору.
Упомянутая документация устарела. А здесь я писал только относительно сабжа - ZX-Poly.
Любой вариант (не только именно мой) "отдельной платой" по определению можно юзать где угодно (была бы шина выведена). Причем он окажется значительно производительнее для графики, чем четыре зетника.
Также я не могу судить о затратности переделки игр под эти три варианта – прошу оценить это Летаргика и других игроделов. Интересно было бы узнать мнения по этому поводу.
Это надо отдельную тему (и видимо все-таки в "Программирование").
Black_Cat
21.01.2007, 07:33
то есть четыре бита на пиксел, да еще четыре атрибутаЯ так понял что у тебя имеются 2 режима - с атрибутами и без (значит ошибся). Если обычные (хоть и учетверённые) атрибуты есть всегда - значит есть и клешинг -> тогда этот режим хуже чем я думал :( - пардон, переоценил :).
Lethargeek
21.01.2007, 08:03
Если обычные (хоть и учетверённые) атрибуты есть всегда - значит есть и клешинг -> тогда этот режим хуже чем я думал
Гы, и чем же он хуже? Если все атрибуты одинаковые сделать на всем экране (с INK/PAPER, несовпадающими с другими цветами палитры), то ваще получится обычный 16-цветный режим. :D
Чтоб не было клэшинга (кстати правильно называться будет уже color spill, как в MSX) - используй эти два атрибутных цвета только для фона, и будет тебе щастье. Да и незаметно с атрибутами 4x4 получится...
Еще вариант - переключать несколько (зависит от разрядности ЦАП) цветов в палитре на одно полное (8x8) знакоместо. Но тут уже надо ВК наворачивать - в отличие от "четвертованного" :) варианта, где те же самые атрибуты корректно работают в обоих разрешениях.
Black_Cat
21.01.2007, 08:10
и чем же он хуже?тем, что не решает поставленную задачу :)
Еще вариант - переключать несколько (зависит от разрядности ЦАП) цветов в палитре на одно полное (8x8) знакоместо.поподробнее, не въехал
Lethargeek
21.01.2007, 08:20
тем, что не решает поставленную задачу
Зато задачу совместимости решает - с атрибутами все как на Спеке. К тому же (повторяю), спилл 4x4 малозаметен! А то что ты описал - это практическое решение по твоему? :v2_laugh: Хотя возможно Raydac-у пондравится именно в силу сложности и геморройности. :v2_lol:
Описанная тобою задача издавна решается аппаратными спрайтами. :D
Или нормальным APA-режимом с большой глубиной цвета (блиттер рулит!).
Правда, к четырехпроцессорным извращениям оно уже отношения не имеет...
Lethargeek
21.01.2007, 08:25
поподробнее, не въехал
Ну не 2 из 16 в квадрате 4x4, а скажем 4 из 16 в квадрате 8x8 (с общей палитрой 256 цветов) или там же 5 из 16 (палитра 64 цвета, два остальных атрибутных бита как-нить еще заюзать)...
Black_Cat
21.01.2007, 08:25
Описанная тобою задача издавна решается аппаратными спрайтами.
Или нормальным APA-режимом с большой глубиной цветает понятно, но по условиям задачи не проходит :), не адреналинь, задача пока академическая :)
Ну не 2 из 16 в квадрате 4x4, а скажем 4 из 16 в квадрате 8x8 (с общей палитрой 256 цветов) или там же 5 из 16 (палитра 64 цвета, два остальных атрибутных бита как-нить еще заюзать)...ясно, если всего раскрасок спрайтов четыре-пять, то может и прокатит, а если больше - то не катит :(. Как очень частное решение - пойдёт, но не пойдёт как общее :).
Lethargeek
21.01.2007, 08:29
ет понятно, но по условиям задачи не проходит
Ты не забывай, что "по условию задачи" 16-цветный режим должен быть "по совместительству" и стандартным (при совпадении данных во всех четырех плоскостях)!
ясно, если всего раскрасок спрайтов четыре-пять, то может и прокатит, а если больше - то не катит
Для переделки игрушек прокатит - спрайты вполне можно будет различить по одному "сигнальному" цвету, тем более если по нескольким.
Как очень частное решение - пойдёт, но не пойдёт как общее
ZX-Poly в принципе не тянет на "общее решение".
Black_Cat
21.01.2007, 08:34
должен быть "по совместительству" и стандартнымправильнее "может быть по совместительству и стандартным"
Лучше скажи что-нить на предмет помены атрибутов построчно по краям накладывающихся спрайтов (у меня во втором "выводе" описано).
Lethargeek
21.01.2007, 08:43
правильнее "может быть по совместительству и стандартным"
Должен, иначе игрушки надо будет переделывать слишком тщательно "от и до".
Лучше скажи что-нить на предмет помены атрибутов построчно по краям накладывающихся спрайтов (у меня во втором "выводе" описано)
Уже сказал - геморрой. (нет, не так...) ГЕМОРРОИЩЕ! :v2_devil:
Причем даже с нормальной системой растровых прерываний.
Black_Cat
21.01.2007, 08:51
ГЕМОРРОИЩЕ!а с повышением тактовой процессора раз в 6-8 ему не полегчает? А если аппаратно извратиться и сделать каждому процессору буфер на 32х2 байта, шоб он туды мог писать не только во время обратного хода? В первые 32 пишет не напрягаясь, а вторые 32 выгружаются во время обратного хода. И прерывания нам по барабану будут.
Lethargeek
21.01.2007, 09:10
а с повышением тактовой процессора раз в 6-8 ему не полегчает? А если аппаратно извратиться и сделать каждому процессору буфер на 32х2 байта, шоб он туды мог писать не только во время обратного хода? В первые 32 пишет не напрягаясь, а вторые 32 выгружаются во время обратного хода.
А щитать фсе енто будет нещастный кодер? И чем больше спрайтов, тем ближе по затратам одной только памяти оно будет приближаться к 256-цветному режиму, не говоря уж о скорости... Впрочем, Raydac хочет ленивых кодеров заставить "высшим пилотажем" заниматься, так что ему и карты в руки. :D
Black_Cat
21.01.2007, 09:15
А щитать фсе енто будет нещастный кодер?ага, вместе с процессором :), но ты как чуешь оно хоть вытянет обсчёт игры и при какой тактоваой? Напоминаю: дискуссия- академическая, пока воевать не надо :).
AlexCrush
21.01.2007, 12:19
У меня тут возникла пара вопросиков по режиму CPU IO - когда какой-либо CPU назначен обработчким IO для CPU0.
1). В доке сказано: если CPU0 выполняет запись в порт,то генерируется NMI для процессора-обработчика. Вопрос: предусмотрен ли механизм "торможения" CPU0 до окончания обработки этого NMI? Если да - то какой? Если нет, то что станет с CPU-обработчиком если CPU0 станет выполнять цепочкой команды OUT, например, OUT (254),A (на бордюре ему порисовать вздумалось)?. Ведь тогда первый обработчик будет прерван вторым NMI, затем второй - третьим, и т.д. В итоге стек заездит всю доступную память :-)
2). Я так понял, "перехватываются" все порты (ну кроме #7FFD и #3D00). То есть, если я хочу сэмулировать CMOS-часики, то мне придется еще эмулировать клавиатурный порт #FE на чтение. Т.е. CPU-обработчик вынужден хотябы раз в кадр делать IN из всех портов клавы (а их 256, хотя можно считать 8, остальные высчитать - но это тоже не так просто) и расписывать их в память по адресам #XXFE (или нет?).
Вобщем, хотелось бы иметь возможность задавать - какие порты эмулируются, а какие - нет, при этом различать порты "на запись" и на "чтение". Я, правда, себе это слабо представляю, но всё же...
acidrain
21.01.2007, 13:27
нашел несколько злостных (!) опечатокАга и есть постоянно преследующая тебя опечатка - kBt вместо kB...
И вообще эта и тема про желтый спек - мне кажется междуусобной войной, кто круче придумает. Имхо этот и желтый спеки - беспонтовое занятие.
Имхо этот и желтый спеки - беспонтовое занятие.
никакой междуусобной войны мы не ведем, наши пути разошлись бесповоротно и окончательно в 1999 году. Игоря знаю с 1997 года, с тех пор он в жизни добился гораздо больше чем многие другие. Он мало обещает, но что обещано делает. Так что все неконструктивные наезды здесь на него это бесперспективное занятие. Он же вам всем сказал: у кого есть собственные проекты - РЕАЛИЗУЙТЕ их. Сравнивать нереализованные идеи хотя и развивающее интеллект занятие, но оно оправдано лишь в том случае, если сам собираешься делать нечто подобное. Охотник ни разу не паливший из ружья-это выдумщик, хорошо если литератор или душа компании, а то просто балобол.
acidrain
21.01.2007, 15:40
не надо и париться с контроллерами sdКонтроллер SD/MMC само по себе простейшее устройство, вот кто программно поддержит это на спеке?
acidrain
21.01.2007, 17:38
что эта иде (ZX-Poly) еще конца прошлого века..
Честно признаюсь, меня приятно удивило появления эмулятора.
Но думаю многие тут правы - эта идея лишь хороша той частью, что игры расскрасить можно. Но ведь советуют упростить схему.
Но чувство соперничества остается наглядным имхо =)
ЗЫ. Если я правильно понял: игра after the war1 ведь раскрашена? А можно ее выложить, чтоб в эмуле погонять?
Как загрузить tap-файл в ZX-Poly? Или это просто демонстрация графических режимов?
AlexCrush
21.01.2007, 19:14
Бит 4 ZXPoly R1 (стр 9) отключает поступления NMI на выбранный процессор
"Бит 4 – установленным блокирует аппаратно приход на процессор модуля сигнал NMI. Установка данного бита фактически отключает ножку процессора от поступающих сигналов. Данный бит не имеет действия, если был сделан программный RESET и действует система считывания команды из внутренних регистров."
Да, это я видел... Но по поступлении первого NMI-прерывания, процессор-обработчик потратит около 20 тактов (довыполнение команды, CALL #66 :PUSH AF...) прежде чем успеет изменить состояние "бита 4 регистра ZXPoly R1". Так что, на мой взгляд - толку от отключения NMI нету, все равно не успеть...
Пример: эмуляция HDD. Понадобится перехват записи в регистр данных. Запись выполняется весьма быстрыми цепочками OUT-ов. Каким образом сделать так, чтобы ни байтика не потерялось?
Да, идея понятна, но к сожалению введение каких то диапазонов эмулируемых портов неадекватно усложнит платформу :(
Можно ввести отключаемую карту маппинга. Отъест она в памяти 16 Кб (64 К портов, на запись и на чтение = 128к, на каждый по битику). Хотя, безусловно, это тоже усложнит систему. Но без подобной карты (да хоть фиксированной или в быстром флеше) смысла в перенаправлении портов я всё таки я не вижу.
Ведь чтобы проэмулировать даже самую простую перифирию процессор обработчик должен "служить прослойкой между портами и CPU0." для всех осталных портов, а это очень тяжело, а часто и невозможно. Как минимум, все бордюрные эффекты сразу умрут, beeper-овский звук тоже, и т.д.
BTW, каким образом узнать адрес порта в случае возникновения в процессоре-обработчике NMI или INT?
AlexCrush
21.01.2007, 21:19
2) Основной USE CASE для которого делалось это - возможность CPU0 менять/читать содержимое памяти других ПМ без изменения своего адресного пространства, а NMI и INT при чтении были сделаны в расчете на кого то более умного :) т.е. дана потенциальная возможность, а как она будет использоваться это уже надо копать.. добавка карты портов конечно полезно и интересно, но сильно усложняет аппаратную часть имхо..
Очень странный Use case. Если для модификации памяти других ПМ - то это как то странно. Т.е. получается, что таким образом модифицировать чужую память ого-го как сложно. Сначала надо переключиться в этот самых режим, затем поработать с памятью через порты (при этом некоторые адреса (#3d00, #7FFD недоступны), при этом следя чтобы CPU-обработчику не поплохело от большого кол-ва NMI и INT (или отключать ему их (кстати можно ли отключить NMI и INT другому процу я не совсем понял)), затем обратно включать IO на порты. Вроде как бы ничуть не проще, чем поменять свое адресное пространство и работать по-людски.
Другой Use case, который указан в документе, а именно - "эмуляция отсутсвующей периферии" - неюзабелен по приведенным мною ранее причинам. Надо обязательно вводить возможность тормозить CPU0 на время пока проц-обработчик не сделает свои дела, и, но уже не столь обязательно - карту маппинга.
Я, к слову, использовал подобный трюк с подменой портов для контроллера PS/2 клавиатуры на базе второго спека. Были помыслы расширить данную идею до "эмуляции прочей периферии", однако по многим причинам - ничего нормального не выходит. Максимум - эмуляция KB и KemMouse. Увы. Вот если бы второй, эмулирующий, проц был раз в 20 быстрее основного - то тогда да.... Но это как-то глупо :-) - доп проц быстрее основного :p
Вобщем мой вывод - маппинг портов к другому процу - идея интересная, но очень слабо продуманная. Предлагаю для упрощения реализации основной идеи вообще выкинуть эту вещь из архитектуры. Ну не нужна она в таком виде, понимаете? Хотя и выглядит красиво.
Lethargeek
22.01.2007, 01:06
ага, вместе с процессором , но ты как чуешь оно хоть вытянет обсчёт игры и при какой тактоваой? Напоминаю: дискуссия- академическая, пока воевать не надо
Академическую дискуссию - в отдельную тему, и так ветку засрали. ;) Обо всяких "извращениях ради извращений" я "дискутировать" не намерен, ибо пустая трата времени. Ты предлагаешь фактически эмулировать центральным процессором (большую часть времени - всеми четырьмя) функции спрайтового VDP, при отсутствии растровых прерываний такая эмуляция все время отображения растра сожрет (аналогично интерлейсовым смотрелкам моргалок), в случае растровых прерываний будут проблемы, если пикселы разных спрайтов слишком часто меняются (надо обходить программно); и в обоих случаях надо спрайты предварительно отсортировать по каждой пиксельной строке (и возможно подготовить что-то вроде построчных скриптов)... ужос!! Для раскрасок однозначно не подойдет, ибо много кода дополнительного пихать, а для нового софта уж лучше как-нить попроще различать одинаковые по форме объекты, например тем же сигнальным цветом, или печатать спецпроцедурой с преобразованием цветов - дешевле обойдется.
Если мегагерц добавить, полегчает компу, а не кодеру. Аццтойная схема остается таковой при любых скоростях. Хотя - если добавить ну очень много мегагерц, можно будет игрушки лепить сразу на Васике. :D
Летаргик как то так быстро начинает тонуть в "слюне", что не успевает внятно сформулировать свои идеи и позицию..
Летаргик как-то быстро начинает тонуть в общем нежелании обдумывать даже собственные предложения, что уж говорить о чужих. Предполагается, что любой высказанной идеей все должны немедленно восхититься, в крайнем случае - делать мелкие замечания о деталях.
Всем на будущее.. идея должна начинаться с нормального описания..
Идея должна начинаться с нормального обоснования. В доке по ZX-Poly по поводу использования всех прочих (излишних для раскраски игрушек) возможностей - несколько строк в послесловии (благие пожелания к программистам поизвращаться и что-нибудь наваять в четырехпроцессорной схеме). То есть о целесообразности и особенностях практического применения предложенного девайса (помимо "раскраски") сам автор имеет весьма смутные представления?
Предполагается, что любой высказанной идеей все должны немедленно восхититься
щас лопну :v2_lol: :v2_lol: :v2_lol: :v2_lol:
Lethargeek
22.01.2007, 02:11
щас лопну
Лучше не здесь, а в закрытом разделе, перечитав примеры из оного. ;)
P.S. Заодно можешь наконец ответить мне на вопрос, который я задавал тебе уже четыре раза. :v2_tong2:
Но это как-то глупо :-) - доп проц быстрее основного ну почему же глупо? просто ассиметричный кластер
AlexCrush
22.01.2007, 12:56
Нормальный use case так как данный механизм хорошо работает еще в следующих случаях
1) заливка подпрограмм считывание результата при многопоточной работе процессоров
2) работа в расширенных графических режимах без задействования всех процов, т.е. CPU0 может заменить себя и еще один проц (или несколько),записывая графические данные в его память, который в это время обсчитывает что то в фоне..
Всё это в разы удобнее и привычнее делать через память, а не через порты. Очень здорово будет через порты заливать 30-байтную процедуру в память по адресу #7FF0. А во временной смене адресного пространства ничего страшного нет.
Почему Вы боитесь признать что фишка с подменой портов в имеющемся виде бесполезна? Давайте её выкинем! Зачем усложнять железо ненужными вещами? Вот когда будет применение этой вещи + когда идея будет доведена до ума...
"Контроллер SD/MMC само по себе простейшее устройство, вот кто программно поддержит это на спеке?"
Сейчас я делаю поддержку сом через вход-выход
магнитофона (пока только 38400 и ТАР-файлы)
Затем - 1 меговый+ диск, после карты ...
А "ZX-Poly" помрет не родившись ...
ну почему же глупо? просто ассиметричный кластер
Що? Вы, господа, когда тут перестанете генеталиями мерятся?
Що? Вы, господа, когда тут перестанете генеталиями мерятся?
+1 :v2_clapp:
до чегож народ у нас любит офтопить.....
(icebear это не про тебя.... :v2_wink2: )
Lethargeek
23.01.2007, 11:56
В целом я не вижу там куда доводить еще, основная проблема была в синхронизации процессоров, а она добавлена, так что идея на 99.9% законченная.. даже два резервных видеорежима остались.. всё что покамест предлагается выходит за рамки "простоты"
Хм. Предложение унификации атрибутов выходит за рамки простоты?
Кстати о простоте (и гибкости) - так называемые "видеорежимы 0-3" вообще не нужны в явном виде, они прекрасно получаются настройкой режимов 256x192x4 и 512x384x1, нужно (в дополнение к регистрам палитры) всего два байта-описателя пиксельных и атрибутных блоков 2x2 (то есть с какой плоскости брать соотв-й пиксел/атрибут в каждой четверке пикселов/атрибутов). При этом сразу появляются "режимы" 512x192 и 256x384 с прямоугольными точками (не считая остальных извращенных частных случаев), можно моргалки быстрые делать... В режиме 256x192x4 "лишние" цвета убиваются просто настройкой палитры.
Romanich
23.01.2007, 12:15
Що? Вы, господа, когда тут перестанете генеталиями мерятся?
Когда кто-то реально докажет и покажет :)
..своё железо в действии, разумееца...
Lethargeek
24.01.2007, 01:17
В нашем деле, самое страшное - именно выражение "всего то добавить"..
Самое страшное - это не видеть, "куда там доводить еще". Иметь четыре одинаковых псевдостандартных режима - это типа не страшно, а ведь там требуются те же переключатели. Описанные дополнительные настройки - ерунда по сравнению палитрой, тем более вроде как решено для логики юзать ПЛИС, какие проблемы-то? В случае трудностей спецы здесь всегда помогут.
Видать, реализовать более эффективную (а главное - полезную) архитектуру "инженерное мышление" не позволяет? Почему из разряда "невозможно" надо обязательно переводить в разряд "сложно", а не в разряд "просто, удобно и эффективно"?
Black_Cat
24.01.2007, 10:27
дискутировать" не намерен, ибо пустая трата временинет, не правильно, такое обсуждение полезно даже в случае "извращений ради извращений". Метод, при котором рассматриваются даже бредовые идеи используется в ТРИЗ и называется "мозговым штурмом". Это очень полезный метод :), т.к. он позволяет в дальнейшем рассмотрении оперировать на всём поле возможных вариантов, а не зацикливаться на одном направлении, хоть возможно и перспективном с первого взгляда.
в случае растровых прерываний будут проблемы, если пикселы разных спрайтов слишком часто меняютсяну это в обычных переделываемых игрушках врядли есть, а если есть, то помена не частая (т.е. не несколько раз на строку или на кадр).
при отсутствии растровых прерываний такая эмуляция все время отображения растра сожрет (аналогично интерлейсовым смотрелкам моргалок)Я ж не спорю что вариант прожорливый, но тут уже можно подумать об аппаратных возможностях нивелирующих фазовое рассогласование обсчёта и отображения, что-то типа отделения памяти видеопроцессора от общей памяти и синхронизация содержимого во время обратного хода луча.
Ладно, спасибо за участие в обсуждении и подведём итог:
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
24.01.2007, 14:27
нет, не правильно, такое обсуждение полезно даже в случае "извращений ради извращений". Метод, при котором рассматриваются даже бредовые идеи используется в ТРИЗ и называется "мозговым штурмом".
Мозговой штурм производится в соответствующих разделах. А здесь похоже уже все ясно: автор - гений, проект - совершенство, и что-то предлагать/критиковать не только бесполезно, но и кощунственно. Аллилуйя и вечная слава "инженерному мышлению". :v2_biggr:
ну это в обычных переделываемых игрушках врядли есть, а если есть, то помена не частая (т.е. не несколько раз на строку или на кадр).
В любых несколько спрайтов запросто могут сойтись на одном небольшом участке - например вражины толпой накинулись на героя.
2) Можно достичь решения задачи более простыми средствами, но ограничиваясь при этом меньшим количеством цветов на пиксель, чего при определённых условиях может быть достаточно. Для этого достаточно отдать один из битов цвета (например бит плоскости I) в качестве определителя палитры (сигнальный цвет как предлагал Lethargeek). При таком раскладе получаем 8 цветов на пиксель
Ну что за фигня опять, я ж русским языком написал: 16 цветов так и остается, 16! Из них два зависят от (четвертушки) атрибута. Палитра - общая, глубина цвета в ней зависит только от разрядности ЦАП. В том числе и "цвета" в соотв-х атрибутах - это тоже номера регистров палитры, а не цвета напрямую.
Маскировать отдельные плоскости и сокращать количество цветов действительно полезно (тогда при соответствующей настройке палитры получаем полный аналог "стандартных режимов 0-3", или например два 4-цветных режима), нужен только байт безразличия плоскостей для определения атрибутнозависимых цветов, тогда и получится что-то похожее на твое описание. "Группы пикселей" - только 2x2 в режиме высокого разрешения - опять-таки только для "отключения" плоскостей.
А, бесполезно тут разоряться... :v2_sleep:
Black_Cat
25.01.2007, 02:10
16 цветов так и остается, 16! Из них два зависят от (четвертушки) атрибута. Палитра - общая, глубина цвета в ней зависит только от разрядности ЦАП. В том числе и "цвета" в соотв-х атрибутах - это тоже номера регистров палитры, а не цвета напрямую.не, этот вариант меня не устраивал. Палитра на знакоместо - это клешинг, атрибут на четвертушку тоже не намного лучше. Я описывал несколько видоизменённый свой вариант (1х8 или 1х4), в котором битовая плоскость I определяет одну из двух палитр на группу пикселов (как это обычно делается в Спеке). При этом цвета берутся не из соотвующих атрибутов, а из регистров пар палитр на которые эти атрибуты указывают, а бит I указывает на один из пары цветов в соответствующем регистре палитры (при этом нужно 16 8ми разрядных регистров палитры).
только 2x2Меня как раз интересовали соображения на предмет почему группа пикселов такая, а не этакая. Есть тут какие-то предпочтения для кодера и чем они обусловлены?
Lethargeek
25.01.2007, 05:30
не, этот вариант меня не устраивал. Палитра на знакоместо - это клешинг, атрибут на четвертушку тоже не намного лучше.
И что "клэшинг" (правильно - спиллинг) всего двух (а скорее всего только INK) цветов из 16 (то есть 14 - независимы на всем экране) хуже, чем 8 цветов на точку для неполноценных переднего/заднего плана?!
Поскольку тайминги сканера менять нельзя, "палитра на знакоместо" слишком сильно завязывает цветной режим на все четыре плоскости. Особенно в твоем варианте - я так понял, атрибуты там вообще не используются... и ради чего? Если хочешь менять палитру, юзай бит BRIGHT (четвертушки) атрибута , тогда и совместимость не пострадает (при соотв-й настройке палитры). По крайней мере можно иметь несколько окон с разными палитрами. А с точностью до пиксела - слишком "дорого" и неудобно, как ни группируй.
Думаешь, консоли под переделанные игрушки не хватит 16 цветов (из двух палитр) в окне? Это (с поправкой на скорость) практически уровень Atari ST (а то и лучше) - многие эффекты с растровым прерыванием можно как раз атрибутами повторить.
Меня как раз интересовали соображения на предмет почему группа пикселов такая, а не этакая.
Из-за попиксельного расслоения в режиме 512x384x1. :)
Black_Cat
25.01.2007, 07:57
Из-за попиксельного расслоения в режиме 512x384x1.имеется ввиду способ формирования изображения в режиме 5? А думаешь эти два режима (4+ и 5) должны быть как-то связаны? Вроде нет задачи конвертить что-то из 4+ в 5 (а значит нет задачи иметь идеологическую связь по форме атрибутных областей). Есть задача конвертить из стандартного режима в 4+ или 5 и тут могут быть некие предпочтения. Например был такой расширенный режим для Спека как атрибут на байт, дык он фактически является подмножеством режима с пикселями сформированными в группы 8х1 и это уже является определённым обоснованием (если под этот режим ещё и софт есть :)), хоть и не с точки зрения кодера, а с т.з. наличия доп. софта.
я так понял, атрибуты там вообще не используются.Имеешь ввиду атрибуты переделываемого софта? Используются, но не совсем напрямую, т.к. они для всего знакоместа, а у меня знакоместо разбито на группы пикселей имеющих свои отдельные атрибуты (т.е. детализация выше и соответственно вероятность спиллинга ниже, т.к. основная идея в том что-бы по возможности не испортить не имеющий спиллинга 4 режим, в противном случае вообще нет смысла цеплять сюда ещё и атрибуты, уж лучше пускай остаётся вообще без атрибутов но и без спиллинга). Разница между 4 и 5 режимами не в глубине цвета и разрешении, а именно в наличии или отсутствии спиллинга - это критерий.
Для того, что бы небыло путаницы ещё раз опишу схему формирования цвета:
В зависимости от размера группы пикселов четыре байта атрибутов делятся на группы бит адресов регистров палитры (Ар). Для группы из 8 пикселов - атрибут имеет 4 бита (Ар0-3) на каждый пиксел в строке знакоместа, для группы из 4 пикселов соответственно 2 бита (Ар0-1) на каждый пиксел в строке знакоместа. В соответствии с 4х (или 2х) битным адресом регистров палитры Ар выбирается один из 16 (или 4) регистр палитры Rр0-15 (Rр0-3). Из него считывется байт палитры имеющий структуру p0p1p2p3p0'p1'p2'p3'. Выбор полубайта р или р' осуществляется в соответствии со значением бита I. Цвета RGB формируются соответственно как R(G,B)p0p1p2p3 или R(G,B)p0'p1'p2'p3'. Разница в вариантах с группами по 4 или 8 пикселов на атрибут в количестве доступных для адресации регистров палитры на весь экран - соответственно 4 или 16. В результате получаем 8 цветов из палитры 128 на каждую группу пикселов, каждый пиксел своим цветом.
P.S. Это судя по всему окончательное решение задачи о возможности использования одних и тех же спрайтов с разной атрибутной раскраской в режиме 4.
Lethargeek
25.01.2007, 15:43
Вроде нет задачи конвертить что-то из 4+ в 5 (а значит нет задачи иметь идеологическую связь по форме атрибутных областей). Есть задача конвертить из стандартного режима в 4+ или 5 и тут могут быть некие предпочтения.
Мож кому-то захочется сконвертить И в 4+, И в 5? Чем больше у них общих мест, тем меньше работы.
Имеешь ввиду атрибуты переделываемого софта? Используются, но не совсем напрямую, т.к. они для всего знакоместа, а у меня знакоместо разбито на группы пикселей имеющих свои отдельные атрибуты (т.е. детализация выше и соответственно вероятность спиллинга ниже,
Четвертушки - фактически то же самое.
т.к. основная идея в том что-бы по возможности не испортить не имеющий спиллинга 4 режим, в противном случае вообще нет смысла цеплять сюда ещё и атрибуты, уж лучше пускай остаётся вообще без атрибутов но и без спиллинга).
Ну дык делаем во всех атрибутах атрибутные цвета равными палитровым цветам, вот тебе и обычный 16-цветный режим "без атрибутов".
Разница между 4 и 5 режимами не в глубине цвета и разрешении, а именно в наличии или отсутствии спиллинга - это критерий.
Гы, 512x384 vs 256x192 - и разница не в разрешении? Жжош!
И кстати в режиме 5 не спиллинг, а как раз старый добрый клэшинг. ;)
Для того, что бы небыло путаницы ещё раз опишу схему формирования цвета:
Имхо делить пикселы на мелкие группы неудобно. Ну можно например забабахать 4 палитры, и каждые два бита (из 32) атрибутов определяют свою палитру для группы 2x2 пиксела. А толку? Для нормальной анимации придется цвета урезать,
то есть в 4 палитрах будет не 64 разных цвета, а меньше; переделывать игрушки тщательнее придется, стандартный режим отдельно лепить опять же... ну нах! А если атрибуты одинаковые во всех режимах, можно например в игрушках весь текстовый вывод не трогать, раскручивать только графическую часть (и то возможно не полностью). Ресурсов опять же меньше понадобится в пересчете на логику (та же палитра к примеру - лучше даже не две иметь, а зафиксировать атрибутные цвета как прямой код IGRB). Если у разных видеорежимов много "общих мест" при сильном внешнем различии - имхо это хорошо. Для переделок унифицированных атрибутов за глаза хватит, а что кто-нить чего-то сложное и оригинальное кодить будет - большие сомнения. Спектрумисты и так народ ленивый, а тут еще извращаться надо, чтоб картинка не глючила...
Ну да все равно никто ничего делать не будет.
Alex_kapfa
26.02.2008, 17:14
Добрый день. Я пересмотрел все посты этой темы, но нигде не нашел ссылки на эмулятор «ZX-Poly platform»
Пожалуйста, подскажите, откуда можно скачать описываемый здесь эмулятор. Быть может, я был не очень внимателен, и «просмотрел» нужную мне ссылку.
James DiGreze
27.02.2008, 06:54
Raydac, вынеси эти ссылки в первый пост темы, так будет проще искать ;)
а исходники эмулятора открыты? :v2_rolley
balu_dark
02.05.2008, 22:00
а сайт у всех не открывается - или только у меня?
а сайт у всех не открывается - или только у меня?
http://www.igormaznitsa.com/zxpoly/zxpoly.html
этот открывается или ты про что ?
balu_dark
03.05.2008, 13:29
этот не открывается :(
Error404
15.10.2008, 17:04
p.s.
еще раз уточняю на всякий случай что никакого изменения исполняемого кода редактора или его коррекции не производилось, был только фонт отредактирован
Забавно. КМК, возможность работы в высоком разрешении немало стоит и сама по себе (не только в режиме совместимости). Уже можно будет, наконец, делать нормальные редакторы по 80 символов в строке.
Black_Cat
15.10.2008, 17:07
уточняю на всякий случай что никакого изменения исполняемого кода редактора или его коррекции не производилось, был только фонт отредактировант.е. фонт 8х16 получился? А 8х8 и 6х8 будут?
Mad Killer/PG
05.11.2008, 23:37
Raydac, с днём рождения !
Andrey_PROFI
12.11.2008, 16:46
Поддержка Profi-1024 v5 будет ли реализована в данном проекте?
copperfeet
13.11.2008, 13:37
я мягко говоря мало знаком с Profi, но если судить по цифре обозначающей объем памяти в мегабайт, то боюсь, что поддержать его будет нереально, так как суммарная память системы 512 кБт
Ну, памяти-то можно и напаять, она счас копейки стоит..
:v2_wink2:
Black_Cat
17.11.2008, 19:23
Raydac, а ты кстати не думал реализовать всё то-же, но в системе с разделением времени, тогда такую конструкцию реально будет засунуть в FPGA например того-же "Aeon"(т.е. Neo), а то 4 компьютера туды всёж врядли влезет. И будет реальная железная реализация :) Частоты процессора там запредельные - до 70МГц, дык что 70/4=17,5МГц, т.е. ещё и пятикратное ускорение :)
Black_Cat
17.11.2008, 21:07
Ну т.е. продумать систему так, чтоб не 4 проца параллельно работали, а один проц по очереди работал за все четыре (например подменяя по очереди матрицу своих внутренних регистров, внешних портов, ну и память ессно). Т.е. получается что-то типа подобия железно реализованной RTOS обрабатывающей сразу 4 задачи в режиме разделения времени.
Black_Cat
17.11.2008, 21:45
а какой смысл так усложнять
усложнять - эт как раз ставить 4 реальных проца - ни уму ни сердцу. Сложней раз в десять в разработке, во солько-же хуже по надёжности, невозможность сборки без спец оборудования для монтажа BGA корпусов, что сразу требует централизации производства и больших партий, что невозможно в принципе! И при этом цена сабжа возрастает чуть ли не в 30-40 раз! Нахрен нужно такое счастье?
идеологически это было бы более верно имхо, так как аппаратный Z80 внутри это символ спекане вижу здесь никакой идеологии кроме фетишизации.. тебе что важно? ехать, или шашечки?
Black_Cat
17.11.2008, 22:02
Это всё не технологично! Сейчас не то время, чтоб выпускать архаичные конструкции как бы тебе они были не милы. Либо эту штуку можно будет поставить на унифицированную платформу, либо она никогда не будет реализована в железе. Третьего не дано.
Black_Cat
17.11.2008, 22:24
и за это народ даже готов заплатить, так как это как настоящие металические диски и рев на мотоцикле
ты для кого комп делаешь? для вот таких идиотов? : http://hdd-911.com/index.php?option=content&task=view&id=67&Itemid=27
:) для идиотов можно будет выпускать то же самое, но на гетинаксе и запихнутое в фанерный ящик с зелёной ЭЛТ от осцила прикрученной снаружи :)
Stingrey
17.11.2008, 22:28
Наверное, это первый раз, когда я полностью согласен с мнением Raydac'а :v2_wink2:
Alex_kapfa
18.11.2008, 15:23
Выскажу своё любительское мнение :-) Мне тоже ближе, когда «сердце» Спектрума – «железный» Z80, а не «эмулятор».
Black_Cat
18.11.2008, 16:33
К счастью успешность конструкции определяет рентабельность для коммерческого производства, или доступность для любительского повторения. А то, что "..манам" и "..филам" "греет душу" никогда не перешагнёт рубеж штучного производства, если вообще не останется чисто маниловщиной :) . Поэтому эти мнения можно просто не брать в расчёт, как находящиеся в области статистической погрешности :) . В общем, как сделать реализацию конструкции в реальном железе ясно, дело за желанием автора.
И все ж ты напрасно упираешься против чип-программы своего 4-х ядерного чуда. Не будь ты Явлинским, если хочешь добиться своей цели! Эмулятор это только первая ступень космического корабля.
Ну не миллион, допутим. И потом, у тебя ж фишка в использовании готового софта, как я понимаю.
Black_Cat
07.05.2011, 14:07
считайте что GPLбыло бы лучше, если бы оно всё было под GNU GPL
я все же считаю что в эмуляции процессоров есть что то неправильное, в голове не укладывается когда что то более мощное эмулирует что то менее мощное без особых причинПЛИС - это не "что то более мощное", это ведро логических элементов и программа, описывающая как они должны соединяться
можно получить ZX-Poly даже на базе соединенных четырех спектрумов собранных по древней Зоновской схеме по нынешним временам это конечно экстрим сродни компьютеру на реле :)
есть только концепция, архитектура и эмулятор с несколькими тестовыми приложениями (в том числе и с тестовой ПЗУ) показывающими что идея действительно работает и работает отличноУ сабжа есть один существенный недостаток, который мешает его внедрению - это левое использование старших разрядов #7FFD и кривоватые адреса доп портов. Вот если это переделать, и всё выложить под GNU GPL, тоды реализация в ПЛИС станет вероятной.
michellekg
08.05.2011, 04:31
То ли я адски туплю, то ли у меня что-то не работает, но не могу даже запустить игру в эмуляторе. Его скачал, джаву скачал, rom-ы распаковал и в папку с эмулем кинул, запускаю, он проходит всякие тесты (включая видео), и останавливается на картинке 512x384.
И после этого - всё. Загружаю игру (модифицированную After the War) - ноль эффекта. Жму F12 - всё заново.
Что я делаю не так и что надо делать так? Если что, то у меня Windows 7 64 bit.
Попробуй установить Java. Смотри start.bat: "java.exe -jar zxpoly.jar".
Возможно, для Windows 7, нужно установить будет установить Microsoft Visual C.
И после этого - всё. Загружаю игру (модифицированную After the War) - ноль эффекта. Жму F12 - всё заново.
Используйте ROM из 3th_romimages.zip
Raydac, Ваш проект оказался "тяжелым" для серии ultra (u9). Четыре CPU съедают 90% ресурсов FPGA. Возможно ли сократить их кол-во до двух? Исходя из аппаратных ограничений для u9 (частота работы CPU без тактов ожидания с SDRAM составляет 21MHz (single read/write), с SRAM уже 105MHz).
а если сделать одно последовательно работающее на частоте 4.5 МГц процессорное ядро, которое будет в режиме разделения времени имитировать 4 процессора?
Это потянет на доработку, в виде 4-х аппаратных(программных- больше тактов при переключении) процессорных контекстов. С другой стороны, залезем в виртуализацию, т.е. к-во задач(виртуальные CPU) относительно производительности и поставленной задачи на систему.
Black_Cat
08.05.2011, 15:17
Исходя из аппаратных ограничений для u9 (частота работы CPU без тактов ожидания с SDRAM составляет 21MHz (single read/write), с SRAM уже 105MHz). Этого должно быть более чем достаточно. Делать надо как я тебе уже говорил. В FPGA делаешь регистровое ОЗУ для хранения внутренних регистров 4х CPU и портов 4х плат, которые мультиплексируются мгновенно. Также в каждом из 4х компьютеров надо продублировать регистры видеовывода, чтоб в одни писалась инфа процессорами, а из других выводилась на экран, а потом они менялись. Цикл обсчёта всех 4х CPU выполняется за 8 тактов 7 MHz, т.е. за время вывода строки одного знакоместа. Соответственно CPU должны работать на 14MHz, т.е. 4х.
При такой архитектуре всё прекрасно будет работать и свободного места останется достаточно!
michellekg
08.05.2011, 15:35
Попробуй установить Java. Смотри start.bat: "java.exe -jar zxpoly.jar".
Возможно, для Windows 7, нужно установить будет установить Microsoft Visual C.
Джава и так стояла, у меня даже jar-файл сам запускался (ибо проассоциирован). Но для надёжности я даже изменил батник, прописал абсолютный путь к java.exe и запустил. Оно, опять же, запустилось (правда, почему-то заметно тормознее, чем если просто запустить jar-файл), но результат тот же самый.
---------- Post added at 15:35 ---------- Previous post was at 15:33 ----------
Используйте ROM из 3th_romimages.zip
После того, как не сложилось с обычным ромом, кинул эти два в папку эмулятора. Тот же эффект.
Вообще, я так понимаю, после видеотеста эмуль должен вывалиться в стартовый экран 128-го спектрума или в TR-DOS?
michellekg
08.05.2011, 22:23
Фуф, слава богу, заработало!
Оказывается, в прошлый раз rom.bin тупо не заменился при копировании двух файлов из папки 3th_romimages.zip
Почему - не понятно. Но теперь всё ок, всем спасибо.
русскоязычное описание платформы почило в бозе, англоязычное заревьюил и переработал что бы было более менее человеческим языком написано, а не на Tarzan english , так что теперь это только один документ zxpoly_eng.pdf (http://igormaznitsa.com/zxpoly/zxpoly_eng.pdf) , один документ проще поддерживать
А чего случилось с русскоязычным?
Прикольное место:
http://s012.radikal.ru/i321/1105/a1/b4e2bfe77085.png
И на счет тактирования - у всех процессоров свои кварцы? Если это так, то они обязательно разойдутся.
Не маловато-ли 16 цветов?
Да и никто не спешит перерисовывать игры в многцветность, хотя подобные расширения существуют давно.
Black_Cat
29.05.2011, 15:00
хотя подобные расширения существуют давно.подобных не существует, и перерисовывать ничего не надо, токо рихтовать код
подобных не существует, и перерисовывать ничего не надо, токо рихтовать код
В эмуляторах существует.
Перерисовывать НАДО. Каждый спрайт. Если хочешь получить 16 цветов на точку. А вообще, такая методика плоховато подходит для графики, выводимой по xor, и по xor же стираемой. Так же могут разойтись в разные стороны программы, если идет сравнение коллизий с пикселами.
ну вот игры типа ATF вполне нормально адаптируются, да и я много видел с подобным хранением спрайтов (спрайт+маска), про то что если проверки попиксельно идут то процы "разъедутся" это понятно и я про это пишу :) но ZX не столь мощная штука что бы такие проверки проводить и 90% софта идут по простейшему пути, который вполне совместим с ZX-Poly
Проверка коллизий непосредственно с пикселами на экране - вещь соверешнно нормальная. Не могу сказать, в каких играх применяется, но если начнете переделывать, наверняка быстро наступите на эти грабли.
Второе - вывод по xor. Весьма распространенная вещь. К глюкам не приведет, но цвета при наложении двух таких спрайтов испортятся основательно до всех цветов радуги.
Black_Cat
29.05.2011, 21:42
Raydac, единственно не пойму зачем ты так вцепился в свои авторские права? Имхо, без GNU GPL оно и даром никому не надо..
Black_Cat
29.05.2011, 23:04
:) и сажи мне, кто эти бессребренники, что будут двигать чужую коммерческую разработку? :) Имхо, с таким подходом, на конструкции можно уже поставить крест.
Чую, опять концептуальная война разгорается)
---------- Post added at 23:25 ---------- Previous post was at 23:22 ----------
А вообще, идея увеличения количества битпланов достаточно распространенная, и ZX-Poly только частный случай ее реализации на Спекки. В данном случае 4 битплана. Встречалась в эмуляторах идея с 8 битпланами. Я вообще 16-битплановую систему придумывал, но лениво было делать)
Это я к тому, что копирайт тут можно наложить разве что на конкретную реализацию в виде какой-то хардварной железяки, но никак не на саму идею.
Black_Cat
30.05.2011, 08:28
у меня целевая аудитория не российская всежну эт ещё более фантастично звучит :) , там тем более никто коммерческий проект двигать не будет - only open source & open hardware :)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot