Тормозят хоть и примерно одинаково, но по-разному, поэтому мультиколорщикам приходилось подстраиваться под модель, если они ориентировались на оригинальные машины. Но у нас большинство не парилось, и писало демки исключительно под Пентагон, с его безтормозной архитектурой, да ещё и с запасом по тактам на фрейм.Сообщение от mmxdmv
Увы, всё сложнее в плане торможения. Несмотря на то, что действительно на 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%" тормозим (уже непонятно на чём экономим)...
- - - Добавлено - - -
Я говорил о торможении во время прорисовки битовой части картинки, а не о торможении в целом за кадр.
Ответить с цитированием