SuperCharge Decompiler

Anything QL Software or Programming Related.
martyn_hill
Gold Card
Posts: 449
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperCharge Decompiler

Postby martyn_hill » Mon Jun 18, 2018 7:16 pm

Hi again Martin

Some early feedback...

My first attempt at running (Turbo)ProcessDump against one of my Turbo compiled apps failed to recognise my version of Turbo (appears to be v5.37).

I naively modded the SELect ON version clause for 5.1 to accept 5.37. The program then runs without error, but produces an empty _codes file and displays an empty value for the "Sub routines start around" field (the rest of the summary looks reasonable):

ProcessDumpSummary.png


Not unexpected, given its early stage of development and the numerous versions of Turbo out there... :-)


martyn_hill
Gold Card
Posts: 449
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperCharge Decompiler

Postby martyn_hill » Tue Jun 19, 2018 11:52 am

Hi Martin

After a more thorough scan of the Turbo v5.37 compiled disassembly of my sample job, I note the following:

a) The various 'jmpkey$' options coded in the current version of TurboProcessDump are not to be found in my job disassembly, but the following looks promising:

> "4EF60000" == JMP $00(a6,d0.L) in place of "4EF60000" == JMP $00(a6,d0.w) - note the d0.L rather than d0.w that is currently checked-for in the SELect ON version=5.0
or
> "4EEE8370" == JMP -$7C90(a6) in place of "4EEE8228" == JMP -$7DD8 that is checked-for against version=5.1

b) There are no lineStart$ matching "3C1D" == move.w (a5)+,d6, but rather many "3E1D" == move.w (a5)+,d7 - note the switch of d6 for d7

I'll try some adjustments to ProcessDump in light of the above findings and report back - in case anyone else is also using this later version of Turbo...


martyn_hill
Gold Card
Posts: 449
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperCharge Decompiler

Postby martyn_hill » Tue Jun 19, 2018 12:05 pm

OK, so after adding a SELect ON clause for version 5.37, thus:

Code: Select all

ON version=5.37
  jmpkey$="4EEE8370"
  jmp$="JMP   -$7C90(a6)"
  lineStart$="3E1D" : REMark move.w (a5)+,d7
  :


ProcessDump now populates the "Sub routines start around" field and also populates the _codes file. The output _lib file also has sub-routine sections split-out, so we're getting somewhere.

However, ALL the line-number references in the _codes file report as '-1', whereas I know that the job was compiled with line-numbers enabled, so still something amiss to work with Turbo v5.37.

I'll play some more tomorrow.

M.


Martin_Head
Gold Card
Posts: 356
Joined: Tue Dec 17, 2013 1:17 pm

Re: SuperCharge Decompiler

Postby Martin_Head » Tue Jun 19, 2018 2:03 pm

martyn_hill wrote:My first attempt at running (Turbo)ProcessDump against one of my Turbo compiled apps failed to recognise my version of Turbo (appears to be v5.37).

The version number appears to be the version of the part of Turbo that creates the final executable, rather than the version of Turbo itself. My version of Turbo (3.24) gives version 5.10 in the final executable.

martyn_hill wrote:a) The various 'jmpkey$' options coded in the current version of TurboProcessDump are not to be found in my job disassembly, but the following looks promising:

> "4EF60000" == JMP $00(a6,d0.L) in place of "4EF60000" == JMP $00(a6,d0.w) - note the d0.L rather than d0.w that is currently checked-for in the SELect ON version=5.0
or
> "4EEE8370" == JMP -$7C90(a6) in place of "4EEE8228" == JMP -$7DD8 that is checked-for against version=5.1

b) There are no lineStart$ matching "3C1D" == move.w (a5)+,d6, but rather many "3E1D" == move.w (a5)+,d7 - note the switch of d6 for d7

All the SuperCharge and the (few) Turbo programs I have looked at, have end of routine codes along the lines JMP -$7C90(a6). Except one. The install program for Fleet Tactical Command II. Which is like JMP $00(a6,d0.L). It has a version of 5.00. And if I remember correctly it has a copyright message of "Simon N Goodwin" rather than "The Turbo Team" that the others have. I thought it might have been a one off change in format that did not work, then got changed back. And as it's a commercial program so I did not go much further.

martyn_hill wrote:However, ALL the line-number references in the _codes file report as '-1', whereas I know that the job was compiled with line-numbers enabled, so still something amiss to work with Turbo v5.37.
This will happen, as none of the routines checksums in the Library2_id file will match the checksums in your disassembly. Because of at least, all of the different routine endings.

All of the routines in the disassembly file will need to be identified. And put in Libray1 files like the Library2 files. I haven't yet tried looking at these different types of routines.

Post what you've got and the original BASIC program here, and I will try to create the Library1 files. Unless you want to have a go yourself.


Martin_Head
Gold Card
Posts: 356
Joined: Tue Dec 17, 2013 1:17 pm

