Re: [ql-users]QLiberator
On 19 Mar 2001, at 0:30, Q Branch wrote: > On another tack it seems I was wasting my time looking for faults with Q > 40 with regards to some of the problems with QLiberated programs. The > same problems can occur on QPC 2 so the fault must lie somewhere in the > colour drivers themselves. Now all we need to do is to find it and then > fix it. > I'm not sure whether it is the colour drivers or a memory question. I've noticed that on many occasions whena Qlib program refuses to work correctly, this is due to the fact that bit 31 of an address is set. Qlib program have a structure where some address is put into A0 and then a JMP or JSR is made to that address. This goes wrong on more modern machines, where high addresses are allowed... What I haven't found out, is why this doesn't happen EVRY time you start Qlib programs on the same machine... Wolfgang
Re: [ql-users]QLiberator
Wolfgang Lenerz wrote: > I'm not sure whether it is the colour drivers or a memory question. > I've noticed that on many occasions whena Qlib program refuses to > work correctly, this is due to the fact that bit 31 of an address is > set. That's right but shouldn't pose a problem to QPC. Marcel
Re: [ql-users]QLiberator
- Original Message - From: Wolfgang Lenerz <[EMAIL PROTECTED]> Subject: Re: [ql-users]QLiberator > I'm not sure whether it is the colour drivers or a memory question. > I've noticed that on many occasions whena Qlib program refuses to > work correctly, this is due to the fact that bit 31 of an address is > set. Qlib program have a structure where some address is put into > A0 and then a JMP or JSR is made to that address. This goes > wrong on more modern machines, where high addresses are > allowed... > > What I haven't found out, is why this doesn't happen EVRY time > you start Qlib programs on the same machine... > I have not come across this problem in practice, but is it something which only affects older (or badly written) QL-Liberated programs? Could it be something to do with the original basic? For example assuming that system variables begin at 163840? Or am I being too simple? SMSQ-E was fairly tolerant about this, but this could have changed with the colour drivers. Geoff Wicks [EMAIL PROTECTED]
Re: [ql-users]QLiberator
>I have not come across this problem in practice, but is it something which >only affects older (or badly written) QL-Liberated programs? Could it be >something to do with the original basic? For example assuming that system >variables begin at 163840? Or am I being too simple? SMSQ-E was fairly >tolerant about this, but this could have changed with the colour drivers. Well have found that there is something fairly consistent on my QPC 2 PC. If I edit my office program in QD and then call QLiberator using the QBASIC thing it will work the first time and compile the program. If I do it a second time it locks the QLiberator job. This happens every time I do this so I have to reboot and start again. I have not had too much time to try this out by just stating the Qliberator job on its own etc. but it does happen every time I try it. The same lock up with this happens on the Q40 but it happens every time so I do not get a chance for the first compilation. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/
Re: [ql-users]QLiberator
On 20 Mar 2001, at 19:00, Marcel Kilgus wrote: > That's right but shouldn't pose a problem to QPC. > > Marcel Oh, but it does: a jmp then give a wrong address error. Wolfgang
Re: [ql-users]QLiberator
On 20 Mar 2001, at 19:48, Geoff Wicks wrote: > I have not come across this problem in practice, but is it something which > only affects older (or badly written) QL-Liberated programs? Could it be > something to do with the original basic? For example assuming that system > variables begin at 163840? Or am I being too simple? SMSQ-E was fairly > tolerant about this, but this could have changed with the colour drivers. > I hjave noticed it with QLIB itself, and with Lonely Joker, and (much rarer) with e freshly compiled prog of my own. Wolfgang
Re: [ql-users]QLiberator
Wolfgang Lenerz wrote: >> That's right but shouldn't pose a problem to QPC. > Oh, but it does: a jmp then give a wrong address error. I though you're speaking of data accesses. Marcel
Re: [ql-users]QLiberator
On 22 Mar 2001, at 16:46, Marcel Kilgus wrote: > I though you're speaking of data accesses. > The problem, as I'e encountered it, is as follows: You start a QLiberated job. It hangs. Then you look at it with Jmon. You notice that it hangs in an infinite loop, at some instrcution which says: BRA.S . I know by experience, that this happens whenever the program has some kind of (irrecoverable) exception occurring. If you examine the stack, you can usually find out where the program came from, and you'll notice that it was in somme kind of loop, such as: MOVE.L D2 A0 JSR (A0). D2 (and A0) hae bit 31 set. IF you retry to step through the above uinstructions,under JMON, you get an address error. If you change D so that it poijnts to the same address, but without Bit 312 being set, it works, until the next time the prog goes through this kind of loop (where D2 generally poijts to another address, and bit 31is set - again. TRhis is where I generally give up, since QLiberated progs are all constructed on this model, and you'd have to wade through acres of code and it's not sure that you could find out why this bit is set. Wolfgang
RE: [ql-users] QLiberator problems - any ideas ?
Two minutes after sending the email below, I realised that the problem was because I didn't have the easy pointer apendix file for this application loaded in memory. Its been a while :o) Please ignore my previous pleas for help. (again !) Thanks. Norman.l 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 -Original Message- From: Norman Dunbar [mailto:[EMAIL PROTECTED]] Sent: Friday, March 23, 2001 1:27 PM To: QL (E-mail) Subject: [ql-users] QLiberator problems - any ideas ? I'm getting puzzled now !
Re: [ql-users] Qliberator & SMSQ - problems problems
In article <[EMAIL PROTECTED]>, Norman Dunbar <[EMAIL PROTECTED]> writes < Some details snipped ! > >All of a sudden, I get a screenful of 'ambiguous name' errors. All relating >to Q_ERR_ON/Q_ERR_OFF/Q_ERR/QX etc. The problem stays if I reset the whole >plot, and reload everything as above - now I cannot even compile it the >first time. > >I am one very puzzled (and p*ss*d off) programmer I can tell you. >Does QLiberator work under SMSQ - I've seen mentions of using bit 31 in >addresses etc, but my experiences today have been horrendous - I've wasted a >lunch hour and two (yes two) tea breaks trying to re-compile this program ! > >(I'm going off Malcolm now as well - he suggested the changed :o) - joke !) I can confirm that the compiled _obj file from QLib on the existing version of Snatcher2 works fine under SMSQ / QPC2v2. Not that this helps much if you can't successfully compile an _obj file in the first place :-( I have no experience of QLiberator, so over to others ... -- Malcolm Cadman
Re: [ql-users] Qliberator & SMSQ - problems problems
> > This could be because Qliberator is not able to run under SMSQ properly ; or > it could be because QPC2v2 doesn't like Qliberator; or > it could be both; or > it could be me being a complete idiot :o( ;or > something else altogether > > but . > > Start QPC2v2 and from a clean boot, (800 by 600 res, high colour mode) do > the following : > > lrespr win1_qlib_qlib_sys > qlib_use win1_qlib_, win1_qlib_ > > This loads and configure QLiberator, then the stuff for Screen Snatcher 2 > > > dev_use 2, win1_source_ss2_ > lrespr dev2_snatch_cde > lrespr dev2_snatch_cfg > > The _cde file is an EP3 appendix file holding the required menu and code > file to be compiled into the application, > the _cfg file is a BASCONFIG file holding the config block for the > application - again, to be compiled in. > > Load the application > > qload dev2_snatch > > and compile it > > liberate > set the options (no windows, +line numbers etc) > source file = dev2_snatch_sav > object file = dev2_snatch_obj > > No errors reported. > > Run it .. > > ex dev2_snatch_obj > > it works fine, except that it doesn't vanish from the screen when the > activate loose item is hit - I wonder why ? > > Change a line in the source file - makes no difference which one, then save > it ... > > qsave dev2_snatch > dev2_snatch_sav exists, overwrite Y/N > select Y to overwrite > > ALT P to find and pick the same version of QLiberator again for a recompile > Hit the COMPILE loose item > > All of a sudden, I get a screenful of 'ambiguous name' errors. All relating > to Q_ERR_ON/Q_ERR_OFF/Q_ERR/QX etc. The problem stays if I reset the whole > plot, and reload everything as above - now I cannot even compile it the > first time. > > I am one very puzzled (and p*ss*d off) programmer I can tell you. > Does QLiberator work under SMSQ - I've seen mentions of using bit 31 in > addresses etc, but my experiences today have been horrendous - I've wasted a > lunch hour and two (yes two) tea breaks trying to re-compile this program ! it seems things are a bit more complicated than a bit 31... UQLX did support 256 MB years ago but I have turned it off almost immediately because lots of software (including PE) didn't work with it. Bye Richard
Re: [ql-users] QLiberator problems - any ideas ?
- Original Message - From: Norman Dunbar <[EMAIL PROTECTED]> Subject: RE: [ql-users] QLiberator problems - any ideas ? > Two minutes after sending the email below, I realised that the problem was > because I didn't have the easy pointer apendix file for this application > loaded in memory. Its been a while :o) > All the same there may be some problems in high collour mode with QLiberator compiled Easyptr programs. Versions of QL-Thesaurus prior to 4.02 crash in high colour mode with a parameter out of range message. This is a bit of a puzzle as the only parameter is the window number, which does not cause problems elsewhere. Fortunately for me I discovered the code at this point was redundant, so the bug was easily fixed. It would be interesting to know if other people are having problems with Easyptr programs. I compile all my programs on an SMSQ (NOT SMSQ-E) QXL, and so far it is only QL-Thesaurus that has had a crash problem. BTW from Wolfgang's last message my theory about poorly written programs appears to be wrong. Geoff Wicks [EMAIL PROTECTED]
Re: [ql-users] Qliberator & SMSQ - problems problems
>This could be because Qliberator is not able to run under SMSQ properly ; or Unlikely, I never had a problem like this (I use it all the time) >it could be because QPC2v2 doesn't like Qliberator; or I refer the honourable gentleman to the reply given above ;-) >it could be both; or >it could be me being a complete idiot :o( ;or Knowing you, I doubt it ;-) >something else altogether > >but . > >Start QPC2v2 and from a clean boot, (800 by 600 res, high colour mode) do >the following : > >lrespr win1_qlib_qlib_sys >qlib_use win1_qlib_, win1_qlib_ Is this the only way to install QLiberator, or are there separate files for the compiler (must admit I use qlib_sys) >This loads and configure QLiberator, then the stuff for Screen Snatcher 2 > > >dev_use 2, win1_source_ss2_ >lrespr dev2_snatch_cde >lrespr dev2_snatch_cfg > >The _cde file is an EP3 appendix file holding the required menu and code >file to be compiled into the application, >the _cfg file is a BASCONFIG file holding the config block for the >application - again, to be compiled in. Some versions of Basconfig have a stack error after you have used the extensions to fetch the values, but as you and I fixed various problems with it, I guess we can discount that. >Load the application > >qload dev2_snatch > >and compile it > >liberate >set the options (no windows, +line numbers etc) >source file = dev2_snatch_sav >object file = dev2_snatch_obj > >No errors reported. > >Run it .. > >ex dev2_snatch_obj > >it works fine, except that it doesn't vanish from the screen when the >activate loose item is hit - I wonder why ? > >Change a line in the source file - makes no difference which one, then save >it ... > >qsave dev2_snatch >dev2_snatch_sav exists, overwrite Y/N >select Y to overwrite > >ALT P to find and pick the same version of QLiberator again for a recompile >Hit the COMPILE loose item > >All of a sudden, I get a screenful of 'ambiguous name' errors. All relating >to Q_ERR_ON/Q_ERR_OFF/Q_ERR/QX etc. The problem stays if I reset the whole >plot, and reload everything as above - now I cannot even compile it the >first time. This does indeed sound like the problems I reported a few days ago when trying to use MAX_CON in a procedure or function - some very strange and illogical things happened. I have noticed that if stack errors are introduced, SMSQ/E does seem to have more problems than QDOS did, although very often QDOS would just pretend nothing happened and crash later when you had little idea what you'd done wrong - SMSQ/E appears a little more fussy sometimes, but it's on the whole just that it's better at accurately reporting problems. If things seem to work fine on a 'clean' system it would seem to imply something like a crawling stack error. >I am one very puzzled (and p*ss*d off) programmer I can tell you. >Does QLiberator work under SMSQ - I've seen mentions of using bit 31 in >addresses etc, but my experiences today have been horrendous - I've wasted a >lunch hour and two (yes two) tea breaks trying to re-compile this program ! Never mind, you can have the TOR NT4 system at work which has driven me up the wall this week (although mustn't complain, the problems mean I'll have a nice bit of overtime this month) and I'll compile your program! (BTW, QPC2 v2 seems to work fine on the NT4 system, running OK from CD-ROM, as long as I don't try to save any configuration changes of course) >(I'm going off Malcolm now as well - he suggested the changed :o) - joke !) Are you sulking Malcolm ;-) -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Qliberator & SMSQ - problems problems
On 3/23/01 at 8:37 PM Richard Zidlicky wrote: >it seems things are a bit more complicated than a bit 31... UQLX did >support 256 MB years ago but I have turned it off almost immediately >because lots of software (including PE) didn't work with it. > >Bye >Richard Well, I was told that code and data accesses should actually ignore the top three bits (29, 30, 31). In other words, any combination of bits 29, 30, 31, should effectively act as if those bits are 000. Please someone tell me that's how it's supposed to be because the GF design relies heavily on this fact, the whole address map is constructed around it! Nasta
Re: [ql-users] Qliberator & SMSQ - problems problems
On 23 Mar 2001, at 17:00, ZN wrote: > > Well, I was told that code and data accesses should actually ignore the top > three bits (29, 30, 31). In other words, any combination of bits 29, 30, > 31, should effectively act as if those bits are 000. > Please someone tell me that's how it's supposed to be because the GF design > relies heavily on this fact, the whole address map is constructed around > it! On the original QL, it does. Actually, since you're building the hardware, you can determine this yourself : does referring to a non existing address (with bits 29,30,31 set) cause an exception or not? If you map the hardware so that it always ignores this and doesn't cause an error, then you have no problems! Wolfgang
Re: [ql-users] QLiberator problems - any ideas ?
Geoff Wicks wrote: > All the same there may be some problems in high collour mode with QLiberator > compiled Easyptr programs. Versions of QL-Thesaurus prior to 4.02 crash in > high colour mode with a parameter out of range message. This is a bit of a > puzzle as the only parameter is the window number, which does not cause > problems elsewhere. Fortunately for me I discovered the code at this point > was redundant, so the bug was easily fixed. It would be interesting to know > if other people are having problems with Easyptr programs. > Easysource_exe and Easysprite_exe (Easyptr package) won't run in high colour mode. Datadesign locks in high colour mode when asking info about the opened ddf-file (F3 followed by a). François Van Emelen > I compile all my programs on an SMSQ (NOT SMSQ-E) QXL, and so far it is only > QL-Thesaurus that has had a crash problem. > > BTW from Wolfgang's last message my theory about poorly written programs > appears to be wrong. > > Geoff Wicks > [EMAIL PROTECTED]
Re: [ql-users] Qliberator & SMSQ - problems problems
On Fri, Mar 23, 2001 at 05:00:31PM -0500, ZN wrote: > Well, I was told that code and data accesses should actually ignore the top > three bits (29, 30, 31). In other words, any combination of bits 29, 30, > 31, should effectively act as if those bits are 000. > Please someone tell me that's how it's supposed to be because the GF design > relies heavily on this fact, the whole address map is constructed around > it! depends on the degree of compatibility you are trying to achieve, for some software everything above 16 MB must be wrapped down. You can play with UQLX and Minerva to see the effects. A programmable MMU helps of course. Bye Richard
Re: [ql-users] Qliberator & SMSQ - problems problems
On 3/24/01 at 2:13 PM Richard Zidlicky wrote: >> Well, I was told that code and data accesses should actually ignore >> the top three bits (29, 30, 31). In other words, any combination of >> bits 29, 30, 31, should effectively act as if those bits are 000. > >depends on the degree of compatibility you are trying to achieve, >for some software everything above 16 MB must be wrapped down. >You can play with UQLX and Minerva to see the effects. >A programmable MMU helps of course. OK, any examples of software that needs 16Mb wrapping (or 32, 64, 128, 256)? The GF memory map is 512Mb, wrapped 8 times within the 4G address range. It's roughly divided into 128M RAM, 128M I/O, a 128M copy of the RAM (with cache disabled), and a 128M copy of the IO with cache disabled. Doing a wrap of everything ino 16M would be rather pointless since the evey key feature implemented on the GF could not be implemented any more. Nasta
Re: [ql-users] Qliberator & SMSQ - problems problems
ZN wrote: > Well, I was told that code and data accesses should actually ignore the top > three bits (29, 30, 31). In other words, any combination of bits 29, 30, > 31, should effectively act as if those bits are 000. According to my knowledge this is fine. QPC ignores the top 4 bits, but that shouldn't make much difference. Marcel
Re: [ql-users] Qliberator & SMSQ - problems problems
In article <002c01c0b3da$709613e0$8c075cc3@default>, Dilwyn Jones <[EMAIL PROTECTED]> writes >>(I'm going off Malcolm now as well - he suggested the changed :o) - >joke !) > >Are you sulking Malcolm ;-) No :-) ... I know that if anyone can solve it, the experts on this list will :-) Interesting, though, that this challenge is bringing problems to light, re QDOS and SMSQ. -- Malcolm Cadman
Re: [ql-users] Qliberator & SMSQ - problems problems
On Sat, Mar 24, 2001 at 09:34:50AM -0500, ZN wrote: > On 3/24/01 at 2:13 PM Richard Zidlicky wrote: > > >> Well, I was told that code and data accesses should actually ignore > >> the top three bits (29, 30, 31). In other words, any combination of > >> bits 29, 30, 31, should effectively act as if those bits are 000. > > > >depends on the degree of compatibility you are trying to achieve, > >for some software everything above 16 MB must be wrapped down. > >You can play with UQLX and Minerva to see the effects. > >A programmable MMU helps of course. > > OK, any examples of software that needs 16Mb wrapping (or 32, 64, 128, > 256)? it is pretty long I have done the experiments and I have stopped after findning that not even PE worked. No idea what else would not work. Bye Richard
Re: [ql-users] QLiberator problems - any ideas ?
FrançoisVan Emelen writes: > Easysource_exe and Easysprite_exe (Easyptr package) won't run in high > colour mode. > Datadesign locks in high colour mode when asking info about the opened > ddf-file (F3 followed by a). Youre right :( And EZmenu totters. All in all, my QL now crashes more than 100 times more frequently than W2k - were ahead again! I dont mind too much, because Im sure itll get sorted out eventually - its been like this with every major development, from AH (and its unspeakable predecessors) to JS; from "JM" thru the A, B and C drivers for the Atari, etc. It would be worrying if essential programs such as Qlib, EZptr and others were no longer being upgraded. What is the status on ezptr? Is there any news on Qlib? Per
RE: [ql-users] Qliberator & SMSQ - problems problems
Dilwyn wrote : >> Is this the only way to install QLiberator, or are there separate >> files for the compiler (must admit I use qlib_sys) It's the way I've always done it anyway. Seems to be the way the manual tells me to do it as well. I don't think the problem is with loading QLiberator itself, more that it seems to get it's knickers in a twist for no reason and becomes unstable. (Or is that just me becoming unstable :o) ) >> Some versions of Basconfig have a stack error after you have used the >> extensions to fetch the values, but as you and I fixed various >> problems with it, I guess we can discount that. I'm not actually using the DLJ/ND patched version of Basconfig because I'm using the original (working) Basconfig generated code file from the working version of SS2 as per your web site :o) >> This does indeed sound like the problems I reported a few days ago >> when trying to use MAX_CON in a procedure or function - some very >> strange and illogical things happened. Could be, but I'm not using MAX_CON :o( >> (BTW, QPC2 v2 seems to work fine on the NT4 system, running OK from >> CD-ROM, as long as I don't try to save any configuration changes of >> course) I'm using it at work on NT4 - works fine for me :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
RE: [ql-users] Qliberator & SMSQ - problems problems
Per a sav file header is as follows : 4 byte header = Q1 plus CHR$(0) + CHR$(0) OR 4 byte header = Q1 plus CHR$(2) + CHR$(192) Word = Number of entries in the name table Word = Name table length Word = Number of program lines I have a utility 'wot I wrote' years ago to decode a SAV file which you can have if you want. (That applies to anyone) I don't know if the Minerva versions are compatible - but I would have thought so (They all run on SBASIC don't they ?) As for the QLib stuff, I have an 8K database and an 8K stack space, I have 6 channels reserved (But I only ever use one !) HTH 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 -Original Message- From: P Witte [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 27, 2001 12:12 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Qliberator & SMSQ - problems problems >> Does anyone know the qsave sav-file format? I know most of it, but dont >> understand the significance of the second word (version or facilities?), nor >> some of the extra bits in the variable types' top nibble. Are files qsaved >> on Minerva interchangable with SMSQ ones (integer tokenisation, etc)? Per
RE: [ql-users] Qliberator & SMSQ - problems problems
PS. The sav file format is identical (?) to the internal tokenised version of a SuperBasic program - see Jan Jones for full details, (Or my source code which is hopefully readable - failing that I shall document it !) 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 -Original Message- From: P Witte [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 27, 2001 12:12 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Qliberator & SMSQ - problems problems >> Does anyone know the qsave sav-file format?
Re: [ql-users] Qliberator & SMSQ - problems problems
Norman Dunbar writes: <> > I am one very puzzled (and p*ss*d off) programmer I can tell you. > Does QLiberator work under SMSQ - I've seen mentions of using bit 31 in > addresses etc, but my experiences today have been horrendous - I've wasted a > lunch hour and two (yes two) tea breaks trying to re-compile this program ! > > (I'm going off Malcolm now as well - he suggested the changed :o) - joke !) > > Any Ideas anyone ? Here are some of my spells: I find a lot of the Qlib problems Ive had (and solved) have had to do with the Qlib stack getting into a mess, and hanging the program or the whole environment, due to lack of memory. Perhaps the stack underflows into the channel table, or something.. Anyway, by increasing the number of channels, eg using the $$chan directive, most weird errors and myserious lockups seem to vanish. Nowadays I add at least two to the number of channels actually used. The $$stac directive also plays a part, so on compiling a new program for the first time, I keep both chan and stac big, and then work my way down (with the aid of the compile-with-stats facility at the main console) until the program starts playing up. Then I add a good dollop of space back in. I find with the new colour drivers some(?) programs seem to require more stack space than previously. BTW I use V2.35. Id say its compatible on the whole. Isnt there a V2.36? Does anyone know the qsave sav-file format? I know most of it, but dont understand the significance of the second word (version or facilities?), nor some of the extra bits in the variable types' top nibble. Are files qsaved on Minerva interchangable with SMSQ ones (integer tokenisation, etc)? Per
