from:"pjwitte"


I'll post one on the forum
Per

On 08/11/2021 23:07, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

Thanks, Marcel. I arrived there by a different route, but no, it doesnt work 
for me.

OK. I'll ask if there is a Windows 11 VM I can use at work to see it
myself. I can't even find many pictures of it online.

Marcel

___
QL-Users Mailing List


___
QL-Users Mailing List

Re: [Ql-Users] Windows 11 and emulators

Hi Derek,

On 08/11/2021 16:14, Derek via Ql-Users wrote:

I used repair Windows software problems, so I can maybe help.

So did I back in the heady days of W95 and NT4 ;o)

Can the service not be disabled, or msybe removed.
I dont particularly want it removed. I need to see whats going on or
Id have to test the keyboard every time before, say, typing a password.

I have a Windows 10 Pro PC, which I could upgrade to see if Ican solve your
problem.

I wouldnt wish that on you ;o) But thanks for the offer. I see plenty
of other people are complaining, so perhaps it may get fixed without
extortion.

I guess its going to get harder and harder to workaround the
encroachment of the worst kinds of futures.. I dont see QLing on an
iPhone as a viable option..

Per

---
Regards,
Derek

On 8 November 2021 13:39:36 GMT, pjwitte via Ql-Users
wrote:

On 08/11/2021 14:11, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

I don't have Windows 11 and I find very little on the subject online.
I have no idea how I could hide the blob, but as far as I can see the
feature can be disabled, can it not?

https://www.reddit.com/r/windowsinsiders/comments/oa9e4p/windows_11_how_to_remove_input_indicator/

Sure you can turn it off, but then 50% of the time I'll be typing
half sentences and passwords in the wrong character set! (Not for
nothing do people go retro-fitting caps lock LEDs to their QLs.. But this is
worse..)

As far as I understood the posting was that the behaviour can be
reverted to the "old" one and not the floating thingie.

Marcel

Thanks, Marcel. I arrived there by a different route, but no, it
doesnt work for me.

Im now looking for the small print, where it no doubt says something
along the lines of "This feature is brought to you sponsored by the
WannaCry software team.." :oD

Per
___
QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Windows 11 and emulators


On 08/11/2021 14:11, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

I don't have Windows 11 and I find very little on the subject online.
I have no idea how I could hide the blob, but as far as I can see the
feature can be disabled, can it not?

https://www.reddit.com/r/windowsinsiders/comments/oa9e4p/windows_11_how_to_remove_input_indicator/

Sure you can turn it off, but then 50% of the time I'll be typing
half sentences and passwords in the wrong character set! (Not for
nothing do people go retro-fitting caps lock LEDs to their QLs.. But this is 
worse..)

As far as I understood the posting was that the behaviour can be
reverted to the "old" one and not the floating thingie.

Marcel

Thanks, Marcel. I arrived there by a different route, but no, it 
doesnt work for me.


Im now looking for the small print, where it no doubt says something 
along the lines of "This feature is brought to you sponsored by the 
WannaCry software team.."  :oD


Per
___
QL-Users Mailing List

Re: [Ql-Users] Windows 11 and emulators


On 08/11/2021 13:46, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

At least one of their insane "improvements" is to move the keyboard language
indicator, which was happily situated on the task bar/system tray, into its own
blob on the screen.

I don't have Windows 11 and I find very little on the subject online.
I have no idea how I could hide the blob, but as far as I can see the
feature can be disabled, can it not?

https://www.reddit.com/r/windowsinsiders/comments/oa9e4p/windows_11_how_to_remove_input_indicator/

Marcel


Sure you can turn it off, but then 50% of the time I'll be typing half 
sentences and passwords in the wrong character set! (Not for nothing 
do people go retro-fitting caps lock LEDs to their QLs.. But this is 
worse..)


Its bad enough, practically, for me, but even for Windows it seems so 
incongruous and unaesthetic. I wonder what theyre smoking back there 
at M$ HQ..


Per
___
QL-Users Mailing List

Re: [Ql-Users] Windows 11 and emulators


On 08/11/2021 10:51, François Van Emelen via Ql-Users wrote:


Op 6/11/2021 om 21:03 schreef pjwitte via Ql-Users:
Ive just "upgraded" to Windows 11, as I didnt want to get caught 
out again being <>



Hi Per,

Can't help you here as I'm still using W7. Installing QPC2 
/Smsqmulator  on a Linux machine could solve your problem( at least 
temporary). Not difficult, even I could do it.


Wolfgang and Marcel could have a look at it.

BTW: thanks for the treasures I found on Knoware.

Have  a fine day.

François Van Emelen 


Hi François,

Ive installed and used Linux many times since Red Hat V1.00 - and I 
still hate it!


I have a beautiful 12 year old MacBook Pro that used to run W7U. When 
M$ stopped supporting W7, threatening dire consequences for those who 
didnt upgrade to W10, I decided to give Linux another twirl. I tried 
numerous variants; they all missed out various vital aspects of the 
Mac hardware and BIOS, and whatever I tried, I couldnt fix it. In the 
end, the best fit was Ubuntu. (I guess I could have reverted to using 
OSX. But while OSX no doubt can handle the Mac hardware, Im pretty 
sure no SMSQ/E environment can happily co-exist with such a smug, 
solipsistic OS!)


Yes, I got QPC2 running under Wine, and SMSQmulator, of course, but 
they were clearly operating in hostile territory - you couldnt just 
forget you were running an emulator under some foreign host - all the 
host's baggage was there, barely concealed. So I bought a new laptop 
with W10, thinking Id be safe for another ten years or so.. And now this!


Thanks for your kind words on Knoware.

Per

___
QL-Users Mailing List

[Ql-Users] Windows 11 and emulators

2021-11-06 Thread pjwitte via Ql-Users

Ive just "upgraded" to Windows 11, as I didnt want to get caught out 
again being
forced into a paid upgrade - or risk being saddled with an unsupported 
older
version of Windoze. (Oh do I hate "upgrades", when all I want is for 
things to
get fixed, and incremental improvements that relate to things I 
actually find
useful!)  As usual, the wise guys at M$ have, for their own ineffable 
reasons,

re-arranged the furniture to no discernable purpose, other than, no doubt,
to leverage their colonisation of my privacy.

At least one of their insane "improvements" is to move the keyboard 
language
indicator, which was happily situated on the task bar/system tray, 
into its own
blob on the screen. I need to switch keyboard layouts as I type in 
different
languages, and not having an indicator is as bad, or worse, than not 
having a

capslock indicator. (But at least on my "QL" I can fix the latter myself!)

The problem is that *this blob shines through* in QPC2 and 
SMSQmulator's full

screen mode! (I never think of my QL as just another Windows "app"!) In
SMSQmulator its a dud, ie its not clickable, but in QPC2 the blob is 
active and
hostile. Yet the last thing one wants in an emulator is some other 
system's

active control shining through, messing up one's display where it has no
business!

Some Windows and Web movie applications in full screen mode manage to 
blot out
the blob, but others dont/cant. But that must mean that it is possible 
at least.


Any tips or suggestions as to how this may be dealt with are welcome! 
Im new to
W11, so perhaps I just havent found the way to put the indicator back 
where it
belongs - visible, but out of the way when you dont want it. (And why 
they hell

did they take away Toolbars!)

Per
___
QL-Users Mailing List

Re: [Ql-Users] QL-SD-ROM

2021-07-14 Thread pjwitte via Ql-Users


On 11/07/2021 19:23, Dilwyn Jones via Ql-Users wrote:

I've written a review of Marcel Kilgus's forthcoming QL-SD-ROM add-on
hardware for the Sinclair QL on my blog at
https://dilwyn2.wordpress.com/2021/07/11/ql-sd-rom/


Ingenious little product! If I had a QL these days Id probably get one ;o)

Good of you, Dilwyn, to keep writing reviews. Youre probably the last 
bastion now..


Per

PS: Sorry I didnt leave a Like or a comment on your blog. I didnt like 
the login feature as I dont know where my details will end up. If I 
knew it only went to you, I wouldnt mind, of course, but Wordpress.com.. P



___
QL-Users Mailing List

Re: [Ql-Users] Lookup%


On 06/07/2021 16:51, Graeme Gregory via Ql-Users wrote:


On Tue, 6 Jul 2021, at 3:44 PM, pjwitte via Ql-Users wrote:

<>
If it were only that easy.. :o(

I havent gone through all of it, but just a couple of things:

MACHINE would be better for sorting out wots wot, except not all
systems implement it. However, you can get the same info directly from
the system variables. I dont have the details to hand, but Im sure
someone will produce them any moment now..

EMU_VER$ was a result of my nagging to get some semblance of
conformity across the various emulators (Why does each emulator have a
different command to do the same thing!) The idea was that EMU_xxx
would replace JVA_xxx and QPC_xxx and anything else like it. Sadly,
that didnt happen only SMSQmulator complied (but then still kept the
old JVA_xxx) However, one day QPC (and/or any other) may conform and
then BANG! goes your test for SMSQmulator. If you want to do it that
way, better target JVA_VER$.

Just a wee logical slip up: You cant use FDEC$ unless either TK2 or
SMSQ/E (or some other toolkit I dont know about) are present.


I can add that to sQLux pretty easilly (the EMU_VER$) any documentation I 
should read?

Graeme


The bits in the SMSQmulator readme and QPC Keywords manuals that 
describe the JVA_xxx/QPC_xxx keywords.


EMU_EXIT, EMU_VER$, EMU_MINIMISE, EMU_NETNAME$, EMU_NETADDR$, 
EMU_HOSTOS$ are things you might consider. It seems to me to make 
sense to support the existing command set rather than invent parallel 
ones.


Its a while since I used xQLx, so I may be talking through my hat 
here. Back then it seemed to masquerade as a QL emulator with a few 
extras thrown in. But it now seems to me to be a true alternative 
platform/system in its own right. Maybe its time it came out of the 
closet? In which case, and while youre at it, you may wish to confer 
with Wolfgang about adding some bits and pieces to the system 
variables, eg sys_mtyp, $00A7, and possibly others..


Per

___
QL-Users Mailing List

Re: [Ql-Users] Lookup%


On 06/07/2021 16:18, desin via Ql-Users wrote:

Am 06.07.21 um 15:07 schrieb Graeme Gregory via Ql-Users:



On Tue, 6 Jul 2021, at 1:59 PM, desin via Ql-Users wrote:



I agree with Francois, using LOOKUP% as alternative for EXISTS.
I use it a lot. It returns the place in the name table which can 
also be

used to test for conflicting keywords if found out of place.

Bob


on QDOS
Lookup% can not distinguish between
SCR_XLIM and SCRXLIM
http://www.dilwyn.me.uk/tk/scrxlim.zip

if SCRXLIM_cde is loaded
print Lookup% ("SCR_XLIM") gives 160
print Lookup% ("SCRXLIM") gives 162

conclusion
QDOS  -> EXISTS_bin
SMSQE -> Function_code


That looks right to me, assuming uQLx based code.

Lookup%(SCR_YLIM) will give 161 (its the last extension installed 
by uQLx), and SCRXLIM is the first user one at 162.


Graeme
___
QL-Users Mailing List




On the other hand; would it be safe to presume; for all Systems;
if SCR_XLIM is not present; the default screen resolution is used ?

my reason is a simple system info
depends on
Exists_bin
scrxlim_cde

 CLS
 PRINT
 IF EXISTS ("EMU_VER$") : PRINT " SMSQmulator"
 IF EXISTS ("QPC_EXIT") : PRINT " QPC2 "&QPC_ver$
 IF EXISTS ("UQLX_RELEASE$"): PRINT " UQLX "&UQLX_RELEASE$
 smsqe% = 0 : min% = 0 : tk% = 0
 IF "HBA"  INSTR VER$ : smsqe% = 1
 IF "JSL1" INSTR VER$ : min%   = 1
 IF EXISTS ("ED") : tk%    = 1
 IF smsqe%  : PRINT   " SMSQE "  &VER$ (1)
 IF min%    : PRINT   " Minerva ROM "&VER$ (1)
 IF NOT min% AND NOT smsqe% : PRINT " ";VER$ &" ROM"
 fr_mem%=FREE_MEM/1024
 IF fr_mem% >  1024:PRINT " "&FDEC$ (fr_mem%/1000,4,1) &" Mb free"
 if fr_mem% <= 1024:PRINT " "&fr_mem%&" Kb free"
 if tk%    and not smsqe% : PRINT " Toolkit2 enabled"
 IF EXISTS ("HIS_USE") and not smsqe% : PRINT " History  enabled"
 IF exists ("PINFO")   and not smsqe% : PRINT " Pointer  enabled"
 IF EXISTS ("RAM_USE") and not smsqe% : PRINT " Ramdisk  enabled"
 xx%=512:yy%=256
 IF EXISTS ("SCR_XLIM"):xx%=SCR_XLIM  :yy%=SCR_YLIM
 IF EXISTS ("SCRXLIM") :xx%=SCRXLIM(0):yy%=SCRYLIM(0)
 PRINT " Screen "&xx%&"x"&yy%

Markus 


If it were only that easy.. :o(

I havent gone through all of it, but just a couple of things:

MACHINE would be better for sorting out wots wot, except not all 
systems implement it. However, you can get the same info directly from 
the system variables. I dont have the details to hand, but Im sure 
someone will produce them any moment now..


EMU_VER$ was a result of my nagging to get some semblance of 
conformity across the various emulators (Why does each emulator have a 
different command to do the same thing!) The idea was that EMU_xxx 
would replace JVA_xxx and QPC_xxx and anything else like it. Sadly, 
that didnt happen only SMSQmulator complied (but then still kept the 
old JVA_xxx) However, one day QPC (and/or any other) may conform and 
then BANG! goes your test for SMSQmulator. If you want to do it that 
way, better target JVA_VER$.


Just a wee logical slip up: You cant use FDEC$ unless either TK2 or 
SMSQ/E (or some other toolkit I dont know about) are present.


Per

___
QL-Users Mailing List

Re: [Ql-Users] loopy bug


On 06/07/2021 14:13, Wolfgang Lenerz via Ql-Users wrote:

Hi Per,

an interesting pitfall, thanks for pointing that out.

It does seem that Qlib sets the value of the repeat loop control
variable to 0 at the start of the loop.

Do you know how this fares on plain QDOS, not SMSQE?

Regards

Wolfgang



I dont know if this has been documented anywhere, but Im putting it out
here as it caused me some grief.

It appears that Q-Liberator zeroes the loop variable on entry to a loop.
The following demo, which is acceptable (although perhaps not very
elegant) S*BASIC, will not work in the same way once compiled with Qlib.

100 loop = 3
110 cnt = 0
120 PRINT 'Start:'! loop, cnt
130 REPeat loop
140  PRINT loop, cnt
150  cnt = cnt + 1
160  IF cnt >= loop: EXIT loop
170 END REPeat loop
180 PRINT 'End:'! loop, cnt
190 PAUSE: QUIT

In the Qlib-compiled version the loop is exited after a single run as
the condition cnt >= loop is met immediately, to wit 1 >= 0

The worrying part of this is that while I was figuring out what was
wrong, running an embedded routine like this many times, the system
crashed due to memory corruption. Whether this was due to the SBASIC or
Qlib compiled version I cant say right now. So just beware and keep on
progging!

NB: This works, though. As long as you start out with loop = 0

100 loop = 0
110 cnt = 3
120 PRINT 'Start:'! loop, cnt
130 REPeat loop
140  PRINT loop, cnt
150  loop = loop + 1
160  IF loop >= cnt: EXIT loop
170 END REPeat loop
180 PRINT 'End:'! loop, cnt
190 PAUSE: QUIT


I tested it under Qdos JS and both loops work exactly like in Qlib! 
Minerva, as one might have guessed, behaves like SBASIC. Clearly the 
smarter approach (why forbid something when it doesnt matter, and 
which might even come in handy?) but since its not consistent across 
the board, its best avoided.


Bob, Dilwyn: I only discovered this by chance, due to a spelling mistake.

Per
___
QL-Users Mailing List

[Ql-Users] loopy bug

I dont know if this has been documented anywhere, but Im putting it 
out here as it caused me some grief.


It appears that Q-Liberator zeroes the loop variable on entry to a 
loop. The following demo, which is acceptable (although perhaps not 
very elegant) S*BASIC, will not work in the same way once compiled 
with Qlib.


100 loop = 3
110 cnt = 0
120 PRINT 'Start:'! loop, cnt
130 REPeat loop
140  PRINT loop, cnt
150  cnt = cnt + 1
160  IF cnt >= loop: EXIT loop
170 END REPeat loop
180 PRINT 'End:'! loop, cnt
190 PAUSE: QUIT

In the Qlib-compiled version the loop is exited after a single run as 
the condition cnt >= loop is met immediately, to wit 1 >= 0


The worrying part of this is that while I was figuring out what was 
wrong, running an embedded routine like this many times, the system 
crashed due to memory corruption. Whether this was due to the SBASIC 
or Qlib compiled version I cant say right now. So just beware and keep 
on progging!


NB: This works, though. As long as you start out with loop = 0

100 loop = 0
110 cnt = 3
120 PRINT 'Start:'! loop, cnt
130 REPeat loop
140  PRINT loop, cnt
150  loop = loop + 1
160  IF loop >= cnt: EXIT loop
170 END REPeat loop
180 PRINT 'End:'! loop, cnt
190 PAUSE: QUIT

Per

___
QL-Users Mailing List

Re: [Ql-Users] "RETurn not in procedure or function"

2021-06-29 Thread pjwitte via Ql-Users


On 29/06/2021 11:44, Bob Spelten via Ql-Users wrote:

Wolfgang Lenerz via Ql-Users wrote:

Hi,

in my experience, this is often caused by a Basic extension not
resetting the stack correctly. This generally seems to be the case
either when a keyword changes the value of an entry parameter, to make
it into a return parameter, or when a function returns a value (very
often a string).

But without having a complete program to test, this will be 
difficult to

find out.


Thanks for the suggestions.

My function does not change any of the entry parameters, only sets 
the return value. I have written other functions that do the same 
but without this anomaly, also with 8 chr names.
Anyway I will check the exit section to see what I did differently 
from previous and consult the Assembly Language PDFs to get it right. 

Bob,
If theres no problem with your S*BASIC structure (which I presume is 
the case since youre desperate enough to write here) then the problem 
must almost certainly be with one of the extensions used. A problem 
with SBASIC itself is possible but even less likely.
A string function is the most likely culprit as its easy to make a 
mistake with the return stack, but as Wolfgang mentioned, it could 
also be a bplet issue. My usual test rig for any function I write 
looks something like this:


rem Testing the function TEST$
m = free_mem: mm = m
for i = 0 to 
:
t$ = 'x' & TEST$('abc')
t$ = TEST$('abc') & 'x'
t$ = 'x' & TEST$('abc') & 'x'
:
t$ = 'x' & TEST$('abcd')
t$ = TEST$('abcd') & 'x'
t$ = 'x' & TEST$('abcd') & 'x'
:
if m <> free_mem then
 print m - free_mem
 m = free_mem
endif
endfor i
print 'Memory eaten:'! mm - free_mem

A healthy function should never eat memory as it goes! A function like 
that may well mess up the interpreter's return stack.


NB: The routine may crash the system if theres a serious problem with 
the function. But at least then youll know.


HTH, Per

___
QL-Users Mailing List

Re: [Ql-Users] "RETurn not in procedure or function"

2021-06-28 Thread pjwitte via Ql-Users


On 28/06/2021 13:10, desin via Ql-Users wrote:

Am 28.06.21 um 12:31 schrieb Bob Spelten via Ql-Users:

"RETurn not in procedure or function"
<>
Bob


hello

found some oddities with Exists and SMSQE

10 if exists ("TK2_EXT"):print "TK2"
20 if exists ("MODE")   :print "mode "
30 :
40 print dig_it
50 :
60 def fun dig_it
70 ret 1
80 end def

run
so far so good

now delete line 10
run again
error return not in function

turns out the error is triggered if the length of the
keyword is even

Greetings from  Switzerland

Markus 


Yes, that was my first thought too: A stack problem in one of the m/c 
functions


Per

___
QL-Users Mailing List

Re: [Ql-Users] QL-SD ROM

2021-04-29 Thread pjwitte via Ql-Users


On 29/04/2021 19:45, Marcel Kilgus via Ql-Users wrote:

An update on the progress of the external QL-SD variant:

https://www.kilgus.net/2021/04/29/ql-sd-rom-tiny/

Cheers, Marcel
Another poke at my regret at the necessity of getting rid of all my QL 
hardware! :o( Still, Im glad its out there. I hope it does well!

___
QL-Users Mailing List

Re: [Ql-Users] SMSQmulator 2.31

2021-02-18 Thread pjwitte via Ql-Users


On 18/02/2021 08:35, Wolfgang Lenerz via Ql-Users wrote:

Hi all,


SMSQmulator 2.31 is out (wlenerz.com/smsqmulator).

This is a pure bugfix release, to get rid of the syncscrap bug evoked
here, as well as some others found notably by Fabrizio  Diversi and Bob
Spelten.

Thank you, Wolfgang!

This version does NOT fix the problem with ALT+CTRL hotkeys under
Windows - this requires some more investigation.


That would be great! One gets so used to one's Hotkeys after all.

Per

___
QL-Users Mailing List

Re: [Ql-Users] SMSQmulator 2.30

2021-02-13 Thread pjwitte via Ql-Users

There appears to be a problem with the JVA_SYNCSCRAP job in Windows 
(10). I find it impossible to use the scrap, both internally (eg QD 
<-> QD) or from Windows (eg Notepad <-> QD). It always contains the 
same random text that never gets updated.


Stopping the SYNCSCRAP job cures the problem internally, but then the 
Windows <-> SMSQmulator facility also doesnt work, unless 
JVA_SGET/SPUT is used first.


The syncscrap job did work at some point, but doesnt now, and didnt in 
V2.29 either.


Apparently, in Windows, dont know about Linux, CTRL doesnt work as 
part of any Hotkey sequence; ALT + CTRL + x doest do anything although 
defined. Is this fixable?


Per

___
QL-Users Mailing List

Re: [Ql-Users] Select on

2020-06-21 Thread pjwitte via Ql-Users


On 21/06/2020 13:38, Bob Spelten via Ql-Users wrote:
Op Sun, 21 Jun 2020 09:46:23 +0200 schreef Norman Dunbar via 
Ql-Users :


I have a vague recollection that Simon N Goodwin did something 
similar, maybe, in the DIY Toolkit.


I think it was passed a variable and a list of strings, and 
returned the position of the variable in the list. Something like 
that.


Maybe useful?


That would then be the PICK$ function.
It's on DIY disk 1, sub E, found on Dilwyn's site, where else?
To me it looks like PICK$ is the OPPOSITE of string SELect. PICK$ goes 
like this:


direction$ = PICK$(direction%,"North","East","South","West")

Which is nothing other than what we've already got, ie:

SELect on direction%
 = 1: direction$ = "North"
 = 2: direction$ = "East"
 = 3: direction$ = "South"
 = 4: direction$ = "West"
 = REMAINDER: direction$ = "???"
END SELect

although it is theoretically faster than SELect as it calculates the 
location of the desired value rather than doing a bunch of comparisons.


But what a string select is supposed to do is:

direction% = PICK%(direction$,"North","East","South","West")

ie it returns some processable answer to a string query, viz

SELect on direction$
 = 'North': Go_to_North
 = 'East': Go_to_East
 = 'South': Go_to_South
 = 'West: Go_to_West
 = REMAINDER: Go_to_Hell
END SELect

Just for fun, after reading Giorgio's mail, I went and wrote a 
function like PICK% (not PICK$). Although it is very simple, it is 
significantly slower than the INSTR suggestion I made earlier. It 
would probably more or less match a real string select in speed.


A hash function could be faster/more efficient for lists critical 
enough to justify the presence of such a function.


Ideally, it would be some function that would map lexicographical 
values well onto numbers, eg


f('ABC') < f('abc') or f('abcd') > f('abc'), etc, in a word or 
longword. Then things like ranges might be possible:


term = Magic(term$)
:
SELect on term
 = $0123 TO $0300: Go_to_North
 = $3001, $1234: Go_to_East
 = etc

though of what practical use they would be I know not..

But out of interest, does such a function exist?

Per


___
QL-Users Mailing List

Re: [Ql-Users] Select on

2020-06-20 Thread pjwitte via Ql-Users


On 20/06/2020 17:00, Jan Bredenbeek via Ql-Users wrote:

Op za 20 jun. 2020 14:01 schreef Dave Park via Ql-Users <
ql-users@lists.q-v-d.com>:


ooGyebd = Goodbye
goodbye <> Goodbye


Use a hash algorithm like CRC-16 or CRC-32? ;-)


Thats probably the fastest solution so far :o) Maybe overkill for just 
a few items. INSTR is pretty fast - and its built in.


Per


___
QL-Users Mailing List

Re: [Ql-Users] Select on

2020-06-19 Thread pjwitte via Ql-Users


On 19/06/2020 20:02, Daniel Baum via Ql-Users wrote:

What about doing something like this. In languages like c# the equivalent
of the "select on: command is hardly ever used and if .. else if ... else
is much more common:

100 INPUT a$
110 IF a$="a" THEN
115   PRINT "hello a"
120   ELSE
130 IF a$="b"
135 PRINT "hello b"
150 ELSE
155   IF a$="c"
157   PRINT "hello c "
160   ELSE
170 PRINT "hello d"
180   END IF
190 END IF
200 END IF


Actually, I had need of a similar construct recently. This is what I 
came up with:


100 FOR i% = 1 TO 6
110  case$ = 'case' & i%
120 c% = case$ INSTR "case1 case2 case3 case4 case5 case6"
130 :
140 SELect ON c%
150  =  1: PRINT 'case 1'
160  =  7: PRINT 'case 2'
170  = 13: PRINT 'case 3'
180  = 19: PRINT 'case 4'
190  = 25: PRINT 'case 5'
200  = 31: PRINT 'case 6'
210  = REMAINDER : PRINT 'ERROR'
220 END SELect
230 :
240 END FOR i%
This is obviously just a demo to illustrate the idea. It seems 
reasonably fast. In my case

I was able to keep all the terms to more or less the same size.
If there is a chance of ambiguity, one could wrap the terms in 
delimiters:


c% = '#' & case$ & '#' INSTR '#case1#test this2#or this#etc#..#'

Per


___
QL-Users Mailing List

Re: [Ql-Users] Select on

2020-06-19 Thread pjwitte via Ql-Users


On 19/06/2020 10:52, Giorgio Garabello via Ql-Users wrote:

  "SELect ON" instruction
I find it has a major flaw that will not allow you to manage alphanumeric
variables,
I unfortunately don't know the assemly
Would someone be available to create an extension similar to SELECT (e.g.
SELECT $) capable of handling strings?
I understand that it is not simple .. :-(

Giorgio


Sadly, this is one of many improvements in Minerva BASIC that did not 
make it into SBASIC. At least SBASIC no longer crashes on FOR i$ = 'a' 
TO 'z'! or REPeat a$ .. It just errors. (As of V3.35, I think)


Per

___
QL-Users Mailing List

Re: [Ql-Users] SMSQmulator 2.29

2020-04-19 Thread pjwitte via Ql-Users


Hi Wolfgang,
Gremlins have dissipated.
Thank you SMSQmulator!
Per

19/04/2020 15:38, Wolfgang Lenerz via Ql-Users wrote:

Hi Bob, Per, François, Derek,

thanks for letting me know.

It seems the version for java 11 is ok, not the one for java 8, though
both work ok here.

I re-upped the version for java 8 (also changing the version number).

HTH

Wolfgang



I updated the Java 11 version all is working okay on Linux.

Maybe it's a Windows problem.

Regards,
Derek

On 19 April 2020 13:57:29 BST, "François Van Emelen via Ql-Users" 
 wrote:

Op 19/04/2020 om 7:56 schreef Wolfgang Lenerz via Ql-Users:

Hi all,

hot on the heels of SMSQE 3.36 comes SMSQmulator 2.29.

Win drives can be made removable.
NFA drives can handle (exec, save and load) files with an XTcc

footer,

so that QL files can be  EXEC'd directly from a native drive.

wlenerz.com/smsqmulator.

Have fun


Wolfgang
___
QL-Users Mailing List


Hi Wolfgang,

There seems to be a problem with 2.29.
Launching it displays a black screen.

About says: v 2.29 for Java 8.

François Van Emelen


___
QL-Users Mailing List

---
Regards,

Derek
___
QL-Users Mailing List


___
QL-Users Mailing List



___
QL-Users Mailing List

Re: [Ql-Users] SMSQmulator 2.29

2020-04-19 Thread pjwitte via Ql-Users


Same here. And the version is marked 2B29 in the About.
Per
On 19/04/2020 13:22, Bob Spelten via Ql-Users wrote:
Op Sun, 19 Apr 2020 07:56:30 +0200 schreef Wolfgang Lenerz via 
Ql-Users :



Hi all,

hot on the heels of SMSQE 3.36 comes SMSQmulator 2.29.

Win drives can be made removable.
NFA drives can handle (exec, save and load) files with an XTcc footer,
so that QL files can be  EXEC'd directly from a native drive.

wlenerz.com/smsqmulator.


Thanks Wolfgang for the final 2.29.
But it seems something has gone wrong when making the zip.
The unpacked SMSQm8229 only opens it's W$ window, the content is 
black, no QL windows.

When viewing the supplied SMSQE bin file I see sections of SBasic(?).

Then I copied SMSQE (also 308.5K) from the 3.36 binaries, which 
looked alright although it said there @h01E0: 
"<>SMSQXq3.350002..".

The result was the same, no booting into my usual .WIN.
BTW The SMSQE 3.36 announcement was too hot for me and never reached 
my mailbox.


Bob




___
QL-Users Mailing List

Re: [Ql-Users] QL User grapic competition from 1985: Tree

2020-04-16 Thread pjwitte via Ql-Users


On 16/04/2020 12:39, Michael Berger via Ql-Users wrote:

I remember that. Cool :o)

But I cant answer your question, sorry.

Per

___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

2020-03-22 Thread pjwitte via Ql-Users

I was just pointing out, to anyone interested, that there is a lot 
more one can do with this ;o) Obviously a myprog_bas program has to 
exist and be valid, and the exclamation mark was informative and not 
meant to be part of the command.

