Plugging a wire into the RCA plug! (thats all). You may want to make it a length that is a 1/4 length of the carrier frequency to increase the range, but this isnt nessesary.
So awesom Jon!
In case you can't tell, I'm so ready to pre-order...
I'll need some cash... anyone want to purchase some used but functional commodore C64 equipment?
I Almost cant wait... a whole month... or two... [noparse]:)[/noparse]
Good things come to us who wait, but waiting can be so tedious to tolorate!
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK ·
You have to change a few configuration bits in the video driver and connect a short length of wire to the RCA connector.· You're on you're own with the FCC -- this is purely for educational purposes.
KenLem said...
What additional components are required to broadcast video?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Jon Williams Applications Engineer, Parallax
video demystified is a must read for anyone that wants to understand the plethora of video standards including my personal nightmare "PAL" [noparse]:)[/noparse] Anyway, as noted we are going to release all of our engines, overlay technology, etc. and the demos all open source (GNU/GPL like license, basically do anything you want, just don't sell the stuff and give credit to the authors).
Coding graphics or sound engines on the propeller or any microcontroller isn't for the faint of heart, but the cool thing about the Propeller that gives it a HUGE advantage of other chips is that graphics, sound etc. can all be DECOUPLED from your mainline execution since they can run on seperate Cogs. For example, what makes the XGamestation so hard to program (and fun for me), is that the "program" is the "game" AND the "video driver", you have to really WORK to integrate all the timing into one. Most of our tile games on the XGS work with·a form of multitasking, where the mainline is the video kernal then during the VBLANK we run game logic.
On the PChip you can focus on simply making a graphics engine that draw bitmaps or tiles THEN forget about it. I·can tell you one thing, the PChip is·by far the easiest parallel computer I have programmed. On the Pentium processors·they started with·the·"U" and "V" pipes on the PI, game programmers·and graphics engine developers struggled to get the execution units to run in parallel, then with multiple·execution units and the SS2 (SIMD stuff) on the Pentium 4+, parallel techniques are VERY complex and take·days, weeks of planning to get max performance. The PChip's macro parallel processing is very cool, literally with a couple lines of code you have·another processor running at 100%, the hardest thing is just waiting for the memory hub to come around, so the challenge is simply to maximize what you are doing while you wait to maximize potential bus bandwidth.
In any case, the engines we have already made are more than enough to do ISO RPG or any kind of platformer with full 8-bit color, and sprites, etc. and all will be included in source format, so you can remodulate them at will [noparse]:)[/noparse] and focus on your game play and or application programming. Additionally, we are working on VGA demos and engines as well, so hopefully there will be more than enough to turn everyone's brains to mush until the Hydra 2 comes out! But, its cool seeing this stuff iterate, our 2nd and 3rd generation demos are starting to surface, of course you guys will get gen 1 thru n all at once. But, its amazing to see each generation of game change, its like the Playstation I, the games that came out on it at first were great for the time, but that games on the PS 1 (same hardware) NOW are amazing, they have pushed the 10 year old hardware to its limits, that what we are trying to do here, we are going to save everyone 5-10 years of R&D and show you what can be done along with full source code. For example, I am looking at our first breakout to our current breakout, (the demo reel had the last breakout, previous generation), when·I look at the difference its like looking at a completely different system. So we are having a lot of fun and we have BARELY scratched the surface of what can be done with the PChip, everyone is still in the normal "insane demo coder mode", soon they will all be programming in "Jedi master mode" and we will have the PChip standing sideways spining around dancing and shifting in and out of space time [noparse]:)[/noparse]
Lastly, I am working on the user manual·for the Hydra, basically an introduction to the Hydra, Propeller and Basic game programming on the system, so nothing crazy, there will be VERY basic ASM tile engines etc. that are explained in detail. I am confident that EVERYONE will be able to write their own ASM video drivers, etc. if they wanted to --
Maybe I will post a "mini" tile engine on here, if there is enough interest???
Glad to know it should handle an ISO RPG quite easily. I think it would be cool to see a "mini" tile engine. One concern I have is what is the "maximum" memory you could put together in a cartridge for the Hydra?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truth can be dangerous... Trust can be deadly.
The Hydra cartridges come in 3 sizes; 32, 64, 128K. Its eeprom memory, so has a maximum speed of 400Kbits/sec transfer rate, so you can't execute code directly from it, thus the idea is to store assets and code and then cache it a ram buffer. After the Hydra releases, I will design some more "exotic" expansion carts for the system. But, with 32K we have done·a lot, so 128K should prove to be enough to do all kinds of stuff. Also, the Hydra has 128K onboard eeprom as well, FYI.
This site teaches everything you need to know. NTSC is such an elegant concept. The way color was later worked into the·black/white protocol was ingenious. PAL is a silly European variation of NTSC that is overly-complicated and historically expensive. SECAM, a further French twist, remains incomprehensible to me. It stands for "Systemme Electronique Colour Avec Memoire". Some people say SECAM stands for "Something Essentially Contrary to the American Method". Contrary it is, and its performance is known to be lousy: "SEcond Color Always Magenta".·Currently, our TV.spin object can output NTSC and PAL, only. It's entirely possible for the Propeller to output SECAM. Someone will just have to figure out what is required signal-wise. I looked around and read all kinds of things and I couldn't "get it". I've heard that wherever SECAM is used, the newer TV's can understand PAL, too. SECAM is mainly used in former East Bloc countries and the Middle East.
During the Propeller development, a lot of effort went into building many different state machines to generate TV and·VGA signals. After a lot of work, it became apparent that one simple machine could do both: VGA generation is a subset of TV generation. Once you have a VGA machine, you can add a modulator to generate chroma phase, at the expense of raw output bits, and get a TV signal, too. Once the requirements were understood, a single circuit was designed to do both. The Propeller COGs' video circuits are very simplistic, actually, and I intend to have some documentation ready soon to explain their operation. Basically, they run from synthesized clocks and take over the task of scheduled pixel/sync output, plus modulation for TV. The COG must keep it fed every 16 pixels, or so, with updated pixel/color data. Andre's team had it doing things in a few weeks that I didn't think were possible, like tile engines with up to 8 sprites per scan line. I'm very anxious to see what people will achieve over time.
Chip Gracey said...
NTSC is such an elegant concept. The way color was later worked into the black/white protocol was ingenious.
I'll second that! Black and white TV conveyed picture intensity and synchronization information only. The very notion of adding a subcarrier with phase denoting hue, and amplitude denoting saturation was nothing short of brilliant -- especially considering that it was backwards compatible with B/W TVs. But the fact that this was even possible in 1953 using tube-based analog circuitry only adds to the wonder of it all!
The 'only' problem with NTSC is the tendency for the colours to drift, resulting in blue football-fields and similar fun...
As I understand it, NTSC stands for Never Twice Same Color...
Yes, PAL is more complicated, but when the signal suffers degradation, all that happens is that the colours lose some intensity, so that the brilliantly green football-fields stay green, albeit a washed-out green...
Replace football with Soccer, Baseball, Golf, Tennis, Cricket or any other sport played on a green field...
PAL is also backwards compatible with B/W sets, as I should well know.
(We didn't get a Colur TV at home until about 1980...)
BTW: PAL stands for Perfect At Last...
and isn't used only in Europe, but in Japan, South America and a few other places...
Oh, and the SECAM version used in the former East Bloc countries is a variation on the SECAM, and NOT compatible with the French version.
That would have made it easier for the citizens/comrades to watch unapproved programs...
I think I'll be satisfied with using Composite Video...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Ok...
If I understand this correctly, you have VGA, and from that you get NTSC, right?
Well, Andre', I cant wait to get the pricing for the hydra PChip, and documents...
This is so kewl, being "part" of the birth and begginings of something as "hot" as the PChip.
I've so many ideas, and all limited by the hardware... and this appears to be a "key" answer...
...
Off to do some "required reading"
[noparse]:)[/noparse]
...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
although NTSC might also stand for National Television Standards Committee, I agree with you that it actually abbreviates Never Twice The Same Color. Where this is only true when the TV signal is transmitted and received "through the air". Reflections, and other nasty things applied to the radio waves from the TV transmitter to your receiver can cause such false color information. When you hook up an NTSC monitor directly to an NTSC video source, such problems should not occur.
On the other hand a German engineer at Telefunken, Dr. Bruch once invented the PAL system. PAL can also stand for Pay for Additional Luxury but actually is the abbreviation for Phase Alternation Line. The trick here is that the received TV signal is delayed for the time of one video scan line, and the color information is sent with alternating phases from line to line. So the receiver can take the current and the delayed line's color information which is out of phase by 180° to compensate any phase shifts in the signal on its way from the transmitter to the receiver.
BTW: Instead of calling this the PAL system, some people at Telefunken had the idea to call it after the inventor, Dr. Bruch. Unfortunately, "Bruch System" in German language means something like "junk system", so they pretty soon forgot about this idea.
Finally, SECAM was first designed in France - a bit different from PAL - but French people seem to have the tendency to be a "bit different". As far as I know, SECAM means "Systeme Elegante Contre l'AMerique" .
Doing games means controlling rasters and back in the late 70's and 80's we had to do it manually, so the NTSC signal standard is as chip says amazing. You can follow it 100% or completely break the rules and it still works good. Chip's tv driver follows the spec very closely, but you can write a driver that does NOT and it will still work. The thing about NTSC is as long as you are consistent in your breaking the rules it still works, I am sometimes amazed at how badly you can break the rules and get a perfect raster on all sets. Of course, there is one unfortunete thing -- LCD displays are REALLY anal about the spec and you will find that working with LCDs is very hard, the display has to be nearly perfect, same goes with plasma tv's etc., anything with "new" digital tuners that support all the new formats.
Additionally, I have researched tv development, and a lot of people probably don't know this, but the first raster display system was developed not in the 1940s, 1930's, 1900's --- but
the LATE 1800s!!!!
Around 1890 something there were rudimentary raster systems already being experimented with, I did a talk on NTSC at a conference, and found one particular system where a 18 line raster system was developed in something like 1880-1890's range -- these were of course built on the first "cathode ray" systems. So the amazing thing is this, imagine over ONE HUNDRED YEARS AGO there were guys so smart, with no internet, no digikey, no nothing that were doing this stuff and the system they devised based on quantum theory STILL is in use today and STILL isn't easy for us to understand -- so just goes to show that we aren't as smart as we think we are -- [noparse]:)[/noparse]
Yes, the VSCL is double buffered and will be buffered until the next waitvid picks up the colors and the pixels. On the same subject, VCFG is NOT double buffered, however, typically you wouldn't need to change this during live video, but if you wanted to change it then the best bet would be to do it during a h or vsync time, when you wouldn't see any fuzzy video as a result.
Chip Gracey (Parallax) said...
It's entirely possible for the Propeller to output SECAM.
After over 3 years, has anybody figured out how to do this?
The problem is color in SECAM is fundamentally different from NTSC & PAL - the chroma signal is FM modulated, not AM modulated.· (The luma signal is the same as PAL,·thus B&W SECAM is definitely possible.) So the question is whether the Propeller can generate Y(t) + cos( (F+f*c) * t ).
Okay, thinking about it in that case, I think it's definitely possible, but it will require more effort than NTSC and PAL because the cog will have to generate the color itself.· The idea is to use counter B in NCO mode outputting to the 4th pin.· Then after each WAITVID, the cog updates FRQB to change the color.· This will seriously limit the color resolution.· If a cog is dedicated to generating color, and the colors are buffered in cog RAM, then it would take 12 cycles per color change, or around 300 active pixels per line.· (Actually, that's not bad.· It would require a huge number of cogs though.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
For SECAM the color difference signals are sent on alternating lines - red/cyan on odd lines (as 4.12625MHz - 4.68625MHz) and yellow/blue on even lines (as 4.02MHz - 4.48MHz). Translating those frequencies to FRQB values with an 80MHz clock yields 19-17 and 20-18, or a total of 9 distinct colors221,526,360 - 251,591,131 and 215,822,106 - 240,518,168. The video generator could be used to "force" grayscale by using VGA mode (to allow the 4th pin to be controlled) and then forcing the 4th pin high (masking off CTRB output).
Now, if someone (with the appropriate SECAM equipment) has the desire to code a SECAM driver, I will provide whatever assistance I can. But I think this is as far as I will go on my own.
Chip Gracey (Parallax) said...
It's entirely possible for the Propeller to output SECAM.
Although this statement is factually correct, the Propeller (I) video generator cannot generate a SECAM FM chroma signal. A program controlled frequency generator is required to generate color, which will significantly impact the usability and prevent a "drop-in" SECAM replacement for TV.spin.
(edit - fixed the FRQB values)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Post Edited (ericball) : 10/13/2009 10:57:37 AM GMT
I have no SECAM video, but this seems to me like something that could be cleverly artifacted using
NOT any of the frequencies above, but perhaps their sum and difference, and some kind of logic
controlled phase shifting mixing using the chroma carrier feature and the aural carrier feature and
I imagine (although vaguely) that something like a 74HC4052 may be sufficient for doing.
I know you can make a colorbar test pattern in NTSC using just gray levels and around 3.7 MHz as the
chroma frequency with nothing but a few SN7400 TTL chips. I have a cheap video test pattern generator
that meets that description and also has convergence test patterns without color. But my point is,
the colors come from the apparently continuous phase shift of the Chroma signal across the raster,
since the horizontal rate frequency is approximately added to the normal chroma frequency.
I imagine a technique which results in more abrupt apparent frequency shifts which would be partly
corrected by the switching action of the dual 4-way switch chip 4052 and partly by the driver itself.
For example, maybe two frequencies appear alternating on one line and two others on the other,
the pair selection controlled by the driver via the 4052, and maybe alternating pixels have opposing
colors which the driver fixes by XORing values before loading the video shift register.
Also, it seems to me that this works almost like the phasing of the chroma carrier in NTSC color... hey there's
another phase modulator! Phase modulation and FM modulation are similar enough to be substituted
for one another when necessary. Now the results I imagine will be a little bit different than for NTSC, since
...I think you'll get the 7 gray levels, 16 Saturation levels, and maybe only 4 almost primary colors,
unless you do something much different than my vague idea which makes sense to me with experimental
video experience in general but specifically lacking SECAM. I once thought that SECAM was like
sequential R,G,B lines but based on info above it seems more like PAL or more precisely Frequency Alternating Lines.
VIRAND said...
Also, it seems to me that this works almost like the phasing of the chroma carrier in NTSC color... hey there's another phase modulator! Phase modulation and FM modulation are similar enough to be substituted for one another when necessary.
That's an interesting thought. The Propeller video generator outputs Y(t) + cos(F*t + p*c(t)). So then the question is whether you could fake Y(t) + cos( (F+f*c(t)) * t ) with it.
Line sequential RGB was tried in the pre-NTSC days.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
In case you can't tell, I'm so ready to pre-order...
I'll need some cash... anyone want to purchase some used but functional commodore C64 equipment?
I Almost cant wait... a whole month... or two... [noparse]:)[/noparse]
Good things come to us who wait, but waiting can be so tedious to tolorate!
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
What the Propeller is capable of video-wise, and what Andr
Thanks for the offered reading matieral.
Anyone else have reading suggestions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Coding graphics or sound engines on the propeller or any microcontroller isn't for the faint of heart, but the cool thing about the Propeller that gives it a HUGE advantage of other chips is that graphics, sound etc. can all be DECOUPLED from your mainline execution since they can run on seperate Cogs. For example, what makes the XGamestation so hard to program (and fun for me), is that the "program" is the "game" AND the "video driver", you have to really WORK to integrate all the timing into one. Most of our tile games on the XGS work with·a form of multitasking, where the mainline is the video kernal then during the VBLANK we run game logic.
On the PChip you can focus on simply making a graphics engine that draw bitmaps or tiles THEN forget about it. I·can tell you one thing, the PChip is·by far the easiest parallel computer I have programmed. On the Pentium processors·they started with·the·"U" and "V" pipes on the PI, game programmers·and graphics engine developers struggled to get the execution units to run in parallel, then with multiple·execution units and the SS2 (SIMD stuff) on the Pentium 4+, parallel techniques are VERY complex and take·days, weeks of planning to get max performance. The PChip's macro parallel processing is very cool, literally with a couple lines of code you have·another processor running at 100%, the hardest thing is just waiting for the memory hub to come around, so the challenge is simply to maximize what you are doing while you wait to maximize potential bus bandwidth.
In any case, the engines we have already made are more than enough to do ISO RPG or any kind of platformer with full 8-bit color, and sprites, etc. and all will be included in source format, so you can remodulate them at will [noparse]:)[/noparse] and focus on your game play and or application programming. Additionally, we are working on VGA demos and engines as well, so hopefully there will be more than enough to turn everyone's brains to mush until the Hydra 2 comes out! But, its cool seeing this stuff iterate, our 2nd and 3rd generation demos are starting to surface, of course you guys will get gen 1 thru n all at once. But, its amazing to see each generation of game change, its like the Playstation I, the games that came out on it at first were great for the time, but that games on the PS 1 (same hardware) NOW are amazing, they have pushed the 10 year old hardware to its limits, that what we are trying to do here, we are going to save everyone 5-10 years of R&D and show you what can be done along with full source code. For example, I am looking at our first breakout to our current breakout, (the demo reel had the last breakout, previous generation), when·I look at the difference its like looking at a completely different system. So we are having a lot of fun and we have BARELY scratched the surface of what can be done with the PChip, everyone is still in the normal "insane demo coder mode", soon they will all be programming in "Jedi master mode" and we will have the PChip standing sideways spining around dancing and shifting in and out of space time [noparse]:)[/noparse]
Lastly, I am working on the user manual·for the Hydra, basically an introduction to the Hydra, Propeller and Basic game programming on the system, so nothing crazy, there will be VERY basic ASM tile engines etc. that are explained in detail. I am confident that EVERYONE will be able to write their own ASM video drivers, etc. if they wanted to --
Maybe I will post a "mini" tile engine on here, if there is enough interest???
Andre'
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truth can be dangerous... Trust can be deadly.
Andre'
·
Here is where·all of the know-how came from to make the Propeller·chip generate TV signals:
http://www.ntsc-tv.com/
This site teaches everything you need to know. NTSC is such an elegant concept. The way color was later worked into the·black/white protocol was ingenious. PAL is a silly European variation of NTSC that is overly-complicated and historically expensive. SECAM, a further French twist, remains incomprehensible to me. It stands for "Systemme Electronique Colour Avec Memoire". Some people say SECAM stands for "Something Essentially Contrary to the American Method". Contrary it is, and its performance is known to be lousy: "SEcond Color Always Magenta".·Currently, our TV.spin object can output NTSC and PAL, only. It's entirely possible for the Propeller to output SECAM. Someone will just have to figure out what is required signal-wise. I looked around and read all kinds of things and I couldn't "get it". I've heard that wherever SECAM is used, the newer TV's can understand PAL, too. SECAM is mainly used in former East Bloc countries and the Middle East.
During the Propeller development, a lot of effort went into building many different state machines to generate TV and·VGA signals. After a lot of work, it became apparent that one simple machine could do both: VGA generation is a subset of TV generation. Once you have a VGA machine, you can add a modulator to generate chroma phase, at the expense of raw output bits, and get a TV signal, too. Once the requirements were understood, a single circuit was designed to do both. The Propeller COGs' video circuits are very simplistic, actually, and I intend to have some documentation ready soon to explain their operation. Basically, they run from synthesized clocks and take over the task of scheduled pixel/sync output, plus modulation for TV. The COG must keep it fed every 16 pixels, or so, with updated pixel/color data. Andre's team had it doing things in a few weeks that I didn't think were possible, like tile engines with up to 8 sprites per scan line. I'm very anxious to see what people will achieve over time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
As I understand it, NTSC stands for Never Twice Same Color...
Yes, PAL is more complicated, but when the signal suffers degradation, all that happens is that the colours lose some intensity, so that the brilliantly green football-fields stay green, albeit a washed-out green...
Replace football with Soccer, Baseball, Golf, Tennis, Cricket or any other sport played on a green field...
PAL is also backwards compatible with B/W sets, as I should well know.
(We didn't get a Colur TV at home until about 1980...)
BTW: PAL stands for Perfect At Last...
and isn't used only in Europe, but in Japan, South America and a few other places...
Oh, and the SECAM version used in the former East Bloc countries is a variation on the SECAM, and NOT compatible with the French version.
That would have made it easier for the citizens/comrades to watch unapproved programs...
I think I'll be satisfied with using Composite Video...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
If I understand this correctly, you have VGA, and from that you get NTSC, right?
Well, Andre', I cant wait to get the pricing for the hydra PChip, and documents...
This is so kewl, being "part" of the birth and begginings of something as "hot" as the PChip.
I've so many ideas, and all limited by the hardware... and this appears to be a "key" answer...
...
Off to do some "required reading"
[noparse]:)[/noparse]
...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
although NTSC might also stand for National Television Standards Committee, I agree with you that it actually abbreviates Never Twice The Same Color. Where this is only true when the TV signal is transmitted and received "through the air". Reflections, and other nasty things applied to the radio waves from the TV transmitter to your receiver can cause such false color information. When you hook up an NTSC monitor directly to an NTSC video source, such problems should not occur.
On the other hand a German engineer at Telefunken, Dr. Bruch once invented the PAL system. PAL can also stand for Pay for Additional Luxury but actually is the abbreviation for Phase Alternation Line. The trick here is that the received TV signal is delayed for the time of one video scan line, and the color information is sent with alternating phases from line to line. So the receiver can take the current and the delayed line's color information which is out of phase by 180° to compensate any phase shifts in the signal on its way from the transmitter to the receiver.
BTW: Instead of calling this the PAL system, some people at Telefunken had the idea to call it after the inventor, Dr. Bruch. Unfortunately, "Bruch System" in German language means something like "junk system", so they pretty soon forgot about this idea.
Finally, SECAM was first designed in France - a bit different from PAL - but French people seem to have the tendency to be a "bit different". As far as I know, SECAM means "Systeme Elegante Contre l'AMerique"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Additionally, I have researched tv development, and a lot of people probably don't know this, but the first raster display system was developed not in the 1940s, 1930's, 1900's --- but
the LATE 1800s!!!!
Around 1890 something there were rudimentary raster systems already being experimented with, I did a talk on NTSC at a conference, and found one particular system where a 18 line raster system was developed in something like 1880-1890's range -- these were of course built on the first "cathode ray" systems. So the amazing thing is this, imagine over ONE HUNDRED YEARS AGO there were guys so smart, with no internet, no digikey, no nothing that were doing this stuff and the system they devised based on quantum theory STILL is in use today and STILL isn't easy for us to understand -- so just goes to show that we aren't as smart as we think we are -- [noparse]:)[/noparse]
Andre'
Andre'
Okay, thinking about it in that case, I think it's definitely possible, but it will require more effort than NTSC and PAL because the cog will have to generate the color itself.· The idea is to use counter B in NCO mode outputting to the 4th pin.· Then after each WAITVID, the cog updates FRQB to change the color.· This will seriously limit the color resolution.· If a cog is dedicated to generating color, and the colors are buffered in cog RAM, then it would take 12 cycles per color change, or around 300 active pixels per line.· (Actually, that's not bad.· It would require a huge number of cogs though.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Now, if someone (with the appropriate SECAM equipment) has the desire to code a SECAM driver, I will provide whatever assistance I can. But I think this is as far as I will go on my own. Although this statement is factually correct, the Propeller (I) video generator cannot generate a SECAM FM chroma signal. A program controlled frequency generator is required to generate color, which will significantly impact the usability and prevent a "drop-in" SECAM replacement for TV.spin.
(edit - fixed the FRQB values)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Post Edited (ericball) : 10/13/2009 10:57:37 AM GMT
NOT any of the frequencies above, but perhaps their sum and difference, and some kind of logic
controlled phase shifting mixing using the chroma carrier feature and the aural carrier feature and
I imagine (although vaguely) that something like a 74HC4052 may be sufficient for doing.
I know you can make a colorbar test pattern in NTSC using just gray levels and around 3.7 MHz as the
chroma frequency with nothing but a few SN7400 TTL chips. I have a cheap video test pattern generator
that meets that description and also has convergence test patterns without color. But my point is,
the colors come from the apparently continuous phase shift of the Chroma signal across the raster,
since the horizontal rate frequency is approximately added to the normal chroma frequency.
I imagine a technique which results in more abrupt apparent frequency shifts which would be partly
corrected by the switching action of the dual 4-way switch chip 4052 and partly by the driver itself.
For example, maybe two frequencies appear alternating on one line and two others on the other,
the pair selection controlled by the driver via the 4052, and maybe alternating pixels have opposing
colors which the driver fixes by XORing values before loading the video shift register.
Also, it seems to me that this works almost like the phasing of the chroma carrier in NTSC color... hey there's
another phase modulator! Phase modulation and FM modulation are similar enough to be substituted
for one another when necessary. Now the results I imagine will be a little bit different than for NTSC, since
...I think you'll get the 7 gray levels, 16 Saturation levels, and maybe only 4 almost primary colors,
unless you do something much different than my vague idea which makes sense to me with experimental
video experience in general but specifically lacking SECAM. I once thought that SECAM was like
sequential R,G,B lines but based on info above it seems more like PAL or more precisely Frequency Alternating Lines.
Line sequential RGB was tried in the pre-NTSC days.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum