Господа "спектрумисты", вы вообще в курсе, откуда появился этот самый ИР22 в схеме спектрума на россыпи (а конкретно - в Ленинграде)? Фундаментальная причина.
Надо больше смайликов, а то недостаточно эмоционально. В zx8080 без ИР22 не получится прочитать данные из озу если DBIN начинается в конце временного слота CPU и заканчивается во временном слоте VPU. А тонкое место - чтение когда DBIN начинается в конце временного слота VPU и заканчивается во временном слоте CPU, вот тут все очень напряженно по времени.
- - - Добавлено - - -
Уточню для полной однозначности - не получится прочитать из озу в проц
Уже тыщу раз сказано: M1 у него на 0->1, а M2/M3/Mn на 1->0. Проц синхронизирован к RAS что автоматом даёт правильное окно доступа к M2+, а во время M1 данные щёлкаем в регистр, всё равно M1 это всегда только чтение. i8080 же (он же ВМ80) в любом цикле работает по 0->1 в F2, что делает синхронизацию к ОЗУ идеальной а наличие данного регистра бессмысленным.
Только ответь мне, насколько напряжнее по сравнению с использованием Z80 (оригинальная схема) или, например, того же Ориона с Z80 Card? Я молчу про свой MX2 потому что там SRAM, но она легко может быть заменена на DRAM необходимой производительности (SIMM72 вполне подходят).
Я смотрю схему и вижу, что F2 формируется из RAS, что даёт полную автоматическую синхронизацию процессора к DRAM (как и в оригинале на Z80 для машинных циклов 2+), при этом торможение через READY (это инверси от nWAIT у Z80 по названию, но не по логическому уровню сигнала) не задействовано. А значит процессор маслает как есть и его запись заведомо попадает в ОЗУ без конфликта с синхрогенератором. При этом сигнал WR позаботились маскировать до положенный DRAM величин (режим Late WE, кстати), а вот чтение внезапно нет (но тут и не надо, ибо если процессор читает из ОЗУ то шина данных занята именно процессором и только самим ОЗУ). И почему это не должно сработать, если чтение нигде не маскируется, а вот запись маскируется именно по спаду?
Повторюсь ещё раз: в оригинальном Ленинграде входы DI у DRAM висели на шине данных процессора потому, что запись была засинхронизирована строго с ОЗУ в определённой фазе тактового сигнала Z80. Бонусом получали такую же синхронизацию на чтение в машинных циклах М2+ (это чтение дополнительных байт опкода и/или данных, которые идут в той же фазе что и запись). А вот чтение опкода в цикле M1 данные требовались уже в следующей фазе тактового сигнала и поэтому данные надо задержать на полтакта, чем ИР22 и занималась. И работать там могла только ИР22 как прозрачная защёлка, чтобы не нарушить чтение в М2+. Этот регистр работает как EDO у DRAM на SIMM72. И торможение в Ленинграде именно из-за этого висит на M1 процессора. Блин, ну вы первоисточник то разложите уже в том же Протеусе или на миллиметровке. i8080 вам подарок преподносит своей правильной синхронизацией.
А что касается этого вашего:
Что я могу сказать? Могу только показать правильные эпюры работы i8080:
PS Я понял, схема ТСа не взлетит без синхронизации. В общем, упоминая тот факт, что оригинальная схема Ленинграда делает 4 обращения на каждые 8 точек, из них сами обращения идут вот так: GCAC (G - графика, A - атрибуты, C - CPU). Очевидно, что память доступна процессору только в каждый чётный (или нечётный - смотря как посмотреть) цикл обращения, а команды не всегда чётны в своих циклах. И казалось бы, должна сбиваться синхронизация, верно? Нет, не верно. Требуемая синхронизация сделана за счёт торможения на M1. Из-за особенности Z80, для получения данных в М1 его надо остановить. А вот М2 и далее циклы строго определённой длины и поэтому запись и чтение в M2+ получается автоматически. Синхронизация повторится на следующей команде. А вот i8080 не имеет такой особенности в цикле M1. Поэтому в компьютерах, основанных на ВМ80 главный приоритет отдан самому процессору, который изъявляет своё желание в обращении через установку SYNC, задержав на такт который мы и получаем арбитраж. А чтобы синхрогенератор не показывал снег перед регистрами графики и атрибутов ставятся защёлки, которые сохранят предыдущие данные, если процессор вклинился.
// Здесь был видос с матом, был не прав и слишком груб, удалил. Оставлю только текстовый эквивалент:
Всё фигня, давай по новой.
Последний раз редактировалось HardWareMan; 09.10.2020 в 13:51.
Взял временные диаграммы Micka и некрасиво обвел красным те DBINы, которые не прочитают нормально без ИР22
ivagor, ты обвёл ровно те обращения, которые конфликтуют с синхрогенератором. И длина DBIN, как ты там писал выше, никакой роли тут не играет. А всё потому, что в этой схеме нет ни арбитража, ни синхронизации.
Не помню, где писал про длину DBIN, я писал про то где начинается и (что важнее) заканчивается, и писал в основном для идентификации.
Мне видятся две разные возможные проблемы в этих двух группах чтений:
1. Для "обведенных" критично чтобы проц успел выставить адрес и он дошел до озу к началу /ras. Тогда прочитает в ИР22, а уж прочитать из ИР22 проблем нет.
2. Оставшиеся чтения очень критичны к скорости озу и всем задержкам на пути. Но может повезет, Mick соберет с использованием быстрой памяти и 1531 в качестве D33 (и D30, если поставит) и чтение процом будет работать в полном объеме.
HardWareMan, если ты агитируешь за то, чтобы быть здоровым и богатым, то вряд ли кто-то против. Думаю никто из интересующихся темой не сомневается, что можно спроектировать вариант с прозрачным доступом к памяти при проце 3.5 МГц и при использовании сравнительно умеренных по сегодняшним меркам микросхем озу. Осталось начать и закончить. Сам я сначала думал, что Mick хочет минимальной ценой заменить в ленинграде z80 на 8080, в этом случае проще всего было бы ввести торможение проца. Ну или снизить частоту проца вдвое, как предлагал NEO SPECTRUMAN.
Но у Mickа свое видение и свои приоритеты (из которых я четко понимаю только один - он хочет максимально быстрый 8080. Еще возможно он хочет сохранить ленинградскую выборку видео). На данный момент только он серьезно занимается данной темой, и т.к. мне интересна замена z80->8080 я стараюсь не сильно мешать и иногда даже немного помогать. Если бы железячники активнее учавствовали, то я бы в hard не стал лезть. Не сомневаюсь, что Mick обнаружил бы ошибки, которые я заметил, просто это потребовало бы времени и сил. Если кто-то задумает альтернативный проект, спроектирует схему, разведет плату, закажет плату и детали, соберет и похвастается рабочим компом - это тоже будет очень интересно. Ну или можно попробовать повлиять на Mickа, желательно поконструктивнее.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)