Re: [ql-users] Re: Re: [ql-users] Re: [ql-users] Re: £ 0.00 to spend! (1st ...
In a message dated 19/03/04 11:35:27 GMT Standard Time, [EMAIL PROTECTED] writes: I stand to be corrected on these comments on QDOS Classic and I am sure that George Gwilt would love a simple step by step guide as to how to set it up, so that we can find out why QWord cannot open its TurboPTR windows under it. It would have to be a very simple guide since with my inability to understand instructions (sometimes including my own!) it would be a stumble by trip journey instead of step by step. George
Re: [ql-users] £ 0.00 to spend! (1s t attempt)
In a message dated 18/03/04 16:57:35 GMT Standard Time, [EMAIL PROTECTED] writes: On 18 Mar 2004 at 9:24, [EMAIL PROTECTED] wrote: > >You might try driving without tyres. > But would that be driving? Wolfgang Bumpily - as without SMSQ/E. George
Re: [ql-users] £ 0.00 to spend! (1s t attempt)
In a message dated 16/03/04 17:30:16 GMT Standard Time, [EMAIL PROTECTED] writes: We should be working together to make the QL and its operating system as good as we can, taking the best things from SMSQ/e, QDOS Classic and Minerva to make one operating system which meets everyone's wishes. To put it in context. At the moment, it sounds like there are only 3 wheel manufacturers in the world and if you want a new set of tyres, you have three choices: 1) Buy the same tyres as last time 2) Buy some improved tyres which grip the road much better and perform much better and hope that these tyres will somehow fit your existing wheels. 3) Buy a new car with its own proprietary wheels and tyres. You might try driving without tyres. George
Re: [ql-users] problem with the new C68 pieces for WMAN
In a message dated 15/03/04 07:56:22 GMT Standard Time, [EMAIL PROTECTED] writes: By way of a test, I hid the old libc_a and still it all worked. When I ran 'slb -t ram1_lis libc_a', I could find no evidence of your missing name. Christopher Cave I looked for RELOC (in case it was STRT not START or some other variant) by using qmon with f 'reloc' There were two RELOCs but not remotely like RELOC_START. RELOC_START sounds like something a linker needs to do with all C68 programs, since they all have absolute addresses between modules, not PC relative ones. George
Re: [ql-users] problem with the new C68 pieces for WMAN
In a message dated 14/03/04 11:39:37 GMT Standard Time, [EMAIL PROTECTED] writes: After compiling, I am getting an undefined symbol 'RELOC_START'. Looking at my original LIBC_A file, I see it in there but I don't see it in the new version with George's updates. Any ideas? I'm sorry if something I have done with LIBC_A has made RELOC_START disappear. Just to check I went back over every version of LIBC_A I have from 1999 onwards. There is no sign of RELOC_START in any of them. I wonder where that came from? George
[ql-users] TurboPTR
tptr_ext It has been found that tptr_ext v5.04 does not reserve enough space for the name list and name table for the keywords it loads. This has been corrected on v5.05 which can be found on the SQLUG site www.jms1.supanet.com in the file tptrp07.zip. The fault was traced to the macro FNPROC. A corrected version of this macro is in the file gdlib03.zip. tspr Also new in tptrp07 is an update of tspr which shows sprites. It now shows a sprite's mode, size, origin and time constant. George
Re: [ql-users] QLiberator
In a message dated 11/02/04 01:16:30 GMT Standard Time, [EMAIL PROTECTED] writes: (But why would anyone want to get Q-Liberator when Turbo is free, twice as fast, plus now it can incorporate extensions in the executable. We should know as Q-Word is done this way thanks to George Gwilt). Turbo IMHO was always a superior product and with TurboPTR you can build all the Pointer programs that your heart desires. Thanks for the plug!! Actually the latest version of TurboPTR, which includes all the new colours and the nice advances in the new WMAN should be on the SQLUG site at the weekend. George
Re: [ql-users] WM.RPTRT again
In a message dated 07/01/04 07:47:56 GMT Standard Time, [EMAIL PROTECTED] writes: In the meantime I had also found some issues with the following routines and just made new wrappers that I use instead of those included in the C libary. The dates are what I have on the files when I made my own versions. iop_flim Aug 02 sms_sevt Jun 02 sms_wevt Jul 02 wm_rptrt Jun 02 The last update on Dave's sight that I found incuded the GD2 LIBC routines from March 2001. Jim It is very useful to have a note of these corrections to libc_a. I have looked at iop_flim, sms_sevt and sms_wevt as they are on my libc_a. Only sms_sevt has an error as far as I can see. The error is that the 2nd parameter is loaded from 6(a7) instead of 8(a7). The other two functions worked when I put them into C programs. I would therefore be very grateful if someone could say what the errors are in iop_flim and sms_wevt. As I have already said I have changed wm_rptrt in my libc_a to correct it and also to return only D0. (BTW wm_rptrt is declared as "int" and not "chan_t"). Another error was reported to me some years ago. In ut_scr #$C8 is used instead of $C8 when calling the ut_scr vector. I have corrected that too in my libc_a. Has anyone else detected further errors in libc_a? George
Re: [ql-users] WM.RPTRT again
In a message dated 06/01/04 13:16:22 GMT Standard Time, [EMAIL PROTECTED] writes: In-Reply-To: <[EMAIL PROTECTED]> I have been watching this exchange with trepidation since I have been using wm_rptrt surrounded by many thousands of lines of C68 code WITH NO PROBLEM. I was under the impression that Jonathan Hudson had sorted this call out some time ago. But I must admit that it has only been the timeout aspect of this call that I have been using. On a slightly different tack, what is the state of play on implementing new WMAN vectors for use in C68. At the moment, C68 calls to QMENU enjoy 3-d buttons etc. etc. but homegrown windows do not yet. Christopher Cave I expected that something would have been done, but I was not aware of it! Does anyone know where the amendments can be found? As to the new WMAN vectors for C68, the situation is that I have procuced the necessary functions, manual and header file all of which I have sent to Dave Walker. I don't think he has yet put it on his site. I have already sent a copy of the files to Jim Hunkins. I would propose to put the files on the SQLUG site if Dave Walker gave permission. That way everyone could use them. George
Re: [ql-users] WM.RPTRT again
In a message dated 04/01/04 17:03:38 GMT Standard Time, [EMAIL PROTECTED] writes: >However, there is another question (which I may be able to answer before >anyone else too). The addition of job events to SMSQ/E has caused a change in >IOP.RPTR. This will now allow a return from a job event. The manual states clearly >that the job event will be placed in the top 8 bits of the pointer event >(pt_pvent) in the status area. It also seems to suggest that the top 8 bits of D2 >in a call to IOP.RPTR should contain the job events on which to return. A >short test seems to bear this out. Now comes the question. > >Since the original IOP.RPTR asks for D2.B to be set, does this not mean that >old programs calling the routine might find peculiar things happening? For >example, the contents of D2.L could have $FF as the top byte. D2 might have been >-1 before D2.B was set with the required pointer events return. In that case >any job event sent to the program would cause a spurious return. > >What steps have been taken to prevent this? I have no intelligent answer to this. However, I expect that in most instances people will have used a moveq instruction to set the byte in d2.. Per I agree that a MOVEQ would eliminate the problem. However there are two places where that instruction is not used. 1. The C68 function iop_rptr has something like MOVE.W $10(A7),D2 since the return parameter is "short". Clearly this does not cater for a job event termination so I have produced a new function "iop_rptrj" which sets the correct value in D2 in the way described below for BRPTR. 2. A S*BASIC extension such as BRPTR (from TurboPTR's TPTR_EXT) will have a word parameter so that D2 is filled by something like MOVE.W (A1,A6.L),D2 In fact, since this obviously does not correctly set the job event termination requirement in D2, I have already changed BRPTR (though the alteration is not yet issued) to MOVEQ #0.D2 (to clear the middle 2 bytes) MOVE.W (A1,A6.L),D2 ROR.W #8,D2 ROR.L #8,D2 (BRPTR is a function reading the pointer via IOP.RPTR) WM_RPTR and WM_RPTRT My original query did not concern WM_RPTR/T, mentioned by Wolfgang Lenerz in his comment. However, I have found yet another problem here. I wanted to use WM_RPTRT via C68 so I looked at the code, since I don't seem to have a description of what it does. I was amazed to see MOVE.W $14,D3 MOVE.W $16,D2 inside it. Anyone using that version is in for a nasty shock! Luckily the length of code for the correct MOVE.W $14(A7),D3 MOVE.W $16(A7),D2 is the same. I have thus patched my own copy of the library. However, in addition I discovered that wm_rptrt returns either the error code (if negative) or the channel ID. This is in contrast to wm_rptr which just returns the contents of D0. Thus, although wm_rptrt with infinite timeout and zero job event termination should be equivalent to wm_rptr you will find that while (!wm_rptr(ww)) is not the same as while (!wm_rptrt(ww,-1,0)) since the latter will exit the while on a correct return as well as an error return. Because of this I altered my version of wm_rptrt so that only D0 is returned and a zero test will work. I wonder if anyone else has had trouble with wm_rptrt in C68? George
[ql-users] WM.RPTRT again
As everyone will realise by now, the events given to WM.RPTRT in D2.B are job events, not pointer events. So, obviously, WM.RPTRT will return on any pointer event just as WM.RPTR does whatever the value in D2.B. However, there is another question (which I may be able to answer before anyone else too). The addition of job events to SMSQ/E has caused a change in IOP.RPTR. This will now allow a return from a job event. The manual states clearly that the job event will be placed in the top 8 bits of the pointer event (pt_pvent) in the status area. It also seems to suggest that the top 8 bits of D2 in a call to IOP.RPTR should contain the job events on which to return. A short test seems to bear this out. Now comes the question. Since the original IOP.RPTR asks for D2.B to be set, does this not mean that old programs calling the routine might find peculiar things happening? For example, the contents of D2.L could have $FF as the top byte. D2 might have been -1 before D2.B was set with the required pointer events return. In that case any job event sent to the program would cause a spurious return. What steps have been taken to prevent this? George
[ql-users] WM.RPTRT
The PE vector WM.RPTRT is supposed to read the pointer in the same way as WM.RPTR with two additions. 1. It has a timeout (in D3.W) 2. It returns on the events set in D2.B I find that although it correctly returns on timeout (with D0.L = -1), WM.RPTRT always returns on an event whatever the event and whatever the contents of D2.B. Has anyone else found this? Is this supposed to happen? George
Re: [ql-users] looking for a disassembler...
In a message dated 19/11/03 08:05:16 GMT Standard Time, [EMAIL PROTECTED] writes: Is there on the web any disassembler available free worth a recommendation ?(I mean a 680xx disassembler... might be ok if it run either on a Q40 ora PC) The disassembler GWDISS is available from the SQLUG website. It needs a 68020+, so it runs on a Q40 or QXL. It disassembles all 68xxx instructions including floating point. But it is not an "intelligent" disassembler. You have to work out yourself where jumps/branches go to and what is data and what is instruction. Also it expects instructions to start on a word boundary (which of course they do when they are used by a CPU). The program NET_PEEK, also available from the SQLUG website, will actually disassemble instructions which are not necessarily on a word boundary. I find this useful for looking at relocatable , type 2, files. NET_PEEK also requires a 68020+ for disassembly. George
Re: [ql-users] Bugs
In a message dated 28/10/03 16:13:10 GMT Standard Time, [EMAIL PROTECTED] writes: SMSQ/E can be configured to allow a window move by a. Window b. Outline c. Sprite The last of these is the old way. The new ways cause the window sprite to become the default arrow. This occurs in Q60 and in QPC2. I have only just now discovered this. George What happens is that the long word at $30 of the window working definition is zeroed. This should be the pointer to the window sprite. Being zero you get the default sprite. On a resize, or return from a button the working definition has to be reset from the window definition (at least in QD and also in my programs) and the correct sprite reappears. George
Re: [ql-users] Bugs
In a message dated 28/10/03 18:07:07 GMT Standard Time, [EMAIL PROTECTED] writes: Can you further specify/clarify this (version number, program, someway to reproduce it etc.)?I mean, I and many others use the "window" move feature every daywithout problems.Marcel This occurs in SMSQ/E v3.01 on the Q60 and in v3.01 1/2 (?) with QPC2. Have a look at either QD (perhaps only the old version) with a window sprite in the upper part of the window which is just like a WINDOZE arrow. After a move the default sprite appears. A resize or return from a button resets the otiginal sprite. The same is true of MenuConfig. The long word at $30 in the working definition has been set to zero. George
Re: [ql-users] wm.rptrt
In a message dated 26/10/03 20:52:57 GMT Standard Time, [EMAIL PROTECTED] writes: Sorry for being such a pain, but I have some further questions:How do I position a PE window accurately? Problem is, I want to create abutton, to go into the button frame. Im hoping to use a standard WindowDefinition with a single Loose Item. If I use a window with a border widthof 1 and then use wm.prpos, my button overlaps part of the adjacent button.(This occurs even when my button's x-origen is divisible by 4). If I use aborderless window, ie border width 0, there is no problem, except as below:In certain circumstances, I want to be able to liberate the button from theButton Frame and then, after doing whatever to it, put it back again(automatically, ie not using wm.chwin). wm.prpos makes it jump all overthe place!Ive spent ages trying various alternatives. Please help!Per Have a look at both TurboPTR and CPTR. There are examples there of an easy way of "buttonising" a program both when there is and when there isn't a button frame. The contents of the button can be text, sprite or blob/pattern. If there is no button frame, the button can be moved using the left mouse key. The programs are on the SQLUG site. George
Re: [ql-users] Bugs
In a message dated 24/09/03 19:33:23 GMT Daylight Time, [EMAIL PROTECTED] writes: I'll try to pick up all bugs reported.Wolfgang SMSQ/E can be configured to allow a window move by a. Window b. Outline c. Sprite The last of these is the old way. The new ways cause the window sprite to become the default arrow. This occurs in Q60 and in QPC2. I have only just now discovered this. George
Re: [ql-users] Re SMSQ & Gwass
In a message dated 21/10/03 06:45:34 GMT Daylight Time, [EMAIL PROTECTED] writes:
} It might just be me, but wasn't there also an issue with _expression_ evaluation ?(respecting without parentheses the +/- and * precedences in complexe line)
There was indeed the need for GWASS to deal with "expressions". The situation now is that GWASS can deal with expressions in exactly the same way as Qmac. There is now a switch in GWASS allowing you to choose "expressions" (as Qmac) or "not expressions" (as in earlier versions of GWASS). This allows
4+ 7*3
to be evaluated by GWASS either as 25 ("expressions") or 33 ("not expressions").
The new method also allows GWASS to find the value for eg
(label1 + label2)/label3
The precedences of the set of operators in GWASS follows that in Qmac. Whether that is the same as precedences in other assemblers is another question. Does anyone know whether Qmac is "normal" or "out of line"?
I think all the operators involved are - + - * / << >> ! and &. I would have to look up the GWASS manual to be sure!
George
Re: [ql-users] Re SMSQ & Gwass
In a message dated 20/10/03 15:10:33 GMT Daylight Time, [EMAIL PROTECTED] writes: But I talk about the actual lines (instances) when macros are used.Didn't you say at one time that they all had to be changed?Marcel Some uses of macros within a program can be the same for both GWASS and Qmac, some must be different. It depends on the macro I'm afraid. George
Re: [ql-users] Re SMSQ & Gwass
In a message dated 19/10/03 15:23:18 GMT Daylight Time, [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote:> Most, or a lot, of SMSQ/E can be assembled either by GWASS or by Qmac without> any change. For the remainder it is possible to alter the source code > slightly so that it too could be assembled either by GWASS and by Qmac. The choice of > assembler would be governed by a simple switch.Hm? I thought all macro instantiations had to be changed in a wayincompatible to QMAC?Marcel OK. The "remaining programs" are altered by including code for GWASS as well as the code for Qmac. The choice of which to use is done by the parameter of the appropriate "IF" type instruction which is common to both assemblers. If macros are needed the choice is between the directory "mac" and the directory "mac1". The second directory contains the same macros as the first but in a form suitable for GWASS. The choice here is thus between INCLUDE "dev8_mac", and INCLUDE "dev8_mac1" George
Re: [ql-users] Re SMSQ & Gwass
In a message dated 19/10/03 14:03:24 GMT Daylight Time, [EMAIL PROTECTED] writes: > Sorry Wolfgang but you miss understand my points. There is no technical > reason why it could not run on systems below 68020. I wouldn't know about that. all I know is that I was told that it would not run on machines lower than 68020.> BTW there is GWASSL > that runs on all 68K systems.true - but can it handle everything the not L version can?(...) GWASS requires a 68020+, but GWASL will indeed run on all QL machines, but does not have enough of the facilities that GWASS has to assemble SMSQ/E. Most, or a lot, of SMSQ/E can be assembled either by GWASS or by Qmac without any change. For the remainder it is possible to alter the source code slightly so that it too could be assembled either by GWASS and by Qmac. The choice of assembler would be governed by a simple switch. George
Re: [ql-users] Isn't it open source?
In a message dated 15/10/03 17:29:57 GMT Daylight Time, [EMAIL PROTECTED] writes:
> In a message dated 15/10/03 07:11:12 GMT Daylight Time, [EMAIL PROTECTED] > writes:> 2 - the sources have everything needed but an Assembler to be readily > compiled.> You never know. Even that might change. (An aside from a small mouse-like > thing in the background)Oh, you mean no Assembler will be necessary,the sources will self assemble ("no assembly required") ?Wolfgang
What a wonderful idea! No assembly would be truly terrific! I wish that that is what I meant.
I merely meant that GWASS can certainly now be used in the compilation of SMSQ/E in place of Qmac given a true 68020+ but this machine restriction could be at least partially removed given time.
George
Re: [ql-users] Isn't it open source?
In a message dated 15/10/03 07:11:12 GMT Daylight Time, [EMAIL PROTECTED] writes: 2 - the sources have everything needed but an Assembler to be readily compiled. You never know. Even that might change. (An aside from a small mouse-like thing in the background) GG
Re: [ql-users] Linus Torvalds, the QL, and open source
In a message dated 15/10/03 07:11:24 GMT Daylight Time, [EMAIL PROTECTED] writes: To some extent, QPC and Qx0 might be seen as competing with each other, (I've heard this being said) even though, for me, they are definitely not. Perhaps "competing" means "which is faster(?) better(?)". As far as I am concerned they are two excellent QL type things. When I have yet another trial version of SETZ setting PE windows with the nem WMAN colours I rush from the Q60 to the QPC to see how well it works. In fact, even going so far as to compile it on both "machines" with Turbo, it worked almost better on QPC than the Q60! Even the new borders appear in the PE windows. Of course the actual outcome is a set of C instructions. So, I agree that they are not competing too much for me. George
Re: [ql-users] Bugs
In a message dated 13/10/03 19:36:32 GMT Daylight Time, [EMAIL PROTECTED] writes: iow_blkt ( chanid_t channel, timeout_t timeout, GDSTP_t *, QLRECT_t *rect) This command, and all the others connected with GD2 were put into C68 in April 2001.I certainly have these in my C68 library and have used them in programs. If anyone wants the GD2 set I can probably supply them. But they should be on Dave Walker's website. George
Re: [ql-users] Bugs
In a message dated 14/10/03 07:59:58 GMT Daylight Time, [EMAIL PROTECTED] writes: } } iow_blkt ( chanid_t channel, timeout_t timeout, GDSTP_t *, QLRECT_t *rect)Ok, will have to integrate that in my system...Anybody maintaining C68 ??? I am shortly going to use C68 (with an updated SETZ) and I will add the necessary bits to cover the new WMAN stuff if needed. I will also send the updates to Dave Walker for his comments etc. George
Re: [ql-users] Bugs
In a message dated 13/10/03 13:25:15 GMT Daylight Time, [EMAIL PROTECTED] writes: Further to my earlier email, I could, if that is wished, publish the changes_txt file here on the list.Any opinions on that, anyone? Good idea! George
Re: [ql-users] Bugs
In a message dated 24/09/03 19:33:23 GMT Daylight Time, [EMAIL PROTECTED] writes: I'll try to pick up all bugs reported.Wolfgang Here is another bug in SMSQ/E. 1. SMSQ/E v3.01 on Q40/60 WM_PAPER, WM_INK etc find the WMAN vector (for the new WM.TRAP3) by using IOP.PINF which puts it into A1. Unfortunately this is done before getting the parameters. This means that if a parameter is an "_expression_", so that its value is on the arithmetic stack, it will be lost. 2. SMSQ/E v3.01 (v3.01a?) on QPC2 The above fault does not occur with v3.01a (?) because here the WMAN vector is taken straight to A2 from the CON linkage without using A1. I hope that no other S*BASIC extension clobbers A1 before getting its parameters! BTW does anyone know whether the CON linkage is guaranteed to have such items as the WMAN vector in the same place for each version of SMSQ/E? Or is a programmer expected to use IOP.PINF or the new PV_PINF to get this vector? George
Re: [ql-users] Bugs
In a message dated 24/09/03 19:33:23 GMT Daylight Time, [EMAIL PROTECTED] writes: > PARTYP, PARUSE, PARNAM$, and PARSTR$ dont work on Smsq/e 3.00 and 3.01. Ok I agree. Another bug is with BORDER. If you have a window with a non-zero border and have issued one of COLOUR_PAL, COLOUR_24 and COLOUR_NATIVE you cannot make the border zero with, eg BORDER 0,0. You only get a zero border with COLOUR_QL.. This is true when you use assembler to do the same thing. In other words it is to do with the TRAP #3 border routine. George
Re: [ql-users] What printers do people use with their QL??
In a message dated 04/10/03 01:57:08 GMT Daylight Time, [EMAIL PROTECTED] writes: Epson stylus colour 850. Beats the LX80 hands down, George. The speed is upand the decibels are down. Epson ink is more expensive than Dom Pérignon anddoesnt taste as good, but generics are available at 1/4 of the price.Per But I have trained TRA and Perfection to print on my ancient Epson. It would take too long to try and reset these! Noise doesn't worry me too much nowadays (for obvious reasons given my state of EARS). Does the 850 allow you to design new characters? I remember once getting the LX80 to print integral signs and a greek delta. For letters (correspondance of course) I use a JUKI daisywheel 6100. BTW I find that SMSQ/E v3.01, or Q40, or something, has stopped me being able to change printers in Perfection. To print the same document on the Epson and the JUKI I have to load it into two different versions of Perfection appropriately configured. Hmm. Does anyone else have this difficulty? George
Re: [ql-users] What printers do people use with their QL??
In a message dated 03/10/03 18:06:52 GMT Daylight Time, [EMAIL PROTECTED] writes: However, what printers are people actually using nowadays with their QL??I stick with the 850 - but am I correct in believing that the Epson Stylus 900 (not the Photo 900) is also fully compatible?? Ha! I use - still - an EPSON LX80 9-pin dot matrix. I find it far quicker than the modern printers which put everything into graphics. It uses continuous stationery and has its own built in font. Long may it continue. George
Re: [ql-users] RFC
In a message dated 25/09/03 20:00:03 GMT Daylight Time, [EMAIL PROTECTED] writes: > As suggested, I would agree that F10 is the best idea - it is akeystroke> which is already familiar with the BASIC ED command and I cannotrecall any> software which uses it... (except perhaps Perfection)F10 - is that the same as SHIFT F5?Used as refresh (screen redraw) by many non-pointer programs (e.g.Quill, Xchange, some of my older programs). F10 (which is SHIFT/F5) does seem a good idea. However, in Perfection it toggles single/dual window mode. George
Re: [ql-users] sernet
In a message dated 20/09/03 18:38:37 GMT Daylight Time, [EMAIL PROTECTED] writes: Michael Grunditz writes: > I cant use sernet between my q40 and qpc2. Iget > sernet aborted . > > any help ? Yes. Transfer data using some other method. Eg use a CD instead. Per Might be quicker to print out what is to be transferred from one end and type it in at the other. Or use handwriting for the output end. (I have NEVER been able to get sernet to work ANYWHERE.) George
[ql-users] Turbo v4.19 and overflow as well as TurboPTR
Some time ago there were reports that Turbo v4.19 could not be used because it stopped with an overflow error. The reason was that all versions of Turbo up to 4.19 were unable to cope with more than 32 megabytes of ram. The problem has now been sorted and a corrected version of Turbo (v4.20) should be on the SQLUG site in the middle of September 2003. The reason for the delay is that various other changes were happening. These are now complete. If anyone wants a corrected version before the definitive one appears on the SQLUG site they should apply to me privately and I'll arrange to send one to them. Turbo TK Code Marcel Kilgus has found a long standing error in ALLOCATION which appears so far to have had no ill effects. Nevertheless a new version of TK Code containing amenments to ALLOCATION and DEALLOCATION is also expected soon. TurboPTR I am making changes in TurboPTR and hope to do the same for CPTR which take into account the new version of WMAN currently in SMSQ/E v3.xx. George
Re: [ql-users] is minus one = -1?
In a message dated 07/06/03 18:13:04 GMT Daylight Time, [EMAIL PROTECTED] writes: PS. Just as an aside, I cut my teeth on IBM System/360 floating point, which used a hexadecimal exponent! Very ragged precision - not a good idea at all! Ah. How nostalgic to see the old 360 mentioned. I wonder if any are still in use? George
Re: [ql-users] is minus one = -1?
In a message dated 05/06/03 03:02:54 GMT Daylight Time, [EMAIL PROTECTED] writes: BTW, I've read that Quanta published some IEEE<->QDOS FP conversion routines in the past (might have been quite some time ago). Does anybody remember this and can scan me a copy? The program FPSAVE which allows an FPU to be used if present (eg on Q40/60) contains the two routines IEEE <> QDOS fp. I have recently used these but not, to my knowledge, on the tricky -1+0 numbers. George
Re: [ql-users] Sbasic and numbers
In a message dated 11/03/03 03:40:54 GMT Standard Time, [EMAIL PROTECTED] writes: As a final digression, I've always bemoaned the fact that floating point is only allowed a twelve bit exponent. It could have gone for 15 bits, which would have reduced the overall code and increased the speed! There you go. Ah. But you could use the FPU, with its 15-bit exponent and 64-bit mantissa, on the Q40, Q60 and some QXLs to do rather longer precision arithmetic. Actually the FPU on a Thor 21 was used even to do Qdos arithmetic although AFAIK only Simon Goodwin's trig functions (on the Q40 and Q60) actually use the FPU. Otherwise Qdos is just the old fashioned 3-byte 32 bit mantissa, 12 bit exponent. George
Re: [ql-users] Assembly question
In a message dated 03/02/03 16:53:43 GMT Standard Time, [EMAIL PROTECTED] writes: Just to show what I mean, a wrong evaluation of something like pt.spcln equ 16*4+pt.spmax*2+pt.blmax*2 ; length of sprite cache would have unhealthy effects. Thanks to all those who commented on the type of "expression" which would be preferred in GWASS. I have just completed inserting a new option in GWASS which is to use normal expressions, complete with undetermined labels, brackets and proper precedence of operators. For those interested a beta test version of GWASS should soon be on the SQLUG website. Also I realised the other day that the assembly of GWASS itself uses two of the QMAC macros which form part of the SMSQ/E set. The macros have, of course, been suitably amended for GWASS. George
Re: [ql-users] Detecting GD2 Drivers
In a message dated 01/02/03 02:36:18 GMT Standard Time, [EMAIL PROTECTED] writes: I know, you're not the only one who has sometimes problems with that :-) In some cases it's even plain wrong or at least misleading (QPtr especially). Therefore the best documentation is the source itself. I for example don't know stuff like your VER$ question either, but in this case I just had a look at the actual VER$ code (SBasic commands are usually in sbsext_ext). I also did a complete FiFI run (looking for 'HBA') over the whole sources, just to be sure, which returns smsq_sbas_version_asm. After having a look at that, one subsequently searches for sb.vers and sb_vers etc. I looked at the Ver$ code in two different versions of SMSQ/E, one on the Q40 and the other with aurora. "HBA" is a string embedded in the SMSQ/E code and brought out with LEA for use (eg putting on the arithmetic stack). George
Re: [ql-users] Assembly question
In a message dated 26/01/03 17:09:33 GMT Standard Time, [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: > I never intended in either GWASL or GWASS to go to the trouble of evaluating > expressions except in a "simple" way. That is in both assemblers evaluation > is done from left to right ignoring implied brackets (parentheses) so Well, I can see why you did it this way. But this also means big trouble for somebody who tries to built SMSQ/E using those assembler, the sources rely on correct mathematical evaluations (and now find the bug if you missed to change only one of them...). Just in case anybody is trying. Marcel Here is a case of "trade off". If the *big trouble* in using GWASS on SMSQ/E sources is solved more easily by changing GWASS than by changing SMSQ/E then that should be done. If anyone wants this I would appreciate a definition of how the expressions should be evaluated. An updated GWASS would, of course, have to have a new option to use its current method of evaluation or to use the different method. I await comments with ba(i)ted breath. George
Re: [ql-users] Assembly question
In a message dated 17/01/03 19:35:55 GMT Standard Time, [EMAIL PROTECTED] writes: I don't think so. Do you have any example at hand? And another thing, do you have some example sprites for the various modes? Or even something like your spritetest application perhaps? I usually produce sprites which contain mode4, mode 8 and mode 33 versions indise the code. To find out what they look like in practice I use my own "tspr" program which displays the sprites against a 3-colour background. This program is part of TurboPTR. Perhaps that would be useful? George
Re: [ql-users] Assembly question
In a message dated 17/01/03 12:43:45 GMT Standard Time, [EMAIL PROTECTED] writes: I agree that an assembler *should* evaluate expressions properly, but some don't I'm afraid. QMAC seems to do it, but GWASL (ie the light version) can't assemble the original code for the lea instruction. I can't remember if the original GST non-macro assembler did it correctly or not. I never intended in either GWASL or GWASS to go to the trouble of evaluating expressions except in a "simple" way. That is in both assemblers evaluation is done from left to right ignoring implied brackets (parentheses) so 3+4*8 becomes 3+4 -> 7 7*8 -> 56 Other assemblers no doubt will produce the answer 3 + (4*8) = 3 + 32 = 35 I had to go through several instructions in Turbo'c codegen altering the order of the expressions so that GWASS wouild get the right answer. I apologise if people find it troublesome. (Again it is probably another case of RTFM if things appear to go wrong.) George
Re: [ql-users] Using WMAN and EasyPTR
In a message dated 12/01/03 21:49:02 GMT Standard Time, [EMAIL PROTECTED] writes: What is the best way of setting the mouse pointer to a blank pointer, so nothing appears on screen when the mouse is moved about. Use TurboPTR with S*BASIC or CPTR with C68 and use the nul sprite. I do it all the time with both for several reasons. George ((PS Don't ask me about EasyPTR))
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 10:05:36 GMT Standard Time, [EMAIL PROTECTED] writes: Which reminds me, has anyone else already written programs which output PIC files in the extended colour modes??? Yes, if my PSA files are in the same format as PIC files, as they seem to be. The programs are available on the SQLUG website. George
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 17:28:48 GMT Standard Time, [EMAIL PROTECTED] writes: Even so, it will sometimes be necessary to check for the presence of GD2 initially: I have had to deal with programs which need to know whther the mode is 4 or 8. When mode 33 appeared I changed the (assembler) code slightly to trap the modes 32 and 33. Unless GD2 modes 0,4 and 8 are used (are they really?) then the ordinary mode trap tells you the situation. Of course, if the low GD2 modes 0, 4 and 8 are used as machine native modes, then the mode trap should be extended in a universally accepted way. George rem Init if GD2 then blue = $70: : else blue = 0: rem Main ink#ch;blue This cant be done automatically without retro-engineering Qdos. Per
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 17:28:48 GMT Standard Time, [EMAIL PROTECTED] writes: Even so, it will sometimes be necessary to check for the presence of GD2 initially: I have had to deal with programs which need to know whther the mode is 4 or 8. When mode 33 appeared I changed the (assembler) code slightly to trap the modes 32 and 33. Unless GD2 modes 0,4 and 8 are used (are they really?) then the ordinary mode trap tells you the situation. Of course, if the low GD2 modes 0, 4 and 8 are used as machine native modes, then the mode trap should be extended in a universally accepted way. George rem Init if GD2 then blue = $70: : else blue = 0: rem Main ink#ch;blue This cant be done automatically without retro-engineering Qdos. Per
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 08:08:37 GMT Standard Time, [EMAIL PROTECTED] writes: } } 3) At present, there is no way of differentiating when a PIC file has been } saved using a GD2 colour scheme and when it has not. This causes problems } with the GD2 modes 0, 4 and 8. I would suggest that the unused byte at } offset 7 in the PIC file header is set to signify GD2 mode used. Offset 7 ? The pic format is: 0 Word tag : 4AFC 2 Word width 4 Word height 6 Word row 8 byte mode 9 byte spare So I guess that you are speacking of offset 9 rather than 7. It might be a good idea to use the spare byte for that distinction. Or we might have a stranger mode specification such as mode(2,0) is 255 and mode(2,8) is 254 (there is no conflict with 4, because QL mode 4 is stored as 0) 255 and 254 are arbitrary value, and we can choose whatever we want, as long as we get it documented and agreed by the Great Coordinator... I agree with this. How will the G... C... make His decision known? (This answers the question I have recently asked. Thanks.) } } 4) I presume that even if a palette mapped screen mode is used (7,15 or 31), } the program to create the PIC file does not need to concern itself, as it is } storing the pixel information PEEKed from the actual screen memory. Is this } correct, or should the PIC file be able to store the palette mapping } information?? I would not expect palette information to be stored with a pic file. It would mean that displaying such extended pic would overload the local palette, which is rather agressive behaviour (it would perturb the display of all the palette-based applications.) If palette independance is wanted, the user should export/convert the pic file in a fixed colour mode (such as 64: 24 bits per pixel, for example). But that's only my personal feelings. I would hope that a PIC file stores only information taken from the screen area, ie whatever COLOUR_NATIVE happens to be. George
Re: [ql-users] PIC File format
In a message dated 01/01/03 15:34:46 GMT Standard Time, [EMAIL PROTECTED] writes: If I store a PIC file of an area of the screen in MODE 8, which measures 202 pixels across, that is not exactly divisible by 2. You need 100 bytes to store the first 200 pixels and an extra 2 bytes to store the last 2 pixels (due to the fact that 1 word stores 4 pixels). As a result, the PIC header would need to read: $4AFC 202 50 (presuming height of area is 50 lines) 102 8 Is this correct?? Yes. for a width of n pixels the "increment" (ie the number of bytes per line of n pixels stored in the PIC file) would be 2*((n + 3) DIV 4) For mode 4 the "increment" would be 2*((n + 7) DIV 8) This assumes that the pixels in the screen image are packed to the left in each line. If, for example, you wanted to save the 2nd to the 9th pixel of a Mode 4 screen you would have to pack the information for these 8 pixels into two bytes to be saved after the header. The information would come from bits 0 to 6 of the first screen byte, bits 0 to 6 of the second bytes, bit 7 of the third byte and bit 7 of the fourth byte. At least this is what I would do. In fact I have written programs to save and print parts of a Mode 4, Mode 8, Mode 32 and Mode 33 screen, but I have restricted Modes 4 and 8 to widths divisible by 8 and 4 and starting on word boundaries. It just takes a wee bit more programming to extract or print areas which are not on word boundaries and not multiples of 4 or 8. Question. In my PSA files (as I call them in case PIC files are in a different format from the partial save areas defined in Jochen's QPTR manual) I use 4 or 0 in byte 12 to indicate mode 4. How does a PIC file do this? I use 32 and 33 to indicate these GD2 modes. There seems to be the possibility of confusion here in the coding of GD2 modes 0, 4 and 8. Does anyone know how PIC files cope here? George
Re: [ql-users] File Type/Directory?
In a message dated 01/01/03 22:21:08 GMT Standard Time, [EMAIL PROTECTED] writes: Can anyone tell me the best way in either 'C' or assembly to determine the file type (executable, directory, etc)? Thanks, Jim As it happens I have been doing just this in C. What I do is to read the header of the file and look at byte 5. The header is defined in sys_qlib_h as typedef qdirect_t and the item you want is d_type, which is "char". The header of 64 bytes comes if you use fs_headr. Obviously it is really the same in assembler. George George
Re: [ql-users] ThorXVI Mode 12 and Turbo
In a message dated 28/12/02 17:11:08 GMT Standard Time, [EMAIL PROTECTED] writes: George Gwilt has a THOR and usually tests his programs on it before releasing any changes to them. If the latest version does not work he would appreciate a description of the problem and the actions taken to cause it. I do have a THOR 21, which is a 68020 with 68881 FPU. However it only works for a short time after it is switched on before ram becomes corrupted. The result is that I have given up testing programs on it. But - if anyone has such a machine and wants any of my programs altered to suit I will be happy to have a go. George
Re: [ql-users] screenshoots ?
In a message dated 20/12/02 12:23:14 GMT Standard Time, [EMAIL PROTECTED] writes: > > Hi > > I have a screenshoot pages with my desktops, > http://www.kristnet.org/~migu/gallery/album01 > I like to add some SMSQ/E shoots, how do I make them ? > > /Michael > > There is a set of programs on the SQLUG website which will allow any portion of screen to be saved into a partial save area as defined in Jochen's QPTR manual. George
Re: [ql-users] WMAN progress
In a message dated 07/12/02 19:32:58 GMT Standard Time, [EMAIL PROTECTED] writes: > > I have successfully produced my own explanation windows now by WM.RPTRT on > your advice. However, I look to see where the pointer is on a timeout > (comparing the pointer position with each of the hit areas of the loose > items). ... thus reproducing what wm.rptr(t) has already done... Yes, of course, how stupid of me! The programs are now that much smaller. It is always better to allow the installed software to do its job rather than to re-write it. Because of that I wonder why more people don't use wm.setup to produce a working definition from a window definition. This seems simpler to me than having to invent the whole working definition fron scratch. Ah well... George
Re: [ql-users] WMAN progress
In a message dated 03/12/02 05:41:14 GMT Standard Time, [EMAIL PROTECTED] writes: If what you want to achieve is something like the little help windows in FiFi, this was done as follows: The user can determine the time the pointer should hover over the loose item before the help window pops up. Say it is 1 second. I read the pointer witt a very short timeout (2/50th sec) and then, when coming back, check whether the current item is still the same. If it is, I loop around until 1 s has elapsed (25 times in this case) and, if it is still the same LI, I open the help window. Else, I note the new current item number and do it again. I have successfully produced my own explanation windows now by WM.RPTRT on your advice. However, I look to see where the pointer is on a timeout (comparing the pointer position with each of the hit areas of the loose items). If it is a loose item I set its own window. If not I do nothing. Probably there is an easier way of dong this too! George
Re: [ql-users] WMAN progress
In a message dated 02/12/02 17:27:21 GMT Standard Time, [EMAIL PROTECTED] writes: There is a benefit in using iop.rptr I would imagine, that would be keeping it simple in situations you want to read the pointer without actually producing anything on screen (ie by shutting off SCR0 (This can be useful if you want to write custom Aurora 256 mode programs that move a custom pointer sprite instead of the WMAN one--- Of course all that until we finish the GD2 adaptation for Aurora ;-) Phoebus Yes. I use iop.rptr to move an object around the screen. In fact, because I want this to be available on machines without GD2 I only use the old 4-colours. But I could quite easily make the object any GD2 colour. George
Re: [ql-users] WMAN progress
In a message dated 03/12/02 00:31:25 GMT Standard Time, [EMAIL PROTECTED] writes: From your original message I got the impression that perhaps you have an older version of the manual. For example there is no mention of WM.DRBDR on my page 86. In my manual WM.DRBDR is described on p 88 and it correctly says that is vector $44. So perhaps the description in your manual is incomplete too? It says here: To clear the current item, set the msb of WS_CITEM and, if WS_CIACT is clear, call WM.DRBDR, otherwise call the routine pointed to by WS_CIACT and then clear WS_CIACT. To set a current item, set WS_CITEM, WS_CIBRW, WS_CIPAP (to the highlight colour) and the hit area WS_CIHIT. Then call WM.DRBDR. Finally reset WS_CIPAP to the background colour, and Bobs your aunt's live-in lover! Yes indeed! This is exactly (barring BYLL) what's on my page 86. I must be the one whose subs are out of date! Anyway the actual routine still doesn't do what the manual says. <> > As to the use of iop.rptr, this does not put lines around any item and take > them, away. wm.rptr(t) does but you can't mix both. > > It would certainly be nicer if you could use wm.rptrt than iop.rptr. However, > does that also deal with "dragging"? Have you tried: repeat wm_loop wm.rptr if drag_item is hit then repeat iop_loop iop.rptr if not keydown exit iop_loop keep dragging end iop_loop endif end wm_loop I'll certainly try this. Thanks. Its remarkably difficult to get right, but I think it can be made to work. ALL PE is immensely hard! But in TurboPTR I am reasonablr happy. In C it is more of a problem - but I'm getting there. So I'll try that too. Per George
Re: [ql-users] WMAN progress
In a message dated 03/12/02 00:31:08 GMT Standard Time, [EMAIL PROTECTED] writes: I have four pages of updates (also undated) that takes me from wm.erstr to sms.wevt, but no mention of wm.rptrt. The pages QPTR Updates have Addnl Info on WM.ERSTR and WM.LDRAW on page1; additions to IOP.RPTR on page 2; the "new" sms.sevt and sms.wevt on page 3; the "new" WM.RPTRT on page 4. Perhaps Per's page 4 was missing? George
Re: [ql-users] pointer programming - 'C' routine problem list
In a message dated 01/12/02 21:26:55 GMT Standard Time, [EMAIL PROTECTED] writes: Sorry, not true. See my earlier message re Jonathan Hudson's work on this. I have now used wm_rptrt in 2 programs - although only using the timeout rather than the signal process. JH provided corrected code some time ago. Christopher Cave I can confirm that wm.rptrt works in TurboPTR (with a new extension of course to be issued soon I hope). George
Re: [ql-users] WMAN progress
In a message dated 29/11/02 11:43:17 GMT Standard Time, [EMAIL PROTECTED] writes: > Produce the little explanatory windows after the pointer has rested on > a loose item for more than a certain time, as in QD. yu can also do that with wm.rptrt (vector $78), which allows a timeout (much easier!) This is the way FiFi handles the small help windows. (...) > WM.RPTR very kindly draws and undraws borders on > items as the pointer moves over them. By using iop.rptr, a programmer > forgos this facility and has to do it himself. ... which will result in a loop similar to that introduced by wm.rptr(t). > 1. The manual (page 86) says that WM.DRBDR is accessed by vector $68. > In fact it should be $44. yes, $68 is wm.rname 2. The routine actually seems to perform the > same operation for both drawing and undrawing so that the MS bit of > WS_CITEM seems not to be used. Is this true? The operation performed > is to draw a border of colour WS_CIPAP in the status area. This has to > be set by the programmer to the highlight colour for a draw and to the > window's paper colour for undraw. After this has been done the routine > checks that in fact the pointer is somewhere in the program's window. > Fine for drawing - the pointer must be there. Bad for undrawing if the > pointer is moved out of the item and out of the program's area > altogether before the PE software notices. I solve that problem by > ignoring an "out of range" error on an undraw. Doesn't that mean the the item stays marked as current? No. WM.DRBDR draws/undraws the border first. Then it checks whether the pointer is in or out of the program's window area. wm.rptr(t) checks whether the pointer is out of the window, and, if so, clears the curent item. Wolfgang In fact I wasn't aware of wm.rptrt until Jim Hunkins reported that it didn't work in C68. But I still don't see how you tell that wm.rptrt has timed out while waiting on a loose item (or anywhere for that matter). If you check when timeout has occurred (incomplete) and look to see that you are now on a loose item, do you check that you were there when you called wm.rptrt? Even then what's to prevent you moving the pointer back to where it was just before timeout? Do you assume that if the position is exactly what it was at exit as at entry no movement has taken place? As to the use of iop.rptr, this does not put lines around any item and take them, away. wm.rptr(t) does but you can't mix both. It would certainly be nicer if you could use wm.rptrt than iop.rptr. However, does that also deal with "dragging"? George
Re: [ql-users] WMAN progress
In a message dated 30/11/02 00:25:04 GMT Standard Time, [EMAIL PROTECTED] writes: This is not documented anywhere in my Qptr manual!! (3rd revision) so its the first I hear of it. It looks like its been in the code all along. Ive needed such a call many a time! Apart from the timeout, are there any other parameters? D2.B = job-events to return on Per It is in my manual just as QPTR Updates (no date). Perhaps you didn't renew the subscription for updates(?) Also in that update are the trap#1 calls sms.sevt and sms.wevt that trouble J. Hunkins. George
Re: [ql-users] Re: pointer programming - 'C' routine problem list
In a message dated 28/11/02 06:51:24 GMT Standard Time, [EMAIL PROTECTED] writes: Sorry, left a major one off my list of 'C' wrappers that have errors. Here is the revised list: iop_flim sms_sevt sms_wext wm_rptrt Jim I thought Jim was saying that there were errors in the GD2 routines. In fact I tested these about two year's ago and they seemed OK then. The items Jim has listed as containing errors are not GD2 after all! However, since I promised to look into these I will now report. iop_flim The code for this is very simple and seems to contain no errors. I tried it in a C program and found that it worked. So what is the problem here? sms_sevt The program here is also very simple: MOVEQ #$3A,D0 MOVE.L 4(A7),D1 destination job ID MOVE.W 6(A7),D2 events to notify TRAP #1 do it RTS I didn't try it, but what is wrong with it? sms_wext The program for this is as follows. MOVEQ #3B,D0 MOVE.L 4(A7),A1 address containing events to wait for MOVE.B (A1),D2 this moves the top byte of (A1) to D2 (we must hope that the top byte IS the event byte!) MOVE.W 6(A7),D3 timeout TRAP #1 do it MOVE.L 4(A7),A1 retrieve the address for the event byte M0VE.B D2,(A1) push the events causing the return -> (A1) RTS Provided the top byte of the address sent to the routine contains the event byte this looks as though it will work. Unfortunately D3 is not preserved. As I understand it D3 may be used to hold data by C68 and so should be preserved. A better program might be MOVE.L D3,-(A7) MOVEQ #$3B,D0 MOVE.L 8(A7),A1 4 added because of the saving of D3 MOVE.B (A1),D2 MOVE.W 10(A7),D3 " " TRAP #1 MOVE.L 8(A7),A1 " " MOVE.B D2,(A1) MOVE.L (A7)+,D3 RTS If the return from sms_wevt is to be the error code we perhaps should also add MOVEQ #0,D0 before the RTS since sms.wevt returns no errors (but does it clear DO?). wm_rptrt It is clear from the coding that no-one except Jim has attempted to use wm_rptrt. I give the code below and you will see why. MOVEM.L D2-3/A4,-(A7) MOVE.L $10(A7),A4 1st parameter - pointer to working defn MOVE.W $14,D3 Hmmm!!! MOVE.W $16,D2 Hmmm!!! MOVEQ #$78,D0 JSR wm_chkv get the vector BMI.S L oops - no vector JSR (A0,D0,L) do wm_rptrt TST.L D0 OK . . . BMI.S L . . . no MOVE.L A0,D0 channel ID to be returned L MOVEM.L (A7)+,A4/D2-3 RTS The two lines with "H!!!" are missing the (A7) which rather spoils the program. If I were changing this code I might consider NOT preserving D2, since it is only used by C68 as a scratch register. I hope this is of help to some. And also that Dave Walker is listening in. Cheers George
Re: [ql-users] pointer programming
In a message dated 28/11/02 06:48:36 GMT Standard Time, [EMAIL PROTECTED] writes: One caution for 'C' coders - if you are using the new GD2 calls and the message passing routines that are available in C68, I have found that several of the 'C' wrappers that call the native assembly routines are incorrect. Some of the corrections have been passed on (block drawing for example) and have been incorporated into the C68 release (make sure that you have the latest libraries). Unfortunately I haven't had a chance to do it with the rest of the ones that I have found. Here is a list of problem routines that I hit so far. I will submit my 'corrected' 'C' routines if I ever come up for air but QDT is taking precedence at this time. iop_flim sms_sevt sms_wext Jim I wrote the originals of the functions for GD2 and these were put into C68 after some changes. I will have a look at the routines you mention. George
Re: [ql-users] WMAN progress
In a message dated 27/11/02 14:34:17 GMT Standard Time, [EMAIL PROTECTED] writes: > >A better way would be a menu designer for QPTR, of course... >Would also make it easier for Assembler programmers > >(...) >> * I hope all this makes sense ;) > >It does to me. > Well THERE'S GOT TO BE an easier way... ie an easier Interface for PE programs Right now the whole process looks so much like Visual Basic Window Definitions it's not even funny. I think the problem lies in trying to make a procedural language (SBasic) to work like a oO one. I looked into Jerôme's C68 PE articles and I got SCARED! Timothy Swenson's article on the same thing made the whole lot look a lot more easier but that didn't change the fact that the whole process is complicated in itself! In any way, I was thinking about what Wolfgang said too. A QPTR menu designer along the lines of EasyPTR would be great (It would be greater if it were free too :-). What would be even better is to create a good all-round IDE w/GUI designer that would remove all the menial work from the programmer completely. Yes like EasyPTR but adding up something like the Linker, a Basic compiler (Turbo seems great for the job ;-) a tool like MasterBasic an editor and a debugger all rolled into one. Hmm I'll look into it when I get some more time in my hands (after finals in two weeks). Why don't you have a look at TurboPTR? I find that the easiest way to atttack PE. George PS TurboPTR is on the SQLUG website.
Re: [ql-users] WMAN progress
In a message dated 26/11/02 17:26:31 GMT Standard Time, [EMAIL PROTECTED] writes: iop.rptr does if you set the appropriate bits in the return vector. But Wman calls (wm.rptr) only respond to "events" (see the Qptr manual, pages 89 ff "Window Manager Access Routines") WM.RPTR does a lot of work for the programmer, but has a fairly complicated way of monitoring the position of the pointer and any mouse clicks/keystrokes. I wanted to do two things. a. Drag a block throughout an area (eg for use as a scroll/pan bar) b. Produce the little explanatory windows after the pointer has rested on a loose item for more than a certain time, as in QD. To achieve this I read the pointer directly by iop.rptr, which,amongst other things, allows timeouts. Doing this will allow a programmer to react to a HIT or DO on any area, not necessarily in an AW or LI. I think this could solve the problem. However, it introduces another one for the programmer. WM.RPTR very kindly draws and undraws borders on items as the pointer moves over them. By using iop.rptr, a programmer forgos this facility and has to do it himself. Actually it is not difficult. However - there are two snags. 1. The manual (page 86) says that WM.DRBDR is accessed by vector $68. In fact it should be $44. 2. The routine actually seems to perform the same operation for both drawing and undrawing so that the MS bit of WS_CITEM seems not to be used. Is this true? The operation performed is to draw a border of colour WS_CIPAP in the status area. This has to be set by the programmer to the highlight colour for a draw and to the window's paper colour for undraw. After this has been done the routine checks that in fact the pointer is somewhere in the program's window. Fine for drawing - the pointer must be there. Bad for undrawing if the pointer is moved out of the item and out of the program's area altogether before the PE software notices. I solve that problem by ignoring an "out of range" error on an undraw. This is easy in C68. All you do is ignore the out of range error return from the function. In TurboPTR I had to introduce a function to return the error routine when accessing WM.DRBDR. I can then ignore -4. I wonder if anyone else has had this trouble. George
Re: [ql-users] One box or two
In a message dated 17/11/02 04:46:12 GMT Standard Time, [EMAIL PROTECTED] writes: Having sold my Q40 to help fund a Q60 I now have thoughts about QPC. I know the arguments for and against both and I have QPC2 v3 demo. The unknown ( to me ) factor is speed, sure the Q60/80 is advertised as 160 bogomips but I would be purchasing a Q60/60. So would some kind soul's furnish me with the following if possible 1. speed of Q60/60 in bogomips 2. speed of QPC2 v3 on a 1.8 gh celeron based PC in bogomips I'm quite aware that benchmarks are not the be all and end all, but they are a factor to consider along with others, I have spare cash at the moment to purchase a Q60 but it could be used on other projects, oooh decisions decisions. The speed of the Q60 can be enhanced by the use of: * the 68020+ instructions * the use of the FPU Neither of these is supported (at the moment) by QPC. George
Re: [ql-users] GD2
In a message dated 13/11/02 18:12:27 GMT Standard Time, [EMAIL PROTECTED] writes: All sprites that are drawn on the screen are first converted to native mode and the resulting native mode sprite is stored in a little cache so that you do not need to keep on converting them (this is also the normal way of handling scaleable fonts in Windows, X-Windows etc) Actually, this is a VERY easy way of converting mode 4/8 sprites to, say, mode 33. Just look at the cache after translation and Bob's yout uncle! (If you can find the cache!!.) George
Re: [ql-users] Core software and Q60
In a message dated 13/11/02 11:52:30 GMT Standard Time, [EMAIL PROTECTED] writes: By the way, I remember you having problems with the sprite cache, i.e. that it didn't notice the changes in the sprite edited by sprted. The same problem already exists in WMAN, if you try to define different colours for several scroll/pan bars this will fail as only the first version gets converted. What solution did you come up with? I'd like a clean way to flush the sprite cache but didn't find one so far. Because of this problem, which I mentioned to Jochen who will have passed it to TT, I define all my sprites for use with TurboPTR as mode 4, 8 and 33. This solves the problem, since no translation is needed for the mode 33 sprite, when the mode is, in fact, 33. George
Re: [ql-users] Core software and Q60
In a message dated 12/11/02 17:49:40 GMT Standard Time, [EMAIL PROTECTED] writes: Unfortunately this way there's currently no high colour sprite format in QXL/QPC (and if anybody's wondering that's one of the reasons why the high colour wman is still not finished). Is this why a mode 32 sprite (as described in the documentaion for GD2) doesn't work with QPC? A mode 4 sprite DOES work (presumably because it is changed to the appropriate format??). Any comments? George
Re: [ql-users] Qeymail, last call for suggestions...
In a message dated 12/11/02 14:50:56 GMT Standard Time, [EMAIL PROTECTED] writes: if you are going to use PE and you want to do it 'easily' get hold of EasyPtr (somehow) and there is a totally excellent tutorial avaiulable for download somewhere (Dilwyn's web emporium I think) which shows how to use it without having to go through the same steep learning curve that the author had to. Until I wrote that tutorial (oops !) I used to call the system DifficultPointer - ask Dilwyn, I had many a rant in those days :o) You might also consider looking at TurboPTR which aims also to make life easier for pointer driven programs. If anyone tries this system and finds that additions would make it more useful it is quite on the cards that the system would be upgraded. Have a look at the SQLUG website for the current version (soon to be upgraded in fact!). George
Re: [ql-users] Core software and Q60
In a message dated 12/11/02 17:49:40 GMT Standard Time, [EMAIL PROTECTED] writes: Unfortunately this way there's currently no high colour sprite format in QXL/QPC (and if anybody's wondering that's one of the reasons why the high colour wman is still not finished). Is this why a mode 32 sprite (as described in the documentaion for GD2) doesn't work with QPC? A mode 4 sprite DOES work (presumably because it is changed to the appropriate format??). Any comments? George
Re: [ql-users] Turbo Compiled programs
In a message dated 02/11/02 15:13:04 GMT Standard Time, [EMAIL PROTECTED] writes: George Gwilt is the expert on how to get at the source of compiled programs. However it may not be possible unless the program has been compiled with flags in the same way as C programs can be compiled with a switch so that a debugger can access the lines and enable one to step through it. I know he uses a similar switch for debugging Turbo itself. John may think I know more than I, in fact do. It is true that I will find ways of stepping through a Turbo compiled program to find what is happening. That is not at all the same thing as un-compiling a program. The only way I would embark on such a project is if it were absolutely the only way that I could see to achieve something that I thought was ABSOLUTELY ESSENTIAL. In that case I would probably find a solution. As it is . . . . George
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
In a message dated 25/10/02 17:12:18 GMT Daylight Time, [EMAIL PROTECTED] writes: I have thought about this, and here's how I would solve the problem. Just make it a standard that a toolkit looks for an existing instance of the keyword, and if it is in use, alter the keyword in a standardised way. Eg: WIBBLE tk9_WIBBLE jms_WIBBLE But that's just me. HM! Well! What would happen to a standard program needing WOBBLE which was changed to WABBLE by this process? Actually, both Qlib and Turbo are (or very soon will be) able to "include" the extensions really needed in the program so that they do not need to be LRESPRd at run time. Although this makes for longer programs compiling them might help to solve the problem of 72 keywords all called WYBBLE and all doing different things. George
Re: [ql-users] Movep
In a message dated 08/10/02 17:37:12 GMT Daylight Time, [EMAIL PROTECTED] writes: > GWASS treats 0(a4) as (a4), so the shorter version is always used here. > > George It takes some effort to force an assembler that "helps" like that, when you really do want it to generate the zero offset. You have to define an external that will supply a zero a link time. IIRC there is a bit of code in the debugger that I wrote that needed to do it. It wanted to generate a live sequence of code to push on the stack with an offset to be filled in. I'm not too sure about assemblers that "help" too much. E.g. when you are writing I2C drivers and need to account for every cycle, it's no fun if the assembler quietly replaces your instructions with ones it thinks are "better". A good solution is for an assembler to accept an override control saying "don't mess with what I write". The effective address 0(a4) which GWASS sets to (a4) is an exception to the normal GWASS rule, which is just what you state, namely that a programmer should be master of what he writes. For example, GWASS will shorten branches where possible if they are written BRA but will leave them as requested if written BRA.W, BRA.L or BRA.S. I made GWASS use (a4) in place of k(a4) when k was zero because it seemed obvious at the time that this should be done. It has certainly caused me to use DC.W when I really did want 0(a4) and not a4. If a change were to be made in GWASS over this instruction, I would simply delete the change from 0(a4) to (a4). George
Re: [ql-users] Movep
In a message dated 20/09/02 11:24:47 GMT Daylight Time, [EMAIL PROTECTED] writes: Note. In Fabrizio's original code, using: move.b 0(a4),d1 instead of: move.b (a4),d1 typically causes an assembler to generate exactly what is asked: a four byte instruction with a zero offset for a4 in the second word. GWASS treats 0(a4) as (a4), so the shorter version is always used here. George
Re: [ql-users] QMAKE - FIXED !!!!
In a message dated 19/08/02 16:19:04 GMT Daylight Time, [EMAIL PROTECTED] writes: Uh, one of the other features I asked for MANY, MANY years ago when I implemented the TAB compression in QD. You should definitely get the latest QMAC, Norman. Pity you're not using GWASS!! George
Re: [ql-users] (no subject)
In a message dated 23/07/02 22:02:02 GMT Daylight Time, [EMAIL PROTECTED] writes: Be careful not to use v3.90L instead you should use v3.90L. Confused? Good that is normal, 2 versions same number :-) look for the 187768 bytes version, I am sure Derek would sort you out with it if you like. You could be using a hacked version? very difficult for me to test this as I do not have a Q60 :-( good news, I am going to order myself one in the next production run :-) Thanks. I'll have a look. BTW the Q60 is well worth it. George
Re: [ql-users] (no subject)
In a message dated 23/07/02 20:42:22 GMT Daylight Time, [EMAIL PROTECTED] writes: Hmm that is interesting to read... is it just Abacus that fails I wonder?? May be that it uses one of the commands not supported on 68040+ - certainly ok on 68020. I am not sure, but think Xchange is compiled in C or was it re-written in machine code as planned in the early days... Yes. It is just ABACUS. I use ARCHIVE happily on Q40 to do tax returns with 10 year old programs without difficulty. I certainly don't want to write new ones! George
[ql-users] (no subject)
Does anyone know of a version of xchange which contains an ABACUS that works on a Q40 or Q60? If so where does it reside? George
Re: [ql-users] SMSQ Source upgrading, & assembling.
In a message dated 10/07/02 15:01:10 GMT Daylight Time, [EMAIL PROTECTED] writes: How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? I thought I had answered that. The answer "quite a lot". I would imagine it might even be as much effort as required to change an emulator to deal with the advanced set of instructions in the 68020+. George
Re: [ql-users] GWASS and the SMSQ source code
In a message dated 10/07/02 16:19:28 GMT Daylight Time, [EMAIL PROTECTED] writes: I believe that George has made the source code for GWASS available. (At least I think so) If so, maybe someone would like to take on the task of rewriting it to only use 68000 instructions. :o) Good point!! George
Re: [ql-users] SMSQ Source upgrading, & assembling.
In a message dated 10/07/02 15:01:10 GMT Daylight Time, [EMAIL PROTECTED] writes: How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? Far too much I'm afraid! GWASL, which is an amended version of the assembler written originally for the 68000/8 instruction set, will run on all machines but will not assemble 68020+ instructions. Although it has a macro facility I am fairly certain that it does not produce relocatable SROFF output. This was added to GWASS at the request of Dave Walker so that it could be used with C68. Given that so many actual hardware QL type machines exist, I am slightly surprised that no one is willing even to consider the possibility of an enhancement of the various emulators to cover the extra 68020+ instruction set. I may say that because of that shortcoming I would not consider acquiring QPC2 for example. Otherwise I would certainly buy it! The net result is that I would find it very hard to consider downgrading GWASS. Sorry! If anyone who does not have a 68020+ facility would like to have the result of a GWASS assembled output, they could just let me (or anyone else with a 68020+) have the source and the resultant file could be sent back to them. (Why not invest in a Q60?) George
Re: [ql-users] SMSQ Source upgrading, & assembling.
In a message dated 10/07/02 07:04:04 GMT Daylight Time, [EMAIL PROTECTED] writes: Facetiousness put aside, I'm pretty sure that we'll be able to find a modus vivendi that will allow us to move forward. If things really needing a 68020+ instruction set really come out, there is always a possibility of making it into modules. Even if I wanted to be really strict about the QMAC compatibility, ways could be found (off the top of my head, use DC.W instructions, for example). Yes, things do need some 68020+ instructions if the resulting SMSQ/E is to be usable on QXL, SuperGold Card, Q40 and Q60 since at least some of these, if not all, have some CACHE instructions. These, of course, use the appropriate 68020+ instructions. Obviously you can use DC.W instructions for these, but it is marginally simpler to use the instructions directly. George
Re: [ql-users] SMSQ Source...
In a message dated 10/07/02 07:04:00 GMT Daylight Time, [EMAIL PROTECTED] writes: > Anyway, what is so bad with a set of GWASS-type macros to replace the > Qmac ones provided the USER of these macros can code them in almost > exactly the same way as for Qmac? Simple: you have to change much of the code. It depends how the "code" is organised. In PE applications it is natural to "include" a file containing all the Qmac macros needed. Actually for PE there are two files - one for window definitions and the other for text. In that case substituting one set of macros for another is easy. However, if the macros are dotted around all over the place in a disorganised way, then I admit it would be more tedious. However, since each macro must be enclosed in the header commands and "endm" it can easily be identified by a suitable editor thus making substitution quite easy. Indeed, this sort of problem is one I normally solve by the use of a one off Basic program which would make the substitutions automatically. George
Re: [ql-users] SMSQ Source upgrading, & assembling.
In a message dated 09/07/02 21:00:37 GMT Daylight Time, [EMAIL PROTECTED] writes: I am not convinced How difficult would it be George, to allow GWASS to work on the 68000 chipset?? GWASS needs a 68020+ to operate. But it can produce code siutable for 68000/8 (ie the basic instruction set) by the command LOW_EA (I think!). This prevents GWASS setting long branches, for example. I regularly use GWASS for programs which must be usable on all machines. George
Re: [ql-users] SMSQ Source...
In a message dated 08/07/02 09:59:56 GMT Daylight Time, [EMAIL PROTECTED] writes:
I'd prefer GWASS to be amended!
I assume you mean that you would like GWASS to be altered so that the Qmac macros would work without any change. There are various reasons why this wouldn't be easy or indeed possible.
For example the conditional instructions in GWASS are global - not confined to macros as I believe the Qmac ones are. You also need an "endif" in GWASS.
Also setnum and setstrg of Qmac set numbers and strings inside a macro. GWASS's "set" is again global. It can be used anywhere in a program to set a variable of whatever sort and to reset it later.
A third problem would be strings. In GWASS a string may be delimited either by apostrophes (') or by quotes ("). Only the former are allowed in Qmac.
Anyway, what is so bad with a set of GWASS-type macros to replace the Qmac ones provided the USER of these macros can code them in almost exactly the same way as for Qmac?
George
Re: [ql-users] SMSQ Source...
In a message dated 05/07/02 16:45:58 GMT Daylight Time, [EMAIL PROTECTED] writes:
It is compatible to stuff like
[...]
mkcf_sloop maclab
mkcf.pr0 setstr {[.parm([mkcf.atr])]}
ifstr {[.parm([mkcf.atr]+1)]} = {} goto mkcf_ank
mkcf.pr1 setstr {'[.parm([mkcf.atr]+1)]'}
goto mkcf_pr2
mkcf_ank maclab
mkcf.pr1 setstr {0}
mkcf_pr2 maclab
mkcf.apo {[.parm([mkcf.atr]+2)]}
mkcf.pr2 setstr {[.len(.parm([mkcf.atr]+2))],'[mktxt]'}
mkcf.prm setnum [mkcf.prm]+1
mkcf[mkcf.prm] setstr { dc.w [mkcf.pr0]<<8+[mkcf.pr1],[mkcf.pr2]}
mkcf.atr setnum [mkcf.atr]+3
ifnum [mkcf.atr] < [.nparms] goto mkcf_sloop
mkcf.prm setnum [mkcf.prm]+1
mkcf[mkcf.prm] setstr { dc.w -1}
goto mkcf_iend
Although the above extract is not complete, I can indicate how each command would be expressed in Gwass.
Qmac Gwass
maclab macl
setstr set
setnum set
.parm(n) |#PARM(n)~
[] |~
.nparms \0
goto goto (no difference)
ifnum if
ifstrg if
Macros transferred from Qmac to Gwass tend to look a bit different - sometimes a lot different. Translating macros would take some effort which I am quite prepared to take if they would be used. The big plus is that once the macros are translated their use needs very little alteration from the Qmac syntax.
George
Re: [ql-users] SMSQ Source...
In a message dated 05/07/02 16:45:58 GMT Daylight Time, [EMAIL PROTECTED] writes:
> Why not try GWASS? I would be surprised if it couldn't be made to do
> the job.
It is compatible to stuff like
[...]
mkcf_sloop maclab
mkcf.pr0 setstr {[.parm([mkcf.atr])]}
ifstr {[.parm([mkcf.atr]+1)]} = {} goto mkcf_ank
mkcf.pr1 setstr {'[.parm([mkcf.atr]+1)]'}
goto mkcf_pr2
mkcf_ank maclab
mkcf.pr1 setstr {0}
mkcf_pr2 maclab
mkcf.apo {[.parm([mkcf.atr]+2)]}
mkcf.pr2 setstr {[.len(.parm([mkcf.atr]+2))],'[mktxt]'}
mkcf.prm setnum [mkcf.prm]+1
mkcf[mkcf.prm] setstr { dc.w [mkcf.pr0]<<8+[mkcf.pr1],[mkcf.pr2]}
mkcf.atr setnum [mkcf.atr]+3
ifnum [mkcf.atr] < [.nparms] goto mkcf_sloop
mkcf.prm setnum [mkcf.prm]+1
mkcf[mkcf.prm] setstr { dc.w -1}
goto mkcf_iend
[...]
GWASS was altered a few years ago to allow macros of this sort. This was to enable the large set of macros used in QMAC for Pointer Programs to be used in GWASS, after modification.
If you send some of these macros to me I'll see how they can be amended.
It shouldn't be too difficult.
George
Re: [ql-users] SMSQ Source...
In a message dated 29/06/02 11:01:00 GMT Daylight Time, [EMAIL PROTECTED] writes: It is also a feature of qmac that it cannot, afaik, use relative offsets for include files. Gwass can, but then there may be other issues (like sections)? Perhaps George can let us know whether Gwass can assemble and link SMSQ as it stands? Alternatively, Phil Borman may be interested in up-dating/grading qmac (also wrt the 680x0 instruction set)? Does anyone here have contact with him? I would be surprised if GWASS couldn't assemble SMSQ. I sometimes use Qmac on code written for GWASS and, by and large, it works. However, proof of the pudding is in the eating. If someone were to send me a section of SMSQ I could try GWASS on it. You do need a 68020+ of course. This means a Q40, Q60 super Gold Card or QXL. George
Re: [ql-users] FPUFNs 1.7.1
In a message dated 26/06/02 20:41:36 GMT Daylight Time, [EMAIL PROTECTED] writes: George Gwilt once told me that there is a extension that lets one use the Floating Point Unit of Q40 and Q60 (also QXL with replacement processor with FPU) from BASIC. The software is written by Simon N Goodwin and he was so kind to pass it on to me for release. There may be some guys who already know it, but to me it was new and I also couldn't find it at the usual places for QL software. It is free and open source. Please get it from http://q40.de (Programs section) Speed increase can be huge, depending on the math functions used. I have used Simon's floating point functions for some time now on my Q40. Having recently tried them on my Q60 I found two mistakes in FPSP_60, the floating point software package containing code for the floating point instructions not in the 68060 hardware. The first mistake will treat SIN as COS if COS has previously been requested. The second causes the routine I_TO_Q, which translates IEEE floating point to Qdos format, to crash the Q60. I have thus produced a new version of FPSP_60. Version 1.4 of the FPSP_60 will very soon be on the SQLUG web site inside the updated FPSV package. Also included is a new version (1.20) of FPSAVE. This will not accept versions of FPSP_60 earlier than 1.4. Otherwise version 1.20 of FPSAVE is the same as version 1.19 which can continue to be used by 68040s (eg Q40). George
Re: Re[6]: [ql-users] Come & get it
In a message dated 17/06/02 21:14:41 GMT Daylight Time, [EMAIL PROTECTED] writes: Gac> Are PSA, ie Partial Save Areas, as defined in Jochen's QPTR Manual on page Gac> 110, acceptable? I would hope so as I now can grab any rectangular area on a Gac> screen in that format when I want. Gac> George Gwilt George I presume this is just a _pic file, if so yes. The format of a Partial Save Area is: Spare Long available to a user Flag Word $4AFC X_size Word width in pixels Y_size Word Height in pixels Increment Word length of one line in bytes Mode Byte mode of saved image Spare Byte zero Image Increment*Y_size bytes The "Image" is simply the exact copy of the part of the screen which is saved. If the mode is 33 (as for the Q40/60 extended colours) each pixel is a word. For mode 4 each word contains 8 pixels. I would imagine that a _pic file is not in that format, but I could be wrong.
Re: [ql-users] Re: QPC
In a message dated 14/06/02 01:30:56 GMT Daylight Time, [EMAIL PROTECTED] writes: John Sadler wrote: > Does QPC emulate 68020+ and floating point instruction set? No. > If not why not extend it so it does, Basically just too much work. > so we can use some of the programs George Gwilt is writing, > particularly his progrms for manipulating images and getting > pictures of Kodak digital cameras. He needs floating point for that? Yes and no! To change the size of a "partial save area" I use the 68020+ instruction set, which by the way is standard on QXL, Q40, Q60 and Super Gold Card. This operation does not use a FPU. I also plan to allow the "distortion" of an image so that it appears to be on a cylinder or sphere. This I plan to do using a PFU. Some QXLs, all Q40s and Q60s have this facility - so why not use it? George Gwilt
Re: [ql-users] Plight of a Software House
In a message dated 11/06/02 09:58:45 GMT Daylight Time, [EMAIL PROTECTED] writes: I think that to start the ball rolling, we need someone to take on the reins of easyptr - bring this up to date and possibly enhance it to create the bare bones of a SuperBASIC procedures to call the menus at least and cater with standard functions in menus, similar to how Visual Basic on the PC does things. This is surely not that a difficult task, as many users of the program will already have fairly standard PROCedures/FuNctions which they start of with... I have a library of ones which I have were based on the original series in Quanta on how to program EasyPtr and I have used these to good effect to produce Q-Help, Q-Index and Q-Route fairly rapidly. Anyone willing to take this on?? TurboPTR, available from the SQLUG website and from Dilwyn's, is intended to allow programmers to use SuperBASIC to write PE programs. This system also allows these programs to be compiled by Turbo, which considerably speeds them up. I have had some useful feedback from Geoff Wicks but from few others (if any!). Anyone who has suggestions that can be implemented will probably find these incorporated in an update. Will this produce a flood of ideas? Incidentally I recently took a course in VB partly to see how similar it was to TurboPTR and found the latter much more modest though along the same lines as VB. Some of the VB possibilities have been added to TurboPTR already. George Gwilt
Re: [ql-users] Camera
The Kodak DC215 can easily be accessed by the Q40 and Q60. I use my own program Digiview to do this. In case anyone is interested, I'll put the program on the SQULUG website. George Gwilt
Re: [ql-users] Camera
The Kodak DC215 can easily be accessed by the Q40 and Q60. I use my own program Digiview to do this. In case anyone is interested, I'll put the program on the SQULUG website. George Gwilt
Re: [ql-users] Forwarded on behalf of Nasta
In a message dated 24/05/02 20:24:58 GMT Daylight Time, [EMAIL PROTECTED] writes: > I think only the linker, but I though it can be freely distributable? There > is a free assembler, assuming of course you can assemble the sources with > it (gwass?) no idea, the code makes some use of macros so this may not be trivial. I've not looked at the (c) status of Quanta assembler and linker closely. I would imagine that GWASS would cope. It does have quite an extensive macro facility. Another point is that GWASS can be altered to do whatis needed (provided the change is not too major - [unlikely]). George Gwilt
[ql-users] Screen size
An assembler program to find the size of the current screen in pixels is included in the library of routines held in the SQLUG web site @ . I have used this in the latest versions of NET_PEEK and DISP3 to allow these programs to be moved on pressing F9, as for The Editor and Perfection. Minor amendments to the program allow it to produce a function which can be used in a C program. The result produced is 2^16 * x_size + y_size. George Gwilt
