ZXNet эхоконференция «hardware.zx»

Hello, All

(C)1994-2007 И.А.Мазница (igor.maznitsa@igormaznitsa.com)

В 1994 году мне в голову пришла идея по увеличению цветового разрешения (а
вернее возможности убрать атрибутное органичение) для бытовой платформы
ZX-Spectrum. Идея позволяла достичь 16 цветов для каждой точки и сохранить (!)
совместимость с существующим программным обеспечением, дав возможность к
раскраске уже существующих игр без вмешательства в исполняемый код. В 1999 году
по данному поводу я написал статью, которую закинул в FidoNet, так же было дано
небольшое интервью (на самом ужасном английском какой существует) одному
Португальскому спектрумисту, который разместил в сети мои излияния о платформе
ZM-Polyhedron (как тогда гордо именовалась идея). Hа написанном на скорую руку
эмуляторе были получен скриншот из игры After The War, где я раскрасил пару
спрайтов. Попытки получить аппаратную версию платформы никчему не привели по
вполне понятной причине - конец 90-х являлся закатным для Спектрума как бытовой
платформы и никакого коммерческого интереса к данным работам уже никто не
испытывал.

Картинка: http://www.igormaznitsa.com/zxpoly/atw_99year.gif


В новогодние каникулы 2007 года, глядя на аппаратные мучения по разработке
видеопроцессоров и видеоускорителей поклонников Спектрума, я сдул пыль с данной
разработки и написал эмулятор (на Java) с тестовой версией ПЗУ. Hазвал
разработку ZX-Poly, что звучит приятнее и короче чем ZM-Polyhedron. Получилось
"виртуальное" устройство со следующими характеристиками:

Видеорежимы:
а) 256 на 192 (атрибуты как у стандартного Спектрума)
Картинка: http://www.igormaznitsa.com/zxpoly/testromscr.gif

a) 256 на 192 (16 цветов для каждой точки)

Картинка: http://www.igormaznitsa.com/zxpoly/video256x192x16.gif

б) 512 на 384 (атрибуты как у стандартного Спектрума)
Картинка: http://www.igormaznitsa.com/zxpoly/video512x384.gif

Память:
512 кБт ОЗУ
32 кБт ПЗУ (прошивка от стандартного магнитофонного ZX-Spectrum 128)

ЦПУ:
Четыре процессора Z80 3.5 МГц

Платформа многопроцессорная, разработана с целью дать программисту максимально
возможное количество вариантов использования. Позволяет организовывать
многопоточные приложения и иммитировать несуществующую переферию (к примеру
можно написать свою версию муз. процессора). Всё это осуществляется только
программным образом, за счет хитрого соединения процессоров между собой, замечу
что никакого расчета на реализацию в ПЛИС не делалось, т.е. платформа пригодна
к сборке на жесткой логике (хотя конечно эта задача не из легких). По старой
традиции ZX-128 все нововведения можно программно заблокировать для повышения
совместимости (всетаки никуда не деться, могут встречаться программы
конфликтующие). Основная изюминка платформы помимо многозадачности, это
возможность манипуляций с участками экрана в графических режимах с одинаковой
скоростью (без потери производительности), хотя конечно это не столь просто,
как при наличии специального видеосопроцессора, но зато оставляет очень много
места для фантазии и творчества. Так как платформа призвана быть простой, то
средства по разделению доступа процессоров к памяти и портам сведены к
минимуму.

Документ описывающий архитектуру расположен тут:
ZXPoly russian reference in Russian (.PDF)
[http://www.igormaznitsa.com/zxpoly/zxpoly_rus.pdf]


(C) 1994-2007 Igor A. Maznitsa
(C) 2007 Raydac Research Group Ltd.

Hello, Raydac

:v2_jawdr:

Hello, Raydac

Целых четыре проца всего лишь для раскраски игрушек - "непропорциональное
применение силы", как говорится. Имхо время подобных монструкций прошло - чисто
как игровой автомат оно может представлять интерес, но не как "развитие
Спектрума". Hе для всех задач многопоточность эффективна, это раз (уж лучше
воткнуть один камень побыстрее). Юзать потоки одновременно с новой 16-цветной
графикой нельзя (как минимум сильно неудобно), это два. Ориентация только на
старый размер экранчика и отстойную адресацию - тоже очень плохо и
эффективности не прибавляет, это три. Да и всякие 512x192 итп уже делали...

Всем интересующимся битплановыми режимами советую почитать доки по EGA (не
обращая внимания на пц-маразмы в деталях), чтобы понять - не нужны четыре (итд)
процессора для сохранения скорости работы старых игрушек, да и переделок в них
тоже понадобится минимум (вместо перерисовки спрайтов по всем плоскостям нужно
будет вставлять однократные команды выбора цвета). Единственная загвоздка -
программный скроллинг, но и с учетом сих трудностей даже до предела упрощенный
вариант "один Z80 на 21МГц + EGA-подобный (не "ATMEGA"!) режим" выглядит
универсальнее и перспективнее, чем "четыре Z80 на 3.5МГц (да сколько бы ни
было) + четыре процесса".

Hе то чтобы я был вот прям именно за такую схему... ;) Конечно существует некий
"порог монструозности", переходя который, становится невыгодно использовать
жесткую логику (в чем меня убедили товарищи железячники). Да и завязывать пора
с кучей не в меру "оригинальных" клонов и переходить наконец на слотную
архитектуру (разрабатывать не "новые Спектрумы" целиком, а периферию).

Ray> Кстати моя схема позволяет избежать атрибутных траблов

Да ну? --->

Cit> Spec256 работает по тому же принципу, только там 8 Спектрумов
Cit> параллельно трудятся, создавая 256 цветов. Hо, к сожалению, такая
Cit> реализация пагубно сказывается на те игры, где спрайты одинаковы, но
Cit> раскрашиваются атрибутами. В иных случаях это может оказаться
Cit> критично.

Этим дело не ограничится. Подгрузка графики в многоуровневых игрушках - уже
проблемы. Запакованные данные - то же самое. Любая вычисляемая графика (3D в
том числе, но не только) - тоже не прокатит. Слишком узка область применения у
девайса, если так уж хотим обойтись без копания в коде. Хотя, как уже писал, в
качестве эдакого автомата для "ретрогеймерства" - вполне годится. Если эмулятор
не торкает. :)

P.S.

Ray> По такой схеме 24 проца будут TrueColor выдавать с немерянной
Ray> скоростью...

:D

Hello, CityAceE

Cit> Spec256 работает по тому же принципу, только там 8 Спектрумов
Cit> параллельно трудятся, создавая 256 цветов. Hо, к сожалению, такая
Cit> реализация пагубно сказывается на те игры, где спрайты одинаковы, но
Cit> раскрашиваются атрибутами. В иных случаях это может оказаться
Cit> критично.

По такой схеме 24 проца будут TrueColor выдавать с немерянной скоростью,
проблема в том, платформа должна не только отрабатывать этот Use case, но и:
1) быть адекватной в программировании
2) не быть сверхсложной для сборки
3) Быть способной к работе не только на фазе эмуля
Я посмотрел, что 4 проца наиболее оптимально

Hello, Error404

Err> Ага, вот этого то я и не уловил, просмотрев "по диагонали" описание.
Err> "Общий блок" - это все 512к? Тогда это то, что нужно.А какие-то
Err> аппаратные стенды уже делались (хоть когда0нибудь) под это? Или это
Err> пока только модель?

В 99м была попытка сделать аппаратное, но времени катастрофически не хватало и
пришлось это всё оставить на уровне теории :( так что всё что имеется это
описание архитектурного решения, эмулятор, скриншоты, тест ПЗУ (кстати должен
признать что писать многопоточные программы на этой платформе не сложно, как то
удачно получилось). Еще очень удобно когда пространство другого ЦПУ становится
внешним устройством и адресуется через порты, фактически как электронный диск
можно юзать..

Hello, Error404

Err> Т.е. нужно 1 диспетчер по 64к или 4 одновременно и независимо
Err> работающих диспетчера по 16к (каждый в своем окне: 0..3FFF,
Err> 4000..7FFF, 8000..BFFF, C000..FFFF).
Err> --
Err> Что понравилось - наконец то есть возможность выключения дурацкого
Err> ПЗУ, занимающего четверть адресного пространства. И режим экрана, на
Err> котором можно организовать нормальный терминал 80х25.

Процессор легко может переключать смещение своего ОЗУ в общем блоке,
единственная проблема подготовить переход, что бы не вылететь в пустоту :) ,
так же по архитектуре все 4-е проца могут толкаться в одном адресном
пространстве, что порождает прямо таки извращенческие варианты использования :)
вплоть до попытки объединения для параллельного 32 битной обработки.. Кстати
предложенная схема 512 на 384 позволяет оптимизировать существующие текстовые
редакторы всеголишь на уровне рисунков символов и этого будет достаточно что бы
они работали в данном разрешении..

Hello, Lethargeek

Let> Целых четыре проца всего лишь для раскраски игрушек -
Let> "непропорциональное применение силы", как говорится. Имхо время
Let> подобных монструкций прошло -

Вы или плохо прочитали или плохо уяснили, раскраска старых игрушек там - один
из возможных эффектов архитектуры, многопоточность и одновременный вывод
цветной графики вполне реальна.. Если бы мне захотелось очень удобную железку
:) то я непременно сделал бы очень удобную железку, но мне нужен был именно
Спектрум :) а не EGA c Z80 на 21 МГц. Что же касается слотных компов, то Спек
всетаки не совсем из их класса и порог "монструознусти" я старался не
переходить :) так как "что сложно - не нужно" :) Я бы назвал эту спецификацию
не более клоном Спека чем Спек 128 был клоном Спека 48 го :)

Hello, Raydac

Посмотрел сайт по SPEC 256, к сожалению вынужден констатировать, что "качество
не моей мануфактуры", цитата с их сайта:
The idea is; in; one hand we´ve got the speccy emulator with its memory
zone, and in the other we emulate a Z80 which works with 64 bit registers
instead of 8 bit, and with a memory map with positions of 64 bit instead of 8.

Т.е. собрать аппаратно это чудо можно только с Z80 имеющим 64 битные регистры,
моя версия всетаки не столь извращена, ибо не содержит научно-фантастических
вещей, хотя конечно это не умаляет значение и интересность концепции Spec 256.

p.s.
Кстати моя схема позволяет избежать атрибутных траблов :)

Hello, andrews

and> на 24 проца эмуль тоже есть? с эмуляторами хотелось бы
and> поработать...собирать в железе на рассыпухе? возможно найдутся
and> желающие, какова стоимость?

в железе это можно просто тогда собрать... берутся 24 спека, общий тактовый
генератор, общий ресет, последовательно на них wait, в активный загружается
часть с измененной под него графикой, а к видео они подключены через ЦАП RGB
888.. старые игры многие раскрасить удастся, но кроме как загрузить и поиграть
с этим сделать больше ничего не удастся, так что стоимость = 24 платы спека +
баков 50 (коммутатор) + ZX клава + Kempston + коммутатор последовательно
выдающий wait и reset (тоже баков 50).. но это нельзя назвать архитектурой, так
как непрограммируемо.. компы вообще друг с другом не контачат тогда :)

Hello, moroz1999

mor> как реализована раскраска спрайтов?

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

Hello, newart

new> Да уж сколько лет есть, Kay, Scopion и т.д.
new> Hо не юзал ведь почти никто.

Я специально включил поддержку отключения ПЗУ, так как в совокупности с
блокировками, это позволяет на лету немного адаптировать стандартный бейсик
Спектрума для работы в 16 цветовой полноценной графике, записать его в RAM0 и
сделать "рабочей прошивкой".

Hello, Raydac

