Yet another future of uzebox+comparison of chips

[portets]

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.

hmmm..

and that added chip wouldn't be a problem because it could be a small DIP.

i don't know why i didn't think about that. the only difference between the xmega models are ram and eeprom. otherwise they're identical.

would 2K vs 4K of eeprom limit us in any way?

and what could the "8KB Boot Code section" be used for? all xmega's have it.

[uze6666]

SRAM in DIP are too small to be seriously considered (32K). We'd have to go SMD for 256K-512K. I reckon that if one can solder the xmega, the sram should be a piece of cake!

By the way, there is differences between the Atxmega families. The AtxmegaxxD don't have DMA, external BUS and audio DACs. And there's more difference in the peripheral within sub-families like A1, A2 and A3. Check Atmel's parametric product table for more details.

2K of EEPROM is way enough to store game scores. The bootloader would be used the same way as for the current Uzebox, to hold the SD card game loader.

-Uze

[portets]

SRAM in DIP are too small to be seriously considered (32K). We'd have to go SMD for 256K-512K.

i was actually looking at the 32K 8-pin DIP on digikey when i mentioned that. here
i was thinking two of them for $3.50 would be simple and a total of 72K(64+8 on xmega128a1).

were you thinking about loading entire games into ram, and running them from there?

I reckon that if one can solder the xmega, the sram should be a piece of cake!.

i was hoping we'd all just use the sparkfun xmega100 breakout.

By the way, there is differences between the Atxmega families.

sorry, i meant within the A1 family.

[DaveyPocket]

Another question, how simple are these atxmega's to program? Would I still be able to use the ISP (AVRISPmkII) programmer I have?

[uze6666]

Another question, how simple are these atxmega's to program? Would I still be able to use the ISP (AVRISPmkII) programmer I have?

Yes! Atmel uses a new programming/debug interface (PDI) but AVRISPmkII supports it with the same 6/10 pins connector. AVRstudio support the chips, so it should be as easy to program as the ATmegas. The pin assigment for the PDI interface can be found in Atmel's application note "AVR1005: Getting started with XMEGA" (page 9).

-Uze

[MonteroJCs]

Maybe a change of topic, but I would like to ask what happend with the networking issue. I think I read something about it but I couldn't understand why was impossible (or not) to add an ethernet port to the Uzebox

[Flecko]

Simply put, adding the networking would take away flash and ram that is already so precious on the Uzebox. It would be possible to add it, but then our games would have to be even simpler.

The more complicated answer is that networked games take a lot of 'fiddling' either on the client side (if the Uzeboxes are going to talk to a central server) or on each peer if its going to be 1 to 1. Trust me...its a lot of work.

[uze6666]

Yeah I agree. It's still something I want to try out, but using "helper" hardware, like those Wiznet modules. Some have a simple SPI interface so it should not be very hard to develop a very simple API to exchange data with another peer. However it can get tricky when we talk about peer discovery, latency and so on. Tricky, but an interesting challenge nonetheless. I just still didn't find that "Wow" Ethernet module that's cheap enough so everyone would like to buy and use.

On another subject (well, the subject of this thread actually ) I've started fiddling with my Atxmega128 Sparkfun board and making it "wire-wrappable". Still have to get a 3.579545Mhz crystal to try out the chip's PLL internal clock multiplier and see if I can crank it to 35.79Mhz or 10 times the NTSC color burst frequency. That would give us a sweet 20% more raw CPU power. Add to this all the cycles that will be saved using the new DMA and event systems (that can do a lot of stuff in the background without cpu intervention) and thing starts to get very interesting. I also plan to test the external bus interface with a 128K SRAM chip I have (3$ Digikey). Though I know it wouldn't be a "2 chip" design anymore, it would indeed add a slew of possibilities, while remaining quite retro (regarding it's limited amount). Amongst other, it would allow a full resolution double frame buffer and memory space for sprites and graphics data loaded from the SD card. Feel free to comment on external RAM thing, I'm interested in hearing what you think about it.

-Uze

[portets]

aww, i guess i laid it down kind of heavy.
i should learn more before talking about these kinds of things.

i'm just so excited about a newer diy console.


well, keep us posted on your atxmega work uze. i'd love to get some chips and help you prototype and play around with it. but alas, i'm lacking skills.

[havok1919]

Howdy everybody,

Just making my semiannual appearance to see what's up.

We've been using the Xmega32A4 on a gaming platform, so based on that experience smaller external SRAMs might not be totally useless. You can DMA from an SPI based SD card to memory with very little CPU overhead (interestingly enough, you can even throw that same data through AES decryption with only a negligible performance hit!), so paging out external SRAM on the fly from the SD card is an option. (ie, you could ping-pong buffer the SRAM and easily stream graphics or level data or sound or whatever from the card while only needing a relatively small SRAM connected.

OTOH, sticking down a 16Mbyte SDRAM on the 128A1 is about the same amount of work soldering-wise and has a much larger 'elbow room' upside, obviously.

Uze, have you looked into using the event system and DMA to an IO port for video generation on the xmega? (I've glanced at it and it *seems* like that'd work. With so many timers and that crazy event system it's hard to wrap your brain around how to do things sometimes.) I confess that I'd be pretty leery about overclocking on the Xmega-- based on the amount of scrap I had with the AVCore and our problems going to the 1284 there *is* something to be said for coloring inside the lines.

Oh, I'll also mention that it's pretty straightforward to go from the "RGB" output of the Uzebox (prior to hitting the RGB->NTSC encoder) to component video. It's just some op-amps really.

-Clay