Contended memory и прочие тормоза спектрумов

Советский гений создал Пентагон, на остальных машинах всё оказывается не так радужно =\
Вот тут http://www.worldofspectrum.org/faq/r...htm#Contention пишут "so programs which run in the contended memory (from 0x4000 to 0x7fff) or try to read from Port 0xfe ... will be slowed".
На тормоза с портом, как я понимаю, можно наплевать, всё равно его читать обычно надо на прерывании, когда у нас рисуется бордюр.
В 128х всё ещё хуже - тормозит не одна область памяти, а половина банков, у разных моделей разные наборы. Не тормозят только 0 и 2.
Эти тормоза происходят только при исполнении кода из тормозного диапазона или даже когда идёт обращение к данным в эту область?

Что произойдёт, если я выставлю I=#FE? (ну нету места в нижней памяти на табличку =\) "to crash the machine shortly after I is set to point to contended memory" будет зависеть от банка, торчащего в окне? А если надо банками щёлкать, то когда нужно подтыкать банк№0 с табличкой и обслуживанием инта?

Какие ещё тормоза можно встретить на спектрумах? Что за "even M1"? Это из-за него Скорп называют тормозом?

even M1 - это WAIT на 1 такт, если команда начинается на нечетном такте. Зачем так сделано было - слабо понимаю. Скорее всего из-за схемы всобачивания турбы.
В фирменных ZX тормозят нечетные банки (схема 128К) или банки 4..7 (схема +3) - это чтобы замедлить банки 5 и 7, где располагаются экраны.
Медленными портами, кажется, болеют только некоторые варианты 48К.
"Снег" возникает, если I находится в медленой памяти, включенные в #C000 медленные банки тоже считаются, если I там

Цитата:

---

Сообщение от NovaStorm

Эти тормоза происходят только при исполнении кода из тормозного диапазона или даже когда идёт обращение к данным в эту область?

---

при любом доступе к медленной памяти, но и не только. Задержки идут также на промежуточных циклах процессора, когда по факту доступа к памяти или портам нет, но на шину процессор выставляет адрес медленной области памяти и неполную комбинацию сигналов для чтения/записи. Т.е. процессор по сути не обращается ни к памяти, ни к портам, но из-за упрощенной логики ULA, возникает комбинация сигналов приводящих к задержкам процессора. В зависимости от инструкции на шину при этом может попадать содержимое регистровых пар IR, PC, SP или HL...

---------- Post added at 17:54 ---------- Previous post was at 17:35 ----------

Цитата:

---

Сообщение от SAM style

even M1 - это WAIT на 1 такт, если команда начинается на нечетном такте. Зачем так сделано было - слабо понимаю. Скорее всего из-за схемы всобачивания турбы.

---

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

Спасибо!

Цитата:

---

Сообщение от ZXMAK

при любом доступе к медленной памяти, но и не только

---

Печаль, однако... Тормозищи выходят катастрофические.

Цитата:

---

Сообщение от ZXMAK

хитрая замена порядка операций

---

Я конечно не электронщик, но, насколько понимаю, вроде там довольно просто всё было - видео контроллеру каждые 4 такта надо прочитать два байта на точки и цвет, и ему по барабану в какой такт М1 это делать. Если шина занята, он ждёт. И в какой-нибудь такт шина обязательно становится ему доступна.

А насчёт I можно прояснить, когда там снежить начинает? Тоже _сразу_ при его попадании на медленную память(когда медленную страничку например в банк втыкаем)?

У отечественных машин такого ужаса ведь ни кого нету?

Цитата:

---

Сообщение от NovaStorm

У отечественных машин такого ужаса ведь ни кого нету?

---

у первых достаточно точных клонов (львовский,москва) всё это есть.

Цитата:

---

Сообщение от NovaStorm

Я конечно не электронщик, но, насколько понимаю, вроде там довольно просто всё было - видео контроллеру каждые 4 такта надо прочитать два байта на точки и цвет, и ему по барабану в какой такт М1 это делать. Если шина занята, он ждёт. И в какой-нибудь такт шина обязательно становится ему доступна.

---

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

Цитата:

---

Сообщение от NovaStorm

У отечественных машин такого ужаса ведь ни кого нету?

---

С чего вы решили? У бресткого горячо любимого Байта, как раз-таки двухполевая схема. И в своё время приходилоь править кучу софта из-за того что пейсатели под пятногон кидали I в медленную память.

Цитата:

---

Сообщение от NovaStorm

А насчёт I можно прояснить, когда там снежить начинает? Тоже _сразу_ при его попадании на медленную память(когда медленную страничку например в банк втыкаем)?

