TriloTracker 0.7.2

Thanks for the updated version

Things just keep getting better... Just a few more updates and I have no reason not to get my ass into this fine program anymore. Ah well, if it works on a turbo R st with an external MB in it that is...
Luckily I got quite a big tutorial by John on video... I can't hear what he says, but the things he does on screen are more than half the thing I need

Great job and keep them updates coming...

It should be support of secondary mappers.. Dos2 (not on turbo r or panasonic 2+, they always selected internal memory as primary ) selects the biggest mapper as primary and most programs than only select pages in the primary mapper.

thx! i will test it soon...

@norakomi: Thanks for the offer.

I'll try to document as much as possible about the replayer to make it easier to use the replayer in your own code. Although using most of the existing replayers isn't to difficult eighter. But it does take a long time to get them working as in most cases you need to reverse engineer the code to really understand how it works beofre you can addapt it to your needs. I'll try to avoid that so it would be easier to add/remove functionality and include it in own projects.

As for the assembly format; I use sjasm and don't use any macro's. So it won't be too hard to addapt it to another compiler (I guess).

A 'how to add the replayer to your own sourcecode' example would be great.

Hello, I am Oscar Kenneth, from Kai Magazine (lilo, no-name, nuts...) we are developing new projects and the cartridges we use include SCC sound chip, so we are MOST interested on a replayer for the trilo-tracker; a .bin which can be controlled from basic, and compatible with turbo-basic (similar to moonblaster replayer, which also works with 64k ram msx computers, and is the replayer we used for No Name and Nuts).

I would be most honored to serve you as beta tester, and to use your replayer in our next projects.

Please let me know anything about it.

Keep up the good work!

Best regards:
Oscar.

Once released the ASM version, it should be possible to include it in nestor basic using its capability to handle segments.

I'll do that.
It shouldn't be too hard.

ATRAG will probably help with his invaluable experience (no pun intended ). Would be fun to work together again on code.

Great! In case you already want to check things out just look here: https://github.com/cornelisser/TriloTracker-Re-player
If you want you can make your own branch

I was having a look at the replayer code (looks very clean). I never programmed the SCC myself before, so I was wondering why you were checking if the new register value was different from the old register value; if it's not a hardware limitation, wouldn't it be more efficient to just write the new values instead of comparing them and doing a conditional jump?

talking about this part:

;--- Update changed SCC registers.
ld hl,oldregs
ld de,SCC_registers
ld bc,0x9880
ld a,3*5+1
loop:
ex af,af' ;'
ld a,(de)
cp (hl)
jr z,1f
ld (hl),a ; update old registers in ram
ld (bc),a ; update scc registers
1:
inc hl
inc de
inc bc
ex af,af' ;'
dec a
jr nz, loop
ret

vs:

;--- Update changed SCC registers.
ld hl,oldregs
ld de,SCC_registers
ld bc,0x9880
repeat 3*5+1
ld a,(de)
ld (hl),a ; update old registers in ram
ld (bc),a ; update scc registers
inc hl
inc de
inc c ; instead of 'inc bc' as C will never overflow
endrepeat
ret

(or an even more efficient LDI[R] based version, if you don't care about reading back the register values)

Whenever you set the frequency (period) register, the internal period counter resets to 0, extending the time taken to output the next value. The reason for this reset is all explainable and logical, however this causes a small glitch in the playback, which is unpleasant to the ears (a small click). Only changing the frequency when necessary avoids this as much as possible. Though, it’s more audible in emulators than on real hardware, and of course it can’t be avoided when doing a vibrato.