Введение в C64 crossdevelopment

Этой статьей мы начинаем публикацию цикла переводов с сайта http://covertbitops.c64.org. Статья довольно старая, но некоторые моменты и общая концепция описанная в ней актуальны по сей день.

 

Добро пожаловать в наш самый первый разговор посвященный crossdeveloping для C64 и методам, которые я лично использую (не обязательно самым рекомендуемым).

0. История

Некоторые представления в этом разговоре довольно радикальные. Для начала я кратко расскажу о себе:

  • 1986 год —  Мне в руки попал C64.
  • 1987 год — Эксперименты в BASIC
  • 1988-1991 годы —  Эксперименты с ассемблером. Немного достижений, большинство проектов не закончено(частично можно обвинить в этом примитивные инструменты: SEUCK и MikroAssembler).
  • 1992 год — С этого года и далее в основном игры на C64.
  • 1995 год — Исследование возможностей эмуляции C64.
  • 1996 или 1997 год — Бросил заниматься C64.
  • 1998 год — Бороздя интернет натолкнулся на идею crossdevelopment. Начал работу над игрой Metal Warrior. Невиданный уровень производительности на C64.
  • 1999-2000 годы —  Crossdevelopment, crossdevelopment, crossdevelopment
  • 2001 и по сей день —  Снова работа над аппаратными средствами C64, crossdevelopment…

Так,  я благодарен в основном crossdevelopment за все мои успехи, стоящие упоминания.

1. Что такое crossdevelopment

Crossdevelopment использует различные (обычно, более мощные) платформы, чем целевая платформа для управления некоторыми или всеми программами, используемыми в процессе создания продукта (ассемблер, редактор текста, возможно редактор графики/музыки).

Преимущества C64 crossdevelopment:

  • Меньшее время компиляции из-за мощности процессора
  • Командные файлы или makefiles могут автоматизировать процесс компилирования
  • Редактирование может быть легче или быстрее при использовании современных утилит (например, PC как основной редактор текста для написания исходного кода)
  • Файлами на жестком диске легче управлять, а также более надежно хранить чем на дискете (хотя, некоторые люди оборудовали жестким диском C64.) В любом случае, помните важность резервных копий!

Недостатки C64 crossdevelopment:

  • Проверяя на эмуляторе, помните что графика (размытость телевизионного изображения!) и эмуляция звука еще не на 100% точна, и вероятно никогда не будет. Эмуляция процессора и чипов очень точна в настоящее время в хороших эмуляторах (например в CCS64 или VICE). Если Ваша программа работает в CCS64 и VICE, Вы можете на 99% быть уверены, что она будет работать на реальном C64.
  • Будьте осторожны с пользовательскими дисковыми процедурами! (fastloaders и т.д.). Если используете эмуляторы, проверяйте их и в VICE (используя несколько эмулируемых моделей дисководов) и CCS64 чтобы быть на 99% уверенным в работоспособности. Чтобы быть на 100% уверенными, проверьте на реальном C64. Я имею опыт неизвестной drivecode ошибки, которая появилась в CCS64 & реальном C64, но не в VICE.
  • Чтобы проверить на реальном C64, потребуется некоторое усилие, чтобы скопировать  программу (например, с помощью Star Commander и кабеля X1541). Но Я настоятельно рекомендую проверять на реальном C64, каждый раз, когда есть возможность!
  • Внесение небольших испытательных изменений в код и данные (например, с помощью freezer cartridge) во время выполнения может быть более удобным, чем перекомпилирование проекта в crossdevelopment-системе.

Crossdevelopment может быть «смешанным»: например, эмулятор C64 используется в основном для запуска C64 графических и музыкальных редакторов. Получающиеся файлы данных затем извлекаются из образа диска D64 по мере необходимости (у VICE есть также возможность «примонтировать» напрямую папку жесткого диска —  нет надобности в образах дисков)

2. Мои принципы и инструменты

