Вопрос про "состязательную/несостязательную" память.

[mmxdmv]

, то почему ПОЧЕМУ делали компы с торможением?? Ну, ладно, допустим когда сэр Клайв первый спек сделал в 80х, еще не знали/не умели/дорогие схемы были. А в 90х наши-то клоны?

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

P.S. а на самом деле торможение не такое уж страшное было. У z80 всего ничего команд которые выполняются нечётное кол-во тактов (чётные не надо тормозить). Так что даже в самом худшем случае ЦП замедлялся не более чем на 5-7%

[Advertiser]

[Spectramine]

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

В случае фирменных спеков речь идет о некотором усложнении микросхемы ULA, насколько я понимаю, не таком уж критичном. Скорее действительно не хотели на халяву перерабатывать.

Ну и в третих - совместимость. Мало кому нравится когда мультиколорные эффекты разъезжаются

О какой совместимости идет речь? Spectrum 48, 128 и +2А/+3 тормозят по-разному, так что мультиколорные эффекты по-любому разъезжаются. Я уже молчу о клонах.

P.S. а на самом деле торможение не такое уж страшное было. У z80 всего ничего команд которые выполняются нечётное кол-во тактов (чётные не надо тормозить). Так что даже в самом худшем случае ЦП замедлялся не более чем на 5-7%

Неправда ваша, тормозятся все команды, независимо от их длины в тактах. (Может быть, вы спутали с желтым Скорпионом? Там да, тормозятся только нечётные команды). Разве что некоторые команды тормозятся неоднократно за их выполнение, а некоторые (4х тактовые) - только при выборке кода операции. Так что в худшем случае, во время прорисовки байтов основного экрана, торможение на фирменных машинах может достигать 50% и выше - можете посмотреть паттерны торможения здесь: http://scratchpad.wikia.com/wiki/Contended_memory .

[NEO SPECTRUMAN]

не совсем по теме
но кто не читал
читаем все подряд
http://zxnext.narod.ru/hist1982_1.htm
http://zxnext.narod.ru/hist1982_2.htm
http://zxnext.narod.ru/hist1983.htm
http://zxnext.narod.ru/hist1983_2.htm
http://zxnext.narod.ru/hist1984.htm
http://zxnext.narod.ru/hist1984_2.htm
http://zxnext.narod.ru/hist1985.htm
http://zxnext.narod.ru/hist1985_2.htm
http://zxnext.narod.ru/hist1986.htm

[Бука]

не совсем по теме

И не совсем по теме вопрос - где можно найти лакуну • 1979 • 1980 • 1981 • - пусть даже на аглицкой мове?

[NEO SPECTRUMAN]

Нигде... (по крайней мере мну не знает)
И аффтара статей на этом сайтеке давно нету... х3 де он делся...
http://speccy.info/%D0%9A%D0%BE%D0%B...B4%D0%BE%D0%B2

[Бука]

Нигде... (по крайней мере мну не знает)
И аффтара статей на этом сайтеке давно нету... х3 де он делся...

Жаль... Я тоже искал, писал на указанный емайл... Печально.

[mmxdmv]

О какой совместимости идет речь? Spectrum 48, 128 и +2А/+3 тормозят по-разному, так что мультиколорные эффекты по-любому разъезжаются. Я уже молчу о клонах.

Имелось в виду не совместимость, а скорее наследственность. Тормозили они примерно одинаково. В смысле у отечественных клонов разброс был значительно больше.
А мультиколорщики к основным (читай буржуйским) моделям подстраивались. Правда у них быстро пересели на PC и амиги...

Неправда ваша, тормозятся все команды, независимо от их длины в тактах. (Может быть, вы спутали с желтым Скорпионом? Там да, тормозятся только нечётные команды). Разве что некоторые команды тормозятся неоднократно за их выполнение, а некоторые (4х тактовые) - только при выборке кода операции. Так что в худшем случае, во время прорисовки байтов основного экрана, торможение на фирменных машинах может достигать 50% и выше - можете посмотреть паттерны торможения здесь: http://scratchpad.wikia.com/wiki/Contended_memory .

Хм. Я не очень владею буржуйским переводчиком, чтобы понять ньюансы. Просто читал в каком-то, тогда ещё бумажном руководстве что торможение происходит ТОЛЬКО если процессор и ULA обращаются к шине одновременно. Частота генерации пикселов - 7мегагерц, но картинка монохромная + атрибут; поэтому на восемь пикселов (или 4 такта z80) происходит два чтения. А z80 как раз подавляющее большинство команд имеет с чётными тактами. По идее нелогично тормозить всегда, если можно только в случае конфликта...

Ну и на счёт 50% и выше... совсем уж не верится. Такую цифру можно получить лишь в том случае, когда на момент вывода экрана процессор полностью отрубается (и включается только на BORDER).

А вообще, да, странно такое читать: берём процессор на 4 мегагерца (большинство из которых прекрасно работают на 5-6), тормозим его до 3.5 мегагерц (на тактовом генераторе и синхронизации экономим), а потом ещё "до 50%" тормозим (уже непонятно на чём экономим)...

[NEO SPECTRUMAN]

ну 50% это сильно жирно

даже если полностью отключать проц на время отрисовки экрана

