The problem here is video memory. When QB was written, the best video card that was commonly available was the VGA, which contained 256 kilobytes of RAM and has some very strange & bizarre video mode configuration options. In consideration of its design, the fact that a flat 320x200 256-color mode is available is really quite a privilege. All other modes are planar, which means that the pixels are broken up into bits and each bit is stored in a different block of memory.
The problem with multiple on-card pages of [tt]SCREEN 13[/tt] is that writing to video memory is done through the use of device-mapped memory. Memory starting at segment &HA000 actually exists on the video card and not in system memory (the system memory there exists too, but you can't access it without going into protected mode, for the most part). The problem, though, is that 320x200x8-bit uses 64,000 bytes of memory, which is well over half the size of a segment. Therefore, only one page of video can be "exposed" at once, so to say. To expose a different page, you need to directly communicate with the video card using 'OUT' statements.
As for 640x480x8-bit, a single frame requires 307,200 bytes of memory, which is more than the amount of memory available on the VGA. That is to say, the mode 640x480x256-color does not *exist* on an actual VGA card, and therefore the VGA standard has no way to enter this mode. Since QB is written to the VGA standard, QB also has no access to such a mode.
Doing 640x480x8-bit with multiple pages is plain out of the question, without invoking higher APIs, newer standards, such as the VESA extensions to which DigitlDud referred. The problem is that while the VGA standard means that most video cards can do all VGA modes in exactly the same way, there was no standard proposed for higher modes until it was already too late and all the manufacturers had made their own standards. As a result, accessing SVGA modes is different for every single video card, pretty much.
Another twist in the works to consider is that the higher video modes -- those that use more than 65,536 bytes to store a frame -- cannot be fully "exposed" in the device-mapped memory at any one time. This means that to access the entire screen's worth of data, you have to access it one piece at a time, advancing the visible "page" forward to access parts farther down on the screen. It is a pain, and it is slow.
To be honest, for a long time I have been of the opinion that writing programs to make use of modern hardware in QuickBASIC is, for the most part, a waste of time. Modern languages and systems provide a far more suitable environment for this sort of experimentation (such as DirectX under Windows, which really isn't as bad as everyone says, as long as you know C++ and are familiar with the component object model ^_^). However, I wish you luck with your project.
