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
kscharf
Posts: 18
Joined: Fri Sep 12, 2008 12:50 am

Re: Yet another future of uzebox+comparison of chips

Post by kscharf »

The atxmega256a3 is available now.
schmartboards can be used as breakout boards and you can solder a .5mm TFQP to them with a fine tip soldering iron.
Might need a level translator to feed the D/A resistors or change values as the xmega is a 3.3 volt part.
The xmega will require code changes to handle IO as the register layout is different, but it does have the same
instruction set as the atmegas.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

Ah, they are indeed available...I just receive some last week!
Image

In the mean time, I stopped procrastinating, learned Eagle and made my own little breakout.:
Image

I just have to wait for it to come back from Batch PCB (~3 weeks!). Just suck that I discovered ITead studio shortly after. They can make pcb for half the price (you even get 10 pieces!) and in half the time of BatchPCB! We'll see the quality soon, I just put an order for a *very special* board I just completed... ;) For the breakout, if some are interested I'll have a batch made and sell them at bargain price.

So, things are not stalled, just moving more slowly than I'd like. I'll try posting some draft specs open for comment soon, so stay tuned.

-Uze
User avatar
kscharf
Posts: 18
Joined: Fri Sep 12, 2008 12:50 am

Re: Yet another future of uzebox+comparison of chips

Post by kscharf »

I first used this chip almost a year ago. We had some problems with GCC where an application that worked on the xmega128a3 did NOT work on the xmega256a3 even though the only important differences between the two is just the upper memory limits. Something to do with the way GCC fakes pointers larger than 16 bits for AVR code space access I think. Never did find where the problem was, and our application was actually less than 128k bytes in code size.

A breakout board is nice. Soldering a .5mm chip to a 'plain' board with an iron takes a steady hand, a very thin tip iron, very thin solder wire, and lots of solder wick to remove the shorts that WILL result. You can also have stencils made from the pc gerbers to apply solder paste, pick and place by hand, and flow in a skillet or a toaster oven.

While you were doing the cad work you could have added the other parts to have made a complete module complete with the DA resistors and SVGA chip, though the break out board will be useful for other stuff.

Good luck and keep us informed!
User avatar
DaveyPocket
Posts: 378
Joined: Sun Sep 14, 2008 8:33 pm
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by DaveyPocket »

I'll definitely make a JAMMA version of the Uzebox using the XMEGA :lol:
User avatar
uze6666
Site Admin
Posts: 4801
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'll definitely make a JAMMA version of the Uzebox using the XMEGA :lol:
One complaint I heard over and over regarding the original Uzebox design was it's use of the "awfully expensive" AD725. The XMEGA has many peripherals and I think I can directly generate Y/C (Luminance/Chrominance) video without the AD725. Obviously this will causes a problem for those who need RGB components. Does JAMMA support Y/C video? I'm wondering if a dual solution would be possible. More tinkering needed. :)

-Uze
User avatar
kscharf
Posts: 18
Joined: Fri Sep 12, 2008 12:50 am

Re: Yet another future of uzebox+comparison of chips

Post by kscharf »

uze6666 wrote:
I'll definitely make a JAMMA version of the Uzebox using the XMEGA :lol:
One complaint I heard over and over regarding the original Uzebox design was it's use of the "awfully expensive" AD725. The XMEGA has many peripherals and I think I can directly generate Y/C (Luminance/Chrominance) video without the AD725. Obviously this will causes a problem for those who need RGB components. Does JAMMA support Y/C video? I'm wondering if a dual solution would be possible. More tinkering needed. :)
-Uze
It may be possible to get the AD725 as a free sample from AD if you ask them nicely. I was able to obtain one this way about a year ago, I gave them my amateur radio callsign as the 'company name'. They must have a few hams working there.

The clock generator on the xmegas is a lot simpler than the PPL used on ARM chips. In fact the xmega has a build in RC oscillator that is stable enough to generate accurate Usart clocks even at very high baud rates. I'm working on a project that doesn't even use a crystal and it just works. So I can't see you having problems with the PLL clock, but do start off with the highest crystal frequency you can. 7.18mhz would allow 28.72, and 35.9 which you'd probably get away with. But SOCKET the crystal to allow trying things out. BTW as you probably know the 'A3' parts DON'T have the external memory interface and the xmega256a1 ISN'T shipping yet.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

Samples are great...when you receive some. :( And then, it not of much use for kit makers.
The clock generator on the xmegas is a lot simpler than the PPL used on ARM chips. In fact the xmega has a build in RC oscillator that is stable enough to generate accurate Usart clocks even at very high baud rates. I'm working on a project that doesn't even use a crystal and it just works. So I can't see you having problems with the PLL clock, but do start off with the highest crystal frequency you can. 7.18mhz would allow 28.72, and 35.9 which you'd probably get away with. But SOCKET the crystal to allow trying things out. BTW as you probably know the 'A3' parts DON'T have the external memory interface and the xmega256a1 ISN'T shipping yet.
Since I'd need the base 3.59Mhz for the chrominance modulation why now use that as the crystal? I understand the PLL could multiply that to 28.6, 32.2, 35.8 or other other frequencies. We could overclock "on demand" 8-) . What advantage would you see in using a higher vs lower frequency crystal.

Uze
User avatar
DaveyPocket
Posts: 378
Joined: Sun Sep 14, 2008 8:33 pm
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by DaveyPocket »

uze6666 wrote: Does JAMMA support Y/C video? I'm wondering if a dual solution would be possible. More tinkering needed. :)

-Uze
JAMMA interfaces directly with RGB and the sync signals. I haven't seen any arcade monitors use Y/C. Is there a way where, when this project is further developed, to have two kernels? One supporting Y/C and the other supporting RGB? All one would have to do is change code a little bit but other than that the kernel should be identical. Something to consider.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by uze6666 »

JAMMA interfaces directly with RGB and the sync signals. I haven't seen any arcade monitors use Y/C. Is there a way where, when this project is further developed, to have two kernels? One supporting Y/C and the other supporting RGB? All one would have to do is change code a little bit but other than that the kernel should be identical. Something to consider.
Well, the real issue is about the image ressources generated. The pixel data would be quite different: for RGB the classic R3:G3:B2 vs Y/C's HUE3:LUM5 (3 bit for chroma, 5 bits luma). The kernel could indeed have a compile switch to support both hardware interfaces. We would have to make sure the graphics conversion tooling produces data files with both formats from the start.

-Uze
User avatar
DaveyPocket
Posts: 378
Joined: Sun Sep 14, 2008 8:33 pm
Contact:

Re: Yet another future of uzebox+comparison of chips

Post by DaveyPocket »

uze6666 wrote: Well, the real issue is about the image ressources generated. The pixel data would be quite different: for RGB the classic R3:G3:B2 vs Y/C's HUE3:LUM5 (3 bit for chroma, 5 bits luma). The kernel could indeed have a compile switch to support both hardware interfaces. We would have to make sure the graphics conversion tooling produces data files with both formats from the start.

-Uze
I have a feeling there will also be users that want to connect through a SCART interface using RGB seeing there have been some who have.
Post Reply