Using SSD1327 128x128 4-bit display

Anyone else having trouble with SSD1327 128x128 4-bit screens?

I have the same module and I don’t. Which display settings do you use?

From memory I think DIY Arduino, Leonard, ssd1327 128x64 on 128x128

[edit]
Had a look…
Board: “Homemade Arduboy”
Based on: “Arduino Leonardo”
Core: “Arduboy optimized core”
Display: “SSD1327/29 (128x64 on 128x128)”
Bootloader: “original (Caterina)”
Flash select:“Pin0/D2/Rx (recommended)”
Port: “COM3 Arduino Leonardo)”

I’m using a Pro Micro if that helps.

That should be fine. Do you have installed the Arduboy and/or Arduboy2 Library manually? If you did then those will be favored on compiling and the display code will be for the SSD1306.

You can easily check for this when you have the show verbose output enabled in preferences. The log will tell you if multiple libraries are installed and which ones are used.

1 Like

Excellent! after removing arduboy and arduboy2 it works perfectly :-).

Just 2 questions…

  1. I want to make a couple of genuine greyscale games, is there a way to do this with the current setup, or is the screen inited in a monochrome way?
  2. The screen looks like it might be too big to fit inside a VMU, what do you think?
1 Like

It’s all mono. I do have ideas for 64x64 2-bit gray pixels. but that would also require all the graphic functions to be rewritten. It’s remaining on my project heap.

You’d need to remove 0,8-1.0mm at left and right of the display module. The top screw mounts of VMU probably need to be removed and you’d need to cut out a part of the top of the VMU display frame.

Here’s a test of 64x64 2-bit images on the display. The pixels looked a bit too flat to my liking (have some ideas to improve that but still didn’t get around working on that)

3 Likes

It looks good to me. I was thinking of full 128x128 but using a tilemap instead to mostly remove the need for a buffer.
Does there exist anywhere a bare bones example for using this screen at all? It doesn’t seem to be a very common screen yet.

[edit] I found some code for initing the screen and writing a buffer. It seems there is quite a jump between having the pixels off and the lowest grey value.

you’d still need a tilemap buffer and a small buffer for mixing sprites may be handy. But it shoudln’t take more then the current 1K used for framebuffer. Looking forward with what you’ll come up with.

It didn’t really look around for it. But here’s my demo code (remove .pdf extension):
slideshow.ino.pdf (71.8 KB)

Select 128x128 display option to compile it (any SSD1327 option should be fine though)


Edit 1: Oh you may wanna remark out the following line in paintScreen:
if ((y & 1) && c) c |= 0x30;

Edit 2: Add the following line after the 2nd SPDR = c; line for some scanline effect.
if (c)  c|= 0x33;

Here’s my first attempt at something. I’ve thrown in blank frames to see how well I can gauge the framerate. It doesn’t seem super fast. Not sure if there’s simply a bottle-neck or perhaps the screen not set up correctly?

https://socoder.net/uploads/124/2019/48/128x128_screen.zip

It’s hard to judge the speed from the flickery display. if you’d toggle a led every x frames you’d get a better idea on how much time it takes.

There’s a lot that can be optimized. For example:

  • Don’t use Digital Write
  • you only need to setWriteZone once (display ram will wrap automatically)
  • don’t use SPI.transfer but inline a SPI write.
  • You also don’t need to use palette you could just use colors 0…3 if you want and initialize the displays greyscale table with your required values (check the SSD1327/1329 datasheet)
1 Like

Second(ish) attempt… https://socoder.net/uploads/124/2019/49/128x128_screen_191203.rar

I’m getting 49fps without any game logic or anything. Do you think it’s possible to get any faster?

I didn’t get your new example to work correctly. But regarding your question if it can be faster, Yes it can. The time that is now wasted by the nops could be put to use and inlining the paintTile function or write a loop around it could.

A head to head SPI transfer takes 18 clock cycles. transfering a full frame (8192 bytes) @ 50fps this would consume ~46% of CPU power leaving ~54% for everything else.

instead of using standard SPI mode you can also use the UART in MSPI mode which takes 16 clock cycles per transfer (because of buffering) a 12.5% speed increment. display update @50fps would take ~41% CPU usage in that case

In comparison with the standard Arduboy, updating the display @ 60fps takes just ~6.9% CPU usage

By the way I seen this screen before it’s interesting.

I’m kind of fancying using 2-bit grays and hooking it to atmega4809 (20MHz, 48K flash, 6KB SRAM) Yeah I know could hook it to ARM or ESP32 but I’m a sucker for 8-bit :smiley:

Current target is a SAMD51 cuz that’s what adafruit wants me to use. Trying to make something that they can put in their adabox next year that guarantees 5,000 units so won’t be a problem starting production.

I changed the gfx loop to read 8 pixels at a time and send them once read, cutting out a lot of the nops.


Got from 47 to 64 FPS just doing that.

4 Likes

Doubling the vertical resolution kind of makes me think of the DS/3DS.

1 Like

This thing is expensive tho AFAIK

Adding sprites is going to be a nightmare. I already caused the frame rate to drop to 9fps and not even draw the correct sprite😜

What was the issue?