Classic Mac OS supported full screen applications since the beginning. I'm not sure if Apple allowed it or whatever in their very strict interface guidelines, but from a programming perspective you just have to turn off the menu bar and take the entire screen as the GrafPort.
I think the recommended route is to make a window that fills the screen, rather than taking the entire screen as a GrafPort. If you want the code to be portable, you can make your fullscreen window, draw to an offscreen GWorld, and CopyBits to the window. There’s a whole song and dance that you do in order to make sure that this is fast.
Later on, there was DrawSprocket. It solved the problem of figuring out how to do “portable” and “fast” at the same time, and let you use features like page flipping, if the hardware supported it (saving you the call to CopyBits).
You can think of HyperCard as a fullscreen app, and that’s not wrong. Look at it another way, and it’s displaying a 512x342 pixel window. On B&W compact Macs, that’s the size of the display. If you ran Hypercard on a later 640x480 color Mac, you could see the border of the window and move it around.
Later versions of HyperCard let you choose the size of the window. Various extensions would let you use a borderless window for the stack, and put a big black window behind it covering the rest of the screen.
HyperCard did some particularly weird things to draw to the screen quickly on older machines. If you try dragging a HyperCard stack window around, you'll notice that its horizontal position is quantized to 8-pixel increments, probably to accelerate drawing on low-bit-depth displays. :)
Yes, that’s something you’ll need to do if you want to stay on the fast path :-)
The Motorola 68000 does not have a barrel shifter. You want to shift by 4 bits? That’s four cycles, buddy! Avoiding shifts keeps you on the fast path for CopyBits().
