Пятница, 15.12.2017, 09:04
БК-0010.01. Повесть о настоящем компьютере
Главная Регистрация Вход
Приветствую Вас, Гость · RSS
Меню сайта
Категории каталога
Введение в руководство [2]
Введение [0]
Организация БК-0010 [1]
Раздел 1. Организация БК-0010
Работа с МСД [1]
Раздел 2. Работа с МСД
Системные регистры [1]
Раздел 3. Системные регистры
Системное ПО [1]
Раздел 4. Системное программное обеспечение БК-0010
Прерывания. Приоритет ЦП [1]
Раздел 5. Система прерываний БК-0010. Приоритет процессора
Командные прерывания [1]
Раздел 6. Командные прерывания
ЕМТ БК-0010 [1]
Раздел 7. командные прерывания ЕМТ БК-0010
Коды и ассемблер. Мнемокод. [1]
Раздел 8. Коды и ассемблер. Мнемокод. Формат команды
Способы адресации [1]
Раздел 9. Способы адресации
Команды процессора БК-0010 [1]
Раздел 10. Система команд процессора БК-0010
Псевдокоманды. Метки. Комментарии [1]
Раздел 11. Псевдокоманды ассемблера. Метки. Комментарии
Программирование на ассемблере [1]
Раздел 12. Программирование на ассемблере. Начало. Трансляция программ. Ошибки
Отладка программ [1]
Раздел 13. Отладка программ. Позиционно-независимое программирование. Компановка
Подпрограммы ПЗУ БК-0010 [1]
Раздел 14. Подпрограммы ПЗУ БК-0010
Системная область ОЗУ БК-0010 [1]
Раздел 15. Системная область ОЗУ БК-0010. Некоторые секретные сведения об авторе и МП-клубе
Повышение быстродействия БК-0010 [1]
Раздел 16. Вопросы повышения быстродействия БК-0010
Об использовании ПЗУ [1]
Раздел 17. Полезная подпрограмма. Об использовании ПЗУ
Загадочные регистры [1]
Раздел 18. Загадочные регистры
Штурм системной области [1]
Раздел 19. Продолжаем штурм системной области
Об автозапуске программ [1]
Раздел 20. Об автозапуске программ
Коварные программы [1]
Раздел 21. Коварные программы
Еще о системной области [1]
Раздел 22. О пользе плагиата, или еще о системной области
О псевдокомандах и компановке [1]
Раздел 23. Еще раз о псевдокомандах, метках и компановке
Тук-тук, кто в стеке живет? [1]
Раздел 24. Тук-тук, кто в стеке живет?
Фокал с позиций ассемблера [1]
Раздел 25. Взгляд на фокал с позиций ассемблера
Наш опрос
Оцените мой сайт
Всего ответов: 47
 Каталог статей
Главная » Статьи » Программирование на ассемблере

Программирование на ассемблере. Начало. Трансляция программ. Ошибки

Теперь вы знаете, в принципе, вполне достаточно, чтобы приступать к программированию на ассемблере. С чего же начать? Как всегда, с начала. предположим, мы решили написать простейшую игру, развивающую глазомер и скорость реакции. Представим себе, что мы хотим получить. Пусть по одному краю экрана движется какой-либо символ -"мишень". Навстречу ему по другому краю экрана пусть движется с иной скоростью другой символ. При совпадении позиций символов требуется нажать любую клавишу. Если момент выбран правильно, следует звуковой сигнал, начисляется 1 очко, и игра продолжается. Если же мы "промахнулись", очко не начисляется, и звука нет. Игра продолжается, например, до 100 попыток. Таков черновой набросок алгоритма. Теперь попробуем представить те средства БК-0010, с помощью которых мы будем реализовать наш алгоритм.
Прежде всего, очевидно, нам потребуется устанавливать курсор на противоположных краях экрана (ЕМТ 24), постоянно изменяя его положение по 'х' (R1), причем предыдущее положение требуется где-то хранить. затем, нам потребуется печатать выбранные символы "стрелка" и "мишени" (код R0, ЕМТ 16), предварительно стирая символ в предыдущей позиции (код пробел=40, ЕМТ 16). Затем, потребуется после каждого перемещения символов определять, не нажата ли клавиша (разряд 06, регистр 177716) делать это лучше всего оператором BIT.
Если клавиша не нажата, продолжаем смещать символы. если нажата - требуется сравнить позиции 'х' символов. если они не совпадают ("промах"), то добавить 1 к числу попыток, вывести новое число сделанных (или оставшихся до 100) попыток в какое- либо место экрана, и продолжать, если число попыток было не более 100. если же позиции совпали, то, кроме того, выдать звук (запись с определенной частотой чередующихся 0 и 1 в разряд 06 рег.177716), добавить 1 очко, и продолжать. если же число попыток превысило 100, выдать сообщение о конце игры, и ее результат. очевидно, что нам потребуется организовать множество ветвлений программы с помощью операторов условных переходов, придется использовать и операторы сравнения CMP.

