| |
Trap
Registered: Jul 2010
Posts: 223 |
Restoring vectors between parts in a trackmo
Hi,
So I'm fiddling with Spindle and I am at the point where I need to take a good look at how to make the shift from one part to another. Obviously I have to save the IRQ vectors FFFE/FFFF when I start my part after loading and restore the vectors again when I am done.
Now I wanted to hear if there is anything in particular I need to do other than that?
So the only thing I do when the part is complete is to wait for VSYNC and then restore the old vectors. One thing I have been thinking about is if I should in fact change the vectors in the last part of my existing IRQ. In my logic that would be a smoother/stable approach. I am not sure however and I hope that this thread will save me a headache or two when it comes to final linking.
Thanks.
/Trap |
|
... 1 post hidden. Click here to view all posts....
|
| |
lft
Registered: Jul 2007
Posts: 369 |
I prefer to do it in main context. SEI, update vector, call init routine of new effect, CLI. If there's a visual glitch, I add a delay before the SEI, waiting for a good spot (e.g. vblank). If there's a music hiccup, I add an extra call to the playroutine before or after the wait. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
once there was thread on how to change the place of the music jsr without hiccups, some guy was talking about X frames of moving the irq place, maybe a good idea to automate this in the framework :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats the old, glitchy way. DONT :=) it'll save you a few WTFs during debugging. (you hardly ever want a CLI anywhere unless doing recursive IRQs)
Oswald: thats not required often enough to put it into the framework... mostly you are calling the music in the border anyways. |
| |
Axis/Oxyron
Account closed
Registered: Apr 2007
Posts: 91 |
I mostly do the IRQ-switching the lazy way (in the mainloop with a VSYNC before). Sometimes this can cause trouble/glitches, e.g. if an IRQ occupies the rastertime around the VSYNC.
What Oswald is talking about, is the fact that not only missing or doubling a music playback-IRQ in the switch-frame can cause glitches, even changing the rasterline of the playback-IRQ can cause a glitch. Not as noticeable as the normal case, but hearable. The glitch gets bigger linearly with the amount of rasterlines your IRQ´s jump. So moving the IRQ-rasterline smoothly is sometimes the only way to get rid of it. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Also, refrain from stuffing all kind of functionality into a framework or other resident parts like a loader script when it could easily be added statically and still very comfortably with the use of some simple macros or at least includes. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
axis: "sometimes" is they important part there... unless its "nearly always", then putting it into a (static) framework is a waste of memory and should be linked when needed, like faker said. |
| |
Trap
Registered: Jul 2010
Posts: 223 |
Thank you guys. So, what I gather from all this is that I should probably redirect the last irq handler in my irq chain to the saved vectors. Makes sense to me. Not sure I fully grasp the timing issues around music mentioned here, but I guess I'll see it.
cheers
Trap |
| |
algorithm
Registered: May 2002
Posts: 705 |
if your music routine will be running at a fixed area, you can also set up a nmi running once per frame along with the required io values (d011,dd00,d018 etc) then no need to worry about syncing the audio. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i wouldnt worry about it unless you really notice a glitch... its seldom a problem :) |
| |
Trap
Registered: Jul 2010
Posts: 223 |
ok. thanks. |
| Previous - 1 | 2 - Next |
