Yet another future of uzebox+comparison of chips

[portets]

after reading up on the possibilities of chip upgrades on the forum here, i decided to create a chart comparing them. i also threw in the NES for comparison.

chips.png (22.6 KiB) Viewed 10918 times

as most of us here know, the atmega644 is the chip everyone is using for the classic uzebox. and the atmega1284 is a proposed upgrade.

the benefits of upgrading to the atmega1284 are complete(?) compatibility with existing hardware, software and firmware. it's a direct drop-in replacement that's available in a dip package for ease of use in hobby projects like uzebox. to work with the existing hardware and schematics, all it needs is a voltage increase. the 1284 will give us twice the rom storage for double the game/application size. the 1284 also has four times the ram, which would just speed things up in general.

people that built their own uzebox on a breadboard would have it the easiest, just pop out the old chip and put in the new and increase voltage. if you built one yourself on a circuit board, you just need to desolder the old, solder in the new, solder in higher voltage. same goes for buyers of adafruit's fuzebox.

the only people left in the dark would be buyers of sparkfun's uzebox avcore. unless sparkfun started selling 1284 avcores.

another talked about option is moving to the atxmega series, specifically one of the better models like the atxmega384. as well as increased rom and ram, the benefit here is the higher speed. 32 mips stock, compared to 28 mips(theoretical) for the current overclocked 644. and the atxmega could probably be overclocked also.
the drawbacks to the atxmega are incompatibility with existing hardware, software(partially?) and firmware(also partially?). the atxmega is also only available in surface mount, so then we're starting to edge away from the hobbyist crowd.

now, i don't want to sound to harsh here.
but in my opinion, moving to the atxmega would mean a smaller user base, and the possible demise of uzebox.

UNLESS, we find either the atxmega256 or atxmega384 on a breakout board from a reliable source. i'm thinking something like http://www.sparkfun.com/products/9546, but with the 256 or 384 on it. that could be a cool possibility if/when they come out.
but i've only seen the atxmega128 on a breakout board. and the atxmega128 has half the ram of the atmega1284.

so i've got four questions. first two are for uze6666.

