| |
Raistlin
Registered: Mar 2007
Posts: 548 |
Goattracker .. can someone add a feature for me?
I couldn't figure out how to get GT to compile .. and wondered if somebody could help?
Basically, what I'd like is to be able to have tunes output from GT that write to -both- ghost registers -and- D4xx. Eg.:-
STA $d418
STA zpghost + $18
for whatever ZP address we specify.
I believe that GT will allow either of these options.. but not both at the same time.
Being a crazy fool - I want BOTH :-)
I don't suppose anyone can help...?
I could do this in the CPP .. but I have no idea what configuration of MinGW/GCC/... i need in order for GT to compile for me :'( (yeah, I'm a Windows user.. one that's used to Visual Studio / C++ etc.............). |
|
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Doesn't GT already supports delayed writes to ZP that have to be then copied to the actual SID regs after calling the play address? |
| |
Mixer
Registered: Apr 2008
Posts: 421 |
Like iAN said. You can enable the buffered writes in GT2 when exporting the tune, then just copy from the zp or the buffer mem to sid. GT2 Documentation covers this. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
I sense an XY problem.
Raitlin: What do you want to achieve? And why is using either option and copying memory to SID yourself not an option? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
I think he wants to know the written values for visualization purposes :) But indeed, using ghostregs and copying them to SID in your IRQ is the solution :) |
| |
Raistlin
Registered: Mar 2007
Posts: 548 |
That's what I already do (with a reverse copy to D4xx from D418 to D400)... however... I'm reliably informed by our musicians that it doesn't sound the same...
For a 1x tune, I can keep everyone happy:-
- one copy of the tune at $1000-2fff that plays music as usual, writing to D4xx;
- another copy at $3000-4fff that writes to ghostregs .. I use this version for the visualiser.
Expensive in memory and CPU to do this way as you'll appreciate .. and 6x tunes will never work ;-)
So... my hopeful solution is that GT2 could write to both ghostregs and D4xx and, hopefully, the music will still sound correct.
Trust me, ask your artists - they can hear the difference. The timing of the writes is important .. I suspect also that repeatedly writing into D4xx unchanged/unused values that you're copying from ghost registers could cause problems. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
If the music is written so to require very specific timing of writes (ie. unsafe ADSR settings) it can be trouble to figure out a "good" write order and timing for the ghostregs.
However, in that case also adding anything extra to the player would disturb the timing too. |
| |
Raistlin
Registered: Mar 2007
Posts: 548 |
Cadaver's right .. but I still think this is the best solution (other than doubling CPU and memory use). Adding 3 cycles to each D4xx write is going to be much better than completely changing the timing by copying ghost regs around. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
I thought it's mostly the SID register write order that must be preserved to ensure that there are no distortions to the sound.
That is, a regular SID tune should tolerate something like calling the player, which would write to memory, then immediately copying the values to SID registers. (And regular SID players don't need stable raster routines. :D)
Things like writing to the same register twice (with different values) and rather precise hard-restart timings or similar should be observed, probably.
So yeah, at a certain point having the player itself write to SID registers and memory may be unavoidable. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
What i did for a similar thing (Bullets over Vegas).... just find out the order of writes (VICE watchpoints are really useful for this) and then do the copying of the ghostregs in the same order.
copymethod_sidwizard:
// copy registers in same order as sidwizard does (DAM tunes)
.for (var i = 0; i < 3; i++) {
lda sid_ghostbytes_adr+5+(i*7)
sta $d400+5+(i*7)
lda sid_ghostbytes_adr+6+(i*7)
sta $d400+6+(i*7)
lda sid_ghostbytes_adr+3+(i*7)
sta $d400+3+(i*7)
lda sid_ghostbytes_adr+2+(i*7)
sta $d400+2+(i*7)
lda sid_ghostbytes_adr+0+(i*7)
sta $d400+0+(i*7)
lda sid_ghostbytes_adr+1+(i*7)
sta $d400+1+(i*7)
lda sid_ghostbytes_adr+4+(i*7)
sta $d400+4+(i*7)
}
lda sid_ghostbytes_adr+$17
sta $d400+$17
lda sid_ghostbytes_adr+$18
sta $d400+$18
lda sid_ghostbytes_adr+$16
sta $d400+$16
lda sid_ghostbytes_adr+$15
sta $d400+$15
jmp play_continue
copymethod_sidtracker:
// copy registers in same order as sidtracker does (topshelf tunes)
.for (var i = 0; i < 3; i++) {
lda sid_ghostbytes_adr+4+(i*7)
sta $d400+4+(i*7)
lda sid_ghostbytes_adr+5+(i*7)
sta $d400+5+(i*7)
lda sid_ghostbytes_adr+6+(i*7)
sta $d400+6+(i*7)
lda sid_ghostbytes_adr+2+(i*7)
sta $d400+2+(i*7)
lda sid_ghostbytes_adr+3+(i*7)
sta $d400+3+(i*7)
lda sid_ghostbytes_adr+0+(i*7)
sta $d400+0+(i*7)
lda sid_ghostbytes_adr+1+(i*7)
sta $d400+1+(i*7)
}
lda sid_ghostbytes_adr+$15
sta $d400+$15
lda sid_ghostbytes_adr+$16
sta $d400+$16
lda sid_ghostbytes_adr+$17
sta $d400+$17
lda sid_ghostbytes_adr+$18
sta $d400+$18
jmp play_continue
copymethod_gt:
// copy registers in reverse order, like what goattracker does
ldx #$18
!l1:
lda sid_ghostbytes_adr,x
sta $d400,x
dex
bpl !l1-
play_continue:
(apparently xiny (gt tunes) already used buffered writes =P) |
| |
Raistlin
Registered: Mar 2007
Posts: 548 |
Ahhh. You can check Stinsen's latest tune on CSDB, however... Jazz i Jacuzzin (where I do the nasty double-load/call thing I described earlier).
I now see though that the D4xx writes happen in this order:-
$16,$17,$18
$05,$02,$03,$00,$01,$04 //; channel 0
$0c,$09,$0a,$07,$08,$0b //; channel 1
$13,$10,$11,$0e,$0f,$12 //; channel 2
I've just reordered my ghost-to-sid copy to this .. and Stinsen tells me it sounds perfect. So I guess that's all I needed :-)
Ian: your reverse-copy is what I started with .. so maybe that's for a different GT mode or something..? Stinsen didn't like it that way, regardless ;-)
Thanks everyone. |
... 1 post hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