But EXEP 'SBASIC' should do what I presume you were trying to do.
Per
On 22/03/2020 21:35, Giorgio Garabello via Ql-Users wrote:

Il giorno dom 22 mar 2020 alle ore 18:22 pjwitte via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:


Try EXEP 'SBASIC',


this work well!



or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!


this not

Giorgio


Per
On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:

I'm trying to run the SBASIC command inside a compiled program (with
Qliberator) but nothing happens .
Ideas?

100 PRINT "STEP 1"
110 SBASIC
120 PRINT "STEP 2" Regards Giorgio
___
QL-Users Mailing List
.


___
QL-Users Mailing List


___
QL-Users Mailing List
.




___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

2020-03-22 Thread pjwitte via Ql-Users


Try EXEP 'SBASIC', or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!

Per
On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:

I'm trying to run the SBASIC command inside a compiled program (with
Qliberator) but nothing happens .
Ideas?

100 PRINT "STEP 1"
110 SBASIC
120 PRINT "STEP 2" Regards Giorgio
___
QL-Users Mailing List
.



___
QL-Users Mailing List

Re: [Ql-Users] E-mail etiquette: New subject, new message

2020-02-08 Thread pjwitte via Ql-Users

A lot of people simply dont know this because they never view their 
mails by thread. I know I didnt, until I was told off about this some 
years ago. (I hope Ive managed to behave since then!)
On this list there also used to be a convention to top- or tail- reply 
(I can no longer remember which 'cause I do it so rarely these days) 
Tony Firshman used to ball us out regularly for misbehaving wrt this.
As anyone who tries to write programs for the QL "that just work out 
of the box" knows only too well, educating the general QLing public is 
a soul-destroying task. I guess we are a particularly idiosyncratic lot!

Id like to do better, truly I would. I can only keep trying ;o)
Per

On 08/02/2020 21:01, Marcos Cruz via Ql-Users wrote:

Hello.

Probably most of you know that e-mail messages contain, in their
metadata, a unique message identifier and also the unique message
identifier of the responded message, if any. These identifiers allow the
automatic hierarchic organization of messages into threads.

Sometimes in this list, messages that start a new subject, actually are
"responds" to other unrelated messages (even several years old). That is
unlogical, has no advantage, breaks the sense of the threads and makes
reading the list more difficult.

For example, the recent announcement of the 16th Sinclair QL Italian
meeting is a "respond" to the announcement of the 15th meeting (posted
in 2018-10), which was a "respond" to the announcement of the QDOS/SMS
reference manual 4.1 (posted in 2016-09).  And then, three days later,
the announcement of SMSQ/E 3.35 is a "respond" to the announcement of
the 16th Italian meeting...  As a result, without reason, both recent
and interesting announcements belong to (and are "hidden" in) a thread
started more than three years ago, and therefore they don't appear as
two independent new threads at the top of the current hierarchy of
messages in 2020-02, as they should.

I know some webmail services don't care about the message identifiers
and use the subject fields instead in order to recreate and display the
threads, but that's not the way e-mail is supposed to work.  Perhaps
that is the reason some users don't realise the trouble caused by
writing a new message by "replying" to whatever previous unrelated
message, instead of writing an actual new message.

Changing the subject in a thread only makes sense when the actual
respond naturally leads to a different topic, but there's a helpful
convention to mark that cases: "Re: New subject (Was: Old subject)".

Please remember a basic rule of e-mail (lists) etiquette: New subject,
new message; only respond to a message if you actually want to respond
to what that message contains.

Thank you in advance.

Kind regards.



___
QL-Users Mailing List

[Ql-Users] testing

2020-02-08 Thread pjwitte via Ql-Users


I sent a response to something here, but it didnt arrive..

___
QL-Users Mailing List

Re: [Ql-Users] WM_move_mode and Easyptr menu

2019-10-19 Thread pjwitte via Ql-Users


On 19/10/2019 17:00, François Van Emelen via Ql-Users wrote:

Op 18/10/2019 om 11:34 schreef pjwitte via Ql-Users:

On 18/10/2019 11:17, François Van Emelen via Ql-Users wrote:

Hi,


Can someone confirm what happens in line 220?

In a menu created with Easaymenu (Easyptr) there is a Loose Item 
to allow the menu to be moved.


Configuration A: the key for that Loose Item is CRTL E, seems to 
be the default value.


Configuration B: I replaced the default key with value 77 (‘M’) 
for Move.


….

200 SELect on ObjectHit

205 = -1:Remark do something

210 = -2:Remark do something

215 =- 3:Remark this is the move Loose Item

220 :Remark do something

….


With Configuration A, WM_movemode 0,1,2,3 can be used but line 220 
is never executed. Why?


With Configuration B, line 220 is executed but only WM_movemode 0 
(the old way, using the “move window” sprite) is available. Why?


Is this a feature, a bug or am I missing something?

Help and explanation are welcome.


François Van Emelen 


In A. the Move window call is trapped by the system, so it never 
reaches line 220. In B. you need to add the instruction to move the 
window, for example WMOV. This gives you the opportunity to carry 
out other stuff before and after the the move instruction. The 
standard key for this is CF4, tho'.


WMOV has evolved over the years, so make sure youre using the 
latest version of ptrmen_cde to get the best. Get it directly from 
Marcel's.


On my Knoware.no site, for example, there are a number of PE 
programs with source code included. They show a variety of ways you 
can do this.


Per


___
QL-Users Mailing List


Hi Per,

Thanks for your reply.

In my programme WMOW is of course present in line 215. Yes of 
course, in A. the call is trapped by the system. As for B. I'll have 
to investigate further. WM_MOVEMODE not working correctly is perhaps 
due to the menu itself created a long time ago with an older version 
of Easyptr.


Of course, your site is not unknown to me: I visited it more than once.

Thanks for your comments!

François Van Emelen 


As Bob mentioned, you should use WMOV#ch; -1. This is supposed to 
work, but perhaps only with more recent versions of the ptrmen_cde 
toolkit. The current version is 4.10. However, sometimes EP reverts to 
the old Wmov method for reasons that are not always obvious (to me, at 
least). When this happens, it is usually because I did something 
wrong, ie some bug in my code. Good hunting!


Per

___
QL-Users Mailing List

Re: [Ql-Users] WM_move_mode and Easyptr menu

2019-10-18 Thread pjwitte via Ql-Users


On 18/10/2019 11:17, François Van Emelen via Ql-Users wrote:

Hi,


Can someone confirm what happens in line 220?

In a menu created with Easaymenu (Easyptr) there is a Loose Item to 
allow the menu to be moved.


Configuration A: the key for that Loose Item is CRTL E, seems to be 
the default value.


Configuration B: I replaced the default key with value 77 (‘M’) for 
Move.


….

200 SELect on ObjectHit

205 = -1:Remark do something

210 = -2:Remark do something

215 =- 3:Remark this is the move Loose Item

220 :Remark do something

….


With Configuration A, WM_movemode 0,1,2,3 can be used but line 220 
is never executed. Why?


With Configuration B, line 220 is executed but only WM_movemode 0 
(the old way, using the “move window” sprite) is available. Why?


Is this a feature, a bug or am I missing something?

Help and explanation are welcome.


François Van Emelen 


In A. the Move window call is trapped by the system, so it never 
reaches line 220. In B. you need to add the instruction to move the 
window, for example WMOV. This gives you the opportunity to carry out 
other stuff before and after the the move instruction. The standard 
key for this is CF4, tho'.


WMOV has evolved over the years, so make sure youre using the latest 
version of ptrmen_cde to get the best. Get it directly from Marcel's.


On my Knoware.no site, for example, there are a number of PE programs 
with source code included. They show a variety of ways you can do this.


Per


___
QL-Users Mailing List

[Ql-Users] Knoware.no

2019-05-13 Thread pjwitte via Ql-Users

Just to let you know that Knoware is up and running again after ten 
years or so of being nowhere. While I hope there will be something of 
interest for anyone interested in the QL and derivatives in general, 
its main interest will be for those of us who like to write programs 
for it and generally mess around with the software.

www.knoware.no/ 

___
QL-Users Mailing List

Re: [Ql-Users] New QPC release ?

2019-04-09 Thread pjwitte via Ql-Users


On 09/04/2019 12:51, François Van Emelen via Ql-Users wrote:

Op 8/04/2019 om 14:58 schreef pjwitte via Ql-Users:
What seems to be the problem? To me the only "problem" seems to be 
one or two small inconsistencies:


DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf 
call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) 
but -1 is arguable..)


The other relates to iof.xinf directly, but that is not wired up to 
any DMEDIUM_ command, namely:
IOI_HDRL $28 Long File header length (per file storage overhead) - 
which returns 512b on DOS, while all other devices return 64b. The 
inconsistency here is that 512b doesnt relate to the actual file 
header size, as I always assumed was the intention..


Those two points also differ from SMSQmulator's NFA device, which 
returns the "expected" values, ie 2 and 64, respectively.


Just my penny's worth..
Per

On 06/04/2019 12:55, François Van Emelen via Ql-Users wrote:

Hi,

There seems to be a new release of QPC2 in the pipeline.

It would be very useful if someone would/could debug the 
'DMEDIUM_XXX' functions.


Have a fine day,

François Van Emelen



Hi,

As my programming skills are limited to some easy basic, I can't 
argue about "DMEDIUM_TYPE returns -1 on DOS devices (the underlying 
iof.xinf call suggests: IOI_FTYP $2C Byte Format type (1=qdos, 
2=msdos etc) but -1 is arguable..)"


I noticed some months ago that some DMEDIUM-functions returned wrong 
values (see SBASIC/SuperBASIC Reference Manual Online Documentation 
Release 4.0.1 Rich Mellor).


Not only wrong values but also differences between Smsqmulator and 
Qpc. And as there is a new release of QPC in the pipeline, I thought 
it was right time to try to convince Marcel to do some work on those 
DMEDIUM-functions .


You could try this in QPC and SMSQMULATOR to see the difference.

90  REMark test for for some dmediium_xxx functions
100 OPEN_OVER#3,'ram2_rdonly_txt'   ::datad_temp$=DATAD$
110  REMark Why does 'dmedium_rdonly(\dev$) return 0 instead of 1
120  REMark Why does 'dmedium_type(\dev$) return -1 instead of 3
130  REMark Why does 'line 240  return  -23  WITH qpc2 (which seems 
correc)t BUT -7 with SMSQMULATOR

140  dev$='dos3_' :d$=DATE$
150 REMark DOS3_   is an external USB CD DRIVE
160 DATA_USE 'dos3_'
170  fichier$=dev$&d$
180 WHEN ERRor
190 IF  ERNUM:PRINT#3,ERLIN,ERNUM:END IF
200 END WHEN
210 d= FTEST(dev$)
220 IF d<0:CLOSE#3:DELETE 'ram2_rdonly_txt' :DATA_USE 
datad_temp$:STOP:END IF

230 f=FOP_NEW(fichier$):
240  PRINT#3,240,' f=fop_new(fichier$) = ',f
250  PRINT#3,250,'dmedium_rdonly(\dev$) = '; 
DMEDIUM_RDONLY(\dev$),'rdonly' ,' 0= Read/Write 1=Read Only'
260  PRINT#3,260,'dmedium_type(\dev$) = ', 
DMEDIUM_TYPE(\dev$),'type'  ,'0= Ram disk : 1= floppy drive :2= hard 
disk :3=CDrom drive'
270  PRINT#3,270,'dmedium_name$(\dev$) = ', DMEDIUM_NAME$(\dev$) 
,'name'

280   CLOSE#3
290 DATA_USE datad_temp$  :PAUSE

Thanks for your reply..

Have a fine day.

François Van Emelen


Hi François,

I tried your program with different devices, this is what I found:

    ram1    flp2    win1 dos1/nfa1 win3  
dos3/nfa3

SMSQmulator

f=fop_new(fichier$)  4   4   4 -7 4    -7*
dmedium_rdonly(\dev$)    0   0   0 0 0 0
dmedium_type(\dev$)  0   1   2 2 2 2
dmedium_name$(\dev$) RAM1    MyFlp   Syst   NFA DRIVE 1  Pics   
NFA DRIVE 3



QPC2 (V4.xx)

f=fop_new(fichier$)  4   4   4 -23**  4 4
dmedium_rdonly(\dev$)    0   0   0 0 0 0
dmedium_type(\dev$)  0   1   2 -1 2    -1
dmedium_name$(\dev$) RAM1    MyFlp   System C:\   Pics  Temp


* The reason NFA file returned -7 here is because the : in the date 
got translated
to " on the drive: April 9th 2019 17:06:51 -> April 9th 2019 17"06"51, 
so it

couldnt find the file it had just created!

** -23 => Access denied on system root. DMEDIUM_RDONLY reported 0..

The  problem doesnt, IMHO, lie with DMEDIUM_xxx. Its down to the 
various driver implementations. It would, of course be good if the 
various drivers could all behave in a consistent way. With QPC2 and 
SMSQmulator there is still hope, but for many other systems, like the 
Falkenberg HDD interface (ref the SBASIC/SuperBASIC Reference Manual) 
that boat has probably sailed.

Per
___
QL-Users Mailing List

Re: [Ql-Users] New QPC release ?

2019-04-08 Thread pjwitte via Ql-Users

What seems to be the problem? To me the only "problem" seems to be one 
or two small inconsistencies:


DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call 
suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 
is arguable..)


The other relates to iof.xinf directly, but that is not wired up to 
any DMEDIUM_ command, namely:
IOI_HDRL $28 Long File header length (per file storage overhead) - 
which returns 512b on DOS, while all other devices return 64b. The 
inconsistency here is that 512b doesnt relate to the actual file 
header size, as I always assumed was the intention..


Those two points also differ from SMSQmulator's NFA device, which 
returns the "expected" values, ie 2 and 64, respectively.


Just my penny's worth..
Per

On 06/04/2019 12:55, François Van Emelen via Ql-Users wrote:

Hi,

There seems to be a new release of QPC2 in the pipeline.

It would be very useful if someone would/could debug the 
'DMEDIUM_XXX' functions.


Have a fine day,

François Van Emelen



___
QL-Users Mailing List



___
QL-Users Mailing List

[Ql-Users] Just testing

2018-12-07 Thread pjwitte via Ql-Users

I discovered there had been some activity on the list which I havent 
received. The last message I received until today was dated 29.10.2018.


Per

___
QL-Users Mailing List

Re: [Ql-Users] QD 2018

2018-09-20 Thread pjwitte via Ql-Users


On 20/09/2018 23:57, desin via Ql-Users wrote:



Anyone else have these symptoms?

Per


System QPC 4.05 SMSQE.3.33

from FiFi to QD B 05  (B 04 is ok)

QD hangs then QPC freezes

i bet Sysmon would be yodeling


greetings from Switzerland

    Markus

Strange. Ive been using QD B05 heavily these past few days, including 
with FiFi. No problem until I needed to test something on 
SMSQmulator.. And, yes; there was pronounced yodeling


P


___
QL-Users Mailing List

Re: [Ql-Users] QD 2018

2018-09-20 Thread pjwitte via Ql-Users


On 16/09/2018 00:55, Marcel Kilgus via Ql-Users wrote:

I have just updated QD 2018 to version B.05:

; B.05  Implemented per-extension editor-usage (configurable) (MK)
;   Fixed BASIC usage for DEFine FuNction (MK)
;   Fixed colours in replacement confirmation dialog (MK)
;   Fixed DO on resize to keep the x window size (MK)
;   Bottom right corner stays where it is on normal resize (MK)
;   Allow CTRL+Z (mark current line) in read-only mode (MK)

As previously with the tab settings the editor-usage can now be
configured per extension, so you can say all "_bas" (or "_bsl" ;) )
files automatically invoke the "BASIC" editor usage, for example.

The rest is the stuff we've already talked about here.

https://www.kilgus.net/smsqe/qd/

Cheers, Marcel
There may be a problem with this version and SMSQmulator (V2.26 + 
SMSQ/E 3.33).
I LRESPR QD and either EXEP it with a large basic file or execute the 
file via QPAC2 Files and the whole thing goes tits up. When I try this 
with a minimum configuration, like only QD and menu rext it is less 
obvious, by I think the memory gets corrupted. I havent noticed this 
with QPC2, or in either emulator with QD B01.

Anyone else have these symptoms?

Per
___
QL-Users Mailing List

Re: [Ql-Users] QD 2018 colours


On 29/08/2018 00:53, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

So that wouldnt help you, Bob. In VB0.3 the behaviour
changed again. Now DOing the resize button annoyingly resets the width
to 80 coloumns for some reason as well as maxing the hight.

It has never worked for me before, but I fixed it anyway,

Great! :)

There is one serious bug though, that I hope will one day be tackled
by some brave and patient soul.

Tried. Failed. Not happening, sorry.


Its hard to demonstrate and almost impossible to catch in the act.

That's basically the problem. That and that the editor core is
thousands of lines of hard to read code. But if you can ever repro
it...
Ill have another go at trying to reproduce it. But itll take time, so 
dont hold yer breath ;)


Thanks for all youve done so far! :)

Per
___
QL-Users Mailing List

Re: [Ql-Users] QD 2018 colours


On 29/08/2018 00:48, Marcel Kilgus via Ql-Users wrote:

Bob Spelten via Ql-Users wrote:

But setting a custom width, moving the "size" to the left, is where the
right side also moves left.

OK, now I see what you mean.

The size is incremented in 20 character steps. There is no explanation
in the code why that is, but as this is the same amount that is used
when the edit window is panned I guess that this is the reason. I
tried removing the restriction and most things seemed to work, but I
found at least a minor bug, so I'm not comfortable lifting that
restriction.

I can make the bottom right corner stay in place, though. The downside
is that now when you resize less than 20 characters more basically
nothing happens at all, this might be confusing for some users.
A possible compromise might be to round up? If the user indicates he 
wants to resize
by managing to move the resize sprite more than half way to the next 
size increment,
that is taken as a valid resize request (provided there is room 
enough). Just a thought..

Jochen once explained that size grows in
discrete steps but I would expect the right side to be anchored, now full
screen can never be reached.

Ususally it cannot be reached because the maximum line length is
exhausted before the maximum screen width.
Im not sure I understand what you mean here. QD comes pre-configured 
for a maximum
line length of 160 char, so that should allow for a window width of at 
least 960 pixels

<>

Per
___
QL-Users Mailing List

Re: [Ql-Users] QD 2018 colours


On 28/08/2018 21:10, pjwitte via Ql-Users wrote:
Op Tue, 28 Aug 2018 15:26:22 +0200 schreef Marcel Kilgus via 
Ql-Users :

