[ql-users] Lost messages [was Turbo]
I never saw the message jms1 was answering with his message below. In fact this is the first message Ive seen since 18/08 from Duncan Neithercut. Is this a symptom of a general problem or just local to me? Per - Original Message - From: jms1 [EMAIL PROTECTED] To: Fabrizio Diversi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 12:32 AM Subject: Re: [ql-users] Turbo Thank you for pointing out the error. Should be alright now. John - Original Message - From: Fabrizio Diversi [EMAIL PROTECTED] To: John Sadler [EMAIL PROTECTED] Sent: Sunday, August 21, 2005 4:46 PM Subject: Re: [ql-users] Turbo Hello, maybe I am wrong, but the link to Trbot07_zip on the SQLUG web site is missing. I download the latest Turbo but i am not able to download TK ves 3.37. Many thanks and ciao. Fabrizio - Original Message - From: jms1 [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 07, 2005 11:54 AM Subject: [ql-users] Turbo ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Size for QXL.win Files
Nasta writes: If you want to be absolutely sure, 1G QXL.WIN, with 32k allocation block size is the way to go, it avoids all the possible pitfalls... Actually a 1G QXL.WIN drive (cant we find a better name for QXL.WIN files? How about just Win files?) has an allocation block size of 16k; 2G has 32k. As you say, there is some confusion about whether the allocation block counter is signed or not. I think I have read a Win file that was 4G, but QPC2 wont create them. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Size for QXL.win Files
John Gilpin writes: 4Gb per QXL.win file is more than enough for me! I just didn't want to set it all up then find I had overstepped the mark. (I will probably set up three or four 1Gb files and see how it goes. - my BIG Hard drive is about 80Gb in total ). I only get 2GB with QPC2: FORMAT win8_4000 fails while win8_2000 doesnt. Even then the file allocation block is a massive 32k. It seems to me that 4GB must be the theoretical limit for the current mapping scheme. The minimum space taken by a file on disk would then be a whopping 64k Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SERNET (help required)
wolfgang mühlegger writes: Can anyone point me to the Sernet V2.25 manual? I want to know the meaning of the keywords and parameters. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm hi, AFAIR is a textfile on the qpc program-disk and another 2 textfiles can be found on the QLT-Cover CD i could send them 2 you if you still require them. Thanks to you and François Van Emelen. I found the one in the SMSQE manual, but its not uptodate. Please send the files. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SERNET (help required)
Do I hear the distant hum of busy QLs - or is it just tinnitus? Can anyone point me to the Sernet V2.25 manual? I want to know the meaning of the keywords and parameters. Per ___ 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
[ql-users] list bug
Dilwyn Jones must have written: [EMAIL PROTECTED] wrote: It's geared up for people with always-on connections. Dial up users have to force it to update unless they happen to be online when AVG7 reckons it's time to update. It normally tries to update every 2 days and normally has downloads of anything from 150K to 2MB of updates every time. .. but it never arrived in my inbox! Has anyone else experienced this sort of thing? Also, some days ago I wrote: 250 END IF From my quick skim through the documentation Id say 200 DEBUG 9 however, I never put the in front of the line From my quick.. and it also doesnt show up in my copy of the file that was actually sent. Any idea wots going on? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] www.kilgus.net updated
Hi Marcel, I cant download (error 404: Datei nicht gefunden!). Can you check whether the link is working, please? Per - Original Message - From: Marcel Kilgus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 29, 2005 3:31 PM Subject: Re: [ql-users] www.kilgus.net updated Marcel Kilgus wrote: I'd just like to inform you that a somewhat bigger update has happened to www.kilgu.net. Of course thats www.kilgus.net ... Marcel ___ 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] Internet on the QL
. writes: BTW: Due to the birth of my son I realise that I haven't uploaded the Congratulations!! appropriate files (as promised in the article) to my webserver. These will be put there later tonight for everyone to download. If you download these qxl.win files you can ensure that the programs therein are fully tested and guaranteed to work with all three emulators: QPC II v.3.30 and later, QemuLator v.2.3.2 and greater (Expanded registration ONLY) and uQLx (*NIX and Mac editions but NOT Windows). They also have a good set of gnu tools and other unix ported commands as well as a fully set up Shell so you can unixify your QDOS experience (I refer you to Tim Swenson's article on a previous QLT... check Dilwyn's site for the exact volume/issue) That would be nice, yes. Would you also be able to put up a non-RARified version of win32uQLx? Afterall, zip is the current standard archiving method on win32.. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Internet on the QL
Dilwyn Jones writes: -- 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 Look at the nasty virus youve got on your computer. Probably trying to shame you into forking out more dosh. What lowlife! Time to get something better, dont you think? Per ___ 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
Re: [ql-users] Just an idea for a new Product.....
David Tubbs writes: You, Per, don't convince me you have not solved someone else's problem with taking top payscale. Never done work for local community, or worked for a charity ? Im not sure I catch your drift, but Ive spent most of my working life in unwaged positions, in so-called ideal communities. If I didnt believe in what I do I would be a rather sad monkey. You either need to believe in what you do or get paid (lucky are those who have it both ways ;) Therefore I understand the nature of the contribution a number of people in the QL community make to keep it all ticking over and that is why it irkes me when people appear to rubbish those efforts. Sheer ignorance, of course. The way I see it, it works the other way round too: Either you contribute, or you pay. If for valid reasons you are not able to do either, you appreciate. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] was... Just an idea for a new Product.....
Dilwyn Jones writes: QPAC2 is NOT as many assume a more recent version of QPAC1! But strangely enough QPAC2 is a successor to QRAM for all practical purposes. However, most Qram utilities no longer work with the versions of PE that came with and after Qpac2. The general advice seems to be to decide if you want maximum compatibility with older QL software, stick with QDOS, or if you want the benefits of the new facilities available under SMSQ/E you will need to go down that route. But only if you want maximum compatibility. Most old programs will run, or can be made to run, under PE. It is often not PE which is the problem with older programs, rather their reliance on microdrives, or a reliance on fixed locations for the screen or systems variables (ie poor programming practises). Also upping the speed can render some old programs incompatible. Apart from those emulators that are designed to be hardware compatible with the black box, one of the most versatile platforms to run old software, IMHO, is QPC2. But it has the added advantage of running the bleeding edge stuff too. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Software Prices.
John Sadler writes: As Dilwyn Jones says in his article in Qtoady that TurboPtr is more flexible than EasyPtr, and the group members feel that software should be paid for, George I wondered whether the group members did not use it because it was free and they would be happier paying £60 to George because then they felt the program was well worth using and the author was interested in maintaining it. I wouldnt be surprised if that were the case ;) Free programs are all well and good, but we have now begun to expect all programs to be free and that may not be good for the continuation of the QL community. Linux is in a different league, with universities and research intstitutions supplying much of the quality free stuff: The authors of those programs are at least fully funded and doing their thing during their working hours. I dont think that is the case for QL programmers.. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] QL PE files
Roy wood writes: The current version of ptr_gen and wman is 2.01. They are both in need of an update though, as they are out of synch with the corresponding SMSQ/E versions (bugs and new facilities). Who maintains these? Well, they are now free to distribute and I do not think that anyone is maintaining them. I suppose if there are bugs they should be reported but I am not sure who would be willing to take it on for nothing. As for new facilities, I think it was never intended that the three PE files should be the same as SMSQ/E. The recent upgrade was so that programs that accessed the new colours would not crash but run in QL mode. Some programs will now crash, for sure, eg any using SP_JOBOWNPAL (part of Wman), and ptr_gen may not be able to handle the new sprite format Marcel has introduced (mask-less patterns). Neither of the mentioned facilities may be much good in QL colour modes to be sure, but it would be nice if programs wouldnt just bomb out. Wolfgang may have other ideas but I think if you want extended an O/S you will have to get SMSQ/E. Wouldnt many, if not most, of the source files be a subset of the SMSQE ones? If that is the case, they are probably best maintained by our esteemed Registrar. If any help were needed to sychronise them, Id be willing, if not guaranteed able, to help with that. Per ___ 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
Re: [ql-users] Just an idea for a new Product.....
Jochen Merz writes: I'm on Tony's mailshot, or so I thought, but I never saw it! :-( You are. His announcement was on the JMS .gif image linked to from the emailshot. Thanks Tony, makes one wonder if that is read at all... maybe we should, if it is a show invitation, just put the show and the date in...? I must admit I missed the ads too. Being on a dial-up connection I dont normally click on email links, as by the time I see them Im already off-line. The mailshot seemed to indicate that a text version of the ads where available further down, so I only looked at those: Traders ads - see bottom of email for text. TF Services: http://firshman.co.uk/mailing/tfs.jpg Just Words http://firshman.co.uk/mailing/jwhove.gif Qbranch http://www.qbranch.demon.co.uk/showflyer.htm Jochen Merz Software http://firshman.co.uk/mailing/JMS.gif RWAP Software http://firshman.co.uk/mailing/rwap.jpg See what I mean? Very sloppy reading on my part not to see the .gif and .jpg endings, but there you are; I may not have been the only one. Im glad we cleared this one up. Now there is a chance of doing something about it. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
David Tubbs writes: that the starter pack offer (234 Euros worth Shall we say priced at rather than worth. The authors think it should be higher whilst the market seems to suggest otherwise. What market? Pay peanuts, get monkeys. Per ___ 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
Re: [ql-users] Just an idea for a new Product.....
COLIN PARSONS writes: So whats wrong with the demo version of QPC2? You can check out most of the new facilities and run most new programs. Enough to satisfy curiosity, I should think. You can't save any work. Hardly the way to encourage any new programmer to the platform!! Its perfectly possible to write programs which you can test on the demo - only you have to write them on another platform and put them into a .WIN container. The moment you talk of saving your work I suppose you are, strictly speaking, no longer in demo mode.. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
Jeremy Taffel writes: So whats wrong with the demo version of QPC2? You can check out most of the new facilities and run most new programs. Enough to satisfy curiosity, I should think. No, not really, not without being able to save config files etc. Ok, so if you had to solve the problem of producing a demo that would satisfy curiosity, but was limited in some way that would compell the thus satisfied punter to buy the product rather than just continuing to use the demo, what would you suggest? Selling previous versions at a discount doesnt really help as it would become a logistical nightmare for programmers to support what would in effect be new platforms. I don't understand. What new platforms? Surely support is still provided for the previous versions; even if only yes that's a known problem, its fixed in the upgrade Would you buy the buggy version, even if it were £20 less? The fix is usually to get the latest version. There are also limits to how much backward compatibility people who write free or negative-profit software are prepared to strive for. My own stuff will usually not run on an earlier version of the OS than the one it was designed on although, hopefully, it will run on all subsequent versions. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
Peter Graf writes: Id go one better: The place to start, of course, is to make the Qx0 designs public and free so other people can develop and improve them, and in some cases, build their own. A free computer to run free software on. Just the thing. The obstacle is production. If I publish software, it automatically exists, if I publish hardware it does not. Every single piece of hardware must be built (in series production if it's going to be affordable) and at the complexity and massive costs of the Qx0, this means commercial production. Unfortunately one can't materialize mainboards by a uploading to a website or burning a CD. All that is pretty obvious, of course - and neatly side-steps the issue ;) Equally obvious to me, however, is that a /design/ is not a physical thing, but it is essential information to understand the physical thing; how it works, how it can be fixed if there is a problem, how to improve it, how to create addons and expansions, and how to build your own if you are that way inclined. (Presumably, even you had to build a few one-off prototypes to test your design before going to production.) Now, as an owner of a Q60 - a considerable investment, I would feel a lot happier if I knew the designs were available for many of the reasons mentioned above. You might not always be around, you might loose interest, or you might (heaven forbid!) decide to use the monopoly position you enjoy with your closed, proprietory architecture, to my disadvantage. Thered be precious little I could do about that. But luckily it need never come to that because, as you suggest, there is another way: You would make your designs and firmware open and make your profit on the added value thing! (I am assuming, of course, that you respect other people's intellectual property rights as you do your own, and would never expect others to do what you would not wish to do yourself.) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
David Tubbs writes: Really Per, I am surprised at your response ! Ooops! Have I put my mouth where my foot should have been? No, not really, not without being able to save config files etc. Ok, so if you had to solve the problem of producing a demo that would satisfy curiosity, but was limited in some way that would compell the thus satisfied punter to buy the product rather than just continuing to use the demo, what would you suggest? Do you really suggest the potential customer provides the solution. Suggestion, not solution. Solutions in this matter are not my call. Surely support is still provided for the previous versions; even if only yes that's a known problem, its fixed in the upgrade Would you buy the buggy version, even if it were £20 less? The fix is usually to get the latest version. So someone was happy to sell Buggy versions for top dollar ! Yes, it all one big conspiracy to do us poor punters in ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Just an idea for a new Product.....
Dilwyn Jones writes: So whats wrong with the demo version of QPC2? You can check out most of the new facilities and run most new programs. Enough to satisfy curiosity, I should think. No, not really, not without being able to save config files etc. A reminder here that there are programs like my own Launchpad out there which write frequently to disk as part of any norml usage - change anything in Launchpad, it immediately writes out new configuration files which of course gets stopped by QPC2 demo. (just a reminder and not getting at anyone in particular since someone asked me about Launchpad not running on QPC2 lately and it turned out it was the demo version of QPC2 not allowing saving after about 2 days of fruitless bug hunting). Might be an idea to pre-configure all software to be able to run from a RAM disk out of the box. That way punters can try it out in a controlled environment, and QPC demo users wont be stuck. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Perfection
Dilwyn Jones writes: Although I don't think Freddy gets much time for QLing these days, he speaks nostalgically of his time with the QL. I happened to mention Quanta's QL Is 21 meeting to him. He said it may be of interest to him and might wish to attend, if only for nostalgic reasons, if his work etc allows at the time, so there is a possibility we may see him there this autumn as well. Some time ago, I was also in email contact with Leon Heller, Quanta founder, and he said he may take an interest if his commitments allow nearer the time. Wouldn't it be great if we could have a few such distinguished guests from the QL's past attending this event! Hear, hear! Im all for it. Will someone make sure they get reminders in good time? (We wouldnt want them to get away, would we ;) And how about Sector Beatty, SNG, Sturat, Lau Reeves, Jonathan Oakley, Chas Dillon, and anyone else we can think of, too? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
Dilwyn Jones writes: One can make money with free software also, but by adding value instead of charging for the rigths over the binaries. Added value can be: - Distribution packages (Disk/CD/DVD) - Handbooks and documentation - Commercial support (e.g. for those who bought the package/docs) - Provide development for a donation (but the resulting code will be free) - A piece of hardware that uses the free software Nobody will gain a monopoly on such an added value, because the software itself remains free. Nevertheless successful business around free software has proven to work, especially in the embedded systems market. It requires flexibility though. Even in the QL scene, selling added value for free software is not impossible. E.g. the QDOS Classic/Q60 Linux CD sold well, although the software was free and one could have also downloaded the contained pieces at no charge. Also developers of free QL software have been given donations. Such ideas came too faint and too late for the QL probably. Peter I don't always agree with what Peter says, but I think he makes his point well here. This is certainly food for thought. I know myself having put most of my older programs onto my website for free download, I still get people asking for copies on disk or CD or for minor updates for their own needs for which they are willing to pay modest amounts. I must admit, I'm seeing both sides of the viewpoints presented here today. It will be very interesting to see how this dicussion develops. Id go one better: The place to start, of course, is to make the Qx0 designs public and free so other people can develop and improve them, and in some cases, build their own. A free computer to run free software on. Just the thing. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
Roy wood writes: I have no problem reading mine from QPC2. I do have a w problem with it being called WIN6. I must confess that that had not occurred to me before. I just made it up as WIN6_ and did not really pay much attention to it being named that. I have corrected this now and future users will see it called 'QDT' courtesy of your QWIRC utility. Ah thanks. That mollifies my ruffled sensibilities ;) The question really was why did users of other systems have a problem reading it as reported? Works fine on QPC2. I also have no problem reading the QDT CD's QXL.WIN file with wxqt2 rev 1.4 (whew! that last half sentence was a mouthful!). Sorry you were feeling unwell on Sunday. It didnt appear to affect your performance as an attentive and entertaining host! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Just an idea for a new Product.....
Roy wood writes: I intend to tackle the details of QXL.WIN file handling in the next part of 'Start Here' in QL Today. I believe there is software to read QXL.WIN files on other systems but I did get reports of people being unable to access the QDT QXL.WIN files on the CD so I would be grateful for more details on this. I have no problem reading mine from QPC2. I do have a w problem with it being called WIN6. True, that sort of differentiates it from the Quanta Library disc I got at Hove last Sunday, which is called WIN8. But that again is the same as the QWord master disk, which - you guessed it - is also called WIN8, so really not all that helpful. Considering that I have (twice, I believe) on this list published a routine to set the name of a QXL.WIN container file, and have gone to a lot of trouble to produce a handy little PE utility, called Qwirc, that is designed to do just that and a lot more besides, I dont quite see why. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Hove Workshop
Roy wood writes: Problem is, at the end most people are busy getting home. I dont suppose therell be an aftermath on Sunday? I cant make Saturday.. There is always some kind of aftermath. Jochen always likes to get an Indian meal in at some point when he is here so I am planning to visit a restaurant in Brighton Marina fairly soon after the show. You are welcome to join me at my house for a coffee after the show and a meal in the early evening. I should like that. Thank you! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] TobaQQo [OT]
Could I ask a favour? I miscalculated the amount of stress and aggrevation a recent programming project would cause me ;) so Ive smoQued up my stash of acceptably taxed tobacco. If one of our Continental Cousins would be so kind as to top me up at the Hove meeting on Sunday, Id be much obliged! Id like 5 x 50g packets of Drum or Samson for 5 euro per packet or less (about 40% of the UK price). Let me know off-list. TIA, Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
George Gwilt writes: Turbo cannot set sliced arrays as parameters to S*BASIC procedures or functions. This is because of the way the array descriptors are defined. However it is theoretically possible to set a sliced array as parameter to a machine code extension since Turbo defines an S*BASIC descriptor. Unfortunately I cannot see at the moment a way of doing this in practice. Also I had thought that programs could be fairly easily written to avoid slicing. There are often good reasons for using array slices. Although work-arounds are usually possible, they may require shifting data into other arrays which is both time and space consuming. An array descriptor merely presents a logical view of the data. If Turbo at present just sees that a parameter is an array and ignores any indices, then parsing those indices would have to be implemented - something that could be a major job! If, however, the indices are accessable to Turbo, then its simply a matter of creating a descriptor based on those indices - not much more difficult than creating the descriptor for the whole array? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes: But I can change everything Oh yes? ;)) One very simple improvement that could be made to MAWDRAW would be to allow it to take an address instead of an array. The address would point to a data area with the following structure - which you will recognise as the last part of a Menu Application Window Definition: dc.w $0001;number of actual columns dc.w $000A;number of actual rows dc.w $;x offset to start of menu (section) dc.w $0006;y offset to start of menu (section) dc.w list1-* ;pointer to x (column) spacing list dc.w list2-* ;pointer to y (row) spacing list dc.w 0;pointer to x (column) index list dc.w 0;pointer to y (row) index list dc.w list3-* ;pointer to menu row list ; list1 ;column spacing list : dc.w $FFB0;object hit size dc.w $FFAE;object spacing list2 ;row spacing list : dc.w $FFF6;object hit size dc.w $FFF5;object spacing ;menu row list : list3 dc.w list4-* ;pointer to object row list start dc.w list5-* ;pointer to object row list end ...etc, etc The header part (the first 18b) would have to be copied to EP's internal structures and the pointers adjusted accordingly, the rest simply remains in situ. This would allow extra flexibility when needed to produce 1) 2-dimensional lists with the exact number of elements (not rounded up as now), 2) Mixed object type lists, 3) Indexed lists, 4) Turbo-compatible lists with DIY slicing, 5) Pre-defined lists that can be loaded from disk on demand, 6) rapid switching between multiple lists... Dangerous but powerful! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes: P Witte wrote: But I can change everything Oh yes? ;)) Can, not will ;-) I knew I must be dreaming.. ;) One very simple improvement that could be made to MAWDRAW would be to allow it to take an address instead of an array. The address would point to a data area with the following structure - which you will recognise as the last part of a Menu Application Window Definition: Well, MAWDRAW are 1000 lines of code that are not exactly easy to understand, I'd rather not dig too deep in there. And quite frankly, I guess nobody except you would know how to use it. You know best. Its just if it were easy to do.. Youre probably right that it is not very useful. Plus if one really needs it, it could probably just be done by a few POKEs, MWDEF does return the working definition after all. This would be the equivalent to MAWSETUP, the menu can then be drawn using MAWDRAW. Just speaking freely, no idea whether it really works, of course. I agree it should be possible. This would allow extra flexibility when needed to produce 1) 2-dimensional lists with the exact number of elements (not rounded up as now) Rounded up? For example, if you have 10 items to display with three items per line, you have to supply the data in a two-dimensional array, eg DIM arr$(3, 2, 10). arr$ has 12 elements, not 10, so you get two unwanted places tacked on the end. This is not a feature of Wman but of EP having to use arrays. Not a big deal, but it has just that whiff of mickey mouse technology to it. 2) Mixed object type lists, MAWDRAW can do this, can't it? Sort of. I forgot you could also specify string objects using the '@»' adr construct. The latter is an unfortunate scheme though. It may have been ok-ish in the sub 16Mb days, but with more than 16Mb memory you get rounding errors on the addresses! (unless suitable precautions are taken). Why didnt Albin just use floating point arrays for this, I wonder? 4) Turbo-compatible lists with DIY slicing, As a workaround for this, how about a command that somehow explicitly creates a header for an array that has sliced indexes? Just a thought. But how would you pass that descriptor to a command? Its possible if the relevant commands that take array parameters could simply take the descriptor instead, but they dont. Ive used a similar idea for a different reason, so Im pretty sure the concept is sound. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Hove Workshop
Tony Firshman writes: Two day shows are dead loss for me. It simply means I am less busy for two days. Most people seem to come on the second day (like you John). You always seem to manage to be busy enough ;) Personally, I think the duration needs to be in some kind of proportion to the time it takes to travel. QL2004 was just a wee bit too short I would always rather a one day show with socialising at the end. Problem is, at the end most people are busy getting home. I dont suppose therell be an aftermath on Sunday? I cant make Saturday.. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Knoware update
A.. 2005/04/10 Update a.. PED - Reported bugs fixed, except changing palette under Qdos. Some minor additions Available now @ http://knoware.mysite.freeserve.com/index.html Id particularly like to hear from those who cant get the program to start at all Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes:
[EMAIL PROTECTED] wrote:
The latest beta test version of Turbo, v4d21, should soon be on the
SQLUG
site. This one has compiled QPTR's demo_bas (after some
modifications).
I'm curious, what kind of modifications? Dimensioning of strings?
I've read the readme of v4c21 and it sounds pretty promising. What
grade of compatibility do you think you'll be able to achieve?
It sounds very promising! It must also be a major achievement as, IIUC,
Turbo gains some of its speed advantage by not mimicking certain SuperBasic
interpreter structures. Are these structures now being emulated by Turbo?
And without a significant speed penalty?
EasyPtr has sometimes a very powerful but also very complex syntax,
e.g.
{} = alternative
[] = optional
MAWDRAW [#ch%] {,}{;}{\} num[, [array$][, xst%, yst%[, [under%]
[, [xsz%], [ysz%][, [xju%][, [yju%]]]
MAWDRAW #3,1,array$,0,0,,,16
but I think it only passes back simple integers or integer arrays in
its parameters (with MINPUT being the only exception, it alters a
given string using SB.PUTP). Could Turbo manage all this stuff?
All EasyPtr keywords can return an error code in the channel parameter,
provided it is supplied as an integer, ie #ch%. However, it gets more
complicated: You can set EasyPtr up so that instead of a channel number you
pass a pointer to the working definition. A designated variable then gets
any error code instead!
100 adr = MWDEF(#ch%)
110 REPeat loop
120 ch% = 0
130 action = MCALL(#adr)
140 if ch% 0: PRINT 'Error during MCALL:'! ch%: EXIT loop
...
Luckily, both these behaviours are optional. Their main use is for aiding
program development. Turbo should now be able to handle the first scenario
in any case. But it probably doesnt handle the second?
The main stumbling block was that Turbo couldnt handle arrays being passed
as parameters. With this considerable inconvenience overcome, a major
disincentive to use Turbo has been removed.
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Knoware update
A.. 2005/04/08 Addition a.. PED - PSION printer driver utility. For QDOS with TK2 and Wman2, or SMSQE Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes: P Witte wrote: The compiler directive is correct, or at least as per what is in ptrmen_cde ($$asmb=filename,4,82) If the filename above should happen to be ptrmen_cde the correct parameters are $$asmb=filename,0,82 No, 4,82 is the correct one. Address 4 is the entry point without sb_inipr, 0 is the one with it. Qliberator wants the one without it. Im aware of the embedded message, but at some point I changed to using 0,82 (ie dont call the initialisation routine at all) and it has apparently worked. What deos the initialisation code do? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Norman Dunbar writes: MSTAT% is not in the redistributable code, it lives solely in the ptrmenR code, ie, the resident stuff which you are not allowed to link into your programs. I never noticed. But it definitely is in the runtime version of the toolkit now, and has been since V3.50 at least. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Dilwyn Jones writes: The compiler directive is correct, or at least as per what is in ptrmen_cde ($$asmb=filename,4,82) If the filename above should happen to be ptrmen_cde the correct parameters are $$asmb=filename,0,82 Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Knoware
Ffibys writes: I do... I actually do not like minesweeper games at all, but this is Nor do I, but I liked writing one. As these games go, now that Ive at last had a chance to practise, I find D-Miner quite enjoyable to play. pretty damn good! I like the fonts Per used; are these prerendered bitmaps or something else :-) It gives it a X-Windows look that it is totally non-PE (which is pretty nice). Cut out of M$ Word, Im afraid to say.. I am actually waiting for the Cabal game myself which looks pretty awesome. I have worked on a similar solitaire for years but never got to finish it for lack of time and losing interest. However I do have a lot of decks made (even one designed by my daughter which is pretty funny). Per, if you're interested I can send you the decks in a size and format that you desire :-) It would be a shame for them to go to waste ;-) Cabal will be at least another year in the making, sorry. The deck format is currently: -- Card faces file deck dc.w ccount card count, normally 52 face ; table of offsets to cards dc.w x,ycard dimensions. x must be even dc.l sp_SA-*- Ace of Spades dc.l sp_S2-*- Duce of Spades ... * dc.l sp_HA-*- Ace of Hearts ... * dc.l sp_CA-*- Ace of Clubs ... * ... dc.l sp_DJ-*- Jack of Diamonds dc.l sp_DQ-*- Queen of Diamonds dc.l sp_DK-*- King of Diamonds * sp_SA ; Ace of Spades sprite defintion ... -- Card backs file backs ; table of offsets to card backs dc.w bcount number of backs back dc.w x,yx/y size; should be same as corresponding faces dc.l sp_std-* - standard (default) card back ... - sp_std; Standard card back sprite definition ... * Faces and backs must be supplied in separate files, either * in pure binary (no S-ROFF) or in assembler. The cards are just standard sprites, compressed if possible. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Knoware
Marcel Kilgus writes: P Witte wrote: A.. 2005/03/27 Addition and Update a.. D-Miner - Minesweeper clone for high-end SMSQ/E systems Has nobody any comment on this? I thought this thing is freakishly impressive and is really pushing the boundaries on what can be done with the PE. Anybody tried? Just goes to show: It takes a genius to know one ;) Pity about your kind remarks above, though, as I was just about to rave about one of your own upcoming projects (as soon as were allowed to talk about it, that is). Now it will look as if Im fishing for more compliments, so youll just have to take my word for it: My praise would have made you blush! Im always interested in any feedback on any of my programs. How else am I going to improve? Fan mail and general interest feedback may be directed to this list. The remainder should be sent to me privately ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Knoware
Changes to Knoware: A.. 2005/03/27 Addition and Update a.. D-Miner - Minesweeper clone for high-end SMSQ/E systems b.. Timer V0.09 - small update Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Knoware
Watch this space.. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Turbo v4b21
Ffibys writes: I need a break from testing software as Ive got some pressing stuff of my own to do, but Im very interested to hear how this goes. The day Turbo can be used with EasyPtr I may jump ship.. Per Passing by reference works RIGHT now (Q-Word is working with that :-) Ffibys As for EasyPTR... :-) I personally don't care :-) Although I do think it works... sort of (Ask Rich for details. I think he's using a part of EasyPTR for QWord) I only mentioned EasyPtr as this would make a good test of compatibility. The same applies to Qptr, of course. Use Tptr! I hear you say. My only complaint of Tptr, over and above the issues I mentioned regarding Qptr, is the nomenclature. It is unlearnable due to the way my brain is configured. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] louder
Ffibys writes: I only want to play 20KHz samples to avoid the need for duplicate files across QPC2 and Qx0. Im not sure Rich did solve the problem, as QWord - beautiful as it looks on the Q60! - only beeps there, while it plays sampled sounds on QPC2. Per No, The Q60 DOES play sounds (I know because I have tried it :-) I did have both a Q60 and Q40 here so I tried both sides. I looked up my IM and email exchange with Rich on the matter and I remembered that Wolfgang's player initialises everything at 20KHz, which messes up the sound4_bin driver. However if you play a file with copy foobar_ub TO SOUNDx first, the problem is gone. Please mail me a copy of foobar_ub, as I dont seem to have this file* As for QWord on the Q60's sound not working, make sure: * Wolfgang's music player is ONLY used for the PAUSE annoying theme (my bad ;-) ). In general if you can copy the UB files from QWord to the SOUND devices installed by sound4_bin, QWord should be also playing sound (as it uses that sound driver -simplified things immensely-) That must be the cause then. Thanks! Per * Bad joke. I once worked as a helpdesk agent, yknow ;) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] louder
Hi guys, Ive been fiddling around with sound on my Q60. Problem 1) Im using a standard PC speaker, but the sounds are so faint as to be barely audible. The Q60 manual says to use a speaker with an impedance of 32 or higher. Standard speakers are 8 Ohm, and I have yet to find an electronics shop that has heard of a 32 Ohm one. Is there another way to do this, or does anyone have a spare 3 - 4 speaker suitable for Qx0es kicking around that I could buy? Problem 2) Although barely audible, some samples recognisably sound the same on the Q60 as on QPC2, but others either sound different or cannot be heard at all. Any ideas? Or is this just a symptom of problem (1)? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] louder
Roy wood writes: Ive been fiddling around with sound on my Q60. Problem 1) Im using a standard PC speaker, but the sounds are so faint as to be barely audible. The Q60 manual says to use a speaker with an impedance of 32 or higher. Standard speakers are 8 Ohm, and I have yet to find an electronics shop that has heard of a 32 Ohm one. Is there another way to do this, or does anyone have a spare 3 - 4 speaker suitable for Qx0es kicking around that I could buy? I have a small amplified speaker setup that I used to sell with Q40s when I was doing them. It fits into the 5.25 bay, is powered by a hard drive cable and just needs a little fiddling with the input cable to work. I am sure these are available new still and cost around 20 pounds with a volume control. I can get one for you if you want. Yes please! (I'll write to you seperately) Thanks for all replies! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
Ian writes: When I try to run this in QPC, setenv is refused (not recognised). I must be missing something in my boot program? Any ideas? Make sure youre loading ENV_BIN before using SETENV Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Easyptr Move
Dilwyn Jones writes: If you use WMOV there is only the old method available. You can't use any of the new methods. Sometimes you have to use WMOV. For example, the Launchpad clock runs in a MW_LINKed window so it has to be stopped before a move routine is called to move the main display. Something to consider adding to the wish list for any new Easyptr updates I suppose, especially if a trivial change, although hardly a high priority. In the mean time you can use my Wrezmov toolkit which was designed as a stopgap for exactly that problem.Available where? Knoware! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Wolfgang Uhlig writes: EasyMenu is not very good at displaying high colour sprites, you have to fool it by putting a 4/8 mode sprite in front of each high colour sprite. This is not true! Only if you want to have the sprites in mode 4 or 8, too. Just to confuse things a bit more: Loose items and sprites drawn by SPRW can be standard high colour sprites. However, the routines to display sprites in regular menus, such as MAWDRAW, cannot cope with these, and require a mode 4/8 sprite to be prepended to a hicolor one. The fix could be very simple if one were able to read the code, find the problem and re-assemble it again, but as mentioned before, some of those steps are not straight forward.. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Marcel Kilgus writes: P Witte wrote: 1) Manually added scaling flags are removed on re-loading a menu definition and may even crash the program. 2) System sprites cant be shown and other hicolour sprites are problematic. 3) Application window scroll bar attributes cannot be set or changed without specifying a pre-set menu too. Part of the problem may be with the toolkit which seems to ignore or overwrite attributes added by hand later. 4) When changing the sprite origen of a, if the pointer sprite is moved outside the window EasyMen crashes. .. of a menu, OK, noted. But basically I was only going to address high colour problems, though if time permits and the job is simple enough I might look into some others. No promises though. Sorry, it wasnt intended as a shopping list. I just wrote down a few problems that I could think of. Great if you feel like doing something about it. Just your little tweak to allow palette colours to be used has been very helpful. A great stop-gap improvement to this program might be to allow a menu definition to be saved as an assembler file directly from the program (EasyAsm doesnt work in GD2) No, that is much too difficult. But EasySource can easily be made to be GD2 compliant. IIRC all that's needed is to change one branch instruction. That would be very useful! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Roy wood writes: The upgrade situation is not easy. I do have an updated version of Easymenu and Easysprite but they are by no means releasable as Marcel considers them unfinished. The question is would there be a market for an updated version. Marcel does a lo of work on this kind of thing and gets little back for it. He has the source files but I cannot, in all honesty, ask him to work for nothing. He says that the code is not that easy to understand so he is the ideal person to do it. I would like to see and improved high colour version and I, for one, would be willing to pay for this. How many others? Its a pity Albin is no longer interested in developing EP, but thats life. It needent be such a big task, though. IMHO EP could be split into three or four different projects: 1) EasyMen, 2) EasySprite, 3) the toolkit, 4) C-stuff. 1) Marcel has already done some work on this. If what he has done so far is reasonably stable and useful, why not release that for an upgrade fee (with Albin's blessing, of course)? It might even generate a few new sales of the whole package? Although, in the fullness of time, the tools that George has produced to go with TurboPtr, may become replacements for EasyMen, they are by no means there just yet - at least not last I looked. However, that is another possibility for the future. 2) I understand from Albin that this could be quite difficult to upgrade due to the way it is designed. It could be dropped altogether if there were viable alternative developments. How about Jerome's sprite editor? Or how about a more generalised spin-off of Jim's Icon Edit? 3) The EasyPointer keywords are mainly wrappers for the underlying Wman utilities. Wouldnt it be great if some (if not all) of those commands were to be included in SMSQE - or rather in Wman2? From my brief assessment of the toolkit, it seems to me the whole thing could be simplified and purified (to do away with the easymen Thing, for example) and improved. It neednt be compatible, but rather a replacement. The reason Im not enamoured of Qptr, the original PE toolkit, is the way it gets the user data into the Wman. It is superficially attractive to have all your data easily available and manageable from Basic. The problem for me is that there can be so much data to deal with that it swamps out the functional code. Although there are ways of minimising the hassle, it is still not ideal as, in effect, you have up to four copies of the window definition data in memory at the same time (DATA statement data gets put into arrays, which are copied to a Window Definition, which again is copied to a Working Definition). Also it is relatively fiddly to design and alter objects in this way. The EP approach of editing the design in a designated program and then linking the binary data to the code, compiled or interpreted, seems to me to be simpler, cheaper and more flexible. 4) Something for the C-fraternity to get their teeth into? So we come to the fraught question of who would do the work. Adding the toolkit to the Wman module could be an open project to go hand-in-hand with SMSQE development. The main thing would be to get off to a good start - perhaps initiated by one of the cognoscenti - and then building up the functionality over time. Even someone at my level could contribute there. We can live without a good menu designer or a sprite editor, but not without a way of displaying and manipulating our windows and menus from within programs, so for me that is the main priority. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Quite quiet
Nice and quiet around here for a change .. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Fred Toussi
Tony Firshman writes:
I keep quoting Lau's brilliant superHermes documentation, but it is
worth repeating.
The sH _asm was vast, but is mainly documentation.
He wrote giant introductions, where he had a dialogue (with himself) on
how to approach basic logic, listing out -all- his thoughts.
Brilliant. Not only does a future programmer know what he did ('cos it
is there) but what he rejected.
Even the version number code was seamlessly integrated, but simply
un-commenting one allocation line in the middle of comment.
On a slight tangent to that, the core of my sb2htm program (which converts a
S*Basic program into colour-coded, navigatable html) was based on an OCRed
scan of the documentation:
Thus
18.4.2 BASIC Token Values
The following section defines the token values used for the internal storage
of a SuperBASIC program.
tkb.space$80 spaces in the listing - two bytes: token, count
tkw.keyw$81 all sorts of keywords:
tkw.end$8101 END
tkw.for$8102 FOR
tkw.if$8103 IF
tkw.rep$8104 REPeat
...
became
...
66 REMark The following section defines the token values used for the
internal storage
67 REMark of a SuperBASIC program.
68 :
69 tb% = PEEK(pos)
70 SELect ON tb%
71 = tkb.space :REMark spaces in the listing - two bytes: token count
72 PRINT#cw; FILL$(' ', PEEK(pos + 1));
73 :
74 = tkb.keyw : REMark all sorts of keywords:
75 tw% = PEEK(pos + 1)
76 SELect ON tw%
77 = tkw.end : PRINT#cw; 'END';
78 = tkw.for : PRINT#cw; 'FOR';
79 = tkw.if: PRINT#cw; 'IF';
80 = tkw.rep : PRINT#cw; 'REPeat';
...
The first thing I tried to do was to get the program to LIST itself (without
using the LIST keyword, of course). Shock and horror! It worked first time!
Its a very handy piece of code as it can be used for a whole range of
utilities that need to scan a S*Basic source file. I'll put it up on my
website when I get round to it.
Great when documentation can work like that.
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Virus [OT]
Im now the proud owner of my first Internet Security Solution, ie anti virus, anti spam, anti adware, + firewall. I now fully realise what a dreadful inconvenience the rest of the world and his dog seems to have put up with while Ive been running wild and free these past ten years! Its expensive - and theyve got me for life by the short'n curleys now, havent they? Its intrusive, and it slows many things down to the level I feel Im back with a 133 MHz 486. Its also pretty scary and complicated stuff, (And what a turn-off for a novice computer user!) Having said that, I believe Ive got one of the friendlier ones, having tested, seen and read-up on many of the market leaders. Norton, with its rude and insistent threats (always when it is most inconvenient) to update the virus definitions or renew your subscription, should be arraigned before the court of Human Rights; Kapersky (and derivates), so aggressive it makes you feel a stranger in you own home, and a couple of others I dont deign to confer the dignity of remembering their names, are beyond the pale - yet they make millions. Where do they find the programmers? Ex prison guards, perhaps? So why did I do it? Well, broadband has finally arrived here in this godforsaken nook of England, (although it will be a few months before I get connected, so please dont mail me all your holiday snaps just yet). Continuing to ride the Internet bare backed would probably be irresponsible, so Ive swallowed my pride and conformed. Yet despite the dire warnings and the shaking of wise and moral heads, my first complete system scan using all the tools available showed that there was nothing amiss with my system. Yes, it did throw up a couple of viruses (mainly from friends on this list! (Thanks guys)) but they were all still contained in the mails they arrived in and have never been activated. There were also a couple of tracking cookies, most of which I was already aware of and which I have no problem with; and some remnants of malware that I had already neutered. Is it really worth it? Havent I just been duped into purchasing this whopping great virus that consumes my time and my resources, forces me to receive spam (s.c Security Bulletins) that I now HAVE to read, etc? Cant I just turn my broadband connection off when I dont use it, so in effect it will operate in the same way as my dial-up connection? All that this does is protect my system from past viruses which, so far, Ive been perfectly competent to deal with myself. It offers virtually zero protection from the NEXT new virus. Retreating behind my firewall..., Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] on a hiding to knoware
Since its been so quiet these past few days, perhaps you wont mind me announcing a piffling update to my website Knoware @: http://knoware.mysite.freeserve.com/index.html A.. 2005/02/06 Update a.. Qwirc V0.66 - update and more bug fixes b.. LX2 V0.03 - tiny but important change! See Readme for details. c.. Msprv V0.07 - bug fix and small update Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] smsq gold
Rich Mellor writes: No I am not certain. All I am certain of is that it's SMSQ_GOLD v3.06. It probably ain't the colours version as DISP_COLOUR 2 does nothing it seems. I don't use the QL and MiniSQL Aurora that much, so have probably not installed the right versions. Only way of telling for sure is the file length - maybe Roy can remind us all of the file length for the two versions... Another way of detecting whether you have the colour version is by noting the difference in the price... Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
- Aucun - writes: I understand and believe that in your situation EX WIN6_myprog_exe executes myprog on your local machine, but EX n1_*win1_myprog_exe executes myprog on the remote machine, provided QPC runs there as well, I suppose (and WIN6_ on you local QPC is WIN1_ on your remote QPC)... Aha! So the * in n1_*win1_.. was not a typo. I never knew this. Great! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
wolfgang mühlegger writes: P Witte schrieb: How do you make this work? marcel hacked sernet to work 'over udp' and it's working great! I think I got that part of your earlier message ;) What do you need to connect and how do you make it work? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Old games
Rich Mellor writes: Otherwise just use RESPR instead of ALCHP. ..provided no jobs are running (Qdos). Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
wolfgang mühlegger writes: to me the most exiting thing has not been mentioned by a word: marcel has modified sernet to udpnet. so ql-networking is MUCH faster now and easier too - you do not have to deal with baud rates, cables ... How do you make this work? thx marcel .. Yes. A lot! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Pointer Environment and TK II
Dilwyn Jones writes: Tony Tebby wrote: Maybe that's out of copyright by now or maybe I'm not dead yet. Ah, uncertainty. Maybe somebody should open the box and have a look then? No wonder the QL user list has been so busy this year if we are starting to get contributions from beyond the grave... -- Rich Mellor Old operating systems programmers never die, they just run out of bugs to fix In that case certain old OS programmers will live on forever. Either way, copyright ceases after 50 years. In the mean time I think we owe it to Tony not to discuss the future disposal of his property but rather to rejoice in the good things we have had. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Pointer Environment and TK II
P Witte wrote: TK2 V2.12, at least, contains the keywords to make or open directories. I think the actual directory drivers are implemented separately. At least with some of the emulators you have to load both the toolkit ROM and a driver ROM such as NFA.ROM The above is wrong. Apologies. TK2 v2.12 (at least my version) doesnt have the MAKE_DIR command. I mixed it up with another version I used to have but can no longer find anywhere on my system. V2.12 has FOP_DIR and seems to work with directories, ie it appears to be able to read real directories but cannot make them. The current Smsqe version of TK2 is 3.28. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Pointer Environment and TK II
Roy wood writes: All you've proved is that the MAKE_DIR procedure is part of TKII... But that was the bit he wanted. What were the differences between the level two drivers and the normal ones then? This was a long time ago but I thought that the differences were mainly the sub-directories TK2 V2.12, at least, contains the keywords to make or open directories. I think the actual directory drivers are implemented separately. At least with some of the emulators you have to load both the toolkit ROM and a driver ROM such as NFA.ROM Are the sources also released? If they are, wouldnt it be convenient to maintain them together with Smsqe, so that at least some of the enhancements made to the Smsqe version of the toolkit can be made available to Qdos/Minerva systems? Presumably, they share a number of common files? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Pointer Environment and TK II
Roy wood writes: After a discussion with Tony Tebby Jochen Merz and I have his permission I hope you will all agree this is good news. This is splendid news! Time for an Upgrade your QL website, somebody? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
George writes: Caution! Caution! I was asked by someone to allow any file type to be set by GWASS (other than 255 which is special). This implies that someone somewhere is perhaps setting up file types of 3 to 254 in assembled programs. Suddenly using one of these for another purpose might scare the living daylights of this someone. And so it should. He played with them at his own risk. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
Isnt the thing to do here to emulate the Windoze solution? Ie, each directory entry has a short filename [SFN] wchich complies in every respect with the old directory specs. The LFN is stored within the directory file in specially marked records, or in a separate file. Eventually, the old system could be removed altogether from hard disks, but would always exist for floppy drives. To develop this idea a bit further: Keep the old directory structure, but use it in a different way. Instead of a combined pathame/filename, each record stores a filename of say max 20 or 22 char long, which may be seen by old programs that read the raw directory structure. Each directory record also stores a unique file number (and possibly additional housekeeping information) and that file number is a unique file identifyer. A separate utility, a Thing, maintains the real, or user, directory structure. It can create or delete sub directories on the old system as it sees fit, to maintain efficient access to its data. It also provides all the directory services, which could eventually include some advanced database functionality. All OPEN calls for the relevant devices go through the Dir Thing. You can supply the full path and filename, or the short name, or the unique file number to locate the file. It would be easy to implement Undelete and shortcuts to such a system. Keeping the old structure allows some degree of backward compatibility, but more importantly it allows one to deal with the files on the file level rather than having to deal with them on the block level - a much bigger and more complicted task. A problem is that many programs that do no more than simply parse a filename, might fall over, but steps could be taken to alleviate a lot of that. The system neednt be mandatory. Only those wanting to read or use long filenames would have to deploy it. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: But why? Its enough to know it can be done without knowing how ;) OK, so this whole discussion makes no sense, I should just have gone ahead... That does not follow. The point of the discussion is not to fall into fixed ideas before all the issues have been explored. Now is the time to chop and change and take a few wrong turns, as we dont have the code base to drag around. Im trying to understand the present state of play, so how do you see the question of Qdos compatibility and any consequences? Should a Current Directory [CD] be included with the HD or is this a different project? How do filename/path limits affect this project? And how can we be expected to come up with solutions before we even agree on what it is were trying to do? You may know exactly what it is you want to do. Marcel's ideas appear to be somewhat different (as this discussion revealed) I have an inkling of what I want but I dont know if anyone else wants it. Are we even really talking about the same project? That the implementation ideas are different is obvious. Does the implementation affect the functionality or does the functionality dictate the implementation? Or do we have the Supermarket syndrome ie a number of different choices that produce identical results. Which to chose? The cheapest, the strongest or the sexiest? Practical people dont like being held up by planning and philosophical considerations. And yes, there is a risk of it all running into the sand if theres too much talk and too little action. But I believe the optimal solution will only be found if we take the trouble to search for it. It doesnt matter if we have to wait another year, its just a fraction of what weve waited so far. The CD issue cropped up as we were talking of HD. But how about other things while we are toying with the idea of doing something about jobs? It would, for example, be great for a job to have some kind of Quit code: When a job is removed it can either be called with a soft request (which the job could reject or delay, eg as a result of user input Save file before quitting Y/N?) or a hard request, which would allow it a few seconds to prepare itself for death after which it would be snuffed out without further ado, ready or not. Maybe we need an overall development plan before we continue poking around? More seriously, I don't pretend to know it all and if you have a better idea, I (generally) don't suffer from the NIH syndrome. What is the NIH syndrome? Actually I can think of one sure method to find a Home Directory [HD] string. Taking the structure to look like this: I think I can answer all your questions, but I doubt it would be very useful at this stage. Moreover, Joachim said on this list that there is a mechanism in the heap allocation/release whereby a call would be made to some user specified code when the mem is released. I can't find this facility anywhere, thgough. All that exists, AFAIK, is an address that will be set when the memory is released. This is not documented anywhere to my knowledge. Details would be welcome. The key file Common Heap header (smsq/keys/chp) mentions a chp_orel Offset of pointer to RELease code from chp_drlk Is that it? Incidentally, I don't know the DUP DDOWN commands. Whilst I have no problem understanding the DUP command (after all there is only one parent dir), am correct in assuming the DDOWN command has one obligatory parameter, the name of the dir? No, the name of the next sub dir: DATA_USE 'win1_prg' DDOWN 'ext' PRINT DATAD$ would print win1_prg_ext_ on your screen. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
P Witte wrote: DATA_USE 'win1_prg' DDOWN 'ext' PRINT DATAD$ would print win1_prg_ext_ on your screen. I should add: Whether it exists or not, ie it appears to be a simple string operation. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: I mean things like .. and \ (root directory) of DOS. Yes!! Ok, so at least one likes my idea :-) Two, I hope? Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). As long as it is a reasonable limit. Sure. What's reasonable for you? How about using the same as the enhanced ISO9660 standard (Joliet)? That might be one complication less. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
George writes: stack (a7) channel count channels command string magic (.w) - (a6,a5) (as at present) program's name length (.w) HD's length (.w) program's name bytes padding of above to 42 bytes Since there is nothing on the stack after the end of the parameter string, (A6,A5) can be said to point either to the end of the parameter string or to the bottom of the stack. I have alwys treated (A6,A5) as pointing to the bottom of the stack and this seems more logical to me than to say that it points to the end of the parameter string. I would then think it better to find the new information by looking to the end of the parameter string. After all, you can't use (A6,A5) to get to the parameter string itself, you have to look to the end of the channel info. I see your point and agree. It shouldnt affect compatibility except possibly in the case of QLib, who's workings we dont know. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC Keyboard
George writes: I have also produced a private keyboard table loaded by KBD_TABLE which to some extent allows the two uses of the number pad. Holding down Alt Gr makes the num pad act as though Num lock was off. How difficult would it be to add Minerva's 'Compose' keystrokes? You know, 'a' + ALT ENTER : makes 'ä' Very easy - if you hold down Alt Gr and then press the A key. Do you mean it already exists and is available? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
Marcel Kilgus writes: Just an unrelated note to the DOS long-filename-hack: They had to do this because a single file name was limited to only 8 characters. We have 36 characters to work with, which is much less of a burden. So I don't see the need for something similar. But they had a greater directory depth, I seem to recall. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: set a default filename for a job with a certain name No. I dont see the point. They can just use PROGD$ as now. No, I thought about hot_rext'd progs. What are they?. I dont have a hot_rext (or similar) command. If this is contained in some toolkit, then that toolkit should be altered, not the system. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: Also something one should probably think about: should functions like OPEN automatically use the current directory if no drive name is given? Currently most commands default to DATAD$. Or, speaking completely into the blue, what about a meta device like DEV_ that uses dynamic paths instead of static ones? Something like home_MyDataFile? The DEV device doesnt seem to work like that: If you have a directory structure like win1_ps_ - win1_ps_letter_doc win1_ps_pt_ - win1_ps_pt_letter_doc If you set DEV_USE 1, 'win1_' then you can OPEN, or whatever, dev1_ps_letter_doc and dev1_ps_pt_letter_doc. All well and good. If you set DEV_USE 1, 'win1_ps_' then Qpac2 or OPEN finds dev1_letter_doc (= win1_ps_letter_doc) ok, as youd expect, but it cant find dev1_pt_letter_doc. You better check out whether DEV's behaviour is what you expect. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: Even though it is my idea this probably needs more thinking. The device I proposed is probably not the way to go, instead perhaps the OPEN routine would need to be changed to automatically make use of the current directory, otherwise it's probably somewhat pointless. BUT if this were so, relative path-names would have to be introduced, too. I mean things like .. and \ (root directory) of DOS. Yes!! get the length of the file/dir names (this would only be of interest if *somebody* actually gets around to implementing some form of long file names). Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). As long as it is a reasonable limit. set a default filename for a job with a certain name How do you know the job name? When using HOT_whatever, don't you just know the filename then? As usual, relatively few people have commented on this... Which sometimes can be a good thing ;-) I heard that! ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC Keyboard
George writes: I have also produced a private keyboard table loaded by KBD_TABLE which to some extent allows the two uses of the number pad. Holding down Alt Gr makes the num pad act as though Num lock was off. How difficult would it be to add Minerva's 'Compose' keystrokes? You know, 'a' + ALT ENTER : makes 'ä' Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware conflict...
Some time ago I wrote about a problem with a green, jinxed PC I have, and I received a lot of helpful advice on this list - Thank you! I had this machine built for me at a local computer shop. Not the industry's brightest people, pehaps, but very helpful and friendly. They were at a complete loss. In desperation, one of the guys brought his own XP3200+ to work and plugged it into my machine. Hey presto! It worked. Then he took my CPU and plugged it into his machine. Lo and behold it worked too! Finally, he claimes, he put my CPU back into my machine - and that too worked! So I took it home, and my green beauty has been working flawlessly for the past 48 hours - a record!. I phoned the guy up to tell him so. He says that his machine doesnt work anymore! He is adamant that I have my own CPU and he his. Whats he got? The computer clap? or is it all clap trap? I dont know. Perhaps Roy has a point about the reliability of Athlons. Perhaps it was just dirty contacts. Perhaps it was the colour of the case. Hopefully the saga has run its course. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes:
What are they?. I dont have a hot_rext (or similar) command. If this is
contained in some toolkit, then that toolkit should be altered, not the
system.
yes, you do :-)
eg ert hot_rext(' f ',' win1_progs_fifi ').
Sets FiFi up as a hotkey (in fact an executable thing). Hit Alt F and FiFi
excutes. But what would its home dir be?
win1_progs_ ?
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: It will be set up as a thing (since I don't think we have found any other satisfactory solution for compiled Basic). We havent really tried, but ok Go ahead!!! But why? Its enough to know it can be done without knowing how ;) Actually I can think of one sure method to find a Home Directory [HD] string. Taking the structure to look like this: stack(a7) channel count channels command string magic (.w) - (a6,a5) (as at present) program's name length (.w) HD's length (.w) program's name bytes padding of above to 42 bytes Algorithm: get job info find start of allocated memory list scan through list: if memory ID my ID: next if length of block 52 bytes: next if the word at block_length - 48 magic: next HD found: exit scan end scan Another way would be to analyse QLib_rext or trace a running program to determin whether QLib retains any memory of its original data area. If it does, say in a6, then all that is needed to find the HD string is the correct offset. If it doesnt, eg it releases this memory again, this method wont work. A third way would involve a hybrid between the Thing and the Stack schemes: Let the EX code link the dataspaces of all jobs under its auspices using part of the area to store its information. No need to reserve an additional memory area whenever a job is started. Thus a different structure could be used: stack(a7) channel count channels command string Link to next dataspace (.l) - (a6,a5) (as at present) Any other household info the Thing needs program's name length (.w) HD's length (.w) program's name bytes padding of above to max bytes Any Other Business Remember, all this dataspace is invisible to legacy programs. The memory is perfectly legally there, but the legacy program wouldnt know anything about it. No marker is needed because all data is at known offsets. The mechanism would be the same as I understand you were thinking; that when a job is removed, the Thing is freed. The Free rutine unlinks the dataspace and the kill job function (sms.frjb) releases the memory. So its clean, lean, less messy than having a different memory area to store the details, compatible with legacy software, and cognizant programs running on a legacy OS will be warned unless the Thing is there. (...) Both. By why not re-use the DUP DDOWN code as a general utility to work on any filename string, given the string's location? Suggest the new Sbasic keywords be called UD, DD and CD (CD - Change dir, ie set a new start string) ie, something quick and simple (though admittedly a two char name is potentially dangerous) NOT trivial. What is not trivial? The implementation? or reusing DUP/DDOWN? As for the principle, I believe that is what Marcel is proposing with his Current Directory. [Note: Since we're still in brainstorming mode I reserve the right to make /outrageous/ and even downright /stupid/ suggestions without being smirked at at future QL shows, ok? ;o] Ok, we'll just smirk here, then... That was a very discreet one ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: [Save Name] Right, I wasn't even aware of that possibility! I've had a quick look, this seem to be an Sbasic specific feature, it doesn't exist in Superbasic (nor, I think in TK II, but could somebody check?).. Yes, its strictly SMSQE only. Nice little job for some Qdos aficionado to add the facility to SuperBasic? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Your idea sounds excellent. Instead of my bicycle you and Wolfgang have produced a Mercedes. I am in favour (as long as I dont have to produce it ;) Damn, that was my precondition, too! ;-) But it does start to sound like a worthwhile job. You will notice that (contrary to the long file names topic) I didn't ask a question, but made a suggestion. This implies that I'm quite willing to do that stuff... Bravo to you! I'm not promising anything quick, though. (Wasnt that what I said two years ago? ;) Can we more or less agree on the following: --- It will be set up as a thing (since I don't think we have found any other satisfactory solution for compiled Basic). We havent really tried, but ok For each job, the thing should contain: the complete filename the dir whence it came from (home dir) the current dir which will initially be the home dir facilities should exist to set the complete filename. This will also set the home dir and current dir. get the filename, home dir and current dir. set the current dir (either directly or by ddup, ddown?) Both. By why not re-use the DUP DDOWN code as a general utility to work on any filename string, given the string's location? Suggest the new Sbasic keywords be called UD, DD and CD (CD - Change dir, ie set a new start string) ie, something quick and simple (though admittedly a two char name is potentially dangerous) [Note: Since we're still in brainstorming mode I reserve the right to make /outrageous/ and even downright /stupid/ suggestions without being smirked at at future QL shows, ok? ;o] get the length of the file/dir names (this would only be of interest if *somebody* actually gets around to implementing some form of long file names). Yes! Ie, no LEN, it has to be a system call set a default filename for a job with a certain name No. I dont see the point. They can just use PROGD$ as now. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Sorry but A6,A5 does indeed point to the *end* of the command string at least when the job is invoked by EX it doesn't point to any data area Yes, the documentation is a bit misleading here. Apart form that, I think we agree on the Ex mechanism. (...) QLib does, of course, know about the space taken up by the channels and command string and so, if it likes, can scribble all over it. It cant scribble over my area as, as far as it is concerned, that memory doesnt belong to it. So a6,a5 would stay where it is. I hope this clarifies matters. However, the point is moot at present, since it seems that at a different solution is currently the favourite. Could you agree to it? The only power a volunteer has in cases such as these is to give or to withhold his work, so of course I agree ;) But do you agree that the concept of stacking information on top of the stack, as outlined invarious mails in recent days, is theoretically feasable? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: However, this is a much more ambitious project than a mere home directory affair. Actually I think it doesn't amount to much more work. Perhaps it is a separate piece of work altogether? Afterall, why not have as many current directories as you like, from 0..n? This could be a separate System Service altogether. You have to alter the device driver to cater for it too. Hm, which? I don't propose that every device driver should know about the current directory but that there could be a new device like home_ or something that did specifically include the current-path, exe-path or whatever. You did mention OPEN in an earlier mail... It also implies that Qdos is left out in the cold and that programmers who want to make their programs run under Qdos will have to make a considerable effort to achieve that. Hmm, why? Currently I don't see anything in my proposal that is strictly SMSQ/E specific. Thought I am beginning to hate QDOS compatibility, just out of spite. As above. Another thing with Things is that every program will have to carry the code to scan for the THING Thing (apologies to the scores of avid readers following this thread for this apparent mumbo-jumbo ;) if they want to stay Qdos compatible. Not a big deal but the word bloat does tend to insinuate itself.. However, my thinking goes: If all the Homedir is wanted for is to find the location of some config file (as will often be the case) then the space taken up by the Homedir string could simply be re-used as a Current dir. Well, this is what I call a hack. Nothing wrong with that per se, I do that a lot. But if I design a *new* OS interface it is usually not the way I want to go, at least if I can't help it. No, extending the CDB was a hack, and not a pretty one either, but quite servicable. My proposal is an extension of an existing facility, namely stacking an additional parameter above the command line, where only cognizant programs will know to look for it. The concept is widely used throughout Qdos/SMSQE. The only hack involved would be to get QLib to find it, and QLib is going to have to be hacked almost whatever solution is chosen. I don't see memory fragmentation as a problem. The memory block will start its life with the memory block for the job and will end its life along with it. No fragmentation really. If you say so. You havent explained how you would set about it. Example: allocate the memory before the execution of the job with the job as the owner. It will get freed automatically on removal of the job. And how do you know that the memory is not valid anymore? Easy, the job-ID won't be valid anymore. The fragmentation I suggested would be due to the fact that whenever a job dies there will be three holes in memory instead of just two. However, I concede that this probably is insignificant. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Other thought: make the job use the thing, which in turn reserves the memory. On removal the thing will be informed and can deal with that. Just a thought, I am NO expert on things. But this is entirely correct - it would just mean that the thing would have to be used continuously by that job. Is there any reason why the job cant be born as a confirmed Thing user, ie it doesnt have to take any specific action to use the Thing when it starts up. Let the setup routine (currently EX) sort it all out before handing over to the job? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes:
Sorry if I misunderstood.
(or I did!)
It is easier to misunderstand that otherwise. Weve all been doing a lot of
that during this and other discussions. Very frustrating, but it cant be
helped. As long as we get some results AND stay positive very little else
matters ;)
Executable Things that were set up using HOT_RES
and family would have access to the filename, and every instance of of
the Thing that was executed via EXEP could inherit that filename.
This means that the thing will, indeed, have to have some kind of
default facility, as envisaged earlier.
No, no:
ERT HOT_RES('x', 'win1_psion_XChange', 'X')
The file name is there! Thats the one to store somewhere and propagate to
every instance of that job.
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: 1) Older programs which would expect (a6,a5) to point to the command string at the top of the data area. If we were to adopt this scheme, then a lot of existing programs would immediately not be able to get at any parameters passed to them. We do not have the software authors or sources to enable us to amend existing programs or re-write them. I guess we could overcome this by amending the setup job code to have (A5,A0) (?) point to the location of the home directory No. Let a6,a5 point to where it usually points, i.e. the command string. Finding the home dir after the command string (for a prog aware of this) is trivial. My notes say (a6,a5) points to the top of the data area, not the command string? However, it is not important. A new convention could specify that (a6,d3) (or whatever), would point to the marker. Am I right in assuming that, apart from the registers that are defined (a4-a7), all other registers are zeroed on job initialisation accross all Qdos-compatible systems? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Whatever the low-down implementation, ideally the workings of the HD/CD should be as consistent as possible accross m/c programs, interpreted Sbasic or compiled Sbasic. Anything that wouldn't be available to compiled Sbasic wouldn't make much sense! True ;) I really only meant that it should operate in an intuitively identical manner considering the differences between the interpreted and compiled environments. That is why Im suggesting to use the Save Name as the Homedir in the interpreter. The difficult bits have already been implemented, only we dont currently have access to the Save Name except indirectly through (Q)SAVEing and (Q)LOADing the current program. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Or a completely different proposal: (putting the home dir after the command string) As long as you dont mean that this has to be done on the EX command line, I agree with the above description. Having said that, it /would/ perhpas be nice to add something like this as an option to overwrite the default home directory, although is does complicate an already overloaded parameter list: EX filename ; command string ! different homedir (...) QLib compiled programs pose a challenge as we dont have access to the compiled job's initialisation code to access that information. However, there are other, more plodding, ways to find a job's data area and locate the HD string. Thus a function such as HOMED$ or CDIR$ to read the HD string would have to work differently in compiled and interpreted mode. Thereyougo. Now shoot it down in flames! OK. Flamethrower mode I'd thought of that, too. The only problem I see with it is, indeed Qlib. I presume that your way of doing it would involve some kind of basic keyword that you call and that returns the home dir string. Precisely How do you find this string? Have you tried finding the command string from a QLibbed prog other than with the QLib internal CMD$ command? The problem is that once you get to the stage where your keyword will be invoked, A5 will point to who knows what (in fact, the parameter list, relaive to A6) I see no safe way to find the string - but I stand to be corrected! Its first of all a matter of finding the job's dataspace. The Homedir string is at the top of that, past where the QLiberated job has any legitimate business to poke around (it thinks its dataspace (according to my scheme) is 48 bytes smaller than it in actual fact is). So QLib initialisation code is unlikely to scribble over it. (Ive just briefly checked: A QLibbed program doesnt appear to interfere with its command line either, so thats hopeful.) I havent looked in detail how the dataspace may be found, but I presume it possible to find any executing job's dataspace by legitimate means. It is also possible that the QLibbed job's a6 points to its dataspace. Either that or it stores the its location somewhere, as it needs to find its own command string on demand. Alternatively, EX could be made to identify a QLibbed program and store its dataspace address in a known safe location before activation. This requires investigation, but Im not concerned that it wont be possible. / flamethrower mode Better to flame now than once it is implemented ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Wolfgang Lenerz wrote: Default could also be DATAD$ or whatever. that would defeat the wholme exercice. Why that? It's just a fallback solution if otherwise no other directory can be provided (none set). Well, it already exists... Wouldn't it be better if the user explicitly set default home dirs per job name? Doesnt this defeat the object? We already can do this with a simple Config block. The point of a Homedir is that you can always know the name and path of the current job from wherever it is executed. (BTW, by supplying the name too, it would allow the program to poke its own binary on disk, eg for configuration purposes). Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: That is why Im suggesting to use the Save Name as the Homedir in the interpreter. The difficult bits have already been implemented, only we dont currently have access to the Save Name except indirectly through (Q)SAVEing and (Q)LOADing the current program. Oops, in this case I don't understand at all what you are talking about. What is the save name? LOAD win1_prg_fred_bas: REMark Load a program SAVE: REMark Save the same program win1_prg_fred_bas is the Save Name as far as Im concerned as I dont know what else to call it. The Save Path (or directory) here is win1_prg. I propose that this name be accessed from Sbasic via the a function like HOME$ or HOMEN$ or whatever, and the path be accessed via HOMED$ (to follow the current nomenclature). Perhaps it should be possible to change it directly (rather than indirectly as now): HOME_USE win1_new_john_bas. In compiled mode HOME$, HOMED$ and HOME_USE would all act upon the home directory. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Doesnt this defeat the object? We already can do this with a simple Config block. The point of a Homedir is that you can always know the name and path of the current job from wherever it is executed. I think we were talking about jobs executed from things which don't have a filename. Weren't we? Sorry if I misunderstood. Executable Things that were set up using HOT_RES and family would have access to the filename, and every instance of of the Thing that was executed via EXEP could inherit that filename. (BTW, by supplying the name too, it would allow the program to poke its own binary on disk, eg for configuration purposes). OK, sure. I think Marcel said something similar, too- the dir name and the total name of the file. Yes, theres no point in not doing so. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: No, I have for example a current directory in mind, which should be changeable (on request of the application) after the application started to run. I also have a device in mind that automatically accesses the current directory. None of which is cleanly doable with the put it into data space method. As soon as a job runs the data space is his to mess with, nobody else. How should a potential device find the directory name there? Fair enough, but you are trying to solve a different problem to the one I was solving. Im not a mind reader. I never knew that I wanted a current directroy, but I can see that it makes sense. However, this is a much more ambitious project than a mere home directory affair. You have to alter the device driver to cater for it too. It also implies that Qdos is left out in the cold and that programmers who want to make their programs run under Qdos will have to make a considerable effort to achieve that. There is nothing wrong with that per se, as long as we are concious of the fork in the road. My proposal would have allowed retro-fitting onto Qdos, either as a separate toolkit to replace EX co, or by upgrading the file version of TK2 should the sources ever become available. And, thinking further, the thing could even do more. It could supply the complete filename of the EXE, it could supply the path of the EXE This has been my thinking all along, too. (home directory) AND it could supply a current directory. All with very little effort. Then it could offer services like change directory, a bit like DUP and DDOWN. A third party (like the mentioned device) could easily get the directory for another job, without any guessing. All neat and clean. Very nice ;) However, my thinking goes: If all the Homedir is wanted for is to find the location of some config file (as will often be the case) then the space taken up by the Homedir string could simply be re-used as a Current dir. Equivalent functionality to DUP and DDOWN could be a system service and be applied to that string. The assembler programmer would have some assistance to maintain this file name string, but it wouldnt be a true Current directory. For the Sbasic programmer the illusion of a true Current dir could be made total, so he wouldnt be able to tell the difference between your Current dir solution and mine. And how do you know the OS does provide all those directory services? Easy, if it didn't, there would be no thing! Can't say the same about (A6,D3.L) or something similar. That was a simple suggestion to carry a more complex argument; not a solution, the best solution, the only solution or the whole solution. My proposal is less likely to fragment memory and would use less of it (M/c programs could simply use the memory reserved for the HD if it were not required). I don't see memory fragmentation as a problem. The memory block will start its life with the memory block for the job and will end its life along with it. No fragmentation really. If you say so. You havent explained how you would set about it. Whatever the low-down implementation, ideally the workings of the HD/CD should be as consistent as possible accross m/c programs, interpreted Sbasic or compiled Sbasic. That's why an independent interface like a thing could really help. It can be accessed from any language because it does not rely on any information but the job-ID, which is always readily available. Your idea sounds excellent. Instead of my bicycle you and Wolfgang have produced a Mercedes. I am in favour (as long as I dont have to produce it ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Having said that, it /would/ perhpas be nice to add something like this as an option to overwrite the default home directory, although is does complicate an already overloaded parameter list: EX filename ; command string ! different homedir Before IMPROVING the service, let's already get it... (grin) (...) Of course. But its good to peek around the corner - as we are doing - to see how it might affect the implementation. Its first of all a matter of finding the job's dataspace. No,no! To recap: command line (a6,a5) This is not the case. As it says in the documentation (and I have just varified it with Jmon) (a6,a5) points to the top of the data area (it says points to the top of the jobs area but this is a typo). It doesnt point to the command string (although the illustration seems to suggest that). (Qdos Bible, Section 3.0 pp 1-2) The top part of the data area is of course the stack. The language is perhaps a bit imprecise - at least to mere mortals like myself: When you set up a job manually from m/c you specify exactly how big the data area must be. That will include the amount of dataspace you require plus the size of stack you need. When EX sets up the job for you it uses the dataspace specified in the file header, but then adds at least one word (channel count), plus room for the actual number of channel IDs, plus enough space to contain the command string, if any, on top of that again. As the size of this cannot be known at compile time (its entirely up to the user, not the programmer) this has to be in addition to the fixed dataspace size you specified. Since all this is a single, contiguous block of memeory, consisting of the job's private data, it can justifiably be called the data area. Since EX already uses this technique to add the user-specified data on top of the (programmer-specified) dataspace, it didnt seem unreasonable to me to extend the concept to include the home directory string. As it happens, (a6,a5) would then point to the magic marker I suggested in a previous mail - or into the void where, as I mentioned, QLib had no business to poke around. QLib does, of course, know about the space taken up by the channels and command string and so, if it likes, can scribble all over it. It cant scribble over my area as, as far as it is concerned, that memory doesnt belong to it. I hope this clarifies matters. However, the point is moot at present, since it seems that at a different solution is currently the favourite. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
Dilwyn Jones writes: We've down this road many times before, unless Marcel has new ideas to offer I don't really see the point of raising this again. Just because JRH managed to exceed 36 characters in his zip files! Not quite. Ive always lobbied for an advanced new file system. Im now prepared to accept something less ;) The reason is order and sanity. Ive hit the path depth limit in trying to arrange things the way I need to have them, and I rarely use directory names of more than three of four letters. One letter is too limited. Another reason is that many software authors seem to expect their stuff to be stored in the device root. You cant move their stuff to a subdirectory without altering filenames and dependencies. Awful! As a rule, I dont like having more than a page's worth of files or subdirectories in a subdirectory. In five years or so, I'll be desperate! In an indirect way, by defining the pseudo devices like DEV you can work around this to some extent in some circumstances if you are desperate. Setting the base devices for DOS to have longer Windows path names lets me access files in long and deep subdirectories in Windows from QPC2. When you are trying to cope with lengthy Windows network path names to shunt stuff from terminal to terminal at work (which I shouldn't be doing but occasionally need to when I use the office scanner on my colleague's machine and fetch the files using QPC2 on my office machine it's usually the only way because of the path name lengths. Fiddly, time consuming etc but possible if you get desperate. I get by by juggling .win drives, but its not ideal. All the suggestions Per made have merits I guess and if we don't debate them we'll never get them. I just don't get the impression that even Marcel The Miracle Maker will get this done soon! I wouldnt dare to suggest that Marcel should deal with this. I think hes done plenty already! There are other people out there with the skills, or potential skills, to do the job. It doesnt take a genius to write it, but it may take some ingenuity to design it and produce a specification. It would also require some kind of consensus to go ahead, as such a move is almost certainly bound to be traumatic. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
Marcel Kilgus writes: Im assuming that you were answering two different mails here. Forget the QPC 'hole' that got me going and lets look at path depth for SMSQ/E in general: Unfortunately directories have to be read raw, meaning that the format is limited to 36 characters. If one were to overcome this, one would probably have to create a few new real directory traps. After those are established and used in all the applications one could then think about extending them to allow more characters. That would be one way forward, and I did have that in mind as a possibility. But I can already hear the whining but I can't adapt my application to use the new traps as then it wouldn't be QDOS compatible anymore, so I probably just don't bother. Not trying to discourage anybody else, of course, it's just my view of things. There are a number of different defenses to this argument: 1) Ignor Qdos as such a DDD neednt apply to low-end devices such as floppies The recent questionnair should be able to answer the question: What percentage of QLers use both Qdos AND hard disks [HDD] (a small percentage I would think) Minerva and emulator users can upgrade the OS. Hardware Qdos users with HDD would have to migrate to new hardware - or stagnate. 2) We could use a method that could be added on, eg a) utility Things b) trap #3 (extendible even in Qdos) c) a new System Services trap, eg adopt trap #[5..15] d) Other ;) I could go on, but that would bore eveyone sick. Ive been pondering this question ever since I realised the full horror of the current implementation (back in '87 or therabouts). Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Lynx 282
Kjartan Geble Olsen writes: Norsk? But I can already hear the whining but I can't adapt my application to use the new traps as then it wouldn't be QDOS compatible anymore, so I probably just don't bother. Not trying to discourage anybody else, of course, it's just my view of things. Is it not time to let 'old' applications die? The qdos filing system is in my opinion the one thing that renders the ql useless, I can live with limited screen resolution and 24Mhz, but not the file system. Agreed! Can't say that I really use the ql anymore, although I just upgraded to the colour version of smsq and bought Qword.. Very interesting! I had an inkling that good, colourful games would revitalise the interest in the QL, which is why I set out to produce a couple myself. (Sadly, I havent got round to finishing mine yet, due to design-creep and some very colourful bugs. But theyll arrive eventually, inshallah) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
François Van Emelen writes: Perhaps we should have another bash at finding a solution to our debilitating filename length problem? snip Let battle commence! Per What about QVFS QDOS Virtual File System by Hans-Peter Reckenwald? François Van Emelen I did mention this (option 2) I tried it a long time ago. It works alright, but I wasnt too happy with some of the design desicions HPR made. It is a possible starting point, though. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Or a completely different proposal: Lets take the standard job as the starting point. Dealing with QLiberated or Turboed jobs need some special treatment. When a job is first started it has a code area and a data area. If there are open channels or a command line the Basic keywords EX (and family) adds the space this data requires to the dataspace and stacks that data on top of the data area. It would not be difficult to stack the home directory on top of that again thus: Home directory Command string Channel ID Channel ID number of channel IDs Data area At present (a6,a5) point to the top of the data area. This could now be the pointer to the directory string (alternative registers could be used instead, if better). Since the data area is private to each instance of a job, the Home Directory [HD] could easily be dynamic, ie a Current Directory [CD] instead/as well. Id propose the following format for the HD/DC area: (magic word) full file name lengthword directory length word string bytes bytes padding to 42 bytesbytes There would have to be some way to flag that the HD/CD was present: eg an additional magic word at the top of the structure, or some other method. For Sbasic one could simply extend the Save Name (to call it something. That is the name that is stored somewhere when you SAVE your program) system currently in place. Ie some additional keywords to read or change the Save Name string. QLib compiled programs pose a challenge as we dont have access to the compiled job's initialisation code to access that information. However, there are other, more plodding, ways to find a job's data area and locate the HD string. Thus a function such as HOMED$ or CDIR$ to read the HD string would have to work differently in compiled and interpreted mode. Thereyougo. Now shoot it down in flames! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
