PDA

Просмотр полной версии : Не пойму, как работает "прозрачный доступ" к ОЗУ (читал М.Буна)



IanPo
01.04.2008, 12:03
Что я понял из схемы и статей Буна, так это как
отключаются-подключаются проц и контроллер
к памяти. Но Бун пишет, что контроллер дисплея
и проц друг другу не мешают.
Однако:
1. К линейке ОЗУ одновременно может обратиться
только 1 устройство (проц или контроллер).
2. Вывод на экран не может задерживаться из-за
того, что проц хочет обратиться к памяти.
Вот как это сделано в арбитре - не понимаю.
(Как это сделать с WAIT - примерно понимаю).
Кто-нибудь может объяснить?

icebear
01.04.2008, 12:40
Вот как это сделано в арбитре - не понимаю.
(Как это сделать с WAIT - примерно понимаю).
Кто-нибудь может объяснить?

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

bigral
01.04.2008, 13:47
Общий принцип такой: арбитр тактируется частотой выше (например в два раза) чем самый "быстрый" узел схемы, осуществляющий доступ к памяти. При этом каждый первый такт арбитр подключает один узел к памяти, а каждый второй такт - другой узел. Таким образом общая шина памяти делится между двумя узлами.

:) процессор продолжает выгребать данные с той же скоростью так как его частота не меняется - значит во время доступа проца память должна работать на той же скорости как и раньше, другой вопрос что данные для видеоконтроллера можно успеть выгребсти во время того как процессор производит RЕFRЕSH на большей чем обычно скорости. Такая схема потеряет совместимость со спектрумом (snow effect, contended memory).

icebear
01.04.2008, 14:40
:) процессор продолжает выгребать данные с той же скоростью так как его частота не меняется - значит во время доступа проца память должна работать на той же скорости как и раньше, другой вопрос что данные для видеоконтроллера можно успеть выгребсти во время того как процессор производит RЕFRЕSH на большей чем обычно скорости. Такая схема потеряет совместимость со спектрумом (snow effect, contended memory).

Вспомни, что у Z80 цикл доступа к памяти два-три такта (в зависимости от), это 1). А ВК читает "медленнее" процесcора, так как читает сразу 8 сосдених пикселей (и двигает их потом), это 2). Грубо говоря, память должна успеть отработать на скорости арбитра в самом худшем случае. А такого не произойдёт никогда, т.к. 1) и 2) :)

Есть более продвинутый способ, выгребать данные процессора в промежуточный буфер (обычный регистр, не фифо), ибо адрес и RD или WR висят не один такт процессора в положеном состоянии. Мало того, при таком раскладе память будет работать на половине частоты процессора (снова грубо говроя Т1 - engage, Т2 - execute, Т3 - fetch).

IanPo
02.03.2009, 11:46
Продолжаю думать над схемой, возник такой вопрос:
На диаграмме (рис.13) активизация сигнала CPU, разрешающего процессору доступ к памяти (и отключающего дисп.контроллер), приходится на второй такт. В этом случае схема работает. А если контроллеру нужно считать байт именно во втором такте? Ведь никакой привязки к тактам процессора у него нет, так что может попасть и на второй такт, а по сигналу /MREQ контроллер во 2-м такте отключится от ОЗУ и включится проц. Т.е. контроллеру надо считать, а проц его отключает. Вот никак этот момент не пойму. По картинке сигнал CPU непериодический, т.к. у проца разное количество тактов на операцию, а триггер DD5 работает от /MREQ.

Keeper
02.03.2009, 12:22
Ведь никакой привязки к тактам процессора у него нет

Есть :), Все тактируется от одного генератора...

KALDYH
02.03.2009, 12:33
У Пентагона (наглядный пример компьютера с "прозрачным" доступом к ОЗУ) между памятью и видеовыходом стоит 3 последовательно включенных регистра, образующие FIFO буфер. Особенности работы не помню, схему изучите.

IanPo
02.03.2009, 13:50
Есть :), Все тактируется от одного генератора...

Это я понимаю, но у процессора разное кол-во тактов на операцию (fetch - 4 , read - 3), и контроллер не знает, когда у процессора будет T1.

Zloy
02.03.2009, 14:54
Это я понимаю, но у процессора разное кол-во тактов на операцию (fetch - 4 , read - 3), и контроллер не знает, когда у процессора будет T1.
Тоже задавался таким вопросом... так до конца и не понял.

Keeper
02.03.2009, 15:09
Ведь никакой привязки к тактам процессора у него нет, так что может попасть и на второй такт, а по сигналу /MREQ контроллер во 2-м такте отключится от ОЗУ и включится проц.

В общем видеоконтроллер читает данные из памяти несколько чаще чем ему нужно, по-этому видеоконтроллер не против отдать процессору доступ в "момент Т2". "Момент Т2" как раз и отслеживается триггером D5. А вот для формирования непосредственно изображения данные берутся из REG.DISP, а не из памяти, соответственно конфликта доступа к памяти не будет.

IanPo
02.03.2009, 17:34
В общем видеоконтроллер читает данные из памяти несколько чаще чем ему нужно, по-этому видеоконтроллер не против отдать процессору доступ в "момент Т2". "Момент Т2" как раз и отслеживается триггером D5. А вот для формирования непосредственно изображения данные берутся из REG.DISP, а не из памяти, соответственно конфликта доступа к памяти не будет.

Т.е., один и тот же (расположенный по одному и тому же адресу видеопамяти) байт записывается в регистр по несколько раз?
А где гарантия, что нужный байт будет в итоге записан? :confused_std:
Где гарантия, что когда байт из регистра загрузят в сдвиговый регистр (уже для вывода), то там будет нужное значение? Почему-то М.Бун этот момент не осветил. Может быть, я что-то очевидное упустил? :v2_conf2:

Keeper
02.03.2009, 18:02
Где гарантия, что когда байт из регистра загрузят в сдвиговый регистр (уже для вывода), то там будет нужное значение?

Ну у нас же 1 байт - 8 точек, которые выводятся за 4Т 3,5МГц, т.е. запас есть плюс упреждающее чтение в Т1, а вот в режиме 16c видеоконтроллер занимает все такты и процессор приходиться полностью останавливать на время отрисовки экрана...

Добавлено через 1 минуту

Может быть, я что-то очевидное упустил?

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

IanPo
02.03.2009, 18:20
52 мкс - прямой ход луча
256 точек / 8 точек на байт = 32 байт
+ 32 байт цвета = 64 байт

Время, отводимое на вывод точки:
tb := 52E-6/64
= 8.125E-7

Период тактовой частоты процессора:
Tcpu := 1/3.5E6
= 2.85714286E-7

На вывод точки отводится N тактов процессора = tb/Tcpu = 2.84375

Запас (небольшой), конечно, есть, но где гарантия, что контроллер попадет в T2?

Ewgeny7
02.03.2009, 19:06
Прочитай четвертый мануал, там есть кое-что, даже с осциллограммами:
http://www.zx.pk.ru/showpost.php?p=179392&postcount=39

IanPo
03.03.2009, 11:49
KALDYH
Посмотрел схемы пентагонов (на сайте KoE). Та же схема переключения доступа, что и у Буна. Регистры видел, насколько понял, это в т.ч. для того, чтобы атрибут по 8 раз не считывать, что уменьшает количество обращения к ОЗУ. Но без осциллограмм не очень понятно, а главное, нет ответа на вопрос, как гарантированно считать байт из видеопамяти, если процессор может отключать контроллер, когда ему надо.

ewgeny7
Посмотрел доку, но у Буна по-другому. Насколько я понял, у тебя зона прозрачного доступа меньше полутакта, поэтому используется быстрая статика (кстати, время доступа почему-то написано 15 мкс, а не наносекунд).

Добавлено через 7 часов 11 минут
Единственное, что мне приходит в голову: адрес дисплейного контроллера меняется не чаще, чем раз в 2 такта. Т.е. один и то же адрес держится >=2 тактов, тогда контроллер может считать нужный байт до или после T2.

Conan
03.03.2009, 22:10
IanPo
ОЗУ в ZX Spectrum имеет разрядность слова в 8 бит. То есть считать один бит (пикселей, атрибутов, данных) не считывая другие нельзя, считаются сразу все 8 бит.
Принцип работы (упрощенно) такой: относящиеся к одному знакоместу атрибуты и пиксели считываются из ОЗУ в разное время (последовательно), в промежуточные регистры, откуда и используются (параллельно) для формирования RGBY одного знакоместа. Затем процесс повторяется для следующего знакоместа...
Количество обращений к ОЗУ тут ни при чем.