---

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

Цитата:

---

Сообщение от ZXMAK

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

---

А схемы посмотреть? )

Цитата:

---

Сообщение от breeze

У бресткого горячо любимого Байта, как раз-таки двухполевая схема

---

И тоже тормоза до шести дополнительных тактов на команду?

Цитата:

---

Сообщение от Titus

А схемы посмотреть? )

---

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

Цитата:

---

Сообщение от ZXMAK

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

---

Надо попросить помощи зала, схемотехников тут немало.

Цитата:

---

Сообщение от NovaStorm

Советский гений создал Пентагон

---

Не только пентагон. Есть еще "Орель БК-08", там тоже нет никаких задержек при обращении к ОЗУ.

Цитата:

---

Сообщение от ZXMAK

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

---

По схеме "Орели" я могу ответить на любые вопросы (эта схема несколько лет висела у меня на стене в комнате вместо портрета любимой девушки).

В "Орели" порядк выборки attr/pixel или pixel/attr не меняется. Просто в начале каждого такта 3.5МГц анализируется сигнал запроса памяти процессором (сигнал /CSM, который вырабатывается из /MREQ и адресных линий A14, A15). Если он активен - то процессору предоставляется шина памяти на 1 такт. Считанное из памяти за этот такт значение защелкивается на регистре ИР22 и доступно на шине данных Z80 в течение всего последующего времени, пока активен /MREQ. Что же касается записи, то она происходит в указанный такт, когда процессору предоставлен доступ к ОЗУ, а в последующем такте (или тактах) активности /MREQ запись в ОЗУ не производится. Таким образом, в течение 2х тактов Z80 видеоконтроллер сможет обратиться к ОЗУ как минимум 1 раз, и этого как раз достаточно для нормального отображения экрана без задержек процессора.

Думаю, что подобным образом сделано и в Пентагоне. Менять порядок считывания pixel/attr сложно схемотехнически, да и не нужно, если требуется только гарантировать одно обращение видеоконтроллера к ОЗУ за период в 2 такта 3.5МГц.

С точки зрения эмуляции мультиколора - да, тут есть некоторая сложность, т.к. если Z80 не обращается к ОЗУ - то пиксели и атрибуты считываются оттуда каждый такт (т.е. избыточно), а если обращается - то возможны варианты +-такт. Если содержимое той области памяти, к которой обращается видеоконтроллер, изменяется так, что эта разница в +-такт становится существенной - то да, мультиколор начинает вести себя сложным образом.

Но это существенно только при формировании вертикальных мультиколорных полос. Кроме того, поскольку весь код, рисующий мультиколор, как правило, однороден и располагается в ОЗУ - то возможно предсказать и активность процессора в это время, а значит, и точно рассчитать этот код. На практике, думаю, все это делалось эмпирически, т.е. методом проб и ошибок.

Цитата:

---

Сообщение от Barmaley_m

Думаю, что подобным образом сделано и в Пентагоне. Менять порядок считывания pixel/attr сложно схемотехнически, да и не нужно, если требуется только гарантировать одно обращение видеоконтроллера к ОЗУ за период в 2 такта 3.5МГц.

С точки зрения эмуляции мультиколора - да, тут есть некоторая сложность, т.к. если Z80 не обращается к ОЗУ - то пиксели и атрибуты считываются оттуда каждый такт (т.е. избыточно), а если обращается - то возможны варианты +-такт. Если содержимое той области памяти, к которой обращается видеоконтроллер, изменяется так, что эта разница в +-такт становится существенной - то да, мультиколор начинает вести себя сложным образом.

---

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

Цитата:

---

Сообщение от Barmaley_m

Есть еще "Орель БК-08"

---

Она же 48я? Меня интересует конечно всё, но волнуют именно 128+BDI+AY. Всех моделей конечно не охватить, но как дела хотя бы у тех, что на наших БМК?

Цитата:

---

Сообщение от Barmaley_m

если Z80 не обращается к ОЗУ - то пиксели и атрибуты считываются оттуда каждый такт

---

O_o Разве? Я думал, что считываются два байта, а потом в регистре точки сдвигаются. Как заканчиваются - всасывается следующий+цвет - один раз в 4 такта.

Цитата:

---

Сообщение от NovaStorm

Она же 48я? Меня интересует конечно всё, но волнуют именно 128+BDI+AY.

---

Заводская - 64К (не 48), но схем расширения до 128К, 256К и более было полно в ходу. Двое моих знакомых десятками дорабатывали "Орели", а ведь были еще и конкуренты.

