Soviet Union ZX Spectrum CommunityЧетверг, 28.11.2024, 18:27
Вы вошли как Гость | Группа "Гости" | RSS
 [ · Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Pentagon by Northwood
Black_CatДата: Среда, 01.07.2020, 16:12 | Сообщение # 1
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
1. Сигналы DOS/, IODOS/ для NemoBus v.1.2



Цепи DOS/, DOS на выходе DD29 идущие на дешифрацию портов разорвать, и в разрыв врезать схему. Цепи, идущие на выборку ПЗУ оставить как есть.
Прикрепления: 8323490.png (30.3 Kb)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Вторник, 06.10.2020, 14:52 | Сообщение # 241
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Программный мультиколор, это тяжеловесная для процессора задача, т.к. требует постоянно в реальном времени обслуживать экран, даже если это статическая картинка, постоянно меняя атрибуты для каждой строки + выполнять основные задачи ПО, включая скроллинг фона, перерисовку спрайтов, общая логика ПО. В связи с этим быстродействия процессора обычно не хватает для того, чтобы обеспечить минимальный элемент цветного атрибута 8x1, часто делают 8х2, а так же ограничивают общий размер поля с мультиколорным изображением.

Аппаратный мультиколор освобождает процессор от необходимости обслуживать статическое изображение на экране, процессор занимается только насущными задачами, и у нас всегда гарантировано максимальное разрешение цвета с размером атрибута 8х1 и на весь экран. В сумме размер экрана больше почти в 2 раза (если быть точным, то на 77,78%, а не в 2 раза), так что аппаратный мультиколор нужен. Ещё у нас есть режим Турбо-7 МГц без WAIT, что обеспечивает необходимую производительность для работы с экраном размером 12 КБ.
 
Black_CatДата: Вторник, 06.10.2020, 15:02 | Сообщение # 242
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
:) Тем не менее, в реальности, игр с программным мультиколором - море, даж движок для их написания в AGD есть, а с аппаратным - две алонекодерские, да и в тех этот режим токо как вариант, т.к. они могут работать и без него - токо с программным :) . И дело здесь именно в перерисовке экрана, которая для аппаратного режима более медленная.

Добавлено (06.10.2020, 15:20)
---------------------------------------------
Цитата Northwood ()
Ещё у нас есть режим Турбо-7 МГц без WAIT, что обеспечивает необходимую производительность для работы с экраном размером 12 КБ.

А конкретно под турбо, игр вааще ноль! :) Есть конечно много игр, которые в турбо будут более играбельны, но нет ни одной под простой Спектрум, изначально заточенной под турбо! Использование турбо в TS-конфиге и АТМе я в расчёт не беру, ибо это не спектрумовские игры :)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Вторник, 06.10.2020, 15:22 | Сообщение # 243
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
В этой Алонекодеровской игре как раз минимальный размер атрибута 8х2. А если разрешение цвета сделать максимальное, т.е. 8х1, то для программного мультиколора нагрузка вырастет в 2 раза, когда для аппаратного на перерисовке экрана это не отразится. Игр под аппаратный мультиколор почти нет потому, что почти ни у кого нет этого видеорежима, его надо продвигать.
 
Black_CatДата: Вторник, 06.10.2020, 16:17 | Сообщение # 244
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Ну, на западе на перечисленных актуальных платформах есть, но до этого года таких клонов было меньшинство, а в этом году наконец сделали обещанные 3150 шт ZX Next, и баланс немного сместился. Но это токо в этом году, и пройдёт ещё не мало времени, пока начнут писать сугубо под аппаратный мультиколор :)

Добавлено (08.10.2020, 00:09)
---------------------------------------------
Такой нескромный вопрос, а почему у тебя на выходе АТмеги RES/ нету диода, забыл, или забил? :) Аналогично и на выходе MAGIK/, а на WAIT/  логично было бы перенести диод на верхнюю плату.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Суббота, 31.10.2020, 12:25 | Сообщение # 245
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
Такой нескромный вопрос, а почему у тебя на выходе АТмеги RES/ нету диода, забыл, или забил? :) Аналогично и на выходе MAGIK/, а на WAIT/  логично было бы перенести диод на верхнюю плату.


