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?
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.(Continue reading)
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:(Continue reading)
RSS Feed