XMega cranks out NTSC color and digital stereo sound!

Go To Last Post
42 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Greets fellow Freaks!

The holidays finally gave me the chance to complete my XMega game/demo system I call Vixen384. This will be a hand held PCB with joystick control buttons and 3 RCA connectors to hook to any TV (NTSC input and R/L audio).

This system uses only a single XMega384 and a few resistors, doing all of the color and sound generation right in software. Currently, it does double buffered rock solid NTSC with 256 simultaneous colors as well as sampled stereo sound with a 4 channel mixer.

Thanks to much help from this great community, I have redone the entire AV engine in GCC so that games and demos can be written in C, while the bare-metal heavy lifting is done by my assembly routines in the background. No knowledge of NTSC or even interrupts is necessary in order to program this system.

This simple sprite demo was done in a few hours and fills about 50% of the XMega program memory.

Here is a screencap of the the XMega doing some sprite and sound tests. Please excuse the horrific quality of the video - the cheap USB capture stick really distorted the video. The real video is crisp and has no dropped frames at all.

YouTube Video...
https://www.youtube.com/watch?v=CXFOTpM2Jn4

At this point, I am sending away for a few proto boards and then will see if there is enough interest to make 100 units. I would like this to become a fun learning platform for GCC and the great XMega.

Thanks again to all who helped during my transition from Atmel Assembler to GCC.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool!

AtomicZombie wrote:
... I call Vixen384.
May not go over well with the women in the audience :(
Ref. http://en.wiktionary.org/wiki/vixen

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.
Vixen was the original name of the Commodore Vic-20, but the marketing department thought it was too "sensual". I have no such department to direct me, so I get to walk the line without reprisal. Since this project seduced me into many sleepless nights, I find the name fitting!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks to the entire audio/video engine being in assembly, the C coding is super easy. here is the code that makes the balls fly around the AVRFreaks logo...

//////////////////////////////////////////////////////////////////
////////// PART 4 : AVR FREAKS BALL ORBIT
//////////////////////////////////////////////////////////////////

	// INITIALIZE BALLS SIZE, COLOR, DIRECTION
	#define numballs 13
	
	for (balls = 0; balls < numballs; balls++) {
		dx[balls] = (balls*32)%128;
		bc[balls] = (balls+1)*16;
	}

	// PLAY DEMO MUSIC
	Channel1Set(LOOP4);
	Channel1Play(255,50,2);

	// RUN DEMO
	while (Channel1[13] !=0) {
		
		// CLEAR SCREEN
		ScreenClear(123);
		
		// ROTATING BALL SPRITE ANIMATIONS BACK
		for (balls = 0; balls < numballs; balls++) {

			// MOVE BALLS
			dx[balls] = dx[balls] + 2;
			bx[balls] = SineWave(dx[balls]+balls,140)-10;
			by[balls] = SineWave(dx[balls]+balls*16,60);
			br[balls] = SineWave(dx[balls]+64,13);
					
			// DISPLAY BALL SPRITES
			if (br[balls] < 4) AnimSprite16(bx[balls],by[balls],bc[balls],BALLANIM[br[balls]]);
			}
				
		// DRAW FREAKS IMAGE
		DrawImage16(30,21,0,FREAKS);
		
		// ROTATING BALL SPRITE ANIMATIONS FRONT
		for (balls = 0; balls < numballs; balls++) {
			
			// DISPLAY BALL SPRITES
			if (br[balls] > 3) AnimSprite16(bx[balls],by[balls],bc[balls],BALLANIM[br[balls]]);
			}

		// SWAP BUFFERS
		ScreenFlip();
	}

The video engine takes care of all timing and memory management. The command "ScreenFlip()" swaps the dual buffers for 100% flicker free animation.

I may do some retro arcade conversions next. Perhaps Gallaga or Gyruss. Maybe Wolfensten3D... ahh the possibilities!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that is pretty cool!

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice project. Did you try it with computer monitor? I’ve found that modern LCD monitors are more demanding regarding video signal quality.
BTW, what’s with your project to interface XMEGA with TV using HDMI?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting project. Your video says that you don't use an interrupts, so I am curious how you managed to get the timing good enough to produce a stable image.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, here are some answers...

Yes, I have tried this system using multiple NTSC sets, modern LCD and old glass units. I have followed the NTSC spec right to the nanosecond, so the image is perfectly stable on every monitor. I am using composite inputs (Video In, and R/L Audio In). I also have an alternative engine that drives VGA, but find the pixels too crisp. NTSC looks better as it "smooths" out the video at lower resolutions.

Interrupts are produced by the audio/video engine so that the user can program in C, not worrying about timing or memory management. So yes, I am utilizing 6 timers and an interrupt in the engine, but this is done in the background by my assembly code (one HUGE included .S file).

My plan is to release the system with my included audio/video engine which also includes many optimized graphics routines such as lines, circles, sprites, text, and even improved delay and Sine functions. The "user" can then code in C and make cool games and multimedia demos.

Of course, someone with assembly experience can also mod the audio/video engine as it is heavily commented and I plan on doing some very detailed tutorials on how to build an AVR video engine from scratch as well.

The video system is capable of resolutions as high as 1280x960, but the limitations are the NTSC signal and the onboard memory in the XMega384. I have managed a few colors at 320x200, and shades of grey at 640x400 onto a TV set. The current system is fully double buffered and bitmapped to 256 colors using a set of 150x100 frames.

I also wrote a VisualStudio program that converts bitmaps and wave files into .inc files to make it easy to add sampled sounds and sprites to the C program.

I am currently looking for a board house to make the PCB and do the assembly so I can offer this system as a ready to use product. Will also be releasing the full source codes, hex codes, PCB files and detailed tutorials on how to make it from scratch.

Still doing it on the odd weekend, but so close now!

https://www.youtube.com/watch?v=CXFOTpM2Jn4

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
Interrupts are produced by the audio/video engine so that the user can program in C, not worrying about timing or memory management. So yes, I am utilizing 6 timers and an interrupt in the engine, but this is done in the background by my assembly code (one HUGE included .S file).

Ah, okay, so when you said "no interrupts" you meant "loads of interrupts" :-)

It sounds like you decided to meet the NTSC spec exactly, hence the use of so many timers. How many are free now?

I found that I could produce PAL video that was okay on CRTs and LCDs without having to be so precise, so I just re-used one timer over and over. You will probably find you can loosen it up a lot and save yourself some resources.

Quote:
My plan is to release the system with my included audio/video engine which also includes many optimized graphics routines such as lines, circles, sprites, text, and even improved delay and Sine functions. The "user" can then code in C and make cool games and multimedia demos.

I was quote impressed with the big sprites. Are you just blitting them into memory or are they real sprites of some kind?

Quote:
I am currently looking for a board house to make the PCB and do the assembly so I can offer this system as a ready to use product.

Seeed have an MOQ of 100 but are pretty good. I have used them extensively before.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

AtomicZombie wrote:
... I call Vixen384.

It is a catchy name. If it stood for something -- e.g. VIdeo eXchange ENgine -- then it would make sense.

Vixen is a female fox, right? Why does a fox make a good name? What about our other animal friends?

As you are using gnu tools, what about "cow" if your board is female?
(also applies to alligators, dinosaurs, dolphins, hippos, whales, ...)
If porcine would you call it a "sow"?
(also applies to badgers, guinea pigs, bears, ...)
Surely it isn't a dog; otherwise it would be a "b....".
(also applies to coyotes, wolves, weasels, ...)

If a cat it would be a "queen". At first thought that sounds P.C. But then ...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One reason to use animal names for products is that they are not copyrightable/trade-markable so you cannot infringe anyone else's use by using them. On the other hand you have no protection and someone else could start making vixen "clones" and pass them off as an inferior copy of what your are selling.

As for the use of a vixen/female fox. I don't know about your neck of the woods but the following would be considered "foxy":

A real "vixen" you might say - very sexy indeed :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The Vixen name idea came from my favorite book "The Spectacular Rise and Fall of Commodore". I read it a lot to get inspiration. The stuff they managed to do back in the day!

I am not worried about copyright issues as I plan to release this as a 100% DIY project and then offer the boards for those that don't want to solder down a 64 pin TQ package. It is really a simple project hardware-wise. This project will be fueled by the community, much like this forum and my AtomicZombie site, so if someone feels like stealing the design and making cheap China boards, I will just have to rely on the community support to keep my efforts going. When I get AVRCade.com up and running, it will also showcase other multimedia AVR projects and have a load of source code and tutorials, so if I can make enough from my Vixen board kits to pay for the hosting, that will be great. My ads on LucidScience.com make enough to just pay the hosting costs, so that is a good sign. It's great to give back to the community, so I hope I see the same results from this project.

@Chan..

Yeah, I am using the XMega hardware to the max to bit-bang both the chroma and luma signals. It took many late nights to figure out how to synthesize the phase shifted 3.57MHz signal that has to overlay the analog portion without getting any artifacted colors, dot crawl, or tearing. The signal is so solid that it works even on the most demanding capture board. I dare say that the color is more crisp and stable than what I was getting when using the AD725 NTSC decoder chip.

But the video interrupt leaves tons of room (free cycles) for the main loop, so that is good.


https://www.youtube.com/watch?v=CXFOTpM2Jn4

The recent goal was to make a single .S include file that takes care of everything, leaving the user to program freely in basic C, and that really worked out well thanks to a lot of help from this community as I migrated to GCC-AS. My original system forced the user to program in assembly, and I realized that it would not create a large enough user base to justify making 100 boards to sell. Now this is the easiest of all game systems to program - no interrupts, no bizarre data packing. Just write basic C and call the drawing / graphics routines at will.

I took inspiration from the BlitzBasic language when I did my graphics routines. You start the main loop by clearing the screen, then you draw stuff, then you flip the buffers. It all happens 60 times per second, 30 fps if you are really working the routines.

Sprites are somewhat different than bobs, as they do have active transparency, color shifting ability, and can be stored as either 256,16,8 or 2 colors. They are unlimited in size and number though, so you are not restricted in any way. In the demo where it shows the large checker rotating sprites, they are 90x60 in size and 256 colors. The system could draw a dozen at once and keep up the frame rate! I only drew 3 in the demo because it looked cleaner and well.. it was also drawing full screen 256 color fire in the background at 30 frames per second!

All sound routine are also interleaved into the video engine, so the user just has to set the sample name, frequency, volume, channel#, and loop count. It is super easy.

Currently, here are all of the routines included with the video engine. These are part of the .S assembly file, but are called from the C program...

SystemReset();
ScreenFlip();
ScreenClear(Color);
ScreenSnow(Mode);
Delay(Value);
SineWave(Shift,Amplitude);
DrawPixel(X,Y,Color);
DrawPixelNB(X,Y,Color);
DrawLine(X1,Y1,X2,Y2,Color);
DrawRect(X1,Y1,X2,Y2,Color,Fill);
DrawCircle(X1,Y1,Radius,Color,Fill);
Channel1Set(Sample Name);
Channel2Set(Sample Name);
Channel3Set(Sample Name);
Channel4Set(Sample Name);
Channel1Play(Frequency,Volume,Loops);
Channel2Play(Frequency,Volume,Loops);
Channel3Play(Frequency,Volume,Loops);
Channel4Play(Frequency,Volume,Loops);
DrawSprite256(X,Y,Data Name);
DrawSprite16(X,Y,Color Shift,Data Name);
DrawImage256(X,Y,Data Name);
DrawImage16(X,Y,Color Shift,Data Name);
PrintChar(X,Y,Color,Character);
PrintString(X,Y,Color,String);
PrintConstString(X,Y,Color,String Data);

I am going to also include some 3D vector routines and try to implement a flood fill that uses minimal memory.

The XMega has some serious power! Every time I test another graphics routine, it blows me away to see it on the screen. My last retro game system used a Spartan3 FPGA and although it had more resolution, I must say that this XMega version is faster.

Anyhow, I am super excited about getting this project released, and hope it spawns a community of AVR multimedia projects. I have just set up a forum on AVRCade and will be contacting others who have made cool video projects / products so I can profile their work as well. Hopefully, my site will become a hub for those looking at doing video / game / demo stuff with AVRs. Not competition to this great forum, just a supplement.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

Last Edited: Thu. Jan 3, 2013 - 07:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congratulations, Brad. A great achievement. Impressive.

Nard

