I'm loving it ! Still few things I don't understand. Mainly 64kHz source. You say you are realigning the IRQ every frame .. is it enough to prevent IRQ/DLI conflict ? Well since it's once per 8 lines, I guess it is, but I want to know more.
Also the demo is stereo pokey right ? I mean you need 2 channels for IRQ, and even if you share synth with RMT, the music is clearly more then 2 channels .. right ?
Thanks for making everything public !
Thanks for your questions and your nice comment on YouTube!
Let me address each of your questions inline:
> You say you are realigning the IRQ every frame .. is it enough to prevent IRQ/DLI conflict ? Well since it's once per 8 lines, I guess it is
Ok, so I demonstrated two different approaches to propagate the generated sample buffer to the sample register.
1. HCM based screens
This is the approach that's by far the easiest to implement as DLIs and IRQs never run at the same time.
24 updates are written into the sample register from the HCM screen kernel (that's a good thing about the small & generic HCM screen kernel - it leaves you a little time to perform tiny tasks in it in a predictable way).
15 updates are handled via IRQ. (that's covering the areas outside of the DLIST)
There's no conflict therefore.
The once-per-frame realignment happens via setting the timer freq to 0 at the beginning of the screen kernel (when we don't need the IRQs anyways).
Then we kick off our IRQs at the end of the screen kernel and it gets kicked off in a re-initialized / realigned state since our last IRQ has long ran out.
To keep the IRQ from drifting away constantly during a single frame there's a timer pattern in the code that's being followed by the IRQ code to even out the inherently unalignable 64KHz timer vs scanline difference.
That - in theory - makes the timer aligned to the same position where it started each 7th character line (if I remember my calculations correctly ).
This one's doing IRQ+DLI based sample updates.
Now this approach (like I also say in the player example code) can be a hit and miss situation.
DLI and IRQ conflicts and order issues must be expected unless you come up with some clever stuff or you're simply lucky.
I think I was lucky as it worked out nicely with my display list and the order in which IRQs and DLIs kick in on that screen turned out to be consistent.
I'm re-aligning the IRQs in DLI code and I also modify the IRQ code from DLI code so that IRQs take the samples from the correct position in the correct buffer.
Again, this could have been a lot more complex depending on the screen layout / DLIST / DMA setup.
If you choose to go down this route, you'll have to design a system that works for your screen.
You can start out from mine and debug the DLI & IRQ code to see what's happening and when.
There are more possible approaches than these two, but I didn't have more screens in REHARDEN
(something to explore / flesh out: 24 DLI based updates instead of screen kernel based ones, then 15 IRQ based updates outside of the DLIST area)
> Also the demo is stereo pokey right ? I mean you need 2 channels for IRQ
No, it's made for stock 64K XL/XE.
It's using channel #4 only for both the IRQ and the sample register.
> the music is clearly more then 2 channels .. right ?
Correct. You have all 4 POKEY channels in RMT and HARDBASS will only consume Channel #4 when RMT is not using it. (when channel #4 volume = 0 in RMT -OR- when channel #2 volume = 0 when channel #4 serves as a filter for channel #2)
It's completely dynamic and automatic.
For example, the bass sound I'm using most consists of a highest pitch (pitch=0) RMT instrument noise sound for a frame followed by pulse-width modulated HARDBASS bass. Along with a fully RMT drum instrument. All in Channel #4, mixed automatically.
Feel free to ask if something doesn't make complete sense
Edited by Sandor / HARD, Wed Dec 13, 2017 11:30 AM.