The question is, how much more power do you really need? How much extra do you want to spend? How far away from a “real” Arduino product do you want to deviate? How much time do you want to spend developing hardware and software?
The ATSAMD21 processor used by the Arduino Zero is actually cheaper than the ATmega32u4 processor in the current Arduboy. I’ve already got an Arduino Zero compatible prototype working.
I agree. I am a HUGE RPi fan and I actually got a little mad when they changed SD to Micro SD. I was crushed. All that money wasted on huge SD cards, but then I realized that Micro is so much better. It fits better, it is cheaper, and looks sleeker.
I mean compare these: Here is a regular SD card
There’s no way to implement an 1/8" audio jack. I mean, cell phone manufacturers are dropping them because they are too thick… and we are thinner than any other cell phone on the market. The external dimensions of most jacks are close to the same thickness as our entire device.
It may well be possible to implement the audio through the USB, so you could use an adapter there.
I’m also looking at ways to have some female pin connectors on the edge of the device, but it looks difficult.
Better quality sound with some hardware volume control is something I would love to do. I feel we are on the edge of getting some quality sound libraries (@JO3RI) so this would be really nice. We should be able to fit an actual speaker, but then we will need an amplifier circuit. So things get complicated and expensive quickly. But we are looking at it.
Large Internal Memory:
This is of course ideal, but any chip that starts to have significant memory (megabytes) typically is physically large with a package of high pin count (larger than the qfn44 we use now) and/or also is just way overpowered in terms of absolute pin count, processor speed, power consumption, and cost of the processor.
What would be ideal, would be a chip that allows for external code execution but that doesn’t start happening until ARM6/7 which puts us in the territory of heavier power consumption. And as others have note if we put a chip of that horsepower in the device, we are competing with actual gameboy hardware. But maybe it makes sense way down the line once we get a color screen which wont be for a year or two.
Right now looking at the SAM21D, it would give us compatibility with the Arduino Zero, it’s got more memory and faster than our current chip and it’s actually cheaper than what we are currently using.
Seeed, our manufacturer and distributor, actually just put a NRF52 module in their store:
@bateske thank you for all the insight! Can’t wait to see what y’all have planned for future versions. I still love the current Arduboy just the way it is though. The build quality is fantastic and the games are wonderful and plentiful!! ️️
Only if by size you mean resolution. There was a very famous 8 bit computer back in the day, some of us old people had them, the Commodore 64. It had two graphics modes, hi-res or multi-colour. Basically, it would half the horizontal resolution to display 16 colours without using up extra RAM.
Below is an example, with the top image being what a multi-colour image looks like and the bottom being what the RAM for the image would look like. A very acceptable compromise I think, 2bit per pixel and half resolution.
You all seem to miss the point @bateske is trying to tell you. You have to buy A LOT of screens (millions) if you want something out of the custom range. Yes all those screens are possible, but factories will not even startup production if you don’t order at least 100K. There are example screens floating around, but those have been produced in small badges, just for example purpose.
Bottom line: EVERY screen size, resolution, bpp is possible, BUT you have to order a lot before the factories want to produce. And as long as Arduboy doesn’t get an 500K arduboy order, they will NOT stock 1M screens.
If anyone points us in the direction and can get a sample of something else that is better, we are all ears!
There is a Color oled that is 160x128 pixels so that is only 16 shy of the original game boy, maybe it wouldn’t be too terrible to lose those. You could have a hardware switch to cut the top and bottom 8, or shift it 16.
But to be honest, the 128x128 color oled seems to be the most available, but it’s so expensive it probably is cost effective to have a custom LCD built. But then the power consumption is higher and the controller chips are typically much larger.
the good news is, it may not be much thicker, I’ve found some LCD screens that are basically as thin as what we are using now, but I don’t know what the cost is like.
Pocket Chip has a color screen but it’s about the worst quality LCD you can buy, and it still has a resistive touch screen. That’s 10 year old technology, but then again most people seem not to care.
Further more, you could buy an amazon fire tablet for $33 this year, and it’s got an HD IPS screen with capacitive touch screen so theoretically we should have all bought one of those if the equation was simply the cheapest product with the best screen.
Actually I like the current hardware of the Arduboy . It provides a nice playground with acceptable hardware contrains to be not overwhelmed when creating games for it.
One thing I would like to see is to get more RAM and space for content. An SD card is definetely an option and beside that we could add an SPI RAM like described here:
It would give us the chance to add more graphics/bigger levels without adding too much expensive hardware.
Another thing goes around in my head is to add a second atmega like a copro that is offloading the first one and doing any calculation on data in the spiRAM… Signalling between the two CPU’s on who is allowed to access the spiRAM is something one must solve. Also possible would be that the second CPU is reading from the SD to the spiRAM so the main CPU can just work on the data (maybe even preprocessed by the second one)… I know… sounds complicated, just wanted to drop this idea here…
SPI RAM is really slow and isn’t random access. You wouldn’t be able to use it for a larger screen buffer.
I think you’re getting overly complicated in the quest to retain the ATmega32U4 processor. The Arduino Zero compatible ATSAMD21G18 processor in my ArduboyZ prototype is cheaper and provides more RAM, flash and CPU speed.
I’ve already ported the majority of the Arduboy library to it and have a microSD slot working as well. It currently uses the same 1 bit display as the Arduboy, but the increased RAM and flash in the processor would likely be able to handle easily a larger display with more colours, if a suitable one could be found.
Yeah you are right. I just wanted to drop the idea here. Ths ATSAMD21G is a nice chip and I believe it will provide a lot of performance. I am only a bit concerned that changing the processor that early will drop a lot of old games that are optimized for the atmega. As far as I know all the optimizations done for a 8 bit CPU will be pain on a 32bit CPU. E.g. 8 bit accessess are not possible on an 32bit ARM. I think only at 4 byte boundaries and all the rest will be shifted around by the compiler when you do an unaligned access. Maybe for the cortex M0 thats different but that is what I remember from other ARM CPUs when you look at the assembler code. The C programmer will not recognize it when you give 8bit optimized c code and compile it for the ARM but the result will be not optimal.
On top, I think many games for the Arduboy will likely provide some nice libs and optimizations even with assembler for the atmega. All that will not work anymore.
Do no get me wrong, I like the ATSAMD21G18 idea. But I fear the old and yet young Arduboy platform will starve soon if we change the CPU in that direction. Or at least we will generate two different communities.
Isn’t there an atmega with more flash/ram? E.g. the ATmega1284P…
Sure they are, no problem. The compiler takes care of it.
The main problem with switching from Atmega to ARM is Atmega code written in assembler for optimisation purposes, but the ATSAMD21G is so much faster that you could probably just write the equivalent code in C++ and it would still be faster.
Keep in mind that this is Arduino Zero compatible, which is a “real” Arduino. A good portion of the standard Arduino libraries are available for it, such as the SD card library I used for testing, and more are being ported all the time.
Sure I know they are possible but look at the assembly code when e.g. accessing unaligned addresses (8 bit access to odd addresses). I do not know the M variants but ARM9 and high range Cortex assembly code will not be optimal here. Usually the code is much faster when just working with 32bit aligned addresses.
Anyway I get your points. Maybe I just like the atmega architecture
People should be avoiding assembly unless absolutely necessary. Compilers do a pretty good job of optimisation these days.
Even adding just an SD card is going to split the community somewhat. People with the new hardware are going to take advantage of it. Working to a “lowest common denominator” means new features won’t be fully utilised.
Wow I checked the datasheet of the ATSAMD21 (>1100 pages) and it quite a cute beast. It even provided a full fledged descriptor based DMA unit. That will give us an extra boost when it comes to data transfers between the display and sd card. There are so much devices that we could spare a dedicated SPI for SD and the display (not sure about the max tsck timing here but looks like the APB clock can be evenly divided from CPU clock, so maybe 48, 24, 12, … MHz are possible here).
There is even a I2S interface so a real audio codec could be connected
I wonder if all this infrastructure is already supported by the Arduino community.