Re: [ql-users] Source Code Status
On Mon, 25 Mar 2002 06:39:27 +0100, [EMAIL PROTECTED] wrote: Hi all, Following the discussions at EIndhoven,here is what has been agreed upon, Tony TEBBY also having agreed to it: In short: In short this is GREAT NEWS ! :-)) Finally, I would like to add a personal note: A - Some passages of the above, mainly those which result in a limited distribution of SMSQ/E may loook pretty harsh to some of you, especially the proponents of totally open software. Open software is not an aim it itself. I see the openning of the SMSQ/E sources as the key survival of this wonderful OS, the fact that some restrictions (particularly style related ones) are put on it is, as far as I am concerned, a GOOD THING ! However, I consider that there are a few people (like JMS and Qbranch) who are the glue that hold the QL world still together. If they have absolutely no financial incentive to continue, they probably won't. In my opinion, the effect on the QL World could be disastrous. There are also some other people, like Marcel Kilgus, who have put an enormous effort into SMSQ/E, and would like their efforts to be retibuted in some way. Others, such as Peter Graf, have invested much of their time and money to design hardware which is still being built and sold - if no coherent verson of SMSQ/E exists, then the effect on sales could also be disastrous. The above all implies that some incentive exists for people to a) maintain an offical registration b) pour more time into developments beneficial to all versions of SMSQ/E c) BUY the official distribution, to have something coherent and supported. This incentive can only result, in such a small world as ours, from some restriction on the copyright. I HOPE you can agree with this. 100% agreed ! B - I have been appointed as the registrar (more by default than anything else). I will try to fulfil that role as well as possible. As I have already stated in this list, my main aim is to make sure that we have coherent versions for all machines. There will always be locomotives, i.e. people doing something new for one version of SMSQ/E, which will then also be applied, hardware permitting, to other versions. However, I can not do that work (alone). I NEED the help of some of you (who will be key developers for one machine) so that they can implement the necessary changes (if any) for each specific machine. Thus I make a PLEA for volunteers. Obviously, for SMSQ/E running on QPC, Marcel KILGUS will be the key developer. For SMSQ/E on Q60/Q40, the obvious persons would be Claus and Peter GRAF (yes, I know, I'm trying to twist your arm here, Claus and Peter :-) and perhaps also Jerôme GRIMBERT (?)). You can add me to this list. :-) What about the other machines? Anybody out there interested: QXL (Thierry Godefroy?) Why not ? Although my programming efforts will be mainly turned towards the Q60, now... Aurora ? SuperGoldCard ? I got Aurora+SGC, so here again, I could help... Thanks, Wolf, Jochen, Roy and of course TT for making this dream come true ! QDOS/SMS forever ! Thierry. PS: I'm overly busy right now, so I can't really participate to the discussions, but I will keep reading eagerly this thread and will only react in case I disagree on some point... To those who are wondering: I just can't updates my websites right now, I will do it ASAP (i.e. probably in two or three months !)...
Re: [ql-users] Q60
On Thu, 7 Mar 2002 20:17:32 +0100, Claus Graf wrote: Hi Fabrizio, I was also disappointed to see Thierry's free.fr sites down. This is a problem with my ISP, I don't know why but all my web sites are currently unavailable on free.fr. I sent email to the support about 1à days ago and I'm still waiting for a reply... I guess one of their server upgrade went wrong... Thierry.
Re: Fw: [ql-users] ISO-9660 CD-ROM file utility
On Tue, 15 Jan 2002 05:54:13 -0800 (PST), Fabrizio Diversi wrote: Thierry , I tried it immediately but without success for the moment , but i do not why. The program start without error, the CD run , but nothing appear on the screen also if the program run in the background. (the command jobs show it) To be honest i spent on it very few time and now i am away from home and i have with me only qpc. I will try again next week end. In its documentation, Duncan says that some PC magazines CDs could not be read: this is perhaps because they are not _pure_ ISO-9660 (i.e. they got Joliet or Rockridge extensions). This is just a guess as I can't test the program here and do not have time to give a close look to QCDEZE source... QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Fw: [ql-users] ISO-9660 CD-ROM file utility
Hi ! I'm afraid my last message about the new QCDEZE utility got unoticed among all the heavy trafic (over 400 messages in 2002 (i.e. in 15 days) already in ql-users, wow !) the list is experimenting now... Did anyone tried it ? Any feedback ? QDOS/SMS forever ! Thierry. Begin forwarded message: Date: Mon, 14 Jan 2002 06:23:01 +0100 From: Thierry Godefroy [EMAIL PROTECTED] To: ql-users [EMAIL PROTECTED] Subject: [ql-users] ISO-9660 CD-ROM file utility Hi happy QLers ! Duncan Neithercut just sent me a utility that for sure will be GREATLY appreciated by Q40/Q60 and SGC+Qubide users ! It's name is QCDEZE and it is to be used as a front-end to my CDROM device driver. It is PE driven and allows you to browse, copy and execute (via FileInfo II) files present on an ISO-9660 CD-R(OM/W). I could not test it myself as my Q60 is in France ;-( but it apparently makes use of the proper methods to take the largest benefits from the existing CDROM driver features (it must be very fast when compared to qxltools for example). QCDEZE is available from the QDOS/SMS repository at: http://smsq.free.fr/#DISK Note that Duncan did also update its CSB (Clip Scrap Board, now at v2.18) utility: it now works on almost all QL-compatible systems and should cope with any screen resolutions (available into the generic utilities section of the repository). Congratulations and a big thanks to Duncan ! QDOS/SMS forever ! Thierry.
Re: [ql-users] Progs.be FTP links
On Thu, 10 Jan 2002 11:35:41 -0500, Phoebus R. Dokos wrote: Joachim, I tried to download the ProWesS S*Basic interface docs and the ftp site you reference on your link is not working (ftp.triathlon98.com) The same goes for ftp.progs.be Is there any other way we can get the files? Yes, from the QDOS/SMS software repository: http://smsq.free.fr/#OS Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Progs.be FTP links
On Thu, 10 Jan 2002 13:50:45 -0500, Phoebus R. Dokos wrote: At 06:33 ìì 10/1/2002 +0100, you wrote: On Thu, 10 Jan 2002 11:35:41 -0500, Phoebus R. Dokos wrote: .../... Is there any other way we can get the files? Yes, from the QDOS/SMS software repository: http://smsq.free.fr/#OS Thanks Thierry :-) Actually I just found out since I did a search on my harddrive and found it there (Area 11)... I dowloaded the whole archive last night for use locally and save everyone some bandwidth :-) Wow ! You must have a DSL link ! Phoebus P.S. I don't know how they do it in Free.fr but your whole archive was downloaded in under 15 mins. Dilwyn's site (in order to update the mirror) takes me more than 1/2 hour! Yes, free.fr is EXCELLENT (and I am pretty demanding on the ISP quality); the only grief I got against them is that they do not allow you to setup a telnet (or ssh) account on their servers (therefore I cannot transfer a my sites contents directly from their server to another: I must re-upload everything on the other server...). Thierry.
Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
On Wed, 9 Jan 2002 00:21:20 +0100, Richard Zidlicky wrote: On Tue, Jan 08, 2002 at 01:38:48PM +0100, Thierry Godefroy wrote: maximum name length (including directory path) 36 chars I already explained on this list how to circumvent this problem under SMSQ/E. In fact, with my trick, you can use up to 32765 characters (QDOS string limit) per path+filename. This should hopefully be enough, even in a far future... ;-) agreed, and I will patch QDOS and Minerva to allow for this trick. Beware, that I did not told everything about my trick (because the message was already too long for my taste ;-) You must also ensure that a new open call on an already open file DOES NOT reuse the existing channel definition block (something the IOSS does auto- matically): this can easily be done by putting random characters as the last (say the last 4) characters of the truncated filename (the one which will get passed to the IOSS during directory device driver scanning)... it seems that your idea is a bit different than mine. If you use the non-dir device driver interface than you don't have any filename in the cdb and IOSS will never touch it except for the first 14 bytes. It will neither reuse anything and the filesystem driver will be left completely unsupported with all the work like recognising files already open - which may be a good thing in the end. I don't use the non-directory device driver IOT implement the CDROM device driver (which will indeed be a legal SMSQ/E directory device driver): I use a FAKE non-directory device driver so to intercept the long filename, store its address in a safe place for later use by the actual directory device driver (here, the CDROM one), and then replace it (changing the address passed by and back to the IOSS in A0) by a truncated filename; once this is done the fake device driver reports a failure to recognize his device (in fact it got no device name at all) and then the IOSS scanning for the proper device driver may continue with the truncated filename... As a result a directory device driver channel definition block WILL be setup (with the truncated filename in it, thus the need for the random characters at the end of it)... Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Euroconverter 1.40
On Tue, 8 Jan 2002 19:37:01 + (GMT), Dexter wrote: On Tue, 8 Jan 2002, Thierry Godefroy wrote: It is on the Italian club website (link on my Web site page), as well as in the new QDOS/SMS systems software repository: http://smsq.free.fr/ I downloaded the zipped JSROM disassembly, but winzip claimed it had a bad CRC so I couldn't open it. Could someone else check it? Yes, alas the original zip file I got is corrupted (the basic3_asm file is damaged), but nevertheless you may unzip everything (just use the plain unzip). Also, Thierry, if you'd like a US mirror, let me know. The problem with a mirror is that I would have to upload everything again (and with a 56K modem this still has some cost you know...). Moreover I think that my provider (free.fr) got a very good bandwidth (including to US). If you encounter problem, let me know, I will then perhaps reconsider your kind proposal. :-) QDOS/SMS forever ! Thierry.
Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
On Mon, 7 Jan 2002 00:40:01 +0100, Richard Zidlicky wrote: On Sun, Jan 06, 2002 at 07:32:14AM +0100, Thierry Godefroy wrote: the problems are QDOS specific: - drivers can be practically written only in assembler, True, but as far as I am concerned (I don't want to restart the assembler vs C flame war), this is not a problem but a GOOD THING ! may be a good thing for you but not everyone is good enough with assembler to write more complex pieces of software in it and hardware drivers are the worst nightmare to debug if something doesn't work. Realistically we would probably have a few more drivers if it was possible to write them eg in 'c' or even SBasic. It looks like the Assembler vs C war is about to break out again... just kidding ! ;-) Well, nothing prevents you to write device drivers in C for QDOS/SMS (this will be somewhat tricky because of the limitations on stack space usage but a possible solution is to use static variables), but you will have to do some assembler written glue code (typically putting registers contents on the stack before calling the C routine and extracting the returned parameters from the stack on return) and the result will be very inefficient drivers... As of SBASIC, you will probably appreciate that I did the very first ATA/ATAPI protocol testing with SBASIC written routines. ;-) .../... As an example, for the ATAPI thing and the CDROM device driver, most of the development time was spent searching, printing, reading and under- standing the ATA, ATAPI and ISO specs (nothing less than 10Mb of PDF files...). The actual implementation of ATA/ATAPI took about 40% of the total time... why did you bother with the broken standard if HW vendors obviously don't read it ;) Yes indeed, they apparently did not read the standards (or at least they interpreted them the wrong way) ! There are actually some workarounds that had to be implemented to cope with some broken implementations of the protocol (and I'm pretty sure that we will find even new problems with other broken CD-ROM readers while the user base will grow...). ;-( .../... To be fair, all QDOS/SMSQ filesystems are long overdue to be scraped. To be fair, do you know of a filesystem in _any_ 20 years old OS (QDOS is already 19 years old !) that did not or should not get scraped ? The mass media just evolved too fast and too hugely for anyone to guess right what the filesystems limitations had to be in first place... absolutely agreed, although there are notbale exceptions of filesystems older 20 years which arent completely obsolete most are. Doesn't change the situation though, there is not a single QDOS filesystem that is worth to be reused. This is why I don't intend to reuse any... There are jewels like maximum 65535 files per drive, This is driver specific, there is no such limitation into QDOS/SMS OS itself, as an example, the maximum file per drive (I suppose you are talking about the 16 bits File Id into the files channel definition block) will be 4 billion (32 bits) for the CDROM device driver. there are many places where this and similar limits are implicitly hardwired into SMSQ. Nothing that could not be cured with a whole new filesystem design. Exactly but what I want to point out is that these limitations may all be circumvented in SMSQ/E. The fact that the current SMSQ/E filesystems are outdated in many aspects does NOT prevent anyone to implement new, up to date filesystems, and I am going to prove this with the CDROM device driver ! maximum name length (including directory path) 36 chars I already explained on this list how to circumvent this problem under SMSQ/E. In fact, with my trick, you can use up to 32765 characters (QDOS string limit) per path+filename. This should hopefully be enough, even in a far future... ;-) agreed, and I will patch QDOS and Minerva to allow for this trick. Beware, that I did not told everything about my trick (because the message was already too long for my taste ;-) You must also ensure that a new open call on an already open file DOES NOT reuse the existing channel definition block (something the IOSS does auto- matically): this can easily be done by putting random characters as the last (say the last 4) characters of the truncated filename (the one which will get passed to the IOSS during directory device driver scanning)... .../... If you are making allusion to the file naming conventions (such as the directory separator which is _ in current QDOS/SMS filesystems), they are just that: conventions ! The CDROM device driver will accept both / (natively) and _ (for backward compatibility) separators... _ is still a problem when the rules whether it can be part of filenames are rather complicated. Complicated but possible (I already got a few different algorithms in mind to solve this issue, the problem will be to find the fastest one). Let's
Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
On Tue, 08 Jan 2002 10:36:08 -0500, Phoebus R. Dokos wrote: Just my two cents (and pardon my cluelesness in many parts) Just got the QDOS/SMS reference manual and begun (thanks partly to the work of Norman with assembler and the good contributions of every savant one in the list) to understand roughly a little more on how SMS works. Based to all Thierry did with the ATAPI drivers The ATAPI thing is only responsible for the ATA/ATAPI protocol layer, it does not implement anything directly related with filesystems; it is only responsible for sending and receiving ATAPI packets (as well as a few ATA commands) to the ATAPI-compatible devices on the ATA-IDE interface (either the ISA I/O board of the Q40/Q60 or the Qubide board of SGC-based systems). BTW you may use it from either assembler, SBASIC or even C (I will also write a small C library for it)... OTOH, the CDROM thing (which is still in embryonic state for now) is responsible for the standard SMSQ/E filesystem API implementation (the TRAPs #2 and #3), provides support for reading data from a CD-R (on a direct access basis), and _will_ provide full facility to plug filesystem support modules in it (ISO-9660 and its extensions, namely Joliet and Rockridge, as well as packet-CD filesystem): I will probably write the ISO-9660 pluggin myself as well (and then perhaps another programmer will follow my steps and implement other extensions/filesystems pluggins)... wouldnt it be possible to go a similar way (and by reusing as much of Thierry's code - no use of reinventing the wheel!) and provide an interface for ALL devices under SMS? The way I think about it if a Device Driver API (along the lines of the Meta devices proposed by Nasta) was implemented as a thing it would be possible to trap all IOSS functions and translate them to something a device would understand and vice versa. What could be done under SMSQ/E is something similar to QVFS (which was written by Hans Peter Recktenwald) but that would use all the standard SMSQ/E TRAPs (QVFS did not, by design and because it was to run on QDOS as well: the DELETE system call could therefore not be implemented and had to be supported by a special TRAP #3 call). Using things and a more memory based approach (for example QVFS was using a file to define the mount points: IMO this should be held in memory and (un)mounts should occur via an extension thing call), this could give you support for UNIX naming conventions on all filesystems (including old ones), with long filenames support (as well as soft links) while preserving the backward compatibility with software using the QDOS file naming convetions (i.e. it would still be possible to access the QDOS filesystems directly). Note that there is no need to change the API (TRAPs) to obtain this dual compatibility... This is one of the projects I have but I never found the time to implement... Note that I did _think_ a lot about it though and got most of the solutions to the problems such a thing/device driver raises. See also the old discussion we had in this list with Richard about non- blocking TRAP #2 calls... This API (?) Thing could be linked as a module to SMSQ/E No need for this, it could just be loaded at boot time as any thing/device driver. Its actual (de)activation could be made via an extension thing call (i.e. a standard extension thing call in assembler, a new keyword in SBASIC, a new library function in C, etc...). together with a UN*X-like filesystem driver written for it In fact it would INCLUDE the UNIX to QDOS file naming translation... no need for a new UNIX filesystem. and provide at the same time the much needed fs update and a method of adding devices logically (I find that the UN*X like approach of devices being part of the filesystem extremely useful). Yes, see the mount discussion above... Note that even newer device drivers/filesystem (such as the future CDROM/ISO9660 one) which already understand the UNIX naming convention could still be mounted (with a do not translate flag)... Additionally it could standarise device driver creation by setting a uniform all-encompassing standard for device driver writing. This is another story !!!... and another thing (in fact a vector collection to be glued into an extension thing) to write ! QDOS/SMS forever ! Thierry.
Re: [ql-users] Euroconverter 1.40
On Tue, 8 Jan 2002 18:02:09 +0100, Wolfgang Lenerz wrote: On 7 Jan 2002, at 17:38, Andrea Carpi wrote: Euro converter Darn, I've just erased the originalmessage with the link the the website. Would you lmind letting me have it again, so I can download the software? It is on the Italian club website (link on my Web site page), as well as in the new QDOS/SMS systems software repository: http://smsq.free.fr/ QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] seasonal cheer, Silly Season
On Mon, 7 Jan 2002 08:51:16 +, Tony Firshman wrote: On Mon, 7 Jan 2002 at 08:23:12, Norman Dunbar wrote: I use QPC2v2 on Win2K at work and on Win98 at home. I have the system installed on a 100Mb Zip disc which I take back and forth with me so I have the same setup at home and at work. Well, that's the theory, at work the zip is win1_ and at home it is win2_ and I even remember to backup my home Win1 to Win2 occasionally. The problem is when I have done stuff at work and forgotten to synchronise with win1 at home and then 'update' my zip from the 'real' win1 at home hence losing all the stuff I did at work. I wouldn't be difficult to write a program to synchronise automatically. This programs already exists ! It's called TGBack and is available from the QDOS/SMS software repository ( http://smsq.free.fr/#DISK ). Example of use for the particular purpose of Norman's needs: EX TGBack_exe;-from win1 -to win2 /m /s Note that TGBack may also run unattented, e.g. from a boot file or in conjunction with minicron (MiniCron109.zip in the repository). I think that is one of the major failings of QDOS/SMSQ - that date stamps are transitory at the O/S level. TGBack does preserve files date stamp. QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Future of QL - The continuing Saga... Part 9.8E13 ;-)
On Sun, 06 Jan 2002 16:40:03 +0100, Peter Graf wrote: Hi Thierry, The old debate should software be designed before hardware ? is a nonsense to me I didn't mean to say that software should be designed before hardware. No, but as I wrote, this is an old debate (GoldFire etc..). Please, don't take it (nor what follows) as an attack against you, my only aim is to bring some constructive thinking to the debate. When I designed the Q40/Q60, there was no software at all!!! For me, there are two software-related conditions, before I implement any QL hardware: 1. I must see a (reasonable) chance QL software will use it later on. This is the difficult part: how to see... and how to see right ! The only thing I regret about most QL (in the largest meaning of the QL term) hardware is that there is generally no consultation between the hardware designer and the software writers. This was the case for the QXL (TT had to make up for its poor PC I/F design by accrobatic and processing power consuming routines), as well as for Aurora (there, it looks like someone took for granted that once Aurora would be available, TT would write the screen drivers for free, the result is: no enhanced screen driver for Aurora !). Note that this is not always the case (Nasta did publish the GoldFire specs and asked for advices), but this is _generally_ the case... What I would really love to see are open specs of hardware before it is actually prototyped, so that software writers have a chance to spot the potential programming difficulties/limitations and warn the designer about them before it is too late... In a small and shrinking communities like ours, we just can't waste human ressources, everybody should have a chance to contribute and bring his expertise to the projects. 2. I must be able to write enough software myself to test basic functions of the hardware. This makes sense, but here again you are not alone and may ask for help if needed. Both conditions were given for the (ISA-like) extension bus of Q40/Q60, and even more for the peripherals on the mainboard itself. I do not think nor pretend that the choice of ISA was a bad choice for the Q40 at the time it was designed, but nowadays ISA cards are just disapearing (there is no more ISA slot on new PC motherboards, there was still one on a few motherboards six months ago, in two years you will not find any ISA card left in the shops)... Both conditions are not given for PCI, in my opinion. This is to be studied IMHO... Now, with some good motivation, most of these programmers will be ready to sacrify significant part of their free time to do some software development. New hardware (INCLUDING UNSUPPORTED ONE under QDOS/SMS) is a very good motivation as far as I am concerned. I do fully second that. Your CDROM driver is a vey promising piece of software and proves that very well!!! But what you say, does not mean *every* interesting looking hardware will eventually get software support later on. Chances are that, if you approach software writers before producing the hardware, you may find some of them ready to support it. If the approach gives negative result, it is still time to change the specs by removing the hardware parts that will for sure never get supported. There are limits of reasonable software expectations! Yes, because of the low number of remaining QDOS/SMS software developers and (most important) to the fact they are all hobbyist (i.e. they can't work full time for a project), you can't expect too big software to be written and moreover (because we are all so geographically scattered), the project has to be achievable by one man only. But you will notice that most device drivers are not big software, some of them are just harder to develop than others... And in the special case of PCI to expand a QL related mainboard, I see that limit reached. Furthermore I doubt that PCI would really be a good motivation for possible software writers. Most of the things that we lack and eagerly wish, can already be implemented in a more simple way than PCI. There is not much use in wasting enormous software-writing resources, just so we can say hey look how modern we are, we have PCI. If there are easier ways, why chose the almost impossible ones? Soon the motivation will result from the choice: PCI support or no more cheap add-ons for the QL plateforms... But you are right, many things are still to be implemented, even in the current Q40/Q60 design. ;-) QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Future of QL - The continuing Saga... Part 9.8E13 ;-)
On Sun, 06 Jan 2002 12:57:12 -0500, ZN [EMAIL PROTECTED] wrote: On 1/6/02 at 7:32 AM Thierry Godefroy wrote: [PCI on the QL] the problems are QDOS specific... ...Not many people around who have the thorough knowledge about the hardware and software to write more complicated drivers. True, but knowledge can be acquired by anyone, the problem being the time needed to do so... Note that most of the knowledge to acquire is NOT QDOS/SMS specific, whatever driver you are going to implement on whatever plateform, you need to learn about protocols, standards, etc... .../... Thierry made several good points. Of course, many will not find them as valid if they come from a standpoint of modifying an existing driver (and recompiling it for a speciffic platform) rather than building one from scratch. Note that for the CDROM device driver, I did consider to adapt Linux sources. But while digging into the Linux sources, I quickly understood that this would lead nowhere... The way things are done under SMSQDOS (assuming you have divined this 'from the source' :-) ) actually makes attempts at converting existing drivers (unless they already come from SMSQDOS) quite unproductive. This is EXACTLY what I finally concluded in the CDROM driver case... Therefore the only sensible approach was to write everything from scratch with the actual ATA/ATAPI/ISO specs as the reference. .../... The problem is rather the lack of professional programmers that could actually work full time on QDOS/SMS... TT is not the only man that can write device drivers or OS extensions for QDOS/SMS, there are still talented programmers around, but none of them are able to spent signifi- cative time (i.e. a few months - full time) on QDOS/SMS software development... Now, with some good motivation, most of these programmers will be ready to sacrify significant part of their free time to do some software development. The equation is very different if a huge potrion of that time, or even MORE than that time is needed to first reverse-engineer code. Doing that is far more time consuming than actually writing working code. Exactly ! It is rather painful to have to reinvent the wheel everytime (this is the reason that made me decide to make the ATAPI/CDROM things sources open: at least if my method of implementing a driver works, then someone else will be able to use it in another device driver). In light of the comments regarding access to SMSQ/E source code, it begs the question: what would it take to BUY the source code from Tony Tebby? A lot of money I guess ! ;-) Or, some kind of licencing agreement that would effectively have the code in the open but with someone as the 'code cuistodian' - i.e. it would not be freely distributable, rather under something liek a GPL. I really don't think TT would be ready to GPLize his OS ! By GPLing a source, you loose all control on what it will become (for the best or for the worst). This is why I choosed the Artistic license for the ATAPI/CDROM things: at least I can keep some control on what the code becomes... New hardware (INCLUDING UNSUPPORTED ONE under QDOS/SMS) is a very good motivation as far as I am concerned... IF a new 680x0 board with PCI bus is built, then I could well find enough motivation to write a bus initializer for it... Which, of course would be the first 1% of the job since something has to be plugged into it, and that's when all the fun begins :-) Yes, but I like to have fun ! :-) The old debate should software be designed before hardware ? is a nonsense to me: IF there is hardware I can test software on, THEN I can write software for it. Actually, it's a kind of chicken and egg argument. For some hardware to actually start doing ANYTHING usefull it has to be initialized. .../.. OK, but to test hardware you do not need a full functional OS ! Your bootstrapping code may therefore be more crude... Once it is possible to bootstrap some code, then the actual and definitive initializers/ drivers development may start... QDOS/SMS forever ! Thierry.
Re: [ql-users] Happy New Year (and with a BITTER lesson to be learned) Love Live QLs
On Thu, 03 Jan 2002 09:07:10 -0500, Phoebus R. Dokos wrote: DO not install XP on a laptop if you do not have AT LEAST 256 Megs of Ram. It will crawl like a snail. It will work alright but it will be REALLY slow better stay with either NT (if you don't require USB ports) or 2K Pro Not even Win2K: better stay with Win95 OSR2 (only for running QPC2 of course ! ;-) and/or go the Linux way !!! QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Happy New Year (and with a BITTER lesson to be lea rned) Love Live QLs
On Thu, 3 Jan 2002 15:27:56 - , Norman Dunbar wrote: Well, I'm running QPC2v2 on Win2k - what's wrong with it ? Apart from being slowest than Win95, more bloated (if at all possible) and giving you no way to run in TRUE DOS (a MUST on desktop PCs for QXL !), nothing is wrong... Win956 is way too flakey for anything 95 OSR2, once patched appropriately with all bugfixes available from Microsoft site, is CERTAINLY more stable than 98 or 2K, stable enough anyway to run QPC2 (which is the ONLY reason why I keep Win95 on my laptop knowadays... if only QPC2 could run under Linux !!!). - 'real' Windows programmers Beware, with the real word, under Windoze (and more exactly with Intel CPUs), this word has several unreal meanings... ;-) refer to it as Windows Play Station due to its inability to be used for anything other than games. This is perfect then, because this is exactly for what I use Win95 on my desktop computer ! Or is it (sorry, the Win2k stuff) only for Laptops ? We have a couple of Compaq Evos which run Win2k very nicely. It may run nicely, this is not to say that it makes a good usage of the machine ressources: re-install Win95 and compare the speeds of the same software under both OSes: you will be _amazed_ by the speed difference... Well, let's go back on topic (QDOS/SMS stuff for those who forgot what the topic was ;-), my wish list for 2002 is: - for Marcel: QPC 2 (or 3, or 4...) for Linux. - for Peter : a Q60/100MHz laptop. And YES, I still believe in Santa Claus ! ;-) QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Re: Welcome to ql-users
On Mon, 31 Dec 2001 14:17:48 + (GMT), Dexter wrote: I've been looking at the current batch (that's really too big a word for it) of QL-evolved boards and don't really see anything that I can say Hey, that's a modern day super-QL! I want one! You probably did not had a look to the Q60 then: go see: http://www.q40.de/q60/forsale.html and: http://www.q40.de/q60/miniq60.html This begs the question: What is the current best performer in 68XXX Integer: 68LC060 80MHz (but it lacks a FPU) Floating point math: 68060 66MHz A 68060@66MHz Q60 will give you about 300 times the processing power of a QL... not that bad, hue ? QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
[ql-users] Updated site and new software repository
Hi happy QLers ! I did an (over due) update to my Web site today ( http://qdos.cjb.net/ and its mirrors), plus I activated the biggest and most up to date download site for QDOS/SMS ( http://smsq.free.fr/ ): over 90 Mb of compressed software are available there (i.e. all software available on QLCF BBS save the QLCF collection which is only accessible to QLCF members at http://smsqe.free.fr : 40 more Mb of software !). QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Easyptr 3
On Fri, 21 Dec 2001 08:38:40 -, Dilwyn Jones [EMAIL PROTECTED] wrote: Can anyone help me with an Easyptr query? I am trying to assign a sprite to be a loose item object within a BASIC program, with the MITEM command. It works fine if you put the sprite in the loose item from Easymenu, but the sprite needs to be changed from BASIC. There is a bug in MITEM that prevents it to load a sprite by its name (or filename). The workaround is to place the sprite into an appendix and to load it by its address with: MITEM #Channel,Item_number,-2,SPRA(Sprite_number) where sprite_number is the number of appearance in the appendix file (this appendix has to be linked to the QLiberated program). QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Easyptr 3
On Fri, 21 Dec 2001 12:40:26 -, Dilwyn Jones [EMAIL PROTECTED] wrote: Thank you Thierry. I should have thought of directly addressing the sprite like this. So if I just APPEND the sprites to a ptrmen_cde file for example that should work fine compiled. Correct. It may also work in BASIC I suppose. Yes, provided you LRESPR a ptrmen_cde copy merged with the appendix containing the sprite... .../... Looking at the manual, SPRA should also allow the name of the sprite to be specified in place of number, IIRC this does not work either: I think the bug is generic (i.e. you cannot reference a sprite by its name, whatever EasyMenu extension you use)... QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] CDROM driver for Q40/Q60 and Qubide
On Lundi 30 Juillet 2001 21:01, [EMAIL PROTECTED] wrote: [ CD-R(W) burning from SMSQ/E] The problem I see is the annoying Slaving mechanism of SMS. It terribly slows down the machine, so how can you create the data stream needed for burning? Simple (byt dirty) solution: the ported program will have to reserve most of the free memory (letting only 2Mb or so left). As the slave blocks use the free memory, the smaller it is, the faster is the slaving (because less blocks have to be searched for cached data). I've tested Audio CD playing and reading of QLWA file systems with qxltool, it works well on Q40 and Q60! Has someone tested the CDROM driver with Qubide? I did ! ;-) QDOS/SMS forever ! Thierry.
Re: [ql-users] Spam
On Dimanche 29 Juillet 2001 12:43, Tony Firshman wrote: No, its worse Would Kit Lester please tell me when he intends to take his next holidays, that way we can all go off at the same time and avoid his daily mails. .../... I even emailed him personally last time telling him about the chaos he is causing .. but no reply when he returned. .../... One easy solution would be to unsubscribe him, This is exactly what I was considering ! His unrespectful behaviour deserves such a severe measure indeed !:-( and send him the months archives on his return. No need for this, the whole mailing list (including his stupid auto- responses) is automatically archived at: http://www.mail-archive.com/ql-users%40nvg.ntnu.no/ So, could the list maintainer unsubscribe him ? Thierry.
Re: [ql-users] Q40 I/O
On Jeudi 26 Juillet 2001 09:16, Jerome Grimbert wrote: My Q40 IDE is currently fully used. (One hard disk and an EZ-135, for a total of 5 partitions). I was wondering if it was possible to add a second I/O board on it, and would it work with SMSQ/E ? Or even only with Linux ? It should work with both, provided you configure the new I/O board properly (secondary IDE channel I/O address and IRQ). (Target: moving another HD from my PC to my Q40, as well as a CD-Rom reader, ... which will also be usabble under SMSQ/E thanks to my ATAPI+CDROM things... I would then give SMSQ/E another 3 partitions, and a try to linux on Q40 on the remaining of the disk (which gonna be in the 6/8/10 GB range in size)) (I'm still hesitant about the use of the second ISA slot, should I reserve it for an ethernet card, There are probably two IDE channels I/O ISA cards available: plugging such a card as a replacement for the original I/O card would prevent using the second ISA slot... if it ever work with SMSQ/E ?) Writing a device driver for an ethernet card is definitely possible under SMSQ/E, the problem is the lack of TCP/IP stack so far (and I don't know how easy it will be to use Jon's TCP/IP stack when it will be ready...). QDOS/SMS forever ! Thierry.
Re: [ql-users] HD problem
On Lundi 09 Juillet 2001 16:00, [EMAIL PROTECTED] wrote: Hello, I have a problem with the HD. First I have deleted Files in the directory DIR1 (win4_DIR1_File1?.File99). What worries me is the ? into the filename... QDOS/SMS do not understand UNIX wildcards natively (although a a shell or programs ported from the UNIX world usually do understand wildcards in their command line)... IOT delete all files from DIR1_ directory from SBASIC, use: WDEL_F win4_DIR1_ Second I deleted the directory DIR1 Problem: The DIR1 always existent. The command Delete win4_DIR1_ shows the Error Massage Not found The command Make_Dir win4_DIR1_ shows the Error Massage always existent Try first the WDEL_F command, then do a DIR win4_DIR1_ (it should print no file at all, if it does, then something is wrong: probably a hard disk map corruption). Then you can try DELETE win4_DIR1 If no file are left in DIR1_ and the DELETE command fails, this is to say that a hard disk map corruption occured. Same thing if you can't MAKE_DIR win4_DIR1 again after the DELETE and/or if you can't delete files inside DIR1_... If your hard disk is corrupted, then backup all data on another hard disk (preferred) or another partition of the same hard disk (more risky). You will probably get errors while backing up (such as unaccessible files and/or directories) so you should use a backup program that allows to retry/abort/ignore errors (I would recommend TGBack, available from my web site: http://qdos.cjb.net/). Once you backed up all your data: - IF YOUR HARD DISK IS A SMSQ/E formatted one AND IF YOUR PARTITION IS LESS THAN 500MB, then execute the drvlink utility (you should got it together with SMSQ/E). Then try to recover the files that TGBack could not backup. - Try to recover remaining lost files using WinEd (author: Wolfgang Lenerz, commercial software available from JMS), wineditor (freeware for use with Qubide) or Doctor4 (freeware): the recovery will be slow and painful (it is usually relatively easy to recover pure text files, but other files are much harder to recover and a good knowledge of the hard disk structure is needed). - Reformat the corrupted hard disk partition and copy back the files on it from the backup you made... Note that it is always a good idea to backup all your data regularly... QDOS/SMS forever ! Thierry.
Re: [ql-users] QLIB externals and SMSQ
On Vendredi 06 Juillet 2001 11:52, Dilwyn Jones wrote: Here's a list of changes to QLiberator after v3.32. Note that there is still a problem with the QLiberator runtimes in v3.35 and v3.36 in that the codes returned for error line number and error number. Someone (Thierry perhaps? I think it came with either fileinfo2 or archivers control panel) produced a qlib_run336_mod which patches this bug Yes, 3.36mod is from me and corrects the ERLIN/ERNUM bug. Note though that the patch applied does not work for ERNUM with error messages instead of error codes (under QDOS/SMS, you may use extended error messages by returning the message address with bit31 set): this is because QLib_run only takes into account the less significant word of the error code (i.e. bit 0 to 15, which is insufficient to pass an address with bit 31 set...). Hans Peter Recktenwald and Phil Borman both produced their own modified version of QLib_run as well. HPR lost the changelog for it though (and nobody can therefore tell what was fixed/changed in his version). AFAIK, Phil's modifications were related to the error logging facility (he changed it so that the errors are redirected to a file, allowing for his Pbox suite to run without the intervention of a human that would have to acknowledge any QLib error). QDOS/SMS forever ! Thierry.
Re: [ql-users] Another MIllenium style bug
On Vendredi 06 Juillet 2001 09:16, Dave Walker wrote: Of course whether by then we still be able to see a screen or type on a keyboard is another question! Another thing to worry about regarding the date: the QDOS/SMS clock will hit its limit on 06 Feb 2097 06:28:16 (and it will go back to 01 Jan 1961 00:00:00)... It's odd, I will be 133 years old _only_... It's time to take urgent measures ! :-D QDOS/SMS forever (well, almost...) ! Thierry.
Re: [ql-users] QLIB externals and SMSQ
On Jeudi 05 Juillet 2001 19:45, Timothy Swenson wrote: 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). The latest QLib_obj (compiler) is v3.35, the lastest runtimes is v3.36. QDOS/SMS forever ! Thierry.
[ql-users] SCSI drivers (was: Re: Q40/Q60 device drivers ...)
On Lundi 02 Juillet 2001 19:56, [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2001, Malcolm Lear wrote: I have the documented sources for the CST SCSI hard drive if anyone requires them. Hi, is it possible to publish these sources? What about the rights of the author, do you know anything about this? If they're well documented, we might learn a lot. I don't think so: Thor/REBEL drivers were NOT DD2 (device drivers level 2) compliant, and introduced quite a lot of nasty incompa- tibilities (regarding file headers, directory entries, file types, etc). I would discourage anyone to port them as is on another system... and adapting them may take more time that writing a proper SCSI driver from scratch ! The ONLY thing that could be of some interest is the low level stuff (i.e. SCSI protocol implementation), but even there, the SCSI protocols have evolved so much that I am not sure it is worth the effort... Believe me: to write the ATAPI CD-ROM device driver, I first looked at Linux device driver sources: I finally gave up, downloaded the ATAPI spec from Internet, printed them, read them and then all became obvious ! QDOS/SMS forever ! Thierry. PS: note that a lot of the work I put into the ATAPI CD-ROM driver could be re-used quite easily for a SCSI driver (if there is any need for it !): this is just a matter of adapting the low level stuff (and even there, ATAPI is just a subset of SCSI protocols...).
Re: [ql-users] CD-ROM direct access for Q40/Q60
Oops... typo ! On Lundi 02 Juillet 2001 23:22, I wrote: Of course ! The actual size of data CD-Rs sectors is 2048 bytes and the ATAPI read command only got a block granurality (i.e. you can read less than 2048 bytes). CAN'T READ Thierry.
Re: [ql-users] Re: Q40/Q60 device drivers
On Vendredi 29 Juin 2001 22:49, Robert Newson wrote: Don't invoke LOGIC here, as I see no logic in your proposal: they are DIFFERENT devices (one SCSI and one IDE) on DIFFERENT hardware... Even UNIX uses DIFFERENT device names for SCSI and IDE ! But Unix DOESN'T have to! It only does so to assist the user; [roughly speaking] Unix uses special files which are actually pointers to device drivers (as defined by the major number of the file) which can obviously be named anything you [as root] like. Major numbers are DIFFERENT for SCSI and IDE drive as they refer to DIFFERENT device drivers: so your remark is pointless Thierry.
TURBO and SMSQ/E (was: Re: [ql-users] New QPC2 release)
On Samedi 30 Juin 2001 13:22, Phoebus Dokos wrote: After a quick check... Nope! With SMSQ/E 2a97 and new QPC Turbo still produces the same error. I never succeed to make Turbo work on a SMSQ/E system (tested on QXL and QPC2), so I am wondering how it could ever work for you... QDOS/SMS forever ! Thierry.
Re: TURBO and SMSQ/E (was: Re: [ql-users] New QPC2 release)
On Jeudi 28 Juin 2001 16:03, Phoebus Dokos wrote: H now that's ODD! I used the following little program to run a benchmark of Turbo of sorts 10 CLS 20 PRINT #2, date$ 30 FOR F=1 to 1000 40 PRINT #1, SQRT(F) 50 END FOR F 60 PRINT #2, date$ 70 PAUSE Ooops make the 1000 1 On QPC 2v2 FINAL, SBASIC reports execution in 9 secs. When I execute the compiled same program I get 10 secs! Is it possible? Phoebus Anyways after changing line 30 to 10 and then 40 to read SQRT (F), ATAN(F) then I got a little better results: SBASIC did it in 2 mins 31 secs and TURBO in 2 mins 21 secs. Still though it's only 7% faster h There is nothing extraordinary in these results... SBASIC is NOT SuperBASIC: SBASIC is nothing less than an on the fly semi-compilator. As such, it runs programs as fast as QLiberator (which is itself almost as fast as Turbo). You will get better figures with TURBOcharged programs that use Turbo optimized compiled features, such as integers or string slicing/conca- tenation. Note that most Turbo optimized features make it incompatible with usual S*BASIC syntax/usage though... QDOS/SMS forever ! Thierry.
Re: TURBO and SMSQ/E (was: Re: [ql-users] New QPC2 release)
On Samedi 30 Juin 2001 15:03, Phoebus Dokos wrote: I never succeed to make Turbo work on a SMSQ/E system (tested on QXL and QPC2), so I am wondering how it could ever work for you... Ha! The fact that it works for me exactly proves why I have NO CLUE in assembly and C :-) Seriously now, there's really nothing to it... you load the Turbo Toolkit and that's it practically if you're working on a floppy... After CHARGE everything's fine :-) I just tested the latest (4.9) Turbo, and I still get the same results on QXL (see below) and even worst (arythmetic overflow when executing PARSER_TASK) on the Q60... Here is what I did: - Turbo Toolkit v3.28 (the SMSQ/E version) is loaded at boot time - I Unzipped the Turbo 4.9 archive into ram1_ - I set DATA_USE ram1:PROG_USE ram1 - I write a small hello world program: 100 OPEN #3,con_512x256a0x0 110 CLS #3 120 PRINT #3,Hello world ! 130 REPeat Loop 140 IF INKEY$(#3,-1)=CHR$(27) THEN EXIT Loop 150 END REPeat Loop 160 CLOSE #3 - I execute PARSER_TASK And the parsing stops after 100 OPEN # Doing the EXACT same thing under Minerva (running on UQLX) gives a proper result (i.e. the parsing is successful)... So what did I do wrong Doctor Phoebus ?;-) What I _think_, is that Turbo is unable to cope properly with the SBASIC semi-compiled tokens... QDOS/SMS forever ! Thierry.
[ql-users] Re: Q40/Q60 device drivers
On Vendredi 29 Juin 2001 07:14, ZN wrote: On 6/28/01 at 11:14 AM Thierry Godefroy wrote: [lots snipped] OK, this is supposed to be a discussion, not an argument, so let me make some things clear right here. I have nothing against arguments (in the debate acceptation of the term, not in the dispute one of course)... actually, as many french people, I like to argue about anything ! ;-) Thierry, I am not arguing 'my' approach over yours. We are really on the same side here and arguing serves no purpose. Quite the opposite (we can now have an argument about arguments: how lovely !)... I thing that this helps to make things (no pun inteneded !) clearer in both parties mind and sometimes encourage some sort of very benefic brainstorming. I find it quite stimulating ! If nothing else, I've written no QL software, and you are famous for it, so you have done infinitely more than I have, therefore I really have no grounds for arguing at all. You are a QDOS/SMS user and, moreover, a remarkable hardware designer: as the later, I have myself no ground at all, and your experience may be quite profitable to me, especially in the device driver scope... Don't under estimate yourself nor over estimate me ! Besides, YOU are doing the driver, so you will eventually do exactly what you want. I'm just hoping you are keeping an open ear :-) I always do so... ask to those who made suggestions for the software I wrote in the past. .../... (lots of things cut, all of them agreed to) [meta-devices] NO! Channels are meant to exchange DATA, NOT to send COMMANDS or PARAMETERS to a piece of hardware ! (of course, you could argue that commands and parameters are just some form of data, but you won't, will you ? ;-) I could but I won't :-) You are right, but you cannot deny that there is a need to pass control information to drivers and even hardware (this being a case of the 'simplest possible' driver) in a clean manner - and more importantly, in a 'standard' manner. Things as such provide the 'clean' part to that, but of themselves they do nothing for 'standard'. This is only because of lack of documentation about the latest things implemented in SMSQ/E (such as the DV3 thing), but they do setup a standard by themselves: the problem bieng that to date this standard is secret ! For better or worse, you will be the one that will define the standard, and it's a big responsibility, and a big job. Not so big a job, but yes, this is an important responsibility: just imagine that I setup a new (well documented) standard that would be incompatible with an already (but undocumented) standard setup by TT himself... what a waste of time and efficency ! .../... (snipped and mostly agreed) [devices of the same kind accessed through different hardware being treated as different devices] although they logically should be [treated the same] Don't invoke LOGIC here, as I see no logic in your proposal: they are DIFFERENT devices (one SCSI and one IDE) on DIFFERENT hardware... Even UNIX uses DIFFERENT device names for SCSI and IDE ! This opens a HUGE can of worms. Later on you mention the integration of file system and device. It really goes deeper than that - you should add 'hardware attachment' to the list. Things were easy when the only thing you could connect to a floppy interface was a floppy. Trouble started when they inroduced tape drives. With IDE things got complex faster - it started off as hard drive only, now you can put almost any storage device (including floppy) onto it, using two distinct protocols. With SCSI, things are even worse, cause there you can use non-storage devices. This is a rather RARE usage though... Then, we have non-storage oriented interfaces that got storage devices grafted to them, such as parallel ports. We don't have USB yet - and if we did, we'd be in DEEP trouble, more or less anything can be on USB. OK, here you got me ! I did not think about USB (note that I got a little time to think about it as there is currently no QL hardware fitted with USB ;-). But you could have invoked bidirectional parallele port as well: you may attach SCSI, IDE or whatever converter cable you want to it ! So how I would implement, say, a SCSI driver over a bi-directionnal (SPP, ECP or EPP) parallele port ? I think that I would use some sort of encapsulation. The lower level stuff (exchanging data over the port itself) being processed by a vectored (with things) low level protocol pertaining to the parallele port driver, and the SCSI level, by all but the lowest level of the (hypothetic) SCSI driver, the lowest SCSI level being replaced by the encapsulation protocol... For the sake of (a really irrelevant) argument, let's assume the question here is, how do we treat QDOS/SMSQ devices - by the device ultimately attached, by the protocol(s) it uses, or by the hardware interface it first came bundled with? You can find examples of all
Re: [ql-users] Re: Q40/Q60 device drivers
On Jeudi 28 Juin 2001 04:13, ZN wrote: [long filenames support via special device driver and thing] Well, I am glad to have been proven wrong on this. Briliant idea! I wonder if a more complete spec could be made for such 'registration' mechanisms as they could be useful for other parts of the driver, not only the long file names. Which parts ? Regarding long file names, some kind of 'shorthand' may be required when referring to them, such as the concept of 'current directory'. There is already references to current directory into the channel headers of level 2 devices... Are we going to have the directory separateor argument again, i wonder? :-) Nothing to argue about: both QDOS and UNIX namming conventions may be implemented into an ISO9660/Joliet device driver. They are just that: conventions... and not driver programming constraints. I do see one remaining problem, though. There is still a limit to the number of directory devices that can be in use simultaneously. Yes, 16... Since all calls in SMSQ/E are passed to a non-directory driver, I have to ask, why bother with a directory driver? Because the IOSS takes care of most ancillary tasks when opening a channel on a directory device driver: - device physical definition block check and allocation (if absent). - channel definition block duplication in case of a shared open call on an already open file. - automatic freeing of channel def. block for DELETE calls. And also because non-directory device drivers don't get listed into the programs that scan the directory device driver linked list to find out which directory devices are available on the system (QPAC2 Files menu, Cueshell, PWfile, etc)... [modular device driver] This is not really what I meant. What I emant is that 'mounting' of a devices, i.e. linking of a driver to a piece of physical hardware, should logically be handled by TRAP #2. However, there are no calls to do this Yes there are... Under SMSQ/E this is handled through extensions things when needed (i.e. floppy and ramdisks do not need this mechanism, but hard disks and ATAPI device do and got one). For hard disks (on Q40/Q60 and probably ATARI), you got the SBASIC WIN_DRIVE command (which in fact calls an extension from the WIN control thing): e.g. WIN_DRIVE 1,0,1 links win1_ to first IDE drive (1st IDE controller, master) and to the second partition (0=1st, 1=2bd, etc...). With the CDROM device driver, you got CDR_DRIVE device,drive,session. E.g. CDR_DRIVE 1,1,3 links cdr1_ to the fourth session on the second IDE drive (1st IDE controller, slave). The problem is that I don't have the WIN control specs, so I don't know if my implementation of the DRIV extension (same problem for the USE one BTW), in the CDROM thing is the same (on the parameters passing point of vue) than the one of the DRIV extension in the WIN control thing... I will write to TT about this (let's hope he will reply this time...). Of course, these extension should ideally share the same parameter passing conventions so that they can be called from the same routine in assembly or C (or whatever language). Example with a C library routine: int set_device(char *thing_name, int device, int drive, int volume); Such function would then just have to call the thing which name is thing_name with DRIV as the required extension and device/drive/volume as parameters... but special parameters passed to open/close or even format calls could be used for this. I see the meta device sea serpent emerging once again here... ;-) Let me say that this is (although definitely possible) NOT in the philosophy of QDOS/SMS. TRAP #2/TRAP #3 are related to channels (with the notable exception of the FORMAT TRAP #2), and NOT to anything related to device driver (or drive) parameter settings... Here AGAIN, think thing ! However, even if they are, at the very lowest level, where a single piece of hardware can be used by many drivers, there may be a problem, unless all of the drivers that can access the hardware are rewritten to take account of each other, or a 'hardware' driver was written, into which other drivers are linked (problem here is that we might end up with more than the max number of simultaneous directory drivers). If all device driver are properly written, there is no risk for this... IDE is the example that comes to mind on a QL. Suppose that the user connects a hard drive and a CD ROM as master and slave on a single IDE channel. This is my case on my Q60... But IDE specs do take care for this and a same IDE bus may be shared by the two master and slave devices provided they both obey to the IDE specs (see below)... Effectively, this looks like a set of registers for each device, however, only one set at a time can be used, and this is switched by one bit. This bit is visible and changeable by both drivers. Unfortunately, most (if not all) drivers assume the hardware will exclusively be used by themselves - and here we have a
Re: [ql-users] New QPC2 release
On Jeudi 28 Juin 2001 15:33, Marcel Kilgus wrote: For those who didn't subscribe to Jochens QLNews: the long overdue update to QPC2 v2.02 has been released: New, necer seen bug: when starting Cueshell v2.13 (with two default windows open to RAM1_ and DRV1_), I get a crash (only the Cueshell borders get drawn) and after a few seconds the screen fills (upward down) with a pretty mauve pattern of pixels (screen mode is full screen 1024x768 65536 colours). Reverted to v2.01 (no such problem encountered with this one)... QDOS/SMS forever ! Thierry.
Re: [ql-users] Re: Q40/Q60 device drivers
On Jeudi 28 Juin 2001 23:42, Tony Firshman wrote: On Thu, 28 Jun 2001 at 21:16:18, you wrote: C'est l'exception qui confirme la règle (which I will risk to try to translate into: This is the exception which confirms the rule) The exception proves the rule I knew it was risky... ;-) Thierry.
Q40/Q60 device drivers (was: Re: [ql-users] Derek Stewart BB)
On Dimanche 24 Juin 2001 10:41, Derek Stewart wrote: Hi Ian, Apparently, this message was not for the ql-users list, but it is indeed a Good Thing (tm) that you sent it there ! Although I would like a tape streamer, but I am having trouble writting the device driver for the floppy disk based cable streamer. I was hoping to work out the FTAPE device driver from Linux, but things are not that easy. There is not much information on the FLP_CONTROL thing. Derek, I am right now writing a device driver for CD-ROM drives on Q40/Q60 (I think I can announce it officially now as things build up nicely and I will probably able to release something useful before I leave for Indian Ocean). I think it would be much easier to write an ATAPI streamer device driver, as it will not conflict with the SMSQ/E built-in drivers (floppy and ATA hard disk). The CD-ROM device driver does allow to use its low level routines (they are vectored as an extension thing) for use by any other ATAPI device driver (no risk of conflict either), so you could re-use quite easily the low level stuff I wrote for your own ATAPI tape device driver... The CD-ROM device driver will be made open sources and, although these sources are not yet ready for a public release (MANY things still to do...), I could send them to you in their current state if you are interested. QDOS/SMS forever ! Thierry.
Re: [ql-users] New Q40/Q60 software
On Samedi 16 Juin 2001 13:01, Dilwyn Jones wrote: How do you manage to do your QLing away from home, Thierry? Do you have a QL system you take with you on the ship, or do you use a QL emulator on a laptop or something? Laptop and QPC... Your website seems to be up to date however long you are away. I usually update the site just before leaving and just after comming back. I also sometimes update the site during port visits... QDOS/SMS forever ! Thierry.
Re: [ql-users] NEXT in FOR-loop
On Samedi 16 Juin 2001 17:51, Christopher Cave wrote: I have just come across a feature in the behaviour of NEXT in FOR-loops which is a bit puzzling. If NEXT is invoked from the body of the loop with the counter NOT on its final value, control ends up in the loop with the counter reset at its next value - just what one would hope for. However, if the counter IS on its final value, the same happens except that the counter is not reset. Try entering even and odd integers in the program below (I am using QPC2v2.00 and SMSQ/e v2.98) : 100 CLS : INPUT '';n 110 FOR i=0 TO n 120IF i MOD 2=0 THEN NEXT i 130PRINT i 140 NEXT i 150PRINT 'done' 160 END FOR i To get round this in a piece of code I'm currently engaged on, I have had to test for i=n when the exception arises and use EXIT i when on the final loop. Comments anyone? This is normal: although NEXT is _NOT_ the equivalent of END FOR (it is used to reenter the loop, either FOR ... END FOR or REPeat ... END REPeat, short circuiting the instructions after the NEXT), it behaves in much the same way: when the counter reaches its maximum value, the interpreter aborts the loop, continuing just after the END FOR or NEXT (whichever was reached first). In a FOR ... END FOR loop, the NEXT directive must be followed by EXIT if you want to ensure that S*BASIC branches after the END FOR when the NEXT is executed while the FOR counter is already at its maximal value. NEXT always worked that way in all QDOS/SMS versions, so it is surpising that you discover this today. QDOS/SMS forever ! Thierry.
[ql-users] New Q40/Q60 software
Hi happy QLers ! Today, I wrote a small Q40/Q60 utility: CAPSMON v1.00 A CAPSLOCK monitor that makes for the absence of the keyboard CAPSLOCK LED support on Q40/Q60 (why the hell are the keyboard LEDs disabled ?!? Peter ?). CAPSMON is written as an extension thing (you can even (un)link it at will), and is open sources: I hope this will encourage some of to write some software for QDOS/SMS using things (it's sooo easy !). CAPSMON is available from my Website: http://qdos.cjb.net/english/download.html QDOS/SMS forever ! Thierry. PS: another big THING is in the pipeline for the Q60/Q40... I just hope I will find time to finish it before having to leave for Indian Ocean: one year to spend far from France and far from my Q60 ;-(
Re: [ql-users] List - Forums
On Jeudi 07 Juin 2001 23:26, Bojan Kotur wrote: This mailing list is all great and everything but wouldn't it be better (and making less net traffic) if the list master just set up a bulletin board like UBB or similar? Such a forum already exists for QDOS/SMS: http://qdos.cjb.net/english/messages.html That way we could avoid having to recieve tons of mail every day and still have the same amount of people (or even more) with us. Think about it... surely there are QLers out there who are not on the list because of all the e-mails but still want to keep in touch with the rest of the QL community. In this case, just unsubscribe an use the ql-users mailing list archives instead: http://www.mail-archive.com/ql-users%40nvg.ntnu.no/ QDOS/SMS forever ! Thierry.
STAY OT PLEASE ! (was: Re: [ql-users] Email and HTML)
On Lundi 04 Juin 2001 22:47, Malcolm Cadman wrote: This should complete my experiments with OE. .../... Please could everyone interested in Outlook and other stupid M$ crap write PRIVATE messages to each other instead of clobbering this list with uninteresting stuff (regarding true QLers) ? I am sorry to react this way, but although I am patient, I am now fed up with this Outlook thread ! QDOS/SMS forever ! Thierry.
Re: [ql-users] diff
On Samedi 02 Juin 2001 14:30, [EMAIL PROTECTED] wrote: is there a port of diff for QDOS? Yes there is: I know about two of them, the best one being GNU diff v2.4, available on QLCF BBS (GNUdiff_zip, ported by Erling Jacobsen), see: http://qdos.cjb.net/FileList/area09.html Just tell me if you want me to email it to you... QDOS/SMS forever ! Thierry.
Re: [ql-users] QL BBS
On Samedi 12 Mai 2001 20:56, Derek Stewart wrote: Hi, lloks like Nene Valley BBS is cosing down at the end of May this year. This is bad news: QLCF BBS was a point on Nene Valley (I also poll QBBS though) and Nene Valley was the relay between QBBS and SyncNet (SyncNet itself relaying messages to/from MausNet and Internet maus.computer.ql* newsgroups) If any requires a BBS to call then my system, Holborn View is open 24 hours on a dedicated telephone line. So is mine (QLCF BBS). The system runs on a Supergold card QL, Superhermes, Same here (+Aurora+Qubide+RomDisk). USR Courier modem. Connect speeds upto 33600 baud, but due the rubbish telephone lines 28800 and sometimes 31200 is available 28800 max for QLCF BBS (good line: if yours is good you'll get 28800). There is lots of interesting QL specific software for download, which comes from all the QL Internet sites. Same here. I have links to the Fidonet, which can give other computer interests. If anyone is interested then please call. Would you be able to ensure relaying to SyncNet ? QDOS/SMS forever ! Theirry.
Re: [ql-users] Benchmark
On Mercredi 03 Janvier 2001 15:35, Davide Santachiara wrote: On the same Athlon 1000 at 1024x768 Windows mode (16 Mb) Dhrystone / s 24789,3 VAX Mips 14,11 Bogomips 20,52 Was it the latest (gcc-compiled) dhrystone v2.1 benchmark ? If not, please get it from my Web site and retry... ;-) This makes QPC2v2 on Athlon 1000 faster than my Turbo-QXL (the 35MHz one: 23364 Dhrystones/s, 9 VAX Mips, 21,8 BogoMips) in integer calculations. QPC2v2 will still be slower for programs using the FPU though (mainly POV and ghostscript). QDOS/SMS forever ! Thierry.
