Version 0.5 preview - Page 20 - FamiTracker

# FamiTracker

FamiTracker Support Forums

Skip to content

## Version 0.5 preview

General discussion about tracking, help and support.
Post Reply

- Print view

295 posts

- Page 20 of 30
  - Jump to page:
- Previous
- 1
- …
- 18
- 19
- 20
- 21
- 22
- …
- 30
- Next

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

### Re: Version 0.5 preview

- Quote

Post by 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
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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.
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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.
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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.)
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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
Top

HertzDevil
  Posts: 475
  Joined: Thu Apr 23, 2015 7:39 pm
  Location: Hong Kong SAR
  Contact:
  Contact HertzDevil
  Website Facebook Twitter Skype
  YouTube

### Re: Version 0.5 preview

- Quote

Post by 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
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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 129 times
  araa.ftm
    (1.44 KiB) Downloaded 118 times

Formerly Macromaniac
Soundcloud
Top

HertzDevil
  Posts: 475
  Joined: Thu Apr 23, 2015 7:39 pm
  Location: Hong Kong SAR
  Contact:
  Contact HertzDevil
  Website Facebook Twitter Skype
  YouTube

### Re: Version 0.5 preview

- Quote

Post by 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
Top

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

### Re: Version 0.5 preview

- Quote

Post by 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.
Top

Display posts from previous:
Sort by

Post Reply

- Print view

295 posts

- Page 20 of 30
  - Jump to page:
- Previous
- 1
- …
- 18
- 19
- 20
- 21
- 22
- …
- 30
- Next

Return to “General Talk”

Jump to

- Rules
- Wiki
- FamiTracker
- General Talk
- Bug Reports
- Feature Requests
- Source and development
- Music
- Original Music
- Cover Music
- Other
- Site Issues & Suggestions