1) Начнём с порта #FE на запись:
Дешифрация адреса порта сделана по единственному биту шины адреса - A0. В большинстве случаев ничего страшного. Но если, к примеру, запустить какую-нибудь программу, которая работает с контроллером NemoIDE или SMUC, то при его отсутствии получим цветной бордюр и щелчек в аудиоколонках, а это очень не красиво. Поэтому, даже если периферия подключается через ZX-Bus, где доступ к устройствам разделяется с помощью цепочки IORQG, всё-равно дешифрация порта #FE на запись должна обеспечить развязку конфликтов с этими устройствами. Как минимум, нужно ещё проверять биты A2 и A6 на уровень "1", чтобы при обращении к портам SMUC и NemoIDE байты не попадали в порт #FE.
Находим микросхему DD22.4 (ЛЛ1) и отрезаем сигнал "A0+" от выв.13. Допаиваем 2 новые микросхемы 1533ЛЛ1 и 1533ЛА3, или используем свободные элементы микросхем, допаянных в прошлых доработках, заводим на них A0+, A2 и A6 в соответствии с доработанной схемой.
2) Теперь порт клавиатуры #FE:
Что касается дешифрации, в принципе, к тому что проверяется один только бит A0, претензий нет. Но в схеме есть ошибка - не используемый бит D7 при чтении из этого порта читается как "0", а должна читаться "1", в результате многие тесты ругаются на некорректный порт клавиатуры.
Находим микросхему DD68 (КП11), отрезаем от 14-й ноги землю и подключаем к +5в.
3) И порт джойстика #1F:
Не понятно, зачем для его дешифрации проверяется бит A13 ??? Как я понимаю, это была неудачная попытка KOE развязать конфликт джойстика с мышкой. Порт #1F должен откликаться во всём диапазоне адресов от #001F до #FF1F, поэтому A13 там не нужен. А для того, чтобы полностью развязать конфликт со всеми возможными мышками - с Kempston и тем более с AMX, более жёстко дешифрировать надо только младший байт адреса. Для этого хорошо подходит бит шины адреса A7.
Находим микросхему DD23.2 (ЛЛ1), от выв.5 отрезаем сигнал "A13" и вместо него подключаем "A7".
Схемы для всех 3-х пунктов:
Оригинальная схема: | Доработанная схема: |
4) Кэмпстон мышь:
Во-первых, хочу настоять на том, чтобы отказаться от WAIT-овых мышек в принципе, ну а про использование COM-овских мышек даже не хочу разговаривать.
Расскажу только свои впечатления от попытки использования COM-овской мышкой в Pentagon-е 1024 SL1.4. Вначале я прошил PIC16C622 прошивкой Влада Сорокина, купил через Аукро 3 разные COM-овские мышки (продавались одним лотом), почистил их и проверил на ПЦ - две из них вполне нормально работали, одна Mitsumi, вторая A4Tech (вроде бы). Подключаю шлейф с COM-разъёмом к Спектруму, подключаю мышку Mitsumi, запускаю TEST 4.30 и проверяю. Это был страх и ужас - пытаюсь толкать курсор к нужной кнопке (именно что толкать, а не двигать), но он то дрыгается на месте, то пятится назад. Впечатления такое, как будто я в поте лица толкаю увязший в грязи автомобиль, а он не поддаётся.
Далее, включаю я турбо-режим 7 MHz, и как только дёргаю мышку, комп тут же зависает или сбрасывается. Стало понятно, что длительность сигнала WAIT, который генерирует контроллер на PIC-е, рассчитана только для частоты процессора 3.5 МГц. Для турбо 7 МГц длительность WAIT-а должна быть в 2 раза короче, иначе работа с ОЗУ нарушается.
Далее, подключаю я вторую мышку - A4Tech, а она на Спектруме вообще не заработала.
Короче, спрятал я подальше эти мышки и постарался забыть их как кошмарный сон. Начал искать варианты подключения мышек PS/2 на ATtyni2313, нашёл на форумах вариант, адаптированный под Pentagon-1024 SL1.4, где достаточно платку воткнуть в разъём вместо PIC-а, и типа всё должно заработать. Однако, я рассчитывал на без-WAIT-овый вариант, поэтому дорожку с WAIT-ом я от панельки давно отрезал. Прошил ATtyni2313, прошил Fuses в соответствии с описанием, и... ничего не заработало - как только я прикасался к мышке, комп моментально зависал или сбрасывался.
Начал рыть другие варианты, другие прошивки. В результате выяснил вот что: Тот вариант схемы и прошивки, который позиционировался как "Special for Pentagon-1024 SL1.4", как раз использует WAIT, поэтому пришлось его отбросить. Удалось найти прошивку, где самим автором прошивки было заявлено, что WAIT не используется. Прошил, включаю - комп не стартует вообще. Вытягиваю контроллер - комп работает, вставляю обратно - не стартует. Заглядываю в прилагающуюся схему, оказалось, что нужен буфер для коммутации доступа ATtyni2313 к шине данных.
Тогда я взял за исходный вариант самую первую схему, которая рассчитана для Пентагона-1024 1.4, только допаял туда буфер на 1533АП5. Но тут выяснилось, что в этом случае требуется доработка на самой плате Пентагона, т.к. в оригинальной схеме сигнал выборки контроллера мышки положительный, а на АП5 надо подавать инверсный, и, как оказалось, и на саму ATtyni2313 в этом варианте прошивки, так же нужен инверсный сигнал выборки. И тогда я подвёл инверсную выборку с выхода 1533ЛА2 на 2-ю ногу разъёма вместо WAIT-а, оставив на всякий случай на 3-й ноге положительный сигнал CS. Мышку купил Genius, самую дешёвую, с роликом прокрутки, попробовал в работе - просто сказка!
Однако, для полного счастья этого оказалось мало. Опять конфликт мышиного порта с джойстиком, только в этот раз уже гадит на шину данных при опросе джойстика, сама мышка. В оригинальной схеме для дешифрации мышиных портов используются следующие биты шины адреса: A0, A1, A2, A5, A12 и A15. Как оказалось, A1 здесь не особо и нужен, а вот для развязки конфликта с джойстиком, не хватает A6 или A7. Я решил выбрать A6, из известных мне периферийных устройств на Спектруме, конфликт только с ATM-овским IDE-контроллером, которого у меня никогда не будет. Однако, и в оригинальной схеме этот конфликт присутствует, так что отрезая сигнал A1, мы ничего не теряем. А заменив его на A6, мы полностью закрываем вопрос конфликта с джойстиком.
Что в конечном итоге получилось, смотрим на схемы:
Оригинальная схема: | Доработанная схема: |
И в таком случае, привожу схему контроллера мышки, который и работает у меня на Пентагоне-1024 1.4:
Прошивка с фьюзами под этот вариант схемы, проверенная и рабочая здесь:
http://www.letitbit.com.ua/wknw18v3jmdk.html
Теперь в моём BIOS-е Кэмпстон джойстик проходит тест.