Andy Pennell's books.

[pjw]

Although I have the latest Apache OO it crashes regularly, and on "restoring" the document I find that some of the changes I made have reverted, while others stuck, wasting me a lot of precious time and leaving me confused and even more !

Not related to the editing, but Apache OO is a dead project, LibreOffice is where actual development of the codebase happens!

Ok, thanks.This version was released in May 2022, so I assumed it was reasonably up to date. Ive switched to Libre Office now. Hopefully that will do better.

[Derek_Stewart]

Hi,

I tried Open Office, but it just does not work as good as Libre Office.

To save any issues of learning how to use Libre Office, just make a list i an ASCII text file with the page number and the change to be made.

I did wonder about the absolute addresses of System Variables, Traps, Vectors, etc ... is a good idea, but that is the style of the book, whether this correct or not is debatable.

We can spend many hours correcting the book, to end up with another QL Technical Manual.

One point about Mnemonics, is there a standard, as referring to the QL Technical Manual, where all Traps, Vectors use a dot separator and Systems Variables use a dash separator, Basic Channel definitions use dot separator, Job Header definitions use a underscore separator, then there is Micrdrive double dot separators.

Looks a little dis-organised, but I suppose it must work.

[pjw]

Hi,

I tried Open Office, but it just does not work as good as Libre Office.

To save any issues of learning how to use Libre Office, just make a list i an ASCII text file with the page number and the change to be made.

Ive already spent some time making changes, so unless youre happy to throw away my work, I suggest you wait with updating until you get the document back from me.. I seem to recall that google docs could be worked on collaboratively, but its a bit late for that.

I did wonder about the absolute addresses of System Variables, Traps, Vectors, etc ... is a good idea, but that is the style of the book, whether this correct or not is debatable.

Please include me out of any debate on the matter

We can spend many hours correcting the book, to end up with another QL Technical Manual.

More or, possibly, less, yes.

One point about Mnemonics, is there a standard, as referring to the QL Technical Manual, where all Traps, Vectors use a dot separator and Systems Variables use a dash separator, Basic Channel definitions use dot separator, Job Header definitions use a underscore separator, then there is Micrdrive double dot separators.

Looks a little dis-organised, but I suppose it must work.

The main difference is that xx_xxx relate to addresses and offsets, while xx.xxx are normally numbers/values. The xx..xxx mnemonics usually relate to sub-values, like bit numbers. It does help that you know what order of value you are dealing with. (Im sure there are technical terms for all this, but Im not a pro. Sorry).

[Derek_Stewart]

Hi Per,

The idea of using Github was to allow multiple authors to make changes to the document.

But just save the file here and I will update Github.

[NormanDunbar]

You don't say whether your findings apply to .., JM, JS, Minerva, SMSQ/E etc. It could, in other words
just be random.

Well, today I had a few minutes -- but that turned into hours -- to try and test this out as best as I could. I brief, the results are: There are indeed slight differences between QDOS:JS and SMSQ/E.

SMSQ/E seems to take an extra 2 bytes over the space used on the maths stack for the use of the expression so far.

Code: Select all

x%=1234
x=1234.0
x$="1234"
:
PRINT x% + myFunct(...)
PRINT x + myFunct(...)
PRINT x$ + myFunct(...)


For integer * function, it's 4 bytes as A1 is -4. ($FFFFFFFC)

For float * function, it's 8 bytes as A1 is -8. ($FFFFFFF8)

For string * function, it's 6 bytes as A1 is -6. ($FFFFFFFA)

I was unable to recreate a test that would give me a positive value in A1 at the start of the code, other than zero, so I have no valid results for that.

In case anyone was interested!

Cheers,
Norm.

[pjw]

<>
In case anyone was interested!

It was worth a try, although in this instance I dont think anything of use was found. You can gain almost any kind of information about parameters and the like using documented means that will be replicated across the board, and in all likelihood, barring a major re-imagining, like SuxBASIC , any future updates.

[NormanDunbar]

It was worth a try, although in this instance I don't think anything of use was found.

I disagree!

I found that QDOS:JS differs slightly from SMSQ/E so that's something learned.

I also found that it is still the case, and contrary to the QDOS books, that A1 is not pointing anywhere near the Maths Stack on entry to a procedure or function.

So, while my original investigations into the QDOS:JS "problem" way back when, things have moved on and the advice (or findings) pretty much no longer apply in any usable format. I feel an update to the eBook coming on.

Thanks for making me look into this again.


Cheers,
Norm.

[pjw]

It was worth a try, although in this instance I don't think anything of use was found.

I disagree! <>

I didnt mean it in that way, just that I cant think of anything to use the technique for, particularly now you have demonstrated that it is not universal.

<>
I also found that it is still the case, and contrary to the QDOS books, that A1 is not pointing anywhere near the Maths Stack on entry to a procedure or function.

I had a quick scan through Adrian Dickens' "Advanced QL User Guide", which I grew up with. I noticed a few possible myths, but not that one. As you know, once one has called one of the get parameter routines, A1 does indeed point to the last item fetched on the stack. I guess thats how the misunderstanding arose as, after all, that is normally one of the first things one wants to do.

So, while my original investigations into the QDOS:JS "problem" way back when, things have moved on and the advice (or findings) pretty much no longer apply in any usable format. I feel an update to the eBook coming on.

Thanks for making me look into this again.

Keep 'em coming, Norm!

[NormanDunbar]

I didnt mean it in that way, just that I cant think of anything to use the technique for, particularly now you have demonstrated that it is not universal.

No worries Per, I know you didn't. In my original write up, I couldn't think of a good use for my findings either. I just documented what I found.

Now that you made me revisit things, it's even less "useful". But at least we know.

As I said earlier, thanks for making me look into it again. In the next (exciting) issue of the Assembly Language eMagazine, I've written it up. You get a mention too!

Cheers,
Norm.

[pjw]

<> You get a mention too!

Aaah! Fame at last!