Just wanted to join the discussion regarding the compiling of a driver. I do concur the OS4 compile of AHI is slightly messed up. In 2007 I was porting a 68K multi-module player to AHI. I did a lot of the testing and programing on my OS4 machine. I was programming the replayer routine in the "proper" way by using an AHI interrupt. On my AmigaOne I noticed a bug where the sound kept stuttering caused by a high speed tempo. I determined that it was due to a fault caused by using an Emu10K AKA SoundBlaster Live5.1 PCI card (which I had) in my AmigaOne, where the driver has to cut down the number of hardware interrupts generated by the card requesting sound data, because the VIA chip holds up the bus. A buffer overflow had occured. Because the driver was being sent data at a faster rate than it could actually send to the card.

I had this idea to modify the driver so that at a certain speed, where overflow would occur, it would double the buffer, so to speak, and then call two AHI interrupts in place of one to compensate and fill it so the problem would not occur. And this is where it ends.

I found the Emu10K source, that Davy Wentzler compiled for OS4, would not compile out of the box from a standrd SDK install. It was made to compile with an earlier SDK version, IIRC, and expected other things I did not have in my public machine. Eventually with his help, I did manage to compile a driver. My reward? It crashed. Simply crashed. I spent some more time with it but eventually gave up. I connsidered sending Davy my code changes but I wouldn't be able to test them directly. I had to agree with Davy in the end, that compiling an AHI driver is a bitch! :-D

@Massi

The AHI player interrupt most likely uses a soft interrupt and I would use the term "timer" loosely. Sure, it all comes down to timing, but all that particular interrupt does is call a requested routine or player interrupt that can start sounds or modify fequency or volume of an existing sound. The net result being that AHI uses this information to fill a sound buffer for that particular slice of time. And the speed of the interrput thus corresponds to how much of the buffer is filled on each call. So not necessarily a realtime interupt.

If you understand the workings of ProTracker or any other tracker, where an interupt is called in realtime, you can understnnd the AHI player interrupt. For example a PT player routine at 50 FPS, corresponding to 125 BPM, can play a note every six interrupts with effects in between. I forget the math but I know it is six. Almost did my head in once dealing with it. :-)

So, with this in mind, involving timer.device wouldn't help AHI. Well, not in this particular case anyway. AHI could even call the interrupt several times a second, since the purpose is to fulfill a sound buffer. So AHI could do that, calling the intrerrupt repeatedly, until the buffer was filled and ready for send off. Send that to the sound card for processing via the drvier. And then render the next buffer while the other is playing.. :-)

@Massi

Okay, so you certainly know how to program an AHI module player. :-)

I just wanted to touch on Tocatta again. So you found the AHI driver depends on another library, but this is nornal. AHI is just used as an interface or transport layer for audio programs. So the AHI drivers pass the real work down to the actual sound card API. It means the card can be supported and with less fuss to produce an AHI driver.

Now your intention was to produce a driver that world work in emulation. Knowing that 68K call backs and UAE opcodes don't work under PPC emulation, do the actual Tocatta drivers work, when that card is emulated? Is there a built in UAE driver that works instead?

@MAssi

Yes, so in this case you don' t see how the hardware is touched.

You don't as it's cleanly hidden away. All you can assume is that it is mapped somewhere in memory in Zorro space. And that Expansion API can be used to write to it.

I don't know if using an MMU program to catch writes on the real thing will tell you what memory is being hit so you can decipher it. Or you could study a disassembly of the API in Monan or ReSource or something similar.

My personal guess is that Toccata emulation is supposed to work from within OS3.x emulated only.

Have you tried it yet? ;-) Well, either way, the emulation has to catch access to memory. So even if PPC mode is on I think it still needs to interpret things like custom chip access. So then, an emulated Toccata sound card hanging off the Zorro bus, should still exist in the virtual memory. And so, should still work. IMO. :-)

As to UAE sound driver, I think that might not work, if it uses UAE callbacks ignored under PPC.

Toccata is hardware, it cannot be specific to a certain software version.

Surely Toccata works in OS4, that's the only reason why Toccata emulation exists, because OS4 only supports real existing hardware.

@Massi

Not yet and you?

LOL. :-) No I haven't. I failed to get PPC emulation working on my iBook G4 and haven't tried on my PC which is lacking space.

I am puzzled, wasn' t Toccata specific for M68K AmigaOS?

Well yes, since it is also an actual Amiga sound card.

How his words should be interpreted? That OS4 emulated can run Toccata or?

I haven't read it from the the orginal context, but from the above it looks like Toni is being asked what is wrong with emulating a Tocatta card under normal circumstances in UAE, as if it was pointless, going by the response. Even though in his answer he fails to point out that not all prograns, such as OctaMED, are AHI aware.

But, in light of the answer, I think it should be interpreted as you have. That the Tocatta emulation exists so that an OS like OS4, that kills off the 68K and thus any special UAE opcodes and hooks, can actually play sounds.

Does a native AHI driver for OS4 exist?

I looked and didn't see a driver. Anything on the OS4 CD? Given the OS4 AHI drivers are based on the sane sources I suspect not fully if one at all.