Re: [ql-users] Q40 problems
On Fri, 30 Mar 2001 at 13:59:25, Timothy Swenson <[EMAIL PROTECTED]> wrote: (Ref: <[EMAIL PROTECTED]>) >I've been having some problems with my Q40 starting up. I thought it was bad >memory, but I think that is a separate issue. Essentually here is what is >happening, when I start the Q40 up, the lights come on, the drive spins up, the >monitor gets a signal (green light) and then nothing. The typical QL screen >does not come up nor does my BOOT program start. > >The only resolution for the problem is to pull the memory out and reseat it. > >Personally, I think it's a static electricity issue. The PC case is sitting on >the carpet under the desk. I've had the problem happen by just hitting the >reset button (system working, hit the reset button, then it won't boot). > >The power plug is three prong (grounded). Is there a better way to ground the >case so that it does not zap the Q40? It is more likely to be a badly seated I/O card. On some I/O cards, I elongated the I/O card metal plate board to bracket screw hole so that the screw fixing allowed the card to sit lower in the ISA slot. TT does not do a splash screen, so there is no way of telling SMSQ starts other than a small blip sometimes near the bottom but only if the previous state was blank screen (ie memory has lost its contents. Often at boot you can recognise the previous screen if one powers up again quickly. Bad ram would not allow SMSQ to start, and one would get some screen display, often white/black bars. -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
[ql-users] Q40 problems
I've been having some problems with my Q40 starting up. I thought it was bad memory, but I think that is a separate issue. Essentually here is what is happening, when I start the Q40 up, the lights come on, the drive spins up, the monitor gets a signal (green light) and then nothing. The typical QL screen does not come up nor does my BOOT program start. The only resolution for the problem is to pull the memory out and reseat it. Personally, I think it's a static electricity issue. The PC case is sitting on the carpet under the desk. I've had the problem happen by just hitting the reset button (system working, hit the reset button, then it won't boot). The power plug is three prong (grounded). Is there a better way to ground the case so that it does not zap the Q40? Tim Swenson
Re: [ql-users] Geoff Wicks letter
On Fri, 30 Mar 2001 at 19:50:30, Geoff Wicks <[EMAIL PROTECTED]> wrote: (Ref: <[EMAIL PROTECTED]>) > >- Original Message - >From: Dilwyn Jones <[EMAIL PROTECTED]> >Subject: [ql-users] Geoff Wicks letter > > >> If anyone has read the solicitor's letter on page 24 of Quanta 03/01 >> referring to me, please can you translate it for me. My grasp of >> English is not up to the job. >> > >Sorry I forgot you come from a far flung corner of the kingdom, where the >natives are reputed to speak in a strange tongue. > >Perhaps you could ask QUANTA to provide dual language newsletters. After all >these days if a I apply for a UK death certificate it comes half in Welsh, >llofnod, disgrifiad a chyfeiriad yr hysbysydd, and all that. Why not in >Gaelic as well? It's discrimination against we 6.25% Irish/93.75% English. > >Geoff Wicks >[EMAIL PROTECTED] > >PS How do we get this back on topic? It _is_ on topic - it was after all in Quanta (8-)# Well I thought it was funny.. -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Geoff Wicks letter
At 01:50 ìì 03/30/2001, you wrote: >PS How do we get this back on topic? Aw... simple... make a Gaelic spellchecker ;-)
Re: [ql-users] Screen Snatcher 3 - maybe !
In article <[EMAIL PROTECTED]>, Norman Dunbar <[EMAIL PROTECTED]> writes < clipped > Latest version now working fine ! No phantom window :-) Instant screen snatches ... now extended at least to PC's running QPC2v2. To view the screen captured you need to get the screen base number with SCR_BASE function in SMSQ, so PRINT SCR_BASE. On a P1 PC with a 640 x 480 display with 256 colours this gives me 557360. So lbytes win1_images_screen1_scr,557360 : PAUSE loads the image back, with the PAUSE giving time to view it :-) DISP_COLOUR 3 changes to True Colour resolution and the screen base number becomes 3132032. So lbytes win1_images_screen2_scr,3132032 : PAUSE loads back TIFFs and JPEGs. Thanks for the new utility, so far :-), next the ability to capture a selected screen area ... as well as a full screen. Anyone got it working on QXL or Aurora ? I am testing it using images generated via Photo Version 0.8 available from Thierrys web site. -- Malcolm Cadman
Re: [ql-users] Geoff Wicks letter
- Original Message - From: Dilwyn Jones <[EMAIL PROTECTED]> Subject: [ql-users] Geoff Wicks letter > If anyone has read the solicitor's letter on page 24 of Quanta 03/01 > referring to me, please can you translate it for me. My grasp of > English is not up to the job. > Sorry I forgot you come from a far flung corner of the kingdom, where the natives are reputed to speak in a strange tongue. Perhaps you could ask QUANTA to provide dual language newsletters. After all these days if a I apply for a UK death certificate it comes half in Welsh, llofnod, disgrifiad a chyfeiriad yr hysbysydd, and all that. Why not in Gaelic as well? It's discrimination against we 6.25% Irish/93.75% English. Geoff Wicks [EMAIL PROTECTED] PS How do we get this back on topic?
Re: [ql-users] Phantom black con channel in QLiberated programs - SOLVED !
Dilwyn Jones wrote: > SCR_XLIM and SCR_YLIM most probably call iop.flim trap No. They just need the channel block in order to find the address of the PTR/CON linkage. From then on it's one simple MOVE command. So it's not really an "official" way of doing it. > The SMSQE manual I have hints at this but doesn't fully clarify it. > SCR_BASE and SCR_LLEN are described as accepting channel numbers, > SCR_XLIM and SCR_YLIM are not, Oh, you've another manual (ok, I didn't expect you to have a German manual anyway). My version tells me that the optional channel parameter for all functions. > but the description refers to maximum size windows can be set to > rather than screen size as such, implying the behaviour of an > iop.flim type extension. No, it's always the screen size. Marcel
Re: [ql-users] QL List:: QPC2v1 and TRA
Jerome Grimbert wrote: > Have you tried start% instead ? Integers are 16bit and a no-no for addresses. Marcel
Re: [ql-users] Screen Snatcher 3 - maybe !
>>> only the top left of the screen on an Aurora is used. You should >>> only save the actual number of bytes used for the screen resolution >>> used, i.e. for mode 0 and mode 8, this is pixel_width DIV 4. > >Is this mode 0 the same as mode 4 then, or has Aurora got mode 0, 4 and 8 Mode 0 is in fact Mode 4. QDOS seems to return 0 for 4 colour mode. FOr some reason in the past I thought it was 4, but n checking it turns out to be 0. Many programs will accept either 4 or 0 for 4 colour mode. Some will only accept 0. I think PIC files use a value of 0 for 4 colour screen mode. >So I need something like the following : > >MyMode = DISPLAY_MODE >if (MyMode = 0 or MyMode = 8) AND RunningOnAurora THEN >do a loop to save DISPLAY_WIDTH(#0) DIV 4 bytes from the screen address >for as many lines as SCR_YLIM >else >if (MyMode = 4) THEN > do something else >endif >endif > >Thanks for the info on pic formats, I have got it somewhere at home, just >not here at work. Umm, I'm not too sure if you need to do this. What you could do is something like this, using DJToolkit extensions: MyMode = DISPLAY_MODE IF MyMode = 0 OR MyMode = 8 THEN IF DISPLAY_WIDTH(#channel) = (pixel_width DIV 4) OR pic_file = 1 THEN SBYTES filename$,SCREEN_BASE(#channel),DISPLAY_WIDTH(#channel)*pixel_height ELSE OPEN_NEW #op_channel,filename$ IF pic_file = 1 THEN output 10 byte preamble for pic files address = SCREEN_BASE(#channel) FOR line_no = 0 TO pixel_height PRINT #op_channel,PEEK_STRING(address,(pixel_width DIV 4)); address = address+(DISPLAY_WIDTH(#channel)) END FOR line_no END IF ELSE REMark different routines for high colour modes (which I can't remember) END IF Not tested at all, written from memory. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Phantom black con channel in QLiberated programs - SOLVED !
>> why not simply use >> >> open#x, con >> scr_xlim#x > >is it documented somewhere? > SCR_XLIM and SCR_YLIM most probably call iop.flim trap and this in turn needs an open window - it returns the maximum possible outline of a channel - this corresponds to maximum screen size if it's a primary channel (e.g. #0 in BASIC), or the maximum outline that the secondary windows can be set to within that primary. Most extensions I've seen which return max screen dimensions call iop.flim (I wrote one such pair of extensions FLIM_W and FLIM_H in the DISPLAY_CDE article in a past QL Today), and all need either an open channel to test, or if none supplied open a channel themselves. After Marcel's comments, I'm sure we can assume that SCR_XLIM and SCR_YLIM work in pretty much the same way as others I've seen. The SMSQE manual I have hints at this but doesn't fully clarify it. SCR_BASE and SCR_LLEN are described as accepting channel numbers, SCR_XLIM and SCR_YLIM are not, but the description refers to maximum size windows can be set to rather than screen size as such, implying the behaviour of an iop.flim type extension. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Phantom black con channel in QLiberated programs - SOLVED !
> On 29 Mar 2001, at 13:27, Norman Dunbar wrote: > > > What to do to avoid a phantom : > > > > 1. Compile with windows copied. > > 2. Open #0 or #1 before calling scr_xlim/scr_ylim > > > > I suspect therefore that scr_xlim/scr_ylim look for channel #0 first and if > > found use it. > > If #0 not found, then try #1 and if found use it. > > If #0 and #1 not found, open a new #0 and use that. This channel appears to > > stay open until the end of the job. > > > why not simply use > > open#x, con > scr_xlim#x is it documented somewhere? Bye Richard
RE: [ql-users] Phantom black con channel in QLiberated programs - SOLVED !
>> why not simply use >> open#x, con >> scr_xlim#x >> Wolfgang Ah well, at the time I didn't know about the channel id parameter. :o( But Marcel pointed it out this morning - so I do now :o) Thanks. Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
Re: [ql-users] Phantom black con channel in QLiberated programs - SOLVED !
On 29 Mar 2001, at 13:27, Norman Dunbar wrote: > What to do to avoid a phantom : > > 1. Compile with windows copied. > 2. Open #0 or #1 before calling scr_xlim/scr_ylim > > I suspect therefore that scr_xlim/scr_ylim look for channel #0 first and if > found use it. > If #0 not found, then try #1 and if found use it. > If #0 and #1 not found, open a new #0 and use that. This channel appears to > stay open until the end of the job. > why not simply use open#x, con scr_xlim#x Wolfgang
RE: [ql-users] Qliberatore problems - SOLVED !
François wrote : >> Thank you for sending me SS3. You're welcome ! >> I modified line 2130 as well. >> 2130 DumpSize=ScreenWidth*(ScreenDepth*2) >> If ScreenDepth is not multiplied by 2, only the top half of the screen is >> snatched. I don't understand this. When testing (800 by 600 res in high colour) my screens all snatched fine - I loaded them back again to test ! In fact I have just tested with the latest version and it works fine. >> I use QPC2 v2 high colour mode and the snatched file is 96 bytes long. I use QPC2v2 in High Colour mode, 800 by 600 and this gives me a filesize identical to yours which when loaded back using : LBYTES ram1_screen1_scr,SCREEN_BASE(#0): PAUSE shows the complete screen (and I even had a FILES menu open at the bottom right corner to make sure when I snatched it) so I am a little puzzled to say the least. What resolution are you running in ? What result does DISPLAY_WIDTH(#0) give ? What result does scr_ylim give ? If you multiply scr_ylim by DISPLAY_WIDTH(#0) you get the number of bytes saved. There must be scr_ylim lines on the full screen and each of these is DISPLAY_WIDTH wide. Also scr_ylim should be equal to the depth setting on your resolution. >> Thank you for the time and work you have put in SS3!! You're welcome (again !) Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
Re: [ql-users] Qliberatore problems - SOLVED !
Norman Dunbar wrote: > > It's turning into a better week now ! > > I have now managed to solve the 'ambiguous name' errors with Qliberator when > compiling Screen Snatcher. I had set dev2_ to be the location where I load > and save to, and in the code, I had some $$asmb refernces to dev2_. > > Dilwyn pointed out that sometimes Qlib fails to find files etc up a devn_ > device, so I changed my source to use the full path name and lo, it compiles > every time so far. I hadn't changed anything, except the path names and > where it failed to compile before, now it works. > > Lets hope it isn't just a transient fix ! > > Norman. > > PS. By opening #0, instead of #3 in SS3, the 'stay on screen all the time' > and the 'Phantom window' faults have been removed - I now have a working > version. All I need to finish now is saving to pic format and getting my > head round the Aurora screen layout. > > Thanks to all who helped recently - much appreciated. > Hi, Thank you for sending me SS3. I just discovered the same problem: QLIB complained about DJTOOLKIT_BIN. I had to copy it to ram2_ and modify line 1010 accordingly. I modified line 2130 as well. 2130 DumpSize=ScreenWidth*(ScreenDepth*2) If ScreenDepth is not multiplied by 2, only the top half of the screen is snatched. I use QPC2 v2 high colour mode and the snatched file is 96 bytes long. Thank you for the time and work you have put in SS3!! François Van Emelen
RE: [ql-users] Screen Snatcher 3 - maybe !
Dilwyn wrote : >> only the top left of the screen on an Aurora is used. You should >> only save the actual number of bytes used for the screen resolution >> used, i.e. for mode 0 and mode 8, this is pixel_width DIV 4. Is this mode 0 the same as mode 4 then, or has Aurora got mode 0, 4 and 8 ? So I need something like the following : MyMode = DISPLAY_MODE if (MyMode = 0 or MyMode = 8) AND RunningOnAurora THEN do a loop to save DISPLAY_WIDTH(#0) DIV 4 bytes from the screen address for as many lines as SCR_YLIM else if (MyMode = 4) THEN do something else endif endif Thanks for the info on pic formats, I have got it somewhere at home, just not here at work. Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
RE: [ql-users] Screen Snatcher 3 - maybe !
Thanks Marcel. I knew you would know :o) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com >> It's true, all scr_ functions need a channel block in order to get the >> information (and open one themselves if there isn't any).
[ql-users] Qliberatore problems - SOLVED !
It's turning into a better week now ! I have now managed to solve the 'ambiguous name' errors with Qliberator when compiling Screen Snatcher. I had set dev2_ to be the location where I load and save to, and in the code, I had some $$asmb refernces to dev2_. Dilwyn pointed out that sometimes Qlib fails to find files etc up a devn_ device, so I changed my source to use the full path name and lo, it compiles every time so far. I hadn't changed anything, except the path names and where it failed to compile before, now it works. Lets hope it isn't just a transient fix ! Norman. PS. By opening #0, instead of #3 in SS3, the 'stay on screen all the time' and the 'Phantom window' faults have been removed - I now have a working version. All I need to finish now is saving to pic format and getting my head round the Aurora screen layout. Thanks to all who helped recently - much appreciated. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
