Subject: RE: [TI994A] NTSC vs PAL

From: Brian Tristam Williams <[email-masked]>
Date: Fri, 13 Nov 2009 12:17:15 +0200

I don't have time to jump right in to all of your question, but PAL is 625*25 = 15 625 lines per second, and NTSC 525*30 = 15 750.

I've never seen the NTSC output, but the 50Hz console only outputs fields (half-frames) of 312,5 lines, 50 times a second. It is not interlaced cos the timing's funny - always made it difficult to record to VHS. About 25 of those are blanking. 192 are addressable pixel rows. The rest (approx. 100 lines) are used as filler in background colour. That makes the PAL image considerably more squashed - draw a circle and you'll get an ellipse.

-----Original Message-----
From: kabldb <[email-masked]>
Sent: 13 November 2009 10:20
To: [email-masked]
Subject: [TI994A] NTSC vs PAL

If the no. of scanlines is 525 and 625 for NTSC and PAL respectively, then that is 31,500 (525*60) and 31,250 (625*50) lines per second. I gather almost the same video out work ?

 Anyways, the TI screen resolution output is fixed at 192 lines, so software don't have to care about how things look, but things might move slightly faster (20%) or slower (16,67%). A PAL developer has to be aware of the limited CPU available with a NTSC frame. But how much is that with a display enabled ? Is there actually 100 lines of vertical blank space to do good with ?

 :-)

 ref.:
http://www.ihffilm.com/videostandard.html

 --- In [email-masked], "Tursi" <yahoogroup@...> wrote:
 >
 > >Anyone got a PAL TI to try this on?
 > >I think the PAL VDP is clocked slower... It runs at 25 frames p/s, not
 > >30...
 >
 > 50 frames per second, but yes, slower. The MSX guys see the difference,
 > too. This is pretty much non-disputed.
 >

Reply to sender

[The entire original message is not included]

---

From: "Tursi" <[email-masked]>
Date: Fri, 13 Nov 2009 05:34:31 -0500

It actually outputs 313 full lines in PAL, no half lines from the VDP, 
at least according to the datasheet. That, and the lack of interlacing, 
causes the problems with some devices. NTSC is the same way, but does 
262 lines. The datasheet spells out the exact purpose of every scanline 
for NTSC but doesn't bother to give that information for PAL, it only 
mentions the total count.

----- Original Message ----- 
From: "Brian Tristam Williams" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 13, 2009 5:17 AM
Subject: RE: [TI994A] NTSC vs PAL

I don't have time to jump right in to all of your question, but PAL is 
625*25 = 15 625 lines per second, and NTSC 525*30 = 15 750.

I've never seen the NTSC output, but the 50Hz console only outputs 
fields (half-frames) of 312,5 lines, 50 times a second. It is not 
interlaced cos the timing's funny - always made it difficult to record 
to VHS. About 25 of those are blanking. 192 are addressable pixel rows. 
The rest (approx. 100 lines) are used as filler in background colour. 
That makes the PAL image considerably more squashed - draw a circle and 
you'll get an ellipse.

---

From: mark wills <[email-masked]>
Date: Fri, 13 Nov 2009 02:51:59 -0800 (PST)

LOL! I thought you were in bed!!!

>
>From: Tursi <[email-masked]>
>Sent: Fri, 13 November, 2009 11:34:31
>Subject: Re: [TI994A] NTSC vs PAL
>
> >
>
>
>
>
>  >
>>      
> 
>>From: "Brian Tristam Williams" <briantw@briantw. com>
>>To: <TI994A@yahoogroups. com>

---

From: Brian Tristam Williams <[email-masked]>
Date: Fri, 13 Nov 2009 13:32:35 +0200

Hi, if by "blank," you mean black or invisible, not so, they are there, but
in the current background colour. Not being anal, just that "vertical
blanking" has a specific technical meaning. But yeah, I don't see why you
couldn't do calculation during that time :)

2009/11/13 kabldb <[email-masked]>

>
>
> Excellent.
>
> 313 – 262 = 51 blank scanlines. When I wrote 100 extra lines, I forgot they
> are interlaced, so that would have been 50 extra lines per frame. Close.
>
> As I understood the CPU can't write to (or read from) VDP as fast when the
> VDP is drawing the screen image (192 scanlines). Apart from some vertical
> retrace, reset etc., I'll jump right into it ... Please correct me if I'm
> wrong.
>
> NTSC
> 262 – 192 = 70 vertical blank scanlines.
>
> PAL
> 313 – 192 = 121 vertical blank scanlines.
>
> That's almost 73 percent more blank scanlines for PAL to do some heavy CPU
> calculations and VDP modifications within. That's something !? - I know I'm
> not considering the 192 scanlines plus vertical retrace etc.
>
> I would assume NTSC people wouldn't like demos (and games) taking too much
> advantage of this.
>
> Wonder if some MSX1 demos (like "bold") rather counts on the lower PAL fps.
>
> ;-)
>
>
> --- In [email-masked] <TI994A%40yahoogroups.com>, "Tursi"
> <yahoogroup@...> wrote:
> >
> > It actually outputs 313 full lines in PAL, no half lines from
> > the VDP, at least according to the datasheet. That, and the
> > lack of interlacing, causes the problems with some devices.
> > NTSC is the same way, but does 262 lines. The datasheet
> > spells out the exact purpose of every scanline for NTSC but
> > doesn't bother to give that information for PAL, it only

-- 
Brian Tristam Williams

"One man can make a difference."

---

From: "Tursi" <[email-masked]>
Date: Fri, 13 Nov 2009 12:06:00 -0500

>When I wrote 100 extra lines, I forgot they are interlaced, so that 
>would have been 50 >extra lines per frame. Close.

It's not interlaced on the TMS99x8.

>As I understood the CPU can't write to (or read from) VDP as fast when 
>the VDP is drawing the screen image (192 >scanlines). Apart from some 
>vertical retrace, reset etc., I'll jump right into it ... Please 
>correct me if I'm wrong.

The CPU is free to go ahead and try. The VDP needs longer to actually 
process the request while it's drawing. So if the CPU accesses the VDP 
too fast, it will miss accesses. There's no circuitry to halt the CPU or 
even detect that the miss occurred. So for instance, if you write 3 
bytes too quickly, the VDP might actually only see 2 of them, and 
there's really no way to know (I guess you could read back the VDP 
address and make sure it's what you expect.)

>couldn't do calculation during that time :)

Yeah, the datasheet does say that if the blanking bit is set, you get 
background color over the visible area and still have no wait for CPU 
access, and that the same is true during vertical blank, so they SHOULD 
be available.