under the hood, norns only uses a single grid command: /grid/led/level/map.
this command is only sent from the grid.refresh() lua function. it is sent once per dirty quad (8x8 led grid region) with x,y offsets set to the “local zero” for each quad.
all other lua grid API functions simply update the buffered LED state and set dirty flags for each quad.
so one thing that happens is that norns assumes all grids have 4 quads. that means after g.all(), there will always be 4 led/map commands sent on the next g.refresh(). i guess this is technically a bug, but it doesn’t have any ill effects for newer grids. my guess is that the older HW/FW doesn’t handle the extraneous quads gracefully (or simply can’t keep up with the bandwidth.)
so here is a ticket to teach the norns grid middleware to respect device size. i will also check the driver code next time i am looking in libmonome.
in the meantime, a good question would be: what happens if you send, from max, four consecutive messages like:
/monome/grid/led/level/map 0 0 [0 ... x64]
/monome/grid/led/level/map 0 64 [0 ... x64]
/monome/grid/led/level/map 64 0 [0 ... x64]
/monome/grid/led/level/map 64 64 [0 ... x64]
(apologies, i’m not sure of the real max syntax for the char lists in level/map.)