Да, забыл про них. Диод на WAIT лучше оставить на нижней плате, поскольку как показала практика, до диода длина цепи WAIT играет большее влияние, а после диода - нет.

Добавлено (13.11.2020, 12:26)
---------------------------------------------
И так, я освободился пока от срочных дел. Возвращаясь к предлагаемым тобой доработкам, думаю, что ты не обидишься, если я всё-равно сделаю по-своему ? Я внимательно изучаю твою схему, нахожу, чем она лучше или хуже моей, вношу изменения в свою схему, но делаю это с учётом более удобной разводки платы и пока вношу только критические доработки.

Из критического: 9, 10, 11) в списке твоих доработок присутствует фатальная ошибка - отсутствует ~IORQ при формировании сигнала AY_BC1, т.е. при установке музыкального сопроцессора, компьютер вообще не заработает. Поэтому не нужно было отрезать ~IORQG от ИД7. По задержкам сигналов: в сравнении с моей схемой, у тебя максимальное количество каскадов, через который проходят адресные разряды: для AY - не изменилось, но в режиме блокировки верхних адресов - увеличилось на 1 каскад (A15), для #DFFD - увеличилось на 2 каскада (A1, A14 и A15). Поэтому схема будет работать медленней, если не заменить ИД7 на серию 1531. Но без сомнения тот факт, что WAIT при обращении к порту #DFFD у тебя не формируется, в отличии от моей. Поэтому посмотрю, что из твоего предложения можно будет использовать у себя, как это сделать лучше.

1,2) Дублирование я убрал, там действительно можно было оптимизировать схему;
3) Пока оставил без изменений, т.к. эта доработка ничего не меняет, а призвана только изменить состав логических элементов, потом будет видно.
4) Пока оставил без изменений, потому что ближайший свободный элемент ЛН1 на плате располагается слишком далеко.
5) Исправил, ты прав, диоды там действительно ставить нельзя, но сделал по-своему.
6) В принципе, ты прав, там можно обойтись и без элемента ЛИ1, кроме того, в моей схеме присутствовал серьёзный недостаток, связанный с тем, что резистор R48 в цепи ~NMI вместе с резистором R80 в подтяжке ~NMI образовывали делитель напряжения, что не желательно. Поэтому с диодами будет работать лучше, сделал полностью твой вариант.
7) Пока что оставил практически без изменений, т.к. ближайший свободный элемент ЛЕ1 располагается слишком далеко, а доработка логически ничего не меняет, признана только изменить состав элементов, поэтому там я сделал иначе.
8) Было исправлено мной ещё в схеме версии 8.4, оставил мой исправленный вариант.
9,10,11) Написал выше, сейчас в процессе.

 
Black_CatДата: Пятница, 13.11.2020, 18:20 | Сообщение # 246
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Из критического: 9, 10, 11) в списке твоих доработок присутствует фатальная ошибка - отсутствует ~IORQ при формировании сигнала AY_BC1

Я же это исправил https://zx.clan.su/forum/8-166-1368-16-1601194780

Добавлено (13.11.2020, 18:31)
---------------------------------------------
Цитата Northwood ()
По задержкам сигналов: в сравнении с моей схемой

Ты неправильно считаешь задержки, считать их надо после IORQG/, RD/, WR/. Все задержки до начала этих сигналов нивелируются более ранней установкой адреса. При чём на частотах до 14МГц нивелируются без укорачивания сигнала, а на 14МГц укорачиваются токо некоторые сигналы, но не критически, и полюбому, если правильно считать, у меня задержки получаются меньше твоих В НЕСКОЛЬКО!! раз! А ты считаешь неправильно, поэтому и схемотехника неправильная :) . Более раннее выставление адреса у Z80 по сравнению с IORQG/ - это фундаментальная фича, на которой построена вся NemoBus, и без которой эта шина просто не сможет работать!

