Prices are crazy right now for components so that’s why I’m waiting to do any more production.
IMHO, after solving the biggest problem that the Arduboy had (i.e. storing only one game), and all the positive feedback for the FX variant (Input Mag, Hackaday, user comments), it might be a good idea to try to support the original Arduboy for as long as possible – this little handheld still has got lots of potential, and it looked like it was gaining steam again. Is the price hike of the 32u4 connected with the global chip shortage? Maybe it could be waited out, or the chip could be emulated/replicated in some form? If there is a new Arduboy, I would love to see a device that is fully compatible with the original Arduboy (like the Game Boy Color is with the original GB).
And when it comes to a completely new homebrew handheld, I would like to see a PICO-8 device made with custom hardware the most. Some people say it might be possible to implement PICO-8 on FPGA (and someone is even looking into this brownphoton comments on How would you run a fantasy console on FPGA?). I wonder what Lexaloffle would say about a crowdfunding campaign for a PICO-8 console…
You have to realize that we had maxed it out with Evade2, which used 100% of PROGMEM and 100% of RAM.
Using a SAMD21 will allow advanced user to push it further, although, if we really are going SAMD21, I urge for a bigger display so we can extend the 32KB of RAM and 256KB of ROM (as well as the inherent 32 bit advantage and blistering fast speed) further.
By potential I meant that with the release of the FX, there are new users interested in the device. The SAMD21 is obviously more powerful.
Unfortunately this is going off topic a bit, but…
I very much agree. We haven’t even begun to make full use of the FX yet.
I think later on I’ll have a go at trying to calculate what kind of power/throughput an emulator would require in order to emulate an AVR chip.
Speed is usually the biggest issue with any emulator.
Another alternative is to write a transpiler that can convert AVR machine code to another platform’s machine code, but the thing would complicate that is the code that controls the hardware.
This is one of the reasons I think it’s important that Arduboy games are open source - reimplementing Arduboy2 and recompiling games from source is by far the simplest and easiest method for running the games on other devices.
As someone who knows a thing or two about virtual machines, I’m inclined to believe this is possible, but not necessarily practical.
It’s been done for Java bytecode with Jazelle, though admittedly not with FPGA as far as I’m aware.
“Only if I’m profiting from it” if he has any business sense.
“Sure, no problem” if he cares more about people’s enjoyment than money.
Unfortunately the biggest issues with PICO-8 will always be its licensing. It’s not licensed in an open way, so you’re at the whims of its creator. If you do anything the creator doesn’t like, you could be sued for copyright infringement.
Although as of the resolution of Google vs Oracle, in which they finally ruled that it’s possible for another implementation of an API to be considered ‘fair use’, so it may be more complicated than that.
But while that’s definitely relevant for someone reimplementing the PICO-8 API, an FGPA implementation of the bytecode might fall under different rulings because bytecode most likely isn’t judged the same as an API (though I would argue that bytecode is a protocol which must be implemented, and thus shares important characteristics with an API).
If it weren’t for the legal issues, I’d be perfectly happy to reverse engineer PICO-8 and provide alternative implementations, despite not actually being all that fond of PICO-8.
The problem with that though is that with those specs you start to compete with devices like the Pokitto. (Gamebuino is no longer an issue since they went bust.)
I think you’d need something more unique to set it out from the crowd, like an infrared transmitter or link cable to enable multiplayer games.
By the way, I just found out about FPSLIC, which is an AVR chip with FGPA capabilities and the capability to run machine code from RAM. I’ve not seen a device with that sort of arrangement before, so the possibilities are interesting.
If that were to be combined with the FX chip, it would make it possible to load functions from the FX chip into RAM and execute them, which opens up a lot of possibilities for game scripting.
Not quite … they are alive again.
Then make that two competators, and no doubt others that I’m unaware of.
Maybe we need to create a new thread with titles like “future arduboy planning” among other things.
Maybe like “[Poll] New Arduboy: AVR or ARM32?”
But from Bateske’s saying, I feel like that he don’t want to be disturbed until the price for these electronics goods return to normal prices (and availability returns to normal)
I think Arduboy’s “killer feature” is the monochrome display. I realise many people see it as detrimental to game experience and, as I am not a gamer, I concede that may be so. But we all know that the display is only part of the experience. Otherwise there would be no demand for retro gaming of any kind, with the display technology of today. So if you want to make the screen bigger, either in pixels count or area, that does not seem like a departure from what I perceive to be the key traits of an Arduboy. And for that reason, I would consider pokitto and gamebuino meta less like direct competition.
The flash cart/multi-game part seems to be a very popular feature that should probably remain in any future Arduboy.
I have had the hardware for an IR link in GAMOO since first conceived, as I think it could make Arduboy more fun and also give a real motivation boost to anyone developing their first few games in an educational setting to progress to a wireless multiplayer mode.
Anyway, back to the screen - monochrome (Edit-colours are fine as long as monochrome is the default option is in the libraries to simplify game development for beginners) and fast enough refresh rate without ghosting are my top suggestions. Size that could accommodate 128*64, even if you want a larger playing field or different orientation options is next suggested priority. Below those priorities, daylight readable would be nice but I think the OLEDS do remarkably well, all told.
Agreed!! Still remember opening the Arduboy packaging and turning it on and being absolutely entranced by the adorable monochrome OLED. It definitely makes the arduboy unique and it’s why I prefer it over my PyBadge, which is alright, but I mostly use it for NES emulation now.
(trying to remember what that get me into the rabbit hole)
I mean, everything about the device is pretty nice. Few times you see that USB connector covered in gold (even if it’s just plating). The ONE thing that get me into the rabbit hole is perhaps because there is a rabbit hole for me to get in (the fact that it’s open source and community driven)
But, ahem. We are really getting off topic.
I don’t see it as ‘detrimental’ as such. I think having too much colour availability can be a problem because it means poor quality sprites are more obvious.
However, I do think having 4-16 colours would be a better arrangement. Just as having too much colour creates problems, having too litte can also be a nuissance. I think 4-16 colours is ideal.
The original Game Boy and the GBC both had 4 colours, and th difference really shows if you try to replicate GB/GBC games for Arduboy.
16-colour palettes can be found in early computers like the Commodore 64, particularly anything using EGA. The ZX Spectrum had 15 rather than 16 for some unknown reason. Old Amstrad computers tended to have 2, 4 and 16 colour modes.
But again, the potential competition then becomes a concern.
It’s a shame there aren’t any 4-colour screens readily available. Without that, the best option is to use a full colour screen and not attempt to drive it at full colour.
Just to make a point, here’s a few areas from Pokemon Yellow:
Note that despite there only being 4 colours in use (black, white, green and blue) the amount of detail is so much more impressive. That’s due to the simple fact that having the two extra colours make it possible to express shadows and highlights whereas with black and white alone, the only way to pull that off is with skilled use of dithering.
In particular, take a really close look at the shadow by the counter in the shop:
That effect simply isn’t possible with two colours alone because it takes at least three colours to express the difference between the floor, the shadow and the object.
See also, the ‘four colour theorem’, which is vaguely related to this phenomenon:
Do you have any software/functions for sending/receiving yet?
Essentially any larger screen can do that. People often complain about the wasted space, but it doesn’t seem like that much of an issue to me, and even if it is you can just fill the background in with a decorative border, like the Super Game Boy did.
The key issue is how large the resulting image would be. E.g. putting a 128x64 image onto a 200x100 screen that’s the same size as the Arduboy’s current screen would mean the image would be a lot smaller and harder to see.
That’s the other issue with the much more powerful devices. If a device is powerful enough to emulate other old consoles, people will inevitably start to gravitate towards that, and you lose people’s interest in developing new games from scratch.
Balance is key.
Things have circled back to discussing colour versus monochrome, so it’s somewhat back on topic.
No, I was working through existing Arduboy features first. I did display, then got sound. EEPROM equivalent is next. Although I have been a bit side-tracked.
Maybe not for long!
GBA homebrew development with interesting things about the gba. includes draw functions and talk of mode 3, 4 and 5 and examples of simple draw square and what happens when you put said code in different modes and how it packs pixel data
2 bit you cant do what they did exactly if still reading from a buffer to display to screen. however if you multiplied ram by 2 you easily can pack the data with a few more if statements and multiplying by 2 the x and y in the draw function since its drawing to the buffer .if x != 0 dont multiply by 2 for x to clamp the first pixel. then reading you need another pointer if nobody made a hex interpreter to read 2 bits and say 2 is 0x02 (also useful for paking that 0x02 is edit 10… mistyped 11) but it slows things down a little. original gameboy ran at 8 mhz and gba ran at 16 mhz
for the arduboy it means using almost all ram for 2 bit and needs a new screen if you still display at 128 x 64 and have saved the extra color values in the buffer… for me this isnt a issue i also dont need the psram of a dev c esp32 board. i realized its storing the buffer as width times height bytes. gba did it with a little over 40kb ram for the double buffer and had more pixels than 160 x 120 active
Consider though that even if you break hex compatibility, it really does not take that much time to convert recompile a game to run on a new platform especially one similar like the samd21
The external memory function could also be carried over so that codebase could work, and much faster as well.
This is the beauty of open source is that it means we don’t have to be tied down to a new chip.
I mean sure, inside of a vacuum I think it’s way better to just stick with the 32u4 but if it isn’t too expensive and difficult to get already, it will be very soon. Microchip won’t discontinue it but they will make it more expensive over time.
The Samd21 that is comparable to our 32u4 should be just a bit more than a dollar, it’s closer to 2 dollars or maybe more now because of the shortage and probably also difficult to find.
But the thing about that is the price will almost certainly come down after the shortage as it’s something that more people are using instead of less. It also supports mbed, you know… if you wanted to do that.
I also really think RP2040 is great, I still want to make a replacement PCB for the micro arcade with that chip. The Open Micro Arcade, I think it could be great, especially if it could also be really cheap.
There is probably not a need to do both, but I think I’m trying to make both happen. I really want to hook up the RP2040 to the screen that is in the Micro Arcade! Haven’t had any time to develop for it.
If anyone really wants a color screen hook up an RP2040 to a 128x128 ST7735 let me know how you did it!
EEPROM is indeed a tricky one when your CPU doesn’t have any actual EEPROM.
Sod it, I’ll fork it it off tomorrow.
Very much this.
Even without the chip shortage, this is actually an unethical but relatively common business practice for microchip companies: make a chip, sell it cheap, and then crank the price up when people are dependent on it for their devices.
Not really the case, very few people are buying these, other mfg might discontinue it but they will price it to allow them to continue to produce them. This naturally encourages their customers to switch to new platforms without actually cutting them off.
It’s an old chip and not many people use it any more, lots of people use the SAMD21 and that’s why hopefully after the shortage the cost will go down even more when the supply can meet with demand.
I looked back and realised that actually quite a few older posts had already started to talk about other CPUs, so I brought them along for the ride.
Now I’m back on topic, my distraction has been GAMOO / SAMD21 Arduboy related. Much thinking and reading but I hope to actually have something to show for it soon. I’m not trying to tease but you know how often these things go where you aren’t sure if you can do something that you want to so don’t give much away until you have a little progress to show.
I was actually referring to the kind of post which followed mine - but don’t let me drag us back there!
As ever, feel free to ask if you need any help of any kind.
Especially on the software or theoretical side of things.