Серийно выпускались контроллеры дисковода и принтера (было две удачные модели от независимых производителей), которые подключались к штатному системному разъему. Я думаю, что большинство днепропетровских владельцев "Орелей" подвергли их расширению и подключению дисковода. Разве только те владельцы, которые до середины 1993г перешли на другие платформы (Amiga, PC) и продали/выкинули свои "Орели", пропустили этап расширения.

Цитата:

---

Сообщение от NovaStorm

O_o Разве? Я думал, что считываются два байта, а потом в регистре точки сдвигаются.

---

Конкретно в "Орели" применяется двойная буферизация. Для первичного защелкивания пикселей и атрибутов установлено два регистра (ИР27 - DD26, DD27), данные в одном из которых защелкиваются всякий раз, когда видеоконтроллер обращается к памяти. Происходит это, как я уже говорил, каждый такт 3.5МГц (если процессор не обращается к памяти) или, по крайней мере, не реже 1 раза каждые 2 такта, если процессор к памяти обращается.

Из этих промежуточных регистров пиксели поступают в сдвигающий регистр (ИР9 - DD32), а атрибуты - в мультиплексор с памятью (2 микросхемы КП13 - DD33, DD34), на выходе которых защелкивается либо цвета атрибута, либо цвет бордюра. Таким образом, неважно, сколько раз и когда именно видеоконтроллер считал из памяти данные. В нужный момент, когда данные переносятся из первичных буферов во вторичные, данные гарантированно верны.

Цитата:

---

Сообщение от Barmaley_m

не реже 1 раза каждые 2 такта

---

Но ведь фетч опкода операции - два такта, в течение которых на ША лежит PC, как тогда получается отсутствие задержек?

Цитата:

---

Сообщение от NovaStorm

Но ведь фетч опкода операции - два такта, в течение которых на ША лежит PC, как тогда получается отсутствие задержек?

---

Выборка кода операции (цикл M1) - это полтора такта, а не два, хотя при прочих обращениях к памяти (чтение/запись данных) сигнал /MREQ действительно активен два такта. Но, как я сказал выше:

Цитата:

---

Сообщение от Barmaley_m

Считанное из памяти за этот такт значение защелкивается на регистре ИР22

---

Шина данных считывания памяти в "Орель БК-08" отделена от шины данных Z80. Данные от памяти поступают на ШД Z80 через регистр-защелку ИР22. Там они защелкиваются и остаются верными в течение всего времени, пока активен сигнал /MREQ, а сама память в это время уже может быть занята другими делами (т.е. отдавать данные видеоконтроллеру).

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

Ну и да, шина адреса памяти в "Орели", да и вообще во всех ZX, тоже не одна на всех. Есть ША процессора, есть ША видеоконтроллера. На микросхемы памяти подается адрес с одной из них через мультиплексор 4:1. В фирменном ZX этот мультиплексор находится внутри ULA.

Цитата:

---

Сообщение от Barmaley_m

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

---

Спектрум вообщето на ПЛМ был сделан, это у нас даже в 90-е электронику еще на рассыпной комлектухе из мелкой логики в виде счетчиков, триггеров и регистров собирали :)

Цитата:

---

Сообщение от Barmaley_m

Разработчики сэкономили микросхему-регистр

---

Вот *****еды =) Неужели в ULA места не осталось...

Цитата:

---

Сообщение от NovaStorm

Вот *****еды =) Неужели в ULA места не осталось...

---

Думается мне, не места, а выводов. Еще +8 отдельно для процессора.

