NTSC

rjo__ · 2013-10-21 05:41

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 · 2013-10-21 15:25

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__ · 2013-10-21 15:47

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 · 2013-10-21 18:05

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 · 2013-10-21 20:39

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 · 2013-10-21 21:48

Andy,

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

thanks
Lachlan

Ariba · 2013-10-21 22:03

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 · 2013-10-21 22:31

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 · 2013-11-17 05:59

No probs Tubular

I missed this post, glad I checked it out

rjo__ · 2013-11-19 18:58

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

NTSC

Comments