When the prop 2 comes out I bet this driver would be the basis of alot of programs. you know when it comes out,if you used two of the prop 2's anything would be possible with the addition of SRAM and SD storage! [noparse]:D[/noparse]
Wow, baggers I can't wait to see what you make next!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Realize that I am really a mad scientist··· and
JT Cook said...
Ok, thats not cool. You updated your avatar showing off your driver, but didn't upload a new screenshot
Anyway what is the horizontal resolution you are running it at?
lol Sorry [noparse]:)[/noparse] I've added the new screenshot [noparse]:)[/noparse]
The display·res is 288x222, can be larger though, as there's blank screen area on right edge, and the bottom
When the prop 2 comes out I bet this driver would be the basis of alot of programs. you know when it comes out,if you used two of the prop 2's anything would be possible with the addition of SRAM and SD storage! [noparse]:D[/noparse]
Wow, baggers I can't wait to see what you make next!
I wouldn't be surprised if Chip is wiring them up as we speak to a Component·layout, as they don't have scart over the water [noparse]:)[/noparse]
But yeah, I can't wait to have access to one of those prop 2 puppies, let alone two [noparse]:)[/noparse] that would be sweet.
Baggers said...
lol Sorry [noparse]:)[/noparse] I've added the new screenshot [noparse]:)[/noparse]
Baggers, you're just showing off now with your fancy dan display driver lol
Seriously though, I hope Parallax do sit up and take notice of you and a few other of the top guys on this forum and get you involved in beta testing the Prop2.
If this is what you can do with Prop1 after a few months what will you do with Prop2! I am drooling with anticipation lol
Yeah, that would be excellent, to be involved in beta testing the prop2 [noparse]:)[/noparse] to anyone at parallax reading this, If you'll have me, deffo put me down for Prop2 beta testing [noparse];)[/noparse]
True, I've not had the prop that long, I just love the rawness of it, and it's simplicity and ease of use, and it's multi-cog technology just puts it way infront of any competition.
Baggers, that is cool! And you did this without external ram or video chips?! Very cool, this IS the example of what the Prop is capable of!
BTW, might 45 I/O lines and two cores interest you? I've been tooling with a design for a few weeks now and thought it'd be fun to see what others thought of the concept & design. The schematics are attatched to the post hyperlinked above, still need a spot of pollish, but feel free to use them in your design if you feel they're up to snuff.
DVI does have RGB but i think it's more akin to VGA RGB than SCART's RGB, the timings can't possibly be the same though, that would just be too easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ E3= Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! The average PC while browsing the internet typically uses less than 30% of it's potential, why not donate a portion of the rest for cancer resaerch?
<FONT color=blue>DVI[noparse][[/noparse]/color] does have RGB but i think it's more akin to VGA RGB than SCART's RGB, the timings can't possibly be the same though, that would just be too easy.
I don't know much about DVI but I do know VGA monitors will sync to a wide variety of input signals. CRT's will sync to nearly anything, but newer LCD monitors might be more picky.
I use RGB color on my compy monitor! [noparse]:D[/noparse] Maybe that would work with this driver? I'm not sure which plug is RGB though...can someone draw a picture so I can confirm?
Is it possible for you to make a NTSC or VGA version of this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Realize that I am really a mad scientist··· and
There are some rgb to composite decoder chips on the market. Looking through the datasheet shows it is not the simplest thing to use, but may be worth a gander. I have never used one, so whether it would be an acceptable solution for conversion is questionable. Anyway, here is the datasheet if someone wants to have a look.
Sorry for the late reply, been to a wedding today [noparse]:)[/noparse]
mpark: lol [noparse];)[/noparse]
Rinks: thanks [noparse]:)[/noparse] and yes, it's without extra ram or video chips, it's just the prop, and a few resistors [noparse]:)[/noparse] I'll have a good look at your design tomorrow, back of out in a mo, for the evening section, just came home to put the girls to bed, and have grandparents come round to mind them while we go back out.
Potatohead: 400 colours from 3 resistors is still an amazing feat [noparse];)[/noparse] like you say, it shows the uber-coolness of the prop.
Dennis: I think i'll be going the AD725 route, for compatibility, as most have tv access, than a spare monitor. ( I'm assuming anyway lol )
Bob: if I use the AD725, it'll be NTSC and PAL.
Hi Kelvin, yeah I'm looking into AD725's too, might be the easiest way to go, to allow Composite use for the US.
JT Cook said...
Baggers: Are you using the video serializers at all or are you doing the timing by counting assembly clocks or something else?
JT Cook: I'm not using the video serializers at all, didn't think they could cope sending 24bits + sync. it's all assembly bit banging for video, ( well I suppose it's more long banging, rather than just bit banging. ·) and waitcnt for sync timing.
Just I'm thinking in digitalize a·"RGB" video signal, I thought that to scan a "H" line of the video of 64uSeg each, ·I would have about only 5120 clock cycles (at 80Mhz clock) to do that··, that means I could take·only a few samples per line, due an assembly intruction like "wrbyte" takes me about 7 to 22 clock cycles to get the data saved in memory. If you add to that process only a few more instructions "like to clock the A/D"...
I found that maybe I could take no more than 90 samples per line, and that is slower resolution than you got in your sample picture
Could you give me an idea of..How do you get such resolution in your picture? or What I'm thinking wrong in it ?
Maybe you are using some method that is unknown for me...
Hi BTX,
Thanks for the compliments [noparse]:)[/noparse]
yes, Hscan is 64us, giving you ~1280 instructions since each cog is running at 20mips. but ~14us is used up on sync and front and back porches. so it gives you ~50us which gives you ~1000 instructions. rdlong is like two instructions timewise, then add to source pointer, and djnz for loop altogether takes around 4 instructions worth, giving you ~256 samples but it's a bit more, cos the rdlong takes ~7 clocks not 8 ( since we're not using another read within the hub access time or whatever the correct technical term for each cog's turn lol ). so makes it up to ~320.
Hope this helps, you and anyone else for that matter. [noparse]:)[/noparse] since this is a great forum helping others learn too.
Baggers.
Thanks so much again Baggers.
You're right....but I will waste some more "clock cycles" to get the A/D clock....same, I could take a enough quantity of samples for my application.
One idea... let me know If I'm wrong please... What about to use the COG RAM during the image time to get the data ?? Could be only 4 clock cycles instead 7...
Maybe that memory could be refreshed with new data from main memory before need it in the following "H" line ...
In my case, of taking about 200 samples each H line, and then jumping next "two H lines" to take my new samples...I could have time todo so...don't you ?
I also will have enough COG memory to do that... That only increases my "H" resolution, not "V"
What do you think about this.
Yeah, I guess you could run a scan line or two behind, depending on how many cogs you use to read a line at a time, then copy it to hubram ready for the renderer, like the scanline renderers already do.
Comments
edit: As you can tell, i like thinking outside the box.
Anyway what is the horizontal resolution you are running it at?
Wow, baggers I can't wait to see what you make next!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
The display·res is 288x222, can be larger though, as there's blank screen area on right edge, and the bottom
But yeah, I can't wait to have access to one of those prop 2 puppies, let alone two [noparse]:)[/noparse] that would be sweet.
Baggers, you're just showing off now with your fancy dan display driver lol
Seriously though, I hope Parallax do sit up and take notice of you and a few other of the top guys on this forum and get you involved in beta testing the Prop2.
If this is what you can do with Prop1 after a few months what will you do with Prop2! I am drooling with anticipation lol
Well done Baggers, A++ Top of the class
Coley
Yeah, that would be excellent, to be involved in beta testing the prop2 [noparse]:)[/noparse] to anyone at parallax reading this, If you'll have me, deffo put me down for Prop2 beta testing [noparse];)[/noparse]
True, I've not had the prop that long, I just love the rawness of it, and it's simplicity and ease of use, and it's multi-cog technology just puts it way infront of any competition.
Baggers.
BTW, might 45 I/O lines and two cores interest you? I've been tooling with a design for a few weeks now and thought it'd be fun to see what others thought of the concept & design. The schematics are attatched to the post hyperlinked above, still need a spot of pollish, but feel free to use them in your design if you feel they're up to snuff.
DVI does have RGB but i think it's more akin to VGA RGB than SCART's RGB, the timings can't possibly be the same though, that would just be too easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! The average PC while browsing the internet typically uses less than 30% of it's potential, why not donate a portion of the rest for cancer resaerch?
That's the coolness of the Prop for you though. Love it.
I don't know much about DVI but I do know VGA monitors will sync to a wide variety of input signals. CRT's will sync to nearly anything, but newer LCD monitors might be more picky.
Is it possible for you to make a NTSC or VGA version of this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
Post Edited (Bob the Builder on a C64) : 7/13/2007 11:34:23 AM GMT
mpark: lol [noparse];)[/noparse]
Rinks: thanks [noparse]:)[/noparse] and yes, it's without extra ram or video chips, it's just the prop, and a few resistors [noparse]:)[/noparse] I'll have a good look at your design tomorrow, back of out in a mo, for the evening section, just came home to put the girls to bed, and have grandparents come round to mind them while we go back out.
Potatohead: 400 colours from 3 resistors is still an amazing feat [noparse];)[/noparse] like you say, it shows the uber-coolness of the prop.
Dennis: I think i'll be going the AD725 route, for compatibility, as most have tv access, than a spare monitor. ( I'm assuming anyway lol )
Bob: if I use the AD725, it'll be NTSC and PAL.
Hi Kelvin, yeah I'm looking into AD725's too, might be the easiest way to go, to allow Composite use for the US.
Baggers [noparse]:)[/noparse]
apnews.excite.com/article/20070713/D8QBSVK09.html
Possibly would need more memory to handle the received video, for one.
Maybe not enough cogs.... But interesting to hear of such robots. Pricey. Ya!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Baggers
You've done a very good job !!! Well done.
Just I'm thinking in digitalize a·"RGB" video signal, I thought that to scan a "H" line of the video of 64uSeg each, ·I would have about only 5120 clock cycles (at 80Mhz clock) to do that·
I found that maybe I could take no more than 90 samples per line, and that is slower resolution than you got in your sample picture
Could you give me an idea of..How do you get such resolution in your picture? or What I'm thinking wrong in it ?
Maybe you are using some method that is unknown for me...
Thanks in advance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Thanks for the compliments [noparse]:)[/noparse]
yes, Hscan is 64us, giving you ~1280 instructions since each cog is running at 20mips. but ~14us is used up on sync and front and back porches. so it gives you ~50us which gives you ~1000 instructions. rdlong is like two instructions timewise, then add to source pointer, and djnz for loop altogether takes around 4 instructions worth, giving you ~256 samples but it's a bit more, cos the rdlong takes ~7 clocks not 8 ( since we're not using another read within the hub access time or whatever the correct technical term for each cog's turn lol ). so makes it up to ~320.
Hope this helps, you and anyone else for that matter. [noparse]:)[/noparse] since this is a great forum helping others learn too.
Baggers.
You're right....but I will waste some more "clock cycles" to get the A/D clock....same, I could take a enough quantity of samples for my application.
One idea... let me know If I'm wrong please... What about to use the COG RAM during the image time to get the data ?? Could be only 4 clock cycles instead 7...
Maybe that memory could be refreshed with new data from main memory before need it in the following "H" line ...
In my case, of taking about 200 samples each H line, and then jumping next "two H lines" to take my new samples...I could have time todo so...don't you ?
I also will have enough COG memory to do that... That only increases my "H" resolution, not "V"
What do you think about this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Regards,
Baggers.