Post by thread:[sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall

SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and Contest Ok, its time for us Scenix users to put this PIC video thing to rest... We alone have the speed required in a low cost micro controller to really make it happen! Just a few thoughts: Even at 50MHz on an Scenix SX (and the 100Mhz SX52's are working nicely), the 52uS video line on a standard TV allows for up to 2600 instructions. At 40 columns that would be 65 instructions per column. 320 dots per line (8 dots per column) would allow 8 instructions per dot. Enough to be shifting out bits by rotating port A interleaved with indexing a table and looking up the next character dot line value? 256 dots per line would allow 10. http://www.efd.lth.se/~e96rg/mc/video/rtvideo.html The lack of memory is the major limiting factor. With the 52 and about 200 bytes of RAM, we could try for a 40 character by 5 line display. Or 20 x 10. And if you are displaying only numbers... in BCD that is 400 digits. (...last 40 Caller ID numbers?, ...video paper tape for a calculator?, etc...) And there is enough time (about 600 instructions) between lines to do some unpacking of the next line... www.sxlist.com/techref/method/compress/embedded.htm www.sxlist.com/techref/method/compress.htm www.sxlist.com/techref/scenix/lib/math/radix/index_sx.htm ...or reading in a new line from an external serial RAM http://www.sxlist.com/techref/mem/srams.htm FRAM is $2.95 each for the 2kByte part To generate character data for 128 characters, a 5 x 7 character matrix is 640 bytes of data in FLASH (hard to rotate though...). Or 1536 bytes with a 8 x 12 matrix. Use IREAD so you won't have any problems with big tables. Really only need 95 characters. The data is already done for you: http://www.sxlist.com/techref/datafile/charsets.htm Here is the current "state of the art" in PIC video character generation. www.efd.lth.se/~e96rg/mc/mc.html#softvideo www.efd.lth.se/~e96rg/mc/mechanic/232disp.html http://www.rt66.com/dthomas/pic/vidclock.html http://www.brouhaha.com/~eric/pic/pictock.html http://www.tinaja.com/glib/muse134.pdf http://www.ubasics.com/adam/pic/archive/picdream.zip In graphics, 200 bytes is only 1600 dots.. maybe 32 by 50 on the screen. The gameboy is 160x144. It might be more interesting to make larger "sprites" in FLASH instead of characters and work out a way to position them anywhere on a 256 x 256 grid. http://www.rt66.com/dthomas/pic/pong.html http://www.brouhaha.com/~eric/pic/picpong.html http://www.efd.lth.se/~e96rg/mc/video/tetris.html Why bother? - Drop-in Big Screen replacement for an LCD panel. Very nice when you need to see the status of the device you are operating from across the room. - Combine with RF modulator and small antenna for a wireless status display from a device in motion... bio monitor, robot, RC car or plane, etc... Could also overlay video from an on-board camera. Battery level, debugging info, etc... - TV overlay kitchen timer. Bake the cake while watching Opra. - General use: Much cheaper than an LCD panel since you already have a TV. - Worlds smallest (SMT) video game? School project for the terminal Playstation addict. Maybe use a standard LCD portable TV. Do they have video inputs? RF Modulator? - A small device for the deaf that says "telephone is ringing" etc... on the TV. Add caption decoding to older TV's? - All of which pale in comparison to the #1 reason why this would be a cool thing to do... ...its a really neat HACK! Also, I like CRT's better than LCD's... So... I'm announcing the first sxlist.com challenge! I will pay $100, give away some SX's and do a big write-up on the site for the first person who can make a 20 character by 4 line NTSC output, standard Hitachi 44780 command (or RS232 or SPI or I2C or... anything useful) input, LCD replacement using an SX processor, some resistors, and the right code! http://www.sxlist.com gets about 10,000 hits a day from 500 or so visitors (distinct IPs) and I will proclaim that you are an SX Master on every page for a week with a link to the full write-up of your accomplishment. Now, if money is what motivates you, and the exposure doesn't bring you any new customers, you can re-write the code with what you learned (its always better the second time around), add the RS232 hardware and virtual peripheral and sell the unit. Intelligent LCD controllers with 20 x 4 LCD's (and an RS232 input) cost better than $100. Even if you don't already have a TV (or need a bigger display) you can buy a 9" professional video monitor for less than that or a little TV (no video input need RF modulator) for $39 or even a color unit (with CATV input) for $100 so you might have a Serial Backpack(tm) killer. (Serial Backpack is a registered trademark of Scott Edwards electronics) http://www.seetron.com/bpp420_1.htm $79.00 if you can get 40 x 4 it would replace the BPP440 http://www.seetron.com/bpp440_1.htm $159.00 Or build up some competition for bob: http://www.decadenet.com/bob2/bob2.html http://www.decadenet.com/bob2/screensht.htm Fine print: - With the finished unit, you should be able to unplug the LCD and 44780 (or RS232 terminal, etc...) from any device and plug in the TV. 4 or 8 bit interface (either one) is fine. See here for 44780 details: http://www.sxlist.com/techref/io/lcd/44780.htm - Must respond to cursor positioning commands as a minimum. I'd really like to see all the features of the 44780. It would be cool to add some TV typewriter ability... but leave that for somebody's project or product down the road. - Minimum of 64 symbols in the character set although I'd probably settle for ten (0...9) if the source code was not terribly difficult to extend to 64 or 96 characters for other applications. It would be good to be flexible on that point as the trade off between character set bitmap data and application program space is likely to be an issue. A numerical only character set would free up a lot of code space for calculating the numbers to be displayed! - Must work with both PAL and NTSC. Just make it possible to change the number of lines in each frame between 625 and 525 and you cover the world! - No restrictions on clock speed. I'd be most happy to see something slower due to power consumption issues and because you can always re-write tight code to make it run slower on a faster processor but the other direction... <GRIN> It might also be good to look at some "best common fit" between baud rates and video... the RS232 ISR Timing Calculator at http://www.sxlist.com/techref/scenix/lib/io/osi2/serial/rs232_sx.htm or www.sxlist.com/techref/scenix/isrcalc.asp might be helpful. - The source and design must use a Scenix SX and be GPL'd. - I'm the judge, jury and executioner, no-one comes to the money except by me, my decisions are final. ...Always wanted to say that... - The contest will run from now until the end of January 2001. About 2 months. Something to do over the holidays. - I WILL award at least half the prize money to SOMEONE and I will post all entries to the site so send in what you have even if it's not perfect. Happy hacking! James Newton 1-619-652-0593 spam_OUTjamesnewtonTakeThisOuTsxlist.com SX FAQ: http://www.sxlist.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

You need to specify what additional hardware is acceptable. While you can certainly do it with the processor alone, addition of a single dot clocked shift register greatly reduces overhead. Sure, it's then not pure software but if the aim is to be purist rather than allow a $0.20 part you may have to also exclude any external resonator and run with the Scenix internal oscillator (at 4 MHz). After all, the resonator costs rather more than the glue logic needed for a dot clock and shift register. Then we'll see how it compares to a PIC :-). >Ok, its time for us Scenix users to put this PIC video thing to rest... We >alone have the speed required in a low cost micro controller to really make >it happen! While we are on the "we alone have ..." thought, look at the Clive "I can do magic" Sinclair ZX80 which used an ancient and venerable (and venerated?) Z80 plus a shift register to work video magic. It also managed to pretend to be a "full" computer during the flyback period. The CISC set-and-forget block move instruction has it's place :-). I'm sure the Scenix would be hard to beat in this application using a true single chip solution but it does wilt rather on other tasks in the face of some of the competition. Russell McMahon -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Thu, 30 Nov 2000 14:37:08 +1300, you wrote: >You need to specify what additional hardware is acceptable. >While you can certainly do it with the processor alone, addition of a single >dot clocked shift register greatly reduces overhead. >Sure, it's then not pure software but if the aim is to be purist rather than >allow a $0.20 part you may have to also exclude any external resonator and >run with the Scenix internal oscillator (at 4 MHz). After all, the resonator >costs rather more than the glue logic needed for a dot clock and shift >register. Then we'll see how it compares to a PIC :-). If you want to keep the hardware to a minimum, you can of course use an I/O port as a shift register to get one pixel per cycle using rotate instructions - this can work well for character based apps, where you have a gap between bytes to do the reload. The horizontal flyback time gives you enough time to prepare the next line of data. I did this awhile ago for an app generating 6 characters per line at 6MHz. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> While we are on the "we alone have ..." thought, look at the Clive "I can do > magic" Sinclair ZX80 which used an ancient and venerable (and venerated?) > Z80 plus a shift register to work video magic. It also managed to pretend to > be a "full" computer during the flyback period. The CISC set-and-forget > block move instruction has it's place :-). Correct me if I am wrong, but... I believe the ZX80 did _not_ use a block move instruction to do the video. Instead, it set a special flag that indicated that it was about to _execute_(!) video. When this flag was set the opcodes being fetched from RAM were routed to the screen. Of course this would confuse the processor something awful (or else really restrict what could be displayed). So, the hardware would 'jam' a no-op onto the processor's data bus when the video flag was set, regardless of what instruction was fetched from memory. In other words: the program counter of the Z80 became the video refresh address register. > I'm sure the Scenix would be hard to beat in this application using a true > single chip solution but it does wilt rather on other tasks in the face of > some of the competition. Sure would be nice to have a built in USART to shift out the dots. That is how my PIC18C manages to get 432 H x 240 V pixels on the screen, including animated graphics. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

>Sure would be nice to have a built in USART to shift out the dots. That is >how my PIC18C manages to get 432 H x 240 V pixels on the screen, including >animated graphics. And how does that compare with the likely software only Scenix performance using software alone I wonder? RM -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

----- Original Message ----- From: Russell McMahon <.....apptechKILLspam@spam@CLEAR.NET.NZ> To: <PICLISTKILLspamMITVMA.MIT.EDU> Sent: Thursday, November 30, 2000 4:14 PM Subject: Re: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and Contest > >Sure would be nice to have a built in USART to shift out the dots. That is > >how my PIC18C manages to get 432 H x 240 V pixels on the screen, including > >animated graphics. > > > And how does that compare with the likely software only Scenix performance > using software alone I wonder? > Imagine using a scheme where you store 8 pixels in a PORT register, and feed the MSBit to the outputs. Now you could have code that looks like this: movwf PORTx ; output msbit i1 i2 i3 rlf PORTx,F ; move to next bit i1 i2 i3 rlf PORTx,F ; move to next bit i1 i2 i3 where 'i1', 'i2' and 'i3' are instructions that are getting the next byte of pixels ready to send. Note that this gives you 24 instructions to prepare each byte, but they have to be in little groups of 3. I would imagine you'd need at least these 4 instructions per pixel to manage anything reasonable. It would be hard to do anything conditional in fewer cycles. So: PIC = 8 instructions for 8 pixels and SX = 32 instructions for 8 pixels Thus for equivalent resolution the SX would need four times the MIPS as the PIC. My PIC does 10MIPS, so an SX at 40MIPS should be able to manage it. However, it would be _very_ tricky coding! Going to 50MIPs on the SX and 5 instructions per bit might help a lot. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I did some SX "video" to drive a controllerless graphic LCD. The SX generates every pixel for this 240x64 pixel LCD using code. If 26K is not too big, I can post the source files it to the PICList. :-) -- Rich p.s. James, does this count for partial credit in the SX video contest? I know you said you wanted to eliminate LCD's... Russell McMahon wrote: {Quote hidden}> > >Sure would be nice to have a built in USART to shift out the dots. That is > >how my PIC18C manages to get 432 H x 240 V pixels on the screen, including > >animated graphics. > > And how does that compare with the likely software only Scenix performance > using software alone I wonder? > > RM > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Bob: That is a little hard to answer precisely. The code was never optimized so I don't have an exact number. My notes say that there is a perceptible flicker when using a 24MHz oscillator (24 MIPS). A lot of bit shuffling is done to create a large font with 64 pixels per character dot. The dots must then be put into appropriate pixels of the 4 quadrants making up the 240 by 64 pixel graphic display. -- Rich Bob Ammerman wrote: > > {Original Message removed}

Excellent! That code will be very useful for LCD projects. Part of it will undoubtedly apply to the SX video contest, but I hope someone will post a video solution in the future. James Newton, PICList Admin #3 .....jamesnewtonKILLspam.....piclist.com 1-619-652-0593 phone http://www.piclist.com {Original Message removed}

I believe your analysis is specific to graphic (pixel) data from RAM rather than character pixel data from program memory with the character selected by RAM data and that you have not taken into account the SX's IREAD instruction... http://www.sxlist.com/techref/scenix/inst.htm www.sxlist.com/techref/scenix/usersmanual/gohtm/result_86.html which does a one cycle lookup of a memory location any where in program memory (character data) addressed by the combination of the mode register and W and returns a 12 bit result in mode and W. I have a chunk of code written (untested) that will put out a pixel from a character table every other instruction with an extra pixel separation (black) between each character. Any takers? I'll post it tomorrow. James Newton EraseMEjamesnewtonspam_OUTTakeThisOuTsxlist.com 1-619-652-0593 phone http://www.sxlist.com {Original Message removed}

I believe your analysis is specific to graphic (pixel) data from RAM rather than character pixel data from program memory with the character selected by RAM data and that you have not taken into account the SX's IREAD instruction... http://www.sxlist.com/techref/scenix/inst.htm www.sxlist.com/techref/scenix/usersmanual/gohtm/result_86.html which does a one cycle lookup of a memory location any where in program memory (character data) addressed by the combination of the mode register and W and returns a 12 bit result in mode and W. I have a chunk of code written (untested) that will put out a pixel from a character table every other instruction with an extra pixel separation (black) between each character. Any takers? I'll post it tomorrow. James Newton jamesnewtonspam_OUTsxlist.com 1-619-652-0593 phone http://www.sxlist.com {Original Message removed}

This (TOTALLY UNTESTED OF THE TOP OF MY HEAD) code uses RA as the (4 bit) shift register so that only 3 IO lines are wasted. RA.0 is the video out pin. It assumes a 7 x (ScanLines / Rows) character size with each character pixel row stored in the lower byte of a 12 bit program memory word and that there are 256 characters (a kind of a waste but that could be fixed). It assumes that the SX's built in hardware comparitor is being used as a Horizontal Sync detector for an external source of video which is being overlaid with text. ;code for generating a frame of character video using the ;Ubicom (Scenix) SX 18 or 28. See ;http://www.sxlist.com/techref/scenix/contest/video.htm mov RowCout, #Rows :RowLoop mov RowScanLine, #(ScanLines/Rows) ;if you wanted to, you could skip a line of video here (between ;rows) and use the time to load a row of character data from ;external RAM or FRAM ;http://www.sxlist.com/techref/mem/srams.htm :ScanLineLoop jnb HorzSync, $ ;wait for the Horizontal sync. mov ColCount, #Cols mov w, ScanLine ;high pointer into the character generator table mov m, w ;(which character pixel row) mov w, ind ;low pointer into the table (which character) iread :CharScanLoop mov ra, w mov DataHi, W rr ra inc fsr rr ra setb fsr.4 rr ra mov w, <>DataHi mov ra, w mov w, ind rr ra iread rr ra dec ColCount rr ra jnz :CharScanLoop ;And extra cycle or 2 here just spaces the characters a bit more. djnz RowScanLine, :ScanLineLoop djnz RowCount, :RowLoop ;each entry in the character generator table needs to have bits 8..11 (the ;top 4 bits of the 12 bit word) set to the top 4 bits of the address of ;that word so that when M is loaded by the IREAD, its value is retained. ;http://www.sxlist.com/techref/datafile/charsets.htm Well? Does that help? Any comments? Anyone playing with it? --- James Newton 1-619-652-0593 @spam@jamesnewtonKILLspamsxlist.com SX FAQ: http://www.sxlist.com {Original Message removed}

>row stored in the lower byte of a 12 bit program memory word and that there >are 256 characters (a kind of a waste but that could be fixed). how about 4 bit colour ? use msb used for "bright", and the other 3 bits for r g and b... would be impressive to see a colour display from a PIC or a Scenix. Regards, Simon -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Well, the 12 bit data I was talking about was a part of the character generator data (the pixels that make up each scan line of a characters image) so it would always be the same for each character. You could have a red "A" and a blue "B" or a "C" with alternating green and red scan lines ...sounds pretty silly until you think about "sprites" and video games ...or if the characters are images on a playing field (like pacman or a chess board) then hard coded character color makes sense. And how would you find the processing time to display and move the pacman and ghosts? You put out the board on the even frames and (only) the sprites on the odd frame. Some tight programming there, but it could be done (I think). Now, you could take the top bit of each byte of character data (from RAM) and put that out on a second pin to bias the character image a bit lighter or darker ...or use a different scan line loop under each character row to do an underline ...or invert the pixel data for reverse video. --- James Newton 1-619-652-0593 RemoveMEjamesnewtonTakeThisOuTsxlist.com SX FAQ: http://www.sxlist.com {Original Message removed}

> While we are on the "we alone have ..." thought, look at the Clive "I > can do magic" Sinclair ZX80 which used an ancient and venerable (and > venerated?) Z80 plus a shift register to work video magic. It also > managed to pretend to be a "full" computer during the flyback period. > The CISC set-and-forget block move instruction has it's place :-). Wanna buy one? http://users.rcn.com/zebra.interport/ts2/index.html -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

Ummm... no, it hasn't been done with an SX as far as I know... ...which is why I'm sponsoring the contest... see www.sxlist.com/techref/scenix/contest/video.htm for links to the current PIC code, ideas, signal specifications and the challenge and contest rules. --- James Newton 1-619-652-0593 TakeThisOuTjamesnewtonEraseMEspam_OUTsxlist.com SX FAQ: http://www.sxlist.com {Original Message removed}

I've been thinking about sync detect without using an external sync separator. Doesn't seem to be much on the web about doing that with a microcontroller... ...but it also seems to me like it ought to be very possible. Referring to www.sxlist.com/techref/io/video/ntsc.htm if we add a check for a sync pulse in the character loop of the code below, so that it will pick up the sync pulse on the half scan line for even fields, and count scan lines so we know when to stop on the odd fields, we can enter a vertical refresh detection loop that counts the width and number of the pulses... We just need to look for 5 more fast (double the hsync rate) narrow pulses, then 6 fast wide pulses, then 6 fast narrow pulses. If we are counting narrow pulses and we see a wide pulse, then we resync to the wide pulse loop. If we see hsync rate pulses, we have missed the vertical sync and have to wait for the next one. If we match up with the entire vertical sync pattern and then miss one fast pulse, we are on an even field, otherwise we are starting an odd field. Doesn't it seem like that could pretty easily be turned into code? http://www.sxlist.com/techref/scenix/contest/video.htm --- James Newton 1-619-652-0593 RemoveMEjamesnewtonTakeThisOuTsxlist.com SX FAQ: http://www.sxlist.com {Original Message removed}

James: I would suggest that you emulate how it is done in dedicated hardware. See the National Semiconductor LM1881 data sheet for an example. The vertical sync pulses are separated using an integrator and comparators. This could be implemented using up/down counters in software. When the counter crosses a threshold value that is the beginning or end of the vertical sync region. A retriggerable one shot can be used to get the horizontal pulses. Set the one shot time to be longer than a serration or equalizing pulse spacing but shorter than a horizontal line period. This can be done with software counters as well. Once you have the horizontal and vertical separated, you do similar tricks using them together to get the odd/even field signal. -- Rich James Newton wrote: {Quote hidden}> > I've been thinking about sync detect without using an external sync > separator. Doesn't seem to be much on the web about doing that with a > microcontroller... > > ...but it also seems to me like it ought to be very possible. > > Referring to > www.sxlist.com/techref/io/video/ntsc.htm > if we add a check for a sync pulse in the character loop of the code below, > so that it will pick up the sync pulse on the half scan line for even > fields, and count scan lines so we know when to stop on the odd fields, we > can enter a vertical refresh detection loop that counts the width and number > of the pulses... > > We just need to look for 5 more fast (double the hsync rate) narrow pulses, > then 6 fast wide pulses, then 6 fast narrow pulses. If we are counting > narrow pulses and we see a wide pulse, then we resync to the wide pulse > loop. If we see hsync rate pulses, we have missed the vertical sync and have > to wait for the next one. If we match up with the entire vertical sync > pattern and then miss one fast pulse, we are on an even field, otherwise we > are starting an odd field. > > Doesn't it seem like that could pretty easily be turned into code? > > http://www.sxlist.com/techref/scenix/contest/video.htm > > --- > James Newton > 1-619-652-0593 > jamesnewtonEraseME.....sxlist.com > SX FAQ: http://www.sxlist.com > > {Original Message removed}

