Apple ][+ rolling video started today

[Witchy]

Hi folks,

I've been running up and testing my oldest Apple ][+ to resurrect the first program I ever wrote in Apple Structured BASIC and getting ADTPro 2.10 going on it. Today I powered up and the display was rolling so I tweaked the horizontal hold on the monitor which fixed it for a bit then it went again. Thinking it was the screen I tried an LCD TV with composite input, same problem, then my trusty Sony PVM which also had the same problem.

So it's the video output on the ][+ at fault. Looking at Mike Willegal's link to the Apple][ Service Notes it says 'rolling video B14 74LS32/C11 74LS04. Trouble is my board doesn't have a 74LS32 at B14, both B13 and 14 are 74LS02s. There IS an LS32 at C14 but that tests OK, as does the LS04 at C11. Looking at Mike's reproduction board it doesn't have B14 either.

I'm surprised this doesn't seem to me a more searchable problem. Anyone else seen it?

Cheers!

 

[Hugo Holden]

Apple II vdu's as far as I recall have a very conventional H & V scan system (much like a standard video VDU). Which means they have separate vertical and horizontal scan oscillators and the set therefore has an "H hold preset control" and a "V hold preset control".

"Rolling" of the the picture vertically up or down implies the V oscillator has dropped out of lock and is not synchronizing with the vertical sync pulses.

The vertical hold control should bring it into lock, if all is normal with the circuitry.

If the V hold control setting is off and if the picture is seen to be rolling downwards it cannot be bought into sync because the V scan osc is running faster than the incoming sync. The correct setting of the V hold control, is when the picture is seen to be rolling upwards just in the moment before it locks. This is because, at that setting, the natural running frequency of the V scan osc is just a little lower than the incoming sync, and that sync triggers the start of vertical flyback, rather that the V osc itself. So the V osc is synch'd on a pulse by pulse basis from the incoming V sync pulses.

When the H hold or H scan osc drops out of lock the picture appears to tilt over on its side and diagonal bars appear. The H lock system is quite different than the vertical lock system, it is like an AFC (automatic frequency control or a PLL design). When the H scan osc locks it is "captured" and the H scan osc will stay in sync over a range of setting of the H hold control, and the picture phase (Horizontal position) of the picture will be seen to move left and right manipulating the H hold control, until it suddenly drops out of lock at each end. This is because the H scan osc is controlled by a DC level. This level represents the averaged frequency difference of the H scan osc compared to the incoming sync, so unlike the vertical osc synchronization, it is not done on a pulse by pulse basis.

From what you said the vertical hold control needs adjusting most likely. But, a photo would be good just to be sure.

 

[Witchy]

Hi Hugo,

Thanks for the reply but you didn't read the whole message. In the first paragraph I said I'd also tried an LCD TV and my trusty Sony PVM so the fault is in the video circuit on the motherboard. I'm currently running through 'The Apple ][ Circuit Description' by Winston D. Gayler so I can trace the video signal back from the composite output to the sync generator. 'Scope time!

 

[Hugo Holden]

Hi Hugo,

Thanks for the reply but you didn't read the whole message. In the first paragraph I said I'd also tried an LCD TV and my trusty Sony PVM so the fault is in the video circuit on the motherboard. I'm currently running through 'The Apple ][ Circuit Description' by Winston D. Gayler so I can trace the video signal back from the composite output to the sync generator. 'Scope time!

Yes, if its is rolling vertically on both monitors, and won't come into vertical lock, it suggests something has happened to the vertical sync pulse circuit on the motherboard.

If you could post that sub-circuit I could make some suggestions what to look for. Generally, there is a part of the circuit where the H syncs and V syncs are combined (often with an XOR gate or other gates) before they are mixed with the video content and that will be the first place to look with the scope.

 

[daver2]

I checked the online schematics and the ICs referenced (B14 and C11) are the types as specified.

There must be at least two (2) revisions of the PCB then.

Anyhow, three of the B14 gates and one of the C11 gates are implicated in the synch circuitry. I assume (if it is rolling) that the H synch. would be present, but the V synch. is either absent or the wrong frequency.

I think the plan would be exactly what you are doing - going on a safari with the oscilloscope!

It would, however, be interesting to track down the schematics for your particular PCB though - just to see what the differences are...

Dave

 

[Witchy]

It would, however, be interesting to track down the schematics for your particular PCB though - just to see what the differences are...

Buzzing out with a meter my video circuit matches the Rev 1 board, video schematic is on page 219, Fig C-18. As luck would have it, while I was probing around with the scope the display suddenly steadied when I touched the LS04 at C11. I should point out this was on yet another LCD screen on my workbench. Going back to the original Apple monitor and the problem returned so I swapped in the C11 chip from a Europlus I had kicking around and there's no difference.

Strange.

It's currently stable on the workbench LCD and I've added back in the DISK][ card, SSC and a Saturn 128K board which I've never tested. I'll order a couple of new LS04s to see if the display steadies on all screens and not just this one; both LCD TVs are Samsungs so you'd expect them to be similar if not identical in performance.

Speaking of the Saturn 128K board, it's full of MCM6665 64kx1 chips which I'm having trouble finding equivalent listings for, AFAIK the 4164 64kx1 should work as a replacement for dead chips but I haven't found anything to confirm this.

*edit* I just remembered PCBJunkie which lists equivalences for all relevant chips - http://pcbjunkie.net/index.php/resources/ram-info-and-cross-reference-page/ - it lists the 4164 as spare for the MCM6665 so that's splendid since I've got some of those.

 

[daver2]

The thing to watch out for with 4164 DRAM is whether they are 128 or 256 cycle refresh devices.

128 cycle DRAM will work in place of 256 cycle ones - but not the other way round (unless the board supports 256 cycle refresh and was originally populated with 128 devices for some reason).

Dave

 

[Witchy]

I used a 4164-15 which works fine. Interestingly it was the first chip in bank 0 that was dead and that killed the whole board. Also not having a RAM multiplexer (MC3242) fitted for some reason but thanks to a quick DDG* search I found a good enough hi-res pic of the board to show me what the chip should be.


*DuckDuckGo