RE: [ql-users] SMSQ Source upgrading, assembling.
Thanks Phoebus, Richard et al. I *knew* it wasn't United Arab Emulators :o) BNorman. - 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: Phoebus Dokos [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 9:35 PM To: [EMAIL PROTECTED] Subject: RE: [ql-users] SMSQ Source upgrading, assembling. At 06:47 ðì 11/7/2002, you wrote: UAE is Unix Amiga Emulator Phoebus 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 upgrading, assembling.
This makes good sense and is a resonable plan for the future. The only problem with the conversion to C is that it may not fit into an old machine. Sure. I envisaged that any project in C would be only as a way forward for the higher spec. machines, existing and under development. The current SMSQ/E would need to be maintained for as long as necessary to support the older hardware and to allow old apps to still be run. A requirement of any newer OS versions would be to support the same filesystems, offer the same user interfaces, same system calls [where applicable] and run SBASIC programs unmodified, but beneath the skin would be totally different beasts. The actual mechanism for passing parameters to system calls would obviously vary for different platforms as they are 68k register based at present but the C libraries would take care of that. BTW I tried to look at the documentation on the SMSQ/E source CD. A few of them are Word 6.0 which I could open in Wordpad, but most are Word 2.0 which I could not. I will have to bring the CD to work next week to read them, that is if Word 97 or 2000 can open them. Ian. -Original Message- From: John Sadler [mailto:[EMAIL PROTECTED]] Sent: 11 July 2002 11:40 To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source upgrading, assembling. This makes good sense and is a resonable plan for the future. The only problem with the conversion to C is that it may not fit into an old machine. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 10, 2002 12:42 PM Subject: RE: [ql-users] SMSQ Source upgrading, assembling. 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. I agree with that, for the time being. The code has only just been made available. It would be best if a few people started looking at it, figuring out how to do a build in the most painless way - i.e. using the same tools TT used - and put some documentation together, before everyone dives in trying to solve the same problems with a lot of wasted effort. Let's learn to walk before we run. But for the future... There is a wide variety of platforms to be supported by 'one coherent version'. It is good that the whole range of QL-like systems can run QL applications when the users want/need to use them, but it seems a shame that the fastest machines should only be supported by lowest common denominator code if strict backwards compatibility is not always required. The Q60 needs a fully optimized SMSQ/E, freely using whatever 68060 instructions and techniques that will extract best performance from that platform. Is the QL community really so small that a few branches of SMSQ/E could not be supported while maintaining sufficient central control to prevent them mutating into unrecognizable monsters? The coherence could be maintained as a standard for system calls, parameters, responses ... Qosix? ;o) with a suite of test programs to demonstrate compliance by new versions. The trouble with hardware that becomes obsolete is that it depends on manufacturers with suitable plant to maintain production as sales dwindle; the chips are just too complex for a bunch of enthusiastic hobbyists to make in their sheds (unless they have extremely well equipped sheds!). Software on the other hand, is intellectual property. It can be kept alive indefinitely by jumping and adapting to new hosts. QPC has already enabled that by the emulation route. If you tie software to hardware it will die when the hardware does, which it will eventually. Linux has been able to make the jump from x86 to 68k architecture and running successfully on Q40 and Q60, so SMSQ/E should be able to make the jump in the opposite direction. But first, it would be necessary to prise it away from its assembler dependence (much as I hate to say it - I always liked assembler). I once worked for a firm that produced a proprietary operating system that was written in assembler. It was a good system (well, I liked it) but when the new wave of microprocessor-based boxes with the new 32 bit MPUs from Motorola and later Intel started to target the minicomputer market, rather than try to port their OS to these machines, they moved to Unix because it was already C and more easily ported (plus it was the beginning of the era of open systems and they realized that proprietary was no longer the place to be if you wanted to survive). After the current SMSQ source has been digested I really think there should be a project to get all the non-machine dependent parts rewritten in C. Apart from the portability, it would also become easier to develop new features. It would be nice if Tony Tebby gave
Re: [ql-users] SMSQ Source upgrading, assembling.
On Wed, Jul 10, 2002 at 02:48:17PM -0400, [EMAIL PROTECTED] wrote: In a message dated 10/07/02 15:01:10 GMT Daylight Time, [EMAIL PROTECTED] writes: How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? Far too much I'm afraid! no problem, QLay is UAE based and thus could be easilly tweaked to support anything up to 68040. Richard
RE: [ql-users] SMSQ Source upgrading, assembling.
Richard, excuse my complete ignorance, but what is 'UAE' ? 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: Richard Zidlicky [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 10:37 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source upgrading, assembling. no problem, QLay is UAE based and thus could be easilly tweaked to support anything up to 68040. Richard 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 upgrading, assembling.
United Arab Emirates. Tsk. didn yu lern nuffink wen yu wos at scool? ;O) -Original Message- From: Norman Dunbar [mailto:[EMAIL PROTECTED]] Sent: 11 July 2002 11:22 To: '[EMAIL PROTECTED]' Subject: RE: [ql-users] SMSQ Source upgrading, assembling. Richard, excuse my complete ignorance, but what is 'UAE' ? 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: Richard Zidlicky [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 10:37 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source upgrading, assembling. no problem, QLay is UAE based and thus could be easilly tweaked to support anything up to 68040. Richard 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. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
RE: [ql-users] SMSQ Source upgrading, assembling.
Ian, Nice one :o) I knew that UAE was United Arab Emirates, but I thought it was something to do with some fancy computing term like ELF, SROFF etc etc. Anyway, when I was at school the UAE hadn't been invented :o) 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: RE: [ql-users] SMSQ Source upgrading, assembling. United Arab Emirates. Tsk. didn yu lern nuffink wen yu wos at scool? ;O) 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 upgrading, assembling.
United Arab Emirates. Well, Yes - But No!! . But the UAE Richard is referring to is the Amiga Emulator package which has varying other uses - I think it is basically a 68000 emulator for a range of processors, so this is what hes on about.. Tsk. didn yu lern nuffink wen yu wos at scool? ;O) -Original Message- From: Norman Dunbar [mailto:[EMAIL PROTECTED]] Sent: 11 July 2002 11:22 To: '[EMAIL PROTECTED]' Subject: RE: [ql-users] SMSQ Source upgrading, assembling. Richard, excuse my complete ignorance, but what is 'UAE' ? 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: Richard Zidlicky [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 10:37 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source upgrading, assembling. no problem, QLay is UAE based and thus could be easilly tweaked to support anything up to 68040. Richard 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. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: [ql-users] SMSQ Source upgrading, assembling.
Did you know Dr Grant in Elgin? Regards Mike [EMAIL PROTECTED] www.macnamaras.com - Original Message - From: Norman Dunbar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 11, 2002 4:27 PM Subject: RE: [ql-users] SMSQ Source upgrading, assembling. Seafield Primary School - Elgin. Elgin Academy - Elgin. Moray College of Further Education - Elgin. :o) I Only worked in Aberdeen. Cheers, 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: Mike MacNamara [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 4:16 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] SMSQ Source upgrading, assembling. Where was that then Robert Gordons?. Unusual Aberdonian Education, no doubt Regards Mike 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 upgrading, assembling.
In a message dated 10/07/02 15:01:10 GMT Daylight Time, [EMAIL PROTECTED] writes: How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? I thought I had answered that. The answer "quite a lot". I would imagine it might even be as much effort as required to change an emulator to deal with the advanced set of instructions in the 68020+. George
Re: [ql-users] SMSQ Source upgrading, assembling.
In message [EMAIL PROTECTED], Norman Dunbar [EMAIL PROTECTED] writes Seafield Primary School - Elgin. Elgin Academy - Elgin. Moray College of Further Education - Elgin. Have you got any of those Elgin marbles left over from your school days ? I hear the Greek government is looking for some. (Ducks as Phoebus loads catapult) -- Roy Wood Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!) Mobile +44(0)7836 745501 Web : www.qbranch.demon.co.uk
RE: [ql-users] SMSQ Source upgrading, assembling.
At 06:47 ðì 11/7/2002, you wrote: Ian, Nice one :o) I knew that UAE was United Arab Emirates, but I thought it was something to do with some fancy computing term like ELF, SROFF etc etc. UAE is Unix Amiga Emulator Phoebus
Re: [ql-users] SMSQ Source upgrading, assembling.
This makes good sense and is a resonable plan for the future. The only problem with the conversion to C is that it may not fit into an old machine. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 10, 2002 12:42 PM Subject: RE: [ql-users] SMSQ Source upgrading, assembling. 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. I agree with that, for the time being. The code has only just been made available. It would be best if a few people started looking at it, figuring out how to do a build in the most painless way - i.e. using the same tools TT used - and put some documentation together, before everyone dives in trying to solve the same problems with a lot of wasted effort. Let's learn to walk before we run. But for the future... There is a wide variety of platforms to be supported by 'one coherent version'. It is good that the whole range of QL-like systems can run QL applications when the users want/need to use them, but it seems a shame that the fastest machines should only be supported by lowest common denominator code if strict backwards compatibility is not always required. The Q60 needs a fully optimized SMSQ/E, freely using whatever 68060 instructions and techniques that will extract best performance from that platform. Is the QL community really so small that a few branches of SMSQ/E could not be supported while maintaining sufficient central control to prevent them mutating into unrecognizable monsters? The coherence could be maintained as a standard for system calls, parameters, responses ... Qosix? ;o) with a suite of test programs to demonstrate compliance by new versions. The trouble with hardware that becomes obsolete is that it depends on manufacturers with suitable plant to maintain production as sales dwindle; the chips are just too complex for a bunch of enthusiastic hobbyists to make in their sheds (unless they have extremely well equipped sheds!). Software on the other hand, is intellectual property. It can be kept alive indefinitely by jumping and adapting to new hosts. QPC has already enabled that by the emulation route. If you tie software to hardware it will die when the hardware does, which it will eventually. Linux has been able to make the jump from x86 to 68k architecture and running successfully on Q40 and Q60, so SMSQ/E should be able to make the jump in the opposite direction. But first, it would be necessary to prise it away from its assembler dependence (much as I hate to say it - I always liked assembler). I once worked for a firm that produced a proprietary operating system that was written in assembler. It was a good system (well, I liked it) but when the new wave of microprocessor-based boxes with the new 32 bit MPUs from Motorola and later Intel started to target the minicomputer market, rather than try to port their OS to these machines, they moved to Unix because it was already C and more easily ported (plus it was the beginning of the era of open systems and they realized that proprietary was no longer the place to be if you wanted to survive). After the current SMSQ source has been digested I really think there should be a project to get all the non-machine dependent parts rewritten in C. Apart from the portability, it would also become easier to develop new features. It would be nice if Tony Tebby gave his blessing to it, so that it could become an official version (if it ever even got off the ground). Ian.
Re: [ql-users] SMSQ Source upgrading, assembling.
On Thu, Jul 11, 2002 at 12:07:27PM +0100, [EMAIL PROTECTED] wrote: Anyway, when I was at school the UAE hadn't been invented :o) I left in 1981; not sure when UAE was formed. Haven't a clue what UAE means in this context, but I'd guess the U means universal. U=Unix Richard
RE: [ql-users] SMSQ Source upgrading, assembling.
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. I agree with that, for the time being. The code has only just been made available. It would be best if a few people started looking at it, figuring out how to do a build in the most painless way - i.e. using the same tools TT used - and put some documentation together, before everyone dives in trying to solve the same problems with a lot of wasted effort. Let's learn to walk before we run. But for the future... There is a wide variety of platforms to be supported by 'one coherent version'. It is good that the whole range of QL-like systems can run QL applications when the users want/need to use them, but it seems a shame that the fastest machines should only be supported by lowest common denominator code if strict backwards compatibility is not always required. The Q60 needs a fully optimized SMSQ/E, freely using whatever 68060 instructions and techniques that will extract best performance from that platform. Is the QL community really so small that a few branches of SMSQ/E could not be supported while maintaining sufficient central control to prevent them mutating into unrecognizable monsters? The coherence could be maintained as a standard for system calls, parameters, responses ... Qosix? ;o) with a suite of test programs to demonstrate compliance by new versions. The trouble with hardware that becomes obsolete is that it depends on manufacturers with suitable plant to maintain production as sales dwindle; the chips are just too complex for a bunch of enthusiastic hobbyists to make in their sheds (unless they have extremely well equipped sheds!). Software on the other hand, is intellectual property. It can be kept alive indefinitely by jumping and adapting to new hosts. QPC has already enabled that by the emulation route. If you tie software to hardware it will die when the hardware does, which it will eventually. Linux has been able to make the jump from x86 to 68k architecture and running successfully on Q40 and Q60, so SMSQ/E should be able to make the jump in the opposite direction. But first, it would be necessary to prise it away from its assembler dependence (much as I hate to say it - I always liked assembler). I once worked for a firm that produced a proprietary operating system that was written in assembler. It was a good system (well, I liked it) but when the new wave of microprocessor-based boxes with the new 32 bit MPUs from Motorola and later Intel started to target the minicomputer market, rather than try to port their OS to these machines, they moved to Unix because it was already C and more easily ported (plus it was the beginning of the era of open systems and they realized that proprietary was no longer the place to be if you wanted to survive). After the current SMSQ source has been digested I really think there should be a project to get all the non-machine dependent parts rewritten in C. Apart from the portability, it would also become easier to develop new features. It would be nice if Tony Tebby gave his blessing to it, so that it could become an official version (if it ever even got off the ground). Ian. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 10 July 2002 07:01 To: [EMAIL PROTECTED] Subject: 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
Re: [ql-users] SMSQ Source upgrading, assembling.
In a message dated 09/07/02 21:00:37 GMT Daylight Time, [EMAIL PROTECTED] writes: I am not convinced How difficult would it be George, to allow GWASS to work on the 68000 chipset?? GWASS needs a 68020+ to operate. But it can produce code siutable for 68000/8 (ie the basic instruction set) by the command LOW_EA (I think!). This prevents GWASS setting long branches, for example. I regularly use GWASS for programs which must be usable on all machines. George
Re: [ql-users] SMSQ Source upgrading, assembling.
In a message dated 10/07/02 13:38:58 GMT Daylight Time, [EMAIL PROTECTED] writes: I am not convinced How difficult would it be George, to allow GWASS to work on the 68000 chipset?? GWASS needs a 68020+ to operate. But it can produce code siutable for 68000/8 (ie the basic instruction set) by the command LOW_EA (I think!). This prevents GWASS setting long branches, for example. I regularly use GWASS for programs which must be usable on all machines. George - I think that you are missing the point here. It would be ideal if SMSQ/E could be compiled with GWASS (or at least those modules which use 68020+ instruction set). I know that GWASS will handle programs written for use on 68000 as well as 68020 (thanks to your sterling efforts). However, the fact remains that a lot of SMSQ/E developers use computers/emulators which do not support 68020+ and therefore cannot run GWASS to write the code... How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? 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.
On 10/07/02 at 09:58 [EMAIL PROTECTED] wrote: George - I think that you are missing the point here. ... However, the fact remains that a lot of SMSQ/E developers use computers/emulators which do not support 68020+ and therefore cannot run GWASS to write the code... How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? 68000 = 68008 as far as software goes (except of course addressing capability but that is up to the user to handle properly). It would be a GREAT benefit to have an assembler package that is coded using only 68000 (or even reduced 68000) instructions, that never the less can handle 68020+, and more. This is of course my perspective as a hardware designer - knowing that Motorola has seen fit to (try to) kill off 68k, and force ColdFire on ex-68k developers. Things are getting better as far as the differences between CF and 68k with every new CF generation, but the fact remains, requiring 68020+ for a piece of software may be a 'built-in' dead end - even the 68060 is technically obsolete (actually, the trem is 'end of life'). Assuming the community still exists at that point, it's only a matter of time until a CF based QL happens. Nasta
