NTSC

rjo__

At this point there is so much I don't know that I have some difficulty formulating a reasonable question:)

I think I have one.

I have gone back through this forum twice. If it is here, I don't see it.

I have some nice NTSC sample code from Tubular, Potatohead, Baggers etc.

What I don't see is a full NTSC driver for a de0... I don't care if it displays black, with a little window for actual data.
I have the 256x192x8bit_grey displaying very nicely... but it fills the whole screen. How do I get it to just display the 256x192 in the middle of a full NTSC screen?

Thanks
Rich

Tubular

Hi Rich

I don't have time to do this right at the moment, but what you need to do is reduce the Video circuit "clocks per pixel" from 9 to say 3, and then compensate 3x to keep the timing the same overall. An easy way to start might be to repeat the same data three times (resulting in 3 compacted images across the screen), or replace the first and third with black, for instance. Then move on to modifying the vertical in a similar way

rjo__

Tubular,

Thanks.

That's as much help as I actually wanted unless someone had the code ready to go.
I think I have tried everything you suggested... but who knows for sure?

Happy coding

Rich

ozpropdev

Hi Rich

Here is example of what Tubular was talking about.
In this example of VGA 800x600 I am placing 6 separate panels within that window.
Each panel is 256 pixels wide with 2 16 pixel black edges.
The key is that the total clock count is 800 (for 1 clock per pixel)
As long as the clocks add up to the correct width of your video mode, you can position your image where you want.
Here is a sample of my pixel output code

send_pixels		call	#sync			'do horizontal sync

			waitvid	edge,#0
			waitvid	mode1,char_color
			waitvid	mode2,char_color4
			waitvid	mode3,char_color2
			waitvid	edge,#0

edge			long	pixel_base << 24 + $7 << 20 + 1 << 13 +	16
mode1			long	pixel_base << 24 + $7 << 20 + 1 << 13 +	256
mode2			long	32 << 24 + $7 << 20 + 1 << 13 +	256 '288
mode3			long	(pixel_base+8)  << 24 + $7 << 20 + 1 << 13 + 256

Hope this helps
Cheers
Brian

Ariba

Here are two of my PAL drivers changed to NTSC and adapted to the new clkfreq.

Because rjo_ likes grayscale, the first one is a 256x100 grayscale driver.
The second is a modified version of Baggers Fire demo (256x100 with colours).

Andy

Tubular

Andy,

Can you add the fire.bin.pal.bin file it's looking for? Look forward to seeing that fire.

thanks
Lachlan

Ariba

Tubular wrote: »

Andy,

Can you add the fire.bin.pal.bin file it's looking for? Look forward to seeing that fire.

thanks
Lachlan

Okay it's added to the prevoius post
Enjoy

Andy

Tubular

Thanks for that file Andy

That fire effect is brilliant. Thanks Baggers!.

I have a P2 WS2812B driver and many 150 pixel long led strips coming... will be interesting to scale it up

cheers
Lachlan

Baggers

No probs Tubular

I missed this post, glad I checked it out

rjo__

Golly,

This makes me look ungrateful. In my defense, this conversation was continued in a different thread.

Just as an update, I have NTSC working as I want it… but the only way that I can use it with a camera is to put the camera first, fill a buffer… and then display it…. which means that
I would have to reboot to take another picture.

Multithreading is a no brainer… once you look at it carefully, but making NTSC multithreading in 8 bit gray scale would require me to actually understand all of the code I am using… and … and …. nope:)

Rich