FAQ

What are the differences between the Uzebox AVCore and Fuzebox kits and what are the pros and cons?

Clay Cowgill's kit (AVCore module+baseboard) and Ladyada's kit (Fuzebox) are both 100% functionally equivalent and compatible with the reference design. That is, code will run and produce the exact same result. The major difference is that the AVCore is a fully assembled, surface mount design while the Fuzebox is a built-it-yourself kit. The Avcore is basically a full Uzebox on a 40-pins chip size module. It can be plugged in any project that would require an MCU and video and/or sound.

Here's some differences:

• They both use the same Atmega644 (but in different package) and the same weighted DAC design.
• For the RGB-to-NTSC conversion, the AVcore uses an AD723 vs. an AD725 for the Fuzebox. Although these two chips produces the exact same results, Clay preferred the AD723 because it's newer and does not require big 220uf capacitor (essential for his small module design).
• The SD card interface is, again, 100% compatible, the AVCore uses MicroSD (again to fit on the small module) while the Fuzebox uses the regular size.
• Both have S-VIDEO output. The AVCore implements the "Luma Trap" on the AD723 not the Fuzebox. This circuit gives less artifact and somewhat better colors on the composite video output (no difference on the S-VIDEO output).
• Both also adds to the reference design: A pin to control the external LED, a pin to read the "soft power" switch and a pin to turn on/off the AD725/AD723.
• The AVCore come with a single 6-pins SPI programming port, meaning you must have/buy an ISP programmer (~35$). The Fuzebox have 6 & 10 pins SPI programming ports & also an FTDI serial programming port. It ships with a cable to use the FTDI port and the mega644 pre-flashed with a 2K bootloader (required to use the FTDI).
• Assembled vs DIY: If you know nothing about electronics and just want the thing to work, get the AVcore. If you want to build it yourself without to much hassle, get the Fuzebox. If you want to do everything yourself, build the reference design.

On the pro and cons side, the Avcore has the Luma trap but you can not replace the ATMega644. The Fuzebox allows you to replace the ATMega644 and you can also program the chip without having to buy an ISP programmer (note this has it's issues, read the bootloader thread on the forums for more).

Some reported that the sound output is a bit louder on the Fuzebox than the AVCore. Also, video quality is a bit better on the AVCore. Clay Cowgill is an electronics engineer who has been working in the field for many year (even designing video games boards!), so that may explain things.

What are the differences between the Uzebox and the Hydra system?

The main one is the general approach. The Uzebox goal was simplicity yet enough power to do great games. The Hydra on the other hand is more powerful because it uses a Parallax 8 cores MCU running at 80Mhz. That in turn comes at the cost of much more complexity (and $$$ too). The multi-threaded programming required is not trivial, and moreover you are stuck using either assembler or Parallax own 'Spin' language. The Uzebox is based on a single core micro-controller (ATMega644) that can be programmed in assembler or in plain C/C++, the most common languages out there. All development tools are open source. The Hydra is of the kind "everything and the kitchen sink": Keyboard, mouse, VGA port, etc. and that raises cost to about USD200$. The Uzebox on the other hand is more retro-minimalist to lower cost and complexity. That said, it has a SD card interface and S-Video out (the Hydra doesn't as of this writing). So it's not really competing with the Hydra. We could say that it has it's own little market that fits between the original XGS and the Hydra in terms of power and complexity.

Is there any reset button sequence so I can return to the gameloader?

When booting or resetting the console, press any button on the first controller to start in the gameloader. While playing most games, press START+SELECT+Y+B to perform a soft reset and get back to the gameloader.

I am using the bootloader to start games. The games however often show weird behavior or crash.

Your SD card might have poor contacts, or the wires connecting the card reader (on a home-built Uzebox) might be too long. The bootloader (currently) have no error checking, so defects will be programmed in, making the games exposing weird behaviors. Until a better bootloader is completed, you can do the following:

• Use these test programs to verify whether the SD reading indeed malfunctions.
• Use Harty's bootloader which communicates with the SD card at a slower rate, less prone to defects.
• If applicable, try to shorten wires between the ATMega and the card reader, anything making it less prone to noise.
• If possible (if you have a regular SD socket), use a regular SDSC card (not a Micro-SD one in a converter, converters might be sloppy).

I have a midi song I converted to uzebox format and am playing it with StartSong. However when the song ends it seems to just hang on the last notes forever.

Since the MIDI converter tool strips out note-off events to save space, you'll end up with "stuck" notes if your instruments don't have fade-out envelopes. Three possible solutions to this:

• Insure all your patches include a fade-out or note cut command
• Add notes with zero volume at the very end of the song
• In the conversion tool, don't strip out note-off

The video signal on the S-video output exhibits a "checker board" pattern. Is that normal?

No, this is a ground problem. Ensure the S-video connector's metal casing is soldered to your ground plane.

On the Fuzebox, can I flash the new kernel to it with the USB TTL-232 cable. I don't want to try if it's only going to mess up the chip!

The kernel is not something you overwrite on the Atmega644 like a BIOS upgrade on your computer. The "kernel" is the term used to describe the libraries and core functions that makes your game alive. It is always compiled and linked with each game (the .HEX file), they can not function separately. The Fuzebox USB cable can naturally flash these as long as they are smaller than 62K. The other 2K is being used by Ladyada's USB cable bootloader. Note that you *can not* replace this bootloader or flash the SD card Gameloader/bootloader with this cable, you absolutely need an ISP programmer.

What is the optional luma trap for and what are it's benefits

Put simply, when color signals (chroma) were added to black and white (luma) television standards, the designers did it in such as a way that the new color signal would be backwards compatible with older black and white TVs. The chroma and luma signals are mixed together to form composite video. The problem is some of the signals can interfere with each other and the TV (which has to separate and decode the combined signal) can't tell sometimes which part is chroma or luma. This causes an effect commonly known as dot crawl.

The AD725 solution to this problem is to use a notch filter that "traps" the part of the luma signal that interferes with the chroma signal. If you use S-Video the luma and chroma are always kept separate and do not have this problem.

Can the Uzebox generate PAL video signal?

No. For both hardware and software reasons. The Uzebox runs at 28.63 Mhz. That is not just a random number, but is in fact the NTSC colour carrier frequency x8. It needs to be this x8 to be able to drive the AD725s x4 clock input (saving crystals/chips) and also make the pixel clock a factor of the colour carrier (which avoids the worst of dot crawl)

The PAL colour carrier is 4.43Mhz so that would mean the AVR would have to run 35.5Mhz.

The AVR is already being overclocked to 28Mhz. 8mhz over its rated speed of 20Mhz. It gets by on this overclocking barely in the DIP package (some chips fail and some need "over volting"). Even in the DFN package with good decoupling the BEST I have seen an ATMega644 overclock too was ~33Mhz.

In addition PAL uses different resolutions and timings and the whole kernel timing would have to be rewritten and games would no be compatibles between standards.