And now, somehow, I’ve broken my local repo entirely. git diff shows no changes in the src directory, and I even tried recreating the build directory from scratch, but it still results in an executable that garbles the screen.
I’m able to flash other things like MMBasic so my pico isn’t dead.
Doesn’t matter whether I use the debug probe to download the elf, or bootsel to download the uf2, same garbled image that looks like it’s from one of my earlier experimental builds.
EDIT: Flashing the released version of 0.03b still works too, so it’s definitely something I’ve screwed up locally somehow.
I can’t check right now, but I probably messed up with pushing the git commits. The garbled screen happened when I would send the display data with the frambuffer pointer not initialized. Do you get anything on the debug uart (through usb-c), in particular about the sd-card? Does the emulator still react to ctrl-alt-F1 (meaning that it’s the emulator that’s not working, not the lcd/keyboard drivers) ?
Yeah, it’s on my todo list, but I am trying to understand PIO those days (with zero success so far). If you make 3-bit work, I’ll be happy to review a pull request.
PIO is on my list of things to understand as well. Seems like a slam dunk for things like VGA output… no idea if it can be used to bit-bang data through to the LCD or not.
EDIT: Also, I’m an idiot. At some point last night I figured out it was hanging trying to read the SD card, so I simply ejected it. Then, this morning, I thought “why did I leave the card out?” and clicked it back in. Derp.
git show says the last submit to the repo was last Friday, so I don’t think anything you submitted had affected me at all. Also, I hadn’t done a git pull.
With the stock image it’s hard to see judge speed when just scrolling the screen. Are there any games with full screen animation that might demonstrate it better?
Did not make a release, but I pushed a change which allows loading two disks, the one from flash which is used to boot, and an additional disk from the SD-card. This allows working with disks that do not contain an operating system, or an unsupported one.
The umac emulator does not yet support an API for ejecting and loading a different disk but there is some discussion in their issues.
The 56/7 swap doesn’t surprise me, it was a first guess. Thank you so much for figuring out we needed to write 0x2 instead of 0x1 to the pixel format register. I foolishly believed the documentation even though we know there’s crazy stuff like versions of this chip that absolutely do not support 16bpp.
Also instead of a bunch of tests (which might compile down to predicated instructions anyway) you can do eight pixels at once pretty easily:
(note the lut depends on bit order in the frame buffer, so you might need to invert entries or swap them around; you might also need buffer[I*4+3] for the first one instead of +0 again depending on bit order. I borrowed this from my font rendering code and the font I have has LSB on the right, not left, of the bitmap)
// outside of loop
uint8_t lut[4] = { 0, 7, 56, 63 };
// every eight pixels: (I'm assuming compiler is smart enough to hoist out multiply)
pix = frameBuffer[i];
buffer[i*4+0] = lut[pix & 3]; // might need +3 here, +2, +1, +0 below
buffer[i*4+1] = lut[(pix>>2) & 3];
buffer[i*4+2] = lut[(pix>>4) & 3];
buffer[i*4+3] = lut[(pix>>6) & 3];