Добавлено (13.11.2020, 20:45)
---------------------------------------------
Вааще, непонимание фундаментального базового принципа, на котором построена  NemoBus - это болезнь всех размороженных, кто вернулся на Спектрум после четверть вековой заморозки :) . И состоит она как раз в непонимании, что адрес процессором выставляется раньше IORQ/. Именно поэтому в правильно спроектированных устройствах NemoBus не происходит укорачивание сигнала IORQ/ за счёт задержек дешифрации, т.к. эти задержки меньше чем интервал от выставления адреса до IORQ/. Я уже устал бороться с этим фундаментальным непониманием каждого нового пришедшего размороженного, я даж специально статью в За рулём №22 написал, но ты её как видно не читал :) . Каждый размороженный, приходя на спектрум после 25-летней заморозки наступает на эти грабли. И к сожалению большая часть их вместо того, что бы исправить свои ошибки, предпочитают просто избавиться от того, кто им на них указывает :) . Например при проектировании конфига PentEvo для девборды ZXEvo, LVD не понимал как работает NemoBus, и в итоге в этом конфиге до сих пор шина работает неправильно, аналогично и TSL в своём TS-конфиге, в котором скопировал неправильное решение LVD :) . В результате, вместо того, чтоб исправить свои ошибки они просто решили зобанить меня везде где токо можно на их ресурсах, а их конфиги как работали изначально неправильно, так до сих пор и неправильно работают, из-а чего приходится на устройствах NemoBus ставить костыли для генерации суррогатного IORQ/ из сигналов MREQ/, RD/, WR/ :) . Ессно, при этом происходит дикое укорачивание сигнала IORQ/, но на 3,5МГц это ещё прокатывает, поэтому всем пофиг :) . И это сплошь и рядом :) . Размороженный JV-Soft, когда я ему сказал, что он не понимает принципа работы NemoBus, вааще как токо меня не проклинал на ZX.PK :) - он же, типа бессеребряник, который всем помогает, а я, враг народа, его такого хорошего шельмую, указывая, что он не понимает базовых принципов, и делает неправильно :) .  Кароче, читай статью про NemoBus в За рулём 22, http://notsoft.ru/zr/3aRulem_22.zip :)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Суббота, 14.11.2020, 11:22 | Сообщение # 247
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Наверно потому, что даташит на Z80, в котором можно посмотреть времянки, не лежит в инете на самом видном месте. А если когда-то и скачал его, забывается, что он уже есть на своём ПК и в какой папке лежит, и на такие детали, как приход адреса раньше чем IORQ, как правило, редко обращают внимание.
Впрочем, я точно помнил, что уже скачивал даташит на Z80 и знал, где искать его у себя. Сделал вырезку из этого PDF документа:


Добавлено (14.11.2020, 11:29)
---------------------------------------------
Но только точка времени, когда адрес порта считается валидным, наступает раньше сигнала IORQ менее, чем на пол-такта, т.е. при тактовой частоте 14 МГц у нас не более 30 нс.
P.s. не смотря на всё это, такое категоричное заявление про "быстрее в несколько раз", улыбнуло.
Прикрепления: 2649497.png (27.9 Kb)


Сообщение отредактировал Northwood - Суббота, 14.11.2020, 11:30
 
Black_CatДата: Суббота, 14.11.2020, 22:11 | Сообщение # 248
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Но только точка времени, когда адрес порта считается валидным, наступает раньше сигнала IORQ менее, чем на пол-такта, т.е. при тактовой частоте 14 МГц у нас не более 30 нс.

Скорее даже меньше, вот аппроксимация:



Из этой аппроксимации можно сделать вывод, что на 14МГц схемотехника периферии на дискретной логике без вейтов может и не работать вааще, и для такой частоты лучче периферию делать токо на CPLD. На 7МГц, тиаретически, при грамотном проектировании может работать периферия без вейтов и на дискретной логике, но всёж лучче на CPLD.

Цитата Northwood ()
P.s. не смотря на всё это, такое категоричное заявление про "быстрее в несколько раз", улыбнуло.

