Running Cport from Win1_

[NormanDunbar]

Morning all,

I'm getting old and my brain is fading.

I noticed that I've never loaded Cport onto my QPC hard drive. Luckily my floppies which have survived include the Digital Precision Collection, so \i extracted the zip andinstalled it in win1_cport_.

It looks like I'm not able to run Cport unless loaded from floppy. There's no configuration that I can see anywher, so executing win1_cport_cport just barfs as it's looking for the grammar file and not finding it.

I realise I can create a "floppy" using qltools and assign that to flp1 in QPC, but I was wondering if there's a lazy option that someonehas found to let me configure it? The manual says nothing at all.

I did try to use Martyn's disCharge to decompile Cport -- why not -- but it barfed when running the full decompiler, with an error along the lines of A9A6 or similar. No codes file was created. I was thinking it would be good to ressurect the source for Cport -- in a manner similar to the hard work everyone (involved) did for QLiberator.

Cheers,
Norm.

[RalfR]

I do not know the program, but is it possible, that there is a hard coded "flp1_" in the program? Try to search in an (suitable) editor.

If there is, you may try to change this to "dev" or "sub" or "pth", because extending the string in the program code (for your subdir) will be not possible.

[mk79]

The way I did it on my QL-SD demo disc (which includes many old games) is using the SUB device to map the program directory to SUB1_ and patch any MDV or FLP in the binaries to SUB. This way the programs are oblivious to the fact that they are run from a sub-directory.

Edit: ah, just saw that Ralf had the same idea. Sorry

[NormanDunbar]

Thanks Gents, and Marcel, don't worry about repeating Ralf! Too much information is better than none at all.

I thought I would have to do some binary editing (S-Edit anyone!) to patch things, but I was hoping that somewhere, there was an alternative option.

Thanks again.


Cheers,
Norm.

[NormanDunbar]

S-Edit did the trick. Running from DEV1_ now.
Seems to be ok -- at least I get the initial screen up.

Having to do housework at the moment - SWMBO has decreed that the house needs tidying up.

Playtime later, maybe!


Cheers,
Norm.

PS. SWMBO? She Who Must Be Obeyed!

[Martin_Head]

I did try to use Martyn's disCharge to decompile Cport -- why not -- but it barfed when running the full decompiler, with an error along the lines of A9A6 or similar. No codes file was created. I was thinking it would be good to ressurect the source for Cport -- in a manner similar to the hard work everyone (involved) did for QLiberator.

Back in August I did an update to DisCharge for someone, But I don't remember if I ever posted it anywhere. So here it is.

If I remember, The other person was having problems with no code file being generated with a Turbo'ed program. The issue was that the compiled program reported that the CodeGen used was V5.10, but the routines looked like they came from V5.09. From my experience of looking at Turbo'ed programs, there seems to have been some major changes made around 5.09 and 5.10

I also discovered that things started to go a bit strange in the compiled program if it's larger than 64K. You start getting long and short "GO TO's" in the code.

I think I also added support for GLOBAL and EXTERNAL, but I think they still need a bit of work.

Anyway if this is not the one you have, give it a go. If I can find a bit of time, I may have a go at decompiling Cport.

[NormanDunbar]

Thanks Martin (and apologies for spelling your name wrongly previously!)

My original version of disCharge_bas was 17/05/2019 and this is 12/08/2020 so a much more recent version.

This time I get a better decompile, but it bombs out eventually, in the full decompiler, with "Unexpected code $A288 found while analyzing array variables and searching for the start of the Basic program". GOTO 1000, as expected, gives the same error. At least I got further with this version, I get data in the codes file where I didn't previously.

If you need the codes and dmp/dmp_lib file(s) let me know, it might help in diagnosing things.

Thanks for the latest version, it helped.


Cheers,
Norm.

[Derek_Stewart]

Hi,

I looked at the Discharge programme and worked my way through the worked example on SuperKit.

The Discharge programme stopped at line 27430, with error message:

At line 27430:1 assignment can only be a variable or array element

Looking at line 27430, shows variable assignment: FOUND=0

I have the DBAS extensions loaded on boot up, which defines a function: FOUND, this causes a clash.

Not loading the DBAS, all is OK.

What is the best way to avoid system Function or Procedure clash when defining applications programmes?

[Martin_Head]

Thanks Martin (and apologies for spelling your name wrongly previously!)

My original version of disCharge_bas was 17/05/2019 and this is 12/08/2020 so a much more recent version.

This time I get a better decompile, but it bombs out eventually, in the full decompiler, with "Unexpected code $A288 found while analyzing array variables and searching for the start of the Basic program". GOTO 1000, as expected, gives the same error. At least I got further with this version, I get data in the codes file where I didn't previously.

If you need the codes and dmp/dmp_lib file(s) let me know, it might help in diagnosing things.

Thanks for the latest version, it helped.


Cheers,
Norm.

The complied program has a section that defines the types of all the variables and arrays used in the program. The decompiler scans this looking to find the number of dimensions in arrays. It looks like there's an array type I have not encountered yet. The $A288 should refer to a routine in one of the generated disassemblies.

This is one of the things about the decompiler, You have to teach it what each routine does, But you don't know what the routine does until you try to decompile a program that uses that routine. Hence all the library files for the different versions of Super/TurboCharge. And if you look at these files you will see gaps where there are routines I have not encountered yet.

I have the DP Collection, so I should be able to find Cport. If I can find a bit of time to dig it out and have a go.

[Martin_Head]

Hi,

I looked at the Discharge programme and worked my way through the worked example on SuperKit.

The Discharge programme stopped at line 27430, with error message:

At line 27430:1 assignment can only be a variable or array element

Looking at line 27430, shows variable assignment: FOUND=0

I have the DBAS extensions loaded on boot up, which defines a function: FOUND, this causes a clash.

Not loading the DBAS, all is OK.

What is the best way to avoid system Function or Procedure clash when defining applications programmes?

I've had this problem before in programs, I will change the name of the offending variable.