| |
Trifox
Account closed
Registered: Mar 2006
Posts: 108 |
*stupid* ASM Sid Player Example ?
Hi i just started coding on the good old c64 and i am wondering how to play music in an assembler executable,
on some tutorials i found that the music usually is located at $1000 but if i load a sid file to that location and jump
jsr $1009
nothing happens, the c64 exits my programm, i think it is clear, a sid file is not an assembler programm to jump in, but how do i now play a music file ?!?!?!?
thanks for any reply ... |
|
... 19 posts hidden. Click here to view all posts....
|
| |
Trifox
Account closed
Registered: Mar 2006
Posts: 108 |
'nkay, what is about interesting sid registers ?!?! any meaningful to display as bars ?!?!?! |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
You plan to route all SID writes through the RAM underneath IO area? (no other way to read SID registers, unless you happen to know where/how the player in question stores its own internal data)
Just be aware that depending on the SID register write order, you may break how the player was intended to sound like when you then write the data from your register buffer to SID.
Unless you have a SuperCPU and implement a 6510 emulator for the playroutine to also capture the SID register write order :)
What to display.. don't know, maybe some equalizer bars based on frequency and detecting gate on/off changes. |
| |
dalezy
Registered: Apr 2002
Posts: 476 |
trifox, do you happen to have been nicknamed brötchen during the 90s?
(sorry for this totally off-topic interrupt =) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
cadaver,
- last 2 sid regs are readable
- if you change sid writes to jsr's, you can know the order too. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hmm, that's clever. Though you'd still need the emulator (if possible to implement in sufficient speed) to get exact timing :) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
<smart idea to read registers and still keep timing>
how about calling the tune twice,
once with the tune writing below IO in the ramspace ($01=#$30), and then call it again ($01=#$35/#$37) so it will write the registers into IO.
The 'only' thing you'd have to do is backup all changing memory adresses in which the tune keeps where it's playing right now, and restore them when playing the tune the 2nd time.
</smart> |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yeah it should not even be *terribly* expensive on rastertime, I guess the state doesn't in most cases exceed 100 bytes. Save+restore (unrolled) = lda,sta,lda,sta * 100 = 1600 cycles = about 27 lines. Plus calling the player twice :) |
| |
Trifox
Account closed
Registered: Mar 2006
Posts: 108 |
Quote: trifox, do you happen to have been nicknamed brötchen during the 90s?
(sorry for this totally off-topic interrupt =)
ehrm yes: I AM BRÖTCHEN, not the Brötchen, simply BRÖTCHEN, hehe, it is an old relikt from Mailbox Modem Times ... |
| |
WVL
Registered: Mar 2002
Posts: 902 |
another thing you can do is have the tune in memory twice, say once at $1000, and once at $2000..
saves the trouble of changing the state back, except maybe some 0page adresses.. ofcourse it does cost a bit more memory, and you have to relocate the tune.. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
cadaver, I will play you $10000 if you can tell the difference between a music played "normally", and using stored register data for each frame. AFAIK modern players do sid writes like first doing the "calculations" then write sid regs at "one go", so if its 8 or 44 cycles between writes is highly negligable.
thats it about the importance of timinig.
but there's still a solution, which does not need the stupid emulation, to preserve timing:
each JSR-ed routine may read (and stop when entered) a cia timer, and compensate for the time the routine uses up. (and restart the timer when exiting the routine.)
then replaying the tune with the stored data and timing is a breeze. |
| Previous - 1 | 2 | 3 - Next |
