Re: CRTC timing for VSYNC, 4032 vs 8032

Hi Olaf,

Am 16.10.23 um 21:25 schrieb Rhialto:
> It seems the PET is getting more popular! There are now several demos
> (and games) that depend on a cycle-exact timing of writing data to
> screen memory, so it can swap characters before their next scan line is
> displayed.
>
> VICE got pretty good at emulating this. First I did it for the pre-CRTC
> models, so the Cursor HI-RES program works great.
Cool, that's great to hear! I was only able to do a basic emulation back
then, even though I added some of the effects e.g. from varying the
HSYNC. Do these still work?
http://www.6502.org/users/andre/hwinfo/crtc/pet/index.html
> Now somebody came with an interesting bug report.
> https://sourceforge.net/p/vice-emu/bugs/1954/
> Because of the included test programs, I found that I had to indicate
> the VSYNC signal a cycle earlier than I would have thought. Not at the
> start of a scan line, but just (1 cycle) before.
>
> And the weird thing: on the 8032, to make my test runs look the same as
> the supplied screen photos, I had to do it even another cycle earlier!
>
> Can somebody think of any reason why the VSYNC would start a cycle
> earlier on the 8032 compared to the 4032?

As Commodore used the "universal" board for 4032 and 8032 at some point,
and that was derived from the 8032 CRTC board, the hardware is basically
the same.

HSYNC/VSYNC signals directly go from the CRTC to the output. DE (Display
Enable) is delayed by at least one cycle (and if I read /SR correctly)
even a second one. Those are needed by the hardware to have the time to
a) read byte from video memory, b) pass that through the character ROM
to create the bitmap.

So, HSYNC/VSYNC are - I think - two cycles off (early) the actual screen
display, as the data needs to be processed.

> Another explanation for the difference might be on the other side of the
> timing: maybe somehow on the 8032, you can write to screen memory a
> cycle later and still be "ahead of the beam", in time to get the new
> value displayed rather than the old.
>
> I'm including that possiblity only for completeness, because it seems
> even less likely to me than a difference in VSYNC timing.
>
> Let's give some context to understand these timings better.
>
> In CRTC emulation terms (which fits nicely with the line and character
> numbers in the CRTC, so the designers probably thought of this
> similarly), the screen starts at the first scan line (0) of the first
> char (0) of the first character line (0).  In each scan line, the text
> part is followed by right border, horizontal sync/retrace, left border.
> I think the VIC II works similarly? (but I'm less knowledgable in that
> area)
>
> Each character is output in 1 clock cycle (or on 8032, 2 characters are
> output in 1 clock cycle).
>
> The text lines are followed by a bottom border, vertical retrace
> (which includes vertical sync), and top border. This total number of
> scan lines is expressed in VTOTAL text lines + VTOTALADJ scan lines.
>
> The start of vertical sync is (vertically) adjustable in whole text
> lines. Typically on a 4032 in graphics mode the screen has 25 text
> lines (of 8 scan lines each), vsync starts at text line 37, is 16 scan
> lines long, and the total screen height is 50 text lines + 0 scan lines
> (that includes the top and bottom border and vertical blanking time).
>
> The CRTC signals when the VSYNC signal is active to PIA1 CB1 and to the
> VIA, PB5. CB1 triggers IRQs, PB5 can be polled.
>
> In VICE, the CRTC emulation runs some code at the end of each scan line.
> It is in this code that the indication of the VSYNC signal is done.
>
> (Now that I'm thinking about it, maybe it actually runs 1 cycle too
> late... which might explain some but not all of the off-by-one cases:
> yes for the 4032 1-cycle-earlier, not for the 8032 another-one earlier)
>
> The reporter also reported a difference between 8032 and 8296, but not
> in which direction. Maybe the tested 8296 had the same timings as the
> 4032.
>
> Could there be VSYNC timing differences between different board
> revisions somehow? That could potentially explain things too, but also
> here I don't see a plausible cause. Or differences caused by differently
> sourced CRTCs (6545 vs 6845 maybe?)

Indeed there are differences in that area. Hm but looking them up I am
not sure they are in the correct area. SOME(!) CRTC can skew Display
Enable and Cursor (not used on the PET) by one or two cycles. 
http://6502.org/users/andre/hwinfo/crtc/diffs.html

But as the hardware does the delay itself, there is no need to set it,
and adding a delay would actually put display enable and character data
"out of phase".


André