Что, можно начать писать программу? Нет еще. наверное, нам еще потребуются временные задержки после каждого перемещения символов, иначе скорость игры будет слишком велика (давно ли мы сетовали на низкое быстродействие фокала!). Как это сделать, мы уже знаем (см. оператор SOB). конечно, такие же задержки потребуются и для формирования определенной частоты звука. А как мы будем изменять положение символов? Так как в строке экрана 64 позиции, очевидно, что каждый раз один из символов или оба должны смещаться на 1 позицию, или же оставаться на месте, причем, желательно, в случайной последовательности. Видимо, нам будет нужен генератор случайных чисел. даже беглое знакомство с формулами простейших таких генераторов покажет, что реализовать их на ассемблере, не имеющем операторов деления и умножения, будет очень трудно.

Как быть? Мы могли бы, конечно, использовать генератор FRAN() фокала, но мы даже приблизительно не представляем, Как к нему обратиться (это, и в самом деле, довольно сложно). Подумаем. Ага, в БК-0010 есть ПЗУ, а это ни что иное, как последовательность нулей и единиц, для играющего совершенно случайная! Прекрасно: будем каждый раз выбирать по 1 биту (например, 00) очередного слова ПЗУ, и использовать его для задания смещения символа - 0 или 1. ПЗУ МСД+ПЗУ фокала дадут нам 40000 случайных бит. Если этого мало, можно пройти ПЗУ еще раз, но уже используя биты 01, и т.д. а как нам вывести информацию на экран, например, счет игры? Потребуется, очевидно, подпрограмма преобразования двоичного содержимого ячеек памяти в коды восьмеричных, а еще лучше - десятичных чисел. Как она должна выглядеть? Придется, видимо, вспомнить, как преобразуются числа из одной системы счисления в другую, составить алгоритм и написать подпрограмму (автор не надеется, что все читатели справятся с этой задачей, но есть обширная литература по этому вопросу).

Если же нам потребуется вывести текстовое сообщение, то мы уже знаем, как это сделать. А что будет, когда символы достигнут краев экрана (х>63д или х<0)? В фокале курсор "перескочит" на другой край экрана, и его позиция составит (х)mod64 (остаток от деления числа х на число позиций экрана). Это нас устроит, А как в ассемблере? мы этого не знаем (автор-то знает, но молчит!). Не придется ли определять конец экрана (х=63, х=0)? Видимо, нужно проверить это экспериментально. а что произойдет, если игрок нажмет клавишу и будет держать? игра будет всегда успешной? Нет, ведь при этом будет больше несовпадений. А если игрок просто не успел вовремя отпустить клавишу? Будут потеряны попытки? Не лучше ли останавливать игру на время, пока клавиша нажата? Это к тому же позволит "стрелку" убедиться воочию, "попал" он в символ-мишень, или нет.

Вот теперь наш алгоритм разработан (неформально, конечно) более или менее подробно. Но раньше, чем писать программу, подумаем, как бы мы еще хотели улучшить нашу игру, ведь всегда легче продумать это сразу, чем изменять готовую программу!

