BrainF#ckery Devlog #2!

What’s Changed?

A LOT!
Since the last devlog, I’ve practically finished the BF -> Assembly compiler, and even used subprocess.run() to call NASM and GCC to build the script! It currently looks for a file called in.bf and then compiles it into an EXE that gets dumped straight into a build/ folder along with the out.asm and out.obj files!

How does the Compiler actually work?

Right now, all the compiler really does is go character by character in the input file, and if the character is one of the special 8, (<>+-,.[]) I just append some assembly into the out.asm file that corresponds with the instruction. For example, for + I just add inc byte [ebx] which increments the byte stored at the location the EBX register is pointing at. (EBX stores the tape pointer, and you manipulate it with < and >). The cool thing about writing the compiler like this is that it literally just ignores everything else, so I don’t have to write code to “clean” the input file of newlines, tabs, spaces, comments, ect.
Now for [ and ], they’re a bit special. The way these guys work is I have a stack and counter. Whenever I add a [ to the assembly, I first increment the counter by 1 and then push the value to the stack. Then I use fstrings to modify the assembly I’m about to add by doing this:
cmp byte [ebx], 0
jz loopEnd{bracketCounter}
Now to break this down, cmp is comparing the current cell (byte [ebx]) with 0. Then, the next instruction, jz only jumps to the given location in code if the two values compared previously are equal to eachother. The fstrings come into play because they modify this jump location to be loopEnd(whatever the counter is), and this location becomes the corrisponding ] when that instruction is read.

What’s next?

Well, firstly I need to make a bunch of QoL changes to the compiler, like allowing the user to pass custom input and output names/directories, specify whether or not to fully compile or leave it as a chunk of assembly, ect
I also want to make a slightly higher level BF-esque language, where you can do stuff like + 2, 5 to increase cell 2 by 5, if statements, batch outputting, ect, but that’s not gonna be the easiest thing…

See Ya Later!

- Elio

BrainF#ckery Devlog #1!

What is BrainF#ckery?

BrainF#ckery, or BFery for short, is a compiler for Brainf#ck! It’s written fully in python and takes BF and converts it into working assembly that you can plug into NASM and gcc to turn BF into a working executable!

But why?

Shut Up.

How will it work?

BFery will essentially just read and translate any BF directly into assembly. It’s actually really simple, since most of BF converts into a single line of assembly, like >, which moves the tape pointer up one, translates to inc rbx. That’s it! the rest are as follows:

• < -> dec rbx (dec means to decrease)
• + -> inc byte [rbx] (byte tells NASM to only write one byte of data, and the two brackets here are the equivalent of dereferencing a pointer in C.)
• - -> dec byte [rbx]
• the rest([ ] , .) I have yet to figure out…

OK Thats really all for this devlog, thanks for stoppin’ by!

• Elio

REACTOR DEVLOG #3.5!

This is a very speedy devlog, since it’s only like 30 mins of bugfixing so I can reship, but Ill give some details:
So basically, when I wrote the error handling in the last devlog, turns out I was trying to write to a dictionary (the bot’s data dictionary) without actually initializing it first, causing a silent crash.
I just did a little switcharoo to move the init statement (which was right after ) to run first and now it works fine! I also just added some more error logging with the textual notification system in case something goes wrong and bumped up the PyPi python package version to 1.0.4 instead of 1.0.3.
Also, for the shipwrights, I just want to clarify that it only loads files if they are .js or if they have no extension at all, so no .txt or any other file.

Reactor Devlog #3!

Hello guys! Ive been a little busy the past week, but I finally got around to making some progress, and so here’s what I have to show for it:

WE’RE ON PYPI!

I managed to upload Reactor to pypi under the name reactor_mindstormpro3 (Check it out here!)
It took a while to get everything set up but basically I just used hatchling to build and twine to upload, with a pyproject.toml I borrowed from some guide and modified to require some dependencies like py_mini_racer. (Hippity Hoppity Your Code Is Now My Property)

A Lot of Bug Fixing And Changes!

I fixed the following issues:

• Invalid bots that throw errors when loaded now throw an error as a push notification but doesnt crash the app.
• Made refreshing more reliable
• Moved loading bots at boot to a separate thread to not impair loading time of the app.

Reactor Devlog #2!

What changed?

A lot has happened since my last devlog! I locked in and implemented a bunch of new features, such as:

• error handling!!!
• a WORKING request system to fetch the latest reactor bots to test your bot against
• A bot selector system to add any bot in the CWD or sub-directories into the runner, so you can test your own bot!
• Better UI!!

