Re: [Ql-Users] WMAN Weirdness!

2012-05-02 Thread Norman Dunbar

On 02/05/12 22:14, Malcolm Cadman wrote:


As the great Bob (Marley) sang ... no WMAN no cry . :-)


And we all know how Bob Marley likes his donuts?
We Jammin.

(You started it!)


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] SMSQmulator

2012-05-02 Thread Marcel Kilgus
Wolfgang Lenerz wrote:
> Much is now working correctly.
> Basic works.
> PE & WMAN work.
> It's now possible to have a bigger screen (I normally use 1024x512) but
> screen access remains slow.

Congrats. I remember it to be pretty satisfying once things start to
work ;) I probably never forget the joy of the Minerva logo appearing
on screen or the first blinking cursor :-)

> I mention the bogomips prog, because I used that to test the speeds of
> SMSQmulator.
>
> On the slowest machine around here (a 3 year old laptop), I get :
> Smsqemulator 6.61 bogomips
> but
> QPC 50.06 bogomips - so SMSQmulator is about 8-10 times slower than QPC,
> and it'll probably be even slower than that when heavy screen redrawing
> is involved.

That is somewhat slow, and I actually mean the QPC figure. Do you run
QPC under Linux? In that case Wine might be slowing things down. I got
a solid 183 bogomips here on my laptop that is slightly over a year
old and is even just an i5. It shouldn't be three times as fast as
your machine.

> There are at least two known bugs. One stops QLiberated progs that read
> DATAS from working - you get the famous red error window telling you
> that the prog is out of DATA. This will be a tough one to figure out,
> because trawling through QLiberated code is just awful!

Been there, done that, didn't even get a T-shirt. Have fun :-P

> There also seem to be some problems with C compiled progs, but I don't
> have many of those, I'll have to check.

Try setting sys_ptyp to $10.

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] WMAN Weirdness!

2012-05-02 Thread Malcolm Cadman
In message <4fa10f60.5070...@dunbar-it.co.uk>, Norman Dunbar 
 writes


Hi Norman,

As the great Bob (Marley) sang ... no WMAN no cry . :-)



On 02/05/12 11:35, George Gwilt wrote:

The status area is $40 bytes long so that the loose item status block 
starts at wst + $40.
Thanks George, that works perfectly. It appears that the offset into 
the definition's status area is exactly the same as for the working 
definition. This is good.


Thanks again.


Cheers,
Norm.


--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] SMSQmulator

2012-05-02 Thread Dave Walker

> -Original Message-
> From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-
> boun...@lists.q-v-d.com] On Behalf Of Wolfgang Lenerz
> Sent: 01 May 2012 17:33
> To: ql-us...@q-v-d.com
> Subject: [Ql-Users] SMSQmulator
> 
> 
> There also seem to be some problems with C compiled progs, but I don't
> have many of those, I'll have to check.

I m guessing here, but I would think the most likely area to cause a problem
is the bit of code in the start-up module that tries to detect the processor
type and whether hardware floating point is supported as that relies on some
exception's being handled correctly and also some variations in instruction
behaviour between different processors in the 68K family.   That code is in
the proctype.x module from the LIBC library source.  Having said that I am
not sure that in most cases it would matter if the wrong answer was given as
long as the program did not crash in that code.

Dave Walker

Tel:  +44 (0)1707 652791
Mob: +44 (0)7999 218953
Web: http://www.itimpi.com
Skype:  itimpi


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Bug in WM_ENAME

2012-05-02 Thread George Gwilt

On 2 May 2012, at 16:00, Norman Dunbar wrote:

> 
> When I edit a string using this vector, and press ESC to terminate the edit, 
> I'm seeing zero in D0 instead of a positive number. D1.W is correctly set to 
> 27 for the ESC key.
> 
> The docs state that:
> 
> D0 negative is an error.
> D0 zero means ENTER pressed to end the edit.
> D0 positive means another key ended the edit.
> 
> What I'm finding in tracing the code is the following:
> 
> D0=0, D1=27, ESC pressed.
> D0=0, D1=$0a, ENTER pressed.
> D0=0, D1=$d0, UP pressed.
> D0=0, D1=$d8, DOWN pressed.
> 
> It appears that D0 is always zero on return.

The code in ee_wman_rname_asm (which contains the code for WM.ENAME) sets D0 to 
0 when a character is correctly read. If it is one of the terminators then D0 
remains zero. this means that the code distinguishing between ENTER and the 
rest is just not there!

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[Ql-Users] Bug in WM_ENAME

2012-05-02 Thread Norman Dunbar

I'm seeing a possible bug in WMAN's WM.ENAME.

When I edit a string using this vector, and press ESC to terminate the 
edit, I'm seeing zero in D0 instead of a positive number. D1.W is 
correctly set to 27 for the ESC key.


The docs state that:

