VoyForums
[ Show ]
Support VoyForums
[ Shrink ]
VoyForums Announcement: Programming and providing support for this service has been a labor of love since 1997. We are one of the few services online who values our users' privacy, and have never sold your information. We have even fought hard to defend your privacy in legal cases; however, we've done it with almost no financial support -- paying out of pocket to continue providing the service. Due to the issues imposed on us by advertisers, we also stopped hosting most ads on the forums many years ago. We hope you appreciate our efforts.

Show your support by donating any amount. (Note: We are still technically a for-profit company, so your contribution is not tax-deductible.) PayPal Acct: Feedback:

Donate to VoyForums (PayPal):

[ Login ] [ Contact Forum Admin ] [ Main index ] [ Post a new message ] [ Search | Check update time | Archives: 1, 2, 3, 4, 5, 6, [7], 8, 9 ]

[ Next Thread | Previous Thread | Next Message | Previous Message ]

Date Posted: 09:34:24 03/03/02 Sun
Author: A coupla words..
Subject: Re: PAL B/G decoder PT - Starting
In reply to: Gaz 's message, "PAL B/G decoder PT - Starting" on 08:11:11 03/03/02 Sun

The SX's have a difficult programming algorithm compared to the standard microchip pics and I had some setbacks until I built the 'fluffy' programmer - no problems since but it's more complex than the 'JDM' type interface.
Writing the software in C may cause timing problems and you'll have to pick over every line of the assembly output to ensure extra cycles have not been added or subtracted in critical routines (most of them) - if you're using the 3chip approach that is. As you'll find, being 1 cycle out (20MHz) can be enough to make the difference between good picture and no picture.
I've got nothing against C but the executable it produces is ultimately assembly language and the lowest level is where you'll be working with this type of application especially when troubleshooting the code.

>I saw lots of things around the net on this week, and
>i decided to choose the PIC from Scenix.
>Main reasons: Not very expensive, it's very fast
>50MHz, program the device it's very simple just need
>to have a socket on the decoder board, and plug-it
>into the PC via a very simple parallel or serial cable
>that anyone can make for itself, instead of have to
>buy a expensive comercial PIC programmer. Also i
>founnd that's possibel to make the software in C
>Language, in this way it will be easier for most
>people to understand what the sofwate is doing,
>instead of the assembly.
>I intent to seperate the "problem" in 4 steps:
>1º - Vertical Sync of the picture.
>2º - Horizontal Sync of the picture.
>3º - The Random Color Burst Polarity.
>4º - The Random Video Inversion.
>The general idea is to isolate each part for a simple
>and smaller problem.
>First of all get a locked picture on
>Vertical/Horizontal (this it's the easy part ... i
>have a tv set at home that makes this automatically
>and i already saw how it works, for this it's not
>needed a pic, it's solved with common components ah
>ah), only when this is achieved (i mean get a GOOD
>locked (should i say perfect? eh eh) then get into the
>color burst or the video inversion... and so on!
>For know this is just ideas (off course), i intent to
>put this in pratice over the next week, i'm sure that
>many things will come up and so the ideas will change,
>but i'm not running to get that train! :)
>
>Be back soon!
>
>Gaz

[ Next Thread | Previous Thread | Next Message | Previous Message ]

Replies:

[ Contact Forum Admin ]

Forum timezone: GMT-8
VF Version: 3.00b, ConfDB:
Before posting please read our privacy policy.
VoyForums(tm) is a Free Service from Voyager Info-Systems.
Copyright © 1998-2019 Voyager Info-Systems. All Rights Reserved.