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$$
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

2018-08-28 Thread pjwitte via Ql-Users

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

2018-08-28 Thread pjwitte via Ql-Users

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

2018-08-28 Thread pjwitte via Ql-Users

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

2018-08-28 Thread pjwitte via Ql-Users
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

2018-08-28 Thread pjwitte via Ql-Users

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] 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

2018-06-08 Thread pjwitte via Ql-Users
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

2018-06-08 Thread pjwitte via Ql-Users

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

2018-06-08 Thread pjwitte via Ql-Users

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

2018-06-08 Thread pjwitte via Ql-Users

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=2272=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

2018-02-16 Thread pjwitte via Ql-Users

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

2018-02-16 Thread pjwitte via Ql-Users

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

2018-02-16 Thread pjwitte via Ql-Users

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

2018-02-16 Thread pjwitte via Ql-Users

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

2018-02-15 Thread pjwitte via Ql-Users

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

2018-02-15 Thread pjwitte via Ql-Users

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

2018-02-15 Thread pjwitte via Ql-Users

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

2018-02-15 Thread pjwitte via Ql-Users
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

2018-02-14 Thread pjwitte via Ql-Users
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

2018-02-14 Thread pjwitte via Ql-Users
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

2018-02-14 Thread pjwitte via Ql-Users

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

2018-02-14 Thread pjwitte via Ql-Users
|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

Please complain if you know otherwise, or correct your notes, as 
appropriate


Per
|||
___
QL-Users Mailing List

Re: [Ql-Users] Re-upping QL-SD new driver [OT]

2018-01-24 Thread pjwitte via Ql-Users

On 24/01/2018 06:34, Wolf via Ql-Users wrote:

Hi Per,


Keep on dealing! :)



Are you waiting for the next bug-fix?

Sure :D
Got anything cooking?
P


Wolfgang 


___
QL-Users Mailing List


[Ql-Users] Re-upping QL-SD new driver [OT]

2018-01-23 Thread pjwitte via Ql-Users

On 23/01/2018 11:33, Wolfgang Lenerz via Ql-Users wrote:

Hi,


Re-upped! Been watching The Wire? -

The wire?
I dont want to muddy the list with OT, but I think its only polite to 
reply:

The Wire is a US TV series about the drug epidemic in Baltimore, and no
doubt elsewhere in Americastan. (Its not for everybody, but is often 
rated
as one of the better TV series of its time.) Id never heard the 
expression

"re-upping" before watching it, so I assumed, wrongly obviously, that you
were a secret admirer too. In that context re-upping means re-supplying
your pushers (and if youre a junky, presumably, yourself) with drugs.

Well, youre certainly keeping us QL junkies happy! ;)

That's an unintended side-effect.


Keep on dealing! :)

Per
___
QL-Users Mailing List


Re: [Ql-Users] QL-SD new driver

2018-01-23 Thread pjwitte via Ql-Users

On 23/01/2018 05:48, Wolf via Ql-Users wrote:

> done, re-upped with the keys.

Ah, thats better, thanks :)

Re-upped! Been watching The Wire? - Well, youre certainly keeping us 
QL junkies happy! ;)


Per
BTW, I forgot to add that the driver is for v. 0.82 of the 
interface. If you have v. 0.75, please holler!!


Wolfgang

On 22/01/2018 17:08, pjwitte via Ql-Users wrote:

On 22/01/2018 10:41, Wolfgang Lenerz via Ql-Users wrote:

Nice one, Wolfgang :)

The sources state: include 'DEV1_q68_qlsd_keys', but I cant find 
the file anywhere..


Per

Hi all,

I've released a new driver for QL-SD that uses standard qxl.win 
drives

instead of Qubide ones.

It's for Minerva only, though.

You can download it from www.wlenerz.com/QLSD

Have fun.

Wolfgang
___
QL-Users Mailing List





___
QL-Users Mailing List



___
QL-Users Mailing List


.



___
QL-Users Mailing List


Re: [Ql-Users] QL-SD new driver

2018-01-22 Thread pjwitte via Ql-Users

On 22/01/2018 10:41, Wolfgang Lenerz via Ql-Users wrote:

Nice one, Wolfgang :)

The sources state: include 'DEV1_q68_qlsd_keys', but I cant find the 
file anywhere..


Per

Hi all,

I've released a new driver for QL-SD that uses standard qxl.win drives
instead of Qubide ones.

It's for Minerva only, though.

You can download it from www.wlenerz.com/QLSD

Have fun.

Wolfgang
___
QL-Users Mailing List





___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-21 Thread pjwitte via Ql-Users

On 21/01/2018 10:26, Fabrizio Diversi via Ql-Users wrote:

Must be a pretty ancient Mac Book Pro if it still has a serial port. 
Mine is from 2008 and doesnt.
<> the "PC" is a Mac Book pro using Win10 with Parallels...and 
finally QPC. 

<>
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-20 Thread pjwitte via Ql-Users

On 20/01/2018 13:04, Derek via Ql-Users wrote:


<> Not tried Atari ST QL emulator yet.
The QVME graphics card used with the ST has a fast serial port. I got 
the best speeds with that. 230k, I believe, between my Mega ST + QVME 
and a PC (in the days when PCs had real serial ports).


Per

<>

___
QL-Users Mailing List


Re: [Ql-Users] Ql-Users Digest, Vol 167, Issue 2

2018-01-05 Thread pjwitte via Ql-Users

Hehe! Spot on, Tobias
Per
On 05/01/2018 15:49, Tobias Fröschle via Ql-Users wrote:

AF = Awfully faulty
JM = jerkily mended
JS = just stable
MG = mainly good

;) (just joking)

Tobias


Am 05.01.2018 um 12:56 schrieb Norman Dunbar via Ql-Users 
:

Hi Paolo,

as far as I remember, the code letters for the various QL ROMs have been named 
after:

* Taxi Drivers used by Sinclair staff;
* Engineers at Sinclair;
* Women in the Sinclair offices.

There may bo other "uses", but the letters in JM and JS etc are the initials of 
certain people from the above list. I have not seen a full list of the various names 
actually used though, so I can't tell you who JM and JS were. Sorry.


HTH

Cheers,
Norm.

On 04/01/18 18:30, Paolo Del Bene via Ql-Users wrote:

Today's Topics:
1. Re: about JM and JS roms
 (Paolo Del Bene)
 34 years are passed, and I haven't
 anymore a QL Sinclair from 27
 years when my father before bought
 it for me and then he sold without to
 say nothing to me.
 I am here only to ask for what stand
 the name JM and JS in the roms.
 I haven't found any information
about, if you can help me I'll be
 happy
 Happy GNU Year 2018
 Paolo Del Bene iw0fzw



--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
27a Lidget Hill
Pudsey
West Yorkshire
United Kingdom
LS28 7LG

Company Number: 05132767
___
QL-Users Mailing List

___
QL-Users Mailing List





___
QL-Users Mailing List

Re: [Ql-Users] Merry Christmas with SMSQ/E

2017-12-31 Thread pjwitte via Ql-Users

On 30/12/2017 16:10, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

Thanks, Marcel. Yes, I thought you might enjoy this little holiday
from "industrial" programming ;)

Oh well, I'm already swamped with non-industrial work, I have so many
ideas and projects on what to do that I hardly ever manage to finish
anything :-( I even started designing PCBs for fun and probably no profit.

Well, thats how the really Big Ideas are sometimes born :)

BTW, no criticism was ever intended of the creators of either SMSQ/E
or DISA!

Ah yes, DISA indeed still has some bugs, I occasionaly stumple upon
them, too. It might even be that I introduced some more in 3.05, I
don't know, but DISA is strictly "end of life" for me. The source code
(all assembler) is very complicated, life's too short to trying to
understand it. But if anybody REALLY wants to invest a few days or
even weeks of ones life to improve it, contact me...