:) Где-то в несколько раз, где-то немного, НО! везде быстрее! :)
Прикрепления: 7448194.png (19.8 Kb)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Воскресенье, 15.11.2020, 01:55 | Сообщение # 249
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Из всего семейства процессоров Z80, в этом Пентагоне работать будет только Z84C0020PEC (в обоих Турбо-режимах) и Z84C0010PEC (Турбо-7 МГц). Поэтому можно считать, что никакого опережения IORQ в реальности не будет.

Добавлено (15.11.2020, 02:07)
---------------------------------------------
Цитата Black_Cat ()
Из этой аппроксимации можно сделать вывод, что на 14МГц схемотехника периферии на дискретной логике без вейтов может и не работать вааще, и для такой частоты лучче периферию делать токо на CPLD. На 7МГц, тиаретически, при грамотном проектировании может работать периферия без вейтов и на дискретной логике, но всёж лучче на CPLD.


В моей практике в Турбо-14 МГц:
1) Внутренняя периферия (порты памяти, биппер, бордюр) прекрасно работают без никакого WAIT-а.
2) Музыкальный сопроцессор, если поставить YM-2149F, прекрасно работает без никакого WAIT-а. Все остальные требуют WAIT.
3) NemoIDE прекрасно работает без никакого WAIT-а, обеспечивая более чем 3-кратную скорость загрузки данных с HDD. Но правда, на плате NemoIDE я заменил микросхемы ИР23, АП5 и АП6 на импортную серию 74Fxxx.

4) Клавиатура механическая 40-клавишная отлично работает в Турбо-7 МГц, что касается Турбо-14 МГц, не помню и проверить для меня затруднительно, хотя возможно, но смысла нет. Плёночная клавиатура, воткнутая в этот же комп, уже в Турбо-7 МГц глючит (основные клавиши работают, а расширенные клавиши нет), а в Турбо-14 МГц не работает вообще. PS/2 контроллер, естественно, никакое Турбо не переносит. Поэтому чтобы обеспечить нормальную работу любой клавиатуры, в обоих Турбо-режимах я завёл WAIT.
5) Мышка PS/2 тоже никакое Турбо не переносит, соответственно, завёл WAIT для Турбо.
6) CMOS часы никакое Турбо не переносит, тоже завёл WAIT.
7) Контроллер FDC никакое Турбо не переносит. Для Турбо-7 МГц завёл WAIT - работает великолепно. В Турбо-14 МГц никакой WAIT не помогает, поэтому при активном сигнале "VG93_RDY" Турбо-14 МГц снижается до Турбо-7 МГц (если включить оба Турбо режима одновременно) либо снижается до 3.5 МГц (если включить только Турбо-14 МГц).


Сообщение отредактировал Northwood - Воскресенье, 15.11.2020, 02:07
 
Black_CatДата: Воскресенье, 15.11.2020, 09:11 | Сообщение # 250
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
(если включить оба Турбо режима одновременно)

А зачем включать оба, и кстати, почему у тебя такое возможно?

Цитата Northwood ()
Поэтому можно считать, что никакого опережения IORQ в реальности не будет.

Будет, на 14МГц небольшое, порядка 22нс, но этого вполне достаточно для формирования IORQGE с помощью CPLD, на 7МГц 89нс вполне достаточно даже для формирователя IORQGE на рассыпухе, не говоря уже про CPLD. Нам нужно чтоб все периферийные устройства на шине NemoBus сформировали свои IORQGE до прихода IORQ/, тогда во-первых, сам арбитр не будет его укорачивать, и во-вторых, не будет на выходе арбитра иголок по IORQ/, т.к. все переходные процессы закончатся ещё до прихода IORQ/. Конечно, для этого формирователь IORQGE должен быть сделан правильно, т.е. должны юзаться только сигналы адреса и M1/, и ни в коем случае IORQ/. Например, в оригинальном GS формирователь IORQGE сделан неправильно, в результате все устройства после GS мало того, что вынуждены юзать укороченный IORQ/, дык ещё с иголками, что может привести к конфликтам с быстродействующей логикой.
И ты неправильно понимаешь цель ускорения дешифрации. Задержки в дешифрации конечных устройств, о которых ты говоришь, нам как раз не критичны, достаточно чтоб конечное устройство надёжно срабатывало при стандартной для этой частоты длительности IORQ/, а борьба за ускорение дешифрации нужна токо чтоб иметь запас на случай, если внешняя периферия будет укорачивать IORQ/ своим медленным IORQGE без выставления вейта.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Воскресенье, 15.11.2020, 16:01 | Сообщение # 251
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
А зачем включать оба, и кстати, почему у тебя такое возможно?
Просто упрощение схемы, в усложнении здесь нет никакого смысла. По одной линии включается Турбо-7 МГц, по второй - Турбо-14 МГц. Если включить одновременно, то будет работать Турбо-14 МГц.
Сигнал активности дисковода блокирует линию Турбо-14 МГц, не влияя на Турбо-7 МГц. Поэтому если их включить одновременно, то контроллер дисковода снизит Турбо до 7 МГц. А если включить только одну линию Турбо-14 МГц, то контроллер дисковода снизит частоту процессора до 3.5 МГц.


Сообщение отредактировал Northwood - Воскресенье, 15.11.2020, 16:01
 
Black_CatДата: Понедельник, 16.11.2020, 01:10 | Сообщение # 252
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Просто упрощение схемы, в усложнении здесь нет никакого смысла.

Я спрашивал почему в контроллере клавиатуры возможно включение одновременно двух частот. Кто прошивку в контроллере делал? Что надо нажать чтоб включить частоту?


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Понедельник, 16.11.2020, 02:46 | Сообщение # 253
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
Я спрашивал почему в контроллере клавиатуры возможно включение одновременно двух частот. Кто прошивку в контроллере делал? Что надо нажать чтоб включить частоту?


Прошивку под управление турбо-режимами модернизировал я. Турбо-7 МГц включается и выключается клавишей Scroll Lock. Турбо-14 МГц включается и выключается комбиницией клавиш Shift + Scroll Lock, при этом контроллер включает сразу обе линии Турбо, чтобы при работе контроллера дисковода Турбо не выключалось полностью, а снижалось до 7 МГц. Использовать клавишу Shift в комбинации со Scroll Lock было не очень удачным решением, но мне нужно было быстро сделать прошивку, чтобы проверить возможность задействования линии PB7/XTAL2 в АТМеге для управления линией Турбо-14 МГц, переведя АТМегу в режим тактирования от внешнего генератора, чтобы либо принять этот вариант или искать другие пути управления Турбо-14 МГц, и можно было бы продолжить разработку схемы. От идеи циклического переключения между 3-мя режимами одной клавишей я отказался сразу.


Сообщение отредактировал Northwood - Понедельник, 16.11.2020, 02:48
 
Black_CatДата: Понедельник, 16.11.2020, 10:19 | Сообщение # 254
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
От идеи циклического переключения между 3-мя режимами одной клавишей я отказался сразу.

А почему отказался, чем плохо? Ведь это ручное включение, ему пофиг сколько раз кнопку тиснули.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Понедельник, 16.11.2020, 10:41 | Сообщение # 255
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
А почему отказался, чем плохо? Ведь это ручное включение, ему пофиг сколько раз кнопку тиснули.

В реальности это неудобно, по крайней мере для меня. Если я хочу выключить Турбо-7 МГц, то я не хочу сначала включать Турбо-14 МГц, чтобы потом его выключить полностью. Из опыта юзания на ПК комбинации клавиш Ctrl + Shift для переключения языка, когда их установлено 3 - английский, русский и украинский, и когда мне нужно с русского переключить на английский, я иногда промахиваясь количеством нажатий и вместо английского попадаю на украинский. Сама идея циклического переключения нескольких режимов, плоха. Лучше позже придумать для Турбо-14 МГц другую более удобную клавишу, которая не была бы задействована в качестве спектрумовской клавиши.
 
