| |
Mace
Registered: May 2002
Posts: 1799 |
PAL music on NTSC
What would be a good way to have a PAL 1-speed SID play at proper speed on an NTSC machine, when a raster-IRQ is already running?
|
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: What would be a good way to have a PAL 1-speed SID play at proper speed on an NTSC machine, when a raster-IRQ is already running?
Use a timer... If you use a timer on CIA2 it'll even be NMI and thus run on a different vector. \o/
If it's a timing critical raster effect, then run the timer on CIA1 and thus have it generate IRQ then simply arbiter and prioritize the incoming IRQs properly in your service routine. I.e. allow a lag of the timer if the raster IRQ needs time, otherwise execute it immediately.
It's all quite simple actually. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:If it's a timing critical raster effect, then run the timer on CIA1 and thus have it generate IRQ then simply arbiter and prioritize the incoming IRQs properly in your service routine. I.e. allow a lag of the timer if the raster IRQ needs time, otherwise execute it immediately.
I understand the principle, I think... but how is it done?
How do you determine if the IRQ needs time?
And what do you mean with 'timing critical': that it's very critical in scanline location (like siderborder stuff) or just that it's using a pretty lot of rastertime? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
do your raster stuff using timers and nmi, and use a timer irq for the lower priority stuff. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:If it's a timing critical raster effect, then run the timer on CIA1 and thus have it generate IRQ then simply arbiter and prioritize the incoming IRQs properly in your service routine. I.e. allow a lag of the timer if the raster IRQ needs time, otherwise execute it immediately.
I understand the principle, I think... but how is it done?
How do you determine if the IRQ needs time?
And what do you mean with 'timing critical': that it's very critical in scanline location (like siderborder stuff) or just that it's using a pretty lot of rastertime?
Like this: If you place the music call on a CIA2 timer and thus uses NMI the NMI will always have priority over your IRQ. That means that if your IRQ is doing some timing critical cool raster FX the NMI will interrupt it and execute the music routine and then resume the IRQ. This will effectively render your cool raster FX quite uncool.
However if you can all some slack in the music playback then simply run the music on a CIA1 timer. Then in your interrupt service routine you simply check what kind of interrupt you have and process them accordingly:
1) check $d019 for raster IRQ, if we have one then acknowledge it and do the cool raster fx, then RTI.
2) check $dc0d for timer IRQ, if we have one then acknowledge it and call the music routine, then RTI.
Since the interrupt line will be kept high until all IRQs have been acknowledged the raster IRQ will re-enter the interrupt service routine immediately if a timer IRQ have occurred meanwhile.
Now, since the scheme above FIRST checks for raster THEN checks for timer the raster will have priority and might stall the call to the music routine by the amount of time the raster routine takes to process. If this is a sideborder code opening the border for 200 lines it will most certainly stall the call to the music routine too much. But if it's a simple code like updating some sprite pointers, moving some data etc. the possible stall will be non audible.
The downside with the above is of course that if you're processing the music and during that time you get a raster IRQ then it won't be processed until the music is finished, hence directly when you have acknowledged the timer in the beginning of the IRQ then also allow more IRQs to interrupt using a simple CLI call. This will allow the possible raster interrupts to interrupt the music routine, again something that might be audible but mostly ok.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: do your raster stuff using timers and nmi, and use a timer irq for the lower priority stuff.
Yup, that is another way of doing it if you don't want to use the $d012 service of course. I've used both methods in my productions and it depends on the situation which one to choose.
F.e. not so timing critical raster code colliding with timing critical raster code is perfect to use NMI for the latter and IRQ for the first. (like sprite multiplexing vs. opening the top/bottom borders, used in Chilipower f.e.) |
| |
Mace
Registered: May 2002
Posts: 1799 |
My 'thing' is an intro which calls several raster IRQs on various places on the screen. There's 'space' in between.
Also, in the current version I have a 4-speed music, but I need to change that to a 1-speed music.
So it seems there is enough time for playing music, just not ALL the time. There are some rasters and some less $d012-dependant stuff.
I'll try to figure out how to implement your suggestions.
It sure sounds interesting :-)
Thanks so far. |