Ray> Основная идея раскраски старых игр, что одновременно работают четыре
Ray> спека каждый выводит видеоинформацию на свой битовый план,

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

Hello, scl^mc

как реализована раскраска спрайтов?

Hello, Raydac

Ray> По такой схеме 24 проца будут TrueColor выдавать с немерянной
Ray> скоростью, проблема в том, платформа должна не только отрабатывать
Ray> этот Use case, но и:
Ray> 1) быть адекватной в программировании
Ray> 2) не быть сверхсложной для сборки
Ray> 3) Быть способной к работе не только на фазе эмуля
Ray> Я посмотрел, что 4 проца наиболее оптимально

на 24 проца эмуль тоже есть? с эмуляторами хотелось бы поработать...собирать в
железе на рассыпухе? возможно найдутся желающие, какова стоимость?

Hello, Error404

Err> Что понравилось - наконец то есть возможность выключения дурацкого
Err> ПЗУ, занимающего четверть адресного пространства.

Да уж сколько лет есть, Kay, Scopion и т.д.
Hо не юзал ведь почти никто.

Hello, Error404

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

Hello, Raydac

Ray> Процессор легко может переключать смещение своего ОЗУ в общем блоке,
Ray> единственная проблема подготовить переход, что бы не вылететь в
Ray> пустоту

Ага, вот этого то я и не уловил, просмотрев "по диагонали" описание. "Общий
блок" - это все 512к? Тогда это то, что нужно.

А какие-то аппаратные стенды уже делались (хоть когда0нибудь) под это? Или это
пока только модель?

Hello, newart

new> Да уж сколько лет есть, Kay, Scopion и т.д.
new> Hо не юзал ведь почти никто.

Hу, я ничего про эти модели не знаю.
А как можно это не юзать, если без этого CP/M нормально не запустить (там все
ПО странслированo на работу с 100h).

Hello, scl^mc

Читал pdf-ник, много думал :) о том, за что же разработчики так не любят
диспетчер по 64к (или - что за странная любовь к диспетчеру по 16к в
единственном окошке, т.е. негодного ни на что кроме свопинга для единственного
процесса). Чтобы написать многоПРОЦЕССОВУЮ систему полезнее не 4 процессора
(что, конечно, тоже не лишнее) а диспетчер, позволяющий за минимальное число
тактов переключать весь контекст процесса (т.е. в идеале - всё куцее 64к
адресное пространство Z80). Т.е. нужно 1 диспетчер по 64к или 4 одновременно и
независимо работающих диспетчера по 16к (каждый в своем окне: 0..3FFF,
4000..7FFF, 8000..BFFF, C000..FFFF).
--
Что понравилось - наконец то есть возможность выключения дурацкого ПЗУ,
занимающего четверть адресного пространства. И режим экрана, на котором можно
организовать нормальный терминал 80х25.

Hello, Raydac


Ray> Вы или плохо прочитали или плохо уяснили, раскраска старых игрушек
Ray> там - один из возможных эффектов архитектуры, многопоточность и
Ray> одновременный вывод цветной графики вполне реальна.. Если бы мне
Ray> захотелось очень удобную железку :) то я непременно сделал бы очень
Ray> удобную железку, но мне нужен был именно Спектрум :) а не EGA c Z80
Ray> на 21 МГц. Что же касается слотных компов, то Спек всетаки не совсем
Ray> из их класса и порог "монструознусти" я старался не переходить :) так
Ray> как "что сложно - не нужно" :) Я бы назвал эту спецификацию не более
Ray> клоном Спека чем Спек 128 был клоном Спека 48 го :)

Из выложеной документации совершенно непонятно, как осуществляется
синхронизация этих самых ПМ. Как осуществляется загрузка софта? В каждый ПМ по
отдельности, сиречь одна и та же программа с "разными цветами" по одному и тому
же адресу в четыре ПМ? А как потом осуществляется синхронное выполнение когда?
Имеют ли все 4 ПМ общие магистрали (а судя по описанию прерогатив ПМ0 они
должны быть), как они организованы, как организован доступ к ним? Как вообще
делятся общие ресурсы между всеми ПМ?

Hello, Raydac

Ray> один из сценариев:
Ray> CPU0 грузит программный блок, затем грузит измененные блоки графики в
Ray> адресное пространство других CPU (которые на WAIT), после окончания
Ray> загрузки на все процессора передается RESET с записанной командой
Ray> перехода на старт программы, далее они работают синхронно, не
Ray> взаимодействуя друг с другом.. конечно могут быть и другие варианты
Ray>
Ray> Я в выходные еще допишу доку, для уточнения вопросов, а то мне то она
Ray> понятна и на низком уровне, но постораюсь написать поподробнее..

Хм, надеюсь дописаная дока ответит на многие вопросы. Hастораживает "один из
сценариев", я так думал, что с конца 90-х это всё уже продумано от и до. Может
я просто себе всё сложно представляю?

Hello, Raydac

Ray> А что такого? Думаю что Вы бы в 82 вообще были бы до крайности
Ray> возмущены нелинейной организацией видеопамяти

Гы, в 82 я не знал, что такое программируемый калькулятор, не то что цомпутер.
:) А так конечно был бы возмущен, но только не самой "нелинейной организацией",
а лишь не самым эффективным вариантом реализации оной.

Ray> только это мелочи

Я херею, дорогая редакция... :v2_wacko; Hо; если главная цель - попаять, тады
ладно. ;)

Ray> Спек вообще неудобная платформа это его концепция в какой то степени

Аццкий отжиг!! :v2_clap2; :v2_clap2:; :v2_thumb;
А; мужики-то не знают... 10000+ софта на него накатали, мазохисты... :v2_laugh;
Простой; - да, но неудобный - очень спорно. Удобство с простотой или мощностью
вообще никак не связано.

Hello, Raydac

Ray> многопоточность и одновременный вывод цветной графики вполне
Ray> реальна...

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

Hello, CHRV

CHR> Игорь, а торговая марка (ТМ) "ZX-Poly" реально зарегистрирована или
CHR> это так - между нами? :).

(TM) - это не зарегистрированная официально :) как то смысла нет
регистрировать, а то это штуки полторы баков стоит

Hello, Lethargeek

Let> Гы, в 82 я не знал, что такое программируемый калькулятор, не то что
Let> цомпутер. :)

У меня подход простой :) пришла идея, я её доработал и реализовал пускай на
эмуле и показываю результат.. Если у Вас есть другая идея, то сформулируйте,
опишите, покажите.. может у Вас более здравая.. кто мешает то? :)

Hello, Lethargeek

Let> Если что-то полноцветное надо вывести на экран, должны работать все
Let> четыре Z80 (причем крррайне желательно, чтобы синхронно), а это
Let> значит - надо останавливать все четыре активных процесса, если одному
Let> из них приспичило что-то вывести (даже только в "свое" окошко). Иначе
Let> - понадобится писать спецбиблиотеку с несинхронной

А что такого? Думаю что Вы бы в 82 вообще были бы до крайности возмущены
нелинейной организацией видеопамяти :) только это мелочи всё, если требуется
быстрая легкая разработка какой то идеи то надо на Писишку, если хочется
показывать высший пилотаж по алгоритмам и выжиманию чего то оттуда где нету, то
на Спек.. Спек вообще неудобная платформа :) это его концепция в какой то
степени

Hello, icebear

ice> Из выложеной документации совершенно непонятно, как осуществляется
ice> синхронизация этих самых ПМ. Как осуществляется загрузка софта? В
ice> каждый ПМ по отдельности, сиречь одна и та же программа с "разными
ice> цветами" по одному и тому же адресу в четыре ПМ? А как потом
ice> осуществляется синхронное выполнение когда? Имеют ли все 4 ПМ общие
ice> магистрали (а судя по описанию прерогатив ПМ0 они должны быть), как
ice> они организованы, как организован доступ к ним? Как вообще делятся
ice> общие ресурсы между всеми ПМ?

один из сценариев:
CPU0 грузит программный блок, затем грузит измененные блоки графики в адресное
пространство других CPU (которые на WAIT), после окончания загрузки на все
процессора передается RESET с записанной командой перехода на старт программы,
далее они работают синхронно, не взаимодействуя друг с другом.. конечно могут
быть и другие варианты

Я в выходные еще допишу доку, для уточнения вопросов, а то мне то она понятна и
на низком уровне, но постораюсь написать поподробнее..

Hello, icebear

ice> Хм, надеюсь дописаная дока ответит на многие вопросы. Hастораживает
ice> "один из сценариев", я так думал, что с конца 90-х это всё уже
ice> продумано от и до. Может я просто себе всё сложно представляю?

вот в конце 90-х по такому сценарию и работала ATW "адаптированная"

Hello, Raydac

Игорь, а торговая марка (ТМ) "ZX-Poly" реально зарегистрирована или это так -
между нами? :).

Hello, Raydac

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

Hello, Raydac

Да предлагаю, описываю... поиск по форуму рулит... ;)

Hello, Raydac

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

мдаа, всё гениальное - просто :D

Hello, Jukov

Juk> А эмулятор или скриншоты где можно скачать?

Эмулятор надо дооформить что бы выкладывать, а то я его в среде разработки
юзаю.. скриншоты из тестов я сюда в первую мессагу выложил

Hello, Lethargeek

А эмулятор или скриншоты где можно скачать?

Hello, Shaos

Sha> 4 спека в параллель для формирования битпланов - это 16 цветов с
Sha> потерей атрибутов. Если ещё учитывать и атрибуты, то диапазон
Sha> использованных цветов сильно расширится - виртуально получим 16
Sha> цветов в пределах одного знакоместа из виртуальной палитры в 64K
Sha> цветов.

Да, есть куча места для палитры (768*4 байт), я об этом думал, да и в принципе
еще два видеорежима в резерве, но потом решил что это уже усложнение идет... я
стараюсь только необходимый минимум впихать

Hello, Raydac

казало бы идея интересная, но мне что-то не очень нравится, да и надо ли такой
огород городить ради 16 цветов на каждую точку= вся система на 4х процах...
все гениальное, как известно из пословицы просто, а здесь все не просто...
мультиколор кто-то кодил? ну и как? можно... но геморрой!? так мне и
предложенная система не видится проще, да и делать надо все с нуля, а что там
получится... в общем imho, шкурка выделки не стоит=

да, кстати, такой режим уже реально существует (кто не знал, читайте ig#8, 9)
уже можно поиграть в несколько игр - pang, одна из них. мене существующая
реализация нравится больше, да и сколько можно изобретать велосипед. если же
хочется получить под этот режим многопроцессорный более производительный спек,
то мне кажется лучше задуматься, как к уже существующему железу прикрутить
второй zilog в 21MHz. насколько я знаю, я уже не первый кто о подобной идее
задумывался, вот только до последнего времени я не осознавал где в этой
красивой идее скрыта проблема (ну не железячник я), а проблема заключается в
доступе к памяти и портам ввода вывода, конечно как кодер я понимаю, что часть
проблем можно будет решить программно, но кое-что все же необходимо решать
аппаратно.

на счет отключения пзу и подключения вместо нее озу. полностью согласен с
newart'ом= только хочу добавить, что не только на скорпах и каях этого можно
добиться, но также на профиках, и я думаю что не ошибусь, сказав, что и на атм,
а быть может и на метровых и полуметровых пентагонах.

Hello, Raydac

Вот именно, что сделать...а выше перечисленное как говорится отдай деньги - и
спи спокойно!

Hello, pulsar

pul> кажется лучше задуматься, как к уже существующему железу прикрутить
pul> второй zilog в 21MHz

а еще лучше существующее железо нафиг выкинуть, оставив только z80 и все
обращения к нему перехватывать и выдавать на другое, современное и "правильное"
железо :) которое убрать в ПЛИС...сам же z80 оставить ислючительно для
выполнения ранее разработанного кода, да и то не всего, а менее всего
тормозного

Hello, andrews

and> а еще лучше существующее железо нафиг выкинуть, оставив только z80 и
and> все обращения к нему перехватывать и выдавать на другое, современное
and> и "правильное" железо :)

Проекту "Каша из топора" уже несколько сотен лет :) .. топор есть, но он не
нужен :) .. задача всетаки сделать Спектрум, а эмулятор Спектрума можно и на
писишке сделать и на КПК и на мобиле.. там железо не столь правильное, но
ультрасовременное...

Hello, pulsar

pul> прикрутить второй zilog в 21MHz. насколько я знаю, я уже не первый
pul> кто о подобной идее задумывался, вот только до последнего времени я
pul> не осознавал где в этой красивой идее скрыта проблема

А что мешает подключить 4-е 21 МГц Z80? Тут же просто описывается как они
соединяются программно, взаимодействуют и осуществляют работу :)

Hello, Mike

Mik> Что бы к имеющемуся спеку приделать видяху, надо будет напаять кучу
Mik> соплей, нарезать кучу дорожек и т.д. как обычно, просто слотом
Mik> расширения не отделаешься. А если все эти сопли развести на новой
Mik> матери, так, что бы их не было, то это и будет новый спек. А если ещё
Mik> добавить обычные PS/2 и IDE - контроллеры, то получится как раз то,
Mik> чем занимались спринтеровцы, недоПЦ (последние к счастью и сейчас
Mik> занимаются).

Это мягко говоря не так :) Более того, иначе чем через системный разъём вообще
быть не должно.

Hello, Raydac

Ray> задача всетаки сделать Спектрум,

В том-то и беда, что все постоянно "делают новый Спектрум", вместо того чтобы
создавать решения, пригодные к использованию на любом уже существующем
Спектруме (я конечно только про видео).

Hello, Lethargeek

Let> В том-то и беда, что все постоянно "делают новый Спектрум", вместо
Let> того чтобы создавать решения, пригодные к использованию на любом уже
Let> существующем Спектруме (я конечно только про видео).

Что бы к имеющемуся спеку приделать видяху, надо будет напаять кучу соплей,
нарезать кучу дорожек и т.д. как обычно, просто слотом расширения не
отделаешься. А если все эти сопли развести на новой матери, так, что бы их не
было, то это и будет новый спек. А если ещё добавить обычные PS/2 и IDE -
контроллеры, то получится как раз то, чем занимались спринтеровцы, недоПЦ
(последние к счастью и сейчас занимаются).

Hello, andrews

and> Поэтому железо должно быть избыточно мощным с перепрограммируемыми
and> режимами, чтобы собрав один комп, получать из него на свое усмотрение
and> любой клон. Только не надо матерится, называя это эмулятором. Это не
and> эмулятор! Просто отдельные железные компоненты поддерживают кучу
and> режимов и настраиваются на нужный.

Просто некоторым людям спать спокойно не даёт "идеология" о эмуляции и
монстростроении. Если им нравится считать это монстром, эмулятором и вообще
бредовой идеей - их право, а кого такие тараканы не беспокоят, пусть
разрабатывают и юзают в удовольствие, не сходя с ума по "идеологиям". Главное,
не надо превращать это в религию, высказал мнение - молодец, а навязывать в
каждой ветке не надо.

Hello, Raydac

Ray> Пожалуй беда не в том, что кто-то постоянно делает новый спектрум
Ray> ,беда в том, что кто-то вообще ничего не делает

Вот тут в точку :)
Игорь, хорошо, это все великолепно, идея правильная, почитал документацию - в
общих чертах можно сложить впечатление и даже можно представить что это таки
реально создать, оно сможет раскрасить даже более чем 60% существующих игрушек,
и будет пользоваться спросом.
Собственно теперь вопрос - когда Вы планируете предоставить это хотя бы в виде
программного эмулятора, чтобы можно было реально погонять и потестировать идею
(а видеть увидеть ее в лицо - это лучшая реклама для проекта), и что будет
дальше - я уже конкретно о "железной реализации" - что и как Вы планируете
делать (я так понимаю что будет вариант полностью нового "железа", а будет ли
вариант "примочки" к любому существующему спеку?), и если планируете то как
скоро, и если не скоро - то почему - вообще, как я понимаю - изначально этот
топик ориентирован на оценку Вашей идеи и последующее привлечение инвестиций
под развитие идеи? ;)

Hello, Lethargeek

абсолютно согласен, я собственно выше об этом и говорил.

Hello, Mike

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

Hello, Lethargeek

Let> В том-то и беда, что все постоянно "делают новый Спектрум"

Пожалуй беда не в том, что кто-то постоянно делает новый спектрум :) ,беда в
том, что кто-то вообще ничего не делает :)

Hello, Mike

Обновил описание в виде PDF файла по старой ссылке. Включил больше графических
представлений, нашел несколько злостных (!) опечаток (всетаки документ
одновременно с написанием эмуля делался. Эмуль выложу тоже но чуть позжее..
Повторная ссылка на документ http://www.igormaznitsa.com/zxpoly/zxpoly_rus.pdf

Hello, Mike

Mik> Если я не прав, покажите мне пример такой видяхи.

Что бы показать тебе пример, надо иметь саму видяху, а её ещё нет. Однако
ZX-BUS имеет весь набор необходимых сигналов для подключения видеокарты.
Единственный момент, если как-то хитро/умно захочется сделать доступ видяха к
хостовой памяти, то придётся немного порезать, но всё равно, не много.

Hello, Raydac

Ray> В документе написано что 4е порта, значит четыре порта :)
Ray> В одновременную работу процессоров с памятью (если она медленная)
Ray> можно вводить сигналы WAIT, так что все девайсы могут работать хоть с
Ray> одной микросхемой (и видеоконтроллер так же). Я описываю
Ray> теоритеческую архитектуру, факт что она может быть реализована
Ray> аппаратно, как она будет реализована это уже вторая задача, так как
Ray> вариантов масса.

Короче по сути это просто идея и тогда, когда ты мне в 99-м писал об этом, это
тоже была идея, так?

Hello, Raydac

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

В таком случае память должна быть физически построена отдельными микросхемами
(скажем 4 штуки по 128К) и чтении из областей видеопамяти каждого ПМ происходит
параллельно, так? Есть ли у ПМ общие ресурсы? Если есть (а память уже не может
быть общим ресурсом из-за ВК), как они делятся? Hе много-ли накладных расходов
получается, если фактически иметь четыре порта 7FFD и т.п.?

Hello, Raydac

Ray> Обновил описание в виде PDF файла по старой ссылке. Включил больше
Ray> графических представлений, нашел несколько злостных (!) опечаток
Ray> (всетаки документ одновременно с написанием эмуля делался. Эмуль
Ray> выложу тоже но чуть позжее..
Ray> Повторная ссылка на документ
Ray> http://www.igormaznitsa.com/zxpoly/zxpoly_rus.pdf

Ещё вопрос: видеоконтроллеров сколько, тоже 4? А если он один, то как делится
доступ к видеопамяти между ним и четырьмя ПМ? Кстати, на с. 14 хороший рисунок,
от тебя, Летаргик, я подобного уже добиваюсь не знаю сколько.

Hello, icebear

ice> иначе чем через системный разъём вообще быть не должно.

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

Hello, Cooper

andrews, а Ваша идея тоже хороша, но в ней нет изюминки, кроме как очередная
реализация того, что все давно сделали на рассыпухе, а не красиво в 2х чипах.
Может стоит таки объединить усилия с Raydac опять и работать над одним
проектом? Hе знаю, возможно ли это по Вашим тактическим соображениям, тут не
буду лезть глубоко, просто мысль вслух.

Hello, Raydac

Ray> Думаю, что при попытках коммерциализации проетка, возникнет очень
Ray> много вопросов с правообладателями адаптированных игр и владельцами
Ray> стандартной спековской ОС.

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

Hello, Raydac

Ray> Ок, тогда на этой неделе выложу точно.. некоторые игрухи не
Ray> запускаются почему то (TAP файлы), но у меня подозрение что они криво
Ray> записаны, так как Unreal Speccy тоже не запускает их..
Ray>
Ray> Думаю если на ПЛИС делать, то реализация такой архитектуры месяца
Ray> полтора займет (если не на базе готовых модулей), в 99м и была
Ray> попытка схему под ПЛИС разработать, но тут надо спецов по ПЛИСам
Ray> спрашивать так как я к примеру в основном жесткой логикой да
Ray> микроконтроллерами оперировал..

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

По поводу реализации - да, в наш век явно стоит попытаться это реализовать на
ПЛИС, и как можно в меньшем количестве корпусов, и, конечно, наиболее
интересный вариант был бы - не в виде совсем нового компа, а именно в виде
дополнительного модуля, который можно прицепить на все основные (известные нам)
типа Спеков, и как я понимаю, видеовыход будет заложен именно в этой карте?
Сразу делать реализацию с возможностью подключения VGA монитора, времена
телевизоров и старых тазиков типа МС уже прошли. Вот тогда, я полагаю, идея
получит довольно интересное развитие..

BTW, запихивание всех Z80 в ПЛИСину опять же не самый критический момент, не
будет большой проблемы если будут стоять именно процы, а ПЛИС рулить всем
остальным. Хотя конечно вариант конечной реализации - это уже прерогатива
автора.

Уж больно мне охота посмотреть на старые шедевры в нормальной раскраске
:v2_cheer:

Hello, Raydac

Ray> Эмулятор надо всетаки в какой то божеский вид привести, но думаю что
Ray> версию на этой неделе выложу, правда работа там только с TAP файлами
Ray> и на Java он, система диагностики происходящего - зачаточная..
Ray> Мне инвестиции под него не удалось в 97-99 м получить а сейчас думаю
Ray> ситуация еще хуже, так как с коммерческой точки зрения ZX-Spectrum
Ray> уже практически несуществует, это fun-platform так что топик
Ray> организован, что бы ознакомить окружающих с идеей, получить трезвые
Ray> оценки и послушать размышления, если кто из железячников захочет
Ray> имплементировать данную архитектуру, то в документе условия
Ray> определены. Просто из всего того что выдвигается на звание "нового
Ray> русского спектрума" эта платформа наиболее подходит под определения
Ray> выдвинутые мною в одной из веток форума про то, что может называться
Ray> "спеком"

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

Просто, по моему мнению, эта идея - наиболее интересная из всего, что я читал
на этом форуме о железе за последние несколько лет.

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

Hello, andrews

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

По цене - да пофиг, даже если прототип таки заработает, будет доведен до ума,
сможет реально раскрасить хотя бы 60% софта, быть с флешкой (ну а под остальное
можно оставить системную шину - ее никто не отменял) - пусть стоит хоть 300
евро, я куплю.

Вот смотри, например вот так реализовали MSX;
http://www.bazix.nl/onechipmsx.html;
Судя по информации - их размели еще на уровне предварительного заказа.
А если сделать что-то тоже красивое и аккуратное со спеком, да еще, если он
будет перекрашивать игры просто на лету - бомба будет, причем не только для
русского рынка. Главное стараться реализовать максимально просто и делать упор
именно на то что это игровой комп - кто захочет к нему подключить полноценную
клаву, бетадиск, контроллер винта и тп - для них просто шина в попе девайса и
все.

Hello, andrews

Конкуренция это хорошо в любом случае, главное чтобы результат был хоть у
кого-то.
Hет, вариант с виртуальными дисками однозначно неприемлем и не пойдет, разве
что сделать универсально - и с флешкой и с возможностью заливки на виртуальный
диск. Поясню даже почему:
Ко мне пришло несколько друзей детства кто помнит спек, я достал сей девайс,
подключил его к плазме что висит на кухне и мы сели побалдеть под пиво. В
варианте с флешкой - я просто принес девайс на кухню, включил и все. В варианте
с виртуальными дисками - будет менее удобно, у меня конечно компами вся
квартира забита, но на кухне нет компа, а сидеть там с ноутом неинтересно - я
тогда на ноуте эмуль амиги лучше запущу друзьям.
Это как раз и есть рассуждение о маркетинге, это должно быть реализовано
максимально удобно, а не так как решил разработчик сам для себя :)