Bob Spelten via Ql-Users wrote:

<>

There is one serious bug though, that I hope will one day be tackled 
by some brave and patient soul. Its hard to demonstrate and almost 
impossible to catch in the act. In fact some people, including Jochen, 
deny its very existence: Its the "Creeping last line/rubbish bug". A 
scan through the SMSQ/E sources should convince doubters of its 
existence. In a number of files youll see a many lines gap from the 
last code line to the END directive. Heres one:

<>

I just want to correct an assertion made above: It is true (in my 
recollection) that Jochen was an unbeliever at first, but by 2001 he 
certainly knew about this bug (we referred to it as the cut'n paste 
bug), and he tried very hard to find and fix it.


Per
___
QL-Users Mailing List

Re: [Ql-Users] QD 2018 colours

Op Tue, 28 Aug 2018 15:26:22 +0200 schreef Marcel Kilgus via 
Ql-Users :



Bob Spelten via Ql-Users wrote:

Per already mentions the jumpy resize behaviour.


I frankly don't quite see what's jumpy about it?

My default QD size is 80 columns by 40 lines, and I like that a size 
DO  makes it maximize the height.
But setting a custom width, moving the "size" to the left, is where 
the right side also moves left. Jochen once explained that size 
grows in discrete steps but I would expect the right side to be 
anchored, now full screen can never be reached.
It seems that the bigger the move to the left, the more the right 
moved along with it.


Uh-oh. I think we have conflicting wishes here. If I understand you 
correctly, you are not able to re-size the the WIDTH of the window by 
HITting the window resize button and moving the icon to the left. 
Right? To achieve that you needed to DO the window resize button, 
which makes the window expand to maximum, something that no longer 
works in VB0.xx.


The thing is, you CAN resize the window width using the standard Wman 
resize mechanism, but you need to move the resize icon some 150 pixels 
or more to the left for the next allowable width increment. I guess 
you need a screen width of at least 640 pixels, and to move the QD 
window as far right as possible to be able to resize the width to the 
next level. Thats why you wish for the old VA.xx behaviour.


I agree this stepwise increment is a nuisance. Ideally the increment 
should be in the order of one or a few character widths; not 20.


In VB.01 the behaviour changed somewhat. DOing the resize button would 
only maximise the HIGHT, leaving the width at whatever one had 
labouriously managed to set it (I usually prefer 100 columns for 
working). So that wouldnt help you, Bob. In VB0.3 the behaviour 
changed again. Now DOing the resize button annoyingly resets the width 
to 80 coloumns for some reason as well as maxing the hight.


There are a number of bugs in QD. I shant list them here, as that 
might be seen like "looking a gift horse in the mouth", or worse: 
nagging ;)


There is one serious bug though, that I hope will one day be tackled 
by some brave and patient soul. Its hard to demonstrate and almost 
impossible to catch in the act. In fact some people, including Jochen, 
deny its very existence: Its the "Creeping last line/rubbish bug". A 
scan through the SMSQ/E sources should convince doubters of its 
existence. In a number of files youll see a many lines gap from the 
last code line to the END directive. Heres one:


dev8_iod_con2_qpc8_mblock_asm, from 2003 with a 37 line gap!

That implies that you wont always see the problem, because its 
off-page. Whats worse is that you dont always know what the last line 
contains. Here are some with some rubbish at the end


dev8_dv3_q68_sdhc_wsect_asm
dev8_dv3_q68_win_card__asm

both from 2018. Since the rubbish is past the END it wont matter here, 
but you can see the potential for strange, inexplicable bugs in other 
code - or perhaps even a nasty letter where you thought youd deleted 
what you really thought of someone..


The oldest Ive found in the SMSQ/E source files, so far is

dev8_iod_con2_16_recol_asm

from Dec 1998, ie just after QD VA.06 came out. Perhaps there is a 
connection?


I did a general tidying up of the source files a year or two ago, so I 
caught a lot of the most extreme cases and fixed them, but I left a 
few for posterity - and new ones have emerged since.


Anyway, that was just to try to convince any unbelievers. The issue 
has been with us for a very long time. I believe it has something to 
do with QD's block handling: copy, replace, delete..? But, as I said, 
its hard to get a clear idea of when it happens. Not least because 
most(?) of the time it happens out of sight below the bottom of the 
visible text.


Per


___
QL-Users Mailing List

Re: [Ql-Users] QD 2018 colours


On 28/08/2018 14:45, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

Im having a problem with the latest QD (2018). The 'Replace
confirmation sub menu' seems to have its colours mixed up. I cant read
that menu in any palette!

I've never used or seen this menu, but yes, it's broken. Jochen was
being clever here, unfortunately without explaining comments in the
menu/code what he did! Bad Jochen! The window actually has a "hole" in
it that let the original text shine through. Apparently Bernd, who did
the colour conversion, gave up understanding it. Took me halve an hour
to get it, too.

Unlike the last official release my sources are based on Bernd's
version, so you got a confused and bugged halve-finished version of
the window. The last official release just didn't colour the window at
all.

Well thanks for the effort :)

If "someone" ;) is going to delve into the innards of QD again to sort
this out, could they also tweak the 'resize to full screen' option (DO
resize icon) to perhaps leave the current x-size of the window
unchanged (as it was in the earlier version)?

I don't think there ever was a version that left the x-size alone? As
far as I can tell all previous versions just made the window a LOT
wider, to the maximum allowed size. I much prefer the current
behaviour.

VB0.1 does.

Per
___
QL-Users Mailing List

[Ql-Users] QD 2018 colours

2018-08-25 Thread pjwitte via Ql-Users

Im having a problem with the latest QD (2018). The 'Replace 
confirmation sub menu' seems to have its colours mixed up. I cant read 
that menu in any palette!


Since no one else has complained, and I recently made some changes, I 
was wondering if Im just being confused (again!) But then an older 
version of QD (2003) seems unaffected, although it too uses the old 
colourways settings for part of that menu.


If "someone" ;) is going to delve into the innards of QD again to sort 
this out, could they also tweak the 'resize to full screen' option (DO 
resize icon) to perhaps leave the current x-size of the window 
unchanged (as it was in the earlier version)?


Great that this program is now freely available!

Per

___
QL-Users Mailing List

Re: [Ql-Users] colour confusion

2018-08-25 Thread pjwitte via Ql-Users


On 25/08/2018 15:16, Bob Spelten via Ql-Users wrote:
Op Sat, 25 Aug 2018 12:03:03 +0200 schreef pjwitte via Ql-Users 
:




Thank you, guys. The confusion, it appears, was entirely mine. I'll 
spare you my various excuses; one of the many clues that should 
have alerted me to the error of my ways was in sp_titletextbg! :) I 
do wish, however, that there had been some "safe" way to put text 
on a stippled or striped background in other cases too. But thats ok.
Im very glad of the palette system as it is. It has stood up well 
to the test of time!



I can understand the "middleground" confusion.
When you open a theme in QCoCo and click the INFO WINDOW item there 
is "ink_1" and "ink_2". The manual explains that ink_2 stands for 
middleground, probably called this way to avoid just this confusion.
Not all themes that are around will fully exploit this, nor do many 
programs, I never did.
So if some text seems missing or vague it's worth checking your 
theme in QCoCo to see if the ink_2 item is actually visible or 
different enough.


QCoCo's "SYNCHRO" section will take the Outline ink & paper and copy 
this to other sections to quickly build a theme but syncing 
middleground with ink_1 is missing and I will add this to v1.63. 
Thanks Per for making this point.


"sp_titletextbg" is also tricky.
In some themes Title-ink and -paper are the same, using this as a 
contrast. But SuQcess doesn't use it so the title (database name) 
could become invisible with such a theme. For the current version a 
test has been added to make sure ink and paper are different.

Thanks, Bob. QCoCo did provide another clue I blithely missed.
Text background is not featured in EasyPTR and should be created 
with overlapping Info Windows.
Im not sure using overlapping info windows would have helped for what 
I had in mind. But no matter. For my part, now that the matter has 
been cleared up, the problem has gone away.


[Pologies about top posting earlier. Another list Im on insists on it, 
so I keep forgetting. More confusion..]


Per
___
QL-Users Mailing List

Re: [Ql-Users] colour confusion

2018-08-25 Thread pjwitte via Ql-Users



Thank you, guys. The confusion, it appears, was entirely mine. I'll 
spare you my various excuses; one of the many clues that should have 
alerted me to the error of my ways was in sp_titletextbg! :) I do 
wish, however, that there had been some "safe" way to put text on a 
stippled or striped background in other cases too. But thats ok.
Im very glad of the palette system as it is. It has stood up well to 
the test of time!


Per

On 24/08/2018 22:00, Dilwyn Jones via Ql-Users wrote:
I tended to avoid "strip" colours in my WMAN2 programs and preferred 
to think of the middleground as a second INK colour, either for 
headings or for "sub-texts" such as prompts or warnings above menus. 
I never really knew if I was using it correctly (guess I was for 
title bars), but never really thought to query it at the time 
despite writing articles about it in QL Toady, Quanta, etc.


Dilwyn
-Original Message- From: Marcel Kilgus via Ql-Users
Sent: Friday, August 24, 2018 4:37 PM
To: ql-us...@q-v-d.com
Cc: Marcel Kilgus
Subject: Re: [Ql-Users] colour confusion

OK, I have a little bit more time and net here now. When I defined 
the colours 15 or so years ago I was asking the community for 
feedback, but I think most people didn‘t even quite understand the 
purpose yet, so there weren‘t really any changes to it.


I defined the colours based on three things, the Windows 95 colour 
palette, the WMAN window structures and the colours needed to 
successfully port QPAC2 to them. Only one or two additions were made 
for other software like QD (which still has the editor colours in 
its own config block as I felt these were not generic enough in usage).


With QPAC2 it was necessary to have a foreground colour and one 
other font colour, for which I created the name „middle ground“. 
This was part joke and part lack of a better name. Plus, nobody 
complained ;)


I never realized this could be interpreted as STRIP colour, 
especially as I actually defined one „STRIP“ colour, too: „Title 
text background“. I don‘t have my laptop with me, but I don‘t think 
there is the concept of a „STRIP“ colour in the data structures, so 
I probably never really considered it. Sorry for the confusion!


I was hoping that some day there would be a style guide, but 
adoption of the system palette was slow and finally I forgot about 
it. Still, many applications these days use them, so I consider them 
a success nonetheless.


One more thing: they are defined somewhat conservatively because if 
you give too many options thing get even more messy. I know Per was 
always on the rather bleeding edge of WMAN UI development so 
probably struggled a lot more with them than anybody who simply 
duplicated the QJump style.


Cheers, Marcel

Am 24.08.2018 um 14:45 schrieb pjwitte via Ql-Users 
:


There appears to be some inconsistency in the application of colour 
components of palettes by different software authors. Im referring 
in particular to the use of "middle ground". Correct me if Im 
wrong, but I assumed this option was reserved for use as the strip 
colour, ie the colour of the text background. Some authors do it 
this way, while others use the background (ie normally the paper 
colour) as text background. This can make texts like titles, info 
texts, and error messages unreadable, depending on the palettes used.


While it is possible to devise palettes that will work in either 
case, it sort of cramps one's style a bit. And the whole motivation 
for going to the trouble of devising palettes and systems, one 
presumes, is to make things simpler, more consistent - less 
mickymouse.


Unless it is already too late (ie the bug has become convention) it 
would be great if the next iteration of relevant documentation 
could firm up the convention that:


background is equivalent to PAPER colour,
middle ground is equivalent to STRIP colour, and
foreground is equivalent to INK colour,

if that is indeed the intention.

Perhaps authors too, would try keep this in mind when releasing 
updates?


Per


___
QL-Users Mailing List


___
QL-Users Mailing List

---
This email has been checked for viruses by AVG.
https://www.avg.com
___
QL-Users Mailing List



___
QL-Users Mailing List

[Ql-Users] colour confusion

2018-08-24 Thread pjwitte via Ql-Users

There appears to be some inconsistency in the application of colour 
components of palettes by different software authors. Im referring in 
particular to the use of "middle ground". Correct me if Im wrong, but 
I assumed this option was reserved for use as the strip colour, ie the 
colour of the text background. Some authors do it this way, while 
others use the background (ie normally the paper colour) as text 
background. This can make texts like titles, info texts, and error 
messages unreadable, depending on the palettes used.