Что касается "прозрачного доступа к ОЗУ", то все примитивно:
есть промежуток времени (машинный цикл) продолжительностью в 4 такта CPU. В этом промежутке видеопроцессор дважды читает из ОЗУ (те самые байты пикселей и атрибутов). Поскольку чтение производится в промежуточные регистры, не имеет значения в каких двух, из четырех тактов будут считаны атрибуты-пиксели. В "пентагонах" последовательность чтения из ОЗУ в машинном цикле может меняться, например.

При этом CPU всегда получает доступ к ОЗУ из-за того, что самый короткий цикл чтения (fetch) занимает 2 такта. То есть если CPU требуется доступ к ОЗУ, а в это время оттуда считывается байт пикселей или атрибутов, то в следующем такте ОЗУ будет доступно процессору. И для CPU считавшего или записавшего данные из/в ОЗУ оно будет "прозрачным", то есть доступным без ожидания (циклов WAIT).

IanPo
04.03.2009, 11:48
Conan
Понял, спасибо.
Один вопрос только остался невыясненным: может ли тогда один и тот же байт из видеопамяти быть считан 2 раза (в регистр)? Предположим, что процессор в этот момент обрабатывает последовательность NOP из ПЗУ и у контроллера, фактически, монопольный доступ к ОЗУ.

Conan
04.03.2009, 12:24
может ли тогда один и тот же байт из видеопамяти быть считан 2 раза (в регистр)?Зависит от аппаратной реализации "прозрачного режима". Их два: синхронный и асинхронный.
В "пентагонах" - асинхронный, поэтому в них пиксели или атрибуты читаются по нескольку раз, а за промежуточными регистрами, стоят еще регистры ;), куда читается (из промежуточных регистров) уже строго когда надо (выводить атрибуты и пиксели конкретного знакоместа).

В синхронном режиме по два раза могут читаться данные для CPU. Проще говоря чтение из памяти идет через раз:
CPU-ATR-CPU-PIC
Синхронный режим требователен к сигналам управляющим ОЗУ, регистрами и т.д. Но имеет ряд преимуществ. Одно из них это дополнительная регенерация ОЗУ (адресами CPU). Ибо в подавляющем большинстве отечественных клонов этот параметр (период регенерации) запредельный для наших микросхем.

Keeper
04.03.2009, 12:59
Зависит от аппаратной реализации "прозрачного режима". Их два: синхронный и асинхронный.

Спасибо за ликбез. Скажите, в каком из клонов использован синхронный режим? Насколько я понял у Буна описан асинхронный режим...

fan
04.03.2009, 20:46
КАЙ и выпрямленный ленинград .

Mick
04.03.2009, 21:11
Спасибо за ликбез. Скажите, в каком из клонов использован синхронный режим?

Практически во всех :) и даже у меня.
Еще дополню малость. При этом режиме частота процессора как бы смещена относительно частоты счетчиков, а именно относительно H0(3,5МГц). Синхронность достигается сигналом H1(1,75МГц), который состоит из двух фаз 0 и 1. Так вот при H1 = 0 доступ к памяти осуществляет процессор, а при H1 =1 доступ разрешен видеоконтроллеру. Переключение видео и атрибутов происходит сигналом H2(0,875МГц). При Н2 =0 запоминается видеоинформация, при H2 =1 запоминаются атрибуты.
А так как при активизации процессорного доступа к памяти информация из ОЗУ(при чтении) запоминается в промежуточном регистре, то информация всегда достоверна и процессор, у которого неокорые такты могут попасть на фазу видеоконтроллера читает информацию из промежуточного регистра. Т.е. процессор даже не в курсе что есть еще видео контроллер, а видеоконтроллер в свою очередь не знает что еще есть один нахлебник - процессор, но доступ у них строго регламентирован или синхонизирован.
Синхронный режим наиболее простой и удобный :)

KALDYH
04.03.2009, 21:15
Тогда у меня вопрос. Можно ли "малой кровью" сделать в Ленинград-подобных машинах прозрачный доступ к памяти?

Mick
04.03.2009, 21:24
Тогда у меня вопрос. Можно ли "малой кровью" сделать в Ленинград-подобных машинах прозрачный доступ к памяти?

А смысл? Никаких существенных выигрышей нет. Все теже такты, лишних то не будет. Скорость не увеличится ни как :)
Прозрачный доступ делался в основном в компах на процессоре КР580ВМ80. Просто по другому там достаточно сложно было сделать.

fan
04.03.2009, 21:43
На ленинград была схема доработки .

Добавлено через 3 минуты
http://sblive.narod.ru/ZX-Spectrum/Leningrad48k/WMG5.zip

KALDYH
04.03.2009, 21:55
А смысл? Никаких существенных выигрышей нет. Все теже такты, лишних то не будет. Скорость не увеличится ни как
Есть смысл, и скорость увеличится. Избавляемся от сигнала /WAIT и получаем честные 69988 тактов на прерывание, а не левую величину в районе 67 тысяч. Можно будет демы смотреть без тормозов и доработать машину до полной совместимости по тактам с Пентагоном.

Mick
04.03.2009, 22:11
Есть смысл, и скорость увеличится. Избавляемся от сигнала /WAIT и получаем честные 69988 тактов на прерывание, а не левую величину в районе 67 тысяч. Можно будет демы смотреть без тормозов и доработать машину до полной совместимости по тактам с Пентагоном.

Ну на самом деле, от WAITа и так избавлялись и получали те самые нужные 69888 тактов. В качестве примера. Я ставил эксперимент над компьютером ZX-777(еще когда он был в строю), убирал WAIT и по совету Conan'a изменил схему включения счетчика ИЕ7. И все проблема исчезла. :)

IanPo
05.03.2009, 11:48
Практически во всех :) и даже у меня.
А где можно посмотреть временные диаграммы? :v2_wink2:

Conan
05.03.2009, 18:23
Скажите, в каком из клонов использован синхронный режим?К уже перечисленным ребятами моделям добавлю, что самый ранний клон с синхронным режимом (о котором известно) был "Красногорск". Его отличительной чертой было использование РФ2(5), как дешифратора для формирования различных сигналов.

Mick
05.03.2009, 21:21
А где можно посмотреть временные диаграммы? :v2_wink2:

Когдато, когда начинал баловаться на палках, нарисовал для себя диаграмму. Что же, возможно она кому еще пригодится :)
Вот примерный расклад растактовки синхронного режима.

bigral
06.03.2009, 00:48
Когдато, когда начинал баловаться на палках, нарисовал для себя диаграмму. Что же, возможно она кому еще пригодится :)
Вот примерный расклад растактовки синхронного режима.

Как же так вместе с CAS сигналом защелкивается регистр данных для процессора? Надо бы сдвинуть на четверть такта чтоб успела шина данных устаканиться? Аналогично защелка для видеоконтроллера - может ей немного подождать после CAS-a?

Mick
06.03.2009, 08:08
Как же так вместе с CAS сигналом защелкивается регистр данных для процессора? Надо бы сдвинуть на четверть такта чтоб успела шина данных устаканиться? Аналогично защелка для видеоконтроллера - может ей немного подождать после CAS-a?

Информация защелкивается по окончанию импульса WRBUF. И что тебе не понятно. Или ты забыл как работает микросхема ИР22

bigral
06.03.2009, 15:58
Информация защелкивается по окончанию импульса WRBUF. И что тебе не понятно. Или ты забыл как работает микросхема ИР22

Просто думал что WRBUF должен на четверть такта ранее заканчиватся, как раз перед переходом CAS в 1.

ARTi
02.02.2010, 03:56
Хотел бы поднять тему как очередной тупица, который лишь примерно понял принцип прозрачного доступа к ОЗУ. Как я понял, соль в том, что процессору память чаще чем раз в 3 такта (процессорных) не нужна, при этом минимум 1.5 такта удерживается адрес, который можно использовать сразу в первом такте чтения, запомнив результат в регистре, содержимое которого, в свою очередь, выставить на шину данных процессора вплоть до завершения цикла доступа. Так что такта 2 (процессорных) из 3 достаются видеоконтроллеру.
Примерно та же ли тема используется и в Scorpion? Вопрос, что тогда происходит при повышении частоты процессора в 2 раза?