Clock ticks per scan line

[Tyrant]

Hiya, a late-night thought has got me thinking about how much time there really is in a Jaguar, and specifically how many clock cycles there are per scanline of video (for the main chips, I know the 68k is at one-half the clock rate).

 

I did some incredibly crude calculations (that didn't account for blanking time) and came out with a value of approximately 850, but I'm sure I'm wrong, so can anyone give me a better answer for how many clock cycles there are per scanline?

[Zerosquare]

851 for PAL mode, 845 for NTSC mode

 

They are system clock cycles ; if you want to compute timings on the 68k, divide that number by two since its clock frequency is only half of the rest of the system. If you use RAM and/or other processors, you have to take into account bus priorities issues and RAM latency & refresh time as well to know how much code you can run during the duration of a video line.

[Tyrant]

851 for PAL mode, 845 for NTSC mode

 

They are system clock cycles ; if you want to compute timings on the 68k, divide that number by two since its clock frequency is only half of the rest of the system. If you use RAM and/or other processors, you have to take into account bus priorities issues and RAM latency & refresh time as well to know how much code you can run during the duration of a video line.

That's what I got, but I assumed it couldn't be that simple.

[Zerosquare]

You're right, it's not that simple, I made a mistake Sorry ! (thanks to SCPCD for noticing it).

 

It's actually 1702 cycles for PAL, and 1690 for NTSC. I used the horizontal period register value as a basis, but forgot that it was the duration of a half-line, not of a complete line.

[Tyrant]

I used the horizontal period register value as a basis, but forgot that it was the duration of a half-line, not of a complete line.

Hmm... interesting.

 

My calculations were Video Clock (techref p.5) divided by framerate divided by number of scanlines.

PAL:

(26.5939 * 10^6) / 50 / 625 = 851.0048

NTSC:

(26.590906 * 10^6) / 60 / 525 = 844.15575...

 

Also today I ran a simple test, creating a short object list of one 640 wide 16bpp bitmap, and one 80 wide 16bpp bitmap scaled to 640, and found I was getting occasional flicker on the display (the scaled object was getting a line chopped out of the (vertical) middle, at a non-constant position) which I took to mean the OP was running out of time but only just.

 

When we do the maths, we find it should take: (640 * 0.5) + (640 * 1) = 960 ticks to draw that, assuming ideal conditions. If we only had 851 ticks (I only tested under pal) that would seem to make sense to me in a way that 1702 does not.

[Zerosquare]

My calculations were Video Clock (techref p.5) divided by framerate divided by number of scanlines.

PAL:

(26.5939 * 10^6) / 50 / 625 = 851.0048

NTSC:

(26.590906 * 10^6) / 60 / 525 = 844.15575...

Ah, you've made a small mistake

625 (or 525) is the number of lines per frame, but 50 Hz (or 60 Hz) is the field frequency. As a frame is made of two fields, there's a 2x factor you have to include.

 

Another way to get the result is to consider the horizontal video period : 64 µs for PAL, 63.555... µs for NTSC.

That gives us (26.5939 * 10^6) * (64 * 10^-6) = 1702.0096 for PAL (rounded to 1702), and (26.590906 * 10^6) * (63.555... * 10^-6) = 1689.98503083 (rounded to 1690).

 

Also today I ran a simple test, creating a short object list of one 640 wide 16bpp bitmap, and one 80 wide 16bpp bitmap scaled to 640, and found I was getting occasional flicker on the display (the scaled object was getting a line chopped out of the (vertical) middle, at a non-constant position) which I took to mean the OP was running out of time but only just.

 

When we do the maths, we find it should take: (640 * 0.5) + (640 * 1) = 960 ticks to draw that, assuming ideal conditions. If we only had 851 ticks (I only tested under pal) that would seem to make sense to me in a way that 1702 does not.

For OP time calculations, SCPCD is the person to ask

[Tyrant]

Ah, I get it now.

 

Thank you both.

 

Although...

 

I suppose the reason 960 into 1702 doesn't go is because I wasn't accounting for the time taken to fetch the data (or fetch / process the two object definitions).

 

But then again, the OP is supposed to be able to fetch data (at 2 ticks per fetch if there isn't a column select involved) while it's busy expanding the data it's already got. At 16bpp unscaled, it takes it two ticks to write out one phrase, so if it can fetch stuff exactly in the background, it reads as fast as it writes.

 

I don't entirely get it.

 

Also while this isn't exactly a stress test, the 68k shouldn't be interrupting anything since the OP hangs onto the bus while it's running, and the graphics are in main ram, so the OP can have all the time it needs.

[SCPCD]

With calcul I think that this should work.

 

I will make some test with a logic analyzer this week-end, I don't know extacly the comportement of the OP with zoomed object.

 

This would give more informations than the Techrefs

 

[Tyrant]

I will make some test with a logic analyzer this week-end, I don't know extacly the comportement of the OP with zoomed object.

Thanks, that would indeed be very useful, and I don't have the faintest idea how to go about using a logic analyser (or the time to learn right now).

 

Oh, and if, while you're doing that, you have time to test RMW objects too (both unscaled and scaled) it would be very useful to me.

[SCPCD]

Hi,

 

You will find description timing of different 16-bit Object here : Op Timing

 

I try to make a test drawing simultaneously on a 640x240 16-bit screen that is correctly drawed :

- 2 branch object : 4+4 = 8

- one width 640pix 16-bit bitmap unscaled : 7+(2+(160-2)*3+5)+4 = 492

- one width 320pix 16-bit bitmap scaled x2 : 10+665+4 = 679cycles (include refresh)

- stop object : 10cycles

 

=> total = 8+492+679+10 = 1189cycles

 

there is about 1702 - 1189 = 513 free cycles

 

 

 

 

[Tyrant]

You will find description timing of different 16-bit Object here : Op Timing

 

That looks to be fantastically useful info, not just for me but for everyone, thank you.