QLiberator decompiler

[RalfR]

BTW: The window MOVE takes place in "procfun34401", if someone wants to investigate, "var0388" is true, if PE is available.

Inside procfun34401: IF PE then WM_Sptr and WM_Rptr are both called, else an inkey$ loop is entered where the cursor can be moved around. When ENTER is pressed it comes out the loop and the screen is updated. I have tried this using Q-emuLator with Minerva without the PE present, and this does work. However, it appears to me that a better performance could be obtained by PANning and SCROLLing inside the inkey$ loop. Try adding these lines ...
30875 PAN #var0368, -6
30905 PAN #var0368, 6
30935 SCROLL #var0368, -10
30965 SCROLL #var0368, 10
Now, every time you hit a cursor arrow key QLiberator's front panel will move.

WM_rptr is called with "129" as snd parameter, this makes it move under PE. The problem is to make it move further than 512x256. The Move Sprite is set absolutely in the main window "var0348", I had (formerly) thought, the move window has its own window to place it.

[EmmBee]

WM_rptr is called with "129" as snd parameter, this makes it move under PE. The problem is to make it move further than 512x256. The Move Sprite is set absolutely in the main window "var0348", I had (formerly) thought, the move window has its own window to place it.

I think we have to consider this ...

Code: Select all

31150 DEFine PROCedure procFun35021
31160 IF (var03F0 < 0) THEN
31170  var03F0 = 0
31180 END IF
31190 IF (var03F0 > (512 - (var0390 + 8))) THEN
31200  var03F0 = (512 - (var0390 + 8))
31210 END IF
31220 IF (var03F8 < 0) THEN
31230  var03F8 = 0
31240 END IF
31250 IF (var03F8 > (256 - (var0398 + 8))) THEN
31260  var03F8 = (256 - (var0398 + 8))
31270 END IF
31280 END DEFine procFun35021 

The above apparently checks the limits. Perhaps all occurences of 512 and 256 need to be replaced with SCR_XLIM and SCR_YLIM

[RalfR]

Just try it, you're welcome But that alone doesn't work (in that procfun). The main problem is, that they do not set global variables for the use of the screen sizes even though bigger ones existed in the Atari drivers during the development of QLiberator.

[EmmBee]

I have just done this ..

Now I will try to do a byte by byte comparison ...

[RalfR]

Oh, 3 seconds compared to Martin 's 2 hours with Qemulator? Can't understand this. What's about those Turbo lines? You should use a clean OS, without any extensions.

[mk79]

Perhaps, we will sometimes understand, how QLiberater and its runtimes manages this (if someone disassembles the runtimes and can really understand, how it all works).

I do know the code. You only get the line number if the "LINES" option is enabled. You only get the statement number if the "TRACE" option is enabled. No other way around it.

Marcel

[Martin_Head]

Oh, 3 seconds compared to Martin 's 2 hours with Qemulator? Can't understand this. What's about those Turbo lines? You should use a clean OS, without any extensions.

I only have the unregistered Qemulator. So only normal QL speed, and so no floppy disk images, or QXL.WIN file support. And I was using my FDI driver to access floppy disk images.

I don't usually use Qemulator, or QLiberator. The only speed references I have are the test programs I wrote for developing the decompiler. So maybe my set up with the FDI driver causes very slow disk access in Qemulator.

If I ever try to recompile in Qemulator again, I may try not using the FDI driver.

[EmmBee]

I have been doing some work on renaming variables and proc/fn names in the new decompiled QLIB_BAS source. The idea is to make it all readable and understandable. I'm not altering the code in any way, just doing the renaming. So far I have renamed about 80 out of 400. This is all a guessing game, trying to fathom out what is going on.

To help me further, it would be very useful to have a list of machine code routines, each with a brief description of what they do, along with details of their parameters. There is a routine called NEXT_TOKEN, with 5 parameters. This appears to be the equivalent of Turbo Parser's Getsym procedure, but I am not sure.

[RalfR]

I have been doing some work on renaming variables and proc/fn names in the new decompiled QLIB_BAS source. The idea is to make it all readable and understandable. I'm not altering the code in any way, just doing the renaming. So far I have renamed about 80 out of 400. This is all a guessing game, trying to fathom out what is going on.

To help me further, it would be very useful to have a list of machine code routines, each with a brief description of what they do, along with details of their parameters. There is a routine called NEXT_TOKEN, with 5 parameters. This appears to be the equivalent of Turbo Parser's Getsym procedure, but I am not sure.

Thank you so much. About the MC extensions, perhaps Marcel can give you a few hints. A few dissassembled ones will be found elsewhere in this thread.

[Martin_Head]

Back to Disk Mate 5. I got a bit side tracked, and forgot that I had not posted the decompiled sources for Disk Mate 5.

The zip file contains the original Disk Mate 5.10 source, and my version 5.11 which has the reference to the FileInfo 2 command 'FEX' changed to FI2_CALL.
And so need s FileInfo 2, version 3.50 or above.
Also the date checking on startup has been increased to January 2029. There are problems with the QL function 'DATE' after this date, which makes it go to a negative number. This causes at least one problem with Disk Mate 5.

See the document for some more details.

There is also a floppy disk image with all the extension files required.

There are still a few things I have noticed that could do with looking at in DM5. The DATE issue needs looking into. When in high colour mode, the 'un-selectable' things are the wrong colour. And I think I saw a menu item that was not in English. I don't know when, and if I can get around to these things. But if anyone wants to try...

I have also included a copy of the DM5 manual in Open Document, and PDF formats. The main body of the manual is unchanged, but I have added the (updated) version history on the end.