Atxmega Videogame Console NEW!

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Atxmega Videogame Console NEW!

Post by mast3rbug »

First, MERRY CHRISTMAS to ALL OF YOU! I don't know if you remember me but I have tried to do composite video signal with an atxmega without the AD725 chip.

A few months later, I'm back, but with another idea. Why do we need to output a video on a old composite signal that is already out of this world when we can probably generate a more precise VGA output directly from the atxmega with some resistors only?
So, for the past week, I have messed aroud with the ATXMEGA and made some test to see if it can be possible to do some useful VGA signal generation with this MCU.
after a few hours, I was able to output a static picture.
Video generated by atxmega with direct output
Video generated by atxmega with direct output
3.jpg (92.55 KiB) Viewed 16308 times
Now, after 1 week of my free time, (Coding instead of sleeping at night...) I have managed to have some cool results and here is what achieved:

CPU: ATXMEGA256A3
MAX SPEED: 32 MHZ
OVERCLOCKED TO: 42 MHZ (STABLE)
RESOLUTION: 224 X 240
NUMBER OF COLORS: 256
REFRESH RATE: STANDARD 31 KHZ HORZ 60 HZ VERT VGA SIGNAL
EXTERNAL MEMORY: NONE
INTERNAL MEMORY: 16K
FLASH MEMORY: 256K
TILE BASED DISPLAY UNIT: 8X8 pixels
TILE RESOLUTION: 28X30 (224 X 240 pixels)
ON SCREEN SPRITES: UP TO 128
MAXIMUM SPRITES ON THE SAME LINE: 6 SPRITES

Of course, all is in assembly language. The work was really hard because at 31KHZ Horizontal refresh speed, the remaining free cycles to manage all the sprites animation is really low. Now, I will start to do the sound engine. What I want for the sound is not like the UZEBOX retro sounds, but .MOD compatible (OLD AMIGA and PC music style with samples). Since we have 256K of FLASH memory, a nice .MOD music file can easily be under 100k, I think this is not a problem at all. And for composign purpose, you can use any .MOD music file editor!

Anyway, that's all for the preliminary test, and of course, here is a video of the first animation I have made after all the debugging done 30 minutes ago! (Patterns reused from an old MARIO BROS projects for testing...) Enjoy and again, MERRY CHRISTMAS to all of you!




here is fast made schematic:
xmegaschematic.JPG
xmegaschematic.JPG (57.73 KiB) Viewed 16303 times
Feel free to ask and comment!

Mast3rbug.
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: Atxmega Videogame Console NEW!

Post by HardlyUnique »

Wow! Awesome! I'm very impressed! Nice job, especially for a week of work! :o I wouldn't mind seeing a pic of the hardware, if you get a chance :).

Nice choice for a test pic, btw ;).

Merry Christmas!
User avatar
martinsustek
Posts: 117
Joined: Sat Apr 30, 2011 11:34 am
Location: Ostrava, Czech Republic

Re: Atxmega Videogame Console NEW!

Post by martinsustek »

Looks nice, I've thinking about VGA because it's very common these days.
I think that also fully bitmapped video mode or mode with ramtiles should be possible with that hardware.
What about toolchain, is it AVR-compatible? And how expensive is that chip? Is it possible to get it in some DIY solder-friendly package? What about SD card possibilities? Is it possible to run code from SD or read in-game data (picture, video or music) directly at runtime?
Mod compatible sound engine is a great idea for music, but I'm not sure about sound effects (there should be some option to trigger some sound at certain time).
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Atxmega Videogame Console NEW!

Post by uze6666 »

Hey Mast3rbug,

Awesome! I also agree composite video is deja-vu by now and VGA ports are the way to go (they are on all new TVs anyway). I have one of those xmega256 lying over here. Hopefully in january I will have time to build the circuit and try to see how hard it would be to port the Uzebox kernel to the xmega. Btw, if you could arrange the RGB to output on the same port pins as on the uzebox that would greatly help that goal. :)
What about toolchain, is it AVR-compatible? And how expensive is that chip? Is it possible to get it in some DIY solder-friendly package? What about SD card possibilities? Is it possible to run code from SD or read in-game data (picture, video or music) directly at runtime?
Yes, you can use AVRStudio, it's basically an ATmega644 with more RAM, flash and peripherals. However it's only available in SMT form (TQFP 64 pins doesn't seem so bad). These chips have 3 SPI interfaces, so one of them could be used for the SD interface, just like the Uzebox. Since it's an atmega, you can't execute code that is not flashed. But I believe the same bootloader function is available.

Merry Xmas!

-Uze
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Atxmega Videogame Console NEW!

Post by mast3rbug »

HardlyUnique wrote:Wow! Awesome! I'm very impressed! Nice job, especially for a week of work! :o I wouldn't mind seeing a pic of the hardware, if you get a chance :).

Nice choice for a test pic, btw ;).

Merry Christmas!
You really want to see the messed hardware setup? lol You will be deceived, only one chip and a few wires (A lot of unuzed wires from other projects over the time...)

Here the picture:
AtxmegaUZE.jpg
AtxmegaUZE.jpg (130.4 KiB) Viewed 16201 times
Ho and one important thing to mention here, about the test pic... It's not a test pic, it's a real time tile generated graphic AND sprite animation overlay. So from now, the hardware is 100% ready for side scrooling programming with no sound for the moment. The tiles in the Demo video is from my first videogame console project a few years ago.

Thanks!

Mast3rbug.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Atxmega Videogame Console NEW!

Post by mast3rbug »

martinsustek wrote:Looks nice, I've thinking about VGA because it's very common these days.
I think that also fully bitmapped video mode or mode with ramtiles should be possible with that hardware.
What about toolchain, is it AVR-compatible? And how expensive is that chip? Is it possible to get it in some DIY solder-friendly package? What about SD card possibilities? Is it possible to run code from SD or read in-game data (picture, video or music) directly at runtime?
Mod compatible sound engine is a great idea for music, but I'm not sure about sound effects (there should be some option to trigger some sound at certain time).

Hi.

-Yes, This is RAMTILE based.
-Yes, A RAM BITMAPPED mode is possible (And will be implemented) 120X120 256 colors, OR 160X190 with 16 colors.
-For the toolchain like UZE said, it's 100% Avr studio compatible like all other atmega
-For the price, at digikey, for a single unit it's priced at about 17$ for single unit and 11$ for 25 units. It's possible to also use the cheaper (10$ single unit and 6$ for 25) ATXMEGA256A3 instead of D3 since no special features like DMA or Routing events are used. But the problem is that the D3 version have no JTAG programming feature. Only PDI interface. I'n not sure, but I think the DRAGON is not compatible with that?
-For the sound, If possible I want to make 4 channels for music and 1-2 channels for sound effects and triggers events.

Mast3rbug.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Atxmega Videogame Console NEW!

Post by mast3rbug »

uze6666 wrote:Hey Mast3rbug,

Awesome! I also agree composite video is deja-vu by now and VGA ports are the way to go (they are on all new TVs anyway). I have one of those xmega256 lying over here. Hopefully in january I will have time to build the circuit and try to see how hard it would be to port the Uzebox kernel to the xmega. Btw, if you could arrange the RGB to output on the same port pins as on the uzebox that would greatly help that goal. :)
What about toolchain, is it AVR-compatible? And how expensive is that chip? Is it possible to get it in some DIY solder-friendly package? What about SD card possibilities? Is it possible to run code from SD or read in-game data (picture, video or music) directly at runtime?
Yes, you can use AVRStudio, it's basically an ATmega644 with more RAM, flash and peripherals. However it's only available in SMT form (TQFP 64 pins doesn't seem so bad). These chips have 3 SPI interfaces, so one of them could be used for the SD interface, just like the Uzebox. Since it's an atmega, you can't execute code that is not flashed. But I believe the same bootloader function is available.

Merry Xmas!

-Uze
Hi UZE.

I have carefully used the same layout as UZEBOX for the RGB output. But I don't believe that it can be direct compatible with actual UZEBOX stuff, but eventually with the kernel adapted, can be recompiled with little effort to run on the VGA atxmega. It's very difficult to generate a VGA signal with SPRITES. The video signal is twice the normal composite speed (31kHz instead of 15kHZ) and the atmega644 is already overclocked to 28 mHZ... the Atxmega is overclocked to only 42 MHZ... to be able to do the same work than the UZEBOX the clock speed should be 56 mHZ. So for this reason, I used a special trick. Something used in an old computer, the AMIGA. On the Amiga, the graphics was interlaced with black lines between each and it produced (to my opinion) better visual graphics than the one with doubled scanline. So I can work on the next display line between each line. But even with this technique, it was really hard to manage 6 sprites on the same scanline. At first, it was simply impossible. But after a lot reflexion, I had the idea to prepare the sprites in the 25 Front Porsh unused lines. Even with this, only 5 sprites was possible with the horizontal 224 pixels. The 6th sprite is generated in the active line black left border, and I just relaized that I can push a 7th sprite in the Horizontal pulse of the active line scan (It can be usefull for shooting bullet after all).

Thats all for now!

Mast3rbug
User avatar
martinsustek
Posts: 117
Joined: Sat Apr 30, 2011 11:34 am
Location: Ostrava, Czech Republic

Re: Atxmega Videogame Console NEW!

Post by martinsustek »

I'm not sure if we both understand same thing by ramtile. In uzebox mode 3 there are not limit for number of sprites per scanline, because sprites aren't actually computed per scanline, but precomputed into ramtile (as composition of original tile + part of sprite). Drawing line is then composed only from drawing tiles from flash or ram. I think this should be preferred approach.

I think that with possibilities (ram and flash size) of atmega we can also do mode 3 like mode with 2 bit addresses (to overcome 255 tiles limit).

If we are trying to create better Uzebox sequel (with better HW), what about making some improvements in concept:
Graphics: 24 or 16 bit colors (instead of 8 - Atmel writes it's 8/16 bit MCU) there may be modes with more colors or statically/dynamically paletted 256 color modes (for backward compatibility, saving memory or palette effects).
Sound: Consider stereo, please. I'm not sure if current appproach 1 bit PWM has good quality for playing MOD-quality music, I saw few MOD players with AVR, but all had external D/A converters.
Controllers: What about using some today's controller interface (USB?) instead of relatively hard-to-find SNES - it will also open possibility to analog controllers. But I don't know how hard is it to do USB host (I saw only project of USB joystick, not USB joystick "receiver"). Maybe gameport will be easier to interface, but not so common these days. There will raise problems with calibration or buttons/axis mapping, which could be done in per-application or by kernel (storing values in eeprom by special calibrating application.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Atxmega Videogame Console NEW!

Post by mast3rbug »

martinsustek wrote:I'm not sure if we both understand same thing by ramtile. In uzebox mode 3 there are not limit for number of sprites per scanline, because sprites aren't actually computed per scanline, but precomputed into ramtile (as composition of original tile + part of sprite). Drawing line is then composed only from drawing tiles from flash or ram. I think this should be preferred approach.

I think that with possibilities (ram and flash size) of atmega we can also do mode 3 like mode with 2 bit addresses (to overcome 255 tiles limit).

If we are trying to create better Uzebox sequel (with better HW), what about making some improvements in concept:
Graphics: 24 or 16 bit colors (instead of 8 - Atmel writes it's 8/16 bit MCU) there may be modes with more colors or statically/dynamically paletted 256 color modes (for backward compatibility, saving memory or palette effects).
Sound: Consider stereo, please. I'm not sure if current appproach 1 bit PWM has good quality for playing MOD-quality music, I saw few MOD players with AVR, but all had external D/A converters.
Controllers: What about using some today's controller interface (USB?) instead of relatively hard-to-find SNES - it will also open possibility to analog controllers. But I don't know how hard is it to do USB host (I saw only project of USB joystick, not USB joystick "receiver"). Maybe gameport will be easier to interface, but not so common these days. There will raise problems with calibration or buttons/axis mapping, which could be done in per-application or by kernel (storing values in eeprom by special calibrating application.
Wow. I'm not really sure that you know what are the limitations here. The first limitation is that the CPU is inferior to the initial UZEBOX due to the fact that the Horizontal scanline is twice the speed of an composite video.
-The sprites are already in RAM because it's impossible to do FLASH based sprites because it need 1 more cycle to read and the 31khz scanline is too much time consumming for that. It's possible to do unlimited sprites on a scanline but at the cost of animation speed (not 60 FPS...)
-16 or 24 bit is out of the question because the time to load and latch two color data on one scanline will result in only like 64 horz pixel with direct drive and will need external components latching gates to overcome the delay between the two pixel out and with that, let us with a mere 32 pixels output.
-For USB controllers, Ok, it's possible with external hardware. But if you want to manage hardware with single chip, you will need stable and constant interrupt to answer to the USB BUS or you will be disconnected. You don't have this process time available when generating time critical video signals.

This is is a retro minimalist computer machine, it's already a challenge to display gaphics on it. All is generated without external active hardware. If you want a more complexe machine, you can code on a PC with direct X? I mean, the fun is that we can do magic tricks with a MCU that is designed to run a microwave oven! You can also do more complicated stuff with an ARM9 MCU, but hey, this MCU is made for doing that!! so what is the challenge?

Mast3rbug
User avatar
martinsustek
Posts: 117
Joined: Sat Apr 30, 2011 11:34 am
Location: Ostrava, Czech Republic

Re: Atxmega Videogame Console NEW!

Post by martinsustek »

You're right at colors part, I didn't noticed that twice output means not only twice memory, but also twice computational power.
Necessity of pre-loading tile data into RAM should be an issue, because it will limit us in count of useable tiles than keeping tiles in FLASH.
You wrote that maximum sprites per line is 6, that lead me to hypothesis, that you're using Mode-2 approach (generating picture data on-line for each scanline) instead of Mode-3 approach (precomputing tile data at spare time, not during rendering). I believe, that atxmega has enough computational power to load tile data from flash. How many instructions do you have for each pixel to render?
Interlacing is good idea to get more processing power, but it should be tested on more monitors (old analog and new digital ones - in fact my current TV shows Uzebox's picture interlaced).

About controllers: I know, that USB protocol is very hard to implement, but I'll be great way to open uzebox for different types of controllers (gamepad, joystick, racing wheel, guitar, etc.). Gameport has support for only 4 buttons (2x2 for 2 players), I think, and it's too few. So we'll probably keep SNES.

About sound: I've fiddled with atxmega datasheet, and found, that it has 2 12bit DAC channels. I don't know if it has audio quality, but at least it's good think to test if sound can be generated using it.
Post Reply