Utilization des Auto-Ints (92+)

[Lionel Debroux]

Edit: Just looked into PolySnd a bit. I can't figure out how it's using AUTO_INT_5. There's a move.w #$700,d0, trap #1 at the beginning... so how exactly does this work?

In my local copy of PolySnd 2.47.2, which is in a pristine state according to the files' date stamps, both occurrences of move.w #$700,d0; trap #1 in the sources/statique folder are commented out ? Otherwise, yeah, it shouldn't work.

Looking at it, there's a bug in GetHardware: the andi.l immediate operand should be E00000. And GetHardware should have been inlined.

[utz]

D'oh! Of course I had an outdated version of PolySnd.

Anyway, I now have a working 4-channel sound routine using auto-ints 5 and 6. Which is still quite a stretch from what I have in mind, but for now I'm glad I at least managed to figure the interrupt thing, so thanks a ton for your help, Lionel.

Only one problem remains: After running the program, I can't turn off the calc (ie it'll turn itself on again after a fraction of a second). I had this problem even before implementing the interrupts, so it should be unrelated to that. In my opinion(tm) I'm resetting everything to system defaults on exit (ie restoring original int mask, clean usr stack, pull link port lines high, disable direct sound). Any ideas what I might be missing here?

[Lionel Debroux]

What I did in my aforementioned TV Noise demo didn't yield such behaviour after exiting the program, so try doing the same

[utz]

Problem solved, was resetting the wrong bits in ($60000E). Interesting side note, seems the 92+ does not like writes to bit 2 (and possibly 3) of the aforementioned port. I've yet to see something about that in J89hw.txt

[Lionel Debroux]

OSLinkReset does that and more.

[utz]

Ok, so how exactly do I use that function? I tried jsr tios::OSLinkReset, but that failed (unresolved symbol).

[Lionel Debroux]

First of all, you need to include the appropriate os.h header file. It's in $TIGCC/include/asm for A68k or $TIGCC/include/s for GNU as.
The ROM_CALL method is up to you, with different speed / size compatibility tradeoffs: direct ROM_CALLs, optimized ROM_CALLs, kernel-style ROM_CALLs, F-Line ROM_CALLs, etc. See the documentation.

[utz]

Ok, so I gather ROM_CALL OSLinkReset will do a "direct" ROM_CALL? Aside from it being slow (which doesn't matter much at this point), are there any other drawbacks of doing it this way? Sorry, I don't really understand the documentation on this, at least as far as asm usage is concerned.

Anyway, got 4 channel sample playback working. Needs a bit more testing before I can release it though.

[Lionel Debroux]

Direct ROM_CALLs always work, but they're one of the largest ways to perform ROM_CALLs, because the jump table's address is always reloaded, no Common Subexpression Elimination occurs. Slowness doesn't matter here indeed, the ROM_CALL itself contains much more code than that. And F-Line ROM_CALLs are slower than direct ROM_CALLs, and work only on AMS 2.04+ (unless one enables the internal F-Line emulator), but they're the smallest way to perform ROM_CALLs: only 2 bytes, no relocation.

[nature]

Bonjour, c’est un peu difficile de lire le post en français et les commentaires en anglais. Nous on veut tout simplement trouver des solutions à ces problèmes et on perd du temps à traduire ces commentaires pour mieux comprendre.