Thanks for the warning. I pass ;)

Per
___
QL-Users Mailing List


Re: [Ql-Users] Merry Christmas with SMSQ/E

2017-12-30 Thread pjwitte via Ql-Users
Thanks, Marcel. Yes, I thought you might enjoy this little holiday 
from "industrial" programming ;)


BTW, no criticism was ever intended of the creators of either SMSQ/E 
or DISA! Bugs are a fact of life, and not even Nature is imune (My 
brain is full of them, for starters - and thats not the inter-festive 
DT's talking!) The deeply philosophical line 5 (in the light of line 
4) in the first code sample, is for anyone to ponder in the New Year - 
for which I wish y'all a happy one!..


Per
On 30/12/2017 13:39, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

If you want a really miserable Christmas, you could try the following
- without saving your work first:

1 x% = 32000
2 y% = x%
3 z% = 1600
4 t  = x% * y% * z%: REMark Kabm!!!
5 PRINT "-- Im dead!"

Nice find and, as usual, good repro, thanks. As good as TT's code
usually is, here he has used too many "magic numbers" instead of
speaking EQU symbols and promptly used the wrong number (6 instead of
8) when calculating a code offset. I will send Wolgang the fix for the
next release.

What's happening:

1. "x% * y%" is "int16 * int16" and results in an "int32"
2. Then z% in "* z%" is promoted to "int32" so the operation is "int32 * int32"
3. It checks if the result will overflow, which it will in this case,
so the operands are converted to "float" and it retries again using the
"float * float" code path
4. But the code to retry jumps back into the "int32 * int32" path instead
of the "float * float" path and hilarity ensues. This path has never
worked since the dawn of SBasic :-o


The above crashes SMSQ/E 3.32 on QPC2 and SMSQmulator! Even the
four-finger reset wont work. The following is, as youd expect, fine:

1 x% = 32000
2 y% = x%
3 z% = 1600
4 t  = x% * y%
5 t  = t * z%
6 PRINT "Yippi! - Im still alive!"

"t" is float in this case, so "t * z%" is "float * int16". In this
case z% is promoted into a float, so the operation is "float * float"
from the start and everything is happy.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] New document on DV3 drivers

2017-12-29 Thread pjwitte via Ql-Users

Thanks, Wolfgang. Youre very helpful, as always  :)

Yes, I meant drives, of course.

Some programs, such as Qpac2 Files and Qmenu's DIR_ and FILE_SELECT$ 
seem to assume a maximum of 8 DDDs so, presumably, devices beyond that 
would not be accessable via these programs.


Per

On 29/12/2017 15:47, Wolf via Ql-Users wrote:

Hi Per,


1) Is there is a limit to the number of directory device drivers 
that can be loaded at once (I believe there is/was and the number 
was 8?)


No, there is no limit that I'm aware of. I'm pretty sure I already 
had more than 8 different devices loaded at some time. (you can test 
this with the sub device, jut use Wined or some such to change the 
device name every time and load it 10 times)




2) Is there is a limit of 16 devices (ie driver + device number 
1..8) that can be in use at the same time?


It is true that only 16 drives (not devices) can be accessed at once.
This limit is set in the system variables :

sys_fsdd equ    $0100   16*long pointers to Filing System Drive
    Definitions
sys_fsdt equ    $0140   Filing System drive Definition table Top
sys.nfsd equ    $10 max Number of Filing System Drive definitions
sys_fsch equ    $0140   long    linked list of Filing System CHannel
    blocks

Back in the day, I seem to recall that once one had accessed one's 
allotted 16 devices, no further devices could be opened. (One had 
to do a DEL_DEFB to proceed.) 


Yes, except that it's drives, not devices.
So if you have files open on flp1 ... flp8 and win1 ...win8 - that's 
it.


Recently I discovered that if a device is no longer in use, its 
slot will be re-used, but I havent seen this documented anywhere. 
Do you have information on any of this?


Not without checking in the source code, but I'm pretty sure that 
this is the correct scheme.


HTH

Wolfgang
___
QL-Users Mailing List





___
QL-Users Mailing List

Re: [Ql-Users] New document on DV3 drivers

2017-12-29 Thread pjwitte via Ql-Users

On 29/12/2017 08:06, Wolf via Ql-Users wrote:

Hi all,

I've added a small technical explanation of DV3 drivers for SMSQE to 
the additional info and data section on the SMSQE site.


Have fun

Wolfgang

Very nice, Wolfgang. Thank you!

I have two questions (for now) which dont appear to be answered:

1) Is there is a limit to the number of directory device drivers that 
can be loaded at once (I believe there is/was and the number was 8?)


2) Is there is a limit of 16 devices (ie driver + device number 1..8) 
that can be in use at the same time? Back in the day, I seem to recall 
that once one had accessed one's allotted 16 devices, no further 
devices could be opened. (One had to do a DEL_DEFB to proceed.) 
Recently I discovered that if a device is no longer in use, its slot 
will be re-used, but I havent seen this documented anywhere. Do you 
have information on any of this?


Per
___
QL-Users Mailing List


[Ql-Users] Buggy Christmas

2017-12-28 Thread pjwitte via Ql-Users

Re: [Ql-Users] Merry Christmas with SMSQ/E

Probably spotted by Dilwyn years ago, only weve forgotten.. ;)

It was a bad day for me for sure, as shortly after, thinking lightning 
wouldnt strike twice (and thus not being in a hurry to save..), I 
managed to bomb out again by feeding DISA 3.05 with a simple, chained 
sprite. One sprite was a mode 8 chained to a mode 4, and later, I 
tested a dynamic sprite: Two mode 4 sprites in a loop: Load into DISA, 
press defp and DO on the first line and.. well, you almost guessed it; 
it was more of a Ka-pfiffle, followed by wailing sirens..


Per
On 28/12/2017 16:44, Wolf via Ql-Users wrote:

Hi,

yes, that part of SMSQ/e probably hasn't been touched for ages.

Wolfgang


On 28/12/2017 13:44, Bob Spelten via Ql-Users wrote:
Op Thu, 28 Dec 2017 07:43:13 +0100 schreef Wolf via Ql-Users 
:



Hi,
yes that's a bug.
Somehow the return stack gets confused/overwitten (stack 
overflow!), causing a jump to a strange address where you then 
will get an illegal instruction error.
I've checcked that, under SMSQmulator this isn't due to the 
replacemnt FP routines, which it isn't.



It looks like it's an old bug.
On my SGC/AUR (SMSQ/E v3.26) the Kaboom is modest.
No error is reported, it just freezes after one howl from Sysmon.
No keyboard or mouse response anymore.

Bob


___
QL-Users Mailing List





___
QL-Users Mailing List


[Ql-Users] Merry Christmas with SMSQ/E

2017-12-26 Thread pjwitte via Ql-Users
If you want a really miserable Christmas, you could try the following 
- without saving your work first:


1 x% = 32000
2 y% = x%
3 z% = 1600
4 t  = x% * y% * z%: REMark Kabm!!!
5 PRINT "-- Im dead!"

The above crashes SMSQ/E 3.32 on QPC2 and SMSQmulator! Even the 
four-finger reset wont work. The following is, as youd expect, fine:


1 x% = 32000
2 y% = x%
3 z% = 1600
4 t  = x% * y%
5 t  = t * z%
6 PRINT "Yippi! - Im still alive!"

Per
___
QL-Users Mailing List

Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread pjwitte via Ql-Users

Thanks :)
On 16/12/2017 19:36, Peter Graf via Ql-Users wrote:

The least significant of the 6 green bits.

Am 16.12.2017 um 19:12 schrieb pjwitte via Ql-Users:

Sorry for yanking your chain again so soon but, on going the other
way, ie from mode 32 to 33, what is the best value for W? g6, 0, 1..?

Per

On 16/12/2017 18:13, pjwitte via Ql-Users wrote:

Aah! Perfect! Thanks Marcel, youre a star!

So in fact I interpreted the input wrong. It should have been:

GGGggRRR rrBBBbbW <- input

and
ggWBBBbb RRRrrGGG -> output

Seems so obvious now ;)

Per

On 16/12/2017 15:30, Marcel Kilgus via Ql-Users wrote:

320 c$ = c$(4 to 5) & c$(16) & c$(11 to 15) & c$(6 to 10) & c$(1 to 3)


___
QL-Users Mailing List




___
QL-Users Mailing List

___
QL-Users Mailing List





___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread pjwitte via Ql-Users
Sorry for yanking your chain again so soon but, on going the other 
way, ie from mode 32 to 33, what is the best value for W? g6, 0, 1..?


Per

On 16/12/2017 18:13, pjwitte via Ql-Users wrote:

Aah! Perfect! Thanks Marcel, youre a star!

So in fact I interpreted the input wrong. It should have been:

GGGggRRR rrBBBbbW <- input

and
ggWBBBbb RRRrrGGG -> output

Seems so obvious now ;)

Per

On 16/12/2017 15:30, Marcel Kilgus via Ql-Users wrote:

320 c$ = c$(4 to 5) & c$(16) & c$(11 to 15) & c$(6 to 10) & c$(1 to 3)



___
QL-Users Mailing List





___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread pjwitte via Ql-Users

Aah! Perfect! Thanks Marcel, youre a star!

So in fact I interpreted the input wrong. It should have been:

GGGggRRR rrBBBbbW <- input

and
ggWBBBbb RRRrrGGG -> output

Seems so obvious now ;)

Per

On 16/12/2017 15:30, Marcel Kilgus via Ql-Users wrote:

320 c$ = c$(4 to 5) & c$(16) & c$(11 to 15) & c$(6 to 10) & c$(1 to 3)



___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread pjwitte via Ql-Users

Thanks both for your input!
However, Wolfgang, Im having trouble with your suggestion. Perhaps Ive 
interpreted wrongly?


Heres how I got on:

100 REMark Convert screens mode 33 to 32
110 REMark POC, pjw, December 16th 2017
120 :
140 fnm$ = 'ram2_dmp1024x768_scr'
150 :
160 t = DATE
170 ERT ScrCv33to32(fnm$, fnm$ & '_32')
180 PRINT DATE - t
190 :
200 DEFine FuNction ScrCv33to32(fnmi$, fnmo$)
210 ch = FOP_IN(fnm$): IF ch < 0: RETurn ch
220 fl = FLEN(#ch): CLOSE#ch
230 adr = ALCHP(fl): LBYTES fnm$, adr
240 :
250 REMark 12345678 9ABCDEFG (in string coordinates)
260 REMark ggGGGRRR rrBBBbbW <- input
270 FOR a = adr TO adr + fl - 2 STEP 2
280  c$ = BIN$(PEEK_W(a), 16)
290  REMark GGGBBBbb RRRrrggW:
300  c$ = c$(3 TO 5) & c$(11 TO 15) & c$(6 TO 10) & c$(1 TO 2) & c$(16)
310  REMark ggWBBBbb RRRrrGGG -> RRRrrGGG ggWBBBbb in big-endian:
320  remark c$ = c$(1 TO 2) & c$(16) & c$(11 TO 15) & c$(6 TO 10) & 
c$(3 TO 5)

330  POKE_W a, BIN(c$)
340 END FOR a
350 :
360 SBYTES_O fnmo$, adr, fl
370 RECHP adr
380 RETurn 0
390 END DEFine ScrCv33to32
400 :

With

290  REMark GGGBBBbb RRRrrgg0
300  c$ = c$(3 TO 5) & c$(11 TO 15) & c$(6 TO 10) & c$(1 TO 2) & '0'

I got the best results. While, with 300 REMarked out and 320 un-REMarked:

310  ggWBBBbb RRRrrGGG -> RRRrrGGG ggWBBBbb in big-endian
320  c$ = c$(1 TO 2) & c$(16) & c$(11 TO 15) & c$(6 TO 10) & c$(3 TO 5)

(which is how I understood your suggestion) BGIMAGE 
"ram2_dmp1024x768_scr" went psychedelic!


On 16/12/2017 11:59, Wolf via Ql-Users wrote:

Hi Per,

The PC switches the bytes around.

So
gggb rgg0
actually means
rgg0 gggb


In other words, you're switching the third highest byte for green on 
or off.

If you sure that's what you want, then that's fine.

Wolfgang




On 16/12/2017 11:43, pjwitte via Ql-Users wrote:
I havent tested your suggestion yet, Wolfgang, but what I found so 
far was that gggbrgg0 appears (to my eye) to look cleaner 
than gggbrggW. Is that so wrong? ;)


BTW, when converting the translation to assembler, I found the 
following representation helpful:


GGGggRRR rrBBBbbW = mode 33
gggBBBbb RRRrrGGG = mode 32
gggBBBbb RRRrrGGW = mode 32 translated

Per
On 16/12/2017 10:55, Wolf via Ql-Users wrote:
No, not the same as %gggbrggW, as suggested in the 
original post.


Wolfgang

On 16/12/2017 10:18, Peter Graf via Ql-Users wrote:

Wolfgang Lenerz via Ql-Users wrote:

I'd do it this way

%ggWbrggg


Which is the same :)




___
QL-Users Mailing List



___
QL-Users Mailing List


.



___
QL-Users Mailing List



___
QL-Users Mailing List





___
QL-Users Mailing List

Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread pjwitte via Ql-Users

Oops! That should be:
GGGBBBbb RRRrrgg0 = mode 32 translated
P
On 16/12/2017 11:43, pjwitte via Ql-Users wrote:
I havent tested your suggestion yet, Wolfgang, but what I found so far 
was that gggbrgg0 appears (to my eye) to look cleaner than 
gggbrggW. Is that so wrong? ;)


BTW, when converting the translation to assembler, I found the 
following representation helpful:


GGGggRRR rrBBBbbW = mode 33
gggBBBbb RRRrrGGG = mode 32
gggBBBbb RRRrrGGW = mode 32 translated

Per
On 16/12/2017 10:55, Wolf via Ql-Users wrote:
No, not the same as %gggbrggW, as suggested in the original 
post.


Wolfgang

On 16/12/2017 10:18, Peter Graf via Ql-Users wrote:

Wolfgang Lenerz via Ql-Users wrote:

I'd do it this way

%ggWbrggg


Which is the same :)




___
QL-Users Mailing List



___
QL-Users Mailing List


.



___
QL-Users Mailing List





___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-15 Thread pjwitte via Ql-Users

Thanks guys :)

On 16/12/2017 00:30, Peter Graf via Ql-Users wrote:

What do I do with 'w' in either case for best results?

I would just use the RGB0 bit of mode 33 as G0 Bit of mode 32, which is
what you probably do already.

There is no perfect translation, since mode 33 has 64 clean grey levels,
while mode 32 has only 32. There will be a minimal green tint in mode 32
where RGB0 of mode 33 was set, but almost not noticeable.

___
QL-Users Mailing List





___
QL-Users Mailing List


[Ql-Users] Mode 33 to 32

2017-12-15 Thread pjwitte via Ql-Users
I want to convert a mode 33 screen (Qxx) to mode 32 (QPC2) and visa 
versa. I got this far with 33 to 32, but Im not sure this is the best 
translation:


rem %grbw = mode 33
rem %gggbrggg = mode 32

c$ = BIN$(PEEK_W(a), 16)
c$ = c$(3 TO 5) & c$(11 TO 15) & c$(6 TO 10) & c$(1 TO 2) & c$(16): 
rem = %gggbrggw


What do I do with 'w' in either case for best results?

Per

___
QL-Users Mailing List