Re: [ql-users] display or convert non _scr formats to _scr
On 11 Jan 2005 at 6:49, Wolfgang Lenerz wrote: (...) I wrote some extensions for this quite some time ago. You might want to check my download site and get the bmp converter prog for this! Alternatively, use the enclosed keywords. Sorry, I sent that before I noticed that the problem had already been solved. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] display or convert non _scr formats to _scr
On Mon, 10 Jan 2005 at 18:21:59, James Hunkins wrote: (ref: [EMAIL PROTECTED]) snip Now, this raises the question, why do we not have a native QL program that can convert one of the major image formats to a _scr image directly? I found tons of stuff that converts between formats plus from _SCR to others. The only one I found reference to was called BMP2SCR but I could not find a copy any where on the net. Dilwyn has a copy it seems: http://homepages.tesco.net/dilwyn.jones/djpdsoft/djpdlib.txt GE52 Tony -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Lynx 282
Lynx is GPL license and you should include the source. Perhaps the answer is to unzip on a linux box, change the directory names to shorter ones and zip it up again. Probably breaks terms of licence in much the same way and certainly fouls up replacement should Jonathan update it. What I've done is to put my cut down package on the page as well as Jonathan's FULL package including sources. Where people can't make head or tail of the original package as I couldn't, they can at least have a cut down get them going version to start with and move on to the full version when they feel ready to tackle it. I don't like breaking licence terms, but I'm very happy to do so on this occasion to sort out this mess (and Jonathan makes some pretty cutting remarks about QL filing systems etc in his own documents) which otherwise renders QLynx virtually unuseable to less experienced/non uQLx users. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz wrote: There has been some talk on this list about some form of currrent directory or home directory for programs that are being executed. As far as I understand it, the purpose of such a directory is to give the program the name of the directory from which the file was executed, so that, for example, it can find a configuration or data file in that directory. This facility as such doesn't exist in the QL world. I propose to incorporate it into SMSQE. The problem is one of compatibility, of course. Technically, various solutions could be considered, such as putting it after the command string, but all of them will face some obstacles, such as how to get at this from a compiled basic program. Concept =-=-=-=-= The solution I find most acceptable, would be to create a new Thing. This thing would hold the home directory string, and each job could get it from there. Conceptually, I'm not keen on this centralised approach - it seems rather too Windows-like! Since it's an item of job-specific data, couldn't it be associated with a job-specific data area or structure (e.g. put on the stack prior to activation)? Apart from anything else, this would maintain the self-cleaning property of the operating system... SNIP In today's everyday use, there seem to be several ways that programs are executed. - Via the EX, EW etc commands, which are part of SMSQE itself. These commands will have to be amended. - Via the Hotkey system. Unless a default home dir is set up explictly, jobs set up in this way won't have a home directory - Via QPAC2. This would have to be changed to send the home dir name to the thing. - Via other file managers (which ones?). They would have to be changed, too. If there are many of them, I might envisage creating a new trap (#3, D0 = $3F) which takes as parameter the name of a file excutes it (this is a facility which I find sorely missing from the OS as such anyway). Trap#3 functions deal with channel IDs, not device names. Shouldn't this be implemented as a vectored routine? John ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Lynx 282
The answer is to create two zip files, one with the runtime version and one with the sources etc - we know the second one will not unzip on the QL properly. Then zip these two zip files together - so there is ONE download. The user can unzip on the PC and then access the runtime zip from within QPC2. Which is a totally absurd thing for 56k modem dial up users anyway as Qlynx is 2.4MB and the runtimes only need a few hundred KB at most. I uploaded both versions to my site plus a link to JRH's site as well, so should be OK. Dilwyn ___ 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: Re: [ql-users] display or convert non _scr formats to _scr
Now, this raises the question, why do we not have a native QL program that can convert one of the major image formats to a _scr image directly? I found tons of stuff that converts between formats plus from _SCR to others. The only one I found reference to was called BMP2SCR but I could not find a copy any where on the net. Dilwyn has a copy it seems: http://homepages.tesco.net/dilwyn.jones/djpdsoft/djpdlib.txt GE52 I've only just noticed this thread, 12 hours late! We published a routine in a fairly recent QL Toady about converting between .BMP files and QL _SCR files. Malcolm Lear has written some SBASIC programs to convert between SCR and BMP although I can't remember which way (QL to Windows, or Windows to QL) as I'm at work. The SBASIC programs are fairly slow - 16-bit colour screens are quite large. If you convert between SCR and BMP, yes the SCR and BMP files will be quite large as they are not compressed, and I guess that the different number of bits per pixel of colour data means there will be some approximation, e.g. 24 bit per pixel BMP files is converted down to 15 or 16 bits of equivalent QL data means that the 8-bits per colour component have to be resolved to only 5 (or 6 bits in the case of one of the 3 promary colours) bits on the QL. So a value range of 0 to 255 for say red component on the PC would have to be stepped to 0 to 31 on the QL, so I think that means there'd be 8 red levels possible in a PC-24-bit file for every red level in the QL equivalent (primaries which have 5 bit QL fields) and 4 times as many for the primary with the 6-bit field. Dilwyn Jones * I've just read the above again and I think it's total garbage, or I've just managed to confuse myself (I've just had a row with my volatile boss so probably not thinking straight, I only came on here for a few minutes to get him out of my mind) - someone thinking straighter than me correct me!. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] QL filename length revisited
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. Was QVFS ever fully finished? I remember trial versions. I'm not too sure if HPR (the author) is still around writing and maintaining QL software. I haven't actually used it to know what it's like for the user. It's always interesting to be reminded that such applications exist of course! Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] display or convert non _scr formats to _scr
Now, this raises the question, why do we not have a native QL program that can convert one of the major image formats to a _scr image directly? I found tons of stuff that converts between formats plus from _SCR to others. The only one I found reference to was called BMP2SCR but I could not find a copy any where on the net. Dilwyn has a copy it seems: http://homepages.tesco.net/dilwyn.jones/djpdsoft/djpdlib.txt GE52 I've only just noticed this thread, 12 hours late! We published a routine in a fairly recent QL Toady about converting between .BMP files and QL _SCR files. Malcolm Lear has written some SBASIC programs to convert between SCR and BMP although I can't remember which way (QL to Windows, or Windows to QL) as I'm at work. Drat, me and my big mouth. I thought these were on my website as well as in the PD library as TF mentioned. I'll try to remember to post them there tonight, or I could email them from home to you Jim in case you need them another time. Again, not being too sure from memory - didn't Phoebus write a graphics conversion program which ran in Windows and converted between Windows and QL graphics? If I could remember the name I could probably tell you if I had a copy. Maybe this was what Rich Mellor was referring to. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 11 Jan 2005 at 10:53, John Hall wrote: (...) Conceptually, I'm not keen on this centralised approach - it seems rather too Windows-like! Since it's an item of job-specific data, couldn't it be associated with a job-specific data area or structure (e.g. put on the stack prior to activation)? Apart from anything else, this would maintain the self-cleaning property of the operating system... True. However, how do you get at that from basic, espacially compiled basic? By the time your (new) keyword to fetch the data has been called, what is on the stack will/might have been overwritten The only other job-associated data structure is the job header. I am NOT willing to bet on the number of programs out there that assume that this structure is $68 bytes long... (...) If there are many of them, I might envisage creating a new trap (#3, D0 = $3F) which takes as parameter the name of a file excutes it (this is a facility which I find sorely missing from the OS as such anyway). Trap#3 functions deal with channel IDs, not device names. Shouldn't this be implemented as a vectored routine? Well - whatever. It mixes trap#1 (creating a job), trap#2 (opening a channel), trap#3 (getting the file into mem). However, you just made mùe think of something - it isn't possible to call the job creation trap from withing another trap, in Supervisor mode (now where have I heard that before recently?) so a vectored routine it might be. wolfgang John ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm www.scp-paulet-lenerz.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
Quite agree. I too have recently been driven nuts with the limitations. A new set of traps to an advanced directory system sounds good. Perhaps with a new 'CD' navigation command. I suppose the old traps could be rewritten such that older software has access to the new system to a path length of 36 characters. Does anyone know the history of the 36 character limit. Was it a file name length limit set before directories came about? Cheers Malcolm P Witte wrote: 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. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
On 11 Jan 2005 at 16:24, Malcolm Lear wrote: (...) Does anyone know the history of the 36 character limit. Was it a file name length limit set before directories came about? Yes. At first the Ql didn't have directories at all. They came, unless I'm mistaken with TK II and disk interfaces Cheers Malcolm Wolfgang www.scp-paulet-lenerz.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz wrote: Apart from anything else, this would maintain the self-cleaning property of the operating system... True. However, how do you get at that from basic, espacially compiled basic? Without having any personal view on the issue yet, isn't it basically the same issue as with CMD$? Does CMD$ work in compiled basic? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 11 Jan 2005 at 17:44, Marcel Kilgus wrote: (...) Without having any personal view on the issue yet, isn't it basically the same issue as with CMD$? Does CMD$ work in compiled basic? Yes and no. (That's a true lawyes's anwer for you) No problem for Sbasic itself, of course. However, while CMD$ works in Qlib, this is only because Qlib has it's own CMD$ command. There is no way to have a similar home$ command in Qlib. I don't know about Turbo, but since that is still maintained, something should be possible there (George?). Wolfgang www.scp-paulet-lenerz.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz wrote: Yes and no. (That's a true lawyes's anwer for you) No problem for Sbasic itself, of course. However, while CMD$ works in Qlib, this is only because Qlib has it's own CMD$ command. There is no way to have a similar home$ command in Qlib. Ah, very well. Anyway, if one now aims a little bit higher, instead of having a home directory allowing a current directory (which can be-preset to the home directory), i.e. something dynamic, the stack debate becomes irrelevant as it's only suitable for static passing of data. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz wrote: --- Finally, progs executed from memory (executable things) would probably not have a home directory, unless a facility is set up whereby a default home dir is set up for programs with a certain name. Default could also be DATAD$ or whatever. - Via QPAC2. This would have to be changed to send the home dir name to the thing. If it's easy enough to do no problem ;-) - Via other file managers (which ones?). They would have to be changed, too. CueShell, which I have acquired the sources for but didn't have a look at yet. If there are many of them, I might envisage creating a new trap (#3, D0 = $3F) which takes as parameter the name of a file excutes it (this is a facility which I find sorely missing from the OS as such anyway). Hm, the meaning of a Trap #3 depends on a specific device you've opened, not a good choice IMO. But if you do use a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). Preliminary way the Thing could handle requests =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - set the home dir name -- get the true job ID if passed as -1 -- try to find this job ID in my list - if found, return with error - else, set up string (possibly reserve more mem in chunks of 512 bytes) As I said, I think if we/you are going ahead with this, I think it should probably be a current directory functionality with functions like up one directory and change directory to x (absolute and relative). Or perhaps both? On other systems Applications get 2 things: a current directory and the complete name of their EXE file. Some way must be devised to delete the filenames after a certain time. When the job is deleted? Yes. Should the home dir name be deleted once it has been passed back to the job? No. Should there be an explicit deletion? No. Should there be a normal request for the home dir (doesn't delete it) and one where deletion is automatically done after passing the name to the job? Don't see why (and as said, a current directory would have to be present during the whole process anyway). We're talking about a few bytes here. 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? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 11 Jan 2005 at 18:19, Marcel Kilgus wrote: Default could also be DATAD$ or whatever. that would defeat the wholme exercice. Why not have the user set the default? (...) Hm, the meaning of a Trap #3 depends on a specific device you've opened, not a good choice IMO. But if you do use a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). See my other email (starting a job from a trap?) (...) As I said, I think if we/you are going ahead with this, I think it should probably be a current directory functionality with functions like up one directory and change directory to x (absolute and relative). Or perhaps both? On other systems Applications get 2 things: a current directory and the complete name of their EXE file. OK, this bears thinking about. (...) Don't see why (and as said, a current directory would have to be present during the whole process anyway). We're talking about a few bytes here. Ok, I hadn't envisaged the current dir as such. 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$. I HATE the open commands that append the data/prog dir when I don't want them! But I'm probably alone with that opinion. 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? Too ambitious? Wolfgang www.scp-paulet-lenerz.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Lynx and QPC2
- Original Message - From: Dilwyn Jones [EMAIL PROTECTED] To: QL Users List [EMAIL PROTECTED] Sent: Monday, January 10, 2005 12:21 AM Subject: [ql-users] Lynx and QPC2 skip To get a copy, goto www.dilwyn.uk6.net/internet/index.html or browse there from my home page of course. The idea is that this cut down version will be enough to get people going, as they become more familiar with it they can ditch my version and start to use all the other parts of Jonathan Hudson's full distribution which includes sources and all sorts of extras. Unzip lynxrun.zip to win1_l_ (I hope Jonathan used a cross compiler on a Linux box and then tested it with UQLX I've got the archive set up so that it'll go here by default). Load LYNX_BOOT from there, check whether you need to add ENV_BIN (Environment variables) and SIGEXT30_REXT (Signal Extensions) - they are included, but you will need to remove the REMark from that line if you don't normally have them installed on your system. The LYNX_BOOT is extensively commented by Jonathan, I've added even more comments to help you get it going. What about unzipping to a windows machine, renaming the directories so that they do notr cause problems for qdos and then rezip them. Surely this is cleaner! I hope I've understood enough of the package for this to be a useable version for most people. Certainly, no software is ever truly bug-free or beyond improvement, so suggestions for corrections and improvements are welcome. It's only been tested on my own QPC2 system and will only work with v3.30 or later of QPC2. It hasn't been tested with UQLX or SOQL (the other TCP/IP capable QL systems) - perhaps someone would try it and let me know! I hope it works and proves to be of value for some of you when QPC2 v3.30 goes on release. Shameless bragging for a moment - I managed to use Lynx from within QPC2 to download a QPC2 update from Marcel's website and even unzipped it from QPC2 into Windows (turns out it was older than the Beta version I was using but who cares, it worked!) and in case you think you can get a free update from Marcel using Lynx and QL Unzip, oh no, the password protection for registered users works in exactly the same way from QDOS unzip as it does in Winzip! -- Dilwyn Jones Why run lynx from QPC2 when you can run better browsers within Windows? If it is to avoid hackers, viruses then it provides no protection whatsoever! ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Lynx 282
- Original Message - From: P Witte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 10, 2005 2:11 AM Subject: Re: [ql-users] Lynx 282 Dilwyn Jones writes: I honestly don't believe this is useable on QPC2. Poor old Dilwyn. My commiserations (in advance) for 2005. I agree with you that for us poor QLers Lynx is a malevolent and misogynistic piece of software. I also agree with Marcel (as he says further down the line) that it is better than no software - but only just: If your serotonin levels are high Lynx (and other *X-derived software) is fine. If normal to low, no software is probably better. There is nothing to stop an enterprising QLer modifying the source so it is more QL specific and starting another fork of Lynx. As it is GPL you would have to include the source but that is no problem. Per ___ 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] display or convert non _scr formats to _scr
In message [EMAIL PROTECTED], James Hunkins [EMAIL PROTECTED] writes Any other suggestions out there? It turns out that the software Phoebus is working on runs on Windows and is tied to Microsoft's .net stuff which I am not setup with and can't afford to install this close to QDT release. Yes, you do need the .net support. I tried Photon sometie ago now, and came to the same conclusion. I believe that .net itself only works on the more recent incarnations of Windows. Also quite a large download. OK, to those who have it. Has any one experienced using it ? Roy, if you are on line, I think you told me how to display a full screen image before and capture it? Have you got the improved Norman Dunbar software - which is called 'Snatch-IT' I believe ? ... although I could be wrong with the name. It was originally developed for QDOS, but Norman modified it to work under QPC so that higher pixel count images could be 'snatched' from the screen. You could also use any similar PC Application for this that will capture a screen. In editing software you can erase any unwanted parts, such as the Windows background screen, etc. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] graphics kudos
In message [EMAIL PROTECTED], James Hunkins [EMAIL PROTECTED] writes Snip I converted the image, as described in a separate thread, to a PNG format file, used Marcel's windows program to convert that to a QL _SPR image, and then in SBASIC with the build in commands displayed it on the screen (OK, it wasn't quite instant at this resolution on running under Virtual PC but not bad at all!). Then I used Dilwyn's nice little screen grabber, Snatch4, and captured it directly to the file name and location that I wanted. Then simply ran BGIMAGE filename, and there it was, in full color with no quality loss. Really cool. And glad to see that I can't use the excuse that the software couldn't do what I wanted. Thanks Marcel and Dilwyn - very nice job. I am glad that you have succeeded Jim. Could you just break that down again into more step by step, then others can follow and use the method too. PS - It was Snatch4 that I was referring to in another email. WhichI should have credited to Dilwyn. Although Norman Dunbar also made a modification. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
In message [EMAIL PROTECTED], Dilwyn Jones [EMAIL PROTECTED] writes clip 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. Interesting ... can you write this up sometime in QLToday as this would be a useful guide to 'Getting the best out of QPC'. -- Malcolm Cadman ___ 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
[ql-users] Mac mini thoughts...
Isn't the new mac mini everything you want in a replacement QL? What would it take for us to put together something as tidy as this? http://www.apple.com/macmini/design.html Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL shows (was QWord payment)
- Original Message - From: Tony Firshman To: [EMAIL PROTECTED] Sent: Monday, January 10, 2005 9:08 PM Subject: Re: [ql-users] QL shows (was QWord payment) I meant Bill let -us- know when his favourite m/c shows are - preferably late next year or 2006. I appreciate that, but we are now encouraging show planning up to a year in advance. (We already have a preliminary date for Quanta AGM 2006). So good if Bill could give his favourite dates. Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] good superbasic book?
- Original Message - From: John Gilpin To: [EMAIL PROTECTED] Sent: Monday, January 10, 2005 11:00 PM Subject: Re: [ql-users] good superbasic book? In my copy there is a preface to the second edition dated 19th July 1989 and at the foot of that page there is a Copyright Notice As of December 1987 all rights in this book reverted to Jan Jones. No portion of this book may be reproduced without her written permission. Does this mean that by 'reproducing' these extracts, we are contravening the copyright? The interesting thing is that the copy which Quanta has for resale does not have this page in it but in all other respects the two of them look identical. John Gilpin.(Individual) As Dave P pointed out on 24th December copyright can mean many things. To quote from his mailing: (Quanta's copyright is) on a different thing to Jan Jones' copyright. She has a copyright of the contents. Quanta has a copyright on that specific edition (the cover, those changes which make it a quanta publication A fundamental principle in law is always to go back to the original documents. There should be an original contract somewhere. Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On Tue, 11 Jan 2005 22:00:37 -, P Witte [EMAIL PROTECTED] wrote: 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). I prefer this type of approach as it would ensure that the home directory (or whatever) would be removed together with the job. However, I perceive several problems with this approach: 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 2) The bigger problem and one which is harder to address... How do you decide what is the home directory of a file called win1_basic_exts_turbo_config_exe I guess the code which sets up the job would have to look at each of the levels before the underscore to see if they were set up as a directory (ie file type 255). In other words, it would need to check whether the following were directory files and select the home directory as the first one it found with file type 255 win1_basic_exts_turbo_config_ win1_basic_exts_turbo_ win1_basic_exts_ win1_basic_ win1_ 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. Yes, I can understand the need for this - it all depends on what points to the HD/CD -- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ http://www.rwapservices.co.uk/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Rich Mellor wrote: I prefer this type of approach as it would ensure that the home directory (or whatever) would be removed together with the job. If the job uses the thing, the thing is informed when the job dies. Even if not, one could allocate the necessary memory on behalf of the job and therefore it would get freed along with the job. So far I think I'd prefer that over any stack hack, but I haven't completely made up my mind yet. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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). Hm, the meaning of a Trap #3 depends on a specific device you've opened, not a good choice IMO. But if you do use a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). See my other email (starting a job from a trap?) I wonder how sms.crjb ever managed to do it ;-) Anyway, a vector is probably a better idea, yes. 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$. I HATE the open commands that append the data/prog dir when I don't want them! Well, partly yes, some files do tend to show up at wrong places if I misspell a device name. On the other hand, I do prefer ex fifi over ex dev1_fifi. 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? Too ambitious? As usual code reuse is the magic word. The DEV_ device exists, it shouldn't be hard to adapt. But basically it's a separate project, if there was a thing it would simply just use the thing, too. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users]Long file directory Trees
I have not used the path rext but if it worked like path in MSDOS or Unix vatriants it would solve a lot of problems. A Path could be set up to cover all your program directories and then a program will able to find its help, configurration or other files because it will be in the path. Data$ can be set to ones home directory Prog$ can be set to start up program directory. I have skipped the correspondence about long file names, but both MSDOS and Unix use files as directories. These could contain the long directory names and the actual directory name which is a single byte allocated by the system (if 256 directories is enough!). The system could automatically create the directory files and use them. Hence on an old system the existing file names would work but a new system would be able to cope with longer file name trees. There could be a conversion program that read the existing directory tree and converted it to the new system. We would just have to ensure that when we distributed programs they could work on the old system but those with hard disks and the latest version of SMSQE could enjoy longer file, directory names and trees. Rather similar to the long file name change in Windows This would seem to me to offer the advantage of backward compatablity with advantages for those with big hard drives. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] BMP files etc
I've updated the Graphics page on my software download site to include the BMP and QL high colour screen conversion and other graphical utilities as I mentioned earlier today. The upload includes a copy of the article from Vol 8 Issue 3 of QL Today and the SBASIC listings showing how to convert between 24 bit BMP files and QL mode 32 and mode 33 screens in both directions. Hope this helps Jim Hunkins and anyone else trying to get their QL to handle PC graphics. Point your browser at this URL, then steer to the Graphics page. www.dilwyn.uk6.net Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
In message [EMAIL PROTECTED], Rich Mellor [EMAIL PROTECTED] writes On Tue, 11 Jan 2005 11:42:37 -, P Witte [EMAIL PROTECTED] wrote: cut 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. How do you work this out - Minerva is unlikely to be updated to take account of the new device format, any more than QDOS. Most emulators still rely on either Minerva or QDOS 48K ROMs and I sure there would not be room to implement the new code in the actual ROM. Hey but Minerva is now open source and free. Wasn't the argument about the licence all about the hundreds of programmers that would come crawling out of the woodwork to work on a free open source system and make it all powerful, -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] display or convert non _scr formats to _scr
Have you got the improved Norman Dunbar software - which is called 'Snatch-IT' I believe ? ... although I could be wrong with the name. It was originally developed for QDOS, but Norman modified it to work under QPC so that higher pixel count images could be 'snatched' from the screen. You could also use any similar PC Application for this that will capture a screen. In editing software you can erase any unwanted parts, such as the Windows background screen, etc. I've put Norman's version onto the graphics page on my website. IIRC it was a port of my original screen snatcher, but pointer driven and he added a facility to save successive screens with auto-numbering of the filenames. It was called Screen Snatcher 2 IIRC, haven't really looked at the content of the zip file. For those who wish to use a QL program, use my Snatch4 from Launchpad. It can be used by itself without Launchpad and you can download it from the graphics page on my website. It will handle high colour files. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
2) The bigger problem and one which is harder to address... How do you decide what is the home directory of a file called win1_basic_exts_turbo_config_exe I guess the code which sets up the job would have to look at each of the levels before the underscore to see if they were set up as a directory (ie file type 255). I'm not sure I fully understand what you mean, but here goes: Using your example above, in BASIC using FNAME$ you can extract the filename part to separate it from the directory name - I do this in Q-Trans. channel=FOP_DIR(win1_basic_exts_turbo_config_exe) PRINT FNAME$(#channel) CLOSE #channel FNAME$ on a channel opened by FOP_DIR returns the pure directory name. Assuming your program int he example is called turbo_config_exe, FNAME$ would in this case return basic_exts, the directory in which turbo_config_exe is called. The above is from memory and I think only works if you use FOP_DIR (i.e. it has to be open directory channel). I think in this situation that FNAME$ returns the directory name and not the pure filename, but is easily checked. All I'm saying is that (assuming I understood the message first time) it is possible to some extent already. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Rich Mellor writes: 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). I prefer this type of approach as it would ensure that the home directory (or whatever) would be removed together with the job. However, I perceive several problems with this approach: 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 Not at all. Currently (a6,a5) points to the top of the data area. That doesnt change! Only cognizant programs would attempt to peek beyond their area into the void. There, if they were EXecuted by an equally cognizant OS, they would find a marker that tells them that there is a HD there. If the OS were not HD-aware the program would have to offer a warning to the user or find some workaround. Non-HD-aware programs would not even look. Ie this method would be wholly transparant to legacy programs. 2) The bigger problem and one which is harder to address... How do you decide what is the home directory of a file called win1_basic_exts_turbo_config_exe The OS already provides that information unambiguously. In S*basic try: ch = FOP_IN(path+name): PRINT FNAME$(#ch): CLOSE#ch ch = FOP_DIR(path+name): PRINT FNAME$(#ch): CLOSE#ch 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: If the job uses the thing, the thing is informed when the job dies. Even if not, one could allocate the necessary memory on behalf of the job and therefore it would get freed along with the job. So far I think I'd prefer that over any stack hack, but I haven't completely made up my mind yet. Theres no stack hack involved; simply a new convention. I suspect you may have the path depth/filename length issue at the back of your mind. So did I. Ideally, setting up the stack in this way should be done via a single system call (a System Service call in my parlance), accessable to any program or toolkit that is in the business of EXecuting jobs for whatever reason. That way, if at some time in the future the 36 char limit were to be removed, there would only be a single routine to change. M/c programs wanting to set up sub-jobs for it own purposes could still do so manually in the old way, ignoring the new convention if it doesnt need HDs. 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). 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. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users]Long file directory Trees
jms1 writes: I have not used the path rext but if it worked like path in MSDOS or Unix vatriants it would solve a lot of problems. A Path could be set up to cover all your program directories and then a program will able to find its help, configurration or other files because it will be in the path. Data$ can be set to ones home directory Prog$ can be set to start up program directory. I think people work to different paradigms. Paths are all well and good, but wouldnt solve any problems for me unless the path string were half a mile long, which is impractical. I have skipped the correspondence about long file names, but both MSDOS and Unix use files as directories. These could contain the long directory names and the actual directory name which is a single byte allocated by the system (if 256 directories is enough!). The system could automatically create the directory files and use them. Hence on an old system the existing file names would work but a new system Currently Qdos directories are nothing else than a special kind of file, ie just as you propose. Or do you mean that one should use an additional, secondary directory file with a different structure to store the long filenames? Rather similar to the long file name change in Windows I once understood how Windoze got around the filename limitations of Msdos and thought it a clever idea (it was ugly, but it worked) but I can no longer remember. Does anyone here know? And would it be possible for us to make use of the same method? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 11 Jan 2005 at 22:19, Rich Mellor wrote: (...) 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. 2) The bigger problem and one which is harder to address... How do you decide what is the home directory of a file called win1_basic_exts_turbo_config_exe Simple. Open_dir win1_basic_exts_turbo_config_exe. Get the name of the resulting file. This will be the directory name (!). (...) Wolfgang -- W. H. Lenerz www.scp-paulet-lenerz.com -- ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
I have a question here. Currently, the way directories are handled is by making a directory a somewhat special file (file type -1, IIRC). Apart from that, though,a directory ia a simple file that can be accessed more or less like any file. Directories contain an entry per file referenced in that directory. Part of the entry is the filename of the file. However, and that is where the original designers made a design decision we all regret today, this filename is the ENTIRE name of the file, (minus the device name). Example: you have a file called win1_subdir1_subdir2_subdir3_myfile The filename as contained in the entry in subdir3_ for this file will be: subdir1_subdir2_subdir3_myfile. As you can see, we are quickly getting to the 36 chars limit since that is the most space a filename can take in the directory file entry. Wouldn't the most simple way to get around the name length limitation be that each directory holds only the filename itself? Of course, each name on each directory level would still be limited to 36 chars, but something like: win1_verylongsubdirname1_verylongsubdirname2_verylongsubdirnam e3_verylongsubdirname4_verylongsubdirname5_prettylongfilename would be possible. Perhaps the directory should be a new file type (-5 ot whatever) to show that this is a new type of directory. Legacy applications wouldn't work in this scheme. But, let's face it, whatever the scheme you are going to implement, they won't work (one, because the finale filemane will be too long anyway, two because they can't access new directories anyway). I'm just asking this question since I don't think I'd be competent enough to make these changes. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] BMP files etc
Hi Dilwyn, I don't think that I see the changes. Am I blind or did they not actually get uploaded yet? Thanks, jim On Jan 11, 2005, at 4:08 PM, Dilwyn Jones wrote: I've updated the Graphics page on my software download site to include the BMP and QL high colour screen conversion and other graphical utilities as I mentioned earlier today. The upload includes a copy of the article from Vol 8 Issue 3 of QL Today and the SBASIC listings showing how to convert between 24 bit BMP files and QL mode 32 and mode 33 screens in both directions. Hope this helps Jim Hunkins and anyone else trying to get their QL to handle PC graphics. Point your browser at this URL, then steer to the Graphics page. www.dilwyn.uk6.net Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
