QLiberator decompiler

[mk79]

It makes me think this list come from the SuperBASIC name list on the machine you compile on. (or at least the one that the _wrk file is created on) So to have any chance of getting an exact copy, I would need to know what operating system and version was used originally. But I'm a bit surprised that compiling under QDOS (JS ROM) and SMSQ/E gives the same name list order.

You've certainly loaded TK2, which overwrites many of the operating system keywords. And TK2 was the base for the SBASIC keywords, so all keywords have the same order! It's actually pretty difficult to find some keywords that exist on both SMSQ/E and QDOS(+TK2) and that do not have the same order. I managed to find one example:

Code: Select all

100 LRESPR "test"
110 TK2_EXT

For me this results in "LRESPR, TK2_EXT" on QDOS and "TK2_EXT, LRESPR" on SMSQ/E.

Keep in mind that EXTRAS on QDOS does not list keywords in the OS area, while SMSQ/E's EXTRAS does (I changed that 20 years ago as on SMSQ/E any keyword can end up in the OS area), so the lists are a bit difficult to compare.

Marcel

[mk79]

On second thought, loading TK2 IIRC does not change the name list order even when it overwrites keywords. The fact remains that SMSQ/E has basically the same keyword order as e.g. JS. I could guess that this was probably done as a compatibility thing, there might be software out there that expects the third keyword to be STOP or whatever.
QLiberator expects certain things at certain addresses, too, so both Minerva and SMSQ/E has extra code just to make QLiberator happy...

Cheers, Marcel

[RalfR]

QLiberator expects certain things at certain addresses, too, so both Minerva and SMSQ/E has extra code just to make QLiberator happy...

I always thought, that was only a problem with the original QLOAD/QSAVE.

Do you know more details?

[EmmBee]

It makes me think this list come from the SuperBASIC name list on the machine you compile on. (or at least the one that the _wrk file is created on) So to have any chance of getting an exact copy, I would need to know what operating system and version was used originally.

http://www.dilwyn.me.uk/qlib/Q_Liberato ... manual.pdf
I've been looking in the manual, and on page 86, there is this ...

CHAPTER 15 RELEASE 3.3 ENHANCEMENTS


INTRODUCTION

When QLiberator was originally conceived, the majority of QLs were fitted with AH and JM ROMS. The later ROMS, JS and MG introduced the WHEN ERROR and WHEN variable constructs, but deficiencies in the implementation meant that they could not be used reliably although Toolkit 2 from QJUMP went some way towards correcting them. By that time we were concentrating on enhancing QLiberator to provide full compatibility with QJUMP products such as QRAM and HOTKEY 2 and to provide the valuable facility of external procedures and functions.

The emergence of MINERVA prompted us to revisit Q-Liberator to provide support for its dual screen mode feature and to add some enhancements we had long planned. At the sane time we have implemented WHEN error and WHEN variable as they work consistently with that ROM. The result is QLiberator Release 3.3.

So, its MINERVA which was the last compiled version from QLiberator. Q-emuLator has Minerva installed...

[RalfR]

To clarify it: The namelist in an _obj program just contain the commands/keywords, which are used in this program and the sequence is independently from the usage in the program. It is of course possible that it is the sequence in the OS:

Testprogbas.JPG (27.09 KiB) Viewed 2222 times

[Martin_Head]

So, its MINERVA which was the last compiled version from QLiberator. Q-emuLator has Minerva installed...

Not necessarily. I think without checking, All the WHEN ERRor stuff is handled by the Qliberator runtime module. I have wondered about Minerva being used to do the compile on. But I don't know if I fancy another two hour compile, just to find out.

I think I may stop wasting time on trying to get an exact copy at the moment. And try throwing some largish BASIC programs at the recompiled version so see if there are any obvious problems, and maybe compare the created object files with the same program compiled on the original QLiberator.

[RalfR]

Martin was so kind to send his QLiberator source to me. It is easy to make it moving to the whole screen (if that is needed), I can use the SMSQ/E keywords for that, but then it is only running on SMSQ/E. But QLiberator should run on every platform. I do not know, if there are platforms with greater sizes without PE beside old C and D drivers for Atari.

I can assume, that every resolution bigger than 512x256 has a PE running (hopefully). That seems to be the safest thing. What I need, is a little ASM extension for SCRXLIM/SCRYLIM to give the sizes to me.

If anyone can do this, that would be helpful to make a QLib v3.36a.

[tofro]

It is actually pretty hard (if not impossible) to detect SCR_XLIM and SCR_YLIM without the PE in plain QDOS.
You can detect the length of a scan line in bytes from channel definition blocks, but I neither know a portable way to detect the color depth (i.e. translates that into actual pixels) nor the amount of available scan lines (i.e SCR_YLIM).

If you simply assume "It doesn't have PE, and we're in MODE 4 or 8, so we have 512x256", you will miss all platforms that support higher resolutions in these modes. (That is, QDOS Classic and uQLX, provided there is no PE).

With PE loaded, it's an easy call to iop.flim.

Tobias

[RalfR]

Yes, I know, QDOS does not give any things to detect the screen limits and the easiest way is IOP.FLIM.. So, I have no idea to realise this. QLIberator should work on every platform, the easiest way is to assume, if no PE is present, 512x265 is ok. I can't find another way.

MODE 8 ist detected in QLiberator and switched to MODE 4. They use a self written (or TT made ) RMODE to detect this. There seem to be very, very equalities to QPTR.

But I still need SCR_XLIM and SCR_YLIM as separate extension.

[EmmBee]

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