D0 negative is an error.
D0 zero means ENTER pressed to end the edit.
D0 positive means another key ended the edit.

What I'm finding in tracing the code is the following:

D0=0, D1=27, ESC pressed.
D0=0, D1=$0a, ENTER pressed.
D0=0, D1=$d0, UP pressed.
D0=0, D1=$d8, DOWN pressed.

It appears that D0 is always zero on return.


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] WMAN Weirdness!

2012-05-02 Thread Billy

On 02/05/2012 10:55, Norman Dunbar wrote:

On 02/05/12 09:55, Norman Dunbar wrote:

It seems that SETW, not the latest version, defines a WORD for the
window flag byte and the shadow depth byte.

When I typed the above, what I was meaning to say was that SETW combines
the two bytes (flag and shadow depth) into a single word, not that it
generates a separate word for each of them.

English isn't my first language! :-)


Cheers,
Norm.


 Oh come on now, I've heard many a scot put BBC English to shame
All the best - Bill
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] WMAN Weirdness!

2012-05-02 Thread Norman Dunbar

On 02/05/12 11:35, George Gwilt wrote:


The status area is $40 bytes long so that the loose item status block starts at 
wst + $40.
Thanks George, that works perfectly. It appears that the offset into the 
definition's status area is exactly the same as for the working 
definition. This is good.


Thanks again.


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] WMAN Weirdness!

2012-05-02 Thread George Gwilt

On 2 May 2012, at 09:55, Norman Dunbar wrote:

> 
> When setting up a window, how do I set a couple of the loose items to 
> unavailable? I know how to do it in the working definition after the window 
> has been set up, but I think I need to do it in the status area before I call 
> WM_SETUP? If so, what's the offset for the loose items into that area as 
> opposed to the working definition? Or are they the same? I can't find 
> anything in the QPTR docs.
> 

If you use SETW to set the window you will find that the area for the status 
block and the loose item block immediately following are defined by

wst ds.b

The status area is $40 bytes long so that the loose item status block starts at 
wst + $40.

Since the combined block is defined by ds,b there is no guarantee that all the 
values are zero. For that reason in my examples I clear the whole area thus 
setting all loose items to available. This clearing is done before the working 
definition is set up. To set a loose item to unavailable you just have to set 
the appropriate byte to $10.

George


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] WMAN Weirdness!

2012-05-02 Thread Norman Dunbar

On 02/05/12 09:55, Norman Dunbar wrote:

It seems that SETW, not the latest version, defines a WORD for the
window flag byte and the shadow depth byte.
When I typed the above, what I was meaning to say was that SETW combines 
the two bytes (flag and shadow depth) into a single word, not that it 
generates a separate word for each of them.


English isn't my first language! :-)


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[Ql-Users] WMAN Weirdness!

2012-05-02 Thread Norman Dunbar
I'm in the middle of my next (exciting) article for QL Today and I've 
come across something unusual in WMAN under QPC. But first a "simple" 
question.


When setting up a window, how do I set a couple of the loose items to 
unavailable? I know how to do it in the working definition after the 
window has been set up, but I think I need to do it in the status area 
before I call WM_SETUP? If so, what's the offset for the loose items 
into that area as opposed to the working definition? Or are they the 
same? I can't find anything in the QPTR docs.



Ok, the weirdness. I have QPC running with a resolution of 1024 by 768. 
I have a window defined as being 336 by 224 and a shadow depth of 2. The 
window was set up using George's SETW utility, as usual.


When I draw the window on screen it appears, without a shadow. Strange. 
What is even stranger is, I cannot move the window outside of the normal 
512 by 256 window area. Even stranger, I notice that while the window is 
on screen, a shadow - probably the missing one - is displayed over on 
the far right of the screen outside the 512 by 256 window area.


There's nothing unusual in this window - 7 loose items, 6 information 
windows, 1 application window (no menu yet) and that's about it. Every 
other program I have moves happily around and keeps the shadow with it. 
This one is puzzling!


When I trace the program execution, the call to iop_flim correctly 
returns the 1024 by 768 at 0 by 0 settings for the maximum window limits.


Any clues?

By the way, QPC is running under Linux - as it always does. But the 
problem also shows up under QPC on Windows XP as well.


I'm trawling through the window definition even as I type, but so far, 
it all looks fine to me:


STOP PRESS SOLVED!

Got the b*gger! It seems that SETW, not the latest version, defines a 
WORD for the window flag byte and the shadow depth byte. Because I was 
using an older version (sorry George, I'll get it updated soon!) it was 
generating thw wrong value for these two bytes.


In my stupidity, I set the word to $82 (aka 130) whihc set the shadow 
depth to 130 instead of 2. The word should have been $8002 (aka 32270).


So, setting a "bonkers" shadow depth was the cause of my problem, the 
shadow was hitting the window limits as I moved the window around while 
the window itself appeared to be ok.


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm