P.S.
Сегодня понял как вкравшаяся ошибка осталась незамеченной — если одновременно и FT_PAL_SUPPORT = 1 и FT_NTSC_SUPPORT = 1, то всё скомпилируется потому что выполнение пойдёт по ветке когда все символы определены и проблем не возникает. А вот попытка хоть что-то из этого отключить вызовет ошибку отсутствия определения символа FT_PITCH_FIX.
Оставлю это здесь, для подшивки к основополагающим принципам.
Релизы идеально называть именами не больше 8 букв для сохранения совместимости с разными файловыми системами.
Старая кассетная школа говорит нам, что имя может быть 10 символов — ОК.
Однако если вы пошли дальше, и пишите длинное название релиза, учитывайте, что в браузере DivIDE FatWare видно всего лишь 19 символов (имя точка расширение). Если у вас несколько версий файлов и СУТЬ указана в конце (например финальный релиз Tiratok) то после копирования их на DivIDE просто невозможно понять, какой из файлов нужен.
Подозреваю еще, что в культуре где как минимум три разных ассемблера на вкус и цвет многие просто правят не задумываясь «адаптируя исходник под другой ассемблер на свой» и не считая нужным сообщать что есть какие то проблемы, т.к. такое часто бывает.
Я без понятия, видимо так. Надо понимать, что это старый проект, в который на протяжении многих лет предлагали изменения какие-то люди, ожидая, что я всё время только о нём и думаю — но мне, чтобы ответить на любой вопрос, теперь нужно разбираться столько же времени, сколько и любому другому человеку. Это вообще типичная история поддержки homebrew-проектов — первые несколько лет после выхода они не нужны и не интересны никому. А когда успел разочароваться в результатах, сделать десяток других, заняться вообще принципиально другими делами в жизни, люди вдруг начинают писать — а почему эта запятая не на том месте? А почему в конвертере в версии XYZ пятилетней давности было $30, а в версии XYZZ четырёхлетней давности стало $c0, но код плеера не поменялся? А почему окно конвертера открывается и сразу закрывается?
Версия CA65 автоматически генерируется из мастер-исходника для NESASM, вероятно отсюда растут ноги у проблемы. Вероятно, когда и если я с этим сталкивался сколько-то лет назад, я один раз пофиксил по месту и забыл. Но скорее просто за всё это время данные дефайны ни разу никому никаким образом не понадобились, включая меня — в рабочем коде пары текущих проектов они у меня точно в таком же виде, как в цитате выше.
Насколько я понял в последней версии Famitone2 (1.15) ( вроде бы одно и то же лежит и тут famitracker.com/downloads.php и тут shiru.untergrund.net/code.shtml ) закралась ошибка в версии исходника для CA65.
Комментарии и код предполагают как бы такое использование:
; FT_PAL_SUPPORT ;undefine to exclude PAL support
; FT_NTSC_SUPPORT ;undefine to exclude NTSC support
.if(FT_PAL_SUPPORT)
.if(FT_NTSC_SUPPORT)
FT_PITCH_FIX = (FT_PAL_SUPPORT|FT_NTSC_SUPPORT)
.endif
.endif
т.е. идентификаторы воспринимаются как макросы которые могут быть defined/undefined.
Но справка по ключевому слову .IF в CA65 www.cc65.org/doc/ca65-11.html#ss11.47 говорит, что .IF воспринимает константу времени компиляции которая обязана быть defined и трактует её как число ровно как c-style if.
Соответственно попытка компиляции выдаёт кучу ошибок и здесь и ниже везде на .if и чтобы этого не было нужно присвоить идентификаторам 0 или 1 и вообще убрать .if в данном случае (но не ниже по коду), т.е.:
FT_PAL_SUPPORT = 0 ; set 0 or 1
FT_NTSC_SUPPORT = 1
FT_PITCH_FIX = (FT_PAL_SUPPORT|FT_NTSC_SUPPORT)
Тогда вроде компилируется, хотя до запуска я еще не скоро дойду чтобы точно сказать что работает.
.if-ы в этих строках вообще получается что не нужны, т.к. могут сделать символ undefined и это вызовет ошибку ниже где он тестируется в .if опять же.
Да, переменные плеера занимают не всю страницу. В neslib они традиционно размещаются в странице стека, а также туда идёт буфер палитры, т.к. сам аппаратный стек в реальных программах не превышает 32 байт.
У меня как раз вопрос по FamiTone2 для следующих уроков. Верно ли что после того как мы целую страницу отдали под FT_BASE_ADR в ней всё-таки еще немало свободного места остаётся и им можно воспользоваться ориентируясь на FT_BASE_SIZE?
согласен. видимо это действительно было верно только для первых моделей. и в принципе полагаться на такое поведение для каких то спец-эффектов не было никакого смысла, а вот избавится от него — давало только профиты. возможно даже, что оно было актуально только для TR-DOS первых версий — тех что были предназначены для ZX Spectrum 48 и где точки входа вообще лежали в странице 3Cxx и где как упоминалось выше была другая более медленная память. так вот при переезде на ZX 128 этот подход уже могли сохранить по инерции или просто памятуя что проблема точно была для гарантии.
Да, было бы интересно узнать как точно всё было. А параграф про это в самой статье я постараюсь сделать как то более обтекаемым…
а я даже не успел увидеть, какие правки)) но одно дело утвердительно сказать «отстаёт», и совсем другое «может отстать» или даже «авторы прошивок полагали, что отстать может» (авторы же эмуляторов полагают, что в нормальной эталонной системе скорее переключится сразу)
P.S.
Проверил сам — если смотреть сюда: zxpress.ru/article.php?id=10362 для версии TR-DOS 5.04T описаны следующие точки входа:
15616 (3D00)
15619 (3D03)
15622 (3D06)
15629 (3D0D)
15632 (3D10)
15635 (3D13)
15638 (3D16)
15663 (3D2F)
Для всех в спектакулаторе в режиме пентагона верно то, что в оригинальном ПЗУ в этих адресах лежат NOP.
Для всех них верно так же то, что после переключения в ПЗУ TR-DOS в них так же лежат NOP-ы. Без исключений.
Код распрыжек почти везде (кроме последней точки, которая и не точка входа вовсе, а чит, насколько мне известно) выглядит как NOP:JR смещение.
В общем по моему этот NOP, как говорится, неспроста. Он явно был зачем то нужен и других версий кроме той что была изначально упомянута в статье — что это гарант некоей задержки или стабилизации шин при переключении банков я не вижу.
Поэтому пока восстановлю статью как она была вчера до правок. Если будут другие сведения — буду рад узнать и проапгрейдить статью до абсолютной истины. :)
«посмотрел, в литературе документирована 15663 — то есть #3D2F»
Т.е. пока правило, что официальные точки входа всегда смотрят в оригинальном ПЗУ в нулевые байты не нарушается?
Ладно, мне уже уходить фильм смотреть, но конечно будет интересно выяснится ли точно ошибка это или нет.
«может ли так быть, что оригинальный фирменный бета-диск и наши клоны выборку по-разному делают?»
Это может быть запросто. Микросхемы разного быстродействия, отклика, стабилизации всякой. В том же ZX 16/48 пресловутая раскладка видеопамяти сделана такой витиеватай же для того чтобы воспользоваться ускоренным режимом считывания page mode DRAM, а мне говорили что и в ZX 128 и в многочисленных клонах на это уже ложили болт, т.к. с повышением скорости микросхем стало ненужно. Вопрос. Я так то просто что прочитал то и скомпилировал в статью.
Понятно, значит это чей то домысел или путаница в воспоминаниях. Буду исправлять. Спасибо. Хм, тогда даже интересно перепроверить то же самое про микродрайв, потому что странно что там в одних микросхемах отстаёт, а в других нет. Ладно, посмотрим…
Сегодня понял как вкравшаяся ошибка осталась незамеченной — если одновременно и FT_PAL_SUPPORT = 1 и FT_NTSC_SUPPORT = 1, то всё скомпилируется потому что выполнение пойдёт по ветке когда все символы определены и проблем не возникает. А вот попытка хоть что-то из этого отключить вызовет ошибку отсутствия определения символа FT_PITCH_FIX.
Могу подтвердить, что на сером +2 Dizzy 3 сбрасывается в самом начале игры, в буквальном смысле — с первым снегом.
Релизы идеально называть именами не больше 8 букв для сохранения совместимости с разными файловыми системами.
Старая кассетная школа говорит нам, что имя может быть 10 символов — ОК.
Однако если вы пошли дальше, и пишите длинное название релиза, учитывайте, что в браузере DivIDE FatWare видно всего лишь 19 символов (имя точка расширение). Если у вас несколько версий файлов и СУТЬ указана в конце (например финальный релиз Tiratok) то после копирования их на DivIDE просто невозможно понять, какой из файлов нужен.
Версия CA65 автоматически генерируется из мастер-исходника для NESASM, вероятно отсюда растут ноги у проблемы. Вероятно, когда и если я с этим сталкивался сколько-то лет назад, я один раз пофиксил по месту и забыл. Но скорее просто за всё это время данные дефайны ни разу никому никаким образом не понадобились, включая меня — в рабочем коде пары текущих проектов они у меня точно в таком же виде, как в цитате выше.
Комментарии и код предполагают как бы такое использование:
т.е. идентификаторы воспринимаются как макросы которые могут быть defined/undefined.
Но справка по ключевому слову .IF в CA65 www.cc65.org/doc/ca65-11.html#ss11.47 говорит, что .IF воспринимает константу времени компиляции которая обязана быть defined и трактует её как число ровно как c-style if.
Соответственно попытка компиляции выдаёт кучу ошибок и здесь и ниже везде на .if и чтобы этого не было нужно присвоить идентификаторам 0 или 1 и вообще убрать .if в данном случае (но не ниже по коду), т.е.:
Тогда вроде компилируется, хотя до запуска я еще не скоро дойду чтобы точно сказать что работает.
.if-ы в этих строках вообще получается что не нужны, т.к. могут сделать символ undefined и это вызовет ошибку ниже где он тестируется в .if опять же.
И ещё раз извини за корпус!)
Да, было бы интересно узнать как точно всё было. А параграф про это в самой статье я постараюсь сделать как то более обтекаемым…
Проверил сам — если смотреть сюда: zxpress.ru/article.php?id=10362 для версии TR-DOS 5.04T описаны следующие точки входа:
15616 (3D00)
15619 (3D03)
15622 (3D06)
15629 (3D0D)
15632 (3D10)
15635 (3D13)
15638 (3D16)
15663 (3D2F)
Для всех в спектакулаторе в режиме пентагона верно то, что в оригинальном ПЗУ в этих адресах лежат NOP.
Для всех них верно так же то, что после переключения в ПЗУ TR-DOS в них так же лежат NOP-ы. Без исключений.
Код распрыжек почти везде (кроме последней точки, которая и не точка входа вовсе, а чит, насколько мне известно) выглядит как NOP:JR смещение.
В общем по моему этот NOP, как говорится, неспроста. Он явно был зачем то нужен и других версий кроме той что была изначально упомянута в статье — что это гарант некоей задержки или стабилизации шин при переключении банков я не вижу.
Поэтому пока восстановлю статью как она была вчера до правок. Если будут другие сведения — буду рад узнать и проапгрейдить статью до абсолютной истины. :)
Т.е. пока правило, что официальные точки входа всегда смотрят в оригинальном ПЗУ в нулевые байты не нарушается?
Ладно, мне уже уходить фильм смотреть, но конечно будет интересно выяснится ли точно ошибка это или нет.
но эмуляторы считают, что и переход на следующий адрес тоже сработает
Но тогда и прошивки разные должны быть. Непонятно.
Это может быть запросто. Микросхемы разного быстродействия, отклика, стабилизации всякой. В том же ZX 16/48 пресловутая раскладка видеопамяти сделана такой витиеватай же для того чтобы воспользоваться ускоренным режимом считывания page mode DRAM, а мне говорили что и в ZX 128 и в многочисленных клонах на это уже ложили болт, т.к. с повышением скорости микросхем стало ненужно. Вопрос. Я так то просто что прочитал то и скомпилировал в статью.
может ли так быть, что оригинальный фирменный бета-диск и наши клоны выборку по-разному делают?