Ethan's Retrocomputing Corner - The Killer Poke
cbm-hackers: PET video and the Killer Poke
Subject: Fw: Re: Fw: Re: Modern myths
Date: Thu, 22 Apr 1999 16:49:25 -0700
From: Todd S Elliott
Reply-to: cbm-hackers@dot.tcm.hut.fi
Another response by Jim Butterfield. I will post the earlier response
very soon.
Enjoy.
-Todd Elliott
--------- Forwarded message ----------
From: Jim Butterfield
To: Todd S Elliott
Date: Thu, 22 Apr 1999 11:34:29 -0400 (EDT)
Subject: Re: Fw: Re: Modern myths
Message-ID:
Good for Andre ...
OK, have looked into stuff a little more. My original response can be
set loose, but I'll offer the following revision...
-----------------------
Looking further at the original PET interfaces:
Levak's confusion regarding the PIA chip may stem from this: That
although the EOI-input bit he identifies (bit 6 at 59408) has NOTHING to
do with the screen ...
... the EOI-output bit (controlled by bits 3 to 5 at 59409) was also an
OUTPUT control to blank the screen. Early users of disk drives may
recall the screen "blinking" when they wrote to the drive.
On the same chip (at 59411, bit 7), the retrace-interrupt flag is
found; I don't recall this flag being used for anything.
Yes: in early 1979, Commodore changed the cicuitry in this area. To
quote from an article by Jim Russo in The Transactor, V2, N1, May 1979
(at that time, The Transactor was published by Commodore) dealing with
changes between the original 8K PET and the newly released 16/32K PET:
" - The signal which blanks the video on the 8K is not connected on the
16/32, so POKE 59409,52 no longer works. The ROM routines still
reference this address but the required hardware seems to have been
omitted".
Note that we're talking about an output bit here, which has nothing to
do with detecting whether we're in retrace mode or not. As I previosly
noted, that's on the VIA at 59406. I would have thought that a
self-styled qualified engineer would have noticed the difference between
input and output circuitry.
The video-blanking circuitry was popular with game-writers .. you could
get a good explosion effect by blasting the screen on and off. It was in
no way related to the later C64 screen-blanking feature.
--Jim
Date: Thu, 22 Apr 1999 17:16:15 -0700
Subject: Fw: Re: Fw: Re: Modern myths
From: Todd S Elliott
Reply-to: cbm-hackers@dot.tcm.hut.fi
Jim Butterfield's earlier reply. Enjoy.
-Todd Elliott
--------- Forwarded message ----------
From: Jim Butterfield
To: Todd S Elliott
Date: Thu, 22 Apr 1999 10:42:14 -0400 (EDT)
Subject: Re: Fw: Re: Modern myths
Message-ID:
> > It did this by watching the
> > retrace bit in the VIA chip (bit 5 at address $E840/59424)...
> He probably means bit 6 at 59408.
No, I meant bit 5 at 59424. It was in the VIA chip, not the PIA. Users
effected the speedup by changing the directional register at 59458.
> At any rate, that is the circuit that was changed.
?? Claiming that no other circuits were changed ?? The same VIA I/O
register contained a number of bits related to the IEEE-488 interface,
such as NRFD (both in and out), DAV, ATN, and NDAC, as well as some
cassette tape controls. The EOI signal was elsewhere.
> This line [bit 6 at 59408] was shared with the EOI line of the IEEE
> interface.
Shared with what? The retrace signal certainly wasn't there.
> This interfered with disk operation so Commodore seperated [sic] the
> two functions. The timing function was replaced with changes to the
> display timing circuitry.
?? Where did this come from ??
> ... The remaining EOI remains as it was before except for being
> disconnected from the display circuitry.
Assuming the fantasy that it ever was connected.
> 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
Haven't looked, but I trust that schematics for all revisions are
supplied there.
> > 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
> [sic]. It is theoretically possible to damage a display in this way,
> but I know of NO VERIFIED instance of this happening.
We are talking of events many years in the past. I can assure you that
it's true that more than one user told me that his computer had been
damaged as a result of toying with CRT controller settings.
Some of these could undoubtedly be tracked down, but I don't see the
point. For my part, when I was told of such cases of damage, I decided
not to play with these registers (other than the relatively standard
values that are set up for 40/80, text/graphics options). I would find
it curious if Mr. Levak is advocating uncontrolled experimentation in
this area, assuring all comers that damage is impossible.
> From the Commodore Reference Sheet on the 6545 CRT Controller:
"NOTES:
1. Registers are write-only.
2. Avoid extreme changes in Register 0. CRT damage could result...."
> When it comes to choosing between the information of a qualified
> engineer, and gossip and rumor.... Well, there isn't really any
choice.
When it comes to choosing between the information of someone claiming to
be a qualified engineer, and Commmodore technical information sheets, I
know what choice I will make.
--Jim
From: Andre Fachat
Subject: Re: Modern myths
Date: Thu, 22 Apr 1999 15:36:25 +0200 (MEST)
Reply-to: cbm-hackers@dot.tcm.hut.fi
William Levak wrote:
>
> 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
...
> > 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
Sorry to disagree with you here.
Have you had a look at what Jim is talking about?
He is talking about VIA PB5, the "sync in" input. This pin is normally
used as input and connected to the PIA#1, CB1 to generate the system
interrupt. In earlier PETs (pre-CRTC) this signal came from the "master timing"
electronics, where it was produced by a 74LS08 (C6 in the 2001 schematics
on funet). This signal is also used in IC E9 (input to 74LS20) to blank
the video signal on off-screen times. The signal itself, as I can see
is not fed to the (analog) video (CRT i.e.) electronics.
In normal operation C6 produces the signal that is 5v for screen active
and 0v for off-screen. Now guess what this routine in the Basic 2 kernal
(from a 3032) does (trace $ffd2 to output a blank character for example):
.C:e6ea A8 TAY
.C:e6eb AD 40 E8 LDA $E840
.C:e6ee 29 20 AND #$20
.C:e6f0 D0 F9 BNE $E6EB
.C:e6f2 98 TYA
.C:e6f3 A4 C6 LDY $C6
.C:e6f5 91 C4 STA ($C4),Y
.C:e6f7 60 RTS
This routine waits until the video is off-screen by waiting until VIA PB5
goes low.
The "speed" poke now is to set PB5 to a low output. This way the kernal
routine always thinks it is off-screen and never waits - boom, speedup!
However already in this case we have an unhealthy situation:
The 74LS08 drives the line high and low according to the timing, but
the VIA always pulls the line low. Obviously the 74LS08 wins, because
otherwise the screen would be blank anyway (due to E9), but probably
only because a TTL input recognizes even 2.4V only as a logic 1.
Now the upgrade to the CRTC PETs. A CRTC does not produce the
video on signal - it is not needed: either there is VSYNC for the
vertical flyback or there is DE (Display Enable) that also changes during
horizontal flybacks.
Now the newer PETs have the VIA PB5 and the PIA#1 CB1 connected to the
VDRIVE (basically the VSYNC) signal, that toggles only once a frame
(for the interrupt). So far so good.
The problem is that in the "early model 8032" schematic on funet
the VDRIVE signal is _directly_ fed into some _analog_ circuitry
that directly handles 12V.
In normal operation this is not a problem, because the signal arrives
at the specs, with around 5V and 0V levels.
Now consider the speed poke applied: The VIA always pulls the
line low, reducing the voltage of the high level (which is the onscreen
time here, not the flyback).
I have not analyzed the analog circuitry, but I would not by default
rule out that a video flyback electronics that is set to flyback
for more than the few ms a frame can never go haywire.
In newer PETs CBM has probably added a TTL receiver (probably even a
Schmitt Trigger as I would) before the analog circuitry, which would
prevent this situation, but I cannot confirm this because I have not
found a newer PET CRT schematics on funet.
I have no confirmed PET death as well, but _I_ think it's possible,
so believe whatever you like :-)
> any way. The remaining EOI remains as it was before except for being
> disconnected from the display circuitry.
Indeed. The EOI line used to blank the screen on the first PET boards
(which gives an annoying flicker in the VICE emulator due to the many
screen refreshs). This was done during scroll operations for example.
> 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
So I did.
> 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.
Did you actually try setting VIA PB5 to low output?
(I mean, I won't do it on my PET, but you said it will not damage
your computer ;-)
Andre
--
Email address may be invalid. Use "fachat AT physik DOT tu-chemnitz DOT de"
------Fight SPAM - join CAUCE http://www.cauce.org------Thanks, spammers...
Andre Fachat, Institute of physics, Technische Universität Chemnitz, FRG
http://www.tu-chemnitz.de/~fachat
Date: Fri, 23 Apr 1999 00:43:05 -0400 (EDT)
From: William Levak
Subject: Re: Modern myths
Reply-to: cbm-hackers@dot.tcm.hut.fi
At least that was a coherent description of the circuit.
I don't see where there is a problem. We have 3 TTL level chips connected
together. Typically a TTL chip output can drive 10 devices. There is no
potential for chip failure here. Remember, these are not unlimited output
drivers. for instance, a 74LS20 will output 0.4 milliamps, maximum,
whereas it's input current is 0.1 milliamps. The 6522, on the other hand,
can handle 1.6 milliamps. If the 6522 is set to input, it will clearly
pull the signal to it's level, whether high or low. The signal will then
either be close to zero volts or five volts. This signal is fed to a ramp
generator. The actual voltage level is not relevant. all that is
necessary is that it is high enough to trigger the ramp generator. The
ramp generator controls the output to the deflection yoke by a feedback
network. You cannot overdrive it. The only potential problem is to drive
it at a frequency higher that it is intended for, and thus supplying a
higher effective power output to the deflection yoke. But, the feedback
circuit limits this also.
This is about as much as I know about ramp generators. All I can do is
repeat what several engineers have said to me. If you try to run the ramp
generator at too high a frequency, it will simply not trigger and you will
get no output.
Bill
From: Andre Fachat
Subject: Re: Fw: Re: Fw: Re: Modern myths
Date: Fri, 23 Apr 1999 09:48:43 +0200 (MEST)
Reply-to: cbm-hackers@dot.tcm.hut.fi
William Levak wrote:
> I can make no sense out of this message.
>
> 59460 referred to in the original message is the 6522 timer.
> 59406 referred to in this message is not connected to anything on any
> PET.
> 59424 is the IEEE data input.
He probably meant 59456, i.e. $e840 VIA, Port B.
(I know why I normally use symbolic names for pin names... :-)
VIA PB5 has the mentioned Sync input, that is also connected to
PIA#1, CB1 (should be $e813, 59411), to generate the system interrupt
once a frame (see the RESET routine, it enables the CB1 interrupt).
The other stuff is PIA#1, CA2 (should be $e811, 59409) that drives
the "BLANK TV / -EOI" line
(see http://www.funet.fi/pub/cbm/schematics/computers/pet/2001/320130-1
.gif)
and that, in early PETs, give that blinking when saving to disk,
or the flash effects Jim mentioned.
Later the "blank screen" feature for this output pin has been removed.
Andre
From: Andre Fachat
Subject: Re: Modern myths
Date: Fri, 23 Apr 1999 11:08:49 +0200 (MEST)
Reply-to: cbm-hackers@dot.tcm.hut.fi
William Levak wrote:
> At least that was a coherent description of the circuit.
>
> I don't see where there is a problem. We have 3 TTL level chips connected
> together. Typically a TTL chip output can drive 10 devices. There is no
> potential for chip failure here. Remember, these are not unlimited output
> drivers. for instance, a 74LS20 will output 0.4 milliamps, maximum,
> whereas it's input current is 0.1 milliamps. The 6522, on the other hand,
> can handle 1.6 milliamps. If the 6522 is set to input, it will clearly
> pull the signal to it's level, whether high or low. The signal will then
> either be close to zero volts or five volts. This signal is fed to a ramp
The Problem is that if that would be true, then the poke would not even
work on the original PET. As I said in the description, in the original
PET the Sync signal (produced by an LS08) and read by VIA PB5 is fed
to a 74LS20. This LS20 blanks the video signal during off-screen areas.
Would the VIA, if set to output, draw the level to close to 0V, then
the screen would always be completely blank.
Therefore I had a look at the 74LS08 datasheets (see for example
http://www.fairchildsemi.com/pf/DM/DM74LS08.html) and it indeed states
that the chip can source 0.4mA on high output. But when the VIA draws
up to 1.6mA, the LS08 would surely think this is a short circuit, and
happily source up to 20-100mA short circuit current [1]. I guess that's
more than the VIA can handle. As I said, not a healthy situation.
>From the fact that the LS20 enables the screen as it should we can then
draw the conclusion that the voltage level on the line is
still above approximately 2V, which is the minimum "safe" voltage
for a "1" (could be less, depending on tolerances, etc. max "0" voltage
is 0.8V). But it may be close.
> generator. The actual voltage level is not relevant. all that is
> necessary is that it is high enough to trigger the ramp generator. The
> ramp generator controls the output to the deflection yoke by a feedback
> network. You cannot overdrive it. The only potential problem is to drive
> it at a frequency higher that it is intended for, and thus supplying a
> higher effective power output to the deflection yoke. But, the feedback
> circuit limits this also.
I don't know much about ramp generators either. But some plausibility
checks:
The VDrive input of the early 8032 schematics (see
http://www.funet.fi/pub/cbm/schematics/computers/pet/8032/321448.gif
expects 5V for onscreen and 0V for flyback.
As long as the Vdrive input is (much?) higher than 1.93V
a current is simply integrated to get the ramp voltage (see oscilloscope
point (4)) A diode (D602) lets the TTL output draw the charge of C601 and the
ramp generator goes to 0 when it is time (see oscillscope picture (3) & (4))
The DC voltage at (4) is around 1.93V (so the schematics says).
Now apply the poke to set Via PB to low output. If
the ramp goes a bit above the 1.93V, and then probably above the
voltage of the TTL level (that might be lower than 5V because the VIA
draws it) the flyback could be triggered earlier, because the diode
drains C601 much earlier than it should.
> This is about as much as I know about ramp generators. All I can do is
> repeat what several engineers have said to me. If you try to run the ramp
> generator at too high a frequency, it will simply not trigger and you will
> get no output.
Don't forget that we have to handle pretty old stuff, no CPUs that
analyze the video signal and check the timings or so, just simple
analog electronics. Probably you could ask those engineers to
analyze this analong circuitry with the schematics?
Later (see
http://www.funet.fi/pub/cbm/schematics/computers/pet/8032/8032034.gif)
the analog electronics has been replaced by an integrated circuit,
a TDA 1170. This could probably handle the reduced Vsync voltage.
Andre
[1] Only one pin and not longer than a second, otherwise....
Date: Fri, 23 Apr 1999 16:16:38 -0700
Subject: Myths or Fact?
From: Todd S Elliott
Reply-to: cbm-hackers@dot.tcm.hut.fi
Passing along Jim Butterfield's response.
Enjoy.
-Todd Elliott
===============================
On Fri, 23 Apr 1999, William Levak said:
> I can make no sense out of this message.
I would not want Mr. Levak to be confused, and don't know if typing
or transposition errors might have befuddled him.
So here's a detailed and proofread list of addresses involved:
E810 59408 PIA (6520) Peripheral A I/O Port/Directional Reg
E811 59409 PIA (6520) CRA Control Register
E840 59456 VIA (6522) I/O Port B
E842 59458 VIA (6522) Data Direction Register B
Now, let's recap. Slowly.
Users of early PETs (pre-16K) discovered that they could accelerate
printing to the screen by switching bit 5 of the VIA Data Direction
Register B (at 59458) to "output" instead of "input".
The way this worked was this: that bit 5 of the corresponding VIA
I/O Register B was normally an input which showed when the PET screen
raster was in retrace. The early operating system did not put
characters to screen memory unless retrace was seen. Andre Fachat
has quoted the ROM code that does this.
For some reason, Mr. Levak has gotten the impression that this bit,
and its corresponding POKE, have something to do with the EOI signal
on the IEEE bus, and that it was rewired in revisions of the circuit
board so that the EOI occupied this place alone. Not so.
There was indeed a change in the connecting circuitry; this happened
long before the CRT controller and change to 16/32K architecture.
The POKE that we thought was a clever speedup on the original PET 2001
now started to cause chip failures. Levak doesn't believe it? Tough.
It happened. And it had nothing to do with the EOI signal.
Let's go to the point where Levak fantasizes that the EOI signal had
something to do with the retrace input. To recap the chips:
E840 59456 VIA (6522) I/O Port B
E842 59458 VIA (6522) Data Direction Register B
E810 59408 PIA (6520) Peripheral A I/O Port/Directional Reg
E811 59409 PIA (6520) CRA Control Register
Levak seemed to think that the EOI input signal, bit 6 of E810 (59408)
had something to do with retrace. It didn't. He seemed to think
that the related circuitry on the PIA was rewired to separate the
EOI input and video signal; they were never connected.
There was, however, an interesting setup at E811, 59409. This control
register needs a little more description (from the manufacturer's
data sheet):
"Control Register CRA (figure omitted):
.. the control registers allow the microprocessor to control
the operation of the interrupt lines (CA1, CA2) and peripheral
control line (CA2)..."
Note that on the early PET computers, CA2 was used as an output
port to control both screen blanking and EOI out. Note also that
on these machines, interrupt line CA2 was not used.
"Peripheral A Peripheral Control Lines (CA2, bits 3-5):
... CA2 can act as a totally independent interrupt input ..."
It was not used this way on the PETs.
"... or as a peripheral control output."
Yup, that's how it was used.
"In the output mode (CRA, bit 5 = 1) CA2 can operate
independently to generate a simple pulse ... A second
output mode allows .. a 'handshake .. "
Nope, didn't use either of those features.
"The final output mode can be selected by setting bit 4 of CRA
to 1. In this mode, CA2 is a simple peripheral control
output which can be set high or low ..."
That's how it was used in the PET.
Output, right? Has nothing to do with detecting retrace, right?
Yes, it sent output to both the EOI and the screen-blank, but
that didn't hurt anything, and there was no need to rewire it.
The screen would blink briefly when a user wrote to the IEEE,
but there was no harm - one output driving two devices is not
that strange an occurrence, and poses no technical dangers.
Levak seems to imagine that this connection was changed from
output to input for some mysterious reason; but I've never
heard of that being done. The only retrace POKE that I know of
took place in a VIA register, as indicated above.
When a CRT controller was introduced (with the 16K/32K models)
the screen-blank line was no longer connected. However, this
happened in early 1979; the change to the circuitry on the VIA
(bit 6 of the VIA (6522) I/O Port B at 59456) took place at a
much earlier date.
With the introduction of the 16/32K units and the associated
CRT controller, "..screen snow and 'scroll-up flash' has been
eliminated thanks to dynamic screen RAMs.." (quote from Jim
Russo, The Transactor, May 1979); there was no further need
for the retrace signal to be fed into the system.
--Jim
To Ethan's Home Page
Last modified:
29 June 1999
Compilation © Copyright 1999, Ethan Dicks
<erd@infinet.com>.
All Rights Reserved.