Black_CatДата: Вторник, 17.11.2020, 21:52 | Сообщение # 256
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
Если я хочу выключить Турбо-7 МГц, то я не хочу сначала включать Турбо-14 МГц, чтобы потом его выключить полностью.

Логичней циклическое переключение одной комбинацией 3,5 - 7 - 14. И для системных нужд лучче юзать Win + key.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
Black_CatДата: Четверг, 19.11.2020, 20:39 | Сообщение # 257
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
4) Пока оставил без изменений, потому что ближайший свободный элемент ЛН1 на плате располагается слишком далеко.
Ну дык сделай так:



У тя для генерации сраного ресета с одной стороны целый контроллер на Аттини стоит, а с другой на Атмеге, а ты зачем-то ещё десять раз буферируешь это, в то время как в древних PC XT сброс вааще шёл с БП, как POWERGOOD и параллельно ему кнопка на морде, и всё чудесно работало.
Прикрепления: 1604226.png (8.5 Kb)


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Пятница, 20.11.2020, 15:14 | Сообщение # 258
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
На ATTiny13 сделан сброс кнопкой включения питания, для корпусов с одной кнопкой. Короткое нажатие питания формирует сброс, длительное нажатие выключает компьютер. Для корпусов с двумя кнопками, отдельно сброс и отдельно вкл/выкл, я сделал отдельный вход для кнопки сброс XS9.

Сброс с ATMega-48 работает с PS/2 клавиатуры, это дополнительная плюшка, которая будет работать только если использовать клавиатуру PS/2. Те пользователи, которые будут использовать механическую клавиатуру, не смогут этой плюшкой воспользоваться, но и выпиливать её из ATMega-48 не нужно.
Сброс на ATTiny-13 решает проблему для тех, кто запихнёт плату в корпус с одной единственной кнопкой Power.
Выпиливать разъём XS9 не стоит, потому что если на корпусе есть две кнопки, то это намного удобней, чем клацать кнопку Power при неиспользуемой кнопке Reset.

P.s. прошивку для ATTiny13 писал не я, а воспользовался решением Mick-а, он дал на это добро.

Добавлено (20.11.2020, 15:32)
---------------------------------------------

Цитата Black_Cat ()
в то время как в древних PC XT сброс вааще шёл с БП, как POWERGOOD и параллельно ему кнопка на морде, и всё чудесно работало.

К цепи ~RES подключены 19 микросхем - потребителей сигнала и 4 слота NemoBus, поэтому один электролит на 10 мкф здесь не справится, поэтому я и буферизировал эту цепь. МК Attiny13 в этой схеме со своим сбросом появился гораздо позже, изначальная схема сброса осталась. Если ATTiny13 формирует сброс необходимой длительности, тогда согласен, что электролит можно убрать вместе с буфером. На момент добавления в схему ATTiny-13 я не умел программировать эти МК, ассемблер и сами МК я изучил позже, поэтому теперь в случае необходимости, смогу подкорректировать прошивку для обеспечения стабильного сброса при включении питания.


Сообщение отредактировал Northwood - Пятница, 20.11.2020, 15:17
 
Black_CatДата: Пятница, 20.11.2020, 20:12 | Сообщение # 259
Координатор
Группа: Координаторы
Сообщений: 731
Статус: Offline
Цитата Northwood ()
К цепи ~RES подключены 19 микросхем - потребителей сигнала и 4 слота NemoBus, поэтому один электролит на 10 мкф здесь не справится

:) Прекрасно справится. Конденсатор выполняет роль задержки и антидребезга, и ни Аттини, ни Атмеге, ни механической кнопке не мешает, просто фронты становятся более пологими, что для ресета пофиг. Я бы и на инверсный сброс на ISA поставил КТ315 вместо инвертора, транзистор можно куда угодно всунуть возле самой ISA - он маленький, и не надо тянуть дорожку к микросхеме через всю плату, а потом обратно. И кстати, на верхней плате сброс на AY можешь подавать HRES/ раз уж есть буферизация, до перемычки.


"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
 