Re: Super/TurboCharge Decompiler

Postby Martin_Head » Tue Jun 19, 2018 2:15 pm

Derek_Stewart wrote:Hi Martin,

The source to Diskmate 5 is lost and only the Turbo compiled executable exists. I was trying to rewrite Diskmate 5 based on the way it works. I have extracted some of the Easyptr menu definitions, which were added to the end of the Turbo compiled code.

Maybe your discharge programme could be used to analyse the compiled code.


I have downloaded it, And I will have a look. Are you sure it Turbo'ed? A quick look at the dm5_obj files says "1993 Liberation Software"


User avatar
dden
ROM Dongle
Posts: 19
Joined: Thu Jan 19, 2017 8:56 am

Re: SuperCharge Decompiler

Postby dden » Tue Jun 19, 2018 3:50 pm

Hello Martin,

I'm very pleased to read about your Turbo decompiler software. It's a little bit too advanced for me to follow at times, but I find it so interesting that you've achieved what many thought couldn't be done.

So, trying to help in whatever way I can, I enclose an old word game program of mine called Xwords, compiled with Turbo. I can't remember which version but there's a "5.35" in the preamble of the compiled task. I've attached both the executables (from Dilwyn's site) and the sources, thinking it might be helpful for you to compare the decompiled output with the original sources. The sources include a little config block created using George Gwilt's TConfig and a small toolkit from Dilwyn linked to the executable.

Dilwyn: feel free to add the sources to your website if you think it will be of interest to users.
Attachments
xwordssource.zip
Sources for Xwords
(6.26 KiB) Downloaded 18 times
xwords.zip
The Xwords game
(83.1 KiB) Downloaded 17 times


David
Martin_Head
Gold Card
Posts: 356
Joined: Tue Dec 17, 2013 1:17 pm

Re: SuperCharge Decompiler

Postby Martin_Head » Tue Jun 19, 2018 5:53 pm

Martin_Head wrote:
martyn_hill wrote:However, ALL the line-number references in the _codes file report as '-1', whereas I know that the job was compiled with line-numbers enabled, so still something amiss to work with Turbo v5.37.
This will happen, as none of the routines checksums in the Library2_id file will match the checksums in your disassembly. Because of at least, all of the different routine endings.

All of the routines in the disassembly file will need to be identified. And put in Libray1 files like the Library2 files. I haven't yet tried looking at these different types of routines.

Post what you've got and the original BASIC program here, and I will try to create the Library1 files. Unless you want to have a go yourself.

I've spent some of the afternoon looking at the Fleet Tactical Command II Install program, and started creating Library1 files. There are only 14 routines identified at the moment for version 5.00. But hopefully you will get a match somewhere.

Remember to change the TCLibrary2_id file name at the start of the ProcessDump program to TCLibrary1_id.
Attachments
Library1.zip
(6.87 KiB) Downloaded 16 times


martyn_hill
Gold Card
Posts: 449
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperCharge Decompiler

Postby martyn_hill » Wed Jun 20, 2018 12:34 am

Hi Martin!

This is interesting - I'm hooked!

Martin_Head wrote:The version number appears to be the version of the part of Turbo that creates the final executable, rather than the version of Turbo itself. My version of Turbo (3.24) gives version 5.10 in the final executable.


Makes sense - so the version recorded in the executable is tied to the Turbo 'code generator.' My version of Turbo is actually v5.09 (from the 'charge' control panel.)

Martin_Head wrote:All the SuperCharge and the (few) Turbo programs I have looked at, have end of routine codes along the lines JMP -$7C90(a6).


I guess you meant "JMP -$7DD8(a6)" - the jmp$ that is currently programmed in ProcessDump for version 5.1 - version 5.37 appears to generate that "JMP -$7C90(a6)"...

Martin_Head wrote:This will happen, as none of the routines checksums in the Library2_id file will match the checksums in your disassembly. Because of at least, all of the different routine endings.


Doh, of course... Understood - nothing to do with line-numbers, but routine IDs...

Martin_Head wrote:All of the routines in the disassembly file will need to be identified. And put in Libray1 files like the Library2 files. I haven't yet tried looking at these different types of routines.

Post what you've got and the original BASIC program here, and I will try to create the Library1 files. Unless you want to have a go yourself.


I think I'll have a go myself (though you're more than welcome to my source files) - it'll be quite a job matching each of those 200 odd routines and I suspect my program uses most of them!

One question for you - given that the line-start marker generated by v5.37 appears to be "3E1D" rather than the "3C1D" for v5.1 as in the current version of ProcessDump, I note that later in the program an explicit reference is made to the new line-start marker (line 5210 -> "IF PEEK_W(base+(address-dumpStart))<>$3E1D THEN RETurn") - should this 'GOTO' check still work as expected now that it's the same as the line-start marker?

Thanks for providing such an interesting distraction from my QNET-USB project (still very much alive, but stalled slightly...) :-)