James Newton wrote: > I've been thinking about sync detect without using an external sync > separator. Doesn't seem to be much on the web about doing that with a > microcontroller... > ...but it also seems to me like it ought to be very possible. Sync detection is sure possible with a SX. I made a quick test on the evaluation board (50 MHz SX28), just for horizontal sync, using the comparator to catch the sync pulses. It works in most cases, but sometimes, when video is bad quality (noisy, but screen is stable) lines are missed with that setup. There are a few problems: 1) Comparator lowest input voltage level is 0.4V. With a 0 to 1V video, sync threshold is at about 0.15V. So it is out of specs, though seems to be working. 2) Noise. I wonder how screen remains stable even when signal is noisy. There must be some filtering in a TV. I'll try to dig the sync separator circuit from an old TV. 3) SX counts the pulse width in a loop like: . . . measure_ov2 mov w, #5 mov dx, w measure3 mov w, #128-100 mov RTCC, w mov w, #compMode measure3a mov !RB, w mov temp, w snb temp.0 jmp measure_ok sb RTCC.7 ;or any other reg my be used for ;counting jmp measure3a decsz dx jmp measure3 ;too long - repeat pulse catch jmp wait_1 . . . The inner loop takes 8 cycles (without comparator that would be 6 cycles). So the comparator is sampled every 8 cycles, and maximum jitter in sync detection is 8 cycles. That can be visible if SX frequency is too low. Probably, it will be better to build an external circuit on a transistor and not use the comparator altogether. Well, the text over video is a cool idea! I'll play with it a bit more. :) Nikolai -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

