ZX-Poly™ platform

[Lethargeek]

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

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

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

[Lethargeek]

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

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

[Black_Cat]

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

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

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

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

[Lethargeek]

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

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

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

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

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

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

[Black_Cat]

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

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

[Lethargeek]

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

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

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

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

[Black_Cat]

ГЕМОРРОИЩЕ!

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

[Lethargeek]

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

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

[Black_Cat]

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

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

[AlexCrush]

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