Disassembly feature as a 3rd party extendable plug-in?

[Maël]

Looks like your approach is quite flexible.

Congrats on your progress

P.S.: Once the plugin is ready/source available, I can link to it from my website.

[Maël]

Still working on it?

[GregC]

Yes, I have progressed further. I was just finalising code to now support an optional second operand, which was initially driven by my desire to support the full Rockwell / WDC 65C02 extended instructions (specifically BBR). Then, I wish to complete the remaining 65xx and finalise the 6809 definition files, before I fully release.

However, unfortunately I've been side-tracked over the last couple of weeks with resolving some Big Sur upgrade issues on my Mac systems, and also with the arrival of my new Reverb G2 VR headset (so I've also been spending way too much time in the VR space! LOL).

[GregC]

UPDATE: I've just committed to github the following updates:

• Implementation of Second Operand option. Note this changes the .csv format, with added columns for the Second Operand parameters.
• Change of terminology in terms of 'Argument' references, now replaced with more appropriate 'Operand' terminology.
• Added 6502, 65C02, W65C02S, and 65C816 CPU definition .csv files (all completed).
• Note that W65C02S completely implements the WDC variation W65C02S instruction set (including the WDC unique two Operand test-and-branch BBRx & BBSx instructions).
• Also of note, currently W65C02S and 65C816 include instructions having two Operands.
• Updated README.md and .ini file documentation to reflect latest.

Get it here: Disassembly Plugin on GitHub

TODO: I have yet to complete the 6809 CPU defintion .csv file. That remains the last step for me to complete before I am happy to officially call this a v1.0 release, at which time I will also commit the fully commented v1.0 release source.

Finally, my apologies for the delay in completing the above. I have been completely mind blown by the latest Virtual Reality headset visual quality, and have therfore spent far too much of my spare time in "the Matrix". To remedy this, I intend to disipline myself by allocating my mid-week spare time to progressing only non-VR related projects & pursuits!

[Maël]

Nice update. All I can really do is wait until there is some source code, but it looks like good progress.

And don't worry about the VR stuff, I was just wondering if you abandoned the project.
Not the first time someone started a plugin, to then suddenly go silent/decide it was too much work.

[Maël]

The plugin framework changes are available in HxD 2.5, which will be released soon when all the translations are ready.

For now you can get it here (without setup):

German:
https://mh-nexus.de/downloads/HxD25Deu.zip
English:
https://mh-nexus.de/downloads/HxD25Enu.zip

[GregC]

Thanks Maël. Happy New Year! I'll take a look at your latest 2.5 downloads.

I've made a further Disassembly plug-in change since my last post, but everything stalled with Christmas / New Year break (and some health issues).

But I plan to progress completing the MC6809 definition file, as I'm hopefully getting back into some of my projects again from this week.

[Maël]

Happy New Year to you as well, and I hope you are fine.

The release will be available soon.

[GregC]

UPDATE: I've just committed to github the following (v1.0 release) updates:

• Completed the Motorola MC6809 CPU definition .csv file (Dasm6809.csv).
• Change to ensure the Hex formatted Operand output matches the actual Operand normalised byte length.
  eg. 24 bit Operands were previously being rendered as a normalised 32 bit (4 byte) value, instead of the actual 3 byte value that it actually is.
