On 08/23/2018 07:30 AM, silverdr@wfmh.org.pl wrote: > > What I'd love to eventually see/use is a tool that allows me to: > > - drop some files on it - let's start with two only: the binary (or whatever format you already support) and the label definition file Drag'n'drop support was there in the beginning, but had some problems. It shouldn't be too hard to reenable that as browser support on such things should have stabilized by now. > - get it/them disassembled (including interactive selection of data types) > - navigate through the JMPs/JSRs > - add comments as appropriate > - automatically mark fragments, which are not accessed directly > - save the disassembly to a few popular formats > > Some things are already there, which is why I find it so promising. Yep. I just need time to work on it. Currently the internals are in a large rewrite, so there haven't been any newly published versions in a while, during this transition. >> Unfortunately, I'm not going to be adding in .asm export for a while. >> There's too many issues to solve for the general case (ie, wildly >> varying platform assumption, multiple file overlays, WFDis allowing >> names the assembler doesn't like, etc) and I don't want to lock it into >> a simpler model that I'd have to tear out later. The main thrust of the >> project is to explore mechanical "understanding" of the code, not >> necessarily a code modification & reassembly tool... yet. > I am not sure I understand this correctly. It is not about using your tool to do modification / reassembly although this is obviously welcome. It is more about "what good is a tool for if one can't really keep/use the outcome of its work?" Yes, you can analyse some short passages this way in order to get understanding but not much beyond that. > You can currently keep/use the output. There is a save/load binary format encompassing all the workspace's information. This gets saved into the browser LocalStorage, and can be imported/exported as a normal .wfdis file on your computer as well. I guess exporting a textual format without regard to any given assembler's specific format would also be reasonable, before full support is figured out. As an example of problems with real asm syntax support, I label many local loop destinations as "+" or "-", which few assemblers would recognize. Label names also don't have to be unique, and can have spaces and punctuation in label names as I figure out what things are, like "Save X-Coord(?)", all of which would confuse assemblers if they were exported as-is. Graphics and colors in the WFDis workspace also would need to translate to source somehow, hopefully in a visually representative way, or maybe as separately linked .fnt/.spr/.koa/etc files.Received on 2018-08-24 04:00:05
Archive generated by hypermail 2.2.0.