Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because of invalid timing parameters.
One of my own storys, and I'm a bit hazy so some details are probably wrong: We found an old computer in a university dumpster some night, and decided to mess with the floppy drive. More beer than common sense around. There was some way to tell the hardware which track to read/write, with sane values from 0 to 79. But it was a byte , we could go to 255, so we decided to go up up up!
Well, the drive did exactly as commanded. 80 - 85 worked quite well, except the floppy wasn't guaranteed to be magnetically coated. But once we pushed it too far, the read head went literally over the edge: It jumped off the axle, dropped on the spinning disk below, got a serious yank, and the tiny wires got snapped off.
All of this with a single x86 out instruction, I think in dos 3.x debug. The OS was not stopping you if you did something stupid, there was no hardware protection or anything.
Even today, one is better off not to write undocumented values to registers. True story: I had to investigate a SW bug report concerning a modern, fairly popular microcontroller. (I won't name which.) Sometimes data in RAM changed without our code writing to it. Turns out that our startup code accidentally wrote to a 'reserved' bit in a register, activating some kind of internal RAM test mode. This was confirmed by the µC's manufacturer.
This was how an Apple II made sure you were in track zero - by banging the head against the stop. This is why it makes that typical noise when booting up.
This is similar to the "undocumented instructions" on many CPUs of the time. The Z-80 was famous for reacting to invalid opcodes in somewhat useful ways. The 6502 also reacted in weird ways to invalid opcodes, but I don't remember any useful behavior. When the 65C02 came out (//c and //e enhanced) all invalid opcodes mapped to NOPs.
https://x86.fr/investigating-the-halt-and-catch-fire-instruc...
A CPU, when it encounters bytes in its instruction stream, has to do something, whatever. If there is no interrupt for invalid instruction, it has to do something else. Common behaviour is shadowing legal insn's , but completely new behaviour is always possible
