Re: [stella] Re: [Fpga2600] Where am I going wrong?

Subject: Re: [stella] Re: [Fpga2600] Where am I going wrong?
From: Adam Wozniak <adam@xxxxxxxxxxxxxxxx>
Date: Fri, 3 Jun 2005 11:42:15 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Latest pic...

http://cuddlepuddle.org/~adam/PICT0231.JPG

The white line down the center of the screen is diagnostic.

I disabled the HMOVE logic for now; it was broken.

The GRP0/GRP1 logic seems a little off; the left edges of the invaders
look goofy.

I _still_ have problems when I flip that color/bw switch to color.
(see below)

On Fri, 3 Jun 2005, Chris Wilkson wrote:
> On Fri, 3 Jun 2005, Adam Wozniak wrote:
> > I'm still not sure if that's the bitscope being goofy, or if they're real.
> 
> The more I think about it, the more I think it's probably real.
> 
> > My DAC is an 8 bit r/2r ladder feeding a high speed op-amp in a unity
> > gain configuration.  I used the op-amp because I wasn't sure what the
> > exact load would be or what it would do to the output of the resistor
> > ladder.
> >
> > I thought throwing s very small cap on the output of the resistor ladder
> > might smooth out small glitches.  The nearest cap at hand was a .1uF, which
> > of course is way too big. :)
> 
> The opamp is a good idea.  You should put a 75 Ohm resistor between the opamp
> and the monitor for impedance matching.  When you do this of course, your video
> will need to be 0-2V with no load so when you attach the 75 Ohm monitor (or TV)
> the voltage will be 0-1V.  Adding a cap can help filter glitches, but probably
> not in a meaningful way.  If a cap is big enough to fix glitches, it's going
> to "smear" the image, making it blurry.  I think I'd avoid it in general.
> Anyway, your glitch is happening during the hsync pulse, which means the
> digital inputs to the D2A are glitching.  That's a logic problem.  :(

One I'm not sure how to fix either.  Take the glitch during sync as an example.
My VHDL looks something like this...

if posNOW < X"14" then   -- from memory, values probably not correct
   ntsc <= ntsc_blank;
elsif posNOW < X"25" then
   ntsc <= ntsc_sync;
elsif posNOW < X"37" then
   ntsc <= btsc_blank;
[ and so on ]

Not sure if/how I can get the glitches out of something like that.  Advice
appreciated.
 
> No problem.  BTW, those will be hard to achieve exactly with an 8-bit DAC unless
> you modify the ladder to be non-linear.  But you can get "close enough" if you
> make it so that 255 -> 1V.  You can then modify the numbers I gave by multiplying
> IRE by 255/140 ~= 1.82.

Hrm.  I've been using 256, not 255, and no scaling resistor, so my full
scale DAC voltage is 255/256 * 3.3V.  Of course I never drive it that high,
and the synthesizer optimizes my MSB to zero.

I was hoping this would be "close enough".  Of course it won't hurt to
get closer.  Probably the simplest mod would be to put that scaling resistor
in there so that 255 = 1.4V  (0 = 0V)

> IRE  ->  DAC
> ------------
> 20   ->  37  (bottom of colorbust = 145mV)
> 40   ->  73  (blank = 286mV)
> 47.5 ->  87  (black = 341mV)
> 60   ->  110 (top of colorburst = 431mV)
> 100  ->  182 (bottom of brightest color = 714mV)
> 120  ->  218 (white = 855mV)
> 140  ->  255 (top of brightest color = 1V)

Here's where I'm at now...

for color /= 0
lum =    0      1      2      3      4      5      6      7
low : X"1A", X"1E", X"23", X"27", X"2B", X"2F", X"33", X"37",
hi  : X"30", X"35", X"39", X"3D", X"41", X"45", X"49", X"4E",

for color = 0

lum =    0      1      2      3      4      5      6      7
mid : X"1A", X"22", X"29", X"30", X"38", X"3F", X"46", X"4E",

blank : X"16"
bottom_colorburst : X"0B"
top_colorburst : X"21"

Again, these are using a 3.3V fullscale.

> > I _have_ gotten a good b&w image for sometimes several minutes at a time.
> > I suspect I've got other problems too though; sometimes it looks as if the
> > processor is locking up (My next plan is to look at phi0 and rdy).
> 
> Are you modeling the processor too?  Or just the TIA?  One thing that can be helpful
> is infinite recording.  Set your scope to store each signal with infinite persistence.
> Then go do something else.  When you come back, you can find out where glitches are
> happening and you can start to track down the causes.  Try that with PHI0 and RDY
> to see if they are glitching (or dying altogether).

Just the TIA.  I think something is wrong with RDY, possibly something else
too.

RDY should be normally high, and go low just after a WSYNC, and stay low until
the next video sync pulse, right?

When I watch it with the bitscope, sometimes when it's low, it'll go high
in the middle of a scanline and then low again before the scanline ends.
This isn't right, is it?

When I flip that color switch, the RDY line goes high and stays there.
It doesn't jump around as I'd expect.  There's something else going wrong
here, isn't there?

- -- 
adam@xxxxxxxxxxxxxxxx        http://cuddlepuddle.org/~adam
KG6GZR                       http://cuddlepuddle.org/~adam/resume.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCoHovyvXf5Z0z5zERAuGlAJsGbyjJzDSoPWZZgQNGC5E4F4DjWACdGMqY
ucKIOoJh3iIGBb525HIKeHY=
=XU09
-----END PGP SIGNATURE-----

Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com

Current Thread