A GIF is worth a thousend words   She is called Rosa, lives at Mint17.3 https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for sharing Brad. I agree about the XMEGA and AVR architecture in general. The performance per clock is quite excellent for an 8 bit CPU. Makes me laugh when you see guys running their PICs at 96MHz and still sucking.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, XMega has really brought my projects to the next level. If Atmel ever released a 100MHz XMega with a 1MB program memory and 256K SRAM, then I may give up on FPGAs!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As someone who was involved with video games from (almost) the first(Nutting's SpaceBall), through the Breakout/Tank/Space Invaders/Stunt Cycle period right up until the BattleZone/Williams Defender/Qix era, and who once wrote an extremely crappy game for the Atari 2600, I am very impressed.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well thanks! If you can code for Stella, then you are indeed on of a select few. QIX... I used to like that game - simple, yet addictive.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You've made the big time! @Atmel on Twitter retweeted a post from @AtmelMCUJo that mentions your project and links to the YouTube video.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey cool! If Atmel "digs" my project then perhaps an all expenses paid trip to Norway to show the unit in person might be good.... yeah baby!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very interesting project.

AtomicZombie wrote:
I also have an alternative engine that drives VGA, but find the pixels too crisp.

Would you please to explain more about the problem?

Ozhan KD
Knowledge is POWER

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

electronic.designer wrote:
Very interesting project.
AtomicZombie wrote:
I also have an alternative engine that drives VGA, but find the pixels too crisp.

Would you please to explain more about the problem?

I have about a dozen VGA video projects (AVR/XMega/FPGA/CPLD/Pure Logic) ranging in resolution from 256x240 up to 1024x768 and have found that VGA pixels are so square and sharp that any resolution less than 400x300 is too blocky looking.

In one instance (a 320x240 retro game system), I added an analog component to the output latch, resulting in slightly hazed pixels, which was more true to a TV display, but in general, VGA is for high res. and NTSC is great even down to 128x64.

Another concern is pixel clock phasing on newer LCD VGA monitors. An LCD is not analog like the CRT, so it can only show its base resolution. So my 1600x1200 monitor is fine when showing 800x600 or 400x300, but when displaying something like 640x480 or 320x240, there is a slight banding as the pixel clock is "fudged" by the internal display processor in the monitor. Since I am much too insane to tolerate such glitches in my projects, I stay away from scaling too low of a resolution on VGA.

But to be honest, I do these projects just fo the challenge, and VGA is just so easy to generate that it bores me now. The entire goal of the Vixen project was to generate NTSC color all in software, and that kept my gears spinning for many late nights. With VGA, you just spew pixels from a port and let the monitor display the colors, but with NTSC, you need to generate an analog luminance level and at the same time send an overlayed phase shifted 3.579 MHz sine wave that causes a color shift. The process is 10x more cycle intensive on a micro-controller.

I am dabbling in sending HDMI from Xmega now through a simple CPLD serializer, but want need to get this project written up and put online before I lock the dungeon door again!

https://www.youtube.com/watch?v=CXFOTpM2Jn4
Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

Last Edited: Sat. Jan 5, 2013 - 05:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most impressive!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!

Now if I can find a North American board house that will assemble these units in quantities of 100 for less than $45.00 per unit, I will be happy.

Raw parts are about $18.00 per unit, and I figure a PCB will cost about $5.00, so I am not sure if an assembly cost of $22.00 is good or not. That seems to be the rate for the 2 quotes I have now.

So if I could turn a profit of even $20.00 per unit, then it would be worthwhile and allow room to expand into other AVR projects later on.

I have never tried anything like this, so I am not sure of a selling cost of $69.95 would be acceptable or not for this unit.

Manufacturing is a tough game when you are just a basement hacker!

I still intend to do the entire thing as an open source project anyhow and show tutorials on how to solder the Xmega to a carrier board, but it would be nice to offer ready to use boards as well.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You know how a project is never really finished?
Yeah...

So I was wasting some time tonight and read the AVR32 UC3 datasheet. I then started up a project in studio6 and did a bit of c+asm coding. You know what?... it isn't really much more difficult to work with an AVR32 as it is an XMega. Now, I don't yet have an AVR32, but it did get the program to compile and understand the basics of the chip.

So it got me thinking...

AVR32-UC3 with 512K is only a 3 bucks more than an XMega384, and it is certainly faster.

Perhaps I should do the first AVR32 retro NTSC game system. If that built in SDRAM EBI is half decently fast, that would sure make for some nice frame buffering and screen flipping. I can push 32MHz (read or write) from an SRAM on the XMega (overclocked to 64MHz)right now, but maybe the AVR32 can do this without bending the rules?

Hmmmm....

Now that it takes no more skill or $$$ to work with an AVR32 in Studio6, it makes me wonder why I would stay with the XMega. I mean really, it's friggn' C man... you just learn a few new reg names and you're stylin!

Anyone else come to this realization?
I think I am going to order an Xplain UC3 tomorrow and see where it takes me.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMega is a low power microcontroller platform. If you want performance then AVR32 might be a better bet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
If that built in SDRAM EBI is half decently fast, that would sure make for some nice frame buffering and screen flipping.
AVR32 AP7 has a LCD controller; looks like the AVR32 UC3A3 DMCA (not the PDCA) was a partial re-purpose of the LCD controller.
AtomicZombie wrote:
... but maybe the AVR32 can do this without bending the rules?
Noticed the thru-put difference on XMEGA SRAM vs DRAM.
Does the UC3A3 have this difference?
AtomicZombie wrote:
... it makes me wonder why I would stay with the XMega.
XMEGA is coin cell friendly; only some of the UC3 are.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting things to consider. But I best stick to my current project and get it out there before starting another one or I will never get anything past the 90% complete point!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi AtomicZombie.

Nice project you have here. Strangely, you are working on a a project similar to mine! I'm working to a console too, based on an Atxmega256U, But mine is working with memory mapped, and have 2 video buffers of 256x240 in 256 colors, and I use VGA instead.

I made NTSC display in the past, and also Color NTSC only in software with passive component and an Atxmega. But this time, I wanted something memory mapped, to have a good resolution and each pixel mapped to the screen. This way, I have the total control over the display, and all is easier to program in avr GCC for final user.

For the audio, my console is compatible with the .MOD audio format.

If you are interested to see it, here is the link to another forum :

http://uzebox.org/forums/viewtopic.php?f=10&t=1781

and 2 videos to youtube:

http://www.youtube.com/watch?v=hL3_t7yUrfc

http://www.youtube.com/watch?v=q6NhnOiSLk4

See ya!
Mast3rbug.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just when I was getting over my inferiority complex alongs comes AtomicZombie and Mast3rbug to remind me how pathetically slow my coding really is... :(

Nice job, guys! Both are impressive systems.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Just when I was getting over my inferiority complex alongs comes AtomicZombie and Mast3rbug to remind me how pathetically slow my coding really is... :(

Nice job, guys! Both are impressive systems.

JC

Hehe. I remember at the time, Nintendo VS Sega system. Which one is the better lol.

about 30 years later, it happen not on video console systems, but on 10$ chips!

Mast3rbug

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Mast3rbug... sent you a greets on your UZE thread. Great work on your project!

@DocJC... thanks, but no need for a complex... I can't do much else besides video stuff, so I better be decent at it after 4 years!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
@Mast3rbug... sent you a greets on your UZE thread. Great work on your project!

@DocJC... thanks, but no need for a complex... I can't do much else besides video stuff, so I better be decent at it after 4 years!

Brad

Hi Brad.

Any new development on your console?

from my side, I finished the video drivers, I'm now writing my first game. Turrican II with original music. I have found all the sprites on internet. Really cool.

Mast3rbug

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your balls have me utterly astounded.

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Awesome! Now if only you used external RAM, that would be great! Plus, loading resources and bitmaps from the SD card rather than from the little tiny poor program memory which should be for executable code only.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The XMEGA external RAM interface is kinda slow for this sort of thing. Maybe if you heavily overclock... What you really want is dual port RAM so that the XMEGA doesn't have to clock out each pixel by itself, which is basically what mast3rbug did except without the dual port bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand. What should be the frequency of the SDRAM to operate at the same speed as the internal SRAM? And what exactly is dual port RAM? SRAM or SDRAM? Can I see the schematics?
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The way external RAM works on the XMEGA it is just inherently slower than SRAM. Nothing can overcome that.

 

Dual port RAM is like normal RAM but has two I/O ports so that two devices can read/write it at once. It's often used for video memory so that the CPU can access it at the same time as the video DAC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow. I had no idea dual port RAMs exist. So that way there can be two XMegas. One for processing the game and the other for processing the picture. That video buffer will surely be big! If there's gonna be a TV XMEGA project with 320x240 resolution in color, I'll be so happy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately, it's been 2 1/2 years since his last post in this thread. I have a feeling that making a living and real life got in the way.

Last Edited: Tue. Jun 30, 2015 - 10:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I simply must try this some day.

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was wrong. He just took a detour.

 

 

AtomicZombie Jun 30

AtomicZombie's picture

Hello,

 

I kind of took a "detour", heading back in time to try something much more "retro"!...

 

http://forum.6502.org/viewtopic.php?f=4&t=3329

 

Brad

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I was wrong. He just took a detour.
Holy <phneeeep>!!

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]