Орион-128: Разное

[Stampmaker]

А куда Вы истратите второй триггер из корпуса ТМ2 ?

наверное, разумнее всего истратить этот триггер на переключение ТУРБО-НЕТУРБО

да, я так и хочу сделать.

При включении НЕТУРБО надо не только менять клок на входе CLK, но и надо блокировать формирователь WAIT D5.1 путем подачи 0 на вход S D5.2 вместо /RESET)

а зачем, разве недостаточно просто менять частоты с одной на другую?


схема ТУРБО-НЕТУРБО была опубликована здесь
http://zx-pk.ru/threads/17580-sborka...l=1#post880245

вот она



с нашим свободным триггером схема будет такая



ЛЕ1 можно припаять сверху на ТМ2, помимо питания припаивается вывод 5 (именно поэтому я поменял местами выводы 5 и 6)

после включения питания на ТМ2/5 будет "0", а значит сразу режим ТУРБО (судя по схеме, переключатель работает именно так)

[Advertiser]

[barsik]

Эта схема коммутации клока - вообще нехорошая. Это вариация аделаидской схемы Турбо-142%, которую я считаю "химией".

Это не коммутация клоков, а их логическое сложение. Начертите диаграммы сложения такта 5 и 2.5 МГЦ и Вы увидите, что это не эквивалентно коммутации клоков на мультиплексоре. Поэтому эта схема никак не может работать на такте 10 МГЦ, а только на 5 и, и-то только в этой полярности сигналов (т.е не даёт возможности подобрать наиболее выгодный клок, а это может быть инверсия сигналов 42 или 43) и не даёт возможности сдвигать клок задержками на последовательных вентилях. Но главное, схема с нормальной коммутацией клоков работает при 7.5 и 10 МГЦ (если сам Z80 достаточно быстрый), а эта схема "химии" не может.

В раннем варианте Z80 от ОРИОН-СЕРВИС с тактом 2.5 МГЦ WAIT не используется. Отличие варианта 3.10 от 3.20 заключается в том, что для 5-ти МГЦ добавляется узел на D8.1 и D8.2, что удлиняет ZSYNC и, соответсвенно, WAIT ещё на пол такта частоты 2.5 МГЦ, т.е на такт частоты 5 МГЦ. Итого общее число тактов WAIT добавляемое в схеме ОРИОН-СЕРВИС составляет 1 период частоты 2.5 МГЦ и ещё пол периода частоты 2.5 МГЦ. Итого, это 3 периода частоты 5 МГЦ, а достаточно ввести WAIT лишь на один такт частоты 5 МГЦ. Т.е задержка больше, чем минимально необходимо. Из-за этого и приходится вводить "химию" и вешать 20-ти ногие печко-образные регистры ИР82 вторым этажом.

Если сравнить узел формирования WAIT в моей схеме Турбо-142% с узлом D5.1 и D5.2 (+ D8.1, D8.2) в схеме ОРИОН-СЕРВИС, то видно, что WAIT в обоих схемах возникает одновременно, но длится по-разному. В моей схеме второй триггер взводится и сбрасывает WAIT уже следующим тактовым импульсом 5 МГЦ, отчего WAIT длится только 1 маш.такт, что и требуется. А в схеме ОРИОН-СЕРВИС второй триггер, сбрасывающий WAIT, тактируется не тактом 5 МГЦ, как у меня, а тактом в 2.5 МГЦ. Что приводит к тому, что WAIT уже изначально длится период 2.5 МГЦ, т.е два такта частоты 5 МГЦ. Но более того, в варианте 3.20 добавили узел D8.1 и D8.2, что продлевает WAIT ещё на пол такта 2.5 МГЦ. Итого имеем 3 такта WAIT частоты 5 МГЦ. Это излишне на такте 5 МГЦ, но, видимо, необходимо на такте 10 МГЦ. Вероятно это и позволяет схеме ОРИОН-СЕРВИС работать на 10 МГЦ.

Если при такте в 2.5 МГЦ подачу /WAIT на 1.5 периода частоты 2.5 МГЦ не отключать, то вероятно, благодаря переделке N3 и применению ИР82 ничего плохого и не будет (кроме небольшого снижения быстродействия и блёсток на экране). Хотя в варианте установки Z80 V3.10, т.е на такте 2.5 МГЦ никакой WAIT не используется.

Я хочу сказать, что при такте 2.5 МГЦ всё желательно вернуть к базовой схеме, т.е в НЕТУРБО надо исключить подачу /WAIT на Z80 (удобно тем же мультиплексором, что коммутирует такт или схемой с диодами подавать "1" на вход /WAIT). Блокирование формирователя WAIT D5.1 путем подачи 0 на вход S D5.2, как предложено ранее (и как это в моей схеме Турбо-142%), не годится, т.к это одновременно отключает и формирование ZSYNC, а в схеме ОРИОН-СЕРВИС формирование WAIT и ZSYNC сделано на одном и том же триггере D5.1.

