[Ql-Users] Coldfire V4m

2008-02-28 Thread pgraf
Hi,

talking Coldfire V4, my knowledge horizon ended at the V4e core. Checking 
back yesterday, I saw that very recently some chips with V4m core were 
released (MCF5445x).

Compared to V4e, the FPU was removed, but there also were some changes in 
the instruction set and exception handling. Might be worth a closer look, 
to see if further improvements toward 68k were made. It was not much the 
V4e was lacking regarding support for complete emulation of misbehaving 
opcodes. Maybe some gaps were silently closed with the V4m.

Peter

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


Re: [Ql-Users] IOP_RPTR event vector - where is it documented.

2008-02-28 Thread George Gwilt

On 26 Feb 2008, at 08:02, [EMAIL PROTECTED] wrote:

 In the next issue of QL Today I'm starting on the Pointer  
 Environment. To
 this end, I've started simple but I find that easier! In the second
 article - which I'm writing right now - I've built a small 'pointer
 record' decoder but I'm looking for information of what exactly is set
 in the event vector at the end of each call to IOP_RPTR.

 My experimentations have shown that :

 After the start of the program, the pointer remains inside the hit  
 area,
  a click with the mouse buttons sets the vector to $2B. This is the  
 value
  when SPACE or ENTER are pressed.

 If the pointer remains inside the windows as above, any other keypress
  sets it to $2D.

 If the pointer has been outside of the window and comes back in,  
 SPACE,
  ENTER, HIT or DO buttons set it once to $3B. Other key presses set it
  once to $3D. Subsequent button or key presses revert to $2B and  
 $2D as
  before.

 If the job is 'picked' the KeyStroke is set to $08 and the event  
 vector
  is set to $3D - which could be 'pointer out of window'

 I have the QPTR toolkit documentation from many many years ago, but  
 I'm finding some bits missing in detail - as I think Bruce  
 discovered some time back with the Sub Windows and stuff. I found a  
 posting by Bruce on the list - but he never got a reply!

 Any information from your PE Gurus gratefully received.


The manual (called description) for TurboPTR and the source code for  
the extra keywords (tptr510_asm) will give information about WRPTR.  
All this is on he SQLUG site.

The information is  sufficient to enable actual programming but there  
is far too much too put in this email!

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


Re: [Ql-Users] IOP_RPTR event vector - where is it documented.

2008-02-28 Thread Norman Dunbar
Hi George,

 The manual (called description) for TurboPTR and the source code for  
 the extra keywords (tptr510_asm) will give information about WRPTR.  
 All this is on he SQLUG site.
 
 The information is  sufficient to enable actual programming but there  
 is far too much too put in this email!

Ok, I'll give that a try when I have a moment of five to spare. I've had
some good information from Wolfgang and Per as well.

Thanks.


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


Re: [Ql-Users] IOP_RPTR event vector - where is it documented.

2008-02-28 Thread Norman Dunbar
Hi Wolfgang,

 Use the send_event keyword. (send_event job_id,events)
Thanks, I googled for something else and found a reference to the send
event trap. Will have a look later.

 If I PICK the job, or button frame it, then DO it's button,
 I get the same event both times - $2D with a Key Stroke of $08.
 Which would be a wake.
Thought it might me, I'm sure a Wake is a keypress of $08. Need much
more reading though.

 Both showing that the pointer moved event took place, but the pointer 
 coordinates never changed...
 
 I haven't checked that, either.
I think I may have the answer. Apparently (it is written) that the
coordinates in D1 when IOP_RPTR is called are only used to check where
the pointer is, and if it isn't at whatever D1 says, then it is assumed
to have moved.

Good explanation, but if I always set it to 0,0 and I leave the pointer
at 0,0 then it still 'moves'. H.

 FYI, this is the code I'm currently playing with :
 OK, thanks, I'll give it a spin this weekend.
Don't expect anything grand and spectacular - this is only about my
second PE assembly language program ever - apart from some 'fun' stuff I
did for Dilwyn many years ago (1992 I think!) which I never really
understood anyway!



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