Uzebox forums has been a great resource for my game console project. I recently found this in a post in the forums:
http://www.theresistornetwork.com/2013/ ... ation.html
It documents a project that generates a VGA signal with an ATmega1284p. (I realize that nobody has been able to reliably overclock the ATmega1284p, so he must have received a magic microcontroller! I have considered using the ATmega1284p, but I've also ordered some PICs that have more RAM and I might use those instead.)
My questions relate not to overclocking but to framebuffers. In the project, he uses 12288 bytes of RAM as a framebuffer for a 128x96 VGA output, but it's only a single framebuffer. I was contemplating whether or not to use internal RAM for a framebuffer for my project, perhaps a single framebuffer with 8 bit color or a double framebuffer with 4 bit color; however, I don't have enough experience and knowledge to fully evaluate the pros and cons before proceeding. That's why I want to get your opinion.
My questions are:
1) What are the advantages and disadvantages of a single framebuffer using the microcontroller's internal RAM?
2) What are the advantages and disadvantages of a double framebuffer using the microcontroller's internal RAM?
3) Do you think using framebuffers would simplify the assembly programming for someone who isn't an assembly pro?
framebuffers with microcontrollers
Re: framebuffers with microcontrollers
1. Tareing is the main disadvantage of a single buffer. Memory conservation is its advantage.
2. No screen tareing. Double memory use.
3. No idea.
2. No screen tareing. Double memory use.
3. No idea.
Re: framebuffers with microcontrollers
I should have been more specific with my original questions. I'm trying to evaluate the pros and cons of framebuffers with respect to a graphics rendering system like the Uzebox uses which doesn't use framebuffers at all. There are actually 3 options I am considering:
1) No framebuffer (like the Uzebox)
2) single framebuffer
3) double framebuffer
It seems to me like writing assembly code to render graphics without any framebuffer at all would be much more difficult than say writing assembly code that uses a double framebuffer because timing would be less critical with a double framebuffer system due to the presence of a back buffer.
1) No framebuffer (like the Uzebox)
2) single framebuffer
3) double framebuffer
It seems to me like writing assembly code to render graphics without any framebuffer at all would be much more difficult than say writing assembly code that uses a double framebuffer because timing would be less critical with a double framebuffer system due to the presence of a back buffer.
Re: framebuffers with microcontrollers
I dont think anyone here actually tried over volting the 1284 because of the SD card interface and having to change the offical design. Not a hinderance in your case. Seems to me if you throw enough power at it, it should work like other cpus?
Frame buffers are way easier from the assembly side, but with such limited ram as 16k I dont think the resolution/color depth is real impressive for most games. Its also a lot of cycles just for pixel fill which is really the whole beauty of tiles+sprites.That said, there would be a lot of things you could do even with single frame buffer that uzebox never could. I would make some mock up screenshots using the resolution limits you are thinking and see if its something you would like. With external hardware maybe you could pull some tricks.
Frame buffers are way easier from the assembly side, but with such limited ram as 16k I dont think the resolution/color depth is real impressive for most games. Its also a lot of cycles just for pixel fill which is really the whole beauty of tiles+sprites.That said, there would be a lot of things you could do even with single frame buffer that uzebox never could. I would make some mock up screenshots using the resolution limits you are thinking and see if its something you would like. With external hardware maybe you could pull some tricks.
Re: framebuffers with microcontrollers
Yeah, 16k would mean very low resolution/few colors if a framebuffer is used, but I'm not fully committed to the ATmega1284 for this project. (It would be great if Atmel made an ATmega DIP microcontroller with 512k of flash and 128k of RAM!) If I decide to use a framebuffer, I might choose a PIC with more RAM instead of the Atmega1284, but PICs have their challenges and drawbacks. (I've never worked with PICs, but I've heard that programming a PIC in assembly is absolutely painful.)
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: framebuffers with microcontrollers
depends on the PIC.
The 8 bit PICs (16F, 12C, 10F) are painful. They are also >4x slower than an AVR clock for clock. The 32bit PICs are only PICs by name. The 32bit PICs are actually MIPS cores.
I am not sure what the big desire for DIP chips is. dead-bugging TQFPs is easy and making PCBs is even easier.
The 8 bit PICs (16F, 12C, 10F) are painful. They are also >4x slower than an AVR clock for clock. The 32bit PICs are only PICs by name. The 32bit PICs are actually MIPS cores.
I am not sure what the big desire for DIP chips is. dead-bugging TQFPs is easy and making PCBs is even easier.
Re: framebuffers with microcontrollers
The 2561 doesn't come in a pdip yet and only clocks 16MHZ. There has to be some kind of brick wall they are hitting with the current design.Vitis wrote:Yeah, 16k would mean very low resolution/few colors if a framebuffer is used, but I'm not fully committed to the ATmega1284 for this project. (It would be great if Atmel made an ATmega DIP microcontroller with 512k of flash and 128k of RAM!) If I decide to use a framebuffer, I might choose a PIC with more RAM instead of the Atmega1284, but PICs have their challenges and drawbacks. (I've never worked with PICs, but I've heard that programming a PIC in assembly is absolutely painful.)
But, I'm with you I wish atmel would make a version for us. More ram more flash and some kind of video out.
Re: framebuffers with microcontrollers
Hi Vitis,
Tile-based modes are all assembler, can get quite complex and give headaches!! To see what I mean, have a look at Uzebox video mode 3 (tile+sprites modes) vs. mode 8, a 2bpp bitmap mode with a 2.8k framebuffer. So there's no doubt, I'd start with a bitmap mode, monochrome 1bpp perhaps, you could have 320x200 in 8k. Then try simple tile based mode like Uzebox mode 1 and so on.
Tile-based modes are all assembler, can get quite complex and give headaches!! To see what I mean, have a look at Uzebox video mode 3 (tile+sprites modes) vs. mode 8, a 2bpp bitmap mode with a 2.8k framebuffer. So there's no doubt, I'd start with a bitmap mode, monochrome 1bpp perhaps, you could have 320x200 in 8k. Then try simple tile based mode like Uzebox mode 1 and so on.
Hey, made me think that I made a demo with the same image of Daft Punk from Tron and never shared. Just rediscovered it and made a separate topic for it!http://www.theresistornetwork.com/2013/ ... ation.html
Re: framebuffers with microcontrollers
Hi Uze,
I'm going to take your advice and start with a bitmap mode with a framebuffer and progress from there, but I'll probably starting off with 240x160 instead of 320x200. I'll keep you posted on my progress with this project.
I'm going to take your advice and start with a bitmap mode with a framebuffer and progress from there, but I'll probably starting off with 240x160 instead of 320x200. I'll keep you posted on my progress with this project.