Version 0.5 preview

General discussion about tracking, help and support.
8BitZtunerYT
Posts: 379
Joined: Thu Apr 23, 2015 7:20 pm
Location: Somewhere stuck in Winamp

Re: Version 0.5 preview

Postby 8BitZtunerYT » Fri Sep 18, 2015 11:44 am

I reported this somewhere but I wanted it to re-report again.
For whatever reason with any expansion chip, any NSF you export in Beta 5, there is the default NTSC region, but when using NSFplay, and activating Force PAL, the song still plays normal, not slowed down or anything, (sometimes) not pitched down whatsoever, the instrument data is of course slowed down, but the sequence is still playing at normal speed.
The Force Dendy option is not affected by this.
slowly ceasing to exist.
"8BitZ caresses his keyboard as he orgasms to the sounds of Winamp."
-retrodpc, 2015

User avatar
Stratelier
Posts: 378
Joined: Sun Apr 26, 2015 7:46 pm

Re: Version 0.5 preview

Postby Stratelier » Fri Sep 18, 2015 1:12 pm

8BitZtunerYT wrote:I reported this somewhere but I wanted it to re-report again.
For whatever reason with any expansion chip, any NSF you export in Beta 5, there is the default NTSC region, but when using NSFplay, and activating Force PAL, the song still plays normal, not slowed down or anything, (sometimes) not pitched down whatsoever, the instrument data is of course slowed down, but the sequence is still playing at normal speed.
The Force Dendy option is not affected by this.

Actually that sounds normal, NSFs compiled by FamiTracker try to achieve the Tempo specified in the song settings. Even if you're using Fxx sequences, 150 BPM is still 150 BPM.

8BitZtunerYT
Posts: 379
Joined: Thu Apr 23, 2015 7:20 pm
Location: Somewhere stuck in Winamp

Re: Version 0.5 preview

Postby 8BitZtunerYT » Fri Sep 18, 2015 4:12 pm

But PAL should be slower and not in the speed of NTSC.
slowly ceasing to exist.
"8BitZ caresses his keyboard as he orgasms to the sounds of Winamp."
-retrodpc, 2015

User avatar
za909
Posts: 79
Joined: Tue May 12, 2015 12:10 pm
Location: Hungary

Re: Version 0.5 preview

Postby za909 » Fri Sep 18, 2015 6:53 pm

That is the case unless you happen to select Dual compatibility mode for your exported NSF. In this case, the exported NSF attempts to play a PAL song with tempo 150, to approximate NTSC speed instead of using 125 for the tempo as the default PAL speed. You need to select which region you want it to work with.

User avatar
Stratelier
Posts: 378
Joined: Sun Apr 26, 2015 7:46 pm

Re: Version 0.5 preview

Postby Stratelier » Sat Sep 19, 2015 1:06 am

za909 wrote:In this case, the exported NSF attempts to play a PAL song with tempo 150 ... instead of using 125 for the tempo as the default PAL speed.

Yeah, that.

(This happens even without an NSF export, if all you do is change your engine speed in FT then your song will still play at the same tempo specified, just with a different engine resolution.)

8BitZtunerYT
Posts: 379
Joined: Thu Apr 23, 2015 7:20 pm
Location: Somewhere stuck in Winamp

Re: Version 0.5 preview

Postby 8BitZtunerYT » Sat Sep 19, 2015 10:13 am

I did mention it happens with any expansion chip, I always select NTSC.
slowly ceasing to exist.
"8BitZ caresses his keyboard as he orgasms to the sounds of Winamp."
-retrodpc, 2015

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Version 0.5 preview

Postby HertzDevil » Sat Sep 19, 2015 12:16 pm

PAL setting is invalid for expansion chips since they must use the NTSC clock rate, so FamiTracker deprecated them since version 0.4.0. It would be appropriate to enable only the NTSC region in the NSF export dialog, as FamiTracker will always write the NTSC region flag regardless of that dialog setting if any expansion chip is used. What happens to expansion chips in specific NSF players when they are forced to use the PAL region on NSF files in general is completely irrelevant to FamiTracker.

