Re: [ql-users] dragdrop
Ive tried to post a certain message on this topic a number of times, but it doesnt get through! It doesnt contain any obscene language or anything like that (although the words size and large appear three times - could that be the problem?) I dont find this list server very reliable. Messages sometimes take a long time to arrive, and do so rather higgledy-piggledy (probably as a result) - much more so than with nvg.ntnu.no... Per
[ql-users] Re: [ql-users] £ 0.00 to spend! (1st attempt)
Peter Graf writes: Time for an offer: I could possibly be persuaded to try and integrate my drivers into SMSQ/E for the whole range of QL style machines, by a simple act of wisdom: Place SMSQ/E under the GPL. (I have no problem to accept modifications to allow QPC remain commercial.) Speaking for myself, the only persuasion Id be inclined to attempt is for you to come in from the cold. Per
[ql-users] Turbo
Just thought I should mention something that might cause a few strange hiccoughs: Turbo Toolkit (TTK) comes in two different forms, one version for SMSQ/E and one generic version. The generic PEEK$ and POKE$ are a sub-set of SMSQ/E's PEEK$ and POKE$ and have therefore been ommitted in the SMSQ/E version. This implies, among other things, that (Basic or compiled Basic) programs that claim to be SMSQ/E compatible wont be if you have loaded the generic version of TTK into SMSQ/E. Always use TURBO_SMSQ_CODE in SMSQ/E. Per
[ql-users] Re: [ql-users] £ 1000 to spend! (2nd attempt!)
Geoff Wicks writes: Remember your subscription is your money, not Quanta's. How would you like them to spend it on your behalf? In a way, hardware development is more deserving as hw developers have real outlays apart from spare time, ie their profit can go negative rather than just zero. But how relevant is hw development at this time? Rather than the sexy stuff, like an AuroraII or a Q3500 (!), we would need things like USB, CD drives and Ethernet just to stay afloat. Can a small sect support such an undertaking, even with leveraged assistance from Quanta? I think possibly the best place to start would be with a survey - a massive and thorough one - to try to determine what punters really, really want. (See http://www.questionpro.com/ for a way of doing it via email or the web) I know our record on responding to surveys has not been great in the past, but things change and lessons are learnt, so, together with the sort of promotion we saw for QL2000, it could still be a sucess. Without it, we are blind and cant really hope to get it right. A survey should determine what people already have and what they wish for; how much they would be prepared to spend on various proposed strategic and desirable items; how punters would respond to un-renewable hardware packing up; how well aware people are of existing alternatives; etc Keep up the good work Geoff! We need it ;) Per
Re: [ql-users] dragdrop
Wolfgang Uhlig writes: I have two questions, though: 1) With the PVAL procedure (result%(10 and 11)) I can determine the origin of a window. How would I have to alter your line 100 when PVAL returns xorg%=500, yorg%=300 (just to take an example) As you will know by now, I sent you the solution in a private mail: A small SBasic function to cut out any reasonable sized piece of screen and convert it to a pointer sprite. 2) In line 150 you define the opacity of the sprite. Could you explain which change to the value would result in which degree of opacity? Possible alpha-mask values go from 0..255, with 0 being totally transparent and 255 being solid. Thus the value I chose, 128, makes the sprite semi-transparent. Per
Re: [ql-users] Menu_rext
On March 13, 2004 6:52 AM, Wolfgan Lenerz wrote: On 13 Mar 2004 at 1:37, P Witte wrote: (...) On 13 Mar 2004 at 3:17, Marcel Kilgus wrote: (...) Don't you guys ever sleep? Of course. Only we get up a wee bit earlier than you ;) Per
Re: [ql-users] Menu_rext
Wolfgang Lenerz writes: On 13 Mar 2004 at 1:37, P Witte wrote: (...) I've now also tested this on ram, and the problem does, indeed, exist there But this is still with a patched version of menu_rext Thanks for your help - Marcel too. This gave me enough info to get a grip on the issue. I first thought there might be a difference between the German and English versions of Menu_rext, but that wasnt the problem. The problem is a bug in the short filenames implementation. This is set in the configuration item: Menu Extension/General/Short filenames in File-Select/ If you configure this item to Yes you get the deviant behaviour as described in my earlier mail. Strangely, this doesnt affect FILE_SELECT$ anymore. Can this be fixed, please? Per
[ql-users] Menu_rext
Hi all, I have a wee problem with Menu_rext, the ubiquitous menu toolkit from Jochen Merz Software. I need to find out whether the problem Im experiencing is confined only to my systems or whether there is a bug in menu_rext. Could as many as possible of you please perform the following test: This applies to any system (please specify in your feedback) with PE and menu_rext loaded. Also your system should support hard directories and have at least two drives or devices available. Save and secure any valuable data in memory first! In SuperBasic or an SBASIC instance type OUTLN PRINT DIR_SELECT$ (If youre not using SMSQ/E you may need to use a different keyword for Outline, eg OUTL in EasyPtr) Say you have two drives, win1 and win2_. Select a directory that exists on one drive, such as win1_prg_, that does not exist on the other. Now click on 2, so the directory selector shows win2_prg_ (which mustnt exist) If your computer crashes, or you see garbage in the directory window, or, checking the Qpac2 Jobs menu, you see memory corrupted the test is complete. If not, try some other directories, eg dos1_windows_ then click WIN to get win1_windows_ If everything is still ok, please let me know too. Thanks for your help! Per
Re: [ql-users] New Mode 16 Sprite Collection
Tim Swenson writes: Per Witte is working on a MultiSprite Viewer. I have it but since he has not released it, I have not mentioned it or put it on my page. His viewer will view a whole directory of sprites. I viewed a directory of 485 sprites with no problem. I hope Per will release it soon. Sprite Viewer and Multi Sprite Viewer (imaginativeley named Sprv and Msprv, respectively) are available now. Under-the-bonnet access to these programs is enabled by inclusion of the source code. Sprv is best attached to your FileInfo2 database; view a sprite directly from Qpac Files or similar program; view it in its various states and under different system palettes; view some basic information on the sprite. Msprv allows viewing all sprites located in a single directory in one go. DOing one of the displayed sprites brings up that sprite in an instance of Sprv for more detailed inspection. Once Ive sorted out the hosting, the package will be available on the web somewhere. In the mean time it can be had directly from me at pj dot witte at fsbusiness dot co dot uk. Per
Re: [ql-users] Quanta
Dave P writes: a. The number of gun owners in the US is 80,000,000. b. The number of accidental gun deaths per year (all age groups) is 1,500. c. The number of accidental deaths per gun owner is 0.000188. Its the deliberate ones that are the worry. Per
Re: [ql-users] Quanta
Phoebus R. Dokos writes: and a couple of others running custom QDOS-based software, that unfortunately cannot work with SMSQ/e either. custom often meant pretty dirty; didn't it? Most likely, but where the user is concerned they really don't care as long as it works correct? :-D I agree 100%: as long as, as you say, it works. And keeps working. And doesnt stop other legally constituted stuff from working. Unfortunately, a lot of dirty software only starts screwing your system years later, eg when the OS gets ugraded.. We all make mistakes, but a deliberate high-handedness with the rules of the game makes life hell for everyone else long after the author has moved on to greener pastures. Per
Re: [ql-users] Quanta
Dilwyn Jones writes: What I'm getting at (not being familar with PC networks) is would you need a driver to access Ethernet in general (or another QL on ethernet), another driver to access a PC over a network, another driver to talk to a printer hub, another to talk to a Mac etc etc. I am still smarting a bit from other QL hardware like Aurora which for all their promised merits (no blame fired at anyone here) were not fully usable until the drivers eventually came along (thinking of Aurora 256 colours which were not fully supported until Marcel took the law into his own hands). You can probably see what I'm hinting at, if drivers are an issue, and we were asking Quanta to assist with development costs, need this only apply to the hardware or do we need to think of the software costs too. How about the existing NET driver; could that be easily converted to run over Ethernet? At least that would enable non-QL QLs with Ethernet capabilities to communicate.. Per
Re: [ql-users] wman
Jerome Grimbert writes, } I think this project would be good for the QL community as it would help } new PE programmers save the time in designing sprites. The more the same } sprites were used, the more PE programs would start looking more standard. There is, in the new SMSQ/E, a set of 'system' sprites which should do that. Look at the documentation. Sure, but it is not complete in my opinion. } As someone new to working with sprites, I'm willing to take some feedback } on what size the sprites should be or if they should be of multiple size. Sprites should be single size, but mode-linked (so that mode 4, mode 33 and mode 16 users always get What I meant by different sizes in my original mail on the subject was for small, standard and large sized suits of sprites: It is not always suitable to have a large, say 32x32 pixel, Quit sprite in a submenu. I think Tim's offer of hosting a sprite library is a great idea! Per
Re: [ql-users] Wanted: Aurora Tower System
John Gilpin writes: Have you considered an Aurora System in a Pandora Case? The two I use are so reliable that I think I could manage without my spare one. Famous last words ? Per
Re: [ql-users] Athlon 1,8GHz + Pentium 3 GHz + XP + QPC
Roy wood writes: ... and hard drives need defragmentation - even QL ones except we do not have a tool for it. QPC users have a simple workaround, though: Simply create a new QXL.WIN file and, from within QPC, copy the contents of the drive you need to defragment to the new drive, then delete the old QXL.WIN file. This takes in the order of 5 minutes to do. Per
Re: [ql-users] EasyPtr revisited
Rich Mellor writes: I have the sources for EasyPtr Per, if you would like to take a look. They do not make easy reading unfortunately and despite offers of help initially, no-one seems willing to take on the task of upgrading this software. Ok, lets take a look then, if its ok with Albin. Per
[ql-users] EasyPtr revisited
Hi all EasyPtr enthusiasts. Could you please confirm that MAWITEM wont process a high definition (mode 16 or 64)sprites/icons: Returns err_bp. I found a way around, though (after much hassle!) Define a sprite chain, with the first sprite a mode 0 one, eg: sprite ; mode 0 sprite definition dc.w $0100,$ ;form, time/adaption dc.w $0006,$0009 ;x size, y size dc.w $,$ ;x origin, y origin dc.l pattern-* ;pointer to colour pattern dc.l mask-* ;pointer to pattern mask dc.l spr_hi-* ;pointer to next definition ... ... spr_hi ; mode 64 sprite definition dc.w $0240,$0020 ;form, time/adaption dc.w $0010,$0010,0,0 ; etc dc.l blank_col-* dc.l blank_mask-* dc.l 0,0,0 Wman2 then takes over and displays the correct hi definition sprite when machine is in the right mode. None of the other keywords appear to be affected by this (eg MAWDRAW SPRW). Another problem I experienced was with the MCALLT keyword. The pointer sprite noticably blinks each time the call times out. I find this irritating, and therefore cannot use it for something like popup help, which would timeout every 1 to 5 seconds. This does not appear to happen with the equivalent Qptr call, so it must be an MCALLT issue (please check for yourselves). All the above relate to ptrmenX_cde V 3.05 E Is any progress being made in updating the EasyPtr package? Per
Re: [ql-users] EasyPtr revisited
I wrote: All the above relate to ptrmenX_cde V 3.05 E Sorry, a tpyo: Should be V3.50 E BTW, all I wrote about MAWITEM also occurs with MITEM (and possibly MINOB): You need to define a QL mode sprite first and attach the hicolor sprite to that, or else EasyPtr wont want to know. A skeleton sprite definition will do (provided your program will never run in QL colour mode.) Per
Re: [ql-users] Birthday QL 2004
Geoff Wicks writes: Indeed the response has been disappointing. Just 4 replies to a possible Eindhoven event, and 3 of those were business replies on specific matters. Apologies for my lack of response. Shows and all that is not my thing, but I recognise that they are important for the totality of the scene, and every now and again I enjoy attending one. I shall certainly try to attend a QL 2004. I believe some people have mentioned a lack of workshops and talks as things they miss about shows in recent years. The problem may partially have to do with too great a spread of interests over too few people. How about a panel of Wise (Wo)Men to answer specific questions from the audience? That way we could have a number of short talks (eg 2 to 15 minutes each) on a varitey of special interest questions. Per
Re: [ql-users] Birthday QL 2004
Jon writes: As I said in the QL-Today poll I will do my absolute best to get to either or evenboth events whether in UK or NL. Would an Internet connection workshop be of interest? I'm thinking in terms of Bring along your QL get it fitted with Hermes, Help with registering with an ISP, setting up an email account, etc. Install and try-out the soQL TCP/IP stack Aim of the workshop would be that none connected QLers could go home with the know-how, hardware and software to participate on ql-users. Any comments? Sounds like the right kind of idea. But there may not be that many QLers who are not yet connected (by some means). And how are those going to find out about the show ? Per
Re: [ql-users] WM.RPTRT again
George Gwilt writes: 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. Sorry I wasnt more helpful but Ive been extermely busy being lazy this Christmas. Glad you resolved it. 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
[ql-users] wman
Hi all, hope you had a good break! (As did I ;) Now to business: I want to update a couple of my PE programs to the new wman standard. The first obstacle I encountered was sprites/icons. What a bummer to have to design those bloomin things - as if writing programs wasnt enough! Thanks to Wolfgang, Marcel, Jerome and probably others, we at least have some tools to create and convert them. Thats a good start! I dont particularly want to nick sprites from Windoze as Id prefer to keep the QL-side as unpolluted as possible, so I suppose I'll have to do my own. Id like to take this opportunity to apologise for what they might look like in advance! If, however, anyone was twiddling his thumbs wondering how to become a QL saint, he could do worse than design a PD sprite/icon collection... Finally, I think it would be a great idea if some more standard sprites could be included with the system. At present the system sprites consist of: 0 = default pointer 1 = padlock 2 = mode 4(?) 3 = mode 8 4 = K - keyboard 5 = No entry/busy 6 = move selected 7 = resize selected 8 = move 9 = resize 10 = sleep 11 = wake 12 = F1 ... 23 = F12 24 = CF1 ... 35 = CF12 36 = cursor block? 37 = ? How about the following additional standard system sprites: wake icon, help icon, quit/close window icon, escape/back icon, precision pointer (cross), resize right/left pointer(s), resize up/down pointer(s), resize diagonal forward pointer, resize diagonal backward pointer, move pointer (arrows pointing NESW), hand pointer (or link select), standard block cursor (animated) pointer, text select pointer, help pointer...? The current scheme allows for up to 256 system sprites in each display mode, so perhaps the sprites could be provided in two different sizes, large and small. Alternatively, two different schemes could be provided, eg normal and hi-contrast... Just a thought... Per
Re: [ql-users] SMSQ/E Version 3.04
John Sadler writes: On the demo SMSQ/E gold ALT enter does not give you the last command. Is this an error or has this useful facilty been removed? If so a history facilty would be better. The default keystrokes have (by mistake, I think) been set to ALT+s and ALT+S. For some reason this does not automatically get updated to your preference when using MenuConfig/Update; you have to do it manually. Per
Re: [ql-users] isp
Tony Firshman writes: With all this moving of accounts, I am amazed that more don't buy a domain (£1.99 a year from oneandone.co.uk - beware the £1.99 a MONTH offer). Can you use a domain via a dial-up connection? Having your own domain doesnt solve the dail-up problem. You still need an ISP, yes? Can anyone recommend a reliable Pay-As-You-Go ISP? Per
Re: [ql-users] isp
TonyTebby writes: You're lucky. When Tiscali took over my beautiful knoware.nl ISP I had similar experiences to the ones you describe but I put it down to them being mean rather than crooked. What a wunch of bankers! I think its time to get outta here! Per
Re: [ql-users] isp
John Hitchcock writes: Why not the ubiquitous TISCALI ? I've set up many for different users. My personal experience with Tiscali.co.uk is that you get swamped with spam, the negotiation time with the host computer (both logging in and logging out) takes longer than with freeserve (thus clocking up extra revenue for Tiscali at your expense), that sometimes you are not allowed to log on to your email account via another ISP (thus forcing you to use Tiscali to get your Tiscali mail), and finally, that they dont permit your sending mail on another ISP account than your Tiscali account while connected via them. Freeserve offers an altogether cheaper and more reliable service. I was able to set up a freeserve account a year or two ago without using their CD which, however, is widely available from Dixons, PC World, etc, and on computer magazine cover disks. Id be happy to be recommended another ISP myself. Preferably something with a memorable name so its easy to give to people verbally. For example pj at witte dot fsbusiness dot co dot uk doesnt exactly roll off the tounge, while pjwitte at tiscali dot co dot uk is very convenient; the only positive point about tiscali ISP. Per
Re: [ql-users] Sbasic and slicing
I wrote: get1string ;SB string on stack. a1-string move.w 0(a6,a1.l),d0;get len lea.l 2(a1,d0.w),a0;a0 - end string That last line above should of course have read: lea.l 1(a1,d0.w),a0;a0 - last char Per
Re: [ql-users] Sbasic and slicing
Phoebus R. Dokos writes: I always thought that slices could work in reverse as well (and they should actually) so eg. a$ = hi b$ = a$ (2 TO 1) PRINT b$ should return ih but maybe it's just me :-) Phoebus Patience my boy! Marcel The Miracle Maker will crack this one eventually! Hehe that or crack our head for making these suggestions ;-) Seriously though that would be a great improvement as it would eliminate the need for a reverse function (Geoff would love that one as well I'd imagine) It's rather annoying to have to resort to LEN(String$)-1 iterations to solve this :-) It would be trivial to write your own m/c routine to do the job! Off the top of my head, something along the lines of get1string ;SB string on stack. a1-string move.w 0(a6,a1.l),d0;get len lea.l 2(a1,d0.w),a0;a0 - end string lsr.w #1,d0;only need to swap half the string bra.s loop_end ;dont bother if 1 char or less loop move.b 2(a6,a1.l),d1 ;swap chars move.b 0(a6,a0.l),2(a6,a1.l) move.b d1,0(a6,a0.l) subq.l #1,a0;next pair addq.l #1,a1 loop_end dbra d0,loop returnstring;reset a1 and return string to SB should work. Per
Re: [ql-users] Sbasic and slicing
François Van Emelen writes: Hi all, Could someone explain me this? P1 100 a$=SMSQE 110 b$=a$(4 to 3) 120 print b$,len(b$) Line 120 prints an empty string with length 0. P2 100 a$=SMSQE 110 b$=a$(4 to 2) 120 print b$,len(b$) Line 120 returns the error 'unacceptable array index list' Question: Why doesn't P1 return the same error as P2? Any ideas? Because len(a$(4 to 4)) = 1, len(a$(4 to 3)) = 0 - still an acceptable string, but len(a$(4 to 2)) = -1, is not It probably saves time not to have to test for these odd cases, and it returns the right answer, in my opinion. Per
Re: [ql-users] Byfleet workshop
Dilwyn Jones writes: I also added a few new and updated pictures to the QL Rogues page: Oughtnt you to feature prominently on the page yourself, Dilwyn, rather than skulking in some godforsaken corner of your web. I mean, whats the point of calling it QL *Rogues* Gallery without you? Per
Re: [ql-users] wm.rptrt
Wolfgang writes: I feared, but was hoping I wouldnt have to, go there having to fiddle around to do it manually. Thank you for your code ;) I think this is just what Im looking for. I shall test it as soon as I can. OK let me know if it breaks. (...) By DOing the liberated button, I want it to jump back into the BF, but whatever the x-coordinate I provide, wm.prpos positions the button wherever it thinks fit. Eg, if the free button was at (0,100) wm.prpos puts it in the correct place at the end of the row of buttons at the top of the screen, eg (764,0), exactly as specified. However, if the free button was at the other screen edge, eg (972,50), wm.prpos puts it at (0,0)! If the free button was anywhere in between, wm.prpos puts it in some intermediate position (xxx,0). Surely this must be an issue? BTW, this behaviour is the same whether QPC is running in HiColor or QLColor mode ? This something I'm unable to reproduce. init (open con, wm.setup etc) wm.prpos wm.wdraw loop wm.rptrt if HIT then release BF and interactively move elseif DO then get coordinates from BF Thing and wm.prpos endif endloop As you see from this (partial and oversimplified) representation, I dont wm.rset or anything like that, just re-call wm.prpos. This may not be how wm.prpos is designed to operate.. Anyway, the BF doesn't place anything anywhere, it is your code that does so. The second code example I've sent you should tell you how to position your wdw again where you want it. Yes, Im aware of that, hence my need to use wm.prpos. Just as a recap, let me remind you how the PE positions (primary) windows. If you tell it to position a window at coords x,y, it puts the POINTER at x,y. Then it draws the wdw around the pointer in such a way that the pointer, being at coords x,y, will be located within the window at the coords x2,y2 (relative to the wdw origin), the coords x2,y2 being the coords given in ww_xorg in the working definition (!!!). In other words, when positioning primary wdws, ww_xorg and ww_yorg contain not the window position, but the initial pointer position of the pointer within the window. This explains why the buttons overlap initially. My WD's default pointer position was set to (0,0), but this is inside the border. I'm sorry if the above sounded pedantic and only told you things you already knew! Its always difficult to know what others know. Its years since I last did any serious PE programming in assembler, so Im starting again almost from scratch. And I thought doing just a simple little button affair would allow me to get acquainted with some of the new facilities in a controlled, overseeable environment! Ha! Thanks for your help. I hope to get it all sorted out this weekend. Per
Re: [ql-users] wm.rptrt
Wolfgang writes: How do I position a PE window accurately? Does the software have to be able to run on a machine that may NOT have the menu extensions installed? If not I suggest you use the menu extensions to set up your button. (I could help you there) I hadnt thought of that, (I dont yet have the new Qmenu). But Id still prefer to know how to do it myself ;) if not, I've dug up some old code I hd used previously for a button with a standard border I feared, but was hoping I wouldnt have to, go there Thank you for your code ;) I think this is just what Im looking for. I shall test it as soon as I can. In certain circumstances, I want to be able to liberate the button from the Button Frame and then, after doing whatever to it, put it back again (automatically, ie not using wm.chwin). wm.prpos makes it jump all over the place! I'm not sure I understand your problem - what jumps all over the palce? I presume it is not the button, but your normal wdw. By DOing the liberated button, I want it to jump back into the BF, but whatever the x-coordinate I provide, wm.prpos positions the button wherever it thinks fit. Eg, if the free button was at (0,100) wm.prpos puts it in the correct place at the end of the row of buttons at the top of the screen, eg (764,0), exactly as specified. However, if the free button was at the other screen edge, eg (972,50), wm.prpos puts it at (0,0)! If the free button was anywhere in between, wm.prpos puts it in some intermediate position (xxx,0). Surely this must be an issue? BTW, this behaviour is the same whether QPC is running in HiColor or QLColor mode If that is so, here is the code I use for that in some of my programs: Thanks a lot for the code! I'll see if I can make it work for me. Per
Re: [ql-users] wm.rptrt
Wolfgang Lenerz writes: What are the call and return parameters (all of them) for wm.rptrt again? Here are the notes I have on that - Vector $78 WM.RPTRT How do I know Ive timed out?cmpi.w #-1,d0? from basic: if event% = 0 timeout% can't be -1, must be -1, solution: pass event% as 1 (this is ignored anyway) Does this apply to wm.rptrt too? Thanks for your help. Per
Re: [ql-users] wm.rptrt
John Gilpin writes: I have just checked in the Quanta library and the latest I can find is Qmac V1.06 and Qlink V1.03 Thanks for checking. Per
Re: [ql-users] Launchpad
Dilwyn Jones writes: I noticed some reference in the documentation to an EasyPtr keyword called MCALLT. Is this a new keyword implementing wm.rptrt? Where can I get it? This is new in version 3.50 of the Easyptr extensions (I got Easyptr upgraded from Roy Wood), only documented in the updates file, as follows: Thanks for the info, Dilwyn, and good luck with Launchpad! - A major opus from the house of DJC. Check it out! I believe I bought my EasyPtr direct from Albin himself. Since hes no longer in business, would someone else (Roy, perhaps?) be prepared to update me? Per
[ql-users] wm.rptrt
Hi all, What a shock to get back from a 10-day absence to discover nearly 200 ql-user mails in my inbox! My first thought was that something major had happened, eg large chunks of Smsq/e source code had been discovered at the heart of Windows and here was Bill Gates frantically trying to defend himself on this list. But alas! it was only the same old licensing issue again. Rattles and cut-off noses all over the place, as was to be expected. But this time, did I detect the first overtures of a rapprochement? If so, I hope the protagonists are willing to pursue this one as its importance to the community cannot be overstated. In the mean time, the show goes on, and Im stuck for some info. What are the call and return parameters (all of them) for wm.rptrt again? Also, can others confirm that the DATA directive in Qmac 1.06 doesnt work? If so, can this be fixed? Is 1.06 the current version? TIA Per
Re: [ql-users] Launchpad
Dilwyn Jones writes: Just had a quick peek at the demo. Its not hard to detect that you have been very busy indeed. You must have worn at least 5mm off you fingertips! I noticed some reference in the documentation to an EasyPtr keyword called MCALLT. Is this a new keyword implementing wm.rptrt? Where can I get it? Per
Re: [ql-users] Re:smsqe 3.03 - sources are out
Wolfgang writes: The sources for smsqe 3.03 are now officially out. (smsqe 3.03 itself is avaialble from your usual reseller). I have enclosed, as an attachment, some small text files, they tell you what is new in this version. I shall be sending the sources out on monday to those who have recently requested them from me. How very exciting! An enormous amount of work seems to have gone into this. Thanks to all you hard-working contributers. Where would we be without you? Please include me on your mailing list, Wolfgang. (A blank disk and postage will be dispatched this weekend.) Per
Re: [ql-users] RFC
Marcel Kilgus writes: P Witte wrote: In some older programs I use a different scheme, with F10 stuffing the edited string into the stuffer buffer. Oh well, so you're already doing exactly the same. Those, and any other existing programs that do something similar, will find that they get two copies of the keyboard queue contents. The first copy would hold what iob.edlin thinks is the resultant string (accessed by Alt+Shift+Space or equivalent) while the second would hold what your program knows to be the correct version. Disconcerting, messy and quite unnecessary, methinks. This I don't really understand. Either you use iob.edlin, in this case F10 was useless in the past and now could be filled with some life. Or you don't use iob.edlin, then the change doesn't really concern you. Youre right. I got confused. It shouldnt affect my line editor as I use iob.fbyt not iob.elin or iob.flin. As an aside, iob.elin is/was incompatible with the documentation: it doesnt update the cursor position on return, so it was of no use to me. I asked TT whether hed fix it but in the end he didnt as he feared it would introduce incompatibilities with existing programs. I still think the key should be configurable. Per
Re: [ql-users] QL Hot-removable Compact Flash Adapters - ONE LEFT!!
Darren Branagh writes: I still have ONE hot-removable compact flash adapter left!! This is definitely the last one - first come, first served. And when he runs out, Im floging one surplus-to-requirements Hot removable CF adapter including brackets and cover to insert into a 5 1/4 drive bay. I say Hot removable as it didnt work for me with Windows 2000. You have to have the flash card in at boot-up for it to work. The same applies to my Q60, but that was understood when I bought it. Per
Re: [ql-users] RFC
Marcel Kilgus writes: I already use this keystroke in a number of my programs for the purpose (F5 in Qwirc, FF and others, and F10 in older programs) so in my case Id want to override, disable or avoid this facility in individual programs. Why? It wouldn't change the behaviour of your program at all. It would just add the additional feature of reacting to F10 within a read-line trap (instead of doing nothing at all). Just trying to be controversial in these quiete times ;) There are however some good reasons. A number of my programs (and probably other people's too) have their own line editor using editing keystrokes that are not understood by the edlin trap. In FF and Qwirc, for example, I use F5 to stuff the resulting string into the global stuffer buffer and F10 to stuff it into a local buffer. This is so you have a CHOICE: A frequently used file name might be held in the global stuffer buffer while intermediate or more dynamic data can be held in the local buffer. In some older programs I use a different scheme, with F10 stuffing the edited string into the stuffer buffer. Those, and any other existing programs that do something similar, will find that they get two copies of the keyboard queue contents. The first copy would hold what iob.edlin thinks is the resultant string (accessed by Alt+Shift+Space or equivalent) while the second would hold what your program knows to be the correct version. Disconcerting, messy and quite unnecessary, methinks. Per
Re: [ql-users] RFC
Wolfgang writes: Per : I think it is a good idea. Great that you are prepared to do it! Might it be an idea to add some kind of test for this functionality (eg set a bit on some sysvar), as application programmers may wish to eg provide a limited functionality on systems that dont support it. Do you mean that the application programmer will build this facility into his program (via some special keystroke or menu item?) so that , for example, in QDOS this can also be achieved? Well, then it would simply be possible to achive it with 2 different methods on an SMSQ/E system. I already use this keystroke in a number of my programs for the purpose (F5 in Qwirc, FF and others, and F10 in older programs) so in my case Id want to override, disable or avoid this facility in individual programs. (remember, as Marcel rightly points out, the keystroke is trapped anyway, the application doesn't even get it) CTRL-C is, of course, out of the question, as that is used elsewhere. Couldnt this also be an Smsq/e configurable item (Im aware that it is easy enough to do as a POKE, but..) together with the Hotstuff keys, F10, and anything else that may crop up? Per Yes, it could be. Personally, I'm not so sure that it is really such a good idea, I like the idea of systemwide unified keystrokes. Everybody knows not to use CTRL-C in one's applications because it is a fixed system wide keystroke. Same for CTRL F5 for screen freeze, or Alt Enter etc Some of these may be changeable via POKEs in the sysvars, but in general, they are fairly constant over all systems. We could of course all walk round in Mao-suits then no one would be embarrassed for mis-dressing at dinner parties. ;) People use different platforms, have different keyboards, different disabilities, different needs.. Choice is not always a luxury. For the new keystroke I'll probably foresee some kind of configuration item, since I realistically can't really know that it will work in all circumstances at all times Actually Ctrl+c seems a good (optional) choice to copy the keyboard queue , as this avoids confusion when working with QPC under Windoze. Its a convenient keystroke as its easy to remember and can be accessed with one hand (by people with two or more fingers). As someone said, PE users hardly need to use Ctrl+c to change queue anymore. It is virtually redundant. Might as well make it configurable so it can be used for something else. If the application programmer can find out what keys the system is configured to use then a program can use (or avoid) these keys, ie forget the suggestion of setting a bit: Set the complete keycode somewhere in sysvars - as for Change Queue. Per
Re: [ql-users] RFC
Wolfgang writes: I'm toying with the idea of implementing, withing SMSQ/E, some sort of general keystroke which will put the content of a con channel into the stuffer buffer (similar to CTRL-C on Windows) when using the edit/input string OS call (eg. INPUT inSbasic).. Thus, all software which uses the normal edit string OS call would profit from that. You can get the string back with the ususal ALT-ENTER. Are you thinking of buffering output sent to each scr/con channel, or are you thinking of using OCR, as in Qlip, or something else? The key so used will be effectively unusable for the application whenever it makes this OS call (but not for anything else). Marcel proposed the F10 key for that, as the ED command in SBasic already uses that for the same purpose and, as he rightly points out, this OS call already screen out the function keys and such. Does anybody have some strong feeling about this (or even just an idea?). I think it is a good idea. Great that you are prepared to do it! Might it be an idea to add some kind of test for this functionality (eg set a bit on some sysvar), as application programmers may wish to eg provide a limited functionality on systems that dont support it. CTRL-C is, of course, out of the question, as that is used elsewhere. Couldnt this also be an Smsq/e configurable item (Im aware that it is easy enough to do as a POKE, but..) together with the Hotstuff keys, F10, and anything else that may crop up? Per
Re: [ql-users] sernet
George 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.) Hehe. Actually, after messing with sernet for three days (at least in this latest (and last!) desperate attempt), I did what I should have done from the start: copied the main stuff onto some 160 floppies and moved it over. After that it wasnt so difficult to keep it up to date. Per
Re: [ql-users] sernet
Phoebus R. Dokos writes: It's a matter of cabling actually usually. However as Jochen said in that Sernet Special on QLT and I quote: It DOES work I have been using SERNET with: QPC to Aurora, QPC to Q40, Q40 to Aurora even QemuLator to Aurora and QXL... If you are using QDOS Classic however it WILL NOT work. You need the H.P.R's SimSer to emulate SMSQ/E's ports. There are just too many variables: sernet version, cables, OSes, ports, hardware, etc, plus virtually no feedback except some general error message after every 5 minute hogging of your machines. Either you have the luck of the Devil or your fortitude deserves a citation. For the rest of us: Its just not worth the pain. Forget it! Per
Re: [ql-users] sernet
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
Re: [ql-users] Whats up?
Jerome Grimbert writes: You got the wrong end of the stick, Jerome. I believe Darren was talking about WINDOWS, the Woefully Idiotic Nasty Destructive and Obnoxious Wrecking System that is commonly found on computers sporting the much-loathed Intel (Intuitively Non-programmable Topsy-turvy-Endian Logic-defying) chip. Since WINDOWS is an acronym, the final S is not indicative of plurality, therefore it is correct to say Windows IS.., although the subsequent sentiments expressed by Darren must be considered to be erronous or mischieveous. I HTH, Per [EMAIL PROTECTED] makes some magical things to make me read } } I think its time to start a riot then - } } Aren't QL's rubbish?? Windows is much better. Windows ? What's the relation between computer and house hardware ? (excepted home-computing of course). QL-compatible are just fine, anyway. And to get the fresh air someone seems to need: Doors are much better! Btw, your grammar is bogus, plural requires are instead of is. Repeat after me: I am, you are, he/she/it is, we are, you are, they are. I was, you were, he/she/it was, we were, you were, they were. I will, you will, he/she/it will, we will, you will, they will. I have been, you have been, he/she/it has been, we have been, you have been, they have been I had been, you had been, he/she/it had been, we had been, you had been, they had been ...
[ql-users] Whats up?
Is anybody body out there out there out there?
Re: [ql-users] Dual IDE controller needed for Q40 - Will Exchange :-)
Phoebus R. Dokos writes: I want me too one of this 4 IDE card for my Q60, I have already one in my Q40 that work very well (2xHD,1xCDRW,1x CF reader). On the other side I bought a new one controller like this, some time ago, by myself from a computer shop but it did not work, I think (if I remeber well from an old e-mail from Peter) that not all this kind of controller works when installed in a Qx0. Another possible solution is a 3 slot ISA riser card, i found this site in Canada http://www.barada.ca/eng/index.htm and the BBP3R could be an example to allow to mount 2 controller plus the ethernet. BTW I am available to spend 40 $ for the card if proved working with Q60. Ciao Fabrizio Hi Fabrizio, I will be willing to try them first and maybe get all of them for you and ship them to Europe if they work. I will be calling the vendor tomorrow to verify possibility of conditional purchase (if it works fine and we buy a couple more, if it doesn't we return) You interested? Id also be interested, provided it works properly, as life is too short to mess with hardware.. Per
Re: [ql-users] Testing new email - please ignore
Norman Dunbar writes: It's only me - getting sorted aout at home. Your dysqwertya is getting worse, Norman. Per
[ql-users] an [OT] favour
I urgently need to install the latest service pack on my W2k machines! However, it is a 120+Mb download! and I dont have broadband. Would any of you like to contact me about downloading this file onto a CD and sending it to me for a fiver or so? SOO unpatriotic and off-topic, I know, but I dont know of any other option. Per PS Contact me privately first - I only need one. And please dont email this file to me or dump it on the list! ;) P
Re: [ql-users] an [OT] favour
To my I urgently need to install the latest service pack on my W2k machines! Thanks to all who responded. I am now sorted! Per
Re: [ql-users] an [OT] favour
Roy wood writes: Sorry to continue an OT discussion here but you are wrong. You can go to the Microsoft site and download the SP4. The pack you need to download is the one for network users. This is because people with multiple machine do not want to connect them individually to do the updates. You are exactly right. Another reason I like to have the whole thing on a CD is that I regularly have to re-install Windoze from scratch to keep it ticking over nicely. This is a pain, but well worth it. Qdos/Smsq never needs to be installed, thats one of the beauties of that system. BTW Has anyone tried HyperOs? Theyve run a 16 page ad in Computer Shopper every month for the past 6(?) months. I ask for two reasons, one is that it appears to promise that I wont have to keep doing these re-installations as you can simply clone a pristine installation, use it until it screws itself silly in the normal Windoze fashion, and then just clone a new, pristine one in a couple of seconds. The other reason is that the ad campaign reminds me suspiciously of ol' Freddy Vaccha's approach to advertising. Does anyone know whether he has a hand in it? Its either Freddy or a very close relative. Id be prepared to bet a penny on it! Per
Re: [ql-users] Crash help
Per Witte writes: After having downloaded the latest batch of mails from this list the mighty Windoze 2000 silently hung on me. Could someone kindly do me the favour of forwarding the last few mails to me, ie everything that arrived between 05/08/2003 23:34 and this mail. (I dont mind if I receive 200+ copies, as long as I get one. I'll let you know when to stop ;) TIA Thanks, I got it. Per
[ql-users] Crash help
After having downloaded the latest batch of mails from this list the mighty Windoze 2000 silently hung on me. Could someone kindly do me the favour of forwarding the last few mails to me, ie everything that arrived between 05/08/2003 23:34 and this mail. (I dont mind if I receive 200+ copies, as long as I get one. I'll let you know when to stop ;) TIA Per
Re: [ql-users] Machine Code Extension
- Original Message - From: Thierry Godefroy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 11, 2003 12:33 AM Subject: Re: [ql-users] Machine Code Extension On Sat, 9 Aug 2003 06:20:20 EDT, [EMAIL PROTECTED] wrote: Hmm - one of my old machine code extensions reports an error on QL2K (oddly enough, it reports Channel Not Open when I use d$=SAV_DEV$). Possibly an RI stack problem in another (nearby) keyword is causing this. * Def SB extensions Lab1000A dc.w 0 dc.w 0 dc.w 2 dc.w lab1001e-* dc.b 8 dc.b 'SAV_DEV$' dc.b 0 dc.w 0 * End SB ext That last 'dc.b 0' should be removed, although it will not make a difference here given their is no more function name after that one and that the following bytes are 0 as well... The number of bytes in the name table must be kept even: as SAV_DEV$ counts 8 bytes, you don't need for a padding null byte. The padding byte needs to be there: Nametable name strings all have byte sized length counters. The code seems correct although far than optimized. I'd propose: Lab1001Emoveq #0,d5 Clear MS word. lea Lab10076,a4Name string address move.w(a2)+,d5 Name length addq.l#3,d5 | Take length word into account bclr #0,d5 | and round up to word boundary or moveq #3,d5 lea.l Lab10076,a4 add.w (a4),d5wont overflow in this context bclr #0,d5 move.ld5,d1 Number of bytes to reserve movea.l $58(a6),a1 Arithmetic stack address. movea.w $011a,a0 QA.RESRI jsr (a0) Reserve the space on the stack movea.l $58(a6),a1 New stack address suba.ld5,a1 Make space for the string move.la1,$58(a6) Store the new top of stack or jsr (a0) sub.l d5,$58(a6) move.l $58(a6),a1 movea.l a1,a2 Copy of stack pointer lsr.l #1,d5 | Number of words to transfer or lsr.l #1,d5 loop move.w (a4)+,0(a6,a2.l) first move is length word addq.l #2,a2 dbra d5,loopmin once through loop subq.l#1,d5 | Lab1005Amove.w(a4)+,0(a6,a2.l) Transfer a word. addq.l#2,a2 Increment stack pointer dbf d5,Lab1005AContinue until end of name. moveq #1,d4 Parameter on stack = string moveq #0,d0 No error rts retuns... Lab1006Edc.b 'QDRV' Lab10076dc.w 13 dc.b 'win2_NEMESIS_' Lab10086ds.b 35 The above is tested and working. Per
[ql-users] Bugs
Ive recently discovered the following bugs in Smsq/e PRINT PRT_USE$ crashes Smsq/e since at least version 2.98 on QPC2 (and QPC2 itself). PARTYP, PARUSE, PARNAM$, and PARSTR$ dont work on Smsq/e 3.00 and 3.01. Ok on 2.93 and 2.98 Can anyone confirm? (Save your work first!) Is there somewhere to report bugs in Smsq/e? Preferably it should be somewhere where they can also be looked up by others who are experiencing problems or who are out looking for something to fix.. Per
[ql-users] Issues raised by Geoff Wicks
Geoff Wicks writes: As promised, some detailed reasons. It is a long piece, about 1,700 words, so I have done it as an attachment. It is in four sections, which can each be read separately. One of the sections is positive. While I sympathise with your struggles I find your conclusion, ie to walk away, rather strange. First of all, I have never really noticed your struggles; this is the first I conciously hear of them. Im sorry about that as I may somehow have found a way to avoid being another straw on the camel's back. As you may have detected, I have been prepared to make a fuss over those issues that have come to my notice, especially the tendency in this group to generate virtually no feedback, often even in cases of direct one-to-one communication (which bears more of a likeness to rudeness than mere lethargy). Secondly, the timing seems particularly ill-chosen as, despite all problems, so much is going on just now, a lot of it with no other apparent justification than as a gambit to generate more interest in developing software and keeping the whole caboodle afloat. Finally, I want to say that although our ways have never really crossed, I am a user of some of your software (about four commercial titles, I believe) I read your letters and articles, and basically agree with most of what you say, or at least dont disagree enough to contradict you, which is why youve never had any feedback from me ;) (Not that it matters much, but at least you now know of one more person who appreciates your contributions, which you perhaps didnt know about before.) Let me candidly declare my interests, so that no-one can suspect me of being an insider with a priviliged stake in this whole business. I am not a regular attendee at events (though I really feel I ought to try harder). I dont know any of the Great and Good in the QL community. I am not a professional programmer, nor do I sell or trade in QL software. I am merely a ql-user who has invested hundreds, or even thousands, of pounds over the years in hardware and software, not to mention the hundreds (or thousands) of hours I have spent writing programs - mainly for my own use or amusement. I regularly use Windoze, mainly for those things for which there presently is no QL equivalent, and I have muddled through with Linux when necessity has compelled. I use the QL (mainly QPC) out of choice, both for business and privately. The reason I stick my neck out at all is to safeguard and maintain my investment. That is not to say that I dont consider many of the people I have met over the years, on-line and in the flesh, as freinds. Of course, I dont mean to imply that I expect you (Geoff) or anyone else, to have to fork out a small fortune for the privilige of supporting my interest. I do think it unfair that some people carry a disproportionate cost in time and/or money to keep the whole thing going. I think ways should be considered to distribute this load more fairly. But how? The benefit of committing hari-kiri on-line, as opposed to the real thing, is of course that you can review, and possibly even reverse the act in the light of the subsequent obituaries. I sincerely hope you will take the opportunity to reconsider. I have many a time tottered on the very cusp of doing the same, and perhaps only the fact that I did not have an exposure £100 per anum to gain from it, restrained me from pushing that final send button. Now that you have brought your concerns into the open, and there have been responses that indicate that these concerns are shared by others too, lets get to the bottom of this and try and find the causes and some constructive solutions. Per
Re: [ql-users] Quanta workshop support
John G writes: I have noticed the comments regarding a QUANTA 2000 type event but all the contributions are coming from the expected sources. (Thanks Dilwyn J, Darren B, Geoff W and John T). What about the rest of you? come on. Put your ten penn'orth in. (Should that be Dimesworth in USA or Centsworth in Europe?) Let's here from you ALL. It would be highly unusual to hear from ALL of us on any topic. 2-5% of the subscriber mass is about as close as youll get, and possibly represents the full spectre of opinion. Im all for all of Dilwyn's ideas on the subject. We even have venues other than Scout Huts in Manchester and also such a lot to see in the surrounding areas (for those not QL minded). We have Motorways (Full of congestion), International Airports (BA Check-in staff permitting!), Ports with easy access on both sides of the country and The City of Culture 2008 is only 35 miles away. As to venue I dont have a preference as I know a lot of people are going to have to travel far to get there wherever its going to be. Not being a very sociable type myself, I might find it attractive if the venue could be available 24 hours and near, or combined with, the place of repose, so that those who prefer computing to eating/sleeping could get on with it at any unsociable hour they saw fit. (Perhaps some extra shaver sockets could be laid on?) There. - QUANTA have thrown down the gauntlet so what's the challenge? Let's start a list of celebrities to invite. Let's bring everyone up to date on the latest and best in the QL world (or QL Today - to keep certain members happy!) Keep the comments coming - yes we realise that this needs attention NOW. Still no update on Roy's most practical offer (I don't even know which Roy we are talking about) Add your thoughts about what is to happen to the QL and Quanta in the future. What is the way forward? Who is out there with something interesting and/or informative to say in the form of a tutorial or lecture and what do we want to learn about? Some talks on more advanced aspects of Qdos/Smsq might make a nice change: GD2, Wman2, PE, Things, etc, ie beyond the basics that are available in the various tutorials. Anything that will promote the development of good software by the sort of people who develop software for the QL, ie amateurs, or programmers/computerati that work professionally in other environments. This may also be interesting for lapsed QL professionals. By all means lay on the How to improve your chances of promotion using Quill and Cataloguing your vintage whisky collection with Archive if there is a demand, just dont forget the rest of us. Per
Re: [ql-users] Dynamic arrays?
Wolfgang Lenerz writes: As an example, I have at least two assembler toolkits of a total of 17000 bytes (compiled) - I don't really know how many assembler lines that makes. At least some fo the commands se vector $120 - this is an easy way of returning several values tro Sbasic by one command. Perhaps it would be easier to amend SMSQ/E in such a way that, for Turbo programs, some special form of vector $120 is used. I've submited this idea to George - let's see what he thinks of the feasbility of htis. This would lift THE major obstacle to using Turbo (for me, at least!) ..plus array slicing, of course Per
Re: [ql-users] QPC2 v3.11 SMSQE v3.01
Marcel writes: Announcement =-=-=-=-=-=- Ive been playing around with the new QPC and Smsq/e for a couple of days now, and I must say that Im very impressed! Marcel, Wolfgang and others have done a splendid job. Bravo! guys, and many thanks! I find it a bit sad that one of the biggest things to have hit the QL world in recent times has barely caused a ripple on this list. Lets assure these guys that they made the right choice in poring over their overheated computers in darkend rooms for the benefit of their friends and fellow nerds, instead of taking up fishing in the healthy fresh outdoors, or pursuing wealth and glory in the material world! I very much hope that we shall see some great new software that takes full advantage of all the new treats weve now got! The problem is that there are virtually no tools to make a programmer or user's life easier. We need tools to help creating styles, to pick colours, to design sprites and menus, and so on. Its going to be very difficult for casual programmers, such as me, to produce new stuff or upgrade old stuff if we have to do all the hard work by hand. I dont enjoy creating user-interfaces in a text editor! There are some promising beginnings, as was pointed out in a recent QL Toady. But it could take a very long time before some of these products become generally useful to the average punter. If the same level of collaboration could be achieved in developing or improving some of these tools, as was the case with Smsq/e, we might really get somewhere. This requires that programmers make clear what kind of help they need, and that people take them up on it. Things like the translation of manuals, reviews-cum-tutorials, sprites, add-ons, help, collaboration over standards, etc could all be useful. For those that feel they dont have anything to contribute, how about at the very least registering the use of a product with the author, or making your interest and appreciation clear, or even sending a donation, where this is wanted? C'mon guys! Weve all got things to do! Per
Re: [ql-users] Is there a right way to detect if TK2 is installed.
Jimmy MONTESINOS writes: I'm searching what is the right way to detect if TK2 is installed on a QL system. I need to make the difference between a TK2 loaded from ROM cartridge or LRESPR command too. If anyone know the superbasic code to check this out... I dont know if there is an official way, or how secure this method is (but no doubt you will hear the howls of disapproval if Im wrong ;) but you could try something along these lines: First check if a TK2 ROM is plugged in: rom = 49152: rem $C000 if peek_l(rom) = '1257963522' then rem $4AFB0001 is the ROM signature rem You may get a bus error or some other rem hysterics if nothing is plugged in. Dont know rem how the various emulators will react.. rem OK with QL2K plug plugg s$ = for i = 1 to peek_w(rom + 10) s$ = s$ chr$(peek(rom + 11 + i)) endfor i if Care / Qjump Toolkit instr s$ then rem you can assume that TK2 is in ROM else rem Not in ROM, at least rem Check whether TK2 is loaded sv = 163840: rem $28000 sys vars p = peek_l(sv + 172): rem $ac = PROGD if p 0 then rem you can assume that TK2 is RESPRed endif,etc Per
Re: [ql-users] efficient buffer size
Wolfgang writes: A question: A program uses io.fstrg/iob.fmul to load files in smaller chunks for scanning. The files could be of any size on any media (first of all hard disks). What, theoretically, is the smallest efficient buffer size to use? (Im thinking *speed* here.) Eg 512 bytes, as a whole sector can be loaded in at once? Or allocation unit size? Or any arbitrary size that best suits my program? If you're thinking speed, then the larger the buffer, the better - reading the data in small chunks will always cost more time. If at all possible use a buffer for the entire file (scatter) read it in. Yes, that is understood. It is in situations where the whole file cannot be read at once, Im thinking about. (Besides, on a multitasking machine it is probably not very polite to grab huge buffers ;) Sector (512 bytes) sized buffers don't make that much sense IMHO, since the file data doesn't occupy the whole of the first sector (there's the file header), so reading the first 512 bytes from a file will read from 2 separate sectors. This brings us to the heart of the question: What would be a sensible size? First one block of 512-64b and then subsequent blocks of 512 bytes (or multiples thereof)? Per
Re: [ql-users] is minus one = -1?
Darren.Branagh writes: I just spelt 'remember' wrongly TWICE in that email. I'm getting old. My spellings gone down the drain, too (in three languages) I started spelling remeber just like you, so now I keep a lookout for that word (among others) and usually catch it. Old age, you think? Whats next! Incontinence? Floppy dikss? (phew, back OT!) Per
Re: [ql-users] is minus one = -1?
Lau writes: P Witte wrote: While were talking fp, can someone please explain what the purpose of the $81f bias (or whatever the technical term) is? Why not just represent exponents as +/-32k ? Per It's a bit historic, I suspect. It allows all operations on the exponent to be done with unsigned arithmetic, which saves some brain work when implementing the stuff. It gives an easy test for a magic value of zero exponent, which is handy for the special cases. If is were not biased, you would have to use a value like 0x8000, which would become messy. The specific bias varies, but to some extent is one that preserves a balance of mantissa precision for maximum and minimum absolute values. It is generally just one off what you'd expect. Note that, with the IEEE format, operations on both exponent and mantissa are unsigned (as it uses a separate flag to indicate positive/negative value). The QDOS implementation is somewhat of a hybrid, as it uses signed arithmetic for the mantissa. I suspect Sinclair adopted that format to make the code a fraction quicker. By doing so (instead of using the concealed leading bit), you lose one bit of precision (and introduce the invalid representation problems), but you can write shorter, more straightforward software code. The IEEE format is expected to be done by harware, which can happily re-manifest the concealed leading bit of the fly. I'm waffling a bit here... but if QL used a concealed leading one on a 32-bit mantissa, it would have to do 33-bit arithmetic all the time. 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! Thanks for the explanation. (I may have to come back to this ;) Per
Re: [ql-users] is minus one = -1?
Lau writes: P Witte wrote: While were talking fp, can someone please explain what the purpose of the $81f bias (or whatever the technical term) is? Why not just represent exponents as +/-32k ? Per It's a bit historic, I suspect. It allows all operations on the exponent to be done with unsigned arithmetic, which saves some brain work when implementing the stuff. It gives an easy test for a magic value of zero exponent, which is handy for the special cases. If is were not biased, you would have to use a value like 0x8000, which would become messy. The specific bias varies, but to some extent is one that preserves a balance of mantissa precision for maximum and minimum absolute values. It is generally just one off what you'd expect. Note that, with the IEEE format, operations on both exponent and mantissa are unsigned (as it uses a separate flag to indicate positive/negative value). The QDOS implementation is somewhat of a hybrid, as it uses signed arithmetic for the mantissa. I suspect Sinclair adopted that format to make the code a fraction quicker. By doing so (instead of using the concealed leading bit), you lose one bit of precision (and introduce the invalid representation problems), but you can write shorter, more straightforward software code. The IEEE format is expected to be done by harware, which can happily re-manifest the concealed leading bit of the fly. I'm waffling a bit here... but if QL used a concealed leading one on a 32-bit mantissa, it would have to do 33-bit arithmetic all the time. 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! Thanks for the explanation. Per
Re: [ql-users] is minus one = -1?
While were talking fp, can someone please explain what the purpose of the $81f bias (or whatever the technical term) is? Why not just represent exponents as +/-32k ? Per
Re: [ql-users] is minus one = -1?
Robert Newson writes: Does it happen on all negative exact powers of 2, ie: -(2^x) -(2^x) + 0 for x = 0, 1, 2, 3, ... (ie -1, -2, -4, -8, -16, etc)? Youre right. Take the program: for i=0 to 16:print i!-i=(-i+0) The results are: Smsq/e 3.00 Qdos JM/JS/Minerva 1.98 0 1 0 1 1 0 1 1 2 0 2 1 3 1 3 1 4 0 4 1 5 1 5 1 6 1 6 1 7 1 7 1 8 0 8 1 etc Is this a bug? Naa, just a feature... It does mean that unless one takes suitable care, programs will not behave the same on different machines. I'm no fp expert (fp dummy is probably the best description), but is it a normalisation bug (based on -8 failing, but -9 working)? [In my very limited experience of fp I vaguely remember that the mantissa should be normalised so that a one is implied to the left of it, and the exponent is offset - so that zero is recognised by (mantissa =) exponent = 0. Thus, exact powers of 2 should have a zero mantissa - excepting sign bit?] Thats right, so the result of the addition -1+0 does, for some reason not get normalised in Smsq. Per
Re: [ql-users] is minus one = -1?
Marcel Kilgus writes: In internal format, Exponent . Mantissa: -1= $800 . $C000 -1 + 0 = $801 . $8000 which can be a flaming nuisance! You got the mantissas and exponents mixed up, $800 $8000 is -1 and $801 $C000 is -1 but not your two. As Robert wrote this is a Just checking whether everyone was paying attention. You obviously were ;) question of normalisation, however, QDOS FP values don't have the implied 1. he mentions (this is for example found in the IEEE standard, except the 80bit one which is a bit special in this respect). As far as I know normalisation is not required for QDOS FP values. A bit special, eh. Nice pun. Example: Epsilon = 0.1 IF (a - b) Epsilon THEN PRINT They are equal. In SuperBasic I believe this technique is already implied when using the = operator. But you cannot just compare the bytes of the two The S*Basic == (double equals) works in this case. values (e.g. in assembler) because of the different representations a value can have (there's some rounding going on almost every time one uses FP). So that means a hefty re-write of my old assembler float comparison routine ;( And anyone using SNG's diy stuff, based on the same assumptions, is in for a surprise too. I just checked.) Is this a bug? Point of view, I'd say no. The original SMSQ/E routines give the same result for both -1 and -1+0, it's the PC FPU (or the IEEE-QDOS translation) that gives something different on QPC. I could probably do some normalisation, which could solve your problem in THIS case, but other than that... Bug or no bug, it is a compatibility issue, and one that may trash existing programs. Are there any other likely pitfalls? Thanks for your comprehensive reply! Per
[ql-users] is minus one = -1?
A question to my learned friends: In Smsq -1 (-1 + 0) In internal format, Exponent . Mantissa: -1= $800 . $C000 -1 + 0 = $801 . $8000 which can be a flaming nuisance! However, -1 == (-1 + 0) which is some relief! This behaviour appears to apply to all (small?) negative numbers, thus -8 -8 + 0 but -9 = -9 + 0 ! Is this a bug? Per
Re: [ql-users] News
Norman writes: I'm puzzled - why did it become an embarrasment then ? I dont particularly want to advertise the sorry details, if you dont mind ;) It worked for me !! Im happy to hear it. Per
Re: [ql-users] News
Norman writes: Another minor project Ive been working on recently is fixing and updating my asm2htm utility (big yawn, everyone!) No big yawns from me - I thought that it was a great little utility - and then it vanished ! Ah yes. Good old user no. #3 of 4, I seem to recall. To tell you the truth, it became an embarrassment and so was withdrawn for the benfit of the ql-ing public and my own reputation. Personally, I think the output is impressive. Whether anyone apart from me finds it useful is another question. I'll find it useful - when I get time to that is ! Im sure all of us on this list meditate over a few lines of the Smsq sources before bed. This should make it easier. Per
Re: [ql-users] News
Dilwyn writes: I have long been wanting to have some sort of home directory facility in Smsq, ie a way for programs to know which (sub)directory they were executed from, so that they could easily find any associated resource files, eg configuration files, help files, saved settings, and the like, without any further user input or configuration. I totally agree - this is needed. The simplest way to apprach it would be to change the O.S. code to execute files which then places the execute source in a system or environment variable or perhaps in part of the job header code, though this might make the job self-modifying. What I;m getting at is that as the program is executed, the EXEC code (at OS level, not BASIC of course) stores the execution drive/dir name in somewhere where the job can access it, as it would potentially be different for each job of course. The current plan is to reserve additional dataspace when the job is executed and insert the home directory there, at least for normal jobs. Im hoping that this will also work for compiled jobs without any problems. For SBasics I thought of employing a similar scheme to that used by JOB_NAME to store the directory, but I havent investigated this thoroughly yet. In this case the home directory would be that of the last program file loaded, using a copy of PROGD$ as a default. As you see, it could get rather involved if I go the whole hog, and this is why it will take some time. Coming as I do from the kilobyte school of computing Im rather parsimonous regarding memory usage. Since the current plan uses up 44 bytes of overhead for each job (a two-byte marker plus device name plus the max length directory qstring) Ive been trying to figure out a way to conserve memory in cases where no home directory is wanted. One problem here is that I have no control over how compiled executables use their dataspace. Any ideas anyone? Per
Re: [ql-users] News
Dilwyn writes: I usually only put news of my freeware stuff here for fear of being seen as advertising. I dont particularly want to see pure adverts on this list, but I certainly wouldnt mind being informed of updates, changes (to products or services), or new creations, whether commercial or not. I also wouldnt mind information on what a product does in cases where developers or traders feel that they cannot fit this in a normal advert, provided it is balanced, designed to enlighten rather than obfuscate and manipulate, and is not merely an endless reptition of what we have heard before. I think our poor traders are far too reticent here. What do others think? Per
Re: [ql-users] Sbasic and numbers
TonyTebby writes:
No need for fancy modifications - the SBASIC arithmetic routines already
check the types of the variables involved in calculations and do different
operations for integers and floats. All you need to do is detect
string{+-*/}string and do string arithmetic with string result instead of
float. Lau Has a really dinky routine for doing square root in the same
number of operations as divide and other more complex functions can be
left
for later.
A$ = 123456789.01 - 123456789
would give A$ = .01 - IEEE double precision will never give
you that result - it would be quicker, but wrong. Do you want it quick or
right?
The only parameterisation required is setting the maximum precision for
inexact operations (divide, square root, non positive integer powers and
trig)
Good one! The same would presumably apply to any scheme devised to do the
maths, ie you could just as well use IEEE fp, eg
result$ = s.s - s.s
if you see what I mean. In fact you could probably cater for both string
arithmetic and IEEE by, for example, prefixing a marker to the IEEE
numbers.
The only disadvantage with this approach is that it would break a
fundamental compatibility with Qdos. Perhaps that doesnt matter?
Isn't it great being able to think up work for other people to do - I am
enjoying myself!
Welcome to the club!
Per
Re: [ql-users] Sbasic and numbers
Tony Firshman writes: I once had an old mechanical calculating machine, given to me by my grandfather to play with when the bank he worked for upgraded to electro-mechanical ones. I later used it for my homework, the only kid at school with access to a calculator, (something I had to keep secret as my teacher would not have approved.) Division was quite a convoluted affair involving multiple subtractions and shifts. I used that same algorithm later in my assembler longword division routine. I am your grandfather it seems, as these were, other than slide rules, the only mechanical things we had at Imperial College in the 60s. Unlikely, but Id be happy to adopt you as mines gone missing ;) Even transistors were new then (8-)# Was yours the one you had to turn a handle - one way for addition and the other for subtraction, and shift manually? Exactly! A good athlete could squeeze between 0.1 and 0.4 flops out of one of those. A proficient abacus user would beat that hands down, though. Using methods like that, as you say, give one a good feel for the mechanics of programming. I believe the algorithms used today are fundamentally the same. The same could be said for the UK101 (almost all discrete 74X TTLs) and computer hardware. Sinclair ULAs don't give any good feel of what the poor old computer is actually _doing_ at the basic level. Even the system clock on the UK101 was divided by 7404s! Developments have been incredible since then! I wonder if we are entering a phase of diminishing returns and consolidation or whether were going to see changes on that scale for the next 40 years. Per
Re: [ql-users] Sbasic and numbers
Dave Walker writes: If there really is a need for these extra precision routines to be available from SB, then maybe it would be worth writing SB wrappers for the maths support routines used by c68? These include support for IEEE 32,64 and 80 bit, and also for 64 bit integers with add/subtract/multiply/divide supported as arithmetic operators. They are highly optimised assembler, so should not be that difficult to wrap? In fact if there is a real need, I could do it (on the basis that I already support these routines). Need? I did have a need for such once, when I wrote my accounts program. I started writing an fp package then, but got another job before inflation and the operation outgrew the limits of long word integers (21,474,836.47 ;) so it was never completed. It could be very useful. And where there already is a solution, the need may soon follow ;) The hardest part will be to get agreement on the SB interface needed to support what is wanted. Introducing a new type into SB, though it undoubtedly would be the most pleasing solution, would be a major operation that could take years to get right. The simplest method, imho, would be to do it as an add-on toolkit, which would also benefit the non-smsq scene. Heres my penny's worth on how to implement it. Store the numbers in their internal formats or as coded strings (ie not straight ascii, see below) and have suitable conversion routines to input and display the numbers. From this starting point there are different ways of proceeding: 1) Separate routines for each of the new types, eg result$ = ADD64(n1$, n2$), result$ = ADD80(n1$, n2$), result$ = ADDI64(n1$, n2$), etc, or 2) Internal coercion within the package, eg result$ = HP_ADD(fp64$, fp80$) or even result$ = HP_ADD(int64$, qdosfp) The latter method (my preference) would make use of coded strings, ie the type of the number would be included in the string together with the number in its internal format. I seem to recall that there are some spare bits in the IEEE formats which could be used, otherwise simply tag a byte to the front of the number. The tag could also be usefully employed to indicate whether the operation or conversion was successful, which would be translated into standard Qdos errors using something like ERT HP_ERR(result$) Another nice touch might be to use the FPU if present, though perhaps this may not speed things up due to the various overheads. Per
Re: [ql-users] Sbasic and numbers
Franois Van Emelen writes: It is not too difficult to write your own fixed or floating point routines in Basic using basic school maths, but they would be relatively slow. (The book Mathematics on the Sinclair QL, by Czes Kosniowski (out of print) might provide a suitable starting point.) I doubt I could do that myself. Monetary calculations normally only require the four basic operations, add, subtract, multiply and divide. These are really not too difficult to implement using basic arithmetic. (Divide could be a bit tricky, though.) Heres a silly example I knocked together in a few minutes just to demonstrate. (Input validation, output formatting and, more challengingly, the remaining three operations are left as an excercise for the determined reader.) 100 DEFine FuNction Add$(n1$, n2$) 110 LOCal i%, c%, r%, m$, n$, r$ 120 IF LEN(n1$) LEN(n2$) THEN 130 m$ = n1$: n$ = FILL$(0, LEN(n1$) - LEN(n2$)) n2$ 140 ELSE 150 m$ = n2$: n$ = FILL$(0, LEN(n2$) - LEN(n1$)) n1$ 160 END IF 170 c% = 0: r$ = '' 180 FOR i% = LEN(m$) TO 1 STEP -1 190 r% = c% + m$(i%) + n$(i%) 200 IF r% 9 THEN 210 r% = r% - 10: c% = 1 220 ELSE 230 c% = 0 240 END IF 250 r$ = r% r$ 260 END FOR i% 270 IF c% = 1: RETurn c% r$ 280 RETurn r$ 290 END DEFine 300 : This will add two integers of any size, entered as strings, digit by digit. On my Athlon 1700 PC, using QPC2v3/SMSQ2.99, it will do about a thousand 20-digit additions per second. you cant change the world, change yourself! might usefully be applied to the problem. Or in this situation; if more serious work is involved, avoid Qdos/Smsq ;-) No, no. Dyed-in-the-wool QLers should stick with it and always plump for the change-the-world option instead. Per
Re: [ql-users] Sbasic and numbers
Tony Firshman writes: Monetary calculations normally only require the four basic operations, add, subtract, multiply and divide. Surely two only - addition and subtraction? Multiplication and division are shorthand for addition/subtraction in my book. ... or am I being too simplistic. It all depends on what youre trying to do. Working out percentages requires the use of multiplication and division, for example, and as someone pointed out, you'll need powers to calculate compound interest rates. Theres no limit. Look at large companies, such as the late Enron, they even use imaginary numbers! However, nowadays, subtraction seems to be all the rage. As you point out in a later mail, most of these operations are merely addition or subtraction at heart. I once had an old mechanical calculating machine, given to me by my grandfather to play with when the bank he worked for upgraded to electro-mechanical ones. I later used it for my homework, the only kid at school with access to a calculator, (something I had to keep secret as my teacher would not have approved.) Division was quite a convoluted affair involving multiple subtractions and shifts. I used that same algorithm later in my assembler longword division routine. Per
Re: [ql-users] Sbasic and numbers
Franois Van Emelen writes: Thank you for your 'ADD$' function, but it doesn't solve my problem. I'll rephrase my question with a concrete example: A DBAS-file is open. One of the fields is of type 3 (floating point) The user wants to update that field. That could be done with something like: 120 input new_value$ Suppose the value assigned to new_value$ exceeds 9 digits (new_value$='12345678.55') or another value with more than 9 digits As long as '12345678.55' is manipulated with a text variable everything will be ok, of course. But that large number has to be stuffed into the floating point field. set#channel, x,new_value$ , x=field number New_value$ is 'save' to the floating point field in its internal format (I suppose) Let us now (or later on, of course) retrieve the content of that field: a=fetch(#channel,x): 'a$' could be used instead of 'a' print a (or a$) will display '1.234568E7' which is not the same as the value assigned to new_value$. And here comes my original question again: Is there a way to get the original value.In other words is it possible to act upon 'a' (or 'a$') to 'extract' '12345678.55' from '1.234568E7' ? Use a string variable in DBAS instead of a float and use the sort of routines I described to do the calculations. Didnt someone write an IEEE fp (64 or 80 bit) emulation package for the QL? Even if there is one, youd probably have to store the values in a string unless DBAS happens to support the type. Per
Re: [ql-users] Sbasic and macro substitutions
François Van Emelen writes: Hi Marcel, Thank you for your answer. Wouldn't there be a problem when your Eval$(e$)function is used 1000s of times? Isn't there a limit to the number of times a channel can be opened and closed in a program? There is be no need to keep opening and closing channels or even re-executing the SBasic interpreter. As my program demonstrated you can simply keep it plumbed in for re-use for as long as you need it. Youd only have to set it up again if it crashed. A combination of Marcel's program with the principle of mine would be a solution to your problem, I think. Per
Re: [ql-users] Missing source code
Marcel Kilgus writes: P Witte wrote: In the Smsq/e sources there are two libraries, util_menus_lib and uti_lib, that dont have any sources. They have been lost. util_menus are the files for accessing menu_rext (written by Jochen), those are not lost. On the other hand, theyre not present. If you (or Jochen) have them, and they are freely availible, could they be passed on to Wolfgang for the next release? That leaves one down and one to go. Anyone? Per
Re: [ql-users] QLWA documentation
Jerome Grimbert writes: does anyone have a synthetic and complete documentation regarding the QLWA filesystem (the one used on Qx0 and QPC). I have found some 'educated'-guess about the value of the first sector, but I wonder about: - a better documentation of that first sector - how the files are organised - what is the content and meaning of the map - how does a (sub)directory work (and what is its contains ?) Or would I have to read the code and figures it out myself ? (Any helps appreciated) You could scan the archives of this list for lots of useful details. Start at 1998! Per
Re: [ql-users] Epson 800 wanted
Jerome Grimbert writes: [EMAIL PROTECTED] makes some magical things to make me read } Anyone got an Epson stylus 800 colour printer (or similar) for sale?? Needs } to be a serial printer - I only have dot matrix ones here Are you sure the Epson is not a parallel printer ? I have not meet a new serial printer since the middle of the eighty, and it was all dot matrix then... I have an Epson Stylus Color 850, about three years old, that has both a serial (RS232) and parallel (IEEE 1284, EPP) interface. Great printer! Speaks ESC/P2. Im not about to sell mine, but I can recommend it (if you can get one). Like most things, its not perfect. You cant turn it off at the mains and it spends a long time grooming itself and burping and farting in the mornings. Generic ink cartridges come cheap though. You can forgive a lot for that. Per
Re: [ql-users] Display_cde GD2 update
Norman Dunbar writes: There's always one isn't there ! when the line gets too long - and I'm not quite there yet - you simply get a 'buffer full' error when loading a really really long line into S*Basic. So, I suspect the limit on the number of parameters in a PRINT is defined by the length of the actual line of pre-compiled text - 32Kb if I remember correctly. I'll let you know what the limit is - if I ever find it ! Theoretically one would expect the maximum possible number of parameters to be max_linelength / 2 - 2 Say you defined a single character machine code procedure (X) and didnt use a line number, eg: X p,p,p,p,p,... youd expect to be allowed up to 16380 parameters. Actually, for Smsq/e 2.99 the answer appears to be that 'only' up to 5459 parameters are allowed (provided the line length is not exceded). But this could be arbitrary. Check it out: 100 p% = 5459 110 OPEN_OVER#3;'ram1_tst_bas' 120 PRINT#3; '1 X '; 130 FOR i% = 1 TO p% - 1: PRINT#3; 'p,'; 140 PRINT#3; 'p' 150 CLOSE#3 LOAD ram1_tst_bas into an SBasic and try to LIST or EDIT it. What are the limits for other systems? (Not terribly important, I suppose, but nice to know all the same ;) Per
Re: [ql-users] Feedback and suggestions for new sprted
Jerome Grimbert writes: I'm planning to rewrite the sprite editor 'sprted' soon. So far, the main evolution would be support of the now numerous GD2 sprite modes. Is there anything else that would be also welcome ? Anything that you would like to change ? or remove ? I do not promise to follow all suggestions (especially hard ones and contradicting ones!). As for traditional wedding in movie, speak now or ... An English manual? Per
Re: [ql-users] Assembly question
Norman Dunbar writes: I wasn't being critical - honest. You wont get much thanks for being either ;) Per
Re: [ql-users] Assembly question
Jerome Grimbert writes: My assembly being a little rusted, I would like to check with the knowledgeable people the following portion of code. ... tst.l d2 beq.s first_place second_place: ... Now, if d2 is 0, would executing that code reach first_place or second_place ? (I have my idea, but I do not want to influence the audience). Thanks for your attention. Glad to see that "assembly questions" still appear to attract a lot of interest. Itoo sometimes haveproblems with conditionals. Probably something to do with latent dyslexia (I really must get round to joining the DNA - National Dyslexia Association ;) (If you dont get the joke you are probably a sufferer too!) My solution was to create and use the following table: Conditional branching (bcc) --- CMP Dx,Dy X = branch taken, N Z C = flags set Dx/Dy | 1/0 | 1/1 | -1/0 | 0/1 | 1/-1 | -2/-1 | Flags | NC | Z | C | | N | | + - - - + - - - + - - - + - - - + - - - + - - - + U bhi | | | | X | X | X | + + + + + + + U bls | X | X | X | | | | + + + + + + + U bcc | | X | | X | X | X | + + + + + + + U bcs | X | | X | | | | + + + + + + + bne | X | | X | X | X | X | + + + + + + + beq | | X | | | | | + + + + + + + S bpl | | X | X | X | | X | + + + + + + + S bmi | X | | | | X | | + + + + + + + S bge | | X | X | X | | X | + + + + + + + S blt | X | | | | X | | + + + + + + + S bgt | | | X | X | | X | + + + + + + + S ble | X | X | | | X | | + + + + + + + (Please let me know if youdiscover any mistakes!) Per
Re: [ql-users] QMON2
Rich Mellor writes: I think the trick is to set a breakpoint in the actual code to debug. I seem to remember you can debug code which runs under iow.xtop, just not through the call itself. I think that I have tried that before.. but thanks for the tip - I will give it a try again!! Often it is possible to fake the trap and trace the code in user mode. When you know it works you wrap it up inside the iow.xtop trap. - Just in case you hadnt tried this. Per
Re: [ql-users] Using WMAN and EasyPTR
Rich Mellor writes: OK, I have tried to create a null pointer. However, can anyone please explain why the following code shows 2 pointers on screen: Your thoughts/ideas would be much appreciated... Two pointers?! I couldnt properly run the code, so I cant really say. However perhaps this null sprite definition may work better: rem Set up Null pointer restore BlankPtrAdd = alchp(32) for i = 0 TO 30 step 2: read word: poke_w BlankPtrAdd + i, word : data $0100, $ :rem .w form, time/adaption data $0001, $0001 :rem .w x size, y size data $, $ :rem .w x origin, y origin data 0, $000C:rem .l pointer to colour pattern data 0, $0008:rem .l pointer to pattern mask data 0, $:rem .l pointer to next definition : data $, $ :rem .w colour pattern data $, $ :rem .w pattern mask You shouldnt need to use REMPT before using this sprite. In an SBasic with the standard windows try: outl#0: cls rem Set up Null pointer here, as above sprs#1; BlankPtrAdd x% = -1: y% = -1: tv% = 13 rep rdpt#1; tv%, x%, y% print#0; tv%, x%, y% endrep Per
Re: [ql-users] Using WMAN and EasyPTR
Rich Mellor 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. I have tried REMPT from EasyPTR, but this does not appear to work that well - when you use RDPT to read the mouse position, you get flickering of the standard WMAN mouse pointer... Depending on the effect you wish to achieve, you could try fiddling with the termination vector. Try tv% = %10110100 as in 100 OUTL#0 110 tv% = %10110100 120 x% = 0: y% = 0: sw% =-1 130 REPeat 140 RPTR#0; x%, y%, tv%, sw%, xr%, yr%, t$ 145 PRINT#0; x%, y%, tv%, sw%, xr%, yr%, t$ 160 END REPeat (Tested with Smsq/e 2.93 and 2f99) When bit #7 is set in the termination vector a window request is initiated - same as when you do a Move - so the sprite is active across all windows. Terminate the operation with a HIT or a DO. If you just wanted something local, you could try designing a null sprite instead, but I havent tried this. Per
Re: [ql-users] New christmas WMAN
Wolfgang Lenerz writes: The only thing I know is that, if the bar colour AND the bar section colour are BOTH set to 0, then, instead of having a black bar on a black background, the scroll bar and the scroll bar section aren't drawn AT ALL. So the combination of these two parameters, set to 0, means that you can have a window with scroll arrows, but no scroll bar. Perhaps that is what it was intended for (?). Exactly. Please dont fix it, anyone ;) Per
Re: [ql-users] PIC File Format and GD2 Continued
Jerome Grimbert writes: If you can wait a little, I should write a new trap soon (as I said, the I really believe that the various GD2 modes should not be a burden for an application programmer, but an opportunity to choose the best suitable format for the data. Therefore, the usage of GD2 drivers should not add any code (such as which mode is running) into the application. You may want to use the extra functionalities of GD2 if present, but that might impact compatibility. I think this is an excellent principle - if it can be solved in a technically satisfactory way. Does anyone else have any thoughts on how this might impact? To get back on the exact question, I do not know. May be there is some calls which give that information ? (or which do not return an error in such cases ?) I suppose the only legal way at present is to query the DISP_xxx Thing. From SBasic: IF DISP_TYPE = 32: PRINT HI COLOR MODE However, from assembler its really quite an unnecessary fiddle to do. There really wants to be a system variable or a simple call for this, one that would be easy to implement as a dummy toolkit for older systems. Do you have any hardware which use mode(2,0) ? I only know of QXL/QPC: mode(2,32) and Q40/Q60: mode(2,33) And if you leave the conversion to the system, I really believe that you do not need to know the current mode at the application level: Especially, Imagine that your application has detected a mode and has performed some adaptation to it. And somehow, outside of your application, the user changed the mode after your adaptation, how are you going to react and prevent that ? Are you going to regularly check the current mode and readapt on the fly ? It is really simpler to have the system do that for your application, which means in first place that your application should not be aware of the current mode. Your application should make provision for both original QL and GD2 driver and leave the data structures upto the system to choose the best appearance. (so it can run on a classical QL too, if meaningfull [for instance, the sprite editor is not currently able to run on such mode]). Even so, it will sometimes be necessary to check for the presence of GD2 initially: 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] File Type/Directory?
James Hunkins writes: Can anyone tell me the best way in either 'C' or assembly to determine the file type (executable, directory, etc)? Here is a Directory Record Definition (The mnemonics may possibly be my own as none were published when this was written). * File Header Definition fht_len equ $00.l file length fht_acces equ $04.b file access key (0 in qdos 1.03) fht_type equ $05.b file type: fht.nor equ 0 basic program or ordinary data files fht.exe equ 1 executable program fht.rel equ 2 relocatable object files fht.thd equ 3 Thor directory files (ArgOS) * Others ? fht.dir equ 255 directory files (standard) fht_finf equ $06 8.b file type-dependent information fht_data equ $06.l default data space for executable files fht_name equ $0E.q name string fht.nmln equ 36 max file name length fht_updt equ $34.l date of last update fht_vers equ $38.w version number fht_filn equ $3A.w file number fht_bkdt equ $3C.l date of last backup HTH Per
Re: [ql-users] QPC hard drives size
Bill Waugh writes: I was using a 2.2 Gb drive on my Q40 and it was plenty, so sort of assumed this would be ok for QPC, I have a 40 Gb drive in the PC and it has almost 30 GB free. I formatted the .win file to 2000 and it has worked, well this is probably more than I really need, thinking about it maybe I need to think out just what I need from QPC, the Q40 had on it a lot of jpeg's from my digi camera ( also on my PC for safety and to be sure to be sure burnt onto a CD, so I think my mind set needs a purge ( render unto Ceaser and all that ). Yes I think I'll sleep on it, tomorrow I'm into wallpaper unfortunately not the screen type but the up a ladder type ( cut and paste though ) (:-) With QPC you are probably better off with a larger number of smaller drives: They are a lot quicker to backup using the Windoze file system. Although you can only have up to eight drives online at a time, you can have many more on your hard disk and swap between them as required. Use Qwirc for this (FREE from Dilwyn's excellent site) or type in your commands in Basic. Still wonder if there is any reason for the format failure, maybe a limit to block size or something ? The theoretical limit of the QLWA disk format appears to be 4Gb (using a block size of 65k - what a waste!) But only max 32k block sizes are currently implemented = 2Gb. Only worth using where you need to store large files. Better use smaller partitions for normal use. Per
Re: [ql-users] WMAN progress
George Gwilt writes: 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. Erm, I must admit that BYALL was just the taking of a bit of artistic license on my part. 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. Indeed. And though is does get easier, it always requires a lot of effort. We certainly need all the tools we can get. Per
Re: [ql-users] QDT : Program Recognition assistance request
James Hunkins writes: If you have the programs, could you send me the additional details (I need this for any submissions to be added to the data base). 1) a list of the actual file names of the executable code 2) title of the program 3) a very short description of what the program does (editor, window designer, game) 4) a list of any executable files that are support files and are not meant to be run directly (IE: no icons should be made for them) 5) optional : any minimum command line requirements Again, thanks. I appreciate your help and suggestions. Jim Quill; Quill; Word processor; ; F2F3ldefault_docENTER Abacus; Abacus; Spreadsheet; ; F2 Archive; Archive; Database; ; run start_prgENTER Easel; Easel; Business graphics program; ; F2 XChange; Psion XChange; Office suite; ; ; Xchange is worth expending a bit of extra effort on, imho. I never liked the idea of lumping these four programs together, prefering the single-program versions. However, the extra capabilities of the Xchange versions of the programs, plus the fact that the whole package has been updated to run on modern QL systems leaves little choice. To get round the fiddle of negotiating around the different programs I normally run each in its own instance of Xchange. I use a variety of startup scripts, attached to hotkeys, depending on what I want to do: One will load Xchange with Quill, loading the default document template, another will load Xchange with Archive, etc. Using hotkeys I can switch between different intances of Quill or Archive, etc. It would be nice if QDT would support this. Quill and Archive, and to a lesser extent, Abacus, are still among my most used programs. (Are there any more of us dinosaurs out there?) I dont see Qpac 1 and 2 anywhere in your list - or does QDT supercede them all? BTW I notice Easel no longer seems to display properly under GD2. Advice, anyone? Per
Re: [ql-users] Quanta Editor
John Taylor writes: Roy Brereton, Quanta secretary, has just told me that Colin Baskett has passed away. He had no details other than it was sudden as he suffered no illness. Im sorry to hear that. Though I didnt know him personally his contribution as our long-suffering Quanta editor has been much appreciated. Per
Re: [ql-users] SoQL and Dip -t -v
Jonathan Dent writes: I don't think there are any articles on using SoQL. I'm sorry the documentation is sparse. The library functions are based on the standard library functions though. If you need specific help I'll try to make time to answer your mails. You can mail me directly on this from: address or DENTatFREESURFdotCH. Since there is so little documentation couldnt you please mail via this, or the ql-developers, list? One never knows when it may come in handy.. Per
Re: [ql-users] WMAN progress
George 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 Thanks ;) 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. I have four pages of updates (also undated) that takes me from wm.erstr to sms.wevt, but no mention of wm.rptrt. Per
