What did the cassette bootloader in 8 Bit Ataris do?

Question

...or for that matter, what didn't it do, so that you'd use the "bootloader/main program" separation instead of loading everything at once.

Normally, when loading games or any non-BASIC software from tapes, you'd start the computer holding START+OPTION - it disabled BASIC ROM and started it in 'boot' mode. A characteristic deep beep sounded, you'd press 'play' on the cassette recorder, then Return on the keyboard. Some 8-10 seconds of high-pitched constant lead-in, then six (very rarely any other number) records of data from the tape, another deep beep, and another lead-in. At that point often the screen would change, to show some countdown, ads, welcome, or whatever extras the bootloader contained. The game proper would begin loading, and start when it finished loading.

I never understood the waste: obviously the bootloader was a program, and often quite fancy one. Why couldn't the whole game be implemented as a bootloader? Why waste time on the two start-up procedures, two lead-ins, and a piece of software that was usually overwritten by the game when it finished loading? What were the shortcomings/restrictions of the bootloader so that it was universally implemented in such a minimal form, instead of just being the full application/game?

EDIT: Just to clarify:

• about the most common, generic bootloader didn't print anything or affect the screen in any way.
• you couldn't just fast forward past the bootloader and start from the game proper. It wouldn't load, generating a 'BOOT ERROR' message instead.

Answer 1

De Re Atari describes the cassette boot protocol, which helps understand why bootloaders were (nearly) always used. In cassette boot mode, the operating system reads a record from the tape recorder and loads the following information:

• byte 2 gives the number of records to load (up to 256 records, each containing 128 bytes, so 32 KB in theory)
• bytes 3 and 4 give the address at which the tape must be loaded
• bytes 5 and 6 give the address of the initialisation routine which must be called once the given number of records have been loaded and the first-stage initialisation has completed
• the remaining bytes contain code which is called (JSR) once the given number of records have been loaded

The operating system expects the code called at this point to return success or failure; if it indicates success, the initialisation routine pointed to by bytes 5 and 6 is called (JSR again), and when that returns, control is transferred to DOSVEC using a plain JMP, so DOSVEC must be set up too. Once the tape had been loaded, RESET restarts the second-stage initialisation.

So the cassette boot protocol expects a three-stage boot in any case. Since the cassette boot loads the tape linearly, it makes sense to use a tape-specific boot loader: the vast majority of programs would have a non-linear memory layout, so dumping all of memory to tape would just result in even longer load times than strictly necessary. Having a boot program allows various records to be loaded from tape into the appropriate location, and it allows RESET to be handled without reloading everything from tape. As pointed out by bjb, it also allows requirements to be checked before spending lots of time loading the tape: a program requiring 48 KB can thus abort on a 16 KB system early on. Obviously for anything larger than 32 KB it's required anyway...