Re: [ql-users] c68 guide for one who wants to know.
Neil Riley scripsit:: Dave in your example LRESPR win1_PTH_rext PTH_ADD win1_C68BIN_ PTH_ADD win1_QJUMP_ PTH_ADD win1_SYS_ PROG_USE PTH1_ Id expect DIR PTH1_ to show all objects in C68BIN , QJUMP SYS. In my example i have two directories 48k and 128k ( and they are directories off win1_) so ( and it seems the aren't really necessary ) 10 LRESPR rom1_pth_rext 20 PTH_ADD win1_48k_ 30 PTH_ADD win1_128k_ 40 PROG_USE PTH1_ Id expect dir pth1_ to show all objects in 48K and 128K but it only shows objects in 48K !?! swapping lines 20 and 30 shows only the objects in directory 128k ! Argh ! Neil PTH is not used like that. PTH is good for your binaries' location. When it failed to find the binary in the first directory, it looks on the next, and so on. PROG_USE PTH1_ is fine. DATA_USE PTH1_ is dangerous: opening existing document is fine, but creating new file is a bad idea! Saving is also bad. PTH*_ devices are chained, so dir pth1_ show first directory, dir pth2_ the next... and so on. pth_list might be your friend too. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] For sale at Eindhoven show, 24 march 2007
Hello, just to keep informed everybody interested (I try to reply individually too), and closing this thread, maybe. Packages A B eprom have been sold this week-end. I do not have it any more. (It seems to have created a lot of interest, all from people unable to attend the eindhoven show). I therefore won't travel either to eindhoven, even if packages C, D E, as well as monitor are still mine (weight kind of prohibite postage of them). Have an happy new year (chinese new year, that is). ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] For sale at Eindhoven show, 24 march 2007
I need room... The following packages might be available, if you manifest yourself here or by email, at the coming soon Eindhoven QL show of 24.03.2007: - package A: QL(JS)+SuperHermes+SGC+Miracle 40MB harddisk+modem+twin ED drives+mouse+many hundreds of floppies, including some ED floppy (most are SD, ql format... you sort them!). - package B: Q40 in black box (32MB memory)+HD floppy+2 hard disk+sound system+keyboard(french)+mouse, fitted rom 3.12 SMSQ/E, original SMSQ/E and QDOS classic - package C: Collection of QLWorld (nearly complete, some duplicate, missing some QLissue), and QLToday(the six or seven first years) (as well as the stopped american QL fanzine, and probably some - package D: Canon BJC600 printer (parallel port, colour ink jet, works with esc/p code, Quill compatible), with programmer's book (all the codes). Head might need an alcohol cleanup - package E: Epson LX-800 printer (parralel port, dot-matrix printer, same esc/p, BW), with a set of still sealed rubans, and all paper feeder options (continous roll, cut-sheet stocker (A4) as well as basic hand feed if you do not want). Expected Price (in euros, and cash only, no card, no check): A: 120 € A+B: 150 € C (only if A or A+B): 50€ D: 20 € E: 30 € A+B+C+D+E: 200€ I won't travel for only C/D/E, and B is available only if A is sold too! Optional extras (only if package sold): for package A, you might also have a philips monitor, add 20€. for package B, a set of 8 empty eproms for Q40 (would fit 4 Q40), with an eprom programmers (on parallel port, need MS windows) and eprom eraser, for 100€ (that's not even the tenth of what it cost me, but if package B is sold, I won't need it anymore). If you save me the travel by collecting at Paris early, you can save some money too. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 and DOSx
Marcel Kilgus scripsit:: Bob Spelten wrote: The FLUSH command is not used in Suqcess but I will patch a copy and see if it makes a difference. I somehow doubt that it will help, but bugs can be weird, so who knows. Have you tried enabling the map checksums (WIN_CTRL command)? Marcel Just a wandering question: what are the size of your partition ? (when such bug does occurs) I'm wondering about a limited addressable space of slave block which might collides when a partition is big enough, and disk usage is more than reading a single file. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Platforms OSs (was month number)
Bob Spelten scripsit:: Now A Question. When running SMSQ/E on a QXL in high colour mode, this takes up a lot of extra memory and is very slow in screen operations. The Aurora suffers less from this compared to running in mode 4. Would a QXL mode 256 option give back some memory and speed? If the screen I/O are compressed to be aware of mode 256, I would say yes (passing 1 byte instead of 2 is still a good bandwith's gain, as well as needing less memory for the screen map) But you need the PC-program to be aware of that mode. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q40 and SMSQE v3.12
Marcel Kilgus scripsit:: George Gwilt wrote: This, of course, will not work on the Q40, because it does not have the register PCR. Obviously I am missing something because I could not see anywhere the code preventing this operation from being applied to a 68040. Nope, not missing anything, the code seems to be broken for Q40, looks like a 100% chance for a crash there. Am just not sure what the fact means that nobody noticed it for over halve a year. I broke/change my other computer (PC) with the internet connection a year ago, so I haven't yet downloaded compiled the new smsq/e 3.12 for my Q40. (after compilation, I would have tested it, then program the eeprom with it, but this requires the PC to be working with the eeprom programer, which, until lately was not so... therefore I spare my time and effort even downloading the new sources... hence no test for me of the new version). Now, I would say: fix it (or try to) in 3.13, and I will check it out quickly. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Next Heindoven ?
Hello everybody, May I ask a question: when are planned the next heindoven meeting ? (Just to try to book one of them in my schedule...) Are there any closer (from Paris) meeting ? (and when ?) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] apostrophes
Stephen Usher scripsit:: On Thu, May 25, 2006 at 08:10:56PM +0100, Laurence Reeves wrote: Secondly, how do you go about comparing the number of points on a straight line (uncountable) with the number of computable numbers (countable). Are there less computable numbers than points on a line, or fewer? Ah, but this assumes that space-time doesn't have a finite smallest unit of distance. If there's quantum space and quantum time then the number of points on a straight line will be finite and countable, as would be the time it takes to count them. No, you do not get it. It's not a problem of physics, it's a problem of grammar! The initial problem is that IN ENGLISH countable quantities should be compared with fewer, whereas uncountable quantities should be compared with less. There is less milk in my glass than in yours. There are fewer peas in my dish than in yours. Now, due to some lacks of the educational system (is that english ?), as well as everyone in the world stating that they speak english when in fact they are only able to reproduce the basic scheme of spoken words which might be understandable as english (do not get me going on the write it as you listen it, it starts with nite-club... ends up in some vice-president spellings a vegetable), we have to face the universal incorrect usage of less for everything. There is a difference between: I want less jockey on my horse! and I want fewer jockey on my horse! On the former sentence, there is probably a fat jockey on it. On the latter sentence, there is at least two jockeys on it... poor horse! ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] some QL to collect
Hello, yesterday I got a phone call: a QLer is moving away in fourteen days, and has some QL-related to offer (before trashing all that...). There is 4 QL (2 JM, 2 JS), a FLP-interface from CST, a FDK-interface, a colour monitor, about 100 floppies, some books, and a serial printer. He's currently located in Wattrelos (59/ North of France, near belgium border, suburban of Lille). If you are interested, email me directly, I will give you more details about his address phone. Hurry up, time is going... My email for that issue is: [EMAIL PROTECTED] ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] GST C Compiler
Timothy Swenson wrote: Here is another request for help from the QL Community. I'm trying to track down the status of the GST C compiler. I know that Quanta had aquired it and was selling it around 1995. I've been in contact with Quanta and they no longer have any copies of the compiler and really don't know much about it. I was given a copy many years ago and never really played with it. Recently I pulled it off the shelf and am interested in tinkering with it, but I would like to know if it is now free or not. So, does anybody have a clue about the GST C compiler? Are you sure it was a C compiler ? I remember having used a GST Assembler/linker, but for C I first went along the Metacomco (with Eprom), then C68 lines. That was the only C compiler I know for the QL. (Moreover, I remembered that the GST Assembler was Quanta-deliverable.) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] CTRL ALT left/right
[EMAIL PROTECTED] wrote: I find that with QPC v3.11 that the keys CTRL/ALT with up, down, right, left produce $D3, $DB, $CB, $C3. But perhaps that is just my peivate Keyboard Table. George Which is correct, and this is what it does on my PC at home. I know QPC2 works OK in this respect as long as Windoze lets it get the keypresses. Something is happening in Windows which stops QPC2 detecting these keypresses. Are you using some X11 emulation software ? Most come configured as 'assigning' one or the other ALT/ALTGr to X11 only, hiding it from Windows... if such X11 software is running, that might have effect on QPC2. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
Joachim Van der Auwera wrote: jms1 wrote: Surely the trick is to check whether the directory is type 5. If so treat it like a new directory and file naming. If not treat it like a type 255 directory. Careful with file types. Some have been used in the old days. I am sure we used file types for some grpahics files in The PAINTER. There were some other programs using file types as well. However, I think 254 (aka -2) would be possible. If you change the filesystem (on the partition of the harddisk), you can safely reuse type -1. There is no need for yet another file type. Hint: we are missing a repository database for file type usage... ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
P Witte wrote: Marcel Kilgus writes: Just an unrelated note to the DOS long-filename-hack: They had to do this because a single file name was limited to only 8 characters. We have 36 characters to work with, which is much less of a burden. So I don't see the need for something similar. But they had a greater directory depth, I seem to recall. Depth, yes, wide, not at all. The number of entries in the root directory is really limited on DOS... especially with LFN! (The limitation is not so true for non-root directory) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL filename length revisited
[EMAIL PROTECTED] wrote: In a message dated 12/01/05 06:08:07 GMT Standard Time, [EMAIL PROTECTED] writes: I have a question here. Currently, the way directories are handled is by making a directory a somewhat special file (file type -1, IIRC). Apart from that, though,a directory ia a simple file that can be accessed more or less like any file. Directories contain an entry per file referenced in that directory. Part of the entry is the filename of the file. However, and that is where the original designers made a design decision we all regret today, this filename is the ENTIRE name of the file, (minus the device name). Example: you have a file called win1_subdir1_subdir2_subdir3_myfile The filename as contained in the entry in subdir3_ for this file will be: subdir1_subdir2_subdir3_myfile. As you can see, we are quickly getting to the 36 chars limit since that is the most space a filename can take in the directory file entry. Wouldn't the most simple way to get around the name length limitation be that each directory holds only the filename itself? Of course, each name on each directory level would still be limited to 36 chars, but something like: win1_verylongsubdirname1_verylongsubdirname2_verylongsubdirnam e3_verylongsubdirname4_verylongsubdirname5_prettylongfilename would be possible. Perhaps the directory should be a new file type (-5 ot whatever) to show that this is a new type of directory. Why not. It seems to make sense to me. Legacy applications wouldn't work in this scheme. But, let's face it, whatever the scheme you are going to implement, they won't work (one, because the finale filemane will be too long anyway, two because they can't access new directories anyway). We could even do better. We have two kind of filesystem: the floppy and the harddisk. Maintaining floppy compatibility is essential. If we could store the EXEC information on DOS format, things would be simple, and I would push for the DOS format, not because it is DOS, but because it is so wide spread. So far, let's keep the QL floppy format. (We could also devise a new QL5C floppy format, but only updated system could read it, so that's not so useful.) BUT, the harddisk does not need to be exchanged with another system. Therefore, we can do as we want on a harddisk partition. As long as we are able to copy the harddisk file to the floppy, who care how the file is stored on the harddisk. The filenaming issue can easily been dealed with by the user at copy time. I had the impression that directories in QDOS were notional, not real. That is, each file, with its full name, exists on the medium whether or not a directory has been made. Thus, if win1_op_f1 and win1_op_f2 are two files on win1_ they will immediately appear in a directory if win1_op is made a directory by make_dir win1_op. The original files are totally unchanged, but a new file with type 255 (or -1) and name win1_op is added to win1. This has the effect, through software, of all files with names starting win1_op_ being treated as though they were in a directory called win1_op. Correct. The filename is stored at the beginning of the file itself, in the first sector given by the index. I currently assume that make_dir, when creating the directory either: - refuse the creation if somefile already exists - move the mapping entries from the current directory (/root directory or an already existing directory) to the new directory. Now, the problem is that the stored information at the beginning of the file is not the filename, but the pathname (the device part being removed anyway). That why I always think that a full pathname (device included) can be longer that 41 char: win1_+36 char = 41, but n1_dev1_+36 is already bigger! If we could simply change the make_dir routine, as well as the name building code (you have to remember which directories you went through), the system could very well provide an unlimited pathname (well, at worst, a 32767-char pathname... with at least a directory every 36 char) But then we could as well force a directory separator, to ease parsing as well as other things: what about a real '/' ? The obvious problem with / is that simple expression like win1_eort/ekr must be put inside quote to avoid floating evaluation by the basic. SAVE win1_eort/ekr, I can live with that! A note for any filesystem designer: the partition size is currently limited to a, by today standard, very small size. If we could avoid to resort to big chunk, that would be very good. (give us back a 512 sector allocation unit, please!) (What about a 32 bits indexing instead of the limited one we have today: 32 bits of 512 bytes sectors should be big enough for a single partition, that's about 4 TBytes) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Eprom Programmer
Marcel Kilgus wrote: Wolfgang Lenerz wrote: Does anybody know what kind of Eprom programmer would be suitable? Any eprom programmer able to handle 27C1024 ! (DIP 40 format, beware of cheap programmer which are a few bit short!) Wolfgang, I can offer you the programming of eproms if you want. (as well as erasing programmed eproms too!) Last year (or was it two year ago ?), I got chipmax (web site: www.seeit.fr , internet explorer only site!), which work on the parallele port and W98. Other model exist for USB. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] good superbasic book?
David Tubbs wrote: At 16:56 27/12/2004 +0100, you wrote: David Tubbs wrote: http://dilwynjones.topcities.com/qldocs/qpckeywords.zip Nice one, danke ! Just spotted 'FLP_STEP' entry is present twice, but I'm guessing the first one should be read 'FLP_STOP'. You're welcome. By the way, is anybody who knows how to do text processing right up to the task of re-formatting that document? And with right I mean properly defined paragraph and character styles instead of manual formatting, no formatting by multiple spaces, empty lines and manual page breaks and also things like that the index should be auto-generated and not manually maintained. I would go along using Lyx, but designing the right model document in latex is going to be an extensive work. Then importing the full text, and then painting the styles everywhere is a mouseclick game... a long game. If you really want to achieve the same look, you have a long way to go for the model. The stopping part: Lyx does not know of user-defined character formatting, at best you can have a Noun style, a emphasied style and the normal style. I was thinking on slightly different lines, either an html or spreadsheet. Facility to search and sort, easy cut+paste, rather than a pretty printable picture. Making a database out of it might be simpler, but the inserted tables of the text might need to be reconsidered. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Trump Cards and FORMAT
P Witte wrote: Phoebus Dokos writes: However in all truth, there is a GREAT SMSQ/e partition tools only it doesn't run under SMSQ/e... it runs under Linux (atari-fdisk) and it's worth to boot a ram-based linux only for atari-fdisk :-) Is there any reason why it could not be ported to Qdos/Smsq? If you are looking for a partition program for a Q40/Q60 that run on SMSQ/E, I might very well provide you with mine: it's PE and allow up to 12 partitions on first sector (standard partition scheme). In fact, it's just a half-cooked partition sector editor. You could even have more partition by using more than sector 0 (but that's by hand, you have to know how to link additional partition in Extended partition.) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Trump Cards and FORMAT
Roy wood wrote: In message [EMAIL PROTECTED], ZN [EMAIL PROTECTED] writes The major part is more radical. It is high time that hard drive partitions and formats be unified on QL platforms, and in fact, it is only Qubide that does not directly conform to the norm. It should be possible (indeed, it should not be much work) to convert the SMSQ/E win drivers for Qx0 to run on Qubide hardware. The problem here is the lack of utilities. Qubide's format and partition utilities are, to my knowledge, far more than is available to the Qx0 user. Adding a partition might be less useful than supporting large drives and leaving the separation down to Sub Directories. I say this thinking of the limitations on 8 devices. 8 devices, yes, that's the first limit. Then there is that 16 devices limit in the kernel tables... at least, 8 devices limit is only: 8 mounted partitions at the same time. With a suitable partition program, big drives could be split in small slices, and a small PE utility which would allow to switch from the list of possible partitions to the list of actual mounted partition would make life easier in such configuration. The biggest trouble so far is big partition. I have seen trouble with the caching facility whenever the partition is big enough (and filled enough), probably a collision on the indexing mechanism. It was made for small removable drive (microdrive, ramdisk, floppies), not for a huge filesystem. Partition smaller than 128MB are safe. Bigger than 512MB are not... Mind you that takes us back to the old Long Name argument. I must admit my views on that have changed over the last few years - since we last had the discussion and I feel that we should be prepared to make that major jump into new directory structure. It would leave many older programs out in the cold but I suppose you could, as you suggest, always use the partitions in different modes in the same way that windows will handle FAT32 and NTFS on the same machine. This would take someone far more competent than me to work out though and, as you say someone who can write that kind of driver code. And then come the dreadful question: should we reinvent the wheel (... a filesystem) or adapt to an existing one (and which one ? and why ?) Fat32 and NTFS fan beware: we are still going to run into the Motorola/Intel bytes ordering issue. Not a good thing at all. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] locking a window?
James Hunkins wrote: I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Of two things, one or the other: - if you are considering a subwindow like a dropdown menus, then it should, as a secondary, fit inside the primary. May be the primary is too small to allow that, or your secondary might enjoy some sliding bars to fit ? (or any other trick that would reduce the needed space). Secondary that falls outside of primary are not a good idea (it's impossible so far with PTR, and I believe it's a good thing.) If the secondary need more room than the primary, you have a design problem. (nevertheless, being able to move a secondary might be a good idea, so remember to allow such icon and action in your secondaries). - if the sub-window is an independant application, why do you want to lock down the primary at all ? If the primary is visible, then, as a user, I'm expecting to be able to use it. (Even if the sub-application is running). Do not enter the fascist dialog-mode with a user. Rather than denying it access to a visible locked application, hide the application. If the user cannot see it, he cannot use it! Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: By the way, this mechanism is only being used when a particular sub-program is called and the calling window needs to be locked. Examples programs that need windows larger than the caller's window [drop-down menus, File and List selects, etc] and programs that will be directly changing something in the calling program so we would want to lock the calling program out [IconDraw for notebooks which will change the notebook's icon, Add Objects for folders, and notebooks for folders or Icons]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] use of new system sprites from C68?
James Hunkins wrote: Jerome, Since no one else has jumped in with help on this yet, would you mind digging through for a sample of your 'C' code showing the proper use of the new system sprites. It would really help me a lot. Ok. You will have to wait till monday, but just be patient... ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] use of new system sprites from C68?
James Hunkins wrote: Has anyone used the new system sprites from C68? This would be using it in the window definition which was originally a pointer to a sprite file. I have tried it by defining 2 bytes such as: unsigned short test_sprite = 0x0008;[ byte 0 = 0x00 for a system sprite 0x08 for the sprite number ] and then doing a pointer to its address from the proper loose item field: test_sprite, If I point to one of the normal sprites (with byte 0 = 0x01) I get the expected sprite. But when I do the above all I get is a red 'X' sprite, no matter what sprite number I use. Any ideas? If someone has used the new system sprites, could you supply sample code and instructions? I think I did use the system sprite from C68. I used an array of char instead of a short... It did work, or so I believe. I would have to dig that code if you do not get a better answer. ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] WIN drives
Dilwyn Jones wrote: Is the facility to have WIN1 to WIN8 redefinable limted to QPC2 or does it exist on QXL, QemuLator, UQLx etc (systems handling QXL.WIN)? It is also available to Q40. From old memory, QXL use [letter]:\QXL.WIN with letter starting at C for win1. If you can create subdrive (was possible with 3.11, seems to have disappears with latter version), and you have less than 8 partitions, you can in theory redefine at least win8! ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] QPC2 vs Word 97
Dilwyn Jones wrote: QPC is a CPU cycle hog, but it seems to share with other programs willingly enough. The only thing that slows QPC to a crawl on my system is the Epson printer driver: When I print from Word or other PC programs, QPC is unusable. The Epson printer driver does tend to swamp other applications, but that's a general issue. This problem of mine is limited to QPC2 and Word. If I use another PC program to do pretty much the same thing alongside Word, the problem doesn't occur. Nor does it with QemuLator demo, which is the really interesting part, since QemuLator demo is speed restricted anyway so you'd expect it to be unusable but theres no perceptible change! Disable all background operation in Word/Option: in particular repaginate, saving, printing... And of course, disable the Find Fast hungry process. That may help a little. ___ QL-Users Mailing List
Re: [ql-users] QSI
Davide Santachiara wrote: Just for curiosity I had the chance to run QSI with QPC on a P4 3200 Mhz with extra fast ram and it's actually slower than my Athlon 2600+ (2562 vs 2733 - i.e. 27,33 times faster than a GC). Maybe QPC is optimised for AMD processors? Nope, at least I do not think so. P4 is just awfully slow when compared to AMD, on a Hz-for-Hz comparaison. And it is even worst for legacy code (old x86 code, like QPC is). Only time P4 might be good is for P4-optimised code (which is damn rare, as long as you expect to be able to still run on thing like a P3). And even then, only with heavy use of the SSE2. (do not ask for Floating point calculation on double precision...) Perfect for playing WMedia, but that might be all it is good for! Even slower Xeons are better than fastest P4! Comparing CPU with bicycles, P4 has a small drive and a big rear-wheel gear. You can be impressed by the pedaling speed, but others go quicker with a smaller pedaling speed! Side note: P4 MUST (per Intel request) be temperatur-monitored with variable speed fan... I'm not even sure they do not reduce speed when too hot without telling you. So, even if it's uphill and against the wind, P4 might not even be the good choice. ___ QL-Users Mailing List
