About to wire up the non-color version of the Uzebox

[unebonnevie]

Hi,

Ok, finally have some time to try out the Uzebox. I am about to wire up the non-color version of the Uzebox. Have some basic questions.

1. +/- 5% off the values of the resistors for the DAC is OK? I will be using 1% tolerance resistors, but don't have the exact values as specified in the schematic.
I noticed that the values for R1, R2, and R3 are doubled successively; that is, R2 is doubled of R1 value; and R3 is doubled of R2 value, meaning R3 is 3 times the value of R1. So, if I choose a value for R1, I should be able follow the rest for R2 and R3 values. That should work, no?

I happen to have available R1 = 1.8K, R2 = 3.6K, and R3 = 8.2K, where R2 is exactly doubled of R1, but R3 is 1K more than doubled of R2. I do have 6.8K for R3. That should be close enough double R2. Probably better than choosing R3 = 6.8K.

From the schematic http://belogic.com/uzebox/schematics/uz ... mal_v2.pdf, there is R9 = 500ohm. That seems out of the pattern. Someone please explains? I understand 75ohm is needed for impedance with the TV.

The DAC indeed is an R2R DAC.

2. What is the exact Uzebox fuse bit values for the ATMEGA644?

3. Is this just black and white or there will be gray shades as well for the "black and white" DAC? In other words, without the AD725, the "black and white" DAC will generate voltages between 0.3V (black) and 1.0V (white) for gray shades?

Thanks!

[D3thAdd3r]

1. Some one else can answer this question better.
2. Look here http://uzebox.org/forums/viewtopic.php?p=3847#p3847
3. I believe it is grey scale.

[unebonnevie]

Very interesting...Now that I wired things up, a couple issues.

1. I am using the crystal 28.63636Mhz, as required by the uzebox schematic. Programming Donkey Kong with AVRDude using USBASP program takes 470 secs. Normally, with the 20Mhz crystal, things fly by. Anyone experiences such slowness?

Code: Select all

c:\AVR\projects\uzebox>avrdude -p m644 -c usbasp -u -U flash:w:dk.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9609
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "dk.hex"
avrdude: input file dk.hex auto detected as Intel Hex
avrdude: writing flash (61278 bytes):

Writing | ################################################## | 100% 469.94s
avrdude: 61278 bytes of flash written
avrdude: verifying flash memory against dk.hex:
avrdude: load data flash data from input file dk.hex:
avrdude: input file dk.hex auto detected as Intel Hex
avrdude: input file dk.hex contains 61278 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 359.30s
avrdude: verifying ...
avrdude: 61278 bytes of flash verified

avrdude done.  Thank you.


2. My fuse bits are: 0xCF for low byte and 0x91 for high byte. Should be fine.

3. So far, nothing shows up on my little b/w NTSC TV. Need to recheck things. The one difference is that I use an 10uF16V electrolytic cap for the VCC/GND pins of the MCU instead of a tantalum one. And, of course, the R1/R2/R3 values as previously mentioned in my original post.

Btw, any picture and/or vids of B/W Uzebox wired up?

Thanks!

[HardlyUnique]

I'm not an expert but I'll try to help with what I know:

0x91 for the high bit leaves JTAG enabled. JTAG must be disabled for the Uzebox. See here. Not sure if that would cause the slow programming or not. You may want to check your wiring, especially around the oscillator.

After that, you may want to hook up a speaker and see if you get sound. That's a much simpler circuit.

As for R9, I believe it's there for generating the video sync signals. You'll notice that it isn't part of the 8-bit DAC. It can't be left out!

As for your resistor values, having a higher R3 won't hurt much; your Uzebox will just have a slightly darker shade of gray when that bit is on.

Hope that helps a little. Good luck!

[unebonnevie]

@HardlyUnique:

Thanks so much for the response. What I had changed:

1. Took JTAG out of the fuse bits. Now: 0XCF for low byte. 0xD1 for high byte. Does not make a difference

2. Replaced the 10uF/16V electrolytic with a 10uF/16V tantalum (got one from a friend). BAM! Things show up! But, not perfect at all. See attached pictures. I can't imagine that makes a BIG difference (I saw uzz6666's post on this already) between the two caps from no show to showing something. It could be not perfect is because my R3 (6.8K) is not 100% doubled the value of R2 (3.6K). I think there is much voltage noises and/or crystal issue.

Then I make sure I replaced all ceramic caps, the 22pF, with the best ceramic caps, quality wise. Still, same problem.

3. Absolutely no sounds. All I can hear from my 8ohm speaker is RRRRRRRrrrr sounds. There is a cat inside the speaker! LOL!

Tips? Thanks!

[unebonnevie]

One more thing:

Looking at fuse bits site http://uzebox.org/wiki/index.php?title=Troubleshooting that HardlyUnique mentioned. When enabling CKSEL3, I will have "Full Swing Oscillator; Start-up time: 16K CK + 0ms; Crystal Osc.; BOD enabled; [CKSEL=0111 SUT=01]". I have always for, my AVR projects, used Ext Crystal option. For CKSEL3, it does mention "Crystal Osc." but does NOT mention external crystal. Is selecting CKSEL3 really intended for the Uzebox crystal setting for overclocking? Sorry, I don't mean to have doubts, but I don't want to render the MEGA644 dead if I put in the wrong fuse bits. The below says: 0xD7 for lfuse and 0xD7 for hfuse. Thanks!

