randomouscrap98 / arduboy_toolset Goto Github PK

I'm still really nervous about updates. It should be made clear that saving is recommended and to prevent users from applying updates without knowing this

In the file menu, there should be a "Patches" option that opens a submenu with a checkbox for ssd1309 and a radio for contrast. One option should be "no change". If there's no radio option for menus and it must be done manually, just allow double checking to remove and don't include the "no change"

It's just the background. It's so weird, see here:
basic_sprites.zip

I've only tried it on the basic sketch uploader. Either the hex parser is broken or... something else.

Need:

• To alert the user when no updates are found
• To apply games with no category to SOME location (or remove them from the update list? maybe that's bad)
• Maybe add more information to the loading screens?
• Try to avoid that freeze on "applying" the update? Is there any way to do that?

This may require updating the "simple" form of the progress thing to still allow information to show in the box somehow.

Warn that it's a community-made tool and I don't take responsibility for damages etc.

Also add all the licenses somewhere, including our own, if possible.

Just like --cart, there should be an option to open the arduboy file editor immediately as well. IDK if --arduboy is the best... maybe rename everything to package?

When adding data to the cart, IF there is no save already added to a slot and you're adding data, if the data has a section at the end that is precisely the size of a save (4k, 8k, etc when looking at page chunks), ask if the user would like to trim that save file out and add it as a save. Or, if a save already exists, just ask if you want to trim the save without overwriting what's there.

It'd be nice if you could export a slot as a .arduboy file, or export the whole cart as such.

So, I think large portions of the cart builder, the UI, and arduboy parsing may need to be completely changed because of this oversight.

There needs to be a way to ensure that the device for the current cart is KNOWN. Always known, like... if you load it from the device, then the device can be set. If you load a bin from the filesystem, then the device must be autodetected (if possible) or the user will have to choose.

Furthermore, parsing AND creation of arduboy files needs to be changed to support multiple binaries. There need to be systems in place to determine if a given binary is safe for use on a given device. The devices must be standardized + constants (hopefully there are standard naming conventions chosen in the arduboy community for these).

• When creating a binary, nothing needs to be changed
• When creating the .arduboy package (any time), need to indicate the system it's for. Since the ArduboyParsed format is changing anyway, just need whatever is constructing the ArduboyParsed object to put the right binaries in the right places.
• Will probably need to entirely reinvent the package creator interface, can't reuse the slot item (unless...?)
• When parsing arduboy files, need to inspect list of binaries and create proper list. Always need to check device.
• When parsing hex files into ArduboyParsed, need to auto-detect device (if possible) and if not possible, device must be set to "unknown".
• When loading .arduboy into the cart, need to load the appropriate binaries. If none are available for the current system (remember, system must ALWAYS be chosen), need to throw up appropriate errors.
• What happens when a default .hex is loaded? Assume it's correct for the system?

There's a major script I'm missing which builds fxdata from an fxdata.txt file. Need to figure that out

There's a script in Mr.Blinky's repo that shows images on the arduboy. You should do that; readd the "utilities" section and maybe have something like that there?

I don't know if this'll be useful, it's mostly for carts that are missing a save when there should be one. Just having a save in the cart should automatically patch the program, so it could "fix" development mode I think? Hopefully nobody will need more than the 4k save, I don't want to complicate that interface...

Have a very minimally featured hex display for both the header and the save file. Perhaps there's something you can import which will be a hex editor already...

Anyway, add this inspect feature to the debug menu.

There's a lot of wasted space with categories. Perhaps there could be some room made for a button for adding games to a category? It's a bit clunky to click on a category then add the game from the menu, especially because clicking on the big yellow area doesn't select the item.

Maybe also look into making ANY focus select the current item, so it's more intuitive. Might be a manual process.

• A new tab dedicated to image conversion
• A big area to display the image X:1 (needs scrollbars)
• A way to set the zoom (default 4?)
• An area for configuring tile + spacing + transparency
• Image is redrawn with bounding boxes as settings change
• A readonly box at the bottom for output, must manually convert
• Button to convert, button to convert + save (adds pragma and stdio.h)
• Modifying any image values should mark the box as "invalid" (or maybe just clear it?)
• Should maybe mark the parts of the image that will become the mask? Seems difficult...

Finding the cart builder is a bit more confusing on Mac (or maybe I'm just not used to it) and so it'd be nice to have a second way to get to the cart builder by going to the utilities tab.

Let drag+drop work for... maybe just the preview area? I was thinking the whole thing but IDK how it'll function with inputs.

Dragging and dropping is all well and good, but it'd be nice to quickly move a slot through the list. Since a lot of stuff is going to share this "remove and readd" slot code, it should definitely be made generic.

Not sure what the keyboard shortcut is. Ctrl+shift+u already moves whole categories up and down. Ah, idea:

ctrl+u/d moves up and down through categories
ctrl+shift+u/d shifts categories up and down
ctrl+shift+up/down shifts slots up and down

(nothing assigned to ctrl+up/down maybe)

If we're going to stick with the list format for a while, there should be a way to move categories around and bring all their games with them. Should be easy, since I calculate the category index values on compile and ignore whatever was there before.

Probably better to just backup program data as .hex. Just make sure you trim any unused data (not sure how to do that, is the bootloader at the end or at the beginning?)

The sketch backup function from Mr.Blinky's scripts assumes a bootloader size of 4k, meaning a backup of a larger program will not include the last 1k. This may need to be remedied after adding other functions to detect bootloader size + type

It's hard to see which slots are categories at a glance, it should be way more obvious. Maybe categories could have a spacer at the bottom that's a very ridiculous color? That might also fix the glitchy height issues if you can somehow get it to be the size of two textboxes...

Also, there should be some visual indicator if a game is FX enabled. Just check if there's FX data or save data.

May also need this for saving in other places. Not sure how difficult this is... but saving images is a nightmare because of this

Might as well have an easier (gui) way to create .arduboy files. Could be a simple form that accepts .hex files, data + save files, a title screen (I'm aware arduboy files allow more than one image), and the various bits of information that goes inside the info.json file. More complex things can be added later (like multiple images, etc).

One important feature is that the data .bin file can be scanned to see if there's potentially a dev save file at the end of it, and ask if you want to strip it out into a proper save. The form should have the usual user error stuff, like not having a .hex file, maybe parsing the .hex file to see if it's valid, auto conversion of images to the proper 1 bit format and size, maybe an auto-generation feature for the title screen, etc. For now, I want to only support a subset of the fields, namely the ones that go into the cart file.

Kevin had issues in stream with weird c++ errors around "clickable label". Wonder if it's new, clickable label IS new. It said something about "deleted": https://clips.twitch.tv/WonderfulCulturedCaterpillarAMPEnergy-UZuxAMkrf7qPUeq7

Sketch analysis now does a rudimentary test for fx, mini, or plain arduboy. It might not be entirely trustworthy, but let's assume it is. Sketch analysis runs against raw bytes, so it will work on the bootloader too.

Create a function which reads the correct amount of data out of the bootloader (4kb for older, 3kb for V > 13 (?)) and returns the bootloader itself. Perhaps there's a function in mr.blinky's scripts, otherwise read the bootloader instructions.

Once you have that function, create a wrapper function (perhaps in shortcuts? idk) which will detect what device is connected to a port. Later, use this to improve the entire toolset (not yet though, want to test it in the field)

I don't see any way to mark a screenshot as a title image, so I'm going to assume anything called "title.png" is the title. What I think should happen is:

• If you find a .png file and there's no image (and it's not banner.png), set it as the image
• If you find a title.png, always set it as the image regardless if it has been set before
  This should still allow us to do a single pass on the zip and get an image, but prefer the title.png

To indicate everything will be overwritten

When exporting image to .h, have option to choose between header guard or pragma. Or... just generate the header guard? Not sure yet, does anyone actually prefer the pragma?

See: https://community.arduboy.com/t/arduboy-toolset/11227/37

I'll add more information as it comes. Might have to inspect the flashcart that was built.

The UI has changed sufficiently enough that all new screenshots are in order I think

If you create a game first, then create a category, the menu seems to want to squish everything down to the last added size. Maybe... not sure. Definitely a bug regardless

The screenshots can live in appresources, then you can link them with raw links (I hope). Make sure to name them uniquely and descriptively.

Even though the image appears transparent, the mask is always 0xFF

There are certain oft-used drags which could be made easier. Right now, each file is treated as an individual slot, so you can't for instance drag a .hex and a .bin into the cart builder and expect the .bin to work. However, I could detect if "data" or "save" is in the .bin file, and if the only dragged files are a single .hex file and one or both of those bin files, I could put them all together into a single slot.

But this would require users to name their files appropriately, as there's no good way to tell if a file should be a save file or a data file (at least, not without guessing, which might be bad).

Not sure what the keyboard shortcut should be, maybe ctrl+up or down? I kinda wanted to use that to move individual slots up and down, maybe reserve that for ctrl+shift+up? Those two might not make sense put together like that though.

As the title says. If python has function documentation usable in intellisense, do that too.

Should be pretty simple; on load, see if those 5 fields we removed exist and simply add them as contributors

I'll have to look into existing tools and what's even available out there and familiarize myself with the arduboy libraries for sound

Mr.Blinky recently added a commit which fixes a "last page" fill in the fx writer and which has some kind of contrast patch: MrBlinky/Arduboy-Python-Utilities@e9f8e86

Just like the cart builder, there should probably be a section in the main window to indicate the last thing you did

I find myself having to set that frequently

Since you removed the bootloader from the update list, it is no longer linked against missing data in the category

It'd be cool if there were some quick way to pull all the fx saves off (maybe even including the dev save at the end?). I don't know what people would do with them, it might be difficult to automatically reapply them later, but they could definitely manually apply them.

I'm thinking I could have a command that parses a bin file into an extremely simple sqlite database. The user could then use their own commands to modify the database, then use the tools to recompile the database into a bin. Maybe there should be a shortcut step too that somehow updates games on the cart? Seems difficult, the sqlite thing might be easier.

Take a look at the .csv outputs from the actual cart builder (http://www.bloggingadeadhorse.com/cart/Cart.html) and figure out a good format for some tables in SQLite. It might be as easy as just two tables: one for categories and one for programs. There should be fields to store blobs for the images and the flashable data, whatever format you decide to store it in (is there a conversion from bin to hex? If stored as bin, you'll need to add the ability to flash raw bin to arduboy sketch area). Remember, this isn't meant to be a replacement for the official cart format, and isn't meant to go on the web, so you don't need anything fancy. But make sure it COULD be extended in the future just in case.

After creating the format, consider looking at the flashcart decompiler from Mr.Blinky and seeing how difficult it would be to have it decompile to sqlite data instead. Probably simple... I hope.

When connecting to my arduboy mini for upload/backup/etc, the device shows as getting reset. During this reset process, the ttyACM0 device is owned by root for a second instead of dialout. I think this is why I get could not open port /dev/ttyACM0: [Errno 5] Input/output error: '/dev/ttyACM0'. MrBlinky's python scripts work for me, so it could be there are some timeouts in place there that allow the device reset to settle.

I asked Mr.Blinky and they said the "flashcart-upload.py" is the correct file (the old one), so I will use that. There's a lot of "dev" options there, I'm not sure if I want to add all those flags, even though they are probably pertinent to someone. I'll have to think about it; it makes sense to create it "on the fly" but then we have all these special flags JUST for fx uploads. It's easy to do in the UI, and if the CLI should mirror the UI, then the flags SHOULD exist. An alternative is to run the tool once to generate special fx data with extras and another to flash that newly created file, but that's a lot of extra work, especially if that's a common workflow. It also doesn't match the current setup of flags for "on the fly" patches, like for the screen and LEDs.

Chances are, this flash will take a long time. It's not even 8KB per second I think, and it has to flash 16MB. But someone online said 5 minutes for 9MB... far shy of the 22 minutes I calculated assuming no losses. Hm... who knows

For both the CLI and GUI, there should be a way to mimic the "upload dev data" script from Mr.Blinky's utilities

You are already keeping a log of all actions performed, have some way to view this in case someone wants to know if they did something already or not.