RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
On 24 Oct 2002, at 14:49, [EMAIL PROTECTED] wrote: Must send my SMSQ source CD back to Wolfgang so I can get the updated one. I'm ready... Wondering whether Jochen is about. I emailed him about the Qmake disk I bought at the Byfleet show but have not had a reply. I'm pretty sure that if you haven't had a reply he hasn't got your email. he generally is pretty responsive. Just looking at the hard disk details. On a disk with a single QWA partition on it, which physical sector would that information be found in? the very first sector. wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 5 Nov 2002, at 8:46, Phoebus Dokos wrote: Wolfgang, I was under the impression that Peter had acquired (ie paid) the rights to resell/modify SMSQ/E... Not that I know of Even it isn't so, I do not believe that DD would want to hijack the software only that there's an honest misunderstanding somewhere I hope :-) I've kept my fingers crossed for so long now that I can't undo them anymore. But I DOUBT. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 5 Nov 2002, at 10:05, Öïßâïò Ñ. Íôüêïò wrote: Now that's an interesting thought :-). However Bill, that's (legally) up to the software license. If it doesn't EXPLICITLY state that for every platform you NEED to have a separate copy of the software (I haven't read the finalized license in length but I seem to recall that once you have one legal version of SMSQ/E you can use the other ones) then a current SMSQ/E owner doesn't have a problem getting SMSQ/E from another source... (...) (Sounds complicated doesn't it?) Actually, it's pretty much simpler (oufff). No reseller may sell a new copy of the compiled code to you unless he abides by the licencen meaning payment. Thus, if you already have, say QPC, and buy a new one and get a new copy of SMSQ/E with it, you pay again. If you get an upgrade for QPC, you don't pay again. Same thing with the Q60. You buy a new Q60 and get sold a new SMSQ/E, you pay (again). Not so difficult, is it? If you did get a new copy and the reseller didn't abide by the licence, then you have a pirated copy. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 5 Nov 2002, at 9:36, Bill Cable wrote: Wolfgang, What if you already own a current legal copy of SMSQ/E in QPC2 or some other way when you buy a Q40/60 as many already do. Surely you do not have to buy it twice. -- Bill Under the licence you do, because you get an entirely new copy of SMSQ/E -not an upgrade. Wolfgang - www.wlenerz.com
Re: [ql-users] Pirates and mad sheep
Tony Tebby wrote: (rest of message clipped). I just hope that this put some doubts to rest. And again I appeal to DD - let's get on with it, correct the situation, it isn't too late yet. Wolfgang - www.wlenerz.com
Re: [ql-users] SMSQ/E License
On 7 Nov 2002, at 17:07, Dave P wrote: (different possibilities on different machines) I don't know what I'm doing wrong, but, obviously it is something. I distinctly seem to remember that, as long as something is useful only for one machine, I see no problem in putting it in the code for that machine. COnversely, it does without saying that machines that don't have a facility (your example of mdvs is great) then they don't have it - Q60 or the Atari don't have mdv code and why should they? On the other hand, if some new functionality exists for a machine which can be useful for other platforms, why exclude it? Wolfgang
Re: [ql-users] Software pirates in our midst?
On 7 Nov 2002, at 23:21, Mike MacNamara wrote: (...). Which license would it be under, old or new?? This would be the new licence. But, anyway, for the end user nothing much has changed, apart from the fact that, if they are technically literate, they can get the sources and tinker with them. Sorry Roy, I'm answering in your stead... Wolfgang
Re: [ql-users] Quanta Claus is coming...
On 7 Nov 2002, at 21:11, Michael Berger wrote: Hello Everybody! I am SO tired of that endless piracy discussion. Do you really believe anybody likes it? On the othe rhand, if there is really a problem like that, shouldn't you be told? (..) This is my advice to the involved parties: get your duel pistons out, involve lawyers, Let(s hope it doesn't come to that. do whatever you want - but please stop using this community like a hostage! I wasn't aware I was doing that. Telling the community about a problem in its midst is not holding it hostage, if believe. Wolfgang
Re: [ql-users] Software pirates in our midst?
On 7 Nov 2002, at 21:46, dndsystems1 wrote: But he has asked you, correct. Not after the licence came into force correct... You have not told him, correct. So I do not know, correct. You are selling them. correct. You must ask correct. You didn't still correct. etc... This is a redundant address that I use for reading this list, nothing else. If anything other than this list tries to come in it is deleted as spam automatically. If I use another computer to read the list nothing gets deleted and I can see all. This is when I caught Dilwyn Jones, Tony Tebby, Alex Wells and maybe one or two others using the wrong address. I always try to reply using my correct (different) address hoping they will catch on. How nice of you to explain this now And strange how you got all other email but mine... If anyone wants to contact DD Systems the front door is [EMAIL PROTECTED] as in all advertising for over a year. Postal, fax phone are all included. Look on the web www.q40.de. Where is the hard to contact bit? Simple - I used the email you use here. Of course, now you tell us that all other email goes in the bin... Also, don't forget to mention that I emailed Derek directly - he gave me a choice of 2 email addresses one of which I used. Had he told me to use only one, I'd have used that only. Nobody has been given the Supanet address above to use. It was used 2 years ago for a different purpose, it has never been public. It was used on 14th of june 2002 - which is where I got it from and emailed you. My Email to Tony Tebby was on 08.10.02 18:44 ? Now what? I think you have had his reply... Dennis - DD Systems Just to make things clear - is the above email address, i.e. [EMAIL PROTECTED] the one you are asking me to use in reply to my earlier message on this list? Wolfgang
RE: [ql-users] Mention in PC Plus
Hey Norman, Is that you mentioning QPC UQLX in PC Plus? When are you getting a regular column? :-) Wolfgang - www.wlenerz.com
Re: [ql-users] QPC and QXL.WIN
On 8 Nov 2002, at 15:34, François Van Emelen wrote: Hi, Is there a way to hide the 'QXL.WIN' files to avoid accidental deletion from within 'QPC' ? You can set (under windows) the attribute of the file to read only. That way you can'r write (delete) anything to/from the disk. If you want to hide the entire file from QPC, just give it another name, and it won't be found as a HD. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 8 Nov 2002, at 12:18, Mike MacNamara wrote: Hi Wolfgang That's what I feared, if I need any further support on any of my existing copies, or indeed updates or fixes. I will have to buy a new license and lose the old ones. Umm, sorry where did that come from? All we were talking about is what happens if you buy a new copy of SMSQ/E... For support, contact whoever you bought your copy from. I have no doubt that the remaining QL dealers will give you support if you bought SMSQ/E from them Asto updates, I have yet to hear of a Ql dealer who refused to give you free upgrades (provided they were free) Glad to note that the Wolfgang vs DD skirmish, was mostly down to a lack of communication. Ok, let's call it that, then. And despite Michael Bergers protests this list has been the catalyst in resolving the matter before it had gone to far. yes - hopefully. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 8 Nov 2002, at 11:47, Tony Firshman wrote: (...) The best course is to stop thinking, How do you do that? Does it happen often to you?... grin Wolfgang - www.wlenerz.com
Re: [ql-users] Pirates and mad sheep -a deep groan
On 8 Nov 2002, at 17:15, Dave P wrote: (...) Now that we've had two or three different problems with the license, and Wolfgang has given various reassurances (which has been a positive experience, Wolfgang!), Thanks, but this begs the question - have I been acting in accordance with these reassurances? (Just BEGGING for a compilment here, of course). maybe we can amend the license a little to make these assurances explicit? It's november. Maybe we could make the relatively minor changes and have SMSQ/E license v1.1 come into force on January 1st? Oh groan. Groan. Groan. groan. Mind you,I'm not saying no - just, well, groan. Do you really want us to go through the entire debate again every year? I'm not looking at this as a way to squeeze more out of the license, No comment... but merely to tidy up those parts that have alrerady been found ambiguous? Maybe Wolfgang would like to submit the license to annual review, as the situation will change over time? Actually, I wouldn't like it - but if there is really a demand for that, I'll do it. Wolfgang - www.wlenerz.com
Re: [ql-users] Pirates and mad sheep
On 8 Nov 2002, at 16:00, Dave P wrote: Well, that's illegal in every European country. Once someone owns a license to software, they're free to sell it to whomsoever they wish under the first sale doctrine. You cannot restrict someone's right to sell something they own, even by license, once the first sale has occured. You can only require they place the same conditions of sale on their buyer as you placed on them. Unfortunetely, things aren't as clearcut as that. 1 - Remember that a licence is a licence to USE... 2 - There is a huge difference between a user who has bought a licence to use a software and a reseller who buys the licence to resell the software. Wolfgang - www.wlenerz.com
Re: [ql-users] QL Calendar for 2003
On 9 Nov 2002, at 9:16, Jonathan Dent wrote: How about: Everybody takes their QL stands in front of a local famous landmark and gets someone to photograph them. What, you means with us in the picture, too? Hey, It'll be the the QL Horror picture show, then... Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 8 Nov 2002, at 21:10, Tony Firshman wrote: Not often enough (8-)# Hmm I wuld have thought Never mind. :-))) Wolfgang - www.wlenerz.com
Re: [ql-users] SMSQ/E License
On 8 Nov 2002, at 22:21, Malcolm Cadman wrote: There seems to be some confusion around SMSQ/E's 'core' and its 'flavours'. It seems to me that Wolfgang has taken on the onerous task of maintaining the integrity of SMSQ/E so that it remains consistent and coherent, and that all users - irrespective of platform - get access to all the 'new' features. Yipee yey! Hooray! Somebody understand what I'm trying to do. Wolfgang - www.wlenerz.com
RE: [ql-users] Mention in PC Plus
On 8 Nov 2002, at 17:13, Norman Dunbar wrote: PS. Note that they are asking for emails/letters from people who use emulators - why not all write in, they might even do an article on us 'retro-dudes' ! Well, I will, but not living ointhe UK I will have little impact. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 9 Nov 2002, at 14:45, dndsystems1 wrote: I have called Wolfgang a fool on this list for using the wrong address while I was waiting for his incomming. :-))) Oh dear, oh dear, oh dear. How wrong can things go? Wolfgang, the above mess is DDs fault. Please accept my apology on behalf of DD. I will not call you a fool again but can I still call you WolfGanster - sorry just kidding. Dennis, I've sent you a long private email in reply to the private one you sent me - I told you there, there is no need to apologize in public. Sorry apparently it came too late. Perhaps you can tell me whether you got my private email ? Can we work something out from that? Wolfgang - www.wlenerz.com
Re: [ql-users] QL Calendar for 2003
On 9 Nov 2002, at 23:42, Marcel Kilgus wrote: Tony Firshman wrote: ftp://ftp.franken.de/pub/people/m/pix/comp/QLs_and_Zwiebeltuete-3-s.jpg he he - who is that? What a crank. Wolfgang - www.wlenerz.com
Re: [ql-users] Mention in PC Plus
On 10 Nov 2002, at 11:23, Dilwyn Jones wrote: Aha...a possible future editor of QL Today perhaps ;-)) Oops, youre thinking of resigning? Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 10 Nov 2002, at 0:28, Roy Wood wrote: (...) Wolfgang is the person who could incorporate the 'patch' into the distribution not DD. Yes, then it wouldn't be a patch anymore, of course. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 9 Nov 2002, at 19:31, Roy Wood wrote: You could be saying there has to be a version of SMSQ/E specially for the Q60. If so you must discuss this with Wolfgang. If there was a differnce between the Q60 platform and other platforms (e.g. the Q40), that could warrant another version. It wouldn't be too much work, but I would, of course, have to be made aware of it. (rest cut) Wolfgang - www.wlenerz.com
Re: [ql-users] Ooo! What's happened
On 9 Nov 2002, at 18:42, ZN wrote: The key to it is not to have a wife ;-) A friend of mine used to say that you have a counter argument if she has her own set of toys. Then he got married and had all the proof it wasn't so :-) yes, strangen, that, isn't it? Wives never have toys, only useful things. Wolfgang - www.wlenerz.com
Re: [ql-users] Software pirates in our midst?
On 9 Nov 2002, at 19:44, Roy Wood wrote: In message [EMAIL PROTECTED], Derek Stewart [EMAIL PROTECTED] writes I am comming to the London Show with a Q60, I hiope things can be sensible. For my part, as I told Derek privately, my emails may seem a trifle 'spirited' but there is no personal malice involved. All I want is that we get it right. So, perhaps, we can get something rolling. I'd just like to let the list in general now that DD and I are speaking an trying to get everything done OK! With regard to the payment thing I think that we each should bear responsibility for our own sales. That said I think that an SMSQ/E Citibank account would be a good idea. We could all pay in, email the remittance advice to Wolfgang and let him pass it on to Tony. Ok, I would have no trouble with that. (poor sales) no surprise there - www.wlenerz.com
Re: [ql-users] Toolkit keywords list
On 10 Nov 2002, at 13:05, Dilwyn Jones wrote: François Van Emelen's toolkit keywords list is now available from the QL Documentation page on my website, as a plain text file. Great Work François! (warning: about 102KB download!) (why not zip it?) The QL Net links page now includes a pointer to the World Of Spectrum pages, from where you can find copies of the QL Manual and QL Service Manual in Adobe PDF format in the Technical Docs section. By following the link from my QL Net page to Javier Guerra's Sinclair QL Spanish Resources page, you can also find a copy of the QL Service Manual in HTML format. What a service to the community! Wolfgang - www.wlenerz.com
RE: [ql-users] Mention in PC Plus
On 11 Nov 2002, at 9:42, Norman Dunbar wrote: Morning all, I'll try to combine all replies into one email - I don't want to hog the list :o) MARCEL : (...) I don't have the magazine any more (I'm not that vain !) but maybe someone else still has it and will scan it for you. Yes, I can do that (tomorrow) () Wolfgang - www.wlenerz.com
Re: [ql-users] Qeymail, last call for suggestions...
On 11 Nov 2002, at 13:33, Dave P wrote: > Finally, how important would it be to use a pointer environment, or would > you be happy to use industry standard CTRL-key combinations? For, it would be PE, Prowess or nothing... If you want, I could probably rapidly build you a prototype PE application, all in Sbasic, to which you could add later. Prowess would take a bit more time... Wolfgang
Re: [ql-users] Core software and Q60
On 12 Nov 2002, at 14:01, TonyTebby wrote: The specific solution is to re-write the QL colour mode driver to eliminate all MOVEP instructions. I had started this work before passing the partially modified MC68060 routines over to Peter Graf. The modified code works on earlier processors, but is not as fast. It is, therefore, necessary to provide separate MC68060 and MC680x0 versions of the GD2 QL mode drivers, even though they are 99% the same. This is exactly what happened in fact. Fabrizio Diversi took the code in the sources, removed the MOVEP instructions from it by replacing it with other instructions. He then renamed the resulting modified files AND MODIFIED THE Q60 link files, to point to the new files. He then passed that on to me. So now, the source tree had two versions of certain files, some specific to the Q60, others still perfectly the same. One of the registrar's jobs is to ensure that the modifications are properly recorded. They are :-). You can'tbe more explicit that I am in the changes_txt file! In this case, he would have to ensure that the lower performance MC68060 version did not crawl through into the standard versions. Exactly. I'll also have to check that, if in the future one of these two versions is changed, the change shouldn't also be reflected in the other version. Naturally, other suppliers of MC68060 based machine could use this version because it is in the open source. The Q60 developers would, however, be quite justified in asking for 1% of the price they paid for the Q40 version of the GD2 QL driver - 1% of nothing is not too much to ask for, is it? In this case, Fabrizio is playing entirely by the rules and hasn't asked for any money (nor has Marcel Kilgus for the other code developped by him). Wolfgang
Re: [ql-users] gold card and SMSQ/E
On 12 Nov 2002, at 17:58, Andreas Berger wrote: Hi, i have heard that SMSQ/E is free for users of Gold Card/Super Gold Card. Can anyone enlighten me? regards, Andreas No, SMSQ/E isn't free for GC or SGC users. As with all other SMSQ/Es, there is the 10 EUR payment to TT, and then whatever amount a dealer wants to charge you for the service provided. Wolfgang
Re: [ql-users] SMSQ/E
On 12 Nov 2002, at 10:57, Dave P wrote: On Tue, 12 Nov 2002, Wolfgang Lenerz wrote: The relatively small take up is also the reason I haven't yet seen fit to call upon Dexter's help for setting up a website for the sources. For those who missed out on that conversation, I offered Wolfgang a password protected site where developers could upload/download and exchange/communciate code changes - Wolfgang would issue usernames/passwords to people who asked him to join the 'developer community'. Yup, that's right. Dave, do you think it would be worth it for such a small base? Wolfgang
Re: [ql-users] Core software and Q60
On 12 Nov 2002, at 18:29, TonyTebby wrote: (and, hopefully, functionally identical !!!) Yes! OK, so if the open source system is working fine, why are some people making such of fuss Beats me. In this case, Fabrizio is playing entirely by the rules and hasn't asked for any money (nor has Marcel Kilgus for the other code developped by him). This, of course, does not stop generous users or groups offering such developers donations to encourage them to make improvements that they would like to see, does it? No, of course not - as you are well aware, the licence also allows for that... I don't know if Fabrizio has had any reward other than the Golden Glow from helping other people, but the total revenue earned by Marcel for QPC, or the brothers Graf on the Q40 or . cannot come anywhere near the real cost of the work they have done. I don't think anybody ever said that. We all know how it is in the Ql World... The rules don't say that developers cannot be rewarded, do they? No (not yet :-))) Let's see, what did Dave want to change in the licence? Wolfgang
Re: [ql-users] Core software and Q60
On 12 Nov 2002, at 12:27, Dave P wrote: (...) If someone where to, say, make a TVToy, they should be able to drop all of the redundant modules of SMSQ and alter others as appropriate, and submit to Wolfgang and have an official branch for that specific application. Just to go on record (AGAIN), nothing in this licence stops this from happening, I've ALWAYS stated that I'd be open to suggestions in this respect etc. etc. etc... It would not help the main SMSQ branch much, Who knows? (...) Wolfgang
Re: [ql-users] Mouse on the Q40
On 12 Nov 2002, at 19:37, Phoebus Dokos wrote: I have a problem with the mouse. I am using a MS compatible 3 button serial/PS/2 mouse (worked great with superHermes and the regular QL using Sermouse) but isn't recognized by SMSQ/E... is there anythin I need to run? (I tried sermouse but it doesn't work with that either...) I've always used a normal serial mouse. That has worked w/o any problems - what kind of Serial/PS2 converter does it have? Wolfgang
Re: [ql-users] SMSQ/E
On 12 Nov 2002, at 21:45, Dilwyn Jones wrote: available from (um Dilwyn's web site ?) Ummm, no, but I think I have the sources of some of Chas's programs, which he sent me when re released his ex-DP programs. Not sure if that includes compare...must have a browse. -- Dilwyn Jones I have the source for Compare, but can't remember at all where I got it from. Wolfgang
Re: [ql-users] SMSQ/E
On 12 Nov 2002, at 12:53, Dave P wrote: Dave, do you think it would be worth it for such a small base? There is a conflict with the license, because electronic distribution is not allowed. Wrong. This was one of the concerns you had already expressed earlier during the discussion about the licence and the licence was changed to take that into account, to wit: quote E Developer versions The registrar may set up a system whereby identified software authors may have access to, and possibly exchange among themselves, source code or binary versions being actually developed. unquote :-)) Wolfgang
Re: [ql-users] GD2 and Hardware
On 13 Nov 2002, at 9:54, Malcolm Lear wrote: > > I was wondering if anyone can explain why programs such as > POV Ray only work on Qx0 machines. Mainly because they check whether they ARE running on such a machine, and, when not, just give up. The reason: The Qx0 on the one side, and QPC/QXL on the other side have incompatible High colour modes. The Qx0 has mode 33, QPC/QXL mode 32. In both cases, when you look at the data representing on pixel on the screen, the colour is coded on one "word" (16 bits). For mode 32, this is coded as: gggb rggg where for mode 33 this is coded as: grrr rrbw (where W is 1 if any two of the highest bits for the other colours are 1) In many applications that doesn't matter, since, when writing to the screen they just use the OS (SMSQ/E) which handles the "painting" onf th epixels correctly. Other software, however, such a POV, will write to the screen directly, this writing a word for each pixel into the screen memory. To avoid getting funny colours all over the screen, this software checks whether it runs on a machine that has the corresponding mode - if not, it gives up. Other software is a bit more intelligent (accomodating?) and paints the screen corresponding to the mode it runs in... > I can see that the > colours would be incorrect on other platforms such as QPC, > but don't understand why they refuse to run. With all this > talk of maintaining OS compatibility on different platforms > it seems strange that a lot of new software has major > problems dealing with something new like GD2. As there are only really 2 major high colour screen formats, and as there only thing one really has to do is some byte shifting, software could/should be written to take both formats into account - IF you really have to write to the screen directly! Wolfgang
Re: [ql-users] New WMAN (was: GD2)
On 14 Nov 2002, at 1:35, Marcel Kilgus wrote: WMAN should really be updated to GD2 - any volunteers? That'd be me again, then... In fact I'm almost done. Since yesterday all routines accept the new colour word definition, only a few more lines for the system palette are needed. And some sensible defaults for that palette (which'll probably be the hardest task). Three cheers for Marcel! Please be reminded that his work will benefit all platform physically capable of it! Yes, there is, I called it ws_scach. And yes, I'm not good at names. You're pretty good at everything else I hope so. I want to tie up some lose ends like this WMAN thing before concentrating on the university project. After that I hope others are sufficiently familiar with the code to start contributing, too (it's BTW not only SMSQ/E. EasyPtr should be updated as well, for example. Any volunteers?). Are the sources available? BTW, QPTR pratically doesn't need to be updated - I've done some work on that, and, provided one or two new functions are used, to reduce 24 bit colours to 16 bit and set the correct MS bit, you can use it to produce high colour PE windows from Basic. I'm trying to finish an article for QL Today for that System palette entries (...) Just a couple of questions here: 1 - Does button mean the buttons in the button frame, or also (other) loose items? 2 - I often give my application subwindows different colours to my info subwindows. I'm not sure whether I'm alone in that. If not, we (you!) should, perhaps, provide for it. Wolfgang
Re: [ql-users] SMSQ-E Development
On 14 Nov 2002, at 1:39, P Witte wrote: (...) Quite some work has already been done by various people, such as tidying up the code to make it suitable for general distribution, adding various tools and help utilities, and Marcel has added some significant improvements to the code base which were previously only available to SMSQ-E for QPC. All well and good so far :) Yes, and until now my job consisted more or less to play catchup with the code supplied by Marcel (and Fabrizio). (...development being people driven) There is, of course, no way that I, nor anyone else, can force anybody a) to contribute b) to contribute in any given direction. I DO try to nudge people in the right direction, by asking whether they couldn't do some development in such and such area. As an example, I have asked one person whether he couldn't make the necessary developments for the home directory to be used by jobs. (You do remember that, don't you? :- I am in the process, however, of trying to collect the different ideas different people have given me at different times to have an overview of what should be done. In my opinion, there are, basically, three kinds of projects: 1 - Small improvements (e.g. Fabrizio's italian language support). By small I DO NOT mean unimportant - but they are improvements that can be handled by a single developper in not too much time. 2 - Important changes - the new WMAN and, possibly, rewriting the mass strorage device drivers for more/better/different/true etc directory support and longer filenames, come to mind. 3 - Adaptions to various machines. It is probable that many a development will need to be adapted to some machines more that to others. I had already mentioned the idea of a key developper for each machine, but that hasn't really been taken up. So how do we go about this? We can have a general scatter load approach, everybody doing something in the corner, alone - as you pointed out, this will peter out pretty quickly. Or, as you rightly suggest, we can have some form of centralisation, where, at the least, track is kept of the progress in different areas. The best way, IMHO, would be to have somebody to parcel out the work. However, in view of the fact that the QL scene is pretty individualistic, and that my perceived authority seems to be on the low side, I think this is rather irrealistic... So, your idea of a website could be a pretty good one. The thing that is stoppping me for the time being, is the feable number of developpers. Again, the question is whether it is worth it to go through all of that, just for four or five people. Ok, so the argument will be that if we don't do it that way, nobody else will participate etc I don't believe that for a second, I also don't believe that doing it this way will bring back the Q60 crowd into the fold. But - why not, if there is a sufficiently strong demand for it. (the website could): Hold general information about the project yes. List the sub-projects yes List planned developments yes List the developers and their areas yes - if the developers want. List progress information yes List the resellers and registrar yes Allow downloading of components to registered developers This is the area where I balk the most. By making the sources available to everyone, I still hope to draw people into development, who whould not, normally, have done so. Making a distinction between registered developers and those who are not (and don't have accessto everything) makes me pretty uneasy. As an example, I do not know whether Fabrizio would have become a registered developer? The fact is, that it was decided to keep destribution of the sources in a certain way. Doing it on a website means either detroying this way of duistributing the sources, or introducing a difference between normal QLer and registered developers. If there really is a majority opinion to do it that way (and I would like EVERYONE'S opinion on this) I'll bow to it, though. BTW, what do you mean by component? Moreover, one of the disadvantages of the website will, of course, be that some control is removed from me (at least that is a disadvantage in my eyes :-)). For the time being, most of the developers speak to me, and, as said above, I try to nudge them in a general direction. If we set up a website, the developers will speak to each other. I'm NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it Allow downloading of the latest binaries to registered users That would be a definite no. The users should get
Re: [ql-users] New WMAN (was: GD2)
On 14 Nov 2002, at 2:50, Phoebus Dokos wrote: There is a distinctive problem there provided you've used just what I call bit cropping... ie removing by brute-force the highest order bits from each colour... err no, the lowest oder bits of course... Anyway, the problem you describe is, IMHO, irrelevant here, since you are designinbg a wiondow, and can thus choose any colour scheme you like. It's not a question of displaying a bitmap in this respect... I'm trying to finish an article for QL Today for that We're all waiting :-) You mean, you are all programming with QPTR...? With the major updates that happened to the PE, using a different Window Manager should become redundant I would think It would be a good idea on restructuring it a bit (without losing compatibility) to accept add-ons... Since the PE in general provides a good enough (and known enough most important) framework a new gui (for which I strive for so long) will be a lot easier to construct. AFAIK, attaching bitmaps (ie skins) and high-colour (or should I say multi-colour) icons (sprites) is already possible so by polishing it up a bit every one could build his own window manager in a sense... Actually, it is pretty easy to do so, within some limits. I have here a small progs I use for keeping my dvd colection. This displays the dvds (I scanned the sleeves) and uses, for example, a green triangle as a button (that lights up when the pointer is over it). this was done entirely in Basic - only, it uses RPTR instead of RD_PTR(T) and thus is responsible itself for handling things like pointer in/out of the window/loose item etc... I was able to display higher colours even before Marcel changed WMAN (it also works on the Q60, for example) since it doesn't use WMAN, just the Pointer interface... Wolfgang - www.wlenerz.com
Re: [ql-users] New WMAN (was: GD2)
On 14 Nov 2002, at 13:54, Marcel Kilgus wrote: 2 - I often give my application subwindows different colours to my info subwindows. Ok. How would you call the entries? Info window colours... Appsub window colours... Wolfgang - www.wlenerz.com
Re: [ql-users] Memory
On 14 Nov 2002, at 11:42, Tony Firshman wrote: When one does a reboot with SMSQ/E image file (using LRESPR), I wonder whether the following might work: No, that won't work. SMSQ/E checks the available memory. However, it might be possible to poke a value somewhere before doing the cCALL - I'll have to check that (this weekend). Wolfgang - www.wlenerz.com
Re: [ql-users] WMAN progress
On 20 Nov 2002, at 13:51, Marcel Kilgus wrote: Hi. All things I wanted to integrate into WMAN are now there, Great news! though some still need to be tested. I'm volunteering! (...) The development state is too early to be integrated into the other versions. That will probably follow in December. I stand ready for that... Anybody volunteering for adaption work? Finally, for anybody interested I have attached the current system palette. That should be almost the final version but I am of course still open for suggestions. (...) Marcel has done an enormous amount of work - ALL ALONE! Fabulous. Wolfgang
Re: [ql-users] Easyptr
On 19 Nov 2002, at 20:49, Dilwyn Jones wrote: Anyone have any experience of saving and restoring screen areas with Easyptr under GD2? Can it be made to work reliably or not? I had a quick go and could get it to load (L_WSA) a mode 32 PIC file and display it (using WSARS) as long as the PIC file and the current screen mode were the same, I don't know about Easyptr, but if it uses the underlying PI features, then this is correct - it saves and restores screen areas and expects them to be in the same screen mode when restoring as when saving. i.e. mode 32 pictures could only be displayed in mode 32, a mode 0 (QL 4 colour) pic could not be displayed in mode 32 for example, which was probably predictable. yup. If anyone knows more about this, let me know to save me wasting too much time on something which can't be done reliably yet. (I'm trying to write a simple PIC and SCR graphics viewer for Launchpad using Easyptr). No, that wouldn't really work with these OS (PI) calls, if the images to be displayed aren't of the same screen mode. You would need some kind of conversion program. I can't remember whether the scr format stores the screen format/mode with the file or not - if you need that info, I can find out. What I'm afraid of is a scenario like: I find it only works on QPC2 for example as it's the only GD2 system I have to test it on at the moment! If, again, it uses the underlying OS calls, then is should work on any machine as well as on QPC. It seems to work at first glance, but it's my first significant foray into Easyptr versus GD2, so any advice gratefully received! I have always foun that GD2 doesn't really change anything for programs that aren't aware of it, so that shouldn't be too much of a problem. Wolfgang
RE: [ql-users] keyboards
On 21 Nov 2002, at 13:35, Norman Dunbar wrote: Hi Wolfgang, I always thought you were German - oops ! (Must be the name !) What, Wolfgang is a germanic sounding name? Whatever gave you that idea? I'm living near Paris, though, hence the Azerty... Ok, if you are so clever then, get over here and use a QWERTY - that'll sort you out :o) That's what my first QL had, I bought it in '84 in London. :-) Wolfgang
Re: [ql-users] WMAN progress
(...) Anybody volunteering for adaption work? Actually there's no adaption work required, as usual it will run out of the box. I just need to go through everything again, collect all involved files, etc. I want more of stuff like that! Wolfgang
Re: [ql-users] smsq/e source and Q40
On 22 Nov 2002, at 7:16, Phoebus Dokos wrote: V. 2y99 (If you are talking about this one Fabrizio) is available now for sale (It has been for about a week now). As a matter of fact it's the one I am using now. I have noticed however too that scrolling in general is slower compared to v2.98 Now that is pretty interesting - do you know by how much? It was supposed to be faster! Wolfgang
Re: [ql-users] ALT-ENTER
On 23 Nov 2002, at 17:49, Phoebus Dokos wrote: .. I will wait for the sources and get the fix :-) Haven't they arrived yet? Wolfgang - www.wlenerz.com
Re: [ql-users] WMAN progress
On 24 Nov 2002, at 14:22, P Witte wrote: . However, keystrokes intended for the main window dont get passed on if the pointer happens to be in an AW. ? Are you sure? This is not the behaviour I experience - provided, of course, that the AW doesn't have an item with the same keystroke. Wolfgang
Re: [ql-users] WMAN progress
On 26 Nov 2002, at 17:25, P Witte wrote: iop.rptr does if you set the appropriate bits in the return vector. But Wman calls (wm.rptr) only respond to events (see the Qptr manual, pages 89 ff Window Manager Access Routines) Ah yes, you WERE talking about wm.rptr... AW events are entirely up to the programmer. My point is they are not processed by wm.rptr but by iop.rptr. This explains why there is no reaction to keystrokes defined in the main menu unless the AW happens to be a MSW. Again, I find this not to be the case. Just to be sure, I built a small application with QPTR, a wdw with an appsub window that is not a menu appsub window. I DO get the keystrokes for the Loose Items even if the pointer is in the appsub wdw. I can let you have the program if you want. Now, I know that QPTR uses a special action routine for appsub wdws that aren't menu appsub wdws (and where the call returns to basic at every pointer move keyclick in the appsub wdw), but, unless I'm wrong, the keystrokes for Loose Menu items get trapped by the WMAN RPTR loop before this action routine is ever called. I haven't tried this from assembler, though. Perhaps it's just EasyPtr's way of handling things? The simplest solution here is to use Dummy LIs in your main menu, as described earlier, and then use wm.rptr. However, this may not always be appropriate as MSWs can display a variable amount of data whilst the number of LIs must be pre-determined. Even though it would be possible to generate the LIs dynamically (after all they are size (0,0) generally at position (0,0) so colours etc don't matter) I don't like this solution of dummy LIs very much. I persume, though, that you couldn't do that from EasyPtr anyway, due to the way it builds the wdw (but I could be wrong here). (...) I'm sorry, I don'y use that. I've always found QPTR far easier - but it's a matter of taste! Having tried both, I definitely find EasyPTR easier to use - at least once I got to grips with it. Same here, but with QPTR - I think it's just a question of getting used to the thing. If you really prefer Qptr, you could still benefit from using the interactive design tools from EasyPTR - especially EasyMenu - if you could write a program to convert window definitions into Qptr-compatible SB statements. This might not be too difficult to do. A better way would be a menu designer for QPTR, of course... Would also make it easier for Assembler programmers (...) * I hope all this makes sense ;) It does to me. Wolfgang
Re: [ql-users] WMAN progress
On 27 Nov 2002, at 17:53, P Witte wrote:
Yes please.
OK, enclosed- load outptr_bin first. (lrespr)
Wolfgang
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: p.zip
Date: 28 Nov 2002, 12:57
Size: 14642 bytes.
Type: ZIP-archive
p.zip
Description: Zip archive
Re: [ql-users] WMAN progress
Well on the Q40 (at least mine) I tried to load it and it's impossible to get it to work. There has been a long history with incompatibilities between the Q40 and Prowess. I have managed to get it working, though and working correctly on the latest SMSQ/E (2y99 - else I wouldn't have released it!). For one thing, it is important to get the latest version of Prowess, as can be found on Joachim's site. You should really ditch your old Proforma/Prowess, including, especially, the configuration files (proforma_cfg, prowess_cfg - but keep a backup of these) and use only the one downloaded from the site. At the beginning, use the standard config files. I have found that they work without a hitch coming stright out of the box, as they should. Then you can incorporate the changes you have made to your old config files. I know there was a line in there that causes Prowess (or rather Proforma IIRC) to crash, but I have lost my notes on this problem :-(((. I *think* it was something to do with the font caches, but am not sure. I have also found that sometimes it is easier to split up the startup file into two. My first one looks like this: %% general ProWesS startup file prg_setenv PWSDIR +$PWSDIR_prg;$PWSDIR_ext;$PWSDIR_mine %% first executable thing which is needed rext rext %% load button frame (if doesn't exist) %% rext button_rext Button Frame %% already in SMSQ/E %% load DATAdesign engine %% rext engine_rext DATAdesign.engine %% already loaded %% load PROforma library pf_PROforma $PWSDIR_mine wait PROforma DLL and the second one: %% general ProWesS startup file prg_setenv PWSDIR +$PWSDIR_prg;$PWSDIR_ext;$PWSDIR_mine %% load ProWesS library pw_ProWesS $PWSDIR_mine wait ProWesS %% load some useful executable things rext loader rext setenv rext request rext cbutton rext mbutton rext reader rext calc rext rconfig wait ProWesS reader %% actually set up standard system %% personal_ldr %% mbutton intro -name ProWesS - start here -wait I start them up with something like: EX dev1_prowess_prg_loader;dev1_prowess_startup_1 and EX dev1_prowess_prg_loader;dev1_prowess_startup_2 at different stages of my boot process. I load the same boot for QPC and the Q60, and Prowess works on both systems. (a small advertisement here : I've noticed that the standard distribution doesn't seem to included sprite_pfd, which enables you to display normal PE sprites and is needed for, e.g. Agenda. It can be obatined from me). but I still have problems with its response. I must admit that I do, too. It is not a question of slow loading on bootup - that is not a problem for me as I load so many things on boot that I don't even notice Prowess. However, I think that Joachim's answer about precalculated fonts is the direction to look at. This should make things a bit faster. It is true, however, that opening new windows under Prowess is noticeably slower than under WMAN. Here at the office, I use QPC with a 730 Athlon and there is a noticeable lag when opening new windows (e.g. under Agenda). Perhaps this is something that can be speeded up. would like to use the PROforma part of it used more however. (which I plan on getting into in depth (better late than never) after I sort out what's wrong with it on the Q40. It installed on SMSQ/E 2.91 but I can't really use it with 4 colours now... can I? :-) ) I hope the above help! I use the Proforma part every day, since I print my invoices with it directly from Basic onto a PCL compatible laser printer. Really great stuff, that! The combination of WMAN + PROforma seems more sensible due to the main advantage of WMAN being written in assembly... I am sending you a separate file to illustrate what MY preference would be :-) Good Wolfgang
Re: [ql-users] WMAN progress
On 28 Nov 2002, at 12:15, TonyTebby wrote:
(...)
There are other simpler methods. How about
alert('Hello World') (Javascript)
Wouldn't you need something like
html
head
script language=javascript
(...)
/script
/head
/html
around it?
(makes everything longer)
How about:
open#3,con
print#3,'Hello World'
Perhaps instead of pursuing WMAN, we could try an HTML / CSS window manager?
The main difficulties are the font and image rendering and Joachim has
really mastered that.
Umpf - who is going to do that...
Re: [ql-users] WMAN progress
On 29 Nov 2002, at 4:18, [EMAIL PROTECTED] wrote: WM.RPTR does a lot of work for the programmer, but has a fairly complicated way of monitoring the position of the pointer and any mouse clicks/keystrokes. I wanted to do two things. (...) b. Produce the little explanatory windows after the pointer has rested on a loose item for more than a certain time, as in QD. yu can also do that with wm.rptrt (vector $78), which allows a timeout (much easier!) This is the way FiFi handles the small help windows. (...) WM.RPTR very kindly draws and undraws borders on items as the pointer moves over them. By using iop.rptr, a programmer forgos this facility and has to do it himself. ... which will result in a loop similar to that introduced by wm.rptr(t). 1. The manual (page 86) says that WM.DRBDR is accessed by vector $68. In fact it should be $44. yes, $68 is wm.rname 2. The routine actually seems to perform the same operation for both drawing and undrawing so that the MS bit of WS_CITEM seems not to be used. Is this true? The operation performed is to draw a border of colour WS_CIPAP in the status area. This has to be set by the programmer to the highlight colour for a draw and to the window's paper colour for undraw. After this has been done the routine checks that in fact the pointer is somewhere in the program's window. Fine for drawing - the pointer must be there. Bad for undrawing if the pointer is moved out of the item and out of the program's area altogether before the PE software notices. I solve that problem by ignoring an out of range error on an undraw. Doesn't that mean the the item stays marked as current? wm.rptr(t) checks whether the pointer is out of the window, and, if so, clears the curent item. Wolfgang
Re: [ql-users] WMAN progress
On 30 Nov 2002, at 0:18, P Witte wrote: This is not documented anywhere in my Qptr manual!! (3rd revision) so its the first I hear of it. It looks like its been in the code all along. Ive needed such a call many a time! Apart from the timeout, are there any other parameters? Enclosed a small text file with some explanations. Some of the comments in this are mine. Wolfgang - www.wlenerz.com QPTR Updates The following features are available on the following systems: QDOS, Minerva, SMS2, SMSQ and SMSQ/E. Additional information on WM.ERSTR == This manual did not mention that there is a limit on the length of own error messages. An own error messages is easy to create: LEA own_msg,A0 ; get address MOVE.L A0,D0 ; into our error register BSET#31,D0 ; an error is negative Now the limit: the length of the string is limited to 40 ($28) characters. If it is longer, unknown error is returned instead! Additional information on WM.LDRAW == WM.LDRAW clears the change bit in the status are of every item which is selectively redrawn. Additions to the CONFIG standard The attributes for strings have been extended, to allow menu-driven CONFIG programs better options for a selection, depending on the type. There are two additional bits used in the string attributes: 8 and 9. These define the type of string, so that the CONFIG program can treat these strings in a special way. The possible combinations are: cfs.sspcequ %0001 ; string strip spaces cfs.fileequ %0001 ; string is filename cfs.dir equ %0010 ; string is directory cfs.ext equ %0011 ; string is extension At present, these features are supported by the new MenuConfig, and ignored by the standard config. Undocumented SuperBASIC Procedure = SPTR has never been documented. Easy to guess, it does the same as IOP.SPTR, i.e. moves the pointer to a given position. The syntax is: SPTR [#channel], xpos, ypos [,key] Option Default Meaning xpos, ypos nonenew pointer position key 1 origin key The origin key should be zero if the pointer coordinates are absolute. A key of -1 will set the position relative to the current window definition. A key of 1 will set it relative to the hit area. Undocumented selection keystroke for SuperBASIC === It is possible to put an underscore under a selection key for text loose menu items and text info items. To do this, specify the type to be text minus twice the underscore position. This means, to underscore the first character, give 0-2 (=-2), to underscore the fifth position give -10 etc. The following features are supported on the following systems: SMSQ and SMSQ/E from Version 2.71 onwards only. Additions to RPTR = The QPTR RPTR call has been modified to accept job events in the most significant byte of the termination parameter. The job event values are, therefore, multiplied by 256. Note that while all pointer events that have occurred since the call are returned in term%, only those job events (including pending events) which caused the return are returned in term%. term% = $2001 Return on button / keystroke or job event $20 RPTR #ch, xabs%,yabs%, term%, swnum%, xrel%, yrel%, bt$ Event 32 is notified by another job so the wait is terminated and term% is set. PRINT term% DIV 256 Prints 32 Additions to IOP.RPTR and Pointer Record Bits 23 to 8 of the event vector in the pointer record are already used by the Window Manager. The 8 job events are, therefore, mapped into the most significant 8 bits (pp_jevnt) of the event vector within the pointer record and for the IOP.RPTR operating system call. Note that while all pointer events that have occurred since the call are filled into pt_pevnt in the pointer record, only those job events (including pending events) which caused the return are filled into pt_jevnt. New Pointer Event = Pointer event bit 6 (number 64) is now used to indicate that the pointer sprite has hit the edge of the screen. e New Operating System Calls == -- sms.sevt Send Event Trap #1, D0=$3A callreturn A0 destroyed D1 destination job ID destination job ID D2.bevents to notifypreserved Common error returns err.ijob The events in D2 are sent to the destination job. If the job is waiting for one of these events, the job is released, otherwise all the events are pended.
Re: [ql-users] WMAN progress
On 29 Nov 2002, at 22:42, Phoebus Dokos wrote: Other tricks include: fiddle with the TIMEOUT values, change the scroll value to greater than 200, reduce the shadow to 1 pixel or none -never tried the latter really but I will now that I thought about it-). Use only two colours for everything (I have a nice set of blue). I have to dig up my configuration and send it to you. Why not send it here, so that we can all profit from it? It is. The anti-aliased version comes as a separate download... from where? What would make ProWesS really fly would be a complete rewrite in assembly :-) Any takers? Phoebus - www.wlenerz.com
Re: [ql-users] DJ's new website
On 1 Dec 2002, at 20:15, Dilwyn Jones wrote: Now up and running, the revised Dilwyn Jones QL website! Pretty neat! Wolfgang
Re: [ql-users] WMAN progress
Doesn't that mean the the item stays marked as current? No. WM.DRBDR draws/undraws the border first. Then it checks whether the pointer is in or out of the program's window area. Actually, it's the other way around, wm.rptr(t) checks whether the pointer is out of the window and then, if yes, undraws the border. But here I was asking Per about his way of doing things. In fact I wasn't aware of wm.rptrt until Jim Hunkins reported that it didn't work in C68. But I still don't see how you tell that wm.rptrt has timed out while waiting on a loose item (or anywhere for that matter). If you check when timeout has occurred (incomplete) and look to see that you are now on a loose item, do you check that you were there when you called wm.rptrt? Even then what's to prevent you moving the pointer back to where it was just before timeout? Do you assume that if the position is exactly what it was at exit as at entry no movement has taken place? Well, why would you? wm.rptr(t) does all the work for you, in that, if you move the mouse pointer it draws borders around the current item etc, and will come back from any event generated inside the window. If it comes back without an event being generated, then it has timed out (from Basic, check the event% parameter). If what you want to achieve is something like the little help windows in FiFi, this was done as follows: The user can determine the time the pointer should hover over the loose item before the help window pops up. Say it is 1 second. I read the pointer witt a very short timeout (2/50th sec) and then, when coming back, check whether the current item is still the same. If it is, I loop around until 1 s has elapsed (25 times in this case) and, if it is still the same LI, I open the help window. Else, I note the new current item number and do it again. It would certainly be nicer if you could use wm.rptrt than iop.rptr. However, does that also deal with dragging? No, that is THE big things missing from that loop. Wolfgang
Re: [ql-users] QXL_EXT
On 4 Dec 2002, at 18:05, Phoebus Dokos wrote: (...): QXL_EXT...(...)... anybody have any idea of what they do (well the second one is obvious) and their syntax if any? Thanks, 1 - Look at dev8_smsq_qxl_basic_asm QXL_EXT just loads (modified) CALL and LRESPR procedures. 2 - look at dev8_smsq_qxl_disp_asm DISP_UPDATE number to check, number to transfer (how often the QXL displai is updated. set this to a low value if you wxant more procesing power, a higher value if you want to have a faster screen response) Wolfgang
Re: [ql-users] WMAN progress
On 6 Dec 2002, at 14:10, [EMAIL PROTECTED] wrote: I have successfully produced my own explanation windows now by WM.RPTRT on your advice. However, I look to see where the pointer is on a timeout (comparing the pointer position with each of the hit areas of the loose items). ... thus reproducing what wm.rptr(t) has already done... Wolfgang - www.wlenerz.com
Re: [ql-users]
Just t=o tell everyone that I'll be absent til the beginning of the new year. Merry Chrstimas and a Happy New Year to all of you! Wolfgang
Re: [ql-users] PIC File Format and GD2 Continued
On 3 Jan 2003, at 9:09, Jerome Grimbert wrote: } 1) What is the best way of detecting whether GD2 drivers are present } and in use?? For the time being, there seem only to be the WMAN version numbers. If you can wait a little, I should write a new trap soon (rest cut) OK, so that takes care of sprites. However, there still must be some way to know on what type of WMAN you're running, and what colours are available to your software. I really believe that the various GD2 modes should not be a burden for an application programmer, but an opportunity to choose the best suitable format for the data. Therefore, the usage of GD2 drivers should not add any code (such as which mode is running) into the application. You may want to use the extra functionalities of GD2 if present, but that might impact compatibility. No, of course not,a nd it seems that Marcel has taken extreme care when designing the new WMAN to make sure of cpmpatibility. However, if one is to make use of the new functionalities (such as different colours), one must know just where one stands. Why not use the MODE keyword as used in Basic? This will return some quite sensible values. The thing is that your software must be able to find out on what machine it is running - even if it is running on an old machine. Do you have any hardware which use mode(2,0) ? Yes, Atari monochrome. I only know of QXL/QPC: mode(2,32) and Q40/Q60: mode(2,33) And if you leave the conversion to the system, I really believe that you do not need to know the current mode at the application level: Especially, Imagine that your application has detected a mode and has performed some adaptation to it. And somehow, outside of your application, the user changed the mode after your adaptation, how are you going to react and prevent that ? You don't. If the user really changes the mode in such a drastic manner, then he might be expected to rstart the application as well. Let's not forget that in many cases this will not really be very important: doing a mode call on a high colour system (eg QPC or Qx0) doesn't really change the mode anyway -it'll still be mode 32 or 33 (even when using palette colours!). Are you going to regularly check the current mode and readapt on the fly ? It is really simpler to have the system do that for your application, which means in first place that your application should not be aware of the current mode. How do you set the paper colour of a window without knowing what mode you're in? How do you know what colours are available? Perhaps the easiest way is to do this as follows: First, find you if you're running on SMSQ/E. (print ver$) If not, this can only be an old WMAN anyway, so you're restricted to 4 and 8 colours. Then do a read mode call and take it from there... Offset 7 ? The pic format is: 0 Word tag : 4AFC 2 Word width 4 Word height 6 Word row 8 byte mode 9 byte spare So I guess that you are speacking of offset 9 rather than 7. It might be a good idea to use the spare byte for that distinction. Or we might have a stranger mode specification such as mode(2,0) is 255 and mode(2,8) is 254 (there is no conflict with 4, because QL mode 4 is stored as 0) 255 and 254 are arbitrary value, and we can choose whatever we want, as long as we get it documented and agreed by the Great Coordinator... I'm open to suggestions! Again, I As I see it, there are several problems here. First of all, let's not confuse Sprites with Pics and Psaves (partial save areas), even though they may share some common ground. The problem,as I see it, is that, until now at least, none of these formats was designed to be used in another mode than the one it was used from. This is understandable for Psaves which are mainly used whilst a program is running, and for that program. For sprites, again, a provision is made by the system for having sprites in different modes, the system then automatically choosing the best one for the current mode, and possibly, adapting it (in the buffer) before displaying it. Jéröme is doing quite some work on that! That leaves PIC files. To my knowledge, and as pointedout above, they were not designed as some kind of interchangeable picture file format - even in the old days, you couldn't use it to display a mode 8 file on a mode 4 screen. Is that what is wanted? This will entail a certain number of conversion routines (which will be part of the application doing the displaying of the pic file). Do you want/need some help with that? } } 4) I presume that even if a palette mapped screen mode is used (7,15 } or 31), the program to create the PIC file does not need to concern } itself, as it is storing the pixel information PEEKed from the } actual screen memory. Is this correct, or should the PIC file be } able to store the palette mapping information?? For the time being, there simply are no palette mapped screens. OK, so there are some dark mutterings here and there about
Re: [ql-users] New christmas WMAN
On 7 Jan 2003, at 18:48, [EMAIL PROTECTED] wrote: I think that this bug does need fixing to allow different colours to be used for the scroll bars, but agree that in the case of both parameters being set to zero, the scroll bars should not be drawn (as at present) I'm not so sure - it all depens on how much software is out there that depends on this value not being used for anything other than determining whether a scroll bar should be drawn or not. If (seeing that it isn't used up to now) programs put some arbitrary value in there, just to make sure it isn't 0, these programs would look pretty strange if, in new WMAN versions, this value was taken as the paper value for the scroll bar background... Wolfgang . -- Rich Mellor RWAP Software 35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JH TEL: 01977 610509 http://hometown.aol.co.uk/rwapsoftware
Re: [ql-users] Using WMAN and EasyPTR
On 13 Jan 2003, at 7:41, [EMAIL PROTECTED] wrote: OK, I have tried to create a null pointer. However, can anyone please explain why the following code shows 2 pointers on screen: As I don'thave easyptr, I can't really comment. However, the sprite defintion seems wrong to me 1 - the form should be data 1,0,0,0 2 - , line 7920 should be: 7920 POKE_L BlankPtrAdd+20,0:REMark Pointer to next definition (there is none) 3 - Im' not sure whether the size should be 0 try ti set it to 0,2,0,2 Here is a null sprite definition (in asm) I *Know* works: sp4_vide; this is just an empty sprite DC.W$0100,$ DC.W2,2,0,0 DC.Lsc4_vide-* DC.Lsc4_vide-* DC.L0 sc4_vide DC.L$,$ ; just a transparent sprite I hope this helps Wolfgang - www.wlenerz.com
Re: [ql-users] Size of the current QL market
On 14 Jan 2003, at 18:34, [EMAIL PROTECTED] wrote: Does anyone have any indication of the current QL market?? market ? Wolfgang
Re: [ql-users] QMON2
On 17 Jan 2003, at 10:20, TonyTebby wrote: I used to solve a lot of problems this way but, since I moved to France I have started talking to myself in French. The trouble is, my French is so bad I cannot understand myself. Nor can anyone else... grin Wolfgang
Re: [ql-users] Assembly question
On 17 Jan 2003, at 11:04, Jerome Grimbert wrote: harpo equ $160 chico equ $140 elem_size equ $0c clr.l a1 ; (just to fixe a1 to 0 for the question, ; irrelevant how to if illegal) ; but once a1 has been modified, we cannot have it back ; to THIS value moveq.l #4,d2 lea harpo(a1),a1 myloop: ...; use a1 but keep it adda.w elem_size,a1 ...; use a1 but keep it dbra d2,myloop lea chico-4*elem_size(a1),a1 Question: what is the value of a1 at the end ? (I also have my idea, but I do not want to influence yet!) Ignoring the adda error (should be adda #elem_size,A1) the result should be :original content of A1 + harpo + chico + elem_size. which, using your values would be $160+ $140 + $c = $2AC (in the loop, you add 5 times elem_size, deduct it 4 times later) Wolfgang
Re: [ql-users] Assembly question
On 17 Jan 2003, at 12:30, Joachim Van der Auwera wrote: Wow, very strong. This is the kind of features that make writing (and debugging) assembler interesting. Yeah, right, next you're gonna suggest we switch to 'C'. :-))) Wolfgang
Re: [ql-users] Assembly question
On 17 Jan 2003, at 16:53, Jerome Grimbert wrote: Oh, while you speak of the PE, I will jump in the wagon... I have just found out that blob and mask when used in an information windows (How silly, it would be simpler to use a sprite instead!), seems to have their origin at the screen origin, not the window origin... (whereas sprite are just ok...) Is-that the normal behaviour ? No - I have never seen that behaviour - the strange thing is that the blob and sprite centering routines are the same (ee_wman_drobj_asm)... Are you sure of this behaviour? Wolfgang - www.wlenerz.com
Re: [ql-users] SMSQ/E v.2y99 for Aurora with GD2!!!!!!
On 25 Jan 2003, at 16:04, Marcel Kilgus wrote: No, fortunately not. Otherwise I would be as depressed as Marvin (as anybody hitchhiking through the galaxy should now) ;-) Does that mean that you're an android? Now THAT explains a lot... Don't panic... Wolfgang - www.wlenerz.com
Re: [ql-users] SMSQ/E v.2y99 for Aurora with GD2!!!!!!
On 26 Jan 2003, at 15:51, Phoebus Dokos wrote: He has to be an android as he has been working around the clock apparently... at a certain point he sent me more than 3 versions in less than 20 mins ;-))) (Okay just happened once but you get the idea) Oh well, that only shows that we worked for 20 minutes :-) Wolfgang
Re: [ql-users] SMSQ/E v.2y99 for Aurora with GD2!!!!!!
On 27 Jan 2003, at 7:03, Wolfgang Lenerz wrote: Oh well, that only shows that we worked for 20 minutes Oops, I meant of couse He worked (I didn't have anything to do with it). Just a typo Wolfgang
Re: [ql-users] Feedback and suggestions for new sprted
On 3 Feb 2003 at 12:12, [EMAIL PROTECTED] wrote: I guess what he means, is that it WMAN is not a true sprite handler - ie. although you can animate a sprite by switching between several images in a loop, there is no way of giving a sprite direction and speed, plus collision detection - this is what any games developers desperately need Ah yes, but then we're talking about two very different things here. A WMAN sprite is not, by design, a games sprite. Wolfgang
Re: [ql-users] Display_cde GD2 update
On 4 Feb 2003 at 0:05, Marcel Kilgus wrote: Nice one regarding programming style: I have just spent several hours tracing through the SBasic compiler to find a bug that caused SBasic to crash. The program causing the crash used PROCedures with up to 358 (sic! three hundred fifty eight!) parameters. This was too much for a poor subq.b within the compiler's second stage. A shiny new subq.w can now handle even that one... 358 parameters? To a basic procedure? I'd be MOST interested in knowing what that procedure does... Wolfgang
Re: [ql-users] QLWA documentation
On 7 Feb 2003, at 13:26, Jerome Grimbert wrote: Thanks. At least it clarify a little the structure of the first sector of the file system. (but qwa.pflg for instance lie on the partition list (which I luckily already found and understood) on the first physical sector. It should never appears in the first sector of the filesystem. Here is some info I have on the first sector. Do you need info on the BGM / GEM/ XGM partitioning scheme (if I can find it)? Wolfgang - www.wlenerz.com Main header of device +00 longQLWA +04 wordlenth device name +06 20 bytesASCII device name +1A word ? +1C wordrandom number +1E wordaccess counter +20 word ? +22 wordnumber of sectors (512 bytes) in cluster (4 = 2048 bytes) +24 3 x word ? +2A wordtotal clusters (1) +2C wordfree clusters(1) +2E wordsize of FAT? +30 word0001 ? +32 wordpointer to first free cluster (2) +34 wordpointer to main directory cluster (2) +36 longlenth of main directory +header +3A 3 x word ? +40 words linked cluster pointer map (3) (1) virtual values if device 33 MB (2) if cluster = 2048 bytes (h800) then pointer x h800 = address (3) Linked cluster pointer map: +0040 word pointer to next cluster or if end +0042 word pointer to next cluster or if end ... + word same until all clusters are pointed Example reading main directory (win about 20M): +0022: 0004 cluster = h800 +0034: 001A x800 = address hD000 = DIR now look at (001A x 2 + h40 = 0074) if then main directory has no more clusters else for exemple: +0074: 1939 ; x800 = address hC9C800 more entries now look at (1939 x 2 + h40 = 32B2) +32B2: 2605 ; x800 = adress h01302800 still entries now look at (2605 x 2 + h40 = 4C4A) +4C4A: no more cluster: end of main directory Structure of directories: DIR+00 64 bytesspace for header (not used) DIR+40+00 long lenth of file (+header) DIR+40+04 word filetype (0=data, 1=exe-file, h00FF=subdirectory) DIR+40+06 word generally sometimes 0318 DIR+40+08 word dataspace if exe-file else DIR+40+0A word generally sometimes 0318 if exe-file ? DIR+40+0C word ? DIR+40+0E word file name lenth DIR+40+10 36 bytes ASCII file name DIR+40+34 long date or if subdir DIR+40+38 word file version DIR+40+3A word pointer to first file cluster (4) DIR+40+3C 2 x word ? (4) Structure of file: FILE+00 64 (h40)bytes of space for not used header (only in the first cluster of file) FILE+40 h7C0bytes of data then search next adress through clusterpointer: see example adress+00 h800 bytes of data until pointer = number of sectors = number of clusters * nbr_of_sects in clusters $8C00 space need for FAT = 2 bytes per cluster = 71680 bytes = 140 ($8c) sectors + $40 for header = 141 ($8d) sectors how to find a cluster in absolute positioning: cluster number * 512* nbr_of_sects_in_cluster
Re: [ql-users] QL User Guide (Advanced ?)
On 12 Feb 2003, at 15:58, Jerome Grimbert wrote: I do not know, but I wonder also if there is somewhere the equivalent of the QL Advanced User Guide, updated for SMSQ/E (with a comparaison of the original QL) ? (Especially the documentation of all the trap calls and vectored utilities) (Documentation of the Basic variables is fine too, but accessing directly the system variable is not a good idea IMHO, even if documenting them is good!) Or I am doomed to write it myself ? How about the QDOS reference guide and the QPTR guide? Wolfgang - www.wlenerz.com
Re: [ql-users] QLtoday and CD
He is currently trapped in the UL (8-)# United Lapland? Ubiquitous Laughter? Unashamed User? grin Wolfgang - www.wlenerz.com
Re: [ql-users] efficient buffer size
On 21 Jun 2003, at 2:41, P Witte wrote: (...) Yes, that is understood. It is in situations where the whole file cannot be read at once, Im thinking about. (Besides, on a multitasking machine it is probably not very polite to grab huge buffers ;) (...) Oh well, if you start worrying about being polite to other programs... :-) I'd still simply grab just as much memory I can use. If speed is of the essence, as you said in your requirements, then the user will probably also know to let the machine alone (tell him!) and not have too many other progs trying to get memory at the same time. If notn, then speed is not that essential, after all. So I'd still go for as much memory as I can get and read in the entire file. If that can't be done (not enough space): Ultimately, it will then be the read operations that slow everything down. Now, considering that iob.fmul fstrg use D2 to indicate how many bytes they should get, and since D2 only can be word sized, you can, at most, read $f bytes in one go. If nothing else, I'd use that as my buffer size Wolfgang - www.wlenerz.com
Re: [ql-users] SMSQ/E v3.01
Hi all, version 3.01 of smsqe is now arriving at your friendly dealer. go get it! Wolfgang - www.wlenerz.com
Re: [ql-users] Dynamic arrays?
On 13 Jul 2003, at 21:01, P Witte wrote: ..plus array slicing, of course ? doesn't that work in Turbo? Wolfgang - www.wlenerz.com
Re: [ql-users] Quanta Workshop in Norwich
On 13 Jul 2003, at 18:03, Dilwyn Jones wrote: On Expect a wayward American missile to fly low over you soon... (just pray it has a QL controlling it not a PC!) No, no, let it have a PC by all means -it'll probably go down somewhere in the ocean (a blue screen of death...) Wolfgang Didn't you know, that's why the Americans call them missiles. Or Miss-iles (they miss their targets) OK, that's reassuring for you (they'll miss the isles) - but I'lm on the continent Wolfgang - www.wlenerz.com
Re: [ql-users] OT
On 15 Jul 2003, at 12:05, Dilwyn Jones wrote: Anyway, you'll never get hit by anything British, not because British bombs and bullets are accurate but our poor soldiers end up having to borrow and scrouunge American kit and bullets while overseas... Is that the newspeak for friendly fire? Wolfgang - www.wlenerz.com
Re: [ql-users] Bugs
On 9 Aug 2003, at 20:39, P Witte wrote: Ive recently discovered the following bugs in Smsq/e recently was a long time ago. - I'm slowly working up my backlog. PRINT PRT_USE$ crashes Smsq/e since at least version 2.98 on QPC2 (and QPC2 itself). Yes, confirmed, I'll have a bugfix soon. (Monday). PARTYP, PARUSE, PARNAM$, and PARSTR$ dont work on Smsq/e 3.00 and 3.01. Ok on 2.93 and 2.98 I'll have a look, I haven't had time to confirm/deny. Can anyone confirm? (Save your work first!) see above Is there somewhere to report bugs in Smsq/e? Preferably it should be somewhere where they can also be looked up by others who are experiencing problems or who are out looking for something to fix.. in view of the underwhelming response to that, I presume that you'd better report bugs to me and/or the list. I'll try to pick up all bugs reported. Wolfgang - www.scp-paulet-lenerz.com
Re: [ql-users] Isn't it open source?
On 15 Oct 2003, at 10:56, Phoebus R. Dokos (Φοίβος Ρ. Ντό wrote: (...) Well that's restriction 1... As seen below you have to be able to distribute legitimate copies both in binary and in source form so... it's not OK That's the restriction, alright. (...) To your (*) that alone breaks the premise of Free Software. Plus that you really do not have FREE access to the source code (Free as in Freedom) as the Source code is only available by the registrar. Although it is free (as in beer to get) that's not the point. There should be the possibility of multiple points of access to the code (ie me putting up a website where everyone that wants it can download it). Well, you CAN give it away on a CD, it's just Web access that is restricted. To that I have to add that I have no problem paying for media and shipping charges when I get the source code in a CD, from you or anyone else. Yes, I don't think that's the problem. (...) As I said I have no problem with the money part. Indeed I find it better than charging money (although it might help to charge copying fees maybe that could even be sent to TT). OK, let's forget the money part, then. However you are not *REALLY* allowed to distribute copies as a further distribution even unmodified turns the software into unofficial! (It's in the license). A copy made by a third party (accepting the money precondition as it stands now) should be official in itself. Why? Define official. Is there an official linux? No, of course not. If you were to make enormous changes to the source code, distribute it with instrctuins to compile and and everybody used that, would the official bit make any difference? () Again I beg to differ. You HAVE to be able to distribute binaries. As you said, there we difer. Plus if you want your changes to be part of the sources we HAVE to notify one person only. A decision is not made collectively which defeats the purpose. It's fundamentaly different (and this is in no way a critisicm on your objectivity personally, just a fact) when one person is in charge than a set of persons operating in a democratic environment. I prefer the latter as it fits my personal set of beliefs. Ah, I see where this is going now. Yes, I can understand that. So, you want a say of what goes into the sources or not. Seeing as many of us can't agree on what direction everything should take, getting a general agreement will not necessarily be easy - opr even feasible. The freedom to use a program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job, and without being required to communicate subsequently with the developer or any other specific entity. Still true here. Not really if you use binaries created by you, these are unofficial So what? (...) There is a restriction here for the binaries. Exactly right and it's a big obstacle to the free software idea. Moreover from the wording above that means also that when sold SMSQ/E should also include the sources if the user wants them Well, I would really take exception to the sources being sold. There is nothing to stop a reseller to sell a copy of the binaries, and distribute the sources along with it, for free. You do have this access. Not really. Free access in the internet age, means that the software can be accessed by anyone at any time (ie on a server) via CVS or otherwise. Even if you do not choose to do so, somebody else that has the sources should be allowed to give the sources without them being deemed unofficial. It's logical to have a central point of access to maintain uniformity, but acceptance of this should be voluntary by the users (I don't know of anyone that wouldn't agree to this as long as they HAVE the option) and not compulsory. Now users don't have that option. It's a matter of perspective first and foremost. Everyone would prefer to get their sources from the official point if they were given the choice, but this HAS to be a choice. Again you can distribute the sources (though not through the Internet). I fail to see why that is so paramount. (...) Not all of it but anyway, I think I made my point too :-) Happy you did. Wolfgang - www.scp-paulet-lenerz.com
Re: [ql-users] Re SMSQ Gwass
On 17 Oct 2003, at 15:56, Tarquin Mills wrote: (...) There is no technical reason why 68020+ instructions cannot be assembled in an easy way on all 68K based environments. That's not the problerm - the problem is that GWASS doesn't run on sub 68020 machines. From the point view of versions of SMSQ/E using 68020+ instructions, why is it assumed that Atari users own sub-68020 based Ataris. Yes, you're right - I just hapen to own one. Also there is no technical reason why any complete software emulator cannot emulate a 68020+ rather than a 68000 or 68008. Why does the Amiga always seem forgotten? I wasn't aware that there is an SMSQ/E for the Amiga. Wolfgang - www.scp-paulet-lenerz.com
Re: [ql-users] Re:smsqe 3.03
On 22 Oct 2003, at 19:37, Roy wood wrote: (...) You have just broken your own licence ! Well I AM allowed to send it out for testing purposes, and it obviously was intended only for you, not the entire list. So the intention was OK, at least. Wolfgang - www.scp-paulet-lenerz.com
Re: [ql-users] Re:smsqe 3.03
On 22 Oct 2003, at 17:30, Wolfgang Lenerz wrote: Hi Roy, This is what should be the final version of SMSQ/E 3.03 for the GoldCard. Would you lminbd having a look at it, to see whther is now (!) works OK bvefore I release it? It works here, but I remember you having had problems before. Oh dear, I really shot myself in the foot there, didn't I? This of course was a private message meant for Roy Wood. Sorry! Wolfgang. - www.scp-paulet-lenerz.com
Re: [ql-users] Re:smsqe 3.03
On 22 Oct 2003, at 23:25, Marcel Kilgus wrote: I dont suppose it was intentional Definitely not. Bloody right. (...) Yes, fortunately the version didn't include my GD2 aurora driver. It never does. Wolfgang - www.scp-paulet-lenerz.com
RE: [ql-users] Re:smsqe 3.03
On 22 Oct 2003, at 21:52, Duncan Neithercut wrote: I dont suppose it was intentional and its not Wolfgang's licence but its TTs SMSQ/E licence, but if you are interested I was sufficiently interested to test it on my Aurora setup. Aurora, Supergoldcard 2.49 Qubide 2.01. After approx 1.5hrs initial conclusion is that it works OK in mode 4 including window move but crashes immediately on boot if the initial colour depth is set to 256 instead of QL. Once in QL colour it cant be set into mode 16 or 256 colour that the Aurora supports. Hope that helps Yes it does, thanks. The version I distribute fdoes not have the high colour drivers in them, so it is not surprising that you can't use them. I should, though, take the corresponding config item out, of course. Wolfgang - www.scp-paulet-lenerz.com
Re: [ql-users] Re:smsqe 3.03
On 22 Oct 2003, at 23:23, Tony Firshman wrote: This could save future embarrassment - I can feel the heat from Wolfgang's ears from here (8-)# Yup. I'm just baking bread in them. He isn't the first to post to the wrong place, and I am sure won't be the last. Thanks. I do hope it'll be MY last mispost, though. Again, apologies all around. Wolfgang - www.scp-paulet-lenerz.com
Re: [ql-users] No Virus Now - Maybe
On 5 Dec 2003 at 8:57, Phoebus R. Dokos (è á. ç) wrote: Pah! Blame it on the woman now won't we? :-D Poor thing she couldn't help it! It's like saying that it's Dilwyn's fault that he's so popular with the ladies ;-) Hmm, Dilwyn of Wales somehow hasn't got the right ring to it. I can't see wars started over that (sorry Dilwyn). Wolfgang
Re: [ql-users] BMP2SPRT v. 1.01
Hi all, version 1.01 of BMP2sprt can be found at www.scp-paulet-lenerz.com/14mljkl24/wolf/download Wolfgang
Re: [ql-users] SMSQE sources website
Hi all, Plaese note that the SMSQ/E sources may, as off now, be obtained at the following website: www.scp-paulet-lenerz.com/smsqe The site is still under construction, so please be patient. It is forseen to include the following for download: individual directories within the sources upgrade package from one version to another (but only from version x.xx to version x.xx + 1) (Helpful) comments are welcome, as usual. Wolfgang
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
On 8 Dec 2003 at 12:44, Phoebus Dokos wrote: I think it cannot be killed but CAN BE replaced (ie from another shell or whatever... at least I think that's what TT said at one point) (or something) ? It's a moot point here since that is not what is happening. (...) IIRC he is ie the extensions are royalty free. (Of course don't hold me to that but I can assure you that whatever Rich does is 1000% (yes the extra 0 is intended) legal. I don't intend at all to question his honesty. I just didn't know that you're allowed to do that. (...) 2- Surely it would be better if your QWord adapted itself to the existing screen resolution colour depth rather than the other way around? Not really. Remember QWord (the same executable) works regardless of the presence of Colour Drivers (ie it runs on Minerva and QDOS Classic). In the latter cases it manually modifies the hardware registers to switch to the colour depth and resolution required. So if QWord was to adapt to the existing screen colour depth, you would only get 4 colour QWord on the Aurora with Minerva or non-colour SMSQ/E ;-) I understand (now). Still, instead of automatically chaning the screen resoultion colour depth, At LEAST make it configurable, i.e. 'Do you want this program to change colour depth resolution automatically Yes/no. If not, and if it doesn't run on a system already having higher colour, then don't switch. Plus that the whole thing is based around careful measurements that are resolution specific. Does that mean that wen I run in a higer resolution, its doesn't change the screen? Unless of course someone wants to implement for just one game scaleable graphics and draw every object on the screen (plus icons, plus letters, 3D effects, shadows etc.) instead of using pre-rendered graphics. They are sure welcome to try ;-) Prowess? (...) Wolfgang
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
On 8 Dec 2003 at 16:36, [EMAIL PROTECTED] wrote:
Umpf, and how do you test for that? What happens if the user unsuspends the
job
whilst the screen is still too small?
The unsuspend routine could surely check the screen dimensions and refuse to
unsuspend the job if the screen is too small...
And the user wouldn't be happy.
(...) I have made it configurable in QWord (similar to Launchpad) as to whether
it
can alter the screens resolution and colour depth,
Ah, great, then!
(...)
Job 0, the mother of all SBasics isn't killed off. I don't think it can be
killed at all.
The easiest way around your problem is to set up a hotkey
eg ert hot_wake ('b','sbasic'). This will call up a new sbasic, with the
standard windows,
whenever there is none there yet..
Hmm - very odd - I wonder why if SBASIC is set to OUTLN #0,512,256,0,0 and I
execute QWord (which resets the screen to 640x480), it is fine when I switch
to SBASIC (or quit QWord). - Remember that QWord resets the original screen
dimensions when Quit. However, if I set SBASIC to OUTLN #0,800,600,0,0 and then
run QWord, on quitting QWord, the screen dimensions are reset to 800x600, but
there is no cursor available to #0 - in fact, QPC just hangs !!
Not here, it doesn't.
my disp_size is 1024,768
ert hot_wake ('B','')
ert hot_wake ('b',sbasic')
ALT +B - job 0
DISP_size 800,600
job 0 seems to disappear.
alt +b get a new sbasic, type disp_size 1024,768
alt + B brings back job 0 with t working cursor in channel#²0
(ok, sometimes it's windows aren't reset correctly
(...)
Not too sure - I was hoping for some input from TT. QTYP uses SMS.LIOD to
link the new device driver and I am storing the address of the link to use for
the pointer to remove the device with SMS.RIOD. Not actually tested this yet.
It should work...
The idea is to avoid a boot program altogether, so that people who have not
installed QTYP on their system as a default, do not have to remember to run a
BOOT program before executing QWord. Surely that is the main reason for
linking in extension toolkits when compiling a program !
Indeed it is.
I do suggest, however, that a device driver as such isn't a toolkit, but a system
extension.
Alternative : why not test for the presence of qtyp before re-installing it (if that is
possible at all).
()
QWord can be configured to use the existing screen
resolution and colour depth (though at present does not support mode 4 or mode 8).
However, it does mean that if the resolution is smaller than 640x480 on QPC,
it will not run (reports an error), and if the resolution is greater, then the
tiles appear smaller on screen (and harder to read).
Yes, this seems indeed the way to go!
Feedback from users suggests that they would rather QWord be configurable to
set the screen accordingly so that it appears as large as possible.
Fair enough. I personally wouldn't want that...
(...)
No - I would want the job to be able to realise that it had lost focus so
that it could then reset the colour depth and resolution, or maybe do something
in the background instead (such as stop writing to the screen). The only way
it can do this at the moment is to have a small window open on the screen that
it attempts to PRINT to and use error trapping to take alternative action when
focus is lost (such as not output data). However, this is not always apt !!
If Qword uses the PE, then there is a way to find out if it has lost focus or not.
Read the pointer with a timeout and check the returned pointer position
(e.g. if using QPTR's RD_PTRT, the xrel,yrel parameters will return -1 if the pointer
is
outside the job's window).
I accept any criticism - postive or otherwise
Perhaps the above was less otherwise
Wolfgang
[ql-users] Re: BMP2Sprt
Hi all, version 1.03 of bmp2sprt i ready and waiting. You can get it at: www.scp-paulet-lenerz.com/14mljkl24/wolf/download New in this version: Support for mode 16 sprites (thanks Marcel!) Support for extended sprites. Wolfgang
Re: [ql-users] WM.RPTRT again
On 2 Jan 2004 at 11:51, [EMAIL PROTECTED] wrote: (...) Since the original IOP.RPTR asks for D2.B to be set, does this not mean that old programs calling the routine might find peculiar things happening? For example, the contents of D2.L could have $FF as the top byte. D2 might have been -1 before D2.B was set with the required pointer events return. In that case any job event sent to the program would cause a spurious return. What steps have been taken to prevent this? I've just come back - it seems to me that these are 2 different calls .RPTR and .RPTRT. Only the second has the additional parameters (from the start). So no overlap or problem there! Wolfgang
Re: [ql-users] bmp2sprt
Hi all, there is a new version of bmp2sprt at http://www.scp-paulet-lenerz.com/14mljkl24/wolf/download/ Thanks to Per Witte for finding the bugs! Wolfgang
Re: [ql-users] BMP2SPRT
BMP2SPRT v. 1.10 can be found on my website www.SCP-Paulet-Lenerz.com/14mljkl24/Wolf/Download Have fun. Wolfgang
