Насколько я понял в последней версии 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 и в многочисленных клонах на это уже ложили болт, т.к. с повышением скорости микросхем стало ненужно. Вопрос. Я так то просто что прочитал то и скомпилировал в статью.
Понятно, значит это чей то домысел или путаница в воспоминаниях. Буду исправлять. Спасибо. Хм, тогда даже интересно перепроверить то же самое про микродрайв, потому что странно что там в одних микросхемах отстаёт, а в других нет. Ладно, посмотрим…
«откуда инфа? что именно с бета-диском так происходит?»
Я из таких лоскутов это собирал что уже не вспомню, иногда просто форумы какие то. Если это точно неправда, то надо исправить и тут. Прошу проверить даже такой момент — есть ли точки входа где байты в оригинальном пзу ненулевые.
откуда инфа? что именно с бета-диском так происходит?
я вот сдуру сделал так в своём эмуляторе, и после этого стал неправильно работать TESTall: vtrd.in/system/TEST_ALL.zip
который переходит на #3D30 явно предполагая, что выбираться с него будет уже опкод ret из ПЗУ тырдоса
а в других эмулях — unreal, spin, xpeccy — оно работает!
Попробовал так сделать — ассемблер ругается что символ неопределён. Логично, ведь ini-файл есть параметр в линкер, но не в ассемблер. А если сообщаешь через .global что есть символ который потом пытаешься положить в .byte, то ругается что range error. Опять таки логично, ведь символы это адреса как правило и обойти можно сделав <NAME, т.е. взять младший байт и видимо в простой ситуации как PRG_BANKS уже сработало бы, но я попытался воткнуть это в вычисление по битовым маскам
byte MIRRORING | (HAS_SRAM << 1) | ((MAPPER & $0F) << 4) | NAME
и тут линкер выдал ошибку «Attribute expected» которая даже не гуглится особо да и я не понимаю как линкер может такое вообще отрабатывать нормально. Если только весь байт сразу там и определить разве что, но есть ли там битовые операции?
Комментарии и код предполагают как бы такое использование:
т.е. идентификаторы воспринимаются как макросы которые могут быть 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 и в многочисленных клонах на это уже ложили болт, т.к. с повышением скорости микросхем стало ненужно. Вопрос. Я так то просто что прочитал то и скомпилировал в статью.
может ли так быть, что оригинальный фирменный бета-диск и наши клоны выборку по-разному делают?
Я из таких лоскутов это собирал что уже не вспомню, иногда просто форумы какие то. Если это точно неправда, то надо исправить и тут. Прошу проверить даже такой момент — есть ли точки входа где байты в оригинальном пзу ненулевые.
откуда инфа? что именно с бета-диском так происходит?
я вот сдуру сделал так в своём эмуляторе, и после этого стал неправильно работать TESTall:
vtrd.in/system/TEST_ALL.zip
который переходит на #3D30 явно предполагая, что выбираться с него будет уже опкод ret из ПЗУ тырдоса
а в других эмулях — unreal, spin, xpeccy — оно работает!
byte MIRRORING | (HAS_SRAM << 1) | ((MAPPER & $0F) << 4) | NAME
и тут линкер выдал ошибку «Attribute expected» которая даже не гуглится особо да и я не понимаю как линкер может такое вообще отрабатывать нормально. Если только весь байт сразу там и определить разве что, но есть ли там битовые операции?