Jump to content

Killer poke

Edit links
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Tathar (talk | contribs) at 13:30, 22 December 2023 (Removing extra word). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In computer jargon, a killer poke is a method of inducing physical hardware damage on a machine or its peripherals by the insertion of invalid values, via, for example, BASIC's POKE command, into a memory-mapped control register. The term is typically used to describe a family of fairly well known tricks that can overload the analog electronics in the CRT monitors of computers lacking hardware sanity checking (notable examples being the IBM Portable[1] and Commodore PET.)

Specific examples

Zuse Z1/Z3

The Z1 (1938) and Z3 (1941) computers built by Konrad Zuse contained illegal sequences of instructions which damaged the hardware if executed by accident.[2]

Commodore PET

The 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 I/O register (POKE 59458,62[3]) 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.[1]

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 CRT monitor.[4] 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 burn in to the display led to the nickname “killer poke,”[3] however, it is not known to have ever caused any permanent damage to the monitor.[5]

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 III

The 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.[6] 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] While this is not a single "killer poke", it demonstrates a software failure mode that could permanently damage the hardware.

Cassette tape relay

The TRS-80 Color Computer, IBM PC, IBM PCjr, Nascom, MSX, Amstrad CPC, and BBC Micro from Acorn Computers all contained a built-in relay for controlling an external tape recorder.[7] Toggling the motor control relay in a tight loop would reduce the relay's longevity.

Amiga

The floppy drive of the Amiga personal computer could be made to produce noises of various pitches by making the drive heads move back and forth. A program existed which could play El Cóndor Pasa, more or less correctly, on the Amiga's floppy drive.[8] As some sounds relied on the head assembly hitting the stop, this gradually sent the head out of alignment.

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").[9]

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.[10]

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 MSi laptops) by using the rm command to delete the /sys/firmware/efi/efivars/ directory, or recursively delete the root directory.[11]

Game Boy

The Game Boy's LCD screen can be turned off by game software. Doing so outside of the vertical blanking interval can allegedly damage the hardware.[12]

Dragon 32

The Dragon 32 CPU clock speed was defined by a programmable clock divider which could be programmed by the user to increase the CPU speed by 50% or 100% and theoretically, 150% (though selecting this speed caused the system to crash.) The installed CPU, a 6809E, was originally rated at 1 MHz with the Dragon 32 running at 0.89 MHz. A speed uplift to 1.33 MHz appeared mostly stable whereas an uplift to 1.78 MHz would cause video sync to be lost. It was publicized at the time that the increased heat produced by the speed increase would eventually damage the CPU. POKE 65495, 0 allowed for double speed with graphics still displayed properly. POKE 65497, 0 lost video sync.

See also

References

  1. ^ a b "Computing Myth #1: Software cannot damage hardware". Oldskooler Ramblings. 2 February 2006. Archived from the original on 23 February 2011. Retrieved 28 December 2010.
  2. ^ Rojas, Raúl (April–June 1997). "Konrad Zuse's Legacy: The Architecture of the Z1 and Z3" (PDF). IEEE Annals of the History of Computing. 19 (2): 5–16 [9–10]. doi:10.1109/85.586067. Archived (PDF) from the original on 3 July 2022. Retrieved 3 July 2022. p. 10: There are a lot of details that the engineer designing the "microprogram" must keep in mind, otherwise short circuits can destroy the hardware. The Z1 with its mechanical design was still more sensitive in this respect than the Z3. Even after it was completed, there were sequences of instructions that the programmer had to avoid in order not to damage the hardware. One of those sequences was inadvertently tried at the Berlin Museum of Technology and Transportation, which led to slight damaging of the reconstructed Z1 in 1994. (12 pages)
  3. ^ a b "Commodore PET 2001 computer". oldcomputers.net. Archived from the original on 1 January 2011. Retrieved 10 January 2011.
  4. ^ Fachat, André. "Killer Poke". PET index. 6502.org. Archived from the original on 9 November 2010. Retrieved 10 November 2010.
  5. ^ The Killer POKE. Archived from the original on 11 December 2021.
  6. ^ "80-GRAFIX Manual". Vintagecomputer.net. 1980. Archived from the original on 27 February 2016. Retrieved 8 June 2015.
  7. ^ Mims, Forrest M. (June 1985). "Computerized security alarms". Creative Computing Magazine. 11 (6): 58. Archived from the original on 28 June 2011. Retrieved 16 February 2011.
  8. ^ "El Condor Pasa". minimal video. 16 September 2008. Archived from the original on 13 February 2011. Retrieved 6 November 2010.
  9. ^ "Re: LG CDRoms". newbie@linux-mandrake.com. The Mail Archive. 29 October 2003. Archived from the original on 30 September 2010. Retrieved 29 December 2009.
  10. ^ https://www.cs.unc.edu/~porter/pubs/fbrick-mobisys-2019.pdf
  11. ^ "Mount efivarfs read-only · Issue #2402 · systemd/systemd". GitHub. 21 January 2016. Archived from the original on 23 October 2016. Retrieved 9 November 2016.
  12. ^ "LCD Control". Pan Docs. Retrieved 17 September 2022.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Killer_poke&oldid=1191262797"