This might have gone unnoticed with all the news, but contained in the lastest SMSQ/E source code is a new version of the PE for QLs: https://www.kilgus.net/smsqe/pe/
The new PTR_GEN hopefully fixes the remaining problems/crashes of my strain of the SMSQ/E based PTR_GEN versions. Sorry it took so long! It should be very stable, I tested it on real hardware.
It now also contains native support for QemuLator's mouse, so the MacMouse extension is not needed anymore with it! It's only 60 additional bytes or so, but it makes development of the PE much easier for me.
With the new WMAN I just tried to reign in the size a bit once more (17kb vs 20kb). It's been a while, but I think I got rid of the config block for example, functionality wise it's the same.
We have one pending submission from HAOUI for WMAN that actually fully implements the WM.INDEX call. I'm of two hearts on this one, on one hand I'm really grateful that somebody other than Wolfgang or me submits code for the PE, on the other hand there is currently no use case for it. Especially for the QL version where I try to save as many bytes as possible the additional unused code would bother me right now. Not so much on SMSQ/E.
Anyway with this release out of the way we can have a closer look at least. Any thoughts about it here? Somebody interested or has an application for it in mind?
To be honest, and no disrespect to HAOUI intended, I think it's probably too late now. There are no programs that need WM.INDEX given its absence for so many years.
I don't have a need for it -- unless I was to write a PE Spreadsheet perhaps!
I respect HAOUI for the work done, but, I think the effort might have been wasted.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
mk79 wrote:This might have gone unnoticed with all the news, but contained in the lastest SMSQ/E source code is a new version of the PE for QLs: https://www.kilgus.net/smsqe/pe/
The new PTR_GEN hopefully fixes the remaining problems/crashes of my strain of the SMSQ/E based PTR_GEN versions. Sorry it took so long! It should be very stable, I tested it on real hardware.
It now also contains native support for QemuLator's mouse, so the MacMouse extension is not needed anymore with it! It's only 60 additional bytes or so, but it makes development of the PE much easier for me.
I guess I should think about adding some mouse support to sQLux (currently it pokes value into memory)
mk79 wrote:<>
We have one pending submission from HAOUI for WMAN that actually fully implements the WM.INDEX call. I'm of two hearts on this one, on one hand I'm really grateful that somebody other than Wolfgang or me submits code for the PE, on the other hand there is currently no use case for it. Especially for the QL version where I try to save as many bytes as possible the additional unused code would bother me right now. Not so much on SMSQ/E.
I have occasionally wished it were available, but then either found a workaround or done without. Im used to be without now, so..
I agree with the desire to keep things compact - who knows what other goodies may be fitted in the freed up space!
Could it be made into an optional add-on, like a toolkit extension? Best of both worlds if thatd be possible..
Per
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen
We have one pending submission from HAOUI for WMAN that actually fully implements the WM.INDEX call. I'm of two hearts on this one, on one hand I'm really grateful that somebody other than Wolfgang or me submits code for the PE, on the other hand there is currently no use case for it.
...
To be honest, and no disrespect to HAOUI intended, I think it's probably too late now. There are no programs that need WM.INDEX given its absence for so many years.
Well I don’t get it, if the feature was not implemented then it is normal there is no program using it. If it is included then future development might use it. I am sure it is not the first time a new feature is implemented in the PE with no previous need. I find it sad that someone takes the time to implement something that end up discarded so fast. However I get the “no more space on bbQL” argument. So how big is the WM.INDEX implementation ? Marcel just saved 3kb in WMAN...
XorA wrote:Just my dislike as a software person for writing values into other tasks data structures directly
I feel your pain and QPC never did this for that reason, writing into structures is always done on the 68k side of things. But then it's basically impossible for the offsets to ever change, so "never change a running system" can equally be applied here
We have one pending submission from HAOUI for WMAN that actually fully implements the WM.INDEX call. I'm of two hearts on this one, on one hand I'm really grateful that somebody other than Wolfgang or me submits code for the PE, on the other hand there is currently no use case for it.
...
To be honest, and no disrespect to HAOUI intended, I think it's probably too late now. There are no programs that need WM.INDEX given its absence for so many years.
Well I don’t get it, if the feature was not implemented then it is normal there is no program using it. If it is included then future development might use it. I am sure it is not the first time a new feature is implemented in the PE with no previous need. I find it sad that someone takes the time to implement something that end up discarded so fast. However I get the “no more space on bbQL” argument. So how big is the WM.INDEX implementation ? Marcel just saved 3kb in WMAN...
Just my 2 cents.
Factually the overhead is exactly 236 bytes for wman and 4 bytes for Qptr after having fixed a couple of serious bugs corrupting the window data definition. The feature could be turned off (default) or on by flag either from basic+Qptr program or assembler program.
This was my challenge but we could hopefully live without it and no stress for anyone.
End of the story.
Alain
I guess it's a documented feature (QPTR guide etc), so purely in that respect it should be included. But I do take the point that it's rarely if ever been used.
Alain, do you have a specific need for it in software, or is it just that you have spotted the problem and wish to get it fixed?