part 1 7048 bytes content-type:multipart/alternative; (decoded quoted-printable) ------_ 2000\12\08@034949 by Sean H. Breheny Hi Mike, Could you please explain how that circuit works? I haven't had much time to study it, but simple as it is, it isn't obvious to me. Thanks, Sean At 08:29 AM 12/8/00 +0000, you wrote: >{Original Message removed} 2000\12\08@041029 by Michael Rigby-Jones > -----Original Message----- > From: Sean H. Breheny [SMTP:EraseMEshb7CORNELL.EDU] > Sent: Friday, December 08, 2000 8:50 AM > To: RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU > Subject: Re: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge > and Co ntest > > Hi Mike, > > Could you please explain how that circuit works? I haven't had much time > to > study it, but simple as it is, it isn't obvious to me. > > Thanks, > > Sean > > The diode/resistor combination bias the transistors base to a nominal 0.6 volts. Any negative going signal on the emitter will switch the transistor on, effectively stopping the emitter swinging below 0 volts. The video is AC coupled to the emitter so this ensures the bottom of the sync pulses cannot be lower than 0 volts. Theoretically the sync level is always a fixed amount lower than the black level ( can't remember exactly by how much), so the video can be processed by a comparator with a fixed reference. In practice this circuit definitely works, I build the DCFG, and I was most impressed at seeing TV pictures (in B/W) on my old 286 many years ago. However, this is definitely not a "production quality" circuit. A "proper" circuit would use the back porch part of the video signal to clamp the true black level to ground, so the size of the sync pulses wouldn't matter. If this circuit was set up with a comparator that gave good operation on one video source, there is no guarantee it would work 100% on another source Hope that helps, I'm really quite bad at explaining stuff even when I know how it works :o) Mike -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads 2000\12\08@053237 by Simon Nield michael: >ISTR that TV's use a "Flywheel" circuit, which is actualy a phase locked >loop. This would give a good degree of noise immunity. This could probably >be implemented with the scenix, although I'll leave that as an exercise for >the reader :o) use a counter with a variable end count / reset point. when the counter resets to zero this is you internal H sync. if the next external sync occurs before your internally generated sync then you decrement the end count variable. if the external sync occurs after the internal one then you increment the end count variable. this will take some time to lock up, but is effectively a fairly heavily damped pll. (to speed up the initial locking time you could 'crash lock' the counter for a while at power-up: reset the counter on each external sync and just keep adjusting the end count. when you are 'close enough' to the right number then stop crash-locking) locking vertically should be a lot easier now. when you get a V sync in and you are 'near' then end of the field (vertical counter greater than some arbitrary number) then set a flag to reset the internal vertical counter on the next H sync generated internally. another possibility would be to run the device off a voltage controlled video rate clock (13.5MHz or some multiple of that) and to control that clock frequency with a dac output; change the voltage rather than the counter length. this would have the advantage of scaling anything you put on the screen too. not too sure how easy building your own vco would be but it might be as simple as replacing one of the caps on a standard crystal with a varicap diode...? regards, Simon -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads 2000\12\08@074320 by mike >> 2) Noise. I wonder how screen remains stable even when >> signal is noisy. There must be some filtering in a TV. I'll >> try to dig the sync separator circuit from an old TV. >> >ISTR that TV's use a "Flywheel" circuit, which is actualy a phase locked >loop. This would give a good degree of noise immunity. This could probably >be implemented with the scenix, although I'll leave that as an exercise for >the reader :o) You can also get a big improvement by adding a holdoff, so that when you get a sync pulse you ignore any input until just before you're expecting the next one - very simple and pretty effective. Checking the sync pulse width & rejecting too-short ones can also help. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads 2000\12\09@034029 by Nikolai Golovchenko Thanks Mike for the circuit. I assembled it and now it works in my TV. :) By the way, this is where I experiment with the SX video thing. The TV is assembled from a black-and-white monitor and a radio channel block from a TV. The block has a video output with a DC component of a few volts (about 2V - I didn't measure it), but the monitor works only for zero DC video signal. Before I used a 'dirtier' circuit of a 22 uF capacitor and an adjustable 470 Ohm resistor in parallel, connected between video ouput of the block and video input of the monitor to lower the DC offset. It sort of worked, with some of contrast lost. Now it's much better with the new circuit :) One catch with the DC separator is that the capacitor is charged by the transistor through the video output and the output has to have a sufficiently low impedance, which my radio channel hadn't. So I added a p-n-p emitter follower before the DC separator to make it work. It should also work for the SX comparator input (or simply a digital input) if the transistor base is adjusted to something like 0.7V. I'll check it. Yesterday I tried a circuit that separates sync signal from video. It uses 2 transistors and a few resistors and capacitors. It has a good digital output, but I still can't make SX synchronize at the same period to every individual HSYNC pulse in the noise presence. So besides sync separation a PLL scheme should be added. In that case, I guess the sync separation can be made in software altogether, if the DC separator and a comparator is used. Thanks all for replies, Nikolai ---- Original Message ---- From: Michael Rigby-Jones <RemoveMEmrjonesspam_OUTKILLspamNORTELNETWORKS.COM> Sent: Friday, December 08, 2000 10:29:13 To: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU Subj: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and Co ntest >> {Original Message removed} 2000\12\13@134657 by jamesnewton For anyone participating in the sxlist video design challenge ( www.sxlist.com/techref/ubicom/contest/video ) or who is interested in overlaying PIC or SX generated signals on existing video, this is a fantastic tutorial on how to detect sync in software. http://64.30.204.60/tom/theory/theory.htm This is related to descrambleing cable video, but the site is technical enough that no one could build one without completely understanding it. And I'm not posting this link to show people how to descramble cable, but rather how to reliably genlock to a video signal using software. If that makes me a hypocrite, tell me so off-list. --- James Newton 1-619-652-0593 EraseMEjamesnewtonspamspamBeGonesxlist.com SX FAQ: http://www.sxlist.com {Original Message removed} '[sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall' 2001\01\02@022851 by Dan Michaels Rich Ottosen wrote: >No characters here but there is color. Yes, it is a SX doing all the >work. :-) > >See the picture I have attached! >I hope the picture file isn't too large for the list. > Pretty amazing stuff for an SX. What are you using for RAM space, or doing it all on the fly? [and isn't about time you retired that monitor? :)]. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads More... (looser matching) - Last day of these posts - In 2001 , 2002 only - Today - New search...