A couple of things I thought when I looked into 2 bits per pixel greyscale on the Arduboy a while ago:
Because perceived pixel intensity is the result of pixel PWM at frame rate, missing a frame is baaaad so trying to keep up rendering from the application’s main loop like most (all?) games do is fragile and probably too restrictive. With 1 bit color if you miss a frame no one notices, but when alternating ON-OFF to get shades of grey missing frames changes the shade of grey the user sees. One way to solve this is decouple + prioritise i.e. to give display rendering priority over game logic (simplest way is to use an interrupt handler).
A full screen 2 bits frame buffer is likely too large for most games (~ 500 bytes for stack and game state left). Games could reduce the portion of the screen using shades of grey to reduce frame buffer size but… if rendering is decoupled from the game loop as suggested in the previous paragraph double buffering is needed.
My guess is that greyscale applications would end up having special render loops that fill (portions of) the screen from program memory (sprites for instance) and other tricks to reduce frame buffer size, or do away with it completely and use tile + sprite based rendering loops and double buffered tile/sprite maps like in most games for personal computers from the 80s. The bottom line is that writing greyscale games with so little RAM is not as easy as filling a frame buffer and pushing it to the screen every once in a while.
Thanks @filmote! Yes, once in a while I still stick my head out . I haven’t had much spare time since April. I’m looking forward to having more time to dedicate to the Arduboy, hopefully in early 2019
So we run out of memory holding a 2 bit buffer and also practically run out of time to even transmit the full buffer at full frame speed?
Sounds like grayscale is fesable for this screen if FR is broken out, but really needs a faster processor with more memory. And sounds like something with DMA would really help too and eliminate processor hits when stepping through memory.
So something with grayscale might work on an ESP32 pretty well?
I think the CPU can keep up (but of course DMA would help). RAM is the limiting factor if you want to keep game development simple. 4kbytes is needed for a double buffered full screen 2 bits frame buffer.
You’re right. Display update would become the priority, but as you say … it would have to be interrupt driven.
Really when you think about it, a full greyscale display would be an even better option, but of course memory requirements increase with this.
I thought to myself after posting that you’d have to be leaving out SPIF flag check, but you’d still have to know when the time was right to load the next byte into SPDR. A few NOPs would do it i suppose. Must try this myself.
Cool … never thought of doing this before.
Discussion around using CL and CLS plus FR was the fact that frame rate could be increased by supplying your own clock and maximum starting frame rate is important when multiplexing display images. Reduces flicker. My hacking revealed a major difference between display boards with regard to top attainable frame rates.
One display was 168FPS and another only 128FPS. The reason - RC Oscillator variation due to manufacturing process.
Maybe that is why the manufacturer cannot be bothered to bring out the FR pin, they are thinking “just use a display with a grayscale (or 16 bit) controller”
My guess is they figured the target market for this kind of panel+controller combinations wasn’t video/entertainment (and they are mostly right). I haven’t seen a panel+controller (monochrome or color) with 3 or 4 wire interface featuring a broken out VSync.
I understand the goal here was to enable greyscale graphics but VSync and HSync signals also enable raster effects like ones available on the Uzebox which IMO are the essence of 8-bit gaming as much as chip-tunes are. For some time now I have been looking for a programable and portable retro game console which has a VSync signal but found none.
@Mr.Blinky
I just had a go at this and ended up with the same18 MCU clocks per byte ie.1.152ms . Can’t do it any faster. SPI won’t let you write any sooner.
I gotta thank you for the idea. I’ve learnt something.
The Arduboy clocks the SPI at 8Mhz but the display can handle a bit faster (I think it’s 10Mhz). It would be interesting to know whether the maximum speed is time per byte or SPI clock cycles per byte.
I’d say time per byte as there are only 8 SPI clock cycles per byte.
There is a possibility to clock a byte out in 16 MCU cycles though by using the UART in MSPIM (Master SPI Mode). But this not useful for Arduboy as it requires different pin configuration.
I’ve converted the top half off a 2 bit .bmp pic off the internet to display on the SSD1306 OLED.
Just in case you can’t make it out, it’s a parrot. The converted original pic as well.!
It’s no simple job to do. I had to create 3 images from the original .bmp file.
. I haven’t had much spare time since April. I’m looking forward to having more time to dedicate to the Arduboy, hopefully in early 2019 