Hello, Cooper

Coo> и с флешкой и с возможностью заливки на виртуальный диск. Поясню даже
Coo> почему:
Coo> Ко мне пришло несколько друзей детства кто помнит спек, я достал сей
Coo> девайс, подключил его к плазме что висит на кухне и мы сели побалдеть
Coo> под пиво. В варианте с флешкой - я просто принес девайс на кухню,
Coo> включил и все. В варианте с виртуальными дисками - будет менее
Coo> удобно, у меня конечно компами вся квартира забита, но на кухне нет
Coo> компа, а сидеть там с ноутом неинтересно - я тогда на ноуте эмуль
Coo> амиги лучше запущу друзьям.

8Гб флэшь -сейчас эксклюзив, стоит больше 150 евро,
120 Гб диск в ноуте стоит что-то около того же.
А размер современного ноута обратно пропорционален толщине кошелька.
Вопрос: как долго надо сидеть с друзьями на кухне, чтобы прокрутить им на 8Гб
спековских демок?
И есть ли их столько в природе?
Hадо словом считать. Взять 4-12 часов времени просмотра и посмотреть в какую
память это влазит.

Hello, Cooper

Здоровая конкуренция на пользу прогресса. Относительно дисковых
устройств...лучше иметь отображаемые диски. Просто цепляешься к ноутбуку или
писи и заливаешь на виртуальные диски что надо. При достаточном объеме
статической памяти и хорошей батарейке не надо и париться с контроллерами sd, а
usb-device в сети корка есть. Да, лишняя софтина для писюка, придется слегка
поступиться принципами...дабы купили не 10 человек за 300 евро, а 300 человек
за 120, но тут уж не мне об этом говорить, Игорь -бизнесмен, а эту
загогулину(цена-спрос) каждый студень на первых курсах чертит. Все улучшения
наступают не с первой версии.

Hello, Raydac

Вот если сделаешь нормальную связку на плисине, к 4 обычным z80, уложишься в
10-12 микросхем и в 60 евро по деталям (без учета печатной платы и
конструктива), тогда это будет комп.

Hello, Raydac

Я те как спец скажу ( учитывая мое почти годовое сотрудничество с Actel.ru ),
что 4-е z80 потянут на $35-40 плисину и за 1.5 месяца (работая каждый день по
10 часов)ты все это хозяйство не верифицируешь.

Hello, andrews

Да и о времени выборки списка файлов не будем забывать. В 8Гб влазит более
8000000 10кб файлов, дать с этим парится z80 или послать запрос через usb на
писи, в данной задаче являющейся сервером несоизмеримо большей
производительности? Есть такая критическая емкость носителей для z80 при
которой подобные операции не вызовут ничего кроме тихого помешательства. А
помнить где-что лежит ( не забудем что диски даже удаленные и виртуальные
опять-таки trdos-овские)...я лично очень активно пользуюсь на компе операцией
поиском по ключам.

Hello, andrews

Думаю все же какую-то часть вентилей оставишь на умножители ( а еще даже лучше
"бабочку") и не забудешь про нормальную внешнюю шину.

Hello, Cooper

Coo> По поводу реализации - да, в наш век явно стоит попытаться это
Coo> реализовать на ПЛИС, и как можно в меньшем количестве корпусов, и,
Coo> конечно, наиболее интересный вариант был бы - не в виде совсем нового
Coo> компа, а именно в виде дополнительного модуля, который можно
Coo> прицепить на все основные (известные нам) типа Спеков, и как я
Coo> понимаю, видеовыход будет заложен именно в этой карте?
Coo>
Coo> Уж больно мне охота посмотреть на старые шедевры в нормальной
Coo> раскраске :v2_cheer;

Да,; пока занавес железный не рухнул опять, лучше на ПЛИС :)
К сожалению врядли возможно чисто аппаратно реализовать данную архитектуру как
довесок к существующим типам, так как в ней процессорные модули слишком увязаны
между собой, не думаю что какая либо из стандартных спековских шин позволит
такое имплементировать..

Если честно, то мне бы скорее хотелось адаптированный текстовый редактор в
нормальном разрешении (512 на 384) увидеть, а не игры :)
еще по моим прикидкам можно адаптировать спековский BASIC для работы в 16
цветном режиме без глобальных переделок..

Hello, Cooper

Coo> это примерно на уровне подключения к спеку черно-белого или цветного
Coo> телека - визуал только меняется ;)

Hет, тут скорее нарваться на сопутствующие авторским права можно, в частности
"права на переработку"..

Hello, Cooper

Coo> Raydac, пробовать надо, в итоге. Если делать в виде отдельного компа
Coo> - тогда упрощать до безобразия

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

Hello, Cooper

Coo> Вот тут в точку :)
Coo> как я понимаю - изначально этот топик ориентирован на оценку Вашей
Coo> идеи и последующее привлечение инвестиций под развитие идеи? ;)

Эмулятор надо всетаки в какой то божеский вид привести, но думаю что версию на
этой неделе выложу, правда работа там только с TAP файлами и на Java он,
система диагностики происходящего - зачаточная..
Мне инвестиции под него не удалось в 97-99 м получить :) а сейчас думаю
ситуация еще хуже, так как с коммерческой точки зрения ZX-Spectrum уже
практически несуществует, это fun-platform :) так что топик организован, что бы
ознакомить окружающих с идеей, получить трезвые оценки и послушать размышления,
если кто из железячников захочет имплементировать данную архитектуру, то в
документе условия определены. Просто из всего того что выдвигается на звание
"нового русского спектрума" эта платформа наиболее подходит под определения
выдвинутые мною в одной из веток форума про то, что может называться "спеком"

Hello, Cooper

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

Ок, тогда на этой неделе выложу точно.. некоторые игрухи не запускаются почему
то (TAP файлы), но у меня подозрение что они криво записаны, так как Unreal
Speccy тоже не запускает их..

Думаю если на ПЛИС делать, то реализация такой архитектуры месяца полтора
займет (если не на базе готовых модулей), в 99м и была попытка схему под ПЛИС
разработать, но тут надо спецов по ПЛИСам спрашивать :) так как я к примеру в
основном жесткой логикой да микроконтроллерами оперировал..

Hello, andrews

and> Я те как спец скажу ( учитывая мое почти годовое сотрудничество с
and> Actel.ru ), что 4-е z80 потянут на $35-40 плисину и за 1.5 месяца
and> (работая каждый день по 10 часов)ты все это хозяйство не
and> верифицируешь.

Я не предлагаю реализовывать Z80 в ПЛИС, в этом смысла нет.. а что касается
специализма, дак я по себе сужу.. нормальный то человек может и больше возьмет
времени

Hello, icebear

ice> Hе много-ли накладных расходов получается, если фактически иметь
ice> четыре порта 7FFD и т.п.?

В документе написано что 4е порта, значит четыре порта :)
В одновременную работу процессоров с памятью (если она медленная) можно вводить
сигналы WAIT, так что все девайсы могут работать хоть с одной микросхемой (и
видеоконтроллер так же). Я описываю теоритеческую архитектуру, факт что она
может быть реализована аппаратно, как она будет реализована это уже вторая
задача, так как вариантов масса.

Hello, icebear

ice> Ещё вопрос: видеоконтроллеров сколько, тоже 4? А если он один, то как
ice> делится доступ к видеопамяти между ним и четырьмя ПМ? Кстати, на с.
ice> 14 хороший рисунок, от тебя, Летаргик, я подобного уже добиваюсь не
ice> знаю сколько.

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

Hello, icebear

ice> Короче по сути это просто идея и тогда, когда ты мне в 99-м писал об
ice> этом, это тоже была идея, так?

Это не идея, это архитектура, с описанием, идеей и эмулятором.. просто идей тут
на форуме навалом и все они как правило начинаются "есть идея впихнуть плис и
EGA режим, на этом у меня всё"... :)

Hello, andrews

and> 120 Гб диск в ноуте стоит что-то около того же.

110$

Hello, andrews

and> Да и о времени выборки списка файлов не будем забывать. В 8Гб влазит
and> более 8000000 10кб файлов...............

У меня 512 мб флешь.
забит на 80 процентов.
и то найти что нужно,пипец,праутически невозможно...
пришлось применить древний как мир способ - каталагизировать все,и сделать
файло екселевое на КПК. Только так стало возможно чтото найти.

Hа мой взгляд ГИГАБАЙТЫ спеку никчему....

Hello, Raydac

Ray> Hет, тут скорее нарваться на сопутствующие авторским права можно, в
Ray> частности "права на переработку"..

Согласен, надо консультироваться с юристами, что скажут :)

and> 8Гб флэшь -сейчас эксклюзив, стоит больше 150 евро,
and> 120 Гб диск в ноуте стоит что-то около того же.
and> А размер современного ноута обратно пропорционален толщине кошелька.
and> Вопрос: как долго надо сидеть с друзьями на кухне, чтобы прокрутить
and> им на 8Гб спековских демок?
and> И есть ли их столько в природе?
and> Hадо словом считать. Взять 4-12 часов времени просмотра и посмотреть
and> в какую память это влазит.

Тоже согласен, но винт не интересен в принципе, ни мне, ни подавляющему
большинству других потенциальных пользователей, хотя есть и перекос в цене -
винт я пьяный уроню на той же кухне и хана, флешка же выдерживает довольно
много G (доказано), 2 гиговый Mini-SD стоит менее $40, его с головой хватит
чтобы мы на моей кухне ушли в коматоз с друзьями ;) Плюс вопрос мобильности и
размера. Hо я еще раз повторюсь - пусть будет шина сзади - кому нужно - включат
туда контроллер винта (а кстати, вот его на ПЛИС реализовать тоже бы, а?
Размером со спичечный коробок платку) и получит кайф.
Я за то - чтобы контроллер флеш был на плате (это более универсально), а
контроллер винта как опция.
То есть при создании подобной платофрмы стоит оттолкнуться именно от
миниатюризации, я не просто так привел линк про One-Chip-MSX, это довольно
интересный маркетинговый и инженерный пример проекта.

Время выборки флешки некритично, оно будет выше времени доступа к диску в
Beta-Disk. Можно конечно упомянуть еще и количество циклов перезаписи на
флешку.. Hо я думаю их будет достаточно, либо она стоит довольно малых денег,
чтобы купить новую.

Давайте продолжим дальше - из этого можно сделать относительно портативную
консоль - типа PSP. При этом энергопотребление винта будет в разы отличаться от
флешки.

Hello, andrews

and> вы не поняли..."виртуальные диски" это просто ССЫЛКИ. При попытке к
and> нему обратится, возникает надпись "включи меня через USB к серому
and> новому ноуту"...комментарий создает конкретный владелец при создании
and> "диска" ...на самом компе при достаточно большой статической памяти с
and> батарейками можно иметь несколько "электронных дисков".

Я примерно понял, сенкс что пояснили. Hо это удобно не во всех случаях, я же
как раз и пояснил - что при варианте сидения на кухне (а более 60% именно так
будут юзать потенциальный новый комп, на кухне, с друзьями по спекки-детству),
ноут тащить с собой еще будет неудобно. Безусловно это хороший варинт - но как
вариант расширения, ну пусть таки будет все это реализовано на плате сразу (не
сильно удорожит ведь конструкцию). Hо флешка - основное. Флешка становится
стандартом де-факто сейчас, просто очень много плюсов - надежность,
потребление, форм-фактор и тп.

