Hey guys!
@adeko (from Gamebuino.com) and I have been working on the ultimate extension board for the Gamebuino: The Ninja Board
The features
- Boosts SRAM to 129 KB!
- 128x64 OLED for extra status information like texts, maps, images
- Intelligent keypad matrix for text and other input on the Gamebuino; customizable by games
- ATmega328pu coprocessor @ 8 MHZ
- Plugs right into the I2C and the SPI bus of the Gamebuino (connects to the Gamebuino's top)
- Connections for more SPI devices on the Coprocessor's bus
- Works standalone (needs 3V3 and GND)
- Leaves I2C in tact (I2C ontop of SPI)
- Blazing fast hardware SPI communication
- Fully compatible with BuinoBasic
- Updateable using a special loader on the Gamebuino: Create your custom firmware!
- Arduino library for easy integration in games
- Powered right from the Gamebuino
- Hackable (e.g. make your own TVout, serial terminal, ... with it)
Estimated pricepoint:
- Bare PCB: ?? EUR + shipping from Europe
- Full kit: around 20-30 EUR + shipping from Europe
We are already taking preorders if anybody wants one.
Sounds pretty interesting. Keep us informed ^^
With the 128x64 screen, I wonder if this could be turned into some sort of Nintendo DS or Game and Watch?
In any case, this extension would be nice to expand games further. With the combined CPU powers, could faster games be made?
Quote from: DJ Omnimaga on July 04, 2015, 12:10:40 AM
With the 128x64 screen, I wonder if this could be turned into some sort of Nintendo DS or Game and Watch?
In any case, this extension would be nice to expand games further. With the combined CPU powers, could faster games be made?
Oh yeah would be a nice idea!
The Gamebuino will have some limited control over the OLED but I can probably extend this support and add bitmaps and other stuff.
Well, I actually don't think the games would be any faster, but as soon as a game needs heavy processing power, the Ninja core (the coprocessor) can probably easily help the Gamebuino. And the Ninja core could be easily modified in software to support wifi, ethernet, bluetooth and even more interfaces.
In this way could the games even become online support with no additional load on the main game processor.
Btw. I almost finished the board. Here is a mockup:
(http://i.imgur.com/pfCqcjQ.jpg)
Yeah my idea was having the processing power split between both processors.
This looks interesting, by the way :)
Wow, looks impressive. Could this possibly be used as a companion to buinobasic allowing it to run as fast as the native c (is that even the native lang?) applications?
awesome :D very cool project! :3
Quote from: CKH4 on July 04, 2015, 01:18:42 AM
Wow, looks impressive. Could this possibly be used as a companion to buinobasic allowing it to run as fast as the native c (is that even the native lang?) applications?
C gets compiled to ASM, the native lang. If you want to run basic as fast as C, you need to compile it to asm too :P
Actually, machine code isn't ASM :P Anyway, I think CKH4 wants to know if Ninja + Gamebuino could be as fast as badly optimized C-code (translated to machine code)... But isn't BuinoBasic compiled too?
Quote from: p4nix on July 04, 2015, 11:50:36 AM
Actually, machine code isn't ASM :P Anyway, I think CKH4 wants to know if Ninja + Gamebuino could be as fast as badly optimized C-code (translated to machine code)... But isn't BuinoBasic compiled too?
The thing about BuinoBasic is, that it doesn't require reflashing the chip to run something.
The code is compiled to bytecode (similar to machine code; liks java) which is then ran in a virtual machine on the Gamebuino.
So it is not slow, but absoultely not as C (the virtual machine will be written in C).
Quote from: p4nix on July 04, 2015, 11:50:36 AM
Actually, machine code isn't ASM :P
Yeah yeah, its machine code... asm is just the readable form
Quote from: DarkestEx on July 04, 2015, 11:53:23 AM
So it is not slow, but absoultely not as C (the virtual machine will be written in C).
Comparable to that Android-bytecode?
Quote from: p4nix on July 04, 2015, 12:09:28 PM
Quote from: DarkestEx on July 04, 2015, 11:53:23 AM
So it is not slow, but absoultely not as C (the virtual machine will be written in C).
Comparable to that Android-bytecode?
Kinda comparable. But it is essentially a whole new instruction set + a new basic dialekt.
My original question is could the second processor be told to run if it is a buino basic program. Something similar to axe where you could specify FullSpeed to use both processors or not to just use the one.
Quote from: CKH4 on July 04, 2015, 02:46:14 PM
My original question is could the second processor be told to run if it is a buino basic program. Something similar to axe where you could specify FullSpeed to use both processors or not to just use the one.
Ah, I get you.
No, there is no way to sync the processors efficiently enough to get any speed boost out of it except for calculation heavy operations.
Btw, the coprocessor runs at half the speed of the main core.
EDIT: Actually I will look into this and see if I can find a way to get this done.
Could the coprocessor be used for graphics? (Adding a gpu to the game buino :w00t:)
Quote from: CKH4 on July 04, 2015, 03:58:37 PM
Could the coprocessor be used for graphics? (Adding a gpu to the game buino :w00t:)
Only for the oled on the ninja board. The coprocessor has no connection to the display on the Gamebuino and can't ever get one (hardware limitations).
Oh, do you sync between the coprocessor and the memory? It's possible that you could encode instructions but I guess it might not even be faster than doing all the calculations on the main processor. If the screen is stored in memory then it's possible you could do advanced shape calculations (ie. 3d) on the coprocessor then store the shape over the screen memory. I'm probably just throwing out garbage because I'm not familiar with the game buino but whatever.
Quote from: CKH4 on July 04, 2015, 04:31:16 PM
Oh, do you sync between the coprocessor and the memory? It's possible that you could encode instructions but I guess it might not even be faster than doing all the calculations on the main processor. If the screen is stored in memory then it's possible you could do advanced shape calculations (ie. 3d) on the coprocessor then store the shape over the screen memory. I'm probably just throwing out garbage because I'm not familiar with the game buino but whatever.
That idea is really interesting!
I would probably need to run a cs pin to the coprocessor, but the I would have access. But I would have problems with race conditions.
On the other side, we have a high-speed connection between the coprocessor and the main cpu. maybe we could use that to do stuff.
Maybe we could define the processor order at the beginning of the program so if you wanted the graphics done before the calculations you could define mP-cP or cP-mP to determine the processing order. Also I'll write two programs with fake syntax later to see if I can explain any other ideas with it.
Quote from: CKH4 on July 04, 2015, 04:51:20 PM
Maybe we could define the processor order at the beginning of the program so if you wanted the graphics done before the calculations you could define mP-cP or cP-mP to determine the processing order. Also I'll write two programs with fake syntax later to see if I can explain any other ideas with it.
Oh, thanks!
Can't wait to see it! :)
Heres the code stuff that I made up.
- means a user sub-routine
// Setup
// No preference for main math or graphics processor
mP() // sets the main processor to auto
cP() // sets the co-processor to auto, not necessary if you only want the main processor
// variable loading
x1, x2, x3, x4, y1, y2, y3, y4 = 10, 50, 10, 50, 10, 10, 50, 50
// Main loop
Repeat() // if empty defaults to quit
// rand(min,max,step size)
x1, x2, x3, x4, y1, y2, y3, y4 = 10+rand(-1,1,2), 50+rand(-1,1,2), 10+rand(-1,1,2), 50+rand(-1,1,2), 10+rand(-1,1,2), 10+rand(-1,1,2), 50+rand(-1,1,2), 50+rand(-1,1,2)
FPolygon(x1, y1, x2, y2, x3, y3, x4, y4)
ScreenUpd()
End // closes the loop
// Setup
// No preference for main math or graphics processor
mP(math) // sets the main processor to math routines
cP(graphics) // sets the co-processor to processes graphics routines
// variable loading
rotation = 0
// Main loop
Repeat() // if empty defaults to quit
rotation = rotation + 1
a = sin(rotation/10) // math handled by the main processor
b = cos(rotation/10) // math handled by the main processor
Polygon(a,b,a,-b,-a,b,-a,-b) // graphics handled by the coprocessor
ScreenUpd()
End // closes the loop
Quote from: CKH4 on July 04, 2015, 07:50:16 PM
Heres the code stuff that I made up.
- means a user sub-routine
// Setup
// No preference for main math or graphics processor
mP() // sets the main processor to auto
cP() // sets the co-processor to auto, not necessary if you only want the main processor
// variable loading
x1, x2, x3, x4, y1, y2, y3, y4 = 10, 50, 10, 50, 10, 10, 50, 50
// Main loop
Repeat() // if empty defaults to quit
// rand(min,max,step size)
x1, x2, x3, x4, y1, y2, y3, y4 = 10+rand(-1,1,2), 50+rand(-1,1,2), 10+rand(-1,1,2), 50+rand(-1,1,2), 10+rand(-1,1,2), 10+rand(-1,1,2), 50+rand(-1,1,2), 50+rand(-1,1,2)
FPolygon(x1, y1, x2, y2, x3, y3, x4, y4)
ScreenUpd()
End // closes the loop
// Setup
// No preference for main math or graphics processor
mP(math) // sets the main processor to math routines
cP(graphics) // sets the co-processor to processes graphics routines
// variable loading
rotation = 0
// Main loop
Repeat() // if empty defaults to quit
rotation = rotation + 1
a = sin(rotation/10) // math handled by the main processor
b = cos(rotation/10) // math handled by the main processor
Polygon(a,b,a,-b,-a,b,-a,-b) // graphics handled by the coprocessor
ScreenUpd()
End // closes the loop
Thank you. That looks interesting and I will absolutely look into that.