Re: [ql-users] What do you want to do with the source to SMSQ ?
At 09:18 AM 5/21/2002 +0100, Norman wrote: >So, what do you want to do with the source code when it gets released ? I think I would find it useful to see the comments and hopefully they will document parts of SMSQ/E that is not fully documented. The code might shed some light on particular areas that I might have questions on. As I am not an assembly programmer, I don't know how readable the code will be to me. Tim Swenson
RE: [ql-users] basic HTML viewer?
At 10:40 AM 5/20/2002 +0100, you wrote: >Hi James. > >There was an HTML browser for the QL going around some time back, written in >SuperBasic. The last I heard was that there were a couple of problems with >it, and I haven't heard much since then. (Was it Tarquin ?) I believe you are talking about Hyperbrowse. There was also an earlier browser written by somebody in Italy. They used CSIZE to show the different font sizes from HTML. I've got a copy around but I don't know if the source code was distributed. Tim Swenson
Re: [ql-users] Source Code
I guess you have to be European to become flame bait on this mailing list. Here I thought my last message about support and SMSQ/E would send electronic fire and brimstone heading my way. Instead, It seemed like it made not a single blip on the radar. So, I'll ask again, when we talk about support for SMSQ/E from the resellers (i.e. their value add), I don't know exactly what is meant. Does it mean bug fixes to SMSQ/E? Does it mean hard copy manuals? Does it mean hand-holding in getting SMSQ/E running and working? Does it means X free upgrades? Heck, is a less buggy version of SMSQ/E an "upgrade"? The license seems to make a big issue about the support from the vendors, but I really would like to know the extent and content of the support. I hope someone can educate me on this matter. Tim Swenson
Re: [ql-developers] Re: [ql-users] Source Code
At 07:18 AM 5/19/2002 +0100, you wrote: >Timothy, > >When I got SMSQ/E from Jochen, I got: > a) A generic SMSQ/E User Guide (38 pages) that was not machine specific > b) Custom supplement pages for each hardware environment I bought >(typically 6-10 pages) >I agree that the SMSQ/E Reference manual is extra - but I do not think that >is what was being refrred to. > >Dave I guess the point I was trying to make was that the 38 page guide was no where near comprehensive enough to document a full OS. I'm sure that it assumed that the user was already familiar with QDOS. The Gold Card/TKII manual was a little more in depth, as it only covered some extensions to the OS. The original poster said something about a "printed handbook" for SMSQ/E and I would expect a little more than a 38 page guide that barely covers the topics. Tim
Re: [ql-users] Source Code
I've glanced over the comments made by others on the SMSQ/E official statement and have decided to take a nice long look at the statement myself. The comments below are strictly my opinion, not based on any input from the other commentors. At 02:50 PM 5/13/2002 +0200, you wrote: >Official statement >== > >3/ No distribution of SMSQ/E may be SOLD, except >for the official distribution. This interdiction >includes that of including and distributing >SMSQ/E in Public domain libraries. > >Official distributions will be sold in compiled >(binary) form, possibly together with the >official distribution as source code. For such >sales, for the time being, two >distributors/resellers, namely Jochen MERZ (JMS) >and Roy WOOD (QBRANCH) have been appointed by >the copyright holder. Resellers provide support >for the versions sold by them. Except by prior >agreement, binary, i.e. compiled, versions of >SMSQ/E may not be distributed other than through >the distributors. It would be better to leave out stating who the official distributors are in this Official Statement, and put it in a separate document. It would be kind of like putting in the name of the Officers in a set of By-Laws, as the names will change over time, and the By-Laws probably will not. >4/ The registrar, i.e. me, will maintain >official distributions of SMSQ/E, in binary and >source code form, one for each machine on which >SMSQ/E may run. I would recommend defining the terms "Registrar" (but not as "me") and "Distributor/Reseller". Just to fully clarify who they are and what they do. >5/ Any person may make any >changes/additions/modifications/adaptions to the >source code he feels like. Any person may give >away to others the modification he thus made, >including the official distribution in source >code form only, provided this is made ENTIRELY >FOR FREE - >no charges, not even copying charges, or charges >for the media on which this is distributed, >may be levied. I understand the total avoidance of any one making money off of the source code for SMSQ/E, but I feel not allowing charges for media a bit strict. A simple workaround would be to send the person a blank CD or other disk and some IRC's. I am assuming that IRC's are not considered a form of currency. If your local Post Office does not know that an IRC is, then talk directly to the Post Master for that Office. There is no reason for a Postal Employee to not know their job. I spent 8.5 years as a federal employee, so I know the power of the "chain of command". >This distribution of the source code including >the changes/additions/modifications/adaptions >made by any author may not be made in electronic >form other than on a physical disk. I really don't understand not allowing distribution via anything other than sneaker-net. What would be the consequences of the Registrar, putting the Official Distribution Source Code of SMSQ/E on a web server? It could be arranged that the requester must give their name and address before getting the Source Code. As someone that is about 5,000 miles from the Registrar, mail can take an awfully long time. Plus, someone like Thierry, sitting on a French Naval ship in the Persian Gulf, mail is very slow to come. As a veteran I try to keep fellow service members in mind. >Distribution of the changes/additions may be in >binary(compiled) form, provided that the >original and/or official version of SMSQ/E, >which is copyright © T.Tebby, is not distributed >in binary form as well. With all due respect, I don't think the above is physically possible. If I make a change to the SMSQ/E scheduler, I don't think that I can compile it and distribute it without including SMSQ/E (since this is what I have changed). If I can make a change and distribute it without any original SMSQ/E code, then I'm not actually modifying SMSQ/E and don't fall under this "license". I think this statement needs to be looked at again. >1/ When a new author adds some code to make >SMSQ/E better, only the resellers (and Tony >Tebby) see some profit from it. Before I comment on this statement let me first say this: If the Emperor has no clothes, I'll be the first one to say that he does not. I hope all understand what I mean. Also, I hope no ones take offense at my asking the following question, as I am not trying to offend, but ask a question that I feel is pertinent and important. So, the above statement says that only TT and the Distributors/Resellers will see profit from SMSQ/E. A further statement says "the resellers provide support when selling the binary versions, hence they should get some money". I've spend 5 years doing technical support for a living. Most companies define traditional support as meaning that if the product has a problem (like a bug), then the company is obligated to fix the bug (most of the time), else the buyer is getting no benefit for his dollars (and the support contract ma
Re: [ql-developers] Re: [ql-users] Source Code
At 01:43 AM 5/19/2002 +0100, Roy Wood wrote: >What rights are they ? As I have said we have no objections to you >becoming an official reseller if you follow the rules. In fact we would be >glad if you did because we have no wish to be involved with support for >the Q40/Q60. As an official reseller you can sell SMSQ/E for whatever you >want provided you pay the fee to TT, provide a printed manual, disk and >support for the platforms that you sell.It really is that simple. Printed Manual When I got SMSQ/E I did not get a full printed manual. I got a hardware guide and a very short guide to SMSQ/E for the Q40 (bought mine 2 years ago). The Reference Manual was extra. If I had not know much about QDOS and SMSQ/E when I got the Q40, the manual would not have kept me from being SOL. The Gold Card manual was much more in depth than the SMSQ/E manual I got. Tim Swenson
Re: [ql-users] The Next Step...
At 11:26 PM 4/20/2002 +0100, you wrote: >Unfortunately neither Turbo itself not its output is very "clean": It is >neither ROMable not Thingable ;( > >Per Given Simon's Assembly background I would think that the output from TURBO would be fairly clean (but I've never looked at it and I really don't know assembly). Given how complex TURBO is (and it's described fairly well in some of the TURBO docs), I don't know how much major changes George G. can do. You are right in that Qlib has had no recent work on it (and it does not look like it will in the near future). Which compiler you use will depend on your needs. I just wish I had more time for those needs (in other words, more time to program). Tim
Re: [ql-users] c68 question
At 12:50 AM 4/21/2002 +0100, you wrote: >But is the command line the same as stdin? I tried the syntax in (1) above >and also: The command line is not STDIN. With C (and Perl) the command line is normally stored in a variable (ARGV tells how many arguements). ARGV[0] is the program that was executed, ARGV[1] is the first argument, etc. (ARGV is close the the real answer. Check a C manual for the exact variable name. I'm going by memory here). > 3 EX cprog, file_list, #1; "-options parameters " I believe you are doing channel redirection (again going from memory). I have not tried this with C68 and found a problem with it in Qliberator (a bug caused it not to work). The Qlib docs talk about how this works. I don't know if TKII docs or SMSQ/E docs talk about channel redirection or not. I don't think it's used all that often. > 4 EX cprog, file_list, #1; "-options parameters -f file_list" > >returns "cannot open -f file_list" - ie it thinks -f file_list is one of the >list of files.. -f as one of the options makes the program take >to be the file_list filename! Ie it will happily except a list of parameters >from the file, but not a list of files. The program has to be written so that it thinks that '-f file_list' is a proper option and knows how to deal with it (in other words, you need to fill in this part to make it work). Without it knowing the '-f' option then of course it will assume it's a file name. Besides, I suggested a '-f' option as an example, you can name the option what ever you want. I'm assuming you are dealing with code that you are writing. Tim Swenson
Re: [ql-users] c68 question
At 10:28 PM 4/20/2002 +0100, you wrote: >Is there a way to get a c68 program to accept a commandline >(or part of a command line) from a file/pipe. > >I want to achieve something like: > EX cprog ; "-options parameters rather than > EX cprog ; "-options parameters file1 file2 .. fileN" >Or is all this entirely up to cprog? I'm pretty sure C68 supports file redirection. Since the filelist_file would be coming in on STDIN and not as an argument list, it is up to the program to process it correctly. With some programming skill, you could get the program to accept data either way. Using an option like "-f filelist_file" would work. This would have the user tell the program to use a file list file (and not list any files in the command line. If a program will work in Unix, then it should work in C68. It's very Unix like in how it handles itself. Tim Swenson
Re: [ql-users] The Shell's utilities
At 09:00 AM 4/20/2002 -0400, you wrote: >Hi all, >I was wondering if any one has "The Shell"'s accompanying utilities >available. The zip file i had them in is (once more) corrupt and i would >appreciate it if someone mailed them to me :-) If you don't get all that you need from Dilwyn, I had a number of utilities that came with "The Shell" and some that did not (some from C68). I can zip them up and e-mail them to you. BTW, I did an article a while back on Unixifying the QL and it covers a bunch of things like "The Shell". Check my web page for it (www.geocities.com/svenqhj/). Tim Swenson
Re: [ql-users] The Next Step...
At 04:28 PM 4/20/2002 +0100, you wrote: >Is your FileCOnfig able to create level 2 config blocks now, Tim? I have not touched FileConfig in a while, and since it's based 100% off of BasConfig, it still only does Level 2 config blocks. If BasConfig is updated, then I can update FileConfig. BasConfig comes with some extensions (if I remember right). I went through the SB source code of BasConfig and determined how each type of config item was done (using the extensions) and just wrote my own routine to do it (seriously copying from BasConfig). Tim Swenson
Re: [ql-users] The Next Step...
At 12:20 AM 4/20/2002 -0400, you wrote: >I don't see that really to be a problem. However I remember reading >somewhere about George wanting to solve this. It's like not loading >QLib_run! The thing is that Turbo being around for so long (from the time >of Supercharge) it has an impressive amount of code templates that do the >trick. And George updates it extremely often. What was the last time >Q-Liberator was updated? Additionally being restrictive in some aspects I >believe that is a feature. By being very strict programmers are forced to >write "clean" programs Given that Simon Goodwin wrote TURBO (and He and I got a chance to sit and talk tech a few years back when he was a house guest), TURBO was designed with certain "opinions" that Simon had about how he felt programming should take place. I agreed with most of his opinions except that I felt that each one had some well justified exceptions. He felt that extensions (libraries) should be loaded at startup (from a boot file) so that all programs could use them. This also allows them to be updated without affecting the executable (sort of like updating a Window .dll file or a Unix library file). This is fine, except that most of the licenses for commercial extensions said that if you linked the extension into the program, you don't need to pay a license fee. If you want to make the extension loadable at boot time, you had to pay a license fee. Sort of made it difficult to write freeware programs that used commercial extensions. I'm not faulting Simon for any of this. I too have my own opinion about programming and tools. I do fine that Qlib has worked better into my opinions, but I'm trying to get my opinions and TURBO to meet half way. One example of my opinion is that I prefer tools that produce code or some file that can be edited later if you wish to tweak things. The tool BasConfig (for creating Config Blocks for SB programming) is OK to create a Config Block, but it does not allow you to edit a definition and expand on it (say, adding another Config Item). I wrote FileConfig to get around this. The user creates a definition file for the Config Block (using an editor). The Config Block definition is run through FileConfig and out pops a new Config Block (binary file). You need to add another Item? Edit the file, run it through FileConfig and, bingo, a new item is added. With BasConfig you have to start from scratch each time. This can add up if you have 20-50 Config items. Tim Swenson
Re: [ql-users] The Next Step...
At 05:14 AM 4/20/2002 +0100, Dave wrote: >One, how do I unzip something and keep the headers. You have to unzip using a QDOS version of unzip. You can't unzip using a Windows, DOS, or Unix version. Only the QDOS version will allow the headers to come through. If you don't have an executable copy of unzip or infounzip, then check out Jonathan Hudson's web page where he give the executable and a way to re-create the headers. >Two, is there a utility like the Linux RAWRITE utility that would allow >someone to distribute disk images and have them reproduce perfectly at the >other end? Maybe, if there isn't one, someone could find a simple way to >make a disk image that RAWRITE can use? Using a QDOS version of unzip (or info-unzip) you really don't need a tool like RAWRITE. Remember that different QLers are using different versions of the file system. QBIDE HD file system is different that a QXL.WIN file, which is different than the Q40 HD file system, etc. Heck, I just got a Miracle HD system and it's probably got another version of the file system. I'm guessing that RAWRITE is something similar to 'dd'. 'dd' is OK for somethings, but I would not use it to transfer files from IRIX to Linux to Solaris, mostly because they use a different file system. Think of zip/unzip more generic like 'tar' or 'compress' (and gzip). If any North American QLer needs any of the archiver tools on a QDOS DD floppy, I can dump what I have onto a disk (got tons of them) and get it off in the mail. I think I've got a disk with a number of archiving programs on it. Tim Swenson
Re: [ql-users] The Next Step...
At 06:53 PM 4/19/2002 -0400, you wrote: >At 06:44 ìì 19/4/2002, you wrote: > >>For SBASIC programming, best start is TURBO, which is now freeware. It's not >>quite as powerfull as Qliberator, but you can get it online (check Dilwyn's >>web site) with manuals and a number of extra tools including TurboPTR, a tool >>for creating Pointer Environment programs with TURBO. > >"Powerful" is in the eye of the be(er)holder :-) > >Actually equivalent Sbasic code generated by Turbo is faster by a factor >of almost 15% or so (in tests I run) over QLiberator. >Turbo has other problems though like parameter passing... TURBO does have more constraints than does Qlib. Qlib allows linking in of extensions (TURBO does not). Qlib allows for keywords not loaded in an extension, if the code never hits that section (TURBO complains at runtime about a keyword not being available even if that section of the code is never executed). There are other examples out there. I find that TURBO feels a bit more constricting that Qlib. With all that said, I'm still a big fan of TURBO as it is FREEWARE. I'd like to see some more elegant work-arounds to some of the issues, but I'll take what I get. The combination of TURBO and TurboPTR is the only freeware way to write PE programs in SBasic. Tim Swenson
Re: [ql-users] The Next Step...
For SBASIC programming, best start is TURBO, which is now freeware. It's not quite as powerfull as Qliberator, but you can get it online (check Dilwyn's web site) with manuals and a number of extra tools including TurboPTR, a tool for creating Pointer Environment programs with TURBO. As for other things, go to my web page (www.geocities.com/svenqhj) and check out my documentation page. On it is the "SuperBasic Sourcebook" and I cover a variety of freeware toolkits and tools for SuperBasic. Toolkits like DJTK, DIYTK, Qsend, DBAS, etc. There really is a bunch of this stuff out there. The Sourcebook also talks about tools like Editors, and such. Of cource I like to push my Structured SuperBasic (SSB) filter program. Also, check the verious QL download pages on the net looking for programming utilities. If there is something specific that you are looking for and can't find it, ask the list. If there is a tool you can't find on the web (but you know it exists), let me know as I might have a copy someplace and can e-mail it to you (I like to collect SB programming tools). Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] THING questions
>On 16 Apr 2002, at 11:15, Timothy Swenson wrote: >> 1 - What is a Forced Free? >> I know that you FREE a THING when an application stops using it, but I can't >> find an explanation for FORCED FREE. > >Forced free is when the job owning the thing is removed. A thing >could be set up in such a way that the linkage block is not stored >in the common heap, but within the memory area of a job. When >that job disapperas, so will the thing. Hence a routine to make sure >that all other jobs using this thing will also disappear - that is >forced free. This sounds a lot like a ZAP (removing the THING and all Jobs on it's USAGE list). Is there a situation when a Forced Free would apply versus a Zap? >> 2 - What is a Forced Zap? >> The TT docs talk about ZAP and use the term FORCED ZAP in defining the THING >> table. It looks like a FORCED ZAP is just another word for ZAP. Is this correct? > >Sorry, I wan't able to find where it mentiones a forced zap. A zap is >normally the removal of a thing. You can force remove a thing. The online THING documentation mentionens "Forced Zap" but is changed in the SMSQ/E docs to "thing owner is removed". I should have caught this. >> 3 - Pointer to "close" routine vs. Pointer to code >> In the THING table, TH_FRFRE is defined as a Pointer to "close" routine for >> Forced Free, and TH_FFREE is defined as a Pointer to code to Force Free a THING. >> What's the difference between the "close" routine and code for Forced Free. >> Would these two pointers point to the same code or are they two unique pieces >> of code that do two different operations? To me it looks like the two pointers >> are redudant. > >TH_FRFRE is an OS supplied piece of code - don't touch it. >TH_FREE is the code the thing writer supplies for a forced free (i.e. >the job ownning the thing is removed). The statement in the SMSQ/E docs just above the definition of the THING table states: "Items from TH_THING onwards (inclusive) must be filled in by the initialization code..." This leads me to the conclusion that the fields TH_NXTTH, TH_USAGE, TH_FRFRE, TH_FRZAP are all filed in by the system and the user does not need to worry about them. Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] THING questions
Thanks Wolgang and Per. The pieces of the puzzle are coming together. I'll document what I sort of understand and then make it available for others to tell me how wrong I was (and give me the right answer). Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] Thierry's CD ROM extensions and QDOS
The CD rom extension is a THING. If you have the PE installed, then you should have the THING system loaded. The PE contains the Window Manager, Pointer Interface, HotKey System II and the THING System (anyone should feel free to jump in with both feet if I'm wrong about this :-) ). If you don't have the PE, I think there might be a THING_REXT available someplace on the net. Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] THING questions
> >IIRC all these are explained in the QDOS/SMS Reference Manual I have not looked there, so I'll have to check my copy. Now as for the explanation being clear, I'll have to see. The QDOS/SMS Reference Manual was aimed clearly at the Assembly programmer and seems to make some assumptions about the knowledge of it's audience. Tim ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
[ql-users] THING questions
I find that documenting a new subject helps me learn that subject. So, to better understand THINGs, I'm working on some THING documentation aimed at the general user. I'm reading the THING documentation from TT and the THING articles by Jochen. I've run into a number of terms and issues that I don't quite understand. I thought I would ask the list to see if I can get these questions resolved. 1 - What is a Forced Free? I know that you FREE a THING when an application stops using it, but I can't find an explanation for FORCED FREE. 2 - What is a Forced Zap? The TT docs talk about ZAP and use the term FORCED ZAP in defining the THING table. It looks like a FORCED ZAP is just another word for ZAP. Is this correct? 3 - Pointer to "close" routine vs. Pointer to code In the THING table, TH_FRFRE is defined as a Pointer to "close" routine for Forced Free, and TH_FFREE is defined as a Pointer to code to Force Free a THING. What's the difference between the "close" routine and code for Forced Free. Would these two pointers point to the same code or are they two unique pieces of code that do two different operations? To me it looks like the two pointers are redudant. 4 - How long is a THING name? TH_NAME in the THING table does not seem to have a definition of how long it should be. It is defined as a QDOS string which has a terminating character? Is there any limitation on size? 5 - THING Header I'm guessing that the THING Header (as defined by TT) is part of the THING code itself (as pointed to by TH_THING) and not part of the THING table. If so, is the header the first bit of code in the THING? Hopefully someone will know the answers to these questions and take the time to enlighten me. Thanks, Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] Suggestions...
At 12:48 AM 4/12/2002 -0400, you wrote: >Seriously though, you are REALLY good at it :-) So was the Army (Air >Force) to blame for that? > >Phoebus Well, I did spend 8.5 years as an Air Force Officer, but I don't know if my writing style was affected by my service time. AF writing is more like dry business writing. Tim
Re: [ql-users] Suggestions...
At 02:18 AM 4/11/2002 -0400, you wrote: >Definitely a must-read :-) Tim is extremely talented in making even the >most complex subjects easy to understand... Ok, was that $5 or $10 for the glowing remarks. :-) Tim
Re: [ql-users] Suggestions...
At 01:11 AM 4/11/2002 +0100, you wrote: >On Wed, 10 Apr 2002, Phoebus Dokos wrote: > > > I suggested to Dave to start off with MicroEmacs as since he's been using > > Linux he would be a known environment (QD is FAR EASIER TO WORK WITH > > than MicroEmacs :-) > >If it's anything like emacs, I'll pass... I'm a pico person :o) MicroEmacs is really nothing like Emacs. The version done by Thierry has menus so that the command keystrokes really don't need to be memorized. The problem with MicroEmacs is that it can be a bit slow on a Gold Card QL (which is what I am currently using). A simpler editor is QED, which is a clone of Metacomco's ED. QED is fast, small, and fairly easy to use. It even allows for simple macros. MicroEmacs has a full macro language (with conditional statements and loops), plus it can execute other programs. As for programming, if you are using SuperBasic, I might suggest looking into Structured SuperBasic. It's a S*Basic preprocess and filter. It allows SB code to look like C or Pascal with spaces and no line numbers. It also allows preprocess command like "conditional compilation", just the C preprocessor does. It's free and I wrote it. You can use MicroEmacs and use a macro that will save the file and execute Structured SuperBasic, and then call Qliberator (working on a Turbo compatible version). So, you can do all of the compiling process without leaving MicroEmacs. BTW, On my web page (www.geocities.com/svenqhj/) is my "SuperBasic Source Book" that covers some details about using Qlib, plus a bunch about freeware tools for SB programming. It's a few years old, you might find it usefull. I cover a number of freeware toolkits available (and possibly some commercial, but I can't remember). SSB is also on my web page. Tim Swenson
RE: [ql-users] EasyPtr
At 11:07 AM 4/9/2002 +0100, you wrote: >Nah, it's just the windows concept of programming. I never got to grips >with Windows programming on PCs or X-Windows. And as for C++ and Object >Disorientated programming, well... Sometimes it's easier to learn by comparing the same general topic between computer systems. I started learning Windowing by reading on Perl/TK and comparing it with the Pointer Interface. It helps a little bit, but the data constructs and terms are very different. I've also tried understanding the QDOS kernel my learning the Unix kernel. Tim Swenson
Re: [ql-users] Miracle Hard Disk
Tony, I got some hard copy with the one that Ruth sent me. I can either photocopy and send via snail mail, or I can scan it in and send to you. Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] Turbo
> >I am currently using Turbo Toolkit v3.32 and have noticed that some of my old >software compiled with an earlier version of Turbo just hangs under SMSQ/E... > >Does anyone know why?? Rich, Can you give some code examples and the failures you're seeing. To help GW, I've volunteered to do some bug triage and pass the stuff to GW. If you can give some examples of the failures and possible parts of the code that is causing it, I can try to a little more debug and then pass the info over to GW. Thanks, Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] QL Stuff
So, it looks like I have a spare PSU and Francios has one also. Dave & Phoebus, why don't you decide if you both need one. Since I am sending a package to both of you, you two can decide who gets the PSU. And then decide to whom Francios can send one to (if he still feels so generous). Tim
[ql-users] QL Stuff
Jack Boatwright sent me a bunch of older QL stuff. Most I don't have a need for, so I'm willing to send it on to any US QLer that is interested. His is the list of stuff that I got. DP Lightening (microdrive cart) DP 3D Precision CAD (5.25" disk) DP Professional Publisher manual DP Super Media Manager manual DP Prof. Astrologer/Astromomer (microdrive cart.) QL Paint manual (photocopied) IQLR issue Vol 4 #3-6, Vol 5 #1-6 QL manual (2 pages/page) + Keywords section Text87 manual (photocopied) Qram manual Turbo Quill Manual Taskmaster Manual QL Speedscreen Manual TKII manual a bunch of QL feet Assorted 5.25" disks with Quanta stuff on them I have not tried the media, so I don't know if everything is still good. It looks like this was a bunch of old supplies from RMG when he went out of business (I even found some RMG and A+ letters). First person to ask for an individual item gets it. Tim Swenson
Re: [ql-users] SMSQ/E license criticisms
>But that is actually the case if you click the 'accept' box in Windoze. >You are not legally entitled to sell your copy of Windoze 98 on to >another user even if you have stopped using it yourself. It is all there >in the small print that no-one reads but every one, including the >pirates, agrees to. Most software license agreements are not worth the electrons they are printed on. Some software license agreements had content that was illegal and would not hold up in court. In fact, I don't think any software license agreement has actually been run through a court room (or at least that what I read in the general computer press). So, buy feel free to buy software and don't worry about your first born child. Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] SMSQ/E license criticisms
I don't know if everyone is ignoring me, but I made a few points about the SMSQ/E statement that can make all of the discussions going on a mute point. The statement says that no one can SELL SMSQ/E except for the distributers. It made no mention of any person giving a SMSQ/E binary to any other person (except for PD libraries). Now, we can leave the statement as is and freely pass around binaries, much to the consternation of TT and the registrar, or the statement can be fixed to either block or control personal distribution of the binaries. I understand the spirit of the statement, but the wording is very bad and it is the wording that the law will follow. If I tell my daughters they can't watch TV in the front room, I can't yell at them for watching TV in their room. I may have thought "they can't watch TV at all" but only said "can't watch TV in the front room". There is a difference. Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] Source Code Status
As one of the Pacific Time Zone QLer's, I get to be late to the conversations, but at least I can have a try at the final word. >3/ No distribution of SMSQ/E may be SOLD, except for for the official >distribution. >This interdiction includes that of including and distibuting SMSQ/E in Public >domain libraries. >Official distributions will be sold in compiled form, possibly together with >the official distribution as source code. >For such sales, for the time being, two distributors, namely Jochen MERZ (JMS) >and Roy WOOD (QBRANCH) have been appointed by the copyright holder. A strict interpretation of the above would allow anybody to give the source and/or binary version of SMSQ/E as long as no money changed hands. The part of not including it in an PD libraries would not prevent any person-to-person transfers. I think the above statement is very badly worded. I sort of understand the idea behind the statement, but there are logic holes that I could fit a Mac truck through (or Lorry for you non-American speakers). >5/ Any person may make any change to the source code he feels like. >Any person may give away to others the modificaton he thus made, including >the official distribution in source code form only, provided this is made >ENTIRELY FOR FREE - >no charges, not even copying charges, or charges for the media on which >this is distributed, >may be levied. But, a charge can be made if the original source code is not included, meaning just any new code that the author created. Also, if I can compile just my code as a stand alone object, is this statement saying that I can't distribute my own stuff, even without the SMSQ/E source code. Again this is badly worded and leaves more logic holes, esp. when trying to tell an author what they can or can not do with their own code. >G - >Is anyone interested in doing a nice documentation package? So many people >out there >have protested about no documentation being available. NOW is your chance >to make a >contribution. Well, I hate to talk about something in the works, esp. when I don't know when I might finish it, but I'm currently working on a "Idiot's Guide" (in the same vein as the one Norman did) for PE programming and on THINGS (so that I better understand it all). I would like to do one for the OS in general and have a draft that is only about 20% complete. I prefer to have documentation that does not assume the reader knows assembly. I also like the more complex OS documentation to use terms used by other OS books (processes, threads, atomic, semaphores, mutex's, etc). I try and understand both QDOS and Unix by comparing the two, picking up little pieces of each as I go. Anyhow, I've read the formal statement, and I've read a lot of the feedback today on the statement and I don't see a lot of the issues that others saw. Somebody make a comment about not being able to distribute binary copies of SMSQ/E, esp. if they compiled them. I don't see that in the above statement. Only a restriction on SELLING copies (both source and binary). The statement seriously needs to be revised before those Mac trucks come rolling through. I spent the last Fall re-writing By-Laws for a local non-profit, that was reviewed by the press and the City Attorney. I'm good at catching loop holes and making sure they don't exist (kind of like preventing bugs in code). As is, the above mentioned statement is fairly weak and contains statements that will not stand up in court. I'd highly recommend that it be reviewed by the registrar, TT, and any others. I really does not accomplish what it sets out to do. So until the statement changes, I don't think any one has anything to worry about. Tim Swenson
Re: [ql-users] Q40 to ql transfer
At 08:15 AM 3/22/2002 +, you wrote: > >When I was using my Z88 and the QL, to copy data from the Z88 to the QL > >all I did on the QL was: > > > >copy ser1_ to ram1_file_txt > > > >and then have the Z88 send the file. When the Z88 was done, I hit > >CTRL-C on the QL to break out of the copy. Worked like a champ. The > >same principle should work for the Q40 to QL xfer. > >The champ breaks down very often, especially at 9600, as the 8049 code >was very broken. That was why the Astracom modem was developed for the >QL - it was the only 'real' modem that worked with the QL at 9600. I guess I forgot to say that I kept my baud rate down to 1200 for my transfers. Did not really transfer large files. I don't know about the UK, but the above worked for my on a US QL. Never tried between QL's, but I did do QL-Z88 and QL-PC. Tim
Re: [ql-users] Q40 to ql transfer
With a null modem cable (or Ser1 on the Q40 to Ser2 on the QL), it should be fairly simple to send ASCII data (and possibly binary). When I was using my Z88 and the QL, to copy data from the Z88 to the QL all I did on the QL was: copy ser1_ to ram1_file_txt and then have the Z88 send the file. When the Z88 was done, I hit CTRL-C on the QL to break out of the copy. Worked like a champ. The same principle should work for the Q40 to QL xfer. Tim Swenson
Re: [ql-users] Open source
From what Marcel is saying about his continuing to focus on QPC code changes, and debate if he should port the changes to the Q40 (I hope that I summarized that correctly), we may need to tailor our approach to how we do this. I would really, really, really, like to see SMSQ/E behave basically the same on all platforms (QPC, Q40, QL, uQLx, and so on). Given that Marcel seems to be the closest to the code, he can take the lead on what happens with the core of SMSQ/E. There can be different persons designated to port the main changes to the other platforms (Q40, uQLx, etc). This way Marcel could concentrate on moving forward. I would suggest that portability be of higher value than taking short cuts due to some different feature in the underlying hardware. As for paying for all of this, we could leave this option open to the different porters involved. If the person doing the Q40 changes contributed his work for free, then the Q40 changes would be free and so on. If the port comes from a lot of code that Marcel has done and Marcel has decided to charge a fee for his work, then the Q40 port would come a some fee. Personally, I'm not too worried about paying a small fee for seeing new features. Heck, I'd be willing to do a subscription service for changes (say $X per year). This approach might generate enough funds to cover the work. Marcel, there might be a portion of this whole project that must be done for free. I can see you charging for QPC changes, but any work done for the WHOLE project, might be done as a volunteer (sort of overseeing the project). Might this be workable? I understand Jochen's concern. If SMSQ/E and extra parts to QDOS (wman, ptr_gen, hotkeys) move toward Open Source, then what happens to the license to distribute these binaries? After a certain date, can I freely distribute the PE to any QLer? We need to think about this issue. We need to think about how it will affect the dealers, esp. Jochen. Will the SMSQ/E documentation be freely available, or will the fees that Tony received be removed and lower the price of the documentation? Jochen, I think it's time for you to jump in and speak your mind. I think you should feel free to let us know how it will affect you, esp. in the pocket book. I appreciate the discussion of technical details on the list of possible changes to SMSQ/E. I don't know the OS at that level so I'll stay out of the conversation until something is mentioned on how it will affect the user. But thanks for keeping it in the list so those interested can read. I think that opening up SMSQ/E is a good thing for the QL world. How we do it should be contrained by how much it will affect all those involved. I don't see a necessity that it be fully GPLed. At the very least I think that the cost of SMSQ/E, documentation, and updates should come down in cost. (I'm assuming that TT will no longer expect his normal license fees). I can see paying a few $$ for the source code and such, to cover the cost of distribution and work. I do think that the more the code can get out to other programmers the more features we will get. One more thought, since SMSQ/E can be modularized, I'd seriously recommend that features that can be added via modules and kept out of the core OS code, be done this way. This will keep the core code smaller and easier to maintain. Authors of new features can implement their code without relying on someone to check the code into the main source tree. I look forward to hearing what other think and to what the final decision is on how the community is going to go about this project. Tim Swenson
Re: [ql-users] Open source
At 02:20 PM 3/15/2002 +, you wrote: >Ok, now I am totally confused. Open source has a very specific meaning. >And this isn't it. If the source isn't going to be generally available, it >isn't open source, and you shouldn't call it that. I think we can expect the source code to be available, but any "official" changes to the code would have to go through the registrar. For some Open Source means using the "official" Open Source license. For others Open Source means all source code licenses (including the GPL). For Richard Stallman (founder of the GNU Project), Open Source and the GPL are not the same thing. The SMSQ/E project can use pretty much what ever license that is available, or create a new one. I don't think the GPL would fit for our project, but some other related license might. I think it would be up to the community (and really TT) as to the specifics of the license. Open Source does not mean that the source code cannot be put on a CD and sold. The GNU folks used to charge $150 for tapes of GNU software. I'd be willing to put down some money to get the source code and any documentation that goes with it. I highly recommend that a group of folks get together at the next big QL show and hash out the initial details in person. Divide the entire projects into smaller chunks and start getting volunteers to take on each chunk. Documenting the source code could be broken down and distributed. Speaking of documentation, I think the subject of the QDOS/SMSQ/E and QPTR documentation needs to be discussed as this is still being sold commercially. If the docs do also become available with the source code, we'll need to find a way to offset the loss to any vendors involved. I think a fully open SMSQ/E would benefit the entire QL community, but it will cause some loss to some (namely vendors). We will need to address this issue. If we pass the hat, maybe a certain amount of the sum should go to the vendors too, and not just TT. Jochen, since you are probably going to be the most effected, time now to get up and say your piece. Let us know how much this might hurt your business and suggest ways we can offset the loss. Tim Swenson
Re: [ql-users] Open source
At 07:48 AM 3/15/2002 +0100, you wrote: >On 14 Mar 2002, at 20:22, Timothy Swenson wrote: > > > The person who I think has the best qualifications to lead the group, due > > to his in depth knowledge of QDOS, SMSQ/E and 68000 assembly code, > would be > > Simon Goodwin. > >I'm not so sure about that, due to his strong opposition against the >PE. I was not aware of any opposition Simon had of the PE. I know that Simon has some strong feelings about how things should be done on the QL and TURBO reflects his design decisions. Whomever the person is they have to be fairly organized, willing to take a few barbs from programmers feeling that their code is great and just the right thing for SMSQ/E. I would think the person has to be fairly familiar with 68000 Assembly and be the person to do the final build. So, folks, now is not the time to be shy. If you feel you have the right skills and chutzpah, come one and step up to the plate. Tim Swenson
Re: [ql-users] Open source
At 06:58 PM 3/14/2002 +0100, you wrote: >I've just spoken to Tony Tebby. He agreeD, in principle, to make >SMSQ/ Open Source. First, let me say this: Waah!!! Ok, now that that has been said, I've got some ideas of how this process might go. I'd recommend that a committee be formed to oversee the further direction of SMSQ/E, with one person leading the effort (sort of like what Linus Torvald is to Linux). Here are the people that I'd like to see on the committee, based on how well I think they know SMSQ/E: Jochen Merz Marcel Kilgus Nasta Thierry Godefroy Wolfganz Lenerz Richard Zidlicky (There may be others, but I can't think of them right now) From the Commercial Side, Roy Wood and Tony Firshman. It would be nice to get Lau involved, but I don't know his availability (I'm a bit out of touch out here in the Pacific Time Zone). The person who I think has the best qualifications to lead the group, due to his in depth knowledge of QDOS, SMSQ/E and 68000 assembly code, would be Simon Goodwin. I know that he is not as active as others, but he really knows his stuff. It might take some convincing to get him to accept such a position, and it might take some work to get him to work well in the position. At the very least, we should get him involved because he probably writes 68000 assembly in his sleep. I only got to spend a week with him when he came to the West Coast Sinclair Show back in 1999, but I think I got a feel for the man (pre-fatherhood). I would recommend that the model/process used by Linux we the model that we adopt (with possibly some modifications). Strategy meetings could be held at different well-attended QL shows, where most of people involved would attend. I would recommend that others get involved in doing other duties (such as testing, documentation, etc.). I'd be willing to assist on the documentation. Any way we can get Tony's address to send "Thank You" cards? Tim Swenson
Re: [ql-users] The future of SMSQE- a user's point of view
I think your message may have been aimed at the postings I made. So I'll take a moment to defend myself. >DON'T extend, update or uograde SMSQ/E I actually encouraged further development. >DON'T make the system more appealing by dding new feature I actually encouraged new features. >DON'T worry about the slave blocks problems I never discussed it, but, PERSONALLY, I'm not worried about the slave block issue. At least I'm not spending my time worrying about it. >DON'T touch that 36 characters limit I did not touch this one, but, except for porting Unix stuff to SMSQ/E, I've never had a chance to hit a situation where I found the 36 char limit a problem. I've just never hit the limit with my filesystem. >DON'T make SMSQ/E more appealing and user-friendly for non QL users I did not say "don't", I said we have little chance of converting a "I've never seen a QL" person to using the QL. I prefer to see bang for the buck. Put the most effort where it will do the most good. I also feel that those that have been using the QL for soo many years should have input into where it is going. If a poll of QL users determines that most one feature A and most don't want feature B, then development should proceed to feature A. BUT, I do feel that any QLer can do what they want. If you feel like writing a new device driver for an obscure device, go for it. Don't let me stop you. And finally, how I see the development of SMSQ/E is heavily biased by my own computing needs. If I don't Flash or MacroMedia on the QL, then I don't be pushing for it. I hope I've made myself clear. Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] The future of SMSQ/E
Hmm, I think you misunderstood what I was getting at.
1. I see very few chances of getting new folks to the QL. This is not a
bad thing, just reality.
2. I would like to see further development for the QL world. The recent
developments for TCP/IP and CD access are prime examples of what
development I am talking about. I don't see development to compete with
other OS's ("Gee, Linux has Gnome and KDE, let's get something for SMSQ/E"
or something like that)
3. Current users will demand more features. The QL world has done this in
the past (color drivers) and will do it in the future.
4. I am not proposing we not support the current developer. In fact I
propose that we expand the number of people developing SMSQ/E.
At work I have to worry about what other people want and need for their
computer needs. In some cases, what I use is dictated to me (I use a Win2K
system as my desktop machine).
QDOS and SMSQ/E are the only system that I have chosen to put a lot of time
and effort into, without pay. I gauge the future of SMSQ/E by my personal
needs. This may seems selfish, but I've got 16 years invested in this OS
and I'm pretty picky about making any major changes and forcibly putting in
features that I don't feel I need. I plan to use my QL systems for as long
as I can.
I look at my QL systems like a nice, well designed tool (such as a
hammer). I don't upgrade until I really need to. I won't buy a new hammer
until my old one no longer fits my needs. I guess this has been the main
reason I've used the QL for so long. I really fits my needs.
Tim Swenson
Re: [ql-users] The future of SMSQ/E
Windows was successful not because of the desktop, but because it was based on MS-DOS, the winner of the desktop OS wars. Back when the PC first came out there where three reasons to by the IBM PC; I, B, and M. IBM validated the PC for business use. By the time Windows came out, the only competitor was Apple, and they were always priced higher. Popular does not always mean better. Betamax was technologically better than VHS, but VHS won the marketing battle. I don't want to use an OS designed for the "average" person, who still has problems getting the VCR to stop flashing "12:00". I have no interest in marketing SMSQ/E to the outside world. I find it great for my own purposes and I leave it at that. If I had my own company, I would probably use 100% Linux. I prefer SMSQ/E for my personal computer and personal programming. It is my opinion that future of the QL should be aimed squarely at the present users will very little consideration to expending to new users. Yes, I would like to get some old QL users back into the fold, but I don't think we'll be able to convert Win2K or Linux users. Point-and-click is OK for some things, but I find I can get files copied faster with a shell than by using two GUI file browsers and dragging and dropping between them, esp. for mass copying. Luckily I learned touch typing years back in High School and I use it every day. The only problem I have is typing "copy file_txt" instead of "cp file_txt" when I'm at work. I also find moving my right hand from the keyboard to the mouse, and back again, can slow things down. I've seen a real good Win2K person doing everything to administer a server without touching the mouse. Remember, this is only my personal opinion. I feel that it is SMSQ/E that I have the most to help control the future of and so I want to get as much input as I can. There is no way I can influence the direction of Linux or Unix in general. Tim Swenson
Re: [ql-users] The future of SMSQ/E
At 10:52 PM 3/11/2002 -0500, you wrote: >Tim, >A real desktop and a standard Look and Feel are required for modern >computing platforms, it's both useful from an aesthetic view and from a >usability point... Browsers, gfx programs... why don't we have these >things on a QL? Ever tried to write something like that? I am currently >and it's a real pain as the OS doesn't help at all, ProWesS could be of >real help due to it's nice "connectivity" with its "API" but it's slow >therefore impractical... A desktop and a "look and feel" are to separate things. WMAN is a GUI without an ingrained desktop. In writing X window programs, there is no reference to the desktop and is very similar to writing PE programs (at least with Perl/TK). Suntools was a simple desktop that did not allow for documents to be icons (only executables) (and if I remember correctly). I like the feature of the PE that does not require an actual desktop. I have found desktops to be usefull with Linux/Gnome only when I did not know much about what apps to run and used the app launcher feature on the desktop (kind of like Window->Programs->). But with SMS/QE, most of the main apps I've loaded myself so I know where they are and can easily add them to Qascade. Everybody seems to be heading the was of the desktop metaphor, but I do not like it and do not see it as a necessity. I can't think of a single requirement that would make a desktop a necessity. Tim Swenson
Re: [ql-users] The future of SMSQ/E
At 10:35 PM 3/11/2002 -0500, you wrote: >1. Being really a part of the OS ever present and without memory loss X is not an ingrained part of Unix, but it seems to do fairly well. The GUI for QDOS and/or SMSQ/E could be an addable feature (like X). >2. Extremely fast. Yea, speed is the main issue for why I don't use ProWess. >3. Being able to provide a TRUE desktop where now we have a patchwork of a >quasi GUI routines and pseudo graphics. I've never fallen for the whole desktop metaphor, be it the Xerox interface, Mac interface, or Windows interface. I've used desktops on Xerox, Macs, Unix (Sun, SGI, Linux), and Windows and found that I could get by without the desktop. Mind you a GUI is perfect for opening other shells. But the desktop bit with files on the desktop, and such, not for me. I think using Qascade and using buttons is a better metaphor. Tim Swenson
Re: [ql-users] The future of SMSQ/E
At 04:36 AM 3/12/2002 +0100, you wrote: >You're satisfied with 512x256 as resolution? Wow, that's about the >size of a bunch of icons on my screen ;-) I don't use a desktop on the QL and really don't see a major need for a desktop. I use them at work (IRIX, Linux, Windows) and find them moderately usefull. For the QL, I find Qascade fits my need to fire off programs. Anyhow, I feel a GUI is just there for me to open more shells :-). Tim Swenson
Re: [ql-users] The future of SMSQ/E
At 10:19 PM 3/11/2002 -0500, you wrote: >IMHO what should be done is to leave WMAN alone and work on an entire new >PE that could give the QL a whole new GUI, >there all new developments and features could be implemented without >sacrificing compatibility with older apps (since the original >PE would still be in place). There the common "look and feel" as well as >other features could be implemented from scratch neatly >and correctly taking into account all possible QL platforms. Isn't this what ProWess is? A whole new WMAN system with lots of features over the PE WMAN? Tim Swenson
Re: [ql-users] The future of SMSQ/E
I did a quick scan on what you are proposing. My main concern is to make sure that any PE program compiled to use the new WMAN and colors will still run with the older WMAN. I'm assuming that the older WMAN ignored part of the 16-bit color word and will continue to do this. As for colors in general, I don't use them other to view JPG's ( and don't really look at them too much on the Q40). I'd like to see more people on this "project". I like that Thierry did to write CD drivers of SMSQ/E. Using this approach, additional capabilities can be brought to SMSQ/E without having to get into the original source code. I would encourage you to work on documenting areas of SMSQ/E that are sparsely documented. I've been going through the QPTR manual to figure out PE data structures, and I've found inconsistencies between QPTR and the C68 examples (both written by TT). Some attributes are mentioned but are not detailed (a one word description of an attribute does not help too much). The QPTR concept section is done alphabetically and not from general to specific (Imagine learning division before subtraction because it's alphabetically before subtraction). I think better documentation might allow more people to do other driver development. I would encourage others to help in writing documentation (like Norman's "PE Idiot's Guide). I'm doing some documentation that I should have a beta release soon for. It's nice to see that you are working to move SMSQ/E forward and I highly encourage it (esp. since you volunteered yourself). I think it would be worth approaching Tony Tebby to see what it might take to open up SMSQ/E development, either as Open Source, or a loose confederation of developers that sign an NDA about SMSQ/E. There are many approaches one could try to get SMSQ/E to be so dependent on one individual. There might be a few others that are willing to toss a bit into a passed hat. To quote a 60's TV show," Good luck, Jim. This message will self destruct in " Tim Swenson
Re: [ql-users] Membranes
After 12 years of using my QL with a keyboard interface, there is no way that I am going back. I think the true solution to the membrane issue is to get a keyboard interface. Then, if the keyboard dies, there are tons more available. Plus, you can get one to the layout and color that you like. I was able to find a black Acer keyboard for $5, 3 years ago. Plus, with the Keyboard-90 Interface I can use the CueCat bar code scanner that Radio Shack was giving away. I also have a habit of beating on a keyboard when not in the best of spirits. The keyboard I can sacrifice, the QL I can not. It's safely tucked under a small wooden table I've build to hold the monitor. Tim Swenson
Re: [ql-users] PCL3 printers
At 11:00 PM 3/5/2002 +, you wrote: >Does anyone know where I can download a listing of PCL3 or 5 commands >for programming purposes? Dilwyn, I have a copy of the HP PCL 5 Printer Language Technical Reference Manual. If you can't find what you need, I can scan in parts of the book and send it to you. Tim Swenson
Re: [ql-users] Frank Davis - accident
Here is a web page for Jack Boatwright. http://www1.outlawnet.com/~jboatno4/ ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] Frank Davis - accident
At 10:37 PM 2/24/2002 -0500, you wrote: >I still have a few boxes of stuff put away. > >Paul Holmgren Luckily that stuff was not in your house when the exploding furnace happened. Are you waiting for the stuff to become collector's items? Tim Swenson
Re: [ql-users] Frank Davis - accident
At 02:34 AM 2/25/2002 +, you wrote: >Although my studies were more aimed at air accident investigation, Interesting that you studied Aircraft accident investigation. My Air Force instructor pilots were worried about me causing such accidents, so I washed out of Pilot Training. My landings weren't that bad. At least I had an equal number of takeoff and landings. We used to read a instructional book called "Road to Wings" which detailed Class-A T-37 mishaps. Since most of the photo's of the accidents showed charred planes, the students called the book "Road to Toast". I still have it along with some of my other T-37 training workbooks. To get back on topic, it was John Rish that sort of took over the QL and Z88 business from Frank. John started doing Z88 repairs for Frank and then got more into straight sales. I have not heard much from him in a year or two. It's probably safe to say that there are no active US QL dealers in the US. I think Jack Boatwright in Oregon still has a bunch of stuff that he picked up from RMG (a long time Sinclair dealer in the US). Tim Swenson
Re: [ql-users] Frank Davis - accident
>As an on-topic note, I used my QL at Uni. I wrote several BASIC programs >for subjects like energy distribution, acceleration vectors, suspension >behaviour etc. I had an Independent Studies course in College to get me just over the number of credits to graduate. I was studying Cellular Automata and concentrating on One-Dimensional. I wrote the main program that demo's the CA on the QL using Metacomco Pascal. Since the Professor needed a demo, I packed up my entire QL and took it off to the college, set it up and demo'ed the program. Luckily he had no problems with me writing software for a computer the college did not have. But, his computer graphics class was still using an old kludged CP/M computer with some special graphics hardware. For his office, he was using a Sun-2. I found a bug with Metacomo Pascal and contacted the US office (here is Silicon Valley). I sent them a microdrive with the source code. One of the support guys thought there was a QL stored somewhere around the facility and tried to find it. Never did hear back from them. About a year later they closed the US office. Tim Swenson
Re: [ql-users] Frank Davis - accident
Sorry to hear about Frank and Carol. While living in Ohio I got a chance to drop by and visit them in Peru, Indiana. I'm guessing that you got the news from Paul Holmgren, since I think he still keeps in touch with Frank and Carol. They don't live all that far apart. Tim Swenson
[ql-users] QPTR Window Structures
I've finally decided to sit down and figure out how to write programs in the PE. The first step I'm taking is to understand the different PE structures (Windows, Sub-Window, Items, Objects) and what the attributes are of each one. I'm reading the QPTR docs and looking over some C68 examples (which do a good job of detailing the attributes). The problem I have is that the C68 examples and QPTR.H does not seem to contain all of the structures. There are two ways to do complex menus; Menu Sub-Window (a sub-type of an Application Sub-Window) and a Menu Window (a secondary window). The C68 docs have a WM_appw for an Application Sub-Window. WM_menw looks to be a Menu Window and not a Sub-Window (it has a lot of the same attributes as a Window). Am I right in thinking that the C68 QPTR.H does not have a structure for a Menu Sub-Window? Tim Swenson ___ Free Domain Name Registration with Web Hosting at Lanset Communications. 56k Dialup, Web Design, and Colocation at http://www.lanset.net
Re: [ql-users] Sources
At 07:51 PM 2/7/2002 +, you wrote: >In-Reply-To: <[EMAIL PROTECTED]> >Tim Swenson suggested, inter alia, the following book when I >originally asked about books on computing: > >"The Elements of Programming Style" Kernighan and Plaugher Here's a link that has a summary of the lessons in the book. http://users.erols.com/blilly/programming/The_Elements_of_Programming_Style. html I don't know if any of your local libraries have old book sales, but this is a great source for older books that are computing classics. At one time I had a spare copy of this book, I must have already passed it on to another QLer. Tim Swenson
Re: [ql-users] List etiquette. (Was: ms-users-and-smalltalk-list)
I thought I would chime in here on the current topic of the mailing list. In keeping with the style I find a lot of the traffic on this group to be not really worth my time to read. The delete key is my handy little friend and I use it often after skimming the subject line. There is too much "Oh, Yea" or "Me, too" messages. I do read the list because amongst all of the chaff there are occasionally little bits of gold, well worth my time reading most of the messages in the list. As a reader of USENET for 13 years, I know that at time the signal to noise ratio can be low, but I'm used to it. I find the list to be my main source of current QL information and help. QL Today is nice, but the mailing list is current and timely. I will not unsubscribe from the list, because to do so I would become a QL hermit. I prefer to be the guy sitting in the back of the room, listening to all the discussion, and piping up only when I have something worthy to say. I'd rather have the mailing list chatty than completely silent. So, continue on with the blather, my friends, as this California will listen. Tim "flame me, I dare you" Swenson
Re: [ql-users] Replacing S*Basic procedures
At 11:48 PM 1/31/2002 -0500, you wrote: >I was wondering if there was a way to change or "enhance" standard S*Basic >commands. > >I'm pretty sure that this is impossible from Basic but what about machine >code... for example instead of writing an x_Print x,w,z,d,s command, >redefine the standard Print command to be extended (I suppose that there >MUST be a way to do this, as TK2 for example does it) I think what you are getting at is that TK2 takes the original definition of, say EXEC, to include the option of having arguments, i.e. EXEC foo;"bar". I believe how this is done is that TK2 includes a resident procedure called EXEC and this newer EXEC takes precedence over the older definition in the name table. I hope I interpreted your question and I hope I'm right in my answer. Tim Swenson
Re: [ql-users] Linux on the SGC?
At 12:09 AM 1/26/2002 -0500, you wrote: >At 07:58 ìì 25/1/2002 -0800, you wrote: > >Yep but still very relevant... >I wonder who did that and if it's available from its author (well I want >tell PH if you don't ;-) > > >Phoebus > >Oh and Tim, sorry for the delay on sending you the file I promised... but >between the CF, on-line classes, regular classes, the baby... etc... well >you know :-) I'll try my best though! Looking in QHJ #1, it looks like Felix Croes started the project (but soon dropped it and also dropped the QL) with Erwin Dondorp ([EMAIL PROTECTED] ***10 year old address***) taking the project over. Erwin reported he had Minix version 1.5.5 running. I was told that Minix runs as a job under QDOS. I was promised a copy of the diffs, but they never materialized. Tim Swenson BTW, Phoebus... the baby. The first one is difficult. After that you get good at ignoring them and the wife.
Re: [ql-users] Linux on the SGC?
Some of you might remember, some years back, when one QLer was able to port Minix to the standard QL, but could not distribute the diffs due to Prentice-Hall saying "No". Andrew Tannenbaum saw no problem with it, but PH did. Now Minix is pretty much forgotten. Tim Swenson
Re: [ql-users] Documentation Project...
At 07:58 PM 1/7/2002 +, you wrote: >In light of the above, there's a couple of practical things I can do to >help the situation. I would like to start a QDOS/SMSQ documentation >project. Dilwyn Jones has a whole bunch of documentation on his web site. Plus, a while back I started the QL PD Documentation Project, where I collected as many files as I could find that talk about QDOS. Some discuss user level stuff, some discuss programming, some discuss system level stuff. It sounds like your aim is mostly at the OS itself. We already have a freeware version of QDOS, called .. QDOS. It's my under understanding that Amstrad (and/or Sinclair) has allowed the distribution of the QL ROM's for things like emulators. This is how QDOS Classic came about. Mark Swift ported QDOS to the Amiga and to the Q40. Some have suggested that this be a starting point for extending the QL OS. A bunch of QDOS extensions (that have pretty much become part of QDOS) are still copyright (like the Pointer Environment, new color drivers, ToolKit II, newer file system drivers). These parts are what makes SMSQ/E different that QDOS. I have not looked at the QDOS Classic code, so I don't know if it is very documented. There was a nice article in Quanta that explains the QDOS Scheduler (in very gross detail). There is also the QDOS book by Pennel that goes into great detail about QDOS (although a little dated). Maybe someone could contact the author and get the book released as freeware. Tim Swenson
Re: [ql-users] UQLX on StrongARM
At 12:24 AM 1/7/2002 +0100, you wrote: > So, expected QDOS behavior is not there. > >you have missed the 'qdos-like' flag, it does exactly that and a bit more. >Use it for filesystems that are intended for QL/UQLX use only, otherwise >you might get some confusion. Indeed I must have. Next time I have Unix box as my workstation, I'll have to give it a try. Right now I get to play with a Linux box, but my workstation is Win2K. Maybe at my next contract. Tim Swenson
Re: [ql-users] A new QL user needs your help :)
At 02:32 PM 1/6/2002 -0200, you wrote: > 4) What shall I use to: > A) wordprocessor > B) spreadsheet (w/ .xls translation or something similar) > C) database (not complex, just for a collection control) Xchange is probably the best program to start with. It includes: Quill - Wordprocessor Abacus - Spreadsheet Easel - Business Graphics (charts) Archive - Database with programming language Xchange allows taskswapping between applications. You can have two documents, a spreadsheet, and a database open all at one time and swap between them. You can find Xchange on any number of QL software pages. See Thierry's page first: http://wwwusers.imaginet.fr/~godefroy/english/main.html > D) mail and navigation (as far as I read here, it is not > possible by now, right?) Quite right, not ready for prime time yet. > E) programming SuperBasic is really a nice language. Going from VB to SuperBasic should be fairly easy. You can find lots of SB resources on the net. See Dilwyn Jone's page or my page for documentation (we're both listed at the above URL). There is a freeware SB compiler called Turbo. It's fairly good. It should be able to handle all that you need for now (plus you can't beat the price). Tim Swenson
Re: [ql-users] UQLX on StrongARM
At 09:20 PM 1/5/2002 +, you wrote: >What is peoples' opinion of UQLX? uQLx is a free emulator on a free OS. It works fairly well. You do need to provide you own copy of TKII, to get it really working well (I feel TKII is essential on the QL). I find that using the QDOS filesystem on top of the Unix filesystem to be a problem. In QDOS, 'FILE.txt' and 'file.txt' are the same. Under uQLx they are not, as the underlying fs is Unix where they are not the same. So, expected QDOS behavior is not there. I'd like to see uQLx expand and continue to become more like QDOS. If/when I get a Linux box for home, I'll install uQLx on it. I was using uQLx on my Indy workstation when I worked at SGI. Tim Swenson
Re: [ql-users] The reality... and other things
First, let me say that I'll be briefer than Nasta in my comments. I see the whole QL/QDOS/SMSQ/E really comes down to hardware. Software really does not break, but eventually, hardware will. Granted my original QL (bought in 1986) is still working, eventually it will have some sort of hardware problem. There are two approaches to solving this hardware problem: 1 - QDOS-native hardware (like Q40) 2 - Other hardware with emulation (like QPC or uQLx) Approach 1 is better and more efficient, but it can be costly and hard to implement. Approach 2 is less efficient, but it can be cheaper and easier to do. The future of the QL world should be in the coordination of both approaches. I'd like to see a time when SMSQ/E will run exactly the same, no matter the platform it's running on. I'd like to see color drivers on the Q40, QPC, and uQLx to behave the same (same modes work the same way). Storage on HD can differ from platform, but how they read floppies and CD's should all be the same. Access to networking should be the same. Sitting a user down to either one of these systems, they should not be able to see a difference. The approach each QL user will depend on what they like. Personally, I like to run in a "pure" QL world and I bought a Q40. When I feel like I have some extra cash, I might buy QPC. I'd like to see the Q40 become the standard hardware solution for the future. It has a lot of potential and it's already done. I'd like to see both QPC and uQLx move closer in how the behave and move toward emulating how the Q40 behaves. Granted uQLx depends more on QDOS than SMSQ/E, but getting SMSQ/E to be Open Source is another rant. We can all sit around and talk about the future and they way it should go, but actually making it happen takes work. I commend developers of the Q40, QPC, and uQLx. They put actions behind their words. As a great procrastinator, I appreciate how much effort goes into taking an idea and turning it into a reality. I'm not trying to step on anybody's toes. If somebody else want's to design more QL hardware, for what ever reason, I would not try to stop them, I'm must expressing my opinion. In an example of how not to do it, I'm spending my days playing with both Linux and IRIX systems. Even though they are both Unix systems, I have to translate the differences of where configuration files are ( is that /etc/inetd.d or /etc/xinetd.d). To make matters even worse, different Linux distributions put config files in different places. So a Linux book written about Slackware does not translate 100% to Red Hat or Mandrake or Suse or . (and don't get me started on different Fibre Channel switches and different RAID boxes). As I said, this is all just my opinion. I really does not matter until I actually turn it into action. Tim Swenson
Re: [ql-users] US QL differences...
At 09:00 PM 1/3/2002 +, you wrote: >Hi all, >I've been sat like a hawk on Ebay waiting for a QL to come up for auction. >I recall the US QLs had a different ROM version and PSU, but are their any >other differences? There should be some US QL's running around from US sources. Jack Boatwright in Oregon or John Rish in Texas (listed as Home Electronic Services on Thierry's web site list) should have some or know where to get some. Also, T/SNUG (T/S North American User Group) might know of some folks that have upgraded to say QPC or Q40 and are willing to get rid of their QL. The NESQLUG would also be source. I don't know if I would trust EBAY for a QL. I would trust other QLers. Tim Swenson A US QLer
Re: [ql-users] Why me
At 09:51 AM 12/27/2001 +, you wrote: >I run Linux and W98 side by side 24hr on two machines. Linux needs >rebooting maybe once every two months, and then only because it is >clearly getting short of memory. I bet there is a Linux task I can run >to help that! I've seen this problem of Unix slowly running out of free memory on my SGI Indy workstation running IRIX 6.2. After about 3 months, I would be out of free memory, even while not having any applications running. I attributed it to a very small memory leak. When processes were ended, I figured that not quite all of the memory was freed and over time this small unfreed memory would grow until it took over most memory. A reboot every three months for a workstation is not bad at all. Tim Swenson
Re: [ql-users] Why me
At 08:48 PM 12/24/2001 +, you wrote: >Centrally heated room Tim, no change in temperature only thing that has >happened really is I took the Q40 down to our last sub group meeting but >it has worked fine since then. >I'm beginning to suspect planned obsolesce (;-) I was more referring to Dilwyn's bit with his computer. He mentioned it was in storage. I thought it might have been in a cold garage or attic. Tim Swenson
Re: [ql-users] Why me
In the server world, you always let recently shipped servers come to room temperature before turning them on. They are usually get cold during shipment and firing them up right away could cause thermal stress, so they are allowed to sit a number of hours in the computer room. Your HD might have needed some time to warm up. Tim Swenson
Re: [ql-users] Sources
At 04:32 PM 12/23/2001 +, you wrote: >If you get time then try a visit to Dillions bookshop ... I have found >this in the past to be a treasure of all the latest in computer related >texts. Latest does not necessarily mean good. I find that most modern computer books fall into two categories: 1 - Good thought out volumes on a particular computer program, language, or technology. 2 - Worthless 500 page tome with the nutritional value of sugary breakfast cereal. Most O'Reilly books fall in the first category. They are full of good technical information that is aimed at the programmer or System Administrator. They cover topics like Perl, Apache, DNS, Cisco routers, etc. Most are about an inch thick. I've been buying O'Reilly books for about 11 years and have about 30 so far. The others are these "Java in 24 hours" tomes put out by publishers like Que, that are 3-4 inches think and are pretty much worthless. They are aimed at the new guy to computers and are glitzy enough to catch the attention of the new guy. They seem to think that the greater the word count, the better the book must be. There are probably a few books on the last 10 years that might eventually become classics. There is a web page called "Joel of software" where this guy talks about books and such, but he is mostly talking about User-Interface books. You might fine some good programming books at the local bookstore, but I would aim for a computer speciality book store or an on-line bookstore where the selection will be better. I still say, stick with the classics, they have proven themselves over the years. "Elements of Programming Style" has not change since it's second edition in 1978. Current prices are probably in the $20-$30 range (if not more). I was able to find an older copy at a used bookstore for 80 cents. I did the same with two of three Knuth books. Another way to find out what might be a current classic is to read current programming magazines, like Dr. Dobb's Journal, and see what books they keep refering too. I have not read DDJ is a number of hears (after having a subscription from '88 to '95). Tim Swenson
Re: [ql-users] Sources
Software tools only has two editions, one for Pascal and an earlier one using RATFOR (I think that stands for Rationalized Fortran). Looking at my programming bookshelf, here are some that you might find usefull. "The Elements of Programming Style" Kernighan and Plaugher "Programming Pearls" and "More Programming Pearls" Jon Bently Of course, the Knuth books "Art of Computer Programming", but very detailed. For programming projects, Brooks "Mythical Man Month" is pretty good. These are old classics that have been around for years and had the test of time. I don't know of any newer books that would be considered classics like these. Tim Swenson
[ql-users] TURBO Support Page
To help in tracking current bugs in TURBO and the TURBO Toolkit, I've created a TURBO Support Page on my web page (www.geocities.com/svenqhj/). I only have one bug listed, but I'm ready to list more. This page can be used by TURBO users to see if any bug they encounter has been seen or not and if there is a fix on the way. I'm hoping that it will help triage some bugs before we "bug" George Gwilt about it (pun intended). Tim Swenson
[ql-users] QL Hacker's Journal #34
For those that have been waiting, finally, I have finished QHJ #34 have made it available on my web page (www.geocities.com/svenqhj/). This issue focuses primarily on TURBO and all of the tools that come with it. Boy, have there been a number of distractions this year. Tim Swenson
Re: [ql-users] Turbo Toolkit 3.31
I just downgraded from TTK 3.31 to TTK 3f27 and CHARGE is working again. So, it looks to be an issue with 3.31. Tim Swenson
[ql-users] Turbo Toolkit 3.31
I've got a problem using TTK 3.31 and I wanted to see if anyone else is seeing the problem. First, setup: JSU QL with Gold Card and two ED drives. I've got TURBO on a disk in FLP1_. I type in a program in SuperBasic, then enter the TTK keyword CHARGE. This is supposed to fire up TURBO and compile the program. The error I get is "bad parameter". Now, when ever I type in any keyword I get "bad name". The 'charge' command makes no attempt to look at FLP1_ (in an attempt to load parser_task). I can run parser_task and then codegen_task and get the program compiled. I have not tried going back to an earlier version of TTK, yet. Thanks, Tim Swenson
Re: [ql-users] OT - Community web site
Mug shot is right. I actually pictured you to be a little bit younger (well, OK, a lot younger :-) ). Tim Swenson
Re: [ql-users]What about re-writing QDOS for x86 processors
Overall I think the idea is a good one. An OS really is not tied to the underlying CPU. Linux is a good example of an OS supporting a number of CPUs. A first step might be to convert all of the SMSQ/E assembly code from M68K to x86. Overall it might be better to use more C and leave the low level stuff for assembly. Granted this might cause some code bloat, but it would allow for greater portability. I do think the weakness in the QL world has always been the hardware. It's easy to copy software and keep it around for many years. Hardware is eventually going to break. I doubt that a project like this will get started as a group effort. The only way it will come to pass is if one person take it upon themselves to do most of the work and get a working example (Linux was just like this). Once a working example is done, then others might join. Since the source code to SMSQ/E is not publicly available, maybe a good start would be to take QDOS Classic and port it to x86. This would demonstrate the feasibility of the project. Tim Swenson
Re: [ql-users] Q-Celt Computing News
It's been a while since I cranked up the QL, but I'll give the new binary a try. My Q40 is currently down (blown power supply and HD problems). Luckily my Gold Card QL is still set up and working. Tim Swenson
Re: [ql-users] Q-Celt Computing News
The idea of Viewer supporting hyperlinks, like HTML, is a good idea, esp. of the links can be inside a document. What about creating a CD chock full of QL documentation. I'm sure a lot of QLer's that wrote articles for newsletters would contribute, esp. newsletters that are no longer in print or were written years ago. I'd be willing to help with this. Tim Swenson
[ql-users] Bad to worse Q40.
After letting my Q40 sit for a while (since I am still having the partition problem), I decided to hook up a 400 Meg drive as master (leaving the current master idle) and give that a shot. So, I unplugged the old drive (IDE cable and power), hooked up the spare drive, and turn it on. Have you ever seen lightening indoors? Boy, did the power supply light up and make a funny noise. It looks like the power supply is fried. I doubt a fuse blowing would produce a lot of light, make a an arcing sound, and smell that bad. The power is still being passed to the monitor (it's power was plugged into the computer). I think hardware does not like me. Tim Swenson
Re: [ql-users] Woosh Bang
Whoops, I think "nur" does mean "only" and not "not". Tim
Re: [ql-users] Woosh Bang
By German is rusty, but I think "nur fur benzine" means "not for benzine". I'm guessing that benzine in German is the same as benzine in english. Hope this helps. Tim
Re: [ql-users] Virus
At 08:25 PM 8/5/2001 +0100, you wrote: > >The best solution I reckon is for originating ISPs to filter emails >with > >attachments for virii. > >Mind you we are then getting into privacy issues. Since virus scanners only look at files at the binary level (comparing binary sequences to known virii), there really is not a privacy issue. I don't know about NT boxes, but it would be fairly simple to have SendMail pass off mail to a virus filter. Tim Swenson
Re: [ql-users] qxltool and multipartitions
Now, after I formatted parition 1 I was able to reboot from linux to SMSQ/E and copy some files from flp1_ to win1_. Now I did a reboot to verify that the boot file will run and suddenly I can't see win1_. I set win_drive 1,0,0 and nothing. I set win_drive to 2,0,1 and I see the second partition (QDOS2). Any ideas why I'm losing the first partition? I even disconnected the Syquest to make sure it was not interfering. Sigh. Tim
Re: [ql-users] qxltool and multipartitions
I'm still having problems with the Syquest and it keeping a partition. I also found that copying from the Syquest to win1_ caused win1_ to be corrupted. I'm also starting to wonder about the Q40 manual. I formatted HD like this Partition 1 (/dev/hda1) QWA QDOS1 Partition 2 (/dev/hda2) QWA QDOS2 Partition 3 (/dev/hda3) SWP Partition 4 (/dev/hda4) LNX When the system first boots up, it has WIN_DRIVE$(1) set to 0,0,0. This should be the whole disk on the master on the primary bus. When I do a "stat win1_" it shows it as being QDOS1. I was worried about win1_ referring to the whole disk, so I did WIN_DRIVE 1,0,1 (first partition on the master disk on the primary bus). When I do a "stat win1_" it now shows QDOS2. So, it looks like the 0 does not refer to the whole disk, but to the first partition, and the 1 refers to the second partition. Anybody else discover this? Tim Swenson
Re: [ql-users] qxltool and multipartitions
I booted Linux from floppy and it looks like /dev/hda4 is still there (mounted it as /newroot). So I booted again from floppy and used /dev/hda4 as the root device and all seems well. Another thing is that the Syquest drive not makes a funny noise after I put a disk in, then it spits the disk out. Can computer hardware be cursed? Tim Swenson
Re: [ql-users] qxltool and multipartitions
At 12:07 AM 7/12/2001 +0100, you wrote: >You are missing a bit. >after the >WIN_FORMAT 3 >you should then type >Format win3_ >the first command allows the drive to be formatted but does nothing else. >This is a protection against accidental formatting. Long winded but worthwhile. I think I get it. The impression that I got from the manual is that WIN_FORMAT 1 turned on formatting overall, and WIN_FORMAT 0 turned it off (in other words, setting a flag). What I'm getting from you is that to format win3_ I have to say win_format 3 to turn formatting on for device 3. In the manual it says "WIN_FORMAT 1- Allows WIN drives to be formatted" and "WIN_FORMAT 0 - Prevent WIN drives from being formatted" So, do we need a better manual? I'll try what you suggest and see if it works. It would explain the "access denied" error. But in mucking with my system, I seem to have totally blown all partitions (even Linux). All I did was disconnect the HD and run a bit with just the Syquest attached. Is it OK to run with just a Slave IDE device and no master? This was all last night and today I've been too bummed out to try anything. Tim Swenson
Re: [ql-users] qxltool and multipartitions
Ok, I am now able to read the Syquest as win3_. I dumped some files there and I am able to boot into Linux. From there I put partitions on a number of Syquest carts. I also formatted my first and second QDOS partitions "qxltool /dev/hda1 0 QDOS1" and "qxltool /dev/hda2 0 QDOS2". I did get some "unknown error ###". I rebooted into SMSQ/E and I now have a win1_. I tried to access win2_, but had no luck. I then tried to format a Syquest disk and got "access denied". I wonder if this has something to do with having a win1_ now, where as before (when it worked), I did not have an active win1_. Something to ponder on. Tim Swenson
Re: [ql-users] qxltool and multipartitions
Well, this is interesting. With SMSQ/E 2.91 running (from ROM), I decided to try and format the Syquest again (just for S&G's). I did the following (as per the manual): win_format 1 win_drive 3,1 format win3_ instead of getting the "access denied" error, it asked for two letters and then formated it just fine. (52428 sectors, which seems a little small). So, is there a difference between 2.91 and 2.98beta in how it handles HD's? Tim Swenson
Re: [ql-users] qxltool and multipartitions
At 12:10 AM 7/11/2001 +0200, Richard Z. wrote: >I have reformated my /dev/hda2 today with > qxltool -W /dev/hda2 0 xx xx xx >and it worked perfectly. I tried it using 256 instead of the 0 (since it's 256 MB partition). That should still work though, right? Tim
Re: [ql-users] qxltool and multipartitions
At 11:17 PM 7/10/2001 +0100, you wrote: >Hi > >You need to give the WIN_FORMAT command as: WIN_FORMAT win_drive, that is >for WIN4_ WIN_FORMAT 4 The manual says "WIN_FORMAT 1" to allow HD's to be formatted (doing this did not format my win1_ drive). It then says "WIN_FORMAT 0" to disallow HD's to be formatted (which gives an error). Now you are saying WIN_FORMAT X will format drive X. So to format the Syquest I would have to do the following: WIN_DRIVE 3,1 (Set win3_ to the slave drive on the primary bus) WIN_FORMAT 3 (to format the drive) I just tried that (with SMSQ/E 2.91 in ROM) and it did not work. So, it looks like the manual is correct. Tim Swenson
[ql-users] qxltool and multipartitions
After my adventure with the Syquest drive, I thought I would use qxltool and see if I could get my second QWA partition working. I figured I would use qxltool to format the second partition and then see if I can accesses it. I have 4 partitions: 1 QWA256 Meg 2 QWA256 Meg 3 SWP128 Meg 4 LNX rest of 6GB drive I used qxl in the following way: qxltool -W /dev/hda2 256 Label It seemed to be working fine until it showed 105% formatted. I stopped it at about 120%. I rebooted to SMSQ/E and found that I no longer have a win1_ drive (nor a win2_ etc.). Did I do something wrong? Why did qxltool even touch the first partition? Now the problem is how to get everything back to where it was. Has the FORMAT command been fixed? I remember when I first got the Q40, FORMAT would totally ignore any partitions and format the entire drive. Since I still have a LNX partition, I don't want to experiment and found out it's still broken. So, what I first have to do is to load Linux off of floppy, mount the LNX partition, then run qxltool to format the first two partitions (I hope it works), and then restore off of floppy (if SMSQ/E can find the disk). I'm looking for a little advice from folks that might have been in the same position. I'd also like to know the state of the existing tools we have for working with hard drives. I've had very bad luck with SMSQ/E and HD's, including the Syquest issue (I've followed instructions out of the Q40 manual for formatting the Syquest drive and I get errors. WIN_FORMAT 0 gives "invalid parameter" error.). Sigh... Tim Swenson
Re: [ql-users] Syquest and Q40 question
Richard Z. suggesting using atari-fdisk and qxltool to get the Syquest up and running. I used atari-fdisk to partition the drive (1 partition). I used qxltool to format the disk. I first tried something like this: qxltool -W /dev/hdb1 0 label This got an error during format (unknown error 1771094350). So, I used 127 instead of 0. I then had to run the fix-geometry command in qxltool to get that set (32/16). When I try to access the disk in SMSQ/E, it does not see it. I set WIN_DRIVE 3,1,0. Using the WIN_DRIVE$ command I get 1,0,1 (which is correct). But when I copy a file from win1_ to win3_, it shows up on win1_ as "win1_win3_.". Anybody have any ideas? Now for my other adventure (see next message). Tim Swenson
Re: [ql-users] Syquest and Q40 question
Ok, before I do something stupid and accidently format my main HD, can someone refresh me on getting a second HD going on the Q40. I know to use MKPART_EXE, but I'm worried that it will default to the main drive and not the secondary drive and then there goes my data. I also remember that the manual that came with the Q40 was not quite right on the WIN_DRIVE command or something like that. BTW, I found that I had to pull out the CD to get the Syquest to fit. Since the HD is at the bottom of the drive holder (just under the floppies) and the Syquest was at the top (just over the CD), the IDE cable was not long enough to reach both. No big deal as it's a 3 minute swap job (I never put the screws on the case). Thanks, Tim Swenson
Re: [ql-users] Syquest and Q40 question
At 09:06 PM 7/9/2001 +0200, Peter Graf wrote: >BTW I am successfully using CompactFlash as removable media for Q40/Q60. >Seems a very nice thing! Smaller than a QL microdrive cartridge, silent, >portable, and works under Q40 SMSQ/E and QDOS Classic *without* new drivers! > >I use a special PCMCIA/CompactFlash-IDE adaptor. But attention, not >all CompactFlash-IDE adaptors work. There are also differences >between CompactFlash cards. This needs further investigation. > >CompactFlash has the disadvantage not to be well-suited for hot-plugging. >You have to switch off your machine when you change media. Fortunately the >Q40/Q60 boots quite fast... and needs no shutdown under SMSQ/QDOS. How about letting us know exactly which model adapter you are using? Are there any that you have tested that have failed? I'd like to see a web page the covers all of the different hardware that people have tried on the Q40. If we know exactly which ones work and which ones fail, I'd be more willing to go further with the Q40 than just relying on blind luck. I don't want to spend a week going to Fry's trying all sorts of cards seeing which ones work or not. BTW, I CompactFlash (aka Digital film) on the PC. The driver on the PC does not require a reboot when changing CompactFlash cards. It senses when a new one is put in or one is taken out. I'm using a little USB-based adapter called Jump Shot made by Lexar (same folks that make the CompactFlash cards). The CompactFlash card is viewable from inside "My Computer" but it does not have a drive letter assigned to it. I'm guessing the Adapter that Peter is using makes the CompactFlash look just like a HD or floppy. Tim Swenson
[ql-users] Syquest and Q40 question
I want to bounce an idea off the collective. I just picked up a Syquest EZ-Flyer 230 (EIDE) with about a dozen disks. I've already got two IDE devices on my Q40 (HD and CDROM). I'm thinking about putting in the Syquest in the Q40 and only hooking it up when I needed it (mostly for backup). Essentially I would turn the Q40 off, crack the case, switch the power and IDE cable from the CDROM to the Syquest, turn on the Q40 and go about using the Syquest. I'd reverse the procedure to get the CDROM back. Does this sound like a good idea? Has anybody tried the Syquest on the Q40? BTW, I got the Syquest free, so if I can't use it on the Q40, no problem. A friend of mine is moving from an apartment in San Francisco to an RV (where he'll travel and find jobs in different towns). He was giving most of the stuff in his apartment to friends. Besides the Syquest I got a boat-load of 80's records. I know if I kept him as a friend for the past 20 years it would pay off :-). Tim Swenson
Re: [ql-users] QLIB externals and SMSQ
Since I've got my Q40 and my GoldCard QL sitting next to each other, I can quickly run some tests on what works and does not work between the two. Can you give a short example that I can quickly compile on both systems? I think my Qlib is like yours, 3.32, which I think is the latest (and has been the latest for a number of years). Tim Swenson
Re: [ql-users] Test
At 10:23 PM 7/4/2001 +0100, you wrote: >Just think of it as "nobody has any problems to raise"... >(i.e. be positive) For me it's just been too hot to play with the QL. Last few days have been 97, 100, and today it's only about 91. Of course, since it's the 4th, I get to sweat over a Bar-B-Q. Tim Swenson
Re: [ql-users] Re: Q40/Q60 device drivers
At 01:12 PM 6/28/2001 -0400, Nasta wrote: >Let me give you an example. Suppose someone implemented SCSI on the Q40. >Then, you could connect an IDE and a SCSI hard disc to it. Boh would use >the QWA file system, but here is the problem: each device would have it's >own copy of the QWA handling code. If there was a CD connected to either >(and here we would already be circumventing another driver that works on >the same hardware), with a QXL.WIN on it, then the CD driver would also >need it's own copy of the QWA handling code. And, there would be no way to >make one be win1_ the other win2_ and the QXL.WIN on the CD be a win3_, >although they logically should be. It could be done, if they were all set >to _USE another name, then some sort of DEV_USE would be used to make them >dev1,2,3, and then a DEV_USE win would make them win 1,2,3. Total number of >QWA copies: 3. Total number of directory devices used: 4. If you think >about it, only one copy of the QWA handler code and only one device driver >would really be needed. Now, I'm not an expert in XFS (the IRIX file system), but I spent enough time listening to the experts talking about it so that I know a little about it. With XFS, the file system is separated from the physical device by a virtual file system (vfs). In other words, an XFS inode, points to a vfs inode, which points to a physical device sector. This way XFS can work across hard drives and CD's. This also allows for a volume manager (XLV) to come into play, and step in between XFS and the VFS. XLV allows striping and disk mirroring. With SCSI pretty much being the only way to hook up disks and tapes, the SCSI controller one the one point where every call has to go through and the controller could handle multiple conversations (sort of timeshared as the SCSI protocol only allows one conversation at a time). Something like this could be implemented in SMSQ/E, but it would take a concerted effort. The XFS team had about 5-8 people at any one time. With SMSQ/E we just have TT. Tim Swenson
RE: [ql-users] Re: Q40/Q60 device drivers
At 08:38 AM 6/29/2001 +0100, Norman wrote: >Just to take off at a tangent, how about an open source (type) project to >build a new Operating System for ALL the QLs/compatibles/emulators out thare >to use. An interesting idea, Norman. There are some pluses and some minuses: + Good way to expand our knowledge of QDOS + Possible way to get additional features - More fractionalizing of QDOS community (QDOS, Minerva, SMSQ, etc.) If this was to go forward, there are two ways to go: - QDOS Classic (should be able to use in North America) - Minerva (if ever publicly released) An organization similar to what Linux is using could be setup to keep the project running smoothly. We do have a number of experts (outside of Tony Tebby) that might be willing to contribute to the project. I'd be willing to help on the documentation side (so that I could learn QDOS better). There might need to be some work to replace some commercial parts of QDOS that have become integrated in QDOS (PE), or some arrangement worked out, or an assumption that they will stay commercial. Anyone willing to step up and play project leader? Tim Swenson
Re: [ql-users] Re: Q40/Q60 device drivers
At 10:13 PM 6/27/2001 -0400, Nasta wrote: >SCSI is another related example. A SCSI host adapter does nothing of >itself, but may have many different devices connected to it, that all >require treatment by essentially different drivers. Just to expand on what Nasta said, different drivers (such as disk or tape) utilize the SCSI controller to talk with their respective devices. The controller is opened as a device and just handles the SCSI conversation between the devices and their drivers. I've done some SCSI Bus trace analysis so I'm familiar with how the protocol works. I wrote an article for Sys Admin mag on the subject if anyone wants to know more. Tim Swenson
Re: [ql-users] Digital Precision Collection
At 12:02 AM 6/28/2001 -0500, you wrote: >Maybe Simon (N) Goodwin or Chas Dillon can shed some light into this? They should know the status. I believe that most of the programs had a time clause to them and are now owned by the original authors. Now the problem might be tracking down the authors, or they could be considered abandonware. There's been a lot of discussion about abandonware on comp.sys.sinclair, dealing with old spectrum games. Remember, copyright infringement is only illegal if the copyright owner sues you. A city or government can't sue on behalf of the copyright owner. So, you take your chances. Tim Swenson
