• Please review our updated Terms and Rules here

Commodore static PET (early dynamic PET) video timings?

F

fachat

Experienced Member
Joined
Apr 24, 2010
Messages
125
Location
near Heidelberg, Germany
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?

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.

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 .... !

So, if anyone has ever looked at that in detail and is able to share some notes, I'd be very happy!

Many thanks
André
 
I can help to some extent with this question.

there is a diagram here I made of the PET's 4 state machine. It is clocked by very narrow pulses, post #58:


The active vertical scan time is 12.86 mS. From that, and the Horizontal period of 64uS, you can work out how many raster lines will be displayed on the VDU. But the actual scan line length on the raster, is shorter than 64uS, because you have to subtract the horizontal retrace time. Inside that raster scan though not all of the lines are used for active display, and the data is clocked out of the shift register by the pixel clock to create a rectangular window on the screen where the characters appear which is smaller than the visible raster scan. So, usually, not all of the scan lines seen on the VDU above and below the characters are "active" lines that can display data and less than 100% of the active H scan time per line is used, or in both cases, the characters would be too near the raster scan's edges.

I would have to have a look on my PET tonight for some estimates.
 
Last edited:
Thanks, that helps a lot. Not that I understand how the NEXT pulse input is generated, but the timing anyway.

So, with 16.7ms screen duration, that is 16700 cycles, so my assumption is this is running at 16704 cycl/screen = 64us x 261 rows. But then, it would be too slow and skipping Jiffies as it does would not make sense.
If it would run at 64us x 260 rows, that would make 16640 cycles per screen - a tad bit too fast. So skipping a Jiffy from time to time would make sense, and the ratio 622/623 would make perfectly sense. Only it does not fit the diagram.

Having a deeper look. The NEXT pulse signal is created by two signals, called "/20 LINES" and "/200 LINES" (see e.g. here http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-7.gif ). With your diagram, that makes perfectly sense, but leads to a correction of the timing values I think. So, NEXT in general pulses every 20 lines, i.e. 1280 cycles = 1.28ms. That's good so far. But the 200 lines would be 12800 cycles, i.e. 12.80ms, not 12.86ms as is stated in the diagram. Which also makes sense, as 12.86ms is not a multiple of 1.28ms as is suggested by the diagram. So, when we have DISPLAY ON for 200 lines = 12800 cycles, and TOP BLANK, VERT SYNC and BOTTOM BLANK each be 20 lines, i.e. 1280 cycles, we end up with 260 lines, and 16640 cycles. So, the 622/623 fix suddenly makes perfect sense.

I really wonder what the rationale was, to actually make the effort of Jiffy correction, as it uses up valuable kernel space. Maybe they wanted to be very correct to be able to use it for scientific instruments connected to the IEEE488 bus? But this bus alone introduces so much latency already.... Any idea?
 
I would suggest using the online Falstad circuit simulator at https://www.falstad.com/circuit/.

This can simulate digital logic and permit you to observe the outputs at various points using the equivalent of an oscilloscope.

I would be very interested in the results as well...

Dave
 
I can take some fairly accurate scope recordings at the weekend, I have a scope with accurately calibrated cursors. I'll double check that 12.86mS measurement, just in case it was 12.80mS.

Can you explain what you mean by the term Jiffy correction ? I am not familiar with that.
 
Last edited:
A jiffy is the hardware clock interrupt.

Jiffy correction is the act of either missing (or inserting) an extra 'imaginary' clock tick every 'n' clock ticks to make the internal real time clock more accurate.

Dave
 
Is there really a "Jiffy pulse" in the PET , if so, where in the circuit do they generate it ?

I played around with the scope tonight on my PET and made some measurements.

The actual timing, you could regard as at least +/- 10% as it was just measured with scope cursors.

But it appears the basic arrangement is shown in the diagram attached.

It should, in theory at least, be possible to correlate this, approximately, with the circuitry.
 
The jiffy clock is the VIDEO ON signal fed-back to one of the 6520 PIAs.

This signal generates an IRQ interrupt to wake up the PET. The same signal (interrupt) is used to scan the keyboard and flash the cursor etc.

Dave
 
fachat said:
Having a deeper look. The NEXT pulse signal is created by two signals, called "/20 LINES" and "/200 LINES" (see e.g. here http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-7.gif ). With your diagram, that makes perfectly sense, but leads to a correction of the timing values I think. So, NEXT in general pulses every 20 lines, i.e. 1280 cycles = 1.28ms. That's good so far. But the 200 lines would be 12800 cycles, i.e. 12.80ms, not 12.86ms as is stated in the diagram. Which also makes sense, as 12.86ms is not a multiple of 1.28ms as is suggested by the diagram. So, when we have DISPLAY ON for 200 lines = 12800 cycles, and TOP BLANK, VERT SYNC and BOTTOM BLANK each be 20 lines, i.e. 1280 cycles, we end up with 260 lines, and 16640 cycles. So, the 622/623 fix suddenly makes perfect sense.

