The first way how Casey wanted to implement it was to have rectangle around camera and to move memory around inside rectangle when player moves.
You can realize that you don't need to move any memory for that. Simply move your origin in this rectangle. So let's say you ground rectangle has size w/h and is fully cached, and player is at (x,y) position. Then player decides move to right for 10 units. Instead of doing RectangleCopy from (10,0)+(w-10,h) to (0,0)+(w-10,h) and filling up (w-10,0)+(10,h) rectangle with new info you can simply assume that new origin of ground rectangle starts at (10,0) position and fill up only (0,0)+(10,h) rectangle with info from (x+w-10,y) position in world.
This gives some advantage that updating buffer is very simple - just two relatively small rectangle blits (only with new info). And blitting buffer to screen is up to 4 blits. Also looking up what rectangle to cache is much simpler calculation than to loop over all 256 GroundBuffers.
But it has some disadvantages - you won't handle teleportation Casey mentioned in ep.86 over large distances. You could solve that by using two ground buffers which are cached separately before and after telportation.
This mechanism is used as part of clipmaps - mechanism to render 3D terrain.
Here are some more information with nice diagrams:
https://a248.e.akamai.net/f/862/5.../Source/Clipmaps/doc/Clipmaps.pdf (page 4 "Updating Strategy")
https://www.cs.virginia.edu/~gfx/...Data/papers/Texturing/Clipmap.pdf (4 "Updating Clipmaps")
And some illustrations:
