gamebuino mega

What do you think of making a version of gamebuino with atmega2560 (in some distant future). 256 KB of flash memory and 8 KB of SRAM sounds nice.

Also is it possible to port the library for the arduino mega board, I was thinking of just remapping the screen SPI pins for the atmega 2560 in the settings part of the library.

I hesitated to use and atmega 644 or even 2560, but they are really really expensive, and I wanted Gamebuino to be as cheap as possible. I might develop a Gamebuino 2 in the future, but I think it would be better to work on expansion modules first as a lot of people request wireless communication, analog joystick, accelerometer, external RAM and sound jack.
But most the things that using an atmega2560 would improve can be added on the existing Gamebuino:
Extra RAM: external 32K SPI RAM module (ok, it's slower)
Extra ROM: use the micro SD card and bootloader
Extra I/O: use a I2C port extender
All these things will be included in the expansion module.
Does that answer your question?

if in a year(or 2) and so want to update the gamebuino
the better chip would be one of the xmega line although that means some architecture changes but the chip is cheaper then a 2560 and can be anything between 4 and 16 kb sram

furthermore it probably be best to update the screen size at that point, since what are you going to do with all that memory

both things will create some problems for backwards compatibility

adekto wrote:if in a year(or 2) and so want to update the gamebuino
the better chip would be one of the xmega line although that means some architecture changes but the chip is cheaper then a 2560 and can be anything between 4 and 16 kb sram

16kb would be amazing,

adekto wrote:furthermore it probably be best to update the screen size at that point, since what are you going to do with all that memory

Hmm, stores tons of sprites, smoother animations, 4 levels of parallax, more sounds and music, more enemies and better physics. I can think of plenty of things to do with more memory on a small screen. Right now I feel that we have a very powerful processor that we can hardly exploit to its full potential because of memory limitations, although I might change my mind when I actually get my hands on a Gamebuino. We'll see. ;)

it can do smooth ray casting (3D thing) so 4 layes paralax would be resonable
chip can handle better animations but ur limited by the lcd frame rate (and ghosting)
sound im not sure but i heurd of sd streaming to do digitized sound (also u probely want a dedicated chip if u want beter sound)
physics maybe

ether way i think there is more gain in a biger screen wen ur updating the hardware

Yes of course we can do it already, but for example, with 4 levels of parallax, you need to feed data for the screen. A full screen is about 500 bytes right now, so if you want 4 levels of parallax (assuming full screen) you need to store a lot of tiles, that fills up the 2kb memory right away, and we don't even have space for actual monsters and hero sprites, the code and variables for physics and etc.

If you up the screen resolution, say, make it 160x144 like a Gameboy, which is about 6 times bigger, you still need to fill it up with sprites, which are going to be larger and again consume all your memory very quickly, and you are left in the exact same situation.

I'd rather have a low resolution color screen instead (if they exist). That would be quite amazing. 2 bits or 4 bits Color sprites use more memory, but you can keep them small enough to keep many in memory. If we want gray right now we need to store sprites in 2 bits anyway, so the memory usage won't be that much higher.

wel ok im not looking at that big of a screen the current coment screen size that is monochrome is 128x64
so its not that drastic increase (baby steps)
ok my problem mostly is on sure u can have parralaxing but whats the point wen u can hardly see it
also u can maybe stream background textures straignt of the sd card
(in fact im looking into how to load sprites ad text in from sd for buinomon project)

Streaming from the SD card is going to involve some latency, it's good during level load but ideally, once the action start, if you want it to be smooth you will keep SD card access to a minimum... I would not do it for a texture that is drawn every frame.

Communication with the micro SD is pretty fast in fact. Moreover the expansion module will feature 32KB of SPI RAM, which could be used to store bitmaps.
We shouldn't overthink Gamebuino's limitation until we actually tried to develop games on it ^^

And if we really want more power, we can use a cortex M3+, which will provide way more RAM and Mhz for the same price. But it'll break compatibility with arduino. Or we could use the same microcontroller than in chipkit : 80 Mhz 32-bit MIPS 128K Flash, 16K SRAM http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,892,893&Prod=CHIPKIT-UNO32

And if we really, really want power, just develop games on Android hahaha

Edit: If we ever make a Gamebuino 2, we should use an OLED screen to get rid of that ghosting

I guess we should call on the all mighty Myndale to do some tests for us again, since he has an actual Gamebuino. How long does it take to load, say, 256 or 512 bytes off the SD card, and can the Gamebuino do other processing while waiting for the data, or are we forced to wait for the data once we use the function that loads data from the SD card? If that number is over 25ms, that doesn't leave us much time to compute if we run at 20 fps (50ms per frame), and that's the time normally required for processing a whole frame at 40 fps.

The ghosting is a feature... it's what makes the Gamebuino retro. =)

As for the processor, I think the current chip is fine, it is quite a welcome challenge to code for it. Some more memory would be great, but it is not required to make good games. Although, in the next iteration of the Gamebuino, going for as much memory as possible would be great.

did some digging around on colour displays and wel oled are nice but are usualy very small and bit pricy
there is ofcource the old alternative wich is celphone colour lcd's wich are biger but maybe have a to high resolution to drive
we could use a second chip as "video unit" but i dont know enugh about that

About screen, I have an old Nokia 6111 phone here that I keep so to one day canibalize the screen, a tft 256k colors 29 x 35 mm 128x160 pixels.
Maybe in a far future I could attach this screen to the gamebuino?
Anything at 168x96 would be funky if a bit bigger in size.

You'd need about 2k of ram (2016 bytes) to drive that screen with a screen buffer... and that's in monochrome.

Gee never mind then, but I will keep it around for maybe future use on something else. :)

2016 bytes? gb2 in 2016 confirmed?
bad joke aside, it means we defenetly need a beefy chip / dedicate graphics chip to do so
staying in the realm of avr the ATmega2560 can ofcource pull it off, there are many examples online
alternativly there is the ARM based stuff wich gives more power for better cost and there is an arduino port for these as shown with the due and upcoming zero

adekto wrote:2016 bytes? gb2 in 2016 confirmed?
bad joke aside, it means we defenetly need a beefy chip / dedicate graphics chip to do so
staying in the realm of avr the ATmega2560 can ofcource pull it off, there are many examples online
alternativly there is the ARM based stuff wich gives more power for better cost and there is an arduino port for these as shown with the due and upcoming zero

Adekto, I agree with you, but what we really need is both more RAM and Flash Memory.

If there's a rev. 2, I'd like to see more pins brought out along the top. I understand there's I2C, but sometimes you want to plug into something that doesn't have an I2C compatible port.

I would like to jump on the ARM bandwagon. The extra CPU power, etc would allow for a bootloader that can copy game executables from SD to RAM and skip the re-flash step. You could even add a TUI/GUI at boot to pick which game to run. I just got the STM32F429 Discovery board and I'm going to experiment with running programs from SD on there. I'd gladly help out in designing an ARM based console as a next generation device.

mr1337357 wrote:[...] You could even add a TUI/GUI at boot to pick which game to run. [...]

That is what LOADER.HEX is for, and believe me, the new one is turning out super awesome!

Sorunome wrote:

mr1337357 wrote:[...] You could even add a TUI/GUI at boot to pick which game to run. [...]

That is what LOADER.HEX is for, and believe me, the new one is turning out super awesome!

yes but its still reflashing, with arm you dont need to do that, but yea the feature is already there it just takes a bit of time ech time

what about the icsp?

mr1337357 wrote:If there's a rev. 2, I'd like to see more pins brought out along the top. I understand there's I2C, but sometimes you want to plug into something that doesn't have an I2C compatible port.

You can also use the I2C data and clock pins like regular input/ouputs

adekto wrote:what about the icsp?

You can use it but be careful because the SPI port is already used by the screen and the SD card, make sure to only enable one at a time.