I have now joined the "Dark Side".

Atomic Zombie

Ok, that may be a little dramatic, but I have been burnin' PICs for the last 3 years. I love pushing minimal components to the max such as my video TicTacToe game in picbasic pro - yes video generation in basic, even crude overlay! I also run all my robots with picbasic pro and a pic16f84....

http://www.atomiczombie.com/book-robots.htm

Both bots have a pic decoding RC signals and controlling motors / peripherals.

I am awaiting my SXKey (Wahoo!), and will be soon porting all my code to the sx28. I also plan on converting my video generation code to SXB, and will post it if anyone is interested. The SX seems to be the way to go for speed intensive apps and pushing the limits - the poor old PIC just barely gets by on some of my projects.

Future projects include....

- Text overlay done in SXB (did a crude version in PicBasic Pro on a 16f628 @ 20Mhz)
- Basic STV5730 OSD chip emulation
- SPO256 speech IC emulation
- Hardware keylogger for PC

Anyhow, thanks to all who post on this forum, and to Parallax for putting the power into the hands of the hardware hacker!

Hope to get hacking the minute my SXKey arrives.

Brad

·

Jon Williams

Not the dark side at all ... you have finally come into the light!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Post Edited (Jon Williams (Parallax)) : 9/9/2005 10:33:48 PM GMT

Atomic Zombie

Yeah, I submit! I will probably still have most of the parts in the bubble wrap when I burn my first program - I already started coding, and I don't even have the SXKey yet!

2 large coffees, and a few hours should yeild some decent video bandwidth on my test monitor·- not the postage stamp sized pixels I am getting out of my 16f series·with picbasic. If all goes well, I might even start digging into quadrature modulation for color signals - hmmmm, that will require a LOT of large coffees.



Cheers,
Brad

Jon Williams (Parallax) said...
Not that dark side at all ... you have finally come into the light!

Bean

Brad,
Check out my video module using the SX28 at http://www.sxvm.com
It's open source too.

And I'm very close to finishing a video overlay module using the SX48.

Good to have you "on-board",
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available soon!! Video overlay(OSD) module...

"I'm a man, but I can change, if I have to, I guess"
Red Green
·

Atomic Zombie

Most excellent work! I see you also use the trusty old 1881 - great chip. Have you figured out how to get around the no input signal problem? I did this by using a pulsin on the vsync - if there was no sync, software generated a gray or gradient background.

I really think I can do full overlay using only the sx - no sync separator chip at all - almost pulled it off on a 20mhz pic16f628 using picbasic, but it was just too jittery. There should be enough bang in that sx28 to sample the sync signals, and then lock on to the incoming video. As for mixing, I just spit out a 1v signal right back into the output - made a nice crisp white overlay.

When I get set up, I will post my results - good or bad!

Thanks for the reply.

Brad

Bean (Hitt Consulting) said...
Brad,
Check out my video module using the SX28 at http://www.sxvm.com
It's open source too.

And I'm very close to finishing a video overlay module using the SX48.

Good to have you "on-board",
Bean.

Ken Gracey

Hi Brad,

I have your "All Terrain Robot" book. Just finished reading through it the last couple of evenings. My next robotic project is a similar tracked robot, designed for over-the-snow travel. A Honda gas engine is going to be coupled to a hydraulic motor, a few proportional/directional valves for hydrostatic steering (plus all the other stuff such as a tank, heat exchanger, etc). At the moment I'm sorting out the options for tracks, and leaning towards building my own instead of using snowmobile tracks. I'll be using some of the ideas in your book, but this time I want to take the step to welding aluminum instead of steel. I do everything very slowly, so this project will take me two years.

I can appreciate the Chop This book as well, having built a custom 13' unicycle for myself. Now that I have kids I can't ride it anymore, but selling it on eBay scares me even more due to liability.