Woah thats a lot of changes, lemme break it down…

First, the Error Handling!

This one is kinda the most self-explanitory. Basically, The mini_racer engine for python uses an old version of javascript, so some features, like table.at() isnt supported. For table.at() I just added a filler script to the front of the src that defines it, but I can’t realistically catch everything so I a segment in the loading of the bot that runs the code once and checks for a crash or parsing error from the engine and if it fails then it doesn’t import the bot into the bot table. (AI wrote the filler script, but I originally found the bug and also made the error handling section)

Secondly, The Request System!

The request system is arguably the coolest part of this project, but I feel obligated to also explain that some of the request system was assisted by AI (meaning that AI wrote code, I read it, and then reimplemented it with the same general idea) and also ai DID write the leaderboard grabber which just grabs all of the bots’ id’s that I can use to find their links and grab the src, but ONLY the leaderboard parser, not the bot page parser.
Ok, with that out of the way, how does this really work?
well basically I take and parse the current leaderboard stream at defector.hackclub.com/_app/remote/1jsclqx/leaderboardData. Then with that info, I manually take the bot IDs given with that and shove them into this template: https://defector.hackclub.com/bot/(bot ID here). That spits out an HTML page, so I use BeautifulSoup to parse it with this absolute horror of a line: BeautifulSoup(response.text, "html.parser").find_all("pre")[-1].get_text() and extract the source code, before writing them into a file in the botCache folder in the CWD. Then I load the file as normal, just like any other bot.

Thirdly, The Bot Selection System!

The bot selection system works by just replacing the normal leaderboard widget with a DirectoryTree widget and then setting it to show the current working directory, or CWD. I then use a custom sorter script to show only folders and .js files. whenever a JS script is clicked, it just imports it as a normal bot.

Finally, we have UI Improvements!

I added zebra tiling to the leaderboard to make it more readable, made buttons disable themselves during certain actions like disabling the run button when refreshing, and fixed a few little UI bugs.

What’s Next?

well after this I’m going to try to ship, with only 9 days left in Stardance. I Just need to package it with PyPi and I’m done!

Reactor Devlog 1!

Wait…. So what is Reactor?

Reactor is a tool to test bots made for Defector without having to publish your bot to the website and go through all that hassle.

What I’ve done in the first 6 hours

• Installed mini_racer for python and wrote a basic function to take a .js script and run the bot function inside it.
• Fixed a but with mini_racer lacking array.at() due to mini_racer using an outdated version of js by just defining it myself :)
• Learned the basics of Textual for making TUIs in python
• Made a cool TUI that allows you to start the reactor and then shows the statistics of the sim in a table. (see attached image)
• fixed some misc bugs

Ok, now how does it actually work?

So basically, whenever I want to to play two bots against each other, I define a new mini_racer context with a modified version of their src (changed the export default with export default", "globalThis.botFunc = because otherwise mini_racer wouldnt be able to see it, and added a polyfill to the front of the script to define table.prototype.at()) and then evaluate the bot () function for both bots and simulate a match between them! I then just made a function to loop through each possible robot matchup and run the game of 100-150 rounds, and then delegated the whole thing to a thread so the UI could still render while it runs.

So What’s next?

• Add the ability to get the bots on the leaderboard and play against them
• Make some more simple bots
• add misc features like better UI and the ability to select extra bots to add instead of just ones in the cache folder

See Ya Later!

- Elio :3

More API Docs and functions!

I improved the API docs and also added the following functions to the tile rendering system:

• CLEAR.tiles.clearTileSystem()
  • clears the initialized tile system
• CLEAR.tiles.hideTile(tx, ty, value)
  • sets the hidden value for the tile at tx, ty to value (a boolean)
• CLEAR.tiles.isHidden(tx, ty)
  • returns the hidden value for the tile at tx, ty as a boolean
• CLEAR.tiles.removeTile(tx, ty)
  • removes the tile at tx, ty from the tile system

I also added a simple check to all the CLEAR.tiles functions to make sure the tilesystem is initialized before they run to prevent errors.

BASICALLY READY TO SHIP!!!
I whipped up a quick demo that generates a 5x5 random room that you can spin around with the crank!
I also implemented some basic docs using markdown to explain the basic usage of the API! (the docs are very simple rn, but I encourage you to actually read some of the source code and modify it to suit your needs if you feel you need a special feature out of it or just want more understanding to how it works)
I just gotta make the README actually READable, Make a demo video, and clean up the documentation a little more and then profit!

PREPARING FOR FIRST SHIP!!!