NorthwoodДата: Среда, 25.11.2020, 12:42 | Сообщение # 260
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
Цитата Black_Cat ()
25) Т.к. мы для убыстрения дешифрации повыкидывали IORQG/, то этот сигнал надо добавить в формирователь вейта, что и делаем с помощью пары диодов и инвертора.

Бррр, этого в моём Спектруме не будет категорически, я уже объяснял, почему. Зачем тормозить абсолютно все порты, когда можно не тормозить, к примеру, жёсткий диск и получить максимум скорости чтения и записи ? Зачем тормозить порты переключения памяти ? Даже вейт для AY в Турбо-режимах я сделал опционально, потому что одни модели AY прекрасно работают в Турбо-режимах без вейта, другие нет. И поэтому я ввёл элементы DD107 (ЛА2) и DD108.2 (ЛН1), чтобы вейтить только выбранные порты, которые действительно в этом нуждаются.

Цитата Black_Cat ()
33) На верхней плате выкидываем корпус ИД7 и изменяем дешифратор.

В том дешифраторе был заведён сигнал ~M1, по которому в случае подтверждения прерываний, блокировались буферы АП6 и вторая половинка АП5. Сама схема дешифратора была использована мной НедоПЦ-шная без изменений. Но судя по всему, это не принципиально и от сигнала ~M1 в этой части дешифратора можно отказаться, потому что:

1) Сигнал ~M1 повторно заводится на вторую часть дешифратора - на DD5, поэтому сигналы ~IOW и ~IOR не формируются в цикле подтверждения прерывания, а значит сигналы ~HIOR и ~HIOW, проходящие через АП5, тоже будут отсутствовать. В таком случае наличие случайных сигналов ~HCS0 и ~HCS1 будет до фени.
2) Возможные сигналы данных HD0-HD7, которые пройдут через АП6 на IDE в цикле подтверждения прерываний, тоже будут до фени, потому что не будет сигналов ~HIOR и ~HIOW.

Но лучше всего, перед тем как делать это упрощение, проверить это на практике, не будут ли портиться данные на HDD, особенно в случае нестабильной ШД.

Добавлено (25.11.2020, 12:54)
---------------------------------------------
Цитата Black_Cat ()
32) Ну и наконец, заменив сэкономленные корпуса, и добавив корпус ЛП8, собираем такой менеджер АВМ, позволяющий устанавливать следующие ограничения адресного пространства АВМ: 16k(16k ПЗУ или 16k ОЗУ или их комбинации), 32k, 64k, 128k, 256k, 512k, 1Mb, 2Mb, 4Mb.

Этого не будет. Я не хочу разбивать память менее чем по 128 КБ. Здесь будет по-моему. И в твоей схеме ошибка. Твоя АВМ допускает короткое замыкание выходов ЛП8 в момент захвата шины картой расширения. У тебя при выставлении активного бита маски АВМ, соответствующий выход ЛП8 подключается к линии MEM_xx, которая идёт на слот NemoBUS, причём, выдать ЛП8 может как 0, так и 1 (определяется соответствующим битом порта на DD12). И если на выходе ЛП8 будет 1, а карта расширения там же попытается выставить уровень 0, то будет КЗ выхода ЛП8. И причём, это будет не гипотетическое КЗ, как в случае с дешифратором клавиатуры, где такое возможно только в случае случайного сбоя, и то вероятность такого КЗ ничтожна мала, а будет реальная угроза КЗ, которое будет регулярно происходить во время нормального выполнения ПО.

Добавлено (25.11.2020, 13:01)
---------------------------------------------
И ты неверно используешь сигнал ~BUSAK. Это сигнал от процессора, который является подтверждением захвата шины в ответ за запрос по линии ~BUSRQ. Мы можем использовать сигнал ~BUSAK, формируемый процессором, но никто, кроме процессора, не имеет права выставлять туда свой сигнал, в том числе карта расширения. Поэтому назначение диода VD18 и резистора R9 остаётся загадкой.


Сообщение отредактировал Northwood - Среда, 25.11.2020, 13:12
 
Поиск:

Copyright MyCorp © 2006Сайт управляется системой uCoz