Введение одного такта WAIT обычно не вредит при такте 2.5 МГЦ. И это использовалось для повышения надёжности КНГМД при КР580 (при Z80 это менее актуально, т.к там /RD /WR длиннее). Но введение двух и более тактов WAIT вредит, - на экране появляются блёстки. В данной схеме на такте 2.5 МГЦ вводится 1.5 такта WAIT (частоты CLK 2.5 МГЦ). В зависимости от фронтов, Z80 это может воспринимать как 1 или как 2 такта WAIT. Если как 1 такт, то всё в порядке, будет лишь чуть тормознее 2.5 МГЦ. А вот, если как 2 такта, то даже, если будет работать, на экране будут блёстки.

Это я пояснил, почему мне кажется, что подачу /WAIT на Z80 на такте 2.5 МГЦ надо отключать.

Исходя из вышеизложенного, теоретически, схема ОРИОН-СЕРВИС на такте 5 МГЦ должна давать меньшее быстродействие чем обычная схема Турбо с WAIT на 5 МГЦ, дающая ускорение в 1.41 раза. По слухам, по кранней мере, ранние схемы Z80 от ОРИОН-СЕРВИС на 5 МГЦ давали ускорение в 1.25.

[uart]

barsik, что то я запутался
Я считал, что в Орион-Сервис 3.1 такты идут стандартно: 1, 2, 3, 4, ...
В 3.2 просто добавляется wait: 1, 2, w, 3, 4, ...

А как на самом деле расположены такты? И как дело обстоит в командах in/out, где в Z80 уже есть дополнительный wait?

[barsik]

В версии 3.20 просто добавляется WAIT: 1, 2, w, 3, 4, ...

Не важно на каком такте цикла добавляются WAIT-ы. А важно сколько тактов WAIT добавляется.
Речь шла о том, что в режиме НЕТУРБО формирование сигнала /WAIT надо отключать.

Видео-генератор даёт процессору для доступа к ОЗУ только один машинный такт частоты 2.5 МГЦ. Поэтому продлевать время доступа долее, чем до окончания периода 2.5 МГЦ незачем и только приводит к проблемам. Если в OUT-командах уже есть дополнительный такт WAIT, то это только приводит к проблемам на такте 2.5 МГЦ. А на такте 5 МГЦ нет, просто при 5 МГЦ аппаратный WAIT дополняется программным встроенным в Z80. Но WAIT в схеме Z80 вводят не для команд OUT, а для обычных команд работы с памятью.

А при 2.5 МГЦ команды IN/OUT адресованные в ОЗУ тоже получают ненужный такт WAIT, встроенный внутри Z80. Отчего команды IN/OUT адресованные в ОЗУ на такте 2.5 МГЦ читают и пишут чушь. Т.к защелкивание считываемых данных происходит по фронту /MREQ, когда уже целый такт буфер ОЗУ и буфер CPU закрыты. Запись в ОЗУ командой OUT адресуемой в ОЗУ, возможно, сработает, а вот чтение по IN - нет. Т.е и вводить подмену старших адресов для команд IN/OUT при такте 2.5 МГЦ просто не имело смысла. Это как раз тот случай, когда WAIT встроенный в Z80 для команд OUT вреден. А вот на такте 5 МГЦ команды IN/OUT адресуемые в ОЗУ сработают.

У меня никогда не было схемы с подменой команд OUT на команды записи в ОЗУ, так что любопытно работает ли команда IN и команда OUT адресуемая в ОЗУ (т.е с N порта менее F4) на схеме ОРИОН-СЕРВИС с тактом 2.5 МГЦ.

[LeoN65816]

Комрады, быть может Вам будет интересно: "MSX super turbo 3.0". Там особое внимание уделено моменту переключения частот.

[uart]

Не важно на каком такте цикла добавляются WAIT-ы. А важно сколько тактов WAIT добавляется.

Как это не важно? Процессор тормозит только на определенных тактах цикла, все остальные WAIT процессору побоку.
Ну а мне важно, что бы понять для себя.

[OrionExt]

Комрады, быть может Вам будет интересно: "MSX super turbo 3.0". Там особое внимание уделено моменту переключения частот.

В правильном направлении идете товарищ

По классике правильно снижать частоту к медленным устройствам.

Только многоножку с диодами, я бы заменил на один сигнал с ОК. С целью экономии ножек на системном разъеме. Но это я забегаю уже вперед

[barsik]

Как это не важно на каком такте цикла добавляются WAIT-ы?
Мне важно, что бы понять для себя

Не понимаю, чего здесь сложного. Идея WAIT примитивна. Включение тактов WAIT с целью удлинения времени доступа процессора в ОРИОНЕ с тактом более 2.5 МГЦ вызвано особенностями работы применённого типа ОЗУ и схемой синхронизации с видео частью.

А именно, считываемые данные готовы для фиксации в CPU спустя ~150 НСЕК после /CAS=0 и прекращаются по переднему (0->1) фронту /CAS. /CAS в моей схеме 2.5 МГЦ совпадает с CLK (Ф1 КР580). В схеме ОРИОН-СЕРВИС 2.5 МГЦ в качестве такта CLK используется Ф2. Из-за этого, а также из-за неудачной схемы формирования ZSYNC, им и пришлось задерживать закрытие буферов (переделка N3) и делать защёлки, чтобы продлить читаемые данные. В моей схеме это не требуется, т.к задержка закрытия буферов происходит автоматически.

