QLMultimon - source question

[NormanDunbar]

I've done a pull request with my changes, you should be able to merge it into your own source tree.

Much obliged, thank. I'll get that done as soon as I can. Christmas shopping apparently has higher priorities!

[NormanDunbar]

Hi Jan,

Patch1 has been merged. I had a couple if conflicts to sort out, but I got there in the end.

Cheers,
Norm.

[NormanDunbar]

Hi Jan,

I have finished (unless you have more correction) the commenting of MON1_ASM now, I think. I've raised a pull request for you to fetch the latest code back into your repository. Github says that it will merge quite happily.

I've also raised three issues (sorry!) as follows:

Enhancement: the V command lists jobs as suspended when they have a non-zero JB_STAT. A -2 is a waiting job (could print a W), -1 is suspended (S) while zero is active. There is also a >0 value which might need to be ignored or handled as well. (I've forgotten what it indicates at the moment!)

Bug?: The F command, to search for hex text never starts searching from the current memory pointer, it always starts at the next address due to the code at the top of the loop incrementing A3 - I think a decrement of A3 is required just before FH_LOOP and just after FH_MEM to fix this.

Bug/Enhancement: The V command shows the total retrieved by MT_FREE but if this is over 60M then it goes negative. I think a test of the top bit of D1.W is required after the divide by 1024, and if set, another divide by 1024 is desired to show MB rather than KB. That should prevent the negatives.

I'd quite happily create a patch, but at the moment, I cannot find my QMAC assembly/link manual (will be checking with Dilwyn's site later) so that I can assemble and link the two files to test, I've been using GWAS[L] for far too long and never had to use linking. I'm getting too old to remember stuff these days!


Cheers,
Norm

[NormanDunbar]

I'd quite happily create a patch, but at the moment, I cannot find my QMAC assembly/link manual (will be checking with Dilwyn's site later) so that I can assemble and link the two files to test, I've been using GWAS[L] for far too long and never had to use linking. I'm getting too old to remember stuff these days!

Consider the manuals found - thanks Dilwyn, read and digested. I have assembled QL-MULTIMON and it is, for some strange reason, 2 bytes larger than before - possibly because I default to long BRSs in QMAC, perhaps. Anyway it failed to run and when I checked with the original, I found that I have managed to set the number of channels to open at startup to 7 rather than 6. I don't know how that happened - other than a fat fingered typist I(me!) - fixed in master branch.

I have also created three branches - issue_2, issue_3 and issue_4 to fix (or enhance) the code for the issues I logged the other day. All have been tested and work fine. These are:

Issue_2: Search never starts from the current memory pointer when a new search text is entered, it always starts one byte further up in RAM. I fixed this by loading MEMPTR(A6),A3 then decrementing A3 if we had a new search text entered, then jumping to FH_LOOP, rather than the FH_MEM label. This now works for new searches and existing ones.

Issue_3: MT_FREE goes negative when there is at least 32M of free memory left (D1 = $8000 and UT_MINT prints this as negative due to bit 15 being set). This is fixed by dividing by 1024 again if bit 15 is set, and using 'M' instead of 'K'.

Issue_4: I 'enhanced' the V command to show suspended jobs as 'S' only when JB_STAT was -1, Waiting jobs get a 'W' when JB_STAT is -2 and all others get the existing space - for active and delayed until rescheduled (zero or +ve in JB_STAT).

I've raised separate pull requests for each of the above so that you can check before merging.

Cheers,
Norm.

[janbredenbeek]

Hi Norman,

I have finished (unless you have more correction) the commenting of MON1_ASM now, I think. I've raised a pull request for you to fetch the latest code back into your repository. Github says that it will merge quite happily.

Thanks, I've merged them.

I've also raised three issues (sorry!) as follows:

