Yeah, I don't really know what I mean. I have a good understanding of
exactly how programmable sound generators work (in that I've written
cycle-perfect emulators of them) but I've no musical talent whatsoever
so how you build actual music from that is something that I have an
extremely nebulous grasp of.
The real foundation of my question is that I'm busy trying to figure
out exactly what I need to support to allow audio playback to work
with my 3d library stuff. At the minute it's possible for a user to
supply extra code for the interrupt handler, I was just wondering how
much room I needed to leave in the interrupt handler to allow someone
who understands what they're doing to lever in a music player.
I guess I'll allow a small number of bytes and stop being so
protective of the 32 kb I was saving for faster multiplication code.
So one could chuck the ProTracker or E-Tracker tunes and player into
the spare 32 kb and then just page and branch in the IRQ handler. The
IRQ handler is going to have to be sandwiched onto each and every one
of the already-cramped video pages, so keeping it minimal is a priority.
Work-in-progress documentation of the library here, by the way: http://members.allegro.cc/ThomasHarte/temp/Lib3d.pdf
(~112 kb). It's all about the interface you'd use if you were going
to use my library. I don't think it's the place for documentation of
the internals or my various bits of work on tweaking and optimising;
that stuff will continue to be the subject matter for SAM Revival for
now. Please anyone feel free to comment or criticise.
On 7 Oct 2008, at 23:13, Andrew Collier wrote:
On 7 Oct 2008, at 22:42, Thomas Harte wrote:
Roughly how much code (in kilobytes) is the part of an average end-
of-display interrupt driven music player that actually resides in
the interrupt handler?
Hi,
That depends what you mean...
The code you would write in an interrupt handler would need to:
1. page in the music player (if necessary)
2. call the player routine (often at 32774)
3. page back the previous memory state (if you changed it in step 1)
and is just a few bytes.
The music player itself is much larger, and depends on which music
system you use. A compiled E-Tracker tune is a few k depending on
its size - all of that needs to be paged in when you use it. The
first 1202 bytes of this are a player code routine which is the same
for all tunes, the rest is data specific to each tune.
A compiled ProTracker tune is larger (partly because the effects are
more complicated, but mostly because I was concentrating on
execution speed, rather than code size, when I wrote the compiler).
The player routine is about 12k including some tables of sine waves
and things; the data for a particular tune is usually somewhere
between 8k and 16k.
Both systems expect the whole music player code to be played once
per frame. There isn't support for, say, filling up a buffer of a
few seconds worth of music, and just playing from the buffer at
interrupt time. (That said, if you have a particular need for this,
it might be relatively easy to hack up the ProTracker player to
support doing that. Bear in mind it is decade-old code, though...)
Cheers,
Andrew
--
--- Andrew Collier ----
---- http://www.intensity.org.uk/ ---
--
