Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
OK. Hear me out. Here's a way to get cheap one-shot PCM without any recode of the engine. It only needs two new features:
1.) PCM envelopes on 2a0x/MMC5 instruments
For 2a0x instruments a PCM macro could be drawn or imported via hex copy/paste. (8-bit PCM values obviously downsampled to 7-bit values.)
MMC5 instruments could easily accept 8-bit values without conversion. An additional MMC5 PCM tracker channel would be unnecessary this way as well; unless one is added for tidiness and extra room.
(There are many other potential uses for this envelope, but for brevity sake they will not be discussed currently.)
2.) Engine playloop lag multiplier command (Lxx)
xx = Multiplier of playloop lag subroutine
Delay the engine by (XX)x(lag subroutine clocks)
=============
Take both of these features into consideration with a high refresh rate such as 480Hz...
Blank (or combined) instruments with PCM envelopes in the 2a0x or MMC5 would play the envelope at 480Hz minus engine overhead; tweaking of refresh rate would be possible to properly "tune" the sample.
With the Lxx (engine lag) command, we could effectively change the "sample-rate" making the frequency lower. Would be good for crisp 7/8-bit drum/snare samples or countless other applications; at the cost of changing the speed globally of all other envelopes.
...
There you have it: Potential PCM without recoding the engine from scratch.
1. I'm sorry but I fail to see the use of such a feature, all it would do is to create different kind of buzzing sounds at around the frequency of the refresh rate. Even at higher refresh rates there wouldn't be much control for making actual tones.
If you think there actually is a way this can be useful then I'd really appreciate an example of that.
2. If I understand you correctly, would this be used to lower the refresh rate? For example temporarily going from 120Hz to 60Hz?
--
If PCM audio is what you want, then the easiest way would probably be to use the NSF v2 IRQ features, but one issue is that there are no players that supports it (at least not that I'm aware of). And even then, there already are excellent tools for using PCM in NSF v1.
1.) A lot of my music has already used buzzy Zxx ($4011) commands anyway; given the limits of 60Hz and without macro writes (since the feature currently doesn't exist.) (And people seem to be mystified about how acceptable it is.) There is an example of Action 52 "make your selection now" using Zxx and a higher refresh rate on this forum. (Attached.) Now it does use hacked tempo and an impossible refresh rate of 7500Hz, but that doesn't mean other lower sample-rated samples are out of the question.
2.) Yes. Exactly. The purpose being to basically have "variable refresh rate."
=======
Regarding NSF2, FamiTracker is the perfect forum and platform to launch it out of the mud. kevtris has basically designed the majority of its body but due to nobody fully agreeing on certain things such as: Hardware acceptable multi-track track/author/year/ripper/etc. documentation and its compression algorithm and IRQ register mapping location that doesn't conflict with potential 2a03 TEST register coding. Discussion of NSF2 should be definitely discussed in another post and ironed out among us; namely rainwarrior and yourself and pushed forward. kevtris would probably smile.
This is the newest topic I could find searching the board about nsf2 -- it's not mentioned very often lately! I have an old VS board that I modifed to play nsfs. I just came across some songs that use nonstandard engine speeds, so I substituted a 82c54 into the PPU socket. It works fine, but I guess it would be more um...realistic to use a 6522 or 6840 rather than an Intel-style part. Anyway it would be nice if, for nsf2, emulation of a real timer chip is used instead of something custom. If only a simple rate generator is needed, I guess 74592s could be used as well.
I don't know a lot about the nsf format, so I can't figure out why the last nsf "bank" is able to be switched -- having it switchable increases the difficulty of hardware implementation, since the player-wrapper can be switched out from under you unless there's a special initializer bank that puts the wrapper code in RAM. The vectors still have to be checked in all banks that are switched into that last nsf bank. Is it to better support multi-song files?
So, now I see that the nsf2 is going to add a timer and writeable INT vector, I think it could be a good idea to map the timer registers into fff0-fff3, and reserve ff00 on down for the wrapper code. This would be helpful if implementing the address decoding with 74-series chips. I noticed that the powerpak nsf player has a timer mapped into 5ff0-5ff2, but doesn't that conflict with MMC5?
To the previous poster in this thread: Have you tried playing that tune with a powerpak ? I'm still working on adding bankswitching to my VS board, so I can't play that one.
The last bank is switchable likely because some memory mappers allowed it, and indeed it requires the vectors to be present in all pages that's supposed to be located there. Famitracker however has the last bank fixed to the last page, to remain compatible with the TNS-HFC NSF playback carts. The powerpak solves it in a different way, probably by decoding the vector addresses.
Regarding NSF v2, there is not much talk about it since there are no players or tools. One reason is that the current NSF specification is good enough, I guess.