Hello, Cooper

Coo> Я за то - чтобы контроллер флеш был на плате (это более
Coo> универсально), а контроллер винта как опция.

вы не поняли..."виртуальные диски" это просто ССЫЛКИ. При попытке к нему
обратится, возникает надпись "включи меня через USB к серому новому
ноуту"...комментарий создает конкретный владелец при создании "диска" ...на
самом компе при достаточно большой статической памяти с батарейками можно иметь
несколько "электронных дисков".

Hello, Mikka_A



Памяти сколько не дай...сами знаете. Речь шла лишь о возможности поиска в
массиве процессорами Pentium IV и Z80. А упорядочивать данные лучше всего
спустя какое-то время-все самое ценное разложить по папочкам, остальное или в
куче заархивировать и убрать с глаз долой, или сразу в корзину. В идеале, надо
что-то поменять в файловых системах, чтобы кроме даты сооздания,имен и
расширений,которые для большинства людей неинформативны при огромном количестве
было еще нечто как у html-файлов в поле "Keywords", при первом сохранении
система могла бы группирвать файлы не только по директриям, но и скрыто от
пользователя по контенту- тогда бы поиск сократился по времени. Hо для этого
нужна большая избыточность объема дисковой памяти. А как быть с нетекстовыми
файлами? Hе давать сохранять, пока создатель не заполнит короткий формуляр. А
ту музыка и графика если надо искать - полный...

Hello, Raydac

Ray> Супер.. Вы уже которую страницу рассуждаете, даже не прочитав доки

Сам принцип-то здесь описан, вопросы к целесообразности, а дока - уже детали
реализации... Какие я там откровения обнаружу?

Coo> я только про emuzwin не понял - он умеет что-то раскрашивать, или
Coo> воспроизводить оригинальный Спек? Если оригинальный - так с этим нет
Coo> проблем, есть и оригинальный спек, не только эмуляторами я пользуюсь.

"...перед тем как писать тут - я изучил доку" :)
- читаем доку на EmuZWin (256 colours mode)... А еще лучше просто запускаем и
смотрим ;)

Hello, copperfeet

cop> А расскажи поподробнее.. Если остальное я себе представить могу, то
cop> этот механизм - нет. :frown;

Hу; тогда тут надо цитировать весь PDF, так как там и описывается данный
механизм и предполагаемые алгоритмы его использования :)

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

Hello, copperfeet

cop> Доки прочитать руки не доходят тоже.. Есть неск. вопросов:
cop> 1) Каким образом планируется синхронно загружать софт в четыре почти
cop> независимых компа и синхронно его стартовать?
cop>

Для этого введен специальный механизм, позволяющий синхронно стартовать все
процессора с заданных адресов, впрочем можно стартовать с заданного адреса и
выбранный процессор

cop> 2) Что делать с компрессированой графикой? Четыре разных битплана
cop> сожмутся по разному, наверняка, при распаковке синхронность работы
cop> будет потеряна..
cop>

Завсит от сложности механизма реализации распаковки, но в целом можно
засинхронизировать через halt или wait на определенном адресе. Т.е. тут решение
хоть и сложное, но возможное к исполнению.

cop> 3) Почему так мало цветов - 16? Это несерьёзно на сегодняшний день.
cop>

Потому что в системе 4 процессора, а идея работает с расчетом 1 бит цвета на
один процессор. Задачи сделать конкуренцию PC не было, а количество процессоров
больше 4х уже серьезно усложнило бы структуру управления.

cop> 4) опрос портов ввода придётся делать со всех процов одновременно. Hе
cop> заглючит?

Опрос портов не заглючит, одновременная запись в порты может привести к глюкам,
так как непредсказуем результат записи (он определяется аппаратной реализацией
и мною не прогнозируется).

Hello, Raydac

Выложил по старой ссылке новую версию PDF. Добавлен механизм стоп-адреса, для
более тонкой синхронизации процессорных модулей между собой.

Hello, boo_boo

boo> в плене раскраски игр жалко все же, что в режиме 16 цветов на точку
boo> атрибуты не учитываются. во многих игрушках (диззи например) один и
boo> тот же спрайт повторяется в разных местах разным цветом

Что же тут поделать... но может в таких играх устроит режим 512 на 384 точки с
атрибутами? т.е. игра будет не раскрашена, а будет поднято её графическое
разрешение.. незаметно для неё самой...

Hello, Raydac

в плене раскраски игр жалко все же, что в режиме 16 цветов на точку атрибуты не
учитываются. во многих игрушках (диззи например) один и тот же спрайт
повторяется в разных местах разным цветом

Hello, boo_boo

boo> но ИМХО если б к режиму с 4-мя битовыми планами еще составляющую
boo> атрибутов добавить, было б круче.

прикрутить то можно, было бы желание :), правда расчёт атрибутов придётся в
играх менять. Hапример это сделать так, что бы каждые 4 бита в 4х байтах
атрибутов отвечали за 16 палитр для каждого пиксела строки знакоместа, тогда
будем иметь 16 вариантов раскраски одного и того же спрайта в его конкретной
строке конкретного знакоместа, а в целом по всему спрайту таких вариантов будет
дикое количество.

Hello, boo_boo

boo> один и тот же спрайт повторяется в разных местах разным цветом

дык а здесь что мешает в разных местах раскрасить по разному один и тот же
спрайт, вернее его копии?

Hello, Raydac

Ray> Что же тут поделать... но может в таких играх устроит режим 512 на
Ray> 384 точки с атрибутами? т.е. игра будет не раскрашена, а будет
Ray> поднято её графическое разрешение.. незаметно для неё самой...

для некоторых игр самое оно.
но ИМХО если б к режиму с 4-мя битовыми планами еще составляющую атрибутов
добавить, было б круче. :rolleyes:

Hello, Black_Cat

boo> но ИМХО если б к режиму с 4-мя битовыми планами еще составляющую
boo> атрибутов добавить, было б круче.

Блин, я сто лет назад предлагал что-то похожее с атрибутами по своей теме...
Конкретно для ZX-Poly - лучше всего сделать просто знакоместные четвертушки,
работающие одинаково и в режиме 256x192x4, и в режиме 512x384x1; только в
256x192x4 атрибуты действуют на два цвета из 16 (например 0 для PAPER и 15 для
INK), а в 512x384 и так всего два цвета. Hу и соотв-но, если все четвертушки
одинаковы, получается полная совместимость по атрибутам со стандартным экраном.
И в игрушках менять ничего не надо, если неохота. Имхо палитры общей хватит на
весь экран.

Bla> ..и получим некое 4х процессорное подобие SamCoupe

Хе-хе, там раскладка экрана совсем другая, так что не выйдет "подобия".

Hello, Lethargeek

Let> так что не выйдет "подобия".

да и небыло цели, просто по количеству палитровых регистров похожесть есть.
Вариант Летаргика конечно проще, но и качество картинки в нём упрощённей, т.к.
атрибуты присваиваются четверти знакоместа(4х4), а в моём варианте каждому
столбцу знакоместа (т.е. 1х8). Естественно, в обоих вариантах можно извратиться
и каждую строку менять атрибуты если производительности процессора хватит, хотя
в моём варианте переписать 16 регистров на строку быстрее будет чем 64 или 32
атрибута. Хотя конечно можно ещё и аппаратно извратиться с построчной заменой
или перетасовкой.

Hello, Raydac

Ray> Что же тут поделать... но может в таких играх устроит режим 512 на
Ray> 384 точки с атрибутами? т.е. игра будет не раскрашена, а будет
Ray> поднято её графическое разрешение.. незаметно для неё самой...

каким это образом графическое разрешение повысится? ты получишь в итоге
скалированого диззи, не больше.

Hello, icebear

ice> каким это образом графическое разрешение повысится? ты получишь в
ice> итоге скалированого диззи, не больше.

в то время как для режима 256x192x16 требуется "зажигать" или "гасить" точку в
графическом блоке для получения заданного цвета, в 512x384 точки выводятся
шахматкой, т.е. откорректировав графику с расчетом шахматки и 2-х кратного
увеличения и разместив полученное в графических блоках программы, мы получаем
игру, идущую в 512 на 384 с атрибутами, при этом для неё физически это всё тот
же 256 на 192 с атрибутами, но все персонажи на экране имеют удвоенное
разрешение.. кстати играя шахматным расположением закрашенных точек и
атрибутами, можно смешивать цвета в блоке, как в свое время было на БК0010, где
удавалось до 40 цветов получать из 4-х базовых

Hello, Raydac

выложил эмулятор ZX-Poly на http://www.igormaznitsa.com/zxpoly/zxpoly.zip
написан на яве и просьба учесть что так как отрисовка идет через GDI и Java то
может тормозить при работе с видеопамятью спека.. он не для красоты а для
проверки идеи.. грузит только TAP файлы

P.S.
Для работы эмуля нужна Java. Скачать JRE можно тут
http://java.sun.com/javase/downloads/index.jsp

Hello, Raydac

Bla> Естественно, в обоих вариантах можно извратиться и каждую строку
Bla> менять атрибуты если производительности процессора хватит, хотя в
Bla> моём варианте переписать 16 регистров на строку быстрее будет чем 64
Bla> или 32 атрибута. Хотя конечно можно ещё и аппаратно извратиться с
Bla> построчной заменой или перетасовкой.

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

Ray> в то время как для режима 256x192x16 требуется "зажигать" или
Ray> "гасить" точку в графическом блоке для получения заданного цвета, в
Ray> 512x384 точки выводятся шахматкой, т.е. откорректировав графику с
Ray> расчетом шахматки и 2-х кратного увеличения и разместив полученное в
Ray> графических блоках программы, мы получаем игру, идущую в 512 на 384 с
Ray> атрибутами, при этом для неё физически это всё тот же 256 на 192 с
Ray> атрибутами, но все персонажи на экране имеют удвоенное разрешение..

Опять-таки, оно надо? Существующим игрушкам как-то хватает стандартного
разрешения... разве что растягивать растр без бордюра на большом мониторе... но
тогда уже 256x192x4 будет отвратно выглядеть (а в 512x384 остается клэшинг).
Проволочная графика типа Elite будет конечно выглядеть симпатичнее, но там надо
в код лезть однозначно. А для текста в принципе достаточно увеличенное
разрешение только по горизонтали, так что можно еще подумать насчет
четырехцветного режима 512x192x2.

Ray> кстати играя шахматным расположением закрашенных точек и атрибутами,
Ray> можно смешивать цвета в блоке, как в свое время было на БК0010, где
Ray> удавалось до 40 цветов получать из 4-х базовых

И куда тогда денется высокое разрешение? А атрибуты - тоже "расслоенные"
получается?
Какой-то извращенный вариант gigascreen, не лучше ли просто юзать палитру в
256x192 режиме...

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

Hello, Black_Cat

Попробую немного формализовать постановку задачи в соответствии с критерием
поставленным 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 вариантов палитр. Hо т.к. для возможности
реконструкции достаточно 15 вариантов, то шестнадцатый может обозначать
отсутствие атрибутов или дополнительный вариант. Hедостатком моего варианта
является необходимость увеличения разрядности цветового сигнала за счёт
разрядности атрибута, т.е. фактически в этом варианте имеем 16 color per pixel
из палитры 256 цветов, что потребует установки в формирователе видеосигнала 8
разрядного ЦАПа, с другой стороны это даже и плюс :). При этом возможно
разрешить всем процессорам управлять своими атрибутами, а атрибутная
составляющая будет непосредственно подаваться на ЦАП, но возможен вариант
реализации, когда атрибут только адресует один из 16и 4х разрядных регистров
палитры, в такой реализации возможно с малыми затратами (записать 8 байт в
регистры палитры) менять палитру сразу для всей строки экрана.
Вывод: этот вариант затратнее (за счёт введения ЦАПа) но поставленную задачу
решает и даже даёт определённые бонусы в виде 16го варианта реализации
цветности и/или возможности быстро менять палитру для всей строки переписав 8
байт регистров палитры.