NSFPlay (and most likely other NSF players with a region setting) simply writes the overridden region flag to the X register; on initializing a dual-region tune, the NSF driver is supposed to read this value from the X register and perform necessary steps in the INIT routine to set up its variables. In the case of FamiTracker, this includes:
  • The internal speed divider, which sits at the header of the music data exported in FamiTracker. There are two values, corresponding to NTSC and PAL, formed as a multiple of the respective default clock rate, or the FTM's custom clock rate. Both values are present in the NSF regardless of the number of regions specified, so that only one version of the NSF driver is required when handling dual-region NSFs. The smaller these values are, the faster the NSF driver steps through the rows in terms of number of ticks; tempo inaccuracy would occur if these results are not integers. Note also that these values do not change according to the region setting in the export dialog; that affects only the region flag in the NSF header. When forcing NSFPlay to use the PAL region, it loads the refresh rate at $78 of the NSF header, and loads 0x01 into the X register.
  • The address of the 2A03 period lookup table. This address is post-indexed to fetch the period value for use of the 2A03 and MMC5 (and, since 0.5.0 beta 5, 5B as well). In these cases the table address is loaded only once during initialization, immediately after loading the speed dividers; however, if VRC6, FDS, or N163 is used (VRC7 is handled separately, but can be unified), then this occurs every time the NSF driver requests a new period/frequency value upon loading a note, e.g. during arpeggio sequences or the Qxy effect. The NSF driver does not set the region flag somewhere in the memory, so the region flag is lost after the INIT routine, and the NSF driver has no knowledge of the PAL table's address. This overrides the setting from the INIT routine sooner or later, forcing 2A03 channels to use the NTSC period values even when the PAL region is enforced.
Here is the code from init.s responsible for the differences between two regions: (I have added some comments of my own)

Code: Select all

    ...                                 ; y is equal to 9 (w/o FDS) or 11 (w/ FDS); assume no FDS below
    ; ...                               ; it represents the offset from beginning of music data
    cpx #$01                            ; PAL / NTSC flag
    beq @LoadPAL
.ifdef NTSC_PERIOD_TABLE                ; Load NTSC speed divider and frequency table
    lda (var_Temp_Pointer), y
    iny
    sta var_Tempo_Dec                   ; 60 * refresh rate, so 3600 = 0x0E10 by default
    lda (var_Temp_Pointer), y
    iny
    sta var_Tempo_Dec + 1               ; var_Tempo_Dec[0, 1] = *var_Temp_Pointer[9, 10]
    lda #<ft_periods_ntsc               ; (this address is patched upon NSF export if bankswitching is used)
    sta var_Note_Table
    lda #>ft_periods_ntsc
    sta var_Note_Table + 1
.ifdef USE_N163
    iny                                 ; as N163 NSFs contain the channel count *after* the speed dividers
    iny                                 ; it would be necessary to skip over the PAL divider
.endif
.endif
    jmp @LoadDone
@LoadPAL:
.ifdef PAL_PERIOD_TABLE                 ; Load PAL speed divider and frequency table
    iny                                 ; skip over the NTSC divider
    iny
    lda (var_Temp_Pointer), y
    iny
    sta var_Tempo_Dec                   ; 60 * refresh rate, so 3000 = 0x0BB8 by default
    lda (var_Temp_Pointer), y
    iny
    sta var_Tempo_Dec + 1               ; var_Tempo_Dec[0, 1] = *var_Temp_Pointer[11, 12]
    lda #<ft_periods_pal
    sta var_Note_Table
    lda #>ft_periods_pal                ; this becomes useless if VRC6, FDS, or N163 is used
    sta var_Note_Table + 1              ; otherwise var_Note_Table is only updated once here in INIT
.endif
@LoadDone:
.ifdef USE_N163                         ; Y might be used here again
    ; ...
And here is from player.s:

Code: Select all

ft_translate_freq:
    ; the same code appears in ft_translate_freq_only
    ; ...
.ifdef USE_VRC6
    jsr ft_load_vrc6_saw_table
.endif
.ifdef USE_FDS
    jsr ft_load_fds_table
.endif
.ifdef USE_N163
    jsr ft_load_n163_table
.endif
    ; ...
An example of the VRC6 chip, in player.s until version 0.4.2, and vrc6.s since version 0.4.6:

Code: Select all

ft_load_vrc6_saw_table:
    cpx #SAW_CHANNEL
    bne :+
    pha                        ; Load VRC6 sawtooth table
    lda #<ft_periods_sawtooth
    sta var_Note_Table
    lda #>ft_periods_sawtooth
    sta var_Note_Table + 1
    pla
    rts
:   pha                        ; Load 2A03 table
    lda #<ft_periods_ntsc      ; always NTSC region here, not checking the current region
    sta var_Note_Table         ; effectively rendering the INIT routine useless
    lda #>ft_periods_ntsc
    sta var_Note_Table + 1
    pla
    rts
For NSFs exported using the default refresh rate, this can be "fixed" by finding an instance of "10 0E B8 0B" in the NSF with a hex editor, then replacing it with "10 0E 10 0E". This makes it so that both regions use the NTSC speed divider, which will then make the NSF play "properly" at the slower refresh rate. It must again be said that FamiTracker has no responsibility of fixing this if it has decided since version 0.4.0 that PAL NSFs with expansion chips should not be supported.

In NSFPlay, the only difference between NTSC and Dendy is that they use different keys in in_yansf.ini to specify the CPU clock rate (NTSC_BASECYCLES / DENDY_BASECYCLES).

(FCEUX always disables the PAL flag while playing an NSF with expansion chips. In this case the NSF assumes NTSC settings, but uses the PAL refresh rate nonetheless if "PAL emulation" is enabled in the FCEUX menu.)
refactoring 0cc-famitracker

User avatar
Mojitone
Posts: 87
Joined: Tue May 12, 2015 10:15 pm

Re: Version 0.5 preview

Postby Mojitone » Tue Sep 22, 2015 10:16 am

In case these bugs aren't already reported:

Envelope commands in the 5B player conflict with each other, in that:
1° Using H00 and Hxy commands simultaneously in one channel and the one to its right, silences the former until a new Hxy command is added
2° Using H00 and Hxy commands simultaneously in one channel and the one to its left, silences the former from the second playback and so forth
Both situations also occur when two Hxy commands are used - but not at the same time
3° If two Ixy or Jxy commands are added, the new command overwrites the former even when added in a different channel
4° If two channels are using envelope mode and are interrupted by a note cut, playback is stopped completely on these two channels as long as envelope mode is still active.

Don't know if 3° is normal behavior from the YM chip but the rest are most definitely player-related bugs.
Attachments
5B player bug.ftm
each of the 5 songs demonstrate the bugs
(2.06 KiB) Downloaded 53 times
araa.ftm
(1.44 KiB) Downloaded 47 times
Formerly Macromaniac
Soundcloud

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Version 0.5 preview

Postby HertzDevil » Tue Sep 22, 2015 11:50 am

This seems to be what was going on: an Hxy command sets the wave shape immediately for all values of y, but only the rightmost channel using auto-octave (i.e. x is non-zero) has control over the AM period. Here is an example: (the instrument column has been omitted; assume blank instrument)

Code: Select all

     # : Square 1  : Square 2  : Square 3  $08 $0B Ctrl.
ROW 00 : C-3 . HCE : ... . ... : G-3 0 ...  1A  0E   1   SQ1 has control, AM period is now determined from SQ1
ROW 01 : ... . ... : ... . HCE : ... . ...  00  0E   2   SQ2 has control, AM period is now 0 since SQ2 has no note
ROW 02 : ... . ... : ... . H00 : ... . ...  1A  00   1   SQ2 releases control, SQ1 fades out at fast rate as shape is 0
ROW 03 : ... . ... : ... . ... : ... . HCE  11  0E   3   SQ3 has control, AM period from SQ3 is applied on SQ1
ROW 04 : ... . ... : ... . H9C : ... . ...  11  0C   3   SQ2 sets wave shape to C (sawtooth), octave has no effect
ROW 05 : ... . ... : ... . ... : ... . H00  00  00   2   SQ3 releases control, plays square tone as AM period is 0
ROW 06 : ... . ... : C-3 0 ... : ... . ...  D6  00   2   SQ1 and SQ2 fade out at rate determined by SQ2 and H9C above
ROW 07 : ... . ... : ... . H00 : ... . ...  1A  00   1   same has in row 02, SQ1 now has control
ROW 08 : ... . ... : ... . ... : ... . I07  1A  00   1   Ixy and Jxy have no memory, any active Hxy command masks them
ROW 09 : ... . H0E : ... . ... : ... . ...  1A  0E   -   no channel has control, AM period stays until next Jxx effect
In track #5, put a H0E on row 24, 5B Square 2; this returns control of the AM period to the first square channel, without changing the wave shape. I have not looked into the exported NSF yet, but it seems to have some inconsistent behaviour for the FTM you provided.

Note again that effects on the same row are processed from the left to the right except for Gxx which processes from right to left in each channel; so if two Hxy effects appear on the same row, the wave shape will be determined by the one to the right.

The 5B only has one register for each parameter. The Ixx and Jxx effects will apply to all channels.
refactoring 0cc-famitracker

Roflo
Posts: 292
Joined: Thu May 07, 2015 3:51 pm
Location: Germany
Contact:

Re: Version 0.5 preview

Postby Roflo » Fri Sep 25, 2015 6:27 pm

There are some missing <algorithm> includes for std::min/max in sinc.hpp and others. At least in VS 2015.