| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Concerning PAL-NTSC-Differences: exact amount of available cycles per second
Don't know if this is the right forum to ask this, but I'll give it a try...
I'm wondering about the exact amount of cycles per second on a PAL machine compared to a NTSC machine. Up to now, my simple approach was as follows:
PAL-TV-Norm: 625 interlaced lines/frame, 50Hz
PAL-C64: 312 frames (=floor(625/2))
63 cycles per rasterline (no badline, no sprites)
20 cycles per rasterline (badline, no sprites)
-> total number of cycles per second (standard PAL-screen with badlines, no sprites) =
(no.of nonbadlines*cycles + no.of badlines*cycles)*no.of frames per second =
((312-25)*63 + 25*20)*50 = (287*63 + 25*20)*50 = (18081 + 500)*50 = 18581*50 = 929050 cycles/second
NTSC-TV-Norm: 525 interlaced lines/frame, 60Hz
NTSC-C64: 262 frames (=floor(525/2))
65 cylces per rasterline (no bl, no spr)
22 cylces on a badline (no spr)
-> total number of cycles per second (standard NTSC-screen with badlines, no sprites) =
(no.of nonbadlines*cycles + no.of badlines*cycles)*no.of frames per second =
((262-25)*65 + 25*22)*60 = (237*65 + 25*22)*60 = (15405 + 550)*60 = 15955*60 = 957300 cycles/second
However, I found different values on the internet. For example, AAY64 has a table with the following values:
+----------+--------+-------+---------+---------+---------+------------+
| VIC | Video | # of | Cycles/ | Cycles/ | Frames/ | System |
| Type | system | lines | line | frame | second | Clock (Hz) | +----------+--------+-------+---------+---------+---------+------------+
| 6569 | PAL-B | 312 | 63 | 19656 | 50.125 | 985248 |
| 6567R8 | NTSC-M | 263 | 65 | 17095 | 59.826 | 1022727 |
+----------+--------+-------+---------+---------+---------+------------+
While it is clear that my calculations take bl into consideration while the other values don't, I'm stuck with the following questions:
i. How does it come that there are 263 rasterlines on an NTSC-machine, while the TV-Standard is 525 interlaced lines which should give 525/2 = 262.5 -> 262 (just like the math would be in PAL world)?
ii. Is the no. of frames/second really as stated in the table? Does it mean that the 51st PAL-frame is already started before the end of the respective second? And for NTSC, that the 60th frame is not fully finished?
Every hint's welcome! |
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Ofcourse, it has to be
PAL-C64: 312 lines/frame (=floor(625/2)) and
NTSC-C64: 262 lines/frame (=floor(525/2) accordingly.
Hope it's correct now. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I. one frame would be 263 and the other would be 262 lines (iirc)
II. yes. remember the C64 (video source) dictates the frame timing and the monitor syncs to it
last not least - dont forget that the oscillators arent ever exactly 985248Hz or 1022727Hz either, so the exact number of cycles per second varies between individual setups - and even change over time (temperature).
what are you trying to do here anyway? =) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Also for normal interlaced sources, the odd fields contain a half line at the bottom, while the even fields contain a half line at the top. So 262.5 lines each.
On the C64 (and other '240p' computers and consoles of the time), this is not done, so it outputs two fields on top of each other, thus no interlacing but therefore you get visible scanline gaps. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
also, the last (or first?) scanline is one cycle shorter (on NTSC only perhaps, i forgot) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
As for the standards:
NTSC: line rate 15734 Hz, 525 lines, frame rate ≈ 59.939 Hz
PAL: line rate 15625 Hz, 625 lines, frame rate = 50 Hz
As you noticed, the C64 doesn't follow the standard. The table from AAY64 is correct, so if the question is "how many clock cycles does the C64 process in a second" the answer is 985248 for PAL and 1022727 for NTSC, with some variation due to oscillator inaccuracies and temperature variation. Speaking of which, does anyone know tolerances or specifics? I don't think I've ever seen any measurements.
If the question is "how many clock cycles are usable by the 6510 in a second", it gets a little more complicated (unless the screen is turned off). Badline DMA takes 1000 cycles per frame, and every sprite takes two cycles per raster line, but that's just the *minimum*. AEC goes low three cycles before DMA starts, so depending on which instruction the 6510 is executing DMA typically takes 3 cycles extra.
Worst case, with 8 expanded sprites enabled and no write cycles hitting the AEC window, that's going to cost 25 * (40 + 16 + 3) + (42 - 5) * (16 + 3) = 2178 cycles per frame, or roughly 11-13%. With more DMA (e.g. sprite multiplexing or FLI) you of course lose even more. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
as for tolerance... couldnt find a datasheet quickly, but it should be somewhere in the 20..30PPM range |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: as for tolerance... couldnt find a datasheet quickly, but it should be somewhere in the 20..30PPM range
Do you mean the crystal? You are at least a magnitude off. Early 80s consumer xtals should be well above +/-200 ppm. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
oh really =) didnt expect it to be THAT bad =D |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Thanks to everyone for the replies!
I was more aiming at "How many cycles are available for the 6510?" (thanks MV for explicitly separating cases;)). But this was more or less obvious from my calculation in the inital post, as I already calculated the cycles loss caused by badlines.
What I get now is that it's better to think the other way around, i.e. not starting with rasterlines and frames, then multiplying it by the TV-Norm-Refresh-Rate, but to deduct the no.of frames per second from the no.of cycles available per second (which is given by the crystal frequency). As you write, the crystal frequency changes over time and temperature; this means, that we have alternating no.of frames/second depending on the actual crystal frequency (though only in fractions, i.e. in PAL world, 50.125 could become 50.005 etc.), right?
Still, some questions remain:
1. If there are different no.of rasterlines depending on odd/even frame in NTSC world, it should be the same for PAL (i.e. 313/312). Up to now, I thought it's always
no.of rasterlines per frame = floor([no.of interlaced lines in the discussed TV-Norm]/2),
where the "/2" comes from the fact that only one frame type is used (even or odd) while "floor" cuts the ".5" of the division as the half rasterline at the end of each frame _has to be_ skipped in order to force the rasterlines to match the the same frame type.
2. AFAIR the first cycle of rasterline 0 is available for normal calculations but it's skipped when doing raster irq. Is it true that this cycles is _always_ unusable for the processor? If so, why?
Quoting Groepaz...
what are you trying to do here anyway? =) No specific idea or piece of code in the making atm, it's more for "scientific reasons" ;) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I guess the first cycle of the first rasterline is used by vic to reset internal "counters and/or pointers" so the chip have no time free to check and set irq...
But this cycle still available to cpu if no sprites are active... |
... 11 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
