*TAPE wrote: ↑Mon Mar 29, 2021 9:53 pm
NC....
very impressive.
I would like to invoke Terry Thomas and say, "
My dear chap, you're a delightful swine!"
It would appear you had this idea about 1 year before me!
I came up with this very idea about December last year.
As a youth I was always fiddling with making sound, stealing music from games, but was never good enough at assembler to do what you've done here.
You've run up against the memory issue.
One thing I was considering was looping.
Music is set at a given tempo. And for that tempo you know that notes will have a specific minimum length.... in which case you know you will need to repeat the note switching pattern
n times, rather than 1 byte per switch.
...or, pardon my ignorance, is this what you've done?
The other thing I was considering was compressing mute.
You've got 0xFF as mute, what if the following number was a repeat number.
i.e. Silence lasts for
n beats.
Saves many bytes on pauses..... although on faster music would end up costing more in space.
Thanks. I hope this inspires you to continue rather than deters. I make no claim over discovering this technique (simondotm and 0xC0DE showed the way with Bad Apple) and Nick Pelling was doing something similar over 30 years ago... my original inspiration, but didn’t have the knowledge to take it further at the time
Recently I discovered
http://ssb22.user.srcf.net/mwrhome/midi-beeper.html which renewed my interest. However, the limitations soon become apparent when using the OS Sound and Envelope commands.
With regards to memory limitations it really hasn’t been an issue to date. My original technique used the approach you describe where I tried to store repeat notes as a single entry plus duration. However, I ended up wasting bytes on most notes as I needed to store them as a word and most had a value that would fit in a single byte. For precise timing I needed to hook into the interval timer, and that requires fast data access at every increment. I soon realized Exomizer can compress this data far better than I can. For example, the Out Run track before manipulation and compression is over 260kb in size.
0xFF refers to the value that needs to be supplied to the ULA’s counter to represent silence (simondotm has details about it here:
https://github.com/simondotm/vgm2electron). See FE06 and FE07 in the EUG for details. I actually turn off sound with FE07 when this byte occurs in the stream.
Looping is implemented for some tracks (check the BBC Music disc on my GitHub for examples), but I’ve still work to do on tracks that loop part way through rather than at the beginning.
I’m just finishing up the complete set of Out Run tracks which I’ll post to my GitHub repository (
https://github.com/NegativeCharge/Releases) in the next few days. Some of these are over 8 minutes long and they’re getting towards the memory limit (having to borrow some screen memory) - however, when I get some time I’ll investigate SWRAM - I have one of RamTop’s excellent ElkSD64’s so just need to work out how to detect and utilise the extra memory.
I’d love to take this further given the time - I’m throwing away so many sound channels from tracks to get this to sound reasonable on the Elk. With the Beeb and it’s three channels plus noise I see the potential for 12 concurrent notes plus percussion. However, that one’s for another day
Don’t be deterred by lack of asm experience - I’ve only touched 8086 assembler about 20 years ago, and am having fun writing 6502 assembler badly. You’ll find most of what you need in these very forums, and if not there are very helpful people here ready to offer assistance.
