KAY - разводка печатной платы

[zx-kit]

Сделать можно, только где Вы видели ARM в DIPe?

Да, корпус у него LQFP100. Зато на нем можно без проблем NOWAIT на клавиатуру, мышку и джойстики делать - скорости внутри огромные.

Придется делать переходную плату, которую можно будет ставить например в панельку от DIP28 вместо ATMega48.

---------- Post added at 23:40 ---------- Previous post was at 23:36 ----------

У нас в Промэлектронике ATMEGA48V-10PU - 147 руб.
Проверено, на 5 Вольтах работает даже на 24 МГц.

В Элитане по 140 руб. Более-менее вариант.

[Alex_NEMO]

Скажи для чего эти микросхемы?

4-BIT BIDIRECTIONAL VOLTAGE-LEVEL TRANSLATOR
WITH AUTOMATIC DIRECTION SENSING AND ±15-kV ESD PROTECTION
Я его использую для согласования SD-карты(питание 3,3в) с контроллером (питание 5в).

[zx-kit]

4-BIT BIDIRECTIONAL VOLTAGE-LEVEL TRANSLATOR
WITH AUTOMATIC DIRECTION SENSING AND ±15-kV ESD PROTECTION
Я его использую для согласования SD-карты(питание 3,3в) с контроллером (питание 5в).

Интересная микросхема.

[Alex_NEMO]

Интересная микросхема.

Да. У неё и "разводка" очень удобная! Есть ещё 8-битная версия TXB0108.

[Black_Cat]

cчитаю, что лучше подавать на порт FF не номер строки, а код атрибутов. Ведь программа может закрасить часть экрана определенным атрибутом и ждать именно его появления, а не кода, отличного от FF

Нет, неправильно считаешь. Во-первых програмы юзающие #FF можно пересчитать на пальцах (поэтому в KAY'е его и небыло), так что доля прог юзающих цвет - никакая. Во-вторых стандартным применением #FF является определение начала экранной области, а юзать его для определения конкретного места на экране нецелесообразно из соображений затрат машинного времени, это проще сделать другими методами, хотя сдуру это возможно. Так что ориентироваться на плохих программистов нет смысла, проще раз и навсегда ввести табу на такое программирование.

зря он врезал дешифрацию порта FF до сигнала IORD1. При этом могут возникнуть конфликты, так как сигналы C1 и *DOS/ уже не будут блокировать чтение из порта FF

Да, по #xxFD в этой схеме будут проблемы. Насамделе в схеме изначально стояли ЛА4, и на дешифрацию заводился ещё A1, но за давностию лет забылось зачем это делалось, и возник соблазн упростить, но это была ошибка . Но такое упрощение можно сохранить если замес делать после сигнала IORD1, так что такой вариант будет самым оптимальным. Что же касательно *DOS/, то ты ошибаешься, т.к. BDI перехватит IORQGE/ раньше. Кстати, порт #FF скорее всего будет конфликтить с ZXM-SoundCard и не будет давать ей работать при обращении к SAA.

[zx-kit]

Нет, неправильно считаешь. Во-первых програмы юзающие #FF можно пересчитать на пальцах (поэтому в KAY'е его и небыло), так что доля прог юзающих цвет - никакая. Во-вторых стандартным применением #FF является определение начала экранной области, а юзать его для определения конкретного места на экране нецелесообразно из соображений затрат машинного времени, это проще сделать другими методами, хотя сдуру это возможно. Так что ориентироваться на плохих программистов нет смысла, проще раз и навсегда ввести табу на такое программирование.

Надо ценить то, что уже сделано. Можно конечно переделывать игры, чтобы добится работоспособности на существующем железе. А можно немного железо подогнать.

Кстати, для чего мог понадобиться порт FF. Например, изображение строится долго/сложно и от начала INT до начала отображения SCREEN, обновить изображение не хватало времени. Поэтому можно использовать порт FF для определения конца отображения экрана или конца отображения 2/3 экрана (например в нижней трети экрана статическая картинка). Другого разумного применения я не придумал.

Интересно, почему INT формируется не сразу после окончания отображения активной части экрана? Тогда запаса времени было бы больше.

