Yet another future of uzebox+comparison of chips

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
uze6666
Site Admin
Posts: 4822
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

Hey Clay,

Indeed the xmega A1 series looks quite nice. And external RAM looks to me essential to fully take advantage of all the peripherals, DMA, event systems, etc. Speaking of the event system, I've looked at it but played with it yet. Though it seem it would work to stream out graphics in conjunction with DMA, I'm unsure about the DMA bus priority and the jerkiness if may cause if the main CPU can interrupt DMA transfers. We'll see. In any cases, I'm pretty sure we could do some pretty cool stuff with the event system and all of timers. Just the video timing could be entirely done in the background without any CPU intervention.

Also about overclocking, that's true that this was a lot of hassles for some. When DIP parts it wasn't too bad to switch it for another one when testing, but when using surface mount parts that's another story. Though my idea was to use a 3.579Mhz crystal and use the internal PLL clock multiplier to dynamically overclock the chip. So at least it would not be permanent. Btw, how stable are those PLL clock multipliers? Do they tend to drift making them unsuitable for the AD725?

As for the video output stage, I'm still thinking if all those xmega peripherals could allow me to generate the color modulation without the AD725. Since I suck big time at analog design, I may need some help at some point. :) On the other hand if I stick with the 725, I'd like to change the DAC design to the approach you proposed a long time ago, using 2 bits for each component plus 2 bit for global "lightness". That would give better gradients and a much more usable color palette. Another option is to have a VGA output, but all older analog TVs would be left in the dark...

-Uze

p.s.: What up with the Avcore and baseboard in 2011? Did we see the last batch at Sparkfun?
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by havok1919 »

Talk to me about the SDRAM on the external bus some time. I can make that happen really cheap. :)

I've actually accumulated a fair bit of scrap from Mega644 overclocking issues on the AVCore. I've still not sold through the first batch of the AVCore's that I had built :oops: but I'm going to say it's in the 10-15% range (I built 128 boards; I think I have ~15 that didn't pass manufacturing test). For whatever reason, those QFN packaged parts always seemed more finicky than the DIPs. (ie, I wasn't even able to get video from the 1284P on the AVCore and I tried a few different parts)

I'm not sure what PLL setup Atmel has in the XMega, but if it's like the one in their ARM 9's the stability will vary based on the external caps and crystal differently depending on the crystal frequency. (for example, I tried using a 10MHz crystal with the '9261 and could never really get stable pixel clock at VGA when used with LCD monitors although the math *should* have been fine. Going to an 18.432MHz crystal fixed that. Staying in the "sweet spot" of the multiplier/divisor range and avoiding the edges was a big deal. Also it was VERY particular about PCB layout. You really had to watch your ground planes and trace routing around the crystals and PLL filters if you want it to be low jitter.) Hard to say if it'd be doable in a 2-layer board or not for 'video' use. It might be OK though just because of resolution-- I only had noticeable issues at "VGA"-- QVGA and the like was always fine. At VGA you'd see ragged edges on things since the ADC in an LCD/plasma display would pick up a little edge jitter on the pixel clock and latch the wrong pixel. Heavily dependent on the monitor though too.

What I would probably try would just be doing something like getting a pretty good quality 14.31818MHz crystal and use that to feed the PLL-- then route that crystal clock (presumably unmolested by the multiply/divide) to a clock out for the AD725. That way a little jitter won't affect your colorburst. I suspect though that the PLL is pretty stable-- they've been using those for audio sample rate codecs and USB framing for years now. Gotta be pretty good for USB 2.0 to work.

Back to video... The AD725 is spendy, but it does have a lot of stuff in there that you wouldn't get (and would spend a lot of parts trying to make discretely) with a purely 'synthesized' composite/YC type output. The luma trap, the four pole low pass filters on the color burst, the clamps, etc. all contribute a lot to why the AD725 "looks" as good as it does compared to something like an Atari 2600 or whatever. (For example, even if you give the AD725 a 'hot' color in RGB-- like a fully saturated red-- it clamps it to an NTSC gamut red and gives you the 'most' that it can without distortion. Do that without the AD725 and you'll get tons of smear and weird over-saturation/darkening as the input swamps the TV's video input. There's a lot of black magic in there that 'fixes' otherwise out of spec input. I have no doubt you could generate video, but having something compatible with lots of TV's and that looks as nice as the present stuff could be pretty tricky.)

As for the AVcore, Sparkfun did actually send me an RFQ for more. The 'gotcha' is that I still have not sold out of that first production run, but the quantity they asked for is more than I have left-- so I'd have to make another run. With the unexpected (high) fallout rate I don't think I'm in the black on the first run yet... So... Dilemma. :lol: I had already purchased Mega644's, PCB's and AD725's back when we first started though (which is good, 'cause 644's appear to be totally sold out at the moment), so I think I'll just see if I can run a few panels (just do like ~32 pcs) and hope for good yield. That'll be like a year's supply and I guess I'm only "out" the production costs since I already paid for the parts anyway. I should have 'em restocked by mid-February I think. Depends on if the assembly house is busy or not... They took 10 AVCores before Christmas and sold through those pretty quick, but it took 'em have a year to sell a few before that! Unpredictable sales to say the least. ;)

-Clay
User avatar
uze6666
Site Admin
Posts: 4822
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