Мой принцип crossdevelopment чрезмерно требователен, но лично для меня самый эффективный. Проще говоря, это:

Никакие «родные» C64 утилиты не используются в процессе создания

На первый взгляд это кажется довольно странным, для создания C64 программы казалось бы логичным использовать опробованные и проверенные временем  утилиты, по крайней мере для некоторых задач. Здесь приведены мои личные предпочтения для решения каждой задачи (не всегда подчиняясь правилу на 100%):

2.1 Исходный код

Я использую TSE (DOS редактор, много команд через клавишные сокращения) для редактирования исходного кода, разделение исходного кода на несколько файлов, по задачам (например, весь код растрового прерывания идет в один файл, весь код бегущей строки в другой) для удобства управления проектом.

Кроме того, нет проблем с памятью, являющейся основной проблемой C64 «родного» объединенного редактора/ассемблера (например Turboassembler). Я могу комментировать так, как я хочу и использовать длинные имена меток при необходимости.

Недавно я также экспериментировал с Windows редактором ConTEXT.

2.2 Графика спрайтов и фона

Рисование спрайтов обычно является обыденной задачей, практически одинаковое от проекта к проекту. Поэтому «родной»C64 редактор спрайтов будет прекрасно соответствовать задаче, без потребности в разных настройках (как например, редактор спрайтов в SEUCK).

Однако быстро возникают проблемы с фоновой графикой. SEUCK был бы прекрасен для простых игр со сдвигом экрана, но:

  • Он ограничен только вертикальным скролингом фона.
  • Блоки размером 5×5 символов. А если мы хотим 4×4?

Так что, вероятно, понадобится специальная утилита. Я не сомневаюсь, что напишу редактор для 32-битной платформы на языке C быстрее, чем я могу написать на C64 редактор на ассемблере (и редактор, написанный на BASIC , будет очень медленным для любых больших объемов работы в большинстве случаев). Это, как и все остальное, вопрос предпочтения. Для других это может быть быстрее, чем написать нa C64 утилиту, даже на ассемблере.

И как только я закончил свой первый редактор фона, общие процедуры и графика была пригодны для использования в PC редакторе спрайтов.

Если Вы интересуетесь программированием графических редакторов на 32-битной платформе, я могу предложить воспользоваться портативной SDL библиотекой или возможно моей собственнойBME библиотекой, которая использует SDL, но имеет некоторую высокоуровневую функциональность, например поддержка спрайтов там уже есть.

2.3 Растровые картинки

Я привык к Deluxe Paint за время моего программирования на Amiga. Поэтому, рисование в программе, подобной Deluxe Paint (сейчас я использую GRAFX2 для лучшей совместимости с NT/W2K), для меня наиболее естественно. Я настроил палитру, подобную C64, 2×1 сетку и размер кисти и начал рисовать(GRAFX2 доступен можно скачать здесь).

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

Хотя работа этим методом для меня быстра даже со всеми проверками, меня это не полностью удовлетворяет. Сделанная на PC программа рисования для C64 была бы идеальным решением, но программа рисования — намного большая задача, чем редактор символьного фона и я совершенно уверен, что не смогу написать такое. Я также боюсь завала из-за пожеланий новых функций…

Для преобразования картинок из IFF/LBM к совместимому с C64 формату я использую простые, самодельные утилиты.

Я знаю, что этот метод немного странный, поэтому я рекомендовал бы использовать программу рисования для C64. Однако это стоит попробовать хоть раз в жизни!

2.4 Музыка и звуки

Как и в предыдущей главе, метод, который я рекомендовал бы больше всего, использовать «родной» C64 редактор (главным образом потому что их доступно много), Но теперь давайте посмотрим то чего хотел я…

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