While it is possible to devise palettes that will work in either case, 
it sort of cramps one's style a bit. And the whole motivation for 
going to the trouble of devising palettes and systems, one presumes, 
is to make things simpler, more consistent - less mickymouse.


Unless it is already too late (ie the bug has become convention) it 
would be great if the next iteration of relevant documentation could 
firm up the convention that:


background is equivalent to PAPER colour,
middle ground is equivalent to STRIP colour, and
foreground is equivalent to INK colour,

if that is indeed the intention.

Perhaps authors too, would try keep this in mind when releasing updates?

Per


___
QL-Users Mailing List

Re: [Ql-Users] Odd behavour of the DIR command?

2018-07-26 Thread pjwitte via Ql-Users


On 26/07/2018 14:50, Jan Bredenbeek via Ql-Users wrote:

What we really need, is a new file system! :)

I like the way DOS_DRIVE/NFA_DRIVE work in QPC2/SMSQmulator. You can 
"root" the device DOS/NFA anywhere in the host's filing system. The 
result is transparent to the rest of the system. This would be a way 
forward for any new filing system: The old (current) way of doing 
things could just be a hooked to the new in a similar way. Any old 
software would just continue to use the old system. On the emulators 
weve basically got a new file system already. "All" it would take 
would be for it to be better integrated into SMSQ/E and "one" should 
perhaps devise a new way to deal with that extra info that goes into 
the QDOS file header. Finally, to top it off, a hardware version 
should be made for any "hardware QLs" that can run SMSQ/E and a real 
harddisk.


Pinch me! Its not going to happen, is it?

Per

On 26 July 2018 at 13:24, Marcel Kilgus via Ql-Users <
ql-users@lists.q-v-d.com> wrote:


Has anybody got the source code to the SUB device? It does this kind
of substitutions.


I remember having done a disassembly some years ago. Will look when the
temperature here drops to non-tropical levels (it's now 35C :( ).



Another solution would be to make the DIR command 'substitution-aware' so
it would recognise a substituted device and act accordingly.

But then you have to do the same for QPAC2, QMenu, ...


Agreed. Wouldn't it be great if we would only see the names of the files
within a subdirectory and not the subdirectories themselves every time? But
I expect that this might break some other programs as well...

Jan.



___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

2018-06-29 Thread pjwitte via Ql-Users


On 28/06/2018 09:03, Wolfgang Lenerz via Ql-Users wrote:

Hi,

I made a small Sbasic testcase (SMSQE, not QDOS).

I made a program with procedures all called "abcdefghijklmnopqrt"+ a 5
digit number at the end.

The program starts at line 100, is increased by one and very 12th line a
new 10 line procedure is created. The first statement therein is
"return", so that I don't meausre the body of the procedure. The rest of
the lines on the procdure are filled with "Print".

(so
100 def proc abcdefghijklmnopqrt00100
101 return
102 print
...
110 print
111 end def
112 def proc abcdefghijklmnopqrt00112

etc, until just after line 3.

The last procedure then is always

31000 def proc abcdefghijklmnopqrt31000

I then measured how long it takes to call the first procedure and the
last procedure.

Measured with the millisecond timer of SMSQmulator:

calling the fist procedure 1 million times takes 5742 milliseconds
calling the last procedure 1 million times takes 5768 milliseconds

Strange. I wonder whats eating the 26 nanoseconds..
Per
___
QL-Users Mailing List

Re: [Ql-Users] Qdos/Sms reference manual

2018-06-11 Thread pjwitte via Ql-Users


Splendid! It all works now. Thank you! :)
Per
On 11/06/2018 07:36, Wolf via Ql-Users wrote:

Hi all,

new version on the site, should keep bookmarks etc..., thanks, Per, 
for pointing that out.


Wolfgang
___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] Qdos/Sms reference manual

2018-06-10 Thread pjwitte via Ql-Users


On 10/06/2018 09:48, Wolf via Ql-Users wrote:

Hi all,

the updated Qdos/Sms reference manual (v. 4.4) is now on my site.

Have fun!

Wolfgang 
Perhaps its just me, but it seems the PDF version has lost the 
bookmarks and the text is no longer searchable. Via some detours Ive 
restored both, but the resulting file is like 7x larger than the old 
one (now 7.5 Mb). Are you able to produce a more compact PDF with 
bookmarks and searchable text? If not you could have a copy of me. It 
is so much more practical.


Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI info incorrect

2018-06-09 Thread pjwitte via Ql-Users


Great, Wolfgang!
But surely, if you have something on the stack youd like to keep, you 
still need to save the stack pointer, otherwise how will the system know?


Per
On 09/06/2018 06:50, Wolf via Ql-Users wrote:

Hi,

I'll amend the documentation. I will also mention that this vector, 
under SMSQ/E, simply does nothing when called from a compiled 
program. I already added a note that under SMSQ/E it is not 
necessary to save the stack pointer in BV_RIP(A6) before calling 
this vector.


There are also other additions/corrections to the documentaton.

I'll release the new doc either today or tomorrow.

Wolfgang




On 08/06/2018 19:29, pjwitte via Ql-Users wrote:
Having gone through it all again, Ive come to the conclusion that 
the bugs are in the documentation! This is what it should look like:

||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI
Call parameters Return parameters
D1.L Number of bytes required  D1 ???
D2 D2.L ???
D3 D3.L ???
A0 A0 Preserved
A1 A1 ???
A2 A2 Preserved
A3 A3 Preserved
Error returns: none
In other words, in the case of insufficient memory this routine 
returns to a higher level; it never comes back here. There is no 
need, in fact it is a mistake, to test d0 on return from this routine.

If anyone knows otherwise then please let ut know!

Per
___
QL-Users Mailing List



___
QL-Users Mailing List



___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI info incorrect

Having gone through it all again, Ive come to the conclusion that the 
bugs are in the documentation! This is what it should look like:

||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI
Call parameters Return parameters
D1.L Number of bytes required  D1 ???
D2 D2.L ???
D3 D3.L ???
A0 A0 Preserved
A1 A1 ???
A2 A2 Preserved
A3 A3 Preserved
Error returns: none
In other words, in the case of insufficient memory this routine 
returns to a higher level; it never comes back here. There is no need, 
in fact it is a mistake, to test d0 on return from this routine.

If anyone knows otherwise then please let ut know!

Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI info incorrect


On 08/06/2018 17:16, Jan Bredenbeek via Ql-Users wrote:

On 8 June 2018 at 15:52, pjwitte via Ql-Users 
wrote:


When loading this into RESPR and then doing CALL base+4 I get an

'insufficient memory' error. But PEEK_L(base) returns 0 so the code never
got to the point where it stores the result.


Sure, but this is not the whole story. For example when I ran your code
just now in a daughter SBASIC, with no free memory, it returns ok, but
peeking result I get an err.ipar!
Depending on circumstances, there are a number of possible paths this
routine can take. From my own investigations (I wish Id written up what I
did, not only the conclusion!) in some cases this routine forgets to set
error code on a successful return.


Well the source code starts in
https://github.com/SinclairQL/SMSQE/blob/master/smsq/sbas/ressb_asm at line
40 (actual entry point at line 46):

;+++
; reserve stage posts SuperBASIC d1 bytes (optional), d1/d2/d3 smashed
;---
sbs_rar32
moveq #32,d1 ; the order of these instructions
; ; is critical for compatibility
moveq #sb_arthp,d2 ; with some QL software
bra.s sbs_dn

Then it jumps via a long jump to sbr_dn:

sbr_dn
cmp.l #sb.flag,sb_flag(a6) ; SBASIC?
bne.s sbr_nop
sub.l 0(a6,d2.l),d1 ; -(pointer - required)
add.l sb.loffp(a6,d2.l),d1 ; lower limit -(pointer - required)
bgt.s sbr_alldn

or it returned here

