| |
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! |
|
... 11 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
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: 2014 |
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: 2014 |
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: 2014 |
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: 2980 |
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: 2014 |
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: 1648 |
All contributions welcome:
http://codebase64.org/doku.php?id=base:detect_pal_ntsc
:) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
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: 299 |
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: 2014 |
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 |
| Previous - 1 | 2 | 3 - Next |
