Не надо только Синклера в очередной раз поливать грязью. Вы достигните хотя бы 10 доли того что сделал он, тогда можете "покритиковать".Сообщение от Lethargeek
Сейчас уже точно никто не скажет точно, можно или нет, но то что ни в Sinclair ни в Amstrad этого не сделали а наши разработчики смогли - только повод вспомнить их добрым словом.
К слово сказать "торможение" не было сильно критичным, а маленький "Ленинград-1" производил тогда впечатление.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
"грязью" правда может выглядеть лишь на фоне старых слащавых сказок от "инфоркома"
несколько ответов тебе на выбор
Прихожу без разрешения, сею смерть и разрушение...
Ответы даются на вопросы, я вопрос не задавал. К тому же вы дурно воспитаны. Зачем называть заслуженного человека "дядей" и поливать его грязью? Ответ не требуется и так все понятно.
а также на непрошеные советы, предложения, условия, указания...
зачем дяде настоящему рыцарю нужна помощь и защита ненастоящего?
- - - Добавлено - - -
не видеоконтроллера - речь о памяти, медленная память дешевле стоит (+ тогда емнип как раз цены подскочили на озу)
юла, кстати, как и прочие заказные чипы - это тоже способ удешевления (при большом заказе, естественно)
Прихожу без разрешения, сею смерть и разрушение...
потому что для прозраного доступа нужен был регистр 8 бит и немного логики в ULA, т.е. тупо жлопп
Чтобы критиковать президента, надо самому быть президентом...
Чтобы осуждать убийцу, надо самому быть убийцей... хотя бы на 10%.......
Железная логика.
Во первых цена разработки. Никто не хотел нахаляву перерабатывать.
Во вторых цена сборки - десяток корпусов микросхем средней интеграции. Тем более "лишние" микросхемы - это увеличенное питание, повышенная нагрузка на шину и т.п.
Ну и в третих - совместимость. Мало кому нравится когда мультиколорные эффекты разъезжаются
P.S. а на самом деле торможение не такое уж страшное было. У z80 всего ничего команд которые выполняются нечётное кол-во тактов (чётные не надо тормозить). Так что даже в самом худшем случае ЦП замедлялся не более чем на 5-7%
В случае фирменных спеков речь идет о некотором усложнении микросхемы ULA, насколько я понимаю, не таком уж критичном. Скорее действительно не хотели на халяву перерабатывать.
О какой совместимости идет речь? Spectrum 48, 128 и +2А/+3 тормозят по-разному, так что мультиколорные эффекты по-любому разъезжаются. Я уже молчу о клонах.Ну и в третих - совместимость. Мало кому нравится когда мультиколорные эффекты разъезжаются
Неправда ваша, тормозятся все команды, независимо от их длины в тактах. (Может быть, вы спутали с желтым Скорпионом? Там да, тормозятся только нечётные команды). Разве что некоторые команды тормозятся неоднократно за их выполнение, а некоторые (4х тактовые) - только при выборке кода операции. Так что в худшем случае, во время прорисовки байтов основного экрана, торможение на фирменных машинах может достигать 50% и выше - можете посмотреть паттерны торможения здесь: http://scratchpad.wikia.com/wiki/Contended_memory .P.S. а на самом деле торможение не такое уж страшное было. У z80 всего ничего команд которые выполняются нечётное кол-во тактов (чётные не надо тормозить). Так что даже в самом худшем случае ЦП замедлялся не более чем на 5-7%
Последний раз редактировалось Spectramine; 22.02.2017 в 13:42.
Имелось в виду не совместимость, а скорее наследственность. Тормозили они примерно одинаково. В смысле у отечественных клонов разброс был значительно больше.
А мультиколорщики к основным (читай буржуйским) моделям подстраивались. Правда у них быстро пересели на PC и амиги...
Хм. Я не очень владею буржуйским переводчиком, чтобы понять ньюансы. Просто читал в каком-то, тогда ещё бумажном руководстве что торможение происходит ТОЛЬКО если процессор и ULA обращаются к шине одновременно. Частота генерации пикселов - 7мегагерц, но картинка монохромная + атрибут; поэтому на восемь пикселов (или 4 такта z80) происходит два чтения. А z80 как раз подавляющее большинство команд имеет с чётными тактами. По идее нелогично тормозить всегда, если можно только в случае конфликта...
Ну и на счёт 50% и выше... совсем уж не верится. Такую цифру можно получить лишь в том случае, когда на момент вывода экрана процессор полностью отрубается (и включается только на BORDER).
А вообще, да, странно такое читать: берём процессор на 4 мегагерца (большинство из которых прекрасно работают на 5-6), тормозим его до 3.5 мегагерц (на тактовом генераторе и синхронизации экономим), а потом ещё "до 50%" тормозим (уже непонятно на чём экономим)...
Тормозят хоть и примерно одинаково, но по-разному, поэтому мультиколорщикам приходилось подстраиваться под модель, если они ориентировались на оригинальные машины. Но у нас большинство не парилось, и писало демки исключительно под Пентагон, с его безтормозной архитектурой, да ещё и с запасом по тактам на фрейм.
Увы, всё сложнее в плане торможения. Несмотря на то, что действительно на 4 такта происходит два чтения, процессор тормозится каждые 6 тактов из 8, при чтении кода операции, обращении к памяти, и в некоторых других случаях, - на 48/128к и каждые 7 тактов из 8 - на +2A/+3. Почему - я не знаю, я не схемотехник, увы.Хм. Я не очень владею буржуйским переводчиком, чтобы понять ньюансы. Просто читал в каком-то, тогда ещё бумажном руководстве что торможение происходит ТОЛЬКО если процессор и ULA обращаются к шине одновременно. Частота генерации пикселов - 7мегагерц, но картинка монохромная + атрибут; поэтому на восемь пикселов (или 4 такта z80) происходит два чтения. А z80 как раз подавляющее большинство команд имеет с чётными тактами. По идее нелогично тормозить всегда, если можно только в случае конфликта...
Ну и на счёт 50% и выше... совсем уж не верится. Такую цифру можно получить лишь в том случае, когда на момент вывода экрана процессор полностью отрубается (и включается только на BORDER).
Возьмем, например, цепочку команд 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%. Как-то так.
Я так понял, экономим в основном на времени разработки. Не думаю, что небольшое усложнение ULA сильно её удорожило бы.А вообще, да, странно такое читать: берём процессор на 4 мегагерца (большинство из которых прекрасно работают на 5-6), тормозим его до 3.5 мегагерц (на тактовом генераторе и синхронизации экономим), а потом ещё "до 50%" тормозим (уже непонятно на чём экономим)...
- - - Добавлено - - -
Я говорил о торможении во время прорисовки битовой части картинки, а не о торможении в целом за кадр.
Последний раз редактировалось Spectramine; 23.02.2017 в 01:56.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