rts ..
sbr_nop
rts
Somehow the test for SBASIC at sb_flag(a6) failed and the routine returned
at sbr_nop, leaving D0 unmodified. Since on entry to a CALLed routine it
contains -15 (err.ipar), this is probably what happened.
Strange enough, when I tested this on a SBASIC daughter job, I got the same
result as before ('insufficient memory', no normal return), even when
running the commands in a program.
So when does the test for sb.flag at sb_flag(a6) fail? I think it's
probably a test for compiled (i.e. Qliberated or Turbo'ed) SBASIC?

or on this trajectory in the same file, ie via sbr_rtr, which would 
also not set D0.


sbr_retb
cmp.la6,a0; allocation in SBASIC?
blo.ssbr_retdo; ... no
cmp.lsp,a0
blo.ssbr_rtr ; ... yes, do not return it
sbr_retdo
moveq#sms.rchp,d0
trap #do.sms2
sbr_rtr
movem.l (sp)+,sbra.rgx
sbr_rts
rts

(Taken from the official sources and always reads ok ;)


Jan.



(I hope the assembly listing is readable, I copy-pasted them from GitHub).



___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI info incorrect


On 08/06/2018 14:29, Jan Bredenbeek via Ql-Users wrote:

On 8 June 2018 at 13:26, pjwitte via Ql-Users 
wrote:

It appears that, on an error, QDOS doesnt return here at all!
Correct.



Under SMSQ/E it may return an error (IMEM), but the error code is not
always set! That implies that you could get a wrong result, depending on
what was in D0 before the call.


I've tested this earlier using this code on SMSQmulator:

result   dc.l 0
  move.l   #16*1024*1024,D1
  move.w   $11a,a2
  jsr  (a2)
  lea  result(pc),a1
  move.l   d0,(a1)
  moveq#0,d0
  rts

When loading this into RESPR and then doing CALL base+4 I get an
'insufficient memory' error. But PEEK_L(base) returns 0 so the code never
got to the point where it stores the result.
Sure, but this is not the whole story. For example when I ran your 
code just now in a daughter SBASIC, with no free memory, it returns 
ok, but peeking result I get an err.ipar!
Depending on circumstances, there are a number of possible paths this 
routine can take. From my own investigations (I wish Id written up 
what I did, not only the conclusion!) in some cases this routine 
forgets to set error code on a successful return.


Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI info incorrect


On 08/06/2018 12:20, gdgqler--- via Ql-Users wrote:

On 14 Feb 2018, at 13:49, pjwitte via Ql-Users  wrote:

|In later versions of the QDOS and SMSQ/E Reference Manual the documentation on 
QA.RESRI (aka bv.chrix), to test or stretch the arithmetic stack states:

Vector $11A Reserve Room on Arithmetic Stack QA.RESRI
Call parameters Return parameters
D1.L Number of bytes required  D1 ???
D2 D2.L ???
D3 D3.L ???
A0 A0 Preserved
A1 Pointer to RI stack (rel. A6)   A1 ???
A2 A2 Preserved
A3 A3 Preserved
Error returns:
IMEM out of memory [SMSQ]
none [QDOS]

This is strongly suspected to be incorrect. It should say the following (two 
corrections):

||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI
Call parameters Return parameters
D1.L Number of bytes required  D1 ???
D2 D2.L ???
D3 D3.L ???
A0 A0 Preserved
A1 A1 ???
A2 A2 Preserved
A3 A3 Preserved
Error returns: none

D0 returns the error code under SMSQ but is corrupted under QDOS

It appears that, on an error, QDOS doesnt return here at all!
Under SMSQ/E it may return an error (IMEM), but the error code is not 
always set! That implies that you could get a wrong result, depending 
on what was in D0 before the call.


To my mind, SMSQ/E should behave the same way as QDOS in this 
instance, as many old toolkits will not test the error code, assuming 
that if the call returns, it implies there was no error. In other 
words, IMHO,  SMSQ/E's behaviour here is a  BUG.


Per

___
QL-Users Mailing List

[Ql-Users] iop.rptr

2018-06-05 Thread pjwitte via Ql-Users

According to documentation when this call returns it should update the 
pointer record with, among other things, the ID of the channel the 
pointer finds itself in. This it does perfectly well when bit 7 of the 
return vector is set, ie on a "special" move. But in all other cases 
it will only return the ID of a channel within the calling job's own 
outline.


I may be wrong but seem to remember that this was not always so. Is it 
a bug? After all the pointer position is being updated whether the 
pointer is within the calling job's outline or not..


Per

___
QL-Users Mailing List

[Ql-Users] QL wikis and information

2018-04-16 Thread pjwitte via Ql-Users

On 16/04/2018 18:14, Dave Park via Ql-Users, Re: Graphic objects and 
padding, wrote:

It's almost like we need some kind of public "infobase" or "programmer's
wiki" to make these nuggets easily searchable and reference-able.

Where might we find something like that?

PS: I offer free web hosting to anyone willing to run it.

On Mon, Apr 16, 2018 at 9:47 AM, pjwitte via Ql-Users <
ql-users@lists.q-v-d.com> wrote:
At present there is 
http://qdosmsq.dunbar-it.co.uk/doku.php?id=qdosmsq:start, which is a 
technical wiki. There is also 
http://qlwiki.qlforum.co.uk/doku.php?id=qlwiki:sinclair_ql_home_computer, 
which is more "historical".  There is of course lots more info out 
there, but it is widely spread around.


I had rather hoped the relevant people would pipe up here and trumpet 
their wares! The above request seems like a timely reminder.


A lot of this passes people by (and as we get older, some of us may 
need regular refreshers ;-) So it would be great if those of you 
sitting on valuable information could (re)introduce yourselves and 
briefly (or not) tell us about the essential hardware and software 
information you have in custody.

___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

2018-04-16 Thread pjwitte via Ql-Users


On 14/04/2018 20:01, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

If those who "wrote the book" on these matters arent able/willing to
pipe up, then we'll have to waste some time R-ingTFBs and doing the
tests ourselves. I'll be back.

"The books" were written so long ago, even the people who wrote them
must usually spend some serious time to answer questions like yours.

Regarding your question in the forum, the internal save area format
always has a "spare" long-word after each line, fuck knows why. So
that is why every line is 4 bytes longer, because it just writes out
the internal format. But it doesn't matter really, the "increment"
field in the file header is what's important, for all it's worth it
can be one 65kb per line and should still work, the field must just
match the data. If you construct a file yourself, use whatever line
increment pleases you.


The fog is slowly clearing :) Thanks for your input. I
assumed anyone "in the know" would just know the answer and
not have to waste precious hours figuring out what was
already known, as I did - and presumably many before me.
Trying to derive the rules  from the various implementors
proved frought, as it seems that, for pragmatic reasons (or
perhaps to compensate for other's non-compliance) they
mostly have their own rules for outputs and acceptable
inputs. Anyway, once Im certain, Ill write it up, so no one
needs to ask or answer this again.

Per
___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

2018-04-14 Thread pjwitte via Ql-Users


On 13/04/2018 17:46, Dilwyn Jones via Ql-Users wrote:

Could someone please explain the rules to me regarding the padding of
graphics objects for the two main formats: Sprites and Pics/PSA?

I thought Id worked it all out, at least for some modes, but my rule-
book does not appear to be complete, nor provide stable answers in 
all

cases. Also, there are some  formats Im not able to test.. So now Im
confused and would like to get a "definitive" take on the matter.

(...)


As I understand it,
Sprites must always be padded to Longs for all modes QL or GD2.

PIC/PSA must be padded for modes 4 & 8.
The GD2 modes 16 to 33 should/need not be padded and some viewers 
may have problems if they are.

SQRview will detect excess padding and not show it.

Bob
This agrees with my experience of sprites and PIC files from when I 
was writing Q-Dock. Some unusual things can happen if the sprites 
aren't long word padded.


I haven't much experience of PSA files, but since they are 
essentially PIC files with an extra long word in the preamble, I 
would assume they would handle exactly the same as PIC files after 
taking the extra long word into account.


Dilwyn 
Thanks for your replies, most of which agree with my understanding 
but, unfortunately, not with my recent experience. (Eg see my post on 
the Forum for one example: 
http://www.qlforum.co.uk/viewtopic.php?f=3&t=2272&start=40#p22823)


And that is the crux of the matter: Without a definitive description 
its each to his own interpretation. This is bad for those of us trying 
to produce fun or useful stuff. And the number of offerings out there 
that dont really work, or work inconsistently, dont exactly evoke the 
sense that "The QL" is a serious or relieable machine. It certainly 
puts me off at times (my own failings in this regard notwithstanding ;)


If those who "wrote the book" on these matters arent able/willing to 
pipe up, then we'll have to waste some time R-ingTFBs and doing the 
tests ourselves. I'll be back.


Per
___
QL-Users Mailing List

[Ql-Users] Graphic objects and padding

2018-04-13 Thread pjwitte via Ql-Users


Could someone please explain the rules to me regarding the padding of
graphics objects for the two main formats: Sprites and Pics/PSA?

I thought Id worked it all out, at least for some modes, but my rule-
book does not appear to be complete, nor provide stable answers in all
cases. Also, there are some  formats Im not able to test.. So now Im
confused and would like to get a "definitive" take on the matter.

Variables:
x%/y%
llen% = increment between lines
bpp   = bytes per pixel

The question relates to sprites, of QL modes and all the supported
GD2 modes: Are all lines to be padded to a size divisible by four?
In all modes?

Pic format objects:
QL modes:
I presume x% must always be divisble by 2?
All modes:
Must lines physically be padded beyond that, eg to be dividsible
by four?

If I can get definitive rules on this, Id be happy to write them up
and pass them on to the maintainers of the relevant documentation.

Per

___
QL-Users Mailing List

Re: [Ql-Users] FiFi

2018-03-31 Thread pjwitte via Ql-Users

Very nice! Thank you, Wolfgang. I bought the first version years ago 
and have updated since then, but hadnt realised that we werent still 
on V4.30.


BTW, Im not able to change the main display palette: Whatever I 
configure it to, it stays at no. 1 (no. 2, in FiFi parlance).


Having fun ;)
Per
On 30/03/2018 06:48, Wolf via Ql-Users wrote:

Hi all,

FiFi, my formerly commercial file finder can now be downloaded from 
my site.


www.wlenerz.com/qlstuff

Have fun!

Wolfgang
___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] QL Video Card?

2018-03-29 Thread pjwitte via Ql-Users


I found this little snippet in my files that I thought you might enjoy :o)

Per


 Masterpiece by Miracle Systems

The long awaited GRAPHICS CARD, now titled the "Masterpiece Enhanced 
Graphics Card” will soon see the light of day. The targeted selling 
price is £50 (may change).


The small circuit board  will  replace  the 8301chip (for those who  
have been  replacing 8301's the cost of the board alone is well  
worth  being done with the 8301)) and  will cause you to remove the 
68008 if you hadn’t already done so.


There are two displays, QL mode (512 x 512) or an enhanced graphics 
mode (1024 x 512 - requiring an SVGA non-interlaced monitor). Software 
to drive the new board will reside in a new ROM to be issued for the 
Super Gold Card (required for enhanced graphics). Masterpiece will 
have 128K of video ram on board.


Those of  you  with Gold Cards will get the benefit of  replacing the 
costly 8301 chip and the ability to upgrade in the future, who knows 
maybe the Super Gold Card or maybe even the Super-Duper Gold Card (the 
last one, at present is only in our publishers mind).


What are you waiting for ?? Give yourself a Christmas present! I Call 
Miracle Systems for further information.


36

On 30/03/2018 01:28, Peter Graf via Ql-Users wrote:

Am 29.03.2018 um 22:59 schrieb Marcel Kilgus via Ql-Users:

(By the way, I wish Stuart had finished his QL Graphics Card,
because all the video converters I tried with my QLs suck.)

Yes, this is true. That's the reason I have built a prototype of a
bus-snooper that mirrors the QL screen on an HDMI monitor, but... damn
it, now that you know I will never finish it :-)

Believe it or not, but when I wrote my remark this noon, I was actually
thinking "that could be something for Marcel Kilgus" now that he started
playing with FPGA. Really.

My guess is that you'd use an FPGA with >=32 KB RAM, so why bus-snooping
and not fully replace the video area? Just to keep the original video
output alive?

How would you work around the HDMI licensing costs issue?

Personally, I still prefer VGA, because I also have some older monitors
and converting VGA to HDMI can be done by small cheap dongles.

Peter
___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] Sjef vd Molengraaf

2018-03-09 Thread pjwitte via Ql-Users


Thanks Sjef, for arranging those great shows at Eindhoven!
And thanks Bob, for letting us know.

Per
On 09/03/2018 16:35, Bob Spelten via Ql-Users wrote:


I am sad to inform you all that Sjef van de Molengraaf passed away 
earlier this week at the age of 73.
As long time secretary of the Dutch SIN_QL_AIR foundation he will be 
remembered by many international QL'ers. He was the driving force 
behind many great Eindhoven meetings during the 90's and later, 
until they ended in October 2008.
He seldom posted on this list but it kept him informed of what was 
going on in the QL community.


Our thoughts are with his family.

Bob



___
QL-Users Mailing List

Re: [Ql-Users] R: Source code availability for Minerva v1.92 or v1.89?

2018-03-01 Thread pjwitte via Ql-Users


Great!! I want my money back! ;)

On 01/03/2018 21:14, Wolf via Ql-Users wrote:

Hi,

TT told me some time ago that it was alright to have Qmon downloadable.

Wolfgang
___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-26 Thread pjwitte via Ql-Users


Well caught, Marcel :)
Per
On 27/02/2018 00:00, Marcel Kilgus via Ql-Users wrote:

Martyn Hill via Ql-Users wrote:

Specifically, when receiving via LBYTES (and SBYTES at the remote end),
Minerva 1.97+ on its own receives perfectly, but once the NET driver is
effectively replaced with TK2 (upto v2.23), issuing LBYTES will
completely hang the /receiving /QL - immediately and regardless of
whether the sending end has even started.

I had a quick look and actually this was caused by Lau trying to save
2 bytes. When you look at io_serio_asm

io_pend
*moveq   #0,d0   test routine is the first element
 bsr.s   vectest set up test routine address
 bra.s   callit  go do it

you see that the moveq is commented out because "d0 is 0 anyway!".
Well, except in the case when io_pend is called through headr1, in
this case D0 has some other value and the whole thing will crash.

I hope you can now resume more productive work :-)

Cheers, Marcel

___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-25 Thread pjwitte via Ql-Users


Ok.
On 25/02/2018 21:05, Martyn Hill via Ql-Users wrote:

Hi Per

That would be excellent - thank you!

I'll rely on Google to translate what I can't decipher of the German.

I'll PM you via the QL Forum with my personal email, if that's alright.

Thanks again!

M.


On 25/02/2018 18:56, pjwitte via Ql-Users wrote:
I have a commented (in German!) disassembly of V1.89, if thats of 
any interest. It seems quite thorough and detailed, but Ive not 
tried to reassemble it. Let me know where to send it if you want it.


Per
On 25/02/2018 15:51, Martyn Hill via Ql-Users wrote:

Hi everyone!

I'm looking to get a hold of the *source *for either of *Minerva 
v1.92 *or *v1.89*. We have v1.98 source available, which I have 
poured over for /many /an hour... 

<>
___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-25 Thread pjwitte via Ql-Users

I have a commented (in German!) disassembly of V1.89, if thats of any 
interest. It seems quite thorough and detailed, but Ive not tried to 
reassemble it. Let me know where to send it if you want it.


Per
On 25/02/2018 15:51, Martyn Hill via Ql-Users wrote:

Hi everyone!

I'm looking to get a hold of the *source *for either of *Minerva 
v1.92 *or *v1.89*. We have v1.98 source available, which I have 
poured over for /many /an hour... 

<>
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide


On 16/02/2018 22:12, pjwitte via Ql-Users wrote:
<>
If Ive understood correctly, SBASIC sets up each array in its own 
heap. This assumption was partially or wholly incorrect. Sorry. I'll shut up 

now.

P
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide


On 16/02/2018 12:50, pjwitte via Ql-Users wrote:

On 16/02/2018 10:27, Jan Bredenbeek via Ql-Users wrote:

<>
SBASIC bahaves in much the same way as QLiberated programs. I guess 
QLib has always used the Common Heap for its names and variables, as 
SBASIC does now. Also a6 is fixed under both models (and Turbo); the 
only reason to double index references is where it is necessary to 
maintain compatibility with SuperBASIC.



I made a quick test today regarding what I stated above about QLib:

10 ch = FOPEN('con')
11 m = FREE_MEM
12 DIM a$(32000, 200)
13 PRINT#ch; HEX$(m - FREE_MEM, 32)
14 PAUSE#ch

