5 ms·

Can a USR command damage a ZX Spectrum?

83 points by Razengan 7y ago

tedunangst 7y ago
> Once ago we told you that it was impossible to break a computer by issuing commands from the keyboard. Well, this would be the exception that proves the rule. Or efivarfs.
- newnewpdro 7y ago
  Or in the bad old days of CRTs and XF86Config, Modeline [0]: You shouldn't use monitor timing values or ModeLine values for monitors other than the model that you own. If you attempt to drive the monitor at a frequency for which it was not designed, you can damage or even destroy it. [0] http://www.faqs.org/faqs/linux/howto/XFree86/ http://www.faqs.org/faqs/linux/howto/XFree86/
  - duskwuff 7y ago
    This warning was probably obsolete even when the FAQ was written (in 1995), though. Multisync monitors were already pretty standard at that point, and they could usually recognize an out-of-range input and display a warning on screen. It's possible that someone damaged a really old single-scan monitor with a bad XFree86 configuration, but I wouldn't be surprised if this were just a rumor which got propagated through warnings in FAQs.
    - anthk 7y ago
      It was possible. I did it by hand with a Windows 98 machine, the OS adverted me on trying to set up the resolution to 800x600. A pitched buzz began and the CRT I was using in some sort of academy bugged off with some burnish smell. No smoke, but you noticed it a bit. The screen had a SVGA resolution by default, so it may have been from 1995 or so.
      - Razengan 7y ago
        I hope it wasn't intentional because that sounds like it cost that academy a monitor.
        anthk 7y ago
        It was my fault, I was just trying.
    - dfox 7y ago
      Any VGA monitor is inherently multisync, which does not imply that it is capable of detecting that horizontal scan is too fast to be safe. The mechanism by which damage occurs involve the fact that essentially everything inside the monitor is synchronized with horizontal scan, including HV power supply for the CRT (usually even the main SMPS is synchronized with horizontal scan to reduce switching noise). And efficiency of both horizontal scan circuitry and the HV power supply depends on the incoming frequency and it is perfectly possible that some frequency (usually, but not necessarily higher than indended) will cause over voltage somewhere. I have destroyed one small monochrome VGA monitor (the kind used in late 90's on cash registers) by just blindly switching the output to some SVGA mode, it even involved quite loud bang from inside of it.
    - milesvp 7y ago
      I killed a vga monitor ~2000 trying to install redhat on a machine with an old monitor. Made me really paranoid every time I tried to install X for the next few years.
      - 72deluxe 7y ago
        As a burst of nostalgia, do you remember using Linuxconf on that machine? I kinda miss the early GTK+ and GNOME1 days, whilst I fumbled with fvwm under RedHat (before the Fedora split).
        milesvp 7y ago
        I don’t think I knew enough at the time to remember. Linuxconf sounds familiar though, I’m sure I used it at some point.
    - 72deluxe 7y ago
      I was poor and using a secondhand "due to be thrown out" IBM 12" display (which despite being 12" had a colossal black border around the actual image on the screen, making the usable area even smaller than 12") and had a 486 DX2 whilst everyone else had Pentiums. I remember fumbling around to get my abysmal graphics card working under XFree86 whilst groping around magazines for appropriate commands and setting the configuration to various bad values that caused that monitor to make hellish screaming noises as I attempted to set it to a resolution and frequency higher than it could ever go. I should have read the warning.
  - flyinghamster 7y ago
    Also, (IIRC) if you had a monochrome display driven by a Hercules card, and accidentally or intentionally set the horizontal refresh rate to zero, your monitor was toast.
    - ksaj 7y ago
      The weird thing I remember with Hercules cards was that their memory was square even if the display wasn't. In other words, if your screen was 720x350, you could set up X for 720x720 and scroll down past the bottom edge of the screen to expose a bigger area than fits on the visible part of the screen. I assume it's still the same on all graphics boards today, but I haven't seen this bidirectional desktop scrolling since back in the Hercules days.
      - newnewpdro 7y ago
        I never had a Hercules, but that virtual desktop automatic panning was a general feature of XFree86. It was especially useful back then when we had CRTs capable of myriad native video modes. In XFree86 you'd switch through them with ctrl-alt-+ and ctrl-alt--, the monitor's video mode would change but the virtual desktop size stayed the same. Whenever the monitor showed less than the entire virtual desktop, the viewport would pan within the virtual desktop when the pointer moved past the screen edges.
        ksaj 7y ago
        Yup exactly. I think most people didn't realize if they set X for a square screen, they could scroll all over the place. I'd forgotten that it was called a viewport. And of course, my favourite was all the custom/customizable video modes that Hercules had silently lurking on the board. Some of the early 32-bit desktops (like the 32032) used 4-colour Hercules at 1024x1024. I don't think 16 and 8 bit PeeCees were capable of going that far, though.
- zozbot234 7y ago
  Modern mobile SoC's can probably be hard bricked even by accident. Run a kernel image that is not intended for the exact model of your hardware, and you incur the risk of e.g. misconfiguring some voltage regulators and trashing some arbitrary part of the SoC beyond recovery. (And the whole thing a huge mess because the patched kernel code is often the only kind of hardware documentation that's actually available for the SoC - hardware designers work directly on the kernel support, and implement all sorts of horrible, undocumented hacks in the process. Though I can only assume that the recently-mainlined SoC's and the IoT-ish designs that are being repurposed by the likes of Purism are somewhat better from that POV.)
  - deleted 7y ago
    [deleted]
  - detaro 7y ago
    Configuration (including boot or memory setup, crypto keys validating firmware, ...) also is sometimes in write-once fuses you can set from software.
  - swiley 7y ago
    I've been told just failing to set up clock trees right can burn some things up.
floatingatoll 7y ago
In summary: No, but certain port behaviors can be toggled between two states in a little-understood manner. Relevant quote from the top answer by the author of the video and article below: > The first video shows what happens if the "randomize of the death" is issued to a real Inves Spectrum+. The video starts with a power cycle to initialize the Inves. If you can, compare this with the result obtained with Spectaculator running the Inves ROM: > Link to video showing an Inves Spectrum+ executing BORDER 5: RANDOMIZE USR 4665 FLV video: http://www.zxprojects.com/images/stories/videos/rand_usr_4665_inves.flv http://www.zxprojects.com/images/stories/videos/rand_usr_466... > Well, I think that after seeing this, it's the end of the "randomize of the death" hoax. Details, including the port behavior, are here: http://www.zxprojects.com/inves/ http://www.zxprojects.com/inves/
myrandomcomment 7y ago
There was an original Commodore PET that could be damaged by a POKE command. They fixed it quickly.
stevenwoo 7y ago
But you can kill a Commodore Pet with a poke, we had those Pets in our high school programming class in the 1980's. https://en.wikipedia.org/wiki/Killer_poke https://en.wikipedia.org/wiki/Killer_poke http://www.6502.org/users/andre/petindex/poke/index.html http://www.6502.org/users/andre/petindex/poke/index.html
- ksaj 7y ago
  The PET's killer poke made the text on the screen look like it was wrapped around a cylinder. The damage it could cause was screen burn in along the left-most and right-most columns because they were at maximum brightness, while the rest of the text was less bright and quite stretched out.
peterclary 7y ago
The BBC Micro B had a physical internal relay which controlled cassette tape player motors. The following program (from memory) would produce an alarming buzzing which, if left long enough, purportedly led to the relay wearing out, i.e. physical damage. 10 *MOTOR 1 20 *MOTOR 0 30 GOTO 10
- jlarcombe 7y ago
  I think some Electron games actually used this 'feature' as a percussion sound effect...
- gambiting 7y ago
  I mean, CD/DVD based games consoles have the drive rated for only a certain number of reads, there is an interview with Naughty Dog devs talking about development of Crash Bandicoot, where apparently they discovered that on average playing through the entire game would do a "lifetime" of reads, Sony allowed the game to be released anyway(and it looks like the drive was under-rated if anything, since no significant drive breakages were reported from playing this game). I do however know of one Gamecube game which was an inch away from being on the market in a state that would brake the drive of every gamecube that played it - some very clever person found an undocumented command that would increase the speed of the drive, leading to super quick streaming from the drive, resolving some loading issues that the game had at the time. It worked well, the game was finished and went into manufacturing, and fortunately Nintendo realized that it's no coincidence that QA's and their own test kits keep breaking after playing the game, and pulled it before it hit the shelves.
  - peterclary 7y ago
    That’s really interesting. Thanks!
  - pj1115 7y ago
    That's great. Any articles about the Gamecube issue? I can't find any info.
    - 7y ago
trollied 7y ago
Halt and Catch Fire. https://en.wikipedia.org/wiki/Halt_and_Catch_Fire https://en.wikipedia.org/wiki/Halt_and_Catch_Fire
growlist 7y ago
I seem to recall that pulling out a joystick connector from a joystick port whilst the Spectrum was switched on could permanently damage both the joystick and the computer! Though there might have been an edge connector peripheral in there somewhere depending on the model.

83 points by Razengan 7y ago

> Once ago we told you that it was impossible to break a computer by issuing commands from the keyboard. Well, this would be the exception that proves the rule. Or efivarfs.

newnewpdro 7y ago
Or in the bad old days of CRTs and XF86Config, Modeline [0]: You shouldn't use monitor timing values or ModeLine values for monitors other than the model that you own. If you attempt to drive the monitor at a frequency for which it was not designed, you can damage or even destroy it. [0] http://www.faqs.org/faqs/linux/howto/XFree86/ http://www.faqs.org/faqs/linux/howto/XFree86/
- duskwuff 7y ago
  This warning was probably obsolete even when the FAQ was written (in 1995), though. Multisync monitors were already pretty standard at that point, and they could usually recognize an out-of-range input and display a warning on screen. It's possible that someone damaged a really old single-scan monitor with a bad XFree86 configuration, but I wouldn't be surprised if this were just a rumor which got propagated through warnings in FAQs.
  - anthk 7y ago
    It was possible. I did it by hand with a Windows 98 machine, the OS adverted me on trying to set up the resolution to 800x600. A pitched buzz began and the CRT I was using in some sort of academy bugged off with some burnish smell. No smoke, but you noticed it a bit. The screen had a SVGA resolution by default, so it may have been from 1995 or so.
    - Razengan 7y ago
      I hope it wasn't intentional because that sounds like it cost that academy a monitor.
      - anthk 7y ago
        It was my fault, I was just trying.
  - dfox 7y ago
    Any VGA monitor is inherently multisync, which does not imply that it is capable of detecting that horizontal scan is too fast to be safe. The mechanism by which damage occurs involve the fact that essentially everything inside the monitor is synchronized with horizontal scan, including HV power supply for the CRT (usually even the main SMPS is synchronized with horizontal scan to reduce switching noise). And efficiency of both horizontal scan circuitry and the HV power supply depends on the incoming frequency and it is perfectly possible that some frequency (usually, but not necessarily higher than indended) will cause over voltage somewhere. I have destroyed one small monochrome VGA monitor (the kind used in late 90's on cash registers) by just blindly switching the output to some SVGA mode, it even involved quite loud bang from inside of it.
  - milesvp 7y ago
    I killed a vga monitor ~2000 trying to install redhat on a machine with an old monitor. Made me really paranoid every time I tried to install X for the next few years.
    - 72deluxe 7y ago
      As a burst of nostalgia, do you remember using Linuxconf on that machine? I kinda miss the early GTK+ and GNOME1 days, whilst I fumbled with fvwm under RedHat (before the Fedora split).
      - milesvp 7y ago
        I don’t think I knew enough at the time to remember. Linuxconf sounds familiar though, I’m sure I used it at some point.
  - 72deluxe 7y ago
    I was poor and using a secondhand "due to be thrown out" IBM 12" display (which despite being 12" had a colossal black border around the actual image on the screen, making the usable area even smaller than 12") and had a 486 DX2 whilst everyone else had Pentiums. I remember fumbling around to get my abysmal graphics card working under XFree86 whilst groping around magazines for appropriate commands and setting the configuration to various bad values that caused that monitor to make hellish screaming noises as I attempted to set it to a resolution and frequency higher than it could ever go. I should have read the warning.
- flyinghamster 7y ago
  Also, (IIRC) if you had a monochrome display driven by a Hercules card, and accidentally or intentionally set the horizontal refresh rate to zero, your monitor was toast.
  - ksaj 7y ago
    The weird thing I remember with Hercules cards was that their memory was square even if the display wasn't. In other words, if your screen was 720x350, you could set up X for 720x720 and scroll down past the bottom edge of the screen to expose a bigger area than fits on the visible part of the screen. I assume it's still the same on all graphics boards today, but I haven't seen this bidirectional desktop scrolling since back in the Hercules days.
    - newnewpdro 7y ago
      I never had a Hercules, but that virtual desktop automatic panning was a general feature of XFree86. It was especially useful back then when we had CRTs capable of myriad native video modes. In XFree86 you'd switch through them with ctrl-alt-+ and ctrl-alt--, the monitor's video mode would change but the virtual desktop size stayed the same. Whenever the monitor showed less than the entire virtual desktop, the viewport would pan within the virtual desktop when the pointer moved past the screen edges.
      - ksaj 7y ago
        Yup exactly. I think most people didn't realize if they set X for a square screen, they could scroll all over the place. I'd forgotten that it was called a viewport. And of course, my favourite was all the custom/customizable video modes that Hercules had silently lurking on the board. Some of the early 32-bit desktops (like the 32032) used 4-colour Hercules at 1024x1024. I don't think 16 and 8 bit PeeCees were capable of going that far, though.
zozbot234 7y ago
Modern mobile SoC's can probably be hard bricked even by accident. Run a kernel image that is not intended for the exact model of your hardware, and you incur the risk of e.g. misconfiguring some voltage regulators and trashing some arbitrary part of the SoC beyond recovery. (And the whole thing a huge mess because the patched kernel code is often the only kind of hardware documentation that's actually available for the SoC - hardware designers work directly on the kernel support, and implement all sorts of horrible, undocumented hacks in the process. Though I can only assume that the recently-mainlined SoC's and the IoT-ish designs that are being repurposed by the likes of Purism are somewhat better from that POV.)
- deleted 7y ago
  [deleted]
- detaro 7y ago
  Configuration (including boot or memory setup, crypto keys validating firmware, ...) also is sometimes in write-once fuses you can set from software.
- swiley 7y ago
  I've been told just failing to set up clock trees right can burn some things up.

floatingatoll 7y ago

In summary: No, but certain port behaviors can be toggled between two states in a little-understood manner. Relevant quote from the top answer by the author of the video and article below: > The first video shows what happens if the "randomize of the death" is issued to a real Inves Spectrum+. The video starts with a power cycle to initialize the Inves. If you can, compare this with the result obtained with Spectaculator running the Inves ROM: > Link to video showing an Inves Spectrum+ executing BORDER 5: RANDOMIZE USR 4665 FLV video: http://www.zxprojects.com/images/stories/videos/rand_usr_4665_inves.flv http://www.zxprojects.com/images/stories/videos/rand_usr_466... > Well, I think that after seeing this, it's the end of the "randomize of the death" hoax. Details, including the port behavior, are here: http://www.zxprojects.com/inves/ http://www.zxprojects.com/inves/

myrandomcomment 7y ago

There was an original Commodore PET that could be damaged by a POKE command. They fixed it quickly.

stevenwoo 7y ago

But you can kill a Commodore Pet with a poke, we had those Pets in our high school programming class in the 1980's. https://en.wikipedia.org/wiki/Killer_poke https://en.wikipedia.org/wiki/Killer_poke http://www.6502.org/users/andre/petindex/poke/index.html http://www.6502.org/users/andre/petindex/poke/index.html

ksaj 7y ago
The PET's killer poke made the text on the screen look like it was wrapped around a cylinder. The damage it could cause was screen burn in along the left-most and right-most columns because they were at maximum brightness, while the rest of the text was less bright and quite stretched out.

peterclary 7y ago

The BBC Micro B had a physical internal relay which controlled cassette tape player motors. The following program (from memory) would produce an alarming buzzing which, if left long enough, purportedly led to the relay wearing out, i.e. physical damage. 10 *MOTOR 1 20 *MOTOR 0 30 GOTO 10

jlarcombe 7y ago
I think some Electron games actually used this 'feature' as a percussion sound effect...
gambiting 7y ago
I mean, CD/DVD based games consoles have the drive rated for only a certain number of reads, there is an interview with Naughty Dog devs talking about development of Crash Bandicoot, where apparently they discovered that on average playing through the entire game would do a "lifetime" of reads, Sony allowed the game to be released anyway(and it looks like the drive was under-rated if anything, since no significant drive breakages were reported from playing this game). I do however know of one Gamecube game which was an inch away from being on the market in a state that would brake the drive of every gamecube that played it - some very clever person found an undocumented command that would increase the speed of the drive, leading to super quick streaming from the drive, resolving some loading issues that the game had at the time. It worked well, the game was finished and went into manufacturing, and fortunately Nintendo realized that it's no coincidence that QA's and their own test kits keep breaking after playing the game, and pulled it before it hit the shelves.
- peterclary 7y ago
  That’s really interesting. Thanks!
- pj1115 7y ago
  That's great. Any articles about the Gamecube issue? I can't find any info.
  - 7y ago

trollied 7y ago

Halt and Catch Fire. https://en.wikipedia.org/wiki/Halt_and_Catch_Fire https://en.wikipedia.org/wiki/Halt_and_Catch_Fire

growlist 7y ago

I seem to recall that pulling out a joystick connector from a joystick port whilst the Spectrum was switched on could permanently damage both the joystick and the computer! Though there might have been an edge connector peripheral in there somewhere depending on the model.