How to create custom mapper for interstate 75?

Support
1

I have a stack of 4 64x32 hub75 modules. I’ve gotten them hooked up to my Interstate 75w, and after some experimenting I’ve determined that they work hub75 module when chained together, if I set the resolution to 256x32.

However, I’d really like to run the display at 128x64, so I need to be able have the virtual pixel grid which will work with the graphics library, but have it remap the pixels to show up properly when the panels are arranged properly.

However, i’m having a hard time finding the source code where I can go to actually write a new mapper or update the existing ones. I checked github but I think i’m looking in the wrong place. I found the .py files but I didn’t find the lower level code for the software, and in another place i found the micropython code but it didn’t seem to include the support files to compile a new i75 firmware.

any suggestions?

2

Tagging alone, as I have two 64 x 32 (128x32) that I want to run as 64x64. Mine is an Interstate 75W, RP2040W onboard. Also running an older version of the Pimoroni uf2. It’s been sitting there doing its thing so I haven’t undated it in a while, no real need to.

1 Like
3

I’m still trying to figure out how to pull the repo the right way so I can recompile everything, i found the hub75.cpp file within the rp2040 section, i thought it would be under the rp2350 section but it seems like it’s a more complicated set of inheritance and dependencies than i expected.

I feel like if i do some dirty math in the hub75 set_color function that might let me do one level of remapping, but i don’t know yet if the picographics uses that at the low level.

I’m hoping one of the devs will point me towards the right function where I can intercept the processing to map the pixels a different way. I don’t need more than like 15fps for my purposes so i don’t care if it’s slow. Otherwise I’ll keep trying to make sense of the codebase.

4

If you haven’t already, posting on github may get you faster results.

5

I ended up switching to CircuitPython. The graphics library in pimoroni seems way, way better designed for humans, but the hub75 driver just wasn’t up to the task.

I ended up needing to use a new power supply too; with the micropython driver I could have all four displays running at max brightness and nothing even broke a sweat, whereas with the circuitpython hub75 driver, the display ends up pulling over 10 amps with all panels at full brightness, its also way brighter.

It also natively supported the different resolution, tiling mode, and even the panel serpentine flipping properly. Working with displayio is not a fate I’d wish on anyone, but sadly it’s the only option here.

6

I have an Adafruit Matrix Portal, it’s what I started out with way back when. Trying to display scrolling text with displayio was so frustrating that I finally just threw in the towel. Right about then the i75W came out and I switched to it. I still can’t do scrolling text with my orientation, but what I am displaying is now easy peasy.

7

@hel pointed me to this file.
interstate75/modules/rp2040/interstate75.py at f0fab5c9b04926dfa3303c66fd0b06b97f3f7e60 · pimoroni/interstate75

The following is what they use with their 128 x 64 stacked panels.

        if display == DISPLAY_INTERSTATE75_128X128:
            out_width = 256
            out_height = 64

I may have just lucked out in that my panels are half that size, 64 x 32 stacked for 64 x 64, but In there I added the following:

        if display == DISPLAY_INTERSTATE75_64X64:
            out_width = 128
            out_height = 32

And the balls demo now works (correctly) on my setup. =) I copied the interstate75.py file to my i75, and then modified it.
from interstate75 import Interstate75 now calls up the modified file that’s saved to the i75. I haven’t tried scrolling text, but that’s on my todo list for today. I’m going to try that clock example too. I’m not sure this will help you as your 4 panels are in a serpentine, but I thought I’d pass this info on anyway.

8

I got the vector_clock to run. It was very chunky graphics wise, but it ran. I also got scrolling text to display correctly on my stacked layout. Text was really chunky / blotchy, and slow, but it worked. The irony is I’ll get better readability if I redo my layout for 128x32. I’m likely just going to keep what I have for now. It’s all nicely bolted in place with a hand cut diffuser, etc.

9

for my current project, i’ve gotten it all to work fine with adafruit’s system, and it’s much brighter too (the four screens screens top out at 10amps instead of 2), which works well for this purpose.

however, i do have a second i75w, and some more screens that i can use for another project, so when i clear up my backlog a bit i’ll give that a shot. I still need to figure out how to pull the right repos to recompile the firmware.

10

I have mine setup to auto adjust the brightness based on background light intensity. I use an LTR-559 for sensing and switched to HSV instead of RGB to make it all work. Low light in a dim room, full bright with the lights on or bright sunlight.

