Running Cport from Win1_

[Martin_Head]

Thanks Martin.

I'll get in these ASAP. Tking MrsD for her first vaccination today.

Much obliged.

Cheers,
Norm.

Had mine as well. So far, still feeling OK, no flu symptoms yet

[NormanDunbar]

I had the A-Z vaccine. No symptoms at all. Mind you, I did sleep for two solid hours on Saturday afternoon - possibly related? But most likely because I was awake at 1 Am the night before!

Alison has also had the A-Z one, and she's had no symptoms either.

Looking forward to my second.


Cheers,
Norm.

[bixio60]

I had the A-Z vaccine. No symptoms at all. Mind you, I did sleep for two solid hours on Saturday afternoon - possibly related? But most likely because I was awake at 1 Am the night before!

Alison has also had the A-Z one, and she's had no symptoms either.

Looking forward to my second.


Cheers,
Norm.

Hi,
Off-topic:
I had the A-Z vaccine last Saturday....well not good.... 2 days (Sunday and Monday) in the bed with fever, nausea, pains all over my body, especially where I got the injection ... today all fine ... phew

Back on topic:
I am working on the results of decompiling (thanks Martin) DP Astrologer and Astronomer. The _bas resulting is not too bad in respect of the result I got from Cport_bas

Fabrizio

[EmmBee]

I am working on the results of decompiling (thanks Martin) DP Astrologer and Astronomer. The _bas resulting is not too bad in respect of the result I got from Cport_bas

Fabrizio

Hi Fabrizio,

In DP Astrologer and Astronomer, are you getting any ** Stack empty ** 's ? In Cport_bas there are quite a few of these showing up. The question is what to do about them. I reckon we need to replace these either with a 0 or a null string as appropriate. However, this may be problematic for some keywords, such as POKE$, POKE_L and PEEK$.

Michael

[Martin_Head]

I am working on the results of decompiling (thanks Martin) DP Astrologer and Astronomer. The _bas resulting is not too bad in respect of the result I got from Cport_bas

Fabrizio

Hi Fabrizio,

In DP Astrologer and Astronomer, are you getting any ** Stack empty ** 's ? In Cport_bas there are quite a few of these showing up. The question is what to do about them. I reckon we need to replace these either with a 0 or a null string as appropriate. However, this may be problematic for some keywords, such as POKE$, POKE_L and PEEK$.

Michael

Here's an example

Code: Select all

11866 procFun13057 : IF (** Stack empty ** < (var94A4 * 1024)) THEN 

procFun13057 is almost certainly a function, so the line should be

Code: Select all

11866 IF (procFun13057 < (var94A4 * 1024)) THEN 

The decompiler tries to identify functions, but defaults to procedures if it's not sure.
The ** Stack empty ** is a warning that the compiler was expecting to find something on the stack, and it was not there. As the compiler incorrectly identified procFun13057 as procedure, it did not place it on the stack, as a function would have been.

Once you have identified which are Functions, and which are Procedures. It gets easier to spot what's going on.

I notice there are also some Stack empties by some READ's. Let me know if you have problems with them that I need to sort out.

[EmmBee]

There is one such line here ...

Code: Select all

11413 FOR var9400 = 1 TO 12 STEP 1 : READ  : var9AA0$(** Stack empty ** TO var9400%) = var9400% : END FOR var9400%

I was going to interpret this as

Code: Select all

11413 FOR var9400 = 1 TO 12 : READ var9AA0$(var9400)

Note the index name of var9400 only would be used - and not var9400%

[Martin_Head]

There is one such line here ...

Code: Select all

11413 FOR var9400 = 1 TO 12 STEP 1 : READ  : var9AA0$(** Stack empty ** TO var9400%) = var9400% : END FOR var9400%

I was going to interpret this as

Code: Select all

11413 FOR var9400 = 1 TO 12 : READ var9AA0$(var9400)

Note the index name of var9400 only would be used - and not var9400%

If var9AA0$ is an array, that looks likely. I seem to remember having some problems with READing into arrays. I would have to do a manual decompile to be sure of what's going on.

var9400 probably had an IMPLICIT somewhere to make it integer. I think in the compiled code, FOR just specifies that its var9400 and there is no indication that it's integer. So the decompiler does not know to add a '%' on the end of the FOR.

I think you will find that tidying up a Turbo decompile, is harder than a Qlib decompile. QLib seems to me to be a lot more consistent and simpiler, and it also offloads a lot to QDOS, that Turbo handles internally.