Posted By
Murphy
on 2023-04-13
02:47:52
|  Re: Revision 2023
I tried to smile friendly. 
My goal is to communicate that here you are seeing the TED Vibes #2 musician recruitment list.
From the technical side, TED Vibes has three interesting features.
1. Since not all music can fit in the memory at the same time, I load the music, and a fifo cache algorithm is also built in. I have room for about 8 compressed music in the memory at the same time, and I always throw away the oldest one when I need space for a new one. I want to improve on this algo later, but it still loads 1-1 music very quickly. I recommend everyone to use Bitfire because it is fast and easy to work with. Thanks bsz and Bubis!
2. Since the program thread is reserved for loading and decompressing, all functions had to be implemented from IRQ. This was an interesting challenge because opening the border (the image is 160x256 pixels), updateing the scroll and playing 8x music requires 13 precisely placed IRQs.
So, there is no area on the screen where I have more than 39 free raster lines at once, and there are places where it is much less. If I were to wait longer than this in any IRQ, the next IRQ would not be able to be called, and the screen or the music would break up. (In the end, by the way, the 8x music was not included in the music disk, but the code was made for that).
Because of this, the code had to be added with a kind of multithread thinking, because there are parts of the code that consume much more CPU than 39 rasterlines. The animations, the scrolling of the tracklist (which is more than one frame), but even the music playback could conflict with the next IRQ.
For this reason, I placed cli in 4-5 places in the IRQs before the lower priority routines. So that, if necessary, the next IRQ can be called while the CPU has not yet completed the previous one. e.g. When playing a 4x music, the 4th player call is interrupted by the next IRQ at the top of the scroll for more than one raster line. There is also a situation where 3 IRQs overlap each other. It really just needed attention, but I don't think it would be a very common solution.
3. And the third is the lower, colored scroll, which is much trickier than it seems at first.
The problem is that if you switch $ff07 to 38-character mode, the border color appears in the two outermost character positions. This was not good for me because the border and background colors are different.
Therefore, the edge masking had to be manually emulated. So I scroll smoothly with $ff07, but the screen remains 40 characters wide, and the two outermost characters are always modified by the CPU so that the scroll movement is not visible at the edges.
|