1 Like
11

Assuming that you use the original 64x32 pixels matrices, this would be an array of 2x2 panels, which - and this is the significant part - would also require an vertical alignment (besides the horizontal one).

Back in the days I have also played around with many combinations or display chaining, and I thought I would also have aligned the matrices vertically - but obviosly my memory must be wrong…

I checked back the Picographics specification and it still reads only one possible combination of chaining displays together vertically and this is 128x128 using two vertically arranged 128x64 displays. Any other vertical arrangement should not be supported as of now.

Bildschirmfoto 2025-04-30 um 17.56.46
Bildschirmfoto 2025-04-30 um 17.56.46991×439 66.6 KB

So far nothing new for you.

So, basically the resolution which you want is, what’s supported already: 128x64
And even two of those can be vertically chained together.

Thus, the conclusion is: It’s just a logical thing rather than a physical thing, as twice of the frame buffer can be addressed already and handled by Interstate75, it should be no big deal for @Pimoroni to update the PicoGraphics library and make us all happy…

So, rather than doing some mapper coding myself to mitigate, I propose to file a feature request on the github site to have this new thing brought to life for all of us…
…because I also would like to see some new fancy resolutions, such as four 64x32 displays arranged vertically for some fancy retro gaming machines or so…

…it’s no impossible ask, as they are aware of already and open to future improvements, which they also state on the spefcification site…

Bildschirmfoto 2025-04-30 um 18.34.57

As @Gadgetoid from Pimoroni is the maintainer of the library and I know he is versatile guy, he would probably be able (willing) to easily incorporate some new fancy resolution schemes for us with ease; to realize our lovely projects.

Maybe we should collect some of our resolution wishes here and let him change this at once in May or so…

I vote for any possible combination of horizontal as well as vertical alignments of up to four displays with resolutions of 64x32 and 128x64 pixels.

This would resolve into the following:

====================[ 64x32 ]====================
1:1 = 64x32

horizontally:
2:1 = 128x32
3:1 = 192x32
4:1 = 256x32

vertically:
1:2 = 64x64
1:3 = 64x96
1:4 = 64x128

====================[ 128x64 ]====================
1:1 = 128x64

horizontally:
2:1 = 256x64
3:1 = 384x64
4:1 = 512x64

vertically:
1:2 = 128x128
1:3 = 128x192
1:4 = 128x256

1 Like
12

@hel could you probably slightly push this towards the right direction inside Pimoroni…? ;)
I think this would be easily done in a few moments (say minutes) and make a lot of us happy connecting 4 matrices vertically for some fancy LED fun…

13

I think better/custom mapping for Interstate 75 panels is on @gadgetoid 's radar, but I get the impression this would take more than a few moments to implement :) It’s discussed somewhat in this Github issue: Interstate75 - supporting more panel types · Issue #233 · pimoroni/pimoroni-pico · GitHub

What combination of panels are you trying to get working?

14

4 vertically connected panels, so either 64x128 or 128x256 (and everything in between is just a moment away)…

15

Did you try the hack that @alphanumeric posted about? Saving your own version of interstate75.py to the board and modifying this section:

    if display == DISPLAY_INTERSTATE75_128X128:
        out_width = 256
        out_height = 64

I’m not sure if that would work with multiple stacked panels though?

16

Oh, now, I missed this…

Just briefly screening the case, I don’t get the logic behind…

when i get this right, this gives the target resolution of 128x128 (I need to specify in my code while defining the screen driver/config)

if display == DISPLAY_INTERSTATE75_128X128:

and these statements tell the matrix parameters for the libraries logic…

out_width = 256
out_height = 64

I don’t get it at the first glance… how could the target resolution (128x128) be achieved by displays with 256x64, where the width is already double sized?

17

The new i75 RP2350 Starter Kit has two 128x64 Panels. It also has a custom one of stacked setup for “those” panels in the examples. The,

       if display == DISPLAY_INTERSTATE75_128X128:
            out_width = 256
            out_height = 64

Does something fancy, overriding the normal way 128 x128 would be handled.
The

        out_width = self.width
        out_height = self.height

interstate75/modules/rp2040/interstate75.py at f0fab5c9b04926dfa3303c66fd0b06b97f3f7e60 · pimoroni/interstate75