Non-CRTC PET video circuitry...

[Josh Dersch]

On 11/14/2014 12:50 AM, Josh Dersch wrote:
> On 11/13/2014 10:44 PM, tony duell wrote:
>>> t's only drawing a single line of characters (garbage with some noise
>>> due to a very terrible socket holding the character ROM), centered
>>> vertically.  I initially thought this was a VRAM addressing issue (a
>>> stuck counter or whatnot) but it turns out the VSync signal is much too
>> Since the vertical timing signal is triggered by the counters getting 
>> to end of frame, are
>> you sure it's not a counter problem? Are D6 and D7 counting correctly?
>
> Thank you -- I knew that the counters fed back into the monitor 
> control logic but after I had initially taken a look at the counters 
> (at D6 and D7) I saw that the Load and Clear inputs were getting 
> triggered rapidly (at 64us intervals) and I assumed (incorrectly) that 
> this was the actual problem -- that this load / clear behavior was 
> incorrect.
>
> And after debugging that for a few hours last night I *completely* 
> spaced on that counter-controls-the-monitor thing and after confirming 
> that the 64us interval was actually correct never went back to look at 
> the counters.

Addendum -- the 64us interval is correct for the Load signal, not 
Clear.  Realized the mistake this morning when I got out of bed :).

- Josh

>
> Well, I just did.  D6 is fine.  D7 has all of its outputs stuck high.  
> Replaced it and I now have a full display (of random garbage).
>
> Now to get the CPU to reset properly :).
>
> Thanks for pointing me in the right direction, as usual...
>
>  - Josh
>
>
>>
>>> fast -- it's only about 1.2ms long (it's supposed to be about 16ms).
>>> I'm actually surprised the monitor can deal with that without 
>>> damage, so
>>> I've been leaving the monitor disconnected while debugging. The HSync
>>> period is correct (63.8us or so), and most of the addressing / 
>>> character
>>> display logic (which is driven by earlier portions of the video timing
>>> chain) seems to be running correctly, it's just only getting a 
>>> chance to
>>> draw one line of characters before the next frame starts.
>>> I'm not having much luck tracing down the fault; I have a schematic
>>> (http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001/320008-3.gif) 
>>>
>>> but it's not making it easy to work out exactly how everything ties
>>> together.  I can't find anything resembling a service manual for this
>>> model, but perhaps I haven't looked hard enough yet.
>> I agree, that's  not a nice schematic. It's not obvious if an input 
>> (e.g. a reset input) is actually a logic
>> signal or just pulled high. You have to trace it all over the diagram.
>>
>> Anyway, I think I would start at C6 pin 13. Is it stuck high, or 
>> totally the wrong period?
>>
>> Then check the gates ay the bottom next to the copyright notice, E8, 
>> etc.
>>
>> -tony
>>
>>
>