In SX Microcontrollers, SX/B Compiler and SX-Key Tool, transistortoaster wrote:

>Frank,
>Thanks that is interesting.
>I've got one prototype with the SRAM, but I've got some problem with the video generation ISR not "playing nice" with >the main code when they both access the SRAM.


>I got the interrupt routine to co-operate by remembering the SRAM status 
>and returning it when it's done.
>So the main code can write to SRAM anytime (much faster).
>But I still have the startup problem...
>Bean.

Bean,
I have a leftover question back from the original black and white mere mortal engin, which I suppose has been triggered when you talk about the SRAM access shared by two threads.

You used  __PARAM1 in your ISR at NextTile: and PrimeTileDots:. Exactly why did you use that register? If a function is called in the main code and it gets interrupted, isn't there a problem? I know you made a subroutine to wait for the non-active video phase of the screen display, but is it necessary considering 1) that the worse case scenario is a few pixels that get updated 1/60 seconds later and 2) there are no writes to the shared memory in the ISR?


>As you can see some combinations don't work too well.
...
>I was surprised to see the nice range of colors considering how the color is generated.
The large gamut of colors is perfectly logical because the TV demodulator circuit is continuous in time plus has memory.  

Let
y()= +-1 generated by SX
K=4, 
T = 1/3.57MHz
n1=time

y(n1 *K *T)-> BP filter    h1(t) -> c(t)      : color signal before phase demodulation
y(n1 *K *T) -> notch filter h2(t) -> l(t)    : luminance

It is originally designed for each pixel to last a timespan of T as expressed in y(n2 * T). where , n2=n1*K. However the output is not taken at discrete time intervals c(n2 * T). It can only be written as c(t) where the phase and magnitude change continuously in time. Also, the filter impulse response h(t) cannot be expressed as a constant scaling factor which implies it has memory.


We could only minimize the interference.  I'd like to think about that a bit. Maybe some tricks can be done considering we have 20 clock cycles per colorburst. The easiest technique for consistency I see is to precede each color by at least one pixel of black. Could you please five and equation that relates for a given (x,y) coordinate, what  bit pattern you intended to shift out?

Frank

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=143039#m145217

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)