while i wait for my circuit boards, im stuck programming and designing the shell for mallow. this is gonna be a short update because it’s not much of an update at all, rather a todo list.

the first screenshot: my todo list
the x means it’s done already, the - means it’s halfway done, and nothing at all means that i have yet to start that. in short, i have to complete some draw functions, lua(?), flash memory, and the sd card (all in the respective order of easy to hard )

the second screenshot: ifdefs
i got inspiration from the TFT_eSPI UserSetup.h file where you uncomment the settings you want. in this case, im just gonna swap back and forth. ifdef just checks if the macro is defined, so BREADBOARD or PCB doesnt hold a value.

the third screenshot: new way of handling flash
i connected the CS pins to an mcp23017 since CS is just high or low values. little did i know, this would make using spi lines harder than it already is

flash is easy: set the mcp pin to output, add helper functions to drive the CS pin high or low, call it before every spi transaction.

sd cards on the other hand are along the same line now that i think about it. i just say it’s a pain because i need to do exactly what i did for the flash memory again, except for sd card commands. time to read through more documentation

other:
+ i think i mentioned this somewhere in my code, but it wouldnt be a shame if the sd card slot doesnt work. i just need it to read from flash memory. i can always flash the game cartridges on my breadboard system.
+ i used carbon for my fancy code screenshots (https://carbon.now.sh)

the final circuit board … for revision 2

CHANGES:
+ micro sd card wiring
+ new screen! instead of using the i80 parallel bus, im using a screen in spi mode. there’s two fpc connectors: one for the screen, one for touch controls
+ controller layout and wiring
+ new game cartridge

OTHER:
+ i made a shell for mallow to show an example of how i want the project to look fully assembled.
+ PCB ART!!!!!! check the slack art channel if you wanna see it
+ while i wait for these circuit boards to come in, im going to rewrite my program to suit the pcb wiring rather than the breadboard wiring.
+ i really hope this screen works, because if it doesnt, i dont have a backup plan
+ my mallow neocities website is under construction. i forgot i had that on my circuit board.

the debug board was… a flop

let’s get the bad out of the way first:

• the screen won’t work and the wires heat up. i don’t know why, i followed the pinout and checked for shorts on the circuit board. only the backlight goes on. i think i might try another raw screen, but plan for another failure and have a slot for a pre-built module.
• no audio. i followed the schematic of a pre-built module and, when testing, i couldn’t figure out why audio wouldn’t come out of the speaker. there are no shorts on the amp, all the pins i used to wire it up are valid. maybe it’s a programming issue, or everything i just listed into one. all i know is that i might use another pre-built module for the sake of shipping my project in time. the final version will have an embedded screen and amp, im just starting to get on a strict time frame with only a month left of this challenge.

okay, those are the failures. im happy to announce that the buttons and gpio expander work fine! i didn’t test out the flash memory yet, as well as the micro sd card slot. a few issues with the pin configuration for the controller (image 4), but so far it’s working good.

in short: im going to shoot my shot with another raw screen, but if that doesn’t work, im using a pre-built module, as well as the same for the amp. we’ll see if the micro sd card works tomorrow when i get the slot in, as well as flash.

im almost finished with the breadboard mallow configuration, it’s just the pcb that’s driving me nuts.

ps: the esp32 s3 module on the main board is a temp solution. im getting another s3 wroom 1u, the one without the antenna.

as always, thanks for reading. i hope to come back with good news next devlog

a little bit of this, a little bit of that: yet another programming update (except i locked in today)

today was a long day. after almost 4 hours, i finally got images working. a quick way to describe what i did was making a little file system to work with. i also quickly added a few lines of code that checks if a flash_update.txt file exists before flashing the program. if it doesn’t, it’ll just read from the cartridge. this is so it doesn’t wear out the flash chip and so i dont have to wait 3 minutes for it to load.

hopefully by the next time i upload another devlog, i’ll have audio and images working better. right now, i need to go into the esp-idf code and tell the code what files to flash (instead of it flashing everything inside of the images directory automatically). loading audio into flash memory will probably be interesting, i never even thought about it before.

i attached a video of carbuncle from puyo puyo dancing. the raw binary files of the frames are on my github if, for some odd reason, anyone wants them.

programming update (8/23/26): added a workflow closer to mallow revision 1.4’s

i added an sd card slot to the flash spi line for uploading lua files easier. before, it was just a small const char* script = "print(\"hi\")"; expression. it works, but it gets messy for long scripts. now, a main.lua file can be stored on the sd card and flashed to memory with ease.

rant about the sd card and sending lua files to flash

one thing that’s cool about the sd card system is that once it’s mounted, you can use plain old fopen expressions like you would on a computer. to load the lua file onto flash memory, i used fseek to get the length of the file. i then used that length to malloc that file size + 1 byte for the string null terminator. then it sends the fseek pointer back to the start of the file, iterates through each character, and loads that into a buffer. the buffer is sent to flash with my flash_write_script function from last time (just check my github page. you’ll see it at programs/08_23_26.)

something that is worth mentioning that i forgot about is that multiple devices can have the same spi line, just different CS pins. there’s 3 hosts for the esp32 s3: SPI1_HOST for internal ram and SPI2/SPI3_HOST for external devices.

another thing i love about this sd card is that i can just easily edit the main.lua file on the sd card and pop it back into the card slot. it’s way easier than reflashing the esp32 s3 just to get a new rectangle on the screen.

tomorrow im gonna work on trying to make a makeshift file system for loading up image files into flash and displaying them on screen via lua.

programming update: implemented most of the flash memory into my program, as well as some (SOME) lua.

flash memory took the longest. reading through documentation is boring but informative. i got a better understanding of how SPI works, and if not that, how the chip itself works. they have these diagrams of the MISO, MOSI, CS, and SCK lines which shows how data gets transferred. i attached a picture of one of those diagrams below.

regarding lua: it didn’t take that long because i’ve experimented with it before in mallow revision 1.4. lua is interesting since, using the lua VM in C at least, it’s stack-based, using pop and push functions. it reminds me of the time i tried learning assembly.

i need to try to push an actual file so i dont need to write down files like this…

// i'll probably need to store the length of the script somewhere.
// a script struct is probably going to be used for organization 
const char *script = "local counter = 0\n"
                     "function update() end\n"
                     "function render()\n"
                     "if counter >= 0.5 then\n"
                     "draw_rect_filled(5, 5, 310, 230, 0xf81f)\n"
                     "display_fb()\n"
                     "counter = 0\n"
                     "end\n"
                     "counter = counter + delta_time\n"
                     "end\n";

…it works for now, but it’s gonna get messy if i were to push an actual game file. i need to also figure out how to push image data to flash.

here’s an example of popping stuff in lua (from my program on 8/19/26:

    // get and call update
    lua_getglobal(L, "update");
    if (lua_isfunction(L, -1)){
      if (lua_pcall(L, 0, 0, 0) != LUA_OK){
        printf("ERR CALLING UPDATE: %s\n", lua_tostring(L, -1));
        lua_pop(L, 1);
      }
    }
    else {
      lua_pop(L, 1);
    }

when you get the function, it pushes it to the top of the stack. then it checks if what you got was a function, as well as actually calling the code inside the function. if something goes wrong, it print’s the error. either way, it pops the function from the stack since we dont need it any more for that while loop cycle. this is the same process for render.

if anyone actually decided to read through all of this, tell me about your own project. idk if im yapping into the void or not.

i cant wait for my pcbs to come in, programming gets boring sometimes 🥹

over the span of today and some of yesterday, i designed the rest of mallow revision 2.2 and a controller for it.

this board is haphazardly laid out, these aren’t the final component placements. on the back of the main board (image 2), there’s pads that i can solder to for debugging. let’s say i wired something up to the wrong pin in the schematics. i can just cut the trace and solder a wire from point A to point B to make up for that mistake. i probably could have just used a bunch of 0ohm resistors for this instead of cutting the trace, but idk cutting traces is more fun.

the controller port is really just a 2.54mm 2x10 pin female header that the male header pins connect into. i couldn’t find the footprint for what i was looking for, so i just laid out through holes, making my own footprint essentially.

long story short, this is just a debugging board and a test run

there’s gonna be two parts of this devlog: the hardware and software.

regarding the software, i just ran the draw_rect_filled function from my draw_functions.h header that i worked on yesterday and alternated the colors (see the gif)

hardware is where everything started to fall apart. the good news is that the esp32 s3 works fine: no shorts, no errors when plugging it in. the main issues are the screen and the speaker.

the screen is a cheap one i got off of aliexpress. it had an unusual pinout, or at least not the standard miso, mosi, etc that im used to. for anyone curious, it’s an i80 parallel spi interface. the pinout can be found here

for the audio module, i already know that’s not gonna work. it was only during my debugging session last night that i realized this: GPIO37 is reserved for PSRAM, and i connected my audio module to pins GPIO35-39.

what this means for future revisions: revision 2.2 is going to be a debugging board. there’s going to be a through hole for every component’s pins so i can cut traces and wire to another gpio/pin if i wanted to. that’s what i did with mallow rev 1.4.

im going to start mallow revision 2.2 tonight!

edit: the gif didnt work, just take my word for it 😭

DEVLOG 1: programming day 1

today i crossed off a little from my roadmap today:

// TODO:
// FLASH MEMORY [] - https://www.pjrc.com/teensy/W25Q128FV.pdf
// ESP_LCD [x]
// DRAW FUNCTIONS/VISUALS [-]
// LUA INTEGRATION []
// BUTTONS [x]

this is at the top of every main.c file i have on my github page.

you can find today’s work here on my github page.

some things i learned today:

• how to make header files. this one was actually kind of fun. i liked
  writing the descriptions for the functions and seeing them show up when i
  hover over the function in vscode. it’s a good way of organizing
  different functions. i was originally going to use a struct or something
  to hold all of the functions, like how a class would, but header files
  seemed like the better choice.
• how to use pointers. not fun at all, but it had to be done. learned from this video the most:
  https://www.youtube.com/watch?v=2ybLD6_2gKM&t=438s . i used that for my get_button_press function

those are the major things i learned.

tomorrow i plan on using littlefs for the flash memory so i don’t need to set raw memory addresses and break stuff.

i wrote this kind of program before, so that’s why i was able to do this on the faster side. tomorrow will probably be a much slower day since im learning something completely new (littlefs).

i really hope stardance allows me to timelapse my drawing process, that would be an easy day off…….👀

the first image shows my wiring, the second shows the program actually running. i dont know why i chose that gross color, let’s just pretend i did yellow for a star for stardance

Devlog 2: The schematic is ALMOST done!

after almost an hour and a bunch of documentation reading, im essentially done with the bare minimum schematic.

i learned what a bunch of stuff is today and its usage, like crystal oscillators and understanding flash memory better.

as far as my project goes, i need to wire the GPIO pins to the header pins, then i can add all the bells and whistles (OLED display, GPIO controlled LEDs, etc.)

StarPi power input and filtering

hello everybody, this is my first devlog for StarPi, a celestial themed raspi pico!

currently, as seen in the picture, I’ve been going off of the official RP2354B hardware guide to get a better understanding of what to do. once I’m done with the bare minimum, im going to add some extra features, like an OLED display and 3 gpio controlled LEDs.

my current goal is to hit an hour total today, with flash and the crystal oscillator fully complete.

I’m happy to call this my first hack club and stardance project!