4 ms·

Ha, reminds me of a myth from 20+ years ago, that there was a virus that could damage your CRT display by requesting the monitor to refresh at 1000Hz or somethi

Ha, reminds me of a myth from 20+ years ago, that there was a virus that could damage your CRT display by requesting the monitor to refresh at 1000Hz or something stupid, which would damage at least some monitors without the proper safeguards. No idea if that was real though.

darkr 4y ago
No idea if there was a virus doing this, but it was definitely possible to permanently damage at least some CRTs by setting refresh rate too high
capableweb 4y ago
> reminds me of a myth from 20+ years ago > No idea if that was real though Chose one :) You can't state it was a myth and then later say you don't know! I've heard the same thing about older CRT monitors and remember reading about people damaging their CRT monitors by careless programming in regards to refresh rates. But I haven't actually seen in real life, and I must have read about this in the early 90s or something like that I think, so long time ago.
- omnibrain 4y ago
  I heard this in regarding to Linux and X, back in the 90ies. That scared me away from Linux for quite some time. I felt confident, that I could fix any "software damage" to the family PC running Windows, but I did not want to risk hardware damage.
- gambiting 4y ago
  Well I mean it was in the category of "you can catch mew in Pokemon Yellow if you get to the truck behind the ship"-myth. People have said it, I read about it online in the "early days" but I've never seen it happen to anyone.
  - capableweb 4y ago
    Yeah, I'm in the same camp :) Heard/read about it, never seen it myself. However, I have seen people having Mew back when I played some Gameboy myself, that one is _not_ a myth :)
  - Cthulhu_ 4y ago
    What I'm reading is that Mew was "handed out" in magazines and events, although this article does mention a method of getting it, probably involves RNG manipulation and bit flippery: https://www.ign.com/wikis/pokemon-red-blue-yellow-version/Mew https://www.ign.com/wikis/pokemon-red-blue-yellow-version/Me...
    - gambiting 4y ago
      Yes, "back in the day" you could only get it through official distribution, or hack it in with a gameshark code. There was a truck behind the SS Anne that you could get to(you had to get the HM move from the boss, then faint - that would put you in the nearest pokecentre, so you could continue until you found HM Swim, then you could go back to the ship since it never departed, and swim behind it - and yep, there was a truck) - but that truck did nothing, it was just set decoration. The RNG method to encounter Mew in the wild was only discovered years and years later and most definitely wasn't known 20 years ago.
- radarsat1 4y ago
  > You can't state it was a myth and then later say you don't know! The word myth generally has two meanings. One is that it's a false belief. The other is that it's a legendary story of which the truth is not known. GP obviously intended the latter definition.
  - capableweb 4y ago
    I was not aware of this, so thank you for clarifying it for me.
b112 4y ago
I recall, back in the day, we had video cards on the Amiga with a passthrough port. The Amiga could output stock NTSC/Pal and some close variants, and many monitors existed which could handle that lower scan frequency (15khz), as well as higher res output with Picasso cards. https://bigbookofamigahardware.com/bboah/product.aspx?id=466 https://bigbookofamigahardware.com/bboah/product.aspx?id=466 Anyhow, we always tested new monitors before selling them. Monitors which could handle 15khz and higher frequencies too, were expensive and rare. Often customers would plug in a cheaper, standard PC monitor, and so we wanted to offer those too. We plugged in one such, and when the switch came to 15khz? It exploded. Like, the magic grey smoke escaped, along with flames and melting plastic. Every other monitor brand we tested just went blank screen, or reported "out of sync" on the display. In as customers might accidentally leave passthrough on/setup, we figured selling this monitor to them to be a mistake. So if it can happen with too low of a frequncy, surely crappy monitors also exist which blow when too high a frequency is passed. But that's just terrible, crappy hardware.
amiga-workbench 4y ago
You could overdrive the CRT on the Commodore PET with a poke to a particular register. On some models it would cause damage, on other models it would cause faster screen draws.
dredmorbius 4y ago
Those of us who've calculated our own modelines are familiar with that caution. It was part of the documentation of standard tools at the time, though I've never personally encountered a damaged display or knew of anyone else who had. Though one turns up in this thread: <https://news.ycombinator.com/item?id=33093385 https://news.ycombinator.com/item?id=33093385> A typical modeline calculator warning: It is also important to say that some seemingly reasonable modelines can damage monitors, so this method of hand-crafting monitor descriptions includes a certain amount of risk. <https://arachnoid.com/modelines/ https://arachnoid.com/modelines/> My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.
- dbttdft 4y ago
  Before "multiscan"/"multisync" CRTs, there were fixed mode CRTs which would break in one way or the other if the incoming signal had the wrong timings. > My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations. It's done in the monitor.
  - blarghyblarg 4y ago
    yep, 13 year old me had one of these around the first time I was using X. Way back when you had to write your config files by hand. One little oopsie, and that monitor had a line through it for the rest of its life.
