I would be so happy with more flash and rom. 32kb is so damn nothing.
While a 4bit screen would be nice, I think if we could get a version of the current screen with the reset line broken out, then we could have pseudo greyscale without breaking compatibility. I seem to remember Kevin mentioning that this was the problem with the currently used screen, and the early attempts at greyscale resulted in flickering as it couldn’t be reset in hardware. I’m probably wrong, but it was something like that, it’s early, I need more coffee lol
Was also thinking, if the audio out could be broken out to pads, this could be incredibly popular with chiptune people, PWM, DAC and pretty beefy hardware in a small package could be very tempting.
It’s the Frame Synchronisation (FR) signal that needs to be broken out. From what @bateske has said so far, I believe the chances of this happening are slim to none.
Pads for audio out and solder jumpers to isolate the speaker are a definite possibility, but for anything more than that we have to keep feature creep in mind.
To put it into context, original gameboy cartridges had a minimum of 256 KB and the console itself had 8 KB work RAM and 8 KB VRAM on top of that.
4bit/16colour would be a lot of memory. 2bit/4colour is a more reasonable amount.
A 128 x 64 display with 4 bit colour (16 colours) requires 4096 bytes of RAM buffer. With 32 KB RAM total, that leaves 28 K of RAM for other stuff.
The current Arduboy uses 1 KB RAM for display buffer, leaving 1.5 KB for other stuff.
So even with a 16 colour display we still have more than 18 times more RAM for other stuff than is currently available.
I wasn’t looking at the actual spec at the top, I was assuming a minimal increase. With 32KB 4bit would definately be fine, perhaps even push to 6 bit RGB instead of 4 bit greyscale (though I suspect many people would prefer greyscale because it appears more retro).
I think ARM would be a massive upgrade over AVR.
I’ve read the instruction listings for both (a fun life I live) and ARM seems like a much better design in my opinion.
The nice thing is, the ATSAMD21G18 ARM microcontroller is actually cheaper, at about $2.80, than the Atmega32U4 AVR microcontroller, at about $3.70. (That’s in quantity 1000 from Digikey.)
Well, seeing that the SAMD21 is (I believe) confirmed as the next processor for the Arduboy, I guess we can consider this the new “Hackduboy” thread, right?
So, long live the Hackduboy (or Samduboy, or Arduboy-Z, as you wish.)
I found a good list with Micro Displays,but the resolution is too high
How much will it cost? If it is about the same price/cheaper than the arduboy, sign me up!
And about the SD card, won’t we need a special library dedicated to the Arduboy-Z? Since it uses an SD card, it would have to have an altered version of the arduboy library, right? It sounds so awesome!
Also, will we be taking suggestions for box art? I think I have a pretty neat idea
If we keep the same display and there are only minor alterations to the case, and nothing more gets added except the microSD slot, then the parts cost shouldn’t be much different than the current Arduboy.
We can still maintain a single library that works with both the Arduboy and Arduboy-Z. Any differences can be handled by conditional compiles based on the processor and board type. This is what I did with the Arduboy library that I altered for my prototype. Read the original post in this topic for more info.
Of course, sketches that take advantage of any new features, such as the SD card or features in the new processor, wouldn’t run on the original Aruduboy, but most sketches written for the Arduboy should be fairly easy to get working on the Arduboy-Z.
Theoretically the .arduboy format being worked on allows for different .hex contained in one. So it is possible to package the same game together (if cross-compiled and included) that will run on both systems.
The chip is cheaper but this new setup will need a bit more passives, which does increase the cost some, but not by much. The design will likely require a 4 layer pcb which also adds to the cost. We would want to include an SD card with games installed.
Need to check, but it’s my estimate any cost we recover from cheaper components we will end up spending on the SD card, but maybe not.
Of note on the cost savings side, I’m actually looking at a snap-together design. This will reduce the need for the screws, which are actually very cheap… But it will completely remove the need for screws on the assembly line which really speeds up production.
We will need a new mold for the front and back for this.
So, all in all I would guess the cost could more or less be kept the same. At the end of the day, the volume of units has a much greater influence on the cost of the units to produce. So keep letting us know what you would like to see in the new one!
My wishlist is as follows -
SD card - seems to be 100% in the works (great!)
Headphone jack, or at least a space to put one after purchase
SPI ‘port’, to allow external peripherals to be created.
If the same screen is being used, does that mean that we will still struggle to get grey?
Jack connectors (talking about the mini jack) are huge for this small device. Does it fit?
Look at going “Samsung headphone compatible”. Many of the Samsung phones let you plug a passive headphone adapter into the USB port. It uses “resistor programming” on the ID pin of the USB port to let the device know to cut off the USB signals and connect the audio instead. Although it does add to complexity and parts count, it avoids large items such as a jack, while staying with commonly available external adapter components.
I would like to refer to the respond from kevin
That would be really cool. Just have multiple compiled versions in a single binary.