1. how is your uzebox with the 1284 coming along since your september update here: viewtopic.php?f=4&t=651 ?
2. you mentioned that you bought the atxmega128 breakout board(unless i'm mistaken). have you found the time to mess with it?

3. what is eeprom, and what does uzebox use it for?
4. does uzebox allow deleting info in program rom and replacing parts of it with the sd card during program execution? effectively allowing programs to be as big as the sd card allows. i know the nes did this.

and thanks everyone for making uzebox what it is! i'm excited to hopefully dive into the uzebox soon.

[uze6666]

Hey,

Glad you like the project! That table is a pretty good recap. Though you could also add the often mentioned ARM Cortex M3.

people that built their own uzebox on a breadboard would have it the easiest, just pop out the old chip and put in the new and increase voltage. if you built one yourself on a circuit board, you just need to desolder the old, solder in the new, solder in higher voltage. same goes for buyers of adafruit's fuzebox.

Unfortunately it wouldn't be *that* easy. Almost all resistors values would need to be recalculated to match the elevated voltage, specifically the video DAC resistor network and SD card voltage dividers. Otherwise the picture would be too bright and out of spec and you could toast your SD card inputs.

1. how is your uzebox with the 1284 coming along since your september update here: viewtopic.php?f=4&t=651 ?

Not much, I've been very busy on "real world" work since a while. And the 1284 overclocking issues kinda cooled things down a bit...I agree with you that the 1284p seems the best successor, specially because it's bigger and still a DIP part. But having it both overclocked and overpowered doesn't seem viable to me. In these extreme conditions, I'm guessing the chips life span will be reduced much faster. In this context the xmega route would seem the only option. The other one, much more extreme, is going Cortex M3. Much more powerful @70Mhz+, external memory bus, etc. But then, why not go ARM9, AVR32 at 200+MHz and so on!? It's all a question of finding the perfect trade-off between simplicity, power and flexibility.

2. you mentioned that you bought the atxmega128 breakout board(unless i'm mistaken). have you found the time to mess with it?

Nope, not yet. Maybe during Christmas vacations...

3. what is eeprom, and what does uzebox use it for?

The EEPROM is a non-volatile memory section that the running program can re-write up to 100K times. The Uzebox games uses it to store hi-scores and other state (see pac-man, donkey-kong, etc). Each game reserves and ID that's used to access a small block of EEPROM.

4. does uzebox allow deleting info in program rom and replacing parts of it with the sd card during program execution? effectively allowing programs to be as big as the sd card allows. i know the nes did this.

Indeed. It has some limitations, but that's the way the SD card gameloader/bootloader works. Code located in the bootloader section is allowed to reflash the whole chip. But remember the flash can only be reprogrammed about 10K times.

-Uze

[portets]

mmmm.. cortex m3 does sound tempting..

but then what's to stop someone from building one with a more powerful ARM? if we give people a slower ARM, they'll want faster if it's available. that could split this project into 10 other projects requiring people to upgrade to the best chip, just so they can play all of the available games.

and going with arm means someone is bound to make a little NES emulator for it.
that could mean fewer new/unique games. not to mention arm being more complicated and incompatible with the current uzebox.


i think going with the most powerful atxmega we can find would be best. it's more powerful than the current uzebox, but not powerful enough to support an emulator. it would very much limit the chip upgrade options, creating a more unified project like the current uzebox is. there would be code compatibility between everyone's system due to everyone having the same chip, also like the current uzebox. the xmega is also more in-line with the classic 8-bit nostalgia that this project is all about.

and correct me if i'm wrong from here on, as i don't know much about this stuff yet:
going with xmega would just be a modification of the uzebox schematic. it would still be a two chip design with audio and video done in software. the ad725, DAC, all inputs and outputs, and DC circuit would stay close to the same. just modification of component values.

the xmega would also allow easy porting of the uzebox kernel, firmware, emulator and existing games/applications, due to being similar to the atmega644 in design.

but going with the cortex m3 would require new kernel, firmware, software and a new emulator(or modification of an existing emulator). as well as an entirely new, possibly more complicated schematic.

who knows, if enough people ask sparkfun to slap an atxmeg384/256 on their xmega100 breakout board....

now a couple more questions:

1. when overclocking the atmega or atxmega on the current uzebox circuit, does the clock speed have to be in certain increments due to timing issues, etc? for example to clarify: is there a specific reason why the uzebox is overclocked to 28mghz and not 27 or 29?

2. do you have a rough estimated guess on what the xmega's video mode 3 would be like? number of sprites instead of the current 20, a resolution higher than 240x224, etc. this is with assuming we remain with 4 audio channels and 256 colors.

[uze6666]

That's right, going Cortex would be a huge rework. So that's why I was looking more for the xmegas.

1. when overclocking the atmega or atxmega on the current uzebox circuit, does the clock speed have to be in certain increments due to timing issues, etc? for example to clarify: is there a specific reason why the uzebox is overclocked to 28mghz and not 27 or 29?

That's because the AD725 requires a clock that is 4 times the NTSC color burst frequency (~3.5795Mhz). In order to avoid video aliasing artifacts, the Uzebox must run at or a multiple of the AD725 frequency. Currently, it double that frequency (or 8 times the NTSC color burst freq).

2. do you have a rough estimated guess on what the xmega's video mode 3 would be like? number of sprites instead of the current 20, a resolution higher than 240x224, etc. this is with assuming we remain with 4 audio channels and 256 colors.

Well, that depends of what trickery can be done using all the new features of the Xmegas like DMA and the event system. Having 16K of RAM would definitively allow variations of mode3 to increase resolution and sprites count. If it can be slightly overclocked, we could crank the speed at 10 times the color burst frequency, or ~35.79Mhz. More speed could allow for new video modes, like palette-based ones and more sound channels.

-Uze

[portets]

ahh. thanks for answering all of my questions
hope i'm not making you feel too bombarded.

just a few more questions and i think i'll be set for a little while. hehe.

1. do we know if the xmega384 is even released? i've been having trouble finding them, seems that everywhere i've looked only carries up to the xmega256(which would be fine anyway ).

2. can the clock frequency of the uzem emulator be modified? i've looked in the code but can't find a straight answer. i just want to play with it between 32 and 42mghz. and also, running some of the more demanding games in uzem like D3thAdd3r's raycaster run at 22-23mghz instead of 28.

3. would it be (easily) possible to add ypbpr component video out to the uzebox?

[DaveyPocket]

I'd like to make a little comment here:

Have we tried modifying the current Uzebox kernel to fully work with the Atmega1284p? Is there anything more we can get out of using this instead of the 644? It seems like with more RAM and ROM Space, more could be done (Just what I think)

[uze6666]

1. do we know if the xmega384 is even released? i've been having trouble finding them, seems that everywhere i've looked only carries up to the xmega256(which would be fine anyway ).

Haven't look much for it. And don't hold your breath for the it, there was litterally 2 years between the time Atmel announced the Atmega1284p and when it was realeased.

2. can the clock frequency of the uzem emulator be modified? i've looked in the code but can't find a straight answer. i just want to play with it between 32 and 42mghz. and also, running some of the more demanding games in uzem like D3thAdd3r's raycaster run at 22-23mghz instead of 28.

The emulator synchronizes the frame rate to the sound driver since it must emit a sample for each and every scanline, including those in the overscan. IF the sound driver is dropped to regain more CPU (that may be the case for this demo), the frame rate in uzem won't mean much.

3. would it be (easily) possible to add ypbpr component video out to the uzebox?

Nope, the AD725 doesn't support this.

Btw, I was thinking about using the A1 series bus interface and use external SRAM. That would add a chip to the design, but that would greatly expands the possibilities like rendering double-buffer, data cache for sound and graphics, etc. In this case we could settle for less than 16K of internal SRAM.

-Uze

[uze6666]

I'd like to make a little comment here:

Have we tried modifying the current Uzebox kernel to fully work with the Atmega1284p? Is there anything more we can get out of using this instead of the 644? It seems like with more RAM and ROM Space, more could be done (Just what I think)

Ah, if it was not for the overclocking issues, this was a direct replacement for the 644. No kernel changes whatsoever is required, you can flash ROMs compiled for the 644 and it works fine.

-Uze

[DaveyPocket]

I'd like to make a little comment here:

Have we tried modifying the current Uzebox kernel to fully work with the Atmega1284p? Is there anything more we can get out of using this instead of the 644? It seems like with more RAM and ROM Space, more could be done (Just what I think)

Ah, if it was not for the overclocking issues, this was a direct replacement for the 644. No kernel changes whatsoever is required, you can flash ROMs compiled for the 644 and it works fine.

-Uze

So you're saying if a game requires more than the 4KB the 644 provides it will be able to address more memory in the 1284?

[uze6666]

So you're saying if a game requires more than the 4KB the 644 provides it will be able to address more memory in the 1284?

Yep. Naturally, to use more than 4K, you'd have to compile the game with the atmega1284p as the target otherwise the build process will throw an error.

-Uze