Atxmega NEW powerkill CONSOLE

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
AtomicZombie
Posts: 23
Joined: Wed Jan 09, 2013 5:16 pm

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie » Thu Jan 10, 2013 6:37 am

AtomicZombie wrote: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!

And just to be safe, try...

getworkbuffer:
ldi r24,123
clr r25
ret


Oh the fun!
Brad

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug » Thu Jan 10, 2013 6:38 am

lol.

Yes the fun.

Sure, I must do sbrs instead... This routine was written late yesterday lol. Sometimes when it's too late I took the complex way.

I'm sure the routine works, because when I do:

Code: Select all

mychar=getworkbuffer();
if (mychar==0)
{
some code
}
it works. The bug is only when I put the function call directly in the IF, I must use typecast.

I'm sure it's a compiler bug, it compare to a integer instead of a char. I don't know if we can safely clear R25 even if the function definition is char? can we? If we can, I will do it because like I said, if I put 0 directly in the register, it's the same. When I put R25,r24 to 0000 it works. I will search around on forums to see if I can find something.

Thanks
Mast3rbug

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug » Thu Jan 10, 2013 7:03 am

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
It remind me my first console in NTSC, I used this concept too. But in the end, I managed to use a 44 pins CPLD to do the chip logic color phasing instead of all these ICs. It worked fine. Maybe you already saw it previously:
console1.JPG
console1.JPG (58.83 KiB) Viewed 3672 times


Mast3rbug

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

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie » Thu Jan 10, 2013 8:11 am

Yep, I remember that one. You used propagation delays through buffers in the CPLD by schematic capture. Xilinx ISE won't even let you do that these days, it will just trim the gates to remove the delays!

Brad

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug » Fri Jan 11, 2013 4:15 am

AtomicZombie wrote:Yep, I remember that one. You used propagation delays through buffers in the CPLD by schematic capture. Xilinx ISE won't even let you do that these days, it will just trim the gates to remove the delays!

Brad

In the Altera CPLD I used, there is setting for slower slew rate to increase the delay propagation. I think this was a feature for delay.

Mast3rbug

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

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie » Fri Jan 11, 2013 6:02 am

Ahh, creative use of the slew to make chroma shifts!

I was getting into a lot of video stuff with Spartan3, but once my XMega hit 57.262MHz, I went back to trusty old 8 bit power.
For chroma rotation, on the Spartan, I ran it at 57.262 and had a 4 bit counter running. I would then tap it at some point between 0 and 15 and then send out 4 bits (half the wave) to a 4 bit R2R DAC. This came very close to the actual sine wave spec for the chroma carrier, but oddly, it looked worse than a sharp square wave like we are doing now. Seems the square edge of the chroma signal gives the pixels an almost crisp transition somehow.

Do you still do any HDL design? I do enjoy it sometimes, but these damn FPGAs can be so quirky with timing and propagation when dealing with SRAM. I managed to get about 60MHz in and out of a 10ns SRAM and after that, tings start to go bad on a breadboard design. Here is a Spartan3 connected to an AVR, taking care of some memcopy operations and page swapping...

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

I think I can do this all in XMega now!
I will complete my 512K / XMega game system in the next few weeks and post my results to see how it works.

Oh, yeah, I wanted to tell you about a trick I used for ultra high res VGA from XMega. If you have not tried already, connect the CLKVOUT pin (port.7) to the LSB of your X address bus, then you can spew out pixels at FCLK speed! At only 40MHz, an XMega can generate 800x600 connected to a 10ns 512K SRAM, and get 2 full pages just by flipping bit 18 on the address.

But since you now have 2 IO pins connected to the MSB, you just change the direction regs so only one is active at a time. So in high speed horizontal draw mode, you drop the normal MSB IO line and flip on the CLKVOUT so your MSB is toggling at full clock speed. You can then just count the other bits using inc,out and end up with a pixel clock at your base frequency. I even did 1024x768 this way (32.5MHz PLLx2), but did not have enough SRAM for 2 pages!

Cheers!
Brad

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug » Sat Jan 12, 2013 12:58 am

