Editing Killer poke (section)

==Specific examples==
===Zuse Z1/Z3===
The [[Z1 (computer)|Z1]] (1938) and [[Z3 (computer)|Z3]] (1941) computers built by [[Konrad Zuse]] contained illegal sequences of instructions which damaged the hardware if executed by accident.<ref name="Rojas_1997"/>

===Commodore PET===
The [[Commodore PET|PET]]-specific killer poke is connected to the architecture of that machine's video rasterizer circuits. In early PETs, writing a certain value to the memory address of a certain [[memory-mapped I/O|I/O]] register (<code>POKE 59458,62</code><ref name=":1">{{cite web|url=http://oldcomputers.net/pet2001.html|title=Commodore PET 2001 computer|publisher=oldcomputers.net|access-date=10 January 2011|archive-date=1 January 2011|archive-url=https://web.archive.org/web/20110101165618/http://oldcomputers.net/pet2001.html|url-status=live}}</ref>) made the machine able to display text and graphics on the screen 106% faster. This was accomplished by disabling a "wait to print to screen" safeguard designed to reduce static/noise by preventing the shared VRAM from being read by the display at the same time as it was being written to by the CPU. With this safeguard disabled, graphics could appear on the screen twice as fast, but small bits of static would also appear. Despite the static, some games designed for early PETs included this POKE in their source code in order to benefit from the faster graphics.<ref name=":0" />

When the PET range was revamped with updated hardware, the video rasterizer circuits were redesigned to run at a faster speed and without the need for a "wait to print" safeguard. Thus, the old POKE trick no longer resulted in faster graphics. Instead, performing the old trick on the new hardware led to strange behavior by the new video chip, which could cause [[signal contention]] and possibly damage the PET's integrated [[cathode-ray tube|CRT]] monitor.<ref>{{cite web |url=http://www.6502.org/users/andre/petindex/poke/index.html |title=Killer Poke |work=PET index |first=André |last=Fachat |publisher=6502.org |access-date=10 November 2010 |archive-date=9 November 2010 |archive-url=https://web.archive.org/web/20101109023601/http://www.6502.org/users/andre/petindex/poke/index.html |url-status=live }}</ref> This is because the exact pin targeted by the POKE command used to control display timing, but in the upgraded video chip, that pin controlled the vertical sync. Thus, running the POKE on the newer hardware caused graphics to compress vertically, sometimes down to an extremely bright horizontal line. Fears that this anomaly might [[Screen_burn-in|burn in]] to the display led to the nickname "killer poke";<ref name=":1" /> however, it is not known to have ever caused any permanent damage to the monitor.<ref>{{cite video |url=https://www.youtube.com/watch?v=7bMJ0NIuWU0 | archive-url=https://ghostarchive.org/varchive/youtube/20211211/7bMJ0NIuWU0| archive-date=2021-12-11 | url-status=live|title=The Killer POKE}}{{cbignore}}</ref>

===Commodore 1541 Disk Drive===
The [[Commodore 64]] had an optional external 5-1/4" floppy drive. The [[Commodore 1541]] contained a 6502 microprocessor which was used to run [[Commodore DOS]] and also to manage the drive mechanism. The drives stored data on 35 tracks (#0–34), and the stepper motor could be manually controlled through BASIC by PRINT#-ing "MEMORY-WRITE" commands to the drive (which correspond to the POKE command of BASIC, but write to the drive's internal memory and I/O registers, not those of the computer itself). If the drive was at either end of its range (track 0 or track 39) and it was commanded to continue moving, there was no software or firmware method to prevent drive damage. Continued "knocking" of the drive head against the stop would throw the mechanism out of alignment. The problem was exacerbated by [[copy protection]] techniques that used non-standard disk formats with unusual track counts. The [[Commodore 1571]] had an optical head stop instead of a mechanical one.

===TRS-80 Model I & III===
The original [[TRS-80]] and [[TRS-80 Model III]] had the ability to switch between a 32-character-wide display and a 64-character display. Doing so actuated a relay in the video hardware, accomplished by writing to a specific memory-mapped control register.<ref>{{Cite web|url = http://www.vintagecomputer.net/fjkraan/comp/trs80/grafix80/80grafix.html|title = 80-GRAFIX Manual|date = 1980|access-date = 8 June 2015|website = Vintagecomputer.net|archive-date = 27 February 2016|archive-url = https://web.archive.org/web/20160227094802/http://www.vintagecomputer.net/fjkraan/comp/trs80/grafix80/80grafix.html|url-status = live}}</ref> Programs that repeatedly switched between 32- and 64-character modes at high speed (either on purpose or accidentally) could permanently damage the video hardware.{{Citation needed|date = June 2015}} While this is not a single "killer poke", it demonstrates a software [[failure mode]] that could permanently damage the hardware.

The TRS-80 Model I also has a similar cassette motor relay accessible via a memory poke command and could result in damaging the relay.

===LG CD-ROM drives===
Certain models of LG CD-ROM drives with specific firmware used an abnormal command for "update firmware": the "clear buffer" command usually used on CD-RW drives. Linux uses this command to tell the difference between CD-ROM and CD-RW drives. Most CD-ROM drives dependably return an error for the unsupported CD-RW command, but the faulty drives interpreted it as "update firmware", causing them to stop working (or, in casual parlance, to be "[[bricked]]").<ref>{{cite web |url=http://www.mail-archive.com/newbie@linux-mandrake.com/msg142409.html |title=Re: LG CDRoms |work=newbie@linux-mandrake.com |publisher=The Mail Archive |date=29 October 2003 |access-date=29 December 2009 |archive-date=30 September 2010 |archive-url=https://web.archive.org/web/20100930225309/http://www.mail-archive.com/newbie@linux-mandrake.com/msg142409.html |url-status=live }}</ref>

=== Flash memory ===
The resource of flash memory is large, but limited. Since writing to storage is an essential operation, most applications have enough privileges to exhaust the resource of flash chips within 24 hours by filling the storage enough to cause [[write amplification]] and continuously rewriting a small file.<ref>https://www.cs.unc.edu/~porter/pubs/fbrick-mobisys-2019.pdf {{Bare URL PDF|date=August 2024}}</ref>

===MSi Laptops UEFI===
[[Systemd]] mounts variables used by [[Unified Extensible Firmware Interface]] on [[Linux]] system's [[sysfs]] as writable by the root user of a system. As a result, it is possible for the [[root user]] of a system to completely brick a system with a non-conforming UEFI implementation (specifically some [[Micro-Star International|MSi]] laptops) by using the <code>rm</code> command to delete the <code>/sys/firmware/efi/efivars/</code> directory, or recursively delete the [[root directory]].<ref>{{cite web|url=https://github.com/systemd/systemd/issues/2402|title=Mount efivarfs read-only · Issue #2402 · systemd/systemd|website=[[GitHub]]|date=21 January 2016|access-date=9 November 2016|archive-date=23 October 2016|archive-url=https://web.archive.org/web/20161023083811/https://github.com/systemd/systemd/issues/2402|url-status=live}}</ref>{{better source|date=March 2024}}