I was actually misquoting Wayne’s World 2: “If you book them, they will come”. I’m not so cultured that I’d reference the original!
In all honestly I haven’t seen either film (Field of Dreams or Wayne’s World),
I just like picking up useless bits of trivia,
like the fact that despite their long necks, giraffes only have 7 vertebrae,
the same number as a human.
Fun fact, the only mammals which dont have 7 are some sloths and manatees.
Surely the phrase is “If you build it, …” ?
Evidently I need to clean the fur out of my keyboard again.
Your furry? How man vertebrae does a @Pharap have?
A little more on topic has anyone looked at the Sharp Memory LCD’s?
And that question was for the @SimonMerrett’s topic that I thought I was in …
I don’t own a furry, but I do own a furry creature that thinks my keyboard is suitable for walking on.
(In fairness a portion of it probably is my own hair, I’m not exactly bald either.)
Stay away from my vertebrae collection or else…
@SimonMerrett I did find a LCD that looks pretty inexpensive compared to 2.42 OLEDs which is based on the ST7920 chip. Someone did get the arduino to print graphics to it. It’s just a matter of getting the arduboy libraries to play nice with it. Honestly I think we need some help from @Mr.Blinky who has done some awesome things with getting other displays to work with arduboy’s libraries.
Maybe there’s something of interest in these links?
Speaking of Mr.Blinky does anyone know how to flash his bootloader, Cathy3k onto a 32u4?
Sure you can find info on flashing Bootloaders here
Feel free to make another topic if you need more assistance.
Thank you! @Keyboard_Camper
If you have a usbasp icsp programmer and avrdude already installed (you should if you have the arduino ide installed) I wrote a super simple windows batch script to automatically set/verify the correct fuse bits, write the bootloader and even flash a game hex all in one go (you just plug in the usb, icsp wire, and drag the hex onto the bat file and it will handle the rest). I have it on my old laptop so if it’s something that could help you I can dig it up.
@JinxLynx daylight readability is important for me, so I probably won’t go down that way but I’m open to other LCD panels if they don’t rely on the back light to be readable…
Thanks. I had a quick look at the PDF and it’s interface is a bit different than the displays I’ve played with sofar. It doesn’t use standard SPI for serial interface. But it’s not that complicated to implement.
One important thing about (most) LCDs to remember is that the refresh rate is very low compared to OLED and fast games will be hard to play on them.
As for the bootloader @Keyboard_Camper and @sjm4306 already gave you some tips. If you have the Homemade package installed you can easily install the bootloader through the tools menu By selecting Homemade Arduboy board then your Arduino board, cathy3K and display type. You can us an USBasp, Arduino UNO or any other supported programmer by the IDE.
like @Mr.Blinky, I have used similar 128x64 graphic LCDs in the past, and would strongly advise against using them for an Arduboy build. They usually have horrible viewing angles, produce a lot of ghosting if driven more than a frame or two a second, and require a lot of pins to interface with.
A few years ago, I went through the effort of creating a shift register backpack that reduces the number of required interface pins down to 2, but that really slows down data transfer speeds and introduces some timing constraints that the code has to take into account as well. https://bitbucket.org/serisman/pcb-ks0108-128x64-glcd-backpack/src/master/
So, not very well suited for an Arduboy I’m afraid.
If you end up using the SAMD21G18a (or similar), you might just have enough RAM and CPU speed (especially if you can use a DMA channel to drive the LCD) to make one of those cheap color TFT LCD screens work out.
Something like this: https://www.aliexpress.com/item/p/32392376642.html
Edit: One challenge would be that the 128x64 resolution wouldn’t cleanly map to the 220x170 resolution. So you would either have to deal with a black border, or an un-even stretched screen.
Oh yes, I completely agree. I think the same could be said about using such an upgraded MCU (and some of the other deviations in this thread) as well, though. It doesn’t really seem like an Arduboy at that point, even though some/most Arduboy games could be back-ported to play on it.
I was simply trying to respond with another potential display option that fulfills the cheaper-than-but-as-big-as the 2.42" oled criteria. In hind-sight, because of the resolution scaling issue, the TFT display is not really a good option for back-ported Arduboy games, even though it feels like a better fit for the suggested MCU.
I guess my 2 cents are that I don’t really see a compelling reason to move up to the SAMD MCU for an Arduboy to begin with, unless the platform was expanding more towards the Meta/Pokitto territory (which doesn’t seem likely). If more RAM or flash space is the driver, there are higher-end 8-bit AVRs available that are much closer and more compatible to the 32u4 than moving all the way to 32-bit ARM. Or, just embrace the ‘cart’ SPI flash expansion that seems to be the likely future and will still allow for larger games (i.e. more levels and/or more graphics) that could still be directly backwards compatible (without the extra levels/graphics) with Arduboy’s that don’t have the extra SPI flash space. I think most games run out of flash space before RAM anyway, and it is probably usually all the assets (i.e graphics) that push the flash space so high, not so much the program code, so offloading these to the external flash makes a lot of sense and should mean larger and more complicated games are possible.
Part of that is because there isn’t enough RAM to make much use of RAM,
so people tend to shove everything into progmem.
E.g. there isn’t enough RAM to store a particularly large map, so most people put their maps in progmem and thus we don’t have many games that generate their map ‘on the fly’.
@Botisaurus’s Arduwars is an example of a game where RAM started to become an issue.
The map was/is struggling to fit in RAM.
Time and time again we see people “wasting” a lot of time trying to find more program space (and frequently RAM, as well) to get a good concept working the way they would like it to. Although this can lead to improving the skills required to work with limited resources, it can also be frustrating for beginners.
Another common complaint is the restriction of only having one game loaded at a time, requiring hooking the Arduboy up to another device to change games.
IMHO the simplicity and size (and to some extent cost) of the Arduboy are big selling points. So, other than increasing available flash and RAM, and adding an SD slot for multiple games and for things such as game levels, I think a new Arduboy should be identical to the current one. Consider that using the same case (perhaps with minor modifications), display, battery, and most other components has economic advantages for production, especially if the original Arduboy were to remain in production along side a new one.
Have you checked the price and availability of a higher-end AVR compared to SAMD or other ARM based chips with at least equivalent capability? Since most games stick to using the provided libraries for interfacing with the hardware, switching to a different processor architecture would only require a re-compile against ported libraries for the majority.
As I’ve said in the past, you have to be wary of feature creep.