QLiberator decompiler

[RalfR]

Yes, that seems to be a clever way

I would like to put that in Martin's Qlib8 and send this to him as QLib9, We should ensure, that QLiberator works on all platforms as it had up to now.

[tofro]

It is possible to find SCR_XLIM and SCR_YLIM in SuperBASIC by trying to find the maximum Window size possible - without it stopping with an error.
Fortunately, using QLiberator, such errors can be detected by using the Q_ERR_ON feature. Eg. try something like this ...

Code: Select all

REMark Finding maximum x and y size possible before it gives an error

100 OPEN #9,CON_ : x = 510 : y = 255
110 Q_ERR_ON "WINDOW"
120 REPeat find_x : x = x+2 : WINDOW #9,x,y,0,0 : IF Q_ERR : x = x-2 : EXIT find_x
130 REPeat find_y : y = y+1 : WINDOW #9,x,y,0,0 : IF Q_ERR : y = y-1 : EXIT find_y
140 Q_ERR_OFF "WINDOW"
150 CLOSE #9
160 PRINT #0,"SCR_XLIM = "; x !! "SCR_YLIM = "; y
170 PAUSE -1

This sortof is how The Editor, for example, detects screen size. It's probably the only way to do it without PE, but creates quite a bit of flickering. From there and the bytes/scanline figure from a CDB, you can "guess" the color depth.

Tobias

[RalfR]

Just to see, how complicated it is, to see the screen limits without IOP.FLIM.

[dilwyn]

Attached is a short basic extensions file with two functions, SCRXLIM and SCRYLIM to return screen width and height respectively. Names one character different to SMSQ/E to distinguish.

PRINT SCRXLIM(#channel) returns width
PRINT SCRYLIM(#channel) returns height

Lifted out of my display_cde files, it's not quite what Ralf wants as it expects a channel number - give it the channel number of the job's primary channel to get screen sizes (#0 for Basic), otherwise it returns the outline if you give a secondary channel number.

If there is no iop.flim (QDOS without pointer environment) it just returns 512x256 by default, which will suffice in most cases apart from uQLx and possibly QDOS Classic.

To work more like the SMSQ/E (without needing a channel) it will need to be modified to open an implicit primary channel and get its channel ID. Haven't got time to go further with it, hopefully someone can use it as a starting point and alter it e.g. by looking at the SMSQ/E sources.

scrxlim.zip

[RalfR]

The best solution would be, if someone (or Dilwyn... )writes a little MC extension with two keywords using IOP.FLIM, so that can be put into QLiberator and then it is compatible with every system using a PE. As SCR_XLIM/SCR_YLIM is SMSQ/E specific, it is best to have them separate.

I think, the rest of the QL World (without PE) can stick with QLiberator as before.

[dilwyn]

The best solution would be, if someone (or Dilwyn... )writes a little MC extension with two keywords using IOP.FLIM, so that can be put into QLiberator and then it is compatible with every system using a PE. As SCR_XLIM/SCR_YLIM is SMSQ/E specific, it is best to have them separate.

I think, the rest of the QL World (without PE) can stick with QLiberator as before.

For what it's worth, Ralf, you would be very welcome to include my little extension in your QLiberator (modified or not) if you consider suitable and it meets your needs. Like the Display_Code they were taken from, these extensions are freeware and may be used without restriction in programs. Can be linked to compiled program with $$asmb=flp1_scrxlim_cde,0,10

I changed the name from SCR_XLIM and SCR_YLIM to SCRXLIM and SCRYLIM to avoid name clash with SBASIC.

[JonS]

If the intention is to release the sources, surely it can be left up to individuals to add such changes if they require them?

[EmmBee]

If the intention is to release the sources, surely it can be left up to individuals to add such changes if they require them?

Yes I do hope so. There must be a great many readers who are eagerly awaiting to see the source of QLiberator. How about it, Martin? Even if there are some problems with it, the source would be good to see. And we can all work together to make further progress and make suggestions of how to cure existing bugs, etc.

About the version number. I would propose we start with a completely new 4.00 version. So the first version could be numbered 4.01

I believe our first task will be to try to understand how QLiberator works - and to change variable names and proc/fn names to more humanly readable ones.
This might be easier said than done. It might take us a long time.

[Derek_Stewart]

Hi,

Maybe a GIT Hub project would be the best solution here so that changes and updates can be tracked.

[Martin_Head]

There must be a great many readers who are eagerly awaiting to see the source of QLiberator. How about it, Martin? Even if there are some problems with it, the source would be good to see. And we can all work together to make further progress and make suggestions of how to cure existing bugs, etc.

The intension is to release publicly, when I am as happy as I can be that it is a good decompile, without any added problems.

Marcel Kilgus is working on disassembling the machine code parts of QLiberator. I have not spoken to him yet, as to whether we should release a complete QLiberator source package. Or if I should release the SuperBASIC sources separately.