fadden
commented
2 years ago I've had the basic notion of support for structs on the list for a while. I think most of the work would be on the UI side, to create a "struct definition editor". Simple structs that are just a list of fixed-width items are easy, but when they have multiple variable-width pieces, some of which are optional, it can get complicated in a hurry. You want to be able to drag & drop items and add attributes, and preview the struct with actual data to see if you're getting it right.
Defining structs in a file would be easier to write since the edit UI could be skipped. Limiting it to C-style structs makes life easier but even then you need attributes for endianness and word alignment vs. packed, and have to decide what to do with nested structs. I don't know if it would be enough to parse the struct definition as flat data; treating it as a program that drives the formatting might be necessary.
Mostly I'm not sure how much is "enough".
Right now the closest thing is to format the data with an extension script. For example, the Apple II ProDOS 8 and GS/OS scripts will format the contents of OS call parameter blocks, which have 8/16/32-bit fields and string pointers. However, scripts need to be triggered by something (like an OS call), which may not make sense for a struct.
As far as the underlying mechanics go, selecting a region of data and giving it some sort of "struct tag" would be pretty straightforward. As you point out, it's not so different from string formatting.
In terms of your specific example of a C64 sprite, you can create a visualization if you want to see how the image looks. If you create the project with one of the C64 system entries, you'll already have RT:Commodore/VisC64.cs loaded. Select the first byte of the sprite and hit Alt-V twice. Pick the format from the pop-up menu at the top and adjust the parameters below. The manual explains a bit more.
It's not quite as nice as a C64-specific tool would be, but it's enough to see which shapes are which, and it's a lot easier on the eyes than ASCII art in the comment field. OTOH, if you generate assembly code rather than HTML, you lose the visualization, so dressing the data up nicely has advantages. The "densely-packed bytes... with a limit of 3 bytes per line" feature is intended for quickly formatting this sort of thing, but it's currently limited to hex output only, which isn't so good for bitmaps.
BacchusFLT
There is already a variety of options on how to structure data in the Operand menu, but in order to take that to the next level, I would like to suggest an option of adding data in a "struct" like fashion.
One example is commodore 64 sprites; they are three bytes wide (24 bit) and 21 bytes high with a padding byte before the next sprite, which means the sprites appear on 64 byte intervals. Here a struct would be a label on the first line (sprite name), 21 lines that are three bytes wide (the sprite body) and then a padding byte in the end, before the struct repeats. Possibly one would also want the bytes in binary format so you can easily see the sprite.
A Cartridge header is also one such defined struct (two words and then the string CBM80).
Similar structs would apply to screens, bitmaps, fonts and other objects. I'm thinking a setup with a definition file, where one could add more formats, which would build a pull down in the Operand menu. Quite frankly, the strings are already examples of such structs, so it's already there in one form.