+----------+--------+-------+---------+---------+---------+------------+ | 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 | +----------+--------+-------+---------+---------+---------+------------+
no.of rasterlines per frame = floor([no.of interlaced lines in the discussed TV-Norm]/2),
... what are you trying to do here anyway? =)
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?