QLiberator decompiler

Anything QL Software or Programming Related.
User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 12, 2020 3:32 pm

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.


User avatar
tofro
QL Wafer Drive
Posts: 1794
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QLiberator decompiler

Postby tofro » Sun Jan 12, 2020 4:54 pm

EmmBee wrote: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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 12, 2020 5:14 pm

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


User avatar
dilwyn
Mr QL
Posts: 1568
Joined: Wed Dec 01, 2010 10:39 pm
Location: Wales
Contact:

Re: QLiberator decompiler

Postby dilwyn » Sun Jan 12, 2020 7:49 pm

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
(2.64 KiB) Downloaded 10 times


Dilwyn
All things QL: see www.dilwyn.me.uk
User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Mon Jan 13, 2020 10:37 am

The best solution would be, if someone (or Dilwyn... :D )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.


User avatar
dilwyn
Mr QL
Posts: 1568
Joined: Wed Dec 01, 2010 10:39 pm
Location: Wales
Contact:

Re: QLiberator decompiler

Postby dilwyn » Mon Jan 13, 2020 6:01 pm

Ralf R. wrote:The best solution would be, if someone (or Dilwyn... :D )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.


Dilwyn
All things QL: see www.dilwyn.me.uk
User avatar
JonS
Chuggy Microdrive
Posts: 69
Joined: Fri Nov 11, 2011 3:54 pm
Location: Cumbria

Re: QLiberator decompiler

Postby JonS » Mon Jan 13, 2020 10:33 pm

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
Trump Card
Posts: 158
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: QLiberator decompiler

Postby EmmBee » Mon Jan 13, 2020 11:17 pm

JonS wrote: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
QL Wafer Drive
Posts: 1605
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: QLiberator decompiler

Postby Derek_Stewart » Mon Jan 13, 2020 11:23 pm

Hi,

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


Regards,

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

Re: QLiberator decompiler

Postby Martin_Head » Tue Jan 14, 2020 11:24 am

EmmBee wrote: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.



Who is online

Users browsing this forum: No registered users and 4 guests