The Sinclair QL Forum

It was the first time I had such a problem with the Pyramide Graphic Toolkit and my SQB with a mouse. There was a keyword "Pointer", that was also there on the SQB, that started Pointer I/F from SQB EPROM.

Hi Norm,

emmbee wrote:
To actually do this I suppose there would have to be lists of Toolkits with there names.


Norm replied :
https://superbasic-manual.readthedocs.i ... lkits.html


Yet another case of RTFM ? Wow! Thanks to Rich, lots of revision to do again....


Steve.

NormanDunbar wrote:

emmbee wrote:To actually do this I suppose there would have to be lists of Toolkits with there names

Like this?

https://superbasic-manual.readthedocs.i ... lkits.html

Cheers,
Norm.

Or something like this one?
http://www.wlenerz.com/smsqe/addkeys.html

BSJR

NormanDunbar wrote:

Martin_Head wrote:Don't run the disassembling first phase again, just run the turbodischarge1_bas program, and use the cport_codes file supplied.

Many thanks indeed Martin, that helped a lot. Using the codes file you supplied, and the updated version of the TurboDisCharge1_bas decompiler, I got about 14,500 lines of "interesting" SuperBASIC. You've done a fantastic job on this utility, well done. I do have a lot of lines with just a single colon in them, at the start of the output but I remember reading about those in the manual, so I can work with them -- when MrsD allows of course!

Thanks again.


Cheers,
Norm.

I was having another little look yesterday. Of the 4 unidentified code routines. I think one is the 'bitwise NOT', one is an integer TO as in 'SELect ON c% 1 TO 10' . The other two I think may be something to do with LOCal variables, but they don't quite match LOCal handling that I have seen before.

I have compiled a little test program to check the first two. I just need to de-compile it to see if I get code routines to match the ones in Cport.

The lines with just a colon are things like REMarks, and the start of REPeats. Things that don't generate any compiled code. (And I think that includes compiler directives in REM's)

stevepoole wrote:Hi,
A simple way to avoid name-table clashes is to type EXTRAS to get a list of names, before loading any suspect code...
So having a printed listing of the suspect code is handy !
This is of course a manual process, not an automatic one, but usually makes things clear... Anyone fancy writing a name checker ?
One of my favourite pitfalls in trigonometry is using : ax, bx, cx, dx , ex ....
Steve.

Here is a little "proof of concept" I've quickly knocked together this morning for a "Name Check" program. Further work needed of course, this is a simple demo.

This is a short BASIC program which takes the alphabetically sorted names list in the text file "namessc_txt" in the zip file attached, and asks you to enter a variable name. It scans through the plain text file looking for the name. The text file, which can be edited in any plain text editor to add or amend names, has three columns, separated by semi-colons:

NAME;TYPE;IN_WHICH_TOOLKITS

The name would be any standard keyword name.
The type is a single character - such as F for function, P for procedure, - for unknown type etc etc
IN_WHICH_TOOLKIT is just a short line of text listing which toolkit(s) the keyword is found in.

This list is taken from a file on Wolfgang Lenerz's website (also on my site, but not sure which is more recent) at http://www.wlenerz.com/smsqe/addkeys.html

My program is a simple binary chop search routine (hence why the text file has to be sorted in alphabetical order). At the moment, all the program does is ask you to input a name, and searches through the list looking for matches and prints them to the screen. Needs to be run in BASIC at the moment with windows set to TV mode (unless you add some WINDOW commands at the beginning).

If you wish to tinker with it while I work on it, the important line is line 570, which does the searching by calling the procedure SEARCH_FOR with the name you entered in line 550. That procedure does the binary search and formats the output list of name matches. Most of the code in the earlier part of the program is just to do with loading and preparing the names text list into an array called array$. Not much error trapping and the binary search could probably be made more efficient as it was simply lifted from an existing routine in an older program of mine.

I hope to add two more options to it:

1. QREF software users could create a list of names used in their programs with QREF_V and QREF_P sent to a file (OPEN_NEW#3,ram1_VARS_TXT:QREF_V#3:CLOSE#3) and process this to extract the variable/procedure names - the format of file produced by QREF makes it fairly easy to process the list I think). This could automate the checking of names.

2. I hope to extract a routine from my Basic Reporter program which scans the name table to extract a list of names in your loaded BASIC program. This uses commands in Turbo Toolkit, so if compiled would work alongside BASIC (like Basic Reporter) to do an automated check of names in your currently loaded BASIC program on request.

Will see what I can come up with this afternoon. Meantime, feel free to tinker!
EDIT: I forgot to mention that the program loads the text file from ram1_ for speed, change this in line 170 as required.

Coming back on topic, here's another update...

If you just run the turbodischarge1_bas program as before, The decompile will complete without hanging. I have not looked through the program so there may be some lurking problems in the generated BASIC.

I think there may be some EXTERNAL/GLOBAL things going on. I have not figured out all of the EXTERNAL/GLOBAL stuff yet. So bear that in mind.

I think that a lot of the empty lines in the program are DATA statements, there is a big list of data at the end of the decompile.

I don't know the copyright status of this program, So I have not included the decompile. PM me with an email address if you want it.

I had a quick try to decompile the CFIX program, but that requires some more work.

And here's an update for the Cfix program.

Thanks Martin.

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

Much obliged.

Cheers,
Norm.

Hi,

I've finally managed to decompile Cport, and Cfix. With Cport, I get just over 6,000 lines of code.
This is all looking good. We should be able to do everything we did with QLiberator. We can learn from experiences - there were a lot of single-line IF statements, where the terminating END IF could have been left out, to improve readability, and also reduce the code size. There are many problem lines still to be unravelled. We are still in the decompiling stage.

Our goal is to, first of all, get the program up and running. After this, we can concentrate on renaming the variables to finally find out how the program works.

The size of Cport is over twice that of QLiberator, so we have quite a lot of work to do. This should take us quite a while.

EmmBee

It appears that I have unleashed a demon!