Enhancement: the V command lists jobs as suspended when they have a non-zero JB_STAT. A -2 is a waiting job (could print a W), -1 is suspended (S) while zero is active. There is also a >0 value which might need to be ignored or handled as well. (I've forgotten what it indicates at the moment!)

A JB_STAT value >0 means it has been suspended that number of frame interrupts - it gets decremented every 20 ms.

Bug?: The F command, to search for hex text never starts searching from the current memory pointer, it always starts at the next address due to the code at the top of the loop incrementing A3 - I think a decrement of A3 is required just before FH_LOOP and just after FH_MEM to fix this.

IIRC this was intended - when searching repeatedly for a string you can just re-issue the S command (not F - that's for filling memory ) and it will start searching from the next memory location. If it would start from the current location you would end up there every time. (maybe a 'find next' command would solve that).

Bug/Enhancement: The V command shows the total retrieved by MT_FREE but if this is over 60M then it goes negative. I think a test of the top bit of D1.W is required after the divide by 1024, and if set, another divide by 1024 is desired to show MB rather than KB. That should prevent the negatives.

Who on earth needs 60MB of RAM on a QL?
- Edit - When I set QPC2 to use 96MB RAM, it says I have about 29M free. Looks like you should do a CMP.L #32768,D1 instead of just testing bit 15

I'd quite happily create a patch, but at the moment, I cannot find my QMAC assembly/link manual (will be checking with Dilwyn's site later) so that I can assemble and link the two files to test, I've been using GWAS[L] for far too long and never had to use linking. I'm getting too old to remember stuff these days!

I have QMAC and LINK ready on my QPC setup, I'll give it a try when I have time. We could start numbering this version from 2.2 onwards. I have an unpublished version of MON1_ASM with many modifications added since 1988(!) which I never completed to an assembled version; I'll try to merge your commented version manually with my mods so I could possibly produce a version 3.x branch...

regards, Jan.

[janbredenbeek]

Update - the binary is now available at https://github.com/janbredenbeek/QL-Mul ... MMON22.ZIP

regards, Jan.

[NormanDunbar]

Hmm, I can't type! When I said 60M free I really meant 32 of course, $8000 kb.

The F instead of S too, I did intend to type S. Sigh. Anyway, I tested my fix and it works fine on the first search for some text, or on subsequent S commsnds followed by Enter. No need for a find next now.

I wonder what else you had running in your 96 Mb set up? MT_FREE returns the biggest area of free ram in the transient memory area I believe (from Pennell) so maybe you had some fragmentation in there perhaps?

For UT_MINT, anything over $7fff is deemed negative so testing just bit 15 should be ok, unless of course someone is running with 32 gb free!

Cheers,
Norm.

PS. This has been a fun way to while away the hours!

[janbredenbeek]

I wonder what else you had running in your 96 Mb set up? MT_FREE returns the biggest area of free ram in the transient memory area I believe (from Pennell) so maybe you had some fragmentation in there perhaps?

According to Pennell MT.FREE returns the largest free area in TRNSP or SV.BASIC-SV.FREE-$200, whichever is greater.

For UT_MINT, anything over $7fff is deemed negative so testing just bit 15 should be ok, unless of course someone is running with 32 gb free!

If MT.FREE returns more than 64MB then division by 1024 yields a number > 65535. Bit 15 will be zero but UT_MINT only works on the lower 16 bits so will print 32000something K when you have 96MB free. Thus you should do a long compare and do another division by 1024 when D1 is over 32767K.

PS. This has been a fun way to while away the hours!

regards, Jan.

[NormanDunbar]

I sit corrected!

Cheers,
Norm.

[NormanDunbar]

Hi Jan,

I checked Pennell for MT_FREE - and yes, if I had read a little further down the page I would have seen that it does return the larger of the two memory amounts. Note to self: learn to read all the relevant text!

Re the V command and free megabytes, my issue_3 branch is updated again to compare D1.L with 32MB-1 and if greater to do another 1024 division - that now works correctly on 96MB systems - I tested on 128MB and got the correct answer of 124 free with the old version, which is a tad strange. Anyway, I've raised another pull request for the change.

Cheers,
Norm.