| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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: 466 |
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: 11100 |
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: 421 |
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: 11100 |
also, the last (or first?) scanline is one cycle shorter (on NTSC only perhaps, i forgot) |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
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: 11100 |
as for tolerance... couldnt find a datasheet quickly, but it should be somewhere in the 20..30PPM range |
| |
tlr
Registered: Sep 2003
Posts: 1702 |
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: 11100 |
oh really =) didnt expect it to be THAT bad =D |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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: 442 |
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... |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting Copyfault1. 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.
Old monitors are much dumber than you think. They're just electron guns firing at phosphor screens, and the C64's video signal controls the gun movement. It's all analog, and *timing* is what matters to generate a stable image. The NTSC standard mandates alternating 262/263 line frames at a specific rate, but the C64 is out of spec and doesn't follow that. It could probably get away with sending 260 or 265 lines per frame too on most monitors.
Quote: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?
Cycle 0/0 is available to the 6510, unless you have sprite 3 enabled in which case DMA uses that cycle.
The special case with line 0 is that raster IRQs are triggered a cycle later than on other lines. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: 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!
Can you guys help me fill in a complete table f.e. with for the following VICE types c64/c64c/c64old, ntsc/newntsc/oldntsc, drean, jap, c64gs, pet64, ultimax?
Specifically, master clock frequency, number of cycles per raster line and frame rate. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
TLL pointed me into the correct direction: https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/sr..
So four different types to handle:
C/Line Lines Clock
PAL 63 312 985248
NTSC 65 263 1022730
Old NTSC 64 262 1022730
DREAN 65 312 1023440
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
My (at least in VICE) functional detection code:
; C/Line Lines Clock Val
;PAL 63 312 985248 516%312 = 204 cc
;NTSC 65 263 1022730 508%263 = 245 f5
;Old NTSC 64 262 1022730 512%262 = 250 fa
;DREAN 65 312 1023440 508%312 = 196 c4
;
;16384/63 = 260+256 = 516
;16384/64 = 256+256 = 512
;16384/65 = 252+256 = 508
.segment "START"
.export systemDetect
.proc systemDetect
sei
lda #0
sta $d011
sta $dc0e
sta $dc0f
bit $d011
bpl *-3
bit $d011
bmi *-3
lda #$7f
sta $dc0d
bit $dc0d
lda #<(16384-1)
sta $dc04
lda #>(16384-1)
sta $dc05
lda #%10011001
bit $d011
bpl *-3
sta $dc0e
:lda $dc0d
beq :-
lda $d012
; cc => PAL
; f5 => NTSC
; fa => Old NTSC
; c4 => DREAN
rts
.endproc
|
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Interesting approach you took there, quite elegant. :)
Is this for your game? And do you really want to support all these platforms, including the weirder ones? I didn't even know PET 64 existed. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Interesting approach you took there, quite elegant. :)
Is this for your game? And do you really want to support all these platforms, including the weirder ones? I didn't even know PET 64 existed.
For Eye of the Beholder. And no I don't HAVE to support them, but if it's a matter of simple detection and a few patches here and there, why not? Let's not be lazy here when I've been honoring details on everything else.
Basically I just need to know the master clock to set the correct master game timer (55ms ticks). Then I need to know cycles per line (63 / 64 / 65) for the raster code in the intro. The above code gives me all the info I need. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
All contributions welcome:
http://codebase64.org/doku.php?id=base:detect_pal_ntsc
:) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: All contributions welcome:
http://codebase64.org/doku.php?id=base:detect_pal_ntsc
:)
Not much to contribute imo. My method is not better than the others and I just forgot about checking Codebase first. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
As far as c64gs goes I don't know if gs had any other version than PAL, all I've got is PAL anyway. If you like to detect it, it has different ROM so this is probably the easiest method to check for it. Probably due to lack of keyboard and tape port someone could come up with some clever method of detecting it otherwise but VIC timing still should be the same as for c64 PAL and ROM check method may probably fail in case of VICE or any other emulator I guess there aren't many users with c64 and kernal switch including gs ROM ;)
BTW: care to tell us more about PET 64? |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: As far as c64gs goes I don't know if gs had any other version than PAL, all I've got is PAL anyway. If you like to detect it, it has different ROM so this is probably the easiest method to check for it. Probably due to lack of keyboard and tape port someone could come up with some clever method of detecting it otherwise but VIC timing still should be the same as for c64 PAL and ROM check method may probably fail in case of VICE or any other emulator I guess there aren't many users with c64 and kernal switch including gs ROM ;)
BTW: care to tell us more about PET 64?
I will not need to detect GS. Pet64, dunno, just copied the values from VICE |
| |
Count Zero
Registered: Jan 2003
Posts: 1820 |
I own an Educator64 (or PET64 or ...) - it is very heavy! :)
https://en.wikipedia.org/wiki/Commodore_Educator_64 |