• Explored a code length optimisation change, but this would have been at performance cost. Therefore the change has only been retained as commented out.
• Now compiled for HxD 2.5.0.0 which is understood to be pending general release (see Maël's HxD 2.5 post and links above).
• Now includes first release of fully commented Source code (in the repository src sub-folder)
• Updated README.md file documentation (and LICENSE) to reflect latest.

Of Note: Currently the MC6809 is the most complex definition, due to it's comprehensive addressing modes and extended multiple-byte operands. The MC6809 definition includes 5,530 unique instructions, as compared to the MC6800 with only 197 unique instruction definitions, or the simplest (MOS 6502) which requires only 151 unique instruction definitions.

Finally, I'm now happy to call this my v1.0 release version. My apologies again for the delay in completing the above, with other commitments over the Christmas / New Year period.
My last task was completing the MC6809 definition file (fulfilling my original motivation CPU for doing this project!). The MC6809 was also a good final test of the implementation, due to the added complexity of the MC6809 CPU addressing modes and extended multiple-byte operands. This involved pretty much a full day's keyboard session to create the 5,530 unique instruction definitions. However, it also confirmed that a more complex CPU can be easily added (ie. defined), and in *only* a day!

Get it here: Disassembly Plugin on GitHub

Please Note: Compiled for HxD 2.5.0.0 understood to be pending general release (see Maël's HxD 2.5 post and links above).

[GregC]

Quick screenshot showing HxD v2.5.0.0 with the v1.0 Disassembly Plugin, with all six current CPU definition files loaded:

ps. I highlighted the grid's selected 6809 disassembly bytes outline, as my screen capture couldn't capture the outline.

HxD_DisassemblyPlugin_v1.png (122.76 KiB) Viewed 292219 times

[Maël]

Thanks for the update and the source code release!

I tried to compile it with Delphi XE3 (which is the version I use) and stumbled on two issues:

• Default param value for TBytes [] is not known, but nil works equally well.
• Insert and Delete are not yet defined in XE3 for TBytes (or arrays in general). Would you consider using RawByteString instead of TBytes, so it can compiled with XE3 and you can use Insert/Delete?

Edit: I tested it, and RawByteString has a one-based index, as opposed to the zero-based index of TBytes, which is an issue/needs to be considered when changing the type. Unfortunately Insert and Delete for TBytes are quite complex and cannot be copied easily from newer Delphi versions (especially since they are built-in functions that use compiler magic (such as implicit parameters).

Edit2: I used a simplified version of Insert/Delete that just handles TBytes instead of the generic solution in System.pas, which is quite short. Adding conditional compilation for XE6 around this and it works.

[Maël]

I made a few other changes to fix hints/warnings due to AnsiString/string mixing.
Should I send it per mail?

The compiled version works fine, as far as I can tell. And the updates are speedy as well when selecting random data in the hex editor.

Congrats!

[GregC]

Hi Maël,

Good point regarding the Compiler warnings. I just habitually ignored these knowing these specific warnings to be harmless, however it would certainly be wise for me to clean this up to avoid any confusion.

In terms of your noted XE3 compile issues / TBytes, I've added to the README "Source" section to note that the source was compiled with Delphi 10.3, and also noting the availability of the free Delphi Community Edition.
Given the availability of the free Delphi Community Edition, I don't see any need to retrograde the existing published source to allow for earlier Delphi version compatibility (current TBytes handling is a tidy solution).

On this basis, I've just now committed to github the following UPDATE:

• Include explicit type casting for various AnsiString <-> String conversions, to avoid any confusion around harmless W1057 / W1058 Compiler warnings.
• Update README to advise the Delphi compiler version used, and availability of the free Community Edition IDE.

[Maël]

Here are the changes I meant.
Reason is as I stated earlier. I use Delphi XE3 Professional, and it's not a big change (just two short functions, TBytes remains
If we collaborate this makes it easier.

I solved it without type casting, and just using string (Unicode string throughout) and AnsiLowerCase/AnsiUpperCase (LowerCase/UpperCare are ASCII only). It's better to avoid AnsiString if possible, you never know what characters you will have in the file (not everyone just uses ASCII).

Ansi*Case sounds like it is for AnsiString, but it's for Unicode, the naming is an unfortunate result of Delphi's legacy, but its the correct functions.

[GregC]

Thanks Maël. I certainly agree that collaberation is good. It also promotes learning from other's experience.

I'd not utilised AnsiLowerCase/AnsiUpperCase as I didn't consider the associated data files would have international character implications.
ie. The data files referenced are the included plain text .ini and .csv file content.

Being old-school, I'd utilised AnsiString on the basis that the subject matter (Hex strings and Assembly language mnemonics) are traditionally ASCII character based. But I don't profess to being experienced with international language / international character support (although I'm certainly familiar with Unicode).
Are you suggesting that someone could potentially create a new .csv (or .ini) file as a UTF-8 Unicode text file containing multi-byte characters?

I do however see that I should just trust the Delphi HexToBin handling of multi-byte characters (and that Length, of course, returns the actual character count). Being old-school, I'm always thinking of data at the byte level. LOL

Your {$IF RTLVersion <= 27.0} directive is certainly a non-intrusive resolution for older Delphi version support.

My only remaining question is to understand why you have changed SmallInt types to Int16? Delphi Int16 is an alias of SmallInt (ie. type Int16 = SmallInt;).
Is this simply your preference for more clearly specifying a 2-byte integer type?

Otherwise, I'm happy to roll your suggestions into the published source (I'll just await the clarification on your Int16 changes).