Non-CRTC PET video circuitry...
derschjo at gmail.com
Fri Nov 14 10:57:05 CST 2014
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
> 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 :).
> 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 /
>>> 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
>>> 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,
More information about the cctalk