Code: Select all

Mega644s ships with CKDIV8 AND JTAGEN activated and *must* be uncheked/unprogrammed. CKDIV8 internally divides the master clock by 8, so your Uzebox runs at 3.57Mhz. No chance it will generate video with that! Also JTAGEN activates the debug port, which is on the VIDEO DAC port and will screw up some color component if left active.
Insure *only* these fuses are written (this means checked in AVRStudio) (written fuse=0, unwritten fuse=1):
IF you are using a crystal:
-SPIEN (pre-written in the factory)
-EESAVE
-CKSEL3
-SUT1
-These fuses correspond to a setting of 0xD7 for lfuse and 0xD7 for hfuse


[uze6666]

I'll also try to help.

The fact that you are getting a picture would, at first, seem to imply that it's not an oscillator problem. Certain parts of the picture appears steady while other distorts. For me this would suggest the sync signal is somehow distorted by the DAC's output. Seems to occur when color is present, specifically blue. Check you connection for this part of the DAC. The B/W schematic was derived by a forum member from Steve Chamberlin's work. I do not know if anybody actually built it before, so it may be hard helping you troubleshoot your issue. Here's the thread: http://uzebox.org/forums/viewtopic.php?f=4&t=343#p3042. You may need to use the resistors setup defined by steeve to see if things get any better. Another potential culprit, overclocking. In the picture with the high scores, some characters are garbled. To they always appears like that? At they flicking between a garbled and correct form? That a common issue for chips that can't handle overclocking. In that case you would need to test with another one to be sure.

For the programming, why it's taking forever at 28Mhz may have to do with the overclocking. Some chips can have a hard time to cope with it or, sometime, it's just a peripheral like the UART or ISP. You may try to lower the programming speed a bit to see if it make any difference.

For the 10uf cap, were should sure it was good and polarity respected? It should not make such a difference too prevent the 644 from starting. Hmm, or perhaps the tantalum helps in stabilizing the power faster and hence start the oscillator? Hard to say. One thing is for sure, you can indeed use CKSEL=0111 & SUT=11 (full swing oscilltor/crystal). The later SUT is to allow enough time for power to stabilize.That is the setting I use for the kits I sell. I read an Atmel white paper back then that led me to this choice, though I can't seem to find it anymore. I will correct the WIKI to reflect this. Perhaps a good clock setting could stabilize overclocking issues.

For the sound, if you are connecting to the TVs speaker, better use the voltage divider circuit from the regular schematic (i.e F2).

And be sure the JTAGEN is not programmed since that would result is sync problems for sure.

Hope this helps!

-Uze

[HardlyUnique]

That's a head-scratcher! I agree with Uze; the oscillator is working properly. Those 0's in the middle of the 2nd pic are perfect, even on the same line after some distortions. It's one of those, I-couldn't-reproduce-it-if-I-tried problems .

I think if replacing C13 went from totally-not-working to almost-working, then it couldn't hurt to improve the filtering a little further. I'd try adding another .1 uF ceramic capacitor in parallel with C13 and see if that helps any - after double-checking the DAC, like Uze suggested.

[martinsustek]

Try verifing contents of FLASH or reprogram chip again (or with another programmer or out of circuit). For me, it seems like distorted graphics data of some tiles in program memory.

[unebonnevie]

Thanks, all for the responses and helps. Made some progress. Turning for the day...Will try out the rest of your tips/suggestions tomorrow.

1. Eliminated the slowwww programming issue. Jumper setting to the USBASP programmer to sync-up with the ATMEGA644 nicely and re-programmed Donkey Kong to make sure it's done right.
36 secs to write and 23 secs to verify. Fast!

Code: Select all

avrdude: writing flash (61278 bytes):

Writing | ################################################## | 100% 35.31s
avrdude: 61278 bytes of flash written
avrdude: verifying flash memory against dk.hex:
avrdude: load data flash data from input file dk.hex:
avrdude: input file dk.hex auto detected as Intel Hex
avrdude: input file dk.hex contains 61278 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 23.89s
avrdude: verifying ...
avrdude: 61278 bytes of flash verified


2. Definitely NOT the MCU problem nor overclocking problem. I get better vid output by removing everything else on the breadboard and only the Uzebox project, that is, MCU and the DAC on the breadboard. But, still messing up on displaying the Kong. The text is perfect. So, it's very likely my DAC + Sync output. My weighted DAC resistor values are different from the schematic (See my original post), but I still use R9 = 500ohm, as someone previously mentioned that it's the sync resistor. So, maybe I should play around with R9's value?

3. Still no sound, even I tried the voltage divider. In fact, complete silence. Without the voltage divider, I hear the RRRRRrrrr's from my speaker. Ok, no problem. Low priority for me on this one. The vid output is higher priority.

4. Don't take out the 75ohm. If I do, nothing is displayed.