Depth
#01
14 октября 1997 |
|
Программистам - 14 советов пишещему boot, советы пищущему Компрессор, несколько советов пищущемо Музыкальный редактор. Рекомендации автору Alasm и STS.
________________________________________ Текст : VIATOR Музыка : COOPER ________________________________________ HELLO SOI AND ALL CRYSTAL DREAM !!!!!!! Я сел писать этот текст ночью, сразу после нашего телефонного разговора. Я уже давно собирался написать подобную статью, но никак не доходили руки. Наконец меня окончательно достали ламеры с их левым софтом, и я решил, что такая статья крайне необходима. КРАТКОЕ ПОСОБИЕ ДЛЯ СИСТЕМНОГО КОДЕРА. Человек, решивший написать системную программу, сталкивается со многими тудностями. Этот текст призван хотя бы частично помочь Вам сделать свою программу качественной и удобной. Естественно, я не мог учесть все нюансы, но все же, если Вы воспользуетесь советами изложеннми ниже, будет легче и Вам самим, и пользователям Ваших программ. ЧТО СЛЕДУЕТ УЧИТЫВАТЬ В ПЕРВУЮ ОЧЕРЕДЬ ПРИ СОЗДАНИИ СИСТЕМНОЙ ПРОГРАММЫ. 1. В Вашем произведении должны быть учтены все недостатки и достоинства предыдущих программ такого типа. Учитесь на чужих ошибках, и используйте все достижения своих предшественников. 2. Управление в программе должно быть гибким и разнообразным. Стандартным на- бором является: SINCLAIR (правый), KURSOR, KEMPSTON (с проверкой) КЛАВИАТУРА (O,P,Q,A, SPACE и M ). А также KEMPSTON и АУ мыши. Если у вас нет мыши, но вы хотите реализовать ее поддержку, можно прочитать о том, как это сделать в следующих изданиях: о KEMPSTON mouse - "SPECTROFON 2O" в разделе "Конструктор" о АУ mouse - "ZX-POWER 1" в разделе "Железо". 3. Необходимо всегда проверять наличие KEMPSTON джойстика и не опрашивать его, если он отсутствует. Иначе, на всех машинах без этого порта Ваше произведение работать не будет. Напомню, что если KEMPSTON'а нет - биты 5-7 установлены. 4. Ваша программа должна максимально использовать все ресурсы машины, на которой она работает. Нужно протестировать доступный объем памяти и работать именно с ним. Могу посоветовать воспользоваться автоконфигуратором памяти из "ZX-FORMATS", написаным CREATOR'ом. Он позволит Вашей программе работать с памятью от 48к до мегабайта. 5. Копировщики и другие дисковые утилиты должны работать как с одним дисководом, так и с двумя. 6. Если в программе много изменяемых параметров (больше трех), просто необходимо сделать их запись на диск (SAVE SETUP). При этом запись нужно производить внутрь самой программы, предварительно проверив ее наличие и местоположение на диске. 7. Если ваша программа работает со вторым режимом прерываний, подключать их необходимо создав 257 байтную таблицу, забитую одним числом, т.к. во многих машинах с шины считывается не #FF, а любое число. Об этом уже много говорилось, но все равно иногда появляются программы, не учитывающие этого. 8. Естественно, сегменты (страницы) переключать нужно не через порт #FD, а через полный порт #7FFD (dec: 32765). 9. При обращении к диску должен быть подключен первый режим прерываний (IM 1). Если же Вам по какой-то причине требуется IM 2, можно использовать вектор прерывания только в пределах быстрых областей памяти (#8OOO-#BFOO (32768-49151) или в страницах O,1,2,3 ), при расположении вектора прерываний в медленной области памяти, весь компьютер, а с ним и TR-DOS, станут работать на 25 процентов медленнее, и дисковые операции будут нарушены. Это свойственно только для машин с раздельным полем памяти, для остальных, например Pentagon, это не имеет значения, но все равно это нужно учитывать. O раздельных полях памяти подробно написано в белорусской газете "ECHO 2", советую Вам его почитать. НЕСКОЛЬКО БОЛЕЕ ПОДРОБНЫХ СОВЕТОВ ПО ОПРЕДЕЛЕННЫМ ТИПАМ ПРОГРАММ. 14 СОВЕТОВ ЧЕЛОВЕКУ ПИШУЩЕМУ "воот". 1. Сразу нужно решить для каких дисков этот "воот" будет использоваться. Для системных предпочтительнее простые, но удобные оболочки, без различных эффектов и ненужных наворотов. Если же "воот" предполагается использовать для игр и демок, тогда другое дело, эффекты, графика и музыка только приветствуются. 2. Естественно он должен занимать как можно меньше места на диске. 3. Чем быстрее Ваш "воот" будет загружаться и запускаться, тем лучше. Во всяком случае не стоит подвешивать к нему эффектов с долгими DECRUNCHER'ами. 4. Старайтесь, чтоб одновременно на экран было выведено наибольшее количество файлов. 5. Имена программ должны быть хорошо читаемыми. Подберите подходящий шрифт и цвет окна. Желательно, чтоб окно с файлами не двигалось. 3а пределами же окна делайте что угодно. 6. Управление должно быть разнообразным и гибким. Одновременно от наибольшего количества устройств. Если выбор файлов происходит при помощи стрелки, сделайте поддержку KEMPSTON и АУ мышей. Лично я в подавляющем большинстве случаев для выбора файлов пользуюсь курсорными клавишами (расширеная клавиатура). При опросе клавиатуры, сначала проверяется нажатие CAPS SHIFT, если она нажата, то клавиши 5,6,7,8 опрашиваются как КУРСОР джойстик, иначе как SINCLAIR. Смену диска обычно производят по клавише SPACE, это уже стало стандартом. Также удобно использовать клавишу "ENTER" как FIRE. 7. Если в вашем воот'е не реализована автоматическая проверка смены диска, перед запуском программы необходимо перечитать каталог и в случае, если нужного файла там не окажется, вывести каталог уже нового диска и, естественно, ничего не запускать. 8. Перед запуском программы необходимо восстановить все системные переменные и все, что требуется для нормальной работы Basic'а. Экран можно оставить черным (область атрибутов заполнена кодом O), а вот в системные переменные необходимо записать стандартные атрибуты. Также, желательно очистить всю память, которую занимал "воот". 9. Программ, использующих 128к ПЗУ или 128к Basic, очень мало (если честно, то я так и не вспомнил ни одной), зато программ, которые не работают с подключеным 128к ПЗУ - множество. Поэтому, желательно, чтобы "воот" сразу же подключал 48к ПЗУ, но с активными страницами. Если не знаете как это сделать, возьмите строки из загрузчиков ассемблеров "TASM", "ALASM" или из какого нибудь другого. На 48к компьютере все также будет работать нормально. 1O. В большинстве бутов файлы с именем "воот" не выводятся, но иногда это неудобно, поэтому советую этот файл выводить, но, если он записан первым на диске, то указатель сразу же переместить на следующий файл. Также, при поиске имени "воот", необходимо проверять все восемь букв, а не только первые четыре. 11. Иногда в одной и той же программе бывает несколько Basic блоков, запускается из которых только один. Этот случай можно предусмотреть, и не выводить определенные Basic файлы. Единого стандарта в данном случае не существует. Иногда не выводят все файлы, начинающиеся с маленькой буквы, но данный способ не всегда удобен. На мой взгляд, удобнее отсеивать все файлы, начинающиеся с точки. 12. В некоторых "воот'ах" реализивана сортировка файлов по алфавиту, но обычно это только затрудняет работу. Поэтому сортировку лучше сделать отключаемой. 13. Полезно, когда кроме списка файлов на экран выдается краткая информация о диске. Например, его имя, количество свободных секторов и количество файлов. 14. Желательно не привешивать жестко определенную музыку, а сделать ее легко меняемой. В этом случае есть два способа: можно хранить в памяти player от какого-либо музыкального редактора и подгружать файл с музыкой без player'а. Или же загружать компилированный блок с player'ом из любого редактора, но при этом он должен быть откомпилирован под определенный адрес. В любом случае нужно подробно описать процесс подвешивания музыки. ЕСЛИ ВЫ РЕШИЛИ НАПИСАТЬ КОМПРЕССОР... Во-первых, он должен позволять, записывать компрессированные блоки без декомпрессора, чтоб можно было раскомпрессировать одним depacKer'ом много файлов. Во-вторых, вы должны прилагать к компрессору текстовый вариант декомпрессора, чтоб любой смог его изменить на свой вкус или попытаться ускорить. Время компрессии не особенно важно, а вот скорость декомпрессии должна быть максимально быстрой. DepacKer должен нормально работать при разрешенных прерываниях. При работе с различными компрессорами оказалось, что практически все существующие "кранчеры" (DSQЧ,MS_РАСК,LPC и др.) работают не всегада корректно. Однажды, пытаясь скомпрессировать файл, я перепробовал 6 или 7 компрессоров, и ни один из них не распаковал его правильно ! Обычно ошибки проявляются в том случае, когда в компрессируемый файл входит уже сжатый блок или экран. Я не являюсь экспертом в данной области, но осмелюсь высказать свое мнение, слегка попахивающее ламерством :-) ... Повидимому, пакеры расставляют свои контрольные коды, и при повторнй компрессии они могут совпасть, что повлечет за собой неправильную декомпрессию (только не бейте по голове, если я сказал какую-то тупость :-) )... Такие глюки проявляются редко, но постарайтесь, чтобы в Вашем компрессоре их небыло вообще. НЕСКОЛЬКО СОВЕТОВ ЧЕЛОВЕКУ ПИШУЩЕМУ МУЗЫКАЛЬНЫЙ РЕДАКТОР. 1. Если Вы уж решили его написать, то Вы должны превзойти все существующие до этого редакторы, иначе зачем же этим заниматься. В таком случае просто необходимо написать полноценный конвертор из всех редакторов в Ваш. 2. Важно, чтобы player занимал как можно меньше тактов. Желательно 2-3 тысячи. В противном случае область использования вашего редактора очень сузится. 3. Прилагайте к редактору исходный вариант playera в формате какого-либо ассемблера (желательно "TASM" т.к. из него проще всего конвертировать файл в любой другой редактор). Можно также прилагать текст проигрывателя в обычном текстовом формате. 4. В первую очередь советую ознакомиться с редакторами на других платформах. Могу посоветовать посмотреть редактор "OCTAMED" на AMIGA. Я думаю, Вы найдете там кучу полезных идей по сервису и Ваш редактор получится гораздо удобнее. 5. Кроме облегчения жизни музыканту, следует позаботиться и о кодере, который будет использовать музыку в своей программе. Будет очень удобно, если вы реализуете realtime timer.То есть таймер, который будет показывать время проигрывания музыки с точностью до прерывания. Это поможет синхронизировать музыку в программе с графикой. 6. Сделайте возможность изменения громкости мелодии во время проигрывания, чтоб можно было легко реализовать затихание музыки. Можно ввести три переменные в player'е, которые будут содержать значение максимальной громкости для каналов A,В,C. 7. Вывод в любой из трех каналов должен просто отрубаться в любой момент проигрывания, чтобы можно было пустить по этому каналу sound FX. 8. Неплохо было бы сделать возможность перехода на любую позицию. Это позволит быстро перейти в любое место мелодии, хранить несколько мелодий в одной или, например, использовать мелодию как набор звуковых эффектов. O СОВЕТОВ ЧЕЛОВЕКУ РЕШИВШЕМУ НАПИСАТЬ ГРАФИЧЕСКИЙ РЕДАКТОР. Вероятность того, что вы станете писать столь обширный проэкт крайне мала. Кроме того мы (AVALON) сами пишем GFX editor. Поэтому, вместо того чтобы давать советы вам, я попрошу всех, у кого есть интересные идеи, связаться со мной и поделиться ими. Еще,недавно мы услышали, что графические редакторы пишут в Кишиневе, Питере и Харькове, но пока поттверждения этим данным у нас нет. Если это действительно так, мы просим группы, занимающиеся этим, связаться с нами и объединить наши усилия. У нас готово всего процентов 2O-25, но вместе с тем, есть целая куча идей и заготовок. Не хотелось бы заниматься тем, что кто-то уже сделал... тел. (O4622) 5-36-O8 (Виктор) адрес: 2SOOOS Украина, г. Чернигов, ул. Киевская, 6 / 34. Онищенко Виктору. КОНКРЕТНЫЕ РЕКОМЕНДАЦИИ АВТОРАМ НЕКОТОРЫХ СИСТЕМНЫХ ПРОГРАММ. 1. "ALASM" ву ALEM Ассемблер обязательно должен понимать двоичное представление чисел, записанное после знака % (например %OOOOOOO1). При загрузке WORK файла курсор лучше сразу установить на последний записанный исходник. Возможность пометки части текста другим цветом или инверсией. Так же отмечать другим цветом строки с ошибками. По нажатию определеленной комбинации клавиш, ассемблер должен запоминать текущее положение в тексте, и затем он должен иметь возможность быстрого перехода на это место. Команды одноразовой компиляции очень удобны, но часто встречается такая ситуация, когда подгружаются несколько файлов один за другим, и метки располагаются между ними. При этом при повторном ассемблировании адреса меток будут сбиты. Например фрагмент программы: MUSIC +INCBIN "RAVE+ " SPRITES +INCBIN "GFX_CODE" TABLE +INCBIN "DATA " При первой компиляции значения меток SPRITES и TABLE будут зависеть от длины предыдущих файлов, как и должно быть, но при последующем ассемблировании, когда маркер "+" будет заменен на "-", и файлы подгружаться не будут, все три метки будут указывать на один и тот же адрес. Я думаю, чтобы этого избежать, достаточно запоминать при ассемблировании длины всех подгружаемых файлов и затем их прибавлять при каждой последующей компиляции. Полезно также отключать звук на АУ, после возврата из запускаемой программы. Можно также, чтобы незадействованная клавиша BREAK в режиме редактирования работала как ENTER, но с переводом строки не на поле меток, а на поле команд. Работу с диском лучше организовать как в "TASM-4", то есть подгружать каталог диска в память и брать параметры файлов прмо оттуда, не гонять головку лишний раз на нулевой трек. И еще несколько советов не только ALEM'у, а и всем создателям ассемблеров: Желательно предусмотреть тестирование запускаемых процедур по времени, в лучшем случае с точностью до такта, чуть хуже с точностью до четырех, а в крайнем случае хотя бы с точностью до прерывания, используя системный счетчик ( FRAMES ). Необходимо, чтобы после выхода из запущенной программы, не очищая экран, можно было войти в специальный режим вычисления экранных адресов. А именно в режим, когда по экрану ездит указатель величиной в один байт или одну точку, и при нажатии FIRE выводится адрес данного байта в экранном файле, в области атрибутов и координаты по X и У. Была бы полезной команда которая привязывает следующий адрес компиляции к ровному шеснадцатиричному адресу. Хотелось бы, чтобы в ассемблерах были команды типа: SAVE O TRACK TO 159 и RESTORE O TRACK FROM 159. 2. STS ву STALKER Если при записи файла на диск там уже будет файл с таким же именем и при этом находящийся в конце каталога, его нужно стирать и записывать новый файл на его место, как делает подавляющее большинство программ. При вводе числовых параметров для различный функций, например COPY, необходимо привязывать вводимые числа не к правому краю окна, а к левому, чтоб не приходилось постоянно двигать курсор на несколько знаков правее. 3. PERFECT COMMANDER ву JAMES ADVENT В моей версии коммандера, наблюдается один незначительный, но неприятный глюк: при копировании нескольких файлов на диск на котором осталось меньше 256 секторов, коммандер иногда "делает вид", что копирование прошло удачно, а на самом деле последние файлы не переписываются. Если же коммандер перезапустить, все будет скопировано отлично. Перед просмотром экрана, лучше забивать атрибуты кодом O. Не помешает также элементарный проигрыватель компилированной музыки, при этом сам коммандер должен "спрятаться" в страницах и подгрузить музыку с player'ом под любой адрес. 4. TOTAL COMMANDER ву Dr. LOVE Обязательно сделай "горячие" клавиши, т.к. с окнами работать слишком медленно. Советую получше подобрать цвета в коммандере, чтоб он не смотрелся так чересчур пестро, это только мешает восприятию информации. Необходимо реализовать возможность запуска кодовых файлов. Возможность выбора любой маски для выводимых файлов. В данной статье я рассмотрел лишь несколько программ, но если у Вас есть какие-либо идеи или замечания по системному soft'у, пишите мне или в редакцию и мы продолжим эту тему в следующих номерах журнала. Желаем творческих успехов в деле создания системных программ !!!
Другие статьи номера:
Похожие статьи:
В этот день... 21 ноября