Atxmega NEW powerkill CONSOLE

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug »

majorsky78 wrote:Hi!

Great work so far!!! Looks very promising!

Is the automatic adressing now finally working? I did not see any more investigations about this.
It would be a pity, if we have this possibility, but cannot use it because of SW or HW bug?

Regards,
Andre
Hi.

No it will not work. it's an hardware limitation. But after all, it will not make a big difference if you take into account that during a video line generation, you can only compute local RAM data and calculation, and also you have to do the sound and mixing 4 channel during each line. So at the end, maybe 40% speed increase... But anyway, I was planing to do it at 40 MHZ, but now, I don't have the hardware scanline, but it running stable at 64 MHZ. So, It's a net advantage anyway.

Mast3rbug
jeffreygoines
Posts: 1
Joined: Wed Jan 09, 2013 12:45 am

Re: Atxmega NEW powerkill CONSOLE

Post by jeffreygoines »

Very cool work on your project. Looks like the xmega sure has a lot of power. Here is an Xmega project on avrfreaks doing ntsc color without any external parts...

http://www.avrfreaks.net/index.php?name ... c&t=128249

Looks like Xmega could give some of the ARMs a bit of a run!
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug »

Wow.

I know AtomicZombie a little, I talked to him a few times. But I didn't know that he was working to a similar project! Really strange, two persons at the same time, working on similar project. Kind of funny!

Mast3rbug.
AtomicZombie
Posts: 23
Joined: Wed Jan 09, 2013 5:16 pm

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie »

mast3rbug wrote:Wow.
I know AtomicZombie a little, I talked to him a few times. But I didn't know that he was working to a similar project! Really strange, two persons at the same time, working on similar project. Kind of funny!
Mast3rbug.
Greets Cedric!
Seen your hello on AVRFreaks and decided to drop in here.

You have made some amazing progress on your project since we last talked on AVRFreaks.
Yeah, it is so cool that we have almost done the exact same things over the last year. In fact, I had just finished a VGA system as well right before trying to bitbang the NTSC color version. I guess us VideoFreaks all think alike because when I was doing a retro system years ago, the amazing UzeBox had just been release only days after I posted my project on AVRFreaks. It must be some kind of virus that drives us!

Wow, there is a lot of great info here, and this is a great community. I should have peeked in here earlier, but when you are up until 3:00 am counting cycles, who has the time!?

I will have to post my XMega VGA project soon so we can compare work. I see you did the same 8xtimer technique I did, creating an automatic 8 bit counter. I found that the timers had a 2-5ns phase error as well, but did find a way to correct this. Instead of using a 245 or 244 as an output buffer, use a 373 latch, and control LE on the last cycle so that all addresses are put back into sync. This works perfectly. You can also use the 373 OE as a blanking pin.

I have another system that uses 8 timers and has only 1 extra chip (the SRAM) and it manages 420x480 resolution using the internal PLL up to 64MHz. I hope to find enough time soon to detail my Vixen project on http://www.avrcade.com, and I will then post all of my XMega VGA projects as well. We should collaborate on a project one day, I think we have the same hard-wired brains!

The Vixen project was a fun challenge. I sat down one free weekend and decided I would find a way to push out 256 NTSC colors without any external hardware. it took some careful PWM and cycle counting, but it turned out very well. The video is even more crisp than the AD724 version I was working on earlier. I did get 150x100 (dual buffered) resolution out of an XMega384, and although this is low, it looks great on a retro set. The 4 channel stereo sample mixer was an added bonus thanks to having so much free time on each line. Now doing some 3D routines and compression stuff.

Anyhow, great work! I look forward to seeing your progress and will bug you for some more details when I get my AVRCade site up and running. I want to profile every working AVR video or sound project I can find and try to make the site a hub for video freaks like us. I have about 20 tutorials to post (including some of my old LucidScience work), and hope it will inspire others to jump in and push these great AVRs to their limits. You will get a kick out of my bit banged color NTSC video system running on an 8 pin ATTiny... color pong with stereo sound!

I am under the gun to complete my AVR projects and get the site up and running because in a few months I switch to bike building and don't do much electronic work. If only a day was twice as long!

I would also like to send greetings to UZE666 and say thanks for your work. I know how much time and effort it takes to do these projects and then create these tutorials..... respect!

Cheers!
Brad
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Atxmega NEW powerkill CONSOLE

Post by uze6666 »

I would also like to send greetings to UZE666 and say thanks for your work. I know how much time and effort it takes to do these projects and then create these tutorials..... respect!
Heeeyy nice to see you around here! :D I also really like your work and your great tutorials on LucidScience. I recall seeing your Youtube video about your VGA console...pretty cool. And you are quite right on the effort required to create and maintain such a project...I wished I had there was more time to join and comment on other similar communities! Just like you guys,I started fiddling with the xmega in 2011, but the Uzebox PCB & kits I decided to sell took over. I'm quite happy and curious to see you could do NTSC without external parts, I had a gut feeling it could be done but never had time to dig into it.
AtomicZombie
Posts: 23
Joined: Wed Jan 09, 2013 5:16 pm

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie »

uze6666 wrote:
I would also like to send greetings to UZE666 and say thanks for your work. I know how much time and effort it takes to do these projects and then create these tutorials..... respect!
Heeeyy nice to see you around here! :D I also really like your work and your great tutorials on LucidScience. I recall seeing your Youtube video about your VGA console...pretty cool. And you are quite right on the effort required to create and maintain such a project...I wished I had there was more time to join and comment on other similar communities! Just like you guys,I started fiddling with the xmega in 2011, but the Uzebox PCB & kits I decided to sell took over. I'm quite happy and curious to see you could do NTSC without external parts, I had a gut feeling it could be done but never had time to dig into it.
Thanks!
I still remember when you first launched. I was on the beach in the Dominican working out some FPGA retro games design using an AVR as the "cartridge" and then POW... there was your amazing system! It was great to see so much being done with so little circuitry and using mainly DIP parts. Too bad those days are slipping away.

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug »

I will have to post my XMega VGA project soon so we can compare work. I see you did the same 8xtimer technique I did, creating an automatic 8 bit counter. I found that the timers had a 2-5ns phase error as well, but did find a way to correct this. Instead of using a 245 or 244 as an output buffer, use a 373 latch, and control LE on the last cycle so that all addresses are put back into sync. This works perfectly. You can also use the 373 OE as a blanking pin
Ho no! You know what? I known that! I don't know why I have not applied it to this situation damn.... Now I just want to test it, my hardware is already made for that! I have just one wire to route somewhere else, I already use a 573 buffer... Thanks for the hint! What I understand is that I have to put the LE on the LSB of the counter, to latch the pixels DATA at the latch end of all counters? I think it make sense...


For the NTSC generation in software, I already made some tests in the past like you already know (We talked about that on avrfreaks), but with medium results. and you was working on that too without more interesting results... But it looks like you have found the right way to do it. (on my side, the colours was slowly changing from line to line.) Here is the link to the post: (for other here)

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

it might be interesting to share our way of doing some tricks one day.

Mast3rbug.
AtomicZombie
Posts: 23
Joined: Wed Jan 09, 2013 5:16 pm

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie »

Let me know how the 373 latch system works out. Your video should be rock solid once you get the transparent latch opening just after the last counter has settled.

I am using the phase shift of a PWM timer to control the chroma rotation. I read the byte, copy it to a spare register, swap the nibbles then AND it with 15 to remove the luma info. I then check to see if the chroma is value zero and do some trickery to set the data direction regs on the pin with the chroma PWM output. That part was tricky, but needed if you want shades of grey. Without dropping the chroma on 1 of your 15 values, you will always be sending color and have no greyscale. After that part, I AND the copied reg with 240 to remove the chroma info and send it out of the last 4 bits of a port to the 4 bit R2R DAC. This gives a nice palette of 16 colors with 16 shades each for 256 colors.

This system requires a pixel clock of 16 in order to shift through all of the colors. This also keeps the color sub-carrier overlaid nicely with each pixel - no chroma pattern or artifacting in the image. Cleaner than an AD725 actually.
I will post the full code with a much better explanation when I have the chance.

I am also working on an NTSC system using a 512K external SRAM, and it does 256x200 resolution with 10 full pages. I have only 1 external IC in this system, a quad AND gate. I can't wait to finish this one as well, it has some serious magic happening in it. My new single AND gate system replaces the trusty and true XGS style multiplexed gate delay system that requires at least 6 external ICs.

This stuff is so much fun! Reminds me of the long nights I would spend glaring into that old tube TV, hacking away on my Vic-20!

Cheers!
Brad
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug »

Ha ok.

I was not using any counters, it was only static in the line generation itself. I think this was my problem. I have not tried really hard on that.

Also I have a strange bug here:

maybe Brad or UZE have already had this bug in C:

I have an ASM function, very simple:

Code: Select all

getworkbuffer:
	in    r24,framebuffer
	andi r24,0b10000000
	clc
	rol r24
	rol r24
	ret
the returned value is zero. You can even replace the code by this, it will do the same:

Code: Select all

getworkbuffer:
        clr r24
	ret


when I do something in C to call it:

Code: Select all

if (getworkbuffer()==0)
{
some code
}
it does not work

if I do:

Code: Select all

if ((unsigned char)getworkbuffer()==0)
{
some code
}

it works, it go to the IF condition. My .h definition is unsigned byte. I suspect that is a compiler bug... because normally a typecast take some CPU cycles, but not in this case. I suspect the compiler to compare with an integer and since I don't use r25, it have some garbage in r25 and it compare to something like 0x3400 instead of 0x00

Someone know something about that?

EDIT:

I have made some test, when I clear R25 to 0, it works without the typecast. So, it must be a bug in the compiler?


Mast3rbug
AtomicZombie
Posts: 23
Joined: Wed Jan 09, 2013 5:16 pm

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie »

It's always difficult to find the problem without knowing the before and after.
It looks like you are doing a routine that determines which frame buffer is presently selected? Might be faster to use sbrc or sbrs to make your tests on the value?
Perhaps the value returned from "IN" is not what it should be?
Is there in an interrupt happening that borks the value of r24 before your routine returns?

If you do this, do you still get zero as a return value?...

getworkbuffer:
ldi r24,123
ret

If you get 123 as would be expected, then there must be something alse awry!

Test this as well just in case...

getworkbuffer:
clr r25
ldi r24,123
ret

Oh the fun!
Brad
Last edited by AtomicZombie on Thu Jan 10, 2013 6:39 am, edited 1 time in total.
Post Reply