Re: Modern myths

From: William Levak (wlevak_at_cyberspace.org)
Date: 1999-04-22 02:42:30

Well, here are two perfect examples of the misinformation I have
mentioned.

On Tue, 20 Apr 1999, Todd S Elliott wrote:

> Please read Jim Butterfield's reply below to this thread.

> Sorry to disagree.  To recap the tech aspect:  in early PET/CBM machines,
> 
> Basic waited until "retrace time" before writing to the screen, so that 
> there would not be a screen-snow problem.  It did this by watching the 
> retrace bit in the VIA chip (bit 5 at address $E840/59424).  On earlier 
> PETs you could defeat this wait by changing the directional register of 
> this I/O bit; when it became an output, rather than an input, the system 
> would think that the screen was in retrace all the time, and would 
> deliver the screen data immediately.
> 
> This was quite safe on the earlier machines; but somewhere along the way,
> 
> Commodore changed the design so that this could cause failure; after the 
> design change, there were two TTL-level devices connected to each other, 
> both trying to output different levels.  There were indeed failures, and 
> early users who rejoiced in the speedup now found that they were 
> endangering their machines.

He probably means bit 6 at 59408.  At any rate, that is the circuit that
was changed.  This line was shared with the EOI line of the IEEE
interface.  This interfered with disk operation so Commodore seperated the
two functions.  The timing function was replaced with changes to the
display timing circuitry.  Theses changes are not accessable by any
POKE as they are not connected to any interface or to the address bus in
any way.  The remaining EOI remains as it was before except for being
disconnected from the display circuitry.

The TTL devices "trying to output different levels" simply do not exist.
Anyone can see this for themselves.  The schematics are available at 
http://www.funet.fi/pub/cbm/schematics/computers/pet/index.html

> There was another one that came in when Commodore introduced the CRT 
> controller chip to later models of the CBM line ("Fat 40" and 80xx 
> units).  Users playing POKE games with this chip (at $E880/1, decimal 
> 59520/2) could vary the frequency and sizing of the screen raster.  Keep 
> in mind that the business end of this was transistor circuitry driving a 
> flyback yoke;  take the frequency too far out of line and the yoke's 
> inductance could start to cause damage.  I heard a number of reports of 
> damaged yokes (surprisingly .. I would have thought that the driving 
> circuitry would have been more susceptible to damage).

The danger of damaging the computer by doing this is grossly exagerated.
It is theoretically possible to damage a display in this way, but I know of
NO VERIFIED instance of this happening.

As you change the values from their optimum level, the image begins to
waver and distort.  Getting farther away, you lose sync and the picture
breaks up.  Even further, and the driver circuitry (technically known as a
ramp generator) ceases to respond to the signals and the screen goes
blank.  NONE of this damages the display in any way.

I and others have experimented with the CRTC values, sometimes for hours
on end, without causing any damage whatever.  Even more important is the
statement by the Commodore engineer, that I mentioned before, that he had
tested this out, and it is not possible to do any damage in this way.

When it comes to choosing between the information of a qualified engineer,
and gossip and rumor....   Well, there isn't really any choice.

> In principle, computers should be designed so that software can't damage 
> hardware.  But there were indeed some exceptions in the early PET/CBM
> days.

Well, Commodore did design that computer that could not be damaged by
software, but some people prefer to beleive otherwise, even when the
described faults bear no resemblence to the actual circuitry involved.

Bill Levak


-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.

Archive generated by hypermail 2.1.1.