• Please review our updated Terms and Rules here

Is the PET killer poke really a killer?

One thing of note is that Sony PAL encoders don't work like standard encoders with delay lines. Here is an interesting thread on the topic:

https://www.vintage-radio.net/forum/showthread.php?t=136086

But I am writing about multi-standard decoder here, more precisely about its NTSC part. By the way the same monitor with PAL euro apple2 does not produce the these out-of scanline dots though there are other less visible defects there related to the apple2's PAL output design and are observed on all PAL monitors/tv sets.

Here is a link to the schematic/service manual of the problematic sony monitor:
https://archive.org/details/sony_PVM-1440QM_1442QM_1444QM_Service_Manual
 
Interesting. But indeed while trying to film such a situation, we found something that actually messes up the HSync as well it seems. See this twitter thread: https://twitter.com/AkBKukU/status/1254104735554002945?s=20

VICE crashes at that point with a CPU JAM, but if you let it continue (just skip or go into a CPU loop), VICE shows you that the video output is broken... Let's see here:

PET: cycles per frame set to 20042, refresh to 49.895Hz
PET: cycles per frame set to 20050, refresh to 49.875Hz
*** Main CPU: JAM at $0003
PET: cycles per frame set to 15208, refresh to 65.754Hz
PET: cycles per frame set to 401, refresh to 2493.765Hz

Not sure yet what the cause of this is, but we'll find out and see if this is just a crash artefact or something intended for the old PET and crashing the new PET.

Thanks
André

Any significant disturbance to the H drive H interval could cause the monitor to fail. All that it requires is for the HOT to be turned on for say twice or more the usual period for example.

So if that Poke is affecting the H drive, it could certainly kill the VDU or have a high risk of killing it.

The HOT's collector current rise fairly linearly with time, the stored energy in the LOPT & yoke increases with the square of the current, the peak flyback voltage on the HOT's collector is proportional to the square root of the stored energy, so if the scan time is doubled, the so the peak voltage is doubled, as is the EHT too. So the HOT or EHT diode could fail or other diodes around the LOPT. Some protection in the PET VDU's is afforded by the fact they peak rectify the flyback pulse on the HOT's collector with a diode and electrolytic cap, this will help suppress any transient increases in the HOT's peak collector voltage, but if it is sustained, it will climb up as the capacitor charges.
 
I don't actually own any video monitor where the H drive being incorrect could kill it, monitors like the one in the PET or for example the IBM5151. If I had any video monitor designed like this I would modify it with a small add in pcb, which had a fee running H oscillator (and V osc if required) that was running all the time and uses the drive pulses from the computer to synchronize them. This way, just as in most monitors & TV sets, if you feed them any abnormal sync pulses all that happens is they don't lock and nothing gets damaged.
 
But I am writing about multi-standard decoder here, more precisely about its NTSC part. By the way the same monitor with PAL euro apple2 does not produce the these out-of scanline dots though there are other less visible defects there related to the apple2's PAL output design and are observed on all PAL monitors/tv sets.

Here is a link to the schematic/service manual of the problematic sony monitor:
https://archive.org/details/sony_PVM-1440QM_1442QM_1444QM_Service_Manual

Probably this discussion should be moved by the Mods to its own thread.

I'm a little unsure where the problem is. It could be a non standard NTSC signal from the APPLE2's which is not enough to show on the JVC monitor, but visible on the Sony monitor. Or it could be the NTSC signal out of the APPLE2's is perfectly normal and there is an issue with the Sony monitor, on NTSC mode.

The only way I can see to distinguish the two is to get a definite good standard NTSC signal source from a standard generator, like a Philips PM5519 (common in your part of the world, normally set to PAL, but easy to re-configure internally with links to generate standard NTSC, its a simple task shown in the manual) or another generator. Then test the Sony monitor with that. If its normal, then you would need to look at the Apple2's to examine the composite waveform on the scope and possibly the chroma on a vectorscope too and try to determine why there is an anomaly in the signal causing the effect. If there is an issue with the Sony monitor on a standard NTSC signal, that would require investigating in the monitor.

Also it might pay to check if the NTSC signal out of your APPLE2's is true 3.58MHz NTSC, in case its actually modified NTSC (MNTSC) with a 4.43MHz rather than a 3.58 MHz color frequency. That could be easily checked on a good scope with frequency cursors.

Did you import your Apple's from the USA, or possibly could they have been modified ?
 