"Окно доступа" к ОЗУ при КР580 длится пока DSYNC=1, т.е ровно один маш.такт, т.к стробируется сигналом /CAS. По переднему фронту /CAS - исчезает DSYNC, убирается /WE, закрываются буфера (CPU и ОЗУ). По записи это работает прекрасно, т.к РУ5-тым до лампочки, что CPU держит /WR ещё хоть час после исчезновения импульса /CAS. А вот по чтению хреновее, т.к защелкивание данных с шины внутри CPU происходит по фронту /RD, который длится дольше, чем точно 1 маш.такт.

Но как доказал опыт сборки ~50.000 ОРИОНОВ, из-за задержек (сквозь буфера) и паразитных емкостей, сигналы на ШД исчезают не мгновенно, так что при КР580 никаких проблем не возникает. Для Z80 ситуация хреновее, т.к у него сигнал /RD более длинный. Но при CLK равном Ф1 в моей схеме тоже всё работает. А вот с Z80 от ОРИОН-СЕРВИСА при CLK=Ф2 даже на такте 2.5 МГЦ возникают проблемы. Оттого им и приходится делать доработку N3 (удлиняющую время открытия буферов), доработку N5 (запоминание данных с шины в регистре ИР82) и закорачивать вентиль D11.5.

А вот при такте 5 МГЦ, происходит наоборот. Процессор слишком рано кончает писать (убирает записываемые данные до фронта /CAS), и слишком рано защелкивает данные считываемые из ОЗУ, когда они ещё не готовы из-за низкого быстродействия ОЗУ.

Кстати, делюсь ценным секретом. При 5 МГЦ можно ввести регистр на вывод, который защелкивает и удерживает данные на шине после окончания /WR, что позволит отказаться от использования WAIT при записи (что даст ускорение до 1.75 при ОЗУ на том же медленном такте). Т.е это идея регистра, но по сравнению с идеей ОРИОН-СЕРВИС, это "регистр наоборот". Продлеваем в защёлке данные для ОЗУ, а не как в схеме ОРИОН-СЕРВИС, где продлеваем данные для процессора. Эту идею я уже использовал в своём несинхронном текстовом адаптере и она прекрасно будет работать и в ОРИОНЕ, дав выигрыш скорости на 30% без перегрева ОЗУ.

Чтобы обращение к ОЗУ от Z80 на такте 5 МГЦ продлилось на весь период "окна доступа" в 400 НСЕК и вводится ОДИН такт WAIT. Это в моей схеме. А сколько тактов вводится в схеме ОРИОН-СЕРВИС - одному Богу ведомо. Как я уже писал, это, как минимум 2 такта, а скорее всего (из-за D8.1 и D8.2) три такта.

Кстати, для схемы ОРИОН-СЕРВИС возможно иное решение, чтобы избежать напайки ИР82 на ВА86. В схеме ОРИОН-СЕРВИС удлинять данные приходится потому, что данные на выходах ОЗУ исчезают по концу /CAS. Решение проблемы ясно и обезьяне. Достаточно задержать /CAS на 50 НСЕК последовательными вентилями или емкостями.

Задержка закрытия буферов в моей схеме происходит автоматически. Буфера открываются сигналом /DSYNC (D13/8). При КР580 SYNC короткий, потому при очередной импульсе /CAS на входе D13/11 его уже нет, отчего SYNC длится чётко 1 маш.такт. А вот при Z80 используется имитация SYNC - сигнал ZSYNC, а он исчезает не по следующему фронту /CAS, а по концу /MREQ, отчего DSYNC удлинённый. Т.е буфера окрыты всё время пока идёт /MREQ. Отчего мой вариант формирования ZSYNC и DSYNC грамотнее.

[gdv2002]

память SIMM30 две по 256 кБт.

А схемку установки не подкинешь?

[barsik]

имею память на двух SIMM30 по 256 кБ

А схемку установки не подкинете ?

Схемка тут может быть только "лобовая", т.е /RAS к /RAS, /CAS к /CAS, данные к данным, и адреса к адресам. Интересно, используются ли у VladimirS, все 512К (как в схеме rev.512) или лишь те же базовые 256К. При 512К надо устанавливать ТМ7 вторым этажом над TM7 (D18) и КП12, напаянный вторым этажом над D23, а при 256К достаточно только одной КП12.

Интереснее, как конструктивно сделать эту замену, как закрепить и смонтировать SIMM чтобы выглядело не очень страшно. Я тоже имею ненужные SIMM-30 256 кб и есть надежда их применить на такте 8.25 МГЦ (Z80 на такте 8.25 МГЦ, а WAIT только для ПЗУ и ВВ55). А уж при /RAS /CAS в 5 или даже 7.5 МГЦ SIMM-30 смогут работать без проблем.