Re: [ql-users] SMSQ Source styleguide
On 10 Jul 2002, at 0:18, Jochen Merz wrote: > > Dear Derek, Tim, Dave, Rich, > > a combined reply to the four mails from you. > > I like the idea of putting a bundle together like you suggested, > but > > - in no way I'd bundle it with the SMSQ/E sources (the license). See my other email. It is possible., but you would be distributing an unofficial version. > - what sort of accusations would Wolfgang or myself would have > to look forward to after the discussions which took place here > for the last few months? You do not need much imagination, do > you? I, for example, could earn the fortune which I don't get > by selling SMSQ/E now by selling thousands QMAKEs instead. > Wolfgang could be accused of being biased, making a profit > there by making sure QMAKE has to be used or whatever. Two replies here 1 Wanyway, whatever I'll do, I'll be accused of being biased. I can see that now - and am NOT getting used to it. 2 - really, I don't think that I'd be biased - I've given another MAKE away here. That is compatible and can be used. If you prefer QMAKE, go ahead and buy it. No problem. > Many mails and accusations were unreasonable, so why should it > be more reasonable now? No, I fear it would probably get the > whole thing going again. So let's be reasonable now, all of us , myself included, OK? > I am so glad that QMAKE is not essential for assembling SMSQ/E's > sources. It sure helps a lot to have it, makes it fast and convenient, > and you may have to re-write the link files (but you can hardly expect > Tony to do it for free) but - and that's important, QMAKE is not > essential. QMAC and QLINK are a different matter, but that does not > touch me, fortunately. Even Qlink isn'tn because you can use Tony's linker that I sent to this list. So, the only tool you really need is QMAC. C'me on, this is what TT used - do you really expect us to rewrite the sources if anybody doesn't feel like buying it? (...) > In addition, there are other problems like: > To put a bundle together, QMAC is probably not a big problem, > I could buy it from Quanta, but QMON is. I don't hold the > right to sell new copies of the English QMON, nor does Tony. > I can sell new German QMONs, and I can sell upgrades from > QMON to QMON&JOMN, both German and English. > But a "fresh" English QMON - sorry, impossible. Well, that isn't an "essential" tool to compile the sources. It is an essential tool if you want to do some debugging. And anyway, can't you sell a German Qmon with an english manual? (...) > Then, as I said, next step when Bernd is back from his holidays, > I'll spend some time making sure the QMAKE manual is up-to-date > as I have two potential customer. :-)) Woah, riches at last! Wolfgang
Re: [ql-users] SMSQ Source upgrading, & assembling.
On 8 Jul 2002, at 23:55, John Sadler wrote: > > Are we in danger of restricting SMSQE to be assembled with Qmac > restricting ourselves to 68000 code, casting aside all those QLers who > have invested in a Super Gold Card, QXL, Q40 or Q60? Let's try to be reasonable here. Up until now, development of the sources - ALL OF THEM - was done with the system as described in the style guide. In my mind, it is essential that, at least for the time being, we keep that system: if we change tools and sources at the same time, the complexity will just go up. > You are not going > to be able to do some serious number crunching if you are not >going to use the floating point extensions. > You are not going to stop the QL > crashing without using the memory management unit of the 68030+ chips > and instruction set. Oh, come on, that's just not true, and you (should) know it. To take a (bad) example, Windows uses the mem prot, and still manages to crash irretrievably, and i can be trashed by an application. I do agree that using memory protection would be a good idea. Howevern before you do even think about implementing it, have a good look at the source code, and see all of the problems that go with it. Draw a road map of all of the changes that will have to be made etc... > Gwass is the only assembler which can cope with > 68020+ and floating point instructions. Correct. However, please remember one thing: SMSQ/E also runs on machines that don't have a 68020+ (Gold card, Ataris, QPC come to mind). I have sufficiently stated here that I want coherent versions... which doesn(t mean that, e.g. the Q60, shouldn't be able to use native facilities. > Furthermore Gwass is > maintained and can be extended and corrected as required, whereas Qmac > is not and you are going to have to put up with its errors and > restrictions. George has offered to convert the macros. What better > offer could you have? Change GWASS ? > If you are not going to use these features there does not seem much > point in upgrading SMSQE. Just treat the QL like a crystal radio. > Something to nostalgically recall the pioneering days of computing, or > leave to the local museum to be looked at by our grandchildren. Facetiousness put aside, I'm pretty sure that we'll be able to find a modus vivendi that will allow us to move forward. If things really needing a 68020+ instruction set really come out, there is always a possibility of making it into modules. Even if I wanted to be really strict about the QMAC compatibility, ways could be found (off the top of my head, use DC.W instructions, for example). Wolfgang
Re: [ql-users] SMSQ Source...
On 9 Jul 2002, at 11:19, [EMAIL PROTECTED] wrote:
> I assume you mean that you would like GWASS to be altered so that the
> Qmac macros would work without any change.
yes.
> There are various reasons
> why this wouldn't be easy or indeed possible.
>
> For example the conditional instructions in GWASS are global - not
> confined to macros as I believe the Qmac ones are. You also need an
> "endif" in GWASS.
>
> Also setnum and setstrg of Qmac set numbers and strings inside a
> macro. GWASS's "set" is again global. It can be used anywhere in a
> program to set a variable of whatever sort and to reset it later.
I see, that really seems to be quite a problem.
> A third problem would be strings. In GWASS a string may be delimited
> either by apostrophes (') or by quotes ("). Only the former are
> allowed in Qmac.
Well, that wouldn't be such a problem then, since GWASS could
do "more" than QMAC, and the "subset" used by Qmac would be
OK with it.
> Anyway, what is so bad with a set of GWASS-type macros to replace the
> Qmac ones provided the USER of these macros can code them in almost
> exactly the same way as for Qmac?
Simple: you have to change much of the code.
For the time being, I'd prefer not to chage the code, until we get a
much better understanding of it, can compile it correctly, and are
certain about the total effects of all of the macros.
I tend to think that if I have to choose between changing a lot in
source codes, and changing a tool, changing the tool is generally
the better option.
(this is not intended as any kind of comment on GWASS's
possibilities and functions!)
Wolfgang
Re: [ql-users] SMSQ Source styleguide
On 9 Jul 2002, at 15:17, [EMAIL PROTECTED] wrote: > Or, better still, Wolfgang could offer three versions of the source > code CD... Sorry to disappoint you guys, but I don't intend to become a software (re)seller... I'd have to handle payments to Jochen, Quanta etc (nd I don't even know whether Quanta sells QMAC or gives it away as soon as you become a member) What I could do, to be of service, would be to send CDs out wiht these tools on it , if I were notified by JM and Quanta that peple have paid their dues to them, and asked for these tools to be sent out... Wolfgang
Re: [ql-users] SMSQ Source styleguide
On 9 Jul 2002, at 12:31, Timothy Swenson wrote: > > A > Actually, I would probably work better if Jochen took the SMSQ/E > source code, added the commercial programs to the CD and sold it. (...) No, he certainly can't sell the source code! He is, however, entitled to distribute it for free... If this happens to be on the same CD he sells wiht somethin on it, the terms of the licence would be fulfilled. However, the version thus distributed would be an unofficial version. Wolfgang
Re: [ql-users] SMSQ Source upgrading, & assembling.
On 9 Jul 2002, at 15:57, [EMAIL PROTECTED] wrote: > The problem is based upon the fact that QPC does not support anything > after 68000 instruction set, therefore GWASS does not work on it. I do > not know the percentages of developers working on the different QL > implementations, but understand that a fair few of those who will work > on SMSQ/E use QPC. Probably most of the SMSQ/E users. > BTW Which chip set does QXL use?? I think even that is 68020 - am I > correct Roy?? No, 68040 > This remains a problem as both QPC and the Gold Card cannot support > the 68020 instruction set and yet both allow SMSQ/E. Let's not forget the Ataris. > Perhaps the > safest is to rely on Qmac to assemble the core of SMSQ/E and use GWASS > to compile specific modules which rely on the 68020+ instruction set. Yes, that's a possibility. Wolfgang
Re: [ql-users] QPC and ports
On 10/07/02 at 00:41 Marcel Kilgus wrote: >ZN wrote: >> Yes, but that is for the periodic interrupt only. Once other IO >> interrupts get going, it can get quite hectic - for instance, 16kHz >> for HD floppy access. >Hm, you're sure that's the case on PC hardware? Because then the >internal registers of my processor must be tricking me (the one that >counts interrupts at least)... according to them one can't even tell >whether a floppy disc access is currently in progress: next to no >additional interrupts. Well, there is one interrupt every sector (or even cluster, not sure) when DMA is used for FDC access, vs an interrupt on average every 8-12 bytes if PIO is used. Granted, DMA has advantages, but given a fixed number of hardware DMAs it's rather difficult to have them as a generally available system resource - the same philosophy is true for interrupts on a PC. Because DMA can be so useful, but tends to be so scarce (and if hardware is used, tends to require special connection between peripheral and DMA controller, one per peripheral!), is the reason for the 2nd CPU on GF. Essentially, when a second CPU is fitted, it really only gets the poll, level 7 and first cpu interrupts to deal with, in reality it will probably only deal with the first and very occasionally with the last. This CPU then really runs the OS, the original one, that has all the interrupts generated by IO devices routed to it, then becomes an 'IO CPU' of sorts. Making that into a sort of very intelligent DMA is just the start, but in essence, it completely unburdens the second CPU, much like DMA does. The big difference is, of course, that one may use it to, say, refresh the screen from burried windows, etc, whereas DMA is simply to primitive for this. >> Curiously, the floppy controller also alowes a so called 'tape' >> data rate od 2Mb/s (250kB/s) - what comes after ED? - which makes >> this calculation doubly worse. > >I had some QIC streamer that was attached to the floppy channel. >Didn't get anywhere near 2MB/s though ;-) That would be 2M _bits_. So, 256k bytes /s, but this depends on the tape drive and tape - they have density ratings too. Of course, since many of them can also vary the speed of the tape, one can always use lower speed and lower data rate, to maintain capacity, but slow down the whole thing (this is very often done in compression mode to keep up with the software - and most of it is really from 286 days or before that even). >> Now, you are the master of all things PC, but I have a measurement system >> here that uses it and IIRC the primary data rate of directsound is, >> whenever possible, 48kHz (there are actually good reasons for that, to do >> with sound and picture synch). > >Actually the default DirectSound data rate is (at least according to >"Inside DirectX" from MSPress) 22050Hz, stereo, 8 bit. A quick >experiment confirms this (DX3, NT). This was meant to be somewhat the >least common capabilities. Therefore most applications will try to >alter it, usually to 44100Hz, 16bit. Don't remember having a single >application that uses 48kHz. Yes, I looked it up - obviously a case of mixed up pointers in my memory :-) it is the sound chips that default to 48kHz, including AC97 codecs, software is then used to resample (badly!). >> Most current cards actually resample (badly!) from 44.1 to 48 - I >> know this precisely because I have problems with measurements, >> getting spurious harmonics from the bad conversion process. >That's an AC97 codec then, isn't it? Real sound cards shouldn't do >this ;-) No, it's a common problem. In fact, many much revered cards use a DSP front end (or application speciffic DSP) only to then drive an AC97 CODEC chip as the analog portion. In my case, it's a SB Live (granted, not the greatest, but decent), and it internally works at a fixed 48kHz. It does some fuzzy math to resample from or to 44.1 (of course, they don't call it a cheat, they call it 'proprietary technology', ha ha). To get back on topic: an AD1816 was chosen because AD knows how to do audio AD and DA. They also know how to do ASRC (asynchronous sample rate conversion) and they used to have a really high-spec chip for the PC, but that was a long time ago and it was ISA based. Needless to say, it has been obsoleted and not even the surplus people have it because it used to be high end and expensive. Funnily enough, with the proliferation of home theater and multichannel audio, the number of 'standard' sample rates has become so high that now one can get a decent ASRC chip for about $7 or so. Can't turn back the clock, unfortunately :-( >> Exclusive as the simples implementation - alowing combining of >> multiple streams would add considerable overhead. > >At least that's something QPC could do without much problems if the >device is just a wrapper for a DirectSound buffer. All done >automatically (even different sampling rates), very convenient. Yes, though as I said, it does not really get things rig
Re: [ql-users] QPC and ports
ZN wrote: > Yes, but that is for the periodic interrupt only. Once other IO interrupts > get going, it can get quite hectic - for instance, 16kHz for HD floppy > access. Hm, you're sure that's the case on PC hardware? Because then the internal registers of my processor must be tricking me (the one that counts interrupts at least)... according to them one can't even tell whether a floppy disc access is currently in progress: next to no additional interrupts. > The one problem here is the floppy controller. At ED data rates, the byte > rate is 125kB/s, which means the 16 byte FIFO would exhaust in 128uS, > corresponding to a data rate of 7812.5Hz. Curiously, the floppy controller > also alowes a so called 'tape' data rate od 2Mb/s (250kB/s) - what comes > after ED? - which makes this calculation doubly worse. I had some QIC streamer that was attached to the floppy channel. Didn't get anywhere near 2MB/s though ;-) > I think you should use the garbage in - garbage out principle here, the > best you could do is having a minimum FIFO depth before you go into a loop > buffer. Probably the best way to do it, true. > If the app is not quick enough, it will loop back into old samples - > and produce dreadful noise. But if the app is not quick enough, > there is hardly any way to avoid that in teh first place! Well, on Q40 this is no problem because when its software FIFO is empty the current output value is just held, i.e. if the software is slightly slower there's a decrease in frequency but depending on how much difference there is it might not be noticeable. The equivalent would be to always fill the whole ring buffer up with the last written value to maintain the output level. Not an idea I really like. > Now, you are the master of all things PC, but I have a measurement system > here that uses it and IIRC the primary data rate of directsound is, > whenever possible, 48kHz (there are actually good reasons for that, to do > with sound and picture synch). Actually the default DirectSound data rate is (at least according to "Inside DirectX" from MSPress) 22050Hz, stereo, 8 bit. A quick experiment confirms this (DX3, NT). This was meant to be somewhat the least common capabilities. Therefore most applications will try to alter it, usually to 44100Hz, 16bit. Don't remember having a single application that uses 48kHz. > Most current cards actually resample (badly!) from 44.1 to 48 - I > know this precisely because I have problems with measurements, > getting spurious harmonics from the bad conversion process. That's an AC97 codec then, isn't it? Real sound cards shouldn't do this ;-) > The software resampling is even worse, but usually not as bad as > the cheap sound chips :-) Anyone involved in audio will tell you that > resampling is no easy matter. No need to tell me that... > As someone involved in audio electronics, my advice would be to run the > system at it's default rate, whatever it is (hopefully 48k). IIRC the > resolution of the Q40/60 is 8 bits and as bad as the rate conversion may > be, essentially what you will be doing is putting the 8 bits of a sample > into the MSB of a 16 bit sample, before it gets converted. There are 8 bits > of LSB for the resample algorithm to 'muddle up' before it spoils the > original sample. The only problem is if the conversion produces harmonics > with some order to them. You can avoid this by dithering the 8-bit sampel > into 16 bits before giving it over to directsound (contact me off list for > ideas on how to do this). The whole idea behind the resampling being rather > primitive, is that most sound chips have effectively 12-13 bits of > resolution anyway. OK, I might have a look at the details when I again play around with that whole sound stuff. Personal problems and a nice commission for designing some industrial software make it hard to spent much time on it right now. > As long as the device is exclusive - or at least semi-exclusive, it > should not be a huge problem, I think. Right, probably not. Just measured that a simple device can have more than 1MB/s of throughput on my PC, so that should be ok. > Exclusive as the simples implementation - alowing combining of > multiple streams would add considerable overhead. At least that's something QPC could do without much problems if the device is just a wrapper for a DirectSound buffer. All done automatically (even different sampling rates), very convenient. >> I strongly discourage any messing around with the _PAL >> palette. If Jim needs an own palette for icon drawing then there's no >> problem at all to implement this internally and use 24bit draw calls >> for it. > Realistically, how many programs rely on the asignemnts in the _PAL? None I know of. Anway the palette is only something one needs on palette based systems. All else can simply use the true colour definition and don't need to bother with the palette. > Ah, the 'since the mountain won't come to Muhammed, Mugammed has to go to >
Re: [ql-users] SMSQ Source styleguide
Dear Derek, Tim, Dave, Rich, a combined reply to the four mails from you. I like the idea of putting a bundle together like you suggested, but - in no way I'd bundle it with the SMSQ/E sources (the license). - what sort of accusations would Wolfgang or myself would have to look forward to after the discussions which took place here for the last few months? You do not need much imagination, do you? I, for example, could earn the fortune which I don't get by selling SMSQ/E now by selling thousands QMAKEs instead. Wolfgang could be accused of being biased, making a profit there by making sure QMAKE has to be used or whatever. Many mails and accusations were unreasonable, so why should it be more reasonable now? No, I fear it would probably get the whole thing going again. I am so glad that QMAKE is not essential for assembling SMSQ/E's sources. It sure helps a lot to have it, makes it fast and convenient, and you may have to re-write the link files (but you can hardly expect Tony to do it for free) but - and that's important, QMAKE is not essential. QMAC and QLINK are a different matter, but that does not touch me, fortunately. Honestly, I'm glad that the discussion is over, and I do prefer to have the SMSQ/E source stuff etc. separate from commercial issues. I may be a bit touchy on this subject, and reading Marcels last reply I can see it there too, but I'm sorry, we have a clear solution here, so at least I (and probably Marcel too) hopes that we can leave things the way they are not to complicate matters again. Maybe we could have come up with a nicer solution, a bundle for SMSQ/E, like the agreement I have with D&D for the Q60 software bundle, which would take into account that some people have something, but I'm afraid, I feel that's impossible now after what has happened. In addition, there are other problems like: To put a bundle together, QMAC is probably not a big problem, I could buy it from Quanta, but QMON is. I don't hold the right to sell new copies of the English QMON, nor does Tony. I can sell new German QMONs, and I can sell upgrades from QMON to QMON&JOMN, both German and English. But a "fresh" English QMON - sorry, impossible. I shall re-consider the bundle - it could be useful in general, especially with the Ref. Manual like Rich suggested... and maybe something can be done about QMON. I will speak to Tony about it. ... but first I need some time getting the next QL Today issue done. Then, as I said, next step when Bernd is back from his holidays, I'll spend some time making sure the QMAKE manual is up-to-date as I have two potential customer. :-)) Cheers Jochen
[ql-users] re QL Service Manual
Folks, very sorry for not pointing out the size of the book. I found it whilst at work with a fat pipe and did not notice how big it was. Hope your father finds lots of other stuff in that book which will keep him occupired. Good luck Michael __ D O T E A S Y - "Join the web hosting revolution!" http://www.doteasy.com
Re: [ql-users] SMSQ Source upgrading, & assembling.
John Sadler wrote: > You are not going to be able to do some serious number crunching if > you are not going to use the floating point extensions. Then built a separate serious number chrunching module. What's there to stop you? > You are not going to stop the QL crashing without using the memory > management unit of the 68030+ chips and instruction set. I'd certainly like to see how you'll do any memory protection in SMSQ/E without breaking 90% of the applications. Anyway, something that needs an MMU can use an MMU, just not in any part of the code that is common to ALL platforms (that's at least Atari, GC, SGC, QXL, QPC and Qx0). Is this so difficult? > Furthermore Gwass is maintained and can be extended and corrected as > required, whereas Qmac is not and you are going to have to put up > with its errors and restrictions. What errors? Give me one example please. And why not contact Quanta, perhaps they're giving it away now if approached, who knows? > George has offered to convert the macros. What better offer could > you have? I have no problem with providing the macros alongside of the main distribution as long as the distribution itself stays QMAC compatible. But like it or not, I'm currently your main developer for SMSQ/E. And I don't even have a platform to run GWASS on! See any problem there? Well, I do! But if you want to take over my developments, fine, go ahead! I can provide you with all sources you need, just say the word! I have enough non-QL related stuff to do, I certainly won't get bored. Marcel
Re: [ql-users] Monitor connections
Tony Firshman wrote: > On Tue, 9 Jul 2002 at 03:30:56, Alan Tyson wrote: > (ref: <001b01c226f0$a81a5620$3a51883e@alantyso>) > >>My 86-yr-old father in S.Wales (I'm near Chester) acquired a >>s/h QL about 10yrs ago, which has kept him well amused. He >>used a selection from his many ancient TVs as monitors until >>recently, when the last old wreck died, despite much >>tinkering. His interest has been revitalised by a double >>cataract operation, so now he can see what he's doing. >> >>A kindly neighbour has given him an old monitor with a 7-pin >>DIN socket on the back. Its manufacturer is "St Bernadette, >>Made in Singapore". We don't even know if it's monochrome or >>colour. >> > Google search found 'St Bernadette' school who 'monitor staff' (8-)# > > ie found nothing on the web. > > Any more details like model ID? > >>My Dad tells me there's a 7-pin DIN socket on the back of >>the QL, I'd better check that again...AFAIK all QLs have a 8-pin DIN. Here you have to be VERY careful. Sinclair assigned BLUE to the centre pin, but some/a lot of TV manufacturers who also put an 8-pin DIN on their equipment assigned +ve to this pin. The result being that putting the connecting cable in the wrong way round could cause the QL to be fried. [One cable supplier for the QL always supplied 8-pin for the QL end and 7-pin for the TV end.] > and the QL web site tells me there's RGB and >>composite video output. A former colleague who dealt with >>the audiovisuals where we both worked tells me it's quite >>likely that either a straight-through or a crossover 7-pin >>DIN plug to 7-pin DIN plug lead might miraculously work >>(courtesy of St Bernadette). CPC claim to supply such >>(straight-through) leads for 1.02 ukpounds, but whether >>they'll sell me a single one at a reasonable price I don't >>know. >> >>What do list members think? Can anyone provide me with a >>pinout diagram for the RGB or composite video QL outputs? The QL uses an 8-Pin DIN (circular, not offset) connector, as viewed from outside the QL/solder side of plug: --- / 7 ^ 6 \ ^ = locating notch / 3 1 \ |8|1-8 = Numbered pins \ 5 4 / \ 2 / --- However, there appears to [possibly] be a mistake in the manual, as the pin functions were given in 'QL world' (May 1987) differently: Pin Manual QL World 1 Composite PAL Monocrome (b/w) video 2 GroundGround 3 Composite Monocrome PAL colour video 4 Composite SyncComposite Sync 5 Vertical Sync [No connection] 6 Green Green 7 Red Red 8 Blue Blue The main difference being that Black/White and Colour composites are swapped and Vertical sync doesn't actually do anything. > Do >>we stand a cat in QL's chance of success? My Dad is very >>happy sticking bits of wire in the individual socket holes >>to try things out if necessary. This can be dangerous, not only to him, but to the monitor & QL - he could end up frying either or both of them. > I think it very very very very unlikely it is a straight through > connector - there are too many permutations. > > Sinclair was the sort of guy who specialised in making apparently std > sockets, non-standard - ie 9D serial connector > > Sticking wires in pins could be dodgy. Find the GND pin first using > continuity meter (with power off). I will stop here - I reckon it would > be pretty dodgy trying at random. Is there no existing lead? At least > then you can see active connections.
Re: [ql-users] SMSQ Source upgrading, & assembling.
In a message dated 09/07/02 20:46:14 GMT Daylight Time, [EMAIL PROTECTED] writes: Are we in danger of restricting SMSQE to be assembled with Qmac restricting ourselves to 68000 code, casting aside all those QLers who have invested in a Super Gold Card, QXL, Q40 or Q60? You are not going to be able to do some serious number crunching if you are not going to use the floating point extensions. You are not going to stop the QL crashing without using the memory management unit of the 68030+ chips and instruction set. Gwass is the only assembler which can cope with 68020+ and floating point instructions. Furthermore Gwass is maintained and can be extended and corrected as required, whereas Qmac is not and you are going to have to put up with its errors and restrictions. George has offered to convert the macros. What better offer could you have? If you are not going to use these features there does not seem much point in upgrading SMSQE. Just treat the QL like a crystal radio. Something to nostalgically recall the pioneering days of computing, or leave to the local museum to be looked at by our grandchildren. I agree that it is important to allow SMSQ/E to use the later enhancements offered by the 68020, 68040 and 68060 computers, for which, I admit, GWASS is essential. Thankyou George for offering to change the macros. The problem is based upon the fact that QPC does not support anything after 68000 instruction set, therefore GWASS does not work on it. I do not know the percentages of developers working on the different QL implementations, but understand that a fair few of those who will work on SMSQ/E use QPC. BTW Which chip set does QXL use?? I think even that is 68020 - am I correct Roy?? This remains a problem as both QPC and the Gold Card cannot support the 68020 instruction set and yet both allow SMSQ/E. Perhaps the safest is to rely on Qmac to assemble the core of SMSQ/E and use GWASS to compile specific modules which rely on the 68020+ instruction set. I am not convinced How difficult would it be George, to allow GWASS to work on the 68000 chipset?? Rich Mellor RWAP Software 7 Common Road, Kinsley, Pontefract, West Yorkshire, WF9 5JR TEL: 01977 614299 http://hometown.aol.co.uk/rwapsoftware
Re: [ql-users] SMSQ Source upgrading, & assembling.
Are we in danger of restricting SMSQE to be assembled with Qmac restricting ourselves to 68000 code, casting aside all those QLers who have invested in a Super Gold Card, QXL, Q40 or Q60? You are not going to be able to do some serious number crunching if you are not going to use the floating point extensions. You are not going to stop the QL crashing without using the memory management unit of the 68030+ chips and instruction set. Gwass is the only assembler which can cope with 68020+ and floating point instructions. Furthermore Gwass is maintained and can be extended and corrected as required, whereas Qmac is not and you are going to have to put up with its errors and restrictions. George has offered to convert the macros. What better offer could you have? If you are not going to use these features there does not seem much point in upgrading SMSQE. Just treat the QL like a crystal radio. Something to nostalgically recall the pioneering days of computing, or leave to the local museum to be looked at by our grandchildren. - Original Message - From: "Wolfgang Lenerz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 1997 9:57 AM Subject: Re: [ql-users] SMSQ Source... > > On 6 Jul 2002, at 10:27, [EMAIL PROTECTED] wrote: > > > > > > [...] > > > > > > > > > > GWASS was altered a few years ago to allow macros of this sort. This was to > > enable the large set of macros used in QMAC for Pointer Programs to be used > > in GWASS, after modification. > > > > If you send some of these macros to me I'll see how they can be amended. > > > > It shouldn't be too difficult. > > I'd prefer GWASS to be amended! > > Wolfgang > > George > > > > > - > www.wlenerz.com
Re: [ql-users] SMSQ Source styleguide
At 03:17 PM 7/9/2002 -0400, you wrote: >Or, better still, Wolfgang could offer three versions of the source code >CD... Actually, I would probably work better if Jochen took the SMSQ/E source code, added the commercial programs to the CD and sold it. This way the Registrar (Wolfgang) does not have to become a commercial vendor and can stay away from $$. I don't know about the license, but I don't think it would disallow a vendor from becoming a VAR (Value Added Reseller) of the Source Code, esp. a vendor allowed to sell binary copies of SMSQ/E. Tim Swenson
Re: [ql-users] SMSQ Source...
Dave Walker wrote: > The MAKE and LD (linker) from the C68 package will also work fine if anyone > wants to use them. I don't know about ld, but regarding MAKE: there are no MAKE files, QMake works differently, it takes linker control files as an input. Marcel
Re: [ql-users] Tools required to build the SMSQ source
Norman, Converting the SMSQ/E assembler source to use the AS68 assembler is unlikely to be practical. It does not understand the concept of macros, and is not very good at relocatable code! It was designed specifically to be an assembler that backends a compiler - not one that is used directly by an assembler programmer. The other tools in the C68 suite (MAKE, LD) will work fine though. Dave - Original Message - From: "Norman Dunbar" <[EMAIL PROTECTED]> To: "QL (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 10:16 AM Subject: [ql-users] Tools required to build the SMSQ source > > People, > > don't forget that just because you can now get your hands on the source code > for SMSQ, that everything else is free too. This is not the case. Because > I've been working on the source and sending emails to the list, I've been > asked to supply the tools to do the assembling and linking. I cannot do this > because these tools are still commercial products. > > Tony Tebby uses QMAC to assemble, his own linker to link (but Marcel says > that QLINK will work too) and to make life easier for himself, he uses QMAKE > to build everything easily. I'm assuming he paid for these tools himself - > so why shouldn't we? > > Please don't send me any more emails asking for QMAC etc - send them to > Quanta. > For QMAKE, contact Jochen Merz. > > Alternatively, if you absolutely must have free tools, why not download Dave > Walker's C68 package and convert the source to use AS68, ld and make as > supplied in that package. Or, if you don't use QPC, get hold of George > Gwilt's excellent GWASS - but you may have to rewrite the macros Tony uses > to suit the macro language of GWASS. > > (Just remember that this won't be acceptable as part of the official source > under the advice given in the Style Guide from Marcel.) > > Thanks. > > > Regards, > Norman. > > - > Norman Dunbar > Database/Unix administrator > Lynx Financial Systems Ltd. > mailto:[EMAIL PROTECTED] > Tel: 0113 289 6265 > Fax: 0113 289 3146 > URL: http://www.Lynx-FS.com > - > This email is intended only for the use of the addressees named above and > may be confidential or legally privileged. If you are not an addressee you > must not read it and must not use any information contained in it, nor copy > it, nor inform any person other than Lynx Financial Systems or the > addressees of its existence or contents. If you have received this email > and are not a named addressee, please delete it and notify the Lynx > Financial Systems IT Department on 0113 2892990. >
Re: [ql-users] SMSQ Source styleguide
In a message dated 09/07/02 18:27:00 GMT Daylight Time, [EMAIL PROTECTED] writes: Obviously, when talking about commercial products, especially where Jochen has kindly lowered the price for a period to allow SMSQ tinkerers to get in at a lower level, I think all is right with the World. Jochen, why don't you chuck together a little bundle of these apps, so everything we could possibly need is available for one low price, with lower media and mailing costs for you? You could even do a couple of packs - a mud hut pack with the compiling apps, and a pyramid pack with debuggers, monitors, etc? Or, better still, Wolfgang could offer three versions of the source code CD... 1) Just the source code - for free as now. 2) CD with source code, QMAC, QMake and QLink on it sold at a price including the commercial rates for the commercial aspects - some sort of deal could be made with the software producers. 3) CD as per (2) above with Qmon II and QD on it (as a preferred editor) plus any other useful debuggers etc. Again at a commercial rate - maybe Qmon II could be fixed to work in Supervisor mode in IOW.XTOP again!! Even the QDOS/SMS Reference Manual could be thrown in here as an extra to assist!! Jochen would be pleased!! Rich Mellor RWAP Software 7 Common Road, Kinsley, Pontefract, West Yorkshire, WF9 5JR TEL: 01977 614299 http://hometown.aol.co.uk/rwapsoftware
Re: [ql-users] SMSQ Source...
The MAKE and LD (linker) from the C68 package will also work fine if anyone wants to use them. That would at least have the advantage of allowing that part of the development cycle to also be hostable under Windows and Linux - all that would then be needed is an assembler hosted in those environments :-) Dave - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 05, 2002 5:49 AM Subject: Re: [ql-users] SMSQ Source... > > On 4 Jul 2002, at 16:47, Marcel Kilgus wrote: > > > > It's all there. You just need QMAC, QLINK and QMAKE. In principle you > > can do without QMAKE but it makes life much easier. > > > I can supply a MAKE and a linker if anybody needs it - next > monday... > > Sould I append them to a message here in the list? > > Wolfgang >
Re: [ql-users] SMSQ Source styleguide
On Tue, 9 Jul 2002, Derek Stewart wrote: > No that is not waht I meant, people who want to compile SMSQ/E and have not > got QMAC, QLINK and QMAKE will have to buy them. Obviously, when talking about commercial products, especially where Jochen has kindly lowered the price for a period to allow SMSQ tinkerers to get in at a lower level, I think all is right with the World. Jochen, why don't you chuck together a little bundle of these apps, so everything we could possibly need is available for one low price, with lower media and mailing costs for you? You could even do a couple of packs - a mud hut pack with the compiling apps, and a pyramid pack with debuggers, monitors, etc? Dave
Re: [ql-users] SMSQ Source styleguide
Well I wish I never entered this message On Tuesday 09 July 2002 9:39 am, you wrote: > This is very funny. Yes, let's have EVERYTHING for free > No that is not waht I meant, people who want to compile SMSQ/E and have not got QMAC, QLINK and QMAKE will have to buy them. I did not say anything about them being free, of course they are, the people who have programmed the software deserve the money for thier efforts. > ... and, Wolfgang, don't forget users with a QL and without > harddisk - they can't compile the sources. Will you make sure > that these people get the hardware on which they can do it > for free as well? :-)) > I'm sure there are lots of people out there who would not > mind a free Q60... so ask for some more IRCs to cover the parcel > price for the big package which will soon come with the > sources CD, containing a machine, a monitor, and a coupon > for free electricity. > Really this is so silly, who say anything about FREE software No wonder things are drifting apart if this is the example of the comments made. > Jochen > > p.s. QMAKE is not essential, but it adds a lot of convenience > and speeds up the turnaround time considerably. > > And - interesting, I have not had a single inquiry about a > QMAKE so far So it the Style guide an advert for the Qmake or Qmac Derek
Re: [ql-users] Re:
> Warning - that file is 15mb! > Yes, thanks, I know that *now*, having found out the hard way. As it was in the middle of the night it was cheap, and a good test of Freeserve & my setup, as it's much the biggest download I've ever made. - Original Message - From: Tony Firshman <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 11:27 AM Subject: [ql-users] Re:
Re: [ql-users] Re:
TVM for the info. The pinouts are on p1.10, A1, and A2. It's rather a long book, but worth the download to keep Dad quiet. Alan T - Original Message - From: Michael Lasham <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, July 09, 2002 4:13 AM > > [:)] > I did [:)] > > You need to read the Sinclair QL service manual at > ftp://ftp.worldofspectrum.org/pub/sinclair/technical-docs/QL ServiceManual.pdf > Which has the pin outs for the DIN connection. >
Re: [ql-users] SMSQ Source...
In a message dated 08/07/02 09:59:56 GMT Daylight Time, [EMAIL PROTECTED] writes:
I'd prefer GWASS to be amended!
I assume you mean that you would like GWASS to be altered so that the Qmac macros would work without any change. There are various reasons why this wouldn't be easy or indeed possible.
For example the conditional instructions in GWASS are global - not confined to macros as I believe the Qmac ones are. You also need an "endif" in GWASS.
Also setnum and setstrg of Qmac set numbers and strings inside a macro. GWASS's "set" is again global. It can be used anywhere in a program to set a variable of whatever sort and to reset it later.
A third problem would be strings. In GWASS a string may be delimited either by apostrophes (') or by quotes ("). Only the former are allowed in Qmac.
Anyway, what is so bad with a set of GWASS-type macros to replace the Qmac ones provided the USER of these macros can code them in almost exactly the same way as for Qmac?
George
Re: [ql-users] SMSQ Source styleguide
It puzzled me for a bit until I discovered it was a problem with the unzip program. It assumes the file names in the zip do not include the device name, which in this case they did. The real limit is 36 characters + the device name = 40. With a bit of messing around I got the lot on the .WIN file only to find the u$$ wasn't needed anyway. Cheers Malcolm Norman Dunbar wrote: > > >I'm a wee bit puzzled as to how Tony managed to zip up the sources as many >of the filenames were longer than the allowed 36 characters - especially as >he had that extra 'U$$' directory name present. Anyone know what he develops >on ? > >Once I get to that stage, I'll be having a proper look into the code to see >what I can do :o) > >
Re: [ql-users] SMSQ linker & make
On 9 Jul 2002, at 12:26, [EMAIL PROTECTED] wrote: > Hi all > enclosed a likner & make. The make soufce is basic is also supplie > Sorry, that was written a bit hastily as somebody else was talking in my ear. What I meant is that enclosed are the make & linker. The make is a compiled basic prog, source supplied. I hope I am forgiven for sending this to the list. Wolfgang >
Re: [ql-users] SMSQ Source styleguide
On 9 Jul 2002, at 7:52, Derek Stewart wrote: > > The styleguide looks very good, but all the programs specified to > compile the SMSQ/E source code are commerical. Indeed they are. > QMAC and QLINK maybe only available through QuantA > QMAKE is available through Jochen Merz Software You can also use the linker and make provided today on the list. You are not obliged to use the programs mentioned in the styleguide, provided that the code you write is compatible with them (as it says in the styleguide itself). > Is it your intension to make all these commerical programs available > on the SMSQ/E CDROM disk. > Definitely not. I fail to see why. Wolfgang
Re: [ql-users] SMSQ Source styleguide
On 9 Jul 2002, at 2:07, Fabrizio Diversi wrote: > A general question for all the other people, what is > happening outside here with the SMSQE sources ? > - who receive the cd ? (hoping this is not covered by > a specific clause of personal confidentiality) I'm sorry, I don't feel free to divulge that information - people aked me by private email. Moreover, does it matter, really? Hey, how about a coming out on this list?... :-) I've sent some 20 odd sources out, 3 more are pending, total should arrive at about 25 - much more than I thought. There were people there I'd never heard of. > - apart me and Norman someone else is working on it ? > - new resellers ? No, there are still only three resellers. Wolfgang
Re: [ql-users] SMSQ Source styleguide
On 9 Jul 2002, at 10:39, Jochen Merz wrote: > This is very funny. Yes, let's have EVERYTHING for free Actually, I fail to see what this whole debate is about. Who ever said that the tools necessary to compile whatever, including the source codes, would be free for anybody? Tony graciously accepted to provide the linker & make, as I had mentioned in an earlier email. I have sent them to the list today. Be warned: they are not as nice as the programs sold by Jochen! As you can see, you get them as is, without any other instruction on use. Wolfgang
RE: [ql-users] SMSQ Source styleguide
On 9 Jul 2002, at 10:43, Norman Dunbar wrote: > > Once I get a compilation done, I can check the original 'win1_' and > the 'dev8_' versions for similarity (or complete lack) and if ok, send > Wolfgang what I have. And I will be very grateful for it! > Once I get to that stage, I'll be having a proper look into the code > to see what I can do :o) Why don't we all wait a bit till the code is digested, and then I can send a new, "proper" version out. (send me your CDs back) Wolfgang
Re: [ql-users] SMSQ linker & make
Hi all
enclosed a likner & make. The make soufce is basic is also supplie
Wolfgang
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: makelink_zip
Date: 9 Jul 2002, 7:33
Size: 17866 bytes.
Type: ZIP-archive
makelink_zip
Description: Zip archive
[ql-users] Re:
On Mon, 8 Jul 2002 at 20:13:30, Michael Lasham wrote: (ref: <[EMAIL PROTECTED]>) >You need to read the Sinclair QL service manual at >ftp://ftp.worldofspectrum.org/pub/sinclair/technical-docs/QLServiceManual.pdf >Which has the pin outs for the DIN connection. Warning - that file is 15mb! -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Monitor connections
On Tue, 9 Jul 2002 at 03:30:56, Alan Tyson wrote: (ref: <001b01c226f0$a81a5620$3a51883e@alantyso>) > >My 86-yr-old father in S.Wales (I'm near Chester) acquired a >s/h QL about 10yrs ago, which has kept him well amused. He >used a selection from his many ancient TVs as monitors until >recently, when the last old wreck died, despite much >tinkering. His interest has been revitalised by a double >cataract operation, so now he can see what he's doing. > >A kindly neighbour has given him an old monitor with a 7-pin >DIN socket on the back. Its manufacturer is "St Bernadette, >Made in Singapore". We don't even know if it's monochrome or >colour. Google search found 'St Bernadette' school who 'monitor staff' (8-)# ie found nothing on the web. Any more details like model ID? > >My Dad tells me there's a 7-pin DIN socket on the back of >the QL, and the QL web site tells me there's RGB and >composite video output. A former colleague who dealt with >the audiovisuals where we both worked tells me it's quite >likely that either a straight-through or a crossover 7-pin >DIN plug to 7-pin DIN plug lead might miraculously work >(courtesy of St Bernadette). CPC claim to supply such >(straight-through) leads for 1.02 ukpounds, but whether >they'll sell me a single one at a reasonable price I don't >know. > >What do list members think? Can anyone provide me with a >pinout diagram for the RGB or composite video QL outputs? Do >we stand a cat in QL's chance of success? My Dad is very >happy sticking bits of wire in the individual socket holes >to try things out if necessary. I think it very very very very unlikely it is a straight through connector - there are too many permutations. Sinclair was the sort of guy who specialised in making apparently std sockets, non-standard - ie 9D serial connector. Sticking wires in pins could be dodgy. Find the GND pin first using continuity meter (with power off). I will stop here - I reckon it would be pretty dodgy trying at random. Is there no existing lead? At least then you can see active connections. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
RE: [ql-users] SMSQ Source styleguide
Aha ! SMSQ/E means 'SMSQ with Extended filenames' then :o) Your summer offer is too tempting, I may have to cut out the purse keeper ... regards, norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Jochen Merz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 11:02 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source styleguide > Anyone know what he develops on ? SMSQ/E, of course :- >> cut the price of QMAKE down to EUR 19.90 (plus postage) 'til end of >> August 2002 (let's call it "special SMSQ/E source summer offer") :-)) Jochen This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] SMSQ Source styleguide
> I'm a wee bit puzzled as to how Tony managed to zip up the sources as many > of the filenames were longer than the allowed 36 characters - especially as > he had that extra 'U$$' directory name present. Anyone know what he develops > on ? SMSQ/E, of course :- > PS. QMAKE - enquiry 1, sale 1, sale pending wife's permission 1 :o) Maybe a shall bring a big box of QMAKEs to Byfleet then :-)) Well, QMAKE always was a niche product - but maybe it may change now. What I'll do is: I will go through the manual together with Bernd to make sure it is up-to-date (haven't sold one for ages, so it is difficult to tell - but it will take some days because Bernd is on holiday) and cut the price of QMAKE down to EUR 19.90 (plus postage) 'til end of August 2002 (let's call it "special SMSQ/E source summer offer") :-)) Jochen
RE: [ql-users] SMSQ Source styleguide
Fabrizio, so far the only work I've done couldn't really be called 'work' as such. I'm trying to assist Wolfgang and get a QXL.WIN format set of the source code produced. As a by product, I've amended all the files to use 'dev8_' and all include statements now have single quotes around them. Once I get a compilation done, I can check the original 'win1_' and the 'dev8_' versions for similarity (or complete lack) and if ok, send Wolfgang what I have. I'm a wee bit puzzled as to how Tony managed to zip up the sources as many of the filenames were longer than the allowed 36 characters - especially as he had that extra 'U$$' directory name present. Anyone know what he develops on ? Once I get to that stage, I'll be having a proper look into the code to see what I can do :o) Cheers, Norman. PS. QMAKE - enquiry 1, sale 1, sale pending wife's permission 1 :o) Dilwyn will know what I mean :o) - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Fabrizio Diversi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 10:07 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source styleguide Just sent mine. So, update on QMake: inquiry 1 - sale 1 A general question for all the other people, what is happening outside here with the SMSQE sources ? - who receive the cd ? (hoping this is not covered by a specific clause of personal confidentiality) - apart me and Norman someone else is working on it ? - new resellers ? This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] SMSQ Source styleguide
Just sent mine. So, update on QMake: inquiry 1 - sale 1 A general question for all the other people, what is happening outside here with the SMSQE sources ? - who receive the cd ? (hoping this is not covered by a specific clause of personal confidentiality) - apart me and Norman someone else is working on it ? - new resellers ? Ciao Fabrizio --- Jochen Merz <[EMAIL PROTECTED]> wrote: > > Norman Dunbar wrote: > > > > Oh yes you have !! > > I sent one myself this very morning - via your web > site. > ... you're right - NOW - but this goes to a > different email account - > so after replying here I found your message and you > have a reply in > your box now :-)) > > So, update on QMake: inquiry 1 - sale 0 > > Cheers Jochen __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
[ql-users] Tools required to build the SMSQ source
People, don't forget that just because you can now get your hands on the source code for SMSQ, that everything else is free too. This is not the case. Because I've been working on the source and sending emails to the list, I've been asked to supply the tools to do the assembling and linking. I cannot do this because these tools are still commercial products. Tony Tebby uses QMAC to assemble, his own linker to link (but Marcel says that QLINK will work too) and to make life easier for himself, he uses QMAKE to build everything easily. I'm assuming he paid for these tools himself - so why shouldn't we? Please don't send me any more emails asking for QMAC etc - send them to Quanta. For QMAKE, contact Jochen Merz. Alternatively, if you absolutely must have free tools, why not download Dave Walker's C68 package and convert the source to use AS68, ld and make as supplied in that package. Or, if you don't use QPC, get hold of George Gwilt's excellent GWASS - but you may have to rewrite the macros Tony uses to suit the macro language of GWASS. (Just remember that this won't be acceptable as part of the official source under the advice given in the Style Guide from Marcel.) Thanks. Regards, Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] SMSQ Source styleguide
Norman Dunbar wrote: > > Oh yes you have !! > I sent one myself this very morning - via your web site. ... you're right - NOW - but this goes to a different email account - so after replying here I found your message and you have a reply in your box now :-)) So, update on QMake: inquiry 1 - sale 0 Cheers Jochen
RE: [ql-users] SMSQ Source styleguide
Oh yes you have !! I sent one myself this very morning - via your web site. :o) Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Jochen Merz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 9:39 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source styleguide >> And - interesting, I have not had a single inquiry about a >> QMAKE so far This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] SMSQ Source styleguide
> The styleguide looks very good, but all the programs specified to compile the > SMSQ/E source code are commerical. > > QMAC and QLINK maybe only available through QuantA > QMAKE is available through Jochen Merz Software > > Is it your intension to make all these commerical programs available on the > SMSQ/E CDROM disk. This is very funny. Yes, let's have EVERYTHING for free ... and, Wolfgang, don't forget users with a QL and without harddisk - they can't compile the sources. Will you make sure that these people get the hardware on which they can do it for free as well? :-)) I'm sure there are lots of people out there who would not mind a free Q60... so ask for some more IRCs to cover the parcel price for the big package which will soon come with the sources CD, containing a machine, a monitor, and a coupon for free electricity. Jochen p.s. QMAKE is not essential, but it adds a lot of convenience and speeds up the turnaround time considerably. And - interesting, I have not had a single inquiry about a QMAKE so far
