| |
Starfox
Registered: Jul 2014
Posts: 31 |
Coding a small demo. Rules about music?
Hello,
I'm coding a small demo, after having coded the last one 27 years ago (lol), and while coding it I have used an older GREAT placeholder tune. Now, I could keep using that tune in the release as I got in contact with the composer, and he said I could use it, no problem.
But the music routine is taking a bit too much rastertime (peaks at around 30 lines), and that's just too much - since my effect takes up almost all available rastertime, and because of that I have to cut back the size of the effect, which is a bummer.
I know there are more optimized routines out there today that take much less rastertime, but I am concerned that since it is of newer date, that it would not be acceptable to just use one of those tunes?
I also got the idea that maybe I could transplant the music data from the placeholder tune into a newer more optimized player, but it seems like a bit of a challenge lol.
Anyone have any ideas as to what I could do?
Peter |
|
... 17 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
I think order is more important than timing. But cant help you out with that. |
| |
4mat
Registered: May 2010
Posts: 63 |
Writing the sid registers in reverse order is "better" in a lot of cases. |
| |
Starfox
Registered: Jul 2014
Posts: 31 |
Tried reverse order and it now sounds identical. Now I just need to calculate if there's enough memory left (probably not) but I have an idea I want to try where it starts off by recording voice 1, and while recording it scans for patterns so it only stores each different pattern, and it updates an index table where it keeps track of which pattern just appeared. then dump that voice out, and do it again with the next voice, and the next.
Then I should have kind of patterns for each voice, and just make a small player that plays pattern X for each voice.
Should work in theory lol
Also, I'm already noticing (by dumping the sid data to screen) that some values never change, that might be space saved |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
cool idea, looks like you're still at it, despite 27 years :) I'd dump though the data from emulator and use a higher level language for re-tracking it.
a simple but fast lzw (packer in c64 terms) would do aswell I guess, but better to handle channel data individually :) |
| |
Starfox
Registered: Jul 2014
Posts: 31 |
Yes, it's fun to code a bit of c64 again =)
yeah, good idea. I hope I'll be able to do something like that. There's bound to be a lot of data. |
| |
DRAX
Account closed
Registered: Oct 2004
Posts: 224 |
Cool to see you active here - Peter :D ... |
| |
Starfox
Registered: Jul 2014
Posts: 31 |
Hey Drax, long time since back then =) I think it was at some party in Odense I last met you. I was there with some guys from Mechanix. They had to go home early, but I decided to stay and wait for Liteace (Kenneth Bedsted) who was to arrive one day after they had left. I wanted to get some sleep in the meantime, but it was impossible with the noise levels there, so I spent a lot of time looking like a zombie trying to get some sleep under the table. Then I think you recognized me through a window into the next room or something (I was most likely looking like a zombie) =)
I hope you are doing great, and I can see that you are also still in the c64 scene =)
Another friend got me interested in fiddling with the c64 again after he showed me some cross development tools. First I just wanted to see if I could remember how to do a simple scrolltext, then I got an idea for the routine I'm working on. It took a lot of time refreshing how to do things lol.
Edit: It seems the music routine is repeating or letting pass - 6 frames between new data to the sid. Dunno if this is normal, but it means less data if it holds true throughout the entire tune =)
From looking at the c64 memory map at sta.c64.org it seems that $d41b and $d41c are not used in the actual playing of music, so I should be able to skip dumping and writing to those two addresses right? <-- edit: duuh! why don't I just try it and see what happens. It's getting too late to code =) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
My 2 cents:
Use this doc as reference:
http://unusedino.de/ec64/technical/aay/c64/
may be useful...
=) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Even though the update of notes may be once per 6 frames (usually the default speed for most SID tunes) the updating of waveform data, filter, pulse duty and pitch slides can occur every frame.
To dump rhe registers back to sid, you would essentially need to update around 24 registers (And write them in a specific order) This would require around 1200 bytes per second!
Some type of delta based preprocessing and compression for fast decode can be used (although this will eat up some of your precious cpu time) I would probably estimate that you can shrink the 1200 to less than 300 bytes or so on average. |
| |
Starfox
Registered: Jul 2014
Posts: 31 |
Thanks for the link Flavioweb =)
Algorithm: Yeah there will more than likely be some space issues, but I'll try and see what happens. At least, it's fun =)
I played the tune for 10 minutes to make sure I got all all the patterns. The voices have 852 different patterns in total (v1:179 v2:118 v3:555), so thats 852 * 7 bytes just for those. I haven't done the filter+volume yet.
The real spacehog will probably be the 4 tracks that determine which patterns to play each frame x_X
Edit: Let's say we have 100 different sid patterns for voice 1. Would it be wrong to assume that once we notice that 100 different patterns have been played for voice 1 - that voice 1 will now loop?
It will keep playing the tune, harvesting new patterns from voice 1. And since I already know how many different patterns occur in each voice, it will stop playing once it has harvested the last pattern. The music routine in the meantime has played a mix of all the patterns to produce the voice 1 sound output, so all the patterns are included in that timeframe. I don't know - somehow it seems logical to me that that must also be the time where the track for voice 1 loops, but I'm not sure. |
| Previous - 1 | 2 | 3 - Next |
