Graphics program for SMSQ/E

Helpful tips and guides, also new users can ask for help here.
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Graphics program for SMSQ/E

Post by Martin_Head »

Derek_Stewart wrote:Hi,

I will have a look at decompling Qdesign, I not done decompilation before, maybe time learn...
Yesterday, Out of interest I tried throwing the 4 Qliberated Qdesign files at the decompiler.
It was not too happy about any of them.

The Qsnap program, breaks my 6 byte float conversion routine, of mantissa*(2^(exponent-$81F)). It tries to do 2^-2073, and SMSQ/E can't handle it.
First time I've ever hit this problem.

The six bytes are $000640A24E92 I tried a quick patch of my routine replacing the 2^ with a loop and got an answer of -1.123959E12

But trying the calculation with the calculator in Windows I get 9.999E-616 I don't know which is right.

And I've no idea why the Qsnap program need such a small number. [edit] or is it a big number?


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Graphics program for SMSQ/E

Post by mk79 »

Martin_Head wrote:Yesterday, Out of interest I tried throwing the 4 Qliberated Qdesign files at the decompiler.
Cool, thanks!
The Qsnap program, breaks my 6 byte float conversion routine, of mantissa*(2^(exponent-$81F)). It tries to do 2^-2073, and SMSQ/E can't handle it.
Interesting. In these extreme value ranges it matters in principle which platform you use, because all have different floating point codes. The QL format is a bit problematic because it has much less precision than the PC formats but a larger exponent range than the standard "double" data type. This is the reason why the FPU code was the only remaining assembler code in QPC, because I use the exotic 80-bit floating point data type which can encompass the range... but this data type cannot be used in MS C! SMSQmulator falls back to the slower native SMSQ/E code in this case.

But a quick test revealed that all platforms seem to have a problem with it.

Question: why don't you just use PEEK_F?
And I've no idea why the Qsnap program need such a small number. [edit] or is it a big number?
Very near to zero ;) Can't really imagine a scenario where one would need this value.


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Graphics program for SMSQ/E

Post by Martin_Head »

mk79 wrote:Question: why don't you just use PEEK_F?
I don't know, I can't remember if I even thought about it. But I use the same conversion routine in all the decompilier versions. So I will need to fix it in all of them.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Graphics program for SMSQ/E

Post by janbredenbeek »

Martin_Head wrote:
Derek_Stewart wrote:Hi,
The Qsnap program, breaks my 6 byte float conversion routine, of mantissa*(2^(exponent-$81F)). It tries to do 2^-2073, and SMSQ/E can't handle it.
First time I've ever hit this problem.

The six bytes are $000640A24E92 I tried a quick patch of my routine replacing the 2^ with a loop and got an answer of -1.123959E12

But trying the calculation with the calculator in Windows I get 9.999E-616 I don't know which is right.
The QL FP system can only handle 2^-2048 (represented as $0001 4000 0000) to 2^2047 (represented as $0FFF 7FFF FFFF). The stored exponent must be in range 1 to 4095 (with offset 2048, less is interpreted as negative) and the mantissa normalised to be in range $40000000 to $7FFFFFFF (for positive numbers) or $FFFFFFFF to $80000000 (for negative numbers). A zero is represented as six zero bytes.

The calculation mantissa*2^(exponent-$81F) is correct but neglects the fact that the mantissa is not a 32 bit integer, but in fact a normalised floating point number between 0.5 and (nearly) 1. Hence the exponent offset by $81F to compensate for that, but in your case it leads to overflow since 2^-2073 cannot be stored in the QL FP format.

If you do the calculation using (mantissa/2^31)*2^(exponent-$800), this yields 1E-615 so the Windows calculator is correct (short of rounding errors).

Jan


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Graphics program for SMSQ/E

Post by Martin_Head »

janbredenbeek wrote:If you do the calculation using (mantissa/2^31)*2^(exponent-$800), this yields 1E-615 so the Windows calculator is correct (short of rounding errors).
I will give this a try.
Is this formula good for all 6 bytes floats? Or just the extreme values.