Welcome to the forums and I'm glad you're now part of our action (and that we're part of your action!).

Ken Gracey
Parallax, Inc.

Atomic Zombie

Hey, thanks for your support! Didn't want to come in here and start honkin' my own horn about the book, but I'm glad you liked it, and hope to see your completed robot. I seen another unit using snowblower tracks and it did turn out to be a very rugged unit indeed. 2 - 130 rpm wheelchair motors, and a pair of simple 30 amp fet controllers.

I think Parallax has done a great job on this forum, and the support is just great -·looks like my PIC drawer is soon to be filled with SX28's instead. I am totally into software video generation, and hope to contribute to the wealth of great information already in this forum.

I have a copy of SXWIZ coming to me soon as well, and hope to give that a whirl - anyone here using it yet?

Cheers,
Brad

Ken Gracey (Parallax) said...
Hi Brad,

I have your "All Terrain Robot" book. Just finished reading through it the last couple of evenings. My next robotic project is a similar tracked robot, designed for over-the-snow travel. A Honda gas engine is going to be coupled to a hydraulic motor, a few proportional/directional valves for hydrostatic steering (plus all the other stuff such as a tank, heat exchanger, etc). At the moment I'm sorting out the options for tracks, and leaning towards building my own instead of using snowmobile tracks. I'll be using some of the ideas in your book, but this time I want to take the step to welding aluminum instead of steel. I do everything very slowly, so this project will take me two years.

I can appreciate the Chop This book as well, having built a custom 13' unicycle for myself. Now that I have kids I can't ride it anymore, but selling it on eBay scares me even more due to liability.

Welcome to the forums and I'm glad you're now part of our action (and that we're part of your action!).

Ken Gracey
Parallax, Inc.

Bean

Brad,
· As to the 1881. It works as it should. I tried to use the built-in comparitor, but it seemed that different input sources had to be tweeked to get a solid overlay. So I admitted defeat and used the 1881 [noparse];)[/noparse]

As for detecting when there is no input video.
I use the RTCC counter/timer.
The composite sync signal causes a hardware interrupt.
Inside the interrupt I reset the timer.
Then in the main loop (when I'm waiting for serial input), if bit 7 of RTCC is set, I know that too much time has passed without an interrupt, so I switch to "generate video" mode.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available soon!! Video overlay(OSD) module...

"I'm a man, but I can change, if I have to, I guess"
Red Green


Post Edited (Bean (Hitt Consulting)) : 9/12/2005 11:06:18 AM GMT

Atomic Zombie

Sounds like you have a mature well designed product there - hope I can say that after a few too many late nights this winter at the ol' workbench.· I have a future project that will require the sx to place an incomiing NTSC signal into the top right 1/4 of the monitor and then display some stats such as battery voltage, direction, etc in low res black and white. The display part, I know will be easy, it's the redrawing of the screen in 1/4 size that is going to be a task.

This process will be similar to how a video quad works, but I don't think I will need a frame buffer since there is only 1 incoming video signal - just a lot of fancy timing, maybe something like this....

wait for hsync
start grabbing·the picture information for aprox every second sample on the incoming BW camera
redraw the video onto the top left of the target monitor for half the line or aprox 300 pixels
start drawing stats on the other half of the line
continue until vsync pulses sent from camera

If this does not work, then I will have to store the picture information in memory in a 256x256 box, and redraw it later. This gets a lot more complex, but will then let me use a vga monitor rather than NTSC monitor - much easier to software generate color on a VGA monitor.

Maybe we could start a thread for software generated video - there seems to be a lot of call for this on the piclist. It would be easy to convince a few 16f people to convert!

Cheers,
Brad

Bean (Hitt Consulting) said...
Brad,
· As to the 1881. It works as it should. I tried to use the built-in comparitor, but it seemed that different input sources had to be tweeked to get a solid overlay. So I admitted defeat and used the 1881 [noparse];)[/noparse]

As for detecting when there is no input video.
I use the RTCC counter/timer.
The composite sync signal causes a hardware interrupt.
Inside the interrupt I reset the timer.
Then in the main loop (when I'm waiting for serial input), if bit 7 of RTCC is set, I know that too much time has passed without an interrupt, so I switch to "generate video" mode.

Bean.

Paul Baker

Interesting project Brad.

If Ive thought this through properly, your application will require a frame buffer.

First if you place the input video into the 1st, 2nd or 3rd quadrants (upper right, upper left, lower left) you will have a frame delay of one, because the input video wont present its current frame's lower right pixel until the very last pixel, but you will need to place it in the output video before then. If you place it in the 4th quadrant (lower right) there is no needed frame delay, but you need to store pixels for the output. It turns out regardless of which quadrant you'll need to store roughly the same amount of data. In the 4th quadrant, youll need to store the first half of the subsampled pixels (ballparked, theres the question of the first half of the next row, after the pixels are placed in the output frame the storage can be reused).

If the input video is sampled into 320x240 and subsampled to 160x120, the first half subsampled frame will need storage or 80x120 or 9600 pixels. Using 256 bytes on the SX52 (theres a few more but your program will need its own variables) thats 2048 bits, so not even a black and white rendering is possible. A 40x30 (1/16th) frame would require 600 pixels of storage enabling 3 bits of greyscale per pixel.

So you see, your going to require more than 8K for 8 bit greyscale, or half for 4 bit. But the SX48/52 is fast enough to access external fast SRAM (and enough pin out to not require external logic) with time to spare.

If you want a simple memory layout (each pixel has a unique storage location) it will require 19200 bytes for 8bit, 9600 for 4 bit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 9/12/2005 8:16:06 PM GMT

Atomic Zombie

Yes, now that I have had some time to sketch this down, I see what you mean. If I had no frame buffer, all I could really due is blank part of the screen - not compress it. I did find one other way to place a live image in the upper left quadrant while being able to fill the other three quadrants with info, although it is a bit ugly....

Since the 1/4 size resulting video will have a resolution of 300x200 pixels at best, why not just pass the entire ntsc signal from the camera's input out to the destination output then mask right over the signal? Yes, this would waste most of the cameras image, but it would end up doing the same thing as compressing the image. So it goes like this...

wait for vsync - start loop
wait for hsync then wait for half of the image to be drawn, or about 400 pixels
software generate·the info for the first quadrant - top right
once 200 lines or so have passed, generate the other two quadrants
start over

Yes, this is really just an overlay that·leaves 1/4 of the incoming camera signal unmasked, but it would really do the same thing as my first idea. The only con is that you would have to remember to aim the camera slightly to the left since only 1/4 of it's ccd will be used.

Thanks for all the great ideas - I now have a rough plan on how to attack this project. Should have the SXKey in a week, so I will post my results - if there are any [noparse]:)[/noparse]

Next project - to generate color video using the ad725 IC....
http://www.analog.com/en/prod/0,2877,AD725,00.html
This IC looks very promising.

Cheers,
Brad

Paul Baker said...
Interesting project Brad.

If Ive thought this through properly, your application will require a frame buffer.

First if you place the input video into the 1st, 2nd or 3rd quadrants (upper right, upper left, lower left) you will have a frame delay of one, because the input video wont present its current frame's lower right pixel until the very last pixel, but you will need to place it in the output video before then. If you place it in the 4th quadrant (lower right) there is no needed frame delay, but you need to store pixels for the output. It turns out regardless of which quadrant you'll need to store roughly the same amount of data. In the 4th quadrant, youll need to store the first half of the subsampled pixels (ballparked, theres the question of the first half of the next row, after the pixels are placed in the output frame the storage can be reused).

If the input video is sampled into 320x240 and subsampled to 160x120, the first half subsampled frame will need storage or 80x120 or 9600 pixels. Using 256 bytes on the SX52 (theres a few more but your program will need its own variables) thats 2048 bits, so not even a black and white rendering is possible. A 40x30 (1/16th) frame would require 600 pixels of storage enabling 3 bits of greyscale per pixel.

So you see, your going to require more than 8K for 8 bit greyscale, or half for 4 bit. But the SX48/52 is fast enough to access external fast SRAM (and enough pin out to not require external logic) with time to spare.

If you want a simple memory layout (each pixel has a unique storage location) it will require 19200 bytes for 8bit, 9600 for 4 bit.

Bean

Brad,
Have you checked out the xgamestation that Parallax sells ?
I think you would have a ball with it...
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available soon!! Video overlay(OSD) module...

"I'm a man, but I can change, if I have to, I guess"
Red Green
·

Atomic Zombie

That is a beautifull product - in fact the reason I switched from PIC to SX. Makes one wonder why I would attempt to design my own video signal generator when such a mature product is already available... well, I'm just crazy like that!

I will probably purchase the XGS soon, but first I am must succeed in generating a good video signal from my sx28. I just received my sxkey and IC's today, so my second project (right after the required led blinker) will be the conversion of my PIC16f628 vga message generator to sxb. The final project will decode the standard AT keyboard and display the pressed·letter or number·on the screen of a standard VGA monitor. It has no real purpose besides learning how to generate VGA signals and decode the serial AT keyboard. Think of it as "The World's Most Useless Single Chip Computer".

Currently, the PIC16f628 was not fast enough to do both - I could decode an AT keyboard and store the data in an eeprom, or generate simple color VGA, but not at the same time. I think my SX28 buddy is going to fix that problem for me!

I will post the schematic, and source code for this when it is ready.... see you then.

Thanks for all the info.
Brad
SYS64738

Bean (Hitt Consulting) said...
Brad,
Have you checked out the xgamestation that Parallax sells ?
I think you would have a ball with it...
Bean.

Forrest

Another good source of information on generating video with a PIC and an SX is www.rickard.gunee.com/projects/

I've built both the black and white PIC Game system and the color SX Game system and both work great. I think it's amazing he was able to do color graphics, music and joystick input using just a SX28.

BMM

Hi,
At least ·you should·· get the xgs· cd··· it has a wealth of information. I ··bought···· the xgs cd ,· sxkey and· the guenther’s book· from· xgamestation.com. Also ·you can go· to www.xgamestation.com ·and download several chapters· specially the chapter 11.
I am too , new to sx micro···and a very loyal pic user for around 4 years. But I think·· now is the time· to jump in to the sx world.
Regards
bmm ···

Atomic Zombie

Yep, I use the NTSC timing info on his page often! Well, it's been 3 days since I connected my sxkey, and so far have been able to generate basic NTSC video, and a simple overlay using an lm1881 - much easier in SXB than picbasic on a 16f628. My next goal is to eliminate the lm1881 and use the sx comparator instead - just look for the negative sync pulses and count the pulse width looking for the equalization pulses to lock on to. Why use a sync sepparator IC when the sx can do it already? After all the lm1881 is nothing more than a few comparators and some logic.

When I have some time I will post all of the code and info on my site. In the end I hope to have a nice character overlay using nothing more than an sx and some basic semiconductors.

Brad

Forrest said...
Another good source of information on generating video with a PIC and an SX is www.rickard.gunee.com/projects/

I've built both the black and white PIC Game system and the color SX Game system and both work great. I think it's amazing he was able to do color graphics, music and joystick input using just a SX28.