I compiled it with QLib; dataspace 3.5Kb. It proves that QLib reserves 
memory in the CHP rather than being bound within its dataspace. Some 
470 bytes additional to the array+descriptor requirements were taken, 
so whether it performs the same stunt as SBASIC and creates a whole 
new name table/name list area once it outgrows an old one, or just 
reserves room for the array and some extra, is not revealed by this 
simple test.
I seem to recall, back in the mists of time, that QLib (or was it 
SuperCharge?) had this restriction: Everything had to fit within the 
dataspace; if you DIMed large arrays etc, you needed to increase your 
dataspace accordingly.
If Ive understood correctly, SBASIC sets up each array in its own 
heap. That doesnt seem to be the case with QLib, but I cant say for sure..

P

___
QL-Users Mailing List

Re: [Ql-Users] A polite request


On 15/02/2018 21:07, Norman Dunbar via Ql-Users wrote:
<> There is plenty one could moan about on this list if one were 
thus inclined. Nuff said.


Oh, I would tend to disagree there. Respectfully disagree of course. 
I think this is one of the better lists I enjoy reading - even when 
the subject has little or no interest for me - and responding to as 
and when appropriate. 
I was thinking more of how (physically) messy it sometimes gets. The 
excuses I make for others in such instances is that it may have to do 
with how familiar they are with evolving vagaries of their various 
email clients. When Im forced to use Google's webmail interface, I 
have no idea what the result looks like for anyone else. It tries too 
hard to be helpful in doing stuff I just dont want done! Ive had the 
extreme annoyance and embarassment of accidentally forwarding 
information sent by one party to another that wasnt supposed to see 
that information. This despite the efforts I made to ensure it didnt 
happen. The only upside to such potential calamity is that other 
people do it too, and so one may acquire useful information one was 
not supposed to have ;)


Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide


On 16/02/2018 10:27, Jan Bredenbeek via Ql-Users wrote:

<>
What puzzles me however is that, in case more space from the system is
needed, this is done using a call to sms.achp (mt.alchp) rather than
mt.albas. So the extra space seems to be allocated in the Common Heap
rather than the S*BASIC area. Now I know that SMSQ/E has a memory
allocation scheme that's different from good old QDOS in some respects, but
I'm curious about the rationale behind this. When space for the RI stack
(or any other S*BASIC area for that matter) is allocated from the Common
Heap, there would be no problem extending this to compiled programs
(assuming they won't expect their data to be somewhere in the TRNSP area).
SBASIC is very different from SuperBASIC. It uses a fixed memory 
model. Different parts of each instance of SBASIC live in their own 
areas. Only the bit that is called  the SuperBASIC Stub - which is a 
minimalist version of the old SuperBASIC area - is movable in the old 
sense, and subject to expansion or contraction by the now emulated 
MT.ALBAS/REBAS traps. The Stub is only there for reasons of 
compatibility with a small subset of once popular - and now 
unnecessary - programs.


SBASIC name tables and name lists reside in the Common Heap. When 
these need to expand, new areas are allocated in the common heap, and 
the necessary bits are moved over, and pointers adjusted accordingly. 
Each SBASIC has its own local name table/list, but there is also a 
global name table from which entries may be copied during parsing.


SBASIC bahaves in much the same way as QLiberated programs. I guess 
QLib has always used the Common Heap for its names and variables, as 
SBASIC does now. Also a6 is fixed under both models (and Turbo); the 
only reason to double index references is where it is necessary to 
maintain compatibility with SuperBASIC.


There is relatively detailed documentation floating about, but, for 
some reason, it isnt easy to find.


Per


___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide


On 15/02/2018 18:42, pjwitte via Ql-Users wrote:


     move.w qa.resri,d0
     moveq #0,d0
     jsr (a2)
     tst.l d0


Err, that should be move.w qa.resri,a2, but I guess that's pretty 
obvious. The next bit isnt obvious, but is correct.


Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide


On 15/02/2018 14:46, Wolfgang Lenerz via Ql-Users wrote:
<>

Thanks for testing these.

How big was the amount of memory requested? Big enough that a shift 
would occur?



Yes.
Further tests show that d0 sometimes returns zero (at least two 
different paths) but usually not, ie it returns with the pre-call 
value intact. If insufficient memory, it returns to BASIC. In other 
words, to get a reliable error result, one would have to:


    move.w qa.resri,d0
    moveq #0,d0
    jsr (a2)
    tst.l d0

This is obviously not ideal..

I havent done any tests with either compiler, but Ive already lost two 
hours of my life I'll never get back, so if someone else wants to have 
a go, I promise to read - and cherish - the results :)


Per
___
QL-Users Mailing List

Re: [Ql-Users] A polite request


On 15/02/2018 14:32, Marcos Cruz via Ql-Users wrote:

En/Je/On 2018-02-14 19:40, Norman Dunbar via Ql-Users escribió / skribis
/ wrote :


Please, please, please do not "hijack" a thread. Don't reply to a
thread and change the subject to something completely unrelated.

I agree. That is important. I support your request.

<>
For my part, I believe Ive apologised very handsomely for the error of 
my ways (although any forgiveness still seems to be working its way 
though my accuser's brain) so I have no more to give on this and 
require no further instruction. Nor will I take kindly to any further 
reprimand on the topic. There is plenty one could moan about on this 
list if one were thus inclined. Nuff said.


Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

I think the whole thing bears further investigation, as there appears 
to be doubt about other aspects too. Jan Bredenbeek, for example, 
suggests that:


Call parameters                         Return parameters
..
A1                                     A1 Preserved

He was going to investigate the various OS sources, and perhaps is 
still busy doing so.. Jan..?


What there seems to be general agreement on,  contrary to current 
documentation,  is that 1) what is in A1 is irrelevant to this call, 
and 2) that the routine doesnt return on the only possible error: IMEM.
Minerva, apparently, returns D0 = 0 on a successful return (because 
QLib requires it according to one source?) but for the other OSes it 
is undefined. (I dont doubt that Minerva does so, but that QLib should 
require it is news to me..)
As for BV_RIP (aka sb_arthp), my understanding is that if you have 
information on the stack prior to this call, that you wish to keep, 
you do need to set BV_RIP to point to it. Example:


    get three longs
    do stuff..
; you want to keep the first long on the stack and loose the rest
    addq.l #8,A1                    ; A1 -> long on stack
    do some more..
; now you want ten more bytes, but dont want to loose the long, so you
    move.l A1,BV_RIP(A6)
    moveq #10,d1                    ; request 10 bytes (but in effect 
you only want two more)
    to save or not save A1 here, that is the question.. (SMSQ/E 
appears to preserve it)

    move.w BV.CHRIX,A2
    jsr (A2)
; dont bother testing D0 here.. (SMSQ/E appears to set D0 to 0, but 
not JS)

    sub.l #10,BV_RIP(A6)            ; grab the extra ten bytes
    move.l BV_RIP(A6),A2            ; A2 -> 10 (+ 4) bytes on stack
    do stuff here..
; say you want to return a word integer to BASIC
    lea.l 12(A2),A1                ; add the difference and put into A1
    move.l A1,BV_RIP(A6)
    move.w Dx,(A6,A1.l)            ; put your return value on the stack
    now return int to BASIC

What we still dont know for sure is if A1 is preserved after the call 
in all variants of the OS.


Update:
After sribbling down the example above, I decided to "weaponise" it to 
test the following three premises:

1) Is A1 preserved?: JS, Minerva and SMSQ/E all appear to do so
2) Is D0 set to 0 after BV_CHRIX?: JS: No. Minerva & SMSQ/E: Yes
3) Are items on the stack preserved after BV_CHRIX (as described 
above)?: JS, Minerva & SMSQ/E: Yes
Incidentally, running the test in various typical configurations to 
test stack leakage showed it to be copper bottomed; ie, no leaks.


Obviously, these are limited tests as I cannot create the environment 
to challenge every case, so it will be down to the code peekers to 
make any final determination. If anyone wants my code to test on AH 
and other exotica, you know where I live..


Per
On 15/02/2018 05:08, Wolf via Ql-Users wrote:

Hi,

thanks, Per, for pointing out the inconsistencies in the entry 
conditions in vector QA.RESRI.


I'll make a note in the next version of the "QDOS SMS Reference 
guide" (ex Technical Manual and ex QDOS SMS reference manual) that 
on SMSQ/E it is not necessary to save the stack pointer in 
BV_RIP(A6) before calling this vector. However, I'm going to leave 
the general requirement in, since I don't know how this is handled 
in QDOS (AH, JM, JS etc), or in Minerva.



Wolfgang
___
QL-Users Mailing List




___
QL-Users Mailing List

Re: [Ql-Users] A polite request

Ah, I see. Although I too use Thunderbird (except when Im on the hoof) 
I never realised thats how it worked. Very sorry. Pure ignorance not 
callous disregard for anyone's finer sensitivities. Also, being 
slightly dyxlespic I forget whether top or bottom posting is /de 
rigueu/r on this list. I remember that getting it wrong drove poor 
Tony Firshman spare! Sadly he hasnt been around for a while to give us 
a timely reminder. Anyway, this may be a good time to remind ourselves 
of Napoleon's excellent maxim: Dont put down the malice that which can 
adequately be explained by incompetence!


Per
On 14/02/2018 21:24, Norman Dunbar via Ql-Users wrote:

Hi Per,

On 14/02/18 20:21, pjwitte via Ql-Users wrote:
If Ive sinned, Norm, please forgive. Are you refering to anything I 
did? I ax cause I havent noticed the problem, so perhaps I missed 
something?
Anyway, enjoy your wine, although I would have thought a hot toddy 
would bring more cheer after your wet waddle to Waitrose..


Per


on this occasion, you just happened to be the victim, yes. Other 
culprits have done it before, not just to me though. So worry ye not!


I also get this on some Oracle lists that I follow for work, it's a 
right pain, and even when the mods tell people off, they still do it.


I'm currently scoffing a hot, decaf latte, one wine a  night midweek 
is enough, I need to be up early tomorrow and at work by 7AM.



Cheers,
Norm.



___
QL-Users Mailing List

Re: [Ql-Users] A polite request

If Ive sinned, Norm, please forgive. Are you refering to anything I 
did? I ax cause I havent noticed the problem, so perhaps I missed 
something?
Anyway, enjoy your wine, although I would have thought a hot toddy 
would bring more cheer after your wet waddle to Waitrose..


Per
On 14/02/2018 20:40, Norman Dunbar via Ql-Users wrote:

Good Evening All,

my wife is currently in Central America, chasing sloths, and I've 
been lambasted because she didn't get her Valentine's card. Go 
figure, it's waiting here for he but that's not good enough - I 
should have hidden in in her suitcase!


That's just so you know what kind of night I'm having, plus, is 
pi55ing down and I'm soaked having just (stupidly) decided to walk 
to the supermarket. And back, with the shopping!



Right, the request...

Please, please, please do not "hijack" a thread. Don't reply to a 
thread and change the subject to something completely unrelated. 
Thanks.


It's a complete pain in the backside (see, I'm being polite!) when I 
miss out on some interesting topics because someone has replied to 
another thread that I'm not following.


It's especially painful when someone replied to my threads - I don't 
tend to read my own stuff after the topic has come to a graceful 
conclusion, so the new topic thread remain hidden within my 
ramblings. I just noticed a new topic thread hidden in my recent 
"Assembly language ePeriodical Issue 4" thread.


I use Thunderbird, I have it configured to list emails in threads, 
and in reverse date order with most recent first. If you start a new 
thread by replying to another, and change the subject, your threaded 
topic ends up hidden within the original topic thread and I miss out 
on stuff!


Anyway, I just wanted to get that off my chest!

Cheers,
Norm.

PS. Yes, I have had a large glass of crisp white wine tonight! ;-)



___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI info incorrect


On 14/02/2018 15:04, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

Error returns:
IMEM out of memory [SMSQ]

This is correct.
If this is correct, isnt that bad news for any old toolkits that dont 
expect the call to return on IMEM (as per the original Technical 
Guide)? They would assume the memory is there and poke a hole in it..



A1                                     A1 ???

This is probably correct.


Error returns: none

This is not ;-)

You are certain of this? Some of us have tried to follow some of the 
many paths this routine could take, and at least in some instances it 
appears to actually return to BASIC directly. So are you saying that 
in some instances it dosnt?

___
QL-Users Mailing List

[Ql-Users] QA.RESRI info incorrect