Video generator docs - someone?
Andrey Demenev
Posts: 377
I may be wrong - and will be glad if I am - but I think the video generator is lacking documentation, even pretty basic.
I am now at the point in my Propeller education when I am not satisfied with existing code that uses the video generator, and starting to think about writing my own. What is stopping me is that I cannot understand how video generator works. What I am expecting to find is some simple explanation, like : when in composite mode, writing FOO to VCSL would generate sync level, BAR would generate these values for Y,U,V, and FOOBAR - these Y,U,V. Same for VGA mode
I am now at the point in my Propeller education when I am not satisfied with existing code that uses the video generator, and starting to think about writing my own. What is stopping me is that I cannot understand how video generator works. What I am expecting to find is some simple explanation, like : when in composite mode, writing FOO to VCSL would generate sync level, BAR would generate these values for Y,U,V, and FOOBAR - these Y,U,V. Same for VGA mode
Comments
The reason you don't find much in the way of documentation for the video generator is that most of the work is done in software, not hardware. The hardware is just a specialized shift register with its own (system clock derived) clock. It shifts either 1 or 2 bits per clock and uses those bits to select which byte of a 32-bit "color" register to output. For VGA, that's it. Everything else (including sync) is done in software. For TV, the hardware uses the "color" information to generate the color subcarrier information during the active portion of the scan line. Everything else (sync, back porch, blanking, etc.) is done in software.
Part of what you are asking for depends on the video circuit. There is the reference one, shown in the Demo Board schematics. Those are in wide use for TV and VGA. There are others too. What levels one gets, depends on those circuits.
Another part of what you are asking for comes down to the signal format timing. I hear you there. Right now, I'm working on PAL signals, and it comes down to finding the spec documentation, observing code that has been written, using scope to see what actually needs to happen. Those that wrote that first round of code, used the documentation in the prop manual and data sheet to match up the signal requirements with waitvid timings and pixel and color data. The docs are plenty good enough for that to occur. That's just some work, and testing, which is the harder part of doing all software video.
The docs we do have are actually fairly complete where the operation of the generator is concerned. To get a level = value association, you look at those, then you do the math on your circuit, and you know the signal voltage level.
There is no YUV space on the Propeller. Props have a coarse RGB on the VGA, and that's simple. Props also have a HUE + Intensity space on TV, that produces YUV values too. With the reference circuits, very little actual control of those things is open to the programmer. Software video, without using the generators is possible too.
Perhaps you should look at how that's done in all software, then look at the generators. That's what I did early on, because it took a while to realize the video generators really don't do much. There isn't a ton to document in terms of the chip function. The key to the whole thing is understanding the signal format. The generators do not help with this, which is why there is not a lot of documentation on it. They are just a tool to generate serialized data. That's all they do.
Some reference, you make signal X, this way, docs would be good, and that's essentially the video code we have right now, barring some other effort.
IMHO, you are probably thinking it does a lot more than you think!
This might help you:
Forget the generators. They don't exist for a moment. Now, let's say we clock the propeller at some multiple of the TV color burst frequency, or some multiple of the VGA pixel clocks. Either is fine in concept. I'll just stick with TV, because I know and like TV, mostly because I'm almost never where I can do VGA.
Imagine the video signal as a serial stream of values. That's all it really is, as far as a propeller is concerned. Signals have parts. Sync pulses, porches, active video areas. You get these things from an online reference, which would be nice to have documented, but just go and get one.
Then you have your video circuit. Maybe it's a simple DAC, or series resistors. Now you've got your levels. If you've got 8 bits, you've got 256 levels to work with. If you've got 3 bits, there are 8 levels to work with. That's what the prop does on TV. It works with three bits, giving us 8 levels to work with.
Depending on your circuit, those may be linear or not. Some math is needed to sort that out.
Generating a picture then is just a closed loop that runs over and over and over.
Build vertical sync, build horizontal sync, draw back porch, draw active pixels, draw front porch, repeat for the proper number of lines, repeat!
For TV graphics, using the parallax video circuit, the value 00 is sync, and 01 is sync. 02 - 07 are actually displayable values, intended for the active video area. That's actually true for a monochrome signal.
To build that signal, you would setup the counter to provide reference timing pulses, then use mov commands to write the values to the pins at the right time, streaming out the signal. Done with the right timing, you then see a picture.
The challenge in software is to fetch pixel data from the HUB, while bit banging those pins to keep the signal going.
Doing all of that is entirely possible, and probably should be done one of these days, just because.
Now, what does the generator do?
It just automates the bit banging part, leaving you the programmer to fetch colors and pixels from the HUB, during the output frames, without having to worry about that precision timing needed otherwise.
The documentation for that task is pretty good actually.
One other thing the generators do is output chroma info for TV graphics. It does that with 16 possible phase shifts, meaning we get 16 basic hues, with a fixed saturation level, and 5 in spec intensity levels. Remember there are 8 intensity levels total, two are used for sync, leaving 6. Color is +1, so the brightest pixels, if colored, are actually out of spec. These display anyway, BTW, but are too "bright" for the specification.
The VCFG register controls the output pins, some minor league output mode options (like chroma information being output or not). Counter A is used as the basis for the generator timing, and generally speaking, it should be set to some multiple of the color burst for TV, and some other multiple for VGA.
VSCL controls the actual waitvid operation. One thing to know about waitvids, is once you start them, they are running. They have a start up and stablize time, which is 4096 * PLLA, and can be stopped any time, so long as that time is considered when starting them.
The key concept to understand is "the frame" VSCL is expressed in terms of PLLA cycles. Each pixel will have X number of PLLA cycles as it's output duration. You tell the waitvid how many pixels you want by multiplying the pixel output time by the number of pixels, and those values go into VSCL, and that's a frame! That also happens to be about how long you have to fetch the data for the next frame too!
Add all that up, and a video driver is some setup:
do math to calculate timings
Set PLLA, VCFG, VSCL, do your first waitvid, and it starts and never stops, unless you are done outputting video.
Build the signal by stuffing the desired pixel clock, and frame size into VSCL, and doing so while the current waitvid is doing whatever you told it to do before. Your program is always prepping the next waitvid, while the current one is doing stuff.
Get that prep done, and execute "waitvid colors, pixels".
Repeat!
That's really the entire process.
It's worth looking at existing drivers to see what the VSCL values are. Read those, consider the PLLA frequency, add up the cycles, and look at the pixel and color data used, and you can tell what a driver is doing at any one time.
One nice trick, for example, is how to make a blank scan line. Instead of blasting out a ton of black pixels for that blank line, many drivers just set the pixel size to be very large so that one waitvid will output that scan line! Picture long, black pixels, or maybe even that whole scan line being just one big pixel!
Sync pulses are shorter pixel times, and are just colors and pixels over time, with no real difference from real graphics data, other than when they occur, and what level they are. If you think of levels as "colors", which I find easiest to do, colors 00 and 01 are sync values that should not appear in the display.
A look in a timing diagram for a video standard then, shows some pulses of different kinds. Translate those to color and pixels, and you've got the very basics of how the generator is used.
I'll end this monster with there being no particular magic. The generators are not needed at all to make video. Color video is easier on the TV with them too.
All they do is allow the programmer to specify output over time, and some output data. While that output is happening, there is time to get the next set of signal and graphics data to output. That's the core of why they exist.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 7/31/2010 4:06:44 PM GMT
I still cannot agree video hardware is documented. Maybe I am looking in wrong place? I realize that software is important, but it is nothing without hardware. How to set up counter to get desired sub-carrier freq? How to output sync? "16 possible phase shifts" + "8 intensity levels total" = 7 bits. What is the 8th for?
I for sure can read others' code, and I'm experienced enough to find out what I need with existing code editing and a scope. Was just hoping there is a shorter way [noparse]:)[/noparse]
Step1:
There are not really any "colors", the video shift register just selects what 8 pins to set high or low.
It's that we use different ohm resistors tied to different vga pins it's when we get the colors.
Step2: (for 4 color vga mode)
waitvid shift register uses two 32bit word inputs.
The first 32bit word have four bytes,
each byte tells what 8 pins to be high or low when THAT byte is selected.
Step3:
The second 32bit word in the waitvid command,
selects wich one of the·four bytes above to use.
Only·two bits at a time are used (%00,%01,%10,%11)
This 32bit word it's shifted sixteen times.
hint:
Nearly all vga prop implementations uses only 6pins for color, so the lower 2 bits in each byte in Step2 is always zero during the line display.
Post Edited (tonyp12) : 7/31/2010 4:45:50 PM GMT
Everything in the video signal is based off of one core frequency. For TV, NTSC, this is the 3.58 Mhz colorburst. The data on how to do that is in the counter documentation.
Counters accumulate (in one of their many modes) every cycle. To get a specific frequency, you divide that by your system clock, shift it left 32 bits, and you have the value that when added to the counter accumulator every system clock cycle, will result in pulses at that desired frequency.
So then, sync is all about picking a waitvid pixel clock and frame size that will output a usable sync signal, given specific pixel and color data.
I think you are looking for a "how to build a specific video signal" document, not documentation on how the hardware actually works. That documentation is complete, but for some extreme cases.
You are correct in that documentation is existing code. [noparse]:)[/noparse]
An example of that difference would be creating audio signals with the video generator hardware. All the information needed to build the audio signal is present in the docs, just as it is for the video signal. One is just more complex than the other.
In fact, I recommend doing exactly that. If you want to, you can pick really long pixel clock times, and blink LED's with the thing too, if visualizing what happens is important to you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
Thank you so much for that 8:39 AM explanation. Lots of words and explanations from other than the Parallax documentation to further simplify for those of us not familiar with what's going on with video generation. Now to compare your words (and the Hydra text) with those seemingly cryptic connections between the hardware and soft-/firm-ware and try to see through the 'fog'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
CON _XINFREQ = 12_000_000 _CLKMODE = XTAL1 + PLL8X VMode =29 CMode = 28 Chroma1 = 27 Chroma0 = 26 AuralSub = 23 VGroup = 9 VPins = 0 PUB main VCFG := (%10 << VMode) | (0 << CMode) | (0 << Chroma0) | (%10 << VGroup) | (%1111 << VPins) CTRA := %00001_111_00000000_000000_000_000000 FRQA := 100000 DIRA := %1111_0000_0000_0000_0000 VSCL := (10 << 12) | 320 repeat waitvid($0700, $55555555)No chroma, TV mode. I am setting the counter to run on pretty low freq. What I expect is to see a meander on the pins involved in video generation ($55555555) - but the waveform I am observing is not meander. It can be meander for some time, then a short 0->1 "needle" where it should be a 0->1 transition if it was a meander, then short needle anywhere. Basically, that is a meander with some added noise
Well, what you are going to get is pulses, which is what your scope shows the chip doing. All the generator does is serialize pin states. Now, if you turn the chroma on, it will also generate the phase shifted signal needed for composite video color. That can be ignored right now.
Try this:
Set the 4 color mode, TV, no chroma.
For your colors, choose $07_05_03_00 and for your pixels, try: %%0123_0123_0123_0123
If you are outputting that through the reference TV video circuit, you should see a coarse ramp.
Two other things to know: The pixels are output MSB to LSB, and the colors are processed LSB to MSB. Color 00 = lower 8 bits of the colors long, color 01 = next higher 8 bits, etc...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 7/31/2010 6:59:24 PM GMT
Note: although SPIN does include WAITVID, I don't think SPIN is fast enough for anything more than a very low resolution display, assuming it can even generate sync. 'twould be interesting to see if it were possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Ok, I think now I am understanding this better. In VGA mode, the bits of colors are outputted directly to VPins - that's simple.
In composite mode, first you need to setup CTRA in video PLL mode, and set PLL freq to desired subcarrier freq - depending on color coding system (PAL/NTSC).
In this mode, colors[noparse][[/noparse]2..0] control the intensity, and colors[noparse][[/noparse]6..3] control the phase of subcarrier. When colors[noparse][[/noparse]6..3] is all zero, the subcarrier is not generated,
and colors[noparse][[/noparse]2..0] are outputted to VPins "as is". When colors[noparse][[/noparse]6..3] non zero, depending on colors[noparse][[/noparse]2..0], Vpins output either a constant logic level or subcarrier.
The image below illustrates how colors[noparse][[/noparse]2..0] correspond to output patterns. 0 and 1 are logic states, + and - mean that subcarrier is outputted. "+" - subcarrier phase
is colors[noparse][[/noparse]6..3] + 0 degree, "-" - subcarrier phase is colors[noparse][[/noparse]6..3] + 180 degree. I am not sure if %000 and %111 are same phase, possibly one of them is inverted.
Basically, this is the information I was missing to start coding a video driver from scratch, without using existing code [noparse]:)[/noparse] Hope this can be helpful
Color[noparse][[/noparse] 0..2 ] is the base luma value. If color[noparse][[/noparse] 3 ] is zero or Chroma0 is zero, then that value is output to VPins[noparse][[/noparse] 0..2 ] or vpins[noparse][[/noparse] 4..6 ] depending on VMode. Color[noparse][[/noparse] 4..7 ] is added to a 4 bit counter and the MSB is used. (Since this counter is driven by PLLA, this is why PLLA is 16 times the colorburst frequency.) If Chroma0 is zero and color[noparse][[/noparse] 3 ] is one, the MSB is output to VPins[noparse][[/noparse] 3 ] or [noparse][[/noparse] 7 ] (S-Video mode). If Chroma0 is one and color[noparse][[/noparse] 3 ] is one then +/-1 is added to Color[noparse][[/noparse] 0..2 ] based on the MSB and is then output to VPins[noparse][[/noparse] 0..2 ] or [noparse][[/noparse] 4..6 ]. In Broadcast mode additional modulation is performed before output to VPins[noparse][[/noparse] 4..6 ] or VPins[noparse][[/noparse] 0..2 ].
For baseband with embedded color the TV extracts the luma value by averaging the output. So for color[noparse][[/noparse] 0..3 ] = 0..7, 9..14 the luma and chroma are decoded normally and the chroma has amplitude 2. But for color[noparse][[/noparse] 0..3 ] = 8 or 15, the +/-1 wraps around and the luma is decoded as 4 and 3 respectively and the chroma is amplitude 6, but 180 degrees out of phase.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Post Edited (ericball) : 8/2/2010 1:05:42 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Like a driver which just light the first pixel on the screen and that's all.
I really want to understand how all of that is working too, but so far I was not able. I will read this post few other times, and probably search for some other Patatoshead's posts since he usually give a lot of useful details...
Tomorrow I will receive my screem and try to play with it.
JM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.
There are several layers to this.
Eric has done work at the lowest layer. That's where you take the signal spec, set PLLA to the base frequency desired, then build up that signal. A signal is a continuous stream, forming frame after frame. Signals can be broken into their components. For TV, those are the VBLANK, HSYNC, Porches, and active video area. The HSYNC may or may not contain a color reference, or colorburst too. Porches are essentially overscan, or "the graphics border".
The color bar templates are a great reference for how this is done, and for the next layer up.
On the Propeller Wiki, and there is a link in my sig to that, you can find other drivers that do the signal stuff differently. So far, there is the 1 pin, NTSC 240 Sprite driver, and the color bar templates, all contributed by Eric. (thanks man!) IMHO, those are fine references that actually do just about everything one can think of with the signal. For comparison, I've got a simple NTSC Driver, derived off some work Cardboard Guru did that generates a much simpler NTSC video signal, that's a lot like the old 8 bit computers. It's in the wiki as the high-color bitmap driver. There is an older 8x8 NTSC character mode driver in the Obex that uses that same signal code as well as AiGeneric. That signal code is limited in that it's NTSC only, and it's color resolution is poor, compared to the ones Eric did. Finally, there is the Parallax TV driver, shipped with the Propeller tool, and it does NTSC and PAL, and is a balance between what I consider some of the better signal options, and overall utility / complexity.
I would like to highlight the NTSC Sprite driver Eric wrote generates the video signal in software, and really rocks. It's got the best NTSC TV color possible on this chip, without adding on to the reference video circuit.
Also, the video circuit in use, impacts how the signal level of the driver code is written. If we had a 8 bit DAC attached to the prop, a grey scale driver, or probably color driver could be written with that, yielding probably 160 or so colors, once the sync levels are taken into account. Remember, doing it this way means outputting the entire signal with whatever you have attached. If sync were generated on it's own pins, and a more complex circuit were built, then all 256 of the levels from the DAC would appear in the display, and the driver would have to be written differently to output the right parts at the right time.
It's also possible to not use the waitvid at all, as described in the posts above.
Anything you build needs to be built off a signal option that will get you where you want to go. All that work at the signal level gets you essentially nothing but a container for the next layer up. If you want to build a better signal, it's going to be slow going, and you are going to need to really think the entire signal through, because you won't see anything, until that's done proper. Without a scope, this isn't easy. With a scope, this isn't easy.
The next layer up is Pixels!
With video drivers, there isn't really a first pixel on the screen. The color bars are essentially where one starts, or a simple bitmap is where one starts. A single sprite might be a start too, though I think I would build some simple check display parts to debug code that will draw it.
Color bar drivers display the same thing on every scan line. They have no memory scanning logic to do anything else. They are an excellent starting point for coding whatever graphics scheme you are interested in coding.
Bitmap drivers are really easy, compared to most other things, because all one really needs is a display memory pointer, and maybe a color memory pointer, if desired. Bitmaps just display pixels, found in the HUB, one after the other.
There are a few basic approaches at this level. Single COG video is basically a driver that does what it can, while also outputting the signal. The Parallax TV driver is an excellent example of how much can be done in one COG. That one has some limits, with the tiles and colors, but it's doing a ton, and it's very, very flexible. Easily one of the best drivers there is.
Other variations on single COG video are character drivers, like the AiGeneric, or 8x8 drivers in general. It's not too tough to setup the few counters needed to emulate an Atari or C64 style display, right in with the signal. Bitmaps are easy too.
Single COG video drivers have limits, because time and COG space is limited. Generally speaking, these are either 2 color, 4 color, or full color, because those operating modes are the ones offered up by the video generator hardware. There generally isn't time for fancy things like color redirection, or mode changes, or sprites, etc...
Single COG video drivers are passive in that they grab the data and draw it to the screen, leaving the work of manupulating that data to other COGs, or a SPIN program.
If you want more than that, you probably (very likely) are going to be using a multi-cog video driver approach. The basic technique that appears to work very well is the scan line buffer. Your video signal COG (the TV COG) will output each scan line from a buffer in the HUB. If no new data is sent, it just keeps drawing the same pixels, over and over, essentially doing nothing more than the simple color bar one does. That kind of COG code needs to output it's state, what scan line it's on, or when the sync is happening, so that other COGs know when to fill the scan line buffer. Those other COGs can fill it in any number of ways, and that's how the better sprite drivers are done.
The layer above that is the application layer where there is a program just doing stuff, as if it's talking to a graphics chip, or some similar dedicated device.
Honestly, if you want that first pixel, it's probably better to go and run some of the drivers written, and work backward, as it's much easier to learn how waitvids and stuff work, when you can see the product of it. That means building on one of the established signal code bases, filling in with your graphics memory scheme, whatever it is. And if that's troublesome, work backward from a higher level still, using the graphics_demo that comes with the Propeller tool to learn about graphics memory, drawing things, buffers, modes, and colors.
The "Hello World" example for a video driver is the color bar templates Eric did. That's for lower level driver stuff.
At the higher level, the "hello world" would be graphics_demo.spin, or some of the simple programs on the HYDRA CD, such as Andre's bouncing squares demo.
I've also linked a commented graphics_demo.spin in my signature that strips that one down to the very basics, and it makes colors, tiles and such really easy to change, and it includes some very simple code for drawing lines, or changing colors. That one is extremely easy to change, delete, etc... to get some pixels on the screen. Going for the lower level stuff too early will highly likely be frustrating, unless working through the signal stuff makes sense to do.
It did for me, because I like that kind of thing, and I've some very specific video driver stuff in mind. Honestly, for just doing some graphics, I would pick the Parallax driver in a second, because it does a lot, is not hard to use, and includes library code to do most common things that people want to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
"Like a driver which just light the first pixel on the screen and that's all."
Really, this probably means a PROGRAM that uses a driver to draw the first pixel on the screen.
I've packaged up exactly that, using the Parallax TV driver, and a stripped down version of the commented graphics_demo.spin.
Enjoy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/2/2010 5:04:43 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
I know we can use the waitvid instruction, etc, to output a variable bit stream. What other keen ideas could they be used for??? The biggie for me would be any possible way to use the counters for inputting bit streams. I believe this is not possible, but without a definitive specification of the counters, we will never know. We have found many uses of the prop that Chip never dreamed of. The counters are likely another untapped pot of goodies anxiously waiting to be opened up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
A lot of this thread didn't align well with the docs we have.
Re: 4 bit counter = color phase differences, and the PLLA being 16 times the color burst. Somewhere, there needs to be a counter and logic to trigger the output. Yeah, that's an implied thing, but a fairly consistent one, given the video circuits I've seen.
Should it be documented? Absolutely. However, I would also say that the docs we have are enough to ferret out how the device works --making it just a matter of somebody running test cases and observing results.
I think it's also safe to say we know how the waitvid works for a very large majority of cases. Linus bumped into an odd one, having to do with the timing for 80Mhz and a 800x600 VGA display. (the S and D registers were fetched and aligned with when the waitvid wants them, which was cool) I've ran into the occasional case when switching from 2 to 4 color mode mid-scan line too, where VSCL isn't properly loaded at higher resolutions.
Guess the way to get more of that sorted is to bang on the chip some, and post what is found [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/2/2010 7:54:48 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The documentation we have is plenty good enough for most use case purposes. Obviously, going to exploit the hardware in new ways, requires knowing some special case information.
It seems to me, the time and materials cost of such an extensive characterization, in the hopes that it would provide enough detail to make some "off label" uses productive, without a discovery phase to vet the idea first, seems a losing proposition.
Look at it this way: The vast majority of people will use it to generate video. Some will use it for audio, and some will use it for other things, all within the scope of the docs we have. Eric's contributions actually extend those considerably, improving the state of things to the point where only some very small details, which remain unimportant to nearly everyone, are missing.
Seems to me, the burden for working through that new idea lands on those wanting to pioneer, so that those documents could actually be written! For the purpose of generating video, we've got very good docs. For some specialized cases, such as my artifacting, and some pushing of the waitvid as several of us have done, we learned of some timing data, and that sync between PLLA and the chroma phase counter is difficult. Those are niche things!
I think a larger company, of sufficient size to make those kinds of investments profitable, may find it makes sense to grind through all of it. In this case, it's an awful lot of work with a very low potential return.
Lots of hacking on chips happens every day, with one hell of a lot less info than we've got for this one, that's all.
And the comment about a spec is interesting. I don't think there was one! Basically, it was built to generate the video in a specific way, then tested for that higher level functionality. Below the scope of that, it's new territory, and that's somewhat typical of software dependent video generator hardware that I've seen. A quick look at older hardware of this type shows a loose specification that meets rather conservative requirements. That is followed by development actually pushing the hardware over time to meet considerably more aggressive requirements that essentially become possible because of the flexible and general purpose nature of the silicon, when grey matter is applied to it over time.
If the chip were actually spec'ed, we would know the scope of it's capabilities, and most interestingly, pushing them would actually require the hardware operate beyond the specifications, or be buggy! Interesting no?
That's the core disconnect that's been bugging me on this thread anyway.
[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/2/2010 9:21:58 PM GMT
I look at this as similar to the Atari 2600 TIA chip. For a long while no-one really understood why it behaved and misbehaved in certain ways. For example, the TIA has a strobe register HMOVE, which adds a delta to the sprite position registers when written to at the beginning of the line. It also has the side effect of blanking the video at the start of the line. This was the known behaviour. But naturally some asked "what happens if HMOVE is written in the middle of the line, or twice in quick succession?" So people experimented and codified the results. Why it behaved in this way was still unknown, but enough was known that this previously unknown behaviour could be exploited. Later the gate level diagrams were released and people determined why HMOVE behaved the way it did, but the results were actually known.
My explanation of the video generator comes from the available documentation, some of Chip's forum posts (i.e. the color counter), fiddling around myself and seeing the results, and asking myself "how would I build it?".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
It is strange to hear people saying we do need this spec. Though I can guess few reasons for such answers :
So now I am asking Parallax : are there specs for video generator? If yes - would you publish them, if no - would you consider writing?
Re: #1 What we have is what there is.
(I would be surprised to see more, as it would have been published already.)
Re: #2 I personally do not need it kind of applies, but not in the way you think. The bottom line is I know there isn't a lower level spec, due to how the chip was built, and why it was built the way it was. It's necessary to get that information, but only when the existing info isn't enough, and when that's the case, one just runs the tests to understand both how things work, and whether or not that use case makes sense.
One such case was overlaying the output of two generators on the same pins. On VGA, and TV monochrome this is possible and practical. On TV color, it's not because the relationship between the chroma phase counter and PLLA is not consistent between generators and COGs, even when the PLLs are running in sync. The amount of documentation required to make that fact known would have been huge, and that was not a defined, and specified use case in place at the time of the design. It was however fairly easy to realize once some code had been written and people could examine the output. It was also determined at that time, the effort required to sort that out, if it was possible to sort out, wasn't warranted. The use case was not particularly valuable, given there are other methods to get the same thing done, and doing it exactly that way just wasn't worth it.
Generally speaking, the level of information detail you are asking for exceeds that required for the practical use cases. So then, for most people, it's not necessary. This is consistent with wanting to pioneer some new use of the hardware, BTW.
Re: #3 You will quickly find this crowd isn't one where the keeping of those kinds of secrets makes any sense.
The simple truth is we have the information we have, and we have that information that has been added through tests and use cases done by others, with some very specific elements of that put on this thread for your consumption. The rest resides in the code published to date (which is damn near all the code ever written), and in forum threads that are here for a bit of research. That, mind you, is something that might come to mind, given a use case, but is hard to just go and scoop up, just because.
The other simple truth is that getting the information you are asking for is a *LOT* of work. What are you needing to do that would warrant that work? Fair question.
Re: We do not need it. That wasn't said. What was said is that it's not necessary for the vast majority of use cases. It also was said that producing it involves a significant effort, with very little return. Finally, needing it was expressed. Always good to have more information, however the burden for producing it currently lies with those looking to use the video hardware beyond the scope of the use cases covered by the documentation we have, and that others have contributed to date.
Nobody is hiding anything from you. However, the implication that others are somehow under a burden to supply that detail information, without a demonstrated use case is kind of odd, which is why I posted what I did. For the purpose of generating video, the existing docs are great. They meet the need, and document the supported use case of video. Why do anything else, given the effort required? That's where the burden is, and that's not personal, just the current state of things.
What is that use case? I think answering that might help. At first, you commented that you are not satisfied with existing code. Cool! How is it lacking, and what would you like to do differently? That discussion will probably spark some interesting commentary, and we all learn something. Several of us here think that's an entertaining discussion.
Re: Go do it yourself. Yes, to a degree this is true, for reasons stated. This isn't personal either. What it comes down to is nobody knows what the goal of the effort would be, other than to document the chip to a higher degree. Some of that's been done, because people had a use case where it mattered, and where that happened, several jumped into clarify what was learned. Without that, the whole discussion is rather difficult.
Edit: Truth is, the video capability of the Propeller was originally intended as a modest, and effective software video system. The bare minimum of silicon was added to accomplish this task as 2 and 4 color tile, sprite, bitmap graphics. Because that original spec was open ended, as in the fewest number of functions were committed to silicon, leaving the rest to software, ways have been found to extend that capability significantly.
Ways that would simply not exist, if the specification were more complete and locked down. So then, you are quite literally asking for information to support new ideas, without actually hinting at what those new ideas are. That's the disconnect here. The moment you say, "I'm here, and it's not working for me", then people can take what they know, and help understand why that is, and whether or not it's possible. Building a body of information, prior to that time, that would answer the question is simply premature, all things considered.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 5:35:31 AM GMT