It gets much simpler when you realise that in the original PC there's no "driver" in the way but bits of hardware are wired directly to various processor buses.
This is sixteen-bit assembly, so you have the famous 640kb of RAM available to the user and a 64k bit of RAM beyond that (see "0xa000" in the program). The graphics hardware is continuously rendering frames out of there at 320x200, one pixel per byte, using the default system palette.
The rendering is rather like a pixel shader. There is a big for loop over all the pixels, and at each point it computes a pixel value. First it decides which frame number it is on (stored in BP register I think), then calls an "effect" for that pixel.
It then jumps three pixels. This gives that nice "dissolve" transition between effects.
Keyboard controller is wired directly to the bus, so you can read the keyboard with a single instruction.
A MIDI controller is wired directly to address 0x330 (not standard equipment, back in the day this required a Roland card or SoundBlaster 32?), so you can just write MIDI to that.
There is a system timer interrupt configured for the music. The graphics appear to run continously, I can't see a link to the timer or vertical sync in the graphics code, that appears to just run continuously.
(author here)
The "three pixel jump" is just for the looks, and it smoothes the animation for more calculation heavy effects (f.e. raycast tunnel). The transition effect is not bound to this, it is rather using the "noise" (as you described it) from the coordinate calculation to offset the time (desribed in the writeup). The graphic output is linked to the timer via register BP, which is modified in the interrupt routine.
This is sixteen-bit assembly, so you have the famous 640kb of RAM available to the user and a 64k bit of RAM beyond that (see "0xa000" in the program). The graphics hardware is continuously rendering frames out of there at 320x200, one pixel per byte, using the default system palette.
The rendering is rather like a pixel shader. There is a big for loop over all the pixels, and at each point it computes a pixel value. First it decides which frame number it is on (stored in BP register I think), then calls an "effect" for that pixel.
It then jumps three pixels. This gives that nice "dissolve" transition between effects.
Keyboard controller is wired directly to the bus, so you can read the keyboard with a single instruction.
A MIDI controller is wired directly to address 0x330 (not standard equipment, back in the day this required a Roland card or SoundBlaster 32?), so you can just write MIDI to that.
There is a system timer interrupt configured for the music. The graphics appear to run continously, I can't see a link to the timer or vertical sync in the graphics code, that appears to just run continuously.