Searching \ for '[sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ubicom/lib/io/index.htm?key=video
Search entire site for: 'SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall'.

Exact match. Not showing close matches.
PICList Thread
'[sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall'
2000\11\29@143348 by jamesnewton

flavicon
face
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_OUTjamesnewtonTakeThisOuTspamsxlist.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


2000\11\30@005112 by Russell McMahon

picon face
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.


2000\11\30@054050 by mike

flavicon
face
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.


2000\11\30@075320 by Bob Ammerman

picon face
> 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.


2000\11\30@184853 by Russell McMahon
picon face
>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.


2000\11\30@190953 by Bob Ammerman

picon face
----- Original Message -----
From: Russell McMahon <.....apptechKILLspamspam@spam@CLEAR.NET.NZ>
To: <PICLISTspamKILLspamMITVMA.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.


2000\11\30@193719 by rottosen

flavicon
face
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}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.



'[sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall'
2000\12\01@004048 by rottosen
flavicon
face
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}

2000\12\01@020130 by James Newton

face picon face
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
.....jamesnewtonKILLspamspam.....piclist.com
1-619-652-0593 phone
http://www.piclist.com

{Original Message removed}

2000\12\01@021428 by James Newton

face picon face
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_OUTspamTakeThisOuTsxlist.com
1-619-652-0593 phone
http://www.sxlist.com

{Original Message removed}

2000\12\01@103240 by sxtech

picon face
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
jamesnewtonspamspam_OUTsxlist.com
1-619-652-0593 phone
http://www.sxlist.com

{Original Message removed}

2000\12\01@131537 by jamesnewton

face picon face
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@jamesnewtonKILLspamspamsxlist.com
SX FAQ: http://www.sxlist.com



{Original Message removed}

2000\12\01@132823 by Simon Nield

flavicon
face
>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 KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\01@141923 by jamesnewton

face picon face
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
RemoveMEjamesnewtonTakeThisOuTspamsxlist.com
SX FAQ: http://www.sxlist.com



{Original Message removed}

2000\12\01@144822 by rich+piclist

flavicon
face
> 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 spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\06@114416 by jamesnewton

face picon face
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
TakeThisOuTjamesnewtonEraseMEspamspam_OUTsxlist.com
SX FAQ: http://www.sxlist.com



{Original Message removed}

2000\12\06@120836 by jamesnewton

face picon face
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
RemoveMEjamesnewtonspamTakeThisOuTsxlist.com
SX FAQ: http://www.sxlist.com



{Original Message removed}

2000\12\06@212743 by rottosen

flavicon
face
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}

> {Original Message removed}

2000\12\08@023529 by Nikolai Golovchenko

flavicon
face
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


2000\12\08@032825 by Michael Rigby-Jones

flavicon
face
part 1 7048 bytes content-type:multipart/alternative; (decoded quoted-printable)


------_ 2000\12\08@034949 by Sean H. Breheny
face picon face
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

flavicon
face
> -----Original Message-----
> From: Sean H. Breheny [SMTP:EraseMEshb7spamCORNELL.EDU]
> Sent: Friday, December 08, 2000 8:50 AM
> To:   RemoveMEPICLISTEraseMEspamEraseMEMITVMA.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

flavicon
face
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

flavicon
face
>> 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

flavicon
face
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_OUTspamKILLspamNORTELNETWORKS.COM>
Sent: Friday, December 08, 2000 10:29:13
 To: RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU
Subj: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and Co              ntest



>> {Original Message removed}

2000\12\13@134657 by jamesnewton

face picon face
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
EraseMEjamesnewtonspamspamspamBeGonesxlist.com
SX FAQ: http://www.sxlist.com



{Original Message removed}


'[sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Chall'
2001\01\02@022851 by Dan Michaels
flavicon
face
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...