Что я понял из схемы и статей Буна, так это как
отключаются-подключаются проц и контроллер
к памяти. Но Бун пишет, что контроллер дисплея
и проц друг другу не мешают.
Однако:
1. К линейке ОЗУ одновременно может обратиться
только 1 устройство (проц или контроллер).
2. Вывод на экран не может задерживаться из-за
того, что проц хочет обратиться к памяти.
Вот как это сделано в арбитре - не понимаю.
(Как это сделать с WAIT - примерно понимаю).
Кто-нибудь может объяснить?
Общий принцип такой: арбитр тактируется частотой выше (например в два раза) чем самый "быстрый" узел схемы, осуществляющий доступ к памяти. При этом каждый первый такт арбитр подключает один узел к памяти, а каждый второй такт - другой узел. Таким образом общая шина памяти делится между двумя узлами.Цитата:
Сообщение от IanPo
:) процессор продолжает выгребать данные с той же скоростью так как его частота не меняется - значит во время доступа проца память должна работать на той же скорости как и раньше, другой вопрос что данные для видеоконтроллера можно успеть выгребсти во время того как процессор производит RЕFRЕSH на большей чем обычно скорости. Такая схема потеряет совместимость со спектрумом (snow effect, contended memory).Цитата:
Сообщение от icebear
Вспомни, что у Z80 цикл доступа к памяти два-три такта (в зависимости от), это 1). А ВК читает "медленнее" процесcора, так как читает сразу 8 сосдених пикселей (и двигает их потом), это 2). Грубо говоря, память должна успеть отработать на скорости арбитра в самом худшем случае. А такого не произойдёт никогда, т.к. 1) и 2) :)Цитата:
Сообщение от bigral
Есть более продвинутый способ, выгребать данные процессора в промежуточный буфер (обычный регистр, не фифо), ибо адрес и RD или WR висят не один такт процессора в положеном состоянии. Мало того, при таком раскладе память будет работать на половине частоты процессора (снова грубо говроя Т1 - engage, Т2 - execute, Т3 - fetch).
Продолжаю думать над схемой, возник такой вопрос:
На диаграмме (рис.13) активизация сигнала CPU, разрешающего процессору доступ к памяти (и отключающего дисп.контроллер), приходится на второй такт. В этом случае схема работает. А если контроллеру нужно считать байт именно во втором такте? Ведь никакой привязки к тактам процессора у него нет, так что может попасть и на второй такт, а по сигналу /MREQ контроллер во 2-м такте отключится от ОЗУ и включится проц. Т.е. контроллеру надо считать, а проц его отключает. Вот никак этот момент не пойму. По картинке сигнал CPU непериодический, т.к. у проца разное количество тактов на операцию, а триггер DD5 работает от /MREQ.
Есть :), Все тактируется от одного генератора...Цитата:
Сообщение от IanPo
У Пентагона (наглядный пример компьютера с "прозрачным" доступом к ОЗУ) между памятью и видеовыходом стоит 3 последовательно включенных регистра, образующие FIFO буфер. Особенности работы не помню, схему изучите.
Это я понимаю, но у процессора разное кол-во тактов на операцию (fetch - 4 , read - 3), и контроллер не знает, когда у процессора будет T1.Цитата:
Сообщение от Keeper
Тоже задавался таким вопросом... так до конца и не понял.Цитата:
Сообщение от IanPo
В общем видеоконтроллер читает данные из памяти несколько чаще чем ему нужно, по-этому видеоконтроллер не против отдать процессору доступ в "момент Т2". "Момент Т2" как раз и отслеживается триггером D5. А вот для формирования непосредственно изображения данные берутся из REG.DISP, а не из памяти, соответственно конфликта доступа к памяти не будет.Цитата:
Сообщение от IanPo
Т.е., один и тот же (расположенный по одному и тому же адресу видеопамяти) байт записывается в регистр по несколько раз?Цитата:
Сообщение от Keeper
А где гарантия, что нужный байт будет в итоге записан? :confused_std:
Где гарантия, что когда байт из регистра загрузят в сдвиговый регистр (уже для вывода), то там будет нужное значение? Почему-то М.Бун этот момент не осветил. Может быть, я что-то очевидное упустил? :v2_conf2:
Ну у нас же 1 байт - 8 точек, которые выводятся за 4Т 3,5МГц, т.е. запас есть плюс упреждающее чтение в Т1, а вот в режиме 16c видеоконтроллер занимает все такты и процессор приходиться полностью останавливать на время отрисовки экрана...Цитата:
Сообщение от IanPo
Добавлено через 1 минуту
Должен признать что механизм не совсем очевидный, по крайней мере я не сразу понял что происходит...Цитата:
Сообщение от IanPo
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?
Прочитай четвертый мануал, там есть кое-что, даже с осциллограммами:
http://www.zx.pk.ru/showpost.php?p=179392&postcount=39
KALDYH
Посмотрел схемы пентагонов (на сайте KoE). Та же схема переключения доступа, что и у Буна. Регистры видел, насколько понял, это в т.ч. для того, чтобы атрибут по 8 раз не считывать, что уменьшает количество обращения к ОЗУ. Но без осциллограмм не очень понятно, а главное, нет ответа на вопрос, как гарантированно считать байт из видеопамяти, если процессор может отключать контроллер, когда ему надо.
ewgeny7
Посмотрел доку, но у Буна по-другому. Насколько я понял, у тебя зона прозрачного доступа меньше полутакта, поэтому используется быстрая статика (кстати, время доступа почему-то написано 15 мкс, а не наносекунд).
Добавлено через 7 часов 11 минут
Единственное, что мне приходит в голову: адрес дисплейного контроллера меняется не чаще, чем раз в 2 такта. Т.е. один и то же адрес держится >=2 тактов, тогда контроллер может считать нужный байт до или после T2.
IanPo
ОЗУ в ZX Spectrum имеет разрядность слова в 8 бит. То есть считать один бит (пикселей, атрибутов, данных) не считывая другие нельзя, считаются сразу все 8 бит.
Принцип работы (упрощенно) такой: относящиеся к одному знакоместу атрибуты и пиксели считываются из ОЗУ в разное время (последовательно), в промежуточные регистры, откуда и используются (параллельно) для формирования RGBY одного знакоместа. Затем процесс повторяется для следующего знакоместа...
Количество обращений к ОЗУ тут ни при чем.
Что касается "прозрачного доступа к ОЗУ", то все примитивно:
есть промежуток времени (машинный цикл) продолжительностью в 4 такта CPU. В этом промежутке видеопроцессор дважды читает из ОЗУ (те самые байты пикселей и атрибутов). Поскольку чтение производится в промежуточные регистры, не имеет значения в каких двух, из четырех тактов будут считаны атрибуты-пиксели. В "пентагонах" последовательность чтения из ОЗУ в машинном цикле может меняться, например.
При этом CPU всегда получает доступ к ОЗУ из-за того, что самый короткий цикл чтения (fetch) занимает 2 такта. То есть если CPU требуется доступ к ОЗУ, а в это время оттуда считывается байт пикселей или атрибутов, то в следующем такте ОЗУ будет доступно процессору. И для CPU считавшего или записавшего данные из/в ОЗУ оно будет "прозрачным", то есть доступным без ожидания (циклов WAIT).
Conan
Понял, спасибо.
Один вопрос только остался невыясненным: может ли тогда один и тот же байт из видеопамяти быть считан 2 раза (в регистр)? Предположим, что процессор в этот момент обрабатывает последовательность NOP из ПЗУ и у контроллера, фактически, монопольный доступ к ОЗУ.
Зависит от аппаратной реализации "прозрачного режима". Их два: синхронный и асинхронный.Цитата:
Сообщение от IanPo
В "пентагонах" - асинхронный, поэтому в них пиксели или атрибуты читаются по нескольку раз, а за промежуточными регистрами, стоят еще регистры ;), куда читается (из промежуточных регистров) уже строго когда надо (выводить атрибуты и пиксели конкретного знакоместа).
В синхронном режиме по два раза могут читаться данные для CPU. Проще говоря чтение из памяти идет через раз:
CPU-ATR-CPU-PIC
Синхронный режим требователен к сигналам управляющим ОЗУ, регистрами и т.д. Но имеет ряд преимуществ. Одно из них это дополнительная регенерация ОЗУ (адресами CPU). Ибо в подавляющем большинстве отечественных клонов этот параметр (период регенерации) запредельный для наших микросхем.
Спасибо за ликбез. Скажите, в каком из клонов использован синхронный режим? Насколько я понял у Буна описан асинхронный режим...Цитата:
Сообщение от Conan
КАЙ и выпрямленный ленинград .
Практически во всех :) и даже у меня.Цитата:
Сообщение от Keeper
Еще дополню малость. При этом режиме частота процессора как бы смещена относительно частоты счетчиков, а именно относительно H0(3,5МГц). Синхронность достигается сигналом H1(1,75МГц), который состоит из двух фаз 0 и 1. Так вот при H1 = 0 доступ к памяти осуществляет процессор, а при H1 =1 доступ разрешен видеоконтроллеру. Переключение видео и атрибутов происходит сигналом H2(0,875МГц). При Н2 =0 запоминается видеоинформация, при H2 =1 запоминаются атрибуты.
А так как при активизации процессорного доступа к памяти информация из ОЗУ(при чтении) запоминается в промежуточном регистре, то информация всегда достоверна и процессор, у которого неокорые такты могут попасть на фазу видеоконтроллера читает информацию из промежуточного регистра. Т.е. процессор даже не в курсе что есть еще видео контроллер, а видеоконтроллер в свою очередь не знает что еще есть один нахлебник - процессор, но доступ у них строго регламентирован или синхонизирован.
Синхронный режим наиболее простой и удобный :)
Тогда у меня вопрос. Можно ли "малой кровью" сделать в Ленинград-подобных машинах прозрачный доступ к памяти?
А смысл? Никаких существенных выигрышей нет. Все теже такты, лишних то не будет. Скорость не увеличится ни как :)Цитата:
Сообщение от KALDYH
Прозрачный доступ делался в основном в компах на процессоре КР580ВМ80. Просто по другому там достаточно сложно было сделать.
На ленинград была схема доработки .
Добавлено через 3 минуты
http://sblive.narod.ru/ZX-Spectrum/L...ad48k/WMG5.zip
Есть смысл, и скорость увеличится. Избавляемся от сигнала /WAIT и получаем честные 69988 тактов на прерывание, а не левую величину в районе 67 тысяч. Можно будет демы смотреть без тормозов и доработать машину до полной совместимости по тактам с Пентагоном.Цитата:
Сообщение от Mick
Ну на самом деле, от WAITа и так избавлялись и получали те самые нужные 69888 тактов. В качестве примера. Я ставил эксперимент над компьютером ZX-777(еще когда он был в строю), убирал WAIT и по совету Conan'a изменил схему включения счетчика ИЕ7. И все проблема исчезла. :)Цитата:
Сообщение от KALDYH
А где можно посмотреть временные диаграммы? :v2_wink2:Цитата:
Сообщение от Mick
К уже перечисленным ребятами моделям добавлю, что самый ранний клон с синхронным режимом (о котором известно) был "Красногорск". Его отличительной чертой было использование РФ2(5), как дешифратора для формирования различных сигналов.Цитата:
Сообщение от Keeper
Когдато, когда начинал баловаться на палках, нарисовал для себя диаграмму. Что же, возможно она кому еще пригодится :)Цитата:
Сообщение от IanPo
Вот примерный расклад растактовки синхронного режима.
Как же так вместе с CAS сигналом защелкивается регистр данных для процессора? Надо бы сдвинуть на четверть такта чтоб успела шина данных устаканиться? Аналогично защелка для видеоконтроллера - может ей немного подождать после CAS-a?Цитата:
Сообщение от Mick
Информация защелкивается по окончанию импульса WRBUF. И что тебе не понятно. Или ты забыл как работает микросхема ИР22Цитата:
Сообщение от bigral
Просто думал что WRBUF должен на четверть такта ранее заканчиватся, как раз перед переходом CAS в 1.Цитата:
Сообщение от Mick
Хотел бы поднять тему как очередной тупица, который лишь примерно понял принцип прозрачного доступа к ОЗУ. Как я понял, соль в том, что процессору память чаще чем раз в 3 такта (процессорных) не нужна, при этом минимум 1.5 такта удерживается адрес, который можно использовать сразу в первом такте чтения, запомнив результат в регистре, содержимое которого, в свою очередь, выставить на шину данных процессора вплоть до завершения цикла доступа. Так что такта 2 (процессорных) из 3 достаются видеоконтроллеру.
Примерно та же ли тема используется и в Scorpion? Вопрос, что тогда происходит при повышении частоты процессора в 2 раза?