Да, по #xxFD в этой схеме будут проблемы. Насамделе в схеме изначально стояли ЛА4, и на дешифрацию заводился ещё A1, но за давностию лет забылось зачем это делалось, и возник соблазн упростить, но это была ошибка . Но такое упрощение можно сохранить если замес делать после сигнала IORD1, так что такой вариант будет самым оптимальным.

Я тоже так считаю, что надо после IORD1. При этом для порта FF будет использована часть адресов, которые раньше использовали клавиатура и кемпстон. Самый бесконфликтный вариант.
Кстати, в КАЕ есть порт с адресом FF, но читается состояние кемпстон джойстика.

Что же касательно *DOS/, то ты ошибаешься, т.к. BDI перехватит IORQGE/ раньше. Кстати, порт #FF скорее всего будет конфликтить с ZXM-SoundCard и не будет давать ей работать при обращении к SAA.

Если идет обращение к ZXM-SoundCard, то она должна заблокировать другие контроллеры и порты на материнской плате. Как же возникнет конфликт. Только если на ней самой адрес FF используется. Но тогда она заблокирует порт FF на материнской плате. У портов на материнской плате приоритет ниже, чем у контроллеров в слотах и они работают только, если такой адрес не используется и не заблокирован контроллером. А те контроллеры, которые не делают блокировку опасно подключать к шине ZX-BUS.

[Black_Cat]

Если идет обращение к ZXM-SoundCard, то она должна заблокировать другие контроллеры и порты на материнской плате. Как же возникнет конфликт. Только если на ней самой адрес FF используется. Но тогда она заблокирует порт FF на материнской плате.

нет, не успеет т.к. у неё в дешифрацию замешан вопреки стандарту шины NemoBus сигнал IORQ/ , в результате чего порт #FF на мамке может включиться раньше и конфликт будет неизбежен.

[zx-kit]

нет, не успеет т.к. у неё в дешифрацию замешан вопреки стандарту IORQ/ , а он устанавливается позжее, в результате чего будут иголки и конфликт неизбежен.

В КАЕ при чтении из порта FF читается состояние кемпстно джойстика. То есть на шину выдаются данные. В Фениксе разве не так?

[Black_Cat]

В Фениксе разве не так?

я говорю о ZXM-SoundCard, а не об Фениксе, в Фениксе как раз всё нормально . В KAY и Фениксе дешифрация #1F разная, в Фениксе учитывается A7. Некорректность в ZXM-SoundCard

---------- Post added at 11:39 ---------- Previous post was at 11:16 ----------

Надо ценить то, что уже сделано.

кривое программирование необходимо изживать без всяких сожалений.

Можно конечно переделывать игры, чтобы добиться работоспособности на существующем железе. А можно немного железо подогнать.

В корне неправильно. Объясню почему: т.к. криворукие программисты ещё не успели накосячить таких "шедевров", то и поощрять их это делать - не стоит, нечего себе гемор создавать. Пусть все знают, что так программить нельзя - и точка!

[Alex_NEMO]

БК-0010, исли можно, подправь, пож. свою схему порта #FF и используй "логику" с учетом доп корпусов, т.к. так проще развести, чем тянупь МГТФ/резать/перепаивать.

Мужики, ещё такой вопрос: сейчас плата "отрисована" и "рихтуется" в SL5, ширина "сигнальных" дорожек и мин. зазоры между соседними дорожками/выводами/переходными ответстиями ~ 0,32 мм. Я слышал, что для плит "3-го класса" мин. параметр на ширину дорожек и мин. зазоры между соседними дорожками/выводами/переходными ответстиями 0,23(0,25) мм. Я пробовал "трассернуть" в SPECCTRE одну из промежуточных плат, подготовленных в DipTrace с частью доработок - все развелось, при уменьшении вышеозвученных параметров до 0,26 мм. Я так думаю, что есть шанс "нормально" развести всю плату со всеми нашими "хотелками", если общественность будет не против!
Так как, на счет такого варианта? На сколько "критично" такое "утоньшение" дорожек и уменьшение "зазоров"?

---------- Post added at 12:14 ---------- Previous post was at 12:10 ----------

кривое программирование необходимо изживать без всяких сожалений.

Дык, кто ж против, просто "наследие прошлого" заставляет!
Опять же, сейчас моло кто программит... К сожалению.