| |
Starfox
Registered: Jul 2014
Posts: 42 |
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 |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
just take a tune that you like. |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Okay, so I guess the scene is still relaxed about using other people's tunes as long as credit is given =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
most people are, some will give you the shits and spawn drama. just like in 1986 =) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you can just record the sid register writes, if you have the memory. then find a good looping point :)
also there is a 1 rasterline player by hermit, and a lots of tunes made for it.
Visage - 1 Rasterline Cover
One Rasterline Tracker V0.9 |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
You can try to optimize main demo code for speed, and if you have some free memory, just unrolling some loops can give you sufficient time to play the music.
30 rasterlines isn't the world fastest player, but isn't very very bad after all... if you are coding on a PAL environment. |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Interesting idea oswald =), and I will look into that player. Btw, wouldn't I need to record more than once per frame. I mean arpeggio etc. isn't that some kind of loop in the music routine that changes notes or whatever over a predefined amount of time in the same frame?
Flavioweb:
Yes it's PAL =)
I have optimized it as much as I think I can within reason.
If I completely unroll it where it is only absolute adresses like: LDA ADDR - STA ADDR, it would take like 30kb with 0 cycles overhead.
I have another version using indexed adressing (LDA ADDR,X - STA ADDR,Y) taking 17kb with 390 cycles overhead for the entire runthrough.
And a more practical version taking a few kb with 676 cycles overhead (using the same indexing).
I was surprised I could even make it work using indexed because of the way the data has to be stored. It isn't just LDA ADDR,Y - STA ADDR,Y for X amount of bytes. The load is from sequential addresses, but the store isn't.
Also, the rastertime used to display the effect is almost dead, which is why I need every last cycle almost lol.
Maybe I can put a link to the routine. I'm sure there's more or better ways to optimize it. |
| |
Hate Bush
Registered: Jul 2002
Posts: 465 |
AFAIR, if a tune is singlespeed (called once per frame), you need to record the registers only once per frame. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
What you mean exactly with
Quote:Also, the rastertime used to display the effect is almost dead ?
Do you calculate fx data somewhere and display they somewhere else in mem? |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Randall: Ok, I will have to try to find out then =)
Flavioweb: Yeah, after the raster is done displaying the effect, the draw routine takes data from tables and places them in the display data area. Then next frame the display will show the changes.
There's pretty much 0 cycles left in the area where the effect is displayed because of the way it works, so I can only really optimize the draw routine and have a faster music routine =)
Here's a small snippet of one of the draw routines:
https://dl.dropboxusercontent.com/u/4130839/new%20draw%202.txt |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
...mmm...
But when "raster display data"... the code is working on something or just "waiting"? |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
It's doing something that can't really be changed and takes 52 cycles per line (STA/STX/STY) + 9 for "loop" + 2 wasted cycles on a nop to make it 63 cycles. I bet someone can already guess the overall theme of the effect by now.
I guess without the "loop" I would have 11 cycles free per line. Maybe that would be enough to play some notes?? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I suppose you need the cycles, both for "normal" play or "dumped" play, almost in a "consistent block", otherwise is useless to -gain- 10/11 cycles per line because you can't execute a "play" here to "dump" and play sounds, or execute code outside irqs...
And if you need to be in cycle-exact timing with raster beam, it's just impossible to "move" cycles from where they "are".
The only thing is to reduce cycles in the "work" part outside visualization area...
Maybe using some precalculated values or so... in the part of code that isn't just lda/sta'ing bytes around...
But you need 1890 cycles... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
1 raster tracker will do if 30 lines tracker almost cuts it. |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Flavioweb, Yeah, I did consider using the last cycles of 200+ rasterlines to do an LDA ADDR - STA ADDR to help the draw routine, but other problems pop up then, where the effect become kind of distorted because to make it look decent - I have to find the best compromise between the number of real rasterlines, and how many times they are duplicated to make the effect fill as much of the screen as possible. And yeah, I will have to figure out if I can use even more precalculated tables.
But the routine is nothing special, I just wanted to see if I could code a small demo again after all these years =)
Oswald, I checked that player out, and I also tried experimenting with reading the sid registers when the IO area is in ram mode, and then writing them back after switching back to normal mode. The music sounded a little weird and distorted, but it wasn't hard to recognize. I'm not sure it's worth the hassle though as it would take up too much ram, but it is an interesting idea =) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
yup, the timing & order of the sid writes is a sensitive thing. |
| |
Dr.j
Registered: Feb 2003
Posts: 277 |
@Starfox: sorry to interfere but i think the easy and
comfort way is to..simply find another sid from dozens
of HVSD sids that they aren't that big rasters consumers , i believe most of the tunes with Jch player and the latest most used players are okey to use or better to use hermit
1 raster player like Oswald already suggest |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Ahh, yeah probably screwed up the timing and order of writing the values back =/ I even made some music routines back in the day, but can't remember anything about it lol.
And I guess you are right Dr.J, but I will give just a little more time to see if I can make it work with this tune. And as you suggest, it should be possible to find something. I gotta admit, I only heard a few tunes in that hermit player. They sounded a bit like it was made for a 4k demo =) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I think order is more important than timing. But cant help you out with that. |
| |
4mat
Registered: May 2010
Posts: 66 |
Writing the sid registers in reverse order is "better" in a lot of cases. |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
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: 5094 |
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: 42 |
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
Registered: Oct 2004
Posts: 225 |
Cool to see you active here - Peter :D ... |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
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: 463 |
My 2 cents:
Use this doc as reference:
http://unusedino.de/ec64/technical/aay/c64/
may be useful...
=) |
| |
algorithm
Registered: May 2002
Posts: 705 |
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: 42 |
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. |