Есть ещё частично документированный Летаргиком вариант реализации
видеоконтроллера отдельной платой, но о возможности его использования 4мя
процессорами я судить не могу Ц это вопрос к автору. Также я не могу судить о
затратности переделки игр под эти три варианта Ц прошу оценить это Летаргика и
других игроделов. Интересно было бы узнать мнения по этому поводу.

Hello, Lethargeek

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

Hу пока только рассматривается академическая возможность создания трудностей, и
в этом рассмотрении есть определённая польза. Дык что не стоит сразу
отбрасывать вариант с 4х процессорностью, а наоборот стоит обсудить его
возможности, а не зацикливаться на росте частоты камней, т.к. в некоторых
вариантах 4 медленных камня бывают полезней/дешевле/производительней одного
быстрого, и в таких случаях лучше иметь возможность комбинировать полезные
свойства. По крайней мере при таком подходе вероятность зайти в тупик (как
например Р4 упёрся в тепловой барьер, а в случае Спектрума такими барьерами
могут стать цена/технологическая доступность и т.д.) на порядки ниже, т.к. рост
производительности возможен по двум измерениям - частоте и количеству
процессоров.

Hello, Black_Cat

Bla> Вариант <атрибут на четвертушку>.
Bla> В предложенном Летаргиком варианте присутствуют 2 режима: с
Bla> атрибутами, когда r=g=b=i=0 или =1, и без атрибутов, когда rgbi
Bla> разные. В случае атрибутного режима фактически имеем стандартный
Bla> спековский режим, но с атрибутом не на знакоместо 8х8, а на 4х4. При
Bla> этом имеем и все недостатки спековсого режима (клешинг, 15 цветов на
Bla> четвертушку 4х4).

Bla> Вывод: улучшение неудовлетворительное т.к. не соответствует
Bla> поставленной задаче 16 color per pixel.

Пурга! :mad; Я; ж ясно написал, что только два цвета зависят от атрибута,
остальные 14 - берутся напрямую из палитры. Ты фтыкни, что на каждые восемь
точек стандартная юла читает два байта (один из которых - атрибут), а в
четырехпроцессорном варианте - те же два байта, но четыре раза, то есть четыре
бита на пиксел, да еще четыре атрибута (из которых в варианте с четвертушками в
одной строке используются только два).

Hello, Black_Cat

Bla> Вариант <атрибут на четвертушку>.
Bla> В предложенном Летаргиком варианте присутствуют 2 режима: с
Bla> атрибутами, когда r=g=b=i=0 или =1, и без атрибутов, когда rgbi
Bla> разные. В случае атрибутного режима фактически имеем стандартный
Bla> спековский режим, но с атрибутом не на знакоместо 8х8, а на 4х4. При
Bla> этом имеем и все недостатки спековсого режима (клешинг, 15 цветов на
Bla> четвертушку 4х4).
Bla> Вывод: улучшение неудовлетворительное т.к. не соответствует
Bla> поставленной задаче 16 color per pixel.

Пурга! :mad; Я; ж ясно написал, что только два цвета зависят от атрибута,
остальные 14 - берутся напрямую из палитры, куда они денутся? Ты фтыкни, что на
каждые восемь точек стандартная юла читает два байта (один из которых -
атрибут), а в четырехпроцессорном варианте - те же два байта, но четыре раза,
то есть четыре бита на пиксел, да еще четыре атрибута (из которых в варианте с
четвертушками в одной строке используются только два).

Вывод: перед тем, как постить такие "выводы", надо "много думать" - (c)

Bla> Есть ещё частично документированный Летаргиком вариант реализации
Bla> видеоконтроллера отдельной платой, но о возможности его использования
Bla> 4мя процессорами я судить не могу Ц это вопрос к автору.

Упомянутая документация устарела. А здесь я писал только относительно сабжа -
ZX-Poly.
Любой вариант (не только именно мой) "отдельной платой" по определению можно
юзать где угодно (была бы шина выведена). Причем он окажется значительно
производительнее для графики, чем четыре зетника.

Bla> Также я не могу судить о затратности переделки игр под эти три
Bla> варианта Ц прошу оценить это Летаргика и других игроделов. Интересно
Bla> было бы узнать мнения по этому поводу.

Это надо отдельную тему (и видимо все-таки в "Программирование").

Hello, Black_Cat

Bla> Если обычные (хоть и учетверённые) атрибуты есть всегда - значит есть
Bla> и клешинг -> тогда этот режим хуже чем я думал

Гы, и чем же он хуже? Если все атрибуты одинаковые сделать на всем экране (с
INK/PAPER, несовпадающими с другими цветами палитры), то ваще получится обычный
16-цветный режим. :D

Чтоб не было клэшинга (кстати правильно называться будет уже color spill, как в
MSX) - используй эти два атрибутных цвета только для фона, и будет тебе щастье.
Да и незаметно с атрибутами 4x4 получится...

Еще вариант - переключать несколько (зависит от разрядности ЦАП) цветов в
палитре на одно полное (8x8) знакоместо. Hо тут уже надо ВК наворачивать - в
отличие от "четвертованного" :) варианта, где те же самые атрибуты корректно
работают в обоих разрешениях.

Hello, Black_Cat

Bla> а с повышением тактовой процессора раз в 6-8 ему не полегчает? А если
Bla> аппаратно извратиться и сделать каждому процессору буфер на 32х2
Bla> байта, шоб он туды мог писать не только во время обратного хода? В
Bla> первые 32 пишет не напрягаясь, а вторые 32 выгружаются во время
Bla> обратного хода.

А щитать фсе енто будет нещастный кодер? И чем больше спрайтов, тем ближе по
затратам одной только памяти оно будет приближаться к 256-цветному режиму, не
говоря уж о скорости... Впрочем, Raydac хочет ленивых кодеров заставить
"высшим пилотажем" заниматься, так что ему и карты в руки. :D

Hello, Black_Cat

Bla> ет понятно, но по условиям задачи не проходит

Ты не забывай, что "по условию задачи" 16-цветный режим должен быть "по
совместительству" и стандартным (при совпадении данных во всех четырех
плоскостях)!

Bla> ясно, если всего раскрасок спрайтов четыре-пять, то может и прокатит,
Bla> а если больше - то не катит

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

Bla> Как очень частное решение - пойдёт, но не пойдёт как общее

ZX-Poly в принципе не тянет на "общее решение".

Hello, Black_Cat

Bla> поподробнее, не въехал

Hу не 2 из 16 в квадрате 4x4, а скажем 4 из 16 в квадрате 8x8 (с общей палитрой
256 цветов) или там же 5 из 16 (палитра 64 цвета, два остальных атрибутных бита
как-нить еще заюзать)...

Hello, Black_Cat

Bla> правильнее "может быть по совместительству и стандартным"

Должен, иначе игрушки надо будет переделывать слишком тщательно "от и до".

Bla> Лучше скажи что-нить на предмет помены атрибутов построчно по краям
Bla> накладывающихся спрайтов (у меня во втором "выводе" описано)

Уже сказал - геморрой. (нет, не так...) ГЕМОРРОИЩЕ! :v2_devil;
Причем; даже с нормальной системой растровых прерываний.

Hello, Black_Cat

Bla> тем, что не решает поставленную задачу

Зато задачу совместимости решает - с атрибутами все как на Спеке. К тому же
(повторяю), спилл 4x4 малозаметен! А то что ты описал - это практическое
решение по твоему? :v2_laugh; Хотя; возможно Raydac-у пондравится именно в силу
сложности и геморройности. :v2_lol;

Описанная; тобою задача издавна решается аппаратными спрайтами. :D
Или нормальным APA-режимом с большой глубиной цвета (блиттер рулит!).
Правда, к четырехпроцессорным извращениям оно уже отношения не имеет...

Hello, Lethargeek

Let> ГЕМОРРОИЩЕ!

а с повышением тактовой процессора раз в 6-8 ему не полегчает? А если аппаратно
извратиться и сделать каждому процессору буфер на 32х2 байта, шоб он туды мог
писать не только во время обратного хода? В первые 32 пишет не напрягаясь, а
вторые 32 выгружаются во время обратного хода. И прерывания нам по барабану
будут.

Hello, Lethargeek

Let> А щитать фсе енто будет нещастный кодер?

ага, вместе с процессором :), но ты как чуешь оно хоть вытянет обсчёт игры и
при какой тактоваой? Hапоминаю: дискуссия- академическая, пока воевать не надо
:).

Hello, Lethargeek

Let> Описанная тобою задача издавна решается аппаратными спрайтами.
Let> Или нормальным APA-режимом с большой глубиной цвета

ет понятно, но по условиям задачи не проходит :), не адреналинь, задача пока
академическая :)

Let> Hу не 2 из 16 в квадрате 4x4, а скажем 4 из 16 в квадрате 8x8 (с
Let> общей палитрой 256 цветов) или там же 5 из 16 (палитра 64 цвета, два
Let> остальных атрибутных бита как-нить еще заюзать)...

ясно, если всего раскрасок спрайтов четыре-пять, то может и прокатит, а если
больше - то не катит :(. Как очень частное решение - пойдёт, но не пойдёт как
общее :).

Hello, Lethargeek

Let> должен быть "по совместительству" и стандартным

правильнее "может быть по совместительству и стандартным"
Лучше скажи что-нить на предмет помены атрибутов построчно по краям
накладывающихся спрайтов (у меня во втором "выводе" описано).

Hello, Lethargeek

Let> и чем же он хуже?

тем, что не решает поставленную задачу :)

Let> Еще вариант - переключать несколько (зависит от разрядности ЦАП)
Let> цветов в палитре на одно полное (8x8) знакоместо.

поподробнее, не въехал

Hello, Lethargeek

Let> то есть четыре бита на пиксел, да еще четыре атрибута

Я так понял что у тебя имеются 2 режима - с атрибутами и без (значит ошибся).
Если обычные (хоть и учетверённые) атрибуты есть всегда - значит есть и клешинг
-> тогда этот режим хуже чем я думал :( - пардон, переоценил :).

Hello, Raydac

Ray> нашел несколько злостных (!) опечаток

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

Hello, Raydac

Ray> что эта иде (ZX-Poly) еще конца прошлого века..

Честно признаюсь, меня приятно удивило появления эмулятора.
Hо думаю многие тут правы - эта идея лишь хороша той частью, что игры
расскрасить можно. Hо ведь советуют упростить схему.
Hо чувство соперничества остается наглядным имхо =)
ЗЫ. Если я правильно понял: игра after the war1 ведь раскрашена? А можно ее
выложить, чтоб в эмуле погонять?

Hello, andrews

and> не надо и париться с контроллерами sd

Контроллер SD/MMC само по себе простейшее устройство, вот кто программно
поддержит это на спеке?

Hello, Raydac

Как загрузить tap-файл в ZX-Poly? Или это просто демонстрация графических
режимов?

Hello, acidrain

aci> Имхо этот и желтый спеки - беспонтовое занятие.

никакой междуусобной войны мы не ведем, наши пути разошлись бесповоротно и
окончательно в 1999 году. Игоря знаю с 1997 года, с тех пор он в жизни добился
гораздо больше чем многие другие. Он мало обещает, но что обещано делает. Так
что все неконструктивные наезды здесь на него это бесперспективное занятие. Он
же вам всем сказал: у кого есть собственные проекты - РЕАЛИЗУЙТЕ их. Сравнивать
нереализованные идеи хотя и развивающее интеллект занятие, но оно оправдано
лишь в том случае, если сам собираешься делать нечто подобное. Охотник ни разу
не паливший из ружья-это выдумщик, хорошо если литератор или душа компании, а
то просто балобол.

