Исходники журнала "Черная ворона"

[Rene Sens]

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

И оказалось, что либо я туплю, либо тут что-то не так...

Ну то, что Alasm 5.07 отказался понимать директивы вроде

DD "maks..."
DD "информация"

это ладно, это можно исправить.

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

То есть, например, в файле BOPOHA.h, встречаем что-то вроде:

LD (STEK),SP
CALL INIT
CALL PAGE

а эти самые STEK, INIT, PAGE впервые встречаются в BOPOHA2 или BOPOHA3, которые подключаются после вышеприведенных команд.

И естественно, дебаггинг выявляет, что на месте CALL INIT находится веселая команда CALL #0000.

Так в чем прикол?

[Advertiser]

[Vitamin]

Если не ошибаюсь, переменные объявленные через EQU должны быть объявлены ДО использования, а вот если они объявлены как метки, то без разницы где. Ибо заполнение мест использования происходит после резолвинга метки. Так что call 0 - это весьма странно

По поводу DD - это скорее всего следствие изменения формата файлов - похоже, что ранее коду соответствовло DEFM, а в новом формате это уже DD

[Rene Sens]

Понятно, значит какие-то еще непонятки там присутствуют.

Добавлено через 18 часов 42 минуты
В результате дальнейших экспериментов установил, что проблемы дает файл BOPOHA4.h
Если его подключение закомментить, то ассемблирование проходит на ура (не считая, конечно нераспознанных меток), и вместо CALL #0000 появляются правильные адреса процедур. И в общем-то даже журнал с некоторыми ухищрениями запускается и даже что-то пытается делать, однако ясно, что это не выход.

А если не отключать вышепоименованный файл, то при его ассемблировании вываливается занятная синтаксическая ошибка:

ADD IX,G

Какое-то "г" короче. Что за "г"?
И что характерно ничего подобного в тексте нет!

Добавлено через 18 часов 58 минут
Все! Разобрался! (Хотя вопросы остались)

Дело в АЛАСМе. В версии 4.41 Stall Edition ассемблирование прошло без всяких проблем (если не считать того, что из основного файла процесс не пошел, а когда я загрузил на редактирование подключаемый файл, то ассемблирование стартовало ).

[GriV]

Насколько я помню пробелм с компилированием файлов с константами EQU заданными в подгружаемых файлах нет.
Да, при первом проходе он оставляет call #0000, но после того как подсоединит нужный файл метки аттачит и меняет все эти Call на call #1234 если угодно.
Я даже в GENS'е так делал. И подключение вроде всегда похже выполнял %)
а с ADD IX,G очевидно глюк распаковки текста алясма...