А какой эмулятор поддерживает лучше всевозможные тормоза и глюки?
Потестил свою поделку на EmuZWin - FPS на 128м, как и ожидалось, упал с 25 до 17(как он их считает кстати?), даже на скорпионе не падает, а тут - без шансов =(

Цитата:

---

Сообщение от NovaStorm

А какой эмулятор поддерживает лучше всевозможные тормоза и глюки?
Потестил свою поделку на EmuZWin - FPS на 128м, как и ожидалось, упал с 25 до 17(как он их считает кстати?), даже на скорпионе не падает, а тут - без шансов =(

---

в emuzwin contentended memory некорректно работает.

Для 128К и 48K early модели поддерживают хорошо ZXMAK2, Spectaculator, Fuse, SpecEmu.

А вот для 48К late модели сами тайминги в этих эмуляторах работают вроде везде корректно, но вот c эмуляцией таймингов INT есть разница - у каждого эмулятора по своему. Как правильно неизвестно - никто так и не смог проверить на реальном железе :)
Не исключено что во всех эмуляторах тайминги INT или сама эмуляция INT для 48K late неправильные :biggrin:

Чтобы код работал быстрее на contended памяти, нужно чтобы как минимум:
- код исполнялся в быстрой памяти;
- стек находился в быстрой памяти;
- не было обращений к медленной памяти
- не было обращений к медленным портам
- значение IR, SP или HL не попадало на медленную область памяти - это актуально при использовании некоторых инструкций, которые хотя явно и не обращаются к медленной памяти, но могут выставлять значение этих регистров на шину в сочетании сигналов управления, которые ULA детектит как обращение к медленной памяти
- все обращения к медленной памяти/портам производить пока луч находится за пределами экрана

Цитата:

---

Сообщение от ZXMAK

- значение IR, SP или HL не попадало на медленную область памяти - это актуально при использовании некоторых инструкций, которые хотя явно и не обращаются к медленной памяти, но могут выставлять значение этих регистров на шину в сочетании сигналов управления, которые ULA детектит как обращение к медленной памяти

---

А можно поподробнее, что это за инструкции такие?

Цитата:

---

Сообщение от ZXMAK

Спектрум вообщето на ПЛМ был сделан,

---

ULA - это не ПЛМ, это БМК. Полузаказная микросхема. А другие игровые компьютеры тех времен (Commodore-64, Atari 800) использовали полностью заказные БИС (всякие там CTIA/GTIA, Pokey, ANTIC и др). На полностью заказной БИС можно реализовать еще более сложные функции, поэтому эти компьютеры так и не были клонированы в СССР. Или слишком сложно было их реверсить, или потребовалось бы слишком много "рассыпухи", чтобы их повторить.

Цитата:

---

Сообщение от ZXMAK

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

---

Ну, не всю. Были школьные компьютеры типа УК-НЦ, там были и ПЛМ, и заказные БИС. Всякие "средние" ЭВМ, типа клонов PDP/11 - СМ-4, или клонов VAX, тоже широко использовали ПЛМ (в первую очередь - 1556ХЛ8/ХП8).

Цитата:

---

Сообщение от Alex Rider

Думается мне, не места, а выводов. Еще +8 отдельно для процессора.

---

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

Цитата:

---

Сообщение от Alex Rider

А можно поподробнее, что это за инструкции такие?

---

например LD SP,HL; ADD HL,rr; INC/DEC rr и т.п. детектятся ULA как обращение по адресу IR.

Цитата:

---

Сообщение от ZXMAK

например LD SP,HL; ADD HL,rr; INC/DEC rr и т.п. детектятся ULA как обращение по адресу IR.

---

С какого это перепуга так сделали?

Насколько я понимаю, сама ULA во время выполнения этих команд кладет на шину IR для регенерации памяти.

Цитата:

---

Сообщение от Titus

С какого это перепуга так сделали?

---

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

Цитата:

---

Сообщение от ZXMAK

например LD SP,HL; ADD HL,rr; INC/DEC rr и т.п. детектятся ULA как обращение по адресу IR.

---

IR с записью попадают на шину каждый цикл M1, ибо регенерация, отсюда берется снег. Мне интересно, когда на шину попадают HL и SP в командах, которые не читают/пишут память косвенной адресацией?

Цитата:

---

Сообщение от ZXMAK

например LD SP,HL; ADD HL,rr; INC/DEC rr и т.п. детектятся ULA как обращение по адресу IR.

---

Вот эти команды не должны выкидывать на ША значения SP, HL, rr и прочего, это все внутри проца деется.
То есть, если я в быстрой памяти делаю ld sp,hl, sp и/или hl укзывают в медленную память, i указывает в быструю память, то тормозов быть не должно.
Если я делаю ld (#4000),hl или ld (hl),n при #40 <= h <= 7f, то тормоза могут наступить только в цикле записи в память (если i в быстрой памяти).

Цитата:

---

Сообщение от Alex Rider

Мне интересно, когда на шину попадают HL и SP в командах, которые не читают/пишут память косвенной адресацией?

---

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

---------- Post added at 07:05 ---------- Previous post was at 06:57 ----------

Цитата:

---

Сообщение от Alex Rider

Вот эти команды не должны выкидывать на ША значения SP, HL, rr и прочего, это все внутри проца деется.
То есть, если я в быстрой памяти делаю ld sp,hl, sp и/или hl укзывают в медленную память, i указывает в быструю память, то тормозов быть не должно.

---

А они будут, я об этом и говорю. Что по смыслу операции задержки быть не должно, но на риале она есть из-за упрощенной логики ula и особенностей процессора.
Если IR указывает на медленную память, то NOP в быстрой памяти выполнится без задержки, а LD SP,HL с задержкой. Цикл регенерации и в той и в другой инструкции одинаковые. И к медленной памяти обе инструкции не обращаются. Но у одной задержки не будет, а у другой будет

Цитата:

---

Сообщение от ZXMAK

А они будут, я об этом и говорю.

---

А есть где почитать про это?

http://scratchpad.wikia.com/wiki/Contended_memory
http://scratchpad.wikia.com/wiki/Contended_IO
http://zx-pk.ru/showthread.php?p=1659#post1659

Цитата:

---

Сообщение от weiv

http://scratchpad.wikia.com/wiki/Contended_memory

---

Ага, понял. Если инструкция выполняется дольше 4 тактов, то будет задержка по IR, но не по содержимому регистров.
upd: Вернее, тоже не совсем так, дето не в длительности инсрукции.

Цитата:

---

Сообщение от Alex Rider

Ага, понял. Если инструкция выполняется дольше 4 тактов, то будет задержка по IR, но не по содержимому регистров.
upd: Вернее, тоже не совсем так, дето не в длительности инсрукции.

---

дело не в тактах, а в том как процессор инструкцию выполняет. На какихто инструкциях IR на шине болтается, на каких-то PC, на каких-то SP, на каких-то HL. Но чтобы это улу заффектило, нужно чтобы кроме адреса совпала еще комбинация сигналов. Большинство инструкций вообще улу не аффектят (кроме прямого влияния по смыслу операции).

Цитата:

---

Сообщение от Alex Rider

Ага, понял. Если инструкция выполняется дольше 4 тактов, то будет задержка по IR, но не по содержимому регистров.
upd: Вернее, тоже не совсем так, дето не в длительности инсрукции.

---

В таблице внизу (http://scratchpad.wikia.com/wiki/Contended_memory) каждая инструкция расписана по временным интервалам в тиках, в начале каждого интервала процессор может быть задержан в зависимости от значения регистра, указанного вместе с длительностью интервала.

Например, pc:4 означает - на первом такте 4-тактового интервала процессор может быть задержан ULA, если значение PC в данный момент находится в адресах медленной памяти.
Большинство команд могут тормозиться многократно:
pc:4,pc+1:4,ir:1 x 7 => pc:4,pc+1:4,ir:1,ir:1,ir:1,ir:1,ir:1,ir:1,ir:1.

В квадратных скобках указан вариант выполнения команды при выполнении условий команды..

Цитата:

---

Сообщение от weiv

Например, pc:4 означает - на первом такте 4-тактового интервала процессор может быть задержан ULA, если значение PC в данный момент находится в адресах медленной памяти.

---

Ага, сообразил. Вот для ld sp,hl указано: pc:4,ir:1 x 2. Это значит, что процессор тормозится по значениям pc и ir в медленной памяти, но не hl и sp. Потому что ни hl, ни sp на шину во время исполнения не попадают. А вот для ret sp в медленной памяти может вызвать тормоза, потому что происходит косвенное чтение по sp, и он попадает на ША.

---------- Post added at 23:15 ---------- Previous post was at 23:13 ----------

Цитата:

---

Сообщение от ZXMAK

На какихто инструкциях IR на шине болтается, на каких-то PC, на каких-то SP, на каких-то HL.

---

pc на всех, ir - если во время выполнения инструкции предусмотренна регенерация, другие регистры - если их значение выставляется на ША для косвенной адресации памяти или портов.

Цитата:

---

Сообщение от Alex Rider

pc на всех, ir - если во время выполнения инструкции предусмотренна регенерация, другие регистры - если их значение выставляется на ША для косвенной адресации памяти или портов.

---

еще раз повторюсь - регенерация на всех инструкциях есть, но на улу она не влияет. задержки по IR возникают НЕ во время регенерации. Какие инструкции другие регистры выставляют, можно по коду в zxmak2 посмотреть

Спасибо за табличку. Любопытно, contended memory оказалась не такой плохой, какой я ее себе представлял. Где-то раньше слышал, что любая попытка чтения из медленной памяти приводит к задержке процессора до самого конца строки экрана (т.е. задержка до 128 тактов), а оказывается - максимум на 6 тактов, после чего открывается окно в 2 такта для свободного обращения к памяти. Вероятно, в ULA для этого установлено несколько буферных регистров. 2 такта - это, наверное, чтобы один полный цикл доступа к памяти Z80 в них уложился.

Написал простенький тест для замера скорости памяти в тактах на INT на 128К машинах. Можно жать TURBO, смотреть на циферки :)

Вложение 77437