- nyanpasu64 4y ago
  One of my recent projects was to get my PC to output 480i signals to my recently acquired Trinitron TV for running modern and historical games on a CRT TV (I'd definitely be better served by a monitor, but I didn't have one and still don't :( ). I learned many interesting but otherwise-irrelevant bits of trivia from this experience: - A modeline used to output 480i SDTV-compatible signals (525 scanlines) from a PC, differs from the same resolution's modeline under Coordinated Video Timings (arachnoid.com generates a 516-line modeline for 480i, and Linux's cvt tool doesn't document its interlacing flag because interlacing is not part of VGA or something). - DVI and HDMI signals are effectively continuous signals with CRT-like timings, translated into digital signals (discrete-time at your GPU's configured dot clock, and quantized) and encoded using TMDS with special pixel values on the blue channel (outside of the 0-255 range) for hblank and vblank. Whereas DP signals are packetized in some manner I haven't researched. - One common way to output 480i is through HDMI-to-component converters. But 480i has a too low pixel clock below the HDMI spec's minimum timing, and many GPUs cannot put out such a slow signal or converters cannot understand it. (I wonder how DP-to-component would fare, given it's packet-based and might not suffer from a minimum dot clock readable by the receiver chip.) A common workaround recommended by the developers "CRT Emudriver" (AMD GPU drivers modded by in-place binary patching) is to set a 2560x240p or 480i "super resolution", then configure emulators and games to output stretched signals. Unfortunately, neither non-RetroArch games nor Windows's CRT Emudriver cannot rescale their image to non-square pixels and their 1440x480 images were squashed to a 4:3 aspect ratio, so I had to switch to Linux and xrandr for square images. - I had to pick 1440x480i because otherwise the vblank pulses generated by my AliExpress HDMI-to-component converter were insufficiently staggered between interlaced and non-interlaced scanlines. Since I don't have an oscilloscope, I diagnosed this by piping the sync-on-green composite signal into my motherboard's 192khz line-in capture, then recording in Audacity and comparing to correct NTSC timings (the vertical serrations should be evenly spaced and they weren't). - The Linux amdgpu driver is well capable of outputting a 1440x240p resolution (there are many NTSC modelines, with varying undesirable horizontal offsets and stretching, and vertical offsets), and xrandr is an excellent way to scale a 1280x960 framebuffer to 1440x240 or such (which is scaled back to square aspect ratio on-screen). Unfortunately Linux amdgpu's dc driver for its display controller (compatible with atomic modesetting) has missing support for interlacing, the easiest workaround being to pass `amdgpu.dc=0` to the Linux kernel command line (this disables atomic modesetting, switches to the legacy display controller driver, breaks HDMI audio, and makes the mouse cursor unaffected by Redshift so Plasma's text cursor becomes practically invisible on white text fields). - - I debugged this extensively at https://gitlab.freedesktop.org/drm/amd/-/issues/1636 https://gitlab.freedesktop.org/drm/amd/-/issues/1636, but failed to solve the problem. If I hack the driver to force interlacing on (not realizing I needed interleaving as well), the resulting analog signal repeats the first scanline hundreds of times followed by a birth-defect serration pulse, which I would be unsurprised if it would physically destroy some CRTs. I recorded a video (epilepsy warning) at https://www.youtube.com/watch?v=GoQ9q1lwKHI https://www.youtube.com/watch?v=GoQ9q1lwKHI. - - Antonio Giner claims to have a fix for interlacing in amdgpu.dc=1 mode, for his GroovyArcade arcade CRT distribution, but it's not upstreamed, it doesn't currently work on my GPU, and I never did get around to porting it to my older RX 570, finding the correct modeline, and testing that it works. Turns out modern games like Stray aren't optimized for interlaced displays (vsync caused horrendous input lag) or 480-line-tall screens (HUD elements and jump prompts are too small to see), who would've known! I do think Celeste would work fairly well in 240p mode, but I haven't gotten around to testing that either (in either amdgpu.dc=0 or porting my patch). - Compensating for CRT television overscan (since modern games like Stray draw HUD elements like jump prompts right on the edge of the screen) is a nightmare. On amdgpu, xrandr's underscan option can only take off <=128 pixels evenly split between the left and right, or the top and bottom. Worse yet, the display controller outputs eg. 1340x460 of non-black image, by downscaling (in hardware?) a second time from the 1440x480 framebuffer downscaled in software from 1280x960, creating unnecessary vertical blur. - - Since I don't know how to perform both downscaling steps in hardware with unmodified amdgpu drivers (like a non-square-pixel VSR), I opted to perform both downscaling steps in software, by writing a shell script to kill plasmashell and open a full-screen mpv showing a black .png file on a 1440x1030 framebuffer, then use KWin rules to overlay a 1280x960 borderless window of Stray at a precise position over mpv (with black mpv borders on all 4 sides), use xrandr to downscale 1440x1030 to 1440x480i, then kill mpv once Stray exits. It's a terrible setup and I wish there was a better way. But CRTs and overscan is dead, interlacing is dead, 640x480 is dead, and only a fool or experimenter (or someone with complex-trauma depression seeking comfort in nostalgia and cats) would try hooking up modern computers and games to triply-dead CRT SDTVs and expecting them to work.
