On Wed, 15 Oct 2003 12:58:20 +0200, <[EMAIL PROTECTED]> wrote:
<snip>
On 15 Oct 2003 at 3:05, Phoebus R. Dokos (è á . ç ) wrote:
Oh boy, do I disagree with you.
Allow me to take my own example.
I just have to use a PC at the office. A good word processor, spreadsheet, PRINTER,
Internet access etc are just things I need.
So are other, homewritten, programs.
Now, the word processor runs on the PC. So I need a PC. There just is no way around
it.
Am I going to put 2 computers in my office? Have twice the noise? Use twice as much
electricity? etc....
No way. I could justify that at home (it's a hobby) but not at the office, where I receive
people.
OK, so a PC it is. Now, I also need some homemade programs.
If I can't have them under some kind of SMSQ emulator, I'll need them on the PC.
So I start PC programming - what do you think will then gradually happen?
Sooner or later all of my programming will be done on the PC, because, the
homemgrown programs are also done at home.
Exit SMSQDOS....
So, for me, QPC is a very real reason TO CONTINUE TO STAY WITH THE QL WORLD!
I don't disagree with you. That's the point I was making actually. You have to use it but others don't necessarily. It's however so convenient to use an emulator (any emulator doesn't matter which one) that it has turned the OS away from the hardware.
I for example had to get QPC when I first came to the US as I had no way of bringing my hardware. Now that I brought my hardware, QPC has been reduced to a support and testing role for me, although my wife's machine being that it doesn't have enough space to house a KVM + real QL hardware runs QPC more consistently to play QWORD :-D
My daughter now plays with a Schön keyboard equipped QL soon to be upgraded to SGC/Aurora and it's connected to the small TV in her room so she can practice her letters :-) (Loves the new colour drivers btw ;-)
(...)However (and that is the user's preference not Marcel's doing of course)
when the emulator becomes the only place where the software is run, then
first the hardware becomes totally obsolete and then the emulator itself.
OK, I can agree ith that -it was one of the reasons I did buy a Q60.
Then we really agree :-)
If the trend for emulation-based only QL work continues, then we might as
well totally abandon QPC/QemuLator/uQLx etc and rewrite QDOSMSQ (to use
Thierry's term ;-) in a higher level language and use it natively on PCs,
MACs and what have you.
Don't tempt the devil...
Why not? I argued that point a long time ago. If the hardware is to fail us at some point in the future, why not consider developing a principles-compatible QL OS that's portable?
Oh well, of we go into this debate again - QPC does run on hardware and can takeThe purpose of existence of any QL derivative OS is to run on hardware after all and to take advantage of that hardware. If that doesn't happen what is the point of still using the OS?
advantage of it - I can read CDs, I can use USB printers etc...
QPC does run on hardware but SMSQ/E for QPC doesn't. I believe that's a clear distinction.
It is (and according to my belief illustrated above) therefore imperative
that the users choose to invest in hardware instead on only software (in
the best situation both) if there is any point in all of this.
Yes, and despite the above I still agree.
But for me, conceptually, there is not that much difference between an QPC machine
and a Q60 machine.
We will disagree here :-)
(...)No, but what can you use it for if not to run SMSQ/E (ok, Qdos classic, but I wantI don't think that the Q60 was ever sold as a Linux machine (although it runs it very capably) but with the *ability to run* Linux. (Similar to saying PC with the ability to run QL software via QXL or QPC!.. It's not primarily therefore a QL ;-)
MORE than a QL from a modern machine).
Exactly right but the quest for code uniformity imposed by both the structure of the license and choices make it impossible for SMSQ/E to be that on the Q60 as the situation stands.
Again, I disagree in practice. If the hardware is there but no software to take care of it,
Apart from that I fail to see how the Q60 is being developed actively?
Software development and hardware development are distinct processes. The
Q60 is completed and working fine. Peter designed and implemented the
hardware and we're asking him to make the software for it too? (Don't get
this in the wrong way I am just asking a legitimate question). Nobody asks
Marcel or you to design hardware to fit the software right? Just as we
never asked Miracle to write SMSQ. TT did that!
The fact that Peter has the ability to contribute software is unrelated to
the fact that he designed the hardware.
what use the hardware?
And who is to blame for that? Certainly not Peter right? For the reasons I said we cannot expect from Peter only to develop software for the Qx0. We do not live unfortunately in the time where CST or Dansoft or Sinclair were around and had the market and the capability of developing both the hardware and systems software. (Okay maybe the CST/Dansoft paradigm isn't the best but it illustrates the point). And even if Peter (or Nasta or even Tony Firshman and the ill-fated iBox) want to do so, shouldn't the software fit their needs and plans? If SMSQ/E doesn't fit their requirements why should they invest time and money on it?
Sorry, I don't understand the reference to "making" ED drives.Now, if you mean by developing to create new hardware solutions more extended than the current Q60 offering that's a different process that involves a substantial and immediate investment. Even to make my new ED drives it took me several hundreds of dollars and that's an easy task...
I meant getting the parts necessary, developing the new cable, buying documentation etc... all this take money to make even if all the parts are available and the design is simple and not really a design :-)
But let's use this as an example. If you want ED drives, you have to upgrade the OS for
it. And who could help there better then Peter Graf?
Peter has more than helped (as has Marcel) in several projects that I have done in my own time. For ED drives btw, it is impossible to use on a Qx0 since extremely few ISA controllers are capable of driving an ED drive. If I reverse the argument a bit, shouldn't QPC support ED drives since PCs do support them? I cannot blame Marcel for not doing so and neither should be Peter be expected to do the same.
imagine tackling a whole machine in say a ColdFire implementation with PCI
bus... can it be done? Sure... will it be done? Probably not, and one of
the reasons was explained by Peter... he doesn't feel that the current
license of SMSQ/E can help a potential design.
Noted. I disagree, of course.
Hehe me too ;-)
(...)
I think that the issue is a lot more complicated than that. Unfortunately,
in order for the Q60 hardware to be fully utilised, a lot of processor and
hardware specific code has to be written. Unfortunately the current
situation of the license permits that only for one's own leisure.
Wrong. See my other message re the open software question.
I disagree. The license may not state it explicitly but the restrictions are so many that it's impossible to do so, so in reality my argument is true although not in the letter.
The
license is what it is and has to be respected regardless of one's personal
opinions. A solution to that would be extensive patches on the code and
the list has seen a tremendous disagreement over that in the past. As for
the sound system what do you mean? If you mean sound generation by tapping
into the DACs directly it has already been done (and a future version of
QWord will include that code which I am now perfecting thanks to the
always valuable assistance by Simon Goodwin) but we should not forget that
many of the hardware capabilities are severely restrained by the software.
So you do agree that hardware and software are interdependant.
On this specific question - wouldn't it be better if the OS itself had these sound facilities
built-in.
Of course it would but that brings us back to the lack of what constitutes an acceptable minimum standard and what an extension. Right now almost everything has to be brought down to even the smallest machine and if not possible (with few exceptions) then the facility is not deemed to be worthy of inclusion in the official source tree. A device independent OS should solve these problems to a large extent (which brings us back to the IOSS problem).
Even better, if some kind of common sound generation code or at least interface could
be made for QPC, Qx0 and the Atari (which also has capable sound hardware). Yes I
know, I'm dreaming here. Sorry.
Well it CAN be done as illustrated by the newest uQLx. (It also has midi capability btw ;-) The Amiga can do it as well with QDOS Classic and all these work great and in the same way to the user although very different in implementation. The thing is that QDOS Classic is more device independent than SMSQ/E and uQLx is an emulator so it can patch whatever it wants. QPC can do the same and if I am not mistaken QL SSS will be included pretty soon in the capabilities of QPC.
(...)<snip>
Sorry, this argument is based on a flawed premise - see my other email.
Well I beg to differ :-)
<snip re Marcel & Q60 development)
Agreed.
As for Thierry's CD driver it still is severely hindered by the structure
of the IOSS which needs a VERY serious overhaul. CD ROMS being inherently
slow devices lock the machine completely. Thierry's work is great but
without substantial improvement on the way I/O is handled by SMSQ/E and
QDOS it is good only as a once-in-a-while access for massive files that
need only scarce access. The funny part is that by allowing 040+ commands
in the code you could save a lot of time in many I/O operations and you
would at times double the effective speed on many operations on Qx0s. But
this is not allowed is it?
Yes it is.
How? If you restrict the use of tools that can make this happen and then refuse for the most part extreme modifications isn't that in effect contradicting what you are saying?
Actually, your example is a damn good one.
I agree that another IOSS would be VERY nice.
MUCH of that code could be common to all machines and I think that my insisting that it
be done in a way that would, then, benfit all machines is only very reasonable.
Exactly right. But a new IOSS would have to be tailored to each machine to be efficient. Otherwise we fall in the same problem of inefficiency. Again the emulators are excluded from this as they can do whatever they please in IO operations. And of course more conditional assembly would be required to fend for each machine's capabilities. The whole system is need of an overhaul, starting with the IOSS and whatever attaches currently to it.
Of course, there could AND WOULD be code specific to the Qx0, QPC, Goldcard, the
Atari and do on. Would I disagree with that? Not in the slightest.
I sure hope you don't, but I think everyone in favour of the Free Software status of any QL OS sees severe restrictions in the license that prohibit just that.
As an example:
Fabrizio Diversi made Qx0 specific versions of some code that used the MoveP
instructions. These MOVEP instructions are beneficial for the GoldCard versions and
were present in all of the others. It was common code but did hamper the Qx0.
Fabrizio kindly undertook the work to get rid of that and made new source code (based
on the old ones, of course) and gave them to me. Thus, today, these parts have been
taken out of the common code tree and made into a Qx0 specific version.
I never once "protested" against it. Why should I?
I don't see how this argument pertains to the above. MOVEP removal does not affect ANY platform apart from slight reducing of speed and is compatible end-to-end. I do not think though (again judging by various articles and posts here) that you would accept 020+-only instructions in the code at a large extent conditionally assembled, would you?
However, then you can't complain if the same thing would be done for QPC with
"native" code, or, for GoldCard with Movep instructions of what have you.
I do reserve the right to make suggestions every time to make code more common to
all machines.
I think you fail to see my point here. You cannot really complain about QPC (IIRC Marcel is covered by an earlier agreement with TT so much of that doesn't apply to him) but let's take QemuLator as the solution in question.
QemuLator will run whatever code base you throw at it as it can be tailored by Daniele to fit the code and not vice versa. On real hardware that can never be the case, unless you have reconfigurable hardware (machines like the C1 or the Sprinter). Since the Qx0 is not made like that, this doesn't apply.
You always HAVE to make the code fit the machine whereas Marcel, Daniele or whoever else writes an emulator could just as well adapt the emulator to run say the Atari version of SMSQ/E without significant problems.
Everyone would. One lost developer is one too many :-)
Agreed
Ditto
Phoebus
--
Visit the QL-FAQ at: <http://www.dokos-gr.net/ql/faq/> (Still uploading stuff!)
Visit the uQLX-win32 homepage at: <http://www.dokos-gr.net/ql/uqlx.html>
Visit the uQLX-mac home page at:<http://www.dokos-gr.net/ql/uqlxmac.html>
