We are looking at producing some developer kits that will probably be shields for the Arduino Zero until we have the bootloader/SD software figured out.
@bateske Please make they have a 6 pin easy header (3x2 pinout, etc) for use with a real reprogrammer so i can play around with the Bootloader. 
The Arduino Zero has an Atmel Embedded Debugger (EDBG) on board, so no need for an external programmer to burn the bootloader. That’s why we’re looking at using it, plus a shield, for initial prototyping and development.
Oh I thought we were talking about the CPU, not an entire board. As in a new “devkit” like the original devkit… that wouldn’t necessarily be a whole Zero - or would it at this early junction?
My suggestion to @bateske was as he said:
Meaning an actual Arduino Zero board and a custom shield. These would be provided to a limited number of developers to initially work on the bootloader. The advantage of this is you get not only the ability to burn the bootloader, but also an Atmel EDBG debugger included, at a fairly low cost.
It hasn’t been determined whether a “DevKit” in the style of the current one would be produced later for further development, or we would just go strait to low volume prototypes then production.
I’d love an opportunity to work on the bootloader. Might be nice to try a few different things and see what gels.
Should we start a whole new topic to discuss bootloader stuff?
That’s probably a good idea. There’s been some discussion on how the bootloader would handle an SD card, for loading sketches, here:
http://community.arduboy.com/t/why-a-sd-card-may-change-everything/2741
I’d love to be involved at such an early stage, but bootloaders are way out of my comfort zone. So I wont even volunteer at this point. I hope you guys get the right people involved, can’t wait to see what the Arduboy2 will bring.
Also, I assume that topic is for ‘special’ people?
“Sorry, you don’t have access to that topic!”
The topic in question was posted to the “Lounge” category. I see no reason that it should be there, so I’ve moved it to Development.
it looks beautiful
At this point, the samd21 looks like a good candidate. But, it kind of seems like the next product release won’t exactly be a sequel to the Arduboy, but actually something a little different from video games entirely. Still credit card size, still arduino compatible with buttons and an OLED… but what other platform could it be???
a Tamagotcih?
This project looks very interesting. But I hope there will be another arduboy release based on the atmega32u4 with monochrome display but with new features like differect aspect ratio with 96x96 pixels using 2-bit palette (gameboy style) out of 4-bit greyscale) and SD card support similar to gamebuino(or use easier to implement SPI FLASH memory as game carts for an even more retro-ish feel
Personally I think using beefed up MCU with color screen would be competing with pico8 running on a raspberri Pi zero with 128x128 color screen.
Interesting idea…
I’m sure I’ve commented here before but I’d like to again - based on reviewing the specs of the Gamebuino META (which I’ve helped kickstart).
The ST7735 is the chip used in the Gamebuino META. It looks like it’s going to be a great system BUT already they are trying to sell “50 fps” as the new “60 fps” (and 25 FPS will be the default on a lot of things evidently) just because of how heavy writing all that data to the screen is over SPI. They are using the 16 bit data mode… but if use the 18 bit mode for example it takes 17ms of SPI time just to push the 0.5mb of data that is one full screen. That’s 100% of available time if you wanted to run at 60 FPS… i.e., no games at 60 FPS. (just to push the RAM buffer to display, that’s not counting any game logic or rendering)
Things are slightly better with the 16 bit data mode. You can push a screen in 11.7ms. Leaving 4.96ms for rendering and game logic (if you wanted to hit 60fps).
Of course this is the reason these chips have parallel modes. If you wired up 16 lines to 2 ports on the chip you’d be able to push 16 bits at once instead of one at a time. If you could somehow mix this with DMA you might have a way to push the screen from memory to the driver without very little if any CPU involvement. Also lets not forget using parallel wiring allows you to access the VRAM on most driver chips (which are often read/write) - which creates all sorts of other possibilities - possibly removing the need to buffer a large 16/18 bit color screen in RAM.
I don’t know exactly how much faster it would be… as this point you’d have to calculate the cost of the instruction pipeline since the CPU itself might become your bottleneck. I also don’t know what the max speed could be. The docs mention switch speed for the WRX pin itself as having a 100ns write cycle with 30ns each for the high and low pulses. So if I assume that is a full flip (pushing one segment of data) that means you can push 8-18 bits per 100ns. Around 10Mhz. So if a faster ARM chip (say 48Mhz) would still hold around one instruction-ish per cycle… that should give you 38 cycles left to FETCH, set PORT, and flip WRX (if you can’t use DMA or something cool). If you have 16-bit MOV/LD instructions this seems more than feasible (esp. for 16-bit parallel, maybe even 18-bit).
So now comparing… 1 bit SPI bus at 22MHz vs a 16bit parallel bus at 10Mhz. By my rough math that would make the parallel interface over 7 times faster cutting your “transfer” time down to 2-3ms for a whole screen of data. Even 8 bit parallel should come out to around 3.5x faster.
If any of my math is confusing or doesn’t make any sense, please let me know. I think I got most of it right.
Wiring the video chip to the CPU this tightly would allow some for some seriously impressive graphics pushing even with a larger high-color LCD/OLED screen. The Gamebuino bills itself as a “hacker” device in that they want to support expansion shields, so they leave all the pins open (as much as possible)… but I don’t think that has even really been the Arduboy’s goal… it’s more of a “closed shell” device… so we shouldn’t have the same motivation to leave pins unused as they do.
So are there any good reasons NOT to do parallel wiring in the Arduboy 2?
It goes without saying that we should consider 4/8-bit parallel access for the SD card to if we had enough pins and any chipsets support that. You don’t want the SD card to become the new bottleneck. Although I know with SD cards eventually you might have to deal with the read speed of the card itself, but no room to discuss that here.
If we stick with the current 128 x 64 x 1 bit display, SPI should be plenty fast enough. It can do hundreds of FPS. Plus, with an Arduino Zero equivalent system, you could probably update the display via direct DMA from RAM. If you double buffered the screen buffer, you could DMA one buffer while the CPU is building the next one, resulting high FPS with very little CPU overhead.
If you go with a parallel interface, you would probably need to update using bit-banging, which would rule out DMA.
Again, not using SPI for an SD card would probably mean bit-banging. I envision the SD card as being just for holding multiple games, or segments of the same game. In this case, SD access speed doesn’t have to be very fast.
Sure. My whole rant was predicated on a BETTER display: color, higher-res, etc. I was only saying that IF we have a nice deep color, high-res screen that we should have the hardware wired to access it FAST.
I would be careful to design the new Arduboy with too much power. It was already mentioned that most developers are one man shows doing all itself (art, programming, music). Too much complexity scares them off or will lead to longer release times (if ever released). The more the system is limited to more likely is it to get games ready. Or even games done by single persons will look awkward compared to games designed by teams that have manpower or are even commercial. As for the current Arduboy the difference between both is not that big.
So balancing must be careful (e.g. color displays required more art skills, large memories allow more content, etc.).
It can easily happen that a too advanced Arduboy is not interesting for the regular developers which are the majority for this product. Remember the Gameboy story. It easily survived the GameGear and others although it was like a century behind competitors technology.
Amen, brother. If I wanted to write complex games I would do it on a PC …
The A and B buttons should be labeled on the next model
They are labeled
The print on the pcb is ARDUBOY where “A” and “B” are above the corresponding buttons by intention. 
This is still obscure for many users.
