Multiple Games / Side Loading

Let’s start talking about how to have multiple games on one piece of hardware. What do you think is the best way to go about this?

  • We are gonna need a bigger chip right?
  • What bigger chip can keep arduino (or arduino like) development compatibility?
  • External Memory?
  • Dual-Microcontrollers?

I would at the very least like to support having one game that can come pre-loaded on the Arduboy, and then people can do all the development and try out other games without erasing the game it came with.

In other words, if we had some kind of official game come with Arduboy… it would be sad to have to erase it and not be able to put it back on.

Let me know your suggestions, I’ve got a few ideas but time again (maybe nordic NRF51822, ARM3?) you’ve shown me you’re smarter than me on most of this stuff!

1 Like

Is this for current system or a future unit? If future unit maybe consider other chips entirely.

For this unit. Maybe add in an external flash chip? Quick google fu seems to show it’s possible.


Interesting - this echoes some themes I posted a bit back over at the Arudboy 2 topic

I didn’t get to research it completely, but it looked like the AT90USB1287 was code compatible. With its128K flash, you would have enough space to easily store a number of games, but also have a space for a memory managing boot loader - which is now going to be more like a relocating loader.

You should also be able to (as noted) use the SPI bus to talk to an SD card. Using these two features together gives you lots of space, but still says that you to run from the on-board flash. That’s likely a good thing, because I think you would take too much of a performance hit trying to run from an SD card.

External temporary storage can be reached via USB sticks, since that chip has both USB and USB OTG.

I was thinking no SD card, just keep a couple of games handy. But if you are looking for “library inside the form factor”, SD over SPI is likely your best bang for the buck.

The Gamebuino has a micoSD included in its hardware. It has a modified bootloader that supports game loading and other SD card handling capability. Perhaps the same, or similar, system could be used with a future Arduboy.

I’ve suggested using the ATSAMD21G18 ARM based Arduino Zero as a reference platform.

1 Like

Yeah for a “future” version. The goal is to support official branded material that is maybe closed source and needs to remain on the chip. And still allow people to develop.

The option would also be there to wipe out the whole setup and maybe take advantage of some parallel processing.

Would both chips need to be hooked up to the display? So you can boot into one chip and have a menu? Or would it be a switch or something?

I’m on the road right now I’ll check out what you guys posted in detail when I get back to wifi. Awesome, thanks!

The SPI flash chip or SD flash card seem to be the simplest solution but they would not help to cope with the limited amount of RAM.

The nRF51822-QFAC has 256 KB of flash and 32 KB of RAM, costs less than the ATmega32u4 and has Bluetooth 4.0. You would be able to fit on it 8 of the current games.

Furthermore, Bluetooth (or Wi-Fi with the Photon) would allow wireless reprogrammability with a phone, tablet or computer. It would even enable wireless multiplayer!

These are all awesome suggestions! I think you might shoot me when you hear what I’ve come up with. It’s for a secret project that will be launched in the next few weeks (assuming everything goes to plan). It’s a hack job, I’m not entirely proud of it but it works and unfortunately I can’t explain 100% of my logic behind it because it’s so secret!

Planning on using a 3 position power switch and 2 independent processors. There will be a 328p with some closed source software on it and then also a 32u4 that is 100% compatible with the existing Arduboy ecosystem. The power switch will independently power the respective chips. So the power sequence is OFF -> Included game -> User game.

Both chips will be connected to all the peripherals, meaning they will share the SPI bus with the display. I’m planning on bringing one signal between the chips so it can function as a chip select. And having some open solder jumpers on the back to power the chips simultaneously (if you wanted to erase the 328p and have some dual processing power).

Feel free to throw tomatoes at me for this one but I think you’ll understand once the surprise is revealed!

Thanks again for the comments because the more advanced hardware (bluetooth+sd card) is probably in the works for Arduboy 2!

5 Likes

I support your idea of an arduboy with a extra chip on which there will be a closed source game and the switch, so you can choose which one will boot.

If that extra chip is only dedicated to a single “default” game, with no possibility to re-load it with something else, then it would end up to be a waste if the user never plays that game.

However, if the extra chip could be updated with something that ends up more useful to a particular user, then it could be a nice feature.

It wouldn’t even have to be a game. For instance, @ChrisS has suggested a password manager program, that can store multiple passwords and send them, by emulating a keyboard, over the USB port. You could have such a program loaded permanently into the “extra” chip and use the main one for your games as usual.

1 Like

It will be sold branded with the exclusive content, and will also be more expensive as well. So if users want to create their own stuff we still will be offering the current design.

That said, if you crack it open and jump a couple solder bridges you’ll be able to reprogram the other chip similar to a UNO by loading the usb-serial interface from the 16u4 on there. Or if you have an external programmer as well.

So you’ll be able to get at it but not by default. For the most part my hands are tied on this as this is actually the result of a lot of legal negotiations. Stay tuned you’ll understand more when it launches.

I realize you noted that the second chip can be re-programmed. However, from they way you laid out the process, it appears that if I ever delete the closed source program, I can never reload it. That’s my first concern.

