Оригинал это видео которое имплантировано в текст. Сам текст же не является переводом поскольку на 3/4 состоит из другого текста нежели говорит голос в видео.
Эта заметка писалась когда еще Ion Maiden не была переименована в Ion Fury.
Это же надо было прикопаться к такому.
Маркетологи рок-группы по моему пробили днище из днищ.
Я реально не понимаю связи. Почему 36 какое то отношение имеет к ноте C-4 и какое отношение обе этих вещи вообще могут иметь к потоку однобитовых звуковых данных со звуком лающей собачки.
У музык и sfx всё было достаточно просто — 0..N и соответствующие API логичные и простые и их легко было увидеть в интерфейсе в поле «Song», а тут непонятно.
Но я всё-таки вообще не шарю как музыкант в трекерных этих делах потому что музыкантом даже близко не являюсь и в трекерах шарю как та лающая собачка в апельсинах. Поэтому не удивительно.
Ладно, я даже уже из-за необходимости 3 раза опрашивать контроллер выкинул DCPM из урока, проблем куча, а одно уже только объяснение почему я его выкинул заняло полэкрана. Со всеми этими фейковыми считываниями портов ввода и как там биты портятся.
Думаю это годится на «сложную» тему в будущем после мапперов и полноценного скроллинга реальной карты метатайлов. Посмотрим. Так или иначе спасибо за ответы.
Появились еще вопросы связанные с Samples. Тут мне не хватает уже видимо знаний самого Famitracker, как устроены его мелодии.
1. Правильно ли я понимаю, что Samples изначально могут быть как бы инструментами в мелодии?
2. Правильно ли я понимаю, что Samples поэтому как бы пристёгнуты в первую очередь к мелодии и чтобы их инициализировать нужно вызвать FamiToneMusicInit?
3. Когда мы Samples грузим через .incbin по адресам в верхних 16Кб ПЗУ — там внутри .dmc файла тоже есть некий заголовок который хранит сколько самплов тут есть? Потому что совсем непонятно почему в demo.asm вызывается так:
lda #36 ;play sample 36
jsr FamiToneSamplePlay
но в readme.txt написано:
FamiToneSamplePlay
A is sample number 1..12 (i.e. note C..B with assigned sample).
«Таким образом в итоге в буфере остаются данные только самых громких частей… Это не самое оптимальное решение, но оно вполне рабочее»
На практике звучит отлично. Давно удивлялся как при всего четырёх-пяти физических осцилляторах-каналах на практике игр у Famicom/NES/Денди и музыка играет и выстрелы-попадания-прыжки звучат как влитые. И ощущение, что музыка выпадает существует прям на грани восприятия. Ведь всё это было и звучало нормально.
«можно делать что угодно без ограничений и без указания авторства.»
Я вообще считаю обязательным такой тип лицензии для уроков/обучения, т.е. все мои уроки в той же лицензии. Но конечно в самих уроках нельзя не упоминать откуда берёшь материал.
Общаюсь по письму в неделю по поводу IDE Nesicide с Кристофером (который её автор) упомянул как то тебя и он мне написал следующее:
«Indeed. He is very talented. I created a nesicide project of his Alter Ego game to show debugging in C in nesicide.»
:)
У меня появилось два вопроса:
Первое — для теории мне надо понять как в Famitone2 Sfx совмещаются с музыкой и как они совмещаются друг с другом. Подозреваю что Sfx-каналы с меньшими номерами пишут в порты в Update позже больших и таким образом просто перетирают их осцилляторы при коллизиях. А вот как с музыкой оно сосуществует?
Второе — для урока нужны примеры и музыки и звуков. Можно ли взять (естественно с указанием авторства) их из самой Famitone2 с одной стороны, а с другой стороны нет ли желания какую нибудь новую мелодию выставить? В license.txt я для всех сторонних материалов по умолчанию пишу «автор дал разрешение использовать в рамках данного урока, любые другие применения надо обсуждать с ним».
P.S.
Сегодня понял как вкравшаяся ошибка осталась незамеченной — если одновременно и FT_PAL_SUPPORT = 1 и FT_NTSC_SUPPORT = 1, то всё скомпилируется потому что выполнение пойдёт по ветке когда все символы определены и проблем не возникает. А вот попытка хоть что-то из этого отключить вызовет ошибку отсутствия определения символа FT_PITCH_FIX.
Подозреваю еще, что в культуре где как минимум три разных ассемблера на вкус и цвет многие просто правят не задумываясь «адаптируя исходник под другой ассемблер на свой» и не считая нужным сообщать что есть какие то проблемы, т.к. такое часто бывает.
Насколько я понял в последней версии 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 опять же.
У меня как раз вопрос по 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 и в многочисленных клонах на это уже ложили болт, т.к. с повышением скорости микросхем стало ненужно. Вопрос. Я так то просто что прочитал то и скомпилировал в статью.
Понятно, значит это чей то домысел или путаница в воспоминаниях. Буду исправлять. Спасибо. Хм, тогда даже интересно перепроверить то же самое про микродрайв, потому что странно что там в одних микросхемах отстаёт, а в других нет. Ладно, посмотрим…
Это же надо было прикопаться к такому.
Маркетологи рок-группы по моему пробили днище из днищ.
И кто комментирует её первым?
>8-D
Я реально не понимаю связи. Почему 36 какое то отношение имеет к ноте C-4 и какое отношение обе этих вещи вообще могут иметь к потоку однобитовых звуковых данных со звуком лающей собачки.
У музык и sfx всё было достаточно просто — 0..N и соответствующие API логичные и простые и их легко было увидеть в интерфейсе в поле «Song», а тут непонятно.
Но я всё-таки вообще не шарю как музыкант в трекерных этих делах потому что музыкантом даже близко не являюсь и в трекерах шарю как та лающая собачка в апельсинах. Поэтому не удивительно.
Ладно, я даже уже из-за необходимости 3 раза опрашивать контроллер выкинул DCPM из урока, проблем куча, а одно уже только объяснение почему я его выкинул заняло полэкрана. Со всеми этими фейковыми считываниями портов ввода и как там биты портятся.
Думаю это годится на «сложную» тему в будущем после мапперов и полноценного скроллинга реальной карты метатайлов. Посмотрим. Так или иначе спасибо за ответы.
1. Правильно ли я понимаю, что Samples изначально могут быть как бы инструментами в мелодии?
2. Правильно ли я понимаю, что Samples поэтому как бы пристёгнуты в первую очередь к мелодии и чтобы их инициализировать нужно вызвать FamiToneMusicInit?
3. Когда мы Samples грузим через .incbin по адресам в верхних 16Кб ПЗУ — там внутри .dmc файла тоже есть некий заголовок который хранит сколько самплов тут есть? Потому что совсем непонятно почему в demo.asm вызывается так:
но в readme.txt написано:
Откуда эти числа берутся на самом деле?
На практике звучит отлично. Давно удивлялся как при всего четырёх-пяти физических осцилляторах-каналах на практике игр у Famicom/NES/Денди и музыка играет и выстрелы-попадания-прыжки звучат как влитые. И ощущение, что музыка выпадает существует прям на грани восприятия. Ведь всё это было и звучало нормально.
«можно делать что угодно без ограничений и без указания авторства.»
Я вообще считаю обязательным такой тип лицензии для уроков/обучения, т.е. все мои уроки в той же лицензии. Но конечно в самих уроках нельзя не упоминать откуда берёшь материал.
Общаюсь по письму в неделю по поводу IDE Nesicide с Кристофером (который её автор) упомянул как то тебя и он мне написал следующее:
«Indeed. He is very talented. I created a nesicide project of his Alter Ego game to show debugging in C in nesicide.»
:)
Первое — для теории мне надо понять как в Famitone2 Sfx совмещаются с музыкой и как они совмещаются друг с другом. Подозреваю что Sfx-каналы с меньшими номерами пишут в порты в Update позже больших и таким образом просто перетирают их осцилляторы при коллизиях. А вот как с музыкой оно сосуществует?
Второе — для урока нужны примеры и музыки и звуков. Можно ли взять (естественно с указанием авторства) их из самой Famitone2 с одной стороны, а с другой стороны нет ли желания какую нибудь новую мелодию выставить? В license.txt я для всех сторонних материалов по умолчанию пишу «автор дал разрешение использовать в рамках данного урока, любые другие применения надо обсуждать с ним».
Сегодня понял как вкравшаяся ошибка осталась незамеченной — если одновременно и FT_PAL_SUPPORT = 1 и FT_NTSC_SUPPORT = 1, то всё скомпилируется потому что выполнение пойдёт по ветке когда все символы определены и проблем не возникает. А вот попытка хоть что-то из этого отключить вызовет ошибку отсутствия определения символа FT_PITCH_FIX.
Комментарии и код предполагают как бы такое использование:
т.е. идентификаторы воспринимаются как макросы которые могут быть 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 и в многочисленных клонах на это уже ложили болт, т.к. с повышением скорости микросхем стало ненужно. Вопрос. Я так то просто что прочитал то и скомпилировал в статью.