Например, неплохо бы в начале игры выводить текст правил. А не ввести ли классы игры по скорости? А не сделать ли игру постепенно усложняющейся, для чего вначале выводить символы в соседних строках экрана, а по мере увеличения числа набранных очков удалять их друг от друга? А не менять ли при этом и скорость игры? А не усложнить ли игру, например, падающими по экрану "вкось" символами? А не сделать ли символ "стрелка" управляемым, например, клавишами, и , и поставить задачу уклоняться от этого "дождя", ограничив число "жизней"? А не нарисовать ли вместо символа "мишени" какого-либо динозавра? А вместо символа "стрелка" и на самом деле - стрелка с луком? А не сделать ли "стрелы" видимыми? но давайте остановим полет фантазии, пока не поздно. И так уже игра в таком виде начинает сильно напоминать известные игры "саранча" на Т-языке (рига), или "пифпаф", asp-corp. (зеленоград). Так как нам явно не "переплюнуть" эти знаменитые "фирмы", оставим игру в ее исходном варианте, пусть ее преимуществом будет простота!

А вместо того, чтобы фантазировать, начнем-ка писать программу. Пусть читатель не надеется, что автор вместе с ним будет претворять изложенный алгоритм в текст ассемблера. Как бы ни хотелось это сделать, это просто невозможно в кратком руководстве, да и в длинном тоже. на подробный разбор такой, казалось бы, простейшей программы, уйдет не один десяток страниц, и не один день. вот когда воочию видна разница между скоростями мышления и речи! Поэтому придется предоставить возможность написать такую игру самому читателю, благо поле деятельности свободно: такой игры еще нет, автор просто сделал попытку представить, как она может выглядеть. он может только еще посоветовать не жалеть места для комментариев, описывать в них вначале буквально каждую строку ассемблера, иначе вы перестанете понимать свою программу задолго до конца работы.

Но вот текст программы написан. что дальше? Не забыли поставить в конце <end>? Тогда выходим из редактора микро8, и даем директиву трансляции <CO>.
Вот уже строки текста бегут по экрану так быстро, что мы ничего не успеваем прочитать - это работает транслятор. И вдруг - остановка! Конец? Нет - на экране сообщение: "ошибка ...", и часть строки, в которой транслятор обнаружил ошибку. По таблице ошибок справимся, что именно произошло, вернемся в  редактор, и исправим ошибку. Снова выйдем из редактора, и повторим трансляцию. Вот теперь она закончена: в конце сообщение: "ДЛИНА=...", и таблица меток.

Но что это?! Некоторые метки, как белые вороны, выданы инверсными символами! Это метки, которые мы забыли поставить, хотя и обратились к ним по ходу программы. Снова вернемся в редактор, и проставим все метки. Вновь трансляция! Ошибок нет! Инверсных меток нет! Ура! Но не спешите радоваться: все только начинается. Теперь, зная, что транслятор формирует загрузочный модуль, т.е. собственно программу в кодах, с адреса 12000, мы можем выйти из ассемблера (клав.стоп), и запустить ее для проверки (так не терпится это сделать поскорее!). однако благоразумие требует сначала записать текст программы на МЛ, ведь если наша программа написана неправильно, она может испортить ассемблер, и тогда все пропало! Ну что ж, ST имя, пишем! Записали? Тогда - вперед! стоп, 12000G. Ну, как?!
Если ваша программа сразу "пошла", знайте, что случилось чудо. А если, наоборот, она совсем ничего не делает, или делает непонятно что, значит, все идет, как надо! Приступаем к отладке.

Для этого вернемся в ассемблер - 1114G (при этом текст программы сохранится, если только мы не испортили ассемблер!), войдем в редактор (SC), и попытаемся понять, что произошло, где же мы ошиблись? Это значит, что мы заново пройдем все этапы создания программы, от алгоритма до каждого оператора, имея перед глазами текст, а в душе - твердую надежду на то, что программа нам в конце концов покорится.

Вот здесь, "в минуту, злую для него" (А. С. Пушкин), мы и покинем нашего читателя... до следующего раздела.


 
**************************************************************************************
** основы системного программирования для БК-0010 **
** зальцман ю.а., мп-клуб, г.алма-ата, тел.691797 **
** декабрь 1987 г.! **
**************************************************************************************
Категория: Программирование на ассемблере | Автор: ЗАЛЬЦМАН Ю.А., МП-КЛУБ, г.АЛМА-АТА
Просмотров: 650 | Рейтинг: 0.0/0 |

Всего комментариев: 0
Имя *:
Email *:
Код *:
Используются технологии uCoz
Форма входа

Поиск
Друзья сайта
Статистика