What is Arkos Tracker? › Forums › Arkos Tracker forum › Bug reports › [Not a bug] PLY_CFG_UseTranspositions + looping bug?
- This topic has 6 replies, 2 voices, and was last updated 4 years, 2 months ago by tulinmola.
-
AuthorPosts
-
September 21, 2020 at 11:14 am #30168tulinmolaParticipant
Hi there! First of all, thank you very very much for this software. It’s amazing!
I’ve been playing with exporting songs. My target is SDCC compiler. Following the guides, I ended compiling AKG player with this configuration:
compile_akg.asm
`
;What hardware? Uncomment the right one.
PLY_AKG_HARDWARE_CPC = 1
;PLY_AKG_HARDWARE_MSX = 1
;PLY_AKG_HARDWARE_SPECTRUM = 1
;PLY_AKG_HARDWARE_PENTAGON = 1; Comment/delete this line if not using sound effects.
PLY_AKG_MANAGE_SOUND_EFFECTS = 1; Configuration
PLY_CFG_ConfigurationIsPresent = 1
PLY_CFG_UseSpeedTracks = 1
; PLY_CFG_UseTranspositions = 1
PLY_CFG_UseEventTracks = 1
PLY_CFG_UseEffects = 1
PLY_CFG_UseInstrumentLoopTo = 1
PLY_CFG_NoSoftNoHard = 1
PLY_CFG_SoftOnly = 1
PLY_CFG_SoftOnly_ForcedSoftwarePeriod = 1
PLY_CFG_SoftOnly_SoftwareArpeggio = 1
PLY_CFG_SoftOnly_SoftwarePitch = 1
PLY_CFG_UseEffect_PitchDown = 1
PLY_CFG_UseEffect_SetVolume = 1include “PlayerAkg.asm”
`
The configuration there is a merge of all my song configurations. To adapt the player to work with all of them.
Then, I use the usual rasm/Disark commands to generate SDCC compatible file:
`
$ rasm compile_akg.asm -o tmp/akg -s -sl -sq
$ Disark tmp/akg.bin src/akg.s –symbolFile tmp/akg.sym –sourceProfile sdcc
`
I convert my songs to binary with something like:
`
$ SongToAkg song.aks song.akg -bin -adr 0x8000 -smd –exportPlayerConfig
`
And play it with:
`
#include <cpctelera.h>extern void PLY_AKG_INIT(void* songdata, u8 subSong) __z88dk_callee;
extern void PLY_AKG_PLAY();
extern const u8* song_akg;void main(void) {
cpct_disableFirmware();PLY_AKG_INIT(&song_akg, 0);
while (1) {
// play
PLY_AKG_PLAY();// wait until next frame
cpct_waitHalts(2);
cpct_waitVSYNC();
}
}
`
Notes:
– cpct_disableFirmware just overwrites interrupt handler address with EI, RET
– cpct_waitHalts waits for halts
– cpct_waitVSYNC… wel… waits for vsyncSo it simply calls AKG_PLAY 50 times per second and there is no other code that could cause side effects. And, in fact, it works great!
The issue comes when uncommenting
PLY_CFG_UseTranspositions = 1
line in player compilation configuration (and recompiling everything). Then, the first time it plays the song everything goes OK. But, when looping, the second time –after a couple of frames– music slows down a lot. But the code still executes 50 times per second.I’m not sure if it is a bug or I am doing something wrong. My inclination is towards the latter. But, what do you think?
And, of course, some of my songs uses transpositions… So keeping it uncommented is not a workaround, hehe.
It happens with all the songs I tested. So if you need the songs, the generated code, the project, or whatever else, just tell me and I will be happy to prepare it!
Thanks in advance!
Cheers,
TuloSeptember 21, 2020 at 11:18 am #30169TarghanKeymasterHi,
Just to be sure, before I delve any further, if you uncomment the Transpose flag, are you sure that:
– No transposition is actually present in the song, else some unexpected data will be present!
– You fully recompile your player.If this is OK, I’ll whether it’s a bug or not :).
September 21, 2020 at 11:20 am #30170TarghanKeymasterOk, re-reading the post better, I can see that you recompile the player BUT the songs have transpositions! This is a problem, because the player will not TRY to read the transposition bytes, and thus, will not skip them. So this WILL bug.
September 21, 2020 at 11:26 am #30171tulinmolaParticipantHello. Such a quick response!
I have songs with and without transpositions. The slow down after the fist play loop happens when playing both type of songs.
When having the player compiled without transpositions and playing a song with them, it plays. And it looks like it simply does not apply the transpositions. Maybe it’s bugging more things internally. But I couldn’t notice. As you can see, the test environment is as small as possible.
September 21, 2020 at 2:31 pm #30172tulinmolaParticipantAs expected, the issue was on my side. Even having so few lines of code… It was a problem with calling the play function without saving all needed registers and ensuring interrupts couldn’t occur while playing. And it is clearly described in the documentation!
void main(void) { cpct_disableFirmware(); // Init song __asm ld hl, #_songs_akg ld a, #0 call _PLY_AKG_INIT __endasm; ; loop forever while (1) { // do play __asm di ex af,af' exx ; Only a few registers needs to be saved as the system requires them. push af push bc push ix push iy call _PLY_AKG_PLAY; pop iy pop ix pop bc pop af ex af,af' exx ei __endasm; // wait until next frame cpct_waitHalts(2); cpct_waitVSYNC(); } }
At least I hope this post serves as a complementary guide for running on SDCC.
Sorry for being such a mess. Thank you very much Julien!
TuloSeptember 21, 2020 at 6:48 pm #30176TarghanKeymasterGlad it’s working now :). I’ll add one item in the FAQ about the auxiliary registers, just in case.
September 22, 2020 at 9:31 am #30194tulinmolaParticipantYes, I think it’ll be very valuable knowing which exact functions use alternate registers.
Thanks a lot!
Tulo -
AuthorPosts
- You must be logged in to reply to this topic.