I have patched in PEEK_F by poking the values into memory, then using PEEK_F to get the number. And this returns 1E-615
I have not just PEEK_F'd the compiled program directly, as I also have to deal with 4 byte floats. Where the last two bytes of the 6 byte float are assumed to be 0.

Going past this problem. I've hit a snag with the decompiler with TO in SELect.
It's fine with things like, ON y=1 TO 10. But gets upset with expressions in TO like, ON y=12^2 TO (24^2)+1.
I noticed in my documentation, I commented that "SELect is a bit of a problem area"


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Graphics program for SMSQ/E

Post by mk79 »

Martin_Head wrote:It's fine with things like, ON y=1 TO 10. But gets upset with expressions in TO like, ON y=12^2 TO (24^2)+1.
Wow, who would do anything like this :shock:
I noticed in my documentation, I commented that "SELect is a bit of a problem area"
Isn't it all ;)

I have already decoded large parts of the assembler extension for fun and no profit. If there is any _PIC compression going on it seems to be hidden in the basic parts.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Graphics program for SMSQ/E

Post by janbredenbeek »

Martin_Head wrote:
janbredenbeek wrote:If you do the calculation using (mantissa/2^31)*2^(exponent-$800), this yields 1E-615 so the Windows calculator is correct (short of rounding errors).
I will give this a try.
Is this formula good for all 6 bytes floats? Or just the extreme values.
It works for any float, even the smallest ones. I tried using 2^-2048/2^28, which yields $0000000a96f2 and prints as 9.999994e-621. It looks like that you can create floats smaller than 2^-2048 in this way, yielding zero exponent and non-normalised mantissa. Entering 2^-2048/2^29 yielded zero though, and trying 2^-2049 throws an overflow error (at least on QPC2).

Fun fact: Minerva allows you to enter numbers as small as 2^-2079, which is 1.440917E-626!

Jan


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Graphics program for SMSQ/E

Post by Martin_Head »

mk79 wrote:I have already decoded large parts of the assembler extension for fun and no profit. If there is any _PIC compression going on it seems to be hidden in the basic parts.
All four of the 4 QLiberated QDesign files have some built in SuperBASIC extensions. I have extracted them, but not looked at them yet. The existing Delib program will extract them. Just run the program, and it will ask if you want to extract them.

I used Jan's formula, and did a bit of a rewrite of the SELect TO handling, and now three of the four programs go through the decompiler without complaint. I don't know how good the decompile is yet, but at least it does not complain.
Ran out of time for the fourth program.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Graphics program for SMSQ/E

Post by mk79 »

Martin_Head wrote:
mk79 wrote:I have already decoded large parts of the assembler extension for fun and no profit. If there is any _PIC compression going on it seems to be hidden in the basic parts.
All four of the 4 QLiberated QDesign files have some built in SuperBASIC extensions. I have extracted them, but not looked at them yet. The existing Delib program will extract them. Just run the program, and it will ask if you want to extract them.
Yeah, extracting is the easy part ;) But good to know there is a tool for it, will try that next time, I did it manually so far. But what I meant is that I have already recovered about 6000 of the 9000 lines of source code for the extension contained in the QDesign executable, symbols, comments and all. The QSnap extension seems to be a very simple subset of that. The other ones I haven't examined yet.
I used Jan's formula, and did a bit of a rewrite of the SELect TO handling, and now three of the four programs go through the decompiler without complaint. I don't know how good the decompile is yet, but at least it does not complain.
Ran out of time for the fourth program.
Sounds great, thank you!


User avatar
BSJR
Trump Card
Posts: 182
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: Graphics program for SMSQ/E

Post by BSJR »

mk79 wrote:I have already decoded large parts of the assembler extension for fun and no profit. If there is any _PIC compression going on it seems to be hidden in the basic parts.
Among the Extra keywords you mentioned before I found S_SAVE & S_LOAD which are also part of a Quanta Lib SCREEN routine by Ron Dwight, to compress mode 4 & 8 screens and works with a 16 colour words table.
Maybe an adaptation was used to accommodate for the 1-bit monochrome mode. So far I have not got my head around how the original exactly works though.

BSJR


Post Reply