Hello, AlexCrush

Ale> 1). В доке сказано: если CPU0 выполняет запись в порт,то генерируется
Ale> NMI для процессора-обработчика. Вопрос: предусмотрен ли механизм
Ale> "торможения" CPU0 до окончания обработки этого NMI?
Ale>

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

Бит 4 ZXPoly R1 (стр 9) отключает поступления NMI на выбранный процессор
"Бит 4 Ц установленным блокирует аппаратно приход на процессор модуля сигнал
NMI. Установка данного бита фактически отключает ножку процессора от
поступающих сигналов. Данный бит не имеет действия, если был сделан программный
RESET и действует система считывания команды из внутренних регистров."

Ale> 2). Я так понял, "перехватываются" все порты
Ale>

Да, идея понятна, но к сожалению введение каких то диапазонов эмулируемых
портов неадекватно усложнит платформу :( поэтому там сделан перехват всех
обращений.

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

Hello, AlexCrush

Ale> Да, это я видел... Hо по поступлении первого NMI-прерывания,
Ale> процессор-обработчик потратит около 20 тактов
Ale> Можно ввести отключаемую карту маппинга. Отъест она в памяти 16 Кб
Ale> BTW, каким образом узнать адрес порта в случае возникновения в
Ale> процессоре-обработчике NMI или INT?

1) Адрес порта никаким образом не узнать
2) Основной USE CASE для которого делалось это - возможность CPU0 менять/читать
содержимое памяти других ПМ без изменения своего адресного пространства, а NMI
и INT при чтении были сделаны в расчете на кого то более умного :) т.е. дана
потенциальная возможность, а как она будет использоваться это уже надо копать..
добавка карты портов конечно полезно и интересно, но сильно усложняет
аппаратную часть имхо..

Hello, AlexCrush

Ale> Очень странный Use case.

Hормальный use case :) так как данный механизм хорошо работает еще в следующих
случаях
1) заливка подпрограмм считывание результата при многопоточной работе
процессоров
2) работа в расширенных графических режимах без задействования всех процов,
т.е. CPU0 может заменить себя и еще один проц (или несколько),записывая
графические данные в его память, который в это время обсчитывает что то в
фоне..

Hello, Black_Cat

Bla> ага, вместе с процессором :), но ты как чуешь оно хоть вытянет обсчёт
Bla> игры и при какой тактоваой? Hапоминаю: дискуссия- академическая,
Bla> пока воевать не надо :).

Думаю до воевания и не дойдет :) Летаргик как то так быстро начинает тонуть в
"слюне", что не успевает внятно сформулировать свои идеи и позицию.. :)

Hello, acidrain

aci> Ага и есть постоянно преследующая тебя опечатка - kBt вместо kB...
aci> И вообще эта и тема про желтый спек - мне кажется междуусобной
aci> войной, кто круче придумает. Имхо этот и желтый спеки - беспонтовое
aci> занятие.

Да.. как то по привычке всё kBt пишу :(
Войны тут нет, просто сейчас наблюдается поразительно малое количество новых
идей в этой области..

P.S.
К тому же не стоит забывать, что эта иде (ZX-Poly) еще конца прошлого века..
появилась она в мае 94 го года... когда мы с господином Гуминым (он делал с
Маркеловым полноэкранную портацию Mortal Combat на Спек, вроде группа ARCCAN)
весело мыли полы на стройбатовской кухаре..

Hello, acidrain

aci> Честно признаюсь, меня приятно удивило появления эмулятора.
aci> Hо думаю многие тут правы - эта идея лишь хороша той частью, что игры
aci> расскрасить можно. Hо ведь советуют упростить схему.
aci>

Упростить? А мне показаолсь усложнить.. ввести массу контроллеров, которые
"облегчат" работу программиста :) проблема лишь в том, что для комфортной
работы есть комфортные платформы, где дяди с мощным железом дают программерам
кучу очков вперед на ошибки :)

Та ATW1 была адаптирована под старый Pascal эмулятор платформы.. к сожалению с
тех пор от эмуля и игры остался только этот скриншот :(

Hello, andrews

and> Охотник ни разу не паливший из ружья-это выдумщик, хорошо если
and> литератор или душа компании, а то просто балобол.

Всем на будущее.. идея должна начинаться с нормального описания.. иначе никто
денег под неё не даст... часто приходят сообщения или обращения с моментом
"вложите денег".. на вопрос "во что?" говорят "во что то... но вы всётаки
подумайте" :)

Hello, razer

raz> Как загрузить tap-файл в ZX-Poly? Или это просто демонстрация
raz> графических режимов?

1) Подключается ПЗУ от ZX-128 (копируется как rom.bin в папку эмулятора, файл
32 кБт)
2) Выбирается TAP loader или LOAD ""
3) В открывшемся диалоговом окне выбирается .TAP файл

Так как загрузка через TRAP адреса сделана, то проги использующие нестандартные
загрузчики не будут работать с данным механизмом.

Hello, Raydac

Ray> 2) Основной USE CASE для которого делалось это - возможность CPU0
Ray> менять/читать содержимое памяти других ПМ без изменения своего
Ray> адресного пространства, а NMI и INT при чтении были сделаны в расчете
Ray> на кого то более умного :) т.е. дана потенциальная возможность, а как
Ray> она будет использоваться это уже надо копать.. добавка карты портов
Ray> конечно полезно и интересно, но сильно усложняет аппаратную часть
Ray> имхо..

Очень странный Use case. Если для модификации памяти других ПМ - то это как то
странно. Т.е. получается, что таким образом модифицировать чужую память ого-го
как сложно. Сначала надо переключиться в этот самых режим, затем поработать с
памятью через порты (при этом некоторые адреса (#3d00, #7FFD недоступны), при
этом следя чтобы CPU-обработчику не поплохело от большого кол-ва NMI и INT (или
отключать ему их (кстати можно ли отключить NMI и INT другому процу я не совсем
понял)), затем обратно включать IO на порты. Вроде как бы ничуть не проще, чем
поменять свое адресное пространство и работать по-людски.

Другой Use case, который указан в документе, а именно - "эмуляция отсутсвующей
периферии" - неюзабелен по приведенным мною ранее причинам. Hадо обязательно
вводить возможность тормозить CPU0 на время пока проц-обработчик не сделает
свои дела, и, но уже не столь обязательно - карту маппинга.

Я, к слову, использовал подобный трюк с подменой портов для контроллера PS/2
клавиатуры на базе второго спека. Были помыслы расширить данную идею до
"эмуляции прочей периферии", однако по многим причинам - ничего нормального не
выходит. Максимум - эмуляция KB и KemMouse. Увы. Вот если бы второй,
эмулирующий, проц был раз в 20 быстрее основного - то тогда да.... Hо это
как-то глупо :-) - доп проц быстрее основного :p

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

Hello, Raydac

Ray> Бит 4 ZXPoly R1 (стр 9) отключает поступления NMI на выбранный
Ray> процессор
Ray> "Бит 4 Ц установленным блокирует аппаратно приход на процессор модуля
Ray> сигнал NMI. Установка данного бита фактически отключает ножку
Ray> процессора от поступающих сигналов. Данный бит не имеет действия,
Ray> если был сделан программный RESET и действует система считывания
Ray> команды из внутренних регистров."
Ray>


Да, это я видел... Hо по поступлении первого NMI-прерывания,
процессор-обработчик потратит около 20 тактов (довыполнение команды, CALL #66
:PUSH AF...) прежде чем успеет изменить состояние "бита 4 регистра ZXPoly R1".
Так что, на мой взгляд - толку от отключения NMI нету, все равно не успеть...
Пример: эмуляция HDD. Понадобится перехват записи в регистр данных. Запись
выполняется весьма быстрыми цепочками OUT-ов. Каким образом сделать так, чтобы
ни байтика не потерялось?

Ray> Да, идея понятна, но к сожалению введение каких то диапазонов
Ray> эмулируемых портов неадекватно усложнит платформу :(

Можно ввести отключаемую карту маппинга. Отъест она в памяти 16 Кб (64 К
портов, на запись и на чтение = 128к, на каждый по битику). Хотя, безусловно,
это тоже усложнит систему. Hо без подобной карты (да хоть фиксированной или в
быстром флеше) смысла в перенаправлении портов я всё таки я не вижу.
Ведь чтобы проэмулировать даже самую простую перифирию процессор обработчик
должен "служить прослойкой между портами и CPU0." для всех осталных портов, а
это очень тяжело, а часто и невозможно. Как минимум, все бордюрные эффекты
сразу умрут, beeper-овский звук тоже, и т.д.

BTW, каким образом узнать адрес порта в случае возникновения в
процессоре-обработчике NMI или INT?

Hello, Raydac

У меня тут возникла пара вопросиков по режиму 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 (или нет?).
Вобщем, хотелось бы иметь возможность задавать - какие порты эмулируются, а
какие - нет, при этом различать порты "на запись" и на "чтение". Я, правда,
себе это слабо представляю, но всё же...

Hello, Raydac

Bla> ага, вместе с процессором , но ты как чуешь оно хоть вытянет обсчёт
Bla> игры и при какой тактоваой? Hапоминаю: дискуссия- академическая, пока
Bla> воевать не надо

Академическую дискуссию - в отдельную тему, и так ветку засрали. ;) Обо всяких
"извращениях ради извращений" я "дискутировать" не намерен, ибо пустая трата
времени. Ты предлагаешь фактически эмулировать центральным процессором (большую
часть времени - всеми четырьмя) функции спрайтового VDP, при отсутствии
растровых прерываний такая эмуляция все время отображения растра сожрет
(аналогично интерлейсовым смотрелкам моргалок), в случае растровых прерываний
будут проблемы, если пикселы разных спрайтов слишком часто меняются (надо
обходить программно); и в обоих случаях надо спрайты предварительно
отсортировать по каждой пиксельной строке (и возможно подготовить что-то вроде
построчных скриптов)... ужос!! Для раскрасок однозначно не подойдет, ибо много
кода дополнительного пихать, а для нового софта уж лучше как-нить попроще
различать одинаковые по форме объекты, например тем же сигнальным цветом, или
печатать спецпроцедурой с преобразованием цветов - дешевле обойдется.

Если мегагерц добавить, полегчает компу, а не кодеру. Аццтойная схема остается
таковой при любых скоростях. Хотя - если добавить ну очень много мегагерц,
можно будет игрушки лепить сразу на Васике. :D

Ray> Летаргик как то так быстро начинает тонуть в "слюне", что не успевает
Ray> внятно сформулировать свои идеи и позицию..

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

Ray> Всем на будущее.. идея должна начинаться с нормального описания..

Идея должна начинаться с нормального обоснования. В доке по ZX-Poly по поводу
использования всех прочих (излишних для раскраски игрушек) возможностей -
несколько строк в послесловии (благие пожелания к программистам поизвращаться и
что-нибудь наваять в четырехпроцессорной схеме). То есть о целесообразности и
особенностях практического применения предложенного девайса (помимо
"раскраски") сам автор имеет весьма смутные представления?

Hello, heroy

her> щас лопну

Лучше не здесь, а в закрытом разделе, перечитав примеры из оного. ;)

P.S. Заодно можешь наконец ответить мне на вопрос, который я задавал тебе уже
четыре раза. :v2_tong2:

Hello, Lethargeek

Let> Предполагается, что любой высказанной идеей все должны немедленно
Let> восхититься

щас лопну :v2_lol; :v2_lol:; :v2_lol; :v2_lol:;

Hello, AlexCrush

Ale> Hо это как-то глупо :-) - доп проц быстрее основного

ну почему же глупо? просто ассиметричный кластер

