Twilighte wrote:
I can only imagine you are referring to SID files which are basically the music + code ripped out of C64 games and stuck in a file.
There are several formats that include the original binary code.
One of which is for the AY sound chip and includes Z80 code. There are trackers that generate portable data if you have a player.
I find it difficult to understand the usefulness of this idea, though i do agree we have a real problem on portability of music files on legacy machines.
The original idea (posted a couple years ago) was that it would give greater control over the music from within the player and still remain portable.
For example, you could also have the main game code interact with the player in a way that would allow smooth transitions from a section of a song to another. You could set a value in one of the song player memory locations that tells it to transition from one repeating section to another without abrupt change in the music.
So, you could implement a while loop in the song data itself that kept repeating a section until a flag told it to continue or to jump to a different section. The flag the main program modifies could even tell the player what section to transition to. And the transitions could be seamless.
You'll also notice my comment that I thought it would be to slow after I looked it over again and I dropped the idea.
I thought the interrupt would take too long but maybe that was just me not wanting to start over. I think the goal is good but it could be simpler to implement.
I am also slightly miffed why it is neccesary to modify the existing interrupt config, since the existing irq setup should be fine for most apps.
speed can easily be changed from 100hz to 50hz, and to process some other code during the irq is a simple 3 byte patch to page2.
Wow, "miffed". My first Oric program *ever* and you are "miffed". You seem to be taking it rather personal.
Some songs are written on NTSC machines and they play too slow on a PAL machine. If you have a timer you just alter the timer and don't have to do any math in the player to correct the wait time problem. And guess what the only timer example I found in the forum does? Exactly what I did because I was following the example... unless I screwed up which is entirely possible but I believe someone replied in that thread they had the same problem when they used the example.
Also, Do you really require 100% cpu to process the sound?
Sorry, i'm confused James.. or perhaps its my age!
Moohahahaha... all your cpu belong to us!
But seriously, I understand your confusion and it's that way for a very selfish reason. First of all, the code I posted had nothing to do with the original concept other than it's a music player of sorts, though a rather limited one. It was a direct port of a Z80 program, which btw, did exactly the same thing (100% cpu). The original Z80 code didn't even use an interrupt at all, it polled the hardware looking for the TOF signal.
I'm working on an AY sound chip upgrade for the Radio Shack MC-10. I was already going to port the Z80 code to the 6803 as a demo/test for the hardware and I figured, what the hell, let's see what it looks like on other CPUs... so I ported it to the 6809 (CoCo Speech & Sound Pak) and the 6502 (Oric). It was a cpu vs cpu comparison I was interested in. And yes, the 6803 and 6809 code uses 100% of the CPU cycles even though it doesn't need to. It was do that or fix the Aquarius Z80 code to make it work right.
However, I'm not sure it's worth the effort to fix other than to demonstrate the proper way to do it. The player is very limited and I don't even know what tracker the data came from so I don't even know how to create a different song for it. If someone figures that out, let me know. I have a hunch the data was ripped from a game.
I'd be happy to fix it if people are actually interested... but I kinda figured once I had time I'd pick a popular tracker and use what I learned to make a player for that tracker format.