PAF Commander, Version 2.00 Copyright (C) 1992, 93 by Petrosyan Alexander Файловый менеджер для УКНЦ со встроенным просмотрщиком. Клон Norton Commander. Сейчас 26 марта 2006 года, по просьбе 'архивариуса', Arseny Gordin , я Петросян Александр пишу, что запомнилось. 0. писал один, где-то 1 год. поначалу использовал только УКНЦ, потом появилась ДВК-3, пересел за неё. пользователь запускал программку 'pc'. моё огромное спасибо этим людям: * Леонид Евгеньевич Фрейдензон мой учитель информатики, и высшей математики (первая Зеленоградская физматшкола) дал мне возможность и даже что-то продал ;) * Дмитрий Климов автор DESS, программы, без которой было невозможно программирование и, главное, исследовательская деятельность. в частности, периферийный процессор УКНЦ, его ПЗУ и рабочие данные были исследованы в DESS, через драйвер PP: * Ростислав Полежко ценнейший носитель знаний про программироваю, что смог, я у него взял. автор драйвера PP:, без которого анализировать периферийник было бы очень неудобно и неудобно. * Константин Маланин ценнейший носитель знаний про программироваю, что смог, я у него взял. изготовитель кабелюки ДВК-УКНЦ, без которой разработка велась бы с черепашьей скоростью. * Игорь Зафиевский (Гоша) ценнейший носитель знаний про программироваю, что смог, я у него взял. не припомню, чтобы мы общались конкретно по этому проекту, но это не важно ;) 1. нужен был быстрый вывод на экран, а стандартные механизмы обеспечивали невыносимо медленный. в ходе экспериментов было выяснено, что если действовать самому, минуя стандартные механизмы, можно выводить текст раза в 2-3 быстрее, чем это делает код из ПЗУ. манипуляции были реализованы в виде большого куска кода, забрасываемого в PP (периферийный процессор) при старте. общение идёт в виде команд, номерочек команды и данные пересылается через дырочку между процессорами. 2. обязательно было сделать сохранение/восстановление экрана, а места в памяти супермало. сначала попробовал подход, который видел на БК: распознать текст, выведенный на экран. ведь, как и на БК, у УКНЦ видеопамять графическая. шрифты были быстро найдены в памяти PP, анализ показал, что для распознания вполне достаточно просмотреть лишь маленькую часть буквы. тесты были написаны, работало, но медленно. оставил бы и такой вариант, но придумался другой: * не требующий распознавания * не требующий дополнительной памяти * быстрый а именно: спрятать палитрой один лишний план [из трёх], картинку в нём оставить (её не видно, но она есть), а при Ctrl+O (Ctrl+F1/F2) раскопировать данные из этого плана в другие оставшиеся два (визуально восстанавливается панелька). при выходе палитру восстановить. 3. пользуясь тем, что в PP есть свой код, удалось сделать очень запоминающийся текстовый курсор: курсор плавно менял свой цвет от белого к чёрному и обратно. 4. из имевшейся куцей документации по PP вычиталось о номере регистра дисковода (без деталей). в ходе экспериментов были вычислены биты этого регистра, отвечающие за два светодиода внутри дисковода. один(A): защита от записи, второй(B): индексная дырочка. кто забыл: на 5-ти дюймовых дискатах была у внутреннего отверстия было отверстие в конверте диска, а в самом диске -- малопонятного предназначения (об этом позже) дырочка. эти знания так бы и остались бесполезными, но на ум пришла ассоциация с метро: помните, у турникета тоже есть два(больше) детектора(лампочка+фотодетектор), и когда проходишь, последовательно пересекаешь туловищем эти лучи. так вот конструктивно дырочка A находится чуть ближе к пользователю, чем B. придумалось, что совершенно запросто можно отличить ситуации * вставляют дискету * достают дискету * она спокойно стоит * она вертится просто внимательно глядя на состояния битов A и B. когда вставляют дискету, то сначала перекрывают краем дискеты бит A, затем B. эти эксперименты дали возможность автоматически перечитывать панельку, если дискету сменили. 5. нужно было как-то защищать, чтобы софтинка хоть сколько-то дохода успела принести, прежде чем её обязательно сломают. было понимание, что защитить что-то можно только на уровне некопирующейся дискеты, и сделать это можно только в PP. за неимением подробной документации по ПЗУ за 2 денели было проделано следующее: DESS'ом дизассемблирована _вся_ ПЗУ, получился огромный файлище. этот файл был на PC проанализирован, и найден кусок, занимающийся низкоуровневым форматированием дискеты. кусок был вычленен, и поправлен, чтобы он работал на произвольных адресах (стал позиционно независим). анализ кода показал, что дырочка в дискете используется для организации interleaving при форматировании дискеты: на первой дорожке первый сектор форматировался сразу после того, как будет замечен индекс (дискета повернётся этой самой дырочкой, светодиод просветит её насквозь, фотодетектор скажет 'ага'); уже не помню, чередовавали ли номера секторов как-то хитро (есть разные подходы), но помню твёрно, что на второй дорожке первый сектор форматировался с некоторым сдвигом, чтобы к концу передвигания шаговым двигателем головки на следующую дорожку, первый сектор подкрутился примерно под неё, и не пришлось долго его ждать. тестовое форматирование уже выделенным форматирующим кодом успешно удалось, дальше был план: как-нибудь изменить форматирование, чтобы стандартное чтение блока сорвалось, но моё собственное низкоуровневое чтение прошло успешно (кусок чтения пока не был проанализирован). что-нибудь простенькое, вроде неправильной на единичку контрольной суммы сектора. был начат анализ кода, обрабатывающего чтение. тут был приятный подарок: в коде ПЗУ периферийного процессора, обрабатывающем запрос центрального процессора на чтение блока данных, была _ошибка_: код проверял правильность запрашиваемого начального номера сектора, находится ли тот в правильном диапазоне 1..10, однако проверка проверяла так: 0..10, трактуя запрашиваемый 0 (нулевой) сектор, как правильный. с ходу было решено воспользоваться этой ошибкой, и не делать своего куска чтения, не тратить лишние усилия и память, а 'просто' форматировать на дискете один из секторов, указывая в его заголовке, что его номер 'нуль'. после чего считывать из этого сектора важный кусок программы. отдельного внимания тут заслуживало бы то, как было придумано спрятать считывающий это дело код от внимания хакера. если бы не было допущено (в версии 1.0) грустной ошибки: после всех ухищрений и умных трюков (вроде блокирования пультового режима до полного выхода), содержимое памяти было не стёрто, и сломавший меня хакер (мир тесен, мы с ним встретились и обсудили), просто сохранил содержимое оперативки после выхода, затем аккуратно подклеил на нужное место. 6. ясно, что из-под PC нужно было уметь запускать команды/программы и возвращаться обратно. как это организовать программно мне подсказали старшие товарищи и выдали ценнейшую оранжевую папку, где описывалось, как писать системные драйвера (.sys). 7. цикл компиляция-запуски-выписывание всех найденных ошибок-правка был очень медленным после появления ДВК-3 стало возможно компилировать всё куда быстрее, однако стало нужно манипулировать с дискетой, записывая на неё результат на ДВК, потом перетыкая её в УКНЦ для запуска. после тысячного тырка это надоело и возник вопрос к старшим товарищам: а нет ли какой-нибудь возможности это дело побороть? добрые люди сказали, что и в ДВК и в УКНЦ есть последовательный порт. дали номера регистров на ДВК, сказали, что на УК это называется порт C2, и спаяли нужную кабелюку. как известно, при включении УКНЦ можно выбирать, с какого устройства грузиться, и на выбор, кроме дискеты и локальной сети предлагался и порт C2. мной был написана софтинка для ДВК, которая представляла файл с образом УКНЦ-ношй системной дискеты (с точки зрения ДВК это была LD-шка) и загрузочный драйвер (.sys) для УКНЦ, который умел по этому самому C2 порту общаться с ДВК. после этого жизнь наладилась: один раз УКНЦ загружалась с C2, результат компоновки выкладывался сразу на LD-шку, после чего на УК оставалось перезапустить Commander. работала связь не супербыстро, чуть быстрее дискеты, но не нужно было записывать и не нужно было перетыкать. без этого PC никогда не было бы закончен.