≡ Передовица » Hardware » ДЗУ » Исследование КНГМД 140 » Программы секвенсора
Программы секвенсораЯзык программирования секвенсораСинтаксис был предложен Jim Sather, я лишь слегка его дополнил. Всего имеется шесть команд:
Команды кодируются четырьмя битами, любая комбинация бит представляет собой некоторую команду, но часть комбинаций имеют идентичное действие, поэтому отдельных команд всего шесть. За мнемоникой команды следует знак "->" и шестнадцатеричная цифра - адрес следующей команды: указатель команд секвенсора не является счётчиком и очередное его значение берётся из кода текущей команды. Указатель команд имеет четыре бита, всего ПЗУ содержит 256 команд. Поэтому ещё четыре бита - это:
Таким образом, адрес очередной команды формируется как указатель команд (т.е. значение, считанное из текущей команды) и четыре бита данных - при их изменении меняется и поток исполнения: программа "прыгает" между своими ветками - нечто вроде условного перехода. Процедуры секвенсораК описанному выше добавим ещё один синтаксический элемент: "XX>XX". Здесь XX - шестнадцатеричные числа - это адрес и хранимое по нему значение в реальном ПЗУ Агата, соответствующее данной команде. Для Эпл-листингов не приводятся. В тексте рассматривается три версии контроллера, однако только процедуры чтения данных различаются. Остальные - идентичны. С них и начнём. Процедура чтения флажка защиты записиВсе ветки этой процедуры заполнены единственной командой "SR -> 0". Таким образом, она очень быстро заполняет все биты аккумулятора флажком защиты записи, причем первоначально он появляется именно в старшем разряде. Отсюда и рекомендации мануала - следить за D7, хотя, если дать секвенсору всего несколько тактов, он заполнит вполне корректным значением весь байт. Одновременно происходит сброс указателя команд на 0. Процедуры захвата байта с шины ЦПУ и сдвига байта в линию записиПроцедура состоит из двух половин, которые выбираются в зависимости от защелки "C/D", причем каждая из них разделена на две части старшим битом аккумулятора. Первая половина - CD = 0 - сдвиг аккумулятора на каждый 8-й такт. Её части отличаются только адресом перехода на шаге 7 и 15: в зависимости от D7 происходит или не происходит изменение старшего бита указателя адреса. Его значение, в итоге, и уходит на дисковод как данные записи. Вторая половина - CD = 1 - загрузка аккумулятора с шины ЦПУ. Её части имеют такое же отличие, но это не имеет особого значения, т.к. драйвер, сразу после записи данных в аккумулятор, переключает CD в состояние 0 - ещё до достижения адресов 7 или 15.
Обе процедуры не зависят от значения данных чтения. Логично, не правда ли? Процедура чтения данных (версия "Apple Disk 3.2")Эта процедура зависит от D7 и данных чтения. Она разделена на две большие части: D7 = 0 - этот блок исполняется по мере считывания бит с пятого по нулевой и D7 = 1 - старший бит дополз до своего места и секвенсор даёт паузу, чтобы ЦПУ успел прочитать аккумулятор. Состояние линии чтения при этом продолжает анализироваться, но пока оно влияет только на указатель команд. Секвенсор сбросит аккумулятор только после того, как обнаружит "1" на линии чтения (т.е. read = 0: не забываем об инверсии входных данных) и отсчитает время для ещё одного бита. Получив его (или недождавшись) секвенсор сбрасывает аккумулятор, что сразу приводит к переходу в первую часть кода (D7 = 0), где выполняется SL1 и затем SL0 или SL1, в зависимости от значения считанного во второй половине значения. После чего продолжает ожидание остальных шести бит.
Важная особенность версии 3.2 - ожидание нулевого бита продолжается 10 тактов секвенсора. Эта версия расчитана на то, что подряд может идти только один нулевой бит. Т.е. считывание комбинации 1 0 0 будет выполнятся 30 тактов, в то время как три бита должны занимать лишь 24 такта. Набегание столь серьёзной ошибки приводит к тому, что реально такая процедура успешно читает, в лучшем случае, один сектор из шестнадцати - если на диске есть комбинации из двух нулей подряд. Эта версия использовалась с DOS до 3.2 включительно и предполагала 13 секторов по 256 декодированных (т.е. после всех расшифровок контроллером и драйвером) байт на дорожке. Последовательность из двух нулей не допускалась. Процедура чтения данных (версия "Агат", оба варианта контроллера)
Вот тут-то самое интересное: Агат использовал 16 секторов по 256 байт на дорожке и ДОС3.3 (я уже по русски её называю, поскольку она была адаптирована для Агата). Но прошивка секвенсора - почти точь-в-точь - как 3.2 Эпла. Отличия: второй столбец, адрес 9 - здесь возврат после SL0 происходит на адрес 2, а не 0 - т.е. после очередного нуля секвенсор ждет следующий ноль только 8 тактов, что несколько уменьшает ошибку. Некоторые отличия видны также в колонках 3 и 4. Процедура чтения данных (версия "Apple Disk 3.3")А дальше мы видим оригинальную прошивку Эпла для версии DOS 3.3 и соответствующего ей контроллера. Есть что-то общее с Агатом ? :) Буквы, вроде, знакомые... Эта прошивка также ждёт повторный ноль только 8 тактов, но в ней есть много других отличий. Анализировать их лень, хотя и интересно: эта прошивка даёт более стабильное чтение, чем агатовская. Иногда разница весьма существенна. Чтобы хоть как-то объяснить сей феномен, я представил себе такую ситуацию: допустим, очередная единичка пришла не вблизи "своего" момента (тайм-слот - 8 тактов), а раньше - например, проскочила комбинация 1010 (это явная помеха, но что с ней делать?). Как поступят контроллеры (порядок колонок/адресов):
Возможно, это не самая важная причина, но, полагаю, направление поиска найдено верно.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |