Music and VBL while reading files

[remz]

Hello coders,

I would be happy to get help on the following topic:
I'd like my game to be able to animate sprites (or other things) and continue to play music while accessing the file system.

At the moment, I am coding in C using ACE https://github.com/AmigaPorts/ACE
When my game needs to read a file from disk, it "enables the OS" by putting dmacon and intena and the 7 interrupt vectors back to normal, which then makes the Open(), Read(), etc., function properly, and once reading is done, it grabs the interrupt vectors, which means the OS is "disabled".

While it works OK, it doesn't allow animating or music to continue while the OS is reading files. (Currently if I try it, the music will simply stutter and repeat the same note until the OS is disabled once again, so the game' interrupts are re-activated).

Is there a clean, easy, os-friendly way of doing this?
Thank you very much, as always!
RemV

[a/b]

Yeah, if you install your interrupt vectors, the ones you actually use and don't touch the rest, in an os-friendly way (exec's AddIntServer()) and don't mess with intena and dmacon too much. OS is using interrupts to multii-task so if that's a problem call Forbid() instead of poking intena (you can still load/save).

[hooverphonique]

I think others have had success with just enabling level 2 or 6 only (can't remember which) to load from HD without re-enabling the whole system.

@a/b: using dos will re-enable multitasking, so if you're relying on Forbid, it may not work as you expect (i.e. your Forbin is undone).

[a/b]

Yeah, I'm aware that some functions break Forbit() as well as Disable(), I didn't mean it can be used as a one-and-done, just apply it when needed (e.g. after done loading).

I'd guess it also depends on OS version, what device are you loading from, etc. Safest way is to use OS, but yeah you might get away with less in some/most/all(?) cases.

[phx]

I noticed that ACE uses my ptplayer for music, but I can only guarantee its function when you have taken over the system.
I know I'm repeating myself, but there are only two solutions:

1. Write your game 100% OS-friendly without hacking the hardware directly (this basically excludes my ptplayer, and probably also ACE), as a/b indicated in his first reply.
2. Take over the system, kill the OS, do never return to it until reboot. This is usually the best approach for games and demos, and gives you all options, but restricts you to floppy disk trackloaders, as you cannot write drivers for all existing mass storage devices.

Everything else feels hackish and you will always find a configuration which causes trouble.

[Thomas Richter]

Originally Posted by remz

Is there a clean, easy, os-friendly way of doing this?
RemV

The clean way of doing this to use the exec interrupt handler chain where you can install a "struct Interrupt" yourself which will be called, for example, on a VBI. This then cooperates nicely with the remaining Os. Do not fiddle in the 68K autovector table.

[remz]

Thank you for your inputs:
After much fiddling, I was able to make it work with a mixed approach:
ACE overtakes the whole system 7 levels while in 'game mode', and when going back into 'OS mode' to allow file reading, it restores everything back to the OS.
The modification I've added is by registering my vertb int server using the struct Interrupt you mentioned:
struct Interrupt rvInt3Server;
... fill up the struct ...
AddIntServer(INTB_VERTB, &rvInt3Server);
I found this link with good explanation too: https://wiki.amigaos.net/wiki/Exec_Interrupts
So when the OS system is enabled, my int server continues to be triggered, making the music continue to play, and when the OS system is disabled (for precise interrupt and dma control during gameplay), then the normal int3 handler is taking care of updating the music.
The result works perfectly, from Ram, to HD, to floppy, on OS 1.2 up to 3.1, with any Amiga models I managed to try in WinUAE.