> On 2018-08-24, at 01:05, David Holz <david.holz@grindwork.com> wrote: > > 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. Yes, I use a cross-browser "drag'n drop" for file upload in daytime projects for some time already. Still - by "dropping" files on it I didn't necessarily mean literal dropping. More like "giving it to process" in any easy to use way :-) Obviously drag'n drop is very much welcome too. >> - 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. The most common problem we experience with our hobby stuff. > Currently the internals are in a > large rewrite, so there haven't been any newly published versions in a > while, during this transition. I see. > 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 take you mean that I can import this "normal .wfdis" binary back into your browser application? This I know I can but it is still of very limited use. Suppose I spent sizeable amount of time doing a large disassembly and eventually I have it all the way I like it. What next? Currently I can use a trick to copy-paste the /rendered/ output into a text editor but that's not like a right way to do it. And obviously requires lots of post-processing then too. > 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. It could be a good starting point. > 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. Hm, I gave it a run over the whole 251968-03 DOS and didn't notice any of those "cheap, local labels" (+/-) but in general yes, eventually there need to be "export filters", translating what you use internally into what is understandable to a particular external tool. I use ca65 these days (although xa was my previous choice and I still like it a lot) so at least cheap labels are not an issue ;-) Labels - either need to be restricted (there are comments still where one can user whatever he likes) in what form they can take, or escaped/translated on output... but I am sure you know all this and it is mostly the matter of finding time. > 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. I would suggest saving these for the final touches. For a good start any graphical stuff, can be safely surrounded with comments and exported as hex or binary strings. For some limited readability sprite data can f. e. be output in sets of three eight-bit-binary strings per line, etc. This shouldn't be a show-stopper. -- SD! - http://e4aws.silverdr.com/Received on 2018-08-24 12:00:06
Archive generated by hypermail 2.2.0.