Re: [ql-users] Q60 software update
On Mon, 8 Apr 2002 10:50:20 + Bruce N [EMAIL PROTECTED] wrote: Forwarded on behalf of Wolfgang.. Hi all, I've has some trouble getting Prowess to work on my Q60. Roy also had some problem with this. He had problems with printing out of Linedesign on a Q40 IIRC. This is now solved for me - I downloaded the latest version of the binaries from Joachim's site (www.progs.be), and this worked nearly straight out of the box. (it is a bit difficult to download them, because they don't download directly -it is a file called PWS_zip.txt. The only thing you need to amend is a line in the startup file, which reads as follows: wait Prowess You should simply comment that line out. I also did download the latest ProWess and it also worked at once. I didn't even had to skip the wait that you mentioned. You may have read in QL Today that I had some problems getting the QPAC2 jobs menu to run under the Q60. This was due to the dreaded 'MOVEP' instruction in there (and in sysmon, too). A simple patch took these out. I can make a simpe basic program available that patches these. Is anybody interested?. Don't you use the extension by Mark that traps those commands and handles them right? Claus
Re: [ql-users] Q60 software update
On 14 Apr 2002, at 15:35, Claus Graf wrote: Don't you use the extension by Mark that traps those commands and handles them right? Umph. Obviously not. I know, RTFM... Wolfgang - www.wlenerz.com
[ql-users] Q60 software update
Forwarded on behalf of Wolfgang.. Hi all, I've has some trouble getting Prowess to work on my Q60. Roy also had some problem with this. This is now solved for me - I downloaded the latest version of the binaries from Joachim's site (www.progs.be), and this worked nearly straight out of the box. (it is a bit difficult to download them, because they don't download directly -it is a file called PWS_zip.txt. The only thing you need to amend is a line in the startup file, which reads as follows: wait Prowess You should simply comment that line out. As I had some unrelated problems with my harddisk (Q60 : 4 - Wolfgang: 0) I ahven't ad time to set this up as I usually do, but, e.g. Agenda worked fine. Hope this helps (notably Roy). Wolfgang -- Hi all, You may have read in QL Today that I had some problems getting the QPAC2 jobs menu to run under the Q60. This was due to the dreaded 'MOVEP' instruction in there (and in sysmon, too). A simple patch took these out. I can make a simpe basic program available that patches these. Is anybody interested?. Wolfgang
Re: [ql-users] Q60
On Thu, 7 Mar 2002 20:17:32 +0100, Claus Graf wrote: Hi Fabrizio, I was also disappointed to see Thierry's free.fr sites down. This is a problem with my ISP, I don't know why but all my web sites are currently unavailable on free.fr. I sent email to the support about 1à days ago and I'm still waiting for a reply... I guess one of their server upgrade went wrong... Thierry.
Re: [ql-users] Q60
On Sun, 10 Mar 2002, Thierry Godefroy wrote: This is a problem with my ISP, I don't know why but all my web sites are currently unavailable on free.fr. I sent email to the support about 1à days ago and I'm still waiting for a reply... I guess one of their server upgrade went wrong... I am happy to mirror your site for US users. If you're interested let me know... Dave
[ql-users] Q60
I notice that the Q60 and specifically D D Systems got a good mention on page 75 of the 7/3/02 issue of Micro Mart magazine. Good news - if Micro Mart can bring themselves to do this, then surely other computer mags could too. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
[ql-users] Q60
Does someone know what happen to Thierry web sites ? I am not able to access both smsq.free.fr and linux one. I need to download linux kernel for my q60 , my old q40 Linux kernel crash the q60. I just received my q60 that now is up and happily running with smsqe under my desk and near my old q40 and i would take this occasion to say how good is quality of the Q60 delivered from DD. The Q60 combo is really well produced and packaged , with comprehensive manual, system software and last but not least a good pre and post selling support. Ciao. Fabrizio __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
Re: [ql-users] Q60
Does someone know what happen to Thierry web sites ? I am not able to access both smsq.free.fr and linux one. Look at http://wwwusers.imaginet.fr/~godefroy/english/index.html Robert
Re: [ql-users] Q60
At 06:53 ðì 7/3/2002, you wrote: Does someone know what happen to Thierry web sites ? I am not able to access both smsq.free.fr and linux one. I need to download linux kernel for my q60 , my old q40 Linux kernel crash the q60. I just received my q60 that now is up and happily running with smsqe under my desk and near my old q40 and i would take this occasion to say how good is quality of the Q60 delivered from DD. The Q60 combo is really well produced and packaged , with comprehensive manual, system software and last but not least a good pre and post selling support. Ciao. Fabrizio In any case I have saved a local copy of both here so tell me if you want anything, Phoebus
[ql-users] Q60, Goldfire and everything...
Hi again... I've received a couple of emails from people, and it's made me a bit worried. People are asking me if they should hold off the purchase of an upgrade, or Q60, based on something that may be released in the future. Not I, not anybody, knows when things will be released. When they are, the next best thing will be right around the corner. If you're thinking of buying a Q40 or Q60, go buy one! Don't hold off for 6 or 12 months for some mystery product. Don't hold out for a new IDE interface if you can get a 2nd hand one from a dealer. We don't know when, or even if, any project will happen, until the boxed card is sat on a dealer's shelf. Don't gamble on that uncertainty. Go buy your upgrades. That was a public service announcement from me. Dave ql.spodmail.com
Re: [ql-users] Q60, Goldfire and everything...
Hi Dave, I've received a couple of emails from people, and it's made me a bit worried. People are asking me if they should hold off the purchase of an upgrade, or Q60, based on something that may be released in the future. [...] Thanks for recognizing this problem. People holding off decisions about a hardware purchase, based on ideas or announcements has always been a major problem for Q40 and Q60. I had a lot of discussions with users who wait because the hope for something on the other side of the fence (where the grass is always greener). Part of this problem may have it's roots in the fact that the concept of the Q40/Q60 could not be easily fitted into the old QL scheme. There was a golden rule which said: A *complete* QL style computer can not succeed. The last attempt was the Thor, and it was not successful. While the GoldGard, which was only a partial QL extension, had a very good success. Since then, all QL hardware developments only changed portions of the system, or supported emulation on Atari or PC. Even Miracle never risked a complete QL style mainboard. For some QL users it had the effect that they compared Q40/Q60 directly to the PC mainboards they knew, including the price, excluding that a PC has no 68060 or other QL similarities. Of course a PC mainboard is cheaper, and of course it has more MHz (now GHz). For some other QL users it had the effect that they compared Q40/Q60 to QL CPU cards they knew, including the price, excluding that a (Super)GoldCard has no highcolor graphics, sound, fast peripherals, and so on. Of course a (Super)GoldCard is cheaper, and allows use of old hardware. For some other QL users it had the effect of waiting for some Miracle announcements (like QL Graphics or UltraGoldCard) and the GoldFire, which fit better into their partial upgrade scheme of thinking. And, last, but not least: For some QL developers (including Tony Tebby, Marc Swift, Thierry Godefroy, and several others) the Q40/Q60 had the effect of writing major QL software again. Unfortunately the personal effort of a few developers can not replace a bigger user base. Peter
Re: [ql-users] Q60 production running!
Peter Graf wrote: To start off with some news, I have the pleasure to announce that the Q60 series production is now up and running! The waiting is over, thanks to Dennis Smith and Derek Stewart, who run DD Systems. Although the possible user base seems very small, and is already partially supplied by earlier Q40 sales, DD decided to make the dream of a highend 68060 powered QL come true. When nobody else had the courage to do the Q60 series production, DD helped. They deserve high respect and a lot of thanks for their decision! I already had the chance to inspect the first board from their new production and I was very impressed by the fine quality of their work. My own involvement in Q60 production has been reduced to sourcing and preparing parts. Now that the series production is running, I no longer build or sell any prototypes. This is excellent news Peter, congratulations on this. I wish you and D D Systems every good fortune with this. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Q60
It's not only the peripherals that are re-used - in fact, everything but a part of the PCB slightly larger than the size of the PGA package is reused. The PCB was designed that way, it has distinct areas that can be re-designed as needed. By now it must be obvious why :-) Any chance of a subpanel for this area of the board to allow future flexibility. Cheers Malcolm
Re: [ql-users] Q60
On Mon, 24 Sep 2001 at 10:21:23, Malcolm Lear wrote: (ref: [EMAIL PROTECTED]) It's not only the peripherals that are re-used - in fact, everything but a part of the PCB slightly larger than the size of the PGA package is reused. The PCB was designed that way, it has distinct areas that can be re-designed as needed. By now it must be obvious why :-) Any chance of a subpanel for this area of the board to allow future flexibility. You snipped just a mite too much from this. ie who sent the original, and what it was about. I don't think it was Q60. GF replacement I suspect. -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 mailto:[EMAIL PROTECTED] 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] Q60
Roy Wood wrote: [ULTRA GOLD CARD announcement Nov./Dec. 1997] ... This was not a competitor to the Q 40 but a direct response to Qubbesoft's announcement of the Goldfire. At least the *timing* when the announcement appeared was directly related to the Q40. Goldfire specs had been announced before the Q40, so looking from outside it seemed to be targeted at the Q40 in the first place. Especially as there has just appeared a working Q40 prototype, what can not be said about the Goldfire. 68040 - 68060 Multi IO - Super IO SIMM socket - SIMM socket audio - improved audio no multiproc. - multiproc. All this does not only compete to the Goldfire but also to the Q40. Who would care about a 68040 machine invented by a *nobody*, if *Miracle* comes up with a 68060 machine? Peter
Re: [ql-users] Q60
Nasta wrote: When it finally materialized (somehwere around the time the Aurora became available) I already had plans to do a SGC successor because it was clear Miracle was pulling out of the QL market. You must have had a lot of insider knowlegde about Miracles policies. After I announced the Q40, Miracle came up with a new competitive announcement in QL Today. Back then, I took the announcement seriously, but from what you say, Miracle had already pulled out. Frankly, I don't think I knew much more than anyone else, getting information about plans from Stuart is worse than pulling teeth :-) Even so, Stuiart is a geat guy and i am really sorry he isn't involved with the QL any more, or at least his involvement isn't public any more. ... In fact, I honestly don't remember Miracle's counter-proposal to the Q40. It was in Nov./Dec. 1997, after I announced the Q40 in summer, and showed a prototype in fall. Looking back, it sounds amusing, but back then I was scared that my work had been almost useless, and considered to give up. Knowing that at least my graphics would be a lot better than the announced machine, made me decide to go on. It sounded like this: U L T R A G O L D C A R D Miracle services is working with TF Services and Qbranch on a new accelerator card for the QL. ... The processor will be the 68060 which is currently the fastest member of the 68000 family and should give an 8-fold speed improvement over the SUPER GOLD CARD. Memory expansion will be by way of a SIMM socket allowing for low cost RAM upgrade. ... add some form of of improved audio interfacing ... multiprocessing ... The ULTRA GOLD CARD will have a high speed network so that many of these will be able to be connected together and use each others processing power. ... In the not too distant future you will be able to come along to a workshop, plug in your ULTRA GOLD CARD to the network, and experiment with processing power rated in GIPS! All the best, Peter
Re: [ql-users] Q60
In article [EMAIL PROTECTED], Peter Graf [EMAIL PROTECTED] writes SNIP It was in Nov./Dec. 1997, after I announced the Q40 in summer, and showed a prototype in fall. Looking back, it sounds amusing, but back then I was scared that my work had been almost useless, and considered to give up. Knowing that at least my graphics would be a lot better than the announced machine, made me decide to go on. It sounded like this: U L T R A G O L D C A R D Miracle services is working with TF Services and Qbranch on a new accelerator card for the QL. ... The processor will be the 68060 which is currently the fastest member of the 68000 family and should give an 8-fold speed improvement over the SUPER GOLD CARD. Memory expansion will be by way of a SIMM socket allowing for low cost RAM upgrade. ... add some form of of improved audio interfacing ... multiprocessing ... The ULTRA GOLD CARD will have a high speed network so that many of these will be able to be connected together and use each others processing power. ... In the not too distant future you will be able to come along to a workshop, plug in your ULTRA GOLD CARD to the network, and experiment with processing power rated in GIPS! This was not a competitor to the Q 40 but a direct response to Qubbesoft's announcement of the Goldfire. It was conceived around my kitchen table after one of the early shows when Miracle were still active but only just. Jochen and I wanted to keep Stuart involved and he seemed annoyed that Qubbesoft were 'poaching into his territory' by doing an expansion card so he got fired up by the idea of the Ultra Gold Card. Soon after he made the announcement he called to say that he was not going to do it after all and then pulled out of QL stuff altogether. He had looked into the available chips and come up with a list of things that the card could do. He was also heavily into the idea of multiprocessing. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/
Re: [ql-users] Q60
Nasta wrote: You are right, i should have been more precise, the QXL WAS the closest hardware And NOW it is the Q40/Q60, isn't it? ;-) When it finally materialized (somehwere around the time the Aurora became available) I already had plans to do a SGC successor because it was clear Miracle was pulling out of the QL market. You must have had a lot of insider knowlegde about Miracles policies. After I announced the Q40, Miracle came up with a new competitive announcement in QL Today. Back then, I took the announcement seriously, but from what you say, Miracle had already pulled out. The 68040 doesn't just compete, it clearly outperforms the 5102. It's a pity that you have cancelled the GoldFire. I would have enjoyed to see the Q40 win the benchmarks ;-) Yes, though the difference would not be that spectacular. Agreed, except for FPU stuff like Povray or other C programs. [details about history snipped] Using a 68EC060, as I said in the original mail, presents a few challenges. Which is, in other words, a new concept and new design work. Are you sure that the users who waited for the announced GoldFire wouldn't prefer a *finished* Coldfire 5102 design to the new challenges of a 68EC060 design? (After all your price for the Coldfire 5102 chip was still cheap.) [details about DRAM interface and multiprocessing snipped] If I was in your shoes, I would think twice before I spend my time with multiprocessing and the best DRAM interface for it. If the design and the operating software development is finished someday, there will be other and faster semiconductors anyway. But that's just my own approach, and I really don't want to push you into the same direction. As you said, thinking about a design is part of the fun, and the more practical things about time and realization you burden upon yourself, the less fun it might be. The PCB was designed that way, it has distinct areas that can be re-designed as needed. Doesn't that cost siginificant board space and routing flexibility? ... but if you are in a situation where you can't actualy make it (for whatever reason) - such as the situation I have - exercising the paper in order to prepare the best design when it can eventually be made into reality, is the only thing that remains. This doesn't sound very good. My best wishes that your personal situation may become better! Have you ever considered to let your SGC successor plans rest, and concentrate your design efforts on smaller projects which do not cost so much time and money? For example if you design an ethernet card for the QL/Aurora, forces on the software side could be joined with the Q40/Q60. Or if you build a QL soundcard, we could re-use and extend the drivers from Q40/Q60. Or... Or... there could be a lot of ideas. All the best Peter
Re: [ql-users] Q60
On 9/22/01 at 2:44 PM Peter Graf wrote: You are right, i should have been more precise, the QXL WAS the closest hardware And NOW it is the Q40/Q60, isn't it? ;-) Oh, yes, definitely. The Q40/60 is definitely the closest type of hardware, for several reasons. For instance, the GF IO chips are all designed for PCs originally, and the Q40/60 uses an ISA PC IO board - the similarity is obvious. In some ways, there still are similarities between the QXL and the GF, in particular the way IO is relocated and the way the original QL screen is emulated. When it finally materialized (somehwere around the time the Aurora became available) I already had plans to do a SGC successor because it was clear Miracle was pulling out of the QL market. You must have had a lot of insider knowlegde about Miracles policies. After I announced the Q40, Miracle came up with a new competitive announcement in QL Today. Back then, I took the announcement seriously, but from what you say, Miracle had already pulled out. Frankly, I don't think I knew much more than anyone else, getting information about plans from Stuart is worse than pulling teeth :-) Even so, Stuiart is a geat guy and i am really sorry he isn't involved with the QL any more, or at least his involvement isn't public any more. In any case, we talked at one of the meetings (I think in Italy) and Stuart sent me the 5102 User's Manual. We later had a series of phone calls and faxes exchanging ideas on what could be done with it. The idea of a QXL II on the PCI bus was also mentioned, but it soon became obvious that a PCI bridge chip would be more expensive than all the rest of the board. You have to remember that I haven't been to a lot of meetings so I don't know what was being said or discussed on them, and what other proposals were mentioned. In fact, I honestly don't remember Miracle's counter-proposal to the Q40. The 68040 doesn't just compete, it clearly outperforms the 5102. Yes, though the difference would not be that spectacular. Agreed, except for FPU stuff like Povray or other C programs. Of course, since the 5102 doesn't have a FPU. But for QL programs it would have acceptable performance. Using a 68EC060, as I said in the original mail, presents a few challenges. Which is, in other words, a new concept and new design work. Well, yes and no - if you only knew how many iterations I went through with the GF... the history from the last mail was VERY abbreviated. It is a not a new concept in the sense that I have considered it before, quite a long time ago. It is a new concept because what was a consideration before, now needs to be completely developed, so unlike before where I only saw problems with that idea, now I have to develop solutions to them :-) Are you sure that the users who waited for the announced GoldFire wouldn't prefer a *finished* Coldfire 5102 design to the new challenges of a 68EC060 design? (After all your price for the Coldfire 5102 chip was still cheap.) At this state of completeness, there is absolutely no difference at all. [details about DRAM interface and multiprocessing snipped] If I was in your shoes, I would think twice before I spend my time with multiprocessing and the best DRAM interface for it. If the design and the operating software development is finished someday, there will be other and faster semiconductors anyway. Ordinairly, I would agree, but as I said, since I cannot at the moment start actually implementing the hardware, such an approach is beside the point. I still have the option to think, though, so I do - as for the best DRAM interface, actually most of the multiprocessing interface would have been implemented on the second CPU board, only the very minimum was included on the GF. It doesn't seem so from the block-diagram that I have on the web, but keep in mind that was made to make the idea clear, not necesairly the actual implementation. Of course, now this will have to be updated :-) The idea of a more efficient interface was born when I decided to use SDRAM. This was really mostly made for me by the price of the components, and the fact that it opened so much space on the PCB. It is actually very simple to connect two CPUs to a shared bus, but there are things one has to figure out such as read-modify-write cycles and caching - but there is always the fact that two CPUs only get half of the bandwidth of the single CPU each, at best. It turned out that I could get tthe CPUs to overlap quite efficiently, which also solved the problem of read-modify-write. But as I said, the 68EC060 is a step back in this area, fortunately to a concept that has already been designed, and has it's own set of reasonably balanced advantages and disadvantages. The PCB was designed that way, it has distinct areas that can be re-designed as needed. Doesn't that cost siginificant board space and routing flexibility? Not really as the necessity for trace reduction always exists, the basic layout of the GF is such
Re: [ql-users] Q60
Nasta wrote: This doesn't sound very good. My best wishes that your personal situation may become better! Actually, I am sorry to say, it got signifficantly worse just a few days ago - WTC and Pentagon attack spillover... :-(( Yes. One of them is going to be finished very soon, too, the Qubide II Congratulations. If you have read the readme.txt that come with the CDROM driver, it's mentioned in there. I read it, but obviously not careful enough. I thought the CDROM driver would just use the existing Qubide interface. Actually, I had an idea along those lines. Me too. I waited to see if you are interested in smaller projects or just all or nothing with your SGC successor. It has to do with the GF's IO part. Basically, the set of IO chips on the GF is really an 'integrated QL peripheral' of sorts, and just like the rest of the GF, it is also a relatively separate part of the PCB. It could be converted to a separate QL peripheral (within reason), or into a Q40/Q60 integrated IO card. In the later case, one would have to hope the extra features such as compatibility across all QL hardware platforms, fully featured sound, ethernet, PS2 mouse and keyboard, two IDE channels and the requirement for only one ISA slot would offset the higher price (which actually would not be that terribly high) compared to second hand old ISA boards. As you probably know, the Q40/Q60 already supports all these features hardware-wise, except that it uses a different mouse. (And except for ISA sound cards, there already is software, too.) Integration into one card is a nice thing, but new features for Q40/Q60 users would be missing, so I am not sure if that could attract enough users. Could such a card offer something more? Something that can not be done by just using existing ISA cards? That would make it interesting. - I had a different idea, how the Q40/Q60 might help you finish your SGC successor project, and the Q40/Q60 users could also have a little benefit. If you separate your board into two parts, and make them plug together via the CPU's PGA socket, one of those parts could also plug into the Q40 or Q60. This way you could rely on a tested environment and existing software, when you start with the first part. And when you go for the second part later on, you would already know that the first part works OK, and could use the Q40 /Q60 as a reference. If you manage to put something interesting for Q40/Q60 users on the first part, you would already have a finished product that can be sold, long before the 2nd part and all the operating software is finished. Obviously there are also disadvantages, e.g. the logic split, and the extra PCB. But maybe it is worth considering. All the best Peter
Re: [ql-users] Q60
On 9/20/01 at 10:27 PM Peter Graf wrote: Yes, the original idea behing the GoldFire was to use the QXL version of SMSQ as the basis for it, as that is the closest related hardware. I don't think so. The Q40 is *much* nearer to your earlier announcement than the QXL. Think about memory map, interrupt structure, screen memory, Qubide, IO chips and so on. You are right, i should have been more precise, the QXL WAS the closest hardware - the idea for a GoldFire was concieved long before it was announced. It stemmed from a discussion with Stuart Honeyball about a PCMCIA version of the QXL, and the possibility for me to do some design work on it. However, it was soon scrapped as the announced MCF5102 continually failed to become available on the market (where have we heared that before?). When it finally materialized (somehwere around the time the Aurora became available) I already had plans to do a SGC successor because it was clear Miracle was pulling out of the QL market. The 040 would have to run at it's highest clock available (or close enough) to compete with a (at the time) cheaper 5102 The 68040 doesn't just compete, it clearly outperforms the 5102. It's a pity that you have cancelled the GoldFire. I would have enjoyed to see the Q40 win the benchmarks ;-) Yes, though the difference would not be that spectacular. I usually consider 6dB :-) (2x) difference as signifficant... The idea is really to cover the costs of manufacture, and of course, the necessary firmware, that's all. If you cover the costs, you'll earn a lot more than I did. Currently I am WAY below due to the Auroras that were never sold... Also, the GF has not been canceled Point of view. I remember well that you described the Coldfire 5102 CPU as the very heart of the GoldFire and it's multiplexed bus as the most essential feature that turned the project from fantasy into must be done. You also ephasized the importance of the smaller CPU size compared to PGA chips. Actually, the multiplexed bus gave me the idea behind the implementation of a 32-bit bus protocol on the QL's expansion bus. Later on the multiplexed bus reduced the number of lines needed to communicate with the logic chip, and reduced the number of traces on the board considerably. Yes, the ColdFire's small footprint was very important, and in fact made the GoldFire physically possible when it was originally specced out using 72-pin SIMM RAM. This has since been changed to SODIMM SDRAM, freeing a LOT of space. At the time it sounded like a good idea, right now, doing anything else would be foolish as the sprice of SDRAM is very low - it is almost a given that the GF (or whatever it's name is going to be) will come with 128M of SDRAM as standard, it's cheap, and if I only have to design for one configuration, it simplifies the logic some. Once SDRAM was in place, it even became possible to physically put BOTH the PGA and the PQFP package, the first for a 68040V and the second for the 5102. It was a possibility which was soon discarded when the 68040V turned out to cost about 200$ a piece in huge quantity, plus it turned out that it would be extremely difficult to do a dual footprint PCB on 4 layers, and retain signal integrity. That's how I came up with the SIMBUS concept, a rehash of a very old idea I had. The extra space previously used by the planned PGA package was used up by two buffer chips that convert the 5102 bus into the very similar SIMBUS. Using a 68EC060, as I said in the original mail, presents a few challenges. Space is again one of them which is why the SIMBUS concept had to be abandoned in favor of a direct CPU to SDRAM conenction. Address lines still have to be multiplexed externally by a LVCMOS chip, and it is going to be a challenge fitting one onto the board, as space is again at a premium. A little help is coming in the form of abandoning a dual footprint for the sound chip (used to be AD1815 or 1816, now it's only 1816). The deletion of the SIMBUS means that a lot of the potential bandwidth of the SDRAM is wasted - the process of setting up a SDRAM access takes about as much as the access itself. The construction of the SDRAM alowes another access to proceed while the next is being set up. However, since the CPU only does one access at a time, effectively doing setup-access-repeat, the ability to use this overlap to one's advantage is lost. The SIMBUS idea alowed two CPUs to overlap their access and thus use the SDRAM to full advantage. SIMBUS would add a 10% memory access speed penalty for one 5102, but two would still have a 10% penalty and be able to access the same SDRAM - even if the wanted to do it at the same time. Now I am back to the shared bus system using arbitration, which means that one CPU gets 100% of all the bandwidth it can use (no overlapping), two CPUs then share that 100% getting 50% each. On the positive side, the logic is simpler, amongst other reasons, because the 68060 arbitration is better than either
Re: [ql-users] Q60
Nasta wrote: Yes, the original idea behing the GoldFire was to use the QXL version of SMSQ as the basis for it, as that is the closest related hardware. I don't think so. The Q40 is *much* nearer to your earlier announcement than the QXL. Think about memory map, interrupt structure, screen memory, Qubide, IO chips and so on. The 040 would have to run at it's highest clock available (or close enough) to compete with a (at the time) cheaper 5102 The 68040 doesn't just compete, it clearly outperforms the 5102. It's a pity that you have cancelled the GoldFire. I would have enjoyed to see the Q40 win the benchmarks ;-) You have to understand that developing QL hardware is very much a passion for me, not intended for generating profit That's really not hard for me to understand, as I am in the same position. The idea is really to cover the costs of manufacture, and of course, the necessary firmware, that's all. If you cover the costs, you'll earn a lot more than I did. In that venue, any notion that I would be introducing new paperware to foil the success of someone elses hardware, is completely absurd. Absolutely. I already said that I don't complain about your paperware. You just provoked a comment, because you stated that your announcements mean no competition to Q40 and Q60. I think they mean competition - why not? Also, the GF has not been canceled Point of view. I remember well that you described the Coldfire 5102 CPU as the very heart of the GoldFire and it's multiplexed bus as the most essential feature that turned the project from fantasy into must be done. You also ephasized the importance of the smaller CPU size compared to PGA chips. Now this announced GoldFire CPU and its long promoted must be features are gone! Why not admit that it is cancelled? Even if you re-use the peripherals, your new announcement is something different than the GoldFire, and has moved somewhat into the direction of the Q60. (Not a bad direction ;-)) To tell the truth, there is nothing I'd like more than cooperating in a design of the 'ultimate QL'... On one hand it is nice to hear that you still have dreams. As long as there are such dreams, the spirit of the QL is not dead. On the other hand, I never had plans or hopes to build the 'ultimate QL'. Because the 'ultimate QL' is a machine that will never be finished. (Which does not mean that unfinished machines are the ultimate QL's.) All the best Peter
Re: [ql-users] Q60
Nasta wrote: Thanks for that info. The 68060 cleverly provides a thermal sensing resistor on chip, so at least temperature can be conclusively measured. I see that you know what I mean ;-) First, there have been some impressive figures posted on the Q60 web site about the power consumption. From what data I could find, it seems that the 060 has signifficantly lower power consumption than the 68040 - no doubt due to the lower supply voltage. What would be your assessment of this? All 68060, even the full-blown, indeed consume significantly less power than the 68040. Unless you overclock 68060 chips, or have no airflow, they can be used without heatsink. Second, you had mentioned on the list that the Q60 cannot use a 68EC060. Would you care to explain in a bit more detail why not? Of course the mainboard can use the 68EC060, but I wouldn't call that a Q60 anymore. The biggest disadvantage would be, that it could no longer run Linux. So it would not even retain the features of the Q40. SMSQ/E also uses the MMU. At the moment mostly for implementation of compatibility features, but Tony Tebby asked for my promise that all machines have the MMU. I think he had future improvements like memory protection in mind. QDOS Classic can live without the MMU at the moment. I know that both the Q40 and Q60 could be a lot cheaper if I had sacrificed MMU and FPU, and went for the cheap EC CPU's. But I saw the lack of MMU and FPU could block technical progress. MCF5102 @ 40MHz, $19 a piece, minimum order 50 pieces. 68EC060 @ 66MHz, $10 a piece, minimum order 50 pieces. Congratulations. Your prices for the 68EC060 are a *big* miracle! Have you checked if the chips are OK? What would you do??? I would like to search if there were also full-blown chips in the list ;-) In short, I now have a batch of 68EC060. Using it on the GF presents a couple of challenges [...] The name 'GoldFire' may be changed since there is no more ColdFire CPU to justify the original moniker. I expected that you someday announce a '060 board. I just didn't know when ;-) Let me also take the oportunity to answer a question before it is asked: I do not consider the Q40 or Q60 in any danger of competition at this time - the GF is still largely paperware [...] Why deny competition? Real competition is a good thing! It encourages technical progress and gives users a choice. Unfortunately paperware competition has the tendency to make users wait instead of getting (and thus supporting) what they can have now. The grass is always greener on the other side of the fence. Lets face it: Some users interested in a Q40 did not get it, because they waited for the GoldFire. Now that the GoldFire has been cancelled, the Q60 will also suffer a bit from your EC060 announcement. Don't get me wrong... I don't complain about your latest announcement. I just don't buy that it has no effect ;-) Good luck with the design! Peter
Re: [ql-users] Q60
On 9/19/01 at 11:20 PM Peter Graf wrote: Nasta wrote: Thanks for that info. The 68060 cleverly provides a thermal sensing resistor on chip, so at least temperature can be conclusively measured. I see that you know what I mean ;-) Well, the most recent look into the 060 manual was more a refresher course :-) All 68060, even the full-blown, indeed consume significantly less power than the 68040. Unless you overclock 68060 chips, or have no airflow, they can be used without heatsink. Yes, I was hoping the EC would use even less power, wvwn though it may be slightly overclocked. Of course the mainboard can use the 68EC060, but I wouldn't call that a Q60 anymore. The biggest disadvantage would be, that it could no longer run Linux. So it would not even retain the features of the Q40. SMSQ/E also uses the MMU. At the moment mostly for implementation of compatibility features, but Tony Tebby asked for my promise that all machines have the MMU. I think he had future improvements like memory protection in mind. QDOS Classic can live without the MMU at the moment. Yes, the original idea behing the GoldFire was to use the QXL version of SMSQ as the basis for it, as that is the closest related hardware. In reality, it would be something of a cross between the QXL and SGC version. I know that both the Q40 and Q60 could be a lot cheaper if I had sacrificed MMU and FPU, and went for the cheap EC CPU's. But I saw the lack of MMU and FPU could block technical progress. In principle I agree with you. But since GF (or whatever it ends up being called) is intended as a extension of the original QL hardware, I considered the MMU a secondary concern at that point - this is how the 5102 was chosen for the GF. Of course, if a CPU appeared that had a MMU and FPU at a reasonable (or better said, justifiable) price, it would be considered - but so far only a real 68040 or a 68060 would provide that. The 040 would have to run at it's highest clock available (or close enough) to compete with a (at the time) cheaper 5102, but would consume too much power to be usable on something like the GF. The 060 was simply out of reach price-wise. MCF5102 @ 40MHz, $19 a piece, minimum order 50 pieces. 68EC060 @ 66MHz, $10 a piece, minimum order 50 pieces. Congratulations. Your prices for the 68EC060 are a *big* miracle! Have you checked if the chips are OK? As far as I can tell, they are - the supplier gave me a waranty. What would you do??? I would like to search if there were also full-blown chips in the list ;-) The idea had occured to me :-) but getting a full 060 proves to be nearly impossible, at any price - unless I go to a regular Motorola dealer. the price is too high for the range the GF is aiming for. Of course, if someone manages to obtain one, they can then replace the EC060 with it. In short, I now have a batch of 68EC060. Using it on the GF presents a couple of challenges... The name 'GoldFire' may be changed since there is no more ColdFire CPU to justify the original moniker. I expected that you someday announce a '060 board. I just didn't know when ;-) Quite honestly, neither did I. I had simply done the calculation with the EC060 vs the 5102, and what came up put the 5102 back into the drawer. Let me also take the oportunity to answer a question before it is asked: I do not consider the Q40 or Q60 in any danger of competition at this time - the GF is still largely paperware [...] Why deny competition? Real competition is a good thing! It encourages technical progress and gives users a choice. Unfortunately paperware competition has the tendency to make users wait instead of getting (and thus supporting) what they can have now. The grass is always greener on the other side of the fence. All I can say is, the users are by all means encouraged to get a Q60 - in fact, when I get the means, I will get one myself. You have to understand that developing QL hardware is very much a passion for me, not intended for generating profit - in fact, so far, I am waaay into red ink with it. The idea is really to cover the costs of manufacture, and of course, the necessary firmware, that's all. In that venue, any notion that I would be introducing new paperware to foil the success of someone elses hardware, is completely absurd. After all, anyone can 'anounce' their own paperware any time - as the saying goes, paper endures anything written on it. Lets face it: Some users interested in a Q40 did not get it, because they waited for the GoldFire. Now that the GoldFire has been cancelled, the Q60 will also suffer a bit from your EC060 announcement. Don't get me wrong... I don't complain about your latest announcement. I just don't buy that it has no effect ;-) Well, I never said it had no effect. Also, the GF has not been canceled - in fact, it's going to be exactly the same hardware, just with a 68EC060 instead of a 5102. Even the rest of the PCB design remains unchanged. Please do not misunderstand, I am
Re: [ql-users] Q60
Not entirely on-topic... and probably a question for Peter Graf: The Q60, AFAIK uses either a 66MHZ 68060 or a 75MHz (clocked at 80MHz) 68LC060. My question is: were any tests conducted with clocking the 66MHZ regular 060 at a higher clock, and if so, what were the findings? 68k CPUs are know to be very conservatively spec'd. I've already asked this on my QLhardware e-group, but got no reply. Regards, Nasta
Re: [ql-users] Q60
Hi Nasta, Not entirely on-topic... and probably a question for Peter Graf: I'd say fully on-topic! You talk about QL hardware, and I am sure it is one of the purposes of this list. The Q60, AFAIK uses either a 66MHZ 68060 or a 75MHz (clocked at 80MHz) 68LC060. Almost. The 66 MHz version is a 68060RC60A (60 MHz) chip clocked at 66 MHz. This is the fastest available 68060 chip with both MMU and FPU. I have never found a real 66 MHz chip with both MMU and FPU. It is said that in the early days of the 68060 there were some, but this is likely to be a saga only. My question is: were any tests conducted with clocking the 66MHZ regular 060 at a higher clock, and if so, what were the findings? As you see above, it is no regular 66 MHz chip, but the A version of a 60 MHz chip, overclocked by 10 %. The heatsink is largely oversized, so the die is actually a lot cooler than with normal operation at 60 MHz. I even ran the 68060RC60A at 70 MHz and more without noticeable problems, but I wouldn't use that for production. 68k CPUs are know to be very conservatively spec'd. Confirmed. I've already asked this on my QLhardware e-group, but got no reply. I had replied on the ql-developers list. The list owner has kindly alowed hardware development issues there, and I very much prefer open mailinglists to Yahoo-groups. I thought you were subscribed to ql-developers. I apologize for not sending a copy of my reply to your personal adress. What is the background of your questions? Do you plan to add a 68060 upgrade socket to the GoldFire specs? Bye Peter
Re: [ql-users] Q60
On 9/18/01 at 10:20 PM Peter Graf wrote: I'm not sure my first reply got through, this new NT virus is bombarding my web server which also has the proxy program, until it eventually crashes. [Overclocking a 68060] The Q60, AFAIK uses either a 66MHZ 68060 or a 75MHz (clocked at 80MHz) 68LC060. Almost. The 66 MHz version is a 68060RC60A (60 MHz) chip clocked at 66 MHz ...a 60 MHz chip, overclocked by 10 %. The heatsink is largely oversized, so the die is actually a lot cooler than with normal operation at 60 MHz. I even ran the 68060RC60A at 70 MHz and more without noticeable problems, but I wouldn't use that for production. Thanks for that info. The 68060 cleverly provides a thermal sensing resistor on chip, so at least temperature can be conclusively measured. 68k CPUs are know to be very conservatively spec'd. Confirmed. Well, at least there is someone with experience to ask :-) I am very grateful for this data. But as they say, give them a finger and they want the whole hand :-) - I do need a bit more data. First, there have been some impressive figures posted on the Q60 web site about the power consumption. From what data I could find, it seems that the 060 has signifficantly lower power consumption than the 68040 - no doubt due to the lower supply voltage. What would be your assesment of this? Second, you had mentioned on the list that the Q60 cannot use a 68EC060. Would you care to explain in a bit more detail why not? I am guessing that it has to do with the interaction of the compatibility requirements in SMSQ/QDOS and the changes in the memory map on the Q40/60 that were necessary to add new capability. I've already asked this on my QLhardware e-group, but got no reply. I had replied on the ql-developers list. The list owner has kindly alowed hardware development issues there, and I very much prefer open mailinglists to Yahoo-groups. I thought you were subscribed to ql-developers. I apologize for not sending a copy of my reply to your personal adress. No apology is necessary, I thought I was subscribed to QL developers too, but it seems that my subscription had somehow lapsed. This would not be surprising as there were several problems with my email due to the various DOS attacks on Croatian sites, my main mailbox is still on servers in Croatia! I will look into this shortly. I can't blame you for not wanting to use an Egroup forum. The prerequisite to use them and not drown in spam, is to have a 'sacrificial' email account for the spam, and use only the web access for the egroups. Unfortunately, if that isn't done from teh start, there could be spam. What is the background of your questions? Do you plan to add a 68060 upgrade socket to the GoldFire specs? Ah, well, I guess the cat is going to be out of the bag anyway, so I might just tell everyone. Currently, the GoldFire (which might actually need a name change, see below), is a good 3 years late. I know that I keep promising it, and now, amongst other things, it's a question of honor to produce it. However, since it's so late, and I cannot for many reasons invest as much work and money in it as I would like to, I try to upgrade the spec where I can, without incuring extra cost in developement time or the final cost to the user. It would make no sense to eventually produce a 3 year old design. Recently my 'GF fund' got a little boost and I decided to start looking for a supplier for the ColdFire 5102 CPU that would have it at a reasonable price and quantity. I finally found a small supplier that had a number of batches of Motorola chips. I was shocked to find this in the price list: MCF5102 @ 40MHz, $19 a piece, minimum order 50 pieces. 68EC060 @ 66MHz, $10 a piece, minimum order 50 pieces. What would you do??? In short, I now have a batch of 68EC060. Using it on the GF presents a couple of challenges, but they are well worth the increase in performance. As a result, the dual CPU feature has been simplified, in favour of alowing a single CPU implementation to work as efficiently as possible. This actually makes the logic simpler! As far as the 'EC' vs 'real' 68060 matters, there is no difference in the design since the 5102 is essentially a 68EC040 with a smaller cache. The name 'GoldFire' may be changed since there is no more ColdFire CPU to justify the original moniker. The reason I asked the question is that for hardware reasons, it would be simpler for me to clock the CPU at 70 or 72MHz, which is less than 10% overclock. I was fairly certain that it could do this with ease. Let me also take the oportunity to answer a question before it is asked: I do not consider the Q40 or Q60 in any danger of competition at this time - the GF is still largely paperware, and it will, unfortunately, stay so for a while longer, though things ARE moving. Plus, it will be 68EC060 based, though upgradeable (no stopping that, the 'real' 060 or the LC060 are all pin-compatible). It will also NOT be possible to add a different CPU
Re: [ql-users] Q60
Richard wrote: On Fri, Sep 14, 2001 at 06:22:26PM +0200, Wolfgang Lenerz wrote: On 13 Sep 2001, at 22:28, Thierry Godefroy wrote: I wonder what this instruction is as none of the beta-testers had reported any crash so far... I thought you were gone for a long time, so didn't send you this info already. The offending instruction is: INIT_SCHD MOVE.B#1,$FF10Disable external interrupts. I just took out the line (leaving the label). I can't find anywhere an instruction where you re-enable ext. interrupts? should not be a problem, because according to my docs the above instruction does enable, *not* disable the external interrupts. More exactly, it enables interrupt line 2 to 7, which corresponds to IRQ5,6,7,10/11,14,15 on the extension bus. The serial interrupts (lines 0 and 1) are not affected. They are related to a different bit in the interrupt register, for a QL compatibility reasons. (For the QL, serial interrupts were not external.) Bye Peter
Re: [ql-users] Q60
On 12 Sep 2001, at 20:50, Peter Graf wrote: Just in case you refer to the MOVEP instruction: No, it's the instruction that disables external interrupts. The 68060 has no MOVEP. Just read the docs on your support disks, and use the MOVEP-emulation software. All the crashes you reported to me will disappear. MOVEP was meant to deal with 8 bit peripherals on old 16 bit 68000 systems. Motorola had removed it, because they saw no more need for this outdated instruction. The best thing would be to remove all MOVEP instructions from SMSQ/E. (Tony Tebby had said he wouldn't use any non-68060 instructions, but unfortunately he overlooked MOVEP.) Yeah OK, that's what I told you. I didn't know this was a well know phenomenon. The MOVEP isntructions can be found in the QPAC2 file and in the QPAC1 sysmon utility. I've replaced them with NOOPS, to no ill effect (so why are they in there?). search for $0b8a and $0b8a0001... Indeed. No wonder. The CDROM driver is not optimized yet. As I said, I don't know whether it was the driver or qxltool. The problem is due to the stupid SMSQ/E SLAVEing which incredibly slows down disk access on machines with lots of RAM. The more free RAM you have, the worse it gets. We need to persuade TT to impose a limit on slaveblock usage or means to disable SLAVEing. OK. I tried the simple expedient of setting the high end of the slave block table pointer to the low end but that doens't work, in SMSQ, they don't seem to be used (?). Wolfgang - www.wlenerz.com
Re: [ql-users] Q60
On 13 Sep 2001, at 22:28, Thierry Godefroy wrote: I wonder what this instruction is as none of the beta-testers had reported any crash so far... I thought you were gone for a long time, so didn't send you this info already. The offending instruction is: INIT_SCHD MOVE.B#1,$FF10Disable external interrupts. I just took out the line (leaving the label). I can't find anywhere an instruction where you re-enable ext. interrupts? As I wrote previously: the QXL.WIN file access on CD-R was just a quick hack. The driver is still in an early alpha state and will only go beta once proper error recovery/correction and data caching is implemented. Oh Thierry, if only M$'s final release versions would work as well as your alphas. The world would be bliss! Wolfgang - www.wlenerz.com
RE: Re: [ql-users] Q60
We need to persuade TT to impose a limit on slaveblock usage or means to disable SLAVEing. ...or to implement a more efficient method of disk caching. Caching will necessarily slow down access when what you're looking for has not previously been loaded, but a good algorithm should keep the overhead to a minimum and not be affected greatly by the size of the cache. For frequently accessed blocks the benefits of efficient caching should outweigh the disadvantages - and reduce wear and tear on the disk. An alternative for large memory machines is to use RAMdisk and have your most frequently used programs and data loaded in at boot time. Ian -Original Message- From: pgraf Sent: 12 September 2001 19:51 To: ql-users Cc: pgraf Subject: Re: [ql-users] Q60 Hi Wolfgang, like you I feel deep sympathy to the americans. I hope nobody on this list has lost friends or relatives. I've recently had some time to play around with my all new Q60. I'm very happy with it, it is a nifty beast. Nice to hear. I had to change one instruction in the ATAPI driver, else it would completely crash the machine Just in case you refer to the MOVEP instruction: The 68060 has no MOVEP. Just read the docs on your support disks, and use the MOVEP-emulation software. All the crashes you reported to me will disappear. MOVEP was meant to deal with 8 bit peripherals on old 16 bit 68000 systems. Motorola had removed it, because they saw no more need for this outdated instruction. The best thing would be to remove all MOVEP instructions from SMSQ/E. (Tony Tebby had said he wouldn't use any non-68060 instructions, but unfortunately he overlooked MOVEP.) CDROM driver: The bad point is: it is really s-l-o-w. Indeed. No wonder. The CDROM driver is not optimized yet. A general hint if you feel that IDE harddisk access is slow on SMSQ/E systems with a lot of free RAM: Waste memory! The problem is due to the stupid SMSQ/E SLAVEing which incredibly slows down disk access on machines with lots of RAM. The more free RAM you have, the worse it gets. We need to persuade TT to impose a limit on slaveblock usage or means to disable SLAVEing. All the best Peter 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] Q60
Hi all, I've recently had some time to play around with my all new Q60. I'm very happy with it, it is a nifty beast. This also gave me the opportunity to test the CD driver. Indeed, I (of course) waznted to get my usual setup also going on the Q60. Sp I copied my QPC QXL.WIN fimle to a CD (i've written abaout this before) and, with the help of many of you, actually managed to het it going. I had to change one instruction in the ATAPI driver, else it would completely crash the machine, but, once that was done, it works (if anyone is intered in the tweak, contact me, I'll be sending an email to Thierry a bit later to tell him about it, as well). I then used the QXLTOOL utility to transfer my files (about 40 MB in a 70MB qxl.win file). The good point : IT WORKS. I was able to tranfer the files from the qxl.win CD to the hard disk. As far as I can tell, there was *NO* file corruption or anything. Hats off to Thierry and J. Hudson. The bad point is: it is really s-l-o-w. the 35 MB mentioned above took about 36 hours (yes!) to transfer. I don't know whether this is due to the driver or QXLtools, I'll attempt to find out at a later stage. It was very noticeable that copying files thatlay towaords the end of the disk took MUCH longer (at the same file size) than some that lay at the start of the disk. By start of the disk I mean those that are at the start of the entire file list as gen,erated by the qxltools 'lslr' command. The good point of the bad point is that I left the machine to itself for 36 hours, and it slaved away without any problems. Does anybody know whether a special version of prowess isnecessary for the Q60? Wolfgang PS : I recently joked about the by-line we could adopt, e.g. bomb, terrorists etc, to give Echelon something to think about. In view of recent events, that's no longer really smart. To our american friends : I grieve with you. - www.wlenerz.com
Re: [ql-users] Q60
Hi Wolfgang, like you I feel deep sympathy to the americans. I hope nobody on this list has lost friends or relatives. I've recently had some time to play around with my all new Q60. I'm very happy with it, it is a nifty beast. Nice to hear. I had to change one instruction in the ATAPI driver, else it would completely crash the machine Just in case you refer to the MOVEP instruction: The 68060 has no MOVEP. Just read the docs on your support disks, and use the MOVEP-emulation software. All the crashes you reported to me will disappear. MOVEP was meant to deal with 8 bit peripherals on old 16 bit 68000 systems. Motorola had removed it, because they saw no more need for this outdated instruction. The best thing would be to remove all MOVEP instructions from SMSQ/E. (Tony Tebby had said he wouldn't use any non-68060 instructions, but unfortunately he overlooked MOVEP.) CDROM driver: The bad point is: it is really s-l-o-w. Indeed. No wonder. The CDROM driver is not optimized yet. A general hint if you feel that IDE harddisk access is slow on SMSQ/E systems with a lot of free RAM: Waste memory! The problem is due to the stupid SMSQ/E SLAVEing which incredibly slows down disk access on machines with lots of RAM. The more free RAM you have, the worse it gets. We need to persuade TT to impose a limit on slaveblock usage or means to disable SLAVEing. All the best Peter
Re: [ql-users] Q60
On Wed, 12 Sep 2001 at 20:50:55, Peter Graf wrote: (ref: [EMAIL PROTECTED]) like you I feel deep sympathy to the americans. I hope nobody on this list has lost friends or relatives. I know someone in Credit Suisse who worked in one of the towers. They were near the ground and escaped. -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 mailto:[EMAIL PROTECTED] 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] Q60
Tony Firshman wrote: On Wed, 12 Sep 2001 at 20:50:55, Peter Graf wrote: (ref: [EMAIL PROTECTED]) like you I feel deep sympathy to the americans. I hope nobody on this list has lost friends or relatives. I know someone in Credit Suisse who worked in one of the towers. They were near the ground and escaped. -- A cyber friend on another list ( Brit-Iron - motorcycles) lost his niece, she was on flight 11 that flew into one of the towers. brings it that much closer to home I think. All the best - Bill
Re: [ql-users] Q60 and Linux
In article [EMAIL PROTECTED], Peter Graf [EMAIL PROTECTED] writes Hi Malcolm, So the operating system on a Q60 is SMSQ ( in ROM ? ), which is loading a complied version of Linux optimised for SMSQ ? What is the actual sequence of a Q60 startup ? QDOS/SMSQ boots from ROM. That takes just a few seconds. If you just want to use QDOS/SMSQ, here you are. If you want to start Linux, you simply execute the Linux loader, which is an QDOS/SMSQ application. You can do that from the commandline or your bootfile or any other basic program. That will start the Linux kernel, which will leave QDOS/SMSQ and take control over the Q60. To get back to QDOS/SMSQ you shutdown Linux and reboot QDOS/SMSQ. Q40/Q60 Linux is no QDOS/SMSQ application except for the loader. It is directly based on the Q40/Q60 hardware just like PC Linux is based on the Intel PC hardware. This is much more than just an optimization, it is a complete operating system port. An enormous work - Richard deserves the highest respect for this achievement. BTW if you want to run a QDOS application while using Linux on a Q60, you can use a special version of UQLX. Unlike emulators on a PC it can run QDOS programs native on the 68060, which is of course a lot faster. Thanks for an excellent summary :-) ... that explains a lot, and much as I expected. I have not yet caught sight of a Q60 in real life, and only had brief dealings with a Q40 at various QL Shows. Keep up the good work, and make sure we all are informed of what can be done with a Q60. Richard has done 'sterling work' ... -- Malcolm Cadman
Re: [ql-users] Q60 and Linux
On 10 Jun 2001, at 21:23, Peter Graf wrote: BTW if you want to run a QDOS application while using Linux on a Q60, you can use a special version of UQLX. Unlike emulators on a PC it can run QDOS programs native on the 68060, which is of course a lot faster. Does that run QDOS classic or SMSQE? Wolfgang
Re: [ql-users] Q60 and Linux
Hi Malcolm, So the operating system on a Q60 is SMSQ ( in ROM ? ), which is loading a complied version of Linux optimised for SMSQ ? What is the actual sequence of a Q60 startup ? QDOS/SMSQ boots from ROM. That takes just a few seconds. If you just want to use QDOS/SMSQ, here you are. If you want to start Linux, you simply execute the Linux loader, which is an QDOS/SMSQ application. You can do that from the commandline or your bootfile or any other basic program. That will start the Linux kernel, which will leave QDOS/SMSQ and take control over the Q60. To get back to QDOS/SMSQ you shutdown Linux and reboot QDOS/SMSQ. Q40/Q60 Linux is no QDOS/SMSQ application except for the loader. It is directly based on the Q40/Q60 hardware just like PC Linux is based on the Intel PC hardware. This is much more than just an optimization, it is a complete operating system port. An enormous work - Richard deserves the highest respect for this achievement. BTW if you want to run a QDOS application while using Linux on a Q60, you can use a special version of UQLX. Unlike emulators on a PC it can run QDOS programs native on the 68060, which is of course a lot faster. All the best Peter
Re: [ql-users] Q60
On 20 Mar 2001, at 22:20, Peter Graf wrote: 128 MB RAM / 60 GB for example. But it wouldn't make sense. And let us pray that it never will Wolfgang
Re: [ql-users] Q60
Peter Graf wrote: Marcel wrote: Dilwyn Jones wrote: He he, I love Claus Graf's signature...never thought we'd see the time when we started throwing these sorts of figures around in SMSQDOS! I just hope the Q60 does see the light of day...as good as the emulators are I doubt we'll get this kind of setup from an emulator (no doubt Marcel will correct me!) At least you can easily beat the RAM and disc space values ;-) But don't think the Q60 is at its limits with Claus's modest setup ;-) What sorts of figures are possible if Claus's setup is a "modest" one, Peter? -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Q60
It would be a real shame to see all that hard work wasted. Is there any possibility that the complete design (Gerber files, PLD equations, schematics, etc.) could be put on a web site so anybody could get the PCB made up and buy in all the components. Obviously this would be an expensive route for the individual, but at least the Q60 would be available. An open hardware design could also lead to production by small companies in places like Russia and promote further development. Peter Graf wrote: Marcel, Fabrizio, Thierry, Wolfgang, Jerome: Thank you very much for your encouraging comments!!! If you look back to the GoldCard or the QXL you find that QL folks were willing to pay DM 1400 just for an addon-card. When the Q40 came out it was already difficult to find QL folks willing to pay DM 1000 for a complete motherboard. It has become almost impossible: Many QL folks (there are exceptions and I am thankful !!!) are willing to pay less and less while the cost for producing highend QL style hardware rises and rises. Still Q40 and Q60 have very competitive price/performance compared to other 68K machines, although the produced quantity is smaller. Of course Q40 and Q60 don't stand an apples-to-oranges comparison to a Windows machine. Once some non-technical problems have been solved, I will try to supply the most eagerly waiting persons with Q60 boards. I can only do that in a very small scale. The only other solution would be to find a person or company that is capable and willing to produce the Q60 *without* my involvement. *Maybe* the Q60 might be interesting for other 68k markets. But I definitely have no time for: - Looking for new markets/marketing - Support more software development - Support users outside the QL scene - More features / another hardware redesign - Support the hardware production So it seems not very realistic such a person or company will appear. Peter
RE: [ql-users] Q60
Peter, whatever you decide to do, good luck ! Regards, Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com -Original Message- From: Peter Graf [mailto:[EMAIL PROTECTED]] Sent: Monday, January 08, 2001 5:46 PM To: [EMAIL PROTECTED] Subject: [ql-users] Q60 The only other solution would be to find a person or company that is capable and willing to produce the Q60 *without* my involvement. *Maybe* the Q60 might be interesting for other 68k markets. But I definitely have no time for: SNIP