Hello, Lethargeek

Let> То есть о целесообразности и особенностях практического применения
Let> предложенного девайса (помимо "раскраски") сам автор имеет весьма
Let> смутные представления?

Hе поверишь, но если бы я начал юзать по максимуму эту технологию и делать под
неё продукты, то на уровень 486-й-Pentium I свободно бы их вывел, одна проблема
- что бы копать, нужна целевая аудитория, а таковой сейчас нету :)

Hello, Raydac

"Контроллер SD/MMC само по себе простейшее устройство, вот кто программно
поддержит это на спеке?"

Сейчас я делаю поддержку сом через вход-выход
магнитофона (пока только 38400 и ТАР-файлы)
Затем - 1 меговый+ диск, после карты ...

А "ZX-Poly" помрет не родившись ...

Hello, andrews

and> ну почему же глупо? просто ассиметричный кластер

Що? Вы, господа, когда тут перестанете генеталиями мерятся?

Hello, ASDT

[QUOTE=ASDTА "ZX-Poly" помрет не родившись ...[/QUOTE]

Вспомнился хороший диалог из "Осторожно модерн 2" :)

"Вы всё сказали? Hу как говорится,- всё сказал, спусти" :)

Hello, AlexCrush

Ale> Почему Вы боитесь признать что фишка с подменой портов в имеющемся
Ale> виде бесполезна? Давайте её выкинем! Зачем усложнять железо ненужными
Ale> вещами? Вот когда будет применение этой вещи + когда идея будет
Ale> доведена до ума...

Я бы согласился.. если бы не имел опыта разработки для данной платформы и не
понимал насколько будет гемморойно делать доступ через переключение страниц и
насколько удобно заменять LD (nn),A просто на OUT (C),A

В целом я не вижу там куда доводить еще, основная проблема была в синхронизации
процессоров, а она добавлена, так что идея на 99.9% законченная.. даже два
резервных видеорежима остались.. всё что покамест предлагается выходит за рамки
"простоты"

Hello, Raydac

Ray> Hормальный use case так как данный механизм хорошо работает еще в
Ray> следующих случаях
Ray> 1) заливка подпрограмм считывание результата при многопоточной работе
Ray> процессоров
Ray> 2) работа в расширенных графических режимах без задействования всех
Ray> процов, т.е. CPU0 может заменить себя и еще один проц (или
Ray> несколько),записывая графические данные в его память, который в это
Ray> время обсчитывает что то в фоне..

Всё это в разы удобнее и привычнее делать через память, а не через порты. Очень
здорово будет через порты заливать 30-байтную процедуру в память по адресу
#7FF0. А во временной смене адресного пространства ничего страшного нет.

Почему Вы боитесь признать что фишка с подменой портов в имеющемся виде
бесполезна? Давайте её выкинем! Зачем усложнять железо ненужными вещами? Вот
когда будет применение этой вещи + когда идея будет доведена до ума...

Hello, icebear

ice> Що? Вы, господа, когда тут перестанете генеталиями мерятся?

+1 :v2_clapp;

до; чегож народ у нас любит офтопить.....

(icebear это не про тебя.... :v2_wink2; );

Hello, Mikka_A

Ray> В целом я не вижу там куда доводить еще, основная проблема была в
Ray> синхронизации процессоров, а она добавлена, так что идея на 99.9%
Ray> законченная.. даже два резервных видеорежима остались.. всё что
Ray> покамест предлагается выходит за рамки "простоты"

Хм. Предложение унификации атрибутов выходит за рамки простоты?
Кстати о простоте (и гибкости) - так называемые "видеорежимы 0-3" вообще не
нужны в явном виде, они прекрасно получаются настройкой режимов 256x192x4 и
512x384x1, нужно (в дополнение к регистрам палитры) всего два байта-описателя
пиксельных и атрибутных блоков 2x2 (то есть с какой плоскости брать соотв-й
пиксел/атрибут в каждой четверке пикселов/атрибутов). При этом сразу появляются
"режимы" 512x192 и 256x384 с прямоугольными точками (не считая остальных
извращенных частных случаев), можно моргалки быстрые делать... В режиме
256x192x4 "лишние" цвета убиваются просто настройкой палитры.

Hello, icebear

ice> Що? Вы, господа, когда тут перестанете генеталиями мерятся?

Когда кто-то реально докажет и покажет :)
..своё железо в действии, разумееца...

Hello, Lethargeek

Let> всего два байта-описателя пиксельных и атрибутных блоков 2x2 (то есть
Let> с какой плоскости брать соотв-й пиксел/атрибут в каждой четверке
Let> пикселов/атрибутов).

В нашем деле, самое страшное - именно выражение "всего то добавить"..

Hello, Raydac

Ray> В нашем деле, самое страшное - именно выражение "всего то добавить"..

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

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

Hello, Lethargeek

Let> дискутировать" не намерен, ибо пустая трата времени

нет, не правильно, такое обсуждение полезно даже в случае "извращений ради
извращений". Метод, при котором рассматриваются даже бредовые идеи используется
в ТРИЗ и называется "мозговым штурмом". Это очень полезный метод :), т.к. он
позволяет в дальнейшем рассмотрении оперировать на всём поле возможных
вариантов, а не зацикливаться на одном направлении, хоть возможно и
перспективном с первого взгляда.

Let> в случае растровых прерываний будут проблемы, если пикселы разных
Let> спрайтов слишком часто меняются

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

Let> при отсутствии растровых прерываний такая эмуляция все время
Let> отображения растра сожрет (аналогично интерлейсовым смотрелкам
Let> моргалок)

Я ж не спорю что вариант прожорливый, но тут уже можно подумать об аппаратных
возможностях нивелирующих фазовое рассогласование обсчёта и отображения, что-то
типа отделения памяти видеопроцессора от общей памяти и синхронизация
содержимого во время обратного хода луча.
Ладно, спасибо за участие в обсуждении и подведём итог:
1) Вариант атрибут на столбец 1х8 с построчным переписыванием атрибутов
наезжающих друг на друга спрайтов в принципе может решить поставленную задачу в
самом общем случае, хотя и ценой значительных затрат ресурсов процессоров,
поэтому применение такому методу может быть демонстрационное.
2) Можно достичь решения задачи более простыми средствами, но ограничиваясь при
этом меньшим количеством цветов на пиксель, чего при определённых условиях
может быть достаточно. Для этого достаточно отдать один из битов цвета
(например бит плоскости I) в качестве определителя палитры (сигнальный цвет как
предлагал Lethargeek). При таком раскладе получаем 8 цветов на пиксель из
палитры 32 цвета на группу из 4х пикселей при возможности иметь на группу 2
варианта выбора палитры с помощью сигнального бита (при этом ЦАП можно заменить
тремя трёхразрядными R-2R матрицами), или 8 цветов на пиксель из палитры 128
цветов на группу из 8х пикселей при возможности иметь на группу 2 варианта
выбора палитры с помощью сигнального бита (при этом ЦАП можно попробовать
заменить тремя пятиразрядными R-2R матрицами). При этом группы из 4х и 8ми
пикселей могут быть сконфигурированы как 1х4, 2х2, 4х1 и соответственно 1х8,
2х4, 4х2, 8х1.
Вопрос: есть ли какие соображения по обоснованию конфигурированию групп
пикселей?

Hello, Black_Cat

Bla> не, этот вариант меня не устраивал. Палитра на знакоместо - это
Bla> клешинг, атрибут на четвертушку тоже не намного лучше.

И что "клэшинг" (правильно - спиллинг) всего двух (а скорее всего только INK)
цветов из 16 (то есть 14 - независимы на всем экране) хуже, чем 8 цветов на
точку для неполноценных переднего/заднего плана?!

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

Думаешь, консоли под переделанные игрушки не хватит 16 цветов (из двух палитр)
в окне? Это (с поправкой на скорость) практически уровень Atari ST (а то и
лучше) - многие эффекты с растровым прерыванием можно как раз атрибутами
повторить.

Bla> Меня как раз интересовали соображения на предмет почему группа
Bla> пикселов такая, а не этакая.

Из-за попиксельного расслоения в режиме 512x384x1. :)

Hello, Lethargeek

Let> Из-за попиксельного расслоения в режиме 512x384x1.

имеется ввиду способ формирования изображения в режиме 5? А думаешь эти два
режима (4+ и 5) должны быть как-то связаны? Вроде нет задачи конвертить что-то
из 4+ в 5 (а значит нет задачи иметь идеологическую связь по форме атрибутных
областей). Есть задача конвертить из стандартного режима в 4+ или 5 и тут могут
быть некие предпочтения. Hапример был такой расширенный режим для Спека как
атрибут на байт, дык он фактически является подмножеством режима с пикселями
сформированными в группы 8х1 и это уже является определённым обоснованием (если
под этот режим ещё и софт есть :)), хоть и не с точки зрения кодера, а с т.з.
наличия доп. софта.

Let> я так понял, атрибуты там вообще не используются.

Имеешь ввиду атрибуты переделываемого софта? Используются, но не совсем
напрямую, т.к. они для всего знакоместа, а у меня знакоместо разбито на группы
пикселей имеющих свои отдельные атрибуты (т.е. детализация выше и
соответственно вероятность спиллинга ниже, т.к. основная идея в том что-бы по
возможности не испортить не имеющий спиллинга 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.

Hello, Black_Cat

Bla> Вроде нет задачи конвертить что-то из 4+ в 5 (а значит нет задачи
Bla> иметь идеологическую связь по форме атрибутных областей). Есть задача
Bla> конвертить из стандартного режима в 4+ или 5 и тут могут быть некие
Bla> предпочтения.

Мож кому-то захочется сконвертить И в 4+, И в 5? Чем больше у них общих мест,
тем меньше работы.

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

Четвертушки - фактически то же самое.

Bla> т.к. основная идея в том что-бы по возможности не испортить не
Bla> имеющий спиллинга 4 режим, в противном случае вообще нет смысла
Bla> цеплять сюда ещё и атрибуты, уж лучше пускай остаётся вообще без
Bla> атрибутов но и без спиллинга).

Hу дык делаем во всех атрибутах атрибутные цвета равными палитровым цветам, вот
тебе и обычный 16-цветный режим "без атрибутов".

Bla> Разница между 4 и 5 режимами не в глубине цвета и разрешении, а
Bla> именно в наличии или отсутствии спиллинга - это критерий.

Гы, 512x384 vs 256x192 - и разница не в разрешении? Жжош!
И кстати в режиме 5 не спиллинг, а как раз старый добрый клэшинг. ;)

Bla> Для того, что бы небыло путаницы ещё раз опишу схему формирования
Bla> цвета:

Имхо делить пикселы на мелкие группы неудобно. Hу можно например забабахать 4
палитры, и каждые два бита (из 32) атрибутов определяют свою палитру для группы
2x2 пиксела. А толку? Для нормальной анимации придется цвета урезать,
то есть в 4 палитрах будет не 64 разных цвета, а меньше; переделывать игрушки
тщательнее придется, стандартный режим отдельно лепить опять же... ну нах! А
если атрибуты одинаковые во всех режимах, можно например в игрушках весь
текстовый вывод не трогать, раскручивать только графическую часть (и то
возможно не полностью). Ресурсов опять же меньше понадобится в пересчете на
логику (та же палитра к примеру - лучше даже не две иметь, а зафиксировать
атрибутные цвета как прямой код IGRB). Если у разных видеорежимов много "общих
мест" при сильном внешнем различии - имхо это хорошо. Для переделок
унифицированных атрибутов за глаза хватит, а что кто-нить чего-то сложное и
оригинальное кодить будет - большие сомнения. Спектрумисты и так народ ленивый,
а тут еще извращаться надо, чтоб картинка не глючила...

Hу да все равно никто ничего делать не будет.