mirekrusin 4y ago
Yes, it was real, the same with moving hard drive head outside of the disk so it falls off.
GekkePrutser 4y ago
It's very common in a range of hardware throughout the years: https://en.m.wikipedia.org/wiki/Killer_poke https://en.m.wikipedia.org/wiki/Killer_poke Also not mentioned there but on the MSX 1 you could 'burn out" the tape drive relay by switching it on and off very fast.
formerly_proven 4y ago
In a poorly constructed CRT you can definitely damage the drive circuits by an excessively high line rate. That's basically the reason why CRTs tend to include "out of range" warnings and shutdowns. You could, I think at least theoretically, also cause damage by incorrect blanking, because line rate + blanking determines the drive waveform for the LOPT.
f1shy 4y ago
I heard about a million times that, and that you could also destroy the hard drive by reading the first and last track many times in secession. If at all truth, it was in very specific HW (I was in touch with really, really, really big amounts of people in the industry and HW, and have never first hand heard of that happening).
flyinghamster 4y ago
One I remember from way back was that the XT-era Hercules monochrome adapter allowed the refresh rate to be set to zero, causing the monitor to emit its magic smoke. I'm not sure it was weaponized, though.

darkr 4y ago

No idea if there was a virus doing this, but it was definitely possible to permanently damage at least some CRTs by setting refresh rate too high

capableweb 4y ago

> reminds me of a myth from 20+ years ago > No idea if that was real though Chose one :) You can't state it was a myth and then later say you don't know! I've heard the same thing about older CRT monitors and remember reading about people damaging their CRT monitors by careless programming in regards to refresh rates. But I haven't actually seen in real life, and I must have read about this in the early 90s or something like that I think, so long time ago.

omnibrain 4y ago
I heard this in regarding to Linux and X, back in the 90ies. That scared me away from Linux for quite some time. I felt confident, that I could fix any "software damage" to the family PC running Windows, but I did not want to risk hardware damage.
gambiting 4y ago
Well I mean it was in the category of "you can catch mew in Pokemon Yellow if you get to the truck behind the ship"-myth. People have said it, I read about it online in the "early days" but I've never seen it happen to anyone.
- capableweb 4y ago
  Yeah, I'm in the same camp :) Heard/read about it, never seen it myself. However, I have seen people having Mew back when I played some Gameboy myself, that one is _not_ a myth :)
- Cthulhu_ 4y ago
  What I'm reading is that Mew was "handed out" in magazines and events, although this article does mention a method of getting it, probably involves RNG manipulation and bit flippery: https://www.ign.com/wikis/pokemon-red-blue-yellow-version/Mew https://www.ign.com/wikis/pokemon-red-blue-yellow-version/Me...
  - gambiting 4y ago
    Yes, "back in the day" you could only get it through official distribution, or hack it in with a gameshark code. There was a truck behind the SS Anne that you could get to(you had to get the HM move from the boss, then faint - that would put you in the nearest pokecentre, so you could continue until you found HM Swim, then you could go back to the ship since it never departed, and swim behind it - and yep, there was a truck) - but that truck did nothing, it was just set decoration. The RNG method to encounter Mew in the wild was only discovered years and years later and most definitely wasn't known 20 years ago.