До сих пор я использовал 3 варианта:

  • Редактирование музыки непосредственно в исходном коде как байтовые данные. Символьные метки могут помочь в этом процессе (например, имена нот), но тем не менее я не могу порекомендовать этот метод любому работающему сегодня. Это полезно, если нужно сжать каждый байт музыкальных данных. Например, в Metal Warrior 3 памяти была чрезвычайно мало, и я запрограммировал систему «вызовов подпрограмм» в музыкальных данных. Таким образом музыкальные данные стали похожи на код программы, и возможно редактирование исходного кода было самым эффективным способом в этом случае.
  • Написание в «родном» C64 редакторе. Я делал это в SadoTracker, и  в NinjaTracker. Извлечение готовых мелодий из образа диска было болью, хотя я позднее автоматизировал это.
  • GoatTracker. PC музыкальный редактор для C64, поддерживающий reSID эмуляцию или HardSid.

2.5 Ассемблирование

Я выбрал кроссассемблер DASM от Мэтью Диллона, но есть много кроссассемблеров на любой вкус. Некоторые особенности, которые мне нужны от ассемблера:

  • Возможность работать с большими файлами (практически, ассемблер, должен быть скомпилирован с 32-битным C компилятором)
  • Макросы и поддержка операторов повторения
  • Генерация объектного кода в отличающийся логический от физического адреса; например, код для выполнения в дисководе или депакер компилируют так, чтобы он был скопирован в другой адрес памяти
  • Возможность включать другие файлы исходного кода и двоичные данные

В основном «главная программа» файла исходного кода для моих проектов похожа на это:

И полностью программа собирается по команде:

dasm program.s -oprogram.prg -p3

(-p3 включает 3 прохода при ассемблировании)

2.6 Управление процессом компиляции

Сложный проект может состоять из множества файлов, которые например, загружаются с диска по мере необходимости. Таким образом, было бы неуклюже, набирать все команды ассемблирования и манипулировать данными вручную каждый раз, когда надо что-то поменять.

В большинстве случаев командный файл все сделает хорошо; просто укажите все требуемые команды для полной компиляции программы.

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

 2.7 Кросскомпрессия

Не хотите ждать минуты или часы пока упаковщик или cruncher на C64 закончит работу? Дам простой совет, используйте Pucrunch от Pasi ‘Albert’ Ojala или Exomizer от Magnus Lind. Они легко могут быть объединены в загрузочную систему. Exomizer более эффективен и имеет меньшую процедуру распаковки, но сжатие занимает много времени.

2.8 Создание образа диска для проверки

Теперь есть связка файлов, лежащих на жестком диске, которые готовы к выполнению/загрузке на C64. Если есть только один файл, выполняемый, то следующий шаг ненужен; файл может быть записан на C64 дискету, непосредственно в C64 с помощью кабеля PC64 или запущен в эмуляторе. Кроме того, если тестирование происходит исключительно на реальном C64, программа из нескольких частей может быть передана одним файлом за раз на C64 дискету.

Но тем не менее хорошо бы знать, как сделать образ диска. Вот несколько способов:

— Использование программ, например, Star Commander или 64Copy, чтобы создать новое образ D64 и копирование в него файлов. Насколько я знаю, это делается вручную (не очень удобно).

— Использование программы C1541, включенную в комплект эмулятора VICE. Она включает в себя команды создания & форматирования нового образа диска и копирования файлов на него. Применяя командный файл к программе образ диска может быть создан автоматически.

— Использование некоторых других утилит копирования, чтобы скопировать файлы в образ диска один за другим. Лично я использую самодельную программу под названием MAKEDISK, которая использует список всех файлов, которые будут скопированы, и создает образ диска с нуля (дисковое имя и чередование секторов может быть задано как параметры командной строки).

3. Заключение

Этот разговор достиг своего конца и все главные аспекты crossdevelopment были рассмотрены. Помните, что все утилиты, упомянутые в этот тексте доступны в разделе «tools» на сайте http://covertbitops.c64.org

Удачи в C64 программировании!

Lasse Öörni

Перевод на русский: Crazy Bender/ex-PLACEBO

Добавить комментарий