Martin_Head
Gold Card
Posts: 356
Joined: Tue Dec 17, 2013 1:17 pm

Re: SuperCharge Decompiler

Postby Martin_Head » Wed Jun 20, 2018 10:35 am

martyn_hill wrote:One question for you - given that the line-start marker generated by v5.37 appears to be "3E1D" rather than the "3C1D" for v5.1 as in the current version of ProcessDump, I note that later in the program an explicit reference is made to the new line-start marker (line 5210 -> "IF PEEK_W(base+(address-dumpStart))<>$3E1D THEN RETurn") - should this 'GOTO' check still work as expected now that it's the same as the line-start marker?)


Working from memory, and the Processdump listing...

The program uses the 'end of routine' markers to separate out the different routines. However it kind of misses the first routine, as it only finds the end of it and not the start.

So the routine from 5187 to 5300 'back tracks' trying to find the start of, and identify the first routine. Up until now I have found the Super/TurboCharge programs, always has the same first routine "GO TO". With the same number of bytes - 10 (Line 5200 address=address-10), and starting with the same instruction - $3E1D

If you look at your processed disassembly, I expect that where you get what appears to be the first routine identification. You will find just before it, a short routine. If I remember correctly in the Turbo'd programs I have looked at there is a big block of zero's, or spaces just before the start of the first routine.

These different endings and jumps at the ends of the routines, either a negative offset of A6, or a D0 offset of A6. which seem to be changing with different versions. Could it be something to do with options at compile time, or compiler directives in the program? What compiler options do you use? I have used the default ones that my version of Turbo came with.


martyn_hill
Gold Card
Posts: 449
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperCharge Decompiler

Postby martyn_hill » Wed Jun 20, 2018 12:25 pm

Hi Martin

Makes sense - thanks.

Here are the Turbo compile options I hard-code in the pre-amble to the test program in question (a Lap Counter/Race Timer for my son's Scalextric):

Code: Select all

TURBO_locstr "R"
TURBO_windo 0
TURBO_optim "B"
TURBO_model 1
TURBO_struct "S"
TURBO_diags "I"
TURBO_list "YES"
TURBO_sound "YES"
TURBO_objdat 16
TURBO_buffersz 16
TURBO_objstk 512
TURBO_taskn "RMS v4.4k"
TURBO_objfil "ram1_RMS_v4t4k_exe"
TURBO_repfil "dos2_RMS_RMS_v4t4k_rpt.txt"


I'm about 5% the way through the 200-odd code IDs, switching-out the existing check-sums for those of the routines found in the test job.

One thought for a future version - given that, once a suitable 'line-start' marker is defined, based on version of the detected Turbo code-generator, could the check-sum routine be made instead to only scan the intervening code fragment to build the hash, i.e. excluding the line-start marker itself - thus potentially making the check-sums more likely to match across/independent from compiler version?

On a side note, I've already found at least one duplication of routine (ID: 204 - "RETRY_HERE") that appears twice in my disassembly (so far), only with very slightly different offsets for the BCC and LEA instructions (due to position-dependence), thus:

Code: Select all

Prefix - 9BE2 (204a)
Version 5.37 - Checksum = 001A00C948
0031C55A  41E9FF80       lea       -$0080(a1),a0               A...
0031C55E  B1CC           cmpa.l    a4,a0                       ..
0031C560  6404           bcc.s     [b]$0031C566[/b]                   d.
0031C562  4EEE8AEC       jmp       -$7514(a6)                  N...
0031C566  45EE805A       lea       [b]-$7FA6(a6)[/b],a2               E..Z
0031C56A  24CD           move.l    a5,(a2)+                    $.
0031C56C  48D2D200       movem.l   a1/a4/a6-a7,(a2)            H...
0031C570  4EEE8370       jmp       -$7C90(a6)


and:

Code: Select all

Prefix - 9BFC (204b)
Version 5.37 - Checksum = 001A00CA24
0031C574  41E9FF80       lea       -$0080(a1),a0               A...
0031C578  B1CC           cmpa.l    a4,a0                       ..
0031C57A  6404           bcc.s     [b]$0031C580[/b]                   d.
0031C57C  4EEE8AEC       jmp       -$7514(a6)                  N...
0031C580  45EE806E       lea       [b]-$7F92(a6)[/b],a2               E..n
0031C584  24CD           move.l    a5,(a2)+                    $.
0031C586  48D2D200       movem.l   a1/a4/a6-a7,(a2)            H...
0031C58A  4EEE8370       jmp       -$7C90(a6)


Obviously, this produces two distinct check-sum hashes, but the current program logic only appears to accomodate one routine/segment per ID...

Is this an example of where manual intervention is expected, following the ProcessDump run?

Interestingly, I don't actually have any explicit RETRY_HERE commands in my source program :-)

Meanwhile, I've got some more visual inspection to do to match-up the remaining routines between the disassembly and TCLibrary2_lib...

M.



Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 1 guest