I can think of two ways this has been done:
- Brute force: just draw the scene
- Mode-X and panning registers. Draw the bit to be scrolled into view and adjust the panning registers to scroll the scene. You would need to redraw the top display area each frame, but that is less work to do than drawing the main play area. You wouldn't need to redraw the bottom area as there was a register in the hardware that would cause the video DACs to read from address 0 at a given scan line (so the bottom area would be at address 0 in video ram and the top would start after the bottom area)*.
I'd probably go with 1) as there's not much graphically going on, there may be some self-generated code to blit and clip images at the edges. One possible technique that a collegue of mine was working on back then was self-writing sprites, that is, the sprite data wasn't data, it was code. This meant there were no transparency checks and the data read of the blit was effectively free (this was on a 386 where each instruction was read and then decoded so instead of read code->read data->write data it was just read code->write data). It worked amazingly well - we got lots of huge sprites on multiple parallax layers running at 25fps+.
But we are talking about Romero here and there's probably a bit of exageration going on about the techniques.
- I did actually do this in my first major DOS game, and there's a bug in some hardware whereby the address reset happened a scanline too soon so you'd have a half-height pixel between the two sections.