Last edited:
Nothing was modified in these apple2 units. An original Apple //e and a //gs were both tested that output NTSC 3.58. The problem is in the monitor's NTSC path when composite video input is used. But what is puzzling me is that information from a previous scanline is influencing the problem under NTSC system. I discovered today that when S-video input is fed with the same composite signal the problem is not present (and the picture is more detailed) so most likely it is some fancy chroma rejection filter incorporated by sony which is not suitable for computer generated images and which for some reason uses the delay line for its processing. Other possibility is incorrect/insufficient disconnection of the delay line under NTSC. The only standard generator I have is of Russian origin and provides only PAL and SECAM ;)
 
so most likely it is some fancy chroma rejection filter incorporated by sony which is not suitable for computer generated images and which for some reason uses the delay line for its processing. Other possibility is incorrect/insufficient disconnection of the delay line under NTSC

The only thing as I mentioned is that Sony TV's don't generally use a PAL delay line, they have a unique type of PAL decoder, that I mentioned in that link about it. But there maybe something about the NTSC mode in the Sony monitor that is not suited to the NTSC signal from the APPLE2's. You need to get a standard NTSC signal to find out.
 
And now we see where the results of all this recent flurry of enquiry about the killer POKE has gone! An excellent video:

https://www.youtube.com/watch?v=7bMJ0NIuWU0

Yes, just as I said, "The Killer Poke is Busted"

Also, don't get too upset about forcing the output of a 74LS TTL IC to ground, remember that a TTL IC is excellent at sinking current, but pretty useless at sourcing it. This is one of the primary reasons why negative logic designs were encouraged (true active low) in that the operating states, where all the action was happening, were generally low on gate outputs with a fan out of 10 or so IC inputs. Also why you will note a lot of enable lines on TTL chips are active low, example chip select lines on ROMs etc.

In addition, passing by all the remarks in the video, the fundamental problem with the "killer Poke" was in fact nothing at all to do with the design of the computer. It was the design of the VDU that was the problem in my view.

When it comes to video snow obviously, if the computer is doing things that alters the video ram data, during scan time you are going to see it as the ram is read out. So most designs, or operating modes, the video ram data updates in the blanking time. The H blanking time is very short, so mostly its done in the V blanking time to avoid image disturbances on the VDU (video monitor).

Back to the monitor:

Because the video monitor in the PET was built into the housing, the designers in my view took liberties. If the pet was designed to drive an existing external monitor, like many computers such as the SOL-20, they would have been forced to create a near industry standard composite video signal.

However, since they custom designed the monitor(VDU), they thought, heck, why bother having an independent vertical and horizontal scan oscillator, we can save on parts and not have that, we will create those signals from the computer's logic circuitry. It was actually a foolish error and I suspect that the designers were unfamiliar with the lesson learnt in the Television industry, where it was realized, even in the early 1930's, that H & V scan oscillators for video monitors (or the part of a TV you can call that) need to be "free running" with their own oscillators, and synchronized to the incoming timing pulses, but don't depend on those incoming pulses (after all it might be noise) to even be present or roughly correct, and they can be grossly abnormal in amplitude and frequency without any detrimental effect on the monitor or VDU part of the television.

So in a computer system, if you don't have those independent scan oscillators (like you have in a standard TV monitor) and rely on H & V "Drive" signals from the computer's logic circuits to coordinate the scan activities (and the fact that the EHT and other auxiliary voltages are derived from the H scan output stage), and for any reason these drive pulses from the computer's logic circuits are corrupted in any way, it will affect the VDU. As noted though a reduction in V drive signal amplitude or frequency cannot harm the monitor in my view, but this is definitely not the case for the Horizontal scan circuits.
 
Last edited:
Is there an easy mod for the 4032/8032 to make it so the poke doesn't do anything at all? It would be easy to modify the IRQ routine to "put it back" but some programs might bypass the regular IRQ. The video mentions adding a resistor? Does the PIA actually need this signal at all on the 4032/8032 or can the pin just be lifted?
 
Last edited:
Is there an easy mod for the 4032/8032 to make it so the poke doesn't do anything at all?

(Creator of the video here)

I wanted to investigate this, but the 6522 VIA on my PET is soldered down. It would be nice to try solving it, but this falls into the realm of "If it ain't broke, don't fix it". It would require desoldering the 40 pin chip which is just inviting lifting pads on the 40yr old PCB. Just lifting the pin would probably be fine, you would loose the CRT sync reference point but I imagine there is barely any software that uses it, if there is any at all. From what I've seen, the system seems to work fine with the signal set as an output so the kernal must not care.


[EDIT] Removed a remark about the keyboard
 
Last edited:
If the keyboard doesn't work after the poke, then it would seem maybe the main system IRQ uses this line for timing. However, I searched the disassembly for the 4.0 Kernal/BASIC and saw no reference to $E842.
 
Last edited:
Oops, I thought I deleted the keyboard part before posting. I tested it again before posting and it was a PEBKAK error on my part.
 
Back
Top