[ql-users] The QDOS/SMS repository is back up...
Hi all ! Because of some problems with my ISP, the QDOS/SMS repository has been shut down two months ago. As I could not sort out these problems, I had to setup a new web site (but I will change it soon again so to get enough room for the whole 90Mb software archive). At the time being, the repository is available at: http://www.multimania.com/godefroy/ Most links are in fact pointing to Phoebus R. Dokos' mirror (many thanks Phoebus for setting it up !!!), but the newest software I got has been put back in place locally as well... As my sparse free time will permit, I will eventually get everything up and running again (an overdue update to my main QDOS/SMS site is also to come "soon")... Please be patient, everything should be sorted out by this summer... I appologize for any inconvenience. QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
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.
[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] Future of QL - Part: ERROR, arithmetic overflow !
On Fri, 11 Jan 2002 15:01:34 -0500, Phoebus R. Dokos wrote: > At 06:45 ðì 11/1/2002 +0100, you wrote: > > >On Fri, 11 Jan 2002 00:04:59 +0100, Richard Zidlicky wrote: > > > > > On Thu, Jan 10, 2002 at 10:00:33PM +0100, Thierry Godefroy wrote: Err... please quote at least a little bit so that I can see which among the 1E121 messages is dealt with ! > No criticism whatsoever however just to satisfy my curiosity and with my > limited knowledge, isn't the method you proposing actually a drawback? > If (and if I understand Richard correctly) you take away all i/o functions > from QDOS/SMS by implementing a thing that would report itself as a > non-directory device which will manage ALL devices directory and non - > directory Totally WRONG ! Please READ carefully what I already wrote (since June 2001 !) about this device driver: I know that my english is rather approximative, but I got no time to explain over and over again the same thing. Once for all: the CDROM device driver (and its ISO/Rockridge/Joliet/ Packet-CD extensions if someone ever implements them all) is already and will stay a LEGAL SMSQ/E directory device driver. BUT, because of the current IOSS limitations, I had to find a way to overcome the 36 (or 80 for DV3) filename length limit (no problem for ISO-9660 which also supports 36 chars max in "legal" implementations, but definitely a problem for Rockridge/Joliet extensions as well as for Packet-CD filesystem). This is done by intercepting the IOSS call for OPEN to the drivers BEFORE the directory device drivers OPEN routines are called: under QDOS/SMS, all the device drivers are called in chain (non-directory ones first) during an OPEN call until one of them reports a success into finding/opening the device/file passed as a parameter to OPEN. This can only be ensured by implementing a FAKE non-directory device driver (no limit on the device+parameters length for those...) which ONLY responsibility is to store over-36-chars-filenames in a safe place for REGISTERED directory device driver to use them later, AND to truncate the filename so that the IOSS does not report a "bad name" (because length>36) before starting to call the directory device drivers OPEN routines. > (in the beginning File I/O and later on maybe video or sound) and > by implementing a SCSI disconnection type of operation (that is creating a > software representation of disconnect feature: send the command to the > device to do whatever and report back when it's finished) wouldn't that be > A LOT faster and open up a whole new world of possibilities for QDOS/SMS? > This way we wouldn't lose the (let's call original QDOS/SMS i/o) legacy > support and at the same time you could implement a whole multitude of > device drivers. There is no such problem for I/O TRAPs (TRAP #3) under QDOS/SMS: if a call can't complete immediately, an immediate return is made via the scheduler and a later try will be attempted (provided you passed a big enough (or infinite) timeout). The problem occurs with TRAP #2 calls though (OPEN/CLOSE/FORMAT/DELETE): there are some (non trivial ways) to overcome this problem, each one bringing some level of incompatibilities with existing software. BTW, in direct "sector" access mode, the CDROM device driver already implements asynchronous OPEN calls (the call returns immediately, the actual check for the presence of a CD-ROM into the device is made during the first I/O TRAP which, being a TRAP #3, is ALSO non-blocking): this already could make it incompatible with some existing software. Imagine that a software only checks for the "medium check failed" and "not found" errors after the TRAP #2 OPEN call and then only checks for "end of file" on subsequent TRAP #3 I/O calls: this is legit under QDOS (were a TRAP #3 never reports "not found"), but with the CDROM device driver "medium check failed" or "not found" will occur only after the first I/O call. If the programmer of the software in question is intelligent enough, he should have make provision to check for "unknown" errors and take appropriate measures when they occur; if he did not, then his program may well just crash ! > Also you wouldn't have to remove or disable the IOSSS module (possible > according to TT) and at the same time effectively kill the slave blocking > mechanism... no block devices no slave blocks ;-) hehe Slave blocks are NOT a bad thing themselves: the inconsiderate usage TT did with them under SMSQ/E _IS_ the actual problem. I will use them BUT only in a few cases: when less than 2048 bytes are requested for a read, thus avoiding to re-read each time 2048 bytes of data (you can't read less on a CD) from the device each time a software reads only two bytes... For bigger transfers, slave blocks a
Re: [ql-users] Future of QL - Part 1E121 (I had to increment it ! ;-)
On Fri, 11 Jan 2002 00:04:59 +0100, Richard Zidlicky wrote: > On Thu, Jan 10, 2002 at 10:00:33PM +0100, Thierry Godefroy wrote: > > > 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; > > this seems slightly risky to me; the fact that QDOS/SMSQ did never save/ > restore A0 when calling the driver open routine is no guarantee this will > stay so forever. You are depending on undocumented behaviour.. NOT AT ALL !!! This is perfectly documented: the documentation for the IOSS (see the QDOS/SMS reference manual) DOES says that A0 must stay unchanged or at least be restored if the device driver did not recognize its own device in the name during an open call, and it also says that this is because A0 is reused after by the other device drivers. > why this complication? The IOSS will be of very little help for you, all > "facilites" it provides are usefull only for very limited filesystems > like the original MDV one. Instead it limits unnecessarily 'key' and > uses valuable drive definition blocks which are still very limited > resource. I NEED to implement it as a legal directory device driver for a few reason: at the user (and utility programmers) level, you must register it so or the device (here cdr1_) will never be found as a mass storage (e.g. in QPAC2 or Cueshell). At the driver programming level, I will use (although differently than TT does) the slave blocks for caching (in fact caching will occur ONLY when less than a CD-R data block (=2048 bytes) read is requested). > You get the mangled display of filenames in QPAC channels menu but this > can be only an intermediate solution, Whatever way you choose to implement a long filename driver, you simply CAN'T support fully existing utilities which make the assumption that the 36 chars limit applies to all devices ! Moreover the truncated filename will not be "mangled" (it will just have 4 alphanumeric characters at the end) > anyway clean methods have to be > defined to get the name of open channels (if it is regarded usefull > enough feature). This already exists as a TRAP #3 call in SMSQ/E and will actually return the long filename with my method. Anyway I think that the best thing now (well, in fact in 7 months, when I will be back to France) is to implement the driver the way I feel like and release it. Then anyone will have the possibility to criticize the way it was implemented, and the opportunity to change it himself (it will be open source)... ;-) QDOS/SMS forever ! Thierry.
Re: [ql-users] Progs.be FTP links
On Thu, 10 Jan 2002 22:35:10 +0100, Marcel Kilgus wrote: > Thierry Godefroy wrote: > > 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...). > > IIRC the FTP protocol allows server to server copies, although hardly > anybody is using it. Are you speaking about the "PROXY" FTP command: yes it is possible but nevertheless you must stay connected to the ISP while the transfer takes place. with a telnet (or ssh) account you can just launch the ftp locally with a "nohup" and disconnect immediately: the transfer will occur while you are off line (much cheaper !). 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] 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] 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] 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] 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] The reality...
On Tue, 8 Jan 2002 17:25:22 +0100, Wolfgang Lenerz wrote: > Hi all, > > Phew! > I just came back from holoday, Welcome back Wolf, and happy new year to you ! > and there were 191 message in this > list over a 2 weeks period! > > Who said the QL was dead? Nobody... ;-) QDOS/SMS forever ! Thierry.
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] Future of QL - Part 1E120 (I had to increment the it ! ;-)
On Sun, 06 Jan 2002 15:00:22 -0500, ZN wrote: > On 1/6/02 at 7:12 PM Thierry Godefroy wrote: > > .../... 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!) > > Actually, TT was probably the very first person to receive the Aurora > specs, while it was still a prototype, and a long way from production. > Result: NOTHING. Not even an answer. For all I know, there was a shredder > linked to the output of his fax machine, since that was the only way he > communicated (if that could be called communication) at the time. I'm afraid this is still the case... ;-( > Maybe I should ave promised money? Not that I am faulting TT, because I _DO_ > understand his posittion. OTOH, I never really dealt with the people who > wrote the software myself, rather that was done by Ron Dunnett. Originally, > I really wanted to make the specs completely public, but since I did get > signals about more colors (for the QXL, though) from different sources, I > decided to give the specs to only a few people, until I made them freely > available on my (ex) web site. Guess what: NOTHING, for years. Actually, the graphic cards device drivers are probably the most complicated and sophisticated ones (especially when you take all "ancillary" extensions into account, such as the pointer environment)... I for one would hesitate to write such a driver from scratch (there the sources availibilty of existing drivers is more than a critical prerequisite) ! I think that the only one who is able to write such drivers is... TT himself (with the QXL or Q40 SMSQ/E sources, I guess this could be implemented in a few days...). > IMHO before > the community was largely web connected, waiting for a response before the > hardware was built, would mean the hardware never would have gotten built > in the first place. The situation is a little bit different now, not as > much as you would think: > > > Note that this is not always the case (Nasta did publish the GoldFire > > specs and asked for advices)... > > And got VERY little. I am sure once the GoldFire becomes available, I will > hear no end to complaints about decisions made in it's design. However, at > this point, as detailed as the descriptions are (and they need to be to > make it possible to write software for it or decide about any aspect that > should be changed), they seem to be too detailed to have many people bother > actually reading them. Mind you, I did download all the specs of the GF a while ago (you even sent me some) and I did read _some_ but, here again, time is the limiting factor ;-( > This is highly disconcerting considering there are aspects of GF that are > 'new' to SMSQDOS. I must confess, that I do like a lot the onboard Ethernet concept... :-) > For instance, people will complain about disk operations > stopping everything, but when a solution is offered to this problem, which > involves hardware (and unfortunately, this is the only way to address it), > and associated changes to the drivers (or better yet OS because the feature > introduced is generally usefull), the feedback equals more or less zero > (with notable exceptions). Yes, I think I can remmember about a few emails we exchanged about the GF design and interrupts management... ;-) > I certainly hope this is not the way open > hardware developement on the QL is going to work. So I hope as well, or better abandon any hope for new QL hardware in the future ! > >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... > > Well, there's the GF stuff - feel free to open fire. But as much as I can understand, the actual specs are quite a bit outdated (ColdFire based, while the processor of your choice is now a 68EC060 IIRC), aren't they ? ;-) > >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. ;-) > > This begs the question: WHAT PCI expansion devices do you want to see on a > QL platform? I would be willing to bet they could easily be numbered on the > fingers of one hand... and that most of these already exist, just in QL > speciffic form. I don't deal with the present situation (there are still a few ISA cards available), but with the _future_ one: if there is no PCI-based successor to the Q60, then what the hell a f
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 conventio
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 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] 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, 6 Jan 2002 13:04:21 +0100, Arnould Nazarian wrote: > > > - neither QDOS nor SMSQ are available with source. > > > > Alas for developers... > > As far as I understand, in SMSQ/E TT does test programming techniques > which he thinks could possibly be patented. It seems possible to try to > patent very low level stuff as that is exactly what the company at > www.nexwave-solutions.com has in mind (Emmanuel Marty, their > programmer who met TT, did a very complete study of current OSes, see > http://tunes.org/Review/OSes.html where there also is a small paragraph > about the QL) Let me tell you that if I (or any assembly programmer) had the will to steal TT code, this is perfectly possible with a good disassembler (I tend to use DISA) and time. I already disassembled and commented myself assembly written software, including parts of TT's (this way for example, I could understand how the mouse driver works under PE and I wrote a driver for the Thor XVI mouse). Someone already disassembled the full JS ROM (and commented it, therefore understood it as well), the same thing could be done with SMSQ/E... Not divulgating assembly sources is therefore NOT a protection against code or programming technique robbery. It just makes it more difficult, but it also makes it more difficult for the developers to write new software as well... > OTOH TT is also very aware that this leads to nowhere because he is > alone on this path. However there is one developper who got the > sources for SMSQ/E, named Marcel. How did Marcel get access > to those sources? I think TT was very impressed by Marcel's emulator (who is not ?). Indeed, TT does sometimes release sources (or part of sources, for example I got the QXL net driver sources from him) when you ask him kindly. The problem is that TT answers very rarely when you write him (for whatever reason, not only when requesting something)... ;-( > Did he sign a non-disclosure agreement? And how > many developpers in the QL world would be interested to see these > sources? I for one would LOVE to have them and would be ready to sign any non- disclosure agreement (indeed, each time I asked something to Tony, I always promissed to never divulgate it unless he authorizes me to do so: I never failed to the promises I did). QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Future of QL - The continuing Saga... Part 9.8E13 ;-)
On Sat, 5 Jan 2002 18:58:11 +0100, Richard Zidlicky wrote: > On Fri, Jan 04, 2002 at 10:58:08PM +, Dexter wrote: > > > > > > On Fri, 4 Jan 2002, Peter Graf wrote: > > > > > PCI instead of ISA on Q40/Q60 would give you: > > > > > > *No* expandability under QDOS/SMS at all. > > > > Peter, thanks for explaining where the problem lies... > > > > Could you just fill things out a little for me and explain why it's such a > > problem for QDOS/SMS? As I said, software isn't my strong suit, and you > > obviously know your subject very well... > > > > What specifically is it that's difficult? Would this difficulty apply to > > Linux also? > > 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 ! >with severe restrictions like 64 bytes stack usage. This is QDOS specific, you may use more under SMSQ/E (because the supervisor stack is bigger). Moreover, in assembler, 64 bytes of stack is already "plenty of space"; it has always been into the QDOS "philosophy" to use the smallest amount of stack, thanks to an intelligent and consistant use (between OS calls) of registers. >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... 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... > - filesystem is hardwired into device driver. Instead of just writing >a block device driver to implement a new hard disk you have to write >a complete filesystem.. it has been done about 100 times. SMSQ has >some way of solving this but nobody except TT ever went this route >so nobody can say how (if) it works. I will go this route too for the CDROM device driver, although most probably in a different way than TT did, because of lack of _public_ documentation about how SMSQ/E does it ;-( (but my route WILL be publicly documented and open source). >Judging by source fragments and disassembly it is rather messy, even >simple things like partitioned harddrives are a disaster. It's difficult to "judge by source fragments and disassembly", unless you got the documented sources... >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... >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. >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... ;-) >and complete and useless incompatibility with anything else on the >planet. Such as ? 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... >Unfortunately >the OS interface in both QDOS and SMSQ still has severe limitations, >practically enforcing the 36 chars limit. Untrue, SMSQ/E DV3 (device driver level 3) has built-in support for 80 chars filenames instead of 36. Alas the current (native) SMSQ/E device drivers don't use this feature. > - neither QDOS nor SMSQ are available with source. Alas for developers... >If you write eg an >PCI bus initialiser the OS must have hooks to execute the code very >early. Both QDOS and SMSQ have some way to do it but eg the SMSQ way >appears very cumbersome. It would work somehow by linking the code >into SMSQ which seems like a nightmare (for all parties) to get >the distribution and copyright somehow correct. TT himself explained how to link new modules into SMSQ/E (
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] 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] 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 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] 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] SD_PXENQ (trap #3, D0=$0A)
On Thu, 15 Nov 2001 09:05:04 -, Norman Dunbar <[EMAIL PROTECTED]> wrote: > I'm having a couple of problems on QPV2V2 calling the SD_PXENQ trap (sorry, > I don't have the SMSQ name for it - I'm an old lag !) It's IOW.PIXQ (TRAP #3 with D0=$A). > I have my 4 word buffer filled with values, but I'm getting incorrect > results for the xpos and ypos values - offsets 4 and 6 in the buffer. > > The buffer is 4 words and is in the following order - width, height, xpos, > ypos - at least that's what it is supposed to be. I get correct values for > width and height, but garbage for xpos and ypos as follows : > > #0 444x40a0x30 > #1 444x200a0x190 > #2 444x200a0x190 > > If I open a new channel #3 as 'scr_100x150a50x70', I get > > #3 100x150a0x0 > > Which is totally wrong as far as positioning is concerned. NO !!! It's perfectly right on the contrary: IOW.PIXQ returns the window size and the CURSOR POSITION in pixel (NOT the window origin !). When the window is defined, the pixel coordinates are of course set to 0x0; try to print something in #3 and then re-call IOW.PIXQ: you will get a new value for words at offset 4 and 6. BTW, if you want good info on SMSQ/E (or, QDOS, SMSQ, ARGOS,...) assembly programming, I warmly recommend you to buy the QDOS/SMS reference manual from Jochen Merz ! QDOS/SMS forever ! Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Q60
On Mercredi 12 Septembre 2001 18:39, Wolfgang Lenerz wrote: > Hi all, > > I've recently had some time to play around with my all new Q60. > > I'm very happy with it, it is a nifty beast. Yes indeed ! > This also gave me the opportunity to test the CD driver. Indeed, I (of > course) waznted to get my usual setup also going on the Q60. Sp I > copied my QPC QXL.WIN fimle to a CD (i've written abaout this > before) and, with the help of many of you, actually managed to het > it going. > I had to change one instruction in the ATAPI driver, else it would > completely crash the machine, but, once that was done, it works (if > anyone is intered in the tweak, contact me, I'll be sending an email > to Thierry a bit later to tell him about it, as well). I wonder what this instruction is as none of the beta-testers had reported any crash so far... > I then used the QXLTOOL utility to transfer my files (about 40 MB > in a 70MB qxl.win file). > > The good point : IT WORKS. I was able to tranfer the files from the > qxl.win CD to the hard disk. As far as I can tell, there was *NO* file > corruption or anything. Then you are lucky as I DID experiment some files corruptions (I guess qxltools does not retry when an error occurs and read-retry after error is not yet implemented into the CDROM driver)... > Hats off to Thierry and J. Hudson. Thanks, but as far as I am concerned, the work on the CDROM driver is _far_ from being over. > The bad point is: it is really s-l-o-w. the 35 MB mentioned above > took about 36 hours (yes!) to transfer. No wonder here: there is simply no caching mechanism implemented so far... > I don't know whether this is > due to the driver or QXLtools, I'll attempt to find out at a later stage. In fact this is due to both: - the driver lacks caching and must reads at least 2Kb of data each time 2Kb or less is to be read (you can't read less than 2Kb of data from a CD). - qxltool issues a read for each filename, file length, date, dataspace, (etc...) fields and, as the QLWA filesystem got 512 bytes per sector, it reads 512 bytes at a time (combined with the missing caching of the driver, this means that in fact each 512 bytes block is read 4 times from the CDROM !). > It was very noticeable that copying files thatlay towaords the end of > the disk took MUCH longer (at the same file size) than some that > lay at the start of the disk. Here again the reason is lack of caching: each time a file is copied, qxltool gets the sector numbers from the FAT which is located at the start of the disk and then go get the corresponding sector; I suspect it does so for each sector of a file (there is therefore as many head moves as there are 512 bytes blocks in a file !). As I wrote previously: the QXL.WIN file access on CD-R was just a quick hack. The driver is still in an early alpha state and will only go beta once proper error recovery/correction and data caching is implemented. QDOS/SMS forever ! Thierry (currently in Djibouti).
Re: [ql-users] Dubai
On Lundi 13 Août 2001 14:14, Ian Pizer wrote: > Hi Thierry > > Do you communicate from a cyber cafe in Dubai, a cyber cafe in your ship or > by something sophisticated in your ship office? From a laptop in my office. Thierry.
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.
[ql-users] CDROM device driver (was: Re: Spam)
On Dimanche 29 Juillet 2001 23:09, Bill Waugh wrote: > Hi all > I just downloaded Thierry's cd stuff and have a couple of questions for > your combined wisdom > > 1. will this allow me to use a cd writer on Q40 Yes for reading, not yet for writing: but if someone ports "cdrecord" or an equivalent program (using the ATAPI thing), then you will be able to write CD-R(W) from SMSQ/E on Q40 (and SGC+Qubide !)... > 2. if the answer to 1 is no then would be I able to read cd's on q40 > that I had written files to on a cd writer in a PC. Yes, of course ! The best option so far is to write a QLWA image (QXL.WIN file) right on the CD-R(W) and use qxltool under SMSQ/E to read it back... > I can imagine Thierry reading this and wondering if we users are ever > satisfied, Alas, there are only 4 days left before I leave France for one full year (and I will NOT be able to do more SMSQ/E development before I leave), so the CDROM driver will be left in an "alpha" state for a while, I'm afraid... 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.
[ql-users] ATAPI extensions thing and CDROM device driver
Hi happy QLers ! I just put the beta (v0.20) of my ATAPI thing and the alpha (v0.06) of my CDROM device driver/thing onto mt web site. BEWARE: this still must be considered as unstable software ! The good news is that it works for both Q40/Q60 _AND_ QUBIDE systems (only under SMSQ/E and with (Super)Gold Card for QUBIDE though). It is also possible to get access to a QLWA disk image (QXL.WIN file) burnt directly on a CD-R. Go get it on http://qdos.cjb.net/english/download.html ! QDOS/SMS forever ! Thierry. PS: overdue web site update also done...
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] 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 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] 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.
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] CD-ROM direct access for Q40/Q60
On Lundi 02 Juillet 2001 16:47, Richard Zidlicky wrote: > On Sun, Jul 01, 2001 at 07:59:12PM +0200, Thierry Godefroy wrote: >.../... > > I now can get direct access to a CD-ROM on my Q60 with: > > > > OPEN #3,"cdr1_*d2d" (for 512 bytes blocks access, or *d4d > > for 1024, or *d8d for 2048) > > I assume the block size is just a "soft" size? 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). This is the device driver that takes care of splitting data in virtual 512 or 1024 bytes blocks. > Otherwise it would > be necessary to get the real block size somewhow. The naming > scheme will be somewhat difficult to maintain with audio discs, > they have a sector size of 2352 or something like that ;) A CD-ROM block size can be 2048, 2052, 2056, 2324, 2332, 2336, 2340 or 2352 _data_ bytes long, depending on the CD-ROM format. Hopefully almost all data CD-ROMs use 2048 bytes sectors (this is the only format currently supported by the device driver, but other format could easily be implemented later). Audio CDs can currently be played using the driver (PLAY, PAUSE, RESUME, and STOP are implemented). The final driver will also provide Audio data acquisition from the CD (that is, you will be able to recover CD audio data into memory)... > Btw how about getting the length of the CD? Yes, this will be implemented very soon (this is needed anyway). > > For the most curious or impatient among you, the sources for > > the alpha release (still many cleanup to do and most TRAP #3 > > to implement) are available (write me a private email)... > > how much more do you want to implement? io.sstrg/io.fstrg seems > quite sufficient. All SMSQ/E TRAP #3 calls will be implemented (but those irrelevant to direct access, such as IOF.RHDR, IOF.DATE and IOF.VERS which are specifically _file_ related). 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...).
[ql-users] CD-ROM direct access for Q40/Q60
A small progress reports: It works... :-)) I now can get direct access to a CD-ROM on my Q60 with: OPEN #3,"cdr1_*d2d" (for 512 bytes blocks access, or *d4d for 1024, or *d8d for 2048) GET #3,A$ A basic direct access CD-ROM device driver should be available sometimes next week (beta release). For the most curious or impatient among you, the sources for the alpha release (still many cleanup to do and most TRAP #3 to implement) are available (write me a private email)... QDOS/SMS forever ! 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.
[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
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.
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.
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: [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.
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.
[ql-users] Re: Q40/Q60 device drivers
On Jeudi 28 Juin 2001 19:12, ZN wrote: > On 6/28/01 at 11:14 AM Thierry Godefroy 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 ? > > Exactly the ones you describe in the rest of your answer. > 1) have a _USE and _DRIVE thing that handles the corresponding commands for > all devices > 2) your 'que atapi packet' thing, if slightly extended, could be used by > anything working over IDE > etc... > > Don't think that I am nagging - you have obviously thought of many things > (maybe even everything :-) ) and I for one am VERY glad to see it, but you > must already realize you are breaking new grounds here. I hope you will > document it all, otherwise people will have to read the code again, and we > know how 'well' that works :-) Don't worry, there will be full documentation (although the doc will most probably be available some time after the first driver release)... > >> 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... > > Well, that's nice to hear. Are they being used? Yes, somewhat, but not in the way you describe below... > >> 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 meant things like opening files at ../somewhere. i.e. embedded > 'shorthand' for directory level up/down etc :-) I see what you mean by "shorthand" now... Well, yes, this could be implemented (cdr1_../myfile would then refer to the file held into the parent directory of the DATA_USE default directory), but I don't think it is a high priority feature, not to mention that this is not really driver related but rather SBASIC/C library related (the PROG and DATA_USE stuff is taken care of into the SBASIC and the C68 library procedure and functions, NOT into the directory device drivers)... > [Why directory drivers] > > >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. > > This code should have been a thing (for all I know, it is) - anything that > needed those services would then just call it, and it could be changed or > 'evolved' in time. The fact is that when QDOS was written, "things" did not exist at all and when SMSQ(/E) was written, it had to be upward QDOS-compatible... > But what I really wanted to ask is this: is the 16 device limit only a > limit because of the slave block mechanism using limited bits to track > what blocks belong to which device? I will not use slave blocks in my driver (too slow !) and this has nothing to do with them anyway. This is a rather "stupid" limitation in fact: the pointers to device physical definition blocks are held (unlike all other QDOS tables) _into_ the system variables (i.e. there is only room for 16 table entries)... I suppose that when QDOS was written, TT considered that 16 mass storage units would "forever" be "plenty enough"... Many other programmers/computer conceptors made a lot of such wrong assumptions (I am sure I will or already did make some myself in my own software)... Overcomming this limit would involve quite nasty incompatibility issues with old device drivers and/or software... Note that this is somewhat balanced by the fact that you can unlink devices dynamically under SMSQ/E and re-affect device names to other partitions/volumes/sessions... > >> 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... > > Well, not for TRAP #2, which are IO management and should logically also > manage devices
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
Re: [ql-users] Re: Q40/Q60 device drivers
On Mercredi 27 Juin 2001 05:30, Timothy Swenson wrote: > I think the discussion about what format the CD driver should support > is a mute point. Thierry will implement what he can/wants to implement. > We really can only offer suggestions. I will not have enough time to implement all I want to be implemented into the final product before I leave, BUT I will implement at the very least direct sector access (should be working this week or next one), and possibly sector access into a QXL.WIN file in the root directory of an ISO9660 CD-R. > Personally, I'd like to see the CD driver be able to read both QWA and > ISO9660 formated CD's. The definitive and finished product will implement ISO9660 but NOT QWA (note that a QWA "formatted" CD could be read using direct sector access and qxltool though). Joliet extensions are also planned... > It would be nice if the CD driver was written so that additional formats > could be added in with little work.IRIX works like this. It supports > CD's formated in ISO9660, efs, HFS, and so on. The new IRIX tape driver > (TS) is a generic tape driver with personallity daemons. This way support > for additional tape drives can be added without changing the kernel and > just change the personality daemon. It would be nice if the CD driver > could be like this. Are you a mind reader ? This was planned from the very first specs: I will make provision for new filesystems to be linked into the driver. This is easy thanks to the "thing" system... > And I am very interested in looking over the source code, be it in C or > assembly. It's assembly (largely commented but not yet documented)... On Mercredi 27 Juin 2001 06:35, ZN wrote: > Well, I hate to be a party breaker, but guess what: all standard CD file > systems have a deeper directory structure and/or longer names than the QL > is capable of handling with it's 36 character path+name limit. Wrong ! ISO9660 is limited to 32 chars in filenames (path name included) and to 8 levels of sub-directories... > As a result, > it is not possible to implement a directory device driver that would do > anything but direct sector access, or some sort of bodged file access. Wrong again ! By using a small trick, I can make a SMSQ/E (NOT QDOS !) directory device driver to use long filenames. Here is how the trick works: In QDOS/SMS, when an OPEN system call is issued, the IOSS (Input Output Sub System) first extract the device/file name and asks to each non- directory device driver if it recognizes this name as one of its device (+parameters) name, the length of this name is not limited (well it is, but to a bigger number of chars: 127 if the name was not quoted, 32765 if it was). Then, if none of the non-directory device drivers reported a success, the IOSS scans for the directory device drivers device names and if the filename starts with one of them, sets up a new channel header for it, copying only up to 36 chars (after the device name) into the channel header and reporting "bad name" (QDOS) or "not found" (SMSQ/E) if this name is over 36 chars long: thus the "36 chars limit" in current QDOS/SMS directory device drivers... To overcome the 36 chars limit, the only thing you need is to store the long filename somewhere and truncate it to 36 chars so that the IOSS does not complain; the directory device driver will then have to retreive the stored long filename and setup proper variables for it (e.g. a pointer) into the spare bytes of the channel definition block. This can be done easily through a "special" non-directory device driver (also implemented as a thing): as a non-directory one, this device driver will get called during each OPEN call. It will have to check itself for a directory device name into the filename it receives and then, if a registered device name is prefixing this filename, to keep a copy of a pointer to the name (writing this pointer value into the related device driver linkage block), copying the 36 first chars of the filename into an area it owns (typically its own device driver linkage block), and exchanging the pointer to this truncated filename with the pointer to the original filename (this pointer is held in A0 and should never be changed by a non-directory device driver unless it recognizes its own device: this is because A0 is used by all following device drivers and IOSS open routines). The device driver then reports a failure to recognize hhis device (in fact it got no device name at all itself), and the device scanning continues with the truncated filename... When the proper directory device driver is scanned by the IOSS, the IOSS sets up the channel header using the truncated filename and passes the control to the device driver OPEN routine which will find both the truncated filename into the channel header and the pointer to the full filename into its own device linkage block (it will then just have to copy this pointer into the channel header adn performs the appropriate actions IO
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] 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.
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.
[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.
Re: [ql-users] QPC2
On Mardi 05 Juin 2001 00:16, P Witte wrote: > No, I ask because I could not find it at the usual place, Jochen's > BBS. But youre very welcome to mail it to me. Same for me, please ! > Cant say I noticed the announcement of the update? AFAIK it was not announced (checked ql-users, ql-developers and ql-news mailing lists as well as FidoNet/MaussNet areas to no avail)... ;-( QDOS/SMS forever ! Thierry.
Re: [ql-users] QPC2
On Mardi 05 Juin 2001 08:15, I wrote: > Yes, it is on his Webpage at: > > http://www.j-m-s.com/smsq/qpc/qpc.htm#updates I just got it, but alas the zip file is password "protected" (well, zip encryption is rather weak...) ! :-( I don't understand very well why as QPC2 won't work without a proper key file anyway... 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] QPC2
On Lundi 04 Juin 2001 22:44, Marcel Kilgus wrote: [QPC2 v2.01] > Per wrote: > > Oh good. Where does one get it? > > You've never aquired any updates before? By mail, Jochen's BBS, No, it is not on Jochen's BBS (I checked yesterday)... > Jochen's web-page or whatever you prefer, I don't know. Yes, it is on his Webpage at: http://www.j-m-s.com/smsq/qpc/qpc.htm#updates QDOS/SMS forever ! Thierry.
Re: [ql-users] diff
On Samedi 02 Juin 2001 15:28, [EMAIL PROTECTED] wrote: > > Well, I got two binaries on my hard disk: one is named "diff3" (but it is > > just a cut down version of full GNU diff 2.4) and is 38Kb in size. The > > other one is named "diff" (full GNU diff 2.4 implementation) and is 90 Kb > > in size: the later one is Erling's port... > > Can I have them, please? Thanks in advance. OK (sent in a private message). QDOS/SMS forever ! Thierry.
Re: [ql-users] diff
On Samedi 02 Juin 2001 14:59, [EMAIL PROTECTED] wrote : > On Sat, 2 Jun 2001, Dave Walker wrote: > > Yes. > > > > It normally ships on the C68 disks as one of the utilities. However if > > you want I can email you a copy directly. > > Hi! > > I have got me the runtimes disk 3 now, but there's no diff in it (Thierrys > site is the source). The link to C68 on my site is just a link to files on Dave's site. IIRC, the "C68" diff was available as in separate zip file (GNU textutils or something like that). > So I'd be glad if you can send me the diff program. > Thierry, is your diff different? Well, I got two binaries on my hard disk: one is named "diff3" (but it is just a cut down version of full GNU diff 2.4) and is 38Kb in size. The other one is named "diff" (full GNU diff 2.4 implementation) and is 90 Kb in size: the later one is Erling's port... 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] Q40/Q60 in ATX case
On Samedi 12 Mai 2001 22:55, Peter Graf wrote: > Thierry wrote: > >.../... > > >I can confirm this as I just acquired a Q60 from Peter and mounted it > >into an ATX case: no problem at all, no drilling, no fiddling, EASY! > > It is easy, but for a Q40 (or Q60 ;-)) an ATX case really is a waste of > space, unless you use a Micro ATX case. (Those are expensive.) Of course ther is plenty of space in it... The case I got is a "medium tower" one but it can be used horizontally (the 5"1/4 bay may be rotated by 90°): this is what I did... I now have on my main desktop three computers: QLCF BBS (a medium tower with SGC+AURORA+SH+QUBIDE+ROMDISQ+MODEM) on the left, the Q60 in its case with a 17" monitor on top of it in front of my seat, and my main PC (medium tower too) on the right. On my secondary desktop, still sits the Thor XVI, a black box QL and a secondary PC (mini tower)... > >> AT cases are still available and usually cheaper and smaller than ATX > >> cases, so I don't see much reason for using ATX cases for the Q40. > > > >Well, not in France I'm afraid: it's difficult like HELL to get an > >AT case (you may still find some in Paris, but very few models are > >available) ! > > Have you looked for mailorder suppliers? Here in Germany I know several who > sell AT cases. I was to much in a hurry to get my Q60 cased for waiting after a mail order delivery. Besides, I like to see first what I buy... On Dimanche 13 Mai 2001 01:07, Tony Firshman wrote: > >Have you looked for mailorder suppliers? Here in Germany I know several > > who sell AT cases. > > CPC in the UK still do. > I bought one recently for about £20. > They are mail order, but too expensive to France I guess. > > I could bring to the Paris show on October 13th, but that is far too > long in the future I am sure... Thanks, but the case I got is just fine... Moreover in October, I will not be in Paris but in Indian Ocean ! 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] Q40/Q60 in ATX case
Hi happy QLers ! I'm back from a long trip at sea... Expect an (over due) update to my Web site next week. On Samedi 12 Mai 2001 21:32, Peter Graf wrote: > Hi, > > by a QL Today article from Roy Wood, several users have got the wrong > impression the Q40 was not suitable for an ATX case. I had several personal > emails about this, so I think it is time for a public explanation. > > The Q40 is *not* simply an AT mainboard. It directly fits into both AT and > ATX cases. This also applies to the mounting holes. At design time I had > already used both the AT and ATX specifications. I can confirm this as I just acquired a Q60 from Peter and mounted it into an ATX case: no problem at all, no drilling, no fiddling, EASY ! > To use an unmodified Q40 mainboard in an ATX case with ATX power supply you > only need to: > > 1. Connect pin 14 (green) + pin 15 (black) on the main power connector. > > 2. Remove the ATX IO plate. I just replaced the ATX power supply with an old AT one I got... > Instead of simply removing the ATX IO plate, you could also use a Mini-DIN > keyboard adaptor with slot bracket (needs soldering of 4 wires) or an IO > plate with DIN keyboard hole. My ATX case came with interchangeable plates (4) at the rear, one of which was an AT compatible one: the hole for the AT kbd connector was there. > Please note that a Q40 with unmodified system > ROM does not support software power-on/off. So at the moment you need to > use a hardware power switch (eg. the one at the back of the case). > > AT cases are still available and usually cheaper and smaller than ATX > cases, so I don't see much reason for using ATX cases for the Q40. Well, not in France I'm afraid: it's difficult like HELL to get an AT case (you may still find some in Paris, but very few models are available) ! You may find some second hand ones in "PC casse" or such "shops" though. QDOS/SMS forever ! Thierry.
Re: [ql-users] QPC-2 and SERIAL PORTS
On Samedi 13 Janvier 2001 12:58, John Hitchcock wrote: > I now, after *many* frustrating hours (:( wonder if there may be a > connection with Thierrys recent observation viz. - > > There is a bug in SMSQ/E v2.98 for QXL that trigers characters lost > when sending data via serial and parallele port. The work around is > to reduce the serial/parallele buffer to 1 character (PAR_BUFF 1 in > your case) but this is also to say that the maximum speed will drop > down to 2000cps (as with older SMSQ/E version)... > -- > > My system is - > > QPC-2 : v 1.51 > SMSQ/E: v 2a91 (does the 'a' mean 'for QPC' ?, please any one) > sBASIC : v HBA The bug is only present in SMSQ/E v2.98 for QXL. SMSQ/E v2.91 and any non-QXL versions are fine in this respect. QDOS/SMS forever ! Thierry.
[ql-users] Suqcess
Hi ! Wolfgang Uhlig released a trial version of his excellent Suqcess program. This trial version is available on my Web site download page ( http://qdos.cjb.net/english/download.html ) into the "Demo version of commercial software" section. QDOS/SMS forever ! Thierry.
[ql-users] QL history
Below is a message I received and that could be of interest to some QLers (especially those interested into the original black box history): --- Robert Ladyman] Couldn't really see where I could post this information, so I thought = I'd send it to you and you can do what you like with it, before it's = forgotten forever!! I used to own and use QL's and was surprised to find that in my first = programming job, the company that I was working for had seriously = considered porting their commercial database system to it (under an = operating system called UCSD p-System, which their other products were = written in, using Pascal). The company was Blyth Software Ltd and the = product was Omnis (now at version 7 and still going strong, but not on = QLs). They had ported much of the code but were limited by the = reliability of the microdrives, otherwise the QL would have had a = *multiuser* database development system, compatible with PC's and = Macintosh's way back...I doubt if anyone else remembers this so there = you go - in those days there were many operating systems and computer = types. They abandoned the project but about a year after I started, one of the = project managers who was at Sinclair joined us (as my boss) - I got = talking to him and he stated that the original design of the QL had a = 3.5" disk in the right-hand of the case (where the microdrives went = eventually) and that it was the MARKETING department that changed the = sepcification to microdrives, NOT the technical department / hardware = engineers: as a major criticism of the QL was the microdrives, it makes = one wonder what could have been. In the end I bought their 2 QLs (they had two to test networking) and = the USCD p-system disks but eventually they became unreadable. The site is very good and I'm staggered that there is so much interest = still left in the QL - it was, quite frankly, way ahead of its time, = multi-tasking basic on a home PC...Windows has barely caught up - the = latest idea from MS is ".NET" where all programs compile to a standard = object format that is run by an interpretor - which is what USCD = p-System did all those years ago. - QDOS/SMS forever ! Thierry.
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.
Re: [ql-users] Printing on QXL
On Mardi 19 Décembre 2000 12:20, Christopher Cave wrote: > I now use SMSQ/E 2.98 pretty much all of the time on my QXL but when, I > print to 'par', some output is getting lost. This does not happen under > SMSQ 2.57, so I put it down to SMSQ/E. I have tried setting the buffer as > in: > > PAR_BUFF 1024. > > This seems to delay the breakdown. Is the buffer just too small? What size > buffers do others use? Or should it be dynamic as in: > > PAR_BUFF 0? There is a bug in SMSQ/E v2.98 for QXL that trigers characters lost when sending data via serial and parallele port. The work around is to reduce the serial/parallele buffer to 1 character (PAR_BUFF 1 in your case) but this is also to say that the maximum speed will drop down to 2000cps (as with older SMSQ/E version)... This bug was reported (together with some others) to Tony in June, but no bugfix has been issued so far... :-( QDOS/SMS forever ! Thierry.
[ql-users] ql-users & ql-developers mailing list archives
Hi ! As of 31 december 2000, I will cease to archive the ql-users messages on my web site. I registered both ql-users and ql-developpers mailing lists into "The Mail Archive" web service ( http://www.mail-archive.com/ ). ql-users archives are already available from: http://www.mail-archive.com/ql-users%40nvg.ntnu.no/ and ql-developers will be soon (i.e. as soon as new messages will be sent to the list) at: http://www.mail-archive.com/ql-developers%40nvg.ntnu.no/ QDOS/SMS forever ! Thierry.
