[actionfromafar]

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.

[rzzzt]

The timer interrupt could also do the loading:

- 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

[turol]

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.

[actionfromafar]

Yeah either way, my hunch was just I wouldn’t want to drop frames in the game, so it’s nice have a timer on the graphics.