Re: [ql-users] Turbo v4g21
In a message dated 02/05/05 18:07:18 GMT Daylight Time, [EMAIL PROTECTED] writes: snip I have not tried Turbo on a lower machine than AM Rom plus trump card. You mean AH don't you (8-)# I mean JM. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
In a message dated 01/05/05 10:39:55 GMT Daylight Time, [EMAIL PROTECTED] writes: Hi George, I have downloaded the new Yurbo v4g21, I will try it on all my programs on the Q60, QXl, QPC2, Atari QL, Trump Card QL... I would like you to keep in the backwards compatibility within Turbo, as there are still people using a QL that do not use SMSQ/E and GD2. I think that the backwards compatabilty is important to support these users. What is the minimum specification of QL that is required to use Turbo now. Derek I have not tried Turbo on a lower machine than AM Rom plus trump card. AFAIK it would only be size of ram that would stop it working on an unexpanded QL. I agree totally that backwards compatibility is essential and I always have that in mind. Cheers George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
On Mon, 2 May 2005 at 06:10:12, wrote: (ref: [EMAIL PROTECTED]) snip I have not tried Turbo on a lower machine than AM Rom plus trump card. You mean AH don't you (8-)# Tony -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
AM roms... they must a morning rom... Derek Tony Firshman wrote: On Mon, 2 May 2005 at 06:10:12, wrote: (ref: [EMAIL PROTECTED]) snip I have not tried Turbo on a lower machine than AM Rom plus trump card. You mean AH don't you (8-)# Tony ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
Bill, does Joe still have the QL meetings at his Computer Shoppe' Derek Bill Waugh wrote: - Original Message - From: Derek Stewart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 02, 2005 6:18 PM Subject: Re: [ql-users] Turbo v4g21 Presumable there is no PM rom because THERE JUST IS'NT ALRIGHT All the best - Bill AM roms... they must a morning rom... Derek Tony Firshman wrote: On Mon, 2 May 2005 at 06:10:12, wrote: (ref: [EMAIL PROTECTED]) snip I have not tried Turbo on a lower machine than AM Rom plus trump card. You mean AH don't you (8-)# Tony ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.0 - Release Date: 29/04/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
- Original Message - From: Derek Stewart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 02, 2005 6:36 PM Subject: Re: [ql-users] Turbo v4g21 Bill, does Joe still have the QL meetings at his Computer Shoppe' Derek Sadly no, the North East sub group is to all purposes no more. I have considered visiting the Scottish sub group at some point but time and distance. Shame All the best - Bill ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
Hi George, I have downloaded the new Yurbo v4g21, I will try it on all my programs on the Q60, QXl, QPC2, Atari QL, Trump Card QL... I would like you to keep in the backwards compatibility within Turbo, as there are still people using a QL that do not use SMSQ/E and GD2. I think that the backwards compatabilty is important to support these users. What is the minimum specification of QL that is required to use Turbo now. Derek [EMAIL PROTECTED] wrote: In a message dated 30/04/05 16:37:59 GMT Daylight Time, [EMAIL PROTECTED] writes: There is one more change that I have made. That is in the choice of stack size. EasyPtr and QPTR extensions need more stack than the 350 bytes default. You Could the problems I mentioned to you in a private mail (lots of inexplicable run-time errors) relate to this issue, do you think? I know, I could just try and figure it out for myself ;) but Im shortly going away for a week, and perhaps others are struggling with the same problem.. The effects of overwriting items in dataspce because the stack is too small are unpredictable. I have usually found that it is particularly hard to debug these programs. It is therefore a good idea to bear in mind that some S*BASIC extensions use much more stack than normal. This is true of QPTR and, I think, EasyPtr as well. Incidentally I think it would a good idea if a register were available showing those extensions which needed a stack size of over, say, 250 bytes. I have also looked at PEEK(!! etc) which allow easy access to system variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and POKE are dealt internally by Turbo which is much faster than calling the rom versions. It would not be easy to allow for the !! and \\ variations. However, the system variables is found at SYS_VARS so a slightly extended PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several BASIC_xxx functions which should cover a lot od the PEEK(\\ ...) ground. Im aware of SYS_VARS and BASIC_xxx, but Turbo is supposed to be a S*Basic compiler, not a language of its own (this is the nature of one of the arguments I had with Freddy, who appeared to be arguing that it was SuperBasic that was incompatible!) I don't think it will ever be the case that Turbo can compile all programs written in S*BASIC. If that did come about I guess that the speed advantage would disappear and that it would be just as fast running the program in S*BASIC. PEEK and POKE are examples of this. Instead of calling the machine code Turbo does it internally. Since only two or three assembler instructions are needed this is much faster. There are three areas where, at the moment, programs written to be compiled by Turbo are restricted. 1. DATA lines must contain just pure numbers or strings. 2. Variable names can't be used in different places with a different number of dimensions. 3. Some integer arithmetic requires careful handling. In some cases Turbo assumes that the result will be an integer where S*BASIC assumes floating point. This shows that Turbo does not aim to compile ALL S*BASIC programs. I understand that this could be a wee bit problematic, as these variants arent SuperBasic. However, Turbo is in a state of flux at the moment it might be an idea to lay a couple of DP issues to rest now. Afterall, much of the duplication in Turbo was to try to overcome some of the limitations in the original QDOS ROMs. Im thinking of things like EXECUTE_x and.. well, I can remember just now (Im in a bit of a hurry). The place to compensate for the differences between SBasic and SuperBasic is in their respective Turbo toolkit extenstions. I would stringly advise against using EXECUTE_x. The reason is that as they stand they make no allowance for parameter strings. EX, EW etc all increase the dataspace to accommodate any parameter string supplied, and the length can be up to 32K. The EXECUTE_x instructions do not make that allowance. It is therefore possible to overwrite the compiled program and probably several neighbouring ones as well by : a$=FILL$( ,32000) EXECUTE_W;a$ So, why not get rid of EXECUTE_xx, BASIC_xx and all that and try to simplify things by reducing the number of different ways of achieving the same thing? Sbasic has some 400+ commands already! and Turbo_tk_code has 111 commands. Many people only use about 2000 words in their daily communications, so this combination might imply that learning Sbasic and Turbo is only about 25% as difficult as learning an entirely new language. Probably not a meaningful comparison, but you catch my drift? I certainly would not want to throw away BASIC_xx becasue they are used in parser_task itself! I am not sure why having several extensions doing the same thing (or nearly the same thing) is to be avoided. In GWASS I have several different names for the same command. For example ENDIF and END_IF are exactly equivalent. There has been much talk of maintaining backward
Re: [ql-users] Turbo v4g21
In a message dated 28/04/05 19:44:51 GMT Daylight Time, [EMAIL PROTECTED] writes: Turbo is about to take off, I believe. Id recommend those who gave up on it many years ago to take a look at it now! There is one more change that I have made. That is in the choice of stack size. EasyPtr and QPTR extensions need more stack than the 350 bytes default. You can at the moment configure codegen_task to give more, up to 2048. Marcel thinks that may not be enough. I myself don't much like having to re-configure codegen_task every time I want a different amount of stack. A large stack needs a large data space, which results in a bigger compiled program. The change I have made is to allow TURBO_objstk (a new Turbo TK Code extension) to set a default stack size which can be changed in Turbo's front panel. The size of stack can be set from 350 to 9998 bytes. This new version will require an update of Turbo TK code if TURBO_objstk is to be used, though the front panel can be used to set the stack without it. I have also looked at PEEK(!! etc) which allow easy access to system variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and POKE are dealt internally by Turbo which is much faster than calling the rom versions. It would not be easy to allow for the !! and \\ variations. However, the system variables is found at SYS_VARS so a slightly extended PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several BASIC_xxx functions which should cover a lot od the PEEK(\\ ...) ground. I hope soon to send out Turbo v4h21. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
George Gwilt writes: There is one more change that I have made. That is in the choice of stack size. EasyPtr and QPTR extensions need more stack than the 350 bytes default. You Could the problems I mentioned to you in a private mail (lots of inexplicable run-time errors) relate to this issue, do you think? I know, I could just try and figure it out for myself ;) but Im shortly going away for a week, and perhaps others are struggling with the same problem.. I have also looked at PEEK(!! etc) which allow easy access to system variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and POKE are dealt internally by Turbo which is much faster than calling the rom versions. It would not be easy to allow for the !! and \\ variations. However, the system variables is found at SYS_VARS so a slightly extended PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several BASIC_xxx functions which should cover a lot od the PEEK(\\ ...) ground. Im aware of SYS_VARS and BASIC_xxx, but Turbo is supposed to be a S*Basic compiler, not a language of its own (this is the nature of one of the arguments I had with Freddy, who appeared to be arguing that it was SuperBasic that was incompatible!) I understand that this could be a wee bit problematic, as these variants arent SuperBasic. However, Turbo is in a state of flux at the moment it might be an idea to lay a couple of DP issues to rest now. Afterall, much of the duplication in Turbo was to try to overcome some of the limitations in the original QDOS ROMs. Im thinking of things like EXECUTE_x and.. well, I can remember just now (Im in a bit of a hurry). The place to compensate for the differences between SBasic and SuperBasic is in their respective Turbo toolkit extenstions. So, why not get rid of EXECUTE_xx, BASIC_xx and all that and try to simplify things by reducing the number of different ways of achieving the same thing? Sbasic has some 400+ commands already! and Turbo_tk_code has 111 commands. Many people only use about 2000 words in their daily communications, so this combination might imply that learning Sbasic and Turbo is only about 25% as difficult as learning an entirely new language. Probably not a meaningful comparison, but you catch my drift? There has been much talk of maintaining backward compatibility with Qdos. Also, lowering the threshhold for any potential newcomers (fat chance!) would be great. Here is a chance of doing that. The toolkit is something I would be willing to help with. (In fact I already have written a toolkit or two to fill in some of the gaps between Qdos and Smsqe.) I hope soon to send out Turbo v4h21. Bring it on! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
In a message dated 27/04/05 13:12:26 GMT Daylight Time, [EMAIL PROTECTED] writes: Marcel Kilgus writes: First of all I'd like to note that whatever feature I thought it would be cool if Turbo could do this Turbo could already do, one just has to read the documentation. Just is a pretty big word here ;) But you are right! I wonder if anyone else thinks that the Turbo Manual is perhaps too long. I myself would like a condensed version of what it can do. I have tried to provide that for the additional features for which I was responsible in the Changes file. 200 IF NOT(COMPILED) THEN 210 LRESPR win1_easy_app_appman_cde 220 LRESPR win1_easy_app_fapp_cde 230 LRESPR win1_easy_app_mkapp_cde 240 LRESPR win1_easy_app_qcfx001_cde 250 END IF From my quick skim through the documentation Id say 200 DEBUG 9 210 LRESPR win1_easy_app_appman_cde 220 LRESPR win1_easy_app_fapp_cde 230 LRESPR win1_easy_app_mkapp_cde 240 LRESPR win1_easy_app_qcfx001_cde 250 DEBUG 0 was much better, as that code would then not appear in the binary. Super! I am glad that someone else has thought of using this technique which I use in Parser itself. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
Something nice and terse for reference in true Tebby style would be handy (too?) However, Im not volunteering.. (Nothing - as one of Dilwyn's collections of sage sayings has it - is impossible for the man who doesnt have to do it himself ;) Don't. Reminds me too much of my boss at work. -- Dilwyn Jones -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.18 - Release Date: 19/04/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
Marcel Kilgus wrote: Just to see how Turbo developed I tried to compile EasyPtr's AppMan with it. I'd like to tell some of my quest in case anybody else wants to try it, too. First of all I'd like to note that whatever feature I thought it would be cool if Turbo could do this Turbo could already do, one just has to read the documentation. This has been mentioned to me already. Many people using the current Turbo are working from memory or from DP's old documentation. So much has changed that you really need to download and familiarise with the new documentation. Some of the compiler directives were introduced by Chas Dillon in later versions of Turbo sold by Freddy of DP Ltd but generally not documented or only in readme files. AT some point, the various people who've been involved with the project to update Turbo and its documentation (David Gilham, Mark Knight, George Gwilt, Tim Swenson etc) have introduced new documentation for facilities which were either undocumented before or which have since been introduced in the compiler and toolkit by George, David and Mark Knight. [snip] from a software engineer point of view I actually prefer the way Turbo works, because it can prevent bugs in the code. The downside is that some code probably needs to be rewritten, but usually it's sufficient to just rename some variables, so should not be that big a deal. I think Freddy and Simon Goodwin said this to some extent in the past when people were critical that Turbo was stricter and less changes were needed for a QLib compiled program. As you say, although Turbo is stricter, once you get used to it, you start to appreciate it does make for better programming in the end. Above all, George is improving Turbo at such a rate and QLiberator is not being updated at the moment, plus Turbo is free of course, so it will soon be a potential replacement for QLiberator. I will be watching this with interest, I make heavy use of QLiberator+Easyptr so once I feel Turbo can compile my programs and I have familiarised enough with the new facilities it's quite likely I'll look at using Turbo to compile easyptr apps. I hope this description might help some people get a start with Turbo, I personally am not a big Basic programmer myself but it looks to me as though Turbo gets ready for prime time. Indeed. The time and thought you've clearly put into this one subject alone is greatly appreciated. The level of work you've put into Easyptr and which George has put into Turbo and its companion programs is fantastic. You both seem unable to resist challenges! Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
Marcel Kilgus writes: First of all I'd like to note that whatever feature I thought it would be cool if Turbo could do this Turbo could already do, one just has to read the documentation. Just is a pretty big word here ;) But you are right! 200 IF NOT(COMPILED) THEN 210 LRESPR win1_easy_app_appman_cde 220 LRESPR win1_easy_app_fapp_cde 230 LRESPR win1_easy_app_mkapp_cde 240 LRESPR win1_easy_app_qcfx001_cde 250 END IF From my quick skim through the documentation Id say 200 DEBUG 9 210 LRESPR win1_easy_app_appman_cde 220 LRESPR win1_easy_app_fapp_cde 230 LRESPR win1_easy_app_mkapp_cde 240 LRESPR win1_easy_app_qcfx001_cde 250 DEBUG 0 was much better, as that code would then not appear in the binary. Super! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Turbo v4g21
Just to see how Turbo developed I tried to compile EasyPtr's AppMan with it. I'd like to tell some of my quest in case anybody else wants to try it, too. First of all I'd like to note that whatever feature I thought it would be cool if Turbo could do this Turbo could already do, one just has to read the documentation. It's for example very convenient that all compiler settings can be specified in the BASIC program itself. It pissed me off to no end that I couldn't specify the No winds option, or the job name in Qliberator on a per-program basis. With Turbo it's all there: 100 TURBO_objfil 'ram1_appman' - name of resulting EXE file 110 TURBO_taskn 'APPMan4' - job name 120 TURBO_diags 2 130 TURBO_windo 0 - No winds 140 TURBO_objdat 32- Dataspace size 150 TURBO_buffersz 64 160 REMark %%win1_easy_app_appman_cde,4,82 170 REMark %%win1_easy_app_fapp_cde,0,4 180 REMark %%win1_easy_app_mkapp_cde,0,10 190 REMark %%win1_easy_app_qcfx001_cde,0,10 200 IF NOT(COMPILED) THEN 210 LRESPR win1_easy_app_appman_cde 220 LRESPR win1_easy_app_fapp_cde 230 LRESPR win1_easy_app_mkapp_cde 240 LRESPR win1_easy_app_qcfx001_cde 250 END IF The REMark lines will be quite familiar to QLiberator users and they work exactly the same as $$asmb. With the settings all in the basic file a simple charge , command will automatically compile and create the resulting EXE file. Another feature that I missed for example in Qliberator was support for hexadecimal values using the $ notation. I thought I should probably ask George to include support for them. Once again, after browsing the changes files I saw that Turbo already supports them... After that AppMan did already start, but when trying to access the Files menu the line 1760 MITEM#wdef1,-9,,appnum$ gave an error not found. Changing it to 1760 MITEM#wdef1,-9,0,appnum$ helped, so not much of a problem, but I've told George about it and he has fixed it in 4e21. After this the files menu opened up, I could select something, the file select menu opened up, it loaded the appendix and then booom, another problem. Turned out some variable values were really messed up. To make a very long story short: the application did simply run out of stack space on the file select call and subsequently overwrote some variables of the program. If you do compile programs for EasyPtr, make sure to crank up the stack by configuring codegen_task to a higher value (using MenuConfig). 1024 should be pretty safe, but 2048 can't do any harm either. In any case, Turbo was working correctly, tough a higher default value might be in order. After THAT I could load an appendix and... Sysmon went mad about a memory corruption. God, those are hard to track down! To make an equally long story short, Appman simply had a bug that corrupted the heap! Why it didn't show up in SBasic or in the Qliberated version I don't know, probably chance, but once again Turbo was just fine. After that there was a problem with the MINPUT function of EasyPtr. It has to do with the way Turbo handles strings (only fixed dimensioned strings which EasyPtr didn't accept) but I could easily make the EasyPtr Basic extension compatible, so that's fine then, too. Please note that this EasyPtr version has not yet been released but might be acquired if you really need it. And that really was all of it, Appman works now as fine with Turbo as it did with Qlib, so I think it's really time for you to check out Turbo, too. ;-) This was all some weeks ago, today I did a quick check of the array slicing and it seemed to work perfectly well, too! Well done. One more thing, I tried to compile a very large EasyPtr program with Turbo and got hundreds of errors. The reason being that the same variable names sometimes had different definitions, like 100 DIM a$(10,10): REMark a$ two dimensional 110 Test 120 : 130 DEFine PROCedure Test 140 LOCal a$: REMark a$ is one-dimensional 150 a$=xyz 160 PRINT a$ 170 END DEFine This will be honoured by Turbo with the error ERROR at 100: Ambiguous declaration of name. and some errors ERROR at 150: Ambiguous name used. The reason is simple, consider the extended version of this program 100 DIM a$(10,10) 110 Test 120 Test2 130 : 140 DEFine PROCedure Test 150 LOCal a$ 160 a$=xyz 170 PRINT a$ 180 Test2 190 END DEFine 200 : 210 DEFine PROCedure Test2 220 PRINT a$ 230 END DEFine I guess Turbo cannot know what code to produce for Test2. When called from line 120, a$ is two-dimensional, when called from Test, a$ is one- dimensional. SBasic handles this at runtime, but from a software engineer point of view I actually prefer the way Turbo works, because it can prevent bugs in the code. The downside is that some code probably needs to be rewritten, but usually it's sufficient to just rename some variables, so should not be that big a deal. I hope this description might help some people get a start with Turbo, I
Re: [ql-users] Turbo v4g21
In a message dated 25/04/05 01:49:17 GMT Daylight Time, [EMAIL PROTECTED] writes: Spurred by Per, I have produced a version of Turbo which allows slicing of arrays used as parameters of machine code extensions. Turbo v4g21 should be on the SQLUG site in a few days. When you say spurred I hope you mean encouraged rather than bullied ;) Certainly encouraged. The more difficult a project appears to be the more it appeals to me. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
George Gwilt writes: Spurred by Per, I have produced a version of Turbo which allows slicing of arrays used as parameters of machine code extensions. Turbo v4g21 should be on the SQLUG site in a few days. When you say spurred I hope you mean encouraged rather than bullied ;) Certainly encouraged. The more difficult a project appears to be the more it appeals to me. Last week I tried Turbo again, but most of my programs woudnt compile due to the lack of array slicing. However, those were the only errors that showed up, so Im really hopeful ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Turbo v4g21
Spurred by Per, I have produced a version of Turbo which allows slicing of arrays used as parameters of machine code extensions. Turbo v4g21 should be on the SQLUG site in a few days. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4g21
George Gwilt writes: Spurred by Per, I have produced a version of Turbo which allows slicing of arrays used as parameters of machine code extensions. Turbo v4g21 should be on the SQLUG site in a few days. When you say spurred I hope you mean encouraged rather than bullied ;) Looking forward to try it out! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