I really wonder what the rationale was, to actually make the effort of Jiffy correction, as it uses up valuable kernel space. Maybe they wanted to be very correct to be able to use it for scientific instruments connected to the IEEE488 bus? But this bus alone introduces so much latency already.... Any idea?
Click to expand...
I did a quick and dirty Verilog simulation of the video circuits a while ago: https://github.com/skibo/PetVideoSim. There's a dump of the waveforms in a VCD file that can be viewed with an open-source wave viewer (gtkwave). Yes, the interrupt frequency is 16,640 cycles.

I think they corrected the clock because it would be kind of embarrassing that a device that was supposed to be super cutting-edge technology at the time had a clock that was fast by a couple minutes a day (if my math is correct).
 
Hugo Holden said:
But it appears the basic arrangement is shown in the diagram attached.
Click to expand...

FWIW, your diagram has an error. The PET displays 25 lines of text, not 24. Looking at how the "/200 Lines" signal is generated it's designed to trigger when the video address generator rolls around to (depending on how you split hairs) 1000, or 250 if you count only the upper 8 bits that are latched so each batch of 40 can be repeated 8 times for every line of characters. (The video address generation circuitry takes advantage of the fact that 40 is divisible by 4 so it doesn't bother latching the bottom two bits.)

Also wondering... the diagram shows the video flyback taking 20 lines. Does the circuitry really hold the vertical sync pulse for that long, or it attenuated somehow to better fit the normal 3 lines of vsync that people use when doing progressive NTSC? If the "Vertical Drive" pulse in the PET is really held for 20 lines it's no wonder that people have trouble trying to get composite video circuits to work with it.
 
I see here are the real experts :)

I've been looking deeper into this and I think I understood the different signals now.

So, /200LINES really triggers, as @Eudimorphodon says when the start of the next line is at 1000. Actually it only tests that the bits for $3c8 = 968 are set and ignores the other bits. So the signal is active on 968-975,984-991, and 1000- addresses. But as the start address of the last character line is only 960 the next line starts at 1000, this triggers only there. (which is not completely right, as as in the last rasterline of a character /RELOAD is set, The 74LS373 at G3 becomes transparent and the "start of the character line" counts with each memory access for the displayed rasterline - but this is only relevant outside of the screen, as it is ANDed with HORIZ DISPLAY OFF...). And thus, it counts 200 rasterlines, making 200x64=12800 cycles.

/20LINES is even more nasty. It takes the uppermost bit of the rastline counter for the charrom low bits at H11, i.e. must be in the second 4 rasterlines of a char line, plus video address bit 6 (of value 64). That took me today's whole evening to figure out, but it is also quite simple once you see it...: When HORIZ DISPLAY ON goes off, the video address counter become transparent (I actually had to dig up the 74LS177 datasheet on this that states that the LOAD input is asynchronous) and thus the video address bus reflects the start address of the next rasterline. In the first character line it is 0, in the second character line it is 40 (so bit 6 is zero), and only in the third character line it gets 80, which sets bit 6 to 1, enabling the signal. This happens with some propagation delay, but NEXT is luckily only derived from it via a low-high transition on VIDEO LATCH, which is at the end of Phi 1, while all the counter changes etc happen at the start of Phi1. So, /20LINES triggers after the 4th rasterline of the third character line, i.e. after (2x8+4)=20 rasterlines, i.e. 20x64=1280 cycles.

Both signals are combined, and a signal on each triggers a counter reset, and a state change in the vertical state circuit.

NEXT thus switches between VIDEO ON (12800 cycles), BOTTOM BLANK (1280 cycles), VERT DRIVE (1280 cycles), and TOP BLANK (1280 cycles).

The reason why /20LINES does not count (i.e. trigger) during VIDEO ON is because to trigger, VIDEO ON must be off...

And, as a conclusion, a whole screen cycle for those PETs is 12800 + 3x 1280 = 16640 cycles.

What a pity I only see your simulation now @tsky ;-)

@Hugo Holden indeed there is an error in your diagram. 1. the display area has 25 character lines, thus 25x8 = 200 rasterlines. Also, the bottom blank is not 29 rasterlines, but 20, and takes only 1.28ms.
 
I.e. now I know what that Jiffy correction is for. And I know I can safely remove it. This whole thing got triggered as I am preparing a benchmark for my MicroPET ( https://github.com/fachat/MicroPET ), and I wanted to use the Jiffies as timer....

Edit: and yes, I am going to write up an article about it for the PETindex :)
 
fachat said:
Actually it only tests that the bits for $3c8 = 968 are set and ignores the other bits. So the signal is active on 968-975,984-991, and 1000- addresses. But as the start address of the last character line is only 960 the next line starts at 1000, this triggers only there.
Click to expand...

Yeah, I noticed it didn't have enough bits in the NAND gate to test it exactly, but, eh, because of how it works it does the job anyway.

I genuinely have to give a lot of credit to the ingenuity of whoever designed this circuitry in terms of making it "efficient", if not exactly the most easy to understand thing in the world. It's cute, for instance, how the bottom address line for the video address (and therefore effectively the master clock for the video address generation) is directly the complement output from the same flip-flop that drives the memory refresh address generator's counter.
 
Yes I noted that RA1 routing too :)

It is indeed very space-efficient by leaving out unnecessary bits, but that indeed makes it hard to understand. It's not like simple state bits and static logic that drives changes in your state with the next clock, you have to think in the time dimension too: some signals only make sense some of the time, and are ignored otherwise.
 
fachat said:
I see here are the real experts :)



@Hugo Holden indeed there is an error in your diagram. 1. the display area has 25 character lines, thus 25x8 = 200 rasterlines. Also, the bottom blank is not 29 rasterlines, but 20, and takes only 1.28ms.
Click to expand...
Thanks,

This error came about because I took it (the last character row) to be the end of the group of 8 lines where the cursor appeared (pushed down to the lowest position) after the screen was filled with characters that scrolled off the top. Looking at the last line of the cursor and comparing that to the end of the vertical scan, that was the timing measurement I put on the diagram. However I did not notice that the cursor would/could go down one more row after hitting RETURN. Interestingly, when you do that and keep pressing RETURN the cursor bounces up and down between row 24 and row 25 !

I corrected the error on the new diagram attached.

I just did some work with the frequency counter & scope, the best measurement I could get on the "64us" was 63.978 uS, so we can assume 64 uS is the target figure.
The 16.66 mS stated in the manual though (older VDU) must just be a rounded approximation. 260 x 64uS =16.64 mS. Looking at this with both the scope & the counter on the actual signal, it is very close to this figure and not 16.66mS to 16.7mS. So I have corrected that on the diagram as well. (The newer VDU schematic said 16.7mS).

One thing though, examining these signals, with both the scope and the counter, I could find no evidence of any irregularities in the signals (extra Jiffy pulses etc), nothing appears to be disturbing the regularity of these signals. If they were, there would also be what amounted to H & V drive glitches, which would be obvious on the VDU's scan too.

Also, it would probably be better if the MODs deleted the first defective diagram I posted, in case it circulates in images on the net.
 

Attachments

  • PET.jpg
    PET.jpg
    223.9 KB · Views: 18
Last edited:
There are no extra Jiffies in the hardware. It is just that the CPU is interrupted at slightly higher than 60Hz (16640 vs. 16667 cycles), and the software(!) Jiffy correction ignores one of every 623 interrupts for Jiffy counting. Thus, Jiffies (in terms of the value of the TI variable) appear in 60Hz in average, albeit with slightly too fast counting for 622 Jiffies, and an extra pause after that.
 
it would probably be better if the MODs deleted the first defective diagram
Click to expand...

Try 'reporting' your own post #8 by clicking the small blue 'report' link at the bottom left hand corner of the post. You will be presented with a text box to explain your reason for reporting the post, at which point you can explain why you want the attachment removed.
 
fachat said:
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?

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.

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 .... !

So, if anyone has ever looked at that in detail and is able to share some notes, I'd be very happy!

Many thanks
André
Click to expand...


Correct - the Jiffy clock is slightly fast:

8MHz / 512 / 260 = 60.0692 Hz; or exactly 16.64 mS.

If a Jiffy was truly 1/60 of a second, there would be 3600 jiffies per minute.
But instead we have 60 / 16.64ms = 3605.7692 jiffies per minute.

That accumulates an error of 5.7692 * 16.64mS = 0.096s every minute (too fast) - more than 2m fast per day.

3605.7692 / 5.7692 = 622.0909....

So skipping every 622nd interrupt corrects this back to 3600 jiffies per minute (or close enough).
 
fachat said:
I really wonder what the rationale was, to actually make the effort of Jiffy correction, as it uses up valuable kernel space. Maybe they wanted to be very correct to be able to use it for scientific instruments connected to the IEEE488 bus? But this bus alone introduces so much latency already.... Any idea?
Click to expand...

The PET has a software "real-time clock" accessible to BASIC. Without the jiffy correction the long term accuracy wouldn't be very good. The PETs master clock is 8MHz. 60 doesn't divide into that by an integer value. Making the RTC timebase accurate in hardware would have required either an additional crystal clock circuit exclusively for the system interrupt, a expensive non-standard/custom 7.9872 MHz crystal rather than an 8 MHz one or some kind of complex fractional-n digital divider to get 60.0000 Hz out of 8 MHz.

Also, in the very first PET 2001 with the slow static RAM video memory, the vertical blanking interrupt was also used to synchronize writes to video RAM in the "snow free" display writing mode. That means that a 60.0000 Hz clock source non-synchronous to the video blanking signal could not have been used for the system interrupt.

The simple firmware fix was the most hardware-economical and sensible solution, as far as I can determine.
 

Attachments

  • petclk.jpg
    petclk.jpg
    160.5 KB · Views: 9
Last edited:
You must log in or register to reply here.
Back
Top