[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@quanta.org.uk
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)
Tarquin Mills writes: <> > Four years a go I became a QLer and started writing a web browser on a > emulator (QLay), but the PC I did this on no longer exists and the emulated > environment limited development. So I decide to buy a QL system to continue > development on, over £1000 later (cost mounting) and still no working > system. This is why HyperBrowser development stalled, I even tried > cross-development on M$ Windoze and Debian Linux. A refund plus damages, > or small claims court action are looming. This all could have been > avoid, but the ball has not been in my half of the court, so I could > do nothing. £1000 for a non-working QL system? How on earth did you manage that? Per
ql-users@quanta.org.uk
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
[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
[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@quanta.org.uk
Wolfgang Uhlig writes: <> > Isn't there a possibility to "make" a sprite out of the string "on the > fly"? Possibly with a background-system-colour? > I know that there is something like blobs and patterns but I have > never understood how this works. > > I'd like that very much and think it would make drag&drop routines much > more attractive and clear. Provided the text item you wish to convert is already visible on screen this is not difficult, just a little fiddly. If its not visible it would probably be about as difficult to do as writing a winprinter driver for the QL..., ie not exactly trivial! Per I thought Id have a go just to demonstrate: The routine below is not guaranteed to be bug-free, so save your work before testing! This is just a test and not designed to be universal. It will need some modifications if you are not using QPC2 with GD2! To test, start an instance of SBasic in the top lefthad corner of your screen. Print some text in window#2, eg LIST this program, then RUN it. If you dont have EasyPtr you'll need to change SPRW on line 330 to some other keyword to draw the sprite 100 s = SCR_BASE + SCR_LLEN + 4 : rem Start at top left of screen 110 xs = 100: ys = 10 : rem X/y size 120 pixw = xs * 2 : rem Pixel words 125 CLS 130 : 140 a = ALCHP(24 + (pixw + xs) * ys) 150 POKE_L a, $2200020: rem Mode 32 sprite w alpha channel 160 POKE_W a + 4, xs: POKE_W a + 6, ys: rem Create sprite header 170 POKE_L a + 8, 0 180 POKE_L a + 12, 12 190 POKE_L a + 16, 8 + pixw * ys 200 POKE_L a + 20, 0 210 t = a + 24: rem Target address for sprite data 220 : : rem Create sprite, line at a time 230 FOR i = 1 TO ys 240 POKE$ t, PEEK$(s, pixw) 250 s = s + SCR_LLEN 260 t = t + pixw 270 END FOR i 280 : : rem Create mask (ghost) 290 FOR i = 1 TO xs * ys 300 POKE t, 128: t = t + 1 310 END FOR i 320 : 330 SPRW #1, 10, 50, a: rem Draw sprite using EasyPtr 340 SBYTES_O 'ram1_txt_spr', a, 24 + (pixw + xs) * ys: rem Save sprite 350 RECHP a
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
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
[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
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
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
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
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
[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] Birthday & QL 2004
Wolfgang writes: > On 18 Jan 2004 at 10:20, P Witte wrote: > (...) > 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. > > > Who could propose a topic to be talked about? The audience: Part pre-submitted questions (once the panel is known, perhaps, with the panellists deciding which questions they wish to take up) part real-time. Just a thought - trying to be helpful ;) 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] 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
[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] 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
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
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
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
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] BMP2SPRT v. 1.01
Wolfgang writes: > version 1.01 of BMP2sprt can be found at > > www.scp-paulet-lenerz.com/14mljkl24/wolf/download Great little program, Wolfgang. Looks good too. Thanks! BTW, I cant change the paper colour using the non-Wman option. Eg if I enter ff (or any other number) the window goes black. $xxx, though, works as advertised. 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] The Byfleet Show
If anyone at the show requires a Kingston 256Mb SD flash ram thingy, Ive got one surplus to requirements. Bought it for £61 a couple of weeks ago, but found I couldnt use it as my PDA doesnt recognise anything over 196Mb. Thanks to the dumbed down manuals and specs you get these days this was not obvious :( Best offer over £40 secures. If theres a Bring'n Buy stall youll find it there else ask someone to point me out (Jochen, Tony F and Roy know my face). 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
Sorry for being such a pain, but I have some further questions: How do I position a PE window accurately? Problem is, I want to create a button, to go into the button frame. Im hoping to use a standard Window Definition with a single Loose Item. If I use a window with a border width of 1 and then use wm.prpos, my button overlaps part of the adjacent button. (This occurs even when my button's x-origen is divisible by 4). If I use a borderless window, ie border width 0, there is no problem, except as below: In certain circumstances, I want to be able to liberate the button from 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! Ive spent ages trying various alternatives. Please help! 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
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] wm.rptrt
Marcel Kilgus writes: > > Also, can others confirm that the DATA directive in Qmac 1.06 doesnt work? > > It works. You probably also have to include the line >filetype 1 The file is supposed to be relocatable, as it has to be linked with others to make up the complete job code. Closer investigation reveals that Qmac does afterall correctly set the dataspace in the relocatable fileheader, but the linker (Qlink 1.03) does not seem to pick it up as it should. Qlink is supposed to accumulate all dataspace requirements given in the various relocatable files and set the total amount in the header of the resulting executable, unless overridden by a larger specification given in a DATA directive in the link file itself. I never noticed the current behaviour before, so I suspect that something got broken in the recent update. 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] 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] 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
[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] What printers do people use with their QL??
Phoebus R. Dokos writes: Its an important point you mention about the print heads. With HP you get a new print head with every new cartridge, with the Epson you only get the one you bought with your printer, and when that goes, so, pretty much, does your printer. I also have the same opinion as you regarding the lousy HP sheet feeder, at least on the old Deskjet series. My Epson has worked well for me, and at £70, or whatever Rich is selling them for, you can hardly go wrong. Another thing is I could simply use my old LX80 printer drivers for the new Stylus 850; they are pretty much compatible. Is there anyone among us who is in a position (eg working in a computer shop) to test the latest generation of printers suitable for for QL users? The four most important things I can think of to know about a printer are: 1) Connectors (serial, parallel, USB, dual) 2) Printer language (built-in fonts and plain text) 3) Running costs 4) Design (reliability, long-term cost) Per
Re: [ql-users] What printers do people use with their QL??
Rich Mellor writes: > Just a quick survey. > > A lot of people have expressed an interest in Epson 850 colour stylus > printers for their QL. > > However, what printers are people actually using nowadays with their QL?? <> Epson stylus colour 850. Beats the LX80 hands down, George. The speed is up and the decibels are down. Epson ink is more expensive than Dom Pérignon and doesnt taste as good, but generics are available at 1/4 of the price. 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: > 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] 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
Dilwyn Jones writes: <> > Wiring is critical, the slightest booboo and it will either not work > at all or only at very low baudrates (usually not at all). Sernet is > one off those things that either it fails miserably and takes ages to > set up, or once working works perfectly, faultlessly and quickly > becomes one of those things you could never have managed without it. <> I dont know about booboos. Im not a serial virgin, in case that wasnt obvious. I had QTPI running at 115k baud. Perhaps there are two dud versions of sernet? If anyone can put together a piece of plug'n play kit that includes a copy of sernet plus a 3m cable (D9 plugs either end) for QPC2<->Q60, and guaranteed to work at full speed first time! Im in the market. 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
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
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] Keith Mitchell contact details
Tony Firshman writes: > You might not be aware that publishing literal email addresses like this > in _any_ group, even an email based one like this, is favourite spam > harvesting material. I am sure that this area is archived all over the > place on the web. Its all in the headers anyway, so does it really matter? 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
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] 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
[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] 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 '<>' > > Lab10076dc.w 13 > dc.b 'win2_NEMESIS_' > Lab10086ds.b 35 > > The above is tested and working. 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] 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] 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] New(er) SourceEdit SuperBasic Language file
Phoebus Dokos writes: > Jimmy and I prepared a newer version of the SuperBasic Language File for > SourceEdit.We sent it already to SourceEdit.com (not available yet though). > Until it is, contact me or Jimmy for a copy. > > Among other new things in the newest release is inclusion of ALL operators > (some were missing previously), new (previously missing) keywords for the > (Super)Gold Card and removal of the FOR...NEXT construct (as Next is not > really the formal end of the looping mechanism, just a "jumper" like > RETurn. These two have been moved to the "operators" section, thus allowing > for different colour that will attract your attention. Id like a copy of the language file, please. Please include: defproc/enddef deffn/enddef def proc/enddef def fn/enddef sel on/endsel if/endif rep/endrep for/endfor ret rem as these are all legal S*Basic shortcuts! Source Edit is not wonderfully stable. Ive crashed it a couple of times without even trying, and after that it wont as much as talk to me without re-installing ;( 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] Dynamic arrays?
Wolfgang writes: > I wonder whether anybody out there has come across the same > problem I have, (and has found a solution). A few possible solutions, depending on how your program uses the arrays between re-dimensioning, etc: 1) Dimension the array to the max youre ever going to need right from the start. (This is analogous to your suggestion re the buffer problem we discussed earlier ;) Ie # Its fast but greedy. 2) Use "rubber arrays" as described in the Turbo manual. # Slow, but not too bad on "QLs" with fast drives. 3) Take the re-DIMentioning ouside the sub-routine. However, like the method you suggest by your example, this could be expensive in terms of memory, as the old memory occupied by the the array is, I believe, not released back into the common heap (at least not in Qdos) but remains part of the Basic area. Dont know if Qlib knows how to free that memory again either. # Possibly wasteful. 4) Dont pass the array to the sub-routine as a parameter, but use the array(s) globally. I was going to suggest using PARNAM$ here as a way of determining which global array was to be re-dimensioned, but noticed there is a bug in Smsq regarding this and PARSTR$. So use an extra parameter instead: def proc check_array(array$,count%,new_string_to_add$, which_array%) local b%,temp_array$ if count%
Re: [ql-users] QPC2 v3.11 & SMSQ&E 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] 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
Robert Newson writes: <> > [If you're interested, I found egrep to be the fasted for the grepping I do.] I am interested. Was it you I corresponded with about a multi-file version of grep? The current versions for the QL will only allow one file at a time which makes it rather inefficient for scanning a whole directory or disk. Per
Re: [ql-users] efficient buffer size
Robert Newson writes: <> > [If you're interested, I found egrep to be the fasted for the grepping I do.] I am interested. Was it you I corresponded with about a multi-file version of grep? The current versions for the QL will only allow one file at a time which makes it rather inefficient for scanning a whole directory or disk. Per
Re: [ql-users] efficient buffer size
Lau writes: > > As far as I know, nothing my program does should be affected by the size > > of the buffer, apart from filling it in the first place. So my findings > > would seem to indicate that a buffer size of between 256 bytes! and 1k are > > optimal for this kind of thing. This is strange enough, considering that > > iob.fmul is called more frequently the smaller the buffer. What surprises > > me is why were not seeing the benefits of iof.load in this (or at least I > > dont). Anyone got a theory? > > > > I was watching this thread with interest. Maybe I should have commented > earlier... that the results you have obtained are exactly what I was > expecting. Your explanation made reminded me that a considerable amount of buffering is already going on (the hard disk, Windoze, and Smsq). iof.load is possibly not much more efficient under those circumstances than iob.fmul. Compared with the processing of the data going on, probably only a small proportion of the time is spent on replenishing the data from storage. <> > Then there's caching... if you had enough memory, your test would > produce some curious results... whichever buffer size you ran first > would seem to be rather slow compared to the rest. As you ran your tests > on your hard disk, the caching effect doesn't come into it, but I > thought I'd mention it. That was the significance of 2^n size no. s remarks --- - - --- --- x: xxx xxx xx Primer run ;) > Finally, it all depends on how fast your processor and hard disk are. > These days, processors tend to have a lot of cycles available per byte > transferred from(to) disk. That's the reason why compressed hard disk > partitions are actually *faster* to handle that uncompressed. The > processor has lots of spare time on its hands to perform the > (de)compression. Overall time to process a file becomes tied mainly to > the raw disk access time to get all the data on/off the disk. A > compressed file occupies about half the physical space, so can be > handled in handled in half the overall time. But I thought that PIO mode hard disks, the current norm, actually pushed the data into memory with barely any intervention from the CPU. In that case there would be some reduction in overall responsiveness if the CPU was busy uncompressing data as opposed to having it readily available? > Back to my earlier mention of caching... hard drives and their > controllers do caching as well. I'm not certain if they do read-ahead > caching. > > In summary, I believe your results are just giving the shear time it > takes the drive to spin on its axis tracks * cylinders * interleave > times, and have very little to do with any CPU processing. > > Answer to your original question: "How big a buffer should I use?"... > one byte? Hehe, youre probably right, though I think I'll rely on my test results in this particular case. I suppose my real question was whether there is some "sweet" buffer size pertaining to Qdos/Smsq, that minimises fiddly edge conditions and the like. Just like the mc68 processor prefers to work with words and long words rather than bytes and bits, is there a "word size" for the file system? Even though it wont make much difference, I like to know that everything is ticking over as efficiently as possible. Per
Re: [ql-users] efficient buffer size
Wolfgang Lenerz writes: > I'd still simply grab just as much memory I can use. > If speed is of the essence, as you said in your requirements, then > the user will probably also know to let the machine alone (tell him!) > and not have too many other progs trying to get memory at the > same time. If notn, then speed is not that essential, after all. > > So I'd still go for as much memory as I can get and read in the > entire file. > > If that can't be done (not enough space): > > Ultimately, it will then be the read operations that slow everything > down. > > Now, considering that iob.fmul & fstrg use D2 to indicate how many > bytes they should get, and since D2 only can be word sized, you > can, at most, read $f bytes in one go. > > If nothing else, I'd use that as my buffer size ... in which case youd be in serious trouble.. ;) Actually, it isnt quite that straightforward. I ran a program that scans files (and does unspeakable things to them, but that is of no concern here). It works like this: If the whole file fits in the buffer then the whole file is loaded (using iof.load), otherwise chunks to the size of the available buffer are loaded piece by piece, (using iob.fmul) until the whole file has been processed. I ran this program for every file on the hard disk, using increasing buffer sizes. The table below shows how I fared: 2^n size no. s remarks --- - - --- --- x: xxx xxx xx Primer run 7: 128 282 81 8: 256 543 79 9: 512 722 80 10: 1024 769 79 11: 2048 1063 80 12: 4096 977 82 13: 8192 620 85 14: 16384 290 88 15: 32768 220 90 Actually 32766 16: 65536 233 ?? --- - - --- --- 5719 Total files --- - - --- --- 2^n - I only tried buffer sizes of this series. The numbers 7..16 are the n. size - these are the buffer sizes tested. no. - these, incidentally, are the number of files on the hard disk that would fit entirly into a buffer of that size (plus all the smaller ones), eg there are 1063 files larger than 1024b and <= 2048. 233 are larger than 65536b. s- is the number of seconds to scan all the files on the disk with the given buffer size. remark iob.fmul does not accept sizes greater than $7FFF, so I reduced the size to $7FFE to complete this experiment. As far as I know, nothing my program does should be affected by the size of the buffer, apart from filling it in the first place. So my findings would seem to indicate that a buffer size of between 256 bytes! and 1k are optimal for this kind of thing. This is strange enough, considering that iob.fmul is called more frequently the smaller the buffer. What surprises me is why were not seeing the benefits of iof.load in this (or at least I dont). Anyone got a theory? 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
[ql-users] efficient buffer size
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? TIA 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: > Tony Firshman wrote: > > > > On Tue, 10 Jun 2003 at 00:43:13, Lau wrote: > > (ref: <[EMAIL PROTECTED]>) > > > >> > >> Marcel Kilgus wrote: > >> > >>> The history is documented here > >>> http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html > > > > Can someone please define "Gradual Underflow". > > That was the core issue being addressed. > > (don't if I have simply missed it in this thread) > > Pity Lau wasn't involved. Working in the care "industry" I thought Id heard it all, but this sounds scary: "One used traps, one trap to catch results that underflowed and denormalize them to produce subnormal numbers, and another trap to catch subnormal operands and prenormalize them." If numbers have rights someone ought to go after these guys. Per
Re: [ql-users] is minus one = -1?
TonyTebby writes: > The 68xxx series is 16 bit word oriented (even on the 68008 8 bit bus > version) so a whole word exponent makes sense. > But, by using only 12 bits for the exponent (enough for astonomical > callculations) the 4 MSBs can be used as the "floating point number token" > flag without needing to use an extra word in to flag a floating point > number - a 25% space saving for almost no cost. > At the time, "mass storage" was of the order of 100 kbytes, not the 100 > Gbyte today. That makes goods sense. But (my apologies to all those for whom it is as obvious as an elephant in the living room) with a 12 bit exponent, how come the range is only +/-617? Ie, why isnt it +/-$800 ? > > It allows all operations on the exponent to be done with unsigned > > arithmetic, which saves some brain work when implementing the stuff. > > > > Saving brainwork also means saving time and cost > > > 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. > > > > A floating point value = 0.0 is 6 bytes of zero - not just neat but > economical In practise Qdos seems to interpret $xxx : $ as zero, in other words there are 4096 different ways of saying nothing. That may be neat but hardly economical ;) 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?
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?
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?
Marcel Kilgus writes: <> > BTW, I've read that Quanta published some IEEE<->QDOS FP conversion > routines in the past (might have been quite some time ago). Does > anybody remember this and can scan me a copy? I scanned through my pile of Quanta magazines, but no luck. Perhaps it could have been during the year or two I was a lapsed member (96-98?) Some issues also were missing. Also checked the QL-User/World index. Sorry, cant help. (BTW: In my version of the QLindex, Quanta is only listed up to V6/I9. Did anyone ever continue updating it?) > In a somewhat related story, exactly that piece of code we're talking > about once helped Connectix (recently bought by Microsoft) to fix a > bug they were experiencing in their VirtualPC for Mac emulator. In > fact my code didn't work at all on their software but after sending > them a heavily cut down version (about 50 lines in total) they were > able to solve the problem right away (a very small number was wrongly > rounded to infinite by their FPU emulation). Still waiting for my > cheque in the mail, though ;-) M$ only ever pay one Bill, it seems. 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] Minerva
Lau writes: > Well, I've finally got around to it. > > It's not perfect (as I've had a bit of trouble...). > > See the (very out-of-date) web site. Bravo! Ive been looking forward for a long time now.. Thanks a lot! FYI the gzip version unzips without problems on the QL side. You seem to have forgotten the inc directory; the files win1_m_inc_assert win1_m_inc_bv win1_m_inc_choff win1_m_inc_delay win1_m_inc_err win1_m_inc_gw win1_m_inc_hp win1_m_inc_io win1_m_inc_jb win1_m_inc_mc win1_m_inc_md win1_m_inc_pc win1_m_inc_ri win1_m_inc_sd win1_m_inc_sv win1_m_inc_token win1_m_inc_vect4000 are missing. 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 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] 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
[ql-users] News
Hi all, This recent spat of silences is really off-topic, imho. About time we got the show back on the road. At least here, in this tiny corner of unreality, our thoughts and opinions matter and can make a difference. So why not put morbid thoughts aside and share with us the very latest developments in the weird, wizzo world of QL computing? Eg: Whats the latest on QPC? on SMSQ/E v3? EasyPtr? High precision maths? SOQL/PPP? Membranes? Q60? the Branagh succession? etc, etc.. Due to my present job I get far too little time to do much development myself. I hope this situation will change over time. Even so, I manage to produce a little something here and tweak a little something there, not much of which will interest anybody apart from myself. But since I go to such lengths and stick my neck out to exhort everyone else, I think I should, in all fairness, make some mention of my own recent activities: 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. It is not quite straightforward to do as there is no single system utility to execute files, and there are also a number of special cases that have to be considered, eg plain Basic or compiled Basic versus normal executables. Id want to have them all work in a similar, "intuitive" way. At present Im trying to get my head wrapped around the Smsq source code relating to all this and to work out a scheme that will satisfy my goals without compromising compatibility and without wasting resources unneccessarily. I dont have a completion date in mind, and it may never work to my (or anyone else's) satisfaction, so dont hold your breath. Another minor project Ive been working on recently is fixing and updating my asm2htm utility (big yawn, everyone!) with a view to enabling it to html-ise the Smsq sources for easy, logical browsing, as an aid to understanding the code - for novice and expert alike. This is now just about complete. I have no intention of re-releasing this program at the present time as that would just be too much trouble for the amount of interest there is in it. However, I hope to produce a html-ised version of the latest version of Smsq, to be included with the next distribution CD, viewable in most modern Windoze/Linux/Mac browsers. As asm2htm now supports style sheets, and also differentiates more elements of the code than previous versions, it should be simple enough for the punter to modify the appearance according to taste and need. Personally, I think the output is impressive. Whether anyone apart from me finds it useful is another question. So you see, Im not all mouth and no fingers, I hope you agree. Thats basically all from me for now. Over to you. 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
Lau writes: > By way of a complete diversion, I did produce a *very* high precision > package for the QL. All in assembler, very optimised, and/but requiring > the precision (in multiples of 16 bit) to be stated in advance (anything > from 64 bit up to a ludicrous number of digits). Not IEEE, but close, > and easily converted. It took the form of a library that operated on a > stack (very similarly to the QL's FP stack and its operations) and a > front end to that. Oh to have a peek! > I later converted the whole thing to Delphi, allowing up to 315,643 > digit precision, which you can find on my web site. Converting the > Pascal to C wouldn't be a huge task, and I might just do that anyway. I saw your Ecalc. It looks great! Im rather disappointed that it doesnt handle googolplexes, but then, one cant have everything I suppose ;) During development of my high precision (80 bit) fp package, the idea was to implement an RPN calculator Thing (I wasnt aware of Things at the time (86/87) but it was to have been implemented as a general system resource) based on the HP41 programmable calculator/computer. All calculations internal to the package would use it directly, and it was to be accessable from Basic (and any other language, including assembler). Of course the dream was ultimately to resurect and enhance my much beloved HP41CX, ie to have a simple programmable interface that would manipulate the stack and the rest of the calculator environment natively, but Ive had to shift all that on to my retirement todo list. (Mind you, dont expect any gamma function or FFT multiplication, as I dont even know what they are ;) > The reason I mention it is that it gets to be very inefficient doing > every operation as a separate *BASIC call - the call overhead itself > will be as great as the computation time (for precisions less that about > 256 bit, IIRC). > > Certainly it's a bad idea to convert to/from decimal! That typically > takes longer than the calculation itself. Agreed. That is why it is more sensible to store the numbers in strings in their internal format. Since C handles types differently to S*Basic, I thought it a good idea to hitch the type to the number format, thus saving time on validation, etc, and to allow a more S*Basic-like feel to coercion within the package. Per