Darn! I was pretty sure you would saw that about self-generating the color stuff. :D The idea of the PLL was to use a 3.579Mhz crystal and multiply it 9-10 times to extract all possible extra cycles and feed a 4x clock to the AD723 (since the AD725 is a 5V only part). I do some testing I guess. What kind of circuit did Andre Lamothe used for his XGS? From you comment it doesn't seem the quality was as good as on the Uzebox AVCore? Speaking of which, that's too bad you will restock them *after* their annual "free day" event!

-Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by havok1919 »

To qualify my statement-- you *should* be able to get NTSC quality similar to an XGS (or Atari 2600, etc), but you probably want to switch things over to a native chroma/luma in that case. (ie, not RGB colorspace... it's the RGB->YC conversion that's tricky since the color gamut of those two don't match up.) I don't exactly recall what the XGS AVR did for color, but I remember that the original XGS (with the Scenix chip) used propagation from an improvised hardware delay line to generate the phase shift for the NTSC. (ie, you didn't have to deal with trying to generate phase shifted colorburst in software! That'd be kinda horrific to code up normally, but maybe possible with some clever timer->eventsystem->DMAtoPORT trickery. ;-) The nice thing about YC in NTSC of course is that you can easily do the Atari 8-bit computer thing and have four bits of phase and four bits of amplitude and get 256 'colors'. (More importantly-- 16 colors with 16 brightness levels each which is nice for shading.)

The problem with the propagation delay with external chip(s)/gates is that it'll vary from unit to unit and over temp, etc. The other 'gotcha' with the phase shift is that you tend to never really hit the *right* intervals for good color selection with NTSC with only ~4 bits of phase. You end up with lots of blues and greens and purples, but then you can't make a real 'red' or 'yellow', etc. You can make lots of pretty colors, but the palette you can make is up to the delays you can generate. (Never Twice the Same Color. ;-)

I'd still really, really advise against *relying* on overclocking the ATXmega. The 128A1 is a $10 chip in singles, so getting one that doesn't work (aside from having to rework a 100 pin TQFP) is going to be spendy. Even in 'production' quantities they're $6/ea and if it's anywhere near the 10-15% fallout I see on the QFN Mega644's that's a big hassle/expense. The other problem is that it's a temperature dependent thing too, so them might work fine for you and me in a cool office, but run one in 95F down south without AC and it might crap out.

And yeah, Sparkfun's order system seems to only take action when they're down to one or two pieces left of something, so if there's any sort of leadtime involved they run dry for a while. :-/

-Clay
User avatar
uze6666
Site Admin
Posts: 4822
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

That'd be kinda horrific to code up normally, but maybe possible with some clever timer->eventsystem->DMAtoPORT trickery. ;-) The nice thing about YC in NTSC of course is that you can easily do the Atari 8-bit computer thing and have four bits of phase and four bits of amplitude and get 256 'colors'. (More importantly-- 16 colors with 16 brightness levels each which is nice for shading.)
Exactly what I was thinking! :mrgreen: However I was wondering how do we do white/grayscale then? Since whites (in NTSC) is the absence of chrominance, shouldn't we need some sort of saturation bit or something? As for the overclocking, you're right, it caused enough issue so far, I'll keep it in spec this time. :)

-Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by havok1919 »

For greyscale you should be able to just disable the colorburst output and use luma bits only (no chroma phase to compare, so it should go black and white). I haven't thought to look to see how other systems do that... (ie, if the upper nibble is 0000 then that's the 'greyscale' map and you turn off the chroma burst generation in the code-- or probably better, have the timer/event/DMA write an all 0's pattern instead of the shifted phase from the colorburst. Maybe 0 degrees or something is 'no color'? I should probably know that, but if I ever did I don't recall it now. ;-)

-Clay
User avatar
uze6666
Site Admin
Posts: 4822
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

I recall that Steve Chamberlin (maker of the BMOW) has issues with his monitor refusing to sync on pure B/W signal. After he added the AD725, it worked. So perhaps eliminating the color burst is not desirable. I should aim to just removing the modulation during the active scanning. If using YC scheme, I can directly drive a SVIDEO output no? Also, what would be the simplest circuit to add these two signal in a suitable form for the composite video output?

-Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by havok1919 »

I would think (this is-- admittedly-- just off the top of my head) that you wouldn't really need much more than some resistors to make a little R2R type ladder (just like we do on the present generation Uzebox) with four bits for the luma level, then a single pin to output the chroma phase from the AVR with a resistor divider to set the amplitude right and a cap to AC couple it on to the luma's amplitude. There's probably a whole slew of standards that would violate (I'm thinking about the black level, front and back porch blanking behaviour, etc.) but I also suspect it'd work. ;-) I don't think that there needs to be any filtering on the chroma-- the TV input will probably have some capacitance that'll take the edges off the square wave anyway.

-Clay
User avatar
uze6666
Site Admin
Posts: 4822
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

Excellent then, can't wait to try that. Thanks for the help Clay! :mrgreen:

-Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by havok1919 »

Should be interesting. ;-) You won't have any sort of buffer or power filtering, etc. so don't be surprised if you get a fair bit of noise and whatnot. An opamp buffer would probably be best (that way the AVR isn't sourcing the current for the full load of the TV and all the noise from the AVR CPU and peripherals isn't riding directly on the video output), but it's more parts... Since there could be 'high' resolution modes the buffer would have to be pretty decent too or else the picture will visibly soften. (ie, no LM741's or LF353's here)

OTOH, it could be that the AVR core will be so low power that is just won't get much gunk on the IO port voltages anyway... Again, should be interesting. ;-) Let me know if you need a hand picking resistors and cap and whatnot.

-Clay
Post Reply