Sort of ... but I think it's easier to do the disk access as usual, but move your real-time game code (updating graphics, taking care of input) to a timer interrupt.
Edit: then you effectively have your main loop doing IO and such, while your game loop is a co-routine in modern parlance. The game loop can write a global variable which the main code takes as a hint to start loading file data.
- maintain a, say, ring buffer :) for I/O commands (operation, file handle, offset, buffer address, callback address)
- add requests to the buffer from the game loop
- timer wakes up periodically, splits requests into palatable chunks, completes a portion of the requested work, when it reaches the end it either sets a flag on the request to signal its completion and/or jumps to its callback address
- game loop can periodically check and empty the request buffer or set the requests to self-destruct on completion
That does not really work since the only IO was the BIOS-provided one that was 1. synchronous and 2. really slow. If you tried to do that you'd just get insanely bad pauses.
Presumably and perhaps more compatibly can also call the DOS function with interrupts disabled but with an interrupt line active (e.g. a timer) and handle it.
I'm writing a game and it would be nice to load resources for the next level in the background.