Since so many people are being limited by the low memory of the Arduboy, I was wondering if there was a way to put in something to expand Arduboy’s memory capacity beyond 32 KB. Gamebuino does it with removable MicroSD cards, but could something be soldered onto the board in our case?
It’s “possible” because we have all the GPIO pins broken out on the back side but there are a number of challenges for an SPI or I2C flash chip. Number one is how to get the data onto the chip… you would have to either program the 32u4 with some uploading code or have it within your game to populate the flash.
SD card I think is the correct way to go because you can pull it out and put things inside your PC. Challenge here is that there’s really no time to make these changes for the kickstarter version. We can build some dev kits with this hardware after the kickstarter and try to see how that goes!
At this moment we are looking really hard at offering a version 1.1 after we ship all the kickstarter units that includes SD card and IR communication as well. But that probably won’t be available until summertime. We are also looking at the Nordic NRF51822 as a new processor that is a 32 bit ARM and has 256k of flash and ram, as well as bluetooth. This requires a lot more work on FCC so depending on the timeline we could either do that next or in the future.
So short answer, it’s coming but won’t be in the kickstarter version.
I would totally preorder a 1.1 dev with removable SD and wireless.
Same here, you can pretty much guarantee on my money for all arduboy gear.
Literally the only place it can fit. I wouldnt mind nuking the Arduboy logo (it can be moved) but I’m concerned about having to take a bite out of the side of the front case, it could make it a lot weaker not having that side wall.
I’ll keep working on it, but it’s gotta come later because I don’t want kickstarter people coming after me with pichforks!
the best things come to those who wait…
in terms of version 1.1 have thought about a screen with a few more pixels on it?
more memory and more pixels is all I’d be after
Is there enough space for some supporting struts to go around the SD socket? wouldn’t have to be huge, just a small strut around the 3 internal edges.
Failing that, some adhesive foam/rubber pads to sit between the socket and the case might work to shore up the case.
Just a cross-check - using the NRF51822 would mean no backwards compatibility with the kickstarter version, correct?
Much as I love more memory, extra connectivity, and better performance, I’ve always tried to engineer system balance. The Arduboy kickstarter version achieves that, I think. With an enhanced processor like the NRF51822, I would think the value of higher resolution and color on the display would be substantial. Of course, that drives up battery consumption and costs.
I’m trying to think of ways to get to a nice all-round balance, but it’s very tough. Over the years, relatively few systems I have seen manage to both nail the balance and be long-term successful, although both the GameBoy and the C64 seem to have managed it.
I think I’ve seen that SD card communication can run bare over the SPI bus. That means the display will need the CS managed as well, but after that, it’s all about physical space and memory consumption. It looks like that outline is for MicroSD, not full size - that’s a necessity!
Memory space is tougher, because anything you build in takes memory away from running applications. If you try too much, developers will just decide to not load the card libraries. If you place it in the bootloader, they may find their game cramped enough that some give up.
One tricky alternative is to allow for managed code blocks. Much like higher end systems do not require all of an application in memory at one time, allowing for code blocks to be brought in from the outside flash on demand - ideally in the background, but “loading now” is not necessarily a bad thing - would let applications grow much bigger, as long as the “code of the moment” doesn’t exceed the existing flash space. To be clear - this is tough to get right, but has a massive potential on something close to the Kickstarter hardware.
I’m just glad that there isn’t significant ghosting on the screen like there is on Gamebuino. Expandable memory in the form of MicroSD would be amazing, and a bootloader with support for more than a single file would make Arduboy a whole lot more enticing to developers. I’m content with the current pixel count, but just B&W is a bit limiting. Bateske mentioned Bluetooth support in 1.1 which would be perfect for multiplayer, but we would definitely need more memory to store the code enabling connectivity support in our projects.
I think a few more pixels and memory gets us just right in terms of balance as you mention
it’s why the original gameboy was so perfect!
I don’t think colour is necessary though
Either way there seems to be a lot of talent on here to do some really great stuff within the limits of the existing hardware
Well, the NRF51822 has an ARM Cortex-M0 core which is the same as is in the ATSAMD21G18 processor used for the Arduino Zero. Therefore, the IDE, coding and libraries could probably made to be very similar to the Kickstarter Arduboy.
Assuming that little else changes other than the processor, the Arduboy libraries and most sketches could probably be easily ported.
Of course, if you didn’t want BlueTooth, just using the same ATSAMD21G18 processor that the Zero uses would be a nice incremental upgrade and would probably result in fewer issues, at a lower cost.
In any case, if you could find the room, a Micro SD card slot could be added to the SPI bus, if desirable and the additional cost was justified.
I’ve been trying for so long to find an OLED that could handle gameboy games. 4 colors and 160x144 pixels. It doesn’t exist. The only thing that comes anywhere close is 128x128 color screen. There is a couple oled I saw that had 128x160 which is close, but not quite. And I wasn’t able to source any, just saw a specification somewhere. I’m going to try and gain direct access to some OLED factories and see what it would take to get custom ones but wow that’s going to be expensive
That’s what I’m going to try, but those changes can’t happen for kickstarter. I’ll try it after we ship
Direct compatibility will be broken, in that you won’t be able to use hex files… or anyhting that directly access the memory registers… but it’s entirely possible for us to write the library so that it would be compatible with the arduino functions and existing library functions, so it might be as easy as copy-pasting into the new platform.
The NRF51822 is still only 16mhz so not really enough throughput to run color at any significant speed. If we did color we would need something like an ARM m3 or m4 running in excess of 50mhz. Of course, this ignores the use of fancy tricks to try and run color on lower hardware, but functionally that would be the target.
Color screen chews up 3 times the power, so yeah it is a little prohibitive right now. But I am looking at a color screen, ARM m3/4 (or much greater potentially) along with maybe even wifi… for Arduboy 2. It’s very likley Arduboy 2 will ditch the credit card size, and use a pre-packaged battery like you get inside of cheap cell phones or cameras. So maybe something like the size of a passport and maybe about 12mm thick.
It would be really nice if Atmel just made a 32u4 with much more memory
As mentioned, the nordic chip has 256k flash and ram. We developed some peliminary software for the platform that allowed a wireless bootloader, giving over the air (OTA) updates. The system was designed along side SPI flash that would store multiple games there, and the software would let you switch throguh them. This bootloader/frontloader took 128k leaving 128k space for your game.
We also have spoken in depth with http://www.bluz.io/ on using their platform so the system would be fully compatible with spark ecosystem meaning IFTT commands could be integrated into the device which makes it pretty fun use as a remote or notification device.
Atmel was trying really hard to sell me on this at Makerfaire, so we are looking at it. Although as I mentioned above, as long as we build a driver with the same function names the code will transfer over assuming you aren’t addressing memory registers within your code.
While not OLED, there’s a ton of different Shenzen smart watches that have 240x240 colour LCDs, might be worth thinking about dropping OLED for LCD, the battery hit will be a pain but it might make sourcing screens easier.
I really like the low-res no-gray b&w screen. It’s a lot of fun to program with such strict limitations. I’d at least like to see a years worth of game development towards a system like this-- there’s so much that hasn’t yet been done with these limitations!
As for the flash expansion, it would be cool to be able to have larger games, or more than one game on the system, but after a certain point it becomes a sort of weird expensive open source sub-game boy. I think having one game on the arduboy makes it hella cute. “Oh yeah this red one always has ‘Danger Dork’, try out this one though!” I picture a desk drawer wih a bunch of arduboys with different games on them!
The one tiny game limitation of the original arduboy has been teaching me a lot about programming inside a low-capability system, and it’s been so much fun! If a second revision of arduboy does come out that includes another screen size, I’d like it to be considered a new platform rather than an upgrade.
Like the original gameboy, I’d like to see programmers and game designers spend years mastering the original arduboy before a sequel comes out!
That’s assuming that sketches only use the Arduboy libraries. With the Arduboy being Arduino compatible and with code development being done using the Arduino IDE, programmers are likely to use other Arduino libraries in their sketches. If one of those libraries doesn’t exist for the processor that you choose, then it might not be [quote=“bateske, post:13, topic:540”]
as easy as copy-pasting into the new platform.
By basing a new Arduboy version on the Arduino Zero’s ATSAMD21G18 processor and design (or some other “official” Arduino product), the chances of a standard Arduino library being available is greater, thus increasing the likelihood of a simple “cut and paste” to port a sketch.
Likewise, a popular Arduino compatible library developed and made available by a third party (like, for example, a fancy sound or graphics library), would be more likely to be updated, if necessary, by the author to run on newer Arduino hardware.
You want to try to avoid a situation like:
“I want to compile my Kickstarter Arduboy sketch for the new Arduboy2 but my sketch doesn’t work properly because it uses the such and such library, which doesn’t work on the NRF51822 processor because it doesn’t have the thingamajig hardware feature. If Arduboy2 had been based on the Arduino Zero then that library would work fine.”
If people are building features outside the core library, then obviously yes they wouldn’t work. I just said that in my post. It’s impossible to do something fully backwards compatible, even doing something as simple as jumping between the original 328p and the current 32u4 wasn’t exactly trivial.
Someone once said that they don’t know the secret to success, but the secret to failure is trying to please everyone.
But remaining as close as possible to an existing official Arduino product, with just added peripherals, means a larger hardware base, beyond just the Arduboy product itself. This increases the chances that an existing library will be maintained, to remain compatible with all Arduinos, and a greater amount of new compatible libraries will be created.
Many of those libraries won’t have been developed with an Arduboy in mind, but because you’re based on a standard Arduino, they will “just work”.
But you jumped from looking like an Arduino Uno to an Arduino Leonardo, instead of something different from any existing Arduino. This means you were still compatible with a large software base that is maintained and works on both, so there was less effort involved than there may have been. Not to mention your ability to use an “off the shelf” bootloader during development.