radarsat1 4y ago
> You can't state it was a myth and then later say you don't know! The word myth generally has two meanings. One is that it's a false belief. The other is that it's a legendary story of which the truth is not known. GP obviously intended the latter definition.
- capableweb 4y ago
  I was not aware of this, so thank you for clarifying it for me.

b112 4y ago

I recall, back in the day, we had video cards on the Amiga with a passthrough port. The Amiga could output stock NTSC/Pal and some close variants, and many monitors existed which could handle that lower scan frequency (15khz), as well as higher res output with Picasso cards. https://bigbookofamigahardware.com/bboah/product.aspx?id=466 https://bigbookofamigahardware.com/bboah/product.aspx?id=466 Anyhow, we always tested new monitors before selling them. Monitors which could handle 15khz and higher frequencies too, were expensive and rare. Often customers would plug in a cheaper, standard PC monitor, and so we wanted to offer those too. We plugged in one such, and when the switch came to 15khz? It exploded. Like, the magic grey smoke escaped, along with flames and melting plastic. Every other monitor brand we tested just went blank screen, or reported "out of sync" on the display. In as customers might accidentally leave passthrough on/setup, we figured selling this monitor to them to be a mistake. So if it can happen with too low of a frequncy, surely crappy monitors also exist which blow when too high a frequency is passed. But that's just terrible, crappy hardware.

amiga-workbench 4y ago

You could overdrive the CRT on the Commodore PET with a poke to a particular register. On some models it would cause damage, on other models it would cause faster screen draws.

dredmorbius 4y ago

Those of us who've calculated our own modelines are familiar with that caution. It was part of the documentation of standard tools at the time, though I've never personally encountered a damaged display or knew of anyone else who had. Though one turns up in this thread: <https://news.ycombinator.com/item?id=33093385 https://news.ycombinator.com/item?id=33093385> A typical modeline calculator warning: It is also important to say that some seemingly reasonable modelines can damage monitors, so this method of hand-crafting monitor descriptions includes a certain amount of risk. <https://arachnoid.com/modelines/ https://arachnoid.com/modelines/> My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations.

dbttdft 4y ago
Before "multiscan"/"multisync" CRTs, there were fixed mode CRTs which would break in one way or the other if the incoming signal had the wrong timings. > My understanding is that monitors and/or graphics cards/drivers would reject potentially harmful configurations. It's done in the monitor.
- blarghyblarg 4y ago
  yep, 13 year old me had one of these around the first time I was using X. Way back when you had to write your config files by hand. One little oopsie, and that monitor had a line through it for the rest of its life.
