| Posted By
Csio
on 2009-07-04
06:47:12
|  $ff00/$ff01
Dear Gurus!
Can you help me a little bit?!?
So, if i have a c64 music with the following irq timing, what is the right numbers in plus4 ($ff00/01) ? I don't know what is the different of the frq between the 2 machine.
c64 intimusic source :
$dc04 $63
$dc05 $26
pjiz hep mi!
|
|
Posted By
Luca
on 2009-07-04
07:17:15
 | Re: $ff00/$ff01
That's the CIA, yes, it should work almost the same, apart of the internal clock ratio, right? I think TLC knows more...
|
|
Posted By
TLC
on 2009-07-04
08:56:24
| Re: $ff00/$ff01
He might...  Well. I don't really remember details (the CIA timers are much more versatile than the TED timer 1 ie. $FF00/$FF01) but from this point of view, the real difference comes from the clock frequency.
The PAL C64 runs at 17.734470 / 18. The PAL Plus/4 at 17.734470 / 20 (single clock, I mean). The C64 timer runs faster by a factor of 10/9. Consequently, if you want similar rate for an interrupt routine on the Plus/4, you have to adjust the number of clock cycles (written into the timer) by 9/10.
There seems to be an other difference: the CIA expects T-1 to be written to the reload register (where T is the number of cycles to be counted down in each "full" periods), whereas the TED timer 1 expects T.
So...
In the example below, T is $2663 + 1 = $2664 = 9828.
The new T for the TED is T * 9/10 = 9828 * 9 / 10 = 8845 = $228D. This is what you have to load into $FF00/$FF01.
...Another (practical) hint, for this particular case: as you can see, 9828 = 156 * 63 , ie. the timing of half a frame on a C64 ( 156 rows of 63 cycles each). This should be a timing of a "2x player" interrupt, frequently seen (as technical solution) in HVSC multispeed tune rips. In this case, you can simply drop the CIA timing idea and write a routine which is executed by raster interrupts twice a frame. ...Or copy the original idea, and call the player by TED timer interrupts, by a timing of 156 * 57 = 8892 = $22BC cycles. (Yes, the frame rate of the C64 and the Plus/4 don't match exactly).
|
|
Posted By
Csio
on 2009-07-04
13:10:40
| Re: $ff00/$ff01
thaks for your quick answers!
this is big help for me and the scene too
|
|
Posted By
Csio
on 2009-07-04
13:37:52
| Re: $ff00/$ff01
BUT the problem is that this multi speed music uses digi-sequenzes too, and if i pack it to a simply irq with double jsr, then the digidrum has noise, thats why i should use the $ff00/01 timing irq. thanks the values, BUT whats with the SID CLOCK in SID CARD? What frq uses this? TED? SID? cause if its uses frq of TED, then this values falses...or no?
i don't understand it....bah....
|
|
Posted By
TLC
on 2009-07-04
15:41:49
| Re: $ff00/$ff01
Hmmm, this is very strange. For such stuff to work (ie. both the player and the digi irq off from one single CIA interrupt) the player would have to overwrite the CIA timers continuously. This is suspicious... noone would try that, unless there's a good reason, or if there's something else...
Are you sure that you're calling the player _twice_ in a frame, but not from the same single raster interrupt? It's essential for multispeed tunes to have the calls spread equally around a frame (ie. one call, for example, at line 0, and another at line 156... the particular line numbers don't matter, only that there should always be 156 lines between the calls).
The SID is clocked from the single clock of the Plus/4 (ie. 17.734470MHz / 20, = 886.7235kHz ). Yeah, consequently, the frequency table (contained by original C64 tune players) is false for the Plus/4 SID card... well, not exactly false, but all C64 tunes play some halfnotes lower than intended (and the ADSR is also slower somewhat, for exactly the same reason). This is pretty well detailed in the docs of SIDwinder V01.23. Some tunes may sound weird, but that's pretty rare (I'd say the great majority of C64 tunes play pretty well even despite the different clocking, with some examples playing more or less weird). I'd say there's one critical point -- the player itself should be "relocated", so that it updates the SID registers at $FD40 just by itself (rewrite all references of $D4xx to $FD4x), and definitely not using some external loop that copies data from $D400 after each player calls... that usually results in nasty things, as some players update SID registers more than once during a single call (all of which only the very last one gets copied into the SID registers at $FD40, if an external loop is used).
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