Do you still do any HDL design? I do enjoy it sometimes, but these damn FPGAs can be so quirky with timing and propagation when dealing with SRAM. I managed to get about 60MHz in and out of a 10ns SRAM and after that, tings start to go bad on a breadboard design. Here is a Spartan3 connected to an AVR, taking care of some memcopy operations and page swapping...
I never played with HDL. Here is my program for the Color phasing on my first console: (You will understand, the picture is the code)
cpld1.JPG
cpld1.JPG (40.85 KiB) Viewed 3566 times
It was programed directly with logic gates schematics. I liked to program this way. I have made a complete computer in a logic gate simulator with machine state, 128 byte RAM, It took 22 pages of logic gate design. The mnemonic I hardcoded was ADD, SUB, JMP, CPI, BRNE BREQ, LOAD, STORE. IN, OUT. It was so nice to see it working in the simulator step by step latching the state machine for fetching instruction by the program counter from RAM to the single register, and execute the code! My first program was a blinking led, and my second was two virtual 7 segment counting from 00 to 99
Oh, yeah, I wanted to tell you about a trick I used for ultra high res VGA from XMega. If you have not tried already, connect the CLKVOUT pin (port.7) to the LSB of your X address bus, then you can spew out pixels at FCLK speed! At only 40MHz, an XMega can generate 800x600 connected to a 10ns 512K SRAM, and get 2 full pages just by flipping bit 18 on the address.

But since you now have 2 IO pins connected to the MSB, you just change the direction regs so only one is active at a time. So in high speed horizontal draw mode, you drop the normal MSB IO line and flip on the CLKVOUT so your MSB is toggling at full clock speed. You can then just count the other bits using inc,out and end up with a pixel clock at your base frequency. I even did 1024x768 this way (32.5MHz PLLx2), but did not have enough SRAM for 2 pages!
It looks really nice. But I don't understand... You drive an external counter with that pin attached to an external RAM address to bitbang the pixels? Do you have a part of a schematic for that to see what you mean?


Mast3rbug

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

Re: Atxmega NEW powerkill CONSOLE

Post by AtomicZombie » Sat Jan 12, 2013 1:28 am

Indeed, that chroma phasing method is a nice one, I have used it on FPGA as well as on real logic. I see a set of 244's, a few 7404's, and a 4067 MUX there.
Looks like your are using chroma address 15 as your greyscale. I wonder which is better address 0 or address 15. There seems to be no lack of green near the end of the phase (300 ns), so perhaps that is better.

I am actually away from my lab for the week, but I can probably explain it better. I will post some schematics and code soon as well.

Ok, so we know that the max pixel clock we can get to external SRAM is FCLK/2 by doing this...

INC ADRX
OUT PORT,ADX

So that is 2 cycles, effectively giving a pixel clock of 20 MHz if using a 40 MHz master clock. Using the 800x600 VGA standard, that is 400 pixels across at the most.

But if you use the CLKEVOUT function, you can change bit 7 of your low address bus at full speed, since it sends the 40 MHz clock out to a pin...

PORTCFG.CLKEVOUT = PORTCFG_CLKOUT_PE7_gc;
PORTE.DIR = (1<<7); // clkout;

So now, you only need to count from 0 to 127 and send the address to pins 0-6 as pin 7 is toggling at full clock speed.
You can now get 800 pixels across at 40 MHz.

This trick also works good in a sprite copy loop, where you want to move data blocks faster.

I hope that makes sense, I explain things better on paper than in words!

Brad

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug » Sat Jan 12, 2013 2:08 am

I understand. Half of the pixels are automatic, and the other half is driven by the OUT PORT. Brilliant!

About your actual console, It use only internal RAM of a Xmega384, But you talk about a 512K console too, which one is the console that you want to made at the end?

Also, are you using sprites at render time or copy to RAM with BACKUP RESTORE video Zone?

Mine use backup restore into memory, with malloc(), and it's transparent to the final user, you just use the function putpicture (picture name, X, Y) and at the end of all your putpicture code, you call ExecBuffer(); and all is updated, the page flip, even the frame per second is managed automatically.

This project is sooo fun! and it's the weekend! Code Code Code time!

EDIT: I just read your other post in "Uzebox & SRAM" This gave me some answer to my questions, I will comment on some questions too.

Mast3rbug

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

Re: Atxmega NEW powerkill CONSOLE

Post by mast3rbug » Tue Jan 22, 2013 2:16 pm

Hi.

Just a small update.

Here the scrolltest of the Turrican II Tile set. (The music is not from the console, but will be in the final release). I don't think that I will do the complete Turrican clone, the MAP is way too big. I have found the complet MAP/Tile set on internet. The final scroll will be X and Y. The tool used for tile making is made by me, about 5 years ago in VB6.




Mast3rbug

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests