Well we differ clearly. In a very real sense, the boundaries for that ATMega chip are well known, and a lot of it's functionality is built to address specific needs.
The prop isn't built that way. We don't even know the boundaries, because it's actually new. I don't think we get a Propeller, with that kind of design process and documentation in play.
How hard is it to actually just build it? Seriously. One could argue that time spent reading through all that documentation, could be time spent writing a bit of code, and observing a result too.
It takes a large team considerable time to produce that documentation. Given the Atmel chip is a composite of many other efforts realized over time, this kind of documentation is to be expected.
Given the prop is actually new, gen 1 design, it isn't. Now, the next generation of chip will leverage what is known here, the use cases we pioneer, and all of that will result in a greater volume of docs for the next chip, just like Atmel did.
At some point, a product is either new, or it isn't. If it is actually new, and not some derivative, or composite of things done before, then some discovery about it is to be expected, is it not? Otherwise, how would the product ever be realized at a cost that makes sense?
For sure video generator cannot be built without planning. This is not taking a 8-leg chip, and soldering it on prototyping board with some resistors, without any schematic drawn. It is a moderately complex piece of hardware. A structure diagram should exist at least.
I can understand different reasons why video generator docs do not exist. I am just telling I do need it. If I count correctly, 2 people in this thread say video gen is poorly documented, while 3 say it is ok. 40% is much enough to consider
Anyway, I am stopping to discuss this until we hear from Parallax on the topic - as the discussion is leading to nothing.
When it arrives, what then? Won't the specific use cases still need to be coded and vetted?
I'm sorry for belaboring the point. I find the differences in thinking interesting, and mean nothing personal.
Honestly, I believe such a diagram could be created from the information we have right now too, with the topic of color in composite video serving to make what is happening appear more complex than it really is, but that's me.
That might actually be a quick path to your desired result. Perhaps simply vetting an existing document, generated from what we know right now is easier than setting out to formally author one, given the development mind share is on the next chip generation. You might ask whether or not that's an option.
Actually, I have an editor open right now where I am trying to illustrate how things work [noparse]:)[/noparse] This can be considered purely academic interest, or perfectionism [noparse]:)[/noparse] I do like to know exactly how things work
My initial comment is to mark pixels and colors also as S and D bus. Those get fetched when the waitvid command needs them. I'm not sure there is a sync there either. Once the waitvid is running, it just runs, and will repeat given the VSCL data it has, if no new waitvid command is executed.
Linus, the guy that did the great Prop demo, ran into this with an example that had timing that was almost perfectly synchronized with these things. His code is gone now. Might have a copy. The key thing was a series of in-line waitvids, with a fetch from the HUB, followed by a waitvid, another fetch, with no other code. He had unrolled a waitvid loop to get more speed for a 800x600 VGA display.
Turns out, one could comment out the waitvids, and the pixels and colors worked correctly most of the time anyway! What was happening was the S&D busses contained the necessary data as a result of the other instructions, and the video generator was just fetching right before beginning each new frame. The timing of all that kind of sort of just worked.
Also, if one is late on a waitvid, this behavior is easily seen. Screen "snow" will be seen from the S and D bus data picked up by the video generator. Most often happens when one is asking for a resolution that's just a shade higher than what can be fetched in a waitvid loop.
add count, #4
rdlong colors, count
waitvid colors, #%%3210 (waitvid running as full color, where colors are basically pixels, 4 pixel frame)
jnz #loop
At 80Mhz, that loop will display this behavior somewhere around 500 pixels per line, TV, NTSC.
We had a forum thread on this, and I'll go looking to see about it. BTW: That's the kind of thing that just triggers in people. Often it works that way, and showing in process documentation works about the same as "I'm here and it doesn't work" does.
@potatohead: Yes, counters are not part of the video - sorry, just my incorrect wording. However, IMHO you are way off-base with saying we can document it. It does need something like the block diagram done by Andrey. This just makes the Prop professional, and to say it is not required denegrates the Prop to the hobbyist market, which is unfortunately where it really is at the moment.
Andrey said...
This thread is somehow inter-related with recent discussions about what is required for propeller to gain more popularity. Others have said much, I would only add - docs, docs, and docs. If I need to learn how timer/counter or ADC works in ATMega - I do not ask at forums, I do not read code someone has written, I just open the datasheet - and I am done. Nobody knows what my goal is, even maybe myself - but I get complete understanding of how things work. Don't get me wrong, I love the Prop, and the community around it is awesome. I am just looking for more information. Propeller manual is great in all ways, except two - counters (counters appnote mostly fills this gap) and video.
@Andrey... you are spot-on here! Thanks for your diagram. I have no idea how accurate this is as I really do not understand how the video section really works. I have steered clear of it simply because it is poorly documented, and only used what I have had to use. I suspect there is little interest here as most know the lack of specs here and just use the objects. A confirmed block diagram like you have done would be a great addition.
@Chip... We need your input here please.
@Ken...·Then someone from Parallax·needs to take that and add it to the Prop Datasheet. This is VERY IMPORTANT as it tends to lead to assumptions that the Prop is not for the professional market.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Andrey Demenev said...
ok, here is my understanding of video generator equivalent circuit so far. Please comment
waitvid doesn't exactly provide control input to the circuitry. It just primes S and D and then (optionally) blocks. That said, I agree that there has to be a RELOAD signal but it doesn't originate from waitvid. Then again, it may just be a labelling issue.
Also, the frame timing can be off by one cycle if pushed slightly too far. See this thread about waitvid timing. Which suggests that the h/w is slightly more complicated [noparse];)[/noparse]
(something happened to that post, during edit, if you read the older one, know I just needed to start over)
It's not devaluing this market to hold the opinion I do.
A simple diagram can be made from what we know right now. Leon below mentioned VDHL code. That would be fantastic for this effort, and a big time saver, then again, it puts some very clever video hardware out there in easily reproducible form. Hmm... I'm not sure that's all good.
The core basis for my opinion is the docs we have now address the task of making video nicely, for all but extreme cases, where we exceed the original spec anyway. What does this mean?
It means, even when or if we get more complete documentation, there will still be a code, test, discover, phase required to vet and understand all the implications. That's true even for a very complete and highly technical documentation effort.
The other core basis, given that, is what return will that effort really have?
Had a simple frame buffer device been included, we wouldn't have WOLF 3D running on the thing, nor many of the fancy tricks we enjoy, but it would be well documented and professional, right? Which is more important? Simple tools, with some loose specification, or tools that are rigid, with no real discovery, outside of a bug, or flaw, being possible? I'll take the former in a second, because the overall utility of that approach significantly improves over time, and that has huge value. That kind of value comes with a loose spec, leaving a lot of the work in software.
Finally, a block diagram to show key function areas would be great. I want it, others want it, and it would be good. Lack of that level of documentation doesn't prevent improvements to our video code base.
Sorry. I just don't see the return on investment playing out on this one. It's a nice to have, but... kind of thing. It's not like that information is a big sales exception, as in, "we would have ordered half a million, but we didn't know the exact timing relationships behind this obscure use case for the video generator, sorry".
That's not devaluing us, or the market. It's just rational, that's all.
If that rubs, sorry. I just know that effort is significant, and hate to see the investment made with little to no return, beyond "well we know it all now" (which won't happen anyway, because the implications of how things work will still require lots of code and test and discovery, docs or not).
The best way to document something like that is to use VHDL. It's completely unambiguous and would describe the operation exactly. It might have actually been designed that way in the first place, as the various sub-systems were prototyped on an FPGA. Perhaps Parallax can provide the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
potatohead said...
It's not like I don't want the information, or that I think it shouldn't be done. I do. However, given the stated purpose of that particular bit of silicon, I think the burden for better documenting it rests with those that want to push it beyond making video signals, which is does very well, and consistently, I might add.
Actually, the burden of documenting the Propeller is on Parallax, the manufacturer of the product, not on Joe Customer.
I'm just curious, but why are you even debating this issue? I'm assuming that the people asking for better docs have actually bought a Propeller from Parallax, which makes them paying customers. So here you have some paying customers asking for technical support in the form of improved documentation on a manufacturer's technical support forum. It's not really for the community to tell them that they're wrong.
If the Propeller is to have any chance whatsoever to play in the big leagues, people need to stop making silly excuses about why there's no documentation, or this tool doesn't exist, or whatever. Companies expect these things, and to be frank, if they can't/aren't/won't be provided, people will just go elsewhere.
I think better documentation is always good. I also know what that costs.
So there is the stated purpose of the device. Currently, for the Propeller that's making video signals, and some other obvious serialized pin state stuff. Right now, a block function diagram would be good to have. No question. I think the information we have is enough to construct that, and maybe something along the lines of what Leon wrote could happen, making that happen efficiently.
Beyond that, there are other possible uses. Producing documentation sufficient to identify those in advance is very, very expensive, and I'm asking where the return on that is, that's all. I don't see it, and I don't necessarily suggest that Parallax is obligated to provide it, without a business case for doing so. We get those kinds of docs from the larger companies, because they have a library of IP to work with, that is vetted and they have a scale where doing that can be part of an overall large product roll out, and or something they have identified as a market niche worth that kind of investment.
Where is the niche here? What is the potential "off label" use? It seems to me, that's a joint burden if anything, and I think I'm just going to stick with that.
In the niche I work in, we get these kinds of requests. They are almost always backed by some business need. I think the block diagram is valuable, and there is a business need there, if anything to make the data sheet consistent. Bring it on. It's a good thing. However, it currently is not a barrier that is significant, that's all, and the implication that it is, isn't backed by any metrics I can see. If anything, there is at least a stated potential use case, and that's not been identified here either.
(I'll go away now, happy to see this all play out)
Edit: I would add, this dilemma is exactly why we don't often see interesting hardware of this type. It's easier to limit scope and function instead.
Another advantage of using VHDL is that the operation of the circuit can be simulated; you could even model the software driving it, and wouldn't need to mess about with actual Propeller hardware until everything was working properly. Verilog could be used instead of VHDL, of course, if anyone prefers it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Cluso99 said...
Yes, counters are not part of the video - sorry, just my incorrect wording. However, IMHO you are way off-base with saying we can document it. It does need something like the block diagram done by Andrey. This just makes the Prop professional, and to say it is not required denegrates the Prop to the hobbyist market, which is unfortunately where it really is at the moment.
Cluso
Have you read the AN001 Application Note about the counters?
There is such a block diagram on the first page. For me the counters are clear documented.
What do you miss?
Andrey
Thank you for this block diagram of the video generator. Maybe not every detail is correct, but for me, it makes the
video generator much better understandable then every textual description or VHDL code.
Except what has been already said about the source of reload signal and latching of pixels and colors, can someone who knows video generator comment on the diagram?
Not sure about the Phase modulator logic.
I would expect the attached diagram this gives %001 and %111 when modulation is on (=+1 -1)
(red dotted line removed)
Andrey Demenev said...
Except what has been already said about the source of reload signal and latching of pixels and colors, can someone who knows video generator comment on the diagram?
1. VPins / VMode logic missing (the broadcast logic is also missing, but that's another discussion entirely)
2. As noted by Ariba, the phase modulator MSB should not be part of the left AND block. It also might be inverted before being used in the right AND blocks.
3. The Pixel shift register is missing the 30 -> 32, 31 -> 33 shift inputs (the last color is repeated)
4. The "Color subcarrier x16" statement is misleading. There is nothing preventing the video generator from being used as a PSK16 encoder or driving the phase modulator at a different frequency.
5. "Divide by" isn't quite correct as 0 is a valid input. The "Divide by X" is also reloaded with the initial value when it expires, not from the current VSCL value.
6. The reloads are triggered by the frame counter expiring. (I'm not sure what happens if the frame counter expires before the pixel counter.)
However, not to take away from your effort, but such a the diagram is only useful if it is 100% accurate. This is especially true in this case where there are two unsynchronized clock signals (PLL and CLK). So questions regarding signal delays and timing become important. There are also questions about what happens when VMode is 00, i.e. whether the counters are still counting. Thus it may be better to not provide a detailed diagram if it is not accurate.
There is also a risk to Parallax that specifying the video generator to that level of detail might lock the design into a specific implementation, thereby removing their ability to make improvements which would not affect TV.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
1. This is obvious, I think
2. Correct
3. Got it, thanks - but see 5b
4. Agreed
5a. Zero would mean 2^N - I do not see a problem here
5b. I would rather state that "Divide by X" is only reloaded when frame counter has expired, and just stops when it has expired itself - effectively stopping shift register and keeping the last pixel until "Divide by Y" expires
5c. I do think the "Divide by X" and "Divide by Y" are reloaded with current VSCL value. See code below that illustrates this
6. Agreed. If the frame counter expires before the pixel counter - this changes nothing
Here is an example illustrating some aspects of video generator working:
1. Pixel counter and frame counter are reloaded when frame counter has expired
2. Pixel counter and frame counter are reloaded with current content of VSCL - not with value of VSCL had when last WAITVID was executed
3. Pixels and colors are reloaded when frame counter has expired
4. Pixels and colors are reloaded with current state of S/D buses
I have Prop running at 96 MHz. I set the PLL to run at 3 MHz. In a loop, I issue a WAITVID to output 32 alternating 7 and 0, with 1 us width (3 PLL periods). After that, I change VSCL to frame period is 200 us (600 PLL periods), and then WAITCNT long enough. What I am observing is this : a 32-bit pattern of 7 and 0, and then repeating patterns equally spaced at 200 us. These patterns (pixels) depend on S bus (change constant at WAITCNT), and amplitude (colors) depends on D bus (change number of longs before :loop) The 200 us spacing clearly demonstrates that new VSCL takes effect when frame counter has expired.
PUB main
cognew(@video, 0)
DAT
video
mov VCFG, cVCFG
mov CTRA, cCTRA
mov FRQA, cFRQA
mov DIRA, cDIRA
jmp #:loop
long 0[noparse][[/noparse]200]
:loop mov VSCL, cVSCL1
waitvid cColors, cPixels
mov VSCL, cVSCL2
'nop
mov timer, delay
add timer, cnt
waitcnt timer, #5
jmp #:loop
cVCFG long (%10 << VMode) | (0 << CMode) | (0 << Chroma0) | (%10 << VGroup) | (%1111 << VPins)
cCTRA long %00001_011_00000000_000000_000_000000
cFRQA long $8000000
cDIRA long %1111_0000_0000_0000_0000
cVSCL1 long (3 << 12) | (3 * 32)
cVSCL2 long (0 << 12) | 600
cColors long $0007
cPixels long $55555555
delay long 300000
timer res 0
FIT
Post Edited (Andrey Demenev) : 8/5/2010 8:12:47 AM GMT
- reload occurs when frame counter expires
- colors and pixels are loaded from S/D buses
- VPins[noparse][[/noparse] 3 ] does not depend on Chroma0
- amplitude modulator corrected according to Ariba's comment
looks like VCFG is not latched, and changing it will affect the video generator immediately
Post Edited (Andrey Demenev) : 8/5/2010 10:06:16 AM GMT
I am surprised that no-one from Parallax has provided any input on this thread. Seems to me as though a post from a person or persons truly in the know would provide the clarity needed.
Thanks Andrey for the diagram, a picture really does paint a thousand words.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX - The home of the Hybrid Development System and PropGFX Lite
On or about the 19th entry of this thread, potatohead was kind enough to post a simplified version of graphics_demo.spin (which links graphics.spin and tv.spin) that paints a single pixel.
Would anyone know if this can be further reduced to print a true pixel that is just one scan line by one period of the dot clock? Can it be done in one-bit color (eg gray/black or white/black)?
Comments
The prop isn't built that way. We don't even know the boundaries, because it's actually new. I don't think we get a Propeller, with that kind of design process and documentation in play.
How hard is it to actually just build it? Seriously. One could argue that time spent reading through all that documentation, could be time spent writing a bit of code, and observing a result too.
It takes a large team considerable time to produce that documentation. Given the Atmel chip is a composite of many other efforts realized over time, this kind of documentation is to be expected.
Given the prop is actually new, gen 1 design, it isn't. Now, the next generation of chip will leverage what is known here, the use cases we pioneer, and all of that will result in a greater volume of docs for the next chip, just like Atmel did.
At some point, a product is either new, or it isn't. If it is actually new, and not some derivative, or composite of things done before, then some discovery about it is to be expected, is it not? Otherwise, how would the product ever be realized at a cost that makes sense?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 8/3/2010 6:15:24 AM GMT
I can understand different reasons why video generator docs do not exist. I am just telling I do need it. If I count correctly, 2 people in this thread say video gen is poorly documented, while 3 say it is ok. 40% is much enough to consider
Anyway, I am stopping to discuss this until we hear from Parallax on the topic - as the discussion is leading to nothing.
When it arrives, what then? Won't the specific use cases still need to be coded and vetted?
I'm sorry for belaboring the point. I find the differences in thinking interesting, and mean nothing personal.
Honestly, I believe such a diagram could be created from the information we have right now too, with the topic of color in composite video serving to make what is happening appear more complex than it really is, but that's me.
That might actually be a quick path to your desired result. Perhaps simply vetting an existing document, generated from what we know right now is easier than setting out to formally author one, given the development mind share is on the next chip generation. You might ask whether or not that's an option.
Cheers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 8/3/2010 6:34:54 AM GMT
I get that too. Note the position open today!
My initial comment is to mark pixels and colors also as S and D bus. Those get fetched when the waitvid command needs them. I'm not sure there is a sync there either. Once the waitvid is running, it just runs, and will repeat given the VSCL data it has, if no new waitvid command is executed.
Linus, the guy that did the great Prop demo, ran into this with an example that had timing that was almost perfectly synchronized with these things. His code is gone now. Might have a copy. The key thing was a series of in-line waitvids, with a fetch from the HUB, followed by a waitvid, another fetch, with no other code. He had unrolled a waitvid loop to get more speed for a 800x600 VGA display.
Turns out, one could comment out the waitvids, and the pixels and colors worked correctly most of the time anyway! What was happening was the S&D busses contained the necessary data as a result of the other instructions, and the video generator was just fetching right before beginning each new frame. The timing of all that kind of sort of just worked.
Also, if one is late on a waitvid, this behavior is easily seen. Screen "snow" will be seen from the S and D bus data picked up by the video generator. Most often happens when one is asking for a resolution that's just a shade higher than what can be fetched in a waitvid loop.
add count, #4
rdlong colors, count
waitvid colors, #%%3210 (waitvid running as full color, where colors are basically pixels, 4 pixel frame)
jnz #loop
At 80Mhz, that loop will display this behavior somewhere around 500 pixels per line, TV, NTSC.
We had a forum thread on this, and I'll go looking to see about it. BTW: That's the kind of thing that just triggers in people. Often it works that way, and showing in process documentation works about the same as "I'm here and it doesn't work" does.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 8/3/2010 2:12:42 PM GMT
@Andrey... you are spot-on here! Thanks for your diagram. I have no idea how accurate this is as I really do not understand how the video section really works. I have steered clear of it simply because it is poorly documented, and only used what I have had to use. I suspect there is little interest here as most know the lack of specs here and just use the objects. A confirmed block diagram like you have done would be a great addition.
@Chip... We need your input here please.
@Ken...·Then someone from Parallax·needs to take that and add it to the Prop Datasheet. This is VERY IMPORTANT as it tends to lead to assumptions that the Prop is not for the professional market.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 8/3/2010 11:02:31 PM GMT
Also, the frame timing can be off by one cycle if pushed slightly too far. See this thread about waitvid timing. Which suggests that the h/w is slightly more complicated [noparse];)[/noparse]
Post Edited (kuroneko) : 8/4/2010 1:16:41 AM GMT
It's not devaluing this market to hold the opinion I do.
A simple diagram can be made from what we know right now. Leon below mentioned VDHL code. That would be fantastic for this effort, and a big time saver, then again, it puts some very clever video hardware out there in easily reproducible form. Hmm... I'm not sure that's all good.
The core basis for my opinion is the docs we have now address the task of making video nicely, for all but extreme cases, where we exceed the original spec anyway. What does this mean?
It means, even when or if we get more complete documentation, there will still be a code, test, discover, phase required to vet and understand all the implications. That's true even for a very complete and highly technical documentation effort.
The other core basis, given that, is what return will that effort really have?
Had a simple frame buffer device been included, we wouldn't have WOLF 3D running on the thing, nor many of the fancy tricks we enjoy, but it would be well documented and professional, right? Which is more important? Simple tools, with some loose specification, or tools that are rigid, with no real discovery, outside of a bug, or flaw, being possible? I'll take the former in a second, because the overall utility of that approach significantly improves over time, and that has huge value. That kind of value comes with a loose spec, leaving a lot of the work in software.
Finally, a block diagram to show key function areas would be great. I want it, others want it, and it would be good. Lack of that level of documentation doesn't prevent improvements to our video code base.
Sorry. I just don't see the return on investment playing out on this one. It's a nice to have, but... kind of thing. It's not like that information is a big sales exception, as in, "we would have ordered half a million, but we didn't know the exact timing relationships behind this obscure use case for the video generator, sorry".
That's not devaluing us, or the market. It's just rational, that's all.
If that rubs, sorry. I just know that effort is significant, and hate to see the investment made with little to no return, beyond "well we know it all now" (which won't happen anyway, because the implications of how things work will still require lots of code and test and discovery, docs or not).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 8/4/2010 4:54:35 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Actually, the burden of documenting the Propeller is on Parallax, the manufacturer of the product, not on Joe Customer.
I'm just curious, but why are you even debating this issue? I'm assuming that the people asking for better docs have actually bought a Propeller from Parallax, which makes them paying customers. So here you have some paying customers asking for technical support in the form of improved documentation on a manufacturer's technical support forum. It's not really for the community to tell them that they're wrong.
If the Propeller is to have any chance whatsoever to play in the big leagues, people need to stop making silly excuses about why there's no documentation, or this tool doesn't exist, or whatever. Companies expect these things, and to be frank, if they can't/aren't/won't be provided, people will just go elsewhere.
I think better documentation is always good. I also know what that costs.
So there is the stated purpose of the device. Currently, for the Propeller that's making video signals, and some other obvious serialized pin state stuff. Right now, a block function diagram would be good to have. No question. I think the information we have is enough to construct that, and maybe something along the lines of what Leon wrote could happen, making that happen efficiently.
Beyond that, there are other possible uses. Producing documentation sufficient to identify those in advance is very, very expensive, and I'm asking where the return on that is, that's all. I don't see it, and I don't necessarily suggest that Parallax is obligated to provide it, without a business case for doing so. We get those kinds of docs from the larger companies, because they have a library of IP to work with, that is vetted and they have a scale where doing that can be part of an overall large product roll out, and or something they have identified as a market niche worth that kind of investment.
Where is the niche here? What is the potential "off label" use? It seems to me, that's a joint burden if anything, and I think I'm just going to stick with that.
In the niche I work in, we get these kinds of requests. They are almost always backed by some business need. I think the block diagram is valuable, and there is a business need there, if anything to make the data sheet consistent. Bring it on. It's a good thing. However, it currently is not a barrier that is significant, that's all, and the implication that it is, isn't backed by any metrics I can see. If anything, there is at least a stated potential use case, and that's not been identified here either.
(I'll go away now, happy to see this all play out)
Edit: I would add, this dilemma is exactly why we don't often see interesting hardware of this type. It's easier to limit scope and function instead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 8/4/2010 6:19:09 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Cluso
Have you read the AN001 Application Note about the counters?
There is such a block diagram on the first page. For me the counters are clear documented.
What do you miss?
Andrey
Thank you for this block diagram of the video generator. Maybe not every detail is correct, but for me, it makes the
video generator much better understandable then every textual description or VHDL code.
Andy
Post Edited (Ariba) : 8/4/2010 1:44:15 PM GMT
I would expect the attached diagram this gives %001 and %111 when modulation is on (=+1 -1)
(red dotted line removed)
Your version results in %000 and %111
Andy
I would not expect Parallax, or any chip supplier, to provide·VHDL or Verilog of a section of their chip. IMHO this would be absolutely proprietary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
1. VPins / VMode logic missing (the broadcast logic is also missing, but that's another discussion entirely)
2. As noted by Ariba, the phase modulator MSB should not be part of the left AND block. It also might be inverted before being used in the right AND blocks.
3. The Pixel shift register is missing the 30 -> 32, 31 -> 33 shift inputs (the last color is repeated)
4. The "Color subcarrier x16" statement is misleading. There is nothing preventing the video generator from being used as a PSK16 encoder or driving the phase modulator at a different frequency.
5. "Divide by" isn't quite correct as 0 is a valid input. The "Divide by X" is also reloaded with the initial value when it expires, not from the current VSCL value.
6. The reloads are triggered by the frame counter expiring. (I'm not sure what happens if the frame counter expires before the pixel counter.)
However, not to take away from your effort, but such a the diagram is only useful if it is 100% accurate. This is especially true in this case where there are two unsynchronized clock signals (PLL and CLK). So questions regarding signal delays and timing become important. There are also questions about what happens when VMode is 00, i.e. whether the counters are still counting. Thus it may be better to not provide a detailed diagram if it is not accurate.
There is also a risk to Parallax that specifying the video generator to that level of detail might lock the design into a specific implementation, thereby removing their ability to make improvements which would not affect TV.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
1. This is obvious, I think
2. Correct
3. Got it, thanks - but see 5b
4. Agreed
5a. Zero would mean 2^N - I do not see a problem here
5b. I would rather state that "Divide by X" is only reloaded when frame counter has expired, and just stops when it has expired itself - effectively stopping shift register and keeping the last pixel until "Divide by Y" expires
5c. I do think the "Divide by X" and "Divide by Y" are reloaded with current VSCL value. See code below that illustrates this
6. Agreed. If the frame counter expires before the pixel counter - this changes nothing
Here is an example illustrating some aspects of video generator working:
1. Pixel counter and frame counter are reloaded when frame counter has expired
2. Pixel counter and frame counter are reloaded with current content of VSCL - not with value of VSCL had when last WAITVID was executed
3. Pixels and colors are reloaded when frame counter has expired
4. Pixels and colors are reloaded with current state of S/D buses
I have Prop running at 96 MHz. I set the PLL to run at 3 MHz. In a loop, I issue a WAITVID to output 32 alternating 7 and 0, with 1 us width (3 PLL periods). After that, I change VSCL to frame period is 200 us (600 PLL periods), and then WAITCNT long enough. What I am observing is this : a 32-bit pattern of 7 and 0, and then repeating patterns equally spaced at 200 us. These patterns (pixels) depend on S bus (change constant at WAITCNT), and amplitude (colors) depends on D bus (change number of longs before :loop) The 200 us spacing clearly demonstrates that new VSCL takes effect when frame counter has expired.
PUB main cognew(@video, 0) DAT video mov VCFG, cVCFG mov CTRA, cCTRA mov FRQA, cFRQA mov DIRA, cDIRA jmp #:loop long 0[noparse][[/noparse]200] :loop mov VSCL, cVSCL1 waitvid cColors, cPixels mov VSCL, cVSCL2 'nop mov timer, delay add timer, cnt waitcnt timer, #5 jmp #:loop cVCFG long (%10 << VMode) | (0 << CMode) | (0 << Chroma0) | (%10 << VGroup) | (%1111 << VPins) cCTRA long %00001_011_00000000_000000_000_000000 cFRQA long $8000000 cDIRA long %1111_0000_0000_0000_0000 cVSCL1 long (3 << 12) | (3 * 32) cVSCL2 long (0 << 12) | 600 cColors long $0007 cPixels long $55555555 delay long 300000 timer res 0 FITPost Edited (Andrey Demenev) : 8/5/2010 8:12:47 AM GMT
- reload occurs when frame counter expires
- colors and pixels are loaded from S/D buses
- VPins[noparse][[/noparse] 3 ] does not depend on Chroma0
- amplitude modulator corrected according to Ariba's comment
looks like VCFG is not latched, and changing it will affect the video generator immediately
Post Edited (Andrey Demenev) : 8/5/2010 10:06:16 AM GMT
Thanks Andrey for the diagram, a picture really does paint a thousand words.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
Post Edited (Coley) : 8/5/2010 10:32:35 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
An explanation of how it works would suffice, there is no point in giving away the IP......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Would anyone know if this can be further reduced to print a true pixel that is just one scan line by one period of the dot clock? Can it be done in one-bit color (eg gray/black or white/black)?