I’m gonna ship the first part of CLEAR-ENGINE, the rendering engine!
After thinking about this for a while, I decided I want to ship my beautiful framework in multiple parts, with multiple stages of completion, and the first part is basically done!
The rendering engine consists of a bunch of math to render all tiles relative to eachother in a cool way to make it look 3D, complete with a simple API to interface with it and full 360 Degree rotation support!
To be fully ready for the ship, I need to do the following:

• expand the API a bit more
• make and render a couple more demo tiles
• make a simple demo project to show off the awesome functionality I made!
• make some docs

I also do currently have my character and action systems in the works, but I will remove those from the demo and will not include those in the docs for now since those are goals for the next two ships I’ll do.

“oh my god he’s actually being productive…”
- the random person in the mirror

CLEAR ENGINE Devlog #3

wait… what happened to CLEAR?
So CLEAR was going to be a turn-based strategy game based on Ready Or Not combined with Tactical Breach Wizards, but I realized two things:

1. I can’t make good art. period.
2. The scope of this project is way more than something doable in the duration remaining of Stardance.

Luckily there’s some good news!

I am a pretty skilled coder, so I decided to just take everything I have so far and turn it into a framework that anyone can use to make their cool 3D-ish turn-based games for the playdate! (I know, very mainstream right?)
so that’s the new goal:

• I need to unify all of my different APIs into one usable API
• I need to make docs 😭
• I need to add some features like

  • A working state system with a planning, action, and response phase.

  • Better art importing systems

  • An easy character making system via custom lua files

  • A demo for the ship

  • more stuff I don’t really want to do!

CLEAR Devlog #2

The Tile Rendering Engine is DONE!*

*hopefully
Now, tiles can render next to each other with no issues, and with 8 tiles in the scene while spinning it manages a SOLID 30FPS!!! The best part is, that’s with the FPS cap set to 30, so I bet I can push 40, or maybe even optimize it enough to get 50!
I also added distance sorting, so the tiles that are the farthest away from the “camera” get drawn first and so forth so that everything appears normal when overlapping.
Finally, I also completely restructured the entire game so far and moved all the tile stuff to it’s own file, to declutter my main.lua script.

CLEAR Devlog #1!

so what actually is CLEAR?

CLEAR is an isometric (ish) turn-based action strategy game that is essentially a cross between Ready Or Not and Tactical Breach Wizards (would 10/10 recommend). The game flow is something like this:

• Your turn! you can:
  • Move any of your teammates
  • Do any of your characters’ actions that you can do based on their mana and turn levels
• Then you end your turn and the enemy plays:
  • They will move, attack, and use abilities to try to defeat your team
• Repeat! (until either your team is wiped out, the objective is complete, or all enemies are defeated)

Features:

• Fog of war! You can’t see anything your characters can’t actively see.
• Multiple missions
• multiple selectable characters to build your team
• Arco inspired skill tree
• Cool 1-Bit artstyle
• Oh, and did I mention it’s (for now) EXCLUSIVELY for the https://play.date!
  Right now I have spent my time working on the rendering engine, that should be done by the next one! (optimization sucks… sigh)

Devlog #1: PROGRESS!

To sum it up: the firmware mod is almost done, and I am going to start on the homebrew menu!
since the last devlog, I went through 4 iterations on the homebrew loader design:

• It. 1: The OG design, a patched update loop that runs my homebrew before the update loop begins, with a file open func to read payloads
• It. 2: same design, but using lower-level uC-fs file IO funcs since the regular ones didnt seem to work when elevated
• It. 3: New design, this time I patched the LoadPDX() function that loads games/apps to elevate permissions if a system app was being ran (there is an unpatched exploit to install any app as a system app so this route made sense)
• It. 4: New design a function is placed at the end of the firmware that just contains a single svc #2, which is the assembly instruction that elevates your permissions and then returns, so that the caller gets elevated (this works because the CPU only will run elevation/permission change functions from firmware code, not loaded code like a game)

Iteration #4 is the current iteration and I am actively working to get it… well… working. The current issue right now is for some reason it seems to crash when I run the homebrew app, but the firmware itself is fine so I am going to try a couple of things.

WE DID IT!!! - WINDOWS BUILDING WORKS!

super quick summery:

• I added the –Name (or -n) option to specify a game name!
• I made windows building work (Duh)

How windows building works:

in a nutshell you essentially just need to zip the entire game directory with main.lua and friends into a game.love file. then you just copy paste it onto the love.exe file present in the zip downloads of love2D for windows and zip the whole thing up into a game!

ofc tho other things needed to be done like:

• figuring out where to download the love2d version from and also extracting it
• setting up the build environment
• staying sane

it works tho! maybe you could test it and then tell me why it broke because we all know it only works on my machine :)

Made a basic game.love build system!

the python script can copy your game dir, zip it, and then rename it to make a game.love file!

also:

• we now have 3 arguments!
  • -h, or –help (duh)
  • -b, or –build to signal the build target
  • -o or –output for signaling the output dir (like build/)

Devlog 0 - The Overview

Hello! Welcome to the first CMPHONE 4 devlog! It means a lot to me that you are reading this!

so what is the CMPHONE 4?

The CMPHONE 4 is a fully open source (eventually) phone powered by a RPI CM4 module. It will run a modified linux distro and will block out social media and use a SHARP MEMORY lcd to minimize addiction while still having support for all the necessities like native 4G calling/texting, Signal through an android container, and a modified discord client.

Roadmap!

• firstly I have to find all the components that I’m gonna use:
  • CM4, Duh.
  • Some 4G cellular chip W/ volte support
  • mental help
  • IP5356 for power management
  • matrix keyboard array (still need to decide the size)
  • some other small parts
• Next, I have to build it… :(
• Then once it works (hopefully) I can start the software development side!
  • Make a modified barebones linux distro that has a custom interface that shows up on the display for launching apps, managing contacts, and ofc settings
  • somehow get signal to display on a screen over I2C, possibly i gotta make a custom client or an android container :(
  • port an ARM discord client to function on the screen (maybe)

Outro

The scope of this project is HUGE and is gonna require me spending hours of time in both hardware and software development and therapy, but I feel that it is achievable.
That’s all for this one,
Elio

(the image for this devlog is just a stock CM4 module because I don’t really have anything to show rn…)

Devlog #0 - A quick Recap

This is my first devlog for PlayBrew, my Playdate Homebrew, and it is mostly focused on explaining what I have thus far.

What is PlayBrew?

Playbrew is a homebrew for the playdate game console that enables the user of the device (YOU!) to unlock your console’s true potential! You can code payloads, which are C scripts compiled into binary files, and then run them on-device with full low level firmware access (no sandboxing!!!). Possible payloads could be one that enables the bluetooth functionality, one that allows you to set a custom lock screen, and even one for game modding! (I have a whole list of cool ideas that I may share later)

The state of things

Sooo sadly right now PlayBrew is unfunctional 😭…
So far I have been able to modify the firmware to allow for ACE (arbitrary code execution (also don’t worry the games can’t access it so no worry of malware :D)) of some C code that gets compiled and appended to the firmware, but I am having issues with the filesystem and am unable to read the actual payloads. The way the arbitrary code runs is by modifying a function pointer to the main FW update loop to run my code, and then at the end of PlayBrew’s code it just returns into the FW update loop and the firmware runs as normal.

sooo now what’s next?

There’s a couple things I have planned, kinda ranked in order of importance:

• Getting the FS to work (I am making progress on that rn)
• Making the payload build system (gonna need help with that lol… I hate the C compiler)
• expanding the API before the full v1 release (I have to manually expose all of the functions from the FW since their addresses can change…)
• Get sleep (so basically I havzzzzzzzzzzzzzzzzzzzz)
• make a way to dump the unlock code (it’s your FW decryption key)
• make an installer
• don’t get DMCA takedown’ed

Sign me up!

hold up there… even If you own a playdate, there are a few different things you need to know ahead of time, and in short, you can’t install it.
this is because:

• firmware for the device (specifically the pdfw file in a PlaydateOS.pdos (which is just a zip) file) is encrypted, so you gotta get your device specific key and write or find a tool to decrypt it, and I can’t legally share one because of the really dumb law called the DMCA :(
• PlayBrew is ONLY compatable with rev. B devices (the newer ones) at this time. I don’t have a rev. A to test it on but it is possible to port it, I just can’t rn
• You need your unlock code, as required in the first point. The unlock code is a special decryption key used for decrypting FW, and it is not accessable AT ALL unless you are on a FW version below 2.5.0 (maybe 2.6.0???), in which case you can use Crank2Unlock to read your code. Otherwise you gotta wait for the exploit I be cooking (or write your own lol).

Finally, If you ever wanna install this on your device, either stay on 3.0.2 which is the latest fully-stable version, or jump to 3.1.0 when It comes out since I’m not releasing my exploit till after that so It won’t be patched :)

also here’s a pic of the current header file, its super broken (Ill star one of your repo’s if you can spot the issues!) but it used to work and it will, and really that’s all that matters.