(312-192)*224 = 26880т верхняя нижняя граница экрана в которой отрисовка не происходит
192*(224-(256/2)) = 18432т во время отрисовки бордюра по краям экрана проц не тормозиться

итого во фрейме не меньше 45312т когда у процессора есть доступ к памяти
что как бы 64,835164835164835164835164835165% от общего времени его работы
уже никак не 50%
а еще ж процу дается доступ и во время отрисовки экрана...
а того времени вполне хватает
на отдельных мелких командах конечно можно потерять и больше 50 % (nop за 10 тактов)
но это на отдельных одиночных командах

[Spectramine]

Имелось в виду не совместимость, а скорее наследственность. Тормозили они примерно одинаково. В смысле у отечественных клонов разброс был значительно больше.
А мультиколорщики к основным (читай буржуйским) моделям подстраивались. Правда у них быстро пересели на PC и амиги...

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

Хм. Я не очень владею буржуйским переводчиком, чтобы понять ньюансы. Просто читал в каком-то, тогда ещё бумажном руководстве что торможение происходит ТОЛЬКО если процессор и ULA обращаются к шине одновременно. Частота генерации пикселов - 7мегагерц, но картинка монохромная + атрибут; поэтому на восемь пикселов (или 4 такта z80) происходит два чтения. А z80 как раз подавляющее большинство команд имеет с чётными тактами. По идее нелогично тормозить всегда, если можно только в случае конфликта...

Ну и на счёт 50% и выше... совсем уж не верится. Такую цифру можно получить лишь в том случае, когда на момент вывода экрана процессор полностью отрубается (и включается только на BORDER).

Увы, всё сложнее в плане торможения. Несмотря на то, что действительно на 4 такта происходит два чтения, процессор тормозится каждые 6 тактов из 8, при чтении кода операции, обращении к памяти, и в некоторых других случаях, - на 48/128к и каждые 7 тактов из 8 - на +2A/+3. Почему - я не знаю, я не схемотехник, увы.

Возьмем, например, цепочку команд NOP, представим, что она выполняется с начала тормозного цикла. 1-я команда будет выполняться 10 тактов, вторая, третья и последующие - по 8 тактов. Торможение +100% (вместо 4 тактов - 8)! А более сложные команды могут тормозиться ещё и неоднократно. И это до самого конца прорисовки битовой строки экрана. Положение спасают только рисование бордюра и обратный ход луча по строке, дающие затем 96 тактов без тормозов. Т.е. во время рисования всей экранной строки с учетом бордюра торможение будет (128*2+96)/ (128+96)=1.57, (где 128 - количество тактов на прорисовку битовой картинки, 96 - на бордюр и обратный ход луча, 2 - коэффициент торможения (8 тактов вместо 4х)
Т.е. на 57% код в медленной памяти во время прорисовки экранных строк с битовой картинкой (включая левый и правый бордюр и обратный ход луча в начало строки) выполняется медленнее. Правда, для более длинных по времени выполения команд торможение может быть как выше (если они сами обращаются к медленной памяти), так и ниже, за счет меньшего отношения времени ожидания к длине команды. Например, последовательные команды инкремента регистровой пары будут выполняться 12,8,8,8 тактов вместо 6, что дает торможение +25% (если только программист не решит вписать в регистр I что-нибудь из диапазона адресов медленной памяти, тогда эти команды будут выполняться за 16 тактов каждая).

Примерно треть кадра уходит на прорисовку верхнего и нижнего бордюра, и обратный ход луча в начало кадра, во время которых торможения не происходит, что ещё несколько спасает ситуацию.
1.57*(224*192)/69888+1*(69888-224*192)/69888=1.57*0.61+1*0.39 ~=1.35. (1.57 - коэффициент торможения во время прорисовки основных строк экрана, 224*192- время в тактах на их прорисовку, 69888 - общее время кадра в тактах).

Итого, в целом за кадр, медленная память тормозит проц где-то на 35%. Как-то так.

А вообще, да, странно такое читать: берём процессор на 4 мегагерца (большинство из которых прекрасно работают на 5-6), тормозим его до 3.5 мегагерц (на тактовом генераторе и синхронизации экономим), а потом ещё "до 50%" тормозим (уже непонятно на чём экономим)...

Я так понял, экономим в основном на времени разработки. Не думаю, что небольшое усложнение ULA сильно её удорожило бы.

- - - Добавлено - - -

ну 50% это сильно жирно

даже если полностью отключать проц на время отрисовки экрана

(312-192)*224 = 26880т верхняя нижняя граница экрана в которой отрисовка не происходит
192*(224-(256/2)) = 18432т во время отрисовки бордюра по краям экрана проц не тормозиться

итого во фрейме не меньше 45312т когда у процессора есть доступ к памяти
что как бы 64,835164835164835164835164835165% от общего времени его работы
уже никак не 50%
а еще ж процу дается доступ и во время отрисовки экрана...
а того времени вполне хватает
на отдельных мелких командах конечно можно потерять и больше 50 % (nop за 10 тактов)
но это на отдельных одиночных командах

Я говорил о торможении во время прорисовки битовой части картинки, а не о торможении в целом за кадр.

[Lethargeek]

Я так понял, экономим в основном на времени разработки. Не думаю, что небольшое усложнение ULA сильно её удорожило бы.

Мы не знаем, сколько места в юле осталось. В одну, может, больше и не влезло бы ничего.