Re: Static PET video timing?

On Tue 28 Mar 2023 at 23:49:02 +0200, afachat_at_gmx.de wrote:
> Hi there,
> 
> has anyone actually ever analyzed the static (or even early dynamic PET) video 
> timings? The ones where the video display is created by discrete hardware?

From a practical software point of view but not from hardware, which is
also interesting.

> I've been mulling over the schematics for the whole evening, but the use of 
> obscure counters, JK flipflops and strange logic simply eludes me.
> 
> In particular I am looking for how long a rasterline takes, and how many 
> rasterlines there are.

As it happens, I can tell you that a rasterline takes 64 cycles.
I know this because Cursor #18 program HI-RES depends on that, and it
has been replicated in the VICE repository in testprogs/PET/hi-res/ .
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/PET/hi-res/

From the readme.txt file there:

The hi-res program depends on the IRQ timing of the vertical blanking,
and timing loops, to overwrite screen memory as the video circuitry
(not CRTC; this is for CRTC-less PETs) reads it. This way it makes
new characters from parts of existing ones.

The current CRTC-settings for this case are carefully tuned so that this
mostly works. There is some flickering remaining, but on real hardware
this is also true.

              63, /* R0 total horizontal characters - 1 */
              40, /* R1 displayed horizontal characters */
              50, /* R2 horizontal sync position */
            (0 << 4)|8, /* R3 vertical / horizontal sync width */
              31, /* R4 total vertical characters - 1 */
               4, /* R5 total vertical lines adjustment */
              25, /* R6 displayed vertical characters */
              29, /* R7 vertical sync position */
               0, /* R8 MODECTRL */
               7, /* R9 scanlines per character row - 1, including spacing */
               0, /* R10 CURSORSTART */
               0, /* R11 CURSOREND */
            0x10, /* R12 DISPSTARTH */
            0x00, /* R13 DISPSTARTL */

By hacking on VICE, I found that you get a stable image if the moment that the
IRQ is triggered is delayed by about 16-24 cycles.

(Cursor, both the programs and the text, is of course available from
zimmers)
(In VICE, the CRTC-less models are emulated actually *with* a CRTC, but
it is set up in a fixed way and is not memory-mapped, so it cannot be
changed)

> The reason is, in the PET ROM (at least since BASIC 2), there is a small 
> correction in the counting of the Jiffies, in that every 623rd interrupt is 
> skipped and the Jiffy in this interrupt is unchanged. As Jiffies are supposed to 
> be 60 per second, I can only assume that the original PET did not have a real 
> 60Hz display. If I take 60Hz, it would be 16667 cycles per screen - but with a 
> 622/623 correction, this points to 16640 cycles, which is much more likely 
> (e.g. with 64 cycles per rasterline, this would make 260 rasterlines, which 
> would be easy to check for with bit 8 = bit 2 = 1 - if I would even only find 
> something like a rasterline counter .... !

I think I made similar calculations, and indeed with the above settings,
the screen frequency is not exactly 60 Hz but I think the 1/623 correction
works out fairly well.

> So, if anyone has ever looked at that in detail and is able to share some 
> notes, I'd be very happy!
> 
> Many thanks in advance
> André
-Olaf.
-- 
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/  have kids to make his activity cost neutral." -The BOFH    falu.nl_at_rhialto