Halt and catch fire

[kb2syd]

From comp.sys.tandy thread: http://groups.google.com/group/comp.sys.tandy/browse_frm/thread/fcc1f17f909025d9/11d9de2deff6831d#11d9de2deff6831d


In the early years, Tandy computer managers grew to dislike the INP/OUT functions in BASIC (mainly because of the support headaches the third-party programs that used them tended to cause), so on the Model II line of computers, the INP/OUT functions were omitted from BASIC entirely (even the Tandy-provided debugger lost I/O commands) and initially the hardware port maps were not disclosed at all, with Tandy urging programmers to use the OS system calls instead of going directly to the hardware.There were a few sound reasons behind this, because it was completely possible to program a Model II to burn up its video system (complete with smoke and sometimes flames), and a few other expensive hardware pieces were also vulnerable to being destroyed due to not knowing what you were doing or if you only programmed half the settings in the alloted time or
similar issues. However, non-technical reasons also made this hardware programming information hard to come by, even internally.

[bbcmicro]

Sounds a bit like the infamous motor on/motor off loop that would supposedly burn out your cassette circuitry on a BBC Micro, and similar sort of thing on a Commodore PET(?)

Not sure if those were true or urban myths though.

[carlsson]

On early PETs, there was a POKE that speed up the text display. On newer PETs, the video circuitry was updated, and it turned out that sending the POKE risks to damage the monitor. After a while, Commodore found out and re-worked the circuitry again, so no sync signal is sent out if the command is issued, and no risk of overloading the display.

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

Although I do have a supply of PETs, I'm not likely to try to see if I can break them.. there are few enough of them and they tend to get smashed up badly in shipping anyway. :-(