[aaronbwebber]

Can anyone describe at a high level for a complete noob how this kind of thing works? Someone who is not going to be able to read a bunch of ASM and interpret it? I'm guessing that it is something along the lines of:

- the graphics "driver" reads values out of certain registers (AL and AH?) at a set interrupt (maybe every X clock cycles?) and writes one pixel to the screen of whatever color those registers had in them

- by writing values into those registers and aligning the number of operations the program does with the frequency of the interrupts, you can get animation?

Even achieving any sort of flow control so you can switch between the effects is mind-boggling to me.

[pjc50]

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.

[HellMood]

(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.

[hannob]

> - the graphics "driver" reads values out of certain registers (AL and AH?) at a set interrupt (maybe every X clock cycles?) and writes one pixel to the screen of whatever color those registers had in them

It's actually much simpler than that. After you set the right graphics mode (which for most simple dos demos is usually mode 13h, 256 color on 320x200) then there's an area of the memory that you can write to and it will show up as a pixel.

The "flow control" is usually just that you run your effect n times in these simple demos. Which means it will run faster on a faster CPU, but you usually wouldn't bother implement any form of timing in 256 byte.