Exercise 3: Tracing 260 Pushes Without Any Pops — Possible Solution
====================================================================

SETUP
------------------------------
SP starts at $FF (255, decimal). Page 1 spans exactly 256 bytes,
$0100-$01FF. Per the 6502's real push behavior, each push writes to
the current SP's address (within page 1) and THEN decrements SP by
one.

THE FIRST 256 PUSHES FILL THE ENTIRE PAGE
------------------------------
Push 1:   writes to $01FF, SP becomes $FE
Push 2:   writes to $01FE, SP becomes $FD
  ...
Push 256: writes to $0100, SP becomes... $FF - 1 wrapped from $00,
          which in 8-bit arithmetic wraps back around to $FF.

At this point, all 256 bytes of page 1 hold data from the first 256
pushes, and SP is back at $FF — exactly where it started.

PUSHES 257 THROUGH 260 SILENTLY OVERWRITE THE OLDEST DATA
------------------------------
Push 257: writes to $01FF again — SILENTLY OVERWRITING the value
          Push 1 originally stored there. SP becomes $FE.
Push 258: overwrites Push 2's original value at $01FE. SP becomes $FD.
Push 259: overwrites Push 3's original value at $01FD. SP becomes $FC.
Push 260: overwrites Push 4's original value at $01FC. SP becomes $FB.

FINAL STATE
------------------------------
SP = $FB (251 decimal). The four oldest values ever pushed (from
pushes 1-4) have been completely destroyed, silently overwritten by
pushes 257-260, with no error, warning, or any indication anything
went wrong.

WHY THE HARDWARE NEVER STOPS IT
------------------------------
Per this chapter's own warn-box, SP is just an ordinary 8-bit register
being incremented and decremented like any other value -- there is no
special circuitry watching for "SP has gone all the way around the
page and is about to overwrite old data." The 6502 has no concept of
"stack overflow" as a distinct, detectable condition; decrementing SP
past $00 is, from the hardware's point of view, completely
indistinguishable from any other 8-bit value wrapping from 0 to 255.
Detecting and preventing this is left entirely to the programmer's
own discipline -- keeping track of how deep the stack actually goes
and never pushing more than page 1 can hold.

WHY THIS WORKS AS AN ANSWER
------------------------------
It traces SP's value precisely through all 260 pushes rather than
just asserting "it wraps," identifies exactly which four bytes get
silently corrupted and why, and explains the hardware's lack of
detection in mechanical terms (SP is an ordinary register with no
special overflow-watching circuitry) rather than just restating that
it's "unsafe."