Can a USR command damage a ZX Spectrum? | Hacker News Reader

Can a USR command damage a ZX Spectrum?

retrocomputing.stackexchange.com

83 pointsRazengan32 comments

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_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/

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

http://www.6502.org/users/andre/petindex/poke/index.html

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.

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

I think some Electron games actually used this 'feature' as a percussion sound effect...

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.

That’s really interesting. Thanks!

That's great. Any articles about the Gamecube issue? I can't find any info.

No, and unfortunately you won't find it anywhere since it was an internal issue. I'm intentially avoiding naming the game as I don't think this was publicized anywhere before.

It was indeed written about at length from one of the developers.

The Spectravideo computers (probably all MSX ones too) had it aswell. :-D

> 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.

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/

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.

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.

I hope it wasn't intentional because that sounds like it cost that academy a monitor.

It was my fault, I was just trying.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.)

Configuration (including boot or memory setup, crypto keys validating firmware, ...) also is sometimes in write-once fuses you can set from software.

I've been told just failing to set up clock trees right can burn some things up.

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

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.

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

Reply on news.ycombinator.com