nyanpasu64 4y ago
One of my recent projects was to get my PC to output 480i signals to my recently acquired Trinitron TV for running modern and historical games on a CRT TV (I'd definitely be better served by a monitor, but I didn't have one and still don't :( ). I learned many interesting but otherwise-irrelevant bits of trivia from this experience: - A modeline used to output 480i SDTV-compatible signals (525 scanlines) from a PC, differs from the same resolution's modeline under Coordinated Video Timings (arachnoid.com generates a 516-line modeline for 480i, and Linux's cvt tool doesn't document its interlacing flag because interlacing is not part of VGA or something). - DVI and HDMI signals are effectively continuous signals with CRT-like timings, translated into digital signals (discrete-time at your GPU's configured dot clock, and quantized) and encoded using TMDS with special pixel values on the blue channel (outside of the 0-255 range) for hblank and vblank. Whereas DP signals are packetized in some manner I haven't researched. - One common way to output 480i is through HDMI-to-component converters. But 480i has a too low pixel clock below the HDMI spec's minimum timing, and many GPUs cannot put out such a slow signal or converters cannot understand it. (I wonder how DP-to-component would fare, given it's packet-based and might not suffer from a minimum dot clock readable by the receiver chip.) A common workaround recommended by the developers "CRT Emudriver" (AMD GPU drivers modded by in-place binary patching) is to set a 2560x240p or 480i "super resolution", then configure emulators and games to output stretched signals. Unfortunately, neither non-RetroArch games nor Windows's CRT Emudriver cannot rescale their image to non-square pixels and their 1440x480 images were squashed to a 4:3 aspect ratio, so I had to switch to Linux and xrandr for square images. - I had to pick 1440x480i because otherwise the vblank pulses generated by my AliExpress HDMI-to-component converter were insufficiently staggered between interlaced and non-interlaced scanlines. Since I don't have an oscilloscope, I diagnosed this by piping the sync-on-green composite signal into my motherboard's 192khz line-in capture, then recording in Audacity and comparing to correct NTSC timings (the vertical serrations should be evenly spaced and they weren't). - The Linux amdgpu driver is well capable of outputting a 1440x240p resolution (there are many NTSC modelines, with varying undesirable horizontal offsets and stretching, and vertical offsets), and xrandr is an excellent way to scale a 1280x960 framebuffer to 1440x240 or such (which is scaled back to square aspect ratio on-screen). Unfortunately Linux amdgpu's dc driver for its display controller (compatible with atomic modesetting) has missing support for interlacing, the easiest workaround being to pass `amdgpu.dc=0` to the Linux kernel command line (this disables atomic modesetting, switches to the legacy display controller driver, breaks HDMI audio, and makes the mouse cursor unaffected by Redshift so Plasma's text cursor becomes practically invisible on white text fields). - - I debugged this extensively at https://gitlab.freedesktop.org/drm/amd/-/issues/1636 https://gitlab.freedesktop.org/drm/amd/-/issues/1636, but failed to solve the problem. If I hack the driver to force interlacing on (not realizing I needed interleaving as well), the resulting analog signal repeats the first scanline hundreds of times followed by a birth-defect serration pulse, which I would be unsurprised if it would physically destroy some CRTs. I recorded a video (epilepsy warning) at https://www.youtube.com/watch?v=GoQ9q1lwKHI https://www.youtube.com/watch?v=GoQ9q1lwKHI. - - Antonio Giner claims to have a fix for interlacing in amdgpu.dc=1 mode, for his GroovyArcade arcade CRT distribution, but it's not upstreamed, it doesn't currently work on my GPU, and I never did get around to porting it to my older RX 570, finding the correct modeline, and testing that it works. Turns out modern games like Stray aren't optimized for interlaced displays (vsync caused horrendous input lag) or 480-line-tall screens (HUD elements and jump prompts are too small to see), who would've known! I do think Celeste would work fairly well in 240p mode, but I haven't gotten around to testing that either (in either amdgpu.dc=0 or porting my patch). - Compensating for CRT television overscan (since modern games like Stray draw HUD elements like jump prompts right on the edge of the screen) is a nightmare. On amdgpu, xrandr's underscan option can only take off <=128 pixels evenly split between the left and right, or the top and bottom. Worse yet, the display controller outputs eg. 1340x460 of non-black image, by downscaling (in hardware?) a second time from the 1440x480 framebuffer downscaled in software from 1280x960, creating unnecessary vertical blur. - - Since I don't know how to perform both downscaling steps in hardware with unmodified amdgpu drivers (like a non-square-pixel VSR), I opted to perform both downscaling steps in software, by writing a shell script to kill plasmashell and open a full-screen mpv showing a black .png file on a 1440x1030 framebuffer, then use KWin rules to overlay a 1280x960 borderless window of Stray at a precise position over mpv (with black mpv borders on all 4 sides), use xrandr to downscale 1440x1030 to 1440x480i, then kill mpv once Stray exits. It's a terrible setup and I wish there was a better way. But CRTs and overscan is dead, interlacing is dead, 640x480 is dead, and only a fool or experimenter (or someone with complex-trauma depression seeking comfort in nostalgia and cats) would try hooking up modern computers and games to triply-dead CRT SDTVs and expecting them to work.

mirekrusin 4y ago

Yes, it was real, the same with moving hard drive head outside of the disk so it falls off.

GekkePrutser 4y ago

It's very common in a range of hardware throughout the years: https://en.m.wikipedia.org/wiki/Killer_poke https://en.m.wikipedia.org/wiki/Killer_poke Also not mentioned there but on the MSX 1 you could 'burn out" the tape drive relay by switching it on and off very fast.

formerly_proven 4y ago

In a poorly constructed CRT you can definitely damage the drive circuits by an excessively high line rate. That's basically the reason why CRTs tend to include "out of range" warnings and shutdowns. You could, I think at least theoretically, also cause damage by incorrect blanking, because line rate + blanking determines the drive waveform for the LOPT.

f1shy 4y ago

I heard about a million times that, and that you could also destroy the hard drive by reading the first and last track many times in secession. If at all truth, it was in very specific HW (I was in touch with really, really, really big amounts of people in the industry and HW, and have never first hand heard of that happening).

flyinghamster 4y ago

One I remember from way back was that the XT-era Hercules monochrome adapter allowed the refresh rate to be set to zero, causing the monitor to emit its magic smoke. I'm not sure it was weaponized, though.