Definitely! I recall a reference that the PDP-8 had a chess program - with only 4K of 12 bit words. That’s one example of the type of program where you might have the Arduboy idle down while the user studies the screen, with a “press A to enter your move” prompt.
While not a big issue, coming from gaming I would still prefer the primary buttons under the same pin for a single read. A button I think could be a prime candidate for interrupt support would be the start button if that still happens (guessing if we keep questioning between 6 & 7 buttons).
I certainly recall games running like this on smaller 8-bit systems, but we have both 32K of program (lots), a high clock rate (lots), and minimal RAM. Getting specialized functionality out of dedicated pins strikes me as more useful, as it lets us leverage the specialized power of the ATmega32U4. Putting all buttons on a single port would help somewhat, but that strikes me as a really steep trade-off, apparently just to save a few cycles. If the plans in the works to go to 16 MHz are realized, then we will have lots of cycles.
If all the D-pad buttons could be on one port, that may help, because those buttons are typically used in closely related ways, and possibly even as an 8-way pad with chording. Even there, though, I would question the ultimate benefit. A slower processor might show some read-to-read latency, but at the the clock speeds we’re looking at - even at 8 Mhz - the delay across reading multiple ports should be very small. My rough understanding is that direct digital reads only take one cycle per port, so reading from three ports in close succession would take less than 1/2 of one millionth of a second.
Ultimately, even keeping the RX/TX pins unused (and brought out for hacking) would seem to be to be more valuable than a single port of buttons.
A lot of older systems acted that way (and defiantly older portables like GBC/GBA, possibly GB but I never worked on it).
It’s a minor gripe but out of everything suggested it is far more relevant to what I will do or use the arduboy for anyways (which is a micro game system and nothing more).
Also a simple register read is cheap/fast but when spread across pins it will add up (if slightly) along with the fact you NEVER want to read fresh from the input and will want to use a value cashed at the start of your frame (leads to unpredictable behavior) and if the input is spread across multiple pins it will ultimately add up.
Plus I don’t expect to see people be efficient on this thing and keep to strict 8bit limits (ie variable type sizes), so that 32krom 1.5k ram (accounting for most will use the 1k vram buffer) will disappear in an instant.
Like I said, it’s a minor gripe that i’ll live with but it’s the only one really relevant to me.
I agree that aesthetically it would feel nice to have all eight buttons on one port, and access them with a single instruction. But the NES used a parallel to serial shift register that had to be clocked eight times to read in all of the buttons - and the GameBoy used a matrix of diodes that couldn’t read them all in a single instruction either:
The same goes for the I2C interface: pin 2 SDA (PD1) and pin 3 SCL (PD0).
Adds up to a few millionths of a second, yes. For button polling or timing (for a single button or combos) one port vs even as many as 8 makes no practical difference. The only big win (at all) is saving a few bytes of flash.
Details from Creator on extra buttons…
Since @bateske has now stated that an additional Start button will not be implemented, would it be a good idea to move either the A or B button to Pin 7 (PE6) or should they both remain, as I previously suggested, on pins 8, 9 or 10?
Putting each on 8, 9 or 10 means they’re both on port B, so they could both be read at the same time.
Moving one to Pin 7 would allow easily attaching it to an interrupt using the Arduino attachInterrupt() function with int 4.
Note that pins 8, 9 and 10 can also generate interrupts but writing the code to handle them is a bit more difficult since they’re not directly supported by the Arduino libraries. I suppose functions could be added to the Arduboy library to make doing it easier.
I’m digging through this today, my hope is to put all the pins on the same port so they can be read with one port read instead of the 2 it currently takes. So now I have to look if port B has 6 pins available?
Went back and reading, seems like hardware interrupts is our first priority, then keeping things like serial and i2c ports open, and try to stay away from 11,12,13,A4, A5.
Now looking at the speaker port, we have a suggestion to put that on a PWM pin
Trying to get all the buttons on one port is difficult, doesn’t offer a significant advantage, and will likely use pins that would be useful for other functions or brought out to pads for hacking and possible enhanced versions of the Arduboy.
See this post and the related discussion following it. The consensus seems to be that Pin 5 (PC6) is the best pin for the speaker. If you want to put the speaker across two pins, instead of one pin and GND, for added multi-tone mixing and volume functionality, then use Pin 12 (PD6) for the second speaker lead.
I know I’ve said that Pin 12 should be avoided, for Pro Micro compatibility, but I think the advantages of using Pin 12 for the speaker outweigh that desire.
Yeah looks like pin 5 will get it, there’s really no reason to control volume other than on/off due to the nature of the sound the piezo produces.
The multi-tone seems interesting but talking with @JO3RI we can get 4 channel sound out of the 1 pin which sound be sufficient. I’m going to put a resistor this time, and considering a transistor but the internal drive transistor has proven to work pretty well volume wise.
Hope to post a draft schematic up tonight so people can give some feedback.
Using PWM to generate multiple channels, the way @JO3RI describes, takes a lot of horsepower and code space. This would be fine for intro’s with static screens or menus, but it’s unlikely to be usable during action game play.
If you just want to generate dual-tone square wave sounds (such as for two part harmony, or a music track plus a sound effects track), then connecting the speaker across two pins to provide for mixing, allows you to do this with low overhead. Hardware wise, it only costs you one extra pin. If you don’t want to use the feature then you just have to set the second pin as an output (which could be done automatically in the Arduboy library). The overhead with this technique is low enough that it could be used during game play.
If one or both of the pins you use are PWM capable (such as the suggested pins 5 and 12) then you get the best of both worlds and can use either technique.
How does this look?
Up, Right, Down, Left Buttons = A0, A1, A2, A3
A, B Buttons = 7, 8
Speaker = 5, 12
RGB LED = 10,11,13
All the unused pins will be broken out, and I’ll try to break out as many of the used ones as well.
I thought you were seriously considering a Reset button?
We’ve got a reset button, power circuit, the oled display circuit not shown here. Just talking about pinouts right now
Not correct @MLXXXp We made a game with an intro animation, 4 channel music AND full action game play:
Agreed, the library can use more compression and better use of channels, but even than. We even had to share timers with TV-out on the Video Game Shield. So music had to been done, while vertical syncing and we didn’t have a screen buffer. So … Arduboy will have no problem managing music in full action.
Looks good to me. The RGB LED is a nice addition.
As I mentioned in the original post, breaking out the button pins would be nice to allow an external game controller, analog joysticks, etc.
Breaking out MOSI, MISO and SCK would be useful for adding other SPI devices in parallel with the display.