My larger concern is the financials behind this. The scenario you have laid out would almost invariably involve a payment from the closed-source software provider to the Arduboy(Dual) developer; they are effectively paying for a distribution channel. It might be that this is not the case - but then you are spinning resources from other backers to the benefit of that provider. Neither scenario starts out being a happy one for the existing backers. Given the effort needed to plan a dual processor device, it strikes me as most likely that the closed-source provider is paying.

However, this also means that when you sell an Arduboy(Dual) you are selling to two customers, not one. Only one gets the device - but both customers get a say in what the device is and how it operates.

This always concerns me, because without a high degree of financial transparency, it becomes almost impossible to know when any decision was made primarily for the benefit of the device-receiver, and when it was made primarily for the device-payer. This is especially the case when the decisions surround features NOT implemented due to concerns expressed by the device-payer.

It often looks extremely attractive to the developer, since those payments can be extremely helpful in getting the device built and out the door. But it also needs to be seen as equivalent to selling the back panel space to an advertiser.

I would really like to know more about the totality of this arrangement, since such arrangement invariably have technical design effects.

2 Likes

Your concerns and assumptions are noted. If Arduboy ever becomes a publicly traded company you may get you wish :wink:

EDIT: Let me be clear on this, we don’t have a section on the forum for speculative analyis of our operations and financials for a reason. Let’s keep things focused on hardware and software development. I don’t want to stop sharing things with everyone simply because people will pick holes in my business plan.

1 Like

Sounds like a solid plan to me. I’ve programmed an uno using another uno before so I’m at least somewhat familiar with the process if I were to ever do it. But I don’t think there is anything wrong with having a pre packaged game that is mostly permanent. You might not play it all the time, but if it’s solid you always have something to show off your cool device if you’re in the middle of a project.

I’ve made games on microcontrollers in the past, but my electrical engineering skills were seriously holding me back, the Arduboy is the perfect solution. It has been really fun to program on and I’m already excited for a possibly more powerful v2 once I’ve pushed v1 to it’s limits. :smile:

Staying focused on hardware then …

Assuming a goal of a separate processor capability, and a single closed source delivery, there are ways to make that happen while simultaneously providing flexibility beyond just those two starting points.

As you have already noted, the 328 and the 32u4 would share the peripherals. The trick is in realizing that the 328 could be isolated and placed on a small add-on card, using a “card edge with guides” socket that would be barely bigger than the 328. The small extra card would hold nothing except the 328. Then you can easily add in that extra software - but it’s also really easy for your end users and game players to remove it, replace with a different module, and then restore it later.

This adds flexibility on what the technology can deliver, since it suddenly becomes possible to provide not just one, but two or three add-on modules, if that is needed at some point in the future.

There are likely other options as well, but this is an MB1 series “card edge with guides” from SamTec.

https://wwws.samtec.com/technical-specifications/default.aspx?seriesMaster=MB1

Finally, depending on what pins are brought out to the connector, it can also serve as a high density “hacking connection”, enabling far more connect points in a more accessible manner than can be delivered just by placing pads on the board.

1 Like

That sounds like a pretty rad idea. Replaceable modules would allow for some really cool extra features. Like using the Arduboy as a controller for a robot, or a time lapse controller for a digital camera. As long as people would be able to make their own modules which doesn’t look too difficult.

So by the next few weeks, do you mean like when you are going to release the Arduboy on the store (on arduboy.com I presume) or on something completely different. Pardon me for asking a question that may or may not have been asked and answered before, but where will the online store actually be? Like on the Arduboy website or on a completely different domain. Thanks!

Right now we are looking at it being on the main domain.

I personally like the cart idea. Yet probably to simpifly things I would make them tiny and just put a flash chip on them. The only thing is we would need to have a easy way to update or reflash the chip on the cart with out loosing space to make a arduino app that simply just writes or app/game to the flash chip (loosing out on space that that would be needed by the app it self to flash the chip). I don’t see much of a point in putting a separate cpu on the cart unless there is plans to be able to change it to a much higher end chip (like an arm M0 or M3).

Something I always liked about the pokemon mini system were it’s little cartridges.

2 Likes

When CPUs were expensive compared to memory, that was always the best way to go. But now that most of the CPUs we are usually discussing here have included flash, adding external memory is both complex and expensive. Many of the most common low-power devices don’t even support external flash memory, so it has to be added on via the SPI bus.

In addition, the bandwidth needed to external memory for an 8MHz CPU is far higher than the bandwidth needed to connect to the peripherals in many cases. An external memory interface ends up being more expensive to build.

Finally, there is always some basic expense on a per-chip basis. I think you might find that the cost of a bare flash memory chip is comparable to the cost of the low-end CPU – and you still need to buy and integrate the CPU.

I completely agree that it is rather non-intuitive for the cart to be a standalone CPU. But in a world of sophisticated but low-cost SoC devices, it looks like its a better value solution than breaking out the CPU and memory.

1 Like